Introduction 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.
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.
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.
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.
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.
Indicators from the infection Gate activity leading to fake browser update page:
Fake browser update page:
URLs caused by Firefox.js (malware downloader):
Traffic generated by NetSupport RAT-based malware package:
SHA256 hash: 6b89a2c1650012d7953f04f39ef7ecd97341114480918602d041593a597442d7
SHA256 hash: 69ea88be502bd00e87aef75e1f41da3e5e0bdb6946d18db5a4a52d919e2dc79b
SHA256 hash: 49a568f8ac11173e3a0d76cff6bc1d4b9bdf2c35c6d8570177422f142dcfdbe3
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, along with a pcap and Fiddler capture of the traffic (.saz file) can be found here. --- Brad Duncan |
Brad 435 Posts ISC Handler Feb 5th 2020 |
Thread locked Subscribe |
Feb 5th 2020 2 years ago |
Funny you should mention this. We have the SRP GPO running at most of our clients.
This morning one client's report contained: GoogleUpdate.exe C:\Users\dcox\AppData\Local\Temp\GUMBD18.tmp\ 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. |
Anonymous |
Quote |
Feb 7th 2020 2 years ago |
Sign Up for Free or Log In to start participating in the conversation!