[English]Heute noch ein Hinweis für Administratoren in Unternehmensumgebungen. Mit einer simplen Active Directory-Einstellung kann man Windows-Netzwerkumgebungen gegen die Verbreitung von Ransomware wie NotPetya härten.
Anzeige
Die Ransomware NotPetya infizierte im Sommer 2017 ja, ausgehend von der Ukraine, tausende Computersysteme mit Windows. Die Verbreitung erfolgte dann über das Netzwerk, indem eine EternalBlue-Sicherheitslücke genutzt wurde. Die Russland zugeschriebene Cyberattacke der Ransomware NotPetya, die von ESET als Win32/Diskcoder.C erkannt wird, hat zwar nur gut 20.000 Systeme betroffen (siehe Neues zu Petya: Zahl der Infektionen, Ziele und mehr …). Aber die Schäden sind teilweise gigantisch. Wie wäre es, wenn man zumindest die Verbreitung einer solchen Malware per Netzwerk beschränken könnte?
Ein Sicherheitsteam baut einen Test-Computerwurm
An dieser Stelle wird das Ganze zum Krimi. Sicherheitsforscher der NCC Group begannen nach dem NotPetya-Angriff für einen großen Kunden (100 Milliarden Dollar-Unternehmen) einen Computer-Wurm mit dem Namen EternalGlue zu entwickeln. An dieser Software wollte man studieren, wie sich dieser Wurm im globalen Computernetzwerk des Kunden bewegt. Zudem ging es auch darum, zu verstehen, wie man das Produktionsnetzwerk des Kunden besser gegen destruktive Malware-Ausbrüche absichern kann.
Seit 2017 veröffentlichen die Sicherheitsforscher der NCC Group in Blog-Beiträgen ihre Erkenntnisse. Im September 2017 erscheint der erste Artikel EternalGlue part one: Rebuilding NotPetya to assess real-world resilience mit einigen Informationen zum NotPetya-Nachbau EternalGlue. Und im Februar 2018 beschrieben die Spezialisten im Beitrag EternalGlue part two: A rebuilt NotPetya gets its first execution outside of the lab, wie der Nachbau des Wurms erstmals für einen Test in der Praxis in einem Produktionsnetzwerk vorbereitet wurde. Und nun haben die NCC-Leute den dritten Artikel mit den Erfahrungen beim Umgang mit dem Wurm in einem Produktionsnetzwerk veröffentlicht. Der folgende Tweet verweist auf den betreffenden Beitrag.
We designed it, we built it, and we successfully deployed it. EternalGlue part three: Releasing a worm into an enterprise network of a 100 billion dollar company: https://t.co/SaHXG2VYNt#EternalGlue #Series #Malware pic.twitter.com/246AQKere1
— NCC Group plc (@NCCGroupplc) 3. Dezember 2018
Anzeige
Seit dem 8. November 2018 betreiben die NCC-Leute den EternalGlue genannten Wurm erstmals erfolgreich in einer globalen Produktionsumgebung des Zero genannten (aber ungenannt bleiben wollenden) Kunden.
Mit dem von der NCC Group entwickelten modularen Computerwurm konnten Produktionsnetzwerke analysiert werden. Man konnte dem Kunden nicht nur zeigen, wie sich eine entsprechende Malware auf seine Produktionsnetzwerke ausgewirkt hätten. Es ließ sich auch prüfen, ob bestimmte Designentscheidungen und daraus resultierende Annahmen über Widerstandsfähigkeit und Reaktionsfähigkeit gegenüber bzw. auf Malwareangriffe zutreffen. Der Testwurm ermöglichte eine Messung von solcher Ereignisse und erlaubte ein quantifizierbares Verständnis für interne Risiko-, Sicherheits- und Betriebsfunktionen.
Netzwerkhärtung ist leicht möglich
Der modulare Testwurm war so konfiguriert, dass er einerseits keine Schäden anrichtet und andererseits bestimmte Netzwerkbereiche von einer 'Infektion' aussparte. Die Sicherheitsforscher schreiben, dass es keine Überraschungen gab und die Kontrollen des Wurms funktionierten. Aus der Sicht der Tester geschah alles, was erwartet wurde. Aber im Rahmen der Tests kam es irgendwann zu einem Wow-Moment, als ein wirksamer Schutz gegen die Verbreitung des Wurms entdeckt wurde.
Die Ransomware NotPetya konnte die EternalBlue-Schwachstelle zur Ausbreitung verwenden. Diese lässt sich aber durch längst verfügbare Windows-Updates schließen. Eine zweite, von NotPetya im Netzwerk verwendete Verbreitungsmethode basierte auf Token-Imitation. Bedeutet, dass NotPetya die Ausführungsrechte, die es auf einer Maschine erlangte, im Netzwerk für den Zugriff auf weitere Ressourcen verwendete.
Der Testwurm führte dann zur Erkenntnis, dass es in Windows eine Active Directory-Einstellung gibt, die genau dies verhindern kann. Microsoft hat im Mai 2015 im Technet den Artikel Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts veröffentlicht. Darin beschreibt Ian Farr von Microsoft, dass es eine eine Reihe von Konfigurationsoptionen gibt, die sich zur Sicherung hochprivilegierter Konten empfehlen. Eine dieser Optionen heißt "Konto ist vertraulich und kann nicht delegiert werden" ('Account is sensitive and cannot be delegated').
(Quelle: Microsoft)
Ist diese Option aktiviert, stellt das sicher, dass die Anmeldeinformationen eines Kontos nicht von einer vertrauenswürdigen Anwendung an andere Computer oder Dienste im Netzwerk weitergeleitet werden können.
Der Kunde Null hatte innerhalb seines Active Directory das Flag "Konto ist sensibel und kann nicht delegiert werden" für seine Domain-Administratorkonten konfiguriert. Die Sicherheitsforscher fanden nun heraus, dass diese Konfiguration die Verbreitung der NotPetya-Ransomware-Infektion über die Token-Imersonationsroute für Domain-Administrationskonten erheblich behindert hätte. Sprich: Mit einer simplen Option der Active Directory-Administrator-Konten lässt sich eine Netzwerkumgebung gegen Angriffe wie NotPetya zumindest härten. Weitere Details sind dem Artikel hier zu entnehmen. Ein Abriss der Geschichte ist auch bei The Register zu finden.
Ähnliche Artikel:
Master-Key der Petya Ransomware freigegeben
ESET Analyse zu Not Petya/Diskcoder.C Verbreitung
Neues zu Petya: Zahl der Infektionen, Ziele und mehr …
Neues zur Petya Ransomware – Gegenmittel gefunden?
Achtung: Petya Ransomware befällt weltweit Systeme
Anzeige
Danke für den Hinweis. Finde deinen Blog einfach Spitzenklasse!
Nur mal wieder nicht so toll für die, die EFS im Einsatz haben. Dort darf man den Hacken nicht setzten. Werden aber nur die wenigsten haben.
Gruss
Alitai
@Altai: Danke für die Rückmeldung. Ich bin im AD nicht so zuhause – hast Du eine Fundstelle, die erklärt, warum die Option bei Verwendung des Encrypting File Systems (EFS) Probleme macht? Kann man dann über Netzwerk nicht mehr auf EFS-verschlüsselte Dateien zugreifen?
Ergänzung: Von Andreas E. ging mir über Facebook ein weiterer Hinweis zu, den ich einfach mal so einstelle. Laut Andreas hilft der Credential Guard ebenfalls dabei, das Netzwerk für diese Art Angriffe zu härten. Zudem kann man den Domain-Admins das Anmelden an allem außer PAWs/DCs verbieten bzw. Domain-Admins aus der Gruppe der lokalen Administratoren überall rauswerfen. Ich bin in dem Themenfeld nicht zuhause, ich denke, betroffene Administratoren dürften mit den Hinweisen was anfangen können.
BTW: Ist die oben adressierte Thematik euch eigentlich bekannt gewesen und kalter Kaffee? Oder segelt ihr eher mit 'wird schon irgenwie hinhauen' durch die AD-Administration?
Die lokalen Gruppen auf Desktop-Computern sollten sich mit eingeschränkten Gruppen per Gruppenrichtlinie so modifizieren lassen, dass dort keine Domänen-Admins mehr enthalten sind. Domänen-Benutzer bekomme ich auf dieselbe Art aus den lokalen Benutzern rauskastriert.
Fraglich wäre, ob dann noch MMC-Konsolen (z. B. RSAT) per UAC gestartet werden können
Naja, diese "neue Erkenntnis" dürfte eigentlich jedem bekann sein, der sich mit AD-Sicherheit auch nur einmal beschäftigt hat. Dafür kann man z. B., wenn man es sich denn zutraut, eine Software durch sein Netzwerk jagen zu lassen den PingCastle Healtchcheck im AD laufen lassen und sich schön grafisch auswerten lassen, wo es noch Nachbesserungsbedarf gibt: https://www.pingcastle.com/download/
Dort wird genau diese Funktion ebenfalls ausgewertet und angemeckert, wenn bemerkt wird, dass besagtes Konto für administrative Zwecke verwendet wird. Aber schön dass ein 100-Millionen-Dollar Unternehmen für diese Erkenntnis extra einen Wurm bauen musste *hust*, sich aber offenbar keinen Enterprise Admin leisten kann^^