Posts

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).

Microsoft Entra Connect Sync (aka Azure AD Connect) allows establishing hybrid identity scenarios by interconnecting on-premises Active Directory and Entra ID (aka Azure AD) and leveraging synchronisation features in both directions. As you might already know, this brings potential for abuse of the assigned permissions to the involved service accounts and permissions of this service. On the internet are already some posts with subset of this information but I wanted to provide an actionable post with individual measures to implement. Of course should we do MFA for all admins and AD tiering but some of those steps involve more complex measures to implement and I will try to provide some individual building blocks you can use to harden the configuration of your Entra Connect service accounts. Understanding the scope # To understand the scope of hardening we need to have an overview of the inner workings of that service. Entra Connect uses three different kind of service accounts for the different systems: Entra: For the connected Entra tenant, per each Entra Connect installation a cloud only account is created by the wizard: [email protected] Active Directory: The active directory account is used to connect a forest and allows both reading and depending on the leveraged synchronisation options also modifying the objects for password reset or group write-back scenarios Synchronisation Service: Under this principal, the actual Entra Connect service is running on the server Each kind of service account has various interesting privileges that can be abused by attackers. While the security of the server running Entra connect is also an important aspect I want to focus more on the leveraged user accounts as they are subject to multiple well-known attack scenarios.

Microsoft Entra Workload Identity Federation is a hidden gem when dealing with app registrations and service principals because it will significantly improve the security posture of your workload identities. While I already blogged about the more technical and implementation specific details in my GitHub Actions with Entra Workload Identity Federation post, I want to highlight the benefits and scenarios where you can use Workload Identity Federation to access Entra ID protected resources. Quick recap on Workload Identities # Should you read this post and wonder what a Workload Identity is, here a quick recap: A workload identity (can be either a managed identity or service principal) is used to access resources protected by Entra ID (Azure AD) from a service or automation A service principal is an instance of an app registration. To leverage a service principal authentication with either a client secret, certificate, or federated credential is required. A managed identity is a Microsoft managed identity of a resource such as a Logic App, Automation Account or VM. Microsoft manages the credentials of those managed identities. This allows for secure access as the credentials are not exposed to other services. Managed Identity is the recommended type for workload identities for workloads that live in the Microsoft Azure ecosystem. For services and automations outside of Azure, service principals (app registrations) are the only option. The usage and credential configuration is unfortunately not a simple process.

Did you know that for the new Windows LAPS Azure AD is also maintaining the password history? The built in PowerShell commandlet relies on the Microsoft Graph PowerShell SDK and within this post I want to show you how to work with the Get-LapsAADPassword cmdlet. Kudos to Niklas Tinner as he brought this to my attention while working together. Where is this command originating from? # The Get-LapsAADPassword cmdlet is part of the LAPS PowerShell module that was baked into the Windows Operating system with the April 2023 quality updates. The module is maintained as part of the Operating System and builds the Interface to interact with Windows LAPS locally on a device. The module binaries reside within C:\Windows\system32\WindowsPowerShell\v1.0\Modules\LAPS and consist of DLLs and PowerShell files: Let’s retrieve some passwords # Before we can start retrieving passwords we need to make sure, that we have the appropriate Microsoft Graph PowerShell SDK module present. We can easily check this with the following PowerShell command: Get-Module -Name Microsoft.Graph -ListAvailable If you do not retrieve any output, you need to install the module with local Administrator privileges with:

Loooooong awaited and it’s finally here - the new Windows LAPS. With the previous announcement(s) of the integration into the native Windows operating system and support for Azure AD join this was a long-awaited feature. With the recent patch Tuesday the binaries were backed and delivered natively into the current Windows client and Server OS and today they also launched the Azure AD backend that can serve as the backup source for passwords. Within this post, I want to give you a quick impression of what the deployment experience currently looks like and where I needed some adjustments to get the expected result. Setup # Prerequisites # To deploy LAPS with Azure AD password backup and Intune you need licenses/access to those tools and Windows 10/11 devices with the latest April patches installed. A full list of prerequisites is provided by Microsoft here. Azure AD enablement # Unlike the on-premises AD LAPS enablement we do not need any schema extensions and can simply enable the following toggle within our Azure AD device settings:

Microsoft Defender for Identity (MDI) has announced a new capability back in February to detect suspicious certificate usage for Kerberos authentication. It is already well-known, that Active Directory Certificate Services (ADCS) is a lucrative target for adversaries to achieve persistence in Active Directory as ADCS can be easily misconfigured resulting in an easy way to exploit those misconfigurations. In this post I want to show you how easy those misconfigurations can be abused and how and when such an attempt is detected by Microsoft Defender for Identity new detection capabilities for suspicious certificate usage. What makes a vulnerable environment # To be vulnerable for the certificate abuse scenario I will demonstrate an environment needs to have the following conditions present: ADCS Enterprise Certification Authority (CA) CA certificate must be present in NTAuth store (default behaviour when an enterprise ADCS CA is installed) At least one domain controller needs to have a kerberos authentication certificate enrolled At least one vulnerable certificate template that meets one of the following criteria’s: – “specify subject name in the request” flag enabled AND granting enroll permissions to low privileged principals like domain users or domain computers (or equivalent) – grants modify permissions to low privileged principals like domain users or computers (or equivalent) The first three conditions are usually present in a standard Active Directory deployment and provide key functionality for other services. Certificate templates are also a standard thing, but there it really comes down to the (mis)configuration and hardening. Specterops documents those very well and provides tools to check for potential misconfigurations¹.

Intune Endpoint Security Configuration Settings have become the way to go for configuring security features on various platforms. What did start with Microsoft Defender for Endpoint settings for Windows clients has evolved to settings for macOS, Windows Servers and is treated like a first class citizen. So it is important to guard those sensitive configurations as they control (and can potentially disable) vital security features on endpoints such as defender tamper protection, attack surface reduction rules, firewall and many more. Within this post I want to show you an approach to monitor changes to Intune Endpoint security settings with Microsoft Sentinel and watchlists that can be easily customised based on your environment and needs. My main idea is to classify the sensitive configurations in the environment and only creating incidents for those. Of course you could alert on every Intune configuration change but for most of the environments this would lead to many alerts without providing value. Prerequisites # Changes to the Intune Endpoint security settings area are visible like other changes within the Intune Audit Logs. To have the audit events within our Sentinel workspace we need to enable the forwarding for at least AuditLogs. This can be done within the Intune Tenant Administration > Diagnostic Settings blade.

We all have probably been there and developed a PowerShell script that took some fair amount of time until the execution completed, weren’t we? Of course one could argue and say that as long a script ‘works’ it is good enough but depending on the use case and environment a PowerShell script that runs 30 to 60 minutes exceeds the patience of most (IT) people and can also lead to increased costs. But what makes those kinds of scripts that awfully slow and can’t we just tweak them to run faster? The following examples and script will be related to PowerShell and the Microsoft Graph API but the mentioned approaches can be adapted for any kind of RESTful API and scripting language. For all interactions with the Graph API I use the Microsoft Graph PowerShell SDK which is available as a PowerShell module from the PowerShell gallery. Reasons why your script is slow # I would say I have already read and (tried to) understand hundreds of PowerShell scripts out there and I often notice the following flaws which lead to poor performance: Slow algorithms and wrong data structures # Slow algorithms are extricably linked to the understanding of data structures when it comes to PowerShell scripting. Here the top two cases I often observe: