利用Splunk查找表加速检测工程开发

概述

本文介绍如何通过Splunk查找表(Lookups)技术快速实现基于字符串匹配的新型检测规则开发。例如当检测到"dump /service:krbtgt"这类命令时立即触发告警。虽然检测即代码(Detection-as-code)的部署可能减少此类需求，但实践表明基于字符串搜索的新规则部署周期仍然过长。

背景

典型的新规则开发流程包括：阅读威胁报告、识别TTP独特实现方式、创建或获取规则（如从Sigma规则库获取）。即使采用检测即代码模式，这个过程仍可能非常冗长，最终导致管理数百个本质上只是字符串标识的检测规则。

解决方案 - 使用查找表

Splunk查找表本质上是CSV格式的表格，用于存储需要检测的目标数据。我们将现有的IOC威胁匹配机制扩展到包含字符串片段（如mimikatz），并指定目标字段（如command字段）。

Sigma规则示例

以这个检测命令行参数的Sigma规则为例，所有关注点都是CommandLine字段中的特定字符串。我们需要将此类简单Sigma规则转换为CSV结构。

查找表示例

示例查找表包含以下关键字段：

l_field：目标字段名
l_value：待检测值（支持通配符）
l_description/l_name：规则描述/名称
l_references：调查参考信息
l_severity：风险严重等级（可用于基于风险的分析）

Splunk搜索应用方法

有三种使用查找表的SPL搜索方法，各有效能差异：

方法1：先使用inputlookup子搜索的Tstats

1
2
3
4
5
6
7
8


| tstats summariesonly=true c from datamodel="Endpoint.Processes" 
where `rule_tuning_macro` 
[|inputlookup string_indicator_lookup | rename l_value as Processes.process | fields Processes.process] 
by _time Processes.process Processes.user host
| rename Proceses.* as *
| eval lookup_field="command"
| eval lookup_value=process
| lookup string_indicator_lookup l_field as lookup_field l_value as lookup_value

缺点：随着查找表增大，inputlookup命令在索引器上的执行会变慢。

方法2：先获取全部数据再查找

1
2
3
4
5


| tstats summariesonly=true c from datamodel="Endpoint.Processes" where `rule_tuning_macro` by _time Processes.process Processes.user host
| rename Proceses.* as *
| eval lookup_field="command"
| eval lookup_value=process
| lookup string_indicator_lookup l_field as lookup_field l_value as lookup_value

缺点：需要先将所有命令加载到内存，大数据量时性能较低。

方法3：非数据模型数据的双重查找

1
2
3
4
5
6


{{YOUR DATA}}
| eval lookup_field="command"
| eval lookup_value=command
| search
[|inputlookup string_indicator_lookup | eval search=l_value |fields search | format ]
| lookup string_indicator_lookup l_field as lookup_field l_value as lookup_value

通过两次查找减少数据集规模，但未使用加速数据模型。

进阶方向

使用分隔符减少重复条目
添加父进程等附加检测条件
在查找表中存储Sigma逻辑（如ANY/ALL）
探索在数据摄入时进行实时模式匹配

结论

虽然查找表方案在规模增长后可能效率下降，但其核心价值在于大幅缩短从威胁报告到实际检测的响应时间。该方法显著降低了基于字符串检测规则的开发复杂度和实施周期。