Hi, I'm Nicola 👋

In response to CVE-2026-416151 (Microsoft Authenticator Information Disclosure Vulnerability), Microsoft started exposing the used Microsoft Authenticator app details as part of the Entra ID Sign-In Logs in the AuthenticationAppDeviceDetails column. The information can be queried via KQL. Vulnerable builds include versions prior to 6.2605.2973 (Android) and 6.8.47 (iOS), which have been patched. You can use the below KQL query to find users with outdated Microsoft Authenticator app versions, which are vulnerable: // https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41615 let MinimumVersions = datatable( AuthenticatorOperatingSystem: string, PatchedAuthenticatorVersion: string )[ "Android", "6.2605.2973", "Ios", "6.8.47" ]; SigninLogs | where isnotempty(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails) | extend AuthenticatorOperatingSystem = tostring(AuthenticationAppDetails.operatingSystem) | extend UsedAuthenticatorVersion = tostring(AuthenticationAppDetails.appVersion) // b2b and guest accounts include: {"deviceId":"{PII Removed}"} and no authenticator details | where isnotempty(UsedAuthenticatorVersion) | join kind=leftouter MinimumVersions on AuthenticatorOperatingSystem | extend isVulnerable = parse_version(UsedAuthenticatorVersion) < parse_version(PatchedAuthenticatorVersion) | where isVulnerable | distinct UserPrincipalName, AuthenticatorOperatingSystem, UsedAuthenticatorVersion, isVulnerable The AuthenticationAppDeviceDetails (JSON) column itself consists of the following properties: appVersion clientApp deviceId operatingSystem The clientApp property is really helpful, as we now also have another option to identify users who use the Authenticator light capabilities, available as part of the Outlook app: SigninLogs | where isnotempty(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetailsClientApp = tostring(AuthenticationAppDetails.clientApp) | where AuthenticationAppDetailsClientApp == "Outlook" | distinct UserPrincipalName, AuthenticationAppDetailsClientApp This might be relevant in your environment if you did not disable the Microsoft-managed setting for using the Authenticator light option, which, for example, does not support Conditional Access authentication strengths, passkeys, and app protection policies:

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: