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:

  1. There is no privilege escalation – You can only access your own processes (in which you can inject shellcode directly anyhow)
  2. 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.


Comments (5)

  1. redteam says:

    and obfuscation wont change that, right?

  2. blueteam says:

    In the introduction you make it sound as if this technique does not work on Windows 10 but you tested on Windows 7. Does it in fact work on Windows 10 as well? Basic injection techniques currently work on Windows 10. Not sure this technique is really “new” per say.

  3. Thomas Mettam says:

    What happens when you combine this with another exploit which does achieve privilege escalation? The point is, I believe, that this method is effectively unfixable due to it requiring a breaking change to the WinAPI. In addition, the result of this exploit is that malware can effectively masquerade as any process, evading software firewalls, including Windows Defender.. and if it’s true that the exploit is not fixable, then that’s permanently.

    1. Moti Bani says:

      Hi Thomas,
      If you obtained a higher level of permissions on a system, you can inject code directly into the threads, no special need to use this specific technique.

      Sysmon (and other solutions like crowdstrike) can detect the code injection operation.

  4. Idan Freiberg says:

    I don’t think Atom bombing is pretended to be able to do any privilege escalation… it’s just a code injection method.
    Regarding detection, I agree, it’s totally not stleath method. Couple of AVs even monitor the NtQueueApcThread call.

Skip to main content