Dirk-jan Mollema

Dirk-jan Mollema

Hacker, red teamer, researcher. Likes to write infosec-focussed Python tools. This is my personal blog containing research on topics I find interesting, such as (Azure) Active Directory internals, protocols and vulnerabilities.

Looking for a security test or training? Business contact via outsidersecurity.nl

Recent Posts

Borrowing Windows Hello keys for authentication and persistence

11 minute read

Most research into Windows Hello focuses on the mechanics in use when authenticating to the local device. As an Entra ID researcher, I’ve always been more interested in how these keys are used to authenticate to the cloud. I’ve given several talks on Windows Hello for Business (WHFB for short) and about the many implementation flaws discovered in the process, most of which were fixed by Microsoft. For this blog I want to focus on a technique that was left as-is since it is more or less a consequence of how WHFB works: the ability to perform single-sign on with the backing cryptographic keys from a user session, without needing the PIN or other information/user presence. We will not just look at how we can utilize this to request Primary Refresh Tokens (PRTs), but also how we can use this to perform device registration by using the WHFB key as...

Bypassing Conditional Access policies that have a resource exclusion

12 minute read

There is a documented enforcement gap in Conditional Access policies that apply to “all resources” but have an exclusion for at least one resource. What is not documented, is that this gap is much larger than what one would expect, and that the documented mitigation doesn’t actually work. The good news if you are an Entra admin is that this is now considered legacy behaviour that Microsoft is changing and that if your tenant isn’t automatically migrated yet you can opt-in to the new behaviour which addresses and fixes this issue. If you have a policy with a resource exclusion, I would highly recommend applying this change.

One Token to rule them all - obtaining Global Admin in every Entra ID tenant via Actor tokens

17 minute read

While preparing for my Black Hat and DEF CON talks in July of this year, I found the most impactful Entra ID vulnerability that I will probably ever find. One that could have allowed me to compromise every Entra ID tenant in the world (except probably those in national cloud deployments). If you are an Entra ID admin reading this, yes that means complete access to your tenant. The vulnerability consisted of two components: undocumented impersonation tokens that Microsoft uses in their backend for service-to-service (S2S) communication, called “Actor tokens”, and a critical vulnerability in the (legacy) Azure AD Graph API that did not properly validate the originating tenant, allowing these tokens to be used for cross-tenant access.

Extending AD CS attack surface to the cloud with Intune certificates

18 minute read

Active Directory Certificate Services (AD CS) attack surface is pretty well explored in Active Directory itself, with *checks notes* already 16 “ESC” attacks being publicly described. Hybrid certificate attack paths have not gained that much attention yet, though I have come across several hybrid integrations while reviewing cloud configurations. In these setups, certificates are rolled out to cloud-managed endpoints via Microsoft Intune and the Intune certificate connector. The certificate connector runs in on-premises AD and requests the certificates on AD CS via the SCEP or PKCS integrations. In such environments, it would be possible to request certificates with arbitrary subjects as an Intune administrator. What I have also observed in some cases are certificate configurations in Intune being misconfigured in a way that would allow regular users to perform the same attack and effectively perform ESC1 over Intune certificates. That means going from regular user and their endpoint to Domain...

Persisting on Entra ID applications and User Managed Identities with Federated Credentials

7 minute read

Using applications and service principals for persistence and privilege escalation is a well-known topic in Entra ID (Azure AD). I’ve written about these kind of attacks many years ago, and talked about how we can use certificates and application passwords to authenticate as applications and abuse the permissions they have. In this blog, we cover a third way of authenticating as an application: using federated credentials. Federated credentials have been around for a few years, but haven’t been covered much yet from the offensive side. For Entra ID applications, there is no large difference between configuring federated credentials or regular client secrets/certificates. The more interesting part on this topic is that we can also configure federated credentials on User Managed Identities in Azure. This is unusual, because normally Managed Identities have their authentication controlled by Microsoft, and their authentication is tied to a certain resource such as a Virtual Machine....