一次情报更新引发的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告警？

文章目录

共享镜像排查

理论上来说这种内网不提供服务的机器不应该会触发这类告警。所以第一时间让客户做好镜像共享过来，重新生成实例进行排查。这也是云上应急最快捷高效的处理办法。

C:\Windows\System32\wbem\scrcons.exe

先分析被告警的进程是Windows的合法进程，推测可能是被注入或者是其他恶意进程调用该进程触发的请求。经过查询得知：

scrcons.exe（Script Consumers）是Windows系统的合法组件，位于%SystemRoot%\system32\wbem\scrcons.exe，作为WMI标准事件消费者的脚本宿主进程。其正常用途是响应WMI事件触发器执行预定义的VBScript或JScript脚本，支持系统自动化管理任务。

所以推测大概率是通过WMI调用去执行的。

everything全盘扫描恶意域名关键字

这里用到了一个trick，由于告警信息中没有提供更多的父子进程链信息，所以没法直接定位到相关的恶意进程或文件。经过上面的分析，由于WMI调用执行的是VBScript或JScript脚本。这类恶意代码通过明文保存的，采用全盘暴力搜索的方式进行排查。

everything是支持在文件中搜索，使用content的语法。

content:mymst007.info

直接搜索包含恶意域名的文件，定位到C:\Windows\System32\wbem\Repository\OBJECTS.DATA。使用notepad++打开并搜索恶意域名。

在WMI的对象文件中存储了恶意VBscript脚本的内容。

WMI的“计划任务”？

由于只是镜像了客户的机器进行分析，所以仍然保留了原始告警的主机，没有关机只做断网隔离。经过观察在第二天同样的时间点还是触发了同样的告警，基本就能确定是使用WMI自身的机制实现持久化。

在这个应急案例中攻击者创建了：

消费者名称: ASEventConsumerdr
脚本引擎: VBScript
命名空间: root\subscription

为什么计划任务要加引号？实际WMI本身没有计划任务的概念。

WMI事件订阅 = 事件监听器 + 响应机制

事件驱动: 响应系统事件，而非基于时间调度
实时监控: 持续监听系统状态变化
条件触发: 当满足特定条件时执行操作

恶意软件如何”滥用”WMI实现类似计划任务？恶意软件通过监控 Win32_LocalTime 类的变化来实现定时触发。所以看起来像是计划任务，实际上是时间触发器。WMI本身没有计划任务，但可以被滥用实现类似功能。

WMI目录结构分析

C:\Windows\System32\wbem\就是WMI的核心目录，包含：

可执行文件：WMI 服务和工具
配置文件：WMI 的配置信息
日志文件：WMI 运行日志
MOF 文件：管理对象格式文件

重要的子目录和文件：

C:\Windows\System32\wbem\
├── winmgmt.exe          # WMI 服务主程序
├── wmiprvse.exe         # WMI 提供程序宿主进程
├── wbemcore.dll         # WMI 核心库
├── wmic.exe             # WMI 命令行工具
└── Repository\          # WMI 数据库目录

存储库目录：

C:\Windows\System32\wbem\Repository\
├── OBJECTS.DATA         # WMI 对象数据
├── INDEX.BTR           # 索引文件
└── MAPPING1.MAP        # 映射文件

所以之前通过scrcons.exe推断可能是WMI，和everything检索出来的object.data所在的目录就是WMI的目录，也就完全对应的上了。

WMI持久化检测

WMI持久化需要三个关键组件协同工作：

Event Filter (事件过滤器)
       ↓
FilterToConsumerBinding (绑定关系)
       ↓
Event Consumer (事件消费者)

这里使用powershell脚本检测。

# 完整的WMI持久化检查脚本
function Get-WMISubscriptionDetails {
    Write-Host "=== WMI事件订阅完整分析 ===" -ForegroundColor Yellow
    
    # 获取所有组件
    $Filters = Get-WmiObject -Namespace root\subscription -Class __EventFilter
    $Consumers = Get-WmiObject -Namespace root\subscription -Class __EventConsumer
    $Bindings = Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
    
    Write-Host "`n=== 事件过滤器 (共$($Filters.Count)个) ===" -ForegroundColor Cyan
    foreach ($filter in $Filters) {
        Write-Host "名称: $($filter.Name)" -ForegroundColor Green
        Write-Host "查询: $($filter.Query)" -ForegroundColor White
        Write-Host "创建时间: $($filter.CreationDate)" -ForegroundColor Gray
        Write-Host "---"
    }
    
    Write-Host "`n=== 事件消费者 (共$($Consumers.Count)个) ===" -ForegroundColor Cyan
    foreach ($consumer in $Consumers) {
        Write-Host "名称: $($consumer.Name)" -ForegroundColor Green
        Write-Host "类型: $($consumer.__CLASS)" -ForegroundColor Yellow
        if ($consumer.ScriptText) {
            Write-Host "脚本内容: $($consumer.ScriptText.Substring(0, [Math]::Min(200, $consumer.ScriptText.Length)))..." -ForegroundColor Red
        }
        if ($consumer.CommandLineTemplate) {
            Write-Host "命令行: $($consumer.CommandLineTemplate)" -ForegroundColor Red
        }
        Write-Host "---"
    }
    
    Write-Host "`n=== 绑定关系 (共$($Bindings.Count)个) ===" -ForegroundColor Cyan
    foreach ($binding in $Bindings) {
        # 获取过滤器和消费者的名称
        $FilterPath = $binding.Filter
        $ConsumerPath = $binding.Consumer
        
        # 解析路径获取名称
        if ($FilterPath -match 'Name="([^"]+)"') {
            $FilterName = $matches[1]
        }
        if ($ConsumerPath -match 'Name="([^"]+)"') {
            $ConsumerName = $matches[1]
        }
        
        Write-Host "过滤器: $FilterName -> 消费者: $ConsumerName" -ForegroundColor Magenta
        Write-Host "完整绑定: $($binding.__RELPATH)" -ForegroundColor Gray
        Write-Host "---"
    }
}

Get-WMISubscriptionDetails

检测到恶意的WMI并显示对应的VBscrip脚本。

触发流程如下：

23:00:00 系统时间变化
         ↓
EFNMdr过滤器检测到时间匹配
         ↓
触发FilterToConsumerBinding
         ↓
执行MYASECdr消费者
         ↓
运行恶意VBScript代码

清除可疑的WMI持久化

找到恶意的事件消费者后，就可以指定进行删除。

# 删除23点触发的核心绑定
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | 
Where-Object {$_.Filter -match "EFNMdr" -and $_.Consumer -match "MYASECdr"} | 
Remove-WmiObject -Verbose

# 删除恶意事件过滤器
Get-WmiObject -Namespace root\subscription -Class __EventFilter | 
Where-Object {$_.Name -eq "EFNMdr"} | 
Remove-WmiObject -Verbose

# 删除恶意事件消费者
Get-WmiObject -Namespace root\subscription -Class ActiveScriptEventConsumer | 
Where-Object {$_.Name -eq "MYASECdr"} | 
Remove-WmiObject -Verbose

分析真实入侵时间

分析该恶意代码发现在 Windows 的 temp 目录下会写入日志文件。

但对应日志文件的创建时间为 2019 年 10 月 21 日，但是该机器的创建时间为 2022 年，所以排除该机器被入侵的可能性。通过确认该主机是由以前旧的镜像创建，所以以前的镜像就已经存在安全问题。

情报更新导致的告警？

回到这个事件本身，为什么会突然触发告警。

这个是微步的情报，目前仍然没有将该域名拉黑。

但是被腾讯的威胁情报给拉黑。

结合具体的情况分析，这台机器其实几年前就已经被入侵了。恶意域名的请求每天都有被触发，只不过腾讯的威胁请求近期已将其拉黑，所以主机安全才会触发恶意 DNSLOG 告警。

Post Views: 76

赞赏

微信赞赏支付宝赞赏

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