Modelo de madurez para la seguridad del navegador (II) ~ Segu-Info

Hasta hace poco, la metodología de los ciberatacantes detrás de las mayores
brechas de seguridad, había sido bastante consistente:

  1. comprometer un endpoint mediante un exploit, malware o a través del
    uso de ingeniería social para que un usuario ejecute «algo» en su
    dispositivo;
  2. buscar maneras de moverse lateralmente dentro de la red y comprometer
    identidades privilegiadas;
  3. repetir la operación según sea necesario hasta que se pueda ejecutar el
    ataque deseado, generalmente robando datos de recursos compartidos de
    archivos, implementando ransomware o ambas cosas.

Pero los ataques han cambiado radicalmente con la evolución de las redes. Con
la «SaaSización» de la TI empresarial, los sistemas centrales del
negocio ya no se implementan localmente ni se gestionan centralmente como
antes. En su lugar, se inicia sesión en ellos a través de internet y se accede
a ellos mediante un navegador web.

Bajo el modelo de responsabilidad compartida, la parte que le corresponde a la
empresa que consume un servicio SaaS se limita principalmente a la gestión de
las identidades, el vehículo mediante el cual los empleados acceden y utilizan
la aplicación. No es de extrañar que esto se haya convertido en el punto débil
de los atacantes.

Lo hemos visto repetidamente en las mayores brechas de seguridad de los
últimos años, entre las que destacan la masiva
campaña Snowflake de 2024
y la
ola de delitos de 2025 atribuida a Scattered Spider. Estos ataques tienen tanto éxito porque, si bien los atacantes se han
adaptado a los cambios en la TI empresarial, la seguridad no ha seguido el
ritmo.

El
navegador es el nuevo campo de batalla
y un punto ciego de seguridad. 
El robo de identidades de los empleados es el primer objetivo de los
atacantes que buscan atacar a una organización, y el navegador es el lugar
donde se producen los ataques contra los usuarios.

Esto se debe a que es donde se crean y utilizan estas identidades digitales, y
donde residen sus credenciales y sesiones. Esto es lo que el atacante quiere
conseguir.

Las credenciales robadas pueden usarse como parte de ataques dirigidos o en un
robo de credenciales más amplio (utilizando nombres de usuario y credenciales
conocidos en diversas aplicaciones y plataformas), mientras que los tokens de
sesión robados pueden usarse para iniciar sesión directamente en una sesión
activa, omitiendo el proceso de autenticación.

Existen diferentes técnicas que los atacantes pueden usar para acceder a estas
identidades. Los atacantes obtienen credenciales robadas de diversos lugares:
volcados de datos filtrados, campañas masivas de phishing de credenciales,
registros de robo de información e incluso extensiones de navegador maliciosas
que han instalado engañando a un empleado. De hecho, el propio ecosistema de
la ciberdelincuencia ha cambiado su eje para abordar esto, y los atacantes se
encargan específicamente de obtener credenciales y establecer acceso a las
cuentas para que otros las exploten.

Las filtraciones de Snowflake de 2024 marcaron un hito en la transición hacia
las filtraciones basadas en la identidad, donde los atacantes iniciaron sesión
en cuentas de cientos de inquilinos de clientes utilizando credenciales
robadas. Una de las principales fuentes de las credenciales robadas utilizadas
en los ataques fueron los registros de infostealers que datan de 2020:
contraseñas vulneradas que no se habían rotado ni mitigado con MFA.

Los infostealers son conocidos por ser un ataque de malware de
endpoints diseñado para recopilar credenciales y tokens de sesión
(principalmente del navegador) para que el atacante pueda iniciar sesión en
esos servicios a través de su propio navegador web. Por lo tanto, incluso en
los ataques actuales a endpoints, el atacante recurre al navegador para
acceder a las identidades, la clave de las aplicaciones y servicios en línea
donde ahora residen los datos y las funcionalidades susceptibles de ser
explotadas.

Ataques en el navegador vs. contra el navegador

Hay que distinguir entre los ataques que ocurren en el navegador y los que se
producen contra el propio navegador.

Existe un consenso creciente de que el navegador es el nuevo endpoint. Pero la
analogía no es perfecta: la realidad es que los navegadores web tienen una
superficie de ataque relativamente limitada en comparación con la complejidad
del endpoint tradicional. Comparar algo como Google Chrome con un sistema
operativo Windows parece un concepto increíble.

Los ataques que tienen como objetivo el propio navegador como mecanismo para
comprometer identidades son escasos. Uno de los vectores más obvios es el uso
de extensiones de navegador maliciosas; por lo tanto, se presentan escenarios
en los que un usuario:

  • Ha sido inducido a instalar una extensión ya maliciosa, o
  • Está usando una extensión de navegador que posteriormente es comprometida
    por un atacante.

Pero el problema de las extensiones maliciosas es algo que se resuelve una vez
y luego se pasa a otra cosa. La realidad es que los usuarios no deberían
instalar extensiones de navegador aleatorias y, dado el riesgo, se debería:

  • Bloquear el entorno para permitir solo unas pocas extensiones esenciales.
  • Monitorear los indicadores de que una extensión de confianza está
    comprometida.

Esto no aplica en un entorno donde se otorga a los usuarios acceso total para
instalar las extensiones que deseen.
Pero si el navegador es el nuevo endpoint, es como si todos tus usuarios
fueran administradores locales: te estás buscando problemas.

Bloquear las extensiones en tus organizaciones es algo que se puede lograr con
herramientas nativas si, por ejemplo, eres cliente de Chrome Enterprise:
audita a tus usuarios una vez, aprueba solo lo necesario y solicita nuevas
aprobaciones para instalar nuevas extensiones.

La identidad es el objetivo, el navegador es la plataforma, y el phishing es
el arma predilecta.

¿Pero la técnica que SIGUE provocando las filtraciones de identidad más
impactantes? Es el phishing. Phishing para obtener credenciales, sesiones,
consentimiento de OAuth, códigos de autorización. Phishing por correo
electrónico, mensajería instantánea, redes sociales, anuncios maliciosos de
Google… todo ocurre en el navegador o conduce a él.

Y los ataques de phishing modernos son más efectivos que nunca. Hoy en día, el
phishing opera a escala industrial, utilizando diversas técnicas de ofuscación
y evasión de detección para impedir que las herramientas de seguridad del
correo electrónico y la red los intercepten. Probablemente, el ejemplo más
común hoy en día sea el uso de protección contra bots (como reCAPTCHA o
Cloudflare Turnstile), utilizando funciones antispam legítimas para bloquear
las herramientas de seguridad.

La última generación de
kits de phishing AitM
totalmente personalizados ofusca dinámicamente el código que carga la página
web, implementa CAPTCHA personalizado y utiliza funciones antianálisis en
tiempo de ejecución, lo que dificulta cada vez más su detección. La forma en
que se envían los enlaces también se ha vuelto más sofisticada, con más
canales de entrega y el uso de servicios SaaS legítimos para camuflarse.

Y las últimas tendencias indican que los atacantes están respondiendo a una
configuración de IdP/SSO cada vez más reforzada explotando técnicas de
phishing alternativas que eluden el MFA y las PassKeys, más comúnmente
mediante la degradación a un método de autenticación en el cual el phishing
tradicional funcione. Leer más sobre esto
aquí.

Las identidades son el blanco más fácil para los atacantes.


El objetivo del atacante moderno, y la forma más sencilla de acceder al
entorno digital de la empresa, es comprometer las identidades.

Ya sea que se trate de ataques de phishing, extensiones de navegador
maliciosas o malware para robar información, el objetivo sigue siendo el
mismo: el robo de cuentas.

Las organizaciones se enfrentan a una amplia y vulnerable superficie de ataque
compuesta por:

Un factor clave de la vulnerabilidad de identidad es la enorme variabilidad en
la configurabilidad de las cuentas por aplicación, con diferentes niveles de
visibilidad centralizada y control de seguridad de las identidades. Por
ejemplo, mientras que una aplicación puede bloquearse para que solo acepte
inicios de sesión SSO mediante SAML y elimine automáticamente las contraseñas
no utilizadas, otra no ofrece control ni visibilidad del método de inicio de
sesión ni del estado de MFA (otro factor clave de las brechas de Snowflake del
año pasado). Desafortunadamente, como consecuencia del crecimiento impulsado
por el producto y algo que se agrava con cada nueva SaaS que llega al mercado,
esta situación no parece que vaya a cambiar pronto.

El resultado final es que las identidades están mal configuradas, son
invisibles para el equipo de seguridad y son explotadas rutinariamente por
herramientas de ataque convencionales. No es de extrañar que sean el
objetivo principal de los atacantes hoy en día.

La solución: El navegador como fuente de telemetría y punto de control

Dado que los ataques de identidad se producen en el navegador, es el lugar
perfecto para que los equipos de seguridad los observen, intercepten y
detengan. El navegador ofrece varias ventajas sobre los diferentes lugares
donde se puede observar y proteger la identidad, ya que:

  • No se limita a las aplicaciones e identidades directamente conectadas a su
    proveedor de identidad (una fracción de la proliferación de identidades de
    su plantilla).
  • No se limita a las aplicaciones que conoce y gestiona centralmente: puede
    observar cada inicio de sesión que pasa por el navegador.
  • Puede observar todas las propiedades de un inicio de sesión, incluyendo el
    método de inicio de sesión, el método de MFA, etc. De lo contrario,
    necesitaría acceso a la API para obtener esta información (dependiendo de si
    se proporciona una API y de si estos datos específicos se pueden consultar,
    lo cual tampoco es estándar para muchas aplicaciones).


Con todo lo que hemos visto hasta ahora, es obvio que solucionar cada
vulnerabilidad de identidad es una tarea inquietante: el propio ecosistema
SaaS está trabajando en su contra.

Por eso es esencial detectar y responder a los ataques de identidad. Dado que
la vulneración de la identidad casi siempre implica phishing o ingeniería
social para que un usuario realice una acción en su navegador (con algunas
excepciones, como los
ataques al servicio de asistencia relacionados con Scattered Spider
vistos recientemente), también es el lugar perfecto para monitorear e
interceptar ataques.

En el navegador, se recopila información detallada y contextualizada sobre el
comportamiento de la página y las entradas del usuario, que puede utilizarse
para detectar y detener escenarios de riesgo en tiempo real. Tomemos el
ejemplo de las páginas de phishing. Dado que Push opera en el navegador, lo ve
todo:

  • El diseño de la página
  • De dónde proviene el usuario
  • La contraseña que introduce (como un hash abreviado con Salt)
  • Qué scripts se están ejecutando
  • Y a dónde se envían las credenciales

Conclusión

Los ataques de identidad son el mayor problema sin resolver al que se
enfrentan los equipos de seguridad hoy en día y la principal causa de brechas
de seguridad. Al mismo tiempo, el navegador ofrece a los equipos de seguridad
todas las herramientas necesarias para prevenir, detectar y responder a
ataques basados en la identidad: de forma proactiva, al encontrar y corregir
vulnerabilidades de identidad, y de forma reactiva, al detectar y bloquear
ataques contra usuarios en tiempo real.

Las organizaciones necesitan superar las antiguas formas de gestionar la
seguridad de la identidad, que se basaban en atestaciones de MFA, paneles de
gestión de identidades y herramientas antiphishing tradicionales para correo
electrónico y red. Y no hay mejor lugar para detener estos ataques que el
navegador.

Fuente:
THN


Ver fuente

Related Post