Persistentie Detecteren

Minder Trust, Minder Schade

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

In Persistentie Detecteren ontstaat waarde wanneer detectie direct bruikbaar is voor opvolging, niet alleen voor rapportage.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Persistentie Detecteren is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Detectie en verdediging

Detectiematrix

Verdedigingslagen

Laag 1: Preventie

# LSA Protection inschakelen
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "RunAsPPL" -Value 1 -PropertyType DWORD

# Credential Guard inschakelen (via Group Policy)
# Computer Configuration > Administrative Templates > System > Device Guard
# > Turn On Virtualization Based Security > Credential Guard: Enabled

LSA Protection voorkomt Custom SSP en Skeleton Key. Credential Guard isoleert credentials zodat zelfs een gecompromitteerde kernel ze niet kan benaderen.

Laag 2: Monitoring

De absolute minimum-set aan monitoring voor persistentiedetectie:

# Sysmon configuratie (relevant excerpts)
- Event 13: Registry value wijzigingen
  Filter op: \Control\Lsa\Security Packages
  Filter op: \Control\Lsa\DsrmAdminLogonBehavior

# Windows Security Event Log
- Event 4780: ACL wijziging op beschermd object (SDProp-gerelateerd)
- Event 5136: Directory service object wijziging
- Event 4794: DSRM password instelling
- Event 4769: Kerberos TGS requests (filter op RC4 encryption)

Laag 3: Regelmatige audits

# AdminSDHolder ACL controleren
(Get-Acl "AD:\CN=AdminSDHolder,CN=System,DC=domain,DC=local").Access |
  Format-Table IdentityReference, ActiveDirectoryRights

# Security Packages registry controleren
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\ `
  -Name 'Security Packages'

# DsrmAdminLogonBehavior controleren
Get-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa\ `
  -Name "DsrmAdminLogonBehavior" -ErrorAction SilentlyContinue

Voer deze controles maandelijks uit. Beter nog: automatiseer ze en alert bij afwijkingen.

Laag 4: Incident Response

Als je persistentie ontdekt, is de keten van acties afhankelijk van de methode:

Die laatste — Golden Certificate — is reden genoeg om je CA-key in een HSM te bewaren. Een volledige PKI-heruitgifte is een operatie die weken duurt en het hele netwerk raakt.

De werkelijkheid van “we hebben alles opgeruimd”

Laten we eerlijk zijn over het incident response-proces bij de meeste organisaties. Het SOC ontdekt een compromis. Er wordt een crisisteam samengesteld. Er worden wachtwoorden gereset, werkstations opnieuw geïmaged, en VPN-toegangen uitgeschakeld. Na twee weken intensief werk verklaart het management: “We hebben de situatie onder controle. De aanvaller is verwijderd.”

En misschien is dat waar. Misschien.

Maar heb je de AdminSDHolder-ACL gecontroleerd? Heb je de Security Packages in het register van elke DC geïnspecteerd? Heb je het DsrmAdminLogonBehavior op elke DC gecontroleerd? Heb je de WMI-security descriptors geaudit? Heb je de CA-private key geroteerd? Heb je SIDHistory van alle accounts gecontroleerd?

In de overgrote meerderheid van de gevallen is het antwoord: nee. Niet uit onwil, maar uit onwetendheid. De meeste incident response-teams focussen op werkstations en servers — bestanden, processen, netwerk-connecties. Ze zoeken naar malware. Naar C2-kanalen. Naar indicators of compromise die in hun SIEM-regels staan.

Maar de persistentiemechanismen in dit hoofdstuk leven niet op werkstations. Ze leven in Active Directory zelf. In ACL’s. In security descriptors. In registry keys op de DC. In het geheugen van LSASS. Plekken waar het incident response-team niet kijkt, omdat het niet weet dat het daar moet kijken.

Het is als een ziekenhuisteam dat de patiënt behandelt voor een gebroken been terwijl er een tumor groeit die niemand heeft opgemerkt. Het been geneest. De patiënt gaat naar huis. En drie maanden later is het weer mis, en niemand begrijpt waarom.

De les is simpel maar oncomfortabel: een incident response is pas compleet wanneer je actief hebt gezocht naar — en uitgesloten — elke persistentiemethode die de aanvaller had kunnen implementeren. Niet de methoden die je kent. Alle methoden. En dat vereist kennis die de meeste teams niet hebben, tijd die het management niet wil geven, en tools die de meeste organisaties niet bezitten.

“We hebben alles gepatcht.” Nee, je hebt de voordeur gerepareerd. De aanvaller zit nog steeds in de kelder.

Het clean-up probleem

Er is nog een dimensie die dit alles complexer maakt: zelfs wanneer je weet welke persistentiemechanismen er zijn, is het verwijderen ervan niet triviaal. Neem de AdminSDHolder-backdoor. Je vindt de kwaadaardige ACE, je verwijdert hem. Maar heb je ook alle beschermde groepen gecontroleerd? SDProp heeft de ACE al gekopieerd naar Domain Admins, Enterprise Admins, en alle andere beschermde groepen. Je moet de ACE verwijderen van AdminSDHolder en van elke groep waar hij naartoe is gekopieerd. Miss je er een, dan werkt de backdoor nog steeds.

Of neem de Custom SSP. Je vindt de DLL in System32 en de registry entry. Je verwijdert beide. Maar heb je het logbestand gecontroleerd? C:\Windows\system32\mimilsa.log staat vol met cleartext wachtwoorden. Als de aanvaller dat bestand al heeft geexfiltreerd, zijn al die wachtwoorden gecompromitteerd — zelfs na het verwijderen van de SSP. Je moet dan alle wachtwoorden resetten van iedereen die heeft ingelogd sinds de SSP actief was.

En bij de Golden Certificate: als de CA-private key is gestolen, is er eigenlijk maar een oplossing die garantie biedt: een volledige PKI-herinstallatie. Nieuwe CA. Nieuwe root key. Nieuwe certificaten voor iedereen. In een omgeving met duizenden systemen is dat een project van maanden.

De harde waarheid is dat sommige persistentiemechanismen zo diep gaan dat de enige betrouwbare oplossing een volledige rebuild van het domein is: een nieuw forest, nieuwe DC’s, nieuwe accounts, gecontroleerde migratie van data. Dat is de nucleaire optie. Maar soms is het de enige optie.

Persistentie audit checklist

Als pen tester of als verdediger: gebruik deze checklist na elk compromis om systematisch persistentie uit te sluiten:

Active Directory niveau:
[ ] AdminSDHolder ACL gecontroleerd op ongeautoriseerde ACE's
[ ] SIDHistory van alle accounts gecontroleerd (geen verdachte SID's)
[ ] Alle GP-links en GPO's gecontroleerd op kwaadaardige scripts
[ ] Alle certificate templates gecontroleerd op wijzigingen
[ ] CA configuratie gecontroleerd (EDITF_ATTRIBUTESUBJECTALTNAME2)
[ ] Kerberos krbtgt-wachtwoord twee keer gereset (golden ticket invalidatie)
[ ] Replicatie-metadata gecontroleerd op DCShadow-sporen

Domain Controller niveau (per DC):
[ ] Security Packages registry key gecontroleerd
[ ] DsrmAdminLogonBehavior registry key gecontroleerd
[ ] WMI namespace security descriptors gecontroleerd
[ ] WinRM endpoint security descriptors gecontroleerd
[ ] Remote Registry security descriptors gecontroleerd
[ ] Scheduled tasks gecontroleerd
[ ] Services gecontroleerd
[ ] DLL's in System32 gecontroleerd tegen baseline
[ ] LSASS memory geanalyseerd (Skeleton Key, custom SSP)

PKI niveau:
[ ] CA private key integriteit geverifieerd
[ ] Alle uitgegeven certificaten gereviewed
[ ] Onverwachte certificaten ingetrokken

Account niveau:
[ ] Alle wachtwoorden gereset (inclusief service accounts)
[ ] DSRM-wachtwoorden gereset op elke DC
[ ] Alle Kerberos tickets geïnvalideerd

Persistentie prioritering

Niet alle persistentiemethoden zijn gelijk. Als aanvaller kies je op basis van je situatie:

De meest robuuste strategie combineert meerdere methoden in verschillende categorieën: een ACL-gebaseerde methode (AdminSDHolder), een credential-harvest methode (Custom SSP), en een authenticatie-backdoor (DSRM of Golden Certificate). Redundantie is de sleutel — als het incident response-team een methode vindt, heb je nog twee over.

In het volgende hoofdstuk behandelen we tunneling-beheersing — hoe je ongewenste verborgen verbindingen voorkomt, detecteert en blokkeert in productieomgevingen.