{"id":5242,"date":"2012-09-20T20:17:32","date_gmt":"2012-09-20T23:17:32","guid":{"rendered":"http:\/\/www.ethicalhacker.com.br\/site\/?p=5242"},"modified":"2019-07-18T12:48:33","modified_gmt":"2019-07-18T15:48:33","slug":"analise-completa-do-virus-flame","status":"publish","type":"post","link":"https:\/\/www.ethicalhacker.com.br\/site\/2012\/09\/diversos\/analise-completa-do-virus-flame\/","title":{"rendered":"An\u00e1lise completa do V\u00edrus Flame"},"content":{"rendered":"<h3 style=\"text-align: justify;\">An\u00e1lise completa dos servidores de comando e controle do Flame<\/h3>\n<p style=\"text-align: justify;\">Nosso anterior an\u00e1lise sobre o programa malicioso Flame, da avan\u00e7ada ferramenta de ciberespionagem vinculada a opera\u00e7\u00e3o Stuxnet, foi publicada inicialmente no final de maio de 2012 e revelou uma campanha de amplo alcance contra v\u00e1rios pa\u00edses do Oriente M\u00e9dio.<\/p>\n<p style=\"text-align: justify;\">O programa malicioso Flame, incluindo todos os seus componentes, era muito grande e nossa incessante investiga\u00e7\u00e3o tem revelado muito mais detalhes entorno deste. As not\u00edcias sobre esta amea\u00e7a alcan\u00e7ou seu pico em 4 de junho de 2012, quando a Microsoft publicou um patch fora de calend\u00e1rio para bloquear tr\u00eas certificados digitais falsos publicados pelo Flame. No mesmo dia, confirmamos a exist\u00eancia de que era o Flame e publicamos nossa an\u00e1lise t\u00e9cnica sobre este sofisticado ataque. Esta nova faceta do Flame era t\u00e3o avan\u00e7ada que somente os m\u00e1is reconhecidos cript\u00f3grafos do mundo poderiam t\u00ea -lo implementado. Desde ent\u00e3o, tem desaparecido piadas c\u00e9ticas sobre o Flame.<\/p>\n<p style=\"text-align: justify;\">Mais tarde, em junho, confirmamos sem d\u00favidas que os desenvolvedores do Flame haviam estado em contato com a equipe de desenvolvimento do Stuxnet, pelo que constitue outra evid\u00eancia de que o Flame se desenvolveu com padrocinio estatal\/nacional.<\/p>\n<p style=\"text-align: justify;\">Tamb\u00e9m publicamos nossa an\u00e1lise dos servidores de comando e controle (C&amp;C) do Flame com base em observa\u00e7\u00f5es externas e informa\u00e7\u00f5es dispon\u00edveis ao publico. Isto nos ajudou a localizar os servidores C&amp;C e como se tinha registrado.<\/p>\n<p style=\"text-align: justify;\">Neste artigo fornecemos nova informa\u00e7\u00e3o que foi recolhida durante a an\u00e1lise forense dos servidores de comando e controle do Flame. Esta investiga\u00e7\u00e3o\u00a0 se realizou, de forma conjunta com a Symantec, ITU-IMPACT e CERT-Bund\/BSI.<\/p>\n<h3 style=\"text-align: justify;\">Breve informac\u00e3o sobre os servidores C&amp;C<\/h3>\n<ul style=\"text-align: justify;\">\n<li>Sistema operacional: 64-bit Debian 6.0.x<\/li>\n<li>Virtualiza\u00e7\u00e3o: Em geral funciona com OpenVZ<\/li>\n<li>Linguagens de programa\u00e7\u00e3o utilizadas: PHP (na maior parte do c\u00f3digo), Python, bash<\/li>\n<li>Base de dados: MySQL com tabelas InnoDB<\/li>\n<li>Servidor web: Apache 2.x com certificados auto-assinados<\/li>\n<\/ul>\n<h3 style=\"text-align: justify;\">An\u00e1lise do servidor<\/h3>\n<p style=\"text-align: justify;\">Um dos servidores de C$C que temos analizado pertencia a uma companhia europea\u00a0 com centros de dados em outro pa\u00eds europeu. <span id=\"result_box\" lang=\"pt\"><span class=\"hps\">Conseguimos<\/span> <span class=\"hps\">obter uma imagem<\/span> <span class=\"hps\">do servidor<\/span> <span class=\"hps\">que era<\/span> <span class=\"hps\">um <\/span><\/span><span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\">sistema de arquivo-<\/span><\/span><\/span>container <span class=\"hps\">OpenVZ.<span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" class=\"hps\" lang=\"pt\"><span class=\"hps\"> Trabalhar com<\/span> <span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\">sistema de arquivo-<\/span><\/span><\/span>container <span class=\"hps\">OpenVZ<\/span><\/span><\/span><\/span><\/span><\/span><\/span><span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\">, <\/span><span class=\"hps\">significa<\/span> ter <span class=\"hps\">algumas restri\u00e7\u00f5es<\/span> que dificulta a an\u00e1lise forense. <span id=\"result_box\" lang=\"pt\"><span class=\"hps\">Por exemplo<\/span>, os container <span class=\"hps\">OpenVZ<\/span> n\u00e3o deixa ver o espa\u00e7o perdido do disco r\u00edgido, que possibilita <span class=\"hps\">recuperar alguns<\/span> <span class=\"hps\">arquivos apagados. A configura\u00e7\u00e3o deste servidor foi feito numa t\u00edpica 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\u00e1ticos.<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n<p style=\"text-align: justify;\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\"><span id=\"result_box\" lang=\"pt\"><span id=\"result_box\" lang=\"pt\"><span class=\"hps\">Era acess\u00edvel mediante o protocolo HTTPS, portas 443 e 8080. O diret\u00f3rio raiz do documneto era \/var\/www\/htdocs\/ que t\u00e9m\u00a0 subdireto\u0155ios e scripts PHP. Embora o sistema tem PHP5 instalado, o c\u00f3digo foi concebido para executar tamb\u00e9m PHP4. Por exemplo, \/var\/www\/htdocs\/newsforyou\/Utils.php tem a fun\u00e7\u00e3o definida &#8220;str_split&#8221; que implementa as fun\u00e7\u00f5es l\u00f3gicas &#8220;str_split&#8221; do PHP5, que n\u00e3o estava dispon\u00edvel no PHP4. Os desenvolvedores do c\u00f3digo de C&amp;C implementara a compatibilidade com PHP4, por que n\u00e3o estavam seguros de qual das principais vers\u00f5es de PHP instalariam -se o servidor C&amp;C.<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/751.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-5244 aligncenter\" title=\"751\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/751.jpg\"  alt=\"\" width=\"497\" height=\"376\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/751.jpg 497w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/751-300x226.jpg 300w\" sizes=\"auto, (max-width: 497px) 100vw, 497px\" \/><\/a><\/p>\n<table style=\"width: 1px; height: 17px;\" border=\"0\" cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr bgcolor=\"#f7f7f7\">\n<td nowrap=\"nowrap\"><\/td>\n<td nowrap=\"nowrap\"><\/td>\n<td align=\"right\" nowrap=\"nowrap\" width=\"100%\"><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p style=\"text-align: center;\"><strong>Figura 1 &#8211; Conte\u00fado do diret\u00f3rio &#8220;newsforyou&#8221;<\/strong><\/p>\n<p style=\"text-align: justify;\">O c\u00f3digo do painel de controle do servidor C&amp;C foi descoberto em &#8216;newsforyou\/CP\/CP.php&#8221;. Ao abri -lo com um navegador mostrou uma tela de login<\/p>\n<p style=\"text-align: center;\"><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/752.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5246 aligncenter\" title=\"752\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/752.jpg\"  alt=\"\" width=\"334\" height=\"219\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/752.jpg 334w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/752-300x196.jpg 300w\" sizes=\"auto, (max-width: 334px) 100vw, 334px\" \/><\/a><strong>Figura 2 &#8211; Acesso ao painel de controle<\/strong><\/p>\n<p style=\"text-align: justify;\">O nome do usu\u00e1rio e o hash da senha encontram -se dispon\u00edvel na base de dados Mysql local na tabela &#8220;par\u00e1metros&#8221;.<\/p>\n<p style=\"text-align: justify;\">Login: username<\/p>\n<p style=\"text-align: justify;\">Password hash (MD5): 27934e96d90d06818674b98bec7230fa<\/p>\n<p style=\"text-align: justify;\"><strong>(ok, cracked: 900gage!@#)<\/strong><\/p>\n<p style=\"text-align: justify;\">Reiniciamos o hash da senha e acessamos para ver como era o painel, a partir do lado do atacante. Nossa surpresa foi grande.<\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/753.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5247 aligncenter\" title=\"753\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/753.jpg\"  alt=\"\" width=\"597\" height=\"304\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/753.jpg 597w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/753-300x152.jpg 300w\" sizes=\"auto, (max-width: 597px) 100vw, 597px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figura 3 &#8211; Interface do painel de controle<\/strong><\/p>\n<p style=\"text-align: justify;\">Nossa primeira impress\u00e3o foi que o painel de controle havia sido implementado por script-kiddies. parecia uma vers\u00e3o alfa muito antiga do painel de controle de um servidor de C&amp;C de uma rede zumbi \u201cbotnets\u201d. No entanto, depois de analizar esta imagem uma\u00a0 e outra vez, foi muito claro que os atacantes escolheram com prop\u00f3sito esta interface. A diferencia dos ciberdel\u00ednquentes tradicionais que implementam interfaces web atrativas que o usu\u00e1rio pode reconhecer facilmente como um painel de controle de uma rede zumbi, os desenvolvedores do servidor de C&amp;C do Flame foi muito gen\u00e9rico e modesto.<br \/>\nOs desenvolvedores do servidor de C&amp;C n\u00e3o usaram termos profissionais, como bot, rede zumbi, infec\u00e7\u00e3o, malware-command, nem nada parecido em seu painel de controle. Em vez disso, usaram palavras comuns, como dados, carregar, descarregar, cliente, not\u00edcias, blog, avisos, guardar, etc. Nos acreditamos que foi assim, intencionalmente para enganar o administrador de sistemas da empresa de hospedagem que poderia realizar verifica\u00e7\u00f5es inesperadas.<\/p>\n<p style=\"text-align: justify;\">N\u00e3o h\u00e1 forma de enviar comandos a sistemas infectados usando somente a interface do painel de C&amp;C, e esta \u00e9 outra diferencia com as redes zumbis tradicionais. A m\u00e1quina infectada se controla mediante um mecanismo de intercmabio de mensagens baseado em arquivos (os desenvolvedores chamam os arquivos de &#8216;recipientes de dados&#8217;).<\/p>\n<p style=\"text-align: justify;\">Para enviar um comando ou uma s\u00e9rie deles para a v\u00edtima, o atacante carrega um arquivo tar.gz especialmente projetado e que \u00e9 processado em um servidor. Um script especial do servidor extrai o conte\u00fado comprimido e solicita os arquivos *.news y *.ad. Estes arquivos s\u00e3o colocados nos diret\u00f3rios correspondentes &#8216;news&#8217; y &#8216;ads&#8217;.\u00a0 O servidor de C&amp;C permite que o atacante injete uma atualiza\u00e7\u00e3o a uma v\u00edtima determinada, ou a todas as v\u00edtimas de uma vez, \u00c9 poss\u00edvel 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\u00e1, de forma n\u00e3o convencional.\u00a0 Foi armazenadoo um nome de arquivo que o atacante carregou em um servidor de C&amp;C. Abaixo mostramos o novo modelo do nome de arquivo que o servidor de C&amp;C aguarda.<\/p>\n<p style=\"text-align: justify;\">&lt;random_number&gt;_&lt;user_type&gt;_&lt;user_id&gt;_&lt;priority&gt;.&lt;file extension&gt;<\/p>\n<p style=\"text-align: justify;\">O an\u00e1lise dos arquivos fontes mostra que o servidor C&amp;C pode entender v\u00e1rios protocolos de comunica\u00e7\u00e3o para falar com diferentes clientes.<\/p>\n<ul style=\"text-align: justify;\">\n<li>OldProtocol<\/li>\n<li>OldProtocolE<\/li>\n<li>SignupProtocol<\/li>\n<li>RedProtocol (mencionado por\u00e9m n\u00e3o implementado)<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Numa vis\u00e3o 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\u00eas ferramentas de ciberespionagem\/cibersabotagem n\u00e3o descobertas criadas pelo mesmos autores, SP, SPE e IP.<\/p>\n<p style=\"text-align: center;\"><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/754.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5248 aligncenter\" title=\"754\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/754.jpg\"  alt=\"\" width=\"600\" height=\"469\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/754.jpg 600w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/754-300x234.jpg 300w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/a><strong>Figura 4 &#8211; Relac\u00f5es entre clientes e protocolos detectados neste servidor de C&amp;C <\/strong><\/p>\n<p style=\"text-align: justify;\">Uma sess\u00e3o tpipica de cliente gerenciado por um servidor de C&amp;C come\u00e7a com o reconhecimento da vers\u00e3o do protocolo, depois de entrar as informa\u00e7\u00f5es de conex\u00e3o, sequida por uma decodifica\u00e7\u00e3o 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.<\/p>\n<p style=\"text-align: justify;\">O script do servidor de C&amp;C codifica todos os arquivos recebidos desde cliente. O servidor de C&amp;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\u00e1tica IV). A Chave Blowfish se gera aleatoriamente para cada arquivo. Depois de codificar o arquivo, a chave Blowfish se codifica com uma chave p\u00fablica usando um algoritmo de criptografia assim\u00e9tricada fun\u00e7\u00e3o openssl_public_encrypt PHP.<\/p>\n<p style=\"text-align: justify;\">Os par\u00e1metros de criptografia:<br \/>\nIV: 12345678<\/p>\n<p style=\"text-align: justify;\">Chave p\u00fablica SSL:<br \/>\n&#8212;&#8211;BEGIN PUBLIC KEY&#8212;&#8211;<br \/>\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtZslxFiR9KJE05Nhh7Xk<br \/>\n+lVVpD9F6AQnvZeknDiwL3SBjZB\/dB\/LLXtwiet8LUS6JYCXnaIq4NxW1PymwGFZ<br \/>\nzuc\/B3p+ZAFPt06veOHOfaMAI0KDMb+laNPINvn\/jJ8TfvCaUMUuMEY4sayh0xwD<br \/>\nMwSAazMYI8rvaaS\/BqhI\/6vPN6D02UIpwT1TSBVeRRoPBHuYE7A93b8vJw9sBGIp<br \/>\nKXZ90sgP1CjdAmCbhYelelninKdeTKCGvd5YXt86grWgEVf5WXzxXi3ZK1T4w0Yt<br \/>\nmNhUEAwS7zCdtZ+Ak8b0M83wAirASvPZiBl6qF8hqCT5pKkwgBG\/\/kk8JicboLsM<br \/>\nVQIDAQAB<br \/>\n&#8212;&#8211;END PUBLIC KEY&#8212;&#8211;<\/p>\n<p style=\"text-align: justify;\">Isto garante que ningu\u00e9m mais que o atacante possa ler os arquivos obtidos do armazenamento de arquivos do servidor, por que s\u00f3 ele tem a chave privada que \u00e9 fundamental para decodificar os arquivos dos clientes.<\/p>\n<p style=\"text-align: justify;\">Em termos de funcionalidade, os clientes infectados aceitam muito poucos comandos.<\/p>\n<ul style=\"text-align: justify;\">\n<li>GET_NEWS: Obter arquivo (s) do subdiret\u00f3rio .\/news que est\u00e1 atribuido ao atual\u00a0 ID do cliente. Os arquivos de not\u00edcias contem atualiza\u00e7\u00f5es e m\u00f3dulos adicionais do Flame, assim como comandos especiais, como mudar os valores da chave de registro.<\/li>\n<li>ADD_ENTRY: Guarda a informa\u00e7\u00e3o coletada pelo cliente.<\/li>\n<li>ADD_SUB_ENTRY: Similar ao ADD_ENTRY.<\/li>\n<li>GET_AD: Obtem arquivos do diret\u00f3rio\u00a0 .\/ad_path. Esta funcionalidade parece que n\u00e3o funciona no servidor de C&amp;C,\u00a0 porque em vez do diret\u00f3rio .\/ad_path foi o diret\u00f3rio .\/ads. No entanto, o atacante pode fazer upload de arquivos no diret\u00f3rio .\/ads atrav\u00e9s do painel de controle.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Temos notado que o sistema de nomes de arquivos e classes nos scripts n\u00e3o \u00e9 comum entre os desenvolvedores de Unix, por que cada palavra da vari\u00e1vel, fun\u00e7\u00e3o e nome de arquivo come\u00e7ava com uma letra maiuscula. Al\u00e9 disso, h\u00e1 classes especiais que s\u00e3o definidas, por\u00e9m nunca marcadas, como IProtocol (Protocol.php) y IRequestHandler (RequestHandler.php). As classes que nunca s\u00e3o marcadas se usam para o mecanismo de heran\u00e7a em Object <strong>O<\/strong>riented Programming.\u00a0 Estas classes s\u00e3o chamadas interfaces de linguagens de programa\u00e7\u00e3o, como C++, C# y Java. Colocar um &#8216;I&#8217; maiusculo como prefixo destas classes \u00e9 algo comum para muitos desenvolvedores Windows C++\/C#.<\/p>\n<p style=\"text-align: justify;\">Uma das pistas mais importantes deixadas pelos desenvolvedores nos scripts foram seus apelidos, suas dadas e horas internas:<\/p>\n<ul style=\"text-align: justify;\">\n<li>@author [O] censored en 3\/12\/2006<\/li>\n<li>@author [D] censored en 4\/12\/2006<\/li>\n<li>@author [D] censored en 23\/01\/2007<\/li>\n<li>@author [H] censored en 02\/09\/2007<\/li>\n<li>@author [O] censored, [D] censored<\/li>\n<li>@author [D] censored (modificaciones)<\/li>\n<li>@author muy modificado por [D] censored<\/li>\n<li>@author [R] censored @copyright 2011<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Isto \u00e9 o que se sabe sobre a atividade dos desenvolvedores:<\/p>\n<ul style=\"text-align: justify;\">\n<li>[D] censored: trabalhou em pelo menos 31 imagens<\/li>\n<li>[H] censored: trabalhou em pelo menos 10 arquivos<\/li>\n<li>[O] censored: trabalhou em pelo menos 4 arquivos<\/li>\n<li>[R] censored: trabalhou em pelo menos um arquivo (removedor de arquivos duplicados)<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/755.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5250 aligncenter\" title=\"755\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/755.jpg\"  alt=\"\" width=\"600\" height=\"381\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/755.jpg 600w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/755-300x190.jpg 300w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figura 5 &#8211; Cronograma das atividades dos programadores de Flame C2 <\/strong><\/p>\n<p style=\"text-align: justify;\">A partir disso,\u00a0 podemos deduzir que os dois primeiros arquivos do servidor de C&amp;C foi criado em 3 de dezembro de 2006, o que significa que a plataforma Flame \u00e9 mais antiga do que pensavamos no in\u00edcio.<\/p>\n<p style=\"text-align: justify;\">Havia quatro respons\u00e1veis pelo desenvolvimento do servidor C&amp;C. E obviamente um deles, [H] censored, era o mais experiente. Ele codificou alguns patchs muito inteligentes e implementou uma complexa l\u00f3gica; tamb\u00e9m parece dominar os algoritmos de criptografia. Acreditamos que \u00e9 muito prov\u00e1vel que [H] censored era o l\u00edder da equipe.<\/p>\n<p style=\"text-align: justify;\">Os operadores do servidor de C&amp;C usaram a automatiza\u00e7\u00e3o para preparar o ambiente do servidor. Concluimos assim, por que tem tantos servidores que n\u00e3o parecia razoavelmente access\u00e1 -los todos manualment. Abaixo mostramos um segmento de um script muito interessante\u00a0 (LogWiper.sh) do diret\u00f3rio ra\u00edz do arquivo de sistema que permaneceu no servidor atual.<\/p>\n<p style=\"text-align: justify;\">#! \/bin\/bash<\/p>\n<p>apt-get install -y chkconfig<\/p>\n<p>#stop history<\/p>\n<p>echo &#8220;unset HISTFILE&#8221; &gt;&gt; \/etc\/profile<\/p>\n<p>history -c<\/p>\n<p>find ~\/.bash_history -exec shred -fvzu -n 3 {} \\;<\/p>\n<p>service rsyslog stop<\/p>\n<p>chkconfig rsyslog off<\/p>\n<p>service sysklogd stop<\/p>\n<p>chkconfig sysklogd off<\/p>\n<p>service msyslog stop<\/p>\n<p>chkconfigm syslog off<\/p>\n<p>service syslog-ng stop<\/p>\n<p>chkconfig syslog-ng off<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/wtmp<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/lastlog<\/p>\n<p>shred -fvzu -n 3 \/var\/run\/utmp<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/mail.*<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/syslog*<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/messages*<\/p>\n<p>#stop logging ssh<\/p>\n<p>cp \/etc\/ssh\/aa<\/p>\n<p>sed -i &#8216;s\/LogLevel.*\/LogLevel QUIET\/&#8217; \/etc\/ssh\/sshd_config<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/auth.log*<\/p>\n<p>services sh restart<\/p>\n<p>#delete hidden files<\/p>\n<p>find \/ -type f -name &#8220;.*&#8221; | grep -v &#8220;.bash_profile&#8221; | grep -v &#8220;.bashrc&#8221; | grep &#8220;home&#8221; | xargs shred -fvzu -n 3<\/p>\n<p>find \/ -type f -name &#8220;.*&#8221; | grep -v &#8220;.bash_profile&#8221; | grep -v &#8220;.bashrc&#8221; | grep &#8220;root&#8221; | xargs shred -fvzu -n 3 #stop apache2 logging<\/p>\n<p>sed -i &#8216;s|ErrorLog [$\/a-zA-Z0-9{}_.]*|ErrorLog \/dev\/null|g&#8217; \/etc\/apache2\/sites-available\/default<br \/>\nsed -i &#8216;s|CustomLog [$\/a-zA-Z0-9{}_.]*|CustomLog \/dev\/null|g&#8217; \/etc\/apache2\/sites-available\/default<\/p>\n<p>sed -i &#8216;s|LogLevel [$\/a-zA-Z0-9{}_.]*|LogLevel emerg|g&#8217; \/etc\/apache2\/sites-available\/default<\/p>\n<p>sed -i &#8216;s|ErrorLog [$\/a-zA-Z0-9{}_.]*|ErrorLog \/dev\/null|g&#8217; \/etc\/apache2\/sites-available\/default-ssl<\/p>\n<p>sed -i &#8216;s|CustomLog [$\/a-zA-Z0-9{}_.]*|CustomLog \/dev\/null|g&#8217;<br \/>\n\/etc\/apache2\/sites-available\/default-ssl<\/p>\n<p>sed -i &#8216;s|LogLevel [$\/a-zA-Z0-9{}_.]*|LogLevel emerg|g&#8217; \/etc\/apache2\/sites-available\/default-ssl<\/p>\n<p>&#8230;<\/p>\n<p>shred -fvzu -n 3 \/var\/log\/apache2\/*<br \/>\nservice apache2 restart<\/p>\n<p><strong>#self delete<\/strong><\/p>\n<p>find .\/ -type f | grep logging.sh | xargs -I {} shred -fvzu -n 3 {} \\;<\/p>\n<p style=\"text-align: justify;\">O script acima \u00e9 utilizado para preparar ambientes de servidores para que funcione como um servidor de C&amp;C. Limpar os registros de arquivos e impedir a cria\u00e7\u00e3o de novos registros. Este arquivo nos d\u00e1 uma id\u00e9ia das habilidades e prefer\u00eancias dos operadores de servidor de C&amp;C. Em primeiro lugar, vemos que os operadores instalaram e usaram chkconfig. Esta \u00e9 uma descri\u00e7\u00e3o oficial do pacote chkconfig em sistemas Debian:<\/p>\n<p style=\"text-align: justify;\">Chkconfig \u00e9 uma ferramenta de sistema que ativa e desativa os servi\u00e7os do sistema. Chkconfig \u00e9 uma utilidade para atualizar e buscar informa\u00e7\u00f5es runlevel para os servi\u00e7os do sistema. Chkconfig manipula as numerosas liga\u00e7\u00f5es simb\u00f3licas (enlaces) em \/etc\/init.d\/, para evitar aos administradores de sistemas o pesado trabalho de editar manualmente as liga\u00e7\u00f5es simb\u00f3licas. No Debian, existem v\u00e1rias ferramentas com fun\u00e7\u00f5es parecidas, para os usuarios que prov\u00e9m de outras distribui\u00e7\u00f5es Linux as ferramentas deste pacote pare\u00e7e mais familiares.<\/p>\n<p style=\"text-align: justify;\">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 \u00e9 uma implementa\u00e7\u00e3o de uma popular ferramenta RedHat com o mesmo nome. Parece que os que operam o servidor de C&amp;C estavam mais familiarizados com os sistemas RedHat. Isto nos recorda dos servidores de C&amp;C de Duqu que foram baseados em O Mist\u00e9rio de Duqu: Parte VI. Obs: Aguarde pr\u00f3ximo artigo sobre o assunto.<\/p>\n<p style=\"text-align: justify;\">O script para de forma gen\u00e9rica todos os demonios ( procesos do sistema que se executa en segundo plano) de entrada conhecidos, como rsyslog, sysklogd, syslog-ng, msyslog. Enquanto os tr\u00eas primeiros s\u00e3o comuns em sistemas Debian, msyslog n\u00e3o se encontram em reposit\u00f3rios p\u00fablicos oficiais. Parece que msyslog tem respaldo da empresa Core Security:<a href=\"http:\/\/oss.coresecurity.com\/projects\/msyslog.html\" target=\"_blank\" rel=\"noopener noreferrer\"> http:\/\/oss.coresecurity.com\/projects\/msyslog.html<\/a> e que \u00e9 capaz de executar em Linux, BSD, Irix, Solaris y AIX. A \u00faltima vers\u00e3o do demonio msyslog foi publicada em 15 de abril de 2003. Nenhum dos sistemas analizados tinha instalado o demonio msyslog.\u00a0 N\u00e3o est\u00e1 claro, por que raz\u00e3o os operadores tem prefer\u00eancias especiais para o demonio msyslog.<\/p>\n<p style=\"text-align: justify;\">Os operadores do servidor de C&amp;C usaram a ferramenta &#8216;shred&#8217; (triturar) para limpar a exclus\u00e3o. Tamb\u00e9m foi usado na \u00faltima limpeza que a equipe Duqu fez em seu servidor.<\/p>\n<p style=\"text-align: justify;\">Ao final do script, h\u00e1 uma linha para excluir o script original. A exclus\u00e3o tanb\u00e9m se realiza com o comando &#8216;shred&#8217;, mas isto \u00e9 um erro porque o nome do arquivo &#8216;excluido&#8217;\u00a0 \u00e9 &#8220;logging.sh&#8221;, enquanto que o script atual se chama LogWiper.sh, raz\u00e3o pela qual n\u00e3o ser\u00e1 removido do sistema.<\/p>\n<p style=\"text-align: justify;\">O sistema cron daemon foi configurado para executar v\u00e1rias tarefas per\u00edodicas<\/p>\n<ul style=\"text-align: justify;\">\n<li>Cada 30 minutos: php \/var\/www\/htdocs\/newsforyou\/UnloadChecker.php<\/li>\n<li>Cada 6 horas: python \/home\/&#8230;\/pycleaner\/Eraser.py<\/li>\n<li>A meia-noite: php \/home\/&#8230;\/delete.php<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Al\u00e9m do diret\u00f3rio ra\u00edz do servidor web, havia um diret\u00f3rio home para um usu\u00e1rio com um nome de 3 s\u00edmbolos,\u00a0 Segundo a an\u00e1lise de outros servidores, nestes nomes j\u00e1 tinham 3 s\u00edmbolos escondidos aleatoriamente. Isto revelou outros arquivos e diretorios usados no projeto.<\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/756.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5251 aligncenter\" title=\"756\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/756.jpg\"  alt=\"\" width=\"441\" height=\"98\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/756.jpg 441w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/756-300x66.jpg 300w\" sizes=\"auto, (max-width: 441px) 100vw, 441px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figura 6 &#8211; directorio non-root user home <\/strong><\/p>\n<p style=\"text-align: justify;\"><strong>LogWiper_fixed.txt \u00e9 o mesmo arquivo que LogWiper.sh, descrito acima.<\/strong><\/p>\n<p style=\"text-align: justify;\">delete.php \u00e9 um script PHP que se executa de forma programada para arquivar os novos arquivos com tempo de mais de 30 dias. Na remo\u00e7\u00e3o dos arquivos, se realiza, de forma segura mediante uma chamada externa da ferramenta &#8220;shred&#8217; &#8221; do sistema. Tamb\u00e9m movia a metainforma\u00e7\u00e3o dos arquivos excluidos, deste a base de dados.<\/p>\n<p style=\"text-align: justify;\">O diret\u00f3rio pycleanscrhad tem\u00a0 quatro arquivos que s\u00e3o usados para procedimentos autom\u00e1ticos de limpeza:<\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/757.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5252 aligncenter\" title=\"757\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/757.jpg\"  alt=\"\" width=\"399\" height=\"84\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/757.jpg 399w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/757-300x63.jpg 300w\" sizes=\"auto, (max-width: 399px) 100vw, 399px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figura 7 &#8211; diretorio pycleanscr<\/strong><\/p>\n<p style=\"text-align: justify;\">Este script estava desenhado para eliminar os arquivos tempor\u00e1rios do diret\u00f3rio 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\/&#8230;\/pycleaner\/Eraser.py, enquanto que o caminho correto era python python \/home\/&#8230;\/<strong>pycleanscr<\/strong>\/Eraser.py.<\/p>\n<p style=\"text-align: justify;\">Aparentemente, os operadores contavam com v\u00e1rias variantes de scripts para controlar o uso do disco e evitar a sobrecarga do espa\u00e7o no disco.<\/p>\n<p style=\"text-align: justify;\">Tamb\u00e9m observamos um arquivo RequestHandler.php pasta home, o que indicava que estava trabalhando com este arquivo. Foi colocado l\u00e1 em 14 de maio de 2012. Se trata do mesmo arquivo do diret\u00f3rio &#8216;newsforyou&#8217; no servidor web. Mas tarde,\u00a0 quando analizamos outras imagens do servidor, nos demos conta, de que o arquivo era diferente de outros servidores. A diferen\u00e7a neste arquivo estava em injetar nos clientes conectados um m\u00f3dulo chamado internamente\u00a0 &#8216;SHREDER&#8217; (mencionado no cronograma acima), quando n\u00e3o havia outros m\u00f3dulos na fila de\u00a0&#8216;news&#8217;.\u00a0 O &#8216;SHREDER era um conhecido arquivo bin\u00e1rio Windows de autoexclus\u00e3o relacionado com o programa malicioso Flame (Symantec blogpost) &#8211;\u00a0<a href=\"http:\/\/www.symantec.com\/connect\/blogs\/flamer-urgent-suicide\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/www.symantec.com\/connect\/blogs\/flamer-urgent-suicide<\/a><\/p>\n<p style=\"text-align: justify;\">O diretorio Simulator cont\u00e9m scripts especiais para realizar testes de stress no servidor de C&amp;C criando solicita\u00e7\u00f5es id\u00eanticas aos do programa malicioso HTTP original. O operador pode especificar o n\u00famero de t\u00f3picos de trabalho e da frequencia das solicita\u00e7\u00f5es entrantes. Isto indica que os desenvolvedores tanb\u00e9m usaram servidores reais de &#8216;produ\u00e7\u00e3o&#8217; para realizar testes.<\/p>\n<p style=\"text-align: justify;\">Como resposta a nossas publica\u00e7\u00f5es anteriores, recebemos muitas perguntas relacionadas com a quantidade de dados que foi filtrada mediante o Flame. Isto \u00e9 algo dif\u00edcil de determinar, se somente tem acesso ao programa malicioso execut\u00e1vel. Seria mesmo, imposs\u00edvel estimar estes dados n\u00e3o tendo acesso ao servidor de C&amp;C do Flame, j\u00e1 que os operadores descarregavam e eliminavam os dados roubados do servidor C&amp;C a cada 30 minutos.\u00a0 Se os scripts descarregados n\u00e3o funcionavam, por alguma raz\u00e3o, n\u00e3o era um problema, j\u00e1 que havia outros scripts no servidor que controlavam a quantidade de dados guardados no servidor. Se o limite era alcan\u00e7ado, apagava -se os dados antigos para liberar espa\u00e7o no disco.<\/p>\n<p style=\"text-align: justify;\">Ent\u00e3o, mesmo obtido e analizado o conte\u00fado do servidor, s\u00f3 se ver\u00e1 uma pequena fra\u00e7\u00e3o dos dados reais que foram roubados.\u00a0 No entanto, devido a um error atribuido aos atacantes, sem acesso ao servidor, que\u00a0 deixaram para tr\u00e1s uma quantidade de arquivos que n\u00e3o chegaram a excluir. Isto ajudou a medir a quantidade real de arquivos roubados e carregados semanalmente neste servidor de C&amp;C: 5.5 GB (comprimidos)<\/p>\n<p style=\"text-align: justify;\">Em um dos servidores os atacantes esqueceram de apagar os registros de HTTP; isto nos permitiu uma id\u00e9ia da quantidade de v\u00edtimas conectadas no servidor mediante solicita\u00e7\u00f5es POST ao c\u00f3digo Flame C2:<\/p>\n<p><a href=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/758.jpg\" class=\"gallery_colorbox\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-5253 aligncenter\" title=\"758\" src=\"http:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/758.jpg\"  alt=\"\" width=\"600\" height=\"382\" srcset=\"https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/758.jpg 600w, https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/758-300x191.jpg 300w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figura 8 &#8211; Estat\u00edsticas do registro do servidor web <\/strong><\/p>\n<p style=\"text-align: justify;\">Durante um periodo de apenas uma semana (25 mar\u00e7o-2 abril), foi detectado 5.377 IPs\u00a0 \u00fanicos conectados no servidor, a grande maioria do Iran: 3.702. Tamb\u00e9m, o resultado surpreende co grande quantidade de IPs no Sud\u00e3o: 1.280. Nossas estat\u00edsticas anteriores nos mostraram um grande n\u00famero de infec\u00e7\u00f5es no Sud\u00e3o, portanto isto, deve ter sido uma campanha dedicada que atacava sistemas no Ir\u00e3 e Sud\u00e3o.<\/p>\n<p style=\"text-align: justify;\">Se apenas um servidor movimentou mais de 5.000 v\u00edtimas em um per\u00edodo de uma semana, \u00e9 fato que havia v\u00e1rios servidores dispon\u00edveis. podemos estimar que o n\u00famero total de v\u00edtimas do Flame \u00e9 provavelmente maior que o estimado anteriormente, superando a 10.000.<\/p>\n<h3 style=\"text-align: justify;\">SP, SPE, FL, IP, Gauss e Stuxnet<\/h3>\n<p style=\"text-align: justify;\">O c\u00f3digo recuperado do servidor de C&amp;C\u00a0 manipula quatro clientes principais: SP, SPE, FL e IP. Desta lista o programa malicioso mais interessante \u00e9 o IP, que tamb\u00e9m \u00e9 mais recente baseando na aloca\u00e7\u00e3o de c\u00f3digos de clientes:<\/p>\n<p style=\"text-align: justify;\">\/\/\/ Types of clients<\/p>\n<p>define(&#8216;CLIENT_TYPE_UNKNOWN&#8217;, 0);<\/p>\n<p>define(&#8216;CLIENT_TYPE_SP&#8217;, 1);<\/p>\n<p>define(&#8216;CLIENT_TYPE_SPE&#8217;, 2);<\/p>\n<p>define(&#8216;<strong>CLIENT_TYPE_FL<\/strong>&#8216;, 3);<\/p>\n<p>define(&#8216;CLIENT_TYPE_IP&#8217;, 6);<\/p>\n<p style=\"text-align: justify;\">if (preg_match(&#8216;\/^uid\\=\\d+\\&amp;action\\=\\d+\/&#8217;, $data) === 1)<br \/>\n{<br \/>\nreturn array(RC_SUCCESS, PROTOCOL_SIGNUP);<br \/>\n}<\/p>\n<p style=\"text-align: justify;\">Nenhum dos programas maliciosos que temos analizados utiliza este esquema. Por exemplo, Gauss usa &#8220;POST \/userhome.php?sid=string==&amp;uid=string=&#8221;. De forma similar, Stuxnet usa &#8220;index.php?data=&#8230;&#8221;. Portanto, estamos bastante seguros de que este programa malicioso &#8216;IP&#8217; n\u00e3o \u00e9 nem Gauss ou Stuxnet.<\/p>\n<p style=\"text-align: justify;\">Al\u00e9m disso, o c\u00f3digo atual do servidor de C&amp;C n\u00e3o parece capaz de manipular as conex\u00f5es de Gauss ou Stuxnet.<\/p>\n<h3 style=\"text-align: justify;\">Drenagem do &#8216;SPE&#8217;<\/h3>\n<p style=\"text-align: justify;\">Com a colabor\u00e7\u00e3o de nossos parceiros, Kaspersky Lab imnplementou uma dreanagem para o Flame. J\u00e1 temos publicado estatisticas de dados de dreanagem em nossas anteriores publica\u00e7\u00f5es.<\/p>\n<p style=\"text-align: justify;\">Talvez, o mais interessante \u00e9 que com a base de c\u00f3digo do servidor de C&amp;C do Flame podemos\u00a0 catalogar as conex\u00f5es de drenagem em duas categorias principais:<\/p>\n<ul style=\"text-align: justify;\">\n<li>conex\u00f5es OldProtocol provinientes de Flame<\/li>\n<li>conex\u00f5es OldProtocolE usadas por SPE<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Portanto, podemos confirmar que o programa malicioso conhecido como &#8216;SPE&#8217;\u00a0 existe e que circula na internet<\/p>\n<p style=\"text-align: justify;\">Por outro lado, n\u00e3o h\u00e1 pistas dos misteriosos programas maliciosos SP ou IP.<\/p>\n<h3 style=\"text-align: justify;\">Conclus\u00e3o e Resumo:<\/h3>\n<p style=\"text-align: justify;\">Durante a nossa pesquisa em conjunto com os nossos parceiros da Symantec, ITU-IMPACT e CERT-Bund\/BSI, descobrimos v\u00e1rias coisas que n\u00e3o sabiamos sobre o Flame e sua plataforma associada:<\/p>\n<ul style=\"text-align: justify;\">\n<li><strong>O c\u00f3digo de desenvolvimento da plataforma C&amp;C come\u00e7ou em dezembro de 2006.<\/strong><\/li>\n<li><strong>Os coment\u00e1rios sobre o c\u00f3digo fonte indicam o envolvimento de pelo menos quatro programadores:\u00a0[D] censored, [O] censored, [H] censored y [R] censored.<\/strong><\/li>\n<li><strong>A mais recente mudan\u00e7a no c\u00f3digo fonte foi feito em 18 de maio de 2012 (LogWiper_fixed.txt, Constants.py).<\/strong><\/li>\n<li><strong>O c\u00f3digo do servidor de C&amp;C manipula quatro diferentes programas maliciosos que os autores chamaram de SP, SPE, FL e IP. Tamb\u00e9m manipula tres protocolos de comunica\u00e7\u00e3o (OldProtocol, OldProtocolE, SignupProtocol).<\/strong><\/li>\n<li><strong>Dos quatro programas maliciosos, somente se conhece o Flame, portanto, \u00e9 desconhecido no momento os outros tres.<\/strong><\/li>\n<li><strong>Para comunica\u00e7\u00f5es, Flame usa &#8216;OldProtocol&#8217;.<\/strong><\/li>\n<li><strong>Existe um programa malicioso relacionado com Flame, SPE, e\u00a0 est\u00e1 circulando na Internet.<\/strong><\/li>\n<li><strong>Flame n\u00e3o \u00e9 o mais &#8216;moderno&#8217; dos programas maliciosos conhecido pelo c\u00f3digo de C&amp;C.<\/strong><\/li>\n<li><strong>O programa malicioso mais recente se chama &#8220;IP&#8217; e permanece desconhecido.<\/strong><\/li>\n<li><strong>O c\u00f3digo est\u00e1\/estava em desenvolvimento; um novo protocolo chamado &#8220;Red Protocol&#8221; n\u00e3o foi totalmente implementado ainda.<\/strong><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify;\"><strong>A informa\u00e7\u00e3o apresentada nesta publica\u00e7\u00e3o mostra v\u00e1rios fatos importantes. Em primeiro lugar, o trabalho sobre estes projetos de ciberespionagem come\u00e7ou mais cedo do que o estimado (em 2006). Em segundo lugar, o c\u00f3digo que manipula as solicita\u00e7\u00f5es \u00e9 complexo e faz uso extensivo de codificac\u00e3o. Seus progamadores trataram de aparecer como uma plataforma de CMS leg\u00edtima. Por \u00faltimo, mas n\u00e3o menos importante, a informa\u00e7\u00e3o roubada no servidor \u00e9 codificado para que os invasores possam ler apenas por meio de uma criptografia de chave p\u00fablica poderosa. Estas caracter\u00edsticas n\u00e3o s\u00e3o encontradas normalmente nos programas maliciosos dos ciberdelinquentes, o que refor\u00e7a nossa conclus\u00e3o inicial de que o Flame \u00e9 um ataque patrocinado por uma na\u00e7\u00e3o\/estado.<\/strong><\/p>\n<p><strong><strong>Com base no c\u00f3digo do servidor sabemos que o Flame era um, de pelo menos quatro projetos. O prop\u00f3sito e natureza dos outros tr\u00eas, ainda s\u00e3o desconhecidos.<\/strong><\/strong><\/p>\n<p><strong>Global Research &amp; Analysis Team (GReAT), Kaspersky Lab<\/strong><\/p>\n<div><\/div>\n<div>Fonte:\u00a0<a title=\"Kaspersky\" href=\"http:\/\/www.securelist.com\/en\/\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/www.securelist.com\/en\/<\/a>\u00a0&#8211;\u00a0Kaspersky Lab<\/div>\n<div><\/div>\n<div>\n\r\n\t\t<div class='author-shortcodes'>\r\n\t\t\t<div class='author-inner'>\r\n\t\t\t\t<div class='author-image'>\r\n\t\t\t<img src='https:\/\/www.ethicalhacker.com.br\/site\/wp-content\/uploads\/2012-05-30-12.45.38-1143174_57x57.jpg' alt='' \/>\r\n\t\t\t<div class='author-overlay'><\/div>\r\n\t\t<\/div> <!-- .author-image --> \r\n\t\t<div class='author-info'>\r\n\t\t\t<p>By:\u00a0<strong>Gerson Raymond<\/strong><\/p>\n<p>T\u00e9cnico em Contabilidade, T\u00e9cnico em Eletr\u00f4nica, T\u00e9cnico em Telecomunica\u00e7\u00f5es, Bacharel em Ci\u00eancia da Computa\u00e7\u00e3o, Administrador de Redes Linux (CentOS, XEN, Zabbix, Asterisk\/Elastix) e P\u00f3s-Graduando em Seguran\u00e7a em Tecnologia da Informa\u00e7\u00e3o \u2013 UNIVERSIDADE MACKENZIE \u2013 SP.<\/p>\n<p>Homepage:\u00a0<a title=\"Grsecurity\" href=\"http:\/\/www.grsecurity.com.br\/\">http:\/\/www.grsecurity.com.br<\/a><\/p>\n<p><em>\u00a0<\/em>\r\n\t\t<\/div> <!-- .author-info --><\/p>\r\n\t\t\t<\/div> <!-- .author-inner -->\r\n\t\t<\/div> <!-- .author-shortcodes -->\n<\/div>\n<p><strong><strong>\u00a0<\/strong><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>An\u00e1lise completa dos servidores de comando e controle do Flame Nosso anterior an\u00e1lise sobre o programa malicioso Flame, da avan\u00e7ada ferramenta de ciberespionagem vinculada a opera\u00e7\u00e3o Stuxnet, foi publicada inicialmente no final de maio de 2012 e revelou uma campanha de amplo alcance contra v\u00e1rios pa\u00edses do Oriente M\u00e9dio. O programa malicioso Flame, incluindo todos [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":5254,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[100,105],"tags":[],"class_list":["post-5242","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-diversos","category-noticias"],"_links":{"self":[{"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/posts\/5242","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/comments?post=5242"}],"version-history":[{"count":34,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/posts\/5242\/revisions"}],"predecessor-version":[{"id":10596,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/posts\/5242\/revisions\/10596"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/media\/5254"}],"wp:attachment":[{"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/media?parent=5242"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/categories?post=5242"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ethicalhacker.com.br\/site\/wp-json\/wp\/v2\/tags?post=5242"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}