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  
     
     
     
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

Comparación entre el módulo 50251 de Regin y el keylogger “Qwerty”


  Costin       30 enero 2015 | 13:58  MSK

Comentar  

El 17 de enero de 2015, el portal Spiegel.de publicó un extenso artículo en base a documentos obtenidos de Edward Snowden. Al mismo tiempo, proporcionaron una copia de un programa malicioso llamado "QWERTY" (http://www.spiegel.de/media/media-35668.pdf), que supuestamente usan varios gobiernos en sus operaciones CNE.

Obtuvimos una copia de los ficheros maliciosos que publicó Der Spiegel y cuando los analizamos, de inmediato nos recordaron a Regin. Tras analizar el código, concluimos que el programa malicioso “QWERTY” posee idénticas funciones que la extensión Regin 50251.

Análisis

El paquete del módulo Qwerty consiste de tres binarios y sus correspondientes ficheros de configuración. Un fichero del paquete (20123.sys) nos pareció de particular interés:

“20123.sys” es un modo kernel parte del keylogger. Resulta que se creó a partir del código fuente que también se encuentra en el módulo Regin: la extensión “50251".

Mediante un diff binario resulta fácil localizar una parte importante del código que ambos ficheros comparten:

Gran parte del código compartido pertenece a la función que accede al controlador del teclado del sistema:

La mayor parte de los componentes de “Qwerty” llaman a extensiones del mismo paquete (con números de extensión 20121 – 20123), pero también existe un código que referencia las extensiones de la plataforma Regin. Una parte en particular de este código se usa en el módulo 20123 de “Qwerty” y en su contraparte 50251 de Regin, y se refiere a la extensión 50225 que se encuentra en el sistema de ficheros virtual de Regin. La extensión 50225 de Regin es responsable de la intercepción en modo kernel.

Esta es una sólida evidencia de que la extensión Qwerty sólo puede funcionar como parte de la plataforma Regin, utilizando las funciones de intercepción de la extensión 50225.

Como prueba adicional de que ambos módulos usan la misma plataforma de software, podemos dar un vistazo a las funciones exportadas por el ordinal 1 de ambos módulos. Contienen el código de arranque que se encuentra en cualquier otra extensión de Regin, e incluye el número verdadero de la extensión registrado en la plataforma a fin de permitir futuras referencias del módulo. Esto sólo tiene sentido si los módulos se usan con el orquestador de la plataforma Regin.

Aún no conocemos la razón por la que ambos módulos dan diferentes identidades a las extensiones. Quizás se deba a que los utilizan diferentes actores, cada uno con sus respectivos rangos de identidad de extensión asignados.

Conclusiones

Nuestro análisis del programa malicioso QWERTY publicado por Der Spiegel, indica que se trata de una extensión diseñada para formar parte de la plataforma Regin.  El keylogger QWERTY no funciona como un módulo autónomo, sino que depende de las funciones de intercepción kernel que suministra el módulo 50225 de Regin. Considerando la extrema complejidad de la plataforma Regin y las pocas opciones de que alguien la duplique sin acceder a sus códigos fuente, llegamos a la conclusión de que los desarrolladores del programa malicioso QWERTY y los de Regin son los mismos o trabajan juntos.

Otra observación importante es que las extensiones de Regin se guardan dentro de un VFS cifrado y comprimido, lo que significa que no existen directamente en la máquina de la víctima en su formato “nativo”. El despachador de la plataforma carga y ejecuta ahí las extensiones en el arranque. La única forma de atrapar al keylogger es escaneando la memoria del sistema o descifrando los VFS.

Por qué no hay que confiar ciegamente en los archivos firmados con certificados digitales


  29 enero 2015 | 13:00  MSK

Comentar  

La confianza en los certificados digitales estimula a los delincuentes a buscar diferentes formas de usarlos para firmar archivos maliciosos. En este artículos analizaremos las principales amenazas relacionadas con los archivos firmados y propondremos formas prácticas de minimizar los riesgos que implica ejecutarlos.

Andrey Ládikov

Si un archivo tiene firma digital, se considera que no representa peligro. Para los usuarios, la presencia de una firma digital es una garantía de que el archivo no contiene código malicioso. Muchos administradores de sistemas diseñan la política de seguridad de sus compañías para que los usuarios ejecuten sólo los ficheros firmados con certificados digitales. Además, algunos escáneres antivirus consideran que un fichero es seguro de antemano si contiene una firma digital válida.

Al mismo tiempo, la exagerada confianza en los certificados digitales estimula a los delincuentes a buscar diferentes formas de usarlos para firmar archivos maliciosos y después usarlos para objetivos ilegales.

En este artículos analizaremos las principales amenazas relacionadas con los archivos firmados y propondremos formas prácticas de minimizar los riesgos que implica ejecutarlos.

Creación de la firma digital de los ficheros

Para detectar las amenazas relacionadas con el uso de certificados digitales, analizaremos la secuencia de acciones que se realiza para poner una firma digital:

  1. El desarrollador del software compila el fichero.
  2. Se calcula una de las sumas de control (hash) del fichero: MD5, SHA1, SHA2.
  3. La suma hash del fichero se cifra con la llave privada del desarrollador de software.
  4. El bloque de datos cifrados obtenido y el certificado digital se agregan al final del fichero.

El certificado digital contiene la llave pública del desarrollador de programa, que permite descifrar el mensaje y verificar la integridad del fichero, así como la información que permite verificar la autenticidad del desarrollador de software.

La confirmación de autenticidad del productor del fichero se realiza mediante un centro de certificación. Esta organización confirma a los demás usuarios que la llave pública -con la cual se puede descifrar la suma hash y comprobar la integridad del fichero- le pertenece inequívocamente a este desarrollador de software. Con este objetivo, el centro de certificación firma el certificado del desarrollador para con esto confirmar que el par único de llaves pública y privada le pertenece sólo a este desarrollador. El certificado del centro de certificación, que da fe de la autenticidad del fichero también se agrega al final de fichero junto con el certificado del desarrollador.

Los certificados de los centros de certificación no los autentifica nadie, sino estas mismas organizaciones. Para que el sistema operativo Windows confíe en los certificados expedidos por determinado centro de certificación, es necesario poner este certificado en el almacén de certificados del sistema operativo. Los certificados de los centros de certificación más prestigiosos, que han pasado la certificación, se incluyen automáticamente en el almacén y llegan a poder de los usuarios junto con las actualizaciones del sistema operativo Windows. El usuario puede agregar certificados de otros centros de certificación por sí mismo con la condición de que tenga confianza en estas organizaciones.

Uso que los delincuentes dan a los certificados de confianza

Analicemos los ataques que se pueden realizar en cada una de las etapas de firma del fichero. No analizaremos los ataques teóricos relacionados con las debilidades de los algoritmos criptográficos usados durante el proceso de firma del fichero, sino que nos concentraremos en los métodos de ataque usados con más frecuencia por los delincuentes en la práctica.

Incrustación de código malicioso en la etapa de compilación del fichero

En muchas grandes compañías desarrolladoras de software el proceso de firma de los ficheros se realiza de forma automática al finalizar el proceso de compilación de los ficheros, que también se realiza de manera centralizada en un servidor build especial.

Habiendo recibido acceso a la red corporativa del desarrollador de software, el delincuente puede usar el servidor buid de la compañía para compilar un fichero malicioso que recibirá la firma automática de la compañía. Como resultado de este ataque, el delincuente recibe un fichero malicioso que contiene una firma digital auténtica.

En la práctica esta amenaza se da muy rara vez, ya que en las grandes compañías productoras de software los servidores build están bastante protegidos. De todos modos, se conocen casos de ataques a blancos específicos realizados para firmar ficheros maliciosos con los certificados de compañías de confianza.

Robo de la llave privada

A veces los delincuentes consiguen penetrar en la red corporativa de la compañía y obtener acceso a la llave privada usada para firmar ficheros. Usando la llave privada, pueden firmar un fichero malicioso y hacerlo pasar como un fichero del productor legal de software.

Uno de los métodos usados para robar la llave privada es el uso de software malicioso especializado.

Después de robar la llave privada, el delincuente la usa él mismo o la revende. Y mientras más famoso sea el productor de software a quien se le haya robado la llave, más interés representará para los delincuentes, ya que el software de desarrolladores de software famosos no levanta sospechas entre los usuarios y administradores de seguridad de la red corporativa.

Al mismo tiempo, en las grandes compañías dedicadas al desarrollo de software, las llaves privadas se guardan en módulos aparte, que están bien protegidos, lo que hace mucho más complejo que sean robadas. Por esta razón, como regla, las llaves privadas se las roban a pequeñas compañías o desarrolladores privados de software que no prestan suficiente atención a la seguridad.

Vulnerabilidades en el algoritmo de verificación de la firma de ficheros ejecutables

Para que el sistema operativo sepa en qué lugar del fichero buscar la información sobre la presencia de la firma digital, en el encabezado de cada fichero ejecutable firmado hay 8 bytes de datos con información sobre la ubicación y el tamaño de la firma digital, que se excluyen al verificar la firma del fichero. šSi al final de la firma se agrega un bloque de datos y se aumenta el tamaño de la firma en la misma dimensión, estos cambios tampoco influirán en el resultado de la verificación de la firma. Esto permite obtener espacio adicional en el fichero firmado, y los datos que se pongan en este no influirán en el resultado de la verificación de la firma del fichero.

Este algoritmo se usa activamente en los instaladores web legales: sus autores cambian el tamaño de la firma de tal manera que aparezca un bloque de datos adicional que permita incluir en el bloque de la firma digital un enlace a un fichero, que el instalador descargará del sitio del desarrollador de software e instalará en el sistema del usuario. Para los desarrolladores este método es cómodo porque no hace falta firmar el instalador de nuevo cada vez que cambie el enlace a la distribución del programa: basta con sencillamente cambiar el enlace almacenado en el bloque de firma digital.

Por su parte, los delincuentes usan el algoritmo descrito para sus propios objetivos. Tomando un instalador web de un programa legal, el delincuente cambia el enlace al distributivo a descargar, para que el instalador descargue e instale software malicioso en el sistema. Después de lo cual pone el instalador adulterado en los sitios que distribuyen programas.

Para eliminar esta vulnerabilidad, Microsoft publicó una actualización de seguridad que permite verificar de una forma muy estricta la firma digital del fichero. Pero esta actualización no se aplica automáticamente porque una gran cantidad de desarrolladores de software usan el algoritmo descrito en sus instaladores y después de la activación automática de esta actualización los programas de estos desarrolladores se considerarán no firmados. El usuario puede activar esta actualización de forma manual, si le hace falta.

Uso de un certificado obtenido legalmente

Si hace pocos años sólo los grandes productores de software usaban certificados, en la actualidad son cada vez más los desarrolladores privados y pequeñas compañías que los usan. El siguiente gráfico demuestra la dinámica cuantitativa de los certificados de firma de códigos conocidos por Kaspersky Lab. Como podemos ver, la cantidad de certificados aumenta cada año.

Cantidad de certificados conocidos por Kaspersky Lab, cuya autenticidad está confirmada por centros de certificación

El procedimiento de adquisición de un certificado para firmar código ejecutable es bastante simple: a las personas particulares se les exige presentar sus datos de identidad y a las compañías, sus datos oficiales de registro. Pero algunos centros de certificación que expiden certificados no controlan de ninguna manera cuales son las actividades de la compañía que adquiere el certificado. El centro de certificación se limita a expedir un certificado con derecho a firmar ficheros ejecutables y confirmar que este certificado ha sido expedido a esta persona o compañía.

Esta actitud les da a los delincuentes la posibilidad de comprar legalmente un certificado para firmar software malicioso y potencialmente indeseable.

Lo más frecuente es que sean las compañías que producen software potencialmente peligroso las que compren certificados. Por una parte, estas compañías no producen software malicioso y por lo tanto, tienen derecho a recibir un certificado digital para firmar sus programas. Por otra, el software que producen estas compañías infringe incomodidades al usuario. Para hacer que el usuario sienta más confianza en estos programas, se los firma con certificados digitales.

Certificados que no son de confianza

En todos los casos descritos anteriormente (robo de llave, penetración en la infraestructura de la compañía y firma del fichero con la firma digital de ésta, compra de certificado para firmar software malicioso) el resultado es siempre el mismo: un certificado de confianza firma un fichero malicioso.

Por lo tanto, estos certificados, a pesar de que su autenticidad está confirmada por el centro de certificación, no pueden considerarse de confianza, ya que se los ha usado o sigue usando para firmar ficheros maliciosos. šDe aquí en adelante nos referiremos a estos certificados como no de confianza.

En caso de que se robe la llave privada del desarrollador de software o se penetre en la infraestructura de la compañía y se firme el fichero malicioso con un certificado de confianza, los centros de certificación dejan de confirmar la autenticidad del certificado (lo revocan). La celeridad con que reaccionan los centros de certificación depende de cuándo se conoce que el certificado ha sido usado por alguien diferente al desarrollador.

Pero cuando se compra un certificado para firmar software potencialmente indeseable, los centros de certificación no siempre lo revocan, es decir, el certificado sigue estando vigente.

El siguiente gráfico muestra la cantidad de certificados usados para firmar software potencialmente indeseable, entre todos los certificados que no son de confianza (según los datos de Kaspersky Lab).

Distribución de certificados que no son de confianza según tipos

Métodos de protección contra la ejecución de programas firmados con certificados que no sean de confianza

Hemos analizado los métodos más difundidos que usan los delincuentes para firmar sus ficheros con certificados digitales. En el presente el problema de la firma de ficheros maliciosos y potencialmente indeseables con certificados digitales está cobrando cada vez más importancia: si en 2008 se expidieron 1500 certificados que después fueron usados para firmar software malicioso, en 2014 estos certificados ya eran más de 6000.

Cambio de la cantidad de certificados que no son de confianza conocidos por Kaspersky Lab

Tomando en consideración el aumento de la cantidad de amenazas relacionadas con la firma de ficheros maliciosos con certificados digitales, los usuarios y administradores no deben confiar ciegamente en la presencia de firmas digitales para ejecutar ficheros ejecutables.

Daremos varias recomendaciones prácticas que permitan reducir la probabilidad de ejecutar software malicioso nuevo, todavía desconocido por los escáneres antivirus y firmado con certificados digitales:
  1. Permitir la ejecución sólo de programas firmados por compañías conocidas.

    Se puede reducir sustancialmente el riesgo de infección del sistema prohibiendo la ejecución de programas firmados con firmas digitales de productores desconocidos de software. Debido a que, como ya hemos escrito más arriba, lo más frecuente es que se robe certificados a las pequeñas compañías productoras de software.

  2. Permitir la ejecución de programas tomando en cuenta los atributos únicos de la firma digital.

    Bajo un solo nombre se pueden difundir varios certificados expedidos a una sola compañía. Si se roba uno de estos certificados a una compañía famosa, se permitirá la ejecución de un fichero firmado con el certificado robado, si para la verificación se usa sólo el criterio de confiar en los productores conocidos de software.

    Para evitar estas situaciones, es necesario usar atributos diferentes al nombre para permitir la ejecución de programas firmados con certificados de compañías famosas. Estos atributos pueden ser el número de serie o la suma hash del certificado. Como el número de serie del certificado es único sólo en los límites de determinado centro de certificación, recomendamos usarlo junto con el nombre de la compañía que firma el certificado.

  3. Activar la actualización MS13-098.

    Recomendamos a los usuarios expertos y los administradores de sistemas activar la actualización MS13-098 porque corrige un error que permite incluir datos adicionales en un fichero firmado, sin modificar la firma del mismo. šEn el centro de seguridad de Microsoft se puede leer más sobre la activación de esta actualización.

  4. No poner en el almacén certificados de centros de certificación desconocidos.

    No se recomienda instalar en el almacén certificados raíz de centros de certificación desconocidos, ya que en el futuro todos los ficheros firmados con certificados confirmados por este centro se considerarán de confianza.

  5. Usar la base de certificados de confianza proporcionada por los productores de software antivirus.

    Algunos productores de antivirus, entre ellos nuestra compañía, incluyen en sus productos una base de certificados de confianza (y una lista negra de los que no lo son) que se actualiza regularmente junto con las bases antivirus. Esto permite recibir información operativa sobre los certificados todavía no revocados que firman software malicioso o potencialmente indeseable. Los ficheros firmados con certificados que no son de confianza y que están presentes en esta base se someten a un control todavía más riguroso del antivirus.

    En la base de certificados de confianza se incluyen los certificados de productores conocidos usados para firmar programas de confianza. La presencia de un certificado en esta base pude usarse como uno de los criterios para ejecutar programas en la red corporativa.

    La presencia de esta base en el producto antivirus permite reducir la presión sobre el administrador, liberándolo de la necesidad de elaborar y tener actualizada su propia base de certificados de confianza.

El número de certificados digitales que se usan para firmar ficheros maliciosos y potencialmente indeseables se duplica cada año. Como consecuencia, es necesario un estricto control de los ficheros firmados por parte del antivirus y el respeto de las políticas de seguridad descritas más arriba.

Análisis de Hopscotch y Legspin de Regin


  Costin       28 enero 2015 | 14:36  MSK

Comentar  

Con amenazas de alto perfil como Regin, los errores son increíblemente raros. Sin embargo, cuando se trata de humanos escribiendo códigos, algunos errores son inevitables. Entre las cosas más interesantes que observamos en la operación del programa malicioso Regin, están los nombres de código olvidados de algunos de sus módulos.

Estos son:

  • HOPSCOTCH
  • LEGSPIN
  • WILLISCHECK
  • U_STARBUCKS

Decidimos hacer un análisis profundo de dos de estos módulos: Hopscotch Legspin.

A pesar del nivel general de sofisticación (y a veces incluso de sobre-ingeniería) de la plataforma Regin, estas herramientas son sencillas, directas y ofrecen interfaces de consolas interactivas a los operadores de Regin. Lo que las hace interesantes es el hecho que se las desarrolló hace muchos años y que quizás se crearon incluso antes de la misma plataforma Regin.

El módulo Hopscotch

MD56c34031d7a5fc2b091b623981a8ae61c
Tamaño36864 bytes
TipoWin32 EXE
Compilado2006.03.22 19:09:29 (GMT)

Este módulo contiene otro binario, guardado como recurso 103:

MD542eaf2ab25c9ead201f25ecbdc96fb60
Tamaño18432 bytes
TipoWin32 EXE
Compilado2006.03.22 19:09:29 (GMT)

Este módulo ejecutable se diseñó como una herramienta interactiva autónoma para movimientos laterales. No contiene exploits pero en vez de ello depende de credenciales previamente adquiridas para auto-autenticarse en la máquina remota mediante APIs estándar.

El módulo recibe el nombre de la máquina atacada y un nombre de un fichero remoto opcional desde la entrada normal (operador). Los atacantes pueden elegir entre varias opciones para su ejecución y la herramienta ofrece respuestas para lectura humana y sugerencias de posibles entradas.

Este es un ejemplo de la ejecución de ‘Hopscotch’ en una máquina virtual:

Mecanismo de autenticación (SU o NETUSE) [S]/N:
¿Continuar? [n]:
Ya existía un fichero con el mismo nombre en la máquina remota – No se elimina…

El módulo puede recurrir a dos rutinas para auto-autenticarse en la máquina atacada: conectarse al recurso normal llamado “IPC$” (método llamado “NET USE”) o ingresar como un usuario local ("SU", o "switch user") que tiene los permisos necesarios para realizar otras acciones.

Después extrae una carga maliciosa ejecutable desde sus recursos y la escribe en un lugar en la máquina atacada. El lugar predeterminado para la carga es: \\%target%\ADMIN$\SYSTEM32\SVCSTAT.EXE. Una vez hecho esto, se conecta con el administrador de servicio de la máquina remota y crea un nuevo servicio llamado “Service Control Manager” para ejecutar la carga. El servicio se inicia inmediatamente y tras ejecutarse por un segundo, se detiene y se elimina.

El módulo establece un canal bidireccional de comunicación cifrada con la carga remota SVCSTAT.EXE usando dos tubos nombrados. Uno sirve para enviar entradas desde el operador a la carga, y el otro escribe los datos desde la carga a la salida normal. Los datos se cifran con el algoritmo RC4 y el intercambio de llaves inicial se asegura con cifrado asimétrico.

\\%target%\pipe\{66fbe87a-4372-1f51-101d-1aaf0043127a}
\\%target%\pipe\{44fdg23a-1522-6f9e-d05d-1aaf0176138a}

Una vez hecho esto, la herramienta elimina el archivo remoto y cierra las sesiones autenticadas, eliminando así todo rastro de la operación.

El módulo de carga SVCSTAT.EXE lanza su copia en el proceso dllhost.exe. Después prepara los correspondientes tubos nombrados en la máquina atacada y espera la entrada de datos. Una vez que el módulo original se conecta con el tubo, establece el cifrado de la comunicación por el tubo y espera la entrada del shellcode.

El ejecutable se inyecta y se ejecuta en un nuevo proceso de dllhost.exe o svchost.exe, con sus entradas y salidas redirigidas a la extensión remota que inició el ataque. Esto le permite al operador controlar el módulo inyectado e interactuar con él.

El módulo Legspin

MD529105f46e4d33f66fee346cfd099d1cc
Tamaño67584 bytes
TipoWin32 EXE
Compilado2003.03.17 08:33:50 (GMT)

Este módulo también se desarrolló como una utilidad autónoma de línea de comandos para la administración de ordenadores. Cuando se ejecuta de forma remota se convierte en una poderosa puerta trasera. Vale la pena hacer notar que el programa posee soporte completo de consola y presenta una salida en colores cuando se ejecuta a nivel local. Incluso es capaz de distinguir entre consolas compatibles con Windows Console API y terminales compatibles con TTY que aceptan códigos de escape para colores.

Salida “Legspin” en una ventana de consola normal con resaltados en colores

Además de la marca de tiempo de compilación que se encuentra en los encabezados PE, hay dos referencias que apuntan a 2003 como el año real de su compilación. El programa imprime dos etiquetas de versiones:

  • 2002-09-A, mencionada como "lib version"
  • 2003-03-A

Además, el programa usa las funciones API heredadas, como “NetBIOS" que se introdujo en Windows 2000 y se menospreció en Windows Vista.

Una vez que arranca e inicializa, le proporciona al operador un símbolo de sistema interactivo, a la espera de la entrada de comandos. La lista de comandos disponibles es bastante extensa y les permite a los operadores realizar muchas tareas administrativas. Algunos de los comandos requieren información adicional que se le pide al operador, y los comandos proporcionan una descripción de texto de los parámetros disponibles. En realidad el programa es un shell administrativo que el atacante/usuario debe operar manualmente.

ComandoDescripción
cdCambia el directorio en uso
dir
ls
dirl
dirs
Lista de archivos y directorios
tarEncuentra archivos que correspondan con una determinada máscara y rango de tiempo, y escribe sus contenidos en un fichero comprimido cifrado con XOR.
treeImprime un árbol de directorio usando seudográficos

trashLee e imprime los contenidos del directorio “Recycle Bin” de Windows
getRecupera un fichero arbitrario desde la máquina atacada, comprimido con LZO
putEnvía un fichero arbitrario a la máquina atacada, comprimido con LZO
delElimina un fichero
ren
mv
copy
cp
Copia o mueve un fichero a un nuevo lugar
gtmObtiene la creación de ficheros, acceso, escribe marcas de tiempo y recuerda los valores
stmEstablece la creación de ficheros, acceso, escribe marcas de tiempo en los valores previamente recuperados
mtmModifica las marcas de tiempo de los ficheros previamente recuperados
scan
strings
Encuentra e imprime todas las cadenas legibles desde un determinado fichero
moreImprime los contenidos de un fichero arbitrario
accessRecupera e imprime las entradas DACL de ficheros o directorios
auditRecupera e imprime las entradas SACL de ficheros o directorios
finfoRecupera e imprime información de la versión desde un determinado fichero
csVacía los primeros 10.000 bytes desde un fichero arbitrario o desde varios ficheros de sistema:

advapi32.dll
kernel32.dll
msvcrt.dll
ntdll.dll
ntoskrnl.exe
win32k.sys
cmd.exe
ping.exe
ipconfig.exe
tracert.exe
netstat.exe
net.exe
user32.dll
gdi32.dll
shell32.dll

lnkBusca ficheros LNK, analiza sintácticamente e imprime sus contenido
infoImprime la información general del sistema:
  • Tipo de CPU
  • Estado de la memoria
  • Nombre del ordenador
  • Números de las versiones de Windows e Internet Explorer
  • Ruta de instalación de Windows
  • Página de códigos
dlImprime información sobre los discos:
  • Tipo
  • Espacio disponible/usado
  • Lista de particiones, tipos de sistema de archivos
psLista de todos los procesos en ejecución
logdumpInconcluso, sólo muestra la descripción del parámetro
reglistVacía la información de registro para una colmena local o remota
windowsEnumera todos los escritorios disponibles y todas las ventana abiertas
viewLista de todos los servidores visibles en un dominio
domainsLista de los controladores de dominios en una red
sharesLista de todos los recursos de red visibles
regsImprime información adicional del sistema desde el registro:
  • Versión de IE
  • Versión de Outlook Express
  • Nombre de usuario predeterminado para ingreso
  • Fecha de instalación del sistema
  • Fecha de BIOS
  • Frecuencia del CPU
  • Directorio raíz del sistema
ipsLista de datos del adaptador de red:
  • Dirección IP DHCP/estática
  • Dirección predeterminada de la pasarela
timesObtiene la hora actual desde una máquina local o remota
whoLista de los nombres de usuario actuales y los dominios a los que accedió la máquina
net
nbtstat
tracert
ipconfig
netstat
ping
Ejecuta la utilidad de sistema correspondiente e imprime los resultados
telConecta a un determinado puerto TCP de un host, envía una cadena provista por el operador, imprime la respuesta
dns
arps
Resuelve un host mediante peticiones DNS o ARP
usersLista de datos de todas las cuentas de usuario
adminsLista de datos de las cuentas de usuario con permisos administrativos
groupsLista de datos de grupos de usuario
trustsLista de datos de cuentas interdominio de confianza del usuario
packagesImprime los nombres de paquetes de software instalados
sharepwEjecuta un ataque de fuerza bruta para ingresar y obtener la contraseña de un recurso remoto
sharelistConecta a un recurso remoto
srvinfoRecupera información de la configuración actual para un servidor especificado
netuseConecta, desconecta o hace una lista de los recursos de red
netshareCrea o elimina recursos de red en la máquina actual
nbstatLista de datos del adaptador NetBIOS LAN
runCrea un proceso y redirige sus salidas al operador
systemEjecuta un comando arbitrario mediante WinExec API
exitSale del programa
setDetermina varias variables internas usadas en otros comandos shell
suIngresa como otro usuario
killTermina un proceso por su PID
kpinstModifica el valor de registro:
[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] System
Normalmente, este valor debe apuntar a "lsass.exe"
svc
drv
Crea, modifica o elimina un servicio de sistema
help
?
Imprime la lista de comandos compatibles

El módulo Legspin que recuperamos no posee un mecanismo C&C incorporado. En lugar de ello, depende de la plataforma Regin para redirigir las entradas/salidas de la consola a/desde los operadores.

Conclusiones

A diferencia de otros módulos de Regin, Legspin y Hopscotch parecen ser herramientas autónomas desarrolladas mucho antes. En particular, la puerta trasera Legspin data de 2003,š e incluso quizás de 2002. Vale la pena remarcar que no todas las instalaciones de Regin contienen el módulo Legspin; en la mayoría de los casos, los atacantes manejan a sus víctimas mediante otras funciones de la plataforma Regin.

Esto significa que Legspin pudo haberse usado independientemente de la plataforma Regin, como una sencilla puerta trasera junto a un empacador de salidas/entradas.

Aunque más detalles de Regin van saliendo a la luz, todavía queda mucho por conocer. Una cosa está clara: lo que sabemos de Regin es, probablemente, información retirada que ha sido remplazada por nuevos módulos y técnicas con el pasar del tiempo.

Windows 10: Anticipo y seguridad


  Kurt Baumgartner       28 enero 2015 | 12:05  MSK

Comentar  

Esta mañana, en una transmisión en vivo por Internet, Microsoft anticipó su última "experiencia”: Windows 10, cuyo lanzamiento está previsto para los siguientes meses. Windows 10 no está diseñado sólo como un sistema operativo para ordenadores de escritorio, sino como una plataforma informática verdaderamente amplia.

Microsoft afirma que la desarrollaron pensando en una “informática más personal” y que se trata de un avance ambicioso hacia la integración entre la informática de escritorio, la informática holográfica (¡¡fantástica!!), los dispositivos móviles, juegos y el Internet de Cosas (IoT), que es un paso hacia la “Tienda”, las aplicaciones de productividad, los grandes servicios de intercambio de datos, las nuevas tecnologías de hardware, y la informática en la nube para lograr una “experiencia móvil”.

Mencionaron de pasada la “confiabilidad”, sólo en referencia a la privacidad de datos. ššPor mi experiencia, es decepcionante cuando los fabricantes, no sólo Microsoft, dejan de lado el tema de la seguridad. Sin embargo, este nuevo sistema operativo cuenta con una extensa lista de mejoras en seguridad, así como una gran cantidad de nuevas superficies de ataque.

Microsoft está intentando reforzar su nueva versión impidiendo la instalación de aplicaciones no confiables y verificando su confiabilidad mediante sus firmas digitales. Este modelo de confiabilidad de firmas es una mejora, pero su manejo efectivo no es perfecto. Ataques APTs como Winnti contra las principales compañías desarrolladoras y otros múltiples proyectos de ataques han demostrado que los certificados digitales pueden robarse fácilmente para después utilizarse en ataques. No sólo los ataques Winnti sino también los certificados se distribuyen a través de múltiples actores APT que intercambian estos valiosos recursos, quebrando así el modelo mismo de confianza para continuar con sus acciones de espionaje.

Con una integración perfecta de todos estos servicios de intercambio de datos a través de recursos informáticos, la autenticación y sus subyacentes credenciales y autenticadores no pueden filtrarse entre servicios, aplicaciones y dispositivos. Las técnicas de ataques pass-the-hash, tan populares en ataques dirigidos, han atormentado a las compañías con sistemas Windows por casi una década. Se necesita una mejor protección contra estas técnicas de robo de credenciales. šFlame introdujo un nuevo nivel en el robo de credenciales, y puede que veamos ataques contra Hyper-V y el nuevo modelo contenedor de Windows 10 para intentar acceder a estos autenticadores y usarlos para movimientos laterales y llegar a los datos del usuario. Los esfuerzos defensivos no han tenido mucho éxito hasta ahora, y Active Directory sigue sufriendo nuevos ataques contra la autenticación en organizaciones mediante "llaves maestras". Entonces, la implementación del suministro de credenciales y el manejo de autenticadores de acceso merecen mayor atención de parte de los expertos en seguridad, ya que las tecnologías Hyper-V y la superficie de ataques contra los componentes experimentarán un giro en los próximos años. La implementación de DLP para el intercambio seguro de datos corporativos es alentadora también, pero ¿qué tan sólida puede ser dada las šlimitaciones de energía del hardware móvil?

Considerando que 2014 trajo consigo más de 200 vulnerabilidades que requirieron reparaciones para varias versiones de Internet Explorer,š sería necesaria una actualización minimalista de este código con el navegador “Proyecto Esparta”. En 2014 el navegador IE sufrió ataques en todas las plataformas Windows, incluso en la última. Nuestro AEP y otras tecnologías evitaron la explotación de estas vulnerabilidades en numerosas ocasiones el año pasado. No sólo su modelo de implementación de componentes ActiveX y su diseño han estado bajo exigente escrutinio, sino el montón de nuevos códigos y funcionalidades que habilitan las vulnerabilidades “use-after-free” ha permitido la ejecución remota crítica de códigos. El nuevo navegador Esparta incluye grandes cantidades de nuevos códigos para comunicaciones e intercambio de datos, lo que repite la costumbre de Microsoft de introducir anualmente en su navegador cientos de vulnerabilidades que requieren reparaciones. Esperamos que su equipo de trabajo no traiga consigo esa carga, que parece muy pesada con las nuevas funciones. No he visto ninguna de las nuevas funciones de seguridad, prácticas de desarrollo, ni cajas de arena que se anuncian, y esperaré a ver qué pasa después.

Se dedicó mucho tiempo a šla presentación de su “asistente inteligente”, Cortana, que comenzó con una conversación un tanto bizarra y desconectada entre el presentador y Cortana. El diablo está en los detalles cuando se implementa el soporte de seguridad para acceder a los datos a través de servicios bastante impredecibles como este.

Por supuesto, nuestros productos estarán listos para entrar en acción. Los productos de consumo de Kaspersky Lab soportarán Windows 10 tras su lanzamiento oficial. Nuestros clientes no tendrán que reinstalar las soluciones de Kaspersky Lab cuando tengan que migrar a la nueva plataforma. Todos nuestros productos se actualizarán debidamente y seguirán ofreciendo el mismo nivel excepcional de protección con el nuevo sistema operativo de Windows.

La segunda ronda de CODE BLUE en Japón


  Suguru Ishimaru       16 enero 2015 | 12:51  MSK

Comentar  

CODE BLUE@TOKYO, una conferencia de seguridad informática del más alto nivel, se llevó a cabo el 18 y 19 de diciembre. Fue su segunda ronda, continuando su primera aparición en febrero de 2014.



Reunió a más de 400 personas de todo el mundo, incluyendo a alguien que participó en la conferencia a distancia, mediante un dron. šSurgieron acaloradas discusiones entre los investigadores e ingenieros durante los intervalos y los descansos para comer – no faltaron los entusiastas que casi pierden las presentaciones por seguir las conversaciones (admito que fui uno de ellos).


La idea de la reunión es que sea "una conferencia internacional donde los más destacados especialistas de seguridad se reúnen para dar charlas innovadoras, y un lugar para que todos los participantes intercambien información e interactúen fuera de los límites de las fronteras e idiomas". Tal como se indica, todas las presentaciones fueron sobre investigaciones técnicas de alto nivel que se seleccionaron de temas que investigadores de todo el mundo habían propuesto. Los temas de seguridad exploraban cuestiones como: tecnologías integradas, pruebas de intrusión, vulnerabilidades, malware, programación, etc. Me gustaría poderhablar de todas las presentaciones, pero para ahorrar tiempo escogeré cinco:


1. Evaluación de seguridad y prueba de la Unidad de Control de Motor (ECU) automotriz accionada por Tricore

Dennis Kengo Oka (ETAS) y Takahiro Matsuki (FFRI) analizaron el comportamiento de los programas ECU que se ejecutan en TriCore para descubrir los posibles ataques que le afectan. No consiguieron el mismo programa para hacer las pruebas, por lo que ellos mismos crearon uno de prueba para demostrar que el sistema de control TriCore corría riesgos de ataque. Una parte de la memoria tenía una dirección de retorno que, si se sobrescribía con éxito, permitía que se transfieran los procesos del programa a una dirección arbitraria. Los investigadores pusieron a prueba la vulnerabilidad con cuatro demos, usando una tabla de evaluaciones. Dijeron que necesitarían el programa ECU legítimo de TriCore para poder indagar con mayor certeza sobre si la vulnerabilidad es o no una amenaza real.


2. [In]Seguridad Física: No TODO está en lo Ciber


Inbar Raz (Check Point) presentó los riesgos de las máquinas que emiten entradas para el cine, aparatos que funcionan como puntos de venta y televisores de hospitales. Estos equipos tienen puertos USB/LAN; al insertar teclados USB o discos flash con LiveOS en estos puertos e iniciarlos, se puede extraer los datos almacenados en estos equipos. Como estas máquinas suelen guardar información de tarjetas de crédito y claves privadas para las comunicaciones, esta vulnerabilidad puede representar un riesgo muy grande. Durante la presentación, Raz indicó que los dispositivos especiales que se usan comúnmente en público suelen tener fallas de protección contra el acceso inapropiado de terceros, lo que podría poner en manos peligrosas los datos confidenciales de sus usuarios.


3. La historia de IDA Pro


La charla principal del Día 2, por Ilfak Guilfanov, trató de la historia de IDA desde la versión 0.1 a IDA Pro. Habló sobre cómo se creó IDA; las funcionalidades que había implementado; los problemas que había resuelto; y la existencia de una versión pirata de IDA Pro. Junto con el futuro entorno de IDA Pro, se reveló la identidad de la icónica mujer de su logotipo.


IDA Pro es muy usado entre los ingenieros e investigadores de malware para analizar programas; no soy la excepción.


4. Ataque de drones con malware e intrusión a redes


Dongcheol Hong (SEWORKS) indicó los problemas en la configuración de seguridad de un sistema de drones y demostró lo fácil que era secuestrarlos. Hong mostró un video con demostraciones de experimentos de infecciones de malware mediante una aplicación de smartphones y un ataque de un dron infectado hacia uno limpio. Al final de la presentación, alertó que los drones podrían representar amenazas a otros sistemas, ya que se pueden realizar ataques remotos mediante PCs, puntos de acceso o dispositivos inteligentes.


5. Seguridad integrada en la Tierra del Sol Naciente


Ben Schmidt (Narf Industries) y Paul Makowski (Narf Industries) se concentraron en estudiar los routers más populares de Japón, indicar las partes de sus códigos que eran vulnerables y demostrar cómo se los podía atacar. Según ellos, hay muchos routers domésticos en todo el mundo, lo que permite el acceso a puertos HTTP y UPnP desde un WAN – Japón era el cuarto en su lista mundial. También dijeron que al momento de realizar su presentación existían alrededor de 200.000 routers vulnerables que permitían el acceso HTTP y UPnP desde un WAN en Japón. Schmidt y Makowski me enviaron comentarios adicionales después de su presentación. Dijeron: “Los dispositivos integrados japoneses son atractivos para los cibercriminales porque los enlaces a Internet de Japón tienen un ancho de banda alto y una latencia baja". También recalcaron la importancia de parchar los dispositivos integrados tan pronto como sea posible.


David Jacoby, del Equipo Global de Análisis e Investigación (GReAT) de Kaspersky Labš también dio una charla en CODE BLUE. Su presentación, llamada “El día que ataqué mi propia casa” y trató de lo que descubrió cuando hackeó los dispositivos de su propio hogar. Su entrada del blog al respecto puede encontrarse en Viruslist.


Kaspersky Lab Japón fue Patrocinador Esmeralda de CODE BLUE, igual que en la primera ronda.

El valor de Bitcoin se desvanece después del robo de $5M a Bitstamp


  Stefan       13 enero 2015 | 11:26  MSK

Comentar  

El nuevo año comenzó con el pie izquierdo en el mundo de las bitcoins. El 4 de enero, un ciberataque contra Bitstamp, uno de los mayores sitios de intercambio de bitcoins, causó la pérdida de casi 19.000 BTC – el equivalente a 5 millones de dólares.



Aunque todavía se sabe muy poco sobre cómo los atacantes consiguieron realizar el robo, Bitstamp asegura a sus clientes que todas sus bitcoins están a salvo. La compañía dijo que "esta intrusión afecta sólo a una pequeña parte de las reservas totales de bitcoins de Bitstamp", por lo que no debería tener ninguna dificultad cubriendo las pérdidas.


Debido a la naturaleza irreversible de las transacciones de bitcoins, lo único que los usuarios de la moneda virtual pueden hacer por ahora es ver cómo los atacantes están vaciando frente a sus ojos la cuenta usada para recolectar bitcoins.



Tú mismo puedes seguir las transacciones de los ladrones aquí: https://blockchain.info/address/1L2JsXHPMYuAa9ugvHGLwkdstCPUDemNCf


En este momento, lo más probable es que los atacantes estén tratando de mover esas bitcoins por la mayor cantidad de cuentas posible para después lavarlas usando los llamados servicios "de mezcla".


Parece que Bitstamp está mucho mejor preparado para estos incidentes que Mt. Gox, así que, aunque el incidente afectó el precio de las bitcoins, el impacto no fue muy grande. Esto es en parte porque las bitcoins de todos modos se han devaluado hasta alcanzar un valor que no tenían desde mediados de 2013: entre 250 y 300 dólares por BTC.



Precio del bitcoin en 2014 - fuente: ZeroBlock


Tomando en cuenta estos ciberataques, podemos llegar a la conclusión de que la seguridad de 2015 seguirá siendo el factor más importante para los usuarios de bitcoins y sus servicios de intercambio.


Nuestro consejo es que trates de diversificar y minimizar el tiempo en que confías tus bitcoins a cualquiera que no sea tú mismo. Los intercambios de bitcoins y proveedores externos de billeteras son un imán para los atacantes, por lo que es mejor que te encargues tú mismo de la seguridad de tus bitcoins.


No te olvides de revisar nuestros consejos para šmantener a salvo tus bitcoins.

Cloud Atlas: La APT RedOctober regresa con estilo


  Global Research & Analysis Team (GReAT), Kaspersky Lab       22 diciembre 2014 | 17:55  MSK

Comentar  

Hace dos años publicamos nuestras investigaciones sobre RedOctober, una compleja operación de ciber-espionaje que afectaba a las embajadas diplomáticas de todo el mundo. La llamamos RedOctober porque comenzamos esta investigación en octubre 2012, un mes excepcionalmente ocupado.

La operación Red Octuber se cerró poco después de nuestro anuncio en enero de 2013, y se desmanteló la red de C&Cs. Estas grandes operaciones, que implican grandes inversiones y una inmensa cantidad de recursos, no suelen “desaparecer" para siempre. Lo más común es que el grupo desaparezca por algunos meses para rediseñar las herramientas y el programa malicioso y continuar con sus operaciones.

Puedes ver:

Desde enero de 2013, hemos estado alertas por el posible regreso de RedOctober. Es posible que se haya lanzado un ataque mientras observábamos Mevade, un programa malicioso bastante inusual que apareció a finales de 2013. El estilo de los nombres de los C&C de Mevade y algunas otras semejanzas técnicas indicaban una conexión con RedOctober, pero el vínculo era demasiado débil. No fue hasta agosto de 2014 que encontramos algo que nos hizo preguntarnos si RedOctober había vuelto para quedarse.

Conozcan Cloud Atlas

En agosto de 2014, algunos de nuestros usuarios se encontraron ante ataques dirigidos con una variante de CVE-2012-0158 y una cepa rara de malware. Hicimos un análisis veloz del programa y nos llamó la atención de inmediato por algunas de sus características que son muy raras en el mundo de las Amenazas Persistentes Avanzadas.

Algunos de los nombres de archivo que se usaron en el ataque son:

  • FT - Ukraine Russia's new art of war.doc
  • Катастрофа малайзийского лайнера.doc
  • Diplomatic Car for Sale.doc
  • МВКСИ.doc
  • Organigrama Gobierno Rusia.doc
  • Фото.doc
  • Информационное письмо.doc
  • Форма заявки (25-26.09.14).doc
  • Информационное письмо.doc
  • Письмо_Руководителям.doc
  • Прилож.doc
  • Car for sale.doc
  • Af-Pak and Central Asia's security issues.doc

Por lo menos uno de estos nombres nos recuerda a RedOctober, que usaba uno muy parecido en sus ataques dirigidos: "Diplomatic Car for Sale.doc". Al indagar sobre la operación comenzaron a surgir más detalles que apoyaban esta teoría.

Tal vez lo más raro fue que el exploit de Microsoft Office no escribió una puerta trasera de Windows PE directo en el disco. En vez de ello, escribió un script de Visual Basic y lo ejecutó.

Carga explosiva del exploit de Cloud Atlas - VBScript

Este VBScript despliega un par de archivos en el disco – un cargador y una carga explosiva cifrada. El cargador se ve diferente cada vez y las cadenas de caracteres internas indican que se está generado de forma "polimórfica". La carga explosiva siempre está cifrada con una llave única, haciendo que sea imposible descifrarla a no ser que el DLL esté disponible.

Encontramos varios documentos de ataques dirigidos spear-phishing que despliegan cargas explosivas con nombres únicos. Por ejemplo, el MD5 del archivo “qPd0aKJu.vbs”:

E211C2BAD9A83A6A4247EC3959E2A730 despliega los siguientes archivos:

DECF56296C50BD3AE10A49747573A346 - bicorporate – carga explosiva cifrada
D171DB37EF28F42740644F4028BCF727 - ctfmonrn.dll - cargador

El VBS también agrega una llave de registro:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\, estableciendo la llave “bookstore” al valor “regsvr32%path%\ctfmonrn.dll /s", que se asegura de que el programa malicioso se ejecute cada vez que se inicie el sistema.

Algunos de los nombres DLL que observamos incluyen:

f4e15c1c2c95c651423dbb4cbe6c8fd5 - bicorporate.dll649ff144aea6796679f8f9a1e9f51479 - fundamentive.dll
40e70f7f5d9cb1a669f8d8f306113485 - papersaving.dll
58db8f33a9cdd321d9525d1e68c06456 - previliges.dll
f5476728deb53fe2fa98e6a33577a9da - steinheimman.dll

Estos son algunos de los nombres de la carga explosiva:

steinheimmanpapersaving
previliges
fundamentive
bicorporate
miditiming
damnatorily
munnopsis
arzner
redtailed
roodgoose
acholias
salefians
wartworts
frequencyuse
nonmagyar
shebir
getgoing

La carga explosiva incluye un bloqueo cifrado de configuración con información sobre el servidor C&C:

La información de configuración incluye una URL WebDAV que se usa para hacer conexiones, un nombre de usuario y contraseña, dos carpetas en el servidor WebDAV que se usan para almacenar complementos/módulos para el malware y donde se supone que se guardan los datos de la víctima.

Comunicaciones C&C

Los implantes de Cloud Atlas utilizan un mecanismo C&C bastante inusual. Todos los ejemplares del malware que hemos visto se comunican mediante HTTPS y WebDav con el mismo servidor en la nube “cloudme.com”. Según su sitio web, la compañía CloudMe AB, que opera desde Linköping, Suecia, es la dueña y responsable de CloudMe.

(Nota importante: No creemos que CloudMe tenga ninguna relación con el grupo Cloud Atlas – los atacantes sólo crean cuentas gratuitas en este servidor y las utilizan para controlar los equipos infectados).

Sin embargo, cada conjunto de malware que hemos visto hasta ahora se comunica con una cuenta diferente de CloudMe. Los atacantes suben datos a la cuenta y el implante los descarga, descifra e interpreta. Cuando le toca, el malware sube las respuestas al servidor mediante el mismo mecanismo. Por supuesto, se podría reconfigurar el programa para usar cualquier servicio de almacenamiento basado en la nube que funcione con WebDAV.

Esta es una de las cuentas de CloudMe:

Los datos de la cuenta:

El programa malicioso subió los archivos almacenados en la carpeta de nombre aleatorio. Contienen varias cosas, como información del sistema, procesos en ejecución y nombres de usuario actuales. Los datos se comprimen con LZMA y cifran con AES, pero las llaves se guardan en el cuerpo del programa, lo que hace posible descifrar la información desde el C&C.

Sólo habíamos observado otro grupo que usaba un método como este - ItaDuke –, conectándose a cuentas en el servidor en la nube mydrive.ch.

Estadísticas sobre las víctimas: los 5 países con mayor cantidad de infecciones

 CloudAtlasRedOctober
Rusia1535
Kazajistán1421
Bielorrusia45
India214
República Checa2< 5

Semejanzas con RedOctober

Los datos de la Kaspersky Security Network (KSN) indican que, igual que RedOctober, el blanco principal de Cloud Atlas es Rusia, seguido de cerca por Kazajistán. Es más, hemos visto una superposición obvia de blancos entre ambos, con diferencias sutiles que se dan por los cambios geopolíticos de la región que ocurrieron durante los últimos dos años.

Lo interesante es que algunos de los documentos sobre los ataques phishing dirigidos entre Cloud Atlas y RedOctober explotan el mismo tema y se usaron para atacar a la misma entidad en diferentes momentos.

CloudAtlasRedOctober

Tanto los implantes Cloud Atlas como RedOctober dependen de una estructura similar, con un cargador y una carga nociva final que se almacena cifrada y comprimida en un archivo externo. Pero también hay algunas diferencias importantes, en especial en los algoritmos de cifrado que se usan -š RC4 en RedOctober vs. AES en Cloud Atlas.

El uso de los algoritmos de compresión en Cloud Altas y RedOctober es otra semejanza interesante. Ambos programas maliciosos comparten el código del algoritmo de compresión LZMA. En CloudAtlas se usa para comprimir los registros y descomprimir las cargas explosivas descifradas de los servidores C&C, mientras que en RedOctober, el complemento “planificador” lo usa para descomprimir las cargas explosivas ejecutables del C&C.

Resulta que la implementación del algoritmo es idéntica en ambos módulos maliciosos, pero la forma en la que se lo invoca tiene algunas diferencias: la versión CloudAtlas tiene algunos controles de sanidad de entrada adicionales.

Otra semejanza interesante entre ambas familias de malware es la configuración del sistema de construcción que se usa para compilar los binarios. Cada binario que se crea usando la cadena de herramientas Microsoft Visual Studio tiene un encabezamiento especial con información sobre la cantidad de objetos de ingreso y la información de la versión de los compiladores que se usaron para crearlo: el encabezamiento “Rich”, que adopta su nombre de la cadena mágica que se usa para identificarlo en el archivo.

Hemos identificado varios binarios de RedOctober que tienen encabezamientos “Rich” describiendo con exactitud la disposición de los objetos de archivo VC 2010 + VC 2008. Aunque esto no implica necesariamente que los binarios se hayan creado en el mismo ordenador, no hay duda de que se compilaron usando la misma versión del Microsoft Visual Studio, šcon el mismo número de compilación y una configuración de proyecto parecida.

Número de archivos objeto, cargador CloudAtlasCantidad de archivos de objeto, complemento Office de Red OctoberCantidad de archivos de objeto, complemento Fileputexec de Red OctoberVersión del compilador HEXVersión del compilador descifrado
010101009D766FVC 2010 (compilación 30319)
010101009B766FVC 2010 (compilación 30319)
222E6000AB766FVC 2010 (compilación 30319)
5B60A300010000
05071100937809VC 2008 (compilación 30729)
725CAD00AA766FVC 2010 (compilación 30319)
201018009E766FVC 2010 (compilación 30319)

Resumiendo las semejanzas entre ambos:

 Cloud AtlasRedOctober
Marcador Shellcode en documentos afectados por ataques de spearphishingPT@TPT@T
País más atacadoRusiaRusia
Algoritmo de compresión que se usó para las comunicaciones C&CLZMALZMA
Servidores C&C dicen ser / redirigen aBBC (malware paraš móviles)BBC
Versión del compilador VC 2010 (compilación 30319)VC 2010 (compilación 30319) (algunos módulos)

Por último, tal vez la conexión más fuerte viene de los ataques dirigidos. Según demuestran las observaciones de la KSN, algunas de las víctimas de RedOctober también son blanco de ataques de CloudAtlas. En al menos uno de los casos, el ordenador de la víctima recibió sólo dos ataques en los últimos dos años: uno con RedOctober y otro con Cloud Atlas.

Estos y otros detalles nos hacen pensar que CloudAtlas es un renacimiento de los ataques de RedOctober.

Conclusión

Después de grandes anuncios y exposiciones públicas de ataques dirigidos, los grupos de APT actúan de forma predecible. La mayoría de los atacantes que hablan chino sólo reubican los servidores C&C, recopilan los programas maliciosos y siguen adelante como si nada hubiera pasado.

Otros grupos que están más nerviosos con su exposición entran en un estado de hibernación por meses o años. Algunos nunca vuelven a usar las mismas herramientas y técnicas.

Sin embargo, cuando se expone una operación de ciberespionaje de gran magnitud, es muy raro que los atacantes dejen de actuar por completo. Sólo se desconectan por algún tiempo, actualizan sus herramientas y regresan con más fuerza.

Creemos que esto es lo que pasó con RedOctober, que está regresando con estilo en la forma de Cloud Atlas.

Los productos Kaspersky detectan el programa malicioso del conjunto de herramientas Cloud Atlas con los siguientes veredictos:

Exploit.Win32.CVE-2012-0158.j
Exploit.Win32.CVE-2012-0158.eu
Exploit.Win32.CVE-2012-0158.aw
Exploit.MSWord.CVE-2012-0158.ea
HEUR:Trojan.Win32.CloudAtlas.gen
HEUR:Trojan.Win32.Generic
HEUR:Trojan.Script.Generic
Trojan-Spy.Win32.Agent.ctda
Trojan-Spy.Win32.Agent.cteq
Trojan-Spy.Win32.Agent.ctgm
Trojan-Spy.Win32.Agent.ctfh
Trojan-Spy.Win32.Agent.cter
Trojan-Spy.Win32.Agent.ctfk
Trojan-Spy.Win32.Agent.ctfj
Trojan-Spy.Win32.Agent.crtk
Trojan-Spy.Win32.Agent.ctcz
Trojan-Spy.Win32.Agent.cqyc
Trojan-Spy.Win32.Agent.ctfg
Trojan-Spy.Win32.Agent.ctfi
Trojan-Spy.Win32.Agent.cquy
Trojan-Spy.Win32.Agent.ctew
Trojan-Spy.Win32.Agent.ctdg
Trojan-Spy.Win32.Agent.ctlf
Trojan-Spy.Win32.Agent.ctpz
Trojan-Spy.Win32.Agent.ctdq
Trojan-Spy.Win32.Agent.ctgm
Trojan-Spy.Win32.Agent.ctin
Trojan-Spy.Win32.Agent.ctlg
Trojan-Spy.Win32.Agent.ctpd
Trojan-Spy.Win32.Agent.ctps
Trojan-Spy.Win32.Agent.ctpq
Trojan-Spy.Win32.Agent.ctpy
Trojan-Spy.Win32.Agent.ctie
Trojan-Spy.Win32.Agent.ctcz
Trojan-Spy.Win32.Agent.ctgz
Trojan-Spy.Win32.Agent.ctpr
Trojan-Spy.Win32.Agent.ctdp
Trojan-Spy.Win32.Agent.ctdr
Trojan.Win32.Agent.idso
Trojan.Win32.Agent.idrx
HEUR:Trojan.Linux.Cloudatlas.a
Trojan.AndroidOS.Cloudatlas.a
Trojan.IphoneOS.Cloudatlas.a

El troyano “Destover” ahora tiene una firma digital de Sony


  Global Research & Analysis Team (GReAT), Kaspersky Lab       15 diciembre 2014 | 15:38  MSK

Comentar  

Hace varios días, nuestros productos detectaron un ejemplar inusual de la familia Destover. La familia de troyanos Destover se estuvo usando en los notorios ataques conocidos como DarkSeoul en marzo de 2013 y en las más recientes amenazas contra Sony Pictures en noviembre 2014. Escribimos al respecto el 4 de diciembre, en una entrada en la que también hablamos de sus posibles vínculos con el ataque de Shamoon de 2012.

Lo inusual del nuevo ejemplar es que está firmado por un certificado digital válido de Sony:

El ejemplar firmado se había visto antes, pero sin la firma, como MD5: 6467c6df4ba4526c7f7a7bc950bd47eb y parece que se compiló en julio de 2014.

El nuevo ejemplar tiene el MD5 e904bf93403c0fb08b9683a9e858c73e y parece que se firmó el 5 de diciembre de 2014, hace pocos días.

En cuanto a su funcionamiento, la puerta trasera tiene dos C&Cs y se intenta conectar con ambos de forma alterna, con retrasos entre las conexiones:

  • 208.105.226[.]235:443 - United States Champlain Time Warner Cable Internet Llc
  • 203.131.222[.]102:443 - Thailand Bangkok Thammasat University

¿Qué significa esto? Los certificados robados de Sony (que los atacantes también filtraron) pueden usarse para firmar otros programas maliciosos. Estos, a su vez, también pueden emplearse en otros ataques. Como las soluciones de seguridad confían en los certificados digitales de Sony, los ataques son más efectivos. Hemos visto ataques en el pasado que emplean certificados de confianza para burlar los programas de las listas blancas y las políticas de negación de acceso predeterminada.

Hay hemos denunciado el certificado digital a COMODO y Digicert y esperamos que pronto se agregu a las listas negras. Los productos Kaspersky seguirán detectando los ejemplares del programa malicioso aunque tengan firmas digitales.

Número de serie del certificado robado:

  • ‎01 e2 b4 f7 59 81 1c 64 37 9f ca 0b e7 6d 2d ce

Huella digital:

  • ‎8d f4 6b 5f da c2 eb 3b 47 57 f9 98 66 c1 99 ff 2b 13 42 7a

Desde que publicamos esta entrada del blog, se descubrió que este ejemplar puede haber sido una "broma" de un grupo de investigadores de seguridad.š Esto generó preguntas entre los periodistas y otros miembros de la comunidad, así que decidimos abordarlas en esta actualización:

1. ¿Se encontró el ejemplar firmado rondando en Internet?

Hasta ahora, no hemos visto muestras del ejemplar firmado rondando libre en la red. Sólo hemos visto que se ha enviado a servicios de análisis de malware online. Sin embargo, la existencia de este ejemplar demuestra que la llave privada estaba en dominio público. Es por eso que nos dimos cuenta de que teníamos una situación muy seria en nuestras manos, sin importar quién había sido el responsable de firmar el programa malicioso.

Los informes indican que el “investigador” se dirigió a las autoridades de certificación para que revocaran el certificado después de haber enviado el programa malicioso a Internet. El certificado se habría revocado sin crear un nuevo programa malicioso. En realidad no había necesidad de crear nuevos programas maliciosos para probar que el certificado todavía no se había revocado.

2. ¿Se sabe cuántos certificados de Sony se filtraron?

Hasta ahora hemos visto decenas de archivos PFX filtrados en Internet. Los archivos PFX contienen las llaves privadas y certificados necesarios. Los archivos están protegidos por una contraseña, pero puede adivinarse o forzarse con facilidad. No todos estos archivos PFX son de un valor primordial para los atacantes.

3. ¿Cuál es el peligro de que se filtre un certificado para firmar códigos de una gran corporación?

La importancia de la filtración de llaves para firmar códigos no debe subestimarse. El sistema operativo, los programas de seguridad y los primeros usuarios suelen confiar en los programas firmados por una entidad de confianza, por lo que esta es una herramienta muy poderosa para que los cibercriminales ataquen sin ser detectados.

La revocación de certificados debe ser una prioridad al responder a grandes incidentes e intrusiones de malware.

4. ¿Confían más los productos antivirus en los programas con una certificación de “confianza” que en aquellos que no están firmados?

La confianza en los archivos se basa en su reputación, y las firmas digitales juegan un rol muy importante en ello. Pero una firma digital por sí misma no basta para generar confianza. Nos fijamos en la reputación de las entidades que emitieron y solicitaron el certificado.

Los productos Kaspersky Lab detectan los archivos con firmas digitales. Nuestros productos detectaron la variante firmada de Destover con la rutina de detección creada para la primera variante de Destover.

Sony/Destover: El historial de destrucción del misterioso actor norcoreano


  Kurt Baumgartner       15 diciembre 2014 | 13:24  MSK

Comentar  

Esta semana, por primera vez, el FBI emitió una alerta “Flash” sobre las actividades de eliminación de datos de un troyano Limpiador (Wiper) que se está usando en los ataques a Sony Pictures Entertainment. Las muestras de este programa malicioso, conocido como Destover, contenían archivos de configuración creados en sistemas que usaban paquetes de idiomas en coreano.

Desde que se descubrieron los ataques ha salido a flote nueva información sobre el programa malicioso, pero algunos detalles, como los referidos a la actividad previa de los principales sospechosos, todavía se están evaluando.

Mientras Sony Pictures realiza su costosa limpieza en silencio y se prepara para lanzar la película “Una loca entrevista”, discutamos las actividades previas del grupo sospechoso y algunas de las características del programa, que tiene notorias similitudes con otros limpiadores.

Lo primero que llama la atención es que las actividades destructivas dirigidas a las redes de grandes organizaciones son cada vez más comunes. Aquí se discuten algunos programas limpiadores anteriores. La mayoría de estos casos ocurrió en Oriente Medio y la península de Corea. También encontramos un caso llevado a cabo por la APT BE2 que afectaba a ICS, del que se habla en mayor detalle aquí. No podemos ignorar la eliminación completa de datos de Code Spaces en Gran Bretaña, llevada a cabo por un cibercriminal que secuestró la información para extorsionar a sus dueños, como se cuenta aquí.

El programa malicioso que se usó en el ataque a Sony Entertainment se llama Trojan Destover y puede eliminar los datos almacenados en unidades de discos y registros de arranque principal (MBR).

Características del limpiador Destover

Los aspectos más interesantes de las características destructivas del malware son la selección y el almacenamiento/difusión de los controladores que ahora son comunes en estos ataques de sabotaje.

El instalador de malware Destover instala y ejecuta controladores EldoS RawDisk para evadir los permisos de seguridad NTFS y así poder sobrescribir los datos en el disco y el Registro de arranque principal. Esto tiene un impacto en la recuperación de datos. En el caso del malware DarkSeoul, los datos sobrescritos pueden restaurarse con un método similar al de recuperación de los datos “destruidos” por Shamoon. Es posible que se pueda recuperar los datos de Destover de la misma manera.

La cadena de componentes intermediarios que dirigen a la carga explosiva destructiva pasa por varias etapas (que ya se han descrito en otra parte) que pueden ejecutarse en diferentes modos, tal como lo hace Shamoon:

  1. El ejemplar se ejecuta por primera vez en un sistema operativo de 32 bits.
  2. El ejemplar se ejecuta en un sistema operativo de 32 bits como un servicio autoinstalable, con una o varias rutas de código.
  3. El ejemplar se ejecuta en un sistema operativo de 64 bits como un servicio autoinstalable.

En primera instancia, crea el servicio brmgmtsvc “Gestión de Copias de seguridad y Restauración” de Windows, añade su propio ejecutable y un interruptor "-i". También descarga varias copias de sí mismo y ejecuta cada una de ellas con un interruptor diferente: -m, -d y -w.

-m (sobrescritura del MBR):
Intenta conectarse con las tres direcciones IP. La ejecución del proceso se lleva a cabo aunque no logre hacerlo.
Busca su recurso que contiene el controlador EldoS RawDisk y lo escribe en el directorio temporal como "usbdrv3.sys".
Después, instala el controlador como el servicio usbdrv3 "USB 3.0 Host Controller”.
A continuación, inicia el servicio del controlador y cierra su identificador.
Después crea un identificador de archivos para el controlador con permisos de escritura:
'\\?\ElRawDisk\??\\PhysicalDrive0#99E2428CCA4309C68AAF8C616EF3306582A64513E
55C786A864BC83DAFE0C78585B692047273B0E55275102C664C5217E76B8E67F35FCE385E43
28EE1AD139EA6AA26345C4F93000DBBC7EF1579D4F'
y escribe en el identificador con cadenas de caracteres de 64k de “0xAAAAAAAA”. ← el asunto de la gran extensión de la llave de licencia (#99E2428…) se explora en nuestra entrada del blog Shamoon el Limpiador: más detalles (Parte II).
Después crea nuevos subprocesos, cada uno de los cuales intenta conectarse a cualquier unidad conectada y sobrescribirla.

-d (sobrescritura de datos):
Intenta conectarse con las tres direcciones IP. Una vez más, se lleva a cabo una ejecución de procesos aunque no logre establecer una comunicación.
Consigue las unidades lógicas y las atraviesa recursivamente, identificando todos los archivos de datos. Si no es un proceso .exe o .dll, sobrescribe los contenidos del archivo con “0x0df0adba” en un fragmento de 20k. La sobrescritura se completa desde el modo de usuario, sin los controladores EldoS.
Después, trata de eliminar los archivos de datos usando el api win32 “DeleteFileW”. Mientras realiza su acción recursiva a través de todos los directorios del sistema, intenta eliminar los archivos .exe y .dll.

-w (servidor web):
Intenta conectarse con las tres direcciones IP. Una vez más, se lleva a cabo una ejecución de procesos aunque no logre establecer una comunicación.
Detiene Terminal Services de Windows desde la línea cmd: 'cmd.exe /c net stop termservice /y'
Después encuentra resource#85, lo descomprime y escribe sus contenidos en “c:\windows\iissvr.exe".
Ejecuta el proceso iisvr.exe y se retira.
Iisvr es lo que parece: un servidor web que tiene un archivo cifrado JPG, HTML y WAV. Espía el Puerto 80 y le entrega estos archivos. La alerta verde con todos los gráficos puede encontrarse más adelante en el artículo. Este es el jpg descifrado:

Por último, después de dos horas de sueño, el servicio original reinicia el equipo con una llamada a ExitWindowsEx(EWX_REBOOT|EWX_FORCE, 0). Esto obliga a una salida pero retrasa el apagado en sí mientras se mantenga el estado de creación de archivos de sistema.

Similitudes entre los limpiadores

Como Shamoon, los controladores del limpiador Destover son archivos de EldoS RawDisk disponibles de forma comercial.

Al igual que Shamoon, los controladores del limpiador Destover se mantienen en la sección de recursos del instalador de malware.

Shamoon y el limpiador DarkSeoul tienen en común que ambos incluyen vagos mensajes pseudo-políticos cifrados para sobrescribir los datos del disco y el Registro de Arranque Maestro (MBR).

Así como DarkSeoul, los ejecutables del limpiador Destover se compilaron en algún momento entre las 48 horas previas y el día del ataque. Es muy improbable que los atacantes hayan lanzado ataques phishing dirigidos a una cantidad grande de usuarios, y muy posible que hayan conseguido acceso completo a la red entera antes del ataque.

Los componentes de Shamoon se compilaron en un periodo de tiempo igual de limitado antes de propagarse. Las marcas de tiempo CompiledOn indican que se crearon alrededor de cinco días antes de que se detonasen sus ejecutables. Casi todos se compilaron el 10 de agosto de 2012 (entre las 00:17:23 y las 02:46:22) y debían detonarse el 15 de agosto de 2012. Es una brecha muy corta de tiempo para desplegar estos binarios, considerando las decenas de miles de equipos que se destruyeron con este ataque.

En los tres casos: Shamoon, DarkSeoul y Destover, los grupos que se hicieron cargo de la destrucción de los programas en las grandes redes no tenían una historia real ni una identidad propia. Todos hicieron un esfuerzo por desaparecer después de actuar, ninguno hizo declaraciones coherentes, sólo acusaciones extrañas y llenas de rodeos sobre conductas criminales, e instigaron sus actos destructivos justo después de un acontecimiento político que se sugirió como el eje del conflicto.

Las imágenes de los grupos “Whois” de DarkSeoul y “GOP” de Destover incluyen una declaración “Hackeado por” acompañado por una "advertencia” y amenazas sobre los datos robados. Ambos amenazaron con su retorno diciendo que éste era sólo el inicio. Parece que el mismo dibujo de un esqueleto se incluyó en ambos ataques.

Gráficos y advertencia de Whois:

Gráficos y advertencia de GOP:

Las diferencias entre los ataques de los limpiadores Destover y DarkSeoul incluyen la falta de scripts *nix para eliminar particiones en sistemas Linux.

Por supuesto, estas similitudes no prueban que el grupo responsable de los ataques de Shamoon sea el mismo que el de DarkSeoul y Destover. Pero hay que notar que los actos reaccionarios y las características de las herramientas y operaciones del grupo tienen similitudes muy marcadas. Es extraordinario que actos tan inusuales y concentrados de destrucción virtual a gran escala se estén llevando a cabo con similitudes tan fáciles de reconocer.

Actividad de redes

Los destinos señalados se publicaron como:

  • 88.53.215.64
  • 217.96.33.164
  • 203.131.222.102

Pero ejemplares con una relación directa llaman a otras direcciones IP. Los datos de la Kaspersky Security Network (KSN) indican que ninguna de estas direcciones difundía programas maliciosos en el pasado:

  • 58.185.154.99
  • 200.87.126.116
  • 208.105.226.235
  • 212.31.102.100

Las conexiones parecen arbitrarias e inconsecuentes con la ejecución del paquete malicioso. Algunas ni siquiera están activas en la actualidad. Todas estas IPs parecen seleccionadas de una forma extraña.

Se sabe que algunas de estas direcciones han realizado análisis RDP hace poco. A finales de 2012, 217.96.33.164 era conocido por hacer escaneos de RDP con fuerza bruta. El servidor está alojado en una dirección IP en Polonia desde 1996.

A principios de 2014, 88.53.215.64 estaba alojado en Italia y funcionaba como un servidor proxy “Hide My Ass” Premium y gratuito en el Puerto 443. El malware trata de conectarse al servidor en los puertos 8000 y 8080, y en la actualidad no tiene recursos disponibles.

200.87.126.116 también funcionaba como un proxy SOCKS gratuito en 2011 y 2012. Los spammers y estafadores de SEO utilizaban este tipo de recursos con frecuencia para lanzar sus ataques.

Puertas traseras anteriores

Las operaciones de DarkSeoul tienen vínculos con varias familias de troyanos y puertas traseras que se han estado usando a lo largo de muchos años. Algunos vínculos son mucho más fuertes que otros:

  • Concealment Troy
  • DarkSeoul
  • HttpDr0pper
  • HttpTroy
  • TDrop

MD5s de Destover

Troyanos:

MD5TamañoFecha de compilaciónNombre de Kaspersky
d1c27ee7ce18675974edf42d4eea25c6262 kb2014.11.22 00:06:54Trojan.Win32.Destover.a
2618dd3e5c59ca851f03df12c0cab3b8430 kb2014.11.22 00:05:02Trojan.Win32.Destover.d
760c35a80d758f032d02cf4db12d3e55244 kb2014.11.22 04:11:08Trojan.Win32.Destover.c
b80aa583591eaf758fd95ab4ea7afe39304 kb2014.11.24 04:12:55Trojan.Win32.Destover.b
e1864a55d5ccb76af4bf7a0ae16279ba112 kb2014.11.13 02:05:35Backdoor.Win32.DestoverServ.a
a3fa8c7eb4f061ab8b9f7829c6741593111 kb2014.05.03 07:10:22Trojan.Win32.Destover.f
2c545b89acdb9877da5cbb96653b149153 kb2014.07.14 13:38:18Trojan.Win32.Destover.e
e904bf93403c0fb08b9683a9e858c73e90 kb2014.07.07 08:01:09Trojan.Win32.Destover.d

Controladores Eldos:

6aeac618e29980b69721158044c2e544 (32 bits), firmado por EldoS Corporation
86e212b7ec20fc406c692400294073ff (64 bits), firmado por EldoS Corporation

Certificado (6aeac618e29980b69721158044c2e544 32-bit y
86e212b7fc20fc406c692400294073ff 64-bit):


    Data:
Version: 3 (0x2)
Serial Number:
01:00:00:00:00:01:10:0c:98:3a:31
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, OU=ObjectSign CA, CN=GlobalSign ObjectSign CA
Validity
Not Before: Jan 10 15:20:07 2007 GMT
Not After : Jan 10 15:20:07 2010 GMT
Subject: C=VG, O=EldoS Corporation, CN=EldoS Corporation/emailAddress=info@eldos.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:d7:60:2f:bf:3c:85:1b:f3:a1:19:8c:4d:0e:49:
c5:a5:f5:16:15:b6:ea:91:e2:c2:92:7b:d6:e5:2a:
1e:68:8c:7b:28:eb:07:dc:b0:3a:dd:11:ee:84:a9:
8b:6f:04:b0:ae:c2:2d:bc:b7:56:41:61:e1:ae:01:
0d:0e:83:47:00:3a:ca:b5:12:fb:e5:b6:55:ac:e0:
94:00:5b:e0:61:70:24:ba:d9:ef:4a:e2:af:8f:21:
93:9e:8b:83:17:2a:e4:3d:74:e6:07:c8:4a:69:ed:
60:9b:89:6e:5b:85:50:49:52:f9:fa:91:63:9f:61:
a7:ea:e2:3e:d7:1b:07:22:a1
Exponent: 65537 (0x10001)
X509v3 extensions:
Netscape Cert Type:
Object Signing
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:
keyid:D2:5B:F3:4B:26:4B:A5:B0:E7:5D:FD:56:7F:F6:F1:2E:38:4E:53:A0
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.globalsign.net/ObjectSign.crl
Signature Algorithm: sha1WithRSAEncryption
44:0d:5b:2c:f4:c3:c0:91:c0:9f:4d:91:f0:25:5c:79:72:ff:
82:7a:a8:97:fb:08:2b:c2:eb:ae:4b:78:b6:a8:0f:5b:3a:1d:
12:c9:07:81:d0:16:e0:94:1e:69:3c:43:c1:d8:85:b1:4c:1a:
21:84:1c:c8:ed:0a:7e:e4:55:b7:f8:ae:69:a8:b0:8c:10:da:
6e:57:f4:a3:62:5b:2b:4f:06:25:a9:35:f0:63:cc:3f:e0:f6:
4c:ee:1d:d8:9f:d8:ae:d3:fe:de:3b:0b:c5:f3:19:1c:2a:37:
ad:0d:5c:87:5e:da:8f:31:02:d3:78:5d:f1:30:28:78:c3:86:
f7:b2:f6:6c:2d:d8:45:8a:8b:16:eb:bb:d0:6e:5b:98:68:8e:
9b:cc:7e:77:9d:0d:b3:5f:01:d8:57:26:6d:cf:85:2a:46:52:
0f:79:93:85:f7:19:14:01:73:d5:03:e7:96:1a:16:cd:24:0b:
67:6d:f9:72:55:b8:b9:e9:be:07:58:b3:01:bd:a1:18:57:bb:
b3:19:e5:88:0e:f5:96:fe:eb:b8:66:a6:c6:2c:62:b5:21:59:
f2:d9:4d:2b:d1:59:20:07:13:78:26:dc:d5:b3:d1:55:47:5e:
2e:cb:cb:cc:04:7c:d5:e2:9d:7c:24:b1:18:70:da:1f:54:5b:
59:88:d1:17

Data:
Version: 3 (0x2)
Serial Number:
01:e2:b4:f7:59:81:1c:64:37:9f:ca:0b:e7:6d:2d:ce
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com,
CN=DigiCert Assured ID Code Signing CA-1
Validity
Not Before: Sep 18 00:00:00 2012 GMT
Not After : Sep 22 12:00:00 2015 GMT
Subject: C=US, ST=California, L=CULVER CITY, O=Sony Pictures Entertainment Inc.,
CN=Sony Pictures Entertainment Inc.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b6:08:80:f6:6d:9c:3a:f4:fb:45:bc:bd:6a:27:
e5:97:23:fa:6a:5d:39:08:97:37:53:13:70:85:1b:
0e:08:b1:b7:5f:e3:78:6e:b1:6b:26:7a:82:86:f8:
37:2d:b0:b2:65:f0:8a:56:c7:e1:1a:88:19:f9:00:
bd:c3:4b:8d:97:10:b6:9a:09:14:8d:95:0a:75:56:
cd:c5:2f:1c:ad:21:82:cb:8c:ad:8d:78:11:1e:b8:
50:94:90:96:7a:e4:69:38:9c:bd:2f:4c:8c:2b:23:
45:f1:ac:59:2f:10:12:d4:64:3a:9b:41:5d:14:2b:
56:10:eb:c6:15:ed:1d:f0:06:d3:0e:9e:96:8e:c1:
0e:cf:62:17:7c:c7:a9:d5:2a:40:99:d6:a2:68:93:
f6:02:2a:1e:95:e6:1e:a4:d6:c4:fd:61:7d:d7:15:
9a:1f:2d:ab:4e:fc:61:9f:d8:54:55:8e:79:d3:57:
8a:22:14:31:d4:a4:4e:a5:43:ec:4b:35:04:8d:f8:
10:37:10:3f:bb:2a:ae:b7:b8:a1:16:f4:f6:02:df:
97:fc:32:95:97:38:23:48:c2:96:b3:aa:9f:88:66:
26:eb:d4:70:38:2f:84:b1:e0:1e:a1:27:5f:3f:14:
b7:dd:4c:f2:c7:22:6a:1a:f8:85:1a:57:23:b3:c7:
58:1f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:7B:68:CE:29:AA:C0:17:BE:49:7A:E1:E5:3F:D6:A7:F7:45:8F:35:32

X509v3 Subject Key Identifier:
51:6E:D7:E5:BB:2E:FD:39:6B:0D:37:D5:D0:70:6B:5A:8C:D6:11:F8
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
Code Signing
X509v3 CRL Distribution Points:

Full Name:
URI:http://crl3.digicert.com/assured-cs-2011a.crl

Full Name:
URI:http://crl4.digicert.com/assured-cs-2011a.crl

X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.3.1
CPS: http://www.digicert.com/ssl-cps-repository.htm
User Notice:
Explicit Text:

Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers -
URI:http://cacerts.digicert.com/DigiCertAssuredIDCodeSigningCA-1.crt

X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha1WithRSAEncryption
90:0f:0b:0f:93:f7:77:e7:34:dc:b4:2a:7e:bd:d1:0f:05:ac:
a5:9d:c8:1c:77:18:cd:28:90:28:e7:c6:ac:ad:f9:9e:b0:c6:
74:db:da:8c:b2:38:06:c5:a0:e4:cd:66:e4:ef:f7:21:58:1f:
9a:4f:17:3c:e1:af:c3:67:1e:37:ab:2a:2b:8f:7d:bc:9e:eb:
9b:f5:aa:c0:24:80:70:63:b0:2a:10:54:27:01:12:ec:61:12:
97:2d:98:c5:6f:e5:7e:1c:7c:17:2c:f5:ad:40:fb:b2:44:40:
fa:e1:02:45:22:7d:6f:6d:04:fc:ff:2c:d2:e5:2f:3e:49:5c:
72:4b:0c:5a:ce:6e:13:44:79:f9:b9:26:d9:2e:6f:4d:05:72:
0d:d2:e9:bc:66:88:af:63:5b:1b:44:50:a4:c7:e4:bc:73:d6:
ac:25:7c:1a:88:37:c2:71:3f:1c:32:38:32:12:55:75:db:55:
6d:d9:1e:40:a7:d3:35:f4:bf:86:a3:72:60:49:c3:a4:9a:2e:
4d:5d:0d:4d:97:2b:34:91:5c:e1:e6:a9:93:eb:d2:62:2a:ef:
a1:73:6e:a4:0b:22:d4:31:a8:d5:53:9d:26:29:e1:1c:4a:04:
c5:8a:df:15:01:42:6f:a2:b3:3b:da:2e:e5:4c:b5:53:6b:76:
86:b2:25:29


Investigaciones previas y paralelas

El arte de encontrar esqueletos de ciber-dinosaurios


  Global Research & Analysis Team (GReAT), Kaspersky Lab       12 diciembre 2014 | 19:10  MSK

Comentar  

“La investigación de APTs es como la paleontología…”

Nuestro informe sobre la operación cibernética gubernamental Regin despertó dudas sobre si las compañías antivirus retienen información – y detecciones – de forma deliberada cuando los gobiernos y sus clientes se lo piden. Bruce Schneier inició una discusión similar en 2013.

Primero aclaremos lo más importante: Ningún cliente o gobierno nos ha pedido jamás que agreguemos a nuestras listas blancas o dejemos de detectar ningún ejemplar específico de malware. Nunca lo haríamos, sin importar quién lo pida.

No va a pasar. Algunas veces, las investigaciones de ataques dirigidos avanzados incluyen acuerdos de confidencialidad con los clientes, pero esto no evita que agreguemos la detección de los programas maliciosos que descubramos para proteger toda nuestra base de datos contra las nuevas amenazas.

Entonces, ¿por qué nos tomó dos años publicar un informe sobre Regin? Si ignoramos el contexto, se puede llegar a pensar que los investigadores escondieron algo muy importante por la gran cantidad de tiempo que pasó. Sin embargo, las investigaciones de seguridad –como las de las autoridades legales– necesitan pasar por un análisis meticuloso y, en muchos casos, es importante ver cómo se desarrolla un crimen en tiempo real para construir un caso sólido.

Como nuestros recursos son limitados y estamos siguiendo varios actores de Amenazas Persistentes Avanzadas (APTs) a la vez (Careto/Mask, EpicTurla, Darkhotel, Miniduke/Cosmicduke, entre otras), el proceso de llegar a comprender una operación cibercriminal por completo puede llegar a tomar meses y hasta años.

Sean Sullivan, de F-Secure, hizo una descripción perfecta de las investigaciones de APTs, comparándolas con el trabajo de los paleontólogos para encontrar huesos de dinosaurio. Todos pueden tener un hueso, pero nadie el esqueleto completo.

En el caso de Regin, lo que descubrimos en 2012 era un hueso dañado de una parte desconocida de un monstruo que vivía en un lago misterioso de las montañas.

(cortesía de southampton.ac.uk)

Cuando una persona común encuentra un hueso lo más probable es que lo descarte y siga su viaje, pero quienes estamos en la industria del análisis de seguridad los recolectamos. Agregamos el hueso a nuestra colección en el garaje. Tenemos varios huesos fracturados que podrían ser de monstruos desconocidos o criaturas inofensivas. A veces escuchamos que otras personas descubren fragmentos de huesos y revisamos nuestra colección, pero en las primeras etapas no hay suficiente evidencia para llegar a conclusiones significativas. No vale la pena hacer públicos nuestros descubrimientos hasta que confirmemos que los monstruos son reales, grandes y peligrosos.

Seguimos desarrollando medios para recolectar diferentes artefactos que nos puedan ayudar a combinar algunas de las piezas de nuestra colección. A veces trabajamos con otros “paleontólogos” y compartimos nuestros descubrimientos. Cuando conseguimos suficientes huesos para comprobar que estamos ante la presencia de un monstruo y tenemos una idea de su tamaño, peligro y posible hábitat, pasamos a la siguiente fase: una investigación activa en el mundo real para llegar al misterioso lago de la montaña.

Un intenso proyecto de investigación de APTs consiste en varias etapas:

  1. Agregar la detección para los módulos conocidos
  2. Recolectar de ejemplares
  3. Revertir las muestras
  4. Descifrar los cifrados y compresiones complejas
  5. Comprender el movimiento lateral de la amenaza
  6. Definir las múltiples etapas de ataque en el orden correcto
  7. Mapear la infraestructura C&C
  8. Instalar drenajes (sinkholes)
  9. Analizar el tráfico recolectado y protocolos de comunicación
  10. Arrastrarse hacia otros anfitriones que comprenden el mismo protocolo
  11. Cerrar y conseguir imágenes de los servidores C&C
  12. Identificar a las víctimas, notificarles de la situación e informar a las CERTs
  13. Hacer análisis forenses y extraer registros, archivos robados y otros componentes
  14. Recolectar y analizar datos de KSN, servidores C&C, víctimas que quieran ayudarnos, drenajes, arañas web, etc.
  15. Escribir un informe completo

Si tenemos suerte y encontramos al monstruo en su hábitat, esa es la mejor fuente para hacer el estudio. En la mayoría de los casos, entre ellos Regin, observamos y aprendemos del comportamiento del monstruo vivo. Registramos cada uno de sus pasos y acciones.

También podemos atraparlo y estudiarlo en un laboratorio, como zoólogos. Pero, en muchas investigaciones, sólo conseguimos su esqueleto. Debemos unir todas las piezas y reconstruir la forma en la que se movía para develar sus hábitos, las especies que atacaba y cómo coordinaba estos ataques. En pocas palabras: se necesita tiempo y paciencia.

Además, cuando analizamos las características de una criatura, comprendemos que la evolución sigue su curso y que hay otras especies como la que estamos estudiando, vivas y felices en algún lugar aunque no podamos verlas.

Aunque detectamos algunos de los ejemplares de Regin hace tiempo y seguimos encontrando muestras y artefactos a lo largo de la investigación, estamos convencidos de que existen otros que todavía no han sido descubiertos. Se sabía poco sobre su vida y existencia en el pasado, pero sabemos que están presentes gracias a los pequeños rastros que encontramos con el tiempo. Y debemos volver a hacer el paralelismo con la paleontología, porque a gran escala sólo hemos descubierto una pequeña parte de la bestia, pero tenemos suficiente material como para publicar una alerta pública

Como pasó con Regin, a veces descubrimos que hemos estado detectando fragmentos de un programa malicioso por muchos años antes de darnos cuenta de que forman parte de una operación global de ciberespionaje. Un buen ejemplo de ello es la historia de RedOctober. Habíamos estado detectando componentes de RedOctober mucho antes de que descubriésemos que se estaba usando en ataques dirigidos contra organizaciones diplomáticas, gubernamentales y de investigación científica.

En Kaspersky Lab procesamos cientos de miles de ejemplares al día. El arte de diferenciar los más significativos y, además, los que pertenecen a una APT expandida, equivale a encontrar una aguja en un pajar y descubrir a qué costurero pertenece. A pesar de las dificultades, nos alegra encontrar cada una de las agujas, porque nos permite hacer de éste un mundo un poco más seguro.

Page Top  |  Archivo >>

 

Copyright © 1996 - 2015
Kaspersky Lab
Todos los derechos reservados

Correo electrónico: webmaster@viruslist.com