If you keep up with security news then you have probably heard about atom bombing. Atom bombing is the latest way for attackers to inject malicious code into nearly any Windows operating system and it uses an inherent Windows mechanism known as “atom tables.” The jury is still out on just how dangerous this technique is, but anything that would allow an attacker to run malicious code on your machine should be considered a bad thing.

Atom tables are system-defined tables that store strings and corresponding identifiers. Windows uses these tables for a variety of purposes, everything from Dynamic Data Exchange (DDE) to applications. If you are interested in learning more about atom tables, you can go to https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053(v=vs.85).aspx for more details. 

For the purposes of this blog, I am referring to recent security research by enSilo. They demonstrated that atom bombing allows an attacker to inject code into atom tables. When an application uses the atom tables it pulls out the malicious code and executes it. This creates the possibility that an attacker, at the atom table level, could breach your system and create a persistent presence within your network. The “good” thing here is that the code only executes at the user’s access level and, as of this writing, does not allow for privilege escalation.

Code injection is a well-known attack vector and allows attackers to bypass process level restrictions for a variety of purposes. Code injection allows for man-in-the-middle attacks, accessing encrypted passwords, and a large number of other nefarious actions. You can see that atom bombing opens the door to a severe attack vector within any Windows operating system, at least since Windows 2000.

This attack vector demonstrates several things for the security minded:

  1. This attack takes a legitimate part of the operating system and uses it against the target. Since atom tables are inherent in all Windows operating systems since Win2000 the attack vector is already present. This is one of the best methods of attack. Using a legitimate program, application or operating system to perpetrate the attack is brilliant and difficult to defend against. 
  2. This type of attack creates a broad target surface. Once an intruder has gained access to the Windows system, he can use atom bombing to plant malicious code and create a back door, steal data, or perform other actions that can create headaches for the security team.
  3. Since this is not a “vulnerability” in the strictest of definitions, there is no patch or update that can close the gap. Microsoft may, in the future, use something other than atom tables, but for now every single Windows machine is vulnerable to this attack. 

Now, rather than merely being the bearer of bad news, let us examine what we can do to mitigate this newly discovered attack vector. Here are some steps that you should take to help protect yourself against being atom bombed.

  1. Utilize endpoint protection on all of your systems. This provides you with the ability to immediately take action if an attack is observed. Programs such as Carbon Black (www.carbonblack.com) can give you a huge lead in investigating an attack on Windows systems and beginning mitigation. If your endpoints are unprotected then your data and network are vulnerable not only to atom bombing but also to a variety of other attacks.
  2. Begin network security monitoring. Every security department should already be doing this, however in my professional experience I have learned that most do not. Installing and using network-monitoring tools, such as Packet Sled (packetsled.com), can do much to help you in this area. Packet Sled allows for live monitoring of your network traffic and for historical research as well. Every network should be performing network monitoring of some sort and if you aren’t then you are missing a huge piece of the security puzzle.
  3. Monitor all API calls and inspect any read/write access to the atom tables. There are some tools, both free and paid that can help you with this project. One is found at Runscope. Another that can help with this monitoring is Windows Sys Internals. A third could be APImetrics. It is beyond the scope of this blog post to delve into the world of API monitoring however these links can guide you in the right direction. Since the malicious code is hiding in the atom tables, it is there that you must look if you expect to find it! Any suspicious code or activities by programs should be investigated before an attacker can exploit your network any further.

I would suggest that you check your security team and see if they are talking about this new attack vector. Ask a few subtle questions of your security staff to see if they are keeping up with the latest security news. If they aren’t, they should be. Being informed is half the battle!