0.5 The Five Investigations

Introduction

The course works five investigations, all on the SecOps Range, each one chosen to cross services in a different way. Every module configures a service, and its proof and its exercise use one of these investigations, so knowing them before Module 1 means every later lesson starts from a case you already recognize.

This exercise builds the map of the five: what it produces, the five on one timeline, the alerts each raised, the four that arrived as incidents one by one, and the map of which modules work each. Practice is the fifth investigation, the one with no incident, which you place yourself.

The five investigations each cross services in a different way, and together they reach every surface the course configures:

The first is a phishing message that captured a user's session and used it across mail, identity and files. The second is an implant on a laptop, credentials taken from memory, and a second device reached with them. The third is an OAuth application that read organizational data with access of its own.

The fourth is a cloud workload whose identity's secret was used from outside to open a key vault. The fifth is a data transfer: files moved out of the organization by an insider, which must be investigated before anyone knows the intent.

This exercise places each one from the range's records and maps it to the modules that work it:

The map is a working document for the whole course. Each module's lessons name the investigation they use, and the map tells you what that investigation is, where it starts, and what you already know about it from earlier modules. By Module 12 you will have seen four of them several times and the fifth from two angles.

Placing an investigation means three things here: its first record and when, the alerts it raised and the products that raised them, and the entities those alerts named. Those three are what an analyst knows in the first minutes of any incident, and they are what the course builds from.

None of the five is the course's subject. The course is about the platform; the investigations are where its configuration is proved. A Conditional Access lesson is not about the phishing investigation, but the phishing investigation is where the policy it teaches would have stopped the attacker.

Build the map of the five investigations once, here, and use it as the reference every later module's examples point back to.

The first record of each investigation, in time order. Four are incidents; the fifth is an alert:

union
  (SecurityIncident | where IncidentNumber between (100031 .. 100034)
    | summarize arg_max(TimeGenerated, Title, Severity, AlertIds),
        Created = min(CreatedTime) by IncidentNumber
    | project Created, Ref = strcat("Incident ", IncidentNumber), Title, Severity,
        Alerts = array_length(todynamic(AlertIds))),
  (SecurityAlert | where ProductName == "Microsoft Insider Risk Management"
    | where Entities has "b.collins"
    | project Created = TimeGenerated, Ref = "Alert, no incident",
        Title = AlertName, Severity = AlertSeverity, Alerts = 1)
| order by Created asc

The endpoint compromise comes first, on 4 March, as incident 100032: 5 alerts, severity High. The OAuth application follows on 5 March as 100033, with 3 alerts. The phishing compromise is 9 March, 100031, with 7.

The cloud workload is 10 March, 100034, with 3. The data transfer is last, on 13 March, and it is not an incident at all: one High-severity alert from Insider Risk Management, "Data leaks: files uploaded to unallowed cloud storage", standing on its own.

The incident numbers are not in time order, because the range numbered its investigations by kind rather than by date; the timeline is what puts them in order.

The titles are Defender XDR's generic "multi-stage incident" names, which describe the tactics the alerts map to and say nothing about what happened. Reading an incident's title is never enough to know what it is, which is why the next query reads the alerts.

The five spread over ten days of a month that otherwise holds ordinary work. The first and last are separated by more than a week, and between them the organization's administrators kept changing settings, its users kept signing in, and hundreds of other alerts came and went. The investigations do not announce themselves; they are found in that noise by a platform configured to raise them.

The fifth's lack of an incident is a finding worth holding onto. An Insider Risk Management alert outside the Defender incident queue is one an analyst working that queue does not see, and the course comes back to it when it reaches data protection.

The timeline is also the order in which a SOC working this month would have met them, and each one arrived while the earlier ones might still have been open. A queue in which several high-severity incidents overlap is the normal condition the platform has to support.

Read the five investigations as four incidents and one alert, ten days apart, inside a month of ordinary work.

Every alert in the four incidents, with the product that raised it and the entity it named:

SecurityIncident
| where IncidentNumber between (100031 .. 100034)
| summarize arg_max(TimeGenerated, AlertIds) by IncidentNumber
| mv-expand Id = todynamic(AlertIds)
| extend SystemAlertId = tostring(Id)
| join kind=inner (SecurityAlert
    | project SystemAlertId, AlertName, ProductName, At = TimeGenerated,
        CompromisedEntity) on SystemAlertId
| project IncidentNumber, At, AlertName, ProductName, CompromisedEntity
| order by IncidentNumber asc, At asc

The four differ in shape. Incident 100031 has 7 alerts from 4 products, all naming one account: a single identity reached through mail and used across services. Incident 100032 has 5 alerts from 2 products naming 3 entities: two devices and an account, which is what lateral movement looks like in alerts.

Incident 100033 has 3 alerts, and one of them names an application rather than a person. Incident 100034 has 3, naming a key vault and a pipeline's identity: no human account at all.

The order inside each incident tells its story. In 100032, process injection comes first, then access to the memory of the credential process, then remote execution on a second device and the theft of an identity: the attack's sequence, in the order the products saw it.

In 100031, the capture comes first, then the use of the stolen cookie, then downloads and a mailbox rule, then the mail-side alerts raised as the lure was removed from the mailboxes.

The products tell you which services had to be configured for the incident to exist. 100032 exists as one incident because Defender for Endpoint and Defender for Identity both saw it and named entities that correlation could join. Had either been missing or misconfigured, the incident would be smaller, or two incidents, or none.

The entities tell you what the response will act on: an account to contain, devices to isolate, an application to disable, a workload identity whose secret to rotate. Each of those is a containment the protection modules teach.

The same query, run on your own tenant's incidents, is the quickest way to see which of them crossed services, and which of your products contribute to the incidents that matter.

Read every incident's alerts in order, by product and entity, before reading anything else about it.

The phishing investigation is the course's most-used case, because it crosses the most services:

A message from a domain imitating the organization's document sharing reached six mailboxes on 9 March. One recipient clicked, and a proxy page captured her session. The attacker replayed it from another address, downloaded files, registered an authenticator in her name and created a mailbox rule to hide replies. A second wave arrived from a related domain the next day.

Its value as a teaching case is that every service had a part. The mail protection decided whether the lure was delivered and later removed it. The identity protection saw the capture and the replay. The cloud app protection saw the downloads and the rule. The data protection holds the labels on the files that left. And the response, when it came, needed roles from three teams.

It also carries the course's clearest lesson about response. The first alert fired a minute after the capture; the first containment action came hours later, and in between the attacker took every foothold the eviction later had to find. The engineering in the protection modules is about raising that alert; the response module is about acting on it.

You will meet this investigation first in the foundations, where it is the example of an incident spanning services, and last in the coordinated response, where it is taken from scope to a closed report. In between, the identity, mail and data modules each use the part of it their service recorded.

When you see b.mottram or the 9 March lure in a lesson, this is the investigation, and the map tells you which part of it that lesson is using.

Use the phishing investigation as the reference case for how one stolen session reaches every service an account can open.

The endpoint investigation is the course's case for devices and on-premises identity:

On 4 March an implant on one laptop injected into another process, then read the memory of the process that holds credentials on Windows. With an administrator's credentials taken from that memory, the attacker executed commands remotely on a second laptop. Defender for Endpoint saw the injection and the memory access; Defender for Identity saw the credential theft and the remote execution from the domain's side.

Its value is the join between those two products. Endpoint telemetry knows what ran on a device; identity telemetry knows which account authenticated where. Neither alone shows lateral movement: the first sees a process on two devices, the second sees an account used in two places. Together, joined on the account and the time, they show one attacker moving.

It is also the case the course uses for KQL. Building a timeline across device and identity tables, scoping which devices the stolen account reached, and proving which it did not, are the skills of the hunting module, and this investigation is where they are practiced.

Security Copilot's answers about it are checked in the Copilot module, because an investigation with a known answer is where an assistant's claims can be tested.

The entities to recognize are NE-KHAN-LT, the first laptop, NE-COLLINS-LT, the second, and s.mitchell, the administrator whose credentials were used.

The investigation also carries a containment lesson of its own. Isolating the first laptop does not end the attack once a second device has been reached and an administrator's credentials are in the attacker's hands; containment has to cover every device the account reached and the account itself, and the scope query is what finds them.

Use the endpoint investigation as the reference case for how device and identity telemetry join to show an attacker moving between machines.

The OAuth investigation is the course's case for applications with access of their own:

On 5 March Defender for Cloud Apps flagged an OAuth application signing in from an unusual network. A user reported a message as phishing the same morning, and correlation placed it in the same incident. Overnight, the application made a spike of Graph API calls into SharePoint. The application, Campaign Insights Pro, held access granted to it through consent, and it used that access on its own schedule.

Its value is the difference between a user's session and an application's grant. Revoking a user's sessions does nothing to an application the user consented to, because the application holds its own tokens. The investigation therefore turns on what was consented to, by whom, with which permissions, and what the application read with them, which is a different set of records from any sign-in investigation.

The cloud and applications module works it: connecting apps to Defender for Cloud Apps, governing OAuth consent, and containing an application by revoking its grant and disabling it. It is the narrowest of the five in the course's map, because its surface is narrow, and the most likely to be missed in a real tenant, because nothing about it looks like a compromised account.

The entities to recognize are Campaign Insights Pro, the application, and the accounts the alerts name.

The questions it raises are ones a SOC meets more often than this one example suggests. Users consent to applications every week, most of them harmless, and the configuration that matters is the one that decides which consents need an administrator, which applications are watched, and how quickly a grant that starts behaving strangely can be revoked.

Use the OAuth investigation as the reference case for access that belongs to an application, and for why a user's containment does not reach it.

The cloud workload investigation is the course's case for identities that are not people:

On the evening of 10 March Defender for Cloud flagged an unusual application reading a production key vault, then a listing and query of its secrets. Defender for Cloud Apps then saw activity from suspicious addresses by a deployment pipeline's identity. A secret belonging to the pipeline's workload identity had been exposed, and someone outside used it to open the vault.

Its value is that no human account is involved. The attacker never signed in as a person, never received a phishing message, never touched a device the endpoint protection watches. The evidence is in Azure's control-plane and resource logs, the vault's diagnostic logs and the workload identity's sign-ins, and the containment is rotating a secret and restricting the identity, not resetting a password.

It is also the case the detections module uses. A rule that should have caught the vault access, its entity mapping, and an automation that ran when the incident was raised are all read against this investigation, because an incident with no person in it tests whether a rule maps the right entities.

The entities to recognize are kv-ne-prod, the vault, and ne-deploy-pipeline, the workload identity.

Workload identities are also the case where ownership is least clear. A pipeline belongs to a development team, its vault to an operations team, and its secret to whoever created it; the investigation and the containment both need those owners found quickly, which is why the course records them as part of configuring the workload.

The timing matters too. The alerts fell late on a weekday evening, and when a workload identity normally runs is the kind of detail a detection can use and a person reading one alert at a time easily misses.

Use the cloud workload investigation as the reference case for attacks on identities that are not people, where the evidence and the containment are both in Azure.

Each lesson that works an investigation names its entities, so the modules each investigation reaches can be read from the course itself:

The phishing investigation reaches the most modules, from the foundations through identity, mail and data to the coordinated response. The endpoint investigation runs through the Defender incident, endpoint protection, hunting, detections and Copilot. The OAuth application and the cloud workload are concentrated where their surfaces are configured. The data transfer is worked in data protection, in hunting and as the practice case for coordinated response.

Use the map when a lesson names an entity you do not recognize: find the investigation, and you have its timeline, its alerts and the other modules that used it. Use it as well to see what you have already learned about a case before a module reaches it, because each module adds a layer to investigations earlier modules opened.

The map also shows why the modules come in their order. The phishing and endpoint investigations are opened in the foundations and the Defender incident module, before any protection module configures the services they cross; each protection module then shows how its service recorded its part. By the coordinated response, all of their parts are known.

The exam uses none of the five directly. It is one incident across several services, and it asks for the same things the course practices on these: an evidence-backed timeline, a scope, a response plan, verification and a report. The five are the rehearsal.

The map is computed from the lessons themselves, by finding each investigation's entities in them, so it stays accurate as long as the lessons do. If you notice a lesson using an investigation the map does not list, the map is the thing to correct.

Keep the map with your build evidence, and return to it whenever a lesson's example names an entity you need to place.

The fifth investigation is a data transfer by Ben Collins, an employee, and it arrived as one alert with no incident. The query below gathers its three kinds of record: a sensitivity label removed, files uploaded to cloud storage, and the alert Insider Risk Management raised:

union
  (CloudAppEvents | where AccountDisplayName == "Ben Collins"
    | where ActionType in ("SensitivityLabelRemoved", "FileUploadedToCloud")
    | summarize Records = count(), FirstSeen = min(Timestamp),
        LastSeen = max(Timestamp) by Record = ActionType),
  (SecurityAlert | where ProductName == "Microsoft Insider Risk Management"
    | where Entities has "b.collins"
    | summarize Records = count(), FirstSeen = min(TimeGenerated),
        LastSeen = max(TimeGenerated) by Record = AlertName)
| order by FirstSeen asc

The label came off one file first, then the uploads followed later the same evening, and the alert came the next morning.

Place it the way the four incidents were placed: its first record and when, its surfaces, its entities, the product that raised the alert, and why it has no incident. Then say what you would need to know before calling it exfiltration rather than ordinary work, because that question, what the records show against what was intended, is what makes this investigation different from the other four.

The course's five investigations are a phishing compromise, an endpoint compromise with lateral movement, an OAuth application with access of its own, a cloud workload whose identity's secret was used from outside, and a data transfer whose intent is unknown.

Four arrived as incidents between 4 and 10 March, and the fifth as one alert with no incident. Each is placed by its first record, its alerts and the products that raised them, and its entities. The map of which modules work each is the reference every later lesson's example points back to.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Investigate incidents in Microsoft Defender XDR (checked 8 November 2026)