Identity — Egypt VPN Sign-In (SLA Gap documented)
Egyptian IP (TE Data / AS8452 — documented VPN exit) against a 100% London baseline with zero prior foreign activity. Probable VPN usage but escalated as caution due to complete baseline departure. Six-day client response delay is the primary operational finding of this case. Session revoked and forced password reset applied at closure.
TE Data (AS8452) is Egypt's largest internet service provider, offering residential, commercial, and data centre internet services. Its IP ranges are documented as VPN exit nodes for several commercial VPN services, making Egyptian TE Data IPs a common false-positive source in sign-in anomaly detection. The source IP returned an RF Score of 0 — no threat intelligence community has flagged it for malicious use, consistent with a clean ISP address used as a VPN exit.
Despite this context, the correct triage decision here is escalation as caution rather than silent closure. "Probably legitimate" is not "confirmed legitimate," and a 100% London baseline with zero prior foreign activity over 30 days makes any foreign IP a complete baseline departure — regardless of the IP's risk score. The baseline departure is the primary analytical signal; the RF Score 0 is contextual, not exculpatory.
The six-day client response time is the headline operational finding of this case. If Conditional Access had not been blocking the suspicious sign-in, a six-day window of potential account compromise while the client formulated their response would be operationally unacceptable. This incident is a direct argument for automated risk-based CA remediation policies that operate independently of analyst escalation and client response times.
The user's 30-day sign-in baseline showed exclusively London-based activity: [CLIENT_IP] accounting for 46 combined sign-ins from two IP variants, all geolocating to Greater London. This represents a 100% UK-only baseline with no prior foreign activity of any kind — the cleanest possible baseline departure scenario.
The Conditional Access policies successfully blocked the sign-in at the time of detection. No corporate resources were accessed. The blocking mechanism functioned as designed and provided passive protection throughout the subsequent six-day period before client confirmation — but passive protection is not a substitute for active remediation.
TE Data (AS8452) is Egypt's largest telecommunications provider whose IP ranges appear in multiple commercial VPN provider exit node reports, suggesting the sign-in likely originated from a user routing traffic through an Egyptian VPN exit. However, VPN usage is not confirmed — it is assessed as probable. The analytical position is: probable VPN, but the correct action is the same regardless of root cause: escalate, seek confirmation, apply session revocation and password reset.
The two-day and seven-day automation follow-ups maintained escalation pressure during the non-response period. Without automated follow-up, this ticket could have remained unacknowledged indefinitely. The client's confirmed response — session revocation followed by forced password reset — represents the correct and conservative approach. Session revocation invalidates all active access and refresh tokens across all authenticated sessions. The forced password reset ensures the credential cannot be reused if it was exposed.
The KQL retrospective query reviewing all sign-in attempts during the six-day window is analytically important: it demonstrates that CA blocked all attempts during the open period, providing both reassurance and a compelling argument for why automated remediation policies would eliminate this class of response-lag risk.
| Type | Indicator | Notes |
|---|---|---|
| IP Address | [REDACTED_IP] | Egypt, Cairo — TE Data; RF Score: 0; documented VPN exit |
| Geolocation | Africa, Egypt, Cairo | 100% baseline departure — user history exclusively Greater London |
| ISP / VPN Exit | TE Data | Egyptian national ISP — ranges documented as VPN exit nodes |
| Baseline | [CLIENT_IP] (Greater London) | 46 sign-ins from two London IP variants — consistent 100% UK-only pattern |
| Response Lag | 6 days from escalation to confirmed remediation | PRIMARY FINDING — client SLA gap; to be raised formally at next service review |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Initial Access | Valid Accounts: Cloud Accounts | T1078.004 | Sign-in attempt with potentially valid credentials from foreign VPN exit infrastructure |
| Defense Evasion | Proxy / VPN | T1090 | TE Data / VPN infrastructure used as exit — obscures true geographic origin |
// Confirm full 30-day baseline and complete baseline departure
SigninLogs
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated > ago(30d)
| summarize Count=count() by IPAddress, Location, CountryOrRegion
| order by Count desc
// Review all sign-in attempts during the 6-day open window
SigninLogs
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated between (datetime(2025-12-02T12:34:00Z) .. datetime(2025-12-08T13:00:00Z))
| project TimeGenerated, IPAddress, Location, ResultType, ConditionalAccessStatus, AppDisplayName
// Verify no successful sign-ins slipped through CA during open window
SigninLogs
| where UserPrincipalName == "[USER_UPN]"
| where TimeGenerated > datetime(2025-12-02T12:34:00Z)
| where ResultType == 0
| project TimeGenerated, IPAddress, Location, AppDisplayName, ConditionalAccessStatusThe 6-day response time is the headline finding. If this had been a genuine credential compromise, the attacker would have had nearly a week to attempt further access — and Conditional Access was the only barrier.
The KQL retrospective query demonstrating CA-blocked attempts during the 6-day window is important — it's both reassuring and a compelling argument for why automated remediation policies would eliminate this class of response-lag risk.
RF Score 0 is not a benign signal — a 100% London baseline with zero prior foreign activity is significant regardless. Client SLA gap should be raised formally in the next service review.