The Microsoft Sentinel SOAR playbook generator has mostly flown under the radar since it entered public preview, so let’s look at what it can do and whether it can replace Logic Apps with something more native. In SecOps conversations, I often hear the same view: Logic Apps are fine, but if you already script or code, they can feel like overhead rather than a productivity boost. Many MSSPs also rely on more flexible tooling such as Azure Functions or compiled code for incident automation.
The new Sentinel playbook generator feels more native for Defender XDR and Sentinel integration, and it adds AI on top. Let’s see whether that actually helps.
Playbook Generator in Action # You can find the playbook generator in the Unified Security Operations Platform (USOP) under the Sentinel automation blade, via the ‘Playbook Generator ✨’ option.
It opens a Visual Studio Code or GitHub Codespaces-style editor with Cline preinstalled for building Python playbooks.
Creating a playbook with natural language is straightforward. Cline uses a plan-and-act flow: you describe what you want, then it tests and builds the playbook.
For my initial tests, I used the following prompt:
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.
Recently I observed an interesting behavior after setting up a Microsoft Booking page. After creating the booking page, I suddenly got an e-mail to an automatically created mail alias with the same name as the booking page. This made me curious and I wanted to understand the behavior behind this, and if this could be abused by attackers to impersonate users in Exchange online. In this blog post, I want to share my findings and some tips on how to detect and prevent this kind of abuse in your environment.
Microsoft Booking # Microsoft describes the Bookings capabilities as part of Microsoft 365:
“A simpler way to organize schedules and manage appointments.”
Booking pages can be either of type ‘personal’ or ‘shared’:
Personal booking pages provide a handy option for users to create their own booking page, which is automatically linked to their calendar and allows others to book appointments with them. This is a great feature for users who want to share their availability and allow others to easily schedule meetings.
The shared booking pages allow teams to provide a booking experience for services hosted by a team and come with a special mailbox and calendar.
With the Unified Security Operations Platform (USOP), Microsoft introduces Unified Detections - a single detection framework spanning both Sentinel and Defender XDR data. Pair this with native Sentinel Data Lake ingestion for XDR tables, and you have a compelling cost-optimization story. But is it ready for prime time? Let’s dive into the capabilities, current limitations, and what it means for your detection strategy.
Architecture Overview # Previous Detection Architecture # In the ‘previous’ architecture, detections were created and managed separately for Microsoft Sentinel and Microsoft Defender XDR. This often led to overhead in terms of ‘where to create the detection’. Let’s take the use-case of IoC (Indicators of Compromise) based detections. Previously, if a security team wanted to create a detection based on IoCs imported via TAXII into Sentinel and the DeviceNetworkEvents table, they would need to ingest the DeviceNetworkEvents data into Sentinel as well and create the detection rule there. Furthermore, many MSSPs leveraged this pattern to create custom detections for their customers across Defender Advanced Hunting Data.
As part of the USOP onboarding, the following effects come into play, marked with an asterisk above:
At this year’s YellowHat conference in Almere, the Dutch security community had the chance to participate in a Capture The Flag (CTF) competition organized by one of the conference sponsors - Blu Raven. Mehmet from Blu Raven did a great job setting up a CTF with realistic scenarios and datasets, which made it a lot of fun to solve the challenges.
Foreword # Being a big fan of CTFs and digital forensics and incident response (DFIR) in general, I couldn’t resist the temptation to participate. After numerous attempts to solve the first challenge and an enlightening tip from a colleague, I made some progress and solved the first 12 challenges.
To avoid running out of time, I decided to try something unconventional for the remaining challenges - I used AI to help me solve them. Professor Smoke aka Henning Rauch teased the new Microsoft Fabric Real-Time Intelligence (RTI) capabilities during his talk at YellowHat1, so I thought this would be a great opportunity to test these out in a real-world scenario. Little did I know that the outcome would be surprising!
Preconditions # Azure Data Explorer # Because the CTF data was stored in an Azure Data Explorer (ADX) cluster, the prerequisite for using the Fabric RTI MCP server was already met, because we can query data in Eventhouse and ADX. Besides that I had already set up GitHub Copilot within Visual Studio Code in agent mode from previous AI ramblings.
Did you know that the maester framework now supports Microsoft Intune checks? In this blog post, I’ll give you a quick overview of the new capabilities and how to get started.
About Maester # Maester is an open-source security assessment framework that helps you evaluate the security posture of your Microsoft Entra ID and Microsoft 365 environments. It provides a collection of tests that can be run against your tenant to identify potential misconfigurations and security risks.
After executing the tests, maester generates a detailed report that highlights the findings and provides recommendations for remediation:
Intune Related Checks # The great thing about maester is that it’s highly extensible, allowing you to add custom tests and checks based on your specific requirements. To share some Intune best practices with the community, I contributed a set of Intune related checks to the maester framework.
The following Intune checks are now available in maester:
MT.1090 - Global administrator role should not be added as local administrator on the device during Microsoft Entra join MT.1091 - Registering user should not be added as local administrator on the device during Microsoft Entra join MT.1092 - Intune APNS certificate should be valid for more than 30 days MT.1093 - Apple Automated Device Enrollment Tokens should be valid for more than 30 days MT.1094 - Apple Volume Purchase Program Tokens should be valid for more than 30 days MT.1095 - Android Enterprise account connection should be healthy MT.1096 - Ensure at least one Intune Multi Admin Approval policy is configured MT.1097 - Ensure all Intune Certificate Connectors are healthy and running supported versions MT.1098 - Mobile Threat Defense Connectors should be healthy MT.1099 - Windows Diagnostic Data Processing should be enabled MT.1100 - Intune Diagnostic Settings should include Audit Logs MT.1101 - Default Branding Profile should be customized MT.1102 - Windows Feature Update Policy Settings should not reference end of support builds MT.1103 - Ensure Intune RBAC groups are protected by Restricted Management Administrative Units or Role Assignable groups MT.1105 - Ensure MDM Authority is set to Intune Example # To run the tests you can simply run:
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: