Directory Services Internals Blog

  • 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
     Read more...

  • OU Filtering With DSInternals PowerShell Cmdlets

    One of the most frequent questions I am asked about the DSInternals PowerShell Module cmdlets that fetch password hashes from Active Directory (Get-ADReplAccount and Get-ADDBAccount) is whether they could only return accounts from a specified organizational unit (OU). While OU-based filtering is not yet implemented in DSInternals directly, two PowerShell built-in features could be used to achieve this goal.

    A. Where-Object

    The Where-Object cmdlet can easily be used to filter out unwanted objects based on any property, including OU:

    <#
Replicates all AD accounts (DCSync), filters them by the Admins OU,
and tests their passwords against Have I Been Pwned (HIBP) list.
#>
Get-ADReplAccount -All -Server 'dc01.contoso.com' |
    Where-Object DistinguishedName -like '*,OU=Admins,DC=contoso,DC=com' |
    Test-PasswordQuality -WeakPasswordHashesSortedFile pwned-passwords-ntlm-ordered-by-hash-v7.txt
     Read more...

  • 8 Things to Avoid in Azure Active Directory

    What are the 8 most common mistakes admins do when configuring Azure Active Directory?

    8 Things to Avoid in Azure Active Directory

  • Video: Getting Rid of Passwords with FIDO2 and W3C WebAuthn

    Getting Rid of Passwords with FIDO2 and W3C WebAuthn

  • Video: Active Directory Database Security

    Active Directory Database Security

  • Video: A Look Inside a Pass-the-PRT Attack

    Like an NT hash (AKA NTLM hash AKA MD4 hash) and a Kerberos ticket, a Primary Refresh Token (PRT) can be passed in an attack. Mimikatz author Benjamin Delpy and Dirk-jan Mollema have both released detailed research and code showing how attackers could Pass-the-PRT to perform the lateral movement to the cloud.

    I have recorded a short demo of the Pass-the-PRT Attack:

  • 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'
     Read more...

  • Extracting Roamed Private Keys from Active Directory

    #CQLabs 7

    One of the lesser known features of Active Directory (AD) is called Credential Roaming. When enabled, it synchronizes DPAPI Master Keys, user certificates (including the corresponding private keys) and even saved passwords between computers. These credentials can easily be extracted from Active Directory database. If you want to learn more on this topic, be sure to read my #CQLabs article.

  • Video: Exploiting Windows Hello for Business

    Here is the recording of my Black Hat Europe 2019 Briefings session about Exploiting Windows Hello for Business:

  • Black Hat Europe 2019 Slides

    Michael at Black Hat

  • Video: Offline Attacks on Active Directory

    HipConf 2018 slide deck

  • Impersonating Office 365 Users With Mimikatz

    Last month, Microsoft has introduced a new feature of Azure AD Connect called Single Sign On. It allows companies to configure SSO between AD and AAD without the need to deploy ADFS, which makes it an ideal solution for SMEs. Here is a high-level diagram of this functionality:

    Azure AD Connect SSO Diagram

    As we can see from the diagram above, Azure AD exposes a publicly available endpoint that accepts Kerberos tickets and translates them into SAML and JWT tokens, which are understood and trusted by other cloud services like Office 365, Azure or Salesforce. And wherever you have Kerberos-based authentication, it can be attacked using Silver Tickets.

    In usual circumstances this attack can only be performed from the intranet. But what really caught my attention is the fact that with this new SSO feature, Silver Tickets could be used from the entire internet. Let’s give it a try then!

     Read more...

  • Finding Weak Active Directory Passwords

    I recently worked with Thycotic to create a program called Weak Password Finder for Active Directory. The goal was to develop a tool that would be very easy to use yet powerful enough to yield actionable results. I think that this combination really makes it unique in the market. It basically does the same as my PowerShell module, but with a nice and shiny user interface:

    Screenshot 1

     Read more...

  • Auditing Active Directory Password Quality

    Overview

    The latest version of the DSInternals PowerShell Module contains a new cmdlet called Test-PasswordQuality, which is a powerful yet easy to use tool for Active Directory password auditing. It can detect weak, duplicate, default, non-expiring or empty passwords and find accounts that are violating security best practices. All domain administrators can now audit Active Directory passwords on a regular basis, without any special knowledge.

    Usage

    The Test-PasswordQuality cmdlet accepts output of the Get-ADDBAccount and Get-ADReplAccount cmdlets, so both offline (ntds.dit) and online (DCSync) analysis can be done:

    Get-ADReplAccount -All -Server LON-DC1 -NamingContext "dc=adatum,dc=com" |
   Test-PasswordQuality -WeakPasswordHashesFile .\pwned-passwords-ntlm-ordered-by-count.txt -IncludeDisabledAccounts
     Read more...

  • Dumping and Modifying Active Directory Database Using a Bootable Flash Drive

    Since version 2.15, the DSInternals PowerShell Module fully supports Windows PE, the free minimalistic edition of Windows. This means that all the nasty Active Directory database stuff can now be performed from a bootable flash drive or an ISO image, including:

    Windows PE DSInternals

     Read more...

  • How the Active Directory Expiring Links Feature Really Works

    One of the new features in Windows Server 2016 will be the Active Directory Expiring Links feature, which enables time-bound group membership, expressed by a time-to-live (TTL) value. Here is how it works:

     Read more...

  • Retrieving Cleartext GMSA Passwords from Active Directory

    Have you ever wondered how the automatically generated passwords of Group Managed Service Accounts (GMSA) look like? Well, you can fetch them from Active Directory in the same way as Windows Servers do and see yourself. Here is how:

    Creating a GMSA

    To start experimenting, we need to have a GMSA first, so we create one:

    # Create a new KDS Root Key that will be used by DC to generate managed passwords
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

# Create a new GMSA
New-ADServiceAccount `
	-Name 'SQL_HQ_Primary' `
	-DNSHostName 'sql1.adatum.com'
     Read more...

  • Retrieving DPAPI Backup Keys from Active Directory

    The Data Protection API (DPAPI) is used by several components of Windows to securely store passwords, encryption keys and other sensitive data. When DPAPI is used in an Active Directory domain environment, a copy of user’s master key is encrypted with a so-called DPAPI Domain Backup Key that is known to all domain controllers. Windows Server 2000 DCs use a symmetric key and newer systems use a public/private key pair. If the user password is reset and the original master key is rendered inaccessible to the user, the user’s access to the master key is automatically restored using the backup key.

     Read more...

  • Dumping the contents of ntds.dit files using PowerShell

    Although there exist several tools for dumping password hashes from the Active Directory database files, including the open-source NTDSXtract from Csaba Bárta whose great research started it all, they have these limitations:

    • They do not support the built-in indices, so searching for a single object is slow when dealing with large databases.
    • Most of the tools are either Linux-only or running them on Windows is not simple enough.
    • Almost none of these tools can modify the database. And if they do, they do not support transaction logs and are quite cumbersome.

    Therefore, I have decided to create my own set of PowerShell cmdlets that wouldn’t have these shortcomings. In the process, I have unintentionally created my own framework that is built on top of Microsoft’s ManagedEsent library and hides the complexity of the underlying database. I am planning to release it at GitHub later this year.

    One of the cmdlets I have created is Get-ADDBAccount, which can be used to extract password hashes, Kerberos keys and even reversibly encrypted passwords from ntds.dit files. Here is an example of its usage:

    # First, we fetch the so-called Boot Key (aka SysKey)
# that is used to encrypt sensitive data in AD:
$key = Get-BootKey -SystemHivePath 'C:\IFM\registry\SYSTEM'

# We then load the DB and decrypt password hashes of all accounts:
Get-ADDBAccount -All -DBPath 'C:\IFM\Active Directory\ntds.dit' -BootKey $key 

# We can also get a single account by specifying its distinguishedName,
# objectGuid, objectSid or sAMAccountName atribute:
Get-ADDBAccount -DistinguishedName 'CN=krbtgt,CN=Users,DC=Adatum,DC=com' `
        -DBPath 'C:\IFM\Active Directory\ntds.dit' -BootKey $key
     Read more...

  • How Azure Active Directory Connect Syncs Passwords

    Many people have asked me about the security implications of synchronizing passwords from Active Directory to Azure Active Directory using the Azure AD Connect tool. Although there is an article on Technet that claims that the passwords are synced in a very secure hashed form that cannot be misused for authentication against the on-premise Active Directory, it lacks any detail about the exact information being sent to Microsoft’s servers.

    A post at the Active Directory Team Blog hints that the Password Sync agent retrieves pre-existing password hashes from AD and secures them by re-hashing them using SHA256 hash per RFC 2898 (aka PBKDF2) before uploading them to the cloud. This sheds some light on the functionality, but some important implementation details are still missing, including the number of SHA256 iterations, salt length and the type of hash that is extracted from AD. Some research on this topic has been done by Alan Byrne, but it is inconclusive. Therefore, I have decided to do my own research and to share my results.

     Read more...

  • Peeking into the Active Directory Database

    Esent Workbench During my recent talk about inner workings of Active Directory, I showcased the Esent Workbench tool, which can be used to look inside a ntds.dit file. But one must really have stomach for it.

  • Retrieving Active Directory Passwords Remotely

    I have finally finished work on the Get-ADReplAccount cmdlet, the newest addition to my DSInternals PowerShell Module, that can retrieve reversibly encrypted plaintext passwords, password hashes and Kerberos keys of all user accounts from remote domain controllers. This is achieved by simulating the behavior of the dcromo tool and creating a replica of Active Directory database through the MS-DRSR protocol. Furthermore, it has these properties:

    • It does not even need the Domain Admins group membership. The Replicating Directory Changes All permission is more than enough for this cmdlet to do its job.
    • It opens door to other attacks, e.g. pass-the-hash, pass-the-ticket or PAC spoofing, that can be used to seize control of the entire Active Directory forest. Long live mimikatz!
    • It cannot be effectively blocked by firewalls, because the directory replication service (DRSGetNCChanges call to be more precise) shares the same port with other critical services, like user name resolution (exposed by the DsCrackNames call).
    • It only uses documented features of Active Directory and is not a hack per se.
    • It leaves only minimal footprint on Domain Conrollers and can be easily overlooked by security audits.

    Usage example:

    Import-Module DSInternals
$cred = Get-Credential
Get-ADReplAccount -SamAccountName April -Domain Adatum -Server LON-DC1 `
-Credential $cred -Protocol TCP
     Read more...