Pinpoint malware execution with Windows Event Viewer

To use the Windows Event Viewer to find the exact time malware first executed, you need process-creation records, an accurate clock, and a cautious definition of the first malicious execution. Event Viewer can often answer through event 4688 or Sysmon event 1 when those sources were active beforehand. A logged timestamp proves a process event occurred; it does not automatically prove that the process was malware’s first-ever execution.

Australian time zones add a detail worth checking. Event Viewer normally displays the computer’s local zone: Sydney and Melbourne may show AEDT (UTC+11) during daylight saving, Adelaide uses ACDT (UTC+10:30), and Brisbane stays on AEST (UTC+10). Preserve the zone and UTC offset with every export; otherwise a one-hour difference can move a process outside the incident window.

Small retailers, clinics, and offices in Sydney, Melbourne, and Brisbane often combine Windows endpoints with Microsoft 365 and managed-service monitoring. Administrators may need a defensible timeline under the Privacy Act 1988 and the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner. Local logs remain the primary evidence for a particular machine.

Prepare and preserve the event logs

Begin with a read-only snapshot. Run tzutil /g and Get-TimeZone in an elevated terminal, note the zone, and compare the Windows clock with a network time source. If the clock was altered or the device was offline, the event time may be wrong. Record that uncertainty rather than silently adjusting the timeline.

Then export relevant channels before troubleshooting changes them. An administrator can run wevtutil epl Security D:\Incident\Security.evtx and make similar exports for Sysmon and Defender. Keep originals access-controlled and work from copies. Cleanup utilities and quarantine actions can clear evidence, so preservation should precede remediation.

Enable and understand process creation records

The main built-in source is Security event 4688, which records a new process. Open eventvwr.msc, select Security, choose Filter current log, and enter 4688. Depending on policy, the event can show the new process, account, creator process, process ID, and command line.

If auditing was not enabled earlier, 4688 cannot recreate history. Enable Audit Process Creation through Local Security Policy or with auditpol /set /subcategory:"Process Creation" /success:enable, and include command-line data through approved policy. This affects future events only; document the change rather than presenting it as retrospective evidence.

Check Sysmon event 1 under Applications and Services Logs, Microsoft, Windows, Sysmon, Operational, when Sysmon was already installed. It can include executable path, command line, parent process, and process GUID. For a suspected trojan, trojan execution patterns can separate a malicious child from a normal updater, although a familiar process name alone proves nothing.

Compare the relevant event sources

No channel proves which execution came first. Compare event time, source, record ID, and clock quality instead of screen order.

Evidence source	Key event	What it establishes	Important limitation
Security log	4688	A process was created, with policy-dependent user, parent, and command-line fields	Process auditing must already have been enabled
Sysmon Operational	1	Process creation with richer process relationships	Requires Sysmon to have been installed and configured beforehand
Defender Operational	1116 and 1117	Defender detection and subsequent action	Detection time can lag the first execution
Security persistence logs	4697 and 4698	A service or scheduled task was registered	Registration proves persistence setup, not the first payload run

Defender events establish detection and response, not necessarily execution. Event 1116 reports a detection and 1117 an action such as quarantine; malware may have run before both. Current security news briefings may help relate a detection to a reported campaign, but they do not replace the machine’s records.

Trace the earliest suspicious execution

Start with a narrow time window and the suspected filename, hash, folder, or command line. For each 4688 or Sysmon hit, open Properties and record Time Created, Event ID, Record ID, account, parent image, path, and command line. A child launched immediately after archive extraction or a script is often a better lead than the final payload alone.

Trace backward through the parent chain, then forward through descendants. An archive handler may launch cmd.exe, which launches PowerShell, which drops and starts the payload; the earliest logged process may be a trusted Windows utility acting as intermediary. Search all three channels for that window and treat a log gap as missing coverage, not proof that nothing ran.

The strongest finding states the exact time of the earliest logged suspicious process, its UTC offset, source, and any clock-sync caveat. It cannot claim an exact first execution when auditing began later, the clock drifted, records rolled over, or code ran entirely in memory. File times are supporting evidence because malware can alter them and they show when a file was written, not when Windows started it.

Document findings for a defensible response

Turn the result into an evidence record that a responder, insurer, or regulator can follow. Australian Cyber Security Centre guidance, including the Essential Eight, stresses patching, multifactor authentication, application control, and regular review for Australian organisations; endpoint records help verify those controls.

• Export the relevant Security, Sysmon, and Defender channels as EVTX before cleanup.
• Record original UTC time, local offset, clock source, event IDs, and record IDs.
• Enable process-creation auditing and command-line inclusion through managed policy.
• Retain logs centrally with restricted administrator access and adequate capacity.
• Calculate SHA-256 hashes and document each suspect file’s path, size, and signer.
• Record containment actions and preserve the timeline used for notification decisions.

Keep the exports, event timeline, hashes, and containment record together. Under the Privacy Act 1988 and the Notifiable Data Breaches scheme, these details support assessment of affected data and notification duties; the malware start time is one fact in that assessment, not the legal conclusion.