SuperAPI AI Directory

ioc-analysis

Security & auditing

View repository

Updated 10-16 04:41

About this skill

IOC Analysis and Countermeasures

Red Team Positioning: Understand how the blue team tracks you → design short-lived, unlinkable infrastructure

⛔ In-Depth Reference


IOC Pyramid (Pyramid of Pain)

难以更换                     防御者价值高
   ▲
   │  TTPs(战术/技术/过程)      ← 最难改变
   │  工具特征(Imphash/YARA)    ← 需重新编译
   │  网络/主机 Artifact          ← 需改行为模式
   │  域名                        ← 需新注册
   │  IP 地址                     ← 最容易换
   │  哈希值                      ← 改一字节即变
   ▼
容易更换                     防御者价值低

Red Team Strategy: Ensure your own IOCs are at the bottom of the pyramid (easy to replace), and avoid exposing the top (TTPs are immutable)

Part A: Blue Team Perspective — IOC Collection and Analysis

IOC Types

Type Example Collection Source
File Hash MD5/SHA256 Endpoint/Sandbox/VirusTotal
IP Address C2 Server IP Network Logs/PCAP
Domain C2/Phishing Domain DNS Logs/Certificate Transparency
URL/URI C2 Path Proxy Logs/HTTP Logs
Email Sender/Attachment Name Email Gateway
Registry Persistence Key Values Endpoint Detection
Process Process Name/Command Line EDR/Sysmon
File Path Malicious File Location Endpoint Detection
Certificate SSL Certificate Hash JA3/JARM
Network Signature JA3/JA3S/JARM Traffic Analysis

IOC Enrichment Process

原始 IOC → 富化 → 关联
├─ 文件哈希 → VirusTotal/MalwareBazaar → 家族/来源/关联样本
├─ IP → Shodan/Censys/GreyNoise → 服务/端口/历史
├─ 域名 → PassiveDNS/Whois/CT Logs → 注册信息/关联域
├─ 证书 → crt.sh/Censys → 关联域名/IP
└─ JA3 → JA3er → 客户端指纹识别

Part B: Red Team Perspective — IOC Countermeasures

Strategy 1: Infrastructure Separation and Rotation

C2 基础设施设计原则:
├─ 分层架构:
│   攻击者 → Redirector(多个/轮换) → TeamServer(隐藏)
│   被发现的只是 Redirector → 换一个 IP 即可
│
├─ 域名策略:
│   ├─ 注册 30 天以上的域名(新域名有风险评分)
│   ├─ 使用合法分类的域名(非新注册/非恶意分类)
│   ├─ 域前置(Domain Fronting)→ CDN 背后真正的 C2
│   └─ 使用被接管的合法子域名(更可信)
│
├─ IP 策略:
│   ├─ 使用云服务商 IP(AWS/Azure/GCP)→ 难以封锁
│   ├─ 每次行动新建 VPS → 不复用 IP
│   └─ 使用 CDN/反代 → 隐藏真实 IP
│
└─ 证书策略:
    ├─ 使用 Let's Encrypt 证书(最常见,不突出)
    ├─ 或购买与目标同类的商业证书
    └─ ⛔ NEVER 使用自签名证书 → JA3S/JARM 特征明显

Strategy 2: Tool Signature Elimination

文件级 IOC 对抗:
├─ 每次行动重新编译 → SHA256 变化
├─ 使用 Garble/Shikata 多态编码 → YARA 规则失效
├─ 修改 Rich Header / 编译时间 → Imphash 变化
├─ 资源签名替换 → 看起来像合法软件
└─ 代码混淆/虚拟化 → 静态分析失效

网络级 IOC 对抗:
├─ JA3 指纹 → 使用合法浏览器 TLS 库/配置
├─ User-Agent → 匹配目标环境真实浏览器
├─ URI 模式 → 模仿合法 SaaS API(/api/v1/events)
├─ 心跳间隔 → 加大 Jitter(30-50%),不要固定间隔
└─ 数据大小 → 添加 padding 避免固定包大小

Strategy 3: Attribution Countermeasures

防止被关联到同一组织/行动:
├─ 不同行动使用完全独立的基础设施
├─ 工具重新编译(不同编译器/选项/时间)
├─ 不复用 C2 Profile / Malleable 模板
├─ 注册信息使用一次性邮箱 + 不同注册商
├─ 支付使用加密货币 → Monero 优于 Bitcoin
└─ 时区/语言特征随机化

Strategy 4: Shortening the IOC Lifecycle

让蓝队收集到的 IOC 快速过时:
├─ 短期 C2 域名 → 48h 后切换
├─ 一次性 Payload → 每个目标唯一编译
├─ 短期 VPS → 行动结束即销毁
├─ 快速阶段切换 → 初始访问 ≠ 驻留 ≠ 数据外传
└─ Payload 自毁 → 执行后删除自身

Red Team C2 Infrastructure Checklist

部署前检查:
[ ] 域名注册 > 30 天 + 已分类
[ ] SSL 证书为 LE 或商业证书(非自签名)
[ ] Redirector 已配置(Apache/Nginx/Cloudflare)
[ ] TeamServer 无直接公网暴露
[ ] JA3 指纹匹配合法客户端
[ ] JARM 指纹不匹配已知 C2 框架
[ ] User-Agent 匹配目标环境
[ ] 域名 Whois 隐私保护已启用
[ ] IP 不在已知恶意 IP 列表中(VirusTotal/AbuseIPDB 检查)
[ ] DNS 记录无异常(无 TXT payload / 多 A 记录)

行动中检查:
[ ] 监控 C2 域名/IP 的 VT 检出率
[ ] Redirector 日志无异常扫描
[ ] 备用 C2 channel 已测试
[ ] 轮换计划已确认

行动后:
[ ] 销毁所有 VPS 实例
[ ] 销毁所有 Redirector
[ ] 确认无 DNS 残留指向已销毁 IP