Case Study 1 — The Service That Started at 3 A.M.

A finance workstation issues a fraudulent wire transfer over a holiday weekend. There is no eyewitness, no email confession, and the attacker cleared the Security log on the way out. The Windows artifacts that the attacker did not know to erase rebuild the intrusion minute by minute.

Background

A regional accounting firm processes client payroll and vendor payments from a small number of locked-down Windows 10 workstations. On the Tuesday after a long holiday weekend, a controller notices a $48,000 wire to an unfamiliar beneficiary, approved — according to the banking portal — from workstation FIN-WS-02 at 03:24 on Sunday morning, when the office was empty and alarmed. The firm engages you for incident response. Following Chapter 15 — Live Response and Triage you capture volatile data and a triage set, then acquire and hash a full image, FIN-WS-02.E01, with a clean chain of custody per Chapter 14 — Forensic Acquisition. The question for the examination is narrow and consequential: how did someone operate this machine at 3 a.m., and is there evidence of remote access and persistence?

The investigation

You start where intrusions usually announce themselves — the Security log — but the very first finding is an absence. EvtxECmd parses Security.evtx and the record sequence ends abruptly Sunday at 03:31, with a final event 1102: "the audit log was cleared." The attacker tidied up. Clearing the log, though, is itself an event: 1102 records the account that performed the clear (svc_helpdesk) and the exact time, and it leaves a conspicuous gap that the other logs and the registry do not share. The absence is the first trace.

You pivot to the records that survived the clear. The System log is untouched, and it is loud:

EvtxECmd → System.evtx (excerpt, UTC)
03:18:07  EventID 7045  Service Installed
          Service Name:  WinDefendUpd
          Image Path:    C:\Users\Public\Libraries\svc.exe
          Start Type:    Auto
03:18:09  EventID 7036  WinDefendUpd entered the Running state
03:30:55  EventID 1074  Shutdown initiated by NT AUTHORITY\SYSTEM, process svc.exe

A service named to impersonate Windows Defender, autostarting from C:\Users\Public\Libraries\ — a writable directory no legitimate service binary lives in — is a textbook persistence indicator (theme: every action leaves a trace). You confirm it in the registry: SYSTEM\ControlSet001\Services\WinDefendUpd exists, Start = 2 (auto), ImagePath pointing at the same svc.exe. (You read ControlSet001, not the runtime-only CurrentControlSet, and confirm via SYSTEM\Select\Current that set 1 was current.)

Now: did svc.exe actually run, and what is it? You separate presence from execution deliberately. Amcache (AmcacheParser) lists C:\Users\Public\Libraries\svc.exe with SHA-1 5f1a…e93c and a PE compile time of three days before the incident — that is presence plus an identity. You submit the SHA-1 to a reputation service; it matches a known remote-access trojan family. But Amcache alone does not prove execution, so you turn to Prefetch: SVC.EXE-3C7E2A11.pf exists, PECmd reports a run count of 1 and a last-run time of 03:18:11 — execution, with a timestamp, corroborating the 7045/7036 pair to the second. BAM under SYSTEM\…\bam\State\UserSettings\<SID> lists svc.exe with a last-execution time in the same minute for the svc_helpdesk SID, tying the run to that account.

Where did svc_helpdesk come from? It is not a real person. The SAM hive shows a local account svc_helpdesk, created Sunday 03:14, login count 1, with the friendly description blank. The pre-clear portion of the Security log is gone, but you find the creation echoed in the surviving artifacts and the account's NTUSER.DAT itself — a profile directory C:\Users\svc_helpdesk\ created at 03:15. Its MountPoints2 is empty (no USB), but UserAssist in that hive shows cmd.exe and svc.exe launched at 03:16–03:18.

The remaining question is how the attacker reached the box. RDP is the hypothesis (a 3 a.m. hands-on session on a physically secured machine), and you confirm it from logs the attacker forgot existed. The specialized operational log Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx survived the Security-log clear and records a session for svc_helpdesk beginning 03:12 from source address 45.s.s.s (an address outside the firm's ranges). The firewall's own log corroborates an inbound 3389 connection. The picture is complete: external RDP at 03:12 → local admin account created 03:14 → tooling run 03:16–03:18 → persistence service installed 03:18 → fraudulent wire 03:24 → Security log cleared 03:31 → remote shutdown 03:31.

FIN-WS-02 — RECONSTRUCTED INTRUSION (UTC)
03:12  RDP session opens, user svc_helpdesk, src 45.s.s.s   [TS-LocalSessionMgr Operational]
03:14  Local account svc_helpdesk created (login count 1)    [SAM]
03:16  cmd.exe / svc.exe launched                            [UserAssist, NTUSER.DAT]
03:18  svc.exe executes; "WinDefendUpd" service installed    [Prefetch + BAM + 7045/7036 + Services key]
03:24  Fraudulent $48k wire approved                         [bank portal + browser artifacts, Ch.18]
03:31  Security log cleared; remote shutdown                 [event 1102 + 1074]

You hand the wire-portal browser evidence to the workstream covered by Chapter 18 — Browser and Internet Forensics, and fold the timeline into the master timeline method of Chapter 21 — Timeline Analysis.

Before writing a word of the report, you validate the load-bearing findings with a second, independent tool: RegRipper's services and bam plugins reproduce the WinDefendUpd ImagePath and the svc.exe last-execution time that RECmd and PECmd reported, and Autopsy's Recent Activity module independently surfaces the same service and the same Amcache SHA-1. "Three independent tools agree" is the sentence that survives cross-examination under the Daubert expectations of Chapter 27 — Expert Testimony. You also note what you cannot yet prove from Windows artifacts alone — that the source address 45.s.s.s belongs to the attacker rather than a compromised relay, and what the operator's intent was — and you reserve those for the network and account workstreams. There is a dual-lens footnote, too: the same svc.exe SHA-1 that lets the 🔍 examiner identify a known RAT also lets the 🛡️ incident-response team hunt that exact hash across the firm's other endpoints, turning one workstation's finding into an enterprise-wide containment sweep. The remediation that follows — disable inbound RDP at the firewall, rotate every credential, rebuild FIN-WS-02 from known-good media, and recall the wire if the bank's window allows — is driven entirely by the timeline the surviving artifacts made possible.

The analysis

  1. Logon type turns "someone logged on" into a story. A type-10 (RDP) session at 3 a.m. from an external address is not the same finding as a type-2 (keyboard) logon; reading the type — and the source — is what converts an event into a narrative an investigator can act on.
  2. Event-log timestamps are high-trust time anchors. Recorded by the OS at the moment of the event, the 7045/7036/1074 chain is far harder for an attacker to forge than file timestamps, which is exactly why it survives as the spine of the timeline even after the Security log is wiped.
  3. Persistence has a registry fingerprint and a log fingerprint — pair them. Event 7045 (service installed) and the Services\WinDefendUpd key with an ImagePath in a writable public directory corroborate each other; either alone is a lead, the two together are a finding.
  4. Separate presence from execution, then unite them. Amcache gave identity (SHA-1 matching a known RAT) but only presence; Prefetch and BAM supplied execution with timestamps. Stating which artifact answers which question is what makes the conclusion defensible.
  5. Clearing the log is loud, and redundancy defeats it. Event 1102 names who cleared the Security log and when, and the System log, registry, Amcache, Prefetch, and the TerminalServices operational log were all untouched. The attacker erased the one log they knew about and left five they did not — the absence of a trace became a dated trace of its own.

Discussion questions

  1. The attacker cleared Security.evtx but not System.evtx or the TerminalServices operational log. List three other Windows artifact sources, covered in this chapter, that a "clear the Security log" anti-forensic step leaves completely intact, and explain why each survives.
  2. Amcache reported the svc.exe SHA-1 and a known-bad match, but you still consulted Prefetch and BAM before writing "it executed." Why is that discipline worth the extra step, and how would you phrase the conclusion if Prefetch had been disabled on this machine?
  3. The WinDefendUpd service ImagePath pointed at C:\Users\Public\Libraries\svc.exe. Why is the location of a service binary, independent of its name, such a strong persistence signal? Name two legitimate ImagePath locations you would expect for a real service.
  4. ⭐ The local account svc_helpdesk was created at 03:14 with a login count of 1. Construct the strongest defense argument that the workstation owner — not an external intruder — was responsible, then rebut it using only artifacts in this case. What single additional artifact would most strengthen the external-intruder finding?
  5. The fraudulent wire itself was approved through a banking web portal. Which chapter owns that evidence, and what is the risk of an examiner from the Windows-artifacts workstream over-claiming about browser activity they have not properly parsed?