El valor de los indicadores de compromiso en la industria

El tiempo de respuesta ante un incidente es crítico, y en los sistemas de control industrial, de por sí ya críticos, lo es aún más. Saber si un sistema es vulnerable ante un incidente en proceso, o si ha sido o no comprometido, es una ventaja que puede suponer la diferencia entre la gestión ante un incidente y la gestión del caos por un supuesto incidente. Aquí es donde entran en juego los indicadores de compromiso, IoC (de su nombre en inglés, Indicators of Compromise).

El exceso de información recibido durante un incidente, resulta igual de ineficaz que su defecto, la clave es procesar dicha información. El intercambio de información contrastada, de una manera legible por todo el personal encargado de la gestión de un incidente y técnicamente replicable e inconfundible, es la base de los IoC.

Un IoC es un esquema, normalmente escrito en XML, donde se especifican ciertos detalles técnicos replicables enlazados mediante operadores lógicos (AND, OR, etc…), para evidenciar o indicar si un sistema ha sido o no comprometido. Un IoC no siempre es consumido, muchas veces es necesario crearlo para compartirlo dentro de la propia empresa o de manera externa. Por este motivo debemos saber exactamente qué se considera un IoC.

El IoC más usado es el MD5 de un fichero junto con la fecha de creación, tamaño, tipo de fichero, etc. Normalmente procede de la muestra que desencadena el ataque, una vez identificada por el equipo de análisis. Como veremos, este es un indicador más y su presencia puede no ser suficiente para indicarnos si un sistema ha sido comprometido. Todas las evidencias que podamos encontrar en nuestro sistema, y atribuir al incidente, deben ir en el IoC. Existen una gran variedad de evidencias, desde los ya nombrados hashes de fichero MD5, SHA1, etc., hasta otros más específicos como pueden ser: observables de red (IP, Domain, movimientos laterales, scans…), procesos, servicios, ciertas cadenas en registros, etc.

Existen varios formatos para escribir un IoC, igual que existen varios lenguajes de programación. Dependiendo del destinatario del mismo, se elegirá uno u otro, pero las evidencias relativas al incidente van a estar dentro de cualquiera de estos IoC. De este modo encontraremos formatos de IoC bajo diferentes esquemas XML (STIX, OTX, CIF, OpenIoC, etc.).

Las principales características de un IoC son:

• Es un documento de intercambio de información.
• Es un documento vivo, no es definitivo y fácilmente adaptable.
• Es un documento flexible, se pueden recoger todo tipo de evidencias, tanto específicas de un sistema, como generales para todos los sistemas afectados.

- Ciclo de aplicación de un IoC durante un incidente, documento vivo en continuo cambio de forma recursiva -

La gran mayoría de las empresas reconocen saber lo que es un IoC, pero no saben realmente cómo pueden utilizarlos y el potencial que tienen estos durante la resolución de un incidente o la comprobación y prevención de este.

DENTRO DE UN IoC

En la fase inicial de un incidente, la primera evidencia o indicador del que dispondremos será el hash del fichero de entrada, y sobre esta aproximación se irá construyendo el futuro IoC.

Supongamos que nuestra empresa usa el estándar OpenIoC, y no disponemos de un IoC en este formato. Realmente la dificultad radica en el entendimiento del propio IoC, y qué posibles acciones podemos llevar a cabo para cada evidencia en particular.

- Fragmento de IoC en formato STIX proporcionado por el ICS-CERT para el incidente Wannacry-

Este fragmento de IoC nos indica una evidencia o hecho:

• La existencia de un fichero de tipo “PE32 executable (GUI) Intel 80386, for MS Windows” con un MD5 “5bef35496fcbdbe841c82f4d1ab8b7c2” será nuestro indicador de compromiso.

La ACCIÓN que debemos llevar a cabo ante esta información compartida será:

• Crear una lista con todos los MD5 y tipos de ficheros del sistema.
• Comprobar en esta lista si se encuentra el MD5 indicado en el IoC.

Esta acción puede ser más o menos compleja, podemos usar unas herramientas u otras, pero debe determinar un resultado concreto de verdadero o falso para el hecho.

Para facilitar este trabajo se desarrollan herramientas específicas para automatizar ciertas tareas. A continuación se detalla el funcionamiento de algunas:

Ejemplo 1: Visualización de un IoC en formato de OpenIoC

Supongamos que disponemos de un IoC proporcionado por una de nuestras fuentes de confianza. En este ejemplo, se ha usado un IoC creado por Mandiant para el incidente Stuxnet, en formato OpenIoC. Simplemente abriendo la herramienta IOC Editor de FireEye podemos abrir el fichero y visualizar su contenido. Como se muestra en la imagen, existen una serie de indicadores de diferente tipo (File, Driver, File Certificate, etc.) con una serie de expresiones lógicas (AND y OR) que operan con ellos. Esto nos permite saber que la existencia de esta secuencia de evidencias, determina que nuestro sistema ha sido comprometido por el incidente Stuxnet.

- Vista dentro de IoC Editor, de un IoC creado por Mandiant para el incidente Stuxnet-

Ejemplo 2: Creación de un IoC en formato de OpenIoC

Supongamos que disponemos de información referente a un incidente. Está información puede provenir de cualquiera de los canales habituales de confianza o de nuestro equipo de análisis, pero se ha recibido el IoC en un formato STIX y necesitamos convertirlo en formato OpenIoC para poder trabajar con él.

Para realizar este ejemplo, usaremos parte de un IoC en formato STIX proporcionado por el ICS-CERT para el incidente Wannacry. Este IoC nos informa de una evidencia en los sistemas comprometidos en forma hash MD5 de un archivo, como se muestra en la imagen.

- Creación desde IoC Editor, de un IoC para Wannacry creado para este ejemplo fuente de IoC STIX por ICS-CERT-

El primer paso es abrir la aplicación IOC Editor y crear un nuevo IoC en blanco. Rellenaremos los campos genéricos para conformar una pequeña ficha técnica del IoC. El segundo paso es añadir las evidencias que disponemos en ese momento, en nuestro caso, el MD5.

El uso es muy intuitivo. Dentro del cuerpo del IoC simplemente debemos añadir nuevo ‘ITEM’ de tipo ‘File MD5’ y rellenar la información en la pestaña de la derecha, como se puede ver en la imagen.

Ejemplo 3: Utilización de un IoC

Para poder utilizar la información de un IoC lo primero será la recolección de información del sistema. Para ello utilizaremos la ejecución desde línea de comandos de IoC_finder, tarea que puede tardar varias horas.

- Ejecución en línea de comandos de IOC Finder en modo ‘collect’ para recolectar toda información sobre el sistema-

Después de recolectar toda la información del sistema, hay que buscar dentro de estos datos, por aquellos requeridos dentro de nuestro IoC específico.

- Ejecución de IOC Finder en modo ‘report’ busca evidencias de nuestro IOC en los datos recolectados y los reporta -

Ejemplo 4: Resolución de un incidente en un “Sistema Comprometido”

Para comprobar si un sistema está comprometido podemos buscar evidencias con el framework Redline.

En este ejemplo vamos a hacer uso de un IoC modificado, en el cual se busca un hash de una evidencia para fichero ‘PDF_inofensivo_please_open_it.pdf’ calculado previamente.

Aquí se crea un recolector específico para resolver nuestro IoC, no se extrae toda la información del sistema, sino que solamente se extrae la información precisa resolver el IoC, por lo que es mucho más rápido. De esta forma tardamos pocos minutos en comprobar si nuestro sistema está comprometido.

Para llegar a entender un IoC, debemos tener en mente siempre una premisa: el IoC almacena información sobre una evidencia técnica adquirida, no indica cómo o con qué herramienta podemos encontrarla. Esto nos da libertad a la hora de comprobar un IoC, pero debemos tener claro qué herramienta usar para comprobar cada indicador en un sistema pendiente de analizar. Existen herramientas especializadas, como el comentado framework Redline, que permiten analizar un gran número de indicadores y nos facilitan el trabajo. No obstante, existen indicadores más complejos o muy específicos que requieren el uso de herramientas concretas. En esta categoría encontramos los indicadores de compromiso basados en YARA.

IoCs BASADOS EN REGLAS YARA

La herramienta yara está diseñada para la búsqueda de cadenas, por lo que permite identificar de manera rápida y flexible una cadena dentro de un fichero. Las reglas yara son la base de la herramienta, ya que en estas se define una estructura que responde a qué cadena/cadenas necesito buscar y la forma en la que pueden estar relacionadas dichas cadenas. La versatilidad de las reglas permite usar cadenas escritas en formato texto, en hexadecimal, mediante expresiones regulares o el uso de comodines. Además, incluye operadores lógicos para operar entre ellas (AND, OR, ==, >=, etc.).

-Regla Yara proporcionada por el ICS-CERT para el incidente Wannacry-

Como muestra la imagen, la estructura consta de tres campos y son bastante intuitivos:

• “meta”: Muestra información relevante del autor, fecha y para qué se ha escrito esta regla.
• “strings”: Cadenas a buscar, en cualquier formato soportado por yara.
• “condition”: Devuelve un valor Booleano “true” o “false”, después de buscar las cadenas relacionadas de la manera expresada.

Mediante la regla descrita en “meta” se indica al motor de escaneo que busque en todos los ficheros si existe una coincidencia con las cadenas “strings” que cumpla la expresión “condition”, en cuyo caso devolverá un resultado de verdadero “True”.

Las reglas yara son conocidas y usadas por muchos investigadores de seguridad, por lo que actualmente son consideradas como un indicador de compromiso en sí mismas. Algunos estándares como STIX 2.0 indican una forma concreta para integrar estas reglas en un IoC.

-IoC en estándar STIX con una Regla Yara incluida proporcionada por el ICS-CERT para el incidente Wannacry-

IoC BASADOS EN SNORT

Uno de los indicadores de compromiso que nos puede ayudar durante la fase de contención de un incidente, es la compartición de información referente a reglas snort. Compartir esta información o saber cómo viene reflejada dentro de un IoC y cómo podemos usarla, será clave a la hora de contener el avance de un incidente. Al igual que sucede con las reglas yara, las reglas snort tienen un formato específico y un motor bajo el cual se pueden implementar.

Algunos estándares indican una forma concreta para integrar las reglas Snort en un IoC.

-Reglas SNORT extraídas de CERT-EU Security Advisory 2017-012 para el incidente Wannacry-

Supongamos que gracias a una de nuestras fuentes de confianza hemos recibido las reglas snort de la imagen. Una forma de integrarlas en nuestro IoC para poder comunicarlo a nivel interno podría ser la que muestra la imagen:

-IoC en estándar STIX con reglas Snort incluidas creado para este ejemplo. Reglas SNORT extraídas de CERT-EU Security Advisory 2017-012 sobre Wannacry-

En los entornos industriales, las herramientas disponibles para la comprobación de los indicadores de compromiso se ven reducidas debido al uso de sistemas operativos menos comunes o específicos. Esto supondrá un mayor esfuerzo a la hora de realizar comprobaciones en entornos muy cerrados, limitando las herramientas a las propias del sistema. Recordemos que la potencia de los IoCs está en la compartición de información relevante de un incidente, dando libertad a los encargados de gestionar el incidente de cómo aplicar esta información en sus sistemas. El tiempo que no se emplee en repetir el trabajo que otros ya han realizado, probado y lo han compartido en un IoC de confianza, es el tiempo de ventaja en el incidente. Por ejemplo, si ya existe una vacuna o una forma de romper el “killchain” para un incidente, podemos centrarnos en analizar otras partes del incidente (permanencia, análisis de ficheros, etc…).

Disponer de un repositorio de IoCs, bien creado por nosotros mismos, bien proporcionado por fuentes confiables (como puede ser el servicio ÍCARO, actualmente ofrecido desde el CERTSI, de compartición de IoCs a operadores estratégicos, instituciones afiliadas a RedIRIS y CERTs internacionales), nos ayudará a comprobar y proteger nuestros sistemas industriales ante un determinado malware. Actualmente se utilizan IoCs más específicos para análisis de la forma de ataque de un malware, donde se pueden vislumbrar similitudes de comportamiento en la forma de infectar o en la manera de persistencia, esto nos puede ayudar a la hora de tener cierta ventaja en los siguientes pasos del incidente; Incluso identificar un atacante o una familia de malware, aunque ésta mute, o a un grupo común que actúe siempre de la misma manera.

En los ejemplos mostrados se ha empleado como referente el incidente Wannacry. Aunque las acciones de la última fase de este malware son visibles, existen muchos otros incidentes que pueden pasar totalmente desapercibidos. Realizar una comprobación para descartar que nuestros sistemas estén comprometidos empleando los IoCs a nuestra disposición, resulta crucial en el bastionado de los mismos.

Aprender a gestionar los IoCs nos aportará conocimiento de nuestro sistema. El uso de estos indicadores de compromiso nos ayudará a disponer y mejorar una serie de herramientas, que pueden ser claves en la resolución y prevención de un incidente futuro.