NTLM MITM mit Edge / PIKABOT

Vor einigen Tagen habe ich noch eine CVE-2024-21410 Betrachtung geschrieben und gedacht, da müsste dazu einfach nur eine Mail mit einem präparierten Termin an Outlook senden. Wenige Tage später haben meine Kollegen von NoSpamProxy aber eine Mail abgefangen, die zwar nicht Outlook überrumpelt aber aufgrund einer schlechten Voreinstellung des Edge-Browsers dennoch ein Risiko darstellt.

Diese Angriffe sind Ende Deb/Anfang März 2024 ein aktiver Thread unter dem Namen "PIKABOT"
https://bazaar.abuse.ch/browse/tag/pikabot/
https://threatfox.abuse.ch/browse/tag/pikabot/
Eigentlich wollte ich auf der MSXFAQ eigentlich nicht so viele "Security-Themen" beschreiben aber ich hoffe es ist neben all den Exchange und Microsoft 365 Themen immer noch interessant.

Die Reply-Chain-Mail

Es war eine klassische Replay-Chain-Attacke: UserA und UserB haben eine aktive Konversation per Mail und der Angreifer kann das Konto von UserB mitlesen, weil er entweder direkt die Zugangsdaten kennt, eine unbemerkte Weiterleitung konfiguriert wurde oder eine Malware auf dem Client von UserB die Mail weitergegeben hat und der Angreifer nun eine "Antwort" an den UserA sendet. Selbst ein für Angriffe sensibilisierter UserA wird in dem Fall nicht immer sofort diese Mail erkennen.

Der Angreifer hat ja die originale Mail und wenn er diese entsprechend "zitiert" und sich auf den Inhalt bezieht, dann wird es für UserA schon schwer, dies zu erkennen. In der Anlage was dann ein ZIP-Archiv mit etwas Binär-Müll und einer HTML-Datei. Viele Anwender aber auch Firmen haben noch nicht wirklich erkannt, dass auch HTML-Dateien nicht nur aus statischem Text mit Formatierung bestehen, sondern durchaus neben JavaScript auch Links zu anderen Adressen enthalten und nicht alle "HTML-Betrachter" hier Missbrauch unter allen Umständen sicher verhindern.

Eigentlich sollte man überlegen, ob Mails mit HTML-Dateien in ZIP-Anlagen nicht generell geblockt werden.

Die HTML-Datei hatte einen Inhalt, den ich hier nachgebaut habe:


Selbst erstelltes Muster um den Effekt zu prüfen.

Die Malware war natürlich auch etwas ausgereifter und schicker formatiert. Interessant ist hier, das im Body ein "<meta>"Tag ist, welches einen File-URL verwendet. Ich habe hier einfach eine interne IP-Adresse angegeben und nicht den Server es Angreifers im Internet. Für die nachfolgenden Tests ist dies aber nicht relevant.

Mittlerweile weiss ich, dass diese Malwar auch als "PIKABOT" bekannt und umfangreich im Einsatz ist.
Siehe dazu auch https://bazaar.abuse.ch/browse/tag/pikabot/ oder https://threatfox.abuse.ch/browse/tag/pikabot/

Das Problem ist einfach, dass Angreifer sehr viele solche Mails versenden können und wenn auch nur ganz wenige Anwender darauf hereinfallen, hat der Angreifer genug Zugangsdaten.

Einmal über SMTP

Diese Anlage habe ich gepackt und dann per Mail über das Internet an ein Exchange Online Konto gesendet. Das ist erforderlich, damit Outlook diese Mail und die Anlage als "Internetzone" kennzeichnet und entsprechend reagieren kann. Das war nicht mal einfach, da NoSpamProxy die Mail direkt abgelehnt hat und der von mir genutzte Mailserver einen NDR erzeugen musste.

Aber auch Exchange Online Protection hat diese Mail als Malware in die Quarantäne verschoben.

Hier konnte ich sie aber wieder befreien und dann in Outlook betrachten:

Outlook hat hier noch kein Problem, denn ohne Mithilfe des Anwenders passiert erst einmal nichts. Aber wenn die Datei nun nicht "ntlm-file-attack.zip" sondern "aktualisiertes Angebot.zip" heißt und ihr Anwender mit dem Absender sowieso gerade eine Konversation führt und im Anschreiben auch noch auf die frühere Korrespondenz eingegangen wird, dann würde ich nicht darauf wetten.

Kontrollierte Öffnung

Um zu sehen, ob nun irgendein Zugriff auf die hinterlegte IP-Adresse 192.168.102.86 erfolgt, habe ich Wireshark mit dem Filter auf "host 192.168.102.82" gestartet und erst dann das ZIP-Archiv und die darin enthaltene HTML-Datei geöffnet.

Hier muss der Anwender natürlich aktiv mithelfen. Es ist kein Angriff über eine Outlook Lücke, die ohne weitere Aktion des Anwenders triggern würde. Wenn wir aber ehrlich sind, dann gibt es leider immer noch viel zu viele Anwender, die dies dennoch tun, denn es ist ja nur eine "ungefährliche" HTML-Datei

Outlook speichert die Datei in einem TEMP-Ordner und öffnet das Archiv.

Noch hat sich in Wireshark nichts gezeigt aber dann öffne ich die Datei per "Doppelklick" und der Browser zeigt die HTML-Datei erst einmal an.

Dass im Hintergrund ein Zugriff auf die File-URL erfolgt, sehe ich aber im Wireshark.

Der Browser kümmert sich nicht darum, dass die HTML-Datei aus dem Internet ist und auch noch die Zoneneinstellung hat.

Der Browser versucht dennoch eine SMB-Verbindung zur angegeben URLs und meldet sich sogar erfolgreich per NTLM an.

Hier handelt es sich um einen internen Server bei mir, der natürlich NTLM anbietet und eine Anmeldung erfolgreich ist. Nur habe ich natürlich keine Rechte auf C$ des Servers. Darum geht es aber auch nicht, denn ich wollte ja nur den Authentication-Handshake mit NTLM sehen. Bei einem Zugriff auf einen externen Server, der von draußen dann einen Zugriffspunkt per NTLM nutzen könnte, hätte ich nun meinen NTLM-Hash "verraten. Wir sehen aber beim Net at Work SOC und NoSpamProxy, dass solche Angriffe in sehr großer Anzahl stattfinden und damit die Erfolgswahrscheinlichkeit steigt.

Der Browser versucht einige Zeit den Zugriff, bis er dann abbricht und erst dann die URL und den Fehler anzeigt:

Ich habe mich hier auf Windows Clients mit Outlook und Edge beschränkt, die millionenfach im Einsatz sind. Vielleicht funktioniert dies alles auch noch auf MacOS, Linux, Android und IOS aber da die Geräte meist nicht in einer Domain sind, wird eine Anmeldung per NTLM weniger wahrscheinlich, aber nicht ausgeschlossen sein.

Andere Browser

Ich muss ja nicht den Edge zur Anzeige von HTML-Dateien nehmen. Ich habe daher die von Outlook abgelegte HTML-Datei Anlage mit anderen Browsern geöffnet.

Browser Betriebsart Anmeldung

Chrome Version 122.0.6261.71 (Offizieller Build) (64-Bit)

Standard

NTLM-Anmeldung

Chrome Version 122.0.6261.71 (Offizieller Build) (64-Bit)

Gast

NTLM-Anmeldung

Chrome Version 122.0.6261.71 (Offizieller Build) (64-Bit)

Inkognito

NTLM-Anmeldung

Edge Version 122.0.2365.52 (Official build) (64-bit)

Standard

NTLM-Anmeldung

Edge Version 122.0.2365.52 (Official build) (64-bit)

Private

NTLM-Anmeldung

Edge Version 122.0.2365.52 (Official build) (64-bit)

Application Guard

 Datei nicht erreichbar
Direktzugriff auf file://192.168.102.86/c$ geht auch nicht

Brave Version 1.63.165 Chromium: 122.0.6261.94 (Offizieller Build) (64-Bit)

Standard

NTLM-Anmeldung

Brave Version 1.63.165 Chromium: 122.0.6261.94 (Offizieller Build) (64-Bit)

Inkognito

NTLM-Anmeldung

Firefox 122.0.1 (64-Bit)

Standard

Kein Verbindungsversuch in der Standardeinstellung

Firefox 122.0.1 (64-Bit)

Privat

Kein Verbindungsversuch in der Standardeinstellung

Dass ein Edge im "Application Guard"-Mode hier sicher ist. kann ich verstehen, denn er kommt gar nicht an die Datei heran. Der Firefox hat vermutlich einfach den Vorteil, dass er in der Standardkonfiguration einfach HTML machen:

Wenn ich die Einstellung "network.automatic-ntlm-auth.allow-non-fqdn = true" setzen dann greift er auch auf per SMB auf die File-URL und NTLM zu. Ich kann mir vorstellen, dass viele Firmen genau diese Einstellung aktiviert haben, um eine direkte Anmeldung an internen Webseiten zu erlauben. Daher habe ich Firefox nicht komplett "grün" gemacht.

Das bedeutet aber Firefox eine IP-Adresse auch als "non-fqdn" einstuft.

Das Problem ist nicht die Mail oder Outlook sondern die Chromium-basierten Browser mit ihrer Standardeinstellung, dass Sie FILE-URLs, die in HTML-Dateien auf lokalen Volumes trotz der "Zoneneinstellung:Internet" nicht nur ansprechen, sondern auch noch eine NTLM-Anmeldung durchführen.

Abruf von Webserver?

Aus reiner Neugier habe ich noch einen weitere Test gemacht. Ich habe die HTML-Datei einfach auf die MSXFAQ gelegt und mit einem Browser angesurft. Mich hat interessiert, ob hier auch die FILE-URL im META-Tag aktiv geworden wäre. Die TestURL ist https://www.msxfaq.de/test/ntlm_mitm_mit_edge_test.htm 

Öffnen Sie diese URL mit einen Browser und mit aktiviertem Debugger (F12). Alle Zugriff auf IP-Adressen/URLs etc. sollten geblockt sein, d.h. keine Verbindung zu den Zielen und wenn dann zumindest keine automatische Anmeldung per NTLM-Handshake starten.

Edge, Chrome und Firefox haben zwar die HTML-Seite geladen aber die File-URL wurde nicht angesprochen. In Wireshark war nicht einmal ein TCP-Verbindungsversuch zu dieser URL zu sehen. Auch der versuch per File-URL ein Bild nachladen zu lassen, hat keinen Zugriff gezeigt. Im jeweiligen Debugger ist dies auch zu sehen:


Chrome Debugger - Netzwerk

Chromium Debugger hat ein "(blocker:other")  und in der Console sehen Sie dann auch die Blockade auf lokalen Content und weil es nicht HTTPS ist.


Chrome Debugger - Console

Im Firefox zeigt sich ein vergleichbares Bild:


Firefox Debugger - Netzwerk

Insofern ist es mit diesen Browsern nicht möglich, aus einer aus dem Internet geladenen Datei einen Verweis auf "File:"-URls anzutriggern und eine NTLM-Authentifizierung zu erhalten.

Gegenmaßnahmen

Menschen machen Fehler und als Administrator sollten Sie eine möglichst sichere Umgebung. 100% werden wir nicht erreichen aber daher sollten sie nicht aufgeben, sondern dagegenhalten. Es gibt hier mehrere Möglichkeiten, denn solche Angriffe funktionieren oft nur, wenn mehrere Konstellationen zusammentreffen.

  • Anwender Awareness
    Ich kann es immer nur wiederholen: Der Mensch ist oft ein Faktor in der Kette und regelmäßige Schulungen und ein offener und ehrlicher Umgang mit erkannten und abgewehrten Angriffen sorgt für Sichtbarkeit.
  • Spamfilter
    Hier war der Anfangsvektor eine Mail an einen Benutzer. Sie sollten ihre Partner auffordern, dass Sie ihre Domains mit SPF/DKIM/DMARC schützen, so dass Sie einfache Fälschungen des Absenders erkennen und unterbinden können. Das hilft zwar nicht gegen "Vertipperdomains" aber ist ein erster Schutz. Dann muss natürlich überlegt werden, ob man ZIP-Anlagen mit HTML-Inhalten überhaupt "benötigt".
  • Was ist von Außen per NTLM Erreichbar und warum?
    Der Angriff mit NTLM Man in the Middle funktioniert nur, wenn der Angreifer einen Anwender auf seinen Server locken kann, der dann per NTLM wieder zu ihrem System zurückkehrt. Prüfen sie, ob und welche Dienste sie aus dem Internet per NTLM erreichbar machen müssen. Es wird sicher einige Dienste, z.B. für die Exchange Online Migration, geben, aber die kann man auf IP-Bereiche einschränken.
    Für eine Anmeldung per 2FA/MFA sind eh andere Dinge Anmeldeverfahren erforderlich
  • NTLM Intern abschalten
    Im eigenen internen LAN sollten alle Clients konsequent Kerberos nutzen. Das ist eh besser (Siehe auch Warum Kerberos besser ist) und verhindert auch interne NTLM-MITM-Angriffe. Sie starten mit der Protokollierung auf den Domain Controllern, wer denn noch NTLM nutzt.
  • Kein SMB-Zugriff auf unbekannte Ziele
    Der Angriff hier erfolgt über eine "file"-URL auf einen SMB-Server. Ich frage dazu einmal: Wie viele SMB-Server über Port 445 haben Sie? Das sind doch alle Domain Controller und ein paar wenige bekannte Dateiserver. Vielleicht sprechen noch ein paar Server untereinander SMB aber ein klassischer Anwender nutzt auf seinem Computer nur wenige Server. Ein SMB-Zugriff auf Exchange, SQL, SAB etc ist doch eh nicht erforderlich. Vielleicht können Sie SMB einfach auf bestimmte Ziel-Adressen beschränken. Auf der Firewall zum Internet sollte SMB natürlich komplett gesperrt sein. Für Home-Office-Anwender müssen Sie auch eine Lösung finden.
  • NTLM und Anmeldungen schützen
    Wenn Sie schon nicht auf NTLM verzichten können, dann sollten Sie es gegen MITM-Attacken absichern. Die Funktion ist seit Windows 2008 Bestandteil des IIS (siehe IIS Extended Protection). Exchange 2013 und höher unterstützten dies (Siehe Exchange Extended Protection) und seit Exchange 2019 CU14 (Feb 2024) ist es per Default aktiv. Dies gilt aber für alle Dienste auf dem IIS mit NTLM. Auch SMB kann mit SMBSigning (SMB1 Abschaltung) und LDAP Security: LdapEnforceChannelBinding gesichert werden. Das muss aber aktiviert werden, was gewisse sehr alte Systeme dann aussperrt.
  • HTTP-Authentifizierung filtern
    Auch wenn ich aktuell keine Lücke kenne, über die ein Browser oder WinHTTP eine Anmeldung per NTLM an eine externe Seite versucht, so kann es dennoch zukünftig möglich sein. Oder eine Malware versucht es. Ein HTTP-Proxy mit Inspection kann die "Authentication"-Header problemlos erkennen und filtern.

Sie können nicht behaupten, dass es keine Gegenmaßnahmen gegen diese und andere Angriffe gibt. Sie müssen Sie aber auch umsetzen.

Weitere Links