2026-10-17 09:50:25 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

cover_image

我的同事\"被组织\"了一场钓鱼会议

原创

MessFeel
MessFeel

MessFreeSecurity

2026年8月12日 23:23
北京

在小说阅读器读本章

去阅读

下午打开企业微信，日历里躺着一条陌生日程。标题叫\"高温补贴申请通知\"，组织人是我不认识的一个同事，参与人列表拉了整个公司。

我把那条链接复制到手机浏览器。下面是我拆开的东西。

日程入口

先想一个问题：你上班收到一条日程邀请，组织人是部门同事，头像名字都对，标题写着\"补贴申请\"，描述里说要今天内完成——你会觉得这是钓鱼吗？

不会。日程邀请是协作平台里最接近内部通知的形态。它不是群消息，群消息会被折叠会被截屏发到安全群。日程是平台原生的分发通道，组织人写完标题和描述，系统自动推给所有参与人。恶意链接套上了\"内部通知\"的壳，你连怀疑的入口都没有。

链接指向 wap[.]wafnhci[.]cn。每次访问 302 跳转到新的随机子域。同事之间互相转发，最终拿到的地址都不一样。封一个 URL 没用——攻击者早就算好了。

在微信内置浏览器里打开，页面会藏掉一部分菜单，然后弹提示让你\"复制到手机浏览器\"。这不是适配问题。微信浏览器有安全拦截和风险提示，他们想绕过去。

一个特征记住就行：一条消息同时要求\"当天办理\"和\"离开微信打开链接\"，先停。核实发送账号，联系发送人。别点。

同事的账号出了什么事

他说上午点过钓鱼链接。但\"点过链接\"和\"终端失陷\"是两回事。日程能以他的身份创建，有三种可能。

最可能的：登录会话被接管

不需要密码。他上午钓鱼页面里填完资料，页面\"审核中\"的时候，后台操作员可能已经诱导他扫了码，或者拿到了浏览器里的登录 cookie。用他的身份登企业微信，建全天日程，从通讯录拉人——五分钟的事。

截图里组织人是他，只说明日程用他的身份创建，不说明他本人操作了。

次之：应用凭证泄露

企业微信开放接口允许应用建日程，传主题、描述和 attendees 列表。如果某个自建或第三方应用的 Secret 被拿走，攻击者直接调接口批量创建。日程详情里如果有\"由应用创建\"的标记，或者日志里有异常 agentid 和 token 调用，就往这个方向查。

要排除：外部日历邀请同步

伪造显示名称，往邮箱发日历邀请，协作平台同步后也会出现在日历里。查原始邮件头、ICS 里的 UID 和 ORGANIZER，能区分内部创建和外部投递。

我把情况同步给了安全团队，建议按这个顺序查：账号会话先看，再查授权应用，最后排除外部邀请。日志没出来之前，别急着下结论说同事电脑被控了。但不管哪种路径，先冻结组织人账号的活跃会话，撤回恶意日程，这两件事不能等。

链条在攻击之前就铺好了

1收集部门结构、员工账号、群聊列表。参与人接近 100，大概率对应某个部门或群成员集合。

2拿日程创建入口。接管会话、窃取应用凭证、或者伪造外部邀请。

3建全天日程，把诱饵文案和钓鱼域名写进描述，加批量参与人。

4平台自动同步。内部头像、组织人姓名、参与人列表——全都在帮攻击者做背书。

5像我这样点开链接的人，进了手机浏览器之后，踩进一套完整的信息采集流水线。

要区分三条路径，调这几组记录

日程的 schedule_id、cal_id、创建和修改时间、创建来源、组织人 userid、参与人清单、有没有应用创建标记。
组织人账号事件前后的登录 IP、设备、扫码授权、网页登录、会话续期和安全告警。
组织人的手机、电脑、浏览器有没有同时段的异常进程、插件、下载或会话窃取痕迹。
日程权限配置、第三方应用授权、Secret 变更记录、token 获取和日程创建接口的调用日志。
如果是邮件同步，原始邮件头和 ICS 文件。

拿到创建来源、组织人登录记录、应用调用记录，三组数据交叉，基本就能定是哪条路径。

第一道关：不是手机就别想看

手机浏览器打开，页面秒加载，仿冒人社部门的申领界面。后来我在电脑上试同一个地址，跳出来的是个二维码过渡页。

看了源码，不是简单读 UA。它同时查了四样东西：UA 里有没有手机关键词、设备支不支持触摸（maxTouchPoints 和 ontouchstart）、navigator.platform 是不是桌面系统、屏幕短边宽度有没有超过 1200 像素。

mobileUa = UA 命中 Android / iPhone / Mobile / 微信等touch = maxTouchPoints > 0 或存在 ontouchstartdesktop = platform 命中 Windows / MacIntel / Linux x86如果 UA 不像手机、没有触摸、命中桌面平台或屏幕过宽：    跳转到电脑端二维码页

光改 UA 没用。Chrome DevTools 切个 iPhone UA，platform 还是 MacIntel，直接踢到二维码页。后面身份页和银行卡页还会再查一次平台。攻击者很在意分析环境能不能摸到真的采集页面。

图 1｜原始域名移动端实测：页面仿冒人社部门视觉，并强调“一次性最高 1500 元”和“立即申领”。截图只支持页面呈现，不支持页面中的政策主张。

身份页校验比某些政务网站还严

点了\"立即申领\"，进姓名和身份证页面。我随手编了个 18 位数字，前端直接报格式错误。

翻源码，它不止查长度。省份码、出生日期、最后一位校验码全验了一遍。瞎编的号过不去，你得给一个格式正确的真实身份证号才能进入下一步。

代码里还有 Tesseract OCR 的调用、后置摄像头和相册读取，能从证件照片上自动提 18 位号码。页面上那个扫描入口被注释掉了，但 OCR 和摄像头的代码还在运行文件里。换句话说，这个套件有能力直接从身份证照片读号，只是当前页面没把入口亮出来。

图 2｜同集群关联节点实测：姓名与身份证表单。关联节点和原始目标的核心控制脚本、Canvas 话术库哈希完全一致；截图不作为原始域名当次会话的直接回包。

银行卡页问余额，跟\"补贴\"没关系

姓名和身份证先写进 localStorage，然后进银行卡确认。三个必填项：卡号、余额、预留手机号。

页面说余额是用来\"核实本人领取\"的。发补贴不需要知道你卡里有多少钱。余额的真正用途是告诉后台操作员：这张卡值不值得继续。卡里三千和卡里三十万，后续的操作是不一样的。

前端读银行卡 BIN 判断发卡行和卡种。借记卡只收基础字段。信用卡和准贷记卡会多弹两个框：有效期、卡背后三位安全码。卡种和银行名称一起上报服务器，后台按卡类型决定下一步怎么处理。

提交的包：姓名、身份证、银行卡号、余额、手机号、卡种，信用卡再加有效期和安全码。服务器返回 current_order_id，每个受害者从这开始有自己的独立记录。

图 3｜同集群关联节点实测：页面索要银行卡号和余额，并用“资金发放确认”包装采集目的。信用卡会继续出现有效期与安全码字段。

审核中？后台操作员正在看你的资料

银行卡提交完，页面停在\"审核验证\"界面，写着约 1490 元、3%。金额和我的\"补贴资格\"没有半点关系，脚本里写死的。

这时候看网络请求就有意思了。首页加载完就生成了 index_online_tk，每三秒心跳。进采集流程后又生了一个 tk，大约每两秒向 commands.html 发请求，问\"下一步干什么\"。

返回的指令里有 action、url、msg、showtype 和 command_version。url 可以覆盖默认流程，action 决定跳不跳新页面，command_version 用来防止同一个命令反复执行。断网了页面会提示\"正在自动重连\"，恢复之后继续轮询。

所以你看到的\"审核验证\"不是一个自动流程。它是个等命令的状态。你的银行卡信息已经到了后台，操作员在另一块屏幕前看着，决定下一步推给你什么。