Duck and cover or how AtomBombing is really unnecessarily alarmism
The so-called AtomBombing code injection technique discovered by Tal Liberman seemed to be getting a lot of attention recently.
Websites like thehackernews describe the issue as: “no existing anti-malware tools can detect” and “…What’s worse? The company said all versions of Windows operating system, including Microsoft’s newest Windows 10, were affected. And What’s even worse? There is no fix at this moment”.
After reading the blog post and testing the sample provided by the author I've reached the following understanding:
- There is no privilege escalation – You can only access your own processes (in which you can inject shellcode directly anyhow)
- It may be used to hide malicious code in legitimate processes
To test this hypothesis I ran chrome.exe in high integrity level and, as expected, AtomBombing (running in medium integrity level) got ‘access denied’ when it tried to open a chrome process
Given point 2, let’s check if AtomBombing is truly undetectable. I ran the sample on Windows 7 SP1 with the latest version of Sysmon.
As you can see from the screenshot below, event 10 is logged each time a process opens another process memory. Here we can clearly see that AtomBombing.exe opened chrome.exe
When chrome.exe spawned calc.exe we have another event (event id 1). Dropping or starting an executable from a browser is not common, and usually indicative of a potential exploit.
Sysmon was installed with default configuration, and easily detected the code injection method used by AtomBombing.