Windows command-line, script-block and module logging are off by default - which do you enable first?
answer
- three independent switches, not one dial
- arguments before script text
- cheapest interpretive gain first
- secrets in logs is the real objection
- it only ever buys you the future
basics
~20 sCommand-line capture on process creation first: it is the cheapest switch and turns a program name into a statement of what was asked of it. Script-block logging second, on the interpreters that matter. Module logging last, and rarely fleet-wide.
solid answer
~50 sArgue them one at a time, by what each would have answered. **Process command line** (the *Include command line in process creation events* policy, which populates Windows 4688) is first: without it a record says `powershell.exe` ran and nothing about what it was told to do, and the added bytes on an already-flowing stream are small. **PowerShell script-block logging** (event 4104) is second: it records script text as compiled, including what an encoded one-liner expands to, at a real volume cost, so scope it to hosts that actually run scripts. **Module and image-load logging** is last, being extremely verbose and narrowly valuable. State both costs honestly: volume, and the fact that command lines and script bodies carry secrets, so a broadly readable log becomes a credential source. And state the timing constraint: a field that was off produced no record, so this only ever buys you the future.
go deeper
Know that process command-line capture and PowerShell script-block logging are separate settings that are off until someone enables them, and that a record with no arguments cannot tell you what a program was asked to do.
Explain each switch and what it produces: the audit policy setting that populates the 4688 command line, script-block logging writing compiled script text, and module and image-load records as the verbose tier.
Demonstrate the ordering judgment and the costs. Name a question the missing field would have answered, estimate the volume from a pilot rather than guessing, and raise the secrets-in-logs consequence yourself.
Own the estate-wide negotiation: what you ask the platform team for, what you deliberately do not ask for, who accepts the residual risk in writing, and how the collected data is protected once it contains credentials.
## The shape of the argument Windows execution telemetry is not a single dial. It is a set of independent switches, each off by default, each with a different cost, and each answering a different question. The interviewer is testing whether you can make the case one switch at a time rather than demanding "turn on all logging" — which is how these requests get refused wholesale. ### Switch one: the command line on process creation Event **4688** requires the *Audit Process Creation* subcategory to be enabled at all, and even then the arguments are a separate setting: *Include command line in process creation events*, under Administrative Templates > System > Audit Process Creation. Until it is on, a 4688 record tells you a program's path and not one thing about what it was asked to do. This is nearly always the first switch, for three reasons. The marginal cost is a longer string on records that are already being written and shipped. The interpretive gain is enormous: an interpreter or a signed system utility is only meaningful with its arguments. And the field is the one most often missing at exactly the moment somebody asks what a process was doing. The real objection is not volume — it is **secrets**. Passwords, tokens and connection strings get passed on command lines by scripts and installers, and once captured they sit in a log that a wide set of people can read. That objection is legitimate and answerable: tighten who can read the log, and treat the collected data as sensitive. (If Sysmon is deployed, its Event ID 1 already carries the command line unconditionally — but Sysmon is an agent with partial rollout, and the native switch covers hosts it has not reached.) ### Switch two: PowerShell script-block logging Script-block logging, enabled by Group Policy, writes event **4104** to `Microsoft-Windows-PowerShell/Operational` and records the **text of each script block as it is compiled**. That is qualitatively different from a command line: - an encoded or heavily obfuscated one-liner appears in its expanded, readable form, because logging happens after decoding; - content that never reached a command line at all — a script pulled from elsewhere and run in memory, a block constructed at runtime — is still recorded; - a large block is split across multiple messages that you have to reassemble. The costs are equally real: this is high volume on script-heavy estates, and it captures whatever the scripts contain, secrets included. Note also that a limited subset of blocks matching suspicious patterns may be recorded at warning level even without the policy — useful, but far too partial to plan around. ### Switch three: module and image-load records Module logging (PowerShell event 4103, pipeline execution detail) and the sensor's **image-load** records — Sysmon Event ID 7, which reports each module loaded into a process together with whether it is signed and by whom — are the verbose end of the spectrum. Their unique value is that they see something no process-creation record can: a legitimate, signed, expected binary loading a module that has no business being there. But an active workstation loads modules constantly, so this is the switch you scope narrowly rather than enable everywhere. ## Making the case Three things carry the argument with a platform team that owns the endpoint configuration: 1. **Anchor on a real past case.** "Last quarter we could not say what this process was told to do, and this specific field is the one that would have said." A concrete unanswered question beats a general appeal to visibility. 2. **Measure before you ask.** Enable on a pilot ring, measure the added bytes per host per day, and bring numbers rather than fears. Volume estimates offered without measurement are the reason these requests lose. 3. **Say what you will not ask for.** Conceding module logging fleet-wide is what makes the command-line request credible. ## The constraint that makes this urgent Enabling a field changes only the future. A field that was off produced no record, and there is nothing to search, reprocess or recover — the absence of evidence is indistinguishable from the absence of activity. That asymmetry is why this is a pre-incident decision, and why the worst version of this story is not a slow investigation but an intrusion that is never explained at all, because the one field that would have carried the answer was never on.
- What does PowerShell script-block logging capture that a command line cannot?The script text as compiled, after decoding — so an encoded one-liner appears expanded and readable. It also captures blocks that never touched a command line at all, such as a script fetched and executed in memory or built at runtime. Large blocks arrive split across several messages and need reassembling.
- The platform team will accept exactly one of the three. Which do you take and how do you argue it?Take command-line capture. It is the smallest marginal cost on a stream already flowing, and it converts every process record from a program name into a statement of intent. Argue it with a specific past question you could not answer, plus measured bytes-per-host from a pilot ring, and explicitly drop the other two so the ask looks proportionate.
- Why is enabling command-line capture also a security risk in itself?Because scripts and installers pass credentials, tokens and connection strings as arguments. Once captured they live in a log that is often broadly readable and long-retained, turning your telemetry into a credential source. Pair the change with restricted read access to that log and treat the collection as sensitive data.
saying these in an interview costs you the question
- Asks for all logging everywhere with no cost argument
- Believes 4688 records command lines out of the box
- Thinks enabling a field can recover past activity
- Ignores that command lines and scripts capture secrets
- Confuses script-block logging with transcription or module logging