В конце июля 2026 года компания Huntress зафиксировала инцидент, который начинался с ошибки в веб-приложении, а завершился получением злоумышленниками полного контроля над Windows-сервером. Атака привела к краже данных учётных записей из реестра операционной системы. Особый интерес представляет способ проникновения: вредоносные инструменты злоумышленники спрятали внутри самой базы данных Oracle, где их не ожидали увидеть стандартные средства защиты.
Описание
Всё началось с SQL-инъекции - классической уязвимости, известной несколько десятилетий. Она появляется, когда приложение принимает пользовательский ввод и передаёт его в базу данных без должной проверки. В этом случае на публичном сайте работала форма с функцией автодополнения. Злоумышленник ввёл в неё специально составленный запрос, и приложение отправило его подключённой базе данных Oracle как обычную команду. Так атакующий получил возможность выполнять в базе произвольные действия.
В ходе расследования аналитики Huntress установили, что после получения доступа злоумышленники применили необычную технику. Вместо того чтобы сохранять вредоносные файлы на диск, они загрузили исходный код на Java прямо в базу данных, воспользовавшись её штатной функцией хранения таких объектов. Oracle скомпилировала код и сохранила его как часть своей внутренней структуры. Таким образом, в базе появился набор инструментов, названный khunt. Подобный приём обсуждался в исследовательской среде, однако его реальное использование фиксируется крайне редко.
Сигналы тревоги первоначально сработали из-за подозрительной активности, связанной с копированием реестра. Аналитики изучили журналы веб-сервера и восстановили полную картину. В журналах оказалось множество запросов к уязвимой форме, что указывало на целенаправленное воздействие. Это позволило подтвердить, что начальным вектором стала именно SQL-инъекция, а не эксплуатация какой-либо неизвестной уязвимости.
Скрытый в базе данных набор выполнял несколько задач. Один из его компонентов позволял запускать команды операционной системы через SQL-запросы. Другой модуль извлекал из внутренней таблицы Oracle имена пользователей и данные для проверки паролей. Кроме того, в состав входили файловый менеджер, утилита для проверки связи и модуль для распаковки архивов. Злоумышленники оформили все эти элементы как обычные объекты базы данных, поэтому антивирусы и системы обнаружения вторжений, которые отслеживают файлы и процессы, не обращали на них внимания.
Сначала злоумышленники использовали модуль выполнения команд, чтобы подтвердить свой уровень доступа. Выяснилось, что они обладают максимальными привилегиями. После этого они запустили стандартные средства Windows для работы с реестром и создали копии нескольких важных разделов. В этих разделах хранятся настройки системы и данные локальных учётных записей, включая хеши паролей. Затем атакующие собрали список запущенных служб и сохранили его рядом с похищенными данными. Вся эта информация, судя по всему, готовилась для вывода за пределы сервера и последующего извлечения паролей. Наличие копий реестра создаёт угрозу для всей инфраструктуры, так как позволяет применить методы восстановления паролей.
Особую тревогу вызывает то, что все действия выполнялись от имени процесса базы данных. Злоумышленники смогли перейти от управления базой к выполнению команд на уровне операционной системы напрямую. Это стало возможным не из-за уязвимости в самой СУБД, а из-за ошибок в настройке приложения и чрезмерно широких прав учётной записи, через которую приложение подключалось к базе. Право создавать Java-объекты обычно не требуется для работы обычной интернет-формы, однако оно было предоставлено.
Пострадавшая организация столкнулась с серьёзными последствиями. Скомпрометированы учётные данные системы, что может привести к дальнейшему проникновению в инфраструктуру и боковому перемещению. Злоумышленники получили возможность извлекать пароли и получать доступ к другим системам в сети. Такие атаки особенно опасны для компаний, которые используют Oracle для хранения критически важных данных. Подобные инциденты показывают, что даже незначительная на вид ошибка в обработке пользовательского ввода способна привести к полной компрометации сервера.
Для защиты от таких атак необходимо соблюдать несколько базовых правил. Прежде всего нужно настроить проверку всех данных, вводимых в формы, и использовать параметризованные запросы. Это исключает возможность инъекции. Кроме того, следует минимизировать права учётных записей, которые используются для подключения к базам данных. Если приложению не требуется создавать объекты или выполнять команды операционной системы, выдавать ему такие возможности нельзя. Также стоит регулярно обновлять системы управления базами данных и ограничивать доступ к ним из внешней сети. Регулярное тестирование на проникновение и аудит кода помогут выявить подобные проблемы до того, как ими воспользуются злоумышленники.
Отдельного внимания заслуживает ограничение привилегий в самой базе данных. Пользователи, подключающиеся через веб-приложения, должны иметь доступ только к необходимым таблицам и процедурам. Следует запретить им создание любых объектов, включая Java-классы. Это серьёзно затруднит попытки закрепиться в системе.
Компаниям, использующим Oracle, стоит учитывать, что база данных может стать не только источником информации для атаки, но и базой для её развития. Традиционные средства защиты, ориентированные на файлы и процессы операционной системы, не всегда заглядывают внутрь СУБД. Поэтому важно дополнять их мониторингом активности в самой базе: отслеживать создание новых объектов, выполнение непривычных команд и обращение к системным таблицам. Это позволит вовремя заметить подозрительные действия и остановить атаку до того, как она приведёт к краже критически важных данных.
Индикаторы компрометации
IPv4
- 178.162.151.229
