QR-Code Phishing mit Microsoft 365

Diese Seite beschreibt einen Phishing-Versuch auf mein Anmeldekonto bei Microsoft 365, der über einen QR-Code einer Mail gestartet wurde.

Eine Kurzversion, was beim Aufruf auf einem IPhone passiert, finden Sie hier
https://youtu.be/1hZsLR0NtY8

Ich habe die Links zur Malware nicht "klickbar" gemacht und bin sicher, dass sie einige Tage später auch nicht mehr funktionieren. Dennoch sollten sie solche Links NIE NIE NIE in einem Browser aufrufen, in dem Sie schon an einem Tenant angemeldet sind, denn es könnte passieren, das Sie damit schon ein Access Token an den Angreifer senden. Solche Tests machen Sie am besten in einer separaten VM oder System. Selbst ein Edge mit "Application Guard"-Windows oder ein Gast-Browser wäre mir zu unsicher.

Das Ergebnis dieser Seite hat auch mich überrascht und mir vor allem gezeigt, dass die "Security Defaults" nicht ausreichend sind. Ich bin sicher, dass viele Firmen noch nicht wirklich verstanden haben, dass Security Defaults kein MFA für Anwender vorschreiben und daher dieser Angriff letztlich in einer produktiven Umgebung extrem schädlich und gefährlich gewesen wäre.

Die Mail mit QR-Code

Startpunkt war eine Mail von extern, die durch den Spamfilter nicht als Bösartig erkannt wurde. Das ist auch nicht so einfach, da in der Mail selbst keine bösartigen Links zu sehen sind. Warum der QR-Code nicht Schwarz/Weiss, sondern Rot/Blau ist, soll vielleicht Bilderkennungen verwirren.

Hinweis: QR-Code ist absichtlich unkenntlich gemacht.

Hier hat der Angreifer aber definitiv noch Verbesserungspotential, denn darauf sollte eigentlich kein Mensch reinfallen. Aber es reicht, wie so oft, nur ein Anwender, der in der Eile solch einen QR-Code auf dem Smartphone anklickt.

SMTP-Header Analyse

Der Absender behauptet "Netatwork|Maintenance <contact@tc.michelin.eu>" zu sein. Schauen wir uns den relevanten Teil im Header einmal an. Die ersten Zeile  zeigt den SMTP-Header von Exchange Online und ist nicht weiter relevant:

Received: from AMS0EPF000001B1.eurprd05.prod.outlook.com
 (2603:10a6:20b:464:cafe::59) by AS9PR06CA0086.outlook.office365.com
 (2603:10a6:20b:464::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.26 via Frontend
 Transport; Wed, 13 Dec 2023 22:38:04 +0000

Die nächste Zeile zeigt, dass der "SMTP-Mail-From" aber behauptet, dass die Mail von der Subdomain von "michelin.eu" kommt. kurzer Check zeigt, dass die Domain zwar nicht auf HTTPS reagiert aber unter HTTP eine Umleitung auf den bekannten Reifenhersteller https://www.michelin.com hat.

Authentication-Results: spf=pass (sender IP is 212.227.126.187)
 smtp.mailfrom=tc.michelin.eu; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=tc.michelin.eu;compauth=pass
 reason=100
Received-SPF: Pass (protection.outlook.com: domain of tc.michelin.eu
 designates 212.227.126.187 as permitted sender)
 receiver=protection.outlook.com; client-ip=212.227.126.187;
 helo=212.227.126.187; pr=C

Die IP-Adresse 212.227.126.187 ist laut WHOIS aber bei IONOS angesiedelt. und der SPF-Record passt darauf.

v=spf1 mx include:_spf.perfora.net include:_spf.kundenserver.de ~all

Warum Michelin hier ein "~ALL" am Ende macht, bleibt ihnen überlassen aber auch ein "-ALL" hätte hier nicht weiter geholfen denn die SourceIP hat ja gestimmt.

Nun kommt ein Zwischenschritt, weil die Mail nicht direkt zu Exchange Online gesendet wurde, sondern erst einmal durch NoSpamProxy  (Virenschutz, Spamfilter, SMIME-Gateway) musste.

Received: from de-s111-gw2.mail.cloud.nospamproxy.com (193.37.132.219) by
 AMS0EPF000001B1.mail.protection.outlook.com (10.167.16.165) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.7091.26 via Frontend Transport; Wed, 13 Dec 2023 22:38:04 +0000

Erst dann sehen wir die Einlieferung von einem IONOS-Server an NoSpamProxy. NoSpamProxy macht natürlich auch SPF-Checks aber die waren hier ja sogar gültig.

Received: from 212.227.126.187 by de-s111-gw2.mail.cloud.nospamproxy.com via
 connector Default receive connector (Tls12, Aes256, Sha384,
 DiffieHellmanEllipticKey384); Wed, 13 Dec 2023 22:38:01 GMT

NoSpamProxy schreibt auch den "MAIL FROM" des Envelope mit in den Header, so dass wir auch dies wissen und mit dem "From" im Header erkennen, das ein DMARC-Alignment auch erfüllt ist.

X-NetatworkMailGateway-Sender: contact@tc.michelin.eu
X-NoSpamProxy-Gateway: 212.227.126.187:51615

Der folgende Header wurde auch von IONOS addiert und zeigt die IP-Adresse des Einlieferer. Die 134.255.254.177 verweist auf einem anderen deutschen Hoster

• ipinfo.io: DeinServerHost - Hosting , ITP-Solutions UG & Co. KG
  https://ipinfo.io/AS197071/134.255.254.0/24

Received: from [134.255.254.177] ([134.255.254.177]) by
 mrelayeu.kundenserver.de (mreue009 [213.165.67.102]) with ESMTPSA (Nemesis)
 id 1MbAYi-1rkgpA2sum-00bcTJ for <frank.carius@netatwork.de>; Wed, 13 Dec 2023
 23:37:56 +0100

Danach finden sich nur noch die in Outlook angezeigten Daten und anderen nicht relevante Informationen:

From: Netatwork|Maintenance <contact@tc.michelin.eu>
To: frank.carius@netatwork.de
Subject: Warning Notification ID Request Wednesday-December-2023 23:37 PM
Date: Wed, 13 Dec 2023 22:37:56 -0000
Message-ID: <170250707640.3152.11076509529532332389@tc.michelin.eu>

Entweder hat der Angreifer die Hoheit über den Server bei 134.255.254.177 oder konnte dort ein Skript missbrauchen. Komisch ist aber auch, das die Mail von 134.255.254.177 über IONOS als Relay gesendet werden konnte und wurde, denn der MX-Record für netatwork.de verweist nicht auf IONOS. Hier muss also ein Smarthost konfiguriert sein und IONOS muss dem Absender vertrauen, z.B. anhand einer Authentifizierung. Leider steht dazu im Header nichts. Auf jeden Fall sollten die Administratoren von Michelin prüfen, ob ihnen der Server bei 134.255.254.177 gehört oder warum er über ihre Domain und IONOS Mails versenden kann. Wobei das durchaus ein Problem bei IONOS sein kann, was erst in naher Zukunft gelöst werden soll:

• IONOS SMTPAUTH Fail

Der QR-Code

Sie können den QR-Code mit dem Smartphone abfotografieren oder auf diversen Webseite (z.B. https://zxing.org/w/code.jspx o.a.) als Bild hochladen und decodieren lassen. Der QR-Code enthält nur eine URL auf die folgende Adresse (Mailadresse habe ich getauscht)

https://pqgob.chertype.ru/v932y9mr/#phish@msxfaqlab.de

Per DNS landen Sie auf 188.114.97.0, die zu Cloudflare gehört:

Quelle: https://ipinfo.io/AS13335/188.114.97.0/24

Der Aufruf der Webseite auf einem PC hat sehr schnell die Seite geblockt. Aber Smartphones kommen in der Regel nicht in den Genuss solcher Dienste.

Es wäre für Provider sicher einfach, solche Hostnamen auf dem Netzwerklevel zu blocken.

Wenn Sie auf dem PC diese Warnung ignorieren, dann sehen Sie das klassische Microsoft 36 Anmeldebild und je nach Auflösung sogar mit Hintergrund. Sie können sogar einen anderen Anmeldenamen in die URL eingeben, der dann entsprechend übernommen wird. So sehen wir auch, dass die Malware den Benutzer in Echtzeit auch überprüft:

Erst wenn ich einen gültigen User angebe, komme ich hier weiter zur Kennworteingabe. Ein falsches Kennwort wird auch direkt erkannt.

Die ganzen Bilder kommen übrigens direkt von Microsoft und nicht von der URL pqgob.chertype.ru.

An der Stelle habe ich die Nutzung meines Kontos abgebrochen und die gleichen Schritte mit einem Test-User in einem separaten Tenant wiederholt.
Ein nicht sensibilisierter Mitarbeiter dürfte sehr leicht darauf einfallen.

Nur wenn das Kennwort richtig ist, kommt der bekannte Dialog. Das Kennwort wird hier also schon geprüft.

Achtung: Wenn Sie diesen "Stay signed in" Dialog sehen, dann wurden sie schon erfolgreich angemeldet und MFA entweder erfolgt ist oder nicht erforderlich war.

Natürlich sind in dem Tenant die Security Defaults aktiv und ein Angreifer kann bei MFA-Anfragen nur auf einen von zwei Wegen reagieren: Er kann die Anmeldung abbrechen und einen Fehler darauf anzeigen.

Die Alternative wäre die MFA-Abfrage auch noch durchzureichen und damit die Anmeldung erfolgreich abzuschießen. Das Kennwort alleine würde dem Angreifer später natürlich nicht mehr weiterhelfen aber ein als "Man in the middle" abgefangenes OAUTH/SAML-Token kann er durchaus einige Zeit weiter verwenden.

GET und POST

Nachdem wir nun lange genug an der Oberfläche rumgekratzt haben, schauen wir uns die Kommunikation im Unterbau an. In dem Ausschnitt sehen wir noch das Ende der Cloudflare-Kommunikation und dann die Anrufe von weiteren Inhalten.

POST /INFO-URL

Zuerst sind mit die beiden "POST"-Befehle aufgefallen, welche keine Parameter auf der URL mit übergeben.

Sie werden mit "200 OK" beantwortet.

Die Payloads sind jeweils JSON-Strukturen, die eigentlich nur einen Code und einen Status enthalten:

Post1:
type=9&pagelink=s8y8b9n4

Post2: 
pagelink=s8y8b9n4&type=3&ip=180.6.210.27&useragent=Mozilla%2F5.0+(Window....

Vermutlich verfolgt der Angreifer hier nur den Fortschritt, denn hier steht kein Benutzername und erst recht kein Kennwort.

Websocket

Auf der Seite Websockets habe ich schon über diese Technik einer bidirektionalen Kommunikation geschrieben und in dem Trace ist dies nur eine kleine Zeile, bei der auf den GET-Request ein "101 Switching Protocols" folgt:

Erst die Payload offenbart die Übertragungen.

Der Angreifer betreibt unter "wss://pqgob.chertype.ru//web6socket/socket.io/?type=User&EIO=4&transport=websocket" einen Websocket Server zur Annahme der erlangten Zugangsdaten. Wie der Angreifer diese dann weiter verwertet, ist hier dann nicht zu sehen.

JavaScript

Im Trace ist zu sehen, das hier ein JavaScript von der Adresse "https://pqgob.chertype.ru/v932y9mr/myscr293504.js" nachgeladen wird, das schwer leserhaft ist.

Über einen JavaScript Debugger ist aber schnell zu sehen, dass dies im wesentlichen die Cloudflare-Captcha-Seite aufbaut aber wohl keine weitere Malware enthalten ist.

Defender for Endpoint

Während meine Tests auf einem separierten Smartphone für eine IT-Abteilung nicht sichtbar waren, wurden die Analysen mit einem in "Defender for Endpoint" eingebundenen PC sehr schnell erkannt.

Insofern war das wieder ein unfreiwilliger Test des Net at Work SOC und der Security-Bearbeiter, die mich freundlich gefragt haben, ob das meine Absicht war.

Azure Audit Logs

Ich habe über die Phishing-Seite einmal ein "gültiges Kennwort" eingegeben und damit veruntreut. Das Konto selbst hat natürlich MFA aktiv und damit sollte ich spätere Anmeldungen in den Azure SigninLogs sehen können. Zuerst habe ich mir das Auditlog des Benutzers angeschaut. Dort sehen ich noch wie ich den Benutzer angelegt habe aber danach keine weitere Änderung. Der Angreifer hat also keine eigene MFA-Tokens o.ä. eingetragen.

Das Kennwort war gültig aber MFA war natürlich über die Security Defaults aktiv.

Azure SignIn Logs

Zumindest dachte ich, dass MFA und Security Defaults eine Missbrauch unterbinden sollten. Ich habe auch nie die MFA-Credentials verwendet oder eingegeben. Die SignIn-Logs zeigen aber interessante Events. Grün umrandet sehen Sie zuerst die erfolglosen Anmeldungen ohne MFA über einen Server, den Microsoft in Russland platziert. (aber ASN57043 https://www.ip2location.com/as57043). Das waren meine Eingaben auf der Fake-Seite mit dem falschen Kennwort. Da hat dann wohl das Backend direkt geprüft, ob die eingegebenen Daten in Ordnung sind. Von der Entfernung könnte es auch außerhalb der EU sein.

Die IP-Adresse ist sogar per DNS auf einen Namen aufzulösen aber war zu dem Zeitpunkt nicht per 80/443/25 zu erreichen.

C:\>nslookup 212.8.229.180

Name: edwards.bendtheknee.net
Address: 212.8.229.180

Ca. 24 Minuten später um 1:11:32 PM habe ich noch ein Anmeldeversuch von 212.115.124.201 angeblich aus Israel (Petah Tikva, Hamerkaz, IL) gesehen. Wie zuverlässig  die Geolokation ist, sei aber mal dahingestellt da es das gleiche ASN 57043 ist.

Die grünen Anmeldungen nutzen angeblich Linux und Chrome 120 als Plattform:

Das kann natürlich alles gefälscht sein, denn ein UserAgent zu verändert ist einfach und die Daten über einen HTTP-Proxy zu schleifen ist auch kein Kunstwerk

Überraschend sind dann aber die rot umrandeten erfolgreichen Anmeldungen aus den Niederlanden (ASN 58073 https://www.ip2location.com/as58073) etwas später. Sie sehen hier durchaus Anmeldungen mit "Single-Factor" über die Applikation "Office365 Shell WCSS". Die passieren eigentlich nur, wenn der Angreifer tatsächlich schon ein Authentifizierungstoken erhalten hätte. Das würde aber erfordern, dass ich mich mindestens einmal unter der Kontrolle des Angreifers erfolgreich angemeldet habe.

Bislang kann ich noch nicht nachvollziehen, wie die Phisher diese Zugriffe erlangen konnten. Sie hatten zwar absichtlich gültige Benutzernamen und Kennwort aber ich hatte nie eine Anmeldung per MFA abgeschlossen, d.h. definitiv kein EinmalToken eingegeben. Die Authenticator App war dazu auch nicht verbunden, sondern ich hätte manuell die Nummer eingeben müssen

Dennoch finde ich eine Anmeldung, die zwar "Interrupted" wurde aber gut anzeigt, dass die Anmeldung mit dem "Password in the cloud" erfolgreich war.

Nur kann ich beim besten Willen hier nicht nachvollziehen, warum allein mit Username und Kennwort eine Anmeldung möglich war, denn kurz darauf sehen ich Zugriffe wie:

Bei diesem und den weiteren Zugriffen wurden folgende Application ID und Ressourcen verwenden. Folgenden Clients auf die entsprechenden Ressourcen wurden protokolliert:

Anscheinend versucht der Angreifer alle möglichen APIs durch um zu sehen, wo der Benutzer Berechtigungen haben könnte. Alle Zugriffe erfolgten innerhalb weniger Sekunden und deutet auf einen vollautomatischen Prozess hin. Interessant finde ich, dass der Code sich mit unterschiedlichen Client APIs ausgegeben hat, d.h. er muss schon die Credentials für diese APIs extrahiert und im Code hinterlegt haben.

Da stellt sich dann die Frage, inwieweit der Client Application ID generell vertraut werden kann.

Leider hat dieser Spieltenant keine Lizenzen, die mir ein Tracking der einzelnen Aktionen erlauben. Ich konnte damit nicht weiter analysieren, ob die Anmeldung wirklich erfolgreich war und welche Zugriffe oder Veränderungen versucht wurden. Daher endet die weitergehende Analyse hier.

• Access Microsoft Graph activity logs (preview)
  https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview

Mit produktiven Konten ist das Risiko sehr viel höher. Wenn Sie z.B. in einem Browser mit ihrem Tenant arbeiten und dann z.B. in OWA auf eine Mail klicken, die auf eine Malware-Seite verweist, dann kann der Angreifer sehr wohl so ein Authentication-Token abgreifen und sich dann ohne weitere Authentifizierung und MFA als Anwender ausgeben

Security Defaults sind unsicher

Die erfolgreichen Anmeldungen haben mir natürlich keine Ruhe gelassen, und mit dem Net at Work Security Team haben wir dann auch sehr schnell die Ursache gefunden.

Spoiler: Es funktioniert genau, wie Microsoft es vorgesehen hat aber die Security Defaults sind einfach Mist.

Um den Angriff zu testen habe ich mir einen Benutzer "phish@msxfaqlab.de" mit einem Kennwort angelegt und mit erstmalig angemeldet. EntraID hat dann natürlich eine MFA-Einrichtung erfordert, weil die Security Defaults aktiviert sind.

Dies bedeutet aber nicht, dass nun alle Benutzer durch MFA gesichert sind, sondern dass Microsoft diesen Schutz nur für Mitglieder in den verschiedenen administrativen Gruppen aktiv ist.

Administrators have increased access to your environment. Because of the power these highly privileged accounts have, you should treat them with special care. One common method to improve the protection of privileged accounts is to require a stronger form of account verification for sign-in, like requiring multifactor authentication.
After registration is finished, the following administrator roles will be required to do multifactor authentication every time they sign in: <hier folgt dann eine Auflistung der Admin-Gruppen)>
Quelle: Security defaults in Microsoft Entra ID - Require administrators to do multifactor authentication https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults?WT.mc_id=Portal-Microsoft_AAD_IAM#require-administrators-to-do-multifactor-authentication

Kurz darunter steht dann aber auch :

Require users to do multifactor authentication when necessary
... We tend to think that administrator accounts are the only accounts that need extra layers of authentication. 
... After users complete registration, they'll be prompted for another authentication whenever necessary.
Microsoft decides when a user is prompted for multifactor authentication, based on factors such as location, device, role and task. ...

Quelle: Security defaults in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults?WT.mc_id=Portal-Microsoft_AAD_IAM#require-users-to-do-multifactor-authentication-when-necessary

Auf einer anderen findet sich dann noch:

For Microsoft Entra ID Free tenants without Conditional Access, you can use security defaults to protect users. Users are prompted for MFA as needed, but you can't define your own rules to control the behavior.
Quelle: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates 

Was hier so locker beschrieben wird, ist eine deutliche und in meinem Beispiel hier misslungene Absicherung eines Benutzer mit MFA-Token. Aus den SignIn-Logs geht hervor, dass ich mit einige Minuten vorher in Deutschland angemeldet habe und dann eine Anmeldung aus Moskau mit den gleichen Anmeldedaten (Username/Kennwort) erfolgt ist. Diese wurde dann wohl durch MFA abgeblockt, was den Angreifer dann dazu gebracht hat, mit den den Anmeldedaten dann 1,5h später über ein System in den Niederlanden die Anmeldung erneut zu versuchen.

Anscheinend kennen die Angreifer die Microsoft Logik soweit, dass dann die Risiko-Erkennung vielleicht nicht mehr anschlägt:

@Microsoft: Bitte ändert eure Logik so, dass eine fehlgeschlagene Anmeldung per MFA immer erst eine erfolgreiche MFA-Anmeldung erzwingt, ehe dann wieder eine einfache Anmeldung erlaubt wird und MFA immer erforderlich ist, zumindest wenn der Netzwerkstandort des Clients das erste Mal innerhalb einer .Zeit genutzt wird oder es kein irgendwie "bekanntes" Gerät ist.
Mit dem heutigen Wissen, behaupte ich, dass "Security Defaults" nicht ausreichend sicher ist und nur Administratoren aber keine Benutzer absichert. Die Benutzer sind aber die Zugänge, die Zugriff auf die Daten und Informationen haben. Hier ist MFA nicht automatisch aktiv sondern nur, wenn es Microsoft als erforderlich ansieht.

Genau deswegen konnte sich der Angreifer relativ ungestört in der Umgebung umschauen und hätte sogar das Kennwort ändern können. Aber anscheinend hat er recht schnell erkannt. dass hier nichts zu holen ist, denn ohne Lizenz, ohne Daten und in einem leeren Tenant macht es nun mal nicht so viel Spaß und laut Messagetracking konnte er z.B. auch keine Mails versenden.

• Security Defaults
  https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults

Security Default Alternative

Dennoch sollten Sie überlegen, wie sie ihren Tenant besser absichern. Ich sehe da nur zwei Optionen:

• Verzicht auf Security Defaults und "Per User MFA" pro User aktivieren
  Das ist für die Anwender natürlich nerviger, weil Sie nun immer per MFA eine neue Anmeldung bestätigen müssen und "LegacyAuth"-Anmeldungen auch nicht möglich sind. Aber es ist sicher und hätte in dem Phishin-Angriff natürlich geholten.
  
  https://account.activedirectory.windowsazure.com/usermanagement/multifactorverification.aspx
• AzureAD P1/EntraIDP1 Conditional Access
  Die leistungsfähigere Alternative ist natürlich eine EntraID 1-Lizenz mit entsprechenden Regeln in Conditional Access. Damit sind weitere Kosten verbunden, (ca. 5€/User/Monat) aber Sicherheit hat ihren Preis und vielleicht sind mit enthaltene Funktionen wie Azure AD Application Proxy. Wenn Sie in dem Zuge dann von ihrem Office 365 E3-Plan vielleicht noch EMS E3 addieren, dann haben Sie für wenig Aufpreis gleich Intune zur Verwaltung dabei und mit Microsoft 365 E3 wäre auch Windows 10 Enterprise (Bitlocker etc

Auf jeden Fall würde ich mich nicht mehr allein darauf verlassen, dass die "Security Defaults" meinen Tenant und vor allem meine User und meine Daten schützen

• Set up your users with multifactor authentication
  https://learn.microsoft.com/en-us/partner-center/mfa-for-users
• Enable per-user Microsoft Entra multifactor authentication to secure sign-in events
  https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates
• Security Defaults
  https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults

Keine Token-Attacke

Damit ist aber auch klar, dass diese Konto nicht Opfer einer Token-Attacke geworden bin. Wobei das Konto durchaus ein Opfer hätte sein können. Denn entgegen meiner ersten Einschätzung habe ich mich mittels Benutzername und Kennwort am Tenant authentifiziert und der Angreifer hätte neben dem Benutzernamen und Kennwort durchaus auch das Auth-Token mitlesen können. Die Mühe muss er sich aber nicht machen, wenn er Zugangsdaten hat und Microsoft diese Anmeldung nicht als "Risky" ansieht. Daher möchte ich hier dennoch darauf hinweisen, dass in diesem Fall es nicht reicht, das Kennwort des Konto zu ändern, sondern Sie müssen auch alle bislang ausgestellten Tokens ungültig machen:

Ansonsten kann der Angreifer mit einem ausgestellten Token noch weiter arbeiten.

What is Office 365 Shell WCSS?
Office 365 Shell WCSS is the browser code that runs whenever a user navigates to (most) Office365 applications in the browser. The shell, also known as the suite header, is shared code that loads as part of almost all Office365 workloads, including SharePoint, OneDrive, Outlook, Yammer, and many more. ...
... The exploit allows the attacker to gain access to a users account without knowing the user name or password, and will even bypass accounts that are configured for MFA.
Quelle: Office 365 shell WCSS Attack - https://saasalerts.zendesk.com/hc/en-us/articles/12791257866381-Office-365-shell-WCSS-Attack

• Security defaults in Microsoft Entra ID
  https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults?WT.mc_id=Portal-Microsoft_AAD_IAM#require-users-to-do-multifactor-authentication-when-necessary
• Office 365 shell WCSS Attack
  https://saasalerts.zendesk.com/hc/en-us/articles/12791257866381-Office-365-shell-WCSS-Attack
• What is the Office 365 WCSS Attack? | Understanding the Latest Cyber Threat
  https://www.youtube.com/watch?v=pylr1QdefCc

Cloudflare Abuse

Eine nicht ganz ruhmreiche Rolle sehe ich hier bei Cloudflare. Natürlich gibt es ein "ABUSE"-Formular unter https://abuse.cloudflare.com/phishing, mit der man solche URLs und Seiten melden kann. Das Formular schreibt aber auch direkt, dass Cloudflare anscheinend einfach nur die Beschwerde an den Webseitenbetreiber und den Hosting-Provider weiterleitet.

Und wenn Sie dabei nicht aufpassen, dann senden Sie sogar ihre weiter oben zwingend einzugebenden Kontaktinformationen direkt an den "Betreiber" weiter. Was erwartet Cloudflare eigentlich? Sicher stellen Sie skalierbare Webdienste für seriöse Unternehmen bereit, aber schon aus Eigeninteresse sollten sie solchen Diensten keine Plattform bieten.

Oder läuft deren Geschäft schon so automatisiert, dass die Webseitenbetreiber die Skalierungsdienste bei Cloudflare einkaufen und das Inkasso übernehmen und Cloudflare gar nicht mehr weiss, was über ihre Plattform geroutet wird? Nach dem Motto: "To big to fail", niemand wird die Server von Cloudflare auf eine Blockliste setzen, also kann man unreguliert agieren?

Die Verbindung zur Phishing-Seite ist per SSL verschlüsselt, was seit Let's Encrypt auch nicht mehr schwer ist. Hier kommt aber ein Zertifikat von "O = Google Trust Services LLC" zum Einsatz.

Die sind sicher nicht "kostenfrei" und Cloudflare wird vermutlich den privaten Key haben und in den TLS-Handshake zu schauen, Daten zu cachen etc. Hier würde ich die erste Abwehr sehen, auch um die Plattform für eine solche Nutzung uninteressant zu machen. Bis aber die Meldung von mir dann beim eigentlichen Webhoster landet, der dann vielleicht etwas unternimmt, vergeht relativ viel Zeit.

Mein ABUSE-Report habe ich am Do 14.12.2023 14:06 gesendet und mehr als eine Quittung habe ich auch nach 30h nicht erhalten. Die Seite war selbst 4 Tage später noch online. Erst ca. 10 Tage später kam ein "API-Error", als wenn das Backend des Angreifers endlich offline wäre.

Malware Erkennung

Der Nachtest am 29.12.2023 ergab den API-Error aber auch Microsoft Defender hat den Aufruf mitbekommen, obwohl er über "Firefox" im "Private Fenster" erfolgte.

Auch die Beziehungen zueinander sind auf den ersten Blick sichtbar

Die Endpoint Lösung scheint hier sehr effektiv die Prozess oder z.B. DNS-Anfragen zu überwachen.

Strafanzeige

Da sich Cloudflare auch nach einigen Tagen weder gemeldet noch die Seite abgeschaltet hat, habe ich letztlich eine Anzeige bei der Polizei gemacht. Am 2. Jan 2024 bekam ich dann einen klassischen Postbrief mit der Meldung:

"Verfahren eingestellt, da Täter nicht ermittelt werden konnte"

Die ganze Bearbeitung hat weniger als 4 Wochen gedauert aber ich bin auch nicht sicher, wie viel da ermittelt wurde. Vielleicht gab es ja nur eine automatische Anfrage an Cloudflare oder ein Fachbeamte hat sich das angeschaut und die Chancen einer Täterermittlung als gering eingeschätzt.

Auch habe ich keine Information, ob daraus abgeleitet strengere Prüfungen durch Provider angefordert werden, denn ich bin sicher, dass auch die nächsten Angriffe auch wieder über Cloudflare und Co erfolgen könnten. Selbst die Webseite oder Service wurde von Cloudflare noch nicht abgeschaltet

Der Cloudflare Endpunkt ist weiter per HTTPS erreichbar aber liefert am 12. Jan 2024 nur eine Fehlermeldung, die aber den Eindruck macht, dass sie einfach wieder online gehen könnte. Da aber Windows Defender mittlerweile die URL auf einer Blockliste führt, sind zumindest die Clients gesichert, die entsprechend konfiguriert sind.

Bewertung

Dass hier ein QR-Code der Träger des Links war, war nur der Aufhänger. Selbst wenn Spamfilter wie EOP angeblich auch schon QR-Codes parsen und prüfen können, muss der Angreifer ja am Anfang noch nicht die bösartige Seite dort hinterlegt haben. Es also immer irgendwie passieren, dass Anwender unvorsichtigerweise so einen Link erwischen und Sie haben nun gesehen, wie einfach und schnell ein Anwender seine Zugangsdaten oder Access-Tokens aushändigt.

Die Hoffnung, dass "Security Defaults" dies irgendwie schon lösen wird, hat sich aber spätestens mit dieser Seit zerschlagen, denn nur Administratoren werden von Microsoft als so wichtig angesehen, dass MFA immer erforderlich ist. Bei Anwender kommt MFA nur "bei Bedarf" zum Einsatz. Das reicht aus meiner Sicht nicht. MFA müsste auch bei Anwendern immer dann zum Einsatz kommen, wenn er z.B. von einem neuen Client oder einem neuen unbekannten Netzwerkstandort sich anmeldet. Wer diesen "Bedingten Zugriff" anhand eines "Managed Clients" oder über die IP-Adresse ihres Firmenstandorts nutzen möchte, muss EntraID P1 oder höher zusätzlich lizenzieren.

Die nur eingeschränkte Sicherheit von "Security Defaults" muss ihnen bekannt sein.

Weitere Links

• Security Defaults
• QR-Code Phishing
• IONOS SMTPAUTH Fail
• QR-Code Phishing
• YouTube Video
  https://youtu.be/1hZsLR0NtY8
• Let's Encrypt
• Spam und Phishing
• Conditional Access
• Multi Faktor Authentifizierung (MFA)
• MFA und Dienstkonten
• BasicAuth Ende mit POP3/IMAP4 umgehen
• Exchange Online Authentifizierung
• OAUTH2 / Modern Authentication
• Websockets
• Protect your organizations against QR code phishing with Defender for Office 365
  https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/protect-your-organizations-against-qr-code-phishing-with/bc-p/4007456#M450
• Youtube: I Stole a Microsoft 365 Account. Here's How
  https://www.youtube.com/watch?v=sZ22YulJwao
• Evilginx
  https://help.evilginx.com/docs/intro
  https://github.com/kgretzky/evilginx2