Technische beveiliging tegen een phishing aanval

Bij StackSecure phishen we wat af. Niet om snel rijk te worden ten koste van anderen, maar om organisaties inzage te geven in de weerbaarheid van hun medewerkers en medewerkers bewust te maken van en te leren over phishing berichten. Phishing bereikt die medewerkers hoofdzakelijk via e-mail, nog altijd een veelgebruikt zakelijk medium. Zo’n phishing simulatie, om te oefenen, moet de medewerkers natuurlijk wel bereiken, anders test je de technische beveiliging. Ook nuttig, maar niet het doel. 

Nu hoor ik tegenstanders van phishing simulaties al denken; ja maar dat is valsspelen en niet realistisch! Helemaal waar. In de praktijk zullen doorgaans niet alle medewerkers dezelfde e-mail ontvangen. En veel pogingen worden geblokkeerd door de technische maatregelen. Echter komt er een dag dat een kwaadaardig mailtje de inbox van die ene medewerker gaat bereiken. Dan is het een voordeel dat die medewerker enige ervaring heeft phishing e-mails. 

Maar goed, daar wilde ik het verder niet over hebben. We willen even stilstaan bij de beveiliging die we in de praktijk tegenkomen (die we dus moeten omzeilen) en wat je als organisatie dus kunt doen om je medewerkers technisch tegen phishing (en andere frauduleuze e-mail) te beschermen.

Traditioneel gezien is het spamfilter de eerste barrière die kwaadaardige e-mail kan stoppen. We schreven er eerder al een blog over. Een spamfilter kan aanwezig zijn in de e-mailoplossing, maar kan ook los in de e-mailstroom worden geplaatst. Het doel is hetzelfde, kwaadaardige e-mail herkennen en filteren, eventueel met een seintje naar de beoogde ontvanger om te controleren of de mail niet toch legitiem is. Meerdere actieve filters ‘achter elkaar’ kan, maar is niet in alle gevallen het beste idee, omdat het al vrij snel vrij complex kan worden. 

Landt de e-mail toch in de inbox? Dan zijn er ook spamfilters die binnengekomen e-mail kunnen analyseren. Dit soort oplossingen is ook in staat om de onderlinge mailstroom goed te controleren. 

Wanneer de mail wordt geopend door de gebruiker, kan web- of DNS filtering uitkomst kunnen bieden. Phishing e-mails bevatten soms afbeeldingen om bij te dragen aan de geloofwaardigheid en/of trackers. Deze ‘resources’ worden vaak van server van de aanvallers gedownload. Wanneer de gebruikte URL niet door het DNS of webfilter heen komt, bereiken  (tracking)signalen de aanvallers niet en krijgt de gebruiker mogelijk argwaan doordat afbeeldingen ‘niet werken’.

Ook de link die leidt naar een malafide website, bijvoorbeeld waar je gevraagd wordt inloggegevens in te vullen, wordt standaard na een klik geopend in je standaard webbrowser. Een web- filter kan hier een stokje voor steken. Voor dat het echter zover is, kan ‘tijd-van-klikken bescherming' de klik nog onderscheppen en realtime analyseren. 

In zo’n geval wordt je klik omgeleid naar een systeem van de leverancier. Die controleert de doelbestemming en stuurt je enkel door wanneer deze wordt vertrouwd. Het grote voordeel ten opzichte van het filteren van de link bij ontvangst, is dat er tegen de tijd van het klikken wellicht al een melding van de verdachte site is gemaakt. Een nadeel kan zijn dat het 'herschrijven' van links voor dit doel andere maatregelen, zoals DKIM, kunnen breken doordat de originele signature niet meer geldig is.

Terug naar de webfilters, die je browse activiteiten in de gaten houden. Er zijn verschillende plaatsen en smaken van webfiltering die (naast elkaar) actief kunnen zijn. Traditioneel gezien vindt filtering van uitgaand verkeer, zoals browsen op het internet, plaats op een centrale firewall in netwerk van een organisatie. Alle uitgaande verbindingen worden gecontroleerd. Als de bestemming verdacht wordt geacht, wordt de connectie verhinderd. Een gebruiker krijgt mogelijk een waarschuwingspagina, wordt omgeleid of ziet gewoon een foutmelding.

Een centrale (en vaak kostbare) centrale firewall helpt echter niet wanneer medewerkers buiten kantoor aan het werk zijn. Om die reden wordt vaak gebruik gemaakt van Endpoint Detection en Response (EDR) oplossingen (of een variant daarop). Hierbij draait een programma (vaak een daemon of agent genoemd) op de laptop van de medewerker. Deze agent controleert onder andere het uitgaande netwerkverkeer en kan dit op verschillende karakteristieken filteren, waaronder de bestemming.

Tot slot speelt ook de browser een rol. Zo zijn alle grote browsers aangesloten bij de dienst Google Safe Browsing. Open je een website, dan analyseert de browser deze. Als er een vermoeden is van phishing, dan krijgt de gebruiker een rood waarschuwingsscherm te zien. Tevens wordt de bestemming doorgegeven aan een centrale dienst, die andere browsers vertelt de website niet te vertrouwen. Dit systeem werkt best aardig, vaak ook zo goed dat onze phishing simulaties er hinder van ondervinden :)

Mogelijk maakt je organisatie gebruik van detectie en response om geautomatiseerd e-mails uit mailboxen op te sporen en te verwijderen of regels in de firewall toe te voegen wanneer een dreiging wordt gedetecteerd. Grote kans echter, dat dit (nog) niet gebeurt. Een melding in een SIEM kan een goede trigger zijn om handmatig actie te ondernemen. Hier moeten wel goede procedures en afspraken over worden gemaakt met de IT beheerders.

Is dat niet aanwezig, dan is je organisatie mogelijk sterk afhankelijk van oplettende medewerkers die melding maken van verdachte zaken. Het (technisch) faciliteren van een eenvoudig te bedienen oplossing om snel melding te kunnen maken kan dan van grote meerwaarde zijn.

Voorkomen is beter dan genezen, maar er komt een moment dat alle maatregelen falen en de medewerker niet scherp genoeg is. Inloggegevens kunnen daarnaast ook op andere manieren lekken. Het is goed om na te denken wat de impact van gelekte credentials zijn. Allereerst is het prettig wanneer medewerkers geen inloggegevens (wachtwoorden) hergebruiken. Ook MFA is in veel gevallen een no-brainer, maar lang niet elke vorm is onfeilbaar en vele veelgebruikte methoden zijn ook vatbaar voor (geavanceerde) phishing aanvallen. Het goed toepassen van least privilege is tevens essentieel om de impact van een geslaagde aanval te verkleinen. Zo zijn er nog de nodige andere potentiële maatregelen impactbeperkende of herstellende maatregelen te benoemen en nemen. 

We hebben een aantal (technische) verdedigingsmechanismen opgesomd tegen phishing aanvallen. Daarnaast kan de kans op misleiding met behulp van beleid, afspraken en een hoog niveau van bewustwording verder worden verkleind. Met dat alles zijn natuurlijk ook (soms hoge) kosten gemoeid. Zoals met alles in informatiebeveiliging / cybersecurity, moeten de kosten in verhouding staan tot het risico dat wordt gelopen. En hoewel alle organisaties vroeg of laat te maken krijgen met spam en phishing pogingen, zijn sommigen interessanter dan anderen en is daar ook een hogere mate van ‘spearphishing’ te verwachten.