一次情报更新引发的DNSLOG告警排查

【标题】:xxxxx 发现 DNS 恶意请求
【客户名称】:xxxxxxx
【风险等级】:高
【告警时间】:2025-06-12 
【事件类型】:恶意请求行为
【受影响资产】:xxxxxxx 【详情】:[机器:xxxxxxx，请求恶意域名:mst2.mymst007.info，进程: C:\Windows\System32\wbem\scrcons.exe，请求次数:5，首次请求时间:2025-06-12 23:03:43， 最近请求时间:2025-06-12 23:03:43]

最近MSS运营中收到一条主机安全的告警，某客户的机器触发DNSLOG告警。但是这台机器本身也不提供服务，也没有公网ip，甚至已经很长时间都没人登录过，查看记录已经稳定运行几年时间了。这样的机器为什么会突然产生DNSLOG告警？

在应急排查现场，大家最怕的一类情况不是“清晰的恶意域名或 IP”，而是那种表面看起来一切正常的 HTTPS 流量 —— 仿佛业务流量，背后却藏着恶意的 C2 控制信道。当我们看到流量是云厂商 CDN、证书合法、访问域名看起来也没有问题的时候，应急人员的第一反应往往是：

“不会吧，这些都是正经的 CDN 域名，怎么可能是恶意的？”

但事实证明，攻击者正是利用了 CDN 这种“可信流量”的特性来隐藏自己的控制通道，这种技术被称为域前置（domain fronting）。

恶意软件（Malware）的定义很宽泛：凡是在计算机系统上执行非预期行为的软件，都可以归入这个范畴。破坏系统功能、窃取敏感数据、获取未授权访问权限、强制展示广告……这些都算。”病毒”只是其中一种形态，用它来代指所有恶意软件，就像用”感冒”来描述所有疾病一样，早就不够用了。

DFIR，全称 Digital Forensics and Incident Response（数字取证与事件响应），可以拆成两部分来理解：

• 数字取证（Digital Forensics）：对网络犯罪、攻击行为和安全事件相关证据进行收集、检验与保全的过程；
• 事件响应（Incident Response）：在检测到安全入侵后，快速隔离事件、恢复系统的响应流程。

两者合在一起，就构成了处置安全事件的完整闭环——确定损害范围、还原攻击路径、溯源攻击者身份，并提供防止类似事件再次发生的关键情报。

经过对B004镜像服务器深入排查，基本确定黑客通过IIS viewstate反序列化漏洞获取服务器初始权限，进一步植入恶意dll加载到IIS内存，实现网站劫持和后门通信。黑客使用ccprotect驱动实现恶意dll和驱动文件的隐藏。

在真实的安全运营场景中，我们往往是在“事情已经发生之后”才介入：告警触发、业务异常、用户反馈异常登录……随后启动应急响应流程。但随着攻击手段的不断演进，仅靠这种被动响应的方式，已经越来越难以应对复杂攻击。

威胁狩猎，正是在这种背景下逐渐成为安全运营体系中不可或缺的一环。

在实际的应急响应和安全事件调查中，USB 几乎永远是一个“被低估的风险点”。USB 不需要复杂的攻击链，也不依赖网络通信。它只需要一次短暂的插入，就足以完成数据拷贝、恶意程序执行，甚至规避绝大多数网络侧的安全监控。也正因为如此，在涉及数据泄露、内部威胁、可疑文件访问等场景时，USB 取证往往不是“可选项”，而是必须纳入调查范围的核心环节。