Los avances, desarrollos y novedades en cuanto a soluciones IT traen consigo un reto asociado a las consecuencias y peligros emergentes por parte del paradigma de la automatización y sofisticación de procesos, con la premisa de “ahorrar tiempo y costos para priorizar aspectos más críticos y decisivos”, sin embargo, los ataques son cada vez más sofisticados, automatizados y devastadores, mientras que el margen de error para los defensores se ha reducido drásticamente. De acuerdo con Prophet (2025) el tiempo medio para que un operador de ransomware alcance sus objetivos es de apenas 24 horas desde el compromiso inicial. ¿Cuántas empresas podrían asegurar que sus equipos y soluciones de seguridad adoptadas estarían preparados para detectar y responder coordinadamente a esta clase de incidentes?

MITRE ATT&CK: Un marco de referencia, tanto para aficionados como para profesionales.
Bajo el anterior contexto, la mejor solución radica en coordinación de estrategias bajo un panorama de común entendimiento que sea lo suficientemente amplio como para segmentar los incidentes en fases. Es así como MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) se ha consolidado como el marco de referencia global para comprender el comportamiento adversario. ATT&CK es una base de conocimiento pública que documenta las tácticas, técnicas y procedimientos (TTPs) que los adversarios emplean en ciberataques reales, basándose en observaciones del mundo real. Su estructura matricial organiza cerca de 194 técnicas de comportamiento comúnmente asociadas con actores de amenazas antes de la exfiltración de datos y el impacto, creando un lenguaje común que permite a los equipos de defensa comunicarse de manera efectiva tanto internamente como con la comunidad global de ciberseguridad.
Desde un aspecto defensivo, este marco normativo se consolida como una brújula en las labores posteriores a la identificación de amenazas. Por ejemplo, para un equipo blue o un SOC (Security Operations Center), la relevancia de ATT&CK es múltiple:
- Permite mapear detecciones existentes contra técnicas adversarias conocidas, revelando brechas en la cobertura de defensa.
- Facilita la priorización de inversiones en telemetría y controles de seguridad al identificar qué técnicas representan mayor riesgo para la organización específica.
- Proporciona un marco para validar la efectividad de las detecciones mediante ejercicios de emulación adversaria. Finalmente, permite benchmarking contra estándares de la industria, demostrando el valor del SOC ante stakeholders con métricas cuantificables.
Decisiones basadas en una telemetría reducida: prioridades y recomendaciones
Mas allá de la concepción normativa e investigativa que ofrece MITRE, los grandes retos de telemetría pueden recaer en términos de costes de operación para aquellas empresas que aunque están tratando de dar el paso siguiente en implementación de mayores controles de ciberseguridad, no pueden abarcar organizadamente el monitoreo de sus verdaderos activos críticos, pues la realidad es que alcanzar 100% de cobertura de detección no solo es costoso, sino que resultaría operacionalmente insostenible por el volumen de alertas y la carga de mantenimiento que implicaría.
Con base en la anterior afirmación, la telemetría de estas empresas debería estar enfocada en función de restricciones operacionales reales. Estas limitaciones pueden incluir costos de licenciamiento por volumen de datos ingeridos, capacidad de almacenamiento, ancho de banda de red para transferencia de logs, complejidad de configuración en sistemas legacy, o simplemente la madurez técnica del equipo.
La Cybersecurity and Infrastructure Security Agency (CISA), en colaboración con el FBI, NSA y múltiples agencias internacionales, publicó en 2024 la guía “Best Practices for Event Logging and Threat Detection“, que establece un conjunto mínimo de eventos críticos que toda organización debería capturar. A raíz de esta publicación la guía publicada prioriza los siguientes factores:
- Vigilancia sobre políticas de loggin aprobadas por la empresa
- Generación de estrategias de recopilación y correlación centrada en los tipos de logs, p.e syslogs.
- Enfoque en el almacenamiento y gestión de los logs con base en triada CIA (Confidencialidad, Integridad, Disponibilidad)
- Esquema de detecciones y modelos de comportamiento para amenazas relevantes
Cuando MITRE es abordada con base en las anteriores consideraciones, se espera que los eventos dentro de la telemetría puedan ser explicados en esquemas como el que se muestra a continuación:
| Plataforma | Tipo de Evento Crítico | Ejemplos de Datos Específicos | MITRE ATT&CK TTP | Nivel de Prioridad |
| Endpoint (Windows/Linux/macOS) | Login exitoso/fallido | Event ID 4624, 4625 (Windows); auth.log (Linux) | Credential Access (T1110), Initial Access (T1078) | Alta |
| Endpoint | Ejecución de PowerShell/Script | Event ID 4104, 4103 (Windows); process logs | Execution (T1059.001), Defense Evasion (T1027) | Alta |
| Endpoint | Creación/modificación de servicio | Event ID 7045, 4697 (Windows); systemd logs | Persistence (T1543), Privilege Escalation | Alta |
| Endpoint | Acceso a credenciales (LSASS) | Event ID 10 (Sysmon); memory access logs | Credential Access (T1003.001) | Alta |
| Identity/AD | Modificación de grupos privilegiados | Event ID 4728, 4732, 4756 (Windows) | Privilege Escalation, Persistence | Alta |
| Identity/AD | Cambios en políticas de Kerberos | Event ID 4713, 4716 | Credential Access (T1558) | Media |
| Cloud (AWS/Azure/GCP) | Cambios en IAM/permisos | CloudTrail (AWS), Azure Activity Log | Privilege Escalation, Persistence | Alta |
| Cloud | Creación/modificación de recursos | API calls para EC2, Storage, Compute | Initial Access, Resource Development | Media |
| Network | Tráfico DNS inusual | DNS query logs, recursive queries | Command & Control (T1071.004), Exfiltration | Media |
| Network | Conexiones SMB/RDP remotas | Network flow logs, firewall logs | Lateral Movement (T1021.001, T1021.002) | Alta |
| Application | Acceso fallido a recursos sensibles | Application-specific authentication logs | Discovery, Collection | Media |
Hacia la mejor continua: evaluación, retroalimentación y los ajustes necesarios.
Una vez los elementos del ejemplo anterior sean sometidos a una evaluación por parte de los equipos de seguridad, vale abordar las siguientes preguntas con base en un checklist de seguimiento:
Active Directory e Identity:
- ¿Recibimos logs de autenticación (exitosos y fallidos) de todos los controladores de dominio?
- ¿Tenemos visibilidad sobre cambios en grupos administrativos?
- ¿Capturamos eventos de uso de Kerberos y NTLM?
Endpoints:
- ¿Qué porcentaje de endpoints tiene EDR o agentes de logging instalados?
- ¿Recolectamos logs de ejecución de procesos con línea de comandos completa?
- ¿Tenemos visibilidad de PowerShell con Event ID 4104 (Script Block Logging)?
Cloud:
- ¿Está habilitado CloudTrail/Azure Activity Log/Cloud Audit Logs en todas las cuentas?
- ¿Recolectamos eventos de cambios en IAM y configuración de red?
- ¿Monitoreamos la creación de recursos fuera de patrones normales?
Networking:
- ¿Tenemos logs de firewall/proxy con suficiente granularidad?
- ¿Capturamos flujos de red (NetFlow/IPFIX) para análisis de tráfico lateral?
- ¿Monitoreamos tráfico DNS y conexiones externas?
Este ataque hasta la fecha ha sido considerado uno de los incidentes de cadena de suministro más significativos de 2025, no solo por la cantidad de paquetes afectados, sino por la interrupción temporal de miles de pipelines de CI/CD que dependían de ellos. Lo que hace especialmente peligroso este ataque es su capacidad de autopropagación. Una vez que un paquete quedaba comprometido, el malware incluía una función que automáticamente descargaba, modificaba e inyectaba código malicioso en otros paquetes mantenidos por la misma cuenta vulnerada. En otras palabras, cada paquete infectado se convertía en un nuevo punto de distribución, creando un efecto dominó.
¿Cómo mapear desde el marco MITRE un entorno que necesita ajustar reglas y darles más utilidad?
La matriz ATT&CK organiza el comportamiento adversario en dos dimensiones principales: tácticas y técnicas. Las tácticas representan los objetivos tácticos del adversario durante un ataque (el por qué), mientras que Las técnicas son los métodos específicos que los adversarios emplean para alcanzar esos objetivos tácticos (el cómo). Cada técnica puede mapearse a múltiples tácticas; por ejemplo, Process Injection (T1055) se alinea tanto con Defense Evasion como con Privilege Escalation.
Debido a que no todos los comportamientos y ataques pueden ser relevantes para una empresa en el marco de su actividad económica, infraestructura y demás alcances, se sugiere que los equipos de seguridad se centren en técnicas y no exclusivamente en IoC (Indicadores de Compromiso) ya que esto último es fácilmente adaptable para cada campaña maliciosa. Se sugiere revisar los siguientes pasos:
1. Seleccionar un subconjunto de técnicas relevantes
No todas las 194+ técnicas de ATT&CK son igualmente relevantes para toda organización. La priorización debe basarse en:
- Riesgo específico del negocio y activos críticos
- Threat Intelligence relevante al sector
- Plataformas de alta prioridad
- Frecuencia de uso por adversarios
- Capacidad de detección existente
2. Determinar telemetría necesaria por técnica
Para cada técnica priorizada, el equipo debe identificar qué fuentes de datos y componentes específicos permitirían detectarla. Otro ejemplo se presenta a continuación:
T1021.002 – Remote Services: SMB/Windows Admin Shares
Data Sources necesarios:
- Logon Session: Logon Session Creation → Event ID 4624 (logon type 3)
- Network Share: Network Share Access → Event ID 5140, 5145
- File: File Creation → creación de archivos en shares remotos (\C$, \ADMIN$)
- Process: Process Creation → ejecución remota de procesos vía PsExec u otros
Telemetría específica:
- Windows Security Event ID 4624 (logon tipo 3, especialmente con elevated privileges)
- Event ID 4672 (Special Privileges Assigned)
- Event ID 5140/5145 (network share access)
- Sysmon Event ID 3 (Network Connection) para tráfico SMB (puerto 445)
- Sysmon Event ID 11 (File Creation) en rutas de shares administrativos
3. Traducir telemetría en reglas de detección
Luego de las labores de telemetría, pasamos al siguiente punto que consiste en construir la lógica de detección en formato ejecutable. Un ejemplo de formato es las reglas SIGMA, el cual es un estándar abierto para escribir reglas de detección de manera genérica, que pueden luego traducirse a múltiples backends (Splunk, Elastic, QRadar, Microsoft Sentinel, etc.). Si abordamos la telemetría desde la traducción a una regla sigma podríamos visualizar un esquema de ejemplo como el siguiente, el cual describe comportamiento de descarga y ejecución PowerShell con cradle:
| title: Suspicious PowerShell Download Cradle |
id: 1f49f2ab-26bc-48b3-96cc-dcffbc93eadf status: stable description: Detects PowerShell download cradles using Invoke-WebRequest or WebClient references: – https://attack.mitre.org/techniques/T1059/001/ author: Blue Team date: 2025-10-29 tags: – attack.execution – attack.t1059.001 – attack.command_and_control – attack.t1071.001 logsource: product: windows category: process_creation detection: selection_powershell: Image|endswith: – ‘\powershell.exe’ – ‘\pwsh.exe’ CommandLine|contains: – ‘Invoke-WebRequest’ – ‘iwr ‘ – ‘wget ‘ – ‘curl ‘ – ‘Net.WebClient’ – ‘DownloadString’ – ‘DownloadFile’ selection_scriptblock: EventID: 4104 ScriptBlockText|contains: – ‘Invoke-WebRequest’ – ‘[Net.WebClient]’ – ‘DownloadString’ condition: selection_powershell or selection_scriptblock falsepositives: – Legitimate administrative scripts – Software deployment tools level: high |
Finalmente, esta regla puede ser convertida a una consulta o query más concreta y aplicable en otras herramientas tipo SIEM, lo cual incluye integraciones nativas. Este es un ejemplo de la regla SIGMA adoptada a query en Splunk:

Imagen 1. Query equivalente a regla SIGMA, la cual es adaptada para entorno Splunk SIEM
4. Clasificación por prioridad:
Ahora bien, no todas las alertas tienen el mismo impacto y urgencia operacional, por ello se sugiere adoptar el triage a los siguientes eventos:
| ALTA | MEDIA | BAJA |
| • Técnicas de impacto crítico (ransomware, exfiltración masiva) • Técnicas en fases avanzadas del kill chain (Lateral Movement, Exfiltration) • Técnicas con visibilidad completa (Visibility_score ≥ 3 según DeTT&CT) • Técnicas frecuentemente usadas por adversarios (Attacker_score ≥ 75) | • Técnicas en fases tempranas (Discovery, algunos Execution) • Técnicas con visibilidad parcial pero detectable (1 ≤ Visibility_score < 3) • Técnicas de frecuencia moderada | • Técnicas raras o muy específicas a ciertos adversarios • Técnicas que requieren telemetría actualmente no disponible • Técnicas con altas tasas de falsos positivos sin contexto adicional |
Esquema de responsabilidades y consideración de métricas esenciales
Un programa de detección basado en ATT&CK requiere claridad organizacional sobre quién hace qué. Sin roles definidos, las iniciativas se estancan cuando personas clave se van o las prioridades cambian. Las principales organizaciones que asumen la tarea de suministrar servicios SOC incluyen roles con responsabilidades bien definidas:

Debido a que la efectividad operacional debe ser considerada también empleando herramientas cuantitativas, es útil adaptar reglas a procesos de mejora continua y cobertura. Si las métricas son abordadas desde el marco MITRE y presentadas de acuerdo con las tácticas, técnicas y procedimientos entonces resulta más eficiente la medición con las siguientes métricas:
- Técnicas cubiertas (Detection Coverage):

- Cobertura por táctica: Porcentaje de técnicas cubiertas dentro de cada táctica (Initial Access, Execution, Persistence etc.). Permite identificar brechas sistémicas
- Cobertura por plataforma: Separar cobertura para Windows, Linux, Cloud, macOS.
- Número de detecciones activas: Total de reglas/alertas en producción.
- Mean Time to Detect (MTTD): Promedio de tiempo desde ocurrencia de técnica hasta alerta generada.
- Mean Time to Investigate (MTTI): Promedio de tiempo desde alerta hasta determinación de verdadero/falso positivo.
- Mean Time to Remediate (MTTR): Promedio de tiempo desde detección hasta contención completa
- False Positive Rate por regla:

- Coverage delta: Incremento de técnicas cubiertas comparado con trimestre anterior
Conclusiones e invitación al marco normativo
Implementar un programa de detección basado en MITRE ATT&CK con telemetría limitada no es un proyecto de 6 meses con “fecha de fin”, sino un ciclo operacional continuo que evoluciona con las amenazas y la organización. Los pasos clave abordados incluyeron:
1. Establecer telemetría mínima viable siguiendo guías sugeridas
2. Mapear cobertura ATT&CK
3. Priorizar técnicas basándose en riesgo del negocio, frecuencia de uso por adversarios, y capacidad de detección existente.
4. Traducir técnicas en detecciones usando formatos portables como Sigma rules
5. Validar detecciones sistemáticamente.
6. Rastrear métricas de cobertura (Detection Coverage), operación (MTTD, FPR), y mejora continua para demostrar valor y guiar inversiones.
Si tu organización aún no ha mapeado su cobertura ATT&CK, el mejor momento para empezar es ahora. En 7 Way Security contamos con capacidad y experiencia en ciberseguridad para brindar un enfoque transversal y adaptativo, toda vez que comprendemos la importancia de garantizar acompañamiento a quienes han decidido dar el gran salto hacia la formación y estandarización de esfuerzos asociados a la seguridad de la información.
Referencias:
- Bhatt, U. (2025, June 18). Blue team defense in light of the latest MITRE ATT&CK updates. LinkedIn. https://www.linkedin.com/pulse/blue-team-defense-light-latest-mitre-attck-updates-umang-bhatt-ys9lf
- Torq. (2025, October 22). Automating MITRE ATT&CK analysis with Torq Socrates. Torq Blog. https://torq.io/blog/automate-mitre-attack-analysis/
- Red Canary. (2024, July 29). Mapping detectors to MITRE ATT&CK techniques. Red Canary Blog. https://redcanary.com/blog/security-operations/mapping-detectors-to-mitre-attack-techniques/
- HIPAA Journal. (2024, August 21). CISA & partners issue guidance & best practices for event logging and threat detection. HIPAA Journal. https://www.hipaajournal.com/guidance-best-practices-for-event-logging-threat-detection/
- Prophet Security. (2025, May 6). SOC metrics & KPIs that matter: MTTR, MTTD, MTTI, false negatives and more. Prophet Security Blog. https://www.prophetsecurity.ai/blog/soc-metrics-that-matter-mttr-mtti-false-negatives-and-more
- Red Canary. (2025, March 16). PowerShell: Technique analysis and detection guidance. Red Canary Threat Detection Report. https://redcanary.com/threat-detection-report/techniques/powershell/
- MITRE. (n.d.). Adversary emulation plans. MITRE ATT&CK®. https://attack.mitre.org/resources/adversary-emulation-plans/


