最近给某高校做安全巡检时,财务处的人拿着一张工资条来找我:三个员工当月工资显示“已发放”,但本人账户一分钱没进。我第一反应不是银行系统出错,而是先问了一句“这几位最近有没有改过收款卡号”,得到的答复是——都改过,而且都是通过邮件里的链接在线提交的。顺着这条线往下查,果然在工资系统的历史记录里看到了一个又一个员工本人并不认识的“幽灵账户”:开户行对不上、户名对不上、甚至有的连银行卡号位数都对不上。
这类攻击的套路并不新鲜,新鲜的是它精准打击了高校财务流程里一个非常脆弱的口子:员工自助修改银行信息、财务批量代发、缺少交叉核验。一篇仿冒人事处的“薪资复核通知”邮件,就能让一串银行账号在几分钟内被静默篡改。等工资真正发出去,钱进了攻击者的账户,人往往要到次月查账才发现。这篇文章就围绕这个完整攻击链路来拆:钓鱼邮件如何步步设局、银行信息如何被改写、高校和员工各有哪些拦截手段、出了问题后怎么溯源和止损,给校园财务、人事、网安相关岗位以及普通教职工一份能直接用的排查与防护参考。
1. 攻击全景图:一条从收件箱到工资卡的完整链路
1.1 高校为什么成了钓鱼邮件的重点目标?
很多人觉得高校信息系统的安全投入不算低,防火墙、杀毒软件、上网行为管理都配了,怎么还会被这种“老掉牙”的钓鱼手段打穿?但钓鱼攻击的命中率从来不取决于目标的安全预算,而取决于攻击者对业务流程的“阅读理解”水平。
高校工资代发是一个典型的“多方弱验证”流程:人事处负责核定薪酬,财务处负责发起代发,银行只校验账号和户名是否匹配。问题在于,很多高校的员工银行信息变更并没有严格的“原渠道确认”机制。一封标注“【人事处】关于2024年薪资统一复核的通知”的邮件,要求员工点击链接登录OA系统核对工资卡信息,这完全符合员工对学校的认知预期。攻击者赌的就是这一步:员工不会去核对发件人的真实域名,也不会给人事处打电话二次确认。
另外,高校的数据恰好是“高价值+低警惕”的组合。工资卡号、身份证号、手机号、社保信息一次集齐,在黑市里本身就是抢手货。而教职工对学校内部邮件的信任度远高于对陌生外部邮件的警惕度,这种信任就是攻击者的第一道突破口。
1.2 “幽灵账户”是如何产生的:攻击链路的五个关键环节
一个“幽灵账户”在工资单里落地,至少要经过五个环节。任何一环有了主动拦截,攻击链条都走不通:
| 环节 | 攻击手段 | 造成的影响 |
|---|---|---|
| 邮件伪装 | 仿冒HR/财务/银行名义,伪造发件人显示名与相似域名 | 诱导员工点击链接或输入账号 |
| 伪造登录页 | 高仿学校OA或网上银行页面,诱导输入账号密码与银行卡信息 | 员工主动交出敏感凭据 |
| 信息修改入口 | 利用盗取的OA账号进入自助薪资系统修改收款卡号 | 工资收款账户被替换 |
| 工资单静默改写 | 财务审核遗漏,批量代发按新账号推送银行 | 工资进入陌生账户 |
| 资金转移 | 攻击者通过网银/第三方支付快速分流资金 | 资金损失,追回困难 |
这五步里,前三步是全自动或半自动完成的,攻击者甚至不需要实时干预;第四步依赖财务审核的疏漏;第五步是纯粹的“跑分”操作。整个链条的可怕之处在于,单看任何一步都可能不值得警惕,但串联起来就是一个完整的杀伤链。
1.3 为什么传统“只看附件”的防钓鱼逻辑失效了
我见到很多安全培训和宣传材料都在强调“不要点击可疑附件”,这在大规模爆发型钓鱼邮件时代是有效的,但针对工资单场景的攻击根本不走附件路线。它走的是“引导操作”路线:让你访问一个高仿页面,让你自己输入账号,让你自己提交信息。员工没有下载任何恶意文件,也没有执行任何程序,安全软件完全无从拦截。
这就解释了为什么很多高校明明装了终端杀毒、邮件网关、流量审计,却仍然被一击即中——它们拦截的是“恶意载荷”,而这次攻击里根本没有传统意义上的恶意载荷。员工在仿冒页面上输入的信息,对攻击者来说就是最干净的“合法数据”。我习惯于把这类攻击称为“零载荷钓鱼”,它的隐蔽性远高于附件型钓鱼,而且在高校、政府、大型企业这类内网信任度高的环境中,成功率尤其高。
2. 三个高发场景与快速识别逻辑
2.1 场景一:仿冒内部通知的“薪资复核”邮件
这是目前高校里最常见的一种。邮件标题通常是“关于2024年12月薪资发放信息复核的通知”,正文里有一套正式的公文体例,落款是人事处或财务处,还附带一个“复核链接”。链接的域名往往和学校官网很像,比如真实域名是“abc.edu.cn”,仿冒域名可能就是“abc-edu.cn”或“abc.edu.cn.work”,肉眼不仔细看几乎分辨不出来。
识别逻辑其实很简单:任何需要输入银行卡号、身份证号、密码的“复核”,都不要从邮件链接进入。正常高校不会通过邮件链接让员工修改收款账号。正确做法是直接打开浏览器,从收藏夹或官网首页进入OA系统,自己找到“个人信息-薪资账户”入口,如果系统里已经有待办事项,再按流程处理。一句话:改银行卡这件事,永远要从系统内部进,永远不要从邮件外部点。
2.2 场景二:冒充银行的“账户异常”通知
第二种高发场景是仿冒工资卡发卡行的邮件或短信,内容通常带着紧急性,例如“您的工资卡存在异常交易,为保障资金安全,请点击链接完成身份验证”。这其实是用“银行”这个外部权威来压过员工对“学校”的信任,很多对钓鱼有防备心的人,一看到“银行”“账户冻结”“异常交易”反而会心慌,从而点进假链接。
这种场景的一个判断技巧是看它要你做什么。真实银行绝不会在邮件里直接要求你输入“完整银行卡号+查询密码+手机验证码”,更不会要求你在链接页面里同步填写身份证号。银行确实可能发送风险提示,但核实的一定是登录本行手机银行App或网点柜台,而不是邮件里的某个链接。我在内网安全培训里反复强调过一个原则:凡是主动给你发消息说“你有问题需要处理”并要求你登录某页面的,默认按钓鱼处理。
2.3 场景三:内部邮箱被盗后的“合法”钓鱼
相比前两种,这一类是最难防的,因为发件人确实是同事的内部邮箱。很多教职工的邮箱密码本来就不够强,加上某些邮箱系统没有强制开启双因子认证,攻击者盗取密码后直接登录邮箱,从历史邮件里找到人事处的招聘通知或工资相关邮件,套用同样的模板,再向通讯录里的同事群发“薪资信息核对”邮件。这种邮件发件人域名完全正确,SPF/DKIM检查也通过,因为它就是从真实系统发出的。
对付这种情况,靠员工识别邮件真伪已经不太现实,需要靠制度兜底:财务处和人事处明确发文规定,“凡涉及工资卡变更,必须线下或电话二次确认”,而且这个规定要反复强调到每个教职工都形成条件反射。一旦有人在群里问“这个通知是真的吗”,大概率已经出事了——因为真的通知不会让人产生这种疑问。
3. 高校侧与员工侧的防护实操指南
3.1 员工侧:拿到工资条前的三项自检动作
对普通教职工来说,与其学会识别所有钓鱼变种,不如固化三个动作。第一个动作:收到任何与工资、银行卡、OA账号相关的邮件,只看发件人域名,不看显示名称。“人事处 王老师”可以随便显示,但发件邮箱后缀做不了假。第二个动作:邮件里只要有链接,一律不直接点,改为手动输入官网地址登录系统。第三个动作:万一已经点击并输入了信息,不要等工资发了再说,立即修改邮箱和OA密码,同时打财务处电话冻结变更申请。
这三件事听起来不复杂,但真正做到位的人很少。主要原因是绝大多数人觉得“我不会有那么倒霉”,而攻击者赌的恰恰就是这种侥幸心里。我建议高校财务处可以把这三条印在工资条的背面,或者做成一张卡片随入职材料发放,把安全动作嵌入到日常工作流里,而不是停留在一年一次的安全培训课上。
3.2 财务与人事侧:银行信息变更的双人复核机制
在高校场景里,流程制度远比技术手段关键。很多高校的薪资系统允许员工在PC端自助修改银行卡号,修改后立即生效,没有任何冷却期或复核机制。这是整个链路里最大的结构性漏洞。
我建议至少做到三点改造。第一,员工提交银行信息变更后,系统自动发送确认短信到原绑定手机号,要求24小时内确认才算生效。第二,财务处在每月代发前导出“本月变更名单”,与人事处人工核对一遍,尤其是对公账户变动,必须有双人确认记录。第三,设定变更后的“冷静期”,比如新卡号首次代发时默认只发50%工资,剩余部分次月补发,对攻击者来说这种延迟会显著增加其资金沉淀风险,大大降低攻击收益。
这些改造不一定需要全新系统,很多高校的HR系统本身就支持自服务流程,只是默认没有把“强度调高”。改的只是几个配置参数和一条管理规章,成本几乎为零,效果却立竿见影。
3.3 技术侧:经费有限也能用的三层加固
很多高校的网安团队人数有限,预算有限,没法上全套商用安全产品。但至少有三层加固是低成本的。第一层是邮件域的SPF/DKIM/DMARC配置,很多高校根本没有配置DMARC策略,导致仿冒邮件大量外发却无法从源头拦截。如果暂时没有专业邮件网关,先把这三条DNS记录配好就是很大提升。
# 示例:某高校邮件域的SPF/DKIM基础配置参考 # 注意:实际发布前需要与学校邮件服务商确认具体值 SPF: "v=spf1 include:spf.example.edu.cn ~all" DKIM: 由邮件网关提供商提供(通常为 v=DKIM1; k=rsa; p=MIGf... 格式) DMARC: "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.edu.cn"第二层是强制开启邮箱和OA系统的双因子认证。这个动作能在源头上压制“内部邮箱被盗”这一类攻击。第三层是在OA系统或薪资系统上启用IP异常登录检测,例如员工常驻地是A城市,突然从异地IP登录并修改银行卡信息,触发风控提醒并自动延后生效。这些功能很多开源或自研系统都能实现,关键是想不想做,而不是有没有钱。
4. 应急响应与事后排查实录
4.1 发现“幽灵账户”后的第一步操作:冻结、追踪、留存三步走
如果工资已经发出而员工声称没收到,第一步不是急着安抚员工、也不是立刻联系银行追钱,而是按“冻结-追踪-留存”的顺序执行。冻结指的是马上冻结该员工在薪资系统内的所有变更权限,防止攻击者进一步操作;追踪是指把该员工近三个月的登录记录、银行卡变更记录、银行代发流水全部导出来比对;留存是指把相关邮件、登录日志、工资系统操作日志原样备份,避免因为后续误操作把证据覆盖掉。
我见过有的单位发现工资异常后,财务处先把员工骂了一顿,说“你自己改的卡,怎么怪学校”——这句话且不说有没有关怀问题,单从技术上就很不专业。员工操作记录可能被伪造,需要看的是日志,不是口头争执。
4.2 从邮件日志到资金流水的溯源排查路径
正确溯源路径是六步:查邮件头、查访问日志、查账号登录记录、查银行卡变更记录、查代发流水、交叉比对时间线。邮件头主要看Received链路的来源IP是否正常;访问日志看员工是否在预期时间访问过非正常域名;登录记录看是否有异地登录或凌晨登录;银行卡变更记录看变更前后的账户信息;代发流水看款项实际去向;最后把所有事件串起来比对时间,判断攻击的完整时间窗。
这里有一个容易忽略的细节:很多高校薪资系统的操作日志只记录“改了什么”,不记录“从哪里改的”,这是很大的证据缺口。我在建议里反复向高校强调,日志必须记录IP、User-Agent、会话ID三项基础信息,否则出了事后根本无法证明这笔修改是否来自员工本人设备。
4.3 常见问题速查表
为了让排查工作更顺手,我把实际处理过的类似事件整理成一个速查表,供一线财务和安全人员参考:
| 现象 | 可能原因 | 处置办法 |
|---|---|---|
| 员工称未收到当月工资 | 收款账户被替换;或银行代发失败 | 立即导出工资代发明细核对收款账号 |
| 工资卡变更记录出现在非本人提交时段 | OA账号被盗或撞库 | 强制下线所有会话,重置密码,开启双因子 |
| 邮件网关拦截率低且近期冒充邮件增多 | 域名未配置DMARC或配置为p=none | 升级DMARC策略为p=quarantine并配置rua/ruf |
| 员工点击链接但只填了姓名手机号 | 中间人攻击正在定向利用信息 | 监控近一周该手机号是否收到异常短信验证码 |
| 代发资金进入陌生账户后被快速转走 | 攻击者已进行资金分流 | 立即联系发卡行提交止付并保存代发明细 |
5. 内部案例复盘与长期意识建设
5.1 一次“零点击”钓鱼演练的尴尬结果
为了测试单位的警觉性,某高校安保团队做过一次全员钓鱼演练,发的是“2024年度绩效奖金补发明细核对”邮件,链接指向一个高仿OA登录页。演练结果显示,点击链接并输入账号密码的比例高得惊人——接近两成。更让人意外的是,有部分人在输完账号密码后,因为高仿页面的下一步加载不出来,还主动联系“技术支持”询问原因。这个细节说明两点:一是教职工对钓鱼邮件的识别能力普遍低于预期;二是演练本身如果不配套后续教育,单纯“钓鱼”只会让人尴尬,不会让人成长。
建议把这类演练做成季度固化动作,并且不只是记录“谁点了链接”,而是把点击者的后续行为纳入分析,比如有没有二次输入密码、有没有在假页面提交银行卡号、有没有主动向同事扩散。不同行为对应不同的补救动作,分别处理。
5.2 长期机制:季度演练与异常行为复盘
长期来看,单次培训解决不了结构性问题。我的建议是高校把“季度钓鱼演练+月度异常行为复盘”作为固定动作。季度演练主要针对新入职员工和高风险岗位,比如财务、人事、科研秘书;月度异常行为复盘由安全团队和财务处一起开短会,把当月所有涉及银行信息变更、批量代发异常、登录异常的事件过一遍,不管最后是否确认被攻击都要记档。
这个机制的另一个作用是积累校内自己的威胁情报。比如某个月突然出现大量仿冒“公积金调整”的邮件,这种趋势只有通过长期复盘才能被及时发现,并形成下一季度演练的素材。很多单位总在等安全厂商播报外部威胁,其实自己内部数据里的早期信号往往更有价值。
5.3 细化到人的“三问三查”制度
落到每一个岗位的,是“三问三查”:经办这笔代发业务前,问一下这个员工的银行卡号最近有没有变过、变更渠道是什么、是否有二次确认记录;代发前抽查变更名单中是否有不符合常理的户名、开户行、卡号组合。这套制度本质上不依赖技术,只依赖执行惯性,但它几乎不需要成本,却能将绝大多数“幽灵账户”拦在工资单生成之前。
我在实际推动过程中发现,阻力通常不出在制度本身,而出在跨部门协作上:财务处觉得人事处应该把关,人事处觉得技术问题该找信息中心,信息中心觉得自己只负责系统不负责流程。破解这个阻力,最好的办法不是自上而下开会,而是安全团队主动做一次“扫描”——把过去三个月工资系统中所有的银行卡变更记录拉出来,挑出几笔风险最高的(如变更后立即代发、开户行在外地、员工年龄和户名明显不符),拿给财务处看。当真实风险摆在桌面上,跨部门配合自然就顺畅了。
根据个人处理此类事件的经验,最后再分享一个很小的技巧:如果你在高校负责或参与财务安全,可以每个月固定做一次“幽灵账户体检”,从工资系统导出当前有效收款账户清单,按“户名相似度、开户行所在地、卡号合规性”做一次自动比对。写得好的查询脚本,半小时就能筛查完几千人的数据。比起等工资发出去之后才发现钱进了陌生账户,这半小时的投入实在划算。这个动作不需要很高的技术门槛,但长期坚持下来,你会比大多数人都早一步发现异常苗头。