The Game of Domain Dominance
域名优势博弈

Just as in the political landscape of Westeros, defenders face a dynamic adversarial relationship…except instead of fighting rival families, defenders are locked into a struggle with innovators on the offensive side of cybersecurity. This innovation manifests in the form of evolving tradecraft and tooling, and defenders must stand ready to reclaim and fortify their domain’s sovereignty. An organization’s users must have trust in both the domain and the fidelity of its architecture. This concept is important in maintaining your organization’s operational efficiency and making sure that client and proprietary data are secure.
就像在维斯特洛的政治格局中一样，捍卫者面临着一种动态的对抗关系……除了与敌对家庭作战之外，捍卫者陷入了与网络安全进攻方面的创新者的斗争。这种创新体现在不断发展的贸易技术和工具的形式上，捍卫者必须随时准备收回和加强其领地的主权。组织的用户必须信任域及其体系结构的保真度。此概念对于维护组织的运营效率并确保客户端和专有数据的安全非常重要。

Adversaries constantly seek ways to access and maintain presence in your domain. Assuming they’ve achieved persistence and there’s evidence of their activity, defenders typically concentrate on the methods used for access, and overlook the post-breach domain environment.
对手不断寻求访问和维持您域中存在的方法。假设他们已经实现了持久性，并且有证据表明他们的活动，防御者通常专注于用于访问的方法，而忽略了违规后的域环境。

Typically, that post-breach recovery relies on surface level fixes: “rotating the KRBTGT password twice”, “increasing the available RID pool”, etc. What we are interested in exploring is what defenders can do beyond those steps. How do defenders truly reclaim control over their domain? How do they recover operational efficiency without compromising trust or security through the recovery process? What portions of the organization’s recovery process meet a minimum expectation to cut back the adversary’s stolen access?
通常，违规后恢复依赖于表面级别的修复：“轮换 KRBTGT 密码两次”、“增加可用的 RID 池”等。我们感兴趣的是，除了这些步骤之外，捍卫者还能做些什么。防御者如何真正夺回对其领域的控制权？他们如何在不影响信任或安全的情况下通过恢复过程恢复运营效率？组织的恢复过程的哪些部分满足了减少对手被盗访问权限的最低期望？

This post will explore techniques adversaries use to gain and sustain access within a domain, including credential dumping on domain controllers, Active Directory configuration syncing, Kerberos protocol manipulation, and certificate abuse. Additionally, we’ll discuss effective recovery strategies, aiming for a more satisfying resolution than the Game of Thrones finale.
这篇文章将探讨攻击者用来获取和维持域内访问权限的技术，包括域控制器上的凭据转储、Active Directory 配置同步、Kerberos 协议操作和证书滥用。此外，我们将讨论有效的恢复策略，旨在获得比《权力的游戏》结局更令人满意的解决方案。

Attack Technique Format 攻击技术格式

This blog covers multiple Kerberos abuse based attack techniques, detection guidance and remediation of a compromised domain. Due to the extensive length of these topics, we think it is important to provide the attack techniques in a concise and predictable format. Each attack technique discussed will have the following sections:
本博客介绍了多种基于 Kerberos 滥用的攻击技术、检测指南和受损域的修正。由于这些主题篇幅很长，我们认为以简洁且可预测的格式提供攻击技术非常重要。讨论的每种攻击技术将包含以下部分：

Overview: 概述：

• We will cover a brief description of the target technique.
  我们将简要介绍目标技术。
• We will cover the technology that is required of the target technique.
  我们将介绍目标技术所需的技术。
• We will cover the motivation and use of the target technique.
  我们将介绍目标技术的动机和使用。

Execution: 执行：

• We will cover how the attack is performed.
  我们将介绍如何执行攻击。
• We will mention any related blogs, tools, or variations of the attack performance.
  我们将提及任何相关的博客、工具或攻击性能的变体。

Detection: 检波：

• We will cover the Sysmon and Windows Security event IDs related to discovering the target technique.
  我们将介绍与发现目标技术相关的 Sysmon 和 Windows 安全事件 ID。

TLDR; If you’re familiar with the techniques listed below and want to review the remediation guidance, jump to the “Reclaiming the Iron Throne” section.
TLDR;如果你熟悉下面列出的技术并想要查看修正指南，请跳转到“夺回铁王座”部分。

(But who would want to start on the last season of a show?)
（但谁会想从节目的最后一季开始呢？

Spotting and Stopping Persistent Invaders
发现并阻止顽固的入侵者

Nation state affiliated threat actors such as FIN6, NICKEL, and Emissary Panda targeted critical Active Directory assets, notably the (Windows NT Directory Services) NTDS.dit file, the KRBTGT service account, and Active Directory certificates. They often gained initial access through phishing or exploiting vulnerabilities, then used a combination of native and custom tools to persist within the domain with elevated credentials. Emissary Panda, for instance, exploited a widespread SharePoint vulnerability, indicating a broader, more widespread approach rather than a focused target selection. Once defenders confirm a breach and an IR or triage team has eliminated the immediate threat, the focus should shift to blocking adversary access and rotating domain secrets. In order to avoid a compromise, detection engineers should prioritize identifying signs of domain persistence in the environment.
国家附属威胁行为者，如FIN6，NICKEL和Emissary Panda，针对关键的Active Directory资产，特别是（Windows NT Directory Services）NTDS.dit文件，KRBTGT服务帐户和Active Directory证书。他们通常通过网络钓鱼或利用漏洞获得初始访问权限，然后使用本机和自定义工具的组合，以提升的凭据在域中保留。例如，使者熊猫利用了广泛的SharePoint漏洞，表明了一种更广泛，更广泛的方法，而不是集中的目标选择。一旦防御者确认存在漏洞，并且 IR 或分类团队消除了直接威胁，重点应转移到阻止对手访问和轮换域机密上。为了避免泄露，检测工程师应优先识别环境中域持久性的迹象。

In the following section, this post will explore techniques adversaries use to maintain elevated privileges and the detection methods that help identify the “burn down the domain” scenario.
在下一节中，本文将探讨攻击者用于维护提升的权限的技术，以及有助于识别“烧毁域”方案的检测方法。

Credential Theft on the Domain Controller
域控制器上的凭据盗窃

Overview 概述

Adversaries with elevated access to a domain controller (such as domain administrator, enterprise admin, or local administrator) can execute credential theft by utilizing applications to obtain a handle to the LSASS.exe process.
对域控制器具有提升访问权限的对手（如域管理员、企业管理员或本地管理员）可以通过利用应用程序获取 LSASS.exe 进程的句柄来执行凭据盗窃。

The Local Security Authority Server Service (LSASS) handles the authentication of users within a domain. LSASS is critical in servicing the Kerberos Distribution Center (KDC) and the Keberos authentication protocol by generating tokens for requested resources. Whenever a user interactively authenticates to a domain controller, the accounts credential material is cached into the memory of the LSASS.exe process. Active Directory clients can use preventive mechanisms like Credential Guard to isolate the copy of the LSASS.exe process that contains cached credentials. When adversaries attempt to obtain a handle to LSASS.exe with read access rights, the version of LSASS.exe available to them will not contain those cached credentials and instead the credentials are located in the isolated version of LSASS.exe.. However, domain controllers don’t enable Credential Guard because of application compatibility issues.
本地安全机构服务器服务 （LSASS） 处理域中用户的身份验证。LSASS 通过为请求的资源生成令牌，在为 Kerberos 分发中心 （KDC） 和 Keberos 身份验证协议提供服务方面至关重要。每当用户以交互方式向域控制器进行身份验证时，帐户凭据材料都会缓存到 LSASS.exe 进程的内存中。Active Directory 客户端可以使用凭据保护等预防性机制来隔离包含缓存凭据的 LSASS.exe 进程的副本。当攻击者尝试获取具有读取访问权限的 LSASS.exe 句柄时，他们可用的 LSASS.exe 版本将不包含这些缓存的凭据，而是凭据位于 LSASS.exe 的独立版本中。但是，由于应用程序兼容性问题，域控制器不会启用凭据保护。

Adversaries with sufficient access rights can obtain a handle to the LSASS.exe process on domain controllers and read the virtual memory of the LSASS.exe process, which contains cached credentials. Using these stolen credentials, adversaries can change their execution context to access high-valued resources and perform actions that could significantly impact an organization’s business continuity.
具有足够访问权限的攻击者可以在域控制器上获取 LSASS.exe 进程的句柄，并读取包含缓存凭据的 LSASS.exe 进程的虚拟内存。使用这些被盗凭据，攻击者可以更改其执行上下文以访问高价值资源并执行可能对组织的业务连续性产生重大影响的操作。

Execution 执行

This technique can be conducted via many publicly available tools and native “living-off-the-land” Windows binaries (e.g., Task Manager) that can obtain a handle to LSASS.exe with the access rights needed to read the virtual memory of this process.
此技术可以通过许多公开可用的工具和本机“离地生活”Windows二进制文件（例如，任务管理器）进行，这些二进制文件可以获得LSASS的句柄.exe具有读取此过程的虚拟内存所需的访问权限。

Using the Sysinternals suite a user can obtain a handle to the LSASS.exe process with read access rights to the virtual memory of the process. PsExec can remotely call a local copy of ProcDump to create a process dump of the LSASS.exe process.
使用 Sysinternals 套件，用户可以获取 LSASS.exe 进程的句柄，并具有对该进程虚拟内存的读取访问权限。PsExec 可以远程调用 ProcDump 的本地副本来创建 LSASS.exe 进程的进程转储。

./PsExec.exe -s accepteula \\dc1.asgard.corp -u asgard\da -p <PASSWORD> C:\Sysinternals\procdump.exe -accepteula lsass.exe C:\temp\totally_not_lsass.dmp

Detection 检波

When an application requests an open handle to the LSASS.exe process using access rights that enable the application to read the virtual memory of the process, Sysmon will generate event ID 10 — “ProcessAccess.” Detection engineers will need to pair this process access attempt with additional process context specific to the target process of LSASS.exe or the application that obtained the handle to the LSASS.exe process. Natively, many applications will open a handle to the LSASS.exe process; which forces detection engineers to identify additonal telemetry to correlate the behavior.
当应用程序使用访问权限请求 LSASS.exe 进程的打开句柄时，使应用程序能够读取进程的虚拟内存，Sysmon 将生成事件 ID 10 — “ProcessAccess”。检测工程师需要将此进程访问尝试与特定于 LSASS 目标进程的其他进程上下文配对.exe或获取 LSASS.exe 进程句柄的应用程序。本机，许多应用程序将打开 LSASS.exe 进程的句柄;这迫使检测工程师识别其他遥测数据以关联行为。

Additionally, in his blog, Olaf Hartong suggests monitoring the process access attempt in conjunction with Windows Security event ID 4703 — “A token right was adjusted.” This event indicates when a user elevates the process integrity to high integrity, enabling SeDebugPrivilege, and obtains a new access token. The monitoring of process integrity elevation uses the assumption that the adversary will request all access rights to obtain a handle to the LSASS.exe process and read its virtual memory. While variances in technique execution exist to avoid requesting all access rights with SeDebugPrivilege, a dedicated detection engineering can build upon these and other detection recommendations.
此外，Olaf Hartong 在他的博客中建议结合 Windows 安全事件 ID 4703 来监视进程访问尝试 – “令牌权限已调整”。此事件指示用户何时将进程完整性提升到高完整性，从而启用 SeDebugPrivilege，并获取新的访问令牌。进程完整性提升的监视使用以下假设：攻击者将请求所有访问权限以获取 LSASS.exe 进程的句柄并读取其虚拟内存。虽然技术执行存在差异以避免使用 SeDebugPrivilege 请求所有访问权限，但专门的检测工程可以基于这些和其他检测建议进行构建。

NTDS Access 被忽视的热带病访问

Overview 概述

Criminal actors target the NTDS.dit file of organizations by accessing or copying the database file in an attempt to harvest credentials from the organization.
犯罪分子通过访问或复制数据库文件来瞄准组织的 NTDS.dit 文件，试图从组织获取凭据。

The NTDS.dit file is the main database for Microsoft’s Active Directory data. The NTDS.dit file is used by Active Directory to manage and organize users, groups, security descriptors and password hashes. This file is stored on domain controllers typically under the location of %SystemRoot%\NTDS. Active Directory constantly uses the NTDS.dit file for Active Directory processes such as the KDC, and the domain controller deadlocks the file to avoid system errors (Figure 1). If a user attempts to manipulate the NTDS.dit file, this action will cause a SHARING_VIOLATION flag due to the file lock.
NTDS.dit文件是Microsoft的活动目录数据的主要数据库。NTDS.dit文件由Active Directory用于管理和组织用户，组，安全描述符和密码哈希。此文件存储在域控制器上，通常位于 %SystemRoot%\NTDS 的位置下。Active Directory 不断将 NTDS.dit 文件用于 Active Directory 进程（如 KDC），域控制器会死锁该文件以避免系统错误（图 1）。如果用户尝试操作 NTDS.dit 文件，此操作将导致由于文件锁定而导致SHARING_VIOLATION标志。

Adversaries must use techniques that avoid the deadlock and generate a copy of the file to exfiltrate the Active Directory data. Once an adversary has exfiltrated the NTDS.dit and a copy of the SYSTEM registry hive, adversaries can extract secrets and and the entire directory with tools such as ntdsdotsqlite or DSInternals.
攻击者必须使用避免死锁并生成文件副本以泄露 Active Directory 数据的技术。一旦攻击者泄露了NTDS.dit和SYSTEM注册表配置单元的副本，攻击者就可以使用ntdsdotsqlite或DSInternals等工具提取机密和整个目录。

Execution 执行

Several native Windows binaries exist for generating backups of the Active Directory database and copying the deadlocked NTDS.dit file. Most of these tools make use of the (Volume Shadow Service) VSS.
存在几个本机Windows二进制文件，用于生成Active Directory数据库的备份并复制死锁的NTDS.dit文件。这些工具中的大多数都使用（卷影服务）VSS。

To generate a backup of the Active Directory database, the following tools can be utilized in conjunction with the below commands:
要生成 Active Directory 数据库的备份，可以将以下工具与以下命令结合使用：

Ntdsutil.exe “ac i ntds” “ifm” “create full C:\programdata\cache”

Vssadmin.exe create shadow /for=C
Copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\ntds\ntds.dit C:\ntds.dit
Copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\SYSTEM c:\SYSTEM

esentutl.exe /y /vss c:\windows\ntds\ntds.dit /d c:\folder\ntds.dit

Detection 检波

Most open-source detection strategies that exist for detecting the access of the NTDS.dit file do so with process execution telemetry that focuses on the the word “ntds” or the name of the suspected process (e.g., “vssadmin.exe”) within the command line arguments. While these brittle detections have their place within the detection and response program, detection strategies surrounding the access of the NTDS.dit should be the emphasis in broader detections.
用于检测 NTDS.dit 文件访问的大多数开源检测策略都使用进程执行遥测来实现，该遥测侧重于命令行参数中的单词“ntds”或可疑进程的名称（例如“vssadmin.exe”）。虽然这些脆弱的检测在检测和响应程序中占有一席之地，但围绕NTDS.dit访问的检测策略应该是更广泛检测的重点。

Regardless, if the adversary utilizes ntdsutil.exe, vssadmin.exe, or esentutl.exe to create a backup or volume shadow copy; several Volume Snapshot Service based Windows Security event IDs are generated specific to the creation of the copy. As all of the above methods of execution use Volume Shadow technology; defenders can use events specific to the use of the VSS as a common denominator for detections.
无论如何，如果攻击者使用 ntdsutil.exe、vssadmin.exe 或 esentutl.exe 来创建备份或卷影副本;将生成多个特定于副本创建的基于卷快照服务的 Windows 安全事件 ID。由于上述所有执行方法都使用卷影技术;防御者可以使用特定于使用 VSS 的事件作为检测的公分母。

Once the backup applications begin, a sequential process creation for VSSVC.exe (the Volume Snapshot Service) is executed by services.exe.
备份应用程序启动后，VSSVC.exe（卷快照服务）的顺序进程创建将由服务.exe执行。

Additionally, a Windows Security event ID 8222 — “Shadow copy has been created” will be generated upon the use of any of these tools when a backup of the NTDS is created (Figure 2).
此外，在创建 NTDS 的备份时，使用这些工具中的任何一个时，将生成 Windows 安全事件 ID 8222 — “已创建卷影副本”（图 2）。

Finally, defenders can leverage anomaly detections for the access of the Security Account Manager (SAM). To generate a shadow copy of a C:\ drive, a READ_CONTROL handle is requested for the access of the SAM with Windows Security event ID 4661 in mass over a short period of time (Figure 3). The mass requests of object handles for the SAM is often a very easy anomaly detection to implement and can be correlated to multiple other techniques as well.
最后，防御者可以利用异常检测来访问安全帐户管理器 （SAM）。要生成 C：\ 驱动器的卷影副本，需要请求一个READ_CONTROL句柄，以便在短时间内大量访问 Windows 安全事件 ID 为 4661 的 SAM（图 3）。SAM 的对象句柄的批量请求通常是一种非常容易实现的异常检测，并且还可以与多种其他技术相关联。

DCSync

Overview 概述

A DCSync attack exploits the trust relationship within the underlying Windows environment in an attempt to gain unauthorized access to user credentials by syncing a copy of Active Directory data. Directory Replication Service (DRS) is the method by which the Windows Active Directory Domain Service ensures that a change made on one domain controller replicates to all domain controllers. Active Directory replication is facilitated by connection objects that represent replication pathways between source and destination domain controllers. Each of these objects have attributes related to access and permissions. When a change to these objects occurs on one domain controller, the other domain controllers will sync these value changes throughout the Active Directory schema. Additionally, this replication ensures consistent object attributes in the event that a domain controller is offline or otherwise experiencing failure. The extended rights required to conduct a Active Directory replication are:
DCSync 攻击利用底层 Windows 环境中的信任关系，试图通过同步 Active Directory 数据的副本来未经授权访问用户凭据。目录复制服务 （DRS） 是 Windows Active Directory 域服务确保在一个域控制器上所做的更改复制到所有域控制器的方法。表示源域控制器和目标域控制器之间的复制路径的连接对象可促进 Active Directory 复制。其中每个对象都具有与访问和权限相关的属性。当一个域控制器上发生对这些对象的更改时，其他域控制器将在整个 Active Directory 架构中同步这些值更改。此外，此复制可确保在域控制器脱机或遇到故障时一致的对象属性。执行 Active Directory 复制所需的扩展权限包括：

The MS-DSRS RPC protocol uses the RPC method GetNCChanges request and replies in conjunction with the RPC interface (Directory Replication Service Update API) DRSUAPI network protocol to sync active directory changes. Typically, this occurs from primary to backup domain controllers. Adversaries make use of this RPC method to replicate sensitive data (e.g., password hashes) from Active Directory.
MS-DSRS RPC 协议使用 RPC 方法 GetNCChanges 请求和回复与 RPC 接口（目录复制服务更新 API）DRSUAPI 网络协议相结合来同步活动目录更改。通常，从主域控制器到备份域控制器都会发生这种情况。攻击者利用此 RPC 方法从 Active Directory 复制敏感数据（例如密码哈希）。

Execution 执行

A wide variety of public open-source tooling (e.g., Rubeus, Mimikatz, etc.) can use the the RPC method GetNCChanges to sync Active Directory data . Once the adversary has gained access to a compromised account with the sufficient privileges required, they can leverage the compromised account permissions to execute a DCSync and target specific accounts or all of the accounts.
各种各样的公共开源工具（例如，Rubeus，Mimikatz等）可以使用RPC方法GetNCChanges来同步Active Directory数据。一旦攻击者获得了对具有所需足够权限的已泄露帐户的访问权限，他们就可以利用已泄露的帐户权限来执行 DCSync 并针对特定帐户或所有帐户。

To replicate accounts from Active Directory, adversaries can use the GetNCChanges RPC method to request sensitive data from the domain controller.
若要从 Active Directory 复制帐户，攻击者可以使用 GetNCChanges RPC 方法从域控制器请求敏感数据。

lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /all /csv

Detection 检波

When domain controllers replicate, they generate a corresponding event ID 4662, provided the domain controller pulling the sync has Directory Replication Service auditing enabled (Figure 4). Machine accounts usually handle Active Directory replication, so a user or service account appearing in the 4662 event would be noticeable. However, some custom replication services in client environments use a service account to replicate credentials. Still, administrators can often manage the allowlist for DCSync replication, making this alert easy to baseline.
域控制器复制时，如果拉取同步的域控制器启用了目录复制服务审核，它们会生成相应的事件 ID 4662（图 4）。计算机帐户通常处理 Active Directory 复制，因此出现在 4662 事件中的用户或服务帐户会很明显。但是，客户端环境中的某些自定义复制服务使用服务帐户来复制凭据。不过，管理员通常可以管理 DCSync 复制的允许列表，从而使此警报易于确定基线。

In some situations, the adversary may already have gained local administrative access to the domain controller. Whenever DCSync is occurring locally on the domain controller, the network data will not traverse typical outbound/inbound interfaces, but instead use the local loopback (Figure 5). This method of DCSync will avoid most network-based detections because there wouldn’t be any system-to-system communication. The intercommunication occurs between two processes on the same system.
在某些情况下，攻击者可能已获得对域控制器的本地管理访问权限。每当 DCSync 在域控制器上本地发生时，网络数据将不会遍历典型的出站/入站接口，而是使用本地环回（图 5）。DCSync 的此方法将避免大多数基于网络的检测，因为不会有任何系统到系统的通信。相互通信发生在同一系统上的两个进程之间。

Golden Tickets 黄金门票

Overview 概述

The Red Wedding in The Rains of Castamere, S3:E9, is memorable for its unexpected brutality. (#robbshouldhavelived). Adversaries who have established a foothold in an environment use a similar surprise element by imitating legitimate ticket requests. Adversaries can utilize the golden ticket technique to help them evade detection and maintain persistence.
《卡斯塔米尔之雨》（S3：E9）中的红色婚礼因其出人意料的残酷而令人难忘。（#robbshouldhavelived）。在环境中站稳脚跟的对手通过模仿合法的票证请求来使用类似的惊喜元素。攻击者可以利用黄金票证技术来帮助他们逃避检测并保持持久性。

The Kerberos authentication protocol makes use of ticket requests and grants to authenticate users to remote resources. The KRBTGT is a dedicated service account whose password is used to generate a key. This key is the one-way hashed transformation of the KRBTGT account’s password. The KDC uses this key to sign and encrypt (ticket-granting tickets) TGTs which are presented to the remote resources. Kerberos inherently trusts any TGT encrypted with the KRBTGT password hash. If an adversary compromises the KRBTGT’s password hash, the adversary can then generate their own TGTs and bypass the KDC completely. Adversaries can then use this illegitimate TGT, signed and encrypted with the KRBTGT’s password hash to authenticate to remote resources where Kerberos authentication is required. For more in depth information about the Kerberos authentication protocol, please visit the many available resources that cover this protocol in depth.
Kerberos 身份验证协议利用票证请求和授权对远程资源的用户进行身份验证。KRBTGT 是一个专用服务帐户，其密码用于生成密钥。此密钥是 KRBTGT 帐户密码的单向哈希转换。KDC 使用此密钥对提供给远程资源的 TGT 进行签名和加密（票证授予票证）。Kerberos 本质上信任使用 KRBTGT 密码哈希加密的任何 TGT。如果攻击者破坏了 KRBTGT 的密码哈希，则攻击者可以生成自己的 TGT 并完全绕过 KDC。然后，攻击者可以使用此非法 TGT（使用 KRBTGTT 的密码哈希进行签名和加密）对需要 Kerberos 身份验证的远程资源进行身份验证。有关 Kerberos 身份验证协议的更深入信息，请访问深入介绍此协议的许多可用资源。

Execution 执行

Adversaries can craft a new TGT with the following ticket parameters:
攻击者可以使用以下票证参数创建新的 TGT：

• (Fully Qualified Domain Name) FQDN of the domain
  （完全限定域名）域的 FQDN
• (Security Identifier) SID of the domain
  （安全标识符）域的 SID
• Account to impersonate 要模拟的帐户
• KRBTGT password hash KRBTGT 密码哈希

Once an adversary passes this information to a crafted ticket, the adversary can then save the crafted ticket in the current session’s ticket cache.
一旦攻击者将此信息传递给构建的票证，攻击者就可以将构建的票证保存在当前会话的票证缓存中。

mimikatz.exe “kerberos::golden /domain:dc.asgard.corp /sid:S-1–5–21–4198639423–1025486511–2226459690 /rc4:a8bbd83cc1ded03f7db3b07d78e95036 /user:da /id:500 /ptt”

Detection 检波

Golden ticket detection methods can focus on the theft of the KRBTGT password hash or the anomalous use of the KRBTGT account itself. From the perspective of the ticket request, the Windows Security events generated look the same whether its a legitimate TGT request or a request related to the golden ticket attack (4768 and 4769). This forces detection engineers to focus their detection efforts on the theft of the KRBTGT password hash, rather than on the use of that credential material to carry out a golden ticket attack (credential theft on the domain controller, NTDS.dit access, and DCSync).
黄金票证检测方法可以专注于 KRBTGT 密码哈希的盗窃或 KRBTGT 帐户本身的异常使用。从票证请求的角度来看，生成的 Windows 安全中心事件看起来是相同的，无论是合法的 TGT 请求还是与黄金票证攻击相关的请求（4768 和 4769）。这迫使检测工程师将其检测工作集中在 KRBTGT 密码哈希的盗窃上，而不是使用该凭据材料执行黄金票证攻击（域控制器上的凭据盗窃、NTDS.dit 访问和 DCSync）。

Defenders can track group membership changes of users from source hosts identified in earlier detection strategies. Windows Security event ID 4627 -” Group Membership Information” displays the logged-on account’s group memberships. We showcased the difference in group memberships between a legitimate logon (timestamp 00:37) and a Golden Ticket attack (timestamp 00:35) for user bouj33boy (Figure 6).
防御者可以跟踪来自早期检测策略中标识的源主机的用户的组成员身份更改。Windows 安全中心事件 ID 4627-“组成员身份信息”显示登录帐户的组成员身份。我们展示了用户 bouj33boy 的合法登录（时间戳 00：37）和黄金票证攻击（时间戳 00：35）之间的组成员身份差异（图 6）。

In the screenshot, the SID S-1–5–21…-512 corresponds to the Domain Admins group. To reduce noise in 4627 events, use a Security group for Domain Admins instead of assigning them individually. This way, 4627 events from individual users become inherently suspicious and merit investigation.
在屏幕截图中，SID S-1–5–21…-512 对应于域管理员组。若要减少 4627 事件中的干扰，请为域管理员使用安全组，而不是单独分配它们。这样，来自个人用户的 4627 事件本质上变得可疑，值得调查。

An additional detection method relies upon tracking (ticket-granting-service ticket request) TGS-REQs (Windows Security event ID: 4769) that have no corresponding (Authentication Service Request) AS-REQ (Windows Security event ID: 4768). Additionally, some resources explain that forged tickets may not properly display FQDNs when the TGT is forged.
另一种检测方法依赖于没有相应（身份验证服务请求）AS-REQ（Windows 安全事件 ID：4768）的跟踪（票证授予服务票证请求）TGS-REQ（Windows 安全事件 ID：4769）。此外，一些资源解释说，伪造 TGT 时，伪造的票证可能无法正确显示 FQDN。

To validate a suspected Golden Ticket event, use the klist command to list the Kerberos tickets for that user. When an adversary imports the stolen KRBTGT ticket, it triggers a sequential event ID 4624 for a successful logon. This event provides the user’s logon ID, and klist can then show the user’s ticket cache (Figure 7).
若要验证可疑的黄金票证事件，请使用 klist 命令列出该用户的 Kerberos 票证。当攻击者导入被盗的 KRBTGT 票证时，它会触发顺序事件 ID 4624 以成功登录。此事件提供用户的登录 ID，然后 klist 可以显示用户的票证缓存（图 7）。

Diamond Tickets 钻石门票

Overview 概述

Adversaries can avoid crafting their own TGTs and instead opt to modify a legitimately issued TGT from the domain controller. To obtain a legitimate TGT, adversaries can use the (Generic Security Service) GSS-API and obtain a TGT for a user without requiring the user’s password or NTLM\AES hash. The GSS-API provides a standardized way for applications to use the Kerberos security provider. The adversary can use the AcquireCredentialsHandle and InitializeSecurityContext function calls with the ISC_REQ_DELEGATE flag to coerce the domain controller to provide a (Application Request) AP-REQ in the GSS-API output containing the KRB_CRED in the authenticator checksum.
攻击者可以避免创建自己的 TGT，而是选择从域控制器修改合法颁发的 TGT。若要获取合法的 TGT，攻击者可以使用（通用安全服务）GSS-API 并为用户获取 TGT，而无需用户的密码或 NTLM\AES 哈希。GSS-API 为应用程序使用 Kerberos 安全提供程序提供了一种标准化方法。攻击者可以使用带有 ISC_REQ_DELEGATE 标志的 AcquireCredentialsHandle 和 InitializeSecurityContext 函数调用来强制域控制器在 GSS-API 输出中提供（应用程序请求）AP-REQ，其中包含身份验证器校验和中的KRB_CRED。

As stated in the Golden Ticket section, the KDC uses the password hash of the KRBTGT account to sign and encrypt legitimate TGTs. This same password hash can be used to decrypt the legitimate TGTs provided by the domain controller. Upon successful decryption, adversaries can then modify the legitimate TGT and re-encrypt the ticket. The specific portion of the legitimate TGT that is modified is the Kerberos (Privilege Attribute Certificate) PAC. Within the PAC there are various attributes stored like user identification, group memberships, and specific privileges or permissions granted to the user. Adversaries that modify the PAC with the desired elevated permissions and re-encrypt the TGT can then carry out domain persistence without snaring their activity by golden ticket detections (TGS-REQs that have no corresponding AS-REQ).
如黄金票部分所述，KDC 使用 KRBTGT 帐户的密码哈希来签署和加密合法的 TGT。此相同的密码哈希可用于解密域控制器提供的合法 TGT。成功解密后，攻击者可以修改合法的 TGT 并重新加密票证。修改的合法 TGT 的特定部分是 Kerberos（特权属性证书）PAC。在 PAC 中存储了各种属性，例如用户标识、组成员身份以及授予用户的特定特权或权限。然后，使用所需的提升权限修改 PAC 并重新加密 TGT 的攻击者可以执行域持久性，而不会通过黄金票证检测（没有相应 AS-REQ 的 TGS-REQ）捕获其活动。

Execution 执行

To modify a legitimate TGT, adversaries can obtain a usable TGT via the GSS-API, decrypt the TGT via the KRBTGT password hash, modify the PAC, and re-sign/re-encrypt the TGT.
要修改合法的 TGT，攻击者可以通过 GSS-API 获取可用的 TGT，通过 KRBTGT 密码哈希解密 TGT，修改 PAC 以及重新签名/重新加密 TGT。

Rubeus.exe diamond /domain:asgard.corp /user:bouj33boy /password:<PASSWORD> /dc:dc.asgard.corp /enctype:AES256 /krbkey:HASH /ticketuser:da /ticketuserid:USER_ID /groups:GROUP_IDS

Detection 检波

Similar to the Golden Ticket detection strategy, defenders should monitor KRBTGT password hash theft using strategies like lsadump, NTDS.dit theft, and DCSync. They should also watch for unexpected group membership changes, especially when low-privilege users suddenly have significant SIDs like 512 for Domain Admins without a corresponding Windows Security event ID 4627. Unlike a Golden Ticket, a Diamond Ticket triggers a 4768 event when requested. The initial Diamond Ticketing phase produces a Windows Security event ID: 4648, as the ticket’s PAC must be modified. Additionally, network based detections may be able to track and identify anomalies within the AS-REQs where the PA-PAC-REQUEST is set to false and the service has its NA bit set to false.
与黄金票证检测策略类似，防御者应使用 lsadump、NTDS.dit 盗窃和 DCSync 等策略监控 KRBTGT 密码哈希盗窃。他们还应该注意意外的组成员身份更改，尤其是当低特权用户突然拥有重要的 SID 时，例如域管理员的 512，而没有相应的 Windows 安全事件 ID 4627。与黄金票不同，钻石票在请求时会触发 4768 事件。初始钻石票证阶段生成 Windows 安全事件 ID：4648，因为必须修改票证的 PAC。此外，基于网络的检测可能能够跟踪和识别 AS-REQ 中的异常，其中 PA-PAC-REQUEST 设置为 false，服务将其 NA 位设置为 false。

Given that these methodologies might not capture all pertinent events of interest, it remains advisable to employ additional validation techniques for suspicious ticket operations, particularly for specific users. This can be achieved using tools such as klist or ACE: Get-KerberosTicketCache. Although the scalability of tools like klist for enterprise-wide threat hunting remains limited, they prove invaluable for targeted remediation efforts within the infrastructure.
鉴于这些方法可能无法捕获所有相关感兴趣的事件，因此仍然建议对可疑票证操作采用其他验证技术，特别是针对特定用户。这可以使用klist或ACE等工具实现：Get-KerberosTicketCache。尽管像 klist 这样用于企业范围威胁搜寻的工具的可扩展性仍然有限，但它们对于基础架构内有针对性的补救工作证明是无可估量的。

Active Directory Certificate Services
活动目录证书服务

Overview 概述

Adversaries can extract (Certificate Authority) CA private keys and create forged certificates signed by the stolen key. The Microsoft (Active Directory Certificate Services) AD CS server role allows administrators to produce digital certificates for authentication and encryption. The root CA, at the top of the (Public Key Infrastructure) PKI hierarchy is trusted by all intermediate CAs. Its certificate identifies the root CA and the public key that verifies signatures of all other certificates in the PKI.
攻击者可以提取（证书颁发机构）CA 私钥并创建由被盗密钥签名的伪造证书。Microsoft（活动目录证书服务）AD CS 服务器角色允许管理员生成用于身份验证和加密的数字证书。位于（公钥基础结构）PKI 层次结构顶部的根 CA 受所有中间 CA 的信任。其证书标识根 CA 和公钥，用于验证 PKI 中所有其他证书的签名。

CAs, often underestimated in importance, can be remotely managed by lower-level privileged roles such as the server operators group. If adversaries compromise these roles or gain local administrative access to the CA server, they can export the CA private key to create forged certificates. Many organizations set long validity periods for these keys, allowing adversaries to misuse them for extended periods.
CA 的重要性通常被低估，可以通过较低级别的特权角色（如服务器操作员组）进行远程管理。如果攻击者破坏这些角色或获得对 CA 服务器的本地管理访问权限，他们可以导出 CA 私钥以创建伪造证书。许多组织为这些密钥设置了较长的有效期，允许攻击者长时间滥用它们。

Windows stores certificate private keys via the (Data Protection Application Programming Interface) DPAPI. A plaintext DPAPI masterkey is needed to decrypt and successfully exfiltrate the private key. Adversaries can retrieve the plaintext DPAPI masterkey by obtaining the domain’s DPAPI backup which can be used to decrypt any domain user’s master key file.
Windows 通过（数据保护应用程序编程接口）DPAPI 存储证书私钥。需要明文 DPAPI 主密钥才能解密并成功泄露私钥。攻击者可以通过获取域的 DPAPI 备份来检索纯文本 DPAPI 主密钥，该备份可用于解密任何域用户的主密钥文件。

Execution 执行

To obtain a CA’s private key, adversaries can use a decrypted DPAPI masterkey to decrypt the private key and associated certificates.
若要获取 CA 的私钥，攻击者可以使用解密的 DPAPI 主密钥解密私钥和关联的证书。

SharpDPAPI.exe certificates /machine

Detection 检波

Will Schroder and Lee Christensen provide a couple different detection methods within their AD CS focused white-paper, Certified-Preowned. This white paper details cryptographic event IDs, including Windows Security event ID 5058 for operations on files with a Microsoft Software Key Storage Provider (KSP). It also mentions Windows Security event ID 5061 for open key or key creation operations against KSP files. The export of cryptographic keys is detected through Windows Security event ID 5059, while backup operations for these keys are tracked with Windows Security event IDs 4876 and 4877, indicating backup start and completion.
Will Schroder和Lee Christensen在他们的AD CS白皮书《认证-二手》中提供了几种不同的检测方法。本白皮书详细介绍了加密事件 ID，包括 Windows 安全事件 ID 5058，用于对具有Microsoft软件密钥存储提供程序 （KSP） 的文件进行操作。它还提到了针对 KSP 文件的开放密钥或密钥创建操作的 Windows 安全事件 ID 5061。加密密钥的导出通过 Windows 安全中心事件 ID 5059 进行检测，而这些密钥的备份操作使用 Windows 安全中心事件 ID 4876 和 4877 进行跟踪，指示备份开始和完成。

To monitor the access of the DPAPI-encrypted private keys, we can set a (System Access Control List) SACL on the private keys that normally only NT AUTHORITY\SYSTEM accesses. Access to these private keys once the SACL is set will generate Windows Security event ID 4663 (Figures 10, 11).
为了监控DPAPI加密私钥的访问，我们可以在通常只有NT机构\系统访问的私钥上设置（系统访问控制列表）SACL。设置 SACL 后，访问这些私钥将生成 Windows 安全事件 ID 4663（图 10、11）。

There are some blind spots to this detection method, as stated by Will Schroder and Lee Christensen, such as the Mimikatz (CryptoAPI) CAPI/(Cryptography Next Generation) CNG patching methods of reading files.
正如Will Schroder和Lee Christensen所说，这种检测方法存在一些盲点，例如Mimikatz（CryptoAPI）CAPI/（Cryptography Next Generation）CNG读取文件的修补方法。

Reclaiming the Iron Throne
夺回铁王座

If the alert team identifies the mentioned techniques in use, the next logical step is to look for signs of data exfiltration. However, both incident responders should operate under the assumption that domain credential material is already compromised regardless of detected exfiltration. This stance is rooted in the principle of “unknown unknowns,” which means defenders are unaware of what they might be missing. If the adversary triggers the organization’s alerts for the aforementioned techniques, it indicates their ability to achieve total domain control. Defenders can’t predict all adversary exfiltration methods. Adversaries often send fragmented, encrypted data in small segments, making detection difficult as it blends with regular traffic.
如果警报团队确定正在使用的上述技术，则下一个逻辑步骤是查找数据外泄的迹象。但是，两个事件响应程序都应假设域凭据材料已泄露，无论检测到的外泄情况如何。这种立场植根于“未知未知”的原则，这意味着捍卫者不知道他们可能错过了什么。如果攻击者触发组织针对上述技术的警报，则表明他们有能力实现完全的域控制。防御者无法预测所有对手的渗透方法。攻击者通常以小段形式发送碎片化的加密数据，这使得检测变得困难，因为它与常规流量混合在一起。

Post-incident activity requires efficient recovery operations to reduce adversary dwell time after detecting a compromise. Once the incident’s scope is determined, hosts are isolated, reprovisioned, user accounts rotated, and system owners are alerted to close attack paths. If any of the mentioned techniques are identified, full domain recovery is essential. Incident responders should prioritize systems that elevated users could access. Ideally, organizations should rebuild each domain controller related to the adversary’s access. Additionally, if the adversary had domain administrative access and the domain is within a forest where parent/child or tree/root trust relationships are established, defenders must determine the trust type direction and consider these additional domains within the scope of recovery. If telemetry does not indicate forest trust lateral movement, organizations can choose to accept the risk that the adversary may have had access but did not attempt to use it. However, if telemetry is not available (and in many cases, it is not), the additional domains should stay in the scope of recovery as a precaution.
事件后活动需要高效的恢复操作，以减少检测到入侵后的对手停留时间。确定事件范围后，将隔离主机、重新配置主机、轮换用户帐户，并提醒系统所有者关闭攻击路径。如果确定了上述任何一种技术，则全域恢复至关重要。事件响应者应优先考虑提升的用户可以访问的系统。理想情况下，组织应重新生成与对手访问相关的每个域控制器。此外，如果攻击者具有域管理访问权限，并且域位于建立父/子或树/根信任关系的林中，则防御者必须确定信任类型方向，并在恢复范围内考虑这些其他域。如果遥测未指示林信任横向移动，则组织可以选择接受攻击者可能已访问但未尝试使用它的风险。但是，如果遥测不可用（在许多情况下，它不可用），则作为预防措施，其他域应保留在恢复范围内。

At this point, some heavy critical-decision making must occur at the organizational level to recover these potentially compromised domains or modify the scope and accept some level of risk.
此时，必须在组织级别进行一些繁重的关键决策，以恢复这些可能受到损害的域或修改范围并接受一定程度的风险。

Assuming the adversary has been contained and access has been remediated, the organization would begin the recovery operation. The below sections discuss high-level recommendations that an organization can take to recover from an incident at this level of compromise. Keep in mind there are nuanced caveats to any recovery plan that requires the unique perspective of the organization implementing the recovery.
假设已包含对手并修正访问权限，则组织将开始恢复操作。以下各节讨论组织可以采取的高级建议，以从此泄露级别的事件中恢复。请记住，任何需要实施恢复的组织的独特视角的恢复计划都有细微的警告。

Rising Anew from the Ashes
从灰烬中重生

In this section, this post will explore two options available to organizations that are ready to begin recovery operations. The first of these options is to utilize the domain controllers within the scope of the compromised environment and replace them with completely new domain controllers. The reason for replacing domain controllers completely stems from the inherent risk of an adversary having stolen the domain DPAPI backup key. The domain DPAPI backup key is found within the NTDS.dit database file and contains the master key to decrypt the private/public keypair associated with DPAPI. Domain controllers have a domain-wide public/private keypair and clients request the public key when joined to a domain as a member. This DPAPI public key is transmitted via authenticated and private RPC call to the client. This domain-wide backup key cannot be rotated as per Microsoft documentation (Figure 12).
在本节中，本文将探讨准备开始恢复操作的组织可用的两个选项。这些选项中的第一个是在受感染的环境中利用域控制器，并将其替换为全新的域控制器。更换域控制器的原因完全源于攻击者窃取域 DPAPI 备份密钥的固有风险。域 DPAPI 备份密钥位于 NTDS.dit 数据库文件中找到，其中包含用于解密与 DPAPI 关联的私钥/公钥对的主密钥。域控制器具有域范围的公钥/私钥对，客户端在作为成员加入域时请求公钥。此 DPAPI 公钥通过经过身份验证的私有 RPC 调用传输到客户端。此域范围的备份密钥无法按照Microsoft文档进行轮换（图 12）。

The obvious recommendation is to go beyond simply accepting the risk and rotating everything except the domain-wide DPAPI backup key. Instead, organizations should identify the domain controllers where the credential dumping occurred with privilege login and destroy them in order to rebuild these domain controllers from scratch. Rebuilding can occur by re-installing a new Windows Server and promoting the server to domain controller via Windows Server Manager or by promoting the disk of another unaffected Windows Server to the domain controller role (Figure 13).
显而易见的建议是，不仅仅是简单地接受风险和轮换除域范围的 DPAPI 备份密钥之外的所有内容。相反，组织应使用特权登录标识发生凭据转储的域控制器，并销毁它们，以便从头开始重建这些域控制器。通过重新安装新的 Windows Server 并通过 Windows Server Manager 将服务器提升为域控制器，或者将另一个不受影响的 Windows Server 的磁盘提升为域控制器角色，可以进行重建（图 13）。

Conclusion 结论

Domain persistence techniques often focus on abusing default authentication protocols and their specific components within the Active Directory domain. These techniques (and future gemstone-named variations) will continue to evolve in approach and strategy. Defenders need to keep an eye on both emerging trends on the offensive side and on new tools and techniques that help find evidence of adversary behavior within their domain.
域持久性技术通常侧重于滥用默认身份验证协议及其在 Active Directory 域中的特定组件。这些技术（以及未来的宝石命名变体）将继续在方法和策略上发展。防御者需要密切关注进攻方面的新兴趋势，以及有助于在其领域内找到对手行为证据的新工具和技术。

We’ve also walked you through some of the most popular domain persistence techniques and potential detection strategies that defenders can implement in their environments.
我们还向您介绍了防御者可以在其环境中实施的一些最流行的域持久性技术和潜在检测策略。

‘But what happens if we find evidence of adversarial behavior?’, you say. Good question, hypothetical reader. Unlike waiting for the works of a certain popular author, you won’t have to sit for a few decades to see how the story ends. We are going to continue to provide remediation recommendations in the upcoming second half of this blog: Domain of Thrones Part II.
“但是，如果我们找到对抗行为的证据会发生什么？”你说。好问题，假设的读者。与等待某个流行作家的作品不同，您不必坐几十年就能看到故事的结局。我们将在本博客的下半部分继续提供补救建议：权力之域第二部分。

References 引用

• https://www.jpcert.or.jp/english/pub/sr/20170612ac-ir_research_en.pdf
• https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
• https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
• https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/how-to-manage-groups
• https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
• https://learn.microsoft.com/en-us/azure/active-directory-domain-services/concepts-forest-trust
• https://learn.microsoft.com/en-us/windows/win32/seccng/cng-dpapi-backup-keys-on-ad-domain-controllers
• https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age
• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://atomicredteam.io/
• https://media.defense.gov/2023/May/24/2003229517/-1/-1/0/CSA_Living_off_the_Land.PDF

原文始发于Nico Shyne：Domain of Thrones: Part I