In the first installment of “Domain of Thrones,” we meticulously explored an array of six distinctive domain persistence techniques:
在《权力领域》的第一部分中，我们仔细探索了六种独特的领域持久化技术：

• Credential Theft on the Domain Controller (DC)
  域控制器 （DC） 上的凭据盗窃
• NTDS Access NTDS 访问
• DCSync DCSync的
• Golden Ticket 黄金门票
• Diamond Ticket 钻石票
• Active Directory Certificate Services (AD CS)
  Active Directory 证书服务 （AD CS）

These adversarial methods facilitate an elevated level of access to the targeted domains, thereby challenging the defenders with a considerably strenuous eviction and remediation process.
这些对抗性方法有助于提高对目标域的访问水平，从而通过相当艰苦的驱逐和补救过程对防御者提出挑战。

Our initial post ended by offering high-level recommendations on determining the scope of a compromise when evidence confirms the establishment of domain persistence. Additionally, we covered initial recommendations for promoting Windows servers to domain controllers to replace the compromised domain controllers.
我们最初的帖子最后提供了关于在证据证实域持久性建立时确定妥协范围的高级建议。此外，我们还介绍了将 Windows 服务器提升为域控制器以替换受损域控制器的初步建议。

Looking ahead to “Domain of Thrones: Part II,” we will provide post-compromise guidance for the rotation of domain secrets. This sequel will also dive into Windows Security event auditing that provides detection capabilities surrounding domain persistence behavior. Such auditing is crucial to reduce adversaries’ time in the domain and strengthen defenses against further compromising activities.
展望“权力之域：第二部分”，我们将为域名机密的轮换提供妥协后的指导。此续集还将深入探讨 Windows 安全中心事件审核，该审核提供有关域持久性行为的检测功能。此类审计对于减少对手在域中的时间并加强对进一步入侵活动的防御至关重要。

Changing the Guard Post-Siege
围攻后换岗

Following the reconstruction strategies delineated in “Domain of Thrones: Part I” for compromised domain controllers, defenders must also focus on the rotating of the domain’s secret material. Defenders must rotate the secrets of any domain controller identified within the scope of the compromise. Additionally, consider children-domain controllers within scope if the in-scope domain controller is a forest root, and one or more child domains exist.
按照《权力之域：第一部分》中针对受损域控制器描述的重建策略，防御者还必须专注于域秘密材料的轮换。防御者必须轮换在入侵范围内标识的任何域控制器的机密。此外，如果作用域内的域控制器是林根，并且存在一个或多个子域，请考虑作用域内的子域控制器。

As per Microsoft’s remediation guidance, ensure the below steps are performed from a “trusted device, built from a clean source.” Microsoft emphasizes the first step to avoid accidentally providing an embedded adversary with a privileged workstation and account during the remediation efforts. Additionally, defenders should create and utilize brand-new dedicated accounts for remediation activity.
根据 Microsoft 的修正指南，请确保从“从干净源构建的受信任设备”执行以下步骤。Microsoft 强调第一步是避免在修复工作期间意外向嵌入式对手提供特权工作站和帐户。此外，防御者应创建和利用全新的专用帐户进行补救活动。

Defenders can use the Active Directory PowerShell module to identify accounts modified (whenChanged property)before the last date of malicious activity. For instance, if an incident report shows the latest activity date, accounts modified before this date should have their credentials rotated. This broad rotation ensures that all accounts linked to domain persistence are updated, even without direct evidence of compromise by adversaries. The actual credential rotation method depends on the organization’s identity manager. However, for those using on-prem Active Directory or Azure Hybrid, specific commands can help identify accounts requiring rotation (Figure 1).
防御者可以使用 Active Directory PowerShell 模块来识别在恶意活动的最后日期之前修改的帐户 （whenChanged 属性） 。例如，如果事件报告显示最新的活动日期，则在此日期之前修改的帐户应轮换其凭据。这种广泛的轮换可确保更新与域持久性相关的所有帐户，即使没有攻击者入侵的直接证据。实际的凭据轮换方法取决于组织的身份管理器。但是，对于使用本地 Active Directory 或 Azure 混合的用户，特定命令可以帮助识别需要轮换的帐户（图 1）。

$date = "09/18/2023"
$users_to_be_rotated = Get-ADObject | Where-Object {$_.ObjectClass -eq 'user' -and $_.whenchanged -lt $date}

The accounts and objects that will need rotation are to include the following:
需要轮换的帐户和对象应包括以下内容：

• Machine accounts 计算机帐户
• User accounts 用户帐户
• Service accounts 服务帐户
  – Per domain KRBTGT account (the authors will discuss specific rotation steps in more detail below)
  – 每个域 KRBTGT 帐户（作者将在下面更详细地讨论具体的轮换步骤）
• Trust keys and objects related to trust of all other domains
  信任密钥和与所有其他域的信任相关的对象
• Group-managed service accounts
  组托管服务帐户
• Key distribution service root keys
  密钥分发服务根密钥

Rotating Machine Accounts
旋转机器帐户

WARNING: Resetting the client’s machine account password locally will disconnect the client from the domain until the domain trust is re-established.
警告：在本地重置客户端的计算机帐户密码将断开客户端与域的连接，直到重新建立域信任。

By default, machine account passwords do not expire in Active Directory, and they are typically exempt from the active domain password policy. We recommend setting the maximum machine account password age to 30 days, with the client initiating the password change. The client’s netlogon service handles machine password updates via the Workstation Scavenger Thread. Create a script to rotate the machine account passwords and execute it remotely on each client identified within the scope of the compromise, using the Reset-ComputerMachinePassword cmdlet to reset the client machine account password. Then, rejoin the client to the domain, where the client provides the new password to Active Directory. The example script below can remotely reset the machine account password and re-establish trust with Active Directory (see Figure 2).
默认情况下，计算机帐户密码在 Active Directory 中不会过期，并且通常不受活动域密码策略的约束。建议将计算机帐户密码的最长期限设置为 30 天，由客户端启动密码更改。客户端的 netlogon 服务通过 Workstation Scavenger 线程处理计算机密码更新。创建一个脚本来轮换计算机帐户密码，并使用 Reset-ComputerMachinePassword cmdlet 重置客户端计算机帐户密码，并在入侵范围内标识的每个客户端上远程执行该脚本。然后，将客户端重新加入域，客户端在其中向 Active Directory 提供新密码。下面的示例脚本可以远程重置计算机帐户密码，并与 Active Directory 重新建立信任关系（请参阅图 2）。

# ResetAndTestComputer.ps1 
#PowerShell Script to Reset Computer Machine Password and Test Computer Secure Channel
# Parameters
param(
    [string]$DCname,
    [string]$DomainUser
)
# Function to reset computer machine password
function Reset-ComputerPassword {
    param(
        [string]$server,
        [string]$credential
    )
    # Reset the computer machine password
    Reset-ComputerMachinePassword -Server $server -Credential $credential
}
# Function to test and repair computer secure channel
function Test-RepairComputerSecureChannel {
    param(
        [string]$credential
    )   
    # Test and repair the computer's secure channel
    Test-ComputerSecureChannel -Repair -Credential $credential
}
# Execute the functions with provided parameters
Reset-ComputerPassword -server $DCname -credential $DomainUser
Test-RepairComputerSecureChannel -credential $DomainUser
Write-Output "Operations completed successfully!"

The below command can execute the above example script on clients with PSRemoting enabled.
以下命令可以在启用了 PSRemoting 的客户端上执行上述示例脚本。

Invoke-Command -ComputerName RemoteComputerName 
-FilePath C:\Path\To\ResetAndTestComputer.ps1 
-ArgumentList "DCname", "DOMAIN\User" -Credential DOMAIN\User

Rotating User Accounts 轮换用户帐户

Adversaries can establish domain persistence through malicious code execution and privileged account compromise. In recent intrusions, adversaries have used the administrative permissions of compromised user accounts to establish persistent access to on-premises and cloud environments.
攻击者可以通过恶意代码执行和特权帐户泄露来建立域持久性。在最近的入侵中，攻击者使用被入侵用户帐户的管理权限来建立对本地和云环境的持久访问。

You can complete user account rotation using the Active Directory PowerShell module and the Set-ADUser cmdlet. Defenders must identify all account types that allow interactive logon and set the “User must change password at next login” flag by adding the ChangePasswordAtLogon $true argument for each user. Defenders should notify the organization stating that a password change is required. After several days, defenders must lock the accounts that have not had passwords rotated.
可以使用 Active Directory PowerShell 模块和 Set-ADUser cmdlet 完成用户帐户轮换。防御者必须标识允许交互式登录的所有帐户类型，并通过为每个用户添加 ChangePasswordAtLogon $true参数来设置“用户下次登录时必须更改密码”标志。防御者应通知组织，说明需要更改密码。几天后，防御者必须锁定未轮换密码的帐户。

Some accounts will likely have the passwordNeverExpires or cannotChangePassword property set to true, in which case, the Set-ADUser cmdlet for setting changePasswordAtLogon will not work, and their passwords will need to be reset manually via Active Directory Users and Computers or by setting passwordNeverExpires or cannotChangePassword to false.
某些帐户可能会将 passwordNeverExpires 或 cannotChangePassword 属性设置为 true，在这种情况下，用于设置 changePasswordAtLogon 的 Set-ADUser cmdlet 将不起作用，并且需要通过 Active Directory 用户和计算机手动重置其密码，或者通过将 passwordNeverExpires 或 cannotChangePassword 设置为 false。

Microsoft provides additional user rotation guidance focused on MFA-enabled user accounts for Azure hybrid environments. After the user accounts have been rotated, the Revoke-AzureADUserAllRefreshToken AzureAD PowerShell cmdlet should be executed to revoke the refresh tokens of potentially compromised user accounts. This additional measure revokes all access for user accounts, including the compromised user accounts, to Azure Active Directory resources.
Microsoft 提供了其他用户轮换指南，重点介绍 Azure 混合环境的启用 MFA 的用户帐户。轮换用户帐户后，应执行 Revoke-AzureADUserAllRefreshToken AzureAD PowerShell cmdlet 来吊销可能遭到入侵的用户帐户的刷新令牌。此附加措施撤消用户帐户（包括已泄露的用户帐户）对 Azure Active Directory 资源的所有访问权限。

Rotating Service Accounts
轮换服务帐户

Rotating the passwords of service accounts can pose a significant challenge, especially for organizations heavily reliant on legacy applications. In large organizations, legacy services often operate under the expectation of static service account passwords, creating a persistent vulnerability that is challenging to mitigate.
轮换服务帐户的密码可能会带来重大挑战，尤其是对于严重依赖旧应用程序的组织而言。在大型组织中，旧服务通常在静态服务帐户密码的预期下运行，从而产生难以缓解的持续性漏洞。

Defenders (or internal offensive operators) can proactively identify vulnerable service accounts susceptible to cracking by using open-source tools to retrieve the NTLM hash of service accounts with an associated Service Principal Name (SPN). Defenders can then attempt to crack the service account NTLM passwords with hashcat. When defenders know the crackable accounts, they can set additional auditing on these vulnerable accounts. Defenders can promptly identify and respond to malicious activities by closely monitoring ticket requests and activities associated with these service accounts.
防御者 （或内部攻击性操作员） 可以通过使用开源工具检索具有关联服务主体名称 （SPN） 的服务帐户的 NTLM 哈希，主动识别易受破解的服务帐户。然后，防御者可以尝试使用 hashcat 破解服务帐户 NTLM 密码。当防御者知道可破解的帐户时，他们可以对这些易受攻击的帐户设置额外的审计。防御者可以通过密切监视与这些服务帐户相关的工单请求和活动来及时识别和响应恶意活动。

Adopt a strategic approach for services that would allow for the rotation of the service account password. During incident response, separate the service accounts suspected of being compromised based on telemetry data. Involving security engineers and system administrators in the review process is essential. Their combined expertise will help make informed decisions about which compromised service accounts can be immediately rotated and which ones need further testing. Security engineers should also ensure that service account passwords meet robust security standards, recommending a minimum length of 30 characters to enhance security resilience.
对服务采用允许轮换服务帐户密码的战略方法。在事件响应期间，根据遥测数据分离怀疑遭到入侵的服务帐户。让安全工程师和系统管理员参与审查过程至关重要。他们的综合专业知识将有助于做出明智的决定，确定哪些受损的服务帐户可以立即轮换，哪些需要进一步测试。安全工程师还应确保服务帐户密码符合可靠的安全标准，建议最小长度为 30 个字符，以增强安全弹性。

Rotating the KRBTGT Account
轮换KRBTGT账户

The domain Kerberos service account, KRBTGT, is part of the domain’s Kerberos distribution center, which handles all Kerberos ticket requests. As mentioned above, adversaries who have compromised the KRBTGT service account can generate Golden Tickets, which enables an adversary to generate their own TGT using the KRBTGT account password hash. This generated TGT can be modified to have an extremely long lifetime of up to 10 years. Due to the trust that each client has in the KRBTGT password hash, preventing the abuse of a Golden Ticket is extremely difficult. Rotating this particular service account is critical to remediation and recovery operations. The recommendations for rotation will often state to rotate the password of this account twice. However, the complexity of rotating the KRBTGT account password is more nuanced than simply doing it twice (Figure 3).
域 Kerberos 服务帐户 KRBTGT 是域的 Kerberos 分发中心的一部分，该中心处理所有 Kerberos 票证请求。如上所述，入侵 KRBTGT 服务帐户的攻击者可以生成 Golden Tickets，这使攻击者能够使用 KRBTGT 帐户密码哈希生成自己的 TGT。这种生成的TGT可以被修改为具有长达10年的极长寿命。由于每个客户端对 KRBTGT 密码哈希的信任，防止滥用 Golden Ticket 是极其困难的。轮换此特定服务帐户对于修正和恢复操作至关重要。轮换建议通常会声明将此帐户的密码轮换两次。但是，轮换 KRBTGT 帐户密码的复杂性比简单地执行两次更微妙（图 3）。

Many recommendations suggest changing the KRBTGT account password twice to address password history concerns. An account’s password history stores both the current password and the last one (n-1). When rotating the KRBTGT account password, the first password change must be replicated to all secondary domain controllers. To validate that the replication has been completed, security engineers can run the replication admin “show replication” command from a Windows terminal:
许多建议建议将 KRBTGT 帐户密码更改两次，以解决密码历史记录问题。帐户的密码历史记录同时存储当前密码和最后一个密码 （n-1）。轮换 KRBTGT 帐户密码时，必须将第一个密码更改复制到所有辅助域控制器。要验证复制是否已完成，安全工程师可以从 Windows 终端运行 replication admin “show replication” 命令：
repadmin.exe /showrepl dc2 (Figure 4).
repadmin.exe /showrepl dc2（图 4）。

Once replication is complete, the second password rotation can occur to ensure that the previously compromised KRBTGT account password hash is no longer lingering in the environment as a potential attack vector. Additionally, this process will need to be conducted on every domain within the scope of the compromise. Microsoft provides a script, New-KrbtgtKeys.ps1, that will both change the KRBTGT account password and validate that replication was successful before the second change with repadmin.exe.
复制完成后，可能会进行第二次密码轮换，以确保以前泄露的 KRBTGT 帐户密码哈希不再作为潜在的攻击媒介在环境中徘徊。此外，此过程需要在妥协范围内的每个域上进行。Microsoft 提供了一个脚本 New-KrbtgtKeys.ps1，该脚本将更改 KRBTGT 帐户密码，并在使用 repadmin.exe 进行第二次更改之前验证复制是否成功。

Rotating Trust Realm Objects
轮换信任域对象

In a forest with multiple Active Directory domains connected by trust relationships, compromising a Tier 0 account, like a domain admin or the KRBTGT service account, affects all domain controllers within the domain due to their trust relationship with the compromised Tier 0 principal. However, the adversary will not be able to request resources within another domain within the same forest because creating service tickets requires the target service’s password data, and the compromised domain only has the credential information for its own principals. This logical separation is called a Kerberos Realm. To provide a method by which users within a child domain can request resources in the ROOT domain, Microsoft designed a secure password to be shared between the multiple domains in the same forest. This trust password is then converted into a cryptographic key called the Inter-Realm Trust Key. This collection of Kerberos trust between multiple domains is called a Kerberos Trust Realm. When a user requests a resource in another domain, the remote domain’s Key Distribution Center (KDC) returns a signed TGT. However, unlike a typical TGT signed by the KRBTGT account of the domain, the Trust Realm TGT is signed by the inter-realm key.
在具有多个通过信任关系连接的 Active Directory 域的林中，泄露第 0 层帐户（如域管理员或 KRBTGT 服务帐户）会影响域中的所有域控制器，因为它们与遭到入侵的第 0 层主体建立了信任关系。但是，攻击者将无法请求同一林中另一个域中的资源，因为创建服务票证需要目标服务的密码数据，而被入侵的域仅具有其自身主体的凭据信息。这种逻辑分离称为 Kerberos 领域。为了提供子域中的用户可以请求 ROOT 域中的资源的方法，Microsoft 设计了一个安全密码，以便在同一林中的多个域之间共享。然后，此信任密码将转换为称为域间信任密钥的加密密钥。多个域之间的 Kerberos 信任集合称为 Kerberos 信任领域。当用户请求另一个域中的资源时，远程域的密钥分发中心 （KDC） 将返回已签名的 TGT。但是，与由域的 KRBTGT 帐户签名的典型 TGT 不同，信任域 TGT 由域间密钥签名。

Adversaries can abuse Kerberos Trust Realms to regain privileged access in an environment that has begun the eviction process and rotated the KRBTGT account. Once the KRBTGT account is rotated, the adversary can no longer generate Golden Tickets because the password hash has changed. However, if the adversary retrieves credentials from the domain controller, the adversary can generate forged inter-realm trust keys, enabling the adversary to regain access utilizing enterprise admin accounts. Due to the inherent trust between domains in the forest and the trust password, an enterprise admin in one domain is part of the Administrators group in every other domain in the forest.
攻击者可以滥用 Kerberos 信任领域，在已开始逐出过程并轮换 KRBTGT 帐户的环境中重新获得特权访问权限。一旦KRBTGT帐户轮换，对手就无法再生成Golden Tickets，因为密码哈希已更改。但是，如果攻击者从域控制器检索凭据，则攻击者可以生成伪造的领域间信任密钥，从而使攻击者能够利用企业管理员帐户重新获得访问权限。由于林中的域和信任密码之间存在固有的信任关系，因此一个域中的企业管理员是林中所有其他域中管理员组的一部分。

From a remediation perspective, the inter-realm trust password automatically changes every 30 days, according to section 6.1.6.9.6.1 of the Active Directory Technical Specification. Still, the last trust password will be retained in the SAM database until the following change. Defenders must manually initiate the trust password update and wait for it to replicate to all domains before rotating it a second time. Microsoft provides guidance on rotating trust keys with netdom.exe. Incident responders must ensure they rotate the password on the incoming trust side and use the same password on the outgoing trust side. This procedure ensures that the domain controllers do not replicate the compromised domain controller’s password, which may be compromised.
从补救的角度来看，根据 Active Directory 技术规范的第 6.1.6.9.6.1 节，域间信任密码每 30 天自动更改一次。不过，最后一个信任密码将保留在 SAM 数据库中，直到进行以下更改。防御者必须手动启动信任密码更新，并等待其复制到所有域，然后再进行第二次轮换。Microsoft 提供有关使用 netdom.exe 轮换信任密钥的指导。事件响应者必须确保在传入信任端轮换密码，并在传出信任端使用相同的密码。此过程可确保域控制器不会复制已泄露的域控制器的密码，该密码可能会泄露。

Defenders should rotate the inter-realm trust password on the recovered domain controller from the compromise first. The command using netdom.exe will differ slightly depending on whether the affected domain was the parent or child domain in the trust realm. Netdom trust /resetOneSide will write a new trust password on the targeted domain (child or parent) that the command was executed on. The /PasswordO:* command will prompt the CLI to have the administrator input the password. The /PasswordT command should use the same password on either side of the trust relationship.
防御者应首先轮换已恢复域控制器上的域间信任密码。使用 netdom.exe 的命令将略有不同，具体取决于受影响的域是信任域中的父域还是子域。Netdom trust /resetOneSide 将在执行命令的目标域（子域或父域）上写入新的信任密码。/PasswordO：* 命令将提示 CLI 让管理员输入密码。/PasswordT 命令应在信任关系的任一端使用相同的密码。

In the below screenshots, eagle.banking will represent the parent domain and island.banking will mean the child domain.
在下面的屏幕截图中，eagle.banking 表示父域，island.banking 表示子域。

To reset the inter-realm trust password with netdom.exe on a parent domain (Figure 5), defenders can execute the following syntax:
要在父域上使用 netdom.exe 重置域间信任密码（图 5），防御者可以执行以下语法：

netdom trust <PARENT_DOMAIN_NAME> /domain:<CHILD_DOMAIN_NAME> 
/resetOneSide /passwordT:<PASSWORD> /userO:<ADMINISTRATOR_ACCOUNT> 
/passwordO:*

To reset the inter-realm trust password with netdom.exe on a child domain (Figure 6), defenders can execute the following syntax:
要在子域上使用 netdom.exe 重置领域间信任密码（图 6），防御者可以执行以下语法：

netdom trust <CHILD_DOMAIN_NAME> /domain:<PARENT_DOMAIN_NAME> 
/resetOneSide /passwordT:<PASSWORD> /userO:<ADMINISTRATOR_ACCOUNT> 
/passwordO:*

The above commands must only be executed once per domain because netdom.exe will automatically reset the password twice.
上述命令只能对每个域执行一次，因为 netdom.exe 会自动重置密码两次。

Rotating Group Managed Service Accounts
轮换组托管服务帐户

The Microsoft Key Distribution Service (KDS) root key on the domain controller is used to generate group-managed service account (gMSA) passwords. Domain controllers require the root key to create these gMSA passwords. For gMSA specifically, defenders can conduct the following steps to rotate the gMSA passwords:
域控制器上的 Microsoft 密钥分发服务 （KDS） 根密钥用于生成组托管服务帐户 （gMSA） 密码。域控制器需要根密钥才能创建这些 gMSA 密码。特别是对于 gMSA，防御者可以执行以下步骤来轮换 gMSA 密码：

1. Delete the old root key
   删除旧的根密钥
2. Create a new root key
   创建新的根密钥
3. Restart the KDS on all domain controllers once the key is recreated.
   重新创建密钥后，重新启动所有域控制器上的 KDS。
   – The restart will ensure the previous key is not used after deletion due to caching of the key.
   – 重新启动将确保由于密钥缓存而删除后不会使用以前的密钥。

Microsoft introduced Managed Service Accounts (MSA) in Windows Server 2008, which precedes gMSAs. To rotate Standalone MSAs, a different process is required than the one used for gMSA. To rotate passwords for standalone MSAs, use the Active Directory PowerShell module and the Reset-ADServiceAccountPassword cmdlet on local computers. Execute the cmdlet on the standalone client where you have installed the MSA.
Microsoft 在 Windows Server 2008 中引入了托管服务帐户 （MSA），它早于 gMSA。若要轮换独立 MSA，需要与用于 gMSA 的过程不同的过程。若要轮换独立 MSA 的密码，请在本地计算机上使用 Active Directory PowerShell 模块和 Reset-ADServiceAccountPassword cmdlet。在安装了 MSA 的独立客户端上执行 cmdlet。

Remediation of Certificate Authorities
证书颁发机构的修正

The industry standard for Public-Key Infrastructure (PKI) implementation is to establish the first Certificate Authority (CA) as the root, accompanied by the generation of the root certificate and subsequent authorization of intermediate CAs. This practice allows organizations to efficiently distribute and revoke certificates without the direct involvement of the root CA. Industry best practices recommend keeping the root CA secured and offline to mitigate potential attack vectors. This strategic isolation acts as a safeguard, eliminating avenues of compromise.
公钥基础设施 （PKI） 实施的行业标准是建立第一个证书颁发机构 （CA） 作为根，同时生成根证书并随后对中间 CA 进行授权。这种做法允许组织有效地分发和吊销证书，而无需根 CA 的直接参与。 行业最佳实践建议保持根 CA 安全并脱机，以缓解潜在的攻击媒介。这种战略隔离起到了保障措施的作用，消除了妥协的途径。

When the root CA is compromised, a rigorous process of revocation and reauthorization of all certificates issued by intermediate CAs becomes imperative. This revocation process starts with logging into the root CA as a Certification Authority Administrator or Certificate Manager and revoking all subordinate CA certificates. The certificates are then marked as revoked and moved to the Revoked Certificates folder. The revoked subordinate CA certificates will appear on the certificate revocation list (CRL) the next time it is published. An adversary with unidentified persistent access to the root CA could un-revoke any certificates listed as “Certificate Hold” in the revocation reason code. Defenders should execute the following certutil.exe command for the certificates that contain a revocation reason code of “Certificate Hold” to label the revoked certificate as having a new reason code of “CA Compromise.”
当根 CA 遭到入侵时，必须对中间 CA 颁发的所有证书进行严格的吊销和重新授权过程。此吊销过程首先以证书颁发机构管理员或证书管理员身份登录根 CA，并吊销所有从属 CA 证书。然后，证书被标记为已吊销，并移动到“已吊销的证书”文件夹中。吊销的从属 CA 证书将在下次发布时显示在证书吊销列表 （CRL） 上。对根 CA 具有不明持久访问权限的攻击者可以取消吊销吊销原因代码中列为“证书保留”的任何证书。防御者应对包含吊销原因代码“证书保留”的证书执行以下 certutil.exe 命令，以将吊销的证书标记为具有“CA 入侵”的新原因代码。

certutil -revokeCertificateSerialNumber2

After revoking the subordinate CA certificates, defenders should manually publish the CRL on the root CA with the certutil -crl command. This step sets the new CRL as the official list of revoked subordinate CA certificates until the instantiation of a new root CA. Additionally, clients will cache CRLs locally to speed up the certificate verification process. This means that clients will not normally download the newly published CRL until the locally cached CRL has expired. To force clients to download the newly published CRL, defenders will need to invalidate the current cache of CRL on each client. The following command will immediately invalidate all locally cached CRL entries on the client:
吊销从属 CA 证书后，防御者应使用 certutil -crl 命令在根 CA 上手动发布 CRL。此步骤将新 CRL 设置为已吊销的从属 CA 证书的正式列表，直到实例化新的根 CA。 此外，客户端将在本地缓存 CRL 以加快证书验证过程。这意味着，在本地缓存的 CRL 过期之前，客户端通常不会下载新发布的 CRL。若要强制客户端下载新发布的 CRL，防御者需要使每个客户端上的 CRL 当前缓存失效。以下命令将立即使客户端上所有本地缓存的 CRL 条目失效：

certutil -setreg chain\ChainCacheResyncFiletime @now

Once the new CRL is manually published and each client has purged its cache of previously trusted certificates, the original root CA must be decommissioned. Microsoft recommends saving any data, logs, or databases required for retention and sequentially reformatting the root CA’s hard drives. Once the root CA is retired, generate a new key pair on a newly implemented root CA and reissue subordinate CA certificates. Microsoft notes that the newly generated CA keys should use a larger key size and a currently uncompromised algorithm.
手动发布新的 CRL 并且每个客户端都清除了以前受信任证书的缓存后，必须停用原始根 CA。Microsoft 建议保存保留所需的任何数据、日志或数据库，并按顺序重新格式化根 CA 的硬盘驱动器。根 CA 停用后，在新实施的根 CA 上生成新的密钥对，并重新颁发从属 CA 证书。Microsoft 指出，新生成的 CA 密钥应使用更大的密钥大小和当前未妥协的算法。

Recovering from a compromise of the root CA is generally a meticulous and exhaustive process that significantly impedes operational workflows and production. Organizations should proactively strategize and implement measures to isolate the root CA if they haven’t already, strengthen security protocols, and reduce potential threats.
从根 CA 的入侵中恢复通常是一个细致而详尽的过程，会严重阻碍操作工作流和生产。组织应主动制定策略并实施措施来隔离根 CA（如果尚未隔离），加强安全协议并减少潜在威胁。

Recommended Logging for Domain Compromises
针对域泄露的建议日志记录

We’ve reached the end of the series. The dragons burned down the city, the invaders breached the wall, but we’ve started rebuilding. Once an organization recovers from a domain compromise, information security management often asks the question: “How can we be better prepared for a future attempt?” The answer relies upon implementing scalable auditing and reducing adversary dwell time, preventing them from reaching a level that necessitates a complete environment rotation.
我们已经到了这个系列的结尾。巨龙烧毁了这座城市，入侵者攻破了城墙，但我们已经开始重建。一旦组织从域泄露中恢复，信息安全管理通常会问一个问题：“我们如何才能为未来的尝试做好更好的准备？答案依赖于实施可扩展的审核并减少对手的停留时间，从而防止他们达到需要完整环境轮换的水平。

Microsoft Defender for Identity (MDI) provides security event IDs related to many attack techniques discussed in our previous blog, “Domain of Thrones: Part 1.” The following event IDs focus on persistence and privilege escalation related to Kerberos abuse:
Microsoft Defender for Identity （MDI） 提供与我们之前的博客“权力之域：第 1 部分”中讨论的许多攻击技术相关的安全事件 ID。以下事件 ID 侧重于与 Kerberos 滥用相关的持久性和权限提升：

• Event ID: 2009 (Encryption Downgrade)
  事件 ID： 2009 （加密降级）
  – This event filters for TGS_REQ (service requests) where the encryption type is a less secure cipher than previously requested service requests over five days.
  – 此事件会过滤加密类型在五天内比之前请求的服务请求更不安全的TGS_REQ（服务请求）。
• Event ID: 2027 (Nonexistent Account)
  事件 ID：2027 （不存在的帐户）
  – This event filters for TGTs (ticket-granting tickets) provided to resources where the account related to the TGT is nonexistent.
  – 此事件筛选提供给与 TGT 相关的帐户不存在的资源的 TGT（票证授予票证）。
• Event ID: 2032 (Ticket Anomaly)
  事件 ID：2032（票证异常）
  – This event analyzes TGTs for “unique characteristics” corresponding to forged tickets. While we don’t know precisely the characteristics of the forged tickets that cause this alert to fire, open-source research indicates that the ticket anomalies are likely related to ticket lifetimes, such as the MaxTicketAge parameter of a TGT. The expected signal to fire for MaxTicketAge representing an anomalous lifetime would be Event ID: 2022 (Ticket Time Anomaly). However, Synack’s tests prove that event ID 2032 Ticket Anomaly will fire instead. Additionally, this alert likely considers the published anomalies in TGTs that offensive tools generate when forging tickets.
  – 此活动分析了与伪造门票相对应的 TGT 的“独特特征”。虽然我们并不确切知道导致此警报触发的伪造票证的特征，但开源研究表明，票证异常可能与票证生存期有关，例如 TGT 的 MaxTicketAge 参数。表示异常生存期的 MaxTicketAge 触发的预期信号为事件 ID：2022 （票证时间异常） 。但是，Synack 的测试证明，事件 ID 2032 票证异常将改为触发。此外，此警报可能会考虑攻击性工具在伪造票证时生成的 TGT 中已发布的异常。
• Event ID: 2040 (Role-Based Constrained Delegation (RBCD) Ticket Anomaly)
  事件 ID：2040 （基于角色的约束委派 （RBCD） 票证异常）
  – This event filters for TGTs created by setting the RBCD permissions via the KRBTGT account for an account with an SPN.
  – 此事件筛选通过 KRBTGT 帐户为具有 SPN 的帐户设置 RBCD 权限而创建的 TGT。

MDI retrieves logs from the MDI sensor located on the domain controllers or the AD FS servers and parses the network traffic, windows security event traces, and Active Directory data. MDI then analyzes these logs and builds baseline profiles. When deviations from the baseline profiles occur, and these deviations match specific filtering, defenders will retrieve an alert from Microsoft 365 Defender. Enabling these security alerts is a good start, but heavy baselining will be required to identify attacks of the gemstone variety. Additionally, many of these alerts have trivial bypasses for an advanced adversary. Defenders should instead try adding context to existing technique-focused alerting rather than just alerting ticket anomalies alone.
MDI 从位于域控制器或 AD FS 服务器上的 MDI 传感器检索日志，并分析网络流量、Windows 安全事件跟踪和 Active Directory 数据。然后，MDI 分析这些日志并构建基线配置文件。当发生与基线配置文件的偏差，并且这些偏差与特定筛选匹配时，防御者将从 Microsoft 365 Defender 检索警报。启用这些安全警报是一个良好的开端，但需要大量的基线来识别宝石品种的攻击。此外，其中许多警报对高级攻击者都有微不足道的绕过。相反，防御者应该尝试为现有的以技术为中心的警报添加上下文，而不仅仅是警报工单异常。

Many organizations attempt to aggregate only the pertinent telemetry to decrease adversary dwell time and ingestion rates. To facilitate a more straightforward selection process, Microsoft has thoughtfully curated a comprehensive chart. This chart outlines the necessary audit policies and their matching event IDs (see Figure 7). It’s a valuable tool for organizations to strengthen their security measures.
许多组织尝试仅聚合相关的遥测数据，以减少对手的停留时间和引入率。为了促进更直接的选择过程，Microsoft 精心策划了一个全面的图表。此图表概述了必要的审计策略及其匹配的事件 ID（参见图 7）。它是组织加强安全措施的宝贵工具。

Furthermore, we advise employing nested security groups for administrative permissions instead of assigning them to individual users. Access should be exclusively reserved for essential personnel based on roles. Infrequent occurrences of Windows Security event IDs 4732 or 4733, which signify alterations in group membership, warrant immediate scrutiny.
此外，我们建议使用嵌套的安全组来获得管理权限，而不是将其分配给单个用户。访问权限应仅保留给基于角色的基本人员。Windows 安全中心事件 ID 4732 或 4733 的罕见出现（表示组成员身份的更改）需要立即检查。

Audit procedures should include checking Windows Security event ID 4776, which verifies account credentials. A domain controller logs this event whenever it tries to validate an account’s credentials using NTLM over Kerberos or when NTLM logon attempts occur to the local SAM account. Event ID 4776 helps identify the forced use of NTLM, which enables defenders to detect attacks that primarily focus on using an NTLM hash of a password. Microsoft explains that this event exclusively originates from the authoritative source of the credentials. In Active Directory, the domain controller acts as this authoritative source, and the Source Workstation field will display the event ID 4776 alongside the identification of the requesting client. This event, particularly noticeable during tool testing involving forged tickets, can operate with nested security groups to identify unusual NTLM authentication requests.
审核过程应包括检查 Windows 安全中心事件 ID 4776，该事件 ID 4776 验证帐户凭据。每当域控制器尝试使用 NTLM over Kerberos 验证帐户的凭据时，或者当本地 SAM 帐户尝试进行 NTLM 登录时，域控制器都会记录此事件。事件 ID 4776 有助于识别强制使用 NTLM，使防御者能够检测主要侧重于使用密码的 NTLM 哈希的攻击。Microsoft 解释说，此事件完全源自凭据的权威来源。在 Active Directory 中，域控制器充当此权威源，“源工作站”字段将显示事件 ID 4776 以及请求客户端的标识。此事件在涉及伪造票证的工具测试期间尤为明显，可以使用嵌套的安全组来识别异常的 NTLM 身份验证请求。

Like Windows Security event ID 4776, logon telemetry originates from various sources based on the authentication method and credential source. Interactive logons generate event ID 4624 at a local capacity (Logon Type 2 — “Interactive”), with the client serving as the authoritative source of the credentials. In instances where remote logins employ Kerberos to validate the presented credentials (Logon Type 3 — “Remote”), the authoritative source of the credential is the domain controller. However, when adversaries send NTLM password hashes directly to a remote client, the 4624 Logon Type 3 is generated on the remote host (and not the domain controller), as the remote host is the authoritative source of the credential. A similar situation occurs when adversaries provide stolen credentials to a thread within an attacker-controlled process with methods such as Cobalt Strike’s make_token module. This method will generate a 4624 Logon Type 9 — NewCredentials with the client hosting the compromised process as the authoritative source of the event.
与 Windows 安全中心事件 ID 4776 一样，登录遥测数据基于身份验证方法和凭据源源的各种源。交互式登录以本地容量生成事件 ID 4624（登录类型 2 — “交互式”），客户端充当凭据的权威源。在远程登录使用 Kerberos 验证提供的凭据（登录类型 3 — “远程”）的情况下，凭据的权威来源是域控制器。但是，当攻击者将 NTLM 密码哈希直接发送到远程客户端时，会在远程主机（而不是域控制器）上生成 4624 登录类型 3，因为远程主机是凭据的权威来源。当攻击者使用 Cobalt Strike 的 make_token 模块等方法向攻击者控制的进程中的线程提供被盗凭据时，也会发生类似的情况。此方法将生成 4624 登录类型 9 — NewCredentials，其中托管受感染进程的客户端作为事件的权威源。

It’s vital to recognize this distinction, as many organizations mistakenly think they’re capturing all logon data when they’re only collecting remote logon events from the domain controller. By only ingesting logon telemetry from domain controllers, defenders are inherently blind to many techniques that adversaries must execute to propagate successfully.
认识到这种区别至关重要，因为许多组织错误地认为他们正在捕获所有登录数据，而他们只从域控制器收集远程登录事件。由于仅从域控制器引入登录遥测数据，防御者本质上对攻击者必须执行才能成功传播的许多技术视而不见。

Organizations should not only utilize nested security groups correlated with Windows event IDs but also consider integrating custom tools like bots or automated scripts. These scripts, utilizing utilities such as klist, can examine cached tickets to ensure they correspond with the expected user. Due to the legitimate appearance of these tickets, defenders often must collate information from various sources to identify signs of adversary manipulations or interactions with these valid tickets.
组织不仅应利用与 Windows 事件 ID 关联的嵌套安全组，还应考虑集成机器人或自动化脚本等自定义工具。这些脚本利用 klist 等实用程序，可以检查缓存的票证，以确保它们与预期用户相对应。由于这些票证的合法外观，防御者通常必须整理来自各种来源的信息，以识别对手操纵或与这些有效票证互动的迹象。

The 8th Season 第八季

Much like the final season of Game of Thrones, trying to evict a persistent adversary out of your domain can be trying. Since Kerberos is one of Microsoft’s authentication technologies, the “gemstone” variety of techniques can be challenging for defenders to identify. The detection in-depth approach is more challenging than just implementing a vendor solution. We believe constant testing and research is the only way to incorporate a defensive praxis in your organization and environment because the only thing worse than a compromise is a reoccurring compromise.
就像《权力的游戏》的最后一季一样，试图将一个顽固的对手驱逐出你的领域可能是一次尝试。由于Kerberos是Microsoft的身份验证技术之一，因此防御者很难识别各种“宝石”技术。深度检测方法比仅仅实施供应商解决方案更具挑战性。我们相信，不断的测试和研究是将防御性实践纳入您的组织和环境中的唯一途径，因为唯一比妥协更糟糕的是反复出现的妥协。

Organizations often pursue cost-effective remediation steps — short-cutting the more resource-intensive remediation requirements, leading to a false sense of security. While telemetry might show past adversary access to privileged accounts, it doesn’t confirm current access. Due to telemetry and resource constraints, no organization can ensure complete adversary eviction, emphasizing the need for comprehensive remediation.
组织通常会采取具有成本效益的补救措施，从而缩短资源密集型补救措施的要求，从而导致虚假的安全感。虽然遥测数据可能会显示攻击者过去对特权帐户的访问，但它不会确认当前访问权限。由于遥测和资源限制，任何组织都无法确保完全驱逐对手，这凸显了全面修正的必要性。

Detection engineers should validate these techniques in labs and their environments. The provided detection methods are foundational and require context for accuracy. A dedicated sprint should focus on detecting these techniques, indicative of total domain compromise.
检测工程师应在实验室及其环境中验证这些技术。提供的检测方法是基础方法，需要上下文才能准确。专用冲刺 （sprint） 应侧重于检测这些技术，以指示完全的域泄露。

References 引用

• Forest Recovery Guide, Microsoft, https://github.com/MicrosoftDocs/windowsserverdocs/tree/main/WindowsServerDocs/identity/ad-ds/manage/forest-recovery-guide
  《森林恢复指南》Microsoft https://github.com/MicrosoftDocs/windowsserverdocs/tree/main/WindowsServerDocs/identity/ad-ds/manage/forest-recovery-guide
• Active Directory Forest Recovery — Devise an AD forest recovery plan, Microsoft, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-devise-a-plan
  Active Directory 林恢复 — 制定 AD 林恢复计划、Microsoft https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-devise-a-plan
• Active Directory Forest Recovery — Recover a single domain in a multidomain forest, Microsoft, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-recover-single-domain-multidomain-forest
  Active Directory 林恢复 — 恢复多域林、Microsoft https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-recover-single-domain-multidomain-forest 中的单个域
• AD DS Audit Policy Recommendations, Microsoft, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
  AD DS 审核策略建议、Microsoft https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations

原文始发于Nico Shyne & Josh Prager：Domain of Thrones: Part II