I recently followed a live session of Dirk-Jan Mollema and Ceri Coburn on how Windows Hello for Business can be abused as a non-privileged user. I was very intrigued by the concept of the attack they demonstrated, which is why a spend a couple of days thinking of ways how we can counter this attack with detective controls as blue teamers.

In the past couple of weeks, I worked on a project where I needed to provide access to a securely private integrated Azure Storage Account via the Entra ID Private access profile. During this project I encountered a very interesting bug, that made me better understand the insights of how Global Secure Access works.

I am thrilled to participate in the Cyber Back to School initiative hosted during cyber awareness month! This session is all about Primary Refresh Token VS Access Token stealing in Microsoft Entra ID, and will show the practical countermeasures for each of them. I preferred to write a blog post for this instead of a PowerPoint deck since there are a lot of technical details and references I want to cover.

The process is quite similar to the client secret flow described here, so be sure to take a look! The challenge here lies in generating a JWT (JSON Web Token) based on a certificate. I will provide a detailed explanation of how the JWT is generated and exchanged for an access token below.

The next authentication flow in my series will be the Client Credentials Flow. Be sure to check out the first one here! We will first take a look at the client secret model. I will skip the basics in this article as this has been explained in my other article.

In April 2024, MITRE came with their new V15 version of ATT&CK. In this version a new sub-technique was introduced called 'T1556.009 - Modify Authentication Process: Conditional Access Policies'. This was, in my opinion, a great addition to the framework, since it is an important technique which can be abused by adversaries. By changing a Conditional Access policy (later referred to as 'CA policy'), an adversary can establish Credential Access, Defense Evasion, and Persistence in Entra ID. Since it is such a vital component, I thought it was time to do a bit of a deep dive into how we can detect and mitigate suspicious CA policy changes.

In the past, I was always curious about the workings of Connect-AzAccount, the authentication command from the Az.Accounts PowerShell module. This led me to delve into debugging, and the subsequent article is a product of that exploration. It's intriguing that both Az CLI and Az PowerShell are operational across all tenants, even the newly created ones. I aimed to emulate this functionality in PowerShell and utilize it in my scripts. For instance, this could be beneficial when executing commands across various tenants, a task that the Az modules are not adept at handling.

In a previous blog post I talked about how adversaries can exploit SSO capabilities of Hybrid or fully Entra ID joined devices. I mentioned the different ways we can steal tokens from the devices, either by using BrowserCore.exe or MicrosoftAccountTokenProvider.dll.

Adversaries are more and more interested in the data and infrastructure that lives in Cloud environments like Azure and Microsoft 365 solutions. Since Microsoft EntraID is the most common central IDP solution for these environments, it is important to identify the possible paths attackers can use to move from a device to possible crown jewels that live in these Cloud solutions. In this blog post, I wanted to talk about how adversaries can use Entra ID Joined or Hybrid Joined devices to move laterally to the cloud, using EntraID SSO features, and how they can get a foothold on these devices. This blog post is based on a Red-Teaming scenario I encountered in a real-life, and is written from a Blue-Teaming perspective.

How does Data Collection rule and transformations work?