https://www.dsinternals.com/en/ Fri, 05 Jun 2026 10:04:44 +0000 Fri, 05 Jun 2026 10:04:44 +0000 Jekyll v4.4.1 I will be presenting my latest research Pass-the-Passkey Family of Attacks at Black Hat USA 26 in Las Vegas, August 1–6, 2026. Passkeys are slowly but steadily becoming the norm – and our novel research has shown that several real-world implementations are vulnerable to attacks fundamentally similar to Pass-the-Hash and NTLM Relay. We call this category Pass-the-Passkey. In the session I will demonstrate: A Passkey implementation in a major cloud service that is vulnerable to the very attacks it was designed to prevent. Past YubiKey signatures stored in cleartext and readable by authenticated unprivileged users – even remote ones. Impersonation of privileged identities while bypassing phishing-resistant MFA enforcement and staying invisible to popular XDR solutions. Passkey phishing, tampering, spoofing, fuzzing, and prompt-flooding techniques – some executable from compromised terminal hosts or VMs, demonstrated against a popular C2 framework. The WebAuthn specification mandates a 22-step Passkey validation process involving non-trivial cryptography and transactional processing, so making a mistake while implementing the spec is easy – even for companies that co-authored the standard. By open-sourcing our tooling, we aim to help other penetration testers discover many more vulnerabilities stemming from non-compliant Passkey verification. Also check out the Black Hat Briefings talks and Arsenal presentations of my colleagues from SpecterOps. See you in Las Vegas! Fri, 05 Jun 2026 02:00:00 +0000 https://www.dsinternals.com/en/black-hat-usa-26-pass-the-passkey/ https://www.dsinternals.com/en/black-hat-usa-26-pass-the-passkey/ Recording of my SO-CON 2026 talk, co-presented with Lance Cain: Security specialists and end users appreciate the convenience of single sign-on (SSO) technologies like Okta. Unfortunately, attackers do too. We will explore how compromised human or machine identities can lead to hybrid attack paths that begin in Active Directory, move through Okta, and reach critical assets such as Git repositories, CI/CD pipelines, cloud storage, or enterprise password managers. We will also demonstrate how adversaries can deliver payloads to macOS devices by leveraging Okta and third-party MDMs. SO-CON 2026 slide deck Thu, 04 Jun 2026 00:00:00 +0000 https://www.dsinternals.com/en/video-okta-hybrid-attack-paths-socon/ https://www.dsinternals.com/en/video-okta-hybrid-attack-paths-socon/ I will be speaking at TROOPERS26 in Heidelberg, Germany, from June 22–26, 2026, in the new Active Directory & Entra ID Security track. My session, KDS Root Keys: All Secrets Finally Revealed, will dive into online and offline attacks against virtually every use case of KDS Root Keys, including: Decryption of volumes with BitLocker SID Protector enabled. Exporting RSA private keys from group-protected PFX files. Extracting DNSSEC signing keys (ZSK and KSK) from Active Directory. Recovering ASP.NET Core database connection strings. Bulk export of Windows LAPS and DSRM passwords. Generation of gMSA and dMSA passwords offline. The session also covers a newly discovered universal attack against DPAPI-NG SID protectors, allowing any application-encrypted secret to be unlocked without application-specific decryptors. See you in Heidelberg! Thu, 04 Jun 2026 00:00:00 +0000 https://www.dsinternals.com/en/troopers-26-kds-root-keys/ https://www.dsinternals.com/en/troopers-26-kds-root-keys/ After presenting my novel research on KDS Root Keys to the European audience at TROOPERS26 in Heidelberg, I am thrilled to get the opportunity to share it with the US audience in vibrant Nashville. I will be speaking at the Hybrid Identity Protection Conference 26 in Nashville, Tennessee, on September 8–10, 2026. My session, KDS Root Keys and Where to Find Them, is scheduled for Wednesday, September 9 at 11:15 AM in the Identity Security Research track. KDS Root Keys are the cryptographic seeds that Active Directory uses to derive gMSA and dMSA passwords, encrypt Windows LAPS secrets, and power DPAPI-NG SID protectors. Stealing them unlocks far more than just a single account. The session will cover online and offline attacks against virtually every use case of KDS Root Keys, including: Decryption of volumes with BitLocker SID Protector enabled. Exporting RSA private keys from group-protected PFX files. Extracting DNSSEC signing keys (ZSK and KSK) from Active Directory. Recovering ASP.NET Core database connection strings. Bulk export of Windows LAPS and DSRM passwords. Generation of gMSA and dMSA passwords offline. I will also reveal a newly discovered universal attack against DPAPI-NG SID protectors, allowing any application-encrypted secret to be unlocked without application-specific decryptors. See you in Nashville! Thu, 04 Jun 2026 00:00:00 +0000 https://www.dsinternals.com/en/hipconf-26-kds-root-keys/ https://www.dsinternals.com/en/hipconf-26-kds-root-keys/ Updated in January 2026 to reflect changes in the behavior of domain controllers regarding the CUSTOMKEYINFO_FLAGS_MFA_NOT_USED flag. TL;DR The current implementation of the shadow credentials attack in the Impacket framework, most notably used by the ntlmrelayx.py script, contains multiple bugs, leaving unique signatures on the NGC data structures written to the msDS-KeyCredentialLink LDAP attribute by malicious actors. Heuristics could be used to identify most malicious NGC keys, regardless of the hacktool they were generated by. Technical Details I noticed by chance that the current implementation of the shadow credentials attack (a term coined and popularized by Elad Shamir) in the Impacket framework produces malformed KEYCREDENTIALLINK_BLOB binary data structures, having the following issues: The KeyHash entry should contain a SHA256 hash of all other entries, but it is only calculated from the KeyMaterial entry. (Fixed in September 2025) The KeyCreationTime entry should be in the FILETIME format but is incorrectly skewed by 1600 years. (Fixed in September 2025) The DeviceId entry is expected to be present only on user accounts, but it is populated for computer accounts as well. And instead of referencing existing device objects, it contains random values. These bugs are located in the shadow_credentials.py script, which is then optionally used by the ntlmrelayx.py script when performing the NTLM Relay attack against the LDAP protocol. The shadow credentials attack was originally implemented in version 0.10.0 of Impacket, released in May 2022. The bugs were introduced to the master branch in March 2024 and published in version 0.12.0, released in September 2024. As a result, the DSInternals PowerShell module can be used to identify malformed NGC keys (AKA shadow credentials) that are still present in Active Directory (AD): #Requires -Modules DSInternals,ActiveDirectory Get-ADObject -LDAPFilter '(msDS-KeyCredentialLink=*)' -Properties msDS-KeyCredentialLink | Select-Object -ExpandProperty msDS-KeyCredentialLink | Get-ADKeyCredential | Where-Object Usage -eq NGC Sample output: Usage Source Flags DeviceId Created Owner ----- ------ ----- -------- ------- ----- NGC AD None ff53f58e-81a9-5d40-96bb-4980c91008ae 3625-02-23 CN=PC04,CN=Computers,DC=contoso,DC=com NGC AD None e49d674f-0259-44f3-a3bd-8343b76046fc 2025-02-02 CN=Administrator,CN=Users,DC=contoso,DC=com NGC AD None cfe9a872-13ff-4751-a777-aec88c30a762 2019-08-01 CN=John Doe,CN=Users,DC=contoso,DC=com NGC AzureAD None fd591087-245c-4ff5-a5ea-c14de5e2b32d 2017-07-19 CN=John Doe,CN=Users,DC=contoso,DC=com NGC AD MFANotUsed 2025-02-01 CN=PC01,CN=Computers,DC=contoso,DC=com NGC AD MFANotUsed 2017-08-23 CN=PC02,CN=Computers,DC=contoso,DC=com NGC AD 2021-06-11 CN=PC03,CN=Computers,DC=contoso,DC=com The first NGC key in the output above, supposedly created in the year 3625 instead of 2025, can serve as a very reliable indicator of AD compromise (IoC). Moreover, all open-source implementations of the shadow credentials attack generate random values for the DeviceId attribute. It is therefore possible to use Microsoft’s WHfBTools PowerShell module to identify orphaned NGC keys with non-existing device identifiers. The sample data also shows that the CUSTOMKEYINFO_FLAGS_MFA_NOT_USED flag in the CustomKeyInformation entry is used inconsistently by Windows 10+ computers, making it an unreliable indicator of malicious NGC keys. However, since January 2026 updates, domain controllers block validated writes of NGC keys with this flag absent, which violates the specification. Future Work As other implementations of the shadow credential attack might contain similar issues, broader research on this topic should be conducted. Although hacktool authors will probably react to the information contained in this article and improve their implementations accordingly, these changes will not affect pre-existing shadow credentials. Although the current version of DSInternals does not validate the KeyHash entries when parsing existing NGC keys, it correctly implements the hash calculation when generating new NGC keys or serializing existing ones. It should not be hard to implement hash validation as well. Fri, 30 Jan 2026 00:00:00 +0000 https://www.dsinternals.com/en/indicator-of-compromise-shadow-credentials-ntlm-relay-impacket/ https://www.dsinternals.com/en/indicator-of-compromise-shadow-credentials-ntlm-relay-impacket/ This blog post has originally been published at the SpecterOps Blog. Introduction Several new Active Directory offline attack capabilities have recently been added to the DSInternals PowerShell module. These enhancements include the Golden dMSA Attack, full support for Local Administrator Password Solution (LAPS), and the ability to extract trust passwords and BitLocker recovery keys. And thanks to some changes made under the hood, large ntds.dit files (100K+ users) process much faster and it is now possible to read databases originating from read-only domain controllers (RODCs). As a result, DSInternals can access all types of secret and confidential information stored in ntds.dit files, solidifying its status as the most comprehensive and feature-rich tool in its category. Offline Golden dMSA Attack The Get-ADDBServiceAccount cmdlet now retrieves both msDS-GroupManagedServiceAccount (gMSA) (introduced in Windows Server 2012) and msDS-DelegatedManagedServiceAccount (dMSA) (introduced in Windows Server 2025) object types from ntds.dit files and calculates their current managed passwords using KDS Root Keys also stored in the database. Depending on the account type, the attacks are referred to as Golden gMSA or Golden dMSA. Example: Get-ADDBServiceAccount -DatabasePath 'C:\ADBackup\ntds.dit' Sample output: 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 (Calculated) EffectivePasswordId: RootKey=7dc95c96-fa85-183a-dff5-f70696bf0b11, Cycle=6/25/2025 8:00:00 PM (L0=363, L1=11, L2=29) NTHash: 0b5fbfb646dd7bce4f160ad69edb86ba Kerberos Keys AES256_CTS_HMAC_SHA1_96 Key: 5dcc418cd0a30453b267e6e5b158be4b4d80d23fd72a6ae4d5bd07f023517117 Iterations: 4096 AES128_CTS_HMAC_SHA1_96 Key: 8e1e66438a15d764ae2242eefd15e09a Iterations: 4096 Thu, 14 Aug 2025 00:00:00 +0000 https://www.dsinternals.com/en/active-directory-offline-attacks-dsinternals-v6/ https://www.dsinternals.com/en/active-directory-offline-attacks-dsinternals-v6/ Introduction It is best practice to register applications in Entra ID using PowerShell (or another automation tool that utilizes the Microsoft Graph API), rather than adding them manually through the Microsoft Entra Admin Center. This approach offers several advantages: Repeatable Deployment Process: Automating the registration helps prevent human errors that could lead to misconfigurations or security issues. Fast Cross-Tenant Migration: Scripting allows for quick migration between development, testing, and production environments. (You do have at least one pre-production Entra ID tenant, right?) Access to Advanced Settings: Some advanced settings are only available through the Microsoft Graph API and not exposed in the Microsoft Entra Admin Center. Improved Customer Experience: Providing customers with reliable scripts can enhance their product experience and may also reduce support costs for software vendors. Documentation: PowerShell scripts can serve as definitive and up-to-date documentation for the correct configuration of applications. Infrastructure as Code: All the advantages associated with the broader Infrastructure as Code (IaC) practice apply as well. In this article, you will learn how to automate the registration process for AzureHound, the data collector application for BloodHound Enterprise. With only minor modifications, this guide can be applied to automatically register almost any service or daemon application that is using the OAuth 2.0 client credentials grant flow in Entra ID. Required User Permissions To register applications with Microsoft Graph permissions in Entra ID, non-trivial user permissions are required. As an alternative to the almighty Global Administrator role, the following role assignments should be sufficient: Cloud Application Administrator or Application Administrator, for creating the app registration. Privileged Role Administrator, for assigning the required directory role and granting admin consent for the Microsoft Graph permissions. The User Access Administrator role is additionally needed for delegating permissions in Azure. App Registration First, we need to install the required official Microsoft.Graph.* and Az.* PowerShell modules: Install-Module -Scope AllUsers -Repository PSGallery -Force -Name @( Microsoft.Graph.Applications, Microsoft.Graph.Authentication, Microsoft.Graph.Identity.DirectoryManagement, Az.Resources, Az.Accounts ) Next, we can connect to the Microsoft Graph API while specifying all necessary permissions for the app registration process: Connect-MgGraph -NoWelcome -ContextScope Process -Scopes @( 'User.Read', 'Application.ReadWrite.All', 'AppRoleAssignment.ReadWrite.All', 'RoleManagement.ReadWrite.Directory' ) We are now ready to register the BloodHound Enterprise Collector application in Entra ID: [string] $appName = 'BloodHound Enterprise Collector' [string] $appDescription = 'Azure Data Exporter for BloodHound Enterprise (AzureHound)' [string] $homePage = 'https://specterops.io/bloodhound-enterprise' [hashtable] $infoUrls = @{ MarketingUrl = 'https://specterops.io/bloodhound-enterprise' TermsOfServiceUrl = 'https://specterops.io/terms-of-service' PrivacyStatementUrl = 'https://specterops.io/privacy-policy' SupportUrl = 'https://support.bloodhoundenterprise.io/' } [hashtable] $webUrls = @{ HomePageUrl = $homePage } [Microsoft.Graph.PowerShell.Models.IMicrosoftGraphApplication] $registeredApp = New-MgApplication -DisplayName $appName ` -Description $appDescription ` -Info $infoUrls ` -Web $webUrls ` -SignInAudience 'AzureADMyOrg' Wed, 30 Jul 2025 00:00:00 +0000 https://www.dsinternals.com/en/entra-id-azurehound-bloodhound-oauth-register-microsoft-graph-api-powershell/ https://www.dsinternals.com/en/entra-id-azurehound-bloodhound-oauth-register-microsoft-graph-api-powershell/ Introduction In this article you will learn how the Claims X-Ray NG application can be registered in Microsoft Entra ID using the Microsoft Graph PowerShell SDK. With only minor modifications, this guide can be used to register almost any SAML-based application in Entra ID using PowerShell. The Claims X-Ray NG app is a free tool that can be used to test federated identity providers and simulate application migration scenarios. It can be deployed as a drop-in replacement of the now-defunct original Claims X-Ray application from Microsoft. 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 Microsoft Graph API while specifying all permissions required by the registration process: Connect-MgGraph -NoWelcome -ContextScope Process -Scopes @( 'User.Read', '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 NG application in Entra ID: [string] $appName = 'Claims X-Ray NG' [string] $appDescription = 'Use the Claims X-Ray NG service to debug and troubleshoot problems with claims issuance.' [string] $redirectUrl = 'https://claimsxray.net/api/sso' [hashtable] $infoUrls = @{ MarketingUrl = 'https://claimsxray.net/#about' TermsOfServiceUrl = 'https://github.com/marcusca10/claimsxray-ng?tab=MIT-1-ov-file' } [Microsoft.Graph.PowerShell.Models.IMicrosoftGraphApplication] $registeredApp = New-MgApplication -DisplayName $appName ` -Description $appDescription ` -Web @{ RedirectUris = $redirectUrl } ` -DefaultRedirectUri $redirectUrl ` -GroupMembershipClaims All ` -Info $infoUrls Fri, 28 Mar 2025 00:00:00 +0000 https://www.dsinternals.com/en/entra-id-claims-xray-ng-saml-powershell-graph-api/ https://www.dsinternals.com/en/entra-id-claims-xray-ng-saml-powershell-graph-api/ In the recently released Windows Server 2025 and Windows 11 24H2, several network protocols have been reconfigured to be more secure by default. One of the affected protocols is the Server Message Block (SMB), where message signing is now required under most circumstances. These changes eliminate some NTLM Relay Attack vectors, but do not mitigate this hacking technique completely. The following table summarizes the old and new SMB signing enforcement defaults: Operating System SMB Client SMB Server Windows Server 2022 DC ❌* ✅ Windows Server 2022 Member ❌* ❌ Windows 11 23H2 ❌* ❌ Windows Server 2025 DC ✅ ✅ Windows Server 2025 Member ✅ ❌ Windows 11 24H2 ✅ ✅ Legend: ✅ SMB signing is required. ❌ SMB signing is not required. ❌* SMB signing is only mandated when connecting to SYSVOL and NETLOGON shares that contain Group Policy Objects (GPOs) and logon scripts. Sun, 26 Jan 2025 00:00:00 +0000 https://www.dsinternals.com/en/smb-signing-windows-server-2025-client-11-24h2-defaults/ https://www.dsinternals.com/en/smb-signing-windows-server-2025-client-11-24h2-defaults/ As passwordless authentication using Passkeys is finding its way into more and more Entra ID tenants, it is crucial for security auditors to get more than familiar with this technology. Although the FIDO2 security key management plane in the Entra ID Portal is continually improving, any security assessment of FIDO2 key usage still involves a lot of clicking: That is one of the reasons why I added the capability to retrieve the list of all FIDO2 security keys registered in an Entra ID tenant into the DSInternals PowerShell module some years ago. Since then, the same capability has been added to the official Microsoft Graph API, making FIDO2-related PowerShell queries easier than ever: # Microsoft Graph API PowerShell modules must be already installed on the computer Import-Module -Name Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Identity.SignIns ` -ErrorAction Stop # Authenticate against Entra ID Connect-MgGraph -Scopes UserAuthenticationMethod.Read ` -ContextScope Process ` -NoWelcome ` -ErrorAction Stop # Fetch FIDO2 security key details for all users Get-MgUser -All -Property Id,UserPrincipalName | ForEach-Object { Get-MgUserAuthenticationFido2Method -UserId $PSItem.Id | Add-Member -MemberType NoteProperty -Name UserPrincipalName -Value $PSItem.UserPrincipalName -PassThru } | Format-Table -Property UserPrincipalName,CreatedDateTime,DisplayName,Model,AttestationLevel,AaGuid # Logout Disconnect-MgGraph The output of the above script should look similar to the following example: UserPrincipalName CreatedDateTime DisplayName Model AttestationLevel AaGuid ----------------- --------------- ----------- ----- ---------------- ------ michael@dsinternals.com 10/29/2023 12:40:57 PM AWSC Passkey Test notAttested 01020304-0506-0708-0102-030405060708 michael@dsinternals.com 6/13/2023 8:47:47 PM Feitian NFC Feitian ePass FIDO2-NFC Authenticator attested ee041bce-25e5-4cdb-8f86-897fd6418464 michael@dsinternals.com 4/15/2023 6:55:15 AM Feitian Combi Feitian iePass FIDO Authenticator attested 3e22415d-7fdf-4ea4-8a0c-dd60c4249b9d michael@dsinternals.com 12/12/2019 9:42:21 AM YubiKey 5 YubiKey 5 Series attested cb69481e-8ff7-4039-93ec-0a2729a154a8 michael@dsinternals.com 1/14/2022 3:25:27 PM Feitian USB FP Feitian BioPass FIDO2 Authenticator attested 77010bd7-212a-4fc9-b236-d2ca5e9d4084 Additionally, the Format-Table cmdlet can also be replaced with Out-GridView: Get-MgUser -All -Property Id,UserPrincipalName | ForEach-Object { Get-MgUserAuthenticationFido2Method -UserId $PSItem.Id | Add-Member -MemberType NoteProperty -Name UserPrincipalName -Value $PSItem.UserPrincipalName -PassThru } | Select-Object -Property UserPrincipalName,CreatedDateTime,DisplayName,Model,AttestationLevel,AaGuid | Out-GridView -Title 'FIDO2 Security Keys Registered in Entra ID Tenant' -Wait This should produce a nice table with searchable and sortable data: Mon, 25 Mar 2024 00:00:00 +0000 https://www.dsinternals.com/en/entra-id-fido2-passkeys-report-powershell-graph-api/ https://www.dsinternals.com/en/entra-id-fido2-passkeys-report-powershell-graph-api/