Before
Analysts likely reviewed suspicious login alerts individually, searched historical login activity, looked up the user, investigated the source IP, and checked whether the email appeared in exposed data. They then copied the findings into a support ticket and routed the case for follow-up.
How it works
- Receive and route each suspicious Office 365 login alert according to its organization and alert conditions.
- Validate related historical activity and enrich the alert with user details, source-IP intelligence, and email-exposure results.
- Create a structured Zendesk case containing the investigation evidence for subsequent human review.
Workflow details
- Alert intake and routing: The workflow receives a collection of suspicious Office 365 login SIEM signals, processes each alert individually, and applies organization-based routing conditions, including explicit handling for IT and organizations outside Finance or Marketing.
- Historical validation: For each qualifying alert, it searches Elasticsearch for successful Office 365 login activity involving the same user, organization, and source country during the period from 24 hours to two weeks earlier. It evaluates whether the search result is below the configured threshold of four.
- Identity enrichment: The workflow retrieves additional user information from Microsoft Graph using the user identifier and derives a severity-based contact address for ticket ownership or requester context.
- Threat and exposure enrichment: It checks the source IP through VirusTotal and searches DeHashed using the user's email address, adding investigation context beyond the original SIEM signal.
- Case creation: The workflow creates a Zendesk ticket for the suspicious login, including the requester address, source and destination IPs, source country, incident severity, the alert link, and raw alert information so the case can be reviewed with its supporting evidence.
What changed
The investigation package is assembled automatically for each qualifying alert, including the configured organization checks, historical search, identity lookup, IP scan, email-exposure search, and ticket fields. Instead of manually moving between investigation tools and copying results into a case, analysts receive a pre-populated Zendesk ticket for follow-up.
Work removed
Reviewing alerts one by one, searching historical login records, checking the result threshold, looking up user details, scanning the source IP, searching the user's email for exposed data, compiling evidence, and manually creating the Zendesk ticket.
Expected outcome
Each qualifying alert receives one consolidated investigation ticket while replacing roughly five separate lookup or documentation actions that would otherwise be performed manually.