Key Takeaways
-
Proofpoint is tracking multiple different threat clusters that use similar themes related to fake browser updates.
-
Fake browser updates abuse end user trust with compromised websites and a lure customized to the user's browser to legitimize the update and fool users into clicking.
-
Threat actors do not send emails to share the compromised websites. The threat is only in the browser and can be initiated by a click from a legitimate and expected email, social media site, search engine query, or even just navigating to the compromised site.
-
The different campaigns use similar lures, but different payloads. It is important to identify which campaign and malware cluster the threat belongs to help guide defender response.
Overview
Proofpoint is currently tracking at least four distinct threat clusters that use fake browser updates to distribute malware. Fake browser updates refer to compromised websites that display what appears to be a notification from the browser developer such as Chrome, Firefox, or Edge, informing them that their browser software needs to be updated. When a user clicks on the link, they do not download a legitimate browser update but rather harmful malware.
Based on our research, TA569 has used fake browser updates for over five years to deliver SocGholish malware, but recently other threat actors have been copying the lure theme. Each threat actor uses their own methods to deliver the lure and payload, but the theme takes advantage of the same social engineering tactics. The use of fake browser updates is unique because it abuses the trust end users place in both their browser and the known sites that they visit.
Threat actors that control the fake browser updates use JavaScript or HTML injected code that directs traffic to a domain they control, which can potentially overwrite the webpage with a browser update lure specific to the web browser that the potential victim uses. A malicious payload will then automatically download, or the user will receive a prompt to download a “browser update,” which will deliver the payload.
Fake browser update lure and effectiveness
The fake browser update lures are effective because threat actors are using an end-user's security training against them. In security awareness training, users are told to only accept updates or click on links from known and trusted sites, or individuals, and to verify sites are legitimate. The fake browser updates abuse this training because they compromise trusted sites and use JavaScript requests to quietly make checks in the background and overwrite the existing, website with a browser update lure. To an end user, it still appears to be the same website they were intending to visit and is now asking them to update their browser.
Proofpoint has not identified threat actors directly sending emails containing malicious links, but, due to the nature of the threat, compromised URLs are observed in email traffic in a variety of ways. They are seen in normal email traffic by regular end users who are unaware of the compromised websites, in monitoring emails such as Google alerts, or in mass automated email campaigns like those distributing newsletters. This creates a situation where these emails are considered to be malicious during the time the site is compromised. Organizations should not treat the fake browser update threats as only an email problem, as end users could visit the site from another source, such as a search engine, social media site, or simply navigate to the site directly and receive the lure and potentially download the malicious payload.
Each campaign uniquely filters traffic to hide from researchers and delay discovery, but all the methods are effective at filtering. While this may reduce the potential spread of malicious payloads, it enables actors to maintain their access to the compromised sites for longer periods of time. This can complicate the response, because with the multiple campaigns and changing payloads, responders must take time to figure out what they need to look for and identify the relevant indicators of compromise (IOCs) at the time of the download.
Campaigns
The current landscape includes four different threat clusters using unique campaigns to deliver fake browser update lures. Due to the similarity in the lures and attack chain, some public reporting has incorrectly attributed the activity to the same threat cluster. Based on Proofpoint's distinct visibility, Proofpoint researchers were able to break these into more granular clusters.
Proofpoint’s research focuses on the fake browser update landscape overall, to provide details on how defenders can identify each unique campaign, as well as additional links to additional Proofpoint or third-party reporting containing in-depth research and analysis. For example, Jérôme Segura of Malwarebytes has put together a good resource showing some of the images each campaign uses as lures on GitHub.
Each campaign has some general shared characteristics that can be described as three distinct stages of the campaign. “Stage 1” is a malicious injection on a legitimate, but compromised, website. “Stage 2” refers to the traffic to and from the actor-controlled domain that does most of the filtering and hosts the lure and malicious payload. “Stage 3” is the execution of the payload on a host after download.
SocGholish
SocGholish is the primary threat that people think of when talking about a fake browser update lure and it has been well documented over the years. Proofpoint typically attributes SocGholish campaigns to a threat actor known as TA569. Proofpoint has observed TA569 act as a distributor for other threat actors.
Currently, TA569 is using three different methods to direct traffic from the stage 1 compromised websites to their actor-controlled stage 2 shadowed domains.
The first method is using an injection that utilizes the Keitaro traffic distribution system (TDS) via a variety of actor-controlled domains. Those domains will filter some requests out before routing to the stage 2 domains. Most of the injects that point to Keitaro TDS URLs will contain multiple different redirect domains in the same file, as seen in figure 2 below.
The second method TA569 uses is Parrot TDS (also known as NDSW/NDSX) to obfuscate their injected code and apply similar filtering before routing requests to the stage 2 domains. Compromised websites may contain as many as 10 malicious JavaScript files that all contain Parrot TDS injections leading to SocGholish payloads.
The third method TA569 uses is a simple JavaScript asynchronous script request in compromised websites’ HTML that reaches out to a stage 2 domain.
The variety of injections make it difficult for defenders to both identify the location of the malicious injection and reproduce the traffic due to the various stages of filtering.
Each of these methods reaches out to a stage 2 domain which does additional filtering and will deliver the fake browser update lure and payload to traffic that passes the filtering. The payload can be either a plain JavaScript (.js) file, usually named “Update.js”, or a zipped JavaScript file. If the payload is executed by the user, it will first fingerprint the host via wscript. Depending on the results of the fingerprinting, the JavaScript will either quit, load a remote access trojan (RAT), or wait for further commands from the threat actor, which has been reported leading to Cobalt Strike or BLISTER Loader. Proofpoint has recently observed SocGholish infections leading to AsyncRAT and NetSupport RAT as the RAT payloads.
Figure 1. SocGholish fake update lure spoofing a Chrome update.
Figure 2. Keitaro TDS inject example.
Figure 3. Parrot (NDSW) inject example.
Figure 4. Asynchronous inject example.
RogueRaticate/FakeSG
The second fake browser update our researchers identified is known as RogueRaticate or FakeSG. Proofpoint first identified this activity in May 2023, and third-party researchers dubbed it a copy of the existing and high-volume SocGholish campaigns. The activity may have started in the wild as early as November 2022. Proofpoint does not attribute the RogueRaticate activity to a tracked threat actor at this time, and it has consistently been distinctly differentiated from SocGholish campaigns.
RogueRaticate injects heavily obfuscated JavaScript code into existing JavaScript files on stage 1 websites. The injected JavaScript reaches out to a stage 2 domain. The stage 2 domain hosts a Keitaro TDS that filters out unwanted requests and responds with a blank “body” value in a JSON response. When it identifies a target to receive the lure, it sends the lure double Base64 encoded in the “body” value. The lure contains a button which, if pressed, uses an HTML href attribute to download the payload from a separate compromised site, typically hosted on WordPress.
The fake update payload for the RogueRaticate campaigns has always involved an HTML Application (.hta) file. The HTA is either zipped or downloaded via a shortcut (.url) file that points to the .lnk. The .hta file typically loads a malicious NetSupport RAT payload onto the host via the same stage 2 domain that hosted the malicious payload.
Figure 5. Example RogueRaticate fake update lure spoofing a Chrome update.