Identity — Foreign IPv6 Sign-In Blocked (Pakistan)
Sign-in attempt from a Pakistani IPv6 blocked by Conditional Access (Invalid Password). A partial prior Pakistani baseline complicated the analysis, but an independent AADUserRiskEventsTable flag drove the escalation decision. Account disabled. Post-incident, the user confirmed they were physically in the UK at the time — conclusively reclassifying this as a true positive: a malicious actor with compromised credentials. Prior Pakistani baseline events may themselves represent earlier credential testing.
This incident is the most analytically complex identity alert in this portfolio. It introduces a scenario that tests the limits of baseline-based anomaly detection: a partial prior foreign baseline that partially legitimises the alert, combined with an independent risk signal that ultimately drives the correct escalation decision.
Azure AD Identity Protection's unfamiliar sign-in detection compares the current sign-in's seven properties against a 30-day rolling baseline. The complicating factor here is that the user's baseline contained 5 prior Pakistani sign-ins — meaning Pakistan was not a novel location. This required a more nuanced assessment than a clean foreign-IP scenario: the question was not simply "is this location unfamiliar?" but "is the specific IP novel, and are there independent risk signals that corroborate escalation?"
The Independent AADUserRiskEventsTable event — generated by Azure AD's ML model separately from the Sentinel alert — was the analytical tiebreaker. Two independent detection systems flagging the same account simultaneously is not a coincidence to dismiss. This principle — when baseline analysis is ambiguous, look for a second independent signal — is one of the most important lessons in this portfolio.
The source IPv6 address [REDACTED_IPv6] falls in a prefix range associated with Pakistani internet infrastructure, geolocated to Karachi. Recorded Future enrichment returned an indeterminate score — the address is not catalogued in known threat feeds, which is expected for residential or mobile carrier IPv6 space in emerging markets.
The 30-day baseline presented genuine ambiguity: 77 sign-ins from Birmingham, UK ([CLIENT_IP]) alongside 5 sign-ins from the same Pakistani IPv6 range. The 5 prior Pakistani sign-ins suggest the user may have legitimate personal connections to Pakistan — however, the current alert was generated independently by Identity Protection and the specific IPv6 address was novel (not present in any of the 5 prior events).
The sign-in was blocked at two independent layers: Conditional Access (device or location compliance not met) and Invalid Password (the password provided was incorrect). The Invalid Password failure is analytically significant — it suggests the attacker either had a stale credential or was credential stuffing.
A risky event was recorded in the AADUserRiskEventsTable independently of the Sentinel alert. Two independent detection systems flagging the same account at the same time was the deciding factor for escalation over the ambiguous partial baseline.
Post-incident, the user confirmed they were physically in the UK at the time of the sign-in attempt. This conclusively reclassifies the incident as a true positive: the Pakistani IPv6 access was an unauthorised actor attempting to authenticate using compromised credentials. The prior 5 Pakistani sign-ins in the baseline may themselves represent earlier credential testing activity that was not independently flagged.
| Type | Indicator | Notes |
|---|---|---|
| IPv6 Address | [REDACTED_IPv6] | Pakistan, Karachi — RF Score: Indeterminate |
| Device | Android — unregistered (not Entra/Intune enrolled) | Non-managed device — consistent with attacker using personal or emulated Android |
| Sign-in Time | 05:55 UTC, 30 Nov 2025 | Early morning UK time — outside standard business hours |
| Block Mechanism | Conditional Access + Invalid Password | Two-layer block — no access achieved |
| Risk Signal | AADUserRiskEventsTable Count: 1 | Independent Identity Protection ML risk event — second data point driving escalation |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Credential Access | Brute Force: Password Guessing / Credential Stuffing | T1110.001 / T1110.004 | Invalid password — credentials stale or guessed; possible credential stuffing |
| Initial Access | Valid Accounts: Cloud Accounts | T1078.004 | Attempted sign-in using compromised credentials to cloud account |
| Defense Evasion | Use Non-Standard Port / Anonymisation | T1571 | Sign-in from IPv6 on unregistered Android — possible evasion of device-based controls |
// Full 30-day baseline including prior Pakistani sign-ins
SigninLogs
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated > ago(30d)
| summarize Count=count() by IPAddress, Location, CountryOrRegion
| order by Count desc
// Confirm independent risk event in Identity Protection
AADUserRiskEvents
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated > ago(7d)
| project TimeGenerated, RiskEventType, RiskLevel, IpAddress, AdditionalInfo
// Confirm no successful sign-ins from Pakistan in 7-day window
SigninLogs
| where UserPrincipalName == "[USER_UPN]"
| where CountryOrRegion == "PK"
| where TimeGenerated > ago(7d)
| where ResultType == 0
| project TimeGenerated, IPAddress, ResultType, AppDisplayNameThe 5 prior Pakistani sign-ins in the baseline made this the most analytically complex identity alert in this portfolio. The key decision: escalate as caution vs close with monitoring.
The independent AADUserRiskEventsTable flag was the deciding factor. When baseline analysis is ambiguous, look for a second independent signal — this is the core lesson.
Post-incident, the user confirmed they were physically in the UK. The Pakistani access was a malicious actor with compromised credentials. The prior 5 Pakistani events may themselves represent earlier credential testing. Client's swift disablement was correct.