Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows PowerShell · Event 800
The old Windows PowerShell log's record of a command running, written when module logging is switched on. Its value is not the command text — it is the HostApplication field, which carries the full command line of whatever launched PowerShell, including the encoded ones.
Also written as PowerShell Event 800PowerShell 800 pipelineclassic powershell log 800
You will not normally have this. It only appears if someone deliberately turned on PowerShell module logging, which is an administrator setting rather than a default. If you are seeing it on a work laptop, it is your IT department's monitoring doing its job.
The classic Windows PowerShell log survives where the operational log does not: it exists on PowerShell 2.0 hosts, and it keeps recording when an attacker downgrades with -Version 2 to evade script block logging. Event 800 is the workhorse of that log. Read HostApplication before you read anything else — it holds the launching command line, which is where -EncodedCommand shows up even when the pipeline text itself is unremarkable.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
Log Name: Windows PowerShell
Source: PowerShell
Event ID: 800
Level: Information
Computer: DESKTOP-WKS042
Pipeline execution details for command line: Get-ChildItem C:\Users -Recurse.
Context Information:
DetailSequence=1
DetailTotal=1
SequenceNumber=42
UserId=CORP\jbrooks
HostName=ConsoleHost
HostVersion=5.1.19041.4648
HostId=00000000-0000-0000-0000-000000000000
HostApplication=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -nop -w hidden
EngineVersion=5.1.19041.4648
RunspaceId=00000000-0000-0000-0000-000000000000
PipelineId=7
ScriptName=
CommandLine=Get-ChildItem C:\Users -RecurseEverything else in the log line is context.
powershell.exe -EncodedCommand ...A base64-encoded command. Decode it — it is UTF-16LE, so `[Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($s))`. powershell.exe -Version 2A deliberate downgrade to an engine version that predates script block logging and AMSI. powershell.exe -nop -w hidden -ep bypassThe classic combination of no profile, hidden window, and bypassed execution policy. C:\Windows\System32\wbem\wmiprvse.exePowerShell hosted by the WMI provider, meaning the command arrived over WMI rather than from a console. ConsoleHostAn interactive powershell.exe session. Windows PowerShell ISE HostThe ISE. ServerRemoteHostA remoting session — the command came in over WinRM from another machine. Default HostA custom host, meaning some other program embedded the PowerShell engine rather than launching powershell.exe. Most of the time it is one of these.
What gives it awayEngineVersion 2.0 in the event on a Windows 10 or later host. Version 2.0 predates both mechanisms, so the operational log will be comparatively quiet while this log keeps recording.
ATT&CK T1059.001What gives it awayHostApplication containing -EncodedCommand, -enc, or -e followed by base64. The pipeline field may look innocuous while the launching command line does not.
ATT&CK T1027.010What gives it awayHostName of ServerRemoteHost, or a HostApplication of wsmprovhost.exe or wmiprvse.exe. Both mean the command originated on another machine.
ATT&CK T1021.006What gives it awayHostName of 'Default Host' with a HostApplication that is not a PowerShell binary — the engine was loaded by something else, which is what tooling built to avoid powershell.exe does.
ATT&CK T1059.001Get-WinEvent -LogName 'Windows PowerShell' -FilterXPath "*[System[(EventID=800)]]" -MaxEvents 100 | Select-Object TimeCreated, Message | Format-ListGet-WinEvent -LogName 'Windows PowerShell' | Where-Object { $_.Message -match 'EngineVersion=2' } | Select-Object TimeCreated, Id, MessageEvent | where EventLog == 'Windows PowerShell' and EventID == 800 | where RenderedDescription has_any ('-enc','-EncodedCommand','FromBase64String','-w hidden','-nop') | project TimeGenerated, Computer, UserName, RenderedDescriptionindex=wineventlog source="WinEventLog:Windows PowerShell" EventCode=800 | rex field=Message "HostApplication=(?<hostapp>[^\r\n]+)" | stats count by host, hostapp | sort - countMost likely because module logging is enabled and script block logging is not — they are separate Group Policy settings. The other possibility is more interesting: script block logging and AMSI do not exist in PowerShell 2.0, so a session started with `-Version 2` produces classic-log events like 800 while the operational log stays quiet. Check the EngineVersion in the event.
Enable module logging: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > 'Turn on Module Logging', with a module name of * to cover everything. That writes Event 4103 to the operational log and Event 800 to the classic Windows PowerShell log. Enable script block logging alongside it — 800 truncates long commands and 4104 does not.
The full command line of the process that is hosting the PowerShell engine. It is the field to read first, because it shows how the session was started — encoded commands, hidden windows, execution policy bypasses and version downgrades all appear here even when the command that ran looks ordinary. It also identifies PowerShell running inside another program rather than in powershell.exe.
PowerShell encodes with UTF-16LE, so decode it as Unicode rather than UTF-8: `[Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('<the base64 string>'))`. Decoding it as UTF-8 produces text with a null byte between every character, which is the usual sign you have used the wrong encoding rather than that the string is corrupt.
Last reviewed 7 September 2026