Om 09:25 komt er een mail binnen met HIGH in de onderwerpregel. Een “security researcher” heeft een lek gevonden in je website. Engels, strak opgemaakt, met RFC-nummers en een link naar je eigen site. Je hebt geen beveiligingsteam. Je hebt een koffie en een website. Is dit een echte melding, of een beg bounty?
Een websitebeheerder stuurde ons precies deze mail door, met die vraag. Het korte antwoord: dit is een beg bounty. Geen phishing die je wachtwoord wil, maar iemand die met een scanner duizenden sites afloopt en hoopt dat jij een beloning overmaakt.
Betaal niet. Maar gooi hem ook niet blind weg, want in dit geval zat er een randje waarheid in. Dat randje vond de afzender zelf niet.

Beg bounty: een bedelbrief met een scanrapport erin
Bij een echte bug bounty nodigt een bedrijf hackers uit om lekken te zoeken, met regels en een vast bedrag per vondst. Een beg bounty draait dat om. Niemand heeft je iets gevraagd, en toch komt er een rapport met een hint naar geld.
Beveiligingsbedrijf Sophos beschreef het patroon in 2021. Iemand scant automatisch naar simpele fouten en plakt de uitkomst in een vast sjabloon.
Volgens onderzoeker Chester Wisniewski loopt het van eerlijke meldingen met een voorzichtige hint naar een beloning tot “borderline extortion”: geld vragen zonder genoeg informatie om te controleren of het klopt.
De Australische bank CommBank zet de werkwijze op een rij. De afzenders gebruiken gratis tools als Nuclei, Shodan en SSL Labs, en mikken vaak op kleine bedrijven zonder eigen beveiligingsmensen. Een ontbrekende DMARC-regel of beveiligingsheader wordt “CRITICAL”.
Wie betaalt, krijgt vaak een vervolg: in één gedocumenteerd geval ging het bedrag van 500 naar 5.000 dollar, met een steeds grimmiger toon.

Hoe herken je het verschil met een echte melding?
Een echte beveiligingsmelding kan ook ongevraagd binnenkomen. Het verschil zit in wat erin staat en wat er gevraagd wordt. Leg de mail naast deze tabel.
| Let op | Beg bounty | Echte melding |
|---|---|---|
| Aanhef | “Hello [domein] Security Team”, of “Dear website owner” | Gericht aan jouw meldadres, vaak uit je bestand security.txt |
| Ernst | HIGH of CRITICAL in het onderwerp, zonder uit te leggen wat een aanvaller echt kan | Beschrijft stap voor stap wat iemand kan zien of doen |
| Bewijs | Een openbaar adres, een ontbrekende DMARC-regel of een versie van je software | Een concrete test op jouw site, met tijdstip |
| Geld | Vraagt naar een “bounty” of “reward”, of wil eerst weten of je betaalt | Vraagt hooguit of je het hebt opgelost |
| Toon | Steeds meer herinneringen, steeds feller | Geeft je tijd en noemt soms een datum waarop hij het openbaar maakt |
| Druk | “Andere bedrijven betaalden me hiervoor” | Niet nodig |
Die laatste rij is geen grap. Andreas Kling, de maker van de Ladybird-browser, deelde in februari een mail die opent met “I was awarded $300 by reporting the same issue to some other companies”. Zijn samenvatting op X: “beg bounty” fishing with a net. Een generiek verhaal, aan “undisclosed-recipients”, dus naar een hele lijst tegelijk.

Onder ontwikkelaars is het geduld op. “These aren’t our peers, they’re just losers”, schreef securityman Zack Korman in januari, als reactie op iemand die klaagde dat de hele beveiligingswereld kapot is door dit soort mails. Hij vergelijkt het met cryptoscammers: vervelend, maar geen bewijs dat het vak niet deugt.
De scanner had een punt, alleen niet het punt dat hij noemde
Terug naar de mail van 09:25. De afzender schrijft dat iedereen op het adres /oauth/register een eigen app kan aanmelden. Dat klopt. Zo’n open aanmeldadres heet Dynamic Client Registration, vastgelegd in RFC 7591. AI-assistenten als Claude en ChatGPT gebruiken precies die route om zichzelf als koppeling aan te melden bij een dienst.
Doe je het dicht, dan werkt de koppeling niet meer. Het “lek” is dus een functie.
Toch hebben we het niet bij weggooien gelaten. We maakten een testapp aan met een officieel klinkende naam en een nepadres als bestemming.
Daarna openden we het toestemmingsscherm, het scherm waar een gebruiker op “toestaan” klikt. Drie dingen vielen op:
- Bovenaan stond in grote letters de naam die de testapp zelf had verzonnen.
- Nergens stond naar welk domein je na je klik op “toestaan” gaat.
- Een gewoon http-adres zonder versleuteling werd als bestemming geaccepteerd.
Dat is een echte zwakke plek. Een oplichter kan je een link sturen naar het echte inlogscherm van een dienst die je vertrouwt, met daarop een app die zich voordoet als die dienst. Hetzelfde patroon heet OAuth consent phishing. Onderzoekers van Obsidian Security vonden in 2025 bij meerdere bekende bedrijven varianten waarmee één klik genoeg was om een account over te nemen. Ze publiceerden dat begin 2026.
De beheerder heeft het scherm nog dezelfde ochtend aangepast: het bestemmingsdomein staat er nu bij, onbekende apps krijgen een waarschuwing, en http buiten de eigen computer wordt geweigerd.
Het oordeel blijft staan. Wat deze afzender deed was geen onderzoek. Hij las een adres uit een openbaar bestand en plakte er een sjabloon onder. Het echte probleem zag hij niet, want daarvoor moet je inloggen en kijken wat een gebruiker te zien krijgt. Betalen voor zo’n mail beloont het verkeerde werk.
“Allemaal spam” is te makkelijk
Hier zit ook de zwakke plek van ons eigen advies. Wie elke ongevraagde melding als spam behandelt, mist de keer dat er wel iets is. Bij deze mail had de afzender gelijk over het verkeerde ding, en de beheerder vond het echte probleem alleen doordat hij zelf ging kijken. Niet betalen en niet antwoorden is goed. Niet kijken is dat niet.
Niet antwoorden, wel zelf kijken: vier stappen
- Niet antwoorden en niet betalen. Een antwoord bevestigt dat je adres gelezen wordt. Klik ook niet op links in de mail, ook niet als ze naar je eigen domein lijken te gaan. Twijfel je over een adres, link controleren kost een minuut.
- Zoek de claim zelf na. Typ het genoemde adres zelf in, of stuur de mail door naar je websitebouwer of hostingpartij. Gaat het om e-mailinstellingen, lees dan eerst wat SPF, DKIM en DMARC wel en niet doen. Een ontbrekende DMARC-regel is vaak een kwartier werk.
- Kijk wat een gebruiker op die plek ziet. Gaat het om inloggen, toestemming of een beheerderspagina, vraag dan: kan iemand hier mijn klanten of mij iets laten goedkeuren? Daar zat het echte risico in het voorbeeld hierboven. Verdenk je dat je beheeraccount al misbruikt is, lees dan dit patroon bij gehackte WordPress-beheerders.
- Zet een security.txt online. Dat is een klein tekstbestand op /.well-known/security.txt, vastgelegd in RFC 9116, met je meldadres en je regels. Zet erin dat je meldingen waardeert en geen beloningen betaalt. Het NCSC legt uit hoe een nette melding (CVD) werkt.
Werk je in een team en kwam de mail op een gedeeld adres binnen? Stuur hem dan door volgens je interne afspraak voor phishing melden, zodat niet drie collega’s los van elkaar gaan antwoorden. Een gewone verdachte mail check je met de stappen voor phishingmail controleren, en twijfel je bij een bericht, dan kun je altijd een vraag over phishing stellen.
Eén ding dat je vandaag nog kunt doen: open jouwdomein.nl/.well-known/security.txt in je browser. Krijg je een foutpagina, dan heeft een echte melder geen nette route naar jou, en heeft een beg bounty-jager niets om tegenaan te lopen. Vijf regels tekst lossen allebei op.
AI-koppelingen maken de inbox drukker
Elke dienst die AI-assistenten laat meewerken, krijgt aanmeldadressen als /oauth/register en een openbaar bestand dat ze opsomt. Scanners lezen dat bestand net zo makkelijk als Claude. Reken dus op meer mails over “unauthenticated registration” en vergelijkbare titels. De meeste zijn ruis. Het nuttige deel staat nooit in de mail: wat ziet een gebruiker vlak voordat hij op “toestaan” klikt? Wie dat scherm één keer zelf bekijkt, weet meer dan de afzender.
Wil je een mail eerst laten checken voor je iets doet? Op phishing checker vind je de route per type bericht.
