In late October enSilo researchers discovered a new code injection technique that leveraged atom tables – an underlying component of the Windows Operating System.
While code injection isn’t new, utilizing the atom tables in Windows is. The atom tables are a Windows OS feature that allow software programs to store and share data with each other.
Dubbed “AtomBombing”, attackers using this technique could use these atom tables to inject malicious code into legitimate processes, making it more difficult for security software to defend against the threat.
This discovery brought with it a host of questions about the technique, which we attempt to answer here:
Does enSilo detect / block AtomBombing?
Short answer: Yes.
Long answer: While AtomBombing is a unique code injection technique, the end result is still the same: the attacker is still going to try to leverage this new access to steal or encrypt your data. When this injected code tries to reach out to a command and control server or attempts to modify files, enSilo will prevent it.
Preventing the consequences of an attack is the core foundation of the enSilo platform. AtomBombing is just one more technique that shows how futile it is for cybersecurity solutions to focus on solely preventing infiltration.
Shouldn’t Next-Gen Anti-Virus Stop AtomBombing?
Short answer: They should now.
Long answer: AtomBombing utilizes a legitimate Windows component which at time of its release allowed it to bypass most security solutions. Some security vendors have undoubtedly released point fixes to address against this threat.
Has AtomBombing been seen in the wild?
Short answer: Yes. See here for details: Dridex v4 [Updated March 2, 2017]
What about responsible disclosure?
Short answer: What we published was a proof of concept method to demonstrate that this injection technique is feasible.
Long answer: Remember, this is not a new “vulnerability” that can be patched by Microsoft. This is not a “bug” that causes the software to behave badly. This is a legitimate part of the operating system performing as designed. Because there is no vulnerability, there really is no vulnerability disclosure process.
enSilo believes strongly in responsible disclosure, and works closely with vendors when we find vulnerabilities. The industry best practice is to disclose a vulnerability within 90 days of discovery. enSilo goes above and beyond this standard to ensure we don’t release vulnerabilities that can be exploited because a vendor is slow to implement a patch. In our latest Windows vulnerability disclosure, enSilo waited for 6 months (allowing a patch to be successfully released) before providing details.
Attacks leveraging legitimate system operations - we’re going to see more of these aren’t we?
Short answer: You bet.
Long answer: Just like legitimate application developers, malware creators will use the tools they’re given. Malicious use of atom tables is just the latest example of how a normal part of the operating system can be turned against the user by a smart threat-actor. Even if a software vendor can create a reasonable work around to address this “vulnerability by design” they often inadvertently create new problems or introduce new resources that attackers can take advantage of. At the end of the day it seems more prudent to assume that attackers are going to find a way in to your enterprise. Solutions that prevent the consequences of these successful attacks are the only reasonable answer.