The M365 Evidence Map: Identity, Email, Files and Directory

Introduction

Per IR0.1 a Microsoft 365 investigation works from records rather than from systems. This section is the map of those records: what exists, which question each one answers, and which console you reach it through.

It is deliberately a map rather than a manual. What each source retains, what it cannot establish and where it misleads are the subject of module one; the job here is knowing what is on the board before the course starts moving pieces around it.

The tenant produces an enormous number of record types and almost nobody learns them as a list. The useful structure is by what they answer.

Evidence in a Microsoft 365 tenant divides into four domains, and the division is useful because each one answers a different question.

Four domains, and the question attached to each is the part to memorize.

Evidence in a tenant divides four ways, and each division answers a different question. This is the map worth memorizing.

The boundaries between them are Microsoft's rather than ours, and they follow the products: identity is Entra, email is Exchange Online, files are SharePoint and OneDrive, and the directory is Entra again in a different aspect.

Each domain is a set of record types rather than a single log, and the sets are not the same size: identity carries four distinct populations, email carries three record types answering different questions, and the directory is one stream covering several kinds of change.

Almost every investigation crosses at least three of them. A mailbox compromise starts in identity, moves to email, frequently reaches files, and leaves traces in the directory where an attacker added a rule or registered a device.

Nothing about the four is a Microsoft term, and you will not find them named this way in any documentation. They are a way of holding the material, and the value is that each one has a question attached rather than a product name.

A fifth category sits alongside these four and is worth naming so its absence from the list is deliberate rather than an omission. Alerts and incidents, produced by Defender and Sentinel, are not evidence in the same sense: they are somebody else's conclusion about evidence, and per the later modules an investigation reads the underlying records rather than the alert that pointed at them.

The order above is roughly the order an investigation visits them, and it is also the order of decreasing confidence about what you will find, since identity is the best-instrumented domain and directory changes are the easiest to miss.

That crossing is the reason the domains are worth learning as a set. A responder who knows email well and identity poorly will produce a good account of what was read and no account of how the attacker got in, which is the half a regulator asks about first.

It is worth noticing that none of the four is optional in a real case. An account of what an attacker read, with no account of how they authenticated and no check on what they changed, is the shape of an investigation that finishes early and gets reopened.

The three questions in the scenario map onto them directly. How did they get in is identity, what did they do is email and files, and did anything change is the directory, which is the question nobody asks in the first hour and everybody asks in the second week.

The fourth domain is the one people forget. Directory changes are how access is created and how it persists, and they are recorded separately from anything a user does with that access.

Three populations authenticate against a tenant and they are recorded separately, which is the first thing to know about this domain.

The identity domain is the one every M365 investigation starts in, because per IR0.1 identity is the control plane rather than the network.

Each of the four below is a separate record type with its own table, its own volume and its own retention.

The audit log is the entry that overlaps another domain. Directory changes are identity records in the sense that Entra produces them, and they are treated as their own domain here because they answer a different question.

The split between interactive and non-interactive matters more than any other distinction on this page. An interactive record is a person; a non-interactive record is a client doing its job, and in any real tenant the second vastly outnumbers the first.

Both are sign-in records and both look broadly alike in a table, which is why the distinction has to be made deliberately rather than noticed.

The distinction also decides where a compromise is visible. A stolen token is used non-interactively, so the account looks quiet in the table most people open and busy in the one they do not.

The audit log is listed alongside the sign-in records because Entra produces both, and it is treated as the directory domain in section five because it answers a different question.

Module one works this in detail. What matters here is that an investigation confined to interactive sign-ins is looking at a small fraction of the identity activity, and per module one it is frequently the wrong fraction.

The volume difference is not marginal. In a working tenant the non-interactive records outnumber interactive ones by a wide margin, because every client refreshing a token produces one and people authenticate a few times a day.

That population grows quietly in most tenants. Every integration, every automation and every application somebody consented to authenticates this way, and the set is rarely reviewed because nothing about it is visible to the people using the services it supports.

Service principal sign-ins are a third population again, recorded separately, and they are how an application with granted permissions authenticates without any user involved.

It is also the domain where the record types differ most in what they cover, so knowing which one answers which question is worth more here than anywhere else.

Email carries more distinct record types than any other domain, which reflects how much of a typical incident happens there.

Three record types matter most, and they answer questions that sound similar and are not.

Message trace records what arrived and what was sent, at the envelope level. It is how you establish that a message existed and where it went.

Mailbox audit records cover what was done to items: accessed, moved, deleted, sent. This is where the item-level access question lives, and per module one it is also where the licensing and throttling constraints bite hardest.

It is worth knowing which of the three you are reaching for before you open a console. Message trace answers a question about a message, mailbox audit about a mailbox, and configuration about a state, and reaching for the wrong one produces a confident answer to a question nobody asked.

Mailbox audit is also the licensing-sensitive part of this domain, and per module one whether individual item access is recorded at all depends on the license held by the user rather than by the tenant.

Rules and forwarding configuration are separate again, and they are the artifacts that persist. An inbox rule created during a compromise keeps working after the session is revoked, which makes it one of the highest-value things to check early.

Getting these three the wrong way round is the most common early mistake in a mailbox case, and it costs an hour rather than a finding.

Message trace also has its own retention behavior distinct from the audit log, which is one of several places where two sources covering adjacent questions expire on different schedules.

Read those three as an order rather than a list. Rules first because they are still running, mailbox audit second because it establishes what was reached, and message trace last because it is the one that will still be answerable next month.

SharePoint, OneDrive and Teams are one domain for investigative purposes, because they share a record format and a query surface.

File activity is recorded at the operation level: accessed, modified, downloaded, shared, deleted.

The operation names are literal, which makes this domain the easiest to search once you know what happened and the hardest to search when you do not, since a broad question produces an enormous number of ordinary file accesses.

The volume in this domain is the practical problem. An ordinary working day generates a very large number of file access records, so a question here needs a scope before it needs a query, and the scoping usually comes from identity per section two.

Sharing operations are the ones worth knowing about early. A file shared with an external address or through an anonymous link is a durable change rather than an event, and like an inbox rule it continues to work after the access that created it is gone.

Teams sits in this domain rather than in email, which surprises people, and it matters because an internal phishing message sent over Teams is a common second stage in the attacks this course covers. Teams messages, channel activity and membership changes are recorded, and a compromise that used Teams to reach somebody internally leaves its trace here rather than in the mail records.

A shared link is also the one artifact in this domain that is visible to somebody outside the organization, which makes it the one most likely to be reported to you by a third party rather than found by you.

Deletion is the operation people most want to reverse and the one where the recycle bin behavior decides what is possible, which per the recovery material later in the course is a shorter window than most people assume.

The download distinction matters for the exfiltration question. An access record says a file was opened; a download record says a copy left the platform's storage for a device. Per module one neither establishes that data left the organization, and the second is closer than the first.

Three domains cover what people do with their access. This one covers the access itself.

The directory records changes to the tenant itself rather than to its contents, and it is the domain where persistence lives.

Four categories cover most of what an attacker changes when they intend to stay.

Consent grants deserve their own note because they are the least intuitive. A grant is not an action somebody took against your data; it is permission for an application to take actions later, so it appears once in the record and then produces activity indefinitely under a different identity.

Every one of those outlives a session. Revoking an attacker's tokens removes their access; it does not remove an application they registered, a device they enrolled or a role they were granted, and per module one a device registration in particular survives everything a session-level response does.

The application and consent records deserve particular attention because they are how access is granted rather than taken, and per the later modules an application with tenant-wide permissions is a durable route in that no session revocation touches.

Policy changes are the subtlest entry on the list. Weakening a Conditional Access policy, adding an exclusion or disabling a requirement are all recorded, and none of them looks like an attack in a list of administrative activity.

That is why the directory is checked in every incident regardless of where the case started. An investigation that establishes what happened in a mailbox and never asks what changed in the tenant has answered the smaller question.

Group membership deserves a mention alongside roles, because it is the quieter route to the same outcome. Adding an account to a group that holds a role, or that is excluded from a policy, grants access without any role assignment appearing anywhere.

Device registrations sit here for the same reason applications do. A registered device is a relationship between an identity and a machine, held in the directory, and it persists until somebody removes it deliberately.

It is also the domain that answers who changed a control, which is a question that arrives late in an incident and is usually about whether something was weakened deliberately.

Knowing what exists is half of it. The other half is where you go to read it, and the tenant offers several routes to overlapping material.

The four domains are reached through a small number of surfaces, and knowing which is which saves a great deal of time early.

Five surfaces reach the four domains, and knowing which is which saves the first hour of a case.

Five surfaces sounds like a lot and in practice most work happens in two of them.

Most work happens in two of them, and the rest are where you go for a specific question.

// Identity: who authenticated, and from where
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName == "REPLACE"
| project TimeGenerated, IPAddress, AppDisplayName, SessionId
| join kind=leftouter (
    // Email and files: what that session then did
    OfficeActivity
    | where TimeGenerated > ago(30d)
    | project TimeGenerated, Operation, OfficeWorkload, ClientIP )
  on $left.IPAddress == $right.ClientIP

The unified audit log is the one to know first, because it reaches all four domains through one interface and is the closest thing the tenant has to a single source.

Its coverage is the reason. A single search there can return identity, email, file and directory activity together, which is what you want when the question is what happened to this account rather than what happened in this workload.

The Entra admin center is the one to know second, because per section two the identity domain is where most cases begin and its interface presents sign-in data more usefully than a generic audit search does.

The overlap between surfaces is real and occasionally confusing. The same underlying activity can appear in Purview, in the Defender portal and in a Sentinel workspace, with different field names and different retention in each, and per module one those differences decide which one can answer a question about last quarter.

The Sentinel row is deliberately conditional. Not every organization has it, and among those that do, per module one what it contains is whatever somebody chose to export rather than everything the tenant produces.

Exchange Online PowerShell is the specialist surface and it earns its place. Several mailbox questions have no portal equivalent, and the bulk work in a real case is nearly always faster from a shell than from a search interface.

Two query languages cover most of it. KQL for anything in Defender or Sentinel, PowerShell for Exchange and for bulk work against the audit log, and both are taught in the sections that need them per IR0.2.

This section has described what is on the board. Three things it has said nothing about decide whether any of it can answer your question.

A map of what exists is useful and it is not sufficient, and it is worth being explicit about what module one adds to it.

The third omission is the one that catches people, because it is invisible from any interface. A record type not produced for a given user does not appear as an empty result or an error; it is simply absent, and nothing distinguishes that from a period when nothing happened.

Knowing that message trace exists is worth very little without knowing how far back it reaches. The map tells you where to look and module one tells you whether looking will produce anything, which is why the two sections sit in this order.

The order is deliberate and worth stating. A reader who learned the constraints first would have nothing to attach them to, and a reader who learns only the map will go looking for a source that cannot answer the question they have.

That is the honest shape of the course's opening. This section is orientation, and the first teaching module is where the map becomes a working position on your own tenant.

The exercise below is deliberately about opening things rather than finding anything. Four surfaces opened once on an ordinary afternoon is worth more than four read about.

The next section is the toolkit that reaches these sources, and the lab where you can practice against them safely.