QR-Code Phishing

Im täglichen Wettstreit zwischen Spammer, Phishing und Spamabwehr gibt es manchmal auch ein paar Spams, die aus der Masse herausstechen.

Die Phishing Mail

Die Mail im Februar 2021 ist nicht die erste Nachricht mit einem QR-Code die in meinem Postfach gelandet ist. Es ist sogar eher selten aber in Verbindung mit einem Bank-Phishing ist es doch bemerkenswert, denn viele Banken nutzen mittlerweile anstatt dem Flackercode mittlerweile eine PhotoTAN, bei farbige QR-Codes abgescannt werden.

Ich habe den QR-Code verändert, damit er nicht mehr funktioniert und damit kein Schaden passiert.

Auch wenn der Text sehr "flüssig" geschrieben ist, ist nicht nur der Satz "Wir vertrauen darauf, dass wie Sie ausreichend informiert haben." seltsam. Auch das Ablaufdatum 02.09.2021 könnte drauf hinweisen, dass der Sender eigentlich den 9. Feb 2021 gemeint hat. Die Mail kam nämlich am 10. Feb 2021 an aber warum sollte eine Bank dann 7 Monate im Voraus informieren?

Das Bild wurde aber nicht mit der Mail gesendet, sondern auf dem Internet nachgeladen. Damit ein Spamfilter aber die BilderURL nicht als gefährlich ansieht, wurde ein Proxy von DuckDuckGo dazwischen geschaltet. Die Bild-URL wurde über folgende URL geladen.

hxxps://proxy.duckduckgo.com/iu/?u=hxxps://chenoneproduction.s3.ap-southeast-1.amazonaws.com/static/rakrak.png

Anscheinend haben alle Empfänger der Spam-Mail das gleiche Bild bekommen. Zumindest ist keine Individualisierung über Parameter zu erkennen und durch den Missbrauch über den Proxy von duckduckgo.com, kann der Spammer nicht mal eine Source-IP-Adresse ermitteln. Über den Weg konnte ich dann das Bild direkt auch noch herunterladen und einem QR-Decode vorwerfen. Die hinterlegte URL verwies wieder auf Amazon.

Phishing Site

Damit habe ich eine URL ,die von dem Opfer aufgerufen werden könnte. Vom Namen her scheint diese Seite in "Asia Pacific" gehostet zu sein. So eine URL rufe ich natürlich nicht im Browser auf, sondern in einer VM per PowerShell oder WGET o.ä.

PS C:\> Invoke-WebRequest -Uri https://chenoneproduction.s3.ap-southeast-1.amazonaws.com/static/Sparka.html

StatusCode        : 200
StatusDescription : OK
Content           : <!DOCTYPE html>
                    <html><head><title>Email link</title></head>
                    <body>
                    <meta http-equiv="refresh" content="1; URL=https://sparkasse.pushtan-de.app" />
                    </body></html>
RawContent        : HTTP/1.1 200 OK
                    x-amz-id-2: Hv7goFo60IySreip7+xiWk7Cew2+QvRyU775z47gMrznPK7ciz8IaQu3+OSR4Qamsh6tUxcqWHc=
                    x-amz-request-id: E5470694670889E2
                    Date: Sun, 14 Feb 2021 20:05:11 GMT
                    ETag: "83e11514390dc…
Headers           : {[x-amz-id-2, System.String[]], [x-amz-request-id, System.String[]], [Date, System.String[]],
                    [ETag, System.String[]]…}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 166
RelationLink      : {}

Schon auf den ersten Blick sieht man, dass die RawContentLength mit 166 Bytes nicht viel sein kann und relevant ist einfach nur ein Redirect über

<meta http-equiv="refresh" content="1; URL=https://sparkasse.pushtan-de.app" />

Hier lässt der Spammer also Potential brach liegen, da er keine individualisierte URLs verteilt. Die Phishing-Webseite hingegen ist auf den ersten Blick gut gemacht. So wird auch zuerst die Postleitzahl der Hausbank abgefragt und die Abfrage funktioniert sogar.

Der Trick mit dem QR-Code verhindert natürlich, dass jemand auf dem PC die hinterlegte Webseite aufruft und dort bessere Filter dies erkennen. Auf dem Smartphone kann der Empfänger direkt die Zugangsdaten eingeben und sieht vor allem die URL nicht komplett:

Wenn Sie eine gültige PLZ eingeben, dann wird eine Liste der dort erreichbaren Sparkassen angezeigt und mit der Auswahl einer Sparkasse wird auch eine passende Anmeldemaske angezeigt.

Hier funktionieren dann aber nur die beiden Eingabefelder und der Login-Button. Wenn man aber absichtlich falsche Daten eingibt, dann blinkt das Sparkassen-Symbol in folgender Meldung:

Nach einiger Zeit kommt dann auch die Fehlermeldung.

Ich kann mir nur vorstellen, dass die Serverapplikation im Hintergrund dann direkt eine Anmeldung bei der jeweiligen Bank versucht.

Wem hier nicht auffällt, dass er auf der "falschen Webseite" als "Reverse Proxy" arbeitet, kann auch durch TAN-Verfahren oder MFA o.a. nicht geschützt werden. Hier würde dann nur konsequente MTLS-Absicherung mit Client-Zertifikaten dies verhindern, was mit HBCI und Chipkarte der Fall ist.

Übrigens: Die Finanzverwaltungen mit Elster machen schon Client-Zertifikaten mit Browsern. Wann fangen die Banken damit an?

Das könnte für Banken zumindest ein Hebel sein. Sie könnten Anmeldungen von "Consumer"-Subnetzen und Firmensubnetzen etwas anders behandeln, als eine Anmeldung von einer statischen IP-Adresse, auf der vielleicht noch ein Webserver läuft.

Webhoster

Die IP-Adresse der Webseite verweist allerdings auf einen Server, der nicht per DNS rückwärts auflösbar ist.

C:\>nslookup sparkasse.pushtan-de.app
Name: sparkasse.pushtan-de.app
Address: 8.209.69.184

Laut einem Traceroute ist er aber wohl doch "in der Nähe" zu finden:

C:\>tracert 8.209.69.184

Routenverfolgung zu 8.209.69.184 über maximal 30 Hops
  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     9 ms     5 ms     7 ms  100.124.1.8
  3     5 ms     4 ms     6 ms  100.127.1.132
  4     7 ms     6 ms     6 ms  185.22.46.129
  5    10 ms    10 ms    10 ms  185.22.45.11
  6    13 ms    12 ms    10 ms  de-cix.alibaba-inc.com [80.81.195.60]
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8    65 ms    41 ms    55 ms  11.168.63.229
  9    14 ms    12 ms    10 ms  11.223.248.242
 10    13 ms    10 ms    10 ms  8.209.69.184

Bei Hop 6 bin ich wohl an einem Decix-Peering von alibaba-inc.com, von wo es mit 41-65ms weiter geht. Die IP-Adresse wird nicht vom RIPE verwaltet aber beim APNIC wurde ich fündig.

inetnum:        8.209.64.0 - 8.209.127.255
netname:        ALICLOUD-DE
descr:          Westendstrabe 28, 60325 Frankfurt am Main
country:        DE
admin-c:        ASEP1-AP
tech-c:         ASEP1-AP
status:         ALLOCATED NON-PORTABLE
mnt-by:         MAINT-ASEPL-SG
mnt-irt:        IRT-ASEPL-SG
last-modified:  2019-01-28T06:28:42Z
source:	        APNIC

% Abuse contact for '8.209.64.0 - 8.209.127.255' is 'anti-spam@list.alibaba-inc.com'

Quelle: https://wq.apnic.net/static/search.html?query=8.209.69.184

Hier gibt es zumindest eine Abuse-Adresse, der man den bösartigen Webserver melden kann.

DNS-Registrar

Auch die DNS-Dienste werden anscheinend von einer Firma in Deutschland bereit gestellt. Eine WHOIS-Suche nach dem Inhaber von "pushtan-de.app" ergibt:


Quelle https://www.eurodns.com/de/whois-suche/app-domain

Mittlerweile ist es üblich, dass der Inhaber sich hinter einem Registrar versteckt. Insofern kann auch nicht zuverlässig gesagt werden, ob die "private Person" tatsächlich in Moskau in Russland sitzt.

Mail Header - Sendgrid

Dann bleibt nur noch ein Blick auf den Header der Mail, den ich hier gekürzt wiedergebe. Sie können aber sehen, dass die Mail über ENDGRID als Versender mit gültiger DKIM-Signatur eingeliefert wurde.

Received: from 149.72.38.122 by netatwork.cloud.nospamproxy.com via connector
 NSP Cloud-Connector (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey384);
 Wed, 10 Feb 2021 10:28:38 GMT
X-NoSpamProxy-Rating: ***
X-NoSpamProxy-TrustedMail: no
X-NoSpamProxy-Scl: 3.00
X-NoSpamProxy-Gateway: 149.72.38.122:16010
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.net;
        h=content-transfer-encoding:content-type:from:mime-version:subject:to;
        s=smtpapi; bh=Vc9mOOWd3PE85APcEXut30ueNJ4g7oXFrHQ0b/B8ECU=;
        b=OmzxteJcrNpOSsFh4nq+E6xU2cVOgdTS16R0wMKkXeU3XrHov6nSd6ZiW7pmKyPrOuqq
        16jigTjGz9pXzOd8fIOn71JGP4WqUHDDxE1n+vtVfzSfEAY5MySiRVMpZZz3ZD/eVvSRFb
        IAyhkp2FgIidbEz38qDiNOfZmwT7AD4x8=
Received: by filterdrecv-p1las1-asgard-a-6c46446df5-dt4nq with SMTP id filterdrecv-p1las1-asgard-a-6c46446df5-dt4nq-14-6023B552-5B
        2021-02-10 10:28:34.705934827 +0000 UTC m=+41328.363198260
Received: from MTU0OTgzOTQ (unknown)
        by ismtpd0007p1lon1.sendgrid.net (SG)
        with HTTP
        id P3b9CPCWRFmPB7yriAIGYg
        Wed, 10 Feb 2021 10:28:34.488 +0000 (UTC)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=us-ascii
Date: Wed, 10 Feb 2021 10:28:34 +0000 (UTC)
From: Sparkasse <sparkasse@innoshop.co>
Mime-Version: 1.0
Message-ID: <P3b9CPCWRFmPB7yriAIGYg@ismtpd0007p1lon1.sendgrid.net>
Subject: Ihre PushTAN-Registrierung =?UTF-8?B?bMOkdWZ0?= bald ab
To: xxxxx@xxxxxx.de
X-Entity-ID: MghAKbdFGIc/3mmNoEteog==
Return-Path: bounces+15498394-8785-xxxxxx=xxxxxx.de@sendgrid.net
X-Microsoft-Antispam: BCL:0;

Auch wenn die Mail von NoSpamProxy nicht abgelehnt wurde, so wurde Sie zumindest mit einem Spamlevel von 3 belegt.

Gehackter Kunde?

Leider spreche und lese ich kein Arabisch und wenn ich der Google Translation glauben darf, dann ist es eine Firma in Riad, Saudi-Arabien, deren Zugang zu Sendgrid hier missbraucht wurde. Es kann aber auch sein, dass diese komplette Firma nur virtuell existiert, damit ein Konto bei Sendgrid angelegt werden kann.

Allerdings ist die Domain angeblich am 13 Januar 2018 (Siehe https://innoshop.co.ipaddress.com/) registriert worden. Sie sind vermutlich auch "nur" Opfer.

Meldung an Provider

Auch wenn der Kampf gegen Spam und Phishing eher dem eines Don Quijote gegen Windmühlen entspricht, gibt es hier doch einige Mitspieler, die ein Interesse und auch das Potential einer Gegenwehr haben. Vor allem sollte die Webseite mit dem direkten Zugriff auf das Homebanking als Proxy schnellstens von der Bildfläche verschwinden. Daher habe ich die verschiedenen Akteure auch informiert

Teilnehme Status

Redirect-Hoting Amazon AWD
https://aws.amazon.com/de/premiumsupport/knowledge-center/report-aws-abuse/

  • 14.2.2021 21:42 Meldung an Abuse abuse@amazonaws.com.xxx
  • Warten auf Rückmeldung

DNS-Registar Key Systems

  • 14.2.2021 20:53 Meldung an abuse@key-systems.net.xxx
  • 15.2.2021 22:43: Die Domain wurde gesperrt
Webhoster Alibaba
  • 14.2.2021 21:21 Meldung an Abuse anti-spam@list.alibaba-inc.com.xxx
  • 14.02.2021 21:27 Rückmeldung eines Serverfehler: "501 Syntax error in parameters or arguments"'
Mailversender SendGrid
https://sendgrid.com/report-spam/
  • 14.2.2021 21:52 Meldung an Abuse per Mail mit Header
  • Warten auf Rückmeldung

Ich bin mal auf die Rückmeldungen gespannt

Weitere Vorfälle

Es war ja klar, dass diese Mail nicht die einzige Mail war. Ich sammle hier weitere mit bekannte Muster.

Es geht hier nicht drum die Provider zu beschuldigen sondern ihnen zu zeigen, dass die Angreifer viele unterschiedliche Dienste nutzen (Teil kostenfrei, gekapert oder Trials) um ihre Spuren zu verwischen. Insofern müssen die "ausgenutzten" Dienste sich schon mal fragen lassen, wie sicher ihre Verifikation ist.

Die schädlichen URLs habe ich durch "hxxps" ungültig gemacht

Datum Einlieferung QR-Code Image QR-Code URL Phishing Domain DNS-Hoster Phishing Domain Hoster

12. Feb 2021

Sendgrid
Kundendomain "innoshop.co"

hxxps://proxy.duckduckgo.com/iu/?u=hxxps://chenoneproduction.s3.ap-southeast-1.amazonaws.com/static/rakrak.png

Amazon
hxxps://chenoneproduction.s3.ap-southeast-1.amazonaws.com.msxfaq/static/Sparka.html
hxxps://sparkasse.pushtan-de.app/
DNS: https://www.key-systems.net/

IP: 8.209.69.184

Alibaba Webhosting
https://www.alibabacloud.com/de/solutions/hosting

23. Feb 2021

Sendgrid
Kundendomain "gruen-gmbh.de"

hxxps://proxy.duckduckgo.com/iu/?u=hxxps://eachandother-com-assets.s3.eu-west-1.amazonaws.com/public/Uploads/676ac5b9b6/sparta.png

Amazon
hxxps://eachandother-com-assets.s3.eu-west-1.amazonaws.com.msxfaq/public/Uploads/676ac5b9b6/Sparka.html

hxxps://sparkasse.spushtan-de.app/
DNS: https://www.dnspod.com/

IP: 35.228.151.143

DNS: 143.151.228.35.bc.googleusercontent.com

Google Compute Engine

27. Feb 2021

Sendgrid
Kundendomain "dimedic.pl"

https://proxy.duckduckgo.com/iu/?u=http://dataexhaust.io/wp-admin/images/qr-code.png

Direkt zu hxxp://sparkasse.spushtan-de.app/

hxxp://sparkasse.spushtan-de.app/
DNS: https://www.dnspod.com/

IP: 35.228.151.143

DNS: 143.151.228.35.bc.googleusercontent.com

Google Compute Engine

Insbesondere sollten Firmen wie SendGrid ihren ausgehenden Spamschutz verbessern oder bei Verdachtsfällen die Mails anhalten und Rückfrage beim Inhaber des Kontos halten. Letztlich ist es das eigene Geschäftsmodell, was irgendwann drunter leidet.

Für mich sind die "Massensender" mittlerweile weniger vertrauenswürdig als ein einzelner Mailserver.

Zwischenstand

Es ist schon interessant und meine Kollegen von NoSpamProxy haben sich fast gefreut, dass eine Mail durch die Filter gekommen ist. Die meisten Spams und Phishing-Mails kommen ja gar nicht mehr an und daher ist eine Analyse solcher Mails durchaus interessant. Ich nehme von dem Beispiel mit, dass es auch weiter möglich ist, eine Phishing-Mail zuzustellen, auch wenn dazu schon Helfer benötigt werden.

  • Mailversender Sendgrid
    Sendgrid kann man kaum einen Vorwurf machen, wenn ein Kunde seine Zugangsdaten "teilt" und die Werbung mit deren Absenderadresse versendet wird. Bei vielen Filtern ist das schon "legitime" Mail. Aber es bedeutet auch, dass man letztlich niemandem vertrauen oder Bonuspunkte gutschreiben darf. Ich hoffe mal, dass die Abuse-Meldung hier schnell bearbeitet wird.
  • Webhoster
    Die meisten Webhoster werden auch keine Zeit oder Möglichkeiten haben, die bei ihnen abgelegten Webseiten auf Schadcode zu überwachen. Wenn der Betreiber per PHP hier eigenen Code geschrieben hat, dann wird auch ein Virenscanner nicht finden und bei wenigen Nutzer fällt die Seite nicht mal durch hohe Last auf
  • Domaininhaber
    Man könnte aber schon mal hinterfragen, wie eine Domäne "pushtan-de.app" auch noch über einen deutschen DNS-Service registriert werden kann. Das könnte schon als "Vorbereitung einer Straftat" auffallen. Da reichen ja ein paar einfache RegEx-Ausdrücke.

Sie können aber auch sehen, dass das Phishing-Geschäft ein multinationales Business ist und die Täter auch kein Problem haben, ein Geflecht unterschiedlicher Dienste einzusetzen. Anscheinend können Sie nicht wirklich nachverfolgt werden. Wenn schon die vorhandenen Datensätze nicht ausgewertet werden, dann frage ich mich schon, was unser Land mit weiteren Überwachungsbemühungen erreichen möchte. Für Spamfilter bleibt es auch in Zukunft interessant, denn SPF und DKIM und alle anderen Verfahren verhindern zwar das Fälschen der Absenderadresse aber wenn der Mensch als letztes Glied nicht aufpasst, dann reicht eine nicht erkannte Mail im Posteingang.

Die "sichere Lösung" wäre hier die Arbeit mit Client-Zertifikaten, wie Sie mit HBCI und Smartcard schon möglich sind und auch das Finanzamt mit Elster nutzt.

Erinnern sie sich noch an die "grünen Balken" in der Adressleiste für verifizierte Adressen. Vielleicht sollte es etwas ähnlich für "gute Webseiten" geben, bei denen Anmeldedaten normal sind. Oder Google, Chrome, Firefox lassen den Anwender eine "Whitelist" für Felder mit Kennwort führen. Einmal die Hausbank und andere "genutzte" Webseiten addiert und bei fremden URLs einfach warnen und bestätigen lassen.

Weitere Links