Как ИИ-агенты помогли выявить взлом WordPress за 51 минуту

ИИ-реагирование на инциденты позволяет операторам проводить экспертную оценку и принимать соответствующие решения, делегируя выполнение задач ИИ-агенту и его субагентам под контролем человека (human-in-the-loop). Вот как это происходило на практике в течение 3,5 часов во вторник утром – включая два момента: когда ошибся агент и когда имелся вектор сохранения доступа, который мог бы упустить оператор.

В 09:04 сайт на WordPress начал выдавать ошибки 500. Система мониторинга зафиксировала это в тот же самый момент, когда поступило сообщение о сбоях на нескольких страницах. Два независимых сигнала, в одну и ту же минуту. Поначалу я открыл сайт в браузере – доверяй (оповещениям), но проверяй. Сайт действительно был недоступен.

Этот пост о том, что произошло дальше. О механике процесса. Потому что фраза «ИИ-реагирование на инциденты» трактуется достаточно широко, но разница между кричащими заголовками и практическим применением так же сильна, как разница между фразами «ИИ написал несколько предложений по коду» и «инцидент был обнаружен за 51 минуту и устранен за три с половиной часа». В первом случае мы просто отмечаем преимущество. Во втором случае мы подразумеваем существование некоторой архитектуры управления еще до инцидента.

Конкретная конфигурация, описанная в этом посте: сессия Claude Code с файлом управления CLAUDE.md, ограниченным рамками задачи, с возможностью запуска субагентов для параллельных рабочих потоков, при этом каждое последующее действие требует моего явного одобрения. Именно это подразумевается под «агентом» — не какой-то там автономный робот, а инстанс, ограниченный рамками задачи, находящийся под контролем человека (human-in-the-loop).

Далее следует описание событий утра вторника в том порядке, в котором они происходили.

Параллельная работа еще до понимания проблемы

Под давлением инцидентов возникает инстинктивное желание действовать последовательно. Поступает сигнал тревоги. Первое действие, результат. Второе действие, результат. По одному шагу за раз. Проблема в том, что этот принцип плохо укладывается в 51 минуту, особенно когда проблема существует уже восемь дней и ее необходимо одновременно рассматривать с четырех разных аспектов.

Первые две минуты были спланированы таким образом, чтобы избежать этого прессинга. Я открыл задачу агента (Claude Code; документ управления, определяющий область действия задач, был уже создан), и пока загружался контекст управления, я подключился по SSH к инстансу Lightsail, после чего начал напрямую проверять установку WordPress. Запуск агента не бесплатен – он считывает свой CLAUDE.md, загружает специфичный для задачи документ управления и устанавливает контекст, в котором будет работать. Эти 90 секунд – потерянное время, если вы будете просто ждать. Но это не потерянное время, если вы используете его для начала своего собственного расследования.

К тому моменту, когда агент был готов принять инструкции, у меня уже было кое-что, что я мог ему передать.

Что именно?

wpconsole.php.

Это первое, что я увидел – файл в каталоге WordPress с именем, которое выглядело вполне адекватно. Но нет. В ядре WordPress не существует файла с таким именем. Были и другие файлы с похожими названиями – префикс “wp” и какой-то безобидно выглядящий корень. И все это наряду с реальными файлами ядра. Уставший пользователь вполне мог пролистать каталог и посчитать, что здесь вроде как все в порядке.

Злоумышленник, желающий получить постоянный доступ к установке WordPress, имеет два варианта: разместить вредоносные программы там, где администраторы их не увидят, либо разместить их там, где администраторы могут их увидеть, но при этом дать им такие имена, чтобы они выглядели вполне себе легитимно. Второй вариант обнаружить сложнее. Он зависит от того, насколько хорошо оператор знает реальные файлы ядра, чтобы понять, что должно здесь быть, а что нет. Это тот самый особый уровень экспертных знаний в области сопоставления шаблонов, которого нельзя добиться от сканера.

Именно такое понимание стало поворотным моментом. И это был не баг. Это был финальный этап компрометации, который обнаружился только потому, что злоумышленник допустил ошибку в коде, приведшую к сбою вредоносной программы и появлению ошибок HTTP 500, вызвавших предупреждения.

Передача управления

Я проинформировал агента о том, что я выяснил: рассказал о конкретных файлах, которые выглядели подставными, высказал гипотезу о том, что это компрометация, и поделился своей позицией, как именно я хочу решить эту проблему – сначала устранение бреши, а затем уже объяснение произошедшего. Все действия на стороне сервера требовали моего явного одобрения перед выполнением. Принцип HITL – жесткое правило для производственной инфраструктуры.

Агент не стал подтверждать диагноз путем повторения моих действий. Вместо того он, согласовываясь с правилами управления задачами, запустил субагента для параллельного сбора логов сервера, в то время как в основном потоке было инициировано независимое сканирование сайта на наличие дополнительных индикаторов. Мне не нужно было ему об этом говорить – правила предписывали ему такой рабочий процесс, и он рефлексивно к ним прибегнул.

Почему агент сделал это сам

Загруженный этим агентом файл CLAUDE.md, определяющий область действия задач, содержит конкретные инструкции по сканированию безопасности: использовать субагентов для параллельного выполнения потоков расследования, держать основной поток открытым для сортировки и общения с оператором. Когда начинается сканирование, агент обращается к субагенту так же, как опытный специалист по реагированию на инциденты обращается к tail -f в логах сервера.

Управление – это проектное решение, которое я принял еще до инцидента, это не какая-то импровизация, придуманная в процессе поиска бреши. В сжатых условиях никто не изобретает хорошую структуру – все полагаются на уже существующие среды, а в большинстве организаций, использующих ИИ-агентов для кодирования, никакой структуры вообще нет.

Что показала проверка

Примерно через 8 минут после передачи данных агент и субагент вернулись ко мне с более полной картиной.

Компрометация была подтверждена. Мой первоначальный диагноз тоже подтвердился. Но логи поведали историю, которую я не смог установить при первоначальной работе с терминалом – злоумышленник получил доступ к серверу примерно за неделю до этого. Хакеры восемь дней находились в режиме ожидания. За все это время ни один файл не был изменен. Атака стала очевидной только во вторник утром, когда злоумышленник начал развертывать вредоносный софт и допустил ошибку в коде, которая и привел к сбою.

Фаза скрытого взлома – это тот этап, который имеет решающее значение для разработки мер защиты. В течение восьми дней сайт, находящийся под активным удаленным управлением, для всех автоматизированных сканеров выглядел идентично исправному ресурсу. Фаза «злоумышленник получил мои административные учетные данные» не оставляет сигнатур вредоносного ПО. Она оставляет лишь события входа в систему, которые выглядят аналогично легитимным входам.

Более подробная информация появилась после извлечения логов: брутфорс-атака, взломавшая учетные данные администратора, проводилась по довольно хитрой схеме, чтобы избежать срабатывания жесткого порога блокировки fail2ban. В частности, она шла в фиксированном темпе, чтобы оставаться в пределах лимита блокировок, и попытки повторялись в течение трех дней. Автоматизированный, медленный, дешевый метод. Этот конкретный путь был перекрыт в ходе устранения проблем, и были введены дополнительные методы контроля, чтобы предотвратить повторение того же вектора атаки.

Агент и его субагенты также выявили векторы сохранения доступа, которые мне нужно было устранить: модификации mu-плагина, записи cron-заданий, предназначенные для повторного развертывания вредоносного софта из хранящихся в БД блобов, артефакты сессионных ключей, которые сохраняются после смены паролей. Всего пять векторов сохранения доступа.

51 минута

Восстановление прошло в два этапа. Первый этап: локализация. Устранение всех векторов сохранения доступа в порядке приоритета. Восстановление чистого состояния. Закрытие конкретного пути эксплуатации. Второй этап: анализ. Понимание того, как это произошло, достаточно подробное, чтобы превентивные меры были направлены на реальный вектор, а не на какие-то догадки.

Последовательность действий – это классический пример реагирования на инцидент. Остановить кровотечение, прежде чем понять его причину у пациента. Преимущество использования ИИ-ассистированной версии заключалось не в скорости, а в том, что оба этапа выполнялись без прерывания одного другим. В условиях работы в одиночку постоянно возникает соблазн объединить их: исправить одно, осмотреть другое, исправить третье. В результате мы имеем только частичное исправление, поскольку мы бросили все на полпути, и неполную картину произошедшего, поскольку мы учли только часть улик.

В ходе первого этапа агент и его субагенты выполняли параллельные потоки задач – проверку целостности файлов, очистку базы данных, удаление mu-плагина, аннулирование сессий – каждая из которых требовала моего одобрения перед запуском. Большую часть этих пятидесяти минут я утверждал, перенаправлял запросы, задавал уточняющие запросы и принимал решения о последовательности действий. Примерно 70% времени у меня ушло на общение с основным агентом, а не на работу с консолью.

Если бы реагирование на инциденты с помощью ИИ означало «ИИ делает то, что сделал бы я сам, но быстрее», то в таком случае его преимущества были бы слабыми. В действительности же оно означает, что оператор становится исключительно уровнем принятия решений, а агент и его субагенты – уровнем выполнения. Человек выполняет работу, в которой он хорош: распознавание закономерностей, определение приоритетов, выявление цепочек инференса, которые кажутся правильными, но таковыми не являются. Агент выполняет работу, в которой он хорош: параллелизм, систематический перебор, сравнение контрольных сумм.

HITL с позиции перенаправления задач

В ходе анализа уязвимостей агент обнаружил mu-плагин, который был одновременно обновлен на всех сайтах сети. Его название показалось подозрительным. Агент предположил, что это и есть вектор атак, применяемый теперь ко всей сети. Он хотел удалить файл и очистить все сайты.

Это меня насторожило.

Время обновления было странным – оно не совпадало со всем остальной активностью злоумышленника. И имя файла все же выглядело легитимным, а не вредоносным. Почему? Не знаю, но так показалось.

Вместо удаления я попросил агента показать содержимое файла.

Это была часть утилиты управления сетью. Совершенно легитимная часть. Если бы агент продолжил свои действия, мы бы потратили остаток дня на ручную перенастройку каждого сайта в сетевой консоли управления. Честно говоря, восстановление заняло бы, по всей вероятности, несколько дней, что было бы хуже, чем первоначальный инцидент.

Агент не идиот. У него была правдоподобная теория с правдоподобными доказательствами. Мое вмешательство основывалось на информации, которой ему не хватало. Я отталкивался от интуиции, накопленной за годы работы с инцидентами. Именно для этого и существует HITL – не принятие формальных решений, а выявление цепочки на первый взгляд правдивых выводов (инференса), но являющихся ошибочными, еще до их необратимого применения. Проверка подозрительного файла – ничего не стоящая задача. Удаление этого файла – ошибочное действие, как выяснилось бы впоследствии, – совсем другое дело.

HITL с позиции обнаружения взлома

Момент с mu-плагином – достаточно популярная история, связанная с HITL, и подобные примеры можно часто видеть в сети. Но это еще не все.

Один из пяти обнаруженных агентом векторов сохранения доступа затрагивал реальный файл ядра WordPress. Не какая-то там подозрительная подделка с префиксом wp, а легитимный основной файл, модифицированный так, что уставший оператор, пролистывающий результаты поиска, просто пропустил бы его. Агент обнаружил взлом с помощью систематического сравнения контрольных сумм файлов с заведомо исправными файлами ядра для данной версии. Я бы почти наверняка не выявил этого в случае ручного анализа. Контрольные суммы – это не то, что рассматривает одиночка-оператор в сжатые сроки. Обычно такие планы есть, но они рассеиваются, потому что его внимание занимают более очевидные векторы проникновения.

Как мы видим, HITL работает в двух направлениях. Агент обнаруживает то, что оператор пропустил бы, ибо первый делает систематические сравнения, на которые у оператора нет времени. Оператор же обнаруживает то, что пропустил бы агент, поскольку интуиция сопоставления шаблонов пока не является надежным агентским инструментарием. Кейсы, которые подают эту историю только в одном направлении, недооценивают истинную мощь этой архитектуры.

AAR-анализ позволил найти второй скомпрометированный сайт

Меры по локализации завершились в 09:55. Первый AAR-отчет (After Action Review) был опубликован двадцать одну минуту спустя, в 10:16.

Написание AAR-отчета в соответствии с принципом «он должен быть понятен даже через полгода» — это механизм сбора информации. AAR- отчет не просто документирует произошедшее, он заставляет автора взглянуть на артефакты под другим углом. Вот и я решил мыслить шире и в процессе составления первого AAR-черновика обнаружил, что у нас имеется одна нестыковка.

Такая нестыковка стала достаточным основанием для того, чтобы предположить, что метод доступа злоумышленника может выходить за рамки одного сайта. В итоге я поручил агенту проверить все сайты в сети на наличие того же набора индикаторов. И он нашел. Второй скомпрометированный сайт, который мы никогда бы не выявили в ходе расследования одного отдельного инцидента.

Второй сайт был подготовлен к запуску, но еще не развернут. Злоумышленник получил к нему доступ и подготовил почву, но не успел изменить файлы. Архитектура сайта сыграла здесь важную роль: интеграция сайта осуществлялась только в одностороннем режиме отправки, т.е. на подготовленном к запуску сайте не было каких-либо конфиденциальных данных. Процесс устранения уязвимости проходил по той же самой двухэтапной схеме. Он оказался более быстрым, поскольку схема уже была понятна.

Измученный оператор-одиночка не будет тщательно составлять AAR-отчет и затем проводить упреждающий анализ всей сети сайтов. Агент в данном случае сделал за меня большую часть работы.

Что не удалось обнаружить сканерам

На обоих серверах работал сканер вредоносного ПО. Ни одна из атак не была им обнаружена.

Взлом сайта был зафиксирован во время планового вечернего сканирования, когда началась активная фаза развертывания. Но фаза скрытого взлома – та, которая фактически обеспечила закрепление на сайте в течение 8 дней, — не имела сигнатуры, с которой сканер мог бы сопоставить данные. Злоумышленник смог получить доступ ко второму сайту, но еще не развернул вредоносный софт. Доступ без развертывания не оставляет вирусных сигнатур. Это выглядит как обычное авторизованное использование.

Коммерческие сканеры выявляют сигнатуры вредоносного ПО. Они не способны обнаружить доступ с использованием учетных данных или тайное внедрение малвари. Владелец сайта, применяющий стандартные инструменты защиты, не заметил бы ничего подозрительного в обоих случаях, пока злоумышленник никак не проявил себя. Это не какой-то пробел в конфигурации, это структурное ограничение. «Купите более мощный сканер» — не решение проблемы, потому что тип атаки, который произошел в нашем случае, по своей природе недоступен для обнаружения сканерами.

Гипотетическая ситуация

Оператор-одиночка, решающий тот же самый инцидент без ИИ, столкнется с четырьмя проблемами, каждая из которых по отдельности забьет его график.

Одно лишь сдерживание займет целый рабочий день или больше. Ручная проверка пяти векторов сохранения доступа по целостности файлов, mu-плагинам, заданиям cron, параметрам БД и состоянию сессий в порядке приоритета – это далеко не 51-минутная работа. Оператор не может воспользоваться преимуществами распараллеливания. Даже со специализированными коммерческими инструментами очистки WordPress один вектор доступа обычно сохраняется. Злоумышленник возвращается. Восстановление начинается заново, причем в худших условиях, поскольку результаты прошлой очистки уже не вызывают доверия.

Процесс поиска бреши прерывается. Под гнетом происходящего, при ограниченном количестве ресурсов и времени, этап «понимания причин» уступает место этапу «восстановления работы сайта». Вектор атаки не удается полностью вскрыть, а это значит, что меры предотвращения будут основываться только на гипотезах, а не на фактах. Через три месяца атака такого же типа происходит вновь, но уже немного иным способом.

Аудит всей сети сайтов не произведен. К тому времени, как первый сайт очищен и составлен отчет AAR, оператор-одиночка уже сильно измотан. Проактивный аудит – то, что помогло выявить второй взлом, — является задачей низкой срочности, требующей тщательного анализа, от которой отказываются, когда у оператора заканчиваются ресурсы. Без такого аудита компрометация второго сайта остается незамеченной до тех пор, пока злоумышленник не решит действовать.

Верификация – ненадежный этап. Сравнение контрольных сумм и целостности файлов требует скрупулезной работы, что часто упускается, когда измученному оператору нужно объявить инцидент закрытым. «Устранение последствий завершено» превращается в «думаю, мы закончили». Сайты, которые кажутся чистыми уставшему оператору, остаются скомпрометированными. Следующий инцидент, если он произойдет, будет выглядеть как новый.

Форма работы

Внедрение ИИ для реагирования на инциденты меняет распределение времени оператора.

В доагентской версии старший оператор большую часть времени тратил на выполнение задач: запуск команд, чтение логов, написание grep-пайплайнов, отслеживание результатов. Принятие решений – выявление приоритетов, распознавание паттернов, перенаправление заведомо неверных цепочек инференса, дальнейший аудит – происходило в рамках оставшихся когнитивных ресурсов. Зачастую их было немного. А работа по управлению инцидентами, документирование после инцидента, превентивный поиск зоны поражения – все это осуществлялось только в том случае, если у оператора сохранялись ресурсы после выполнения исходных задач. Чего, как правило, не было.

В версии с участием агентов выполнение задач делегируется агентской команде, которая работает в рамках текущего управления и с проверкой HITL. Оператор в итоге уделяет время принятию решений, поскольку эту часть нельзя делегировать. Принятие решений не высасывает все силы так, как реальное выполнение задач.

Аудит всей сети сайтов – та работа, которую я должен был сделать, но до которой я вряд ли бы когда-то добрался. Для этого нужна команда, а не отдельный оператор – но в тот вторник я трудился один.

В этом и заключается основная идея. Привлечение ИИ восстанавливает способность оператора выполнять работу, которая в противном случае была бы отложена вследствие его высокой нагрузки – аудиты, проверки, проактивные поиски проблемных зон.

Я использую агентские рабочие процессы, чтобы расширить свою собственную зону видимости. Именно это позволяет мне выйти за рамки «кажется, я нашел проблему» и перейти к проактивным аудитам, которые действительно выявляют то, что было упущено – со скоростью, которая была недостижима для человеческой команды.

Источник: https://hackernoon.com