In de vorige posts verwees ik steeds naar dezelfde werkwijze, output, beslissing, bewijs. Tijd om die hardop te maken, want uiteindelijk is die methode belangrijker dan welke tool ik ook gebruik. Tools wisselen, de manier van denken blijft.
In de praktijk werd het een vaste lus. Ik kijk eerst wat er feitelijk is, welke poorten, namen, accounts en foutmeldingen ik echt zie. Daar vorm ik een hypothese bij, wat zou dit kunnen betekenen. Dan kies ik de kleinste test met de hoogste informatiewaarde, voer die gericht uit, en controleer of de uitkomst mijn hypothese echt bewijst. Daarna leg ik het vast en kies ik de volgende stap. Observeren, afleiden, beslissen, uitvoeren, valideren, vastleggen, door.
De kern zit in dat valideren. Een tool geeft je output, maar output is geen conclusie. De grootste valkuil, in security en net zo goed in gewoon beheer, is dat je iets laat draaien en de uitkomst leest zoals je hoopt dat die eruitziet. Daarom dwing ik mezelf om bij elke stap ook te vragen wat de output nadrukkelijk niet bewijst.
Dat verschil heb ik in mijn lab het hardst geleerd op één punt: authenticatie is iets anders dan autorisatie. Een geldige credential toont dat ik me als een bepaalde identiteit kan aanmelden. Wat ik daarna mag, aan systemen, gegevens en beheerfuncties, is een aparte vraag. Een account kon zich aanmelden en op de ene machine alles, en op de andere niets. Lokale beheerrechten op een werkstation zeiden nog niets over het domein. Wie die twee door elkaar haalt, trekt te snel een conclusie en bouwt zijn volgende stap op drijfzand.
Zo zag die lus eruit bij één concrete stap in mijn lab:
| Stap | Voorbeeld uit MARVEL.local |
|---|---|
| Observatie | fcastle beschikt over geldige domeincredentials. |
| Hypothese | Dit account heeft mogelijk lokale beheerrechten op meerdere machines. |
| Test | De rechten per doelmachine controleren. |
| Bewijs | Beheerrechten op de werkstations, niet op de domaincontroller. |
| Conclusie | Lokaal beheer betekent niet automatisch domeinbeheer. |
En voor en na elke stap leg ik vast wat die stap onderbouwt. Wat liet zien dat iets werkte, of juist niet. In een pentest wordt dat de documentatie waar een opdrachtgever iets aan heeft. Zonder bewijs is een bevinding niet meer dan een bewering, en een bewering kan niemand controleren of herstellen.
Wat me er het meest aan bevalt, is dat het niet aan aanvallen gebonden is. In pentesten en in security operations werkt precies hetzelfde. Een handeling geeft output, je besluit op basis daarvan, en je houdt bewijs van wat er gebeurde en waarom. Een incidentonderzoek is diezelfde lus. Of ik nu een pad door mijn lab volg of een incident uitzoek, de structuur verandert niet.
Dat is ook waarom ik er gerust op ben dat deze manier van werken meekomt naar het echte werk. De techniek leer ik per omgeving wel. De methode heb ik al. En iemand die zijn beslissingen kan onderbouwen, is op termijn meer waard dan iemand die alleen de knoppen kent.
Hiermee is de serie rond. Een eigen lab om te begrijpen hoe identiteit sneuvelt, de aanvalsketen die ik erin doorliep, de verdedigingslessen die eruit volgden, en de werkwijze die het geheel bij elkaar houdt. Begrijp de aanval, verdedig op basis daarvan, en zorg dat je elke stap kunt uitleggen. Zo werk ik.
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