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.
When designing IaC modules finding the correct syntax to deploy a certain resource type is often not the hardest thing to do. What I found in 3 years of writing Bicep code, is that defining a dynamic way to name your resources which is also easy to use, seems to pose quite the challenge. This article won't define the best way to get this but a way that seems to work for me and the customers I have worked with in the past.
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.
