Directory Services Internals Blog
What are the 8 most common mistakes admins do when configuring Azure Active Directory?
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:
The Test-PasswordQuality cmdlet now supports cross-domain and cross-forest duplicate password discovery and offline password hash comparison against HaveIBeenPwned:(more...)
$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'
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.
Here is the recording of my Black Hat Europe 2019 Briefings session about Exploiting Windows Hello for Business:
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:
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!(more...)
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:
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.
Get-ADReplAccount -All -Server LON-DC1 -NamingContext "dc=adatum,dc=com" | Test-PasswordQuality -WeakPasswordHashesFile .\pwned-passwords-ntlm-ordered-by-count.txt -IncludeDisabledAccounts
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:
- Dumping NT hashes, kerberos keys and cleartext passwords from ntds.dit files.
- Modifying the SID History of user accounts and groups.
- Modifying the Primary Group ID of user accounts.
- Extracting the DPAPI domain backup keys.
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:(more...)
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:(more...)
# 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'
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.(more...)
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:(more...)
# 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
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.(more...)
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.
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.
Import-Module DSInternals $cred = Get-Credential Get-ADReplAccount -SamAccountName April -Domain Adatum -Server LON-DC1 ` -Credential $cred -Protocol TCP