Is command-line activity in command shells (e.g. PowerShell, bash) logged and monitored?
Modern intrusions run on tools already present on the system. Command-line logging is what makes that activity visible at all.
What the carrier is actually asking
The carrier is asking whether commands executed in shells such as PowerShell and bash are recorded and watched. It is asking about a specific log source because that source is where living-off-the-land activity shows up.
Why it is underwritten
Attackers stopped bringing their own tools. They use the administrative tooling already installed, which produces no malware detection and no unusual file. The command line is where the activity is visible, and it is invisible unless script block logging and process command-line auditing are enabled.
Where the answer lives in Microsoft 365, Entra ID, and Azure
These are endpoint policy settings that Insurance Posture does not read, so this is attested. It is worth checking because the settings are off by default.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Endpoint policy | PowerShell script block logging and module logging | Script block logging enabled, which records the actual commands including obfuscated ones after decoding. Attested |
| Endpoint policy | PowerShell transcription | Transcription to a protected location, giving a readable session record |
| Endpoint policy | Process creation auditing with command line included | Enabled, since without it process events record the executable and not the arguments |
| Endpoint policy | Constrained language mode and script execution policy | Restriction as well as logging, which pairs with the application control answer |
| Collection | Whether these logs are forwarded and alerted on | Forwarded centrally with detection rules, since the volume makes local-only storage useless |
Version 2 of PowerShell does not honour script block logging and remains present on many systems. Removing it is a standard hardening step and it is skipped often enough that attackers still check for it.
What a defensible yes requires
- Script block logging and process command-line auditing are enabled by policy.
- Logs are forwarded centrally, not only stored on the host.
- Detection rules exist for suspicious command patterns.
- Legacy shell versions that bypass logging are removed.
- Coverage extends to servers, which is where the highest-value command-line activity happens.
How this answer goes wrong
The answer is yes because PowerShell logging appears in the security baseline, while the baseline applies to workstations and not to servers, and legacy PowerShell is still installed on older machines. The most valuable population is the one not covered.
Frequently asked
Does this generate too much data?
Volume is real and manageable with filtering at collection. The investigative value per gigabyte is among the highest of any source.
What about bash and Linux?
Shell history and audit framework logging are the equivalents and are worth enabling for the same reasons.
Is logging enough without monitoring?
It gives you forensics. Detection needs rules. Most managed detection providers include command-line detections, which makes this a good source to hand them.
Does application control replace this?
No. Application control restricts what can run; command-line logging records what did. Carriers ask about both.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture