Hackare gömmer Khunt-verktygslåda i Oracle-databas efter SQL-injektionsattack

Forskare har upptäckt en attack mot en Oracle-databas där hackare utnyttjade en SQL-injektionssårbarhet för att installera ett verktyg för post-exploatering direkt i databasen.

Incidenten visar hur angripare kan använda en sårbar publik applikation som en väg till djupare åtkomst i nätverket. I stället för att placera vanliga skadeprogramsfiler på servern lagrade gruppen Java-kod i Oracle och använde den för att köra kommandon med höga Windows-behörigheter.

Huntress upptäckte aktiviteten den 27 juli 2026 efter att plattformen identifierat försök att stjäla autentiseringsuppgifter på en server som körde Oracle Database.

SQL-injektion öppnade dörren

Angriparna tog sig enligt uppgift in via en sårbar sökendpunkt i en internetexponerad Java-applikation som kördes på Apache Tomcat.

Applikationen innehöll en funktion för automatiska sökförslag. Den validerade dock inte den inmatade informationen korrekt. Detta gjorde det möjligt för angriparna att injicera SQL-kommandon och interagera med den underliggande Oracle-databasen.

Huntress spårade de skadliga förfrågningarna till IP-adressen 178.162.151[.]229.

SQL-injektionssårbarheter är fortfarande särskilt farliga när applikationer ansluter till databaser med alltför omfattande behörigheter. I det här fallet verkar databaskontot ha haft tillräckliga rättigheter för att skapa och köra Java-objekt i Oracle.

Khunt-verktyg lagrades som Oracle Java-objekt

Oracle Database innehåller en inbyggd Java Virtual Machine. Den stöder även kommandot CREATE JAVA SOURCE, som gör det möjligt att lagra och kompilera Java-källkod som ett schemaobjekt i databasen.

Angriparna missbrukade denna funktion för att distribuera ett verktyg som kallas Khunt direkt i Oracle-miljön. Metoden hjälpte dem att undvika att placera vanliga körbara filer på Windows-servern, vilket potentiellt gjorde intrånget svårare att upptäcka.

Huntress uppgav att denna teknik sällan har dokumenterats i verkliga attacker.

Verktyget bestod av flera Java-komponenter och PL/SQL-omslag som var utformade för post-exploateringsaktiviteter. Dessa verktyg gav angriparna möjlighet att köra operativsystemskommandon, granska filer, samla in autentiseringsuppgifter och packa upp komprimerade arkiv.

Verktyget möjliggjorde kommandokörning och stöld av autentiseringsuppgifter

En komponent, kallad KhuntCmd, startade cmd.exe och gjorde det möjligt för angriparna att köra Windows-kommandon via SQL-satser.

Angriparna använde den för att köra kommandot cmd.exe /c whoami. Kommandot bekräftade att aktivitet som startades via Oracle-databasen kördes med SYSTEM-behörighet på Windows-servern.

Övriga Khunt-komponenter omfattade:

• KhuntHash, som fick åtkomst till Oracles interna användartabell och skrev användarnamn och lösenordsdata till en fil.
• KhuntFS och KhuntFS2, som stödde filbläddring, läsning, sökning och kontroll av filstorlek.
• KhuntT, som fungerade som ett enkelt test för att bekräfta att verktyget fungerade.
• KhuntUnzip, som packade upp komprimerade filer.

Efter att ha fått möjlighet att köra kommandon använde angriparna PowerShell och inbyggda Windows-verktyg för att kopiera registerfilerna SAM, SECURITY och SYSTEM. Dessa filer kan hjälpa angripare att återskapa lösenordshashar för lokala Windows-konton.

De använde också tasklist /svc för att identifiera tjänster som kördes och sparade resultaten i en fil med namnet khunttasks.txt.

Huntress uppgav att registerfilerna sannolikt samlades in för att dumpa autentiseringsuppgifter. Rapporten bekräftade dock inte om angriparna lyckades exfiltrera dem.

Attacken mot Oracle-databasen belyser riskerna med omfattande behörigheter

Incidenten understryker varför internetexponerade applikationer endast bör använda databaskonton med de behörigheter de faktiskt behöver.

Organisationer bör validera och sanera all användarinmatning för att minska risken för SQL-injektion. De bör också förhindra att applikationers databaskonton kan skapa Java-källkod, köra onödiga lagrade procedurer eller utföra administrativa åtgärder.

Att begränsa databasbehörigheter kan minska skadorna även om en angripare lyckas utnyttja en sårbar applikation.