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.
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.
Fake browser update lure and effectiveness
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.
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 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 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.
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.
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.
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.