ITDR

All too often, my baseVISION (IR) colleagues and I find compromised cloud accounts where many security ‘signals’ were missed—both from a prevention and detection perspective. In this blog post, I want to share some motivation and tips to help you adopt Entra ID Protection risk-based Conditional Access policies to increase your tenant’s security posture, and ensure you don’t miss the next obvious account breach. Real-world motivation # Anyone who has seen an AiTM campaign in the wild will probably notice the following details from the Entra ID sign-in logs of a compromised account: ResourceDisplayName: OfficeHome UserAgent: axios/1.13.2 The problem? Even though Entra ID Protection flagged the sign-in as ‘High’ risk, the user could still sign in because MFA automatically remediated the sign-in risk (userPassedMfaDrivenByRiskBasedPolicy). The bummer? # The environment had a Conditional Access policy in place that would have blocked users with high sign-in risk, but the policy was only in report-only mode, so the user could sign in without any issues.

In May I had the pleasure to be invited to the KQL Café which is hosted by Gianni Castaldi & Alex Verboon. Within this format they empower people to work with KQL and share various tips and tricks. So this is not a usual blogpost but rather a summary and resource hub for the things I presented within the KQL Café. Summary # To make the content of my talk more accessible, you can find a summary of the individual topics, including the leveraged KQL queries and further resources as part of this post. The KQL queries were mostly consuming the Entra ID Sign-In and Audit Logs. You can forward them to your Microsoft Sentinel or Log Analytics workspace. Recording # You can find the full recording of the KQL Café on YoutTube. What the heck is ITDR?! # Identity Threat Detection and Response (ITDR) is currently one of my favourite topics. It’s basically a combination of the disciplines Identity and Access Management (IAM) and the cyber security disciplines detection and response. Similar to other cybersecurity topics there’s a rule of thumb: The more you invest on the preventive side to increase your identity security posture — the less effort you (hopefully) have on the detection and response side 🤞🤞. Within my talk for the KQL Café I addressed various of those ITDR topics that help you on the preventive side.

Recently I stumbled over a nice post from Wesly Neelen who built an AiTM phishing toolkit based on a cloudflare worker. Although ‘prooven’ AitM phishing toolkits such as evilginx provide more capabilities in terms of flexibility and robustness I wanted to setup my own phishing toolkit that runs serverless on Azure — based on Azure Functions to phish some Entra ID credentials and cookies. Advantages of serverless phishing toolkits # Serverless platform solutions such as Cloudflare workers, AWS lambda and Azure functions provide some advantages to phishing toolkits that are server-based: No Infrastructure as a Service (IaaS) resources like virtual machines and public IP addresses are required, this allows faster deployments, easier scaling and comes with low costs Serverless platforms often have pooled outbound IP addresses that are dynamically assigned by the cloud provider No DNS domain name or name server entries are required as the cloud provider assigns URLs to the serverless functions As the domain names, IP addresses and certificates are issued and managed by the cloud provider, this goes usually hand-in-hand with better reputation Let’s do AiTM Phishing with Azure Functions # Demo # The following demo provides a quick overview about the Azure AiTM Function and the replay of the cookies in an incognito browser window:

With the availability of passkeys the FIDO2 standards become more accessible in the form of password managers, web-browsers and (mobile) operating systems — without the need for dedicated hardware such as FIDO2 keys. Microsoft is currently in the process of developing support for passkeys and shipping the public preview in Q1 2024: While this is a very welcome addition to make passwordless authentication easily accessible without dedicated hardware such as FIDO2 security keys this also introduces new risks, especially for high value accounts — But why’s that? Let’s imagine a fictive scenario (that might become reality in the future) of a user registering a passkey with his password manager app for a Microsoft Entra account. The security of this passkey is now determined by the security measures on the password manager app. For the Microsoft roadmap this scenario is not (yet) applicable as Entra will only support device-bound passkeys. At the end of the day it is a similar situation as the security of the passkey depends on the device with the authenticator (passkey) on it and that’s not necessarily under the umbrella of IT security measures. Fortunately there is hope and the FIDO alliance included that critical aspect of distinguishing authenticators in their standards as we’ll find out below.

Microsoft 365 Defender and Sentinel provide an IdentityInfo table that contains various information that is helpful for threat hunting and detections. One key piece are also the assigned Entra directory roles for a specific identity. Unfortunately only permanently assigned permissions are covered and in times of Entra Privileged Identity Management (PIM) we should have standing permissions only for non-privileged roles and break-glass accounts. Within this blog post I want to share a few tips and tricks to answer the following questions with Sentinel and a little bit of scripting and KQL: How can we enrich the IdentityInfo table to include eligible assigned directory roles? Which synchronized user accounts have permanent or eligible directory roles assigned? (Spoiler: this should be avoided at all cost) Were eligible directory role assignments not used within the last couple of days and can therefore be removed? As a bonus I also prepared an analytics rule for mass unassignment of highly privileged Entra roles, as this tactic was used for example by the LAPSUS$ group. Gathering PIM eligible Entra Directory Roles # As the IdentityInfo and other available built-in data sources do not include eligible role assignments we need a way to gather the existing role assignments. Fortunately, we can query the following Microsoft Graph endpoint to get the eligible permission assignments:

Microsoft Sentinel Analytic Rules can be shared in both the YAML and ARM format, whereas the ARM format leverages JSON as file type. Within… Microsoft Sentinel Analytic Rules can be shared in both the YAML and ARM format, whereas the ARM format leverages JSON as file type. Within this short post I want to demonstrate an approach that leverages a GitHub Action to automatically build and update the rules in YAML format — so you can just export and update existing rules without any manual conversion effort. Fabian Bader built a cool solution called SentinelARConverter that allows conversion of exported Sentinel Analctic rules from ARM/JSON to YAML (and vice-versa). To emphasize sharing of analytic rules I wanted to adopt also the YAML format without the need to always manually convert the rules. Therefore I incorporated his solution into a GitHub Action. Building a GitHub Action # The automation of this task is fairly simple if you are already familiar with GitHub actions. In case you want to directly see the full pipeline, you can find it here. Otherwise keep on reading. The GitHub action should be triggered as soon as I upload a new Export of an Analytics Rule to the repository. For that, we need to define a folder structure. I maintain the rules within a folder called AnalyticRules. Based on that we can define the triggers for the workflow and filter only for the analytic rules path. This will only run the Action, when a file within that folder get’s changed. Additionally, I added a workflow_dispatch trigger, this allows manual execution of the pipeline.

Microsoft recently made the Microsoft Graph Activity Logs available as part of the Microsoft Entra ID diagnostic settings. This means we can use the MicrosoftGraphActivityLogs Table to enrich custom detections and analytic rules. Within this post I want to elaborate closer on an attack scenario for workload identities that leverage workload identity federation and don’t have any persistent credentials or long lived secrets. But one type of credential artefacts is still theft-able — the short lived access tokens. Adversaries can try to exfiltrate the access token from the CI/CD environment such as a GitHub action and replay the token within another system to access Entra ID protected resources. This tactic could also be used in scenarios with App Registrations that leverage certificates or clients secrets where adversaries don’t have access to the credentials but get possession of the access token due to exposure in cleartext such as in log files or decrypted TLS traffic. Stealing and replaying workload identity access tokens # To demonstrate a scenario to steal and replay an access token of a workload identity, I prepared a demo scenario with a GitHub action that acquires access tokens for the Microsoft Graph API and the Azure Resource Manager API. The pipeline leverages federated credentials (also referred to as workload identity federation).