Project MSFDefender

The Threat Research & Intelligence (TRI) team at Bloo conducted a structured evaluation of Windows payloads from the Metasploit Framework. The intent was not exploitation for its own sake, but defensive research to observe how these payloads behave at runtime and to collect high-quality endpoint telemetry that could directly support the  Detection Engineering (DE) team.

To begin, we provisioned two virtual machines: Windows 10 x64 (Victim Machine) & Kali Linux (Attacker Machine)

Figure 1: Virtual Setup

Our initial strategy focused on API-level visibility using Microsoft Detours to capture fine-grained execution details. While this approach provided insight into network-related API calls, it quickly revealed two challenges: limited system-wide visibility and, in some cases, interference with payload execution itself. Recognizing these limitations, we pivoted to a more defender-aligned approach using Sysmon and NXLog. By configuring Sysmon with permissive rules, we were able to capture comprehensive endpoint telemetry, process creation, command-line execution, network activity, image loads, thread injection, registry changes, and file operations, without impacting payload behavior.

Environment Setup & Payload Detonation

In the “Project MSFDefender”, we executed Windows payloads from the Metasploit Framework on a Windows 10 x64 virtual machine, keeping the defender/antivirus status ON.

Figure 2:Project MSFDefender Payloads and their Detonation Success

Figure 3: Victim System Information Figure 4: Victim System Security Status

Sample Execution: 

Executing the EXE generated from the payload “payload/windows/x64/meterpreter_reverse_tcp” on the victim system, keeping the defender/antivirus status ON. The victim system defender blocks the exe execution, and we don’t get a Meterpreter reverse shell.

Figure 5: Generating the EXE Figure 6: EXE execution blocked by the defender

Now that we had Windows Defender/antivirus settings on (fully enabled antivirus), we adopted a raw shellcode payload strategy. Instead of directly generating an EXE file from MSFVENOM or MSFCONSOLE, we exported the raw shellcode, then encrypted the Shellcode using XOR in Python, and then finally generated the payload EXE.This strategy avoids signature-based detections, static scanners in Windows security, bypasses Windows Runtime security, and gets our Windows payloads detonated on our Windows victim system.

Figure 7: Sample Payload Files created and used for a single exploit

Payload creation and detonation

1. Creating the RAW File:

• Generate raw shellcode using msfvenom or msfconsole in the Metasploit Framework & start the listener.

2. Python Encryption & Creating Shell Encryption File

• Encrypt the Shellcode Using XOR in Python. This step hides the shellcode’s signature by using the XOR encryption method. This is one of many options available; we chose this one due to its ease and simplicity. 
• Steps for Python Script to Encrypt Shellcode:
  • Create a .py with the Python script in it
  • Run the .py file using the CMD/terminal. If successful, the .enc file will be created
  • This saves the XOR-encrypted shellcode in .enc. This step alone defeats many static scanners

Note: This option is also available as modules within Metasploit; however, we chose the more scattered approach of doing it ourselves to defeat Defender. For large payloads, using Metasploit modules for encryption may still be effective.

3. Custom Shellcode Loader in C and creating the final payload

• Write a Custom Shellcode Loader in C that:
  • Reads and decrypts the shellcode at runtime
  • Allocates memory with VirtualAlloc
  • Copies the shellcode
  • Executes it in-memory, avoiding detection

4. Payload Exploitation:

Download the exe and enc file together and execute the exe file on the victim system with full defender/antivirus. Ensure both files are in the same folder (as we have not written an alternate path for fetching the .enc file); if the .enc file and .exe file are not in the same directory in the victim system, the following error will be received:”[-] Cannot open payload.enc”.

Figure 8: Sample Payload Detonation

5. Meterpreter Session:

Once we execute the exe on the victim system, if all configurations are correct & the listener was enabled, we get the Meterpreter session on Kali (attacker machine).

Figure 9: Meterpreter Session

6. Post Exploitation Activities

Figure 10: Connecting with the remote session & executing the ‘dir’ command to get a list of active directories on the victim system. Figure 11:Meterpreter Commands executed: ‘sysinfo’, ‘shell’ & ‘sc query windefend’ Figure 12: Meterpreter Command executed: ‘powershell “Get-MpComputerStatus | Format-List’ Figure 13: Terminating the shell and Meterpreter session. Reason: User exit

Module: Script Web Delivery

Script Web Delivery Module quickly fires up a web server that serves a payload. The module will provide a command to be run on the target machine based on the selected target. The provided command will download and execute a payload using either a specified scripting language interpreter or “squiblydoo” via regsvr32.exe for bypassing application whitelisting. The main purpose of this module is to quickly establish a session on a target machine when the attacker has to manually type in the command: e.g., Command Injection, RDP Session, Local Access, or maybe Remote Command Execution. This attack vector does not write to disk, so it is less likely to trigger AV solutions and will allow privilege escalations supplied by Meterpreter.

To use the web_delivery module and execute either a Python, PHP, or PowerShell interpreter, follow these steps to proceed with exploitation:

At this point, a handler is up for that payload, and the module should instruct you to execute a command. Copy the command. Depending on your testing scenario, you can either inject the command into an EXE or run it from the target’s shell and get a session.

Figure 14: Script Web Delivery with its 9 Modules Figure 15: Configured PowerShell “windows/x64/powershell_reverse_tcp” Payload on ‘Script Web Delivery’ PSH Module

Till now, we have discussed the environment setup and payload detonation steps using a raw shellcode file and XOR encryption. The final EXE is delivered to the victim system, which is then detonated to provide either Meterpreter, command shell, or PowerShell-based reverse shell session. Also, we discussed “Script Web Delivery Modules”.

There are a total of 3 ways in which we have detonated the custom Metasploit Windows modules:

1. Only EXE-based: Delivering the final EXE on the victim system and then exploiting it.
2. Only Command-Based: Configuring Script Web Delivery Modules for our selected custom Metasploit Windows modules and only executing the command on the victim system. 
3. Command + EXE Based: Configuring Script Web Delivery Modules for our selected custom Metasploit Windows modules in “payload/windows/x64/exec”. Executing the “Script Web Delivery Module” generated command via the exe generated by the module “payload/windows/x64/exec”.

Let’s explore the “Command only” and “Command + EXE” based approaches [Both using the “Script Web Delivery” Modules.]

1. The command-based approach (which uses only the script web delivery method) does not involve dropping the .exe file on the victim system. We have to run the command generated by the selected “Script Web Delivery” module on the victim system. No raw shellcode or XOR encoding involved here. Running only the command generated by the selected “Script Web Delivery” module on the victim system gets detected by the Windows antivirus system (See Figures 16 & 17 below).

Figure 16: Configured PowerShell “windows/x64/powershell_reverse_tcp” Payload on ‘Script Web Delivery’ Regsrv32 Module. Started the exploit and got the command to run on the victim machine Figure 17: Ran the command on the victim machine directly (without embedding it in an EXE) and got detected by Windows security

1. The Command + EXE-based approach involves configuring the ‘CMD’ parameter of the ‘payload/windows/x64/exec’ Windows module with the command generated by the selected ‘Script Web Delivery’ module. 
   • The primary reason for combining the “Script Web Delivery” Method with the “payload/windows/x64/exec” Windows module is to bypass Defender security in the Windows system.
   • Configuring that command generated by the selected “Script Web Delivery” module in the ‘CMD’ parameter of the “payload/windows/x64/exec” windows module enables us to generate a raw shellcode file, encrypt it with XOR encoding (or other encoding methods such as RC4 for stronger encryption) and finally delivering the EXE to the victim system that uses “Script Web Delivery” modules.
   • Below are the snapshots for the Python module from the script web delivery modules, where the final command from the Python module configuration is configured in the ‘CMD’ parameter of the “payload/windows/x64/exec” module. Then, we repeat the process of creating a Raw shellcode file, encrypting it with XOR encoding, and executing the final EXE on the victim system, which in turn executes the command provided by the Python module from the script web delivery modules. Detonating the Python module from the script web delivery modules this way helps to bypass Windows security and get a successful Meterpreter reverse shell.

Figure 18:Script Web Delivery Python Module configured with “meterpreter/reverse_tcp” payload Figure 19: Configuring the “meterpreter/reverse_tcp” payload and starting the exploit Figure 20: Python command Figure 21: Configuring the Python command in “payload/windows/x64/exec” module, generating the payload raw file (eventually to create final EXE with XOR encoding), and running the exploit Figure 22:Executing the EXE file (which has the Script Web Delivery Python module command) Figure 23:Exploit successful (Command + EXE-based approach)

Observations from Custom Payloads Detonation

We tested five custom payloads from selected Metasploit Windows modules: four payloads executed successfully, and one payload failed to produce the expected behavior. Screenshot here is the same as shown earlier.

Figure 24: Custom Payloads Detonation Data

Key Observations:

• For “Meterpreter and Command shell Modules (Both IPv4 & IPv6 and reverse tcp modules)”
  • They were successfully detonated in a Windows 10 x64 system with full Defender/antivirus security. 
  • Raw shellcode payload strategy (instead of directly generating EXE file from MSFVENOM or MSFCONSOLE), plus encrypting the Shellcode using XOR in Python, and then finally generating the payload EXE worked for Meterpreter and Command shell Modules.

• For “Windows PowerShell Module”
  • Windows Defender actively blocked the Windows PowerShell module. We had detonated the custom Metasploit PowerShell Windows module [payload/windows/x64/powershell_reverse_tcp] using all three methods we used: 
    • Only EXE-based
    • Only Command-based, and 
    • Command + EXE Based (In this method, we used ‘PSH’ and ‘Regsrv32’ modules from script web delivery. Other modules were not compatible with PowerShell-based payloads.)

• For “Script Web Delivery Modules”: [Web Delivery Modules tested for: Python, PSH & Regsrv32]
  • The Web Delivery Modules (PSH & Regsrv32) were actively blocked by Windows Defender when executed directly via command on the victim system.

Figure 25: Configuring the regsrv32 script web delivery module for the windows payload ‘x64/meterpreter_reverse_tcp’ Figure 26: regsrv32 module actively blocked by Windows Defender when executed directly via command on the victim system.

• The Web Delivery Module “Python” was successfully executed on the victim machine via the “Only Command-based” and “Command+EXE” method using the payload “python/meterpreter/reverse_tcp”
• The Web Delivery Modules “Regsrv32 & PSH” were actively blocked by the victim machine’s Windows Defender when configured to execute their commands with the module “payload/windows/x64/exec” generated exe.

Figure 27: regsrv32 module command. Figure 28: Configuring the regsrv32 module command in the CMD parameter of the ‘x64/exec’ Windows module. Figure 29: Ran the final EXE, which contains the regsvr32 module command, blocked by Windows security.

For every custom payload detonation (successful or failed), Sysmon + NXLog recorded: process creation, command line usage, network activity, image loads, registry interactions, thread injections, and file writes & deletions. All telemetry was forwarded to the DE team, who used it to build detection rules, identify behavior signatures, and develop defensive queries. These detections will be covered in the later Part of this article series.

Conclusion

This research enabled the TRI team to:

• Validate the behavior of the Windows payloads
• Understand Defender’s reaction to different execution methods
• Identify payload types that inherently trigger detection
• Improve our internal detection capability
• Provide high-quality telemetry to the DE team

By combining Sysmon’s comprehensive visibility with rigorous payload testing, we built a strong foundation for advanced detection engineering and threat behavior analysis.