Detection Engineering Brief - Saturday, August 22, 2026

Detection Engineering Summary

This brief produced 2 detection candidates.

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

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

Search metadata extracted for this run includes: CVE-2026-19490, T1190, Citrix NetScaler ADC, Citrix NetScaler Gateway, enterprise collaboration tools, identity systems, T1566, T1566.003, T1110.

No explicit IOCs were preserved for this run.

Deployment blockers or scheduling gates were identified for: Citrix NetScaler Auth Bypass - Unauthenticated Success to Gateway Endpoints (CVE-2026-19490); Teams External Message Followed by Credential Use from New Location - Identity Phishing via Collaboration Tool.

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

Detection 1: Citrix NetScaler Auth Bypass - Unauthenticated Success to Gateway Endpoints (CVE-2026-19490)

Detection Opportunity

Remote unauthenticated exploitation of Citrix NetScaler ADC or Gateway authentication bypass, resulting in HTTP 2xx responses to protected endpoints from external IPs without prior authentication.

Intelligence Context

• Rapid7: CVE-2026-19490: Critical Vulnerability Affecting Citrix NetScaler ADC and NetScaler Gateway — https://www.rapid7.com/blog/post/etr-cve-2026-19490-critical-vulnerability-affecting-citrix-netscaler-adc-and-netscaler-gateway
  • Context: Rapid7 confirmed CVE-2026-19490 allows unauthenticated remote attackers to bypass perimeter authentication on Citrix NetScaler ADC and Gateway over the network. The exploitation produces HTTP success responses to protected endpoints without valid credentials.

Search Metadata

• CVEs: CVE-2026-19490
• Threat actors: Not specified
• ATT&CK tags: T1190
• Products: Citrix NetScaler ADC, Citrix NetScaler Gateway
• Platforms: Not specified
• Malware: Not specified
• Tools: Not specified
• Search tags: CVE-2026-19490, T1190, Citrix NetScaler ADC, Citrix NetScaler Gateway

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

• Environment-specific telemetry or field mapping must be resolved for Microsoft Sentinel: CommonSecurityLog before scheduling.

Required telemetry:

• CommonSecurityLog

KQL

CommonSecurityLog
| where TimeGenerated >= ago(24h)
| where DeviceVendor =~ "Citrix"
| where DeviceProduct has_any ("NetScaler", "NetScaler ADC", "NetScaler Gateway")
| where isnotempty(SourceIP)
| extend HttpStatus = toint(extract(@"cs-status=(\d+)", 1, AdditionalExtensions))
| where isnotempty(HttpStatus) and HttpStatus > 0
| where HttpStatus between (200 .. 299)
| where RequestURL has_any ("/vpn/", "/citrix/", "/logon/", "/nf/", "/epa/", "/cgi/")
| where not(ipv4_is_private(SourceIP))
| summarize
    RequestCount = count(),
    DistinctURLs = dcount(RequestURL),
    SampleURLs = make_set(RequestURL, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    SampleDeviceAction = make_set(DeviceAction, 3)
    by SourceIP, DestinationPort, DeviceProduct
| where RequestCount >= 3
| sort by RequestCount desc

False Positives / Tuning / Risks / Caveats

Expected false positives:

• External load balancer health checks or CDN probes hitting gateway paths from non-RFC1918 IPs with HTTP 200 responses.
• Legitimate remote users accessing VPN or EPA endpoints from external IPs where the NetScaler returns 200 after successful authentication (the query cannot distinguish pre-auth from post-auth success without session correlation).
• Vulnerability scanners or penetration testing tools probing gateway paths.

Tuning notes:

• Run the following validation query before scheduling to confirm AdditionalExtensions contains parseable cs-status values: CommonSecurityLog → where TimeGenerated >= ago(1h) → where DeviceVendor =~ ‘Citrix’ → extend HttpStatus = toint(extract(@’cs-status=(\d+)’, 1, AdditionalExtensions)) → summarize Populated = countif(isnotempty(HttpStatus)), Total = count()
• Increase RequestCount threshold to 10 or higher in environments with external health-check or monitoring infrastructure hitting gateway paths.
• Add a DeviceAction filter (e.g., DeviceAction !in (‘blocked’, ‘denied’)) if the NetScaler WAF profile populates that field, to focus on allowed requests.
• Consider adding a RiskScore or threat intelligence join on SourceIP using the ThreatIntelligenceIndicator table to prioritize known-bad sources.

Risks / caveats:

• The ‘cs-status’ key inside AdditionalExtensions is not a guaranteed standard CEF field for Citrix NetScaler; if NetScaler CEF output uses a different key name (e.g., ‘sc-status’, ‘httpStatusCode’, or embeds status in the message body), the HttpStatus extract will return null for all rows and the query will produce zero results.
• CommonSecurityLog ingestion from Citrix NetScaler requires a CEF-compatible syslog forwarder or the Citrix WAF/ADC data connector to be configured in the Sentinel workspace; if neither is present, the table will contain no NetScaler rows.
• RequestURL is a standard CEF field (cs-uri-stem) but may not be populated by all NetScaler log profiles; if the field is empty, the URL path filter will exclude all rows.
• The ‘cs-status’ regex pattern must be validated against actual AdditionalExtensions values from the specific NetScaler firmware and log profile in use before scheduling; if the key name differs, HttpStatus will be null for all rows.

Triage Runbook

First 15 minutes:

• Confirm the alert is tied to a real Citrix NetScaler device and not a parsing issue by checking whether the source appliance is expected to emit CEF with cs-status in AdditionalExtensions.
• Review the source IP, destination port, and sample URLs to determine whether the traffic is coming from a single scanner, a small set of sources, or a broad internet campaign.
• Check whether the same source IP generated repeated requests across multiple gateway paths such as /vpn/, /citrix/, /logon/, /nf/, /epa/, or /cgi/ within the alert window.
• Look for any concurrent signs of successful authentication, unusual session creation, or admin activity on the same NetScaler appliance around FirstSeen and LastSeen.
• If the appliance is internet-facing and the alert volume is high or the source is clearly hostile, treat as a potential active exploitation attempt and escalate immediately.

Evidence to collect:

• NetScaler access logs and any WAF/ADC logs covering the alert window, including the full request URI, source IP, response code, and any session or cookie identifiers.
• DeviceAction or equivalent action fields to see whether the appliance allowed, blocked, or challenged the requests.
• Configuration and patch level for the affected NetScaler ADC/Gateway instance, including whether CVE-2026-19490 mitigation or vendor guidance has been applied.
• Any authentication, VPN, or gateway session logs that show whether the same source IP or user session progressed beyond the initial 2xx responses.
• Threat intelligence or reputation results for the source IPs and any related infrastructure observed in the same time window.

Pivot points:

• CommonSecurityLog for the same SourceIP, DestinationPort, and DeviceProduct over the prior 24 to 72 hours to identify broader probing or repeated hits.
• NetScaler appliance logs or vendor-specific syslog streams for the same timestamps to validate whether the 2xx responses correspond to protected endpoints.
• Authentication and VPN session logs to correlate any successful logons, new sessions, or unusual user activity after the requests.
• ThreatIntelligenceIndicator or equivalent enrichment source for the SourceIP and any related IPs or domains.
• Change management or patch inventory records to confirm whether the appliance was vulnerable at the time of the alert.

Benign explanations:

• External load balancer or CDN health checks hitting gateway paths and receiving 200 responses.
• Legitimate remote users successfully authenticating to VPN or gateway endpoints from external IPs.
• Authorized vulnerability scanning or penetration testing activity against the NetScaler appliance.
• A logging or parsing issue where cs-status is extracted incorrectly and the alert is not reflecting true HTTP success responses.

Escalation criteria:

• Multiple external source IPs are hitting the same NetScaler gateway paths with repeated 2xx responses in a short period.
• The appliance is confirmed unpatched or exposed and the activity aligns with vendor-described exploitation behavior.
• There is any evidence of post-authentication abuse, unusual session creation, or admin access following the requests.
• The source IP is known malicious or the activity is part of a broader campaign affecting multiple assets.

Containment actions:

• If exploitation is plausible and the appliance is exposed, restrict access to the affected NetScaler interface from untrusted sources while preserving business-critical access paths.
• Apply vendor-recommended mitigations or emergency patching as soon as change control allows.
• Block clearly malicious source IPs at the perimeter if doing so will not disrupt legitimate users or testing activity.
• Preserve logs and configuration state before making disruptive changes so forensic review remains possible.

Closure criteria:

• The source traffic is confirmed to be benign health checks, authorized testing, or legitimate user activity with no evidence of bypass or abuse.
• The NetScaler instance is verified patched or otherwise not vulnerable, and the alert is attributable to expected external traffic.
• No suspicious follow-on authentication, session creation, or admin activity is found in correlated logs.
• The parsing issue is confirmed and the detection is tuned or remediated so the alert no longer represents a real security event.

Detection 2: Teams External Message Followed by Credential Use from New Location - Identity Phishing via Collaboration Tool

Detection Opportunity

Attackers abuse Microsoft Teams external messaging to deliver identity phishing lures, followed by credential use from a previously unseen location or IP, indicating successful credential theft via a trusted communication channel.

Intelligence Context

• Unit 42: Identity Abuse Through Trusted Communication Channels — https://unit42.paloaltonetworks.com/communication-channel-identity-risks/
  • Context: Unit 42 reported that attackers exploit enterprise collaboration tools such as Microsoft Teams to conduct identity phishing and steal credentials. The attack pattern involves external actors sending phishing messages through Teams, followed by credential use from attacker-controlled infrastructure.

Search Metadata

• CVEs: Not specified
• Threat actors: Not specified
• ATT&CK tags: T1566, T1566.003, T1110
• Products: Not specified
• Platforms: enterprise collaboration tools, identity systems
• Malware: Not specified
• Tools: Not specified
• Search tags: enterprise collaboration tools, identity systems, T1566, T1566.003, T1110

Relevant IOCs

No explicit IOCs were preserved for this detection.

Metadata

• Readiness: hunting-only
• Platform: Microsoft Sentinel
• Analytic type: hunting
• Severity recommendation: high
• MITRE ATT&CK: Initial Access: T1566 Phishing/ T1566.003 Spearphishing via Service (medium); Credential Access: T1110 Brute Force (low)

Deployment Gates

• Do not schedule yet; validate as an analyst-led hunt first.
• Entra ID P2 is required for RiskLevelDuringSignIn-based identity-risk detections.

Required telemetry:

• OfficeActivity, SigninLogs

KQL

let LookbackBaseline = 30d;
let PhishingWindow = 24h;
let CorrelationWindow = 6h;
let ExternalTeamsMessages = OfficeActivity
    | where TimeGenerated >= ago(PhishingWindow)
    | where RecordType == "MicrosoftTeams"
    | where Operation in ("MessageCreatedHasLink", "MessageSent", "MemberAdded")
    | where ExternalAccess == true
    | where isnotempty(UserId)
    | project PhishTime = TimeGenerated, TargetUser = tolower(UserId);
let BaselineLocations = SigninLogs
    | where TimeGenerated between (ago(LookbackBaseline) .. ago(PhishingWindow))
    | where ResultType == 0
    | where isnotempty(Location)
    | summarize KnownLocations = make_set(Location) by UserPrincipalName;
SigninLogs
| where TimeGenerated >= ago(PhishingWindow)
| where ResultType == 0
| where isnotempty(Location)
| extend UPN = tolower(UserPrincipalName)
| join kind=inner ExternalTeamsMessages on $left.UPN == $right.TargetUser
| where TimeGenerated between (PhishTime .. (PhishTime + CorrelationWindow))
| join kind=leftouter BaselineLocations on $left.UPN == $right.UserPrincipalName
| where not(Location in (KnownLocations))
| project
    SigninTime = TimeGenerated,
    PhishTime,
    UserPrincipalName,
    SigninIP = IPAddress,
    SigninLocation = Location,
    ConditionalAccessStatus,
    RiskLevelDuringSignIn,
    AppDisplayName,
    UserAgent
| sort by SigninTime desc

False Positives / Tuning / Risks / Caveats

Expected false positives:

• Legitimate users who receive external Teams messages from vendors or partners and then sign in from a new location (travel, new device, VPN exit node) within 6 hours.
• Users who recently changed their primary work location or began using a new VPN provider, causing their sign-in location to appear new relative to the 30-day baseline.
• Shared or service accounts that receive external Teams notifications and authenticate from cloud infrastructure IPs not seen in the baseline.
• Users onboarded within the last 30 days will have sparse or empty baselines, causing all their sign-in locations to appear new.

Tuning notes:

• Before scheduling, validate ExternalAccess field population by running: OfficeActivity → where TimeGenerated >= ago(7d) → where RecordType == ‘MicrosoftTeams’ → summarize ExternalTrue = countif(ExternalAccess == true), ExternalFalse = countif(ExternalAccess == false), Null = countif(isnull(ExternalAccess)) by Operation
• Add a filter on RiskLevelDuringSignIn in (‘high’, ‘medium’) to reduce analyst workload if Identity Protection licensing is available.
• Add an exclusion for known VPN or proxy IP ranges used by the organization to reduce false positives from legitimate remote workers.
• Consider adding a ConditionalAccessStatus == ‘notApplied’ or ‘failure’ filter to surface sign-ins that bypassed conditional access policies.

Risks / caveats:

• The OfficeActivity ‘ExternalAccess’ field is not consistently populated for all Teams message operation types; for ‘MessageSent’ and ‘MessageCreatedHasLink’, external sender identification may require parsing the ‘Members’ JSON array, which varies in structure across audit log versions.
• The ‘Members’ field in OfficeActivity Teams records is a JSON array whose schema (field names such as ‘UPN’) is not guaranteed stable across Microsoft audit log versions; if the schema changes, the parse_json extraction will silently return null.
• SigninLogs requires Azure AD P1 or P2 licensing; tenants without this license will have incomplete or absent sign-in log data, making the correlation unreliable.
• The ‘RiskLevelDuringSignIn’ field in SigninLogs requires Azure AD Identity Protection (P2 license); without it, the field will be empty for all rows.

Triage Runbook

First 15 minutes:

• Identify the targeted user and review the Teams message content, sender identity, and timing relative to the sign-in event.
• Check whether the sender was truly external and whether the message contained a link, attachment, or request for credentials or MFA approval.
• Review the sign-in details for the new location, IP address, user agent, app, and Conditional Access outcome to assess whether the login is suspicious.
• Compare the sign-in location against the user’s recent baseline and determine whether the location is genuinely new or explainable by travel, VPN, or a corporate proxy.
• If the sign-in is high risk, from an unfamiliar device, or followed by suspicious mailbox or collaboration activity, escalate as likely account compromise.

Evidence to collect:

• The full Teams message record, including sender, recipient, timestamp, message body, links, and any file or attachment references.
• SigninLogs entries for the user around PhishTime and SigninTime, including IPAddress, Location, AppDisplayName, UserAgent, ConditionalAccessStatus, and RiskLevelDuringSignIn.
• The user’s 30-day sign-in baseline or recent location history to confirm whether the sign-in location is truly anomalous.
• Any post-login activity such as mailbox rule creation, MFA changes, consent grants, file downloads, or additional sign-ins from the same IP.
• Identity Protection, audit, and alerting records that show whether the account was flagged for risk or unusual behavior.

Pivot points:

• OfficeActivity for additional Teams messages from the same external sender or to other users in the same time window.
• SigninLogs for the same UserPrincipalName, IPAddress, or user agent to identify repeated access or lateral activity.
• AuditLogs for MFA registration changes, password resets, consent grants, or mailbox rule creation after the sign-in.
• Mailbox or collaboration audit data to see whether the user interacted with the message content or followed embedded links.
• Threat intelligence or proxy logs for the sign-in IP and any domains or URLs referenced in the Teams message.

Benign explanations:

• A legitimate vendor, partner, or customer contacted the user through Teams and the user then signed in from a new but valid location.
• The user was traveling, using a new VPN exit node, or working from a different office or home network.
• The sign-in location is a geolocation artifact caused by cloud hosting, mobile carrier routing, or proxy use.
• The user is newly onboarded or has sparse baseline history, making normal activity appear anomalous.

Escalation criteria:

• The Teams message is clearly phishing-like and the subsequent sign-in is from an unfamiliar IP, device, or geography.
• Identity Protection shows medium or high risk, or Conditional Access did not behave as expected for the sign-in.
• There is evidence of post-login abuse such as mailbox rule creation, MFA reset, consent grant, or unusual file access.
• Multiple users received similar external Teams messages or multiple accounts signed in from the same suspicious infrastructure.

Containment actions:

• If compromise is likely, disable the account or force sign-out and password reset according to your identity incident process.
• Revoke active sessions and refresh tokens for the affected account.
• Reset MFA methods or require re-registration if there is any sign of MFA tampering or push fatigue abuse.
• Block the malicious sender or related external tenant in Teams if the organization’s policy and tooling support it.

Closure criteria:

• The external Teams message is verified as legitimate business communication and the sign-in is explained by travel, VPN, or another approved reason.
• The sign-in is confirmed to be the user’s own activity and no suspicious post-login actions are present.
• No additional users or accounts show the same lure-to-sign-in pattern from the same sender or infrastructure.
• The alert is attributable to baseline limitations or incomplete Teams/SigninLogs data rather than a real compromise.

Recommended Next Actions

Pre-Deployment Checklist by Dependency Type

Telemetry availability:

• Citrix NetScaler Auth Bypass - Unauthenticated Success to Gateway Endpoints (CVE-2026-19490): Environment-specific telemetry or field mapping must be resolved for Microsoft Sentinel: CommonSecurityLog before scheduling.

Schema / correlation keys:

• Teams External Message Followed by Credential Use from New Location - Identity Phishing via Collaboration Tool: Do not schedule yet; validate as an analyst-led hunt first.

Licensing / identity risk fields:

• Entra ID P2 is required for RiskLevelDuringSignIn-based identity-risk detections.

Shared-table notes:

• No major shared table dependency identified across this run.

Sequenced Deployment Plan

1. Resolve environment-mapping detections next: Citrix NetScaler Auth Bypass - Unauthenticated Success to Gateway Endpoints (CVE-2026-19490).
2. Keep hunting-only detections in analyst-led mode until their promotion criteria are met: Teams External Message Followed by Credential Use from New Location - Identity Phishing via Collaboration Tool.

Hunting Agenda and Promotion Criteria

• Teams External Message Followed by Credential Use from New Location - Identity Phishing via Collaboration Tool: Do not schedule yet; validate as an analyst-led hunt first.; baseline expected benign activity and define an alert-volume threshold.
• Citrix NetScaler Auth Bypass - Unauthenticated Success to Gateway Endpoints (CVE-2026-19490): Environment-specific telemetry or field mapping must be resolved for Microsoft Sentinel: CommonSecurityLog before scheduling.; baseline expected benign activity and define an alert-volume threshold; prove correlation keys join correctly on real tenant telemetry.

Unique Blind Spot Callout

This run exposes an identity-risk licensing blind spot: detections using RiskLevelDuringSignIn lose fidelity in tenants without Entra ID P2 risk enrichment.

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