RID Hijacking

Всем привет!

Сегодня мы рассмотрим один из способов пост-эксплуатации 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

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

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

Артефакты

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 — изменение значения в реестре

В итоге получаем интересный, но достаточно шумный способ пост-эксплуатации