Canva-Phishing
Heute hat mich eine Mail einer Hochschule erreicht, welche ich kurz teilen möchte. Das Konto des Absenders war kompromittiert, wobei ich keine Information darüber habe, ob der Absender mit MFA/2FA gesichert ist, eine Malware ein Access-Token ausgeleitet hat oder auf dem Client z.B. Outlook fernsteuern konnte. Das ist aber nicht maßgeblich, denn es wird immer wieder passieren.
Phishing per Mail
Wer nicht ganz unbedarft ist, sollte auf so eine Mail natürlich nicht hereinfallen. Das ist aber eher den mangelnden Fähigkeiten des Angreifers geschuldet:
Die Mail ist natürlich ähnlich einer "Teilen"-Mail aufgemacht, wie Sie sehr oft versendet wird. Der Absender was in dem Fall eine Person, die mir ca. eine Woche vorher allerdings auch schon eine erwünschte Mail gesendet hat und es daher eine bestehende Kommunikation gab. Die Prüfungen des Headers ergaben auch, dass alles seine Richtigkeit hatte.
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 40.107.20.124) smtp.rcpttodomain=<zieldomain_ersetzt>.de smtp.mailfrom=<absenderdomain_ersetzt>.de; dmarc=pass (p=none sp=none pct=100) action=none header.from=<absenderdomain_ersetzt>.de; dkim=pass (signature was verified) header.d=<absenderdomain_ersetzt>.de; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=<absenderdomain_ersetzt>.de] dkim=[1,1,header.d=<absenderdomain_ersetzt>.de] dmarc=[1,1,header.from=<absenderdomain_ersetzt>.de]) Authentication-Results: spf=pass (sender IP is 40.107.20.124) smtp.mailfrom=<absenderdomain_ersetzt>.de; dkim=pass (signature was verified) header.d=<absenderdomain_ersetzt>.de;dmarc=pass action=none header.from=<absenderdomain_ersetzt>.de;compauth=pass reason=100 Received-SPF: Pass (protection.outlook.com: domain of <absenderdomain_ersetzt>.de designates 40.107.20.124 as permitted sender) receiver=protection.outlook.com; client-ip=40.107.20.124; helo=40.107.20.124; pr=C Received: from de-s111-gw2.mail.cloud.nospamproxy.com (193.37.132.219) by DB5PEPF00014B8D.mail.protection.outlook.com (10.167.8.201) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8398.14 via Frontend Transport; Mon, 3 Feb 2025 09:31:54 +0000
Sowohl SPF als auch DKIM haben gepasst. Die Mail kam wirklich vom dem Postfach und einen Exchange Online Tenant.
Ich hoffe sie erinnern sich noch an meine Aussage, dass SPF/DKIM kein Spam/Phishing verhindern sondern nur die Fälschung von Absendern.
Link-Verfolgung
Den Link können Sie schon beim zeigen auf die blaue Fläche sehen und verweist auf die Plattform "Canva.com"
Das ist eine durchaus bekannte Internet-Plattform zum Erstellen und Teilen von Präsentationen etc. In meinem Fall war dann genau eine "Folie" zu sehen, die erneut einen anklickbaren Link enthält:
Die Folie suggeriert eine gewisse nähe zur Microsoft und könnte ja auch eine Vorschaltseite von OneDrive o.ä. sein. Diese Seite wurde durch den Angreifer bereitgestellt und könnte so jederzeit angepasst und verbessert werden. Der Link ist dann aber eine Umleitung über canva.com auf den eigentlichen Zielservice.
httpx://www.canva.com/link ?target=https%3A%2F%2Feod.uscourtcloudservice.com%2FcsQu1 &design=xxxx &accessRole=viewer &linkSource=document
Phishing-Seite
Der Link führt dann zu einer Seite, welche den Anwender zur Eingabe von Microsoft 365 Anmeldedaten verleiten soll. Die Seite wird über "Cloudflare" als CDN verteilt, so dass vorher erst einmal die Cloudflare-Schutzfunktionen gegen DoS und Robots kommen und normale Anwender das teilweise sogar schon positiv bewerten. Das ist aber ein Irrglaube. Die Webseite baut danach eine Anmeldeseite auf, die sehr stark der Microsoft 365 Anmeldeseite ähnelt und Falscheingaben beim Benutzer auch meldet
Allerding ist der Bereich "Sign in options" nicht anklickbar. Das fällt einem regulären Benutzer allerdings eher nicht auf.
Sie sollten ihre Anwender auf jeden Fall dahingehend schulen, dass eine Eingabe der Anmeldedaten aus dem internen Netzwerk , bei Nutzung von SSO. nicht erfolgt und wenn eine Rückfrage erfolgt, dann ist ein kritischer Blick auf die Adresszeile erforderlich.
Die Webseite ist mit einem TLS-Zertifikat von Google versehen.
Ein NSLOOKUP verweist auf Cloudflare
C:\> nslookup eod.uscourtcloudservice.com Name: eod.uscourtcloudservice.com Addresses: 2606:4700:3030::6815:2001 2606:4700:3030::6815:3001 2606:4700:3030::6815:7001 2606:4700:3030::6815:6001 2606:4700:3030::6815:5001 2606:4700:3030::6815:1001 2606:4700:3030::6815:4001 104.21.32.1 104.21.96.1 104.21.64.1 104.21.48.1 104.21.112.1 104.21.80.1 104.21.16.1
Wie schon so oft nutzen die Angreifer hier die bekannten Content Delivery Networks. Ich habe nicht weiter hinterfragt, ob das nun ein gekapertes Konto war oder mit einer falschen Kreditkarte gekauft wurde. Auch eine Abuse-Meldung habe ich mir erspart.
Benutzerprüfung
Sobald sie hier einen Benutzernamen eingeben, bekommen Sie eine Meldung, die eigentlich nur Anwender von Tenants mit ADFS sehen:
Bei der Phishing-Seite erfolgt diese Zwischenmeldung aber jedes Mal. Im Hintergrund wurde eine "NEXT.PHP" aufgerufen, die die per Post übergebenen Anmeldedaten vermutlich "versucht" hat.
Die Zieladresse hier ist aber ein Host der Domain "outlookbusinesslawyer.com". Die Root-Seite wird interessanterweise von Defender schon gemeldet:
Allerdings wird die Unterseite nicht angemängelt.
Der Name 6311340922.outlookbusinesslawyer.com löst auf die IP-Adresse 69.49.246.64 auf, welche per ReverseDNS auf 69-49-246-64.webhostbox.net verweist und angeblich in Atlanta unterwegs ist.
Sicher hat ein AV-Hersteller wie Microsoft das Problem eines Overblocking, wenn hinter einer Domain mehrere Subdomains von unterschiedlichen Kunden gehostet werden. Wenn aber die Basis-Domain schonnicht vertrauenswürdigt ist, dann sollten auch Subdomains der gleichen Einstufung unterliegen. Ich verstehe nicht, warum ein POST an diese Seite erlaubt ist.
Den Check können Sie natürlich auch per PowerShell mal eben missbrauchen und damit PHP-Rechenleistung auf Seite des Angreifers konsumieren.
Invoke-WebRequest -UseBasicParsing -Uri "https://6311340922.outlookbusinesslawyer.com/next.php" ` -Method "POST" ` -Body "do=check&email=phish@msxfaqlab.onmicrosoft.com"
Eine fehlerhafte Anfrage liefert dann den folgenden Content
{ "status":"error", "message":"We couldn't find an account with that username. Try another account." }
Wird hingegen eine gültige Anmeldeadresse angegeben, dann liefert der Webservice folgendes
{ "status":"success", "banner":null,"background":null,"federationLogin":"","type":"office" }
Die Webseite zeigt dann einen Kennwortdialog an
Für meine Tests habe ich dazu extra einen User, dessen Signing geblockt ist und natürlich gebe ich hier auch nie ein richtige Kennwort ein. Aber mit dem falschen Kennwort bekomme ich in EntraID hoffentlich einen "Failed Login Event". Der Post auf die gleiche "next.php" enthält nun neben dem User auch das Kennwort:
Ich frage mich schon, warum die Angreifer hier so "lesbare" APIs nutzen. Ein ausgehender Webproxy könnte solche Daten sehr einfach erkennen und für unbekannte URLs blocken. Als Angreifer hätte ich zumindest andere Variablenfelder gewählt und z.B. einfach verschlüsselt. Anscheinend laufen aber auch so noch genug unvorsichtige Anwender in die Falle.
Der Versuch ist in AzureAD auch zu sehen
ich habe dem Angreifer dann ein Testkonto in einem leeren Tenant ohne Lizenzen mit einem gültigen aber abgelaufenen Kennwort gegeben, Anscheinend ist darauf der Angreifer nicht vorbereitet gewesen, denn er hat das Kennwort nicht geändert.
Danach habe ich das Kennwort selbst neu vergeben und dem Angreifer das nun neue Kennwort zur Verfügung gestellt. Die XML-Antwort war dann
{ "status":"success", "message":"Login success", "redirect":"https:\/\/www.office.com\/?auth=2" }
Der Angreifer hat mich dann auf meine reguläre Office 365-Seite umgeleitet. Wenn ich da aber noch nicht angemeldet bin, dann bekomme ich erneut ein Anmeldefenster. Das ist dann aber das reguläre Fenster. Mit dem Wissen um das Kennwort habe ich nun auf weitere Zugriffe des Angreifers gewartet. Natürlich ist
Schnelle Reaktion
Weniger als 2 Stunden nach der Mail habe ich eine weitere Mail erhalten, in der durch den Absender der Fehler eingestanden und aus meiner Sicht sehr verständlich erklärt wurde.
Ob seitens des Absenders noch weitere Schritte unternommen werden, z.B. Meldung nach DSGVO oder forensische Analysen hinsichtlich weiterer Zugriffe über das kompromittierte Konto, geht aus dem Schreiben nicht hervor. Das sollte man aber nach so kurzer Zeit auch nicht erwarten. Ein Schaden mir mir nicht entstanden.
Defender
Die beiden aktiv genutzten URLs wurde auch ca. 24 Stunden noch immer nicht von Defender, Chrome u.a. als bösartig erkannt. Edge hat zumindest Da von dieser Domain natürlich gleich mehrere Personen in der Empfängerfirma angeschrieben wurden, konnten wir über das Messagetracking aktiv die Empfänger anschreiben und warnen. Über eine CustomRule in Defender haben wir die URL für alle Clients geblockt
Zusätzlich haben wir die Entra ID Signin-Logs auf fehlgeschlagene Anmeldungen untersucht, d.h. bei denen Kennworte falsch eingegeben wurden oder die 2FA-Anmeldung nach Eingabe des korrekten Kennworts den Zugriff unterbunden hat. Leider wurden wir hier auch wieder fündig, d.h. hier ist noch mal eine Awareness-Schulung für Mitarbeiter angesagt.
Lernkurve
Das Beispiel zeigt wieder mal, dass Menschen Fehler machen. Irgendwie hat ein Angreifer es geschafft, das Microsoft 365 Konto einer meiner Kommunikationspartner zu kapern, welches vermutlich nicht durch Multi Faktor Anmeldung gesichert wurde. Der Angreifer hat dann eine (schlecht gemachte) Phishing-Mail an vermutlich alle Personen gesendet, mit der der Absender in der Vergangenheit Kontakt hatte. Das dürfte über einen Zugriff auf den Ordner "Gesendete Objekte" passiert sind. Der Link in der Phishing-Mail zeigt aber die recht unverdächtige und häufig auch legitim genutzte Domain "canva.com", auf der eine "einseitige Präsentation" angezeigt wurde. Dabei wurde das Logo des Absenders genutzt, so dass der Besucher leichter getäuscht werden könnte. Erst dann gelangte er auf eine Webseite, die eine Microsoft 365 Anmeldemaske angezeigt hat. Wer hier dann Zugangsdaten zu einem anderen Microsoft 365 Konto eingegeben hat, welches nicht per 2FA gesichert ist, hat dem Angreifer die nächste Tür geöffnet.
Weitere Links
- Spam und Phishing
- OneDrive-Link Spam
- Fälschung
- QR-Code Phishing mit Microsoft 365
-
Überprüfen von Microsoft-Erstanwendungen in
Anmeldeberichten
https://learn.microsoft.com/de-de/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in