Zero trust: wat het betekent buiten de marketingfolder

Als je de afgelopen jaren leveranciers van beveiligingssoftware hebt gesproken, is de kans groot dat zero trust voorbij is gekomen. Soms als productfeature, soms als architectuurvisie, soms als antwoord op een vraag die je niet had gesteld.

Dat heeft de term geen goed gedaan. Want het onderliggende idee is helder en praktisch nuttig. Het is alleen begraven geraakt onder een laag marketing.

Wat zero trust eigenlijk betekent

Het traditionele beveiligingsmodel gaat uit van een kasteel. Alles binnen het bedrijfsnetwerk is vertrouwd, alles erbuiten niet. Wie eenmaal binnen is, kan vrij bewegen. Dat model dateert uit een tijd dat medewerkers op kantoor werkten, data op lokale servers stond en applicaties niet in de cloud draaiden.

Die situatie bestaat lang niet overal meer. Medewerkers werken thuis, onderweg en op locatie bij klanten. Applicaties draaien in public clouds zoals AWS en Azure of in een datacenter. Leveranciers hebben toegang tot interne systemen. De grens van het kasteel is daarmee vervaagd.

Zero trust stelt daar een ander uitgangspunt tegenover: vertrouw niets en niemand standaard, ongeacht de locatie. Niet de medewerker die al tien jaar in dienst is, niet het apparaat dat al jaren op het netwerk zit, niet de applicatie die van binnen het netwerk verbinding maakt. Elke toegangspoging wordt geverifieerd, elke keer opnieuw.

Dat klinkt streng. In de praktijk merkt een medewerker er weinig van als het goed is ingericht.

Drie principes die het concreet maken

• Verifieer altijd (always verify)
  Toegang wordt pas verleend nadat identiteit, apparaat en context zijn geverifieerd. Wie is dit, welk apparaat gebruikt hij, vanwaar maakt hij verbinding en welke rechten zijn daarvoor nodig? Multifactorauthenticatie is een basisonderdeel van dit principe. Het gaat ook verder: een apparaat zonder actuele updates of zonder beveiligingssoftware kan worden geweigerd, zelfs als de gebruikersidentiteit klopt.
• Verleen minimale toegang (least privilege)
  Medewerkers krijgen alleen toegang tot wat ze nodig hebben voor hun werk, niet meer. Een medewerker van de financiële afdeling heeft geen toegang nodig tot de productiesystemen. Een leverancier die een specifieke applicatie onderhoudt, heeft geen toegang nodig tot de rest van het netwerk. Dit principe heet least privilege en is een van de meest effectieve maatregelen om schade te beperken als een account wordt gecompromitteerd.
• Ga uit van inbreuk (assume breach)
  Dit is het meest ongemakkelijke principe, maar ook het meest eerlijke. Ontwerp systemen en processen alsof een aanvaller al binnen is. Wat kan hij bereiken? Hoe ver kan hij bewegen? Hoe snel wordt hij opgemerkt? Wie dit serieus neemt, investeert in segmentatie, monitoring en detectie, niet alleen in het voorkomen van toegang.

Waarom dit nu actueel is

Zero trust is geen nieuw concept. Het werd al in 2010 geïntroduceerd door analist John Kindervag bij Forrester Research. Wat veranderd is, is de context.

De reeks kwetsbaarheden die de afgelopen maanden publiek is gemaakt, laat een patroon zien: aanvallers die via een beperkt account volledige systeemrechten weten te verkrijgen. Copy Fail, Dirty Frag, MiniPlasma, CIFSwitch. Allemaal variaties op hetzelfde thema: een gebruiker met beperkte rechten die door een fout in het systeem uitgroeit tot beheerder met volledige controle.

Zero trust verkleint de schade van precies dit type aanval. Als toegang consequent wordt beperkt tot wat nodig is, en als systemen zijn gesegmenteerd zodat een gecompromitteerd account niet direct toegang geeft tot alles, dan is de impact van zo’n kwetsbaarheid aanzienlijk kleiner. De aanvaller komt wel binnen, maar kan een stuk minder.

Wat het in de praktijk vraagt

Zero trust implementeren is geen project met een einddatum. Het is een richting die je inslaat en stap voor stap uitwerkt. De meeste organisaties beginnen met de meest impactvolle onderdelen.

Identiteit en toegangsbeheer

Wie heeft toegang tot wat, en is dat nog actueel? Voormalige medewerkers, oud-leveranciers, accounts met te brede rechten: dit is waar de meeste organisaties de meeste winst boeken met de minste inspanning.

• Multifactorauthenticatie
  Een gestolen wachtwoord is niet genoeg voor toegang als MFA is ingeschakeld. Dit is een van de meest effectieve en relatief goedkope maatregelen die een organisatie kan nemen.
• Netwerksegmentatie
  Verdeel het netwerk in zones. Een aanvaller die toegang krijgt tot een zone, kan niet automatisch door naar de rest. Dit beperkt de schade bij een incident aanzienlijk. In sommige situaties kan het zelfs waardevol zijn om microsegmentatie te doen waarbij alle devices van elkaar geïsoleerd zijn.
• Monitoring en detectie
  Als je uitgaat van inbreuk, moet je ook kunnen zien wanneer er iets misgaat. Logging, alerting en actieve monitoring zijn geen luxe maar een basisonderdeel van een volwassen beveiligingsaanpak.

Wat zero trust niet is

Zero trust is geen product dat je koopt. Geen leverancier die zegt dat zijn platform zero trust is, verkoopt je daarmee een complete aanpak. Hij verkoopt je een onderdeel dat bij een zero trust strategie past, of niet.

Het is ook geen binaire keuze. Je bent nooit klaar met zero trust, net zoals je nooit klaar bent met risicomanagement. Het is een continu proces van verbeteren, controleren en aanpassen aan een veranderende omgeving.

Wat het wel is: een nuttig kader om beveiligingsbeslissingen aan te toetsen. Verleent deze maatregel minimale toegang? Verifiëren we identiteit en context? Zijn we voorbereid op inbreuk? Wie die drie vragen consequent stelt, maakt betere keuzes dan wie dat niet doet.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties een praktische invulling te geven aan zero trust principes, zonder onnodige complexiteit en zonder de belofte dat één oplossing alle problemen oplost. We brengen in kaart waar de grootste risico’s zitten, welke stappen het meest impact hebben en hoe dat aansluit op de bestaande omgeving en het beschikbare budget.

Wil je weten waar jouw organisatie staat en waar de meeste winst te behalen valt? Neem contact op voor een vrijblijvend gesprek.

Wat een cyberaanval echt kost: verder dan de directe schade

Als organisaties nadenken over het risico van een cyberaanval, gaat de gedachte al snel naar de directe schade: verloren data, versleutelde systemen, herstelkosten. Begrijpelijk, want dat zijn de meest tastbare gevolgen. Maar wie de totale impact wil begrijpen, kijkt verder dan die eerste laag.

De werkelijke kosten van een cyberaanval bestaan uit meerdere onderdelen, en de indirecte schade is in de praktijk vaak groter dan de directe. Dat maakt het ook een bestuurlijk vraagstuk, niet alleen een IT-probleem.

De directe kosten: wat je meteen ziet

De meest zichtbare kosten zijn de kosten die direct voortvloeien uit het incident zelf. Die omvatten onder andere:

• Herstelkosten voor systemen en data
  Het terugzetten van systemen, het herstellen van data en het opnieuw inrichten van omgevingen kost tijd en geld. Bij een ransomware-aanval komen daar mogelijk de kosten van professionele decryptiediensten bij, als back-ups niet voldoende blijken.
• Forensisch onderzoek
  Na een incident moet worden onderzocht hoe de aanvaller binnen is gekomen, hoe lang hij toegang heeft gehad en welke systemen en data zijn geraakt. Dat vereist gespecialiseerde expertise en neemt tijd in beslag, soms weken.
• Juridische bijstand en compliance
  Bij een datalek moeten getroffen personen en in veel gevallen de Autoriteit Persoonsgegevens worden geïnformeerd, binnen 72 uur na ontdekking. Dat proces vereist juridische begeleiding. Als de melding te laat of onvolledig is, kunnen daar sancties op volgen.
• Crisismanagement en communicatie
  Hoe communiceer je naar klanten, leveranciers en de pers? Organisaties die dit niet van tevoren hebben geregeld, huren in een crisis externe communicatiespecialisten in. Dat zijn geen kleine rekeningen.

De indirecte kosten: wat je pas later ziet

De indirecte kosten zijn moeilijker te kwantificeren, maar in de praktijk minstens zo groot. Ze manifesteren zich niet altijd direct na het incident, maar in de weken en maanden daarna.

• Omzetverlies door stilstand
  Systemen die niet beschikbaar zijn, betekenen processen die stilliggen. Gemiddeld zijn organisaties na een ransomware-aanval twee tot vier weken beperkt operationeel. De kosten lopen door; de omzet valt weg.
• Reputatieschade
  Klanten die afhaken, contracten die niet worden verlengd, partners die twijfelen. Reputatieschade is de moeilijkst te kwantificeren post, maar onderzoek laat consistent zien dat het de grootste langetermijnimpact heeft.
• Verhoogde verzekeringspremies
  Na een incident stijgen cyberverzekeringspremies aanzienlijk, of wordt een organisatie in het geheel moeilijker verzekerbaar. Dat effect houdt meerdere jaren aan.
• Productiviteitsverlies
  Medewerkers die niet kunnen werken, IT-personeel dat weken in crisisstand zit, management dat wordt opgeslokt door het incident. De uren zijn zelden zichtbaar in de schadeberekening, maar de kosten zijn reëel.
• Aansprakelijkheid
  Als klantdata is gelekt, kunnen getroffen partijen schadeclaims indienen. Onder NIS2 zijn bestuurders bovendien persoonlijk verantwoordelijk voor het beveiligingsbeleid van de organisatie. Niet-nakoming kan leiden tot persoonlijke aansprakelijkheid.
• Concurrentiepositie
  Terwijl jouw organisatie herstelt, staat de concurrentie niet stil. Klanten die tijdelijk naar een concurrent overstappen, keren niet altijd terug. Dat effect is lastig te meten, maar in sectoren met weinig loyaliteit structureel merkbaar.

Wat zeggen de cijfers?

IBM publiceert jaarlijks een rapport over de kosten van datalekken. De gemiddelde kosten van een datalek lagen in 2024 wereldwijd op 4,88 miljoen dollar, een stijging van tien procent ten opzichte van het jaar daarvoor. Voor Europa liggen de gemiddelden iets lager, maar de richting is dezelfde. Voor het mkb, dat minder reserves heeft om een incident op te vangen, is de relatieve impact vaak groter dan voor grote organisaties.

Die cijfers zijn gemiddelden. De werkelijke kosten per incident variëren sterk en zijn afhankelijk van de omvang van de aanval, de sector, de voorbereiding van de organisatie en de snelheid van respons. Organisaties die een goed ingericht incidentresponsplan hadden, leden gemiddeld aanzienlijk minder schade dan organisaties die dat niet hadden.

Preventie versus herstel: de rekensom

De vraag die bestuurders zichzelf zouden moeten stellen, is niet “hoeveel kost goede beveiliging?” maar “hoeveel kost een incident dat we hadden kunnen voorkomen?”

Preventieve maatregelen zoals patchbeheer, toegangscontrole, monitoring en incidentresponsplanning hebben een vaste, beheersbare kostprijs. De kosten van een incident zijn variabel, onvoorspelbaar en in de meeste gevallen een veelvoud van wat preventie had gekost.

Dat is geen argument voor ongelimiteerde beveiligingsinvesteringen. Het is een argument voor bewuste keuzes: welke risico’s zijn acceptabel, welke niet, en wat is de kostprijs van de maatregelen die die afweging rechtvaardigen?

Drie vragen voor bestuurders

• Wat zou een week stilstand ons kosten?
  Niet alleen in omzet, maar ook in personeelskosten, contractverplichtingen en reputatie. Dit getal helpt de juiste schaal te bepalen voor beveiligingsinvesteringen.
• Zijn we verzekerbaar en onder welke voorwaarden?
  Cyberverzekeraars stellen steeds hogere eisen aan de beveiligingsmaatregelen van organisaties. Wie niet aan die eisen voldoet, betaalt meer of wordt niet gedekt bij een claim.
• Wat is onze persoonlijke aansprakelijkheid als bestuurder?
  Onder NIS2 zijn bestuurders van organisaties die onder de richtlijn vallen persoonlijk verantwoordelijk voor het beveiligingsbeleid. Dat maakt cybersecurity een onderwerp voor de boardroom, niet alleen voor de IT-afdeling.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties inzicht te krijgen in hun werkelijke risicoprofiel en de kosten die daarmee samenhangen. We vertalen technische kwetsbaarheden naar zakelijke impact, ondersteunen bij het maken van gefundeerde beveiligingskeuzes en helpen bij het inrichten van maatregelen die aansluiten op wat de organisatie nodig heeft.

Wil je weten wat een incident jouw organisatie zou kosten en welke maatregelen dat risico het meest effectief verkleinen? Neem contact op voor een vrijblijvend gesprek.

CIFSwitch: een negentien jaar oude Linux-kwetsbaarheid die nu actie vraagt

Een kwetsbaarheid die sinds 2007 in de Linux-kernel aanwezig is, maakt het mogelijk om volledige systeemrechten te verkrijgen op een breed scala aan Linux-omgevingen. Er is een werkende aanvalscode gepubliceerd. Een kernelpatch is beschikbaar maar wordt nog uitgerold door de distributies.

Linux-gebruikers en -beheerders zijn de afgelopen weken geconfronteerd met een reeks kwetsbaarheden: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt en PinTheft kwamen allemaal in korte tijd naar buiten. CIFSwitch is de nieuwste in die reeks, en onderscheidt zich door zijn leeftijd: de fout bestaat al negentien jaar.

De kwetsbaarheid werd ontdekt door een beveiligingsonderzoeker van SpaceX, die een uitgebreide technische toelichting en een werkende aanvalscode heeft gepubliceerd. Actief misbruik is op het moment van schrijven nog niet gemeld, maar de beschikbaarheid van die aanvalscode verlaagt de drempel voor misbruik aanzienlijk.

Wat is CIFS en waarom is dit relevant?

CIFS, voluit Common Internet File System, is een protocol waarmee Linux-systemen bestanden en mappen op andere computers in een netwerk kunnen benaderen. Vergelijkbaar met hoe een Windows-computer een gedeelde netwerkschijf koppelt. Dit protocol wordt veel gebruikt in bedrijfsomgevingen waar Linux-servers samenwerken met andere systemen, bijvoorbeeld bij gedeelde opslag of bestandsuitwisseling tussen servers.

Wanneer zo’n gedeelde schijf is beveiligd met Kerberos-authenticatie, een veelgebruikte methode in zakelijke netwerken, dan vraagt de Linux-kernel een hulpprogramma om die authenticatie af te handelen. Dat hulpprogramma draait met volledige beheerdersrechten. De fout in CIFSwitch zit in het feit dat de kernel niet controleert of verzoeken aan dat hulpprogramma daadwerkelijk van de kernel zelf afkomstig zijn. Een aanvaller kan die controle omzeilen, het hulpprogramma misleiden en via die weg volledige systeemrechten verkrijgen.

Welke systemen zijn kwetsbaar?

De kwetsbaarheid is niet universeel: of een systeem daadwerkelijk kwetsbaar is, hangt af van een combinatie van factoren. Denk aan de versie van de Linux-kernel, de aanwezigheid van het cifs-utils pakket in versie 6.14 of hoger, en de configuratie van beveiligingsbeleid op het systeem.

Distributies die in de standaardconfiguratie kwetsbaar zijn, zijn onder andere bepaalde versies van Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux en Amazon Linux, maar uitsluitend als cifs-utils geïnstalleerd is. Nieuwere versies zoals Ubuntu 26.04, Fedora 40 tot en met 44, CentOS Stream 10 en Rocky Linux 10 zijn dankzij strengere standaardinstellingen voor beveiligingsbeleid niet kwetsbaar via de standaardconfiguratie.

Kortom: niet elke Linux-omgeving loopt risico, maar de combinatie van een ouder systeem met gedeelde netwerkschijven via Kerberos is een duidelijk risicogebied.

Wat nu te doen

• Installeer de kernelupdate zodra die beschikbaar is voor jouw distributie
  De upstream kernelpatch is beschikbaar. De grote distributies rollen deze momenteel uit. Controleer of de update beschikbaar is voor jouw omgeving en voer deze zo snel mogelijk door.
• Schakel de CIFS-module uit als die niet wordt gebruikt
  Veel systemen hebben de CIFS-module geladen zonder dat die actief wordt gebruikt. Het uitschakelen ervan elimineert het aanvalspad volledig op die systemen.
• Controleer of de CIFS-module actief is:
  lsmod | grep cifs
• Schakel de module permanent uit:
  echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
• Verwijder cifs-utils als het niet nodig is
  Het hulpprogramma cifs-utils is een vereiste voor de aanval. Op systemen waar geen gebruik wordt gemaakt van CIFS-gedeelde schijven, kan het pakket worden verwijderd.
• Verwijder cifs-utils (Debian/Ubuntu):
  apt remove cifs-utils
• Verwijder cifs-utils (Red Hat/CentOS/AlmaLinux):
  dnf remove cifs-utils
• Schakel onbevoegde gebruikersnaamruimten uit
  De aanval maakt gebruik van een Linux-functie waarmee gewone gebruikers geïsoleerde omgevingen kunnen aanmaken. Op systemen waar dit niet noodzakelijk is, kan deze functie worden uitgeschakeld als aanvullende beveiligingsmaatregel. Let op: dit kan invloed hebben op containergebaseerde omgevingen zoals Docker.
• Schakel onbevoegde gebruikersnaamruimten uit:
  sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> /etc/sysctl.conf

Een patroon dat aandacht verdient

CIFSwitch is de zesde kwetsbaarheid van dit type die in korte tijd publiek is gemaakt voor Linux. Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt en PinTheft gingen eraan vooraf. Dat is geen toeval: zodra een onderzoeker diep in een onderdeel van de kernel duikt, vindt hij er vaker meer. De aanpak verspreidt zich ook: andere onderzoekers gebruiken dezelfde methoden om vergelijkbare fouten te vinden in andere onderdelen.

Voor organisaties die Linux draaien, betekent dit dat de afgelopen maanden een bovengemiddeld aantal kwetsbaarheden in dit besturingssysteem publiek is geworden. Wie patchbeheer niet structureel heeft georganiseerd, heeft de afgelopen weken meerdere keren achter de feiten aangelopen.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals CIFSwitch. We brengen in kaart welke systemen risico lopen, beoordelen of tijdelijke maatregelen correct zijn doorgevoerd en ondersteunen bij het inrichten van een patchproces dat aansluit op de snelheid waarmee dit soort dreigingen zich de afgelopen tijd hebben ontwikkeld.

Wil je weten of jouw Linux-omgeving kwetsbaar is of hoe jullie patchproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

YellowKey: een USB-stick waarmee BitLocker-versleuteling op Windows omzeild wordt

BitLocker is de ingebouwde versleutelingsfunctie van Windows waarmee organisaties hun laptops en servers beschermen tegen onbevoegde toegang. De gedachte is eenvoudig: als een laptop wordt gestolen of kwijtgeraakt, kan een dief zonder de juiste sleutel niets met de gegevens. Die aanname staat nu onder druk.

Een beveiligingsonderzoeker heeft een kwetsbaarheid gepubliceerd, YellowKey genaamd, waarmee BitLocker-versleuteling op Windows 11 en Windows Server 2022 en 2025 volledig kan worden omzeild. De aanvalscode is publiek beschikbaar op GitHub. Microsoft heeft de kwetsbaarheid inmiddels erkend onder CVE-2026-45585 en tijdelijke mitigatiestappen gepubliceerd. Een definitieve patch is nog in ontwikkeling.

Hoe werkt de aanval?

De aanval is verrassend eenvoudig uit te voeren. Wie fysieke toegang heeft tot een computer, kopieert een mapje met de naam FsTx naar een USB-stick. Vervolgens wordt de computer opgestart vanuit die USB-stick, waarna een fout in de Windows-herstelomgeving wordt misbruikt om toegang te krijgen tot de versleutelde schijf, zonder dat daarvoor een wachtwoord of herstelsleutel nodig is.

De kwetsbaarheid zit in de manier waarop de Windows Recovery Environment omgaat met een specifieke registerwaarde. Via die fout kan een kwaadaardig programma worden uitgevoerd voordat het besturingssysteem volledig is geladen, waarmee de pre-boot authenticatie van BitLocker volledig wordt omzeild.

Voor misbruik is fysieke toegang tot de computer vereist. De kwetsbaarheid treft Windows 11, Windows Server 2022 en Windows Server 2025. Windows 10 is niet kwetsbaar. Dat betekent dat de aanval relevant is in scenario’s waarbij een laptop of server in verkeerde handen valt, bijvoorbeeld bij diefstal, verlies of onbeheerde toegang tijdens onderhoud of reparatie.

Wat dit betekent voor organisaties

Veel organisaties vertrouwen op BitLocker als laatste verdedigingslinie voor laptops van medewerkers. De redenering is begrijpelijk: als een laptop wordt gestolen, zijn de gegevens onleesbaar. Die aanname klopt niet meer voor organisaties die Windows 11 draaien zonder aanvullende maatregelen.

De drempel voor misbruik is laag. De aanvalscode is publiek, de benodigde kennis minimaal en een USB-stick kost een paar euro. Dat maakt dit niet alleen een risico bij gerichte aanvallen, maar ook bij opportunistisch misbruik na diefstal of verlies van een apparaat.

De publieke beschikbaarheid van de YellowKey-aanvalscode verlaagt de drempel aanzienlijk, ook voor minder technisch onderlegde aanvallers.

Mitigatie: wat Microsoft adviseert

Microsoft heeft twee tijdelijke mitigatieopties gepubliceerd. Beide vereisen handmatig werk per apparaat door een systeembeheerder. Er is nog geen geautomatiseerde patch beschikbaar.

• Optie 1: Verwijder het kwetsbare onderdeel uit de herstelomgeving
  De aanval werkt doordat een kwaadaardig programma automatisch wordt gestart wanneer de Windows-herstelomgeving wordt geladen. Door dat programma uit het herstelimage te verwijderen en daarna de BitLocker-vertrouwensrelatie met de herstelomgeving te herstellen, wordt de aanvalsmethode geblokkeerd. Dit is de technisch grondigste aanpak en vereist uitvoering per apparaat.
  
  Mounten van het WinRE-image, verwijderen van autofstx.exe uit de BootExecute-registerwaarde en herstellen van BitLocker-vertrouwen:
  reagentc /disable
mkdir C:\WinRE
reagentc /info
# Noteer het pad naar Winre.wim, bijv. C:\Windows\System32\Recovery\Winre.wim
dism /Mount-Image /ImageFile:"C:\Windows\System32\Recovery\Winre.wim" /index:1 /MountDir:C:\WinRE
reg load HKLM\WinRE_System C:\WinRE\Windows\System32\config\SYSTEM
reg delete "HKLM\WinRE_System\ControlSet001\Control\Session Manager" /v BootExecute /f
reg add "HKLM\WinRE_System\ControlSet001\Control\Session Manager" /v BootExecute /t REG_MULTI_SZ /d "autocheck autochk *" /f
reg unload HKLM\WinRE_System
dism /Unmount-Image /MountDir:C:\WinRE /commit
reagentc /enable
manage-bde -protectors -disable C:
manage-bde -protectors -enable C:
  
• Optie 2: Voeg een BitLocker-pincode toe (eenvoudiger, maar beperkter)
  Het koppelen van BitLocker aan een persoonlijke pincode of een BIOS-wachtwoord blokkeert de huidige versie van YellowKey. Dit is de sneller te implementeren optie, maar let op: de onderzoeker heeft aangegeven ook een variant te hebben die TPM met pincode omzeilt. Die variant is echter vooralsnog niet publiek gemaakt.
  
  Inschakelen van TPM+PIN via Group Policy (voor beheerde omgevingen):
  Via Group Policy Editor:
  Computer Configuration > Administrative Templates >
Windows Components > BitLocker Drive Encryption >
Operating System Drives >
"Require additional authentication at startup"
  Stel in:
  Configure TPM startup PIN = Require startup PIN with TPM

• Aanvullend: stel een BIOS-wachtwoord in en beperk opstartopties
  De aanval vereist dat de computer opstart vanaf een externe USB-stick. Door in het BIOS de opstartvolgorde te beperken tot de interne schijf en dit te beveiligen met een wachtwoord, wordt het aanvalspad verder verkleind. Dit is een eenvoudige maar effectieve aanvullende maatregel, met name voor laptops die buiten de kantooromgeving worden gebruikt.

Bredere aanbevelingen voor organisaties

• Breng in kaart welke apparaten uitsluitend op TPM vertrouwen
  Laptops die buiten kantoor worden gebruikt, zijn het meest kwetsbaar bij diefstal of verlies. Zorg dat deze apparaten als eerste worden voorzien van de mitigatie.
• Controleer of Windows Server 2022 en 2025 in scope zijn
  De kwetsbaarheid treft ook servers. Hoewel fysieke toegang tot een server in een datacenter lastiger te realiseren is, verdient dit aandacht voor servers in minder beveiligde omgevingen zoals kantooromgevingen of co-locaties.
• Sla BitLocker-herstelsleutels veilig op
  Het toevoegen van een pincode heeft alleen zin als de pincode ook daadwerkelijk geheim blijft en de herstelsleutel niet eenvoudig toegankelijk is. Zorg dat herstelsleutels centraal en beveiligd worden opgeslagen, bijvoorbeeld via Microsoft Intune of Active Directory, en niet lokaal op het apparaat.
• Houd de patchstatus actief in de gaten
  Microsoft werkt aan een definitieve patch. Zodra die beschikbaar is, moet deze prioriteit krijgen bij de uitrol, ook op apparaten waar de tijdelijke mitigatie al is doorgevoerd.
• Ga voor een multilayer oplossing
  Door bijvoorbeeld voor een encryptie-oplossing van een andere partij te kiezen waarbij bij elke boot een wachtwoord of PIN-code altijd vereist is.

De kern van het probleem

YellowKey laat zien dat encryptie alleen niet voldoende is als beveiligingsmaatregel. BitLocker beschermt gegevens op een versleuteld apparaat, maar die bescherming is afhankelijk van hoe het is geconfigureerd. Een standaardinstallatie zonder pincode of BIOS-beveiliging biedt bij fysieke toegang minder bescherming dan veel organisaties aannemen. Daarbij zijn wij van mening dat encryptie waarbij elke keer het wachtwoord ingevuld moet worden uit het oogpunt van security altijd beter is.

Dat is de les die hier wordt onderstreept: versleuteling is een laag in een beveiligingsstrategie, geen sluitende oplossing op zichzelf. Wie dat begrijpt, begrijpt ook waarom de configuratie van die versleuteling minstens zo belangrijk is als het feit dat die aanstaat.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties beoordelen of hun encryptieconfiguratie aansluit op de huidige dreigingen. We brengen in kaart welke apparaten kwetsbaar zijn, ondersteunen bij het doorvoeren van mitigatiestappen en adviseren over een structurele aanpak van endpoint-beveiliging die verder gaat dan het standaard inschakelen van BitLocker.

Wil je weten of jouw organisatie kwetsbaar is voor YellowKey of hoe jullie BitLocker-configuratie er voor staat? Neem contact op voor een vrijblijvend gesprek.

Nieuwe zero-day in Windows geeft aanvallers volledige systeemtoegang op volledig bijgewerkte systemen

Deze week werd MiniPlasma gepubliceerd: een zero-day kwetsbaarheid in Windows waarvoor geen patch beschikbaar is. Via deze kwetsbaarheid kan iemand met gewone gebruikerstoegang volledige systeemrechten verkrijgen op elk Windows-systeem, inclusief systemen die volledig zijn bijgewerkt met de laatste updates van mei 2026.

Een zero-day betekent dat de kwetsbaarheid publiek bekend is voordat de softwareleverancier een oplossing heeft uitgebracht. Aanvallers kunnen er direct gebruik van maken. Microsoft heeft nog geen patch aangekondigd en heeft de kwetsbaarheid nog niet voorzien van een officieel nummer.

Wat er precies speelt

De kwetsbaarheid zit in een onderdeel van Windows dat verantwoordelijk is voor de synchronisatie van bestanden met cloudopslag, zoals OneDrive. Via een fout in dat onderdeel kan een aanvaller een proces opstarten met de hoogst mogelijke systeemrechten, de zogenaamde SYSTEM-rechten. Wie op dat niveau toegang heeft, heeft volledige controle over het systeem: bestanden inzien, aanpassen of verwijderen, andere gebruikers beheren, beveiligingssoftware uitschakelen.

Voor dit soort aanvallen is lokale toegang tot een systeem vereist, dat wil zeggen: de aanvaller moet al een account op het systeem hebben, of al op een andere manier toegang hebben verkregen. Dat klinkt als een beperking, maar in de praktijk is het dat niet. Phishing, een gestolen wachtwoord of een andere kwetsbaarheid die eerder is misbruikt, zijn gebruikelijke manieren om die eerste voet tussen de deur te krijgen. MiniPlasma is dan de volgende stap: van beperkte toegang naar volledige controle.

Getest op volledig bijgewerkte systemen

Meerdere onafhankelijke onderzoekers hebben bevestigd dat de aanvalscode werkt op Windows 11 met de meest recente updates van mei 2026. Een standaard gebruikersaccount zonder beheerdersrechten is voldoende om een omgeving te openen met volledige SYSTEM-rechten. De aanval werkt niet op de meest recente testversie van Windows 11, de zogenaamde Insider Preview Canary-build, wat erop wijst dat Microsoft bezig is met een oplossing, maar die is voor reguliere Windows-gebruikers nog niet beschikbaar.

Dat is precies wat een zero-day gevaarlijk maakt: de aanvalsmethode is beschikbaar, de oplossing nog niet.

Onderdeel van een bredere reeks

MiniPlasma staat niet op zichzelf. De afgelopen weken zijn er meerdere vergelijkbare kwetsbaarheden in Windows publiek gemaakt, waaronder BlueHammer, RedSun, YellowKey en GreenPlasma. Van de eerste twee is inmiddels bevestigd dat ze actief worden misbruikt in aanvallen. Samen vormen ze een ongewoon grote hoeveelheid publiek beschikbare aanvalsmethoden voor een besturingssysteem dat wereldwijd op honderden miljoenen systemen draait.

Voor organisaties betekent dit dat het aanvalsoppervlak op Windows-omgevingen de afgelopen weken aanzienlijk is vergroot, ook op systemen die volledig zijn bijgewerkt.

Wat nu te doen

Omdat er nog geen patch beschikbaar is, zijn de opties beperkt. Toch zijn er maatregelen die het risico verkleinen.

• Beperk lokale toegang tot systemen
  MiniPlasma vereist een bestaand account op het systeem. Hoe strikter de toegangscontrole, hoe kleiner de kans dat een aanvaller die eerste stap kan zetten. Controleer welke gebruikers toegang hebben tot welke systemen en verwijder onnodige accounts of rechten.
  Door te beperken wie er een lokale Administrator is beperk je deze kans ook.
• Schakel het Cloud Filter-onderdeel uit waar het niet nodig is
  De kwetsbaarheid zit in een onderdeel dat gekoppeld is aan cloudbestandssynchronisatie. Op systemen waar dat niet actief wordt gebruikt, kan de onderliggende driver worden uitgeschakeld. Vraag je IT-afdeling of leverancier dit te beoordelen, als je actief OneDrive gebruikt is de kans groot dat het Cloud Filter nodig is.
• Controleer of de Cloud Filter driver actief is:
  sc query cldflt
• Schakel de driver uit op systemen waar cloudbestandssynchronisatie niet nodig is:
  sc config cldflt start=disabled
sc stop cldflt
• Versterk detectie op verdacht gedrag
  Zorg dat verdachte escalatie van gebruikersrechten wordt gesignaleerd. Processen die onverwacht met SYSTEM-rechten worden gestart door een gewone gebruiker, zijn een duidelijk signaal. Goede monitoringtools herkennen dit patroon.
• Houd patchupdates actief in de gaten
  Zodra Microsoft een officiële patch uitbrengt, is snelle uitrol noodzakelijk. Gezien de reeks van recente kwetsbaarheden is de verwachting dat dit via een reguliere of spoedpatch zal gebeuren. Zorg dat je patchproces snel genoeg kan reageren.

Wat dit betekent voor jouw organisatie

Een zero-day zonder beschikbare patch vraagt om een andere aanpak dan een reguliere kwetsbaarheid. Updaten lost het probleem nu niet op. Wat wel helpt: het aanvalsoppervlak verkleinen, toegang beperken en zorgen dat verdacht gedrag op systemen wordt opgemerkt.

De combinatie van meerdere publiek beschikbare aanvalsmethoden voor Windows, waarvan sommige al actief worden misbruikt, laat zien dat de druk op Windows-omgevingen momenteel hoger is dan gebruikelijk. Organisaties die hun beveiliging primair baseren op het bijhouden van updates, merken nu dat dat niet altijd voldoende is.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals MiniPlasma, ook als er nog geen patch beschikbaar is. We beoordelen of tijdelijke maatregelen correct zijn doorgevoerd, ondersteunen bij het inrichten van detectie op verdacht gedrag en zorgen dat patchprocessen aansluiten op de snelheid waarmee dit soort dreigingen zich ontwikkelen.

Wil je weten of jouw Windows-omgeving kwetsbaar is of hoe jullie beveiligingsproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

Dirty Frag: een nieuwe Linux-kwetsbaarheid terwijl de vorige nog niet is gedicht

Weken na Copy Fail is er opnieuw een ernstige kwetsbaarheid in Linux gepubliceerd. Dirty Frag werkt op een andere manier dan de vorige, waardoor eerdere tijdelijke maatregelen geen bescherming bieden. Er is nog geen definitieve patch beschikbaar.

Begin mei schreven we over Copy Fail, een kwetsbaarheid in Linux die bijna negen jaar onopgemerkt bleef en inmiddels actief wordt misbruikt. Vorige week werd Dirty Frag gepubliceerd: een nieuwe kwetsbaarheid in hetzelfde besturingssysteem, door dezelfde onderzoeker ontdekt, met een vergelijkbare impact maar via een andere aanvalsmethode.

Het onderscheid is relevant, want organisaties die de tijdelijke maatregel voor Copy Fail hebben doorgevoerd, zijn met die maatregel niet beschermd tegen Dirty Frag.

Wat er aan de hand is

Dirty Frag maakt het mogelijk dat iemand met beperkte toegang tot een Linux-systeem zichzelf volledige beheerdersrechten geeft. Net als bij Copy Fail gaat het om een aanval die alleen in het geheugen plaatsvindt, nauwelijks sporen achterlaat en consistent werkt, zonder dat er sprake is van geluk of timing.

De kwetsbaarheid combineert twee fouten in de Linux-kernel die samen een aanval mogelijk maken. De oudste van die twee bestaat al sinds 2017, de tweede sinds 2023. Vrijwel alle grote Linux-varianten zijn kwetsbaar: Ubuntu, Red Hat, CentOS, AlmaLinux, openSUSE en Fedora zijn bevestigd getroffen.

Wat de situatie extra urgent maakt: de aanvalscode is publiek beschikbaar voordat er een definitieve patch is. De embargo op volledige publicatie werd op 7 mei doorbroken door een derde partij, waarna de onderzoeker in overleg met de beheerders besloot de technische details alsnog te publiceren. Op het moment van schrijven zijn er voor de meeste distributies nog geen definitieve kernelpatches uitgebracht.

Belangrijk: de maatregel voor Copy Fail helpt hier niet

In onze vorige blogpost adviseerden we een specifieke tijdelijke maatregel voor Copy Fail: het uitschakelen van de algif_aead kernelmodule. Die maatregel is nog steeds relevant voor Copy Fail, maar biedt geen bescherming tegen Dirty Frag. De twee kwetsbaarheden werken via andere onderdelen van de kernel.

Organisaties die die stap al hebben gezet, zijn dus nog steeds kwetsbaar voor deze nieuwe aanval. Dat vraagt om aanvullende actie.

Wat nu te doen

Zolang er geen definitieve patch beschikbaar is, zijn er tijdelijke maatregelen die de aanvalsoppervlakte verkleinen. Vraag je systeembeheerder of IT-leverancier de volgende stappen door te voeren:

• Stap 1: Schakel de kwetsbare kernelmodules uit
  Dirty Frag maakt gebruik van specifieke netwerkonderdelen in de Linux-kernel. Die onderdelen kunnen worden uitgeschakeld. Voor de meeste organisaties heeft dit geen merkbare impact op de dagelijkse werking van systemen. Voer daarna ook een geheugencache-reset uit om eventuele sporen te wissen.
  
  Schakel de modules uit en reset de geheugencache:
  sudo printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches
• Stap 2: Controleer of systemen mogelijk al zijn aangetast
  Microsoft heeft gesignaleerd dat er al beperkt actief misbruik plaatsvindt, waarbij aanvallers na toegang via SSH onmiddellijk proberen hogere rechten te verkrijgen. Als je twijfelt of systemen al zijn blootgesteld, is forensisch onderzoek verstandig voordat je alleen de tijdelijke maatregel toepast. Een mitigatie wist namelijk geen sporen van een aanval die al heeft plaatsgevonden.
• Stap 3: Houd de patchstatus actief in de gaten
  Distributies werken aan kernelpatches. Zodra die beschikbaar zijn voor jouw omgeving, moeten ze zo snel mogelijk worden doorgevoerd. De tijdelijke maatregel vervangt de definitieve patch niet.
• Stap 4: Vergeet de cloud niet
  Ook in cloudplatforms en containeromgevingen kan Dirty Frag worden misbruikt, afhankelijk van de configuratie. Controleer of de tijdelijke maatregel ook in die omgevingen is doorgevoerd en of je provider aanvullende guidance heeft gepubliceerd.

Wat dit zegt over de bredere situatie

Copy Fail en Dirty Frag zijn geen toevallige samenloop. Ze zijn onderdeel van een bredere klasse van kwetsbaarheden in Linux die de afgelopen jaren zijn ontdekt, waaronder Dirty Cow in 2016 en Dirty Pipe in 2022. Dezelfde onderzoeker die Copy Fail vond, ontdekte Dirty Frag juist doordat hij de eerste kwetsbaarheid zo grondig onderzocht.

Dat patroon is veelzeggend: wie een kwetsbaarheid vindt, vindt er vaak meer. En de beschikbaarheid van AI-tools versnelt dat proces. De tijd tussen het vinden van een fout en het publiceren van werkende aanvalscode wordt korter. Voor organisaties betekent dat een structurele druk op patchprocessen die niet zijn ingericht op snelheid.

De vraag is niet meer of er nieuwe kwetsbaarheden komen. De vraag is of jouw organisatie snel genoeg kan reageren als ze er zijn.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals Copy Fail en Dirty Frag. We beoordelen of tijdelijke maatregelen correct zijn doorgevoerd, ondersteunen bij het inrichten van een patchproces dat aansluit op de huidige snelheid van dreigingen, en helpen bij het bepalen of systemen mogelijk al zijn aangetast.

Wil je weten of jouw omgeving kwetsbaar is of hoe jullie patchproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

Copy Fail: een Linux-kwetsbaarheid die al negen jaar onopgemerkt was en nu directe actie vraagt

Een ernstige kwetsbaarheid in Linux is publiek gemaakt. De fout zit al sinds 2017 in vrijwel alle versies, er is een werkende aanvalsmethode beschikbaar, en de aanval laat nauwelijks sporen achter. Organisaties die Linux gebruiken, moeten dit nu oppakken.

Vorige week werd een kwetsbaarheid in Linux publiek gemaakt onder de naam Copy Fail (CVE-2026-31431). De fout zat al negen jaar verborgen in het besturingssysteem en treft vrijwel alle gangbare versies die sinds 2017 zijn uitgebracht. Inmiddels is er een werkende aanvalsmethode beschikbaar die publiek toegankelijk is.

Dit is geen theoretisch risico. Het is een concrete kwetsbaarheid waarvoor actie vereist is.

Wat er aan de hand is

Linux is het besturingssysteem waarop een groot deel van de digitale infrastructuur draait: servers, cloudplatforms, webapplicaties en bedrijfssystemen. Ook veel Nederlandse organisaties maken er gebruik van, soms direct, soms indirect via hun cloud- of hostingprovider.

De kwetsbaarheid zit in een onderdeel van Linux dat verantwoordelijk is voor encryptie. Via die fout kan iemand met gewone, beperkte toegang tot een systeem zichzelf volledige beheerdersrechten geven. Dat betekent: volledige controle over het systeem, inclusief alle data die erop staat of doorheen gaat.

Wat deze kwetsbaarheid onderscheidt

Kwetsbaarheden in software worden regelmatig ontdekt en verholpen. Copy Fail wijkt op een aantal punten af van wat normaal gangbaar is.

• Betrouwbaar en eenvoudig uit te voeren
  De aanval werkt consistent, vereist geen geavanceerde kennis en is gebaseerd op een klein, publiek beschikbaar script. De drempel voor misbruik is laag.
• Moeilijk te detecteren
  De manipulatie vindt alleen in het geheugen plaats. Bestanden op de harde schijf worden niet gewijzigd, waardoor gangbare beveiligingstools die controleren op bestandswijzigingen niets signaleren.
• Werkt ook in cloud- en containeromgevingen
  De kwetsbaarheid kan de isolatie tussen containers doorbreken. Een aanval vanuit één applicatie kan daarmee het volledige systeem raken, inclusief andere omgevingen op dezelfde server.
• Treft vrijwel alle Linux-omgevingen
  Ubuntu, Red Hat, Amazon Linux, SUSE: alle grote varianten zijn kwetsbaar. Het maakt niet uit welke versie of configuratie, als het systeem sinds 2017 niet specifiek is aangepast, is het waarschijnlijk kwetsbaar.

Voor welke organisaties is dit relevant?

Dit speelt voor elke organisatie die gebruikmaakt van Linux-servers, cloudplatforms zoals AWS, Azure of Google Cloud, gecontaineriseerde applicaties, of externe leveranciers en hostingpartijen die op Linux-infrastructuur draaien. In de praktijk betekent dat: de meeste organisaties met een IT-omgeving van enige omvang.

Wat moet er nu gebeuren?

Er zijn twee sporen: een tijdelijke maatregel voor nu, en een structurele oplossing voor de iets langere termijn.

• Direct: schakel het kwetsbare onderdeel uit
  De kwetsbaarheid zit in een specifieke module van de Linux-kernel, het onderdeel dat encryptieoperaties afhandelt voor toepassingen die daar gebruik van maken. Deze module kan worden uitgeschakeld zonder dat dit voor de meeste organisaties merkbare gevolgen heeft voor de werking van systemen. Vraag je systeembeheerder of IT-leverancier dit te controleren en indien nodig uit te schakelen. Dit is de tijdelijke mitigatie tot de patch is doorgevoerd.

• Controleer of de module actief is:
  lsmod | grep algif_aead
• Schakel de module permanent uit en verwijder hem uit het geheugen:
  echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
update-initramfs -u -k all
rmmod algif_aead

• Structureel: installeer de kernelupdate
  De definitieve oplossing is een update van de Linux-kernel. Die update is beschikbaar en wordt momenteel uitgerold door de grote distributeurs. Laat bevestigen dat alle betrokken systemen zijn bijgewerkt, inclusief systemen bij externe leveranciers en in cloudomgevingen.
• Vergeet de cloudomgeving niet
  Cloudproviders rollen updates soms automatisch uit, maar niet altijd. Zeker als je zelf verantwoordelijk bent voor het beheer van virtuele machines of containers, is een expliciete controle noodzakelijk.

De bredere context

Copy Fail werd ontdekt door beveiligingsonderzoekers die AI inzetten om kwetsbaarheden te vinden. Wat normaal weken of maanden zou kosten, duurde in dit geval ongeveer een uur. Dat is een ontwikkeling die doorzet: zowel aanvallers als verdedigers zetten steeds vaker AI in, en de snelheid waarmee nieuwe kwetsbaarheden worden gevonden en misbruikt neemt toe.

Voor organisaties betekent dat: de tijd tussen ontdekking van een kwetsbaarheid en actief misbruik wordt korter. Patchbeheer dat niet structureel is georganiseerd, levert daarmee een steeds groter risico op.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties inzicht te krijgen in kwetsbaarheden in hun infrastructuur en zorgt dat patchprocessen aansluiten op de snelheid waarmee dreigingen zich ontwikkelen. We ondersteunen bij het in kaart brengen van risico’s, het beoordelen van maatregelen en het inrichten van structureel vulnerability management.

Wil je weten of jouw Linux-omgeving kwetsbaar is, of hoe jullie patchproces er meer in het algemeen voor staat? Neem contact op voor een vrijblijvend gesprek.

Kwaadaardige code die je niet kunt zien: hoe aanvallers Unicode misbruiken in open source repositories

Unicode is de wereldwijde standaard voor het weergeven van tekst in vrijwel elke taal, elk schrift en elk symbool. De standaard omvat ook een categorie tekens zonder zichtbare weergave: zogenoemde onzichtbare of “non-printable” tekens. Die hebben legitieme toepassingen, zoals het sturen van tekstopmaak, het markeren van leesrichting (links-naar-rechts of rechts-naar-links), of het verfijnen van hoe bepaalde symbolen worden weergegeven in specifieke taalcontexten. Kortom: nuttige tekens, met een duidelijk doel.

Dat doel wordt nu misbruikt. Aanvallers verstoppen kwaadaardige code in precies die onzichtbare Unicode-tekens, waarna die code onopgemerkt in broncode terechtkomt. Wat jij ziet als een lege string of een stukje witruimte, bevat in werkelijkheid een gecodeerde payload.

Glassworm: een aanvaller die al een jaar actief is

De dreiging heeft inmiddels een naam: Glassworm. De aanvaller werd in maart 2025 voor het eerst gespot in kwaadaardige npm-pakketten en is sindsdien actief gebleven. In oktober 2025 werden gecompromitteerde VS Code-extensies gevonden. En in maart 2026 is er opnieuw een grootschalige golf waargenomen, ditmaal in meer dan 150 GitHub-repositories, aangevuld met nieuwe kwaadaardige pakketten op npm en in de VS Code Marketplace.

Onder de getroffen repositories bevinden zich bekende projecten zoals de starterpagina van Wasmer en verschillende repositories van de organisatie achter OpenCode en SST.

Hoe de aanval technisch werkt

De truc is eenvoudig maar effectief. Glassworm plaatst een klein stukje JavaScript-code in een bestand van een legitiem project. Die code ziet er onschuldig uit: een functie die een string verwerkt en het resultaat doorgeeft aan eval(). Het bijzondere zit in de string zelf. Die lijkt leeg, maar bevat onzichtbare Unicode-tekens in het bereik U+FE00 tot U+FE0F en U+E0100 tot U+E01EF. Die tekens coderen samen een verborgen payload, die tijdens uitvoering wordt gedecodeerd en direct uitgevoerd.

Wat er dan gebeurt is eerder al gedocumenteerd: het ophalen en uitvoeren van een tweede script, met als doel het stelen van tokens, inloggegevens en geheimen.

Waarom dit moeilijk te detecteren is

De aanval onderscheidt zich op een paar punten van gewone malware. Ten eerste is de kwaadaardige toevoeging volledig onzichtbaar bij visuele code review. Editors, terminals en code review-interfaces tonen niets. Ten tweede worden de commits zorgvuldig vormgegeven: documentatieupdates, versienummerverhogingen, kleine bugfixes. Ze zien eruit alsof ze van een reguliere bijdrager komen.

Bij meer dan 150 repositories tegelijk is dat niveau van maatwerk waarschijnlijk deels geautomatiseerd, mogelijk met hulp van AI. Dat maakt het schaalbaar en daarmee zorgwekkend.

Bredere context: supply chain risico

Dit type aanval illustreert een groter probleem in moderne softwareontwikkeling. Organisaties bouwen voort op open source code, externe pakketten en community-bijdragen. Dat is efficiënt, maar introduceert ook afhankelijkheden waarover de eigen organisatie geen directe controle heeft. Als een upstream-repository wordt gecompromitteerd met onzichtbare code, wordt die code mogelijk stilzwijgend opgenomen in de eigen software.

Standaard beveiligingsmaatregelen zoals linting, code reviews en statische analyse op basis van zichtbare patronen volstaan hier niet. Je scant immers op wat je ziet.

Hoe RiskGuard kan helpen

RiskGuard beschikt over tooling om broncode te scannen op dit type verborgen Unicode-injecties. Dat geldt voor zowel eigen codebases als externe afhankelijkheden. We integreren dit in bredere supply chain security assessments, waarbij we niet alleen kijken naar bekende kwetsbaarheden in pakketten, maar ook naar afwijkende patronen in de broncode zelf.

Wil je weten of jouw repositories of softwareomgeving blootstaat aan dit type aanval? Neem contact met ons op voor een scan of een gesprek over hoe je dit structureel inregelt.

OAuth-misbruik: hoe aanvallers vertrouwde inlogpagina’s als wapen gebruiken

Microsoft waarschuwde begin maart voor een phishingtechniek waarbij aanvallers misbruik maken van OAuth, het inlogprotocol dat vrijwel elke organisatie dagelijks gebruikt. De aanvallen richten zich specifiek op overheids- en publieke sector organisaties, maar de techniek zelf is breed toepasbaar.

Wat is OAuth en waarom is dit relevant?

OAuth is een standaard die het mogelijk maakt om je via een bestaand account ergens in te loggen, zoals “Log in met Microsoft” of “Log in met Google”. De gebruiker hoeft geen nieuw wachtwoord aan te maken; de identiteitsprovider (bijvoorbeeld Entra ID of Google Workspace) bevestigt wie je bent en stuurt je door naar de applicatie.

Dat doorsturen heet een redirect, en precies daar zit het probleem.

Hoe werkt deze aanval?

De aanvaller maakt een eigen applicatie aan in een door hem beheerde omgeving. Die applicatie configureren ze zo dat de redirect verwijst naar een kwaadaardige website in plaats van een legitieme dienst.

Vervolgens sturen ze phishingmails met een OAuth-link. Die link ziet er betrouwbaar uit, want hij loopt via een echte domeinnaam van Microsoft of Google. De ontvanger klikt, ziet een vertrouwde inlogpagina, en wordt daarna automatisch doorgestuurd naar een pagina die malware aflevert.

Het gaat hier niet om een softwarekwetsbaarheid. OAuth werkt precies zoals het bedoeld is. Aanvallers misbruiken een legitieme functie van het protocol.

Wat er daarna gebeurt

Als de gebruiker op de kwaadaardige pagina terechtkomt, wordt een ZIP-bestand gownload met een snelkoppeling erin. Opent de gebruiker het bijgevoegde LNK-bestand (een Windows-snelkoppeling), dan wordt er direct een PowerShell-commando uitgevoerd. Dat commando start een keten van acties: het systeem wordt in kaart gebracht, een DLL-bestand wordt geladen via een legitiem uitvoerbaar bestand, en uiteindelijk wordt er een verbinding opgezet met een externe server die verdere opdrachten kan sturen, oftewel een command-and-control (C2) server.

In sommige gevallen gebruiken aanvallers de techniek niet voor malware maar voor het onderscheppen van sessiecookies, waarmee ze zonder wachtwoord toegang krijgen tot accounts.

Waarom traditionele detectie hier tekortschiet

De link in de phishingmail verwijst naar een domein van Microsoft of Google. Dat haalt veel e-mailfilters en browserbeveiliging. De gebruiker ziet een vertrouwde URL en een herkenbare inlogpagina. Er is geen verdacht domein zichtbaar, geen spelfouten in het adres, geen reden om te twijfelen.

Dat maakt deze aanvalsmethode lastiger te herkennen dan klassieke phishing.

Wat organisaties kunnen doen

Microsoft heeft inmiddels een aantal kwaadaardige OAuth-applicaties verwijderd die bij dit onderzoek zijn gevonden. Maar de techniek zelf blijft beschikbaar voor aanvallers.

Praktische stappen om het risico te beperken:

• Beperk wie binnen de organisatie OAuth-applicaties mag autoriseren. Laat dit niet standaard open staan voor alle medewerkers.
• Controleer periodiek welke applicaties toegang hebben tot accounts in Entra ID of Google Workspace. Verwijder apps die niet meer gebruikt worden of ruimere rechten hebben dan nodig.
• Zorg dat medewerkers weten dat ook links via microsoft.com of accounts.google.com onderdeel kunnen zijn van een aanval. Vertrouwen op het domein alleen is niet genoeg.
• Zet detectie in op afwijkend inloggedrag, zoals logins vanuit ongebruikelijke locaties of op ongebruikelijke tijden.

Onze Cloud Security baselines en detectie van afwijkend gedrag kan hierbij helpen om het te voorkomen maar ook om te signaleren áls het wel gebeurt.

Conclusie

Deze aanvalsmethode laat zien dat aanvallers steeds vaker legitieme infrastructuur gebruiken om detectie te omzeilen. Geen nep-domeinen, geen malafide certificaten, gewoon het inlogsysteem dat al aanwezig is en vertrouwd wordt.

Dat vraagt om een bredere blik op identity security: niet alleen wie toegang heeft, maar ook welke applicaties die toegang hebben en hoe inlogstromen verlopen.

Bij RiskGuard helpen wij organisaties met het in kaart brengen van identity-risico’s, het beoordelen van applicatierechten en het detecteren van afwijkend gedrag. Neem contact op als u wilt weten hoe uw organisatie ervoor staat.