Introducción

En julio, Google anunció un nuevo mecanismo de protección para las cookies almacenadas en Chrome en Windows, conocido como Cifrado vinculado a la aplicación. No hay duda de que esta implementación de seguridad elevó el nivel e impactó directamente en el ecosistema de malware. Luego de meses con esta nueva característica, muchos ladrones de información escribieron código nuevo para eludir esta protección (como predijo el equipo de seguridad de Chrome) con el fin de seguir siendo competitivos en el mercado y ofrecer capacidades que recuperen de forma confiable los datos de las cookies de los navegadores Chrome.

Elastic Security Labs estuvo rastreando un subconjunto de esta actividad, identificando múltiples técnicas empleadas por diferentes familias de malware para eludir el cifrado vinculado a la aplicación. Si bien el ecosistema aún está evolucionando a la luz de esta presión, nuestro objetivo es compartir detalles técnicos que ayuden a las organizaciones a comprender y defender de estas técnicas. En este artículo, cubriremos los diferentes métodos empleados por las siguientes familias de robadores de información:

• ROBAR/VIDAR
• METASTEALER
• FEMEDRONA
• XENOSTEALER
• LUMMA

Conclusiones clave

• Las últimas versiones de los robadores de información implementan elusiones en la reciente función de protección de cookies de Google mediante el cifrado vinculado a la aplicación.
• Las técnicas incluyen la integración de la herramienta de seguridad ofensiva ChromeKatz, el aprovechamiento de COM para interactuar con los servicios de Chrome y descifrar la clave de cifrado vinculada a la aplicación, y el uso de la función de depuración remota dentro de Chrome.
• Los defensores deben monitorear activamente las diferentes técnicas de elusión de cookies contra Chrome en Windows en previsión de futuras mitigaciones y elusiones que probablemente surjan en el corto o mediano plazo.
• Elastic Security proporciona mitigaciones a través de firmas de memoria, reglas de comportamiento y oportunidades de búsqueda para permitir una identificación y respuesta más rápidas a la actividad de robo de información.

Fondo

En términos generales, las cookies son empleadas por las aplicaciones sitio web para almacenar información del visitante en el navegador que éste emplea para acceder a esa aplicación sitio web. Esta información ayuda a la aplicación sitio web a rastrear a ese usuario, sus preferencias y otra información de una ubicación a otra, incluso en diferentes dispositivos.

El token de autenticación es un uso de las estructuras de almacenamiento de datos del lado del cliente que posibilita gran parte del funcionamiento de la interactividad sitio web moderno. El navegador almacena estos tokens después de que el usuario se autenticó exitosamente con una aplicación sitio web. Luego del nombre de usuario y la contraseña, luego de la autenticación multifactor (MFA) mediante códigos de acceso de un solo uso o datos biométricos, la aplicación sitio web “recuerda” su navegador y usted a través del intercambio de este token con cada solicitud sitio web posterior.

Un actor malicioso que obtiene acceso a un token de autenticación válido puede reutilizarlo para hacer pasar por el usuario de ese servicio sitio web con la capacidad de apoderar de cuentas, robar información personal o financiera o realizar otras acciones como ese usuario, como transferir activos financieros.

Los ciberdelincuentes emplean ladrones de información para robar y comercializar este tipo de información para obtener beneficios económicos.

Seguridad de las cookies de Google Chrome

Las versiones anteriores de Google Chrome en Windows usaban la API de protección de datos nativa de Windows (DPAPI) para cifrar las cookies y protegerlas de otros contextos de usuario. Esto proporcionó protección adecuada contra varios escenarios de ataque, pero cualquier software malicioso que se ejecutara en el contexto del usuario objetivo podría descifrar estas cookies empleando directamente los métodos DPAPI. Lamentablemente, este contexto es exactamente el nicho en el que a menudo se encuentran los ladrones de información luego de emplear la ingeniería social para obtener acceso inicial. El esquema DPAPI ahora es bien conocido por los atacantes con varios vectores de ataque: desde el descifrado local mediante la API, hasta el robo de la clave maestra y el descifrado remoto, hasta el abuso de la clave DPAPI de respaldo de todo el dominio en un entorno empresarial.

Con el lanzamiento de Chrome 127 en julio de 2024, Google implementó el cifrado de datos del navegador vinculado a la aplicación. Este mecanismo abordó directamente muchos ataques DPAPI comunes contra los datos del navegador Windows Chrome, incluidas las cookies. Para ello, almacena los datos en archivos de datos cifrados y emplea un servicio que se ejecuta como SISTEMA para verificar que cualquier intento de descifrado provenga del proceso Chrome antes de devolver la clave a ese proceso para descifrar los datos almacenados.

Si bien consideramos que este esquema de cifrado no es una panacea para proteger todos los datos del navegador (como reconoce el Equipo de Seguridad de Chrome en su comunicado), creemos que logró llevar a los autores de malware a TTP que son más abiertamente maliciosas y más fáciles de identificar y responder para los defensores.

Técnicas de evasión de ladrones, resumidas

Las siguientes secciones describirán técnicas específicas de robo de información empleadas para eludir la función de cifrado vinculado a la aplicación de Google, según lo observado por Elastic. Si bien esta no es una recopilación exhaustiva de bypasses y el desarrollo de estas familias está en curso, representan una dinámica interesante dentro del espacio de los ladrones de información que muestra cómo los desarrolladores de malware respondieron al control de seguridad recientemente actualizado de Google. Las técnicas observadas por nuestro equipo incluyen:

• Depuración remota a través del protocolo DevTools de Chrome
• Memoria del proceso de lectura del proceso de servicio de red de Chrome (ChromeKatz y ReadProcessMemory (RPM))
• Elevar a SYSTEM y luego descifrar app_bound_encryption_key con el método DecryptData de GoogleChromeElevationService a través de COM

ROBAR/VIDAR

Nuestro equipo observó un nuevo código introducido en STEALC/VIDAR relacionado con la técnica de omisión de cookies alrededor del 20 de septiembre. Se trataba de muestras atípicas que se distinguían de las versiones anteriores y se implementaron como archivos PE de 64 bits integrados junto con comprobaciones condicionales. Los valores cifrados en las bases de datos SQLite donde Chrome almacena sus datos ahora tienen el prefijo v20, lo que indica que los valores ahora están cifrados mediante cifrado vinculado a la aplicación.

STEALC se introdujo en 2023 y se desarrolló con una “fuerte inspiración” de otros ladrones más establecido como RACOON y VIDAR. STEALC y VIDAR continuaron con el desarrollo simultáneo y en el caso de las omisiones de cifrado vinculado a aplicaciones se optó por la misma implementación.

Durante la extracción de datos cifrados de las bases de datos, el malware busca este prefijo. Si comienza con v20, se genera un proceso secundario empleando el archivo PE incorporado en la sección .data del binario. Este programa es responsable de extraer los valores de cookies no cifrados que residen en uno de los procesos secundarios de Chrome.

Este binario incrustado crea un escritorio oculto a través de OpenDesktopA / CreateDesktopA y luego emplea CreateToolhelp32Snapshot para escanear y finalizar todos los chrome.exe procesos. Luego se inicia un nuevo proceso chrome.exe con el nuevo objeto de escritorio. Según la versión instalada de Chrome, el malware selecciona un patrón de firma para la función CookieMonster de Chromium, un componente interno empleado para gestionar las cookies.

Empleamos los patrones de firma para pivotar hacia el código existente desarrollado para una herramienta de seguridad ofensiva llamada ChromeKatz. En este momento, los patrones se eliminaron del repositorio de ChromeKatz y se reemplazaron con una nueva técnica. Según nuestro análisis, el autor del malware parece haber reimplementado ChromeKatz dentro de STEALC para eludir la función de protección de cifrado vinculada a la aplicación.

Una vez que el malware identifica una firma coincidente, enumera los procesos secundarios de Chrome para verificar la presencia del indicador de línea de comandos --utility-sub-type=network.mojom.NetworkService . Esta bandera indica que el proceso es el servicio de red responsable de manejar toda la comunicación de Internet. Se convierte en un objetivo principal ya que contiene los datos confidenciales que busca el atacante, como se describe en la publicación de MDSec. Luego devuelve un identificador para ese proceso secundario específico.

A continuación, enumera cada módulo en el proceso secundario del servicio de red para encontrar y recuperar la dirección base y el tamaño de chrome.dll cargado en la memoria. STEALC emplea CredentialKatz::FindDllPattern y CookieKatz::FindPattern para localizar las instancias de CookieMonster. Hay 2 llamadas a CredentialKatz::FindDllPattern.

En la primera llamada a CredentialKatz::FindDllPattern, intenta localizar uno de los patrones de firma (dependiendo de la versión de Chrome de la víctima) en chrome.dll. Una vez encontrado, STEALC ahora tiene un puntero de referencia a esa ubicación de memoria donde comienza la secuencia de bytes, que es la función net::CookieMonster::~CookieMonster, destructor de la clase CookieMonster .

La segunda llamada a CredentialKatz::FindDllPattern pasa la dirección de función para net::CookieMonster::~CookieMonster(void) como argumento para la búsqueda de secuencia de bytes, lo que da como resultado que STEALC tenga un puntero a la estructura de puntero de función virtual de CookieMonster .

El siguiente método empleado por STEALC es nuevamente idéntico a ChromeKatz, donde ubica instancias CookieMonster escaneando fragmentos de memoria en el módulo chrome.dll en busca de punteros que hagan referencia a la tabla virtual CookieMonster . Dado que vtable es una constante en todos los objetos de una clase determinada, cualquier objeto CookieMonster tendrá el mismo puntero vtable. Cuando se identifica una coincidencia, STEALC trata la ubicación de la memoria como una instancia CookieMonster y almacena su dirección en una matriz.

Para cada instancia CookieMonster identificada, STEALC accede a la estructura interna CookieMap ubicada en un desplazamiento de +0x30, y que es un árbol binario. Cada nodo dentro de este árbol contiene punteros a CanonicalCookieChrome estructuras. CanonicalCookieChrome Las estructuras contienen datos de cookies sin cifrar, lo que los hace accesibles para su extracción. Luego, STEALC inicia un recorrido de árbol pasando el primer nodo a una función de recorrido dedicada.

Para cada nodo, llama ReadProcessMemory para acceder a la estructura CanonicalCookieChrome desde la memoria del proceso de destino y luego lo procesa en jy::GenerateExfilString.

STEALC formatea los datos de cookies extraídos convirtiendo la fecha de vencimiento al formato UNIX y verificando la presencia de los indicadores HttpOnly y Secure . Luego, agrega detalles como el nombre de la cookie, el valor, el dominio, la ruta y HttpOnly y Secure en una cadena final para la exfiltración. Las estructuras OptimizedString se emplean en lugar de cadenas, por lo que los valores de la cadena pueden ser la cadena misma o, si la longitud de la cadena es mayor que 23, apuntarán a la dirección que almacena la cadena.

METASTEALER

METASTEALER, observado por primera vez en 2022, mejoró recientemente su capacidad para robar datos de Chrome, eludiendo los últimos esfuerzos de mitigación de Google. El 30 de septiembre, los autores del malware anunciaron esta actualización a través de su canal de Telegram, destacando su capacidad mejorada para extraer información confidencial, incluidas las cookies, a pesar de los cambios de seguridad en la versión 129+ de Chrome.

La primera muestra observada en la naturaleza por nuestro equipo fue descubierta el 30 de septiembre, el mismo día en que los autores promocionaron la actualización. A pesar de las afirmaciones de que el malware funciona sin necesidad de privilegios Administrator , nuestras pruebas revelaron que sí requiere acceso elevado, ya que intenta suplantar el token SYSTEM durante la ejecución.

Como se muestra en las capturas de pantalla anteriores, el método get_decryption ahora incluye un nuevo parámetro booleano. Este valor se establece en TRUE si los datos cifrados (cookie) comienzan con el prefijo v20 , lo que indica que la cookie está cifrada empleando el método de cifrado más reciente de Chrome. La función actualizada conserva la compatibilidad con versiones anteriores y aún admite el descifrado de cookies de versiones anteriores de Chrome si están presentes en la máquina infectada.

Luego, el malware intenta acceder a los archivos Local State o LocalPrefs.json ubicados en el directorio del perfil de Chrome. Ambos archivos tienen formato JSON y almacenan claves de cifrado (encrypted_key) para versiones anteriores de Chrome y app_bound_encrypted_key para las más nuevas. Si la bandera está establecida en TRUE, el malware emplea específicamente app_bound_encrypted_key para descifrar las cookies de acuerdo con el método de cifrado actualizado de Chrome.

En este caso, el malware primero suplanta el token SYSTEM empleando una clase recién introducida llamada ContextSwitcher.

Luego descifra la clave creando una instancia a través del COM del servicio Chrome responsable del descifrado, llamado GoogleChromeElevationService, empleando el CLSID 708860E0-F641-4611-8895-7D867DD3675B. Una vez inicializado, invoca el método DecryptData para descifrar la clave app_bound_encrypted_key que se empleará para descifrar las cookies cifradas.

METASTEALER emplea una técnica similar a la demostrada en un gist compartido en X el 27 de septiembre, que puede servir de inspiración para los autores del malware. Ambos enfoques aprovechan métodos similares para eludir los mecanismos de cifrado de Chrome y extraer datos confidenciales.

FEMEDRONA

Este ladrón de código abierto llamó la atención mundial a principios de año mediante el uso de una vulnerabilidad de Windows SmartScreen (CVE-2023-36025). Si bien su desarrollo aún está en curso en Telegram, nuestro equipo encontró una versión reciente (2.3.2) enviada a fines de septiembre que incluye una nueva funcionalidad de captura de cookies para Chrome.

El malware primero enumera los diferentes perfiles dentro de Chrome, luego realiza una verificación del navegador usando la función (BrowserHelpers.NewEncryption) buscando el navegador Chrome con una versión mayor o igual a 127.

Si la condición coincide, PHEMEDRONE emplea una combinación de funciones auxiliares para extraer las cookies.

Al observar la clase ChromeDevToolsWrapper y sus diferentes funciones, podemos ver que PHEMEDRONE configura una sesión de depuración remota dentro de Chrome para acceder a las cookies. Se emplea el puerto predeterminado (9222) junto con la posición de ventana establecido en -2400,-2400 que se establece fuera de la pantalla para evitar que cualquier ventana visible alerte a la víctima.

A continuación, el malware establece una conexión WebSocket con la interfaz de depuración de Chrome y realiza una solicitud empleando el método obsoleto del protocolo Chrome DevTools (Network.getAllCookies).

Luego, las cookies se devuelven de la solicitud anterior en texto sin formato; a continuación se muestra una captura de red que muestra este comportamiento:

XENOSTEALER

XENOSTEALER es un ladrón de información de código abierto alojado en GitHub. Apareció en julio 2024 y se encuentra en desarrollo activo en el momento de esta publicación. En individuo, la función de omisión de Chrome se implementó el 26 de septiembre 2024.

El enfoque adoptado por XENOSTEALER es similar al de METASTEALER. Primero analiza el archivo JSON bajo un perfil de Chrome determinado para extraer app_bound_encrypted_key. Sin embargo, el proceso de descifrado se produce dentro de un proceso de Chrome. Para lograr esto, XENOSTEALER lanza una instancia de Chrome.exe y luego inyecta código usando una clase auxiliar llamada SharpInjector, pasando la clave cifrada como parámetro.

Posteriormente, el código inyectado llama al método DecryptData desde GoogleChromeElevationService para obtener la clave descifrada.

LUMMA

A mediados de octubre, la última versión de LUMMA implementó un nuevo método para eludir la protección de cookies de Chrome, según informó @g0njxa.

Analizamos una versión reciente de LUMMA, confirmando que logró recuperar exitosamente los datos de cookies de la última versión de Google Chrome (130.0.6723.70). LUMMA primero crea un proceso Chrome visible a través de Kernel32!CreateProcessW.

Esta actividad fue seguida en el depurador con múltiples llamadas a NtReadVirtualMemory donde identificamos a LUMMA buscando dentro del proceso de Chrome chrome.dll.

Una vez encontrado, el malware copia la imagen chrome.dll a su propia memoria de proceso empleando NtReadVirtualMemory. De manera similar a la técnica ChromeKatz, Lumma aprovecha el escaneo de patrones para apuntar al componente CookieMonster de Chrome.

Lumma emplea un patrón de firma ofuscado para identificar la funcionalidad CookieMonster :

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

A continuación se muestra la regla YARA luego de la desofuscación:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

Luego de decodificar y buscar el patrón en chrome.dll, esto maneja al destructor CookieMonster (net::CookieMonster::~CookieMonster).

Luego, las cookies se identifican en la memoria y se eliminan como texto sin cifrar desde el proceso de Chrome.

Una vez completado, LUMMA envía las cookies junto con los demás datos aplicar como múltiples archivos zip (encriptados con xor y codificados en base64) al servidor C2.

Detección

A continuación se presentan las siguientes detecciones de comportamiento que se pueden emplear para identificar técnicas empleadas por los ladrones de información:

• Acceso a las credenciales del navegador sitio web mediante un proceso inusual
• Acceso a credenciales del navegador sitio web mediante un proceso no firmado
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Depuración del navegador desde un padre inusual
• Descubrimiento potencial de información del navegador

Además, se pueden emplear las siguientes consultas para buscar diversos comportamientos anormales relacionados:

Acceso a las cookies mediante un proceso inusual

Esta consulta emplea eventos de apertura de archivos y accesos agregados por proceso, luego busca aquellos que se observan en hosts únicos y con un recuento de acceso total bajo:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

A continuación se muestra un ejemplo de coincidencias de diversos ladrones de información, incluidos los actualizados con nuevas capacidades para robar cookies de Chrome:

El comportamiento de METASTEALER tiende a finalizar primero todas las instancias de Chrome en ejecución y luego llama a CoCreateInstance para crear una instancia del servicio de elevación de Google Chrome; este serial de eventos se puede expresar con la siguiente consulta EQL:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

La búsqueda anterior indica agentes sospechosos pero no identifica el proceso fuente. Al habilitar la auditoría de acceso a objetos de registro a través del evento 4663 en la clave de registro CLSID del servicio Chrome Elevation {708860E0-F641-4611-8895-7D867DD3675B}, podemos detectar procesos inusuales que intentan acceder a esa clave:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

A continuación se muestra un ejemplo de coincidencias en el malware METASTEALER al llamar a CoCreateInstance (CLSID_Elevator):

El ladrón PHEMEDRONE emplea el método de depuración del navegador conocido para recopilar cookies a través de la API de Chromium, esto se puede observar en la siguiente captura de pantalla donde podemos ver una instancia de NodeJs comunicar con una instancia del navegador con la depuración habilitada a través del puerto 9222:

La siguiente consulta EQL se puede emplear para buscar procesos inusuales que realicen un comportamiento similar:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

El navegador Chrome surgió de un padre inusual

La muestra STEALC que emplea la implementación de ChromeKatz genera una instancia de Google Chrome para cargar el perfil predeterminado del usuario y, mientras busca archivos ejecutables principales normales, resulta que está limitado a los archivos principales firmados de Chrome y Explorer.exe. La siguiente consulta ES|QL se puede emplear para encontrar padres inusuales:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Archivos binarios no confiables de la carpeta de la aplicación Chrome

Dado que el servicio de elevación de Chrome confía en los binarios que se ejecutan desde la carpeta program files de Chrome, se pueden emplear las siguientes consultas para buscar binarios no firmados o no confiables ejecutados o cargados desde allí:

Archivos DLL sin firmar cargados desde la carpeta de la aplicación Google Chrome

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Ejecutable sin firmar lanzado desde la carpeta de la aplicación Google Chrome

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

Conclusión

Google elevó el listón al implementar nuevos controles de seguridad para proteger los datos de las cookies en Chrome. Como era de esperar, esto provocó que los desarrolladores de malware desarrollen o integren sus propios métodos de evasión. Esperamos que Google continúe innovando para brindar una mayor protección a los datos de los usuarios.

Las organizaciones y los defensores deben monitorear constantemente la actividad inusual en los puntos finales. Si bien estas nuevas técnicas pueden ser exitosas, también son ruidosas y detectables con la instrumentación, los procesos y el personal de seguridad adecuados.

Bypasses de ladrones y MITRE ATT&CK

Elastic usa el marco MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Acceso a credenciales
• Evasión de defensa
• Descubrimiento
• Ejecución

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Robo de cookies de sesión web
• Inyección de proceso
• Credenciales de almacenes de contraseñas
• Detección de información del sistema
• Descubrimiento de procesos
• Comunicación entre procesos: Modelo de objetos de componentes

YARA

Elastic Security creó reglas YARA para identificar esta actividad.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

Observaciones

Todos los observables también están disponibles para su descarga tanto en formato ECS como en STIX.

En esta investigación se discutieron los siguientes observables.

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html