DEF CON 29 - Tianze Ding - Vulnerability Exchange: One Domain Account For More Than Exchange Server

00:04 - Today, I’m going to share my research about how to attack Microsoft Exchange Servers in Active Directory with only a normal domain account.

00:15 - I’m Tianze Ding. I’m from Tencent Security Xuanwu Lab.

00:19 - I’m focusing on Active Directory Security, red team operations, and web application security.

00:26 - I have reported some vulnerabilities to several well-known companies, such as Microsoft, Apple, and Google.

00:34 - I have also shared my research at Black Hat Asia or Black Hat USA Arsenal.

00:42 - Here is the agenda of this talk. First, I will give a brief overview of the attack surface of Microsoft Exchange Server.

00:50 - Next, I will share two new vulnerabilities.

00:54 - I will show you how I can take over any Exchange mailbox and how I achieve RCE on Exchange Servers.

01:01 - And then, I will detail a new method to help you perform lateral movement and escalate your privilege to Domain Admins after Exchange Server RCE.

01:13 - You may ask, why I choose Exchange Server as a research target? Microsoft Exchange Server is one of the most famous mail servers in the world, especially for enterprise users.

01:24 - It stores large amounts of sensitive corporate information such as emails, email attachments, contacts, calendars of all users in your company.

01:36 - Emails, there may be something that attackers are very interested in, such as business plans, work arrangements, customer information, and even plain text passwords.

01:50 - What’s more, Exchange Server is highly integrated with Microsoft Active Directory.

01:56 - Exchange Server uses Active Directory for user authentication, and mailbox, user, user group management.

02:04 - And it also stores almost all configuration in Active Directory.

02:09 - The Exchange Server must communicate with Active Directory to retrieve information about the restrictions and information about other Exchange Servers.

02:17 - So Active Directory must be available for Exchange to function correctly.

02:23 - There are also some high-privileged AD objects along with Exchange Servers.

02:28 - Usually you’ll need to use enterprise admins to install your first Exchange Server in an organization.

02:36 - So there maybe Enterprise Admins such as on Exchange Servers.

02:41 - If an attacker compromised your Exchange Servers, then they also have ability to compromise the Enterprise Admins.

02:49 - In the older version Exchange Servers, the Exchange Windows Permissions group has WriteDACL rights on the domain object.

02:59 - If an attacker compromised the Exchange Server, he could grant himself distinct rights and then escalate his privileges to Domain Admins.

03:09 - So Exchange Server normally stores a large amount of sensitive corporate information, but also an effective way to escalate privilege to Domain Admin.

03:20 - So it has become a high-value target for both APT groups and red teams.

03:28 - Even only for vulnerabilities, we should have an overview of Exchange Server architecture and attack surface that pay more attention to those attack surface that you know it about other features.

03:41 - As a mail server, Exchange Server has many client access services such as some Exchange HTTPS endpoints, some traditional mail services like POP3, IMAP, SMTP, and unified messaging service for telephone.

03:59 - This exposed services are favorites of attackers, especially the web service.

04:04 - There are lots of Exchange endpoints available to attackers such as OWA and ECP, which you can access directly with a browser, and other endpoints like EWS and MAPI, et cetera, which are mainly used by Outlook.

04:24 - In the past few months, some high-risk vulnerabilities in Exchange Server have been exposed.

04:31 - Most of them mainly attack vulnerable ASP. NET code running on the IIS Server.

04:39 - But the architecture of Exchange Server is complicated.

04:42 - Is there any other attack surface in Exchange Server? In my opinion, the architecture of Exchange Server also contains the IIS Server.

04:54 - Based on my past web security research experiments, it’s a very common situation that the web server was misconfigured by the web application developers.

05:05 - So maybe there will be some misconfiguration on the Exchange IIS Server too, and Windows Server is also an attack surface.

05:14 - There are some services available to attackers in Active Directory environment.

05:21 - Exchange Server also supports load-balancing architecture.

05:26 - There may be more than one Exchange Servers in Active Directory which may also bring new attacks surfaces.

05:33 - And Exchange Server is highly integrated with Active Directory.

05:38 - This may also bring new attack surface to both Exchange Servers and Active Directory.

05:44 - I will discuss this attack surface in the following talk.

05:50 - Next, let’s talk about the story of how to take over arbitrary Exchange mailbox with only a normal domain account.

05:59 - While I was researching the Exchange Server, I found many ECP operations on Exchange PowerShell cmdlets supports users to use UNC paths for file access.

06:11 - So this means if we have access to these ECP operations or these PowerShell cmdlets, we can trigger an SMB connection from Exchange Server to an SMB server.

06:24 - Next, we need to figure out which user’s credential will be used in the SMB connection.

06:30 - Exchange Server use a SYSTEM account to run all its services.

06:34 - The SYSTEM account is a local account. In Active Directory, one process running with a SYSTEM account wants to perform network authentication.

06:45 - The credential of the machine account will be used for the authentication.

06:50 - As shown in the workshop, the Exchange Server will use the machine account, Exchange1$, to perform NTLM authentication in the SMB connection.

07:01 - So what can we do with the SMB connection and the NTLM authentication? How useful is it? Let’s talk about the NTLM protocol firstly.

07:14 - NTLM is a very old authentication protocol in Windows system but it’s widely deployed in Microsoft ecosystem in order to maintain compatibility with legacy clients and servers.

07:29 - And NTLM still plays an important role in Active Directory authentication.

07:34 - 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 at the server.

07:49 - And there is a famous attack about NTLM called NTLM relay attack.

07:55 - It’s very old but very useful in red team operations.

08:01 - 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 send a ticket to the attacker.

08:15 - It will say, “Hey, let me log into the SMB server. ” The attacker can relay the message from the victim to the attacked target, and say, “Hey, I want to log “into the vulnerable service. ” Now, attacked target will send an NTLM challenge message to the attacker, and say, “Hey, here’s a challenge string, “please hash it with your password. ” The attacker relay this message to the victim, “Hey victim, here’s the challenge “from attacked target, hash it with your password.

” Then the victim uses his password to calculate a challenge response and send it to the attacker.

08:53 - The attacker relay the challenge response directly to the attacked target, and the attacked target check whether the challenge response is correct with the NETLOGON protocol.

09:07 - Finally, the attacker successfully logs into the vulnerable service on the attacked target as DOMAIN\victim.

09:16 - If victim has some special privilege on the attacked target, the attacker can do something sensitive, also can do some sensitive operations with the victim’s identity, even RCE.

09:32 - So now, we can trigger NTLM authentication of the Exchange Server machine account.

09:38 - Can we perform NTLM relay attack? Yeah, some preconditions for NTLM relay attack.

09:45 - Firstly, we need to figure out are there any vulnerable services on Exchange Server as the target of NTLM relay attacks.

09:52 - Then does the Exchange Server machine account has any special privileges on these services.

10:01 - As Exchange Server is highly integrated with Microsoft Active Directory, there are many essential endpoints post-NTLM authentication such as /mapi, /EWS, /Rpc, /Autodiscover, et cetera.

10:17 - Some of these endpoints are used by Outlook, which means that if an attacker can log into these endpoints, he can perform almost any operations like a normal Outlook.

10:31 - Can we relay NTLM authentication to these endpoints? If the victim and the attacked target are the same machine, the NTLM relay attack is also called NTLM reflection.

10:46 - 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, Exchange1$ back to Exchange1? The answer is of course, no.

11:03 - The patch of CVE-2018-8581 Remove DisableLoopbackCHECK configuration from Exchange Server.

11:14 - So NTLM reflection is disabled on Exchange Server.

11:20 - And what if there is more than one Exchange Server in the AD? In my red team operations, it’s a very common situation in the past environments as there are more than one Exchange Server in the Active Directory because of the need for load balancing.

11:42 - So we can relay the NTLM authentication from one Exchange Server to another, but there is a protection called EPA.

11:53 - What is EPA? EPA is Extended Protection for Authentication.

11:57 - It’s a protection to defend against NTLM relay attacks.

12:01 - For SSL connection, there is a protection called channel binding in EPA.

12:08 - Your channel binding is enabled in a web server.

12:10 - The client needs to calculate a channel binding token based on the TLS certificate of the HTTPS server and the user’s NT hash.

12:20 - And as a token to the NTLM auth message, if the channel binding token is wrong, the server will not allow the client to log in.

12:29 - Attackers cannot forge a channel binding token without knowing the user’s NT hash.

12:38 - Channel binding token in NTLM authentication over SMB are all zero by default.

12:43 - So if EPA is enabled, we can’t relay NTLM authentication to Exchange Server endpoints.

12:51 - But fortunately, EPA is disabled, and there is Exchange endpoints by default.

12:58 - Usually, most machine accounts in Active Directory are low-privilege accounts.

13:05 - Does the Exchange Server machine account, ExchangeServer1$, has any special privileges on these endpoints? The answer is yes.

13:18 - The Exchange machine account has extended rights called ms-Exch-EPI-Token-Serialization.

13:26 - As the output of the Get -ADPermission command shows, all members of the Exchange Server group have token serialization rights on all Exchange Servers in the Active Directory.

13:38 - The Exchange machine accounts has the members of the Exchange Server group.

13:43 - This means the Exchange machine accounts had this special extended right.

13:51 - For the EWS endpoint, if there is a SerializedSecurityContext field in an XML HTTP request, it will try to create security access tokens based on the value of this field.

14:03 - If the client user has token serialization rights, they can use SerializedSecurityContext to force EWS to impersonate other Exchange users, which means Exchange machine accounts can impersonate other Exchange users on EWS endpoint.

14:21 - An XML request always serialize the security context is like this.

14:26 - You need to set the SID of the user you want to impersonate in SerializedSecurityContext, and if you have a domain account in the Active Directory, a domain user or a domain computer account, you can easily read out the mailer’s SID, so it’s LDAP query.

14:43 - You can also use impacket/exchanger. py to read all active mailboxes and corresponding UserSids.

14:51 - After getting the UserSids, you can set UserSids in the SerializedSecurityContext and impersonate any external user you want.

15:04 - So what can we do after logging into the EWS endpoint as any Exchange user? EWS is used by Outlook for MacOS, so EWS supports almost all operations supported by Outlook such as FindFolder can be used to find all pre-defined and custom folders of Outlook users.

15:31 - FindItem can get emails in these folders, and GetItem can read email contents.

15:40 - So if you can relay NTLM authentication of Exchange machine accounts to EWS, you can impersonate any Exchange users, and it uses EWS API to read emails, download email attachments, send the emails as any Exchange users.

16:01 - So we discussed it before, we can trigger SMB connections with some ECB operations or some PowerShell cmdlets, but all these methods required high-privileged users.

16:13 - Can we trigger NTLM authentication with only a normal domain user without any special privileges? The Printer Bug can do this.

16:21 - Tifkin found there’s an RPC function called RpcRemoteFindFirstPrinterChangeNotification in the printer RPC, and this function is accessible by all domain users and domain computers.

16:34 - So any domain users or machine accounts in the Active Directory can make a request to the printer server, and set the pszLocalMachine to a UNC path.

16:44 - The printer server is running with the SYSTEM account.

16:47 - It will immediately connect to the UNC path and authenticated towards machine account.

16:54 - So we can make a request to Exchange Server and forge the Exchange machine account to authenticated to us.

17:05 - So let’s chain them all together. XLAB\attacker is a normal domain user without any special privileges.

17:14 - He can talk to Exchange1 with Printer Bug, “Hey, Exchange1, authenticate it “to me as Exchange1$ account. ” Then the Exchange1 establish an SMB connection with a malicious SMB server hosted by the attacker, and send NTLM authentication message to it.

17:32 - Attacker directly relays the NTLM authentication to the EWS endpoints on Exchange2, and successfully logs in as Exchange1$.

17:44 - Exchange1$ has token serialization rights on the EWS.

17:48 - So attacker can impersonate any Exchange users, which means the attacker can read mails, download attachments, send emails as any Exchange user.

18:02 - I created a tool based on ExchangeRelayToEWS to exploit this vulnerability, and here’s a demo.

18:15 - There are two Exchange Servers in the Active Directory.

18:32 - The attacker sets Exchange2 as the attacked target.

18:46 - The attacker can trigger SMB connection from the Exchange1 to the attacked machine with Printer Bug.

19:16 - Next, the attacker can dump all mailboxes and user IDs.

19:27 - The attacker tried to take over victim’s mailbox.

19:40 - The attacker can read victim’s emails, download the email attachment.

20:06 - The emails read by the attacker are the same as the emails in the victim’s Outlook.

20:16 - Other content or the attachment is also the same.

20:31 - Next, the attacker tried to take over administrator’s mailbox.

20:49 - The attacker can read administrator’s emails.

21:01 - Next, the attacker tried to send an email to victim as the administrator.

21:38 - The victim successfully received the email sent by the attacker.

21:46 - Let’s talk about the patches. The April patch breaks the exploit chain because the patch no longer allows machine accounts to log into any Exchange endpoints, and the vulnerability finally was fixed on Patch Tuesday in July, and assigned a CVE number, CVE-2021-33768.

22:05 - In conclusion, if you have compromised a normal domain account, a domain user, or machine accounts, and if there is more than one Exchange Server in your Active Directory, you can take over any Exchange user’s mailbox.

22:21 - So is there any chance to achieve RCE on Exchange Server with similar attack methods? When Exchange Server was originally installed, it creates a high-privileged group named Exchange Trusted Subsystem group in Active Directory.

22:39 - All members in this group have local administrator privilege on all Exchange Servers in your domain.

22:46 - And Exchange Server machine accounts are members of this high-privileged group.

22:51 - If we can relay NTLM authentication of Exchange Server machine accounts to some remote management service running on Windows, maybe we can achieve RCE.

23:01 - Someone might say that maybe we can relay NTLM authentication to the SMB and do something like IPS like a CC, but unfortunately, SMB signing is enabled by default on Exchange Server, so we can’t relay NTLM authentication to SMB over another Exchange Server.

23:19 - There are also some other remote management protocols like WinRM.

23:23 - WinRM also supports NTLM authentication. When signing and sealing are all enabled on its HTTP service, and channel binding is enabled in its HTTPS channel, so relay NTLM authentication to WinRM is also impossible.

23:41 - MSRPC is the remote procedure call protocol implemented by Microsoft based on DCE/RPC.

23:47 - MSRPC supports network RPC types. The most common RPC types that can be accessed remotely over the network are NCACN_NP and NCACN_IP_TCP.

23:59 - Can relay to NTLM over SMB to Microsoft RPC.

24:04 - NCACN_NP use SMB as the transport protocol.

24:08 - Obviously, it cannot be our attacked target.

24:14 - NCACN_IP_TCP used port 135 and a dynamic port assigned by the EPM to accept connections from RPC clients.

24:25 - There are many RPC interfaces available for us.

24:29 - RPC clients can set the auth type to RPC_C_AUTHN_WINNT to use NTLM as its key to authenticate to these RPC interfaces.

24:44 - Some security researchers have disclosed that some RPC interfaces that are affected by the NTLM relay attack, such as the CVE-2020-1113 based on NTLM relay vulnerability exists in the Task Scheduler service.

25:00 - An attacker can relay NTLM authentication to Task Scheduler RPC and finally, execute commands remotely.

25:07 - CVE-2021-1678 is NTLM-related vulnerabilities existed in the Printer Spooler service.

25:16 - An attacker can relay NTLM authentication to Printer Spooler RPC and finally, can write any files on the remote system.

25:26 - DCOM is built on top of MSRPC, so how about DCOM? Is there a NTLM relay vulnerability in DCOM? Let’s take a look.

25:34 - A common DCOM connection goes like this. A client firstly, connect to the port 135 on the DCOM server, and send NTLM authentication to it.

25:43 - After a successful login, the client will make a RemoteCreateInstance request, and the request includes poster class ID and interface ID.

25:52 - Then the remote service control manager on the DCOM server become responsible for the DCOM object activation.

25:59 - If the remote object is the well-activated on interface pointer, OBJREF will be sent back to the clients.

26:06 - The OBJREF contains a field called StringBindings and the DCOM client can reach the object explorer with the StringBindings.

26:15 - The client will then connect it to the IP and import according to the StringBindings, and send an NTLM authentication to the server.

26:25 - After a successful authentication, the client can send an object RPC request to use the remote COM object.

26:34 - The MSRPC supports several authentication levels.

26:37 - The RPC_C_AUTHN_LEVEL_CONNECT authentication level indicates that the RPC credentials needs to be encrypted and signed.

26:45 - And the signing and sealing are not supposed enabled on DCOM servers.

26:49 - The authentication level of an RPC connection can be cumulatively determined by the DCOM clients.

26:56 - So attackers can also set the RPC auth level to RPC_C_AUTHN_LEVEL_CONNECT to avoid encrypting and signing under relay NTLM authentication over SMB to DCOM.

27:13 - Now, we can relay NTLM authentication to DCOM.

27:15 - We need to find a COM object to help us execute commands on the remote system.

27:20 - As a well-known technology based on DCOM is WMI, it allows administrators to manage remote system and execute commands on the remote systems but the protocol of WMI is a bit complicated.

27:34 - There are also some simple COM objects and all the COM methods to execute command on the remote system.

27:41 - Here, we choose an MMC20. Application to help us execute commands on remote system after a successful NTLM relay.

27:50 - MMC20. Application has an API called ExecuteShellCommand, which can be used to execute commands on remote system.

27:58 - Why I finally choose to use MMC20 to execute commands compared to ShellWindow and ShellBrowser window? MMC20. Application is still available on latest Windows Server 2019, and compared to direct online.

28:12 - Direct online requires authenticating to too many RPC interfaces.

28:16 - But MMC20 only will require twice NTLM authentications.

28:21 - Just like the Windows Shell, the MMC20 needs to authenticate to the ISystemActivator interface and the IDispatch interface.

28:29 - It’s friendly to the exploit development, so MMC20 is the best choice for us.

28:37 - So let’s chain them all together. The XLAB\attacker is a normal domain user without any special privilege.

28:44 - It can talk to the Exchange1 with Printer Bug, “Hey, Exchange1, authenticate to me “as Exchange1$ account. ” Then the Exchange1 sends NTLM authentication message to the malicious SMB server hosted by the attacker.

28:59 - And there can be multiple NTLM authentications in an ICD connection.

29:05 - So the attacker doesn’t need to send a second Printer Bug request to trigger a second NTLM authentication.

29:11 - Attacker can directly relay first, the NTLM authentication to the DCOM ISystemActivator interface on the Exchange2, and it’ll create remote instance to active the remote MMC20. Application COM object.

29:26 - And then relay the second NTLM authentication to the DCOM IDispatch interface, and finds the ExecuteShellCommand, and invoke it to execute commands remotely.

29:39 - Here’s the demo. There’s no calculator process on Exchange1.

29:54 - And there is no calculator process on Exchange2.

30:06 - First, start attacking Exchange2. Attacker can trigger an SMB connection from Exchange1 to attacker with Printer Bug.

30:34 - Now, the calculation has been executed on Exchange2.

30:43 - Next, we’ll start attacking Exchange1. Attacker can trigger an SMB connection from Exchange2 to attacker.

31:01 - And calculator has been executed on Exchange1.

31:07 - Actually, this is a vulnerability exists in Windows DCOM, not in the Exchange Server.

31:14 - But we can use it to attack Exchange Servers.

31:17 - This vulnerability has been fixed and assigned CVE-2021-26414 but after installing the patch, you’ll need to manually to set RequireIntegrityActivationAuthenticationLevel to one in the registry to enable the protection for DCOM.

31:37 - This protection will force enable RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.

31:42 - After Q4 2021, this protection will be enabled by default on Windows.

31:49 - 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.

32:06 - RCE is only the beginning for red teams. In this part, I will introduce a new manual to help you perform lateral movements and privilege escalation to Domain Admin after RCE on Exchange Server.

32:23 - When Exchange Server was originally installed, it configures and grants itself extensive Active Directory permissions.

32:30 - The permissions provide necessary access that Exchange Server may ever need.

32:35 - Yeah, some privilege escalation methods with this permission such as abusing WriteDACL on the domain object, and abusing DNS Admins group.

32:44 - But this attack passage had been fixed in 2019.

32:48 - There are also some lateral movement methods such as abusing ForceChangePassword right on domain users to force change users’ passwords.

32:57 - But attackers cannot recover the victim users’ original passwords because they don’t know the plain text passwords of the victims.

33:04 - Attackers could also abuse the WriteDACL rights on domain users, and to set SPN on domain users, and perform the Kerberoasting attack.

33:15 - But sometimes it’s hard to brute force passwords if there is a complex password policy.

33:22 - It seems that there are no easy-to-use lateral movement methods and no privilege escalation methods after Exchange Server RCE.

33:31 - So let’s introduce a new one. Let’s introduce the exploit primitives firstly.

33:41 - Supposed the attacker already compromised the Exchange Server, he can fully control the Exchange Server machine account, Exchange1$.

33:50 - He can download the NT hash of the Exchange1$ and do anything as Exchange1$.

33:56 - The Exchange1$ is a member of Exchange Trusted Subsystem, and the Exchange Trusted Subsystem is a member of Exchange Windows Permission.

34:06 - Exchange Windows Permission currently a member to Group Policy Creator Owners and Exchange Trusted Subsystem.

34:13 - So the attacker can add users to these three high-privileged groups.

34:22 - The members of Exchange Windows Permission group can create new organizational units in Active Directory, and the members of Group Policy Creator Owners group can create new group policy objects in Active Directory.

34:40 - The members of Exchange Windows Permission group has Write Distinguished Name, Write Name, Write Name, and Delete Object rights on domain users and domain computers.

34:52 - With these rights, the Exchange Windows Permission group can move domain users or domain computers to other containers.

35:01 - Next, let’s design a new lateral movement method.

35:04 - First, the attacker can add himself to Exchange Trusted Subsystem group, and the Group Policy Creator Owners group.

35:12 - They have again the same permissions as these two high-privileged groups.

35:18 - Then the attacker can create an EvilOU and an EvilGPO.

35:22 - Next, they can create a gPLink from the EvilOU to the EvilGPO.

35:26 - This allows the policies in the EvilGPO to take an effort on EvilOU.

35:33 - And the attacker can add the user immediate tasks to the evil GPO, which is due to execute attacker’s commands.

35:42 - Here is public calculator. Then the attacker can move the victim user to the EvilOU, and just wait for the group policy to refresh.

35:54 - When the group policy is refreshed, the victim will pop a calculator.

35:59 - The waiting time will be longer than the GPO refresh time because GPO group policy engine need to sync all the information of the victim with the Active Directory firstly.

36:12 - After the attack, the attacker can move the victim to his original OU, and then remove the EvilOU and the EvilGPO.

36:23 - I didn’t find a red team tool that can manipulate GPO remotely, so I created a new one called SharpGPO.

36:30 - You can find it in my GitHub. We can use SharpGPO to create OUs, GPOs, gPLinks in Active Directory.

36:37 - We can SharpGPOAbuse to create malicious group policies such as User Immediate Task and Computer Immediate Task.

36:49 - Here’s a demo, I will show how the attacker moves laterally to the victim and pops calculator as the victim user.

36:59 - The computer on the left side is the victim.

37:03 - The computer on the right side is the attacker.

37:08 - Now, the attacker is a member of Domain Users.

37:15 - The attacker can add himself to high-privileged groups if he has compromised Exchange1$.

37:37 - Now, the attacker has been added to these two high-privileged groups.

37:48 - And then, the attacker can create an EvilOU and an EvilGPO.

38:02 - And link the EvilGPO to the EvilOU. And add a malicious user immediate task to the EvilGPO.

38:25 - Next, we move the victim to the EvilOU. And just wait for the group policy to refresh or wait for the victim to log in again.

38:45 - When the victim logs in successfully, the group policy will be refreshed.

38:58 - And the calculator is executed. After the attack, the attacker can move the victim to his original OU and remove the EvilOU and EvilGPO.

39:16 - You may ask can we escalate our privilege to Domain Admins? Can we move the Domain Admins to the EvilOU? The answer is we can’t because of the AdminSDHolder.

39:26 - AdminSDHolder provides a permission template for the protected accounts and groups.

39:32 - All domain admins have their adminCount attribute set to one, which means they are protected by AdminSDHolder.

39:41 - When a new domain admin is created in the Active Directory, the Exchange task have permissions to move it to the EvilOU.

39:49 - And about 60 minutes later, the permission will be removed because of the AdminSDHolder.

39:57 - So we can’t rely on malicious group policies to Domain Admins.

40:01 - Unfortunately today, the COM objects in Domain Controllers group are not protected by AdminSDHolder.

40:12 - So the attacker can create a new OU, a new GPO, and create a gPLink as before.

40:18 - Next, add a malicious computer immediate task to the EvilComputerGPO.

40:24 - Then move the domain controller to the EvilComputerOU, and just wait for the group policy to refresh on the domain controller.

40:33 - Once group policy is refreshed, a calculator will be executed on domain controller with the SYSTEM account.

40:40 - Now, the attacker can fully control the domain controller and the entire Active Directory.

40:47 - If you are worried about that moving the domain controller to a new OU will affect the functionality of it, you can apply the original OU default domain controller policy to EvilComputerOU.

41:03 - After the attack, the attacker can move the domain controller to its original OU and remove the EvilOU and EvilGPO.

41:12 - Here’s a demo, I will show how the attacker moves laterally to the domain controller and pops calculator with the SYSTEM account.

41:23 - The computer on the left side is the domain controller.

41:30 - Now, there’s no calculator process on the domain controller.

41:40 - Next, we run a while loop to check where the calculator is executed.

41:46 - The computer on the right side is the attacker.

41:54 - Now, the attacker is a member of Domain Users.

41:59 - Attacker can add himself to high-privileged groups if he has compromised Exchange1$.

42:21 - Now, the attacker has been added to these two high-privileged groups.

42:41 - Next, the attacker can create an EvilComputerOU and an EvilComputerGPO.

42:59 - And link the EvilComputerGPO to the EvilComputerOU.

43:14 - Next, add a malicious computer immediate task to the EvilComputerGPO.

43:29 - And move the domain controller to the EvilComputerOU.

43:36 - And just wait for the group policy to refresh on the domain controller.

43:43 - About 30 minutes later, a calculator is executed with the SYSTEM account.

43:53 - After the attack, the attacker can move the domain controller to its original OU and remove the EvilComputerOU and EvilComputerGPO.

44:05 - Here’s the mitigation. You can switch your Exchange Server to Active Directory-related permissions model.

44:11 - This model effectively limits Exchange rights in Active Directory.

44:17 - Attackers cannot use the methods we talked about to perform lateral movement and privilege escalation.

44:25 - Conclusion and takeaways. For red teams in this talk, I disclosed two new Exchange Server vulnerabilities.

44:36 - The first one can result in arbitrary mailbox takeover.

44:39 - Attackers can read mails, download attachments, send emails, et cetera, as any Exchange user.

44:46 - The second one can lead to remote code execution on Exchange Servers.

44:50 - I also introduced a new method to help your lateral movement and help you escalate your privilege to Domain Admins after Exchange RCE.

45:01 - For blue teams, you’ll need to patch all your vulnerable Exchange Servers and the Windows Servers your Exchange Servers are running on.

45:08 - And if possible, switch your Exchange Server to Active Directory split permissions model to prevent attackers from escalating privileges.

45:18 - Restrict NTLM usage as much as possible to prevent some NTLM-related attacks is also useful.

45:27 - Thanks to all these security researchers and their amazing work.

45:30 - Their work inspired me a lot. And also thanks to MSRC for their hard work in fixing these vulnerabilities.

45:42 - Okay, thanks for your listening. .