TA419 — AI Policy AitM Credential Phishing

Looks for: a browser process resolving one of the 8 published first-stage redirect domains. FP: none expected — single-purpose phishing infrastructure with no legitimate use.

// HUNT: TA419 - T1566.002/T1204.001 - DNS Resolution of First-Stage Redirect Domain
// HYPOTHESIS: A host mid-way through the TA419 lure chain will issue a DNS request for one of the 8 published first-stage redirect domains, from a browser process.
// CONF: high  FP: low  COST: low | REQUIRES: core Falcon DNS + process telemetry
// LOOKBACK: 90d (set in the Falcon time picker; campaign infra active Dec 2025-Jul 2026)
#event_simpleName = DnsRequest
| DomainName = /^(driftshare\.co|quickfly\.online|cirrushare\.co|goshshare\.online|synchvault\.co|msfile\.online|winsync\.cloud|sharehub\.space)$/i
| rename(field=ContextProcessId_decimal, as=TargetProcessId_decimal)
| join(query={#event_simpleName = /ProcessRollup2|SyntheticProcessRollup2/}, field=TargetProcessId_decimal, key=TargetProcessId_decimal, mode=left)
| table([@timestamp, aid, ComputerName, UserName, DomainName, FileName, CommandLine])
| sort(@timestamp, order=desc)

Looks for: a browser process resolving one of the 7 published second-stage AitM (OneDrive-themed Frameless BitB) domains — a hit here means the user landed on the live credential-harvesting page. FP: none expected.

// HUNT: TA419 - T1557/T1539 - DNS Resolution of Second-Stage AitM Phishing Domain
// HYPOTHESIS: After completing the Cloudflare Turnstile gate, the browser resolves one of the 7 published second-stage AitM domains hosting the Frameless BitB kit.
// CONF: high  FP: low  COST: low | REQUIRES: core Falcon DNS + process telemetry
// LOOKBACK: 90d (set in the Falcon time picker)
#event_simpleName = DnsRequest
| DomainName = /^(globalfileshareplatform\.com|smartsyncbox\.com|mypublicshare\.com|cloudsyncpulse\.com|onecloudfilesync\.com|publicsharefile\.cloud|fileswiftonline\.cloud)$/i
| rename(field=ContextProcessId_decimal, as=TargetProcessId_decimal)
| join(query={#event_simpleName = /ProcessRollup2|SyntheticProcessRollup2/}, field=TargetProcessId_decimal, key=TargetProcessId_decimal, mode=left)
| table([@timestamp, aid, ComputerName, UserName, DomainName, FileName, CommandLine])
| sort(@timestamp, order=desc)

Looks for: reuse of TA419's self-signed VPS certificate (subject/issuer DN C=US, ST=Kansas, L=Millsstad, O=Castro Inc, CN=CI). FP: core Falcon EDR does not natively capture TLS leaf-certificate telemetry — this card only runs where a network-layer source (Zeek/Corelight, firewall TLS inspection, CDN/proxy log) is ingested into NG-SIEM; field/repo names are placeholders until validated against your tenant.

// HUNT: TA419 - Infrastructure Reuse - Self-Signed "Castro Inc" TLS Certificate
// HYPOTHESIS: TA419's mail-sending VPS infrastructure reuses a self-signed cert on a high ephemeral port; reuse elsewhere indicates shared attacker infrastructure.
// CONF: medium  FP: medium  COST: low | REQUIRES: network-layer TLS/certificate telemetry (NOT core Falcon EDR)
// ⚠ TENANT-SPECIFIC: REPLACE_WITH_CERT_REPO and REPLACE_WITH_CERT_SHA256_FIELD are placeholders -- validate the actual repo and field names against your ingested TLS/certificate data source before relying on this query.
// TUNING: confirm the matched session is NOT a known internal TLS-inspection/proxy self-signed cert before escalating -- self-signed certs on non-standard ports have other benign uses (internal tooling, lab systems).
REPLACE_WITH_CERT_REPO
| REPLACE_WITH_CERT_SHA256_FIELD = "b314a1499cd728ca3e54b7150661fd0c7d2279065fe3f570f0f66c395d744460"
| table([@timestamp, REPLACE_WITH_SOURCE_IP_FIELD, REPLACE_WITH_DEST_IP_FIELD, REPLACE_WITH_CERT_SHA256_FIELD])
| sort(@timestamp, order=desc)

Looks for: inbound mail from the 3 attacker-controlled sender addresses or the 4 impersonation domains. FP: exact sender-address match is high-confidence; domain match can false-positive if the tenant has legitimate correspondence with a similarly-named but unrelated organization — manually confirm the sender domain on any domain-only hit.

// HUNT: TA419 - T1566.002/T1036.005 - Attacker Sender Addresses & Impersonation Domains
// HYPOTHESIS: Inbound mail from a TA419-controlled sender address, or a domain impersonating the Heritage Foundation / Japan-Taiwan Exchange Association / Japanese Defense Ministry, lands in a mailbox.
// CONF: medium  FP: medium  COST: low | REQUIRES: Falcon for Email or M365 message trace (NOT core Falcon EDR)
// ⚠ TENANT-SPECIFIC: REPLACE_WITH_EMAIL_REPO, senderAddress, recipientAddress and subject are third-party-ingest parser field names (O365 Management Activity schema), NOT core Falcon EDR fields -- validate against your tenant's actual ingested email-telemetry repo and field names.
// TUNING: for the domain-match branch, exclude any confirmed legitimate partner mailing lists before escalating; exact sender-address hits need no exclusion.
REPLACE_WITH_EMAIL_REPO
| senderAddress = /^(leparker@mail\.com|hcrediker@mail\.com|hcrediker@outlook\.com)$/i or senderAddress = /@(tw-koryu\.org|heritiages\.org|heritiage\.org|shinjirou\.info)$/i
| table([@timestamp, senderAddress, recipientAddress, subject])
| sort(@timestamp, order=desc)

Looks for: per-user sign-in history to spot a non-interactive/token-based sign-in from a new country shortly after a legitimate interactive sign-in — the classic session-cookie-replay signature. FP: VPN egress changes, mobile carrier IP rotation, and legitimate multi-device sign-in can produce the same pattern.

// HUNT: TA419 - T1539 - Session Cookie Replay: Non-Interactive Sign-In From New Country After Interactive Sign-In
// HYPOTHESIS: After a legitimate interactive sign-in, the AitM-captured session cookie is replayed, producing a non-interactive sign-in for the same user from a different country shortly after -- with no fresh MFA challenge.
// CONF: medium  FP: medium  COST: low | REQUIRES: Entra ID sign-in logs (azure_signinlogs) -- NOT core Falcon EDR
// ⚠ TENANT-SPECIFIC: field names follow Microsoft's sign-in log schema (userPrincipalName, ipAddress, isInteractive, authenticationRequirement, location.countryOrRegion); some tenants parse these with a prefix (e.g. azuread.signinlogs.properties.*) -- validate against a sample row before relying on this query.
// TUNING: cross-check any hit against known corporate VPN egress ranges and recent business travel before escalating; collapse results per user and review the two closest-in-time entries for a country/ASN change.
// LOOKBACK: 7d (set in the Falcon time picker)
azure_signinlogs
| groupBy([userPrincipalName], function=[collect([@timestamp, ipAddress, "location.countryOrRegion", isInteractive, authenticationRequirement], limit=200)], limit=5000)
| sort(userPrincipalName, order=asc)

Looks for: a single sign-in token identifier observed from more than one source IP — direct evidence of a stolen session being used from attacker infrastructure alongside the legitimate user. FP: corporate load-balanced egress or carrier-grade NAT can occasionally present as multiple IPs for one session.

// HUNT: TA419 - T1539 - Same Session Token From Two Distinct Source IPs
// HYPOTHESIS: A session/token identifier captured by the AitM proxy is replayed from attacker infrastructure while the legitimate user continues to use the same token -- both source IPs appear against one token in the same window.
// CONF: medium  FP: medium  COST: low | REQUIRES: Entra ID sign-in logs (azure_signinlogs) with a token/session identifier field -- NOT core Falcon EDR
// ⚠ TENANT-SPECIFIC: uniqueTokenIdentifier is Microsoft's documented sign-in log field name; confirm it is populated and not parser-renamed in your tenant.
// TUNING: exclude known NAT/load-balancer egress pools (CGNAT, corporate proxy ranges) before escalating; a DistinctIPs count of exactly 2 with one IP geolocating outside the user's normal country is the highest-confidence case.
// LOOKBACK: 7d (set in the Falcon time picker)
azure_signinlogs
| groupBy([uniqueTokenIdentifier], function=[count(ipAddress, distinct=true, as=DistinctIPs), collect([@timestamp, userPrincipalName, ipAddress, "location.countryOrRegion"], limit=50)], limit=5000)
| DistinctIPs > 1
| sort(DistinctIPs, order=desc)

Looks for: sign-ins satisfied by a single factor (no fresh MFA claim) — on its own this is broad (legitimate CA-trusted-location or remembered-device sign-ins look identical), so it is meant to be reviewed as a corroborating signal alongside Q5/Q6, not escalated alone. FP: high — this is the expected shape of most "remember this device" sign-ins; do not alert on this query in isolation.

// HUNT: TA419 - T1621 - Sign-In Success Without Fresh MFA Challenge
// HYPOTHESIS: A session-cookie-replay sign-in succeeds without the user re-satisfying MFA, because the captured cookie already carries a satisfied authentication claim.
// CONF: low  FP: high  COST: low | REQUIRES: Entra ID sign-in logs (azure_signinlogs) -- NOT core Falcon EDR
// ⚠ TENANT-SPECIFIC: authenticationRequirement values ("singleFactorAuthentication"/"multiFactorAuthentication") follow Microsoft's documented schema -- validate against a sample row in your tenant.
// TUNING: this query alone is NOT actionable -- CA-trusted-location and "remember MFA for N days" sign-ins look identical. Only escalate results that also appear in Q5 or Q6 (new country/ASN, or a token seen from two IPs) in the same time window.
// LOOKBACK: 7d (set in the Falcon time picker)
azure_signinlogs
| authenticationRequirement = "singleFactorAuthentication"
| conditionalAccessStatus = "success"
| groupBy([userPrincipalName], function=[count(as=Hits), collect([@timestamp, ipAddress, "location.countryOrRegion", appDisplayName], limit=50)], limit=5000)
| sort(Hits, order=desc)

Looks for: post-compromise follow-on abuse — an OAuth application consent grant or a new mailbox/transport rule created shortly after a sign-in — common next steps once a session is hijacked. FP: legitimate app onboarding and admin-driven mail-rule changes will also match; corroborate against a flagged user from Q5/Q6/Q7 before escalating.

// HUNT: TA419 - T1098/T1114 (inferred) - Post-Sign-In OAuth Consent Grant or New Mail Rule
// HYPOTHESIS: Following a successful session-cookie-replay sign-in, the attacker grants an OAuth app consent or creates a mail-forwarding/inbox rule to persist access to mailbox content.
// CONF: medium  FP: medium  COST: low | REQUIRES: Entra ID / Exchange audit logs (azure_auditlogs) -- NOT core Falcon EDR
// ⚠ TENANT-SPECIFIC: operationName is an Entra/Exchange audit parser field, not a core Falcon EDR field; it and its activity-name values ("Consent to application", "Add delegated permission grant", "New-InboxRule") follow Microsoft's documented audit-log schema -- validate against a sample row in your tenant.
// TUNING: exclude known IT-managed app deployment windows and admin-initiated mail-rule changes (check the Actor field against your IT admin group) before escalating.
// LOOKBACK: 7d (set in the Falcon time picker)
azure_auditlogs
| operationName = /^(Consent to application|Add app role assignment|Add delegated permission grant|New-InboxRule|Set-Mailbox)$/i
| table([@timestamp, userPrincipalName, operationName, appDisplayName])
| sort(@timestamp, order=desc)

Looks for: the same host resolving a generic public URL shortener and, separately, a published second-stage AitM domain — approximating the "reply → shortener → fake OneDrive" behavioral chain at the DNS layer. The shortener list is a generic set of widely-abused public services, not TA419-specific indicators. FP: medium — the join is scoped by host (aid) only, not a time window, so confirm the two timestamps are close together before escalating; *confidence is high only when both conditions genuinely correlate in time for the same user.

// HUNT: TA419 - Behavioral Pivot - Shortener Resolution + Non-Microsoft OneDrive-Themed Landing
// HYPOTHESIS: A user replies to an unsolicited external email, resolves a URL shortener, then lands on one of the 7 published TA419 second-stage AitM domains -- the attack chain's distinctive DNS fingerprint.
// CONF: high when both events correlate in time for one host; FP: medium  COST: low | REQUIRES: core Falcon DNS telemetry
// TUNING: this join is scoped by aid only (no in-query time window) -- manually confirm @timestamp and AitMTimestamp are within the same browsing session (minutes, not days) before treating a hit as a true positive. Shorteners have legitimate business use on their own.
// LOOKBACK: 30d (set in the Falcon time picker)
#event_simpleName = DnsRequest
| DomainName = /^(bit\.ly|tinyurl\.com|rebrand\.ly|cutt\.ly|is\.gd|t\.co|shorturl\.at)$/i
| select([@timestamp, aid, ComputerName, UserName, DomainName])
| join(query={
    #event_simpleName = DnsRequest
    | DomainName = /^(globalfileshareplatform\.com|smartsyncbox\.com|mypublicshare\.com|cloudsyncpulse\.com|onecloudfilesync\.com|publicsharefile\.cloud|fileswiftonline\.cloud)$/i
    | rename(field=DomainName, as=AitMDomain)
    | rename(field=@timestamp, as=AitMTimestamp)
    | select([aid, AitMDomain, AitMTimestamp])
  }, field=aid, key=aid, mode=inner)
| table([@timestamp, aid, ComputerName, UserName, DomainName, AitMDomain, AitMTimestamp])
| sort(@timestamp, order=desc)