SIDHistory
История SID используется для миграции. Когда пользователь мигрирует из одного домена в другой, привилегии пользователя сбрасываются, создается новый SID, пользователь добавляется в новые группы и т. д. Однако SID из групп, к которым пользователь принадлежит в старом домене, сохраняются. в атрибуте История SID.
Затем, когда пользователь хочет получить доступ к ресурсам в старом домене, его исторические SID добавляются в поле дополнительных SID PAC ((сертификат атрибута привилегий) содержит информацию о безопасности, связанную с клиентом). Таким образом, старый домен может просмотреть эти SID и предоставить пользователю его старые привилегии, что позволит ему получить доступ к ресурсам старого домена.
Однако дополнительные SID могут быть опущены (не скопированы в ST PAC) в соответствии с политикой фильтрации SID. Как правило, домены разрешают SID из других доменов в лесу (по умолчанию), но отбрасывают дополнительные SID из внешних лесов в соответствии с правилом ForestSpecific, поскольку лес является границей безопасности Active Directory. Кроме того, домены одного и того же леса также могут быть помещены в карантин, что позволит удалить лишние SID с помощью политики QuarantinedWithinForest.
История SID может быть включена в доверии между доменами разных лесов с некоторыми ограничениями. Допускаются группы с SID целевого (доверяющего) леса, у которых RID выше 1000. Следовательно, административные группы, такие как «Администраторы домена» (RID = 512), чей RID ниже 1000, фильтруются.
Затем, если история SID редактируется, могут быть введены административные привилегии для других доменов. Например, если вы внедрите SID Enterprise Admins в историю SID пользователя, то пользователь может иметь административные привилегии во всем лесу. Атрибут SID History можно редактировать непосредственно в базе данных Active Directory с помощью команды
mimikatz misc::addsid
Однако, как мы уже говорили ранее, история SID копируется в PAC TGT, поэтому, если мы можем создать Golden Ticket, мы можем внедрить нужные SID непосредственно в атрибут дополнительных SID PAC. Затем, когда мы используем этот билет, его PAC копируется в межобластной TGT. Впоследствии, при использовании этого межобластного TGT для получения ST для службы во внешнем домене, если этот домен находится в том же лесу, привилегированные SID могут быть скопированы в ST PAC, что дает нам привилегии, которые у нас изначально были в модифицированном Golden Ticket.
На самом деле, если вы скомпрометируете корневой лес домена и создадите Golden Ticket, который включает группу «Администраторы предприятия» (чей RID равен 519), вам не нужно создавать Golden Ticket с дополнительными SID, поскольку у вас уже есть разрешения на управление всем лесом, даже доменами, помещенными в карантин (поскольку нет дополнительных SID для фильтрации). Добавление «Enterprise Admins» к дополнительным SID необходимо только в том случае, если вы скомпрометировали некорневой домен и хотите скомпрометировать другой домен леса, за исключением доменов, помещенных в карантин, которые фильтруют дополнительные SID.
Для выполнения атаки dcsync в другом домене, возможно понадобится SID «контроллеры домена предприятия» (S-1-5-9) и «Контроллеры домена» (S-1-5-21-domain-516).
Для создания Golden Ticket вы можете использовать команду
mimikatz kerberos::golden
или скрипт impacket ticketer.py, аналогичный созданию Golden Ticket, но с добавлением дополнительных SID. Если можете, используйте ключ AES256, чтобы избежать обнаружения средсвами защиты.