Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

According to Securityweek, the code-injection vulnerability cannot be patched:

The problem for users is that AtomBombing cannot be fixed -- it's the way Windows works. With no chance of a patch, the solution is some other form of mitigation.

  • 1
    as i've said in my answer, for Microsoft the only chance is to remove atom tables feature or adding MANY extra security measures (meaning the same: it's almost impossible for them).
    – KanekiDev
    Nov 4, 2016 at 7:57
  • 3
    FYI: Episode 585 of the Security Now podcast (released yesterday) has this as its theme. Title: "The Windows AtomBomb". Direct download URL (MP3). Nov 9, 2016 at 11:31
  • 2
    I asked a question over at Stack Overflow on what are atom tables used for anyway... see stackoverflow.com/questions/40553686/… .
    – Stone True
    Nov 11, 2016 at 18:06
  • Well... I'd say that if you're somehow tricked into executing malicious.exe, your machine might well not be your machine anymore.
    – fgysin
    Nov 14, 2016 at 8:50

3 Answers 3


As far as I can guess (not completely sure):

Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

First we must consider how Atom Bombing works:

It works by injecting some malicious code in the Windows Atom Tables. Atom tables are a kind of tables where any program can "save" some data strings to use later or to share with any other application.

So it gives any potential attacker the chance to use this method as a hijacking or privilege escalation vector, but not for a direct attack or intrusion.

Why? Well, unless another vulnerability/bug is used, Atom Tables can only be modified locally. That means: Only when you're already in, you can add something to the atom tables to inject malicious code.

So, there are multiple ways to exploit this vulnerability, BUT, when you're already IN (using a malicious.exe , exploiting another vulnerability to get into the system and then using Atombombing for privilege escalation, etc., etc.).

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

The only way for Microsoft team to patch this would be removing the Atom Tables, or adding many extra security measures.

The easiest way to defend against this kind of threat, is just checking any atom data saved before using it (on programs) and/or any security system/program/module taking a look constantly on those Atom Entries.

The way to fix this shall be by using a pìece of software that checks periodically the Atom Table entries, looking for malicious code. That's probably going to be added by some anti-malware (or antivirus) firms.

You can check those articles for more information:

  • How would you go about "checking any atom data saved"? It is just strings of shellcode is it not?
    – Stone True
    Nov 11, 2016 at 18:08
  • Sorry for the late (weekend). I'm going to re-edit my own answer to add further information about the mitigation.
    – KanekiDev
    Nov 14, 2016 at 7:14

The other coments forget something. An attacker can elevate from an unprivileged context (No administrator rights) into a privileged context (admin rights) if it runs into an account which is actually from an administrator. This is called an UAC Bypass.

The Attack

As you may be expecting, this attack involves code injection techniques, such as AtomBombombing (but in fact any other method, even the simple CreateRemoteThread will work).

This is done in 2 steps. The first thing to do is, effectively, inject code into certain processes that run in user mode. There are a few vulnerable processes but I'll be talking about explorer.exe which is also the most stable. This process is not like others, it is special since it has a lot of uses. That's why it has some special privileges. For example, the COM IFileOperation interface can be elevated; This means it will run with some kind of admin-like privileges. This may look useless, since you can only write files with admin rights. But it isn't! Since you can use that to perform another attack; DLL Hijacking. This is step 2. Basically you would place your evil.dll, which may be embebed in the evil.exe, into the same place where autoelevated processes are; Autoelevated programs or processes are programs that once executed will automatically get admin rights. Shortly, this is done by Microsoft since those programs must have those privileges to run correctly and perform things like automated tasks. Finally, we would execute that program, which will load the evil.dll and then auto elevate, therefore granting admin privileges to the attacker code.


Microsoft tried to patch the second step in the past, by whitelisting .dll files and similar techniques, but they failed, since we can easily bypass that just by replacing existing .dll files in some cases.

The first step is not going to be patched at all. Microsoft hasn't patched other injection methods like CreateRemoteThread, why would them patch Atombombing? That would require a huge effort and heavy modification of the OS, which is likely not going to happen. The only way to prevent that would be deleting those special rights from programs like the explorer but it seems like that's not going to happen neither. So basically it depends on AVs to detect if malicious programs will try to inject code using any method.

You can see a POC of the exploit above here

EDIT: I forgot some points of the question. So, this are the technical ways to prevent atombombing from having success: -API hooking: An antivirus solution may intercept and scan all attempts to modify the atom table. The functions GlobalAddAtom() and GlobalGetAtomName() are the ones used to perform this attack. They could intercept the calls and scan the data that is going to be added to the Atom table, searching for key words or more likely, trying to analize the data, if it's a shellcode.


A quick review of this attack clicked these points in my head:

First point

Victim have to run evil.exe to get exploited. Even if attacker somehow persuades victim to run evil.exe, because of the nature of this attack, evil.exe will only be able to inject code in processes running in same security context as evil.exe is running. So, no privilege escalation just by using this attack. (Maybe persuade victim to run evil.exe as Admin? That's not too difficult if victim is already persuaded to run it)

Second point

Code injection is needed because evil.exe could be blocked by Antivirus due to suspicious activity. So, code is injected in legitimate processes. But, browsers and other applications are not in whitelist of antiviruses too. Why would AV trust a browser when #1 source of malicious activity is web? Only whitelisted processes I have seen are svchost.exe and other system processes. Now, the attack requires an alterable thread to inject code into. But getting an alterable thread in system processes (that run in user security context) is difficult. But again, not impossible. And injecting shellcode to normal processes would also work. So this attack is still possible.

Third point

Heart of this attack is ROP chain. Didn't check the details of how ROP chain is implemented but ASLR is enabled on most of the processes now.


Possible mitigation I see is installing EMET. EMET monitors even low level VirtualAlloc functions for possible ROP. Haven't checked it myself but I'm pretty sure EMET will stop the ROP chain of this attack.

  • You second point contradicts your first point. You agree that (even being so difficult) the code injection can force other applications (alterable threads) to attack, so it can be used for privilege escalation.
    – KanekiDev
    Nov 4, 2016 at 9:22
  • @KanekiDev No contradiction. If victim runs evil.exe as normal user, it can't inject its shellcode in elevated processes, processes in only same security context can be affected. My point is that if attacker persuades victim to run evil.exe as Admin then it can inject shellcode in elevated processes. An unelevated evil.exe cannot inject code in elevated process (thus attain privilege escalation). Nov 4, 2016 at 10:08
  • Thus this is not about injecting code directly in process but in the atom table. So it may be possible to inject some code in the atom table to force another process (maybe with elevated privileges) causing the escalation.
    – KanekiDev
    Nov 4, 2016 at 10:10
  • 1
    @KanekiDev The link nowhere says it can elevate privileges. In fact, the mechanism in Stage 1 is applicable only to threads in same security context as evil.exe. Nov 4, 2016 at 11:19
  • 1
    @KanekiDev ... if you can take an elevated process thread. That's the whole point! You can't take elevated thread with unelevated process. Nov 4, 2016 at 11:25

You must log in to answer this question.

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