ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • DeviceNetworkEvents • DeviceProcessEvents • Endpoint • KQL

Microsoft Defender Blocked the Malware — So Why Was the Device Still Talking to the Internet?

Microsoft Defender did exactly what everyone wanted.

It detected the malicious file.
It blocked execution.
The alert showed the threat had been prevented.

Case closed?

Not quite.

Minutes later, the same endpoint was still making outbound connections.

The malware had been blocked. Something else was still running.

Discuss endpoint security Back to investigations
Agent Foskett investigating outbound endpoint connections after malware was blocked
Prevention Is Not The End Of The Timeline

A blocked payload tells you what Defender stopped. The surrounding telemetry tells you what happened before, during and after the detection.

✓ Establish the detection time
✓ Find outbound connections after the block
✓ Trace each connection back to its process

The alert looked reassuring

The endpoint alert showed that Microsoft Defender had prevented a malicious payload. That was good news, but prevention of one file does not prove that every stage of an attack chain was prevented. Agent Foskett kept the investigation open and examined what the device did next.
The payload was blockedDefender prevented the identified malicious file from completing its intended execution.
The device remained activeEndpoint telemetry continued after the alert, including network connections that required explanation.
The timeline matteredThe question became whether those connections were normal background traffic or evidence that another process had survived.

Start with the network activity after the alert

Once the affected device and approximate detection time are known, inspect outbound network events immediately after the block. Do not begin by assuming every connection is malicious; establish which processes were communicating and where.
post-detection-network.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 Device = "FIN-LAP-042";
let DetectionTime = datetime(2026-08-25 02:14:00);
DeviceNetworkEvents
| where DeviceName =~ Device
| where Timestamp between (DetectionTime .. DetectionTime + 30m)
| project Timestamp,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteIP,
          RemoteUrl,
          RemotePort,
          Protocol,
          ActionType
| order by Timestamp asc

Which process owned the connection?

An IP address alone is rarely enough. The key pivot is the initiating process. A browser, update service or security agent may explain normal traffic. A script host, LOLBin, unexpected executable or process running from a user-writable directory deserves deeper investigation.
network-processes.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
let Device = "FIN-LAP-042";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| summarize Connections = count(),
            RemoteIPs = make_set(RemoteIP, 50),
            RemoteUrls = make_set(RemoteUrl, 50),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
    by InitiatingProcessFileName,
       InitiatingProcessSHA1
| order by Connections desc

Follow the process backwards

Once a suspicious network-owning process is identified, reconstruct its process activity. Who launched it? What command line was used? Did it appear before the malware alert? Was it a child of the blocked payload, or had an earlier stage already created it?
process-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
  17. 17
let Device = "FIN-LAP-042";
let SuspiciousSHA1 = "0123456789abcdef0123456789abcdef01234567";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| where SHA1 == SuspiciousSHA1
   or InitiatingProcessSHA1 == SuspiciousSHA1
| project Timestamp,
          FileName,
          ProcessCommandLine,
          SHA1,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessSHA1
| order by Timestamp asc

Did another file arrive before the block?

The blocked malware may have been only one artifact in a larger chain. Search DeviceFileEvents around the same period for files created, renamed or modified by the suspicious process or its parent. This can expose a second payload, script, DLL or staging file that the original alert did not describe.
related-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
let Device = "FIN-LAP-042";
DeviceFileEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| project Timestamp,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Build one endpoint timeline

The strongest view combines process, file and network evidence. The goal is to determine whether outbound communication after the block belonged to normal software or to an attack component that was already present.
combined-endpoint-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
  17. 17
  18. 18
  19. 19
let Device = "FIN-LAP-042";
union
(DeviceProcessEvents
 | where DeviceName =~ Device
 | project Timestamp, Event="Process",
           Detail=ProcessCommandLine),
(DeviceFileEvents
 | where DeviceName =~ Device
 | project Timestamp, Event="File",
           Detail=strcat(ActionType, " | ", FolderPath, "\\", FileName)),
(DeviceNetworkEvents
 | where DeviceName =~ Device
 | project Timestamp, Event="Network",
           Detail=strcat(InitiatingProcessFileName, " -> ",
                         coalesce(RemoteUrl, RemoteIP)))
| where Timestamp > ago(24h)
| order by Timestamp asc

What could explain continued network traffic?

Continued communication does not automatically prove Defender failed. The analyst must separate expected endpoint traffic from evidence of another malicious stage.
Normal background trafficBrowsers, Windows services, security tools and update agents can continue communicating normally after a malware detection.
An earlier stage survivedA loader, script, scheduled task or other process may already have been active before the blocked payload was detected.
A second artifact existedThe alert may describe one malicious file while another related file or process continues the attack chain.

Agent Foskett's investigation mindset

A prevention alert answers an important question: what did the security control stop? It does not automatically answer the broader question: what happened on the device?
Read the alertUnderstand exactly what Defender detected, blocked or remediated.
Keep reading the telemetryProcess, file and network events can reveal activity outside the alert's immediate scope.
Verify containmentDo not close the incident until the endpoint behaviour after remediation makes sense.

Investigation findings

The malware prevention event was real, but it was not the entire story. Network telemetry showed that another process continued communicating after the block. By pivoting from the connection to the initiating process, then backwards through process and file activity, the investigation established whether the traffic was benign or whether another component of the attack chain required containment.
The block was successfulThe detected payload was prevented.
The investigation still continuedPost-alert telemetry required explanation before the endpoint could be considered clean.
The timeline decided the outcomeNetwork, process and file evidence established what survived and what needed remediation.

Related Agent Foskett investigations

Continue following endpoint evidence beyond the original alert.
The Process Tree Told The Real StoryFollow parent and child processes when the alert does not explain the full execution chain. The PowerShell Command Never Contained a URLUse network telemetry to reveal connections that were invisible in the command line. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
Defender blocked the malware. The investigation wasn't blocked with it.
Prevention is a control outcome. Containment still has to be verified.
Visit the Agent Foskett Academy

Final thought

The green “blocked” status is reassuring, but investigators should never confuse a successful prevention action with proof that nothing else happened. Follow the device after the alert. If it keeps talking, find out which process is speaking — and why.
What was blocked?Define exactly what Defender prevented.
What kept running?Trace post-detection network activity to the responsible process.
What still needs containment?Close the incident only after the surviving behaviour has been explained.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Microsoft Defender Blocked the Malware — So Why Was the Device Still Talking to the Internet?

This Agent Foskett investigation explores Microsoft Defender XDR endpoint telemetry after a malware prevention event, using DeviceNetworkEvents, DeviceProcessEvents, DeviceFileEvents and KQL to determine why outbound network communication continued.

Microsoft Defender XDR Post-Detection Investigation

The investigation follows outbound connections back to initiating processes, reconstructs process and file activity and builds a combined endpoint timeline to verify whether remediation actually contained the incident.

Endpoint Containment And KQL Threat Hunting

GEMXIT helps organisations investigate endpoint incidents using Microsoft Defender XDR and KQL, validating what security controls blocked and identifying suspicious behaviour that may remain after the original alert.