За атакой на Красный Крест стоит APT-группа, использовавшая баг Zoho

За атакой на Красный Крест стоит APT-группа, использовавшая баг Zoho

За атакой на Красный Крест стоит APT-группа, использовавшая баг Zoho

Представители международного гуманитарного движения Красного Креста рассказали детали кибератаки, которая в прошлом месяце поразила подрядчика. Оказалось, что за кампанией может стоять правительственная кибергруппировка, а причиной взлома сервера стал баг корпоративного менеджера паролей Zoho ManageEngine ADSelfService Plus.

Напомним, что киберинцидент произошёл в конце января 2022 года и затронул программу «Restoring Family Links», помогающую семьям воссоединиться после войн, катастроф и миграции. Злоумышленники взломали серверы и украли персональные данные 515 тысяч человек.

Жёсткая обфускация и серьёзные инструменты для взлома указывают на деятельность APT-группировки (advanced persistent threat). Также на работу хорошо подготовленных хакеров намекает использование кода, специально разработанного для атакуемых ICRC-серверов.

«Большинство вредоносных файлов, обнаруженных на целевых машинах, специально созданы для обхода наших защитных решений. Нам удалось обнаружить факт взлома только после установки EDR-системы», — гласит заявление Красного Креста.

Также в ходе расследования выяснилось, что атака началась 9 ноября 2021 года, преступники имели доступ к серверам в течение 70 дней. Для проникновения в сеть атакующие использовали уязвимость под идентификатором CVE-2021-40539 в  Zoho ManageEngine ADSelfService Plus — корпоративном менеджере паролей.

Поскольку администраторы не пропатчили брешь, она помогла злоумышленникам выполнить код удалённо. Исследователи из Palo Alto Networks приписывают эксплуатацию этой уязвимости китайской киберпреступной группировке APT27.

Бесплатные VPN начали умирать за пару дней, IP уже ни при чём

Бесплатный VPN из Telegram бодро запускается, а через несколько дней Reels замирают, YouTube уходит в бесконечную загрузку, а Gemini встречает ошибкой 403. Современные системы фильтрации научились распознавать туннели даже без расшифровки трафика.

По версии пользователя Хабра Djin22, теперь одного нового IP-адреса может быть недостаточно.

Анализаторы изучают размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, маскировка под обычный HTTPS уже не всегда спасает.

Один из характерных сценариев автор называет «проблемой 16 КБ»: соединение успешно устанавливается, передаёт первые данные, а затем резко замедляется или обрывается. Для борьбы с этим используют фрагментацию пакетов, уменьшение размера TCP-сегментов и десинхронизацию DPI с помощью zapret. Идея проста: сервер должен получить нормальный поток, а анализатор — головоломку.

Отдельная история — сервисы Google. Они могут учитывать TLS-отпечаток клиента и замечать, когда программа притворяется Chrome не слишком убедительно. В sing-box для более правдоподобной имитации браузера применяют uTLS.

Если Telegram не работает даже через VLESS Reality, автор предлагает ShadowTLS v3: протокол маскирует соединение под обычную TLS-сессию с разрешённым ресурсом. Ещё один приём — padding, то есть добавление случайных данных для изменения размеров пакетов и усложнения статистического анализа.

В качестве готовых вариантов Djin22 перечисляет hynet.cloud, AmneziaVPN, Red Shield VPN, Cloudflare WARP и собственные серверы на Xray или sing-box. Однако часть текста о hynet.cloud выглядит рекламно, а заявления об «эмуляции JA4», residential-маршрутизации и автоматическом переключении протоколов приводятся без независимого подтверждения.

RSS: Новости на портале Anti-Malware.ru