We are excited about the vast press coverage we have received due to the publication of our latest discovery: A targeted APT attack leveraging Microsoft OWA server. Like any other startup, we greatly appreciate the publicity; but beyond that, we are happy to see this research reach a broader audience because it is an important attack vector that security teams should be aware of. While we wanted to give a brief overview of our research below, if you would like to read a more in-depth discussion about the implications of this type of attack, read Michael Mimoso's post in Threat Post and Graham Cluley's blog post.
Why is this attack important?
This attack was not just a compromise of the corporate email server: it compromised the company's entire Windows domain, giving the attacker the proverbial keys to the kingdom.
How did Cybereason manage to detect this attack?
This attack highlights one of Cybeareason's core capabilities: our unique ability to detect malicious activity using automated behavioral analysis. Through continuous observation of related behavior, Cybereason was able to recognize the malicious DLL file associated with the customers OWA and report on them.
Couldn't a human analyst have discovered this attack just as easily?
The attack was designed specifically to evade anti-virus and human analysis. One of the methods used to throw off casual observers was hiding itself in .NET assembly cache. The .NET assembly cache is a temporary local file mechanism used by the .NET framework and often stores files that are unique to the computer in which they are running. This directory is created dynamically so it would be highly unlikely for any detection software or human analysis to make sense of what they were viewing.
Using our behavioral detection engine, Cybereason noticed:
- The suspicious DLL was unsigned
- The suspicious DLL was loaded from a different directory than normal
- The suspicious DLL was found in the .NET assembly cache but didn't exhibit patterns similar to other files
Could other solutions find it too?
It is highly unlikely that other endpoint detection and response solutions would automatically detect it. Some solutions might have shown, upon an explicit query, that there was a single unsigned DLL file in the OWA process; but then again, such behavior is only anomalous in the right context. Such solutions would offer no other context or understanding of the significance of the situation.
So what are the main concerns?
- The environment was completely compromised (the hackers received the keys to the kingdom)
- The attack employed Anti-detection methods (human analysts blind, AV blind)
- The attack defeated mail encryption systems - (Everything became plain text)
- The attack had a built-in persistence - reboots are futile
- Corporate Microsoft OWA servers are high prevalence in financial institutions
- There are no known defenses - Everybody is vulnerable, and there is nothing to patch: it is not an exploit.
What can you do to protect against this type of attack?
- Consider not exposing OWA to the internet without a VPN connection. And yeah - we know this may be the most useful property of OWA. Use a MFA solution to protect your domain credentials in general and the OWA server in particular against password theft.
- Microsoft should consider turning on mandatory code-signing check on these servers, to prevent unsigned code from launching on OWA (and generally internet-facing servers)
- Adopt a post-breach mindset. Even if the hackers get a hold of all of your passwords, as was the case we described, it is not yet the endgame. There is still time to prevent the hackers from reaching their goal and the real damage can still be prevented.
