How to dismantle an atomic bomb

Security researchers at enSilo recently released a novel code injection technique for Windows known as ‘Atom Bombing’. This is so called because it exploits Windows atom tables and Async procedure calls (APC) to evade detection by many common security solutions.

Code injection can be a useful tool for an attacker as it can be used to make a legitimate application run malicious commands. As this technique exploits the design of the OS and not a bug in code it cannot be patched easily making it very desirable to attackers.

When testing the technique on Windows 10 we see that it is possible to inject shellcode into Chrome causing it to launch calc.exe. This shellcode could just as easily provide an attacker with a remote shell to access data and launch further attacks.

Figure 1- Atomic testing

So how does Defendpoint’s proactive approach help with this exploit?

Using multiple layers of security means there are many ways this attack can be contained and stopped. The most obvious one is based on the assumption that “an attacker was able to persuade a user to run a malicious executable, evil.exe”. This is the very reason that application allow listing is recommended as the #1 defence against attacks. From ransomware to atom bombing, if the payload can’t run the attack stops.

In fact, it is trivial for Defendpoint to stop the malicious .exe even with an out of the box allow list policy in place:

Figure 2 - Allow listing blast door

For the sake of argument, let us assume that somehow the payload does run, maybe encoded into a macro script or chained with another application vulnerability. In this case the successful attack will only be able to exploit processes running in the same context as the payload. If we use privilege management to ensure the user is not using a local administrator account, we prevent the ability of the payload to elevate, or access privileged processes.

Even with access only to user mode processes, the attacker could leverage code injection in a trusted app such as Chrome to bypass application level firewalls and allow external access to user data. This is exactly why Defendpoint content isolation launches websites and email attachments in a secure sandbox. Because the Defendpoint sandbox runs under a separate restricted user account the exploit is unable to compromise processes that have access to the user data. This level of isolation provides great protection against threats such as ransomware that target user data, as well as Atom Bombing.

Figure 3 - Content isolation prevents exploit of a user process causing the exploit to error

Although the Atom Bombing approach initially appears very novel, there have been similar techniques used by malware families such as Carberp and Conflicker for several years. More commonly we have seen NtQueueApcThread calling LoadLibraryA to import a malicious dll or pointing to an infinite loop to prevent debugging. Again, by blocking payloads, limiting privilege and isolating content these attacks can be prevented.

As we have seen time and time again, the key to preventing attacks both old and new is to focus on proactively protecting the endpoint, and not rely on detection alone. If you control privileges, control execution and isolate content, you establish a secure foundation to build on. As Atom Bombing is primarily designed to bypass existing security controls, this shows how a proactive endpoint defence can underpin and protect the rest of your security stack.