Análisis completo de los servidores de comando y control de Flame

Nuestro anterior análisis sobre el programa malicioso Flame, la avanzada herramienta de ciberespionaje vinculada a la operación Stuxnet, se publicó inicialmente a finales de mayo de 2012 y reveló una campaña de amplio alcance contra varios países en el Medio Oriente.

El programa malicioso Flame, incluyendo todos sus componentes, era muy grande y nuestra incesante investigación ha revelado muchos más detalles desde entonces. Las noticias sobre esta amenaza alcanzaron su pico el 4 de junio de 2012, cuando Microsoft publicó un parche fuera de calendario para bloquear tres certificados digitales falsos publicados por Flame. El mismo día, confirmamos la existencia de esto en Flame y publicamos nuestro análisis técnico sobre este sofisticado ataque. Esta nueva faceta de Flame era tan avanzada que sólo los más reconocidos criptógrafos del mundo pudieron haberla implementado. Desde entonces, han desaparecido las bromas escépticas sobre Flame.

Más tarde, en junio, confirmamos sin lugar a dudas que los desarrolladores de Flame habían estado en contacto con el equipo de desarrollo de Stuxnet, lo que constituye otra evidencia de que Flame se desarrolló con padrinazgo estatal/nacional.
También publicamos nuestro análisis de los servidores de comando y control (C&C) de Flame en base a observaciones externas e información disponible al público. Eso nos ayudó a localizar los servidores C&C y cómo se habían registado.

En este artículo brindamos nueva información que se recolectó durante el análisis forense de los servidores de comando y control de Flame. Esta investigación se realizó de forma conjunta con Symantec, ITU-IMPACT y CERT-Bund/BSI.

Breve información sobre los servidores de C&C

• Sistema operativo: 64-bit Debian 6.0.x
• Virtualización: Por lo general funcionan con OpenVZ
• Lenguajes de programación utilizados: PHP (la mayor parte del código), Python, bash
• Base de datos: MySQL con tablas InnoDB
• Servidor web: Apache 2.x con certificados autofirmados

Análisis del servidor

Uno de los servidores de C&C que hemos analizado pertenecía a una compañía europea con centros de datos en otro país europeo. Logramos obtener una imagen del servidor que era un contenedor OpenVZ file-system
El funcionamiento con los contenedores OpenVZ file-System supuso algunas constricciones que dificultaron el análisis forense. Por ejemplo, el tener sólo contenedores OpenVZ no deja ver en el espacio perdido del disco duro para recuperar algunos archivos eliminados.

La configuración de este servidor fue una típica LAMP (Linux, Apache, MySQL, PHP). Se usó para alojar un panel de control web y para ejecutar en segundo plano algunos scripts programados y completamente automáticos.

Era accesible mediante el protocolo HTTPS, puertos 443 y8080. El directorio raíz del documento era /var/www/htdocs/ que tenía subdirectorios y scripts PHP. Aunque el sistema tenía PHP5 instalado, el código se diseñó para ejecutarse también en PHP4. Por ejemplo, /var/www/htdocs/newsforyou/Utils.php tiene la función definida “str_split” que implementa las funciones lógicas “str_split” desde PHP5, que no estaba disponible en PHP4. Los desarrolladores del código de C&C implementaron la compatibilidad con PHP4 porque no estaban seguros de cuál de las dos principales versiones de PHP se instalaría en el servidor C&C.

Figura 1 – Contenido del directorio “newsforyou”

El código del panel de control del servidor C&C se descubrió en ‘newsforyou/CP/CP.php”. Al abrirlo con un navegador mostraba una ventana de ingreso:

Figura 2 – Ingreso al panel de control

El nombre de usuario y el hash de la contraseña se encontraron después en una base de datos MySQL local en la tabla “parámetros”.

Login: username
Password hash (MD5): 27934e96d90d06818674b98bec7230fa

(ok, cracked: 900gage!@#)

Reiniciamos el hash de la contraseña e ingresamos para ver cómo era el panel desde el lado del atacante. Nuestra sorpresa fue mayúscula.

Figura 3 – Interfaz del panel de control

Nuestra primera impresión fue que el panel de control lo habían implementado script-kiddies. Parecía una versión alfa muy antigua del panel de control de un servidor de C&C de una red zombi. Sin embargo, tras revisar esta imagen una y otra vez, quedó muy claro que los atacantes escogieron a propósito esta interfaz. A diferencia de los ciberdelincuentes tradicionales que implementan interfaces web atractivas que el usuario pude reconocer fácilmente como el panel de control de una red zombi, los desarrolladores del servidor de C&C de Flame lo hicieron muy genérico y modesto.

Los desarrolladores del servidor de C&C no usaron términos profesionales como bot, red zombi, infección, malware-command, ni nada parecido en su panel de control. En lugar de ello, usaron palabras comunes como datos, cargar, descargar, cliente, noticias, blog, avisos, resguardo, etc. Creemos que esto fue así intencionalmente para engañar al administrador de sistemas de la compañía de alojamiento que podría realizar verificaciones inesperadas.

No hay forma de enviar comandos a sistemas infectados usando sólo la interfaz web del panel de C&C, y esta es otra diferencia con las redes zombi tradicionales. La máquina infectada se controlaba mediante un mecanismo de intercambio de mensajes basado en archivos (los desarrolladores llamaban a los archivos ‘contenedores de datos’).

Para enviar un comando o una serie de ellos a la víctima, el atacante cargaba un archivo tar.gz especialmente diseñado y que se procesaba en el servidor. Un script especial del servidor extraía los contenidos comprimidos y buscaba los archivos *.news y *.ad. Estos archivos se colocaban en los directorios correspondientes ‘news’ y ‘ads’. El servidor de C&C permite que el atacante inyecte una actualización a una víctima determinada, o a todas las víctimas a la vez. Es posible priorizar un comando que permite organizar un orden de comandos (por ejemplo, recopilar todos los datos y sólo después autoeliminarse). La prioridad y la identidad del cliente atacado se transferían de forma no convencional. Se almacenaban en el filename que el atacante cargaba en un servidor de C&C. Abajo mostramos la plantilla del filename news que el servidor de C&C espera:

<random_number>_<user_type>_<user_id>_<priority>.<file extension>

El análisis de los archivos fuente muestra que el servidor C&C puede entender varios protocolos de comunicación para hablar con diferentes clientes:

• OldProtocol
• OldProtocolE
• SignupProtocol
• RedProtocol (mencionado pero no implementado)

Un vistazo más profundo de estos gestores de protocolos reveló cuatro tipos distintos de clientes con nombres codificados SP, SPE, FL e IP.
Podemos confirmar que el programa malicioso Flame se identificó como un cliente tipo FL. Obviamente, esto significa que existen al menos otras tres herramientas de ciberespionaje/cibersabotaje no descubiertas creadas por los mismos autores. SP, SPE e IP.

Figura 4 – Relaciones entre clientes y protocolos detectadas en este servidor de C&C

Una sesión típica de cliente gestionada por el servidor de C&C comenzaba con el reconocimiento de la versión del protocolo, después el ingreso de la información de conexión, seguido por la decodificación de la petición del cliente y su almacenamiento codificado en el almacenamiento de archivos local. Todos los metadatos sobre los archivos recibidos desde el cliente se guardaban en una base de datos MySQL.
El script del servidor de C&C codifica todos los archivos recibidos desde el cliente. El servidor de C&C usa un mecanismo similar al PGP para codificar los archivos. Primero, los datos del archivo se codifican mediante el algoritmo Blowfish en modo CBC (con IV estática). La llave Blowfish se genera aleatoriamente para cada archivo. Después de codificar el archivo, la llave Blowfish se codifica con una llave pública usando un algoritmo de codificación asimétrica desde la función openssl_public_encrypt PHP.

Los parámetros de codificación:
IV: 12345678

Llave pública SSL:
—–BEGIN PUBLIC KEY—–
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtZslxFiR9KJE05Nhh7Xk
+lVVpD9F6AQnvZeknDiwL3SBjZB/dB/LLXtwiet8LUS6JYCXnaIq4NxW1PymwGFZ
zuc/B3p+ZAFPt06veOHOfaMAI0KDMb+laNPINvn/jJ8TfvCaUMUuMEY4sayh0xwD
MwSAazMYI8rvaaS/BqhI/6vPN6D02UIpwT1TSBVeRRoPBHuYE7A93b8vJw9sBGIp
KXZ90sgP1CjdAmCbhYelelninKdeTKCGvd5YXt86grWgEVf5WXzxXi3ZK1T4w0Yt
mNhUEAwS7zCdtZ+Ak8b0M83wAirASvPZiBl6qF8hqCT5pKkwgBG//kk8JicboLsM
VQIDAQAB
—–END PUBLIC KEY—–

Esto garantiza que nadie más que el atacante pueda leer los archivos obtenidos desde el almacenamiento de archivos del servidor, porque sólo él tiene la llave privada que es fundamental para decodificar los archivos desde los clientes.

En términos de funcionalidad, los clientes infectados aceptan muy pocos comandos:

• GET_NEWS: Obtener archivo(s) desde el subdirectorio ./news que están asignados a la actual ID del cliente. Los archivos news contienen actualizaciones y módulos adicionales de Flame, así como comandos especiales, como cambiar los valores de la llave de registro.
• ADD_ENTRY: Guarda la información recopilada por el cliente.
• ADD_SUB_ENTRY: Similar a ADD_ENTRY.
• GET_AD: Obtiene archivos desde el directorio ./ad_path. Esta funcionalidad parece que no funciona en el servidor de C&C porque en vez del directorio ./ad_path estaba el directorio ./ads. Sin embargo el atacante puede cargar archivos al directorio ./ads a través del panel de control.

Hemos notado que el sistema de nombres de archivos y clases en los scripts no es común entre los desarrolladores de Unix porque cada palabra de la variable, función y nombre de archivo comenzaba con una letra mayúscula. Asimismo, hay clases especiales que están definidas pero nunca se marcan, como IProtocol (Protocol.php) y IRequestHandler (RequestHandler.php). Las clases que nunca se marcan se usan para el mecanismo de herencia en Object Oriente Programming. Estas clases se llaman interfaces en lenguajes de programación como C++, C# y Java. Colocar una ‘I’ mayúscula como prefijo de estas clases es algo común para muchos desarrolladores Windows C++/C#.

Una de las pistas más importantes que dejaron los desarrolladores en los scripts fueron sus apodos y las fechas y horas internas:

• @author [O] censored en 3/12/2006
• @author [D] censored en 4/12/2006
• @author [D] censored en 23/01/2007
• @author [H] censored en 02/09/2007
• @author [O] censored, [D] censored
• @author [D] censored (modificaciones)
• @author muy modificado por [D] censored
• @author [R] censored @copyright 2011

Esto es lo que se sabe sobre la actividad de los desarrolladores:

• [D] censored: funcionó en al menos 31 archivos
• [H] censored: funcionó en al menos 10 archivos
• [O] censored: funcionó en al menos 4 archivos
• [R] censored: funcionó en al menos un archivo (eliminador de archivos duplicados)

Figura 5 – Cronograma de las actividades de los programadores de Flame C2

De esto podemos deducir que los dos primeros archivos del servidor de C&C se crearon el 3 de diciembre de 2006, lo que significa que la plataforma Flame es mucho más antigua de lo que creíamos en un principio.

Hubo cuatro responsables del desarrollo del servidor C&C. Es obvio que uno de ellos, [H] censored, era el más experimentado. Él codificó algunos parches muy inteligentes e implementó una compleja lógica; asimismo, parece dominar los algoritmos de codificación. Creemos que muy probablemente [H] censored era el líder del equipo.

Los operadores del servidor de C&C usaron la automatización para preparar el ambiente del servidor. Nos parece así porque tenían tantos servidores que no parecía razonable hacerlo todo manualmente. Abajo mostramos un segmento de un script muy interesante (LogWiper.sh) del directorio raíz filesystem que permaneció en el servidor actual:

#! /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 {} ;

El script de arriba se usa para preparar ambientes de servidores para que funcionen como un servidor de C&C. Limpian los registros de archivos e impiden la creación de nuevos registros. Este archivo nos da una idea de las habilidades y preferencias de los operadores del servidor de C&C. En primer lugar, vemos que los operadores instalaron y usaron chkconfig. Esta es una descripción oficial del paquete chkconfig en sistemas Debian:

Chkconfig es una herramienta de sistema que activa o desactiva los servicios del sistema. Chkconfig es una utilidad para actualizar y buscar información runlevel para los servicios del sistema. Chkconfig manipula los numerosos enlaces simbólicos en /etc/init.d/, para evitar a los administradores de sistemas el pesado trabajo de editar manualmente los enlaces simbólicos. En Debian, existen varias herramientas con funciones parecidas, pero a los usuarios que provienen de otras distribuciones Linux las herramientas de este paquete les parecerán más familiares.

Esto resulta interesante ya que Debian posee muchas otras herramientas populares para manejar los scripts start-up: rcconf, update-rc.d, sysv-rc-conf, etc. La herramienta chkconfig en Debian es una implementación de una popular herramienta RedHat con el mismo nombre. Parece que los que operaron el servidor de C&C estaban más familiarizados con los sistemas RedHat. Esto nos recuerda a los servidores de C&C de Duqu que se basaban en El misterio de Duqu: Parte VI.

El script detiene de forma genérica todos los demonios de ingreso al sistema conocidos, como rsyslog, sysklogd, syslog-ng, msyslog. Mientras que los primeros tres son comunes en los sistemas Debian, msyslog no se encuentra en repositorios públicos oficiales. Parece que msyslog tiene respaldo de la compañía Core Security, y que es capaz de ejecutarse en Linux, BSD, Irix, Solaris y AIX. La última versión del demonio msyslog se publicó el 15 de abril de 2003. Ninguno de los sistemas analizados tenía instalado el demonio msyslog. No queda claro la razón por la que los operadores tenían líneas especiales para el demonio msyslog.

Los operadores del servidor de C&C usaron la herramienta ‘shred’ (triturar) para limpiar la eliminación. También se usó en la última limpieza que hizo el equipo Duqu en su servidor.
Al final del script, hay una línea para eliminar el script original. La eliminación también se realiza con el comando ‘shred’, pero esto es un error porque el nombre del archivo ‘triturado’ es “logging.sh”, mientras que el script actual se llama LogWiper.sh, razón por la que no se lo eliminó del sistema.
El sistema cron daemon estaba configurado para ejecutar varias tareas periódicas:

• Cada 30 minutos: php /var/www/htdocs/newsforyou/UnloadChecker.php
• Cada 6 horas: python /home/…/pycleaner/Eraser.py
• A medianoche: php /home/…/delete.php

Además del directorio raíz del servidor web, había un directorio home para un usuario con un nombre de 3 símbolos. Según el análisis de los otros servidores, estos nombres ya tenían 3 símbolos escogidos aleatoriamente. Esto reveló otros archivos y directorios usados en el proyecto.

Figura 6 – directorio non-root user home

LogWiper_fixed.txt es el mismo archivo que LogWiper.sh, descrito arriba.

delete.php es un script PHP que se ejecutaba de forma programada para archivar los archivos news con una antigüedad de más de 30 días. La eliminación de los archivos se realizaba de forma segura mediante una llamada externa a la herramienta “shred’ del sistema. También manejaba la metainformación de los archivos eliminados desde la base de datos.

El directorio pycleanscrhad tenía cuatro archivos que se usaban para procedimientos automáticos de limpieza:

Figura 7 – directorio pycleanscr

Este script estaba diseñado para eliminar los archivos temporales del directorio tmp del servidor web y se ejecutaba como una tarea programada. Sin embargo, un error de los autores le impidió ejecutarse. El cronjob estaba fijado para ejecutar python /home/…/pycleaner/Eraser.py, mientras que la ruta correcta era python python /home/…/pycleanscr/Eraser.py.

Al parecer, los operadores contaban con varias variantes de scripts para controlar el uso del disco y evitar la sobrecarga del espacio en el disco.

También observamos un archivo RequestHandler.php en la carpeta home, lo que indica que estaban trabajando en este archivo. Se colocó ahí el 14 de mayo de 2012. Se trata del mismo archivo del directorio ‘newsforyou’ en el servidor web. Más tarde, cuando analizábamos otras imágenes del servidor, nos dimos cuenta de que el archivo era diferente al de otros servidores. La diferencia en este archivo radicaba en inyectar en los clientes conectados un módulo llamado internamente ‘SHREDER’ (mencionado en el cronograma de arriba) cuando no había otros módulos en la fila de ‘news’. El ‘SHREDER’ era un conocido archivo binario Windows de autoeliminación relacionado con el programa malicioso Flame (Symantec blogpost).

El directorio Simulator contiene scripts especiales para realizar pruebas de stress del servidor de C&C creando peticiones idénticas a las del programa malicioso HTTP original. El operador puede especificar el número de hilos de trabajo y la frecuencia de las peticiones entrantes. Esto indica que los desarrolladores también usaron servidores reales de ‘producción” para realizar pruebas.

Como respuesta a nuestras publicaciones anteriores, recibimos muchas preguntas relacionadas con la cantidad de datos que se filtraron mediante Flame. Esto es algo difícil de determinar si sólo se tiene acceso al programa malicioso ejecutable. Sería incluso imposible estimar esos datos teniendo acceso al servidor de C&C de Flame, ya que los operadores descargaban y eliminaban los datos robados desde el servidor de C&C cada 30 minutos. Si los scripts descargados no funcionaban por alguna razón, no era un problema, ya que había otros scripts en el servidor que controlaban la cantidad de datos guardados en el servidor. Si se llegaba al límite, se borraban los datos antiguos para liberar espacio en el disco.

Entonces, incluso si se obtiene y se analiza el contenido del servidor, sólo se verá una pequeña fracción de los datos reales que se robaron. Sin embargo, debido a un error atribuible a los atacantes, quedaron sin acceso al servidor, dejando atrás una colección de archivos que no llegaron a eliminarse. Eso ayudó a medir la cantidad real de archivos robados cargados semanalmente a este servidor de C&C: 5.5 GB (comprimidos).

En uno de los servidores, los atacantes olvidaron eliminar los registros HTTP; esto nos permitió tener una idea de la cantidad de víctimas conectadas al servidor mediante peticiones POST al código Flame C2:

Figura 8 – Estadísticas del registro del servidor web

Durante un periodo de apenas una semana (25 marzo-2 abril), se detectaron 5.377 IPs únicas conectadas al servidor, la gran mayoría en Irán: 3.702. También resulta sorprendente la gran cantidad de IPs en Sudán: 1.280. Nuestras anteriores estadísticas no mostraban un gran número de infecciones en Sudán, entonces esta debe haber sido una campaña dedicada que atacaba a sistemas en Irán y Sudán.

Si sólo un servidor manejaba más de 5.000 víctimas en un periodo de una semana, y dado que había varios servidores disponibles, podemos estimar que el número total de víctimas de Flame es probablemente mayor que el estimado anteriormente, superando las 10.000.

SP, SPE, FL, IP, Gauss y Stuxnet

El código recuperado del servidor de C&C maneja cuatro clientes principales: SP, SPE, FL e IP. De esta lista, el programa malicioso más interesante es IP, que también es el más reciente basado en la asignación de códigos de clientes:

/// 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);

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

Ninguno de los programas maliciosos que hemos analizado utiliza este esquema. Por ejemplo, Gauss usa “POST /userhome.php?sid=string==&uid=string=”. De forma similar, Stuxnet usa “index.php?data=…”. Entonces, estamos bastantes seguros de que este programa malicioso ‘IP’ no es ni Gauss ni Stuxnet.

Además, el código actual del servidor de C&C no parece capaz de manejar las conexiones de Gauss o Stuxnet.

Drenaje desde ‘SPE’

Con la colaboración de nuestros partners, Kaspersky Lab implementó un drenaje para Flame. Ya hemos publicado estadísticas de los datos del drenaje en nuestras anteriores publicaciones.

Quizás lo más interesante es que en base al código del servidor de C&C de Flame pudimos catalogar las conexiones del drenaje en dos categorías principales:

• conexiones OldProtocol provenientes de Flame
• conexiones OldProtocolE usadas por SPE

Por lo tanto, podemos confirmar que el programa malicioso conocido como ‘SPE’ existe y que circula en Internet.

Por otro lado, no hay pistas de los misteriosos programas maliciosos SP ni IP.
Conclusiones y resumen de lo aprendido:

Durante nuestra investigación conjunta con nuestros partners Symantec, ITU-IMPACT y CERT-Bund/BSI, descubrimos varias cosas que desconocíamos sobre Flame y su plataforma asociada:

• El desarrollo del código de la plataforma de C&C empezó en diciembre de 2006.
• Los comentarios sobre el código fuente indican la participación de al menos cuatro programadores: [D] censored, [O] censored, [H] censored y [R] censored.
• El cambio más reciente en el código fuente se realizó el 18 de mayo de 2012 (LogWiper_fixed.txt, Constants.py).
• El código del servidor de C&C maneja cuatro diferentes programas maliciosos que los autores llamaron SP, SPE, FL e IP. También maneja tres protocolos de comunicación (OldProtocol, OldProtocolE, SignupProtocol).
• De los cuatro programas maliciosos, sólo se conoce Flame, mientras que se desconoce de momento los otros tres.
• Para comunicaciones, Flame usa ‘OldProtocol’.
• Existe un programa malicioso relacionado con Flame, SPE, y está circulando en Internet.
• Flame no es el más ‘moderno’ de los programas malicioso conocidos por el código de C&C.
• El programa malicioso más reciente se llama “IP’ y permanece desconocido.
• El código está/estaba en desarrollo; un nuevo protocolo llamado “Red Protocol” no se ha implementado por completo todavía.

La información que se muestra en esta publicación indica varios hechos importantes. En primer lugar, el trabajo en estos proyectos de ciberespionaje comenzó antes de lo que se estimaba (en 2006). En segundo lugar, el código que maneja las peticiones es complejo y hace un uso extensivo de la codificación. Sus programadores trataron de que se parezca a una plataforma CMS legítima. Por último, pero no menos importante, los datos robados se codifican en el servidor de tal manera que sólo los atacantes pueden leerlos, por medio de una poderosa codificación de llave pública. Estas características no se encuentran normalmente en los programas maliciosos de los ciberdelincuentes corrientes, lo que refuerza muestra conclusión inicial de que Flame es un ataque patrocinado por una nación/estado.

En base al código del servidor, sabemos que Flame era uno de al menos cuatro proyectos. El propósito y la naturaleza de los otros tres se desconocen todavía.