Add AtomBombing payload for AV evasion

[cbrnrd]

Has implementing Atom Bombing in Windows payloads and/or making new windows/atombomb/meterpreter/reverse_xxx payloads been considered?

---

Usage References:

http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions https://github.com/BreakingMalwareResearch/atom-bombing https://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/

More info on Windows Atom Tables

https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053(v=vs.85).aspx#_win32_Global_Atom_Table (This one is interesting) http://stackoverflow.com/questions/40553686/so-just-what-are-windows-atom-tables-for https://bsodtutorials.wordpress.com/2015/11/11/understanding-atom-tables/

I hope this can be implemented (and I'd be happy to help with it) 😃

[OJ]

Atom bombing has indeed been considered, at least by me. I'm sure others have considered it too.

Your suggestion of windows/atombomb/meterpreter/... doesn't actually make sense. The aim of the stager is to invoke the staged payload. In this example. The stager is reverse_tcp, and the stage is meterpreter. The stager is what runs when you have code execution already, and it's job is to get and invoke the next stage. That stage executes within the current context, and hence no "code injection" is needed, as you're already running in the target process. So I feel that the notion of a "set of payloads" that utilise atom bombing doesn't fit and is pointless.

Where atom bombing makes more sense is in the context of getting code execution across process boundaries. Atom bombing gives us a way of copying data from one process to another without the classic OpenProcess/WriteProcessMemory pattern. While handy, it comes with caveats, including size of the data that can be copied.

I can see this technique possibly being applied to scenarios such as migration, local priv esc exploitation or other actions that require the ability to get code execution in another process once you're already on the box. That's where I've been spending my spare cycles to see if that would aid us at all.

Migration does have a noticeable fingerprint, so doing something like this would be great so that we have another weapon in the armoury, but I think a bit of engineering will be required in order to cover the edge cases, especially when it comes to migration across architectures, and/or ~shitty~ awesome operating systems like Windows 2003.

[cbrnrd]

Ah okay I see your point. As well as migration and priv esc, could it also be used as a form of persistence (compared to exe dropping)?

[OJ]

Well the proviso there is that you need someone to store the payload. If it's not on disk where does it go?

If you're dropping payloads in the atom table, then you need something to execute it as a backdoor, right? So you need to have something else running or some other way to trigger it. Given you need to invoke a thread or a custom payload to read the atom table to run what it finds, you're back to "we need something else to run it", so it doesn't solve the problem.

Are you able to picture a persistence scenario that this provides? I'm struggling to come up with one :)

Cheers!

[cbrnrd]

In terms of dropping payloads, I was thinking of something like this: https://youtu.be/rRxuh9fp7QI Where we get the browser to send the request back to us instead of the originally dropped exe