Die ursprüngliche Lücke CVE-2026-21510 ließ sich für die Ausführung von Schadcode aus der Ferne nutzen, wenn ein Angreifer das Opfer dazu brachte, eine bösartige Verknüpfungsdatei zu öffnen. Parallel dazu existierte mit CVE-2026-21513 ein Bypass einer Sicherheitsfunktion im MSHTML-Framework, das Microsoft im Februar ebenfalls behob.
In seinem Hinweis beschreibt Microsoft den Angriffsweg so: Ein Angreifer könne die Lücke ausnutzen, indem er einen Nutzer dazu bringe, eine manipulierte HTML- oder Verknüpfungsdatei (.lnk) zu öffnen, die über einen Link, einen E-Mail-Anhang oder einen Download verbreitet werde. Die speziell präparierte Datei manipuliere die Verarbeitung im Browser und in der Windows-Shell, sodass das Betriebssystem den Inhalt ausführe.
Akamai schrieb die Ausnutzung von CVE-2026-21513 in diesem Zeitraum der Gruppe APT28 zu, erwähnte CVE-2026-21510 zunächst aber nicht, weil das Unternehmen den unvollständigen Patch bereits zuvor entdeckt hatte. Diese mangelhafte Behebung führte nach Darstellung von Akamai zur neuen Schwachstelle CVE-2026-32202. Das Unternehmen meldete sie an Microsoft; die Lücke bringt das Opfer ohne Nutzerinteraktion dazu, sich gegenüber dem Server des Angreifers zu authentifizieren – ein Zero-Click-Angriff. Microsoft lieferte die Korrekturen für CVE-2026-32202 mit den April-Patches 2026 nach und markiert den Fehler in seinem Hinweis als ausgenutzt, ohne Einzelheiten zu den Angriffen zu nennen.
Laut Akamai wurden diese Schwachstellen vermutlich im Dezember 2025 von APT28 in Angriffen gegen die Ukraine und EU-Staaten ausgenutzt. Dabei setzte die Gruppe präparierte LNK-Dateien ein, die CVE-2026-21513 und CVE-2026-21510 verketteten, um die Sicherheitsfunktionen von Windows zu umgehen und Schadcode aus der Ferne auszuführen.
Technisch nutzt APT28 laut Akamai den Mechanismus zum Parsen des Windows-Shell-Namespace, um über einen UNC-Pfad eine DLL von einem entfernten Server zu laden. Die DLL werde als Teil der Control-Panel-Objekte (CPL) geladen, ohne dass die Netzwerkzone ordnungsgemäß geprüft werde.
Die Analyse der im Februar verteilten Patches ergab, dass zwar der Weg zur Codeausführung durch eine SmartScreen-Prüfung der digitalen Signatur und der Herkunftszone unterbunden wurde – das Opfersystem sich jedoch weiterhin beim Server des Angreifers authentifizierte. Das Problem ist laut Akamai, dass die Vertrauensprüfung erst am Ende der Aufrufkette greift und eine frühere Stufe verpasst.
Beim Darstellen des Ordnerinhalts mit der bösartigen LNK-Datei fordert der Windows Explorer über shell32 ein Symbol von einem UNC-Pfad an und löst so ohne Nutzerinteraktion eine SMB-Verbindung zum Server des Angreifers aus. Diese Verbindung stößt laut Akamai einen automatischen NTLM-Authentifizierungs-Handshake an, bei dem der Net-NTLMv2-Hash des Opfers an den Angreifer übermittelt wird. Dieser lässt sich später für NTLM-Relay-Angriffe und das Offline-Knacken des Passworts verwenden.