CyberArk Labs continuously looks for new threats targeting credentials in order to better understand common attack vectors. CyberArk’s threat hunting effort recently caught an interesting sample of malware. In contrast to credential theft malware like Pony or Loki, which targets many kinds of software, this particular sample only targets the most common browser – Google Chrome. This sample is not even obfuscated. You would expect anti-virus software (AVs) to block it easily… so, why are most AVs not detecting it? Maybe it’s because this malware uses technology that is unusual for malicious software.
Let Me Hide in Your Resources – Dropper Analysis
Before we get into that, let’s talk about the dropper responsible for dropping and executing the credential harvesting payload. When we discovered this malware, the VirusTotal (VT) score was only 11/71 (Figure 1). Now, it has a score of 33/71, which is still quite low.
In fact, this dropper is really basic. It starts by creating a folder \temp in the current path – the parent folder of the dropper. Then, in this fresh new folder, it creates a batch script named “death.bat,” which is a simple script that deletes the \temp directory. Then, the dropper fills the folder with six other files (Figure 2): five DLLs and the interesting binary “virus.exe.” According to the file names, it seems that the binary is using the library cURL (and libcurl’s requirements). Do you know of any other malware using cURL? There aren’t many types of malware that use cURL, which is interesting.
Note that the folder’s total size is approximatively 6MB and no download has occurred. Wait a minute…this is very similar to the file size of the dropper! In fact, all of the files from the new folder are kept in the file resources (Figure 3). This malware has no encryption, no obfuscation and really clear filenames.
Technical Analysis
Dropper Flow and Sneaky Payload Execution
After creating and filling the folder, the malware runs the main binary “virus.exe” (Figure 4) and then waits five seconds before executing the batch script that deletes all traces of the malware.
Next, the malware pops a MessageBox with a generic error message (Figure 5). It is pretty obvious in IDA that the goal is just to fool the user: the MessageBox is intended to make the user think that there was an error in the execution when, in fact, this is the correct flow of the program. (Figure 4).
The Sneaky Virus Targets Your Privacy – Analysis of the Main Payload
The malware has currently zero detections on VT (Figure 6). Despite this score, it can breach your security and steal your Google Chrome credentials
This malware is not only clever, but is also a real threat to your privacy. Nowadays, Chrome is the most common browser in the world. It can not only store all your passwords, but also your credit card data. Moreover, a regular user without admin privileges can access Chrome credential files. This means that the malware does not need any privilege escalation mechanism to get access to Chrome credentials.
This malware follows a very specific flow. It starts by collecting information about the computer. Then, it checks if the cURL library was successfully loaded. Afterward, it gets the current session username and only then does it start reading the Chrome files and getting the passwords.
Google Chrome’s credentials are stored in a SQLite DB file, named Login Data (without extension) usually located in the following folder:
C:\Users\<USERNAME>\AppData\Local\Google\Chrome\User Data\Default\.
When Google Chrome is running, it locks the DB file so that no one can access it during the runtime of the process. In order to bypass this problem, the malware first kills all the chrome processes (Figure 7).
After killing the Chrome processes, it opens the DB file and performs some SQL queries in order to read the secrets kept in it. One of the SQLite queries is really clear (Figure 8) and targets the logins table, which contains the origin_url, username and password. Then, it saves all the data into a structure allocated in the heap.
Once obtained, it simply sends the data via cURL (Figure 9) to its own Google Form. But, what is cURL and why is it using it?
cURL stands for client URL. API docs provide examples using cURL instead of the famous language Python. Indeed, cURL is a very straightforward and powerful command-line tool for data transfer with URL syntax. It supports a number of protocols including HTTP and HTTPS. It is also cross-platformed and very simple to use. cURL’s authors also provide a C library with all the functions needed to integrate it into any application without requiring additional resources on the victim side. Moreover, the number of types of malware using cURL is pretty low and, consequently, it makes it a great tool to use to avoid triggering AVs suspicions.
Google Forms? Let’s Take a Look
Google Forms is a famous free web-based app used to create simple and complex forms for data collection purposes. Often used as a survey tool by companies and students, it gathers data and stores it in a spreadsheet. It also offers a user-friendly web interface. Besides the web interface provided by Google Forms, it is also possible to submit the form through cURL, which adds another dimension to how Google Forms can be used.
This sample contains a hardcoded Google Forms’ URL (Figure 11). The form is simple but clear (Figure 10): it only contains one data field. This data field is set as a paragraph and can contain a huge number of characters – up to 1,000,000,000,000,000,000 by default, which is enough for all of your Chrome data.
Thus, Google Form (Figure 12) acts as a server for gathering and storing all the data that you need. Data in Google Forms can be submitted through post requests.
As soon as we discovered this malicious usage for Google Forms, we informed Google through its Report Abuse link. This form abuse illustrates how attackers can take advantage of legitimate online services in their malicious infrastracture. This is not unique to Google forms, as we have already seen malware that uses pastebin or even Twitter as part of their infrastructure in the past.
Let’s look at the data sending flow using cURL. After initializing the cURL object through curl_global_init and curl_easy_init, the object needs to be configured before it can perform the operation using a series of curl_easy_setopt. In order to harden the analysis, it uses a function pointer (Figure 13) on the curl_easy_setopt function (Figure 14) and use it over the entire function in order to correctly configure the object. One of the parameters of this function is the cURL object’s option – a.k.a CURLOPT – that you want to set. The full list of options with their corresponding decimal code can be found here.
For example, the first option set in our case can be identified through the code in stack 0x2712 = 10015, which corresponds to CURLOPT_URL. This option allows you to set the URL where the request will be sent. Obviously, in this case, it is set to the Google Form’s URL.
Identified as 0x271F = 10015, the next option set is CURLOPT_POSTFIELDS. It contains the data that will be sent through the POST request to the URL defined earlier. It contains, as previously shown, all the data extracted from Google Chrome. Then, it sets the CURLOPT_WRITEFUNCTION to a simple multiplication function – precisely computing size * nmemb where size is always set to 1 and nmemb is the data size – as is required by the library. Finally, it sets the CURLOPT_SSL_VERIFYPEER to 0, which means that it will not verify the authenticity of the peer’s certificate, most likely in order to prevent it from blocking the request in the case of a strange computer digital signature configuration. Finally, it performs the call to curl_easy_perform, which sends the request to the intended URL and THAT’S IT!
Ok, You Win. It is Malware, But Is It Known or Brand New?
As you may have guessed, there is a lot of malware targeting Chrome credentials. As a consequence, we cannot identify the malware family based only on its target.
Our malware, i.e. the main “virus” payload, is not changing any registry nor does it contain strange strings. The malware is silent and very fast running. It takes less than five seconds to complete its task (Figure 4). It does not create any files on the disk and it sends all the data on secured Google Forms. The only indicator of its family is its behavior: it loads libcurl, steals Chrome Credentials by reading the SQLite DB and uses cURL to send this data to the attacker’s Google Forms. None of those indicators clearly correspond to any known malware family.
Let’s find out if a Yara Rule (Figure 15) will provide us more valuable data about this malware. It is based on the current analysis which highlights five indicators:
- Usage of cURL library called libcurl
- Killing Chrome processes: taskkill /f /im chrome.exe
- Using Google Forms
- Using SQLite
- Reading Chrome credentials stored in Login Data
rule browserhax_rule
{
meta:
author = "David Cohen"
company = "CyberArk"
date = "28-07-2019"
strings:
$lib_curl = "libcurl" nocase
$taskkill = "taskkill /f /im chrome.exe" nocase
$doc_form = "https://docs.google.com/forms/" nocase
$sqllite = "sqlite" nocase
$cred_file = "Login Data" nocase
condition:
all of ($*)
}
Figure 15 Finding malware data via the Yara Rule
This method to find other samples using Yara Rules didn’t provide information on the family it belongs to. Instead, we found other very similar samples which are also undetected samples [Figure 16].
In the most recent data, we found other samples with the same filename. Between the matching filesizes and the evidence from the Yara rule, it is clear that this is same family of malware. VT is able to give you a table of the relationships between the selected sample and other samples it analyzed. Those relationships can be found on one of the web reports tabs, labeled “relations.” Let’s select one of the samples we found and check this tab (Figure 17).
It turns out that the sample in Figure 17 is uses the exact same Google Forms and even provides us the dropper’s hash and a link to its report. The dropper’s report looks very similar to the dropper we analyzed in this article. The dropper’s resources include all of the same libraries and the virus.exe binary. It also gave us information about how it lures the user to execute this malware [Figure 18]. It pretends to be the Minecraft installer or the CAB file extractor from Microsoft. It also includes the Microsoft signature in the file properties, but this is not, in fact, a valid signature, as the digital signature verification proves.
You Should Take This New Threat Very Seriously and Prepare Your Defenses
This threat is a Chrome specific Oneshot – i.e. non- persistent – credential stealer. It does not damage your computer at all. It uses the cURL library and Google Forms, which make it hard to catch since it looks like it could really be legitimate software. Abusing legitimate tools for malicious purposes is, once again, very effective against antiviruses and many sign-based and AI-based protections.
Having a strong defense against the fundamental nature of credential stealers on the endpoint is the best way to prevent this kind of attack. For example, solutions like the CyberArk Endpoint Privilege Manager can protect endpoint credential stores that reside in memory, registry or files. The solution also has the ability to block lateral movement like Pass-the-hash, Pass-the-ticket and more. With this product, it does not matter if the malware bypasses traditional security protections — critical resources are protected.
IoCs
- Malicious Activity
taskkill /f /im chrome.exe
- SHA-256
2774a1a4155a9bb874eebad7f24b94571285d9ebf064cb64f64b3aa02f2494d5 – browserhax.exe
[Dropper]
939511e83f40e3ba73c019b6722a5a02a220e4f5947409115a69fa07e71ce9ba – virus.exe
[Malware and main payload]
- Network Communication
https://docs[.]google[.]com/forms/d/e/1FAIpQLSfPwIyN10QEB7-DMIt2qPYPE7cdArN2b19L64F9JQwUOBty-w/formResponse
