Investigating ProxyLogon Attacks and how to mitigate it

Posted on October 16, 2022 by m365guy One comment

On-Premises Exchange servers are valuable targets for attackers, since it contains critical data and often has wide permissions within AD. Over the years, we have seen different exploits for Microsoft Exchange that could lead to a full compromise on the Exchange farm, as well as a full compromise on Active Directory.

Today I would like to do a recap on the well-known ProxyLogon attack. ProxyLogon is the name that was given for CVE-2021-26855. This is a critical vulnerability on Microsoft Exchange servers that allows an attacker to bypass Exchange authentication by forcing a SSRF request, which allows an attacker to send an arbitrary HTTP request on behalf of the Exchange computer account. This attack can be used against unpatched mail servers running Exchange version 2013, 2016 and 2019. Allowing an attacker to execute commands on an Exchange server by sending commands across port 443.

ProxyLogon is a pre-authenticated vulnerability, which means that an attacker does NOT need to logon or complete any form of authentication to execute code remotely on the targeted Exchange server. In many of the observed ProxyLogon attacks. After the attackers were able to gain unauthenticated access via remote code execution. A Webshell was dropped to establish persistence on the server that provides remote access and code execution capabilities to launch additional attacks.

During this blog post, we will be demonstrating everything that we just discussed. We will also include how to hunt for artifacts based on the available logs that resides on an Exchange server.

ProxyLogon Exploitation – Internal

At this example, we don’t have any special privileges within Active Directory or whatsoever. However, we do have access to an authenticated user.

A simple LDAP query can be run to enumerate all Exchange servers in the domain. Here is one example:

dsquery * "cn=Configuration,dc=contoso,dc=com" -Filter "(objectCategory=msExchExchangeServer)"

At the result, we can see that there is one Exchange server.

Let’s say that we now want to use ProxyLogon vulnerability to target this Exchange server. In order to exploit this, we need to figure out one user in the domain that has a Mailbox attached to it. This is required to ensure that we can exploit this vulnerability successfully.

As we can see in my environment, there are only two accounts with a mailbox attached at the moment.

Ok, let’s go straight to the point now. At this stage, we are trying to exploit this vulnerability. We are executing the following command:

python proxylogon.py exchange2016.contoso.com Usman@contoso.com

At the result, we can’t see that the exploitation attempt failed. It cannot find the LegacyDN. In short, this is an attribute that is part of Exchange which identifies a mailbox by its legacy distinguished name.

Every user that has a mailbox attached to it, will have a value at the LegacyDN attribute in AD. As we can see in this example. The user ‘Colby’ has a mailbox attached to it, so a value has been set at the LegacyDN attribute.

If we now run the following command and use the UPN of ‘Colby’ instead.

python proxylogon.py exchange2016.contoso.com Colby@contoso.com

We can see that the exploitation attempt has now succeeded. If you take a closer look, we are now running as NT AUTHORITY\SYSTEM on the targeted Exchange server.

At this example, we are creating a new local account on the Exchange server and add it to the local Administrators group.

Here we are using nltest.exe to enumerate all the Domain Controllers.

We can use CertUtil for example to download tools and scripts on disk. At this example, we decided to download SharpHound.exe and stage it in the C:\Windows\Tasks folder.

To finalize it, we are now executing SharpHound through our Webshell via the ProxyLogon vulnerability.

As we can see in the C:\Temp folder. The output of SharpHound has been written to disk.

From ProxyLogon to exploiting Exchange Windows Permissions => Domain Admin

As discussed previously, the user ‘Jones’ is just a regular Domain User. During this example, we will be using public tools such as Mimikatz and PowerView to demonstrate how an attacker could elevate to Domain Admin or equivalent. In this blog post, we have discussed that older Exchange CU versions are having dangerous permissions on the Domain Naming Context. See: https://m365internals.com/2022/10/14/history-of-exchange-with-having-wide-permissions-in-ad/

This lab is an Exchange 2016 CU10, so it has Exchange Windows Permissions with WriteDACL on the Domain Naming Context. We will demonstrate how we can chain ProxyLogon with the dangerous Exchange Windows Permissions AD ACL to obtain DCSync rights.

All the steps that are taken in this example is purely for demonstration purposes.

Here we are enumerating all the processes that are currently running on the Exchange server. Our plan is to get the PID of the LSASS process in order to dump it to disk.

At the second phase, we are using rdrleakdiag.exe to dump the LSASS process memory. We can see the .dmp file has been written to disk and staged in the C:\Windows\Tasks folder.

Here we decided to add the user ‘Jones’ to the local Administrators group on the targeted Exchange server.

The user ‘Jones’ can now copy the LSASS dump over to the attacker’s machine.

We will be using Mimikatz to read the content inside the LSASS dump file to obtain the password hashes. We can get the plain-text password of the Exchange computer account.

We can now run under the context of the EXCHANGE2016$ computer account.

After running successfully under the context of the EXCHANGE2016$ computer account. We can now use something like PowerView to assign our user ‘Jones’ DCSync permissions.

The reason that we can use the EXCHANGE2016$ computer account to assign DCSync permissions is, because this account is a member of the Exchange Trusted Subsystem group and is nested in the Exchange Windows Permissions group. As we may know, this group has the rights to modify the permissions on the Domain Naming Context, depending on the Exchange CU version. At this example, we were using an old Exchange CU version.

Last step is to verify whether we have DCSync permissions or not, and as result. We can see the user ‘Jones’ who was just a regular user, now having DCSync permissions.

ProxyLogon Exploitation – Public facing OWA

There are organizations that have OWA exposed to the internet for various reasons. Public facing assets are in general a huge security risk. In this example, we will be using the ProxyLogon vulnerability to exploit a public facing Exchange server.

In order for this to work, we need to have a valid e-mail address of a user, and of course an unpatched Exchange server.

Here we can see our Webshell lingering around on a public facing server. An attacker could scan the internet and do some reconnaissance and use this exposed server to gain initial access to the network.

Hunting ProxyLogon Activities

We have learnt about the impact of ProxyLogon, so it’s time to start hunting for this activity based on the available logs.

IIS logs

IIS logs does a good job to in gathering all the GET/POST requests that are being made, so this would be a good data source to take a look at. From all the public available ProxyLogon POCs that I’ve found on the internet. All of them are dropping a Webshell on disk. IIS logs are stored at the following location: C:\inetpub\logs\LogFiles

The structure of the IIS logs looks like the following:

Here is a snippet of a request that was made through the Webshell generated by the ProxyLogon attack.

Snippets of requests that are being made by ProxyLogon as a reference.

2022-10-16 12:16:13 10.0.0.5 POST /aspnet_client/shell.aspx - 443 - 20.232.131.2 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/88.0.4324.190+Safari/537.36 - 200 0 0 37

2022-10-16 12:06:56 10.0.0.5 POST /aspnet_client/evilc0rp.aspx - 443 - 10.0.0.6 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/88.0.4324.190+Safari/537.36 - 200 0 0 33

2022-10-16 08:33:29 10.0.0.5 GET /aspnet_client/shell.aspx - 443 - 10.0.0.6 python-requests/2.28.1 - 200 0 0 2493

MSExchange CmdletLogs

MSExchange Cmdlet logs may provide some good insights as well. If we see the Set-OabVirtualDirectory cmdlet specified with a strange URL at the -ExternalUrl parameter. It can be a good indicator to work off on.

Microsoft Safety Scanner

After obtaining all the files of interest on the Exchange server for further analysis. It is recommended to run the Microsoft Safety Scanner. This is a free tool that will scan for suspicious files of interest and automatically cleans it up.

How to prevent ProxyLogon?

The first general recommendation would be to reduce the attack surface by not exposing OWA to the internet if applicable. However, Microsoft has done a great job to release security patches for the following Exchange versions:

Exchange 2019:

Exchange 2016:

Exchange 2013:

It is recommended to install the security patch KB5000871 if you have not done this yet. If you are using an Exchange CU version that is not in the list. The recommendation is to upgrade to the latest CU level and then install the patch.

Install the security patch

In order to patch our Exchange server, we need to understand what kind of CU version we’re using. This PowerShell script can gather the CU version.

Run this script on your Exchange servers:

function Get-ExchangeCU() {
    Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" | ? DisplayName -Match "Microsoft Exchange Server \d{4}" | Select -ExpandProperty DisplayName
}
Get-ExchangeCU

At the result, we can see that we’re using Exchange 2016 CU10.

There is a security patch available for this version and can be found here: https://www.microsoft.com/en-us/download/details.aspx?id=102891

Open CMD as an administrator and run the following command:

This will display all the command-line options and also includes installing it in silence mode.

Exchange2016-KB5000871-x64-en.msp /?

At this example, we will be using the option that requires user interaction.

Here we can see that the patch has been installed. If the server doesn’t reboot automatically for some reason. Make sure to reboot the server, so we can ensure that the patch is applied as well.

Open PowerShell and run the following command:

Get-Command Exsetup.exe | ForEach {$_.FileVersionInfo}

At the result, we can get the following result. Pay a close attention to the ProductVersion and then compare it to the version that we can see in the download link.