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

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

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

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

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

Шаг 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.