How can you detect attackers clearing PowerShell command history on Windows?

What to look for when PowerShell history disappears

Cleared PowerShell history is usually an attempt to remove evidence of interactive activity, so the first signal is not the absence of history alone, but a change in the normal sequence of events. Look for deletion or truncation of the history file, a sudden reset in recent commands, or a command pattern that suggests the user intentionally wiped traces after using PowerShell for discovery, staging, or execution.

That pattern becomes more meaningful when it lines up with other telemetry. If you see PowerShell sessions, script block logging, and a user logon close together, then a blank or shortened history may be part of an attempt to hide what was done in that session rather than a routine cleanup by a legitimate operator. The context around the session matters more than the file state by itself.

Which supporting signals make the detection stronger?

PowerShell history is most useful as a corroborating signal, not as a standalone verdict. Tie it to the surrounding process lineage, the account involved, and the timing of recent activity. A cleared history after suspicious commands, encoded content, or reconnaissance behavior is more actionable than a cleared history on its own, because it suggests the actor already used the shell and then tried to erase the trail.

It also helps to compare multiple sources of evidence. Script block logging can show what ran even if the console history is gone, while process creation and logon records can show who executed PowerShell and from where. If those records show an interactive session followed by an abrupt loss of history, you have a better basis for treating the event as concealment rather than an ordinary administrative action.

How should defenders investigate and confirm abuse?

Start by checking whether the history file was deleted, overwritten, or truncated, then compare that timestamp with PowerShell execution, logon activity, and nearby file or process events. If the same host also shows reconnaissance commands, download activity, or payload execution, treat the cleared history as part of a broader post-exploitation cleanup pattern.

It is also worth checking whether the account is expected to use PowerShell interactively. Shared admin workstations, jump hosts, and automation accounts can create noisy baselines, but deliberate history removal on a user workstation often stands out. In practice, the best confirmation comes from showing that the disappearance of history aligns with other signs of active session use, not just with a system maintenance event.

Risk and Threat Considerations

Cleared PowerShell history can hide low-friction attacker activity, especially when an intruder is using the shell for discovery, local execution, or short-lived staging on a Windows host. The risk is not the file deletion itself, but the loss of a lightweight investigative trail that would otherwise help distinguish normal administration from interactive intrusion.

Failure mechanism: An attacker runs commands in an interactive PowerShell session, then deletes or truncates the history file to reduce forensic visibility. If that removal happens after reconnaissance or payload execution, defenders may lose the easiest record of what was typed and when.

Impact: Incident triage becomes slower, command reconstruction becomes harder, and earlier compromise can be missed. That can delay containment, especially when the same host is also used for lateral movement or follow-on execution.

Practitioner Guidance

What to prioritize: Correlate history-file changes with PowerShell script block logging, logon events, and process creation before deciding whether the event is benign. A single cleared history entry is weak; a cleared history immediately after suspicious shell use is materially stronger evidence.

What to verify: Confirm whether the account, host role, and timing fit normal administrative behavior. On systems where PowerShell is used for sensitive administration, absence of history should be treated as a detection cue that requires context, not as proof of compromise by itself.

Practitioner takeaway: The key judgment is whether the missing history sits inside a broader interactive attack sequence. If it does, investigate the session as concealment and not as a routine cleanup event.

Related resources from NHI Mgmt Group

• Guide: PowerShell Security Guide
• How do you detect attackers searching for credentials in files and the registry on Windows?
• How do attackers bypass AMSI on Windows and how do you detect it?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?