OSINT para CTI: Fuentes, Herramientas y Workflow Operativo

Mira, llevo más de una década en esto de la ciberseguridad, y si algo he aprendido es que la inteligencia de amenazas (CTI) sin una base sólida de OSINT es como intentar hacer un forensic de un disco duro con los ojos vendados. Te quedas con la mitad de la historia, y la mitad que te falta suele ser la más jodida. En Riskitera, cuando un cliente nos pide que montemos un programa de CTI desde cero, lo primero que hago es sentarles y decirles: "olvidaos de los feeds de pago y los TIPs sofisticados durante un mes. Vamos a aprender a pescar con nuestras propias manos primero". Porque la realidad es que el 80% de la inteligencia accionable que necesitas para proteger tu perímetro, tu marca o tu cadena de suministro está ahí fuera, en fuentes abiertas. El problema no es la falta de datos, es el ruido. Y saber separar el grano de la paja es una habilidad que se pule con años de experiencia, no con una suscripción a un servicio de threat intelligence de 50.000 euros al año.

Vamos al lío. En 2026, el panorama de OSINT para CTI ha madurado, pero también se ha vuelto más hostil. Las APIs públicas se cierran, los scrapers se encuentran con Cloudflare y reCAPTCHA v3 por todas partes, y los actores de amenazas han aprendido a envenenar las fuentes abiertas con datos falsos para despistar a los analistas. Recuerdo un caso el año pasado con un cliente del sector energético: estábamos monitorizando foros de darknet (que, por cierto, cada vez tienen menos tráfico útil y más honeypots de las fuerzas de seguridad) y nos encontramos con una supuesta filtración de credenciales de sus SCADA. Resultó ser un señuelo, un tarpit para identificar a los analistas que picaban. Si no hubiéramos contrastado esa información con fuentes de passive DNS y certificados SSL, habríamos montado un pollo innecesario. Esto no es moco de pavo. Por eso, el workflow que te voy a contar no es teoría; es el que usamos día a día en Riskitera para alimentar nuestros modelos de riesgo y nuestras reglas de detección.

¿Qué fuentes de OSINT son realmente útiles para CTI en 2026?

La primera tentación de cualquier analista junior es abrir una docena de pestañas con herramientas y fuentes, y empezar a recolectar datos como un poseso. Error. El 90% de lo que recojas no te servirá para nada si no tienes un use case claro. En CTI, trabajamos con hipótesis: "¿este actor APT está atacando a mi sector?", "¿hay alguna vulnerabilidad crítica en mi stack tecnológico que se esté explotando activamente?", "¿nuestro CEO está siendo objetivo de un whaling?". Cada hipótesis requiere un conjunto de fuentes específico. No es lo mismo buscar IOCs de un ransomware que hacer un perfilado de un threat actor.

Para empezar, las fuentes clásicas de paste sites como Pastebin o Ghostbin han perdido mucha tracción. Los atacantes ya no cuelgan credenciales ahí a la ligera; ahora usan canales de Telegram cifrados o servicios de dead drop como los que ofrece la red Tor. Sin embargo, hay una excepción: los leaks de código fuente. En 2025 y 2026, hemos visto un aumento bestial de repositorios de GitHub que contienen código malicioso o, peor aún, código de empresas filtrado con credenciales hardcodeadas. Herramientas como GitDorker (versión 2.1, que ahora soporta autenticación OAuth para evitar rate limiting) son imprescindibles para buscar en GitHub, GitLab y Bitbucket de forma masiva. Pero ojo, hay que saber qué buscar. No vale con lanzar "password" a lo loco. Tienes que usar dorks específicos de tu organización: nombres de dominio internos, palabras clave de tu core business, nombres de proyectos internos. Eso es lo que marca la diferencia.

Otra fuente que infravalora mucha gente son los certificados SSL. Censys y Shodan (con sus APIs, que en 2026 tienen precios prohibitivos para uso personal, pero que siguen siendo el estándar de oro) te permiten encontrar infraestructura de los actores. Por ejemplo, si estás trackeando a un grupo que usa siempre un mismo patrón en los CN de sus certificados o un mismo emisor, puedes mapear su infraestructura C2 rápidamente. Hace unos meses, en un ejercicio de threat hunting para una aseguradora, encontramos un servidor C2 de un stealer que se había saltado todos los filtros de su gateway de correo. ¿Cómo? Buscando en Shodan certificados SSL que contuvieran el nombre de su dominio en el SAN, pero emitidos por una CA que no era la suya. El threat actor había configurado mal el certificado y lo dejó expuesto. Ese tipo de pivoting es oro puro.

¿Y qué pasa con las fuentes de threat intelligence colaborativas?

Aquí tengo una opinión muy fuerte: MISP (Malware Information Sharing Platform) sigue siendo, con diferencia, la mejor fuente de inteligencia estructurada si sabes usarla. Pero la comunidad en España es todavía muy pequeña. La mayoría de los equipos de SOC que conozco tienen una instancia de MISP que alimentan con feeds públicos y ya está. Eso no es CTI, es noise collection. La verdadera potencia de MISP está en los sharing groups privados, donde intercambias IOCs y TTPs con otros equipos de confianza de tu sector. En Riskitera, tenemos un grupo con varias empresas del IBEX 35 donde compartimos información de primera mano sobre campañas de phishing que nos llegan. Eso te da una ventaja de días, a veces semanas, sobre los feeds públicos.

Luego están las fuentes más underground: foros de cybercrime como XSS, Exploit.in o el ya casi residual RaidForums (que ha mutado varias veces). Acceder a ellos requiere credenciales y, en muchos casos, un vouch de otro miembro. No es algo que puedas hacer en una tarde. Y ojo, porque muchos de estos foros están infiltrados por fuerzas de seguridad o por los propios actores que quieren identificar a analistas. Mi consejo: si no tienes una necesidad operativa muy clara y un perfil de undercover bien gestionado, no te metas. El riesgo de exponerte es mayor que el beneficio. Es mejor usar servicios de monitorización de darknet como DarkOwl o Sixgill (ahora parte de Recorded Future) que hacen el trabajo sucio por ti, aunque tengan un coste.

osint-para-cti-fuentes-herramientas-y-workflow-operativo diagram 1

¿Qué herramientas de OSINT uso en mi día a día y por qué?

Aquí voy a ser muy honesto: no uso ni la mitad de las herramientas que salen en los listados de "Top 20 OSINT Tools". Muchas son redundantes o están mal mantenidas. Mi stack se reduce a unas pocas, pero las conozco al dedillo. La primera es theHarvester (versión 5.0, que ahora integra búsqueda en fuentes como Hunter.io y Skymem de forma nativa). La uso para la fase inicial de reconocimiento de un objetivo: emails, subdominios, IPs. Pero ojo, los resultados de theHarvester son un punto de partida, no una verdad absoluta. Siempre hay que contrastarlos con búsquedas manuales en Google Dorks.

La segunda herramienta que no falta en mi caja de herramientas es Maltego (uso la versión 2026.1, con los transformadores de Paterva y algunos propios que he desarrollado). Maltego es una pasada para el análisis de relaciones. Te permite conectar un dominio con un email, ese email con un perfil de LinkedIn, ese perfil con un repositorio de GitHub, y así hasta construir un mapa de la infraestructura de un actor o de la superficie de ataque de una empresa. Pero tiene una curva de aprendizaje jodida. La mayoría de la gente se queda en los transformadores básicos y no profundiza en las opciones de pivoting avanzado. Si no eres capaz de escribir tus propios transformadores en Python o de usar las APIs de los transformadores de pago, te estás perdiendo el 70% de su potencial.

Para la parte de threat hunting y correlación de logs, utilizo Sigma (v2.0, con el conversor a Splunk y Elastic). No es una herramienta OSINT per se, pero las reglas Sigma son el puente entre la inteligencia que recolectas y la detección. Por ejemplo, si encuentras un nuevo IOC de un C2 en un foro, puedes escribir una regla Sigma en cinco minutos y desplegarla en tu SIEM. Eso es CTI operativa de verdad. Y no me digas que usas las reglas de Sigma tal cual del repositorio. Eso es para novatos. Tienes que adaptarlas a tu entorno: cambiar los campos, ajustar los umbrales de false positives, añadir contexto de tu organización. En Riskitera, tenemos un repositorio interno de reglas Sigma customizadas que hemos ido puliendo con los años.

Un ejemplo de workflow con código funcional

Imagina que recibes una alerta de que un dominio sospechoso está haciendo DNS queries a tu red interna. Tienes el dominio: malicioso.evil. Tu workflow OSINT para CTI podría ser algo así:

Resolución DNS inversa y pasiva: Usas dig y consultas VirusTotal o SecurityTrails para ver si ese dominio ha resuelto a otras IPs en el pasado. ¿Hay algún patrón? ¿Resuelve a IPs de un ASN conocido por alojar C2s?
Búsqueda de subdominios y certificados: Lanzas crt.sh para ver todos los certificados emitidos para *.evil. Si encuentras un certificado con un CN como mail.evil o vpn.evil, tienes más superficie que investigar.
Perfilado del registro WHOIS: No te fíes del WHOIS tal cual, porque casi siempre está ofuscado con servicios de privacidad. Pero a veces los actores son descuidados y dejan el email real o un nombre de teléfono. Puedes usar herramientas como Whoxy para ver el histórico de WHOIS y encontrar patrones.
Búsqueda en repositorios de código: Lanzas un dork en GitHub con el dominio para ver si aparece en algún script de configuración, en algún log filtrado o en algún proof-of-concept de malware.

Aquí te dejo un script cutre pero funcional que uso a menudo para automatizar los pasos 1 y 2:

#!/bin/bash
# Script para pivoting OSINT basico sobre un dominio
# Uso: ./osint_pivot.sh malicioso.evil
# David Moya - Riskitera - 2026

DOMAIN=$1
echo "[*] Resolviendo IPs historicas para $DOMAIN"
# Usando la API de SecurityTrails (necesitas API key)
curl -s "https://api.securitytrails.com/v1/domain/$DOMAIN/history?apikey=TU_API_KEY" | jq '.records[] | {ip: .ip, date: .date_first_seen}'

echo "[*] Buscando subdominios en crt.sh"
curl -s "https://crt.sh/?q=%25.$DOMAIN&output=json" | jq '.[].name_value' | sort -u | head -20

echo "[*] Buscando en Shodan (necesitas API key)"
# Buscamos por el dominio en el campo de SSL
curl -s "https://api.shodan.io/shodan/host/search?query=ssl.cert.subject.cn:$DOMAIN&key=TU_API_KEY" | jq '.matches[] | {ip_str, port, org}'

Este script no es nada del otro mundo, pero te da una foto rápida en 30 segundos. Luego, con esa información, puedes empezar a construir hipótesis. ¿El dominio resuelve a una IP en Rusia o Ucrania? ¿El certificado lo emitió Let's Encrypt (típico de C2s de bajo presupuesto) o una CA de pago? Todo eso te da pistas sobre el perfil del atacante.

¿Cómo estructuro un workflow operativo de OSINT para CTI?

Este es el punto donde la mayoría de los equipos fallan. Tienen las herramientas, tienen las fuentes, pero no tienen un proceso. El workflow que usamos en Riskitera se divide en tres fases: Recolección, Análisis y Enriquecimiento, y Producción de Inteligencia.

La fase de Recolección es la más caótica. Aquí no filtramos nada. Usamos un script en Python que orquesta varias APIs (VirusTotal, AlienVault OTX, Shodan, Censys, URLScan.io) y las lanza contra los IOCs que nos interesan. El output lo volcamos en un fichero JSON. Pero ojo, este proceso tiene que ser periódico, no puntual. Nosotros lo ejecutamos cada 4 horas para los IOCs de alta prioridad (como los de ransomware que afectan a nuestro sector) y cada 24 horas para el resto. La clave aquí es la persistencia.

#!/usr/bin/env python3
# Riskitera - OSINT Collector v2.3 - 2026
# Recolecta datos de multiples fuentes para un IOC dado

import requests
import json

IOC = "malicioso.evil"
API_VT = "TU_API_KEY_VT"
API_OTX = "TU_API_KEY_OTX"

def query_virustotal(domain):
    url = f"https://www.virustotal.com/api/v3/domains/{domain}"
    headers = {"x-apikey": API_VT}
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        data = response.json()
        # Extraemos solo los datos relevantes: detecciones, categorias, etc.
        return {
            "malicious": data["data"]["attributes"]["last_analysis_stats"]["malicious"],
            "categories": data["data"]["attributes"].get("categories", {})
        }
    return None

def query_alienvault(domain):
    url = f"https://otx.alienvault.com/api/v1/indicators/domain/{domain}/general"
    headers = {"X-OTX-API-KEY": API_OTX}
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        data = response.json()
        return {
            "pulse_count": data["pulse_info"]["count"],
            "related_urls": data["url_list"][:5] if data.get("url_list") else []
        }
    return None

if __name__ == "__main__":
    results = {
        "domain": IOC,
        "virustotal": query_virustotal(IOC),
        "alienvault": query_alienvault(IOC)
    }
    with open(f"{IOC}_osint.json", "w") as f:
        json.dump(results, f, indent=2)
    print(f"[+] Datos recolectados para {IOC}")

La fase de Análisis y Enriquecimiento es donde realmente se hace la magia. Aquí no solo miras los resultados, sino que los relacionas. Por ejemplo, si VirusTotal te dice que el dominio es malicioso, pero AlienVault no tiene pulsos asociados, puede que sea una campaña muy nueva. O al revés: si AlienVault tiene muchos pulsos pero VirusTotal no lo detecta, quizás es un falso positivo o un scanner de vulnerabilidades legítimo. En esta fase también hacemos pivoting: si el dominio resuelve a una IP, buscamos qué otros dominios resuelven a esa misma IP. Si encontramos un certificado compartido, buscamos qué otros dominios usan ese mismo certificado. Esto se puede hacer con herramientas como PassiveTotal (ahora parte de Recorded Future) o con scripts caseros que consulten las APIs de Censys.

La última fase, Producción de Inteligencia, es la que menos se hace bien. Consiste en traducir todo ese análisis en algo que un equipo de respuesta (CSIRT) o un director de seguridad pueda entender y usar. No vale con soltar un listado de IPs. Tienes que generar un informe que contenga: el contexto de la amenaza (¿qué actor?, ¿qué TTPs?, ¿a quién ataca?), los IOCs con su nivel de confianza (bajo, medio, alto), y las recomendaciones de detección (reglas Sigma, consultas KQL, etc.). En Riskitera, para esto usamos una plantilla en Markdown que luego convertimos a PDF. Pero el formato da igual; lo importante es que la inteligencia sea accionable. Si no puedes escribir una regla de detección o una lista negra en 10 minutos después de leer el informe, has fracasado.

¿Qué tendencias de 2026 están cambiando el juego del OSINT para CTI?

En 2026, la inteligencia artificial generativa ha tenido un impacto bestial, pero no necesariamente positivo. Por un lado, herramientas como ChatGPT-5 o Claude 4 se usan para resumir informes de amenazas o para generar consultas en lenguajes de búsqueda (Splunk SPL, KQL) a partir de descripciones en lenguaje natural. Eso acelera mucho la fase de producción. Pero por otro lado, los actores de amenazas también usan IA para generar contenido falso en foros y redes sociales, para crear honeypots más realistas, o para automatizar la creación de dominios y certificados que envenenen las bases de datos de OSINT. He visto casos donde un mismo threat actor generaba 10.000 dominios en un día usando un modelo de lenguaje para crear nombres que parecieran legítimos. Si no tienes un sistema de clustering y análisis de patrones, te pierdes.

Otra tendencia es la creciente monetización de las APIs. Shodan, Censys, VirusTotal, todas han subido sus precios o han limitado las consultas gratuitas. Esto está forzando a los equipos de CTI a ser más selectivos y a optimizar sus consultas. Ya no puedes hacer dumps masivos de datos; tienes que saber exactamente qué quieres buscar y por qué. Esto, en el fondo, es bueno, porque obliga a pensar, pero también encarece los programas de CTI para las pymes.

Por último, el auge del threat intelligence basado en GenAI para generar informes automáticos está creando un problema de information overload. Hay equipos de SOC que reciben 50 informes de CTI al día generados por IA, y no tienen tiempo de leerlos. La solución no es generar más informes, sino generar inteligencia más granular y personalizada. En Riskitera, hemos dejado de hacer informes genéricos de "Tendencias del mes" y nos centramos en informes ad-hoc para cada cliente, basados en sus activos críticos y en las campañas activas que les afectan directamente. Eso es lo que realmente aporta valor.

Recursos y referencias

Para terminar, aquí van algunos recursos que uso a diario y que considero imprescindibles para cualquier analista de CTI que quiera montar un workflow OSINT serio:

MISP Project: La documentación oficial y los taxonomías. Si no tienes una instancia de MISP, estás perdiendo una de las mejores fuentes de inteligencia colaborativa. https://www.misp-project.org/
Sigma HQ: El repositorio de reglas Sigma. Es la base para convertir IOCs en detecciones. https://github.com/SigmaHQ/sigma
The DFIR Report: Un blog con análisis de incidentes reales, con IOCs y TTPs detallados. Es una fuente de inteligencia de primera mano, no un resumen de feeds. https://thedfirreport.com/
Censys Search: La mejor herramienta para buscar certificados y servicios expuestos. Su API es cara, pero para uso puntual es insuperable. https://search.censys.io/

En resumen, el OSINT para CTI no es una carrera de herramientas, es un ejercicio de método y de criterio. Las fuentes y las herramientas cambian cada año, pero la capacidad de formular la pregunta correcta, de contrastar la información y de convertir datos en decisiones es lo que diferencia a un analista de un simple recolector. Y en 2026, con la cantidad de ruido que hay, esa capacidad es más valiosa que nunca.