 Hello everyone welcome to my talk. Today I'm going to share my research about how to attack Microsoft exchange servers in Active Directory with only a normal domain account. I'm Tian Zedin. I'm from Tencent Security's Xiong lab. I'm focusing on Active Directory security, web team operations and web application security. I have reported some vulnerabilities to several well-known companies such as Microsoft, Apple and Google. I have also shared my research at Blackhead Azure or Blackhead USA Arsenal. Here is the agenda of this talk. First I will give a brief overview of the attack surface of Microsoft exchange server. Next I will share two new vulnerabilities. I will show you how I can take over any exchange mailbox and how I treat RCE on exchange servers. As then I will detail a new method to help you perform lateral movements and escalate your privileges to domain admins after exchange server RCE. You may ask why I choose the exchange server as a research target. Microsoft exchange server is one of the most famous mail servers in the world especially for enterprise users. It stores large amounts of sensitive coverage information such as emails, email attachments, contacts, calendars of all users in your company. In emails there may be something that attackers are very interested in such as business plans, work arrangements, customer information and even contacts passwords. Most more, the service server is highly integrated with Microsoft Active Directory. Exchange server uses Active Directory for user authentication and the mailbox user user growth management. And it also stores amongst all configurations in Active Directory. HGC server must communicate with Active Directory to retrieve information about recipients and information about other exchange servers. So Active Directory must be available for exchange to function correctly. There are also some high privileged ideal jacks along with exchange servers. Usually you need to use enterprise admins to install your first exchange server in an organization. So there may be enterprise admins sessions on exchange servers. If an attacker compromised your exchange servers he may also have ability to compromise their enterprise admins. In all the versions in exchange servers, the exchange winners permission group has right DSTL rights on the domain object. If an attacker compromised your exchange server he could grant himself this sync rights and then escalate his privileges to domain admins. So exchange server not only stores a large amount of sensitive coverage information but also an effective way to escalate privileges to domain admins. So it has become a high value target for both APT groups and red teams. If only for vulnerable entities, we should have an overview of exchange server architecture and attack surface and pay more attention to those attack surface that are annoyed by other researches. As a mail server, exchange server has many client access services such as some exchange ACDS endpoints, some traditional mail services like POP3, NMEP, SMTPC, and unified messaging service for telephone. These exposed services are favorites of attackers, especially the web service. There are lots of exchange endpoints available to attackers such as OWE and ACP, which you can access directly with a browser, and other endpoints like EWS, MAPI, etc. which are mainly used by other loop. In the past few months, some high-risk vulnerability in exchange server has been exposed. Most of them mainly touch vulnerable ASP.net codes running on the IS server. But the architecture of exchange server is complicated. Is there any other attack surface in exchange server? In my opinion, the architecture of exchange server also contains the IS server based on my past web security research experiments. It's a very common situation that the web server was misconfigured by their web application developers. So maybe there will be some misconfiguration on the exchange IS server too. And Windows server is also an attack service. There are some services available to attackers in active directory environments. But in the server also supports both balancing architecture. There may be more than one exchange service in active directory, which may also bring new attack surface. And exchange server is highly integrated with the active directory. This may also bring new attack surface to both exchange servers and active directory. I will discuss this attack service in a following talk. Next, let's talk about the story of how to take over arbitrary exchange mailbox with only a normal domain account. When I was researching the exchange server, I found many ECP operations on the exchange PowerShell command lines support users to use UNC paths for file access. So this means if we have access to this ECP operations or this PowerShell command lines, we can trigger an assembly connection from exchange server to an assembly server. Next, we need to figure out which user's credential will be used in the assembly connection. This server uses a system account to run all its services. The system account is a local account. In active directory, more process running with the system account wants to perform network authentication. The credential of the machine account will be used for the authentication. As shown in the workshop, the exchange server will use the machine account exchange $1 to perform NTLM authentication in the assembly connection. So what can we do with the assembly connection and the NTLM authentication? How useful is it? Let's talk about the NTLM protocol first. NTLM is a very old authentication protocol in Windows system, but it's well-modulated for its Microsoft ecosystem in order to maintain compatibility with legacy clients and servers. And NTLM still plays an important role in active directory authentication. NTLM is an embedded protocol, which means it can be embedded in other protocols which need authentication functionalities, such as NTLM over SMB, NTLM over HTTP to server. And there is a famous attack about NTLM called NTLM Relay Attack. It's very old, but very useful in active operations. The NTLM Relay Attack works like this. If the victim is somehow tricked into accessing a malicious SMB server hosted by the attacker, the victim will be authenticated to the attacker. It will say, hey, let me log in to the SMB server. The attacker can relay the message from the victim to the attack team target and say, hey, I want to log in to the vulnerable service. The attack team target will send an NTLM challenge message to the attacker and say, hey, here's a challenge stream with hot sheets with your password. The attacker relay this message to the victim. Hey, victim, here's a challenge from a targeted target hashed with your password. Then the victim uses his password to calculate a challenge response and send it to the attacker. The attacker relay the challenge response directly to the targeted target and the targeted target check whether the challenge response is correct with the network on protocol. Finally, the attacker successfully logs in to the vulnerable service on the targeted target as domain text class victim. If the victim has some special privilege on the targeted target, the attacker can do something sensitive, can do some sensitive operations with the victim's identity, even RCE. So now we can trigger NTLM authentication of the exchange server machine count to perform NTLM relay attack. There are some preconditions for NTLM relay attack. Firstly, we need to figure out are there any vulnerable services on exchange server as the target of NTLM relay attacks? Then does the exchange server machine count has any special privileges on these services? A exchange server is highly integrated with Microsoft active-degree directory. There are many exchange endpoints for NTLM authentication such as the MAPI, EWS, RPC, auto-discovery, etc. Some of these endpoints are used by Outlook, which means that if an attacker can log in to these endpoints, he can perform almost any operations like a normal auto-look. Can we relay NTLM authentication to these endpoints? If the victim and the targeted target are the same machine, the NTLM relay attack is also called NTLM reflection. If there is only one exchange server in the active directory, can we perform the NTLM reflection attack? Can we relay the NTLM authentication of the machine account exchange one dollar back to exchange one? The answer is of course no. The patch of CVE 2018-8581 remote disabled loopback check configuration from the exchange server. So NTLM reflection is disabled on exchange server. And what if there is more than one exchange server in the AD? In my routine operations, it's a very common situation in enterprise environments that there are more than one exchange server in the active directory because of the need for load balancing. So we can relay the NTLM authentication from one exchange server to another. But there is a protection called EPA. What is EPA? EPA is a standard protection for authentication. It's a protection to defend against NTLM relay attacks for SSLR connection. There is a protection called channel banning in EPA. If channel banning is enabled in a web server, the client needs to calculate a channel banning token based on the TLS certificate of the ADTPS server and the user's NT hash. And as a token to the NTLM auth message, if the channel banning token is wrong, the server will not allow the client to log in. Attackers cannot afford a channel banning token without knowing the user's NT hash. Channel banning token and NTLM authentication over SMB are all zero by default. So if EPA is enabled, we can't relay NTLM authentication to exchange server and points. But fortunately, EPA is disabled on this exchange endpoints by default. Usually, most machine accounts in active directory are low-privileged accounts. Thus, there are exchange server machine accounts. Exchange server $1 has any special privileges on these endpoints. The answer is yes. Exchange machine account has an extended right called MS exchange API token serialization. As the output of the getAD permission command shots, all members of the exchange server group have token serialization rights on all exchange servers in their active directory. The exchange machine accounts are the members of the exchange server group. This means the exchange machine accounts have these special extended rights. For the EWS endpoints, if there is a serialized security contest field in an XML-RGDP request, it will try to create security access tokens based on the value of this field. If the client user has token serialization rights, he can use serialized security contest to force EWS to impersonate other exchange users, which means exchange machine accounts can impersonate other exchange users on EWS endpoints. An XML request with serialized security context is like this. You need to set the SID of the user you want to impersonate in serialized security context. And if you have a domain account in the active directory of the main user or the main computer account, you can easily read all the main user's SIDs or its LDAP query. You can also use SympactExchange.py to read all active mailboxes and corresponding user SIDs. After getting the user SIDs, you can set user SIDs in the serialized security context and impersonate any exchange user you want. So what can we do after logging in to the EWS endpoints as any exchange user? EWS is used by Outlook for Mac OS. So EWS supports almost all operations supported by Outlook. Such as FunFolder can be used to find all predefined and custom folders of mailbox users. FunItem can get emails in these folders and GetItem can read email contents. So if you can relay NTL authentication of exchange machine accounts to EWS, you can impersonate any exchange users and use this EWS API to read emails down the email attachments and emails as any exchange users. As we discussed before, we can trigger SMB connections with some ECB operations or some PowerShark manuals, but all these manuals are required high-privileged users. We can trigger NTL authentication with only a normal domain user without any special privileges. The printbar can do this. Tipkin found there is an RPC function called RPC Remote Find First Printer Change Notification in the print RPC. And this function is accessible by all domain users and domain computers. So any domain users or machine accounts in an active directory can make a request to the printer server and send their PSA local machine to an UNC pass. The printer server is running with a system account. It will immediately connect to the UNC pass and authenticate it to it with the machine account. So we can make a request to the exchange server and force their exchange machine account to authenticate it to us. So let's chat them all together. The XLAB backslash attacker is a normal domain user without any special privileges. I can talk to exchange one with printbar. Hey, exchange one authenticated to me as exchange $1 account. Then the exchange one established a semi-connection with the malicious SMB server hosted by the attacker and send NTLM authentication message to it. The attacker directly relates the NTLM authentication to the EWS endpoint on exchange two successfully looks in as exchange $1. Exchange $1 has token serialization rights on the EWS, so the attacker can impersonate any exchange users, which means the attacker can read emails, download attachments, send emails as any exchange user. I created a tool based on exchange relics to exploit this vulnerability. And here's a demo. There are two exchange servers in the active directory. The attacker says exchange two as the targeted target. The attacker can trigger an ACP connection from the exchange $1 to the attacker's machine with printbar. Next, the attacker can dump all mailboxes and user IDs. The attacker tries to take over victim's mailbox. The attacker can read victim's emails, download their email attachment. The emails read by the attacker are the same as the emails in the victim's outlook. Other contents of the attachment is also the same. Next, the attacker tries to take over administrator's mailbox. The attacker can read administrator's emails. Next, the attacker tries to send an email to victim as the administrator. The victim successfully received the email sent by the attacker. Let's talk about the patches. The APRO patch works as an exploit chain because the patch no longer allows machine accounts to log in to any exchange endpoints. And the vulnerability file was based on patch two exchange rack and assigned a single number CVE-2021-3768. In concurrent, if you have compromised a normal domain account, a domain user, or a machine account, and if there is more than one exchange server in the active directory, you can take over any exchange user's mailbox. So, are there any chance to achieve RCE on an exchange server with similar attack methods? When an exchange server was originally installed, it creates a high-privileged group named Exchange Fasted Subsystem Group in Active Directory. All members in this group have local administrator privileges on all exchange servers in a domain. And exchange server and machine accounts are members of these high-privileged groups. If we can relate anti-armor authentication of exchange server and machine accounts to some remote management service drawn around windows, maybe we can achieve RCE. Someone might say that maybe we can relate anti-armor authentication to the SMB and do something like PSEXEXCC, but unfortunately, SMB sign-in is enabled by default on an exchange server, so we can't relate anti-armor authentication to SMB of another exchange server. There are also some other remote management protocols like WNRM. WNRM also supports anti-armor authentication, but sign-in and sign-in are all enabled on its HTTP service, and channel winding is enabled in its HTTPS channel. So, relate anti-armor authentication to WNRM is also impossible. MSRPC is a remote-produced protocol implemented by Microsoft based on DCRPC. MSRPC supports multiple RPC types. The most common RPC types that can be accessed remotely over the network are ICACN-MP and ICACN-IPTCP can relate to anti-armor SMB to Microsoft RPC. To Microsoft RPC, ICACN-MP uses SMB as their transport protocol. Obviously, it cannot be our attack target. ICACN-IPTCP uses ports 135 and a dynamic port designed by the EPM to accept connections from RPC clients. There are many RPC interfaces available for us. RPC clients can set the OST type to RPC-C-OSTN WNT to use NTRM-SSP to authenticate to these RPC interfaces. Some security researchers have disclosed some RPC interfaces that are affected by the anti-armor related attack, such as the CVE-2020-1113. If the anti-armor related vulnerability exists in the task scheduler service, a attacker can relay NTRM authentication to task scheduler RPC and finally skewed commands remotely. CVE-2020-1167H is a NTRM-related vulnerability that exists in the print explorer service. attacker can relay NTRM authentication to print explorer RPC and finally conducts any files on the remote system. DECOM is filled on top of MS RPC, so how about DECOM? Is there an anti-armor related vulnerability in DECOM? Let's take a look. The common DECOM connection goes like this. Clients first connect to the port-100-35 on the DECOM server and send the anti-armor indication to it. After a successful login, the client will make a remote pretty instance request and the request includes both the class ID and interface ID. Then the remote service control manager on the DECOM server becomes responsible for the DECOM object activation. If the remote object is well-activated, an interface pointer OBGIF will be sent back to the client. The OBGIF contains a field called stream binings and the DECOM client can reach the object explorer with the stream binings. The client will then connect to the IP and the port according to the stream binings and send an anti-armor indication to the server. After a successful indication, the client can object the RPC request to use the remote COM object. The MSRPC supports several authentication levels. The RPC-C-Orson-Level-Connect authentication level indicates that the RPC connection doesn't need to be encrypted and signed. Understanding and solving are not supposed to enable which aren't DECOM servers. The authentication level of an RPC connection can be completely determined by the DECOM client. So, attackers can also set the RPC-Orson-Level to RPC-Orson-Level-Connect to avoid encrypting and signing and relay anti-armor indication over SMB to DECOM. Now, we can relay anti-armor indication to DECOM. We need to find a COM object to help us use skilled commands on the remote system. As a well-known technology based on DECOM and SWMI, it allows emitters to manage the remote system and skilled commands on the remote systems. But the protocol of WMI is a bit complicated. There are also some simple COM objects and all of them can be used to execute commands on the remote system. Here, we choose an MSC-20 application to help us execute commands on the remote system after a successful anti-armor relay. MSC-20 application has an API called a skilled short command which can be used to execute commands on the remote system. Why finally choose to use MSC-20 to execute commands? Compared to Shellwindow and Shellbrowserwindow, MSC-20 application is still available on latest Windows Server 2019. And compared to WMI, WMI requires authenticating to too many RPC interfaces. But MSC-20 only requires twice anti-armor indications. Just like the workshop shows, the MSC-20 needs to authenticate to the iSystemActivator interface on the IP dispatch interface. It's friendly to the exploitive development, so MSC-20 is the best choice for us. So, let's chat them all together. The XLAB backslash attacker is a normal domain user without any special privileges. I can talk to the exchange one with printback hey exchange one authenticated to me as exchange $1 account. Then the exchange one sends anti-arm authentication message to the malicious SMB server hosted by the attacker. And there can be multiple anti-armor indications in an ICD connection. So, the attacker doesn't need to send a second printback request to trigger a second anti-armor indication. The attacker can directly relay first anti-arm authentication to the Decom iSystemActivator interface on their exchange two and use create remote instance to active the remote MSC-20 application project. And then relay the second anti-arm authentication to the Decom iD dispatch interface and find their SQL shell command and invoke it to SQL commands remotely. Here's the demo. There's no calculator process on exchange one. And there is no calculator process on exchange two. First, start attacking exchange two. The attacker can trigger a sending connection from exchange one to the attacker with printback. Now, the calculator has been executed on exchange two. Next, let's start attacking exchange one. The attacker can trigger an SMB connection from exchange two to attacker. And calculator has been executed on exchange one. Actually, this is a vulnerability exists in Windows Decom not in the exchange server. But we can use it to attack exchange servers. This vulnerability has been fixed and assigned CVE-2021-26414. But after installing the patch, you need to manually to set require integrity activation authentication level to one in the registry to enable the protection for Decom. This protection will force enable RPCC OS level PKT integrity. After Q4-2021, this protection will be enabled by default on Windows. In conclusion, if you have compromised a normal domain account, a domain user or a machine account, and if there is more than one exchange server in the active directory, you can execute any commands remotely on this exchange server. RCE is only the beginning for web teams. In this patch, I will introduce a new method to help you perform natural moments and privilege and escalation to domain admin after RCE on exchange server. When exchange server was originally installed, it configures and grants itself extensive active directory permissions. These permissions provide necessary access that exchange server may ever need. There are some privileged escalation methods with these permissions, such as abusing RedDSL on a domain object, and abusing DSLame's group. By this attack passes had been fixed in 2019. There are also some natural moment methods, such as abusing false-change password writes on the main users to false-change users' passwords. But attackers cannot recover the victim user's original passwords because they don't know the plant-type passwords of the victims. Attackers could also abuse the RedDSL writes on the main users and set SPN on the main users and perform their copyrights gene attack. That sometimes is hard to brute-force passwords, because there is a complex password policy. I think that there are no easy-to-use natural moment methods and no privileged escalation methods after exchange server RCE. So, let's introduce a new one. Let's introduce the exploitive parameters firstly. Suppose the attacker already colonized the exchange server he had taken fully controlled the exchange server machine counter to exchange one dollar. He can download the empty hash of the exchange one dollar and do anything as exchange one dollar. The exchange one dollar is a member of exchange trust-based subsystem, and exchange trust-based subsystem is a member of exchange-based permission. Exchange-based permission can add a member to group policy create owners and exchange trust-based systems. So, the attacker can add users to these three high-privileged groups. The members of exchange-windows permission group can create new organizational units in Active Directory. And the members of group policy create owners group can create new group policy objects in Active Directory. The members of exchange-windows permission group has right distinguished name, right name, right name, and delete object writes on domain orders and domain computers. With this right, exchange-windows permission group can move domain orders or domain computers to other containers. Next, let's design a new lateral moment method. First, the attacker can add himself to exchange trust-based subsystem group and group policy create owners group. Then he will get the same permissions as these two high-privileged groups. Then the attacker can create an evo.io and an evo.gpu. Next, he can create a gpu link from the evo.io to the evo.gpu. This allows the process in the evo.gpu to take an effort on evo.io. And the attacker can add user immediate task to the evo.gpu which is to execute attacker's commands. Here is purple calculator. Then the attacker can move the victim user to the evo.io and just wait for the group policy to refresh. When the group policy is refreshed, the victim will purple calculator. The waiting time will be longer than the gpu refresh time because gpu group policy engine need to think all your information of the victim with the active directory firstly. After the attack, the attacker can move the victim to his original orio and remove the evo.io and the evo.gpu. I didn't find a writing tool that can manipulate gpu remotely so I create a new one called sharp.gpu. You can find it in my github. We can use sharp.gpu to create all your gpu.gpu links in the active directory. We can use sharp.gpu abuse to create malicious group policies such as user immediate tasks and the computer immediate tasks. Here's a demo I will show how the attacker moves naturally to the victim and pops calculator as their victim user. The computer on the left side is the victim. The computer on the right side is the attacker. Now the attacker is a member of domain users. The attacker can add himself to high privileged groups if he has compromised exchange $1. Now the attacker has been added to these two high privileged groups. And then the attacker can create an evo.io and an evo.gpu and link the evo.gpu to the evo.io. And add a malicious user immediate tasks to the evo.gpu. Next move the victim to the evo.io and just wait for the group policy to refresh or wait for the victim to log in again. When the victim logs in successfully the group policy will be refreshed and the calculator is executed. After the attack, the attacker can move the victim to his original.io and remove their evo.io and evo.gpu. You may ask, can we escalate our privileges to domain domains? Can we move their domain domains to the evo.io? The answer is we can't because of the domain SD holder. A domain SD holder provides a permission template for the protected accounts and groups. All domain domains have the domain account attributes set to one, which means they are protected by a protected by a domain SD holder. For a new domain domain is created in the acute directory, the exchange does have permissions to move it to the evo.io. But about 60 minutes later, the permission will be removed because of the domain SD holder. So we can't apply malicious group policies to domain domains. Unfortunately, the computer projects in domain controllers group are not protected by a domain SD holder. So, the attacker can create a new orio or new gpu and create a gpu.link as before. Next, add a malicious computer immediate text to the evo.computer gpu, then move the domain controller to the evo.computer orio and just wait for the group policy to refresh on the domain controller. When group policy is refreshed, a calculator will be executed on domain controller with the system accounts. Now, the attacker can fully control the domain controller and the entire active directory. If you are worried about that moving the domain controller to a new orio will affect the functionality of it, you can apply original orio default domain controller policy to evo.computer orio. After the attack, the attacker can move the domain controller to its original orio and remove the evo orio and evo.gpu. Here's the demo. I will show how the attacker moves naturally to the domain controller. I will post calculators with the system accounts. The computer on the left side is the domain controller. Now, there is no calculator process on the domain controller. Next, we run a route loop to check where the calculator is executed. The computer on the right side is the attacker. Now, the attacker is a member of domain users. Attacker can add himself to high-prevaged groups if he has compromised exchange $1. Now, the attacker has been added to these two high-prevaged groups. Next, the attacker can create an evo.computer orio and an evo.computer.gpu. I will link the evo.computer.gpu to the evo.computer.orio. Next, add a malicious computer immediate task to the evo.computer.gpu and move the domain controller to the evo.computer.orio. I just wait for the group policy to refresh on the domain controller. About 30 minutes later, the calculator is executed with a system account. After the attack, the attacker can move the domain controller to its original orio and remove their evo.computer orio and evo.computer.gpu. Here is the mitigation. You can switch your external server to Active Directory's deleted permissions model. This model effectively limits our exchange rise in Active Directory. Attackers cannot use the models we talked about to perform lateral movement and privilege escalation. Conclusion and takeaways. The ratings in this talk are disclosed to two new exchange server vulnerabilities. The first one can be styled in Active Directory mailbox takeover. Attackers can read mails or download attachments, send emails, etc. as any exchange user. The second one can lead to remote code execution on exchange servers. I also introduced a new method to help your lateral movement and help you escalate your privilege to domain means after exchange RCE. For routines, you'll need to patch all your vulnerable exchange servers and their window service, your exchange servers around here. And it's possible switch your exchange server to Active Directory's delete permissions model to prevent attackers from escalating privileges. This tracked anti-army usage as much as possible to prevent some anti-army related attacks is also useful. Thanks to all these security researchers and their amazing work, their work inspired me a lot. And also thanks to MSRC for their hard work in fixing these vulnerable abilities. Okay, thanks for your listening.