Vrijdagmiddag, half vier. Een ontwikkelaar moet een klant iets laten zien dat nog op zijn eigen laptop draait. Een testomgeving aanvragen duurt dagen, dus typt hij één regel in zijn terminal. Drie seconden later heeft hij een https-adres dat hij in de chat kan plakken, en aan de andere kant van dat adres staat zijn werklaptop. Niemand heeft iets aangevraagd, niemand heeft iets goedgekeurd, en in geen enkel logboek van jouw organisatie staat dat dit gebeurd is.
Dat commando bestaat al vijf jaar. Deze week werd het pas echt gezien, toen ondernemer Nick Gray er op X over postte: “I just saw Cloudflare launched Quick Tunnels”, met de belofte eronder die op de site staat. Geen account. Geen DNS. Geen open poorten. Ruim zeventienduizend mensen zagen het langskomen, driehonderdtwintig bewaarden het. Eén reactie eronder benoemt wat de rest overslaat.
“Geen account” is precies de reden dat criminelen het gebruiken
De regel die iedereen als winst leest, staat bijna woordelijk in een dreigingsrapport. Proofpoint schreef op 1 augustus 2024 dat aanvallers “the TryCloudflare feature that allows an attacker to create a one-time tunnel without creating an account” misbruiken. Geen account betekent voor jouw ontwikkelaar: geen gedoe. Voor een aanvaller betekent het: geen betaalspoor, geen registratie, geen naam om op te zoeken.
Proofpoint zag het voor het eerst in februari 2024 en de campagnes liepen op tot juli. De payloads waren Xworm, AsyncRAT, VenomRAT, GuLoader en Remcos. Eén campagne op 11 juli telde ruim vijftienhonderd berichten naar bedrijven in onder meer financiën, industrie en techniek, terwijl een campagne van 28 mei met een belastingthema onder de vijftig berichten bleef en op advocatenkantoren en financiële bedrijven mikte. De volumes liepen van honderden tot tienduizenden berichten per campagne, bij tientallen tot duizenden organisaties. De lokthema’s waren precies de saaie: facturen, documentverzoeken, pakketbezorging, belastingen. En de lures waren er ook in het Frans, Spaans en Duits, dus taal is geen drempel.
Wat het rapport zo bruikbaar maakt voor iedereen die aan human firewall werkt, is de keten. Die begint bij een mens. Een mail met een link of bijlage leidt naar een .URL-bestand. Dat legt een verbinding met een externe bestandsshare via WebDAV. Daar staat een LNK of VBS klaar, die start een BAT of CMD, die haalt een Python-installer plus scripts op, en pas daarna staat de RAT er. Ondertussen ziet het slachtoffer een keurige pdf. Vijf stappen na de klik, en elke stap verplaatst het werk naar een plek die legitiem oogt.
Het willekeurige adres is de hele beveiliging
In het draadje onder Grays post schrijft een gebruiker met de naam Navlio precies waar het om draait: het willekeurige subdomein is het hele verhaal wat toegang betreft. Geen account betekent dat iedereen die die link krijgt bij je laptop kan, en een ontwikkelserver is meestal het minst beveiligde dat erop draait. Die reactie kreeg een fractie van de aandacht van het enthousiasme eromheen.
Hij heeft gelijk, en het is erger dan het klinkt. Zo’n adres is niet te raden, dat klopt. Maar het is ook niet in te trekken. Het staat in de chatgeschiedenis van de klant, in de mailbox van de collega die was doorgestuurd, en in de logs van elke dienst die de link opvroeg. Zolang het proces draait, werkt het. Een ontwikkelserver heeft meestal foutmeldingen aan staan, vaak een debug-console, soms een databaseverbinding met productiegegevens die “even” gekopieerd waren voor een test.
Cloudflare zet het niet weg als speelgoed. In de eigen documentatie staat het kort: “Quick Tunnels are intended for testing and development only.” Sinds een wijziging van 7 oktober 2024 staat er ook een regel in de waarschuwing die het programma zelf afdrukt, waarin Cloudflare zegt dat het gebruik van tunnels mag onderzoeken op schending van de voorwaarden. Die zin is er niet zomaar bijgekomen in het jaar dat de misbruikrapporten verschenen.
Dit verbieden werkt niet, en dat is ongemakkelijk
De reflex in ons vak is een verbod: zet *.trycloudflare.com op de blokkeerlijst en klaar. Dat advies is makkelijk te geven en het houdt ongeveer een week stand. Ngrok doet hetzelfde, Tailscale heeft er een functie voor en in Visual Studio Code zit het ingebouwd, dus de ontwikkelaar die vrijdagmiddag een demo moet geven, is binnen tien minuten weer online. Je hebt dan geen risico weggenomen, je hebt het alleen onzichtbaar gemaakt voor jezelf.
Bovendien is de tool gewoon goed. Webhooks van een betaaldienst testen zonder een server op te tuigen, een collega in een ander land iets laten zien, een site in drie browsers nakijken: daar is dit voor gemaakt en dat werkt prima. Wie doet alsof dit kwaadaardige software is, verliest het gesprek met zijn eigen ontwikkelteam. En dat gesprek heb je nodig, want dit is social engineering van de andere kant: niet de aanvaller die binnenkomt, maar de collega die met goede bedoelingen een deur openzet.
Wat wel werkt is de keten aanpakken in plaats van het merk. In de Proofpoint-keten zit één stap die in bijna geen enkel Nederlands kantoor een zakelijke reden heeft: een werkstation dat uitgaand een WebDAV-verbinding opzet naar een onbekende server. Daar staat de aanvaller zijn LNK-bestand, en daar valt zijn keten om als die verbinding niet mag. Proofpoint geeft zelf nog een tweede: beperk Python op werkplekken waar niemand ermee werkt, want de hele installer-truc bestaat om Python mee te brengen naar machines die het niet hebben.
Vraag je ontwikkelaars wat er nu openstaat
Eén ding voor maandagochtend, en het is een vraag, geen maatregel. Vraag in het teamoverleg van je ontwikkelaars wie er wel eens een tunnel naar zijn eigen machine opzet, waarvoor, en of zo’n adres nu nog leeft. Geen verwijt erbij, anders krijg je geen antwoord. Je wilt weten hoe vaak het gebeurt en waarom het nodig is, want dat vertelt je wat er in je eigen proces ontbreekt.
Bijna altijd is het antwoord: een testomgeving aanvragen duurt te lang. Dat is een planningsprobleem dat zich als beveiligingsprobleem voordoet, en het is met een verbod niet op te lossen. Hetzelfde principe als bij ransomware: de techniek is het laatste stuk, het gedrag eromheen is waar je iets kunt veranderen. Wie wil weten hoe zijn team op dit soort dingen reageert, kan de firewall test ernaast leggen, of nakijken welke soorten phishing in dezelfde keten voorkomen.
Het volgende moment om op te letten zit in Cloudflare zelf. In de broncode van cloudflared staat sinds 28 augustus een reeks wijzigingen die een inlogscherm vóór zo’n tunnel zet, met een lijst van toegestane e-mailadressen; de laatste landde op 17 september. Komt die functie uit en gaat hij standaard aan, dan is de discussie van deze week binnen een jaar achterhaald. Blijft hij een optie die je zelf moet aanzetten, dan verandert er niets en blijft het willekeurige adres de enige drempel.
Zelf een situatie die niet vertrouwd voelt?
Beschrijf wat er gebeurde of waar je over twijfelt, dan denkt Rik mee over de juiste reactie.