We have received a lot of questions regarding our discovery of a targeted attack using OWA to backdoor an organization. We wanted to take this opportunity to publicly address them.
Is there a backdoor in OWA?
No. We know of no backdoor in OWA. In the case we observed, OWA was backdoored. This means an additional program was loaded into the OWA server and introduced the backdoor functionality. The mechanism in this backdoor, as well as a deeper understanding of why the hackers chose to backdoor OWA instead of another asset was the topic of our research.
Was this a vulnerability in OWA?
As was stated in our research, and repeated in Microsoft's blog, there is no specific vulnerability in MS OWA.
What version of exchange was infected?
The malware was loaded into w3wp.exe, version 7.5.7601.17514, the IIS worker process running on a Windows 2008 R2. The exchange version was 14.03. We should note that this malware doesn’t target a specific version of exchange, but a generic mechanism for loading filters into the IIS front-end.
Interestingly, the OwaAuth.dll itself was stored at c:\windows\microsoft.net\framework64\v2.0.50727\temporary asp.net files\owa\c60e4757\114626a\assembly\dl3\b4b06190\0090faec_b903ce01\owaauth.dll.
So how did the hackers manage to load their code into OWA?
This attack is a textbook example of an APT. The hackers actually managed to get access to several other endpoints. The organization in question kept no data from the date of the actual infection, but most of the initial breaches use targeted phishing emails. Eventually, using lateral movement techniques (the hackers' ability to leverage control of one computer to get access to another computer in the same network) they were able to compromise the machine of an OWA administrator. The hackers used the infamous malware toolkit PlugX to control the machines of various users.
Once the hackers obtained the username and password of an OWA admin, they could use remote-desktop to log in to the OWA server. At this point, the hackers can simply copy their new malware to the appropriate folder and register it.
Can you explain how the malware persists and run on the server?
The hackers registered the malware as an ISAPI filter. ISAPI filters are files loaded by the web-server component of OWA as part of the server's normal operation. These filters are used to introduce new functionality and (somewhat ironically) often add additional security measures. Any ISAPI filter can read and modify any web-originating request that happens on the web server and thus the hackers could read any log-in attempt.
So why OWA?
The mechanisms used to install the backdoor on OWA are not specific to OWA and a variant of which happens in most APTs, so why did the hackers choose to backdoor OWA? From the hacker’s perspective, after weeks of laborious work, they have managed to escalate their initial breach into a compromise of an OWA admin's account. However, while this could allow them to impersonate any user logging into OWA, and read every email of these users, this wasn't the attackers’ ultimate goal. In order to reach their ultimate goal, they would need to compromise more users and machines.
For the hackers, the best way into any asset (be it a database or another server) is to walk in through the front door by using legitimate credentials of highly privileged users. This is why they attacked OWA. Using a single malware on the OWA server, they managed to get the username and password for all users in the environment. From this point onward, the way to any other server is much easier.
But there are other reasons for choosing OWA.
OWA is world accessible. One challenge for hackers is to communicate with the malware they have in the organization. In most cases, due to firewall considerations, the malware has to initiate outbound communication to the hacker's command and control servers, which increases the chance of the hackers being caught.
The fact that OWA is an Internet-facing server also made it ideal for the attackers. It allows anyone on the Internet to initiate communication with it over SSL encrypted channels. This allows the hackers to communicate with their malware with little risk of being caught.
After publishing our research, we were notified that Dell published an interesting research about a likely similar attack.
How was the attack caught?
Our software discovered the malware on the first day of a two-week trial deployment of our solution in a customer environment.
The attack was not detected by the malware protection solution used by this company as it relies on signatures. We were able to find the malware by using a behavioral detection approach: observing the type of code running on the OWA servers, and analyzing its behavior. When we observed the malware it had already been running in the system for several months.
How was the server exposed to the Internet? Was the edge firewall rule configured to only allow https (443) traffic from the Internet to the OWA interface/exchange server or were other protocols also allowed to initiate from the internet?
Only port 443 was accessible to the Internet.
Have you shared any IOC's, Hashes, C2, etc.?
Unfortunately, we cannot share the hash of the malware, as it includes customer-specific indicators. This leads us to believe that the malware authors were recompiling the malware for each targeted environment, making it useless to build an IoC based on the specific hash.
Generally, this also highlights the problems of IoCs. IoCs, whether file hashes, names and paths, signatures, registry keys or IP addresses, are notoriously easy to manipulate. When the hackers recompile or change a single byte, the hash changes, when the hackers rename the file, the path and name can easily be changed. The only way to really stop these attacks is by targeting their behavioral patterns. This is how we caught the attack in the first place.
There are some steps companies can take to quickly see if they have this strand of malware. These indicators are not a fail-safe mechanism, but will definitely help.
- Use a tool such as Microsoft's SysInternals ListDlls to see if the IIS work process (w3wp.exe) process was loading any unsigned binary (Example here in powershell).
- The malware stored the stolen password in a file called C:\log.txt. While it's named "txt" the actual content was encrypted binary payload. The encryption used DES in CBC mode with the key and IV of 12345678.
What are the recommended security measures?
- At the very least, companies should make sure log-ins in their environment require multi-factor authentication.
- Companies should treat their OWA servers as they treat their Active Directory servers. There should be a few administrators using dedicated administration accounts, not their day-to-day accounts to manage the servers.
- Companies should be wary of using their OWA server without requiring a VPN (even though this is usually the biggest advantage of OWA).
