Полный анализ командных серверов Flame

Наш предыдущий анализ вредоносной программы Flame, представлявшей собой мощное средство кибершпионажа, имеющее непосредственное отношение к кампании Stuxnet, был опубликован в конце мая 2012 года и вскрыл широкомасштабную кампанию, направленную на несколько ближневосточных стран.

Вредоносная программа Flame, включая все ее компоненты, очень большая; в ходе наших продолжающихся исследований обнаруживаются все новые подробности, связанные с ней. Новости об этой угрозе достигли высшей точки 4 июня 2012 года, когда Microsoft выпустила экстренный патч, который заблокировал три поддельных цифровых сертификата, использованных во Flame. В тот же день мы подтвердили факт использования во Flame поддельных сертификатов и опубликовали наш технический анализ этой сложной атаки. Этот вновь обнаруженный функционал Flame оказался настолько сложным, что он мог быть реализован только лучшими криптографами мира. С тех пор скептические шутки о Flame прекратились.

Позже в июне мы подтвердили, что разработчики Flame взаимодействовали с командой, создавшей Stuxnet. Этот факт лишний раз подтвердил, что Flame разрабатывался при государственной поддержке.

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

В данном блогпосте мы публикуем принципиально новую информацию, которая была собрана во время детального анализа командных серверов Flame, проведенного в партнёрстве с Symantec, ITU-IMPACT и CERT-Bund/BSI.

Командный сервер: краткая справка

Операционная система: 64-битная версия Debian 6.0.x

Виртуализация: в большинстве случаев работает под OpenVZ

Использованные языки программирования: PHP (большая часть кода), Python, bash

База данных: MySQL с таблицами InnoDB

Веб-сервер: Apache 2.x с самоподписанными сертификатами

Анализ сервера

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

Необходимость работы с контейнерами файловой системы OpenVZ добавила определенные ограничения, которые усложнили детальный анализ. Например, располагая только контейнерами OpenVZ, невозможно обратиться к неиспользуемым кластерам жёсткого диска, чтобы извлечь из них удалённые файлы.

Конфигурация сервера типовая — LAMP (Linux, Apache, MySQL,PHP). На сервере размещался веб-интерфейс панели управления, а также несколько скриптов, запускаемых автоматически по расписанию.

Сервер был доступен по протоколу HTTPS через порты 443 и 8080. Корневой директорией для документов была /var/www/htdocs/, в ней находились подкаталоги и PHP-скрипты. В то время как в системе был установлен PHP5, код был написан так, что мог работать и на PHP4. Например, в /var/www/htdocs/newsforyou/Utils.php определена функция ‘str_split’, которая реализует логику функции ‘str_split’ из PHP5, недоступной в версии 4. Разработчики кода командного сервера, скорее всего, обеспечили совместимость с PHP4, потому что не знали точно, какая из двух популярных версий PHP будет установлена на сервере.

Рис. 1. Содержимое каталога «newsforyou»

Административный веб-интерфейс панели управления командным сервером был обнаружен в файле newsforyou/CP/CP.php. При открытии файла веб-браузером выдавалось приглашение ко входу в систему:

Рис. 2. Вход в панель управления

Имя пользователя и хеш-сумма пароля были позже обнаружены в локальной базе MySQL в таблице ‘settings’ (‘настройки’).

Login: username
Password hash (MD5): 27934e96d90d06818674b98bec7230fa

(ok, cracked: 900gage!@#)

Мы сбросили пароль, подменив хеш-сумму пароля, и, залогинившись, увидели, как панель выглядела для злоумышленника. Когда мы залогинились, мы были более чем удивлены.

Рис. 3. Интерфейс панели управления

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

Разработчики командного сервера не применяли и профессиональные термины, такие как бот, ботнет, заражение, статистика загрузок и т.п. Вместо этого они использовали такие общеупотребительные слова, как data (данные), upload (загрузка), client (клиент), news (новости), blog (блог), ads (реклама), backup (резервное копирование) и т.д. Мы полагаем, что это было сделано специально, чтобы сисадмины хостинговой компании ничего не заподозрили в случае внезапной проверки.

Отправить команды на заражённые системы, используя только веб-интерфейс панели управления, невозможно — это ещё одно отличие от традиционных ботнетов. Зараженные машины управлялись с помощью механизма обмена сообщениями, основанного на файлах (разработчики называли файлы ‘контейнерами данных’ — data containers).

Чтобы отослать команду или набор команд на компьютер-жертву, злоумышленник загружал на сервер особым образом сформированный архив tar.gz, который затем обрабатывался на сервере. Специальный серверный скрипт распаковывал содержимое архива и искал файлы с расширениями *.news и *.ad. Эти файлы помещались в соответствующие директории ‘news’ и ‘ads’. Командный сервер позволяет злоумышленнику отправить обновление на конкретный компьютер-жертву или сразу на все заражённые компьютеры. Есть возможность задать приоритет команды и таким образом организовать порядок выполнения команд (например, собрать все данные и только после этого осуществить самоудаление). Приоритетность и идентификационный номер клиента, соответствующий адресату, передавались нетрадиционным способом: они кодировались в названии файла, который атакующий загружал на сервер. Вот шаблон названия файла категории ‘новости’, ‘понятного’ командному серверу:

___.

Анализ исходных файлов показывает, что командный сервер понимает несколько протоколов, применяемых при обмене данными с различными клиентами:

• OldProtocol
• OldProtocolE
• SignupProtocol
• RedProtocol (упоминается, но не реализован)

При ближайшем рассмотрении этих блоков управления протоколами оказалось, что существовали четыре разных типа клиентов под кодовыми названиями SP, SPE, FL и IP.

Можем подтвердить, что вредоносная программа Flame идентифицировалась как клиент типа FL. Таким образом, существует ещё минимум три нераскрытых системы кибервооружения или средства кибершпионажа, созданных теми же авторами: SP, SPE и IP.

Рис. 4. Соответствия клиентов и протоколов, найденных на командном сервере

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

Скрипт командного сервера шифровал все файлы, полученные от клиента. Командный сервер использовал PGP-подобный механизм шифрования файлов. Во-первых, данные файлов шифровались в режиме CBC с использованием алгоритма Blowfish (со статическим вектором инициализации). Ключ Blowfish генерировался случайным образом для каждого файла. После шифрования файла ключ Blowfish шифровался открытым ключом с помощью асимметричного алгоритма шифрования из PHP-функции openssl_public_encrypt.

Параметры шифрования:

IV: 12345678

Открытый ключ OpenSSL:

——BEGIN PUBLIC KEY——
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtZslxFiR9KJE05Nhh7Xk
+lVVpD9F6AQnvZeknDiwL3SBjZB/dB/LLXtwiet8LUS6JYCXnaIq4NxW1PymwGFZ
zuc/B3p+ZAFPt06veOHOfaMAI0KDMb+laNPINvn/jJ8TfvCaUMUuMEY4sayh0xwD
MwSAazMYI8rvaaS/BqhI/6vPN6D02UIpwT1TSBVeRRoPBHuYE7A93b8vJw9sBGIp
KXZ90sgP1CjdAmCbhYelelninKdeTKCGvd5YXt86grWgEVf5WXzxXi3ZK1T4w0Yt
mNhUEAwS7zCdtZ+Ak8b0M83wAirASvPZiBl6qF8hqCT5pKkwgBG//kk8JicboLsM
VQIDAQAB
——END PUBLIC KEY——

Это гарантирует, что никто, кроме атакующего, не сможет прочитать файлы, полученные из файлового хранилища сервера, потому что только у атакующего есть частный ключ, без которого невозможно расшифровать файлы, полученные от клиентов.

Что касается функциональности, вредоносные программы-клиенты на зараженных компьютерах поддерживают всего несколько команд:

• GET_NEWS: Получает файл(ы), предназначенные для данного клиента, из поддиректории ./news. Файлы ‘новостей’ содержат обновления и дополнительные модули Flame, а также специальные команды, как например изменение значения ключа реестра.
• ADD_ENTRY: Сохраняет информацию, собранную клиентом.
• ADD_SUB_ENTRY: То же, что ADD_ENTRY.
• GET_AD: Получает файлы из директории ./ad_path. Как нам показалось, эта функция в командном сервере не работает, поскольку директории ./ad_path не существует, а вместо нее есть директория ./ads. Но при этом злоумышленник может загружать файлы в директорию ./ads через панель управления.

Мы заметили, что стандарты именования файлов и классов, используемые в скриптах, не типичны для Unix-разработчиков: каждое слово в именах переменных, функций и файлов начинается с заглавной буквы. Кроме того, есть специальные классы, которые определены, но не инстанциированы, например IProtocol (Protocol.php) и IRequestHandler (RequestHandler.php). Классы, которые неинстанциированы, т.е. для которых не создаётся ни одного экземпляра объектов, используются для механизма наследования в объектно-ориентированном программировании. В таких языках программирования, как C++, C# и Java, такие классы называются интерфейсами. Добавление заглавной буквы I в качестве префикса к именам таких классов типично для многих разработчиков в Windows C++/C#. И мы действительно увидели, как данные классы были использованы для механизма наследования.

Ники и временные метки, оставленные разработчиками в скриптах, оказались в числе наиболее ценных находок:

• @author [O] удалено in 12/3/2006
• @author [D] удалено on 12/4/2006
• @author [D] удалено on 01/23/2007
• @author [H] удалено on 09/02/2007
• @author [O] удалено, DeMo
• @author [D] удалено (modifications)
• @author modified heavily by [D] удалено
• @author [R] удалено @copyright 2011

Вот что известно об активности разработчиков:

• [D]: работал не менее чем над 31 файлом
• [H]: работал не менее чем над 10 файлами
• [O]: работал не менее чем над 4 файлами
• [R]: работал не менее чем над 1 файлом (средством удаления дублирующихся файлов)

Рис. 5. Временная шкала активности программистов, работавших над реализацией командного сервера Flame

Отсюда можем сделать вывод, что первые файлы для командного сервера были созданы 3 декабря 2006 года. Это означает, что платформа Flame гораздо старше, чем предполагалось вначале.

За разработку командного сервера отвечало четыре человека. Для нас очевидно, что один из них — [H] — был опытнее остальных: он создал несколько патчей весьма продвинутого уровня и реализовал сложную логику; по-видимому, он также является знатоком алгоритмов шифрования. Мы полагаем, что [H], скорее всего, был руководителем группы.

Операторы командного сервера использовали автоматизацию при подготовке серверной среды. Мы полагаем, что это было сделано в связи с тем, что наличие большого числа серверов не позволяло все делать вручную. Вот часть интересного скрипта (LogWiper.sh) из корневого каталога файловой системы, который остался на данном сервере:

#! /bin/bash
apt-get install -y chkconfig
#stop history
echo «unset HISTFILE» >> /etc/profile
history -c
find ~/.bash_history -exec shred -fvzu -n 3 {} ;
service rsyslog stop
chkconfig rsyslog off
service sysklogd stop
chkconfig sysklogd off
service msyslog stop
chkconfigm syslog off
service syslog-ng stop
chkconfig syslog-ng off
shred -fvzu -n 3 /var/log/wtmp
shred -fvzu -n 3 /var/log/lastlog
shred -fvzu -n 3 /var/run/utmp
shred -fvzu -n 3 /var/log/mail.*
shred -fvzu -n 3 /var/log/syslog*
shred -fvzu -n 3 /var/log/messages*
#stop logging ssh
cp /etc/ssh/aa
sed -i ‘s/LogLevel.*/LogLevel QUIET/’ /etc/ssh/sshd_config
shred -fvzu -n 3 /var/log/auth.log*
services sh restart
#delete hidden files
find / -type f -name «.*» | grep -v «.bash_profile» | grep -v «.bashrc» | grep «home» | xargs shred -fvzu -n 3
find / -type f -name «.*» | grep -v «.bash_profile» | grep -v «.bashrc» | grep «root» | xargs shred -fvzu -n 3 #stop apache2 logging
sed -i ‘s|ErrorLog [$/a-zA-Z0-9{}_.]*|ErrorLog /dev/null|g’ /etc/apache2/sites-available/default
sed -i ‘s|CustomLog [$/a-zA-Z0-9{}_.]*|CustomLog /dev/null|g’ /etc/apache2/sites-available/default
sed -i ‘s|LogLevel [$/a-zA-Z0-9{}_.]*|LogLevel emerg|g’ /etc/apache2/sites-available/default
sed -i ‘s|ErrorLog [$/a-zA-Z0-9{}_.]*|ErrorLog /dev/null|g’ /etc/apache2/sites-available/default-ssl
sed -i ‘s|CustomLog [$/a-zA-Z0-9{}_.]*|CustomLog /dev/null|g’
/etc/apache2/sites-available/default-ssl
sed -i ‘s|LogLevel [$/a-zA-Z0-9{}_.]*|LogLevel emerg|g’ /etc/apache2/sites-available/default-ssl
…

shred -fvzu -n 3 /var/log/apache2/*
service apache2 restart
#self delete
find ./ -type f | grep logging.sh | xargs -I {} shred -fvzu -n 3 {} ;

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

Chkconfig — это служебная программа для разрешения или запрещения системных служб. Chkconfig — это утилита для изменения или вывода информации об уровнях запуска системных служб. Chkconfig обрабатывает многочисленные символические ссылки в /etc/init.d/, снимая с системных администраторов часть работы по ручному редактированию символических ссылок. В Debian есть несколько инструментов, близких по функционалу, но для пользователей, мигрировавших с других дистрибутивов Linux, утилиты из данного пакета могут оказаться более привычными.

Это довольно интересно, поскольку в Debian есть много других популярных инструментов для обработки сервисов, стартующих при запуске системы: rcconf, update-rc.d, sysv-rc-conf и т.д. Инструмент chkconfig в Debian — это реализация популярного инструмента из RedHat с таким же названием. Похоже, люди, управлявшие командным сервером, более знакомы с системами RedHat. Это напомнило нам командные серверы Duqu, которые все были основаны на RedHat CentOS.

Скрипт использует общий алгоритм для остановки всех известных служб системного журнала, таких как rsyslog, sysklogd, syslog-ng, msyslog. В то время как первые три часто встречаются в системах Debian, msyslog отсутствует в официальных публичных репозиториях. Судя по всему, служба msyslog, которую поддерживает компания Core Security, может работать в операционных системах Linux, BSD, Irix, Solaris и AIX. Последняя на данный момент версия службы msyslog была выпущена 15 апреля 2003 года. Ни на одной из изученных нами систем не была установлена служба msyslog. Неясно, для чего операторам понадобилась отдельная обработка для службы msyslog.

Для уничтожения данных операторы командного сервера использовали утилиту shred. Она же использовалась командой Duqu в последних ‘зачистках’ серверов.

В конце скрипта имеется строка, удаляющая его оригинал с диска. Удаление также выполняется с помощью команды shred, однако здесь допущена ошибка: имя удаляемого файла указано как logging.sh, в то время как имя текущей версии скрипта — LogWiper.sh. Вероятно, поэтому скрипт не был удален из системы.

Системный демон cron настроен на периодическое выполнение нескольких задач:

• Каждые 30 минут: php /var/www/htdocs/newsforyou/UnloadChecker.php
• Каждые 6 часов: python /home/…/pycleaner/Eraser.py
• В полночь: php /home/…/delete.php

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

Рис. 6 — некорневая домашняя директория пользователя

LogWiper_fixed.txt это тот же файл, что описанный выше LogWiper.sh.

delete.php это PHP-скрипт, который выполнялся по расписанию для удаления файлов ‘новостей’ (news) старше 30 дней. Удаление файлов осуществлялось безопасным способом с использованием внешнего вызова системной утилиты shred. Этот скрипт также использовался для удаления метаданных файлов из базы данных.

В директории pycleanscr находились четыре файла, которые использовались процедурами автоматической очистки (удаления ‘лишних’ файлов):

Рис. 7 — директория pycleanscr

Этот скрипт был предназначен для удаления временных файлов из директории tmp на веб-сервере и должен был выполняться по расписанию. Однако из-за ошибки, допущенной авторами, скрипт ни разу не был выполнен. Задача cron была настроена на выполнение python /home/…/pycleaner/Eraser.py, в то время как правильный путь был python /home/…/pycleanscr/Eraser.py.

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

В домашней папке также находился файл RequestHandler.php, помещенный туда 14 мая 2012 года. Это говорит о том, что этот файл находился в работе у злоумышленников. Это тот же файл, что и в директории newsforyou на веб-сервере. Позже, когда мы анализировали образы других серверов, мы обнаружили, что этот файл отличается от тех, что были на других серверах. Разница состояла в том, что на соединяющиеся с сервером клиенты принудительно загружался модуль с внутренним обозначением SHREDER (он показан выше на временной шкале), если в очереди news (‘новости’) не было других модулей. SHREDER — хорошо описанный (см. блогпост Symantec) исполняемый файл Windows, в котором реализована функция самоудаления вредоносных программ, имеющих отношение к Flame.

Директория Simulator содержит специальные скрипты для стресс-тестирования командных серверов путем создания запросов, идентичных http-запросам, отправляемым самой вредоносной программой. Оператор может указать число рабочих потоков и частоту входящих запросов. Это указывает на то, что разработчики использовали для целей тестирования реальные ‘рабочие’ серверы.

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

Таким образом, даже если учесть и проанализировать содержимое сервера, можно увидеть лишь малую часть реально украденных данных. Однако из-за своей ошибки злоумышленники, потеряв связь с одним из серверов, оставили на нем набор неудаленных файлов. Это помогло нам оценить реальный объем краденных данных, которые загружались на данный командный сервер за неделю. Он составил 5,5 ГБ (в сжатом виде).

На одном из серверов злоумышленники забыли удалить HTTP-логи; это позволило нам получить представление о том, сколько жертв соединялось с сервером, отправляя POST-запросы коду командного сервера Flame:

Рис. 8 — Статистика веб-сервера, полученная из логов

В течение всего лишь одной недели (с 25 марта по 2 апреля) с сервером были установлены соединения с 5377 уникальных IP-адресов, большинство которых (3702) находилось в Иране. Вызывает удивление неожиданно большое количество (1280) суданских IP-адресов. По-видимому, проводилась кампания, целью которой были именно Иран и Судан.

Исходя из того, что всего лишь один сервер за неделю обработал данные от более 5000 жертв, а также из того, что было задействовано несколько серверов, можно сделать вывод, что общее число жертв Flame, вероятно, больше, чем считалось раньше, и превышает 10 000.

SP, SPE, FL, IP, Gauss и Stuxnet

Код, обнаруженный на командных серверах Flame, работает с 4 основными клиентами: SP, SPE, FL и IP. Наибольший интерес из этого списка, вероятно, представляет IP, который, если исходить из кодов, присвоенных клиентам, еще и самый новый:

/// Types of clients
define(‘CLIENT_TYPE_UNKNOWN’, 0);
define(‘CLIENT_TYPE_SP’, 1);
define(‘CLIENT_TYPE_SPE’, 2);
define(‘CLIENT_TYPE_FL‘, 3);
define(‘CLIENT_TYPE_IP’, 6);

Клиент IP использует протокол Signup Protocol, причем это единственный клиент, использующий данный протокол. Чтобы обнаружить ‘Signup Protocol’, код ищет определенную строку ‘uid=number&action=number’ в HTTP-запросе:

if (preg_match(‘/^uid=d+&action=d+/’, $data) === 1)
{
return array(RC_SUCCESS, PROTOCOL_SIGNUP);
}

Ответим на вопрос, который у вас, вероятно, возник: ни одна из проанализированных нами вредоносных программ не использует данную схему. Наприсер, Gauss использует запросы вида ‘POST /userhome.php?sid=string==&uid=string=’, а Stuxnet — ‘index.php?data=…’. Поэтому мы считаем, что вредоносное ПО, обозначенное как ‘IP’, не является ни Gauss, ни Stuxnet.

Кроме того, текущий код командных серверов, судя по всему, не способен обрабатывать соединения Gauss или Stuxnet.

Соединения с sinkhole-сервером от ‘SPE’

С помощью партнеров ‘Лаборатория Касперского’ настроила sinkhole-сервер для машин, зараженных Flame. Мы опубликовали статистику, полученную sinkhole-сервером, в наших предыдущих постах.

Вероятно, наибольший интерес представляет то, что, проанализировав код командных серверов Flame, мы смогли выделить две основные категории соединений с sinkhole-сервером:

• Соединения по протоколу OldProtocol, исходящие от Flame
• Соединения по протоколу OldProtocolE, используемому SPE

Таким образом, мы можем подтвердить, что в дикой среде в настоящее время существует вредоносное ПО, известное как ‘SPE’.

Кроме того, наш sinkhole-сервер не зарегистрировал соединений от таинственных вредоносных программ, обозначенных как SP и IP.

Выводы и краткие результаты анализа:

Исследование, проведенное нами совместно с нашими партнерами — Symantec, ITU-IMPACT и CERT-Bund/BSI — позволило нам получить новые данные о вредоносной программе Flame и лежащей в ее основе платформе:

• Разработка кода командных серверов в рамках данной платформы началась еще в декабре 2006 года.
• Комментарии в исходном коде свидетельствуют о том, что над проектом работало как минимум четыре программиста: [D], [O], [H] и [R].
• Последнее по времени изменение в исходном коде было сделано 18 мая 2012 года (LogWiper_fixed.txt, Constants.py).
• Код командного сервера обрабатывает запросы четырех разных вредоносных программ, обозначенных авторами как SP, SPE, FL и IP. Он также поддерживает три протокола передачи данных (OldProtocol, OldProtocolE, SignupProtocol).
• Из четырех вредоносных программ в данный момент известна только одна — Flame; остальные 3 на сегодняшний день неизвестны.
• Для передачи данных Flame использует протокол ‘OldProtocol’.
• Связанная с Flame неизвестная вредоносная программа SPE существует и активна в дикой среде.
• Flame — не самая ‘современная’ из вредоносных программ этого класса, о существовании которых мы знаем из кода, найденного на командных серверах.
• Последняя по времени создания вредоносная программа носит имя ‘IP’ и остается на сегодняшний день неизвестной.
• Код находился в процессе разработки; новый протокол, названный ‘Red Protocol’, реализован еще не полностью.

Данные, опубликованные в этом блогпосте, указывают на несколько важных фактов. Прежде всего, работа над данными проектами кибершпионажа началась раньше, чем считалось до сих пор, — еще в 2006 году. Кроме того, код, обрабатывающий запросы, сложен и активно использует шифрование. Программисты, которые его разрабатывали, старались сделать так, чтобы он выглядел как легитимная платформа для системы управления контентом (CMS). И наконец, важно то, что украденные данные шифруются на сервере с использованием криптостойких алгоритмов с открытым ключом, из-за чего прочитать их могут только сами злоумышленники. Это не характерно для вредоносных программ, созданных обычными киберпреступниками, что подтверждает наши первоначальные выводы о том, что Flame — атака, созданная при государственной поддержке.

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