Huntress обнаружила атаку, в которой злоумышленники не просто использовали SQL-инъекцию в Oracle Database, а загрузили в саму СУБД постэксплуатационный набор khunt и через неё дошли до команд на Windows с правами SYSTEM. Для ИТ-команд это неприятный сигнал: база данных здесь сработала не как хранилище, а как плацдарм для дальнейшего взлома.
Как SQL-инъекция дошла до Oracle
Сам инцидент Huntress заметила 27 июля 2026 года, а BleepingComputer написал о нём 5 августа. Разбор журналов доступа Apache показал исходную точку: публичное Java-приложение на Apache Tomcat, где поисковый эндпоинт с автодополнением принимал ввод без нормальной проверки. Через JDBC этот ввод уходил в Oracle, и атакующие смогли передавать туда собственные SQL-команды.
Источник вредоносных запросов Huntress связала с IP-адресом 178.162.151[.]229. История поэтому важна не только для специалистов по безопасности приложений: проблема началась в веб-форме, а закончилась выполнением команд на сервере базы данных.
Почему khunt внутри базы опаснее веб-шелла
После SQL-инъекции злоумышленники не стали загружать на сервер заметный исполняемый файл. Они использовали встроенную в Oracle Java Virtual Machine и команду CREATE JAVA SOURCE, которая позволяет хранить и компилировать Java-код как объект схемы прямо внутри базы. Если у учётной записи хватает прав, такой объект можно запускать из SQL и дотягиваться до операционной системы.
Внутри Oracle они развернули набор khunt из Java-компонентов и PL/SQL-обёрток. В него входили KhuntCmd для запуска cmd.exe, KhuntHash для выгрузки имён пользователей и парольных данных из внутренней таблицы Oracle, KhuntFS и KhuntFS2 для работы с файлами, KhuntT для проверки, что набор установлен, и KhuntUnzip для распаковки архивов. Huntress пишет, что такая техника описывалась и раньше, но её использование в реальной атаке документируют редко.
Команды на Windows и копирование реестра
Дальше атакующие использовали KhuntCmd для запуска cmd.exe /c whoami и подтвердили, что команды выполняются на Windows-сервере с правами SYSTEM. После этого они уже работали штатными средствами: через reg.exe сохранили кусты реестра SECURITY и SYSTEM в файлы F:OraclekhuntSECURITY.hiv и F:OraclekhuntSYSTEM.hiv, а вывод tasklist /svc записали в F:Oraclekhunttasks.txt.
Затем в ход пошёл esentutl.exe: с его помощью злоумышленники скопировали SAM и ещё одну копию SECURITY в файлы F:OraclekhuntSAM.hiv и F:Oraclekhunt_SECURITY.hiv. Такие файлы обычно используют для извлечения хэшей локальных учётных записей. Huntress считает, что их готовили к выносу данных, но факт успешной эксфильтрации в отчёте не подтверждён.
Что это меняет для Oracle-команд
Неприятная часть истории в том, что здесь не было уязвимости нулевого дня и экзотической цепочки. Хватило SQL-инъекции и слишком широких прав у учётной записи приложения. Для компаний с Oracle это прямое напоминание: внешние сервисы не должны уметь создавать Java-объекты в базе, выполнять лишние хранимые процедуры и тем более прокладывать себе путь до ОС. Если в мониторинге нет связки вида SQL → oracle.exe → reg.exe, такой сценарий легко проскочит мимо EDR и обычных сигнатур.
Оригиналы: и .