SQL-инъекция позволила запустить код Windows SYSTEM через Oracle
Исследователи Huntress расследовали атаку, в которой SQL-инъекция в публичном веб-приложении открыла доступ к базе Oracle, а затем позволила выполнить команды с правами Windows SYSTEM на сервере. Злоумышленники загрузили Java-исходники в Oracle, скомпилировали их как объекты схемы и развернули набор инструментов khunt без записи исполняемого файла на диск.
Детектирование кражи учётных данных сработало 27 июля 2026 года. Huntress установила, что начальной точкой было поле поиска с автодополнением: оно передавало непроверенный пользовательский ввод в СУБД по JDBC. Учётная запись, используемая приложением, имела права, достаточные для создания Java-объектов.
Как Oracle стала точкой запуска команд
В Oracle встроена Java Virtual Machine. Оператор CREATE JAVA SOURCE позволяет передать Java-код, который СУБД компилирует и сохраняет в виде объекта схемы. В собственной схеме для этого, согласно документации Oracle, достаточно системной привилегии CREATE PROCEDURE.
Запуск процесса операционной системы из Java выполняется через Runtime.exec и требует отдельного разрешения на выполнение файлов, выдаваемого привилегированными администраторами. Huntress не уточнила, какие именно права были у скомпрометированной учётной записи и пришлось ли атакующим получать дополнительные. Однако успешная цепочка подтверждает, что доступов хватило и для создания объектов, и для запуска команд.
Такой подход известен давно: скрипт raptor_oraexec.sql Марко Ивальди, датированный 2006 годом, также создавал Java-объект для выполнения команд и чтения файлов, а затем публиковал функции через PL/SQL-обёртки. Huntress отметила, что использование этой техники в реальных атаках документировалось редко.
Состав khunt и действия после компрометации
Набор khunt состоял из шести Java-объектов и нескольких PL/SQL-обёрток khunt_*. Компонент KhuntCmd запускал cmd.exe и передавал ему команды из SQL. Проверка командой cmd.exe /c whoami вернула SYSTEM.
KhuntHash читал имена пользователей и хеши паролей из внутренней таблицы пользователей Oracle и записывал их в файл. KhuntFS и KhuntFS2 умели выводить список файлов, читать, искать и определять их размер. KhuntT проверял доступность набора, а KhuntUnzip распаковывал архивы.
После получения доступа атакующие применили PowerShell и reg.exe для копирования кустов реестра SECURITY и SYSTEM в каталог F:\Oracle. Также они сохранили вывод tasklist /svc в khunttasks.txt и скопировали SAM и SECURITY с помощью esentutl.exe. Huntress видела локальное размещение файлов, но не подтвердила их эксфильтрацию.
Что проверять и как снизить риск
Huntress связала вредоносные запросы с адресом 178.162.151[.]229, но не назвала предполагаемую группировку. Индикаторы Khunt и KHUNT% относятся к этому конкретному набору, поэтому сами по себе не выявят другие реализации той же техники. Контекст атак, использующих доверенные компоненты инфраструктуры, дополняет тактика злоупотребления заимствованным доверием, где рассматривается тактика злоупотребления заимствованным доверием.
Oracle не может выпустить патч, устраняющий SQL-инъекцию в приложении или чрезмерные привилегии его учётной записи. Huntress рекомендует применять параметризованные запросы и проверку ввода, а также принцип наименьших привилегий: аккаунт публичного приложения не должен создавать Java-исходники или запускать хранимые процедуры без обоснованной необходимости. Для бизнеса это означает необходимость проверять не только файловые артефакты на сервере, но и объекты схем Oracle и журналы SQL-запросов.