Malware written in PowerShell that runs on Windows and uses built-in administration features for execution, discovery, command handling, and data theft. Because it relies on native tooling, a PowerShell trojan can blend into legitimate activity while still enabling reconnaissance, persistence, and exfiltration.
What a PowerShell Trojan Is
A PowerShell trojan is malicious code that abuses built-in Windows administration features to execute without dropping a traditional binary. Its value to an attacker is stealth, because the activity can look like normal administration, scripting, or troubleshooting.
This makes the term less about the PowerShell language itself and more about abuse of a trusted execution environment. The same native reach that makes PowerShell useful for defenders and administrators also makes it attractive for concealment, especially when the script is delivered through a browser, email, remote command, or another initial access path.
How It Operates
PowerShell trojans commonly chain together execution, discovery, command handling, and data theft. They may download additional payloads, inspect the host and network, enumerate users or processes, and then relay results or stolen data to a remote controller. Because PowerShell can be launched in many legitimate workflows, the resulting telemetry may blend into routine administrative noise.
The important operational detail is that the trojan often depends on native tooling rather than custom malware functions. That means defenders may see script blocks, encoded commands, child-process creation, unusual network requests, or suspicious use of administrative cmdlets instead of a clearly named malware file.
Why Detection Is Hard
Detection is difficult because a PowerShell trojan can reuse trusted system components, live briefly in memory, and avoid the filesystem artifacts that many traditional detections expect. Attackers also use obfuscation, compression, or parameter abuse to hide intent inside commands that still look syntactically valid.
Operationally, this pushes defenders toward behaviour-based visibility rather than file-only inspection. The most useful signals are often execution context, command-line detail, parent-child process relationships, script content, and whether the activity matches the expected administrative role on that host.
Where It Fits in Attack Chains
PowerShell trojans are commonly used after initial compromise to move from foothold to deeper access. They are useful for reconnaissance, credential discovery, staging, lateral movement support, persistence, and exfiltration because they can run with the privileges of the current user and interact easily with the Windows environment.
That makes the technique especially relevant in intrusion chains where the adversary wants speed and low friction. A small script can be enough to establish command execution, collect intelligence, and set up follow-on activity without introducing a large malware footprint.
Risk and Threat Considerations
PowerShell trojans matter because they exploit the trust defenders and operators place in built-in administration tooling. If PowerShell is over-permitted, poorly monitored, or allowed to run high-risk command patterns without visibility, the same tool used for legitimate management becomes an efficient route to stealthy compromise.
Failure mechanism: An attacker gains script execution, hides activity inside normal administration workflows, and uses the trusted runtime to collect data, maintain access, or move laterally before detection.
Impact: The result can be credential exposure, persistence, broader host compromise, and delayed incident discovery across multiple systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059.001 — PowerShell | PowerShell trojans rely on PowerShell execution as an attacker technique. |
| T1027 — Obfuscated Files or Information | Trojans often hide intent with obfuscation, compression, or encoded commands. | |
| T1087 — Account Discovery | PowerShell trojans frequently enumerate users and groups during post-compromise discovery. | |
| Recommendation — Map suspicious script execution to T1059.001 and hunt for encoded or hidden PowerShell commands. Detect obfuscated PowerShell content and inspect decoded command material before execution. Alert on scripted account enumeration and investigate unexpected discovery activity. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Script execution and command activity require sufficient audit logging to expose abuse. |
| AU-12 — Audit Record Generation | PowerShell abuse is harder to detect without generated records for script and process activity. | |
| SI-4 — System Monitoring | Behaviour-based monitoring is central to spotting malicious PowerShell activity. | |
| Recommendation — Log PowerShell execution and command details to preserve forensic visibility. Generate audit records for script block, process, and network-related PowerShell activity. Monitor for abnormal PowerShell behaviour, including encoded commands and unusual child processes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detecting PowerShell trojans depends on retaining and reviewing rich execution telemetry. |
| CIS-10 — Malware Defenses | Behavioural malware defenses help identify script-based trojans that lack a classic file footprint. | |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Tightening script execution settings reduces the opportunity for trojan abuse. | |
| Recommendation — Centralise and review PowerShell-related logs to expose malicious scripting. Use malware defenses that inspect script behaviour and block known malicious patterns. Harden PowerShell and related execution settings on managed endpoints. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Network and script-behaviour monitoring is needed to surface PowerShell-based compromise. |
| Recommendation — Monitor for PowerShell-driven network and host activity that deviates from normal administration. | ||
Practitioner Guidance
What to watch for: Treat unusual PowerShell behaviour as a security signal, not just an operations event. Pay particular attention to encoded commands, hidden windows, suspicious parent processes, unexpected network calls, and script execution on systems that should not be running ad hoc administration tasks.
Governance implication: PowerShell policy should reflect the difference between approved administration and unmanaged script use. The practical goal is not to remove PowerShell, but to narrow where it can run freely, increase visibility where it is allowed, and define who is authorised to use it for privileged tasks.
Related resources from NHI Mgmt Group
- What breaks when PowerShell and BITSAdmin are allowed to run unchecked on user endpoints?
- What breaks when users are allowed to execute PowerShell from untrusted prompts?
- How should security teams detect ClickFix-style PowerShell abuse in practice?
- What do teams get wrong about PowerShell-based malware campaigns?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
