Anomalous Single Factor Signin

Hunt Hypothesis

Successful sign-ins using single factor authentication from anomalous devices, locations, and ASN indicators may indicate compromised credentials being used to access sensitive accounts. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential credential theft and lateral movement attempts early.

KQL Query

let known_locations = (SigninLogs
  | where TimeGenerated between(ago(7d)..ago(1d))
  | where ResultType == 0
  | extend LocationDetail = strcat(Location, "-", LocationDetails.state)
  | summarize by LocationDetail);
let known_asn = (SigninLogs
  | where TimeGenerated between(ago(7d)..ago(1d))
  | where ResultType == 0
  | summarize by AutonomousSystemNumber);
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where isempty(DeviceDetail.deviceId)
| where AuthenticationRequirement == "singleFactorAuthentication"
| extend LocationParsed = parse_json(LocationDetails), DeviceParsed = parse_json(DeviceDetail)
| extend City = tostring(LocationParsed.city), State = tostring(LocationParsed.state)
| extend LocationDetail = strcat(Location, "-", State)
| extend DeviceId = tostring(DeviceParsed.deviceId), DeviceName=tostring(DeviceParsed.displayName), OS=tostring(DeviceParsed.operatingSystem), Browser=tostring(DeviceParsed.browser)
| where AutonomousSystemNumber !in (known_asn) and LocationDetail !in (known_locations)
| project TimeGenerated, Type, UserId, UserDisplayName, UserPrincipalName, IPAddress, Location, State, City, ResultType, ResultDescription, AppId, AppDisplayName, AuthenticationRequirement, ConditionalAccessStatus, ResourceDisplayName, ClientAppUsed, Identity, HomeTenantId, ResourceTenantId, Status, UserAgent, DeviceId, DeviceName, OS, Browser, MfaDetail
| extend Name = tostring(split(UserPrincipalName,'@',0)[0]), UPNSuffix = tostring(split(UserPrincipalName,'@',1)[0])

Analytic Rule Definition

id: f7c3f5c8-71ea-49ff-b8b3-148f0e346291
name: Anomalous Single Factor Signin
description: |
  'Detects successful signins using single factor authentication where the device, location, and ASN are abnormal.
   Single factor authentications pose an opportunity to access compromised accounts, investigate these for anomalous occurrencess.
   Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-devices#non-compliant-device-sign-in'
severity: Low
requiredDataConnectors:
  - connectorId: AzureActiveDirectory
    dataTypes:
      - SigninLogs
queryFrequency: 1d
queryPeriod: 7d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - InitialAccess
relevantTechniques:
  - T1078.004
tags:
  - AADSecOpsGuide
query: |
  let known_locations = (SigninLogs
    | where TimeGenerated between(ago(7d)..ago(1d))
    | where ResultType == 0
    | extend LocationDetail = strcat(Location, "-", LocationDetails.state)
    | summarize by LocationDetail);
  let known_asn = (SigninLogs
    | where TimeGenerated between(ago(7d)..ago(1d))
    | where ResultType == 0
    | summarize by AutonomousSystemNumber);
  SigninLogs
  | where TimeGenerated > ago(1d)
  | where ResultType == 0
  | where isempty(DeviceDetail.deviceId)
  | where AuthenticationRequirement == "singleFactorAuthentication"
  | extend LocationParsed = parse_json(LocationDetails), DeviceParsed = parse_json(DeviceDetail)
  | extend City = tostring(LocationParsed.city), State = tostring(LocationParsed.state)
  | extend LocationDetail = strcat(Location, "-", State)
  | extend DeviceId = tostring(DeviceParsed.deviceId), DeviceName=tostring(DeviceParsed.displayName), OS=tostring(DeviceParsed.operatingSystem), Browser=tostring(DeviceParsed.browser)
  | where AutonomousSystemNumber !in (known_asn) and LocationDetail !in (known_locations)
  | project TimeGenerated, Type, UserId, UserDisplayName, UserPrincipalName, IPAddress, Location, State, City, ResultType, ResultDescription, AppId, AppDisplayName, AuthenticationRequirement, ConditionalAccessStatus, ResourceDisplayName, ClientAppUsed, Identity, HomeTenantId, ResourceTenantId, Status, UserAgent, DeviceId, DeviceName, OS, Browser, MfaDetail
  | extend Name = tostring(split(UserPrincipalName,'@',0)[0]), UPNSuffix = tostring(split(UserPrincipalName,'@',1)[0])
entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: UserPrincipalName
      - identifier: Name
        columnName: Name
      - identifier: UPNSuffix
        columnName: UPNSuffix
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: IPAddress
  - entityType: CloudApplication
    fieldMappings:
      - identifier: AppId
        columnName: AppId
      - identifier: Name
        columnName: AppDisplayName
version: 1.0.6
kind: Scheduled
metadata:
    source:
        kind: Community
    author:
        name: Pete Bryan
    support:
        tier: Community
    categories:
        domains: [ "Security - O

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Technique: T1078.004 — T1078.004

References

• Source Query

False Positive Guidance

• Scenario: Scheduled Job Execution via Single Factor Authentication
  Description: A legitimate scheduled job (e.g., using cron on Linux or Task Scheduler on Windows) may authenticate using single factor to access a service or database.
  Filter/Exclusion: Check for known scheduled job processes (e.g., cron, systemd, task scheduler), or filter by user accounts associated with automation (e.g., svc-automation, svc-dbbackup).

• Scenario: Admin Task via Remote Desktop or SSH
  Description: An administrator may use single factor authentication to log in via Remote Desktop (RDP) or SSH to perform maintenance tasks.
  Filter/Exclusion: Filter by IP addresses associated with internal network segments, or include user accounts with administrative privileges (e.g., admin, root, domainadmin).

• Scenario: User Accessing Cloud Service via API Key
  Description: A user may authenticate using an API key (single factor) to access a cloud service (e.g., AWS, Azure) for automation or monitoring.
  Filter/Exclusion: Filter by known API key users (e.g., api-user, monitoring-service) or by service names (e.g., aws-sdk, azure-cli).

• Scenario: Temporary Access for Third-Party Tools
  Description: A third-party tool (e.g., Datadog, New Relic) may use single factor authentication to access internal systems for monitoring or logging.
  Filter/Exclusion: Filter by known third-party service accounts (e.g., datadog, newrelic) or by IP ranges associated with those services.

• Scenario: User Accessing Legacy System via Single Factor
  Description: A user may authenticate using single factor to access a legacy system (e.g., `mainframe