Deceptie 101: Level 1 — Honeytoken-account in Active Directory

Photo by Mario Gogh on Unsplash

Inleiding

Active Direcory. Bijna elke organisatie die met Microsoft-producten werkt, gebruikt Active Directory voor het managen van rechten van gebruikers, groepen, computers… eigenlijk zowat de hele digitale organisatie. Mede daarom is Active Directory een absoluut kroonjuweel in elke organisatie die het gebruikt. De hoogste rechten binnen Active Directory zijn toegekend aan de groep Domain Administrators, maar binnen Active Directory kunnen beheerders- en gebruikersrechten op vele, vele manieren worden gedelegeerd en toegekend. Active Directory kan hiermee een onoverzichtelijk monster worden. Een feit waar aanvallers maar al te graag gebruik van maken. En daar maken wij weer gebruik van.

Onze voorbeeldorganisatie

Voor de voorbeelden in deze serie artikelen maken we gebruik van een kleine, fictieve organisatie: Chapter7. Chapter7 specialiseert zich in innovatieve oplossingen voor de zorgsector en is een typisch MKB-bedrijfje — maar dan met een systeembeheerder die erg geinteresseerd is in logging en monitoring. Daarom heeft Chapter7 wel de beschikking over de pay as you go Sentinel Tier, wat ze nog geen 50 euro per maand kost vanwege de kleine infrastructuur.

Caveat: de voorbeelden in deze serie blogs zijn ontwikkeld in een zeer kleine Active Directory, waardoor de aanvalsscenario’s overdreven kunnen lijken. Dat beseffen we! De gedachte achter de voorbeelden kan — omdat wij het zo klein en simpel houden — wel makkelijk geëxtrapoleerd worden naar veel grotere omgevingen.

Het aanvalsscenario

Struikeldraadjes in het netwerk zijn bedoeld om je te alerteren op een aanvaller die al enige toegang heeft tot je digitale infrastructuur. Chapter8 werkt onder het principe assume breach: ga er van uit dat een aanvaller zich ooit een keer toegang tot je netwerk verschaft. Hetzij via een access broker, hetzij via een nieuwe zeroday, hetzij via configuratiefouten — de mogelijkheden zijn helaas eindeloos. Daar zijn de aanvalsscenario’s in deze serie ook op geschreven.

Een aanvaller met enige toegang tot de infrastructuur van Chapter7 zal de Active Directory in kaart willen brengen en op zoek gaan naar accounts die gemakkelijk te misbruiken zijn. Bijvoorbeeld om het netwerk verder te verkennen, backup toegang te realiseren of zichzelf te verbergen. Want elke toegang telt en met het verstrijken van de tijd kunnen ook “tijdelijke” accounts vele rechten gekregen hebben voor toegang tot gegevens. Nu zijn er minimaal drie voorwaarden voordat een aanvaller Active Directory kan bevragen:

1. De aanvaller beschikt over een geldig Active-Directory-account; OF
2. De aanvaller beschikt over een domain-joined computer (die ene demo-PC in de lobby bijvoorbeeld…); of
3. LDAP is beschikbaar en vereist geen nadere authenticatie.

Het opzetten van het honeytoken

In bovenstaand overzicht zie je een deel van de (zeer kleine) Active Directory van Chapter7, die bestaat uit vijf gebruikers en twee administrator-accounts, een domain controller en een paar werkstations. Dit is voor de demo-doeleinden: bij Chapter8 hebben we Active Directories gezien van meer dan 50.000 entiteiten.

Het is overigens een Best Practice om Administrator-accounts niet zo gemakkelijk herkenbaar te maken. Ja, een slimme aanvaller kan ze sowieso onderscheiden aan de hand van de SID-structuur en er is Red Team programmatuur beschikbaar om dat allemaal in kaart te brengen. Maar zoals een bekende van me ooit zei: “Klein vee maakt ook mest” — alle beetjes helpen.

De crux van een honeytoken is dat deze opgaat in de massa en er uitziet als een regulier deel van de infrastructuur. Nu is dat met 50.000 accounts iets gemakkelijker dan met 7 accounts, maar volg ons even op deze gedachtentrein. Wat opvalt is dat het Description-veld in deze Active Directory leeg is. Dat gaan we veranderen, want dat is precies waar we ons honeytoken gaan plaatsen. Stap 1 is dus het gebruik van het Description-veld:

Het is geloofwaardig dat een klein bedrijf als Chapter7 gebruik maakt van afstudeerders of stagiairs. En het is ook gebruikelijk dat deze hun eigen account krijgen voor de duur dat ze bij Chapter7 werken. In de Active Directory maken we een gebruiker aan die lijkt op het standaard account voor een tijdelijk medewerker. Met het wachtwoord in het Description-veld, want dat is lekker makkelijk om te beheren voor Alice en Steward en makkelijk te onthouden voor de tijdelijke medewerkers!

Allereerst maken we een nieuwe gebruiker aan en vullen we een aantal waardes in.

Daarna geven we dit account een STERK, RANDOM wachtwoord. 0qaNJpEn000wzvYW5eC is een prima kandidaat. We zorgen dat dit wachtwoord niet verloopt en dat de gebruiker het wachtwoord niet kan veranderen. Let op: dit is volledig in lijn met het lokaas: een standaard wachtwoord voor elke stagiair.

Tenslotte vullen we het Description-veld met ons honeytoken. pw = Temp2023! lijkt super valide - om eerlijk te zijn zien de meeste wachtwoorden die wij aantreffen er ongeveer zo uit, maar daarover in een ander blog meer - en is op te vragen voor eenieder die weet waar hij moet kijken.

Het gebruikersoverzicht in Active Directory ziet er nu zo uit:

Het resultaat: we hebben een account aangemaakt met een sterk wachtwoord, wat nooit verloopt, en met misleidende informatie in het Description-veld.

Tijd voor een testje: log in op één van de gemonitorde werkstations als gebruiker tmp en voor de compleetheid als CHPTR7\tmp.

Dit ziet er goed uit. Nu door naar logging, monitoring en alertering!

Het opzetten van logging, monitoring en alertering

Binnen Microsoft Sentinel is het triviaal om logs van de gefaalde aanmeldpoging op te zoeken. Het EventID van een failed logon is 4625 - en we weten dat de poging altijd faalt omdat het echte wachtwoord van het tmp-account niet gelijk is aan wat in het Description-veld staat. Dit EventID is een SecurityEvent en zal altijd de string \\tmp bevatten. De handmatige query is dan ook als volgt:

Let op: Sentinel geeft standaard UTC terug als tijdzone. Houd hier rekening mee bij de interpretatie van de melding! Dit is onderaan het scherm aan te passen.

Kijk eens aan. We hebben een melding van gefaalde inlogpogingen! Klopt, want dit was die handmatige test. Het is mogelijk deze query op te slaan en handmatig uit te voeren, maar het is meer dan wenselijk om eens in de zoveel tijd deze query te laten lopen en daar een alarm aan te hangen. Dit kan in Sentinel Analytics.

Een nieuwe analyseregel aanmaken gaat als volgt: klik + Create aan de top van het overzicht en kies voor Scheduled query rule.

Vul de generieke eigenschappen van de regel in. Voor wat extra juice kun je een MITRE ATT&CK-categorie er aan hangen.

In het volgende scherm kunnen we wat meer details toevoegen aan het eventuele alarm. Het is bijvoorbeeld handig om het IP-adres van waarvan de inlogpoging is gedaan, meteen weer te geven.

Een dergelijke poging wil je snel onderkennen. Voor dit voorbeeld zetten wij de scheduling op eens per uur.

De enige actie die je zo snel mogelijk dient te nemen op dit alarm, is dat je een melding wil ontvangen. Dat kan in Automated Respons. In het inleidend artikel in deze serie hebben we een Logic App aangemaakt op basis van ons Playbook, die een mail verstuurt als een Sentinel incident aangemaakt wordt. Die activeren we nu:

Uiteindelijk ziet het geheel er zo uit:

Het testen van de opzet

We hebben nu een complete honeytoken opgezet, inclusief logging, monitoring en alertering:

• account aangemaakt in het AD
• herhalende query rule in sentinel,
• gekoppeld aan de alerterings-app.

Nu forceren we een incident: log nogmaals in op het werkstation met het tmp-account. Als alles werkt, ontvang je automatisch een mail met de incident-informatie.

Triage

De gehele setup werkt. Wat nu als er een daadwerkelijke melding binnenkomt?

Ten eerste: geen paniek. Als het goed is heb je in het eerste deel van deze serie gelezen dat voorbereiding het halve werk is. Laten we stellen dat je de eerste paar stappen geregeld hebt: de mail komt binnen op een centraal punt en je afdeling heeft het mandaat om gegevens rondom het incident te verzamelen. We gebruiken bijlage 9.3 van het ABDO als referentie.

Stap 1: identificatie

Deze stap bestaat uit vier kleinere stappen: verzamel de logs, rapporteer, stel onderzoeksteam samen en bepaal impact.

Vanuit de initiële mail hebben we een directe link naar het incident in Sentinel. Hier kunnen we de audit logs analyseren, die we vinden onder Evidence.

Als we doorklikken, komen we bij de drie logregels die het incident hebben getriggerd.

Daarmee zijn de logregels verzameld. Rapporteren naar BIV/MIVD is niet van toepassing, dus die stap slaan we over. Bij het samenstellen van het onderzoeksteam houden we minimaal het vier-ogen-principe aan. Dus zorg voor een buddy waarmee je samen het mogelijke incident doorloopt en verdeel de taken: wie zorgt voor de volledigheid van het incident report? Wie doet in eerste instantie het technisch onderzoek?

Stap 2: incident vastlegging

Een centraal register van cybersecurity-incidenten is essentieel, net als een standaard manier om incidenten vast te leggen. We weten nog niet of dit een false positive of een true positive is en hoe meer incidenten we vastleggen, hoe betrouwbaarder onze detectie uiteindelijk kan worden door analyse van deze incidenten. De ABDO heeft een aardig template voor de melding in bijlage 9.2, wat we iets werkbaarder kunnen maken voor niet-defensieorderbedrijven:

Stap 3: eerste respons

Nu de eerste administratie is afgerond, kunnen we naar de logs achter het incident zelf gaan kijken om te bepalen of we hier met een echt incident of met een false positive te maken hebben. Het vastgelegde event ID heeft een aantal eigenschappen die wat meer context geven aan de melding. Als allereerste echter bepalen we de onderzoeksvragen. Denk hierbij aan het 5W+H-model: wie, wat, waar, waarom, wanneer en hoe.

• Wanneer is de log aangemaakt? TimeGenerated geeft je deze waarde. Let op: UTC, dus corrigeren voor je eigen tijdzone.

• Op welke (virtuele) machine is getracht in te loggen? Computer geeft je deze waarde. Dit is de potentiële stepping stone die de aanvaller heeft geprobeerd te gebruiken.

• Hoe is de poging tot stand gekomen? Hier zijn twee velden interessant: LogonType en LogonProcessName.

De waarde 3 als LogonType spreekt voor zich: de poging heeft zich voorgedaan over het netwerk. De LogonProcessName is meer cryptisch, maar afgaande op onderstaand overzicht uit deze presentatie van CyberSafe, representeert de waarde NtlmSsp een aanduiding is voor gebruik van het NTMLv2-protocol. Dit zegt niet veel over de daadwerkelijke methode - het kan duiden op een handmatige poging of een tooltje - maar in ieder geval is het niet een van de andere methodes.

• anaf waar is de poging tot stand gekomen? Dit vind je in de waarde IpAdress:

Hoe summier dit ook lijkt, voor deze fase is het genoeg. Door de opzet van het honeytoken is het mogelijk dat het hier om een true positive gaat, maar zeker weten doen we het niet — er is sprake van een incident, waarbij wie, wat waar, hoe en waarom nog wel nader moeten worden onderzocht. Het belangrijkste “haakje” voor nader onderzoek in dit incident is natuurlijk het IP-adres 10.6.0.5 vanwaar de poging tot inloggen is gedaan.

Nu de eerste response is gedaan, is het tijd voor een korte pas op de plaats. Welke expertise is nodig om dit incident verder te onderzoeken? Kunnen we de benodigde informatie rondom dat IP-adres veiligstellen? Moet het team worden uitgebreid? Waarschijnlijk niet, naar aanleiding van deze melding, maar het is goed om je deze vragen te stellen. Door naar de volgende stap.

Stap 4: communicatie

In deze fase van incident handling is het de vraag of en wat er op dit moment gecommuniceerd moet worden naar eventuele stakeholders. Onze inschatting: nee, eerst is nader onderzoek nodig. Daarvoor is het wel handig de SOC lead en zeker de CISO te informeren, omdat het onderzoek resources vergt. Misschien hebben we wel andere (externe) systeembeheerders nodig.

Stap 5, 6, 7: containment, response strategie, classificatie

Ook over deze stappen kunnen we — in dit geval — kort zijn. Van containment is nog geen sprake. De passende response heeft (nog) geen lastige juridische of politieke componenten en de classificatie kan volgens bijlage 9.4 van het ABDO: Cat 5: poging(en) tot toegang.

Stap 8,9: incident onderzoek, data collection, forensische analyse

Eindelijk! Door met het onderzoek :) we kunnen nog niets attribueren, dus we gaan gegevens verzamelen met betrekking tot het gevonden IP-adres. Omdat dit een blogserie is over deceptie en niet over incident handling, hierbij een paar pointers naar de volgende onderzoeksmogelijkheden rondom IP-adres 10.6.0.5:

• Is het een VDI, een BYOD of een gewone werkplek?
• Wat is (of was) de fysieke locatie van de computer?
• Wat is de functie van de computer?
• Wie was er ingelogd op moment van het alarm?
• Zijn er meer (foutieve) inlogpogingen vanaf die computer?
• Zijn er eerdere alerts geweest rondom deze computer? Denk aan netwerkverbindingen, proxylogs, DNS, inlogpogingen op rare tijden?
• Als er een EDR draait als Defender, wat heeft die voor verdachte events?
• Kan je een forensic package laten maken door b.v. Microsoft Defender for Endpoint?

Kortom: trek je detective-pak aan en ga op onderzoek uit!

Photo by Ali Hajian on Unsplash

Afsluitend

In deze editie van Deceptie 101 hebben we een vrij simpele maar effectieve honeytoken ingericht, de logging en monitoring ingeregeld en wat vragen opgeschreven voor het afhandelen van een melding. We hopen dat dit blog je inspiratie heeft gegeven om hier zelf mee aan de slag te gaan. Heb je hulp nodig of wil je ander offensief of defensief advies? Je vindt ons op https://chapter8.com en achter questions@chapter8.com!

In de volgende editie van Deceptie 101 gaan we een paar broodkruimeltjes achterlaten, zodat onze arme aanvallers de weg terug naar huis kunnen vinden.

Chapter8?

Chapter8 is in 2020 opgericht door drie ex-medewerkers van de Nederlandse Algemene en Militaire Inlichtingen- en Veiligheidsdiensten.

Onze jarenlange ervaring in gerubriceerde omgevingen heeft ons geleerd dat een aanvaller uiteindelijk een keer uw netwerk zal weten binnen te dringen. Dat zal het moment zijn dat uw weerbaarheid echt op de proef gesteld wordt. Onze Purple Team aanpak is dan ook veel meer dan een technische exercitie: het is een hands-on digitale crisisoefening voor uw organisatie.