Manual de recursos CTI / CTH para juniors — Juniors + Fer + vault

Manual de recursos CTI / CTH para juniors

Cómo usar este manual

Este documento empezó como un volcado de las herramientas, marcadores y plantillas que usan dos compañeros junior de CTI más los de Fer. La versión 2.0 lo enriquece con la vault PAI: doctrina mínima viable, workflows operativos, OPSEC, sesgos cognitivos, errores típicos, un roadmap de 90 días y las fuentes A1 que un L1 debería conocer.

Léelo en este orden si eres junior: §A "Cómo usar el manual" → §B "Glosario express" → §C "Doctrina mínima viable" → §1 a §3 (stack y bookmarks) → §D "Workflows del junior" → §F "OPSEC". Después usa §4 como referencia cuando tengas que escribir un reporte. Vuelve a §G/§H/§I/§J cuando lleves dos semanas para no quedarte estancado.

Si ya llevas 90 días en CTI, salta a §C, §D, §I y §K — el resto seguramente ya lo sabes.

Convención: los wikilinks apuntan a notas detalladas dentro de la vault PAI; cuando los veas, abre la nota para profundizar el tema concreto. Las URLs externas son lo que ya tenías en marcadores.

Tabla de contenidos

Parte I — Mapa mental antes de tocar herramientas

Parte II — Recursos operativos (lo que mandaron los juniors)

  1. Resumen y atribución
  2. Stack de herramientas day-to-day
  3. Bookmarks web por categoría
  4. Plantillas de reportes CTI (con hooks de doctrina)

Parte III — Hacer el trabajo bien

Parte IV — Referencias originales
5. Prompts de IA (Feedly TRACCES)
6. Bookmarks personales de Fer
7. Notas y próximos pasos

A. Cómo usar este manual y qué hace un junior CTI/CTH

Tu rol en una frase

Como L1 (analista junior) de CTI/Threat Hunting trabajas en el ciclo de inteligencia — recoges información, la procesas, la analizas, la entregas, recibes feedback y vuelves a empezar. Tu output principal no son los datos: son juicios analíticos trazables, etiquetados con su nivel de confianza y de utilidad para el cliente. Profundiza en [[ciclo-de-inteligencia]].

Lo que un junior CTI hace típicamente en su semana:

  • Triar alertas de SIEM/TIP que llegan a la cola del L1
  • Enriquecer IOCs (IP, dominio, hash) en VirusTotal, Shodan, GreyNoise, OTX
  • Vigilar feeds de CVEs y reportar los críticos del tech stack del cliente
  • Monitorear leaks (foros, Telegram, paste sites, stealer logs vía Flare/Hudson Rock)
  • Escribir reportes cortos siguiendo plantillas (§4) con TLP, Admiralty, WEP
  • Hacer threat hunting con reglas Sigma/YARA cuando llega una nueva campaña
  • Mantener perfiles de threat actors relevantes para el cliente

Lo que NO hace un junior (todavía):

  • Atribuir campañas a actores nacionales — eso es trabajo senior con confidence calibrada
  • Cerrar dominios con take-down ofensivo — eso es legal/ofensivo
  • Tomar decisiones de respuesta — el junior recomienda; el cliente decide
  • Hablar con el cliente sin supervisión en los primeros 90 días
Lo más importante de tu primer mes
  1. Aprende a citar fuentes A1 (§E) y a aplicar el sistema Admiralty (§C.1) ANTES de escribir tu primer reporte.
  2. Aprende el TLP v2 (§C.3). Mandar un reporte sin TLP es como mandar un correo sin asunto: profesionalmente desastroso.
  3. Aprende el WEP (§C.2) y deja para siempre las palabras "seguro", "definitivo", "imposible". CTI vive de probabilidades calibradas, no de certezas.

B. Glosario express (lee esto primero)

Info

Términos que aparecen sin parar en CTI/CTH y que no se explican porque "se asume". Aquí los tienes en una línea cada uno. Si no entiendes uno, búscalo aquí antes de seguir.

Término Significado en una línea
CTI Cyber Threat Intelligence — disciplina de generar conocimiento accionable sobre amenazas
CTH Cyber Threat Hunting — búsqueda proactiva de amenazas que ya están dentro y aún no se detectaron
IOC Indicator of Compromise — artefacto observable (IP, hash, dominio, mutex) que indica intrusión
IOA Indicator of Attack — comportamiento que sugiere intrusión (más resistente al cambio que un IOC)
TTP Tactics, Techniques, Procedures — cómo opera un adversario (taxonomía MITRE ATT&CK)
PIR Priority Intelligence Requirement — pregunta concreta del cliente que define qué intel buscar
RFI Request For Information — solicitud puntual del cliente que dispara un mini-reporte
TLP Traffic Light Protocol — etiqueta de quién puede leer un reporte (RED/AMBER/GREEN/CLEAR)
STIX Structured Threat Information eXpression — formato estándar para describir CTI
TAXII Trusted Automated eXchange of Indicator Information — protocolo de transporte de STIX
CVE Common Vulnerabilities and Exposures — identificador único de una vulnerabilidad publicada
CVSS Common Vulnerability Scoring System — score numérico 0-10 de gravedad de una CVE
ATT&CK MITRE Adversarial Tactics, Techniques & Common Knowledge — la taxonomía estándar de TTPs
CKC Cyber Kill Chain — modelo de Lockheed Martin, 7 fases de un ciberataque
UKC Unified Kill Chain — extensión de CKC con 18 fases
MITRE MITRE Corporation — entidad sin ánimo de lucro, autores de ATT&CK / CTI Blueprints / Navigator
Sigma Lenguaje genérico de reglas de detección; se traduce a queries SIEM (Splunk/Elastic/Sentinel)
YARA Lenguaje de pattern matching para clasificar/identificar malware
Threat actor Grupo o persona que ejecuta ciberataques (APT28, FIN7, LockBit, Conti...)
APT Advanced Persistent Threat — actor sofisticado, normalmente nation-state, con objetivos largos
IR Incident Response — gestionar un incidente desde detección hasta lecciones aprendidas
SOC Security Operations Center — equipo que monitorea y responde 24/7
MSSP Managed Security Service Provider — empresa que vende SOC como servicio
Dwell time Tiempo entre intrusión inicial y detección — métrica clave de CTH
MTTD Mean Time To Detect — promedio para detectar
MTTR Mean Time To Respond/Remediate — promedio para responder
EDR Endpoint Detection and Response — agente en endpoints, ve procesos/registry/red
XDR Extended Detection and Response — EDR + correlación cross-fuente (red/cloud/email)
SIEM Security Information and Event Management — agregador y correlacionador de logs
TIP Threat Intelligence Platform — donde gestionas IOCs/TTPs/actors (MISP, OpenCTI)
SIRP Security Incident Response Platform — gestión de casos (TheHive)
Stealer log Volcado de credenciales/cookies/tokens robado por malware infostealer (Redline, Lumma, etc.)
PoC Proof of Concept — código que demuestra explotación de una CVE
Zero-day Vulnerabilidad sin parche público; los explotadores van por delante
N-day Vulnerabilidad ya parcheada que se sigue explotando porque no todos parchean
Dark web Servicios .onion (Tor) y similares; foros criminales, marketplaces
Deep web Internet no indexado por Google (90% del total); incluye paywalls, intranets, darkweb
Sandbox Entorno aislado para ejecutar muestras sin contagio (Any.Run, Joe Sandbox, Cuckoo)
OSINT Open Source Intelligence — inteligencia obtenida de fuentes públicas
HUMINT Human Intelligence — inteligencia obtenida de fuentes humanas
SIGINT Signals Intelligence — inteligencia de comunicaciones e interceptación
C2 / C&C Command and Control — servidor desde el que el atacante controla el malware
Phishing Ingeniería social por correo/SMS para robar credenciales o instalar malware
Spearphishing Phishing dirigido a una persona/organización concreta
BEC Business Email Compromise — fraude por correo suplantando ejecutivos
Patch Tuesday Segundo martes de cada mes; Microsoft publica parches; el resto del mundo corre

C. Doctrina mínima viable

Important

Estos 7 frameworks son los que no puedes no saber en tu primer mes. No te pido que los domines: te pido que sepas qué resuelve cada uno y dónde mirar la entidad en la vault para profundizar.

C.1 Sistema Admiralty (NATO 6×6) — cómo evaluar fuentes

Calificas fuente (A-F) y información (1-6) por separado. Permite que un titular Reuters cite a un tabloide y tú evalúes ambos.

Fuente Significado Información Significado
A Completamente fiable 1 Confirmada por otras fuentes
B Habitualmente fiable 2 Probablemente cierto
C Bastante fiable 3 Posiblemente cierto
D No habitualmente fiable 4 Dudoso
E No fiable 5 Improbable
F No juzgable 6 No juzgable

Ejemplos prácticos:

  • Mandiant report sobre APT41 → A1 (vendor gold standard + datos forensics propios)
  • Tweet de threat-hunter conocido pero sin enlace al artefacto → B3
  • Post anónimo en BreachForums anunciando leak → F6 (hasta validar muestra)

Profundiza: [[entidad-admiralty-system]]

C.2 WEP — Words of Estimative Probability

Inventado por Sherman Kent en 1964 después de que Bahía de Cochinos saliera mal porque "very serious possibility" significaba 11% para uno y 65% para otro. Hoy es estándar ICD-203.

Frase Rango
Almost no chance / Remote 1–5%
Very unlikely / Highly improbable 5–20%
Unlikely / Improbable 20–45%
Roughly even chance 45–55%
Likely / Probable 55–80%
Very likely / Highly probable 80–95%
Almost certainly / Nearly certain 95–99%
Regla crítica para el junior

NUNCA mezcles likelihood y confidence en la misma frase. Mal: "It is very likely the actor is APT28 with low confidence". Bien: "It is very likely [80-95%] the actor is APT28. Confidence is moderate because attribution rests on infrastructure overlap with two priors, no malware sample matches yet."

Profundiza: [[entidad-wep]]. Equivalente UK: [[entidad-phia-yardstick]].

C.3 TLP v2.0 — Traffic Light Protocol

Quién puede leer tu reporte. Va arriba del documento, siempre.

Etiqueta Quién lo puede leer
TLP:RED Sólo personas nombradas explícitamente en el correo/canal
TLP:AMBER+STRICT Sólo dentro de la organización del receptor
TLP:AMBER Organización del receptor + sus clientes/proveedores con need-to-know
TLP:GREEN Comunidad de seguridad amplia (otros analistas, ISACs)
TLP:CLEAR Sin restricción — público
Default conservador

Si dudas entre AMBER y GREEN, etiqueta AMBER. Bajar el TLP siempre se puede; subirlo después de divulgación es imposible.

Profundiza: [[entidad-tlp-v2]]. Mantenido por [[entidad-first-org]].

C.4 ICD-203 — los 9 estándares de tradecraft

Directiva del ODNI estadounidense. Aplican a cualquier producto analítico decente, no sólo IC clásica.

  1. Describe calidad y credibilidad de fuentes y metodología
  2. Expresa incertidumbres con WEP estándar
  3. Distingue información objetiva de juicios analíticos
  4. Incorpora análisis de alternativas (ACH)
  5. Demuestra relevancia para el cliente y sus implicaciones
  6. Argumentación clara y lógica
  7. Explica cambios o consistencia respecto a juicios previos
  8. Produce juicios precisos
  9. Información visual efectiva cuando aporta
Para el junior

Los más importantes para empezar son los 1, 2 y 3. Si tu reporte cumple esos tres, ya estás por encima del 70% de los reportes mediocres del mercado.

Profundiza: [[entidad-icd-203]]

C.5 Cyber Kill Chain (Lockheed Martin) — 7 fases

Mapa lineal de un ciberataque. Lo usas para situar dónde está la actividad observada.

  1. Reconnaissance — el adversario investiga al objetivo
  2. Weaponization — prepara el payload (exploit + RAT/backdoor)
  3. Delivery — entrega el payload (phishing, USB, watering hole)
  4. Exploitation — explota la vulnerabilidad
  5. Installation — instala persistencia
  6. C2 — establece canal de mando y control
  7. Actions on Objectives — exfiltra, cifra, destruye

Profundiza: [[entidad-cyber-kill-chain]]. Versión extendida 18 fases: [[entidad-unified-kill-chain]].

C.6 Diamond Model — 4 vértices conectados

Complementa CKC. Ves un evento de intrusión como un diamante con cuatro vértices: Adversary ↔ Capability ↔ Infrastructure ↔ Victim. Permite razonar relaciones, no sólo secuencia.

Tip

Cuando tengas un IOC, intenta ubicarlo en uno de los vértices: una IP es Infrastructure, un implant es Capability, una empresa atacada es Victim, un grupo nombrado es Adversary. Si conectas dos vértices, ya tienes una hipótesis de campaña.

Profundiza: [[entidad-diamond-model]]

C.7 MITRE ATT&CK — la taxonomía de TTPs

Catálogo público de tácticas (objetivos) y técnicas (cómo se logran). El junior mapea TTPs vistos a IDs ATT&CK (T1059.001, T1486, etc.) para que cualquier otro analista del mundo entienda al instante.

  • Tactics = qué quería el adversario en cada paso (Initial Access, Execution, Persistence, ...)
  • Techniques = cómo lo hizo (PowerShell, Scheduled Task, ...)
  • Sub-techniques = la variante exacta

Operacionalízalo con MITRE ATT&CK Navigator — capa JSON visualizable en https://mitre-attack.github.io/attack-navigator/. Te permite pintar el "heatmap" de un actor y compararlo con la cobertura de tus detecciones.

Profundiza: [[entidad-mitre-attack]] + [[entidad-mitre-attack-navigator]]. Mantenido por [[entidad-mitre-corporation]].

Trío canónico CTI moderno

CKC + Diamond + ATT&CK se usan juntos: CKC dice en qué fase, Diamond dice qué entidades, ATT&CK dice qué técnica concreta. Cualquier reporte sólido los referencia los tres.

1. Resumen y atribución

Tres voces se mezclan en el archivo fuente:

Voz Aportación Indicador
junior-1 Stack de 24 herramientas operativas; menciona repo OSINT propio "bastante tocho" alojado en otro ordenador (no enviado aún) Líneas 1-49 del message.txt, tono enumerativo, sin URLs
junior-2 Bookmarks web masivos categorizados (~120 URLs), 10 plantillas de reportes CTI, prompt de Feedly del cliente TRACCES Líneas 53-770, dos bloques de bookmarks (el segundo amplía el primero)
Fer Marcadores personales de su navegador (6 entradas) Bloque "Estos son los marcadores en mi navegador web"

Notas previas relevantes: ninguno de los juniors paga IA; uno tiene cuentas en Claude y GPT (gratis) y prevé pasarse a Claude de pago en 1-2 meses. Único prompt almacenado: el de Feedly del cliente TRACCES (incluido en §5).

2. Stack de herramientas day-to-day

Herramientas que junior-1 declara usar a diario, agrupadas por función operativa. Todas se conservan tal cual; la categorización es ayuda navegacional, no la enviada por él (que era una lista plana).

2.1 SIEM / Plataformas de detección

  • Splunk — SIEM enterprise, búsqueda y correlación
  • Elastic Stack — ELK / Elasticsearch + Kibana + Logstash
  • Microsoft Sentinel — SIEM cloud-native de Azure

2.2 Threat Intelligence Platforms (TIPs)

  • MISP — Plataforma open source de IOC sharing → [[entidad-misp]]
  • OpenCTI — TIP open source con grafo STIX2 → [[entidad-opencti]]

2.3 Investigación / Grafos

  • Maltego — Link analysis, transformaciones OSINT

2.4 Incident Response / Casos

  • TheHive — Gestión de casos / SIRP open source → [[entidad-thehive]]
  • Cortex — Motor de análisis y enrichment para TheHive

2.5 Enrichment / Reputación

  • VirusTotal — Análisis multi-engine de archivos/URLs
  • Shodan — Buscador de dispositivos expuestos
  • GreyNoise — Contexto de ruido de internet (escaneadores benignos vs maliciosos)
  • AbuseIPDB — Reputación de IPs (reportes comunitarios)
  • URLhaus — Feed de URLs maliciosas (abuse.ch)
  • AlienVault OTX — Open Threat Exchange, pulsos comunitarios
  • Censys — Buscador de hosts y certificados expuestos
  • RiskIQ — Surface + threat intelligence (PassiveTotal)

2.6 Sandbox / Análisis dinámico

  • Any.Run — Sandbox interactivo en navegador

2.7 Lenguajes de detección

  • Sigma — Reglas genéricas de detección para SIEM
  • YARA — Pattern matching para clasificación de malware

2.8 Frameworks y matrices

  • MITRE ATT&CK Navigator — Mapeo y visualización de TTPs → [[entidad-mitre-attack-navigator]]

2.9 DevOps / Plataforma

  • Docker — Contenedores
  • GitHub — Repos, issues, code search

2.10 Knowledge Management

  • Notion o Obsidian — Notas / documentación personal

Pendiente: junior-1 mencionó tener un "repo de OSINT bastante tocho" en su otro ordenador. Solicitar y anexar cuando lo comparta. Ver §7.

3. Bookmarks web por categoría

Unión deduplicada de los dos bloques de marcadores enviados por junior-2. Las categorías y nombres son los suyos; sólo se han fusionado URLs duplicadas y consolidado las dos pasadas en un único listado.

3.1 Repositorios

3.2 IPs / Puertos

3.3 Mapas / Satélites / Vigilancia

3.4 Geopolítica

3.5 Leaks

3.6 Dashboards

3.7 CVEs

3.8 Breaches / Security

3.9 Emails

3.10 Google Hacking / Dorks

3.11 Search Engine Tools

3.12 GPTs / ChatGPT

3.13 Feeds

3.14 Hosts

3.15 Redes

3.16 Aprendizaje

3.17 IOCs

3.18 Dominios

3.19 Cover Your Tracks / Privacy

3.20 Mapa de amenazas y ciberataques / Monitoreo

3.21 Vulnerabilidades

3.22 Web Browser

3.23 Seguimiento de operaciones humanas y vigilancia

3.24 OSINT & SIGINT

3.25 Forense y relaciones

3.26 Threat Intelligence Platforms — IOCs (búsqueda)

3.27 WhatsApp (forense / OSINT)

3.28 Webs curiosas

3.29 Inteligencia Artificial — Programar / Coding

3.30 Repos AI / HUMINT / OSINT

  • Yokran/BeBrowser — Operational Framework for OSINT & Virtual HUMINT (URL pendiente)
  • kamakauzy/PHINEAS — Profound HUMINT Intelligence Network & Enrichment Automated System (OSINT for pentesters) (URL pendiente)
  • redouanrfr/Caso de inteligencia de amenazas — Inteligencia de amenazas · Infraestructuras Críticas Francesas 2012-2023 — ~40.000 millones € protegidos · Cero Brecha (URL pendiente)
  • jonathan-capers/AI-in-HUMINT — Estudio de viabilidad sobre puntos de integración potenciales para IA dentro de la disciplina HUMINT (URL pendiente)

4. Plantillas de reportes CTI

Las 10 estructuras de reporte que junior-2 utiliza en su día a día. Se conservan verbatim (regla de vault: contenido fuente sin paráfrasis). Los nombres y la numeración del original se respetan.

Hooks de doctrina aplicables a TODAS las plantillas

En cada uno de los 10 templates, siempre añade en cabecera y conclusiones:

  • TLP arriba del documento (§C.3): TLP:AMBER por defecto cuando es para cliente directo
  • Admiralty rating al evaluar cada fuente (§C.1): (B2), (F6), etc., entre paréntesis tras citar
  • WEP en juicios analíticos (§C.2): "It is likely [55-80%] que el actor sea X"
  • MITRE ATT&CK IDs cuando mencionas técnicas: Initial Access via Phishing (T1566.001)
  • CKC fase cuando ubicas actividad: "Indicadores observados en fase Delivery → Exploitation"
  • Confidence (LOW/MODERATE/HIGH) en cada juicio, separada de likelihood

Estos seis hooks convierten un reporte de junior aceptable en uno que un senior firma sin tachar.

4.1 Phishing del cliente detectado

4.1.1 Estructura (Cabeceras)

  • Nombre o nombres de los dominios encontrados (en caso de localizar una campaña)
  • Resumen ejecutivo
  • Por qué se consideran phishing o de carácter sospechoso (certificados recientes o distintos a los de la web oficial, no apuntan a los DNS del cliente, no verifican los datos que se introducen y solo te permiten avanzar en el proceso para que introduzcas cuanta más información mejor)
  • Dónde se han encontrado (si ha sido a través de RRSS, búsqueda por Censys o Shodan, anuncio, etc.)
  • Qué datos solicitan (NIF, DNI, usuario, contraseña, etc.)
  • Estado (activo, inactivo o para monitorizar)

4.1.2 Adjuntos

  • Evidencias del phishing
  • Evidencias del proceso de registro o login del phishing
  • Si existe algún directorio victims.txt o similar, descargarlo y enviar como CSV/Excel con las credenciales recogidas
  • Escaneo de la web en urlscan.org
  • URL o paths del phishing con los enlaces rotos (ejemplo https:// → hxxps[:]//)

4.1.3 Otros

  • En "acciones requeridas", indicar a quién se puede contactar para echar abajo el dominio (por ejemplo, contactar con el registrante o el hosting que da servicio a esta web por correo o formulario dedicado a este tipo de incidentes)
Hooks de doctrina específicos
  • CKC: phishing es fase Delivery (Lockheed CKC paso 3); si recoge credenciales que luego se usan, también Exploitation/C2.
  • ATT&CK: T1566.001 (Spearphishing Attachment) o T1566.002 (Spearphishing Link) o T1566.003 (Service).
  • TLP: AMBER por defecto. RED si la víctima identificable es un VIP del cliente.
  • Playbook IR: ver [[certsg-irm-13-customer-phishing]] (CERT-SG IRM-13).

4.2 Dataleak (credenciales)

4.2.1 Estructura (Cabeceras)

  • Resumen ejecutivo
  • Fuente del leak (foro criminal, marketplace, Telegram, paste, stealer logs, etc.)
  • Tipo de información expuesta (usuarios internos, contraseñas, tokens, cookies, OTP)
  • Nivel de riesgo
  • Estado (en venta, publicado gratuitamente, retirado, confirmado)

4.2.2 Adjuntos

  • Archivo(s) comprometido(s)
  • Tipo (CSV, TXT, ZIP, stealer log)
  • Volumen de datos
  • Muestras sanitizadas
  • Hashes asociados

4.2.3 Otros

  • Usuarios internos afectados
  • Servicios impactados (VPN, O365, GitHub, SaaS, etc.)
  • Acciones recomendadas:
    • Reset de credenciales
    • Forzar MFA
    • Monitorización de accesos anómalos
  • Observaciones CTI
Hooks de doctrina específicos
  • TLP: AMBER+STRICT mínimo. Si hay credenciales activas → RED.
  • Admiralty del foro/canal: BreachForums anónimos = F4-F6; vendor con reputación histórica = D3-C3; verificación con muestra propia = sube a B2.
  • ATT&CK: técnicas asociadas T1078 (Valid Accounts), T1555 (Credentials from Password Stores).
  • Playbook IR: ver [[certsg-irm-11-information-leakage]].

4.3 Eventos de Flare (dispositivos infectados, GitHubs con info crítica, o del estilo)

4.3.1 Estructura (Cabeceras)

  • Identificación del origen del evento reportado por Flare (endpoint, repositorio, servicio)
  • Validación de la legitimidad del dispositivo o recurso afectado
  • Análisis de metadatos asociados: usuario, timestamp, ubicación, tipo de alerta

4.3.2 Adjuntos

  • Revisión de archivos extraídos por Flare
  • Cálculo de hashes y comparación con fuentes CTI internas y externas
  • Análisis estático y dinámico en sandbox cuando aplica
  • Clasificación del riesgo según comportamiento, payload o exposición de datos

4.3.3 Otros

  • Identificación de TTPs asociados a actores conocidos (MITRE ATT&CK)
  • Revisión de repositorios públicos (GitHub, GitLab, Bitbucket) en busca de fugas
  • Evaluación del impacto potencial (exfiltración, persistencia, credenciales expuestas)
Hooks de doctrina específicos
  • TLP: AMBER por defecto. AMBER+STRICT si el endpoint es identificable (laptop ejecutivo, máquina de DBA).
  • Diamond Model: el stealer log conecta los 4 vértices: Adversary (operador del C2) ↔ Capability (familia stealer Redline/Lumma/Stealc) ↔ Infrastructure (panel C2, drop site) ↔ Victim (usuario corporativo).
  • ATT&CK: T1555 Credentials from Password Stores, T1539 Steal Web Session Cookie.

4.4 Nueva campaña de Ransom / malware (con sus IOCs, explicación o recursos para hacer TH)

4.4.1 Estructura (Cabeceras)

  • Resumen ejecutivo
  • Por qué está siendo tendencia, qué vulnerabilidades utiliza, si existe PoC
  • Funcionamiento y análisis técnico
  • Si está estrechamente relacionada con threat actors conocidos (if)

4.4.2 Adjuntos

  • IOCs
  • TTPs
  • CVEs utilizados
  • Query de detección, reglas YARA, reglas SIGMA, common paths, common file names u otros identificadores para hacer hunting
  • Fuentes A1 a poder ser (Unit 42, Microsoft Threat Intelligence Team, Mandiant, etc.)

4.4.3 Otros

  • Recomendaciones para la mitigación y prevención del ataque (normalmente ya se incluyen en los sources)
Hooks de doctrina específicos — el reporte estrella del L1

Esta plantilla es donde se nota más si has hecho los deberes:

  • Diamond Model COMPLETO: rellena los 4 vértices (Adversary / Capability / Infrastructure / Victim) — [[entidad-diamond-model]]
  • CKC mapping: para CADA TTP, di a qué fase de las 7 pertenece — [[entidad-cyber-kill-chain]]
  • ATT&CK matrix: tabla con Tactic | Technique | Sub-technique | Observed Behavior | Source — [[entidad-mitre-attack]]
  • Confidence calibrada: HIGH si tienes muestra propia + fuente A1; MODERATE si dos B2; LOW si una sola C3 o D3
  • Playbook IR ransomware: [[certsg-irm-17-ransomware]]. Para malware genérico: [[certsg-irm-07-windows-malware]] o [[certsg-irm-01-worm-infection]].
  • Plantilla externa "gold": [[entidad-mitre-cti-blueprints]] y [[entidad-zeltser-cti-template]].

4.5 Threat Actor Profiling (procedimientos, TTPs, IOCs…)

4.5.1 Estructura (Cabeceras)

  • Resumen ejecutivo
  • Por qué están siendo tendencia, qué vulnerabilidades utilizan
  • Ataques recientes o más importantes
  • Funcionamiento, cómo proceden o algún tipo de análisis técnico
  • Qué malware o ransomware utilizan (if)

4.5.2 Adjuntos

  • IOCs
  • TTPs
  • CVEs utilizados
  • Query de detección, reglas YARA, reglas SIGMA, common paths, common file names u otros identificadores para hacer hunting
  • Fuentes A1 a poder ser (Unit 42, Microsoft Threat Intelligence Team, Mandiant, etc.)

4.5.3 Otros

  • Recomendaciones para la mitigación y prevención del ataque (normalmente ya se incluyen en los sources)
Hooks de doctrina específicos
  • Atribución como junior: habla de probable atribución con WEP. Mal: "es APT28". Bien: "es likely [55-80%] que la campaña esté asociada a APT28, moderate confidence, basado en infraestructure overlap (B2 Mandiant) y técnica de lateral movement consistente con histórico (C3 propio)".
  • Plantilla TAP standalone: [[entidad-curated-intelligence-threat-actor-profile]].
  • MITRE ATT&CK Navigator layer JSON: pinta el heatmap del actor para que el cliente vea su exposición. Layer público para muchos actores en attack.mitre.org/groups/.
  • Diamond + ATT&CK + CKC integrados son el trío canónico — [[entidad-mitre-attack]] + [[entidad-diamond-model]] + [[entidad-cyber-kill-chain]].

4.6 CVEs críticos / High / PoC / explotados in-the-wild

4.6.1 Estructura (Cabeceras)

  • CVEs recientes, críticos o en tendencia por explotación o gravedad sobre software incluido en el tech stack del cliente (si existe duda en cuanto a si de verdad lo utilizan, pero tal vez no se encuentra en el tech stack como ej: versión de Python, PHP, etc., reportar indicándolo)
  • Funcionamiento o análisis técnico
  • Indicar si existe un parche al momento que se realizó el reporte

4.6.2 Adjuntos

  • Fuentes
  • Link del parche donde se mitiga (si está disponible)
  • PoC si está disponible en GitHub u otros

4.6.3 Otros

  • Recomendaciones para la mitigación
  • Criticidad: depende de la gravedad del CVE, pero elegir entre LOW, MEDIUM o HIGH
Hooks de doctrina específicos
  • CVSS vs criticidad cliente: NO copies el CVSS sin contexto. Una CVE 9.8 que el cliente NO tiene en producción es LOW operativo. Una 7.2 en su gateway expuesto es CRITICAL. Reporta ambos.
  • Exploitation status: cita CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) y EPSS (https://www.first.org/epss/) — son referencias A1 para "explotada in the wild".
  • TLP: GREEN/CLEAR normalmente (CVE pública). AMBER si añades análisis de exposición concreta del cliente.

4.7 Patch Tuesdays / grandes updates con prioridad (segundo martes/miércoles del mes)

4.7.1 Estructura (Cabeceras)

  • Resumen ejecutivo del parche
  • CVEs incluidos en el mismo con relación al tech stack del cliente (si existe duda en cuanto a si de verdad lo utilizan, pero tal vez no se encuentra en el tech stack como ej: versión de Python, PHP, etc., reportar indicándolo)
  • Análisis técnico de las más graves

4.7.2 Adjuntos

  • Fuentes
  • Link del parche donde se mitigan
  • PoC si está disponible en GitHub u otros sobre aquellos CVEs que lo tengan

4.7.3 Otros

  • Recomendaciones para la mitigación
  • Criticidad: depende de la gravedad de los CVEs, pero elegir entre LOW, MEDIUM o HIGH
Hooks específicos
  • Filtra por tech stack del cliente ANTES de redactar. Saca el inventario y cruza CVE × producto. Recuerda que muchos CVE Apple/Adobe no aplican a clientes B2B.
  • Fuentes A1 mensuales: MSRC (https://msrc.microsoft.com/update-guide/) + Talos blog + Tenable Patch Tuesday + Crowdstrike monthly.

4.8 Databreach de una empresa relacionada (ej. la última de Vercel)

4.8.1 Estructura (Cabeceras)

  • Resumen ejecutivo
  • Cómo ha ocurrido el ataque
  • Threat actor o malware responsable
  • Si en el momento del reporte existe comunicación oficial de la entidad afectada
  • Third party involucrada (si hay)
  • Datos o información extraída en el ataque
  • Estado (en venta, publicado gratuitamente, retirado, confirmado)

4.8.2 Adjuntos

  • Fecha del ataque
  • TTPs utilizados
  • CVEs utilizados
  • Screenshot del post del foro en la DW (si hay)
  • Fuente o comunicación oficial de la entidad afectada
  • IOCs (si hay)

4.8.3 Otros

  • Recomendaciones por parte de la empresa afectada (si es third party y el cliente está relacionado)
  • Criticidad como mínimo HIGH y si es cliente CRITICAL
  • Updates constantes sobre los últimos acontecimientos del incidente (nuevas comunicaciones, nueva info)
Hooks específicos
  • Distingue entre comunicación oficial (A1) y filtraciones del foro (D3-F6). Pon Admiralty a cada cita.
  • Third-party risk: si el cliente usa el producto comprometido, levanta un sub-reporte aparte con scope del impacto y SLA del proveedor.
  • Playbook IR: [[certsg-irm-18-large-scale-compromise]].

4.9 Dispositivos públicos en la red (cámaras u otros dispositivos accesibles, webs mal configuradas — DMARC o con vulnerabilidades disponibles)

Nota: el original numera esta sección como 8.1/8.2/8.3 reutilizando el cardinal de Databreach. Se preserva el contenido íntegro y se renumera 4.9.x para coherencia.

4.9.1 Estructura (Cabeceras)

  • Resumen ejecutivo
  • Cómo se ha localizado el dispositivo (Censys, Shodan, etc.)
  • Gaps de seguridad que tiene (DMARC en none, es visible para todo el mundo, portal interno, etc.)
  • Si la versión web contiene CVEs asociados (en caso de WordPress / PrestaShop, Joomla, Nginx, Apache, etc., donde la versión sea pública)
  • IP pública (y nombre de dominio si tiene)
  • En general, cualquier información que haga entender al cliente por qué eso no debería estar así

4.9.2 Adjuntos

  • Screenshots
  • IP y dominio
  • Versión web
  • TTPs posibles

4.9.3 Otros

  • Accesos anómalos
  • Escaneos previos
  • Exploit attempts
  • Servicios expuestos
  • Credenciales por defecto
  • Versiones vulnerables
Hooks específicos
  • Reconnaissance en CKC (fase 1). El reporte gana valor si pintas qué TTPs facilitarías al adversario al dejar esto expuesto.
  • No toques el dispositivo: solo observación pasiva (banner grab via Shodan/Censys archivado). Cualquier interacción activa debe pasar por contrato y autorización explícita.
  • DMARC none: técnica T1566 Phishing facilitada por la mala config; menciona el nexo.

4.10 Perfiles VIP públicos con información sensible a la vista (vida personal, vivienda, DNIs)

4.10.1 Estructura (Cabeceras)

  • Sujeto de la investigación
  • Resumen o profiling en base a lo que se ha encontrado
  • Relaciones con otros sujetos (familiares, esposo/a, etc.)
  • Si hay algún dispositivo infectado relacionado en Flare, también hacer un análisis técnico

4.10.2 Adjuntos

  • Lista de datos personales extraídos (vivienda, DNI, números de teléfono, etc.)
  • Links a webs asociadas
  • Links a perfiles (tanto corporativos como personales)
  • Excel con credenciales extraídas (censurado o con contraseña para descifrar)

4.10.3 Otros

  • Riesgo de ingeniería social o TTPs a los que podría ser vulnerable (en caso de credenciales o dispositivo infectado)
  • Si existe mala política de contraseña, indicar recomendaciones
Reporte legalmente sensible
  • TLP siempre RED o AMBER+STRICT. Datos personales = artículo 6 RGPD, base legal interés legítimo del cliente y proporcionalidad.
  • No publiques credenciales en claro ni en adjuntos sin contraseña. Sanitiza/cifra.
  • Sólo data públicamente accesible. Si entras a una cuenta con creds filtradas → te has pasado a CFAA/intrusión informática. NO LO HAGAS.
  • Playbook IR si hay extorsión: [[certsg-irm-08-blackmail]].

D. Workflows del junior

Info

Seis procedures que vas a ejecutar 80% de tu primer mes. Cada uno tiene inputs, pasos y outputs concretos.

D.1 Triaje de alerta SIEM

Input: alerta del SIEM (Splunk/Elastic/Sentinel) en cola del L1.

Pasos:

  1. Lee la regla que disparó la alerta (no actúes sin entender qué buscaba).
  2. Recoge los IOCs extraídos: IP source/destination, hash, user, hostname, proceso, command line.
  3. Enriquece en paralelo: abre VirusTotal, GreyNoise, AbuseIPDB, OTX, Shodan en pestañas distintas. Pega el IOC en cada una.
  4. Aplica Admiralty a cada hit: VT con 30+ vendors detect = A1; GreyNoise "benign" = A1 a favor del falso positivo; OTX pulse de un usuario aleatorio = D3.
  5. Decide en una de tres: falso positivo (cierra con justificación), verdadero positivo bajo (escala a L2), verdadero positivo alto (escala con urgencia + sugerencia de contención).
  6. Documenta en el ticket: regla, IOCs, fuentes consultadas con Admiralty, decisión, WEP del juicio, próximo paso.

Output: ticket cerrado o escalado, con trazabilidad completa.

D.2 Enrichment de IOC (IP / hash / dominio)

Input: un IOC suelto (típicamente desde un reporte de cliente o un feed).

Pasos por tipo:

Tipo Tools paralelas Qué buscas
IP VirusTotal, AbuseIPDB, GreyNoise, Shodan, Censys, Talos Reputation, Criminal IP reputación, servicios expuestos, ASN, geolocalización, histórico de detecciones
Hash VirusTotal, MalwareBazaar, Any.Run, Hybrid Analysis, Joe Sandbox detección multi-engine, family, comportamiento dinámico, IOCs derivados
Dominio VirusTotal, urlscan.io, WhoisFreaks, RiskIQ/PassiveTotal, AlienVault OTX, Censys resolución DNS histórica, certificados, registrante, subdominios, screenshots histórico
URL urlscan.io, VirusTotal, URLhaus, Any.Run screenshot, redirects, contenido, payload servido

Output: ficha de enrichment con todos los datos cruzados, Admiralty por fuente, y veredicto (malicioso / sospechoso / benigno) con WEP.

D.3 OSINT sobre threat actor

Input: nombre de un grupo (APT41, FIN7, ScatteredSpider, LockBit, etc.).

Pasos:

  1. MITRE ATT&CK groups page: https://attack.mitre.org/groups/<G####>/ — lista canónica de TTPs, descarga JSON layer.
  2. Vendor reports (A1): busca el último report de Mandiant, Microsoft Threat Intel, Crowdstrike, Unit 42, Recorded Future del actor.
  3. MITRE Navigator: pinta el layer JSON sobre la matrix; compara con cobertura del cliente.
  4. MalwareBazaar / ThreatFox: muestras y IOCs vinculados al actor.
  5. TweetDeck/X de threat hunters (B2-C3): @cyb3rops, @malware_traffic, @vxunderground, @cyberknow, etc.
  6. Foros DW / Telegram channels (D3-F6): solo si hay contexto financiero y autorización.

Output: perfil del actor estructurado por la plantilla §4.5, con TTPs mapeados a ATT&CK y links a fuentes con Admiralty.

D.4 Generar reporte para cliente

Input: investigación cerrada (cualquiera de las 10 categorías §4).

Pasos:

  1. Elige la plantilla §4.x correspondiente.
  2. Rellena CABECERA con TLP, fecha, autor, versión.
  3. Resumen ejecutivo (5-7 líneas máximo) con: qué pasó, a quién afecta, criticidad, qué hay que hacer YA. Lo lee el CISO.
  4. Cuerpo técnico con TTPs/IOCs/CVEs/Diamond/CKC/ATT&CK según aplique.
  5. Fuentes con Admiralty obligatorio. Si una fuente es D3-F6, dilo.
  6. Conclusiones con WEP + Confidence separados.
  7. Recomendaciones accionables y priorizadas.
  8. Auto-revisión con ICD-203 (§C.4): ¿cumplo los 9? Si no, arregla antes de mandar.
  9. Revisión por par o senior SIEMPRE en los primeros 90 días. Es lo que paga el sueldo del L2/L3.

Output: PDF/MD/DOCX según el cliente, etiquetado, firmado, registrado en TheHive/OpenCTI.

Plantillas externas que te ahorran tiempo
  • [[entidad-mitre-cti-blueprints]] (gold standard, 4 DOCX)
  • [[entidad-zeltser-cti-template]] (single-page más citado)
  • [[entidad-kraven-security-cti-template]] (Admiralty + WEP + Diamond + Kill Chain integrados)
  • [[entidad-bushidouk-rfi-template]] (especialmente diseñado para junior analysts, te obliga a mapear ATT&CK + Diamond + CKC y separar EVIDENCIADO/INFERIDO/GAP)

D.5 Threat hunting con Sigma + YARA

Input: una nueva campaña reportada (por ej. nuevo loader detectado por Microsoft Threat Intel).

Pasos:

  1. Lee el report A1 y extrae: IOCs (hash/IP/dominio), TTPs (ATT&CK IDs), reglas detección si las publican.
  2. Sigma: si el report incluye reglas Sigma, conviértelas a tu SIEM (Splunk SPL/ELK KQL/Sentinel KQL). Si no, escribe tus reglas a partir del comportamiento descrito.
  3. YARA: si publican reglas YARA, ejecútalas contra tu corpus de muestras (MalwareBazaar histórico + tus colecciones internas).
  4. Hunt window: ejecuta la query Sigma sobre los últimos 30-90 días. Mira si ya estabas comprometido y no lo viste.
  5. Documenta los hallazgos como pivote de hunting y los falsos positivos como exclusiones de la regla.

Output: reglas Sigma/YARA persistidas en repo del SOC, hunt logbook con resultados, recomendación de regla en producción.

D.6 Monitoreo de leaks y dark web

Input: vigilancia continua del cliente y de su sector.

Pasos:

  1. Plataformas (de mayor a menor cost): Flare, Hudson Rock, IntelX, SOCRadar, Cybermonit, leakhub.ai, Telegram channels, BreachForums (con cuenta segregada).
  2. Vigilancia diaria: keywords (dominios, marcas, ejecutivos, nombres internos, productos).
  3. Stealer logs: cruza emails corporativos del cliente contra dumps recientes. Si hit → reporte §4.2 inmediato.
  4. Foros: monitoriza posts de venta/leak relacionados con el sector del cliente. Aplica Admiralty al vendor.
  5. OPSEC obligatorio (§F): nunca uses tu cuenta personal para acceder a estos sitios. Browser perfilado, VPN, sandbox.

Output: alertas accionables en la cola del L1 con triaje §D.1 inmediato si tocan al cliente directo.

E. Fuentes A1 / vendors gold standard

Info

Cuando dices "según fuente A1" en un reporte, esperas que el lector senior reconozca el nombre. Aquí los 8 que un L1 debe conocer y consultar antes que cualquier otro.

Vendor Especialidad Por qué A1
Mandiant (Google Cloud) APT atribución, IR forense Investigaciones forenses propias, telemetria global, M-Trends anual
Microsoft Threat Intelligence Nation-state, ransomware-as-a-service, identity attacks Telemetría de Defender + Azure AD + M365 + GitHub global
CrowdStrike (Falcon Intel) Adversary tracking, e-crime, APT chinos Falcon EDR data + Adversary Universe (200+ actors)
Unit 42 (Palo Alto Networks) Malware analysis, ransomware, cloud threats Cortex XDR data + Wildfire sandbox + research equipo
Cisco Talos Network-based threats, exploit kits, email security Visibilidad de tráfico global Cisco, blog técnico abundante
Recorded Future (Insikt Group) Threat actor tracking, geopolitical CTI Análisis dark web + harvesting masivo + análisis humano
ESET Research / WeLiveSecurity Malware Eastern Europe, Latam, Asia Detección histórica + investigación regional fuerte
Kaspersky GReAT APT (especialmente Eastern Bloc), targeted attacks Securelist research + 25+ años research de campo

Otros que aparecen frecuente y son sólidos (B1-A1 según pieza):

  • Sophos Labs (ransomware, MDR data)
  • SentinelOne (S1 Labs) (malware analysis ágil)
  • Trend Micro Research (IoT, ICS, OT threats)
  • Symantec/Broadcom Threat Hunter Team (telemetría histórica enorme)
  • Group-IB (Eastern Europe/Asia, fraude financiero)
  • Bitdefender Labs (mass-malware + IoT)
  • Check Point Research (phishing, mobile)
  • Trellix Advanced Research Center (APT, ICS)
  • Securelist (Kaspersky) y AhnLab ASEC (Asia)
Sobre atribución

Incluso fuentes A1 fallan en atribución. Cita atribuciones de A1 con WEP likely [55-80%] y MODERATE confidence salvo que tengas convergencia de 3+ vendors A1 → entonces puedes subir a very likely [80-95%] con HIGH confidence. Nunca como junior pongas almost certainly [95-99%] en una atribución.

Feeds gratuitos sólidos (no A1 pero útiles a diario):

  • abuse.ch (URLhaus, MalwareBazaar, ThreatFox, Feodo Tracker) — B2-A2
  • AlienVault OTX (pulses) — variable C3-B2 según autor
  • CISA KEV catalog — A1 para "explotada in the wild"
  • EPSS (FIRST.org) — A1 para probabilidad de explotación
  • NVD (NIST) — A1 para CVE oficial
  • Sigma HQ + YARA-Rules repos — B2-A2 (muchos contribuidores reputados)
  • @malware_traffic_analysis (Brad Duncan) — B1
  • @vxunderground — B2 (archivos de muestras + leaks de operadores)

F. OPSEC del analista junior

Warning

Si haces CTI mal en OPSEC, te conviertes en objetivo. Estos 7 puntos son los no negociables del primer día. Para profundizar: LISAInstitute_MPAI-A4-M4.

  1. Compartimentación: cuenta corporativa nunca toca cuenta personal. Nunca. Ni para "una cosa rápida".
  2. Browser dedicado para investigación: Tor Browser para .onion, Brave/Firefox endurecido para foros clearnet, Burner profile en VPN para webs sospechosas. Usa container tabs (Firefox Multi-Account Containers).
  3. VPN siempre activa durante recon en sitios sospechosos. Si estás en clearnet de proxy del SOC, asegúrate que tu organización lo permite (algunas requieren ir SIN VPN para auditoría).
  4. Sandbox para muestras: NUNCA detones malware en tu host físico. Any.Run en navegador para casos rápidos; VM/Cuckoo/REMnux aislada para análisis profundo. Snapshots antes y después.
  5. 2FA obligatorio en TODOS los servicios profesionales (VirusTotal Enterprise, OpenCTI, MISP, etc.). Hardware key (YubiKey) ideal; TOTP en Aegis/Authy/2FAS aceptable. SMS NO.
  6. Tu huella digital: Egosurfing trimestral. Google Alerts con tu nombre + organización. Si tu LinkedIn dice "CTI Analyst at XYZ", eres objetivo del social engineering. Usa OpSec en redes (no checkpoints, no fotos del despacho con pantallas, no horarios).
  7. "Need to disclose" sobre "need to know": aplicado al hardware, si no puedes securizar al 100% el dispositivo, mejor no lo tengas. Móvil con WhatsApp = potencial leak. Cubre cámaras, desactiva micros cuando no se usan.

Bonus para CTH específicamente:

  • Burner identity sólo si tu organización lo autoriza por escrito y la usas en una infra dedicada (no tu portátil de trabajo, no tu casa). Identidades sin OpSec se queman en 2 semanas.
  • Acceso a foros DW: nunca pagues cuotas con tu tarjeta personal. Cripto desde wallet aislado y atribuible al pago de la operación.
  • Pivots OSINT: cuando buscas un dominio sospechoso, ¡no lo visites directamente! urlscan.io / VT pasivo / Wayback Machine primero. Sólo activo si tienes contención.

G. Sesgos cognitivos a vigilar

Info

Tu cerebro miente todos los días. Estos 6 sesgos son los más letales para un junior CTI. Profundiza en LISAInstitute_MPAI-A5-M1 y [[sesgos-cognitivos-analista]].

Sesgo Cómo ataca al analista CTI Antídoto
Confirmación Encuentras un IOC que apunta a APT28; sólo buscas evidencia que confirme APT28; ignoras que también podría ser FIN7 con TTPs solapadas Aplica ACH ([[entidad-ach]]): lista 3+ hipótesis competidoras y para cada IOC marca cuál refutaría/apoyaría
Anclaje El primer reporte que leíste decía "ransomware Conti". Todo lo que lees después lo lees buscando Conti; ignoras que Conti se disolvió y ahora son Black Basta + otros derivados Antes de leer evidencia, escribe tu prior probability de la hipótesis con WEP. Re-evalúa cada N piezas
Disponibilidad El último ataque sonado fue ransomware. Sobrestimas que el próximo también lo será y dejas de mirar phishing/data exfil Mira base rates (datos de tu sector últimos 12 meses, no últimos 7 días)
Representatividad El IP X ha hecho phishing antes; encuentras nueva actividad → asumes phishing. Olvidas que el botnet del IP cambió de operador y ahora hace bruteforce Trata cada caso como independiente; pídete "¿qué evidencia base-rate apoya esta clasificación?"
Atribución errónea Atribuyes una intrusión a un país por un campo Russian language en metadatos. Olvidas false flags y trabajos a sueldo Atribución sólo con convergencia de 3+ pilares (TTPs + Infrastructure + Victimología) y siempre con WEP+Confidence
Tunnel vision / resistencia al cambio Llevas 2 días con la hipótesis "X". Aparece evidencia que la rompe. La descartas como ruido y sigues Programa Key Assumptions Check ([[entidad-key-assumptions-check]]) cada 24h en investigaciones largas
Ritual diario anti-sesgo

Antes de mandar un reporte, pregúntate: "¿Qué tendría que ser cierto para que mi conclusión esté equivocada? ¿He buscado esa evidencia con la misma intensidad que la confirmatoria?" Si la respuesta es "no", retrasa 30 minutos y re-analiza. Esto es la base de Devil's Advocacy — [[entidad-devils-advocacy]].

H. Errores típicos del junior y cómo evitarlos

Warning

Diez antipatterns que verás en tu primer trimestre. Si sólo recuerdas tres, recuerda los marcados con (★).

  1. (★) Paráfrasis del source en lugar de cita verbatim → pérdida de trazabilidad, riesgo de alteración de sentido. Antídoto: cita verbatim entrecomillado + tu interpretación aparte.
  2. (★) "Es seguro que..." → muerte de la calibración, te quemas la primera vez que falla. Antídoto: WEP siempre. Sustituye "seguro" por "very likely [80-95%], high confidence" y razónalo.
  3. (★) Atribuir actor sin Admiralty + 3 pilares → reporte ridículo si te equivocas. Antídoto: WEP + 3 pilares (TTPs + Infrastructure + Victimología) o no atribuyas.
  4. No poner TLP → tu reporte se reenvía sin control. Antídoto: TLP arriba SIEMPRE, default AMBER.
  5. Mezclar likelihood y confidence en una frase → confunde al lector. Antídoto: dos frases separadas.
  6. Citar VT score "30/70" sin contextualizar → 30 detections puede significar tinder o false positive en familia conocida. Antídoto: cita los nombres detectados, no sólo el ratio.
  7. No mapear TTPs a ATT&CK → reporte ininteligible para el SOC del cliente. Antídoto: cada técnica → ID ATT&CK obligatorio.
  8. Olvidar el tech stack del cliente en CVE/Patch reports → ruido inservible. Antídoto: cruza CVE × inventario ANTES de escribir.
  9. Detonar muestra en host físico → te enseñé esto en §F.4 y aún así lo veo todas las semanas. Antídoto: Any.Run / VM. Sandbox SIEMPRE.
  10. Mandar reporte sin que un par/senior lo revise primer trimestre → te firmas tus errores. Antídoto: peer review obligado los primeros 90 días, sin excepciones.
Pareto

Los errores 1, 2 y 3 (★) son ~70% de las correcciones que un L2 hace a un L1. Domínalos pronto y subes en visibilidad.

I. Roadmap 90 días junior CTI/CTH

Tip

Plan progresivo. Si te sientes ahogado en la semana 1, no pasa nada — el primer mes es turbulento por diseño. Si en el día 60 aún no entiendes ATT&CK, pide refuerzo: no es vergüenza, es eficiencia.

Semanas 1-2 — onboarding y vocabulario

  • Lee §B (glosario) entero y haz tu propia tabla con dudas pendientes
  • Lee §C (doctrina mínima viable) tres veces; abre las entidades vault de cada framework
  • Lee Visser2026_cti-fundamentos-lecciones + Doe2024_cti-theory-vs-experience
  • Crea cuenta en VirusTotal, AlienVault OTX, AbuseIPDB, GreyNoise Free, Censys Free, Shodan (free trial)
  • Configura tu OpenCTI/MISP de prácticas (puedes correr https://demo.opencti.io/ o spin-up local con Docker)
  • Lee 5 reports A1 enteros (Mandiant + Microsoft + Unit 42 + Talos + CrowdStrike) — observa estructura y rigor
  • Aprende a navegar MITRE ATT&CK Navigator y ATT&CK groups page (cubre 5 actores)
  • Lee PAI2026_guia-obsidian-vault-cti-l1 para entender la vault si vas a usar Obsidian/PAI

Semanas 3-6 — operación supervisada

  • Triaje de alertas SIEM (workflow §D.1) — al menos 50 alertas, todas peer-reviewed
  • Enrichment de IOCs (workflow §D.2) — 100+ IOCs cruzados en 4+ fuentes
  • Escribe tu primer reporte §4.6 (CVE crítico) sobre una CVE real del mes — peer-review obligatorio
  • Escribe tu primer reporte §4.4 (campaña ransom/malware) basado en un report A1 reciente
  • Hunt con 3 reglas Sigma públicas convertidas a tu SIEM (workflow §D.5)
  • Domina [[entidad-mitre-attack]] + [[entidad-cyber-kill-chain]] + [[entidad-diamond-model]] — sé capaz de explicar la diferencia entre los tres en una pizarra
  • Lee 3 IRM CERT-SG completos (recomendados: [[certsg-irm-13-customer-phishing]], [[certsg-irm-17-ransomware]], [[certsg-irm-11-information-leakage]])

Semanas 7-12 — especialización inicial

  • Elige UNA vertical para profundizar primero: ransomware, threat actor profiling, OSINT/HUMINT, CTH/Sigma+YARA, dataleaks/dark web
  • Empieza un perfil de threat actor relevante para el sector del cliente (workflow §D.3, plantilla §4.5)
  • Aporta una regla Sigma original al repo del SOC + corresponding hunt
  • Resuelve 5 retos de OSINT CTF Newsletter (https://ctf.osintnewsletter.com/challenges)
  • Lee [[entidad-psychology-intelligence-analysis]] (Heuer) — el fundacional, especialmente capítulo 8 ACH
  • Aprende a aplicar ACH ([[entidad-ach]]) en una investigación real con 3+ hipótesis
  • Si vas a CTH puro: domina Sigma, YARA, KQL/SPL/ES|QL del SIEM del cliente
  • Pide a tu lead un objetivo de progresión a L2 con criterios concretos
Lectura constante (todo el primer año)
  • Daily: Talos blog, Microsoft Security blog, CISA alerts, BleepingComputer
  • Weekly: SANS NewsBites, Risky Business podcast, tldr.sec
  • Monthly: Mandiant M-Trends summary, Recorded Future Insikt selected
  • Yearly: Verizon DBIR, Microsoft Digital Defense Report, ENISA Threat Landscape

J. Pruebas y entrenamiento (CTFs y plataformas)

Info

Donde practicar sin miedo a romper producción.

Plataforma Foco Coste Para juniors
TryHackMe Pentest, IR, CTI rooms Free + €10/mes ★★★★★ ideal primer mes
HackTheBox Academy Más técnico, módulos extensos Free + paid ★★★★ avanzado
OSINT CTF Newsletter Retos OSINT Free ★★★★★ practica visión investigador
Trace Labs Search Party OSINT real (missing persons) Free, requiere registro ★★★★ ético + experiencia real
OverTheWire / picoCTF Fundamentos hacking Free ★★★ si vienes de cero
MITRE Engage / CTID exercises TTPs, deception Free ★★★★ refuerzo doctrina ATT&CK
CyberDefenders Blue team / forensics labs Free + premium ★★★★ casos forenses reales
LetsDefend SOC analyst simulación Free + premium ★★★★ rol L1 directo
DFIRMadness CTF Forensics + IR Free archive ★★★ casos resueltos paso a paso
HackTheBox Sherlocks DFIR retos Paid ★★★ caro pero buenísimo

Recursos de aprendizaje gratuitos:

  • HackTricks Wiki — https://book.hacktricks.wiki/en/index.html — referencia técnica masiva
  • Bellingcat OSINT toolkit — https://bit.ly/bcattools
  • OSINT Framework — https://osintframework.com/
  • SANS Cyber Threat Intelligence Summit talks (YouTube) — años de presentaciones gratis
  • MITRE ATT&CK YouTube channel — workshops oficiales

K. Recursos integrados de la vault PAI

Info

Enlaces a notas detalladas del vault. Úsalas como manual de referencia cuando quieras profundizar más allá de este documento.

K.1 Guías ya existentes (no se duplican aquí — léelas)

Guía Para qué sirve
PAI2026_guia-obsidian-vault-cti-l1 Setup Obsidian replicable + plugins + ejemplo APT29 end-to-end
Guia-elaboracion-informes-CTI PIR, ciclo IC 6 fases, Admiralty completa, ACH, KAC, lenguaje probabilístico
Guia-investigacion-OSINT-redteam 9 fases OSINT pre-engagement, stealer logs, password patterns, SPOF
Visser2026_cti-fundamentos-lecciones Fundamentos CTI con teoría + tecnología + lecciones prácticas
Visser2026_cti-use-cases-catalogo 11 casos de uso CTI por madurez
Boston2026_cti-fusion-playbook-templates Templates fusion CTI ↔ IR
Boston2026_cti-fusion-exposure-validation CTI Exposure Validation, de reportes a impacto operativo
SOCPrime2024_what-is-threat-intelligence Qué es threat intelligence (intro suave)

K.2 Themes (síntesis cross-source de la vault)

  • [[ciclo-de-inteligencia]]
  • metodologia-osint
  • panorama-ciberamenazas
  • respuesta-incidentes-lifecycle (18 IRM CERT-SG indexados)
  • [[sesgos-cognitivos-analista]]

K.3 Entidades — frameworks CTI

  • [[entidad-mitre-attack]] — taxonomía TTPs
  • [[entidad-mitre-attack-navigator]] — JSON layers
  • [[entidad-cyber-kill-chain]] — Lockheed CKC 7 fases
  • [[entidad-unified-kill-chain]] — UKC 18 fases
  • [[entidad-diamond-model]] — 4 vértices conectados
  • [[entidad-stix-taxii]] — formato/transporte
  • [[entidad-tlp-v2]] — Traffic Light Protocol v2

K.4 Entidades — doctrina IC

  • [[entidad-admiralty-system]] — NATO 6×6
  • [[entidad-wep]] — Words of Estimative Probability
  • [[entidad-phia-yardstick]] — UK PHIA Probability Yardstick
  • [[entidad-icd-203]] — 9 Tradecraft Standards
  • [[entidad-ach]] — Analysis of Competing Hypotheses
  • [[entidad-key-assumptions-check]] — KAC
  • [[entidad-quality-of-information-check]] — QoI Check
  • [[entidad-indicators-signposts]] — I&W
  • [[entidad-devils-advocacy]] — Contrarian
  • [[entidad-multiple-hypothesis-generation]] — pre-ACH
  • [[entidad-mom-pop-moses-eve]] — checklists deception/source
  • [[entidad-sherman-kent]], [[entidad-richards-heuer]], [[entidad-robert-clark]], [[entidad-randolph-pherson]]

K.5 Entidades — plataformas y tools

  • [[entidad-misp]], [[entidad-opencti]], [[entidad-thehive]]
  • [[entidad-mitre-corporation]], [[entidad-first-org]], [[entidad-odni]]

K.6 Entidades — plantillas externas (úsalas como referencia)

  • [[entidad-mitre-cti-blueprints]] — gold standard, suite 4 DOCX
  • [[entidad-zeltser-cti-template]] — single-doc más citado
  • [[entidad-kraven-security-cti-template]] — Admiralty + WEP integrados
  • [[entidad-curated-intelligence-threat-actor-profile]] — TAP standalone
  • [[entidad-bushidouk-rfi-template]] — diseñado para junior analysts
  • [[entidad-idir-templates]] — Intelligence-Driven Incident Response

K.7 IRM CERT-SG — 18 playbooks de IR

Cuando un incidente cae en tu mesa, busca el IRM correspondiente para tener guía paso a paso:

IRM Tipo de incidente
[[certsg-irm-01-worm-infection]] Worm / malware infection
[[certsg-irm-02-windows-intrusion]] Windows intrusion detection
[[certsg-irm-03-unix-linux-intrusion]] Unix/Linux intrusion
[[certsg-irm-04-ddos]] DDoS
[[certsg-irm-05-malicious-network-behaviour]] Malicious network behaviour
[[certsg-irm-06-website-defacement]] Defacement
[[certsg-irm-07-windows-malware]] Windows malware
[[certsg-irm-08-blackmail]] Extorsión / blackmail
[[certsg-irm-09-smartphone-malware]] Smartphone malware
[[certsg-irm-10-social-engineering]] Social engineering
[[certsg-irm-11-information-leakage]] Information leakage
[[certsg-irm-12-insider-abuse]] Insider abuse
[[certsg-irm-13-customer-phishing]] Customer-targeted phishing
[[certsg-irm-14-scam]] Scam
[[certsg-irm-15-trademark-infringement]] Trademark infringement
[[certsg-irm-16-phishing]] Phishing
[[certsg-irm-17-ransomware]] Ransomware
[[certsg-irm-18-large-scale-compromise]] Large-scale compromise

K.8 MPAI LISA Institute — sustento doctrinal

Para profundizar en analista de inteligencia (no sólo CTI): cualidades, OPSEC, sesgos, técnicas:

  • LISAInstitute_MPAI-A4-M1 — Introducción a la inteligencia
  • LISAInstitute_MPAI-A4-M2 — Marco normativo
  • LISAInstitute_MPAI-A4-M3 — Cualidades del analista
  • LISAInstitute_MPAI-A4-M4 — Autoprotección (OPSEC) ★
  • LISAInstitute_MPAI-A4-M5 — Técnicas y herramientas
  • LISAInstitute_MPAI-A5-M1 — Sesgos cognitivos ★
  • LISAInstitute_MPAI-A5-M2 — Análisis estratégico
  • LISAInstitute_MPAI-A5-M3 — Análisis de desinformación

5. Prompts de IA (Feedly TRACCES)

Único prompt que junior-2 declara tener almacenado: el de Feedly del cliente TRACCES. Se incluye verbatim.

<role>You are a threat intelligence analyst with strong expertise in internal audits. You can identify TTPs and MITRE identifiers where applicable.</role>

<task>
Generate a short, concise Threat Intelligence report based on the text or URL provided. Follow the structure below and adhere to the protocols described:

Structure:

1. Under "Context," provide relevant background on the threat, specifying nature, affected systems, industries, regions, and timelines into a single parraph.

2. In "Description," explain how the threat operates, including techniques used, associated malware or phishing, and any exploited vulnerabilities.

3. For "Impact and Security Risk," highlight potential consequences such as data breaches, financial loss, operational disruption, or reputational damage.

4. "Recommendations" should outline proactive and defensive measures, including patching, training, or the use of security tools.

5. In "References," list resources, citations, CVE numbers, CVSS scores, MITRE identifiers, IOCs, and any external links.
</task>

<guidelines>
Keep Sections Brief and Direct
Avoid unnecessary adjectives or a pedantic tone in all sections.

Use Internal Audit Language
Maintain an internal audit phrasing and tone throughout.

Maintain Neutral Interpretations
Avoid strong or definitive statements; keep interpretations open and language neutral.

Include Mitigations, TTPs, and MITRE IDs
Focus on current impacts, high-level mitigations, and possible fixes.
Where possible, reference TTPs and MITRE identifiers (e.g., in "Mitigation, Workarounds & Recommended Actions").

Consolidate Research Notes
Combine the main points from all sources into a cohesive overview in your notes.
Keep language neutral, avoiding definitive conclusions or overstated certainty.
</guidelines>
Mejoras propuestas al prompt (cuando lo iteres)

El prompt actual cumple ICD-203 estándares 1-3 implícitamente, pero podría reforzarse pidiendo explícitamente: (a) TLP en cabecera, (b) WEP para juicios, (c) Admiralty para fuentes, (d) tabla ATT&CK matrix con Tactic | Technique | Sub-technique | Observed | Source, y (e) sección Confidence rationale separada del WEP.

6. Bookmarks personales de Fer

Marcadores que Fer tiene en su navegador para trabajar CTI/CTH en el día a día. Lista corta y muy operativa.

  • Repositorio OSINT con herramientas (referencia interna del propio Fer, sin URL pública)
  • Login de Flare — https://flare.io/ (producto: stealer log + dark web monitoring)
  • VirusTotal — https://www.virustotal.com/
  • Feedly — https://feedly.com/
  • SharePoint CTI (interno cliente)
  • OpenCTI (instancia interna o demo https://demo.opencti.io/)

7. Notas y próximos pasos

7.1 Pendientes inmediatos

  • Repo OSINT del otro ordenador (junior-1): pedirle que mande el repo "bastante tocho" cuando vuelva al otro equipo. Anexar al §3.1 una vez recibido.
  • URLs incompletas: completar las 5 referencias org/repo que faltan URL completa: osintambition/Social-Media-OSINT-Tools-Collection, Yokran/BeBrowser, kamakauzy/PHINEAS, redouanrfr/..., jonathan-capers/AI-in-HUMINT. Una búsqueda en github.com/<org>/<repo> debería bastar.
  • Lista email del compañero: junior-2 mencionó tener una segunda lista en su email. Solicitarla y hacer un segundo merge si llega.

7.2 Decomposición a la vault (segunda fase, NO ahora)

Cuando Fer lo solicite, este documento puede decomponerse en:

  • Notas Entity (Projects/<proyecto-cti>/) por cada herramienta core con 3+ apariciones futuras: Splunk, MISP, OpenCTI, MITRE ATT&CK, Censys, Shodan, VirusTotal, Sigma, YARA, TheHive, Cortex, Flare, Maltego.
  • Notas Reference por cada plantilla de reporte CTI (§4.1–§4.10) → reutilizables como template operativo.
  • Tema (Themes/) si emerge cobertura cruzada (≥3 fuentes): por ejemplo "Stack OSINT/CTI L1 español" cuando se sumen los recursos del otro junior y los del repo pendiente.
  • Prompt (Prompts/) → guardar el prompt Feedly TRACCES como entrada con su contexto de uso.

7.3 Cobertura total del documento original

Bloque del message.txt Procesado en
Líneas 1-49 (stack tools) §2 (10 subsecciones)
Líneas 53-211 (1ᵉʳ bloque bookmarks) §3 (unión con 2º bloque)
Líneas 212-372 (2º bloque bookmarks + repos AI) §3 + §3.30
Líneas 378-385 (Q&A IA pago / prompts) §1 (resumen y atribución)
Líneas 386-432 (prompt Feedly TRACCES) §5 (verbatim)
Líneas 434-450 (bookmarks personales Fer) §6
Líneas 453-772 (10 plantillas de reporte) §4 (verbatim renumerado + hooks doctrina)

7.4 Cambios v1.0 → v2.0 (este enriquecimiento)

Sección Cambio
Frontmatter type: research → type: guide, status: seedling → fern, añadido audience: junior-cti-cth, version: 2.0
TOC Reestructurado en 4 partes (mapa mental / recursos / hacer el trabajo bien / referencias originales)
§A Nuevo: "Cómo usar este manual y qué hace un junior CTI/CTH"
§B Nuevo: glosario express con 40+ términos
§C Nuevo: doctrina mínima viable (Admiralty / WEP / TLP / ICD-203 / CKC / Diamond / ATT&CK)
§2-§3 Sin cambios en URLs/listas; añadidos crosslinks entidad-X a herramientas con entidad en vault
§4 Conservadas verbatim las 10 plantillas; añadido bloque "Hooks de doctrina específicos" en cada una
§D Nuevo: 6 workflows step-by-step
§E Nuevo: 8 vendors A1 + criterios de uso
§F Nuevo: OPSEC del analista junior con 7 puntos no negociables
§G Nuevo: 6 sesgos cognitivos con ejemplo CTI y antídoto
§H Nuevo: 10 errores típicos con antipattern y cómo evitarlo
§I Nuevo: roadmap 90 días en 3 ventanas (1-2 / 3-6 / 7-12 semanas)
§J Nuevo: 10 plataformas CTF + recursos de aprendizaje
§K Nuevo: índice de recursos vault PAI (guías, themes, 50+ entidades, 18 IRM, 8 MPAI)

Documento v2.0 generado el 2026-04-27 por PAI 4.0.3 (Algorithm v3.7.0, modo EXTENDED). Base v1.0 derivada de C:\Users\fer\Downloads\Telegram Desktop\message.txt. Enriquecimiento v2.0 derivado de la vault PAI Obsidian (Projects/cyber-threat-intelligence, Projects/doctrina-inteligencia, Projects/incident-response-irm, Projects/lisa-institute-mpai, Themes). Listo para revisión por Fer antes de promover a Projects/<cti-junior-onboarding>/ como guide.

Themes