
read receipts
Jouw antivirus had geen schijn van kans tegen een leeg emailbericht
De zwendel die vorig jaar $2,9 miljard uit Amerikaanse bedrijven pompte, droeg geen enkele virus met zich mee. Het droeg een onderwerpregel en een gunst.
Een salarisbeheerder bij een middelgroot bedrijf krijgt een email van de CEO. Geen bijlage. Geen link. Gewoon vijf regels waarin hij wordt gevraagd een dringende overboeking naar een nieuwe leverancier voor het middaguur uit te voeren, en alsjeblieft discreet erover, we sluiten de overname af. Ze boekt $180.000 over. De CEO had het nooit verstuurd. En elk stukje beveiligingssoftware waarvoor het bedrijf betaalde, zag absoluut niets fout, omdat er niets te zien was.
Dit is business email compromise, en het is bij grote marge de duurste misdaad in je inbox. Het FBI Internet Crime Complaint Center registreerde in 2023 alleen al $2,9 miljard aan gerapporteerde BEC-verliezen. Ransomware, het ding waar iedereen panisch over wordt, het ding met de doodskopgrafiek en de afteltellers? Dat boekte ruwweg $59,6 miljoen aan gerapporteerde verliezen datzelfde jaar. BEC verslaat het met een factor van bijna vijftig. Het ene krijgt headlines. Het ander krijgt jouw geld.
De reden waarom antivirus hier faalt is bijna beschamend. Malware-scanners werken door code te onderzoeken — een bijlage, een uitvoerbaar bestand, een macro verborgen in een spreadsheet. Ze vergelijken het met bekende slechte handtekeningen of kijken hoe het zich gedraagt in een sandbox. Een BEC-email geeft ze een gewoon tekstbericht geschreven in de toon van je baas. Er is geen lading om tot ontploffing te brengen. Het wapen is een zin.
Wat betekent dat de verdediging geen scanner kan zijn. Het moet een gewoonte zijn, en de gewoonte leeft in de headers.
Dit is het bewijs dat de meeste mensen nooit zoeken. Het From-veld en het Reply-To-veld zijn twee verschillende dingen, en oplichters exploiteren de kloof. De From-regel toont een naam en adres die je vertrouwt — ceo@yourcompany.com, correct gespeld. Maar op het moment dat je op reply klikt, wordt het bericht stilletjes gerouteerd naar ceo.finance@gmail-secure-mail.com of een willekeurig domein dat de aanvaller werkelijk controleert. Je antwoord, met de overboekingsbevestiging, vliegt rechtstreeks naar de crimineel. De weergavenaam loog. De Reply-To vertelde de waarheid.
Train jezelf dus om de header uit te breiden voordat je actie onderneemt op enig geldverzoek. Klik in Gmail op de kleine pijl onder de naam van de afzender. In Outlook open je de berichtdetails. Als Reply-To niet overeenkomt met From, stop. Als het domein één karakter afwijkt — rn doet zich voor als m, een .co waar je .com verwachtte — stop.
De geavanceerdere versie moeite zich niet eens in je eigen domein voor te doen. Het geeft zich uit voor een echte leverancier die je al betaalt. De aanvaller zit wekenlang op een gecompromitteerde leveranciersaccount, leest de werkelijke factuurdraad, en stuurt dan op het perfecte moment: "We hebben onze bankgegevens bijgewerkt, gebruik alstublieft de nieuwe rekening." Deze variant is wreed precies omdat de email authentiek is — het komt uit de echte, gebroken inbox van de leverancier. SPF, DKIM en DMARC slagen allemaal schoon door, omdat het bericht werkelijk afkomstig is van waar het beweert af te komen. Authenticatie bevestigt de afzender. Het kan de eerlijkheid van de afzender niet bevestigen.
Dat is de oncomfortabele waarheid onder dit alles: de hele zwendel loopt op vertrouwen en haast, twee dingen die geen handtekeningendatabase kan meten. Een CEO die "nooit zó emailt" doet het plotseling wel. Een leverancier die je drie jaar op dezelfde manier heeft gefactureerd, verandert plotseling rekeningen. Het verzoek komt altijd met een reden die je niet voor het middaguur kunt verifiëren.
Dus verifieer via een ander kanaal. Bel het nummer dat je al hebt — niet het nummer uit de email. Een telefoontje van tien seconden heeft wires van zes cijfers betrouwbaarder ongedaan gemaakt dan enig product met een firewall in zijn naam. De oplichters wedden erop dat je niet opbelt. Bewijs hun ongelijk.