Hackere skjuler Khunt-værktøjssæt i Oracle-database efter SQL-injektionsangreb

Forskere har afdækket et angreb mod en Oracle-database, hvor hackere udnyttede en SQL-injektionssårbarhed til at installere et værktøj til efterudnyttelse direkte i databasen.

Hændelsen viser, hvordan angribere kan bruge en sårbar offentligt tilgængelig applikation som en vej til dybere adgang i netværket. I stedet for at placere almindelige malwarefiler på serveren gemte gruppen Java-kode i Oracle og brugte den til at køre kommandoer med høje Windows-rettigheder.

Huntress opdagede aktiviteten den 27. juli 2026, efter at platformen identificerede forsøg på at stjæle legitimationsoplysninger på en server, der kørte Oracle Database.

SQL-injektion åbnede døren

Angriberne fik angiveligt adgang via et sårbart søgeendepunkt i en internetvendt Java-applikation, der blev hostet på Apache Tomcat.

Applikationen indeholdt en funktion til automatiske søgeforslag. Den validerede dog ikke indsendte input korrekt. Det gjorde det muligt for angriberne at injicere SQL-kommandoer og interagere med den underliggende Oracle-database.

Huntress sporede de ondsindede forespørgsler til IP-adressen 178.162.151[.]229.

SQL-injektionssårbarheder er fortsat særligt farlige, når applikationer opretter forbindelse til databaser med for omfattende rettigheder. I dette tilfælde ser databasekontoen ud til at have haft tilstrækkelige rettigheder til at oprette og køre Java-objekter i Oracle.

Khunt-værktøjet blev gemt som Oracle Java-objekter

Oracle Database indeholder en indbygget Java Virtual Machine. Den understøtter også CREATE JAVA SOURCE-sætningen, som gør det muligt at gemme og kompilere Java-kildekode som et databaseskemaobjekt.

Angriberne misbrugte denne funktion til at installere et værktøj kaldet Khunt direkte i Oracle-miljøet. Denne fremgangsmåde hjalp dem med at undgå at placere traditionelle eksekverbare filer på Windows-serveren, hvilket potentielt gjorde indtrængningen sværere at opdage.

Huntress oplyste, at denne teknik kun sjældent er blevet dokumenteret i virkelige angreb.

Værktøjet bestod af flere Java-komponenter og PL/SQL-wrappere, der var designet til aktiviteter efter kompromittering. Disse værktøjer gav angriberne mulighed for at køre operativsystemkommandoer, undersøge filer, indsamle legitimationsoplysninger og udpakke komprimerede arkiver.

Værktøjet muliggjorde kommandokørsel og tyveri af legitimationsoplysninger

En komponent ved navn KhuntCmd startede cmd.exe og gjorde det muligt for angriberne at køre Windows-kommandoer via SQL-sætninger.

Angriberne brugte den til at køre kommandoen cmd.exe /c whoami. Kommandoen bekræftede, at aktivitet startet via Oracle-databasen blev udført med SYSTEM-rettigheder på Windows-serveren.

Andre Khunt-komponenter omfattede:

• KhuntHash, som fik adgang til Oracles interne brugertabel og skrev brugernavne og adgangskodedata til en fil.
• KhuntFS og KhuntFS2, som understøttede filgennemgang, læsning, søgning og kontrol af filstørrelse.
• KhuntT, som fungerede som en simpel test for at bekræfte, at værktøjet virkede.
• KhuntUnzip, som udpakkede komprimerede filer.

Efter at have opnået mulighed for at køre kommandoer brugte angriberne PowerShell og indbyggede Windows-værktøjer til at kopiere registreringsdatabaserne SAM, SECURITY og SYSTEM. Disse filer kan hjælpe angribere med at genskabe adgangskode-hashes for lokale Windows-konti.

De brugte også tasklist /svc til at identificere kørende tjenester og gemte resultaterne i en fil med navnet khunttasks.txt.

Huntress oplyste, at registreringsdatabasefilerne sandsynligvis blev indsamlet med henblik på at udtrække legitimationsoplysninger. Rapporten bekræftede dog ikke, om angriberne rent faktisk lykkedes med at eksfiltrere dem.

Angrebet mod Oracle-databasen fremhæver risikoen ved omfattende rettigheder

Hændelsen understreger, hvorfor offentligt tilgængelige applikationer kun bør bruge databasekonti med de rettigheder, de reelt har brug for.

Organisationer bør validere og rense al brugerindtastet data for at reducere risikoen for SQL-injektion. De bør også forhindre, at applikationers databasekonti kan oprette Java-kildekode, udføre unødvendige lagrede procedurer eller udføre administrative handlinger.

Begrænsning af databaserettigheder kan reducere skaderne, selv hvis en angriber finder en måde at udnytte en sårbar applikation på.