Aanvallers sturen authentieke phishingmails uit naam van registrar Namecheap

Het e-mailaccount van de registrar Namecheap is dit weekend overgenomen door criminelen. Die misbruiken het account om phishingmails uit naam van DHL en cryptovalutabedrijven te sturen. Mogelijk gebeurde dat via een e-mailmarketingplatform van een derde partij.

E-mails vanuit het primaire mailaccount van Namecheap worden sinds zondag verstuurd, schrijft BleepingComputer, dat verschillende van die berichten heeft ingezien. Gebruikers zeggen op Twitter dat zij phishingberichten krijgen van een e-mailadres van Namecheap. Dat lijkt legitiem te zijn, en niet te zijn gespooft of op een andere manier te zijn omzeild. Zo zouden de berichten met DKIM gevalideerd zijn. Namecheap bevestigt dat het ook zulke signalen van klanten ziet. Het bedrijf verwijst naar een supportpagina voor meer informatie.

Gebruikers zeggen dat er phishingmails uit naam van DHL en cryptovalutaplatform MetaMask binnenkomen. Daarin staat een link die afkomstig lijkt van Namecheap, maar waar gebruikers hun cryptovalutawalletinformatie of andere persoonsgegevens moeten invullen.

Namecheap zegt dat de eigen systemen niet gehackt zijn, maar dat de e-mails werden verzonden vanuit een derde partij. Dat zou Sendgrid zijn, een e-mailmarketingplatform dat eind vorig jaar gehackt zou zijn. Bij Sendgrid, maar ook bij alternatieven Mailchimp en Mailgun, zijn api-keys gelekt waardoor het mogelijk was accounts over te nemen.

Volgens Namecheap is dat waarschijnlijk de achtergrond van de phishingmails, maar het bedrijf zegt nog verder onderzoek te doen en in contact te zijn met Sendgrid om te verifiëren of dat klopt. Sendgrids moederbedrijf Twilio zegt tegen Bleepingcomputer dat er geen hack heeft plaatsgevonden op de systemen, maar zegt niet wat er dan wel is gebeurd en of gelekte api-sleutels als hack kunnen worden aangemerkt.

Reacties (54)

[Ro-Maniak2]

Legitiem is hier niet het juiste woord. https://www.vandale.nl/gr...rlands/betekenis/legitiem

“Seems totally legit” -> hebben wij geen één woord voor volgens mij.

[braboman]

Ik denk ook dat authentiek beter was geweest.

[TijsZonderH]

Authentiek is inderdaad beter. Het was bedoeld als tegenhanger van een gespoofte mail.

[sympa]

Geauthenticeerde misschien? Ze zijn niet authentiek, maar wel voorzien van echtheidskenmerken.

[djwice]

The email seems totally legit.

"De e-mail lijkt van een legitime afzender afkomstig."

Klinkt voor mij een passende vertaling.

Legitiem in de zin dat de afzender volgens de meest gebruikte automatische validatie mechanismen gerechtigd lijkt te zijn om namens de domeinnaam e-mail te versturen.

[Reactie gewijzigd door djwice op 23 juli 2024 13:12]

[gekkeh3nk]

Het is sowieso een erg verwarrend artikel. Wat heeft DHL bijvoorbeeld te maken met de e-mailadressen van Namecheap.

[kristofv]

Eigenlijk probeert men gewoon te zeggen dat gangbare anti spam mechanismen deze mails niet zullen flaggen (omdat ze qua sending mail server matchen met het spf record van namecheap).

Uiteraard zal een oplettende gebruiker, zoals jij dan aanhaalt, wel kunnen zien dat er hier iets niet klopt want dhl en anderen gaan idd in principe nooit mails uitsturen via de sendgrid instance van namecheap.

Dat is het probleem met phishing he :-) Als je dit al niet super duidelijk kan uitleggen op een tweakers pagina moet je niet vragen hoe onduidelijk het allemaal is voor jan met de pet ..

Edit: Dit soort shenanigans is ook waarom ik vanuit een beroepsperspectief (ben IT architect) al lang voorstander ben van een door de wet verplichte standaardisatie van automatische email correspondentie. Bijvoorbeeld:

Alles dat met marketing te maken heeft vanaf @sales.bedrijfsnaam.tld
Alles dat met support te maken heeft vanaf @support.bedrijfsnaam.tld

Dat zou het ook al veel eenduidiger maken voor eindgebruikers en veel makkelijker om phishing te spotten.

[Reactie gewijzigd door kristofv op 23 juli 2024 13:12]

[joker1977]

Ik begrijp niet wat een subdomein zou toevoegen aan de kwestie. Ook is het niet echt wenselijk om daar Engelstalige terminologie voor te gebruiken voor veel bedrijven (bedrijfjes).

En hoe zou dit tegen phishing helpen?

[kristofv]

That would help omdat nu @benaderdedomainname.tld een common tactic is.

Een subdomain is al wat meer werk, ten eerste.

Een bekende standaard maakt ook eindgebruikers meer attentief op, nu is het het wilde westen, iedereen doet maar wat.Onderschat nooit het effect van standaarden op de psyche van een doorsnee mens, bekijk het niet vanuit een tweaker bril.

Dat Engels is natuurlijk vatbaar voor afspraken, doch gezien Engels de facto voertaal is op het net lijkt me dat logisch. dit gaan fragmenteren op basis van een lokale taal "defeats the purpose" zoals ze in het Engels zeggen.

[joker1977]

Als je een e-mail adres gaat spoofen maakt het toch geen verschil dat er een subdomein wordt gebruikt ? Hoezo is "dat al wat meer werk" ?

De rest lijkt me eerlijk gezegd psychologie van de koude grond, gecombineerd met een gebrek aan inbeeldingsvermogen (of ervaring?) hoe de rest van de wereld communiceert. In zowel de Frans- als Spaanstalige wereld wordt er zeer zeker niet "standaard" gecommuniceerd in het Engels, zeer zeker niet. Mijn ervaring met Duitsers is niet veel beter op dat vlak.

Dat je die taal-barriere ziet als een "defeat the purpose" kan, maar ik zie jouw implementatie meer als een oplossing van een niet-bestaand probleem, d.w.z. het probleem is helemaal niet te tackelen door één of andere standaard te bedenken in afzender e-mail adressen.

[kristofv]

Heb ik ergens beweerd dat dat het een oplossing is?

Ik quote mezelf "Dat zou het ook al veel eenduidiger maken voor eindgebruikers en veel makkelijker om phishing te spotten."
Ik zie hier nergens de term oplossing.

Waarom een subdomein een andere zaak is dan een simpel tld is een technisch gegeven, Je kan (en dat is ook vaak zo) de email/dns config van een subdomein instellen los van een tld. Uiteraard houdt dat phishers niet tegen, niets kan dat, je kan het ze wel zo vervelend mogelijk maken. Security through obscurity is geen goed principe doch je moet roeien met de riemen die je hebt qua email. Phishers gaan voor lang hangend fruit.

Jouw redenering is meer van "er is geen echte oplossing" , wat klopt, dus doen we maar niets.

Edit: Nu ik er nog even bij stil sta, je opmerking omtrent "psychologie van de koude grond" is best ironisch. Hoe denk je dat leken nu proberen zien of iets phishing is. Inderdaad door de domeinnaam en de mail lettertje per lettertje te analyseren. Niets meer niets minder. Een standaard domeinnaam conventie helpt daar dus absoluut wel bij.

Je moet niet verwachten dat leken mx records en weet ik wat gaan vergelijken met mail traces, its never going to happen.

[Reactie gewijzigd door kristofv op 23 juli 2024 13:12]

[the_stickie]

Ik volg je redenering wel,...
Maar mij lijkt een oplossing in de wet bijna onmogelijk vanwege het internationale karakter van email en de vrijheden die nu bestaan tav domeinnamen. Het is bijna onmogelijk een dergelijke wet te handhaven: hoe ga je een Amerikaanse KMO/MKB verbieden handel te drijven met Nederland of België als ze een "fout" e-mailadres gebruiken?
Ook zouden spammers en phishers snel op dezelfde wagen zitten. Zie jij iets wat niet kopt aan deze: @ѕаlеѕ.bеdrіјfѕnааm.tld
(tip: zit vol met unicode lookalikes)
Een wet lost weinig op, het is de handhaving ervan die een verschil zou kunnen maken.

[Christoxz]

Via Sendgrid, onder het account van NameCheap worder er phising mails verstuurd namens DHL & MetaMask.

Dus ze gebruiken NameCheap account om 'legit' mails te versturen (Zodat het niet als spam komt), maar ondertussen heeft de inhoud niks te namen met NameCheap, want ze sturen het namens DHL/MetaMask.

Domain registrar Namecheap had their email account breached Sunday night, causing a flood of MetaMask and DHL phishing emails that attempted to steal recipients' personal information and cryptocurrency wallets.

The phishing campaigns started around 4:30 PM ET and originated from SendGrid, an email platform used historically by Namecheap to send renewal notices and marketing emails.

[Dooxed]

DHL is de bezorger van de emails.

[Yzord]

Als dat net zo goed gaat als het bezorgen van de pakketjes is dit al gedoemd te mislukken

[Madshark]

Hoeven mensen geen zorgen te maken, dan komen de berichten nauwelijks op tijd, als ze überhaupt aankomen.

[blorf]

Aannemelijk?

[Henrikop]

Als organisatie gebruik je vaak leveranciers om je mails te versturen.

In de DNS van jouw organisatie domein heb je bijv. een SPF record waarin staat dat je mails verstuurd vanuit SendGrid. Zo'n SPF record is van iedere organisatie zichtbaar.
Zo zie je dat Tweakers pardot en Google en een aantal (eigen?) IP adressen gebruikt:
https://mxtoolbox.com/Sup...tweakers.net&run=toolpage

Tweede stap is DKIM. Je toont hiermee aan dat de mails van jouw komen omdat ze gesigneerd worden van wederom jouw DNS. Ook dit kun je bij SendGrid aanzetten en die records stop je dan in je eigen DNS.

Zo heb je nog veel meer... maar als iemand jouw credentials heeft van SendGrid en de APIKEY dan kan iedereen mail versturen alsof ze echt van jouw organisatie af te lijken te komen. Vaak van korte duur omdat je altijd een reputatie moet onderhouden en als die ineens afwijkt, dan wordt je account even op slot gezet.

Dit is een aanval die we wel vaker zullen zien aangezien mitigerende maatregelen van mailproviders steeds beter werken.

[GoBieN-Be]

Kleine verbetering.
Ze worden niet gesigneerd van jouw DNS.
Je signeert ze met een private sleutel en de pubieke sleutel staat gepubliceerd in een DNS record zodat de ontvanger het kan controleren.

Doordat ze via DKIM gesigneerd waren, en indien dit via de key was die gebruikt werd door Sendgrid, en in combinatie met de SPF weet je dus al bijna zeker dat de mailsystemen van SendGrid ze gestuurd hebben.

[Reactie gewijzigd door GoBieN-Be op 23 juli 2024 13:12]

[Henrikop]

Thanks, details matter :-)

Organisaties zouden er alles aan moeten doen om te voorkomen dat andere authentieke mails kunnen versturen. Dit risico wordt nog onderschat en dan krijg je dit soort praktijken.

[RienBijl]

Ik heb een van de mailtjes gekregen. Het mailtje zelf zit enigzins goed in elkaar, het is verzonden door [e-mail]. De link in de mail lijkt ook enigzins legitiem, doordat deze naar een namecheap.com domein gaat.

De link zelf heeft een content die lijkt alsof het een Metamask link is. Vreemd dat dat niet geflagged is door Google als zijnde malicious.

Your wallet is about to be suspended

Apply for KYC Verification


Dear User,


We are writing to inform you that in order to continue using our wallet service, it is important to obtain KYC (Know Your Customer) verification. KYC verification helps us to ensure that we are providing our services to legitimate customers.


By completing KYC verification, you will be able to securely store, withdraw, and transfer funds without any interruptions. It also helps us to protect you against financial fraud and other security threats.

We urge you to complete KYC verification as soon as possible to avoid suspension of your wallet.

[Niet meer bestaande link hier]

Thank you for understanding. Sincerely

[Reactie gewijzigd door RienBijl op 23 juli 2024 13:12]

[Freekers]

Deze heb ik inderdaad ook ontvangen. Ik gebruik voor elke dienst waarvoor ik me aanmeld een unieke mail alias, dus het was makkelijk terug te herleiden wie de boosdoener was. De phising mail zelf was erg knullig. Hij was zogenaamd van DHL maar door de opmaak viel deze direct door de mand.

[Anoniem: 1576590]

Deze heb ik inderdaad ook ontvangen.

Het is interessant om te weten wat de domeinnaam was van de afzender, was dat iets als "mailings.namecheap.com"?

[beerse]

In deze is het dus de issue dat namecheap.com mail mocht versturen uit naam van andere domeinen: De afzender was dan wel degelijk van het verwachte domein. Alleen als je de header helemaal uit pluist op de mail-servers waar ze langs is geweest, dan blijkt ze helemaal niet op dat domein geweest te zijn maar dus wel begonnen op namecheap.com.

[Anoniem: 1576590]

Door beerse:

In deze is het dus de issue dat namecheap.com mail mocht versturen uit naam van andere domeinen: De afzender was dan wel degelijk van het verwachte domein.

Zo te zien lopen hier spams/phishingmails met verschillende afzenderdomeinen door elkaar.

In deze tweet schrijft de, zo te zien oorspronkelijke, melder Kathy Zant:

Beware of phishing emails coming out of @Namecheap’s @SendGrid account.
DHL, MetaMask, digitally signed with DKIM. [...]

Andere relevante details ontbreken.

Sendgrid beschrijft hier dat en hoe een klant, zoals in dit geval NameCheap, onder andere een CNAME DNS record moet maken voor bijvoorbeeld:
email.namecheap.com
waarbij verwezen wordt naar één of meer IP-adressen van Sendgrid.

Hiermee staat NameCheap dus toe aan Sendgrid om uit naam van NameCheap te opereren.

In de praktijk gaat het om nog een heel stel andere DNS-records (van NameCheap) waarin zaken geregeld moeten worden, namelijk voor SPF, DKIM en DMARC (en, hier niet van belang: "link branding").

Waar scammers misbruik van maken is het vertrouwen dat ontvangende mailservers van grote partijen hebben in emails met afzenderdomein (uit het voor de ontvanger zichtbare of zichtbaar te maken SMTP afzenderadres) *.namecheap.com, waarvan de authenticiteit van dat domein is onderbouwd met DMARC en ofwel een SPF-match ofwel een DKIM-match (zowel SPF als DKIM mag natuurlijk ook).

Door beerse:

Alleen als je de header helemaal uit pluist op de mail-servers waar ze langs is geweest, dan blijkt ze helemaal niet op dat domein geweest te zijn maar dus wel begonnen op namecheap.com.

In theorie zorgen DMARC alsmede SPF en/of DKIM ervoor dat je geen headers hoeft uit te pluizen.

Wat hier, zo te zien, fout ging, is de combinatie van:

1) NameCheap staat Sendgrid toe om email uit naam van NameCheap te versturen;

2) Een scammer kon zich, t.o.v. Sendgrid, voordoen als medewerker van NameCheap (en mogelijk andere Sendgrid klanten), en zo e-mails namens NameCheap verzenden via de servers van Sendgrid.

Aanvulling 11:55: steeds meer mail clients (Apple iOS/iPadOS mail voorop?) laten het SMTP-afzender adres standaard niet zien (ook in bovengenoemde tweet is dat niet zichtbaar). Het uitgangspunt is kennelijk dat als een afzenderdomein betrouwbaar lijkt, het niet meer boeit om welk afzenderdomein het gaat; "het zal dan vast geen phishing-mail zijn". En dus kan een scammer bijvoorbeeld "straffeloos" als afzender gebruiken:
"DHL" <[e-mail]>
Het doel hierbij is het passeren van spamfilters van grote e-mail providers.

Edit 13:05: fixed typo "/url" -> "/i"

Edit 16:15: Sendgrid lijkt te zijn gehacked, NameCheap is zo te zien niet de enige klant van Sendgrid wiens afzenderdomein is misbruikt in phishing-mails (verzonden via Sendgrid servers); meer info.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 13:12]

[Freekers]

Nee, de afzender was '[e-mail]'

[Anoniem: 1576590]

Nee, de afzender was '[e-mail]'

Dank, dan was dit, denk ik, niet hetzelfde als wat BleepingComputer wist te melden.

[Anoniem: 1576590]

Nee, de afzender was '[e-mail]'

Aanvulling en correctie op mijn vorige reactie aan jou.

Sendgrid lijkt stevig gehacked, want niet alleen NameCheap-klanten ontvingen phishing-mails, jouw mail lijkt met dezelfde hack te maken te hebben:

playable.video gebruikt Sendgrid als bulkmailer, zo blijkt uit hun SPF record. Ook publiceert playable.video een DMARC record.

Zelf ontving ik een "DHL" phishing-mail van hostirian.com (zat in mijn spambox zag ik zojuist) eveneens met sendgrid in SPF (zo te zien heeft hostirian.com geen DMARC record).

Sorry als mijn eerdere reactie verwarrend was!

[Sluuut]

Voor jou misschien wel, maar voor andere gebruikers kan dit er als legitiem uit zien en komen hackers op deze manier binnen.

Ik vind het wel zorgelijk dat relatief grote 3e partijen als Sendgrid gehacked worden. Je neemt ze op in je SPF en laat een DKIM key meesturen, dus ze mogen vertrouwd uit naam van jouw domein mailen. Vervolgens worden ze gehacked en gaat jouw domein reputatie omlaag.

Wellicht is een geauthenticeerde relay die door een “email wasstraat” gaat toch beter.

[Anoniem: 454358]

Met een api key kun je natuurlijk vrijwel alles bij dergelijke systemen.
Als die key dan wordt gelekt heb je wel een probleem.
"Hoi dev team, Sandra van marketing hier, Kun je mij even de sendgrid api key sturen? Wij zijn met een klein projectje bezig, groetjes"

[cricque]

Kan je gerust een key aanmaken met restricties op. Geen probleem mee dat marketing even een key wenst, maar dat ga ik toch eerst effe verifiëren hoe ze het willen gebruiken. Natuurlijk gaat niet iedereen dit doen, maar dat zou de reactie moeten zijn

[HuginR]

Met een api key kun je natuurlijk vrijwel alles bij dergelijke systemen.

Ik hoop het niet. Bij dergelijke systemen zouden aan api keys restricties verbonden moeten zijn zodat een afnemer met een api key niet meer kan doen dan wat nodig is. En keys moeten niet worden gedeeld. Iedere afnemer kan een eigen key krijgen.

Als die key dan wordt gelekt heb je wel een probleem.
"Hoi dev team, Sandra van marketing hier, Kun je mij even de sendgrid api key sturen? Wij zijn met een klein projectje bezig, groetjes"

Tja, als een key wordt gelekt dan wordt die ingetrokken. Dan moet dev team bij zichzelf te rade gaan hoe hun key is gelekt (misschien volgende keer toch beter niet de key naar Sandra van marketing sturen)

[phosporus]

Bij Sendgrid, maar ook bij alternatieven Mailchimp en Mailgun, werden api-keys gelekt waardoor het mogelijk was accounts over te nemen.

En deze op enige wijze revoken en nieuwe aanmaken is niet mogelijk geweest?

[Anoniem: 454358]

Natuurlijk wel, met een klik is de oude code ongeldig.
Maar als je zelf een software pakket hebt ontwikkeld, en de api code daar dan tientallen,/honderden keren 'hard' in verwerkt, dan werkt je code niet meer

[Jantimon]

Als je gaat hardcoden dan ben je sowieso niet heel lekker bezig. Zoiets kan je prima middels een database of variabele onthouden.

[Wraldpyk]

Dit zijn inderdaad keys die in een environment variable opgeslagen moeten worden, maar helaas zijn niet alle ontwikkelaars, of managers, zo slim. Dus wanneer deze fout een keer gemaakt is heb je al een probleem.

[phosporus]

Zelfs dan is een zoek vervang actie toch nog een oplossing. Gewoon afwachten totdat de slechte mensen er misbruik van gaan maken lijkt mij toch een verrekt slechte keuze.

[IStealYourGun]

Je ziet tegenwoordig vaker dat third-party systemen worden overgenomen en mails verstuurd worden vanuit die accounts. Vaak omdat die accounts gedeeld (moeten) worden en dus makkelijk wachtwoord hebben en geen mfa. En als je al de optie hebt om meerdere accounts aan te maken, dan is het vaak nog steeds een challenge om al die accounts te beheren.

Aanvulling: tegenwoordig open ik nog zelden URL's in mails. Als er een bericht klaar staat of iets dergelijks, dan ga ik gewoon naar de website en meld ik mij daar aan om het bericht te bekijken.

[Reactie gewijzigd door IStealYourGun op 23 juli 2024 13:12]

[Anoniem: 1576590]

Aanvulling: tegenwoordig open ik nog zelden URL's in mails. Als er een bericht klaar staat of iets dergelijks, dan ga ik gewoon naar de website en meld ik mij daar aan om het bericht te bekijken.

Dat is verstandig, maar helaas kan dit niet altijd, namelijk als je geen account hebt op de kennelijk betreffende website.

En als je wél een account hebt op de kennelijk betreffende website, en het daadwerkelijk om phishing gaat, zit het er dik in dat je de in de e-mail beschreven info niet kunt terugvinden op de betreffende website. En je dus alsnog in de verleiding zou kunnen komen om op de link in de mail te klikken.

Omdat zo'n phishing link bijna altijd allerlei onbegrijpelijke tekens in de URL achter de domeinnaam heeft, en je dat soort links ook ziet als je een wachtwoordreset uitvoert (via "wachtwoord vergeten"), ligt het voor de hand dat je meteen op de juiste plaats uitkomt door op de link in de e-mail te klikken.

M.a.w. niet-doordenkers worden geconditioneerd om op links in e-mails te klikken, want meestal is dat handig en werkt het gewoon.

[jeroen79]

En als je al de optie hebt om meerdere accounts aan te maken, dan is het vaak nog steeds een challenge om al die accounts te beheren.

Maar waarom zou dat een challenge zijn?
Kwestie van bijhouden aan wie je een account verstrekt en waarvoor.

[IStealYourGun]

Offboarding van users durft wel eens mis te lopen. Als ze je niet op de hoogte brengen dat iemand het bedrijf heeft verlaten of je hebt niet verantwoordelijk voor het beheer van die omgeving, dan blijft dat account gewoon bestaan.

Het zou niet mogen, maar het komt toch te vaak voor.

[jeroen79]

Dan kom je weer uit op het bijhouden.

Als ik noteer dat ik voor Jan een account voor systeem X heb aangemaakt dan heb ik vanzelf een los eindje dat pas is opgelost wanneer ik noteer dat ik dat account heb gesloten.
Als ik dan hoor dat Jan uit dienst is hoef ik alleen maar op de bij hem horende losse eindjes te zoeken.

[kodak]

Waaruit blijkt 'vaker'? Want het gebruiken van officiële accounts, van directe of voor indirecte maildiensten, werd al gedaan sinds ze in gebruik zijn. Dat was ook de kritiek op spf of dmarc.

[jpsch]

Ah, vandaar die vele DHL mails.

[Kees-Jan]

Sinds wanneer zijn PhishingMails "legitiem"?

[cadsite]

Dat zou eventueel kunnen, bijvoorbeeld de IT afdeling die controleert hoe de collega's reageren op phising, maar hier was het inderdaad een compleet foute vertaling.

[Wraldpyk]

De mails zelf zijn niet legitiem, maar de manier waarop de mails verzonden zijn wel, oftewel niet via spoofing

[cadsite]

Een "legitieme phishingmail" die toch niet legitiem is.
Eigenaardig...