• Caza optimizada para DFIR
• Reglas YARA

¿Qué es Threat Hunting ?

La caza de amenazas (threat hunting) es un enfoque proactivo e iterativo para detectar actividades maliciosas dentro de la red o los sistemas de una organización que puedan haber evadido las medidas de seguridad automatizadas. A diferencia de las investigaciones reactivas desencadenadas por alertas de seguridad, la caza de amenazas se impulsa mediante comprobaciones basadas en inteligencia de amenazas (TI por sus siglas en inglés) y en hipótesis derivadas de un análisis sistemático y oportunista. Estas hipótesis 💡 ayudan a los cazadores a descubrir amenazas desconocidas, amenazas potenciales o amenazas conocidas que hayan podido evadir las detecciones de seguridad, así como vulnerabilidades o indicadores de compromiso (IoCs) que los sistemas automatizados podrían pasar por alto o excluir. El proceso también se centra en identificar precursores de alertas/dashboards y en mejorar los flujos de trabajo del SOC y del triaje, al tiempo que contribuye a la gestión del inventario de activos fantasma (shadow assets) y escala eventos de fidelidad baja/media que requieren una investigación adicional. El objetivo principal es identificar las tácticas, técnicas y procedimientos (TTPs) utilizados por los actores de amenazas, mejorando la capacidad de la organización para detectar y mitigar proactivamente posibles ataques.

Ventajas del Threat Hunting:

• 🔍 Identifica brechas de visibilidad
  • Detecta áreas donde la monitorización y la detección son insuficientes, abordando puntos ciegos en la red o los sistemas para mitigar amenazas ocultas.
• 🛠️ Cubre brechas de detección
  • Busca de forma proactiva anomalías, precursores y TTPs que pueden no generar alertas
• ⚙️ Mejora la eficiencia del SOC
  • Integra los conocimientos del threat hunting en los flujos de trabajo del SOC para descubrir eventos que las detecciones estáticas podrían pasar por alto. Al reducir los falsos positivos y escalar eventos ignorados, permite a los analistas del SOC centrarse en amenazas críticas y refinar la lógica de detección para uso futuro.
• 🚀 Mejora la detección de amenazas y apoya la mejora continua
  • Identifica amenazas avanzadas, desconocidas u ocultas que evaden los sistemas de detección automatizados y retroalimenta el proceso del SOC con datos valiosos, mejorando las herramientas, la formación y las capacidades de detección futuras
• 🛡️ Reduce la superficie de ataque
  • Descubre sistemas, aplicaciones y TI en la sombra (shadow IT) no gestionados o no autorizados dentro de la red, permitiendo a las organizaciones abordar los puntos ciegos de seguridad y reducir la exposición a posibles amenazas.

Vinculando el Threat Hunting con los servicios principales

Ciclo de vida del Threat Hunting en las operaciones del SOC

Mi sugerencia de proceso para organizar sesiones de threat hunting parcialmente automatizadas y mantener reglas de detección de alta calidad dentro de un SOC

Nivel de madurez de la detección

Los equipos del SOC se centran en implementar detecciones de alta fidelidad en todos los niveles de la Pirámide de Madurez de Detección, apuntando a amenazas conocidas con mínimos falsos positivos. El threat hunting complementa esto abordando amenazas desconocidas, TTPs avanzados y anomalías propensas a altas tasas de falsos positivos, cubriendo brechas y mejorando la cobertura de detección más allá de las capacidades estándar del SOC.

Lista de verificación de Threat Hunting - Áreas clave de enfoque para la recopilación de inteligencia

Ejemplo de metodología de Threat Hunting dirigido

Idealmente, cada sesión de threat hunting debería tener objetivos claros. Este diagrama de flujo proporciona un enfoque estructurado para guiar tu proceso, desde la preparación y la investigación hasta recomendaciones accionables.

🎯 Lista de palabras clave para sesiones de ThreatHunting

Archivos

• ThreatHunting-Keywords
• Keywords de herramientas greyware
• Keywords de herramientas ofensivas
• Keywords de firmas de proveedores
• Herramientas individuales (un archivo csv por herramienta)
• Solo las keywords
• Solo las keywords regex
• Solo las keywords regex (mejor rendimiento)
• Script de Powershell para cazar en archivos
• Reglas Yara
• Reglas Sigma

Para el equipo azul:

Las listas de ThreatHunting-Keywords pueden ser valiosas para los Threat Hunters, los equipos SOC y CERT para análisis estático en SIEM, ya que ayudan a identificar actores de amenazas (o redteamers 😆) que utilizan configuraciones predeterminadas de herramientas de explotación reconocidas en los logs. Se diferencia de los feeds de IoC por su relevancia perdurable: los keywords aquí no tienen 'fechas de caducidad' y pueden detectar amenazas años después de su inclusión; son flexibles, aceptan comodines y coincidencias sin distinción de mayúsculas/minúsculas, y se centran únicamente en keywords predeterminados.

Diseñada principalmente para Threat Hunting, esta lista puede ser útil en escenarios complejos. Ya sea que tengas acceso a un SIEM que no administras, con datos sin parsear, o que formes parte de un equipo SOC con un SIEM bien gestionado, los ejemplos proporcionados aquí pueden acelerar el proceso de detección de actividad maliciosa sin necesidad de parsear nada. Si tus logs ya están parseados, esta lista se puede usar para hacer coincidir campos dentro de tus datos, convirtiéndose potencialmente en una regla de detección según la categoría de tipo de keyword que selecciones, siempre que la tasa de falsos positivos sea suficientemente baja.

⚠️ No todo puede añadirse en esta lista; no hacemos detecciones complejas de comportamiento aquí, solo detecciones simples de keywords en campos o logs sin procesar, destinadas a detectar configuraciones predeterminadas

⚠️ Muchas herramientas de la lista tienen reglas de detección dedicadas, correlacionando eventos con umbrales y relaciones de proceso únicas... no cubriremos todas las detecciones posibles para una herramienta aquí, solo detecciones de keywords

Si formas parte de un Centro de Operaciones de Seguridad (SOC) y gestionas cientos de reglas de detección que dependen únicamente de detecciones simples de keywords sin correlación de campos o eventos, considera replantear tu enfoque. En mi opinión, estas no deberían constituir reglas de detección individuales. En su lugar, podrían adaptarse mejor a una lista consolidada como esta, aunque la implementación podría ser más desafiante si no usas una plataforma como Splunk.

Este enfoque fomenta la creación de reglas de alta calidad y con propósito, manteniendo tus detecciones simples de keywords en campos organizadas y manejables en un solo lugar. ¿El resultado final? Una regla de detección integral que las cubre todas. Esto agiliza tu proceso y optimiza tus capacidades de detección.

Para los respondedores de incidentes, puedes usar esta lista durante tu investigación en logs sin procesar o archivos para identificar rápidamente herramientas de explotación conocidas con las reglas YARA Reglas YARA, un script de Powershell o ingiriendo rápidamente tus logs en Splunk con Splunk4DFIR

Para el equipo rojo:

Para evadir la detección por detección simple de keywords, es fundamental recompilar y renombrar todas las cadenas personalizadas, nombres de clases o funciones, nombres de variables, nombres de argumentos, nombres de ejecutables, user-agents predeterminados, certificados o cualquier otra cadena que pueda asociarse potencialmente con las herramientas que estés utilizando durante tu operación. Emplea los nombres más comunes para todo, a fin de mezclarte con el tráfico normal. Los scripts ubicados aquí pueden ayudarte a identificar algunos de estos.

Sin embargo, si estás desarrollando "herramientas de red team" públicas, considera ayudar al equipo azul utilizando nombres distintivos. Emplea una configuración predeterminada con un puerto exótico, certificados personalizados, user-agents únicos, nombres de funciones y argumentos específicos que no sean comunes. Esto ayuda a crear una firma clara que pueda usarse para detecciones simples de keywords, de modo que el equipo azul pueda al menos detectar fácilmente a los script kiddies.

Contenido del archivo de Threat Hunting Keywords:

• Encabezado: keyword,metadata_keyword_type,metadata_tool,metadata_description,metadata_tool_techniques,metadata_tool_tactics,metadata_malwares_name,metadata_groups_name,metadata_category,metadata_link,metadata_enable_endpoint_detection,metadata_enable_proxy_detection,metadata_tags,metadata_comment,metadata_severity_score,metadata_popularity_score,metadata_github_stars,metadata_github_forks,metadata_github_created_at,metadata_github_updated_at

• keyword: Las entradas en esta columna representan keywords no sensibles a mayúsculas utilizados para Threat Hunting. Estos keywords son flexibles y permiten el uso de comodines para ampliar o reducir tus parámetros de búsqueda según sea necesario.

• metadata_keyword_regex: Las entradas en esta columna representan la detección mediante patrón regex del keyword; estos patrones están refinados para ofrecer capacidades de detección precisas, adecuadas para su uso con YARA, ripgrep o herramientas de detección similares.

• metadata_keyword_type: Tipo de los keywords. Actualmente hay tres tipos:

  • 🛠️ offensive tool keyword: Estos keywords se relacionan con herramientas ofensivas o muestran una alta confianza de intención maliciosa. Es crucial que estos términos sean relevantes y fiables para detectar posibles amenazas (baja tasa de falsos positivos)
  • 🛠️ greyware tool keyword: Los keywords en esta categoría corresponden a herramientas 'legítimas' que son abusadas por actores maliciosos. Dado que estas herramientas también tienen usos legítimos, el potencial de falsos positivos es inherentemente mayor. Es importante interpretar estos resultados con la comprensión de que no todas las detecciones pueden significar actividad maliciosa.
  • 🛠️ signature keyword: Estos keywords pueden no asociarse directamente con herramientas, pero pueden incluir nombres de firmas de productos de seguridad, cadenas específicas o palabras significativas en la detección de amenazas.

• metadata_tool: Nombre de la herramienta que queremos detectar

• metadata_description: descripción de la herramienta que queremos detectar

• metadata_tool_techniques: técnicas MITRE relacionadas con la herramienta que queremos detectar

• metadata_tool_tactics: tácticas MITRE relacionadas con la herramienta que queremos detectar

• metadata_malwares_name: nombres de variantes de malware que utilizan la herramienta en cuestión

• metadata_groups_name: nombres de los grupos de actores de amenazas asociados con la herramienta

• metadata_category: nombre de la categoría global de la herramienta. Esto puede cambiar más adelante y las sugerencias son bienvenidas.

• metadata_link: enlace a la herramienta (código fuente, artículos, muestras, blog ...)

• metadata_enable_endpoint_detection: Campo que indica si el keyword puede emplearse eficazmente en búsquedas en logs de endpoint. Esto incluye, entre otros, registros de eventos de Windows, EDR, logs de PowerShell, auditd, sesiones bastión, Sysmon o cualquier fuente de datos que contenga campos de actividad de procesos y archivos.

  • Si puedes buscar el keyword en logs de endpoint, el valor es 1 (habilitado).
  • Si el keyword no es relevante para logs de endpoint, el valor es 0 (deshabilitado).

• metadata_enable_proxy_detection: Campo que indica la aplicabilidad del keyword para búsquedas dentro de logs de red (Proxy, logs DNS o cualquier dato con consultas y URL originadas desde la red interna)

  • Si puedes buscar el keyword en logs de actividad de red, el valor es 1 (habilitado).
  • Si el keyword no es relevante para logs de actividad de red, el valor es 0 (deshabilitado).

• metadata_popularity_score: puntuación del 1 al 10 (de baja a alta popularidad)

• metadata_severity_score: puntuación del 1 al 10 (de baja a alta severidad)

• metadata_tags: etiquetas para identificar artefactos específicos; varias etiquetas pueden estar asociadas a un keyword. Cuando algunos de los artefactos específicos no pueden añadirse a las listas sin más contexto de detección, se añaden en otras listas increíbles para_detección

• metadata_comment: Este campo puede contener un comentario útil añadido para el keyword.

• metadata_github_stars: Número de estrellas en el proyecto de GitHub (si la herramienta está en GitHub; si está en otro lugar, el valor es N/A). Esto se usa para calcular la puntuación de popularidad.

• metadata_github_forks: Número de forks en el proyecto de GitHub (si la herramienta está en GitHub; si está en otro lugar, el valor es N/A). Puede usarse para estadísticas de dashboard de las herramientas más utilizadas.

• metadata_github_created_at: Fecha de creación del proyecto de GitHub (si la herramienta está en GitHub; si está en otro lugar, el valor es N/A). Puede usarse para estadísticas de dashboard.

• metadata_github_updated_at: Fecha de última actualización del proyecto de GitHub (si la herramienta está en GitHub; si está en otro lugar, el valor es N/A). Puede usarse para rastrear actualizaciones importantes de herramientas ofensivas y ajustar las detecciones de keywords.

Usa la lista para cazar con Splunk:

• sube la lista threathunting-keywords.csv a Splunk

• crea una definición de lookup llamada threathunting-keywords para el lookup threathunting-keywords.csv

  • en las opciones avanzadas, añade el tipo de coincidencia (Match type) WILDCARD(keyword) y asegúrate de que Case sensitive match no esté marcado

  

transforms.conf``` [threathunting-keywords] batch_index_query = 0 case_sensitive_match = 0 filename = threathunting-keywords.csv match_type = WILDCARD(keyword)

Envía el trabajo a segundo plano y conserva el ID del trabajo.

• myendpointslogs es una macro que buscará en todos los registros de tus endpoints; pueden ser registros de Windows, telemetría EDR, sysmon, auditd, sesiones de bastion, registros de ejecución de PowerShell o cualquier otro registro que supervise la actividad de procesos o de archivos. (si no usas la macro, puedes reemplazarla por tu índice, etiqueta o datamodel)
  • Incorporé intencionalmente una macro en los ejemplos para demostrar que la exploración inicial se puede realizar con cualquier método que se adapte a las necesidades, ya sea un modelo de datos, tstats, etiquetas, índice/tipo de origen. Si bien tstats junto con un datamodel suele ser la vía más rápida, filtra con el comando TERM() para búsquedas específicas antes del |lookup si es necesario
• | lookup esto es muy importante; para lookups grandes como este, usa siempre |lookup en lugar de |inputlookup. |lookup utilizará la lookup distribuida a los indexadores cuando el bundle se replica, pero |inputlookup enviará a los indexadores la búsqueda con todo el contenido de la lookup cada vez. Al usar |lookup ganamos mucho rendimiento aquí (esta búsqueda se ejecutará durante horas en entornos grandes, así que es mejor optimizarla).
• ... keyword as _raw OUTPUT keyword as keyword_detection esta es la parte donde compararemos el campo llamado _raw con el campo keyword en nuestra lookup; en Splunk, _raw es el registro sin procesar (nuestro caso de uso). Cuando una keyword coincide, el campo keyword_detection mostrará la keyword de la lookup que coincidió con el campo (_raw) aquí.
• | search metadata_description!="" AND metadata_enable_endpoint_detection=1 aquí nos centramos solo en los registros de endpoints, por lo que añadimos metadata_enable_endpoint_detection=1 para que coincida únicamente con las keywords relevantes para registros de endpoints y metadata_description!="" para tener solo las keywords coincidentes.
• | stats count earliest(_time) as firsttime latest(_time) as lasttime values(_raw) as raw by metadata_keyword_type keyword_detection index sourcetype aquí hice un filtro rápido sin todos los campos de la lookup para el ejemplo (pero también puedes añadirlos si quieres tener más posibilidades de exclusión); esto nos permite hacernos una idea fácilmente de qué keyword está coincidiendo mucho, para poder excluir fácilmente la categoría o la herramienta si tenemos demasiados falsos positivos.
• Cuando mi búsqueda termina, ¿cómo puedo analizar los resultados? Tendrás los registros sin procesar ordenados por keywords y tipos de keyword; usando |loadjob myjobid podemos manipular la salida con los registros relevantes sin volver a buscar en todos los registros.

Filtrar el resultado``` | loadjob 1684146257.1495958 | search NOT (keyword_detection IN ("fixme","fixme","fixme")) NOT (metadata_keyword_type IN ("fixme","fixme")) NOT (raw IN ("fixme","fixme","fixme"))

Añadí un metadata_keyword_type="offensive tool keyword" para centrarme solo en herramientas ofensivas que estoy seguro de que son utilizadas por actores maliciosos

• O filtrar después de nuestra búsqueda inicial (para ganar mucho tiempo):``` | loadjob 1684146257.1495958 | search metadata_keyword_type="offensive tool keyword"

Ahora es lo mismo que la primera búsqueda, pero cambié la fuente de datos por mynetworklogs y añadí metadata_enable_proxy_detection=1 para que coincida con las palabras clave relevantes para networklogs (mejor tener registros de proxy y DNS para esto)

Busca las palabras clave en otros campos 🙂 (url,process,commandline,query...):

Coincidir solo en el campo url:```

mynetworklogs url=* | lookup threathunting-keywords keyword as url OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment | search metadata_description!="" AND metadata_enable_proxy_detection=1 | stats count earliest(_time) as firsttime latest(_time) as lasttime values(url) as url by src_ip metadata_keyword_type keyword_detection index sourcetype | convert ctime(*time)

Coincidir en varios campos al mismo tiempo, ejemplo para registros de endpoint:```

myendpointslogs | eval myfields=mvappend(service, process, process_command, parent_process, parent_process_command, grand_parent_process, grand_parent_process_command, file_path, file_name) | lookup threathunting-keywords keyword as myfields OUTPUT keyword as keyword_detection metadata_keyword_type metadata_tool metadata_description metadata_tool_techniques metadata_tool_tactics metadata_malwares_name metadata_groups_name metadata_category metadata_link metadata_enable_endpoint_detection metadata_enable_proxy_detection metadata_comment | search metadata_description!="" AND metadata_enable_endpoint_detection=1 | stats count earliest(_time) as firsttime latest(_time) as lasttime values(process) values(service) values(process_command) values(file_name) values(file_path) values(parent_process) values(parent_process_command) values(grand_parent_process) values(grand_parent_process_command) by metadata_keyword_type keyword_detection index sourcetype | convert ctime(*time)

El resultado de la búsqueda estará en result_search.log en el mismo directorio que el script.

Mejor opción para archivos muy grandes (en linux):

todo

Caza de malware en archivos solo con powershell y la lista 'only_keywords.txt ' (más lento no recomendado)

En powershell es mucho más lento, pero si aún quieres hacerlo de esta manera, puedes usar el script de abajo; te indicará el número de línea coincidente y la palabra clave correspondiente:

powershell.exe -ep Bypass -File .\hunt_keywords_windows.ps1 -k .\only_keywords.txt -f .\EvtxECmd_Output.csv

Matriz de herramientas

Paneles de Splunk (esto es solo un ejemplo; se puede aplicar una amplia variedad de filtros utilizando los campos disponibles en el archivo):

Grupos de actores de amenazas por herramientas en este proyecto

ejemplo de panel XML de Splunk:

🤝 Contribuciones

¡Las contribuciones, los problemas y las solicitudes de funciones son bienvenidos!

Si quieres que añada una herramienta a la lista, crea un issue con esta plantilla:

Propón cambios a la lista con un PR (proporciona comentarios sobre falsos positivos, muestra de registros si puedes), si una palabra clave está generando demasiados falsos positivos en demasiados entornos, podemos eliminarla)

Decidiré si vale la pena añadir una herramienta a la lista. Las herramientas ampliamente utilizadas y reconocidas por la comunidad tienen más probabilidades de incluirse que las oscuras o nuevas.