khunt: invasores rodam toolkit dentro do banco Oracle
Injeção de SQL em campo de autocompletar levou invasores a compilar um kit Java como objeto de esquema do Oracle, com execução de comandos em nível de SYSTEM. O caso expõe uma lacuna de visibilidade entre o endpoint e o interior do banco.
Imagem editorial original do Plugged Ninja
A Huntress publicou em 5 de agosto de 2026 a análise de um incidente em que invasores usaram uma injeção de SQL para instalar um kit de pós-exploração inteiramente dentro de um banco de dados Oracle. O conjunto de ferramentas, batizado pelos próprios atacantes de khunt, não existe como arquivo no disco nem como processo residente em memória: vive como objeto de esquema do banco.
O alerta inicial disparou em 27 de julho de 2026, quando a plataforma da empresa detectou atividade de roubo de credenciais em um servidor Windows que hospedava a instância Oracle. A investigação mostrou que o processo responsável pela cópia das colmeias de registro do Windows tinha como pai o oracle.exe — sinal de que a origem do comando estava no banco, não no sistema operacional.
O ponto que torna o caso relevante para equipes de defesa não é a injeção de SQL em si, técnica documentada há décadas, mas o uso do banco como cabeça de ponte. Ferramentas de EDR e antivírus se concentram em processos, binários e arquivos do sistema operacional; elas geralmente não inspecionam classes Java e wrappers PL/SQL dentro do Oracle.
Como o acesso inicial aconteceu
A porta de entrada foi uma aplicação Java pública rodando sobre Apache Tomcat, conectada ao Oracle por JDBC. Um recurso de autocompletar em campo de busca não validava adequadamente a entrada do usuário, o que permitiu que instruções SQL enviadas pelo formulário chegassem ao banco e fossem executadas.
A Huntress destaca que não houve exploração de vulnerabilidade inédita. Nas palavras do relatório, não foi necessária nenhuma falha nova, porque o recurso de busca da aplicação já bastava para alcançar o PL/SQL e, daí, o sistema operacional. A análise dos logs de acesso do Apache permitiu rastrear as requisições maliciosas ao endereço IP 178.162.151[.]229.
O que é o toolkit khunt
O Oracle Database embarca uma máquina virtual Java e oferece a instrução CREATE JAVA SOURCE, que permite armazenar código-fonte Java como objeto do banco. Esse código é compilado dentro da própria instância e pode ser chamado via SQL. Quando a configuração permite, esses objetos executam comandos no sistema operacional hospedeiro.
Foi exatamente isso que os invasores fizeram: alimentaram comandos CREATE JAVA SOURCE a partir do Tomcat, através da conexão JDBC, e o código foi compilado como objeto de esquema. A Huntress observa que a técnica já havia sido descrita ao longo dos anos — inclusive sob o nome oraexec —, mas seu uso real em ataques raramente foi documentado.
Os componentes identificados foram:
| Componente | Função |
|---|---|
| KhuntCmd | Carrega o cmd.exe e executa comandos arbitrários do sistema operacional a partir de instruções SQL |
| KhuntHash | Acessa a tabela interna de usuários do Oracle e grava nomes e dados de senha em arquivo |
| KhuntFS e KhuntFS2 | Exploradores de arquivos: listagem, leitura, busca e verificação de tamanho |
| KhuntT | Teste no estilo “ping” para confirmar que o kit está instalado e acessível |
| KhuntUnzip | Descompactação de arquivos |
| khunt_* | Wrappers PL/SQL que chamam os métodos Java subjacentes |
Da camada de banco ao sistema operacional
Com o kit instalado, os invasores usaram o KhuntCmd para abrir um shell do Windows e rodar cmd.exe /c whoami. O retorno confirmou permissões de SYSTEM — ou seja, execução remota de código a partir da camada de banco, com o privilégio mais alto da máquina.
Em seguida vieram comandos PowerShell que invocaram o utilitário de registro reg.exe para copiar as colmeias SECURITY e SYSTEM, gravadas em F:\Oracle\khuntSECURITY.hiv e F:\Oracle\khuntSYSTEM.hiv. Os invasores também executaram tasklist /svc para enumerar serviços em execução, salvando o resultado em khunttasks.txt, e usaram o esentutl.exe — utilitário do Extensible Storage Engine — para copiar as colmeias SAM e SECURITY.
Essas cópias permitem extrair e decodificar hashes de senha de contas locais do Windows. A Huntress avalia que os arquivos foram provavelmente preparados para exfiltração, mas o relatório não confirma se chegaram a ser efetivamente roubados. Também não há atribuição a um grupo específico nem informação sobre o setor da organização afetada.
Por que isso é difícil de detectar
O deslocamento conceitual é o seguinte: o banco deixa de ser apenas o alvo de onde se extraem dados e passa a ser a plataforma de onde se lançam ataques. Um kit armazenado como objeto de banco não aparece nas varreduras de arquivo, não gera um binário suspeito no disco e não fica visível nas listas de processos além do próprio oracle.exe, que é legítimo.
Isso não significa que o ataque seja invisível. No caso relatado, a detecção veio justamente do comportamento no sistema operacional: a cópia de colmeias de registro com processo pai oracle.exe é uma combinação anômala e detectável. A lição prática é que a telemetria de processo continua funcionando — o que falha é a inspeção estática de arquivos.
Há também um limite de generalização a considerar. O ataque depende de uma configuração permissiva: a conta usada pela aplicação precisava ter privilégio para criar fontes Java e executar procedimentos armazenados. Em ambientes onde o usuário da aplicação tem privilégio mínimo, a injeção de SQL ainda causaria danos, mas não chegaria à execução de comandos no sistema operacional.
Recomendações
- Aplique sanitização de entrada e parametrização de consultas em toda aplicação que fale com o banco. O caso reforça que campos aparentemente triviais, como autocompletar de busca, são superfície de ataque.
- Revise os privilégios das contas de banco usadas por aplicações públicas. Elas não devem poder criar fontes Java, executar procedimentos armazenados desnecessários nem realizar ações administrativas.
- Procure na instalação Oracle por objetos cujo
object_namecorresponda a KhuntT, KhuntFS, KhuntFS2, KhuntCmd, KhuntHash ou KhuntUnzip, e busque a stringKHUNT%nos logs de SQL. - Habilite e revise a auditoria do Oracle para instruções de criação de objetos Java e de execução de procedimentos, mantendo os registros fora do próprio servidor de banco.
- Alerte sobre processos filhos incomuns de
oracle.exe, especialmentecmd.exe,powershell.exe,reg.exeeesentutl.exe. - Monitore a criação de arquivos com extensão .hiv em diretórios de instalação do banco e a cópia de colmeias SAM, SECURITY e SYSTEM.
- Verifique conexões de saída e requisições recorrentes a endpoints injetáveis nos logs de acesso do servidor web; foi por aí que a Huntress reconstruiu o vetor.
Conclusão
O incidente não introduz uma vulnerabilidade nova nem exige que administradores corram atrás de um patch. Ele expõe uma lacuna de visibilidade: entre a superfície do sistema operacional, bem coberta pelas ferramentas atuais, e o interior do banco de dados, quase nunca inspecionado. Enquanto a validação de entrada e o princípio do privilégio mínimo continuarem sendo tratados como recomendações genéricas, a combinação de injeção de SQL com recursos legítimos do banco seguirá viável.
Vale acompanhar se o khunt aparece em outros incidentes — o que indicaria uma ferramenta em circulação, e não algo pontual — e se fornecedores de detecção passam a oferecer inspeção de objetos de esquema como capacidade padrão.
Fontes e referências
- Huntress — Inside an Oracle Database SQL Injection Attack (5 de agosto de 2026)
- BleepingComputer — Hackers run khunt post-exploitation toolkit from Oracle database (5 de agosto de 2026)
- Oracle — Documentação do Oracle Database (referência da instrução CREATE JAVA SOURCE e do Java Developer’s Guide)
- OWASP — SQL Injection Prevention Cheat Sheet
