Windows-Angriffe entgegen der Vertrauensstellung

Windows Domänen lassen sich durch Vertrauensstellungen zusammenbringen. Wird der Zugriff nur in eine Richtung benötigt kann man das Vertrauen auch nur einseitig aussprechen – aber sind damit Angriffe in die andere Richtung ausgeschlossen? Leider nicht, denn es gibt Wege um das Vertrauen entgegen der „Direction of Access“ auszunutzen. 

In dem Artikel starten wir erst mit ein paar Grundlagen, um dann den konkreten Angriff vorzustellen. Zum Schluss geben wir noch Tipps für Gegenmaßnahmen und Detektionsmöglichkeiten. 

Vertrauensstellung, was ist das? 

Eine der Kernaufgaben des Active Directory (AD) ist es dafür zu sorgen, dass Nutzer sich bei verschiedenen Diensten und Systemen im eigenen Netz anmelden können. Dafür vertrauen alle Domänenmitglieder dem eigenen Domain Controller (DC), dass dieser die Authentizität der Nutzer gut prüft. 

Aber das Vertrauen kann auch über die Grenzen einer Domäne oder eines Forests hinausgehen1. Dazu wird in beiden Domänen eine Vertrauensstellung (Trust) eingerichtet. Im einfachsten Fall ist sie beidseitig, dann können Nutzer aus beiden Domänen Ressourcen in der jeweils anderen Domäne nutzen. Aber man kann auch nur eine einseitige Vertrauensstellung (One-Way Trust) einrichten, dann können Nutzer der einen Domäne Ressourcen der anderen Domäne nutzen aber nicht umgekehrt. Hier kommt man leicht mit den Richtungen und Begriffen durcheinander, daher findet sich in jeder guten AD-Anleitung ein Bild wie dieses: 

Für unser Beispiel würde dies also so aussehen: 

Ein Angreifer, der in der vertrauten Domäne (hier PARTNER.local) ein Konto oder gar die ganze Domäne übernommen hat, kann natürlich über die Vertrauensbeziehung auch Ressourcen in der anderen Domäne nutzen (entlang der “direction of access”). Bei der beidseitigen Vertrauensstellung gilt das logischerweise in beide Richtungen, aber auch bei der einseitigen Vertrauensstellung gibt es einen Grenzfall wie ein Angreifer, der bereits den Domain Controller übernommen hat, sich entgegen der “direction of access” weiterbewegen kann: 

Kerberos über Grenzen hinweg, die Theorie 

Für die verteilte Anmeldung nutzt Active Directory das Kerberos-Protokoll, das ursprünglich aus der akademischen Welt kommt und ganz im Sinne der akademischen Zusammenarbeit auch bereits alles für die hochschulübergreifende Zusammenarbeit mitbringt. Das Konzept hinter der Vertrauensstellung heißt bei Kerberos Cross-Realm-Authentifizierung.  

Innerhalb eines Realms (oder Domäne in AD-Terminologie) meldet sich der Nutzer initial beim Authentisierungsserver (AS) an und erhält ein Sitzungsticket (Ticket Granting Ticket, TGT). Mit diesem Ticket kann der Nutzer dann beim Ticket-Granting-Server (TGS) Service-Tickets beantragen und sich dann mit diesen bei den Systemen und Services ausweisen, die er nutzen möchte. 

Für die Cross-Realm-Authentifizierung wird dann einfach der fremde TGS wie ein Dienstserver im eigenen Realm betrachtet. Der Nutzer fragt also seinen Heimat-TGS nach einem Ticket für den Fremd-TGS. Dieses Ticket funktioniert dann analog zu einem TGT im anderen Realm. Der Nutzer beantragt mit diesem dann ein Service-Ticket beim Fremd-TGS für den eigentlichen Service, den er nutzen möchte. In beiden Schritten werden die gleichen Befehle ausgetauscht. 

In der Praxis sind der TGS und der AS keine getrennten Server, sondern zwei Funktionen des Key Distribution Centers (KDC), die beide über den UDP-Port 88 erreicht werden. In der Windows-Welt ist das ein Service auf dem Domain Controller.  

Um den Angriff gleich verstehen zu können, müssen wir noch einen Schritt tiefer gehen. Die Tickets, die bei Kerberos immer wieder ausgetauscht werden, sind Datenstrukturen, die mit einem symmetrischen Schlüssel verschlüsselt sind. Diese Schlüssel werden für Nutzer, Services und auch die Zwischenschritte am TGS in Principals gespeichert. Die Schlüssel für die Sitzungstickets (TGT) sind beispielsweise im Principal “krbtgt” gespeichert. 

Für den ersten Schritt, die initiale Anmeldung am AS, basiert der Schlüssel auf dem Nutzerpasswort. Für die anderen Fälle sind auch andere Wege möglich, aber in Windows wird für die Fälle, in denen kein Nutzer involviert ist, einfach ein zufälliges Passwort generiert und daraus der Schlüssel abgeleitet. 

Innerhalb einer Domäne bzw. eines Realms ist das auch einfach, da wir hier ja über eine zentral verwaltete Principal- bzw. Benutzer-Datenbank reden. Wenn wir jetzt aber die Grenzen überschreiten wollen, muss es in beiden Datenbanken einen gleichartigen Eintrag mit dem gleichen Schlüssel (also dem gleichen Passwort) geben. Auf der einen Seite der Grenze, um das Ticket verschlüsseln zu können, und auf der anderen Seite, um es wieder entschlüsseln zu können.  

Die Umsetzung im AD 

Jetzt wollen wir uns anschauen, was bei einer Vertrauensstellung in einem Windows Active Directory (AD) passiert. 

Das Trusted Domain Object (TDO) 

Um sich zu merken, mit welchen anderen Domänen oder Forests eine Vertrauensstellung existiert, wird pro Vertrauensstellung im “System”-Container der dazugehörigen Domänen (bzw. den Root-Domänen bei Forest-Trusts) jeweils ein Objekt angelegt – ein sogenanntes Trusted Domain Object (TDO). Auch bei einseitigen Vertrauensstellungen wird an beiden Enden ein TDO angelegt (einmal als eingehende, einmal als ausgehende Vertrauensstellung).  

In den Attributen des Objekts werden alle Einstellungen für die Vertrauensstellung gespeichert. In dem Objekt wird zudem ein Passwort für das TDO gespeichert. Und zwar zum einen wie man es sonst von Benutzern und Computern kennt als Hash bzw. abgeleiteter Schlüssel und in diesem Fall zusätzlich auch im Klartext. Das Passwort wird automatisch alle 30 Tage geändert und – um Störungen beim Passwortwechsel vorzubeugen – wird jeweils das aktuelle sowie das vorherige Kennwort im TDO gespeichert. Das Passwort, und das ist wichtig, ist für beide Objekte gleich. 

Das Objekt kann man in der MMC unter “Active Directory-Benutzer und -Computer” sehen, wenn man zuvor unter “Ansicht” die “Erweiterten Features” aktiviert hat. Dort findet es sich dann unter dem vollen Namen der jeweils anderen Domäne. 

Der versteckte User 

Das es auf beiden Seiten einen gleichartigen Eintrag mit dem gleichen Schlüssel geben muss, hatten wir schon bei der Kerberos-Theorie gesehen. In der Windows-Welt sind die beiden TDO aber nicht die einzigen Repräsentanten der Vertrauensstellung. 

Schaut man sich die Nutzerliste auf der Seite der vertraueten Domäne (bei uns PARTNER.local) z. B. im ADSI-Editor etwas genauer an, findet sich dort ein User dessen Namen an die vertrauenden Domäne erinnert – in unserem Fall finden wir einen Benutzer HISOCORP$

ADSI-Editor auf dem PARTNER-DC.

In vielen anderen Ansichten wie der MMC wird der Nutzer ausgeblendet. Praktischerweise hat dieser versteckte Benutzer das gleiche Passwort, das auch in beiden TDO-Objekten im Klartext gespeichert wird. 

Der Angriff entgegen der Vertrauensrichtung 

Nach so viel Theorie und Grundlagen wollen wir jetzt endlich schauen, wie wir das Vertrauen gegen den Strom ausnutzen können. Noch einmal zur Erinnerung: Wir wollen gegen die erlaubte “Direction of Access” arbeiten. 

Der Trick ist jetzt, dass der versteckte Nutzer in der vertrauten Domäne ein fast normaler Nutzer ist, und wir sein Passwort kennen. 

Dann besteht der Angriff aus diesen Schritten: 

  1. Die vertrauende Domäne kompromittieren (in unserem Beispiel HISOCORP.local) 
  2. Auf dem kompromittierten DC das Passwort aus dem Trusted Domain Object (TDO) auslesen
  3. Mit dem bekannten Nutzernamen und dem ausgelesenen Passwort bei der vertrauenden Domäne (in unserem Beispiel PARTNER.local) anmelden. Also ein TGT beziehen.
  4. Mit dem TGT können jetzt Dienst-Tickets bezogen werden und ggf. Dienste genutzt werden. 

Auf Schritt 1 gehen wir nicht näher ein. Für die folgenden Schritte nehmen wir an, es ist bereits gelungen die Domäne zu kompromittieren und Zugriff auf einen Domain Controller (DC) zu erlangen. Das ist keine kleine Annahme und damit haben wir bereits vollen Zugriff auf alle Ressourcen auf dieser Seite der Vertrauensstellung. 

Auf dem DC können wir jetzt für Schritt 2 das bekannte Tool Mimikatz nutzen. Für das Auslesen des TDO gibt es einen eigenen Befehl: lsadump::trust /patch 

Im TDO ist das gemeinsame Passwort im Klartext gespeichert – in der Ausgabe oben jedes Zeichen als eine Hexadezimalzahl nach dem Stichwort „CLEAR“ – sowie verschiedene Hashwerte vom Passwort.  

Den NT-Hash (rc4_hmac_nt) können wir direkt für Schritt 3 nutzen. Die beiden anderen Hashes/Schlüssel wurden mit einem anderen Salt erzeugt und entsprechen daher nicht den Hashes, die bei der vertrauten Domain im versteckten Nutzer gespeichert sind. Aber wir kennen jetzt ja das Klartextpasswort und die Berechnungsformel für die Nutzer-Schlüssel, können also diese beiden Werte auch selbst berechnen. 

Wir nehmen in Schritt 3 den einfachsten Weg und melden uns direkt mit dem erbeuteten NT-Hash an. Dafür bietet sich beispielsweise die impacket-Suite an. Damit können wir direkt ein TGT beziehen: 

Das TGT können wir in Schritt 4 dann zum Beispiel für einen Zugriff auf eine Dateifreigabe per SMB nutzen: 

Im Beispiel wird auf die SYSVOL-Freigabe des fremden DC zugegriffen. Das geht, weil diese Freigabe grundsätzlich von allen Nutzern (Gruppe „Domänenbenutzer“) gelesen werden kann.

Da der Nutzer in der normalen Administration nicht sichtbar ist, ist er weder Mitglied in anderen Gruppen noch wurde der User selbst für Dienste oder Zugriffe explizit berechtigt. In einem realen Netz finden sich aber auch häufig weitere Freigaben und Dienste, die alle gemeinsam nutzen und die für die allgemeine Gruppe der Domänenbenutzer freigegeben sind. 

Bei der Bewertung von Sicherheitslücken wird immer unterschieden, ob sie auch ohne Login oder nur nach erfolgreicher Authentifizierung möglich sind. Und genau diesen Sprung zum authentifizierten Angreifer konnten wir jetzt machen, unabhängig davon wie wenig Rechte dem versteckten Nutzer eingeräumt wurden.  

Ein Beispiel sind Kerberoasting-Angriffe, die darauf abzielen, Service-Konten zu übernehmen, die nicht mit einem zufällig automatisch generierten Passwort, sondern mit einem menschlich erdachten Passwort gesichert sind. Einzige Voraussetzung für diesen Angriff ist der Zugriff auf ein funktionierendes Nutzerkonto in der Domäne. Dieser Nutzer muss gar keine Zugriffsrechte für den zu knackenden Dienst haben, daher funktioniert der Angriff auch mit dem versteckten Nutzer: 

Im Anschluss haben wir Zugriff auf ein Nutzerkonto mit mehr Zugriffsrechten, meist sogar einigen administrativen Rechten und können uns so immer weiter in der Partner-Domäne ausbreiten. 

Mögliche Detektions- und Gegenmaßnahmen 

In den nächsten Abschnitten wollen wir uns anschauen, wie man sich gegen diese Art von Angriffen wappnen kann und auch kurz Maßnahmen besprechen, die zwar naheliegend klingen, aber nicht wirken.  

All diese Maßnahmen zielen auf die Sicherheit der vertrauten Domäne (in unserem Beispiel PARTNER.local). Für die vertrauende Domäne (in unserem Beispiel HISOCORP.local) gibt es unabhängig von dem hier geschilderten Problem auch einiges zu beachten, um nicht durch die Vertrauensstellung Probleme zu bekommen. Da dies aber der geplante Zugriffsweg ist, gibt es dazu bereits passende Anleitungen

Detektion 

Das versteckte Nutzerkonto für die Vertrauensstellung wird nie als Nutzer im eigentlichen Sinn verwendet. Daher sind jegliche Aktivitäten mit der Nutzerkennung (Muster <Domänenkürzel>$) wie das Ausstellen eines TGT (Windows Event 4768), eines Service Tickets (Anfordern Windows Event 4769, Erneuern Windows Event 4770, Fehler Windows Event 4773) oder eine Anmeldung ein eindeutiges Zeichen für eine Ausnutzung.  

Gegenmaßnahmen 

Auf verschiedenen Wegen kann die Anmeldung mit dem versteckten Nutzerkonto verhindert werden. 

Die Systeme der beiden Domänen befinden sich meist auch in unterschiedlichen Netzen, daher kann per Firewall der Zugriff auf Port 88 zum Domain Controller der vertrauten Domäne (in unserem Beispiel PARTNER.local) vom Netz der vertrauenden Domäne (HISOCORP.local) gesperrt werden. In die umgekehrte Richtung ist der Zugriff nötig, damit Nutzer sich Service Tickets für freigegebene Dienste der vertrauenden Domäne ziehen können, in dieser Richtung jedoch nicht. Damit wird der Angriff verhindert, wenn der Angreifer aus dem anderen Netz agiert. Hat der Angreifer unabhängig von der Kompromittierung der vertrauten Domäne auch bereits Netzwerkzugriff auf Systeme der vertrauten Domäne, hilft die Firewallregel nicht. 

Die Nutzung des versteckten Kontos kann auch per GPO unterbunden werden. Dafür muss die Regel „Zugriff vom Netzwerk auf diesen Computer verweigern“ erstellt werden und dort dann manuell das Konto (in unserem Beispiel HISOCPRP$) eintragen werden. Der Kontoname muss händisch eingegeben werden, da bei der „Durchsuchen“-Funktion das Konto auch ausgeblendet ist. Wenn die GPO wirksam ist, kann zwar weiterhin ein TGT für dieses Konto bezogen werden, aber keine Servicetickets. Damit geht auch kein Zugriff auf Dienste (wie Dateifreigaben) oder der oben geschilderte Kerberoasting-Angriff. 

Als weitere Verteidigungsschicht können die Zugriffsrechte für den Nutzer eingeschränkt werden. Der Nutzer ist automatisch Mitglied in der Gruppe „Domänenbenutzer“ und gehört auch zur Gruppe „Benutzer“. Dienste und Dateien sollten nicht für eine der beiden Gruppen freigegeben werden, auch wenn sie von allen genutzt werden sollen. Stattdessen bieten sich für solche Freigaben eine zusätzlich gepflegte Gruppe mit allen aktiven Nutzern an. 

Maßnahmen, die nicht wirken 

Es gibt einige Gegenmaßnahmen, die sehr naheliegend klingen, aber tatsächlich nicht umsetzbar oder hilfreich sind.  

So kann der versteckte Nutzer nicht einfach deaktiviert oder gelöscht werden, entsprechende Versuche führen direkt zu Fehlermeldungen.  

Der Nutzer hat als primäre Gruppe die Gruppe „Domänenbenutzer“. Das ist eine automatische Gruppenzuordnung, das heißt man kann zwar eine andere primäre Gruppe eintragen aber der Nutzer wird dennoch immer Mitglied der „Domänenbenutzer“ bleiben. 

Fazit 

Aus einer einseitigen Vertrauensstellung zwischen Domänen kann sich damit auch ein Risiko entgegen der „Direction of Access“ ergeben. Wird die eine Domäne kompromittiert erhält der Angreifer auch das Passwort für einen versteckten Nutzer in der anderen Domäne. Der hat zwar kaum Zugriffsrechte, aber kann als erster „Fuß in der Tür“ für weiterführende Angriffe genutzt werden. 

Da Risiko lässt sich aber durch Firewallregeln, GPOs und gutes Rechtemanagement adressieren. Ein erfolgreicher Angriff lässt sich auch eindeutig in den Windows Events identifizieren. 


  1. Im Folgenden werden wir der Einfachheit halber immer von einer Domäne sprechen, da sich ganze Forests in diesem Fall wie eine Domäne verhalten ↩︎

Weitere News im Juni

Sicherheitslücke durch inetpub: Wie ein gelöschter Ordner Windows verwundbar macht

Im April 2025 sorgte ein unscheinbarer Ordner namens inetpub auf Windows-Systemen für Aufsehen – und für ein ernstzunehmendes Sicherheitsproblem. Was zunächst wie ein harmloses Überbleibsel aus alten IIS-Zeiten wirkte, entpuppte sich als kritischer Bestandteil eines Sicherheitsupdates und als potenzielles Einfallstor für Angreifende.

Was ist passiert?

Mit dem April-Patchday legte Microsoft auf Windows 10- und 11-Systemen automatisch den Ordner C:\inetpub an. Dieser sollte laut Microsoft helfen, die Sicherheitslücke CVE-2025-21204 (Base Score: 7,8 von 10) zu entschärfen, die mit symbolischen Links (Symlinks) zusammenhängt. Dokumentation dazu fehlte zunächst – viele Nutzende hielten den Ordner für überflüssig und löschten ihn kurzerhand.

Das eigentliche Problem

Genau hier beginnt das Sicherheitsdilemma: Wenn der Ordner gelöscht wird, können zukünftige Windows-Updates fehlschlagen. Für die Ausnutzung dieser Sicherheitslücke ist kein ausgefeilter Angriff nötig. Es muss lediglich ein symbolischer Link von „inetpub” zu einer anderen Datei erstellt werden. Das System bleibt dann auf einem unsicheren Stand.

Microsofts Reaktion

Nachdem Sicherheitsforscher Kevin Beaumont auf das Problem aufmerksam gemacht hatte, veröffentlichte Microsoft ein PowerShell-Skript namens Set-InetpubFolderAcl.ps1. Dieses stellt den Ordner wieder her und setzt die korrekten Zugriffsrechte. Das Skript prüft auch, ob der Ordner manipuliert wurde und verhindert so weitere Missbrauchsmöglichkeiten.

Fazit: Ein Lehrstück in Kommunikation und Sicherheit

Der Fall zeigt, wie wichtig klare Kommunikation bei sicherheitsrelevanten Änderungen ist. Ein leerer Ordner mag harmlos wirken, doch in diesem Fall war er ein zentraler Bestandteil eines Sicherheitsmechanismus. Wer ihn entfernte oder manipulierte, öffnete sein System ungewollt für Angriffe.

Nutzende sollten prüfen, ob der Ordner inetpub vorhanden ist und ggf. das Microsoft-Skript ausführen, um die Sicherheit des Systems wiederherzustellen.

https://doublepulsar.com/microsofts-patch-for-cve-2025-21204-symlink-vulnerability-introduces-another-symlink-vulnerability-9ea085537741

https://www.heise.de/news/Microsoft-Abhilfe-fuer-Sicherheitsluecke-durch-geloeschte-inetpub-Ordner-10437103.html

https://www.golem.de/news/windows-10-und-11-mysterium-um-inetpub-ordner-teilweise-aufgeloest-2504-195313.html

https://www.golem.de/news/windows-leerer-inetpub-ordner-schafft-ein-neues-sicherheitsproblem-2504-195563.html

https://www.chip.de/news/Wie-ein-leerer-Ordner-fuer-Windows-zum-Sicherheitsproblem-wird_185936620.html

https://nvd.nist.gov/vuln/detail/cve-2025-21204

TM SGNL – (k)eine Signal-Alternative

Wir erinnern uns an die als Signalgate bekannt gewordene Affäre zu geleakten klassifizierten Informationen über einen Signal-Chat. Wie sich nun herausstellt, nutzten die Angehörigen der US-Regierung nicht den offiziellen Signal-Client, sondern eine abgeänderte Version von TeleMessage, einem israelischen Unternehmen. Diese Version von Signal ermöglichte aufgrund eines trivialen Fehlers den Zugriff auf Chats. @micahflee@infosec.exchange und @ljrk@todon.eu haben interessante Details gefunden.

Für alle Kryptografie-Interessierten empfehlen wir den Blog von @soatok@furry.engineer zu dem Thema, in dem zu lesen ist, was eine Signal-Alternative zu erfüllen hat (und warum die meisten Messenger bereits dort scheitern).

Windows RDP-Cache – Wenn der Cache länger hält, als er soll

Windows RDP-Caches erlauben Log-ins mit alten Credentials, die bereits rotiert wurden. Microsoft behauptet allerdings, dass dies ein Feature sei, damit man sich nicht aussperrt. Die IT-Sicherheits-Szene reagierte irritiert. Es empfiehlt sich, einen Blick auf die eigenen Konfigurationen dazu zu werfen.

https://arstechnica.com/security/2025/04/windows-rdp-lets-you-log-in-using-revoked-passwords-microsoft-is-ok-with-that

Kritische Schwachstelle in WooCommerce Wishlist lange Zeit ohne Patch

In den WordPress-Fällen der letzten Monate ist uns das Modul WooCommerce öfter aufgefallen. Nun stellte sich heraus: Bereits im März wurde eine kritische Lücke (CVE-2025-47577) dem Hersteller gemeldet, worauf dieser aber nicht reagierte. Bei der Lücke handelt es sich um ein „pre-Auth RCE“, also die Möglichkeit zur Ausführung von Schadcode ohne vorhergehende gültige Benutzeranmeldung. Die technischen Details sind im verlinkten Artikel einsehbar.

Dieser Vorfall sollte die Wichtigkeit von Supply-Chains und weiterführenden Mitigationsmaßnahmen neben dem Patchen klar machen, denn manchmal steht kein Patch zur Verfügung.

https://patchstack.com/articles/unpatched-critical-vulnerability-in-ti-woocommerce-wishlist-plugin

Weitere News im Mai

Unser Top-Thema im Mai: Woher kommen eigentlich Zero-Days?

Google M-Trends 2025 – Neues aus der IR-Welt

Google bzw. sein Tochterunternehmen Mandiant berichtet im aktuellen M-Trends-Report von ihren Erkenntnissen zu aktuellen Themen aus der Incident Response. @GossiTheDog@cyberplace.social, eine bekannte Persönlichkeit aus der IT-Sicherheitsszene, hat ebenfalls seine Einschätzung zu dem Thema in einem „Toot“ im sozialen Netzwerk Mastodon veröffentlicht. Diese ist nicht nur spannend für IR-Bereiche, sondern auch für Unternehmen, die sich schützen möchten: Ausgenutzte Schwachstellen kommen hauptsächlich in Cybersecurity-Produkten vor, meist innerhalb von Firewalls. Bei der Bewertung sollte jedoch auch berücksichtigt werden: Firewalls werden auch deshalb häufig angegriffen, weil sie die erste Kontaktstelle nach außen sind. 

Es geht ebenfalls um viele weitere Themen, weswegen wir empfehlen, auf jeden Fall einen Blick in den Report zu werfen. Wir freuen uns, die Erkenntnisse mit Ihnen auf Mastodon einzuordnen und zu diskutieren!

https://services.google.com/fh/files/misc/m-trends-2025-en.pdf

ActiveX ist endlich weg – also fast

Microsoft hat in den letzten Jahren immer wieder Features standardmäßig deaktiviert, die gerne durch Angreifende genutzt werden (wir erinnern uns an XLM-Macros und VBScript). Nun beglückt uns Redmond erneut mit einer schon lange erwarteten Nachricht: ActiveX wird in M365 und Office 2024 deaktiviert –  zumindest im Standard, eine Reaktivierung ist noch möglich.

Wir können der Empfehlung von Microsoft nur beipflichten.

https://www.bleepingcomputer.com/news/microsoft/microsoft-blocks-activex-by-default-in-microsoft-365-office-2024

Windows Server kann jetzt Hotpatching

Microsoft hat einen weiteren interessanten Service angekündigt: Hotpatching. Dabei werden acht der 12 monatlichen Patches so installiert, dass die Änderungen im Hauptspeicher angewandt werden, ohne dass ein Reboot des Systems notwendig ist. Ob dies die damit verbundenen Kosten von 1,50 € pro CPU und Monat wert ist, muss man im Einzelfall entscheiden.

Microsoft.com

Vom Handy bis zur Cloud – die Lücken des Monats

Zwei Vorfälle haben viele Administratoren im letzten Monat bewegt: Die Schwachstellen im Ivanti Endpoint Manager Mobile (EPMM), besser bekannt unter dem alten Namen MobileIron, und die gefälschten Zugangstoken für Microsofts Cloud. Gemeinsam ist beiden Fällen, dass sie initial bei der Analyse von Sicherheitsvorfällen entdeckt wurden.

Auch viele deutsche Unternehmen und Behörden nutzen MobileIron/Ivanti für die Verwaltung ihrer Smartphones und waren daher von der Lücke betroffen. Da die Handys regelmäßig mit dem Verwaltungsserver sprechen müssen, ist dieser meist zum Internet exponiert und damit leicht angreifbar. Der Hersteller hat eine aktualisierte Version nicht nur für die aktuellen Versionen, sondern auch für ältere Versionsstränge herausgebracht. Diese sollten dringend installiert werden, da die Lücke bereits ausgenutzt wurde.
Aufgrund der vielen Betroffenen hat HiSolutions wieder die wichtigsten Punkte als Hilfe zur Selbsthilfe veröffentlicht und pflegt dort regelmäßig die neuesten Erkenntnisse nach: Zum Selbsthilfeleitfaden

Microsoft musste ebenfalls einen erfolgreichen Fremdzugriff auf Mailpostfächer einräumen. Die Angreifer konnten mithilfe von gefälschten Zugangstoken direkt auf die Postfächer der betroffenen Organisation zugreifen. Dahinter steckte jedoch kein Fehler am Anmeldemechanismus, die Angreifer hatten vermutlich einen der privaten Signaturschlüssel und konnten dann ganz leicht beliebige Token ausstellen und korrekt signieren. Der betroffene Schlüssel wurde inzwischen gesperrt. Microsoft liefert außerdem weitere Informationen, mit denen potenziell Betroffene prüfen können, ob die Angreifer auch bei ihnen erfolgreich waren. Die Forscher bei Wiz Research haben sich mögliche Auswirkungen auf weitere Anwendungen über die Cloud-Maillösung hinaus angeschaut. Ihr Ergebnis ist, dass einige weitere Anwendungen (ob selbst entwickelt oder eingekauft), die ebenfalls Azure AD zur Anmeldung nutzen, betroffen sein könnten. Es ist aber unklar, ob die Angreifer dies tatsächlich ausgenutzt haben.

Hafnium Reloaded – Wieder kritische Schwachstellen in Microsoft Exchange

Und täglich grüßt das Murmeltier? Nicht ganz. Trotzdem erleben wir aktuell ein Déjà-vu mit Microsoft Exchange: Am 13.04.2021 19 Uhr MESZ wurden vier neue hochkritische Schwachstellen samt dazugehörigem Patch veröffentlicht.

Das BSI warnt bereits vor der Schwachstelle und fordert dazu auf, sehr zeitnah die eigenen Systeme zu patchen. Die Cybersecurity and Infrastructure Security Agency (CISA) des US Department of Homeland Security (DHS) geht sogar noch einen Schritt weiter und wird am Freitag, den 16.04.2021 alle nicht gepatchten Systeme aus dem eigenen Netzwerk ausschließen.

Bei den von der NSA an Microsoft gemeldeten Schwachstelle handelt es sich u. a. wieder um Remote-Code-Execution-Lücken mit einem sehr hohen CVSS Score von 9.8 (auf einer 10er-Skala). Hierbei kann, ähnlich wie bei Hafnium, ein entfernter Angreifer Code auf die Systeme einschleusen und diese ggf. übernehmen. Bei den Schwachstellen handelt es sich um die folgenden CVEs:

  • CVE-2021-28480 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28481 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28482 Microsoft Server Remote Code Execution Vulnerability
  • CVE-2021-28483 Microsoft Server Remote Code Execution Vulnerability

Patches stehen bereits für die folgenden Systeme zur Verfügung:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 und CU20
  • Exchange Server 2019 CU8 und CU9

Das nicht mehr unterstützte Exchange Server 2010 soll diesmal nicht betroffen sein.

Die Schwachstellen werden aktuell anscheinend noch nicht ausgenutzt. Es dürfte aber nur eine Frage der Zeit sein, bis entsprechende Exploits zur Verfügung stehen . Daher sollten betroffene Exchange-Systeme noch heute gepatcht werden.

Wir empfehlen darüber hinaus weiterhin, Exchange-Umgebungen engmaschig zu kontrollieren.

HAFNIUM Exchange-Schwachstellen: Überblick

Die hochkritischen HAFNIUM-Lücken (CVE-2021-26855 aka ProxyLogon), CVE-2021-26857, CVE-2021-26858 und CVE-2021-27065) bedrohen weiterhin IT-Infrastrukturen weltweit. Auf dieser Seite haben wir die wichtigsten Informationen und Hilfsmittel für Sie zusammengestellt.

Update 14.4.2021: Durch neue kritische Exchange-Schwachstellen könnte eine weitere Hafnium-ähnliche Welle drohen.

Wie Sie den Medien entnehmen konnten oder in nicht wenigen Fällen auch in der eigenen Betroffenheit bemerkt haben, beherrscht das Thema der kritischen Microsoft Exchange Lücke zur Zeit die IT. Bei HiSolutions haben wir aus allen Bereichen Ressourcen zusammengezogen, um den sprunghaft gestiegenen Bedarf an Incident Response und Forensik auffangen zu können. Wir bitten um Verständnis, wenn der Zeitplan des einen oder anderen Projektes aktuell darunter leidet und danken vor allem für das große Verständnis – und dafür, dass wir alle gemeinsam an der Bewältigung dieser Krise arbeiten!

In den letzten Wochen konnten wir daher viele Anfragen zur Security nicht sofort annehmen. Sobald sich die aktuelle Lage beruhigt, würden wir uns gerne bei Ihnen zurückmelden, um Verbesserungen anzugehen.

ProxyLogon-Logo

Letzte Beiträge

  • Hafnium – Überwachen Ihrer Systeme mit Loki
    Auch mehr als ein Jahr nach der gravierenden Hafnium-Schwachstelle sind immer noch nicht alle Systeme abgesichert. Wir haben nun unsere Handreichung Hafnium – Überwachen Sie Ihre Systeme aktualisiert, um aufgrund der Lizenzbedingungen den Scanner Loki (statt Loki und Thor) zu empfehlen.
  • Hafnium Reloaded – Wieder kritische Schwachstellen in Microsoft Exchange
    Und täglich grüßt das Murmeltier? Nicht ganz. Trotzdem erleben wir aktuell ein Déjà-vu mit Microsoft Exchange: Am 13.04.2021 19 Uhr MESZ wurden vier neue hochkritische Schwachstellen samt dazugehörigem Patch veröffentlicht. Das BSI warnt bereits vor der Schwachstelle und fordert dazu auf, sehr zeitnah die eigenen Systeme zu patchen. Die Cybersecurity and Infrastructure Security Agency (CISA) des US Department of Homeland Security (DHS) geht sogar noch einen Schritt weiter und wird am Freitag, den 16.04.2021 alle nicht gepatchten Systeme aus dem […]
  • HAFNIUM/ProxyLogon: Self-Help Guide To Securing Microsoft Exchange
    Due to the high demand for current, in-depth information on how to mitigate the HAFNIUM/ProxyLogon vulnerabilities in Microsoft Exchange we translated our free German HiSolutions Self-Help Guide into English.
  • HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht
    [GTranslate] Von Inés Atug, Markus Drenger und Daniel Jedecke. Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den […]
  • HAFNIUM Exchange-Schwachstellen: Überblick
    Die hochkritischen HAFNIUM-Lücken (CVE-2021-26855 aka ProxyLogon), CVE-2021-26857, CVE-2021-26858 und CVE-2021-27065) bedrohen weiterhin IT-Infrastrukturen weltweit. Auf dieser Seite haben wir die wichtigsten Informationen und Hilfsmittel für Sie zusammengestellt. Update 14.4.2021: Durch neue kritische Exchange-Schwachstellen könnte eine weitere Hafnium-ähnliche Welle drohen. Wie Sie den Medien entnehmen konnten oder in nicht wenigen Fällen auch in der eigenen Betroffenheit bemerkt haben, beherrscht das Thema der kritischen Microsoft Exchange Lücke zur Zeit die IT. Bei HiSolutions haben wir aus allen Bereichen Ressourcen zusammengezogen, um den […]

HAFNIUM/ProxyLogon bei Microsoft Exchange: Hilfe zur Selbsthilfe

[GTranslate]

UPDATE vom 24.03.2021: Empfehlung zur Dauer der Überwachung der Systeme nach Kompromittierung durch ProxyLogon ergänzt (12 Monate).

English version is here.

Feedback ist gerne erwünscht. Aufgrund der Kritikalität der Schwachstelle haben wir uns entschlossen, alle Informationen hierzu als TLP-WHITE zu veröffentlichen. Das Dokument ist zudem lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Für jeweils aktuelle Infos abonnieren Sie auch gerne unseren monatlichen Cybersecurity Digest.

UPDATE vom 17.03.2021: Wir haben die HAFNIUM-Selbsthilfe auf den neusten Stand gebracht und Tool- und Maßnahmenempfehlungen geschärft. Angesichts der zu erwartenden Angriffe über abgeflossene E-Mails und Kontakte haben wir auch unsere Empfehlungen zur Sensibilisierung vor Phishing-Angriffen konkretisiert.

UPDATE vom 14.03.2021: Wir haben am Wochenende parallel zur Incident Response weiteren Research betrieben und uns mit vielen Leuten ausgetauscht. Wir haben erste Erkenntnisse, dass die Angreifer Dateiberechtigungen verändern, um das Installieren von Patchen zu verhindern. Zudem stellen wir vermehrt Ransomware-Angriffe fest.

Auch haben wir ein Update bezüglich des Microsoft Support Emergency Response Tools (MSERT) eingearbeitet. Obwohl MSERT für diesen Anlass angemessen ist, raten wir aktuell zur Vorsicht bei der Nutzung. Das Tool löscht u. U. Shells und kann die vollständige Bereinigung nicht sicherstellen und die Forensik erschweren.

Zudem haben wir nun auch ein Dokument veröffentlich, um mittels Thor Lite die Systeme zu untersuchen und eine grundlegende Überprüfung des Active Directory durchzuführen.


UPDATE vom 12.03.2021 Teil 2: Wir haben die Maßnahmen (auch nach einer möglichen Kompromittierung) umfangreich angepasst. Sobald wir mehr Informationen über die aktuell verteile Ransomware haben werden diese noch nachsteuern. Das BSI hat seine Warnmeldung heute ebenfalls aktualisiert.


UPDATE vom 12.03.2021: Wir haben das Dokument erneut aktualisiert. Feedback gerne wieder an uns. Zudem haben wir einen Verweis auf den Datenschutz eingebaut sowie die Maßnahmen konkretisiert.


UPDATE vom 10.03.2021: Vielen Dank für das viele Feedback und die Anregungen. Wir haben das Dokument überarbeitet und die neusten Empfehlungen des BSI, Erkenntnisse aus der Forensik sowie einige Vereinfachungen im Bereich Monitoring eingearbeitet. Feedback weiterhin gerne an uns oder per Twitter an (@Jedi_meister).


Um unseren Kunden einen ersten Leitfaden zum Umgang mit der HAFNIUM/ProxyLogon-Thematik an die Hand zu geben, haben wir einen Leitfaden „Hilfe zur Selbsthilfe“ herausgebracht. Dieser kombiniert die Empfehlungen des BSI, unsere fachliche Expertise sowie Informationen des Herstellers Microsoft.

Der Leitfaden soll als erster Indikator dienen und eine einfach zu befolgende Checkliste darstellen. Wir aktualisieren das Dokument laufend mit den neusten Erkenntnissen aus unseren Fällen.

Aufgrund der Kritikalität der Schwachstelle verteilen wir den Leitfaden kostenfrei. Sofern Sie Microsoft Exchange nutzen, prüfen Sie bitte, ob Sie bereits alle Schritte durchgeführt haben. Beachten Sie, dass Microsoft am 09.03.2021, dem regulären Patch Tuesday, weitere kritische Lücken in seinen Produkten geschlossen hat!

Weitere Informationen unter:

HAFNIUM/ProxyLogon: Akute Angriffswelle auf Microsoft Exchange

Seit in der Nacht zum Mittwoch, 3. März 2021, das Microsoft Threat Intelligence Center (MSTIC) über eine akute Angriffswelle auf Microsoft Exchange Server informiert hat, haben IT-Organisationen weltweit alle Hände voll zu tun, die ausgenutzten Schwachstellen (inkl. ProxyLogon) zu schließen, eine mögliche Kompromittierung abzuchecken und ggf. Aufräumarbeiten durchzuführen.

Auch wenn Microsoft umgehend Out-of-band Updates veröffentlich hat, wurde schnell klar, dass die vier beschriebenen Schwachstellen in Kombination bereits für zielgerichtete Angriffe verwendet wurden und vielerorts die Möglichkeit boten und bieten, Daten abzugreifen oder weitere Schadsoftware zu installieren.

https://blogs.microsoft.com/on-the-issues/2021/03/02/new-nation-state-cyberattacks/

Zu den Sofortmaßnahmen gehört neben dem umgehenden Einspielen der Patches die sofortige Deaktivierung der über HTTPS erreichbaren Dienste (OWA, ECP, UM, VDir, OAB). Eine erste Überprüfung auf Kompromittierung kann mittels eines von Microsoft bereitgestellten Scriptes oder durch Scannen des Microsoft Exchange Server mit dem Microsoft Support Emergency Response Tool (MSERT) erfolgen. Um die Möglichkeit der Angriffsdetektion zu verbessern, sollte außerdem die Protokollierung der Exchange-Server und des Active Directory ausgeweitet werden.

Im Falle der Detektion einer Kompromittierung (z. B. einer Webshell) müssen das System und je nach Berechtigungen ggf. weitere Systeme wie etwa das Active Directory näher untersucht werden. Hier muss darauf geachtet werden, ob es zum besagten Zeitraum zu Kontenerstellung, vermehrten Zugriffen oder ähnlichen Auffälligkeiten gekommen ist.

Unsere Handlungsempfehlungen

Weitere Ressourcen

Meine Analytics! Microsoft 365 durchleuchtet User

Das „My“ im Namen ist gleichzeitig verräterisch und irreführend: Die Erweiterung MyAnalytics in Microsoft 365 erfasst massenhaft Nutzungsdaten. Seit die Funktion, die umfassend auf Kalender- und E-Mail-Daten zugreifen kann, auch für Europa freigeschaltet wurde, gibt es plötzlich einen Aufschrei in Bezug auf Datenschutz und betrieblicher Mitbestimmung. Wird die Funktion „Productivity Score“ aktiviert, so werden standardmäßig Namen, Gruppenzugehörigkeiten und Standorte aller Angestellten sowie automatisch auch alle Nutzungsdaten von Word, PowerPoint, Excel, OneNote, Outlook, Skype und Teams aufgezeichnet – die perfekte Leistungsüberwachung, zumindest von der Möglichkeit her. Eine Anonymisierung muss gezielt durch Admins erfolgen, deren Zugriffe durch die User selbst nicht nachvollzogen werden können. 

https://www.sueddeutsche.de/digital/microsoft-productivity-score-ueberwachung-arbeitsplatz-1.5130228

Es sieht schwarz aus für den Rotwald – Microsoft kündigt ESAE ab

Das unaussprechliche Enhanced Security Admin Environment (ESAE), vielen auch unter dem griffigeren Namen Red Forest bekannt, ist ein Konzept, das in Kennerinnen und Kennern unterschiedlichste Reaktionen ausgelöst hat: von Ehrfurcht (ob des möglichen Sicherheitsniveaus) bis zu hysterischem Lachen (ob des sechsstelligen Taschengeldes, das notwendig war, damit Vertreter der Erfinderin Microsoft überhaupt vorbeikamen, um über diese Geheimwaffe zu reden). Nun schickt Redmond den Red Forest aufs Altenteil – zu komplex und zu schwerfällig war die Idee, um unter dem Strich für ein Plus an Hochsicherheit sorgen zu können. Ersetzt werden soll ESAE nach Microsofts Idee durch die hauseigene Privileged Access Strategy und die Rapid Modernization Plan (RAMP) Anleitung. Einzig Microsoft selbst möchte intern weiter eine Art Red Forest betreiben „because of the extreme security requirements for providing trusted cloud services to organizations around the globe.“

https://docs.microsoft.com/en-us/security/compass/esae-retirement