Pendekatan ini memungkinkan toolkit lolos dari deteksi alat Endpoint Detection and Response (EDR) dan antivirus tradisional, karena alat-alat tersebut tidak memeriksa objek database . Dari sana, penyerang beralih ke sistem operasi Windows di bawahnya, mendapatkan akses Remote Code Execution (RCE) level SYSTEM, mengekstrak registry hive yang berisi hash password, dan mengeksfiltrasinya secara offline . Infrastruktur penyerang dilacak ke IP 178.162.151[.]229 .

Bagaimana Serangan Bekerja: SQL Injection Melalui Pencarian Otomatis

Vektor akses awal adalah kerentanan SQL injection pada aplikasi Java yang berjalan di Apache Tomcat . Fitur pencarian otomatis (autocomplete search) pada aplikasi gagal memvalidasi masukan pengguna dengan benar, memungkinkan penyerang menyuntikkan perintah SQL melalui koneksi JDBC ke database Oracle . Seperti dicatat oleh peneliti Huntress, ini bukan kelas kerentanan baru—serangan SQL injection telah ada selama beberapa dekade dan biasanya akibat dari kesalahan penanganan masukan pengguna ke server SQL .

Toolkit Khunt: Hidup di Dalam Database sebagai Objek Java

Daripada menggunakan file malware tradisional, penyerang memanfaatkan JVM bawaan Oracle dan pernyataan CREATE JAVA SOURCE untuk mengkompilasi dan menyimpan seluruh toolkit post-eksploitasi sebagai objek skema Java di dalam database . Pendekatan ini membuat toolkit tidak terlihat oleh pertahanan tingkat OS, karena EDR dan antivirus berfokus pada proses, binary, dan file di sistem operasi—mereka tidak memeriksa kelas Java dan wrapper PL/SQL yang disimpan di dalam Oracle .

Toolkit khunt mencakup komponen-komponen berikut, masing-masing disimpan sebagai objek database:

Mendapatkan Kontrol Penuh Sistem: Dari Database ke Windows OS

Penyerang tidak berhenti di akses tingkat database. Mereka menggunakan toolkit khunt untuk beralih dari lapisan database ke sistem operasi Windows yang mendasarinya dalam proses multi-langkah:

1. Eksekusi perintah OS via KhuntCmd: Menggunakan modul KhuntCmd untuk menjalankan cmd.exe /c whoami, yang mengonfirmasi bahwa mereka berjalan dengan hak istimewa SYSTEM di server Windows, membangun RCE dari database ke OS .
2. Pencurian kredensial: Menggunakan PowerShell untuk memanggil reg.exe dan menyalin registry hive SECURITY dan SYSTEM, menyimpannya sebagai khuntSECURITY.hiv dan khuntSYSTEM.hiv di F:\Oracle\ .
3. Enumerasi layanan: Menjalankan tasklist /svc dan menyimpan output sebagai khunttasks.txt .
4. Ekstraksi hive tambahan: Menggunakan esentutl.exe untuk menyalin SAM dan salinan kedua hive SECURITY, menyimpannya sebagai khuntSAM.hiv dan khunt_SECURITY.hiv .

Registry hive yang dieksfiltrasi dapat digunakan secara offline untuk mengekstrak dan mendekode hash password untuk semua akun lokal di sistem .

Titik Buta Pertahanan: Temuan Kunci Huntress

Investigasi Huntress mengungkap beberapa titik buta kritis yang memungkinkan serangan ini berhasil dan lolos dari deteksi:

• Database sebagai beachhead: Database diubah dari penyimpanan data pasif menjadi platform serangan aktif, dengan toolkit berbahaya hidup di dalam database, bukan di disk atau memori .
• Penghindaran EDR/AV: Alat EDR dan antivirus tradisional tidak memeriksa kelas Java dan wrapper PL/SQL yang disimpan di dalam Oracle, membuat toolkit tidak terlihat oleh pertahanan standar OS .
• Kerentanan klasik, pengiriman baru: SQL injection awal adalah kelas bug yang terkenal. Tidak diperlukan zero-day. Fitur pencarian otomatis sudah cukup untuk mencapai PL/SQL dan kemudian OS, menunjukkan bahwa kegagalan validasi input dasar dapat menyebabkan kompromi yang dalam ketika mesin database memiliki kemampuan tingkat OS .
• Akun database dengan hak berlebihan: Bahkan setelah SQL injection berhasil, kerusakan dapat dibatasi jika akun pengguna database tidak memiliki hak istimewa untuk membuat sumber Java atau menjalankan prosedur tersimpan. Organisasi sering kali memberikan hak berlebihan pada akun database, memberi penyerang izin tambahan yang diperlukan untuk menyebarkan khunt .

Mitigasi yang Direkomendasikan oleh Huntress

Berdasarkan serangan ini, Huntress merekomendasikan beberapa mitigasi :

• Sanitasi input yang tepat dan parameterisasi kueri untuk semua input web
• Membatasi hak istimewa pengguna database sehingga kueri yang disuntikkan pun tidak dapat membuat sumber Java atau menjalankan prosedur tersimpan arbitrer
• Memperluas cakupan pemantauan untuk mencakup objek database (kelas Java, wrapper PL/SQL) daripada hanya artefak tingkat OS

Serangan ini menjadi pengingat bahwa mesin database dengan lingkungan pemrograman bawaan (seperti JVM Oracle) dapat berubah menjadi platform serangan yang senyap ketika dikombinasikan dengan satu bidang input yang tidak divalidasi. Tim keamanan harus memperluas pemantauan mereka melampaui sistem operasi hingga menyertakan lapisan objek database.

Pendekatan ini memungkinkan toolkit lolos dari deteksi alat Endpoint Detection and Response (EDR) dan antivirus tradisional, karena alat-alat tersebut tidak memeriksa objek database . Dari sana, penyerang beralih ke sistem operasi Windows di bawahnya, mendapatkan akses Remote Code Execution (RCE) level SYSTEM, mengekstrak registry hive yang berisi hash password, dan mengeksfiltrasinya secara offline . Infrastruktur penyerang dilacak ke IP 178.162.151[.]229 .

Bagaimana Serangan Bekerja: SQL Injection Melalui Pencarian Otomatis

Vektor akses awal adalah kerentanan SQL injection pada aplikasi Java yang berjalan di Apache Tomcat . Fitur pencarian otomatis (autocomplete search) pada aplikasi gagal memvalidasi masukan pengguna dengan benar, memungkinkan penyerang menyuntikkan perintah SQL melalui koneksi JDBC ke database Oracle . Seperti dicatat oleh peneliti Huntress, ini bukan kelas kerentanan baru—serangan SQL injection telah ada selama beberapa dekade dan biasanya akibat dari kesalahan penanganan masukan pengguna ke server SQL .

Toolkit Khunt: Hidup di Dalam Database sebagai Objek Java

Daripada menggunakan file malware tradisional, penyerang memanfaatkan JVM bawaan Oracle dan pernyataan CREATE JAVA SOURCE untuk mengkompilasi dan menyimpan seluruh toolkit post-eksploitasi sebagai objek skema Java di dalam database . Pendekatan ini membuat toolkit tidak terlihat oleh pertahanan tingkat OS, karena EDR dan antivirus berfokus pada proses, binary, dan file di sistem operasi—mereka tidak memeriksa kelas Java dan wrapper PL/SQL yang disimpan di dalam Oracle .

Toolkit khunt mencakup komponen-komponen berikut, masing-masing disimpan sebagai objek database:

Mendapatkan Kontrol Penuh Sistem: Dari Database ke Windows OS

Penyerang tidak berhenti di akses tingkat database. Mereka menggunakan toolkit khunt untuk beralih dari lapisan database ke sistem operasi Windows yang mendasarinya dalam proses multi-langkah:

1. Eksekusi perintah OS via KhuntCmd: Menggunakan modul KhuntCmd untuk menjalankan cmd.exe /c whoami, yang mengonfirmasi bahwa mereka berjalan dengan hak istimewa SYSTEM di server Windows, membangun RCE dari database ke OS .
2. Pencurian kredensial: Menggunakan PowerShell untuk memanggil reg.exe dan menyalin registry hive SECURITY dan SYSTEM, menyimpannya sebagai khuntSECURITY.hiv dan khuntSYSTEM.hiv di F:\Oracle\ .
3. Enumerasi layanan: Menjalankan tasklist /svc dan menyimpan output sebagai khunttasks.txt .
4. Ekstraksi hive tambahan: Menggunakan esentutl.exe untuk menyalin SAM dan salinan kedua hive SECURITY, menyimpannya sebagai khuntSAM.hiv dan khunt_SECURITY.hiv .

Registry hive yang dieksfiltrasi dapat digunakan secara offline untuk mengekstrak dan mendekode hash password untuk semua akun lokal di sistem .

Titik Buta Pertahanan: Temuan Kunci Huntress

Investigasi Huntress mengungkap beberapa titik buta kritis yang memungkinkan serangan ini berhasil dan lolos dari deteksi:

• Database sebagai beachhead: Database diubah dari penyimpanan data pasif menjadi platform serangan aktif, dengan toolkit berbahaya hidup di dalam database, bukan di disk atau memori .
• Penghindaran EDR/AV: Alat EDR dan antivirus tradisional tidak memeriksa kelas Java dan wrapper PL/SQL yang disimpan di dalam Oracle, membuat toolkit tidak terlihat oleh pertahanan standar OS .
• Kerentanan klasik, pengiriman baru: SQL injection awal adalah kelas bug yang terkenal. Tidak diperlukan zero-day. Fitur pencarian otomatis sudah cukup untuk mencapai PL/SQL dan kemudian OS, menunjukkan bahwa kegagalan validasi input dasar dapat menyebabkan kompromi yang dalam ketika mesin database memiliki kemampuan tingkat OS .
• Akun database dengan hak berlebihan: Bahkan setelah SQL injection berhasil, kerusakan dapat dibatasi jika akun pengguna database tidak memiliki hak istimewa untuk membuat sumber Java atau menjalankan prosedur tersimpan. Organisasi sering kali memberikan hak berlebihan pada akun database, memberi penyerang izin tambahan yang diperlukan untuk menyebarkan khunt .

Mitigasi yang Direkomendasikan oleh Huntress

Berdasarkan serangan ini, Huntress merekomendasikan beberapa mitigasi :

• Sanitasi input yang tepat dan parameterisasi kueri untuk semua input web
• Membatasi hak istimewa pengguna database sehingga kueri yang disuntikkan pun tidak dapat membuat sumber Java atau menjalankan prosedur tersimpan arbitrer
• Memperluas cakupan pemantauan untuk mencakup objek database (kelas Java, wrapper PL/SQL) daripada hanya artefak tingkat OS

Serangan ini menjadi pengingat bahwa mesin database dengan lingkungan pemrograman bawaan (seperti JVM Oracle) dapat berubah menjadi platform serangan yang senyap ketika dikombinasikan dengan satu bidang input yang tidak divalidasi. Tim keamanan harus memperluas pemantauan mereka melampaui sistem operasi hingga menyertakan lapisan objek database.