Intro
Previously, I discussed the initial stager—covering spear-phishing with MSI and LNK files, as well as the nuances of “digging out” misaligned shellcode. Because shellcode is position-independent code (PIC) that resolves itself in memory, its alignment—or lack thereof—doesn’t stop it from executing.
We started with the initial foothold—be it through phishing or a direct exploit—and I’ve refactored that logic into a single proof-of-concept (PoC). But now, we’re moving forward. In this article, we’re diving into Mass Exploitation. (Queue the Command & Conquer vibes—I’ve never actually played it, but the aesthetic fits perfectly.)
To pull this off effectively, we have to account for several factors to ensure the virtual machines (VMs) behind the VPN don’t crash under the weight of the scan.
Python is perfectly fine, but take into consideration resources needed for CIDR block expansion (IPv4 only)
My exploitation script was originally a bit “crude,” but I’ve continuously redesigned it for better modularity. It functions as a Python wrapper around Bash commands. Every time it completes a CIDR block, the script halts, and Python is recompiled into a .pyc file to integrate updated payloads. This is crucial for maintaining a rotating C2—such as a Cloudflare Page—that constantly delivers fresh stagers.
We also have to be pragmatic about CIDR expansion. While it’s seamless for IPv4, expanding IPv6 ranges is often a recipe for a VM crash due to the sheer address space. Besides, the vast majority of the public-facing internet remains IPv4-centric. While the “Big 3” cloud providers utilize IPv6-only gateways, they often struggle with resolving legacy IPv4 addresses. Since most endpoints eventually resolve to both, sticking to IPv4 CIDR ranges is simply more efficient.
Regarding performance, I strongly recommend limiting the script to 5 threads. We’ll also be integrating a customized SharePoint payload. This exploit is readily available on GitHub; it’s a 2 or 3-module gadget chain. All you need to do is compile the C# program in Visual Studio, Base64 encode the output, and drop it into the Python script.
Some might argue for “faster” languages, but writing this in Python is actually trivial and sufficient. Anything faster would likely overwhelm the target server or crash the VM. Modern Python benchmarks are surprisingly impressive—it’s not the Python 2.7 of a decade ago. By wrapping multiple Python scripts around a Bash command, you can rotate your C2s effortlessly. Once a small CIDR block is finished, the script recompiles with the new C2 (pointing to a new Cloudflare, Netlify, or Vercel page) and begins firing the next chain.
So there is apparently a guardrail against exploit development
Bash script orchestrator
First get a file of listed CIDR block ranges, five per block (so
it doesn’t crash)
1.1.1.1/10
2.2.2.2/16
3.3.3.3/22
4.4.4.4/9
5.5.5.5/12
Then your bash script orchestrator
while :; do for i in $(ls *CIDRfiles* | sort -r); do python exploit.py -p payload-final.txt -t 5 $i; done; done
So there is apparently a guardrail against exploit development so I hosted it somewhere else.
The full exploitation script
https://zerobin.net/?3b7169d944554e5a#W8AeyW1eTUdJJlvTmZbl96ep/PHskeqZPod/w4LjUqY=
Let’s go back to the attack chain
Let’s pivot back to my earlier resources. Now that we’ve covered automated exploitation and spear-phishing—using both LNK and MSI files—I want to provide the relevant links for context.
I previously demonstrated how to develop fileless stealers, fileless ransomware, and infinite AMSI bypasses. The “infinite AMSI bypass” is particularly potent when loaded via an exploit, specifically targeting Windows environments. While some of the exploits I’m highlighting are Linux-specific, you can utilize a “wormable” Python or Unix shell script to immediately pivot, locate the nearest Windows machine, and launch a lateral attack.
I also have resources on macOS malware development from my YouTube channel that I’ll dig up for you. Moving forward, I will be highlighting these previous resources as header files or reference text:
I realize some of you might be feeling frustrated. I’m constantly re-linking previous articles and may seem to be “rambling” over the same ground. However, there is a method to the madness: it is essential to isolate each topic—the initial attack chain, the foothold (whether via spear-phishing or direct exploitation), and the supply-chain attacks launched through one-liners.
I’ll also be covering cross-platform style attacks in a linked article below. My goal is to break this down step-by-step. Each phase of the attack is defined by distinct technical hurdles and specific levels of privilege; by separating them, I’m ensuring you understand the transition from a low-privilege entry point to full system or domain control.
Windows and Linux LAN Worms
Using my proof-of-concept tools—including the Rubeus, Mimikatz, and PsExec “worms,” as well as Pass-the-Hash and NTLM-based propagation—you can chain an initial foothold with automated privilege escalation. This allows a stager to “worm” its way from a Linux, UNIX, or FreeBSD entry point into the internal network.
By utilizing a highly compatible shell script, the objective is to locate a Windows machine within the LAN and immediately deploy ransomware or additional lateral movement tools. The goal is to pivot from a public-facing Linux endpoint to the internal Domain Controller, potentially compromising the entire forest. From there, the attack scales using threaded runspace pools to distribute ransomware, credential stealers, and other malware across the domain. This entire chain—from exploit to corporate-wide impact—is made possible by automating privilege escalation through vulnerabilities like Notepad++ 8.8.1 or Velociraptor-based exploits.
