Agent Foskett • Microsoft Defender XDR • DeviceNetworkEvents
The Connection Happened At 1:22AM
At exactly 1:22AM, a workstation connected to an IP address nobody recognised.
No alert fired.
Nobody was supposed to be working.
The time of the connection changed everything.
This Agent Foskett investigation explores how defenders can use DeviceNetworkEvents and KQL to investigate suspicious after-hours activity in Microsoft Defender XDR.
Briefing summary
A connection may look routine until the timestamp says otherwise. DeviceNetworkEvents helps defenders see where a device connected, which process made the connection and whether the timing fits normal business activity.
Find after-hours connections
Correlate timing with processes
Pivot to surrounding activity
Why after-hours network traffic matters
Security teams often focus on what connected, but timing can be just as important. DeviceNetworkEvents can reveal whether a connection happened during normal work hours, overnight, during a maintenance window or at a time nobody can explain.
The connection may look ordinaryA device can connect to a destination that looks ordinary until the timestamp shows it happened when nobody should have been active.
The timestamp changes the storyOnce a device talks to unknown infrastructure at 1:22AM, the investigation moves from basic connection review into timing, process context and user activity.
The timeline proves the contextDeviceNetworkEvents and DeviceProcessEvents together can show what happened before, during and after the 1:22AM connection.
First hunt: find after-hours connections
Start with DeviceNetworkEvents and focus on overnight activity. This helps surface connections that happened when most users should not be active.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
DeviceNetworkEvents | where Timestamp > ago(7d) | where hourofday(Timestamp) between (0 .. 5) | project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, Protocol, ActionType | order by Timestamp desc
What to reviewLook at the device, process name, remote IP, remote port, protocol and time of day. Overnight connections deserve closer review.
Why it mattersSuspicious timing may be missed if the investigation only focuses on whether the connection was allowed or blocked.
Best next pivotUse the timestamp and initiating process fields to connect after-hours network activity back to process execution and user context.
Second hunt: identify processes active overnight
The process behind an overnight connection matters. PowerShell, rundll32, mshta, scripts or unusual executables running at 1:22AM may tell a very different story from normal daytime activity.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
DeviceProcessEvents | where Timestamp > ago(7d) | where hourofday(Timestamp) between (0 .. 5) | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName | order by Timestamp desc
When after-hours traffic deserves deeper investigation
Not every after-hours connection is malicious. The investigator mindset is to determine whether the timing, destination, process and device behaviour fit normal business activity.
Suspicious timing contextReview whether the activity happened during a maintenance window, scheduled task, update process or a time that cannot be explained.
1:22AM connection timingA connection at 1:22AM may become important when it follows suspicious process execution or happens repeatedly across several nights.
Surrounding behaviourCheck for process creation, file writes, downloads, persistence activity, sign-ins or additional destinations around the same time window.
Third hunt: identify repeated overnight activity
One overnight connection may be explainable. Repeated overnight connections from the same device, process or destination may indicate a pattern worth investigating.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
DeviceNetworkEvents | where Timestamp > ago(30d) | where hourofday(Timestamp) between (0 .. 5) | summarize Connections = count(), Destinations = dcount(RemoteIP), Processes = make_set(InitiatingProcessFileName, 10) by DeviceName | top 25 by Connections desc
Fourth hunt: find connections near the suspicious 1:22AM event
Once a suspicious 1:22AM connection is found, search the surrounding window. The goal is to understand what happened before, during and after the event.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
DeviceNetworkEvents | where Timestamp between ( datetime(2026-05-30 01:12:00) .. datetime(2026-05-30 01:32:00) ) | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort, Protocol, ActionType | order by Timestamp asc
What after-hours telemetry can prove
DeviceNetworkEvents does not prove compromise by itself. It proves communication and timing. When after-hours communication connects to suspicious processes, rare destinations or surrounding endpoint activity, the evidence becomes much stronger.
The device was activeThe connection confirms that the device reached out at a specific time and gives defenders a starting point for the timeline.
The timing matteredThe same connection can mean different things depending on whether it happened at 10:00AM or 1:22AM.
The process pivot remains availableInitiating process fields can connect the after-hours connection back to the executable, command line and parent process chain.
The Agent Foskett investigator mindset
Do not stop because the device looks healthy. Do not stop because no malware was detected. Follow the timestamp and rebuild the timeline from process to network to endpoint activity.
Ask why it happened thenWas the destination expected, was the process normal, and should that device have been active at 1:22AM?
Follow the timestampUse DeviceNetworkEvents, DeviceProcessEvents, DeviceFileEvents and identity telemetry together to understand the activity around the event.
Correlate weak signalsA strange process, rare destination, odd port and 1:22AM timestamp together can explain what no single alert could.
How GEMXIT approaches after-hours endpoint investigations
GEMXIT helps organisations use Microsoft Defender XDR telemetry to move beyond simple endpoint health checks and understand when devices are active, what they connect to and which processes caused the activity.
We review timestamp visibilityWe help check whether DeviceNetworkEvents, DeviceProcessEvents and endpoint telemetry can support time-based investigations.
We build after-hours hunting logicWe help connect DeviceNetworkEvents, DeviceProcessEvents, DeviceFileEvents, identity telemetry and time windows into practical KQL workflows.
We improve investigation readinessWe help teams understand when after-hours activity deserves device isolation, destination blocking, process review, evidence collection or wider endpoint investigation.
Final thought
The connection looked ordinary.
The device looked healthy.
The destination was unfamiliar.
But the biggest clue was the time.
Nobody was supposed to be working.
Yet the device was active.
The connection happened at 1:22AM.
The device looked healthy.
The destination was unfamiliar.
But the biggest clue was the time.
Nobody was supposed to be working.
Yet the device was active.
The connection happened at 1:22AM.
At GEMXITWe help organisations investigate Microsoft Defender XDR, Microsoft Sentinel, endpoint telemetry, DeviceNetworkEvents, after-hours activity and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “What did the device connect to?”
It is: “Why did it happen at 1:22AM, and what happened around it?”
Continue the investigation with The Device Was Talking To Something It Shouldn't, The Process Tree Told The Real Story, Rundll32 Looked Legitimate, The Process Was Signed By Microsoft, The PowerShell Never Triggered An Alert, KQL Threat Hunting, Microsoft Defender KQL Threat Hunting Complete Guide, Microsoft Defender and the GEMXIT Security Review.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD