(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Como ya habíamos comentado en entradas anteriores (ver parte I y parte II), la investigación estaba siendo bastante complicada: por ahora no habíamos sacado prácticamente nada en claro, y únicamente nos quedaba por analizar la imagen forense del ultrabook de R.G.

En muchas ocasiones el análisis forense tiene unos objetivos dirigidos: comprobar la existencia de unos ficheros, verificar por qué páginas ha navegado un usuario, detectar si se ha enviado un correo electrónico, etc… En este caso el análisis es el clásico generalista, el “tú mira y si encuentras algo raro nos lo dices”. La mejor forma de atacar estos análisis es mediante 3 pasos:

1. Recuperación de ficheros borrados: Recordemos que, cuando borramos la papelera, los datos no se borran realmente sino que se quedan marcados como disponibles para su uso. En muchos casos podemos recuperar información de ese espacio disponible.

2. Creación de una línea temporal: Una vez tenemos todos los ficheros podemos crear una línea temporal, un cronograma de lo que ha sucedido en el equipo.

3. Análisis de la información: Una vez tenemos toda la información espacio temporal llamamos al Dr Wh… digo cruzamos datos y realizamos un análisis mucho más completo.

[Read more…]

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Según lo visto en la entrada anterior, teníamos a nuestra disposición las siguientes evidencias digitales:

• Imagen forense (dd) de un GPS TomTom.
• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Ultrabook HP Spectre.

Una buena forma de comprobar una coartada es verificando la localización GPS, así que vamos a empezar con el análisis forense del navegador, un TomTom One. Si analizamos los artefactos forenses que podemos recuperar, vemos que nos interesan principalmente dos datos:

• Rutas programadas en el dispositivo: Queremos sobre todo la última ruta realizada, y la encontraremos en el fichero: MapSettings.cfg.
• Última conexión a GPS realizada: TomTom guarda la última conexión con la red de satélites GPS, algo que nos puede servir para corroborar la exactitud de la última ruta. Deberemos hacernos con el fichero CurrentLocation.dat.

[Read more…]

(N.d.A. Debido al revuelo que se ha montado a colación del post de hoy, nos vemos en la necesidad de aclarar que esta es una historia de ficción en la que nos hemos tomado ciertas licencias para justificar la intervención de lo que podría ser un equipo de seguridad externo (cuya colaboración en ocasiones se produce, no obstante). Todos los personajes y situaciones que aparecen en este y otros post de ficción no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.

En ningún caso se ha pretendido desmerecer la innegable labor de las FFCCSSE y el excelente trabajo que realizan día a día para proteger a los ciudadanos, tanto en el ámbito digital como en el físico. Asimismo, tampoco hemos querido poner en duda la preparación ni los medios de los expertos de seguridad de estos cuerpos, ya sea la Brigada de Investigación Tecnológica —BIT— o el Grupo de Delitos Telemáticos —GDT— de la Guardia Civil, con cuyos objetivos estamos totalmente alineados: ir a por los “malos”.)

Pocas cosas llaman tanto la atención como una buena dosis de morbo, con doble de sangre como acompañamiento y extra de drama. La noticia llevaba varios días en primera plana: Mª Adoración Puig de Parga Carral-Bryce, última descendiente de los Puig de Parga (una familia castellana poco conocida públicamente, pero poseedora de una considerable fortuna), había aparecido asesinada a cuchilladas en su chalet de La Moraleja.

Su marido, Ronald Green Hinojosa-Del Pinar, vicepresidente ejecutivo EMEA de Armand & Old, una conocida multinacional financiera, no se encontraba en casa en esos momentos (estaba al parecer en una importante reunión de trabajo), lo que ha hecho dispararse las teorías sobre el asesinato.

La que más ha calado, a bien seguro por su truculencia, es la que tiene al propio R.G. como responsable del crimen. Green es atractivo, inteligente, elegante y soberbiamente altivo, siempre con la barbilla ligeramente levantada y esa mirada de “soy mejor que tú, y lo sabes”. Maná caído del cielo para las tertulias de televisión y las redes sociales, que ya lo han apodado “El Mr. Grey español”.

[Read more…]

En los artículos anteriores de la serie (I, II y III) habíamos desgranado prácticamente todo el incidente de seguridad de la Empresa. Tan solo quedaba una pregunta por responder: ¿cómo demonios había llegado el malware a ejecutarse al equipo del director de marketing?

Tenemos una fecha clave: la primera descarga de logo.jpg, realizada el 6 de Octubre. La infección debería haberse producido sobre esas fechas. Los sospechosos habituales suelen ser la navegación web y el correo, aprovechando alguna vulnerabilidad del equipo al navegar por alguna página o abriendo un documento malicioso. Poco probable debido a la excelente política de actualizaciones de la Empresa, pero hay que comprobar si lo que se dice sobre el papel se cumple en la realidad.

Descargamos todos los logs de navegación y de correo, intentando buscar ese ítem malicioso, esa entrada en los registros que señala la descarga de un binario… sin éxito. Varias horas tiradas a la basura. ¿Puede ser que hayan empleado un 0-day contra la Empresa? No sería descabellado, pero aún no hemos descartado todas las posibilidades.

Queda una vía de entrada muy sencilla y desgraciadamente muy efectiva: los USB. Es posible que alguien haya pinchado un USB con el malware en el equipo del director de marketing. O puede que simplemente se lo hayan regalado y que lo haya instalado sin saberlo. Los ecos de BadUSB nos vienen a la mente: ¿ya están empezando a golpearnos con eso?

Hay una forma de saberlo: Windows tiene un listado de todos los dispositivos que se han pinchado en el equipo, así como la última fecha en la que fueron pinchados. Recuperamos de la imagen el SYSTEM desde C:\Windows\System32\config, y corremos USBDeview sobre él.

Varias memorias USB, un disco duro externo, una webcam, un dispositivo HID Logitech, un dispositivo HID Teensy++… Espera. ¿Un Teensy? !!!WTF!!! Sin palabras, llamo a mi jefe, que boquiabierto exclama: ¡Pero qué coj…!

Un Teensy es un pequeño dispositivo hardware del tamaño de una memoria USB que viene con su conector listo para conectarse a cualquier puerto USB. Cuando se conecta a un equipo se identifica como un USB HID (Human Interaction Device), en este caso un teclado. Y cuando tiene conexión, abre una ventana de comandos y lanza de un chorro todas las pulsaciones de teclado que han sido programadas. Es como un Rubber Ducky pero sin forma de USB. Un Teensy es como una mini placa base desnuda. ¿Cómo alguien en su sano juicio iba a pinchar eso en su equipo?

Llega el momento de tener un cara a cara con el director de marketing. Nos reunimos en su despacho con María y él. Las noticias vuelan, porque la tensión en el ambiente se corta con cuchillos. Empezamos a hacer una reconstrucción de los hechos, y a mitad de la segunda pregunta me quedo paralizado, casi no creyendo lo que ven mis ojos:

Como decía Sherlock Holmes: “Una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad”. Un jodido acuario USB. Como también decía Ford Fairlane: “Un-be-lie-va-ble”. Sin mediar palabra, saco un destornillador de mi maletín del portátil (hay que estar siempre preparado), le doy la vuelta al mini acuario y empiezo a desatornillarlo ante las protestas del director de marketing y el asombro del resto.

No lleva mucho encontrar el arma del delito. Cuesta creer que algo tan pequeño pueda causar tantos dolores de cabeza:

La última pieza clave del puzzle cae en su sitio. Como Rusia en la Guerra Fría con el Gran Sello, los atacantes habían entrado hasta la cocina usando un método tan simple como elegante: regalando al director de marketing un mini acuario USB.

Los atacantes al parecer conocían el gusto del director de marketing por los acuarios, así que se hicieron pasar por una empresa de acuarios y le enviaron por correo el mini acuario como detalle. El director de marketing hizo el resto.

Poco quedaba por hacer de la investigación. Los nombres de dominio habían sido comprados con una tarjeta de crédito robada, y estaban a nombre de un ciudadano tailandés que no había visto un ordenador en su vida. De la VPN poco íbamos a poder sacar (en este tipo de empresas se valora en extremo la privacidad de los usuarios, y si además no estás dentro de la Unión Europea poco podemos hacer). La información exfiltrada a estas alturas estaba ya guardada a buen recaudo por los atacantes, que a bien seguro habían conseguido su objetivo.

Nuestro trabajo había terminado, pero aún pudimos hacer un balance de lecciones aprendidas por la Empresa:

• Los malos hacen sus deberes. El director de marketing tenía una importante presencia en redes sociales, y debió ser estudiado concienzudamente por los atacantes y designado como el blanco más fácil de la Empresa.
• Si un atacante tiene acceso físico a un equipo, deja de ser tu equipo. Y no tiene que estar delante para tener acceso. Es necesario imponer controles y restricciones sobre los USB, y no solo a nivel de dispositivos de almacenamiento.
• La correlación es tu amiga. Un sistema de correlación de eventos habría sido capaz de detectar la “ubicuidad” del director de marketing y haber generado una alerta que habría prevenido una mayor fuga de información.
• La detección de anomalías es poderosa. En un buen sistema de detección de comportamientos anómalos, un dominio del estilo de www.period1co.es o una petición POST sin GET previos deberían generar una alerta de nivel alto inmediatamente.

El resto del incidente es historia: rodaron algunas cabezas, la empresa decidió (sabiamente) que necesitaba un CISO y se tomó buena nota de las lecciones aprendidas para que un incidente así no volviera a suceder.

Y nosotros aún nos seguimos maravillando de las cosas que se le ocurren a la gente … :)

El capítulo anterior había quedado en un cierto impasse mientras esperábamos que nuestro experto en reversing destripara el malware encontrado. Afortunadamente, en unas pocas horas obtuvimos unos resultados preliminares la mar de interesantes:

• El malware realiza múltiples llamadas a la librería Schannel.dll.
• Se observan varias ocurrencias de la cadena AKCMDDC4-B2132 justo antes de dichas llamadas.
• Muy cerca de esas llamadas el malware obtiene el nombre del equipo.

Una táctica interesante del malware que emplea cifrado es generar al vuelo una clave usando un patrón fijo y datos del equipo infectado, para así dificultar su descifrado, por lo que AKCMDDC4-B2132 podría ser una buena candidata como clave. Y la librería Schannel.dll es la que guarda todos los algoritmos de cifrado nativos de Windows, por lo que la teoría del uso de cifrado parece ser acertada.

Sabemos que si usa Schannel.dll no está empleando un método de cifrado casero, por lo que tan solo nos queda adivinar el tipo exacto que está empleando nuestro malware. Mi jefe es muy paranoico y opta por AES, mientras que yo pienso que no se han complicado la vida y tiro por RC4 (mucho menos costoso de implementar y más ligero computacionalmente).

Un mini script en Python con pycrypto, y al jefe le toca pagar el café: el tráfico está cifrado en RC4, y aplicando la clave AKCMDDC4-B2132 se descifra a la perfección.

El tráfico de las peticiones POST queda abierto ante nosotros y hiela la sangre: Lo primero que vemos son las credenciales de acceso al OWA (Outlook Web Access), el webmail de la Empresa. Lo siguiente, el contenido de lo que parece un fichero .pcf de un cliente de VPN Cisco (la configuración de una VPN Cisco). Con la contraseña incluida.

El malware no está exfiltrando documentos confidenciales: está enviando todas las llaves del reino con esas peticiones POST, obteniéndolas posiblemente mediante alguna funcionalidad de keylogger o accediendo a las contraseñas en claro guardadas a lo ancho y largo del sistema.

Ya hemos encontrado la causa de la brecha, por lo que podemos empezar la fase de contención. Llamamos a María para que revoquen todos los accesos del director de marketing mientras seguimos analizando el tráfico cifrado, en este caso el existente en la imagen logo.jpg.

Como sospechábamos, el contenido está cifrado, usando RC4 y la misma clave que en la comunicación HTTP. Una vez descifrado, el contenido es claro:

SendPass

Interesante a la par que sibilino. Al parecer el malware no funciona de forma periódica, sino cuando es invocado a través de comandos, que suceden de forma completamente asíncrona. El funcionamiento parece ser el siguiente:

• En horario laboral, y de forma aleatoria, el malware descarga logo.jpg y descifra el comando.
• Un tiempo aleatorio más tarde (pero también dentro de horario laboral), se realiza la comunicación POST con el resultado del comando.

El objetivo del malware es muy claro: hacer que las comunicaciones sean aperiódicas y parezcan tráfico normal para pasar desapercibidas ante los controles de seguridad.

Ya conocemos el objetivo del malware y cómo lo hace. Quedan varias preguntas muy importantes por resolver: qué se han llevado, desde cuándo lleva la Empresa comprometida y cómo han podido entrar en el equipo del director de marketing.

Para ver qué datos han podido ser exfiltrados, repasamos todas las conexiones realizadas con las credenciales del director de marketing tanto desde la VPN como desde el OWA. Al ser un equipo portátil con 3G, las conexiones vienen desde multitud de sitios. Sin embargo, tras un poco de trabajo de limpieza, una dirección se repite con cierta frecuencia, tanto en VPN como en OWA.

Examinando la dirección, encontramos que corresponde con la salida de un conocido proveedor de VPN ruso. Si ya tienes una VPN, ¿qué sentido tiene el pasar tu tráfico por otra? Extremadamente sospechoso.
Hablando con María obtenemos los eventos de inicio de sesión del director de marketing de los últimos tres meses, e intentamos buscar inconsistencias. Sabiendo lo que tenemos que buscar no tardamos en encontrar varios puntos, todos ellos dentro de horario laboral, en los que el director de marras está a la vez dentro de la Empresa y conectado por la (doble) VPN. Ya tenemos los datos de conexión del atacante y conocemos su modus operandi (bastante cuidadoso, por cierto).

Saber qué se ha podido llevar es mucho más complicado. Dado que ha podido entrar como si fuera el director de marketing, su nivel de acceso es muy elevado. Vamos a centrarnos en dos puntos de fuga principales: su cuenta de correo y el servidor corporativo.

Revisando su buzón de OWA no encontramos nada sospechoso. Todo está perfectamente en orden, ordenado y pulcro en extremo. Sin embargo, los logs de Exchange cuentan una historia totalmente diferente: hay docenas de correos electrónicos enviados a cuentas de Gmail con nombres muy similares a personal de la Empresa y otras empresas colaboradoras. Los atacantes siguen intentando mantener un perfil bajo, borrando del OWA los correos enviados para no dejar rastro.

La información exfiltrada es… complicada. Correos con información sensible, documentos de la estrategia de ventas de la Empresa, hasta lo que parece ser un indicio de que el director de marketing está teniendo un “asunto” con alguien de Finanzas. Un completo desastre.

Obtener un registro de qué información ha podido ser exfiltrada del servidor corporativo va a ser un poco más complicado. Afortunadamente tenemos algo de suerte en este aspecto: en la Empresa han apostado por una estrategia de gestión documental férrea basada en Sharepoint, por lo que todo está bastante bien organizado y pasa obligatoriamente por el CMS.

Además, algún administrador de sistemas lo suficientemente paranoico había activado la trazabilidad, por lo que tenemos un listado de quién ha accedido a qué documentos en los últimos seis meses. El problema es que no sabemos qué documentos han sido accedidos por el director de marketing o por los atacantes.

Correlar las fechas de conexión por la VPN no sería del todo efectivo ya que hay momentos de solapamiento. La solución por la que optamos es obtener un listado de los documentos accedidos durante esos solapes, y cruzarlos con los accedidos por el director de marketing. Saber qué documentos han sido accedidos por el director de marketing es algo laborioso pero realizable.

Tenemos una imagen de disco. ¿No os acordáis de ella? Pues nos va a venir de maravilla, porque Windows guarda un listado de los documentos accedidos más recientemente (MRU, Most Recently Used) para cada usuario (en versiones modernas de Windows hasta por programa). Volcamos del disco el NTUSER.DAT y lo pasamos por RegRipper para obtener el listado de ficheros sobre el que trabajar.

Aquí no tenemos tampoco buenas noticias. Entre los documentos que sabemos han sido accedidos desde la VPN y el despiece hecho con RegRipper toda la estrategia corporativa ha sido exfiltrada.

El siguiente paso es saber cuánto tiempo lleva la Empresa comprometida (trufada, como solemos usar en nuestra jerga). Para ello podemos componer una línea temporal con toda la información de la que disponemos, a saber:

• Primera descarga de logo.jpg
• Primera comunicación POST contra www.period1co.es
• Accesos desde la VPN al OWA
• Accesos desde la VPN al Sharepoint

Las piezas van encajando como un puzzle. La primera descarga de logo.jpg se produjo el 6 de Octubre, la primera comunicación POST dos días más tarde, y en ese mismo día ya se estaban descargando documentos tanto del OWA como del Sharepoint. Dos meses trufados sin que nadie se diera cuenta. Como diría Pazos de Airbag: Profesional, muy profesional.

Mientras comunicamos todo lo hallado a María para que la Empresa pueda realizar sus trabajos de contención a nivel de relaciones públicas, solo queda una pregunta por responder: ¿cómo lograron los atacantes entrar en la Empresa?

La respuesta la tendremos en el siguiente y último artículo de la serie…

En el capítulo anterior habíamos dejado la investigación en un punto candente: teníamos pendiente un análisis forense del equipo del director de marketing, ya que todo apuntaba a que podía ser la fuente de la filtración de la información.

Hablando con María, la CIO de la Empresa, tomamos la decisión de ser extremadamente cautos a la hora de hacer una imagen forense del portátil del director de marketing, ya que la paranoia campa a sus anchas por la Empresa y no es posible fiarse de nadie.

Esperamos a que salga a una reunión en otra empresa para entrar en su oficina y abalanzarnos con nuestro bloqueador de escritura de discos para obtener una copia bit a bit (las únicas válidas ya que capturan el estado del disco tal y como está, copiando tanto ficheros borrados como espacio libre del disco duro).

[Read more…]

Comienza un día nuevo en la oficina. Todos los sistemas están funcionando correctamente, el generador de cafeína está a toda máquina y los comerciales están fuera haciendo visitas. Es un momento perfecto para revisar algunos artículos de investigación, o hasta para invertir un poco de tiempo en un par de scripts en Python a los que les llevo dando vueltas un rato… hasta que suena el teléfono.

El jefe ha recibido una llamada de la CIO de una empresa del IBEX 35 (a partir de ahora, la empresa será Empresa, y la directiva María). Según sus palabras, se ha producido una fuga de datos. Una fuga muy grave. Al parecer, parte de lo que se ha filtrado es el plan estratégico de la empresa para los próximos cinco años. Información a la que tiene acceso un grupo muy reducido de personas, entre las que se encuentra el consejo de dirección de la empresa.

Como todavía no sabemos a lo que nos enfrentamos, cogemos tanto la mochila de respuesta ante incidentes como la de informática forense y nos dirigimos a la sede de la empresa en Madrid para una primera toma de contacto.

La Empresa se toma la seguridad muy en serio: registran ambas mochilas, toman fotografías de todos los dispositivos y nos dan una tarjeta de identidad que por la pinta seguro que es capaz de hacer más de lo que parece. Cámaras de seguridad en todos los pasillos, y un ambiente totalmente profesional hasta que subimos a la planta noble, donde nos reunimos con María. Está visiblemente nerviosa, y viendo su traje parece que lleva más de un día en pie.

Dentro de las fases de la respuesta ante incidentes estaríamos todavía de la detección (sabemos que hay algo, pero todavía no conocemos el alcance de lo que está sucediendo). María nos cuenta que alguien está obteniendo información confidencial de la empresa, tan reservada que solo puede venir de los más altos cargos de la empresa: el director general, el director de operaciones, el director financiero, el director de ventas… o ella misma.

Tras firmar varios acuerdos de confidencialidad especialmente virulentos, empezamos nuestro trabajo con la aproximación más simple: un inside job, el clásico empleado descontento que ha robado la información. Pero al parecer todos los directivos son fanáticamente leales a la empresa e incluso su personal administrativo es de la mayor confianza, por lo que a priori podemos descartar esta teoría (en realidad no la descartamos, solo la guardamos para más tarde).

El espionaje clásico también queda excluido: la información robada no es algo que se pueda obtener poniendo un micrófono o “pinchando” un teléfono. Ha sido extraída de un ordenador.

La Empresa también se toma muy en serio la seguridad informática: seguridad en profundidad en toda la arquitectura, varios niveles de cortafuegos, antivirus actualizados, sistemas parcheados hasta la obsesión, acceso remoto por VPN, detectores de intrusos, contraseñas robustas cambiadas cada mes, etc. Uno de esos sitios en los que nunca se esperaría que sucediera nada, pero en el que aquí estamos trabajando.

Lo primero que hacemos es recoger información, toda la que seamos capaces de recopilar para proceder a su análisis y entender qué ha podido suceder. La Empresa tiene todo bien organizado, por lo que podemos hacernos con un paquete de datos completo: logs del proxy, de la pasarela de correo, de los antivirus, eventos de servidores y de las estaciones de trabajo y hasta de la VPN. El problema es que todos esos logs, si tomamos el acumulado de los últimos tres meses (el mínimo con el que empezamos), suman 200Gb de información. Comprimida.

Cogemos tres meses porque estamos empezando a sospechar que una APT (Advanced Persistent Threat) puede estar detrás de esto. Vamos, que alguien puede haber entrado hasta la cocina en la Empresa y se esté comiendo hasta los yogures caducados. El disponer de un histórico de datos nos permite detectar patrones y descartar falsos positivos, haciendo más eficaz nuestro trabajo.

Lo primero que hacemos es realizar un filtro inicial de la información, quedándonos con los equipos tanto de los directivos como de su personal de administración (diez en total), lo que reduce los registros a un poco menos de 20Gb de datos descomprimidos. A través de una serie de scripts normalizamos e importamos la información a una base de datos que nos permita realizar búsquedas y aplicar otros scripts que tenemos desarrollados.

Las primeras comprobaciones son casi rutinarias, pero hay que realizarlas: visitas a dominios infectados, eventos de la consola de antivirus, múltiples envíos de correos a direcciones no conocidas… serían signos que nos permitirían detectar rápidamente el equipo comprometido, pudiendo aislar la infección lo antes posible.

No hay suerte esta vez, aunque en realidad no esperábamos sacar nada en claro. Este incidente huele a algo avanzado desde el primer momento. Tenemos que pasar a la segunda fase: la detección de anomalías. Todos los sistemas (incluidos sus usuarios) siguen unos patrones de comportamiento, un conjunto de acciones y conexiones que pueden ser analizados para conformar un baseline o valor de referencia.

Ese baseline puede ser obtenido de los logs recuperados para hacer emerger todo lo raro, todo lo que no encaja: las anomalías. Es un trabajo complicado, porque la creación del baseline nunca es exacta, y abundan los falsos positivos (y además, nunca sabes si los “malos” han sido tan buenos como para esconder sus acciones tan bien como para que se hagan parte del baseline).

Al final es un trabajo minucioso, costoso y metódico que tiene que hacerse con sumo cuidado y atención al detalle para no dejarse nada. Es como buscar una aguja en un pajar, pero cuando el pajar es del tamaño de un campo de fútbol y no sabes siquiera que lo que quieres encontrar es una aguja.

Menos mal que, si llevas tiempo en el negocio, puedes tomar algunos atajos. Sabiendo cómo se comportan muchas amenazas es posible realizar una serie de modelos de ataque, conociendo qué tipo de anomalías generan en un sistema. De esta forma podemos buscar por esas miguitas de pan, esos indicios que nos permitan averiguar qué es lo que está sucediendo.

La cantidad de datos no es pequeña, así que tenemos algo de tiempo mientras nuestros programas trabajan. Un poco más de cafeína, una docena de correos y dos llamadas telefónicas más tarde, tenemos un listado de unas 30 anomalías.

Casi todas son falsos positivos, pero una de ellas salta a la vista: una petición POST a un nombre de dominio muy similar a un conocido periódico de tirada nacional (a partir de ahora www.period1co.es), tan similar que tan solo han cambiado una letra por otra casi idéntica. La petición en sí es bastante anodina, pareciendo la URL a primera vista el posteo de un comentario en una noticia.

Anomalía por partida doble. En primer lugar, ¿por qué tenemos un POST sin haber tenido antes ninguna comunicación con esa página web? Dentro de una comunicación HTTP el método POST es empleado para enviar datos a una página web, pero lo lógico es que antes hayamos descargado esa web, lo que suele conllevar un cierto trasiego de peticiones GET, que aquí a priori no existen.

En segundo lugar: ¿www.period1co.es? Lo buscamos en diversas páginas de reputación online y ninguna lo marca como malicioso, pero está claro que huele a chamusquina. Nos morimos de ganas por abrirlo en un navegador, pero no sabemos si los atacantes están vigilando los logs y los ponemos sobre aviso.

Mirando el lado positivo, tenemos ya dos hilos de los que tirar: el dominio supuestamente malicioso, y la IP origen de la petición, que resulta ser la del director de marketing de la Empresa.

Ahora podemos empezar a trabajar alrededor de estos indicios, lo que en la jerga conocemos como pivotar. Lo primero es ver más ocurrencias de ese dominio malicioso en todos los logs que tenemos recogidos, sean o no anómalos. Y el segundo paso sería analizar en detalle todo el tráfico de la IP 192.168.39.134, que parece ser a todas luces el equipo infectado.

La emoción de la caza es casi como una droga, así que mi jefe y yo miramos hipnotizados la pantalla mientras las herramientas hacen su trabajo. Diez angustiosamente largos minutos más tarde, tenemos resultados jugosos. Muy jugosos.

El equipo 192.168.39.134 ha realizado en los últimos dos meses 18 conexiones POST como la anterior a la URL www.period1co.es. Todas ellas en horario laboral, con unos tamaños bastante discretos (que hacen pensar a priori que la exfiltración de datos no se ha producido por esa vía) y a subpáginas del dominio con una estructura común (que podrían ser respondidas por un único script en el servidor y que ayudarían a que las URL variaran, haciendo más complicada su detección).

Y de forma adicional, tenemos 5 conexiones más al dominio desde dicha IP:

La seguridad informática es casi siempre compleja, abarcando muchas áreas distintas y haciendo muy fácil caer en el equivalente técnico de la “letra de médico”.

Quién no ha tenido algún momento del estilo de tener a dos técnicos de seguridad y que comiencen a hablar de la “APT que explotaba un CVE del kernel de XP y que exfiltraba por HTTP usando 404 modificados, y que menos mal que el IDS lo pilló y le pusimos un deny en el firewall antes de que dropeara una nueva versión de malware del C2 ”.

Si eres técnico de seguridad seguramente estés sonriendo al leer estas líneas, pero si no lo eres probablemente no hayas entendido ni una coma. El problema es obvio: la seguridad informática es complicada, y comunicar en seguridad informática es más complicado todavía.

Y en mi opinión, la comunicación es algo en lo que deberíamos de trabajar todos los expertos en seguridad informática. Es necesaria tanto para convencer a la dirección para poder invertir tiempo y recursos en mejorarla, como para convencer a los usuarios de que la seguridad es necesaria (por su propio bien en muchos casos).

Por ello, me gustaría proponer una lista de libros, escritos por técnicos, pero en los que explica de una forma clara, sencilla y hasta amena, varios conceptos principales de la seguridad informática.

[Nota: Me temo que todos los libros están en el lenguaje de la pérfida Albión. Es lo que tienen los libros muy especializados …]

”Secrets and Lies: Digital Security in a Networked World”, Bruce Schneier – Ed Wiley

Schneier es uno de los mejores divulgadores actuales de la seguridad informática. Además de su blog de seguridad informática tiene varios libros publicados en los que trata de forma sencilla conceptos como el riesgo, la protección de sistemas, la criptografía y hasta la propia confianza base de la sociedad. Todos sus libros son interesantes pero “Secrets and lies” es el mejor. Si tu jefe solo tiene tiempo para leer un libro de seguridad, que lea éste.

”The Code book”, Simon Singh – Ed. Anchor

Si hay algún campo de la seguridad informática que es especialmente complicado es la criptografía (yo tengo la teoría de “la criptografía de clave pública solo se entiende a la tercera vez que te la explican”). Sin embargo, Singh hace un trabajo maravilloso explicando de una forma cristalina los conceptos más complicados de la criptografía, todo basado en momentos históricos y lleno de anécdotas. Una delicia de libro.

“Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon”, Kim Zetter – Ed Crown

Stuxnet es considerado por muchos como el primer acto de ciberguerra con todas las letras: intención, sofisticación y complejidad son palabras que vienen a la mente cuando pensamos en un malware que, posiblemente, haya abierto la caja de Pandora y que sin duda será estudiado en tiempos venideros. Zetter es capaz de narrar cómo fue detectado, analizado y erradicado de forma amena y casi adictiva, haciendo de la historia prácticamente un tecnothriller.

“Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door” – Brian Krebs, Ed. Sourcebooks

Krebs es posiblemente el periodista especializado en seguridad informática más famoso del mundo. Desde su blog analiza todas las noticias importantes de seguridad desde un punto de vista crítico pero claro. Su libro es una guía muy completa del cibercrimen, contando con todo lujo de detalles el submundo de los delitos informáticos desde los spammers hasta cómo se blanquea el dinero que es obtenido.

“The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers” – Kevin Mitnick & William Simon, Ed. Wiley

Kevin Mitnick (alias “El Condor”) es uno de los hackers más conocidos de la historia, siendo especialmente famoso por su dominio de la ingeniería social (o como él lo llama, “hackear personas”). En este libro, basado en historias propias y de otros hackers de la época, cuenta cómo sobrepasar diversos sistemas de seguridad con pocos o nulos tecnicismos. Es muy interesante la aplicación del pensamiento lateral, y cómo atacan algunos problemas logrando saltarse la seguridad de formas a veces estúpidas pero muy efectivas.

“Inside cyberwarfare” – Jeffrey Carr, Ed O’Reilly

Ciberguerra, ciberespionaje, cibercrimen… Por mucho que cerremos los ojos, van a seguir estando ahí. Carr hace un listado muy completo de los problemas que podemos encontrarnos en Internet, enfocándose en las capacidades existentes de diversos países para la ciberguerra, así como en diferentes escenarios y tecnologías a emplear. Aunque Carr es analítico y claro, huyendo totalmente de intentar causar el pánico, el miedo que te entra en el cuerpo después de leerlo es … inquietante.

Hay muchos más libros “sencillos” para hablar de seguridad informática, pero estos son los que me han parecido más representativos. Y tú … ¿tienes algún libro de cabecera para enseñar seguridad informática a los no técnicos? ¡Compártelo!

Dicen que los perros viejos no aprenden trucos nuevos. Pues parece que los malos sí que son capaces de hacerlo. Desde primera hora del día de hoy nos hemos encontrado con una campaña masiva de correos maliciosos enviados desde múltiples orígenes, pero todos con un patrón común:

• Asunto con el texto “Remittance Advice for 918.97 GBP” (la cantidad varía según el correo).
• Un adjunto con el nombre BAC_XXXXXXY.xls (5-6 números y una letra).

[Read more…]

Si recordamos el último post (primera parte y segunda parte), teníamos un PDF malicioso del que queríamos extraer el shellcode. Tenemos el JavaScript pero no parece que esté completo, por lo que tenemos que seguir analizando el código.

Vamos a fijarnos en este código nativo de Adobe:

hCS(sRi(xfa.resolveNode("Image10").rawValue)); 

Si miramos la referencia de JavaScript de Adobe, la función xfa.resolve permite el acceso a objetos. Y con el método rawValue le estás pidiendo al valor tal cual en bruto de esa variable. Esto… ¿no habíamos dicho que las imágenes no servían para nada?

[Read more…]