Операция Cloud Atlas: шпионская группировка Red October десять лет скрывалась в сетях дипломатов и учёных

Главной целью злоумышленников был сбор разведывательной информации из скомпрометированных систем. Но просто констатировать этот факт недостаточно. Гораздо интереснее понять, как именно строился процесс атаки, какие технические приёмы использовались и почему эта кампания до сих пор считается образцом для изучения специалистами по кибербезопасности.

Точка входа: фишинг и старые уязвимости

Атака начиналась с рассылки целевых фишинговых писем. Вредоносные вложения эксплуатировали уязвимости, которые на момент проведения операции уже были известны, но оставались эффективными из-за медленного обновления программного обеспечения в государственных и научных учреждениях. Речь идёт о CVE-2009-3129 (Microsoft Excel), CVE-2010-3333 (Microsoft Word) и CVE-2012-0158 (Microsoft Word). Все эти бреши позволяли выполнить вредоносный код, встроенный прямо в документ, без ведома пользователя.

С точки зрения анализа, самым интересным является не изучение самого эксплойта, а то, что происходит после его срабатывания. Документ имел формат RTF. При ближайшем рассмотрении в нём обнаружился объект с именем Reminder, расположенный по определённому физическому смещению. Именно там находился фрагмент кода, не зависящий от своей позиции в памяти. Внутри были обнаружены команды NOP и корректные коды операций, которые указывали на начало исполняемого шелл-кода, зашифрованного слоем защиты.

Первый этап: динамическая загрузка и подготовка почвы

После расшифровки первого слоя шелл-код начинал свою работу. Он обращался к структуре данных процесса PEB, которая содержит информацию о загруженных модулях. Это позволило вредоносной программе найти в памяти ядро системы - библиотеку kernel32.dll. Затем через специальные хеши функций он динамически разрешал нужные API-вызовы. Такой метод позволяет обойти статический анализ и сигнатурные детекторы, потому что в самом коде нет прямых строк с названиями функций.

После загрузки необходимых библиотек зловред сбрасывал на диск два файла: фиктивный документ-приманку и VBS-сценарий. Фиктивный документ имел содержимое на русском языке, что, вероятно, использовалось для маскировки или отвлечения внимания жертвы. Сам VBS-сценарий был написан таким образом, чтобы обеспечить закрепление в системе. Он создавал запись в реестре в ветке автозагрузки, гарантируя, что вредоносный код запустится при каждой перезагрузке компьютера.

Второй этап: обфускация и извлечение настоящей нагрузки

Сценарий содержал зашифрованный блок данных большого размера. После его выполнения на диск попадали два файла: ctfmon.dll и redtailed. Первый файл представлял собой библиотеку, задачей которой было расшифровать или разобрать второй. Анализ показал, что ctfmon.dll проверяет структуру второго файла на наличие признаков переносимого исполняемого файла. После проверки происходила распаковка самой библиотеки. Оказалось, что ctfmon.dll была упакована, и после снятия упаковки в памяти появлялся новый PE-файл.

Распакованная версия ctfmon.dll уже полноценно работала с файлом redtailed. Она отображала его в виртуальную память, выполняла процедуру разбора PE-структуры и расшифровывала содержимое. Важно отметить, что вся логика была рассчитана на работу в среде Windows XP. После завершения этих операций в памяти появлялся чистый исполняемый файл, готовый к запуску.

Серверы управления и облачная инфраструктура

Финальная нагрузка, извлечённая из redtailed, содержала логику связи с командным центром. В коде были обнаружены вызовы API-функций семейства MPR, предназначенных для работы с сетевыми ресурсами. Конкретно использовались WNetAddConnection2A, которая подключает компьютер к сетевому ресурсу с указанием имени пользователя и пароля, и WNetGetResourceInformationA, которая запрашивает информацию о сетевом ресурсе и разрешает его.

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

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

Выводы

Кампания Cloud Atlas (Red October) остаётся поучительным примером для всех, кто занимается обеспечением информационной безопасности. Её многоступенчатая архитектура, продуманное использование шифрования и модульный подход отражают высокий уровень инженерной мысли, направленной на скрытность, гибкость и закрепление в инфраструктуре жертвы.

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

MD5

• 35eb4733093130eb313dc9942372abbb
• 4628082e11c75b078ff0465523598040
• 4d7658a41418249368c508bc404f7ee9
• 514ce567c063e951a578701bb7b0a7f5
• c7a1ecb12b9b876795c822a65228777d
• f560bc8d6719dcd2b29eeb39317ca517