Cl0p и file-transfer шлюзы: GoAnywhere, MOVEit и всё что торчит на периметре
Cl0p эксплуатирует GoAnywhere и MOVEit два квартала подряд. Инвентаризируем все точки внешнего обмена файлами и составляем план срочного патчинга и проверки логов.
Группировка Cl0p эксплуатирует уязвимости в GoAnywhere и MOVEit - новая волна атак через managed file transfer, лето 2023
К середине июля 2023-го Cl0p успела дважды сыграть один и тот же сценарий за полгода. Сначала CVE-2023-0669 в Fortra GoAnywhere MFT в феврале, потом CVE-2023-34362 в MOVEit Transfer в конце мая - начале июня. В обоих случаях схема одинаковая: массово открытый корпоративный шлюз передачи файлов, критическая уязвимость без предварительной аутентификации, автоматизированный проход по всем открытым инстансам, кража файлов, шантаж. Никакого шифровального щика - просто экфильтрация и требование выкупа за неразглашение.
После разбора MOVEit мы написали об этом в прошлом посте. Но сейчас, когда паттерн повторился второй раз за одно полугодие, стало понятно: это не разовое событие, а устойчивый вектор, и правильный ответ - не патчить конкретный продукт, а разобраться с классом объектов в целом.
Что объединяет GoAnywhere и MOVEit
Оба продукта относятся к категории managed file transfer - корпоративные шлюзы, которые обеспечивают контролируемый обмен файлами с партнёрами, клиентами, регуляторами. Они появляются в инфраструктуре по одному и тому же сценарию: задача обменяться файлами с внешним контрагентом, IT решает задачу установкой специализированного продукта, продукт настраивается, начинает работать, а потом существует сам по себе годами.
Характерные свойства таких объектов:
- доступен из интернета напрямую - иначе партнёры не смогут зайти;
- работает с чувствительными данными - иначе зачем «управляемая» передача;
- обновляется по остаточному принципу - «работает, не трогаем»;
- не мониторится как приоритетный объект - SIEM есть, но алертов на этот шлюз нет.
Именно поэтому Cl0p выбрала именно этот класс. Один эксплойт - тысячи целей. Данные для шантажа по определению там есть. Время реакции жертвы высокое, потому что никто особо не следит за логами файлового шлюза.
Инвентаризация: что мы ищем
После двух волн атак мы решили пройти по клиентской базе системно. Задача не в том, чтобы проверить наличие GoAnywhere или MOVEit - эти продукты специфичны и у наших клиентов не встречались. Задача шире: найти всё, что относится к классу «внешний обмен файлами».
Категории объектов, которые мы смотрим в рамках аудита:
Коммерческие MFT-продукты. GoAnywhere, MOVEit Transfer, Globalscape EFT, Axway Secure Transport. Если стоит - проверить версию и CVE-статус немедленно.
SharePoint Online / SharePoint Server. Часто используется для обмена с партнёрами через «гостевой доступ». SharePoint сам по себе не MFT, но данные там нередко те же, а про патчинг on-premise-версий вспоминают реже, чем следовало бы.
Файловые порталы собственной разработки. Встречаются чаще, чем кажется: ASP.NET или PHP-приложение на Windows Server, поднятое три года назад для партнёрского обмена. Никаких CVE на него нет - просто потому что никто не смотрел.
FTP/SFTP-серверы с веб-интерфейсом. WinSCP Server, FileZilla Server, ProFTPD с веб-фронтендом - всё это встречается. Особенно в сегменте промышленных предприятий, где EDI-обмен с контрагентами настроен ещё в нулевые.
Nextcloud, ownCloud и клоны. «Корпоративный Dropbox» для обмена с подрядчиками. Ставится быстро, забывается надолго. Регулярно оказывается на устаревшей версии.
По каждому найденному объекту проверяем три вещи: версия и патч-статус, наличие логов и куда они идут, кто вообще отвечает за этот объект.
Проверка логов: что искать прямо сейчас
Если GoAnywhere или MOVEit стоит в инфраструктуре - помимо патчинга нужно понять, не было ли уже атаки. Cl0p начала эксплуатировать GoAnywhere ещё в январе-феврале, MOVEit - в мае. Если патч не поставлен с первого дня, временное окно могло быть использовано.
Признаки компрометации GoAnywhere (CVE-2023-0669):
- Аномальные POST-запросы к
/goanywhere/lic/acceptбез предшествующей аутентификации. - Новые административные учётные записи в журналах аудита, созданные в нехарактерное время.
- Обращения к
/goanywhere/remote/agentс незнакомых IP - признак установки агента.
Признаки компрометации MOVEit (CVE-2023-34362):
- Необычные запросы к
/guestaccess.aspxи другим ASPX-страницам с параметрами, содержащими SQL-синтаксис. - Новые ASPX-файлы в директории приложения - это веб-шелл LEMURLOOT.
- Массовые загрузки файлов с одного IP или в короткий временной интервал - экфильтрация.
Для обоих продуктов Progress и Fortra опубликовали IoC - хэши веб-шеллов, IP-адреса C2, паттерны запросов. Если есть доступ к логам веб-сервера за последние несколько месяцев - прогонять через эти IoC обязательно.
Срочный план патчинга
Если в инфраструктуре есть что-то из списка выше, порядок действий прямолинейный:
- Зафиксировать версии всего найденного. Не «примерно», а точно - из About-страницы или пакетного менеджера.
- Сверить с бюллетенями безопасности вендора. GoAnywhere - Fortra Security Advisory, MOVEit - Progress CVE-страница, SharePoint - Microsoft Security Response Center.
- Изолировать объект, если патч нельзя поставить немедленно. Временно закрыть доступ из интернета через firewall-правило лучше, чем оставить уязвимый инстанс открытым.
- Поставить патч в тестовой среде и убедиться, что ничего не сломалось - MFT-продукты часто интегрированы с партнёрскими системами через API или SFTP-ключи.
- Поставить патч в проде и проверить логи за период до патчинга.
Пункт про изоляцию важен именно потому, что эти объекты обычно «никто не трогает». Решение закрыть его файрволом на несколько дней часто встречает сопротивление - «там партнёры работают». Но партнёры переживут несколько дней на альтернативном канале лучше, чем вы переживёте экфильтрацию их файлов.
Где мы сейчас
По итогам прохода по клиентской базе нашли несколько объектов класса «файловый портал» в разной степени заброшенности - ни GoAnywhere, ни MOVEit нигде не стояло. По каждому сейчас ведём переговоры о приоритете патчинга и настройке мониторинга.
Главный вывод пока такой: два инцидента подряд в одном классе продуктов за полгода - это уже паттерн, а не случайность. Cl0p или кто-то другой с такой же моделью неизбежно пойдёт искать следующий популярный MFT-шлюз с незакрытой дырой. Держать в голове весь реестр файловых шлюзов и знать, кто за них отвечает - базовая гигиена, которую этот год делает обязательной.