Одна SQL-инъекция на веб-странице обернулась не только доступом к данным, но и полным переустройством Windows-сервера. В июньском инциденте злоумышленник включил RDP, создал локального администратора, отключил Windows Defender, поставил BadIIS и XMRig. Для российских команд вывод неприятно практичный: если закрыть только следы вредоносной активности, а не исходную дыру, атакующий вернется тем же маршрутом.
Кейс разобрала Huntress, его пересказал BleepingComputer. По данным Huntress, SOC заметил подозрительную активность 26 июня 2026 года вокруг процесса Microsoft SQL Server, но причиной оказался не взлом самой СУБД, а SQL-инъекция в веб-странице на том же хосте с IIS.
Точка входа была в веб-приложении, а не в SQL Server
Это и делает историю показательной. Исследователи увидели активность через sqlservr.exe, но дальше выяснили: атакующий нашел страницу с плохо проверяемым пользовательским вводом и через SQL-инъекцию добрался до самого сервера. Иными словами, ошибка в приложении открыла дверь уже в Windows-хост, а не только в базу данных.
Для команд разработки здесь старый, но все еще дорогой урок. SQL-инъекция давно числится в базовом наборе уязвимостей, однако на практике она по-прежнему ведет не к абстрактной «компрометации данных», а к вполне приземленным последствиям: удаленный доступ, отключение защиты и монетизация взломанной машины.
После входа атакующий занялся разведкой и закреплением
Сразу после проникновения злоумышленник не стал шуметь. По данным Huntress, он запустил tasklist /svc, чтобы посмотреть процессы и службы на хосте, а затем отправил результат на подконтрольный сервер. Такой шаг помогает быстро понять, что за роль у машины, какие защитные средства на ней стоят и под что удобнее маскировать свою активность.
Дальше началось закрепление. Атакующий включил Terminal Services, то есть службу, которая отвечает за удаленный доступ по RDP, создал локальную учетную запись adminweb2$, добавил ее в группу Administrators и затем вошел на сервер уже через RDP. Параллельно он отключил Windows Defender, но другие защитные средства, включая EDR, не тронул. Для защитников это редкая удача: именно сохранившаяся телеметрия позволила восстановить цепочку действий.
BadIIS и XMRig превратили сервер в источник дохода
На этом злоумышленник не остановился. Через appcmd.exe он установил модули BadIIS, в частности HttpFastCgiModule.dll и HttpCgiModule.dll. Huntress ссылается на исследования Cisco Talos: BadIIS используют для перенаправления трафика, подмены содержимого и поискового мошенничества. Проще говоря, скомпрометированный IIS начинает работать не только на владельца сайта, но и на чужую схему заработка.
Затем на хост загрузили криптомайнер XMRig. Связанные с ним файлы спрятали с помощью attrib.exe: им выставили атрибуты system, hidden, archive и read-only. Для автозапуска использовали nssm.exe, утилиту для оформления обычного исполняемого файла как Windows-службы. Дополнительно Huntress заметила установку CnCrypt Protect, вероятно, для обхода обнаружения.
Посткомпрометация важнее быстрой очистки
В этом кейсе важен не только сам набор инструментов, а плотность действий на одной машине. Сервер одновременно стал точкой постоянного доступа, площадкой для злоупотреблений через IIS и источником скрытой монетизации. Для компаний из России и СНГ, где веб-приложения, IIS и внутренние Windows-сервисы нередко живут на одном узле, такой сценарий особенно дорог: страдает и ИТ-контур, и сайт, и доверие к цифровому каналу продаж.
Практический вывод простой. После такого инцидента мало удалить майнер, подозрительные скрипты и лишнюю учетную запись. Нужно закрыть первопричину, проверить конфигурацию удаленного доступа, пересмотреть локальные администраторские группы и заново оценить, что именно злоумышленник успел изменить в системе. Иначе это не расследование, а косметический ремонт после взлома.
Следующий логичный шаг для атакующих в похожих кейсах — либо повторный вход через ту же уязвимость, либо развитие доступа уже через созданную учетную запись и RDP.
Источник: Huntress; дополнительный пересказ: BleepingComputer.