Fake browser update attacks

The navigation and wearable devices specialist Garmin recently fell victim to a strain of ransomware known as WastedLocker. Garmin's services were interrupted for several days and a large ransom may have been paid to restore them. WastedLocker, like some other strains of malware which we have encountered, is distributed via fake software updates. This is a type of attack whereby a compromised website uses social engineering tactics to trick users into believing that the web browser (or some other software such as a plug-in) is obsolete and offers the user a bogus update. If the update is accepted, malicious code is downloaded and infects the computer.

In late 2019, CCL's Joshua Tedd and Sergey Ermolovich provided incident response investigation services to a new client whose network had been compromised. The cause of the compromise had ultimately originated from a fake web browser update served to an unwitting employee who had been shopping for supplies. The purpose of their investigation was to determine how the breach had occurred and how it had managed to spread across the client's network from one compromised system ('Patient Zero').

This article covers their examination of Patient Zero in order to determine how the attack began. Certain specific details have been redacted to protect the client's identity.

Circumstances

We took receipt of a number of exhibits, including desktops, laptops and external hard drives from the client. The client also shared documents and reports detailing their infrastructure and the circumstances surrounding the case. Patient Zero had been identified to be a corporate asset: a laptop computer used by an employee.

The initial Incident Response team collected a number of Indicators of Compromise (IoC) from a Carbon Black instance on the client's network. These IoC included the following IP address:

185.243.113[.]122

This IP address had been identified as potentially being connected to a threat because multiple endpoints had connected to it around the same time on 07 October 2019. However, a search for this IP address using our own proprietary IoC triage tool did not identify any previously reported malicious behaviour. This may suggest that the IP address is distinct to this particular attack.

As a result of the client's own internal investigation, the potential use of the Dridex malware and the presence of Ransomware was speculated. However, upon our own examination of the exhibits, this did not appear to be the case as no files appeared to have been encrypted. Instead, our analysis suggested that a Remote Access Trojan (RAT) was actually the type of malware used, alongside malicious scripts.

Finding the Source

After creating a forensic image of Patient Zero, its contents were indexed and searched. After searching for activity around 07 October 2019, the following Windows Scheduled Task was discovered, due to trigger at 10 am on that day:

The task was scheduled to execute the file slui.exe located in C:\Users\<user>\AppData\Roaming\1L2ME. What's interesting about this is that slui.exe is a legitimate Windows executable file, but it should not be residing in the user's AppData folder. This is where the second part of the attack began, which may be a topic for another article in the future...

Scheduled Tasks on Windows are stored as files in C:\Windows\System32\Tasks. Our task in this case was named Kteyohsjuch and was created on 03 June 2019 at 08:49:08. The plot thickens! Based on this date and time, another search was performed for activity that occurred on 03 June 2019. The results included notable web browser activity which took place around the time of creation of the task. The browser had been used to visit the following websites:

• hxxps://www.pink-dots[.]de/farbwelten/dunkelblau/1048/12-papiertueten-koenigsblau

• hxxps://www.amazon[.]de/Blaue-BENAVA-Geschenktüten-Papiertüten-Adventskalendern

• hxxps://www.idee-shop[.]com/rico-design-papiertuete-blau

• hxxp://www.partystrolche[.]de/papiert%C3%BCten-blau-p-8659.html

Further examination indicated that the user had been redirected from partystrolche[.]de to a malicious website harbouring a fake update attack.

In the timeline of user activity, we observed that following the redirect, the user did indeed download a file from the website; it was named Firefox.Update.326f86.zip.

Analysing the Fake Update

The ZIP file contains a JavaScript file named Firefox.js. It was extracted, opened in a text editor and reformatted to make it easier to read. But as the following image illustrates, the script was heavily obfuscated:

A rather large block of data is present at the end of the file; this comprises encrypted code that this script decrypts and then executes. But there are multiple deobfuscation steps and function calls which are made first, and the script itself looks rather daunting. As with most obfuscated code however, there is usually a way for the script to execute the decrypted code. Function calls in the JavaScript programming language are denoted with (), so looking for pairs of parentheses may reveal where the execution occurs. We can then use a debugger to stop execution at that line in the code and take a closer look. Looking through the script, line 50 looks like a good place to start:

The debugger built into the Chrome web browser (DevTools) was used to set break points in the script and step through the code. It is very important that a virtual machine or an isolated, disposable machine is used for this task to prevent infecting ourselves.

Running the script after placing a breakpoint at line 50, and then stepping into the function call, we get something that looks like this:

Well, this looks a lot more manageable! This is the script contained within the block of data at the end of the first. However, this script also contains a block of data at the end… perhaps another script? But why? Well, this second script is likely intended to be yet another protection against effective analysis. While the first script obfuscates (i.e. hides away) the second script, this script provides an anti-analysis trick! Its job is to decrypt the third (and thankfully final) part of the script and execute it on line 29 (notice the ()?).

But it uses a copy of itself and a copy of the previous script to derive a decryption key; this occurs on lines 3 and 4. This ensures that nobody has tampered with the script and may be an attempt to impede analysis. The decryption key is derived using the following function:

The second method is particularly relevant here, as changing the script in any way will result in an incorrect decryption key!

Once it has been derived, the key is used to decrypt the block of data at the end of the script, via the routine at line 19. The decrypted data is then executed on line 29. Placing another breakpoint here and stepping into the function call, we wind up in the third script!

The following extract from the third script shows functions responsible for decrypting a URL and decoding content:

The following extract shows functions responsible for encrypting strings and decoding payloads:

The following extract shows where the main functionality of the script is executed. By setting breakpoints at different points in the code, it is possible to view what each of the values are, and step through what the script is doing.

In summary, this final script performs the following steps:

• A URL is decoded and saved in the fileUrl variable. In this instance, the (sanitised) URL is green.mattingsolutions[.]co/empty.gif. A random 8-character string is generated and prepended to the URL, resulting in a URL similar to the following (sanitised) example: hxxp://2e0332e3.green.mattingsolutions[.]co/empty.gif.

• The code to generate a new HTTP POST request is called once a few more variables are constructed, within the initialRequest1() function. A randomly generated 8-character hexadecimal string (e.g. b9798426), a TID value which was decoded at the beginning of the script (in this case 507) and the current date and time in the Unix epoch format (e.g. 1576684784554) are then concatenated together (e.g. 0=b9798426&1=507&2=1576684784554&) and then passed through an encryption routine to produce an encrypted string.

• An HTTP POST request is then generated, destined for the generated URL, with a payload containing the encrypted string. An example POST request sent by the script is displayed in the image below.

• The script then waits for a valid response from the command and control server, awaiting a response with HTTP status code 200. When a response is received, it attempts to decode the content by deriving a key contained within the received payload. The resulting JavaScript is then executed using the eval() command on line 126.

• The script then determines if a function exists with the name step2. If one does not exist, it performs a clean-up via the endOfWork function and shuts down. The endOfWork function attempts to find the file name and path relating to itself, and then deletes the original script.

Our analysis of this payload was carried out some time after the initial attack. Therefore, the next payload the script would have retrieved and executed was no longer available, perhaps having been taken down by the attacker or by law enforcement. We believe that payloads downloaded and executed by this loader created the scheduled task, copied the legitimate Windows executable into the AppData folder, and also placed a malicious version of one of the required DLLs in the same folder, ready to begin the second stage of the attack which took place in October 2019.

Managing the Risk

This is only one example of the sort of malware campaign which uses legitimate looking websites to host harmful software. Other similar attacks have been observed which deploy banking trojans, spyware and ransomware to unwitting victims. The financial and reputational damage caused by such malware could be devastating.

The delivery of the initial payload in this type of attack relies on social engineering and can often evade traditional anti-virus scanning software. The National Cyber Security Centre advises adopting a 'defence in depth' approach to tackle the risk of malware infection. Technical solutions, such as backups, security updates, filters and firewalls, must be accompanied by security education so that staff can learn to spot and avoid potential threats online.

Cyber attacks are becoming more frequent and human error is a major factor in many of them. Security awareness training can be used to inform staff about the range of threats that they could encounter and teach them how to recognise common attack techniques, such as phishing and social engineering. It is also an opportunity to remind them of security policies and guidelines which will keep them and the business safe. Regular, engaging, refresher sessions will help to ensure that standards do not slip over time.

With adequate preparation, a malware attack need not be disastrous. When a compromise does occur however, it is important to be able to return to business as usual quickly, but it also vital that lessons are learnt to avoid another incident. This may require a full forensic investigation of the affected systems, as described in this article.

To learn more about how CCL can help your organisation be ready to face the risks of cyber attacks, and to respond if the worst does occur, please get in touch.

‍