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