« Azure AKS API Server Proxying Request to Kubelet Entra ID Multiple Device Registrations by a Single User »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.28

Entra ID AiTM Phishing-Kit Chain Detected

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID AiTM Phishing-Kit Chain Detected

edit

Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover.

Rule type: eql

Rule indices:

  • logs-azure.signinlogs-*
  • logs-azure.auditlogs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-15m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Sign-In Logs
  • Data Source: Microsoft Entra ID Audit Logs
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Entra ID AiTM Phishing-Kit Chain Detected

This rule correlates three events for the same user within a 10-minute window that together represent the canonical post-AiTM identity-compromise chain:

  1. A non-interactive sign-in through the Microsoft Authentication Broker (MAB) client (app_id 29d9ed98-a469-4536-ade2-f981bc1d605e) to the Device Registration Service resource, with an unbound session token (token_protection_status_details.sign_in_session_status).
  2. A successful Register device audit event initiated by the same user for a target device named DESKTOP-*.
  3. An interactive sign-in using a primaryRefreshToken (PRT) to a resource other than the Device Registration Service, from an unmanaged device.

After an AiTM kit captures a victim session, it registers an Azure AD-joined device to obtain a device-bound PRT. Because the PRT is bound to the device rather than the user session, it survives revokeSignInSessions and password resets, providing durable, MFA-free access. Observing the broker-to-DRS auth, the registration, and the first PRT use in quick succession is strong evidence of active account takeover rather than benign onboarding.

Possible investigation steps

  • Identify the user via azure.signinlogs.properties.user_principal_name / azure.signinlogs.properties.user_id and the registered device via the Register device event (azure.auditlogs.properties.target_resources.0.display_name). Default DESKTOP-<random> names that do not match your convention are suspicious.
  • Review the source of each step: source.ip, source.as.organization.name, and source.geo.*. Hosting/VPS ASNs (for example Tencent or Alibaba) and unexpected geographies, or a single source driving all three steps, are high-fidelity suspicious.
  • Inspect the registration user agent on the Register device event (azure.auditlogs.properties.userAgent); a spoofed Dsreg/10.0 (Windows <build>) string or a raw HTTP client such as axios/* or python-requests/* indicates tooling.
  • Confirm the PRT step: azure.signinlogs.properties.incoming_token_type is primaryRefreshToken, the device trust_type is Azure AD joined, and device_detail.is_managed is false (unmanaged), and the resource_display_name is a real resource (Microsoft Graph, Office 365 Exchange Online, etc.) rather than the Device Registration Service.
  • Check for additional persistence established in the same window: an attacker-registered MFA method (User registered security info), multiple device registrations by the same user, or broker tokens minted for other resources.
  • Review Conditional Access outcomes to determine whether device compliance or MFA was bypassed.

False positive analysis

  • Legitimate Azure AD join / device onboarding can produce a broker-to-DRS auth followed by PRT issuance. Validate the device against inventory and confirm it is managed/compliant and registered from an expected source.
  • Authorized security assessments that register devices and exercise PRTs will match. Document and add scoped exceptions.

Response and remediation

  • Treat as likely account takeover. Remove the rogue device registration BEFORE revoking sessions, because device-bound PRTs survive revokeSignInSessions and a device left in place re-establishes access.
  • GET /v1.0/users/{id}/registeredDevices and /ownedDevices, then DELETE /v1.0/devices/{deviceObjectId} for unrecognized devices.
  • Revoke refresh tokens and sessions, then reset credentials and re-register MFA.
  • POST /v1.0/users/{id}/revokeSignInSessions.
  • Temporarily disable the account if activity must be halted during investigation.
  • PATCH /v1.0/users/{id} with body {"accountEnabled": false}.
  • Remove other attacker persistence: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents.
  • Tighten device registration and join controls via Conditional Access (restrict who can register/join devices, require MFA for registration, and require a compliant/managed device for resource access).

Rule query

edit
sequence with maxspan=3m
  [authentication where
    data_stream.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.resource_display_name == "Device Registration Service" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ] by azure.signinlogs.properties.user_id
  [any where
    data_stream.dataset == "azure.auditlogs" and
    azure.auditlogs.operation_name == "Register device" and
    azure.auditlogs.properties.initiated_by.user.id != null and
    azure.auditlogs.properties.target_resources.`0`.display_name like "DESKTOP-*" and
    event.outcome == "success"
  ] by azure.auditlogs.properties.initiated_by.user.id
  [authentication where
    data_stream.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" and
    azure.signinlogs.properties.is_interactive == true and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.properties.device_detail.is_managed != true and
    azure.signinlogs.result_signature == "SUCCESS"
  ] by azure.signinlogs.properties.user_id

Framework: MITRE ATT&CKTM

« Azure AKS API Server Proxying Request to Kubelet Entra ID Multiple Device Registrations by a Single User »