Mailinglijst blog Have I Been Pwned-oprichter gelekt door phishingmail - update

Troy Hunt, de oprichter van datalekzoekmachine Have I Been Pwned, is het slachtoffer geworden van een phishingmail. Hierdoor is een mailinglist van Hunts blog gelekt. De geëxporteerde Mailchimp-lijst bevat zestienduizend records.

Hunt schrijft dat de phishingmail in kwestie leek alsof het afkomstig was van e-mailmarketingdienst Mailchimp. De mail meldde dat het versturen van e-mailberichten was beperkt en vroeg de beveiligingsonderzoeker om zijn account te controleren. Hunt opende de link, logde in met zijn gegevens en voerde een 2fa-code in.

Toen hij merkte dat de pagina na het invoeren van de one time password bleef hangen, 'viel het kwartje'. "Ik logde daarna in op de officiële website van Mailchimp. Die stuurde een bevestigingsmail die mijn IP-adres in Londen liet zien. Ik heb mijn wachtwoord meteen gewijzigd, maar kort daarvoor kreeg ik een melding dat mijn mailinglijst werd geëxporteerd vanaf een IP-adres in New York", schrijft Hunt.

De HIBP-oprichter zegt dat hij kort voor de publicatie van de blogpost de mailinglijstabonnees op de hoogte heeft gebracht. Hunt zegt dat er ook mailadressen in de geëxporteerde lijst stonden van oud-abonnees die zich hebben uitgeschreven. Hij zegt dat hij 'zo snel mogelijk' zoekt naar een manier om contact op te nemen met deze mensen. Waarom Mailchimp de gegevens van oud-abonnees bewaart, weet Hunt niet. De beveiligingsonderzoeker zegt dat hij contact heeft opgenomen met de dienst.

Verder biedt Hunt zijn excuses aan en raadt abonnees aan om extra alert te zijn op phishingmails en spam. Inmiddels is de valse Mailchimp-site offline gehaald door Cloudflare.

Aanpassing, 16.21 uur - In het originele bericht stond dat er een mailinglijst van Have I Been Pwned was gelekt. Dit klopte niet, want het gaat in dit geval om een mailinglijst met abonnees van Troy Hunts blog. Daarom is het artikel aangepast.

Reacties (90)

[Anders]

Hierdoor is de mailinglijst van HIBP gelekt.

Nee. Zie
https://www.troyhunt.com/...-list/#comment-6676222186

Fortunately, this is just the mailing list for this blog and is totally separate to anything HIBP related

[LFranxWind]

Ai, helemaal over het hoofd gezien. Ik heb het artikel aangepast en voorzien van een update. Bedankt voor het doorgeven!

[FanaticNL]

Klinkt als een soort slapstick grap... Kunnen ze zichzelf melden op hun website.

OT: Zo zie je maar weer, iedereen kan in phishing trappen en een fout is zo gemaakt. Zelf door mensen waarvan je mag verwachten dat ze veel met privacyzaken bezig zijn. De mens blijft een zwakke schakel in de (online)beveiliging.

[Alex3]

Die kans is groot als je handmatig inlogt in plaats van een wachtwoordmanager te gebruiken. Die vult je gegevens niet op nepsites in.

[Heedless]

Hij gebruikt wel een wachtwoordmanager: "[I] entered my credentials which - crucially - did not auto-complete from 1Password".

Onverwachte email, domeinnaam die niet gewoon mailchimp.com is, 1Password autocomplete niet...
Iedereen is menselijk en kan onder de juiste omstandigheden in dit soort phising zaken trappen, maar dit waren toch wel heel veel red flags zou je denken?

[PolarBear]

Nou ja er zijn genoeg sites die meerdere url's gebruiken waardoor auto complete niet altijd werkt.

[Heedless]

Ja, dat overkomt mij ook weleens maar dat is meestal wel weer een trigger nog eens goed te kijken of het klopt. Bijvoorbeeld door de afzender van de mail nog eens te bekijken, wat in dit geval hr@ een random .be website was.

Nogmaals, iedereen kan er intrappen onder de juiste omstandigheden, maar moe zijn was in dit geval blijkbaar genoeg om een HOOP over het hoofd te zien.

[Zoop]

Eigenlijk een gewoonte van maken nooit op een link in een email te klikken, als MailChimp mij iets te melden heeft, dan kan ik dat vast zien als ik inlog op de reguliere manier, net als dat je een bericht van mijnoverheid krijgt, ga zelf kijken, klik niet op iets in mail. Als er dan blijkt meer aan de hand te zijn met de link (buitenom mailchimp, zijn vast apps die soort onetime logins sturen en wetransfer achtige dingen) is dat een drempel om je uit de automatisme te halen en even wat kritischer te kijken naar hetgeen wat je net hebt gekregen.

[Reactie gewijzigd door Zoop op 25 maart 2025 22:56]

[nzall]

Group-f is een Belgisch bedrijf dat schoonmaakdiensten aanbiedt aan bedrijven en consumenten. Ik ben zelf ook klant bij hun, via hun strijkatelier.

[tszcheetah]

Zoals je zegt, de omstandigheden waren in dit geval juist: Troy was moe en had een jetlag. Dan vallen de red flags niet direct op.

[Vinnie.1234]

Behalve dat bijna elke grote dienst weer 10 verschillende domeinen heeft of weer net iets veranderd waardoor de link niet meer werkt. Hoe vaak ik alsnog handmatig moet zoeken naar een wachtwoord omdat die de link weer is niet kan vinden.

[sterkeronline]

Yes, zoals het inloggen op ieder Microsoft domein, wat een verschikking is dat zeg.
1Password raakt daar aardig overstuur van en ik zelf ook.

[Blokker_1999]

Microsoft login is toch echt altijd vanuit hetzelfde domein, ongeacht op welke van de duizenden websites je aanmeld bij hen.

[Korvaag]

Ja en dat is hier juist het issue. Autocomplete staat daar bewust dus uit omdat ik een account heb voor m'n werkgever en sowieso drie klanten. Gaat ie bij elke Microsoft inlog proberen in te loggen met m'n werkaccount en het verschilt per keer wat ik wil. Andere password manager dan 1Password trouwens.

[Davey400]

Dit is dan weer eenvoudig op te lossen door losse browser-sessies te maken waarbij je voor de hele sessie aan die tenant gekoppeld zit. In Edge zijn dat ‘werk of school’-profielen.
Chrome heeft hier ook een variant op waarmee je functioneel hetzelfde kunt.
Je accounts/passwords zijn dan alleen binnen dat profiel beschikbaar en sessies (voor verschillende klanten) lopen niet meer door elkaar.

[Zoop]

Wat prima is als je een handjevol accounts te beheren heb, ik heb er zelf letterlijk honderden. Dus ga ik echt niet klooien met profielen. Incognito en handmatig inloggen werkt dan nog het best.

[Zoop]

Dat is ook zo vreselijk met Google diensten, ik doe dat soort dingen eigenlijk altijd incognito, want als de Google dienst eenmaal door heeft dat je ergens op ingelogd bent, dan kan je uitloggen of van account wisselen wat je wilt, zodra je ergens naar redirect wordt, zit je weer doodleuk op dat eerdere account.

[sterkeronline]

Dat ligt er aan welke toepassingen je gebruikt.
Probeer maar eens in te loggen op Microsoft Clarity, Microsoft Bing Console en Microsoft Advertising.

[jimzz]

Een beetje wachtwoordmanager laat je meerdere domeinen opslaan onder 1 inlog, als je dat voor alle services 1x hebt gedaan is het probleem opgelost.

[Hardfreak]

Ja en nee. Je start de login niet altijd van hetzelfde domein, zo kan je bijvoorbeeld je e-mail adres al ingeven op https://onedrive.live.com/login, die brengt je dan naar https://login.live.com om effectief aan te melden met je credentials (voor persoonlijke accounts). Voor corporate credentials ga je dan weer naar je eigen STS domein om je credentials in te geven.

[sterkeronline]

Dit is het exacte probleem inderdaad, ik ben dus toch niet de enige :-)

[RobertMe]

Ter referentie, bevat Bitwarden deze lijst onder een "Domain rule", waarvan die dus alle domeinen als 1 behandeld (en een password entry met een van deze (top level) domeinen dus als auto-fill gebruikt kan worden op al deze domeinen):

bing.com, hotmail.com, live.com, microsoft.com, msn.com, passport.net, windows.com, microsoftonline.com, office.com, office365.com, microsoftstore.com, xbox.com, azure.com, windowsazure.com

Nu is mijn ervaring ook dat Microsoft vaak redirect naar 1 entry-point / authenticatie portal. Maar Bitwarden zal die lijst vast niet voor niks bevatten.

[mjl]

Mijn ervaring is dat dit niet vaak voorkomt.

[CivLord]

Mijn ervaring is dat het regelmatig voorkomt.
Maar bijna uitsluitend wanneer ik door een re-direct of een link op een dergelijke site terecht kom. Dan staat er iets voor of na het standaardadres waardoor de passwordmanager de site niet herkent.
Wanneer je het adres van de site zelf in de browser intikt heb je er geen last van.

[Alex3]

Dan zoek ik naar andere inloggegevens met hetzelfde wachtwoord. Andere wachtwoordmanagers kunnen domeinen koppelen.

[knokki]

Wel passwordmanager gebruikt. Zie bijdrage hieronder van RobertMe:
"Edit: Blogpost gescand. Blijkbaar wel een password manager gebruikt, 1password. En die "triggerde" dus ook niet de auto complete / auto fill. En vervolgens heeft hij zelf geen dubbel / trippel check gedaan "omdat het wel vaker voor komt dat die niet werkt" (websites die authenticatie op meerdere domeinen hebben / meerdere entry points van authenticatie). Blijft IMO toch slordig."

[dipje2]

to be honest, mijn password manager is een losse tool, dus 'ik zoek wachtwoorden nog steeds op' in mijn password manager, heb 'm niet in de browser zitten of zo. Dus ik zou hier ook zo intrappen.

[haam]

Inloggen via een link in een email is volgens mij de eerste fout. Maar ja, het is altijd makkelijker om lui te zijn dan veilig.

De vraag is ook of iedereen zich de juiste vraag stelt als een wachtwoordmanager het niet automatisch invult.

[Gunneh]

Werk nu al 5 jaar in cyber security field en ik had vorige week de DocuSign phishing email. Moest toch echt eventjes 3x kijken en DocuSign checken of het legitiem was.
Zelfde met een PayPal phishing.

Al die mensen van "Pfff ze zijn er zelf ingetrapt! Zou mij nooit overkomen!"? Ja, tot je het wel doet.

[Jelle Brolnir]

Ja, mensen hebben daar graag een grote mond over. Phishing berichten worden tegenwoordig ook fysiek door je brievenbus geduwd, vond de brief van digid bij mijn ma in de bus best legit. Het is dat ik haar al eens gewaarschuwd heb geen qr codes te scannen met een dringende toon ervoor (want er is altijd een "je moet handelen" toon) anders was ze mooi de sjaak, ik moest ook twee keer kijken. Bizar hoe ver men gaat inmiddels. Het is mij nog nooit overkomen (buiten credential leaks...linkedin enzo...) maar de kans dat het mij wel eens gaat gebeuren is een stuk groter dan niet.

[Gunneh]

De dingen die ik hoor van onze klanten is soms eng. Bv eerst phishing via telefoon, dan komt er ineens 'iemand van de bank' alles ophalen (telefoon, laptop, cash, juwelen etc). Als mijn oma ineens een gast van 1m90 aan de deur krijgt dan geeft ze alles mee natuurlijk

[Riesch]

Al die mensen van "Pfff ze zijn er zelf ingetrapt! Zou mij nooit overkomen!"? Ja, tot je het wel doet.

Compleet mee eens, phishen is een kunst geworden. En ze worden er helaas steeds beter in.
Een zwak moment en je bent het bokje omdat het er 99% legitiem uit zag.

[RobertMe]

En daarom nooit op links in een mail klikken. Zoals @Despen hieronder ook aangeeft. Alleen op links in een mail klikken als je de mail zelf geiniteerd hebt (password reset en dat soort zaken). En niet op een random "er is iets gebeurd en klik hier om ..." of wat dan ook mail. Dat is in principe al een les die zaken als banken de klanten jarenlang proberen bij te brengen. Nooit klikken op een link in een mail ("van de bank") en altijd zelf de website openen (en dan inloggen, en zelf "zoeken" naar wat aan de hand is).

[Gunneh]

Inderdaad, daarom ook handmatig naar DocuSign en Paypal gegaan maar goed, ik zat op mn PC dus geen probleem. Meeste mensen zitten op de telefoon en daar gebeurt het helaas makkelijker

[joeri1]

En daarom nooit op links in een mail klikken. Zoals @Despen hieronder ook aangeeft. Alleen op links in een mail klikken als je de mail zelf geiniteerd hebt (password reset en dat soort zaken). En niet op een random "er is iets gebeurd en klik hier om ..." of wat dan ook mail. Dat is in principe al een les die zaken als banken de klanten jarenlang proberen bij te brengen. Nooit klikken op een link in een mail ("van de bank") en altijd zelf de website openen (en dan inloggen, en zelf "zoeken" naar wat aan de hand is).

Dat klinkt als goed advies, tenzij er net op dat moment een phishing mail binnenkomt. Ik heb ooit iets dergelijks meegemaakt, perfecte timing. Gelukkig was het een interne test om ons scherp te houden.

[RobertMe]

Uiteraard moet je wel altijd scherp blijven inderdaad.

Zo krijgen wij op het werk ook continu test phishing mails (via KnowBe4). Daarnaast zijn we laatst ook overgestapt op AFAS incl de omgeving voor de medewerkers, en vervolgens duurde het niet lang voordat degene die de KnowBe4 test "aftrapt" ook een phishing mail gericht op het AFAS stuk de deur uit liet gaan. Waren er blijkbaar voldoende die de link opende en een enkeling die ook "inlogde".

[MarcMK2]

1 van de punten die we in de incident response hebben is samen met de collega door de mail lopen om de indicatoren te identificeren/laten zien.
Dit omdat iedereen erin kan trappen en we niet een angstcultuur willen creeren. Liever 10 false positives dan 1 false negative.

[Korvaag]

Ja wat mensen ook vergeten is dat als je 5000 mails verstuurt en altijd wel een paar mensen intrappen omdat de situatie er net naar is:
- Je verwacht toevallig inderdaad net een mail van x
- Je zit toevallig echt net al een week op een pakje te wachten en je vraagt je af waar het blijft
- Je bent net bezig met belangrijke zaken en checkt 'on the side' even snel iets in je mail
- Je zit met je hoofd ergens anders en etc.

Dat is gewoon het schieten met hagel. Als jij met hagel schiet op allemaal high priority targets zoals deze, dan is het ook daar wel een keer raak.

[banaj]

Krijg je een een mailje met link naar dienst? Klik NIET op link, ga zelf naar dienst en meld aan. Allemaal heel simpel!

Niet goed te praten als je als proffesional hierin trapt. Heeftt niets met kwaliteit phishing te maken. Alles met practice what you preach for.

[divvid]

absoluut. Vandaag een mail van "IT" met als onderwerp: "Action required before April 1 (no joke)"
Hoop blabla over Win11 uitfaseren en een link......
Het onderwerp was al uitgebreid besproken in de overleg momenten, dus staat op je netvlies.

Totdat ik de link eens goed bekeek...ik was er bijna ingetrapt. (<domein>.ml ipv <domein>.nl)

Gelukkig bleek het bij een telefoontje naar de helpdesk te gaan om een security test, maar toch. Geeft aan hoe snel je er in kan trappen.

[Reactie gewijzigd door divvid op 26 maart 2025 11:52]

[Smokeyy_TR]

De mens kan ook een sterke schakel zijn, onderschat de mens niet haha.

[RobertMe]

Dus hij logde handmatig in op een phishing website met de gegevens van Mailchimp?

Ik laat mooi de Bitwarden browser extensie voor mij de inloggegevens invullen. En als ik een phishing website zit, dan vindt de extensie natuurlijk geen matchend record, en zal die niks doen. Dat zou dan toch een heel duidelijke indicatie moeten zijn dat er iets niet klopt / aan de hand is.

En daarnaast ook maar weer het bewijs dat 2FA op basis van OTP niet veilig is. Geen enkele controle of het op de juiste website wordt ingevuld. En daarnaast toont het maar weer aan dat het gaat om de factor "kennis" (van de juiste code) en niet "bezig" (van het apparaat waarop de code ontvangen wordt (SMS) of gegenereerd wordt (app)). Iets waar Webauthn / FIDO wel tegen beschermd. Want die beveiliging legt wel vast voor welke website, het public/private key pair, in ingesteld en zal dus nooit "het Mailchimp certificaat" gebruiken om in te loggen (/inlogverzoek te ondertekenen) op "phishing website die lijkt op Mailchimp".

Edit:
Blogpost gescand. Blijkbaar wel een password manager gebruikt, 1password. En die "triggerde" dus ook niet de auto complete / auto fill. En vervolgens heeft hij zelf geen dubbel / trippel check gedaan "omdat het wel vaker voor komt dat die niet werkt" (websites die authenticatie op meerdere domeinen hebben / meerdere entry points van authenticatie). Blijft IMO toch slordig.

En daarnaast zou je ook nog kunnen stellen "uberhaupt niet op de link in de mail klikken, maar zelf Mailchimp openen". Hetzelfde als dat bv mails van de bank / ... nooit een link bevatten maar je altijd zelf de website moet openen. Wat eigenlijk vooral een slechte UX is om het niet te doen, en als een phishing mail wel een link bevat is het maar de vraag of de ontvanger dan niet er op klikt.

[Reactie gewijzigd door RobertMe op 25 maart 2025 16:20]

[The Zep Man]

Ik laat mooi de Bitwarden browser extensie voor mij de inloggegevens invullen. En als ik een phishing website zit, dan vindt de extensie natuurlijk geen matchend record, en zal die niks doen. Dat zou dan toch een heel duidelijke indicatie moeten zijn dat er iets niet klopt / aan de hand is.

En daarnaast ook maar weer het bewijs dat 2FA op basis van OTP niet veilig is. Geen enkele controle of het op de juiste website wordt ingevuld.

Tenzij je de OTP opvraagt in de Bitwarden client.

En vervolgens heeft hij zelf geen dubbel / trippel check gedaan "omdat het wel vaker voor komt dat die niet werkt" (websites die authenticatie op meerdere domeinen hebben / meerdere entry points van authenticatie). Blijft IMO toch slordig.

Klopt. Er zit wat handwerk in, maar volgens mij kan je (bij de Bitwarden client) een login credential toewijzen aan een hoofddomein waarna het ook beschikbaar is voor subdomeinen. Dan maakt het niet uit als de dienstverlener bijvoorbeeld op een dag overschakelt van account.example.com naar auth.example.com voor authenticatie. Dit werkt vanuit een beveiligingsperspectief uiteraard enkel voor een dienstverlener die example.com aanbiedt en niet diens dienstverlening enkel op een subdomein van het domein van een ander.

[Reactie gewijzigd door The Zep Man op 25 maart 2025 16:35]

[RobertMe]

[...]


Klopt. Er zit wat handwerk in, maar volgens mij kan je (bij de Bitwarden client) een login credential toewijzen aan een hoofddomein waarna het ook beschikbaar is voor subdomeinen. Dan maakt het niet uit als de dienstverlener bijvoorbeeld op een dag overschakelt van account.example.com naar auth.example.com voor authenticatie. Dit werkt vanuit een beveiligingsperspectief uiteraard enkel voor een dienstverlener die example.com aanbiedt en niet een subdomein.

Bij Bitwarden is de standaard inderdaad om het op basis van het TLD te doen (dus hoofddomein). Maar er zijn ook sites die echt verschillende TLDs gebruiken. Bv een .com of een .nl (of Ubiquiti die van ubiquiti.com naar ui.com zijn gegaan). Om nog maar te zwijgen over bv Microsoft die tientallen sites hebben die niet altijd linken naar hetzelfde authenticatie domein.

Maar Bitwarden bevat ook weer een lijst met domeinen die bij elkaar horen. In de web vault bij Settings => Domain rules. En dan valt ook weer meteen een andere grote op met meerdere domeinen waarop je kunt inloggen youtube.com google.com gmail.com. Als je dus een entry hebt met als URL <foo>.youtube.com en je gaat naar <bar>google.com zal de entry van youtube.com daar ook op werken. Dat voorkomt in ieder geval weer een deel van de problemen met websites die je laten inloggen op verschillende TLDs.

airbnb is zo te zien de "langste". Allemaal losse sites met de verschillende .nl, .be, .de, ... maar blijkbaar wel een gedeelde login. En Amazon heeft dat "natuurlijk" ook, maar minder land-domeinen.

Edit:
Mijn voorbeeld van Ubiquiti staat er zo te zien ook soort van op. ubnt.com en ui.com

[Reactie gewijzigd door RobertMe op 25 maart 2025 16:41]

[The Zep Man]

Maar Bitwarden bevat ook weer een lijst met domeinen die bij elkaar horen.

Eigenlijk zou dat met een cross-domain .well-known-bestand opgelost kunnen worden. Dus amazon.com geeft aan dat je bij amazon.nl mag inloggen met dezelfde credentials en andersom, wat een wachtwoordbeheerder lokaal kan bijhouden bij het eerste bezoek. Pas met die combinatie kan je een login voor amazon.nl gebruiken voor amazon.com en andersom.

Maar goed, ik zal daar wel te simpel over denken. Bij handige webtechnieken horen ook de nodige beveiligingsvalkuilen.

[Reactie gewijzigd door The Zep Man op 25 maart 2025 19:27]

[GertMenkel]

Iedereen kan vallen voor zoiets als ze moe/ziek/dronken zijn. Password managers hebben het wel vaker fout en als je eigenlijk al drie uur in bed had moeten liggen wil je nog wel eens een dubbelcheck vergeten. Plus, het is maar Mailchimp, ik denk dat hij voor Azure of zijn email iets voorzichtiger zou zijn geweest.

Ik gebruik om deze reden bij voorkeur passkeys/u2f, maar helaas is dat moeilijker te implementeren (helemaal cross platform) dan TOTP dus is het maar zelden beschikbaar.

[Reactie gewijzigd door GertMenkel op 25 maart 2025 17:44]

[sys64738]

Dit is wel heel ironisch. Je zou van deze man toch verwachten dat hij de URL van zo'n mail wel drie dubbel checkt voordat je je login en 2FA invoert. Ach, we're all human.

[Stukfruit]

Je zou van deze man toch verwachten dat hij de URL van zo'n mail wel drie dubbel checkt

In de situatie uit het artikel misschien wel, maar helaas is dat te makkelijk gedacht. Je kan tegenwoordig speciale tekens in je urls gebruiken, zoals "homoglyfen", die je met het blote oog niet kan onderscheiden van de normale karakters uit ons alfabet.

Het genereren van zo'n link is zeer simpel te doen met "pentesting"-tools die ik hier niet ga linken omdat het simpelweg te gevaarlijk is. Maar om een idee te geven heb ik een screenshot voor je genomen. Zie de derde "e".

De link die je op de screenshot ziet staan gaat niet naar tweakers.net

[Reactie gewijzigd door Stukfruit op 25 maart 2025 18:03]

[Cyb]

Je kan tegenwoordig speciale tekens in je urls gebruiken, zoals "homoglyfen", die je met het blote oog niet kan onderscheiden van de normale karakters uit ons alfabet.

Al hoewel het klopt wat je zegt, zijn deze uiteindelijk wel te onderscheiden met het blote oog.

Gebruikers zouden (naar mijn mening) bij het klikken op links namelijk twee keer de URL moeten controleren, indien ze niet willen/kunnen inloggen, maar de URL uit een email willen gebruiken. Javascript dient ten eerste uitgeschakeld te zijn in de instellingen van de email client. Vervolgens zou de URL uit de email gecontroleerd moeten worden op o.a. domein naam. Bij een vlugge controle met het blote oog, kan een IDN homograph attack wel nog mogelijk zijn, afhankelijk van de gebruikte emailclient. Maar er moet altijd nog een nacontrole worden uitgevoerd op basis van wat de browser uiteindelijk in de adresbalk weergeeft. Homographs worden daarbij niet gerenderd, maar vertaald naar ASCII Compatible Encoding, wat meteen zou moeten opvallen als een verdachte domain.

[Stukfruit]

Heb je de "e" uit m'n screenshot bekeken? Ik zie het verschil echt niet en Chrome liet ook geen verschil zien in de adresbalk.

Zoals ik eveneens schreef: ik heb de link uitgeprobeerd. Waarschijnlijk was de vage site erachter niet helemaal actief, maar het was geen Tweakers zoals jij en ik het kennen.

[Cyb]

Ik zie in die screenshot wel een tekst veld met "tweakers.net" er in, al dan niet met homographs in dat veld, maar ik zie geen normale adresbalk zoals dat in Chrome gebruikt wordt.

Wel moet je, om het uiteindelijke adres (met ASCII Compatible Encoding) in de Chrome adresbalk te zien, de url bezoeken. Je kan het zelf uittesten: copy/paste maar eens dit in de Chrome adresbalk:
[code]gmáil.com[/code]
zodra je dat domein bezoekt, maakt Chrome er van:
[code]xn--gmil-6na.com[/code]
wat meteen opvalt met blote oog. Ook rendert Chrome standaard het domain in ACE bij links, dus ook bij links valt het met het blote oog op.

[Stukfruit]

Aha, nu begrijp ik wat je bedoelt. Sorry, het is hier nacht

Ja, na het invoeren en op enter duwen zie je dat inderdaad wel, dat klopt.

[hoepstoep]

Dat is ook de reden dat ik PiHole gebruik met een blokkadelijst die enkel bestaat uit .*. Websites die ik wil bezoeken zijn toegevoegd aan de toegestane lijst. Het is iets meer werk, vooral wanneer een bepaalde site voor een inlog daar meerdere controles over meerdere domeinen inbouwt, maar dan heb je nooit problemen met tekens in een url die op het oog goed zijn.

[3raser]

In zijn blog geeft hij ook aan wat de redenen waren. Vermoeidheid, angst voor een echte blokkade en een zeer kundig bericht wat ook nog eens naar exact het juiste e-mailadres was gestuurd. Neemt niet weg dat de alarmbellen hadden moeten gaan rinkelen toen zijn 1password de velden niet automatisch werden ingevuld.

Misschien is de les die we hier uit moeten leren ook dat je eigenlijk altijd beter handmatig naar de website van de betreffende dienst kan gaan dan via een link in de mail.

[computerjunky]

Grappig genoeg hebben ze dat nog niet toegevoegd aan de lijst met leaks.

Ik sta trouwens met een stuk of 20 leaks wel te kijken van deze site want er staan een hoop producten/sites bij die ik nooit aangeraakt heb. Dus of iemand heeft mijn mail adres gebruikt of dit zijn overnames of ergens zijn gewoon mailing lists geïmporteerd en weer verder gelekt wat betekend dat deze bedrijven niet al te fraaie methodes gebruiken voor reclame.

[Vinnie.1234]

Recently added breaches
Troy Hunt's Mailchimp List logo 16,627 Troy Hunt's Mailchimp List accounts

Bij mij staat die er gewoon tussen

[computerjunky]

Apart misschien is een deel/specifieke lijst geleaked?

edit: 4 posts hieronder. Blog ken ik dus niet en ben ik nooit geweest.

[Reactie gewijzigd door computerjunky op 25 maart 2025 18:49]

[dipje2]

Sommige zijn echt accounts van bedrijven, denk aan de Dropbox leak, LinkedIn, Adobe, etc...
Maar er zijn ook 'email lists', bijvoorbeeld een nieuwe dump / lijst vol met gegevens die rondgaat op de wat donkere plekjes van het internet. Daar wordt dan een mooi naampje aan gegeven, maar dat is dus niet per se een dienst waar je zelf je op hebt aangemeld.

https://haveibeenpwned.com/Passwords is ook wel goed om eens te kijken, kan je - via hashing - checken of een wachtwoord van je bekend is ergens. Vooral als je vroeger nog wel eens hetzelfde wachtwoord gebruikte hier en daar, kan een check geen kwaad.

[PearlChoco]

Kan iemand met meer kennis mij uitleggen hoe ze zijn login hebben verkregen, nadat hij wel een 2FA met OTP gebruikte? Ze hebben dus toch zijn paswoord niet te pakken gekregen?

[RobertMe]

Hij heeft zowel zijn gebruikersnaam als wachtwoord als OTP code op een nep website ingevuld. En die nep website heeft vervolgens automatisch direct ingelogd bij Mailchimp zelf. Wat dus maar weer eens aantoont dat al deze zaken betrekking hebben op de factor kennis, en OTP geen 2FA is, hoogstens 2 stappen, maar niet 2 factoren. Immers is er geen gebruik gemaakt van de factoren "iets dat je hebt" of "iets dat je bent", maar alleen "iets dat je weet". Gebruikersnaam en wachtwoord spreken voor zich als "iets dat je weet". Maar een OTP code komt ook neer op "weten" en niet op "bezit van het apparaat met de app" (of bezit van het apparaat waarop de SMS binnen komt), want je hoeft maar de code te weten, en die kun je bewust of onbewust aan iemand anders geven, dat het meer de factor "kennis" maakt dan "bezit".

[PearlChoco]

Ha oke, ik dacht dat hij een OTP doorgestuurd kreeg via een sms ofzo (ander apparaat dus).

[kuurtjes]

OTP is gewoon 2 factoren als je ze apart van het wachtwoord opslaagt.

Verder werkt bijna geen enkele 2FA bescherming tegen een automatische login achter de schermen. Die kan immers ook gewoon je apperaat laten pingen.

[RobertMe]

OTP is gewoon 2 factoren als je ze apart van het wachtwoord opslaagt.

Als OTP 2 factoren is, hoe kan deze aanval dan gelukt zijn? Het feit dat de aanvaller geen toegang had tot de vingers, ogen, gezicht of apparaten van Troy Hunt maakt toch wel duidelijk dat er geen gebruik is gemaakt van biometrie of de controle op het bezit van het apparaat.

De aanvaller heeft bewezen dat hij genoeg had aan het verkrijgen van de gebruikersnaam, het wachtwoord, en de OTP code, via een phishing site. En met de kennis van deze gegevens prima kon inloggen. Ergo: de factor kennis was voldoende. En of Troy Hunt bv een Yubikey gebruikte om de OTP code te genereren ("echt" het bezit van een apparaat) doet er niet toe. De gegenereerde code is een X aantal seconden (/waarschijnlijk minuten) geldig. En als iemand je die code geeft kun je daar prima gebruik van maken zonder dat je als aanvaller fysiek toegang hebt tot het apparaat dat de code genereert (of ontvangt).

En in deze is ook geen ge-/misbruik gemaakt van een automatische login. Want de paasword manager herkende de website niet en wilde geen auto-fill etc doen (want huidige domein kwam niet overeen met het domein van de opgeslagen Mailchimp gegevens).

En 2FA (of zelfs passwordless 1FA) op basis van een passkey / FIDO2 / Webauthn werkt wel degelijk. Want de hardware (zij het een telefoon of laptop met een biometrische beveiliging / bevestiging, zij het een USB key zoals een Yubikey) genereert bij het registreren een unieke, niet te stelen/kopiëren, private key (en deelt de bijbehorende public key met de website) en slaat deze private key op onder vermelding van de website / domeinnaam, volledig beveiligd / afgeschermd en niet te kopiëren/uit te lezen. En als deze phishing website vervolgens deze authenticatie flow zou starten komt de browser (via de hardware) tot de conclusie dat er geen key bestaat voor het domein van de phishing website. En dus zal de challenge die de aanvaller wilt replayen / door het slachtoffer laten uitvoeren linea recta mislukken. Dit dus zonder de mogelijkheid tot "social engineering" om het slachtoffer toch maar (handmatig) gegevens laten in te vullen (zoals nu gebeurt is "hmm, 1Password herkent de website niet, dus ik zal het maar zelf invullen").

[aikebah]

OTP is gewoon 2x de factor kennis in de meest toegepaste implemetatie (TOTP), met als enige verbetering ten opzichte van wachtwoorden dat het 2e deel kennis (het vaste shared secret - de seed voor het gebruikte TOTP algorithme) niet as-is over de lijn gaat, maar je enkel bewijs met een beperkte geldigheidsduur over de lijn stuurt dat je die kennis hebt.

Het is tweetraps en biedt het voordeel dat een deel van de informatie die over de lijn gaat na beperkte tijd niet langer als bewijs van de kennis geldt, maar het blijft 2x de factor kennis.

[SlasZ]

Zo zie je maar, als een beveiligingsexpert in dit soort vallen trapt moet je niet verwonderd zijn als jan-met-de-pet op het werk hier ook in trapt.
Geen wonder dat goeie sysadmins elk toegangsverzoek van zijn users 2 of 3 keer moeten nagaan of iemand wel toegang nodig heeft tot bepaalde data / applicaties, tot grote frustratie van de meeste mensen. Least privilige is tegenwoordig echt wel noodzakelijk, in elke omgeving.

[kodak]

Dit is te simpel. Het feit dat een bekend persoon, waarvan jij niet verwacht dat deze meerdere fouten maakt, toch slachtoffer is geworden zorgt niet spontaan voor een eenduidig verband met het risico van alle andere personen.

Hooguit toont dit nogmaals aan dat de kans slachtoffer te kunnen worden bestaat en niet zomaar heel laag is. Maar daar is juist niets nieuws aan. Er bestaat geen algemene immuniteit tegen fouten maken. Maar omgekeerd ook geen absolute zekerheid dat het moment zich zal voordoen waarbij alles precies zo uit komt dat de omstandigheden alleen maar zorgen slachtoffer te zullen zijn van dit soort phishing.

Troy heeft daarbij niet slechts fouten gemaakt waar hij niets aan kon doen. Als een beroepschauffeur vermoeid achter het stuur gaat zitten en een ravage aanricht bij één of tienduizenden personen dan zeggen we ook niet dat we ons niet hoeven te schamen dat zelfde een keer te doen.

[Despen]

Ik blijf het herhalen: e-mails moet je zien als notificaties op je telefoon; krijg je een mail van website x of y dat je iets moet doen of controleren?

Prima, dan ga je handmatig naar de website, het liefst met een bookmark die je al had staan, log je handmatig in, het liefst weer met een password manager waardoor er ook nog een URL check wordt uitgevoerd dat de URL ook klopt.

Klikken op een link in een mail zou je eigenlijk alleen moeten doen als jij eerst iets zelf geïnitieerd hebt, bijvoorbeeld een wachtwoord reset, waarbij je de mail verwacht en ook binnen een minuut binnen hebt.

Klikken op een link in je mail en dan inloggen zodat je 2 minuten kunt besparen? Dat is vragen om problemen.

[Reactie gewijzigd door Despen op 25 maart 2025 18:58]

[Cyb]

Klikken op een link in een mail zou je eigenlijk alleen moeten doen als jij eerst iets zelf geïnitieerd hebt, bijvoorbeeld een wachtwoord reset, waarbij je de mail verwacht en ook binnen een minuut binnen hebt.

Al hoewel dit vaker wordt aanbevolen (het niet op een link klikken tenzij zelf geinitieerd), is het geen wetmatigheid. Op links klikken kan best, ook als je ze zelf niet geinitieerd hebt, maar het vereist wel extra oplettendheid. Vaak genoeg is er geen account beschikbaar, waardoor het "even inloggen" gewoon niet mogelijk is, zelfs niet bij zeer belangrijke emails. Er zijn immers genoeg legitieme bedrijven die zich niet aan die richtlijn houden, waardoor jij als gebruiker geen andere optie hebt dan de link uit een email te gebruiken. Zelf heb ik de afgelopen tijd diverse legitieme belangrijke emails gehad die in deze situatie vallen.

Het klikken op links is daarmee iets dan gewoon niet 100% te vermijden is, zelfs niet als je het niet zelf hebt geinitieerd. Beter is daarom naar mijn mening i.p.v. het op voorhand uitsluiten van alle links, te leren hoe je links (URLs) moet lezen, zodat je vooraf bepaalde risico's kan nachecken.

Indien Troy dat had gedaan (het verifien van adressen/urls) dan waren er in zijn situatie al drie red flags gezien kunnen worden.

[Despen]

Alright, als toevoeging dan op mijn "regel" van nooit op mails klikken: als je toch op een link moet klikken omdat het niet anders kan, log dan never nooit in.

[[Remmes]]

En daarom word er dus aangeraden niet op links te klikken maar gewoon zelf in je browser naar de bekende url te gaan.

Trouwens vind ik het eigenlijk ook gek dat mailchamp dus niet de emails van oud abonnees automatisch verwijdert.... als ik ergens unsub dan verwacht ik eigenlijk ook dat mijn email totaal uit het systeem word gehaald.

[Stukfruit]

En daarom word er dus aangeraden niet op links te klikken maar gewoon zelf in je browser naar de bekende url te gaan.

En ter aanvulling: ook niet kopieëren en plakken: zie dit.

Voor jou en mij misschien logisch, maar voor mensen die het als een "magische doos" zien kan het idee ontstaan dat je zo narigheid uit een url kan droppen. En soms klopt dat op zich als je de tekst ergens in plakt waar geen Unicode wordt ondersteund, maar zie daar tegenwoordig nog maar eens per ongeluk tegenaan te lopen

[bun00b]

Zo zie je maar dat iedereen slachtoffer kan worden van phishing. Moet maar net de juiste phishing mail binnenkomen.