ble in Windows. System administrators use it to automate tasks, manage Active Directory, configure servers, and deploy software across enterprise environments. Unfortunately, attackers also recognize its capabilities and frequently abuse PowerShell during cyberattacks.
For Security Operations Center (SOC) analysts, PowerShell presents a unique challenge. Simply detecting that PowerShell was executed is not enough because it is used legitimately every day. The real objective is determining whether its execution is consistent with normal administrative activity or indicative of malicious behaviour. By combining guidance from the MITRE ATT&CK framework and the NIST Cybersecurity Framework (CSF), analysts can investigate PowerShell activity more effectively and reduce false positives.
Why Adversaries Use PowerShell
PowerShell is installed by default on most Windows systems and has extensive access to operating system functions. Attackers can use it to download files, execute commands, gather system information, interact with Active Directory, and even communicate with remote servers.
Within the MITRE ATT&CK framework, malicious PowerShell activity commonly falls under T1059.001 – Command and Scripting Interpreter: PowerShell.
PowerShell is attractive because it allows attackers to perform many actions without introducing new executable files. This “Living off the Land” approach helps them blend into legitimate system activity and evade traditional security controls.
However, PowerShell itself is not malicious. Countless IT administrators rely on it every day to manage enterprise infrastructure.
Signs of Suspicious Activity
SOC analysts should avoid creating alerts based solely on PowerShell execution. Instead, they should examine the surrounding context.
Questions worth asking include:
- Which process launched PowerShell?
- Which user executed the command?
- Was it started from Microsoft Word, Excel, or Outlook?
- Were encoded commands used?
- Did it create child processes?
- Did it connect to an unfamiliar external IP address?
- Did registry keys, scheduled tasks, or services change afterwards?
For example, PowerShell launched by Microsoft Endpoint Configuration Manager during a scheduled software deployment is likely expected. On the other hand, PowerShell started by Microsoft Word immediately after a user opens an email attachment deserves much closer investigation.
Using NIST Guidance
The NIST Cybersecurity Framework emphasizes continuous monitoring and well-defined incident response procedures.
Organizations should collect PowerShell logs where possible, including process creation events and command-line arguments. Visibility is essential because analysts cannot investigate activity they cannot see.
NIST also recommends implementing the Principle of Least Privilege. Restricting administrative permissions reduces the damage attackers can cause if they successfully execute PowerShell commands under a compromised account.
Combining strong logging, access control, and incident response procedures significantly improves an organization’s ability to detect malicious PowerShell activity.
Conclusion
PowerShell remains one of the most valuable tools available to both system administrators and attackers. Successful SOC analysts understand that the presence of PowerShell is rarely the problem. Instead, they focus on how it was executed, who executed it, what actions followed, and whether the behaviour matches normal system activity.
By applying the behavioural perspective of the MITRE ATT&CK framework alongside the defensive guidance provided by the NIST Cybersecurity Framework, analysts can investigate PowerShell activity with greater confidence and accuracy. Effective threat detection is not about blocking legitimate tools—it is about recognizing when those tools are being used for illegitimate purposes.