Obduktion einer Phishing-Mail
Phishing-Mails kennt vermutlich jeder, der eine E-Mail-Adresse hat. Ziel dabei ist es, Zugangsdaten zu erbeuten und damit dann allerlei Schindluder zu treiben. Besonders beliebt sind dabei natürlich Bankdaten. Heute schauen wir uns ein sehr gut gemachtes Exemplar an, dass Zugangsdaten zu einem Webhoster abgreifen will und uns letzte Woche im Geschäft erreichte.
Vorweg sei gesagt, dass nicht ganz klar ist, ob das hier ein sehr gezielter Phishing-Versuch ist, oder ob wir das eher durch Zufall bekommen haben. Aufgrund von Informationen wie den Nameservern der betroffenen Domain lässt sich darauf schließen, dass wir Kunde bei all-inkl.com sind. Entsprechend ließen sich E-Mails wie diese also nur an tatsächliche Kunden von all-inkl schicken, was die eigene Phishing-Operation vielleicht etwas länger „unter dem Radar fliegen“ lässt.
Die meisten Phishing-Mails sind nicht gezielt versandt, wie jeder weiß, der die üblichen Versuche erhält, Bankdaten abzugreifen. Aber es steht jeden Tag jemand auf, der drauf reinfällt, und E-Mails kosten nix, also schickt man reichlich davon...
Die E-Mail und Ungereimtheiten
Fangen wir mit der E-Mail an sich an:
-----Ursprüngliche Nachricht-----
Von: billing@all-inkl.com <billing@all-inkl.com>
Gesendet: Montag, 20. Februar 2023 09:38
An: info@unsere-domain.de
Betreff: Rechnung 4131084293 unsere-domain.de
Sehr geehrter Kunde / Sehr geehrte Kundin,
in der Anlage übersenden wir Ihnen die Rechnung für den Leistungszeitraum 20.01.2023 - 20.02.2023 als H T M L File.
Um diese Rechnung anzuzeigen, müssen Sie sie herunterladen.
Den Gesamtbetrag in Höhe von 55.86 EUR werden wir von Ihrem Konto bei der VOLKSBANK EG abbuchen.
Für Rückfragen stehen wir Ihnen jederzeit zur Verfügung.
Mit freundlichen Grüßen
Buchhaltung
Neue Medien Münnich
http://www.all-inkl.com
Mail: billing@all-inkl.com
Tel: +49 35872 353-40
Fax: +49 35872 353-30
-------------------------------------------------------------------------
Um Ihre Supportanfragen zügig bearbeiten zu können, geben Sie bitte in jeder Mail Ihren Domainnamen an !
-------------------------------------------------------------------------
Aber da steht ja billing@all-inkl.com dran! Das ist doch echt! Leider nein, mit den angezeigten Absenderadressen von E-Mails verhält es sich ungefähr wie mit dem Absender auf einem Brief: Ich kann draufschreiben was ich möchte, das muss nicht richtig sein. Ähnlich leicht sind E-Mail-Absenderangaben zu fälschen. Dazu vielleicht ein anderes Mal mehr.
Was der Kollegin die die Mail bekam auffiel, war dass einiges nicht stimmig war: Kundennummer und Domain passten nicht zusammen, die Empfängeradresse war eine andere als sonst, Betrag und Bankinstitut passten auch nicht und zu guter letzt kommen Rechnungen üblicherweise nicht per „H T M L File“ sondern als PDF.
All das ist natürlich, wie man üblicherweise Phishing Mails erkannt. Irgendwas passt nicht, ist nicht stimmig. Ob es damit anfängt, dass ich gar kein Konto bei der Postbank habe und dementsprechend dort auch kein Passwort ändern sollte oder ob so wie hier viele kleine Details nicht zueinander passen, wichtig ist, dass man aufmerksam bleibt.
Hier sei aber auch erwähnt, dass die E-Mail sehr gut gemacht ist. Es gibt keine Rechtschreibfehler, der Inhalt und die Mail an sich sind ingesamt schlüssig, die angegebenen Telefonnummern sind die richtigen, all das passt. Zugleich hat die Mail auch das gewisse „Feeling“ einer automatisch verschickten Mail für eine Rechnung, so dass auch das erstmal unauffällig ist, wenn man Kunde bei all-inkl ist.
Die Login-Seite, die Falle
Für mich war die HTML-Datei aus dem Anhang das Spannende. Wer nämlich die Mail nur überfliegt und dann die HTML-Datei öffnet, ist kurz davor in die Falle zu tappen. Diese HTML-Datei bildet nämlich 1 zu 1 einen Login-Bildschirm von all-inkl nach:
Was ist Original, was die Fälschung?
Dieser Bildschirm ist deshalb so gut, weil er nicht nur exakt wie der originale Login aussieht, sondern auch die Links etc. genau gleich sind. Wer also „sicherheitshalber“ auf den Link zum Impressum klickt, der kommt auch zum echten Impressum, was natürlich den Eindruck einer legitimen E-Mail nochmal verstärkt.
Und im Kern ist das auch kein ungewöhnlicher Prozess: Ich will die Rechnung sehen, dafür muss ich mich einloggen. Klar, Rechnungen sind ja ein sensibles Thema, das ist natürlich durch den Login geschützt. Also logge ich mich ein und dann sehe ich die Rechnung.
Hier liegt natürlich die Falle: Denn statt die Login-Daten beim Klick auf „Anmelden“ an die Server von all-inkl zu schicken, gehen die Daten an den Server des Angreifers. Wer in den Quellcode der Seite schaut kann das entdecken, aber hier wird sogar eine sehr ähnlich lautende Domain verwendet, um das zu erschweren.
Ab hier wird es auch nochmal etwas spannender.
Verschleierter JavaScript-Code
Die angehangene HTML-Datei enthält nämlich nicht das HTML um diese Login-Seite anzuzeigen, sondern einen zunächst unlesbaren Block von JavaScript, hier ein Auszug:
Ich lade das nicht als Text hoch, damit diese Seite hier nicht von Spamfiltern oder sonstigen Systemen entsprechend negativ bewertet wird. Außerdem sollte man Code aus Phishing-Mails vielleicht auch nicht einfach kopieren und ausführen können.
Was ist das und warum macht man das?
Was wir hier sehen ist verschleierter JavaScript-Code. Diese Darstellung ist nicht wirklich menschenlesbar, vor allem aber auch von Spamfiltern schlecht zu bewerten.
Inhaltsbasierte Spamfilter, die Mails und deren Anhänge, auf Schlüsselwörter oder ähnliches untersuchen, kommen hier nicht weiter. Für die ist das einfach ein Block von Text ohne besonderen Zusammenhang was dazu führt, dass das mutmaßlich nicht als Spam eingestuft und an den Empfänger zugestellt wird.
Zurück zum Inhalt: Wir sehen hier einen Funktionsaufruf sowie die teilweise Definition rudimentärer Programmkonstrukte. Die Verschleierung nutzt zum Beispiel auch die hexadezimale Darstellung von Zahlen (0x311 entspricht 785) um die Lesbarkeit weiter zu verringern. Weiter unten in der Datei finden sich weitere Hilfsfunktionen sowie eine Art „Lookup-Tabelle“ mit Teilzeichenketten.
Dieser verschleierte Quellcode ist zu komplex um von Hand geschrieben zu werden. Für diese Aufgabe gibt es spezialisierte Werkzeuge, obfuscator.io ist zum Beispiel eines davon und vermutlich auch das hier genutzte Werkzeug. Mit dessen Hilfe lässt sich aus einer einfachen JavaScript-Anweisung wie this.alert('yeah!'); ein quasi nicht les-/verstehbarer Codeblock erzeugen:
var _0x1d3507 = _0x1fd9;
function _0x1fd9(_0x142d90, _0x4fc1bc) {
var _0x9a41c6 = _0x9a41();
_0x1fd9 = function (_0x1fd9cf, _0x53f77d) {
_0x1fd9cf = _0x1fd9cf - 0x6c;
var _0x94bdee = _0x9a41c6[_0x1fd9cf];
return _0x94bdee;
};
return _0x1fd9(_0x142d90, _0x4fc1bc);
}
function _0x9a41() {
var _0x449089 = [
'alert',
'1046CwYPGV',
'755414apJExW',
'1167984kyRFhH',
'1670TepoJS',
'40485rWzZWr',
'8024PZJBrj',
'29816hpEaCX',
'yeah!',
'581svRzuT',
'1089tEPzbt',
'35uIyIzP',
'831MKeGqq'
];
_0x9a41 = function () {
return _0x449089;
};
return _0x9a41();
}
(function (_0x56134c, _0x2edffe) {
var _0x51c839 = _0x1fd9;
var _0x52bb90 = _0x56134c();
while (!![]) {
try {
var _0x19f5f7 = parseInt(_0x51c839(0x73)) / 0x1 + -parseInt(_0x51c839(0x6f)) / 0x2 * (-parseInt(_0x51c839(0x6d)) / 0x3) + parseInt(_0x51c839(0x75)) / 0x4 * (-parseInt(_0x51c839(0x6c)) / 0x5) + -parseInt(_0x51c839(0x71)) / 0x6 + -parseInt(_0x51c839(0x77)) / 0x7 * (-parseInt(_0x51c839(0x74)) / 0x8) + parseInt(_0x51c839(0x78)) / 0x9 * (parseInt(_0x51c839(0x72)) / 0xa) + parseInt(_0x51c839(0x70)) / 0xb;
if (_0x19f5f7 === _0x2edffe) {
break;
} else {
_0x52bb90['push'](_0x52bb90['shift']());
}
} catch (_0x2b90d8) {
_0x52bb90['push'](_0x52bb90['shift']());
}
}
}(_0x9a41, 0x1b034));
this[_0x1d3507(0x6e)](_0x1d3507(0x76));
Hier könnte man durch die Auswahl entsprechender Optionen den Quellcode sogar noch unleserlicher gestalten, aber ich denke für das Beispiel genügt das so. Wir sehen hier vor allem, dass sich Muster aus unserer Datei wiederholen, beispielhaft die kryptischen Funktionsnamen und die Operationen wo hexadezimale Zahlen als Parameter für Funktionsaufrufe genutzt werden, etc. pp.
Was das Programm/die Funktion aus unserer „Rechnung“ durch die Vielzahl an Aufrufen der Funktion mit dem sperrigen Namen „_0x5ad8a3()“ macht, ist eine Zeichenkette zusammen zu setzen. Dabei werden immer wieder einzelne Teile aus der Lookup-Tabelle ausgesucht und miteinander verknüpft. Diese Zeichenkette, man ahnt es schon, ist dann der HTML-Code der Login-Seite, die wir oben gesehen haben.
Wie man das rausfindet? Zu „Obfuscators“ gibt es auch das Gegenstück, also „Deobfuscators“. Programme, die versuchen diesen unleserlichen Code möglichst weit zurückzuwandeln. Was bei unserem Code von oben sehr gut funktioniert hat ist “synchrony“. Wenn man hier die JavaScript-Funktion einfügt, erhält man binnen einer Sekunde den unverschlüsselten Code:
document.write(
unescape('%3C%68%74%6D%6C%3E%0A%0A%20%20%20%3C%68%65%61%64%3E%0A%20%20%20%20%20%20%3C%6C%69%6E%6B...');
)
Diese Zeichenkette ist so kodiert, dass sie als URL übertragen werden könnte. unescape() macht das rückgängig und erzeugt daraus wieder „Klartext“. Die hier gekürzte Zeichenkette enthält so 1 zu 1 den HTML-Quelltext der Loginseite von all-inkl, mit der kleinen Veränderung des Ziels der Daten. Wird dieser Code vom Browser ausgeführt, wird also die modifizierte Login-Seite angezeigt.
Zurück zur Login-Seite.
Der API-Endpunkt, die abgegriffenen Daten und was man damit machen kann
Das Formular von der gefälschten Login-Seite schickt seine Daten an einen einfachen API-Endpunkt. Dieser Endpunkt ist ziemlich schweigsam. Egal ob man einzelne Felder weg/leer lässt, es kommt keine Antwort zurück und dementsprechend ändert sich auch nichts an der Login-Seite.
Das könnte „Opfer“ dazu verleiten, einen Fehler auf Seiten von all-inkl zu vermuten und erstmal mit etwas anderen weiterzumachen. Was sehr wahrscheinlich im Hintergrund passiert ist, dass die gesendeten Daten zur späteren Verwendung in eine Datenbank geschrieben werden.
Was will man nun eigentlich mit diesen Daten? Nun, mit einer gültigen Nutzername + Passwort Kombination kann man sich bei all-inkl in die sog. „Members Area“ einloggen und von dort Zugriff auf die gebuchten Webhosting-Pakete, Server etc. pp. erhalten.
Mit Vollzugriff auf diese Systeme lässt sich einerseits natürlich viel Schaden durch den Diebstahl oder das Löschen von Daten anrichten, zum anderen lässt sich aber auch relativ unbemerkt weitere Schadsoftware oder ähnliches hochladen und weiter verwenden. So könnte man unbemerkt WordPress-Installationen infizieren, Spam verschicken oder sonstwas tun.
Monetäre Vorteile lassen sich durch diese Zugangsdaten bei all-inkl selbst nicht ohne Weiteres erzielen. Es besteht aber natürlich die Möglichkeit, dass die Zugangsdaten auch auf anderen Seiten verwendet werden. Mit einem Satz gültiger Zugangsdaten für all-inkl können Angreifer also ggf. auch andere Accounts wie PayPal oder sonstiges übernehmen.
Hintermänner
Interessant ist natürlich auch, wer hinter diesem Phishingversuch steckt. Das bekommt man natürlich nicht so einfach raus.
Die WHOIS-Informationen der Domain sind geschützt und ggf. ist die Domain auch unter einem falschen Namen registriert worden. Die IP des Servers gehört zu „panamaservers.com“ die sich mit „No question asked, private web hosting.“ schmücken. Vermutlich nicht gerade ein Unternehmen, das auf Beschwerdemails wegen der „Arbeit“ seiner Kunden reagiert.
Das ist natürlich üblich für Akteure aus dem Bereich von Spam, Scam, Phishing und ähnlichen Aktivitäten. Entweder nutzt man gekaperte Server, das wäre wieder ein Punkt wofür gültige Zugangsdaten gut wären, oder weicht auf Anbieter wie den genannten aus, die sich nicht viel aus den Gesetzen anderer Länder machen.
Anonymisierungsdienste für Domains sind dann oft auch gleich Bestandteil des Angebots und Zahlungen per Cryptowährung nicht unüblich, so dass erstmal relativ wenige Spuren hinterlassen werden.
Als Privatperson ist man an dieser Stelle quasi am Ende, wenn man sich nicht selbst strafbar machen möchte. Fraglich ist jetzt, ob ein Hoster mit Sitz in Panama Rechtsmittel einlegen würde, aber ausprobieren wollte ich das auch nicht unbedingt. Dennoch gibts gleich noch ein paar Ideen/Erkenntnisse aus meinen Tests.
Hilfe für die Geschädigten
Als Geschädigter, gleich auf welcher Seite, steht man so einer Phishing-Aktion ein wenig machtlos gegenüber.
Wie oben schon erwähnt, muss man bei jeglicher E-Mail echt vorsichtig sein und immer mit der nötigen Vorsicht dran gehen. Wie uns das vorliegende Beispiel aber zeigt, gibt es mittlerweile sehr gut gemachte Varianten, die schwer zu erkennen sind. Wird dann noch „mehrschichtig“ und gut aufeinander aufgebaut, wird der Phishing-Versuch immer intransparenter.
Es bleibt also besonders für Leute die nicht den Quelltext von Login-Seiten lesen wollen, und das sollte eigentlich niemand machen müssen, nicht einfach.
Als Geschädigter, in diesem Fall aus Sicht von all-inkl, kann man sich ein wenig mit state-of-the-art E-Mail-Technologien „verteidigen“. SPF und DKIM sind relativ schnell und einfach eingerichtet und ein wichtiger Schritt in die richtige Richtung.
Über diese Technologien lässt sich prüfen, ob wirklich der angegebene Server die E-Mail verschickt hat und ob er dazu berechtigt war. Leider sind beide Technologien noch nicht flächendeckend im Einsatz, und auch kein Schutz gegen gekaperte Accounts, aber besser als nichts ist das immer noch.
Test des Endpunkts / Ideen
Beim Test des Endpunkts sind natürlich ein paar Ideen und Erkenntise entstanden, die ich hier der Vollständigkeit halber aufführen will. Nicht alles davon sollte man wirklich machen, weil einiges geltenden Gesetzen (mindestes in Deutschland) zuwider laufen könnte.
- Aus dem Server läuft phpMyAdmin als Datenbankverwaltung, aber Standardzugänge funktionieren nicht. Würden die funktionieren, hätte man darüber vermutlich Zugriff auf die Datenbank, die die abgegriffenen Logins speichert. Diese Datenbank könnte man schlicht und einfach leeren oder aber vollständig löschen. Löschen hätte den Vorteil, dass dann erstmal keine neuen Logins gespeichert werden könnten.
- Der API-Endpunkt scheint gegen SQL Injections geschützt zu sein. „Kreative“ Nutzernamen und Passwörter können also nicht genutzt werden, um dem Datenbankserver weitere Informationen zu entlocken.
- Der Webspace scheint relativ leer zu sein. Mit Ausnahme des bösen Endpunkts finden sich keine weiteren Dateien auf dem Webspace. Entsprechendes „Raten“ von URLs führt zu keinem Ergebnis sondern nur zu 404-Fehlern.
- Mit etwas Zeit und Aufwand könnte man ein Script schreiben und laufen lassen, dass den Endpunkt mit fehlerhaften Daten vergiftet. So könnte man den Akteuren ihre Arbeit mutmaßlich etwas erschweren, weil sich so einfach ein Verhältnis von 10000 zu 1 zwischen falschen und echten Logins herstellen ließe. Es gibt allerdings auch allerlei Techniken um sowas zu verhindern und/oder festzustellen, aber es lässt sich von außen nicht sagen, ob diese genutzt werden oder nicht. Vielleicht wäre das also einen Versuch wert.
Über mich
Ich bin gelernter Mediengestalter, studierter Druck- und Medientechniker und leidenschaftlicher Tüftler und Bastler.
Beruflich beschäftige ich mich mit der digitalen Transformation von Unternehmen, sowie der Automatisierung von Unternehmensprozessen, in der Druck- und Medienbranche. Mehr dazu findet sich im Lebenslauf.
Privat interessieren mich Kaffee(maschinen), Themen rund um Webentwicklung, das Internet im Allgemeinen und Speziellen und vieles, vieles mehr.
Ich freue mich auf Feedback per E-Mail unter kontakt@flomei.de, einen Euro für die Kaffeekasse oder etwas von meiner Amazon Wunschliste.