Fake browser update pages are "still a thing"

Published: 2020-02-05
Last Updated: 2024-06-10 03:24:05 UTC
by Brad Duncan (Version: 1)
1 comment(s)


SocGholish is a term I first saw in signatures from the EmergingThreats Pro ruleset to describe fake browser update pages used to distribute malware like a NetSupport RAT-based malware package or Chthonic banking malware.  Although this activity has continued into 2020, I hadn't run across an example until this week.

Shown above:  A recent infection chain from the SocGholish campaign.

Fake browser update pages

The beginning of an infection chain starts with a legitimate website with injected code from a file sent by of its URLs.  The URL most often ends with a .js.  The injected code is highly-obfuscated, and I was unable to figure out where it came from on the legitimate site when I generated an infection in my lab.  The end result looked like the image below.

Shown above:  Fake browser update page seen after visiting a legitimate website.

The downloaded zip archive contained a JavaScript file with heavily obfuscated Javascript.  This happened when I used Firefox as my web browser.  If you use Google Chrome, the fake browser page sends an HTA file instead of a zip archive.  In my example, the fake Firefox update page sent a zip archive containing a file named Firefox.js for the malware downloader.

Shown above: The downloaded zip archive and extracted .js file.

Infection traffic

Infection traffic was typical of what I've seen before with this campaign.  The malware downloader is very picky.  It knows which machines I've infected before, so when I use a computer that I've infected once or twice before, it won't deliver the follow-up malware.  Also, this .js-based downloader (or HTA-based downloader if you had a fake Chrome update page) is extremely VM-aware.  It's rare for me to get a full infection chain of events.  In this case, I got the fake browser update page on one computer, then I switched to another computer to get Firefox.js to deliver the follow-up malware.

Shown above:  Gate URLs and a fake Firefox update page from the SocGholish campaign shown in a Fiddler capture.

Shown above:  Gate domain and fake Firefox update page from the SocGholish campaign from a pcap shown in Wireshark.

Shown above: Traffic from infecting a host with the Firefox.js file.

Shown above:  Data returned from the server contacted after running Firefox.js on my lab host.

This NetSupport RAT-based malware package was sent as a 10MB ASCII text file consisting of hexadecimal characters.  This is encoded data, and the file was saved to my lab host and decoded to a zip archive containing the malware package.  This ASCII data and decoded zip archive were deleted from my infected lab host by the time I performed post-infection forensics.

Post-infection forensics

The NetSupport RAT-based malware package was kept persistent through the Windows registry and stored in a folder under the infected user's AppData\Roaming directory.

Shown above:  NetSupport RAT-based malware package persistent on the infected windows host.

Shown above:  NetSupport RAT-based malware package stored under the infected user's AppData\Roaming directory.

Indicators from the infection

Gate activity leading to fake browser update page:

  • 130.0.234[.]134 port 443 - sodality.mandmsolicitors[.]com - URLs from gate domain (HTTPS)

Fake browser update page:

  • 188.120.239[.]154 port 443 - trace.mukandratourandtravels[.]com - initial URL sent as HTTPS
  • 188.120.239[.]154 port 80 - trace.mukandratourandtravels[.]com - follow-up URLs for fake browser update page
  • Note: The domain name used for these fake update pages frequently changes.

URLs caused by Firefox.js (malware downloader):

  • 130.0.233[.]178 port 80 - 2e2be1cd.auth.codingbit[.]co[.]in - POST /submit.aspx
  • Note: The first part of the domain name (with the hex characters) is different for each infection.

Traffic generated by NetSupport RAT-based malware package:

  • 81.17.21[.]98 port 443 - 81.17.21[.]98 - POST http://81.17.21[.]98/fakeurl.htm
  • 62.172.138[.]35 port 80 - geo.netsupportsoftware[.]com - GET /location/loca.asp (not inherently malicious)

SHA256 hash: 6b89a2c1650012d7953f04f39ef7ecd97341114480918602d041593a597442d7

  • File size: 32,231 bytes
  • File name: Firefox.Update.4ee488.zip
  • File description: Zip archive sent by fake browser update page
  • Note: File name is different for each download (file hash might be as well)

SHA256 hash: 69ea88be502bd00e87aef75e1f41da3e5e0bdb6946d18db5a4a52d919e2dc79b

  • File size: 90,690 bytes
  • File name: Firefox.js
  • File description: JavaScript-based malware downloader extracted from downloaded zip archive
  • Note: File hash might be different on each occasion

SHA256 hash: 49a568f8ac11173e3a0d76cff6bc1d4b9bdf2c35c6d8570177422f142dcfdbe3

  • File size: 105,848 bytes
  • File location: C:\Users\[username]\AppData\Roaming\XDk7Fyz6\presentationhost.exe
  • File description: NetSupport Manager RAT executable

Final words

This is a long-running campaign that continually evolves.  To get an idea how it has changed since last year, view my previous ISC diary I wrote about this campaign in February 2019.

Computers running Windows 10 with the latest updates and recommended security settings are not very vulnerable to this threat.  Default security settings for Chrome and Firefox usually block this activity.  However, the criminals behind this campaign keep updating their tactics as they attempt to evade detection, and these fake browser pages sometimes slip through.  If someone clicked through enough security warnings, they might very well infect a vulnerable Windows host.

The associated malware and a pcap of the traffic can be found here.


Brad Duncan
brad [at] malware-traffic-analysis.net

1 comment(s)


Funny you should mention this. We have the SRP GPO running at most of our clients.
This morning one client's report contained:
C:\Users\dcox\AppData\Local\Temp\*\*.exe {SRP rule that was violated}

Twice with a different Temp folder for the 2nd attempt.

My limited understanding is that GoogleUpdate.exe should only run from:
• %USERPROFILE%\AppData\Local\Google\Update
• 32-bit (x86) Windows editions: C:\Program Files\Google\Update\
• 64-bit (x64) Windows editions: C:\Program Files (x86)\Google\Update\

I promptly updated my Chrome and did not violate the rule here.
And it did not show up on any other clients' morning reports.

Diary Archives