Análise completa do Vírus Flame

Análise completa dos servidores de comando e controle do Flame

Nosso anterior análise sobre o programa malicioso Flame, da avançada ferramenta de ciberespionagem vinculada a operação Stuxnet, foi publicada inicialmente no final de maio de 2012 e revelou uma campanha de amplo alcance contra vários países do Oriente Médio.

O programa malicioso Flame, incluindo todos os seus componentes, era muito grande e nossa incessante investigação tem revelado muito mais detalhes entorno deste. As notícias sobre esta ameaça alcançou seu pico em 4 de junho de 2012, quando a Microsoft publicou um patch fora de calendário para bloquear três certificados digitais falsos publicados pelo Flame. No mesmo dia, confirmamos a existência de que era o Flame e publicamos nossa análise técnica sobre este sofisticado ataque. Esta nova faceta do Flame era tão avançada que somente os máis reconhecidos criptógrafos do mundo poderiam tê -lo implementado. Desde então, tem desaparecido piadas céticas sobre o Flame.

Mais tarde, em junho, confirmamos sem dúvidas que os desenvolvedores do Flame haviam estado em contato com a equipe de desenvolvimento do Stuxnet, pelo que constitue outra evidência de que o Flame se desenvolveu com padrocinio estatal/nacional.

Também publicamos nossa análise dos servidores de comando e controle (C&C) do Flame com base em observações externas e informações disponíveis ao publico. Isto nos ajudou a localizar os servidores C&C e como se tinha registrado.

Neste artigo fornecemos nova informação que foi recolhida durante a análise forense dos servidores de comando e controle do Flame. Esta investigação  se realizou, de forma conjunta com a Symantec, ITU-IMPACT e CERT-Bund/BSI.

Breve informacão sobre os servidores C&C

• Sistema operacional: 64-bit Debian 6.0.x
• Virtualização: Em geral funciona com OpenVZ
• Linguagens de programação utilizadas: PHP (na maior parte do código), Python, bash
• Base de dados: MySQL com tabelas InnoDB
• Servidor web: Apache 2.x com certificados auto-assinados

Análise do servidor

Um dos servidores de C$C que temos analizado pertencia a uma companhia europea  com centros de dados em outro país europeu. Conseguimos obter uma imagem do servidor que era um sistema de arquivo-container OpenVZ. Trabalhar com sistema de arquivo-container OpenVZ, significa ter algumas restrições que dificulta a análise forense. Por exemplo, os container OpenVZ não deixa ver o espaço perdido do disco rígido, que possibilita recuperar alguns arquivos apagados. A configuração deste servidor foi feito numa típica LAMP (Linux, Apache, MySQL, PHP). Foi usado para alojar um painel de controle web e para executar em segundo plano alguns scripts programados e completamente automáticos.

Era acessível mediante o protocolo HTTPS, portas 443 e 8080. O diretório raiz do documneto era /var/www/htdocs/ que tém  subdiretoŕios e scripts PHP. Embora o sistema tem PHP5 instalado, o código foi concebido para executar também PHP4. Por exemplo, /var/www/htdocs/newsforyou/Utils.php tem a função definida “str_split” que implementa as funções lógicas “str_split” do PHP5, que não estava disponível no PHP4. Os desenvolvedores do código de C&C implementara a compatibilidade com PHP4, por que não estavam seguros de qual das principais versões de PHP instalariam -se o servidor C&C.

Figura 1 – Conteúdo do diretório “newsforyou”

O código do painel de controle do servidor C&C foi descoberto em ‘newsforyou/CP/CP.php”. Ao abri -lo com um navegador mostrou uma tela de login

Figura 2 – Acesso ao painel de controle

O nome do usuário e o hash da senha encontram -se disponível na base de dados Mysql local na tabela “parámetros”.

Login: username

Password hash (MD5): 27934e96d90d06818674b98bec7230fa

(ok, cracked: 900gage!@#)

Reiniciamos o hash da senha e acessamos para ver como era o painel, a partir do lado do atacante. Nossa surpresa foi grande.

Figura 3 – Interface do painel de controle

Nossa primeira impressão foi que o painel de controle havia sido implementado por script-kiddies. parecia uma versão alfa muito antiga do painel de controle de um servidor de C&C de uma rede zumbi “botnets”. No entanto, depois de analizar esta imagem uma  e outra vez, foi muito claro que os atacantes escolheram com propósito esta interface. A diferencia dos ciberdelínquentes tradicionais que implementam interfaces web atrativas que o usuário pode reconhecer facilmente como um painel de controle de uma rede zumbi, os desenvolvedores do servidor de C&C do Flame foi muito genérico e modesto.
Os desenvolvedores do servidor de C&C não usaram termos profissionais, como bot, rede zumbi, infecção, malware-command, nem nada parecido em seu painel de controle. Em vez disso, usaram palavras comuns, como dados, carregar, descarregar, cliente, notícias, blog, avisos, guardar, etc. Nos acreditamos que foi assim, intencionalmente para enganar o administrador de sistemas da empresa de hospedagem que poderia realizar verificações inesperadas.

Não há forma de enviar comandos a sistemas infectados usando somente a interface do painel de C&C, e esta é outra diferencia com as redes zumbis tradicionais. A máquina infectada se controla mediante um mecanismo de intercmabio de mensagens baseado em arquivos (os desenvolvedores chamam os arquivos de ‘recipientes de dados’).

Para enviar um comando ou uma série deles para a vítima, o atacante carrega um arquivo tar.gz especialmente projetado e que é processado em um servidor. Um script especial do servidor extrai o conteúdo comprimido e solicita os arquivos *.news y *.ad. Estes arquivos são colocados nos diretórios correspondentes ‘news’ y ‘ads’.  O servidor de C&C permite que o atacante injete uma atualização a uma vítima determinada, ou a todas as vítimas de uma vez, É possível priorizar um comando que permite organizar uma ordem de comandos ( por exemplo, recompilar todos os dados e apenas depois excluir -se). A prioridade e a identidade do cliente atacado se tranferirá, de forma não convencional.  Foi armazenadoo um nome de arquivo que o atacante carregou em um servidor de C&C. Abaixo mostramos o novo modelo do nome de arquivo que o servidor de C&C aguarda.

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

O análise dos arquivos fontes mostra que o servidor C&C pode entender vários protocolos de comunicação para falar com diferentes clientes.

• OldProtocol
• OldProtocolE
• SignupProtocol
• RedProtocol (mencionado porém não implementado)

Numa visão mais profunda, destes manipuladores de protocolos revelou -se quatro tipos distintos de clientes com nomes codificados SP, SPE, FL e IP. Podemos confirmar que o programa malicioso Flame se identificou como um cliente tipo FL. Obviamente, isto significa que existe, pelo menos, outras três ferramentas de ciberespionagem/cibersabotagem não descobertas criadas pelo mesmos autores, SP, SPE e IP.

Figura 4 – Relacões entre clientes e protocolos detectados neste servidor de C&C

Uma sessão tpipica de cliente gerenciado por um servidor de C&C começa com o reconhecimento da versão do protocolo, depois de entrar as informações de conexão, sequida por uma decodificação de pedido do cliente e seu armazenamento codificado em um armazenamento de arquivos local. Todos os metadados sobre os arquivos recebidos desde cliente se guardam em uma base de dados Mysql.

O script do servidor de C&C codifica todos os arquivos recebidos desde cliente. O servidor de C&C usa um mecanismo similar ao PGP para codificar os arquivos. Primeiro, os dados do arquivo se codificam mediante o algoritmo Blowfish em modo CBC (com estática IV). A Chave Blowfish se gera aleatoriamente para cada arquivo. Depois de codificar o arquivo, a chave Blowfish se codifica com uma chave pública usando um algoritmo de criptografia assimétricada função openssl_public_encrypt PHP.

Os parámetros de criptografia:
IV: 12345678

Chave 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—–

Isto garante que ninguém mais que o atacante possa ler os arquivos obtidos do armazenamento de arquivos do servidor, por que só ele tem a chave privada que é fundamental para decodificar os arquivos dos clientes.

Em termos de funcionalidade, os clientes infectados aceitam muito poucos comandos.

• GET_NEWS: Obter arquivo (s) do subdiretório ./news que está atribuido ao atual  ID do cliente. Os arquivos de notícias contem atualizações e módulos adicionais do Flame, assim como comandos especiais, como mudar os valores da chave de registro.
• ADD_ENTRY: Guarda a informação coletada pelo cliente.
• ADD_SUB_ENTRY: Similar ao ADD_ENTRY.
• GET_AD: Obtem arquivos do diretório  ./ad_path. Esta funcionalidade parece que não funciona no servidor de C&C,  porque em vez do diretório ./ad_path foi o diretório ./ads. No entanto, o atacante pode fazer upload de arquivos no diretório ./ads através do painel de controle.

Temos notado que o sistema de nomes de arquivos e classes nos scripts não é comum entre os desenvolvedores de Unix, por que cada palavra da variável, função e nome de arquivo começava com uma letra maiuscula. Alé disso, há classes especiais que são definidas, porém nunca marcadas, como IProtocol (Protocol.php) y IRequestHandler (RequestHandler.php). As classes que nunca são marcadas se usam para o mecanismo de herança em Object Oriented Programming.  Estas classes são chamadas interfaces de linguagens de programação, como C++, C# y Java. Colocar um ‘I’ maiusculo como prefixo destas classes é algo comum para muitos desenvolvedores Windows C++/C#.

Uma das pistas mais importantes deixadas pelos desenvolvedores nos scripts foram seus apelidos, suas dadas e 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

Isto é o que se sabe sobre a atividade dos desenvolvedores:

• [D] censored: trabalhou em pelo menos 31 imagens
• [H] censored: trabalhou em pelo menos 10 arquivos
• [O] censored: trabalhou em pelo menos 4 arquivos
• [R] censored: trabalhou em pelo menos um arquivo (removedor de arquivos duplicados)

 

Figura 5 – Cronograma das atividades dos programadores de Flame C2

A partir disso,  podemos deduzir que os dois primeiros arquivos do servidor de C&C foi criado em 3 de dezembro de 2006, o que significa que a plataforma Flame é mais antiga do que pensavamos no início.

Havia quatro responsáveis pelo desenvolvimento do servidor C&C. E obviamente um deles, [H] censored, era o mais experiente. Ele codificou alguns patchs muito inteligentes e implementou uma complexa lógica; também parece dominar os algoritmos de criptografia. Acreditamos que é muito provável que [H] censored era o líder da equipe.

Os operadores do servidor de C&C usaram a automatização para preparar o ambiente do servidor. Concluimos assim, por que tem tantos servidores que não parecia razoavelmente accessá -los todos manualment. Abaixo mostramos um segmento de um script muito interessante  (LogWiper.sh) do diretório raíz do arquivo de sistema que permaneceu no servidor atual.

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

O script acima é utilizado para preparar ambientes de servidores para que funcione como um servidor de C&C. Limpar os registros de arquivos e impedir a criação de novos registros. Este arquivo nos dá uma idéia das habilidades e preferências dos operadores de servidor de C&C. Em primeiro lugar, vemos que os operadores instalaram e usaram chkconfig. Esta é uma descrição oficial do pacote chkconfig em sistemas Debian:

Chkconfig é uma ferramenta de sistema que ativa e desativa os serviços do sistema. Chkconfig é uma utilidade para atualizar e buscar informações runlevel para os serviços do sistema. Chkconfig manipula as numerosas ligações simbólicas (enlaces) em /etc/init.d/, para evitar aos administradores de sistemas o pesado trabalho de editar manualmente as ligações simbólicas. No Debian, existem várias ferramentas com funções parecidas, para os usuarios que provém de outras distribuições Linux as ferramentas deste pacote pareçe mais familiares.

Isto resulta o interesse de que o Debian possui muitas outras ferramentas populares para manejar os scripts start-up: rcconf, update-rc.d, sysv-rc-conf, etc. A ferramenta chkconfig no Debian é uma implementação de uma popular ferramenta RedHat com o mesmo nome. Parece que os que operam o servidor de C&C estavam mais familiarizados com os sistemas RedHat. Isto nos recorda dos servidores de C&C de Duqu que foram baseados em O Mistério de Duqu: Parte VI. Obs: Aguarde próximo artigo sobre o assunto.

O script para de forma genérica todos os demonios ( procesos do sistema que se executa en segundo plano) de entrada conhecidos, como rsyslog, sysklogd, syslog-ng, msyslog. Enquanto os três primeiros são comuns em sistemas Debian, msyslog não se encontram em repositórios públicos oficiais. Parece que msyslog tem respaldo da empresa Core Security: http://oss.coresecurity.com/projects/msyslog.html e que é capaz de executar em Linux, BSD, Irix, Solaris y AIX. A última versão do demonio msyslog foi publicada em 15 de abril de 2003. Nenhum dos sistemas analizados tinha instalado o demonio msyslog.  Não está claro, por que razão os operadores tem preferências especiais para o demonio msyslog.

Os operadores do servidor de C&C usaram a ferramenta ‘shred’ (triturar) para limpar a exclusão. Também foi usado na última limpeza que a equipe Duqu fez em seu servidor.

Ao final do script, há uma linha para excluir o script original. A exclusão tanbém se realiza com o comando ‘shred’, mas isto é um erro porque o nome do arquivo ‘excluido’  é “logging.sh”, enquanto que o script atual se chama LogWiper.sh, razão pela qual não será removido do sistema.

O sistema cron daemon foi configurado para executar várias tarefas períodicas

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

Além do diretório raíz do servidor web, havia um diretório home para um usuário com um nome de 3 símbolos,  Segundo a análise de outros servidores, nestes nomes já tinham 3 símbolos escondidos aleatoriamente. Isto revelou outros arquivos e diretorios usados no projeto.

Figura 6 – directorio non-root user home

LogWiper_fixed.txt é o mesmo arquivo que LogWiper.sh, descrito acima.

delete.php é um script PHP que se executa de forma programada para arquivar os novos arquivos com tempo de mais de 30 dias. Na remoção dos arquivos, se realiza, de forma segura mediante uma chamada externa da ferramenta “shred’ ” do sistema. Também movia a metainformação dos arquivos excluidos, deste a base de dados.

O diretório pycleanscrhad tem  quatro arquivos que são usados para procedimentos automáticos de limpeza:

Figura 7 – diretorio pycleanscr

Este script estava desenhado para eliminar os arquivos temporários do diretório tmp do servidor web e se executava como uma tarefa programada. No entanto, um erro dos autores o impedia de executar -se. O cronjob estava fixado para executar python /home/…/pycleaner/Eraser.py, enquanto que o caminho correto era python python /home/…/pycleanscr/Eraser.py.

Aparentemente, os operadores contavam com várias variantes de scripts para controlar o uso do disco e evitar a sobrecarga do espaço no disco.

Também observamos um arquivo RequestHandler.php pasta home, o que indicava que estava trabalhando com este arquivo. Foi colocado lá em 14 de maio de 2012. Se trata do mesmo arquivo do diretório ‘newsforyou’ no servidor web. Mas tarde,  quando analizamos outras imagens do servidor, nos demos conta, de que o arquivo era diferente de outros servidores. A diferença neste arquivo estava em injetar nos clientes conectados um módulo chamado internamente  ‘SHREDER’ (mencionado no cronograma acima), quando não havia outros módulos na fila de ‘news’.  O ‘SHREDER era um conhecido arquivo binário Windows de autoexclusão relacionado com o programa malicioso Flame (Symantec blogpost) – http://www.symantec.com/connect/blogs/flamer-urgent-suicide

O diretorio Simulator contém scripts especiais para realizar testes de stress no servidor de C&C criando solicitações idênticas aos do programa malicioso HTTP original. O operador pode especificar o número de tópicos de trabalho e da frequencia das solicitações entrantes. Isto indica que os desenvolvedores tanbém usaram servidores reais de ‘produção’ para realizar testes.

Como resposta a nossas publicações anteriores, recebemos muitas perguntas relacionadas com a quantidade de dados que foi filtrada mediante o Flame. Isto é algo difícil de determinar, se somente tem acesso ao programa malicioso executável. Seria mesmo, impossível estimar estes dados não tendo acesso ao servidor de C&C do Flame, já que os operadores descarregavam e eliminavam os dados roubados do servidor C&C a cada 30 minutos.  Se os scripts descarregados não funcionavam, por alguma razão, não era um problema, já que havia outros scripts no servidor que controlavam a quantidade de dados guardados no servidor. Se o limite era alcançado, apagava -se os dados antigos para liberar espaço no disco.

Então, mesmo obtido e analizado o conteúdo do servidor, só se verá uma pequena fração dos dados reais que foram roubados.  No entanto, devido a um error atribuido aos atacantes, sem acesso ao servidor, que  deixaram para trás uma quantidade de arquivos que não chegaram a excluir. Isto ajudou a medir a quantidade real de arquivos roubados e carregados semanalmente neste servidor de C&C: 5.5 GB (comprimidos)

Em um dos servidores os atacantes esqueceram de apagar os registros de HTTP; isto nos permitiu uma idéia da quantidade de vítimas conectadas no servidor mediante solicitações POST ao código Flame C2:

Figura 8 – Estatísticas do registro do servidor web

Durante um periodo de apenas uma semana (25 março-2 abril), foi detectado 5.377 IPs  únicos conectados no servidor, a grande maioria do Iran: 3.702. Também, o resultado surpreende co grande quantidade de IPs no Sudão: 1.280. Nossas estatísticas anteriores nos mostraram um grande número de infecções no Sudão, portanto isto, deve ter sido uma campanha dedicada que atacava sistemas no Irã e Sudão.

Se apenas um servidor movimentou mais de 5.000 vítimas em um período de uma semana, é fato que havia vários servidores disponíveis. podemos estimar que o número total de vítimas do Flame é provavelmente maior que o estimado anteriormente, superando a 10.000.

SP, SPE, FL, IP, Gauss e Stuxnet

O código recuperado do servidor de C&C  manipula quatro clientes principais: SP, SPE, FL e IP. Desta lista o programa malicioso mais interessante é o IP, que também é mais recente baseando na alocação 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);
}

Nenhum dos programas maliciosos que temos analizados utiliza este esquema. Por exemplo, Gauss usa “POST /userhome.php?sid=string==&uid=string=”. De forma similar, Stuxnet usa “index.php?data=…”. Portanto, estamos bastante seguros de que este programa malicioso ‘IP’ não é nem Gauss ou Stuxnet.

Além disso, o código atual do servidor de C&C não parece capaz de manipular as conexões de Gauss ou Stuxnet.

Drenagem do ‘SPE’

Com a colaborção de nossos parceiros, Kaspersky Lab imnplementou uma dreanagem para o Flame. Já temos publicado estatisticas de dados de dreanagem em nossas anteriores publicações.

Talvez, o mais interessante é que com a base de código do servidor de C&C do Flame podemos  catalogar as conexões de drenagem em duas categorias principais:

• conexões OldProtocol provinientes de Flame
• conexões OldProtocolE usadas por SPE

Portanto, podemos confirmar que o programa malicioso conhecido como ‘SPE’  existe e que circula na internet

Por outro lado, não há pistas dos misteriosos programas maliciosos SP ou IP.

Conclusão e Resumo:

Durante a nossa pesquisa em conjunto com os nossos parceiros da Symantec, ITU-IMPACT e CERT-Bund/BSI, descobrimos várias coisas que não sabiamos sobre o Flame e sua plataforma associada:

• O código de desenvolvimento da plataforma C&C começou em dezembro de 2006.
• Os comentários sobre o código fonte indicam o envolvimento de pelo menos quatro programadores: [D] censored, [O] censored, [H] censored y [R] censored.
• A mais recente mudança no código fonte foi feito em 18 de maio de 2012 (LogWiper_fixed.txt, Constants.py).
• O código do servidor de C&C manipula quatro diferentes programas maliciosos que os autores chamaram de SP, SPE, FL e IP. Também manipula tres protocolos de comunicação (OldProtocol, OldProtocolE, SignupProtocol).
• Dos quatro programas maliciosos, somente se conhece o Flame, portanto, é desconhecido no momento os outros tres.
• Para comunicações, Flame usa ‘OldProtocol’.
• Existe um programa malicioso relacionado com Flame, SPE, e  está circulando na Internet.
• Flame não é o mais ‘moderno’ dos programas maliciosos conhecido pelo código de C&C.
• O programa malicioso mais recente se chama “IP’ e permanece desconhecido.
• O código está/estava em desenvolvimento; um novo protocolo chamado “Red Protocol” não foi totalmente implementado ainda.

 

A informação apresentada nesta publicação mostra vários fatos importantes. Em primeiro lugar, o trabalho sobre estes projetos de ciberespionagem começou mais cedo do que o estimado (em 2006). Em segundo lugar, o código que manipula as solicitações é complexo e faz uso extensivo de codificacão. Seus progamadores trataram de aparecer como uma plataforma de CMS legítima. Por último, mas não menos importante, a informação roubada no servidor é codificado para que os invasores possam ler apenas por meio de uma criptografia de chave pública poderosa. Estas características não são encontradas normalmente nos programas maliciosos dos ciberdelinquentes, o que reforça nossa conclusão inicial de que o Flame é um ataque patrocinado por uma nação/estado.

Com base no código do servidor sabemos que o Flame era um, de pelo menos quatro projetos. O propósito e natureza dos outros três, ainda são desconhecidos.

Global Research & Analysis Team (GReAT), Kaspersky Lab