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 merinci pendekatan baru untuk menyalahgunakan Teknologi COM (DCOM) di mana objek COM yang terperangkap dapat digunakan untuk mengeksekusi kode terkelola .NET dalam konteks proses DCOM sisi server. Forshaw menyoroti beberapa contoh penggunaan untuk eskalasi hak istimewa dan bypass Protected Process Light (PPL).

Berdasarkan riset Forshaw, Mohamed Fakroud(@T3nb3w) mempublikasikan implementasi teknik untuk mem-bypass 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 bukti konsep tanpa file dengan menyalahgunakan objek COM yang terperangkap.

COM adalah standar antarmuka biner dan tingkat layanan middleware yang memungkinkan paparan komponen modular yang 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, memungkinkan pengembang untuk mengintegrasikan beragam modul perangkat lunak secara efektif. DCOM adalah teknologi jarak jauh yang memungkinkan klien COM berkomunikasi dengan server COM melalui komunikasi antar proses (IPC) atau panggilan prosedur jarak jauh (RPC). Banyak layanan Windows menerapkan komponen DCOM yang dapat diakses secara lokal atau jarak jauh.

Kelas COM biasanya terdaftar dan terkandung dalam Windows Registry. Program klien berinteraksi dengan server COM dengan membuat instance kelas COM, yang dikenal sebagai objek COM. Objek ini menyediakan pointer ke antarmuka standar. Klien menggunakan pointer 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 instance kelas COM di server DCOM di luar proses, di mana klien mengontrol objek COM melalui pointer objek yang disusun berdasarkan referensi. Bergantung pada kondisinya, vektor kontrol ini dapat menghadirkan kelemahan logika terkait keamanan.

Blog Forshaw menjelaskan contoh penggunaan bypass PPL di mana antarmuka IDispatch, seperti yang diekspos di kelas WaaSRemediation COM, 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 kami dan pengembangan teknik gerakan lateral tanpa file bukti konsep.

Perjalanan riset kami dimulai dengan menjelajahi kelas WaaSRemediation COM yang mendukung antarmuka IDispatch. Antarmuka ini memungkinkan klien untuk melakukan pengikatan akhir. Biasanya, klien COM memiliki antarmuka dan definisi tipe untuk objek yang mereka gunakan didefinisikan pada waktu kompilasi. Sebaliknya, pengikatan terlambat memungkinkan klien untuk menemukan dan memanggil metode pada objek pada waktu proses. IDispatch menyertakan metode GetTypeInfo , yang mengembalikan 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 COM Hijacking pada objek StdFont melalui memodifikasi TreatAs registry key, kelas akan menunjuk ke kelas COM lain yang kita pilih, seperti System.Object di kerangka kerja .NET. Sebagai catatan, Forshaw menunjukkan bahwa StdPicture tidak dapat digunakan karena objek ini melakukan pemeriksaan untuk instantiasi di luar proses, jadi kami tetap fokus menggunakan StdFont.

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

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

• AllowDCOMReflection: Seperti yang dicatat oleh Forshaw, nilai yang diaktifkan ini memungkinkan kita untuk melakukan refleksi sewenang-wenang untuk memanggil metode .NET apa pun. Biasanya, Refleksi.NET melalui DCOM dicegah karena mitigasi yang dibahas dalam MS14-009.
• OnlyUseLatestCLR: Menggunakan Procmon, ami menemukan 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, kami tahu kami berada di jalur yang benar.

Mengalihkan perhatian kami untuk fokus pada aspek pemrograman jarak jauh, pertama-tama kami menggunakan Remote Registry untuk memanipulasi nilai kunci registri .NetFramework dan membajak objek StdFont pada mesin target. Selanjutnya, kami menukar CoCreateInstance dengan CoCreateInstanceEx untuk membuat instance objek COM WaaSRemediation pada target jarak jauh dan mendapatkan penunjuk ke antarmuka IDispatch .

Dengan sebuah penunjuk ke IDispatch, kita memanggil metode anggota GetTypeInfo untuk mendapatkan penunjuk ke antarmuka ITypeInfo, yang terperangkap di server. Metode anggota yang disebut setelahnya terjadi di sisi server. Setelah mengidentifikasi referensi pustaka tipe yang terkandung yang diminati (stdole) dan memperoleh referensi objek kelas berikutnya yang diminati (StdFont), kami akhirnya menggunakan metodeCreateInstance yang “dapat dipindahkan” pada antarmuka ITypeInfo untuk mengarahkan ulang aliran tautan objek StdFont (melalui manipulasi TreatAs sebelumnya) untuk membuat instance System.Object.

Karena AllowdComReflection diatur dengan benar, kita kemudian dapat melakukan refleksi.NET melalui DCOM untuk mengakses Assembly.Load untuk memuat rakitan .NET ke server COM. Karena kami menggunakan Assembly.Load melalui DCOM, teknik gerakan lateral ini sama sekali tidak berfile karena transfer byte perakitan ditangani oleh sihir remoting DCOM. Untuk penjelasan mendalam tentang aliran teknis ini dari instansiasi objek ke refleksi, silakan 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 byte dalam SAFEARRAY VARIANTs lainnya – awalnya, kami terus mencoba meneruskan satu SAFEARRAY byte.

Masalah lain adalah menemukan kelebihan beban Assembly.Load yang tepat. Fungsi-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.Lo ad memiliki dua kelebihan beban statis yang mengambil satu argumen; dengan demikian, kami akhirnya menggunakan solusi hacky. Kami melihat contoh ketiga dari Load dengan argumen tunggal adalah pilihan yang tepat.

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

Dalam keadaan saat ini, ForsHops.exe berjalan sampai beacon keluar, di mana ia menghapus operasi registri. 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 untuk teknik gerakan lateral ini:

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

Selanjutnya, kami merekomendasikan 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, gunakan aturan YARA bukti konsep berikut untuk mendeteksi standar yang dapat dieksekusi ForsHops.exe:

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 daripada eksekusi lokal untuk bypass 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 memberikan masukan tentang riset ini dan memberikan ulasan konten postingan blog.

• Blog “Kelas Bug Windows: Mengakses Objek COM yang Terperangkap dengan IDispatch“ oleh James Forshaw: https://googleprojectzero.blogspot.com/2025/01/windows-bug-class-accessing-trapped-com.html
• Blog “Menyalahgunakan IDispatch untuk Akses Objek COM yang Terjebak & Menyuntikkan ke dalam Proses PPL“ oleh Mohamed Fakroud: https://mohamed-fakroud.gitbook.io/red-teamings-dojo/abusing-idispatch-for-trapped-com-object-access-and-injecting-into-ppl-processes
• Blog “Menyalahgunakan Struktur Registri COM (Bagian 2): Teknik Pembajakan & Memuat“ oleh Jimmy Bayne: https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/
• Bukti konsep CVE-2014-0257 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