HE Domain Phishing
Diesmal wäre ich fast auf eine recht gut gemacht Mail hereingefallen. Allerdings zeigte die Analyse, dass dein Klick anscheinend gar keinen Fehler produziert hätte.
Phishing Mail
Die Mail behauptet von Host Europe zu kommen und meine Domain "msxfaq.de" zu betreffen. Diese Information lässt sich per ja einfach ermitteln. Der DNS-Server für die Zone ist bei Domaincontrol.com.
C:\> nslookup -q=NS msxfaq.de msxfaq.de nameserver = ns15.domaincontrol.com msxfaq.de nameserver = ns16.domaincontrol.com
Über eine Namensauflösung auf www.msxfaq.de finden Sie die IP-Adresse 178.77.117.98 und über Whois auch den Provider.
Quelle:
https://ipinfo.io/AS20773/178.77.112.0/21-178.77.117.0/25
Insofern kann ein Angreifer sehr gut eine passende Mail versenden:
Ich habe bislang noch keine Mail dazu erhalten aber man muss schon etwas über dem Link stehen bleiben, um die finale URL zu sehen und auch die kleine Unstimmigkeit bei den Tagen zu erkennen. Allerdings sollte beim Absender auffallen, dass der Displayname zwar auf "Host Europe" lautet aber die von Outlook angezeigte SMTP-Adresse sollte auffallen.
Allerdings hätte der Absender im Header auch problemlos eine "Hosteurope.de"-Adresse nutzen können, denn leider veröffentlicht HostEurope zwar einen SPF-Eintrag mit "-all" aber keinen DMARC-Record.
PS C:\> nslookup -q=TXT hosteurope.de hosteurope.de text = "v=spf1 .......... -all" PS C:\> nslookup -q=TXT _dmarc.hosteurope.de *** _dmarc.hosteurope.de wurde nicht gefunden: Non-existent domain.
Hier könnte HostEurope noch etwas nachschärfen, damit Spamfilter auch die Domain im SMTP-Header verifizieren.
Allerdings würde ich das nicht schreiben, wenn mir der Absender nicht aufgefallen ist. Leider zeigt Outlook bei der IMAP4-Nutzen nicht an, ob eine Mail von "Extern" kommt. Insofern hat mich die Analyse der URL gestoppt.
Mailheader
Ehe ich die URL weiter untersuche habe ich mir den Header der Mail angeschaut. Hier sehen Sie, dass die Mail an die "info"-Adresse von der IP-Adresse 178.32.247.120 eingeliefert wurde und sogar DKIM-Signiert war.
Return-Path: <SRS0=I7Mtdrtp=EX=rivierazeit.de=contact@msxfaq.de>
Authentication-Results: kundenserver.de; dkim=pass header.i=@rivierazeit.de
Received: from mi027.mc1.hosteurope.de ([80.237.138.228]) by
mx.kundenserver.de (mxeue009 [212.227.15.41]) with ESMTPS (Nemesis) id
1MEnQx-1qP3VO1HCN-00GJK2 for <frank@carius.de>; Thu, 07 Sep 2023 13:06:45
+0200
Received: from ip120.ip-178-32-247.eu ([178.32.247.120] helo=rivierazeit.de)
by mx0.webpack.hosteurope.de (mi027) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim)
id 1qeCqQ-0008Gu-F4
for info@msxfaq.de; Thu, 07 Sep 2023 13:06:45 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mail1; d=rivierazeit.de;
h=From:Reply-To:To:Subject:Date:List-Unsubscribe:Mime-Version:Content-Type:
Message-ID;
bh=BQa2+sC2wbeH/ObOdT/5lu0xDBcMbA+O3Rcz/ka8ECY=;
b=5HX2rXi0lO7ybvs+QLFALlg5xEUVp5DzdBgZ2Y0wuVDj4TRTdIpJ4us5hm6E+VU4QyRxievcJL/T
YbEZgsA3N4ESTbXHCf5MFmg564rkkvx4+DmB2/kRpux/dTqyyzHVrYBClaoRFD3RxNfHgvPKvBcE
tB8waaUeSViikMnDL5w=
From: =?utf-8?B?SG9zdCBFdXJvcGU=?= <contact@rivierazeit.de>
Reply-To: contact@rivierazeit.de
To: info@msxfaq.de
Subject: =?utf-8?B?VmVybMOkbmdlcnVuZyBkZXIgZG9tYWlubmFtZSBtc3hmYXEuZGUgZmVobGdlc2NobGFnZW4u?=
Date: Thu, 07 Sep 2023 13:13:02 +0200
List-Unsubscribe: <mailto:contact@rivierazeit.de?subject=Unsubscribe>
X-Priority: 3
X-Mailer: MailSender [version 2.0.3]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="318559785BF548F89D74CA33778B303E"
Message-ID: <0.0.3.4A2.1D9E17B61CD6984.0@rivierazeit.de>
X-HE-Spam-Level: +
X-HE-SPF: PASSED
Envelope-To: <frank@carius.de>
X-Spam-Flag: NO
Die einliefernde IP-Adresse wird von OVH im Hosting bereitgestellt.
Die Adresse ist "sehr nahe" am MX-Record für die Domain:
C:\> nslookup -q=MX rivierazeit.de rivierazeit.de MX preference = 10, mail exchanger = rivierazeit.de rivierazeit.de internet address = 178.32.247.122 rivierazeit.de internet address = 178.32.247.123 rivierazeit.de internet address = 178.32.247.124 C:\> nslookup -q=TXT _dmarc.rivierazeit.de _dmarc.rivierazeit.de text = "v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:abuse@rivierazeit.de;ruf=mailto:abuse@rivierazeit.de;ri=86400;aspf=r;adkim=r;fo=0:d:s" C:\> nslookup -q=TXT rivierazeit.de rivierazeit.de text = "v=spf1 a mx ip4:178.32.247.122/32 ip4:178.32.247.123/32 ip4:178.32.247.124/32 ~all"
Allerdings hat am Tag darauf keiner der per MX-Record veröffentlichten Server auf Port 25 geantwortet. Ich nehme an, dass da jemand den Mailserver "gehackt" hatte und dann im Namen des Kunden die Mails versendet hat. Der SPF-Record hat leider nur ein "~all", denn sonst wäre die Mail gar nicht angekommen. Die gleichen drei Server werden wohl zugleich als Webserver genutzt. Die 178.32.247.120 ist allerdings daneben und könnte ein Staging oder Test-Server gewesen sein, der vielleicht nicht gut genug gesichert war.
Aus dem Header ist nicht zu ersehen, dass die Mail davor schon über weitere Stationen gelaufen ist. Das interpretiere ich so, dass auf dem Server selbst die Mail generiert und versendet wurde. Zwar kann fast jede Information im Header gefälscht sein, aber der "X-Mailer: MailSender [version 2.0.3]" ist zumindest ein Hinweis auf JavaMail/Springboot Framework.
DNS zur Link-Domain
Aber auch der Link in der Mail verweist auf eine Domain, die nichts mit HostEurope oder rivierazeit.de zu tun hat. Der Name scheint zuerst auf ein dynamisches Angebot eines Webhosters zu verweisen. Allerdings it "pagir.pt" eine portugiesische Firma, die anscheinend Fahrertrainings etc. anbietet. Interessant ist auch hier wieder die Namensauflösung.
pagir.pt -> 185.12.116.103
www.pagit.pt -> 185.12.116.103
webmail-e2855a563d9.pagir.pt -> 104.166.159.66
test.pagir.pt -> 104.166.159.66
1234.pagir.pt -> 104.166.159.66
Anscheinend hat der Angreifer Zugriff auf die DNS-Konfiguration von "pagir.pt" und hat einen Wildcard-Eintrag angelegt, so dass alle Auflösungen auf nicht existierende Namen auf eine abweichende IP-Adresse verweisen. Die Webseite wird sogar auf eine Server in Portugal gehostet:
https://ipinfo.io/185.12.116.103
Ich bin ziemlich sicher, dass der Inhaber von pagir.pt nicht weiß, dass seine Domain in solchen Links verwendet wird. Die URL aus der Phishing-Mail verweist auf eine komplette andere IP-Adresse 104.166.159.66, die
https://ipinfo.io/104.166.159.66
Der Link-Hoster
Einen Link in einer Phishing-Mail sollten Sie nie auf ihrem produktiven Arbeitsplatz mit einem Browser aufrufen. Sie wissen nie, wie viele Informationen ihr Browser quasi "aus Versehen" schon an den Hoster übermittelt und welche Payload zurück kommt. Daher nutze ich in der Regel einfach eine PowerShell oder CURL, um die URL abzufragen.
Auch dies ist nicht 100% anonym, denn wenn Sie sich die URL anschauen, dann ist da schon die Domain als URL hinterlegt. Der Spammer kann so theoretisch sehen, wann ich die Mail gelesen haben könnte. Allerdings kann er sich nicht darauf verlassen, da viele Spamfilter heute auch URLs "Anurfen" um diese auf Malware o.ä. zu untersuchen und in die Bewertung mit einzubeziehen.
Beim ersten Aufruf kam allerdings eine unverfängliche Seite zurück, die meinen Browser mit einem 302 auf die "http://localhost" weiterleitet.
PS C:\> $a= Invoke-WebRequest http://webmail-e2855a563d9.pagir.pt/?id=msxfaq.de -MaximumRedirection 0
Invoke-WebRequest: Response status code does not indicate success: 302 (Found).
PS C:\> $a
PS C:\> $error[0].exception
Response : StatusCode: 302, ReasonPhrase: 'Found', Version: 1.1, Content:
System.Net.Http.HttpConnectionResponseContent, Headers:
{
Location: http://localhost
Server: Microsoft-IIS/10.0
X-Powered-By: PHP/7.4.33
Date: Thu, 07 Sep 2023 14:27:52 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
}
Ein Abruf per SSL ist nicht möglich und liefert auch kein Zertifikat.
PS C:\> $a= Invoke-WebRequest https://webmail-e2855a563d9.pagir.pt/?id=msxfaq.de -MaximumRedirection 0 Invoke-WebRequest: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte
Redirect Teil 2
Mit einer Umleitung auf "localhost" kann eigentlich kein Fehler passieren. Allerdings habe ich die URL dann einige Stunden später noch einmal aufgerufen und diesmal kam dann eine Umleitung zu einem anderen Host zurück. Das "Verhalten" ist durchaus nicht unüblich, dass ein Angreifer die Malware erst verspätet aktiviert, um eben einen Check durch Spamfilter o.ä. zu umgehen.
PS C:\> $b= Invoke-WebRequest http://webmail-e2855a563d9.pagir.pt/?id=msxfaq.de -MaximumRedirection 0 -Method head
Invoke-WebRequest: Response status code does not indicate success: 302 (Found).
PS C:\> $b
PS C:\> $error[0].exception
Response : StatusCode: 302, ReasonPhrase: 'Found', Version: 1.1, Content:
System.Net.Http.HttpConnectionResponseContent, Headers:
{
Location: http://4449ee44.borbaadv.com/?fae02&id=msxfaq.de
Server: Microsoft-IIS/10.0
X-Powered-By: PHP/7.4.33
Date: Fri, 08 Sep 2023 14:25:19 GMT
Content-Length: 0
Content-Type: text/html; charset=UTF-8
}
Das ist eine neue Spur, die aber auf dem gleichen Webserver landet:
C:\> nslookup 4449ee44.borbaadv.com Name: 4449ee44.borbaadv.com Address: 104.166.159.66
Der DNS-Provider ist anscheinend auch in Brasilien.
C:\> nslookup -q=NS borbaadv.com borbaadv.com nameserver = ns520.hostgator.com.br borbaadv.com nameserver = ns521.hostgator.com.br
Zwar gibt es unter "borbaadv.com" auch eine Webseite mit eine Google-Maps-Anzeige in Brasilien und einer Rufnummer aber kein klassisches Impressum. Aber warum sollte eine Firma aus Brasilien einen Webhoster in Amsterdam, NL beauftragen? Die Domain würde ich damit nicht als echt ansehen.
Formular als Payload
Die URL habe ich dann wieder erst einmal PowerShell heruntergeladen aber sehr schnell gesehen, dass diesmal eine HTML-Datei geladen wird.
PS C:\> $c=Invoke-WebRequest "http://4449ee44.borbaadv.com/?fae02&id=msxfaq.de" -MaximumRedirection 0
PS C:\> $c
StatusCode : 200
StatusDescription : OK
Content :
<!DOCTYPE html>
<html><head>
<meta charset="utf-8">
<title>??rt?n-F?rmul?r | Hosteurope</title>
<link href="./file/favicon-he.ico" rel="shortcut icon" type="image/x-icon">
<style>…
Den Content habe ich dann in einer Sandbox mit einen Browser betrachtet und ich war dann schon etwas enttäuscht, dass es sich nur um ein triviales Formular zu Abgreifen von Kreditkartendaten handelt.
Die Seite enthält etwas JavaScript, um grundlegende Formulareingaben zu prüfen, z.B. Zeichen und Länge der Kreditkartennummer, CVV/CVC, Ablaufdatum.
Die eingegeben Daten werden dann als Strings in ein Objekt gepackt, nach JSON konvertiert und verschlüsselt, ehe Sie an den Server über "xhr.php" gepostet werden.
Was die PHP-Seite beim Hoster daraus macht, kann ich nicht mehr sehen. Ich kann aber die PHP-Seite einfach ohne Daten aufrufen und die Antwort sehen.
PS C:\> $d=Invoke-WebRequest "http://4449ee44.borbaadv.com/xhr.php" -Method POST
PS C:\> $d
StatusCode : 200
StatusDescription : OK
Content : {"status":false,"args":{"dmn":".\/unporcessable.php"}}
Die Datei "unporcessable.php" und auch mit der richtigen Schreibweise "unprocessable.php" ist auf dem Webserver nicht vorhanden.
Einschätzung
Es scheint sich immer noch zu lohnen, Kreditkarten mit Name, Nummer, CVC/CVV und Ablaufdatum einzusammeln. Scheinbar gibt es noch viele Akzeptanzstellen, die ohne physikalische Vorlage allein aufgrund dieser Daten eine Leistung erbringen. Die eingesetzten Methoden stellen auch allesamt keine besondere Leistung mehr dar. Hier ein paar DNS-Server und etwas Webhosting. Selbst die Phishing-Mail zeichnet sich nur dadurch aus, dass jemand einen Server einer Firma zu Versand missbraucht. Insofern: Business as Usual.
Ich habe den Hoster der Malwareseite über den Missbrauch informiert aber wir wissen alle, dass die Angreifer dann schnell wieder umziehen, was durch die Wildcard-Domains natürlich auch besonders einfach ist.
