Skip to content

[New Rule] Entra ID AiTM Phishing-Kit Chain Detected#6359

Open
terrancedejesus wants to merge 2 commits into
mainfrom
new-rule/entra-id-aitm-phishing-kit-chain-detected
Open

[New Rule] Entra ID AiTM Phishing-Kit Chain Detected#6359
terrancedejesus wants to merge 2 commits into
mainfrom
new-rule/entra-id-aitm-phishing-kit-chain-detected

Conversation

@terrancedejesus

Copy link
Copy Markdown
Contributor

Pull Request

Issue link(s):

Summary - What I changed

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.

Screenshot 2026-06-30 at 9 49 44 AM

How To Test

Query can be used in TRADE stack.

Checklist

  • Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
  • Added the meta:rapid-merge label if planning to merge within 24 hours
  • Secret and sensitive material has been managed correctly
  • Automated testing was updated or added to match the most common scenarios
  • Documentation and comments were added for features that require explanation

Contributor checklist

@github-actions

Copy link
Copy Markdown
Contributor

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

  • Detailed description of the rule.
  • List any new fields required in ECS/data sources.
  • Link related issues or PRs.
  • Include references.

Rule Metadata Checks

  • creation_date matches the date of creation PR initially merged.
  • min_stack_version should support the widest stack versions.
  • name and description should be descriptive and not include typos.
  • query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
  • min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
  • index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
  • integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
  • setup should include the necessary steps to configure the integration.
  • note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
  • tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
  • threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

  • building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
  • bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

  • Provide evidence of testing and detecting the expected threat.
  • Check for existence of coverage to prevent duplication.

Copilot AI review requested due to automatic review settings July 6, 2026 13:31

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new Microsoft Entra ID detection rule intended to identify an AiTM phishing-kit post-compromise persistence chain by correlating broker sign-in to Device Registration Service, device registration activity, and subsequent PRT-based access to other resources.

Changes:

  • Introduces a new EQL sequence rule correlating Sign-In Logs and Audit Logs for a suspected device-registration → PRT-use chain.
  • Adds an investigation guide with triage steps, false-positive guidance, and response actions.
  • Adds ATT&CK mappings and tags for identity compromise / persistence behavior.

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
type = "eql"

query = '''
sequence with maxspan=3m
Comment on lines +91 to +93
"Tactic: Persistence",
"Tactic: Credential Access",
"Resources: Investigation Guide",
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants