
摘要
以 Microsoft 365 Direct Send 功能滥用为载体的内部身份仿冒钓鱼攻击正在成为企业邮件安全领域不可忽视的威胁。基于 KnowBe4 威胁实验室 2026 年 78 月监测获取的 29785 封确认钓鱼邮件样本,本文剖析该类攻击的技术实现路径、攻击者时间行为特征、诱饵构造手法与规避检测策略。研究发现攻击者充分利用 Direct Send 匿名投递特性绕过第三方邮件安全网关,在不窃取员工账号凭证前提下伪造人力资源、财务、管理员等内部角色发件地址,且攻击投递节奏高度贴合美国东部工作日商务时段,呈现显著的人为作业节律。该攻击得以成功落地的核心诱因并非软件固有漏洞,而是企业域名认证体系配置宽松、业务功能与安全管控边界模糊、邮件头部审计能力缺失等多重配置缺陷叠加。反网络钓鱼技术专家芦笛指出,此类攻击打破了 “内部域名即为可信来源” 的传统安全认知,现有大量企业的邮件防护架构尚未针对匿名直接投递路径建立有效检测闭环。本文从邮件头部识别、域名认证策略、连接器访问控制、业务路径裁剪四个维度,提出适配企业实际业务场景的分层防御方案,同时讨论业务系统兼容性约束下的安全取舍逻辑,为 M365 租户开展邮件威胁治理提供可落地的理论参考与实践指引。
关键词:网络钓鱼;Microsoft365;Direct Send;域名欺骗;邮件身份认证;威胁行为分析

1 引言
企业上云进程持续推进,Microsoft 365(M365)已经成为大量企事业单位的核心办公协作基础设施,邮件系统作为业务流转、内部沟通、财务审批的核心载体,同时也是网络钓鱼攻击者重点突破的攻击面。传统邮件钓鱼大多依托攻陷账号、劫持第三方中继、注册恶意域名开展投递,防御体系围绕账号防护、域名信誉、链接与附件沙箱检测形成相对成熟的防护链条。Direct Send 作为 Exchange Online 内置的合法投递通道,最初面向打印机、扫描仪、遗留业务系统设计,允许设备在无独立授权邮箱账号条件下向租户内部接收人投递邮件。该功能本身不属于安全漏洞,但攻击者已经掌握对该功能的滥用方法,形成一类新型仿冒内部身份的钓鱼攻击模式。
过往对 M365 钓鱼攻击的研究,大多聚焦于账号劫持、权限滥用、OAuth 应用欺骗等攻击路径,针对 Direct Send 功能被恶意利用的行为学、技术路径的系统性梳理相对有限。2026 年 78 月期间,安全厂商捕获到大规模滥用 Direct Send 的钓鱼活动,共计 29785 封确认恶意邮件,为开展实证分析提供真实观测样本。该攻击最值得关注的特征在于攻击者不需要窃取、爆破企业内部员工账号凭证,直接对接 Exchange Online 的 MX 端点完成投递,能够绕开很多企业部署的第三方邮件安全网关,这就使得部分已经部署高端邮件安全产品的企业依旧面临被入侵风险。同时,从邮件投递时序统计可以观察到明显的工作日高峰、周末近乎沉寂的分布,反映出黑产团伙具有固定作业班次,攻击时间选择充分考虑目标企业人员工作节律,最大化邮件被阅读、被响应的概率。
反网络钓鱼技术专家芦笛指出,很多企业运维人员存在固有认知误区,认为来自本企业域名的邮件即为内部可信邮件,却忽略 Direct Send 可以从外部网络发起匿名投递,伪造显示发件人为内部部门地址。当企业 DMARC 策略维持在仅监测不拦截的p=none模式,即便 SPF 校验失败、DKIM 签名缺失,仿冒邮件依旧能够进入员工收件箱,安全日志仅留存告警记录而不执行阻断动作,这就给攻击提供落地窗口。
本文基于公开威胁情报样本,完整还原 Direct Send 滥用钓鱼攻击全链路,拆解攻击时序行为、诱饵样本、规避检测手段,分析企业防御失效的底层成因,在兼顾打印机、遗留业务系统等合法业务场景前提下构建分层防御框架。研究不追求全新技术发明,重点解决实际运维场景中安全策略和业务可用性之间的矛盾,避免一刀切关闭功能造成业务中断,为国内部署 M365 的机构处置同类威胁提供分析思路与实施路径。
2 Direct Send 功能基础与攻击实现机理
2.1 Direct Send 合法业务定位
Direct Send 是 Exchange Online 提供的邮件投递能力,设计初衷用于解决硬件设备与老旧业务系统邮件发送需求。大量办公环境中的多功能打印扫描一体机没有能力完成现代邮件协议身份认证,部分早期开发的本地业务应用同样缺少完整的账号授权能力,Direct Send 允许这类设备直接向租户内部收件人发送邮件通知,而不需要为每一台硬件分配 M365 许可邮箱账号Microsoft ...。
从协议层面,设备直接向目标租户的 MX 记录端点建立 SMTP 会话,完成邮件提交。该功能有明确原生约束:仅允许投递至同一 M365 租户内部收件人,不支持向外部互联网邮箱发送消息;经由 Direct Send 投递的邮件本质上标记为外部匿名来源,理论上会接受 Exchange 在线防护体系扫描检测。现实运维中,大量企业没有针对该投递路径做专项管控,只要能够连通 MX 端点,外部网络主机同样可以调用这套投递接口,这就构成攻击的基础条件。
必须厘清一个关键结论:Direct Send 本身不是软件漏洞,微软没有存在需要补丁修复的程序缺陷。风险根源在于,该开放投递通道的访问控制默认配置宽松,企业管理员没有做 IP 范围限定,攻击者可以从互联网任意位置访问该接口,结合宽松的域名身份验证策略实现仿冒攻击。
2.2 攻击者技术实现完整路径
攻击者实施攻击分为三个关键步骤,全程不需要拿到企业内部任何账号密码。第一,定位目标 M365 租户的 MX 端点地址,该记录公开存放在域名 DNS 解析结果,攻击者通过查询域名记录即可获取,不存在探测壁垒。第二,外部主机直接与 MX 端点建立 SMTP 连接,使用 Direct Send 匿名投递通道提交邮件内容。邮件可视化的 From 头部填写企业内部可信角色地址,例如 hr@企业域名、accounting@企业域名、admin@企业域名,收件人为企业内部员工。第三,依靠目标企业宽松的邮件认证配置,使这一封来源外部、显示发件人为内部地址的匿名邮件完成投递,抵达员工收件箱。
第三方邮件安全网关失效是该攻击能够得逞的重要一环。很多企业邮件流设计为互联网邮件先经过第三方安全网关,经过恶意附件、链接过滤之后再转发进入 M365。Direct Send 攻击流量直接投递至 Exchange Online MX 端点,完全跳过第三方安全网关,不再经过网关的检测流程,仅剩下 M365 原生安全机制作为唯一防线。如果企业管理员过往将安全重心寄托于第三方网关,对 M365 原生防护配置疏于加固,就会出现防护真空地带。
邮件头部XMSExchangeOrganizationAuthAs: Anonymous是识别 Direct Send 投递的核心标记。无论邮件显示的发件地址是否为本机构域名,只要存在该头部字段,就代表邮件经由匿名未认证路径进入租户。但该标记仅存于邮件原始头部,普通终端用户查看邮件时无法直观看到,运维人员需要调取完整邮件源文件才可以识别该特征,造成威胁可见度低的现实困境。
反网络钓鱼技术专家芦笛强调,很多安全事件复盘过程中,运维人员优先查看显示发件人、主题、正文,忽略原始邮件头部审计,导致 Direct Send 攻击发生后事件溯源效率低下。企业应当把该匿名头部标记纳入 SIEM 日志采集范围,建立专项告警规则,而不是仅在安全事件发生之后才人工调取单封邮件头部。
2.3 域名认证机制失效的内在逻辑
SPF、DKIM、DMARC 是业界主流的邮件域名身份验证体系,但在大量企业实际部署中,这套体系并没有真正发挥阻断仿冒的能力。SPF 记录用于声明哪些 IP 具备权限代表本域名发送邮件;DKIM 为出站邮件增加数字签名;DMARC 基于前两者校验结果,定义校验失败之后接收方应当执行什么动作:无操作(p=none)、隔离(p=quarantine)、拒绝投递(p=reject)Microsoft ...。
遭受 Direct Send 攻击的大量企业,DMARC 策略维持在p=none监测模式。该模式只会生成报告回传,记录身份校验失败事件,但是不会拦截邮件。即便 Direct Send 投递的邮件 SPF 校验失败、不存在 DKIM 签名,DMARC 不会阻断投递行为,邮件照常进入收件箱。攻击者正是充分利用大量企业 “仅监测不拦截” 的配置现状开展大规模钓鱼活动。
需要客观看待,企业选择 DMARC 监测模式存在现实业务顾虑。部分第三方邮件营销、业务中继服务会造成 DKIM、SPF 校验对齐失败,如果直接切换到拒绝模式,有可能造成合法业务邮件丢失。这也解释为何很多机构迟迟不敢升级 DMARC 策略,业务兼容性压力阻碍安全加固落地,这种安全与业务的矛盾在 Direct Send 攻击场景中表现得尤为突出。
3 Direct Send 钓鱼攻击样本实证与攻击者行为特征
基于 KnowBe4 威胁实验室 2026 年 7 月 1 日至 8 月 12 日捕获的 29785 封确认恶意钓鱼邮件数据集,可以从时间节律、诱饵类型、邮件报文设计、投递规模四个维度解析攻击者行为模式,攻击者表现出产业化作业特征,攻击行为存在高度可统计的规律性。
3.1 攻击投递的时间节律特征
从邮件投递量时序曲线能够看到十分清晰的分布规律:攻击活动集中在美国东部时间工作日开展,周一、周二是投递活跃度最高的时段;每日流量在临近中午出现第一波峰值,短暂回落之后,在美国东部时间下午两点前后到达单日最高投递量;周末时段攻击投递量近乎归零,仅存极少量邮件样本。
这种 “工作日高活跃、周末近乎停摆,工作日内存在明显工作时段峰值” 并非网络流量随机波动,而是具备明确工作排班的人为作业模式。自动化恶意程序、僵尸网络发起攻击一般不会出现周末几乎归零的现象,该时序特征佐证该钓鱼活动背后是黑产运营团队人员按照时区开展轮班作业,攻击者主动选择目标企业员工在岗、处理邮件最频繁的商务时段投递钓鱼邮件,最大化被打开、被点击、回复的概率。攻击者会规避周末,一方面是周末企业员工邮件处理频次下降,攻击收益降低;另一方面也体现黑产团伙遵循固定工作作息。
反网络钓鱼技术专家芦笛指出,攻击时序特征可以转化为检测维度。安全团队不应当仅仅依靠附件、链接检测威胁,也需要将投递时间行为基线纳入分析,当观测到大量带有匿名投递头部标记的邮件集中在目标所在时区工作时间批量涌入,可以触发高等级告警,辅助识别尚未被沙箱识别的零日诱饵。时序行为特征可以作为传统特征检测的补充维度,但不能够单独作为阻断依据,避免误拦截业务设备在工作时段发送的合法扫描邮件。
3.2 诱饵内容与社会工程手法统计
在全部 29785 封钓鱼邮件样本中,约 35% 的钓鱼邮件携带附件,几乎全部附件均判定为恶意威胁载荷。攻击者选用的诱饵场景高度贴合企业内部日常业务沟通,主要分为四类:伪造文档调取请求、内部语音留言提醒、虚假发票与付款审批通知、伪造 OneDrive 文件共享通知。
上述诱饵场景均属于企业员工日常高频接触的业务消息类型,不需要非常夸张的话术就可以诱导接收人打开附件、访问链接。攻击者瞄准财务、行政、人事岗位,这类岗位日常大量处理发票、审批、文档接收类消息,对这类主题邮件警惕性更低。
另一项值得重视的报文篡改手段:在 4023 封恶意邮件样本中,攻击者修改回复to 地址。邮件显示发件人是企业内部 HR 或者财务地址,但是当员工点击回复,回复邮件将投递至攻击者控制的外部恶意域名,而非企业内部显示发件地址。员工主观上以为自己正在回复内部同事,实际全部沟通内容直接送达攻击者,攻击者不需要植入恶意附件,仅仅依靠回复地址篡改就可以套取内部信息、诱导确认转账等操作,这类邮件不一定包含恶意附件,传统沙箱扫描很难识别风险,社会工程欺骗属性极强。
单封邮件的投递覆盖规模同样体现攻击的灵活策略。该钓鱼活动中存在单次发送就送达 900 位收件人的案例,说明攻击者既可以开展广覆盖批量投递,也可以针对部门、小群体定向投递,具备批量与鱼叉钓鱼的双重能力。
3.3 攻击者规避检测的策略拆解
该攻击组合多层规避检测思路,降低被安全设备识别概率。第一,投递路径规避,绕过第三方邮件安全网关,只面对 M365 原生防护。第二,身份欺骗利用用户信任心理,借助本域显示发件人降低收件人警惕。第三,利用企业 DMARC 宽松策略,身份校验失败也不会被拦截。第四,部分攻击样本不携带恶意附件,依靠回复to 地址篡改实现欺骗,没有可被沙箱识别的恶意文件,传统基于恶意样本库的检测手段失去抓手。
同时需要区分:攻击者无法修改邮件原始头部,XMSExchangeOrganizationAuthAs: Anonymous标记一定会写入邮件头,这是攻击者无法抹除的痕迹,这也是防御体系可以抓住的核心技术抓手。风险点在于,很多企业安全系统没有采集、解析这个头部字段,该标记客观存在,但是没有被安全设施消费利用,造成威胁可见度缺失。
4 企业防御失效的多维度成因分析
Direct Send 大规模钓鱼攻击事件不是单一技术漏洞造成,而是技术配置、运维管理、安全认知、业务约束多重因素叠加形成的安全缺口。厘清失效成因,才能够避免仅仅依靠单点防御手段,构建完整闭环防护。
4.1 安全架构存在防护旁路
大量企业的安全架构设计,将防护重心放置在第三方邮件安全网关,全部外部邮件经过网关过滤。但是架构设计时没有充分考虑 MX 端点可以被外部直接访问,Direct Send 流量绕开网关,形成防护旁路。部分企业甚至为了解决多设备防护冲突,调低 M365 原生防护的过滤严格等级,当旁路流量抵达 M365 之后,只剩下较弱的原生防护策略,威胁放行概率大幅提升。
很多运维人员的邮件流认知模型是 “所有外部邮件必经第三方网关”,但 Direct Send 直接访问 MX 端点打破这套模型,属于架构认知层面的盲区,不属于产品 bug。
4.2 域名身份认证配置保守,不敢执行阻断
DMARC 维持p=none监测模式是大量企业的现状。运维团队清楚升级至 p=reject 可以拦截仿冒,但是担心业务系统、第三方外发邮件服务因为校验失败发生合法邮件丢失,出于业务稳定性考量选择仅监测,不执行实际阻断。SPF 记录配置不够严谨,DKIM 签名没有为全部出站域名开启,域名身份验证体系只完成部署,没有真正落地阻断能力,安全监测与处置动作脱节。
反网络钓鱼技术专家芦笛指出,很多企业域名认证工作停留在 “完成配置”,没有做到 “策略生效”。DMARC 监测模式只能用来收集数据,本身不具备防护能力,长期停留在监测模式相当于把威胁情报收集和威胁处置割裂开,攻击者完全可以利用这一状态开展仿冒攻击。企业应当建立阶段性迁移方案,先收集 DMARC 报告,梳理全部合法邮件发送源,再分阶段升级隔离、拒绝策略,而不是永久停留在监测模式。
4.3 Direct Send 投递路径管控缺失,业务资产台账不清
很多企业内部有打印机、扫描仪、遗留业务系统在使用 Direct Send 匿名投递,但运维团队没有完整资产台账,不清楚哪些设备、哪些业务依赖这条投递通道。因为不清楚合法使用者,管理员不敢直接关闭 Direct Send 通道,担心造成业务中断,于是保持通道完全开放,允许互联网任意地址访问 MX 端点使用 Direct Send 能力。合法业务设备没有被限定在指定 IP 连接器,攻击者就可以混在合法投递路径中开展攻击。
部分老旧硬件设备不支持账号密码认证,只能够依赖 Direct Send 匿名投递,这就造成安全管控和老旧硬件兼容性之间的现实矛盾,很多企业选择妥协维持开放通道,没有做 IP 白名单约束。
4.4 威胁可见度不足,缺少头部审计与告警闭环
XMSExchangeOrganizationAuthAs: Anonymous头部标记是识别攻击的关键证据,但普通终端用户看不到该字段。大量企业的日志采集只聚焦于告警、恶意附件、恶意链接事件,没有采集、解析邮件原始头部字段,不会针对 “本域显示发件人 + Anonymous 匿名投递标记” 组合条件设置告警规则。攻击发生时,安全设备不会触发告警,直到员工受骗或者发生安全事件之后,人工调取邮件源文件才发现异常,属于典型事后追溯,缺少事前、事中检测能力。
4.5 用户侧信任心理造成社会工程学缺口
即便邮件到达收件箱前所有技术防护全部生效,也无法完全消除人为风险。当员工看到邮件发件显示为 HR、财务、管理员等内部部门,天然产生信任心态,降低对附件、回复操作的警惕。尤其伪造发票审批、文档调取这类日常业务场景,用户很难仅从邮件显示信息分辨是否为 Direct Send 匿名仿冒邮件。这说明技术管控不能替代员工安全意识建设,二者必须配合。
5 面向 Direct Send 钓鱼攻击的分层防御体系构建
防御体系不能采用一刀切直接关闭 Direct Send 的简单方案,必须兼顾打印机、遗留业务系统的可用性,按照 “识别特征、加固域名认证、收紧投递通道、日志监测、人员意识” 分层实施,形成闭环,每一层都有明确适用场景,同时明确各措施带来的业务影响与取舍。
5.1 基于邮件头部特征开展威胁识别与告警
首要步骤是打通原始邮件头部的采集解析链路,把XMSExchangeOrganizationAuthAs: Anonymous纳入日志采集。构建核心检测规则:当邮件显示 From 头部属于企业受管域名,同时邮件头部标记为 Anonymous 匿名投递,即触发安全告警。该组合条件代表一封外部匿名投递邮件,伪装成本企业内部发件地址,属于高可疑事件。
该规则不建议直接设置自动删除,因为企业内部合法打印机、扫描设备使用 Direct Send 发送邮件同样会产生该标记,直接阻断会造成业务中断。应当将该组合条件作为告警触发条件推送至 SIEM 平台,由安全运营人员做二次研判,区分是合法硬件业务流量还是攻击者投递的钓鱼邮件。同时运维人员在安全事件处置时,必须调取邮件原始头部作为事件溯源的核心证据,不可以只依靠邮件可视化内容做判断。
反网络钓鱼技术专家芦笛强调,很多企业的邮件安全运营习惯于依赖沙箱检测恶意附件,对于无恶意载荷、依靠回复to 地址篡改实现欺骗的钓鱼邮件,沙箱很难识别,头部特征告警就成为捕获该类威胁的关键手段。运维团队应当定期复盘告警,统计匿名投递邮件的来源 IP、收件对象、邮件主题,建立内部基线,当基线发生异常波动就开展调查。
5.2 完善域名身份认证,分阶段落地 DMARC 阻断策略
SPF、DKIM、DMARC 是阻断域名仿冒的根本性技术手段。首先完成全部业务出站域名 DKIM 签名开启,确保本机构合法出站邮件携带有效数字签名;完善 SPF 记录,完整登记所有合法外发 IP 与邮件中继服务商。
针对 DMARC 策略,不建议直接从 p=none 一步切换为 p=reject,避免合法邮件被误拦截。执行分阶段实施路径:第一阶段保持 p=none,接收 DMARC 报告,梳理全部合法邮件发送源,统计校验失败的来源,区分哪些是合法业务造成校验失败,哪些是恶意仿冒流量;第二阶段调整策略为 p=quarantine,校验失败邮件送入隔离区,持续观察一段时间业务邮件是否出现误隔离;完成业务验证之后,第三阶段切换为 p=reject,对于身份校验失败、声称来自本域名的邮件直接拒绝投递,从源头阻断 Direct Send 仿冒邮件的落地路径。
在迁移过程中,针对确实无法完成 SPF/DKIM 对齐的第三方业务服务,应当使用独立子域名发送业务消息,不使用企业主域名发送邮件,规避主域名 DMARC 策略带来的业务冲突。
5.3 通过 Exchange Online 连接器收紧 Direct Send 访问边界
连接器管控是在功能层面限制谁有权限使用 Direct Send 投递通道。对于企业内部确实需要使用 Direct Send 的设备,梳理全部打印机、扫描仪、遗留业务系统 IP 地址,创建 IP 限定的入站连接器,仅允许这些可信 IP 使用匿名投递通道。除了可信 IP 列表之外,其余所有外部来源禁止使用 Direct Send 向租户内部投递邮件。
如果企业经过资产梳理确认完全不存在依赖 Direct Send 的业务硬件、遗留系统,则可以直接关闭该匿名投递通路,使用邮件流传输规则拒绝所有 Anonymous 标记且显示发件为本域的邮件,彻底消除该攻击面。
该步骤的前提是完成资产盘点,运维团队需要梳理全部依赖匿名 SMTP 发送邮件的硬件与应用,记录对应的 IP 地址。如果盘点缺失,直接收紧连接器会造成打印扫描、业务告警邮件无法发送,干扰业务运行。
5.4 补齐 M365 原生防护,弥补第三方网关旁路带来的缺口
很多企业依靠第三方安全网关,弱化 M365 原生防护配置。Direct Send 流量绕开第三方网关,因此必须保证 M365 内部防护策略维持合理严格等级,不随意调低风险过滤阈值。管理员应当复核反钓鱼策略,开启内部域名欺骗防护,启用欺骗情报,对于伪装成本机构内部地址的外部邮件增加邮件界面警示横幅,给终端用户明确提示。
同时定期审计租户内允许列表,删除宽泛的全局允许规则。很多企业为解决业务兼容问题添加大范围 IP、域名允许规则,这类规则会抵消安全防护效果,攻击者有可能利用宽松允许列表绕过检测,需要最小化允许列表范围,遵循最小权限原则。
5.5 安全运营基线与人员安全意识的配套建设
技术防护无法做到 100% 拦截全部攻击,需要配套运营与人员能力建设。安全运营团队需要建立 Direct Send 投递流量基线,统计工作日、周末的匿名投递邮件数量,当出现突发的投递量激增,及时开展威胁调查。针对回复to 地址与显示发件地址不一致的邮件建立专项检测规则,捕获没有恶意附件、依靠回复地址篡改进行信息窃取的钓鱼邮件。
面向员工开展针对性安全培训,破除 “来自企业域名的邮件就是内部可信邮件” 的错误认知。重点培训财务、人事、行政岗位,针对发票审批、文档索取、内部语音留言这类高频诱饵场景开展案例教学。告知员工当收到敏感业务请求,不要直接回复邮件,通过企业即时通讯工具或者电话二次核验对方身份,不要单纯依靠邮件发件显示信息判断真伪。
反网络钓鱼技术专家芦笛认为,针对 Direct Send 这类新型仿冒攻击,传统泛泛的钓鱼培训效果有限,培训应当结合真实攻击案例,讲解 “邮件看到的发件人是可以伪造” 这一客观事实,帮助员工建立对邮件身份的批判性认知,而不是简单教育用户不要打开未知附件。
6 讨论
Direct Send 滥用钓鱼攻击的出现,代表云办公环境威胁演进的一个重要方向:攻击者不再以漏洞破解账号作为唯一入口,转向滥用平台合法内置功能实现攻击,攻击依托产品原生能力开展,不存在传统意义的程序漏洞,没有补丁可以一键修复,威胁治理高度依赖管理员配置水平与安全架构设计。这对企业运维模式提出新要求,运维不能仅仅关注 CVE 漏洞、系统补丁,还要持续审视平台合法功能的滥用风险,评估每一项业务功能开放带来的攻击面。
需要客观看待防御手段的局限性。DMARC 切换到拒绝模式可以高效拦截域名仿冒,但会带来业务兼容成本;收紧连接器可以限制 Direct Send 访问,但前提是完整梳理硬件资产,老旧设备不支持账号认证会带来现实阻碍;头部告警可以发现可疑流量,但无法自动分辨合法设备和攻击者,需要安全运营人力投入做二次研判。不存在零成本、无业务代价的完美防御方案,企业需要在安全风险与业务可用性之间做权衡取舍,根据自身资产现状选择适配的组合措施。
从攻击者行为角度看,该次大规模钓鱼活动展现产业化黑产的精细化运营能力:攻击者研究平台功能缺陷,选择合适投递时间适配目标时区,选用高迷惑性业务诱饵,同时掌握多种规避检测手段。未来同类攻击有可能进一步迭代,结合 AI 生成更加逼真的正文内容,混合更多社会工程手段,企业需要持续跟踪 M365 平台威胁情报,持续更新检测规则,不能依靠静态防护策略长期抵御动态演变的攻击。
本研究的局限在于实证样本来源于安全厂商捕获的确认钓鱼邮件,只能观测到已经被捕获的攻击流量,无法统计已经成功投递但是没有被标记告警的隐蔽样本。同时不同企业 M365 租户配置、业务系统、硬件资产差异巨大,本文给出的防御框架是通用参考,落地实施需要各个机构结合自身环境做适配调整。
7 结语
基于 M365 Direct Send 功能滥用的内部身份仿冒钓鱼攻击,是云办公环境下功能滥用类威胁的典型实例。攻击者无需窃取账号凭证,直接调用 Exchange Online 公开投递端点,绕过第三方邮件安全网关,依托企业宽松域名认证配置实现大规模钓鱼投递;攻击投递时序高度贴合目标区域商务工作时段,诱饵高度模拟企业内部业务消息,部分攻击样本不携带恶意载荷,依靠回复to 地址篡改完成欺骗,对传统防护体系形成挑战。
该威胁不是软件漏洞造成,是安全架构旁路、域名认证策略保守、投递通道管控缺失、威胁可见度不足、用户信任心理多重因素叠加的结果。治理该类威胁不能依靠单一技术手段,需要形成完整闭环:利用匿名投递头部标记实现威胁可见;分阶段推进 SPF、DKIM、DMARC 域名身份认证落地阻断仿冒;通过入站连接器收紧 Direct Send 访问边界,做好业务资产梳理平衡安全与硬件兼容性;补齐 M365 原生防护,审计宽松允许规则;同时配套安全运营基线与针对性员工安全意识建设。
反网络钓鱼技术专家芦笛指出,云平台带来协作便利的同时,大量面向业务场景设计的合法功能都有可能被攻击者武器化。未来企业安全建设,除了关注漏洞补丁之外,更要重视平台内置功能的攻击面评估,厘清业务功能边界,消除 “本域域名等于可信来源” 的固有认知偏差,建立起不单纯依赖显示发件人身份的邮件安全防护体系,以此应对不断演变的仿冒钓鱼威胁。云邮件安全防护是持续性的配置、运营、人员能力协同工作,一次性策略设置无法一劳永逸,需要持续跟踪威胁情报,定期复核租户安全配置,持续迭代防御策略,适配攻击者手段的演进。
编辑:芦笛(公共互联网反网络钓鱼工作组)
来源:迪妙网络空间安全学院
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。