DLL proxy loading merupakan teknik yang sudah dikenal luas dalam komunitas offensive security — yaitu menggantikan fungsi-fungsi dari DLL legitimate dengan versi yang sudah dimodifikasi untuk menyuntikkan kode tambahan saat library dimuat oleh aplikasi target. Namun, sebuah proyek research terbaru bernama Proxy-DLL-Loads oleh kleiton0x00 membawa teknik ini ke level yang sama sekali baru dengan mendemonstrasikan cara-cara alternatif untuk memicu DLL load melalui undocumented syscall dan Vectored Exception Handler (VEH), menghindari mekanisme hooking dan callstack detection yang selama ini menjadi andalan produk keamanan. Proyek ini, yang sudah mendapat 409 stars dan 57 forks di GitHub, bukan sekadar tutorial DLL proxy loading — ini adalah deep dive teknis ke berbagai primitive Windows yang bisa disalahgunakan untuk menjalankan code secara stealthy.
Metode pertama yang didemonstrasikan oleh Proxy-DLL-Loads menggunakan VEH (Vectored Exception Handler) untuk mengubah execution context saat terjadi exception. Dalam pendekatan ini, attacker memanfaatkan VEH untuk memodifikasi register instruction pointer (RIP) agar menunjuk ke fungsi LoadLibraryA, serta register RCX untuk menahan argument berupa nama module yang akan dimuat. Untuk memicu exception, VirtualProtect digunakan untuk mengatur halaman memori target ke proteksi PAGE_GUARD, yang memicu exception STATUS_GUARD_PAGE_VIOLATION. VEH handler kemudian menangkap exception ini, memodifikasi execution context, dan mengembalikan kontrol ke LoadLibraryA dengan argument yang sudah ditentukan.
Yang membuat pendekatan VEH ini sangat menarik dari sudut pandang evasion adalah bahwa LoadLibraryA tidak dipanggil secara langsung dari kode attacker — ia dipanggil sebagai hasil dari modifikasi execution context yang terjadi di luar alur kontrol normal. Banyak produk EDR mem-hook fungsi LoadLibraryA dan memantau caller stack untuk menentukan apakah pemanggilan tersebut legitimate atau mencurigakan. Dengan pendekatan VEH, caller stack akan menunjukkan alamat dari VEH handler, bukan dari kode attacker, sehingga analisis callstack menjadi jauh lebih sulit dan membingungkan bagi security analyst. Teknik ini secara efektif memanfaatkan mekanisme Windows yang sah untuk melakukan sesuatu yang tidak sah.
Metode kedua yang dijelaskan dalam proyek ini menggunakan Tp* (Thread Pool) functions — sekumpulan undocumented functions di ntdll.dll yang mengontrol thread pool Windows. Penulis menjelaskan proses hunting untuk menemukan fungsi-fungsi ini dengan memulai dari Win32 API yang sudah didokumentasi oleh Microsoft (seperti CreateThreadpool, SetThreadpoolTimer), lalu melakukan reverse engineering pada kernel32.dll untuk menemukan underlying undocumented functions yang dipanggilnya. Hasilnya adalah daftar fungsi ntdll yang mencakup TpAllocPool, TpSetPoolMaxThreads, TpSetPoolMinThreads, TpAllocCleanupGroup, TpAllocTimer, TpSetTimer, dan TpReleaseCleanupGroupMembers.
Fungsi-fungsi Tp* ini sangat powerful untuk tujuan evasion karena mereka beroperasi pada level ntdll yang lebih rendah dan menggunakan callback-based execution yang sulit dipantau oleh EDR. Dalam implementasi Proxy-DLL-Loads, fungsi TpAllocTimer dan TpAllocWait digunakan untuk membuat callback objects yang, ketika dipicu, akan mengeksekusi LoadLibraryA dengan nama module sebagai argument. Karena eksekusi terjadi melalui callback thread pool yang merupakan mekanisme Windows yang sah, callstack yang dihasilkan akan menunjukkan thread pool infrastructure alih-alih kode attacker — sebuah mimpi buruk bagi analisis forensik.
Metode ketiga dan paling canggih menggabungkan Tp* functions dengan call gadget yang diambil dari AuthenticateFAM_SecureFP.dll — sebuah DLL legitimate milik Windows. Gadget yang digunakan terdiri dari instruction call rax yang diikuti oleh cleanup instructions dan ret. Dengan menempatkan gadget ini dalam call stack saat module load, Proxy-DLL-Loads secara efektif memecahkan Elastic callstack detection rule — sebuah rule deteksi populer yang memeriksa pola call stack untuk mendeteksi DLL loading yang tidak normal. Penggunaan gadget dari DLL yang sudah terdaftar sebagai module Windows membuat call stack terlihat seperti pemanggilan fungsi yang sah dari AuthenticateFAM_SecureFP.dll.
Aspek OPSEC yang diperhatikan dalam proyek ini juga layak mendapat apresiasi. Penulis secara eksplisit merekomendasikan untuk tidak menggunakan VirtualProtect dalam implementasi produksi karena fungsi ini sudah sangat dipantau oleh EDR. Sebagai gantinya, alternatif yang lebih OPSEC-friendly harus dicari untuk memicu PAGE_GUARD violation. Selain itu, custom implementation dari GetModuleHandleA dan GetProcAddress direkomendasikan alih-alih menggunakan versi standard, untuk menghindari hook yang dipasang pada fungsi-fungsi ini oleh security products. Rekomendasi-rekomendasi ini menunjukkan bahwa Proxy-DLL-Loads dirancang bukan untuk proof-of-concept semata, melainkan untuk penggunaan operasional yang memerlukan OPSEC tinggi.
Yang menarik dari perspektif deteksi, Elastic sendiri sudah merilis rule behavior bernama “Library loaded via a callback function” yang secara spesifik menarget teknik DLL loading melalui callback — termasuk yang menggunakan VEH dan Tp* functions. Rule ini tersedia di repository elastic/protections-artifacts di GitHub. Namun, efektivitas rule ini bergantung pada kemampuan EDR untuk memonitor seluruh thread pool callback execution di sistem — sebuah tantangan yang sangat besar mengingat betapa seringnya Windows menggunakan thread pool untuk operasi internalnya. False positive rate dari rule seperti ini juga bisa menjadi masalah serius di lingkungan production yang menjalankan banyak aplikasi Java atau .NET yang secara natural menggunakan thread pool secara intensif.
Dampak dari penelitian Proxy-DLL-Loads terhadap komunitas keamanan sangat signifikan. Proyek ini membuktikan bahwa ada banyak cara untuk memicu DLL load yang tidak terpantau oleh mekanisme deteksi konvensional — dan setiap kali sebuah teknik baru dipublikasikan, produk keamanan harus mengejar untuk menambahkan rule deteksi baru. Namun, seperti yang ditunjukkan oleh use of call gadget untuk memecahkan Elastic rule, arms race antara attacker dan defender tidak pernah berakhir. Setiap rule baru akan menghasilkan teknik bypass baru, dan siklus ini akan terus berlanjut selama arsitektur keamanan Windows masih mengandalkan hooking pada level user-mode.
Analisa Retasan
Proxy-DLL-Loads adalah contoh sempurna dari bagaimana penelitian offensive security yang berkualitas tinggi bisa mengungkap kelemahan fundamental dalam arsitektur keamanan. Tiga teknik yang didemonstrasikan — VEH-based loading, Tp* callback loading, dan gadget-based loading — masing-masing menyerang aspek berbeda dari chain deteksi. VEH menyerang caller stack analysis, Tp* menyerang process monitoring, dan gadget menyerang callstack signatures. Kombinasi ketiganya menunjukkan bahwa pertahanan yang hanya fokus pada satu aspek akan selalu memiliki celah.
Bagi tim keamanan di Indonesia, proyek ini menjadi pengingat bahwa DLL monitoring harus dilakukan secara lebih holistik daripada sekadar memantau
LoadLibraryAdanLoadLibraryW. EDR harus mampu memantau seluruh primitive yang bisa digunakan untuk memuat library — termasukLdrLoadDlldintdll, thread pool callbacks, dan bahkan VEH-based execution. Yang lebih penting lagi, logging harus mencakup konteks yang memadai untuk membedakan antara pemanggilan yang legitimate dan yang malicious — sebuah tantangan yang memerlukan investasi signifikan dalam infrastructure logging dan analytics.
Sumber: GitHub – kleiton0x00/Proxy-DLL-Loads | Stars: 409 | Forks: 57 | Bahasa: C 72%, C++ 21.9%, Assembly 6.1% | License: MIT
