上个月帮一家企业做反钓鱼应急时，看到一封让我后背发凉的邮件：发件人写着IT-Support@他们自己的域名.com，正文是“您的企业邮箱存储空间已满，请在两小时内点击下方链接重新认证，否则将暂停收发邮件”。点进去的页面几乎一比一复刻了公司内部的网页登录界面，中招的员工直到当晚才反应过来——不是大家没警惕，而是发件人、链接域名、页面设计全套都是“自家门牌”。这就是典型的内部域名钓鱼。内部域名正在成为钓鱼攻击的新温床，而引爆这一切的，往往是企业自己的配置疏漏。
这篇文章聊聊我在这类应急和加固项目中看到的真实情况：为什么攻击者偏爱内部域名、哪些配置疏漏最容易出问题、信任危机是怎么被引爆的，以及一套可以直接照着做的自查和加固清单。适合负责企业安全建设、邮件系统管理，或者正在被钓鱼演练困扰的同行参考。
1. 内部域名的信任光环：为什么攻击者专挑“自家门牌”下手
1.1 人脑的信任模型与企业域名的“天然白名单”属性
很多人以为钓鱼攻击拼的是技术，实际上拼的是信任心理学。收件人在判断一封邮件是否可信时，不会去查SPF、DKIM、DMARC记录，而是看两样东西：发件人字符串是不是眼熟，以及页面内容是不是符合预期。
当邮件显示来自no-reply@公司域名.com，员工脑子里就会自动把它归入“内部系统通知”。这与经过完整技术验证后的结果没有任何关系，纯粹是长期工作习惯训练出来的条件反射。攻击者正是看中了这一点：与其伪造一个陌生域名让人起疑，不如直接用目标企业自己的域名。
我在给客户做反钓鱼演练时做过一个对比实验：同一批员工，收到伪装成“系统管理员”的外部邮箱（比如admin@service-notice.net）时点击率是3.8%；收到伪装成内部域名（比如it-support@客户公司域名.com）的邮件时，点击率接近17%。差距超过4倍。这个数据解释了为什么内部域名会被攻击者盯上——它自带一层“天然白名单”属性，员工的警惕性会不自觉地降低好几档。
1.2 从攻击者视角看：枚举内部域名比想象中容易得多
还有一个让安全团队更扎心的事实：攻击者要拿到你的内部域名信息，根本不需要攻破任何系统。整个过程只需要三个公开渠道就能完成。
第一是子域名枚举。通过证书透明度日志查询一个域名，几秒钟就能列出该域名下大量历史证书记录，test.example.com、dev.example.com、staging.example.com、status.example.com、portal.example.com，全都暴露在明面上。这些子域名往往承载着测试环境、管理后台、监控面板等高价值目标。
第二是员工邮箱格式。企业官网的团队介绍页面、招聘信息、社交平台上的员工动态，很容易拼出名.姓@公司域名这类邮箱命名规律。有了这个规律，攻击者就能批量生成看似内部人员的发件人地址。
第三是历史泄露数据。企业员工的邮箱地址在中大型数据泄露事件中反复出现，攻击者拿这些公开数据补齐目标企业的“内部通讯录画像”后，发给不同岗位的钓鱼邮件可以做到高度定制：财务收到“供应商付款账号变更通知”，HR收到“员工薪资调整确认表”，IT收到“服务器维护窗口通知”。
攻击者拿到这些信息后，并不需要黑进企业系统。他们只需要把钓鱼页面做得足够像，然后从“内部域名”这扇最容易获得信任的门走进去。
2. 配置疏漏的三张“病例单”：邮件认证、子域名接管与幽灵DNS
2.1 邮件认证三件套：SPF、DKIM、DMARC最容易犯的错
如果说内部域名是温床，那邮件认证配置疏漏就是床垫下那根最扎人的弹簧。SPF、DKIM、DMARC这三项是邮件身份认证的基石，但我在大量企业网络里见过它们以各种意想不到的方式“带病运行”。
先说SPF（Sender Policy Framework，发件人策略框架）。它的作用是告诉接收方“哪些服务器有权用我的域名发邮件”。配置错误的情况五花八门，最常见的几种：
| 配置项 | 常见错误 | 实际风险 |
|---|---|---|
| SPF | 写成v=spf1 -all却忘了加自家邮件服务器IP段 | 自家员工正常发信也会被拒收，于是运维关掉校验 |
| SPF | include链超过10次DNS查询限制 | 接收方直接返回permerror，等于没配置 |
| SPF | 使用了~all软失败策略 | 多数邮件服务商仍会放行，钓鱼邮件照常投递 |
| DKIM | 私钥轮换后没更新DNS上的公钥 | 签名验签失败，邮件被标记为伪造 |
| DKIM | 只对部分系统邮件签名，业务邮件裸奔 | 攻击者模仿未签名发件人，绕过了认证 |
| DMARC | 策略设为p=none只监控不拒收 | 伪造邮件照常进收件箱，企业却以为已启用防伪保护 |
正常配置的SPF记录长这样：
v=spf1 ip4:203.0.113.5 ip4:198.51.100.25 include:_spf.example.com -all字段拆开看：ip4声明直发服务器地址，include引入第三方邮件服务商的合法发送IP段，末尾的-all表示“其他任何来源都不是我发的”。这个-all很关键，很多人图省事写成~all，软失败在Gmail、Outlook这类主流服务商那里经常会被放行，防御效果大打折扣。
DKIM（DomainKeys Identified Mail，域名密钥识别邮件）相当于给邮件内容盖了个数字印章，接收方在DNS上查公钥来验签。它的配置错误常见于更换邮件网关后没同步更新DNS记录，导致验签失败。验签失败本身不一定让邮件被拒收，但会给DMARC判定提供“伪造”的证据。
DMARC（Domain-based Message Authentication, Reporting, and Conformance，基于域名的消息认证、报告与一致性）是兜底策略。它告诉接收方：如果SPF和DKIM都验不过，这封邮件是按“垃圾邮件”处理（quarantine），还是直接拒收（reject），或者什么都不做（none）。
我遇到过一家企业，DMARC记录查出来是v=DMARC1; p=none; rua=mailto:dmarc@该公司域名.com，管理员一直以为“既然配了DMARC，伪造邮件肯定进不来”。实测结果截然相反，攻击者伪造该公司域名发出的邮件在Gmail和Outlook都能正常进收件箱。原因很简单：p=none模式下接收方只把验证结果发到报告邮箱，并不会拦截任何邮件。
这个案例给我们的教训是：配置不等于生效，DMARC策略必须从none逐步升级到quarantine，最终到reject，并配合报告监控确认没有误伤正常邮件后再收紧。
2.2 子域名接管：钓鱼页面长在企业自己的域名上
比伪造邮件更隐蔽的攻击方式是子域名接管。很多企业的DNS里残留了大量指向第三方服务的CNAME记录——比如曾经的监控看板、在线文档库、营销活动落地页，这些记录指向的都是SaaS服务商的域名。
当某一天企业停用了某个SaaS服务，却没有删除对应的DNS记录，攻击者就可以在那个SaaS平台上注册同名账号，接管这个子域名的内容控制权。这样一来，钓鱼页面就长在了企业自己的域名上。员工和客户看到https://status.企业域名.com时，很难把它与钓鱼联系起来，而且攻击者甚至能申请合法HTTPS证书，浏览器的小绿锁也会出现。
这类接管的典型场景我在项目中见过好几个：
- 测试环境的
test-blog子域指向某博客托管平台，停用后DNS未清理，攻击者注册同名空间并搭建了企业伪造登录页。 - 营销活动专用的短链接子域指向外部落地页服务，活动结束后域名解析还在，攻击者接管后把页面换成仿冒的礼品兑换界面。
- 曾经的远程接入入口子域指向某种网关服务，服务下线后CNAME残留，攻击者接管后收集员工账号密码。
检测思路也不复杂，主动枚举子域名后逐个检测响应特征：如果DNS解析正常但页面返回“无归属”或第三方平台默认页，就存在接管的可能。这个动作看起来简单，但大部分企业根本没有定时执行的资产盘点机制。
2.3 已经被遗忘的“幽灵资产”：域名续费过期引发连锁风险
还有一种疏漏比子域名接管更基础，也更致命：域名本身已被遗忘。企业越做越大，域名会越来越多，主域名之外还有活动域名、子品牌域名、历史项目域名，甚至收购来的公司域名。这些域名一旦续费不及时，被他人抢注，那才是真正的灾难。
域名被抢注后，攻击者能做的事远超想象。最直接的是把这个域名配置上MX记录和企业常用邮箱前缀，假扮企业向员工、客户、供应商群发钓鱼邮件。还可以直接用这个域名搭建与原官网一模一样的站点，用于收集登录凭据。
我处理过一个案例：一家客户的旧域名到期后被抢注，抢注者自动配置了该域名的邮件系统，然后给曾经联系过的供应商群发“付款账户变更通知”。供应商看到发件域名确实属于该公司（虽然是旧域名），还真有人转了账。而这家企业直到供应商电话确认时才发现问题——因为旧域名的续费提醒邮件，发到了那个已经离职三年的行政经理的邮箱里。
3. 信任危机是怎样在企业里被引爆的
3.1 员工侧：一封“内部邮件”的杀伤半径
内部域名钓鱼的杀伤半径最先覆盖的永远是员工。攻击者最常用的三套模板我几乎在每家企业都见过：企业邮箱存储空间超限警告、HR系统密码到期提醒、财务报销系统升级通知。这三封邮件有一个共同点：信息足够像真的、语气足够急促、行动指令足够明确。
为什么这类邮件对员工特别有效？除了发件人域名可信外，还因为它制造的是“需要立刻处理的内部事务”的压迫感。员工在忙于日常工作时，很少会停下来核查邮件的技术细节。一旦第一个员工中招，攻击者拿到企业邮箱账号后，就会用这个真实账号继续向通讯录里的同事发送带有同名钓鱼链接的邮件。这种蠕虫式传播让第二波攻击的点击率往往更高，因为“上钩员工”的账号是真实的，邮件看起来像来自内部同事。
演练和真实攻击最大的区别也在这里。演练时员工知道是测试，会下意识寻找破绽；真实攻击中，员工没有这种“测试心态”，判断标准会急剧下降到“发件人域名对不对、页面logo像不像”这种表面特征。
3.2 客户与合作伙伴侧：品牌信任在外部市场的连锁传导
内部域名钓鱼的第二个受害群体是客户和合作伙伴，传播链路比员工侧更难看透。
对客户的攻击通常以发票欺诈为主。攻击者获取企业开票员邮箱后，向客户发送“本季度发票已更新，请用新账户付款”的邮件，邮件里的付款账户被悄悄替换成攻击者的账号。等到月底对账时，资金早已被多层转走。
对合作伙伴的攻击则更贴合商务邮件诈骗（BEC）的经典手法。攻击者伪装成企业采购负责人，与供应商在邮件里完成几轮正常沟通，然后以“合同流程变更”为由要求更改供应商档案中的收款账号。这个套路杀伤力极大，因为不是一次性的大额转账，而是改变信任关系本身，短时间内不易被察觉。
一旦外部受害方发现“收到来自该公司的邮件竟然不可信”，品牌长期积累的信任资产就会崩塌。客户应对此的常见反应是暂停合作、提高验真门槛、将企业列入高风险管理名单。合规层面的责任追查、保险费用的增加，也都会接踵而至。信任危机发生之后，企业再来补救，成本往往是平时的数倍。
4. 全球攻防战升级：当钓鱼攻击进入“工业化”阶段
4.1 攻击者的武器库：自动化套件、二维码与实时中转
说句实话，过去几年攻击者的钓鱼技术已经进入工业化阶段。批量生成钓鱼页面的工具、模块化的攻击套件、自动记录和打包受害者凭据的后台，都已经高度商品化。购买一套现成的钓鱼基础设施，甚至可以做到几百美元“交钥匙”交付。
更值得警惕的是技巧的迭代升级。二维码钓鱼成了绕过邮件网关链接检测的利器：攻击者把钓鱼链接编码进二维码图片，员工用手机扫码后进入钓鱼页面，避开了桌面端的安全检查链路。还有实时中转攻击，攻击者在中间架设一个转发层，受害者在钓鱼页面输入的账号密码和一次性验证码，会实时转发给真实网站。这样一来，即便企业部署了双因素认证，攻击者也能在验证码有效期内完成登录，窃取会话。
我记得有一个案例，攻击者在钓鱼页面上嵌入了一段脚本，只对特定国家和地区的IP显示钓鱼内容，来自安全公司或威胁情报平台的访问一律显示随机404页面。这给企业的威胁分析和溯源工作带来了极大的困难，很多自动化扫描工具完全无法发现这个钓鱼站点的真实意图。
4.2 防御侧的转型：从邮件网关到全程对抗与协同
面对工业化攻击者，防御侧的做法也必须跟着变。过去很多企业的防御思路是“买一个邮件网关，过滤掉明显的钓鱼邮件”，但在内部域名钓鱼面前，这套逻辑会出现明显缺口：网关能拦掉外部相似域名发来的邮件，却拦不住通过被接管子域名托管、从正规邮件服务商发出的钓鱼邮件。
我在项目中推动的防御体系通常涵盖五个层面：
- 邮件认证强制：SPF用
-all，DKIM覆盖全部外发邮件，DMARC逐步收紧到reject。 - 域名资产持续监控：记录所有域名和子域名的DNS变更、证书变更、页面指纹变化。
- 接管风险扫描：定期检测解析到第三方平台却无人维护的“无主”记录。
- 员工行为防线的持续演练：不只是“每年一次点击PPT培训”，而是高频次、贴近真实场景的模拟钓鱼。
- 威胁情报联动：将外部钓鱼域名、URL、发件人情报接入安全设备，缩短从“攻击发生”到“发现拦截”的时间窗口。
全球范围来看，协同也在加深。安全研究者、域名注册商、邮件服务商、浏览器厂商之间形成了投诉下线的联动机制：发现钓鱼页面后向域名注册商的abuse邮箱投诉并要求冻结域名，向搜索引擎提交恶意站点举报，向浏览器安全浏览机制提交黑名单。这些动作看起来基础，但在实战中能够显著缩短钓鱼站点的存活时间。
4.3 攻防不对称背后的成本账
攻防不对称是内部域名钓鱼难以根治的根本原因。攻击者的成本结构很低：注册一个相似域名大概几十元，部署钓鱼页面几乎零边际成本，批量发送邮件也完全可以自动化。加上人工智能生成钓鱼话术之后，很多钓鱼邮件已经不存在明显语法错误和上下文漏洞，识别难度进一步上升。
而防守方要做的事情太多：邮件认证要配置、资产要扫描、员工要演练、事件要响应、业务要连续、数据要保护。人力、工具、时间每一项都是成本，攻击者只需要成功一次，防守方必须每次都正确。
这种不对称决定了企业不能指望“一次性加固”解决所有问题。防御必须把大量检查动作自动化，才能以较低成本保持长期有效。这也是为什么我在给企业做方案时，始终强调“监控比建设更重要”：配置好一套邮件认证并部署到位，只是起点；维持每一条记录的持续正确，才是真正的战场。
5. 把“温床”拆掉：一套可以直接落地的自查与加固清单
5.1 邮件认证配置核查：三分钟检查SPF/DKIM/DMARC
不管企业规模多大，先花三分钟跑一遍下面三条命令，就能知道自己在这三项上处于什么水平。
dig TXT example.com dig TXT default._domainkey.example.com dig TXT _dmarc.example.com把example.com换成自己企业的域名，分别查看返回结果：
| 检查项 | 期望结果 | 需要警惕的返回值 |
|---|---|---|
| SPF | 以-all结尾，包含全部合法发送源 | 查询超限、有~all、包含已失效的IP段 |
| DKIM | 返回以v=DKIM1开头的公钥文本 | 空结果、选择器错误、公钥内容明显被截断 |
| DMARC | 策略为quarantine或reject，报告邮箱有效 | p=none、报告邮箱不可送达、记录格式错误 |
检查出问题后建议按以下顺序修复：先修正SPF，确保合法的邮件服务器都在允许列表内，且把~all改成-all；再检查DKIM的DNS记录与企业当前邮件网关使用的选择器是否匹配；最后根据前两项验证结果逐步收紧DMARC策略。一个稳妥的操作路径是：第一周设p=none收集所有验证数据，第二周改为p=quarantine观察误伤情况，第三周如无异常调整为p=reject。
5.2 子域名与资产盘点：找出藏在暗处的接管风险
子域名接管的风险不在“看得见的页面”，而在“没人维护的解析记录”。建议每个季度做一次完整的资产盘点，核心动作如下。
第一，枚举子域名。通过证书透明度日志可以收集到企业域名下曾经出现的所有证书记录，这些记录直接暴露了子域名的名称，导出后去重整理成候选清单。
第二，比对DNS解析。对每一个子域名做解析查询，记录它解析到的IP或CNAME目标，标出那些指向第三方云服务、CDN、托管平台的记录。
第三，识别无主内容。访问这些子域名的HTTP/HTTPS服务，检查页面响应特征。如果出现“默认页面”“无归属”“该站点不存在”之类的特征，就说明该记录可能已经被废弃，存在接管风险。
第四，建立监控机制。把上述扫描动作脚本化，每月或每季度自动执行一次，并把结果推送到安全团队的消息群。有人值守地处理异常比堆砌扫描器更重要。
并购或业务剥离后的第一时间也要做一轮完整的资产盘点。很多企业在合并后根本不掌握被收购方的完整域名列表，那些被遗忘的域名和子域就是攻击者最稳定的入口。
5.3 事件响应与员工演练：让信任危机在爆发前刹车
再完善的技术加固也扛不住100%保证不中招，所以员工演练和事件响应仍然是不能省的环节。
员工演练这块，我强烈建议把频率从“一年一次”提高到“每季度一次甚至每月一次”，并且场景要贴合企业自身的业务习惯。演练场景建议覆盖三类：IT账号异常提醒类、薪资福利调整类、客户供应商资金往来类。演练结束后统计两个核心指标：点击率和报告率。点击率要控制在5%以下，报告率要提升到50%以上——后者代表了员工识别钓鱼后主动上报的意愿，比单纯考核点击率更能反映安全文化建设的成果。
事件响应这块，发现真实钓鱼邮件后建议按以下链路执行：
- 立刻在邮件网关中封堵发件人、主题、URL和附件哈希。
- 提取钓鱼邮件的完整样本，更新威胁情报库。
- 核查同类邮件是否已投递给更多用户，评估泄露范围。
- 对中招员工立即重置凭据，强制重新认证。
- 如果涉及子域名接管，第一时间删除对应DNS记录并封禁相关第三方服务账号。
- 向全员发送简短通报，提醒注意同类手法。
响应速度在钓鱼事件中至关重要，钓鱼站点的生命周期通常只有几小时到几天，晚一步封堵，就已经有更多员工中招。
最后的一点经验
我在实际处理中最大的体会是：内部域名钓鱼防的不是技术，是疏漏。大部分被攻破的企业并不是没有安全设备，而是SPF配置错了、子域名没人管、DMARC报告没人看。每个月花半天时间跑一次子域名扫描、查一次SPF和DMARC记录，效果比追加预算买一套新设备要明显得多。
再分享一个小技巧：把DMARC的聚合报告接入一个可视化平台，设置异常告警，一旦“来自该域名的未认证邮件量”突然升高，立刻排查。这往往是钓鱼攻击开始前的第一通鼓声——攻击者正在用你的域名向外试发邮件。看到这个信号后花两小时处理，比第二天接到客户投诉再去公关要划算得多。
