Las 10 técnicas que yo ya NO utilizaría en un red team en 2026

Hubo una época en la que un powershell -enc, un rundll32, una exclusión de Defender y un poco de magia con AMSI eran suficientes para convertir una máquina Windows en una fiesta. Pero ya no estamos en 2018… 

Es cierto que muchas de las técnicas que se han convertido en clásicos del Red Team siguen todavía funcionando en determinadas circunstancias pero ya no son una apuesta fiable. El endpoint moderno no depende únicamente de firmas. Telemetría de procesos, AMSI, ETW, EDR, correlación cloud, reglas ASR, identidad, autenticación reforzada y análisis de comportamiento han convertido muchas de aquellas recetas universales en técnicas de alto ruido y bajo rendimiento.

Y esto tiene una consecuencia importante para un operador: el objetivo ya no es encontrar «el bypass que funciona» si no encontrar el camino que el entorno no puede permitirse no detectar.

Estas son diez técnicas que deberíamos dejar de utilizar como primera opción en un Red Team moderno.

01. PowerShell como primera opción

Durante años, PowerShell fue el lenguaje natural del Red Team: estaba instalado en prácticamente todos los Windows, permitía ejecutar código sin dejar un ejecutable tradicional y daba acceso a .NET, WMI, COM y Win32. El problema es que ahora también es uno de los lenguajes más observados.

PowerShell dispone de logging, Script Block Logging y, en muchos entornos, integración con AMSI. Con Script Block Logging habilitado, por ejemplo, los bloques de código ejecutados pueden quedar registrados como eventos 4104. Y AMSI no se limita a PowerShell: también participa en la inspección de contenido procedente de distintos hosts de scripting y Office.

Por eso, lanzar el típico: powershell.exe -nop -w hidden -enc … es cada vez menos una técnica de ejecución y cada vez más un IOC con piernas.

Alternativas

No significa «deja de usar PowerShell», significa deja de asumir que PowerShell es la opción por defecto.

En función del objetivo, merece más la pena evaluar:

• ejecución mediante binarios legítimos ya presentes;
• APIs nativas de Windows;
• .NET cuando el contexto lo permita;
• herramientas administrativas legítimas;
• ejecución remota mediante mecanismos ya existentes;
• o directamente cambiar de host/proceso cuando PowerShell sea innecesario.

02. AMSI bypass genérico

El clásico AMSI bypass era casi un ritual de iniciación. Modificar memoria, tocar AmsiScanBuffer, manipular estados internos, utilizar reflection, lanzar un bypass conocido de un repo en GitHub… Funcionaba hasta que dejó de hacerlo de forma suficientemente consistente.

El problema no es solamente que Microsoft conozca los bypasses. Es que el bypass en sí mismo se ha convertido en comportamiento detectable.

Además, la propia arquitectura de AMSI hace que los intentos de manipular el mecanismo de inspección sean interesantes desde el punto de vista defensivo.

Alternativas

En este caso sería reducir la dependencia de AMSI. En vez de pensar: «¿Cómo evito que AMSI vea mi payload?» piensa: «¿Por qué tengo que introducir un payload que AMSI pueda inspeccionar?»

Esto empuja al operador hacia:

• menor superficie de scripting;
• ejecución de lógica en procesos adecuados;
• binarios mínimos y específicos;
• técnicas living-off-the-land seleccionadas por contexto;
• abuso de funcionalidades legítimas;
• y, cuando sea necesario, investigación específica del stack de seguridad del objetivo.

03. Defender exclusions

Esta probablemente merece un lugar especial en el museo del Red Team. El clásico: Add-MpPreference -ExclusionPath C:Tools era una forma bastante cómoda de decir: «Defender, hazme el favor de mirar hacia otro lado.» En un entorno moderno, es mucho menos interesante.

Microsoft considera explícitamente las exclusiones una reducción de protección y dispone de mecanismos de Tamper Protection para impedir cambios no autorizados en determinadas configuraciones. Y hay otra trampa interesante: una exclusión de Defender no equivale necesariamente a invisibilidad frente al EDR. 

Microsoft documenta que incluso archivos excluidos pueden continuar generando detecciones heurísticas o de comportamiento en Defender for Endpoint.

Alternativas

Primero buscar si existe realmente una configuración débil que permita modificar la postura de seguridad. Eso es mucho más interesante desde un punto de vista Red Team.

Por ejemplo:

• delegaciones excesivas;
• permisos sobre herramientas de seguridad;
• identidades con privilegios innecesarios;
• configuraciones de gestión;
• trust relationships;
• políticas de endpoint;
• herramientas de administración mal delegadas.

La exclusión de Defender puede seguir siendo útil como finding de configuración, pero utilizarla como técnica universal de evasión es cada vez menos convincente.

04. Unhooking clásico

Durante años, uno de los caminos habituales frente a EDR fue: EDR hook -> unhook -> API limpia -> payload. El problema es que el modelo mental es demasiado antiguo.

Un EDR moderno no necesita depender exclusivamente de un hook en una API de user-mode para detectar una actividad. Hay telemetría adicional, correlación, comportamiento, memoria, procesos, identidad y datos enviados al backend. Por eso, quitar unos hooks de ntdll.dll no convierte mágicamente el proceso en invisible. De hecho, el propio unhooking puede ser una señal.

Alternativas

El cambio conceptual es importante: de «bypass del sensor» a «reducción de señales».

En lugar de intentar apagar el radar:

• reduce operaciones innecesarias;
• evita cadenas de procesos absurdamente llamativas;
• utiliza procesos y contextos coherentes;
• separa discovery de ejecución;
• minimiza artefactos;
• utiliza técnicas distintas para cada objetivo.

05. rundll32 para todo

rundll32.exe es otro superviviente de una época más feliz. Durante años fue una de las herramientas favoritas para ejecutar DLLs sin lanzar directamente un ejecutable propio. El problema es que precisamente por eso es extremadamente conocido. 

Un: rundll32.exe suspicious.dll,EntryPoint no es invisible.

Y mucho menos cuando forma parte de una cadena del estilo:

WINWORD.EXE
    ↓
powershell.exe
    ↓
rundll32.exe
    ↓
payload

En 2026 el contexto importa tanto como el binario.

Alternativas

No busques «otro LOLBin universal», ese es precisamente el error. Busca la herramienta legítima que ya tenga sentido en ese contexto.

Si estás en un servidor de administración, la cadena de ejecución esperable será diferente que en un endpoint de usuario. Si estás en un servidor SQL, el camino será diferente que en un DC. Si estás en un entorno cloud, quizá ni siquiera exista un proceso Windows que debas tocar.

El concepto importante es: Living-off-the-land contextual, no Living-off-the-Land por catálogo.

06. Cobalt Strike sin modificar

Si todavía desplegamos un Beacon prácticamente idéntico al que utilizan miles de operadores, estamos haciendo un favor al SOC. Cobalt Strike no es el problema. Los defensores llevan años creando detecciones alrededor de sus características, patrones de Beacon, tráfico C2, comportamiento de procesos y artefactos.

Alternativas

La respuesta no es necesariamente: «Compra otro C2.» La respuesta es: diseña la operación alrededor del objetivo y no alrededor de la herramienta.

Eso implica:

• modificar y comprender profundamente los componentes utilizados;
• generar perfiles de tráfico coherentes con el entorno;
• evitar artefactos innecesarios;
• separar infraestructura de operación;
• utilizar herramientas distintas para diferentes fases;
• y, sobre todo, entender qué telemetría genera cada componente.

Una buena operación Red Team no debería ser reconocible por el nombre de su framework.

07. Kerberoasting indiscriminado

Aquí tenemos un clásico que todavía funciona y precisamente por eso hay que dejar de ejecutarlo indiscriminadamente.

La versión antigua era aproximadamente: enumerar SPNs, solicitar tickets, hacer kerberoasting y creackear offline.

El problema es que pedir tickets para cantidades enormes de cuentas de servicio genera ruido y, además, puede no tener ningún valor operativo. Pero hay algo todavía más importante en 2026: el ecosistema Kerberos está cambiando. Microsoft está impulsando la eliminación progresiva de RC4 y recomienda migrar hacia AES; además, ha anunciado cambios para deshabilitar RC4 como tipo de cifrado predeterminado en los controladores de dominio.

Esto no significa que Kerberoasting haya muerto. Significa que el operador debe preguntarse: «¿Qué cuenta merece realmente la pena atacar?» en lugar de: «¿Cuántos hashes puedo conseguir?»

Alternativas

Kerberoasting dirigido.

Priorizar:

• cuentas de servicio con privilegios;
• cuentas con SPN interesantes;
• cuentas antiguas;
• configuraciones de cifrado débiles;
• passwords potencialmente débiles;
• relaciones con aplicaciones críticas.

El objetivo ya no es recolectar tickets. Es encontrar una identidad que cambie el resultado del ataque.

08. NTLM relay sin mirar el contexto

Este es probablemente uno de los ejemplos más claros de cómo ha cambiado Windows.

Hace años hacíamos coercing para recibir y reenviar autenticación NTLM y podía ser una receta extraordinariamente efectiva. Pero en 2026 el operador tiene que comprobar muchas más condiciones.

SMB signing está siendo reforzado de forma importante: Windows 11 24H2 y Windows Server 2025 requieren firma SMB de forma predeterminada para las conexiones correspondientes, reduciendo una de las superficies clásicas de relay. Microsoft también está avanzando hacia el bloqueo de NTLM y la migración a Kerberos. Y LDAP signing/channel binding añaden otra barrera a determinados escenarios de relay.

Alternativas

No abandonar NTLM relay. Dejar de asumir que funcionará. Antes de intentarlo hay que mapear: 

• ¿Quién autentica?
• ¿Con qué protocolo?
• ¿Hacia dónde?
• ¿SMB signing?
• ¿LDAP signing?
• ¿Channel binding?
• ¿NTLM permitido?
• ¿Existe un destino útil?

Y si la respuesta es «no», cambiar de técnica. En otras palabras: Relay ha pasado de ser una técnica a ser una condición de laboratorio.

09. Macros/VBA

Las macros maliciosas no han desaparecido. Han desaparecido como vector universal de entrega.

Microsoft bloquea de forma predeterminada las macros VBA procedentes de Internet en Office, precisamente por el abuso histórico de este mecanismo. Además, Defender incorpora reglas ASR específicamente orientadas contra comportamientos de Office como:

• creación de procesos hijo;
• creación de contenido ejecutable;
• inyección de código;
• llamadas Win32 desde macros;
• ejecución de contenido potencialmente ofuscado.

Por eso el típico phishing que venía con un adjunto «invoice.xlsm» y acababa ejecutando powershell es una cadena que debería hacer sonar campanas en muchos SOC.

Alternativas

La pregunta vuelve a ser contextual: ¿Cómo interactúan realmente los usuarios con los documentos?

Y eso abre caminos mucho más interesantes:

• abuso de funcionalidades legítimas de colaboración;
• identidad;
• OAuth;
• aplicaciones SaaS;
• compartición de documentos;
• workflows;
• add-ins;
• extensiones;
• ingeniería social adaptada al entorno;
• y vulnerabilidades reales de las aplicaciones utilizadas.

El documento malicioso sigue existiendo. Pero ya no debería ser nuestra primera respuesta por defecto.

10. Payloads genéricos

Y probablemente esta sea la más importante de todas. Porque resume el problema de las nueve anteriores. El payload genérico nació de una época en la que la defensa preguntaba: «¿Qué archivo es este?» Pero ahora el endpoint moderno pregunta: «¿Qué está haciendo este proceso?» y el SOC: «¿Qué relación tiene esto con todo lo demás que está ocurriendo?»

Por eso un genérico es cada vez menos interesante. No importa demasiado que el payload sea técnicamente sofisticado si es una secuencia que el entorno considera imposible o altamente improbable.

Alternativas

Payloads específicos para el objetivo, pequeños, con una única función, con el mínimo número de dependencias y, sobre todo, diseñados alrededor de la operación.

El cambio es pasar de: «Tengo un payload y necesito encontrar dónde ejecutarlo.» a: «Tengo un objetivo y necesito el mínimo código posible para conseguirlo.»

Conclusiones

No significa dejar de usar estas técnicas, sino dejar de utilizarlas por inercia. Antes de lanzar un PowerShell, un Kerberoasting masivo, un NTLM relay o un payload genérico, hay que pensar primero en la operación y evaluar, como mínimo, cuatro dimensiones:

• ¿Funcionará? ¿Las condiciones necesarias están realmente presentes en el entorno?
• ¿Cuánto ruido hará? ¿Qué telemetría, eventos o indicadores generará y quién podrá verlos?
• ¿Tengo el contexto necesario? ¿Conozco suficientemente la identidad, los controles, las configuraciones y las relaciones de confianza que hacen viable la técnica?
• ¿Qué valor aporta? ¿Me acerca realmente al objetivo de la campaña o simplemente me permite ejecutar «una técnica más»?

Porque conseguir ejecutar una técnica no debería ser el objetivo de un Red Team. El objetivo es demostrar un impacto de negocio o un camino de ataque realista con el menor ruido y la mayor relevancia posible.

Muchas de estas técnicas seguirán funcionando en 2026. Lo que ha cambiado es el contexto en el que funcionan y, sobre todo, el coste de utilizarlas cuando ya no son la opción adecuada.

El Red Team ha pasado de buscar “qué herramienta puedo ejecutar” a preguntarse “qué identidad, confianza o control puedo aprovechar para alcanzar el objetivo”. Y ese cambio de mentalidad es probablemente mucho más importante que aprender otro bypass de EDR.

En el siguiente artículo veremos, por encima, algunas de las técnicas y enfoques que están sustituyendo a estas aproximaciones clásicas: Identity-First Red Team, Entra ID, OAuth abuse, cloud attack paths, SaaS, AD CS, Windows Hello for Business, device identity y ataques híbridos AD → Entra.