CERT.at Tipos de feeds CTI

En CERT.at procesamos y compartimos una amplia selección de inteligencia sobre amenazas cibernéticas (CTI) como parte de nuestra misión principal como centro de información de seguridad TI de Austria. En este momento estamos involucrados en dos proyectos que involucran la compra de CTI comercial. Encontré algunas opiniones diferentes sobre qué es CTI y qué se debe hacer con los indicadores de compromiso (IoC) que forman parte de un feed de CTI.

Esta publicación de blog describe mi punto de vista sobre este tema.

El La UE decidió en marzo de 2022 para crear un fondo de respuesta a emergencias de ciberseguridad con la cual ENISA puede comprar servicios de apoyo a las entidades NEI en los estados miembros.

Austria también participa en un proyecto surgido de la convocatoria DEP DIGITAL-ECCC-2022-CYBER-03 en combinación con un adquisición conjunta con las ECCC.

Una forma de estructurar y clasificar los feeds CTI es observar el nivel de abstracción en el que operan. Como Wikipedia lo pone:

• Táctico: normalmente se utiliza para ayudar a identificar actores de amenazas (TA). Se utilizan indicadores de compromiso (como direcciones IP, dominios de Internet o hashes) y se empieza a profundizar en el análisis de tácticas, técnicas y procedimientos (TTP) utilizados por los ciberdelincuentes. Los conocimientos generados a nivel táctico ayudarán a los equipos de seguridad a predecir próximos ataques e identificarlos en las etapas más tempranas posibles.
• Operacional: Este es el nivel más técnico de inteligencia sobre amenazas. Comparte detalles concretos y específicos sobre ataques, motivación, capacidades de los actores de amenazas y campañas individuales. Los conocimientos proporcionados por los expertos en inteligencia de amenazas en este nivel incluyen la naturaleza, la intención y el momento de las amenazas emergentes. Este tipo de información es más difícil de obtener y, con mayor frecuencia, se recopila a través de foros web oscuros y profundos a los que los equipos internos no pueden acceder. Los equipos de seguridad y respuesta a ataques son los que utilizan este tipo de inteligencia operativa.
• Estratégico: Inteligencia generalmente adaptada a audiencias no técnicas, sobre riesgos generales asociados con las ciberamenazas. El objetivo es entregar, en forma de documentos técnicos e informes, un análisis detallado de los riesgos actuales y futuros proyectados para el negocio, así como las posibles consecuencias de las amenazas para ayudar a los líderes a priorizar sus respuestas.

Con la CTI táctica, existe una posibilidad razonable de que pueda compartirse de máquina a máquina con información semántica completa que permita automatizar el procesamiento con fines de detección y prevención. Muchos dispositivos de seguridad comerciales se venden con una suscripción a las fuentes de datos del propio proveedor. Esto abarca desde simples soluciones antispam hasta filtros para servidores proxy web y reglas para SIEM.

Si bien es posible codificar CTI operativo en formatos de intercambio de datos estandarizados como STIX2, es mucho más difícil para los sistemas automatizados poner en funcionamiento esta información. Por ejemplo, ¿qué reacción técnica automatizada es posible ante “el actor de amenaza X que ahora utiliza CPE en el país de sus objetivos de comunicación C2”? Sí, se puede almacenar ese tipo de información en AbiertoCTI (o una plataforma de inteligencia de amenazas (TIP) similar) y asignarla al Marco ATT&CK. Esto puede ser valioso para que el experto humano planifique defensas o reaccione mejor durante incidentes, pero no está lo suficientemente detallado para la defensa automatizada.

Con CTI estratégica, estamos en la capa de gestión humana. Esto nunca está diseñado para el procesamiento automatizado por máquinas.

Centrándose en el capa técnica, encontramos que hay varios tipos diferentes de información codificada en las fuentes de datos. Una forma de ver esto es la Modelo de diamante de análisis de intrusión. que se basa en información sobre el adversario, la capacidad, la infraestructura y la víctima. Si bien este es un modelo muy valioso para el análisis de intrusiones, es demasiado complejo para una categorización simple de las fuentes CTI.

Propongo los siguientes tres tipos básicos:

Tipo 1: Información de la superficie de ataque

Muchos de los feeds de Shadowserver entran en esta categoría. Los datos de Shodan también pueden ser un buen ejemplo. Ahora hay un grupo de empresas centrándose en la “calificación de riesgo cibernético”, que intentan evaluar la infraestructura visible de Internet de las organizaciones.

Ejemplos:

• «En la dirección IP ABCD, en el momento X, detectamos un servidor Microsoft Exchange ejecutando una versión que es vulnerable a CVE-202X-XXXX».
• «Se puede abusar del servidor de hora en la dirección IP Y como reflector de ddos».
• «En la dirección IP Z, hay un MongoDB desprotegido al que se puede acceder desde Internet».

Puntos notables son:

• Esta es información muy específica sobre un sistema concreto. Generalmente queda muy claro quién es el responsable.
• No hay información sobre un compromiso real del sistema listado. Es posible que el sistema no haya sido modificado o que ya haya varios webshells implementados en él.
• No hay información sobre un atacante.
• Se trata de información sensible (potencialmente incluso relevante para el RGPD).
• Esta información es (casi) inútil para nadie excepto para los propietarios del sistema. Bueno, excepto los actores de amenazas, esa es otra razón por la que consideramos que se trata de información confidencial.
• Por tanto, el CSIRT coordinador debe transmitir esta información a los mantenedores de este sistema y a nadie más. CERT.at suele etiquetar estos eventos con “sistema vulnerable/vulnerable” o “servicio accesible vulnerable/potencialmente no deseado”.

Respuesta esperada del propietario del sistema:

• Mitigar la amenaza reconfigurando/parchando/actualizando/eliminando el sistema o tal vez incluso aceptar el riesgo (por ejemplo, “sí, realmente queremos tener telnet habilitado en ese servidor”).
• Verifique que el sistema no haya sido vulnerado todavía.

Tipo 2: COI de actores de amenazas

Esto es todo lo contrario: la información se refiere únicamente al actor de la amenaza y los recursos que utiliza este grupo, pero no hay información clara sobre los objetivos. La información típica contenida en estos IOC es:

• El nombre de dominio de un servidor de comando y control (C2) del TA
• Una dirección IP de un servidor C2
• Nombre de archivo y/o hash del malware utilizado por la AT
• Asunto del correo electrónico, remitente y dirección IP de envío de un correo de phishing
• Nombres mutex, claves de registro o artefactos similares de una infección
• Patrón de URL de conexiones C2

Ejemplo:

• Se detectó una campaña RAT Remcos 2023-06-14 para usar

  • Mutex: Rmc-MQTCB0
  • URI: /json.gp
  • Archivo adjunto de correo electrónico: Shipment_order83736383_document_file9387339.7z
  • MD5: 2832aa7272b0e578cd4eda5b9a1f1b12
  • Nombre de archivo: Shipment_order837363.exe

Puntos notables son:

• Esta es información detallada sobre la infraestructura, las herramientas y los procedimientos de un actor de amenazas.
• A menudo no hay información sobre los objetivos de estos ataques. A veces, se conoce cierta información de objetivos, como «Esta asistencia técnica suele atacar a empresas de alta tecnología».
• Esta información es potencialmente útil para todos aquellos a quienes ese actor pueda apuntar.
• A menos que uno piense que las direcciones IP de los atacantes merecen protección GDPR, estos datos no tienen implicaciones de privacidad.
• Por lo tanto, el CSIRT coordinador debe transmitir esta información a todos los mandantes que sean capaces de poner en práctica dicha CTI. Por lo general, CERT.at no envía este tipo de información de manera proactiva a todos los integrantes, sino que operamos una instancia de MISP que contiene estos IOC. La automatización de la seguridad por parte del constituyente puede utilizar las API de MISP para recuperar y procesar los IOC.
• Si el objetivo de la TA es suficientemente conocido y específico, CERT.at transmitirá los COI directamente al equipo de seguridad del elector.
• En casos raros, la AT está abusando de la infraestructura de uno de nuestros electores. En ese caso, tenemos una mezcla con el siguiente tipo de CTI.

Respuesta esperada del propietario del sistema:

• Agregue los IOC a cualquier tipo de sistema de prevención de incidentes, por ejemplo, listas de filtros en servidores proxy, EDR o software audiovisual.
• Agregar los IOC al sistema de detección de incidentes, por ejemplo, crear reglas adecuadas en SIEM.
• Lo ideal es realizar también una búsqueda en registros antiguos de los IOC recién adquiridos.

Tipo 3: datos de infección

A veces recibimos información sobre amenazas cibernéticas que es muy específica y se refiere a un incidente real dentro de la red de un elector.

Ejemplos son:

• “Detectamos en la marca de tiempo X un webshell colocado en un servidor Citrix. Dirección IP = ABCD, ruta = /logon/LogonPoint/uiareas/mac/vkb.php”
• «Nuestro monitoreo de la red oscura detectó que alguien está vendiendo credenciales de VPN para usuario@ejemplo.com en la plataforma X»
• “Después de la eliminación de la botnet X, estamos monitoreando las conexiones de los drones de la botnet a los antiguos servidores C2. En [timestamp]la dirección IP ABCD conectada a nuestro sumidero”.
• «Logramos obtener acceso a la infraestructura del actor de amenazas X. Según los datos que encontramos allí, su constituyente Y está comprometido».
• “A continuación encontrará información sobre las IP geolocalizadas en su país que probablemente alojen un sistema infectado por el malware SystemBC. […] Marca de tiempo, dirección IP, nombre de host, dirección IP c2”
• “Hay indicios de manipulaciones maliciosas en el sitio web del dominio X, hay una página de phishing en /images/ino/95788910935578/login.php”

Puntos notables son:

• Suele ser información muy específica sobre un incidente real que involucra un sistema concreto.
• En el mejor de los casos, la información es lo suficientemente buena como para desencadenar una investigación y remediación exitosas.
• A menudo, aunque no siempre, se nombra al actor de la amenaza.
• Se trata de información sensible (potencialmente incluso relevante para el RGPD).
• Esta información es (casi) inútil para nadie excepto para los propietarios del sistema.
• Esta información puede ser muy urgente: una reacción rápida a veces puede prevenir un incidente de ransomware.
• Por tanto, el CSIRT coordinador debería transmitir esta información rápidamente a quienes mantienen este sistema y a nadie más. CERT.at suele etiquetar estos eventos como «intrusiones/compromiso del sistema» o «fraude/phishing»

Respuesta esperada del propietario del sistema:

• Inicie el proceso de respuesta a incidentes locales.
• Limpie la infección conocida e investigue la posibilidad de compromisos adicionales en la red afectada (¿movimiento lateral?).
• Investigue cómo se comprometió el sistema y reconfigure/parchee/actualice/elimine el sistema para que ya no sea posible una reinfección a través de la misma vulnerabilidad.

CERT.at está utilizando IntelMQ para procesar alimentaciones de tipo 1 y 3. Las alimentaciones CTI de tipo 2 son manejadas por nuestro MISP instalación.