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 malware that abuses Windows native scripting and administration features to execute malicious actions while looking like ordinary system activity. Its PowerShell-based design matters because defenders may see legitimate tooling rather than a separate binary, which can delay recognition of execution, discovery, command handling, and data theft.
How it works
PowerShell trojans commonly run commands in memory, chain built-in utilities, and use script content to blend into administrative workflows. That makes the initial behaviour harder to distinguish from routine automation, especially when the script is launched through a trusted process, a user session, or a management context that would normally be allowed.
Because PowerShell is flexible, an attacker can use it for reconnaissance, environment discovery, staged payload retrieval, and lateral preparation without introducing obvious new tooling. The malicious logic may be short, encoded, obfuscated, or split across multiple commands, which increases the chance that a quick review misses the full intent.
Why PowerShell trojans are difficult to spot
The main challenge is that defenders must distinguish malicious use from legitimate administration at the command, script, and process levels. PowerShell activity can be noisy in healthy environments, so simple allow or block thinking is usually too blunt: context, lineage, and post-execution behaviour matter more than the language itself.
Detection is stronger when teams correlate script execution with unusual parent processes, hidden windows, suspicious network connections, unexpected archive or download activity, and the use of encoded or heavily obfuscated commands. A trojan that never drops a conventional executable may still leave clear operational clues in process telemetry and endpoint logs.
Security impact and containment
If a PowerShell trojan succeeds, the immediate risk is often not the script itself but the access it unlocks. It can harvest data, stage additional payloads, persist through scripts or scheduled activity, and create a foothold for broader compromise while remaining difficult to attribute to a single obvious file.
Containment usually means restricting script execution pathways, tightening application control, and watching for PowerShell behaviour that does not fit approved administration patterns. NIST SP 800-53 Rev 5 controls on identification, authentication, configuration, audit, and system integrity help frame the controls that matter most, while MITRE ATT&CK provides the adversary-behaviour lens for mapping the execution and discovery techniques involved.
Risk and Threat Considerations
PowerShell trojans are risky because they turn trusted Windows functionality into an execution channel for stealthy compromise. That creates a detection gap: the more normal the command line and process chain look, the easier it is for malicious activity to hide inside legitimate administration.
Failure mechanism: Attackers abuse built-in scripting and administrative features to run code, discover the environment, and stage follow-on activity without introducing an obviously malicious standalone binary.
Impact: The resulting compromise can expose credentials, data, sessions, and internal systems, and it can persist long enough to support later payload delivery or broader intrusion.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | PowerShell trojans require monitoring of suspicious execution and behaviour. |
| SI-3 — Malicious Code Protection | Trojan scripts are malware that need code-execution controls and detection. | |
| AC-6 — Least Privilege | Trojan impact expands when users or processes have excessive execution rights. | |
| Recommendation — Monitor PowerShell execution patterns and alert on anomalous command-line, lineage, and network activity. Use malicious code protection to block or contain suspicious PowerShell content and payload staging. Restrict PowerShell and administrative rights to the minimum needed for approved tasks. | ||
| MITRE ATT&CK | T1059.001 — PowerShell | The term is directly about the PowerShell execution technique used by adversaries. |
| T1036 — Masquerading | Trojans rely on blending malicious activity into legitimate-looking administration. | |
| Recommendation — Map observed script activity to PowerShell tradecraft and hunt for related execution chains. Investigate process, file, and command masquerading that makes malicious PowerShell look normal. | ||
Practitioner Guidance
Why practitioners should care: Treat PowerShell as an administration surface that needs policy, visibility, and behavioural detection rather than a language that can be trusted by default. The practical question is not whether PowerShell is allowed, but whether the organisation can tell approved automation from malicious tradecraft.
What to watch for: Pay special attention to encoded commands, unusual parent-child process relationships, internet-retrieval behaviour, and scripts that perform discovery or data movement outside normal admin tooling. NHIMG’s Trojans Guide is useful here because it covers trojan types, delivery routes, detection, and response patterns that map directly to this threat.
Practitioner takeaway: The best defence is not just blocking PowerShell, but making sure malicious use stands out clearly in logs, endpoint telemetry, and control enforcement.
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
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org