27 июля Huntress зафиксировала атаку на Oracle Database, в которой после SQL-инъекции злоумышленники встроили постэксплуатационный набор khunt прямо в базу данных. История неприятна не только самим багом: через обычное веб-приложение атакующие дошли до команд на Windows-сервере с правами SYSTEM. Для команд, где Oracle живет рядом с легаси-Java и сервисными учетками «с запасом», это не экзотика, а очень узнаваемый сценарий.
По данным BleepingComputer, инцидент обнаружили 27 июля 2026 года, когда платформа Huntress заметила кражу учетных данных на сервере с Oracle. Разбор Apache access logs показал точку входа: публичный Java-сервис на Apache Tomcat, а точнее endpoint поисковой строки с автодополнением. Поле, которое обычно считают скучной частью интерфейса, не проверяло ввод как следует и позволило отправлять SQL-команды напрямую в БД. Источник вредоносных запросов Huntress связала с IP-адресом 178.162.151.229.
Дальше начинается та часть, из-за которой кейс будут разбирать не только AppSec-команды, но и DBA. Вместо того чтобы положить на сервер исполняемые файлы, атакующие использовали встроенную в Oracle Java Virtual Machine и оператор CREATE JAVA SOURCE. Он позволяет хранить и компилировать Java-код как объект схемы, а затем запускать его из SQL. Если конфигурация это допускает, такой объект может обращаться к командам хоста. Huntress отдельно подчеркнула, что применение этого приема в реальных атаках документируется редко. Практический смысл понятен без лишней романтики: чем меньше отдельный бинарник светится на диске, тем меньше у защитников простых файловых артефактов для поиска.
Внутри Oracle Database злоумышленники развернули не один «хакерский скрипт», а целый набор из Java-компонентов и PL/SQL-оберток:
- KhuntCmd — запуск cmd.exe и выполнение системных команд через SQL-запросы.
- KhuntHash — доступ к внутренней таблице пользователей Oracle и запись имен пользователей и данных паролей в файл.
- KhuntFS и KhuntFS2 — просмотр каталогов, чтение файлов, поиск и проверка размера.
- KhuntT — простая проверка, что комплект установлен и отвечает.
- KhuntUnzip — распаковка сжатых файлов.
Название у набора почти шутливое, но функциональность вполне взрослая: от разведки до кражи учетных данных и работы с файловой системой прямо из базы.
Самым показательным эпизодом стала команда cmd.exe /c whoami. Она подтвердила, что цепочка SQL → Oracle → Windows выполнялась с правами SYSTEM. После этого уже без особой магии в ход пошли PowerShell и штатные утилиты Windows: атакующие скопировали кусты реестра SAM, SECURITY и SYSTEM, из которых обычно восстанавливают хэши локальных учетных записей. Затем выполнили tasklist /svc, чтобы получить список процессов и привязанных служб, а результат сохранили в файл khunttasks.txt. Huntress считает, что реестровые файлы, вероятно, готовили к credential dumping и выносу наружу, но прямого подтверждения успешной эксфильтрации у компании нет. Для бизнеса это важная оговорка: подтвержден не полный масштаб ущерба, а способность атакующих быстро превратить веб-баг в контроль над хостом.
Для разработчиков и владельцев enterprise-приложений здесь болезнен не сам факт SQL-инъекции — о ней написаны километры регламентов, — а старый организационный грех: у публичного приложения оказался слишком широкий коридор до Oracle Database. Сервисный аккаунт, который должен был обслуживать поиск, на практике имел достаточно полномочий, чтобы создавать Java source, использовать лишние хранимые процедуры и фактически помогать постэксплуатации. Huntress рекомендует базовую, но часто игнорируемую вещь: валидировать любой пользовательский ввод и урезать права учеток приложений до предела. Если внешнему сервису не нужен CREATE JAVA SOURCE, неиспользуемые процедуры и административные действия, у него их не должно быть. На фоне недавних историй вокруг Oracle E-Business и PeopleSoft этот кейс выглядит не редкой техникой для «штучных» атак, а напоминанием, что старый enterprise-стек остается удобной площадкой для вполне современных вторжений.
Практический вывод для ИТ-команд предельно приземленный. Во-первых, проверять нужно не только формы логина и API, но и «безобидные» элементы вроде автокомплита в поиске: именно такие места живут годами без нормального threat modeling. Во-вторых, Oracle стоит смотреть не только как на хранилище данных, но и как на среду исполнения, если в ней активны Java-объекты и функции, способные дотянуться до ОС. В-третьих, инцидент полезно прогонять в обратную сторону: какие события увидит SOC, если команды начнут выполняться не из процесса powershell.exe, а через SQL-вызовы внутри БД. Если ответ расплывчатый, у атакующих уже есть зазор.
История с khunt неприятна именно своей будничностью: в цепочке нет zero-day, нет сложной supply-chain-операции, нет экзотической платформы. Есть веб-приложение на Tomcat, SQL-инъекция, щедрые права и СУБД Oracle, которую в какой-то момент начинают использовать не как базу, а как плацдарм. Чем дольше компании держат такие связки без пересмотра привилегий и телеметрии, тем короче путь от одного криво обработанного поискового запроса до полноценного захвата Windows-сервера.