За последние два года нам всё чаще приходится участвовать в расследовании взломов: сайтов, криптообменников, криптобирж. И за это время мы своими глазами увидели, как ИИ переписал саму экономику атак. Раньше у защитника было хоть какое-то время на реакцию. Теперь его почти не осталось: хакеры ускорились в разы, а администраторы работают в прежнем темпе. Расскажем, что именно изменилось, как мы находим и предупреждаем жертв, и почему счёт теперь идёт на часы, а не на сутки.
Раньше у защитника было время
Ещё недавно жизненный цикл массовой атаки выглядел предсказуемо. Публиковалась уязвимость, скажем, в популярном плагине WordPress. Хакеры начинали писать универсальный сканер, который обходил бы сайты и пробовал эту уязвимость эксплуатировать. И вот на разработку такого сканера уходило время. Ровно это время и было форой защитника: администратор успевал узнать о проблеме, скачать патч и обновиться до того, как до него доберётся волна сканирования.
Тот сканер был, по сути, глупым. Он умел одно: ходить по адресам и проверять один конкретный известный баг. Наткнулся на защиту вроде WAF, и остановился. Такая механика держала темп атак в рамках, которые оборона хотя бы теоретически успевала отрабатывать.
Теперь сканеры поумнели
Сейчас всё иначе. С приходом ИИ хакеры не просто вайбкодят сканеры быстрее, они встраивают внутрь них искусственный интеллект. Это уже не тупой перебор известных дыр, а умный бот, который подстраивается под конкретную цель: пробует разные способы, обходит WAF и другие механизмы защиты, меняет поведение, чтобы не попасться. Инструмент из простого чек-листа превратился в подобие живого атакующего, только неутомимого и работающего в тысячах потоков.
Итог закономерный: число взломов резко выросло. Причём не потому, что появились какие-то невиданные уязвимости, старые никуда не делись. Просто сместился баланс скорости. Администраторы сайтов не перестроились и не стали реагировать быстрее, а хакеры ускорились в разы. Форы, которая раньше спасала, больше нет: сканер с ИИ добирается до непропатченного сайта раньше, чем его владелец успевает открыть бюллетень безопасности. Ту же логику мы разбирали на примере массовой кампании против серверов PaperCut: там между раскрытием и захватом проходили минуты.
Админки взломщиков теперь пишет ИИ — и пишет небрежно
Но самое интересное мы видим на другой стороне, в том, чем хакеры управляют своей добычей. Раньше им нужен был софт для управления зараженными серверами и взломанными сайтами: собирать данные, логины и пароли, автоматически вставлять поисковый спам или вредоносный код. Такую панель управления надо было написать или купить, а это тоже стоило времени и немалых денег. Порог входа был реальным.
Теперь этот порог исчез. При расследованиях мы всё чаще видим, что админки взломщиков сгенерированы ИИ-моделями. И вот что показательно: сами хакеры почти не уделяют внимания безопасности кода собственных панелей. ИИ выдал рабочий результат, и его пустили в дело как есть, не глядя. В итоге на серверах злоумышленников мы регулярно находим захардкоженные логины и пароли, ключи, скрытые пути. Те же грехи, за которые мы годами ругаем разработчиков обычных приложений, во весь рост цветут в инструментах самих атакующих.
Как это помогает спасать жертв
Эта небрежность оборачивается против самих хакеров. Найденные в их файлах хардкод-доступы, ключи и скрытые пути позволяют нам вытащить список из сотен взломанных сайтов и серверов, которые эта панель обслуживает. Дальше мы связываемся с их владельцами и предупреждаем, что их ресурс скомпрометирован, и часто люди узнают об этом впервые именно от нас.
Важно про закон. Подчеркнём: мы не взламываем инфраструктуру злоумышленников. Взлом ради ответного удара — это hackback, и он незаконен. Мы поступаем иначе: находим способ идентифицировать жертв прямо в самих вредоносных файлах и файлах админки, которые злоумышленники оставили доступными. Мы читаем то, что и так открыто, а не вскрываем чужие замки.
Параллельно мы сразу отправляем abuse-жалобу хостинг-провайдеру, на чьих мощностях крутится панель сбора данных о взломанных ресурсах. Логика простая: чем быстрее сервер злоумышленника закроют, тем меньше жертв он успеет обслужить. Наша задача на этом этапе — не поймать хакера, а разорвать его цепочку и предупредить как можно больше пострадавших.
Проблема на стороне хостинг-провайдеров
Здесь мы упираемся в неожиданное узкое место — реакцию самих провайдеров. Она очень разная. Одни закрывают вредоносный сервер по первому обоснованному обращению. Другим приходится писать по несколько раз: отправляешь один abuse, второй, третий, прикладываешь доказательства, и только тогда сервер, собирающий информацию о взломанных сайтах, наконец отключают. Всё это время панель продолжает работать, а список жертв растёт. Единого стандарта скорости реакции на злоупотребления в отрасли по-прежнему нет, и это серьёзно тормозит защиту.
Что это значит для вас: счёт на часы
Главный практический вывод из всего, что мы видим: скорость реакции стала критичной. Раньше на обновление после выхода патча можно было заложить сутки-другие. Сегодня этого запаса нет. Иногда между появлением уязвимости и первой волной автоматизированных атак проходят часы, а не дни.
Свежий пример прямо подтверждает то, о чём мы предупреждаем. Китайская группировка Red Heron стремительно взяла в оборот только что раскрытую уязвимость в Gitea, CVE-2026-60004, удалённое выполнение кода с оценкой CVSS 9.8. За короткий срок она скомпрометировала 13 организаций в шести странах: воровала репозитории, собирала учётные данные, закреплялась и двигалась вглубь сетей. Это ровно тот сценарий, о котором мы говорим — уязвимость, доступная из интернета, и атакующий, который добирается до неё быстрее, чем защитник успевает среагировать. О том же ускорении мы писали и в разборе атаки автономных агентов на репозиторий RubyGems, и в материале про то, как вайбкодинг снизил порог входа для вредоносных плагинов WordPress.
Что со всем этим делать на практике:
- Сжать окно реакции на уязвимости до часов. Разовый аудит раз в год больше не спасает — периметр нужно проверять постоянно, и здесь работает пентест по подписке и регулярный тест внешнего периметра.
- Держать наготове план реагирования на инциденты. Если вас всё же пробили, скорость обнаружения и локализации решает, отделаетесь вы испугом или потеряете данные.
- Проверять то, что смотрит в интернет, глазами атакующего: заказать пентест, а сайты на CMS отдельно прогнать через аудит защищённости. Криптообменникам и биржам добавьте аудит смарт-контрактов и блокчейн-инфраструктуры.
- Подозрительные файлы на сервере не удалять сгоряча, а сохранить и передать на анализ вредоносного ПО: по ним видно, что именно у вас забрали и куда это ушло.
- Мониторить внешние следы компрометации: упоминания домена, утёкшие доступы, поддельные ресурсы. Это задача OSINT-мониторинга.
Вывод
Мир взлома меняется очень быстро, и пока не в лучшую сторону. ИИ дал атакующим то, чего у них раньше не было даром: умные сканеры, обходящие защиту, и дешёвые панели управления, собранные за минуты. Оборона же осталась примерно там, где и была. Из наших расследований вывод один и он неудобный: реагировать нужно на порядок быстрее, чем принято, иногда буквально в тот же час, когда вышла уязвимость. Хорошая новость в том, что небрежность самих хакеров нередко играет нам на руку и позволяет вовремя предупредить жертв. Плохая — рассчитывать на это как на стратегию нельзя. Если ваши сервисы смотрят в интернет, начните с честной оценки скорости своей реакции: закажите пентест или подключите пентест по подписке, пока за вас это не сделал чей-то умный бот. А как ИИ в целом меняет и нападение, и работу мониторинга, мы показали в разборе нагрузки на SOC.