Kerberos

Kerberos 是一种计算机网络认证协议，作用是进行身份验证

身份验证过程

• 客户端向KDC(通常是域控制器)请求TGT，请求用户的密钥之一用于预身份验证。TGT由身份验证服务(AS)提供，客户端的请求被称为AS-REQ，应答被称为AS-REP
• 客户端使用TGT向KDC请求ST(服务票证)。该票证由票证授予服务(TGS)提供。客户端的请求被称为TGS-REQ，应答被称为TGS-REP
• 客户端使用ST(服务票证)来访问服务。客户端对服务的请求被称为调用AP-REQ，服务的响应称为调用AP-REP
• 两种票证(TGT和ST)通常都包含加密的PAC(特权身份验证证书)，目标服务将读取一组信息来决定身份验证用户是否可以访问该服务(用户ID、组成员身份等)

要理解 K8s（Kubernetes）场景下黄金票据、白银票据与Kerberoasting 攻击的关系、区别和联系，首先需要明确一个核心前提：这些攻击本身并非 K8s 原生攻击，而是源于 Windows Active Directory (AD) 的 Kerberos 认证体系攻击；但在混合云 / 企业环境中，当 K8s 集群与 AD 集成（如通过 AD 做身份认证、服务账户映射、RBAC 权限关联等）时，这些 Kerberos 攻击会间接影响 K8s 的安全，甚至被攻击者利用来渗透 K8s 集群。

下面先从AD Kerberos 基础入手，再分析三者的核心定义、关系，最后结合 K8s 场景说明其实际影响。

一、前置知识：Kerberos 认证与 AD 的核心角色

Kerberos 是一种基于票据的身份认证协议，AD 作为 Kerberos 的 KDC（密钥分发中心），包含三个核心组件：

1. AS（认证服务器）：发放 TGT（票据授予票据），用于后续申请服务票据。
2. TGS（票据授予服务器）：根据 TGT 发放 ST（服务票据），用于访问具体服务（如 SQL、文件共享、K8s API Server）。
3. Principal（主体）：用户 / 服务账户（如[email protected]、HTTP/[email protected]），每个主体有一个长期密钥（NTLM 哈希 / AES 密钥）存储在 KDC。

黄金票据、白银票据、Kerberoasting 均是针对 Kerberos 协议的票据伪造 / 破解攻击，但攻击目标、利用条件、危害范围截然不同。

二、黄金票据、白银票据、Kerberoasting 的核心区别

1. 核心定义与攻击目标

2. 攻击流程对比

（1）黄金票据攻击流程

1. 获取 KRBTGT 账户的哈希 / AES 密钥（通常通过域控制器提权、渗透 AD 数据库 NTDS.dit 等方式）。
2. 伪造 TGT：使用 KRBTGT 密钥签名，冒充域内任意用户（如域管理员）生成 TGT。
3. 使用伪造 TGT：向 TGS 申请任意服务的 ST，进而访问域内所有资源（包括 K8s 集群中与 AD 集成的服务）。

（2）白银票据攻击流程

1. 获取目标服务账户的哈希 / AES 密钥（如 K8s API Server 的服务账户HTTP/[email protected]）。
2. 伪造 ST：直接绕过 AS/TGS，用服务账户密钥签名生成访问该服务的 ST。
3. 直接访问服务：用伪造的 ST 访问目标服务（如 K8s API Server）。

（3）Kerberoasting 攻击流程

1. 枚举域内的服务账户（如[email protected]）。
2. 向 KDC 申请该服务账户的 ST（合法请求，KDC 会返回加密的 ST）。
3. 离线破解 ST：ST 用服务账户的密钥加密，攻击者可通过暴力破解 / 彩虹表获取服务账户的密钥。
4. 利用密钥：用服务账户的密钥访问目标服务，或进一步渗透（如映射到 K8s 的 RBAC 权限）。

3. 核心区别总结

• 黄金票据是 “域级万能钥匙”，控制 KRBTGT 即可冒充任意用户；
• 白银票据是 “服务级万能钥匙”，仅针对单个服务有效；
• Kerberoasting是 “破解服务钥匙”，通过合法获取的 ST 离线破解服务账户密钥。

三、三者的联系

1. 同属 Kerberos 协议攻击：均利用 Kerberos 协议的设计缺陷（如票据签名验证机制、服务票据加密特性），且依赖 AD 的密钥体系。
2. 攻击链可衔接：
   • 攻击者可先通过Kerberoasting破解低权限服务账户密钥，进而渗透域控制器，获取 KRBTGT 密钥后制作黄金票据；
   • 也可通过黄金票据获取高权限，再针对特定服务制作白银票据（更隐蔽，避免频繁使用黄金票据被检测）。

3. 最终目标一致：均为获取域内 / 服务的访问权限，进而渗透到关联的 K8s 集群等资源。

四、在 K8s 场景中的实际影响（关键）

企业中 K8s 集群常与 AD 集成，典型场景包括：

• K8s API Server 使用 AD 认证（如通过 SSO、LDAP 映射 AD 用户到 K8s RBAC）；
• K8s 节点 / 服务账户使用 AD 域账户运行（如[email protected]）；
• 容器内应用访问 AD 集成的服务（如数据库、存储）。

此时，黄金票据、白银票据、Kerberoasting 攻击会通过以下方式影响 K8s：

1. 黄金票据对 K8s 的影响

攻击者制作黄金票据后，可冒充 AD 域管理员，通过 AD 认证机制直接获取 K8s 的cluster-admin权限（若 AD 域管理员被映射为 K8s 集群管理员），进而完全控制 K8s 集群。

2. 白银票据对 K8s 的影响

若 K8s API Server 的服务账户为HTTP/[email protected]，攻击者获取该账户密钥后制作白银票据，可直接访问 K8s API Server，无需经过 AD 认证流程，绕过 K8s 的身份验证。

3. Kerberoasting 对 K8s 的影响

• 若 K8s 的服务账户（ServiceAccount）映射到 AD 服务账户，攻击者破解该 AD 服务账户密钥后，可通过 AD 认证获取 K8s 的对应 RBAC 权限（如edit、view）；
• 若容器内应用使用 AD 账户访问外部服务，攻击者可通过 Kerberoasting 破解该账户密钥，窃取应用数据。

五、防御建议（结合 K8s+AD）

1. 强化 AD 安全：
   • 定期轮换 KRBTGT 账户密钥（默认永不轮换，需手动操作）；
   • 限制服务账户的权限，避免使用高权限账户运行服务；
   • 监控 Kerberoasting 攻击（如频繁申请服务票据、大量离线破解行为）。

2. K8s 与 AD 集成的安全加固：
   • 避免将 AD 域管理员映射为 K8s cluster-admin；
   • 使用 K8s 原生 ServiceAccount 而非 AD 域账户运行容器；
   • 启用 K8s 的审计日志，监控异常的 AD 用户访问 K8s API。

3. 票据安全：
   • 启用 Kerberos 的 AES 加密（而非弱的 RC4），提高破解难度；
   • 缩短 TGT/ST 的有效期，降低票据被破解 / 伪造的风险。

总结

黄金票据、白银票据、Kerberoasting 是 AD Kerberos 体系的三类核心攻击，无直接的 K8s 原生关联，但在 K8s 与 AD 集成的环境中会形成跨域渗透风险。其核心区别在于攻击目标（TGT/ST/ 服务密钥）和权限范围，而联系在于同属 Kerberos 攻击链且可互相衔接。在实际运维中，需同时加固 AD 和 K8s 的集成边界，才能有效防御这类攻击。

kerberoasting攻击

kerberoasting攻击是在TGS_REP过程中用户会收到由目标服务实例的NTLM hash加密的TGS，如果得到了这个TGS，由于该TGS是用服务端hash加密，那么客户端拿到TGS后可以本地爆破，如果字典足够大则能爆破出SPN(服务主题名称)链接用户的明文密码，当该服务在域内权限很高时，攻击者能接管整个域。

分析DC的安全日志，确认kerberoasting活动发生的日期和时间

查看Domain Controller中的安全日志，根据kerberoasting原理查看TGS相关日志，筛选事件 ID 4769，查找服务名称不为krbtgt或以$结尾(比如DC01$)的任何事件。票证加密类型为0x17，用于RC4类型加密，故障代码为0x0

为什么筛选事件ID4769？

Kerberoasting 攻击发生在 Kerberos 协议的TGS（票证授予服务）阶段：

• 当客户端（用户 / 程序）需要访问域内服务时，会向 KDC（域控制器）发送TGS 请求，以获取该服务的票据（Service Ticket）。
• Windows 域控制器会在安全日志中记录TGS 请求操作，对应的事件 ID 就是 4769（描述为 “已请求 Kerberos 服务票证”）。

为什么排除krbtgt和以$结尾的服务名称

Kerberoasting 的目标是可爆破的服务账户密码

• 服务名称为 “krbtgt”：krbtgt是 KDC 自身的服务账户（用于签发 TGT 票证），其密码是域的核心密钥（随机生成、极复杂），无法被爆破，因此攻击者不会针对它。
• 以 $ 结尾:机器账户。机器账户的密码是系统自动生成的 128 位随机字符，同样无法被爆破。

为什么关注加密类型0x17(RC4)

Kerberoasting 的核心是离线爆破服务票据

若加密类型为0x17(对应RC4HMACMD5算法)，票据加密方式是"服务账户哈希+RC4"，而RC4算法的破解难度低(可通过字典/暴力破解获取服务账户的明文密码)

若使用 AES（加密型 0x12/0x13），破解难度极高，攻击者无法爆破，因此 Kerberoasting 攻击会刻意请求 RC4 加密的票据。

时间转换成 UTC

2024-05-21 11:18:09 ->  2024-05-21 3:18:09

Task2

被攻击的服务名称是什么？

MSSQLService

Task3

识别发生此活动的工作站至关重要。该工作站的 IP 地址是什么？

172.17.79.129

Task4

既然我们已经定位到该工作站，现为您提供包括 PowerShell 日志和预取文件在内的诊断数据，以便深入分析，从而了解该端点上的活动是如何发生的。用于枚举 Active Directory 对象并可能在网络中查找可 Kerberoast 账户的文件名称是什么？

去筛选4104事件

┌──(root㉿kali)-[~/ctf/campfire-1/Triage/Workstation]
└─# cat Powershell-Operational.json | jq 'select(.Event.System.EventID==4104)' -c | head -1 | jq .
{
"Event": {
"#attributes": {
"xmlns": "http://schemas.microsoft.com/win/2004/08/events/event"
},
"System": {
"Provider": {
"#attributes": {
"Name": "Microsoft-Windows-PowerShell",
"Guid": "A0C1853B-5C40-4B15-8766-3CF1C58F985A"
}
},
"EventID": 4104,
"Version": 1,
"Level": 3,
"Task": 2,
"Opcode": 15,
"Keywords": "0x0",
"TimeCreated": {
"#attributes": {
"SystemTime": "2024-05-21T03:16:29.811516Z"
}
},
"EventRecordID": 135,
"Correlation": {
"#attributes": {
"ActivityID": "B6DF577B-AB2B-0004-136C-DFB62BABDA01"
}
},
"Execution": {
"#attributes": {
"ProcessID": 7268,
"ThreadID": 9220
}
},
"Channel": "Microsoft-Windows-PowerShell/Operational",
"Computer": "Forela-Wkstn001.forela.local",
"Security": {
"#attributes": {
"UserID": "S-1-5-21-3239415629-1862073780-2394361899-1104"
}
}
},
"EventData": {
"MessageNumber": 1,
"MessageTotal": 1,
"ScriptBlockText": "powershell -ep bypass",
"ScriptBlockId": "168b7dc8-7258-417e-98cc-5f6329cc58ad",
"Path": ""
}
}
}

第一个日志是演员调用，找到绕过限制执行ps文件

powershell -ep bypass

那下一条应该就是具体的文件位置

继续去查看第二个日志

cat Powershell-Operational.json | jq 'select(.Event.System.EventID==4104)' -c | head -2 | tail -1 | jq .

是去加载powerview.ps1，那么这个也就是task4

Task5

该脚本是何时执行的？

2024-05-21T03:16:32.588340Z

2024-05-21 03:16:32

Task6

用于执行实际 kerberoasting 攻击的工具完整路径是什么？

prefetch文件夹 Windows 中的预读取文件夹，存放系统已访问的文件的预读信息，程序首次运行时会存储有关在加载该文件时访问的所有文件的信息，还存储元数据

工具采集信息在11:17:25结束，从17分开始查看prefetch文件夹

可疑程序rubeus.exe

\VOLUME{01d951602330db46-52233816}\USERS\ALONZO.SPIRE\DOWNLOADS\RUBEUS.EXE

C:\USERS\ALONZO.SPIRE\DOWNLOADS\RUBEUS.EXE

Task7

2024-05-21 03:18:08

campfire-2

Task1

When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?

ASREP Roasting攻击的事件代码为"4768"

• 票据加密类型：留意值为0x17的情况，这表示 RC4 加密（一种较弱的加密类型，常与 AS-REP Roasting 攻击关联）。
• 预身份验证类型：值为0意味着未使用预身份验证，这是 AS-REP Roasting 的核心特征之一。
• 服务名称：服务名称应显示为krbtgt，即 Kerberos 票据授予票据服务。

2024-5-29 14:36:40（UTC+8）

Task2

Please confirm the User Account that was targeted by the attacker.

上图可知

arthur.kyle

Task3

What was the SID of the account?

上图可知

S-1-5-21-3239415629-1862073780-2394361899-1601

Task4

It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team.

上图可知

172.17.79.129

Task5

下一个记录的事件是 Kerberos 服务票据作，允许请求服务票以访问指定域名的服务。此作要求请求账户已发放TGT。从日志信息中我们可以看到用户名已经更改。这可能意味着威胁行为者利用了 的电脑为另一个拥有更多访问权限的账户请求 TGT。另外要注意，事件来自的是 的机器的同一个 IP。

happy.grunwald

LLMNR poisoning

LLMNR中毒(也称LLMNR欺骗)并非传统意义上的"病毒感染"，而是内网渗透中利用LLMNR协议缺陷发起的身份凭据窃取攻击。其核心是通过伪造网络响应，诱骗目标主机泄露NTLM认证哈希，进而实现凭据破解或横向渗透，是企业内网常见的高风险的攻击手段之一

LLMNR协议背景

LLMNR(链路本地多播名称解析)是WinXP及以后版本默认启用的局域网备用名称解析协议，作用是：

• 当主机通过DNS无法解析目标主机名(如访问内网共享文件夹\fileserver时DNS查不到fileserver)，会自动通过LLMNR协议，向局域网内所有主机（多播地址224.0.0.252）发送UDP请求（端口5355），询问"谁是fileserver？请告诉我你的ip"；
• 若局域网内存在该主机，会直接响应自己的IP，完成名称解析。

但LLMNR协议设计存在致命缺陷：

• 无身份验证机制：任何主机都可伪造响应，声称自己是目标主机；
• 无请求验证：目标主机收到响应后，会直接信任并发起后续通信，不会校验响应来源的合法性。

这一缺陷为“中毒攻击”提供了基础——攻击者可伪装成“目标主机”，欺骗发起请求的主机泄露敏感凭据。

LLMNR中毒的攻击原理与流程

1.核心原理：伪造响应+捕获NTLM哈希

LLMNR中毒的本质是"响应劫持"：攻击者监听局域网内的LLMNR请求，抢先伪造"合法响应"，诱使发起请求的主机向攻击者发起NTLM认证，进而捕获认证过程中的NTLMv2哈希（windows系统默认的认证哈希格式）。

NTLM哈希是主机登录密码经过哈希算法处理后的结果，虽然不是明文密码，但可通过“破解”或“中继”两种方式：

• 破解：若密码强度低（如123456、Admin@123），可通过Hashcat、John the Ripper等工具离线破解出明文
• 中继：无需破解，直接将捕获的认证请求"中继"到其他内网主机，伪装成发起请求的主机登录目标系统(如登录文件服务器、数据库)

2.典型攻击流程(以"访问错误共享文件夹"为例)

1.触发LLMNR请求

内网用户误操作（如输入错误的共享文件夹路径\filserver，正确应为\fileserver），主机先尝试DNS解析filserver，失败后触发LLMNR协议，向局域网多播发送请求：“谁是filserver？请返回 IP”。

2.攻击者伪造响应

攻击者通过 Responder 等工具监听 UDP 5355 端口，实时捕获到该 LLMNR 请求后，立即伪造响应，告知用户主机：“我是filserver，我的 IP 是 192.168.1.100（攻击者主机 IP）”。

3.目标主机发起NTLM认证

用户主机信任该响应，向攻击者 IP（192.168.1.100）发起 SMB 协议连接（访问共享文件夹需 SMB 协议），并自动发送NTLMv2 哈希（用于身份验证，相当于 “加密后的密码凭证”）。

4.攻击者捕获与利用凭据

攻击者的工具（如 Responder）成功捕获 NTLMv2 哈希，后续可：

• 离线破解：用 Hashcat 跑字典，若密码简单，几分钟内即可得到明文（如破解出用户密码为User@2024）；
• 中继攻击：用 Impacket 的py脚本，将捕获的认证请求中继到内网其他主机（如\\192.168.1.200，财务部门的文件服务器），直接登录该服务器获取敏感数据。

LLMNR中毒的关键工具

攻击者常用工具链分工明确，覆盖 “监听 - 捕获 - 利用” 全流程：

LLMNR中毒的防御措施（从协议、配置、管理三方面入手）

LLMNR 中毒的防御核心是 “阻断攻击利用的协议缺陷” 或 “限制凭据泄露后的危害”，具体可落地以下措施：

1.根本防御：禁用LLMNR协议

既然 LLMNR 协议是攻击的 “源头”，直接禁用该协议可从根本上杜绝攻击：

• 单主机配置：
• 打开 “控制面板→网络和共享中心→更改适配器设置”，右键网卡→“属性”，双击 “Internet 协议版本 4（TCP/IPv4）”，点击 “高级→DNS”，勾选 “禁用多播名称解析”。
• 域环境批量配置（推荐）：
• 通过组策略统一禁用，路径：计算机配置→管理模板→网络→DNS客户端→关闭多播名称解析，设置为 “已启用”，适用于企业内网批量管理。

2.阻断中继：启用SMB签名

LLMNR中毒捕获的哈希常被用于“SMB中继攻击”，启用SMB签名可强制SMB通信进行身份验证，防止中继：

组策略路径：计算机配置→Windows设置→安全设置→本地策略→安全选项，找到：

• “Microsoft 网络服务器：数字签名（始终）”→设置为 “已启用”
• “Microsoft 网络客户端：数字签名（始终）”→设置为 “已启用”。

3.减少触发场景：规范DNS解析

LLMNR 仅在 DNS 解析失败时触发，规范内网 DNS 配置可减少 LLMNR 的使用：

• 确保内网所有主机名（如文件服务器、打印机、应用服务器）都已在 DNS 服务器注册，避免用户因 “DNS 查不到” 触发 LLMNR；
• 禁止用户访问未注册的主机名（通过防火墙或组策略限制）。

4.降低危害：强化密码与权限

即使哈希被捕获，强密码和最小权限可降低危害：

• 强制使用复杂密码（如长度≥12 位，包含大小写、数字、特殊符号），增加 Hashcat 破解难度；
• 遵循 “最小权限原则”：普通用户仅授予必要权限（如禁止访问财务、核心业务服务器），避免某一用户凭据泄露后导致内网大范围沦陷。

总结

LLMNR 中毒是典型的 “利用协议缺陷发起的内网攻击”，其危害不仅在于窃取单个主机的凭据，更可能成为攻击者 “横向渗透” 的突破口（从普通主机切入核心服务器）。防御的关键在于禁用 LLMNR 协议（根本措施）+ 启用 SMB 签名（阻断中继）+ 强化密码与权限（降低危害），三者结合可有效抵御这类攻击。

对于企业而言，还需定期进行内网安全扫描（如用 Nessus、OpenVAS 检测 LLMNR 是否启用），并对员工开展安全培训（避免误输入错误主机名触发 LLMNR 请求），形成完整的防御体系。

noxious

Task1

安全团队怀疑Forela内部网络中存在一个流氓设备，运行响应器工具，实施LLMNR毒害攻击。请找到该机器的恶意IP地址。

筛选LLMNR流量

udp.port == 5355

172.17.79.135

Task2

这台流氓机器的主机名是什么？

我们得到了攻击者IP地址，然后可以通过DHCP请求找到该IP地址的主机名

选择 DHCP 协议来获取主机名，是因为DHCP 请求包中会携带客户端的主机名信息

在 DHCP 报文的 “Option 12” 字段中，客户端（这里的 “流氓机器”）会主动填写自己的主机名，并随请求包发送给 DHCP 服务器，用于服务器识别和分配 IP 时关联设备信息。

kali

Task3

现在我们需要确认攻击者是否捕获了用户的哈希值，并且它是否可破解！！被捕获的哈希值的用户名是什么？

筛选SMB2，SMB2是NTLMv2哈希传输的“载体协议”

john.deacon

Task4

在NTLM流量中，我们可以看到受害者凭证多次被中继到攻击者的机器。哈希值第一次捕获是什么时候？

2024-06-24 11:18:30

Task5

受害者在访问文件共享时打错了什么，导致他的资历泄露？

DCC01

Task6

要获得受害者用户的实际凭证，我们需要将多个ntlm协商包的数值拼接在一起。NTLM服务器挑战值是多少？

可以先看第一个包

包9290：SMB2 Session Setup Request（NTLMSSP_NEGOTIATE）

• 行为：客户端（fe80::7994:1860:711...）向服务端（fe80::2068:fe84:5fc...）发起 SMB2 会话建立请求，并在请求中发送NTLMSSP_NEGOTIATE（NTLM 协商消息）。
• 目的：告知服务端 “我支持 NTLMv2 认证”，同时传递客户端的基础信息（如支持的加密方式），启动认证流程。

包9291：SMB2 Session Setup Response（NTLMSSP_CHALLENGE）

• 行为：服务端返回响应，状态码STATUS_MORE_PROCESSING_REQUIRED表示 “认证流程未完成”，同时携带NTLMSSP_CHALLENGE（NTLM 挑战消息）。
• 目的：服务端生成一个 “随机挑战值” 并发送给客户端，要求客户端用这个值加密自己的哈希（这是 NTLMv2 的核心验证步骤）。

包 9292：SMB2 Session Setup Request（NTLMSSP_AUTH）

• 行为：客户端再次发送会话建立请求，携带NTLMSSP_AUTH（NTLM 认证消息），并明确用户为FORELA\john.deacon。
• 目的：客户端用服务端的挑战值加密自己的 NTLMv2 哈希，将加密结果（即 “认证凭证”）返回给服务端，证明自己拥有正确的哈希。

包 9293：SMB2 Session Setup Response（STATUSACCESSDENIED）

• 行为：服务端返回最终响应，状态码STATUS_ACCESS_DENIED表示 “访问被拒绝”。
• 目的：服务端验证客户端的凭证后，认为其不合法（比如哈希错误、用户无权限），拒绝了此次 SMB2 会话的建立。

那么就看9291包

601019d191f054f1

Task7

现在做类似的事情，找出NTProofStr值。

c0cc803a6d9fb5a9082253a04dbd4cd4

Task8

要测试密码复杂度，可以尝试从数据包捕获中获得的信息恢复密码。这是一个关键步骤，因为这样我们就能判断攻击者是否能够破解该系统以及破解的速度。

NTLMv2哈希得结构如下：

USER::DOMAIN:SERVER_CHALLENGE:NTPROOFSTR:NTLMV2RESPONSE

john.deacon::FORELA:601019d191f054f1:c0cc803a6d9fb5a9082253a04dbd4cd4:010100000000000080e4d59406c6da01cc3dcfc0de9b5f2600000000020008004e0042004600590001001e00570049004e002d00360036004100530035004c003100470052005700540004003400570049004e002d00360036004100530035004c00310047005200570054002e004e004200460059002e004c004f00430041004c00030014004e004200460059002e004c004f00430041004c00050014004e004200460059002e004c004f00430041004c000700080080e4d59406c6da0106000400020000000800300030000000000000000000000000200000eb2ecbc5200a40b89ad5831abf821f4f20a2c7f352283a35600377e1f294f1c90a001000000000000000000000000000000000000900140063006900660073002f00440043004300300031000000000000000000

hashcat --force -m 5600 password1.txt /usr/share/wordlists/rockyou.txt

NotMyPassword0k?

Task9

为了更了解事件背景，受害者试图访问的实际文件共享是什么？

\\DC01\DC-Confidential

HTB Reaper(NBNS)

Sherlock Scenario

Our SIEM alerted us to a suspicious logon event which needs to be looked at immediately . The alert details were that the IP Address and the Source Workstation name were a mismatch .You are provided a network capture and event logs from the surrounding time around the incident timeframe. Corelate the given evidence and report back to your SOC Manager.

Task1

What is the IP Address for Forela-Wkstn001?

题目提示我们使用nbns协议

在介绍nbns协议之前，我们要知道windows解析域名的顺序是

• Hosts
• DNS（cache/server）
• LLMNR
• NBNS

如果Hosts文件里面不存在，就会使用DNS解析。如果DNS解析失败，就会使用LLMNR解析，如果LLMNR解析失败，就会使用NBNS解析。

NBNS（NetBIOS Name Service）是 NetBIOS-over-TCP/IP（NBT/NetBT）协议族的核心组件，核心作用是将 16 字节的 NetBIOS 名称解析为 IPv4 地址，以 UDP 137 端口提供命名注册与查询，Windows 的 WINS 是其典型实现，常用于早期局域网设备发现与通信，对应 RFC 1001/1002 标准。

NetBIOS 协议进行名称解析的过程如下：

• 检查本地 NetBIOS 缓存
• 如果缓存中没有请求的名称且已配置了 WINS 服务器，接下来则会向 WINS 服务器发出请求
• 如果没有配置 WINS 服务器或 WINS 服务器无响应则会向当前子网域发送广播
• 如果发送广播后无任何主机响应则会读取本地的 lmhosts 文件

lmhosts 文件位于C:\Windows\System32\drivers\etc\目录中。

NetBIOS 协议进行名称解析是发送的 UDP 广播包。因此在没有配置 WINS 服务器的情况底下，LLMNR协议存在的安全问题，在NBNS协议里面同时存在。使用Responder也可以很方便得进行测试。

172.17.79.129

Task2

What is the IP Address for Forela-Wkstn002?

上图

172.17.79.136

Task3

What is the username of the account whose hash was stolen by attacker?

提示：

在wireshark中筛选ntlmssp协议，或者筛选4624事件ID并寻找异常登录事件。

arthur.kyle

Task4

What is the IP Address of Unknown Device used by the attacker to intercept credentials?

发现另一个可疑的内部IP地址，但未显示主机名。

怀疑这是攻击者作为中间人（MITM）的机器。

同时在日志事件中

172.17.79.135

Task5

What was the fileshare navigated by the victim user account?

提示我们筛选smb2和BADNETWORKNAME

\\DC01\Trip

Task6

What is the source port used to logon to target workstation using the compromised account?

40252

Task7

What is the Logon ID for the malicious session?

依旧是刚刚那个

0x64A799

Task8

The detection was based on the mismatch of hostname and the assigned IP Address.What is the workstation name and the source IP Address from which the malicious logon occur?

FORELA-WKSTN002, 172.17.79.135

Task9

At what UTC time did the the malicious logon happen?

2024-07-31 04:55:16

Task10

What is the share Name accessed as part of the authentication process by the malicious tool used by the attacker?

筛选5140事件

5140（S/F）

已访问网络共享对象

成功 / 失败浏览 / 连接网络共享（如 SMB 共享）

\\*\IPC$

CrownJewel-1

Sherlock Scenario

Forela's domain controller is under attack. The Domain Administrator account is believed to be compromised, and it is suspected that the threat actor dumped the NTDS.dit database on the DC. We just received an alert of vssadmin being used on the DC, since this is not part of the routine schedule we have good reason to believe that the attacker abused this LOLBIN utility to get the Domain environment's crown jewel. Perform some analysis on provided artifacts for a quick triage and if possible kick the attacker as early as possible.

依据NTDS dumping attack detection这篇文章在这个挑战中我们将会用到下面的几个事件ID

首先我们的事件源限定在ESENT中，其中的事件ID325和327分别在创建新数据库和分离数据库时记录这些事件。两者的描述分别如下

事件源 “ESENT”是 Windows 事件日志中与 Extensible Storage Engine (ESE)相关的事件源。ESE 是 Microsoft 的高性能、事务型数据库引擎，被许多 Windows 组件和应用程序用来管理数据存储和访问。我们的Active Directory服务用它来存储目录信息，例如用户、组和计算机对象。

事件ID 7036由 服务控制管理器 (Service Control Manager)生成的，记录在系统日志中，表示服务的启动或停止状态发生了变化。事件描述如下

The [Service Name] service entered the [state] state.

事件ID 4799当某个进程枚举（列出）计算机或设备上某个启用了安全功能的本地组的成员时，会生成此事件。或者说尝试获取某个本地组（如 Administrators 组）的成员信息时。

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page-----2efb81522f2c--------------------------------

A security-enabled local group membership was enumerated.

NTDS.dit

NTDS.dit是 Windows 域控制器的核心数据库文件，存储了AD中的重要信息，存储了所有域控制器的目录服务数据，如用户账户、组信息和计算机对象。具体包括下面的内容：

• 存储 Active Directory 对象：用户账户、计算机账户、组、组织单位 (OU) 等。
• 存储身份验证凭据：包括用户的密码哈希 (如 NTLM、Kerberos 密钥等)。
• 存储安全策略：如组策略对象 (GPO) 和权限信息。
• 等等

我们之前说过我们的事件源来自ESENT，这是因为该文件采用了 Extensible Storage Engine (ESE)数据库技术，支持高效的数据检索和写入。

NTDS.dit文件为LDAP提供底层支持，因此要访问和查询NTDS.dit通常需要专门的工具如ldapsearch或者ntdsutil等等。

非域环境中也有存储着当前主机用户的密码信息的SAM文件，但是他们都需要SYSTEM文件进行解密，他们的路径分别如下：

• dit文件位置: C:\Windows\NTDS\NTDS.dit
• SYSTEM文件位置:C:\Windows\System32\config\SYSTEM
• SAM文件位置:C:\Windows\System32\config\SAM

注：SYSTEM文件和HKEY_LOCAL_MACHINE\SYSTEM注册表配置单元是同一个数据源，只是表现形式不一样

常见攻击方式

在Active Directory服务运行时NTDS.dit被锁定（不允许被复制），但仍然具有非常多的方式提取NTDS.dit文件，这里仅做简单介绍，以后有机会补充

Volume Shadow Copy Service (VSS)

卷影副本技术绕过文件锁定机制进行提取

vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit .

对SYSTEM文件的提取也类似

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\system.hiv
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM C:\sam.hiv

NTDSUTIL.exe

NTDSUTIL 是一个用于管理和维护 Active Directory 域控制器的命令行工具，主要用于进行数据库操作、恢复、备份、清理活动目录等任务。

关于此工具的详细操作可参考https://www.cnblogs.com/suv789/p/18356208

利用如下命令进行副本的复制

ntdsutil "ac i ntds" "ifm" "create full c:\ADBackup" q q

之后会在C盘下创建ADBackup文件夹，文件夹中存有SYSTEM文件和NTDS.dit文件

工具提取

例如使用netexec进行NTDS文件提取

nxc smb IP -u username -p password --ntds

更多的提取方式可参考https://blog.csdn.net/Ping_Pig/article/details/108914583

在本地利用Impacket工具包的secretsdump.py进行密码提取

python3 secretsdump.py -ntds ntds.dit -system system.hiv LOCAL

MFT

MFT（Master File Table，主文件表），用于存储文件和目录的元数据。每个 NTFS 卷都包含一个 $MFT，它是 NTFS 文件系统的关键部分。

MFT包含以下信息：

• 文件和目录的属性：包括权限、所有者、创建时间、修改时间、访问时间等。
• 文件数据的物理位置：MFT记录了文件数据在磁盘上的存储位置。
• 文件名：MFT中存储了文件和目录的名称。

注：

• 即使文件被删除，$MFT 条目可能仍然保留，可以通过分析条目恢复被删除的文件。
• 通过分析 $MFT，可以追踪文件的创建、修改和删除活动。
• 删除文件的 $MFT 条目通常会被标记为未使用，但实际数据可能尚未被覆盖。
• 文件数据驻留在 $MFT 中时，不会占用磁盘空间，可能被用于隐藏恶意文件。

Task1

Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state.

我们首先要确定卷影复制服务进入运行状态的时间，在SYSTEM.evtx中寻找ID为7036的事件，然后搜索volume shadow copy服务

事件ID 7036由 服务控制管理器 (Service Control Manager)生成的，记录在系统日志中，表示服务的启动或停止状态发生了变化。事件描述如下

The [Service Name] service entered the [state] state.

2024-05-14 03:42:16

Task2

When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the two user groups the volume shadow copy process queries and the machine account that did it.

找到卷影复制进程查询的两个用户组以及执行该操作的计算机账户，在Security.evtx中筛选4799事件，并查找卷影服务进程VSSVC.exe

事件ID 4799当某个进程枚举（列出）计算机或设备上某个启用了安全功能的本地组的成员时，会生成此事件。或者说尝试获取某个本地组（如 Administrators 组）的成员信息时。 

Administrators, Backup Operators, DC01$

Task3

Identify the Process ID (in Decimal) of the volume shadow copy service process.

卷影复制服务进程ID的10进制

0x1190

4496

Task4

Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted.

找到挂载时为影子副本快照分配的卷ID/GUID值。

在Microsoft-Windows-NTFS.evtx中过滤事件ID 4，这标志着NTFS卷已成功挂载，找到ShadowCopy即可

{06c4a997-cca8-11ed-a90f-000c295644f9}

Task5

Identify the full path of the dumped NTDS database on disk.

确定磁盘上转储的NTDS数据库的完整路径。

利用Eric Zimmerman个人网站中的MFT Explorer打开MFT文件

Eric Zimmerman's tools

MFT（Master File Table，主文件表），用于存储文件和目录的元数据。每个 NTFS 卷都包含一个 $MFT，它是 NTFS 文件系统的关键部分。

C:\Users\Administrator\Documents\backupsyncDc\Ntds.dit

Task6

When was newly dumped ntds.dit created on disk?

新转储的ntds.dit是什么时候在磁盘上创建的？

2024-05-14 03:44:22

Task7

A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes?

还与NTDS数据库一同转储了一个注册表蜂箱。是哪个注册箱蜂箱被转储？它的文件大小是多少字节？

SYSTEM

17,563,648

CrownJewel-2

Sherlock Scenario

Forela's Domain environment is pure chaos. Just got another alert from the Domain controller of NTDS.dit database being exfiltrated. Just one day prior you responded to an alert on the same domain controller where an attacker dumped NTDS.dit via vssadmin utility. However, you managed to delete the dumped files kick the attacker out of the DC, and restore a clean snapshot. Now they again managed to access DC with a domain admin account with their persistent access in the environment. This time they are abusing ntdsutil to dump the database. Help Forela in these chaotic times!!

Task1

When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process?

利用ntdsutil.exe将NTDS转储到磁盘时，同时使用Microsoft影子复制服务。该服务最近进入运行状态的时间戳是什么，表明可能启动NTDS倾销过程？

我们在CrownJewel-1中说到了事件ID 7036由SYSTEM.evtx日志生成，记录服务的启动或停止状态发生了变化，我们仅需在SYSTEM.evtx中过滤事件ID 7036，然后查找包含Volume Shadow Copy服务的日志条目即可

2024-05-15 05:39:55

Task2

Identify the full path of the dumped NTDS file.

确定转储NTDS文件的完整路径。

事件ID 325在创建数据库时被记录在APPLICATION.evtx中，过滤出来，并寻找和上面ntdsutil.exe将NTDS转储到磁盘上的时间相符的事件

C:\Windows\Temp\dump_tmp\Active Directory\ntds.dit

Task3

When was the database dump created on the disk?

数据库转储是在什么时候创建的？

2024-05-15 05:39:56

Task4

When was the newly dumped database considered complete and ready for use?

新导出的数据库什么时候被认为完整且可以使用？

当数据库引擎分离了转储的NTDS.dit数据库副本时，表明此数据库已经可被使用，此时会触发327事件表示分离数据库的操作

可以看到有两个日志

根据事件的事件可以推测两次的数据库分离都是发生在攻击事件的过程中，获取事件发生的事件时需要注意一下事件查看器面板中关于事件的常规信息显示的时间戳是根据计算机配置的时区显示的

2024-05-15 05:39:58

Task5

Event logs use event sources to track events coming from different sources. Which event source provides database status data like creation and detachment?

事件日志利用事件源来追踪来自不同来源的事件。哪个事件源提供数据库状态数据，比如创建和分离？

事件源ESENT是 Windows 事件日志中与Extensible Storage Engine (ESE)相关的事件源。ESE 是 Microsoft 的高性能、事务型数据库引擎，被许多 Windows 组件和应用程序用来管理数据存储和访问。我们的Active Directory服务用它来存储目录信息，例如用户、组和计算机对象。

ESENT

Task6

When ntdsutil.exe is used to dump the database, it enumerates certain user groups to validate the privileges of the account being used. Which two groups are enumerated by the ntdsutil.exe process? Give the groups in alphabetical order joined by comma space.

当ntdsutil.exe用于转储数据库时，会枚举某些用户组以验证所使用账户的权限。ntdsutil.exe过程列举了哪两类？按字母顺序排列并加逗号的组。

我们在CrownJewel-1中说到了当某个进程枚举计算机或设备上某个启用了安全功能的本地组的成员时，会生成4799事件。我们在Security.evtx中筛选一下，并查找与ntdsutil进程有关的事件

Administrators, Backup Operators

Task7

Now you are tasked to find the Login Time for the malicious Session. Using the Logon ID, find the Time when the user logon session started.

现在你的任务是找到恶意会话的登录时间。利用登录ID，查找用户登录会话开始的时间。

其中登录ID也在上面了

0x8DE3D

查找恶意会话的登录时间我们需要用到几个事件ID

事件ID 4768

• 此事件表示某个用户请求了 Kerberos TGT（Ticket Granting Ticket），即首次登录 AD 域时的身份验证过程。
• 常见用途有：标志某个用户尝试登录域，检测登录尝试、密码猜测行为（频繁失败的4768），以及横向移动
• 关键字段有
  • Account Name：请求票据的用户。
  • Client Address：发起请求的IP地址。
  • Result Code：认证结果（如 0x0 表示成功，0x6 表示用户名无效，0x18 表示密码错误）。

事件 ID 4769

• 当用户已经拥有 TGT 后，请求访问具体服务时，系统会请求TGS，此时记录该事件。
• 常见用途：检测用户访问了哪些服务，可以帮助分析横向移动（例如使用有效凭据访问其他主机上的服务）
• 关键字段：
  • Service Name：目标服务（如 CIFS、HOST 等）。
  • Client Address：发起访问的IP地址。
  • Ticket Encryption Type：可以用于发现弱加密算法（如 RC4）。

事件 ID 5379

• 该事件表示访问了加密密钥材料，如：凭据保护、DPAPI、Credman(Credential Manager) 凭据或密钥保护等。
• 常见用途为：
  • 检测敏感信息访问，如查看某用户的 Windows 凭据、密钥或使用 Windows Hello、虚拟智能卡。
  • 可用于发现恶意软件访问用户凭据的行为。
• 关键字段：
  • Caller Process Name：访问密钥的进程。
  • Subject User Name：发起访问的用户。
  • Key Type：访问的是哪种密钥，比如 User DPAPI, Virtual Smart Card, Windows Hello, Generic Credentials。

我们先筛选4768,4769

再加入5379事件，此事件中包含我们在上面找到的登录ID0x8DE3D

2024-05-15 05:36:31