{"id":1232,"date":"2015-01-07T15:17:27","date_gmt":"2015-01-07T20:17:27","guid":{"rendered":"http:\/\/adsecurity.org\/?p=1232"},"modified":"2015-01-14T22:34:12","modified_gmt":"2015-01-15T03:34:12","slug":"powershell-security-execution-policy-is-not-an-effective-security-strategy-how-to-bypass-the-powershell-execution-policy","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=1232","title":{"rendered":"PowerShell Security: Execution Policy is Not An Effective Security Strategy &#8211; How to Bypass the PowerShell Execution Policy"},"content":{"rendered":"<p>If you have worked with PowerShell recently, you may have run into an Execution Policy message:<\/p>\n<blockquote><p>c:\\temp\\Find-PSServiceAccounts.ps1 : File C:\\temp\\Find-PSServiceAccounts.ps1 cannot be loaded because running scripts<br \/>\nis disabled on this system. For more information, see about_Execution_Policies at<br \/>\nhttp:\/\/go.microsoft.com\/fwlink\/?LinkID=135170.<br \/>\nAt line:1 char:1<br \/>\n+ c:\\temp\\Find-PSServiceAccounts.ps1<br \/>\n+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br \/>\n+ CategoryInfo\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : SecurityError: (:) [], PSSecurityException<br \/>\n+ FullyQualifiedErrorId : UnauthorizedAccess<\/p><\/blockquote>\n<p>It&#8217;s likely that Microsoft was concerned about another scripting environment where scripts run automatically without built-in controls.<br \/>\nHowever, any teeth the PowerShell execution policy may have had was significantly reduced during the development process.<\/p>\n<p>From<a href=\"http:\/\/technet.microsoft.com\/en-us\/gg261722.aspx\"> Microsoft TechNet<\/a>:<\/p>\n<blockquote><p>It may seem odd to permit users to override an administrator-established value for\u00a0the execution policy, but remember that the execution policy is intended to help stop <em>unintended<\/em> script execution. It is not intended to stop skilled users from executing scripts at all, merely to ensure that they do not do so without knowing what they are doing.<\/p><\/blockquote>\n<p>The result of this is that the Execution Policy does not provide effective security against a determined attacker with access to computers on your network.<\/p>\n<p>Microsoft TechNet decribes <a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/cc764242.aspx\">the different options for the PowerShell Execution Policy<\/a>:<\/p>\n<blockquote><p>The following execution policies govern scripting in Windows PowerShell:<\/p>\n<ul>\n<li class=\"unordered\"><em>Restricted.<\/em> Permits interactive commands only (no scripts). This is the default.<\/li>\n<li class=\"unordered\"><em>AllSigned.<\/em> Permits scripts, but requires a digital signature from a trusted publisher for all scripts and configuration files, including scripts that you write on the local computer.<\/li>\n<li class=\"unordered\"><em>RemoteSigned.<\/em> Permits scripts, but requires a digital signature from a trusted publisher for all scripts and configuration files that are downloaded from the Internet, including e-mail. A digital signature is not required for scripts that you create on the local computer.<\/li>\n<li class=\"unordered\"><em>Unrestricted.<\/em> Permits scripts, including unsigned scripts.<\/li>\n<\/ul>\n<\/blockquote>\n<p>By default, the PowerShell exeuction policy is set to Restricted which means no script will run. Technically this is true, but it is trivial to bypass this &#8220;protection&#8221;.<br \/>\n<!--more--><br \/>\nThe graphic shows that an admin can change the PowerShell execution policy by running set-executionpolicy.<\/p>\n<p><a href=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/01\/PowerShell-ExecutionPolicy.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone  wp-image-1233\" src=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/01\/PowerShell-ExecutionPolicy.png\" alt=\"PowerShell-ExecutionPolicy\" width=\"657\" height=\"245\" srcset=\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/01\/PowerShell-ExecutionPolicy.png 882w, https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/01\/PowerShell-ExecutionPolicy-300x112.png 300w\" sizes=\"auto, (max-width: 657px) 100vw, 657px\" \/><\/a><\/p>\n<p>So, an admin can change the system&#8217;s PowerShell execution policy.<br \/>\nHowever, it isn&#8217;t necessary to change the execution policy to run scripts. It is trivial to bypass the execution policy at any time.<\/p>\n<p><strong>NSPI describes <a href=\"https:\/\/blog.netspi.com\/15-ways-to-bypass-the-powershell-execution-policy\/\">15 ways to completely bypass the PowerShell Execution Policy<\/a><\/strong><\/p>\n<p>I have found the following execution policy bypass methods to be the easiest:<\/p>\n<ul>\n<li>Run the script in PowerShell_ISE by selecting all of the code and pressing F8<\/li>\n<li>PowerShell.exe -ExecutionPolicy Bypass -File c:\\temp\\PowerShellScript.ps1<\/li>\n<li>PowerShell.exe -ExecutionPolicy UNRestricted -File c:\\temp\\PowerShellScript.ps1<\/li>\n<li>Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy UnRestricted<\/li>\n<\/ul>\n<p>References:<\/p>\n<ul>\n<li><a href=\"http:\/\/technet.microsoft.com\/en-us\/gg261722.aspx\">Windows PowerShell Script Security<\/a><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you have worked with PowerShell recently, you may have run into an Execution Policy message: c:\\temp\\Find-PSServiceAccounts.ps1 : File C:\\temp\\Find-PSServiceAccounts.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at http:\/\/go.microsoft.com\/fwlink\/?LinkID=135170. At line:1 char:1 + c:\\temp\\Find-PSServiceAccounts.ps1 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : SecurityError: (:) [], PSSecurityException + FullyQualifiedErrorId : &hellip; <\/p>\n<p><a class=\"more-link btn\" href=\"https:\/\/adsecurity.org\/?p=1232\">Continue reading<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,7],"tags":[388,387,390,389],"class_list":["post-1232","post","type-post","status-publish","format-standard","hentry","category-microsoft-security","category-powershell","tag-bypassexecutionpolicy","tag-powershellexecutionpolicy","tag-powershellrestricted","tag-set-executionpolicy","item-wrap"],"_links":{"self":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/1232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1232"}],"version-history":[{"count":5,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/1232\/revisions"}],"predecessor-version":[{"id":1254,"href":"https:\/\/adsecurity.org\/index.php?rest_route=\/wp\/v2\/posts\/1232\/revisions\/1254"}],"wp:attachment":[{"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adsecurity.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}