{"id":13665,"date":"2017-10-23T05:58:52","date_gmt":"2017-10-23T13:58:52","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/powershell\/?p=13665"},"modified":"2020-02-20T13:40:49","modified_gmt":"2020-02-20T21:40:49","slug":"defending-against-powershell-attacks","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/defending-against-powershell-attacks\/","title":{"rendered":"Defending Against PowerShell Attacks"},"content":{"rendered":"

[Updated Feb 20th, 2020 with latest guidance]<\/strong><\/p>\n

The security industry is ablaze with news about how PowerShell is being used by both commodity malware and attackers alike. Surely there\u2019s got to be a way to defend yourself against these attacks!<\/p>\n

There absolutely is. PowerShell is – by far – the most securable and security-transparent shell, scripting language, or programming language available.<\/p>\n

Our\u00a0recommendations are:<\/p>\n

    \n
  1. Deploy PowerShell v5.1 (or newer)<\/strong>, built into Windows 10. Alternatively, you can deploy the Windows Management Framework<\/a>, available\u00a0down to and including\u00a0Windows 7 \/ Windows Server\u00a02008r2.<\/li>\n
  2. Enable, and collect PowerShell logs<\/strong>, optionally\u00a0including Protected Event Logging. Incorporate these logs into your signatures, hunting, and incident response workflows.<\/li>\n
  3. Implement Just Enough Administration<\/strong> on high-value systems to eliminate or reduce unconstrained administrative access to those systems.<\/li>\n
  4. Deploy Device Guard \/ Application Control policies<\/strong>\u00a0to allow pre-approved administrative tasks to use the full capability of the PowerShell language, while limiting interactive and unapproved use to a limited subset of the PowerShell language.<\/li>\n
  5. Deploy Windows 10<\/strong> to give your antivirus provider full access to all content (including content generated or de-obfuscated at runtime)\u00a0processed by Windows Scripting Hosts including PowerShell.<\/li>\n<\/ol>\n

    Some security professionals recommend disabling PowerShell as a method of risk mitigation. Microsoft\u2019s guidance on this falls into two areas:<\/p>\n

      \n
    1. Client systems<\/strong>. After initial infection (by a macro-enabled document or user double-clicking a malicious executable), malware sometimes uses PowerShell as one component of its attack chain. Microsoft\u2019s recommendation is not to block PowerShell completely, as PowerShell is required for many operating system and system management tasks. Microsoft\u2019s recommendation is to limit PowerShell to authorized users and administrators to mitigate the use by commodity malware, as described by point #4 above (\u201cDeploy Device Guard \/ Application Control Policies\u201d). If Windows Defender Application Control is not an option, security products that block PowerShell from unknown parent processes (such as Word, Excel) are a reasonable middle ground.<\/li>\n
    2. Server systems<\/strong>. Microsoft does not recommend blocking PowerShell on server systems. PowerShell is the most secure remote management technology<\/a>, and disabling PowerShell exposes the server to significant risks of credential theft<\/a> enabled by other remote management technologies (such as Remote Desktop). PowerShell is also the primary management technology for server systems, so blocking PowerShell completely causes an unacceptable administrative burden using tools with little to no security transparency. Additionally, malicious post-exploitation use of PowerShell on a server system is primarily associated with an active adversary, rather than the static approach used by commodity malware on client systems. Without Application Control (as described by point #4 above), active adversaries simply use other scripting languages or custom tooling.<\/li>\n<\/ol>\n

      For further information about these steps and\u00a0solutions, please see the much more detailed presentation: “Defending Against PowerShell Attacks<\/a>“.<\/p>\n