I know this is well known to seasoned detection engineers, and you'll likely have detection rules that actively monitor these events, but I was just auditing some older detection logic in a client environment and realised their primary credential-dumping alert was still looking for FileName == "lsass.exe" inside DeviceProcessEvents.

If you're doing this, an adversary just has to rename their tool to svchost.exe or update.exe, and you are completely blind. DeviceProcessEvents is for process creation, not for process access.

To reliably detect this without generating massive false-positive fatigue from legitimate system noise, you need to query DeviceEvents, filter for OpenProcessApiCall, and explicitly parse the target image from the JSON fields to check the specific access masks.

Here is the clean KQL block that works well in production and looks for 0x1010 (query/read) and 0x1438 (common tool default):

DeviceEvents | where TimeGenerated > ago(1d) | where ActionType == "OpenProcessApiCall" | extend TargetProcess = tostring(AdditionalFields.TargetImageFile) | extend GrantedAccess = tostring(AdditionalFields.GrantedAccess) | where TargetProcess =~ "lsass.exe" | where GrantedAccess in ("0x1010", "0x1410", "0x1438", "0x143a", "0x1f0fff") | where not (InitiatingProcessFolderPath startswith @"c:\windows\system32\" or InitiatingProcessFolderPath startswith @"c:\program files\") | project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, TargetProcess, GrantedAccess 

Found a couple of weird administrative edge cases with legitimate monitoring agents tripping this in a tight loop, so you'll definitely want to tune the folder path exclusions based on whatever endpoint agents your org uses.

Run in your environment to test variants of specific techniques and see what the telemetry looks like.

Curious if anyone else has run into specific bypasses of 0x1010 filtering when attackers manipulate handle rights directly?

The attacker doesn't steal a password. They trick the user into granting permissions to a malicious application. "Sign in with Microsoft" — the user clicks approve, and now the attacker's app has a refresh token with persistent access to their mail, files, and calendar until revoked.

No password compromised. MFA was satisfied by the legitimate user. Conditional Access passed because the user authenticated normally. The malicious action happens at the consent layer — above authentication — where none of these controls apply.

The app now reads mail via Graph API. No interactive sign-in anomalies. No anomalous location. The non-interactive and service principal sign-in logs show token activity, but most SOCs never scrutinise them — and even when they do, the API calls are structurally identical to legitimate application behaviour.

Default M365 detections don't catch this reliably. Microsoft has added some — Defender for Cloud Apps flags unusual OAuth credential additions and suspicious mail access — but they're inconsistent, often delayed, and miss consent grants to newly registered external apps without a risk profile.

You need to monitor application consent grants in Entra ID audit logs ("Consent to application" under ApplicationManagement) and alert on any app requesting Mail.Read, Files.ReadWrite, User.Read.All, or offline_access from a non-approved publisher. Better still, disable user consent entirely in Entra ID and enforce an admin consent workflow — shifting the attack surface from "any user can be phished" to "only admins can approve apps."

This is the gap between "we have MFA" and "we have security."

Sharing a detection I built after investigating multiple AiTM compromises. The default Sentinel "suspicious inbox manipulation" template is noisy, and most environments disable it. Here's what I run instead:

High-fidelity query (external forwarding + financial keywords):

OfficeActivity | where TimeGenerated > ago(30d) | where Operation in ("New-InboxRule", "Set-InboxRule") | where Parameters has_any ("ForwardTo", "RedirectTo", "DeleteMessage", "MoveToFolder") | extend RuleDetails = tostring(Parameters) | where RuleDetails has_any ( "gmail", "protonmail", "outlook.com", "yahoo", "tutanota", "pm.me", "RSS Subscriptions", "Conversation History", "invoice", "payment", "wire", "security", "password", "MFA") | project TimeGenerated, UserId, Operation, RuleDetails, ClientIP | sort by TimeGenerated desc 

Broad audit query (all rule operations for manual review):

OfficeActivity | where TimeGenerated > ago(30d) | where Operation in ("New-InboxRule", "Set-InboxRule") | project TimeGenerated, UserId, Operation, Parameters, ClientIP | sort by TimeGenerated desc 

What I look for in results:

• ForwardTo or RedirectTo pointing to any external domain
• MoveToFolder targeting RSS Subscriptions, Conversation History, or Junk
• DeleteMessage with keyword filters on "security", "password", "sign-in", "MFA"
• Rule names that are blank, single character, or "..."
• ClientIP outside your corporate range (strongest single indicator)

Tuning notes from production:

The high-fidelity query fires maybe 1-2 times per month in a ~800-user environment. Most hits are legitimate (someone forwarding to a personal backup). The false-positive check: correlate the ClientIP with SigninLogs — if the same IP has a risky sign-in for the same user within the preceding 24 hours, it's a true positive.

The broad query returns 10-30 results per month. I review these weekly as a hunt activity. Most are legitimate rules. The value is catching the patterns the high-fidelity query doesn't match — like rules that forward to a newly registered domain that isn't in the keyword list.

Important context:

In AiTM compromises, the inbox rule is one of 3-4 persistence mechanisms created within minutes. The attacker also registers a new MFA method and consents to an OAuth app. If you detect the rule, check AuditLogs for the same user:

AuditLogs | where TimeGenerated > ago(24h) | where InitiatedBy has "<compromised user UPN>" | where OperationName in ("Consent to application", "Update user", "Add-MailboxPermission") | project TimeGenerated, OperationName, TargetResources, AdditionalDetails 

If you see MFA registration, OAuth consent, and an inbox rule from the same user in the same hour, that's a confirmed AiTM compromise — not a coincidence.

I'm happy to share more queries from the same investigation if it's helpful.