Incident Response: Business E-Mail Compromise nutzt gefälschte Domains
17. April 2020
Die Arbeit eines Incident-Response-Spezialisten ist nie langweilig: Ein Start-up wartete auf eine Million Dollar als Startkapital, allerdings traf das Geld nie auf dem Bankkonto der Firma ein. Auf der anderen Seite stellte der verantwortliche Manager der Risikokapitalgesellschaft fest, dass der Investmentfonds, den er zur Finanzierung des Start-up-Deals nutzen wollte, kein Geld mehr hat – hier das gesamte Protokoll des Angriffs.
Bereits Anfang 2019 ereignete sich genau dieser Fall: Eine chinesische Risikokapitalgesellschaft wurde von ihrer Bank darauf aufmerksam gemacht, dass es ein Problem mit einer ihrer jüngsten Transaktionen gab. Ein paar Tage später wurde einem jungen israelischen Start-up klar, dass sie eine Million Dollar Anschubfinanzierung nicht erhalten hatten. Beide Seiten telefonierten und erkannten schnell, das Geld wurde gestohlen.
Als beide Seiten dies feststellten, bemerkten sie seltsames bezüglich der E-Mail-Korrespondenz. Einige E-Mails wurden geändert und andere nicht einmal von ihnen initiiert. Zu diesem Zeitpunkt beauftragte der CEO des israelischen Start-ups die Incident-Response-Spezialisten von Check Point mit der Untersuchung der betrügerischen Geldüberweisung. Was als normaler Business E-Mail Compromise (BEC) begann, wurde schnell zu etwas größerem. Die Sicherheitsforscher sammelten und analysierten die verfügbaren Protokolle, E-Mails und PCs. Während der Phase der Beweisaufnahme standen sie vor drei Herausforderungen (siehe Bild 1).
Die Postfächer des Kunden wurden auf dem E-Mail-Server von GoDaddy gehostet. Allerdings lieferte dieser keine hilfreichen Informationen. Die Auditprotokolle zeigten nur die fünf letzten Anmeldungen am Server an und alle wiesen israelische Start-up-Mitarbeiter aus. Wenn das Benutzerkonto auf israelischer Seite kompromittiert worden war, würde sich wahrscheinlich nicht genau bestimmen lässt, wann der Angreifer angemeldet war oder welche IP verwendet wurde.
Zunächst mussten die ursprünglichen E-Mails aufgespürt werden, damit wir die E-Mail-Header untersuchen konnten. Es konnten jedoch nur Screenshots (vom Handy) der betreffenden E-Mails gefunden werden. Deshalb wurden die Mailbox-Archive von allen Personen gesammelt, die im ursprünglichen Thread in CC waren. Über die Suche nach Keywords aus den Screenshots konnten letztlich die ursprünglichen E-Mails gefunden werden.
Angreifer lesen mit
Nun, da die ursprünglichen E-Mails vorhanden waren, wurde das Gesamtbild klarer. Anscheinend, ein paar Monate bevor die Geldtransaktion durchgeführt wurde, fand der Angreifer einen E-Mail-Thread. In diesem Thread wurde die bevorstehenden Anschubfinanzierung angekündigt und er beschlossen, das auszunutzen. Anstatt die E-Mails nur durch die Erstellung einer automatischen Weiterleitungsregel zu überwachen, wie es in den üblichen BEC-Fällen der Fall ist, entschied sich dieser Angreifer dafür, zwei neue und sehr ähnliche Domains zu registrieren (Bild 2).
Die erste Domain war im Wesentlichen die gleiche wie die israelische Start-up-Domain, jedoch mit einem zusätzlichen ’s‘ am Ende des Domainnamens. Die zweite Domain ähnelte jener der chinesischen Firma, fügte aber wieder ein ’s‘ am Ende des Domainnamens hinzu.
Der Angreifer schickte dann zwei E-Mails mit der gleichen Überschrift wie der ursprüngliche Thread. Die erste E-Mail wurde an das chinesische Unternehmen aus der israelischen, ähnlich gelagerten Domain gesendet, um die E-Mail-Adresse des CEO des israelischen Start-ups zu manipulieren. Die zweite E-Mail wurde an das israelische Startup von der ähnlich chinesischen Firmendomain gesendet, um den Account Manager, der diese Investition getätigt hat, zu täuschen.
Diese Infrastruktur gab dem Angreifer die Möglichkeit, den ultimativen Man-In-The-Middle (MITM)-Angriff durchzuführen. Jede beantwortete E-Mail wurde in Wirklichkeit an den Angreifer gesendet. Dieser entschied dann, ob Inhalte bearbeitet werden mussten, und leitete dann die E-Mail von der betreffenden identischen Domain an ihr ursprüngliches Ziel weiter.
Während des gesamten Verlaufs dieser Attacke schickte der Angreifer 18 E-Mails an die chinesische Seite und 14 an die israelische Seite. Geduld, Liebe zum Detail und gute Aufklärungsarbeit des Angreifers machten diese Attacke zu einem Erfolg (Bild 3).
Ohne diese Aktion von Seiten des Angreifers wäre die gesamte Operation wahrscheinlich gescheitert. Es ist vernünftig zu erwarten, dass der Kontoinhaber während des Treffens aufgefordert wird, die vorgenommenen Änderungen des Bankkontos zu überprüfen. Dies war ein inakzeptables Risiko für den Angreifer, und so unternahm er Schritte, um sicherzustellen, dass es nicht passieren würde. Dies ist das Zeichen eines erfahrenen Angreifers (Bild 4).
Anstatt nach einem solchen Raub alle Kommunikationslinien zu unterbrechen, hörte der Angreifer nicht auf, seine Bemühungen einzustellen, sondern versuchte, eine weitere Runde der Investition auszulösen. Als ob das nicht genug wäre: Nachdem der Angriff behoben wurde, erhält der israelische CFO weiterhin jeden Monat eine E-Mail aus dem gefälschten CEO-Konto. In dieser E-Mail fordert er ihn auf, eine Überweisung durchzuführen. Der Inhalt ist in Bild 5 zu sehen. Die komplette sechs Stufen des Angriffs sind in Bild 6 zusammengefasst.
Schlussfolgerungen
Wenn Unternehmen mit Banküberweisungen zu tun haben, sollten sie immer sicherstellen, dass es eine zweite Überprüfung gibt. Zum Beispiel, indem sie die Person anrufen, die um die Überweisung gebeten hat, oder den Empfänger benachrichtigen. Weiterhin sollten sie sicherstellen, dass ihre E-Mail-Infrastruktur in der Lage ist, Audit- und Zugriffsprotokolle für mindestens sechs Monate aufzubewahren.
Zu Beginn ist es einfach, schnell eine sichere Infrastruktur aufzubauen und die Protokollierung nur nachträglich durchzuführen. Darüber hinaus sollten sie bei vermuteten oder bestätigten Cyber-Sicherheitsvorfällen so viele forensische Beweise wie möglich sammeln. Das Löschen eines Beweisstücks hilft nur dem Angreifer.
Rechtzeitige Beweiserfassungen, wenn der Vorfall eintritt, können auch sicherstellen, dass wichtige Protokolle und Beweise nicht überschrieben werden. Neu registrierte Domains zu identifizieren, die dem eigenen Domainnamen ähnlich sind, ist ebenfalls sinnvoll. Ein Incident Response-Plan und taktische Incident Response-Playbooks sollten vorzeitig bereit liegen. Zu wissen, was vor einer Krise zu tun ist, konzentriert die Reaktionsaktivitäten und verkürzt die Zeit für die Behebung von Problemen.
Dan Wiley ist der Leiter der Incident Response & Threat Intelligence bei Check Point Software Technologies.
