El desafío operativo de los registros de infostealer
Los registros de infostealer han evolucionado de ser un producto underground a un problema de seguridad operativo. Para los defensores, encontrar una credencial expuesta es solo el comienzo. En la realidad actual, muchos analistas de seguridad comienzan su mañana con una alerta: la dirección de correo electrónico corporativa de un empleado ha aparecido en un registro de infostealer recién recopilado.
El registro contiene un nombre de usuario y una contraseña para una aplicación SaaS corporativa. Hay cookies de navegador, lo que significa que hay sesiones activas que pueden ser explotadas, y otras credenciales guardadas en archivos. Una computadora personal de un empleado se infectó con Vidar, ubicada a cientos de kilómetros de las oficinas de la empresa. ¿Y ahora qué?
Restablecer la contraseña expuesta parece obvio. Pero eso puede no resolver el problema. Si el ladrón capturó una cookie de sesión autenticada, un atacante ya puede tener una vía de acceso a la aplicación sin necesidad de contraseña o de otra solicitud de MFA. Si el empleado reutilizó credenciales corporativas en una computadora personal, el endpoint que creó la exposición puede que ni siquiera esté gestionado por la organización. Y en algún canal de Telegram underground, la misma información ya puede estar disponible para un corredor de acceso inicial, un afiliado de ransomware o un atacante oportunista.
Este es el desafío operativo al que se enfrentan cada vez más los equipos de seguridad con los registros de infostealer. Según la Guía del profesional para monitorear registros de stealers de Flare Research, aproximadamente el 46% de los registros de stealers que contienen credenciales corporativas se originan en dispositivos probablemente no gestionados o personales. Flare también estima que la exposición que involucra credenciales y sesiones para SaaS y servicios en la nube importantes de productividad está creciendo aproximadamente un 29% anualmente.
Para los defensores, la pregunta ya no es simplemente si deben monitorear los registros de infostealer. La pregunta más difícil es: ¿cómo separar una contraseña antigua sin importancia de un compromiso de identidad que podría estar ocurriendo ahora mismo?
La aguja entre millones de agujas
Los infostealers como RedLine, Lumma, Vidar y otras familias de malware están diseñados para recolectar información almacenada en sistemas infectados. Dependiendo del malware y su configuración, esto puede incluir contraseñas guardadas en el navegador, cookies, información de autocompletado, billeteras de criptomonedas, información del sistema, configuraciones de VPN y otros elementos de autenticación. Estos se empaquetan y venden como un registro de infostealer, cuando una sola infección puede producir cientos o miles de registros individuales. Multiplica eso en un ecosistema global de malware y los defensores rápidamente se enfrentan a un problema de escala.
Mientras que los defensores necesitan procesar y validar todo, los atacantes solo necesitan un conjunto válido y valioso de credenciales. Como describe Flare el problema, esto no es encontrar una aguja en un pajar. Es encontrar una aguja específica entre millones de agujas en millones de pajares. Aunque los registros de stealers históricamente circulaban a través de foros y mercados underground, la investigación de Flare estima que aproximadamente el 90% de los registros ahora aparecen en Telegram, donde los canales públicos pueden anunciar muestras y los canales privados de suscripción pueden proporcionar acceso a conjuntos de datos más frescos.
¿Ya está una cookie de sesión robada eludiendo tu MFA?
Los registros de infostealer pueden dar a los atacantes una sesión autenticada en vivo que omite la contraseña y la solicitud de MFA por completo. Flare monitorea los registros de stealers en la dark web y Telegram en tiempo real, para que puedas marcar identidades y sesiones corporativas expuestas antes de que se conviertan en una toma de control de cuenta.
Una contraseña no siempre es lo más peligroso en el registro
Con la gran cantidad de datos en múltiples canales, es difícil priorizar el nivel de riesgo. Si trabajas en una gran corporación, tienes miles de empleados; si empiezas el día con dos alertas, ¿cómo estableces cuál es más riesgosa? La primera alerta puede involucrar una contraseña antigua de un empleado para un sitio web de consumo que aparece en un registro de infostealer de hace seis meses, mientras que la segunda alerta puede haberse recopilado ayer y contener las credenciales de identidad corporativa del empleado y una sesión de navegador autenticada para el proveedor de identidad de la organización.
Aunque ambas pueden etiquetarse como exposiciones de credenciales de empleados, son completamente diferentes. Es por esto que los profesionales deben priorizar el monitoreo en torno a activos que les digan algo sobre el impacto potencial, por ejemplo, dominios y subdominios corporativos, proveedores de identidad empresarial, cookies de sesión, endpoints VPN y RDP, y consolas en la nube. Los proveedores de identidad merecen atención particular, ya que una identidad SSO comprometida (Microsoft Entra ID, Okta, Google Cloud Identity, etc.) puede abrir un camino a múltiples aplicaciones conectadas. Donde sea posible, la verificación y mitigación automatizadas fortalecen aún más esta protección.
El peligro en las cookies de sesión
Cuando un usuario se autentica con éxito, una aplicación puede emitir una cookie de sesión, para que no tenga que autenticarse en cada solicitud. Si el malware roba esa sesión autenticada, un atacante podría potencialmente reproducirla. Entonces, si los atacantes obtienen una cookie de sesión, y los infostealers las recopilan, no necesariamente tienen que iniciar sesión. Las credenciales robadas por sí solas aún requieren autenticación, lo que crea una oportunidad para que los defensores detecten o bloqueen el inicio de sesión; sin embargo, una cookie de sesión válida puede eliminar ese paso por completo. Esto efectivamente elude la MFA.
Los primeros 60 segundos
Flare recomienda una evaluación inicial inmediatamente después de descubrir datos potencialmente relevantes de stealers, seguida de una puntuación de riesgo y validación. El objetivo no es llevar a cabo toda la investigación de incidentes en los primeros minutos. Es determinar con qué rapidez la organización necesita reaccionar. Una buena primera pregunta es: ¿qué exactamente fue robado? Un analista debe determinar cuándo ocurrió la infección, qué sistema produjo el registro, cuántas credenciales corporativas están presentes y si se capturaron sesiones autenticadas. Luego, agregar contexto empresarial. Una credencial para testserver.company.com no debería recibir necesariamente la misma prioridad que una para finance.company.com. De manera similar, una identidad expuesta que pertenece a un pasante de marketing no debería manejarse automáticamente igual que un administrador con acceso al proveedor de identidad, la consola en la nube y la infraestructura de producción. El marco ilustrativo en la guía de Flare, por lo tanto, coloca las credenciales de identidad empresarial combinadas con cookies de sesión en severidad crítica, con un objetivo de respuesta sugerido de menos de una hora. El acceso VPN/RDP combinado con múltiples credenciales corporativas se clasifica como de alta severidad debido a su potencial de movimiento lateral.
De la exposición a la investigación
Supongamos que el registro de nuestro empleado hipotético contiene una credencial de Entra ID, contraseñas SaaS corporativas y cookies de navegador; la siguiente pregunta es si alguien ya las ha utilizado. Los defensores pueden correlacionar la identidad expuesta con la telemetría de autenticación: inicios de sesión exitosos y fallidos, geografías inesperadas, dispositivos inusuales, direcciones IP desconocidas y acceso a recursos fuera del comportamiento normal del empleado. También deben determinar si la información robada sigue siendo utilizable. ¿Ha cambiado la contraseña desde la infección? ¿Ha expirado la sesión? ¿La cuenta sigue activa?
El flujo de trabajo de investigación recomendado por Flare expande el análisis para incluir información de huella del navegador, el inventario completo de credenciales guardadas, información sobre el sistema infectado y artefactos adicionales como configuraciones de VPN o claves SSH. ¿Quién es el empleado? ¿A qué puede acceder su identidad? ¿La máquina infectada era corporativa o personal? ¿Fue una infección o evidencia de una campaña más amplia? Los registros de autenticación deben examinarse entonces en los sistemas accesibles para esa identidad, priorizando primero los recursos más sensibles. Los defensores deben buscar específicamente comportamientos que indiquen que la exposición ha progresado a una toma de control de cuenta: autenticación desde ubicaciones inesperadas, acceso inconsistente con el rol del usuario, descargas inusuales, actividad de restablecimiento de contraseña e inscripción de nuevos dispositivos MFA. Así es como un registro de stealer se convierte en un sensor de alerta temprana para el compromiso de identidad.
Trata los registros de stealers como un problema de identidad
Una vez que se confirma una exposición de alto riesgo, la velocidad importa. Los defensores deben invalidar sesiones comprometidas, restablecer las credenciales afectadas y aumentar la monitorización en torno a la identidad. Más allá de incidentes individuales, las organizaciones deben rastrear exposiciones recurrentes, aplicaciones afectadas y si las credenciales robadas condujeron a intentos de acceso. En última instancia, la monitorización de infostealers se ha convertido en una capa esencial de la seguridad de identidad, permitiendo a las organizaciones identificar credenciales y sesiones expuestas, entender el acceso que proporcionan, determinar si siguen siendo explotables y disruptir la toma de control de cuentas potencial antes de que se convierta en un compromiso más amplio.
Aprende más registrándote en nuestra prueba gratuita. Patrocinado y escrito por Flare.
Deja una respuesta