How do we mitigate the unpatched vulnerability "AtomBombing" code injection under Windows machines?

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:

• To know more about the attack: http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions
• To know more about the Atom Tables "API": https://msdn.microsoft.com/es-es/library/windows/desktop/ms649053(v=vs.85).aspx

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.

Mitigation

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.