Aanvallers sturen valse supporttickets vanaf e-mailadressen Discord en Tinder

Cybercriminelen kunnen door een authenticatieprobleem in helpdeskdienst Zendesk misleidende supportverzoeken sturen uit naam van bekende bedrijven. Onderzoeker Brian Krebs kreeg eerder deze week 'duizenden' e-mails van adressen van onder meer Capcom, Discord en Tinder.

Krebs schrijft dat hij deze week duizenden meldingen heeft ontvangen over tickets die door hem zouden zijn aangemaakt. De aanvallers versturen de berichten van domeinnamen van klanten. Zij kunnen zelf kiezen welke onderwerpregel het bericht krijgt. Zo kreeg Krebs een bericht van het e-mailadres van de Washington Post over een zogenaamd noodverzoek van wetshandhavers om gegevens.

Zendesk verklaart dat de aangemaakte tickets afkomstig zijn van klantaccounts die zo zijn ingesteld dat iedereen ondersteuningsverzoeken kan indienen, ook anonieme gebruikers. Een woordvoerder zegt dat het bedrijf zijn klanten aanbeveelt om alleen geverifieerde gebruikers toe te staan om tickets in te dienen. Sommige klanten kiezen er echter om 'verschillende zakelijke redenen' voor een anonieme omgeving te gebruiken waarin iedereen tickets kan aanmaken.

Zendesk beweert dat er limieten zijn ingesteld om te voorkomen dat in één keer een groot aantal verzoeken wordt aangemaakt. De woordvoerder erkent dat dat de aanval tegen Krebs niet heeft tegengehouden en onderzoekt 'aanvullende preventieve maatregelen'. Het is niet duidelijk om welke maatregelen het precies gaat.

Een van de berichten die Brian Krebs deze week kreeg. Bron: KrebsonSecurity

Reacties (27)

[grote_oever]

Ik heb ook één van deze mails gehad. De mail die ik heb gehad was van NordVPN en zag er volledig valide uit. Wel grappig, ik ben nooit klant geweest bij hun.

##- Please type your reply above this line -##

Hello there,

Thank you for contacting us. A support ticket has been opened for your request, and we will get in touch with you directly by email. To add any additional comments, please reply to this email. If you have not submitted any requests to our support team, please ignore this e-mail.

In the meantime, we suggest you review our Help Center for frequently asked questions and the latest information about NordVPN: https://support.nordvpn.com/.

Due to high number of requests there might be a delay in our response. We are doing our best to get back to you soon.

Kind regards,

NordVPN Support & Customer Care team

This email is a service from NordVPN.

[Reactie gewijzigd door grote_oever op 18 oktober 2025 13:42]

[faim]

Nou ja valse support tickets? Als ik bij een webshop iets bestel en ik vul een ander e-mailadres in bij de checkout, krijgt die persoon ook gewoon een email van die webshop. Als ik een contactformulier op een website invul en ik vul een ander e-mailadres in, krijg die persoon ook gewoon een kopie van het bericht. Dat is hetzelfde als dat hier gebeurt, om dit nou een 'authenticatieprobleem' te noemen...

[kodak]

Het is in de EU al jaren bij wet verboden om zomaar persoonlijke gegevens te gaan verwerken. En dat is ontstaan nadat er eerst al jaren problemen waren dat wel te doen, zoals om mailadressen die niet van de invuller zijn te misbruiken voor spam en andere criminele handelingen. Precies wat hier weer mis gaat.

Dit is niet slechts een probleem door bedrijven die klant van zendesk zijn. Zendesk hoort geen producten en diensten te leveren die persoonlijke gegevens maar klakkeloos accepteren om hoe dan ook maar te kunnen gebruiken. Ratelimiting is geen voorkomen van illegale verwerking, dat is vooral het proberen te voorkom dat het bedrijf zelf minder klachten krijgt over illegale verwerking.

[Reactie gewijzigd door kodak op 19 oktober 2025 14:10]

[faim]

Dit is onzin, zonder een e-mailadres te verwerken kan je nooit verifiëren dat deze van iemand is. Bij elk registratieformulier op een website wordt een e-mailadres gevraagd, bij elke website zul je een e-mail krijgen met een activatie link, volgens jou definitie is dit al 'klakkeloos accepteren' en verwerken.

[GoBieN-Be]

Een activatielink is net wel verifiëren dat iemand toegang heeft tot het e-mailadres dat hij opgeeft.
Dus eerst activatielink en daarna pas kunnen ticket indienen of bestelling doen of ...

[faim]

Maar dan 'verwerk' je dus al een e-mailadres en krijgt deze een email. Dus als ik een random e-mailadres invul, krijgt deze persoon mail. Hoe is dat anders?

[bigcookie]

Random e-mailadres van iemand anders gebruiken word gezien als het misbruiken van deze persoon zijn/haar persoons gegevens onder the AVG en daarvoor zou jij een boete kunnen krijgen.

[kodak]

Ik stel niet dat het helemaal niet mag. Ik stel dat het verwerken niet zomaar mag. Er zijn uitzonderingen, zoals om de gegevens direct te kunnen controleren op fouten voor er verdere verwerking plaats heeft.

[robvanwijk]

zoals om mailadressen die niet van de invuller te misbruiken voor spam en andere criminele handelingen. Precies wat hier weer mis gaat.

Nee, dat is juist niet wat hier gebeurt. Waar jij op doelt is dat ik mijn eigen emailadres invul en degene die dat formulier ontvangt mijn adres misbruikt voor spam. Wat hier gebeurt is dat iemand anders mijn adres gebruikt (en claimt dat het zijn eigen adres is), waarna de ontvanger dat adres gebruikt precies waarvoor het bedoeld is. In het eerste geval is het bedrijf in overtreding, in het tweede geval is de spammer (die nooit gepakt gaat worden...) in overtreding. Dat is echt wel een wezenlijk verschil.

[kodak]

Misschien dat het woord 'zijn' ontbrak, maar het 'niet van de invuller' verwees al naar dat een ander de persoonlijke gegevens aan het invullen was. We bedoelen dus hetzelfde.

[darkfader]

Anoniem? dat zal dan wel effectiever zijn geweest qua kosten o.i.d.

[blinchik]

Een stukje er van snap ik het wel. Als je een gebruiker laat inloggen om een supportticket aan te maken ben je zeker dat het die gebruiker is. Maar als hij geen toegang meer heeft tot zijn account kan hij dan geen support ticket aanmaken.

Vandaar lijkt het me zinnig dat je support kan bereiken zonder in te loggen (dus: anoniem). Maar het lijkt me dan wel beter dat je enkel support kan bereiken met zo'n vraag, al zeker geen onderwerp zelf kan invullen, en dat je voor andere support wel moet inloggen.

[Cyberpuppy]

Plus dat als een gebruiker bijv. geen toegang meer heeft tot zijn email men nog wel eens een prive adres wil gebruiken. Altijd handig als andere manieren niet werken.

[Jeoh]

Ik ga er even van uit dat Krebs nog steeds [e-mail] gebruikt. In dat geval zou je ook de vraag aan Google kunnen stellen waarom ze nog steeds een softfail in hun SPF-record hebben. Of geen reject in hun DMARC-record. Dan kan Zendesk netjes de gespoofde mails aan de poort weigeren.

[GoBieN-Be]

Jij gaat er van uit dat het aanmaken van het support request per e-mail (met het spoofen van Krebs adres) gebeurt. Ik lees dat echter niet terug in het artikel of de bron. Ik ga er van uit dat het web formulieren zijn dat men invult waarbij men het e-mailadres van Krebs invult.

[Kristof Vxx]

De vraag is nu wat het grotere probleem is dan wat onnodige mails te krijgen?

Wat kan de “aanvaller” nu winnen bij het ingeven van een geldig mailadres op een ander systeem. Het bedrijf krijgt een nutteloos ticket en het mailadres krijgt een nutteloze mail.

Buiten tijdverlies aan beide kanten zie ik de meerwaarde niet. Of zie ik het te eenvoudig?

[R_Zwart]

Het aangevallen/misbruikte bedrijf kan een slechte naam krijgen omdat veel ontvangers niet weten hoe het zit. Plus dat de hoeveelheid werk bij het aangevallen bedrijf piekt en het tijd kost om echte en nep tickets uit elkaar te halen.

[MiesvanderLippe]

Zullen we gewoon een keer e-mail2 ontwikkelen en dan alle problemen fixen?

[duvekot]

Zullen we gewoon een keer e-mail2 ontwikkelen en dan alle problemen fixen?

https://xkcd.com/927/

[Llopigat]

In dit geval is er maar 1 standaard en die is door en door verrot en kapot. Dus op zich zou een grote gezamenlijke standaard geen slecht idee zijn.

[moonlander]

Als de aflevering van email nou eens goed gaat dan is er niks aan de hand en bedrijven ook echt controleren of de mail echt afkomstig is van de betreffende gebruiker . Maar Microsoft met Outlook, hotmail of live adressen komen sommige mails nog steeds in de spam of komen helemaal nooit aan. En dan kun je als die gaan van een domain spf, dmarc etc allemaal goed instellen.. maar toch krijg ik heel veel klachten dat mail niet aankomt. Voornamelijk door de email dienst van microsoft. En dan snappen mensen ook nog eens niet hoe mailboxen werken, voornamelijk ook weer van microsoft. Dan staat het mailtje perongeluk in het foldertje promotie oid..

[Llopigat]

Dat klopt. Had ik ook last van. Microsoft heeft een ongelofelijk vervelende spam detectie die alleen kijkt naar 'reputatie' van hoeveel legitieme mail je stuurt per maand.

Het vervelende is dan dat als je maar 1 of 2 mailtjes naar hun consumenten accounts stuurt per maand, je geblokkeerd wordt omdat je niet genoeg reputatie hebt, ondanks dat je nooit ook maar 1 spam gestuurd hebt.

Je kan het dan laten ontblokkeren, dan moet je langs een of andere indier. Maar een maand later zit je weer in de blocklist. Grrr.

Ik heb een beetje het vermoeden dat ze dit expres zo moeilijk maken om het te ontmoedigen dat mensen zelf mailservers draaien. Want mail hosting is natuurlijk een van hun lucratieve diensten.

Als je stuurt naar zakelijke M365 accounts gebeurt het niet. Alleen consumenten (live.com, hotmail.com, outlook.com).

[Reactie gewijzigd door Llopigat op 18 oktober 2025 21:19]

[drdelta]

We hebben oa. SPF, DKIM, DMARC en BIMI, die het gros van alle problemen al voorkomen. Als mensen dat gewoon eens zouden gebruiken was er al een stuk minder aan de hand.

[Bor]

Aan de andere kant toon je hier goed het nadeel van SMTP aan. Wil je het relatief veilig maken dan heb je pleisters als SPF, DKIM en DMARC nodig waarbij je op alle plekken fouten kan maken (en dat gebeurt in de praktijk dan ook) en waarvoor je technische kennis nodig hebt. Het is niet fool proof, niet iedereen gebruikt het en het zijn eigenlijk allemaal lapmiddelen omdat het originele protocol nooit ontworpen is met security in gedachten of als doel.

[robvanwijk]

We hebben oa. SPF, DKIM, DMARC en BIMI, die het gros van alle problemen al voorkomen. Als mensen dat gewoon eens zouden gebruiken was er al een stuk minder aan de hand.

Daar heb je tot op zekere hoogte een punt.Toch voelt het als een wat vreemde reactie onder een nieuwsartikel over een probleem dat door geen van die technieken voorkomen kan worden. In dit geval is de verzender van de email niet het probleem, maar de claim "ik ben jantje@hotmail en ik heb support nodig" die (zonder enige vorm van verificatie) zorgt voor het versturen van een email die zeer verwarrend en misleidend overkomt.

Met andere woorden: het probleem hier is niet het versturen, authenticeren, afleveren, ... van email ("de techniek achter email"), maar de inhoud van de email. En daar kan het emailsysteem niets aan doen; dat moet email, ongeacht de inhoud, gewoon netjes afleveren. Als de subject iets als "[Washington Post] Your support ticket #123456 has been created" zou zijn, met in de body eerst een inleidende paragraaf, dan expliciet "dit is wat u ons hebt gevraagd" en dan, duidelijk afgebakend, de tekst die de aanvaller vrijelijk kan kiezen, dan is het probleem grotendeels opgelost. Bonuspunten als ze ook nog ergens vermelden "als u geen idee hebt waar dit over gaat, dan heeft iemand anders zijn emailadres verkeerd getypt en dat was toevallig uw adres". En dat alles zou geen enkele technische verandering vereisen, alleen dat iemand net wat beter nadenkt over het email template dat ze gebruiken.

[devilkin]

Een twintigtal binnengekregen...

[qlum]

Als dit zo werkt als bij Freshservice, wat wij voor werk gebruiken kan je dit als volgt doen:

Tickets worden aangemaakt naar hand van het reply-to-adres en niet de afzender, iedereen kan een ticket aanmaken. SPF, DKIM en dergelijke komen hier niet bij kijken. Je kan dus in naam van ieder e-mailadres een ticket aanmaken.

Dit is vooral ingesteld zodat je makkelijk mailtjes van andere kanalen kan doorschieten naar tickets, komt het meteen onder de juiste persoon uit. Maar ja, voor een groot bedrijf als Discord is dit misschien niet zo verstandig.

Verder hoewel dit niet zonder risico is, is het risico beperkt. Je krijgt alleen een automatisch antwoord te zien, verder hangt het af van de opvolging van het bedrijf. Als zij alleen maar terugmailen dan krijgt de aanvaller die mails niet te zien. Je kan er geen spam in kwijt, want je ziet alleen meteen het automatisch antwoord.

[Reactie gewijzigd door qlum op 19 oktober 2025 10:15]