Всем привет!
Сегодня мы рассмотрим один из способов пост-эксплуатации Rid hijacking и посмотрим его артефакты.
Что это такое?
Rid hijacking - атака, при которой путем подмены Rid в SAM можно превратить обычного локального пользователя в локального админа
Условия для выполнения
Для реализации техники нам необходимо:
Права системы для доступа к SAM
Возможность создавать локального пользователя на машине (в домене может быть групповая политика, запрещающая создании локальных пользователей )
Что такое Rid?
У каждого пользователя есть свой Sid, в его структуре есть Rid - уникальный тег для каждой учетной записи. Для обычных пользователей он начинается =>1000

Для стандартных учетных записей есть зарезервированные Rid, например:
Администратор -
500
, или же1F4
Гость -
501
, или же1F5
Где находится Rid?
Значения Rid хранятся в SAM, а именно в HKLM\SAM\SAM\Domains\Account\Users

У каждого пользователя есть несколько ключей, нас интересует ключ “F“

Первые 4 байта строки смещению 0x30 содержат Rid, в данном случае это Rid админа, именно эту строчку нужно заменить у обычной учетной записи чтобы превратить ее в админа.

Пусть к успеху
В итоге имеем следующий план: определяем Rid пользователя → изменяем первые 4 байта строки по смещению 0x30
ключа “F“
в HKLM\SAM\SAM\Domains\Account\Users\(Rid пользователя)
на F401
(Rid админа)
Эксплуатация через GUI
У нас есть обычный пользователь, без особых прав

Находим пользователя по его Rid значению в SAM
В ключе “F“
меняем первые 4 байта смещению 0x30
на F401
Как было:

Как стало:

В итоге получаем обычного пользователя с Rid админа и соответствующими правами

В группу админов пользователь не отображается

Боевая эксплуатация
А теперь смоделируем реальную ситуация, у нас есть системный шел и мы хотим по тихому закрепиться на машине. Создаем локальную учетную запись net user sociska Qq123456! /add

Теперь надо узнать Rid пользователя, я пойду по самому простом пути и просто запрошу список всех Rid в SAM, так как только что создали нового пользователя, его Rid будет самым последним reg query “HKLM\SAM\SAM\Domains\Account\Users“

Запрашиваем значение ключа “F“
и находим, где расположены наши несчастные 4 байта (EE030000)
reg query “HKLM\SAM\SAM\Domains\Account\Users\RID“ /v F

Меняем 4 байта на F4010000
(Rid админа)
reg add “HKLM\SAM\SAM\Domains\Account\Users\RID“ /v F /t REG_BINARY /d ……….

Проверяем что все работает

И пользователя все также нет в группе админов

Артефакты
reg query “HKLM\SAM\SAM\Domains\Account\Users“:
4688 - создание процесса reg.exe
4673 - вызов привилегированный службы (reg.exe)
4656 - запрос дескриптора ключа реестра
HKLM\SAM\SAM\Domains\Account\Users
4663 - попытка доступа к объектам
HKLM\SAM\SAM\Domains\Account\Users\*
(тут было много событий так как доступ запрашивается к каждому ключу )sysmon 1 - создание процесса reg.exe (в comamandLine была вся команда)
reg query “HKLM\SAM\SAM\Domains\Account\Users\RID“ /v F:
4688 - создание процесса reg.exe
4673 - вызов привилегированный службы (reg.exe)
4656 - запрос дескриптора ключа реестра
HKLM\SAM\SAM\Domains\Account\Users\RID
4663 - попытка доступа к объекту
HKLM\SAM\SAM\Domains\Account\Users\RID
sysmon 1 - создание процесса reg.exe (в comamandLine была вся команда)
reg add “HKLM\SAM\SAM\Domains\Account\Users\RID“ /v F /t REG_BINARY /d ……….:
4688 - создание процесса reg.exe
4673 - вызов привилегированный службы (reg.exe)
4656 - запрос дескриптора ключа реестра
HKLM\SAM\SAM\Domains\Account\Users\RID
4663 - попытка доступа к объекту
HKLM\SAM\SAM\Domains\Account\Users\RID
4657 - изменение значения ключа реестра
sysmon 1 - создание процесса reg.exe (в comamandLine была вся команда)
sysmon 12 - удаление объекта в реестре
sysmon 13 - изменение значения в реестре
В итоге получаем интересный, но достаточно шумный способ пост-эксплуатации

gleb4u
Год в сисадминстве ( Жёстком таком, на аутсорсе, с 100+ компаниями), пол года в ИБ, и читая эту статью я почувствовал, что она написана хорошо и понятно для обычного человека ( не семи пядей во лбу) увидел для себя очень много интересного
Но есть один минус, нужно из под админа как то такое провернуть, так же вопрос, мне кажется в доменной структуре AD получиться ли провернуть, что то подобное, т.е. оставить пользователя без отображения членства в группе, но с правами админа ( 99% уверен, что нет, но хочу услышать какие то ваши мысли на тему)
Так же интересно, какими "стандартными" средствами такое можно детектить, в каких EDR агентах такое может быть настроено ПО УМОЛЧАНИЮ, потому что ручками отсматривать журналы, это дело неблагодарное
Заранее спасибо
OziSec Автор
Доброго времени суток!
С радостью отвечу на ваши вопросы:
Данный способ получится провернуть только для локальных пользователей, так как мы изменяем SAM (диспетчер локальных учётных записей безопасности). Всё, что касается доменных учёток, никак не фигурирует в сущности SAM.
Также небольшое дополнение к вашим словам: изменять SAM можно только с правами SYSTEM, так как SAM — критически важный компонент ОС.
Касаемо детекта:
Каждая EDR по-своему устроена под "капотом", но я предполагаю, что любая современная EDR способна отслеживать цепочки событий + контроль WinAPI, что позволяет покрыть детект изменений в реестре с "коробки", в частности в SAM.
Также для более углубленного мониторинга можно интегрировать EDR с SIEM решениями