Unusual Start Time

Red Flags

The core processes of session 0, where Windows runs its own services, start together within moments of each boot, and each session's own copies start as that session is created. Windows does not start them again later, and several are critical processes whose end stops Windows. A core process that started hours after its siblings is usually a copy run under the name, or a clone, and a start that lines up with an intrusion ties a process to it. Read the last full restart first, since with Fast Startup a shutdown hibernates the kernel session rather than closing it, then compare each core process with its siblings.

Normal and Suspicious

A clean machine sits beside a suspicious one, and the pointer marks where to look.

Normal

ws-017,

An illustration from ws-017, dana's workstation, after its boot at 07:57 on 19 Oct 2026.
NameParentStarted
wininit.exesmss.exe, exited07:58:15
lsass.exewininit.exe07:58:16

Suspicious

ws-017,

An illustration from the same workstation, ws-017, later on 19 Oct 2026, with the first copy still running.
NameParentStarted
lsass.exewininit.exe07:58:16
lsass.exelsass.exe11:42:09
StartedStarted nearly four hours after boot: session 0's core processes start together at boot. Unusual Start Time

Why It Matters

Session 0's core processes start together at boot and a session's own as that session is created, so a late copy needs a reason. A start that lines up with the intrusion ties a process to it.

How to Confirm It

Work through these in order. Each step names the page that shows how.

  1. Read the last full restart and each session's sign-in first. With Fast Startup on, the default, shutting down hibernates the kernel session rather than closing it, so only a restart resets session 0's clock.Process Listings and Scans
  2. Compare each core process with its siblings. Session 0's start together at boot, and a session's own as that session is created, so one copy out of step is the lead.Process Listings and Scans
  3. Ask what could have restarted it. Microsoft lists csrss.exe, wininit.exe, services.exe and winlogon.exe among the critical processes whose end stops Windows with bug check 0xEF, so a copy that started long after its session began is not a restart.Process Trees and Call Chains
  4. Set the start against the incident timeline. PSEXESVC.exe started on ws-042 at 09:58:13, the minute psexec.exe ran in alice's session, which ties it to that run.Process Trees and Call Chains

What Defenders See

Each record names its log and what must be switched on to get it.

Record and Where It LandsWhat to ReadHow to Turn It On
DeviceProcessEvents (opens in a new tab)Each row is a process creation or a related event, naming the new process, the process that created it and that creator's parent.Defender XDR, advanced huntingProcessCreationTime for each start, with the boot taken as the creation of the same boot's wininit.exe, where the sensor recorded it.The Defender for Endpoint sensor on the device
4688 A new process has been created (opens in a new tab)SecurityIt is written on the computer the process ran on.When each process started, to set against event 4608 in the Security log, which Windows writes as lsass.exe starts at boot.Process Trees and Call Chains shows how to read it.Turn on Audit Process Creation. For the command line, also turn on Include command line in process creation events.
1 Process creation (opens in a new tab)Microsoft-Windows-Sysmon/OperationalIt is written on any Windows computer running Sysmon.UtcTime of each start. Sysmon logs from early in the boot, so session 0 has a dated record.Process Trees and Call Chains shows how to read it.Run Sysmon with ProcessCreate events in its configuration.
5 Process terminated (opens in a new tab)Microsoft-Windows-Sysmon/OperationalIt is written on any Windows computer running Sysmon.When an earlier copy ended, which tells a replacement from a second copy running beside the first.Process Trees and Call Chains shows how to read it.Run Sysmon with ProcessTerminate events in its configuration.
False Positives

Services start when they are installed or started, delayed ones shortly after boot and trigger-start ones when their trigger fires, and the shell can be restarted without a new sign-in. Judge these by why they started.

With Fast Startup on, session 0's processes can be days older than the person's sign-in. That is normal, not late.

Blind Spots

A record that begins after the process started cannot date it. A sensor installed later, or a log that has rolled over, leaves only the live start time.

Start time flags only what came late, so anything that runs from a service or a driver starts with the boot and passes this check.

Hunt It

The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.

Sees It DirectlyDeviceProcessEvents (documentation, opens in a new tab)

Needs Defender for Endpoint and the boot's wininit.exe creation in the table. A device not restarted within the window, or whose sensor missed it, returns nothing, so check it live. A hit is a core process started well after its own boot.

KQLDefender XDR, Advanced hunting
// lsass.exe, services.exe and LsaIso.exe created long after their boot's wininit.exe, which Windows starts once per bootlet boots = DeviceProcessEvents    | where Timestamp > ago(30d)    | where FileName =~ "wininit.exe"    | project DeviceId, WininitStarted = ProcessCreationTime;DeviceProcessEvents| where Timestamp > ago(30d)| where FileName in~ ("lsass.exe", "services.exe", "LsaIso.exe")| join kind=inner boots on DeviceId| where WininitStarted <= ProcessCreationTime| summarize WininitStarted = max(WininitStarted) by DeviceName, FileName, FolderPath, ProcessCreationTime, InitiatingProcessFileName| extend MinutesAfterWininit = datetime_diff("minute", ProcessCreationTime, WininitStarted)| where MinutesAfterWininit > 10| order by MinutesAfterWininit desc

In a Memory Image

Volatility 3 reads a memory image, and each of its plugins below shows part of this sign.

  • windows.pslist (documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. pslist means process list. Each process's create time, and its exit time if it ended. Set session 0's core processes against the create time of smss.exe, the first user-mode process at boot.
  • windows.psscan (documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. psscan means process scan. Exited copies with their exit times, so a copy that ended before its replacement started shows as such.
  • windows.info (documentation, opens in a new tab)Memory Image A Volatility 3 plugin. It is one check run on a saved copy of a Windows machine's memory. The build and the capture's own system time, so every start reads against the right clock and baseline.

How to Prevent It

Each control helps prevent it, and its line says what it does here.

Related

Where It Matters Most
  • smss.exe A copy that started long after boot with no new session to explain it.
  • csrss.exe A copy that started long after its session began, since a genuine one cannot restart without stopping Windows.
  • wininit.exe A copy that started long after the last full boot, since a critical process cannot restart without stopping Windows.
  • services.exe A copy that started long after the last full boot, since it cannot restart without stopping Windows.
See Them in the Tree
Travels with
Check It in the Registry
Last Shutdown Time

Sources

MITRE ATT&CK is a free public catalogue of the techniques attackers use. Each technique has an ID, such as T1055 for Process Injection, so defenders can name the same behaviour the same way. This red flag can point to these techniques.