Infección masiva: checklist para CERTS

boot

Recientemente ha caído en mis manos una guía estupenda llamada Guide to malware incident prevention and handling, elaborada por el NIST, que me ha servido de lujo para documentar un posible caso de incidente: una infección masiva de equipos. Casos en los que esta situación podría ser posible:

  • Malware muy nuevo cuyas firmas de antivirus aún no les ha dado tiempo a incorporar
  • Campaña de phishing dirigido
  • Vulnerabilidad 0-day para un software muy extendido en la organización

De hecho, los casos reales suelen ser un conjunto de varias de estas situaciones. Ya que no es posible protegerse al 100% de este tipo de amenazas, como buen incident handler, nuestra misión es estar preparados para responder ante estas situaciones lo más rápido posible y así mitigar en mayor medida el posible daño.

Para eso, he redactado una especie de checklist con los pasos a realizar y los casos a tratar para cada una de las fases de un incidente. Obviamente estos casos son genéricos y no son más que un esqueleto de actuaciones, que pueden aplicar o no a la situación concreta de cada organización, y que para que sea realmente efectivo, requiere de una documentación específica, con instrucciones técnicas y procedimientos asociados.

Por ejemplo, si un paso del checklist es “buscar en los logs del IDS en busca de otra actividad sospechosa para la IP del equipo infectado” lo que se debe hacer, si se quiere crear una documentación eficaz, es asociar una instrucción técnica de cómo hacer esa búsqueda en el software del appliance concreto que dispone la organización. Y cuanto mayor detalle de explicación, mejor. Idealmente, este documento lo debería leer una persona totalmente ajena al servicio y hacer la actuación sin haber tocado en su vida nada de lo descrito en el documento, porque de hecho, es probable que por alguna emergencia, la persona que tenga que actuar sea alguien ajeno al servicio. Otro motivo por el que debe estar muy bien explicado es porque en casos de emergencia, donde el tiempo es vital, la presión y los nervios pueden dejar totalmente en blanco a un técnico experimentado.

Allá vamos. Paso a enumerar las fases del ciclo de vida de un incidente, con los pasos aplicados para la respuesta ante una infección masiva:

1.- PREPARACIÓN

Esta fase implica que todo esté listo y en funcionamiento para la gestión de un incidente.

  • Tener una lista actualizada de los teléfonos y correos electrónicos de los actores relacionados con los que se va a estar coordinados y comunicados cuando se identifique un incidente.  Ejemplo: responsable de sistemas, comunicaciones, proveedor de internet, etc
  • Documentación accesible y actualizada: en otras palabras, checklist como estos, al día ;)
  • Personal preparado: que sepan al menos donde encontrar esta documentación

2.- IDENTIFICACIÓN

Esta es la tarea que siempre está en marcha: detectar equipos infectados. Para ello, utilizaremos logs de los elementos de seguridad de red que disponga la organización, como pueden ser:

  • IDS
  • IPS
  • Cortafuegos
  • Consola de antivirus centralizado
  • HIDS, controles de integridad
  • DNS sinkhole
  • Web proxys, o filtradores de contenido
  • Appliance de seguridad de correo electrónico (ej IronPort)
  • Estadísticas de red (Netflow)
  • Analizador de protocolos o traffic shappers
  • Software de IOC

Toda esta cantidad de información sería muy recomendable que estuviera centralizada en un SIEM que sea capaz de correlar la información recopilada. Si se ha detectado una gran cantidad de equipos infectados siguiendo un mismo patrón, y no se tratan de casos aislados, debemos valorar si se trata de un único incidente de infección a gran escala.

Para abordar el caso, debemos recopilar toda la información posible y ser así precisos con la respuesta. Ejemplos de información a recoger puede ser:

  • Volumen de equipos infectados
  • Equipos cliente? Equipos servidor?
  • Alguno de los equipos afectados contenía información especialmente sensible?
  • Direcciones IP, hostname, usuario principal de la máquina
  • Momento de tiempo de la detección
  • Aplicaciones relevantes instaladas, y su versión: flash, java, navegadores, suite ofimáticas, parches de SSOO
  • Log del AV
  • Logs de los elementos de seguridad de red enumerados anteriormente con la información relevante de los equipos infectados
  • Muestras del malware

3.- CONTENCIÓN

En esta fase debemos evitar que la infección se propague a otras máquinas, y evitar que el malware siga dañando al equipo. El equipo de respuesta a incidentes debe elegir las medidas de contención más adecuadas que además minimice el impacto al resto de equipos y servicios.

Es muy importante contener antes de erradicar la amenaza, puesto que podríamos estar limpiando equipos al mismo tiempo que se siguen infectando los mismos, u otros, entrando en un trabajo interminable.

En primer lugar, para conocer las medidas de contención apropiadas, debemos conocer contra qué malware estamos luchando. Será recomendable recopilar la siguiente información:

  • Tipo de malware (virus, gusano, troyano)
  • Servicios, puertos, protocolos atacados
  • Vulnerabilidades que explota
  • Ficheros, tamaño, contenido de estos, metadatos, etc que maneja
  • Versiones de SSOO o aplicación que afecta
  • Cómo afecta al equipo, ficheros que modifica, servicios que instala
  • Cómo se propaga, y qué medidas se deben tomar para contener la propagación
  • Cómo se puede eliminar del equipo

Si el malware no está identificado, no hay información pública disponible sobre éste, y las casas de antivirus aún no han actualizado sus firmas, se deberá buscar información por otras fuentes, como listas de correo especializadas, o plataformas de “information sharing” (p. ej. MISP). También puede ser necesario investigar el malware a fondo, con un análisis estático, dinámico, o usando alguna herramienta tipo cuckoo.

Medidas de contención

  • Por participación del usuario: desconectar PC de la red, actualizar antivirus, etc. Para ello será necesario coordinarse con el departamento de helpdesk para que transmita las indicaciones a cada usuario. Si los equipos están gestionados de forma centralizada, la colaboración del usuario no sería necesaria.
  • A través de elementos de seguridad de red:Bloqueo de contenidos web, correo al que se conecta el malware. Reglas de cortafuegos, IDS o IPS personalizadas. Blacklist de ejecutables, a través de directivas de restricción de software o applocker.
  • Deshabilitando servicios: Si el malware utiliza un servicio interno para propagarse, valorar si merece la pena deshabiiltarlo, teniendo en cuenta el impacto de perder la disponibilidad de éste. ¿Afectaría a otros servicios?
  • Deshabilitando conectividad: Desconectar subredes de equipos afectados, o aislarlos en una VLAN diferente y evitar la propagación a otros equipos expuestos. Ojo con esta medida puesto que es muy disruptiva.

4.- ERRADICACIÓN

Una vez contenida la propagación, es momento de eliminar el malware de los sistemas.

Medidas de erradicación:

  • Si alguno de los equipos es especialmente crítico, valorar si es necesaria la adquisición forense antes de la erradicación del malware
  • Parcheo de la vulnerabilidad utilizada, actualizando software vulnerable, o cambiando la contraseña de un servicio, por ejemplo.
  • Limpieza de los equipos
  • Reinstalación o planchado con un backup limpio: en el caso de que no se pueda limpiar, se tiene evidencias de que el atacante o malware ha accedido con permisos de administración, con la amenaza de haber instalado rootkits o backdoors indetectables. También es conveniente la reinstalación en el caso de que el equipo quede dañado después de la limpieza, o ante la mínima duda de la naturaleza del malware, que haga sospechar que no se haya limpiado totalmente.

5.- RECUPERACIÓN

Este paso implica restaurar las funcionalidades perdida durante el incidente, y quitar las medidas temporales que hayan tenido que ser usadas para la contención

6- LECCIONES APRENDIDAS/AFTERMATH

La última fase de todas consiste en analizar el incidente, estudiar por qué ha ocurrido, y  sobre todo, tomar las medidas para que no vuelva a suceder, como por ejemplo:

  • Cambios en la política de seguridad y en la política de concienciación
  • Reconfiguración de software
  • Despliegue de elementos software/hardware adicionales

Espero que os sea útil este post. o/

social