Recent Posts

Phishing for Primary Refresh Tokens and Windows Hello keys

11 minute read

In Microsoft Entra ID (formerly Azure AD, in this blog referred to as “Azure AD”), there are different types of OAuth tokens. The most powerful token is a Primary Refresh Token, which is linked to a user’s device and can be used to sign in to any Entra ID connected application and web site. In phishing scenarios, especially those that abuse legit OAuth flows such as device code phishing, the resulting tokens are often less powerful tokens that are limited in scope or usage methods. In this blog, I will describe new techniques to phish directly for Primary Refresh Tokens, and in some scenarios also deploy passwordless credentials that comply with even the strictest MFA policies.

Obtaining Domain Admin from Azure AD by abusing Cloud Kerberos Trust

19 minute read

Many modern enterprises operate in a hybrid environment, where Active Directory is used together with Azure Active Directory. In most cases, identities will be synchronized from the on-premises Active Directory to Azure AD, and the on-premises AD remains authoritative. Because of this integration, it is often possible to move laterally towards Azure AD when the on-premises AD is compromised. Moving laterally from Azure AD to the on-prem AD is less common, as most of the information usually flows from on-premises to the cloud. The Cloud Kerberos Trust model is an exception here, since it creates a trust from the on-premises Active Directory towards Azure AD, and thus it trusts information from Azure AD to perform authentication. In this blog we will look at how this trust can be abused by an attacker that obtains Global Admin in Azure AD, to elevate their privileges to Domain Admin in environments that have...

Introducing ROADtools Token eXchange (roadtx) - Automating Azure AD authentication, Primary Refresh Token (ab)use and device registration

16 minute read

Ever since the initial release of ROADrecon and the ROADtools framework I have been adding new features to it, especially on the authentication side. As a result, it supports many forms of authentication, such as using Primary Refresh Tokens (PRTs), PRT cookies, and regular access/refresh tokens. The authentication modules are all part of the shared library roadlib, and can be used in other tools by importing the library. Even though you can request tokens for any Azure AD connected resource and with many client IDs, the only tool exposing this authentication part was ROADrecon. It always felt unnatural and illogical to tell people that you can use a recon tool to request tokens for many other purposes. So I decided to start writing a new tool, which resolves around requesting and using Azure AD tokens. As I was working on this, I started adding proof of concepts I wrote during...

Abusing forgotten permissions on computer objects in Active Directory

10 minute read

A while back, I read an interesting blog by Oddvar Moe about Pre-created computer accounts in Active Directory. In the blog, Oddvar also describes the option to configure who can join the computer to the domain after the object is created. This sets an interesting ACL on computer accounts, allowing the principal who gets those rights to reset the computer account password via the “All extended rights” option. That sounded quite interesting, so I did some more digging into this and found there are more ACLs set when you use this option, which not only allows this principal to reset the password but also to configure Resource-Based Constrained Delegation. BloodHound was missing this ACL, and I dug into why, which I’ve written up in this short blog. If an environment is sufficiently large (and/or old), someone at some point likely added a few systems to the domain with this option...

Relaying Kerberos over DNS using krbrelayx and mitm6

11 minute read

One thing I love is when I think I understand a topic well, and then someone proves me quite wrong. That was more or less what happened when James Forshaw published a blog on Kerberos relaying, which disproves my conclusion that you can’t relay Kerberos from a few years ago. James showed that there are some tricks to make Windows authenticate to a different Service Principal Name (SPN) than what would normally be derived from the hostname the client is connecting to, which means Kerberos is not fully relay-proof as I assumed. This triggered me to look into some alternative abuse paths, including something I worked on a few years back but could never get to work: relaying DNS authentication. This is especially relevant when you have the ability to spoof a DNS server via DHCPv6 spoofing with mitm6. In this scenario, you can get victim machines to reliably authenticate...