ClearFake Campaign - Delivering Malware via “Fake Browser Updates

Introduction

ClearFake is a relatively new, malicious JavaScript framework that was first identified in July 2023 by security researcher Randy McEoin. This malware was originally named ClearFake due to the lack of obfuscation techniques used in the early versions of this JavaScript code. A link to Randy’s blog can be found in the reference section of this report.

Like other fake update campaigns, the ClearFake malware uses social engineering tactics to present a malicious “fake browser update” page to the victim user. This fake update page, delivered through JavaScript iframes, uses legitimate branding to trick a user into downloading a fake, malicious browser update package. The payload is then downloaded onto the victim’s machine.

This file has been packaged in different ways across various campaigns and as several different file type extensions, ranging from Windows executable (.EXE) files to Windows Application files (.APPX). This payload, a malware loader, is designed to conduct further malicious activity on the victim host and boasts a number of capabilities from information stealing to Command-and-Control (C2) mechanisms.

We’ve observed numerous payloads being delivered by the ClearFake campaign including Amadey, SocGhoulish, and a variety of information stealer malware families. 

Figure 1: Diamond Model depicting ClearFake capabilities and Infrastructure.

ClearFake Deploys “Fake Browser Updates”  

The ClearFake Origins

Threat actors are injecting malicious JavaScript code which can download and execute malicious JavaScript payloads. This malicious JavaScript code is injected into the target website through compromised WordPress plugins. These websites are then used to host malicious JavaScript content and deliver it to victim users through ‘watering hole’ style attacks.

A watering hole attack is a technique which often uses a legitimate website that has been compromised via other means or, in some cases, an impersonating website designed to look and feel like a website that the target victim would commonly navigate to.

By using a website that is familiar to the victim, the victim is more likely to frequently visit the website and interact with it, which enables an attacker to manipulate the victim’s trust.

Figure 2: The ClearFake infection chain, as observed by the Bridewell CTI team. 

Once the target website has been compromised by an attacker, the malicious JavaScript is injected into a page on the website and executes when the target navigates to the website. 

Figure 3: An example of an early ClearFake JavaScript payload, after deobfuscation. Source: Sekoia. 

The Emergence of EtherHiding

Over the last few months, the ClearFake distribution technique has evolved. Threat actors are now using different methods to download and execute malware, moving away from embedding malicious JavaScript to employing a relatively new technique, EtherHiding. 

The EtherHiding technique has been described as an evolution of the initial ClearFake technique, which uses the Binance SmartChain technology to propagate malicious JavaScript into the target, victim website. Like ClearFake, EtherHiding uses WordPress plugins and vulnerabilities.

The Binance Smartchain is a blockchain technology which is owned by Binance, a major cryptocurrency broker. The Binance Smartchain is designed to operate similarly to other blockchain technology, like Bitcoin and Ethereum, and works to enable developers to build and use decentralised applications and trade digital assets.  

By using the EtherHiding technique, threat actors can manipulate the Binance Smartchain by hiding the initial payload, which then communicates back to second-stage domains hosting further JavaScript files which are responsible for delivering the fake page update pages to the victim’s browser using HTTP iFrames.

We also observed the execution of further malicious JavaScript on the affected website which was used to fingerprint the victim’s browser. By executing specific JavaScript commands, the threat actor collected and transmitted data to enable them to understand which browser was in use. With this data, the threat actor displayed a different fake browser page depending on which browser was being used, the CTI team observed variations of this page including one for Chrome, Firefox and Microsoft Edge. The below is an example of what the fake update payload looks like, when loaded into a victim browser. 

Figure 4: Malicious JavaScript executes a “fake update” window.

The above fake update page is displayed to the victim user upon navigating to a website. Often, the victim will not realise that this website has been compromised and may be led to believe that the fake update popup has originated from Chrome itself. Upon closer inspection of one of these compromised websites, we were able to uncover the malicious JavaScript code, which was encoded in Base64. 

Figure 5: JavaScript connection to malicious infrastructure, observed in Chrome. 

Figure 6: Base64 encoded JavaScript used to communicate with the Binance SmartChain.

The above base64 encoded javascript, once decoded, shows the code which communicates with the Binance Smartchain.

Figure 7: The base64 string, decoded. 

Using the above base64 encoded Javascript payload, we used this string to conduct further hunting and discovered over 1000 public facing servers that had been compromised.

Following analysis of this JavaScript execution, we conducted pivoting using the IOCs identified. A full list of IOCs can be identified in the appendix of this article.

Figure 8: Malicious domains involved with the execution of ClearFake. 

Using these IOCs, we conducted further research. Pivoting identified 12 servers connected to ClearFake C2 activity, alongside this, a number of IOCs were also found which resolved to the Keitaro TDS (Traffic Distribution System), which was used by the ClearFake operators to deliver further payloads.

A traffic distribution system uses webpage technology to filter incoming traffic based on specific criteria, the traffic directed to the TDS can then be filtered and redirected to alternate destinations. We had identified a number of these TDS related IP addresses and have added hunting queries to our malicious infrastructure database to track their activity moving forward.  

The Infection Chain Continued – ClearFake Malware Loader

Once the user interacts with the malicious browser update page, a connection is made and used to download malware onto the victim’s machine. In the case of a recent incident we investigated, this fake browser update page caused a connection to a Dropbox URL which then delivered the malicious payload, ChromeSetup.exe.

Figure 9: Dropbox URL within VirusTotal. 

Figure 10: MITRE Attack TTPs for ClearFake loader malware.

ChromeSteup.exe – Local Group and Credential Enumeration

When executed, the ChromeSetup.exe malware uses multiple mechanisms to conduct information stealing actions, including enumeration of local accounts and loading of legitimate DLL (dynamic link library) files used by the Microsoft SAM (Security Account Manager).

Figure 11: The ClearFake loader conducts enumeration of local accounts. 

Secondly, the ChromeSetup.exe malware loads the “samlib.dll” library, a legitimate Microsoft DLL file which is used to access the Microsoft Security Account Manager database. This database contains stored information about user accounts and their credentials, highlighting another clear capability of the malware. 

Figure 12: The samlib library can be used to interact with the Microsoft Security Account Manager. 

ChromeSetup.exe – Obfuscation and Anti-VM Techniques

The ChromeSetup.exe was also observed performing defence evasion techniques including anti-virtualisation techniques and the use of encoded commands to avoid detection through anti-virus or other security tooling.

As an example, the ChromeSetup.exe malware was observed executing via PowerShell, using Base64 encoding as an obfuscation tactic. By obfuscating their activity, threat actors can more easily perform activity that may remain undetected. 

Figure 13: Base64 encoded PowerShell allows an attacker to more easily evade detection. 

When de-obfuscated, this command reveals itself as the following:

“Powershell.exe -NoProfile -enc Start-Sleep -s 10”

As shown above, this PowerShell command executed the ChromeSetup.exe with a sleep time, which allows the malware to sleep, or not execute, until the specified time elapses. By dictating when malware should or should not execute, a threat actor can more easily evade detection or sandbox analysis.

The below KQL queries can be used to hunt for this activity.

//Specific KQL query to detect ClearFake loader malware executing a sleep command, encoded with base64.
DeviceProcessEvents
| where FileName == "powershell.exe"
| where InitiatingProcessFileName == "ChromeSetup.exe" and ActionType == "ProcessCreated"
| where ProcessCommandLine contains "-NoProfile -enc UwB0AGEAcgB0AC0AUwBsAGUAZQBwACAALQBzACAAMQAwAA=="

//A broader query identifying all PowerShell encoded commands.
DeviceProcessEvents
| where FileName == "powershell.exe" and ActionType == "ProcessCreated"
| where ProcessCommandLine contains "-NoProfile -enc"

Along with this, we also observed further interesting obfuscation techniques including the use of some anti-virtualisation techniques conducted using WMI queries. 

Figure 14: The ClearFake malware loader conducts sandbox evasion techniques using WMI. 

In the above command, the malware executed a Windows Management Instrumentation (WMI) query to check the temperature of the CPU of the victim machine. This command is used as an anti-sandbox technique by threat actors due to the way that this command operates on virtualisation technology. 

Figure 15: The ClearFake loader malware was identified conducting WMI queries to evade sandbox tools. 

When executed in a sandbox or virtualised environment, this command will return an error due to the fact that the “MSAcip_ThermalZoneTemperature” WMI class is not supported on a virtualised processor. Using this information, a threat actor can execute this command as a mechanism to understand if their malicious program is operating inside a virtualised environment. 

Figure 16: The Bridewell CTI team conducted research into this sandbox evasion technique. 

In the above screenshots, when running on a physical host, we can see that the first instance of the command was successful. Following this, execution of the same command within a virtual machine shows that the command fails which can be used by an attacker to indicate that their malicious software is running on a virtualised environment. 

ChromeSetup.exe & MsBuild.exe – Process Injection

The ChromeSetup.exe malware also displayed further capabilities, notably the ability to conduct process injection techniques; in which the ChromeSetup.exe malware leveraged the MSBuild.exe process. 

Figure 17: The ClearFake malware uses process injection techniques. 

Process injection is a technique used by threat actors for a multitude of reasons and involves executing malicious code through the context of another process to more easily evade detection from anti-virus, endpoint detection and response (EDR) or other security tools.

Hunting for this type of process injection technique can be executed using the following KQL query.

//Check for ClearFake loader malware executing process injection via MSBuild.exe. 
DeviceProcessEvents
| where ActionType contains "ProcessCreated"
| where InitiatingProcessFileName == "ChromeSetup.exe" or InitiatingProcessFileName == “MicrosoftEdgeSetup.exe”
| where FileName contains "MSBuild.exe"

Figure 18: MSBuild.exe was used to perform information stealing techniques. 

The MSBuild.exe process conducted further information gathering actions, including attempted access of browser related resources, such as Chrome browser files.

Following the information gathering actions, the MSBuild.exe executable was observed conducting command-and-control communication with various external IP addresses, a full list of observed IOCs can be found in the appendix section. 

Figure 19: Research conducted by Bridewell CTI into MSBuild command-and-control techniques.

As shown in the above screenshot, these IP addresses have been identified as malicious in VirusTotal and attributed to WordPress exploitation, which also correlates to the original ClearFake infection chain. The following KQL query can be executed to hunt for this activity.

//Check for outbound connections via the injected MSBuild.exe process.
DeviceNetworkEvents
| where InitiatingProcessFileName == "MSBuild.exe" //or InitiatingProcessParentFileName == "ChromeSetup.exe" or InitiatingProcessParentFileName == "MicrosoftEdgeSetup.exe"
| where not (ipv4_is_private(RemoteIP))

Wider Payload Delivery

Once the malicious ChromeSetup.exe malware executed and conducted the above actions, we observed further malicious payloads being downloaded and executed.

Figure 20: MSBuild.exe was used to download and execute further malware. 

The above screenshot shows MSBuild.exe contacting and downloading an executable file from the above URL. Wider research revealed that this IP address was attributed to Amadey malware. Amadey malware, first discovered in 2018, is a malware which boasts numerous techniques and displays characteristics of botnet and trojan mechanisms. 

Figure 21: Further payloads attributed to Amadey malware. 

When executed in a sandbox, this malicious file demonstrates a variety of malicious activities which can be attributed to Amadey. For example, as shown below, the malicious file (named differently in this environment) conducts command-and-control activity and communicates with the below IP address using a HTTP connection.

Figure 22: The Bridewell CTI team conducted analysis of Amadey within a sandbox environment. 

We used this IP address to conduct wider pivoting and fingerprinting and, by doing so, the team uncovered 7 IP addresses relating to Amadey command-and-control activity and 4 more IP addresses on this same subnet, attributed to various other malware families, including a cryptocurrency miner (XMRIG) and Redline Stealer.

To confirm these findings, the team also conducted sandbox analysis of the uncovered IP addresses, which all displayed a login panel when appended with the correct URL string. 

Figure 23: Wider research reveals an Amadey login panel. 

The Amadey malware also created scheduled tasks to establish persistence, allowing the threat actor to maintain access between reboots of the victim machine.

Figure 24: The Amadey payload was observed conducting persistence techniques. 

As above, the Amadey malware utilised “schtasks.exe”, a legitimate Microsoft process, to create a task using the “/sc” flag with “MINUTE” value and the “/mo” flag with the “1” value instructing Amadey to run every minute. The command also uses the “/tn” flag to execute the malware from the Temp directory.

We also observed Amadey conducting information gathering, including the execution registry queries to gather information about the target host. 

Figure 25: The Amadey payload was observed conducting information gathering techniques. 

Lastly, the Amadey malware also boasts an interesting technique to conduct defence evasion using the CACLS Windows command. The CACLS command enables an administrator to display or modify Access Control Lists (ACLs) for files and folders, enabling or preventing read/write permissions for specific users. 

Figure 26: Evidence of Amadey malware executing CACLS commands. Source: VMRay

In wider reporting, security researchers from VMRay observed the Amadey malware using the above command for defence evasion purposes. By using the “cacls <filename> /P <user> /E” command, the malware changes access rights to read only, preventing the deletion of the malicious file.

To test this, we conducted a similar series of commands inside a sandbox environment. 

Figure 27: CACLS can be used to prevent a user from deleting a file. 

As shown above, the command has prevented this file from being deleted without Administrator permission, effectively acting as a Defence Evasion technique by preventing standard users from being able to delete the file.

Figure 28: Research conducted by the Bridewell CTI team into the usage of this command. 

The above screenshot shows that this command was detected by Microsoft Defender however, no alert was raised for this activity in our sandbox. We did not observe this technique in our customer environment as the intrusion was mitigated. To combat this, the following KQL queries can be used to hunt for this technique.

//Checks for usage of CACLS modifying user permissions with specific parameters. Ignores iCACLS.
let cacls_commands = dynamic(["/p", "/n", "/e", "/r", "/t"]);
DeviceProcessEvents
| where ActionType == "ProcessCreated" and ProcessCommandLine == "cacls.exe" and ProcessCommandLine !contains "icacls.exe"
| where ProcessCommandLine has_any (cacls_commands)

//Checks for usage of CACLS modifying user permissions, specifically with the “n” and “r” permissions.
let cacls_commands = dynamic([":n", ":r"]);
DeviceProcessEvents
| where ActionType == "ProcessCreated" and ProcessCommandLine == "cacls.exe" and ProcessCommandLine !contains "icacls.exe"
| where ProcessCommandLine has_any (cacls_commands)

Wider Campaigns and Malware Delivery

In wider reports and campaigns observed in various articles, the ClearFake technique has been used to deliver a variety of second-stage malware payloads such as Amadey and SocGholish which have both been attributed to further delivery of ransomware.

Alongside this, wider campaigns also reported delivery of various botnet and information stealing malware including LummaStealer, RacoonStealer, StealC, HijackLoader and SystemBC.

Conclusion and Recommendations

The ClearFake fake browser update campaign was first seen in July 2023 and continues to exist as a widespread threat due to the nature of the attack and the large target audience. By using watering-hole style attacks, the ClearFake campaign aims to deliver malicious payloads through execution of malicious JavaScript commands, delivered to legitimate, compromised websites through WordPress vulnerabilities and plugins.

We have outlined recommendations to ensure that organisations are protected against this threat.

• Organisations should ensure that they are utilising security tooling including Anti-Virus software and Endpoint Detection and Response (EDR) tools to ensure that they are protected against malicious software on their devices.
• End users should be made aware of and trained to prevent execution of untrusted software, this includes software downloaded from the internet and also software obtained through other means. End users should be prevented from downloading suspicious or untrusted software, especially from the internet.
• Organisations should ensure that policies are implemented to ensure that passwords are secure and are not reused.
  • Password policies should be implemented to ensure that a strong password is used, containing over 12 characters and a combination of uppercase and lowercase letters, numbers and symbols.
  • Passwords should not be re-used between services and tools, end users should be made aware of the risks and dangers of password-based attacks, especially credential reuse attacks. 

Appendix

Indicators of Compromise (IOCs)

MITRE Attack Tools, Techniques and Procedures (TTPs)  

References