“据粉丝爆料，1月5日凌晨，X站公司内部邮件发了全员钓鱼链接，多位同事中招，受骗金额总计8万左右。从5日凌晨2点到下午1点IT才把钓鱼邮件删除完。内部没有发全员邮件告知，导致不断有人受骗。在员工接连受骗的情况下没有第一时间通知全员。全员邮件也不发一个，一分钱赔偿也没有。”
而从该微博内容附件的图片显示，受害员工成立了“钓鱼邮件受害者”群，目前群内有72人，有X站受骗员工咨询相关部门HR得到的回复是，建议同事自行报警。群内部分员工认为，“从企业邮箱发出来的邮件导致员工受骗，难道企业不应该承担后续责任吗？”更有员工称“钱我没追回来，但是做做样子报案，说点啥也好呀。”、“但公司一点责任都不想付。”
我觉得这个Case挺有教育价值，拿来跟大家简单分享一下，同时也给我们自己提出一个问题，如果是我们遭遇这种攻击，我们的应急响应支撑模型是否足够做到快速响应？我们不说高大上的所谓的应急预案，我们需要能落地实行，能帮助我们SOC工程师进行快速响应，快速定位的具体步骤提案。
针对SCF（Security Control Framework）框架下的应急响应步骤，我更倾向于SANS的这一套，即PICERL流程，针对X站的钓鱼邮件，我们尝试通过建模应对该钓鱼邮件的应急响应流程。
建模之前，需要先针对性的提出一些问题，并围绕该问题进行解决才有实际落地的意义：
- 用户邮箱，密码泄露，泄露来源来自于其他钓鱼邮件？
- X站用的是Exchange Online，邮箱OWA登录有没有MFA启用？
- 如果为第3方邮箱发送，SPF/DKIM/DMARC怎么绕过的？（不在本案讨论范围）
- 邮件中含有繁体字眼，员工怎么如此容易中招？有否定期做钓鱼邮件安全意识培训？
- X站钓鱼邮件检测机制是否有优化的可能？
- X站钓鱼邮件应急处置是否有钓鱼邮件上报途径？
- X站钓鱼邮件删除工作，持续了大约11个小时，是否有改善基础？
- X站针对恶意事件爆发情况，有没有施行快速应急熔断机制？
Identification，检测
- 来自于SIEM监控平台的其他关联告警
- 来自于邮件服务器平台病毒，沙箱告警，含且不仅含HASH, IP以及域名等
- 来自于用户的钓鱼邮件通知
Analysis，分析
- 获取受害者用户邮箱
- 获取受害者用户名
- 获取受害者主机名
- 获取受害者网络连接信息
- 获取受害者主机进程信息
- 获取受害者浏览器访问记录
- 获取钓鱼邮件的域名信誉值分析
- 获取钓鱼邮件的附件以及URL的信誉值分析
- 获取钓鱼邮件的宏分析情况
- 获取钓鱼邮件的沙盒运行状况以及截图
- 获取可疑受感染的其他用户，包括收件人，转发，回复，点击以及相关联的数据
Containment，控制
- 关闭攻击向量，含且不仅含杀掉运行进程，残留文件，文件句柄等
- 限制网络连接，通过防火墙或者主机HIDS，进行端口限制，比如仅保留3389等端口作为调查取证备用
- 隔离主机，可通过终端控制系统，比如EDR等进行隔离阻断
- 重置用户密码
- 重置用户MFA
- 重启，关机，PE启动等
Eradication，消除
- Ban钓鱼邮件所提供的可疑域名
- Ban钓鱼邮件所提供的可疑链接
- Ban钓鱼邮件所提供的附件哈希
- Ban钓鱼邮件在沙盒中所涉及到的C2服务器IP地址
- 禁用用户账户
- 远程删除服务器上符合钓鱼邮件涉及到的相关邮件
- 提交钓鱼邮件相关IOC给安全供应商
Recovery，恢复
- 检查受害者主机补丁更新情况
- 检查受害者主机防病毒以及终端控制系统EDR的启用情况
- 采用第3方防病毒程序执行全盘扫描
- 恢复用户禁用账号
- 恢复受限网络
- 重置镜像
- 用户安全意识培训以及考核
Lesson Learned，反思
- 究竟发生了什么，在什么时候？
- 工作人员和管理层在处理事件时的表现如何？
- 什么样的信息需要最快获得？
- 是否采取了任何可能阻碍扩散的步骤或恢复行动？
- 下次发生类似事件时，工作人员和管理层会采取什么不同的做法？
- 如何改进与其他部门的信息共享？是否有通用钓鱼邮件上报渠道？
- 哪些纠正措施可以防止未来发生类似事件？
- 今后应注意哪些前兆或指标以发现类似事件？
- 需要哪些额外的工具或资源来检测、分析和缓解未来的事件？
- 是否遵循了规定的标准程序？ 是否足够？
- 是否能自动化应急响应流程，从而能更快速的处置以及应对危害。
具体施行步骤我就不再赘述，每个企业的安全运营模式都有所不同，需要不同的适配工作，从而摸索出最适合本企业的最佳实践，照搬可能存在无法推进的问题，但SCF框架模型却存在可取性，不同企业也能根据这样的框架进行自问自答，不停调整和优化，从而能更加高效地快速发现，快速响应，快速恢复。
（来源：freebuf）
.jpg)
.png)
发表评论