raf-k1/Soc-Home-Lab-v6

# 🛡️ SOC 家庭实验室 v6.0       ## 📌 目录 - [项目概述](#-project-overview) - [核心功能](#-key-features) - [系统架构](#-architecture) - [索引架构](#-index-architecture) - [技术栈](#-tech-stack) - [前置条件](#-prerequisites) - [文件结构](#-file-structure) - [安装说明](#-setup-instructions) - [Canary Token 设置](#-canary-token-setup-deception-technology) - [Pi-hole DNS 设置](#-pi-hole-dns-setup) - [Kibana Action 文档](#-kibana-action-document) - [攻击模拟 — 杀伤链](#-attack-simulation--kill-chain) - [检测覆盖范围](#-detection-coverage) - [截图](#-screenshots) - [未来改进](#-future-improvements) ## 🔭 项目概述 SOC Home Lab v6.0 是一个完全可运行、借鉴企业级标准的 SOCs（安全运营中心），它模拟了真实的蓝队环境。该实验室通过三个专用的 Elasticsearch 索引来摄取实时的 Windows 端点遥测数据，使用 Kibana Security 检测规则检测威胁，并将实时警报发送至 Telegram Bot——全程自动化，零手动步骤。 **v6.0 引入了专业的 3 索引架构**，它消除了因在单一索引中混合 Sysmon、防火墙和 DNS 字段而导致的映射爆炸问题——这是家庭实验室设置中常见的错误，当字段类型冲突时，会导致 Elasticsearch 拒绝文档。 ## ✨ 核心功能 - **3 索引架构** — 为 Sysmon/Security、防火墙和 DNS 日志提供专用索引，防止映射冲突并提高查询性能 - **纯 ECS 规范化** — Logstash 在索引前将所有字段规范化为 Elastic Common Schema，从而兼容 Kibana 预置检测规则 - **Kibana 原生检测** — 所有威胁检测逻辑均位于 Kibana Security Rules 中，与摄取和传输层完全分离 - **欺骗技术** — Canary Token 蜜罐文件 (`passwords.txt`) 在被任何形式的访问时，会产生零误报的 CRITICAL（严重）警报 - **DNS 可见性** — Pi-hole 作为 DNS 沉洞，阻止 C2 域名并在 Kibana 中提供完整的 DNS 查询可见性 - **智能字段提取** — Python 引擎使用 `get_f()` 回退函数来处理不同 Winlogbeat 版本中的扁平化和嵌套 ECS 字段路径 - **零警报疲劳** — 基于 `_id` 的去重机制即使在重启时也能消除重复的 Telegram 消息 - **防崩溃检查点** — 警报 ID 在每次发送后保存；当在第 25/50 个警报时发生崩溃，将从第 26 个恢复，而不是从第 1 个重新开始 - **动态警报标题** — Telegram 标题由 `kibana.alert.rule.name` 驱动——新规则无需更改代码即可生成正确的通知 - **从源头降噪** — Beats 处理器在大量良性事件消耗带宽之前将其丢弃 ## 🏗️ 系统架构 ``` ┌──────────────────────────────────────────────────────────────────────────────┐ │ TIER 1 — GATHER & FILTER (Ingestion + Normalization) │ │ │ │ Windows Victim (192.168.2.11) │ │ ├─ Sysmon → Process, Network, File events (EID 1,3,11,4663...) │ │ ├─ Windows Firewall → pfirewall.log (DROP/ALLOW per connection) │ │ ├─ Winlogbeat → Sysmon + Security logs → Logstash :5055 │ │ └─ Filebeat → pfirewall.log → Logstash :5055 │ │ │ │ Pi-hole (Docker on Manager) │ │ └─ DNS queries + blocked domains → Filebeat → Logstash :5055 │ │ │ │ Logstash (192.168.2.7:5055) — Pure ECS Normalization │ │ ├─ Branch A: agent.type=winlogbeat → ECS rename → winlogbeat-* │ │ ├─ Branch B: agent.type=filebeat + windows_firewall → dissect → │ │ │ filebeat-firewall-* │ │ └─ Branch C: agent.type=filebeat + pihole → grok → pihole-logs-* │ └──────────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────────────┐ │ TIER 2 — DETECT (Kibana Security Rules) │ │ │ │ Rules monitor: winlogbeat-* + filebeat-firewall-* + pihole-logs-* │ │ ├─ Port Scan → filebeat-firewall-* | Threshold >500 DROPs/1min │ │ ├─ Successful Logon → winlogbeat-* | EID 4624 │ │ ├─ PowerShell Exec → winlogbeat-* | Sysmon EID 1 (whoami etc.) │ │ ├─ Persistence → winlogbeat-* | EID 4698 new scheduled task │ │ ├─ Canary Token → winlogbeat-* | EID 4663 on passwords.txt │ │ ├─ Suspicious Outbound → winlogbeat-* | Sysmon EID 3 on port 4444 │ │ ├─ C2 Exfiltration → winlogbeat-* | Threshold on outbound volume │ │ └─ DNS C2 → pihole-logs-* | Blocked domain queries │ │ │ │ On trigger → Index Action → .alerts-security.alerts-default │ └──────────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────────────────┐ │ TIER 3 — NOTIFY (Python Telegram Engine) │ │ │ │ soc_alert_engine_v6.py (runs on Manager 192.168.2.7) │ │ ├─ Polls .alerts-security.alerts-default every 60 seconds │ │ ├─ Deduplicates by _id → sent_ids.json (crash-safe) │ │ ├─ get_f() extracts fields via nested + flat fallback chain │ │ ├─ Formats Classic Style Markdown with dynamic rule name title │ │ └─ Delivers to Telegram Bot via Bot API → 📱 Telegram │ └──────────────────────────────────────────────────────────────────────────────┘ ``` ## 📊 索引架构 3 索引架构是 v6.0 的核心改进。每个日志源都有一个具有自己字段映射的专用索引——消除了 Elasticsearch 映射冲突。 ``` ┌─────────────────────────────────────────────────────────────────────────┐ │ Source │ Agent │ Tag │ Index │ ├─────────────────────────────────────────────────────────────────────────┤ │ Sysmon + Security │ winlogbeat │ sysmon, windows │ winlogbeat-* │ │ Windows Firewall │ filebeat │ windows_firewall │ filebeat- │ │ │ │ │ firewall-* │ │ Pi-hole DNS │ filebeat │ pihole │ pihole-logs-* │ └─────────────────────────────────────────────────────────────────────────┘ ``` **为什么这很重要：** 在单索引设置中，Sysmon 的 `winlog.event_data.DestinationPort`（字符串）和防火墙的 `destination.port`（整数）会产生字段类型冲突。Elasticsearch 会拒绝其中之一。3 索引架构为每个源提供了自己的映射命名空间——零冲突，保证完整的数据完整性。 ## 🛠️ 技术栈 | 层级 | 技术 | 作用 | |-------|-----------|------| | **SIEM** | Elasticsearch | 日志存储，3 个专用索引 | | **检测** | Kibana Security | 检测规则，警报生成 | | **流水线** | Logstash | ECS 规范化，3 索引路由 | | **端点代理** | Winlogbeat | Sysmon + Security 日志转发器 | | **防火墙代理** | Filebeat | pfirewall.log 转发器 | | **DNS 防御** | Pi-hole (Docker) | DNS 沉洞 + 查询可见性 | | **遥测** | Sysmon | 深度 Windows 事件日志记录 | | **告警** | Python 3.10+ | Kibana 警报 → Telegram | | **通知** | Telegram Bot API | 实时 SOC 通知 | | **攻击者** | Kali Linux | 攻击模拟 | | **受害者** | Windows 10 | 目标端点 | ## 📋 前置条件 ### 基础设施 - **管理机**（Linux Mint，IP：`192.168.2.7`）运行 Elasticsearch、Kibana、Logstash、Docker - **Windows 10 虚拟机**（IP：`192.168.2.11`）配置有 Sysmon、Winlogbeat、Filebeat - **Kali Linux 虚拟机**（IP：`192.168.2.5`）—— 可从受害者机器通过网络访问 ### Python ``` pip install elasticsearch requests ``` ### Telegram Bot 1. 搜索 `@BotFather` → `/newbot` → 复制 `BOT_TOKEN` 2. 搜索 `@userinfobot` → `/start` → 复制 `CHAT_ID` ### Windows 防火墙日志记录（受害者虚拟机 — 以管理员身份运行） ``` netsh advfirewall set allprofiles logging droppedconnections enable netsh advfirewall set allprofiles logging allowedconnections enable netsh advfirewall set allprofiles logging filename "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" netsh advfirewall set allprofiles logging maxfilesize 32767 ``` ### Windows 安全审计（受害者虚拟机） ``` auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /set /subcategory:"File System" /success:enable /failure:enable auditpol /set /subcategory:"Other Object Access Events" /success:enable ``` ## 📁 文件结构 ``` soc-home-lab-v6/ │ ├── README.md ├── .gitignore │ ├── Logstash/ │ └── all-in2.conf ← 3-index routing pipeline │ ├── Beats/ │ ├── winlogbeat.yml ← Sysmon + Security forwarder │ └── filebeat.yml ← Firewall log forwarder │ ├── Docker/ │ └── docker-compose.yml ← Pi-hole DNS sinkhole setup │ ├── Python/ │ └── soc_alert_engine_v6.py ← Kibana alerts → Telegram │ └── ELK_Screenshots/ ├── Nmap.png ├── Nmap2.png ├── Telegram_Nmap.jpg ├── Logon.png ├── Logon2.png ├── Telegram_Logon.jpg ├── Process.png ├── Process2.png ├── Telegram_process.jpg ├── Rules.png ← Overview of Detection Rules ├── sch_task.png ├── sch_task2.png ├── Telegram_sch_task.jpg ├── Canary.png ├── Canary2.png ├── Telegram_Canary.jpg ├── C2.png ├── C2_2.png ├── Telegram_C2.jpg ├── Outbound.png ├── Outbound2.png ├── Telegram_outbound.jpg └── Telegram_start.jpg ``` ## ⚙️ 安装说明 ### 1. Logstash 流水线 ``` cp logstash/all-in.conf /etc/logstash/conf.d/ # 在输出块中编辑密码 sudo systemctl restart logstash sudo journalctl -u logstash -f ``` ### 2. Windows 受害者机上的 Beats ``` # Winlogbeat cd "C:\Program Files\Winlogbeat" .\winlogbeat.exe test config -c .\winlogbeat.yml .\winlogbeat.exe test output -c .\winlogbeat.yml Start-Service winlogbeat # Filebeat cd "C:\Program Files\Filebeat" .\filebeat.exe test config -c .\filebeat.yml .\filebeat.exe test output -c .\filebeat.yml Start-Service filebeat ``` ### 3. 验证 3 个索引已创建 启动 Beats 后，在 Kibana 中验证： ``` Stack Management → Index Management ``` 你应该能看到：`winlogbeat-*`、`filebeat-firewall-*`、`pihole-logs-*` ### 4. Python 引擎 ``` # 在 soc_alert_engine_v6.py 中编辑 ES_HOST = "http://192.168.2.7:9200" ES_PASSWORD = "YOUR_ELASTIC_PASSWORD" TELEGRAM_TOKEN = "YOUR_BOT_TOKEN" TELEGRAM_CHATID = "YOUR_CHAT_ID" ``` ``` python3 python/soc_alert_engine_v6.py ``` ## 🪤 Canary Token 设置（欺骗技术） Canary Token 是放置在明显位置的蜜罐文件。任何访问都是活跃攻击者的**零误报指标**——没有合法的流程应该打开此文件。 ### 步骤 1 — 创建蜜罐文件（受害者虚拟机） ``` # 创建具有说服力的虚假凭据文件 New-Item -Path "C:\Users\$env:USERNAME\Desktop\passwords.txt" -ItemType File Set-Content -Path "C:\Users\$env:USERNAME\Desktop\passwords.txt" -Value @" # 公司管理员凭据 - 机密 Administrator: P@ssw0rd!2024 backup_admin: Backup#9981 domain_admin: D0m@in`$ecure sql_service: SqlSvc!Pass123 remote_access: RDP_Acc3ss! "@ ``` ### 步骤 2 — 启用文件系统审计 ``` # 启用审计策略 auditpol /set /subcategory:"File System" /success:enable /failure:enable # 仅对 canary 文件应用审计规则 $file = "C:\Users\$env:USERNAME\Desktop\passwords.txt" $acl = Get-Acl $file $rule = New-Object System.Security.AccessControl.FileSystemAuditRule( "Everyone", "ReadData", "Success" ) $acl.SetAuditRule($rule) Set-Acl -Path $file -AclObject $acl # 验证 (Get-Acl -Path $file -Audit).Audit # 预期：Everyone | ReadData | Success ``` ### 步骤 3 — Kibana 检测规则 ``` Security → Rules → Create New Rule → Custom Query Index: winlogbeat-* ``` ``` winlog.event_id: 4663 AND file.path: *passwords.txt* ``` | 设置项 | 值 | |---------|-------| | 名称 | `🪤 CANARY TOKEN — Password File Accessed` | | 严重性 | 严重 | | 风险评分 | 99 | | 运行频率 | 每 1 分钟 | ### 工作原理 ``` Attacker opens passwords.txt → Windows EID 4663 fires (File System Audit) → Winlogbeat → Logstash → winlogbeat-* → Kibana Rule matches (file.path: *passwords.txt*) → Alert → .alerts-security.alerts-default → Python Engine → Telegram CRITICAL 🚨 ``` ## 🌐 Pi-hole DNS 设置 Pi-hole 作为整个实验室网络的 DNS 沉洞。每台设备的每个 DNS 查询都流经 Pi-hole，提供完整的 DNS 可见性，并在已知的 C2 域名解析前将其阻止。 ### 部署 Pi-hole（管理机 — Docker） ``` mkdir -p /home/raf/pihole/etc-pihole mkdir -p /home/raf/pihole/etc-dnsmasq.d docker run -d \ --name pihole \ -p 53:53/tcp -p 53:53/udp \ -p 8080:80 \ -e TZ="Europe/Athens" \ -e WEBPASSWORD="YOUR_PIHOLE_PASSWORD" \ -e PIHOLE_DNS_1=8.8.8.8 \ -e PIHOLE_DNS_2=1.1.1.1 \ -v /home/raf/pihole/etc-pihole:/etc/pihole \ -v /home/raf/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \ --restart unless-stopped \ pihole/pihole:latest ``` ### 将所有虚拟机的 DNS 指向 Pi-hole 在 **Windows 受害者机**上（以管理员身份运行）： ``` # 将 Pi-hole 设置为主 DNS netsh interface ip set dns "Ethernet" static 192.168.2.7 # 验证 nslookup google.com 192.168.2.7 ``` 在 **Kali Linux** 上： ``` echo "nameserver 192.168.2.7" | sudo tee /etc/resolv.conf ``` ### Pi-hole 如何提供 C2 可见性 ``` Malware on victim beacons to: evil-c2.tk → DNS query → Pi-hole (192.168.2.7) ├─ Domain in gravity blocklist → BLOCKED → returns 0.0.0.0 └─ Domain not blocked → forwarded to 8.8.8.8 Pi-hole logs ALL queries → Filebeat → Logstash → pihole-logs-* → Kibana Rule: "Blocked domain" OR "suspicious TLD (.tk .ml .xyz)" → Alert → Telegram 🌐 ``` ### 用于检测 DNS C2 的 Kibana 检测规则 ``` # 已屏蔽域名 dns.question.name: * AND dns.resolved_ip: "0.0.0.0" ``` ``` # 可疑 TLD dns.question.name: *.tk OR dns.question.name: *.ml OR dns.question.name: *.xyz OR dns.question.name: *.pw ``` ## 📦 Kibana Action 文档 对于每个 Security Detection Rule，设置 **Index Connector** 动作，将 ECS 字段映射到 `.alerts-security.alerts-default` 中： ``` { "@timestamp": "{{date}}", "kibana.alert.rule.name": "{{rule.name}}", "kibana.alert.severity": "{{context.rule.severity}}", "kibana.alert.risk_score": "{{rule.riskScore}}", "kibana.alert.reason": "{{context.reason}}", "host.name": "{{context.alerts.[0].host.name}}", "user.name": "{{context.alerts.[0].user.name}}", "source.ip": "{{context.alerts.[0].source.ip}}", "destination.ip": "{{context.alerts.[0].destination.ip}}", "destination.port": "{{context.alerts.[0].destination.port}}", "network.transport": "{{context.alerts.[0].network.transport}}", "process.command_line": "{{context.alerts.[0].process.command_line}}", "process.name": "{{context.alerts.[0].process.name}}", "file.path": "{{context.alerts.[0].file.path}}", "winlog.event_id": "{{context.alerts.[0].winlog.event_id}}", "winlog.event_data.CommandLine": "{{context.alerts.[0].winlog.event_data.CommandLine}}", "winlog.event_data.Image": "{{context.alerts.[0].winlog.event_data.Image}}", "event.action": "{{context.alerts.[0].event.action}}", "tags": ["soc_alert", "kibana_rule"] } ``` ## ☠️ 攻击模拟 — 杀伤链 ### 杀伤链概览 | # | 阶段 | MITRE 战术 | 技术 | 来源 | 检测 | |---|-------|-------------|-----------|--------|-----------| | 1 | 侦察 | TA0043 | T1595 — 主动扫描 | Kali | filebeat-firewall-* 阈值 | | 2 | 初始访问 | TA0001 | T1078 — 有效账户 | Windows | winlogbeat-* EID 4624 | | 3 | 执行 | TA0002 | T1059.001 — PowerShell | Windows | winlogbeat-* Sysmon EID 1 | | 4 | 持久化 | TA0003 | T1053.005 — 计划任务 | Windows | winlogbeat-* EID 4698 | | 5 | 收集 | TA0009 | T1005 — 本地数据 | Windows | winlogbeat-* EID 4663 Canary | | 6 | 命令与控制 | TA0011 | T1071 — 应用层协议 | Windows | winlogbeat-* Sysmon EID 3 | | 7 | 数据渗出 | TA0010 | T1041 — 通过 C2 通道渗出 | Windows | winlogbeat-* 阈值 |   ### 步骤 1 — 侦察：Nmap 端口扫描 (T1595) **目标：** 在 `filebeat-firewall-*` 上触发 Kibana 阈值规则——在 1 分钟内来自单一源 IP 的超过 500 个 DROP 事件。 ``` # 在 Kali (192.168.2.5) 上 # -sS = SYN 隐蔽扫描 | -A = 操作系统检测 + 脚本 | -p- = 所有 65535 个端口 # -Pn = 跳过主机发现（将主机视为在线） sudo nmap -Pn -sS -A -p- --min-rate 1000 192.168.2.11 ``` **发生过程：** - Windows 防火墙将数百个 DROP 事件记录到 `pfirewall.log` - Filebeat 将它们发送 → Logstash → `filebeat-firewall-*` - 当计数在 1 分钟内超过 500 时，Kibana 阈值规则触发 - Telegram 接收到：`🟠 PORT SCAN DETECTED`    ### 步骤 2 — 初始访问：成功登录检测 (T1078) **发生过程：** - 成功交互式登录到 `labuser` 账户会生成 Windows EID 4624 - Winlogbeat 将事件发送 → Logstash → `winlogbeat-*` - Kibana Custom Query Rule 检测到成功登录 - Telegram 接收到：`🔴 SUCCESSFUL LOGON DETECTED` ``` winlog.event_id: 4624 AND winlog.logon.type: "3" AND user.name: "labuser" ```    ### 步骤 3 — 执行：PowerShell 命令检测 (T1059.001) **在 Windows 受害者虚拟机上**，执行基本的 PowerShell 命令，以模拟攻击者在获取访问权限后进行信息收集： ``` # 像攻击者那样运行——简单的发现命令 whoami Get-LocalUser ipconfig /all ``` **发生过程：** - Sysmon EID 1（进程创建）捕获每次 PowerShell 调用 - `process.command_line` 字段记录确切的命令（例如 `whoami`） - Kibana Custom Query Rule 在 PowerShell 执行时触发 - Telegram 接收到所运行的确切命令 ``` winlog.event_id: 1 AND process.name: "powershell.exe" ```    ### 步骤 4 — 持久化：计划任务创建 (T1053.005) **在 Windows 受害者虚拟机上**，创建计划任务以模拟攻击者建立持久化： **发生过程：** - Windows Security EID 4698（计划任务已创建）立即触发 - Winlogbeat 将事件发送 → Logstash → `winlogbeat-*` - Kibana Custom Query Rule 匹配 EID 4698 - Telegram 接收到：`🔴 PERSISTENCE — SCHEDULED TASK CREATED` ``` winlog.event_id: 4698 AND winlog.event_data.TaskName: *WindowsUpdateHelper* ```    ### 步骤 5 — 收集：Canary Token 已激活 (T1005) **在 Windows 受害者虚拟机上**，攻击者发现并打开了蜜罐凭据文件： ``` # 模拟攻击者在获取访问权限后打开 honeypot 文件 notepad.exe "C:\Users\$env:USERNAME\Desktop\passwords.txt" ``` **发生过程：** - Windows 文件系统审计在文件打开时立即触发 EID 4663 - `file.path` 字段确认访问了确切的 Canary 文件 - Kibana Custom Query Rule 匹配——风险评分 99（最高可能值） - Telegram 接收到：`🚨 CANARY TOKEN TRIGGERED`——确认主机上存在攻击者 ``` winlog.event_id: 4663 AND file.path: *passwords.txt* ```    ### 步骤 6 — 命令与控制：可疑出站连接 (T1071) **MITRE ATT&CK：** 命令与控制 — [T1071 应用层协议](https://attack.mitre.org/techniques/T1071/) **场景：** 建立持久化后，攻击者向 Kali 机器上模拟的命令与控制服务器发起出站连接。此步骤验证 SOC 是否能检测到 `powershell.exe` 建立到非标准、可疑端口的网络连接。 在 Kali 攻击者机器上打开一个 `netcat` 监听器，以模拟等待信标的 C2 服务器： ``` # 在 Kali (192.168.2.5) 上 — 在端口 4444 开启 C2 监听器 nc -lvnp 4444 ``` 在 **Windows 受害者机**上，以下 PowerShell 命令模拟 C2 信标： ``` PS C:\Windows\system32> Test-NetConnection -ComputerName 192.168.2.5 -Port 4444 ``` **发生过程：** - Sysmon EID 3（网络连接）捕获到出站 TCP 连接 - 关键字段：`process.name: powershell.exe`、`destination.ip: 192.168.2.5`、`destination.port: 4444` - 端口 4444 是默认 C2 框架的已知指标——来自用户端点到此端口的任何出站连接都具有高可信度 - Kibana Custom Query Rule 立即触发 - Telegram 接收到：`🚨 SUSPICIOUS OUTBOUND CONNECTION DETECTED` ``` winlog.event_id: 3 AND destination.port: 4444 AND process.name: "powershell.exe" ``` | 设置项 | 值 | |---------|-------| | 规则类型 | Custom Query | | 严重性 | 高 | | 风险评分 | 73 | | 索引 | `winlogbeat-*` |    ### 步骤 7 — 数据渗出：潜在 C2 数据渗出 (T1041) **MITRE ATT&CK：** 数据渗出 — [T1041 通过 C2 通道渗出](https://attack.mitre.org/techniques/T1041/) **场景：** 在步骤 6 中建立了 C2 通道后，攻击者通过向同一外部 IP 生成大量出站网络连接来模拟数据渗出。这模拟了恶意软件暂存和传输收集到的数据（如文件、凭据或屏幕截图）回传到攻击者基础设施的模式。 此步骤具体演示了**纵深防御**：C2 通道在步骤 6 中通过特征（端口 4444）被检测到，而渗出在步骤 7 中通过**数量异常**被检测到——这是一个不同且互补的检测层。 **模拟 — 生成大量出站流量：** ``` # 在 Windows 受害者上 — 模拟重复的出站连接 # 模拟到 C2 服务器的数据窃取循环 1..50 | ForEach-Object { Test-NetConnection -ComputerName 192.168.2.5 -Port 4444 Start-Sleep -Milliseconds 200 } ``` **发生过程：** - 每次迭代都会在 `winlogbeat-*` 中生成一个 Sysmon EID 3 事件 - Kibana 阈值规则统计滚动时间窗口内到同一目标 IP 的 EID 3 事件 - 当数量超过阈值时，它标志着异常的数据传输——不是一次性连接，而是与分阶段渗出一致的持续出站通道 - Telegram 接收到：`🚨 POTENTIAL C2 EXFILTRATION — VOLUME ANOMALY DETECTED` ``` winlog.event_id: 3 AND destination.ip: "192.168.2.5" AND process.name: "powershell.exe" ``` **Kibana 阈值规则：** | 设置项 | 值 | |---------|-------| | 规则类型 | Threshold | | 分组依据 | `destination.ip` | | 阈值条件 | `2 分钟内` `IS ABOVE 20` | | 严重性 | 严重 | | 风险评分 | 90 | | 索引 | `winlogbeat-*` |    ### 杀伤链关联查询 以下单条 KQL 查询可在 Kibana Discover 中重建所有 7 个步骤的**整个攻击时间线**： ``` (winlog.event_id: (4624 OR 4663 OR 4698)) OR (winlog.event_id: 1 AND process.name: "powershell.exe") OR (winlog.event_id: 3 AND destination.port: 4444) OR (winlog.event_id: 3 AND destination.ip: "192.168.2.5") OR (event.action: "drop" AND source.ip: "192.168.2.5") ``` ## 🎯 检测覆盖范围 下表列出了**此 SOC 实验室能够执行的所有检测**，包括上述杀伤链中演示的检测以及其他独立功能。 ### 杀伤链检测 | 攻击 | MITRE 战术 | 技术 | 源索引 | 规则类型 | |--------|-------------|-----------|-------------|-----------| | Nmap 端口扫描 | 侦察 | T1595 | filebeat-firewall-* | Threshold | | 成功登录 | 初始访问 | T1078 | winlogbeat-* | Custom Query | | PowerShell 执行 (`whoami`) | 执行 | T1059.001 | winlogbeat-* | Custom Query | | 计划任务创建 | 持久化 | T1053.005 | winlogbeat-* | Custom Query | | Canary Token 已激活 | 收集 | T1005 | winlogbeat-* | Custom Query | | 可疑出站端口 | 命令与控制 | T1071 | winlogbeat-* | Custom Query | | 潜在 C2 数据渗出 | 数据渗出 | T1041 | winlogbeat-* | Threshold | ### 附加功能 以下检测在实验室中已配置并激活。它们不属于上述线性杀伤链模拟的一部分，但已完全可操作： | 检测项 | MITRE 技术 | 源索引 | 规则类型 | 备注 | |-----------|----------------|-------------|-----------|-------| | DNS C2 信标 | T1071.004 | pihole-logs-* | Custom Query | 通过 Pi-hole 检测被阻止的域名和可疑的 TLD (.tk .ml .xyz) | | 新增 Windows 服务 | T1543.003 | winlogbeat-* | Custom Query | EID 7045 — 常见的恶意软件持久化方法 | | 审计日志被清除 | T1070.001 | winlogbeat-* | Custom Query | EID 1102 — 攻击者掩盖痕迹 | | PowerShell 编码命令 | T1059.001 | winlogbeat-* | Custom Query | `-EncodedCommand` / `-enc` 标志检测 | ## 📸 截图 所有截图均位于 `ELK_Screenshots/` 文件夹中，并直接嵌入到上方的杀伤链部分。下表提供了参考摘要： | 文件 | 阶段 | 描述 | |------|-------|-------------| | `Nmap.png` | 步骤 1 | Kibana — Nmap 扫描产生的 filebeat-firewall-* DROP 事件 | | `Nmap2.png` | 步骤 1 | Kibana — Nmap 阈值警报已触发 | | `Telegram_Nmap.jpg` | 步骤 1 | Telegram 端口扫描警报 | | `Logon.png` | 步骤 2 | Kibana — 成功登录警报 | | `Logon2.png` | 步骤 2 | Kibana — Discover 中的 EID 4624 | | `Telegram_Logon.jpg` | 步骤 2 | Telegram 成功登录警报 | | `Process.png` | 步骤 3 | Kibana — Sysmon EID 1 PowerShell / whoami 检测 | | `Process2.png` | 步骤 3 | Kibana — process.command_line 字段详细信息 | | `Telegram_process.jpg` | 步骤 3 | Telegram PowerShell 执行警报 | | `sch_task.png` | 步骤 4 | Kibana — 持久化警报已触发 | | `sch_task2.png` | 步骤 4 | Kibana — Discover 中的 EID 4698 计划任务 | | `Telegram_sch_task.jpg` | 步骤 4 | Telegram 持久化警报 | | `Canary.png` | 步骤 5 | Kibana — Canary Token CRITICAL 警报 | | `Canary2.png` | 步骤 5 | Kibana — 风险评分 99 警报详细信息 | | `Telegram_Canary.jpg` | 步骤 5 | Telegram CRITICAL Canary 警报 | | `C2.png` | 步骤 6 | Kibana — Sysmon EID 3 powershell.exe → 端口 4444 | | `C2_2.png` | 步骤 6 | Kibana — Discover 中的可疑出站连接详细信息 | | `Telegram_C2.jpg` | 步骤 6 | Telegram 可疑出站连接警报 | | `Outbound.png` | 步骤 7 | Kibana — C2 渗出阈值警报已触发 | | `Outbound2.png` | 步骤 7 | Kibana — Discover 中的大量出站连接 | | `Telegram_outbound.jpg` | 步骤 7 | Telegram 潜在 C2 数据渗出警报 | | `Telegram_start.jpg` | 设置 | Telegram — Python 引擎启动通知 | ## 🚀 未来改进 - **TheHive 集成** — 根据 Kibana 警报自动创建事件案例，以实现完整的事件生命周期管理 - **MITRE ATT&CK Navigator** — 将检测覆盖范围导出为 Navigator 层，以可视化盲区 - **GeoIP 富化** — Logstash GeoIP 过滤器，将 `source.ip` 映射到 Kibana 世界地图上的国家 - **Elastic Defend EDR** — 在发生 CRITICAL 警报时，主动隔离端点并阻止进程 - **Sigma 规则导入** — 自动将社区 Sigma 规则转换为 Kibana 检测规则 - **自动化响应剧本** — 在发生 CRITICAL 警报时触发 Python 脚本以禁用账户或阻止 IP ## ⚠️ 法律与道德声明 所有攻击模拟均在我自己拥有的系统上，于隔离的家庭实验室环境中专门进行。本项目仅用于教育目的和 SOC 作品集展示。切勿对您不拥有或未获得明确书面测试许可的系统使用这些技术。 ## 📄 许可证 MIT License — 详见 `LICENSE`。

**为蓝队社区而建 🛡️**         

标签：AMSI绕过, Canary Tokens, Cloudflare, DNS安全, Elasticsearch 8.x, Elastic Stack, IP 地址批量处理, MITRE ATT&CK, OISF, PE 加载器, Pi-hole, Python, SOC实验室, Sysmon, Telegram机器人, 企业级安全架构, 内容过滤, 威胁检测, 子域名变形, 安全运营中心, 家庭实验室, 开源安全工具, 插件系统, 无后门, 日志管理, 杀伤链, 流量重放, 端点遥测, 网络安全, 网络安全审计, 网络攻击模拟, 网络映射, 蜜罐, 证书利用, 请求拦截, 越狱测试, 逆向工具, 逆向工程平台, 防御欺骗技术, 隐私保护