AtomBombing – A New Code Injection Attack

Published
November 16, 2016
Type
What's Behind

Introduction

The security research team of "enSilo", a cyber-security company, has revealed (overview, technical analysis) a new code injection attack [1], which affects virtually all versions of Microsoft Windows. Code injection is not a new threat, there are various methods to perform code injection. In this case, potential threat actors can leverage this attack to inject malicious code into legitimate processes, effectively bypassing current security products at the same time. The attack does not exploit a Windows vulnerability or a bug, rather than it manipulates an underlying, benign Windows mechanism. Thus, due to its nature, it cannot be fixed with a patch. This note aims to sketch the technicalities of the attack.

How Does AtomBombing Work?

AtomBombing is named after Atom tables, the Windows mechanism it exploits. An Atom table is used for sharing/exchanging data, i.e. atoms, amongst processes, utilizing shared system memory. Atom tables are useful when processes need to access the same strings. Microsoft defines Atom tables as follows: "An atom table is a system-defined table that stores strings and corresponding identifiers. An application places a string in an atom table and receives a 16-bit integer, called an atom that can be used to access the string. A string that has been placed in an atom table is called an atom name". The idea behind the attack is that someone can use a malicious process to create an atom name by writing malicious code in the form of a string instead of writing a legitimate string, and then get the target process to load the generated atom name and force it to execute the malicious code.

In a nutshell the AtomBombing attack works in three main steps (figure 1):

  • Call the "GlobalAddAtom" [2] function through a malicious process and inject the malicious code in the form of a string into the global Atom table. A global Atom table is accessible by every process in the system.
  • Use an Asynchronous Procedure Call (APC) [3] to call the function "GlobalGetAtomName" [4], in order to get a legitimate target process to copy the malicious code from the global Atom table to the processes' memory space -processes do not sanitize input from the global Atom table. The attack can work against any process that has a thread in alertable state.
  • Force the system to allocate executable memory, i.e. memory where code execution is allowed (by exploiting a Microsoft Windows system-level memory protection weakness), copy the malicious code to the newly allocated memory and execute the malicious code.

Figure 1: The AtomBombing code injection attack

Importance, Possible Uses and Mitigation of the Attack

Despite the facts that the exploitation technique is novel (it leverages Atom tables), there is no patch to fix it, and it is likely to go unnoticed by most contemporary security products, it still requires a malicious application to be executed in the target system first. Therefore, this attack can be used post-infection for injecting code from one process to another, as a new attack vector in the existing attacker's toolbox. A usable Proof-of-Concept code is available for Microsoft Windows 10.

The attack does not lead to privilege escalation, i.e. provide elevated rights to the attacker, but still as noted by "enSilo" it can be used in the following cases:

  • Bypass process level restrictions. Use the attack against a white listed process to bypass a security product, which uses white-listing rules.
  • Access process-specific data. Employ the attack to access data that only certain processes have access to, e.g. take a screenshot of a user's desktop, perform Man-in-the-Browser attacks to modify Web content shown to the user, and access a browser's encrypted passwords.

As previously mentioned, this attack can be used post-infection. This means that following basic security guidelines is critical to avoid malware infection in the first place. Post-infection, protection against this type of attack is limited. Due to the nature of the attack, mitigation measures are limited to monitoring API calls for suspicious or malicious activity and using security products that not only rely on signatures, but on malicious pattern detection and machine learning techniques. The last two techniques require fine tuning to reduce false positives. Notably, machine learning is considered the next step detecting malicious and malfeasance activities.

Conclusion

The lead security researcher behind this attack noted, that he "started poking around to see how hard it would be for a threat actor to find a new method that security vendors are unaware of and bypasses most security products". The findings suggest that determined and resourceful threat actors with plenty of time at their disposal will almost certainly find new techniques to exploit systems to gain an advantage over defenders. Thus, it becomes critical that defenders reassess their defences and redesign their defensive solutions accordingly. They need to also focus on how to limit or prevent the consequences of such attacks after the fact, rather than preventing the attacks per se, which is something that is getting more and more difficult - if not impossible - to do.

 

[1] OWASP defines code injection as follows: "Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application".

[2] "GlobalAddAtom" function as defined by Microsoft: "Adds a character string to the global atom table and returns a unique value (an atom) identifying the string."

[3] APCs are little documented and their inner working is only partially covered. In simplified terms according to "Opening Windows", APCs are: "A Windows functionality that can divert a thread from its regular execution path and direct it to execute some other code. The most important thing about an APC is that when one is scheduled it is targeted to a specific thread".

[4]"GlobalGetAtomName" function as defined by Microsoft: "Retrieves a copy of the character string associated with the specified global atom."

About "What's Behind" from ENISA

With the "What's Behind" series ENISA aims at giving the interested reader some in-depth background about NIS related topics. The background is derived from past experiences and common sense; in no way should "What's Behind" be understood as recommended course of action in a specific incident or investigation, or being a final conclusion. Feel free to get in touch with ENISA to discuss or inquire more information on the "What's Behind" series (cert-relations@enisa.europa.eu).

We use cookies to ensure we give you the best browsing experience on our website. Find out more on how we use cookies and how you can change your settings.

Ok, I understand No, tell me more