Guide

Auditing Windows services

An audit is not a list of what is on the machine. It is the difference between what is on the machine and what was supposed to be - and nothing on a stock Windows records the second half.

Three questions, and what answers them

What changed since this machine was built?

A snapshot taken at deployment, and a diff against the machine tonight. Configuration is reported apart from what merely started or stopped, so the one start type somebody changed is not buried under forty services that happen to be running.

bws snapshot diff baseline.json --live

Why does staging differ from production?

Take a snapshot on each and diff the two files - anywhere, without either machine present. The files carry the machine name and the account that took them.

bws snapshot diff staging.json production.json

What is on here that should not be?

Queries that find the shapes worth looking at: a service whose binary is gone, one that is not signed, one running although it is disabled, one asking for debug rights.

file:missing, signed:no, mismatch:running

The nightly shape

# the day the machine goes into service
bws snapshot create C:\baselines\web01.json --note "after the build"

# every night, from a scheduled task
bws snapshot diff C:\baselines\web01.json --live --exit-code --json > C:\logs\drift.json
#   0 - no configuration drift
#   5 - the configuration drifted, and drift.json says what
#   3 - it ran and could not read everything, so the answer is partial

Exit code 5 is what makes this an audit rather than a report nobody reads: the task is silent until the machine drifts, and the night it does, somebody is paged.

Take the baseline from an elevated session. Without administrator rights the manager lists fewer entries and refuses more of what it lists. The snapshot records whether the account that took it was an administrator, so the comparison can say that rather than reporting entries as removed that nobody removed - but a baseline missing half the machine is still a baseline missing half the machine.

What a snapshot is worth in evidence

  • It is JSON with one field per line, so it goes into a repository and git diff reads it. An auditor who does not have this tool can still read the file, and a version control system already answers when.
  • It holds what the snap-in never showed: the launch path and arguments, the hash and signer of the file, the dependencies both ways, the triggers, the required privileges, the SID type and the security descriptor.
  • It says what it could not read. A field this session had no rights to is recorded as not read - never as empty - so a later comparison can say not compared instead of quietly calling it unchanged.
  • It is a description of the whole machine. File it accordingly: it is written with whatever permissions its directory already has, and the tool narrows nothing.
How snapshots and diffs work