ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Endpoint Security • Process Trees • Defender XDR • Living-off-the-Land • KQL

The Antivirus Scan Was Clean — The Process Tree Wasn't

The antivirus scan completed successfully.

No malware was detected. No malicious file was quarantined. The endpoint appeared clean.

But one question remained:

why had the browser launched a Windows utility that immediately made an outbound network connection?

Agent Foskett stopped looking for a malware verdict and started following the process tree.

Discuss Endpoint SecurityBack to investigations
Agent Foskett investigating a suspicious Windows process tree in Microsoft Defender XDR
Clean Scan. Suspicious Behaviour.

Antivirus answers whether something was detected. Process telemetry answers what actually ran. When the two stories disagree, the investigation continues.

✓ No malware verdict
✓ Suspicious parent-child process chain
✓ Outbound network activity

The scan said the endpoint was clean

The user reported unusual behaviour after browsing the web. A security scan was run. It completed without finding malware.

That result was useful — but it was not the same as proving nothing suspicious had happened.

Microsoft Defender XDR retained something equally important: behavioural telemetry.

The endpoint had recorded which processes started, who started them, their command lines, their parent processes and the network activity that followed.
No detectionNo malicious file or traditional malware verdict explained the behaviour.
Process telemetryDeviceProcessEvents preserved the execution chain even without a malware detection.
Network evidenceDeviceNetworkEvents showed what one of those processes did after it started.

The process tree changed the investigation

A browser normally creates many child processes. That alone is not suspicious. But analysts should pay attention when an expected user application launches a utility that is unusual for the user's activity — especially when that utility then launches another process, interprets a command, writes a file or connects externally.

In this case, the interesting sequence was not a malware filename. It was the relationship between processes.

Browser → Windows utility → command execution → network activity.
ParentWhat application initiated the chain?
ChildWas the child process expected in that context?
BehaviourWhat did the process do immediately after execution?

Start with the suspicious device timeline

In Microsoft Defender XDR Advanced Hunting, begin with the device and the approximate investigation window. Review process creation in chronological order rather than searching only for known malware names.
device-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
let Device = "WORKSTATION-01";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          SHA1
| order by Timestamp asc

Which unusual processes did the browser launch?

Next, narrow the hunt to browser-initiated processes. The example list below contains common browsers and several Windows utilities worth reviewing when they appear unexpectedly as descendants. Their presence is not automatically malicious — context is what matters.
browser-child-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
  15. 15
  16. 16
  17. 17
  18. 18
let Browsers = dynamic([
    "msedge.exe", "chrome.exe", "firefox.exe"
]);
let ReviewProcesses = dynamic([
    "powershell.exe", "pwsh.exe", "cmd.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe",
    "wscript.exe", "cscript.exe"
]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (Browsers)
| where FileName in~ (ReviewProcesses)
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName,
          ProcessCommandLine, SHA1
| order by Timestamp desc

Follow the process into the network

Finding an unusual child process is a lead. Correlating that process with outbound network activity adds context. Use the process identity and timing to determine whether the same executable connected to an unexpected remote host shortly after it launched.
process-network-pivot.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
let Device = "WORKSTATION-01";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| where InitiatingProcessFileName in~ (
    "powershell.exe", "mshta.exe",
    "rundll32.exe", "regsvr32.exe"
)
| project Timestamp, DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl, RemoteIP, RemotePort
| order by Timestamp asc

Was the same behaviour happening elsewhere?

A single endpoint can be an isolated event. The same unusual parent-child relationship across several devices can indicate something larger. Hunt the behaviour across the environment rather than relying only on the original alert or device.
environment-process-hunt.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
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (
    "msedge.exe", "chrome.exe", "firefox.exe"
)
| where FileName in~ (
    "powershell.exe", "mshta.exe",
    "rundll32.exe", "regsvr32.exe",
    "wscript.exe", "cscript.exe"
)
| summarize Events=count(),
            Devices=dcount(DeviceId),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp)
    by InitiatingProcessFileName, FileName,
       ProcessCommandLine
| order by Devices desc

Why legitimate Windows tools matter

Attackers do not always need to place an obviously malicious executable on disk. Windows includes powerful signed utilities that administrators, applications and the operating system use legitimately. Those same utilities can sometimes be abused to execute commands, scripts or other content.

This is why the presence of a legitimate Microsoft binary does not settle the investigation either way.

Signed does not mean suspicious. Signed also does not mean safe in every context.
PowerShellEssential administration technology that also deserves context when launched unexpectedly.
Script hostsWScript and CScript may be legitimate, but their parent process and command line matter.
Other utilitiesMSHTA, Rundll32 and Regsvr32 should be interpreted by behaviour, ancestry and surrounding evidence.

Build the chain, not just the event

Suppose the timeline shows the browser starting an unusual Windows utility, which then creates another process, followed seconds later by an outbound connection. None of those events should be judged in isolation.

The browser may be legitimate. The Windows utility may be legitimate. The destination may not yet have a malicious reputation verdict.

But together, the sequence may be inconsistent with normal user behaviour.

The process tree provides the story that a clean antivirus scan cannot.
10:14:02 — BrowserThe user is browsing normally.
10:14:07 — Child processA Windows utility appears beneath the browser in an unexpected context.
10:14:10 — NetworkThe process initiates outbound activity that now needs to be explained.

What Agent Foskett checked

Parent processWhat actually launched the suspicious process?
Command lineWhat arguments, URLs, paths or encoded content were supplied?
Process ancestryDoes the complete execution chain make sense for the user and application?
Network activityDid the process communicate externally after launch?
File activityWere scripts, payloads or temporary files created around the same time?
Environment prevalenceWas the behaviour unique to one device or repeated elsewhere?

What the evidence can and cannot prove

A clean antivirus scan is valuable evidence. It means the scan did not identify malware according to the detections and content available at that time. It should not be rewritten as proof that no malicious activity occurred.

Likewise, seeing PowerShell, Rundll32, MSHTA or another legitimate utility does not prove compromise. Administrators and applications use these tools every day.

The conclusion comes from correlation: process ancestry, command line, timing, network behaviour, file activity, prevalence and the user's expected workflow.

The lesson

The antivirus scan was clean.

That was true.

But the process tree showed behaviour the scan result could not explain.

Agent Foskett did not need to argue with the antivirus result. He simply asked a different question:

What actually happened on the endpoint?

That question led from the browser, through the child processes, into the network telemetry — and turned an apparently clean endpoint into a proper investigation.
Investigation principle: No malware detection does not mean no malicious behaviour. Follow the process tree.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.Who is Agent Foskett?Meet the investigator behind the case files and the principle: follow the evidence.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The scan was clean. The behaviour wasn't.
Don't stop at the verdict. Follow the process tree.
Continue the Investigation

Final thought

Security products produce verdicts. Investigators build explanations.

Sometimes those two things align immediately. Sometimes the most important evidence sits outside the detection itself — in the parent process, command line, network connection or sequence of events.

Follow the evidence. Build the timeline.

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 Antivirus Scan Was Clean — The Process Tree Wasn't

This Agent Foskett case file examines a Microsoft Defender XDR endpoint investigation where no malware was detected, but process ancestry and network telemetry revealed behaviour that still required investigation.

Microsoft Defender XDR Process Tree Investigation With KQL

Use DeviceProcessEvents and DeviceNetworkEvents to investigate browser child processes, command lines, living-off-the-land utilities, outbound connections and suspicious execution chains across Windows endpoints.

A Clean Antivirus Scan Is Not the End of the Investigation

Antivirus detections are important evidence, but behavioural telemetry can reveal suspicious execution even when no file receives a malicious verdict. Process ancestry, command-line context and network activity help analysts reconstruct what actually happened.