Containerized Payloads

Using Virtualization Based Security against Windows

Weaponizing VBS

“Okay, so let’s move on with our tradecraft development. I’ve already shown you that I can bypass most AMSI and API-based defenses. It doesn’t matter how many times Microsoft tries to patch it; I can simply encode malicious strings as characters pulled from a resource instead of using a suspicious-looking lookup table in non-executable data.

This is the culmination of my fileless framework. I’ve already discussed state machines, so let’s talk about binaries that are way too big to be reflectively loaded through DInvoke. Have you actually tried to inject a Golang binary as a DLL? ‘Hello World’ is at least 20MB. This makes it impractical to convert into shellcode—which causes its own problems because it uses Plan 9 assembly rather than standard assembly.

Ideal payloads to put inside containers

The sheer size of Golang binaries creates serious issues when trying to convert them into Position Independent Code (PIC) for self-injection, as taught in courses like Sektor7 or MalDev Academy. Another option is to manually map the DLL. While you can map a full-size DLL into memory, understanding the PE32 format and the specific bytes that define a DLL—then reliably placing a massive Golang DLL into allocated memory—is a huge undertaking.

But there is another way. We can take a binary like TruffleHog, which is gigantic, compile it, and nest it within a miniaturized Alpine Linux distribution. We can then load that small container onto Windows, Linux, or Mac. By doing this, we abuse hypervisor protections—specifically Hyper-V—to protect the container’s memory space. To AV and EDR, this isn’t an AMSI issue anymore because we aren’t ‘dropping’ malware in the traditional sense. We bring our tools onto the host, mount the host drive, execute malicious commands within Alpine, and run TruffleHog to enumerate the host and exfiltrate credentials. By using Shielded VMs or similar Hyper-V features, we weaponize the Windows environment to protect our malicious binaries—a tactic the Russian SVR has utilized for years.”

Why I speak differently on social media, GuidedHacking Model

“Um, so one of the things I want to point out—and okay, maybe I was going a little bit too fast—is why I’ve been making separate videos to draw people toward my Substack. The videos are more like ‘shitposts’ unless they are directly relevant to the Substack content. My goal is to ensure the Substack remains focused strictly on the technical content, rather than turning into a series of rants.

I use these ‘shitpost’ videos to inspire or encourage people to head over to the Substack, where I can then get much more technical. It’s similar to the Guided Hacking model. They put out free content on YouTube showing how to cheat at video games; then, once you sign up for a free account, you’re introduced to elementary game-cheating concepts. If you decide to pay, you gain access to the higher-tier material. It’s effectively a junior or senior-year computer science course that you would have paid a fortune for in college—but instead, you pay around $65 to become a subject matter expert in cheating and obfuscating paid cheats.”

Where containerized payloads is appropriate and where LotL/LotC is appropriate

“That being said, let’s go back to the Alpine Linux method. The reason I’m telling you this is that we first need to discuss C, C++, Nim, Rust, and other languages that may be higher-level than C, but can still be reliably converted to shellcode.

Tools like sRDI (Simple Reflective DLL Injection) must follow a standard Application Binary Interface (ABI). You definitely need to know why you have to write in C. Even though Sektor7 and MalDev Academy provide source code in C, they often demonstrate dropping binaries to disk as a stepping stone. Once you master reflective loading and fileless malware, anything you do in C or C++ can be reflectively loaded.

However, you then face another mitigation plane: AMSI (Antimalware Scan Interface). Before you even get to the EDR, AMSI is just a different door; it doesn’t necessarily mean that door is less or better defended than standard on-disk tools. It’s not some sort of ‘security apocalypse’ where all mitigations are crushed. Fileless execution adds stealth, but it requires a deep understanding of how that tradecraft works and the specific mitigations you have to bypass, which are often much more difficult to navigate than those for disk-dropped malware.”

Challenges of writing malware in C/C++

“Finally, when you write malware in C or C++, you have to manage your own memory, and you learn a lot in the process. If you’ve never compiled a program in C or C++, you really shouldn’t be talking about making malware. For example, if you haven’t taken a C++ crash course, you probably won’t understand how compilation errors work.

Most of the time, if you wrote bad code that doesn’t compile, or it crashes afterward, the root cause is often the very first error—like a missing bracket or an unenclosed code block—which causes a cascade of subsequent errors. I recommend reading ‘C Programming: A Modern Approach’ by K.N. King and ‘C++ Crash Course’ before you mess with anything like Red Teaming.

Often, you just fix the first couple of errors and the code compiles, but then you deal with crashes. This was evident in the failed ransomware-as-a-service affiliate for Vect 2.0, where the convoluted obfuscation method failed, likely due to poor memory management. If you use VirtualAlloc—and I know we just jumped from a simple concept to a difficult one—you have to understand how it works. If you keep asking Windows to allocate memory, you cannot guarantee that one allocation won’t be overrun by another unless you understand offsets and page boundaries.

You can easily see this in a debugger like x64dbg by creating two memory dumps and checking if the integrity changed. You could dump a section of memory at a specific offset, dump it again later, and check if the hashes match to ensure the memory wasn’t overwritten. You must set specific flags on VirtualAlloc and potentially use randomized base addresses for memory pages. If you know your shellcode or keys are a specific length, you should allocate enough space (or an extra guard page) to ensure it doesn’t overwrite itself, while setting the appropriate memory protection flags.”

Back to containerized payloads

“Now, given all these obstacles, you’ll realize there is another way to protect malware that is dropped to disk, rather than loaded filelessly in memory. Fileless loading doesn’t just face the AMSI hurdle; it often fails to bypass antivirus solutions because the AMSI scan buffer captures the code—whether cleartext or obfuscated—which then gets logged by Event IDs 4103 and 4104 once a DFIR (Digital Forensics and Incident Response) analyst investigates.

However, there is another trick, which is why we’re circling back to Alpine Linux. I’ve already pointed out the use cases for Alpine Linux containers. These containers utilize Virtualization-Based Security (VBS) thanks to Microsoft Hyper-V. You can simply check for the proper conditions, ensure Hyper-V is enabled, and then deploy your payloads hidden within the container.

While there are now detection rules for this after years of research, it remains a viable trick for hiding malicious binaries. It significantly reduces the development overhead of constantly re-obfuscating your binaries. Furthermore, it allows you to execute massive binaries—whether they are malicious or legitimate tools being abused, like TruffleHog. This method isn’t entirely ‘undetectable,’ but it prevents your tools from being flagged instantly by Windows Defender as soon as a signature updates—which happens frequently, sometimes within hours—whereas AMSI signatures often update in less than an hour.”