Los indicadores de peligro como forma de reducir riesgos

Los propietarios de infraestructuras TI tienen que comprobar con frecuencia si hay componentes maliciosos en sus recursos. El contagio puede ocurrir, por ejemplo, si los delincuentes explotan vulnerabilidades de “día cero”. En estos casos, puede que los desarrolladores de software de seguridad informática todavía no sepan nada de las nuevas amenazas. Al mismo tiempo, es posible que los expertos ya estén investigando los incidentes relacionados con la nueva amenaza. Es más, hasta puede que ya hayan publicado algunos resultados de sus investigaciones.

Estos informes tienen valor práctico. Un informe típico sobre una campaña APT contiene la siguiente información:

• quiénes son las víctimas del ataque y qué objetivos persiguen los delincuentes;
• qué tiempo han estado activos los componentes maliciosos;
• la lista de los nodos (direcciones IP) de las víctimas;
• las actividades actuales de los componentes maliciosos y/o los grupos de ciberdelincuentes;
• una descripción detallada de los instrumentos y programas maliciosos que usan los delincuentes;
• una descripción de la infraestructura de los centros de administración;
• los indicadores de peligro (IoC, reglas YARA, etc.).

De la información técnica detallada sobre las APT, al administrador de seguridad informática le interesarán sobre todo los indicadores de peligro. Es decir, el conjunto de datos que puede ayudar al administrador de la infraestructura IT a descubrir actividades malintencionadas en el sistema y tomar las medidas necesarias.

Pero en la práctica, ¿cómo usan los administradores de sistemas informáticos estos indicadores? En este artículo trataremos de dar respuestas a esta pregunta.

El indicador de peligro es una información estructurada sobre señales de actividad maliciosa que se puede importar a los sistemas automatizados de búsqueda de infecciones en la infraestructura. A pesar de que todavía no existe un formato estándar de descripción de los datos de los indicadores, en la industria han recibido una amplia difusión y soporte algunos tipos de datos estructurados.

IOC

IOC (indicator of compromise) es una lista de datos sobre amenazas (por ejemplo, cadenas que describen la ruta de ficheros o claves del registro), que brinda la posibilidad de utilizar programas de análisis automatizado para detectar la presencia de amenazas en la infraestructura.

Los escenarios más simples de uso de IOC suponen la búsqueda en el sistema de ficheros específicos según diferentes criterios: hash MD5, nombre del fichero, fecha de creación, tamaño y otros atributos. Además, se pueden buscar diferentes indicios específicos en la memoria o en el registro del sistema operativo Windows.

Existen diferentes formatos de representación de estos datos, por ejemplo, OpenIOC. Estos formatos permiten importar los datos en diferentes soluciones de protección para el posterior procesamiento de los indicadores. El administrador puede integrar los IOC tomados de los informes con diferentes soluciones de protección:

• sistemas de protección de la clase “Endpoint Security”;
• SIEM
• IDS/IPS
• HIDS/HIPS
• diferentes instrumentos de investigación de incidentes.

Existe un gran número de soluciones comerciales para el procesamiento de IOC, pero en algunos casos las posibilidades de sus análogos de licencia libre son suficientes para analizar el sistema en búsqueda de indicios de infección. Por ejemplo, Loki, un escáner IOC distribuido bajo la licencia GPL, que permite buscar en el sistema diferentes indicios que aparecen como consecuencia de las actividades maliciosas.

Para analizar un sistema con la ayuda del scanner Loki basta con descomprimir el archivo de la utilidad e introducir los atributos IOC en la base de conocimientos del escáner. El directorio “signature” de la aplicación contiene las siguientes categorías de IOC:

• “filename-iocs”, un fichero de texto que contiene listas de diferentes atributos del sistema de ficheros que son el resultado de las actividades de las amenazas;
• “hash-iocs”, una lista de los hashes MD5, SHA1 y SHA256 de los componentes maliciosos que aparecen en el sistema después de la infección;
• “falsepositive-hashes”, una lista de exclusiones de hashes MD5, SHA1 y SHA256 que el escáner clasifica como “falsos positivos” al detectar los componentes correspondientes.

Para ilustrar su uso, tomemos nuestro informe sobre la investigación de APT Carbanak. En la página 36 hay una lista de los hashes MD5 de todos los componentes maliciosos que pueden aparecer después de la infección. Abramos el fichero “hash-iocs” del escáner e introduzcamos la regla correspondiente en el siguiente formato: <MD5>;<description>.

Lista de los hashes MD5 de los compontes de la APT Carnabak en el fichero “hash-iocs” del escáner Loki

Acto seguido, en el fichero de texto “filename-iocs”, que describe los atributos de los componentes maliciosos en el sistema, crearemos un indicador en el formato:

# COMMENT

# REGULAREXPRESSION;SCORE

IOC para el sistema de ficheros en la lista “filename-iosc” del escáner Loki

Después de introducir los indicadores necesarios en la base de conocimientos del escáner, se puede iniciar el análisis de la estación de trabajo. Para hacerlo, hay que lanzar el fichero ejecutable “loki.exe” con privilegios de administrador (porque en caso contrario, el escáner no podrá analizar el contenido de la memoria operativa en búsqueda de atributos) y esperar que termine el análisis.

Proceso de análisis de la utilidad Loki

Al concluir el análisis, la aplicación creará un informe con el nombre “loki.txt” en el directorio del programa.

Reglas YARA:

Aparte de los diferentes indicadores de IOC, se pueden adjuntar a los informes ficheros con la extensión “.yar”. Estos ficheros contienen reglas creadas según una sintaxis especial para YARA, un instrumento destinado a la identificación y clasificación de muestras maliciosas. Las reglas YARA describen las señales de la presencia de actividades maliciosas en el sistema. Si alguna de las reglas se ejecuta, el analizador emite un veredicto sobre la infección con los detalles correspondientes (por ejemplo, el nombre de la amenaza).

El escáner Loki también admite las reglas YARA y por consiguiente, los ficheros .yar tomados de los informes pueden servirle al administrador para analizar el sistema en búsqueda de las amenazas mencionadas en el informe. Y para esto basta con trasladar el fichero .yar al directorio “signatura” e iniciar el análisis.

Sin embargo, para trabajar con las reglas YARA es mucho más adecuado usar el instrumento oficial de los creadores del proyecto YARA, porque su base de conocimientos se actualiza regularmente y es mucho mayor que las bases de utilidades similares. Esto permite usar los resultados del análisis para tener una visión más cabal del nivel de protección del sistema informático e información más completa sobre la presencia de componentes maliciosos en el mismo.

Para realizar el análisis en la estación de trabajo, basta con ejecutar la utilidad YARA con los parámetros necesarios. Por ejemplo:

yara32.exe –d md5= <MD5_hash><esta regla yara.yar><directorio a analizar>

donde el parámetro “-d” se usa para determinar variables externas. Si la utilidad detecta alguna correspondencia con las condiciones de la regla, mostrará una notificación con el nombre de la regla y el componente correspondiente.

Ejemplo de notificación sobre una regla YARA que se ejecutó

El administrador puede iniciar análisis similares, por ejemplo al iniciarse el sistema operativo. Para hacerlo, basta escribir un sencillo script PowerShell, que ejecutará la utilidad con los parámetros necesarios y, de ser necesario, usar Active Directory para organizar su ejecución en todos los equipos. User configuration -> Windows configuration -> Scenarios ->Logon.

STIX y JSON

Structured Threat Information Expression (STIX) es un idioma unificado para la notación estructurada de información sobre amenazas y su posterior importación en soluciones de software. Muchas de las soluciones de protección permiten importar la información descrita en el formato STIX (y también en JSON, del que hablaremos más adelante) para su uso posterior en la infraestructura, por ejemplo:

• SIEM;
• Soluciones de protección basadas en indicadores (por ejemplo, escáneres);
• Plataformas Forensic;
• Soluciones de la clase “Endpoint Security”, etc.

La solución popular SIEM IBM QRadar puede importar informes STIX, usando un script Phiton especial:

./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet

Donde “-f” determina la ubicación del documento STIX local, “-i” determina el host con la consola QRadar instalada y “-t” determina el token de servicio para QRadar.

JSON es uno de los formatos más populares de intercambio de datos, que también se usa con frecuencia en los adjuntos de los informes. El uso de datos en el formato JSON depende de las tareas del administrador y las peculiaridades de la solución de software donde se realice la importación de estos datos. Por ejemplo, si el fichero JSON contiene las direcciones IP de los centros de administración a los que se conectan las estaciones de trabajo infectadas, el administrador de la infraestructura puede poner estas direcciones en la lista de rechazados de su firewall, si este admite la importación de datos JSON. Si el firewall no admite la importación en este formato, el administrador puede utilizar un parser (procesador de ficheros JSON) para exportar la lista de direcciones del fichero, y después importarla a la lista de rechazados del dispositivo.

Prepáralos como se debe

Los “indicadores de peligro” hacen que los datos sobre las amenazas tengan una aplicación efectiva: detectar software malicioso y reaccionar de inmediato a la aparición de incidentes. Al mismo tiempo, es muy frecuente que los indicadores se adjunten a los informes sobre amenazas, que muchos leen sin prestarles la debida atención. Pero incluso si el informe de alguna investigación no contiene una sección especial de “Indicators of Compromise”, siempre se pueden extraer del mismo los datos útiles, convertirlos a cualquiera de los formatos descritos e importarlos en una solución de protección.

Nuestras últimas investigaciones con indicadores de peligro:

Wild Neutron – Economic espionage threat actor returns with new tricks

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns

The Great Bank Robbery: the Carbanak APT

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)