Security Art Work

Todo lo sucedido en 2018 en relación al GRU, tanto las acusaciones públicas de diferentes gobiernos como las investigaciones privadas en relación a sus actividades, nos hacen plantearnos diferentes preguntas; seguramente todas ellas tengan respuesta, pero no la conocemos, o al menos no a ciencia cierta… por eso, también podemos hablar de conspiraciones a la hora de responder a estas cuestiones. Vamos a verlas en este apartado.

¿Cómo se ha obtenido esta información?

No lo sabemos. Desde luego, de fuentes públicas no: seguramente estamos hablando de información obtenida de fuentes humanas, por ejemplo, por un posible topo en el Servicio… o en otro servicio que conozca bien al GRU.

Algunos analistas relacionan con las informaciones que han visto la luz este año la detención, en diciembre de 2016, entre otros de Sergei MIKHAILOV (Coronel del FSB, Director del Segundo Departamento del ISC), Dmitry DOKUCHAEV (Comandante del FSB, adscrito al mismo departamento que MIKHAILOV y buscado además por el FBI) y Ruslan STOYANOV (analista de Kaspersky, pero anteriormente ligado al FSB). Acusados todos ellos de alta traición a la patria y que podrían haber vendido información sensible a la inteligencia estadounidense. ¿Podrían haber traicionado estas personas al FSB, y por extensión al GRU, facilitando datos de operaciones, agentes, técnicas… usadas por el Servicio contra intereses extranjeros? ¿Podría tener un topo aún activo alguno de los servicios rusos que venda esta información a otros servicios de inteligencia? Quién lo sabe…

¿Por qué se ha proporcionado públicamente tanto nivel de detalle, en especial USA y Holanda?

No lo sabemos. Sin ser un experto en leyes dudo que un documento de acusación requiera dar datos de empleos, direcciones, fechas concretas de actividades en una operación; y sin ser un experto en exposiciones de altos cargos de servicios de inteligencia, dudo también que una presentación pública requiera igualmente ese nivel de detalle. Insisto: sin ser un experto en ninguno de los casos. Documentos de servicios de inteligencia sí contienen esta información detallada, pero obviamente no salen a la luz, salvo excepciones (por ejemplo, [1]).

Sí que puedo decir, con algo más de criterio, que técnicamente hacer públicos estos datos puede ser contraproducente, salvo una excepción: que el gobierno estadounidense y el holandés busquen no sólo acusar, sino algo tan impensable como una demostración de fuerza… Quizás las palabras de Theresa May en su discurso ([2]) sean muy significativas: “We are increasing our understanding of what the GRU is doing in our countries, shining a light on their activities, exposing their methods and sharing them with our allies, just as we have done with Salisbury”. Sobre todo “exposing their methods”… ¿se refería la Primera Ministra británica simplemente a compartir esta información con sus aliados, o directamente a sacarla a la luz? Quién lo sabe…

¿Por qué sólo el GRU? ¿Por qué no se ha publicado información del FSB?

No lo sabemos. Al menos en la potencial injerencia rusa en las elecciones estadounidenses de 2016 no sólo participó el GRU: también lo hizo el FSB, en forma de APT29. Entonces, ¿por qué en 2018 sólo se ha acusado a miembros del GRU? ¿Vendieron, si es que realmente lo hicieron, MIKHAILOV, DOKUCHAEV y demás, sólo información del GRU? ¿Dispone la inteligencia estadounidense -o la británica, o la holandesa…- de información también del FSB que por algún motivo no han querido publicar? ¿O simplemente se la reservan para que vea la luz en 2019 y así podamos hacer un análisis y una serie especial del FSB en unos meses, como hemos hecho la del GRU? Quién lo sabe…

¿Es la unidad 26165 del GRU el grupo conocido como APT28? ¿Es la unidad 74455? ¿Son ambas unidades? ¿Ninguna?

No lo sabemos. Sí que sabemos -o creemos saber, porque lo dicen servicios aliados… que también pueden equivocarse o mentir- que APT28 está directamente ligado al GRU; vamos, que es parte del Servicio, bien como única capacidad ciber, o bien como una capacidad ciber más dentro del GRU.

En mi opinión, APT28 puede ser la Unidad 26165 si entendemos a APT28 como un actor avanzado que compromete objetivos y les roba información de potencial interés para Rusia; si entendemos a APT28 como, además de lo anterior, el actor que maneja dicha información -con infraestructura, sockpuppets, etc.-, en línea con el concepto ruso de information warfare o la confrontación de información técnica y psicológica a la que hemos hecho referencia quizás APT28 sea no sólo la Unidad 26165, sino también la Unidad 74455. Pensemos que es lógico que el manejo de información (la confrontación psicológica) recaiga en un grupo diferente al robo de información o las operaciones CNO (la confrontación técnica) por muchos motivos: calidad, seguridad… Así, APT28 podría ser la Unidad 26165 simplemente, la Unidad 26165 y la Unidad 74455 conjuntamente, coordinadas a un nivel superior dentro del GRU, o incluso podríamos identificar a APT28 con el GRU en su conjunto, sin descartar que dentro del Servicio haya más grupos APT, conocidos o no en estos momentos. Quién lo sabe…

¿Ya no es tan bueno el GRU? ¿Seguirá operativo en el ámbito ciber?

Sí lo sabemos. El GRU ha sido históricamente muy bueno (para algunos, el mejor) y seguirá siéndolo de aquí en adelante, tenga el nombre que tenga, tanto en el ámbito ciber como en el ámbito no ciber. Todos cometemos errores, a veces graves; el GRU siempre ha tenido fama de asumir riesgos y cuando uno asume riesgos puede equivocarse. Es así de sencillo. Pensemos, no obstante, en todas las operaciones exitosas que puede estar llevando a cabo el Servicio en estos momentos y que desconocemos: seguramente no hemos visto más que la punta del iceberg.

Sin duda APT28 no va a desaparecer; podrán cambiar sus TTP, algunos de sus objetivos, algunos de sus intereses… e incluso su identificación, pero tenga el nombre que tenga o que le quieran dar analistas de todo el mundo, seguirá operando en el ámbito ciber. Pensar lo contrario sería demasiado ingenuo.

Referencias

[1] NSA. Report on Russia’s Spearphishing. https://cryptome.org/2017/06/NSA-Report-on-Russia-Spearphishing.pdf

[2] Gobierno UK. PM statement on the Salisbury investigation: 5 September 2018. Septiembre,2018. https://www.gov.uk/government/speeches/pm-statement-on-the-salisbury-investigation-5-september-2018

La entrada (Ciber) GRU (XIII): preguntas y conspiraciones aparece primero en Security Art Work.

Hemos analizado en este trabajo principalmente la estructura, objetivos y TTP del GRU en el ámbito ciber, a partir de la información que durante 2018 ha visto la luz y que ha permitido obtener un conocimiento detallado del Servicio y sus actividades no sólo a servicios de inteligencia, sino también a pobres analistas como nosotros que no disponen de todas las capacidades de las que puede disponer un estado; con lo que sabemos, incluso analizando fuentes públicas, tenemos acceso a información que en algunos casos debe considerarse sensible y que sin duda está siendo -o ha sido- analizada por servicios de todo el mundo, empezando por la propia Rusia.

Que conozcamos mejor que hace un año al GRU no quiere decir que ahora sea un peor servicio que antes; seguirá estando en la élite, cumpliendo sus misiones y actuando “en cualquier parte del mundo donde se le requiera” según dijo uno de sus antiguos directores. El GRU, o APT28, o como le queramos llamar, seguirá siendo un actor muy importante en el ámbito ciber y, por supuesto, en el ámbito no ciber; todos cometemos fallos, y el GRU los ha cometido en esta ocasión -y se han publicado-. No obstante, seguro que preocupa más en ciertos círculos que el GRU haya fallado en sus operaciones a que se hayan filtrado las identidades o los modus operandi de algunos de sus miembros.

Desde este año, somos conscientes de la actividad ciber de dos Unidades del Servicio que trabajan de forma coordinada en beneficio de los intereses de la Federación Rusa; una de ellas, la Unidad 26165, es la responsable de las operaciones técnicas del GRU (CNE y CNA), mientras que la otra, la Unidad 74455 es la responsable de las operaciones psicológicas (PSYOP) del Servicio. Su trabajo conjunto refleja la concepción rusa del information warfare, diferente a la occidental y que se identifica con dos ámbitos de actuación: la confrontación de información técnica y la confrontación de información psicológica, el manejo de la información robada para favorecer a los intereses rusos.

APT28 está ligado al GRU, si no es el nombre que le hemos dado a la capacidad ciber del Servicio; posiblemente esté operativo desde 1953, año de fundación de la Unidad Militar 26165, por lo que en lugar de fancy bear deberíamos llamarle old bear (y de paso cambiarle el logo por el de la imagen adjunta), y quizás no sólo roba información en beneficio de un gobierno, el ruso, sino que la utiliza de forma inteligente en operaciones psicológicas. Y no sólo dispone de capacidades CNE, como cualquier servicio de inteligencia del mundo, sino también de capacidades CNA, ya que recordemos que es un Servicio militar y por tanto ejecutará operaciones de ataque puro, no sólo de robo de información.

Confiamos en que este trabajo ayude un poco a conocer mejor al GRU, del que ya hablamos brevemente cuando tratamos el tema de la comunidad de ciberinteligencia rusa y que últimamente, por todo lo que ha pasado, merecía una serie propia. Ahora, a esperar nuevas informaciones públicas que nos permitan analizar igualmente la capacidad ciber del FSB, hasta hace unos meses más conocida que la del GRU pero que seguro que tiene aspectos que ni imaginamos…

La entrada (Ciber) GRU (XIV): conclusiones aparece primero en Security Art Work.

El ciberespionaje se ha incrementado hacia las organizaciones deportivas antidoping. Entre 2016 y 2018 se han identificado diversos ciberataques a importantes organizaciones internacionales antidoping. Como cita A. Villalón en su post sobre la actividad del GRU en octubre de 2018 “el NCSC británico acusó públicamente al GRU de actividades de ciberespionaje contra la agencia WADA (World Anti-Doping Agency)”. También se les atribuyen los ciberataques a la organización IOC (International Olympic Committee Antidoping) y la CCES (Canadian Center Ethics for Sports) donde presuntamente entre sus principales objetivos estaba captar las credenciales de los oficiales y técnicos antidoping para posteriormente poder acceder a la información clasificada. Otro técnico antidoping, en este caso de la USADA (US Antidoping Agency), el cual estaba ubicado en Río de Janeiro durante los Juegos Olímpicos, le fue comprometida su cuenta de email desde la wifi del hotel por presuntos agentes del GRU (se recomienda la lectura de los posts de A. Villalón sobre el GRU, la Unidad 74455 y 26165). Por los diferentes acontecimientos relacionados con el ciberespionaje dentro de las organizaciones internacionales antidoping, podemos apreciar que el deporte internacional posee más relevancia para las superpotencias mundiales, como Rusia, de la que muestran a priori.

El deporte siempre ha sido una herramienta psicosocial útil ([4]) para que los gobiernos de superpotencias puedan incentivar determinadas emociones, sentimientos e incluso valores entre sus ciudadanos. Los éxitos deportivos nacionales de un país generan sentimientos de unión social, rebajando una posible tensión ideológica de los mismos. Existe un efecto psicosocial ([7]) donde la sociedad tiende a vincular su sentimiento patriótico y de identidad nacional con los éxitos deportivos internacionales de su país.

El deporte se podría considerar como una de las partes del “Soft Power” de un gobierno o Estado. Este concepto de “Soft Power” se entiende como aquella acción estratégica que lleva a cabo un gobierno a través de elementos estatales culturales como el deporte, el arte o actos institucionales para llevar a cabo modificaciones de los valores, comportamientos y sentimientos de sus ciudadanos. Entenderíamos como “Hard Power” aquellas acciones, diplomáticas, militares y económicas que emprende un Estado para controlar determinados elementos de interés y seguridad nacional.

Durante el siglo XIX, el uso del deporte por parte de los gobiernos de Estados considerados superpotencias, aumentó considerablemente. Gran Bretaña y Rusia fueron Estados que emprendieron una estrategia de soft power dentro del ámbito del deporte para generar un sentimiento de supremacía deportiva con la intención de que se lleve a cabo una extrapolación hacia otros sectores estatales. A través del éxito deportivo, los gobiernos pretenden transmitir un sentimiento de superioridad enfrente del resto de Estados, pretenden generar la percepción de supremacía que probablemente desembocará en el aumento de patriotismo en la sociedad.

Durante el S.XX, esta estrategia de soft power deportiva fue utilizada por los gobiernos autoritarios de Rusia y Alemania entre otros. Los dos Estados pretendían generar un sentimiento de supremacía entre sus ciudadanos y, al mismo tiempo, tenían el objetivo de aumentar el ocio y la distracción dentro de sus sociedades, ya que tenían unos elevados niveles de represión social. Sus objetivos principales eran, en primer lugar, mantener el patriotismo basado en sentimientos de supremacía racial, nacional y cultural. En un segundo plano, buscaban generar un medio psicosocial de canalización positiva de la opresión y la tensión social sufrida por los mismos gobiernos autoritarios.

Los Juegos Olímpicos que transcurrieron durante el período de la Guerra Fría fueron altamente útiles para que los gobernantes de la URSS y de los EEUU influyeran en la creación de la identidad nacional de los ciudadanos soviéticos y norteamericanos.

Actualmente, para un Estado es altamente relevante disponer de éxitos deportivos internacionales con presencia en los medio de comunicación. ([7]) Este elemento es clave, ya que si las selecciones nacionales de un Estado tienen éxitos profesionales sin que estas sean transmitidas por medios internacionales, sus ciudadanos no desarrollarán la percepción de supremacía ya que una parte muy significativa de la creación de la identidad nacional es el cómo nos perciben las sociedades ajenas o extranjeras. Consecuentemente, la internacionalización de los éxitos deportivos será clave para la creación del sentimiento social de patriotismo. Esta característica nos ayuda a comprender por qué Rusia tiene un elevado interés en sus deportistas olímpicos y no tanto en los deportistas sin proyección internacional o sin presencia mediática. Los Juegos Olímpicos es el evento con más expectación global y además sus participantes están representando directamente a sus Estados y no a entidades privadas como podría producirse en otros eventos deportivos con alta notoriedad mediática internacional.

El Kremlin fue acusado de una presunta manipulación de test/informes positivos de atletas rusos. ([8]) Entre 2011 y 2015, el Kremlin estableció un entramado de corrupción estatal para manipular test positivos de doping de atletas rusos. Presumiblemente, los test de las agencias extranjeras eran enviados a un laboratorio donde se encontraba el Director Grigory Rodchenkov, los analizaba y, cuando daba con un positivo, consultaba con la agencia antidopaje RUSADA para saber a quién correspondía. Seguidamente, informaba a Yuri Nagornykh, Viceministro de Deportes ruso. Él era el responsable de decidir si Rodchenkov debía manipular la información del positivo en el sistema ADAMS, sistema compartido con la agencia AMA y otras federaciones internacionales. De los 577 positivos detectados 312 fueron manipulados y eran los atletas con mayor potencial para obtener medallas.

Como se puede apreciar en el gráfico, la gran mayoría de las manipulaciones de test positivos pertenecían a la modalidad del atletismo, una de las más televisadas en el mundo dentro de los JJOO. En segundo lugar, encontramos a la modalidad de halterofilia, una modalidad que por su idiosincrasia transmite un mensaje de fuerza y grandeza.

En los JJOO de Sochi (Rusia) de 2015, ([8]) presuntamente el FSB construyó un edificio al lado del edificio de antidopaje que estaba gestionado por la AMA que vigilaba el buen desarrollo para los controles antidoping. A través de un agujero en el despacho del Director Rodchenkov pasaba de un edificio a otro las muestras de los test manipulados de los deportistas. El FSB obtenía muestras limpias de todos aquellos deportistas y realizaban el intercambio por la orina manipulada. Hasta 15 de los casos fueron medallistas.

El sistema de dopaje estatal de la Federación de Rusia se diseñó con intención de garantizar o aumentar los éxitos deportivos durante los Juegos Olímpicos. Uno de sus objetivos fue aumentar el orgullo patrio de los ciudadanos rusos y generar una identidad nacional más consolidada. Con las presuntas operaciones de ciberespionaje en las diferentes agencias antidoping ([6]), el GRU, pretendía adquirir información confidencial sobre las investigaciones antidoping dirigidas hacia sus deportistas y robar información sobre deportistas pertenecientes a otros Estados.

Referencias:

Villalón, A. (2018, 26 diciembre). (Ciber) GRU (V): octubre 2018 – Security Art Work. Recuperado de https://www.securityartwork.es/2018/12/26/ciber-gru-v-octubre-2018/
Villalón, A. (2018b, 28 diciembre). (Ciber) GRU (VII): estructura. Unidad 26165 – Security Art Work. Recuperado de https://www.securityartwork.es/2018/12/28/ciber-gru-vii-estructura-unidad-26165/
Villalón, A. (2019, 4 enero). (Ciber) GRU (VIII): estructura. Unidad 74455 – Security Art Work. Recuperado de https://www.securityartwork.es/2019/01/03/ciber-gru-viii-estructura-unidad-74455/
[4] Ørnulf Seippel (2017) Sports and Nationalism in a Globalized World, International Journal of Sociology
[5] McClaren, R. H. (2016). WADA INVESTIGATION OF SOCHI ALLEGATIONS (2nd REPORT). Recuperado de https://www.wada-ama.org/sites/default/files/resources/files/mclaren_report_part_ii_2.pdf
[6] FBI. (2018, 4 octubre). GRU HACKING TO UNDERMINE ANTI-DOPING EFFORTS. Recuperado de https://www.fbi.gov/wanted/cyber/gru-hacking-to-undermine-anti-doping-efforts
[7] Bairner, Alan. 2001. Sport, Nationalism, and Globalization: European and North American Perspectives. Albany: State University of New York
[8] Arribas, C. (2016, 21 julio). Así hacía desaparecer Rusia los positivos de sus mejores atletas. https://elpais.com/deportes/2016/07/18/actualidad/1468863237_248396.html

La entrada El deporte como Soft Power para las grandes potencias aparece primero en Security Art Work.

[Nota: Este artículo ha sido elaborado por Arturo Navarro y Salvador Sánchiz Aranda]

Tal y como nos contaba nuestra compañera Maite Moreno en este mismo blog, Shamoon fue como se denominó a una campaña atribuida supuestamente a Irán en 2012 y centrada principalmente en la destrucción de información, principalmente en petroleras de Arabia Saudí. Como también se indica en el mismo artículo, la rivalidad entre Arabia Saudí e Irán es histórica, con lo que este tipo de campañas podrían ser habituales entre ambos estados.

Shamoon ha estado evolucionando desde aquel 2012 y en este artículo os queremos hacer un análisis sobre las tres versiones que se han ido detectando de dicha amenaza.

LAILAT AL-QADR AGOSTO 2012 – SHAMOON V1

El Laylat al-Qadr (la Noche del Destino o del Poder) es una de las noches más sagradas para el Islam durante el mes de Ramadán. Se trata de la celebración de la revelación del Corán a Mahoma. En 2012, durante esa noche, se aprovechó tal festividad para lanzar un ciberataque (Shamoon) contra el sector energético en Oriente Medio (algo así como aprovechar la Nochebuena en occidente para poner en jaque a las empresas). Concretamente, el ataque fue dirigido contra la empresa estatal de Arabia Saudí de petroleo y gas llamada Saudi Aramco (valorada actualmente en 1.7 billones de euros y que produce más del 10% del petroleo mundial) y en menor medida la empresa de Qatar de gas natural RasGas, como protesta del apoyo del régimen Al-Saul para la represión del gobierno en países vecinos. Aproximadamente tres cuartas partes del total de los equipos de Saudi Aramco fueron comprometidos por un malware de tipo wiper que destruyó todos los datos de los sistemas afectados.

El principal sospechoso de llevar a cabo el ciberataque es el grupo de hackers llamado Cutting Sword of Justice. Los ataques fueron supuestamente auto-atribuidos a este grupo de hackers a través de un comunicado colgado de forma anónima en la web PasteBin y firmado por el susodicho grupo, donde se puede leer una justificación por las afrentas producidas por el régimen de Al-Saud (la Casa Real).

Cuando la pieza de malware asociada a Shamoon fue descubierta, apuntaba a la cadena de texto

“C:\Shamoon\ArabianGulf\wiper\release\wiper.pdb”

y es por ello que Symantec, Kaspersky Lab y Seculert decidieron ponerle ese nombre a la amenaza.

Destripando los componentes (dropper, wiper y módulo de reporte) que forman Shamoon v1 podemos dividir su funcionamiento en las siguientes fases:

FASE 1: VÍA DE ENTRADA

Lo primero que llama la atención es el uso de una memoria USB (existen contradicciones entre fuentes en las que algunas apuntan a que el vector de entrada fue un ataque de spear-phishing al PC de un empleado del equipo de IT), por parte de un insider, conectada en un puerto como vector de infección por donde se introduce el payload en el entorno del sistema, que básicamente es el dropper, responsable de crear todos los ficheros necesarios en el OS y registrar un servicio (%System%\trksvr.exe) de persistencia con el nombre “TrkSvr”.

FASE 2: PROPAGACIÓN

Aparece un comportamiento de gusano, en el que el dropper intenta, en una primera instancia, replicarse en espacios de datos compartidos tomando el control del controlador de dominios para propagarse mucho más rápido y fácil. En segundo lugar, intenta ejecutarse de forma remota para infectar al resto de hosts de la misma red.

FASE 3: DESTRUCCIÓN DE LA INFORMACIÓN

El wiper borra todos los ficheros del sistema siguiendo un orden específico y con una estructura concreta preconfigurada, es decir, busca tipos de carpetas (configuración, documentos, usuarios). En paralelo, sube los datos borrados a un servidor controlado por el atacante y borra los logs de eventos que está generando para no dejar ningún rastro de sí mismo. Un perito forense tendría graves problemas para generar una traza de ejecución del malware. Una vez borrados, genera los archivos que existían y los sobrescribe con contenido binario que coincide con la representación de una bandera estadounidense en llamas con formato JPEG, lo que se puede interpretar como una señal de que el ataque fue realizado por un bando motivado por intereses políticos más que económicos.

Una vez el wiper ha finalizado el borrado inicial prosigue con el MBR (Master Boot Record) y las operaciones realizadas por el core file system. El MBR es el primer sector escrito en el disco duro que define cómo se particiona la memoria y cómo cargar el OS durante el arranque. Con el MBR corrupto, comprometido o borrado el OS se vuelve prácticamente inoperable. En el proceso de modificar, cambiar o eliminar el MBR, Shamoon realmente aprovecha una pieza de software comercial llamado RawDisk, creada por la empresa estadounidense EldoS, que permite acceder al disco duro desde el modo de usuario y sin necesidad de emplear las APIs de Windows y se puede usar para eliminar un MBR.

FASE 4: COMUNICACIÓN CON C2

El módulo de reporte informa de los resultados de las operaciones anteriores a un servidor C2 central ubicado en algún lugar para fines de mantenimiento de registros. Además, dispone de capacidades para descargar archivos binarios adicionales del C2 y cambiar el tiempo preconfigurado de borrado del disco, si así se lo indican. Uno de los puntos a destacar en el caso particular de Shamoon, el C2 está alojado internamente. Este hecho ocurre con muy poca frecuencia, lo cual da más credibilidad y peso al argumento de que la amenaza podría haber sido introducida por insiders en la organización. Un servidor interno es fácilmente accesible desde dentro, pero es posible que desde fuera no sea tan sencillo.

NOVIEMBRE 2016 – ENERO 2017. SHAMOON V2

Shamoon v2 aparece en 17 Noviembre 2016 con más impactos el 19 de noviembre de 2016 y el 23 de enero de 2017. Casi no ha cambiado respecto a v1, pero sí presenta algunos cambios como la mejora de las técnicas anti-sandbox o uso del navegador como vector de entrada para inyectar el wiper directamente en memoria sin usar drivers, según datos de Kaspersky Lab.

Sus objetivos principales siguen siendo el borrado de datos críticos incluyendo el MBR y la destrucción masiva de operaciones. En este caso, las víctimas de este nuevo ataque fueron los sistemas informáticos de la Autoridad General de Aviación Civil (GACA) de Arabia Saudí y otras 5 agencias gubernamentales en el Golfo Pérsico. Se estiman más de 1000 hosts infectados en GACA y no se han encontrado datos concluyentes sobre el resto de organizaciones.

SHAMOON V1 VS V2

Como se ha mencionado, una característica nueva que incorpora esta segunda versión del malware es un módulo de detección de sandboxes con técnicas avanzadas de escape que le agregan la posibilidad de bypassearlas utilizando una bomba lógica en su código.

En esta versión el dropper, una vez alcanza el OS de la víctima, comprueba en una variable de entorno la arquitectura del procesador para instalar la variante de 32-bit (ntssrvr32.exe) o 64-bit (ntssrv64.exe) que levante uno u otro servicio de persistencia, lo cual no estaba presente en v1. El servicio de persistencia (%System%\ntssrvr32.exe o %System%\ntssrvr64.exe) pasa a llamarse “NtsSrv”. Además, también mejora el dropper, que aprende a auto-mutar para evadir los sistemas de seguridad de detección basados en firmas.

El wiper también sufre modificaciones para funcionar en modo borrador o cifrador, es decir, se añade un nuevo módulo de ransomware totalmente funcional que no se ha empleado en este ataque (inactivo) pero no deja de dilucidar ideas para próximas variantes. Se puede apreciar la existencia de un generador pseudoaleatorio de claves RC4 (Rivest Cipher 4) que se cifra adicionalmente con una clave pública RSA (Rivest, Shamir y Adleman) preparada para secuestrar los datos y probablemente pedir un rescate por su recuperación.

Otro detalle añadido al wiper es una función de ajuste de hora del reloj de los sistemas infectados, que la cambia de forma aleatoria a fecha de entre el 1-20 de agosto de 2012 (Shamoon v1), con el fin de poder validar la licencia y el periodo de evaluación de la herramienta de software comercial RawDisk.

También se remplaza la imagen de la bandera estadounidense en llamas por una foto del cuerpo de Alan Kurdi, un refugiado sirio de 3 años muerto ahogado en una playa de Turquía al tratar de cruzar hasta Grecia el 2 de septiembre de 2015.

En el siguiente artículo continuaremos con la evolución de Shamoon y otros aspectos relacionados de interés.

La entrada Evolución de Shamoon – Parte 1 aparece primero en Security Art Work.

[Nota: Este artículo ha sido elaborado por ARTURO NAVARRO y SALVADOR SÁNCHIZ ARANDA]

Tal y como indicábamos en el anterior artículo de esta saga continuamos con la disección de la amenaza Shamoon, en esta ocasión en su vertiente más reciente.

DICIEMBRE 2018. SHAMOON V3

Shamoon v3 aparece el 10 de diciembre 2018 con más similitudes a la versión original que a la v2. Aparece combinada con una nueva pieza de malware, Filerase (también llamada Trojan.Filerase), responsable de borrar datos del OS del host infectado de forma totalmente permanente (siendo imposible su recuperación con técnicas forenses), para posteriormente proceder al borrado de MBR que realiza el componente wiper de Shamoon v3.

Los impactos que ha tenido en el sector energético (petróleo y gas) no son numerosos pero sí muy dirigidos, entre ellos por ejemplo, la empresa italiana Saipem con cerca de 500 hosts infectados y se conoce que existen dos organizaciones más afectadas ubicadas en Arabia Saudí y Emiratos Árabes Unidos. Saipem es una importante compañía del sector de la industria del petróleo y gas.

El vector de entrada usado parece ser spear- phishing a través de páginas falsas casi idénticas a las legítimas que ofertaban empleo:

Hxxp://possibletarget.ddns.com:880/JobOffering

Muchas de las webs estaban vinculadas al sector energético, especialmente relacionadas con Oriente Medio y contenían HTML malicioso que ejecutaba código malicioso. Otras invitaban a las víctimas a iniciar sesión con sus credenciales corporativas. Se cree que esta fase preliminar pudo comenzar en agosto de 2018.

PROPAGACIÓN

OCLC.EXE es el módulo responsable de leer los archivos almacenados localmente, que en el ejemplo se llaman shutter y light que contienen listados de hosts objetivo, para volcar su contenido en una cadena string. Una vez realizado, arranca un proceso en una terminal oculta para invocar al segundo script spreader.exe, que envía a Filerase y al wiper de Shamoon v3, que toman como parámetro el string anterior con la información de las víctimas.

SPREADER.EXE Este módulo es el distribuidor, que realiza la siguiente secuencia de pasos que permiten tracear el movimiento lateral dentro de la red:

Toma el archivo con la lista de víctimas como parámetro y su versión de Windows.
Comprueba la versión de Windows de los hosts objetivo y coloca los ejecutables de Shamoon y Filerase en la carpeta net2.
Crea una carpeta remotamente en las víctimas, en la ruta
```
C:\\Windows\System32\Program Files\Internet Explorer\Signing
```
donde copia el ejecutable.
Lo ejecuta en el host remoto creando un archivo .bat en un recurso compartido
```
\\RemoteMachine\admin$\\process.bat
```
Este archivo contiene las rutas de los ejecutables. Entonces, el spreader eleva privilegios para ejecutar el .bat.

Si algo fuera mal, el módulo generaría un fichero NotFound.txt que contendría el hostname y su versión, lo que permitiría a los atacantes realizar un seguimiento del proceso de expansión y distribución del malware. Si los ejecutables no estuvieran en net2, Shamoon v3 busca las carpetas all y net4.

SPREADER.PSEXEC.EXE es un spreader adicional que los atacantes incorporaron empleando el servicio Psexec.exe, una herramienta de administración para ejecutar comandos de manera remota. La diferencia con el módulo anterior es que en esta ocasión empleamos psexec, que deberá estar almacenado en net2 en el host a donde nos queremos mover. Podría usarse en hosts adicionales para extender y proliferar el malware.

FILERASE es la herramienta de malware más importante del ataque. Este wiper tiene tres opciones:

SilentMode: no genera outputs.
BypassAcl: escala privilegios y siempre está activado.
PrintStackTrace: realiza un seguimiento del número total de carpetas y archivos eliminados.

La opción “BypassAcl” está activada por defecto y activa los siguientes privilegios: SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege y SeSecurityPrivilege.

Para hallar un nuevo archivo que eliminar, emplea la función GetFullPath, que obtiene todas las rutas, para después borrar todos los archivos y carpetas. A continuación, el wiper navega entre todos los archivos del sistema.

En el proceso de borrado, primero elimina el atributo sólo lectura para sobrescribirlos. Entonces modifica los datos de creación, escritura y acceso a 01/01/3000, 12:01:01. El malware reescribe cada archivo dos veces con cadenas de texto aleatorias.

Llegados a este punto, comienza a eliminar los archivos empleando una API: CreateFile, con el flag ACCES_MASK DELETE. Después, emplea FILE_DISPOSITION_INFORMATION para eliminar los archivos.

La función ProcessTracker realiza un seguimiento del proceso de destrucción.

NOVEDADES RESPECTO A VERSIONES ANTERIORES

En esta versión, el servicio de persistencia que crea el dropper se llama MaintenaceSvr y la ruta en la que se instala la variante de 32-bit
```
%System%\MaintenaceSvr32.exe LocalService
```
y la de 64-bit es
```
%System%\MaintenaceSvr64.exe LocalService
```
El dropper, una vez infecta el sistema, puede tomar diferentes valores de forma aleatoria en la ruta:
```
%System%\{wiper name}
```
Las carpetas de red a las que se propaga son:
```
ADMIN$, C$\WINDOWS, D$\WINDOWS y E$\WINDOWS
```
La imagen que sobrescribía los ficheros de una bandera o un niño muerto ya no está, pero hay referencias a una ruta en la que se debería de colocar.

CONCLUSIONES Y ATRIBUCIONES

Shamoon ha sido uno de los malware más letales de los últimos años, provocando cuantiosas pérdidas económicas. Con pocas modificaciones, ha reaparecido una y otra vez, destruyendo sistemas y causando daño a empresas críticas. Ya sea para obtener ventajas económicas o como represalia, lo cierto es que el efecto es sin duda devastador. Respecto al futuro, vaticinamos nuevas apariciones de Shamoon v4, con ligeras pero efectivas modificaciones y mejores técnicas de ofuscación.

Este nuevo ataque recuerda mucho a Shamoon v1, aunque en lugar de una bandera ardiente o un niño ahogado se ha encontrado versos del Corán escritos en ASCII (تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ) lo que nos lleva a pensar que los autores están relacionados con Oriente Medio.

Es razonable pensar que este ataque está relacionado con los anteriores, dado que los objetivos son esencialmente los mismos (empresas relacionadas con Arabia Saudí). Analistas de McAfee afirman que los ataques involucran a múltiples desarrolladores. Si analizamos a nivel técnico, tanto las herramientas como los dominios empleados coinciden con el modus operandi de APT33, un conocido grupo supuestamente relacionado con el gobierno iraní que ya ha mostrado interés, en el pasado, con los sectores de la aviación (tanto militar como comercial) y energético (especialmente la petroquímica). Analizando la hora de los ataques se pueden cuadrar con el horario laboral iraní (de sábado a miércoles, librando jueves y viernes), lo que refuerza la idea de que pudieran trabajar para el gobierno iraní.

Al grupo APT33 se le atribuyen ataques contra empresas estadounidenses, surcoreanas y saudíes mediante las técnicas de spear-phishing, aunque empresas de ciberseguridad como FireEye se niegan a revelar el nombre de las empresas afectadas. Este método se centra en el envío de emails personalizados a un objetivo muy concreto que provoca la descarga y ejecución de archivos .hta (HTML Application), infectando a la víctima que abre su contenido. FireEye también cree que el objetivo de los ataques podría ser la obtención de información, mientras que casas de anti-malware de Corea del Sur estiman que podrían deberse a los vínculos de las empresas afectadas con las petroquímicas árabes.

Una de las herramientas empleadas por este grupo es un módulo llamado ALFA TeaM Shell (también conocido como Alfa Shell) con capacidad para enviar cientos de emails a las víctimas, siempre con un grado de apariencia legítima muy alto, mediante la compra de dominios que parecen reales, por ejemplo de empresas como Boeing, Alsalam Aircraft Company, Northrop Grumman Aviation Arabia (NGAAKSA) o Vinnel Arabia, o por ejemplo, haciendo uso de subdominios gratuitos como boeing[.]servehttp[.]com.

Algunas herramientas cuyo uso se le atribuye a este grupo son NETWIRE y TURNEDUP que permiten al atacante crear backdoors de forma sencilla. Debuggeando varias muestras de estos malwares se encontró la ruta:

C:\Users\xman_1365\Desktop\homeWork\13930308\Bot_70_FIX
 HEADER_FIX_LONGURL73_StableAndNewProtocol-loginall\Release\Bot.pdb

cuyo usuario coincide con el nombre del administrador de la comunidad de un foro de software iraní de Barnamenevis, colocándole en el punto de mira como colaborador durante su desarrollo. Además, FireEye afirma que existen vínculos entre “xman_1365_” y el Nasr Institute (ciber-ejército iraní), no han trascendido más datos.

Por dar más referencias, APT33 emplearía DropShot para instalar un backdoor con TurnedUp. El dropper DropShot/StoneDrill está relacionado con el wiper ShapeShift por contener ambas piezas de malware trazas en farsi, el idioma oficial de Irán, lo que podría significar que los creadores pertenecen a ese país. Otras como Nanocore, Alfa Shell o NetWire están disponibles desde webs relacionadas con hackers iraníes.

La entrada Evolución de Shamoon – Parte 2 aparece primero en Security Art Work.

En esta vida hay cosas que nunca nos apetece hacer: bajar la basura, hacer dieta, una colonoscopia un lunes en ayunas… En el mundo TIC esos “no apetece” son a veces ligeramente diferentes. Sería realmente curioso saber los resultados de esta encuesta.

Elige por orden de preferencia las siguientes actividades:

Realizar una presentación ante tu jefe y el jefe de tu jefe.
Documentar con detalle un código/sistema que estás a punto de desplegar.
Realizar un informe técnico de 50+ páginas.
Pelear en pelotas contra un oso armado con un mondadientes.

En muchos casos el personal técnico es justamente eso: técnico. No vamos a entrar en el cliché de “toda la gente que trabaja en tecnología son unos frikis”, pero sí que hay que reconocer que a los técnicos nos suele gustar más cacharrear, desarrollar, crear cosas… que tener que contarlas.

Existe, sin embargo, una cruda realidad; la calidad de vuestro trabajo va ser el máximo de dos factores: vuestra capacidad técnica REAL y vuestra capacidad técnica PERCIBIDA. Es decir, podéis ser técnicamente excelentes, pero si vuestros jefes no perciben esa calidad… es un problema. Una presentación, una documentación o un informe son en realidad una extensión de vuestras capacidades, y de ahí la necesidad de desarrollarlas como medio de avance profesional.

El cómo presentar dignamente merecería una serie completa de artículos, así que vamos limitarnos a recomendaros varios recursos de calidad:

Presentaciones artesanas: Tienen un par de libros estupendos, y un mini curso en SlideShare que es oro puro. Altamente recomendables.
El arte de presentar: Tienen unos cursos presenciales de cómo hacer presentaciones excelentes, y un libro avanzado espectacular.
Nancy Duarte: Es una jefa de las presentaciones. Sus libros Slide:ology, Resonate e Illuminate son la santísima trinidad sajona de cómo hacer presentaciones like a boss.

La documentación de código/sistemas es un ámbito a veces tan específico que no tenemos recursos sólidos que recomendaros. Si alguien tiene documentación sobre cómo documentar en condiciones (valga la redundancia), será más que bien recibida en los comentarios.

Pasemos entonces a cómo realizar informes técnicos, tarea para la cual hemos recopilado una buena cantidad de consejos y trucos, estructurados en cuatro categorías:

Consejos estratégicos: notas de alto nivel sobre cómo afrontar crear un informe técnico.
Consejos de estructura: cómo estructurar tu informe técnico.
Consejos de redacción: cómo redactar tu informe técnico de forma profesional.
Consejos espirituales: un pequeño cajón de sastre sobre cómo mejorar tus capacidades.

Es obligatorio dar el mérito correspondiente a Lenny Zeltser (@LennyZeltser), que con su cheatsheet de consejos sobre cómo escribir informes (que compartimos al 95%) han ayudado a cristalizar este HowTo (y dicho sea de paso, tiene unos materiales sobre análisis de malware excelentes). Dicho esto, si tienes tu procesador de texto favorito abierto, tu CPU sin carga y un buen café… ¡empezamos!

Consejos estratégicos

Determina los objetivos del informe

Lo primero que debes hacer cuando escribes un informe técnico es determinar su función: qué es lo que queremos conseguir con el mismo, cuáles son los objetivos a alcanzar.

Puede ser explicar un incidente de seguridad (profundizaremos más en esa subcategoría), realizar un análisis de pros y contras de una tecnología o algo tan simple como mostrar el estado de un proyecto.

Sea cual sea, tienes que ser capaz de condensar el objetivo del informe en una línea de texto, y usar esa línea de texto como una regla básica en la redacción del documento: si lo que escribes no está directamente alineado con esos objetivos, probablemente no sea necesario.

Ejemplos:

Definir la respuesta llevada a cabo respecto al incidente de seguridad PI-0023.
Establecer los requisitos de seguridad de la arquitectura de XXX.
Decidir si emplear la tecnología X o Y en el proyecto Z.

Consejo 1: Define el objetivo del informe; Concrétalo para que ocupe una línea de texto.

Identifica a tu audiencia

Casi tan importante como saber lo que tienes que contar es conocer a quién se lo tienes que contar. Nuestros informes pueden estar dirigidos a diversos tipos de perfiles, y cada uno tiene su propia cultura y necesidades. Saber identificar el destinatario de nuestro informe y adaptar nuestro mensaje al mismo hará que llegue más fácil e incrementará su eficacia.

Ejemplos:

Técnicos: querrán más detalles técnicos, y se fijarán más en la solidez de las decisiones técnicas tomadas.
Directivos: querrán más detalles de todo relacionado con costes y plazos, y se centrarán en las ventajas competitivas.
Legal: querrán más detalles de posibles normativas/leyes implicadas, y se centrarán en las posibles consecuencias legales del informe.

Consejo 2: Identifica quiénes va a leer tu informe, y redacta el documento con ello en mente.

KISS (Keep it Simple, Stupid)

Este es un consejo de doble filo: en algunas organizaciones se valora la calidad de un informe y el trabajo que ha costado en función de las páginas que ocupa (lo que se llama cariñosamente “calificar el informe al peso”).

Sin embargo, la realidad es que muchos jefes no quieren (ni tampoco tienen tiempo) de leerse 200 páginas de prosa rimbombante con abundante relleno que engorda el informe cual pienso para un cochino. ¿Para qué sí que van a tener tiempo? Para leerse un informe de 20 páginas en el que se explique de forma clara y concisa el objeto del informe.

Ejemplo: Informe de un incidente dirigido al responsable de seguridad (v1)

Los atacantes hicieron uso de una vulnerabilidad 0-day (fallo de seguridad no reconocido por el fabricante para el que no hay parche conocido) para realizar un ataque de DDoS (Distributed Denial of Service, ataque de denegación de servicio distribuida) para agotar los recursos de CPU de los 16 frontales web del cluster de VMWare PEPITO (situado en las instalaciones de Mordor, Carretera Lorien 21), obligando a los técnicos a realizar un esfuerzo adicional y entrar por la VPN SSL ofrecida por el software F35-B en su versión 2.2.2.1 para realizar un inventario pormenorizado del estado de los servidores y reiniciar mediante IPMI los servidores 2,3 y 5.

En este caso la audiencia es un perfil técnico: si tenéis que explicarle al CISO de vuestra organización qué es un DDoS o un 0-day, estamos buenos. Y a menos que la versión de VPN empleada tenga algo que ver con el incidente, tampoco es necesario incluirla (en todo caso, iría en los anexos como veremos cuando hablemos de cómo estructurar un informe).

Ejemplo: Informe de un incidente dirigido al responsable de seguridad (v2)

Los atacantes emplearon un 0-day para realizar un DDoS contra los frontales web del clúster PEPITO. Los técnicos tuvieron que reiniciar los servidores 2,3 y 5.

Como veis, si vamos al grano y nos centramos en lo importante pasamos de 8 líneas a 2. Ahorramos tiempo en la redacción del informe, hacemos felices a nuestros jefes y salvamos árboles del Amazonas (por desgracia, a día de hoy todavía se imprimen muchos documentos)

Consejo 3: Sé conciso y claro. Si crees que algo no hace falta, elimínalo o muévelo a los anexos.

Ofrece valor

Todo informe realizado debe aportar algo que ayude a resolver el problema presente. Analiza el contenido de tu informe y pregúntate: ¿Qué valor estoy aportando con este documento? Es muy importante identificar el valor que aportamos con ese documento y resaltarlo debidamente en los lugares adecuados (resumen ejecutivo, conclusiones, etc…)

Ejemplo: La optimización de las reglas YARA en función de su tasa de falsos positivos y su necesidad real ha permitido eliminar 100 reglas, reduciendo en un 20% la tasa de falsos positivos de la plataforma de seguridad.

Consejo 4: Identifica el valor aportado en tu documento y dale visibilidad.

La entrada Cómo escribir informes técnicos y no morir en el intento (I) aparece primero en Security Art Work.

Cómo escribir informes técnicos y no morir en el intento [1] [2]

Consejos de estructura

Define una estructura base
Si tu informe tiene una buena estructura va a ser mucho más fácil de redactar, y sobre todo de leer (recuerda que nuestro objetivo es el éxito del informe, así que toda ayuda es bienvenida). Una estructura básica válida para prácticamente cualquier tipo de documento podría ser esta:

Resumen ejecutivo: es tan importante que tiene apartado propio
Objeto y alcance: cuál es el objetivo del documento y hasta dónde vamos a llegar
Antecedentes y consideraciones preliminares: todo aquello que debería conocerse de forma previa a la lectura de este informe
Análisis: describir el trabajo realizado objeto del informe
Conclusiones: a qué conclusiones llegamos con los análisis realizados.
Anexos: toda la información adicional que queramos incluir

Consejo 5: Define una estructura base para tu contenido.

Define el resto de puntos del informe creando un índice

Una vez completada la estructura base, lo siguiente que tienes que hacer es pensar en cómo vas a estructurar el resto del documento. Una técnica excelente es la de “completa el índice”: crea el resto de puntos del documento y crea un índice vacío dentro de tu procesador de textos.

Puede parecer una tontería, pero una técnica muy efectiva para evaluar libros técnicos es a través de su índice: con un poco de práctica, de un vistazo puedes saber si un libro te puede interesar o no… y lo mismo sucede con muchos informes. El tener un buen índice ayuda a los lectores a localizar las partes que les interesan, y a vosotros a la hora de redactarlo ya que al final ya sabéis dónde tenéis que poner cada cosa, y tan solo es cuestión de ir “rellenando” los huecos.

Ejemplo (auditoria de seguridad)

Resumen ejecutivo
Objeto y alcance
- Sistemas a auditar
- Sistemas expresamente fuera del alcance
Antecedentes y consideraciones preliminares
- Personal de contacto de cada entidad
- Reglas particulares de la auditoria
- Fechas de realización de la auditoria
Resultados de la auditoria
- Sistema A: vulnerabilidades graves y muy graves
- Sistema A: vulnerabilidades medias
- Sistema A: vulnerabilidades leves
- Sistema B: vulnerabilidades graves y muy graves
- Sistema B: vulnerabilidades medias
- Sistema B: vulnerabilidades leves
Conclusiones
Anexo A: Listado de vulnerabilidades detallado
Anexo B: Evidencias de los análisis realizados
- Sistema A
- Sistema B

Consejo 6: Crea un índice completo para tu documento. Haz que sea claro y limpio.

El resumen ejecutivo es tu mejor amigo

Este es el punto más importante de todo vuestro informe porque en algunos casos (por desgracia) es lo único que va a ser leído. Esto obliga a que el resumen ejecutivo sea posiblemente la parte del documento que tengáis que cuidar con más cariño.

Un buen resumen ejecutivo NUNCA tendría que ocupar más de una carilla de un A4 a letra normal (el mismo nombre lo dice, es un resumen para los jefes), y tendría que ser leído en menos de dos minutos.

Así mismo, un resumen ejecutivo tendría que tener un lenguaje extremadamente claro, huyendo siempre de terminología técnica (recuerda la audiencia, probablemente no serán técnicos). Aunque parezca algo drástico, yo siempre propongo la técnica del “niño de 6 años”: si vuestro informe no puede ser entendido sin problemas por un niño de 6 años, es que no es lo suficientemente claro.

¿Qué tendría que contener un buen resumen ejecutivo? Grosso modo, estos tres elementos:

Problema objeto del informe.
Solución propuesta.
Acciones tomadas (o que deben tomarse) para alcanzar esa solución.

Y nada más. El resumen ejecutivo debería de ser un ejercicio de minimalismo brutalista: si en lugar de una carilla podéis emplear media, mejor.

Consejo 7: Una carilla (o menos) en lenguaje claro identificando problema y soluciones tomadas constituyen un excelente resumen ejecutivo.

Los anexos son el trastero de tu informe

Uno de los errores más comunes cuando se realizan informes es la saturación de información. Nos hemos pegado una currada con el análisis del problema, y queremos que se note: listados de evidencias, capturas de pantalla, salidas de programas por comandos… todo tiene que estar reflejado en el informe para que se vea el trabajo que nos ha costado.

Error. Un listado sin fin de datos “porque sí” lo único que hace es producir fatiga cognitiva al lector, y dificulta en muchos casos la lectura del informe. Cuando tienes 600 páginas de informe, (y hemos visto algunos así), la simple navegación a lo largo del mismo es un infierno.

Estos elementos son muy interesantes a la hora de redactar un informe, ya que ayudan a defender nuestros análisis y conclusiones. Sin embargo, antes de incluirlos debes preguntarte: ¿son realmente necesarios? ¿Puedo usar un recorte del mismo?

La técnica del recorte (en la que se muestra únicamente parte de la evidencia recogida) es muy útil ya que nos permite centrarnos en lo importante. Por ejemplo, en una salida de una herramienta de port scanning de 5 páginas nos quedamos únicamente con las 4 líneas en las que aparece el puerto del servicio vulnerable.

El resto de la información tiene que estar incluida dentro del documento, principalmente por temas de verificabilidad del trabajo realizado, pero puede perfectamente ir como un anexo. De esta forma cualquiera que esté interesado puede ver la salida en bruto del comando, el subinforme completo de la herramienta X, etc… sin comprometer la legibilidad del texto.

Consejo 8: Todo lo que no sea realmente importante debe ir en los anexos del informe.

Haz de tu informe una plantilla

Antes de hacer un tipo de informe predeterminado, pregunta a quien tengas cerca si hay ya una plantilla hecha (es posible que ya exista, lo que te puede ahorrar mucho trabajo). En caso contrario, construye tu estructura, déjalo bonito… y convierte tu informe en una plantilla.

El motivo es claro: tal y como los programadores reusan código y los administradores de tareas automatizan tareas con scripts, tú también puedes reusar documentos. Un esfuerzo extra a la hora de hacer el primer documento tipo de un aspecto de tu trabajo para dejarlo perfecto hará que el resto de documentos sea “coger y rellenar plantilla”.

Consejo 9: Todo lo que no sea realmente importante debe ir en los anexos del informe.

Huye de los múltiples niveles anidados.

Hemos visto cosas que vosotros no creeríais. Atacar sangrías de texto en llamas más allá de Orion. Hemos visto estilos de texto infames brillar en la oscuridad, cerca de la puerta de Tannhäuser. Todos esos momentos se perderán en el tiempo como niveles 1.3.1.2.2.1.1 en tu informe técnico.

Bladerunner aparte, el consejo está claro: un informe que llega al 1.3.1.2.2.1.1 no es un informe, es tortura no tipificada por los DD.HH. Una estructura bizantina de subniveles, lo único que va a conseguir es confundir al lector y hacer que se pierda mientras intenta comprender tu documento.

En la mayoría de los casos la “regla del tres” funciona perfectamente: no más de 3 niveles de anidado en los títulos, ya que es un compromiso adecuado entre funcionalidad y legibilidad.

Consejo 10: Limita a 3 los subniveles de tu informe para no perder a tu audiencia.

[Advanced] – Convierte tu informe en un recortable

Si tu informe va a ser leído por personas con responsabilidades distintas (por ejemplo: sistemas, redes y seguridad) el estructurar tu informe para que sea fácilmente “recortable” puede facilitar muchísimo la vida a quien tenga que gestionar tu informe ya que puede darle a cada cual únicamente la parte del documento que le corresponde.

Por ejemplo, en una auditoria de seguridad en la que se auditan sistemas propios, sistemas alojados en un ISP y un combo de cortafuegos/WAF/IDS, puedes estructurar el informe de forma que sean tres “mini informes” y que simplemente cortando las páginas cada parte puede tener la información que necesita.

A veces es complicado, pero si lo consigues serás adorado por ello.

Consejo 11: Haz que tu informe sea fácilmente divisible.

La entrada Cómo escribir informes técnicos y no morir en el intento (II) aparece primero en Security Art Work.

El pasado 7 de febrero se celebró en Madrid un encuentro en el Observatorio Vodafone de la Empresa en el que expertos en cloud, inteligencia artificial, robótica y transformación digital dieron una visión sobre cómo afrontar los retos de la industria 4.0. Ya en anteriores artículos de Joan Balbastre acerca de la industria 4.0, podíamos ver qué caracteriza esta revolución industrial y sus principios de diseño básicos. En estos artículos, se nombran hasta seis diferentes principios y uno de ellos, nos permite centrarnos en este texto: la orientación al servicio. Esta orientación resultó ser el eje fundamental de todo el evento.

Bien es cierto que, ante las fuertes competencias entre empresas de diferentes sectores, la optimización de los productos o servicios prestados se ha convertido en prioridad. Existen muchas maneras de mejorar una empresa o producto. En los últimos años, la recopilación de información ha pasado a ser uno de los pilares fundamentales en los que se basa la revolución de la industria 4.0. Los datos recopilados de los consumidores permiten a las empresas realizar diferentes acciones como el mantenimiento preventivo, aseguramiento de la calidad, gestión de defectos en tiempo real, gestión de operaciones, etc. Un claro ejemplo del cambio que están sufriendo las empresas de la industria es el caso de Quality Espresso, que ha pasado de producir únicamente un producto, diseñando, produciendo y comercializando cafeteras, a la prestación de un servicio añadido gracias a la recopilación de información. Las máquinas de café de Quality Espresso no solo permiten tener conectividad con diferentes dispositivos, sino que también son capaces de recabar información estadística para la empresa, a fin de mejorar los productos o incluso influir en el diseño de nuevos, tal y como se indicó en el evento.

No hace mucho existía el paradigma de las “redes neuronales”, pero no teníamos una cantidad compleja de datos que procesar sobre los productos y servicios, ni tampoco la capacidad de cómputo para todo ello.

La informatización de la industria mediante la velocidad de los cambios tecnológicos ha influido en tener menos barreras para la comunicación y procesamiento de la información.

Ilustración 1: Asistente virtual recién llegado a España con altavoces inteligentes Echo

El desarrollo de arquitecturas neuronales que permiten gestionar esta información hace que el mundo se vea como un conjunto de datos y, como es normal en muchos de nosotros, la seguridad de esta información produce inquietudes y desconfianzas.

Como podemos ver hoy en día, cada vez los anuncios de las empresas parecen acertar sobre consumidor a un nivel ya casi individualizado. El “nos escuchan” es una de las ideas más popularmente conocidas cuando hablamos de los dispositivos IoT, tal y como hemos podido ver en recientes campañas publicitarias.

El hecho, en realidad, es que para mejorar cualquier producto o servicio es necesario tener un buen feedback por parte del cliente. De este modo, al llevar a cabo el tratamiento de los datos, se pueden extraer patrones de consumo o preferencias tales como: natural vs sintético, alquilar vs poseer, trato personalizado vs genérico o calidad vs cantidad. Características relevantes que pueden orientar a una empresa en el desarrollo de un producto e inclusive en la producción de nuevos y, ¿quién mejor que nosotros, como consumidores, para crear la línea de tendencia del desarrollo del producto o servicio?

Pero, llegados a este punto, podemos introducir el concepto de ética de acceso a datos extrapolado del evento. Datos que son recabados con un fin único, transparente y legítimo, lo más anonimizado posible para la mejora de un servicio o producto.

Aceptamos las secciones de uso y tratamiento de datos personales cuando adquirimos un producto o servicio y, generalmente, tendemos a asumirlos sin siquiera darle la relevancia que merece, quizás motivado por la extensa lectura que hay que realizar.

Ilustración 2: Mind the Cyber Things – Adam Harvey

Ante el aumento del volumen de información se presume que, en el desarrollo de los algoritmos de procesamiento de estos datos, se hace uso de la ética de acceso a datos. No obstante, a poco que nos pongamos a indagar en esta cuestión, podemos encontrar varios casos en los que, presuntamente, se hace un uso incorrecto de la toma y uso de estos datos para otros fines no específicos del producto o servicio, o incluso para terceros, como es el reciente y llamativo caso de venta de información a terceros por parte de Facebook.

Como usuarios deberíamos ser más conscientes de los riesgos que asumimos al aceptar el tratamiento de nuestros datos y no consentirlos por defecto.
Aparentemente la dinámica es sencilla, las empresas obtienen información para mejorar sus productos y nosotros, como consumidores, obtenemos en compensación mejores productos y/o servicios. Pero, llegados a este punto surgen varias cuestiones. ¿Qué datos estamos aportando? ¿Hasta qué punto no intervienen terceros en nuestros datos? ¿Les ayudamos solo a mejorar un producto o servicio que consumimos? ¿O posiblemente saquen algo más de beneficio?

Quizás ya hemos dejado de contar como personas, para pasar a ser sólo números.

Otras referencias

Acerca de la conectividad de otras máquinas de café

La entrada IoT en la industria 4.0 – Nuestros datos ¿colaboración o aprovechamiento? aparece primero en Security Art Work.

Hace ya tiempo hablamos en este blog del uso de Netflow para analizar nuestra red y la posibilidad de detectar patrones de tráficos sospechosos.

Dado que para analizar tráfico, una de las formas habituales es disponer de un port mirror configurado en la electrónica de red enviando el tráfico interesante hacia nuestro NIDS, y no siempre existe la posibilidad de recibir tráfico Netflow directamente de los dispositivos, si no necesitamos el payload de la comunicaciones, por ejemplo para sacar información estadística o buscar anomalías, podemos usar herramientas para enviar el tráfico recibido como flujo Netflow y proceder a analizarlos. Para este post, usaremos Softflowd para realizar dicho envío.

[Disclaimer: existen otras herramientas, seguramente más actualizadas o con mayores funcionalidades, pero he decidido usar esta por sencillez.]

Una vez instalada la herramienta a través de nuestro gestor de paquetes favorito, indicamos en el fichero /etc/default/softflowd la interfaz a través de la cual voy a recibir el tráfico y el destino donde enviamos el flujo Netflow:

INTERFACES = "eth1"
OPTIONS = "-n 10.10.10.1:9995"

Y arrancamos el servicio:

root@debian:# /etc/init.d/softflowd start

En nuestro caso, para depurar el correcto funcionamiento, lo arrancamos directamente desde la consola, lo que nos permite ver el tráfico que recibe y que convierte en flujos:

softflowd -i eth1 -n 10.10.10.1:9995 -D

softflowd v0.9.9 starting data collection
Exporting flows to [10.10.10.1]:9995
ADD FLOW seq:1 [10.10.10.1]:41302 <> [10.10.10.10]:22 proto:6
ADD FLOW seq:2 [10.10.10.216]:60272 <> [239.255.255.250]:1900 proto:17
ADD FLOW seq:3 [10.10.10.116]:50295 <> [239.255.255.250]:1900 proto:17
ADD FLOW seq:4 [10.10.10.216]:5353 <> [224.0.0.251]:5353 proto:17

Con la opción statistics podemos obtener información más detallada del tipo de tráfico recibido:

root@debian:# softflowctl statistics
softflowd[10123]: Accumulated statistics since 2019-02-20T08:58:43 UTC:
Number of active flows: 565
Packets processed: 227026
Fragments: 0
Ignored packets: 192535 (192535 non-IP, 0 too short)
Flows expired: 23668 (2336 forced)
Flows exported: 23668 in 3884 packets (0 failures)
Packets received by libpcap: 419562
Packets dropped by libpcap: 0
Packets dropped by interface: 4294967290

Expired flow statistics:  minimum       average       maximum
Flow bytes:                  46         26208     593533285
Flow packets:                 1             8         78647
Duration:                  0.00s        37.93s      7483.87s

Expired flow reasons:
tcp =        49   tcp.rst =         0   tcp.fin =        12
udp =     15458      icmp =      5813   general =         0
maxlife =         0
over 2 GiB =         0
maxflows =      2336
flushed =         0

Per-protocol statistics:     Octets      Packets   Avg Life    Max Life
Unknown (6):      606248816       111105      31.12s     234.52s
Unknown (17):       12177738        62378      34.40s    7483.87s
Unknown (58):        1875904        25985      45.24s    3615.52s

El siguiente paso es usar nfcapd para recolectar los flujos enviados por softflowd y almacenarlos. A partir de aquí, es indiferente quien envía el tráfico, si un dispositivo de red o un software que convierte el formato.
El servicio de nfcapd tiene que estar escuchando en el mismo puerto por el que softflowd envía el tráfico; como siempre, para depurar, lo lanzamos desde la consola, indicando donde almacena los flujos de tráfico recibidos:

root@debian:# nfcapd -w -l /var/cache/nfdump -P /var/run/nfcapd.pid
Add extension: 2 byte input/output interface index
Add extension: 4 byte input/output interface index
Add extension: 2 byte src/dst AS number
Add extension: 4 byte src/dst AS number
Bound to IPv4 host/IP: 10.10.10.1, Port: 9995
Startup.
Init IPFIX: Max number of IPFIX tags: 62
Process_v9: [0] Add template 1024
Process_v9: [0] Add template 2048

Por lo que en el directorio de logs, podemos ya ver los flujos almacenados:

root@debian:# ls -l /var/cache/nfdump

-rw-r--r-- 1 root root   29172 feb 20 12:25 nfcapd.201902201220
-rw-r--r-- 1 root root   29652 feb 20 12:30 nfcapd.201902201225
-rw-r--r-- 1 root root   32788 feb 20 12:35 nfcapd.201902201230
-rw-r--r-- 1 root root     276 feb 20 12:40 nfcapd.current.10126

Llegados a este punto, solo quedaría analizar la información obtenida, lo cual podemos hacer por ejemplo con nfdump:

root@debian:# nfdump -R /var/cache/nfdump/

Date first seen          Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
2019-02-20 12:21:45.404   147.307 UDP       10.10.3.120:5353  ->      224.0.0.251:5353         2      123     1
2019-02-20 12:24:16.637     0.000 UDP        10.10.10.61:52421 ->      224.0.0.252:5355         1       58     1
2019-02-20 12:24:34.959     0.000 UDP       172.17.1.127:60537 ->     10.10.3.255:8082         1      168     1
2019-02-20 12:24:38.673     0.000 UDP       10.10.3.120:43697 ->  255.255.255.255:138          1      229     1
2019-02-20 12:14:13.350   633.080 UDP        172.17.2.42:138   ->     10.10.3.255:138         26     5786     1
2019-02-20 12:24:41.153     6.936 UDP        10.10.3.86:60544 ->  239.255.255.250:3702         7     4788     1
2019-02-20 12:24:51.319     6.945 UDP        10.10.3.86:60545 ->  239.255.255.250:3702         7     4788     1
2019-02-20 12:29:42.885    16.754 TCP        10.10.10.87:41302 ->      172.17.2.10:22          53     3168     1
2019-02-20 12:29:42.885    16.754 TCP        172.17.2.10:22    ->      10.10.10.87:41302       44     6248     1
2019-02-20 12:25:04.026     3.002 UDP       10.10.3.238:5353  ->      224.0.0.251:5353         6      408     1
2019-02-20 12:26:37.072     0.000 UDP        10.10.10.90:57245 ->  239.255.255.253:11427        1      180     1
2019-02-20 12:31:23.854    23.862 TCP        10.10.10.87:41302 ->      172.17.2.10:22          80     5536     1
2019-02-20 12:31:23.854    23.862 TCP        172.17.2.10:22    ->      10.10.10.87:41302       44     5728     1
2019-02-20 12:26:57.947     6.457 UDP        10.10.3.86:60272 ->  239.255.255.250:3702         7     4564     1
2019-02-20 12:27:21.888     6.954 UDP        10.10.3.86:51347 ->  239.255.255.250:3702         7     4788     1
2019-02-20 12:27:29.587     0.000 UDP       10.10.10.237:5353  ->      224.0.0.251:5353         1      175     1
2019-02-20 12:27:38.772     0.000 UDP       10.10.3.154:53600 ->     10.10.3.255:19375        1       69     1
2019-02-20 12:27:32.006     7.010 UDP        10.10.3.86:58520 ->  239.255.255.250:3702         7     4788     1
2019-02-20 12:28:00.521     0.000 UDP         10.10.3.4:38140 ->  255.255.255.255:138          1      229     1
2019-02-20 12:28:00.633     0.000 UDP       10.10.3.105:54205 ->     10.10.3.255:137          1       78     1

Dado que toda la información en bruto puede ser tediosa de analizar, podemos jugar con las opciones de filtrado y visualización que nos proporciona nfdump, y por ejemplo, buscar solo flujos de tráfico SSH.

root@debian:# nfdump -R /var/cache/nfdump/ 'port 22'

2019-02-20 12:29:42.885    16.754 TCP        172.17.2.10:22    ->      10.10.10.87:41302       44     6248     1
2019-02-20 12:29:42.885    16.754 TCP        10.10.10.87:41302 ->      172.17.2.10:22          53     3168     1

Adicionalmente, podemos formatear la salida para que sirva de entrada a un sistema de representación gráfica y ver, de forma más cómoda, los flujos de tráfico capturados; como he dicho antes, existen otras herramientas para representar conexiones de red.

Una vez realizado todo este proceso, es trabajo del analista buscar patrones de tráfico sospechosos, siempre teniendo presente que no tenemos el payload, como pueden ser conexiones de administración sin cifrar, flujos de tráfico DNS que un número elevado de bytes, incrementos del volumen de conexiones de un puerto o una IP, etc.

La entrada Analizando nuestra red (IV) aparece primero en Security Art Work.

El error humano sigue estando presente de forma alarmante en los incidentes de ciberseguridad (IBM X-Force Threat Intelligence Index). Varía el entorno, evolucionan las amenazas y el usuario sigue siendo un vector de ataque… y ni siquiera sabe que lo es, o cuáles son esos ataques.

A la pregunta de qué es un phishing, todavía encontramos demasiada gente que no sabe responder o lo hace de manera incorrecta (2018 User Risk Report). Hemos podido constatar personalmente este hecho durante múltiples sesiones a personas de distintos sectores laborales y en una gran variedad de lugares colaborando con el CSIRT-CV, formulando a la gente la misma pregunta. Por no hablar de conceptos como spear-phishing, phishing as a service o whaling; no se han escuchado nunca y se consideran algo lejano (cosas de informáticos). Pero son ataques reales que pueden comprometer la integridad de cualquier empresa por causa del usuario. ¿Cómo va a estar correctamente securizado un sistema con semejante brecha?

La consabida afirmación de que el factor humano es el eslabón más débil de la cadena, podría reformularse; no es el más débil, es el elemento menos adaptado, adaptado a la evolución constante de amenazas existente en la actualidad. Desde Charles Darwin sabemos que no sobrevive necesariamente el individuo más fuerte, sino el mejor adaptado. Si el factor humano no lo está, es entonces cuando se torna un vector de ataque fácil y llamativo.

Los biólogos ilustran algo similar mediante la hipótesis de la Reina Roja. Dicha hipótesis describe la adaptación continua necesaria de las especies. «Para un sistema evolutivo, la mejora continua es necesaria para solo mantener su ajuste a los sistemas con los que está coevolucionando». Y eso es solo para conservar su estado actual. El nombre de la hipótesis está inspirado en la obra de Lewis Carrol, Alicia a través del espejo. En aquella ficción se mostraba un país en el que era preciso correr todo el tiempo para permanecer en el mismo lugar.

Si observamos que el error humano está tan presente en los incidentes, y que su desconocimiento de los mismos es tan significativo, no podemos esperar que evolucionen; ni siquiera saben que forman parte del sistema de seguridad. Es decir, muchas organizaciones están por debajo del mínimo necesario tan solo para mantener su estatus actual de seguridad, muy lejos de poder evolucionar junto con las amenazas.

Pero no podemos achacárselo al usuario, al empleado. No podemos culparle; el usuario tiene en mente realizar la función que se le encomendó en la compañía. Una tarea determinada en la empresa o el uso de una aplicación cualquiera cuando navega como particular en su casa (donde también puede ser víctima de un ataque que afecte a la seguridad de la organización). En definitiva, cree que la seguridad no le compete a él. Esta idea compromete su propia seguridad, la de su familia y la de su compañía. Y es la organización la que goza –o debería– de¬¬ una perspectiva general de su propia situación para gestionar las posibles brechas de seguridad.

La única solución –no la mejor, la única– es implementar planes de concienciación y formación continuos que mantengan al usuario perfectamente adaptado al manejo seguro de los sistemas que le correspondan. Que sea totalmente inútil dirigir un ataque contra él porque esté preparado para detectarlo, impedirlo o responder al mismo.

Muchos profesionales de la concienciación informan de que no gozan del respaldo necesario por parte de sus superiores para llevar a cabo y mantener sus programas de concienciación, como podemos apreciar en el SANS Institute security awareness report. Sin embargo, entre los profesionales que han conseguido ese respaldo, un porcentaje significativo afirma que su trabajo tiene un impacto positivo en la seguridad de su organización, como muestra el mismo informe.

Es decir, el usuario no es consciente de que tiene que adaptarse y sus superiores no muestran la diligencia debida para transmitírselo. ¿Cómo se puede así pretender conservar la seguridad de la organización?

Pero cuidado, la hipótesis señala que «…la mejora continua es necesaria para solo mantener su ajuste a los sistemas con los que está coevolucionando». Incluso aunque estuviera perfectamente concienciado, no bastaría, debe evolucionar constantemente como evolucionan las amenazas; el plan de concienciación debe ser continuo o el usuario volvería a estar inadaptado. Por supuesto el propio plan debe también evolucionar para lograr una madurez en la cultura de seguridad de la organización, que no se limite al mero cumplimiento de la normativa por parte de los empleados, sino que logre en ellos la motivación necesaria, la actitud activa que permita la detección y reporte de los incidentes que perciba. Y de los nuevos incidentes que sigan surgiendo. La compañía más fuerte, si no está adaptada, no sobrevivirá. Caerá, en este caso, por su parte menos adaptada, los usuarios.

¿Pero es verdaderamente necesaria esa adaptación tan continuada del factor humano con respecto a los ciberataques? El Informe de Amenazas y Tendencias del CCN-CERT afirma que las campañas de phishing aumentan tanto en volumen como en sofisticación. Según dicho informe, «este método constituye el vector de infección más exitoso, tanto en ataques dirigidos (ciberespionaje) como innominados (ransomware)». En la actualidad, los ataques buscan objetivos concretos, convirtiéndose así en ataques más específicos.

¿Y qué ocurriría si, además de ser un vector más de ataque –con amenazas cada vez más sofisticadas–, paulatinamente fuera convirtiéndose en el único? ¿No haría más acuciante si cabe la necesidad de la adaptación continua del usuario, de un buen plan de concienciación?

El citado Informe de Amenazas y Tendencias del CCN-CERT afirma que: «La disminución del número de vulnerabilidades atacables provocará un descenso en el uso de exploits-kits (aunque seguirán siendo utilizados en aquellas regiones geográficas donde no puedan ser monitoreados por los investigadores). Por ello, se dará paso a “kits humanos” donde los agentes de las amenazas cambiarán su modelo comercial para lograr sus objetivos atacando las debilidades humanas».

Por todo ello, consideramos que la situación actual de concienciación del usuario está lejos de alcanzar el mínimo aconsejable –que pasa por la adaptación continua– puesto que ni siquiera sabe que forma parte del ecosistema de la seguridad (que es a un tiempo el propio ecosistema empresarial), mientras que las amenazas que pretenden explotar la vulnerabilidad que ello supone aumentan en número y sofisticación, y la tendencia será aún mayor por la disminución de otros vectores de ataque. Ahí radica el valor –y la urgencia– de una buena implementación de programas de concienciación en ciberseguridad para cualquier organización. Que el usuario deje de ser una vulnerabilidad, porque lo es, y cada vez lo será en mayor medida.

Atendamos, pues, a la Reina Roja y aprendamos su lección:

Alicia miró alrededor suyo con gran sorpresa.
—Pero ¿cómo? ¡Si parece que hemos estado bajo este árbol todo el tiempo! ¡Todo está igual que antes!
—¡Pues claro que sí! —convino la Reina—. Y, ¿cómo si no?
—Bueno, lo que es en mi país —aclaró Alicia, jadeando aún bastante— cuando se corre tan rápido como lo hemos estado haciendo y durante algún tiempo, se suele llegar a alguna otra parte…
—¡Un país bastante lento! —replicó la Reina—. Lo que es aquí, como ves, hace falta correr todo cuanto una pueda para permanecer en el mismo sitio. Si se quiere llegar a otra parte hay que correr por lo menos dos veces más rápido.

La entrada Reina roja aparece primero en Security Art Work.

Cómo escribir informes técnicos y no morir en el intento [1] [2] [3]

Consejos de redacción

El corrector ortográfico no cuesta dinero

Tenemos que reconocer que da un poco de vergüenza tener que poner este consejo, pero la cruda realidad obliga: pasar el corrector ortográfico es OBLIGATORIO en todo documento sobre el que tengáis la mínima autoría.

Hay pocas cosas que destruyan más rápidamente un informe que ver un “vamos haber las fases” o un “llendo a las conclusiones”. Pasar un corrector ortográfico cuesta muy poco y te puede salvar de fallos épicos.

Uno de los problemas cuando escribimos informes técnicos reside en que el procesador de texto no reconoce nuestra terminología (ni tampoco los términos en inglés). Un consejo muy interesante es el de ir añadiendo poco a poco estas palabras al diccionario personal de vuestro usuario, de modo que no se vuelvan a mostrar en siguientes ocasiones. De esta forma, cualquier falta de ortografía saltará a la vista y será más fácil de corregir.

Consejo 12: Guarda 10 minutos para pasar el corrector ortográfico. Hazlo SIEMPRE.

Cuidado con las frases largas

Otro de los problemas principales que solemos encontrar en la lectura de informes técnicos es la longitud de las frases. Hemos encontrado en más de una ocasión frases de 8 líneas cuya digestión era peor que la de un cachopo de kilo y medio.

Veamos un ejemplo ficticio (pero muy parecido a la realidad):

Los atacantes emplearon un ataque de spear-phishing contra varios altos cargos de la Organización con un documento malicioso que cuando se abría solicitaba la activación de macros y al aceptarse lanzaba un Powershell que contactaba con el C2 y se descarga la siguiente fase del malware que intentaba robar credenciales, se instalaba como servicio e intentaba escalar privilegios con la vulnerabilidad CVE-2019-001.

La solución mágica en muchos casos es el uso indiscriminado de comas. Una “mejora” del ejemplo anterior:

Los atacantes emplearon un ataque de spear-phishing contra varios altos cargos de la Organización, con un documento malicioso que cuando se abría solicitaba la activación de macros, y al aceptarse lanzaba un Powershell, que contactaba con el C2 y se descarga la siguiente fase del malware, que intentaba robar credenciales, se instalaba como servicio e intentaba escalar privilegios, con la vulnerabilidad CVE-2019-001.

Cada vez que tenemos que corregir alguno de estos, el consejo es el mismo: coge aliento e intenta decir esta frase de un tirón. En cuanto se dan cuenta de que en muchos casos es imposible, se vuelven conscientes del exceso cometido. Mano de santo, oiga.

La solución es muy simple: cualquier frase que no puedas decir sin respirar tiene que ser dividida en dos o más frases (en realidad, tendrías que tener una buena excusa para una frase de más de tres líneas). Veamos el ejemplo inicial dignamente redactado:

Una frase de 5 líneas ha sido dividida en 3 frases más cortas, incrementando su legibilidad. Con un poco de práctica esta técnica se pone en marcha sola y hará que vuestros informes sean mucho más fáciles de leer y entender.

Consejo 13: Escribe lo que puedas decir sin respirar. Parte en dos las frases largas.

No escatimes con los párrafos

Junto con los dos anteriores, el problema de los párrafos conforma la “Santísima Trinidad” de los principales problemas sobre cómo redactar informes técnicos. Imaginemos un poco más de texto del ejemplo anterior.

Los atacantes emplearon un ataque de spear-phishing contra varios altos cargos de la Organización. El correo contenía un documento malicioso que cuando se abría solicitaba la activación de macros y al aceptarse lanzaba un Powershell que contactaba con el C2. En ese momento se descarga la siguiente fase del malware que intentaba robar credenciales, se instalaba como servicio e intentaba escalar privilegios con la vulnerabilidad CVE-2019-001. A lo largo de dos meses los atacantes lograron infectar 12 equipos de la red de la Organización, logrando acceder al servidor de bases de datos MENGANITA y descargando los contenidos de las tablas X, Y y Z. El ataque fue detectado cuando un administrador de sistemas vio una sesión iniciada por un usuario que en este momento estaba de vacaciones, alertando al equipo de seguridad. Los analistas de seguridad verificaron que se trataba de un incidente de seguridad y recabaron información volátil del servidor, procediendo a su análisis.

Aquí tenéis lo que denominamos cariñosamente un “ladrillito”. Tener tantas líneas en un solo bloque de texto dificulta la legibilidad y hace muy fácil perderse, haciendo la lectura del mismo farragosa (algo que en textos online se hace incluso más gravoso).

La solución es partir cada idea en un párrafo (o incluso una misma idea en varios párrafos). Una guía podría ser no tener párrafos de más de 6-8 líneas. Veamos una versión nueva del ejemplo:

En ese momento se descarga la siguiente fase del malware que intentaba robar credenciales, se instalaba como servicio e intentaba escalar privilegios con la vulnerabilidad CVE-2019-001.

A lo largo de dos meses los atacantes lograron infectar 12 equipos de la red de la Organización, logrando acceder al servidor de bases de datos MENGANITA y descargando los contenidos de las tablas X, Y y Z.

El ataque fue detectado cuando un administrador de sistemas vio una sesión iniciada por un usuario que en este momento estaba de vacaciones, alertando al equipo de seguridad. Los analistas de seguridad verificaron que se trataba de un incidente de seguridad y recabaron información volátil del servidor, procediendo a su análisis.

Si os dais cuenta, el texto se ha dividido en cuatro párrafos, cada uno con un concepto (intrusión, acciones de los atacantes y detección), y es claramente de mejor lectura.

Consejo 14: Divide los bloques de texto con párrafos para que no ocupen más de 6-8 líneas.

Elige usar voz pasiva o activa

Este consejo tiene un poco de controversia, ya que existen dos (por así decirlo) corrientes: los defensores de la voz pasiva y los de la voz activa. No quedamos para pegarnos ni estigmatizamos a los contrarios, así que siéntete libre de usar la que te parezca más cómoda.

Para que veas cómo queda vamos a poner tres ejemplos:

Yo revisé los logs del servidor MENGANITA y encontré una serie de accesos inapropiados. Yo realicé un análisis de los accesos y determiné que el primero de ellos se había realizado el 13 de enero a las 15:25h. Yo busqué un listado completo de los accesos y comprobé que se habían realizado 5 accesos entre el 13 y el 15 de enero.

Este primer ejemplo es muy “yo, yo, yo” … lo cual nunca queda bien en un informe. Vamos a volver a redactarlo en tercera persona:

El analista revisó los logs del servidor MENGANITA y encontró una serie de accesos inapropiados. El analista realizó un análisis de los accesos y determinó que el primero de ellos se había realizado el 13 de enero a las 15:25h. El analista buscó un listado completo de los accesos y comprobó que se habían realizado 5 accesos entre el 13 y el 15 de enero.

Un poco mejor, ¿verdad? Vamos a ver ahora si cambiamos a voz pasiva:

Se revisaron los logs del servidor MENGANITA se encontraron una serie de accesos inapropiados. Se realizó un análisis de los accesos y se determinó que el primero de ellos se había realizado el 13 de enero a las 15:25h. Se buscó un listado completo de los accesos y se pudo comprobar que se habían realizado 5 accesos entre el 13 y el 15 de enero.

La tercera opción es la que queda más profesional (todo es cuestión de gustos, ojo), pero la segunda también me parece válida. Lo que sí que es obligatorio es mantener la consistencia: elige la que mejor te parezca, pero mantenla a lo largo del documento.

Consejo 15: Elige el estilo que te parezca mejor, y mantenlo a lo largo del documento.

Usa los tipos de letra con sabiduría

Puedes usar cualquier tipo de letra a la hora de redactar tu informe (excepto Comic Sans, por razones obvias), siempre y cuando tenga una buena legibilidad y ayude a que el texto quede limpio. Eso sí, una vez te decidas por un tipo de letra haz uso del mismo en todo el documento: el tener varios tipos de letra en un mismo texto le dan aspecto de “pastiche”, de copia/pega que hace que quede poco profesional.

En Windows un tipo de letra muy recomendable es Open Sans Light, pero Calibri (la que usa por defecto las versiones nuevas de Office) es bastante limpia. En Linux Liberation Sans/Serif siempre dan buenos resultados, aunque al final es cuestión de gustos :D

Otra cosa a tener en cuenta es que los tipos de letra te pueden ayudar a hacer tu texto más fácil de leer a través de un uso juicioso de las negritas y las cursivas. Una técnica frecuente es emplear las negritas para dar énfasis a palabras clave dentro de un párrafo, y las cursivas para todo lo que sean evidencias.

Ejemplo:

Los atacantes lanzaron un ataque de spear-phishing contra varios altos cargos de la Organización. El correo contenía un documento malicioso que cuando se abría solicitaba la activación de macros y al aceptarse lanzaba un Powershell que contactaba con el C2. En ese momento se descarga la siguiente fase del malware que intentaba robar credenciales, se instalaba como servicio e intentaba escalar privilegios con la vulnerabilidad CVE-2019-001.

A lo largo de dos meses los atacantes lograron infectar 12 equipos de la red de la Organización, logrando acceder al servidor de bases de datos MENGANITA y descargando los contenidos de las tablas X, Y y Z.

Logs de acceso de los atacantes a la base de datos:

Jan 13 15:24 Session started for user pepito1
Jan 13 15:25 Database X dump command started
Jan 13 15:37 Database X dump command finished
Jan 13 15:44 Dump command transferred to computer PC1
Jan 13 15:45 Session closed for user pepito1

El ataque fue detectado cuando un administrador de sistemas observó una sesión iniciada por un usuario que en este momento estaba de vacaciones, alertando al equipo de seguridad. Los analistas de seguridad verificaron que se trataba de un incidente de seguridad y recabaron información volátil del servidor, procediendo a su análisis.

Si os fijáis con cuidado, los ojos parecen fijarse con más detalle en las palabras en negrita, que actúan como “anclas” y hacen de resumen del texto, incrementando la comprensión del mismo. De la misma forma, las cursivas “restan” importancia al texto, haciendo que nos fijemos menos (para así solo hacerlo si estamos interesados).

Consejo 16: Usa un solo tipo de letra. Emplea negritas y cursivas para dar y quitar énfasis.

Usa las sangrías para que tu informe se lea mejor

Las sangrías (de texto, no de vino) son una forma excelente de ayudar a que tu texto se lea mejor, ya que permiten crear pequeñas estructuras de texto. Ya sea mediante el apoyo de listas (que siempre suelen tener una pequeña sangría por defecto), o creando tu propia sangría puedes diferenciar distintos tipos de texto para “romper la monotonía” y mejorar la atención de los lectores.

Si te has ido fijando en el documento, estamos usando la sangría junto con la cursiva con los ejemplos. De esta forma se diferencia claramente un texto de otro, y (creemos) que se mejora la legibilidad.

Consejo 17: Usa siempre las sangrías de las listas, y crea las que necesites (sin excesos).

Usa la terminología adecuada

Como ya has hecho un buen trabajo e identificado la audiencia, ya sabes a quién te estás dirigiendo (o deberías). Aun así, el uso de ATL (Acrónimos de Tres Letras, algo que nos encanta a los que trabajamos en TIC) y de terminología muy técnica tiene que ser usado en su justa medida.

Todo se explica mejor con ejemplos:

El atacante usó un XMAS nmap para detectar el puerto de SIP, empleando a continuación un exploit RCE sobre el Asterisk que le permitió desplegar un listener de Cobalt Strike con comunicación a través de un C2 maleable que se inyectó en el svchost.exe.

Si los lectores tienen un perfil de ciberseguridad es posible que capten todo el mensaje, pero lo más probable es que muchos destinatarios finales tengan dificultades para entenderlo correctamente. No decimos que el informe completo tenga que ser entendido por niños de 6 años, pero es tu trabajo trasmitir el mensaje de la forma más clara posible.

Veamos una versión mejorada:

El atacante realizó un port scanning contra el servidor haciendo uso de la herramienta nmap (con la opción avanzada de XMAS), y detectó que el puerto 5060 estaba abierto (señal de que el servidor podía ofrecer servicios de centralita de VoIP a través del protocolo SIP). A continuación, el atacante ejecutó un exploit RCE (ejecución remota de comandos) contra la centralita Asterisk, logrando desplegar una conexión remota con la herramienta de ataque Cobalt Strike.

Dicha herramienta es capaz de establecer comunicación con su C2 (Command & Control) de forma que ésta sea personalizable (intentando por ejemplo hacerse pasar por un servicio como Dropbox o Spotify). Adicionalmente, se ha detectado que el malware se inyectó dentro del proceso de sistema svchost.exe, posiblemente para pasar desapercibido.

En esta versión estamos siendo bastante explicativos para que veas la diferencia entre una y otra. Encuentra un punto intermedio en el que te encuentres cómodo y te asegures de que no tienes que explicar diez veces tu informe a todo el mundo.

Consejo 18: Usa una terminología adecuada a la audiencia. No abuses de los ATL.

Los gráficos cuestan, pero merecen la pena

Hacer gráficas es algo que a pocos gusta. ¡Es trabajo de diseñadores gráficos! ¡Yo soy programador de Python/Go/Rust/C++++, no de Excel! ¡Eso es para consultores! Estas son frases que solemos escuchar cuando le decimos a alguien “esto mejor explícalo con una gráfica”.

Las gráficas tienen su coste (sobre todo para que queden apañadas), pero tienen un poder innegable para transmitir información. Todavía seguimos enamorados de la gráfica de 7 dimensiones del genio de la visualización Hans Rosling, una maravilla de la condensación de la información conjugado con una claridad absoluta.

Como muestra, dos ejemplos del poder de las gráficas:

A la hora de presentar los resultados de una auditoria de seguridad (da igual que sea un análisis de vulnerabilidades o un pentesting), haz un listado de los sistemas y de las vulnerabilidades encontradas clasificadas por gravedad. Presenta esta información en un gráfico X/Y (un eje para los sistemas y otro para las vulnerabilidades) marcando en rojo/amarillo/verde las vulnerabilidades.
Este gráfico permite a cualquiera que lo vea ver el estado de seguridad de sus sistemas de un solo vistazo (cuánto rojo hay, dónde está concentrado, etc…) y funciona de maravilla.
Hace tiempo, en un incidente de seguridad teníamos múltiples accesos sospechosos a varios sistemas. Para ayudarnos a entender a los atacantes hicimos un recuento de las horas a las que se habían conectado (independientemente del sistema afectado), y lo mostramos en una gráfica de barras donde X era la hora de conexión e Y el número de conexiones. Quedó clarísimo que los atacantes se conectaban en un rango horario fijo, lo que fue de gran ayuda a la hora de responder al incidente.

Consejo 19: Las gráficas son poderosas. Úsalas cuando puedas para transmitir tu mensaje.

[Advanced+] Hazte con un libro de estilo

Si ya sabes redactar correctamente un informe, y quieres pasar al siguiente nivel, tienes dos opciones: hazte con un compañero/a de curro talibán ortográfico que te ayude a base de correcciones a mejorar tu forma de escribir (Hola, M.) … o consigue un libro de estilo. Podemos recomendar sin problemas estos dos:

Libro de estilo de la RAE
Libro de estilo de El País

Consejo 20: Hazte con un libro de estilo para mejorar tu técnica de escritura.

La entrada Cómo escribir informes técnicos y no morir en el intento (III) aparece primero en Security Art Work.

Seguro que todos hemos oído hablar en alguna ocasión o, conocemos algún caso en el que un trabajador ha sido monitorizado, se ha accedido a su correo electrónico corporativo o, se ha ejercido cualquier tipo de fiscalización por parte del empresario sobre los dispositivos que éste pone a disposición del empleado mientras exista relación laboral.

Desde el punto de vista del empleado, podríamos pensar que el empresario no puede utilizar medios que atenten contra tu privacidad porque, por el mero hecho de firmar un contrato no pierdes o renuncias a los derechos que te son inherentes. Y, por otro lado, desde el prisma del empresario, éste podría pensar que el trabajador desde el momento en el que comienza a formar parte de la entidad, todo lo que hace es propiedad de la empresa y, por ende, tiene derecho a acceder por cualquier medio a la información que contienen los dispositivos.

Como sería de imaginar, no todo es blanco o negro sino que existen escalas de grises. Aunque si bien es cierto que el empresario podrá ejercer su poder de control en base al interés legítimo y la relación laboral que une al trabajador con éste, no podrá ejecutarlo como él quiera pues siempre tendrá que tener en consideración diferentes principios como son:

Necesidad: el control debe ser oportuno para alcanzar el objetivo marcado.
Limitación y legitimidad: El empresario podrá recabar datos con una finalidad específica y legítima.
Transparencia: El empresario deberá facilitar, con carácter previo a la implantación del control, toda la información al empleado.
Proporcionalidad: El control debe ser proporcional al objetivo perseguido.
Seguridad: El empresario deberá implementar aquellas medidas de seguridad que sean necesarias en aras de proteger los datos a los que se tenga acceso.

A título de ejemplo, podemos hacer mención al informe que elaboró el Grupo de Trabajo del Artículo 29 sobre la vigilancia de las comunicaciones electrónicas en el lugar de trabajo en el que establecía que: “el simple hecho de que una actividad de control o de vigilancia sea considerada útil para el interés del empleador no justifica en sí misma la intrusión en la vida privada del trabajador, y toda medida de vigilancia debe responder a cuatro criterios: transparencia, necesidad, equidad y proporcionalidad”.

Será a raíz de la Sentencia Barbulescu II cuando se establezca que aunque las instrucciones empresariales relativas al respeto a la vida social/privada en el entorno laboral sean restrictivas y, mitiguen la expectativa de privacidad del empleado, dichas instrucciones no podrán reducir a cero la vida privada del interesado (todavía los tribunales españoles no han aplicado esta apreciación, evaluando únicamente si el interesado ha sido informado correctamente o no). Por lo que si pensabais que emitiendo al inicio de la relación laboral unas normas de uso de los sistemas muy restrictivas y destacando prohibiciones genéricas del uso de dispositivos electrónicos se acabarían los problemas… nada más lejos de la realidad.

La pregunta que nos puede surgir adoptando el prisma de empresario podría ser: ¿qué tendría que hacer para no vulnerar la privacidad de los empleados pero, poder controlar el uso que éstos hacen de mis activos? En este post, daremos algunas instrucciones pero debemos tener en cuenta que no se trata de un numerus clausus:

Debemos tener en cuenta que toda relación contractual se basa en la buena fe contractual (Art. 5 ET), por lo que no podemos partir de la base de que el empleado incumplirá su obligación para con el empresario. En aquellos casos en los que la relación laboral se desarrolle fuera de España o, la relación tenga carácter mercantil, el empresario deberá recopilar todas las restricciones, clasificación y usos de la información, monitorización y grado de la misma, vinculación o referencia a todo aquel documento que sea relevante para prestar el servicio, así como cualquier otro aspecto a tener en cuenta para el desempeño del trabajo, en el contrato que firmen las partes para perfeccionar la relación.
Elaboración de una política de uso de los sistemas TIC donde se recoja el uso que los empleados podrán hacer de los dispositivos, herramientas, redes, etc. que la empresa pone a su disposición y, donde se especifiquen las restricciones establecidas por la entidad, así como las acciones que la organización podrá emprender en caso de uso ilegítimo de los activos. Dicha política deberá ser entregada al inicio de la relación contractual para que el empleado sepa con carácter previo qué controles ejercerá la empresa.
Elaboración de una política de clasificación de la información donde se establezcan los distintos tipos de información que se podrán manejar en la empresa y, los usos y restricciones aplicables a cada una de ellas; siendo imprescindible identificar algunos ejemplos a título enunciativo y no limitativo de lo que se concibe por información “confidencial”, etc.
Elaborar una cláusula de recordatorio sobre los usos permitidos, que tendrá que ser aceptada por el usuario siempre que inicie sesión.
Determinar de manera muy pormenorizada los usos permitidos y, las restricciones de los sistemas proporcionados por la entidad. No es conveniente quedarnos a alto nivel en cuanto a detalle se refiere. No obstante, debemos tener presente la doctrina del TEDH (Barbulescu II) donde se indica que la expectativa de privacidad del usuario no se puede reducir a cero.
Implantar controles graduales, optando por aquellas medidas menos invasivas y utilizar las que son más intrusivas únicamente cuando se tienen sospechas fundadas del uso ilegítimo de los sistemas de información, previo aviso al interesado o a los delegados de personal o comité de empresa en el caso de existir.

A modo de conclusión, podríamos decir que antes de proceder con la implantación de un control que pueda vulnerar la privacidad del interesado, se deberá evaluar la causa que genera la necesidad de dicha implantación; es decir; el riesgo que repercute a la empresa el hecho de que un empleado actúe contra los valores de la empresa, filtre información de la misma, acometa cualquier hecho ilícito en el desempeño de sus funciones o, extralimitándose en éstas. Una vez se haya evaluado la necesidad del mismo, se deberá valorar si se trata del medio menos intrusivo llevando a cabo para ello una evaluación técnica del mismo y, posteriormente, antes de su implantación se deberá informar a los interesados o representantes de éstos; es decir; lo que se pretende es que el control sea proporcional al riesgo soportado por la empresa.

La entrada Intimidad del trabajador vs Control empresarial aparece primero en Security Art Work.

Consejos “espirituales”

Segundas y terceras lecturas nunca fueron malas

Cuando se está redactando un informe hay dos situaciones que se presentan con cierta frecuencia: las interrupciones (estás un día entero con un informe, pero te llaman o interrumpen cada 10 minutos) y el “entrar en zona” (te puedes pegar 2-3h escribiendo sin parar y te marcas 40 páginas de un tirón).

Ambas situaciones tienen su peligro: en el primero de los casos es fácil perder el hilo de lo que estabas contando, dando por supuesto cosas u obviando datos importantes. Y en el segundo puedes “engorilarte” sin problemas, yéndote de excursión por los cerros de Úbeda, Mordor y el chino de la esquina, e introduciendo un montón de paja en tu documento.

Releer tu informe una vez terminado es algo muy importante, porque en ese momento estás centrado en leerlo, no en escribirlo. Una segunda lectura te muestra las frases que no tienen del todo sentido, puntos que puedes reescribir para que se entiendan mejor, aspectos del análisis que no han quedado reflejados… vamos, que una segunda lectura SIEMPRE va a hacer que tu informe quede mejor.

Y si el informe es importante, no descartes incluso una tercera lectura para asegurarte de que está niquelado. No recomiendo lecturas adicionales ya que no es eficiente (si hay algo que no está claro lo tendrías que haber encontrado ya, y lo más que vas a hacer es dedicarte a incluir microcambios que no van a tener impacto alguno sobre el documento).

Consejo 21: Haz una relectura obligatoria del documento final.

Haz que tus compañeros lean tu informe

Pregunta amablemente. Pide. Soborna con bollos. Ruega. Chantajea. Haz lo que debas, pero consigue que algún compañero de trabajo lea tu informe. Alguien imparcial te podrá dar una visión neutra de tu informe y señalar posibles lagunas o zonas de mejora (y siempre es mejor que esa falta de ortografía épica la vea tu compañero y no tu jefe).

Sé también un buen compañero, y no te escaquees cuando algún compañero te pida que revises uno de sus informes. Le harás un favor, y puede que saques alguna idea interesante…

Consejo 22: Encuentra a alguien que lea tu informe y te dé feedback.

Lee en voz alta tu informe / Explícaselo a alguien

Los humanos somos seres llenos de curiosidades. Por ejemplo, aprendemos a hablar muchísimo antes que a escribir… y es que la voz es algo muy importante para nosotros.

Una recomendación MUY interesante para mejorar vuestros informes es leerlos en voz alta. Os parecerá una tontería, pero cuando se vocaliza un texto vuestro cerebro sigue otros caminos y siempre aparecen nuevas ideas que ayudan a mejorar el documento.

Si leer en voz alta te da vergüenza o te parece un poco tonto (no lo es), otra cosa que puedes hacer es contarle tu informe a alguien. El efecto que se produce es similar, y además podrás contar con la opinión de esa persona (con la ventaja adicional de que, si es de un perfil similar al de tu audiencia, podrás saber cuán bien se transmite tu mensaje).

Consejo 23: Lee tu informe en voz alta para detectar posibles fallos, o cuéntaselo a alguien.

Deshazte de tus coletillas

Todos tenemos nuestras peculiaridades a la hora de escribir, pequeñas coletillas que nos persiguen cada vez que escribimos un texto. Suelo ver gente enamorada de las comas, de palabras concretas o incluso de formas de empezar un párrafo (el autor sin ir más lejos parece Pac-Man: tiene un problema serio con los puntos suspensivos).

Estas coletillas no tienen por qué ser perjudiciales para tus informes, pero son un pequeño escollo para alcanzar el “zen de la escritura”: localízalas e intenta poco a poco modificarlas para que no sean predominantes en tu escritura (las segundas lecturas y el tener compañeros informados de su existencia son herramientas magníficas para ello).

Consejo 24: Encuentra tus coletillas, y trabaja para deshacerte de ellas.

Practica, practica y practica

Este consejo está patrocinado por el Capitán Obvio por meridianas razones. No te desesperes si tu primer informe no encandila a tus jefes (reality check: probablemente no lo haga y sea una castaña como los nuestros). Al final, escribir informes es una habilidad que se mejora de la misma forma que el reversing, hacer tortillas de patata o el Fortnite: practicando.

Tu segundo informe será mejor que el primero, y tu décimo mejor que el noveno … hasta que llegará un momento en el que sonarán trompetas celestiales, te aparecerá un círculo dorado y un mensaje de “Level Up!: Writing reports skill acquired!”.

Bueno, posiblemente no sea exactamente así, pero captas el mensaje :).

Consejo 25: Practica redactando informes hasta que te salgan como churros.

Conclusiones

Cuando terminamos la carrera todos tenemos unas ganas locas de cacharrear, montar sistemas, romperlos, construir cosas … de todo aquello que tiene que ver con la tecnología y la seguridad. Las canas al final te dan perspectiva y te enseñan que, aunque la tecnología sea lo que te gusta, necesitas más habilidades para ser un buen profesional.

Las tan de moda denominadas “soft skills” puede que no sean de tu gusto como persona enfrascada en la tecnología, pero piensa desde un punto de vista de persona cuya pasión es resolver problemas: estas “soft skills” son una herramienta poderosa para la resolución de problemas.
Podrás pensar que son herramientas para otro tipo de problemas, pero en realidad son el mismo problema… pero visto con otro prisma ¿Tienes problemas con la aprobación de un presupuesto para comprar un servidor donde poner tu base de datos no relacional y hacer Big Data + ciberseguridad? Haz un informe razonado de las ventajas de su compra y adjunta un presupuesto como anexo.

¿Un jefe de otro departamento no quiere aplicar una medida de seguridad? Haz un informe detallando los posibles riesgos que se pueden correr ponderados por impacto, con una gráfica bonita a ser posible (y mándaselo por correo con acuse de recibo y guardando una copia para que luego no pueda echarte la culpa en caso de una desgracia, aunque el kung-fu de oficina da para otra saga de artículos bastante sangrienta).

En conclusión, saber escribir informes como es debido es algo que te va a costar tu tiempo, pero es algo que va a ser fundamental para tu futuro profesional … y bien usada, es una herramienta estupenda para ayudarte a resolver problemas.

[Bonus extra]: Buscando algún curso sobre escritura técnica hemos encontrado este estupendo manual de escritura técnica de José Miró, profesor de Ciencias Matemáticas e Informática de la UIB. Es más, su web de recursos de escritura no tiene desperdicio alguno. ¡Disfrutadla!

La entrada Cómo escribir informes técnicos y no morir en el intento (IV) aparece primero en Security Art Work.

Este post es, si no nos fallan las cuentas, el quinto (ver el primero, segundo, tercero y cuarto) del colaborador David Marugán Rodríguez. Agradecer una vez más su colaboración con Security Art Work con estos artículos tan interesantes. Si quieres saber más sobre David, aquí te dejamos su perfil en twitter. @radiohacking.

En esta ocasión me gustaría dar algunos consejos sobre seguridad operacional u OPSEC durante los viajes. Debo advertir que no soy ningún gurú de nada, y estos pequeños consejos o advertencias son fruto de la experiencia personal, de mi trabajo y de amigos profesionales de la seguridad que me han asesorado en muchas ocasiones cuando he ido a algún destino. Seguro que tú conoces otros y puede que más adecuados a tu situación personal o profesión. Toma por tanto esta pequeña guía con precaución.

Por mi actividad, he tenido que viajar a algunos países donde he observado riesgos que pueden ser fácilmente evitados o reducidos. Otros, por desgracia, son imposibles de evitar, sobre todo si hablamos de amenazas con actores gubernamentales implicados o países donde la vigilancia es total. No hay nada 100% seguro, pero a veces vale la pena gastar un poco de tiempo y dinero en estudiar nuestras amenazas en viaje. Incluso en algunos casos muy especiales, deberías contratar alguna empresa o perfil especializado que valore las medidas o te proporcione un producto de inteligencia real del sitio que vas a visitar y su contexto.

La idea de este pequeño artículo surge de las preguntas que me han hecho sobre las medidas que se pueden tomar en viajes a congresos de seguridad y hacking en otros países, pero estas medidas pueden aplicarse también a cualquier evento o viaje de trabajo; también en tus viajes de ocio, por supuesto. Debemos recordar que el OPSEC siempre es preventivo, si ha fallado no se puede volver a la situación anterior, no hay “back-up” en estos temas. En breve espero poder hacer una charla más detallada con este tipo de medidas. He incluido algunos enlaces útiles donde poder ver ejemplos de los dispositivos que se venden de forma libre y que pueden ayudarnos, pero son meros ejemplos, investiga por ti mismo en Internet y compara antes de comprar cualquiera de ellos.

Algunas de las medidas que se explican aquí podrían ser contraproducentes porque en determinados casos podrían llamar la atención más de la cuenta. Para no caer en una paranoia absurda e innecesaria (no se trata de ir con aspecto de 007 ni con el perfil de Jason Bourne), intenta modelar tus amenazas y adversarios de forma realista. Estos consejos puede que no sean útiles para todas las situaciones y personas, pero espero que por lo menos alguno de ellos os sea de utilidad en vuestros viajes. En la seguridad, al final todo pasa por usar el sentido común y ser muy disciplinado.

Antes de nada, debemos plantearnos algunas preguntas para poder definir a nuestros adversarios, amenazas y riesgos:

¿Qué tengo que sea valioso para otros? ¿Nuestra actividad está perjudicando de alguna forma a otros? ¿Quiénes son? ¿Qué capacidades tienen? ¿Cómo puedo proteger estos activos? ¿Tengo yo capacidad para protegerlos? ¿Necesito ayuda de terceros? ¿Cuánto tengo que gastar? ¿Cómo lo haré? ¿Qué impacto tendría si fallara mi plan de OPSEC?

Posibles ejemplos para modelar las amenazas en base a adversarios:

Delincuentes comunes
Delincuencia organizada / especializada (p.ej. cibercrimen)
Vigilancia masiva
Agencias de inteligencia
Competidores

En ocasiones, para proteger nuestras actividades, debemos hacer justo lo contrario de lo que se pueda imaginar a primera vista. Por ejemplo, usar un dispositivo de cifrado hardware o una pantalla de privacidad puede parecer beneficioso, pero en ciertos países puede hacer saltar las alarmas, llamando la atención de nuestros adversarios. También hablar en argot o en clave puede perjudicarnos más que beneficiarnos en muchas ocasiones.

A continuación algunos tips sobre OPSEC y recomendaciones de seguridad básica en viaje:

No anuncies tu viaje en RR.SS, sobre todo si viajas a zonas con alto riesgo de secuestro. Si quieres mandar unas fotos hazlo cuando estés de vuelta a tu país de origen, por muy bonito que sea el lugar. No ostentes joyas o dinero en ningún caso. Estudia la cultura del país y se siempre respetuoso.
Si puedes, prepara el viaje con antelación: visados, vacunas, cartas de invitación, etc. Piensa en qué países has estado antes y si esto puede ser un problema en tu destino (podría ser adecuado ver la posibilidad de renovar el pasaporte en caso de tener sellos de países que puedan tener problemas con el destino). Es muy importante llevar un seguro especializado. Existen seguros especializados en viajes no convencionales o de aventura. Estudia siempre con detalle los riesgos de seguridad en la web del Ministerio de Exteriores español. Si así está aconsejado por el destino al que viajas, haz el registro de viajeros en la embajada española (o de tu país de origen) o representación diplomática española en el país de destino. Podrán localizarte o informarte en caso de emergencia. Enlace: http://www.exteriores.gob.es/Portal/es/ServiciosAlCiudadano/SiViajasAlExtranjero/Paginas/RecomendacionesDeViaje.aspx Una buena recomendación para casos de accidente o similares, es usar una pulsera especial que contiene todos tus datos médicos y de contacto en caso de emergencia: https://www.ice-key.it/ (Esta pulsera me fue recomendada en Twitter por Xavi Vila, muchas gracias.) Llevar un pequeño botiquín de viaje también puede serte de gran ayuda cuando menos te lo esperes.
Elige bien tus maletas y, si no viajas a sitios donde se exija, evita usar TSA ya que existen copias de las llaves maestras en Internet hace años. Intenta llevar maletas sin dobles fondos o telas donde alguien pueda introducirte algo que te pueda comprometer. También agilizará una posible inspección. Si es posible, evita facturar y llévala siempre contigo. No está de más usar algún sistema de rastreo de tu maleta. Enlace: https://www.amazon.es/identificativa-Inteligente-Maletas-Mochilas-QR4G-com/dp/B07C1SX4W6
Se que esto es difícil pero intenta dejar TODO lo que puedas y no sea imprescindible en casa. Si llevas dispositivos electrónicos, puedes usar unos específicos para el viaje que sean alquilados, o que no lleven ninguna información previa que sea relevante o sensible, o usa un dispositivo seguro en destino. Puedes no llevar ningún PC o dispositivo electrónico y luego usar la nube para realizar alguna presentación. No lleves ninguna documentación o soporte digital que te identifique como activista, como militante político, o cualquier otra información que te pueda comprometer. Obviamente, cualquier información que sea contraria a la ideología, religión o leyes del país de destino pueden suponerte un problema grave en caso de registro.
Si llevas dispositivos, asegúrate que estén cifrados por hardware (discos duros externos con cifrado por hardware) o software (p. ej. VeraCrypt), actualizados, y apagados durante la inspección de control en fronteras. En algunos casos, puede ser interesante llevar particiones ocultas que solo se mostraran al introducir determinada contraseña y en caso contrario mostrar una partición de “cebo” con información creíble pero inocua. Si te conectas a Internet hazlo como mínimo con una VPN. Usa 2FA, unas Yubikeys pueden ser una buena opción. Desactiva todo lo que no utilices: Wifi, Bluetooth, etc.
Enlace: https://www.yubico.com/
Enlace: https://www.veracrypt.fr/en/Downloads.html
En ciertos países te puedes encontrar con un policía corrupto que te pida dinero. En algunos casos, no darlo a la primera de cambio puede ser bueno pero no está demás llevar varios billetes de poco importe por si nos obligan a que les “abramos la cartera”. Enfrentarte con la policía de otro país NUNCA es una buena opción, mantén siempre la educación y la calma.
No lleves “pines”, ropa o pegatinas en los portátiles de viaje (complicado, algunas son tan bonitas, lo sé) que te perfilen como un “hacker”, activista o perteneciente a tal o cual empresa u organización. No des ninguna información sobre tu ideales políticos o religiosos.
Mantén una “conciencia situacional” mínima para detectar amenazas en lugares públicos. Observa qué es lo “normal en el entorno” y permanece atento a los cambios que puedan producirse. Para no caer en una paranoia absurda e innecesaria, ya hemos comentado que no se trata de ir con aspecto de 007, intenta modelar tus amenazas y adversarios de forma realista antes de viajar a lugares complicados.
Permanece atento a quién se sienta a tu lado, por ejemplo, en un tren o avión. He visto y escuchado cosas increíbles sin nada más que girar la cabeza o poner un poco de “oído”. Usa un protector de pantalla para privacidad. Y también cuidado con las conversaciones en voz alta; a algunas personas les encanta “cantar” sus logros personales o profesionales a voz en grito para darse importancia. Para escuchar esto no tienes más que coger un AVE a primera hora de la mañana de un día laboral y verás lo que digo.
Enlace: https://www.amazon.es/3M-PF14-0W-privacidad-ordenador-port%C3%A1til/dp/B002GI6LXO
Comprar una SIM para el viaje puede ser una opción. También usar tarjetas de crédito virtuales con límite prepago. En algunos países la clonación de tarjetas es un riesgo muy importante.
Enlace: https://www.correos.es/ss/Satellite/site/servicio-tarjeta_prepago-todos_servicios_financieros/detalle_de_servicio-sidioma=es_ES
En algunos lugares, los hoteles pueden ser un riesgo, por no hablar de la facilidad de ganzuar algunas cerraduras o clonar las tarjetas. También puede haber personal que trabaje para algún adversario por dinero o porque esté bajo amenaza. Si vas a estar poco tiempo, no es mala idea dejar el cartel de “no molesten” puesto por fuera de la puerta y así no debería de entrar nadie en la habitación. Puedes dejar la tele puesta o música a un volumen moderado para simular presencia. En algunos casos incluso se han puesto cámaras ocultas, como cargadores de móviles, que pueden detectar movimiento y grabar, como contramedida en casos de intrusión en la habitación de hotel. Si has puesto el cartel de “no molesten” anteriormente citado, no debería entrar nadie y, por tanto, la cámara no habría grabado nada.
Enlace: https://www.amazon.es/TinySpy-Escondida-Grabaci%C3%B3n-Movimiento-Compatible/dp/B0752G8767
Si vas a ausentarte durante varias horas de la habitación, haz una foto de la disposición de los objetos y maletas. Puedes usar precintos de seguridad de tipo VOID ocultos para ver si alguien ha abierto algún cajón, puerta de la habitación, maleta, armario o caja fuerte. Un truco fácil y muy barato es marcar con tinta reactiva a luz ultravioleta la posición de ciertos objetos para luego ver si alguien los ha movido para manipularlos o inspeccionarlos, incluso si los han manipulado muy levemente. Enlace: https://www.amazon.es/DazSpirit-boligrafo-Invisible-Adhesivas-Sencillas/dp/B07J37STP5
Si puedes, lleva una batería portátil. Si tuvieras que verte obligado a cargar el móvil en un lugar público, usa algún “condón” USB para evitar la extracción de datos. No cargues NUNCA el móvil por USB en la computadora de alguien que no conozcas.
Enlace: https://www.amazon.com/PortaPow-3rd-Gen-Data-Blocker/dp/B00QRRZ2QM
Siempre aplico una máxima: si NO lo haces en tu país de origen, NO lo hagas fuera. Hay personas que en otros países aprovechan para “soltarse el pelo” o pegarse “fiestas”. Todo lo contrario, no es buena idea terminar borracho (o drogado) en algún antro de un país desconocido. Ten en cuenta que si eres un objetivo de interés, no dudes que harán lo posible para que caigas en alguna treta para robarte información o cualquier otra cosa de interés.
Aplicaciones de citas y demás pueden ser una auténtica amenaza si das más información de la debida antes o durante tu viaje. Piensa fríamente si realmente has “ligado” con esa chica o chico fantástico o en realidad estás en un auténtico “honeypot”…
Si eres un personaje público o conocido en redes sociales, da por hecho que ya te han perfilado en tu país de destino. Precaución con taxis y transporte público. Infórmate de sus condiciones de seguridad, en muchos países es mejor recurrir a los VTC. Identifica siempre al conductor (hacer una foto de la licencia o matrícula y enviarla a tu contacto de seguridad, si se puede hacer de forma discreta, podría ayudarte en caso de problemas). En algunos países los criminales interceptaban las radios para obtener los datos de recogida del pasajero y darle un “paseo” por todos los cajeros automáticos posibles.
Antes de tu vuelta, inspecciona siempre tus pertenencias, la maleta, ropa, bolsillos, dobladillo de pantalones y cualquier cosa que sea susceptible de servir de escondrijo. En algunos sitios el problema no es el robo, sino que te introduzcan algo indeseado en tus pertenencias con cualquier fin. No dejes ningún documento, ticket o papeles con información en las papeleras del hotel o de una sala de congresos (si has hecho una exposición corporativa, borra además la pizarra y recoge cualquier material sobrante, en particular manuales impresos).
Si compras algún souvenir conserva siempre la factura y aplica la misma inspección que en el punto anterior. No factures objetos de varias personas en una misma maleta, en algunos países los perfiladores de los aeropuertos verán a alguien volando muy lejos sin pertenencias y te podrá suponer un interrogatorio largo y pesado. NUNCA lleves objetos de nadie. Si dudas de algún objeto comprado en el país es preferible no traerlo de vuelta.
Parece absurdo avisar de esto una y otra vez, pero… NUNCA aceptes paquetes o llevar dispositivos de nadie, en ninguna circunstancia.
Lleva un móvil antiguo (no smartphone) tipo Nokia o similar, con linterna y cargador. Existen móviles increíblemente pequeños a buen precio. También lleva los contactos de emergencia, familiares y de la embajada de tu país memorizados. También una radio de Onda Corta o como mínimo AM/FM que funcione a pilas o mejor aún con carga solar y manual. Con esto podrás estar mínimamente informado en caso de catástrofes naturales o revueltas en el país de destino. IMPORTANTE: Existen países donde las radios de Onda Corta están totalmente prohibidas por censura gubernamental, infórmate antes de llevarlas. Si quieres llevar un dispositivo tipo SDR, mejor un SDR basado en TDT-USB, que podría ser perfectamente llevado por un turista para ver la televisión y no levantaría tantas suspicacias como un SDR avanzado.
Enlace: https://www.amazon.es/Tivdio-HR-11S-Despertador-Reproductor-Actividades/dp/B074PN36NW
https://www.amazon.es/HILABEE-Digital-Sintonizador-Receptor-RTL2832U/dp/B07LCDFW1B
No es una buena idea intentar burlar la seguridad de según qué países en la frontera para ocultar información que pueda ser comprometedora por motivos ideológicos o por simple privacidad. Si necesitas llevar información que pueda ser sensible, que contiene algo muy personal como copias compulsadas de tu pasaporte, efectivo, una presentación corporativa o similares, existen diferentes objetos con compartimentos “secretos”, como cinturones o incluso monedas de curso legal modificadas (cuidado, además esto podría ser ilegal en algunos países, donde una simple moneda modificada puede ser un delito grave) donde puedes ocultar alguna documentación personal. En el caso de las monedas, tienen cierto nivel de opacidad comprobada contra las máquinas de rayos X y pueden portar por ejemplo una tarjeta MicroSD con una copia de tu documentación personal, libreta de contactos, presentaciones personales o profesionales, claves privadas de cifrado, CV o algo parecido. Repito, que esto NO es aconsejable, porque parecería que estas realizando alguna actividad ilegal o de espionaje, y te puede traer más problemas que beneficios. No asumas riesgos innecesarios, NO hagas saltar las alarmas de forma innecesaria. A veces ocultar algo inocuo puede hacer creer que estás cometiendo un delito grave.
Enlace: http://spy-coins.com/MicroEuro.html
No subestimes las capacidades del adversario, sobre todo si es un actor gubernamental o muy especializado. Si la amenaza es probable, puede que tu habitación tenga algún dispositivo de escucha, como un micrófono oculto. Si es necesario tener alguna conversación confidencial, estudia dónde puede llevarse a cabo. Un truco simple y que puede resultar efectivo, de forma previa al viaje, ocultar el máximo posible el nombre del hotel donde te alojarás, o incluso mencionar otro a propósito. Si quedas con alguien en el que no confías quizás debas cambiar de planes a última hora y proponer otro sitio. En casos de personas VIP o muy concretas, se puede contratar una empresa de TSCM (contramedidas electrónicas) que realice una inspección previa.
Algo muy importante: el OPSEC no actúa de forma reactiva, si no has tomado las medidas antes, poco podrás hacer después. Esto es muy importante saberlo. A algunas personas les pueden parecer medidas paranoicas, pero creedme: creo haber evitado algún problema grave en ciertos países. También es cierto que es necesario ser muy disciplinado y metódico, y muchas veces he incumplido algunas de ellas, o no las he llevado a cabo con la diligencia adecuada.

Sé que faltan muchos consejos de OPSEC en viaje pero, en mi opinión, creo que estos son fundamentales (aunque yo a veces no los he seguido, lo reconozco). En un futuro haré una charla sobre este tema con más detalles técnicos. Sinceramente, deseo que os sirvan para evitar problemas en cualquier tipo de viaje. En mi opinión es importante tomar unas medidas básicas, sobre todo si nos dedicamos a temas tan sensibles como la ciberseguridad.

La entrada OPSEC básico para viajeros aparece primero en Security Art Work.

Cómo escribir informes técnicos y no morir en el intento [1] [2] [3] [4][Bonus]

Los incidentes de seguridad son un caso muy interesante de informe técnico, ya que tienen unas características particulares que debemos tener en cuenta a la hora de plasmarlas en un informe.

Os mostramos a continuación unos consejos (adicionales a los ya vistos en artículos anteriores) para que vuestros informes de incidentes de seguridad salgan “niquelados”.

Conoce tus tipos de informe

Los incidentes de seguridad tienen varias fases, existiendo varios tipos de informe en función de la audiencia y el objeto del mismo. Conocer qué es lo que esperan recibir en su informe es la mitad del éxito.

Tipos de informe:

Informe de detección: Se ha detectado y confirmado un incidente de seguridad. En este informe (dirigido a los responsables técnicos) se cuenta en 2-3 párrafos lo que se sabe hasta el momento del incidente, estimando sistemas afectados e impacto. El objetivo es iniciar la respuesta ante el incidente, primando la rapidez sobre la exactitud.
Informes “de batalla”: Son actualizaciones del informe de detección, resumiendo las acciones tomadas por el equipo de respuesta ante incidentes. A medida que se va avanzando en la respuesta, estos informes tendrían que incrementar su exactitud (vamos sabiendo con más detalle lo sucedido).
Informes de crisis: El objetivo es el mismo que los informes de batalla, pero la audiencia pasa a ser personal no técnico (dirección y/o legal). Prima la claridad del mensaje, y se debe de tener cuidado con lo que se dice (ojito con la exactitud)
Informes de IOC (Indicators of Compromise): Son informes destinados a compartir inteligencias con otros departamentos o entidades. En muchos casos están anonimizados (sin información del origen), y constan de 1-2 párrafos introductorios y de un listado de IOC (Indicadores de Compromiso) para que sean comprobados por los receptores.

Consejo 1: Identifica el tipo de informe que tienes que redactar.

Estructura tu informe

A lo largo de los artículos hemos propuesto una estructura de informes técnicos básica. En el caso de incidentes de seguridad proponemos una ampliación a esta estructura avanzada:

Resumen ejecutivo: Qué ha pasado. Claro y conciso, sin terminología técnica.
Timeline del incidente: Ver apartado propio.
Datos del entorno.
Gestión del incidente: Qué acciones se han tomado para responder al incidente.
Análisis forense: Si se han realizado análisis forenses, resultados de los mismos (puede ir también como anexo en función de su extensión).
Análisis de malware: Si se han realizado análisis de malware, resultados de los mismos (puede ir también como anexo en función de su extensión).
Impacto del incidente: Determinamos (o estimamos) el impacto del incidente (datos perdidos, equipos afectados, daños causados, etc…)
Atribución: Indicamos (en la medida de lo posible, ojo) quién ha podido ser el causante del incidente
Recomendaciones de seguridad: Qué medidas debemos tomar para que este incidente no se vuelva a repetir.
Lecciones aprendidas: Qué se ha hecho bien, qué se ha hecho mal y qué acciones se deben tomar para hacerlo mejor en el próximo incidente.
Anexo 1: IOC (listado por categorías)
Anexo2: Evidencias (todo aquello que por su extensión no tiene cabida en la gestión del incidente).

Consejo 2: Estructura correctamente tu informe (recuerda el uso de plantillas)

Exactitud por encima de todo

La exactitud es clave en la respuesta ante un incidente. Dado que en buena parte de la gestión todo son incógnitas, el tener puntos de referencia verificados es crítico para el éxito de la respuesta.

Cuando se redacta el informe es muy importante recalcar todas las afirmaciones realizadas y reforzarlas con evidencias. Si dices en tu informe “se buscaron en los logs del servidor web conexiones de la IP atacante y se comprobó que la primera conexión se produjo el 7 de enero a las 16:32h”, demuéstralo con un extracto de los logs.

Una táctica muy útil es la de poner en el informe los comandos ejecutados, añadiendo debajo la parte de la salida que nos interesa. Siguiendo con el ejemplo anterior, mostraríamos el log del servidor web y el comando empleado:

Si se añaden los logs en bruto en un soporte físico, estamos ofreciendo al lector del informe la repetibilidad de nuestras acciones (es decir, poder ejecutar el mismo comando sobre los mismos logs y obtener el mismo resultado), lo cual incrementa la credibilidad de vuestro informe.

Consejo 3: Mantén la mayor exactitud posible en tu informe. Intenta dar repetibilidad de tus acciones siempre que puedas.

Cuenta lo que se ha hecho

Redactar el informe de un incidente de seguridad es a veces una tarea peliaguda, porque cabe la posibilidad de que tu informe sea analizado con lupa (o microscopio electrónico), cuestionando todas y cada una de tus decisiones.

El problema es que la respuesta ante incidentes parte de una premisa básica (la detección del incidente), pero luego puede tomar múltiples caminos en función de las acciones tomadas, el momento en el que se llevan a cabo y la persona que las ordena.

Nuestro jefe es garante de una gran sabiduría popular, y comenta a veces cuando hablamos de respuesta ante incidentes que “a cojón visto, macho seguro” (versión castiza de “es fácil hablar a toro pasado”).

Nos ha tocado leer una buena pila de informes de incidentes, y en los primeros siempre existe esa sensación de “con lo fácil que era cómo es que no lo han visto antes” (sobre todo si el informe está bien escrito y lo explica todo con claridad). Luego te toca a ti uno de esos incidentes bien complicados, y te das cuenta de que sobre el terreno las cosas “ya no son tan fáciles”.

Lo que se pretende decir es que no hay que adornar las acciones tomadas ni modificarlas para que quedemos mejor en el incidente. Como hemos dicho antes, un informe tiene que ser exacto, tanto en lo bueno como en lo malo (y para eso están las lecciones aprendidas). Un lector con experiencia sabrá ponerse en vuestra piel y evaluar sin problema si las acciones tomadas han sido o no correctas.

Consejo 4: No adornes las acciones tomadas, cuenta lo hecho tal y como se hizo

Distingue claramente hechos de hipótesis

Uno de los errores más frecuentes en la redacción de informes de incidentes de seguridad suele ser dar por hechas suposiciones de los investigadores, es decir, convertir hipótesis en hechos. En respuesta ante incidentes es crítico el saber distinguir entre ambos.

Los hechos son, como indica la RAE, acciones que mantenemos como sólidas (al menos hasta que otro hecho de mayor peso nos diga lo contrario). Ejemplos de hechos:

En el servidor PEPITO hay 4 cuentas de usuario con privilegios de administrador.
La usuaria MENGANITA inició sesión en el servidor PEPITO el 7 de enero a las 14:32h.
Se encontraron varios ficheros .zip de 1Gb con datos de la Organización en la carpeta /tmp del servidor PEPITO.

Las hipótesis (suposiciones de algo posible o imposible para sacar de ello una consecuencia) son necesarias para la respuesta ante un incidente, ya que en primer lugar prácticamente nunca vamos a tener toda la información necesaria para saber con exactitud lo sucedido. En segundo lugar, las hipótesis son en realidad una herramienta de trabajo del analista, ya que las necesita para realizar su investigación. Pongamos algunos ejemplos de hipótesis:

Los atacantes del servidor PEPITO son norcoreanos.
La usuaria MENGANITA tenía una contraseña débil en su cuenta.
Los atacantes emplearon los privilegios de la usuaria MENGANITA para acceder al servidor PEPITO.
Una conspiración judeo-masónica-gallega-zurda-bebedora-de-Cruzcampo ha usado 4 0-days para robar información de la Organización.

Si os dais cuenta, las cuatro hipótesis son posibles (en tanto que son físicamente realizables), pero la última si la analizamos con detalle sea poco probable. En todo caso, una vez puestas encima de la mesa lo que debemos hacer es evaluar esas hipótesis e intentar contrastarlas con hechos.

Tomemos por ejemplo la tercera hipótesis: “Los atacantes emplearon los privilegios de la usuaria MENGANITA para acceder al servidor PEPITO”. Esta hipótesis puede comprobarse con una cierta facilidad, ya que bastaría con comprobar que:

La usuaria MENGANITA tenía privilegios sobre el servidor PEPITO (preguntando al controlador de dominio o accediendo al servidor).
La usuaria MENGANITA ha iniciado sesión en el servidor PEPITO (buscando en los logs del servidor PEPITO o en los del controlador de dominio).

En un informe de un incidente de seguridad no tiene cabida la opinión. Por mucho que tu instinto diga “han sido los norcoreanos”, si no tienes datos que soporten esa opinión, no deberías ponerla en tu informe.

Consejo 5: Toda hipótesis tiene que estar sustentada con hechos.

Data todas tus acciones y genera una timeline de eventos

La documentación de los tiempos es muy importante en una respuesta ante incidentes. Por poner un ejemplo, a la hora de redactar un informe deberías de tener marcados todos estos tiempos:

Detección de una pieza de malware en el equipo X.
Extracción del dominio de mando y control de un malware.
Solicitud de bloqueo del dominio a seguridad perimetral.
Bloqueo efectivo del dominio.

Estos tiempos son fundamentales a la hora de evaluar una respuesta ante incidentes y comprobar que se ha actuado de forma correcta (por ejemplo, puede ocurrir que se hubiera solicitado el bloqueo un día y que no se hubiera aplicado hasta el siguiente).

Otra ventaja adicional de documentar los tiempos del incidente es que permiten generar una línea temporal de eventos, algo que permite narrar el evento de forma resumida con facilidad. Veamos un ejemplo:

15/Ene 23:45h – Los atacantes envían el correo malicioso a diversos usuarios.
16/Ene 09:32h – La usuaria MENGANITA abre el correo malicioso e infecta su equipo.
16/Ene 09:33h – El malware contacta con el C2 HTTP atacantes.com
16/Ene 10:01h – Los atacantes inician sesión en el servidor PEPITO con las credenciales de MENGANITA.
16/Ene 10:01h – Los atacantes acceden a diversas bases de datos del servidor PEPITO, extrayendo información y guardándola en la carpeta /tmp
17/Ene 12:07h – Los administradores de sistemas reciben una alarma de disco al 90% en el directorio raíz del servidor PEPITO. Al observar los contenidos deciden alertar a ciberseguridad.
17/Ene 12:10h – El personal de ciberseguridad verifica que se trata de un incidente de seguridad.
17/Ene 15:33h – Se analizan los accesos al servidor PEPITO y se comprueba que la usuaria MENGANITA parece ser la originaria. Se solicita un volcado de memoria y unos datos de triage de su equipo.
17/Ene 17:27h – El CAU entrega los datos de triage del equipo.
17/Ene 18:49h – Ciberseguridad detecta la existencia del malware de acceso remoto ZUTANITO en el equipo de MENGANITA, y localiza el C2 HTTP atacantes.com, solicitando a seguridad perimetral su bloqueo urgente.
17/Ene 19:01h – Seguridad perimetral bloquea de forma efectiva el dominio.
17/Ene 19:09h – Ciberseguridad revisa todos los logs del proxy de salida y comprueba que el equipo de MENGANITA es el único que ha contactado con ese dominio de C2.
17/Ene 19:32h – Ciberseguridad localiza el correo malicioso, y avisa al resto de usuarios para que procedan a su eliminación.

En unas líneas, y con ayuda de los tiempos, se explica perfectamente el incidente junto con las medidas tomadas y lo que ha costado cada paso. De esta forma quedan bien claros los esfuerzos realizados y la demostración de la debida diligencia en la gestión del incidente.

Consejo 6: Pon fecha y hora a todas las acciones, y genera una línea temporal de eventos.

Crea un listado de equipos y usuarios afectados

A medida que va avanzando el incidente, ten un listado de usuarios y equipos afectados, y preséntalo como un apartado o un anexo. De esta forma facilitarás la fase de recuperación (cambio de contraseñas, formateo de equipos, etc…) del resto de compañeros de Sistemas/CAU, y ayudarás a calcular el impacto del incidente (¿cómo? ¿qué FULANO está comprometido?).

[Nota extra]: Cuando listes los equipos, usa el nombre del equipo, la dirección IP y (si puedes) la MAC. No será la primera vez que un DHCP o un nombre mal leído formatea el equipo equivocado (y, sobre todo, deja un malware suelto).

Consejo 7: Genera dos listados: uno con los usuarios y otro con los equipos afectados.

La entrada Cómo escribir informes de incidentes de seguridad aparece primero en Security Art Work.

Recientemente, desde Lab52 de S2 Grupo hemos detectado una campaña de infección a través de un documento malicioso que nos ha llamado especialmente la atención debido a su contenido y título.

El documento en cuestión, llamado “Military Financing.xlsm” y con hash “efe51c2453821310c7a34dca3054021d0f6d453b7133c381d75e3140901efd12”, destaca principalmente por su nombre y la imagen que contiene, que hace referencia a un documento con información secreta del departamento de estado de EEUU.

Ilustración 1 Captura de la imagen que contiene del documento

El fichero contiene macros sin ofuscar que se encargan de extraer de multitud de celdas del documento porciones de código hexadecimal, con el cual compone un ejecutable y un script:

Ilustración 2 Código de las macros

Ilustración 3 Caracteres hexadecimales dentro de las celdas del documento

Una vez extraídos ambos ficheros, los almacena en el directorio %ProgramData% con los siguientes nombres y hashes:

Nombre	Hash
AutoHotkeyU32.exe	967dba8d919693febf96fde4877e7f08077630f886d4e77b778855d998c073c2
AutoHotkeyU32.ahk	acb3181d0408c908b2a434fc004bf24fb766d4cf68bf2978bc5653022f9f20be

Del documento nos han llamado también la atención otros dos elementos.

El primero es el idioma ruso y el hecho de que algunos datos de las macros estén escritos en Cirílico:

Por otra parte, otro elemento que nos ha llamado la atención es el hecho de que contiene un nombre de autor del documento:

A partir de ese nombre, se han encontrado otros 4 documentos subidos a la plataforma Virustotal desde Emiratos Árabes hace algo más de una semana casi a la misma hora, y que contienen pruebas de distintas macros y formas de explotar el documento ofimático para instalar malware. Estos cuentan con los mismos metadatos en el documento y mismas cadenas en Ruso dentro de los datos de las Macros, por lo que podría tratarse de pruebas realizadas por el autor, previas a esta campaña de infección.

Una vez extraídos los ficheros que lleva embebidos, lanza el ejecutable pasándole el script como parámetro:

El ejecutable consiste en un cargador de scripts autoHotkey legítimo, y la lógica maliciosa la compone el fichero con extensión “.ahk” encargado de crear un acceso directo en “Startup” que le aporta persistencia en cada reinicio y reportar el Serial del disco “C:” al servidor de mando y control y dependiendo del comando recibido, actualizarse a sí mismo (Comando 000) o crear un fichero de scripting nuevo y ejecutarlo en paralelo (Comando 001).

Esto le permite quedarse a modo de backdoor, permitiendo al atacante cargar cualquier tipo de nueva funcionalidad o actualizar el propio script para, por ejemplo, actualizar el C2.

El dominio de mando y control con el que contacta la amenaza es el siguiente: hxxp://185.70.186.]145/7773/index.php

Ilustración 4 Información de la IP del atacante

La IP se encuentra ubicada en Paises Bajos y pertenece a la empresa “hostkey.ru”, la cual ofrece un servicio de hosting de VPS en Rusia o Paises Bajos:

Ilustración 5 Captura de la Web de hosting del servidor de C2

Por el momento, no hemos podido obtener nuevas etapas de infección de esta amenaza, ni otras versiones de este documento con distintos indicadores, por lo que seguiremos atentos a este tipo de actores utilizando TTPs ligeramente distintas a las utilizadas por actores de cibercrimen más genérico.

Name	IOC
C2	hxxp://185.70.186.145/7773/index.php
AutoHotkeyU32.ahk	acb3181d0408c908b2a434fc004bf24fb766d4cf68bf2978bc5653022f9f20be
AutoHotkeyU32.exe	967dba8d919693febf96fde4877e7f08077630f886d4e77b778855d998c073c2
Military Financing.xlsm	efe51c2453821310c7a34dca3054021d0f6d453b7133c381d75e3140901efd12

La entrada Military Financing Maldoc: análisis aparece primero en Security Art Work.

Hace ya unos cuantos años (2011), nuestro compañero José Luis Villalón nos hablaba de la certificación CISSP, de (ISC)2. Como las cosas han cambiado algo desde entonces, y aprovechando que aprobé recientemente el examen, vamos a echar un vistazo a esta certificación, a los cambios que ha sufrido y (en el siguiente post) a algunos consejos que personalmente me han servido para superar el examen.

Introducción

La certificación CISSP (Certified Information Systems Security Professional) de (ISC)2 es en la actualidad una de las principales certificaciones (básica para mí, aunque eso depende de la experiencia y recorrido profesional de cada persona) en materia de seguridad de la información, aunque tiene una mayor difusión en EEUU que en el resto de países, si echamos un vistazo al número de certificados por país. Mientras que a 31 de diciembre de 2018 EEUU contaba con cerca de 84500 certificados, entre Alemania (2100), Francia (1000), Italia (400) y España (650) sumaban poco más de 3000. Esto es probablemente debido a que muchos departamentos de Recursos Humanos en EEUU lo consideran un prerrequisito básico en el ámbito de la ciberseguridad, además de la significativa mayor aceptación que los certificados de (ISC)2 tienen en el mercado estadounidense.

Contenido

Suele decirse del CISSP que es “a mile width and an inch deep“, lo que quiere decir que abarca una gran cantidad de conceptos de seguridad en múltiples ámbitos, pero no profundiza en ellos. Dicha definición es bastante adecuada; el material en el que está basada la certificación cubre (por ejemplo) desde aspectos de gestión del riesgo hasta metodologías de desarrollo de software, pasando por modelos de seguridad o algoritmos de cifrado, pero siempre desde un punto de vista de alto nivel.

Aún así, para enfrentarse al examen es recomendable estar al tanto de algunos detalles específicos, como las longitudes de clave de los principales algoritmos criptográficos, los niveles de CMMI o qué protocolo de IPSec proporciona capacidades de no repudio. En este sentido, a pesar de esos detalles que sí es necesario memorizar, se trata de una certificación principalmente de comprensión de conceptos.

El material del CISSP está basado en el CBK o Common Body of Knowledge, que podríamos considerarlo como el conjunto de conocimientos básicos que se deben tener para obtener certificación. Este CBK se actualiza de manera periódica, y cubre los siguientes ocho dominios principales (en contraste con los diez que había hasta 2015):

Seguridad y gestión de riesgos (Security and Risk Management).
Seguridad de activos (Asset Security).
Arquitectura de seguridad e ingeniería (Security Engineering and Architecture).
Comunicación y seguridad de red (Communications & Network Security).
Gestión de identidad y acceso (IAM) (Identity & Access Management).
Evaluación de seguridad y pruebas (Security Assessment & Testing).
Operaciones de seguridad (Security Operations).
Seguridad de desarrollo de software (Software Development Security).

Al respecto, hay que tener en cuenta que al tratarse de una certificación muy relacionada con el mercado estadounidense, hay referencias abundantes a documentación del NIST y a detalles específicos del sector militar americano, como los niveles de clasificación.

No obstante, donde más se nota este aspecto es el contenido sobre legislación, en la que aparecen referencias específicas a leyes en materia de ciberseguridad como la Patriot Act o la Computer Fraud and Abuse Act (CFAA). Aunque no se puede descartar que una pregunta sobre estos temas aparezca en el examen (no he encontrado ningún lugar donde (ISC)2 se pronuncie sobre qué papel tiene la legislación americana cuando el examen se realiza, por ejemplo, en España) y es importante conocerlas, tampoco es probablemente necesario conocer en detalle todas las enmiendas que por ejemplo ha sufrido la CFAA durante estos pasados años, aunque esa es únicamente mi opinión.

Prerrequisitos y mantenimiento

Como es habitual en muchas otras certificaciones, para conseguir la certificación no es solo necesario haber pasado el examen, sino también disponer de cierta experiencia acreditable. En este caso, se debe contar con al menos cinco años de experiencia en dos o más de los dominios del CBK, que puede reducirse a cuatro si se cuenta con alguna otra certificación reconocida como CISA o ciertos requerimientos educativos.

Tras superar el examen, el candidato debe ser avalado por una persona que esté en posesión de la certificación, o si no dispone de ningún contacto, solicitar a (ISC)2 que actúe como valedor. Si todo va bien, en la actualidad el tiempo estimado para la obtención del candidato tras proporcionar la experiencia necesaria es de ocho semanas.

Asimismo, también como es habitual, para mantener la certificación se deben acreditar 120 horas de formación profesional continuada (Continuing Professional Education, CPE) en un periodo de tres años. De no hacerlo, es necesario volver a repetir el examen, como por ejemplo sucede con otras certificaciones de ISACA.

Examen

El formato y duración del examen es probablemente el elemento que mayores cambios ha sufrido en estos años recientes, si nos centramos en la versión en inglés (el resto de versiones no parecen haber cambiado). En cualquier caso, dado que toda la documentación disponible se encuentra en inglés, recomiendo fervientemente hacer el examen en ese idioma, para no encontrarse con problemas de nomenclatura, traducciones dudosas, acrónimos traducidos, etc. Además, como indico a continuación, la extensión del examen (en preguntas y duración) en ese caso es significativamente menor.

En tal caso, de un examen de 250 preguntas tipo test y una duración de 6 horas en el pasado, se ha pasado en la actualidad a un examen adaptativo que consta de 100 a 150 preguntas a cumplimentar en un máximo de 3 horas, entre las que se incluyen 25 preguntas pre-test que no son valoradas (pero que, no obstante, son indistinguibles de las preguntas que computan para el resultado).

El hecho de que sea adaptativo implica que:

La dificultad de las preguntas va incrementándose a medida que el candidato contesta correctamente a respuestas anteriores.
No es posible revisar las respuestas dadas a preguntas anteriores.
Con únicamente 100 preguntas contestadas (de las cuales únicamente cuentan 75, aunque no es posible saber cuáles son) el test puede determinar basándose en criterios estadísticos si el candidato ha aprobado o suspendido el examen, por lo que el cansancio deja de ser un factor relevante, como probablemente lo era hasta ahora. En el caso de que con 100 preguntas el test no pueda determinar de manera fiable si se aprueba o se suspende, continúa hasta que pueda determinarlo, se alcancen las 150 preguntas o se agote el tiempo.

En cualquier caso, información detallada sobre este tipo de test puede encontrarse en la página oficial de (ISC)2.

Aunque existen otros aspectos que cualquier candidato debería revisar antes de plantearse sacarse la certificación (precio del examen, calendario de examen, valedor, código ético, etc.), esos son algunos de los principales aspectos a tener en cuenta.

En el próximo post hablaré de mi experiencia personal y daré algunos consejos concretos y recursos útiles, de acuerdo a mi experiencia, para aquellas personas que estén pensando en sacarse este certificado, al que podría aplicarse aquello de que no es tan bravo el león como lo pintan.

La entrada La certificación CISSP – I aparece primero en Security Art Work.

En la entrada de ayer vimos algunos aspectos generales de la certificación CISSP, que se pueden ampliar en la página oficial de (ISC)2. En esta entrada es donde voy a entrar en detalle en los aspectos no formales, como materiales, consejos y opiniones personales. Empecemos.

¿Es difícil el examen?

Su buscamos en Google, las principales comunidades de usuario relacionadas con (ISC)2 se encuentran en reddit y y en los foros de (ISC)2 . En ambos hay múltiples entradas relatando opiniones, experiencia con el examen, solicitando y dando consejos, revisando materiales de estudio y otros temas. Sin embargo, mi impresión es que el tono tiende a ser negativo y algo atemorizador, terrorífico incluso en ocasiones. Muchas personas que han hecho el examen lo describen como muy difícil, redactado de forma intencionadamente compleja (tricky wording) y muy oscuro. A eso se suma que no hay preguntas “ejemplo” en Internet, y que las personas que elaboran el material de formación (incluyendo el libro oficial de preguntas) u ofrecen los cursos de formación (bootcamps) no son nunca las mismas que escriben las preguntas del examen. Por tanto, un elemento crítico al gestionar durante la preparación del examen es la incertidumbre.

Al respecto, teniendo presente que no soy un hablante nativo de inglés, la forma de plantear las cuestiones desde el punto lingüístico me pareció bastante correcta. Preguntas de una o dos frases, sin ninguna complicación especial. No recuerdo un abuso de dobles negaciones o estructuras gramaticales complejas. Tampoco desde un punto de vista global las preguntas son tremendamente difíciles, aunque sí es necesario conocer el material y razonar las respuestas, y evitar saltar directamente a la primera que te suene bien. Lo más habitual es que sea sencillo descartar dos de las respuestas, quedando otras dos que parecen ser válidas. Como indico en la parte de los consejos, en ese caso es imprescindible buscar los conceptos clave de la pregunta y las respuestas, leerlas al menos un par veces lentamente y tener en cuenta que la gestión del riesgo es siempre el primer paso para todo.

Al hablar de dificultad, es sin duda relevante tener en cuenta la experiencia de cada persona, que le permitirá responder de manera más natural o menos a las preguntas. En mi caso, soy CISA y CRISC, tengo tres años de experiencia como administrador de sistemas (desde un punto de vista bastante amplio), otros tres años como técnico de seguridad, en aspectos ya más relacionados con la seguridad: gestión de eventos, gestión de vulnerabilidades, monitorización, implementación de controles, etc., y finalmente, doce años como consultor GRC enfocado en el análisis y gestión de riesgos, evaluaciones de seguridad, SGSI, continuidad de negocio, privacidad, políticas y procedimientos, cumplimiento, etc. En total, si exceptuamos partes específicas de algunos dominios (modelos concretos de seguridad, por ejemplo), mi experiencia me proporcionaba una base adecuada para gran parte de los dominios de seguridad.

Por tanto, ¿es difícil el examen? En mi opinión, tiene un grado de dificultad intermedio, pero eso dependerá mucho de la metodología de estudio de cada persona, sus conocimientos y su experiencia. Pero, en cualquier caso, es un examen que se puede superar con una cantidad de esfuerzo razonable.

¿Refleja el examen la práctica profesional?

Una de las críticas que se le hacen al CISSP así como al CISM, del que hablaré en el próximo post, es que no reflejan la práctica profesional, sino que para aprobar tienes que aplicar la forma de pensar de (ISC)2 o de ISACA, respectivamente. No estoy en absoluto de acuerdo, y aquí es relevante mencionar otra de las cosas que se dicen del CISSP: piensa como un gestor (“think like a manager“). Para el CISSP, tú no eres el administrador de sistemas encargado de parchear un equipo, sino el gestor que se encarga de supervisar que todo el proceso de parcheo se haga correctamente (eso incluye la gestión del cambio). Sí, quizá tus tareas diarias en el mundo real sean parchear equipos, eso es perfecto, pero vas a tener que abstraerte de eso para el CISSP. Pongamos una pregunta ejemplo bastante obvia.

Recientemente se ha descubierto una vulnerabilidad 0-day que afecta a un servidor web crítico de la compañía, y para la que el fabricante todavía no ha emitido un parche. ¿Cuál es la primera acción a adoptar?

a) Parar el servicio y esperar a que el fabricante genere un parche.
b) Evaluar el riesgo asociado a la vulnerabilidad.
c) Cambiar manualmente la versión del servidor web para reducir la posibilidad de un ataque.
d) Llamar al CEO para informarle de la vulnerabilidad.

Para la mayoría de personas, debería ser evidente que la opción correcta es la b). Detener un servicio crítico para el negocio no será, en ningún caso, lo primero que se haga. Quizá posteriormente sí, pero antes habrá que evaluar el riesgo (para lo que hay hablar con el negocio), decidir las opciones de gestión del riesgo y contemplar potenciales medidas compensatorias, si procede. Tampoco cambiar manualmente la versión del servidor es lo primero que se haría, porque eso se salta toda la gestión de la configuración, con implicaciones, por ejemplo, en el caso de una potencial contingencia o para la actualización de versiones. Por último, quizá el CEO quiera estar informado (no lo sabemos, pero es algo que es irrelevante), pero sin haber evaluado cómo de serio es el problema, sería hacerle perder el tiempo. Quizá se trate de un 0-day que solo es posible explotar internamente, o la vulnerabilidad afecte a una funcionalidad no habilitada en nuestro servidor; ¿de verdad vas a informar al CEO sin conocer el impacto?

Como decía antes, quizá detener servicios o cambiar la configuración de un servidor web sea parte de tus tareas cotidianas, pero la cuestión es que para el CISSP tú no ocupas ese rol. Tú eres un gestor, lo que significa básicamente que cualquier acción debe partir de una evaluación del riesgo sobre el negocio, que es el que tiene la última palabra. Eso no implica que en cada situación adversa se deba llevar a cabo un análisis formal de riesgos a lo largo de varios meses y presentar un informe a Dirección. Significa valorar la vulnerabilidad, la exposición, la probabilidad de explotación, el impacto para el negocio, la motivación del atacante, los aspectos legales, las opciones de gestión del riesgo y el coste de mitigación, entre otros. Y entonces decidir qué se hace. Y todo eso se puede decidir en una reunión de media hora entre el personal de TI, el personal de negocio afectado, el CISO y cualquier otro perfil relevante para la decisión (legal, por ejemplo).

También debemos tener en cuenta que el CISSP asume que la organización, excepto si se indica lo contrario, sigue las buenas prácticas de gestión y gobierno de TI y seguridad de la información. Esto implica que en general, se puede asumir que hay implantada una gestión del cambio, gestión de la configuración, un plan de continuidad de negocio, una estructura organizativa de TI definida, etc. Quizá tu actual organización no tenga ese nivel de madurez y seas tú el responsable de evaluar el riesgo y aplicar las medidas técnicas que se estimen necesarias, pero incluso en ese caso, estás implícitamente evaluando el riesgo. Y en fin, si cambias esa versión o paras un servicio crítico sin pensar antes o tener en cuenta el negocio, estás trabajando mal.

Una última cosa. No es cierto que existan dos respuestas válidas para una misma pregunta, ni que las preguntas del examen estén a años luz del material de estudio del CISSP. Quizá la opción correcta sea poco evidente, quizá no sea tan sencillo como sumar 2 + 2, pero existe una única opción correcta.

Los materiales de estudio

Hay infinidad de materiales existentes para prepararse el CISSP, y dedicando el esfuerzo y el tiempo necesario, es difícil no aprobar el examen, ya sea a la primera, segunda o tercera vez. Y si eso te ha sucedido, debes plantearte que quizá estés haciendo algo mal. Quizá no estés entrando al examen con la mentalidad adecuada, quizá te hayas centrado en memorizar los detalles técnicos o las respuestas de los tests que has hecho, quizá no estés gestionando bien el tiempo del examen, etc.

Entre los materiales existentes, podemos destacar algunos. En primer lugar, se encuentra el libro específico del CBK, aunque según opinión mayoritaria, es duro de leer y no aporta nada relevante respecto a otras alternativas con un enfoque más “agradable”. Frente a este tenemos diversos materiales alternativos, como la guía de estudio y de preguntas oficiales, el CISSP All-in-ONE (AIO) de Shon Harris, el Eleventh Hour CISSP Study Guide, los cursos gratuitos de Cybrary por la fantástica Kelly Handerhan , además de múltiples páginas web y aplicaciones para practicar los tests (Boson, CCCure, Skillset, Simplilearn, CISSP Pocket Prep App, etc.) y vídeos de YouTube de preparación para el examen, preguntas ejemplo, etc.

Los materiales que yo utilicé y algunos comentarios al respecto son los siguientes (sobra decir que no tengo absolutamente ninguna relación con los autores):

CISSP (ISC)2 Certified Information Systems Security Professional Official Study Guide, 8th Edition (9/10). Para mí, este fue el recurso principal de estudio. Aunque se trata de cerca de 1000 páginas, es un texto que está bien escrito y aunque no diría que se hace ameno, se lee con cierta rapidez y facilidad.
Sybex CISSP Official (ISC)2 Practice Tests, 2nd edition (9/10). Como acompañante al anterior, tenemos el material de tests oficial, que contiene ocho tests de aproximadamente 100 preguntas cada uno, uno por cada dominio, más cuatro tests globales de 125 preguntas. En total, vienen a ser en torno a 1300 preguntas.
11th hour CISSP (8/10). Este libro, significativamente más breve que el anterior, es un repaso rápido a todos los conceptos del CISSP, de una manera más concisa y directa. Es un buen libro para dar un repaso rápido, aunque apenas le dediqué tiempo.
Boson CISSP tests (10/10). Para mí, los tests de Boson fueron el recurso principal para la preparación del examen, tras haber leído el libro oficial y el 11th hour CISSP. Con cinco exámenes de 150 preguntas cada uno, son en total 750 preguntas, con un enfoque muy similar al que puedes encontrar en el examen, tanto en redacción como en dificultad. Las dos ventajas principales de estos tests es que te permiten entrar en ese “rol de gestión” del que hablaba antes, y proporcionan información muy útil sobre por qué una respuesta es la adecuada y el resto no.
Simplilearn CISSP free practice test (8/10). Este examen de prueba, que está disponible libremente en Internet, cuenta con 250 preguntas que, aunque quizá no estén tan cercanas al examen como en el caso de Boson, sí se aproximan y permiten dar un repaso global a toda la materia para detectar puntos débiles.

Por último, el día antes del examen vi un vídeo de Kelly Handerhan sobre diez aspectos clave a tener en cuenta a la hora de enfrentarse al examen, y que habla de la importancia del riesgo, la prioridad del negocio, el enfoque no técnico o el necesario equilibrio entre protección y valor del activo, entre otros puntos. Es absolutamente recomendable.

Aparte de estos, las opiniones que se pueden leer en los foros es que el CISSP AIO es bueno, pero entra quizá en demasiados detalles técnicos. Un recurso que recibe excelentes críticas son los vídeos de Kelly Handerhan en Cybrary.it, en los que repasa, en 13 horas (si la memoria no me falla), los ocho dominios del CISSP. Ignoro si tiene subtítulos, pero con un nivel intermedio de inglés se puede probablemente seguir sin demasiados problemas. Por otro lado, la aplicación Pocket Prep me fue de mucha utilidad para superar el examen del CISM un par de semanas más tarde, pero no puedo opinar de la versión del CISSP, aunque en general las críticas que he leído son buenas.

Consejos finales

Tras dar un repaso global al examen y la certificación, vamos con los consejos, que proporciono únicamente a título personal:

A no ser que tengas muchos problemas con el inglés (en cuyo caso es complicado que hayas podido preparar el examen por la falta de materiales de estudio, al menos en español), escoge la opción en inglés. Un examen de 250 preguntas y seis horas supone un desafío importante, en el que deberás luchar no solo con el examen, sino con tu motivación y el cansancio acumulado durante la preparación y el día del examen (antes del cual previsiblemente habrás dormido poco). Por el contrario, en la versión adaptativa tendrás un máximo de 150 preguntas a responder en tres horas, y si tienes algo de suerte y vas lo suficientemente preparado, en 100 preguntas habrás acabado, como fue mi caso. La versión adaptativa impide retroceder para revisar preguntas anteriores, y eso es algo a tener en cuenta, por lo que tendrás que dedicar algo más de tiempo a cada pregunta. En el peor de los casos, tienes 1m15s por pregunta, más que suficiente.
No olvides que no eres un técnico. Eres un gestor y como tal, tu papel está relacionado con la evaluación del riesgo y el funcionamiento del negocio. Y esto es aplicable a CISSP y a CISM. Insisto, la primera acción a adoptar, por lo general, nunca será técnica. Antes de apagar un servidor, cambiar una regla en el firewall, actualizar un servicio, siempre, SIEMPRE, habrá alguien que, al menos en su cabeza, haya valorado el riesgo y las implicaciones para el negocio.
Lee la pregunta dos, tres o cuatro veces, despacio. Haz lo mismo con las respuestas. Busca las palabras clave y ten en cuenta si se pregunta por la primera opción, la mejor, la más eficaz, la más eficiente, etc.
Controla el tiempo que llevas pero no corras si no es necesario, y no te apresures a dar una respuesta si no estás seguro (e incluso aunque estés seguro tras la primera lectura). Sin embargo, tampoco te desmoralices si no tienes ni idea de la respuesta a una pregunta, ni pierdas quince minutos en ella, especialmente al principio del examen. Razona, opta por la opción que mejor te pareza y avanza.
Aunque ya sabes que en el examen del CISSP eres un gestor, no hay que descartar que surja alguna pregunta más directa con detalles ligeramente “técnicos”. En la medida de lo posible, memoriza parte del material (ese para el que no hay otra opción que la memorización) para asegurar esos puntos.
Haz muchos tests. Repítelos, incluso aunque te sepas de memoria algunas preguntas. Presta atención a las explicaciones y entiende por qué esa es la respuesta correcta. Aunque ninguna pregunta de esos tests aparezca en el examen, ni siquiera aquellas de los materiales oficiales, te ayudarán enormemente a ver tus errores y aprender, sobre todo, a analizar la pregunta y las respuestas de la manera adecuada. No te obsesiones con sacar un 70% o un 80%, porque en última instancia acabas memorizando las respuestas y el porcentaje acaba subiendo.
Aplica el sentido común para descartar opciones. Por ejemplo, quizá no sepas en qué fase de la gestión de ciberincidentes se investiga la causa principal, pero desde luego, no es en la detección, en la que no sabemos ni siquiera si es un incidente real o un falso positivo, ni en l fase de contención, que es cuando estamos más enfocados en contener el impacto.
Identifica conceptos en las preguntas y respuestas que te puedan proporcionar información sobre la pregunta correcta. Por ejemplo, quizá en lugar de “VPN” se hable de “acceso remoto seguro”, o no se mencione “firma digital” pero en su lugar mencione “mecanismo de no repudio”.

Para acabar, no te desmoralices por lo que leas en Internet. El CISSP es un examen pasable con un grado de esfuerzo razonable, que en general será inversamente proporcional a la experiencia profesional que poseas en los ocho dominios del CISSP.

En el próximo post hablaré brevemente del CISM, de sus similitudes con el CISSP y algunos consejos básicos para superarlo.

Buena suerte.

La entrada La certificación CISSP – II. Experiencia personal aparece primero en Security Art Work.

Este fin de semana se pronosticaba un tiempo de perros en Madrid, y todavía estaba arrastrando un malware elegante que no terminaba de curar, así que tocaba casa y manta. Y el mismo viernes por la tarde me entero que la gente de Magnet había abierto al público el reto forense que habían jugado en el MUS (Magnet User Summit), junto con una licencia de prueba de Magnet Axiom para poder probarlo y cacharrear al gusto.

Un poco de AC/DC, leche con miel y whisky (ambos son buenos para currar el catarro, o eso dicen) y un buen reto forense no son un mal plan para el finde ;-)

Enlaces de interés:

URL de la plataforma CTFd del reto – https://mus2019.ctfd.io/
Evidencias – https://drive.google.com/drive/u/0/mobile/folders/1E0lELj9NouMwSMGZCI7lXWRqYE2uQCpW?usp=sharing

1. ¿Qué tipo de imagen forense del móvil tenemos?

Viendo que lo que tenemos es un fichero .tar, podemos descartar directamente una adquisición física o un chip-off. Si abrimos el fichero y vemos que solo tenemos las carpetas básicas, podemos afirmar que es una adquisición lógica (aparte de que si sabemos leer, el nombre del fichero es “samsung SM-J337V Quick Image.zip“, y la adquisición lógica viene definida como “Quick/Logical” J )

* Respuesta: Quick/Logical

2. ¿Cuál es el IMSI de la tarjeta SIM?

Si examinamos el contenido del .zip nos encontramos con tres elementos: “Agent Data“, “sdcard” y adb-data.tar… que es justo la salida de las herramientas de adquisición lógica de Axiom, como se puede observar:

https://www.magnetforensics.com/blog/android-messaging-forensics-sms-mms-and-beyond/

Sabiendo eso, lo que queremos no va a estar ni en adb-data.tar ni en la sdcard, así que nos toca examinar la carpeta “Agent Data”. En la misma carpeta encontramos una BD SQLite con nombre agent_sim.db, que tiene una pinta estupenda. Si la abrimos con DB Browser for SQLite podemos encontrar una entrada con los datos del teléfono:

IMSI = International Mobile Subscriber Identity, por lo que la columna “subscriber_id” parece la correcta … y lo es.

* Respuesta: 311480460682294

3. ¿Cuál es el número de teléfono del dispositivo (en formato 2125551212)?

En cuanto nos damos cuenta de que el “formato 2125551212” quiere decir “todo junto sin espacio”, la misma tabla nos da la respuesta:

* Respuesta: 3153165956

4. ¿Qué búsqueda en Google se realizó en el teléfono el 4 de diciembre de 2018?

Después de media hora buscando y rebuscando el historial de navegación por la adquisición lógica del Samsung, recuerdo que teníamos el Takeout (una copia de todo lo relacionado con Google y Android). En 10 segundos localizamos el fichero:

Takeout\My Activity\Search\Myactivity.html

cuyo análisis nos da la respuesta:

* Respuesta: iguana potty training

5. ¿Cuál es el nombre de usuario en Kik del dueño del terminal móvil?

Si buscamos la app en Google vemos que su identificador es “kik.android”. Sin embargo, si buscamos en las evidencias obtenidas comprobamos que no tenemos nada de Kik más allá de un par de directorios vacíos en la sdcard.

Sin embargo, como hemos ido recabando información básica (es decir, revisando los SMS enviados), la tabla SQLite mmssms.db nos echa un cable con un SMS muy revelador:

* Respuesta: selmabspring

6. ¿En qué país estaba el teléfono móvil el 7 de diciembre?

Dado que no tenemos datos de geolocalización, vamos a tener que improvisar. La pregunta induce a pensar que la persona ha podido viajar por varios países. No sé en Yankilandia, pero en España es habitual que cuando cambias de país la operadora te manda un SMS indicándote de posibles cargos y/o condiciones del servicio de telefonía y datos.

Rebuscando en la BD de SMS/MMS encontramos dos referencias a países:

La fecha está en Epoch Time, pero con una conversión rapidita tenemos la respuesta.

* Respuesta: Australia

7. ¿Cuál es el nombre de fichero de la foto más grande que se ha realizado con la cámara?

Aquí tan solo tenemos que localizar el directorio de las fotos del terminal. Encontramos dos, que parecen ser uno copia del otro:

mobile\sdcard\sdcard\DCIM\Camera
mobile\shared\0\DCIM\Camera

Si abrimos la carpeta y ordenamos por tamaño, obtenemos fácilmente la respuesta:

* Respuesta: 20181209_144014.jpg

8. ¿Cuál es la dirección de correo personal para el usuario al que se le manda un SMS el 13 de febrero de 2019?

Si pasamos la fecha a Epoch Time, nos dará algo en el rango de “155009xxxxxxx”. Revisando los SMS enviados, encontramos una serie que parece interesante:

La columna address indica el número de teléfono, así que solo tenemos que ir a la BD contact3.db y cruzar los datos del teléfono 5043449306 con la dirección de correo:

* Respuesta: phoebe5042002@icloud.com

9. ¿Qué dirección de correo envió la invitación de Mega?

Asumimos que el dueño del terminal tenía una cuenta de Gmail, por lo que los datos los tendríamos que tener en:

Takeout\Mail\All mail Including Spam and Trash.mbox

Si buscamos por los Subject por la palabra “MEGA” no tardamos en encontrar el correo con la invitación:

From 1628368704126583192@xxx Mon Mar 18 18:23:30 +0000 2019
Delivered-To: macgyverfan74@gmail.com
To: Macgyverfan74@gmail.com
Subject: MEGA Invitation
MIME-Version: 1.0
From: MEGA <support@mega.nz>
Reply-To: wdoobner@putinsangels.com
Content-Type: multipart/related; boundary=x7543c9c3cf3bf532
Message-Id: <20190318182329.AA09D20C74@lu5.api.mega.nz>
Date: Mon, 18 Mar 2019 19:23:29 +0100 (CET)

--x7543c9c3cf3bf532
Content-Type: multipart/alternative; boundary=y609c26826caa5b12

--y609c26826caa5b12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Macgyverfan74@gmail.com
The user with the email wdoobner@putinsangels.com has sent you an invitation to join MEGA.
"Hello, join me on MEGA and get access to encrypted storage and
communication."

Join wdoobner@putinsangels.com on MEGA by clicking below:
https://mega.nz/#newsignupTWFjZ3l2ZXJmYW43NEBnbWFpbC5jb22eiiyGyNdjkw

Best regards,
— Team MEGA
----

* Respuesta: wdoobner@putinsangels.com

10. ¿Qué imagen forma parte del avatar de Kik del usuario?

El rato que nos pasamos buscando información sobre Kik en la adquisición lógica es bien aprovechado. Dado que hicimos una búsqueda por *kik* en todos los ficheros del terminal, encontramos éste:

mobile\shared\0\temp\kikTmpOriginalPicFile

que abierto con cualquier visor de imágenes, y sin ser un experto biólogo marino, parece ser un pingüino

* Respuesta: penguin

11. ¿En qué estado (de EEUU) estaba el teléfono el 25 de diciembre de 2018?

Los datos de localización no se han guardado en el Takeout como tal, así que tendremos que ser creativos y revisar el resto de los datos disponibles… pero parece algo muy costoso, así que vamos a tirar de la capacidad de Axiom para buscar evidencias en rangos de fechas.

En 20 segundos tenemos una captura de pantalla con una búsqueda de tacos en Orlando más que interesante …

Fail! Probamos con minúsculas (estos retos son a veces muy puñeteros con las respuestas). Fail again! Hay algo que no estamos teniendo en cuenta correctamente. Si revisamos con Axiom las fotos comprobamos que hay una con metadatos de localización:

Si convertimos las coordenadas con una página como esta:

https://www.gps-coordinates.net/

comprobamos que la foto se ha tomado en New York. Lo metemos en la solución y … Fail! Haciendo un doble check de lo que hemos hecho comprobamos dos cosas:

Habíamos metido mal los datos en la web de GPS, y la posición por defecto era New York. Si los metemos correctamente comprobamos que estamos en Orlando.
Geografía básica: Orlando no es un estado de EEUU. Es la capital de Florida. F******* !!!!!

* Respuesta: Florida

¡Extra Bonus! Al desbloquear esta pregunta nos aparece una nueva:

12. ¿En qué parque temático estaba el terminal móvil el 25 de diciembre?

Si repasamos y colocamos correctamente en la web de coordenadas GPS los datos correctos:

GPS Longitude: 81°28’5.0000″ (W)
GPS Latitude: 28°28’43.0000″ (N)

Nos dará una localización perfecta, justo lo que necesitábamos.

* Respuesta: Universal Studios

13. ¿Cuál de las siguientes apps NO fue descargada desde Google Play?

El Takeout tiene una carpeta para Google Play en la que aparecen todos los datos relacionados con las apps:

Takeout\Google Play Store

Si revisamos el fichero de Installs.json podemos comprobar que para cada app instalada aparecen unos metadatos:

{
  "install": {
    "doc": {
      "documentType": "Android Apps",
      "title": "YouTube"
    },
    "firstInstallationTime": "2018-12-04T05:13:33.705Z",
    "deviceAttribute": {
      "model": "SM-J337V",
      "carrier": "Verizon Wireless",
      "manufacturer": "samsung",
      "deviceDisplayName": "samsung SM-J337V"
    },
    "lastUpdateTime": "2019-03-18T18:55:21.504Z"
  }
}

Todas las apps tienen estos metadatos, lo cual implica que las cuatro han sido instaladas. Sin embargo, si nos vamos al documento de Library.json comprobamos que aparecen todas menos YouTube.

Y si nos fijamos en el fichero anterior, la fecha de instalación de las otras tres apps es siempre posterior al 04/12/2018 … que parece ser la fecha en la que se desplegó el SO Android del terminal (algo que nos cuadra ya que Youtube es una “Google app” de las que suelen venir instaladas por defecto en un terminal con “Google Play Services”)

* Respuesta: Youtube

14. ¿En qué timezone estaba el teléfono el 9 de diciembre?

Volvemos a la carga con la actividad detectada por Axiom en el día de autos.

Encontramos una “interacción” de Google Cloud que marca como fecha “Dec 9, 2018, 4:00:00 AM EDT”. EDT = Eastern Daylight Time, pero ojo con el horario de invierno/verano.

Según esta web: https://24timezones.com/time-zone/edt , en invierno es UTC-5 … Fail!

Vamos a ser más minuciosos. Axiom nos da unas cuantas imágenes, así que vamos en primer lugar a asegurarnos de que la fecha de creación es la correcta… y no encontramos ninguna. Sí que es cierto que vemos él archiconocido edificio de la ópera de Sidney, y que según preguntas anteriores el terminal el día 7 de diciembre estaba en Australia (lo que correspondería a AEST, https://24timezones.com/time-zone/aest , UTC+10 para los amigos).

Metemos la solución y … Fail!. Es para tirarse de los pelos ¿Qué podemos estar haciendo mal? Si hemos revisado que estamos en diciembre, no se aplica el horario de verano, !coñe! Espera … ¿estos no eran los que se tomaban siempre las uvas en bañador?

Pues sí, en el hemisferio sur el DST (Daylight Saving Time, horario de verano para los amigos) va AL REVÉS:

https://www.worldtimeserver.com/learn/what-is-daylight-saving-time/

por lo que nuestro UTC+10 es en realidad UTC+11 porque, aunque aquí estemos pelándonos de frío, allí es verano…

* Respuesta: UTC+11

15. ¿Cuál es el apellido del usuario cuyo correo electrónico es pangolinsrock@outlook.com?

Si nos dan un correo, vamos a buscar en los logs de actividad del correo que hemos usado en preguntas anteriores:

Takeout\Mail\All mail Including Spam and Trash.mbox

Buscando por el email pangolinsrock@outlook.com no nos cuesta mucho encontrar lo que estamos buscando:

From: Bri Frazier <pangolinsrock@outlook.com>
To: Selma Bouvier <macgyverfan74@gmail.com>
Subject: Re: What up

* Respuesta: Frazier

16. ¿Qué cuenta posteó el vídeo que el terminal móvil visitó el 4 de diciembre a las 06.23AM (UTC)?

Takeout es un lujo, porque lo tienes TODO (y cuando eres consciente de que Google TAMBIÉN lo tiene, da para pensar un rato…). En este caso tenemos la actividad de vídeos vistos en YouTube en:

Takeout\YouTube\history\watch-history.html

No aparece ninguno a las 06:23 AM … porque la hora es UTC. La hora del vídeo que aparece en el mismo minuto es EDT, que según https://www.timeanddate.com/time/zones/edt corresponde a UTC-4 … pero siendo diciembre no tendría que ser horario de verano sino EST (Eastern Standard Time) que es UTC-5 y encaja con nuestra respuesta.

Me quedo sin saber explicar del todo esta hora de diferencia… pero la respuesta es suficientemente buena como para ser correcta O:)

* Respuesta: DesertedReptile98

!Extra Bonus!: Al resolver esta pregunta me aparece un nuevo reto: “HOLY COW BATMAN!”, en el que al parecer hemos “encontrado” la contraseña de acceso a un volumen cifrado con Bitlocker:

protectedbyjubjub

Ya me parecía raro que con las preguntas que tenía resueltas me faltaran tantos puntos, tenía que haber un nivel secreto por algún lado…:D

17. ¿En qué país estaba el dueño del terminal móvil mientras estaba leyendo un documento que era “IN MEMORY OF MOE”?

Después de revisar a fondo todos los contenidos tanto del móvil como del Takeout sin encontrar ni una sola pista, releemos la pregunta con cuidado: se está hablando del propietario del terminal, pero no parece obligatorio que el documento se esté leyendo EN EL TERMINAL.

Y como en la pregunta anterior nos acaban de dar la contraseña de un volumen de Bitlocker, vamos a buscarlo (en estos retos las pistas siempre sirven para algo). Buscando por ficheros grandes en el directorio de la usuaria nos cuesta poco encontrar este:

C:\Users\SelmaBouvier\Desktop\EvenMoreSecretStuff.vhd

Un fichero .vhd corresponde a “Virtual Hard Disk”, que es la extensión que debería tener un volumen cifrado con BitLocker (por si el nombre del fichero no es pista suficiente). Para poder acceder a su contenido tenemos que montarlo y descifrarlo, algo que podemos hacer con este procedimiento:

Abrimos un terminal de Windows y tecleamos diskmgmt.msc para abrir el Administrador de discos
Acción –> Exponer VHD, y seleccionamos el .vhd del reto
En este momento tendremos la unidad montada y visible desde el explorador de ficheros, aunque con un candado. Si intentamos acceder a la misma, nos pedirá la contraseña … y ¡bingo!

Dentro no encontramos nada más que una papelera y el “System Volume Information”. Pero la basura de uno es el oro del de al lado, así que nos lanzamos sobre la papelera cual mapache hambriento … y no nos deja acceder (niveles de permisos de las papeleras, cosas raras).

Pero podemos darle una vuelta haciendo uso de alguna utilidad como TreeSize (que de paso nos sirve para estimar el tamaño de las carpetas), y encontramos algo mejor que una hamburguesa medio mordida: un precioso .zip

El .zip tiene un montón de chicha que nos hace pensar que vamos por el buen camino: múltiples referencias a “Los Simpsons”, de los que Moe es un personaje importante (le da cerveza a Homer, y todos sabemos que “Sin tele y sin cerveza homer pierde la cabeza”)

Estos ficheros son oro puro, pero no nos ayudan a resolver la pregunta (aunque nos darán un quintal de puntos en el apartado siguiente). Me sirvo una cerveza para no hacer un Homer, y pienso: si no está en los ficheros del takeout y no está en el terminal … en algún lado tiene que estar.

Al final termino por revisar todas las imágenes del terminal para ver si hay algún tipo de mensaje oculto (pista: no lo hay), y por revisar paso a paso todos los ficheros de actividad del takeout para ver si me he dejado algo en algún vídeo (y descubro que McGyver tiene hasta películas, qué cosas).

El peine fino al final tiene su recompensa. En una de las páginas visitadas encontramos la maldita referencia:

¿En serio? Los organizadores del reto son un poco sádicos, aunque sí que es cierto que en algún caso forense habrá que llegar hasta este nivel de detalle para encontrar las evidencias que nos hagan falta…

De todas forma, encontrar la referencia es tan solo la mitad del puzzle, ya que tan solo nos da la fecha: Dec 6, 2018, 2:47:55 PM EDT. En esas fechas el dueño del terminal andaba de viaje, así que puede estar en Australia, New Zealand o EEUU. Si revisamos los SMS que se han enviado tenemos este timeline:

Welcome to New Zealand –> Tuesday, 4 December 2018 20:04:34.285
Welcome to Australia –> Friday, 7 December 2018 0:10:57.096

Por lo que lo razonable es que el 6 de diciembre el usuario estuviera en Nueva Zelanda … !bingo!

* Respuesta: New Zealand

La entrada MUS CTF DFIR – MOBILE (Nivel 1) aparece primero en Security Art Work.

En la entrada anterior habíamos encontrado un .zip altamente jugoso, así que vamos a empezar a apalearlo para que cante todas las flags de este nivel…

1. ¿Qué lenguaje ha sido empleado para crear el ejecutable del proyecto secreto?

Esta la vamos a responder con la información de la última pregunta de la parte anterior. Dentro de ese estupendo .zip podemos encontrar un ejecutable cuyo icono es bastante delator:

* Respuesta: Python

!Extra Bonus! Cuando respondemos esta pregunta se abren 5 preguntas más. Esto parece que va para largo…

2. ¿Qué versión de Python usa el binario compilado (formato N.N)?

El duro trabajo de la respuesta 3 nos da una justa recompensa (Python 3 lo tiene claro para eliminar a Python 2.7, que parece tener cuerda para rato):

* Respuesta: 2.7

3. ¿Qué herramienta ha sido empleada para crear el ejecutable?

Nos dan una serie de opciones a elegir. Viendo otras preguntas que hay más adelante, parece que vamos a tener que decompilar el código, así que vamos a ello.

Py2exe es la opción más común para generar ejecutables Windows basados en código Python, y puede ser decompilado con una herramienta como unpy2exe. Sin embargo, no parece que nuestro ejecutable haya sido generado con py2exe:

La segunda opción es PyInstaller, que podemos decompilar con el script pyinstxtractor.py del toolset de Python-exe-unpacker :

… y como funciona, nos da nuestra merecida respuesta (y de paso, la del apartado anterior).

* Respuesta: PyInstaller

4. ¿Qué arquitectura de procesador tiene el binario compilado?

Un poco de pestudio nos da la respuesta en un periquete:

* Respuesta: amd64

5. ¿A qué número hace rellamada el AT-5000?

pyinstxtractor.py nos ha extraído los diversos componentes del ejecutable. Sin embargo, parece que no ha sabido interpretar correctamente el fichero at-500, que parece nuestro código principal.

Si revisamos la documentación de pyinstxtractor.py, parece que en algunos casos no interpreta correctamente el método principal, algo que podemos corregir con el script python_exe_unpack.py (también de Python-exe-unpacker):

# python python_exe_unpack.py.py -p at-5000

Que nos da un precioso fichero en Python:

# uncompyle6 version 2.11.5
# Python bytecode 2.7 (62211)
# Decompiled from: Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34) 
# [GCC 7.3.0]
# Embedded file name: at-5000.py
import time
import random
NED_FLANDERS = [
 5, 5, 5, 8, 9, 0, 4]

class At5000Error(Exception):
    def __init__(self, message):
        super(At5000Error, self).__init__(message)

class PhoneState(object):
    def __init__(self):
        self.phone_digits = [
         5, 5, 5, 0, 0, 0, 0]
    def increment(self):
        if self.phone_digits == NED_FLANDERS:
            return
        increment_number(self.phone_digits, 6)
    def __str__(self):
        return '{}{}{}-{}{}{}{}'.format(*self.phone_digits)

def increment_number(phone_number, index):
    if index < 0:
        raise At5000Error('AT-5000 Auto-dialer errorerororororor')
    phone_number[index] += 1
    if phone_number[index] == 10:
        phone_number[index] = 0
        increment_number(phone_number, index - 1)

def main():
    phone_state = PhoneState()
    for i in range(10000000):
        phone_state.increment()
        if phone_state.phone_digits == NED_FLANDERS:
            print 'Redialing: {}'.format(phone_state)
        else:
            print 'Calling: {}'.format(phone_state)
        time.sleep(0.01)

if __name__ == '__main__':
    main()

Si lo miramos un poco por encima, cuando el número de teléfono a marcar coincide con la variable NED_FLANDERS, se produce una rellamada (el theme simpsoniano está aplicándose a rajatabla al parecer).

* Respuesta: 5558904

6. ¿De quién es el número al que se hacen las rellamadas?

Pregunta de combo ya que la teníamos resuelta en la anterior con solo ver la variable que se llama … ;-)

* Respuesta: Ned Flanders

7. ¿Cuánto tiempo espera (en segundos) el AT-5000 para marcar números?

Si repasamos el código encontramos un sleep más que revelador:

time.sleep(0.01)

* Respuesta: 0.01

8. ¿Qué dos librerías importa el AT-5000?

Si miramos el comienzo del código veremos los imports:

import time

import random

* Respuesta: time random

9. ¿Cuál es el máximo número de llamadas que puede hacer el AT-5000?

Inspeccionando el código tenemos el bucle for con nuestra respuesta:

def main():
phone_state = PhoneState()
for i in range(10000000):

* Respuesta: 10000000

La entrada MUS CTF DFIR – Secret Project (Nivel 2) aparece primero en Security Art Work.