Un atacante roba unas credenciales. En cuestión de segundos, y de forma completamente automatizada, las canjea por un token de acceso, entra en el entorno cloud, enumera, exfiltra y deja persistencia. Cuando la alerta llega, si llega, ya es tarde. No es un escenario hipotético: es lo que Borja Merino ve, de forma recurrente, en los incidentes que investiga.
Los datos están a su favor: el tiempo medio para identificar una brecha en cloud en 2025 fue de 219 días [CSA Lab Space]. A eso se suma un detalle que lo hace aún más incómodo: para el equipo que defiende, esa actividad se parece muchísimo a un acceso legítimo. Ahí está el verdadero problema de la identidad hoy: no tanto en detectar el ataque, sino en distinguirlo de lo normal.
Borja lleva unos 16 años en el terreno, en ingeniería inversa, análisis de malware y, en los últimos años, Threat Hunting, con paradas en organizaciones como ISDEFE, INTECO/INCIBE, Tarlogic o One eSecurity. Hoy lidera el equipo de Threat Research en Alpine Security, ayudando a mejorar las capacidades de detección y respuesta de sus clientes.
Le pedimos que mirara el riesgo de identidad desde donde mejor lo conoce: desde la cabeza del atacante. Lo que sigue son sus respuestas, sin filtros.
_
8Layers: Cuéntanos un poco sobre ti y tu carrera.
Borja: Estudié ingeniería informática en la Universidad Pontificia de Salamanca, donde, durante mis años de licenciatura, trabajé en el CPD de la propia universidad, participando en diversos proyectos de ciberseguridad.
Desde entonces, y durante unos 16 años aproximadamente, he ido construyendo mi trayectoria profesional en diferentes empresas y organizaciones, entre ellas ISDEFE, INTECO/INCIBE, Tarlogic, iHackLabs y One eSecurity, trabajando principalmente en el ámbito de ingeniería inversa, análisis de malware y, en los últimos años, en Threat Hunting.
Actualmente trabajo en Alpine Security como responsable del equipo de Threat Research, ayudando a mejorar las capacidades de detección y respuesta frente a amenazas en nuestros clientes.
8L: En Alpine Security vosotros “think as they act”. En la práctica, ¿qué te permite ver el pensar como un atacante que un defensor que nunca ha estado del otro lado no suele ver?
Borja: Principalmente permite unir los puntos de manera más ágil durante una investigación y responder con mayor diligencia a las preguntas que generalmente nos hacemos a medida que vamos diseccionando los eventos derivados de un incidente. ¿Qué trata de conseguir el atacante? ¿Cuál ha sido el vector de entrada? ¿Por qué ha escrito en disco determinado fichero? ¿Cómo y para qué ha llevado a cabo cierto movimiento lateral? ¿Cómo ha conseguido escalar privilegios? ¿Por qué se ha inyectado en este proceso? Etc.
Es bastante diferencial el valor que aporta un perfil con un background ofensivo en un equipo de Hunting, no solo a la hora de establecer hipótesis durante un incidente y contextualizar el mismo en base a los eventos analizados, como señalaba anteriormente, sino también para desarrollar queries proactivas eficientes.
En Alpine valoramos muy positivamente perfiles con conocimientos sólidos no solo en forense o respuesta a incidentes, sino también en malware y Red Teaming, precisamente porque sabemos que ese “adversarial mindset” va a mejorar la respuesta temprana.
8L: Buena parte de tu investigación empieza en el endpoint y en la memoria. ¿En qué punto de la cadena de ataque entra en juego la identidad (credenciales, tokens, sesiones)?
Borja: Para responder con precisión a ambas cuestiones, es necesario que desarrolle, en primer lugar, la premisa planteada.
Es cierto que en muchos escenarios el punto de partida de una investigación es un conjunto de eventos o alertas, bien proactivas o bien generadas por la propia solución EDR, que tienen lugar en el propio endpoint. Una de las principales tareas cuando la actividad maliciosa se ha contenido (o se piensa que se ha contenido) es tratar de construir un timeline de todas las acciones ejecutadas por el Threat Actor o el malware correspondiente.
Esta es una fase clave en nuestro trabajo por varios motivos. Nos permite, por ejemplo, identificar artefactos o técnicas de persistencia todavía activas (no detectadas) en el endpoint afectado u otros equipos. Nos permite dimensionar y contextualizar el incidente. Además, nos puede ayudar a mejorar las capacidades de detección y nuestro dwell-time si somos capaces de crear nuevas queries proactivas que identifiquen la misma amenaza en una etapa más previa.
Durante la reconstrucción retrospectiva del timeline es fundamental alcanzar el Initial Access empleado para conocer principalmente si dicho incidente es reproducible de nuevo, pero también para saber si realmente la amenaza todavía está presente en la organización.
Contestando a las preguntas planteadas, hoy en día una proporción significativa de los vectores de entrada actuales que observamos está directamente relacionada con problemas de identidad, derivados principalmente del robo de credenciales mediante infostealers, ataques de phishing y técnicas de fuerza bruta. Esta tendencia constata que la protección de la identidad continúa estando desatendida.
8L: Claro, y para monitorizar la identidad, ¿qué desafíos concretos le plantea a un equipo de Threat Hunting?
Borja: Principalmente hay dos. Por un lado, el tiempo de reacción. De manera recurrente nos encontramos incidentes en donde, en cuestión de pocos segundos, a partir de un AiTM (Adversary-in-the-Middle) el atacante canjea unas credenciales por un refresh/access token para acceder, enumerar, exfiltrar y añadir persistencia en un entorno Cloud. Todo ello de manera automatizada, mediante herramientas open-source muy fáciles de operar (véanse TokenTacticsV2, ROADtools, AADInternals, etc.).
Por otro lado, discernir la actividad legítima de la actividad maliciosa en cuestión de identidad es bastante complejo en muchos escenarios. Hay que invertir mucho esfuerzo en crear casos de uso eficaces. Estos hechos hacen que la identidad sea un dominio especialmente desafiante para la detección.
8L: Eres especialista en técnicas de evasión y artefactos en memoria. ¿Existe un paralelo en el mundo de la identidad, como formas en que el atacante pasa desapercibido usando credenciales y accesos legítimos que los defensores todavía no saben cazar?
Borja: Decir especialista creo que es decir mucho. No obstante, sí que es algo que siempre me ha gustado y a lo que le dedico bastante tiempo. Desde luego que se pueden aplicar paralelismos con la identidad. Solo hay que observar la evolución que están adoptando herramientas ofensivas utilizadas para acciones muy particulares en torno a la identidad. Vemos cómo, cada vez con mayor frecuencia, surgen nuevas técnicas que permiten agilizar determinados procesos y eludir políticas condicionales: uso de proxies residenciales para evadir restricciones de geofencing, registro de dispositivos nuevos para obtener un PRT (Primary Refresh Token) y sortear posteriores restricciones de acceso, etc. Observamos, además, cada vez más plataformas sofisticadas para abusar de flujos OAuth, por ejemplo, para hacer MFA downgrade, FOCI pivoting, etc. Hace unos meses el FBI alertaba de Kali365, un PhaaS competidor de EvilTokens que implementa técnicas de OAuth device-code flow abuse y AiTM, y que pone a disposición de otros afiliados los tokens OAuth extraídos.
La proliferación de este tipo de kits y plataformas cada vez más especializadas, automatizadas y accesibles está reduciendo la complejidad necesaria para comprometer y acceder a secretos, además de complicar cada vez más la vida a los hunters por la dificultad que conlleva, tal y como indicaba en la respuesta anterior, distinguir entre accesos autorizados y actividad maliciosa.
Este hecho, sumado a la proliferación de modelos de afiliación al alcance tanto de TA como de atacantes particulares para la compraventa de credenciales/sesiones/tokens, y del elevado número de infostealers que estamos observando en los últimos años, ha obligado a que los equipos de Threat Hunting consideren el Threat Intelligence como un componente esencial (y no un simple elemento auxiliar) dentro de su estrategia operativa.
8L: Tus charlas recientes tratan sobre agentes autónomos capaces de identificar artefactos en memoria. Mirando la otra cara de la moneda: a medida que los agentes de IA empiezan a actuar dentro de las organizaciones, con sus propias credenciales y permisos, se convierten en una nueva identidad que hay que vigilar. ¿Cómo ves ese nuevo tipo de “identidad autónoma” desde el punto de vista de quien estudia al atacante?
Borja: Sin duda alguna supone un nuevo desafío, por los mismos motivos previamente indicados. En la mayor parte de nuestros clientes ya observamos agentes de IA (Claude agent, OpenClaw, etc.), así como todo tipo de aplicaciones y scripts (ejecutados por medio de Node, Python, etc.) que se comunican con modelos de lenguaje vía API. Esto nos ha obligado a implementar queries de detección muy granulares para tratar de identificar actividad sospechosa.
Parte de esta dificultad se debe a la legitimidad de dichas herramientas y a la permisividad de los EDR frente a ellas (la mayoría de los binarios precompilados están firmados y las comunicaciones, generalmente vía API, son a dominios legítimos). Supone un reto similar al profiling que tenemos que hacer a la hora de identificar un uso malintencionado de RMM Tools o túneles de diversa índole.
Estar al corriente y entender muy bien técnicamente cómo están utilizando los TA estos agentes como herramientas de post-explotación es fundamental para crear detecciones eficaces. Ya a mediados de 2025 se documentaba un caso en donde APT28 utilizaba cierto ejecutable empaquetado con PyInstaller con un payload denominado LameHug, que se conectaba a la API de Hugging Face para usar un LLM a modo de generador de comandos de post-explotación. Este tipo de amenazas no son meras especulaciones o futuribles, sino que son una realidad ya presente y constituyen un nuevo paradigma desde un punto de vista defensivo.
8L: A la industria le encanta competir en número de detecciones listas para usar, la cantidad de reglas preconstruidas que un producto trae de fábrica para lanzar alertas sobre comportamientos sospechosos. Desde tu silla de detection engineer, ¿qué es lo que de verdad separa una buena detección del ruido? ¿Dónde está el límite entre cantidad y calidad, y en qué momento más reglas dejan de ayudar y empiezan a empeorar el trabajo del equipo?
Borja: Bajo mi punto de vista es fundamental, en primer lugar, entender técnicamente cómo funcionan las tecnologías con las que trabajamos. Aquí obviamente no hablo de hacer ingeniería inversa, pero sí es cierto que cuantos más conocimientos a bajo nivel, mejor. Esto ya nos proporciona ciertas pistas sobre los posibles gaps de detección y carencias que pueden tener, o el tipo de ataques de los que pueden ser objeto. Por ejemplo, la mayoría de soluciones EDR se alimentan de ETW, pero otras adicionalmente hacen hooking en espacio de usuario inyectando sus propias DLLs, además de instalar sus drivers correspondientes. Conocer las fuentes de información de las que se alimentan estas soluciones, así como el tipo y la calidad de la telemetría generada, ya nos proporciona información valiosa.
Por otro lado, dado que realmente los fabricantes no te suelen proporcionar la lógica de detección que implementan para sus reglas, es recomendable disponer de un laboratorio y, como parte de la operativa del Hunting, probar muchas TTPs para valorar si es necesario o no crear queries complementarias para cubrir posibles huecos de detección.
A la hora de crear dichas queries, lo que separa realmente una buena detección del ruido es la calidad de la misma a la hora de ser capaz de filtrar por rareza, contexto y desviación de cierto baseline. Combinando múltiples señales correlacionadas y alejándote en la medida de lo posible de los IOC para abarcar un mayor número de escenarios e incrementar el coste operacional del adversario. Esto a nivel teórico suena bien, pero en la práctica requiere de bastante tiempo y de gente con mucha experiencia y con altos conocimientos técnicos.
Además, una última fase que es fundamental es la de testeo, en donde debemos probar dicha detección en el mayor número posible de endpoints y de escenarios diversos para valorar el ruido generado. A nivel teórico muchas veces pensamos que determinada detección puede ser muy buena, pero en la práctica, cuando la aplicamos en entornos reales, nos encontramos con muchos falsos positivos, en donde, a pesar de excepcionar y perfilar la misma, la hace inviable por el ruido generado. Algunos factores como el esfuerzo del perfilado, la cobertura de la detección y el número de falsos positivos generados son los que consideramos finalmente para determinar si incorporamos o no dicha detección a nuestro ciclo de hunting.
8L: Para cerrar: desde el punto de vista de quien estudia al atacante, ¿qué artefactos de identidad (cuentas de servicio, API keys, tokens OAuth) son los objetivos más valiosos y, al mismo tiempo, los más ignorados por los equipos hoy? Y si pudieras dar un consejo a un equipo que se enfrenta a ataques de identidad hoy, ¿cuál sería?
Borja: Yo diría los tokens de sesión y las cookies de autenticación, así como las identidades no humanas, al estar más desatendidas (raramente se rotan y carecen de la misma vigilancia que los usuarios reales).
En primer lugar, aconsejaría, siempre y cuando tengan opción, elegir una solución profesional enfocada a identidades, con capacidad y flexibilidad para crear reglas de detección. En el día a día diría de crear muchas reglas basadas en un baseline conocido (un refresh token que se ha utilizado desde una región no vista previamente, la primera vez que un usuario registra una aplicación, una identidad que pasa a utilizar por primera vez otro Client ID, etc.). También aconsejaría contar y correlar eventos con un servicio de Threat Intel de terceros que permita reportar secretos robados por parte de infostealers y de markets underground.
_
Si algo queda de esta conversación con Borja, es que el ataque de identidad ya no avisa. Ocurre en segundos, de forma automatizada, y, lo más incómodo, disfrazado de actividad perfectamente normal.
Y, además, esa distinción, no se compra hecha. Empieza por entender de qué fuentes se nutre tu telemetría y qué es capaz de ver; sigue por construir un baseline de lo que es normal en tu entorno; y culmina cuando dejas de tratar los tokens de sesión y las identidades no humanas como piezas de segunda y empiezas a vigilarlas con el mismo rigor que a cualquier usuario. Menos reglas de fábrica y más contexto. Ese es, al final, el trabajo.
Identity Attack, Unfiltered
Identity Attack, Unfiltered es la serie quincenal de 8Layers en la que damos voz a expertos en seguridad para hablar, sin filtros, del riesgo de identidad: cómo lo ven desde el terreno, qué les preocupa y qué harían diferente. Cada conversación suma una perspectiva distinta, de la gobernanza al análisis forense, del SOC a la inteligencia de amenazas.
La serie nace de aquello a lo que nos dedicamos en 8Layers: unir en una única visión de la identidad lo que normalmente vive separado: postura, detección y compliance.
¿Trabajas en seguridad de identidad y crees que tienes algo que aportar? Nos encantaría escucharte. Escríbenos a marketing@8layers.io y cuéntanos tu perspectiva; puede que seas la próxima voz de la serie.