Agent Foskett Case File • Microsoft Defender XDR • DeviceNetworkEvents • DeviceProcessEvents • HTTPS • Network Investigation

The Firewall Allowed HTTPS — The Destination Was the Problem

The outbound connection did not look unusual.

TCP 443.
HTTPS.
Allowed by policy.

Nothing in the firewall decision said the connection was malicious.

But Agent Foskett was not investigating whether the traffic was permitted.

He was investigating where the device connected, which process initiated it and what happened immediately before the connection.

The protocol was normal.

The destination was not.

Agent Foskett investigating suspicious HTTPS network activity in Microsoft Defender XDR
Allowed Traffic. Wrong Destination.

Port 443 explained how the connection travelled. It did not explain why the process made the connection or whether the remote destination belonged in the device's normal activity.

✓ Identify the initiating process
✓ Investigate the remote destination
✓ Reconstruct the endpoint timeline

The firewall had done exactly what it was configured to do

The connection was outbound HTTPS traffic over TCP 443.

That is ordinary enterprise traffic. Blocking every HTTPS connection would make modern business systems unusable.

So an allowed firewall event was not evidence that the destination was trusted. It only showed that the traffic matched a rule that permitted the connection.

The firewall answered whether the traffic was allowed. The investigation asked whether the destination made sense.

Start with DeviceNetworkEvents

Agent Foskett began in Microsoft Defender XDR with DeviceNetworkEvents. The table can associate network activity with endpoint and initiating-process context, making it useful for moving from a remote destination back to the process responsible for the connection.

He started with the affected device and the investigation window.
device-network-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
let Device = "FINANCE-LT-07";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| project Timestamp, DeviceName, ActionType,
          RemoteUrl, RemoteIP, RemotePort, Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName
| order by Timestamp asc

Port 443 was not the interesting field

The connection used a common destination port. That was expected.

The important evidence was the combination of fields around it: the remote URL or IP address, the initiating process, its command line, the account context and the exact timestamp.

A browser connecting to a known business service can be routine. An unexpected process making repeated outbound connections to an unfamiliar destination deserves a different level of scrutiny.

Protocol alone does not establish intent.

Which process made the connection?

Agent Foskett narrowed the network events to the destination under investigation and inspected the initiating-process evidence.
destination-process-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
let Destination = "suspicious-example.test";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl =~ Destination
| project Timestamp, DeviceName, RemoteUrl,
          RemoteIP, RemotePort,
          InitiatingProcessFileName,
          InitiatingProcessFolderPath,
          InitiatingProcessCommandLine,
          InitiatingProcessSHA1,
          InitiatingProcessParentFileName
| order by Timestamp asc

The process changed the meaning of the event

The network event was no longer just “HTTPS traffic.”

Agent Foskett could now ask whether the initiating executable was expected, whether its path made sense, whether its command line matched normal behaviour and whether its parent process explained how it started.

That context matters because the same remote connection can mean very different things depending on the process that created it.

A network connection without process context is only part of the story.
Investigation principle: Pivot from the destination to the process, then from the process to the execution chain.

Pivot into DeviceProcessEvents

The initiating-process evidence provided the next pivot. Agent Foskett searched DeviceProcessEvents around the same time to reconstruct how the process started and what surrounded 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
let Device = "FINANCE-LT-07";
let ProcessName = "example.exe";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ Device
| where FileName =~ ProcessName
   or InitiatingProcessFileName =~ ProcessName
| project Timestamp, FileName, FolderPath,
          ProcessCommandLine, SHA1, AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

What happened immediately before the connection?

This was where the investigation became a timeline rather than a collection of isolated events.

Agent Foskett looked for the process creation, its parent, nearby file activity, command execution and the first outbound connection.

If the executable had appeared moments earlier in a user-writable location, or had been launched by an unexpected parent, that context would matter. If it were a known managed application following its normal execution path, that would matter too.

The goal was not to make the evidence suspicious. The goal was to explain it.

How common was the destination?

One device connecting to an unfamiliar destination can be significant, but prevalence helps establish context. Agent Foskett searched the wider environment to determine how many devices and processes had contacted the same destination.
destination-prevalence.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
let Destination = "suspicious-example.test";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl =~ Destination
| summarize Connections=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Devices=dcount(DeviceId)
    by RemoteUrl, InitiatingProcessFileName
| order by Connections desc

Rare does not automatically mean malicious

A destination seen on only one device may deserve attention, but rarity is not a verdict.

New SaaS services, vendor update systems, development infrastructure and legitimate one-off workflows can all produce low-prevalence destinations.

Agent Foskett treated prevalence as one piece of evidence and correlated it with process lineage, file reputation, user activity, destination context and the surrounding timeline.

Rare is a reason to investigate. It is not a reason to convict.

IP address and domain tell different parts of the story

Agent Foskett preserved both RemoteUrl and RemoteIP where available.

A domain can provide naming context, while an IP address can help correlate connections even when hostname information is absent. But shared hosting, CDNs and cloud infrastructure mean an IP address alone may represent many unrelated services.

Likewise, a domain name alone does not prove the content or intent of a specific encrypted session.

Destination evidence must be interpreted in context.

HTTPS protected the session — not the analyst's conclusion

Encryption is expected and valuable. HTTPS protects data in transit between endpoints.

But encryption does not certify that every destination is legitimate. Threat actors can use HTTPS just as legitimate services do.

Microsoft Defender XDR endpoint telemetry can still provide useful surrounding evidence such as the initiating process, remote destination, timestamps and device context even when the application payload itself is encrypted.

Encrypted traffic can still leave an investigative trail.

Look for other devices contacting the same destination

If the destination appeared elsewhere, Agent Foskett wanted to know whether the same process was responsible or whether the pattern crossed multiple applications and devices.
destination-across-devices.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
let Destination = "suspicious-example.test";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl =~ Destination
| summarize Connections=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp)
    by DeviceName,
       InitiatingProcessFileName,
       InitiatingProcessSHA1
| order by LastSeen desc

The investigation was bigger than the firewall

By this point, the firewall decision had become almost incidental.

The useful questions were now:

Which endpoint made the connection?
Which process initiated it?
How did that process start?
Was the executable expected?
Was the destination common or rare?
Did other devices contact it?
What happened before and after the connection?

That is the difference between reviewing a rule and investigating an event.

Build the connection timeline

Agent Foskett organised the evidence chronologically.
Process startsIdentify the executable, path, command line, account and parent process.
Network connectionRecord the destination, IP address, port, protocol and initiating process.
Destination scopedDetermine whether the destination appears elsewhere in the environment.
Process scopedCheck whether the same executable or hash appears on other endpoints.
Surrounding activityCorrelate nearby process, file and network evidence.
Verdict formedDecide from the combined evidence whether the activity is expected, suspicious or confirmed malicious.

What Agent Foskett checked

Remote destinationWhat domain or IP address received the connection?
Initiating processWhich executable actually created the network event?
Process lineageWhat launched the process and did the chain make sense?
PrevalenceHow common were the destination and process across the environment?
TimelineWhat occurred immediately before and after the connection?
Business contextCould the destination be explained by an approved application or service?

What the evidence can and cannot prove

An allowed connection does not prove that the remote destination was trustworthy.

Likewise, a connection to an unfamiliar destination does not by itself prove compromise. The initiating process, process lineage, destination reputation and ownership, prevalence, device role and surrounding activity all matter.

Endpoint network telemetry can establish valuable connection metadata and process context, but analysts should not claim to know the contents of an encrypted session unless another evidence source actually provides them.

Follow the connection far enough to explain it — but do not invent what the telemetry cannot see.

The lesson

The connection used HTTPS over TCP 443 — ordinary enterprise traffic.

Agent Foskett used DeviceNetworkEvents to identify the destination and initiating process, pivoted into DeviceProcessEvents to reconstruct the execution chain, checked prevalence across the environment and rebuilt the surrounding timeline.

The protocol looked normal.

The destination required investigation.

A permitted connection is not necessarily a trusted connection.
Investigation principle: A permitted network path does not remove the need to investigate the process, destination and surrounding endpoint activity.
The connection was allowed. The destination still needed explaining.
Follow the process. Investigate the destination. Build the timeline.
Continue the Investigation

Final thought

TCP 443 is not a trust decision.

HTTPS is not a verdict.

When an outbound connection matters, identify the process that created it, investigate the remote destination, establish how common the behaviour is and reconstruct what happened around the event.

The firewall answered whether the connection was allowed.

Agent Foskett asked whether it belonged.

Follow the evidence. Build the timeline.

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

The Firewall Allowed HTTPS — The Destination Was the Problem

This Agent Foskett investigation examines allowed HTTPS network activity in Microsoft Defender XDR and shows how DeviceNetworkEvents can identify the remote destination and initiating process.

Investigating Suspicious HTTPS Connections with DeviceNetworkEvents

Use Microsoft Defender XDR advanced hunting to correlate RemoteUrl, RemoteIP, RemotePort and initiating process evidence, then pivot into DeviceProcessEvents to reconstruct the execution chain.

KQL Network Investigation in Microsoft Defender XDR

Hunt across endpoint network events to establish destination prevalence, affected devices, process hashes and the timeline surrounding suspicious outbound connections.