Hunting for APT Abuse of Exchange


APT abuse of Exchange is not a new topic, but I noticed there weren’t enough write-ups of hunting methodologies, so I decided to write one based on the various attack techniques I’ve seen various APTs use over the last 2 years. This is not a comprehensive guide as there honestly is WAY too much for me to write and cover (I don’t have enough time T_T but will add to this post over time). I’m going to show you specifically some key areas you can focus on when hunting for malicious behaviour. This guide will not cover the entire attack map of what happens in an APT case where Exchange is abused, it will only cover key areas to hunt on Exchange.   

Over the course of the last few years there has been a heavy abuse of legacy authentication from APT groups from various nations, with a strong focus especially on EWS and other legacy auth methods as their preferred method of access. If there is a business need for legacy authentication… (aka you still have legacy authentication enabled) then make sure you are checking for these things and setting file monitoring on certain locations for malicious webshells / OWA DLL backdoors being uploaded.  

Step 1: MS Exchange Management.evtx

If you aren’t aware – this event log is a goldmine for hunting EWS activity. This event log will log the cmdlets run by threat actors when abusing EWS. As you can see from the screenshot below, this APT proceeded to run export requests. They ran several cmdlets (some of which were to remove export requests and other interesting things).

I recommend that you check for these cmdlets:
  • New-MailboxExportRequest
  • Remove-MailboxExportRequest
  • Search-Mailbox
  • Set-Mailbox
  • New-ManagementRoleAssignment
  • New-ExchangeCertificate
  • Get-MailboxRegionalConfiguration
  • Get-Mailbox
  • Get-ExchangeServer
  • Get-InboxRule
  • Get-MailboxPermission

Step 2: Hunt the Exchange IIS logs
These logs are stored in C:\inetpub\logs\LogFiles\W3SVC1 and should always be reviewed when dealing with a potential compromise. To make your life easier, please ensure you have XFF set up and the appropriate level of logging enabled (as pictured below)… the IR consultant working the case will be super happy if you have these set up with all the fields ticked :)

Specifically, when it comes to APT groups I would hunt for the following things in the following ways:
  • Exploitation of unpatched vulnerability. 

  • Active use of webshells / OWA backdoors that they drop (this is as simple as going through the logs looking for requests through the backdoors or webshells). I am not going to provide an example here, but I would look for ASPX files in typical webshell locations. Or, if you’ve already identified the webshells / DLL files then that makes the hunt much easier.

  • Active signs of exfiltration (especially after you have reviewed the EWS logs for signs of abuse). I would hunt through logs looking for signs of 7Z, TAR, RAR, PST, OST, CAB, ZIP. I have seen all of these been used by threat actors in the past for exfil in truncated chunks. I shouldn’t need to stress the importance of this step.
To ram in my point, here’s a screenshot of an APT group performing exfil. It won’t always be as obvious as these stupid file names, but you get the point :P. The important thing to note here is APTs will often use VARIOUS file extensions. For example, I have had cases where they have exfiltrated multiple files with 5 different extensions at different times. So please be thorough when you are performing this investigation. 

Step 3. Hunt for webshells and OWA DLLs 
Not every case you work will be as simple as China Chopper webshell or a glaringly obvious ASPX file. You can have webshells uploaded in various mechanisms. Threat actors can abuse a RCE vulnerability and drop a webshell onto the host or abuse cmdlets that result in webshells being uploaded that aren't just "upload-file" mechanisms.

In an Exchange server environment, the webshells will usually eventuate in one of the following locations. In many cases I have seen this in multiple of these locations:
  • C:\inetpub\wwwroot\aspnet_client\
  • C:\inetpub\wwwroot\aspnet_client\system_web\
  • C:\inetpub\wwwroot\aspnet_client\system_web\<versionnumber>\
  • C:\Program Files\Microsoft\Exchange Server\<vers>\ClientAccess\owa\bin\
  • C:\Program Files\Microsoft\Exchange Server\<vers>\ClientAccess\owa\auth\
  • C:\Program Files\Microsoft\Exchange Server\<vers>\FrontEnd\HttpProxy\owa\
  • C:\Program Files\Microsoft\Exchange Server\<vers>\FrontEnd\HttpProxy\owa\bin\
  • C:\Program Files\Microsoft\Exchange Server\<vers>\FrontEnd\HttpProxy\owa\auth\
You should also check the .NET temporary folders. You will see .compiled files and evidence of the existence of webshells. These files are not webshells, but some may be referencing webshells that existed. The .compiled format contains information for ASP.Net relating to the files they reference. You can see them here: 
  • \Windows\Microsoft.NET\Framework64\<version>\Temporary ASP.NET Files\root\<version>\<version>\
The reason this is important is often webshells may be removed/deleted by the TA and they *sometimes* leave evidence here. You can also corroborate this with $J, file access artefacts and Exchange logs (if these aren't deleted). 

There are various webshell extensions you need to think about. When you are running an IR on an Exchange compromise, the number 1 step I do is to parse the MFT for file creations around the attack date. This generally results in identification of webshells almost instantly. There are other steps I will take i.e. running Yara rules over the disk etc, and correlating evidence across logs etc. But do not just solely rely on Yara rules and do not solely rely on checking folder locations as you might miss things. Harlan calls this an “artifact constellation” ;)

You need to cross correlate across multiple sources of evidence and methods, otherwise you will miss things. 

Here are some typical webshell extensions to hunt for:
  • ASPX
  • REQ
  • DLL - The malicious DLL file is a compiled OWA backdoor binary and can also be present in those same locations. TAs will choose something that sounds like Microsoft made it up.
Also, check for injected code in an existing ASPX file I have noted this as a key technique leveraged by Chinese APT groups. In these instances, “file access” type artefacts will help you pinpoint this occurrence, along with Yara rules. 

Step 4: Modified OWA config files
Make sure you are checking for file access artefacts as sometimes APTs will perform config modification. By config I am referring to the file stored here:
  • C:\inetpub\wwwroot\web.config
In terms of modification, they will change the OWA config and add various lines into the configuration file. This may not happen all the time, so when you notice something malicious occurring in the environment, make sure you’re checking file access artefacts and then if you see this appear, then you need to review the contents. 

Step 5: Review other critical Exchange Logs
These logs should also be analysed during an Exchange compromise depending on what’s relevant (if these are enabled / authentication methods are enabled) because they contain interesting data pertaining to cmdlet abuse, webshell abuse and commands issued. Check these following locations:

CAS Logs
  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/CasSyncLogs/CAS logs 
  • Logs things relating to use of ActiveSync and OWA

EWS Logs
  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/Ews/
  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Ews

OWA Logs
  • C:/inetpub/logs/LogFiles
  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Owa 

  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Mapi/

  • C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/PowerShell/
  • This one is important as it shows you the various cmdlets they have used

And any other log location containing logs relating to a protocol that the threat actors have abused! 

Step 6: Review deleted files
I have never come across an APT who doesn’t delete files. What this means for an investigator is that the $J is almost a non-skippable place to review. The main reason why I think this artefact should always be checked is because – how are you supposed to get an idea of how thorough your investigation coverage is you have no idea what’s been removed? 

The screenshot below is a snippet of logs that the TA performed removal on one of the key dates of compromise. Over 4k logs and countless files including webshells were removed. So parse the $J!

Happy hunting and I will add to this blog as I find more time. I’ve got 4 other things to add to this blog and will add it when I find some more time <3 



Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?