官方公众号企业安全新浪微博
FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序
“据粉丝爆料,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站针对恶意事件爆发情况,有没有施行快速应急熔断机制?
- 来自于SIEM监控平台的其他关联告警
- 来自于邮件服务器平台病毒,沙箱告警,含且不仅含HASH, IP以及域名等
- 来自于用户的钓鱼邮件通知
- 获取受害者用户邮箱
- 获取受害者用户名
- 获取受害者主机名
- 获取受害者网络连接信息
- 获取受害者主机进程信息
- 获取受害者浏览器访问记录
- 获取钓鱼邮件的域名信誉值分析
- 获取钓鱼邮件的附件以及URL的信誉值分析
- 获取钓鱼邮件的宏分析情况
- 获取钓鱼邮件的沙盒运行状况以及截图
- 获取可疑受感染的其他用户,包括收件人,转发,回复,点击以及相关联的数据
- 关闭攻击向量,含且不仅含杀掉运行进程,残留文件,文件句柄等
- 限制网络连接,通过防火墙或者主机HIDS,进行端口限制,比如仅保留3389等端口作为调查取证备用
- 隔离主机,可通过终端控制系统,比如EDR等进行隔离阻断
- 重置用户密码
- 重置用户MFA
- 重启,关机,PE启动等
- Ban钓鱼邮件所提供的可疑域名
- Ban钓鱼邮件所提供的可疑链接
- Ban钓鱼邮件所提供的附件哈希
- Ban钓鱼邮件在沙盒中所涉及到的C2服务器IP地址
- 禁用用户账户
- 远程删除服务器上符合钓鱼邮件涉及到的相关邮件
- 提交钓鱼邮件相关IOC给安全供应商
- 检查受害者主机补丁更新情况
- 检查受害者主机防病毒以及终端控制系统EDR的启用情况
- 采用第3方防病毒程序执行全盘扫描
- 恢复用户禁用账号
- 恢复受限网络
- 重置镜像
- 用户安全意识培训以及考核
- 究竟发生了什么,在什么时候?
- 工作人员和管理层在处理事件时的表现如何?
- 什么样的信息需要最快获得?
- 是否采取了任何可能阻碍扩散的步骤或恢复行动?
- 下次发生类似事件时,工作人员和管理层会采取什么不同的做法?
- 如何改进与其他部门的信息共享?是否有通用钓鱼邮件上报渠道?
- 哪些纠正措施可以防止未来发生类似事件?
- 今后应注意哪些前兆或指标以发现类似事件?
- 需要哪些额外的工具或资源来检测、分析和缓解未来的事件?
- 是否遵循了规定的标准程序? 是否足够?
- 是否能自动化应急响应流程,从而能更快速的处置以及应对危害。
具体施行步骤我就不再赘述,每个企业的安全运营模式都有所不同,需要不同的适配工作,从而摸索出最适合本企业的最佳实践,照搬可能存在无法推进的问题,但SCF框架模型却存在可取性,不同企业也能根据这样的框架进行自问自答,不停调整和优化,从而能更加高效地快速发现,快速响应,快速恢复。