Anatomy of an AI Investigation: One Alert, Start to Finish

Follow one alert, an impossible-travel sign-in followed by a new mailbox rule, through every step of an AI-run investigation: baseline check, enrichment, correlation, ATT&CK mapping, verdict, escalation, and the customer update.

AI OperationsBy the mysoc.ai team··6 min read

Most writing about AI in the SOC stays abstract: the AI triages, the AI investigates, the AI reports. That makes it hard to judge. So here is one alert, followed from the moment it fires to the moment the customer reads about it, with every step the platform takes and every decision it hands to a human. The organization, the user, and the details are illustrative. The sequence is how the work is actually structured.

The alert

At 02:14 UTC, the identity provider records a successful sign-in for a finance manager at a mid-sized professional services firm. Forty minutes earlier, the same account signed in from the firm's head office. The new sign-in comes from a country where the firm has no presence, from an IP address that belongs to a hosting provider. Eleven minutes later, a new inbox rule appears on the same mailbox: any message containing "invoice" or "payment" is moved to an obscure folder and marked as read.

In a traditional SOC, those are two alerts in two consoles, possibly in front of two different analysts, at the worst hour of the night shift. Here is what happens instead.

Step 1: Check it against the tenant's normal

Before anything else, SiemCore asks the question that disposes of most events: is this normal for this tenant? Impossible-travel detections are famously noisy. VPN egress points, mobile carriers that route traffic through other countries, and staff who travel all trigger them. The tenant's baseline, its Sphere of Normalcy, knows which of those patterns are routine here.

  • Has this user signed in from this country, network, or device before? No.
  • Does the firm use a VPN or proxy that exits through this provider? No. Its known egress points are all in-country.
  • Does anyone in the user's peer group sign in from that region? No one at the firm has, in the baseline's history.
  • Is creating inbox rules normal for this user? They have created one, more than a year ago.

Had those answers come back the other way, the alert would most likely have been closed as benign, with its reasoning attached. That is how around 99% of events are eliminated: not by ignoring them, but by matching them to a documented normal. This one does not match, so it becomes work.

Step 2: Enrichment

Next, the AI gathers the context a tier-1 analyst would otherwise collect by hand across half a dozen browser tabs:

  • Source IP: threat intelligence and reputation lookups on the address and its hosting range.
  • Authentication details: MFA was satisfied, but from a device and user agent never seen for this account.
  • The mailbox rule: its conditions, its target folder, and its name, a single period, chosen to look unremarkable in the rules list.
  • The user: role, department, and the fact that finance staff at this firm handle vendor payments.

Every lookup is recorded with its source and result. That record is what makes the verdict auditable later.

Step 3: Correlation

This is where two alerts become one story. The AI links the sign-in and the inbox rule by account, session, and time window, then looks outward for related activity. Did any other account in the tenant sign in from the same network? No. Has the mailbox sent anything since the new session started? Yes: two replies to external addresses, both inside existing threads with a supplier. Did the EDR on the user's laptop see anything? No, and the laptop has been idle on the office network all night, which supports the idea that the session is not on the user's device at all.

The output is a single incident with a timeline, not two unrelated alerts waiting in a queue.

Step 4: MITRE ATT&CK mapping

The AI maps the steps it can support with evidence. The sign-in with legitimate credentials maps to Valid Accounts: Cloud Accounts (T1078.004). The rule hiding payment-related mail maps to Hide Artifacts: Email Hiding Rules (T1564.008). The outbound replies are recorded in the timeline but not forced onto a technique the evidence does not clearly support. Mapping gives the incident a shared vocabulary for the analyst, the customer, and the monthly report. It has limits too, which we cover in a separate post on automated ATT&CK mapping.

Step 5: The verdict

The AI writes its conclusion the way a senior analyst would:

Likely account compromise with preparation for business email compromise. The account signed in from an unfamiliar hosting-provider address 40 minutes after an in-office sign-in, created a rule hiding invoice and payment messages, and replied to two supplier threads. No matching travel, VPN, or prior behavior in this tenant. Confidence: high. Recommended actions: revoke active sessions, reset the password and review registered MFA methods, remove the inbox rule, and confirm the two outbound messages with the supplier through a known contact.

Note what the verdict is: a written conclusion, the evidence behind it, a confidence level, and specific next steps. Not a risk score of 87 that someone still has to interpret.

Step 6: Escalation

The tenant's escalation rules are part of its Sphere of Normalcy, alongside entities, behaviors, and policies. For this firm, suspected account compromise in finance goes to the on-call analyst immediately and to the customer's IT lead straight after. The analyst receives the incident fully assembled: timeline, evidence, mapping, verdict, and recommended actions. Their job is judgment. They confirm the verdict, approve the response actions, and decide whether anything else needs to happen, such as checking whether other finance users received phishing in the days before. The investigation is already done, so the review is short.

Step 7: The customer update

The customer's IT lead gets a plain-language notification written at detection time: what happened, what has been done, and what they need to do, starting with calling the supplier before any payment details change. No jargon, no technique IDs unless they ask.

At 7 AM, the firm's IT manager opens chat and asks: "Did they send anything to our suppliers?" The AI answers from the incident's own data: two replies, to whom, when, and what they said. Questions that go beyond the incident data or need a judgment call go to the analyst. At month end, the incident appears in the customer's report automatically, with its timeline, its ATT&CK mapping, and the actions taken.

Where the human was

Count the human touchpoints: one review and one approval. Everything a tier-1 analyst would have spent the first part of the night on, including the lookups, the correlation, the write-up, and the customer email, was done before the analyst opened the incident. What the analyst contributed was the part that needs a person: deciding, and owning the decision.

That is the pattern behind every investigation. The machine gathers; the human decides. To see how that changes the shape of a SOC team, read about the AI tier-1 analyst.

See mysoc.ai in action

One AI-run platform for your entire SOC—triage, investigation, customer communication, and reporting.