M365 Credential Phishing

Auf der Seite Session Cookie Security habe ich die Risiken eines lokalen Abgriffs von Sessioncookies beschrieben. Am 7.6.2023 hat mir ein Leser einen Hinweis auf einen Link gegeben, der nicht weniger riskant für normale Anwender ist. Über eine Phsihing-Mail wurde ein Link auf https://servicesfillers.Cloud an den Mitarbeiter geschickt und dann passierte folgende:

Achtung:
Starten Sie solche Experimente nie auf ihrem produktiven System. Ich habe extra einen physikalisch getrennten PC, der zudem über einen Freifunk-Router online geht und damit nicht nur den Rückschluss auch mich erschwert sondern vor allem meine eigene IT nicht angreifen kann. Dieser Client ist definitiv nicht "intern".

Dieser Angriff funktioniert natürlich auch im LAN oder wenn der Angreifer vorgibt, dass der Anwender auf einen Server im LAN zugreifen will und kein SSO erfolgt.

Link URL betrachten

Üblicherweise kaufen oder betreiben Spammer ein paar Webseiten ohne Malware, damit diese nicht gleich bei Providern oder Hostern auffallen, die aber nur eine Umleitung machen. Die IP-Adresse lässt sich per NSLOOKUP schnell ermitteln:

PS C:\> nslookup -q=a servicesfillers.Cloud 

Nicht autorisierende Antwort:
Name: servicesfillers.Cloud
Address: 185.61.154.192

Der Provider dahinter ist Namecheap.


https://ipinfo.io/185.61.154.192

Da ist wohl der Name schon Programm. Da mit ein Browser mit JavaScript etc. immer etwas suspekt ist, schaue ich mit die Quelle erst einmal im RAW-Format per CURL oder Powershell an:

Hier kommt zwar kein 302 Redirect oder ein Meta-Redirect im Header zum Einsatz und das Base-tag ist ja nur der Prefix für alle relativen URLs relevant. Ein einfaches Tracing mit dem F12-Debugger in Chrom/Edge hat leider nichts gezeigt. Ich habe dann in Firefox die automatische Weiterleitung mit "accessibility.blockautorefresh" abgeschaltet:

Dann habe ich eine leere weiße Seite gesehen

Über den Quelltext wurde dann der Redirect sichtbar

Ich bin schon etwas irritiert, dass Edge/Chrome diese Information nicht angezeigt haben.

Captcha auf httpx://lmai.kmitallae.xyz/

Ich habe den Aufruf der ersten URL per F12-Debugger aber auch per Fiddler untersucht aber konnte noch nicht schlüssig erkennen, wie die Umleitung auf die nächste Seite erfolgt, die die eigentliche Malware ist.

Es ist ja bekannt, dass Spamfilter u.a. auch URLs auf Malware scannen. Das dürfte der Grund dafür sein, dass der Link den Browser erst einmal ein Captcha anfordert. Für automatische Prozesse sollen diese Hürden ja sehr hoch sein.

Ein Anwender sollte hier natürlich alarmiert sein, dass die Webseite keinen Firmennamen, kein Impressum o.ä. trägt aber es gibt Anwender, die das Captcha lösen und weiter klicken.

Microsoft Login Seite?

Denn wenn sie diese für Anwender niedrige Hürde genommen haben, an der Spamfilter sich schwer tun, dann begrüßt sie eine Microsoft Anmeldeseite.

Mittlerweile meldet mein Browser diese Seite als "Unsafe content". Das was am Anfang noch nicht so. Dennoch sollten Sie ihre Anwender trainieren, dass man sich die URL anschaut, die so gar nichts mit "login.microsoftonline.com" gemeinsam hat.

Schon hier habe ich erst einmal mit den Debugger-Tools geschaut, wie diese Webseite z.B. die Grafik einblendet. Sie könnte diese ja direkt von Microsoft holen. Dem ist aber nicht so. Anscheinend ist es wirklich ein kompletter Reverse Proxy, der einfach unter einem eigenen Namen veröffentlicht ist und alle URLs auch umschreibt.

Microsoft sieht nicht meinen Client sondern vermutlich den Webserver, zu dem sich mein Client verbunden hat.

Recherche zu kmitallae.xyz

Ehe ich hier nun Credentials eingebe, habe ich wieder auf meinem Arbeitsgerät die Gegenseite recherchiert.

C:\> nslookup -q=NS kmitallae.xyz

Nicht autorisierende Antwort:
kmitallae.xyz nameserver = dns1.registrar-servers.com
kmitallae.xyz nameserver = dns2.registrar-servers.com

C:\> nslookup -q=a lmai.kmitallae.xyz

Nicht autorisierende Antwort:
Name: lmai.kmitallae.xyz
Address: 45.11.181.151

Über die IP-Adresse lässt sich der Provider einkreisen.


https://ipinfo.io/AS9009/45.11.181.0/24

Das ist natürlich nicht das autonome Netzwerk AS8075 von Microsoft, sondern ein Server in Rumänien. Der Provider M247 ist mir übrigens schon früher (Siehe Bumsbude Spam) negativ aufgefallen.

Intelligenztest

Eine Webseite, die einer Microsoft Anmeldeseite aussieht, kann man schon schnell aufsetzen. Aber ist die Logik dahinter denn schlau? Zuerst habe ich daher einen ungültigen Benutzer angegeben.

Nach wenigen Sekunden hat das Formular direkt den Fehler angezeigt. Die Webseite scheint schon zu prüfen, ob die URL stimmt. Ich vermute mal, dass der Webserver die Microsoft Anmeldeseite einfach transparent durchreicht. Prüfen kann ich das ohne Zugriff auf den Webserver oder Microsoft selbst nicht.

Spiel mit dem Feuer

Natürlich wollte ich mehr raus finden und daher habe ich in einem meiner Spiel/Test-Tenants extra einen "Phishing-User" mit einem Kennwort angelegt, der aber keine Lizenz hat und auch sonst war ich immer nur einen Button davon entfernt, das Konto zu sperrren und das Kennwort zu ändern. Die Eingabe des gültigen Benutzernamens wurde mit dem Formular für das Kennwort beantwortet.

Selbst eine 2FA-Anmeldung wird durchgereicht:

Das ist für einen "Reverse Proxy" auch keine besondere Aufgabe. Microsoft fragt danach ja gerne mal an, ob ich "angemeldet bleiben" will. Hier ist interessant, dass der Angreifer wohl ein JavaScript einschmuggelt, welches automatisch auf den "Yes"-Button drückt:

Der Angreifer hat ja nun schon alles aber braucht natürlich noch die entsprechenden Cookies, die Microsoft danach an den Client ausliefert und vom Proxy natürlich "gesichert" werden.

example.com?

Nachdem ich die komplette Anmeldung durchlaufen habe, hat mir der Angreifer leider nicht die Office 365-Seite angezeigt, sondern einen Redirect zu "example.com" gemacht.

Natürlich habe ich sofort das Kennwort wieder geändert und die Sessions zurückgezogen.

Das finde ich nun suspekt, denn ein Anwender, der so weit gekommen ist, würde auch weiter über den Browser seine Daten eingeben. Als Reverseproxy könnte der Angreifer dann ganz problemlos mitlesen, was der Anwender so tut und mittels JavaScript noch ganz andere Aktionen auf dem Client auslösen, z.B. Popup-Meldungen oder beim Öffnen einer Mailanlage diese durch eine Malware zu ersetzen. So bleibt es einfaches Phishing,

Fehlerbild

In meinem Fall ist nun ein Fehler aufgetreten. Angeblich war meine Anmeldung erfolgreich aber ich hätte keine Rechte auf den gewünschten Dienst zuzugreifen. Das kann schon sein, da der Benutzer keine Lizenz hat und der Hacker anscheinend auf die Ofice365-App zugreift.

In den Details ist aber interessant, dass der an Microsoft gemeldet Client die IP-Adresse 45.11.181.151 ist, die genau zum Host "lmai.kmitallae.xyz" passt.

Meine Vermutung ist, dass hier jemand einen Reverse-Proxy aufgesetzt hat, wie dies auch ein Layer-7 Loadbalancer bereitstellen kann. Aber natürlich wird der Proxy die SSL-Verbindung aufbrechen und die essentiellen Informationen ausleiten. Das ist der Benutzername und Kennwort. Wenn der Benutzer aber mit 2FA arbeitet, dann dürft der Proxy auch das an den Client gesendete OAUTH-Token ausleiten, mit dem er sich dann weitere Access-Tokens anfordern kann.

Gerade die letzte Information aus dem OAUTH-Token ist besonders tückisch denn der Angreifer kann damit auch weiter auf das Konto zugreifen, selbst wenn der Anwender sein Kennwort geändert hat. sie sollten in solchen Fällen immer das Konto im AzureAD-Portal deaktivieren und die Sitzungen zurückziehen.

Wichtig ist dabei natürlich, dass Sie den Fehler des Anwenders schnell gemeldet bekommen.

Auditing

Ich habe bei dem Test ja absichtlich gültige Anmeldedaten für einen Office 356 Benutzer überlassen und habe gehofft, über das Office 365 Logging etwas zu finden. Zuerst habe ich im Auditlog die Geschichte des Benutzers nachvollzogen. Sie sehen gut die Neuanlage und ein paar Kennwortänderungen. Die Registrierung der Authenticator-App erfolgt erst später.

Hier sehen sie den normalen Prozess der Anlage und die mehreren "Reset Password"-Aktionen nach jeder Eingabe eines Kennworts auf der Phishing-Seite. Entsprechend sehe ich dann im SignIn-Log die Vorgänge:

Sie sehe drei Bereiche (von unten nach oben)

  • Grün: Reguläre Anmeldung
    Ich habe mit erfolgreich von meinem regulären PC angemeldet, um die Anmeldung zu testen und die 2FA-Authenticator-App einzutragen.
  • Blau: Anmeldung über Proxy
    Hier habe ich dann vom Test-Client mich mit Benutzername + Kennwort + AuthenticatorApp an Office 365 angemeldet.
  • Rot: Fremde Anmeldung
    Etwa 1 Minute später kam dann aber ein Anmeldeversuch von einer ganz anderen IP-Adresse 23.83.184.200, die zu Leaseweb (https://ipinfo.io/AS19148/23.83.184.0/22 ) in den USA gehört. Der Client war zwar per PING mit ca. 150ms aus Deutschland erreichbar aber weder per HTTP, HTTP, RDP, SSH oder TELNET über die Standardports erreichbar. So einfach ist es dann doch nicht.
    In den Details behautet der Useragent (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36), dass es MacOS wäre aber auch der remote DesktopPort auf 5900 ist zumindest von mir nicht erreichbar.

Ich habe den Hoster von 23.83.184.200, über die Abuse-Adresse kontaktiert aber erwarte mir da nicht viel.

Auch 4 Tage später wurde kein weiterer Anmeldeversuch gestartet. Anscheinend merken zumindest diese Angreifer sich die Daten nicht. Ich lasse den Benutzer aber noch bestehen und habe mir eine Alert Policy eingerichtet, mit der ich bei einem Versuch informiert werde. (Analog zu https://www.alitajran.com/office-365-activity-alerts/)

Damit schließe ich meine Analyse erst einmal ab.

Malware

Angeblich hat der Einbruch bei der Quelle erst einmal nur dazu geführt, dass:

  • Posteingangsregel nach RSS
    Es wurde in Exchange Online eine Regel angelegt, dass alle eingehenden Mails in den Ordner RSS verschoben wurden. Damit möchte der Angreifer eventuelle Rückläufer seiner Mails vor dem Benutzer verstecken. Die meisten Anwender kennen den RSS-Ordner nicht und können daher nicht reagieren
  • Weitere Mails
    Mit dem authentifizierten Zugriff auf das Postfach kann der Angreifer natürlich die Kontakte des Benutzers lesen und seine Schadsoftware bzw. den Link an weitere Personen und Kontakte versenden. Vielleicht fällt noch jemand darauf herein, der höhere Rechte hat. Tipp: Administratoren sollten nie ein Postfach haben und Benutzer sollten ein getrenntes Konto und im besten Fall eine getrennte Admin-Workstation haben. Siehe auch PAW – Priviledged Admin Workstation

Alle weiteren Aktionen sollte ein Administrator natürlich über das Auditlog etc. kontrollieren.

Da bei diesem Angriff der Anwender "nur" mit einem Browser eine unsichere Seite angesprochen und dort seine Credentials eingegeben hat, dürfte das Risiko für den lokalen PC oder ein lokales Active Directory minimal sein. Der Anwender hat ja zumindest keine ausführbare Datei aus seinem PC heruntergeladen und ausgeführt.

Domain kmitallae.xyz ist unsafe

Mittlerweile hat auch Microsoft Defender und sicher der ein oder andere Malware-Scanner und Proxy-Server diese URLs als "böse" registriert, so dass Anwender eine deutliche Warnung bekommen.

Dennoch kann der Angreifer natürlich jederzeit wieder eine andere Domain registrieren, einen Link-Verkürzer nutzen oder anderweitig den Anwender überlisten.

Sentinel / Defender

Mittlerweile sollten Sie davon ausgehen, dass Antiviren-Produkte oder auch einfach der Browser von einem Enterprise Monitoring erfasst werden. Meine "Versuche" wurden natürlich von Windows Defender erkannt und entsprechend auch in Azure Sentinel protokolliert:

Dann ist es nur eine Frage, wie schnell ihr Operating beim Benutzer anruft und die Tragweite hinterfragt. Wohl dem, der ein 24x7 SOC hat.

FIDO2/Windows Hello/Zertifikat-Anmeldung

Der Schlüssel für den Angreifer ist das Abgreifen des "Session Cookie", welches der Authentication Server nach erfolgter Anmeldung mit Benutzername/Kennwort + MFA ausstellt. Der Angreifer kann auch alles mitlesen und verändern und damit erscheint es unmöglich, diese Angriffe zu verhindern. Dem ist aber nicht so. Es gibt Authentifizierungen, bei denen der Domainname der URL mit einbezogen wirwd. Der Anwender meldet sich an der bösartigen Seite mit Benutzername und Kennwort an, aber wenn dann der FIDO2-Key gefragt ist, dann gibt es keinen passenden Schlüssel zur Domain. Damit gelingt die komplette Anmeldung nicht und der Authentication Service stellt erst gar kein Session Cookie aus, welches ein Angreifer abgreifen könnte.

Warnung
Allerdings hat der Angreifer in dem Fall den Benutzernamen und das Kennwort. Das kann dem Angreifer schon helfen, einen anderen weniger gut geschützten Weg zu nutzen oder die Zugangsdaten bei anderen Diensten zu versuchen.

Sie sollten daher "abgebrochene Anmeldung" auf jeden Fall überwachen und dem Mitarbeiter z.B. per Mail o.ä. zur Kenntnis bringen. Wenn der Mitarbeiter dies nicht verursacht hat, dann sollte er umgehend sein Kennwort ändern.

Neben einem klassischen "FIDO2"-Key können Sie natürlich auch Windows Hello als zweiten Faktor einsetzen. Im Azure Portal können Sie dies sehr schnell sehen und z.B. für Administratoren auch fordern:


Quelle: https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AuthStrengths

Die Authenticator App mit einer Nummer oder einem Bestätigen ist allerdings nicht sicher genug, da diese ja die URL in ihrem Browser nicht sieht und daher nicht erkennen kann, ob sie als Anwender auf der richtigen Seite angemeldet sind oder über einen "Inspection"-Proxy kommen.

Der Schutz per FIDO2-Key oder Windows Hello funktioniert natürlich nur, wenn andere Anmeldeverfahren nicht mehr erlaubt sind. Ansonsten könnte ich als Malware einfach per Proxy vorgaukeln, dass der Client kein FIDO2 kann und stattdessen eine schwächere Absicherung genutzt wird. Auch der Benutzer sollte nicht selbst auf "alternative Anmeldeverfahren" wie z.B. SMS oder Telefonanruf wechseln können.

Insofern sind FIDO2-Keys und die Abschaltung aller anderen 2FA Verfahren vermutlich nicht für die Massen sondern erst mal für besonders privilegierte Konten interessant.

Um die Verbindung mit dem DNS-Namen in der URL zu überlisten, müsste der Angreifer entweder den DNS-Service spoofen oder lokal z.B.: mi einer Hosts-Datei den Client zum falschen Server leiten, der dann auch noch ein Zertifikat auf den richtigen Namen vorweisen muss. Auch das ist mit einer lokalen Malware auf dem Desktop natürlich möglich, aber dann würde ich mir nicht die Mühe über einen Proxy machen, sondern auf dem PC die Zugangsdaten und Session-Cookies einfach extrahieren.

Lernkurve

Es war wieder mal ein Mittwoch vor einem Feiertag und verlängertes Wochenende, die auch von Angreifern bevorzugt genutzt werden. Vielleicht spekulieren die Angreifer darauf, dass nur wenige IT-Personal die erforderlichen Gegenmaßnahmen einleiten kann. Dieser Angriff war nun die erste URL, über die auch eine 2FA-Anmeldung ausgetrickst werden könnte, wenn die Angreifer es denn richtig gemacht hätten. Sie hatten den Benutzernamen und das Kennwort aber haben trotz aktiviertem 2FA eine erneute Anmeldung versucht. Das klappt natürlich nicht und anscheinend haben Sie auf dem Proxy noch nicht das OAUTH-Token abgegriffen oder die bestehende Verbindung einfach "übernommen".

Dennoch sollten Sie dies an Anlass nehmen und Aktionen ableiten

  • Anwender informieren
    Angreifer ändern immer etwas ihre Muster und tricks. Hier ging es gezielt um das Ausspähen von Zugangsdaten zu Microsoft 365 Diensten über eine komplett abweichende URL. Sensibilisieren Sie ihre Anwender dafür, die URL genau zu prüfen, ehe Sie Zugangsdaten eingeben. Das gilt nicht nur für das Firmenkonto sondern natürlich auch im privaten Bereich, Stichwort Homebanking.
  • 2FA aktivieren
    Eine gut gemachte Phishing-Seite kann auch mit 2FA umgehen und klaut einfach das Token. Aber das können noch nicht alle und die einfachen Angreifer, wie in diesem Fall, haben dann keine Chance
  • Anmelde-Location
    Wenn Sie sich das SignIn-Log anschauen, dann sollte jedem auffallen, dass ein so schneller Wechsel von Borken, NRW, DE über Bukarest, RU nach Scottdale, Arizona, US zumindest mal "suspekt" ist und auf keinen Wall ohne Rückfrage eines zweiten Faktors bleiben sollte. Mit Conditional Access könnten Sie die Anmeldung auf bestimmte Länder beschränken oder "Risky SignIns" aktivieren.
  • Kontaktmöglichkeiten
    Menschen machen Fehler und das gilt auch für Admin. Es ist schlimm, wenn ein Konto so seine Zugangsdaten preisgibt. Viel schlimmer ist es aber, wenn er keinen Admin erreicht, um die Situation zu heilen oder sich der Anwender aus Scham oder Furcht vor Bestrafung die Situation verheimlichen und der Schaden größer wird. Hier sind ihre Kommunikationsfähigkeiten geplant.

Und nun wünsche ich zumindest allen Administratoren ein verlängertes Wochenende, bei denen der 8.6.2023 (Fronleichnam 2023) ein Feiertag ist.

Weitere Links