redsun-bluehammer-undefend-detection-pack

# Detecciones KQL de Microsoft Defender XDR para comportamientos de abuso de Defender relacionados con RedSun, BlueHammer, UnDefend y CVE-2026-33825.

La revisión de fuentes verificada el 2026-05-05 asigna BlueHammer a CVE-2026-33825. Los datos de plataformas afectadas de NVD y las notas de versión de Microsoft Defender identifican las versiones de la Plataforma Antimalware de Microsoft Defender anteriores a 4.18.26030.3011 como afectadas. No se verificó ningún CVE público de Microsoft ni parche de proveedor para RedSun o UnDefend durante esta revisión; Huntress informó que ambos permanecían sin parchear al 2026-04-20. Este repositorio detecta comportamientos y telemetría de Defender; no determina por sí mismo el cumplimiento de parches.

Línea Base de Investigación Verificada

• Última verificación: 2026-05-05
• BlueHammer: CVE-2026-33825; trate la Plataforma Antimalware de Defender 4.18.26030.3011 o posterior como la línea base mínima de parcheo verificada documentada en este repositorio.
• RedSun: no se verificó ningún CVE público de Microsoft ni parche de proveedor durante la revisión de fuentes del 2026-05-05. Mantenga este paquete centrado en el comportamiento.
• UnDefend: no se verificó ningún CVE público de Microsoft ni parche de proveedor durante la revisión de fuentes del 2026-05-05. Mantenga este paquete centrado en el comportamiento.
• Contexto de intrusión entre familias: Huntress documentó herramientas observadas compartidas, actividad posterior de BeigeBurrow y comandos de reconocimiento que son útiles para la caza y el enriquecimiento, no una prueba determinista por sí mismos.

Estructura del Repositorio

El repositorio utiliza carpetas de paquetes tanto para el contenido de detección como para el contenido de soporte. Las carpetas con KQL utilizan numeración secuencial que comienza en 01.

Patrón de Diseño de Consultas

Los cuatro paquetes de detección de cadena completa (RedSun, BlueHammer, UnDefend y CrossFamily) siguen la misma estructura:

1. 01_*_full_attack_chain.kql es la caza compuesta. Ejecuta toda la lógica de etapas junto y correlaciona evidencia en el mismo dispositivo dentro de una ventana de tiempo definida.
2. Los scripts independientes numerados aíslan etapas individuales. Están destinados a la resolución de problemas, análisis de línea base, creación de prototipos de detección personalizada y revisión de falsos positivos.
3. Se espera que los scripts independientes coincidan con el bloque de etapa correspondiente en la consulta de cadena completa, excepto por el orden final solo de visualización como | order by Timestamp desc.
4. Las consultas principales emiten campos normalizados como Stage, StageDescription, ProcessName, ProcessCommandLine, AccountName, Evidence, AdditionalContext y ReportRefs para que la salida entre etapas sea más fácil de revisar.
5. Los candidatos conservadores de detección programada, cuando existen, se encuentran bajo el subdirectorio production/ de cada paquete y son más estrictos que las consultas de caza de nivel superior.

Exposure es un paquete de soporte para informes de exposición basados en inventario, no una caza de comportamiento de cadena completa. ExternalTelemetry es solo documentación y no contiene KQL de endpoints.

Requisitos de Microsoft Defender XDR

Estas consultas están destinadas a Microsoft Defender XDR Advanced Hunting. Dependen de la disponibilidad de tablas y columnas de Defender for Endpoint y telemetría relacionada de Defender XDR.

Las tablas de uso común incluyen:

La telemetría no es uniforme en todos los inquilinos. Algunas primitivas de bajo nivel, especialmente oplock sin procesar, puntos de reanálisis, enlaces simbólicos del administrador de objetos y telemetría de consulta de servicios, pueden no aparecer como eventos explícitos. Por lo tanto, las consultas incluyen coincidencia oportunista contra ActionType y AdditionalFields donde Defender XDR expone esos detalles.

Flujo de Trabajo de Validación Recomendado

Antes del uso en producción, valide cada paquete de detección de cadena completa en este orden:

1. Ejecute cada consulta independiente en Advanced Hunting con una ventana de retroceso limitada.
2. Confirme que la consulta compila en su inquilino.
3. Revise el volumen de resultados sin procesar e identifique flujos de trabajo legítimos de software o administrativos que coincidan.
4. Agregue exclusiones locales para herramientas conocidas y buenas, cuentas de servicio, sistemas de implementación de software, productos de respaldo, herramientas EDR y escáneres de vulnerabilidades.
5. Ejecute la consulta 01_*_full_attack_chain.kql para el mismo paquete.
6. Compare los resultados de cadena completa contra los resultados independientes y confirme que las etapas correlacionadas tienen sentido operativo.
7. Exporte los resultados a CSV y revise rutas de procesos, líneas de comandos, cuentas, dispositivos y marcas de tiempo.
8. Solo después del ajuste debe convertir una consulta en una regla de detección personalizada programada.

El CI del repositorio también ejecuta .github/scripts/validate_repository.py para confirmar encabezados KQL, bloques de metadatos, equilibrio de delimitadores, numeración contigua, alineación de etapas independientes con cadena completa, cobertura de README, reglas de ubicación de producción y expectativas de trazabilidad de fuentes de IOC.

Guía de Implementación en Producción

Trate estas consultas como puntos de partida. Una implementación en producción debe incluir:

• Listas de permitidos específicas del inquilino para procesos y rutas conocidos y buenos.
• Umbrales separados para caza versus alerta.
• Ventanas de retroceso más estrechas para detecciones programadas cuando sea posible.
• Mapeo de severidad documentado y runbooks de triaje.
• Dispositivos de prueba o simulaciones de laboratorio para confirmar coincidencias esperadas.
• Control de cambios antes de habilitar la creación automática de incidentes.
• Revisión periódica después de actualizaciones de sensores de Defender o actualizaciones del sistema operativo.

No implemente todas las consultas principales como detecciones programadas de alta severidad sin ajuste. Algunas etapas detectan intencionalmente señales débiles u oportunistas que son útiles para la correlación pero ruidosas como alertas independientes.

Cuando un paquete proporciona una variante de consulta production/, trate ese archivo como el punto de partida para detecciones personalizadas programadas en lugar de la consulta de caza de nivel superior.

Notas de Rendimiento

Las consultas principales están diseñadas para evitar uniones amplias sin límites cuando sea posible. Utilizan filas de etapas normalizadas, proyección temprana y correlación por intervalos de tiempo. Sin embargo, el rendimiento aún depende de la escala del inquilino, la duración del retroceso y el volumen de eventos.

Si una consulta excede los límites de ejecución de Defender XDR:

• Reduzca Lookback.
• Ejecute primero las etapas independientes para identificar la etapa costosa.
• Agregue filtros más estrechos de proceso, ruta, cuenta o dispositivo.
• Mantenga solo las columnas proyectadas requeridas.
• Prefiera la salida de etapas resumida antes de unir o correlacionar.
• Use sugerencias de shuffle donde sean compatibles y donde se requiera agrupación de alta cardinalidad.

Interpretación de Resultados

Las consultas deben interpretarse como detecciones de patrones de comportamiento sospechosos, no como prueba de compromiso por sí mismas. Una coincidencia de cadena completa es más fuerte que una coincidencia de etapa independiente, pero cada resultado aún requiere revisión del analista.

Campos de revisión de alto valor:

• DeviceName y DeviceId
• FirstSeen y LastSeen
• StageCount
• Stages
• Processes
• ProcessCommandLines
• Accounts
• Evidence
• AdditionalContexts
• ReportRefs

Los analistas deben pivotar desde estos campos hacia la línea de tiempo del dispositivo de Defender, árbol de procesos, línea de tiempo de archivos, línea de tiempo de registro, evidencia de alertas y actividad de identidad.

Documentación de Carpetas

Cada carpeta de detección o soporte tiene su propio README con detalles técnicos específicos del paquete:

• RedSun/README.md
• BlueHammer/README.md
• UnDefend/README.md
• CrossFamily/README.md
• Exposure/README.md
• ExternalTelemetry/README.md

Utilice el README de la carpeta correspondiente antes de usar ese paquete o contenido de soporte. Describe el modelo de etapas, la telemetría esperada, los probables falsos positivos, los puntos de ajuste y las consideraciones de implementación.

Documentación del Repositorio

Archivos comunes del repositorio:

• CONTRIBUTING.md describe el alcance de las contribuciones, el estilo KQL, la validación y las expectativas de pull requests.
• CHANGELOG.md registra cambios notables.
• SOURCES.md asigna afirmaciones públicas, líneas base, mitigaciones y adiciones de IOC a sus fuentes de verificación.
• IOCS.md registra indicadores observados y sus límites de confianza y uso previstos.
• MITIGATIONS.md registra notas de mitigación y controles compensatorios respaldados por fuentes utilizados por este repositorio.
• ATTACK_MAPPING.md registra el mapeo de detección orientado a ATT&CK del repositorio.
• DEPLOYMENT_GUIDE.md registra la guía de implementación de laboratorio, piloto y producción, incluida la gobernanza de reversión y listas de permitidos.
• CODE_OF_CONDUCT.md define el comportamiento esperado para la colaboración.
• SECURITY.md describe cómo informar problemas del repositorio sensibles a la seguridad.
• SUPPORT.md explica qué información de soporte proporcionar al solicitar ayuda.
• DISCLAIMER.md repite la posición de sin garantía y uso bajo propio riesgo en un documento dedicado.
• LICENSE.md contiene los términos de la Licencia Apache 2.0 para este repositorio.
• NOTICE contiene la atribución del repositorio y el aviso de detección generada por IA.
• ROADMAP.md enumera mejoras futuras prácticas.
• .github/PULL_REQUEST_TEMPLATE.md proporciona indicaciones de revisión de pull requests.
• .github/ISSUE_TEMPLATE/*.md proporciona plantillas de problemas para errores, ajuste de detección y documentación.

Notas de Mantenimiento

Estos archivos KQL deben revalidarse siempre que:

• Microsoft cambie los esquemas de tablas de Defender XDR o los nombres de eventos.
• El comportamiento del sensor de Defender for Endpoint cambie.
• Las actualizaciones de características de Windows alteren el comportamiento de servicios, registro, Cloud Files, VSS o MRT.
• Nuevo software empresarial legítimo comience a tocar superficies relacionadas con Defender, VSS, Cloud Files o SAM.
• Los umbrales de consulta se cambien para alertas de producción.

Mantenga un registro de las exclusiones específicas del inquilino y por qué se agregaron. Evite exclusiones amplias que supriman rutas de escritura de usuario controladas por atacantes.