OneDrive-Link Spam

Auf der Seite Phishing mit Consent-Anforderung habe ich ja schon vorhergesagt, dass irgendwann auch SpamMails mit Links zu OneDrive oder anderen Cloud-Diensten enthalten sind, die über diesen Weg dann Malware verteilen oder den Zugriff auf ihre Daten anfordern. Anfang März 2020 kann dann die erste Mail, auf die ich fast reingefallen wäre.

Spam-Mail

Die Mail wurde von einem gekaperten Konto gesendet und die Firma hat dies am gleichen Tag gemerkt.

In dem Fall kennen ich den Absender nicht und bin erst einmal vorsichtig. Darauf sollten Sie sich aber nicht verlassen, denn Emotet und Co finden hier schon ihre könnte hier auch ein realer Absender stehen.

Natürlich ist die Mail nicht perfekt, weil sie einmal an "Undisclosed recipients" geht und auch der Disclaimer mit "T: <nummer>" nicht üblich ist. Aber es sieht aus wie eine Mail mit einem ungefährlichen PDF-Anlage. Die Profis" würden nun auf das kleine Dreieck klicken und die Anlage erst mal als PDF auf das Dateisystem ablegen und vielleicht untersuchen.

Das sollte Sie aber unterlassen, denn das ist keine Anlage und der Links wird aktiviert.

Wenn die die Mail öffnen, dann sehen sie genauer, dass sehen Sie eine Mail mit einem "Bild" ist, welches nur den Anschein erweckt, dass sie eine Outlook Anlage anklicken. In Realität ist es aber eine Mai, welche direkt mit einem Bild anfängt und so aussieht, wie Outlook mit einer Anlage.

Egal, wo sie drauf drücken: Sie landen immer auf dem Link, der hier auch noch auf eine Adresse bei Microsoft verweist. Wenn Sie die Mail aber nur als "Text only" anzeigen lassen, dann fällt der Missbrauch eher auf:

Das Problem ist nur, dass die meisten Mails heute als "Text Only" gar nicht mehr sinnvoll lesbar sind und daher sie den Anwender diesen "Default" nicht mehr zumuten können. Im Dezember 2020 hat ein Spammer die Mail schon etwas "schicker" aufgemacht:

Aber natürlich sollten Sie auch darauf nicht reinfallen.

Der Link zu login.microsoftonline.com

Die Mail gibt ja vor, dass mit jemand eine OneDrive for Business Datei bereitgestellt hat. Also bin ich auf einen abgeschotteten PC gegangen und habe die URL eingegeben. Wie nicht anders zu erwarten, hat Microsoft einen Anmeldedialog geliefert in dem ich meine Anmeldedaten eingeben konnte. Ich habe dazu einen Test-Tenant ohne Daten o.ä. verwendet. Die URL war tatsächlich bei Microsoft mit korrektem Zertifikat.

http://login.microsoftonline.com/common/oauth2/authorize?client_id=b7bd4978-7067-4b39-957a-6c31a80cf57c

Wenn ich auf einem PC im Firmennetzwerk gewesen wäre und eine Anmeldung per Seamless Single Sign On möglich ist, hätte ich nicht einmal die Dialogabfrage bekommen und wäre direkt auf dem Ziel gelandet. Fiddler zeigt das auch entsprechend an.

Die Umleitung hat mich aber nicht auf OneDrive verleitet sondern auf eine Webseite im Namensraum "web.core.windows.net".

Ich bin natürlich sehr erstaunt, dass ich über login.microsoftonline.com und der Angabe einer Client-ID direkt einen Redirect auf eine andere externe Webseite anfordern kann.

https://42781.z13.web.core.windows.net

Es ist auch nicht "login.microsoftonline.com. Dennoch ist die Verbindung natürlich per HTTPS gesichert und im Grund vertrauswürdig.

Dahinter verbirgt sich technisch aber ein Azure Blog Storage, der schon häufiger für Spam und Phishing missbraucht wurden. Microsoft hat diese Webseite auch innerhalb weniger Stunden entfernt.

Die eigene Falle

Natürlich hat mich interessiert, wie der Angreifer das gemacht hat. Es kann ja nur eine Art "Enterprise App" oder App Registration gewesen sein, die er als Besitzer einer Azure Subscription eingerichtet hat. Also habe ich das mit meinem Spiel-Tenant selbst macht und unter https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps eine neue App mit folgenden eingaben registriert.

In der Übersicht konnte ich dann die AppID auslesen. Damit hat die Umleitung aber noch nicht geklappt. Unter "Authentication" musste ich noch "Implicit Grant" aktivieren.

Danach war aber schon alle fertig, um einen Link zum "Versand" zu haben. Sie können es gerne mal ausprobieren

http://login.microsoftonline.com/common/oauth2/authorize?client_id=ad9edce3-988f-4297-bc89-a683756bea59
Diese URL werde ich zu gegebener Zeit auch wieder abschalten.

In meinem Tenant unter "Logins" finde ich dann die entsprechenden Anmeldungen an der App.

Interessant ist nun natürlich noch, was der Client an die andere Seite sendet. Anstatt nun eine PHP-Seite auf meiner MSXFAQ anzulegen, habe ich einfach mit geschaut, welche Daten der Browser an den Webserver sendet.

Die Request-URL habe ich etwas aufgeschlüsselt.

So wie ich die App eingerichtet habe, bekomme ich auf der Zielseite keine weiteren Informationen über den Anwender oder gar ein AUTH-Token sondern nur die Fehlermeldung an meine "App", auf die ich entsprechend reagieren könnte. Ich habe natürlich nicht geprüft, ob man durch Angabe eines "response_type" und anderer Daten den Client dazu bringen kann, nicht doch ein OAUTH-Token an die Applikation zu übermitteln.

Aktuell sehen ich nur die Funktion eines "Redirect" von einer vertrauenswürdigen Domäne wie login.microsoftonline.com auf eine eigene Webseite, die dann z.B. einer OneDrive Seite nachgebildet sein kann. Für Anwender ein kaum durchschaubares Angriffsmuster.

Noch mal gut gegangen?

Das war also noch keine direkte Attacke auf ein Benutzerkonto mit einem "Consent"-Versuch. Aber die Formatierung der Mail hatte ich so noch nicht gesehen und ein normaler Anwender dürfte darauf sehr einfach hereinfallen. In der Mail selbst sind keine bösen Links. Es sind sogar eher "gute" Links, die man auch sonst sehr häufig finden wird. Dennoch sieht der Angreifer natürlich die HTTP-Requests auf seine Malware-Site. Er kann also die URL auslesen und er bekommt vermutlich auch das OAUTH-Ticket des angemeldeten Benutzers.

Damit stellen sich mir Fragen:

  • Outlook/OWA Layout.
    Anwender können auf die Mail viel einfacher hereinfallen, wenn eine Applikation so wichtige Informationen wie Anlagen ungeschickt anzeigt. Ich kann mir nur kaum vorstellen, wie man es wirklich besser machen kann.
  • Wie findet man den "Täter" hinter der "client_id"
    Ich habe verschiedene Wege dies an Microsoft zu melden. Ich bin mal gespannt, wie schnell eine Antwort kommt
  • HTTP-Redirect über Azure Anmeldedienst?
    Sollte es wirklich so einfach sein, als Angreifer über eine Azure-Application eines Test-Tenants einen Redirector auf Malware zu erhalten. Welche Parameter können den Client dazu verleiten, noch mehr Informationen preiszugeben?

Damit sollte die URL "login.microsoftonline.com" auf keinen Fall in einer Allowlist landen sondern eher negativ in einer Mail bewertet werden. Denn Links zu Yammer, Teams aber auch OneDrive haben in der Regel eine andere URL, z.B.

Teams     https://urlshortener.teams.microsoft.com/guid und https://teams.microsoft.com/*
Yammer    https://www.yammer.com/<yammergroup>/threads/<MessageID>?trk_event=dd_thread_click&allow_app_redirect=1 
OneDrive  https://1drv.ms/

Dieses Vorgehen sind also ganz neue Anforderungen an Proxy-Server und Spamfilter, denn die Mail selbst hat bis auf das eigentliche Anschreiben kaum Ansätze für eine Erkennung gelassen. Das Bild ist unverdächtig und die URLs gehen zu Microsoft Online. Das könnten einige Spamfilter sogar irrtümlich positiv bewerten.

Weitere Links