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).
Step 2: Hunt the Exchange IIS logs
- 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.
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:\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\
- \Windows\Microsoft.NET\Framework64\<version>\Temporary ASP.NET Files\root\<version>\<version>\
You need to cross correlate across multiple sources of evidence and methods, otherwise you will miss things.
- 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.
- C:/Program Files/Microsoft/Exchange Server/V15/Logging/CasSyncLogs/CAS logs
- Logs things relating to use of ActiveSync and OWA
- C:/Program Files/Microsoft/Exchange Server/V15/Logging/Ews/
- C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Ews
- C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Owa
- C:/Program Files/Microsoft/Exchange Server/V15/Logging/HttpProxy/Mapi/