ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Purview DLP • Defender XDR • Microsoft 365 • Data Exposure • KQL

The DLP Alert Looked Like a False Positive — Until We Followed the File

The DLP alert looked ordinary.

A user had handled a document containing sensitive information.

The business explanation sounded plausible.
The destination did not immediately look malicious.

It was tempting to classify the alert as noise and move on.

Agent Foskett did something else.

He followed the file.

Where had it been?
Who had touched it?
How had it moved?
And was the DLP event really the beginning of the story?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating a Microsoft Purview DLP alert and following a sensitive file across Microsoft 365
The Alert Looked Harmless. The File Had a Longer Story.

DLP tells you a policy condition was matched. Investigation determines what happened around the data before and after that event.

✓ Identify the sensitive file
✓ Reconstruct its activity
✓ Correlate DLP with security evidence

Do not investigate the alert in isolation

A DLP alert can contain useful context about the policy, sensitive information and activity that triggered it.

But Agent Foskett did not let the alert become the boundary of the investigation.

The alert was one observation about the file.

The file itself became the pivot.

Start with the file identity

Agent Foskett preserved the file name, location, user, DLP policy context and event time.

He also captured identifiers available in the incident and audit evidence rather than relying on the filename alone.

Files can be renamed. Copies can be created. Similar filenames can exist in multiple locations.

A filename is a clue. It is not always a unique identity.

Find the file in Microsoft 365 audit evidence

Where Microsoft 365 audit data was connected to Microsoft Sentinel, Agent Foskett used OfficeActivity to search for activity around the affected file. The exact operations available depend on the workload and auditing configuration, so he first preserved the raw activity rather than assuming a single operation name.
follow-the-file-officeactivity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let TargetFile = "Quarterly-Customer-Export.xlsx";
OfficeActivity
| where TimeGenerated > ago(14d)
| where OfficeWorkload in ("SharePoint", "OneDrive")
| where SourceFileName =~ TargetFile
   or OfficeObjectId has TargetFile
| project TimeGenerated,
          UserId,
          Operation,
          OfficeWorkload,
          Site_Url,
          SourceFileName,
          OfficeObjectId,
          ClientIP,
          UserAgent
| order by TimeGenerated asc

The DLP event was not the first event

The audit trail showed activity before the policy alert.

The document had been accessed from SharePoint.
It had been downloaded.
Later activity involved the same file context.

The DLP event was therefore not a standalone action.

It was one point in a longer file timeline.

Now ask what happened on the endpoint

Microsoft Purview DLP incidents can be investigated alongside Defender XDR security context when the relevant integration and telemetry are available.

Agent Foskett pivoted from the user and file into endpoint evidence.

The question changed from “Did a DLP policy match?” to “What processes and destinations surrounded the file activity?”

Look for matching endpoint file activity

In Defender XDR advanced hunting, DeviceFileEvents can provide file-system activity from onboarded devices. Agent Foskett searched the affected filename around the DLP window and preserved the initiating-process context.
device-file-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let TargetFile = "Quarterly-Customer-Export.xlsx";
let StartTime = datetime(2026-10-04 08:00:00);
let EndTime   = datetime(2026-10-04 12:00:00);
DeviceFileEvents
| where Timestamp between (StartTime .. EndTime)
| where FileName =~ TargetFile
| project Timestamp,
          DeviceName,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessAccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

The process context changed the story

The file was not merely opened by the expected business application.

Endpoint telemetry showed activity involving another process during the same period.

That did not automatically prove exfiltration.

But it gave Agent Foskett a new pivot: the process, the device and the surrounding network activity.

DLP described the data-policy event. Endpoint telemetry described what the device was doing around it.

Follow the initiating process into network activity

Agent Foskett used the device, user and process context to inspect nearby network connections. The aim was not to declare every outbound connection suspicious, but to determine whether the file-handling activity coincided with destinations that deserved further investigation.
device-network-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
let TargetDevice = "LAPTOP-042";
let TargetProcess = "browser.exe";
let StartTime = datetime(2026-10-04 08:00:00);
let EndTime   = datetime(2026-10-04 12:00:00);
DeviceNetworkEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ TargetDevice
| where InitiatingProcessFileName =~ TargetProcess
| project Timestamp,
          DeviceName,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          Protocol,
          InitiatingProcessAccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

A network connection was still not proof of data transfer

This distinction mattered.

A browser or application connecting to an external service does not by itself prove that the sensitive document was uploaded there.

Agent Foskett looked for corroborating evidence from DLP, audit logs, browser or cloud-app telemetry, file activity and the timing of the connection.

Correlation strengthens the story. One coincident connection does not complete it.

The “false positive” label was being used too early

The original explanation focused on why the user's action might be legitimate.

But a DLP investigation has two separate questions.

Did the policy correctly identify sensitive content and an activity?

And was the activity authorised in its full business and security context?

A legitimate user can still perform an unauthorised data action. A correct DLP match can still require contextual investigation.

Build a user-and-file timeline

Agent Foskett combined the available file events into a timeline. This example uses endpoint telemetry; in a real investigation he would preserve the DLP event and Microsoft 365 audit evidence alongside it rather than pretending every signal lives in one table.
file-investigation-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let TargetFile = "Quarterly-Customer-Export.xlsx";
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName =~ TargetFile
| project EventTime = Timestamp,
          DeviceName,
          Account = InitiatingProcessAccountName,
          Event = ActionType,
          FileName,
          FolderPath,
          Process = InitiatingProcessFileName,
          SHA1
| order by EventTime asc

Follow the file beyond the first alert

Agent Foskett widened the scope beyond the original DLP timestamp.

Had the document been copied?
Renamed?
Downloaded from SharePoint or OneDrive?
Moved to another location?
Handled by another process?
Shared or accessed by another identity?

The most important event may happen before or after the event that generated the alert.

Build the data-exposure timeline

DLP alert generatedA sensitive-data policy identifies an activity that initially appears explainable.
File becomes the pivotThe investigation preserves the file, user, location, identifiers and policy context.
Microsoft 365 history reviewedOfficeActivity reveals earlier access, download or sharing-related events around the document.
Endpoint evidence addedDeviceFileEvents identifies processes and file-system activity around the same time.
Network context investigatedRelated process connections are reviewed without assuming a connection automatically proves transfer.
Exposure scope establishedThe full file timeline determines whether the original benign explanation still makes sense.

What Agent Foskett checked

DLP contextWhich policy, sensitive information and activity caused the alert?
File identityWhat identifiers distinguish the affected document from similarly named files?
Microsoft 365 activityWho accessed, downloaded, moved or shared the file?
Endpoint activityWhich processes interacted with the file on the device?
Network contextWhat destinations were contacted by relevant processes around the event?
Business authorisationWas the complete data-handling path expected and permitted?

What the evidence can and cannot prove

A Microsoft Purview DLP alert can establish that configured policy conditions matched observed activity.

OfficeActivity can provide Microsoft 365 audit evidence when the relevant audit data is connected and retained.

DeviceFileEvents and DeviceNetworkEvents can add endpoint context when Defender for Endpoint telemetry is available.

None of those signals should be stretched beyond what they record.

A file event, network connection and DLP alert become powerful when their timestamps, identities, devices and actions support the same evidence-based timeline.

The lesson

The alert looked like something the SOC could dismiss quickly.

The user's explanation sounded reasonable.

But Agent Foskett did not investigate the explanation.

He investigated the evidence.

And once the file became the pivot, the alert stopped looking isolated.

A DLP alert tells you where to start. The file can tell you where the data actually went.
Investigation principle: When a DLP event appears benign, follow the sensitive object across identity, Microsoft 365 and endpoint evidence before deciding the complete data-handling path was authorised.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to investigate identity, endpoint, cloud and data-security evidence.SOC Analyst AcademyBuild practical investigation and triage skills across Microsoft security platforms.
The alert looked harmless. The file had a longer story.
Follow the file. Correlate the evidence. Reconstruct the exposure path.
Continue the Investigation

Final thought

Security alerts are abstractions.

They package evidence into something an analyst can triage.

But the object at the centre of the alert can have a history that extends far beyond the alert itself.

In this case, that object was the file.

Agent Foskett followed it backwards, forwards and across security products until the data-handling story made sense.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The DLP Alert Looked Like a False Positive — Until We Followed the File

This Agent Foskett investigation examines a Microsoft Purview DLP alert by following the affected file across Microsoft 365 audit evidence and Microsoft Defender XDR endpoint telemetry.

Investigating Microsoft Purview DLP Alerts

Use DLP context, OfficeActivity, DeviceFileEvents, DeviceNetworkEvents and KQL to reconstruct how sensitive data was accessed, downloaded, handled and potentially exposed.

Follow the File During a Data Loss Investigation

Learn why a DLP alert should be treated as an investigation starting point and how file, identity, endpoint and network evidence can be correlated without claiming more than the telemetry proves.