название правила powershell исполняет обфусцированный код

Обфускация PowerShell

В антивирусных базах есть миллионы сигнатур, но троянские программы по-прежнему имеются в арсенале у хакеров. Даже публичные и всем известные варианты полезных нагрузок Metasploit, разновидностей RAT и стиллеров могут быть незамеченными. Как такое может быть? Благодаря обфускации! Даже скрипт PowerShell можно спрятать от антивируса.

Взгляните на эту строку. Что вы здесь видите?

Думаю — ничего. А ведь это всего лишь обфусцированная команда netstat /ano. Сегодня мы попробуем разобраться, как привести команды на PowerShell к такому виду, и протестируем, как на это будут реагировать антивирусное ПО.

PowerShell в пентесте

С помощью PowerShell можно загружать код из интернета (к примеру, с pastebin.com) или файла на ПК и выполнять его. Для этого используется специльный командлет Invoke-Expression. Вот примеры использования.

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

Есть масса других интересных трюков с PowerShell.

Обфускация PowerShell

Процесс обфускации PowerShell довольно простой, так как это скриптовый язык и работает со строками, а не с исполняемым двоичным кодом. Итак, рассмотрим некоторые методы обфускации PowerShell. Будем рассматривать все на примере данной команды:

Поглядим, что еще можно сделать. URL в нашей команде — это строка. Что можно делать со строками? Совершенно верно — разделять и соединять, а вернее, конкатенировать. Попробуем это применить.

Команда отрабатывает точно так же. А сейчас постараемся объявить в виде переменной часть команды.

Обфускация отлично работает. Идем дальше. DownloadString, наверное, используется хакерами уже сто лет. Спрячем DownloadString и New-Object среди “ и `.

Неплохо спрятали. Почти трудно определить, что это такое.

Что еще можно использовать для загрузки файла или скрипта кроме DownloadString? Конечно! Методы класса Net.Web-Client:

Есть возможность использовать не Web-Client, а другие классы:

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

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

Разделим и соединим строку другим способом.

И снова конкатенируем другим способом.

Согласитесь, над командой мы поэкспериментировали неплохо. Рассмотрим теперь другие трюки, которые могут помочь доставить полезную нагрузку с использованием cmd. Есть один очень извращенный способ загрузки удаленных скриптов через блокнот. Подгружаем скрипт File → Open.

Загрузка кода из интернета

И все! Он у нас в блокноте.

Можно ли это как-то автоматизировать и использовать? Конечно! С помощью метода SendKeys объекта WscriptShell, который имитирует нажатие клавиш. Вот пример подобного скрипта с использованием блокнота:

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

А можно ли использовать не командную строку, а что-нибудь другое? Например, в некоторых случаях cmd можно заменить на forfiles. Forfiles — это консольная утилита Windows для операций с файлами.

Использование Forfiles

Также cmd можно вызывать не напрямую, а через переменную %COMSPEC%. Запутываем PowerShell еще больше! В командах вместо знака — можно использовать знак /. Например, вот так:

Кажется, намудрили достаточно. Можно еще много обсуждать эти замечательные методы. Кому интересно, еще больше методов найдет в презентациях Даниэля Боханнона (первый PDF и второй). Ну а мы пока что посмотрим на написанные им инструменты, которые упростят обфускацию и сделают все за нас.

Автоматизируем обфускацию

Первый инструмент — Invoke-Obfuscation. Это фреймворк для обфускации PowerShell, который использует разные методы, в том числе и перечисленные в предыдущем разделе. Загружаем архив, запускаем PowerShell. Переходим в папку фреймворка, меняем политику исполнения, если надо, и запускаем сам фреймворк.

Фреймворк Invoke-Obfuscation

Для начального ознакомления введите tutorial. Для тестирования будем использовать все ту же команду. Посмотрим необходимые опции и установим нужные (подсвечивается желтым).

Попробуем использовать конкатенацию. Получаем результат и нашу строку.

Результат обфускации

Также можно закодировать команду в ASCII, HEX, Octal, Binary, SecureString или BXORencoding. Нагрузку возьмем потяжелее. Например, создадим ее с помощью msfvenom.

Попробуем использовать ENCONDING и опцию 6. Получается такая картина.

Результат обфускации полезной нагрузки

Можно использовать вместе конкатенацию, encoding и compress. Попробуйте поиграться с разными вариантами и комбинациями.

DOSfuscation

Следующий инструмент того же автора — Invoke-DOSfuscation. Скачиваем его, запускаем PowerShell и вводим в папке фреймворка команды

Invoke-DOSfuscation

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

Получаем нашу замаскированную полезную нагрузку.

Результат обфускации с помощью Invoke-DOSfuscation

Реакция антивирусов

Пришло время проверить, как реагируют антивирусы на нашу нагрузку с обфускацией и без. Для эксперимента будем использовать три антивируса: Kaspersky, Eset NOD32, Windows Defender.

Первым в бой идет Kaspersky. Проверяем нашу полезную нагрузку msfvenom в первоначальном виде. KAV даже не дал перейти по ссылке для скачивания файла xaker.ps1!

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

Переходим к Eset NOD32 и проверяем файлы в том же порядке. Удивительно, но он не заметил даже необфусцированный файл.

Под конец проверим с помощью встроенного антивируса Windows Defender. Он не дал запустить первый файл без обфускации и сразу удалил его. Второй файл отлично запустился и не был замечен. Третий файл запустился, но во время запуска был обнаружен.

Выводы

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

Доработать обфускацию вы можете сами и, комбинируя разные варианты, сделать так, чтобы антивирус точно не распознал поведение. Попробуйте все методы и затем комбинируйте ручную обфускацию, способы спрятать нагрузку и рассмотренные фреймворки на модели целевой машины. В конце концов, все ограничено только вашей фантазией!

Источник

Политика выполнения скриптов PowerShell

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

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

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

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

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

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

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

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

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

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

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

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

Для областей UserPolicy и MachinePolicy значение политики задаются через GPO. За настройку отвечает параметр Turn on Script Execution (Включить выполнение сценариев), находящийся в разделе Administrative Templates\Windows Components\Windows 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 с указанием требуемой политики. Сделать это можно из командной строки, например для запуска скрипта можно попробовать такую команду:

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

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

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

Источник

about_Signing

Краткое описание

Описывает, как подписывать сценарии, чтобы они соответствовали политикам выполнения PowerShell.

Подробное описание

Политика ограниченного выполнения не позволяет запускать скрипты. Политики выполнения AllSigned и RemoteSigned запрещают PowerShell выполнять сценарии, не имеющие цифровой подписи.

В этом разделе объясняется, как выполнить выбранные сценарии, которые не подписаны, даже если политика выполнения RemoteSigned и как подписывать сценарии для собственного использования.

Дополнительные сведения о политиках выполнения PowerShell см. в разделе about_Execution_Policies.

Разрешение выполнения подписанных сценариев

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

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

Чтобы найти действующую политику выполнения на компьютере, введите:

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

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

Выполнение неподписанных скриптов с помощью политики выполнения RemoteSigned

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

При попытке запустить скачанный скрипт PowerShell выводит следующее сообщение об ошибке:

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

Чтобы выполнить неподписанный скрипт, используйте командлет Unblock-File или выполните следующую процедуру.

Если сценарий, скачанный из Интернета, имеет цифровую подпись, но вы еще не выбрали доверие к издателю, PowerShell выводит следующее сообщение:

Если вы доверяете издателю, выберите «запустить один раз» или «всегда запускать». Если вы не доверяете издателю, выберите параметр «никогда не запускать» или «не запускать». Если выбрать параметр «никогда не запускать» или «всегда запускать», PowerShell не будет выводить запрос для этого издателя снова.

Методы подписания скриптов

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

Рекомендации по подписывания кода см. в статье рекомендации по подписываниякода.

Дополнительные сведения о том, как подписать файл скрипта, см. в разделе Set-AuthenticodeSignature.

New-SelfSignedCertificate Командлет, представленный в модуле PKI в PowerShell 3,0, создает самозаверяющий сертификат, подходящий для тестирования. Дополнительные сведения см. в разделе справки по командлету New-SelfSignedCertificate.

Чтобы добавить цифровую подпись в скрипт, необходимо подписать его с помощью сертификата подписи кода. Для подписи файла скрипта подходят два типа сертификатов:

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

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

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

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

Создание самозаверяющего сертификата.

Чтобы создать самозаверяющий сертификат, используйте командлет New-SelfSignedCertificate в модуле PKI. этот модуль появился в PowerShell 3,0 и входит в Windows 8 и Windows Server 2012. Дополнительные сведения см. в разделе справки по New-SelfSignedCertificate командлету.

Использование Makecert.exe

Дополнительные сведения о синтаксисе и описаниях параметров MakeCert.exe средства см. в разделе средство создания сертификатов (MakeCert.exe).

Чтобы использовать MakeCert.exe средство для создания сертификата, выполните следующие команды в окне командной строки пакета SDK.

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

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

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

В командной строке PowerShell введите следующее:

Эта команда использует поставщик сертификата PowerShell для просмотра сведений о сертификате.

Подписать сценарий

Следующий пример скрипта Add-Signature.ps1 подписывает скрипт. Однако при использовании политики выполнения AllSigned необходимо подписать Add-Signature.ps1 сценарий перед запуском.

Скрипт должен быть сохранен с использованием кодировки ASCII или UTF8NoBOM. Вы можете подписать файл сценария, который использует другую кодировку. Но сценарий не запускается, или модуль, содержащий скрипт, не удается импортировать.

Чтобы подписать Add-Signature.ps1 файл скрипта, введите в командной строке PowerShell следующие команды:

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

Если PowerShell отображает это сообщение при выполнении скрипта, который не был написан, обработайте файл так, как если бы вы ни использовали любой неподписанный сценарий. Проверьте код, чтобы определить, можно ли доверять сценарию.

Включение усиленной защиты закрытого ключа для сертификата

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

Чтобы экспортировать сертификат, выполните следующие действия.

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

Запрет истечения срока действия подписи

Цифровая подпись в скрипте действительна до истечения срока действия сертификата подписи или до тех пор, пока сервер отметок времени не сможет проверить, подписан ли сценарий, пока сертификат для подписи был действителен.

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

Источник