微信扫码
添加专属顾问
我要投稿
大模型如何革新威胁分析?从代码生成到深度逆向,AI正在重新定义安全研究的效率边界。 核心内容: 1. 大模型在威胁分析中的核心应用场景:从代码生成到逆向分析 2. 实战案例:Havoc C2框架的深度静态分析方法论 3. AI提示词工程在安全研究中的关键作用与最佳实践
上篇写到了AI IDE强大的代码生成能力,那不妨反向思考下大模型能够高效生成代码的同时,它在代码分析方面又具备怎么样呢?以威胁分析为例传统人工分析方法往往耗时耗力,该如何借助大模型的理解与推理能力提升分析效率呢。
首先思考下在威胁分析上我们关注哪些点,这里笔者列举几条
1.控制端/客户端生成逻辑
2.控制端/客户端通信特征
3.提取IOC的思路
4.代码中的硬编码信息
5.如何检测,以及利用空间测绘主动发现ioc
按照这个思路,利用AI生成专业的prompt。
需求:
你是一个专业的网络安全工具开发和研究专家,具备代码分析、逆向分析、协议解析和威胁狩猎实战经验。分析havoc的控制端下的每个文件中的代码,分析每个函数的作用及其调用关系,为每个函数生成功能注释,得出如下结论,控制端的代码逻辑控制端与客户端通信特征代码中的硬编码信息如何从空间测绘中提取控制端IOC的思路把分析结果输出到markdown文档。
AI生成的提示词如下:
你是一名具备实战经验的网络安全研究专家,精通C2框架逆向、Go语言分析、协议解析、加密识别与威胁狩猎。现需对 **Havoc C2 Framework** 的以下组件进行深度静态分析:
- `teamserver/`:核心服务端逻辑(Go)
- `client/`:控制端UI与本地接口(Electron + Go)
- `profile/`:通信与载荷配置模板(YAML)
- `data/`:内嵌资源(证书、脚本、图标等)
请基于源码逐文件分析,提取函数功能、调用关系,并生成结构化Markdown报告,涵盖以下九项内容。所有结论必须有代码依据,禁止推测。
---
## 一、控制端代码实现逻辑
1. **架构模式**
判断是否为事件驱动、插件化、C/S分离架构,说明并发模型(goroutine + channel)。
2. **启动流程**
从 `main()` 开始描述执行链:
`main() → LoadProfile() → StartListener() → LaunchUI() → EventLoop()`
3. **生命周期管理**
是否支持热重载、信号处理(SIGTERM)、会话持久化。
---
## 二、功能模块划分与函数调用关系
### 1. 模块划分
| 模块 | 职责 | 关键目录 |
|------|------|----------|
| 配置管理 | 加载YAML Profile | profile/ |
| 通信服务 | 监听、Beacon处理 | server/, transport/ |
| 任务调度 | 任务队列与下发 | tasking/, job/ |
| Agent管理 | 会话注册与状态 | agent/, session/ |
| 载荷生成 | Stager/Agent构建 | payload/, builder/ |
| 插件系统 | 扩展接口 | plugin/ |
| UI交互 | 前端API桥接 | api/, web/ |
### 2. 函数级分析(每模块选2-3个核心函数)
格式如下:
```go
// Function: HandleBeacon
// File: server/beacon.go:120-215
// Purpose: 处理Agent上线请求,解密载荷,更新会话,返回任务
// Params: conn net.Conn, data []byte
// Returns: error
// Calls: Decrypt(), ParseBeaconPacket(), GetPendingTasks(), Encrypt(), Write()
// Called By: acceptLoop() (goroutine)
// Concurrency: 使用session.Mutex保护
// Security: 高 - 涉及密钥使用与反沙箱逻辑
要求:分析不少于15个核心函数,覆盖通信、任务、Agent、加密等路径。
3. 调用链摘要
Agent上线链:Accept() → HandleBeacon() → Decrypt() → RegisterAgent() → SendTask()
任务下发链:UI.Input → CreateTask() → QueueTask() → EncryptTask() → Transmit()
三、网络通信协议
协议类型
WebSocket(默认路径 /ws)
自定义TCP二进制协议
HTTP(可选)
支持多协议并行?是否可配置切换?
传输特征
是否启用TLS?默认证书是否自签名?CN是否固定?
支持域前置(Domain Fronting)?Header字段(如 X-Front-Host)?
使用长连接或短轮询?Beacon间隔是否可变?
应用层协议结构
分析加密前/后的包格式:
深色版本
| Magic (4B) | Len (4B) | SessionID (16B) | Jitter (1B) | Encrypted Payload |
是否使用分块传输?任务与心跳是否同一路由?
四、加密与编码机制
1. 加密算法清单
算法 模式 用途 密钥来源
AES-256 GCM 任务与Beacon加密 Profile配置或硬编码
ChaCha20 IETF Agent通信(低延迟场景) 动态协商或PSK
XOR 自定义 载荷混淆 固定种子
2. 密钥管理
是否使用预共享密钥(PSK)?
是否支持ECDH(如X25519)密钥交换?
密钥是否绑定Session?生命周期?
3. 编码与混淆
Base64、Hex、Gzip使用场景
是否使用自定义Base64表?
载荷是否分段、延迟解密、反射加载?
五、客户端与服务端通信流程与特征
1. 通信流程
Agent启动 → 连接C2地址(来自Profile)
发送Beacon(含主机信息)
Teamserver解密 → 验证 → 分配Session
Agent周期拉取任务(间隔 + Jitter)
执行任务 → 加密结果 → 回传
Teamserver解密 → 显示至UI
2. 可检测特征
类型 示例 可变性
URI路径 /beacon, /ws, /task 可配置
User-Agent Havoc-Agent/v1.0 可伪装
HTTP方法 POST为主 固定
TLS指纹 JA3: 771,4865,107... 若使用默认库
包大小 Beacon <512B,任务可变 可调
时间模式 定时Beacon + Jitter(默认5s±20%) 可配置
六、配置文件分析(profile/*.yaml)
是否加载配置?
是,使用YAML格式(profile/default.yaml),支持命令行指定。
可配置参数清单
| 参数 | 默认值 | 说明 |
|------|--------|------|
| server.host | 0.0.0.0 | 监听地址 |
| server.port | 4444 | 监听端口 |
| server.domain_front | "" | 域前置域名 |
| beacon.interval | 5000 | 心跳间隔(ms) |
| beacon.jitter | 20 | 抖动百分比(%) |
| crypto.aes_key | "DefaultAesKey123!" | AES密钥 |
| payload.user_agent | "Havoc-Agent/v1.0" | Agent UA |
⚠️ 注:即使可配置,若默认值广泛使用,仍构成有效IOC。
七、硬编码信息(Hardcoded Artifacts)
列出所有源码或data/中明文出现的静态值:
类型 值 位置
默认密钥 "DefaultAesKey123!" crypto/aes.go
Magic Bytes 0xDEADBEEF transport/packet.go
字符串标识 "Havoc Session Established" agent/session.go
内嵌证书 server.pem, server.key data/certs/
图标资源 havoc.ico data/icons/
脚本模板 loader.js, shellcode.asm data/scripts/
✅ 建议:提取data/所有文件的SHA256作为文件级IOC。
八、空间测绘与IOC提取思路
1. 主动扫描
扫描端口:4444, 7777, 8888, 8080
探测路径:/beacon, /ws, /task
抓取响应:
HTTP Header(Server, UA, Set-Cookie)
Body特征字符串
TLS证书(CN, Issuer)
JA3S指纹
2. 被动情报
GitHub搜索:filename:*.yaml "c2:" site:github.com
恶意样本回连日志(VirusTotal, ANY.RUN)
域名注册信息(Whois)关联
3. IOC生成建议
输出可用于SIEM/SOC的检测规则模板:
Suricata 示例:
suricata
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Havoc C2 Beacon";
http.uri; content:"/beacon"; http.method; content:"POST";
http.user_agent; content:"Havoc-Agent"; nocase;
sid:2025081001; rev:1;)
YARA 示例:
yara
rule Havoc_C2_Server {
strings:
$key = "DefaultAesKey123!" ascii
$path = "/beacon" ascii
$ua = "Havoc-Agent" ascii
condition:
all of them
}
Sigma 示例:
yaml
detection:
c2:
method: POST
uri: /beacon
user_agent: Havoc-Agent
condition: c2
九、最终输出要求
生成一份结构清晰的Markdown报告:
markdown
# Havoc C2 全栈分析报告
## 1. 架构与执行逻辑
## 2. 模块划分与函数调用
### 2.1 模块地图
### 2.2 核心函数注释(≥15个)
### 2.3 调用链
## 3. 通信协议
## 4. 加密机制
## 5. C2通信流程与特征
## 6. 配置系统分析
## 7. 硬编码IOC清单
## 8. 空间测绘与IOC提取
## 9. 检测规则建议(Suricata/YARA/Sigma)
## 10. 附录:data资源哈希表
要求:语言专业,引用文件与行号,IOC可操作,适合蓝队、威胁情报团队使用。
根据这份信息,我们看下trae生成的结果。
可以看到关于项目的分析内容比较详细,对于威胁情报的提取很有价值。看完这个文档后,可以从几个维度做威胁情报提取,首先了解下agent和server的上线过程。提示词如下:
从代码侧分析下C2通信的流程,大概包含以下维度
1. Agent启动时和C2地址如何建立连接
2. 发送主机的哪些信息
3. Teamserver如何解密客户端发送的内容
4. 这个过程agent发送的内容具体有哪些,然后teamserver进行验证的方式,加解密用的密钥是啥,以及最后返回的Payload的内容有哪些。
返回的分析结果如下。
Beacon中提供的32字节AES密钥和16字节AES IV 具体是什么字符,在那端代码中实现
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-08-21
2025-05-29
2025-06-01
2025-06-21
2025-06-07
2025-06-12
2025-08-19
2025-06-19
2025-06-13
2025-05-28
2025-08-22
2025-08-22
2025-08-21
2025-08-20
2025-08-19
2025-08-19
2025-08-18
2025-08-18