De kennis uit een aanvalslab is pas iets waard als je er iets mee verdedigt. Dat is voor mij het hele punt geweest. Ik heb MARVEL.local niet gebouwd om aanvaller te worden, maar om te zien waar een omgeving onderuitgaat, zodat ik weet waar je moet ingrijpen.
Bijna elke stap in mijn aanvalsketen begon bij een gewone fout in de inrichting. Oude naamresolutie die nog aanstond, waardoor ik verkeer naar me toe kon lokken. SMB signing dat op de domaincontroller netjes was afgedwongen, maar op de werkstations niet, waardoor juist die een doelwit voor relay werden. Een domeingebruiker die op meerdere werkstations lokaal beheerder was, en los daarvan een lokaal Administrator-account dat op beide werkstations hetzelfde wachtwoord had. Een serviceaccount met een zwak wachtwoord en veel te veel rechten, dat door een te ruim groepslidmaatschap uiteindelijk bij de domeincontroller kon. Stuk voor stuk geen hoogstandjes.
Daar volgen de maatregelen vrij direct uit. Zet oude naamresolutieprotocollen als LLMNR en NBT-NS uit, want ze leveren zelden iets nuttigs op en kosten je in een aanval alles. Dwing SMB signing overal af, niet alleen op je domaincontrollers. In mijn Windows 10-lab stond het op de werkstations niet verplicht, al heeft Microsoft die standaard in nieuwere Windows-versies aangescherpt. Geef verder elke machine een uniek lokaal beheerderswachtwoord, bijvoorbeeld met LAPS, zodat één gekraakt wachtwoord niet meteen het halve netwerk opent. Beperk daarnaast welke domeinaccounts überhaupt lokaal beheerder mogen zijn, want dat is een ander risico dat LAPS niet afdekt. En geef serviceaccounts lange, willekeurige wachtwoorden en niet meer rechten dan ze nodig hebben, want juist die accounts zijn een geliefd doelwit.
De gevaarlijkste les ging over Active Directory zelf. Controleer wie er replicatierechten heeft, want dat is het recht waarmee een domein in één keer leegloopt met DCSync. In mijn lab was het een serviceaccount met een veel te ruim groepslidmaatschap dat uiteindelijk bij de domeincontroller kon; geef accounts daarom nooit meer rechten dan ze nodig hebben, en houd kritieke rechten als replicatie strak. Bescherm daarnaast de LDAP-kant, want relay-aanvallen bestaan ook tegen LDAP. LDAP-signing en, bij LDAP over TLS, channel binding voorkomen dat authenticatie zomaar via een andere verbinding wordt doorgestuurd. Alleen LDAPS gebruiken is daarvoor niet genoeg.
Eén les zit dieper dan een losse instelling. Toen ik in het lab een Golden Ticket maakte, werd duidelijk dat sommige compromittering niet met een wachtwoordreset is op te lossen. Zolang de sleutel van het KRBTGT-account geldig is, blijft vervalst vertrouwen werken. Herstel daarvan vraagt een bewuste, dubbele reset en een controle op wat er verder is achtergelaten. Het is het verschil tussen een inbraak opruimen en het slot daadwerkelijk vervangen.
Minstens zo belangrijk als dichttimmeren is zichtbaarheid. Dit soort aanvallen laat herkenbare sporen na: afwijkende naamresolutie, een ongebruikelijke golf aan Kerberos-ticketaanvragen, een account dat ineens replicatierechten krijgt. Met de juiste logging en detectieregels kan een verdediger die activiteit opmerken. Dat soort detecties zelf laten afgaan en valideren is een volgende stap die ik in mijn lab wil zetten.
Dat laatste is meteen de belangrijkste les die ik meeneem. Je vertrouwt pas een detectie die je zelf hebt zien afgaan. Een maatregel die nooit is getest, is een aanname. Door het in een eigen omgeving te oefenen zie je niet alleen hoe een aanval werkt, maar ook of je verdediging daadwerkelijk aanslaat.
Dat is uiteindelijk de rode draad van dit lab. Je leert een omgeving pas echt beschermen als je zelf hebt gezien hoe ze valt. Dat inzicht, aanvallen om beter te kunnen verdedigen, neem ik mee in alles wat ik hierna inricht of onderzoek.
In deze reeks over MARVEL.local
- MARVEL.local: mijn Active Directory oefenlab voor de PNPT
- De aanvalsketen in MARVEL.local
- Wat MARVEL.local mij leerde over verdedigen
- Output, beslissing, bewijs: mijn werkwijze