[New] Remediate Identity - Suspected Phishing Kit or AiTM Compromise

[terrancedejesus]

Summary

Adds an example identity response workflow that investigates and contains a suspected AiTM or phishing-kit compromise. It mirrors the endpoint Remediate ... response templates and is kit-agnostic so it responds to the attacker objective (session, refresh-token, or OAuth theft), not a specific kit (Tycoon, Kali365, etc.).

How it works

1. Correlation (ES|QL over .alerts-security.alerts-*): identifies victims from open alerts raised by the Entra AiTM / phishing-kit detection rules, matched by stable rule_id. Returns the UPN plus indicators (source IP, ASN, user agent, triggering rules, alert count).
2. Corroboration (ES|QL over logs-azure.auditlogs-*): counts recent post-authentication persistence artifacts (auth-method registration, OAuth consent, device registration). This count gates hard containment.
3. Case: opens a Security case with the indicators.
4. Soft containment (automatic, reversible): revokeSignInSessions and confirmCompromised.
5. Hard containment (analyst-approved, corroboration-gated): delete registered and owned device objects, disable the account, revoke OAuth grants, re-revoke sessions.
6. Validation: confirms the revoke artifact and that no devices remain; posts an outcome comment with the remediated-artifact indicators (device IDs/names, OAuth grant IDs).

Triggers

manual (attach as a custom action on the detection rules) and scheduled (every 15m). Both run the same rule_id-filtered correlation.

Graph access

All writes go through the microsoft-graph HTTP connector (OAuth 2.0 client credentials). No inline credentials.

Prerequisites

• HTTP connector microsoft-graph: base URL https://graph.microsoft.com/v1.0, OAuth 2.0 client credentials, scope https://graph.microsoft.com/.default.
• Entra ID App permissions for HTTP connector client (admin-consented): User.ReadWrite.All, Device.ReadWrite.All, DelegatedPermissionGrant.ReadWrite.All, IdentityRiskyUser.ReadWrite.All.
• Keep the correlation_esql rule_id set in sync with the tenant's installed Entra AiTM / phishing-kit rules.

Correlated detection rules (13, rules/integrations/azure)

rule_id	Rule
d2c02b2b-bd01-4d4a-a17a-8df8f357b015	AiTM Phishing-Kit Chain Detected
e5420ced-bc42-4783-a8df-99320567e090	OAuth Device Code Phishing via AiTM
6e6376c1-a71e-4789-a795-198b05664064	Potential AiTM Sign-In via OfficeHome (Tycoon2FA)
4b11dbab-ce37-49c4-bdf1-cdf64b405d96	Kali365 Default User-Agent Detected
14fa0285-fe78-4843-ac8e-f4b481f49da9	OAuth Phishing via First-Party Microsoft Application
4f95e0f8-18b7-459a-b8b5-b2f5c94bf6eb	MS Auth Broker Sign-In to Unusual Resource
a83b3dac-325a-11ef-b3e6-f661ea17fbce	OAuth Device Code Grant by MS Auth Broker
af22d970-7106-45b4-b5e3-460d15333727	OAuth Device Code Grant by Unusual User
375132c6-25d5-11f0-8745-f661ea17fbcd	OAuth Flow by MS Auth Broker to DRS
82629eed-5516-446e-ad73-03b8c4f4d571	Device Registration with Phishing Kit Default OS Build
d4695889-0410-4e7b-a4aa-59be525a11a6	Register Device with Unusual User Agent
90efea04-5675-11f0-8f80-f661ea17fbcd	Unusual Cloud Device Registration
960b1cef-f94d-4150-863d-b1dc311739de	Multiple Device Registrations by a Single User

Design notes

• Correlates on rule_id (deployment-stable), not rule.uuid.
• Corroboration matches the victim across initiated_by and target_resources[0..2] because audit logs lack ECS user.name and the victim's position varies by operation.
• Device deletion runs before session revocation, since a device-bound PRT survives revokeSignInSessions in Entra ID.
• Lookback windows (correlation 1h, corroboration 6h) are sized for audit-log ingestion lag but can be reduced if needed.
• Idempotency guard skips users with an open aitm-containment case.
• Connector query parameters use query, not path (the connector encodes the path).

Testing

Validated end to end in the Elastic Workflows engine against TRADE research tenant. Involved emulating the kit triggers (Kali365 user-agent sign-in and phishing-kit device registration) to raise real detection-rule alerts, then ran the workflow via the manual trigger. Confirmed correlation, corroboration, case creation with indicators, soft containment, the approval gate, hard containment (device deleted, account disabled, OAuth grant revoked, sessions revoked), and the validation comment showing registered devices = 0.