www.elastic.co Open in urlscan Pro
2a04:4e42:600::729  Public Scan

Form analysis
0 forms found in the DOM

Text Content

About
Topics
Vulnerability updatesReportsTools

SubscribeStart free trialContact sales

Open navigation menu
28 October 2024•Jia Yu Chan•Salim Bitam•Daniel Stepanic•Samir Bousseaden•Cyril
François•Seth Goodwin


KATZ AND MOUSE GAME: MAAS INFOSTEALERS ADAPT TO PATCHED CHROME DEFENSES

Elastic Security Labs breaks down bypass implementations from the infostealer
ecosystem’s reaction to Chrome 127's Application-Bound Encryption scheme.

20 min readMalware analysis



INTRODUCTION

In July, Google announced a new protection mechanism for cookies stored within
Chrome on Windows, known as Application-Bound Encryption. There is no doubt this
security implementation has raised the bar and directly impacted the malware
ecosystem. After months with this new feature, many infostealers have written
new code to bypass this protection (as the Chrome Security Team predicted) in
order to stay competitive in the market and deliver capabilities that reliably
retrieve cookie data from Chrome browsers.

Elastic Security Labs has been tracking a subset of this activity, identifying
multiple techniques used by different malware families to circumvent App-Bound
Encryption. While the ecosystem is still evolving in light of this pressure, our
goal is to share technical details that help organizations understand and defend
against these techniques. In this article, we will cover the different methods
used by the following infostealer families:

 * STEALC/VIDAR
 * METASTEALER
 * PHEMEDRONE
 * XENOSTEALER
 * LUMMA


KEY TAKEAWAYS

 * Latest versions of infostealers implement bypasses around Google’s recent
   cookie protection feature using Application-Bound Encryption
 * Techniques include integrating offensive security tool ChromeKatz, leveraging
   COM to interact with Chrome services and decrypt the app-bound encryption
   key, and using the remote debugging feature within Chrome
 * Defenders should actively monitor for different cookie bypass techniques
   against Chrome on Windows in anticipation of future mitigations and bypasses
   likely to emerge in the near- to mid-term
 * Elastic Security provides mitigations through memory signatures, behavioral
   rules, and hunting opportunities to enable faster identification and response
   to infostealer activity


BACKGROUND

Generically speaking, cookies are used by web applications to store visitor
information in the browser the visitor uses to access that web app. This
information helps the web app track that user, their preferences, and other
information from location to location– even across devices.

The authentication token is one use of the client-side data storage structures
that enables much of how modern web interactivity works. These tokens are stored
by the browser after the user has successfully authenticated with a web
application. After username and password, after multifactor authentication (MFA)
via one-time passcodes or biometrics, the web application “remembers” your
browser is you via the exchange of this token with each subsequent web request.

A malicious actor who gets access to a valid authentication token can reuse it
to impersonate the user to that web service with the ability to take over
accounts, steal personal or financial information, or perform other actions as
that user such as transfer financial assets.

Cybercriminals use infostealers to steal and commoditize this type of
information for their financial gain.


GOOGLE CHROME COOKIE SECURITY

Legacy versions of Google Chrome on Windows used the Windows native Data
Protection API (DPAPI) to encrypt cookies and protect them from other user
contexts. This provided adequate protection against several attack scenarios,
but any malicious software running in the targeted user’s context could decrypt
these cookies using the DPAPI methods directly. Unfortunately, this context is
exactly the niche that infostealers often find themselves in after social
engineering for initial access. The DPAPI scheme is now well known to attackers
with several attack vectors; from local decryption using the API, to stealing
the masterkey and decrypting remotely, to abusing the domain-wide backup DPAPI
key in an enterprise environment.

With the release of Chrome 127 in July 2024, Google implemented
Application-Bound Encryption of browser data. This mechanism directly addressed
many common DPAPI attacks against Windows Chrome browser data–including cookies.
It does this by storing the data in encrypted datafiles, and using a service
running as SYSTEM to verify any decryption attempts are coming from the Chrome
process before returning the key to that process for decryption of the stored
data.



Chrome 127 Application-Bound Encryption Scheme. Source:
https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html



While it is our view that this encryption scheme is not a panacea to protect all
browser data (as the Chrome Security Team acknowledges in their release) we do
feel it has been successful in driving malware authors to TTPs that are more
overtly malicious, and easier for defenders to identify and respond to.


STEALER BYPASS TECHNIQUES, SUMMARIZED

The following sections will describe specific infostealer techniques used to
bypass Google’s App-Bound Encryption feature as observed by Elastic. Although
this isn’t an exhaustive compilation of bypasses, and development of these
families is ongoing, they represent an interesting dynamic within the
infostealer space showing how malware developers responded to Google’s recently
updated security control. The techniques observed by our team include:

 * Remote debugging via Chrome’s DevTools Protocol
 * Reading process memory of Chrome network service process (ChromeKatz and
   ReadProcessMemory (RPM))
 * Elevating to SYSTEM then decrypting app_bound_encryption_key with the
   DecryptData method of GoogleChromeElevationService through COM



Timeline of events




STEALC/VIDAR

Our team observed new code introduced to STEALC/VIDAR related to the cookie
bypass technique around September 20th. These were atypical samples that stood
out from previous versions and were implemented as embedded 64-bit PE files
along with conditional checks. Encrypted values in the SQLite databases where
Chrome stores its data are now prefixed with v20, indicating that the values are
now encrypted using application-bound encryption.

> STEALC was introduced in 2023 and was developed with “heavy inspiration” from
> other more established stealers such as RACOON and VIDAR. STEALC and VIDAR
> have continued concurrent development, and in the case of App-Bound Encryption
> bypasses have settled on the same implementation.

During the extraction of encrypted data from the databases the malware checks
for this prefix. If it begins with v20, a child process is spawned using the
embedded PE file in the .data section of the binary. This program is responsible
for extracting unencrypted cookie values residing in one of Chrome's child
processes.



Embedded PE file



This embedded binary creates a hidden desktop via OpenDesktopA / CreateDesktopA
then uses CreateToolhelp32Snapshot to scan and terminate all chrome.exe
processes. A new chrome.exe process is then started with the new desktop object.
Based on the installed version of Chrome, the malware selects a signature
pattern for the Chromium feature CookieMonster, an internal component used to
manage cookies.



Signature pattern for CookieMonster



We used the signature patterns to pivot to existing code developed for an
offensive security tool called ChromeKatz. At this time, the patterns have been
removed from the ChromeKatz repository and replaced with a new technique. Based
on our analysis, the malware author appears to have reimplemented ChromeKatz
within STEALC in order to bypass the app-bound encryption protection feature.

Once the malware identifies a matching signature, it enumerates Chrome’s child
processes to check for the presence of the
--utility-sub-type=network.mojom.NetworkService command-line flag. This flag
indicates that the process is the network service responsible for handling all
internet communication. It becomes a prime target as it holds the sensitive data
the attacker seeks, as described in MDSec’s post. It then returns a handle for
that specific child process.



Enumerating for Chrome’s network service



Next, it enumerates each module in the network service child process to find and
retrieve the base address and size of chrome.dll loaded into memory. STEALC uses
CredentialKatz::FindDllPattern and CookieKatz::FindPattern to locate the
CookieMonster instances. There are 2 calls to CredentialKatz::FindDllPattern.



Calls to CredentialKatz::FindDllPattern



In the first call to CredentialKatz::FindDllPattern, it tries to locate one of
the signature patterns (depending on the victim’s Chrome version) in chrome.dll.
Once found, STEALC now has a reference pointer to that memory location where the
byte sequence begins which is the function net::CookieMonster::~CookieMonster,
destructor of the CookieMonster class.



Byte sequence for net::CookieMonster::~CookieMonster found in chrome.dll



The second call to CredentialKatz::FindDllPattern passes in the function address
for net::CookieMonster::~CookieMonster(void) as an argument for the byte
sequence search, resulting in STEALC having a pointer to CookieMonster’s Virtual
Function Pointer struct.



CookieMonster’s vtable in chrome.dll



The following method used by STEALC is again, identical to ChromeKatz, where it
locates CookieMonster instances by scanning memory chunks in the chrome.dll
module for pointers referencing the CookieMonster vtable. Since the vtable is a
constant across all objects of a given class, any CookieMonster object will have
the same vtable pointer. When a match is identified, STEALC treats the memory
location as a CookieMonster instance and stores its address in an array.



Using CookieKatz::FindPattern to locate CookieMonster instances



For each identified CookieMonster instance, STEALC accesses the internal
CookieMap structure located at an offset of +0x30, and which is a binary tree.
Each node within this tree contains pointers to CanonicalCookieChrome
structures. CanonicalCookieChrome structures hold unencrypted cookie data,
making it accessible for extraction. STEALC then initiates a tree traversal by
passing the first node into a dedicated traversal function.



Initiating CookieMap tree traversal for each CookieMonster instance found



For each node, it calls ReadProcessMemory to access the CanonicalCookieChrome
structure from the target process’s memory, then further processing it in
jy::GenerateExfilString.



CookieMap traversal subroutine



STEALC formats the extracted cookie data by converting the expiration date to
UNIX format and verifying the presence of the HttpOnly and Secure flags. It then
appends details such as the cookie's name, value, domain, path, and the HttpOnly
and Secure into a final string for exfiltration. OptimizedString structs are
used in place of strings, so string values can either be the string itself, or
if the string length is greater than 23, it will point to the address storing
the string.



Constructing string for data exfiltration




METASTEALER

METASTEALER, first observed in 2022, recently upgraded its ability to steal
Chrome data, bypassing Google’s latest mitigation efforts. On September 30th,
the malware authors announced this update via their Telegram channel,
highlighting its enhanced capability to extract sensitive information, including
cookies, despite the security changes in Chrome's version 129+.



METASTEALER announcement and translation





source: https://x.com/g0njxa/status/1840761619686568319/



The first sample observed in the wild by our team was discovered on September
30th, the same day the authors promoted the update. Despite claims that the
malware operates without needing Administrator privileges, our testing revealed
it does require elevated access, as it attempts to impersonate the SYSTEM token
during execution.



Code comparison between an old and a new version of the family



As shown in the screenshots above, the get_decryption method now includes a new
Boolean parameter. This value is set to TRUE if the encrypted data (cookie)
begins with the v20 prefix, indicating that the cookie is encrypted using
Chrome's latest encryption method. The updated function retains backward
compatibility, still supporting the decryption of cookies from older Chrome
versions if present on the infected machine.

The malware then attempts to access the Local State or LocalPrefs.json files
located in the Chrome profile directory. Both files are JSON formatted and store
encryption keys (encrypted_key) for older Chrome versions and
app_bound_encrypted_key for newer ones. If the flag is set to TRUE, the malware
specifically uses the app_bound_encrypted_key to decrypt cookies in line with
the updated Chrome encryption method.



app_bound_encrypted_key extracted from Chrome json file



In this case, the malware first impersonates the SYSTEM token using a newly
introduced class called ContextSwitcher.



New class for TOKEN impersonation



It then decrypts the key by creating an instance via the COM of the Chrome
service responsible for decryption, named GoogleChromeElevationService, using
the CLSID 708860E0-F641-4611-8895-7D867DD3675B. Once initialized, it invokes the
DecryptData method to decrypt the app_bound_encrypted_key key which will be used
to decrypt the encrypted cookies.



New class ComInvoker to invoke methods from GoogleChromeElevationService service



METASTEALER employs a technique similar to the one demonstrated in a gist shared
on X on September 27th, which may have served as inspiration for the malware
authors. Both approaches leverage similar methods to bypass Chrome's encryption
mechanisms and extract sensitive data.


PHEMEDRONE

This open-source stealer caught the world’s attention earlier in the year
through its usage of a Windows SmartScreen vulnerability (CVE-2023-36025). While
its development is still occurring on Telegram, our team found a recent release
(2.3.2) submitted at the end of September including new cookie grabber
functionality for Chrome.



README.txt within PHEMEDRONE project



The malware first enumerates the different profiles within Chrome, then performs
a browser check using function (BrowserHelpers.NewEncryption) checking for the
Chrome browser with a version greater than or equal to 127.



Chrome version verification in PHEMEDRONE



If the condition matches, PHEMEDRONE uses a combination of helper functions to
extract the cookies.



High-level functions used cookie extraction in PHEMEDRONE



By viewing the ChromeDevToolsWrapper class and its different functions, we can
see that PHEMEDRONE sets up a remote debugging session within Chrome to access
the cookies. The default port (9222) is used along with window-position set to
-2400,-2400 which is set off-screen preventing any visible window from alerting
the victim.



New Chrome process in remote debug mode



Next, the malware establishes a WebSocket connection to Chrome’s debugging
interface making a request using deprecated Chrome DevTools Protocol method
(Network.getAllCookies).



Chrome DevTools Protocol used to retrieve cookies



The cookies are then returned from the previous request in plaintext, below is a
network capture showing this behavior:



Cookie data within network capture




XENOSTEALER

XENOSTEALER is an open-source infostealer hosted on GitHub. It appeared in July
2024 and is under active development at the time of this publication. Notably,
the Chrome bypass feature was committed on September 26, 2024.

The approach taken by XENOSTEALER is similar to that of METASTEALER. It first
parses the JSON file under a given Chrome profile to extract the
app_bound_encrypted_key. However, the decryption process occurs within a Chrome
process. To achieve this, XENOSTEALER launches an instance of Chrome.exe, then
injects code using a helper class called SharpInjector, passing the encrypted
key as a parameter.

The injected code subsequently calls the DecryptData method from the
GoogleChromeElevationService to obtain the decrypted key.



Source code of the injected code




LUMMA

In mid-October, the latest version of LUMMA implemented a new method to bypass
Chrome cookie protection, as reported by @g0njxa.





We analyzed a recent version of LUMMA, confirming that it managed to
successfully recover the cookie data from the latest version of Google Chrome
(130.0.6723.70). LUMMA first creates a visible Chrome process via
Kernel32!CreateProcessW.



Dump of CreateProcessW lpApplicationName parameter



This activity was followed up in the debugger with multiple calls to
NtReadVirtualMemory where we identified LUMMA searching within the Chrome
process for chrome.dll.



LUMMA seeks chrome.dll in Chrome



Once found, the malware copies the chrome.dll image to its own process memory
using NtReadVirtualMemory. In a similar fashion to the ChromeKatz technique,
Lumma leverages pattern scanning to target Chrome’s CookieMonster component.



Lumma’s pattern scanning



Lumma uses an obfuscated signature pattern to pinpoint the CookieMonster
functionality:

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

Below is the YARA rule after de-obfuscation:

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
}

After decoding and searching for the pattern in chrome.dll, this leads to the
CookieMonster destructor (net::CookieMonster::~CookieMonster).



Lumma pattern match on CookieMonster



The cookies are then identified in memory and dumped out in clear text from the
Chrome process.



LUMMA dumping the cookie in clear text from Chrome



Once completed, LUMMA sends out the cookies along with the other requested data
as multiple zip files (xor encrypted and base64 encoded) to the C2 server.



Received stolen cookies on the C2 side




DETECTION

Below are the following behavioral detections that can be used to identify
techniques used by information stealers:

 * Web Browser Credential Access via Unusual Process
 * Web Browser Credential Access via Unsigned Process
 * Access to Browser Credentials from Suspicious Memory
 * Failed Access Attempt to Web Browser Files
 * Browser Debugging from Unusual Parent
 * Potential Browser Information Discovery

Additionally, the following queries can be used for hunting diverse related
abnormal behaviors:


COOKIES ACCESS BY AN UNUSUAL PROCESS

This query uses file open events and aggregate accesses by process, then looks
for ones that are observed in unique hosts and with a low total access count:

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

Below example of matches from diverse information stealers including the updated
ones with new Chrome cookies stealing capabilities:



ES|QL query results for suspicious browser cookies file access



METASTEALER behavior tends to first terminate all running chrome instances then
calls CoCreateInstance to instantiate the Google Chrome elevation service, this
series of events can be expressed with the following EQL query:

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"]



EQL query results for suspicious browser termination



The previous hunt indicates suspicious agents but doesn't identify the source
process. By enabling registry object access auditing through event 4663 on the
Chrome Elevation service CLSID registry key
{708860E0-F641-4611-8895-7D867DD3675B}, we can detect unusual processes
attempting to access that key:



Google Chrome Elevation COM registry access



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

Below is an example of matches on the METASTEALER malware while calling
CoCreateInstance (CLSID_Elevator):



ES|QL query results for suspicious access to chrome elevation service registry



The PHEMEDRONE stealer uses the known browser debugging method to collect
cookies via Chromium API, this can be observed in the following screenshot where
we can see an instance of NodeJs communicating with a browser instance with
debugging enabled over port 9222:



PHEMEDRONE - network connection to chrome over port 9222



The following EQL query can be used to look for unusual processes performing
similar behavior:

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.*"]



EQL query results for browser debugging activity




CHROME BROWSER SPAWNED FROM AN UNUSUAL PARENT

The STEALC sample that uses ChromeKatz implementation spawns an instance of
Google Chrome to load the user default profile, while looking for normal parent
executables, it turns out it’s limited to Chrome signed parents and
Explorer.exe, the following ES|QL query can be used to find unusual parents:

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



ES|QL query results for chrome browser spawned from an unusual parent




UNTRUSTED BINARIES FROM CHROME APPLICATION FOLDER

Since the Chrome elevation service trusts binaries running from the Chrome
program files folder, the following queries can be used to hunt for unsigned or
untrusted binaries executed or loaded from there:


UNSIGNED DLLS LOADED FROM GOOGLE CHROME APPLICATION FOLDER

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


UNSIGNED EXECUTABLE LAUNCHED FROM GOOGLE CHROME APPLICATION FOLDER

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



ES|QL query results for malicious DLL loaded by Chrome




CONCLUSION

Google has raised the bar implementing new security controls to protect cookie
data within Chrome. As expected, this has caused malware developers to develop
or integrate their own bypasses. We hope Google will continue to innovate to
provide stronger protection for user data.

Organizations and defenders should consistently monitor for unusual endpoint
activity. While these new techniques may be successful, they are also noisy and
detectable with the right security instrumentation, processes, and personnel.


STEALER BYPASSES AND MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques,
and procedures that threats use against enterprise networks.


TACTICS

Tactics represent the why of a technique or sub-technique. It is the adversary’s
tactical goal: the reason for performing an action.

 * Credential Access
 * Defense Evasion
 * Discovery
 * Execution


TECHNIQUES

Techniques represent how an adversary achieves a tactical goal by performing an
action.

 * Steal Web Session Cookie
 * Process Injection
 * Credentials from Password Stores
 * System Information Discovery
 * Process Discovery
 * Inter-Process Communication: Component Object Model


YARA

Elastic Security has created YARA rules to identify this activity.

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


OBSERVATIONS

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

ObservableTypeNameReference27e4a3627d7df2b22189dd4bebc559ae1986d49a8f4e35980b428fadb66cf23dSHA-256num.exeSTEALC08d9d4e6489dc5b05a6caa434fc36ad6c1bd8c8eb08888f61cbed094eac6cb37SHA-256HardCoreCrack.exePHEMEDRONE43cb70d31daa43d24e5b063f4309281753176698ad2aba9c557d80cf710f9b1dSHA-256Ranginess.exeMETASTEALER84033def9ffa70c7b77ce9a7f6008600c0145c28fe5ea0e56dfafd8474fb8176SHA-256LUMMAb74733d68e95220ab0630a68ddf973b0c959fd421628e639c1b91e465ba9299bSHA-256XenoStealer.exeXENOSTEALER


REFERENCES

The following were referenced throughout the above research:

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

JUMP TO SECTION

 * Google Chrome Cookie Security
 * STEALC/VIDAR
 * METASTEALER
 * PHEMEDRONE
 * XENOSTEALER
 * LUMMA
 * Cookies access by an unusual process
 * Chrome Browser Spawned from an Unusual Parent
 * Untrusted Binaries from Chrome Application folder
 * Unsigned DLLs loaded from google chrome application folder

Show more

ELASTIC SECURITY LABS NEWSLETTER

Sign Up

SHARE THIS ARTICLE

TwitterFacebookLinkedInReddit
 * Sitemap
 * Elastic.co
 * @elasticseclabs

© 2024. Elasticsearch B.V. All Rights Reserved.




NOTICE

We and selected third parties use cookies or similar technologies for technical
purposes and, with your consent, for other purposes as specified in the cookie
policy.



Use the “Accept” button to consent. Use the “Reject” button to continue without
accepting.

Press again to continue 0/1
Learn more and customize
RejectAccept