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.
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”.
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:\ProgramData\rad6598E.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.
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
- Prevent execution of .js files
- 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:\ProgramData\jdg.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