Aplicaciones expuestas, credenciales válidas y confianza abusada: así entra hoy un atacante

El dato que merece atención no es que los atacantes sigan entrando. Eso ya lo sabíamos. Lo incómodo es por dónde: en 2025, más del 80% de los incidentes analizados por Kaspersky Security Services arrancaron por tres vías bastante poco glamourosas y muy eficaces: aplicaciones expuestas a Internet (43,7%), cuentas válidas comprometidas (25,4%) y relaciones de confianza abusadas entre sistemas o proveedores (11,8%). La suma da 80,9%. El resto son técnicas, matices y ruido. La puerta principal sigue siendo una puerta mal cerrada.

Eso desmonta una fantasía persistente en muchos comités de dirección: que el riesgo grave siempre empieza con una amenaza “avanzada”, una zero-day de película o una banda de ransomware con branding cuidado. A veces sí. Pero la estadística vuelve a ser cruel con el relato corporativo. El ataque medio empieza con algo mundano: una VPN sin MFA robusto, una consola expuesta, una cuenta de servicio con privilegios excesivos, una federación de confianza que nadie revisó desde 2022 o un proveedor que entra por una conexión que en papel estaba “controlada”.

La noticia no es solo técnica. Tiene implicaciones directas para banca, seguros, fintech y cualquier organización europea que esté intentando cuadrar tres tableros a la vez: DORA, NIS2 y las obligaciones de notificación de incidentes bajo GDPR cuando hay datos personales afectados. Y aquí aparece la ironía regulatoria habitual: muchas empresas llevan dos años refinando políticas, matrices y presentaciones, mientras los atacantes siguen entrando por el mismo trío de siempre.

La pregunta útil no es si tu organización tiene firewall, EDR o un SOC que manda gráficos muy bonitos. La pregunta útil es otra: si mañana un adversario prueba tus activos expuestos, roba una credencial válida o pivota desde un tercero, cuánto tarda tu equipo en detectarlo, cortarlo y demostrar que el control existía de verdad.

Lo que dicen los números, y lo que de verdad significan

La cifra de Kaspersky encaja con una tendencia que otras fuentes llevan años describiendo desde ángulos distintos. Verizon, en su Data Breach Investigations Report, viene insistiendo desde hace tiempo en el peso de las credenciales robadas y el abuso de accesos legítimos. Mandiant, CrowdStrike y Microsoft repiten otra idea similar con vocabulario propio: la intrusión moderna tiende a parecer actividad administrativa normal. El atacante no necesita romper una puerta si puede abrirla con una llave robada.

Por eso conviene separar las tres vías que destaca el informe, porque juntas parecen una lista táctica y en realidad describen fallos estructurales de gobierno.

Aplicaciones expuestas no significa solo “un servidor visible en Internet”. Significa superficies de ataque que la organización no ha inventariado bien, no parchea a tiempo o publica con configuraciones inseguras. Aquí caben portales VPN, gateways de acceso remoto, paneles de administración, appliances perimetrales, herramientas de transferencia de archivos, entornos de desarrollo olvidados y aplicaciones web internas convertidas en semipúblicas por pura inercia operativa. Basta recordar cómo se han explotado en los últimos años fallos en Citrix NetScaler, Ivanti Connect Secure o MOVEit Transfer para entender que el perímetro sigue lleno de activos con capacidad de abrir una brecha sistémica.

Cuentas válidas es un concepto todavía más delicado. Porque cuando el atacante usa credenciales auténticas, muchos controles se vuelven mucho menos útiles. El evento entra con menos fricción, genera menos ruido y se mezcla con la operación normal. Esto incluye robo de credenciales vía phishing, infostealers, reutilización de contraseñas, fatiga de MFA, secuestro de sesión, abuso de tokens y, cada vez más, compromiso de cuentas privilegiadas o de servicio. No hace falta malware ruidoso si tienes una contraseña correcta y un acceso remoto que nadie vigila de verdad.

Relaciones de confianza es la tercera pieza, y la más infravalorada por muchas organizaciones. Aquí hablamos de conexiones B2B, integraciones con terceros, accesos de mantenimiento, federaciones de identidad, conectividad entre filiales, herramientas RMM, API con permisos excesivos y toda esa infraestructura de confianza que funciona muy bien hasta que deja de hacerlo. El problema es conceptual: una vez que algo se clasifica internamente como “relación confiable”, suele recibir menos escrutinio del que merece. Y a los atacantes les encanta eso.

Si uno mira la distribución, hay una lectura obvia y otra menos cómoda. La obvia: el perímetro sigue importando. La menos cómoda: identidad, exposición externa y terceros ya no son dominios separados. Son el mismo problema visto desde tres consolas distintas. El atacante explota una aplicación expuesta para robar tokens, usa la cuenta válida para moverse lateralmente y aprovecha una relación de confianza para escalar o persistir. Quien siga gestionando estos riesgos por silos organizativos va tarde.

Aplicaciones expuestas: el viejo problema que nadie ha resuelto del todo

La superficie expuesta a Internet ha crecido por motivos perfectamente racionales: trabajo remoto, APIs para socios, migración a cloud, automatización de despliegues, herramientas SaaS, acceso de terceros y presión comercial por publicar más rápido. El resultado no siempre es racional. El resultado suele ser una mezcla de activos conocidos, activos olvidados y activos que nadie sabía que seguían ahí.

La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE.UU. (CISA) mantiene desde hace años su catálogo de Known Exploited Vulnerabilities (KEV), una lista que, con una constancia casi deprimente, demuestra la misma lección: los atacantes no necesitan necesariamente la vulnerabilidad más sofisticada; necesitan una que siga expuesta y sin remediar. En abril de 2024, por ejemplo, CISA añadió vulnerabilidades explotadas en Ivanti Connect Secure, y ese patrón se ha repetido con múltiples fabricantes de edge devices. Cada nueva crisis trae titulares; lo relevante es que el vector no cambia.

En el ecosistema financiero europeo, este punto importa especialmente por dos razones. Primero, porque muchas entidades han multiplicado interfaces expuestas para atender canales digitales, ecosistemas de pago, open banking y operaciones con terceros. Segundo, porque DORA obliga a tener inventario, clasificación, protección y monitorización de activos y componentes TIC, no solo políticas bonitas. El artículo 8 de DORA exige un marco de gestión del riesgo TIC sólido y bien documentado; el artículo 9 entra en identificación; y el artículo 10 se mete de lleno en protección y prevención. Si no sabes qué está expuesto, no puedes defenderlo ni demostrar que lo gestionas.

La lección operativa es poco elegante, pero muy rentable: el control más infravalorado sigue siendo un inventario externo continuo. No una foto trimestral. Continuo. Una entidad puede tener CMDB, escáneres y procesos ITIL impecables en PowerPoint, pero si no contrasta de forma recurrente qué ve Internet de ella, el mapa interno sirve de poco. Herramientas de ASM (attack surface management), escaneo autenticado y no autenticado, correlación con DNS, certificados, activos cloud y validación de exposición real son ya higiene básica. No “madurez aspiracional”. Higiene.

Y luego llega el segundo problema: el tiempo. Entre la publicación de una vulnerabilidad crítica, la explotación activa y la ventana real de parcheo, muchas organizaciones siguen operando con ciclos demasiado lentos. Ahí está el choque permanente entre seguridad y negocio. El negocio pide disponibilidad; seguridad pide cambio urgente. El atacante, mientras tanto, ni siquiera entra en la reunión.

NIS2 es bastante menos paciente con esa tensión de lo que eran algunas normas previas. El artículo 21 de la Directiva (UE) 2022/2555 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas, incluyendo gestión de incidentes, continuidad, seguridad en la cadena de suministro y prácticas básicas de higiene cibernética. “Apropiadas y proporcionadas” suena flexible, sí, pero no significa optativo. Si un activo crítico sigue expuesto con una vulnerabilidad ya explotada públicamente, costará bastante defender ante un regulador que la gestión del riesgo era razonable.

Cuando la credencial es legítima, el atacante parece un empleado más

El abuso de cuentas válidas es uno de esos problemas que todo el mundo dice entender y muy pocas organizaciones han domesticado de verdad. ¿La razón? Porque obliga a tocar identidad, privilegios, procesos de altas y bajas, telemetría, autenticación, PAM, IAM, SSO, acceso de proveedores y, en el peor de los casos, política interna. O sea: todo aquello que genera fricción.

El vector puede empezar con phishing clásico, pero eso sería simplificar demasiado. Hoy las credenciales se filtran por múltiples canales: equipos infectados por infostealers, robo de cookies de sesión, repositorios con secretos expuestos, contraseña reutilizada en servicios personales, APIs mal protegidas o acceso comprado en foros criminales. A partir de ahí, el atacante opera con una ventaja crucial: usa una identidad que tus sistemas reconocen como válida.

Eso cambia la defensa. La cuestión ya no es solo bloquear malware, sino distinguir uso legítimo de uso anómalo. Y eso exige combinar varias capas:

• Autenticación multifactor resistente al phishing, preferiblemente basada en FIDO2 o métodos equivalentes para perfiles sensibles.
• Políticas de acceso condicional según riesgo, dispositivo, geolocalización, hora y patrón de comportamiento.
• Revisión estricta de cuentas privilegiadas, de servicio y técnicas, que suelen ser el cajón desastre de casi todas las auditorías.
• Telemetría que permita detectar imposibles lógicos: inicio de sesión desde dos geografías incompatibles, elevaciones de privilegio inesperadas, creación de persistencia, acceso masivo fuera de patrón o uso de herramientas administrativas atípicas.

Aquí aparece un detalle que muchas organizaciones subestiman: las cuentas de servicio y las cuentas no humanas son un agujero clásico. Tienen privilegios amplios, credenciales de larga duración y menos supervisión que los usuarios humanos. Son cómodas para operar y magníficas para comprometer. En entornos híbridos y cloud, además, el abuso ya no se limita a contraseñas: tokens, secretos embebidos, claves API y permisos de workloads forman parte del mismo problema.

Desde la perspectiva regulatoria, esto cruza varias capas. DORA exige controles sobre gestión de acceso, autenticación y registro de eventos dentro del marco de gestión del riesgo TIC. NIS2 mete presión sobre seguridad operativa y gestión de incidentes. Y si el compromiso de una cuenta termina afectando a datos personales, aparece GDPR art. 33, que obliga a notificar a la autoridad de control una violación de seguridad de los datos personales sin dilación indebida y, de ser posible, a más tardar 72 horas desde que se tenga constancia, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas físicas. Si el riesgo es alto para los afectados, GDPR art. 34 puede activar además la comunicación a los interesados.

La consecuencia práctica es bastante dura para cualquier CISO: si no puedes reconstruir rápidamente qué hizo una cuenta comprometida, no solo tienes un problema técnico; tienes un problema de notificación, de gobernanza y de responsabilidad ejecutiva. Y eso ya no se resuelve con una frase vaga sobre “investigación en curso”.

La confianza entre sistemas se ha convertido en el atajo favorito

Las relaciones de confianza merecen bastante más protagonismo del que suelen recibir. Porque son el punto exacto donde confluyen tres obsesiones del regulador europeo actual: resiliencia operativa, terceros críticos y cadena de suministro.

Una relación de confianza puede ser técnica, contractual o ambas. Pensemos en un proveedor de IT con acceso remoto al entorno productivo, una integración API con permisos de escritura, una federación SAML mal segmentada, una herramienta de gestión remota desplegada en múltiples sedes o una filial que comparte directorio y privilegios con la matriz. Todo eso ahorra tiempo, reduce coste y acelera operaciones. Hasta que uno de esos nodos cae. Entonces descubres que la “confianza” era en realidad una exención implícita de controles.

La cadena de suministro ya dejó de ser una nota al pie hace tiempo. El artículo 28 de DORA obliga a las entidades financieras a gestionar el riesgo asociado a terceros proveedores de servicios TIC como parte integral del riesgo TIC. No es una capa separada; es parte del mismo sistema de control. Los artículos 30 y 31 bajan más al detalle con el contenido de los acuerdos contractuales y las obligaciones en torno a subcontratación y supervisión. NIS2 va en la misma dirección: el artículo 21.2.d menciona expresamente la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos.

La lectura operativa aquí no admite demasiados eufemismos. Si tu proveedor tiene acceso persistente a tu entorno, su postura de seguridad es parte de tu postura de seguridad. Y si no tienes visibilidad real sobre ese acceso —cuándo se usa, desde dónde, con qué privilegios, sobre qué activos y con qué controles de registro— entonces no tienes una relación de confianza; tienes una apuesta.

Este punto afecta especialmente al sector financiero por la concentración tecnológica. Muchas entidades dependen de un conjunto reducido de hyperscalers, procesadores, proveedores de software core, servicios de ciberseguridad gestionada y terceros especializados. El riesgo no es solo individual, también es sistémico. DORA lo reconoce de forma explícita al introducir un marco de supervisión sobre proveedores terceros de TIC designados como críticos a escala de la UE. La señal del regulador es clara: la dependencia de terceros deja de ser un asunto privado de procurement y pasa a ser una cuestión de resiliencia del sistema financiero.

La mala noticia para el comité: esto no se arregla comprando otra herramienta

Cuando la estadística apunta a exposición externa, accesos válidos y confianza abusada, la reacción instintiva de muchas empresas es pedir más tecnología. A veces hace falta. Muy a menudo hace falta otra cosa antes: disciplina operativa. Porque estos vectores prosperan menos por ausencia total de herramientas que por mala ejecución de controles ya conocidos.

Veamos tres ejemplos.

Primero, gestión de vulnerabilidades. Muchas organizaciones escanean, priorizan y parchean. Sobre el papel, perfecto. En la práctica, las excepciones se acumulan, los activos críticos no están bien clasificados, las ventanas de mantenimiento son escasas y la remediación de edge devices compite con la aversión al cambio. Resultado: exposición prolongada. El problema no es no escanear. El problema es no cerrar.

Segundo, identidad. Hay SSO, MFA y PAM, sí. Pero persisten cuentas huérfanas, cuentas de servicio sin rotación, privilegios heredados, accesos de terceros sin caducidad, administradores locales fuera de control y autenticación fuerte aplicada solo a una parte del entorno. El problema no es no tener IAM. El problema es no gobernarlo con rigor.

Tercero, terceros. Existe un proceso de due diligence, incluso cuestionarios de seguridad y cláusulas contractuales. Todo muy correcto. Pero luego aparecen accesos remotos permanentes, poca visibilidad de subcontratistas, registros insuficientes, dependencias críticas sin pruebas de resiliencia y contratos que no reflejan necesidades reales de monitoreo, auditoría o salida ordenada. El problema no es carecer de contrato. El problema es creer que el contrato sustituye al control.

Por eso la respuesta madura no es “comprar XDR y esperar lo mejor”, sino reorganizar el modelo de defensa alrededor de tres ejes conectados: exposición, identidad y confianza. Ese triángulo explica hoy una parte enorme del riesgo real.

Qué deberían revisar ya los equipos de seguridad y compliance

Si el dato de Kaspersky sirve para algo más que para decorar una presentación, debería traducirse en decisiones muy concretas durante este trimestre. No en 2026. Ahora.

La primera revisión debe centrarse en qué ve Internet de tu organización. No solo dominios principales. También subdominios olvidados, entornos de pruebas, consolas administrativas, proveedores con marca compartida, servicios cloud vinculados a certificados emitidos a nombre de la entidad y APIs accesibles desde fuera. Aquí importa correlacionar inventario interno con descubrimiento externo real. Si las dos listas no coinciden, la correcta suele ser la que ve Internet, no la CMDB.

La segunda revisión va a credenciales y accesos. Eso exige una limpieza menos vistosa y más útil: cuentas sin uso reciente, privilegios permanentes que deberían ser temporales, administradores compartidos, cuentas de terceros sin justificación vigente, aplicaciones con secretos de larga duración y MFA ausente o débil en accesos remotos, correo, VPN, consolas cloud y herramientas administrativas. Una organización que no puede responder cuántas cuentas privilegiadas activas tiene hoy no está gobernando identidad; la está tolerando.

La tercera se enfoca en relaciones de confianza. Haz una pregunta simple a cada acceso de tercero o integración sensible: ¿qué pasaría si ese proveedor se compromete mañana? Si la respuesta es difusa, la confianza está sobredimensionada. Conviene revisar segmentación, permisos mínimos, caducidad de accesos, trazabilidad, dependencias de subcontratación y capacidad contractual de auditoría. Bajo DORA, ese ejercicio no es cosmética de compliance; es gestión material del riesgo de terceros.

La cuarta tiene que ver con detección. Muchas intrusiones basadas en cuentas válidas fallan menos por falta de prevención que por falta de señales bien afinadas. Los equipos deben confirmar si están detectando eventos de alto valor: autenticaciones anómalas, creación de nuevas relaciones de confianza, cambios en privilegios, accesos de proveedores fuera de horario, uso inusual de herramientas de administración remota, nuevos túneles o mecanismos de persistencia, y exfiltración desde sistemas con datos sensibles. Si el SOC sigue inundado de alertas de bajo valor y ciego ante cambios de identidad críticos, hay un problema de diseño, no solo de capacidad.

La quinta es incómoda pero imprescindible: probar. DORA, en sus artículos 24 a 27, establece un marco de pruebas de resiliencia operativa digital, incluyendo pruebas acordes al tamaño, perfil de riesgo y complejidad de la entidad, y para algunas entidades, threat-led penetration testing (TLPT). No se trata únicamente de pentests de escaparate. Se trata de validar si una cadena realista de ataque basada en exposición externa, abuso de identidad y pivotaje por terceros puede ser detectada y contenida. Si tus pruebas siguen midiendo solo vulnerabilidades aisladas y no rutas de acceso reales, estás auditando piezas, no resiliencia.

Para las entidades financieras españolas, aquí hay algo más que higiene técnica

En España, la lectura de este patrón debe hacerse con una doble lente: la operativa y la supervisora. Desde el 17 de enero de 2025, DORA es aplicable. Eso significa que bancos, aseguradoras, entidades de pago, proveedores de servicios de criptoactivos cubiertos y otras entidades financieras dentro de su ámbito ya no están en fase de “preparación conceptual”. Están en fase de demostrar ejecución.

Eso afecta a la forma de interpretar un incidente. Una aplicación expuesta vulnerable ya no es solo una debilidad técnica. Puede ser una evidencia de inventario incompleto, de protección insuficiente o de priorización de riesgos deficiente bajo el marco de DORA. Una cuenta válida comprometida no es solo un compromiso de identidad. Puede activar requisitos de clasificación, respuesta, registro, escalado interno y, si hay datos personales, análisis de notificación por GDPR. Una relación de confianza abusada con un proveedor puede abrir preguntas directas sobre gobernanza de terceros TIC, contenido contractual, supervisión continua y capacidad de salida.

Además, el sector financiero español no opera en un vacío nacional. Está sometido a supervisores europeos y nacionales, a exigencias de auditoría interna, a expectativas del consejo y, cada vez más, a la necesidad de demostrar resiliencia de forma transversal. El viejo reparto de papeles —seguridad gestiona la técnica, compliance el papel y negocio la continuidad— ya no aguanta bien ante incidentes que cruzan los tres planos en horas.

Si una entidad sufre una intrusión iniciada por cuenta válida robada y el atacante accede a datos de clientes, el reloj corre en paralelo en varios frentes: contención, forense, continuidad operativa, evaluación de impacto, notificación a autoridad de protección de datos si aplica, comunicación al supervisor sectorial conforme a los canales de incidente pertinentes y, en algunos casos, evaluación del impacto contractual sobre terceros. Lo que antes podían ser departamentos coordinándose con cierta calma hoy se parece más a una carrera de relevos con cronómetro legal.

El verdadero cambio: dejar de pensar en vectores aislados

Hay un error de diseño bastante extendido en la defensa corporativa: tratar las aplicaciones expuestas, las credenciales comprometidas y las relaciones de confianza como disciplinas distintas. No lo son. Forman una misma cadena de ataque. Y quien no la vea completa seguirá reaccionando tarde.

Un escenario perfectamente plausible en 2025 es este: un appliance expuesto tiene una vulnerabilidad o una configuración débil; el atacante obtiene acceso inicial o roba material de autenticación; usa una cuenta válida para moverse sin hacer demasiado ruido; identifica una integración con un tercero o una confianza entre entornos; expande privilegios, exfiltra datos o impacta operaciones. En el comité, meses después, cada equipo explicará su trozo: infraestructura hablará del perímetro, IAM hablará de identidad, procurement del proveedor, legal de notificación y negocio de continuidad. El atacante, en cambio, vio un solo camino.

Ese es precisamente el cambio que están insinuando las regulaciones europeas más recientes. DORA no separa alegremente riesgo técnico, continuidad, terceros y pruebas; los mete en un mismo sistema de resiliencia. NIS2 tampoco trata la cadena de suministro como apéndice decorativo. El mensaje del legislador, por una vez, coincide con la realidad operativa: la ciberseguridad efectiva ya no consiste en acumular controles por dominio, sino en conectar exposición, identidad, terceros y respuesta.

Quien siga midiendo su madurez con listas estáticas de controles puede sentirse cómodo. El problema es que los atacantes miden otra cosa: caminos transitables. Y en 2025 esos caminos siguen pasando, de forma mayoritaria, por lo que la empresa expone, por las identidades que no gobierna bien y por la confianza que concede con demasiada alegría.

Lo que viene ahora: menos tolerancia regulatoria y más presión probatoria

La consecuencia más probable de datos como estos no es un giro doctrinal dramático de los reguladores. No hace falta. El marco legal ya existe. Lo que sí cabe esperar es menos paciencia con excusas operativas conocidas y más insistencia en la evidencia.

Cuando una entidad alegue que sufrió una intrusión por una aplicación expuesta, la pregunta del supervisor no será filosófica. Será concreta: qué activo era, cómo estaba clasificado, qué exposición tenía, qué vulnerabilidades acumulaba, cuándo se detectaron, qué decisiones se tomaron y quién aprobó la excepción. Si el incidente vino por cuenta válida comprometida, llegarán preguntas igual de secas: qué MFA existía, qué logs se conservaron, cómo se detectó el uso anómalo, cuánto tardó la contención y si había segregación de privilegios. Y si hubo un proveedor de por medio, aparecerá el expediente completo de la relación: contrato, controles, trazabilidad, subcontratación, supervisión y pruebas.

Eso cambia también el trabajo de compliance. Ya no basta con verificar que existe una política de terceros o un estándar de acceso remoto. Hay que comprobar si el diseño del control produce evidencia suficiente cuando algo falla. Dicho de otro modo: la próxima auditoría útil no es la que valida que el procedimiento existe, sino la que confirma que sobreviviría a un incidente real.

Quien lea el dato de Kaspersky como otra estadística anual más está perdiendo la pista principal. Lo que muestran esos porcentajes es una jerarquía muy simple de riesgo real. Primero, lo que expones. Segundo, a quién dejas entrar. Tercero, en quién confías cuando ya está dentro. El resto, por sofisticado que suene, viene después.

Y esa es quizá la conclusión menos espectacular y más valiosa de todas: el atacante moderno no siempre necesita inventar nada nuevo; le basta con aprovechar que la organización sigue tratando como problemas separados lo que en realidad forma una sola superficie de compromiso. Si tu entidad no ha unido aún esos tres mapas —externo, identitario y de terceros—, ya sabe por qué debería hacerlo antes de que alguien lo haga por ella.