Detección de dominios DNS maliciosos utilizados por APT

24 de abril de 2015 Por

(N.d.A. La información de este post está basado en gran parte en un paper de Wei Xu, Kyle Sanders & Yanxin Zhang titulado WE KNOW IT BEFORE YOU DO: PREDICTING MALICIOUS DOMAINS, que puedes descargar desde este enlace en PDF o ver aquí en html)

Comencemos diciendo que existen tres tipos de nombres de dominios DNS: buenos (o legítimos), malos y corruptos (es decir, nombres de dominios legítimos que han sufrido algún tipo de ataque).

Un nombre de dominio se puede considerar malicioso tanto por su contenido (malware, paginas web con exploits o con descargas automáticas, etc.) como por su comportamiento (comunicación con máquinas infectadas para el envío de información, lanzamiento de ataques, etc.). Hay que tener en cuenta que un dominio malicioso suele usarse durante un corto periodo de tiempo, ya que de este modo se abaratan costes además de dificultar su detección, puesto que son dominios creados específicamente con este propósito.

Además de las herramientas que todo el mundo conoce para el análisis de dominios DNS (Automater, URL Query, Virus Total, DNS Query, Domain Tools…), existen ciertas características y patrones que estos siguen que también nos pueden ayudar en la predicción del grado de legitimidad de un dominio. Basando nuestro análisis en el ciclo de vida del dominio DNS (preparación, activación, desactivación o bloqueo) y en la reutilización de recursos, encontramos ciertas características y patrones útiles para su detección, que veremos a continuación.

Las primeras alarmas vienen dadas por el hecho de que muchos dominios DNS maliciosos se reutilizan, después de su detección, para otras campañas de ataques. El intervalo de tiempo que suele haber entre su uso inicial y posterior es aproximadamente de un año, tiempo en el que los dominios previamente detectados han vuelto al mercado y han sido borrados de las DNBL. Además, durante el tiempo en el que permanecen desactivados, estos dominios suelen sufrir cambios en su registro y su contenido. Además, otra característica de los dominios DNS maliciosos es que la mayoría de estos resuelven como domain parking, es decir, no tienen asociado ningún servicio.

Si encontramos estas dos características por separado probablemente el dominio haya sido malicioso, pero hemos de tener en cuenta que la mayoría de ellos no se suelen reutilizar con malos propósitos.

Por lo que respecta a las peticiones DNS, podemos extraer ciertos patrones útiles en nuestra predicción antes de que dicho dominio sea usado o detectado. De estos, la mayoría están relacionados con la fase de preparación y test del dominio:

  • Cambios en los registros DNS, como por ejemplo, activación de servidores, realizar un test de resolución de DNS, etc.
  • Patrones temporales de peticiones DNS. Bien porque encontremos dominios cuyo número de peticiones DNS sufre un brote repentino en cuanto a volumen, o bien, porque las peticiones DNS sigan patrones periódicos.
  • Patrones en QNAME (Query Domain Name). Tenemos este tipo de patrones cuando el dominio ha sido generado mediante un DGA (Domain Generation Algorithm), o si se asemeja a algún dominio malicioso conocido o a algún dominio popular y legítimo, sin tener ninguna relación.

Por supuesto, este tipo de características no son determinantes; los dominios también deben pasar un test de detección de contenido JS/HTML maliciosos y ser clasificados en base a las características extraídas de los registros DNS, las direcciones IP, etc. Si ambos tests devuelven positivo, entonces podemos considerar dicho dominio como malicioso. Además, si queremos diseñar una herramienta de detección debemos tener en cuenta que los tests que deberían pasar los dominios DNS son sensibles al tiempo.

Por otra parte, también podemos analizar las posibles conexiones entre los patrones de comportamiento de dominios maliciosos ya conocidos y los que estemos analizando:

Si su servidor de nombres (NS) coincide con el de un dominio malicioso conocido, podremos considerarlo un indicio siempre que descartemos NS legítimos como registradores de DNS, proveedores CDN (Content Delivery Network), web hosting (alojamiento web), etc.; y NS que abastecen a muy muy pocos dominios maliciosos. Para este tipo de análisis necesitaríamos recopilar y mantener una lista de servidores de dominios maliciosos conocidos, teniendo en cuenta el flujo de datos del Passive DNS, es decir, los registros de NS que apuntan a NS de la lista. Cualquier dominio que cumpla dicha condición podría ser considerado malicioso.

Si encontramos coincidencias en direcciones IP, podemos encontrarnos con dos casos:

  • La primera, que coincidieran con direcciones IP utilizadas por dominios maliciosos conocidos, sabiendo que debemos descartar las direcciones IP utilizadas por diferentes dominios, como por ejemplo, direcciones IP en CDN o web hosting.
  • La segunda, que encontrásemos coincidencias con direcciones IP infectadas e identificadas como sinkhole, es decir, direcciones IP utilizadas para cambiar el flujo de URL maliciosas mediante la inserción de una entrada falsa en el NS. Estas URL se pueden deducir de servidores C&C ya conocidos. Debemos tener presente que direcciones IP comerciales o de portales pueden tener estas mismas características y por tanto, se deben descartar.

Algunas herramientas de este tipo basan el filtrado principalmente en la localización y la información de asignación de las direcciones IP y el conocimiento de los posibles dominios de CDN/web hosting/otras empresas.

En cuanto a la información de registro, podemos establecer una conexión entre dominios maliciosos si encontramos similitudes entre nombres de los titulares de registros de dominios maliciosos o coincidencias entre las direcciones, los teléfonos o los emails de los titulares de los registros.

En definitiva, si queremos diseñar un sistema de detección de dominios DNS maliciosos, además de integrar las típicas herramientas de análisis de dominios DNS que todos conocemos, debemos analizar un conjunto de características que sin duda harán de nuestro sistema una herramienta más robusta.

Premio SIC 2015 a S2 Grupo

23 de abril de 2015 Por

(N.d.E. Interrumpimos la programación habitual para anunciar una noticia de la que nos sentimos muy orgullosos)

Desde que S2 Grupo comenzó su andadura hace ya unos cuantos años, los que formamos parte de ella hemos visto cómo años tras año ha sido galardonada con diferentes premios y reconocimientos, incluyendo el premio que este mismo blog recibió hace ya unos años.

En este caso, es la revista SIC la que, en la duodécima convocatoria de sus Premios SIC y coincidiendo con la edición XXVI del congreso global de ciberseguridad, seguridad de la información y privacidad Securmática, concede a S2 Grupo uno de sus premios por su “apuesta firme por la excelencia en la prestación de servicios de seguridad de la información, incluyendo la I+D+i y los servicios gestionados“.

La revista SIC, con una experiencia en el sector de más de 20 años y organizadora de Securmática, Respuestas SIC y Espacio TiSEC, reconoce a través de este premio el buen hacer en materia de seguridad de la información de nuestra empresa.

Desde S2 Grupo queremos agradecer a la revista SIC que nos haya concedido este premio, comprometiéndonos a seguir trabajando duro para que no sea el último.

¿Te sobran 3 Millones de Euros?

22 de abril de 2015 Por

¿Por qué tres millones de euros? Porque, como veremos a lo largo del post, los costes de un ataque informático están en torno a esa cifra. Prevenirnos frente a este tipo de pérdidas es, más que una opción, una necesidad.

Cuantificar qué cantidad de tiempo y dinero debe dedicar una empresa u organismo a impedir los ataques a su infraestructura IT es siempre una cuestión complicada. Por un lado hay que tener en cuenta el apetito por el riesgo que tenga la organización en cuestión y por otro hay que calcular qué precio va a tener la reparación de los daños que provoque un posible ataque informático. A este último tema va dedicado este post: ¿qué coste tiene un compromiso en los sistemas de IT? ¿Cuánto nos va a suponer en robo y fraude directo, multas, pagos a terceros perjudicados, y costes de nuestra IT interna? Vamos a arrojar un poco de luz sobre este tema recordando algunos casos.

Los compromisos de datos en el pasado se ocultaban hasta que eran descubiertos por un tercero, los clientes, los partners, auditores… con lo que tener información sobre los costes de unos compromisos en la mayor parte de los casos no conocidos era tarea difícil. Poco a poco se ha extendido la conciencia de que dar luz a estos hechos es una buena práctica para evitarlos y un derecho de los posibles perjudicados cuyos datos están en manos de terceros no autorizados. Más aún, en ciertos países, sobre todo anglosajones, la ley obliga a informar de las brechas en la seguridad. De esta forma hay diferentes casos publicados (ver por ejemplo http://datalossdb.org).

[Read more…]

Gestión de incidentes práctica. Actuaciones ante malware (III)

21 de abril de 2015 Por

Una vez solicitados y aplicados los bloqueos iniciales es posible analizar el documento con más calma, esto sirve principalmente para adquirir inteligencia sobre el malware y encontrar métodos más eficientes de gestionar incidentes relacionados con él. Por lo que se volverá a repetir la fase Incident Resolution, en esta ocasión el tiempo de respuesta no es tan importante, ya se han realizado las primeras tareas de contención, la empresa debería estar libre de este Malware o camino de estarlo.

5. Fase 5 – Incident Resolution II.

5.a. Data Analysis II: La primera tarea es descargar el fichero “File.exe”. La última vez que lo comprobé aún seguía disponible (09-4-2015). También es recomendable mirar las macros por si hubiese alguna información más. Desde office nos solicita contraseña:

[Read more…]

Introducción al desarrollo de transforms para Maltego

20 de abril de 2015 Por

Una de las características más interesantes de Maltego, herramienta ya potente de por sí, es la posibilidad de desarrollar nuestras propias transformadas, o transforms, para ampliar sus capacidades.

De forma simplificada, una transform no es más que una “caja negra” que toma como entrada una entidad (o entity), y produce como salida una o más entities. Estas entities, ya sean de entrada o de salida, son de cierto tipo (por ejemplo, de tipo Person, EmailAddress, etc.) y deben tener un valor (o value) determinado. Adicionalmente, una entidad puede tener cero o más campos (o fields) extra que pueden enriquecer su valor semántico (cada field está formado por un nombre y un valor).

Las transforms pueden ser locales o remotas: las primeras se ejecutan en la misma máquina donde corre el propio programa cliente de Maltego, mientras que las segundas residen en los llamados servidores TDS (Transform Distribution Service), de forma que el programa cliente de Maltego envía la entity de entrada y recibe de los servidores la entity o entities de salida.

Centrándonos ya en la programación en sí de las transformadas, objeto de la presente entrada, el interfaz para el desarrollo de las transforms locales es sumamente sencillo: cualquier programa que reciba como parámetros el value de la entity de entrada (y, opcionalmente, los nombres y valores de los fields extra), y genere código XML en el formato de especificación de las entities de salida (con sus respectivos valores, etc.), puede registrarse en el programa cliente de Maltego y funcionar como una transform más.

[Read more…]

Gestión de incidentes práctica. Actuaciones ante malware (II)

17 de abril de 2015 Por

Una de las metodologías más usadas para la gestión de incidentes es la metodología publicada por ENISA (European Union Agency for Network and Information Security), que se va usar como guía para la resolución del incidente.

Después de una primera aproximación a este ejercicio mediante el primer artículo de la serie, continuamos con la gestión del incidente.

Este artículo está propuesto a modo de ejercicio, así que se pueden ir siguiendo los diferentes pasos. También se va a mantener un timeline que refleja el tiempo que llevó cada uno de los pasos, teniendo en cuenta que no es el primer incidente de este tipo que se gestiona, por lo que el equipo de respuesta ante incidentes está formado y en plena forma.

En los incidentes de seguridad son muy importantes los tiempos de resolución y los tiempos que se emplean en las diferentes fases. El incidente está enfocado a un doc con Macros maliciosas de los cuales últimamente se están dando multitud de oleadas, ya que es una manera fácil y sencilla de saltarse las protecciones de los antivirus.

Este incidente está basado en un caso real que se detectó en el SOC de S2 Grupo hace unos días.

Desde el enlace https://www.securityartwork.es/wp-content/uploads/2015/03/Virus_cuidado.zip, comprimido con la contraseña “Infected”, se pueden obtener los especímenes de malware a analizar. EL MALWARE DEL ENLACE ES REAL Y ES UTILIZADO ACTIVAMENTE EN INTERNET, NO ES UN FICHERO INOFENSIVO CREADO AD-HOC COMO PRUEBA DE CONCEPTO, por lo que es responsabilidad del lector garantizar la seguridad de su propio equipo y su red si decide abrir cualquiera de los ficheros que contiene. No descargue el fichero comprimido si no sabe lo que está haciendo. Security Art Work publica la muestra con fines educativos, pero no se responsabiliza del mal uso accidental o intencionado que pueda hacerse del malware. Insistimos: si no sabe muy bien lo que está haciendo, NO DESCARGUE EL FICHERO. Los experimentos con gaseosa.

Vamos allá. Empezamos con la gestión.

1. Fase 1 – Incident report – 10:27 del 8 de Abril de 2015: El sistema de correlación de eventos avisa de que se ha detectado un envío masivo de ficheros .doc a multitud de cuentas de la empresa. Además el documento ha disparado la siguiente regla YARA:

rule OfficeMacrosWinintelDLL
{
	meta:
		Autor = "Manuel Bermudez"
		date = "08-01-2015"
		description = "Fichero office con macros sospechosa"
		link = "https://www.securityartwork.es/"
	strings:
		$VBA1 = "VBA6"
		$VBA2 = "VBA7"
		$str1 = "wininet.dll" nocase
		$str2 = "InternetOpenUrl" nocase
		$str3 = "InternetReadFile" nocase
		$str4 = "InternetOpen" nocase
 		$str5 = "InternetCloseHandle" nocase
	condition:
		1 of ($VBA*) and 2 of ($str*)
}

Disponemos de los siguientes datos del fichero en cuestión:

Nombre: (Payment) 04.07.15.doc
SHA256: 8008a15c8321807da9c1ed31db3c00e10dd9d2b84ea15e6d285f35b95eb7c882

2. Fase 2 – Registration – 10:32 del 8 de Abril de 2015: Registramos el incidente, para lo que normalmente siempre se dispone de una herramienta de ticketing que permite hacer el seguimiento de los incidentes. Damos de alta el incidente siendo lo más descriptivos posible, como por ejemplo:

Número Evento: XXXX
Descripción: Recibido doc con posibles Macros maliciosas
__________________________________________________________________

Descripción detallada: Se han recibido multitud de correos con un mismo fichero adjunto que podría ejecutar una macro maliciosa que presumiblemente se descargara algún recurso.
Nombre: (Payment) 04.07.15.doc
SHA256: 8008a15c8321807da9c1ed31db3c00e10dd9d2b84ea15e6d285f35b95eb7c882
MD5: 05a94cd1e361bdee1c9c780036a7c956
SHA1: 8e813356b36ebcf50334794dce4d6e66a1a18b7c

3. Fase 3 – Triage: es un término médico que proviene del francés. Básicamente se trata de determinar qué necesitamos para diagnosticar y resolver el incidente, así como tratar de determinar el posible impacto.

4. Fase 4 – Incident Resolution – 10:35 del 8 de Abril de 2015. Esta es la fase más larga y se describe como un ciclo básico compuesto por 5 pasos, como se ve en la imagen. Esta una de las fases más importante y es necesario ser lo más eficientes posibles para proponer soluciones iniciales, dado que cuanto antes se implementen las soluciones menos equipos se infectaran.

4.a. Data Analysis – 10:40 del 8 de Abril de 2015: Se procede a analizar el documento. Por la información de la que se dispone, se trata de un doc con macros. Existen varias maneras de proceder, como por ejemplo analizarlo con las oletools u oledump. Sin embargo, teniendo en cuenta que el tiempo apremia, lo mas eficiente es copiarlo directamente a la máquina virtual y ejecutarlo, debido a que cada vez las macros están más ofuscadas o bien tienen contraseña, así que una manera que casi con total seguridad va funcionar es ejecutarla en la máquina virtual, que recordemos que no está conectada a internet (ésta está simulada).

Esto es lo se ve al abrir el fichero “(Payment) 04.07.15.doc”:

Al ejecutar las Macros observamos cómo en el DNSchef del equipo anfitrión nos muestra que se ha realizado una petición:

La consola en la que se ha puesto el puerto 80 a escuchar también nos da más datos:

Con esta información ya podemos poner en marcha acciones de contención, así que pasamos a la siguiente fase sin olvidar de documentar con todos los datos nuevos que hemos obtenido.

4.b. Resolution research – 10:50 del 8 de Abril de 2015. La idea de esta “subfase” es básicamente buscar una solución, que en este caso es evidente: bloquear el dominio para impedir que los usuarios que ejecuten las macros se infecten, así como implementar reglas de detección para localizar posibles equipos infectados.

4.c. Action proposed – 10:52 del 8 de Abril de 2015. Se solicita al departamento que corresponda el filtrado del dominio “www.droopy999.w.interia.pl” para que los usuarios no puedan navegar por el. Este proceso normalmente se realiza en el proxy de navegación o en firewall. También se solicita que se implementen las siguientes reglas en el IDS (casi todos los IDS/IPS del mercado suelen aceptar reglas con sintaxis de snort):

alert udp any any -> any 53 (msg:"S2-Malware Doc con Macro Maliciosa"; 
content:"www|09|droopy999|01|w|07|interia|02|pl" ; classtype:trojan-activity; sid:XXXXXX; rev:1;)

alert tcp any any -> any $HTTP_PORTS (msg:"S2-Malware Doc con Macro Maliciosa"; 
content:"www.droopy999.w.interia.pl" ; classtype:trojan-activity; sid:XXXXX; rev:1;)

Es muy importante seguir documentando la incidencia, haciendo especial hincapié en las hora de solicitud de las diferentes acciones.

4.d. Action Performed. En este punto debemos realizar la acción, ya sea realizando las solicitudes pertinentes podemos o aplicando los filtros si es un aspecto que entra dentro de nuestras competencias. En este punto se puede pasar a la siguiente fase.

4.e. Eradication and Recovery – 10:57 del 8 de Abril de 2015: en este paso buscamos información para saber cuántos usuarios han ejecutado las macros. Para esto necesitaremos los logs de navegación, en los que buscaremos equipos que hayan accedido a “http://www.droopy999.w.interia.pl/11/004.exe”.

La recomendación suele ser formatear dichos ordenadores si el departamento de soporte correspondiente dispone de un protocolo para hacerlo, también podemos comprobar si el antivirus lo detecta y erradica. Si no es así, la mayoría de empresas de antivirus te permite enviarle ejemplares para añadirlas en su fichero de firmas. Para ello debemos descargarnos el fichero “004.exe” y hacérselo llegar, aunque la experiencia nos dice que, en la mayor parte de los casos, es mucho más rápido y efectivo formatear los equipos infectados.

Aunque puede parecer que ya estamos en disposición de finalizar la alerta, aún nos queda hacer otra pasada sobre la fase 4 Incident Resolution, ya que al tener el virus es posible detectar si existen equipos infectados. En el siguiente post analizaremos el fichero “004.exe” y procederemos al cierre del incidente.

La línea de tiempo es aproximada, pero este virus se detectó el 8 de Abril de 2015 por la mañana y la detección en virustotal en ese momento era de 1/57. En menos de media hora se pudo analizar el documento y proponer una solución, siempre documentando cada una de las fases.

Evasión de WAFs

16 de abril de 2015 Por

WAF (Web Application Firewall) es un elemento de protección frente a ataques que se encarga de analizar el tráfico web dirigido a los distintos portales que pueda disponer una organización. Este tipo de firewalls se diferencia del resto en que procesa el tráfico HTTP(s) a nivel de la capa 7 de la pila OSI y por lo tanto permite capacitarlo de reglas de detección directamente sobre las tecnologías con las que estén diseñados y desarrollados los sitios web. Además, podemos diferenciar este tipo de dispositivos de lo que denominamos un IPS por las características de identificación de patrones anómalos.

Normalmente pueden operar en 3 modos:

  • Modo negativo, o basado en listas negras.
  • Modo positivo, o basado en listas blancas.
  • Modo mixto, empleando una combinación de los modos negativo y positivo.

Si se emplea el modo negativo exclusivamente, éste puede provocar una cantidad mayor de falsos positivos, además de sufrir un retardo mayor en el tiempo de procesamiento y en definitiva menor protección. En el lado positivo, tiene un menor tiempo de implementación.

[Read more…]

Gestión de incidentes práctica. Actuaciones ante malware (I). Laboratorio.

15 de abril de 2015 Por

En esta serie de tres artículos se va a proponer un ejercicio de gestión de un incidente, concretamente un incidente relacionado con Malware. Se aplicará una de las metodologías de resolución de incidentes más extendida, y se analizaran las diferentes acciones que se deben tomar para gestionar un incidente relacionado con un malware. En este caso vamos a trabajar en un incidente relacionado con malware real, por lo que se necesitara un laboratorio para poder analizar el espécimen.

Además de una Cuckoo sandbox, que podéis ver como se instala en este otro artículo, vamos a necesitar una serie de herramientas:

Un equipo anfitrión, en este caso se trata de un Linux, con el siguiente software:

Equipo huésped Windows XP:

[Read more…]

Denegación de servicio a un PLC Omron con comandos legítimos en FINS

14 de abril de 2015 Por

Hace poco leí un artículo en el blog de Shodan titulado “Why control systems are on the Internet” escrito por John Matherly (fundador de Shodan), en el que comentaba un párrafo de la documentación oficial de Omron donde se explica porqué la conexión a internet de los PLCs de esta marca es completamente segura.

Su robusta teoría se basa (o se basaba, desconozco si han cambiado su punto de vista) en que sus PLCs no tenían un sistema operativo basado en Windows ni se comunicaban a través de un puerto conocido con un protocolo estándar de Ethernet, lo que los haría invisibles a los malvados ojos de los atacantes.

Según esta curiosa pero extendida manera de concebir la seguridad, sería extremadamente extraño que, por ejemplo, alguien se descargara la especificación oficial del protocolo FINS (protocolo industrial de Omron) de la página web oficial e intentara comunicarse con un PLC.

Para ponernos en contexto, la manera legítima de configurar y trabajar con los componentes industriales de la marca Omron es con el software de esta marca CX-One, que comprende distinto software como el CX-Programmer, diseñado para la configuración y programación de los PLCs.

Aunque estos PLCs pueden disponer de diferentes módulos de comunicación como Ethernet, están diseñados con la idea de que bajo cualquier problema que surja, siempre sea posible una conexión en serie de manera física.

[Read more…]

Hardware Hacking, Row Hammer y Light Eater

13 de abril de 2015 Por

En la actualidad, en el mundo de la seguridad recibimos continuamente anuncios de vulnerabilidades de software y sus correspondientes actualizaciones de seguridad. Prácticamente no pasa un solo día en el que no aparezca una nueva vulnerabilidad. La gran mayoría de estas vulnerabilidades aprovechan fallos en la implementación del software para obtener por ejemplo ejecutar código, elevar privilegios, superar mecanismos de validación, obtener información, etc.

Es obvio que en el mundo de la seguridad la atención se centra las potenciales vulnerabilidades en el software, y no falta razón. No obstante, el problema radica en la creencia firme de que los dispositivos hardware que ejecutan el mismo son perfecta y completamente seguros. Nada más alejado de la realidad; el hardware está formado por multitud de bloques de circuitos interconectados que interactúan de una forma muy compleja, y es fundamental que se tenga en cuenta la seguridad en el diseño y ensamblado de los componentes.

Dentro de la cadena de fabricación de, por ejemplo, la placa base de un ordenador personal cualquiera, se emplean distintos chipset de distintos fabricantes y características, como la BIOS, los controladores de memoria, los chipset de bridge, controladores ATA, etc. Y qué decir de cuando a esa misma placa conectamos distintos dispositivos, todos ellos con sus propios componentes. Es fácil hacerse una idea de la complejidad que puede alcanzar un sistema aparentemente convencional. Por lo que, para poder “controlar” la seguridad a este nivel se deberían llevar medidas de control y verificación hasta los propios fabricantes de los dispositivos o los que los ensamblen equipos.

[Read more…]