Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows PowerShell · Event 53504
PowerShell opened its named-pipe listener for a newly started engine, and recorded the process ID and the AppDomain name. It is routine noise with one useful property: it fires wherever the engine loads, including inside programs that are not powershell.exe.
Also written as PowerShell 53504powershell named pipe IPC
Something started PowerShell. That happens constantly on Windows without anyone opening a blue window — installers, Windows features, and settings pages all use it. It is informational and there is nothing to act on.
Its value is coverage rather than content. Because it is written when the engine initialises rather than when powershell.exe launches, it also fires for hosts that load System.Management.Automation directly — the technique usually described as 'PowerShell without powershell.exe'. Correlate the process ID it reports against process creation: if no PowerShell binary was started but an engine initialised, that is the finding.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
Log Name: Microsoft-Windows-PowerShell/Operational
Source: Microsoft-Windows-PowerShell
Event ID: 53504
Level: Information
Computer: DESKTOP-WKS042
Windows PowerShell has started an IPC listening thread on process: 4812 in AppDomain: DefaultAppDomain.Everything else in the log line is context.
A PID belonging to powershell.exe or pwsh.exeOrdinary. The overwhelming majority. A PID belonging to something else entirelyThe engine was loaded inside another program. Legitimate for some management software, and also what tooling built to avoid powershell.exe looks like. DefaultAppDomainA normal console or script host. DscPsPluginWkr_AppDomainDesired State Configuration executing a script resource. Distinctive and worth recognising. An unfamiliar named AppDomainSomething embedded the engine deliberately and named its own domain. Most of the time it is one of these.
What gives it awayA 53504 naming a process that is not a PowerShell binary, with no matching 40961 or 40962. Application allowlisting and process-name-based detections both miss this; the engine start does not.
ATT&CK T1059.001What gives it awayA 53504 in a wsmprovhost.exe process, correlating with a Security 4624 Logon Type 3 from another host at the same moment.
ATT&CK T1021.006Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=53504} -MaxEvents 100 | Select-Object TimeCreated, MessageGet-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=53504,40961,40962} -MaxEvents 200 | Sort-Object TimeCreated | Select-Object TimeCreated, Idlet ps = Event | where EventLog == 'Microsoft-Windows-PowerShell/Operational' and EventID == 53504 | extend Pid = toint(extract(@'process: (\d+)', 1, RenderedDescription));
ps | join kind=leftouter (SecurityEvent | where EventID == 4688 | project Computer, NewProcessId, NewProcessName, TimeGenerated) on Computer | where NewProcessName !endswith 'powershell.exe' and NewProcessName !endswith 'pwsh.exe'logsource:
product: windows
service: powershell-operational
detection:
selection:
EventID: 53504
condition: selectionPowerShell creates a named pipe for each engine instance so that other tools can attach to it — this is what makes `Enter-PSHostProcess` possible. Event 53504 is written when that listener is set up, which happens every time a PowerShell engine initialises. It is informational and says nothing about what the session went on to do.
On its own, no — it fires on every PowerShell start, including the many that Windows does by itself. It becomes interesting when the process ID it names does not belong to powershell.exe or pwsh.exe, because that means the engine was loaded inside some other program. Some management software does that legitimately; so does tooling designed to avoid running a PowerShell binary.
The .NET application domain the engine started inside. Almost always DefaultAppDomain. The one worth recognising is DscPsPluginWkr_AppDomain, which means Desired State Configuration is executing a script resource — a useful marker because DSC activity otherwise looks like ordinary PowerShell.
Because a great deal of Windows uses PowerShell internally. Windows Update, feature installs, MSI packages, Settings pages, antivirus definition updates, and management agents all start engines without showing anyone a console window. Seeing these on an idle machine is normal.
Last reviewed 7 September 2026