Identity — 7-Property Anomaly (No Device ID)
Microsoft Sentinel generated an alert for unfamiliar sign-in properties associated with a service-type user account. The sign-in occurred from a UK-based IP with no prior history in the user's 30-day baseline and no Device ID. All seven sign-in properties were simultaneously unfamiliar. No self-remediation event observed. RF Score indeterminate. Escalated as caution — client confirmed account disabled as precautionary measure. No compromise confirmed.
Azure AD Identity Protection's unfamiliar sign-in detection flags when a sign-in's properties deviate from a user's established 30-day baseline. Seven properties are assessed simultaneously: ASN, Browser, Device, IP, Location, EASId (Exchange Active Sync ID), and TenantIPsubnet. When all seven are simultaneously unfamiliar, Identity Protection generates a maximum-confidence anomaly signal.
Service accounts present a heightened risk profile in this scenario. Unlike regular user accounts — where some variation in sign-in properties may reflect travel, home working, or device changes — service accounts exhibit fundamentally static, predictable access patterns. They sign in from fixed infrastructure on scheduled intervals. Any deviation from this pattern is inherently suspicious and warrants escalation.
The absence of a Device ID is a particularly meaningful signal in a managed Microsoft 365 environment. In such environments, corporate devices enrolled in Entra ID or Intune carry a Device ID in every sign-in event. Its absence indicates either an unregistered personal device or — in an attack scenario — an attacker using a clean machine specifically to avoid device fingerprint detection.
The affected account's 30-day sign-in summary showed a consistent and stable baseline: the vast majority of sign-ins originated from two known IP addresses geolocating to Greater London or a Home Counties location consistent with the organisation's office footprint.
The alert IP (176[.]251[.]176[.]XXX) returned no Recorded Future intelligence — RF Score: Indeterminate, Location: Not Available, ASN: Not Available. The absence of any threat intelligence data does not indicate safety; it suggests the IP has not been observed in threat feeds, which is common for newly provisioned infrastructure, residential connections, or proxies not yet reported to intelligence communities.
The sign-in had no associated Device ID. In Azure AD, a Device ID is present when the sign-in occurs from a device that has been Entra-joined, Intune-registered, or compliant with MDM policy. The absence indicates one of: (a) a personal unregistered device, (b) a browser-based sign-in from a non-managed device, or (c) an attacker using a clean machine or virtual environment to avoid device fingerprint detection.
All seven unfamiliar sign-in property indicators were simultaneously flagged — this represents a maximum-unfamiliarity configuration. There is no single known attribute to provide contextual confidence in the legitimacy of the sign-in.
No risky events were recorded in the AADUserRiskEventsTable for this account prior to this event. No self-remediation actions were logged (no password reset, no MFA challenge response, no session block). In cases where a user is notified of suspicious activity, a self-remediation event typically follows. Its absence suggests the account owner was unaware of the sign-in attempt, further reducing the probability this was a legitimate user action.
The IP geolocated within the UK, which marginally reduces the probability of a geographically distant attack, but does not rule out the use of a UK-based VPN, residential proxy, or compromised intermediary host.
| Type | Indicator | Notes |
|---|---|---|
| IP Address | 176[.]251[.]176[.]XXX | RF Score: Indeterminate — no location or ASN data available |
| Session Anomaly | No Device ID present | Sign-in from unregistered or non-compliant device |
| Session Anomaly | All 7 sign-in properties unfamiliar | ASN, Browser, Device, IP, Location, EASId, TenantIPsubnet — maximum-unfamiliarity event |
| Account | [SERVICE ACCOUNT — REDACTED] | Service or shared-function account type |
| Time | 17:54 UTC, 09 Dec 2025 | Evening sign-in — outside standard business hours |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Initial Access | Valid Accounts: Cloud Accounts | T1078.004 | Sign-in using valid credentials from anomalous IP with no device registration |
| Defense Evasion | Use Alternate Authentication Material | T1550 | No registered device suggests clean machine or virtual environment to avoid device fingerprint detection |
| Discovery | Account Discovery: Cloud Account | T1087.004 | If successful, service account access could enable tenant enumeration |
// 30-day sign-in baseline for service account
SigninLogs
| where UserPrincipalName == "[SERVICE_ACCOUNT_UPN]"
| where TimeGenerated > ago(30d)
| summarize Count=count() by IPAddress, Location,
DeviceId = tostring(DeviceDetail.deviceId), ASN = tostring(NetworkLocationDetails)
| order by Count desc
// Confirm all 7 unfamiliar properties on the alert event
AADUserRiskEvents
| where UserPrincipalName == "[SERVICE_ACCOUNT_UPN]"
| where TimeGenerated > ago(7d)
| project TimeGenerated, RiskEventType, RiskLevel, IpAddress, Location, AdditionalInfo
// Confirm no self-remediation events post-alert
AuditLogs
| where TimeGenerated > datetime(2025-12-09T17:54:00Z)
| where InitiatedBy.user.userPrincipalName == "[SERVICE_ACCOUNT_UPN]"
| where OperationName in ("Change user password","Reset user password","Revoke all refresh tokens for user")
| project TimeGenerated, OperationName, ResultThe combination of a completely unfamiliar IP (no RF context, no ASN), zero Device ID, and no self-remediation event was sufficient to treat this as a potential account compromise. Service accounts do not exhibit variable sign-in behaviour by design — their access patterns are predictable. Any deviation, especially outside business hours, warrants immediate escalation.
The IP geolocated within the UK, which marginally reduces the probability of a geographically distant nation-state attack, but does not rule out the use of a UK-based VPN, residential proxy, or compromised intermediary host as an anonymisation layer.
Client's account disablement was correct. The recommended Conditional Access changes would prevent this class of alert from requiring analyst escalation in future — automated containment is the right long-term answer here.