Recently, a lot of noisehas been made about “AtomBombing” (available on github) which was communicated as an “unfixable” method to inject memory into a process, and “undetectable” from anti-virus because they only do disk scans and not memory scans. AtomBombing works by doing the following steps:
- Find alertable thread in target process (chrome.exe)
- Find a “code cave” in a RW memory block (.data section of chrome.exe!kernelbase.dll)
- Build a ROP chain to be injected
- Add an Asynchronous Procedure Call (APC) to the alertable thread’s queue.
- Hijack the remote thread to execute the shellcode by executing the ROP chain
AtomBombing in effect on a Windows 10 x86.
This indeed sounds very close to existing techniquesused for injection. But what’s interesting here, is that memory-based attacks are getting more and more coverage from the media as mentioned in a recent blogpost about bodiless malwares from Kaspersky.
Malwares hiding in memory from the Disk.
Memory Forensics using WinDbg
How does it work ?
The whole concept of code injection in a process means that this malicious code will be hidden from the disk but will remain present in memory. Hence, we need to find a way to retrieve this piece of malicious code in memory, in the scenario of the POC of Atom Bombing, we need to retrieve the code cave. The algorithm that retrieve the code cave is the following:
It uses the dead space of the .data section of _kernelbase.dl_l, to hide its ROP chain and its “shellcode” — this address space will be null in most of cases which is what !ms_checkcodecave looks for as an anomaly.
SwishDbgExt is a WinDbg extension that I created 2 years ago, which I decided to update this week end to improve support for Windows 10. This is an open-source WinDbg extension which means commits, new features are welcome.
You can fork it on github: https://github.com/msuiche/SwishDbgExt
And don’t forget our WinDbg Feature contest: https://blog.comae.io/comae-2016-contest-swishdbgext-features-3c9a63c62209#.mzl35spb3