Skip to content
EntrevistaRead in English

"Los adversarios ya no explotan vulnerabilidades ni sueltan payloads para el acceso inicial, simplemente se autentican"

Aaron Rolph, Senior Director, Cyber Threat Intelligence & Vulnerability Management en Veeam® Software, sobre por qué los atacantes ahora entran en lugar de irrumpir, por qué la mayoría de los feeds de threat intel son un desperdicio de dinero, y una nueva forma de enmarcar el problema: la deuda de identidad.

·12 min de lectura
"Los adversarios ya no explotan vulnerabilidades ni sueltan payloads para el acceso inicial, simplemente se autentican"

Durante casi toda la historia de la ciberdefensa, una intrusión tenía una forma: encontrar una vulnerabilidad, explotarla, soltar un payload, tomar el control. Buscabas un archivo malicioso. Pero esa forma se está disolviendo, y quien lo expresó de manera más directa en nuestra conversación fue Aaron Rolph.

Aaron lleva más de una década en seguridad, desde defender infraestructura crítica de los mercados financieros (NYSE Euronext, casi diez años en CME Group) hasta liderar hoy threat intelligence y vulnerability management en Veeam® Software. Se describe a sí mismo como alguien "conocido por preocuparse por las personas detrás de los pew pew maps más que por los checklists", y "comprometido con el resultado correcto, no con el fácil".

Hablamos de qué es realmente el threat intelligence, de por qué la identidad se ha convertido en la vía preferida del atacante, y de un término que usa para replantear el problema, "identity debt" (deuda de identidad), que él mismo explica a lo largo de la conversación. Las opiniones que comparte son propias y no representan una posición oficial de Veeam® Software. Lo que sigue son sus respuestas, sin filtros.


8Layers: Has pasado más de una década defendiendo infraestructura crítica de los mercados financieros, desde NYSE Euronext hasta casi diez años en CME Group, y ahora lideras threat intelligence y vulnerability management en Veeam® Software. Son mundos muy distintos: un mercado de derivados frente a una empresa de resiliencia de datos. ¿Cómo cambia lo que significa "seguridad" de uno a otro?

Aaron: Creo que la seguridad no es lo que cambia, lo que cambia es la prioridad de negocio sobre qué activos se protegen y cómo. Pensando en los servicios financieros por un momento, ¿cuál de estas elegirías si tuvieras que escoger una?

A) Que tu saldo bancario mostrara por error un negativo en lugar de un positivo y los recibos no se pagaran, o B) Que tu saldo bancario se filtrara, o C) Que tu portal de banca online estuviera caído durante 12 horas. Yo diría que la integridad es lo que más importa en los servicios financieros, y eso sin la sopa de letras de la regulación. Cuando mencionas seguridad y servicios financieros pienso en: integridad de las transacciones, separación de funciones, aprobaciones múltiples, registros de auditoría inmutables y cumplimiento regulatorio. Priorizando la tríada CIA para una empresa de software, en particular las empresas SaaS, tiene que ser la disponibilidad. Sí, podríamos debatir que la confidencialidad es la principal contendiente (e incluso la integridad), pero toda la confidencialidad del mundo y el pipeline de build más íntegro no servirán de nada si no puedes convencer a tus clientes de que tu producto está realmente disponible para que lo usen.

Cuando mencionas seguridad y la industria del software pienso en: SDLC, higiene del pipeline de CI/CD, aislamiento de tenants, arquitectura de identidad, gobernanza de la cadena de suministro y vulnerability management (bug bounty / vulnerability disclosure, etc.). En última instancia, la seguridad sigue intentando proteger la confidencialidad, la integridad y la disponibilidad de los activos, pero lo que cambia es cuál de las tres se prioriza, qué amenazas son relevantes y qué considera el negocio como riesgo aceptable.


8L: Tu rol se centra en threat intelligence. Para alguien ajeno a ese mundo: ¿cómo describirías qué es realmente el threat intelligence en tu día a día, y qué te dice que otras herramientas de seguridad no pueden?

Aaron: El threat intelligence es, en esencia, un producto que ayuda a un stakeholder a tomar una decisión más informada sobre un tema que le interesa, como un M&A (fusiones y adquisiciones), ubicaciones para celebrar eventos o abrir una oficina, en qué amenazas centrarse, etc. Puede ser estratégico, operativo o táctico. El producto podría ser un informe, una serie de hashes, el perfil de un actor de amenazas, reglas de detección y muchas otras formas, pero necesita cumplir tres criterios para que sirva de algo. La inteligencia tiene que ser oportuna: de poco sirve que mi equipo te cuente algo que puedes leer tú mismo en las noticias. La inteligencia tiene que ser accionable: un informe es inútil si no ayuda a un stakeholder a tomar una decisión informada, que es para lo que has contratado CTI (cyber threat intelligence) en primer lugar.

La inteligencia tiene que ser relevante: hay montones de historias y eventos muy interesantes relacionados con el ciber ocurriendo en el mundo, pero si tú como stakeholder no tienes ningún interés en la geopolítica de Oriente Medio, ¿por qué iba a darte un informe sobre las capacidades ciber actuales de los actores de amenazas iraníes observados?

También es importante señalar lo que el threat intelligence no es. Está diseñado para ayudar a los stakeholders a tomar decisiones informadas, no para tomar las decisiones por ellos. Para llegar al producto final, los analistas de amenazas empiezan recopilando datos en bruto de diversas fuentes (internas, como logs, y externas, como feeds), procesan estos datos, es decir, los corroboran, correlacionan, enriquecen, de-duplican y normalizan para filtrar el ruido y convertirlos en un formato apto para el análisis. En este punto los datos han pasado de brutos a procesados. Se analizan los datos procesados para generar insights y, finalmente, se disemina la inteligencia ya accionable a los stakeholders (y, si quieres cerrar el ciclo, el feedback vendría bien).

La actividad del día a día se ajusta a nuestros PIRs (prioritised intelligence requirements) y a cualquier RFI (request for information) que llegue. Dos ejemplos más grandes serían la inteligencia de vulnerabilidades y el mapeo de actores de amenazas para la ingeniería de detección.

En cuanto a lo que puede decirnos que otras herramientas no. Muchas herramientas miran hacia dentro y son retrospectivas. Pueden decir "oye, algo sospechoso pasó aquí" basándose en una coincidencia de firma, en algo anómalo observado o en una regla de comportamiento que se dispara, pero normalmente no pueden aportar la atribución del actor de amenazas, información sobre si esto es algo puntual o parte de una campaña de ataque en curso o nueva, y qué es probable que ocurra a continuación. Un ejemplo podría ser algo como que se ha detectado tráfico de red hacia una dirección IP desconocida. El threat intelligence podría añadir: esta dirección IP pertenece a un bulletproof hosting, un proveedor usado habitualmente por FIN7, que ha lanzado hace poco una nueva campaña de ataque. O, otro ejemplo, ¿preferirías esperar a que se detecte un login válido porque resulta sospechoso, o que te avisen de que un IAB (initial access broker) está vendiendo acceso VPN a una empresa que coincide con tu descripción?


8L: Y cuando miras cómo operan los atacantes hoy, ¿qué tan central se ha vuelto el ataque basado en identidad en su playbook, comparado con hace unos años?

Aaron: Buena continuación del ejemplo del IAB (Initial Access Broker). Mira el CrowdStrike 2026 Global Threat Report: ~82% de las detecciones fueron malware free. Es una locura. Eso significa que los adversarios ya no explotan vulnerabilidades ni sueltan payloads para el acceso inicial, ¡simplemente se autentican! También coincide con lo que estamos viendo en el panorama más amplio: un aumento enorme de las credenciales comprometidas como vector de acceso inicial en lugar de la explotación de vulnerabilidades. Ya sea a través de un IAB, una filtración de datos o ingeniería social, es más fácil entrar que irrumpir. Cuando lo pienso desde la industria en la que estoy ahora, me asusta imaginar a un atacante autenticándose en la backup console.

En el panorama de amenazas actual, los playbooks enteros de algunos actores de amenazas empiezan hackeando a las personas, no a los sistemas. Por ejemplo, en una campaña Scattered Spider operó aproximadamente 500 dominios de phishing suplantando plataformas como Okta, Salesforce y Microsoft SSO. Una de sus técnicas favoritas es suplantar a los helpdesks y aplicar ingeniería social a las víctimas. Esto podría llevar a credenciales de SSO, bypass de MFA y acceso amplio a la empresa, sin necesidad de ningún exploit técnico.


8L: Profundizando en las intrusiones basadas en identidad en concreto: ¿qué tendencias estás viendo? ¿Hacia dónde crees que va esto? ¿Se están convirtiendo las credenciales robadas y los ataques de acceso válido en la vía de entrada dominante, y qué está impulsando ese cambio?

Aaron: En cuanto a tendencias, la realidad es que estamos viendo ataques impulsados o potenciados por IA en todos los frentes, y dos elementos de eso me preocupan en concreto. La IA reduce la barrera de entrada para atacantes poco cualificados y permite automatizar a escala, y ni me hagas empezar con la IA agéntica... desplegemos millones de agentes, cada uno necesitando credenciales o alguna forma de acceso, cada uno capaz de tomar acciones sin humanos en el bucle. Ese será el próximo objetivo.

¿Te acuerdas de cuando los equipos hablaban de 'technical debt' (deuda técnica)? Una vez trabajé en una organización que congeló el desarrollo hasta que se corrigiera una buena parte de las vulnerabilidades pendientes para reducir la deuda técnica.

Creo que lo que veremos es que la identity debt se vuelva más relevante. ¿Cuántas cuentas inactivas o huérfanas hay en tu empresa ahora mismo? ¿A qué datos y servicios pueden acceder? ¿Tienes entornos legacy que se mantienen vivos 'por si acaso' y, de ser así, están debidamente aislados? ¿Y qué hay de la pregunta "qué permisos necesita realmente esta cuenta"? ¿Cuántas veces hemos visto que la respuesta es admin o root para asegurarse de que funcione? Robar cuentas para desplegar ransomware o exfiltrar datos es una cosa, pero hay más que solo el robo de credenciales.

Piénsalo más como la vía dominante a través de, más que de entrada. Si sale una vulnerabilidad en un dispositivo de borde, va a ser explotada, así que la explotación de vulnerabilidades como vector de acceso inicial sube y las credenciales robadas bajan; sin embargo, el abuso de credenciales casi siempre ocurrirá en algún punto de la cadena de ataque, así que, combinado, está presente en un porcentaje bastante alto de los ataques. Creo que hay varios factores impulsando este cambio. Hay tantas infecciones de infostealers produciendo credenciales en venta que son baratas y abundantes.

Y cuando digo abundantes, mira el informe anual de exposición de identidades de SpyCloud: ahora están rastreando 65,7 MIL MILLONES de identidades distintas, y eso es un 23% más que el año pasado. En segundo lugar, el perímetro parece ahora todo difuso. Con la infraestructura cloud y SaaS, el límite de red tradicional que antes defendíamos y usábamos como punto de estrangulamiento ya no existe. Ahora tenemos plantillas distribuidas y llamadas a API, acceso por tokens e integraciones de terceros. Esto pone el foco de lleno sobre la identidad.


8L: Si pudieras arreglar una sola cosa en cómo las organizaciones gestionan el threat intelligence o la gestión de exposición hoy, sin restricción de presupuesto ni de tecnología, ¿qué sería?

Aaron: Me encanta esta pregunta y suelo hacer algo parecido en las entrevistas. Hace poco rechacé una herramienta nueva y reluciente que haría todo tipo de cosas, porque la respuesta no era comprar algo nuevo y reluciente, era necesitar cambiar algo estructuralmente para extraer más valor de las herramientas y procesos existentes.

Los dos tienen que hablar entre sí. Si tu programa de threat intel no está influyendo en decisiones o acciones, probablemente esté aportando más ruido que valor. Por otro lado, si tu programa de vulnerability management está parcheando por score y no por riesgo, está al revés. A los actores de amenazas no les va a importar si una vulnerabilidad es un 9.8 o un 7.2, quieren saber si pueden explotarla.

"Parchea este crítico 9.8, por favor" es distinto de decir "Esta vulnerabilidad crítica está siendo explotada activamente en el mundo real por actores de amenazas estatales que creemos que tienen interés en nuestra organización, por favor remedia cuanto antes". Unir las dos cosas aporta contexto, lo que permite priorización, responsabilidad y el respaldo de la dirección cuando reconocen la urgencia.


8L: ¿Tienes alguna opinión impopular sobre threat intelligence, vulnerability management o seguridad de identidad que defenderías aun sabiendo que mucha gente no estaría de acuerdo?

Aaron: Vale, allá voy... La mayoría de los feeds de threat intel son un desperdicio de dinero...

Para empezar, si todavía no tienes un programa de inteligencia maduro, no te lances a comprar feeds para poblar tu TIP (threat intelligence platform). Si lo haces, estarás informado, o al menos eso creerás. Digamos que pasa una semana y has ingerido montones de IOCs relucientes. Ahora eres consciente del panorama de amenazas (hasta cierto punto), pero ¿ha cambiado la postura de seguridad de la organización respecto a la semana anterior, antes de que tuvieras todos esos IOCs? Probablemente no, y lo más seguro es que sea porque, si tienes un programa inmaduro, te falta la capacidad de actuar sobre lo que acabas de ingerir. Así que añadir más feeds solo añade más indicadores, más que tu equipo tiene que triar.

¿De verdad necesitas múltiples suscripciones premium de inteligencia? Muchas veces los actores de amenazas reciclan los indicadores tan rápido que los datos del feed están obsoletos. Cuando estés listo, elige el que te dé más contexto según las necesidades de negocio de tu organización (los ISACS y otros grupos de pares también son buenos). En realidad, tu mejor fuente de inteligencia es la telemetría interna, así que, en lugar de comprar tu feed de inteligencia número 27, habla con tus equipos de IAM y SOC sobre registrar anomalías de inicio de sesión, impossible travel, abuso de tokens, revisar los logs de escalada de privilegios en tus tenants cloud y construir un inventario de las cuentas de servicio con sus mapeos de acceso. Eso te dará una inteligencia de muchísima mayor fidelidad que otro feed.



Si algo queda de esta conversación con Aaron, es un cambio en dónde vive lo "malo". El archivo malicioso ha desaparecido; lo que queda es una credencial válida, usada por las manos equivocadas. Y la deuda que se acumula en silencio, como las cuentas inactivas, los accesos huérfanos, la cuenta de servicio que corre como admin "para que funcione", es justo el terreno que los atacantes recorren ahora. Menos gasto en el feed de inteligencia número 27, más atención a las identidades que ya tienes. Ahí es, al final, donde está la señal.


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.