Kommentare zu folgendem Beitrag: RobinHood: Ransomware bringt eigenes Exploit für Infektionen mit
RobbinHood oder RobinHood?
Update: Irgendwie schreibt jeder die Malware, wie es ihm gerade gefällt. In den Medien wird die Schafsoftware mittlerweile größtenteils mit zwei b (= RobbinHood) bezeichnet, die Sicherheitsforscher von Sentinel Labs benutzten nur ein b. Wie auch immer man die Software schreibt, sie ist und bleibt gefährlich.
Vielleicht wurde der Name ja auch von Round-Robin abgeleitet, das wäre dann mit einem „b“!
Der Begriff Rundlauf-Verfahren , englisch Round-Robin , bezeichnet ein Scheduling-Verfahren, ein Verfahren, das Warteschlangen abarbeitet.
Zum Einsatz kommt es beispielsweise als Prozess-Scheduler, wo es mehreren konkurrierenden Prozessen begrenzte Ausführungs-Ressourcen zuordnet (z.B. CPU-Zeit zur Berechnung etc.)
Ja, kann auch gut sein. Der Held in Strumpfhosen vom Sherwood Forest wird auf jeden Fall mit nur einem b geschrieben. 
Hier mal eine kurze Erläuterung, wie RobinHood mit dem uralten Treiber von Gigabyte überhaupt in der Lage ist, so eine tiefgreifende Aktion im Kernel auszuführen, die z.B. die Abschaltung der AV-Prozesse zur Folge hat!
RobinHood selber existiert ja schon ein paar Jahre in einer sehr ausgereiften Version, die auch früher schon Prozesse (ca. 170) selbstständig „killen“ konnte. Die Infektion eines Opfers läuft aber bislang immer auf die selbe Art und Weise ab.
Hauptverantwortlich für diese neue Art der feindlichen Übernahme der Rechner, ist eigentlich Microsoft selber!
Der benannte Treiber wurde schon 2018 als „vulnerable“ gekennzeichnet, nachdem die DLL fast 10 Jahre genutzt wurde - siehe:
https://nvd.nist.gov/vuln/detail/CVE-2018-19320
Gigabyte hat dann widerwillig den Treiber vom Markt entfernt. Die Verbreitung des Herstellers über seine verifizierten (per Zertifikat) eigenen Update-Server wurde parallel abgeschaltet ! Natürlich INKLUSIVE des betreffenden Zertifikats !
Anstatt das MS dieses Zertifikat auch aus seiner eigenen Treiber-Signierungsstelle entfernt, bleibt dieses mit alle seinen negativen Folgen in den Systemen erhalten!
Das ein Treiber mit dieser sicherheitsrelevanten Vergangenheit nicht nur offiziell beim Hersteller zu beziehen ist, sondern auch von Dritten unter Einbeziehung des ungültigen Zertifikats genutzt werden kann, wurde vorsätzlich vollständig ignoriert…
Den RobinHood Devs wurde somit eine 11er Vorlage geschenkt ! Das Verfahren, welches durch den Treiber genutzt wird, für die aktuellen Ergebnisse, ist ebenfalls uralt und wird sogar seit Jahren bei Github zur Verfügung gestellt!
https://github.com/hfiref0x/DSEFix/blob/master/README.md
Der somit problemlos injizierte Treiber verwendet die WinNT/Turla VirtualBox-Kernelmodus-Exploit-Technik, um globale Systemvariablen zu überschreiben, die das DSE-Verhalten steuern, die sich ihrerseits im Kernel-Speicherbereich befinden. Vor Windows 8 ist es ntoskrnl!g_CiEnabled - eine boolesche Variable (0 deaktiviert, 1 aktiviert) und ab Windows 8 ist es CI.DLL!g_CiOptions - eine Kombination von Flags, wobei der Wert 6 eine Standardoption und der Wert 0 gleich „keine Integritätsprüfungen“ ist. Wenn Sie DSEFix ohne Parameter ausführen, wird es versuchen, DSE je nach Systemversion zu deaktivieren. Wenn Sie DSEFix mit dem Parameter „-e“ (ohne Anführungszeichen) ausführen, versucht es, die DSE-Steuervariable in den Standardzustand zurückzusetzen.
Warnung, ab Windows 8.1 CI.DLL-Variablen, die durch Kernel Patch Protection (PatchGuard) als generische Datenregion geschützt sind. Dies bedeutet keine sofortige PatchGuard-Antwort (BSOD), sondern führt letztendlich dazu, wenn PatchGuard in der Lage ist, die Modifikationsfakten zu erkennen (es spielt keine Rolle, ob Sie den ursprünglichen Zustand wiederherstellen). Die Reaktionszeit ist fast zufällig. Sie kann fast sofort erfolgen, oder eine Stunde, zwei oder vier usw. dauern.
DSEFix basiert auf dem alten Oracle VirtualBox-Treiber, der 2008 erstellt wurde. Dieser Treiber wurde nicht für die Kompatibilität mit den neuesten Windows-Betriebssystemversionen entwickelt und funktioniert möglicherweise nicht korrekt. Da DSEFix vollständig auf genau dieser VirtualBox-Treiberversion LPE basiert, ist es nicht ratsam, ihn auf der neuesten Version von Windows zu verwenden.
Man sieht also, dass man als Entwickler von Ransomware nicht jedes mal das Rad neu erfinden muß, da reicht auch oft die Ignoranz und Dummheit der Hersteller und bastelt etwas aus alten Teilen zusammen…
1 „Gefällt mir“