skip to content

Which artefacts prove that a Run key, service or scheduled task you found actually executed?

level: middleimportance: must knowfreq 60%

answer

  1. configuration is a plan, not an event
  2. installed is not the same as started
  3. each mechanism has a characteristic parent
  4. Prefetch of the payload, not of the key
  5. 7045 versus 7036, 106 versus 200

basics

~20 s

A persistence entry is configuration — an instruction to run later — so it proves nothing ran. Execution proof comes from a separate artefact: a Task Scheduler action-start record, a service state-change record, a Prefetch file for the payload, or a process-creation event.

solid answer

~50 s

Separate the two claims. Registration artefacts say something was set up: System Event ID 7045 for a newly installed service, Task Scheduler Operational 106 or Security 4698 for a registered task, the Run value itself and the key's write time. Execution artefacts say it fired: System 7036 showing the service entered the running state, Task Scheduler Operational 200 (action started) and 129 (created task process), and above all a process-creation record — Sysmon Event ID 1 or Security 4688 — for the payload, plus a Prefetch file for the payload's own path. Corroborate with the launching parent, which differs per mechanism: `services.exe` for a service, `svchost.exe` hosting the Schedule service for a task on modern Windows, `explorer.exe` for a Run-key value at logon. If the payload has no execution artefact, say so explicitly rather than inferring a run from the entry's existence.

code

text · 13 lines
text
System log  Event ID 7045  (Service Control Manager)
  Service Name:       VendorAgentUpdate
  Service File Name:  C:\Program Files\Vendor\agent-update.exe
  Service Type:       user mode service
  Service Start Type: auto start
  Service Account:    LocalSystem
  ... a service was INSTALLED; nothing here says it started

Microsoft-Windows-TaskScheduler/Operational  Event ID 200
  Task Name:   \Vendor\NightlyInventory
  Action:      C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  Instance ID: {f1e2...}
  ... the task's action was LAUNCHED at this record's time

go deeper

for a junior

Be ready to say that finding a Run key, service or scheduled task shows something was configured to run, and that you still need a separate artefact showing it actually ran.

for a middle

Name the pairs: 7045 against 7036, Task Scheduler 106 against 200, the registered value against a process-creation record, and know which parent process each mechanism launches its payload under.

for a senior

Demonstrate the judgment about absence — when no run record is the expected result given the trigger — and how you word registration and execution as two separately evidenced claims.

for a principal

Decide what your organisation collects by default so this question is answerable at all: whether registry-value and task-registration telemetry is retained long enough to make persistence findings datable months later.

### Configuration is a plan, not an event Every persistence mechanism is the same shape: a place where the operating system stores *"run this later, under these conditions"*. A Run value fires when a user logs on. A service fires at boot, on demand, or never if its start type is disabled. A scheduled task fires on its trigger. Finding the entry proves someone wrote it. It does not prove the condition was ever met. That gap is where careless findings are written. "A scheduled task was found that runs a script hourly" quietly becomes "the script has been running hourly for three weeks" by the time it reaches a report, and nobody has looked for a single artefact of a run. ### The registration side | Mechanism | Where it lives | Registration artefact | | --- | --- | --- | | Run key | `...\CurrentVersion\Run` under HKLM or HKCU | The value itself; the key's write time; Sysmon Event ID 13 (registry value set) if Sysmon was running | | Service | `HKLM\SYSTEM\CurrentControlSet\Services\<name>` | System log Event ID 7045 (a service was installed); Security 4697 where the audit policy for it is enabled | | Scheduled task | `C:\Windows\System32\Tasks\<name>` XML plus the `TaskCache` registry keys | Task Scheduler Operational 106 (task registered); Security 4698 (a scheduled task was created) | A trap sits in the Run key row. Registry write times are recorded **per key, not per value**. Adding, changing or deleting any value under `...\Run` updates the single write time on the key, so you cannot date an individual value from the hive. If Sysmon was running you get Event ID 13 for the specific value being set; otherwise the honest statement is a bound, not a time — the value existed by the key's write time and you cannot say when it was added relative to its neighbours. ### The execution side - **Service**: System Event ID 7036 records the service entering the running state; 7000 and 7034 record failures and crashes, which are also evidence of an attempt. - **Scheduled task**: Task Scheduler Operational Event ID 200 records that an action was launched, 201 that it completed and with what return code, and 129 that a task process was created. The task's own `TaskCache` registry data also carries values that parsers surface as last-run and last-success times. - **Any mechanism**: a process-creation record for the payload — Sysmon Event ID 1, which carries the command line, parent image and hashes, or Security 4688, whose command line field is only populated where audit policy was configured to include it. - **Any mechanism, after the fact**: a Prefetch file for the payload's own executable path, which is created when it runs and carries a run count and recent run times. ### Use the parent as corroboration Each mechanism launches its payload through a characteristic parent, and that parent is what ties the execution record back to the persistence entry rather than to some other way the same binary might have been started: - service payload → parent `services.exe` - scheduled task action → parent `svchost.exe` hosting the Schedule service on modern Windows (`taskeng.exe` on Windows 7) - Run value → parent `explorer.exe`, at that user's logon A payload with a Prefetch file but a process-creation record whose parent is a remote-management agent ran, but it did not run *via the persistence you found*. That distinction changes what you have proven. ### When absence is expected rather than suspicious A logon-triggered task on a server nobody has logged into since registration *should* have no execution artefacts. The absence corroborates the story instead of contradicting it. Equally, a service with start type 4 (disabled) will show 7045 and no 7036. Reading absence needs the trigger condition in hand; without it, absence means nothing in either direction. ### The sentence to write *"A scheduled task `\Vendor\NightlyInventory` was registered on 2026-03-02 (Task Scheduler Operational 106). Task Scheduler Operational 200 records its action launching on each of the following twenty-one nights, and a Prefetch file exists for the interpreter it launches. Both the registration and the runs are therefore established."* Two claims, each with the artefact that carries it, and neither borrowed from the other.

  • What can you date with the write time on a Run key?
    Only the key, never the value. Registry write times are per key, so adding, editing or removing any value under it moves the same timestamp, and the hive gives you no per-value time. You get an upper bound: the value existed by that time. Sysmon Event ID 13 records a specific registry value being set, and comparing against an older hive backup or shadow copy can narrow the window.
  • The task is triggered at logon and nobody has logged into the server since. What does the absence of run records mean?
    It corroborates rather than contradicts. Read absence only with the trigger condition in hand: a logon-triggered task on a host with no logons, or a service with start type disabled, is expected to show registration artefacts and no execution artefacts. Without knowing the trigger, absence of a run record supports no conclusion in either direction.
  • The payload has a Prefetch file, but its process-creation record shows a management agent as the parent. What have you proven?
    That the binary ran, and that on that occasion it did not run through the persistence entry you found. The parent ties an execution back to a specific mechanism — services.exe for a service, the Schedule service's svchost.exe for a task, explorer.exe for a Run value. A different parent means a different launch path, and the persistence entry may still never have fired.

saying these in an interview costs you the question

  • Says the task exists, therefore the payload ran
  • Reads System 7045 as the service having started
  • Dates a specific Run value from the key's write time
  • Treats a Prefetch file for svchost.exe as proof a task ran
  • Reads absence of run records without knowing the trigger

context

resolving links…