文章总结: 本文披露了滥用WindowsToast通知机制进行社会工程学攻击的技术细节。攻击者可通过WinRTAPI冒充合法应用发送伪造通知,利用AUMID标识符伪装成Edge/Teams等可信应用,通过包含恶意链接的交互式弹窗诱导用户操作。文档提供了完整的PowerShell实现方案,涵盖AUMID枚举、XML载荷构造及三种攻击场景模拟,揭示了这种低权限攻击在红队渗透中的实际价值。 综合评分: 88 文章分类: 社会工程学,红队,内网渗透,终端安全,安全意识
这里有一个我觉得相当有意思的思路——姑且称之为_通过社会工程学实现横向移动(lateral movement)_。你先找到团队里有一定影响力的人:一个 lead、一个 manager,或者大家都愿意听的人。向他们发一条看起来来自可信同事的 toast notification,把他们引入一通与你的社工专家的通话。目标此时已经完成了心理预热:他们因为信任发件人所以点了进来,他们因为感觉紧迫但又平常所以加入了通话。接下来,专家开始施展——某件事必须现在解决,整个团队都得知道,咱们赶紧把大家拉进来。一个人信任你,说服了整个小组,信任边界就此瓦解。就这样,你从一个单一的受损会话,一下子变成了整个团队都在你主持的通话里。
伪造安全警报
这招挺好玩的,因为对某类目标确实管用。通过 Windows Security 的 AUMID(Microsoft.SecHealthUI_xxx),你可以推一条看起来像高危事件通知的弹窗——带显示遥测处理进度的进度条、严重等级选择器,还有一个”加入会议”按钮,指向你想要的任何地方。对那些认真对待安全警报的用户,这招打击力度确实不一样。如果你的目标是让人安装某个工具、加入某个通话,或者把同事也拉进来,紧迫感的包装会帮你省很多力气。
不过说实话:_这些都不是什么魔法_,这项技术和社会工程学里所有东西一样,成败全靠借口。但投递渠道出奇地干净:原生、可信,弹窗自动消失。通知会留在操作中心等用户自己清除,不会留下任何明显暴露你踪迹的持久性痕迹。
限制与检测
这个”技术”有几个显而易见的局限:
-
其一
:你需要一个交互式会话。如果你的 implant 跑在 session 0 里,API 调用会成功,但_显然_,通知根本不会出现。你得在一个真实用户已登录、正在看屏幕的会话里才行。
-
其二
:某些组织可能会下发
NoToastApplicationNotification这类策略,把 toast 通知直接全禁了。启用之后,你的调用照样返回成功,但通知就是不弹。在费心思设计借口之前,值得先确认一下。
检测这边:_不太好搞_。确实有个 ETW provider,Microsoft-Windows-PushNotification-Platform,但没有哪一个事件能直接把你的进程和那条通知关联起来——通知的分发是走 WpnService的,ETW 事件归因到那里,不归因到调用方。如果 EDR hook 了 WinRT COM 接口,那就能捕到了,这点留意一下。
工具包
折腾这些想法一段时间后,我把核心功能封进了一个正式工具:toastnotify-bof。
这是个 BOF,暴露了三个子命令:getaumid、sendtoast和 custom。
getaumid顾名思义;sendtoast让你给任意 AUMID 发一条简单的标题 + 正文通知。custom子命令才是灵活性的所在,也是你大把时间会花在琢磨借口上的地方。它不在内部构建 XML,而是直接接收 base64 编码的载荷,让你能制作任意复杂的 toast 模板——进度条、下拉选择、图片、协议跳转——不用重新编译,直接投送。
inline-execute toastnotify.o go custom MSEdge <base64-xml-string>
结语
这事儿有点诗意。Windows 搭了一套完整的通知系统,本意是把用户注意力引向合法应用,结果同一套系统被指向你想要的任何地方也毫无怨言,不问缘由,用的还是它自己已经注册好的身份。
说实在的,这种”toast 通知滥用”能玩的花样有限,也很具体,但思考起来挺有意思的。最后,如果用户点了,今天就值了;如果没点,嗯,也就是一条通知而已。
更新 – 2026 年 4 月 7 日
原来我不是第一个把 toast 通知往进攻方向想的人。Fox-IT 早就发布了 Invoke-CredentialPhisher,一个用 toast 通知对用户搞社会工程学、套取凭据的 PowerShell 脚本。当时挺好用的,后来新版 Windows 的系统更新把它搞坏了。我写这篇文章时并不知道这件事,我的研究是从 COM 枚举独立起步的,最后落在了同一块 API 面上。发布之后发生了两件事:iPurple Team 用 C# 出了个 BOF 移植版(ToastNotify),把研究延伸了一步,还加了覆盖 DLL 加载监控、Sigma 规则和 MDE 查询的检测工程章节。另外,Censys ARC 发布了一份对此前未记录的俄罗斯工具包 CTRL 的分析,里面有一个 toast 通知伪造模块,用的正是本文描述的同一种方法。
该工具包至少从 2026 年 2 月中旬就开始活跃了,早于本文发布。算是对一个已有文档 API 的独立殊途同归,不过看到这项技术在实战中得到验证,还挺有意思的。
资源
- win11toast
免责声明:本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:securitainment Marco Marco《滥用 Windows Toast 通知实现用户操纵》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论