Sugerencias de mejores prácticas de inteligencia de amenazas

Mucha gente dice que la inteligencia de amenazas (TI) sabe bien, pero pocos entienden cómo cocinarla. Hay incluso menos de los que saben qué procesos involucrar para que TI funcione y genere ganancias. Además, un número insignificante de personas sabe cómo elegir un proveedor de feeds, dónde verificar un indicador de falsos positivos y si vale la pena bloquear un dominio que su colega le ha enviado a través de WhatsApp.

Teníamos dos suscripciones APT comerciales, diez intercambios de información, alrededor de una docena de fuentes gratuitas y una extensa lista de nodos de salida TOR. También usamos un par de poderosos inversores, scripts maestros de Powershell, un escáner Loki y una suscripción paga de VirusTotal. No es que un centro de respuesta a incidentes de seguridad no funcione sin todos estos, pero si está preparado para atrapar ataques complejos, tiene que hacer todo lo posible.

Lo que me preocupaba particularmente era la posible automatización de la verificación de indicadores de compromiso (IOC). No hay nada tan inmoral como la inteligencia artificial reemplazando a un humano en una actividad que requiere pensar. Sin embargo, me di cuenta de que mi empresa enfrentaría ese desafío tarde o temprano a medida que crecía el número de nuestros clientes.

Durante varios años de actividad permanente de TI, he pisado un montón de rastrillos y me gustaría brindar algunos consejos que ayudarán a los novatos a evitar errores comunes.

Sugerencia 1. No ponga demasiadas esperanzas en capturar cosas mediante hashes: la mayoría de los programas maliciosos son polimórficos en estos días.

Los datos de inteligencia de amenazas vienen en diferentes formatos y manifestaciones. Puede incluir direcciones IP de centros de comando y control de botnet, direcciones de correo electrónico involucradas en campañas de phishingy artículos sobre técnicas de evasión que los grupos APT están a punto de comenzar a aprovechar. Para resumir, estas pueden ser cosas diferentes.

Para solucionar todo este lío, David Bianco sugirió usar lo que se llama el Piramide del dolor. Describe una correlación entre los diferentes indicadores que utiliza para detectar un atacante y la cantidad de "dolor" que le causará al atacante si identifica un IOC específico.

Por ejemplo, si conoce el hash MD5 del archivo malicioso, puede detectarlo con facilidad y precisión. Sin embargo, no causará mucho dolor al atacante porque agregar solo 1 bit de información a ese archivo cambiará completamente su hash.

Consejo 2. Intente usar los indicadores que el atacante encontrará técnicamente complicados o costosos de cambiar

Anticipándome a la pregunta de cómo averiguar si existe un archivo con un hash dado en nuestra red empresarial, diré lo siguiente: hay diferentes formas. Uno de los métodos más fáciles es usar una solución que mantenga la base de datos de hashes MD5 de todos los archivos ejecutables dentro de la empresa.

Volvamos a la Pirámide del Dolor. A diferencia de la detección por un valor hash, es más productivo identificar el TTP del atacante (tácticas, técnicas y procedimientos). Esto es más difícil de hacer y requiere más esfuerzo, pero infligirás más dolor al adversario.

Por ejemplo, si sabe que el equipo de APT que se dirige a su sector de la economía está enviando correos electrónicos de phishing con archivos * .HTA a bordo, entonces crear una regla de detección que busque dichos archivos adjuntos de correo electrónico golpeará al atacante debajo del cinturón. Tendrán que modificar la táctica de spam y quizás incluso gastar algo de dinero para comprar exploits de 0 o 1 día que no son baratos.

Consejo 3. No fije demasiadas esperanzas en las reglas de detección creadas por otra persona, porque debe verificar estas reglas en busca de falsos positivos y ajustarlas.

A medida que se dedica a crear reglas de detección, siempre existe la tentación de utilizar las que ya están disponibles. Sigma es un ejemplo de un repositorio libre. Es un formato de métodos de detección independiente de SIEM que le permite traducir reglas del lenguaje Sigma a ElasticSearch, así como reglas de Splunk o ArcSight. El repositorio incluye cientos de reglas. Parece una gran cosa, pero el diablo, como siempre, está en los detalles.

Echemos un vistazo a una de las reglas de detección de mimikatz. Esta regla detecta procesos que intentaron leer la memoria del proceso lsass.exe. Mimikatz hace esto cuando intenta obtener hashes NTLM y la regla identificará el malware.

Sin embargo, es fundamental para nosotros, expertos que no solo detectan sino que también responden a los incidentes, asegurarnos de que realmente se trata de un actor malicioso. Desafortunadamente, existen numerosos procesos legítimos que leen la memoria de lsass.exe (p. ej., algunas herramientas antivirus). Por lo tanto, en un escenario del mundo real, una regla como esa generará más falsos positivos que beneficios.

No estoy dispuesto a acusar a nadie en este sentido, todas las soluciones generan falsos positivos; es normal. Sin embargo, los especialistas en inteligencia de amenazas deben comprender que aún es necesario verificar y ajustar las reglas obtenidas de fuentes abiertas y cerradas.

Consejo 4. Verifique los nombres de dominio y las direcciones IP en busca de comportamiento malicioso no solo en el servidor proxy y el firewall, sino también en los registros del servidor DNS, y asegúrese de concentrarse tanto en los intentos de resolución exitosos como fallidos.

Los dominios maliciosos y las direcciones IP son los indicadores óptimos desde la perspectiva de la simplicidad de detección y la cantidad de dolor que inflige al atacante. Sin embargo, parecen fáciles de manejar solo a primera vista. Al menos, debería preguntarse dónde obtener el registro del dominio.

Si restringe su trabajo a verificar únicamente los registros del servidor proxy, puede pasar por alto el código malicioso que intenta consultar la red directamente o solicita un nombre de dominio inexistente generado con DGA, sin mencionar el túnel DNS; ninguno de estos se incluirá en la lista. registros de un servidor proxy corporativo. Los delincuentes también pueden usar servicios VPN por ahí con funciones avanzadas o crear túneles personalizados.

Consejo 5. Supervise o bloquee: decida cuál elegir solo después de averiguar qué tipo de indicador descubrió y reconocer las posibles consecuencias del bloqueo.

Todos los expertos en seguridad de TI se han enfrentado a un dilema no trivial: bloquear una amenaza o monitorear su comportamiento y comenzar a investigar una vez que activa las alertas. Algunas instrucciones lo alientan sin ambigüedades a elegir el bloqueo, pero a veces hacerlo es un error.

Si el indicador de compromiso es un nombre de dominio utilizado por un grupo APT, no lo bloquees – comience a monitorearlo en su lugar. Las tácticas actuales de desplegar ataques dirigidos presuponen la presencia de un canal de conexión secreto adicional como, por ejemplo, aplicaciones de rastreo celular que sólo puede ser descubierto a través de un análisis en profundidad. El bloqueo automático evitará que encuentres ese canal en este escenario; además, los adversarios se darán cuenta rápidamente de que te has dado cuenta de sus travesuras.

Por otro lado, si el IOC es un dominio utilizado por crypto-ransomware, debería estar bloqueado inmediatamente. Pero no olvide monitorear todos los intentos fallidos de consultar los dominios bloqueados: la configuración del codificador malicioso puede incluir varias URL del servidor de comando y control. Algunos de ellos pueden no estar en las fuentes y, por lo tanto, no serán bloqueados. Tarde o temprano, la infección se acercará a ellos para obtener la clave de cifrado que se utilizará instantáneamente para cifrar el host. La única forma confiable de asegurarse de que ha bloqueado todos los C&C es invertir la muestra.

Consejo 6. Verifique la relevancia de todos los indicadores nuevos antes de monitorearlos o bloquearlos

Tenga en cuenta que los datos de amenazas son generados por humanos que son propensos a cometer errores o por máquinas. algoritmos de aprendizaje que no son a prueba de errores cualquiera. He sido testigo de cómo diferentes proveedores de informes pagados sobre la actividad de los grupos APT agregan accidentalmente muestras legítimas a las listas de hashes MD5 maliciosos. Dado que incluso los informes de amenazas pagados contienen IOC de baja calidad, los obtenidos a través de inteligencia de código abierto definitivamente deben ser examinados para determinar su relevancia. Los analistas de TI no siempre verifican sus indicadores en busca de falsos positivos, lo que significa que el cliente tiene que hacer el trabajo de verificación por ellos.

Por ejemplo, si ha obtenido una dirección IP utilizada por una nueva iteración de TrickBot, antes de aprovecharlo en sus sistemas de detección, debe asegurarse de que no sea parte de un servicio de alojamiento o que emane de su IP. De lo contrario, tendrá dificultades para lidiar con numerosos falsos positivos cada vez que los usuarios que visitan un sitio que reside en esa plataforma de alojamiento van a páginas web completamente benignas.

Consejo 7. Automatice al máximo todos los flujos de trabajo de datos de amenazas. Comience con la automatización completa de la verificación de falsos positivos a través de una lista de advertencia mientras le indica al SIEM que monitoree los IOC que no desencadenan falsos positivos.

Para evitar una gran cantidad de falsos positivos relacionados con la inteligencia y obtenidos de fuentes abiertas, puede realizar una búsqueda preliminar de estos indicadores en las listas de advertencias. Para crear estas listas, puede utilizar los 1000 principales sitios web por tráfico, direcciones de subredes internas, así como los dominios utilizados por los principales proveedores de servicios como Google, Amazon AWS, MS Azure y otros. También es una gran idea implementar una solución que cambie dinámicamente las listas de advertencias que constan de los principales dominios/direcciones IP a los que han accedido los empleados de la empresa durante la semana o el mes pasado.

La creación de estas listas de advertencia puede ser problemática para un SOC de tamaño mediano, por lo que tiene sentido considerar la adopción de las denominadas plataformas de inteligencia de amenazas.

Consejo 8. Escanee toda la empresa en busca de indicadores de host, no solo los hosts conectados a SIEM

Como regla general, no todos los hosts de una empresa están conectados a SIEM. Por lo tanto, es imposible verificarlos en busca de un archivo malicioso con un nombre o ruta específicos utilizando solo la funcionalidad estándar de SIEM. Puede solucionar este problema de las siguientes maneras:

1. Uso Escáneres IOC como Loki. Puede usar SCCM para iniciarlo en todos los hosts empresariales y luego enviar los resultados a una carpeta de red compartida.
2. Utilice escáneres de vulnerabilidades. Algunos de ellos tienen modos de cumplimiento que le permiten verificar la red en busca de un archivo específico en una ruta específica.
3. Escriba un script de Powershell y ejecútelo a través de WinRM.

Como se mencionó anteriormente, este artículo no pretende ser una base de conocimiento integral sobre cómo hacer bien la inteligencia de amenazas. Sin embargo, a juzgar por nuestra experiencia, seguir estas reglas simples permitirá a los novatos evitar errores críticos al manejar diferentes indicadores de compromiso.