KQL on Nicola Suter

Enhanced Filtering for Connectors: SPF failures in Defender for Office 365

Thu, 04 Jun 2026 08:15:02 +0000

Enhanced Filtering for Connectors¹ (aka skip listing) lets Exchange Online and Defender for Office 365 see the actual sender IP address instead of only the last hop. This is required so that MDO can verify message authentication attributes such as SPF, DMARC, and DKIM. Microsoft recommends it in its guides for third party mail flows² ³ to get the full value out of MDO.

Without enhanced filtering, MDO only sees your 3rd party gateway as the sender for incoming e-mails. As a result, you lose important sender metadata, which degrades your experience in Threat Explorer, Advanced Hunting, and the Tenant Allow/Block List.

The mail flow in the environment roughly looks like this, with the 3rd party gateway acting as the MX for inbound mail and as the smart host for outbound mail. Exchange Online is connected to an on-premises Exchange server via the hybrid connector:

flowchart LR
 Internet([Internet])
 Gateway[3rd Party
Mail Gateway
MX record]
 EXO[Exchange Online
Defender for Office 365]
 OnPrem[On-Premises
Exchange Server]

 %% Inbound flow
 Internet --> Gateway
 Gateway -- "Partner connector
+ Enhanced Filtering" --> EXO
 EXO -- "Hybrid connector" --> OnPrem

 %% Outbound flow
 OnPrem -. "Hybrid connector
+ Enhanced Filtering" .-> EXO
 EXO -. "Partner connector" .-> Gateway
 Gateway .-> Internet

 classDef cloud fill:#e6f2ff,stroke:#0078d4,color:#000
 classDef onprem fill:#fff4e6,stroke:#d97706,color:#000
 classDef gw fill:#f3e8ff,stroke:#7c3aed,color:#000
 class EXO cloud
 class OnPrem onprem
 class Gateway gw

Following the Microsoft recommendation, enhanced filtering was enabled on both the 3rd party connector and the Exchange hybrid connectors.

Chasing Entra re-authentication prompts

Mon, 01 Jun 2026 15:37:02 +0000

While troubleshooting unexpected re-authentication prompts in Entra ID, I stumbled over a legacy setting I had almost forgotten existed. The environment was piloting a new set of Conditional Access policies, and some pilot users received daily re-authentication prompts in Microsoft 365 apps, although no Conditional Access policy was forcing this.

Entra ID Protection was the first suspect, but no risk detections were present for the affected users. The actual reason was hiding in plain sight in the Entra sign-in logs, in the SessionLifetimePolicies field.

Inspecting SessionLifetimePolicies
#

A quick KQL query against SigninLogs reveals every distinct expirationRequirement reason observed in the tenant:

Distinct expirationRequirement reasons surfaced from SigninLogs

SigninLogs
| mv-expand parse_json(SessionLifetimePolicies)
| extend ExpirationRequirement = tostring(SessionLifetimePolicies.expirationRequirement)
| extend ExpirationDetail = tostring(SessionLifetimePolicies.detail)
| distinct ExpirationRequirement, ExpirationDetail

The sessionLifetimePolicy resource is also documented as part of the Microsoft Graph API¹.

Legacy MFA settings
#

The rememberMultifactorAuthenticationOnTrustedDevices value stood out and reminded me of the Azure AD days and the legacy MFA settings. Sure enough, the Remember multi-factor authentication on trusted devices setting was still enabled:

Detecting Intune device compliance drift with KQL

Tue, 26 May 2026 16:26:02 +0000

Why are my Intune devices no longer compliant? Rolling out new compliance policies, raising minimum OS versions, or adjusting other controls can all cause devices to drift out of compliance. Ultimately, this impacts resource access whenever Conditional Access enforces a compliant device.

If you forward the IntuneOperationalLogs to a Log Analytics workspace¹, you can query, parse, and alert on non-compliance events with just a few lines of KQL:

Anonymized example of noncompliant devices

IntuneOperationalLogs 
| where OperationName == "Compliance"
| extend Properties = parse_json(Properties)
| evaluate bag_unpack(Properties)
| where AlertType == @"Managed Device Not Compliant"
| extend UserPrincipalName = iif(UserDisplayName != "System account", strcat(UserName, '@', UPNSuffix), "System account")
// Extract the reason
| extend ReasonRaw = tostring(split(Description, '||')[0])
// Parse the compliance Policy ID
| parse ReasonRaw with ReasonParsed:string "_IID_" PolicyIdRaw:string
| extend Reason = coalesce(ReasonParsed, ReasonRaw)
| extend PolicyId = coalesce(PolicyIdRaw, 'DefaultDeviceCompliancePolicy')
| project-away *Raw
| project-reorder TimeGenerated, UserPrincipalName, DeviceHostName, IntuneDeviceId ,Reason, PolicyId

Note

The Properties column is a serialized JSON string that holds all the non-compliance details. The bag_unpack plugin² expands every property in the bag into its own column, which keeps the rest of the query much simpler.

Microsoft Authenticator App Details now exposed in Entra SignInLogs

Wed, 20 May 2026 12:00:01 +0000

In response to CVE-2026-41615¹ (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:

AI just solved a CTF for me!

Fri, 16 Jan 2026 21:00:03 +0000

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 YellowHat¹, 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.

Mai 2024 KQL Café Recap

Mon, 01 Jul 2024 20:07:46 +0000

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.

AiTM Phishing with Azure Functions

Mon, 01 Apr 2024 18:23:49 +0000

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:

KQL on Nicola Suter

Enhanced Filtering for Connectors: SPF failures in Defender for Office 365

Chasing Entra re-authentication prompts

Inspecting SessionLifetimePolicies #

Legacy MFA settings #

Detecting Intune device compliance drift with KQL

Microsoft Authenticator App Details now exposed in Entra SignInLogs

AI just solved a CTF for me!

Foreword #

Preconditions #

Azure Data Explorer #

Mai 2024 KQL Café Recap

Summary #

Recording #

What the heck is ITDR?! #

AiTM Phishing with Azure Functions

Advantages of serverless phishing toolkits #

Let’s do AiTM Phishing with Azure Functions #

Demo #

Inspecting SessionLifetimePolicies
#

Legacy MFA settings
#

Foreword
#

Preconditions
#

Azure Data Explorer
#

Summary
#

Recording
#

What the heck is ITDR?!
#

Advantages of serverless phishing toolkits
#

Let’s do AiTM Phishing with Azure Functions
#

Demo
#