Khunt-attacken: När en Oracle-databas blev en osynlig post-exploateringsplattform

Hur attacken gick till: SQL-injektion via en autocomplete-sökning

Den initiala åtkomsten skedde genom en SQL-injektionssårbarhet i en publik Java-applikation som kördes på Apache Tomcat . Applikationens autocomplete-sökfunktion validerade inte användarens indata korrekt, vilket gjorde det möjligt för angriparna att injicera SQL-kommandon via en JDBC-anslutning till Oracle-databasen . Som Huntress forskare påpekade var detta ingen ny sårbarhet – SQL-injektioner har funnits i decennier och beror oftast på bristfällig hantering av användarindata som skickas till SQL-servern . Det räckte med att applikationen inte rensade ett enkelt sökfält för att hela kedjan skulle starta.

Khunt-verktygslådan: Inbäddad i databasen som Java-objekt

Istället för att distribuera traditionell skadlig kod som filer på den komprometterade servern använde angriparna Oracles inbyggda JVM och satsen CREATE JAVA SOURCE för att kompilera och lagra hela post-exploateringssatsen som Java-schemaobjekt inne i Oracle-databasen . Denna metod gjorde verktygslådan osynlig för vanliga OS-försvar, eftersom EDR- och antivirusverktyg fokuserar på processer, binärfiler och filer på operativsystemet – de inspekterar i allmänhet inte Java-klasser och PL/SQL-omslag som lagras i Oracle .

Khunt-verktygslådan innehöll följande komponenter, var och en lagrad som ett databasobjekt:

Full systemkontroll: Från databas till Windows OS

Angriparna nöjde sig inte med databasnivån. De använde Khunt-verktygslådan för att ta sig från databasen till det underliggande Windows-operativsystemet i flera steg:

1. OS-kommandokörning via KhuntCmd: De använde KhuntCmd-modulen för att köra cmd.exe /c whoami, vilket bekräftade att de körde med SYSTEM-behörighet på Windows-servern – de hade alltså uppnått fjärrkodexekvering (RCE) från databasen till operativsystemet .
2. Kapning av inloggningsuppgifter: De använde PowerShell för att anropa reg.exe och kopiera registerdatabaserna SECURITY och SYSTEM, som sparades som khuntSECURITY.hiv och khuntSYSTEM.hiv i F:\Oracle\ .
3. Tjänsteidentifiering: De körde tasklist /svc och sparade resultatet som khunttasks.txt .
4. Extrahering av ytterligare registerfiler: De använde esentutl.exe för att kopiera SAM och en andra kopia av SECURITY, sparade som khuntSAM.hiv och khunt_SECURITY.hiv .

De exfiltrerade registerfilerna kunde användas offline för att extrahera och dekoda lösenordshashar för alla lokala konton på systemet .

Försvarsblinda fläckar: Huntress viktigaste rön

Huntress utredning avslöjade flera kritiska blinda fläckar som gjorde attacken möjlig och svår att upptäcka:

• Databas som brohuvud: Databasen omvandlades från en passiv datalagringsplats till en aktiv attackplattform, där den skadliga verktygslådan levde inne i databasen istället för på disk eller i minnet .
• EDR/AV-kringgående: Traditionella EDR- och antivirusverktyg inspekterar i allmänhet inte Java-klasser och PL/SQL-omslag som lagras i Oracle, vilket gjorde verktygslådan osynlig för vanliga OS-försvar .
• Klassisk sårbarhet, ny leveransmetod: Den initiala SQL-injektionen var en välkänd sårbarhetstyp. Ingen ”zero-day” behövdes. Autocomplete-sökfunktionen räckte för att nå PL/SQL och sedan operativsystemet – vilket visar att grundläggande brister i indatavalidering kan leda till djup kompromettering när databasmotorn har OS-nivå-funktioner .
• Överprivilegierade databaskonton: Även efter en lyckad SQL-injektion är skadan begränsad om databasanvändarkontot saknar behörighet att skapa Java-källor eller köra lagrade procedurer. Organisationer ger ofta databaskonton för mycket behörighet, vilket gav angriparna de extra rättigheter som krävdes för att distribuera Khunt .

Åtgärder som rekommenderas av Huntress

Baserat på attacken rekommenderade Huntress följande åtgärder :

• Korrekt rensning av indata och parameterisering av alla webbinmatningar
• Begränsning av databasanvändares behörigheter så att även injicerade frågor inte kan skapa Java-källor eller köra godtyckliga lagrade procedurer
• Utöka övervakningen till att omfatta databasobjekt (Java-klasser, PL/SQL-omslag) istället för bara OS-nivå-artefakter

Denna attack fungerar som en skarp påminnelse om att databasmotorer med inbyggda programmeringsmiljöer (som Oracles JVM) kan bli smygande attackplattformar om de kombineras med en enda orensad indata. Säkerhetsteam måste utöka sin övervakning bortom operativsystemet till att även omfatta databasobjektlagret.