本案例来自一家大型企业客服服务中心的安全负责人。该服务中心承接了集团多个业务条线的客户服务工作,日均服务量超过 10 万通,拥有完整的信息安全防护体系,包括 SIEM、EDR 等多层次安全设施。
事件概述
2023 年 12 月,安全团队发现了一起针对客服信息系统的供应链攻击。攻击者通过获取某客服系统维护供应商的账号潜入内网,利用合法身份和正常运维行为作为掩护。
在长达 78 天的攻击过程中,试图获取客服知识库和质检系统的访问权限。虽然期间产生了超过 2000 条相关告警,但由于种种原因,这些告警未能引起足够重视,直到春节假期前的例行安全巡检才最终发现异常。
▌看似完美的防御体系
-
当攻击者首次通过 VPN 登录时,SIEM 产生了"低危"告警,因为登录源 IP 来自可信供应商网段,使用了合法的 VPN 通道。 -
三周后,当这个账号在深夜执行 PowerShell 命令时,EDR 再次告警,但因为都是系统管理常用命令,而且临近系统升级窗口,告警再次被标记为"可忽略"。 -
直到春节假期前的例行安全巡检,我们才发现这个账号在尝试访问客服知识库和质检系统的异常行为。
▌现代攻击者的精妙策略
# 传统告警判断的致命弱点
def is_suspicious(event):
if event.source in trusted_sources and
event.credentials.valid and
event.behavior.matches_normal_ops:
return False # 看似合理的判断实则经不起推敲
return True
现代攻击者早已洞悉这种简单逻辑的盲区。他们不再硬闯防火墙,而是耐心寻找并利用被信任的身份与通道;不再留下明显的恶意程序痕迹,而是完美模仿正常运维行为。 ▌响应体系的"碎片化"困境
更令人担忧的是告警信息的分散。在这起案例中,一些关键但被忽视的信号包括:
-
timing: "非维护窗口的系统访问" -
access: "首次访问非授权系统" -
operation: "异常的权限探测行为" -
location: "非常规 IP 地址段访问"
▌破局实践:从理想到现实
-
老系统的日志质量普遍较差,关键信息经常缺失 -
不同系统的时间戳标准不一,造成关联分析困难 -
存储成本压力大,完整的审计日志动辄就是 TB 级别
-
最初想把规则定得很细,结果告警量剧增,误报率居高不下 -
后来先把明显的误报过滤掉,告警量直接降了 60% -
经过持续调优,总算把有效告警率从 10%提升到了 30%
-
约 20%的供应商账号状态不明确,权限来源和负责人都需要重新确认 -
部分账号权限过大,存在明显的安全隐患 -
权限收敛工作推进困难,需要平衡安全性和业务效率
-
首要响应人的确定 -
清晰的升级路径 -
各部门协作机制
-
人力资源紧张,特别是在 7x24 响应机制的落实上 -
老旧系统的技术债务较重 -
跨部门协作效率仍需提升
▌塞讯验证:以持续验证重塑事件响应
-
定期进行全面的能力评估 -
及时发现新的攻击手法并验证防护效果 -
结合实战经验不断优化响应策略 -
建立安全知识库促进经验在企业内沉淀
原文始发于微信公众号(塞讯安全验证):一起隐匿 78 天的供应链攻击揭示的事件响应困境
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论