From AtomBombing: A Code Injection that Bypasses Current Security Solutions:

What we found is that a threat actor can write malicious code into an atom table and force a legitimate program to retrieve the malicious code from the table. We also found that the legitimate program, now containing the malicious code, can be manipulated to execute that code.

Related slides: http://mista.nu/research/smashing_the_atom.pdf

From AtomBombing: Brand New Code Injection for Windows:

Here’s a new code injection technique, dubbed AtomBombing, which exploits Windows atom tables and Async Procedure Calls (APC). Currently, this technique goes undetected by common security solutions that focus on preventing infiltration

Since the issue cannot be fixed, there is no notion of a patch for this. Thus, the direct mitigation answer would be to tech-dive into the API calls and monitor those for malicious activity.

Q: Would it slow down the machine if the AV would monitor API calls? Is AtomBombing more serious than a DLL Injection? Is it true that it cannot be fixed? Is this something new or just an old thing written in a blog nowadays that was tested in win10 but previously known?

2 Answers 2


It is important to realize a couple things:

  1. Anti-Virus systems are not designed to prevent attacks nearly as much as they are intended to clean up damage after it has been done. In essence they are removing malware that is publicly known.

    It is quite reasonable to write an Anti-Virus system to remove known malware even if it uses the Code Injection technique described in the linked article.

    Sometimes there is malware that has not yet been added to the Anti-Virus program and cannot be cleaned up automatically. So it is always best to Nuke From Oribit if your computer was compromised. (back up important files first)

  2. The 'flaw that cannot be patched', if I'm reading right, is not really a flaw at all, because it is only a logistic issue on what malware can do once it runs.

    By some standards, if malware has run then it's no longer your machine (until you nuke from orbit) because it can already do so much damage, regardless of this 'flaw' in the linked article.

    Running on a non-admin account can be helpful to reduce your risk. Admin accounts have access to the whole computer, while Standard accounts can be easily wiped safely. So if only the Standard account is compromised it is much easier to nuke just that one account.

  3. Because Windows is a classical operating system, access restrictions are user-specific. Any process-level restrictions are usually an afterthought anyway, are less-frequently used, and have limited effect.

    More recent operating systems like Chrome OS, Android, iOS use sandbox techniques and have proper app-specific access control. This way if you run malware it only has the permissions you granted. (note: sometimes the permission is quite inclusive, so be careful what you approve.)

    Unfortunately, with a classical operating system, when you run malware it has access to the whole account. (or whole computer if it is an Admin account)

Is this something new

Nope. "AtomBombing affects all Windows version."

  • 1
    Note: With Windows 8.1 and Windows 10, new-style Windows apps are sandboxed as well. It's unclear to me from reading a few stories about this subject whether "AtomBombing" might theoretically allow a malicious app to break out of that sandboxing (though my initial guess is likely not). But of course, there are still far fewer new, sandboxed apps than traditional Windows desktop programs. It's also unclear to me whether this could be used by a user-land process to effectively seize control of a process running with higher privileges. Nov 2, 2016 at 6:29
  • Neither one of us is 100% informed on this. lol Nov 2, 2016 at 12:37
  • I wonder if this recently discovered flaw would prevent effective sandboxing of the new-style Windows apps. It would stand to reason that Windows would fail to sandbox effectively given this is a new thing for them, and IMHO Microsoft does not have a good track record in OS security barriers. Nov 2, 2016 at 13:23

This is serious because it bypasses process-based access control which most security implementations (including that of the OS) use.

Security products that are specifically coded to protect against the exact method of exploitation in the post can do so (e.g. by hooking ntdll!RtlDispatchAPC syscall and doing some checks on the arguments and stack). However, most of them probably don't have such code before this was disclosed and there may be other syscalls that are equally vulnerable.

The real culprit is the "Atom" APIs which make it much easier to transport long malicious code (shellcode) into the target process than traditional methods. This class of problems cannot be fixed unless this feature is removed/changed in incompatible ways. This is probably why some claim this is "unfixable".

However, changes have been introduced for much bigger "unfixable" issues in Windows before (like the introduction of proper memory protection in NT and UAC in Vista). They may break some software initially, but most will be updated to be compatible eventually.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .