Detection Engineering Brief - Sunday, July 26, 2026

Threat intelligence translated into detection engineering action.

By DevSecOpsDad
Posted on July 26, 2026

Detection Engineering Summary

This brief produced 4 detection candidates.

1 production candidate, 1 hunting-only, 2 require environment mapping, and 0 rejected.

4 detections include KQL. 4 include ATT&CK mappings. 4 include triage guidance.

Search metadata extracted for this run includes: CVE-2026-16232, T1190, Check Point Security Management, Check Point SmartConsole, Microsoft 365, Teams, T1098, T1098.002, T1114, T1114.001, T1020.

No explicit IOCs were preserved for this run.

Deployment blockers or scheduling gates were identified for: Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232); Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232); Teams External Guest Social Engineering - URL or File Shared to Internal Users.

Detection candidates were derived from recent cybersecurity reporting, operational threat research, RSS intelligence feeds, and related detection engineering sources.



Detection 1: Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232)

Detection Opportunity

Unauthenticated attacker obtains a SmartConsole login token via authentication bypass and subsequently authenticates to the management server with full administrative privileges.

Intelligence Context

Search Metadata

  • CVEs: CVE-2026-16232
  • Threat actors: Not specified
  • ATT&CK tags: T1190
  • Products: Check Point Security Management, Check Point SmartConsole
  • Platforms: Not specified
  • Malware: Not specified
  • Tools: Not specified
  • Search tags: CVE-2026-16232, T1190, Check Point Security Management, Check Point SmartConsole

Relevant IOCs

No explicit IOCs were preserved for this detection.

Metadata

  • Readiness: requires environment mapping
  • Platform: Microsoft Sentinel
  • Analytic type: scheduled_rule
  • Severity recommendation: high
  • MITRE ATT&CK: Initial Access: T1190 Exploit Public-Facing Application (high)

Deployment Gates

  • CommonSecurityLog must be populated by a configured Check Point syslog connector forwarding SmartConsole and Security Management events to the Sentinel workspace. If this connector is absent or misconfigured, the query returns no results.

Required telemetry:

  • CommonSecurityLog

KQL

let ApprovedAdminIPs = dynamic([]);
let lookback = 10m;
let AuthEvents = CommonSecurityLog
| where TimeGenerated >= ago(1d)
| where DeviceVendor == "Check Point"
| where DeviceProduct has_any ("SmartConsole", "Security Management")
| where Activity has_any ("Login", "Authentication", "Token")
| where DeviceAction has_any ("Accept", "Success", "allow")
| project AuthTime = TimeGenerated, SourceIP, AuthActivity = Activity, DeviceProduct, AuthUser = DestinationUserName;
let AdminEvents = CommonSecurityLog
| where TimeGenerated >= ago(1d)
| where DeviceVendor == "Check Point"
| where DeviceProduct has_any ("SmartConsole", "Security Management")
| where Activity has_any ("Admin", "Policy", "Install", "Publish", "Write", "Modify")
| project AdminTime = TimeGenerated, SourceIP, AdminActivity = Activity, AdminUser = DestinationUserName;
AuthEvents
| join kind=inner AdminEvents on SourceIP
| where AdminTime > AuthTime and AdminTime <= AuthTime + lookback
| where SourceIP !in (ApprovedAdminIPs)
| summarize
    AuthTime = min(AuthTime),
    AdminTime = min(AdminTime),
    AuthActivities = make_set(AuthActivity),
    AdminActivities = make_set(AdminActivity),
    Users = make_set(AuthUser),
    AdminUsers = make_set(AdminUser)
    by SourceIP, DeviceProduct
| extend TimeDeltaMinutes = datetime_diff('minute', AdminTime, AuthTime)
| project-reorder SourceIP, DeviceProduct, AuthTime, AdminTime, TimeDeltaMinutes, AuthActivities, AdminActivities, Users, AdminUsers

False Positives / Tuning / Risks / Caveats

Expected false positives:

  • Legitimate administrators performing routine policy changes shortly after logging in from approved IPs not yet added to the exclusion list.
  • Automated scripts or orchestration tools that authenticate and immediately perform admin operations as part of normal change management workflows.
  • Multiple admins behind a shared NAT IP where one logs in and another performs admin activity within the time window.

Tuning notes:

  • Populate ApprovedAdminIPs with all known SmartConsole administrator egress IPs or CIDR ranges before enabling as a scheduled rule.
  • Validate Activity field values against a live sample from your Check Point deployment: CommonSecurityLog → where DeviceVendor == ‘Check Point’ → summarize count() by Activity → order by count_ desc.
  • Reduce the lookback window from 10m to 2-3m if your environment shows that legitimate admin workflows complete quickly, to reduce join noise.
  • Consider adding a DestinationPort filter for SmartConsole management ports (18190, 19009) if that field is populated in your syslog profile to narrow scope.

Risks / caveats:

  • CommonSecurityLog must be populated by a configured Check Point syslog connector forwarding SmartConsole and Security Management events to the Sentinel workspace. If this connector is absent or misconfigured, the query returns no results.
  • The Activity field values used for matching (‘Login’, ‘Authentication’, ‘Token’, ‘Admin’, ‘Policy’, ‘Install’, ‘Publish’, ‘Write’, ‘Modify’) are derived from expected Check Point syslog output and may not match the literal strings emitted by the deployed firmware version. A schema mismatch will silently produce empty result sets.
  • The 10-minute lookback window may be too wide for high-traffic environments where many admins authenticate and act within the same window, increasing join cardinality and false positives.
  • The ApprovedAdminIPs list is empty by default; until populated with known admin source IPs, every legitimate admin login followed by policy work will alert.

Triage Runbook

First 15 minutes:

  • Confirm the source IP is not a known administrator, VPN, jump host, or approved management subnet.
  • Verify the auth event and the admin event are from the same SourceIP and DestinationUserName and occurred within the expected short window.
  • Review the admin activity type first: policy install/publish, object modification, user creation, or configuration write actions are higher risk than routine navigation.
  • Check whether the account is a real admin account or an unexpected username/session associated with the source IP.
  • If the activity is ongoing, preserve logs and note the exact AuthTime, AdminTime, and TimeDeltaMinutes for incident handling.

Evidence to collect:

  • All CommonSecurityLog events for the SourceIP and DestinationUserName for at least 24 hours before and after the alert.
  • The exact Activity and DeviceAction values for the auth event and the first admin event after auth.
  • Any additional admin actions from the same SourceIP, including policy publish/install, object changes, or account changes.
  • Whether the source IP maps to a known admin workstation, NAT, VPN, or external internet address.
  • Check Point management audit context if available, including session/user details and any change history tied to the login.

Pivot points:

  • CommonSecurityLog filtered on DeviceVendor=’Check Point’ and DeviceProduct containing SmartConsole or Security Management.
  • CommonSecurityLog for the same SourceIP, DestinationUserName, and nearby TimeGenerated values to enumerate follow-on admin actions.
  • CommonSecurityLog for other SourceIP values using the same DestinationUserName to identify account reuse or lateral admin access.
  • If available, firewall or proxy logs to determine whether the source IP is external, VPN egress, or internal management traffic.

Benign explanations:

  • A legitimate administrator performed routine policy work immediately after logging in from an unlisted but valid IP.
  • An automation or orchestration account performed normal management tasks after authentication.
  • Multiple administrators shared a NAT IP, causing unrelated login and admin events to correlate.
  • The ApprovedAdminIPs list was incomplete, so a known-good admin source was not excluded.

Escalation criteria:

  • The source IP is external or otherwise not associated with approved management access.
  • The admin activity includes policy publish/install, object changes, account changes, or other configuration writes.
  • There are multiple admin actions after the login, especially if they occur from the same unexpected source IP.
  • The destination user is unknown, newly created, or does not match the expected administrator identity.
  • You find evidence of additional suspicious Check Point management activity from the same source or account.

Containment actions:

  • Disable or reset the affected SmartConsole/admin account if unauthorized access is suspected.
  • Block the source IP at perimeter controls if it is clearly external and malicious.
  • Revoke active management sessions and force reauthentication for Check Point administrators.
  • If policy or configuration changes were made, initiate rollback through approved change-control procedures and validate firewall policy integrity.

Closure criteria:

  • The source IP is confirmed as an approved administrator or automation endpoint and the admin activity matches a documented change.
  • No unauthorized configuration changes, account changes, or policy actions are found.
  • The alert is attributable to a known NAT/shared IP or incomplete allowlist and the environment mapping is corrected.
  • Check Point logs show the login was legitimate and no further suspicious management activity occurred.



Detection 2: Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232)

Detection Opportunity

Successful SmartConsole authentication event originating from a source IP outside the management network, consistent with exploitation of the CVE-2026-16232 authentication bypass in the wild.

Intelligence Context

Search Metadata

  • CVEs: CVE-2026-16232
  • Threat actors: Not specified
  • ATT&CK tags: T1190
  • Products: Check Point Security Management, Check Point SmartConsole
  • Platforms: Not specified
  • Malware: Not specified
  • Tools: Not specified
  • Search tags: CVE-2026-16232, T1190, Check Point Security Management, Check Point SmartConsole

Relevant IOCs

No explicit IOCs were preserved for this detection.

Metadata

  • Readiness: requires environment mapping
  • Platform: Microsoft Sentinel
  • Analytic type: hunting
  • Severity recommendation: high
  • MITRE ATT&CK: Initial Access: T1190 Exploit Public-Facing Application (high)

Deployment Gates

  • CommonSecurityLog must be populated by a configured Check Point syslog connector. If absent, the authentication leg of the join is also empty.

Required telemetry:

  • DeviceNetworkEvents, CommonSecurityLog

KQL

let MgmtPorts = dynamic([18190, 19009, 443]);
let MgmtNetworks = dynamic([]);
let CorrelationWindow = 2m;
let NetworkConns = DeviceNetworkEvents
| where TimeGenerated >= ago(1d)
| where ActionType == "InboundConnectionAccepted"
| where toint(LocalPort) in (MgmtPorts)
| project ConnTime = TimeGenerated, RemoteIP, LocalPort = toint(LocalPort), DeviceName;
let AuthSuccess = CommonSecurityLog
| where TimeGenerated >= ago(1d)
| where DeviceVendor == "Check Point"
| where DeviceProduct has_any ("SmartConsole", "Security Management")
| where Activity has_any ("Login", "Authentication")
| where DeviceAction has_any ("Accept", "Success", "allow")
| project AuthTime = TimeGenerated, SourceIP, Activity, DestinationUserName;
NetworkConns
| join kind=inner AuthSuccess on $left.RemoteIP == $right.SourceIP
| where AuthTime > ConnTime and AuthTime <= ConnTime + CorrelationWindow
| where RemoteIP !in (MgmtNetworks)
| summarize
    ConnCount = count(),
    Ports = make_set(LocalPort),
    Users = make_set(DestinationUserName),
    FirstSeen = min(ConnTime),
    LastSeen = max(AuthTime)
    by RemoteIP, DeviceName
| project-reorder RemoteIP, DeviceName, FirstSeen, LastSeen, ConnCount, Ports, Users

False Positives / Tuning / Risks / Caveats

Expected false positives:

  • Legitimate administrators connecting from home or VPN exit nodes not included in the MgmtNetworks exclusion list.
  • Security scanning tools performing port probes against management ports that coincide with a legitimate admin authentication.
  • Load balancers or proxies in front of the management server that cause the observed RemoteIP to differ from the actual admin workstation IP.

Tuning notes:

  • Verify DeviceNetworkEvents contains rows for the management server before scheduling: DeviceNetworkEvents → where DeviceName contains ‘' → take 5.
  • If MDE telemetry is unavailable for the Check Point host, consider replacing the DeviceNetworkEvents leg with firewall or network flow logs in CommonSecurityLog filtered on DestinationPort in (18190, 19009).
  • Populate MgmtNetworks with all approved administrator source subnets in CIDR notation before enabling.
  • Consider removing port 443 from MgmtPorts if the management server hosts other HTTPS services to reduce false positives from the network connection leg.

Risks / caveats:

  • DeviceNetworkEvents is a Microsoft Defender for Endpoint table. Check Point management servers are typically Linux-based appliances and will not have an MDE agent, meaning DeviceNetworkEvents will contain no rows for the management server host. This is a fundamental telemetry gap that makes the network connection leg of the join non-functional in most deployments.
  • CommonSecurityLog must be populated by a configured Check Point syslog connector. If absent, the authentication leg of the join is also empty.
  • The ActionType value ‘InboundConnectionAccepted’ is specific to MDE network telemetry. If the network data source is a different connector (e.g., firewall logs in CommonSecurityLog), this ActionType will not match.
  • If the Check Point management server is not a Windows host with MDE agent, DeviceNetworkEvents will be empty for that host and this detection will not fire. An alternative approach using firewall logs in CommonSecurityLog to detect inbound connections would be more reliable in most environments.

Triage Runbook

First 15 minutes:

  • Confirm the RemoteIP is outside approved management networks, VPN ranges, and jump hosts.
  • Check whether the authentication was followed by any admin or policy activity from the same IP or user.
  • Identify the authenticated account and determine whether it is a known administrator or an unexpected identity.
  • Review whether the management server should even be reachable from that source IP based on network design.
  • If the event is not clearly legitimate, treat it as potential initial access and preserve relevant logs immediately.

Evidence to collect:

  • The full CommonSecurityLog auth event, including SourceIP, DestinationUserName, Activity, DeviceAction, and TimeGenerated.
  • Any subsequent Check Point admin events from the same RemoteIP or account within at least 30 minutes.
  • Network context for the RemoteIP: geo, ASN, VPN exit node, proxy, or known admin workstation.
  • Historical logins for the same account and source IP to determine whether this is a new pattern.
  • Any Check Point management audit or session records that show what the authenticated user did after login.

Pivot points:

  • CommonSecurityLog for the same SourceIP and DestinationUserName over the prior 7-30 days to establish baseline behavior.
  • CommonSecurityLog for the same RemoteIP to find other accounts or repeated authentication attempts.
  • DeviceNetworkEvents or firewall/network flow logs, if available, to confirm whether the source is truly external.
  • CommonSecurityLog for admin-related Activity values after the auth event to identify post-login actions.

Benign explanations:

  • A legitimate administrator connected from a home network, VPN exit node, or travel location not yet added to the approved list.
  • A proxy, load balancer, or NAT device caused the observed source IP to differ from the actual admin workstation.
  • A security scanner or monitoring system triggered a successful-looking auth event in logs without real interactive access.
  • The management network allowlist is incomplete or outdated.

Escalation criteria:

  • The source IP is internet-facing, unrecognized, or associated with hostile infrastructure.
  • The authenticated account is not a known administrator or the login occurred outside normal admin patterns.
  • Any admin, publish, install, write, or modify activity follows the authentication.
  • There are multiple successful logins from the same unexpected source or repeated attempts across accounts.
  • The management server shows signs of additional suspicious access or configuration changes.

Containment actions:

  • Disable or reset the affected account if unauthorized access is suspected.
  • Block the source IP and any related infrastructure at perimeter controls.
  • Revoke active SmartConsole sessions and force credential rotation for impacted admin accounts.
  • If the management plane may be compromised, isolate the management server from external access until validated.

Closure criteria:

  • The source IP is confirmed as an approved admin endpoint or expected proxy/VPN egress.
  • The login is tied to a legitimate administrator action with no suspicious follow-on activity.
  • No additional suspicious logins, admin actions, or policy changes are found.
  • The allowlist or network mapping is updated so the same benign source is recognized in future.



Detection 3: Teams External Guest Social Engineering - URL or File Shared to Internal Users

Detection Opportunity

External or newly added guest accounts in Microsoft Teams sending messages containing URLs or file attachments to internal users, consistent with Teams-based social engineering campaigns observed in Q2 2026.

Intelligence Context

Search Metadata

  • CVEs: Not specified
  • Threat actors: Not specified
  • ATT&CK tags: T1098, T1098.002, T1114, T1114.001, T1020
  • Products: Microsoft 365, Teams
  • Platforms: Not specified
  • Malware: Not specified
  • Tools: Not specified
  • Search tags: Microsoft 365, Teams, T1098, T1098.002, T1114, T1114.001, T1020

Relevant IOCs

No explicit IOCs were preserved for this detection.

Metadata

  • Readiness: hunting-only
  • Platform: Microsoft Sentinel
  • Analytic type: scheduled_rule
  • Severity recommendation: medium
  • MITRE ATT&CK: Persistence: T1098 Account Manipulation/ T1098.002 Additional Email Delegate Permissions (low); Collection: T1114 Email Collection/ T1114.001 Local Email Collection (medium); Exfiltration: T1020 Data Exfiltration (low)

Deployment Gates

  • Do not schedule yet; validate as an analyst-led hunt first.

Required telemetry:

  • OfficeActivity

KQL

let lookback = 1d;
let MinMessages = 2;
OfficeActivity
| where TimeGenerated >= ago(lookback)
| where OfficeWorkload == "MicrosoftTeams"
| where Operation in ("MessageSent", "ChatMessageSent")
| where ResultStatus == "Succeeded"
| where UserId has "#EXT#" or ExternalAccess == true
| extend AdditionalInfoStr = tostring(AdditionalInfo)
| extend IsURLShare = AdditionalInfoStr has_any ("http://", "https://")
| where IsURLShare == true
| summarize
    MessageCount = count(),
    Operations = make_set(Operation),
    ClientIPs = make_set(ClientIP),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by UserId, ExternalAccess
| where MessageCount >= MinMessages
| project-reorder UserId, ExternalAccess, MessageCount, Operations, ClientIPs, FirstSeen, LastSeen

False Positives / Tuning / Risks / Caveats

Expected false positives:

  • Legitimate external partners or vendors who regularly share URLs or documents with internal users via Teams.
  • Automated integration accounts with guest UPNs that post notifications containing URLs to Teams channels.
  • Internal users whose UPNs contain ‘#EXT#’ due to tenant migration or B2B federation configurations.

Tuning notes:

  • Before scheduling, validate that AdditionalInfo contains URL strings for Teams messages by running: OfficeActivity → where OfficeWorkload == ‘MicrosoftTeams’ → where Operation == ‘MessageSent’ → extend s = tostring(AdditionalInfo) → where s has ‘http’ → take 5.
  • If AdditionalInfo does not contain URLs, consider pivoting to the ChatCreated or MessagesListed operations or enriching with Microsoft Graph API data.
  • Increase MinMessages threshold in large tenants with frequent legitimate external collaboration to reduce alert volume.
  • Consider adding a time-window grouping (e.g., bin(TimeGenerated, 1h)) to detect burst sending patterns rather than daily aggregates.

Risks / caveats:

  • The AdditionalInfo field in OfficeActivity for Teams MessageSent events does not reliably contain message body content or URL strings across all M365 audit log configurations. Searching for ‘http://’ within this field may produce no matches even when URLs are shared, making the URL detection logic unreliable.
  • OfficeActivity Teams events require that Microsoft Teams audit logging is enabled in the Microsoft 365 compliance center. If not enabled, no Teams events will appear in OfficeActivity.
  • The ExternalAccess field may not be consistently populated for all Teams event types; its availability should be verified against the target workspace.
  • The AdditionalInfo field may not contain message body or URL content in all Teams audit log configurations. If URLs are not surfaced in this field, the IsURLShare filter will exclude all events and the query will return no results even during active campaigns.

Triage Runbook

First 15 minutes:

  • Confirm the sender is truly external or guest and not a legitimate partner account.
  • Review the message context for obvious business justification, sender reputation, and whether the content is a link or file-sharing lure.
  • Identify which internal users or teams were targeted and whether the same sender contacted multiple people.
  • Check whether the account was recently added as a guest or shows unusual recent activity.
  • If the message appears suspicious, preserve the message metadata and notify the affected users not to interact with it.

Evidence to collect:

  • The sender identity, ExternalAccess status, and any guest indicators such as ‘#EXT#’ in UserId.
  • The message timestamps, Operation values, ClientIP values, and any available AdditionalInfo content.
  • The internal recipients or channels involved, if available through adjacent audit or collaboration logs.
  • Any URLs, file names, or attachment references surfaced in the message metadata.
  • Historical activity for the sender account to determine whether this is normal partner collaboration or a new pattern.

Pivot points:

  • OfficeActivity for the same UserId to enumerate all Teams operations and message bursts over the last 7-30 days.
  • OfficeActivity for other external or guest accounts sending MessageSent or ChatMessageSent events to internal users.
  • If available, SharePoint/OneDrive audit logs for file-sharing follow-on activity tied to the same sender or time window.
  • Entra ID or guest user management logs to determine when the guest account was added and by whom.

Benign explanations:

  • A legitimate external partner or vendor regularly shares links or documents through Teams.
  • A guest account is used for normal project collaboration and the message content is business-related.
  • An automation or integration account posts notifications containing URLs to Teams.
  • The account is external but authorized, and the content is expected in the current business process.

Escalation criteria:

  • The sender is an unrecognized guest or external account with no clear business relationship.
  • The message contains a credential-harvesting link, unexpected file, or urgent social-engineering language.
  • Multiple internal users or teams were targeted in a short period.
  • The sender account was recently added as a guest or shows other suspicious activity.
  • Recipients report clicking the link, downloading the file, or entering credentials.

Containment actions:

  • Remove or suspend the guest account if it is unauthorized or clearly malicious.
  • Delete or quarantine the message if your collaboration controls support it.
  • Warn targeted users not to open links or files and instruct them to report any credential prompts.
  • If credentials may have been entered, initiate account protection steps for affected users.

Closure criteria:

  • The sender is confirmed as a legitimate partner, vendor, or approved guest with a valid business purpose.
  • The message content is benign and no suspicious follow-on activity is found.
  • No additional targeted messages, file shares, or user reports indicate malicious intent.
  • The guest/external access is documented and the alert is attributable to normal collaboration.



Detection 4: M365 Automated Multi-Stage Attack Chain - Sequential Privileged Operations After Sign-In

Detection Opportunity

Rapid sequential Microsoft 365 operations including sign-in, mail rule creation, and data access performed by the same user within a short time window, consistent with automated multi-stage attack chains targeting M365 users observed in Q2 2026.

Intelligence Context

Search Metadata

  • CVEs: Not specified
  • Threat actors: Not specified
  • ATT&CK tags: T1098, T1098.002, T1114, T1114.001, T1020
  • Products: Microsoft 365, Teams
  • Platforms: Not specified
  • Malware: Not specified
  • Tools: Not specified
  • Search tags: Microsoft 365, Teams, T1098, T1098.002, T1114, T1114.001, T1020

Relevant IOCs

No explicit IOCs were preserved for this detection.

Metadata

  • Readiness: production candidate
  • Platform: Microsoft Sentinel
  • Analytic type: correlation
  • Severity recommendation: high
  • MITRE ATT&CK: Persistence: T1098 Account Manipulation/ T1098.002 Additional Email Delegate Permissions (low); Collection: T1114 Email Collection/ T1114.001 Local Email Collection (medium); Exfiltration: T1020 Data Exfiltration (low)

Deployment Gates

  • MailItemsAccessed in OfficeActivity requires Microsoft 365 E5 licensing or the Microsoft 365 Advanced Audit add-on. Without this license, MailItemsAccessed events will not appear and coverage for mailbox access operations will be absent, though the query will still function for other operations in HighRiskOps.
  • MailItemsAccessed events will be absent without E5 or Advanced Audit licensing, reducing detection coverage for mailbox access as part of the attack chain.

Required telemetry:

  • SigninLogs, OfficeActivity

KQL

let ChainWindow = 30m;
let HighRiskOps = dynamic(["New-InboxRule", "Set-InboxRule", "Set-Mailbox", "UpdateInboxRules", "MailItemsAccessed", "FileDownloaded", "FileSyncDownloadedFull", "Send"]);
let Signins = SigninLogs
| where TimeGenerated >= ago(1d)
| where ResultType == 0
| project SigninTime = TimeGenerated, UserId = tolower(UserPrincipalName), SigninIP = IPAddress, ConditionalAccessStatus;
let PostAuthOps = OfficeActivity
| where TimeGenerated >= ago(1d)
| where ResultStatus == "Succeeded"
| where Operation in (HighRiskOps)
| project OpTime = TimeGenerated, UserId = tolower(UserId), Operation, OpIP = ClientIP, OfficeWorkload;
Signins
| join kind=inner PostAuthOps on UserId
| where OpTime > SigninTime and OpTime <= SigninTime + ChainWindow
| summarize
    SigninTime = min(SigninTime),
    OpsPerformed = make_set(Operation),
    WorkloadsAccessed = make_set(OfficeWorkload),
    OpIPs = make_set(OpIP),
    SigninIPs = make_set(SigninIP),
    OpCount = dcount(Operation),
    ConditionalAccessStatus = take_any(ConditionalAccessStatus)
    by UserId
| where OpCount >= 2
| extend IPMismatch = isempty(set_intersect(SigninIPs, OpIPs))
| project-reorder UserId, SigninTime, OpCount, OpsPerformed, WorkloadsAccessed, SigninIPs, OpIPs, IPMismatch, ConditionalAccessStatus

False Positives / Tuning / Risks / Caveats

Expected false positives:

  • Power users or administrators who legitimately create inbox rules and access mail in rapid succession after signing in.
  • Automated IT provisioning scripts that sign in and perform multiple mailbox configuration operations as part of onboarding workflows.
  • Users accessing M365 through a proxy or VPN that presents a different IP for the sign-in versus the subsequent Office operations, triggering IPMismatch without malicious intent.
  • Shared mailbox or service account operations where multiple operations are performed programmatically after a single authentication.

Tuning notes:

  • Increase OpCount threshold from 2 to 3 to reduce false positives from users who legitimately perform two high-risk operations in sequence.
  • Add → where ConditionalAccessStatus == ‘notApplied’ to the Signins subquery to prioritize sign-ins that bypassed conditional access policies.
  • Add exclusions for known service account UPNs that perform automated operations: → where UserId !in (dynamic([‘svc-account@domain.com’])).
  • Validate UPN format consistency between SigninLogs and OfficeActivity by running: SigninLogs → project upn = tolower(UserPrincipalName) → join kind=inner (OfficeActivity → project uid = tolower(UserId)) on $left.upn == $right.uid → take 5.

Risks / caveats:

  • MailItemsAccessed in OfficeActivity requires Microsoft 365 E5 licensing or the Microsoft 365 Advanced Audit add-on. Without this license, MailItemsAccessed events will not appear and coverage for mailbox access operations will be absent, though the query will still function for other operations in HighRiskOps.
  • SigninLogs requires Azure AD (Entra ID) diagnostic settings to be configured to stream sign-in logs to the Sentinel workspace. If not configured, SigninLogs will be empty and the join will produce no results.
  • UserId in OfficeActivity may contain display names or UPNs depending on the workload and event type. The tolower() normalization handles case differences but cannot resolve format mismatches between display names and UPNs.
  • The join between SigninLogs and OfficeActivity on tolower(UserId) will fail silently for accounts where OfficeActivity UserId contains a display name rather than a UPN, which occurs for some Exchange and SharePoint operations.

Triage Runbook

First 15 minutes:

  • Confirm the sign-in was successful and whether the IP address is expected for the user.
  • Review the sequence of operations to see whether mailbox rules, mailbox settings, or mail access occurred immediately after sign-in.
  • Check whether the account is a high-value user, executive, mailbox delegate, or service account.
  • Look for IPMismatch and ConditionalAccessStatus to assess whether the session may involve token replay or policy bypass.
  • If the sequence is suspicious, preserve the sign-in and OfficeActivity records before any user remediation changes are made.

Evidence to collect:

  • The SigninLogs record including UserPrincipalName, IPAddress, ResultType, and ConditionalAccessStatus.
  • The OfficeActivity events for the same user showing Operation, ClientIP, OfficeWorkload, and ResultStatus.
  • The exact operations performed, especially New-InboxRule, Set-InboxRule, Set-Mailbox, MailItemsAccessed, FileDownloaded, or Send.
  • Any mailbox rule details, forwarding settings, or delegate changes if present in adjacent logs.
  • Historical sign-in and mailbox activity for the same user to establish baseline behavior.

Pivot points:

  • SigninLogs for the same UserPrincipalName over the last 7-30 days to compare IPs, locations, and conditional access outcomes.
  • OfficeActivity for the same UserId to enumerate all post-auth operations and identify additional suspicious actions.
  • Exchange/Defender for Office 365 audit logs, if available, for mailbox rule creation, forwarding, or message access details.
  • Entra ID risk and identity logs to determine whether the account shows impossible travel, unfamiliar sign-in properties, or other risk signals.

Benign explanations:

  • A power user or administrator legitimately performed multiple mailbox actions immediately after signing in.
  • An IT provisioning or onboarding workflow executed scripted mailbox operations.
  • A proxy, VPN, or application gateway caused the sign-in IP and operation IP to differ without malicious intent.
  • A shared mailbox or service account performed expected automated actions after authentication.

Escalation criteria:

  • The account is a high-value user, executive, or mailbox with sensitive data.
  • Mailbox forwarding, inbox rules, or delegate permissions were created or modified unexpectedly.
  • MailItemsAccessed or file download activity is unusual for the user and occurs immediately after sign-in.
  • The sign-in IP is unfamiliar, the session bypassed conditional access, or IPMismatch suggests token replay.
  • There is evidence of additional suspicious activity such as mass mail access, message sending, or data download.

Containment actions:

  • Reset the affected account password and revoke active sessions if compromise is suspected.
  • Remove suspicious inbox rules, forwarding settings, or delegate permissions.
  • Disable the account temporarily if there is clear evidence of unauthorized access or ongoing abuse.
  • Escalate to identity and email security teams to review for token theft, phishing, or mailbox exfiltration.

Closure criteria:

  • The sign-in and subsequent operations are confirmed as legitimate and match a documented business process.
  • No suspicious mailbox rules, forwarding, delegate changes, or abnormal data access are found.
  • The IP mismatch is explained by approved VPN, proxy, or application routing.
  • The account is not high-risk and no additional indicators of compromise are present.



Pre-Deployment Checklist by Dependency Type

Telemetry availability:

  • Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232): CommonSecurityLog must be populated by a configured Check Point syslog connector forwarding SmartConsole and Security Management events to the Sentinel workspace. If this connector is absent or misconfigured, the query returns no results.
  • Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232): CommonSecurityLog must be populated by a configured Check Point syslog connector. If absent, the authentication leg of the join is also empty.

Schema / correlation keys:

  • Teams External Guest Social Engineering - URL or File Shared to Internal Users: Do not schedule yet; validate as an analyst-led hunt first.

Licensing / identity risk fields:

  • M365 Automated Multi-Stage Attack Chain - Sequential Privileged Operations After Sign-In: MailItemsAccessed in OfficeActivity requires Microsoft 365 E5 licensing or the Microsoft 365 Advanced Audit add-on. Without this license, MailItemsAccessed events will not appear and coverage for mailbox access operations will be absent, though the query will still function for other operations in HighRiskOps.

Shared-table notes:

  • CommonSecurityLog: shared by Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232); Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232)
  • OfficeActivity: shared by Teams External Guest Social Engineering - URL or File Shared to Internal Users; M365 Automated Multi-Stage Attack Chain - Sequential Privileged Operations After Sign-In

Sequenced Deployment Plan

  1. Start with production candidates that have no gate-level blockers: M365 Automated Multi-Stage Attack Chain - Sequential Privileged Operations After Sign-In.
  2. Resolve environment-mapping detections next: Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232); Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232).
  3. Keep hunting-only detections in analyst-led mode until their promotion criteria are met: Teams External Guest Social Engineering - URL or File Shared to Internal Users.

Hunting Agenda and Promotion Criteria

  • Teams External Guest Social Engineering - URL or File Shared to Internal Users: Do not schedule yet; validate as an analyst-led hunt first.; baseline expected benign activity and define an alert-volume threshold.
  • Check Point SmartConsole Auth Bypass - Successful Login Followed by Admin Activity (CVE-2026-16232): CommonSecurityLog must be populated by a configured Check Point syslog connector forwarding SmartConsole and Security Management events to the Sentinel workspace. If this connector is absent or misconfigured, the query returns no results.; baseline expected benign activity and define an alert-volume threshold; prove correlation keys join correctly on real tenant telemetry.
  • Check Point SmartConsole - Successful Authentication from Unexpected External Source (CVE-2026-16232): CommonSecurityLog must be populated by a configured Check Point syslog connector. If absent, the authentication leg of the join is also empty.; baseline expected benign activity and define an alert-volume threshold; prove correlation keys join correctly on real tenant telemetry.

Unique Blind Spot Callout

No unique blind spot was isolated beyond the detection-specific gates above.



Generated by DevSecOpsDadAttack threat intelligence and detection engineering. Validate detections before deployment.

Tags:  detection-engineering  kql  CVE-2026-16232  T1190  Check Point Security Management  Check Point SmartConsole  Microsoft 365  Teams  T1098  T1098.002  T1114  T1114.001  T1020
DevSecOpsDadAttack!
Share: X (Twitter) LinkedIn