Read Time:6 Minute, 32 Second
Executive summary:
SocGholish, also known as FakeUpdate, is a JavaScript framework leveraged in social engineering drive by compromises that has been a thorn in cybersecurity professionals’ and organizations’ sides for at least 5 years now. Upon visiting a compromised website, users are redirected to a page for a browser update and a zip archive file containing a malicious JavaScript file is downloaded and unfortunately often opened and executed by the fooled end user.
An AT&T Managed Extended Detection and Response (MXDR) client with Managed Endpoint Security (MES) powered by SentinelOne (S1) received an alert regarding the detection and mitigation of one of these JavaScript files. The MXDR Threat Hunter assigned to this client walked them through the activity resulting from the execution of the malicious file, as well as provide additional guidance on containment and remediation of the host involved in the incident.
Investigation
Upon detection of the follow up activity of the malicious file executed by the end user, S1 created an Incident within the S1 portal. This in turn creates an Alarm within the USM Anywhere platform, where the MXDR SOC team works, reviews, and creates Investigations for client notification as necessary. Since this activity was observed all within S1, this analysis will be out of there.
The best way to start looking into a S1 event is to go to the Storyline of the Incident within Deep Visibility.
Once we have all the events related to the Incident, we can also create a new Deep Visibility search for all activity related to the affected host from about an hour before right up to the first event for the incident. This will let us try to see what happened on the host that lead to the execution of the malicious JavaScript file.
Reviewing the events from both the overall logs on the host and the events related to the Storyline, we can build out a rough timeline of events. Note there are close to 15k events on the host in the timeframe and 448 events in total in the Storyline; I’m just going over the interesting findings for expediency sake.
12:07:08 The user is surfing on Chrome and using Google search to look up electricity construction related companies; we see two sites being visited, with both sites being powered by WordPress. The SocGholish campaign works by injecting malicious code into vulnerable WordPress websites. While I was unable to find the injected code within the potentially compromised sites, I see that one of the banners on the page contains spam messages; while there are no links or anything specifically malicious with this, it lets us know that this site is unsafe to a degree.
12:10:46 The user was redirected to a clean[.]godmessagedme[.]com for the initial download. It likely would have looked like this:
We can assume the URI for the request looks like the /report as seen in VirusTotal and described in open-source intelligence (OSI). Note that the subdomain “clean” has a different resolution than the root domain; this is domain shadowing performed by the attackers by creating a new A-record within the DNS settings of the legitimate domain:
12:12:19 Chrome creates on disk: “C:Users[redacted]DownloadsСhrome.Updаte.zip”.
12:13:11 User has opened the zip file and is executing the JavaScript file inside: “C:Users[redacted]AppDataLocalTempTemp1_Сhrome.Updаte.zipAutoUpdater.js”. The first thing that triggers is a POST request to hxxps://2639[.]roles[.]thepowerofgodswhisper[.]com/updateResource – this is the first check in.
12:13:15 The script follows up commands to pull system information, such as the Computer Name, Username, User Domain, Computer Manufacturer, BIOS information, Security Center status and Antispyware Product, Network Adapter information, MAC address, and OS version. There is a POST request again, but this is to pull down additional JavaScript that it will evaluate and execute:
The information is collected to build the URI:
12:13:20 POST request goes through to hxxps://2639[.]roles[.]thepowerofgodswhisper[.]com/updateResource.
A new URL is now leveraged: hxxps://2639[.]roles[.]thepowerofgodswhisper[.]com/settingsCheck
12:13:23 Additional commands are now flying through:
12:13:24 We see whoami as one of the commands leveraged. Whoami.exe is run on the host and the information is written to “radDCADF.tmp” in the Temp folder for exfiltration.
12:31:36 Commands for nltest /domain_trusts to tmp file:
12:34:19 nltest /dclist:[redacted] observed:
12:37:36 Command to pull domain information into the path tmp file and POSTed up observed:
12:48:39 Commands to create “rad0A08F.tmp”, which is a data stream on the C2 server. The file is then renamed to 81654ee8.js and executed with wscript.exe:
The activity that follows is a mix of this new script and the previous script.
12:49:11 Creation of a file from a data stream to “C:ProgramDatarad6598E.tmp” then rename “rad6598E.tmp” to “jdg.exe”.
Activity by the attackers ends there as S1 has prevented additional actions related to this Storyline and pivoting across the environment with the executable name and hash yields no additional results. The client has since removed the host from the network and rebuilt it.
Response
Customer interaction
The MXDR SOC created an Investigation within USM Anywhere and notified the customer about this incident. The Threat Hunter assigned to the customer then followed up to provide them with additional context, findings, and recommendations for containment and remediation.
The host in question was removed from the network and rebuilt, and the user’s credentials were reset. Domains and IP addresses related to the compromise were provided to the customer and were promptly blocked on the proxy and firewall. While unlikely we will see the same file hashes again, the hashes of all files related to the incident were blocklisted within S1.
Protecting against SocGholish
Death, taxes, and SocGholish are certainties in life but there are steps organizations can take to prevent infections. Of course, partnering with the AT&T MXDR service, especially with the MES would be a great way to protect your organization and users, but here are steps to consider to not only prevent SocGholish but to reduce your overall attack surface:
Educate employees on the following sorts of social engineering attacks:
Fake browser or operating system updates
Fake operating system errors or messages telling them to call in for assistance
Phishing and vishing attacks where the employee is asked to download tools or software updates
Turn off “Hide Known File Extension” across the environment via Group Policy
The JavaScript file inside the zip archive has a higher chance of being clicked by a user because they cannot see the file is a .js file, versus an executable. Of course, this is a moot point if the attacker file is an executable to start, but this setting across the user base can help more savvy users recognize potential double extension trickery or icon manipulation.
Prevent execution of .js files
Removing the file association of JavaScript files, as well as other common attack file formats such as .iso, .cab, .wsf, and others can prevent users from just executing files that are uncommonly used.
Implement rules within EDR platform or application blocking software
Detection of wscript.exe activity where the command line contains .zip and .js
Detection of nltrust.exe and whoami.exe from cmd.exe where the parent process is wscript.exe
Detection of executables running out of the ProgramData folder directly, e.g. C:ProgramDatajdg.exe
Execution of executables out of other uncommon folders as well, such as Public, Music, Pictures, etc.
Detection of POST requests for URI: /updateResource and /settingsCheck
Detection of when URIs contain information such as hostnames matching your organization’s format, MAC addresses, and other information related to your domain, such as domain controller hostnames
