Phishing: Detection and Defeat

Phishing is consistently one of the top initial-access vectors in every annual breach report. Verizon’s DBIR has ranked it in the top three in most years over the last decade (sometimes second to stolen credentials or vulnerability exploitation, occasionally third or fourth depending on how the report categorizes social engineering); CrowdStrike, Mandiant, and Microsoft’s annual reports tell the same story from different angles. Despite years of investment in Secure Email Gateways, awareness training, and endpoint protection, a well-crafted email still lands in the inbox. The reason is structural. Defending email is a problem with no clean solution, because the medium itself is designed to deliver attacker-controlled content to a human reader.

For an operator running a phishing campaign on a Red Team engagement, the challenge isn’t only convincing the user. It’s surviving the gauntlet of automated sandboxes, reputation filters, and link-rewriting scanners that all happen before the user sees anything. The campaign has to look benign to a fleet of machines and convincing to one person.

Infrastructure engineering

#

The success of a campaign is mostly decided before the first email is sent. If your infrastructure looks like an attacker from the network layer up, nothing in the email itself will save it.

Domain reputation and warming

#

Newly registered domains (NRDs) are suspicious by default. Every commercial SEG flags or outright blocks NRDs aggressively for the first 30–90 days. A mature operation keeps a pool of domains registered months or years in advance, sometimes acquiring expired domains that already have web reputation and category assignments.

Email authentication is the floor, not the ceiling:

• SPF, DKIM, DMARC all need to be configured. Without all three, deliverability to Microsoft 365 and Gmail is near-zero. Both providers junk-folder unauthenticated senders by default in 2024 onward (Google’s bulk-sender requirements went live February 2024, Microsoft followed similar enforcement in 2024–2025).
• Domain categorization. The big-vendor categorization databases (Symantec/Broadcom, Trellix, Palo Alto, Fortinet, Cisco Talos, Forcepoint) decide whether your domain reads as “finance,” “business,” “health,” or “uncategorized.” Uncategorized blocks at many enterprises. Paid services age and categorize domains for purchase; check both pricing and burn rates.

Example DNS record:

Type: TXT
Host: @
Value: v=spf1 ip4:198.51.100.10 include:_spf.google.com ~all

The redirector pattern

#

Never expose your backend phishing infrastructure (GoPhish, Evilginx2, Modlishka, modern AiTM kits like Tycoon, EvilProxy, or Storm-1167’s tooling) directly to the internet. Use a redirector tier:

• Tier 1, redirectors. Disposable Nginx or Apache instances on cheap VPSes. They fingerprint clients, drop the obviously-automated ones, and proxy the rest to the backend. When one gets blocked, you spin up another and update DNS.
• Tier 2, backend. The actual phishing engine. Lives behind a firewall, accessible from operator workstations over VPN only.

A minimal Nginx config that drops obviously-bot requests and proxies the rest:

server {
    listen 80;
    server_name login.corporate-update.com;

    access_log /var/log/nginx/phish_access.log;
    error_log  /var/log/nginx/phish_error.log;

    location / {
        # Known scanner/bot User-Agents
        if ($http_user_agent ~* (Googlebot|Bingbot|Slackbot|Twitterbot|Baiduspider|HeadlessChrome|PhantomJS|curl|wget|python-requests)) {
            return 404;
        }

        # Most automated scanners omit Accept-Language; real browsers include it
        if ($http_accept_language = "") {
            return 404;
        }

        proxy_pass http://10.10.10.5:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

User-Agent matching alone is increasingly weak; modern sandbox scanners spoof realistic browser headers. Combine with ASN filtering, geo-blocking, and TLS fingerprinting for an actually effective filter.

Cloaking

#

Cloaking means serving benign content to scanners (sandboxes, SEG click-time analysis, search-engine crawlers) and the actual payload to the intended victim. The decision logic lives on the redirector and decides who gets which response.

IP and ASN filtering

#

If you’re targeting a company in Germany, traffic from a datacenter in Virginia or an ISP in Russia is automatically suspicious. The standard approach:

• Geo-block to the target country. For multinationals, narrow to the offices that match the pretext.
• ASN-block the security-vendor ASNs that scan URLs at click time. The usual suspects: Microsoft (Defender for Office 365), Google, Proofpoint, Mimecast, Trellix, Palo Alto, Zscaler, Cloudflare, Cisco Talos, Forcepoint. Publicly maintained scanner-ASN lists circulate on GitHub; they’re worth a quarterly refresh.
• Residential proxy detection. Harder. Some commercial sandbox services proxy through residential ASNs to evade ASN blocking. JA3/JA4 TLS fingerprinting, HTTP/2 frame ordering heuristics, and Canvas/WebGL fingerprinting catch some of them. None of these is a complete answer.

A note on the lineage of the vendors in that list: Trellix was formed in 2022 from the McAfee Enterprise and FireEye product portfolios; Mandiant (formerly part of FireEye) was separately acquired by Google in 2022 and now lives as Mandiant in Google Cloud Security. So “FireEye” as a brand is gone; the products are split between Trellix and Google.

CAPTCHA walls

#

Most cloud sandboxes (Microsoft Defender for Office 365 Safe Links, Mimecast URL Protect, Proofpoint URL Defense) scan URLs at click time. They run a headless browser, follow the redirect chain, and analyze the landing page. They generally cannot solve a CAPTCHA.

A Cloudflare Turnstile, hCaptcha, or simple proof-of-work gate ahead of the actual phishing page stops the scanner cold:

1. User clicks the link in the email.
2. Redirector serves a “checking your browser…” page with the Turnstile widget.
3. On success, JavaScript redirects to the actual phishing login.
4. The scanner sees only the gate page and either marks the URL as “unknown / benign” or times out.

This is the same technique attackers use against bot defenses, just running in reverse. The cat is now the mouse.

HTML smuggling

#

When a link won’t do, the fallback is an attachment. Attachments are heavily scrutinized; every modern SEG detonates them in a sandbox, scans for known signatures, and inspects the wire data for executable content.

HTML smuggling sidesteps perimeter inspection by assembling the malicious payload on the client side using JavaScript. The file never travels across the wire as an executable; it’s constructed in the victim’s browser memory after the HTML is opened.

Mechanism

#

1. The email contains an HTML file (SecureDoc.html or similar).
2. The HTML embeds a base64-encoded blob of the payload (commonly a ZIP, ISO, IMG, or LNK, since a direct EXE attachment is too obvious).
3. JavaScript decodes the blob, uses the HTML5 Blob API and URL.createObjectURL to assemble it as a file, and triggers a download.

The SEG sees text/html with some JavaScript strings. The binary only “exists” once the browser’s JavaScript engine runs the code, which is well outside the SEG’s inspection point.

<!DOCTYPE html>
<html>
 <body>
  <script>
   // Base64-encoded payload (e.g., a password-protected ZIP containing an LNK)
  const fileData = "UEsDBBQAAAAIA...";
  const fileName = "Quarterly_Report.zip";

  function base64ToBytes(b64) {
    const bin = atob(b64);
    const bytes = new Uint8Array(bin.length);
    for (let i = 0; i < bin.length; i++) bytes[i] = bin.charCodeAt(i);
    return bytes;
  }

  const blob = new Blob([base64ToBytes(fileData)], { type: "application/octet-stream" });
  const a = document.createElement("a");
  a.href = URL.createObjectURL(blob);
  a.download = fileName;
  document.body.appendChild(a);
  a.click();
  document.body.removeChild(a);
  </script>
 </body>
</html>

Microsoft and other vendors have added mitigations: Mark-of-the-Web propagation through smuggled downloads in newer Windows builds, EDR detections on the resulting LNK or ISO execution, smart-screen on the eventual unpacked binary. Modern campaigns layer additional indirection. The HTML drops a password-protected ZIP, the user has to type the password from the email body (which strips Mark-of-the-Web from the extracted contents on older Windows), and the ZIP contains an LNK that pulls the actual payload from a remote URL. Each layer defeats a different defender stage.

Other obfuscation techniques

#

SVG smuggling

#

The same idea as HTML smuggling but inside an SVG image. SVG is XML, and the SVG spec allows <script> tags that execute in the browser when the SVG is rendered as a standalone document (not when used as an <img src>). Real-world variants embed base64 payloads inside the SVG and use the same Blob / URL.createObjectURL chain:

<ns0:svg xmlns:ns0="http://www.w3.org/2000/svg" width="100" height="100">
  <ns0:rect width="100" height="100" fill="#fff" />
  <ns0:script>
    const data = "UEsDBBQAAAAIA...";
    // ... (decode, Blob, URL.createObjectURL, click); same pattern as HTML smuggling
  </ns0:script>
</ns0:svg>

SVG is a useful vehicle because many filters treat it as an image type and apply image-class checks (dimensions, color profile) rather than script-class checks. Several Microsoft 365 phishing campaigns in 2024 leaned heavily on SVG attachments for exactly this reason: the SEG sees an “image,” the user double-clicks, and the browser executes the embedded JavaScript.

Homograph attacks

#

Use characters from non-Latin scripts (Cyrillic, Greek, Armenian) that render identically to Latin letters in most fonts:

• Latin a is U+0061.
• Cyrillic а is U+0430.

In a default browser font, paypal.com (all Latin) and pаypal.com (Cyrillic а) are visually indistinguishable. Browsers since 2017 mitigate the address-bar display via the IDN policy: domains containing mixed-script confusables get rendered as Punycode (xn--pypal-mvf.com) instead of the lookalike form. Chrome 58 shipped this in April 2017 using a whole-script-confusable algorithm. Firefox takes a different approach. It relies on UTS #39 “Highly Restrictive” classification with a TLD whitelist, and users need to toggle network.IDN_show_punycode in about:config for full Punycode display. So the Chrome-style mitigation is not the universal default.

The protection only covers the URL bar. Email body text, link anchors inside HTML emails, and rendered HTML on a phishing landing page are not Punycode-converted, so the visual deception still works in the parts of the message the victim actually reads.

A second variant uses combining marks, zero-width characters (U+200B, U+200C, U+FEFF), or right-to-left override (U+202E) to break exact-match filters while leaving the domain visually identical to the target.

Defender side

#

The arms race has settled into an uneasy rhythm. Defenders keep improving sandbox fidelity, click-time scanning, and ML-based anomaly detection. Attackers keep finding the seams between layers and abusing the parts of the web designed to deliver attacker-controlled code (HTML, JavaScript, SVG, MIME types) to a human reader.

For defenders, the realistic mindset is to plan for the click. Specific things that move the needle:

• FIDO2 / WebAuthn second factors, ideally hardware keys or platform authenticators. AiTM phishing kits (Evilginx, Tycoon, EvilProxy, the Storm-1167 toolkit) can intercept session cookies from password + TOTP or push-based MFA setups. They cannot intercept WebAuthn challenges, because the WebAuthn signature is bound to the legitimate domain origin and the attacker’s proxy domain is not it.
• Conditional access policies with device-compliance, location, and risk-based signals. A stolen credential is far less useful if the IdP requires a managed device from a known geography.
• Strict inbound filtering on attachment types. Block HTML, ISO, IMG, VHD, OneNote, LNK, and password-protected archives from external senders unless there’s an explicit business case. The categories smuggling abuses tend to have low legitimate use volume.
• Rapid response on impossible-travel and AiTM session signals. Most AiTM cookie theft produces a session from an unexpected IP within minutes of the phish; time-to-detect should be measured in minutes, not days. Microsoft’s Risky Sign-Ins and equivalent IdP signals are noisy but useful when tuned.

The objective isn’t preventing every phish, because that game isn’t winnable. It’s preventing a single phish from cascading into a compromised tenant. Limit the blast radius. Shorten the response window.

References

#

• Microsoft on HTML smuggling . Microsoft Security’s overview and detection guidance.
• Mandiant threat intelligence blog (Google Cloud) . Search for “HTML smuggling” for defender-side analyses of APT29 / NOBELIUM and follow-on campaigns using the technique.
• Evilginx2 . Canonical open-source AiTM phishing framework.
• GoPhish . Open-source phishing-campaign manager.
• Cloudflare Turnstile . Bot-detection / CAPTCHA replacement, useful as a cloaking gate in either direction.
• Verizon DBIR . Annual breach data; the source for the “top three initial vectors” claim.
• Yubico on AiTM resistance with WebAuthn . Explains the origin-binding that defeats AiTM session theft.
• Microsoft on Storm-1167 and AiTM phishing . Current-state writeup on a major AiTM operator.