Webinar: PowerShell in the Land of DevOps

May 29, 2020 | Michael Grafnetter | No Comments on Webinar: PowerShell in the Land of DevOps

I will be hosting a webinar titled “PowerShell in the Land of DevOps” on Monday, June 29, 2020, 10:00 AM – 11:30 AM CEST. We will explore features of PowerShell that can be used to automate the deployment of server applications, validate the infrastructure configuration against a well-defined baseline, and orchestrate software tests with GitHub or Azure DevOps.

If you are interested, you can register for this event through GoToWebinar.

PowerShell in the Land of DevOps

Tags: , , ,

Cross-Forest Duplicate Password Discovery

March 24, 2020 | Michael Grafnetter | No Comments on 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:

The output of the previous script might look like this (with some parts omitted):

The example above uses the MS-DRSR protocol. Similar results can be achieved by using the Get-ADDBAccount cmdlet to read account information directly from a ntds.dit file.

Extracting Roamed Private Keys from Active Directory

March 24, 2020 | Michael Grafnetter | No Comments on Extracting Roamed Private Keys from Active Directory

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.

Impersonating Office 365 Users With Mimikatz

January 15, 2017 | Michael Grafnetter | 1 Comment on 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:

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!

The Nasty Stuff

To test this technique, we need to retrieve some information from Active Directory first:

  1. NTLM password hash of the AZUREADSSOACC account, e.g. f9969e088b2c13d93833d0ce436c76dd. This value can be retrieved from AD using mimikatz:

    My own DSInternals PowerShell Module could do the same job:

    Both of these commands need Domain Admins permissions.
  2. Name of the AD domain, e.g. contoso.local.
  3. AAD logon name of the user we want to impersonate, e.g. elrond@contoso.com. This is typically either his userPrincipalName or mail attribute from the on-prem AD.
  4. SID of the user we want to impersonate, e.g. S-1-5-21-2121516926-2695913149-3163778339-1234.

Having this information we can now create and use the Silver Ticket on any Windows computer connected to the internet. It does not even matter whether it is joined to a domain or a workgroup:

  1. Create the Silver Ticket and inject it into Kerberos cache:
  2. Launch Mozilla Firefox.
  3. Go to about:config and set the network.negotiate-auth.trusted-uris preference to value “https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com”.
  4. Navigate to any web application that is integrated with our AAD domain. We will use Office 365, which is the most commonly used one.
  5. Once at the logon screen, fill in the user name, while leaving the password field empty. Then press TAB or ENTER.
  6. That’s it, we’re in!
  7. To log in as another user, run the command below and repeat steps 1-6.

It is also worth noting that the password of the AZUREADSSOACC account never changes, so the stolen hash/key will work forever. It could therefore be misused by highly privileged employees to retain access to the IT environment after leaving the company. Dealing with such situations is a much broader problem, which is aptly depicted by the following old Narnian saying:


First of all, I have to point out that this technique would not be very practical in real-world situations due to these reasons:

  • The SSO feature is in Preview and has to be explicitly enabled by an AD admin. Just a handful of companies probably use it at the time of writing this article and enterprises will quite surely stick to their proven ADFS deployments even after this feature reaches GA.
  • The hash/key of the AZUREADSSOACC account can only be retrieved by Domain Admins from DCs by default. But if an attacker had such highly privileged access to an Active Directory domain, he/she would be able to do some way nastier stuff than just replicating a single hash.
  • The password of the AZUREADSSOACC account is randomly generated during the deployment of Azure AD Connect. It would therefore be impossible to guess this password.

As you can see, there is simply no need to panic. But just to be safe, I would recommend these generic security measures:

  • Only delegate administrative access to trusted individuals and keep the number of members of the Domain Admins group (and other privileged groups) as low as possible.
  • Protect backups of Domain Controllers, so no-one could extract sensitive information from them.
  • Enable and enforce Azure MFA for users authenticating from external IP addresses. It is very straightforward and effective against many kinds of attacks.
  • Consider implementing Azure AD conditional access.
  • Deploy Microsoft Advanced Threat Analytics to detect malicious replication and other threats to your AD infrastructure.
  • Force a password change on the AZUREADSSOACC account by re-deploying Azure AD Connect SSO running the Update-AzureSSOForest cmdlet after a highly privileged employee leaves the company and/or on a regular basis. This should be done together with resetting the password of krbtgt and other sensitive accounts.


Although the Silver Ticket attack has been here for some years, it is now probably the first time it can be used over the internet against a cloud service, which theoretically makes it even more potent. On the other hand, it would be quite hard to  perform this technique in a real-world environment due to impracticalities discussed in the previous section, so there is no need to worry. The new Seamless SSO feature of Azure AD Connect can therefore be considered safe and preferred solution for SSO to Office 365 .

Tags: , , , ,

Finding Weak Active Directory Passwords

January 11, 2017 | Michael Grafnetter | 3 Comments on 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:

It generates reports which are suitable for the management:


Of course, you can also drill down through the detailed data:

Here is a quick demo of the tool:

Did I mention that the Weak Password Finder is totally FREE?