ITSEC Newsletter 2024-03-21

I was thinking of a way to obfuscate shellcode that didn’t involve encryption, and didn’t make the payload significantly larger. If I could shuffle all the bytes of a given shellcode payload and keep track of where all the bytes went, I’d have a way to avoid getting detected based on signatured byte sequences. This approach also wouldn’t result in increased entropy. To anyone analyzing the payload, the shellcode would look like a jigsaw puzzle dumped on the table and with no picture on the box as a reference.

Local execution of the shellcode in the original process by jumping to its beginning remains a more stable and OPSEC approach in most scenarios, but it comes with a limitation when doing DLL side-loading, namely the “Loader Lock”. In essence, being inside the loader lock means being significantly restricted as per which functions that can be called in that state. This is because most C2 shellcodes, like Cobalt Strike’s, will attempt to load other DLLs during initialization, which is not permitted nor recommended inside the loader lock. This will result, most of the time, in a blocked process and no shell. So, what are our options?

In the ever-evolving landscape of cybersecurity, evasion techniques play a critical role in circumventing the watchful eyes of antivirus (AV) and endpoint detection and response (EDR) systems. Nowadays it is crucial to have at least a grasp on the malware development world, since without it, you will have huge problems during internal penetration testing (I will not even touch on red teamings here). Currently, with mediocre endpoint protection settings, running useful tools such as Rubeus, Certify or even BloodHound becomes impossible without malware development. Among the arsenal of evasion tactics lies one of my favorite - Direct Pointer execution. This is a subtle yet powerful maneuver that holds the potential to evade even the most vigilant security mechanisms.