On August 29, 2024, a blogpost by Google‘s Threat Analysis Group (TAG) reported the convergence of State-backed attackers and commercial surveillance vendors (CSVs) in their use of similar exploits for cyber-attacks. This phenomenon highlights a troubling trend where both types of actors leverage the same vulnerabilities to achieve their objectives, raising significant concerns about cybersecurity and the integrity of digital communications. The article emphasizied the role of CSVs, which have become increasingly sophisticated and influential in the cyber landscape.
These vendors often provide tools and services that facilitate surveillance and data collection, targeting individuals such as journalists, activists, and political figures. Furthermore, Google’s Threat Analysis Group (TAG) highlights the concerning use of cookie-stealing payloads by state-backed attackers, particularly in the context of a cyber-attack attributed to the Russian group known as APT29 (aka Cozy Bear). This attack involved the exploitation of vulnerabilities in Mongolian government websites, allowing the attackers to infiltrate devices and steal sensitive data, including session cookies.
According to the source, the delivery of this payload occured when attackers injected malicious scripts into trusted websites to target unsuspecting users’ browsers. The article emphasizes that the stolen cookies can grant attackers unauthorized access to user accounts, effectively bypassing authentication mechanisms. APT29’s recent operations showcased the use of sophisticated techniques to extract cookies from users visiting compromised websites. The payloads employed in these attacks often involve JavaScript code that retrieves cookies and sends them to an attacker-controlled server.
For instance, a common method involves using an image tag or a script tag that executes a request to the attacker’s server, effectively exfiltrating the cookie data without the user’s knowledge.The article also notes that the exploits used by APT29 bear striking similarities to those developed by commercial spyware vendors like NSO Group and Intellexa. The TAG report suggests that while these companies claim to sell their tools only to government agencies for lawful purposes, the vulnerabilities they leverage on can easily be exploited by other malicious actors.
Chrome Cookie-Stealer Payload
TAG reported the use of a specific Chrome-oriented cookie-stealer payload delivered against the designated victims in the context of State-sponsored cyber operations (sha256:df21c2615bc66c369690cf35aa5a681aed1692a5255d872427a2970e2894b2e3). This implant is called ANDROSNATCH. As reported in the article “Once the Chrome sandbox is escaped, a new payload is dropped into /data/data/com.android.chrome/c.so and executed via LD_PRELOAD“. The code under analysis unveils a piece of malware designed for data exfiltration from Android devices, particularly focusing on sensitive information stored within the Chrome browser. Interesting to note, it employs a combination of evasion techniques, obfuscation, and dynamic library loading to achieve its malicious goals while attempting to remain undetected. The piece of malware we are analyzing is LD_PRELOADed by exploiting the CVE-2024-4671. As initial stage, in fact, the attacker exploits CVE-2024-4671 to gain code execution within the Chrome Sandbox, drop / execute a new payload under /data/data/com.android.chrome/c.so. At the beginning of go() function, the code unsets the LD_PRELOAD and LD_LIBRARY_PATH environment variables;
The fact that the code goes to unset the LD_PRELOAD is perfectly compatible with a multi-stage attack where the initial compromise might have used LD_PRELOAD, but the subsequent payload (the code we’re analyzing) is taking steps to secure its position and avoid further manipulation. The unsetting of LD_PRELOAD in fact could be done for two main reasons:
1. Prevent Further Hijacking: By unsetting LD_PRELOAD, the malware ensures that no other malicious or security tools can use the same technique against it. It’s essentially cleaning up the environment to protect itself.
2. Evade Detection: Some security tools might look for the presence of LD_PRELOAD as suspicious indicator. By unsetting it, the malware is likely trying to reduce its visibility.
The malware also takes steps to cover its tracks by deleting the “c.so” file (the malware itself) and clearing Chrome‘s crash report directories, hindering forensic analysis.
Despite its malicious intent, the code also exhibits some level of error handling and cleanup routines. It checks the return value of curl_easy_perform to ensure successful data transmission and prints an error message if it fails. Additionally, the presence of functions like _atexit_handler_wrapper, atexit, and pthread_atfork suggests that the malware might perform cleanup actions before terminating, potentially further erasing its traces from the compromised system.
The core functionality of the malware only lies in its data exfiltration capabilities. The send_info function is responsible for targeting and extracting valuable user data from Chrome‘s storage. It specifically focuses on files containing cookies, login credentials, browsing history, and even potentially sensitive information like passwords stored within the Account Web Data file. The stolen data is then encoded using Base64, a common technique to ensure safe transmission over the network, and sent to a remote command-and-control (C2) server via HTTP POST requests. The use of libcurl for network communication, loaded dynamically at runtime using dlopen and dlsym, further adds to the malware’s evasive nature, as it avoids statically linking the library, making detection more challenging.
The function reads the content of these files, encodes it using Base64, and then sends it to a remote server using the libcurl library. The data is sent as part of a POST request with specific parameters (st, tt, size, dtta). The C2 address is embedded within the argument passed to the curl_easy_setopt function with the option CURLOPT_URL (code 10002). The placeholder {{adr0}}{{adr1}}... indicates where these chunks are inserted.
The st and tt parameters appear to have fixed values, while size and dtta are dynamic.
The request includes a Content-Type header with the value text/plain; charset=x-user-defined. The dtta parameter contains the stolen data, which is, as said, Base64 encoded. These parameters could be useful to create network-based detection rules, similar to the following:
#require ssl/tls inspection#
alert tls any any -> any any (msg:"ET Malware - Potential AndroSnatch Data Exfiltration via HTTPS POST Request"; flow:established; method:POST; http.request_body; content:"st=5&tt=egg0lgya14e01535xpd538zm&size="; http.request_body; content:"&dtta="; http.request_body; pcre:"/&dtta=[A-Za-z0-9+\/=]+={0,2}&?$/"; http_header:"Content-Type: text/plain; charset=x-user-defined"; sid:xxxxxxx; rev:1;)Conclusions
The analyzed code reveals a piece of malware designed for stealthy data exfiltration, targeting Android devices and specifically focusing on sensitive information stored within the Chrome browser. It employs a range of techniques to evade detection and analysis, including anti-debugging measures, dynamic library loading, and obfuscation of the command-and-control (C2) server’s address.
The malware’s primary objective is to steal valuable user data from Chrome, such as cookies, login credentials, browsing history and passwords. It achieves this by directly accessing Chrome’s data files and exfiltrating the stolen information to a remote server using encrypted HTTPS POST requests. The use of Base64 encoding further ensures the safe transmission of the data.
The code’s structure and techniques suggest a good level of sophistication and intent to remain hidden. The dynamic loading of the libcurl library and the obfuscation of the C2 address demonstrate an effort to evade detection by traditional security tools and static analysis. The inclusion of anti-debugging measures further indicates the malware author’s desire to hinder analysis and reverse engineering attempts.
Indicators of Compromise
Please refer to the original Google TAG’s post here