📰 Informação fresquinha chegando para você!
Não deixe essa passar: clique e saiba tudo!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Os invasores invadiram o banco de dados Oracle de uma organização por meio de uma falha de injeção de SQL em um aplicativo Web público e, em seguida, instalaram um kit de ferramentas pós-exploração sem gravar um executável no disco. Eles alimentaram o código-fonte Java no banco de dados, deixaram a Oracle compilá-lo em objetos de esquema armazenados e executaram comandos de dentro do mecanismo de banco de dados.
Huntress, que rastreia o kit de ferramentas como khunt, investigou após detecções de roubo de credenciais disparadas em 27 de julho de 2026 e rastreou a cadeia até a execução de código em nível de SYSTEM no servidor Windows subjacente.
A falha estava no aplicativo, onde um campo de pesquisa de preenchimento automático passava entradas não validadas para o banco de dados por meio de uma conexão Java Database Connectivity (JDBC). A conta por trás dessa conexão tinha privilégios suficientes para criar objetos Java.
Nenhum patch da Oracle elimina a falha do aplicativo ou o privilégio da conta por trás dele. Encontrar o kit de ferramentas significa procurar: pesquise na instalação do Oracle por nomes de objetos começando com Khunt e nos logs SQL por KHUNT%.
Uma classe Java compilada em um objeto de esquema de banco de dados não é um processo, um binário ou um arquivo no sistema de arquivos, e os produtos de detecção e resposta de endpoint geralmente não inspecionam os componentes internos do Oracle. Conforme a Huntress o enquadra, o banco de dados deixa de ser algo que os invasores consultam e se torna uma base de onde eles atacam.
A Oracle fornece uma Java Virtual Machine incorporada, e a instrução CREATE JAVA SOURCE permite que um usuário entregue o código Java que o banco de dados compila e armazena como um objeto de esquema. No esquema do próprio usuário, a documentação da Oracle coloca a barreira em um único privilégio de sistema, CREATE PROCEDURE. A geração de um processo de sistema operacional a partir desse código é executada por meio do Runtime.exec, que precisa de sua própria permissão de execução de arquivo, e a Oracle diz que elas são emitidas apenas por administradores privilegiados.
A Huntress não diz qual concede a conta comprometida ou se os invasores tiveram que adicionar alguma. A rede deu certo, então tinha o suficiente para ambos.
A técnica tem pelo menos duas décadas. O raptor_oraexec.sql de Marco Ivaldi, datado de 2006, cria um objeto de origem Oracle com métodos de execução de comandos e leitura de arquivos e, em seguida, os publica no SQL por meio de wrappers PL/SQL. Os objetos khunt usam a mesma arquitetura básica. “O uso da técnica na natureza raramente foi documentado”, disse Huntress.
Seis objetos Java e vários wrappers PL/SQL khunt_* compuseram o kit de ferramentas:
KhuntCmd carregou cmd.exe e executou comandos arbitrários do sistema operacional transmitidos como SQL.
KhuntHash leu nomes de usuário e hashes de senha da tabela interna de usuários do Oracle e os gravou em um arquivo.
KhuntFS e KhuntFS2 listaram, leram, pesquisaram e dimensionaram arquivos.
KhuntT confirmou que o kit de ferramentas estava acessível e KhuntUnzip descompactou os arquivos.
A execução de cmd.exe /c whoami por meio do KhuntCmd retornou SYSTEM. Os invasores então usaram PowerShell e reg.exe para copiar as seções de registro SECURITY e SYSTEM para F:\Oracle, executaram tasklist /svc em khunttasks.txt e copiaram as seções SAM e SECURITY com esentutl.exe.
A Huntress observou os arquivos sendo organizados localmente, mas não estabeleceu que eles foram exfiltrados. A empresa não nomeou nenhum autor da ameaça e rastreou as solicitações maliciosas até 178.162.151[.]229.
Esses indicadores são específicos deste kit de ferramentas, portanto, nenhuma pesquisa por Khunt ou KHUNT% revelará a técnica por trás dele. A correção são consultas parametrizadas e validação de entrada no aplicativo, além do menor privilégio abaixo: uma conta que atende um aplicativo voltado ao público não deve ser capaz de criar fontes Java ou executar procedimentos armazenados que não tenha motivo para tocar.
Huntress, que rastreia o kit de ferramentas como khunt, investigou após detecções de roubo de credenciais disparadas em 27 de julho de 2026 e rastreou a cadeia até a execução de código em nível de SYSTEM no servidor Windows subjacente.
A falha estava no aplicativo, onde um campo de pesquisa de preenchimento automático passava entradas não validadas para o banco de dados por meio de uma conexão Java Database Connectivity (JDBC). A conta por trás dessa conexão tinha privilégios suficientes para criar objetos Java.
Nenhum patch da Oracle elimina a falha do aplicativo ou o privilégio da conta por trás dele. Encontrar o kit de ferramentas significa procurar: pesquise na instalação do Oracle por nomes de objetos começando com Khunt e nos logs SQL por KHUNT%.
Uma classe Java compilada em um objeto de esquema de banco de dados não é um processo, um binário ou um arquivo no sistema de arquivos, e os produtos de detecção e resposta de endpoint geralmente não inspecionam os componentes internos do Oracle. Conforme a Huntress o enquadra, o banco de dados deixa de ser algo que os invasores consultam e se torna uma base de onde eles atacam.
A Oracle fornece uma Java Virtual Machine incorporada, e a instrução CREATE JAVA SOURCE permite que um usuário entregue o código Java que o banco de dados compila e armazena como um objeto de esquema. No esquema do próprio usuário, a documentação da Oracle coloca a barreira em um único privilégio de sistema, CREATE PROCEDURE. A geração de um processo de sistema operacional a partir desse código é executada por meio do Runtime.exec, que precisa de sua própria permissão de execução de arquivo, e a Oracle diz que elas são emitidas apenas por administradores privilegiados.
A Huntress não diz qual concede a conta comprometida ou se os invasores tiveram que adicionar alguma. A rede deu certo, então tinha o suficiente para ambos.
A técnica tem pelo menos duas décadas. O raptor_oraexec.sql de Marco Ivaldi, datado de 2006, cria um objeto de origem Oracle com métodos de execução de comandos e leitura de arquivos e, em seguida, os publica no SQL por meio de wrappers PL/SQL. Os objetos khunt usam a mesma arquitetura básica. “O uso da técnica na natureza raramente foi documentado”, disse Huntress.
Seis objetos Java e vários wrappers PL/SQL khunt_* compuseram o kit de ferramentas:
KhuntCmd carregou cmd.exe e executou comandos arbitrários do sistema operacional transmitidos como SQL.
KhuntHash leu nomes de usuário e hashes de senha da tabela interna de usuários do Oracle e os gravou em um arquivo.
KhuntFS e KhuntFS2 listaram, leram, pesquisaram e dimensionaram arquivos.
KhuntT confirmou que o kit de ferramentas estava acessível e KhuntUnzip descompactou os arquivos.
A execução de cmd.exe /c whoami por meio do KhuntCmd retornou SYSTEM. Os invasores então usaram PowerShell e reg.exe para copiar as seções de registro SECURITY e SYSTEM para F:\Oracle, executaram tasklist /svc em khunttasks.txt e copiaram as seções SAM e SECURITY com esentutl.exe.
A Huntress observou os arquivos sendo organizados localmente, mas não estabeleceu que eles foram exfiltrados. A empresa não nomeou nenhum autor da ameaça e rastreou as solicitações maliciosas até 178.162.151[.]229.
Esses indicadores são específicos deste kit de ferramentas, portanto, nenhuma pesquisa por Khunt ou KHUNT% revelará a técnica por trás dele. A correção são consultas parametrizadas e validação de entrada no aplicativo, além do menor privilégio abaixo: uma conta que atende um aplicativo voltado ao público não deve ser capaz de criar fontes Java ou executar procedimentos armazenados que não tenha motivo para tocar.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #os #invasores #compilam #o #khunt #dentro #do #oracle #para #transformar #a #injeção #de #sql #no #acesso #ao #sistema #windows
🔔 Siga-nos para não perder nenhuma atualização!
Postar um comentário