Hoe zet je honeyaccounts gericht in voor detectie

Kennisartikelen
Leestijd:
Detectie
Verdiepen
Het misbruiken van accounts en gebruikersgegevens blijft een van de meest voorkomende manieren waarop aanvallers toegang en privileges uitbreiden binnen een netwerk. Met honeyaccounts kun je dit gedrag vroegtijdig en betrouwbaar detecteren door aanvallers te verleiden tot het misbruiken van zorgvuldig geplaatste nepcredentials. Lees in dit artikel hoe je honeyaccounts effectief inzet tegen verschillende tactieken en technieken van een aanvaller.

Waarvoor zet ik honeyaccounts in?

Het misbruiken van gebruikersgegevens en accounts voor het verkrijgen en verruimen van toegang en privileges is nog altijd een veelgebruikte aanvalstechniek. Je speelt hierop in door middel van honeyaccounts: nepaccounts die je configureert op jouw IAM- of andere gebruikersbeheerssystemen. Je lokt een aanvaller om dit honeyaccount te misbruiken door de inloggegevens hiervoor (de honeycredentials) gericht te plaatsen op jouw systemen en servers. Zodra de aanvaller probeert in te loggen met de verkregen credentials krijg jij een hoog betrouwbaar alert dat je een sterke indicatie geeft dat er een aanvaller actief is in jouw netwerk. 

Een aanvaller maakt gebruik van verschillende tactieken en technieken zodra deze toegang heeft verkregen tot jouw netwerk. In onderstaand document vind je een overzicht van deze tactieken en technieken en hoe je hierop kan inspelen met honeyaccounts. Download deze mapping om honeyaccounts effectief in te zetten voor detectiedoeleinden. 

Lees daarnaast ook ons artikel over gerichte digitale misleiding voor aanvullende handvatten.

Geen bestand beschikbaar

Lokken

Aanvallers komen op verschillende manieren aan de inloginformatie van (honey-)accounts. Lok hen naar jouw honeyaccounts door de credentials hiervoor op meerdere plekken te verspreiden. Jouw eindgebruikerssystemen, servers, code repositories of andere informatiesystemen bieden hier veel mogelijkheden voor. 

Denk aan het:

  • plaatsen van onbeveiligde tekstdocumenten (‘wachtwoord.docx, accounts.txt’ of ‘backup.old’) die een (minder security-bewuste) medewerker zou aanmaken op een eindgebruikerssysteem om wachtwoorden op te slaan (unsecured credentials)
  • plaatsen van nep beheer-scripts die operationele acties uit lijken te voeren op derde systemen of anderzijds honeycredentials bevat. (bijv. Een read-only folder in C:\Scripts\ met een “intranet-shares.vbs” dat een gebruikersnaam en wachtwoord bevat voor een SMB- of FTPs-server dat gekoppeld wordt in het script. Als de gebruiker het script uitvoert zal dit een detectie veroorzaken)
  • opslaan van honeycredentials in de e-mail van een eindgebruiker (e-mail collection).
  • opslaan van honeycredentials in een (bewust kwetsbare) password store (bijv. Keepass Vault: intranet.kdbx met het wachtwoord: “Welkom01”).
  • plaatsen van honeycredentials op het systeem (operating system). Denk aan het plaatsen van wachtwoorden in de local credential store (OS-credential dumping).

Met high-interaction honeypots is het daarnaast mogelijk om honeycredentials te verstoppen in gesimuleerd netwerkverkeer (Network Sniffing, Adversary-in-the-middle). Let er wel op dat dit doorgaans maatwerk is en relatief complexer is om in te richten en te beheren. 

Het succesvolle lokken van een aanvaller naar een honeyaccount is onderhevig aan een aantal factoren. Denk aan:

  • Een passende plaatsing van honeycredentials. Jouw manier om de aanvaller te lokken staat op gespannen voet met de nieuwsgierigheid van eindgebruikers. Als een eindgebruiker immers zelf de credentials ‘vindt’, dan zullen ze snel geneigd zijn om zelf proberen in te loggen en/of hier melding van te maken. Beide situaties zijn onwenselijk omdat deze zorgt voor een hoge mate van vals-positieve alerts, waarmee op-misleiding-gebaseerde detectie zijn waarde verliest. Denk aan een document ‘config-sap.old’ op een eenvoudig vindbare locatie (denk aan de Downloads of het Bureaublad van gebruikers) of een login-url in de e-mail van gebruikers. Door credentials goed te plaatsen zorg je ervoor dat jouw honeyaccounts alleen alerts genereren als er écht iets aan de hand is, wat de betrouwbaarheid ten goede komt. 

    Neem het gebruikersgedrag daarom mee bij de plaatsing van de credentials. Overweeg credentials te plaatsen in omgevingen waar minder gebruikersactiviteit is verwacht (zoals op servers, edge-devices of soortgelijke systemen). Wil je ze plaatsen in eindgebruikerssystemen? Houd ze dan weg bij diensten en mappen die eindgebruikers minder snel zullen gebruiken en stel beheerders op de hoogte van waar deze staan zodat hier niet per-ongeluk mee geïnteracteerd wordt. 
     
  • Het beheren en actualiseren van de credentials. Om de pakkans te verhogen zal je jouw honeycredentials al snel op meerdere plekken willen verstoppen. Tegelijkertijd wil je weten waar je deze credentials hebt verstopt, zodat je passende opvolging kan geven na een alert. Tooling en processen helpen jou hierbij. Denk aan tooling waarmee je overzicht houdt welke credentials je waar hebt geplaatst. En overweeg om specifieke honeycredentials te plaatsen tijdens het inspoelen van nieuwe systemen of als onderdeel van andere beheersactiviteiten.
     
  • De aantrekkelijkheid van honeyaccounts: Jouw honeyaccounts zijn met name interessant als deze de aanvaller (in potentie) aanvullende toegang geven. Beheerdersaccounts, of (test-) accounts op specifieke toepassingen (zoals externe toepassingen of beheersdashboards), zijn daarvoor bij uitstek geschikt. Aanvallers zijn vaak geïnteresseerd in files-shares of omgevingen die bedrijfsdata bevatten. Denk daarbij aan accounts met namen als (‘adm-service01, ‘beheer’, of ‘admin’).

Detectie

Zodra een aanvaller probeert in te loggen op het honeyaccount, dan weet jij dat er iets aan de hand is. Typisch zal dit zijn tijdens pogingen tot privilege escalation (Valid accounts), lateral movement, of bij het verder verkennen van jouw netwerken en diensten. Denk voor het cloud service dashboard of software deployment tools, die vaak toegankelijk zijn voor IT-beheerders. 

De effectieve inzet van honeyaccounts

We adviseren je om minimaal één honeyaccount te configureren in jouw gebruikersbeheerssysteem-oplossing. Het verzamelen en misbruiken van gestolen inloggegevens is in praktijk nog altijd een veelgebruikte aanvalstechniek. Honeyaccounts bieden jou de mogelijkheid om hierop in te spelen. Zorg ervoor dat dit honeyaccount aantrekkelijk is voor de aanvaller en verhoogde rechten lijkt te hebben.

Onderzoek of jouw gebruikersbeheerssysteem de mogelijkheid heeft om honeyaccounts te configureren (inclusief de bijbehorende alerting). Steeds meer producten bieden hier de mogelijkheid toe. Dit is verreweg de meest effectieve en veilige manier om honeyaccounts in te zetten. 

Biedt dit voor jou geen oplossing en moet je zelf aan de slag om een honeyaccount in te richten? Overweeg dan het risico dat een aanvaller dit account daadwerkelijk zal proberen te misbruiken om je systemen verder aan te vallen. Zorg ervoor dat het account geen (verhoogde) rechten heeft om misbruik te voorkomen.

Zorg voor de geautomatiseerde distributie van honeycredentials om aanvallers naar het honeyaccount te lokken. Denk hierbij aan het:

  • inloggen op eindgebruikerssystemen met het honeyaccount tijdens initiële configuratie. 
  • verstoppen van credentials in een mappenstructuur. Reguliere gebruikers komen in dit geval niet in aanraking met de credentials, maar ze worden wel ontdekt door tools die de aanvaller heeft.
  • vermijden van honeycredentials die in praktijk misbruikt kunnen worden door jouw eindgebruikers. Plaats bijvoorbeeld geen logingegevens op hun bureaublad of in hun browser-bookmarks. Vermoed je dat een gebruiker (of hun account) al gecompromitteerd is? In dat geval kan het de moeite waard zijn om deze credentials juist wel in het zicht te verstoppen.
  • beheren van deze credentials. Actualiseer op het moment dat dit nodig is. 

In samenwerking met

Architecten, adviseurs, specialisten en onderzoekers op het gebied van misleiding en misleiding-gebaseerde detectie van DeepBlue Security, DTACT, Fortinet, Gartner, GriffinGuard, PwC NL, SecurityHive, Thinkst Canary en TU Delft.

Formulier
Heeft deze pagina je geholpen?