Deceptie 101: Level 0 — voorbereiding is alles
Inleiding
Het vergroten van de pakkans van criminele hackers is essentieel in het verder terugdringen van cybercrime en in het onderkennen van aanvallers in je netwerk. In de serie “Deceptie 101” geeft Chapter8 je verschillende tips om digitale struikeldraadjes te zetten voor een hacker die in je netwerk zit. We gaan ze in de val lokken op basis van misleiding. Doe je mee?
Slimmere en betere detectie bouwen. Het is een vak op zich waar steeds meer organisaties hele afdelingen voor oprichten of gespecialiseerde bedrijven voor inhuren. Uit onderzoek blijkt dat deze vooruitgang een positieve invloed heeft op de dwell time: de gemiddelde tijd die aanvallers ongedetecteerd in een netwerk doorbrengen. De XDR/EDR/MDR-leveranciers gebruiken deze daling overigens vooral als vehikel voor de marketing van hun eigen producten en hoe lang die dwell time is, hangt wel een beetje af van welk onderzoek je er bij pakt en of ze het gemiddelde of de mediaan publiceren: bijvoorbeeld 207 dagen of 40… maar dat er een daling in dwell time is ingezet ten opzichte van de vorige jaren, daar is elk onderzoek het over eens.
Interessanter is dat slechts een derde van de onderzochte organisaties zelf in staat bleek de inbraak te ontdekken en dat de gereduceerde dwell time ook een neveneffect lijkt te hebben op de effectiviteit van de aanvallers: die lijken sneller hun doelen te willen realiseren.
Bij de interpretatie van al deze publicaties moet je wel rekening houden met verschillen tussen ransomwaregroepen en bijvoorbeeld digitale spionnen. De eerste groep zal zijn aanwezigheid altijd kenbaar (moeten) maken om de afpersing in gang te zetten. De tweede groep is erbij gebaat zo lang mogelijk ongedetecteerd te blijven. En over de eerste groep wordt veel, veel meer publiekelijk gerapporteerd. Daarmee rijst eveneens de vraag hoeveel waarde je eigenlijk moet hechten aan de cijfers. Maar ondanks alle bedenkingen en neveneffecten is een dalende trend in dwell time in absolute zin een positief gegeven.
In de serie Deceptie 101 zullen we een aantal tips geven om die dalende trend nóg harder te laten gaan.
Cybercrime en pakkans
Volgens de (economisch-criminologische) rationele-keuzetheorie is criminaliteit vooral een beslismodel — een afweging van kosten en baten. Als de kosten (een hoge boete) hoger zijn dan de mogelijke baten (vijf minuten eerder op je werk zijn), dan kiest een rationeel mens voor het niet-plegen van het delict. Een belangrijke factor van de kosten in dit model is de pakkans. Het vergroten van de pakkans is een klassieke manier om de kosten van criminaliteit te verhogen ten opzichte van de baten. Denk hierbij aan het plaatsten van flitspalen op doorgaande wegen en trajectcontroles, maar ook de uitbundige onderzoeken en publicaties over alle zaken die aan de hand van het kraken van de PGP-telefoondienst Encrochat worden voorgelegd aan de rechter en de defacements van beroemde ondergrondse criminele fora. Dergelijke publicaties stralen een duidelijke boodschap uit: ook als je anonieme fora en versleutelde telefoons gebruikt, weet het recht je te vinden. De (gepercipieerde) pakkans gaat omhoog.
Van oudsher is het zo dat zeker bij cybercrime die pakkans enorm laag is. Dit heeft vele oorzaken: de internationale aard van cybercrime, het feit dat een aanvaller niet in de buurt hoeft te zijn van zijn doel (plaats-tijd-premisse) en de enorme beschikbaarheid van middelen en diensten om cybercrime te (laten) plegen: allemaal belangrijke verschillen met “reguliere” criminaliteit, die de aanpak van cybercrime zo complex maken. De potentiële baten van cybercrime zijn dus vele malen groter dan de potentiële kosten, waardoor deze vorm van criminaliteit een enorm aantrekkelijk verdienmodel is geworden. Cybercrime is drugscriminaliteit enkele jaren geleden zelfs al voorbij gegaan in wereldwijde opbrengst en wordt door de internationale politieorganisaties als grootste criminele dreiging gezien. De balans tussen aanvallers en verdedigers is daarmee nog steeds ver in het voordeel van die eersten, hoewel de verdedigende kant langzaam aan terugvecht.
Het vergroten van de pakkans is dus essentieel, ook in het gevecht tegen cybercrime. De opsporings- en inlichtingendiensten doen wat ze kunnen maar roepen niet voor niets om meer bevoegdheden. Maar je kunt zelf ook het een en ander doen. Wij geven je in deze serie artikelen een aantal tips om zelf de pakkans te vergroten en een hacker, die zich in je netwerk bevindt in de val te laten lopen. En dan op zo’n manier dat jij eerder weet dat hij er is, dan dat hij weet dat hij gezien is.
We gaan digitale struikeldraadjes in je netwerk inbouwen!
Terminologie en randvoorwaarden
Digitale struikeldraadjes kennen een aantal vormen, die we hieronder kort uiteen zullen zetten. Daarnaast heb je wel het een en ander nodig aan logging en monitoring om te kunnen detecteren of en wanneer de digitale struikeldraadjes afgaan.
Welke digitale struikeldraadjes zijn er?
Het bekendste voorbeeld van digitale struikeldraadjes is de honeypot. Dit zijn systemen die speciaal zijn opgezet om interactie met een aanvaller te faciliteren, waarbij het lijkt alsof de honeypot een legititiem onderdeel is van de IT-infrastrucutruur. Een honeypot is er in vele varianten, maar gebaseerd op ontwerp zijn ze te classificeren als pure honeypot, high interaction honeypot en low interaction honeypot. We zullen ze in het honeypot-gedeelte de revue laten passeren, want elke variant kent zijn eigen voordelen, nadelen en optimale inzet. Voor het doel van deze serie publicaties, het vergroten van de pakkans van een aanvaller in je netwerk, zijn een aantal varianten mogelijk interessant.
Gebruik je geen compleet computersysteem als struikeldraad, dan spreek je over een honeytoken. Een honeytoken kan, nee: is speciaal ontworpen om buitgemaakt worden door een aanvaller. Zodra de aanvaller gebruik maakt van de honeytoken, dient er een signaaltje af te gaan bij het securityteam.
Een sterk versimpeld voorbeeld uit de financiële wereld zijn speciale creditcardnummers in datasets van banken. Creditcardbestellingen zijn van alle tijden en plaatsen, dus hoe detecteer je of een (serie) creditcards wordt misbruikt? Een creditcardnummer is een serie getallen, die mathematisch aan bepaalde voorwaarden moet voldoen. Een bank kan een aantal mathematisch correcte creditcardnummers genereren en verstoppen tussen de geldige creditcardnummers van een dataset, met gefingeerde (maar geloofwaardige) persoonsgegevens er aan gekoppeld. Mocht de dataset “gestolen” en daarna misbruikt worden, dan worden ook de gefingeerde creditcardnummers gebruikt om spulleboel te bestellen. Het feit dat de gefingeerde creditcardnummers worden gebruikt, is een teken dat de dataset ontvreemd is.
In dezelfde lijn der gedachten kan een ziekenhuis een gefingeerd patientendossier aanleggen tussen de bestaande. Er is geen enkele legitieme reden dat deze dossiers door personeel of derden worden geraadpleegd. Mocht het dossier wél worden geraadpleegd, dan is dat een teken van kwaadwillende actoren binnen de ziekenhuisomgeving.
Dergelijke technieken noemt men ook canaries, naar het oude gebruik in mijnen om vogeltjes in te zetten als tijdige waarschuwing voor giftige dampen. Stopt het vogeltje met zingen, dan is het een goed moment om de mijnschacht te verlaten (bron: Sentinel species).
Alle relatief simpel te implementeren deceptietechnieken vallen in deze twee categorieën. Er bestaan veel complexere oplossingen, bijvoorbeeld om hele fictieve netwerken te creeëren om aanvallers in te laten verdwalen, maar die zijn voor deze serie out of scope.
Randvoorwaarde: logging, monitoring en alertering
Het bedenken en opzetten van honeypots en honeytokens is leuk en interessant, maar net als in de mijn moet iemand wel kunnen zien wanneer het vogeltje ophoudt met zingen. Maar hier houdt het niet op: deze observatie moet zo snel mogelijl worden doorgegeven aan de rest van het team, zodat de observatie kan worden beoordeeld op impact — de triage.
Logging, monitoring en alertering rondom de struikeldraadjes is dus essentieel. Hoe dit moet worden ingericht, is maatwerk per soort struikeldraad. We zullen onze voorbeelden zo compleet mogelijk vormgeven met veelgebruikte detectiemiddelen. Wij gebruiken in het eerste voorbeeld Microsoft Sentinel voor logging en monitoring en een logic app voor alertering.
Praktijk: verstuur een mail bij het aanmaken van een incident in Sentinel
Waar bijna elke andere SIEM-oplossing een functie heeft om een melding te sturen bij het aggegreren van bepaalde logs tot een incident, is dit in Azure werkelijk notoir onhandig.
Om een alerteringsmail te versturen, moet je namelijk een Logic App bouwen, die triggert op het aanmaken van een Sentinel Incident, bepaalde informatie uit het incident haalt en deze informatie verwerkt in een mail, die bijvoorbeeld via Office365 wordt verstuurd. Die workflow ziet er zo uit:
Het bouwen van de app kan een verwarrende klus zijn vanwege de enorme hoeveelheid aan mogelijkheden die Azure Logic Apps je te bieden heeft. Daarom hebben we een Playbook gemaakt van onze app, die je kunt deployen!
Zorg dat je de juiste rechten hebt om in Microsoft Sentinel en Azure Logic Apps de juiste veranderingen aan te brengen. De rechtenstructuur is behoorlijk granulair, merkten we tijden het schrijven van deze serie.
- Je vindt het playbook hier: https://github.com/chptr8/BlueTeam/tree/main/Sentinel/EmailOnSentinelIncident
- Deploy het playbook middels de knop op bovenstaande website.
- Vul de ontbrekende waarden in en voltooi de deployment:
De Azure User Name wordt gebruikt voor het opbouwen van de connectoren voor Sentinel en Office365;
De Mail Recipient is de ontvanger van de e-mail;
- Zoek de app op in de Logic Apps en ga naar de Logic App Designer-view.
- Verifieer de Connections, maak zo nodig nieuwe connecties aan of hergebruik oude, geldige connecties. Zorg dat alle waarschuwingen weg zijn. Dus van dit:
- naar dit:
Gefeliciteerd! Je hebt nu een Logic App die jou een mailtje kan sturen als er een incident wordt aangemaakt in Microsoft Sentinel. Deze gaan we later inzetten.
Randvoorwaarde: incident handling
Alertering alleen is niet genoeg. Als er een struikeldraad wordt geraakt, is het ook belangrijk het alarm op de correcte manier af te handelen. Nu is daar in generieke zin vrij weinig over te zeggen, behalve je een stappenplan aan te reiken en je te behoeden voor de meest gemaakte fouten. Maar geen zorgen, we’ve got your back. We zullen je meenemen in de triage van de melding. Veel verder kunnen we niet gaan, omdat de vervolgstappen zeer organisatie-specifiek zijn. Als leidraad gebruiken we Bijlage 9 van de Algemene Beveiligingseisen Defensie Orderbedrijven (ABDO 2019). Hoewel ABDO is gericht op het beveiligen van gerubriceerde informatie, bieden deze Beveiligingseisen een prima kapstok op een incident handling plan op te stellen voor elk cybersecurity-incident. Daarenboven is de ABDO een operationele blauwdruk voor een veilig netwerk en als je aan de eisen voor TBB4 voldoet, zul je ook voldoen aan vele andere industriestandaarden. Samen met de NBV-brochure “Een verdedigbaar netwerk, hoe doe je dat?” heb je een top-down en bottom-up raamwerk voor digitale beveiliging. Maar dat is een ander blog.
In algemene zin komt het hier op neer:
- Ken je kroonjuwelen. Weet wat je te beschermen hebt en prioriteer deze naar importantie en risico.
- Ken je aanvalsscenario’s. Denk als een aanvaller en verzin manieren om in je eigen organisatie in te breken.
- Stel procedures vast:
— hoe kan een incident worden geïdentificeerd of gemeld?
— hoe kan de juiste informatie worden verzameld, vastgelegd en wie mag die informatie opvragen?
— Zorg voor een centrale plek om documentatie rondom cybersecurity-incidenten op te slaan. Gebruik hiervoor bij voorkeur een apart (afgeschermd) systeem en gooi de incidenten niet op een grote hoop bij andere tickets, zoals in een algemeen helpdesksysteem als TopDesk.
— Wat communiceren we (intern en extern) en wie communiceert wat
— Leg deze procedures naast het business continuity plan
— Draag de procedures uit naar de medewerkers - Zorg dat melden laagdrempelig kan. Gebruik hiervoor een standaardformulier.
- Maak een incident respons stappenplan — ook wel playbook genoemd voor de belangrijkste aanvalsscenario’s. Gebruik bijlage 9.3 van ABDO als voorbeeld.
Tot zover de theoretische achtergrond. In de volgende aflevering van Deception 101 beginnen we met het aanmaken van een honeyaccount in Microsoft’s Active Directory en zorgen we voor de correcte logging, monitoring en alertering.
