告警研判方法论：威胁定性六分类与研判流程

为什么需要”威胁定性”

在态势感知平台或 SIEM 中，平台发现一条告警后，需要结合访问行为、资产信息、日志、响应结果等证据，判断该事件属于哪一种威胁类型。

很多新人拿到告警只会回答”有攻击”，但上级和客户真正要问的是三件事：

  1. 这是什么性质的威胁（定性）
  2. 攻击到什么程度了（定级）
  3. 下一步怎么办（处置建议）

威胁定性就是把第一个问题标准化。经过一段时间的驻场研判实践，我把常见告警归纳为六类。

这是一套工作记录口径，不是通用标准，也不是互斥分类。扫描器同样可能深入利用，人工测试也会使用自动化工具；工具特征只能提供线索，不能单凭请求频率判定操作者身份。记录时应分别标注行为方式、风险根因、利用结果和置信度，证据不足就保留待确认状态。

六类威胁速览

分类 核心判断 常见关键词
人工渗透 有人手工、连续、有目的地深入攻击 试探、绕过、利用链、提权、Getshell
扫描器攻击 工具自动化、批量、高频探测 字典、POC、Nuclei、sqlmap、批量请求
病毒 主机已出现恶意代码或恶意通信 木马、C2、挖矿、勒索、蠕虫、WebShell
业务不规范 业务设计、接口权限或流程存在问题 越权、无鉴权、接口暴露、频控缺失
脆弱性风险 组件、系统或配置存在漏洞和弱点 CVE、弱口令、未授权、过期版本、危险端口
其他 正常行为、误报或暂时无法分类 爬虫、监控、运维、第三方回调、证据不足

1. 人工渗透

定义：攻击者、渗透测试人员或红队对目标进行有目的的手工探测、漏洞验证、权限绕过和进一步利用。

区别于扫描器的主要特征：行为具有连续性和针对性——攻击者会根据前一个请求的响应结果调整后续操作。

典型例子：

场景 示例行为
SQL 注入手工测试 id=1' and 1=1--、id=1' and sleep(5)--
文件上传绕过 先传 .jpg，再尝试 .phtml、双后缀、改 Content-Type
WebShell 探测 访问 /upload/shell.php?cmd=whoami
越权验证 修改 userId、orderId、fileId 尝试访问他人数据

定性建议：如果能看到攻击者在根据返回结果不断试错、绕过、深入利用，定性为人工渗透。若已确认利用成功（执行命令、后台权限、WebShell 落地），升级为入侵事件。

2. 扫描器攻击

定义：使用 AWVS、Nessus、Nmap、Nuclei、Xray、Yakit、sqlmap 等自动化工具做批量探测、指纹识别、目录扫描或漏洞验证。

常见特征：

  • 短时间大量请求，路径呈字典化、模板化特征
  • User-Agent / 请求头带工具特征
  • 同时测多种漏洞类型
  • 可能出现 DNSLog、OOB 回连等自动化验证行为

定性建议：机器自动化、高频、批量探测，没有深入利用证据时，可以记录为扫描器攻击。扫描后如果出现绕过或权限获取，应补充利用阶段和成功证据，不能仅据此认定为人工操作。

3. 病毒（广义恶意代码）

态势感知语境下的”病毒”是广义概念，包括木马、蠕虫、勒索软件、挖矿程序、后门、僵尸网络、WebShell 和其他恶意代码。

定性建议：重点是主机已经疑似感染——恶意进程、C2 通信、挖矿、勒索、异常传播。这类事件应结合终端、进程、文件、网络连接和威胁情报进一步确认。

4. 业务不规范

定义：系统在业务设计、接口开发、权限控制、运维流程或安全配置上存在不合理之处，导致安全风险或触发告警。不一定是外部攻击造成的。

典型例子：

场景 示例
Swagger 暴露 /swagger-ui.html、/v2/api-docs 直接可访问
Actuator 暴露 /actuator/env、/actuator/heapdump 对外开放
越权访问 改 userId=2 能看别人资料
接口无频控 登录、短信、查询接口可被高频调用
验证码不规范 固定、可复用、无失败次数限制

定性建议：根因是业务流程、接口权限、开发规范或运维配置不完善 → 业务不规范。即使没有攻击者利用，也应作为业务安全问题记录。

5. 脆弱性风险

定义：系统、中间件、开源组件、操作系统或安全配置存在已知漏洞、弱配置或可被利用的缺陷。不一定代表已经遭受攻击。

典型例子：存在 CVE 的组件版本、Redis/MongoDB 未授权、弱口令、高危端口暴露、.git/config 可下载。

注意区分三个层次：

  • 只发现漏洞存在 → 脆弱性风险
  • 发现有人正在利用 → 攻击行为
  • 确认利用成功并控制主机 → 入侵事件

6. 其他

正常行为、误报、监控行为、第三方回调等。”其他”不应成为无法判断告警的默认分类——使用时必须记录具体原因（爬虫/监控/运维/规则误报/证据不足）。

推荐的研判流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
收到告警
   ↓
确认源 IP、目的资产、时间、请求路径和 Payload
   ↓
判断是否为正常监控、运维或第三方业务行为
   ↓
判断是否存在自动化批量扫描特征
   ↓
判断是否存在人工试探、绕过和深入利用特征
   ↓
判断主机是否出现恶意程序、C2 或感染迹象
   ↓
判断是业务设计问题，还是组件/配置漏洞
   ↓
确认是否利用成功、是否造成影响
   ↓
完成威胁定性、风险等级和处置建议

判断优先级：先核查是否存在主机失陷、恶意代码或正在造成影响的行为，紧急情况优先处置；再排除正常业务和误报，分析行为方式与风险根因。流程是证据收集框架，不应把感染核查机械地放到最后。

定性时要记录的证据

每条告警至少记录：

  • 发生时间、源/目的 IP 和端口
  • 资产名称、类型和业务重要性
  • 请求方法和访问路径、关键 Payload
  • HTTP 状态码和响应内容
  • 请求频率及持续时间、User-Agent
  • 是否存在成功响应、命令执行、文件写入或回连证据
  • 是否关联其他主机、账号或告警
  • 最终定性及定性依据

一个定性记录示例：

1
2
3
4
5
6
7
8
威胁定性：扫描器攻击
攻击类型：SQL 注入扫描
源 IP：外部地址
主要证据：10 分钟内访问 86 个接口，Payload 具有 sqlmap 特征，
         返回状态码均为 403，未发现数据库报错、数据返回或命令执行证据
研判结论：确认存在自动化扫描行为，暂未确认漏洞利用成功
处置建议：封禁或限速源 IP，检查 WAF 命中情况，核查相关接口是否存在 SQL 注入
置信度：高

一句话记忆

人在打：人工渗透；工具扫：扫描器攻击；主机中毒：病毒；业务设计有问题：业务不规范；组件或配置有洞：脆弱性风险；正常行为、误报或判断不了：其他。

本文整理自驻场安全服务期间的研判实践与知识沉淀，具体分类名称和边界可能因单位、平台或项目规范不同而有差异——实际研判时，以现场证据和本单位定性标准为准。