Hackers invadiram o banco de dados Oracle de uma organização por meio de uma falha de SQL injection em uma aplicação web exposta à internet e, em seguida, instalaram um kit de pós-exploração sem gravar nenhum executável em disco.
A Huntress, que monitora o kit sob o nome khunt, investigou o caso depois que alertas de roubo de credenciais dispararam em 27/07/2026 e rastreou a cadeia até a execução de código com privilégios SYSTEM no servidor Windows subjacente.
Os logs de acesso do Apache mostraram que os invasores conseguiram acesso por meio de um endpoint vulnerável de mecanismo de busca em uma aplicação Java exposta à internet, executada no Apache Tomcat e conectada ao Oracle via Java Database Connectivity (JDBC). A falha estava na aplicação, onde um campo de busca com preenchimento automático repassava entrada não validada ao banco. A conta usada nessa conexão tinha privilégios suficientes para criar objetos Java.
A aplicação não validava corretamente as entradas enviadas pelo recurso de busca com preenchimento automático, o que permitiu aos invasores emitir comandos SQL para o banco de dados Oracle. A Huntress rastreou as requisições maliciosas até o endereço IP 178.162.151[.]229.
Depois de explorar a falha de SQL injection, os invasores alimentaram o banco com código-fonte Java e deixaram o Oracle compilá-lo em objetos de schema armazenados, executando comandos a partir do próprio mecanismo do banco. Em vez de implantá-la como arquivos executáveis no servidor, a ferramenta de pós-exploração chamada khunt foi registrada diretamente no Oracle como um conjunto de objetos Java.
O Oracle conta com uma Java Virtual Machine embutida e com a instrução CREATE JAVA SOURCE, que permite armazenar e compilar código-fonte Java como um objeto de schema do banco de dados. Já no schema do usuário, a documentação do Oracle indica que o requisito mínimo é um único privilégio de sistema, CREATE PROCEDURE. Para criar um processo do sistema operacional a partir desse código, no entanto, entra em cena Runtime.exec, que exige sua própria permissão de execução de arquivos, e a Oracle afirma que essas permissões só são concedidas por administradores com privilégios. A Huntress não informou quais concessões a conta comprometida tinha nem se os invasores precisaram adicionar alguma, mas a cadeia funcionou, indicando privilégios suficientes para ambas as etapas.
“O uso dessa técnica em ambiente real raramente foi documentado”, afirmou a Huntress.
Quando uma classe Java é compilada em um objeto de schema do banco, ela deixa de ser um processo, um binário ou um arquivo no sistema de arquivos, e produtos de detecção e resposta no endpoint geralmente não inspecionam os mecanismos internos do Oracle. Como descreve a Huntress, o banco deixa de ser apenas algo que os hackers consultam e passa a funcionar como uma cabeça de ponte a partir da qual eles atacam.
A ferramenta continha vários componentes Java e wrappers PL/SQL capazes de executar comandos, roubar credenciais e gerenciar arquivos. Seis objetos Java e vários wrappers PL/SQL khunt_* compunham o kit:
- KhuntCmd carregava cmd.exe e executava comandos arbitrários do sistema operacional enviados via SQL.
- KhuntHash lia nomes de usuário e hashes de senha da tabela interna de usuários do Oracle e os gravava em um arquivo.
- KhuntFS e KhuntFS2 listavam, liam, pesquisavam e mediam arquivos.
- KhuntT confirmava que o kit estava acessível, e KhuntUnzip extraía arquivos compactados.
A execução de cmd.exe /c whoami por meio do KhuntCmd retornou SYSTEM, confirmando que os comandos executados via banco tinham privilégios de nível SYSTEM no servidor Windows.
Em seguida, os invasores usaram PowerShell e reg.exe para copiar as hive SECURITY e SYSTEM do Registro para F:\Oracle, executaram tasklist /svc em khunttasks.txt e copiaram as hive SAM e SECURITY com esentutl.exe. A Huntress observou os arquivos sendo preparados localmente, mas não comprovou que eles foram exfiltrados.
A empresa não atribuiu o ataque a nenhum threat actor e rastreou as requisições maliciosas até 178.162.151[.]229.
Segundo a Huntress, a técnica não é nova e remonta a pelo menos duas décadas. O raptor_oraexec.sql, de Marco Ivaldi, datado de 2006, cria um objeto de source no Oracle com métodos de execução de comandos e leitura de arquivos, e depois os expõe ao SQL por meio de wrappers PL/SQL. Os objetos khunt usam a mesma arquitetura básica.
A detecção desse tipo de comprometimento exige buscas específicas: na instalação do Oracle, por nomes de objetos que comecem com Khunt, e nos logs de SQL, por KHUNT%. Esses indicadores são específicos desse kit e não revelam, por si só, a técnica por trás do ataque.
A correção passa por consultas parametrizadas e validação de entrada na aplicação, além do princípio do menor privilégio na camada inferior. Nenhum patch da Oracle corrige, sozinho, a falha da aplicação ou o excesso de privilégios da conta por trás da conexão. Uma conta que atende uma aplicação exposta à internet não deve poder criar fontes Java nem executar procedimentos armazenados que não tenha motivo para usar.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...