Gerakan lateral tanpa file dengan objek COM yang terperangkap

Component Object Model (COM) telah menjadi landasan pengembangan Microsoft Windows sejak awal 1990-an dan masih sangat lazim ditemui dalam sistem operasi dan aplikasi Windows modern. Ketergantungan pada komponen COM dan pengembangan fitur yang ekstensif selama bertahun-tahun telah menciptakan permukaan serangan yang besar. Pada Februari 2025, James Forshaw (@tiraniddo) dari Google Project Zero merilis postingan blog yang memerinci pendekatan baru untuk menyalahgunakan teknologi COM Terdistribusi (DCOM) dari jarak jauh di mana objek COM yang terperangkap dapat digunakan untuk mengeksekusi kode terkelola .NET dalam konteks proses DCOM dari sisi server. Forshaw menyoroti beberapa contoh penggunaan untuk eskalasi hak istimewa dan melewati Protected Process Light (PPL).

Berdasarkan riset Forshaw, Mohamed Fakroud(@T3nb3w) memublikasikan implementasi teknik untuk melewati perlindungan PPL pada awal Maret 2025. Jimmy Bayne (@bohops) dan saya melakukan riset serupa pada Februari 2025 yang telah mengarahkan kami untuk mengembangkan teknik gerakan lateral tanpa file bukti konsep dengan menyalahgunakan objek COM yang terperangkap.

COM adalah standar antarmuka biner dan tingkat layanan middleware yang memungkinkan paparan komponen modular berbeda untuk berinteraksi satu sama lain dan dengan aplikasi, terlepas dari bahasa pemrograman yang mendasarinya. Misalnya, objek COM yang dikembangkan dalam C++ dapat dengan mudah berinteraksi dengan aplikasi .NET, sehingga pengembang dapat mengintegrasikan beragam modul perangkat lunak secara efektif. DCOM adalah teknologi jarak jauh yang memungkinkan klien COM berkomunikasi dengan server COM melalui komunikasi antarproses (IPC) atau panggilan prosedur jarak jauh (RPC). Banyak layanan Windows menerapkan komponen DCOM yang dapat diakses setempat atau dari jarak jauh.

Kelas COM biasanya terdaftar dan termasuk dalam Windows Registry. Program klien berinteraksi dengan server COM dengan membuat instans kelas COM yang dikenal sebagai objek COM. Objek ini menyediakan penunjuk ke antarmuka standar. Klien menggunakan penunjuk ini untuk mengakses metode dan properti objek, memfasilitasi komunikasi dan fungsionalitas antara klien dan server.

Objek COM sering menjadi target riset untuk menilai paparan kerentanan dan menemukan fitur yang dapat disalahgunakan. Objek COM yang terperangkap adalah kelas bug di mana klien COM membuat instans kelas COM di server DCOM di luar proses, di mana klien mengontrol objek COM melalui penunjuk objek yang disusun berdasarkan referensi. Tergantung pada kondisinya, vektor kontrol ini dapat menghadirkan kelemahan logika terkait keamanan.

Blog Forshaw menguraikan contoh penggunaan melewatkan PPL di mana antarmuka IDispatch, seperti yang diekspos di kelas COM WaaSRemediation, dimanipulasi untuk penyalahgunaan objek COM yang terperangkap dan eksekusi kode .NET. WaaSRemediation diimplementasikan dalam layanan WaaSMedicSvc, yang dijalankan sebagai proses svchost.exe yang dilindungi dalam konteks NT AUTHORITY\SYSTEM. Panduan Forshaw yang sangat baik adalah dasar untuk riset terapan kami dan pengembangan teknik gerakan lateral tanpa file bukti konsep.

Perjalanan riset kami dimulai dengan menjelajahi kelas COM WaaSRemediation yang mendukung antarmuka IDispatch. Antarmuka ini memungkinkan klien untuk melakukan pengikatan akhir. Biasanya, klien COM menetapkan antarmuka dan definisi tipe untuk objek yang mereka gunakan pada waktu kompilasi. Sebaliknya, pengikatan terlambat memungkinkan klien untuk menemukan dan memanggil metode pada objek pada waktu proses. IDispatch menyertakan metode GetTypeInfo yang menampilkan antarmuka ITypeInfo. ITypeInfo memiliki metode yang dapat digunakan untuk menemukan informasi tipe untuk objek yang mengimplementasikannya.

Jika kelas COM menggunakan pustaka tipe, itu dapat ditanyakan oleh klien melalui ITypeLib (diperoleh dari ITypeInfo->GetContainingTypeLib) untuk mengambil informasi tipe. Selain itu, pustaka tipe juga dapat merujuk pustaka tipe lain untuk informasi tipe tambahan.

Menurut postingan blog Forshaw, WaaSRemediation mereferensikan pustaka tipe WaaSRemediationLib, yang pada gilirannya mereferensikan stdole (Otomatisasi OLE). WaaSRemediationLib menggunakan dua kelas COM dari pustaka tersebut, StdFont dan StdPicture. Dengan melakukan Pembajakan COM pada objek StdFont dengan memodifikasi kunci registri TreatAs, kelas akan menunjuk ke kelas COM lain pilihan kita, seperti System.Object di. NET Framework. Sebagai catatan, Forshaw menunjukkan bahwa StdPicture tidak dapat digunakan karena objek ini melakukan pemeriksaan untuk pembuatan instans di luar proses, jadi kami berfokus untuk menggunakan StdFont.

Objek .NET menarik bagi kami karena metode GetType dari System.Object. Melalui GetType, kita dapat melakukan refleksi .NET untuk mengakses Assembly.Load pada akhirnya. Sementara System.Object dipilih, tipe ini kebetulan menjadi akar dari hierarki tipe di.NET. Oleh karena itu, objek .NET COM apa pun dapat digunakan.

Setelah mengatur tahap awal, ada dua nilai DWORD lain di bawah kunci HKLM\Software\Microsoft\.NetFramework yang diperlukan untuk membuat contoh penggunaan yang kami pahami menjadi kenyataan:

• AllowDCOMReflection: Seperti yang dicatat oleh Forshaw, nilai yang diaktifkan ini memungkinkan kami untuk melakukan refleksi acak untuk memanggil metode .NET apa pun. Biasanya, Refleksi .NET melalui DCOM dicegah karena mitigasi yang dibahas dalam MS14-009.
• OnlyUseLatestCLR: Dengan menggunakan Procmon, kami menemukan bahwa nilai ini harus diaktifkan untuk memuat versi terbaru .NET CLR (versi 4), jika tidak, versi 2 akan dimuat secara default.

Setelah mengonfirmasi bahwa versi terbaru dari CLR dan .NET dapat dimuat dalam upaya pengujian awal, kami tahu bahwa kami berada di jalur yang benar.

Mengalihkan perhatian kami untuk berfokus pada aspek terprogram jarak jauh, kami menggunakan Remote Registry terlebih dahulu untuk memanipulasi nilai kunci registri .NetFramework dan membajak objek StdFont pada mesin target. Selanjutnya, kami menukar CoCreateInstance dengan CoCreateInstanceEx untuk membuat instans objek COM WaaSRemediation pada target jarak jauh dan mendapatkan penunjuk ke antarmuka IDispatch.

Dengan sebuah penunjuk ke IDispatch, kami memanggil metode anggota GetTypeInfo untuk mendapatkan penunjuk ke antarmuka ITypeInfo yang terperangkap di server. Metode anggota yang dipanggil setelahnya terjadi di sisi server. Setelah mengidentifikasi referensi pustaka tipe yang terkandung yang diinginkan (stdole) dan memperoleh referensi objek kelas berikutnya yang diinginkan (StdFont), kami akhirnya menggunakan metode CreateInstance yang “dapat diakses dari jarak jauh” pada antarmuka ITypeInfo untuk mengarahkan alur tautan objek StdFont (melalui manipulasi TreatAs sebelumnya) untuk membuat instans System.Object.

Karena AllowDCOMReflection diatur dengan benar, kami kemudian dapat melakukan refleksi .NET melalui DCOM untuk mengakses Assembly.Load untuk memuat rakitan .NET ke dalam server COM. Karena kami menggunakan Assembly.Load melalui DCOM, teknik gerakan lateral ini dilakukan tanpa file sama sekali karena transfer byte perakitan ditangani oleh kehebatan akses jarak jauh DCOM. Untuk penjelasan mendalam tentang alur teknis ini dari pembuatan instans objek hingga refleksi, lihat diagram berikut:

Masalah pertama dan utama kami adalah memanggil Assembly.Load_3 melalui IDispatch->Invoke. Invoke meneruskan array objek berisi argumen ke fungsi target dan Load_3 adalah kelebihan beban dari Assembly.Load yang menerima array satu byte. Jadi, kami perlu membungkus SAFEARRAY berisi byte dalam SAFEARRAY lain dari VARIANT – awalnya, kami terus mencoba meneruskan satu SAFEARRAY yang berisi byte.

Masalah lain adalah menemukan kelebihan beban Assembly.Load yang tepat. Fungsi pembantu diambil dari kode CVE-2014-0257 Forshaw, yang mencakup fungsi GetStaticMethod. Fungsi ini menggunakan refleksi .NET melalui DCOM untuk menemukan metode statis yang diberi penunjuk tipe, nama metode, dan jumlah parameternya. Assembly.Load memiliki dua kelebihan beban statis yang mengambil satu argumen; akibatnya, kami akhirnya menggunakan solusi sementara. Kami melihat instans ketiga dari Load dengan argumen tunggal adalah pilihan yang tepat.

Salah satu kelemahan terbesar yang kami amati dengan teknik ini adalah bahwa suar yang dihasilkan akan memiliki masa pakai yang terbatas pada klien COM; dalam hal ini, masa pakai aplikasi biner persenjataan kami “ForsHops.exe” (nama yang sudah pasti elegan). Jadi, jika ForsHops.exe membersihkan referensi COM-nya atau keluar, begitu juga dengan suar yang berjalan di bawah svchost.exe mesin jarak jauh. Kami mencoba solusi yang berbeda, seperti membuat rakitan .NET kami menggantung alur utamanya tanpa batas waktu, menjalankan shellcode di alur lain, dan membuat ForsHops.exe membiarkan alur eksploitasi menggantung, tetapi tidak ada yang efisien.

Dalam keadaan saat ini, ForsHops.exe berjalan sampai suar keluar, di mana ia menghapus operasi registrinya. Ada peluang untuk perbaikan, tetapi kami akan membiarkannya sebagai latihan bagi pembaca.

Panduan deteksi yang diusulkan oleh Samir Bousseaden (@SBousseaden) setelah Mohamed Fakroud menerbitkan implementasinya juga berlaku pada teknik gerakan lateral ini:

• Mendeteksi peristiwa pemuatan CLR dalam proses svchost.exe dari WaaSMedicSvc
• Mendeteksi manipulasi (atau pembuatan) Registry kunci berikut: HKLM\SOFTWARE\Classes\CLSID\{0BE35203-8F91-11CE-9DE3-00AA004BB851}\TreatAs (Kunci TreatAs StandardFont CLSID)

Selanjutnya, kami rekomendasikan untuk menerapkan kontrol tambahan berikut:

• Mendeteksi manipulasi DACL dari HKLM\SOFTWARE\Classes\CLSID\{0BE35203-8F91-11CE-9DE3-00AA004BB851}
• Berburu keberadaan nilai OnlyUseLatestCLR dan AllowDCOMReflection yang diaktifkan di HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
• Mengaktifkan firewall berbasis host untuk membatasi akses port sementara DCOM jika memungkinkan

Selain itu, manfaatkan aturan YARA bukti konsep berikut untuk mendeteksi ForsHops.exe standar yang dapat dieksekusi:

aturan Detect_Standard_ForsHops_PE_By_Hash

Implementasi kami sedikit memperluas penyalahgunaan COM yang dijelaskan di blog Forshaw dengan memanfaatkan objek COM yang terperangkap untuk gerakan lateral alih-alih eksekusi lokal untuk melewati PPL. Oleh karena itu, masih rentan terhadap deteksi yang sama dengan implementasi yang melakukan eksekusi lokal.

Anda dapat menemukan kode gerakan lateral bukti konsep ForsHops.exe di sini.

Terima kasih kepada Dwight Hohnstein (@djhohnstein) dan Sanjiv Kawa (@sanjivkawa) karena telah memberikan masukan tentang riset ini dan memberikan ulasan konten posting blog.

• "Kelas Bug Windows: Mengakses Objek COM yang Terperangkap dengan IDispatch" Blog oleh James Forshaw: https://googleprojectzero.blogspot.com/2025/01/windows-bug-class-accessing-trapped-com.html
• "Menyalahgunakan IDispatch untuk Akses Objek COM yang Terperangkap & Menyuntikkan ke dalam Proses PPL" Blog oleh Mohamed Fakroud: https://mohamed-fakroud.gitbook.io/red-teamings-dojo/abusing-idispatch-for-trapped-com-object-access-and-injecting-into-ppl-processes
• "Menyalahgunakan Struktur Registri COM (Bagian 2): Teknik Pembajakan & Memuat" Blog oleh Jimmy Bayne: https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/
• CVE-2014-0257 bukti konsep oleh James Forshaw: https://github.com/tyranid/IE11SandboxEscapes/blob/master/CVE-2014-0257/CVE-2014-0257.cpp
• Eksekusi .NET dalam deteksi WaasMedicSvc oleh Samir Bousseaden https://x.com/SBousseaden/status/1896527307130724759
• Kode ForsHops oleh Jimmy Bayne dan Dylan Tran: https://github.com/xforcered/ForsHops