Fake President Fraud resp. Fake CEO Trick bei Namics: Zahlung per Mail angewiesen

Nicht über eigene Fehler zu sprechen verbietet anderen daraus zu lernen. Der folgende Post könnte Euch viel Geld sparen.

Nur Glück verhinderte, dass wir per Mail nicht um EUR 75’200 betrogen wurden. Die Masche, bekannt als Fake President Fraud, ist zur Zeit ziemlich verbreitet: Hier je ein Artikel im Focus (mit der Zentralbank als Opfer) und im Spiegel (mit einem Schaden von 17 Mio.).

Ich meine, dass wir bei Namics wissen wie man mit Mail umgeht. Zudem haben wir eine sehr gute technische Infrastruktur und wir haben Kontrollsysteme mit Doppelunterschrift u.s.w. All das hat aber nicht verhindert, dass wir einem Betrüger auf dem Leim gekrochen sind und der genannte Betrag schon aus dem Haus war. «Gerettet» hat uns die türkische Bank Yapı ve Kredi. Doch jetzt zur Geschichte.

Zahlung wird zurückgewiesen

Anfang August bekomme ich eine interne Mail, dass eine Zahlung von der Bank «aus geschäftspolitischen Gründen» zurückgewiesen wurde. Empfänger der Mail war ich, da ich diese Zahlung veranlasst habe — doch hörte ich zu diesem Zeitpunkt das erste Mal davon.

Anbahnung per Mail

Mitte Juli erhielt unser CFO eine Mail mit dem folgenden Wortlaut:
>>>
Hallo Andreas
Ich muss eine internationale Geldüberweisung abwickeln, die ich von dir als bald wie möglich erledigt brauche. Lass mich wissen, ob du es tun kannst, damit ich dir die nötigen Informationen schicken kann…
Freundliche Grüsse,
Jürg Stuker

<<<
«Absender» der Mail war Jürg Stuker von Namics. Genau gesehen kam die Mail aber vom Server email07.europe.godaddy.com und trug die folgenden drei Adressen

From: "=?UTF-8?Q?J=C3=BCrg=20Stuker?=" <juerg.stuker@namics.com>
 X-Sender: dave@chicagocondosource.com
 Reply-To: "=?UTF-8?Q?J=C3=BCrg=20Stuker?=" <info.cc@groupmail.com>
 </info.cc@groupmail.com></juerg.stuker@namics.com>

Für die Techniker unter uns ist der Fall sofort klar. Doch hier die Ansicht des Mails einerseits im Mail-Client des iPhones und andererseits im Webclient von GMail. Keine Chance den X-Mailer oder die Antwort-Adresse zu erkennen.

Da Andreas in den Ferien war, hat er die Mail nicht beachtet und sein «Out-of-Office Agent» antwortete mit der Nennung seiner Stellvertretung. Diese erhielt 20 Minuten später die identische Mail von demselben Absender an sie adressiert.

erste Rückfrage

Sowohl der CFO (später) als auch seine Stellvertretung (sofort) fragten mit der Funktion Antworten «an mich» (also an Jürg Stuker <info.cc@groupmail.com>). Der Angreifer antwortete aber nur noch auf seine zweite Mail. Dabei wäre das Problem erstmals zu erkennen gewesen.

Antwort des Angreifers

Die Antwort des Angreifers folgte nach Minuten mit Angabe der Kontodaten. Dieses Mail ist bereits deutlich schlechter formuliert und zeigt kleinen Ungereimtheiten. So würde ich intern nie jemanden Siezen. Aber der Betrugsversuch war noch immer unerkannt, so auch die sichtbar falsche RCPT TO-Adresse (diesmal ein Ausdruck aus GMail).

Darauf gab es noch eine Rückfrage von uns nach der zu belastenden Kostenstelle. Da zwei zur Auswahl standen, gelang es dem Angreifer auch diese, letzte Hürde einfach zu nehmen.

Interne Prozesse

Was bei uns intern falsch gelaufen ist, tut nichts zu Sache. Aber offensichtlich genügt weder ein Unterschriftenreglement (mit zwei Unterschriften) noch eine digitale Workflowlösung für Zahlungen noch die Tatsache, dass die Zahlung im E-Banking von zwei Personen freigegeben werden musste. Mail und Social Engineering waren stärker.

Was haben wir getan?

1. Wir haben allen beteiligten Firmen / Banken / Hoster Meldung erstattet. Zudem an MELANI und an die Kantonspolizei (die nichts davon wissen wollte).
2. Wir haben mit den direkt betroffenen Personen sofort einzeln gesprochen, damit sie verstehen was geschehen ist und wie sie sich schützen können.
3. Wir nahmen den Fall in unser Schulungs- und Onboarding-Programm auf, um alle bestehenden und neuen Mitarbeiter zu erreichen.
4. Wir haben historische Überweisungen durch unseren Banken nach einem bestimmten Muster prüfen lassen (und glücklicherweise keinen weiteren Fall gefunden).
5. Wir haben die DMARC-Policy auf unserem Mailsystem so verstärkt, dass die Domänen von X-MAILER und RCPT TO im DNS des Senders bewilligt sein müssen. Ein Mail mit der damaligen Adresse-Konstruktion wird nicht mehr ausgeliefert. Ein paar Wochen später erreichte uns ein erneuter Versuch, der transparent eine andere Adresse zeigte. Dies wurde sofort erkannt.

6. Unser Sicherheitsteam, welches den ganzen Prozess kontrollierte, hat in einem Incident-Report den Fall so gut dokumentiert, dass es mir einfach fällt diesen Post hier zu verfassen.
7. Wir haben die Rekonstruktion aus unsere Archievierung durchgespielt und konnten alle Daten finden. Zumindest die funktioniert 😉

Was habe ich gelernt?

• Mail wird sicherer wahrgenommen als es tatsächlich ist. Im Rahmen einer internen Sensibilisierung empfehlen wir Videochat oder Telefon als Kontrollmedium: «Einfach schnell anrufen».
• Zeitdruck ist ein Garant für Fehler. Die mutmassliche künstlich gesetzte Kurzfristigkeit hat einige Kontrollen ausgehebelt.
• Es hat mich erschreckt, dass mindestens eine Person bei uns dachte, dass ich als Person mehr Rechte hätte, als wir gemeinsam definiert haben. Ich würde nie eine Zahlung ohne Beleg anweisen und ich will nicht, dass die zweite Unterschrift ihre Prüfaufgabe nicht übernimmt.
• Mehr technische Informationen über den Mailverkehr oder auch sonstige Massnahmen kann man gerne bei mir erfragen.
• PS: Auf Hinweis von Florian die Anmerkung, dass uns ausschliesslich die türkische Bank Yapı ve Kredi vor dem Schaden bewahrt hat. Sie hat die von der Absenderbank bereitgestellte Zahlung «aus geschäftspolitischen Gründen» nicht angenommen und deshalb kam das Geld zurück zu uns. Wir haben dort sowohl auf Deutsch wie auch auf Türkisch nachgefragt, weshalb dem so war. Doch leider haben wir bis jetzt keine Antwort erhalten.