Aunque gurús varios llevan años vaticinando su muerte, el correo electrónico sigue manteniendo a día de hoy una salud de hierro, siendo parte fundamental de la operativa de muchas empresas. Y dado el uso omnipresente del mismo, es prácticamente imposible imponer cambio global alguno al funcionamiento del protocolo SMTP (diseñado hace décadas para que fuera robusto, no seguro).

Es por ello por lo que los atacantes siguen viendo el correo electrónico como un camino perfecto para penetrar en una empresa, ya que es un vector de ataque sencillo, dirigido y muy efectivo. En muchas empresas existen unos controles de seguridad básicos con respecto al servidor de correo electrónico, pero a día de hoy esos controles son insuficientes para detener ataques sofisticados.
[Read more…]

Hay pocos temas capaces de generar tanto debate dentro del campo de la seguridad informática como el de las certificaciones: son geniales, no sirven para nada, generalistas, de producto, con cebolla, sin cebolla… Defensores y detractores esgrimen argumentos bastante válidos a la hora de defender y cuestionar el valor real de las certificaciones de seguridad.

Imaginemos por un momento que tenemos un casco que nos permite, con tan solo pulsar un botón, convertirnos en un fanboy de las certificaciones o en su enemigo más acérrimo. Casco en mano (bueno, en cabeza, la seguridad es lo primero) vamos a repasar algunos argumentos a favor o en contra de las certificaciones de seguridad.

Pros

• Sirven para conseguir entrevistas: Uno de los problemas principales que tiene el personal de RR.HH. para seleccionar candidatos para un perfil es saber quién puede ser un buen candidato (la contratación en seguridad informática tiene su tela, y merece un artículo por sí sola). Las certificaciones de seguridad les vienen como anillo al dedo ya que les proveen de las buzzwords necesarias para poder discriminar candidatos. El tener o no tener las certificaciones correctas puede indicar en muchos casos el paso a la siguiente fase de un proceso de selección.
• Son personales: Se van contigo debajo del brazo cuando cambias de trabajo y son (mantenimiento mediante, del que ya hablaremos) para siempre. A las empresas les suelen gustar las certificaciones, por lo que es un buen argumento a la hora de negociar salarios.
• Demuestran motivación: Se puede entrar a trabajar en seguridad informática desde muchos perfiles (desarrollador, administrador de sistemas, de redes, etc…) De la misma forma, se puede entrar porque de verdad te apasiona la seguridad o simplemente porque es un campo que ahora está de moda y por ende hay mucho trabajo y/o está bien pagado. El que alguien tenga certificaciones de seguridad demuestra en cierta medida que “va en serio” con la seguridad, y que quiere desarrollar su carrera en esta área. La dedicación y la motivación en nuestro campo cuentan. Y mucho.
• Le gustan a tu empresa: Muchos concursos públicos tienen un apartado puntuable relativo a la calidad del personal que va a ejecutar el proyecto. Dado que el 95% del personal van a ser ingenieros y/o grados, las únicas formas de cuantificar la calidad del personal son los años de experiencia… y las certificaciones de seguridad que poseen. Además, a nivel de marketing que una empresa pueda decir que tiene N-cientas certificaciones le sirve para sacar pecho, lo cual tampoco les viene mal.
• Se aprenden cosas nuevas: Nadie sale de la carrera convertido en un experto en seguridad informática. Por mucho que hagamos cursos y nos formemos, siempre hay aspectos o temas particulares que se nos pueden escapar. El preparar una certificación de seguridad (casi siempre relacionada con un campo específico) nos fuerza a profundizar en ese campo, afianzando conceptos y mejorando nuestro conocimiento del tema.
• Se aprende jerga nueva: En muchas certificaciones se estudian conceptos que no son puramente técnicos, pero que ayudan a comprender el negocio de la seguridad. Saber qué entienden los auditores como “apetito del riesgo”, o los gestores de servicios TI como “gestión del cambio” amplia nuestra visión del negocio y ayuda a comprenderlo mejor.
• Superación personal: El pensar que se controla un tema está muy bien. El pasar una prueba objetiva que demuestre que lo dominas está mucho mejor.

Contras

• Su valor real es discutible: Se puede aducir que obtener una certificación es similar a estudiarse un libro y pasar un examen, no significando necesariamente que se posea la profundidad de conocimientos implícita en la certificación.
• El coste es elevado: La mayoría de las certificaciones tienen un coste elevado. Sentarse en el examen suele empezar en 500€, a lo que hay que sumar el material de estudio de la certificación y los (a veces opcionales) cursos de preparación a la certificación.
• Los exámenes no son adecuados: Aunque hay excepciones, prácticamente todos los exámenes de las certificaciones están compuestos de preguntas con respuesta múltiple (con respuestas discutibles en muchos casos), quedando fuera los ejercicios y los casos prácticos que pueden demostrar realmente el conocimiento del examinado. Y pobre de ti si eliges hacer el examen en castellano, ya que traducir una pregunta ya per se complicada en inglés y hacer que mantenga el espíritu de la misma es a veces imposible.
• Mantener la certificación es un infierno: Una vez conseguida la certificación, en muchos casos es necesario mantenerla mediante los famosos CPE (Continuing Professional Education), actividades formativas que deben ser realizadas para mantenerse al día en el ámbito de la certificación. Los CPE a priori parecen una buena idea ya que obligan al certificado a reciclarse de forma periódica, pero el trámite burocrático en algunos casos es, por así decirlo, costoso.
• Si no tienes certificaciones, no eres bueno: Se puede producir un efecto de lógica retorcida que induzca a pensar que “dado que si tienes certificaciones eres bueno, si no las tienes eres malo”, cuando hay profesionales de altísimo nivel que no poseen ni una sola certificación.

Si estás pensando en certificarte, aquí tienes unos cuantos consejos:

• Decide si necesitas certificarte: Una certificación tiene sus beneficios, pero tiene su coste (tanto en dinero como en tiempo de preparación). Infórmate acerca de la certificación y sobre todo cómo puede ayudar a mejorar tus conocimientos y tu perfil profesional.
• Entérate de lo demandada que está en España y en el extranjero. Una buena técnica es buscar en Infojobs o Tecnoempleo las ofertas que la piden, para hacerte una idea de cuán solicitada está.
• Lee bien toda la letra pequeña, sobre todo en lo referente a los requisitos de acceso (en algunos casos hay que tener experiencia previa certificable), si es obligatorio hacer un curso preparatorio y lo que hay que hacer para mantenerla. Tampoco está de menos saber cuándo y dónde se pueden hacer los exámenes (algunas certificaciones tienen fechas fijas y solo se pueden hacer en Madrid/Barcelona, mientras que otras se pueden hacer todo el año en centros autorizados en casi todas las comunidades).
• Plantéate si estás preparado: Una certificación al fin y al cabo es un examen, por lo que hay que llevar la materia bien preparada. Y dado que sentarse al examen cuesta un dinero, evalúa si tienes los conocimientos necesarios para superarla a la primera.
• Intenta que la pague tu empresa: Al final la certificación viene bien a tu empresa, y cuenta como formación, por lo que intenta convencer a tu jefe para que corra a cuenta de la empresa (en algunas consultoras curiosamente te pagan pero casi obligan a que te saques una certificación al año hasta tener las X decididas como óptimas). Otra opción es que te dejen tiempo para prepararla dentro de tu jornada laboral (en alguna empresa se montan hasta grupos de estudio).
• Hazte con un buen material de estudio: Muchas certificaciones tienen guías oficiales, o libros que aglutinan el temario y lo explican de forma coherente y completa. Entérate de qué material de estudio es el mejor para cada certificación.
• Cuidado con los dumps: Dado que casi todos los exámenes son de preguntas con respuesta múltiple, y que en muchos casos se reutilizan preguntas, es posible encontrar en Internet dumps (recopilaciones de preguntas de otros años y/o de pruebas). Algunos sitios de Internet aseguran tener “todas las preguntas” del año, para que solo tengas que estudiarte las respuestas y pasar así el examen (sic). Mucho cuidado con estos dumps, porque las preguntas cambian cada año y en muchos casos las respuestas son erróneas.
• Planifícate: Una certificación acaba siendo como una carrera. Decide cuánto entrenamiento necesitas, y hazle el hueco necesario en tu día a día. Meterte entre pecho y espalda 20 temas en un fin de semana no es la mejor forma de aprobar.
• Si apruebas, haz el papeleo cuanto antes: Si superas el examen, el trabajo no ha terminado. Toca hacer todo el papeleo administrativo (acreditar años de experiencia, adjuntar fotocopias de títulos, recoger firmas de jefes, etc…). Cuanto antes lo hagas antes te lo quitarás de encima, aparte de que te evitarás posibles problemas (como tener que pedirle una firma a un antiguo jefe, algo que aquí puede costar lo suyo).

En mi opinión personal, las certificaciones de seguridad aportan valor… pero podrían aportar más. Exámenes con un contenido práctico más elevado (aunque hay algunas que sí lo tienen, son la excepción) y con un temario moderno y actualizado año a año probablemente incrementarían su dificultad (tanto de hacerlo como de corregirlo), pero haría que fueran mejor valoradas por la comunidad.

Y por supuesto, es necesaria la aplicación general del sentido común (también conocido por ser el menos común de los sentidos) y una buena dosis de humildad. El tener una firma de correo con dos líneas de cargos más otra línea de certificaciones no te convierte automáticamente en el rey del mambo. Y si te presentas en según qué ambientes como “Pepe Palotes, Cert1, Cert2, Cert3” estás cogiendo boletos para hacer el ridículo.

De la misma forma, aunque seas un “L33T Haxxor” que reniegas de las certificaciones cual Linus Torvalds de Microsoft, tampoco es de recibo llamar “corporate bitch” a alguien que sí que las tenga.

Tanto si estamos a favor como en contra de las certificaciones de seguridad, no se puede negar que son un aspecto a tener en cuenta en la realidad actual de la seguridad informática. Lo mejor que podemos hacer es… convivir con ella.

[Full disclosure: El autor posee las certificaciones CISA, CISM, CISSP, CHFI, CCSK e ITILv3f].

(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.)

En la entrega anterior (ver parte I, parte II, parte III, parte IV y parte V) teníamos el caso a punto de caramelo: habíamos relacionado (inicialmente al menos) a R.G. y a S.P.F. con dos terminales que habían estado implicados en el asesinato.

La última localización del segundo terminal lo situaba en la E-5 (una de las carreteras que conectan La Moraleja con Madrid). Desafortunadamente, en esa zona la densidad de las celdas no es tan alta como en el centro de Madrid, así que la localización es mucho menos precisa, pudiendo estar en el orden de los centenares de metros.

Nos queda el primer terminal, que parece estar perfectamente localizado. Las FFCCSSE van a casa de la hermana de S.P.F. con una orden judicial y obtienen el terminal móvil de su hija Ainara (regalo de su tía Samantha el día después de autos), y le hacen un volcado de sistema de ficheros con el Cellebrite UFED (sigue siendo un iPhone 5, por lo que no podemos hacerle un volcado físico).

Revisamos ávidamente los sospechosos habituales: SMS, llamadas, correo, Whatsapp… sin encontrar nada sospechoso. Es más, se puede apreciar que hay poco contenido en el teléfono (aunque el significado de poco es relativo para un teléfono de una quinceañera), lo que nos hace sospechar que el teléfono ha sido devuelto a los valores de fábrica.

Si nos fijamos en algunos timestamps de los ficheros podemos ver que han sido creados el día después de autos, lo que confirma que el teléfono ha sido borrado. Sin embargo, nosotros sabemos que un borrado muchas veces no es para siempre. Si pudiéramos obtener una copia física del dispositivo…

Dos minutos más tarde, nuestros deseos se hacen realidad: revisando el listado de apps instaladas encontramos una que nos alegra el día: Cydia, el market de apps de terceros para Apple. Cydia tiene una característica muy interesante: solo se puede instalar en terminales que hayan pasado por un proceso de jailbreak previo.

Ergo, si tiene Cydia tiene un jailbreak le podemos hacer un volcado físico, si tenemos una licencia de ElcomSoft iOS Forensic Toolkit). Los dioses nos sonríen y poco más tarde tenemos un precioso volcado físico del iPhone5 de marras. Lo primero que nos pide el cuerpo es verificar cuándo ha sido devuelto a valores de fábrica: para ello podemos comprobar el valor del fichero /root/.obliterated, cuyo timestamp marca la fecha del último reseteo. En nuestro caso, coincide con el día después de autos.

Una vez satisfecha nuestra curiosidad (y apuntado en el informe la intencionalidad del borrado de datos), vamos a intentar recuperar información borrada de la imagen física del iPhone. Los iPhone tienen como formato de sistema de ficheros HFS+, que es perfectamente aceptado por TestDisk.

Sin embargo, hoy no es su día así que necesitamos probar suerte con otra herramienta. Rebuscando un poco en Google encontramos HFSprescue, que parece funcionar a la perfección y en menos de media hora nos ofrece una buena cantidad de archivos borrados.

En realidad solo hace falta un fichero: el ChatStorage.sqlite para tener acceso a los mensajes de Whatsapp enviados y recibidos. Y el contenido, aparte de no ser para menores de edad, lo dice todo: conversaciones entre R.G. y S.P.F. más que subidas de tono, así como el odio manifiesto de S.P.F. hacia A.P. y el desprecio de R.G. hacia su mujer.

Con estas evidencias en la mano, las FFCCSSE tienen el caso envuelto en papel de regalo. Cuando se confronta a S.P.F. y se le enseña el listado de Whatsapp de su antiguo terminal se desmorona por completo y nos cuenta toda la verdad. Según su confesión esto es lo que sucedió:

• R.G y S.P.F. eran amantes desde hace más de un año. R.G. no podía soportar a su mujer, pero sabía que no podía divorciarse de ella (haría todo lo imposible por arrebatarle su fortuna y arruinarle la vida). Es por ello por lo que plantearon asesinarla.
• Compraron dos teléfonos móviles en efectivo, iguales que sus móviles personales para que nadie sospechara si los viese con ellos. Las SIM las adquirió S.P.F. en un locutorio de Lavapies (Madrid).
• Unos días antes, R.G. borra los portátiles de ambos y los reinstalan (en los móviles “oficiales” no hacen nada porque toda su relación está en los terceros terminales).
• El día de autos, R.G. sale con su coche de La Moraleja y va a su casa. Se asegura de ser grabado por las cámaras y hasta de dejar el coche mal aparcado para que lo multen. Una vez en su casa, se conecta a la wifi de S.P.F. y le da su contraseña de usuario para que simule de vez en cuando actividad en el portátil.
• A las 00.00h sale de casa de S.P.F. y coge la moto de S.P.F. y se dirige a La Moraleja. Esquiva las cámaras de seguridad (ha estudiado perfectamente dónde está cada una de ellas), salta la verja y entra por una ventana de la cocina que no tiene alarma.
• Va al despacho, hace ruido para despertar a su mujer y cuando ella entra la apuñala en el pecho con un cuchillo. Deja movido el cuadro de la caja fuerte y le hace unos arañazos a la cerradura para simular su intento de forzado y sale por donde ha entrado.
• Una vez camino de vuelta a Madrid destruye a pedradas el móvil, rompe la SIM y tira ambos en un descampado en un lado de la carretera. Unos cientos de metros más tarde tira el cuchillo y los guantes en una acequia.
• Vuelve a casa de S.P.F, se ducha concienzudamente para eliminar cualquier rastro de sangre y coge el coche para volver a su casa.

El plan está sin duda muy bien definido y ejecutado prácticamente a la perfección. Casi a la perfección. Sin embargo, R.G. se creyó demasiado listo, y cometió errores. El no mantener la OPSEC (seguridad operacional) a lo largo de toda la cadena de la ejecución del crimen hizo que S.P.F. regalara su iPhone 5 a su sobrina, permitiéndonos tirar del hilo y descubrir todo el pastel.

El juicio duró buena parte de un año y terminó con ambos en la cárcel, pero nosotros ya habíamos hecho nuestro trabajo y teníamos cosas mejores que hacer con nuestro tiempo (hay muchas páginas de seguridad interesantes, y no se van a aprender solas).

Moraleja: No cometas crímenes, porque no solo los de CSI son capaces de hacer maravillas…

(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.)

La entrada anterior (ver parte I, parte II, parte III y parte IV) había dejado la investigación en un punto clave: logramos acceder a la cuenta de iCloud de S.P.F, y ahora teníamos que ver si podíamos sacar algo de sus copias de seguridad (recordemos que el MacBook había sido sospechosamente reinstalado). La pantalla de entrada es algo similar a esta:

En función de lo que S.P.F. haya habilitado tanto en su iPhone como en su MacBook podremos recuperar más o menos información. Lo primero es verificar qué dispositivos están conectados a la cuenta de iCloud, por lo que accedemos a Settings -> Devices.

Un MacBook Pro, un iPhone 5, otro iPhone 5… ¡¿qué?! Ojipláticos comprobamos que al parecer tenemos un iPhone “extra” dentro de esta cuenta de iCloud. Vamos a obtener algo más de información pulsando sobre el dispositivo (la foto siguiente es un ejemplo de lo que aparecería).

Como podemos ver tenemos tanto la última fecha de copia de seguridad (en este caso, nunca), así como el número de serie y el IMEI (International Mobile System Equipment Identity), que nos van a servir para identificar de forma unívoca ese terminal esté donde esté.

El paso siguiente es obvio: vamos a ver dónde está ese terminal vía Find my iPhone. Solo nos muestra el primer teléfono de S.P.F, ni rastro de este segundo terminal. Si accedemos al resto de opciones de iCloud no encontramos nada digno de mención aparte de una copia de seguridad de miles de fotos (Instagram es lo que tiene).

Parece ser que ese teléfono se conectó a iCloud pero luego no se ha activado ninguna funcionalidad de copia de seguridad. Y si la funcionalidad de encontrarlo no está operativa lo único que se nos ocurre es que o bien el teléfono esté apagado o que ya no esté conectado a esa cuenta de iCloud (no lo podemos confirmar pero no creemos que un mismo terminal pueda estar conectado a dos cuentas de iCloud a la vez). La información del nuevo terminal es vital para la investigación, así que se la facilitamos a las FFCCSSE para que (siempre con orden judicial) soliciten los datos de llamadas y posicionamiento del terminal, mientras esperamos mordiéndonos las uñas y tomando más café del que deberíamos (es decir, mucho).

Los resultados nos aclaran algunas dudas y nos generan otras. Por si no lo sabéis, cuando se emite una orden de obtención de datos a partir de un IMEI, la operadora facilita los datos de la SIM que está conectada al mismo… y de otras SIM que hayan estado conectadas al terminal en el plazo temporal requerido en la orden.

El terminal ha tenido dos SIM conectadas, cada una con un patrón de uso diferente:

a) SIM1 (conectada hasta el día después de autos).

• Titular: Abdul Alhazred.
• Patrón de llamadas: Varias llamadas diarias al móvil X, casi no hay llamadas a otros números.
• Patrón de localizaciones: Barrio de Chamberí, centro de Madrid, sede central de Armand & Old.

b) SIM2 (conectada a partir del día después de autos).

• Titular: Vanessa Pérez Fuencarral.
• Patrón de llamadas: Pocas llamadas a unos 20 números de teléfono.
• Patrón de localizaciones: Barrio de Salamanca, centro de Madrid, colegio privado XXX.

Oro en lingotes como para hacerle una casita al perro. Cuesta poco obtener las siguientes conclusiones:

• La SIM1, por su patrón de comportamiento, pertenece o bien a S.P.F. o a un señor árabe que está en todo momento junto a ella (y no creemos que sea tan amigo como para que lo dejen entrar en su casa y en su trabajo).
• La SIM2 tiene como titular a V.P.F, que no es más que la hermana de S.P.F. Ella es un poco mayor para ir a un colegio privado, pero es muy posible que tenga hijas que sí que puedan hacerlo (¿y qué adolescente no querría un iPhone5?)

El terminal cambió de SIM1 a SIM2 el día después del asesinato. ¿Alguien se está deshaciendo de pruebas? Y sobre todo… ¿dónde está el móvil X? Una nueva orden judicial (con el juez ya un poco calentito al respecto) deshace el entuerto y nos da información sobre el terminal X:

c) SIM3 (conectada hasta el día de autos)

• Titular: Eduardo Tobías Jiménez Mejido.
• Patrón de llamadas: Varias llamadas a la SIM1, casi no hay llamadas a otros números.
• Patrón de localizaciones: La Moraleja, centro de Madrid, sede central de Armand & Old.

Este último patrón de localizaciones concuerda a la perfección con el de R.G, pero con un añadido: A eso de las 00.00h el terminal sale de la casa de Chamberí, se desplaza hasta la casa de R.G. en La Moraleja, permanece allí como 20min, empieza a moverse hacia el centro de Madrid… y desaparece sin dejar más rastro en la operadora.

Las FFCCSSE lo tienen bastante claro: las SIM han sido adquiridas en algún locutorio (recordad que desde hace años no se puede obtener un nuevo número de teléfono sin que tenga unos datos personales asociados al mismo) y los terminales han sido comprados en el mismo lugar, o mediante efectivo para no dejar huellas. Los patrones de localización cuentan una historia bien fácil de leer, situando ese terminal en la escena del crimen y relacionándolo con S.P.F.

Las evidencias parecen bastante claras, pero dado lo mediático del caso las FFCCSSE quieren un caso sólido y sin ningún resquicio, por lo que vamos a tener que recuperar esos dos terminales. La resolución del caso, en la próxima entrega…

(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 (ver parte I, parte II y parte III), teníamos a nuestra disposición las siguientes evidencias digitales:

• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Apple MacBook Pro.

La situación es casi la misma que en el caso de R.G, solo que con un portátil de Apple en lugar de uno de HP. El tratamiento de los móviles va a ser exactamente el mismo, así que nos ponemos rápidamente al lío.

[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.)

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…