El ransomware ha venido para quedarse. Eso es algo que está quedando claro. Se trata de un negocio muy lucrativo a tenor del éxito en la tasa de efectividad en la infección, y aunque menor, en la tasa de pagos del rescate por parte de los afectados.

A los ya infames Cryptolocker, CryptoWall, TorrentLocker, TeslaCrypt y demás, se han sumado recientemente HydraCrypt y UmbreCrypt, todos con ligeras variaciones sobre el anterior en un intento de evitar las escasas barreras que están introduciendo las casas de antivirus, junto con alguna iniciativa más o menos ocurrente, y más o menos efectiva, para identificar la actividad de este tipo de amenaza.

Recientemente, el CNI, a través del CCN-CERT, publicó una guía sobre el ransomware en el que se recogían algunas de las variantes junto con herramientas de descifrado de los archivos que han ido proporcionando las diferentes casas de antivirus tras la desarticulación de alguna red de criminales o tras un análisis profundo de las muestras.

[Read more…]

Todos los días se producen infecciones de equipos que, si bien no suponen un gran impacto en la organización en la mayoría de casos, sí conviene actuar para que el cúmulo de éstos no suponga un riesgo para la información de la misma. Además, ante el desconocimiento de cualquier actividad sospechosa que pudiera estar realizando un activo, conviente tomar medidas antes de encontrarnos con un incidente grave.

En esto consiste la respuesta ante incidentes en equipos de usuario. Aunque sabemos que los antivirus son necesarios en cualquier equipo (sin descuidar los servidores), no impiden que los sistemas acaben comprometidos, por lo que otros mecanismos de detección son necesarios, como los NIDS o HIDS. Una vez se detecta un posible compromiso en un equipo, debemos confirmarlo antes de emprender las acciones de erradicación, por lo que viene bien una respuesta rápida ante incidentes que permita analizar el equipo de forma ágil y con el mínimo impacto en la actividad del usuario.

[Read more…]

Últimamente se están identificando numerosas campañas de correos maliciosos con ficheros adjuntos; en especial, con variantes de Cryptolocker o CTB-Locker y demás tipo de ransomware.

En la mayoría de casos se trataba de un archivo ejecutable, con extensión .EXE, directamente incluido en un archivo comprimido ZIP sin contraseña. Entre tanto ejecutable, hace unos días llegó un correo diferente que no contenía un ejecutable sino un archivo VBS. En realidad, se trataba de un archivo con doble extensión (algo muy habitual para engañar al usuario y hacerse pasar por un archivo XLS, en este caso).

El correo venía con el asunto “This is your Remittance Advice [ID:92251]” y un archivo adjunto con el nombre VW3840QVDZ.zip, que contenía un supuesto archivo de hoja de cálculo:

5104afe7f36cd6ba8d0ad13848d1b38c963fbb42ea51532c3b01e21805971c72 VW3840QVDZ.zip
f19315d0757362859022e40d7d64a46d5a50227e35d1e10f3c1c7731821ec8ac 8323241AZ#632463.xls.vbs

Evidentemente, este último archivo no se trata de un archivo de Excel, sino un script en Visual Basic con el siguiente contenido:

Se trata de código ofuscado utilizando la función chrw, que convierte números enteros en caracteres, para no mostrar el código original. Además, el entero lo representa como suma de dos números. Al final del código vemos una función que ejecuta el anterior código almacenado en la variable nt:

Desde el punto de vista de un Blue Team, debemos identificar qué realiza este código para tratar de contener el posible incidente de seguridad sin ejecutar el código. Al tratarse de código VisualBasic script, podemos modificar el código para llamar a una función que muestre el contenido de la variable nt, como imprimirla por pantalla o en un archivo, en lugar de ejecutarla. Para esto, vamos a sustituir la última línea por otro código que escriba el valor de nt en un archivo de texto de la siguiente manera:

De esa forma mostramos el código ejecutado por el código en el archivo script.txt, donde vemos que se trata de un dropper de otro archivo sospechoso descargado desde un servidor ubicado en Rusia:

Vemos que el código se trata de una llamada a powershell.exe, para descargarse el recurso casma.gif, descomprimirlo y ejecutarlo. Aquí tenemos el primer elemento de contención: bloquear la dirección IP del servidor desde el que nos descargamos este archivo sospechoso.

Tras conseguir el archivo desde un origen diferente al atacado, podemos analizar el ejecutable.

El archivo parece comunicarse con el servidor 188.120.225.17, también ubicado en Rusia, al que posiblemente le envíe información a través de peticiones POST y otros servidores repartidos por varios países, por lo que tenemos un gran número de direcciones IP a bloquear y contener el posible incidente antes de que se materialice.

Conclusiones

Entre las medidas que tomamos para la contención, hay que bloquear la dirección IP desde la que el dropper descarga el malware para evitar que los usuarios puedan verse comprometidos.
También hay que bloquear la dirección IP <188.120.225.17> para evitar que el malware se comunique con el que es supuestamente el servidor de control o donde se envía la información capturada.

Por último, entre las lecciones aprendidas para evitar que ocurra un incidente similar se encuentra la formación y concienciación al usuario final para no abrir correos sospechosos ni sus adjuntos. No obstante, a nivel técnico tiene una solución bastante sencilla, como bloquear los correos que contengan adjuntos en formato ejecutable (EXE, BAT, VBS, SCR y demás archivos ejecutables).

Yara es una iniciativa que cada vez va consiguiendo un mayor uso en el ámbito de la gestión de incidentes, en especial este último año. Este proyecto ha sido ampliamente comentado en artículos de este y otros blogs.

En esta ocasión voy a mostrar un ejemplo práctico del uso de yara para la gestión de incidentes provocados por ransomware. Estos últimos meses ha habido un aumento de actividad de este tipo de malware que, a pesar de las numerosas advertencias realizadas por aquellos que nos dedicamos a la seguridad y la gestión de incidentes, sigue teniendo un impacto bastante grande. Afortunadamente, los últimos incidentes de ransomware en los que he participado, el compromiso únicamente ha afectado a un usuario en cada caso, lo que ha permitido centrarnos más en el alcance de los archivos cifrados que en la identificación de posibles equipos comprometidos.

Identificación de extensión

Uno de los primeros casos en los que tuvimos que participar fue un incidente con CTB-Locker. En esta ocasión, un usuario reporta un mensaje que le aparece en su escritorio informando que sus archivos han sido cifrados y se solicita un rescate para su recuperación. Una vez contenido parte del incidente desconectándolo de la red e identificando que es el único equipo afectado (no vamos a extendernos en este punto) pasamos a determinar qué archivos han sido cifrados y cuáles pueden recuperarse (nunca recomendamos pagar por su rescate).

[Read more…]

En Seguridad se utiliza habitualmente el símil de la cadena y el eslabón más débil; ese que dice que la fortaleza de una cadena reside en el eslabón más débil, de forma que por mucha seguridad que se implante en algunos de los sistemas de la infraestructura, todo se puede venir abajo si en algún sistema no se tiene la precaución de seguir las mínimas medidas de seguridad. Resulta que aquel sistema que se encuentra olvidado o se cree que no es importante y en el que no se cumple con las mismas políticas de seguridad puede convertirse en la puerta de entrada para un atacante a toda vuestra infraestructura.

Esta situación ocurre más a menudo de lo que pensamos, especialmente en infraestructuras medianas o grandes, donde siempre hay algún sistema que en su momento fue una prueba, o se trata de un sistema poco utilizado que quien lo administra ya no se encuentra en la organización…

Por muchos motivos un sistema puede quedar desactualizado y olvidado. También puede ocurrir que por los mismos motivos, no se cumpla con la política de seguridad de la organización (si es que se tiene alguna) y no se sigan las recomendaciones de seguridad porque “ya las aplicaremos cuando el sistema pase a producción…” contando con sistemas con credenciales por defecto o contraseñas débiles y fáciles de adivinar con ataques de diccionario. En ocasiones las credenciales de administración no se incluyen en las políticas de claves generales, son compartidas por todo el equipo de Sistemas y son más fáciles de adivinar de lo que se piensa.

[Read more…]

Recientemente he utilizado la versión 3 de Autopsy, la popular interfaz web de The Sleuth Kit, con idea de ver las novedades respecto a la versión anterior (v2). El hecho de estar acostumbrado a la versión 2, que la v3 sólo estuviera para Windows y además fuese basada en Java, habían hecho que hasta ahora no me hubiese decidido a probarla

Finalmente me he decidido y estas son algunas impresiones que he tenido.

La primera impresión que se tiene de la interfaz de usuario es que es bastante más amigable, moderna y usable que su antecesora web, con un acceso mucho más ágil a las diferentes partes de la aplicación. Una característica que he visto muy útil es el módulo de Ingest y la posibilidad de seleccionar los plugins que van a utilizarse; de esta forma, para ganar algo de tiempo, podemos realizar una ingesta de datos con un único plugin para tener algo sobre lo que trabajar y, mientras realizamos un análisis preliminar, podemos dejar cargando y procesando el resto de plugins.

Uno de los plugins que nos puede ahorrar algo de tiempo a la hora de descartar archivos conocidos sin manipular es la base de datos de hashes, que compara el hash de los archivos con dicha base de datos. La base de datos que es de obligada descarga es la NSRL del NIST, National Software Reference Library, con un tamaño actual de 6 GB de software conocido (tanto bueno como “malo”). No obstante, hay que recordar que no contiene entradas de malware sino más bien herramientas consideradas para hacking, desde nmap a herramientas de esteganografía. Otra pega es que, al parecer, sólo contempla versiones de software por defecto sin tener en cuenta las actualizaciones, por lo que puede crear falsos positivos o alertarnos ante archivos sospechosos aunque que se trate de actualizaciones lícitas.

Para utilizar esta base de datos tendremos que descargar la base de datos unificada, o bien las otras opciones más reducidas que también nos ofrece; y la importamos de la siguiente manera:

Tras lo que tendremos que indexar el contenido:

Una vez hecho esto, ya podemos realizar una nueva ingesta con el plugin del hash database activado, seleccionando la base de datos del tipo NSRL. Si queremos utilizar una base de datos de malware, tendremos que recurrir a algunas de pago o utilizar servicios online de consulta de hashes que nos dirá, uno a uno, si se reconoce como malware. Entre esos servicios online tenemos la Hash Database de SANS, OWASP File Hash Repository, Malware Hash Registry de Team Cymru, o VirusTotal, entre muchos otros.

El proceso de ingesta tardará dependiendo del tamaño de la imagen y la potencia del equipo, pero nos mostrará una columna con el resultado del hash y si se encuentra en las bases de datos (known/unknown en la NSRL o bad-known si tuviéramos otras de malware. A partir de ahí, podemos descartar aquellas detectadas como known y, aquellas que sean unknown y tengamos dudas, podemos utilizar dichos servicios online copiando el hash del archivo seleccionado.

Para sacarle un defecto que le he encontrado, aparte del hecho que he tenido que configurar el idioma del sistema al inglés debido a problemas de Java con el Timeline y las fechas, es que, no sé si debido a la diferencia entre el número de eventos entre meses u a otro, han desaparecido los eventos de enero y febrero, sin posibilidad de seleccionarlos en el Timeline, con lo que he tenido que sacarlos a través de búsquedas en esas fechas.

Para poder mostrar los archivos modificados en enero y febrero he tenido que recurrir a búsquedas filtradas por esas fechas. En su defensa diré que está funcionalidad aún se encuentra en estado Beta, por lo que son normales estos errores.

La verdad es que he visto una versión más moderna, completa y ágil de utilizar y, a pesar de algunos pequeños detalles, me ha convencido bastante.

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

Recientemente se informó de una vulnerabilidad 0-day en el kernel de Windows XP que estaba siendo explotada activamente. Esta vulnerabilidad estaba siendo aprovechada utilizando código malicioso dentro de un archivo PDF, que se apoyaba en otra vulnerabilidad para comprometer el sistema.

Aprovechando que el otro día estuvimos viendo cómo utilizar peepdf para analizar y extraer código JavaScript y shellcode de un archivo PDF malicioso, voy a describir en este artículo el análisis que realicé de este archivo con peepdf y otras herramientas utilizadas hasta extraer el exploit que está siendo utilizado en la última vulnerabilidad para Windows XP.

Análisis del PDF
Lo primero que hacemos es abrir el archivo PDF y analizar su estructura

offsets…

y la estructura de árbol

A partir de la información anterior vemos que hay código JavaScript en el objeto 3, que se ejecuta automáticamente cuando se abre el archivo. Veamos qué pinta tiene:

Se observa que, efectivamente se trata de código JavaScript pero éste está ofuscado y, como veremos, nos va a costar descifrarlo un poco. Si guardamos el código en una variable y aplicamos el comando js_beatufy, obtendremos un código un poco más legible:

La verdad es que sigue igual de ofuscado y con peepdf no se ha podido extraer más información sobre él. Ahora utilizaremos Firebug para examinarlo aunque para poder mostrarlo correctamente vamos a hacer unas pequeñas modificaciones, por lo que lo volcamos a un fichero y seguimos con el análisis. La última línea de código parece una llamada a una función dentro de otra llamada a la misma función donde se le pasa ese código ininteligible, así que vamos a pasar ese código a la función Q.$() y la almacenamos en una variable arg1. A continuación, pasamos arg1 de nuevo a la misma función y la almacenamos en arg2. Esto lo hacemos para detener el código en tiempo de ejecución y poder ver qué es ese código desofuscado.

Abrimos el código con Firebug e insertamos un breakpoint en la última llamada y vemos el valor del código resultante:

El código, ahora sí, es legible y bastante explícito, ya que comienza definiendo una variable llamada “shellcode”. Además de la definición del shellcode, comprueba la versión de Adobe Reader (versiones 9, 10 u 11) para añadir el ROP adecuado para cada versión.

Posteriormente llama a la función heapSpray para, como su nombre indica, inyectar el shellcode en la memoria.

Finalmente llama a la función addToolButton de Adobe:

Buscando información sobre esta función, vemos que existe una vulnerabilidad en algunas versiones de Adobe Reader donde dichas funciones podrían ser aprovechadas para ejecutar código (ver CVE-2013-3346).

Aprovechando esa vulnerabilidad se consigue ejecutar el shellcode descrito en este código así que pasamos a examinar qué hace este shellcode.

Análisis con scdbg

Cargamos el código en scdbg y lo ejecutamos. Observamos que crea un archivo SHELLC~1.drop_0 y se queda a la espera, buscando un descriptor de archivo (esto ocurre porque intenta leer un archivo que no existe).

Pensamos que el archivo que podría estar buscando es el propio PDF, desde el que el exploit está siendo ejecutado, así que vamos a indicarle la ruta del archivo que tiene que abrir con el parámetro fopen, que devuelve como descriptor de fichero el archivo indicado.

Ahora vemos que deja otro archivo en la misma ubicación con el nombre SHELLC~1.drop_1 e intenta ejectuar otro archivo creado en C:\Documents and Settings\Administrador\Configuración local\Temp con el nombre 4.tmp (en este caso). Este último está vacío por lo que entiendo que el que trata de ejecutar es SHELLC~1.drop_1 así que vamos a abrirlo para ver qué contiene y vemos que se trata de un ejecutable.

Este último archivo descargado es el exploit que aprovecharía la vulnerabilidad CVE/2013-5065. A partir de este punto tendríamos que analizarlo para ver cómo aprovecha la vulnerabilidad y qué trata de realizar.

Hay más información sobre el análisis de este archivo en los siguientes enlaces:
http://www.fireeye.com/blog/technical/cyber-exploits/2013/12/cve-2013-33465065-technical-analysis.html

http://www.invincea.com/2013/12/e-k-i-a-adobe-reader-exploit-cve-2013-3346-kernel-ndproxy-sys-zero-day-eop/
http://labs.portcullis.co.uk/blog/cve-2013-5065-ndproxy-array-indexing-error-unpatched-vulnerability/

A raíz de los numerosos correos sospechosos con archivos adjuntos en formato PDF que estamos detectando últimamente, he decidido introducirme en el análisis manual de estos archivos para determinar si son maliciosos y qué comportamiento tienen, en caso de serlo. En este artículo voy a mostrar un sencillo ejemplo de generación y análisis de un PDF malicioso. Para la demostración haré uso de Metasploit para generar el archivo PDF malicioso y REMnux para el análisis del fichero PDF y su contenido. Vayamos por partes, para comenzar.

Generación del PDF

La creación es sencilla: simplemente se elige el exploit para la vulnerabilidad que se quiere aprovechar, en este caso se crea un archivo PDF en blanco con una vulnerabilidad en GetIcon para Adobe Reader (CVE-2009-0927). El código a ejecutar será un conexión inversa a la máquina del atacante.

[Read more…]

El preprocesador reputacional de Snort no es algo nuevo; de hecho, apareció en agosto de 2011 con la versión 2.9.1. Hasta aquel momento, la única forma de manejar listas negras de direcciones IP era a través de reglas con el motor de detección, creando una regla con una lista de direcciones IP, como las utilizadas en el conjunto BotCC (emerging-botcc.rules).

alert tcp $HOME_NET any -> [103.6.207.37,106.187.42.91,106.187.48.236,107.20.73.183,
108.170.20.73,108.170.56.211,108.61.240.240,108.61.26.189,109.109.228.186,109.111.79.4,
109.163.233.16,109.163.233.22,109.196.130.50,109.228.25.175,109.234.106.53, 109.74.194.110,
112.175.124.170] any (msg:"ET CNC Shadowserver Reported CnC Server TCP (group 1)"; flags:S; 
reference:url,doc.emergingthreats.net/bin/view/Main/BotCC; reference:url,www.shadowserver.org; 
threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; 
flowbits:set,ET.Evil; flowbits:set,ET.BotccIP; sid:2404000; rev:3259;)

Esta forma tenía una limitación por lo que se creaban listas interminables de reglas relacionadas con una lista negra separadas en grupos teniendo alertas del estilo “ET CNC Shadowserver Reported CnC Server UDP (group 49)” o “ET COMPROMISED Known Compromised or Hostile Host Traffic UDP (43)”.

[Read more…]