Использование PowerShell для повышения привилегий локальных учетных записей

Автор оригинала: MICHAEL BUCKBEE
  • Перевод


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

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


Если вы специалист по безопасности, это может показаться очевидным, что пользователи не должны иметь права локального администратора, так как это:

  • Делает их аккаунты более уязвимыми к различным атакам
  • Делает эти самые атаки гораздо более серьезными

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

Шаг 1. Обратное разрешение DNS имен через PowerShell


По-умолчанию PowerShell устанавливается на многих локальных рабочих станциях и на большинстве серверов Windows. И хотя не без преувеличения он считается невероятно полезным инструментом автоматизации и управления, в равной степени он способен превращаться в почти невидимую fileless-малварь (программа для взлома, не оставляющая следов атаки).

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

 import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}

Если скорость работы в больших сетях вызывает проблемы, то может использоваться обратный системный вызов DNS:

[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName




Этот метод перечисления узлов в сети очень популярен, так как большинство сетей не использует модель безопасности с нулевым доверием и не отслеживает внутренние DNS запросы на подозрительные всплески активности.

Шаг 2: Выбор цели


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



Судя по имени, сервер 'HUB-FILER' кажется достойной целью, т.к. с течением времени файловые серверы, как правило, аккумулируют большое количество сетевых папок и избыточного доступа к ним слишком большого круга лиц.

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

Шаг 3: Изучаем ACL


Теперь на нашем хосте HUB-FILER и целевой общей папке share мы можем запустить сценарий PowerShell для получения списка ACL. Мы можем сделать это с локальной машины, так как у нас уже имеются права локального администратора:

(get-acl \\hub-filer\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto


Результат выполнения:



Из него мы видим, что группа Пользователи Домена имеет доступ только на листинг, но вот группа Helpdesk имеет еще и права на изменение.

Шаг 4: Идентификация Учетных Записей


Запустив Get-ADGroupMember, мы сможем получить всех членов этой группы:

Get-ADGroupMember -identity Helpdesk




В этом списке мы видим учетную запись компьютера, которую мы уже идентифицировали и к которой уже получили доступ:



Шаг 5: Используем PSExec для работы от учетной записи компьютера


PsExec от Microsoft Sysinternals позволяет выполнять команды в контексте системной учетной записи SYSTEM@HUB-SHAREPOINT, которая, как мы знаем, является членом целевой группы Helpdesk. То есть нам достаточно выполнить:

PsExec.exe -s -i cmd.exe

Ну а далее у вас есть полный доступ к целевой папке \\HUB-FILER\share\HR, поскольку вы работаете в контексте учетной записи компьютера HUB-SHAREPOINT. И с этим доступом данные могут быть скопированы на портативное устройство хранения или иным образом извлечены и переданы по сети.

Шаг 6: Обнаружение данной атаки


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

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

На скриншоте ниже показано пользовательское уведомление, которое будет срабатывать при каждом доступе учетной записи компьютера к данным на отслеживаемом сервере.



Следующие шаги с помощью PowerShell


Хотите узнать больше? Используйте код разблокировки «blog» для бесплатного доступа к полному видео-курсу PowerShell и Основы Active Directory.
Varonis Systems
Компания

Комментарии 9

    +1
    Все понятно кроме этого.
    «В этом списке мы видим учетную запись компьютера, которую мы уже идентифицировали и к которой уже получили доступ:»
    Такое ощущение что кусок выдрали. Когда доступ к Sharepoint появился? О наличии оного в группе helpdesk только что узнали и уже есть доступ?
      +1
      Как было указано выше в статье, предполагается, что доступ для атаки на Hub-Sharepoint уже был получен в рамках отдельных атак: это могли быть фишинг, эксплоиты, соц.инженерия и т.п. В этой статье мы опускаем подробности получения рут-доступа к этому серверу, это будет тема отдельного цикла статей по неуловимой малвари. Поэтому в этот раз это было опущено намеренно, очевидно, здесь просто возникла путаница.
        0
        Ну тогда я бы добавил в самом начале больше вводных данных и ссылки на статьи или указали, что как было написано ранее в статье(ссылка). И если вы упускаете как получили доступ то так и надо писать. Просто логическая цепочка ломается и статья теряет целостность.
      0
      мы считаем, что злоумышленник получил права локального администратора на исследуемой системе


      Ок, получил.
      Но ему же еще надо попасть в домен. Или он еще и права доменного пользователя получил?..
        0
        Локальная учетная запись пользователя является доменной записью и обладает правами админа на исследуемой системе — тут все как в классике. По сути статья является ещё одним предупреждением не давать прав админа, в том числе, и доменным учёткам.
          0
          Ни разу такого не встречал… Если разворачивать домен, то и переносить пользователей туда же, не? Тем же Powershell'ом — минутное дело. Но Вам виднее, конечно — если говорите, что это классика.
            0
            Ну как же, ведь были компоненты от BS которые стартовали только от локального администратора. Это было давно. Но скорее всего есть некоторый софт, который стартует только от администратора. В силу того, что его не переписали а в продакшене он используется.
        0
        А каким образом учетная запись компьютера попала в группу «HelpDesk»?
          0
          Это нам неведомо, но факт остаётся фактом. Мы часто с таким сталкиваемся в реальности.

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

        Самое читаемое