Before
Analysts likely reviewed failed sign-in alerts one by one, removed duplicate events, extracted affected users and IP addresses, and manually counted failure types. They also searched sign-in history for related activity, reviewed Conditional Access details, assembled the findings into a notification, and handed the incident to someone who could perform account remediation.
How it works
- Receive a failed sign-in event batch, remove duplicate events, extract the relevant artifacts, calculate the event timeframe, and classify the failure patterns.
- Search the flagged IP address across the previous seven days and the event timeframe, then branch based on whether matching or successful sign-ins are found and enrich the alert with available details.
- Send a Teams card containing the investigation results and human-selected options to lock the account, reset the password, or close the alert.
Workflow details
- Event ingestion and deduplication: A webhook receives a batch of failed sign-in events from Microsoft Purview. The workflow removes duplicate events based on their event identifiers before continuing the investigation.
- Incident profiling: The workflow extracts affected users, client IP addresses, user agents, event timestamps, and event types. It calculates the event timeframe and counts failed sign-in attempts, including basic authentication-related failures and multi-factor authentication failures.
- Historical sign-in analysis: The flagged IP address is searched in sign-in history covering the previous seven days. When matching activity exists, the workflow checks for successful sign-ins, identifies the latest relevant activity, and extracts additional sign-in details and successfully applied Conditional Access policies.
- Timeframe validation: The workflow separately checks whether the flagged IP address produced successful sign-ins during the failed-event timeframe. The notification is populated with either the matching successful sign-in context or a clear indication that no successful sign-in was detected.
- Actionable notification: A Teams adaptive card presents the affected user, IP address, failure counts, timeframe, historical activity, and sign-in context. It offers human-selected actions to lock the account, reset the password, or close the alert.
What changed
Each webhook event batch is automatically deduplicated, profiled, checked against relevant sign-in history, and converted into a structured Teams alert. Analysts receive the investigation context and remediation choices in one card, while the decision to lock the account, reset the password, or close the alert remains human-selected.
Work removed
Removing duplicate sign-in events, extracting users and IP addresses, calculating event timeframes, counting basic and MFA failures, searching seven-day sign-in history, checking successful sign-ins and Conditional Access policies, assembling alert details, and manually notifying the response team.
Expected outcome
Each alert batch can eliminate at least four recurring investigation actions—deduplication, failure counting, sign-in-history lookup, and notification assembly—while providing a consistent response handoff; this is a conservative estimate, not a measured result.
