powershell повышение привилегий в скрипте
Использование PowerShell для повышения привилегий локальных учетных записей
Повышение привилегий — это использование злоумышленником текущих прав учетной записи для получения дополнительного, как правило, более высокого уровня доступа в системе. Несмотря на то что повышение привилегий может быть результатом эксплуатации уязвимостей нулевого дня, или работы первоклассных хакеров, проводящих целенаправленную атаку, или же грамотно замаскированной вредоносной программой, но все же чаще всего это происходит из-за неправильной настройки компьютера или учетной записи. Развивая атаку далее, злоумышленники используют ряд отдельных уязвимостей, что в совокупности может привести к катастрофической утечке данных.
Почему пользователи не должны иметь права локального администратора?
Если вы специалист по безопасности, это может показаться очевидным, что пользователи не должны иметь права локального администратора, так как это:
Шаг 1. Обратное разрешение DNS имен через PowerShell
По-умолчанию PowerShell устанавливается на многих локальных рабочих станциях и на большинстве серверов Windows. И хотя не без преувеличения он считается невероятно полезным инструментом автоматизации и управления, в равной степени он способен превращаться в почти невидимую fileless-малварь (программа для взлома, не оставляющая следов атаки).
В нашем случае злоумышленник начинает выполнять сетевую рекогносцировку с помощью сценария PowerShell, последовательно перебирая пространство IP-адресов сети, пытаясь определить, разрешается ли данный IP к узлу, и если да, то каково сетевое имя этого узла.
Существует множество способов выполнения этой задачи, но использование командлета Get-ADComputer — это надежный вариант, поскольку он возвращает действительно богатый набор данных о каждом узле:
Если скорость работы в больших сетях вызывает проблемы, то может использоваться обратный системный вызов DNS:
Этот метод перечисления узлов в сети очень популярен, так как большинство сетей не использует модель безопасности с нулевым доверием и не отслеживает внутренние DNS запросы на подозрительные всплески активности.
Шаг 2: Выбор цели
Конечным результатом этого шага является получение списка имен хостов серверов и рабочих станций, который может быть использован для продолжения атаки.
Судя по имени, сервер ‘HUB-FILER’ кажется достойной целью, т.к. с течением времени файловые серверы, как правило, аккумулируют большое количество сетевых папок и избыточного доступа к ним слишком большого круга лиц.
Просмотр с помощью Проводника Windows позволяет нам определить наличие открытой общей папки, но наша текущая учетная запись не может получить к ней доступ (вероятно, у нас есть права только на листинг).
Шаг 3: Изучаем ACL
Теперь на нашем хосте HUB-FILER и целевой общей папке share мы можем запустить сценарий PowerShell для получения списка ACL. Мы можем сделать это с локальной машины, так как у нас уже имеются права локального администратора:
Из него мы видим, что группа Пользователи Домена имеет доступ только на листинг, но вот группа Helpdesk имеет еще и права на изменение.
Шаг 4: Идентификация Учетных Записей
Запустив Get-ADGroupMember, мы сможем получить всех членов этой группы:
В этом списке мы видим учетную запись компьютера, которую мы уже идентифицировали и к которой уже получили доступ:
Шаг 5: Используем PSExec для работы от учетной записи компьютера
PsExec от Microsoft Sysinternals позволяет выполнять команды в контексте системной учетной записи SYSTEM@HUB-SHAREPOINT, которая, как мы знаем, является членом целевой группы Helpdesk. То есть нам достаточно выполнить:
Ну а далее у вас есть полный доступ к целевой папке \\HUB-FILER\share\HR, поскольку вы работаете в контексте учетной записи компьютера HUB-SHAREPOINT. И с этим доступом данные могут быть скопированы на портативное устройство хранения или иным образом извлечены и переданы по сети.
Шаг 6: Обнаружение данной атаки
Эта конкретная уязвимость настройки прав учетных записей (учетные записи компьютеров, обращающиеся к общим сетевым папкам вместо учетных записей пользователей или служебных учеток) может быть обнаружена. Однако без правильных инструментов сделать это очень сложно.
Чтобы обнаружить и предотвратить эту категорию атак, мы можем использовать DatAdvantage для идентификации групп с компьютерными учетными записями в них, а затем закрыть к ним доступ. DatAlert идет дальше и позволяет создать уведомление специально для подобного сценария.
На скриншоте ниже показано пользовательское уведомление, которое будет срабатывать при каждом доступе учетной записи компьютера к данным на отслеживаемом сервере.
Добавление поддержки учетных данных в функции PowerShell
Оригинал этой статьи впервые был опубликован в блоге автора @joshduffney. Эта статья была изменена для публикации на этом сайте. Группа разработчиков PowerShell благодарит Джоша (Josh) за то, что он поделился с нами этим содержимым. Посетите его блог duffney.io.
В этой статье показано, как и зачем добавлять параметры учетных данных в функции PowerShell. Параметр учетных данных позволяет выполнять функцию или командлет от лица другого пользователя. Чаще всего такая возможность используется для выполнения функции или командлета от лица пользователя с повышенными привилегиями.
Например, командлет New-ADUser имеет параметр учетных данных Credential, в котором вы можете указать учетные данные администратора домена при создании учетной записи в домене, если ваша обычная учетная запись с запущенным сеансом PowerShell не имеет таких прав.
Создание объекта учетных данных
Используйте следующую команду, чтобы создать защищенную строку с паролем:
Теперь, когда вы знаете, как создать объект учетных данных, вы можете добавить параметры учетных данных в свои функции PowerShell.
Добавление параметра учетных данных
Кода в этом примере достаточно для создания работающего параметра учетных данных, но вы можете добавить несколько элементов, чтобы сделать его более надежным.
Использование параметров учетных данных
Запрос учетных данных
При задании показанного значения реестра в этих примерах предполагается, что у вас установлены функции веб-сервера Windows. Выполните Install-WindowsFeature Web-Server и Install-WindowsFeature web-mgmt-tools при необходимости.
Указание учетных данных в переменной
Для этого примера защищенная строка создается с использованием пароля в формате открытого текста. Все упомянутые ранее инструменты CI/CD предоставляют защищенный метод для указания пароля во время выполнения. При использовании таких инструментов замените пароль в формате обычного текста переменной, определенной в используемом инструменте CI/CD.
Выполнение без учетных данных
Работа с устаревшими командлетами
Не все командлеты поддерживают объекты учетных данных или позволяют использовать пустые учетные данные. Для них требуется указать имя пользователя и пароль в формате строк. Существует несколько способов обойти такое ограничение.
Использование оператора if-else для обработки пустых учетных данных
Использование сплаттинга для обработки пустых учетных данных
Работа со строковыми паролями
Командлет Invoke-Sqlcmd является примером командлета, который принимает пароль в формате строки. Командлет Invoke-Sqlcmd позволяет вам выполнять простые инструкции SQL для вставки, обновления и удаления. Командлет Invoke-Sqlcmd требует указания имени пользователя и пароля в формате открытого текста, а не более защищенного объекта учетных данных. В этом примере показано, как извлечь имя пользователя и пароль из объекта учетных данных.
Дополнительные сведения об управлении командлетами
Создание и хранение объектов учетных данных с соблюдением требований безопасности может быть сложной задачей. Приведенные ниже ресурсы помогут вам в работе с командлетами PowerShell.
Как проверить права администратора в скрипте PowerShell?
Если для выполнения некоего скрипта PowerShell нужно, чтобы он был запушен с правами администратора, вы можете прямо в PS коде выполнить проверку на наличие административных привилегий у текущего процесса.
Следующий PowerShell код можно использовать, чтобы проверить, запущён ли текущий скрипт в режиме “Run as Administrator” или нет:
Сохраните PowerShell код в файл check_perms.ps1 и запустите в консоли без прав администратора:
Как вы видите, появилась надпись, что прав администратора нет, поэтому работа PowerShell скрипта прекращена.
Запустите теперь этот скрип в сессии PowerShell с повышенными привилегиями. Как видите, скрипт определил, что данный сеанс PowerShell выполняется с правами администратора.
Также вы можете прямо из скрипта PowerShell запросить повышение привилегий, для этого вместо строки:
Write-Warning «Недостаточно прав”
Используйте следующий код для запуска процесса:
При запуске скрипта без прав администратора, этот скрипт перезапустится в новом привилегированном сеанс PowerShell и появится запрос UAC на повышение привилегий.
В PowerShell 4.0 и выше еще проще выполнить проверку наличия прав администратора. Для этого нужно использовать директиву –RunAsAdministrator.
Если скрипт запущен не под администратором, появится ошибка:
+ CategoryInfo : PermissionDenied: (check_perms.ps1:String) [], ScriptRequiresException
+ FullyQualifiedErrorId : ScriptRequiresElevation
Если запустить это скрип на компьютере с PowerShell v2 появится ошибка:
Для управления Active Directory вам может понадобится другая задача: из скрипта PowerShell нужно проверить, что у текущего пользователя есть права администратора домена. Используйте следующий код:
Использование PowerShell для повышения привилегий локальных учетных записей
Категории
Свежие записи
Наши услуги
Повышение привилегий — это использование злоумышленником текущих прав учетной записи для получения дополнительного, как правило, более высокого уровня доступа в системе. Несмотря на то что повышение привилегий может быть результатом эксплуатации уязвимостей нулевого дня, или работы первоклассных хакеров, проводящих целенаправленную атаку, или же грамотно замаскированной вредоносной программой, но все же чаще всего это происходит из-за неправильной настройки компьютера или учетной записи. Развивая атаку далее, злоумышленники используют ряд отдельных уязвимостей, что в совокупности может привести к катастрофической утечке данных.
Почему пользователи не должны иметь права локального администратора?
Если вы специалист по безопасности, это может показаться очевидным, что пользователи не должны иметь права локального администратора, так как это:
К сожалению, для многих организаций это до сих пор очень спорный вопрос и подчас сопровождается бурными дискуссиями (см. например, мой руководитель говорит, что все пользователи должны быть локальными администраторами ). Не углубляясь в детали этого обсуждения, мы считаем, что злоумышленник получил права локального администратора на исследуемой системе: либо через эксплойт, либо из-за того, что машины не были должным образом защищены.
Шаг 1. Обратное разрешение DNS имен через PowerShell
По-умолчанию PowerShell устанавливается на многих локальных рабочих станциях и на большинстве серверов Windows. И хотя не без преувеличения он считается невероятно полезным инструментом автоматизации и управления, в равной степени он способен превращаться в почти невидимую fileless-малварь (программа для взлома, не оставляющая следов атаки).
В нашем случае злоумышленник начинает выполнять сетевую рекогносцировку с помощью сценария PowerShell, последовательно перебирая пространство IP-адресов сети, пытаясь определить, разрешается ли данный IP к узлу, и если да, то каково сетевое имя этого узла.
Существует множество способов выполнения этой задачи, но использование командлета Get- ADComputer — это надежный вариант, поскольку он возвращает действительно богатый набор данных о каждом узле:
Если скорость работы в больших сетях вызывает проблемы, то может использоваться обратный системный вызов DNS:
Этот метод перечисления узлов в сети очень популярен, так как большинство сетей не использует модель безопасности с нулевым доверием и не отслеживает внутренние DNS запросы на подозрительные всплески активности.
Шаг 2: Выбор цели
Конечным результатом этого шага является получение списка имен хостов серверов и рабочих станций, который может быть использован для продолжения атаки.
Судя по имени, сервер ‘HUB-FILER’ кажется достойной целью, т.к. с течением времени файловые серверы, как правило, аккумулируют большое количество сетевых папок и избыточного доступа к ним слишком большого круга лиц.
Просмотр с помощью Проводника Windows позволяет нам определить наличие открытой общей папки, но наша текущая учетная запись не может получить к ней доступ (вероятно, у нас есть права только на листинг).
Шаг 3: Изучаем ACL
Теперь на нашем хосте HUB-FILER и целевой общей папке share мы можем запустить сценарий PowerShell для получения списка ACL. Мы можем сделать это с локальной машины, так как у нас уже имеются права локального администратора:
Из него мы видим, что группа Пользователи Домена имеет доступ только на листинг, но вот группа Helpdesk имеет еще и права на изменение.
Шаг 4: Идентификация Учетных Записей
В этом списке мы видим учетную запись компьютера, которую мы уже идентифицировали и к которой уже получили доступ:
Шаг 5: Используем PSExec для работы от учетной записи компьютера
PsExec от Microsoft Sysinternals позволяет выполнять команды в контексте системной учетной записи [email protected], которая, как мы знаем, является членом целевой группы Helpdesk. То есть нам достаточно выполнить:
Ну а далее у вас есть полный доступ к целевой папке HUB-FILERshareHR, поскольку вы работаете в контексте учетной записи компьютера HUB-SHAREPOINT. И с этим доступом данные могут быть скопированы на портативное устройство хранения или иным образом извлечены и переданы по сети.
Шаг 6: Обнаружение данной атаки
Эта конкретная уязвимость настройки прав учетных записей (учетные записи компьютеров, обращающиеся к общим сетевым папкам вместо учетных записей пользователей или служебных учеток) может быть обнаружена. Однако без правильных инструментов сделать это очень сложно.
Чтобы обнаружить и предотвратить эту категорию атак, мы можем использовать DatAdvantage для идентификации групп с компьютерными учетными записями в них, а затем закрыть к ним доступ. DatAlert идет дальше и позволяет создать уведомление специально для подобного сценария.
На скриншоте ниже показано пользовательское уведомление, которое будет срабатывать при каждом доступе учетной записи компьютера к данным на отслеживаемом сервере.
Следующие шаги с помощью PowerShell
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Статья Как повысить привилегии в Windows
Добрый день, Коллеги.
Сегодня мы поговорим о повышение привилегий Windows.
Повышение привилегий с BeRoot
Большинство способов поднятия привилегий связаны с ошибками в конфигурации установленного ПО, будь то путь к исполняемому файлу сервиса, не обрамленный кавычками и содержащий пробел (такая ситуация довольно интересно обрабатывается виндой), или же неверно выставленные права на директорию с приложением. Итак, что же BeRoot умеет находить? Для начала те самые пути с пробелами, не обрамленные кавычками:
C:\Program Files\SomeTest\binary.exe.
В данном случае Windows будет пытаться найти и запустить файл в следующем порядке:
Если посмотреть запись для этой службы в системном реестре, то можно увидеть ключ ImagePath значение которого:
C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe
“C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe”
Данный способ называется Неквотируемые пути служб (Unquoted Service Paths)
Далее, проверяются интересные директории, куда мы можем что-либо записать. Эти интересные директории составляются из путей до исполняемых файлов сервисов, запланированных заданий, ключей автозагрузки (HKLM).
Следующим этапом проверяется переменная окружения %PATH%, не содержит ли она директорий, доступных для записи. Если так, то на ОС от Vista до Windows Server 2016 можно будет выполнить DLL Hijacking
Примеры и Триксы
Для проверки прав на папку можно воспользоваться встроенной тулзой
icacls. Ниже показан результат проверки прав для C:\Program Files (x86)\Program Folder:
Как видим группа “Everyone” имеет полный доступ к этой папке. Значит,
мы можем записать любой файл в эту папку.
Описание некоторых флагов в выводе команды icacls:
F = Full Control (полный доступ)
CI = Container Inherit (наследование контейнерами)
OI = Object Inherit (только наследование)
Теперь создадим reverse shell пэйлоад, который запустится с правами SYSTEM.
Для этого можем воспользоваться MSFvenom:
При следующем старте службы A.exe должен запуститься с правами
SYSTEM. Давайте проверим – рестартанем уязвимую службу:
Помимо только поиска уязвимых мест, BeRoot предоставляет возможность проэксплуатировать уязвимость MS16-075 (если она есть). Стандартный трюк с добавлением своего админа будет выглядеть следующим образом:
Повышение привилегий Windows. BeRoot нашел несколько доступных для записи директорий, указанных в переменной окружения PATH Также проверяются файлы, оставшиеся от Unattended Install, которые могут хранить данные админской учетки. Ну и на всякий случай проверяются такие экзотические вещи, как доступность сервиса для модификации, возможность создания нового сервиса, возможность создания ключа автозагрузки в HKLM, а также возможность записи в директорию, где хранятся запланированные задания.
В этом примере Vulnerable.exe содержит DLL hijacking уязвимость. Так как это демонстрация, то Vulnerable.exe является кодом, который подгружает длл без всяких проверок:
Если разбираться, что же такое DLL hijacking, то это хорошо расписано этой статье (Dynamic-Link Library Security (Windows)):
Когда приложение динамически подгружает динамическую библиотеку без указания полного пути (fully qualified path name) к библиотеке, то Windows пытается локализировать эту длл путем поиска в хорошо регламентированном списке директорий и в определенном порядке (детально это описано в Dynamic-Link Library Search Order). Если атакующему удается получить контроль над одной из директорий из списка поиска, то он может поместить вредоносную копию длл в эту директорию.
Это еще иногда называют preloading attackилиbinary planting attack. Если системе не удается найти легитимную длл до поиска в скомпрометированной директории, то будет загружена вредоносная длл. И если приложение выполняется с админскими правами, то атакующему удасться произвести локальное повышение привилегий (local privilege elevation).
Когда процесс пытается подгрузить длл, то система будет выполнять поиск длл в директориях в следующем порядке:
1. В директории из которой запущено приложение
2. В системных директориях
3. В системных директориях для 16-битных приложений
4. В директории Windows
5. В текущей директории
6. В директориях, указанных в переменной окружения %PATH%
Для эксплуатирования данной уязвимости нам необходимо проделать
следующие шаги:
— Проверить существует ли длл которую подгружает процесс в какой-то
директории на диске.
— Если такой длл нет, то необходимо поместить нашу вредоносную копию
длл в одну из директорий, перечисленных выше. Когда процесс будет
запущен он найдет и подгрузит нашу длл.
— Если длл существует в одной из перечисленных директорий, то
необходимо попробовать поместить нашу вредоносную длл в директорию с
более высоким приоритетом поиска чем та, в которой лежит обычная длл.
Давайте проверим есть ли hijackable.dll на целевой машине: