Atom Bombing " An unfixable Bug in windows"

Researchers uncovered new way to leverage mechanisms of the underlying Windows operating system in order to inject malicious code. Threat actors can use this technique, which exists by design of the operating system, to bypass current security solutions that attempt to prevent infection. We named this technique AtomBombing based on the name of the underlying mechanism that this technique exploits.

AtomBombing affects all Windows version. In particular, we tested this against Windows 10.

Unfortunately, this issue cannot be patched since it doesn’t rely on broken or flawed code – rather on how these operating system mechanisms are designed.

Code Injection 101 

The issue revealed presents a way for threat actors to inject code. Attackers use code injection to add malicious code into legitimate processes, making it easier to bypass security products, hide from the user, and extract sensitive information that would otherwise be unattainable.

For example, let’s say an attacker was able to persuade a user to run a malicious executable, evil.exe. Any kind of decent application level firewall installed on the computer would block that executable’s communication. To overcome this issue, evil.exe would have to find a way to manipulate a legitimate program, such as a web browser, so that the legitimate program would carry out communication on behalf of evil.exe.

This manipulation technique is known as code injection.

Code Injection: An Important Tool in the Attacker’s Toolbox

There are quite a few reasons why code injection is useful. An attacker may use code injection, for example, to:

               

               

1. Bypass process level restrictions: Many security products employ a white list of trusted processes. If the attacker is able to inject malicious code into one of those trusted processes, the security product can easily be bypassed.                    
2. Access to context-specific data. Some data is only accessible to certain processes, while inaccessible to others. For example

               

• Taking screenshots. A process that takes a screenshot of the user's screen, must run within the context of the user's desktop. However, more often than     not malware will be loaded into the services desktop, not the user’s, preventing the malware from taking a screenshot of the user's desktop. Using code injection, a malware can inject code     into a process that’s already running in the user's desktop, take a picture and send it back to the malware in the services desktop.        

               

• Performing Man in the Browser (MitB) attacks. By injecting code into a web browser an attacker can modify the content shown to the user. For example, in a banking transaction process, the customer will always be shown the exact payment information as the customer intended via confirmation screens. However, the attacker modifies the data so that the bank receives false transaction information in favor of the attacker, i.e. a different destination account number and possibly amount. In a MitB attack, the customers are unaware of the money being funneled out of their account until it’s too late.        

               

• Accessing encrypted passwords. Google Chrome encrypts the user's stored passwords by using Windows Data Protection API (DPAPI). This API uses data derived from the current user to encrypt/decrypt the data and access the passwords. In this scenario, a malware that is not running in the context of the user will not be able to access the passwords. However, if the malware     injects code into a process that's already running in the context of the current user, the plain-text passwords can be easily  accessed.        
         

Behind the Scenes of AtomBombing

The underlying Windows mechanism which AtomBombing exploits is called atom tables. These tables are provided by the operating system to allow applications to store and access data. These atom tables can also be used to share data between applications.

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.

For more details  https://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/

Code Injections in the Past

Currently there are just a handful of known code injection techniques. A list of several of these can be found here: http://resources.infosecinstitute.com/code-injection-techniques/

Additionally, last summer our research team found a new code injection technique called PowerLoaderEx. PowerLoaderEx enables an attacker to inject code without needing to actually write code or data to the injected process.

Once a code injection technique is well-known, security products focused on preventing attackers from compromising the endpoints (such as anti-virus and host intrusion prevention systems), typically update their signatures accordingly. So once the injection is known, it can be detected and mitigated by the security products.

Being a new code injection technique, AtomBombing bypasses AV, NGAV and other endpoint infiltration prevention solutions.

Mitigation

AtomBombing is performed just by using the underlying Windows mechanisms. There is no need to exploit operating system bugs or vulnerabilities.

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.

It’s important though at this point to take a step back. AtomBombing is one more technique in the attacker’s toolbox. Threat actors will continuously take out a tool – used or new - to ensure that they bypass anti-infiltration technologies (such as AV, NGAV, HIPS, etc).

Obviously we need to find a different way to deal with threat actors. Under the assumption that threat actors will always exploit known and unknown techniques, we need to build our defenses in a way that prevents the consequences of the attack once the threat actor has already compromised the environment.