27 июля к Huntress прилетел алерт на кражу учётных данных с машины, где крутился сервер Oracle. Само по себе скучно: кто-то снимал кусты реестра, приём известен каждому, кто хоть раз ходил по чужой сети. Внимание зацепил не сам дамп, а родитель процесса – reg.exe стартовал не из-под админа, зашедшего по RDP, и не из скрипта в планировщике, а из-под oracle.exe. База данных не запускает утилиту работы с реестром. Никогда.
Когда цепочку размотали до конца, выяснилось, что атакующие не занесли на хост ни одного своего исполняемого файла. Они скормили базе исходники на Java, Oracle сама их скомпилировала, и готовый пост-эксплуатационный тулкит поселился внутри движка обычным объектом схемы – ровно там, куда не заглядывает ни EDR, ни антивирус. А входной дверью послужило поле автодополнения в поиске по сайту, которое не проверяло, что в него вводят.
Вся прелесть захода – в перевёрнутой экономике. Двадцать лет SQL-инъекцию разбирают как способ вытащить данные наружу: дамп таблиц, выгрузка пользователей, слив базы. Здесь база не была добычей. Она была плацдармом: машиной, которая по чужой команде скомпилирует, сохранит и выполнит произвольный код, потому что именно это она и умеет по документации. Дальше – механика: что именно оператор скормил базе и как с её уровня выбрался на уровень сервера.
Эта статья доступна только подписчикам. Оформите подписку, чтобы получить доступ ко всем премиум статьям.
Оформить подписку →Автор: hacker@shifry.local