CFP (Call For Papers): consejos para que tu propuesta no quede en el tintero

En la actualidad existen muchas conferencias de seguridad (CON, como nos gusta llamarlas) tanto en España con el resto del mundo, y la mayoría seleccionan las charlas que se van a dar a través de un proceso abierto que se denomina CFP (Call For Papers).  Un CFP es un proceso abierto en el que cualquiera puede presentar una propuesta de charla, y a través de un comité de selección se eligen las que se consideran más apropiadas.

Presentar una charla a una CON tiene múltiples beneficios: en primer lugar, en España tienes una entrada gratis a la CON (y en casi todos los casos la Organización te paga el viaje y la estancia). Luego tenemos la obvia promoción tanto propia (se habla todavía de algunas charlas épicas de algunas CON de años pasado) como de la empresa para la que trabajas, y a mí me gustaría destacar el hecho de que presentar NO ES FÁCIL: implica tener el tema muy dominado, lo que obliga a aprender cosas nuevas, hacer pruebas, tener en cuenta casos límite… un trabajo de investigación que colabora enormemente a tu propio desarrollo. 

[Read more…]

Los peligros de andar por las nubes: DFIR en O365 (V)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior Ángela había terminado de desgranar todas las acciones de los atacantes, por lo que ya sabía lo que había sucedido realmente y tenía una explicación completa del incidente:

  1. Los atacantes envían un phishing a Pepe Contento, que cae en el mismo e introduce las credenciales.
  2. Leen el correo de Pepe Contento, y no encuentran nada de interés
  3. Crean una app maliciosa en su tenant de Azure y la configuran para que solicite entre otros acceso al correo.
  4. Entran con la cuenta de O365 de Pepe Contento a Teams, y convencen a Inocencio Crédulo para que de permisos a esa aplicación, dando a los atacantes acceso a su correo.
  5. Leen el correo de Inocencio Crédulo y encuentran las credenciales de la cuenta de emergencia.
  6. Inician sesión con la cuenta de emergencia, y despliegan todas las acciones de evasión (usuario administrador global, regla de correo) y de espionaje (permisos sobre los buzones de correo y sitios de Sharepoint).
  7. Desde la cuenta de emergencia, intentan engañar (sin éxito) a la Directora General para que instale un Grunt de Covenant.
  8. La Directora General comparte el documento con uno de sus adjuntos, que poco después lo comparte con el otro adjunto vía O365.
  9. Los atacantes exfiltran el documento del O365 de Pepe Contento, y lo filtran al “Happy Gossipy”.

Sabiendo todo lo que han hecho los atacantes, Ángela puede pasar a la fase de contención y erradicación (que en este caso ocurre de forma simultánea, y según el “método Pelayo”, se realiza con contundencia):

[Read more…]

Los peligros de andar por las nubes: DFIR en O365 (IV)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior Ángela había descubierto que el borrador del documento para la felicidad mundial había sido exfiltrado a través de O365, y que los atacantes tenían privilegios de administrador global gracias a su control de la cuenta “emergencia”.

Dado que Inocencio Crédulo aparece referenciado en varias ocasiones, Ángela decide obtener un eDiscover de su usuario, y revisar los mensajes de correo. Lo que encuentra no le hace especialmente feliz, pero por lo menos resuelve una de las incógnitas presentes:

[Read more…]

Los peligros de andar por las nubes : DFIR en O365 (III)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior, Ángela acaba de recopilar los datos de O365 del MINAF y toda la información de eDiscover de la Directora General, así que se puede poner manos a la obra. El correo electrónico suele ser una vía de entrada de todos los males, así que lo primero que hace es cargar el buzón de correo con Kernel Outlook PST Viewer. 

Como tenemos un marco temporal sobre el que pivotar (sobre el 18 de noviembre a partir de las 19:00h UTC aproximadamente) y un sospechoso (el usuario emergencia), no cuesta mucho encontrar un correo sospechoso:

[Read more…]

Los peligros de andar por las nubes : DFIR en O365 (II)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior habíamos visto cómo se había producido un intento de descarga de malware en el equipo de la Directora General de Festejos del MINAF, y que el malware se había descargado desde el propio Sharepoint. Llegado este momento, es necesario obtener evidencias de O365 porque está claro que la nube está implicada en el incidente. Para ello vamos a contar con las siguientes fuentes de información:

  • UAL (Unified Access Logging): Log básico de O365, guarda todas las acciones relevantes de los usuarios y administradores.
  • Message Trace: Guarda los metadatos de los correos enviados.
  • Salida de Hawk, herramienta de detección de compromisos en entornos O365.
  • Full eDiscover:  salida completa de todos los correos, mensajes de Teams y ficheros de OneDrive y Sharepoint (afortunadamente, la nueva política de seguridad de la información permite estas adquisiciones siempre que estén debidamente justificadas).
[Read more…]

Los peligros de andar por las nubes: DFIR en O365 (I)

Nota 1: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación.

Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo taller práctico, se puede aprovechar de varias maneras: podéis descargar las evidencias ya trabajadas para poder seguir el caso paso por paso, podéis descargaros las evidencias en bruto para hacer vuestra propia investigación … o podéis jugar al CTF DFIR que hemos preparado y que os irá desgranando el caso a medida que vayáis respondiendo a los diversos retos.


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

El año no había sido bueno para Ángela de la Guarda, CISO del MINAF (Ministerio de la Alegría y la Felicidad). Después del susto con el ataque de ransomware del año pasado (del que se libraron por los pelos), el esfuerzo de mantener los niveles de seguridad con todos los requisitos del teletrabajo unido a la falta de personal (la propia Ángela estaba haciendo de CIO en funciones, supliendo la baja del Subdirector General) había hecho que le aparecieran las primeras canas (!maldita sea, recién cumplidos los 40 y ya con tinte!). 

Todo esto sumado a las ya conocidas modas tecnológicas: el furor de este año es la Transformación Digital (que si le preguntas a 100 técnicos tendrás 102 respuestas diferentes, porque cuando lo dices en voz alta en algunos casos te aparece un comercial listo para venderte algo). En el MINAF este reto se ha trasladado en la realización de un piloto para poder trabajar en la nube con todas sus ventajas:  disponibilidad, movilidad y accesibilidad (cierto), ahorro de costes y seguridad (eso lo podríamos discutir).

La Dirección General de Festejos, unas 25 personas,  se ha migrado a O365, usando un conjunto de licencias de E3 (la licencia corporativa más barata). Este equipo ha recibido una formación sobre cómo usar la nube, y están empleando Exchange Online para el correo, Teams para la mensajería instantánea y tanto Sharepoint como OneDrive para compartir ficheros.

[Read more…]

Ransomware ate my network (V)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior ya habíamos terminado el análisis forense del incidente, por lo que Ángela ya tenía una visión global de todo lo que había ocurrido. Los timelines son una herramienta de análisis sensacional para poder entender lo ocurrido en un incidente, así que construimos una (con las horas en UTC, no perdamos las buenas costumbres):

  • 4/Nov: Los atacantes envían los correos con enlaces maliciosos a personal de la FFP.
  • 9/Nov – 11:37h – dolores.jolgorio abre el correo, descarga y ejecuta el .doc con la macro maliciosa.
  • 11:38h – El equipo se infecta con un agente de Meterpreter.
  • 11:41h – Los atacantes ejecutan diversos comandos para reconocer el sistema.
  • 11:46h – Los atacantes “revenden” el acceso al segundo grupo, cediendo el control con un agente de Empire.
  • 12:01 – Los atacantes elevan privilegios con un exploit de la vulnerabilidad CVE-2020-0787.
  • Entre las 12:01 y las 12:37h: Vuelcan hashes con la funcionalidad Powerdump de Empire.
  • 12:37h – Lanzan SharpHound e identifican W10-PC3 como equipo con una sesión iniciada de administrador de dominio.
  • 13:16h – Con los permisos de administrador local, copian el stager de Empire a W10-PC3 y lo ejecutan con PsExec.
  • Entre las 13:16 y las 13:30h – Obtienen el hash NTLM de la cuenta dom.adm con Mimikatz.
  • 13:51h – Montan el pivot SSH-RDP y acceden al DC con el hash NTLM de la cuenta dom.adm.
  • 13:55h – Copian el fichero temp.zip con las GPO y scripts de Powershell.
  • 13:57h – Despliegan la GPO “All in One”, que erosiona severamente la seguridad de los equipos del dominio.
  • 15:08h – Despliegan la GPO “Scheduler”, que copia el ransomware a los equipos y deja programada una tarea para su ejecución a las 17:15h.
  • 15:13h – Lanzamiento de un agente de Empire.
  • 15:30h – Saltan las alertas en GLORIA.
[Read more…]

Ransomware ate my network (IV)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

[Nota del editor: Pinchando en muchas imágenes –aquellas cuyo detalle no se ve del todo con el tamaño de la página principal– se muestra una versión ampliada]


En el artículo anterior vimos cómo Ángela había deducido que los atacantes habían entrado en el equipo empleado para conectarse al DC desde otro equipo empleando la herramienta PsExec. Dispuesta a encontrar el PsExec, Ángela empieza convirtiendo a .csv la MFT extraída por CyLR con mftdump.exe, y buscando por actividad alrededor de la la hora en la que vio la conexión en el otro equipo (sobre las 14:16h, 13:16h en UTC que es lo que nos muestra la MFT).

No hay un objetivo claro, pero ese Prefetch de stalin.exe parece sospechoso (recordemos que los Prefetch se crean la primera vez que se ejecuta el software, con un retraso de unos pocos segundos).

[Read more…]

Ransomware ate my network (III)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior la investigación se había quedado con el equipo con la IP 10.11.2.14 como origen de las conexiones al DC (y que tenía tanto conexiones con el C2 101.143.122.216 como el antivirus desactivado de forma previa al ataque generalizado).

Dado que estamos hablando de conexiones y que disponemos de la memoria RAM, lo primero que hace Ángela es emplear el plugin netscan de Volatility para sacar las conexiones de red (el perfil de memoria es Win10x64_17134) y confirmar las conexiones con el C2:

Netscan devuelve a su vez unos cuantos resultados adicionales:

¿Una conexión a un SSH remoto?

¿Y qué hace este equipo prestando un servicio en el puerto 443/TCP? ¿Se ha vuelto loco? Está claro que tenemos que profundizar en estas conexiones saber qué hay detrás de ellas. Ángela decide revisar los logs de Sysmon, en los que tendrían que aparecer las conexiones de red… pero parece que la FFP no aplicó correctamente la configuración de Sysmon estándar del MINAF, por lo que no se están recogiendo esos datos (grrrrrrr).

[Read more…]

Ransomware ate my network (II)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior vimos cómo el MINAF había evitado por los pelos un ataque de ransomware, pero nos quedaban muchísimas preguntas por resolver.  En primer lugar, averiguar la identidad del grupo de ransomware que había afectado al MINAF. 

Para ello Ángela convierte la MFT del DC con mftdump.exe y realiza una búsqueda rápida de los ficheros v2.exe y v2c.exe, que parecían a priori los encargados de desplegar el ransomware. Da en el clavo porque encuentra los ficheros en la carpeta c:\temp\scheduler:

Rápidamente calcula sus hashes:

5994df288813a7d9588299c301a8de13479e3ffb630c49308335f20515ffdf57  v2c.exe
b2a304e508415d96f417ed50d26e0b987b7cbd9a77bb345ea48e803b5a7afb49 v2.exe
ffa8722a09829acd7ef8743688947f6ccb58d2ef v2c.exe
7320b34c07206fcaf1319d6ce9bef2b29648a151 v2.exe
eddc0e293b0f0ee90bab106f073a41c9 v2c.exe
91438699bed008be9405995f0a158254 v2.exe

Lo siguiente es comprobar si son conocidos. VirusTotal le da una respuesta rápida:

[Read more…]