Payload Placement in PE Files

Written by: Iron Hulk Published: May 1, 2025 Reading time: Iron Hulk
← Back to Blogs

بسم الله الرحمن الرحيم


What is Payload Placement?

When security researchers talk about “payload placement,” they are discussing "where inside the binary itself" a piece of machine code, configuration data, or encrypted shellcode is stashed so that it can be reached at run-time without relying on an external file. In the Windows ecosystem, those storage nooks are the PE sections carved out by the linker. Legitimate software uses them for strings, constants, resources, and executable logic; attackers exploit the very same real estate to hide or at least disguise malicious functionality.

💡 Quick Facts

  • .text: Executable, but visible.
  • .data: Writable, noisy if flipped.
  • .rdata: Quieter flips, better for const.
  • .rsrc: Hidden, parsed at runtime.

.data Section

Writable section often used by malware for storing runtime buffers or decrypted payloads. Requires RWX flip for execution — noisy and risky.

  • Default Memory Protection: RW (Read/Write). Execution blocked if /NXCOMPAT is enabled due to DEP/CFG.
  • Legitimate Purpose: Stores global/static variables that may change during runtime.
  • Executable? No — DEP prevents execution.
  • Why Offenders Use It: Writable by default. Ideal for embedding encrypted payloads, then decrypting and relocating for execution.
  • Trade-offs: RW → RX flips are extremely noisy in EDR telemetry. Encryption can hide static bytes, but behavior detection will still trigger on memory permission changes.
  • Trigger Strategy: Use VirtualProtect or NtProtectVirtualMemory to flip to RWX, or copy to a new VirtualAlloc RWX region and execute.

.rdata Section

Read-only section often used for constants and strings. A quieter zone for payloads with lower detection risk if flipped wisely.

  • Default Memory Protection: R (Read-only). Executing directly from here is blocked.
  • Legitimate Purpose: Used for constants, string literals, RTTI, and v-tables.
  • Can shellcode run directly? No — it's read-only and non-executable by default.
  • Why Attackers Like It: One-time RO → RX or RO → RWX flips are less suspicious in EDR logs compared to modifying RW pages.
  • Trade-offs & Notes: These flips score lower in behavior engines. To land shellcode here, use #pragma const_seg or __declspec(allocate()).
  • Typical Trigger Strategy: Most teams copy the payload to an RWX heap region. A stealthier method is to flip the page to RX just once and jump in.

.text Section

Executable code lives here. It's the engine of your PE, and also a tempting host for shellcode when you want speed and simplicity.

  • Default Memory Protection: RX (Read + Execute).
  • Legitimate Purpose: Contains compiled program instructions — your actual code logic.
  • Shellcode Ready? Yes. It’s already executable — no memory flip needed.
  • Why Offenders Use It: It allows immediate execution without triggering memory protection APIs. But static scanners will inspect this area thoroughly, so packing or encrypting is required.
  • Trade-offs: Direct execution leaves raw opcodes exposed. Unless packed/encrypted, this section is easily flagged by YARA or AV engines.
  • Trigger Strategy: Call a function pointer into payload, overwrite an existing prologue, or redirect execution using a TLS callback or a delay-load thunk.
🛠️ Execution Steps:
  1. Modify memory protections using VirtualProtect (if needed for patching).
  2. Locate the base address and the .text section offset.
  3. Overwrite or inject payload into the section.
  4. Jump to or call the injected code.

.rsrc Section

A favorite for covert payload storage. Though non-executable, its contents are opaque and often ignored by scanners unless explicitly referenced.

  • Default Memory Protection: R (Read-only, non-executable). Loader treats it as passive data.
  • Legitimate Purpose: Stores icons, version info, dialogs, and embedded files.
  • Executable? No. The OS will never execute bytes directly from this section.
  • Why Attackers Use It: The section is opaque to static engines until runtime. Binaries embedded here are later extracted via FindResource, LoadResource, and LockResource.

  • Malware developers choose their payload’s based on strategic trade-offs: stealth vs. simplicity vs. mitigation bypasses like DEP, Control Flow Guard (CFG), or behavior monitoring. Mastery of PE sections is critical because where your code lives dictates how the Windows loader treats it, and how defenders see it.

    • Triggering the Payload

    Page-protection flip

    Win32 API: VirtualProtect, VirtualAlloc, VirtualAllocEx

    Direct syscalls: NtProtectVirtualMemory, NtAllocateVirtualMemory

    Pros: simplest.

    Cons: produces unmistakable RW → RX or RO → RX telemetry.

    Copy-then-Execute

    Allocate new RWX memory, copy the payload, jump. Cleaner, avoids self-modifying code flags.

    Pros: Original image stays untouched; avoids self-modification flags.

    Cons: Still emits the classic “allocate → write → execute” triad.

    Section Merge

    Linker trick: /MERGE: .rdata and .text or /SECTION: .mydat,RWX so the loader already maps the payload pages executable.

    Cons: No runtime VirtualProtect.

    Pros: Suspicious PE characteristics (data section with E flag), flagged by static heuristics.

    Code-cave hijack

    Store the payload in .rdata or .rsrc, then patch an existing function or import-thunk to jump into an RWX copy of that payload. Lets the binary appear normal until first call.

    Choosing the right home for shellcode

    Speed over stealth: Original image stays untouched; avoids self-modification flags.

    For balance: → .rdata (encrypted payload + RO → RX flip).

    For deep static hiding: → .rsrc (encrypted RCDATA, extract and run).

    For easy prototyping: → Embedded resources.

    Why It Matters

    Where you stash your payload inside a PE determines how detectable your implant is. Choose poorly, and static or runtime defenses will catch it. Choose well, and you might just slip under the radar.

    Mastering placement + execution techniques is a core skill for any red teamer, malware analyst, or loader developer.