Een domein wordt zelden met één klap overgenomen. Dat was misschien wel de belangrijkste les uit MARVEL.local. Een inbraak is een ketting van kleine stappen, waarbij elke stap de volgende mogelijk maakt. In mijn lab heb ik de verschillende schakels van zo’n keten geoefend, van de eerste verkenning zonder toegang tot volledige controle over de domaincontroller. Sommige daarvan waren aparte onderzoekspaden, en juist door ze naast elkaar te leggen begreep ik hoe ze in elkaar grijpen.
Het begint met luisteren. In een Windows-netwerk vallen machines soms terug op oude naamresolutie als gewone DNS een naam niet vindt, en dat laat zich misbruiken. Met Responder onderschepte ik op mijn testmachine authenticatieverkeer dat daardoor de verkeerde kant op ging, onder andere van een gebruikersaccount en van een computeraccount. Dat opgevangen materiaal is geen herbruikbaar wachtwoord en geen kant-en-klare hash. Het is iets dat je onder de juiste omstandigheden offline kunt kraken of live kunt doorsturen. Het bewijst op zichzelf nog geen toegang.
Met een gekraakte domeincredential werd duidelijk wat die mocht. Dezelfde gebruiker was lokaal beheerder op de werkstations, maar niet op de domaincontroller. Via gereedschap uit de Impacket-suite kon ik op die werkstations opdrachten als SYSTEM uitvoeren, en uit de opslag van zo’n machine haalde ik nog meer: lokale hashes, een machineaccount, en gecachte aanmeldgegevens van een domeinbeheerder die ooit op dat werkstation had ingelogd. Dat voelde als een doorbraak, tot ik doorhad wat het niet was. Ik had machines overgenomen, maar het domein nog lang niet.
Omdat SMB signing op de werkstations niet was afgedwongen, was daar trouwens ook een relay-aanval mogelijk, waarbij je authenticatie doorstuurt naar een machine die niet tekent. Op de domaincontroller stond signing wél verplicht. Dat verschil is precies waarom juist de werkstations een zwakke plek waren.
Dat is de kloof die het lab me het scherpst liet zien. Lokaal beheer op een paar endpoints is niet hetzelfde als controle over het domein. Je kunt zijwaarts bewegen, geheimen van die machines plukken en hergebruiken, maar om bij de domaincontroller te komen heb je iets anders nodig: hogere domeinrechten, een misbruikbaar serviceaccount, of verkeerd toegewezen rechten in Active Directory zelf. Dat besef veranderde hoe ik naar de rest van de aanval keek.
Om die paden te vinden bracht ik het domein in kaart met BloodHound. Daarmee teken je de rechten en vertrouwensrelaties uit: wie heeft rechten op wie, en welk account leidt via een omweg naar de top. Opeens zie je het domein zoals een aanvaller het ziet, als een web van relaties waarin één verkeerd gezet recht een snelweg naar boven kan vormen.
Het pad dat uiteindelijk naar de top leidde, liep via Kerberoasting. Elke domeingebruiker mag een Kerberos-ticket opvragen voor een account met een servicenaam, en dat ticket kun je offline kraken als het wachtwoord zwak is. Via GetUserSPNs vond ik het account SQLService, waarvan ik het wachtwoord offline achterhaalde. Het bestaan van zo’n serviceaccount is normaal; het probleem was de combinatie van een zwak wachtwoord en veel te ruime rechten. Dit account zat in een groep die het nooit had mogen hebben, en daarmee kwam ik op de domaincontroller zelf.
Vanaf dat punt kon ik DCSync uitvoeren, waarbij je de domaincontroller via zijn eigen replicatieprotocol om gevoelige domeingegevens vraagt, waaronder de wachtwoord-hashes van alle accounts. Niet door een muur te slopen, maar doordat één account een recht had dat het nooit had mogen hebben. Dat DCSync bestaat, is geen fout; domeincontrollers gebruiken het onderling om te synchroniseren. De fout zit in wie het mag aanroepen.
Tot slot gebruikte ik de hash van het KRBTGT-account om een Golden Ticket te maken, de sleutel waarmee je in principe zelf toegangstickets kunt vervalsen. Het ging me niet om het trucje zelf, maar om wat een geldig Golden Ticket aantoont: zolang die ene sleutel geldig is, kun je het vertrouwen in het hele domein blijven vervalsen, ook nadat wachtwoorden zijn gewijzigd. Precies dat maakt herstel zo ingrijpend.
Wat ik uit dit alles meeneem, is dat de uitgangspositie weinig zegt over de eindschade. Een verouderd protocol dat niemand uitzette, SMB signing dat op de werkstations ontbrak, een wachtwoord dat te zwak was, een serviceaccount met veel te veel rechten. Stuk voor stuk klein, samen genoeg om een heel domein te verliezen. Wie dat van dichtbij heeft gezien, kijkt anders naar hoe je zo’n omgeving zou moeten inrichten. En daar gaat de volgende post over.
In deze reeks over MARVEL.local