Huntress’in incelemesine göre, Oracle veritabanı içine derlenen khunt adlı araç seti, 27 Temmuz 2026’da tetiklenen kimlik bilgisi hırsızlığı uyarılarının ardından ortaya çıktı ve saldırı zincirinin sonunda alttaki Windows sunucuda SYSTEM seviyesinde kod çalıştırmaya kadar ilerledi.
Saldırı, bir Oracle uygulamasındaki otomatik tamamlama arama alanının doğrulanmamış girdiyi JDBC bağlantısı üzerinden veritabanına iletmesiyle başladı. Bu bağlantının kullandığı hesap, Java nesneleri oluşturabilecek kadar ayrıcalığa sahipti. Oracle tarafında bu zafiyeti ya da hesabın aşırı yetkisini kapatan bir yama bulunmuyor; Huntress, izi sürmek isteyen ekiplerin Oracle kurulumunda adı Khunt ile başlayan nesnelere ve SQL günlüklerinde KHUNT% kalıbına bakması gerektiğini belirtiyor.
Veritabanı içinde derlenen Java kodu
Huntress’in vurguladığı nokta, bu tekniğin klasik bir kötü amaçlı dosya gibi davranmaması. Veritabanına derlenen Java sınıfı, disk üzerinde çalışan bir ikili dosya ya da endpoint ürünlerinin kolayca taradığı bir süreç değil; Oracle’ın iç yapısında yaşayan bir şema nesnesi. Bu yüzden saldırganlar, veritabanını sorgulanan bir sistem olmaktan çıkarıp üzerinde hareket ettikleri bir ilk erişim noktasına dönüştürüyor.
Oracle, gömülü bir Java sanal makinesiyle geliyor. CREATE JAVA SOURCE komutu, kullanıcının Java kodu vermesine ve veritabanının bunu derleyip şema nesnesi olarak saklamasına izin veriyor. Kullanıcının kendi şemasında bu işlem için Oracle dokümantasyonu yalnızca CREATE PROCEDURE sistem ayrıcalığını yeterli görüyor. Koddan işletim sistemi süreci başlatmak ise Runtime.exec üzerinden gerçekleşiyor; bunun için ayrıca dosya çalıştırma izni gerekiyor ve Oracle, bu izinlerin yalnızca ayrıcalıklı yöneticiler tarafından verildiğini söylüyor.
Khunt araç seti ne yaptı
Huntress, ele geçirilen hesabın hangi yetkilere sahip olduğunu ya da saldırganların sonradan ek bir izin alıp almadığını açıklamadı. Ancak saldırı zinciri başarıya ulaştığı için, hesabın hem Java nesnesi oluşturmak hem de süreç başlatmak için yeterli yetkiye sahip olduğu anlaşılıyor.
Analizde yer alan araç seti altı Java nesnesi ve birkaç khunt_* PL/SQL sarmalayıcısından oluşuyor. KhuntCmd, cmd.exe yükleyip SQL üzerinden verilen işletim sistemi komutlarını çalıştırdı. KhuntHash, Oracle’ın dahili kullanıcı tablosundan kullanıcı adlarını ve parola karmalarını okuyup bir dosyaya yazdı. KhuntFS ve KhuntFS2, dosya listeleme, okuma, arama ve boyut alma işlevleri sundu. KhuntT araç setinin erişilebilir olduğunu doğrularken, KhuntUnzip arşivleri açtı.
Bir denemede cmd.exe /c whoami komutu SYSTEM yanıtı döndürdü. Ardından saldırganlar PowerShell ve reg.exe kullanarak SECURITY ve SYSTEM kayıt defteri kovanlarını F:\Oracle dizinine kopyaladı. Aynı süreçte tasklist /svc çıktısını khunttasks.txt dosyasına yazdırdılar ve esentutl.exe ile SAM ve SECURITY kovanlarının kopyalarını aldılar.
Huntress, dosyaların yerel olarak sahneye alındığını gördüğünü, ancak dışarı aktarılıp aktarılmadığını doğrulayamadığını aktardı. Şirket herhangi bir tehdit aktörü ismi paylaşmadı; kötü niyetli istekleri 178.162.151[.]229 adresine bağladı.
Teknik, yeni değil. Marco Ivaldi’nin raptor_oraexec.sql adlı çalışması 2006 tarihini taşıyor ve komut çalıştırma ile dosya okuma yöntemleri içeren bir Oracle kaynak nesnesi oluşturup bunları PL/SQL sarmalayıcılarıyla SQL’e açıyor. Huntress, khunt nesnelerinin de aynı temel mimariyi kullandığını, ancak bu tekniğin gerçek dünyada kullanımının çok nadir belgelenebildiğini belirtti.
İncelemede işaret edilen zafiyet için Oracle tarafında kapatma yaması yok. Erişim zincirini kıran asıl noktalar, uygulama katmanında parametreli sorgular ve girdi doğrulama ile veritabanı tarafında ise en az ayrıcalık ilkesi. Huntress’in tarif ettiği senaryoda, halka açık bir uygulamayı taşıyan hesapların Java kaynağı yazabilmesi ya da gerekmediği halde saklı yordamlar çalıştırabilmesi için hiçbir neden yok.