Email Phishing Engineering · 1: GoPhish’s Ceiling

This article opens the Email Phishing Engineering series. No fluff—straight into engineering practice and real adversary scenarios: why open-source phishing frameworks have hit a ceiling in 2025–2026, and which technical problems a battle-oriented exercise platform must solve.

First published on the WeChat official account: Yofune Security Research. Follow for more.

0x01 A Fact Everyone in the Industry Already Knows#

Start with a reality most people won’t write down publicly: the vast majority of corporate phishing exercises in China are theater. Anzaixinbang’s 2025 China Enterprise Employee Information Security Awareness Survey Report shows that only about 24% of Chinese enterprises have ever run a phishing exercise—and those that do are mostly compliance-driven with shallow participation. Industry outlets such as Security Internal Reference have repeatedly described current training as “formalistic” and “going through the motions.”

The typical flow looks like this: the security team pulls GoPhish from GitHub, spends half a day deploying it on a cloud host, mass-sends a “your password is about to expire” template from the company domain, tallies click rates, and pastes the numbers into a quarterly PPT. Leadership nods, compliance checks the box, exercise over.

The problem is that this kind of exercise sits across a chasm from real attacks.

Data from the 2024 Microsoft Digital Defense Report makes the point clearly: over the past 12 months, AiTM (Adversary-in-the-Middle) phishing attacks grew 146%, and MFA relay has become a standard APT tactic. Proofpoint’s 2024 State of the Phish Report notes that 83% of surveyed organizations suffered at least one successful phishing attack in 2023, with a median direct financial loss from BEC of $50,000. HP Wolf Security’s 2024 report shows QR-code phishing (Quishing) growing more than 270% year over year.

Our exercise tooling is still stuck at “blast one email and see who clicks the link.”

That isn’t an exercise. That’s a lazy questionnaire.

Blue team view: If your organization still exercises with “known templates + known domains + known IPs,” the resulting “click rate” has no reference value—it measures neither employee judgment against real spear-phishing nor the real effectiveness of existing security controls. Real attackers will not send mail with GoPhish’s default X-Gophish-Contact header, and they will not hit your staff directly from Alibaba Cloud.

0x02 Dissecting GoPhish’s Six Fingerprint Classes#

Give GoPhish its due first. When Jordan Wright open-sourced the project in 2016, it filled a real gap—letting non-security practitioners stand up a phishing simulation environment quickly. A single Go binary, embedded SQLite, RESTful API: those engineering choices were right for the time.

But that was a decade ago.

From day one, GoPhish’s architectural positioning was “security awareness training tool.” That positioning difference produced a series of structural problems.

While auditing GoPhish v0.12.1 source, we mapped six fingerprintable trait classes across the HTTP stack. Each is analyzed below with both red-team evasion and blue-team detection angles.

2.1 Custom Header Fingerprints#

This is the best-known issue. GoPhish inserts two custom headers into every outbound message:

X-Gophish-Contact: support@getgophish.com
X-Gophish-Signature:

Red team view: Some community forks (e.g. evilgophish-FORK, lilloX/gophish, and Chinese-community enhanced GoPhish builds) have removed or renamed these custom headers to evade detection. Header-removal methods are documented in multiple open-source bypass guides and patch scripts (e.g. 0xQRx/Gophish_Customization).

Note, however: upstream gophish/gophish latest v0.12.1 still ships both headers, and high-star forks such as kgretzky/gophish do not clearly document removing them—header removal is a targeted change in some forks for detection bypass, not a universal community-fork trait. Even after deleting the headers, the Received chain may still retain Go standard-library SMTP client traits. In mailer/mailer.go, GoPhish sends via the gomail library; its MIME construction and Message-Id @ suffix patterns are also recognizable. A more thorough approach is to use a dedicated MTA (e.g. Postfix) as the send relay so mail-header characteristics are fully determined by the MTA.

Blue team view: Proofpoint, Mimecast, and Microsoft Defender for Office 365 can all be configured with custom mail-flow rules:

condition: header_contains("X-Gophish")
action: quarantine
severity: HIGH

Go further: write rules that check whether Message-Id matches Go gomail’s default format (UUID with no domain suffix, or a suffix inconsistent with the From domain). These rules need no threat-intel subscription—pure rule engines cover them.

2.2 Route Path Fingerprints#

GoPhish’s phishing server registers several fixed paths in controllers/route.go:

• /track — open tracking (tracking pixel)
• /report — report handling
• /robots.txt — fixed content Disallow: /
• static assets under /static/

Red team view: A customized platform must make routes configurable. Path names should be set dynamically via config, and /robots.txt must not leak path information. A more aggressive approach drops a standalone route table entirely and dispatches everything through a wildcard /{path:.*}, with business logic routing by parameters.

Blue team view: At the reverse proxy or WAF layer, match known phishing-framework path patterns:

# Nginx WAF rule example
location ~* ^/(track|report|static/) {
 return 403;
}

ModSecurity REQUEST_FILENAME rules can effectively identify unmodified GoPhish instances.

2.3 Rid Parameter Fingerprints#

GoPhish uses ?rid= as the user-tracking parameter. In source it is the constant RecipientParameter = "rid", with values encoded as base64(sha1(email + salt))—a fixed 7-character alphanumeric string.

Red team view: Parameter names should be configurable (rid, id, token, code, t, etc., rotated), and encoding should be randomized. Values should also be HMAC-bound to the request so the blue team cannot enumerate valid targets by brute-forcing RIDs. Additionally, GoPhish’s Transparency feature (appending + after the RID to return full campaign info) is a major reverse-tracking vulnerability—anyone can reverse-query campaign send time and contact details from the URL.

Blue team view: Search traffic logs for the pattern ?rid=[A-Za-z0-9+/=]{7,}, combined with UA and Referer analysis, to quickly find unauthorized phishing exercises. A more advanced approach extracts RID-like patterns from all URL parameters in SEG logs and runs frequency analysis—abnormally high base64-encoded parameter request rates are often a phishing signal.

2.4 404 Page Fingerprints#

By default GoPhish uses the Go standard library’s http.NotFound, which returns:

404 page not found

The Go standard-library 404 has no “404 Not Found” title tag; the body is plain text, distinctly different from Nginx or Apache HTML 404 pages.

Red team view: You must override the default 404 handler and return a 404 consistent with the target environment. In TaiGong’s implementation, renderUnknownResponse returns a full Nginx-style HTML page:

404 Not Found

404 Not Found
nginx

It also supports configuring UnknownRedirectURL to 302 invalid requests straight to a legitimate page (e.g. Google.com), fully eliminating 404 response differentials.

Blue team view: Use network mapping platforms such as Shodan, Censys, or FOFA to search for HTTP services returning Go standard-library 404 traits; combined with port scanning, this can surface phishing servers exposed on the public internet. The favicon.ico hash is another easily overlooked fingerprint.

2.5 TLS Fingerprints (JA3/JA4)#

This is the most overlooked—and most damaging—fingerprint. ClientHello messages produced by Go’s crypto/tls have a very distinctive CipherSuite order and TLS extension combination. The default JA3 for Go 1.21+ is roughly:

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0

This fingerprint is completely different from Nginx (OpenSSL-based) or Apache TLS fingerprints, and is widely tagged in open JA3 fingerprint libraries (e.g. ja3er.com).

Blue team view: Deploy Zeek or Suricata passive traffic analysis at the enterprise egress; extract JA3/JA4 from all TLS handshakes. If an IP’s JA3 matches Go standard-library traits and that IP is not on a known Go-service allowlist (Docker Hub, Google APIs, etc.), it is highly likely a phishing server. Example:

tshark -r capture.pcap -Y 'tls.handshake.type == 1' \
 -T fields -e tls.handshake.ja3 -e ip.src

Cross-check output against known Go fingerprint libraries for phishing-infra detection that needs no mail content inspection and no URL denylist.

Red team view: There are two paths against JA3. One is to hand TLS to a reverse proxy—Nginx/Caddy/Cloudflare—so the Go app only listens on 127.0.0.1:80 plaintext HTTP; the handshake is completed by OpenSSL/BoringSSL and fingerprints become standard Nginx/Cloudflare ones. The other is to use a custom crypto/tls Config to rewrite CipherSuite order and extensions. TaiGong’s code uses github.com/psanford/tlsfingerprint to extract client JA4 in real time for anti-detection, while server-side TLS fingerprints are handled by fronting Nginx.

2.6 Static Asset Fingerprints#

GoPhish admin static assets (CSS/JS/images) live under static/; file contents are fixed per version. Hash those files and compare against known versions to pin the GoPhish version precisely.

Red team view: Bundle front-end assets into the binary with go:embed, and on each build apply tiny non-functional mutations (e.g. change version strings in CSS comments, alter whitespace in JS) so hashes match no known release.

Blue team view: Extract hashes of JS/CSS under /static/ from HTTP responses and compare against known GoPhish version hash lists (from GitHub Releases or npm packs). This is the most precise GoPhish version identification method.

0x03 Evolution of Secure Email Gateways: From SpamAssassin to a Five-Layer Detection Stack#

To understand why a 2025 exercise platform must match APT-grade adversarial capability, it helps to map how secure email gateways (SEG) evolved over the past six years.

3.1 Traditional Architecture (~2020): One-Dimensional Detection#

Inbound mail → SPF/DKIM/DMARC checks → keyword denylist → SpamAssassin scoring → allow/quarantine

This generation of gateways centered on static rule- and reputation-based detection. SpamAssassin’s Bayesian classifier, Rspamd scoring, RBL/DNSBL denylists—all relatively static tools.

Red team view: With basic hygiene—reputable domains, correct SPF/DKIM/DMARC, avoiding high-frequency denylist keywords in the body—you could bypass them easily.

3.2 Modern Architecture (2024–2026): Five Layers in Depth#

Around 2020–2021, the email security industry underwent a major paradigm shift. Gartner formally defined the ICES (Integrated Cloud Email Security) category in October 2021; Forrester defined CAPES (Cloud API-Enabled Email Security) in Q3 2020—analyst recognition of emerging cloud-native API email security platforms. Traditional SEG vendors such as Proofpoint, Mimecast, and Microsoft never relied on a “single scoring model”—Microsoft Defender for Office 365/EOP shipped a multi-layer protection stack of 20+ detection techniques from the start; Proofpoint TAP included multi-layer URL rewrite, sandboxing, and threat intel as early as 2012; Mimecast expanded detection via Solebit/Ataata acquisitions in 2018. By 2025, a complete email security detection architecture has evolved into a five-layer collaborative system:

Inbound mail
 ├── L1 Reputation: IP/domain reputation, SPF/DKIM/DMARC alignment, sender behavior profiling
 ├── L2 Content: Transformer-based NLP semantic analysis, intent classification, sentiment detection
 ├── L3 URL: Headless Chrome real-time detonation, redirect-chain tracking, domain age checks
 ├── L4 Attachment: CDR (content disarm and reconstruction), Office macro static/dynamic analysis, file-type spoof detection
 └── L5 Behavior: user send/receive baseline modeling, anomalous communication patterns (first contact, burst bulk)

Several critical shifts deserve deeper analysis:

L2 — NLP semantic analysis. Microsoft Defender and Proofpoint have deployed Transformer-based intent classification models. These no longer depend on keyword matching; they understand semantic intent: “Is this message asking the recipient to take an action (click a link, transfer money, download an attachment)?” Traditional keyword swaps (“password” → “passphrase,” “urgent” → “expedited”) are useless against semantic models.

Red team view: Against NLP models you can use noise injection obfuscation (terminology used in KnowBe4’s 2026 reporting) or what Sublime Security (May 2026) calls “indirect prompt injection via hidden text”—embedding large amounts of benign business text in invisible regions of the body to dilute overall NLP probability scores. This is not merely “lowering the urgency score” (that is only one of the model’s signals); it drowns sparse malicious signals in benign context so the classifier labels the whole message as normal business communication. Note that modern SEGs already weight detection of hidden text (opacity:0, display:none, tiny fonts, etc.) in preprocessing.

L3 — URL hyperlink preview. Not simple denylist checks: Headless Chrome actually visits the URL, waits for JavaScript to finish and the page to fully render, then analyzes DOM structure, visual content, and form fields. If your phishing landing page returns a full phishing form to every visitor, it is already sandboxed before it reaches the target inbox.

Red team view: A battle-oriented platform must embed an anti-sandbox engine—multi-dimensional environment checks on the visitor. TaiGong’s detections engine in the JS probe (magic.js) checks:

• navigator.webdriver (Headless Chrome marker)
• navigator.plugins length (sandboxes often disable plugins)
• screen resolution and color depth match (typical virtualized environments are 1024×768)
• chrome.runtime object (loading outside Chrome exposes it)
• mouse trajectories (real user vs script injection)
• Canvas fingerprint and WebGL renderer string

The server further filters by IP: 200+ CIDRs covering AWS/Azure/GCP/Tencent Cloud/Alibaba Cloud/Linode/OVH/Hetzner. Requests outside the geo-fence return 404 or a forged redirect.

L5 — Behavior baseline modeling. First Contact Safety Tip is a built-in Microsoft Defender for Office 365 feature that shows a gray banner atop mail from first-time senders: “You don’t often get email from this sender. Learn why this is important.” It is meant to raise awareness of unfamiliar senders. Certitude Consulting (August 2024) also disclosed a CSS bypass that lets attackers fully hide that banner via carefully crafted HTML. Yellow banners mark spam classification results and are a different control.

Red team view: Breaking L5 requires reply-chain attacks—injecting In-Reply-To, References, Thread-Topic, and Thread-Index headers so the phishing message is inserted into an existing legitimate thread. The SEG’s behavior baseline sees the mail as “belonging” to an existing conversation and does not trigger first-contact detection. TaiGong’s sponsored edition implements this technique.

3.3 The 2025–2026 Attack Surface#

Defenders are upgrading; attackers never stopped.

SMTP Smuggling (CVE-2023-51766). SEC Consult researcher Timo Longin disclosed a protocol-level vulnerability affecting multiple SMTP implementations in late 2023. Attackers exploit differences in how MTAs (Postfix, Sendmail, Exchange Online) parse the SMTP data end sequence . to “smuggle” extra messages in a single SMTP session. Smuggled messages can forge arbitrary senders and fully bypass SPF—from the receiving MTA’s perspective they came from a legitimate source IP. Proofpoint’s 2024 misconfiguration incidents further underscored the impact.

Red team view: Where enterprise MTAs are unpatched, SMTP Smuggling can craft a fake official notice that “passes” SPF/DKIM/DMARC entirely.

SubdoMailing (Guardio Labs, February 2024). In this large-scale campaign, attackers systematically scanned expired subdomain SPF/CNAME records of major organizations (MSN, VMware, McAfee, etc.), took them over, and sent phishing mail under strong domain reputation. Over 8,000 domains and 13,000 subdomains were abused, with average daily volume of ~5 million messages.

Blue team view: Regularly audit DNS for subdomains no longer in use but still listed in SPF includes. Use dnsrecon or Sublist3r to monitor subdomain resolution. CT Log (Certificate Transparency) anomaly monitoring can surface abnormal certificate issuance against your subdomains early.

Quishing (QR Code Phishing). HP Wolf Security 2024 and Abnormal Security both report 270%+ growth in QR-code phishing. The core reason: SEG URL scanners cannot read URLs embedded in images—attackers encode phishing links as QR codes in the body; users scan with phones and land on phishing pages, fully bypassing desktop security controls.

Red team view: Embed QR codes in forged MFA device-binding or attendance check-in notices; exploit mobile URL preview truncation to hide the full link.

Blue team view: Deploy QR detection modules on the mail gateway that decode images in message bodies and analyze extracted URLs. Train employees explicitly: any mail that requires scanning a code to act must be confirmed via a secondary channel.

0x04 Blue Team Detection Matrix: Finding Phishing Infrastructure Inside and Outside the Organization#

From this series’ dual red/blue perspective, the simplest WAF rules are easy to stand up.

4.1 Detecting GoPhish Instances#

From the six fingerprint classes above, you can build a multi-dimensional detection script:

Mail header layer:

# Check X-Gophish custom headers
grep -ri "x-gophish" /var/log/mail/*.log

# Check Message-Id format anomalies
# GoPhish-generated Message-Ids are often UUIDs missing a domain suffix
grep -E 'Message-Id: <[a-f0-9-]{36}>' /var/log/mail/*.log

Network traffic layer:

# Extract JA3 from all TLS handshakes
tshark -r capture.pcap -Y 'tls.handshake.type == 1' \
 -T fields -e tls.handshake.ja3 -e ip.src -e ip.dst | \
 grep "^771,4865-4866-4867-49195"

URL pattern layer:

# Search for RID-like URL parameter patterns
grep -P '\?rid=[A-Za-z0-9+/=]{7,}' /var/log/nginx/access.log

With a WAF (ModSecurity, Naxsi, etc.) you can auto-block requests bearing known phishing-framework traits. Commercial WAFs (Cloudflare, Akamai) typically already include GoPhish fingerprint rules in managed rule sets.

4.2 Detecting Advanced Phishing Platforms#

Once attackers strip all of the above visible traits, the blue team must upgrade:

Domain age and registration data. Newly registered (<30 day) domains sending “internal notice” mail are strong suspicious signals. Automate registration-date checks of linked domains via whois or SecurityTrails API.

CT Log anomaly monitoring. Watch certificate issuance for domains similar to your org name, e.g. hr-yourcompany.com, login-microsoft.com.

Use certspotter or crt.sh APIs for automatic subscription.

Mail authentication consistency checks. Specifically:

• SPF Pass but Return-Path domain misaligned with From (Alignment Failure)
• DKIM Pass but signing domain (d=) misaligned with From
• Domains with DMARC p=quarantine or p=reject receiving mail claiming to be from that domain without a DKIM signature—possible domain impersonation

SMTP behavioral anomaly detection. The same source IP sending to many different internal recipients in a short window, with MAIL FROM envelope address ≠ From header address, is a classic bulk-phishing signal. Zeek’s smtp.log can extract these fields for analysis.

Infrastructure correlation. Correlate domains, IPs, TLS certs, JA3 fingerprints, mail template hashes, etc. used in one campaign into a threat-intel graph—the classic MISP or ThreatConnect use case.

0x05 Engineering Practice From This Understanding: Taigong’s Design Origin#

GoPhish is a good tool—but it belongs to a previous era.

Looking back at the six fingerprint classes: from mail headers to TLS handshakes, from HTTP 404 pages to JS static-asset hashes, any untreated trait can be identified by blue teams or internet mapping platforms. And even if you erase every visible fingerprint, you still face three architectural limits GoPhish cannot solve: single mail channel (no IM/SMS/QR multi-channel simulation), no environment awareness (cannot distinguish sandboxes from real users), and no MFA adversarial capability (no AiTM relay).

In 2026, enterprise SEGs have evolved from single-layer rule engines into five-layer defense-in-depth stacks; NLP semantics, Headless Chrome detonation, and behavior baseline modeling are standard. Real APT groups already use SMTP Smuggling to bypass SPF, SubdoMailing to borrow domain reputation, and QR codes to bypass URL inspection. If your exercise platform is still standing still, the data it produces—“5% of employees clicked the link”—is simply not the real exposure surface.

Based on this understanding, we built a new phishing exercise platform from the ground up—Taigong (太公).

Taigong’s design premise: a platform aimed at real operational environments must simultaneously reach real-attack fidelity across six dimensions—infrastructure stealth, content adversarial techniques, multi-channel delivery, anti-sandbox detection, MFA adversarial capability, and measurement. It is not an “enhanced” or “beautified” GoPhish; it redefines the capability boundary of phishing exercise platforms from the ground up.

Subsequent articles in this series will center on Taigong’s engineering design. By dissecting architectural decisions of a real platform, we show the logic behind every technical choice in modern phishing offense and defense. Pieces of Taigong’s design and implementation will appear throughout, but the core discussion is always adversarial thinking—how to design a platform so exercise data truly reflects an organization’s security waterline.

Next article: concrete implementation—how to build phishing infrastructure that cannot be identified, from domain selection and DNS configuration through CDN domain fronting to TLS fingerprint adversarial techniques, all from production experience in live environments.

References:

-*Microsoft Digital Defense Report 2024, https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024*
-*Proofpoint 2024 State of the Phish Report, https://www.proofpoint.com/us/resources/threat-reports/state-of-phish*
-*HP Wolf Security 2024 Threat Insights Report, https://threatresearch.ext.hp.com/2024-threat-insights-report/*
-*SEC Consult - SMTP Smuggling (CVE-2023-51766), https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/*
-*Guardio Labs - SubdoMailing: Thousands of Hijacked Major Brand Subdomains, https://labs.guard.io/subdomailing-thousands-of-hijacked-major-brand-subdomains-found-bombarding-users-with-millions-of-malicious-emails*
-*GoPhish v0.12.1 Source Code, https://github.com/gophish/gophish*
-*JA3 - A method for profiling SSL/TLS clients, https://github.com/salesforce/ja3*
-*JA4+ Network Fingerprinting Standard, https://github.com/FoxIO-LLC/ja4*
-*Abnormal Security - QR Code Phishing on the Rise, https://abnormalsecurity.com/blog/qr-code-phishing-attacks*
-*Guardio Labs - SubdoMailing Technical Analysis, https://labs.guard.io/*

Series Navigation

• Part 1: GoPhish’s Ceiling ← This article
• Part 2: Untraceable Infrastructure
• Part 3: Bayesian & NLP Content Adversarial Techniques
• Part 4: Parameter Polymorphism & Response Camouflage
• Part 5: Linkless Delivery & QR Codes
• Part 6: BEC 3.0 & Cross-Channel Orchestration