SocGholish Malware: Script Injections, Domain Shadowing, IPs & Obfuscation Techniques

SocGholish and NDSW NDSX malware, FakeUpdates, SilverFish (SolarWind) and ransomware

In June 2022, we shared information about the ongoing NDSW/NDSX malware campaign which has been one of the most common website infections detected and cleaned by our remediation team in the last few years.

This NDSW/NDSX malware — also referred to as FakeUpdates or SocGholish by other research groups — is responsible for redirecting site visitors to malicious pages designed to trick victims into loading and installing fake browser updates.

We’re now seven months into the year and our team has already detected this malware on over 25,000 sites since the beginning of January, 2022 — with another 61,000 infected websites detected last year alone.

In today’s post, we’ll be outlining the injections and URLs used in the website malware portion of the SocGholish attack outside of the NDSW/NDSX campaign — the components of the infection that are actually observable on compromised sites.

We’ll also reveal how attackers employ domain shadowing to conceal malicious activity, document some of the more recent domains and IPs used in these attacks, and describe the evolution of the malware injection.


What is SocGholish?

SocGholish is a JavaScript malware framework that has been in use since at least 2017. It is distributed through a number of malicious sites claiming to provide critical browser updates. In reality, these sites are designed to trick victims into downloading and installing malware — usually in the form of .zip or .js files (you can find samples on MalwareBazaar).

Fake Update landingpage courtesy of MalwareBytes
Fake Update site screenshot courtesy of MalwareBytes

Once an end user has manually decompressed and executed the archive file by double-clicking the contents, various malware which may include remote access trojans (RATs), information stealers, and Cobalt Strike beacons are deployed. All this malware is just an intermediary step for targeted ransomware attacks against corporations and organizations, resulting in major disruptions of business operations and significant financial losses.

There is ample evidence that SocGholish and its infrastructure have close ties to prominent attacks and criminal groups.

For example, PRODAFT attributed it to being used in the infamous SolarWinds attack and its connection to EvilCorp, a ransomware organization. And in Microsoft’s recent research “Ransomware-as-a-service: Understanding the cybercrime gig economy and how to protect yourself ” SocGholish was also attributed as a loader for other malware campaigns connected with EvilCorp and various other ransomware.

Analysis of recent SocGolish injections

As a preface, we recommend referring to this twitter thread by Andrew Northern if you want to understand the entirety of the SocGholish attack. His thread clearly outlines the different stages and infrastructure involved. We’ll be describing stages 1 and 2 found in his observations; injections and URLs.

For researchers looking for immediate examples, you can find infected websites using this query.

NDSW is the most prominent malware campaign redirecting visitors to fake update sites, but it’s not the only one. Other similar malware campaigns are also using different JavaScript injections to serve SocGholish’s fake updates from the same infrastructure. We’ve been tracking multiple waves of these campaigns since 2017.

Our Sucuri SiteCheck scanner currently detects non-NDSW variations of SocGholish scripts on 500+ sites every week.

SocGholish detection in Sucuri SiteCheck
A SocGholish detection seen in Sucuri SiteCheck

Here is a screenshot of the most recent type of injection we’ve found on compromised websites. It can be found located either right before the closing </head> tag or at the top or bottom of random legitimate .js files.

Typical SocGholish injection seen during August 2022
Typical SocGholish injection seen during August 2022

The script is pretty simple. After deobfuscation, it looks like this:

Deobfuscated SocGholish injection

As you can see, this attack is only interested in a specific segment of user agents: those on Windows computers coming from third party sites (search engines) for the first time.

If the visitor matches this criteria, a script (stage 2) is loaded. In this particular sample seen above, it originates from hxxps://natural.cpawalmyrivera[.]com/report?r=dj0xYTAyMDFiNTJkN2NhOTk5NzE1MyZjaWQ9MjY4, however these URLs have been changing quite often lately.

This type of injection is what we refer to as a vanilla SocGholish injection.

Comparison between NDSW/NDSX and vanilla SocGholish scripts

On a basic level, a vanilla SocGholish script is the same as the one that the NDSW/NDSX campaign serves on its third layer (NDSX script from a TDS server) — just without the var ndsx = true; statement found in the beginning of the code. The ndsw variable is also not referenced anywhere in vanilla SocGholish scripts.

Additionally, it appears that the NDSW/NDSX campaign creates a custom wrapper around SocGholish scripts that dynamically serves them through a PHP proxy found on the same site as the injected ndsw JavaScript.

This wrapper definitely adds a bit of complexity to the infection process — attackers are required to customize the injection for each site, upload different types of malware (JS and PHP), and maintain a proxy. On the other hand, this approach provides obvious benefits over the vanilla versions of these SocGholish injections — the NDSW/NDSX campaign doesn’t need to reinfect websites every time the SocGholish stage 2 URL changes (which happens pretty often lately). Instead, all the attacker needs to do is update the script on their own server and it will be automatically served via their proxy without any direct changes to the infected sites.

Interesting side note:

Website malware is usually poorly detected by conventional antivirus solutions, which focus more on the payloads when they actually reach the protected computer. However, sometimes antiviruses also warn web surfers when they detect certain JavaScript injections and block browsers from executing them.

In the case of these SocGholish injections, antivirus detections are not consistent. For example, Microsoft Defender detected a few variations (~20%) of NDSW injections as Trojan:JS/Agent.AG!MSR but didn’t detect any of our vanilla SocGholish injection samples.

SocGholish platform

One possible explanation for the existence of different malware campaigns leveraging the same SocGholish script is that SocGholish is actually a platform (scripts, servers) managed by one criminal group.

If this is the case, the SocGholish platform might provide scripts to affiliated third-party groups who drive traffic to fake update sites in exchange for share in the revenue. It would be up to third parties on how they drive traffic. For example — malvertising, black hat SEO, or injecting malware into legitimate websites.

Some hackers that use the website malware approach directly inject the scripts provided by SocGholish operators, while others (like NDSW) use an elaborate scheme with multiple layers and PHP proxies.


The SocGholish infrastructure most likely belongs to a highly sophisticated group analyzed by PRODRAFT in 2020-2021 whom they refer to as SilverFish.

In their report, we can find screenshots of a C&C interface featuring SocGholish shadowed domains used in TDS web panel. This C&C server provides attackers with ready-to-use JavaScript and PHP code for injection into compromised sites:

Screenshot of the TDS panel analysis from the PRODAFT SilverFish report
Screenshot of the TDS panel analysis from the PRODAFT SilverFish report

CID analysis

Having analyzed the numerous SocGholish URLs loaded by injected scripts from 2017 to present, we can see that they all contain a cid parameter that likely helps SocGholish operators distinguish which third-party or campaign sent them a visitor.

Originally, these cid’s were passed in clear view to s_code.js scripts. However, newer versions of SocGholish’s URLs leverage the more sophisticated “report?r” URLs which require the r parameter to be base64 decoded in order to retrieve the cid.

SocGholish URLs with CID parameters

Below are a number of examples for SocGholish URLs containing cid parameters. The first four items are URLs that were leveraged by this malware campaign between 2017-2018.

This list is not exhaustive.



In these cases, cid may be interpreted as a “campaign id” rather than “client id”. And several cid’s may belong to the same third-party. For example, back in 2018, MalwareBytes associated different cid’s with different CMS’ targeted by FakeUpdates campaigns.

Furthermore, each domain can be used with multiple different cid’s — and most cid’s can be observed on multiple domains.

One interesting observation is that all cids found in these URLs begin with 200. In fact, we haven’t seen any cid’s lower than 205 with the top of the range extending only as far as 269 thus far (according to our data).

It’s also worth noting that NDSW malware has been using cid=250 and cid=255 for quite a long time, while SocGholish scripts loaded via the soendorg[.]top/jsquery.js injection always contain cid=269.

Domain shadowing for SocGholish

Throughout the years, SocGholish has employed domain shadowing in combination with domains created specifically for their campaign.

Domain shadowing is a trick that hackers use to get a domain name with a good reputation for their servers for free. To accomplish this, attackers leverage compromised domain registrars or DNS provider accounts and add an additional CName or A-record for a randomly-named subdomain, then they point it to their own server.

This sort of malicious activity is very hard to notice if you don’t regularly inspect your DNS records — and many people don’t, as it’s usually a “set it and forget it” scenario.

For example, many SocGholish scripts currently use the baget.godmessaged[.]me host. is a legitimate site hosted on a server with IP However, the baget.godmessaged[.]me subdomain is hosted on a completely different server with IP To accomplish this, hackers created an additional A-record in the DNS settings of the domain.

DiG report for baget.godmessaged[.]meF
DiG report for baget.godmessaged[.]meF
Here are a few more examples of shadowed domains (not exhaustive). The first three items were leveraged by this malware campaign between 2017-2018.


We have also identified some domains that appear to be created specifically for SocGholish.


AWS Cloud URLs instead of domain shadowing

An exception to this pattern of using domain shadowing has recently emerged, however.

Instead of attackers using shadowed domains or their own domains, a small segment of injected scripts use this AWS cloud URL: hxxps://d2j09jsarr75l2.cloudfront[.]net/report?r=dj0xYTAyMDFiNTJkN2NhOTk5NzE1MyZjaWQ9MjY4

At this point, it’s not clear why attackers temporarily shifted to AWS URLs.

Latest SocGholish Domains and IPs

Initially, SocGholish operators weren’t changing their domains very often. But lately, we’ve see attackers introducing new domains on a weekly basis.

Here are some of the domain names observed in SocGholish scripts found on infected sites from the past month alone.


Along with a list of recent IP addresses for SocGholish hosts (stage 2):

Evolution of obfuscation techniques used in SocGholish scripts

During the last 5 years, SocGholish’s JavaScript injection hasn’t changed much — although we have seen distinct waves using different obfuscation techniques to hide the tell tale strings.

First known versions

Here is an example of an injection used around 2017 – 2018.

Typical SocGholish injection in 2017-2018
Typical SocGholish injection in 2017-2018

In this screenshot, you can see a bunch of obfuscated strings in green that look like gibberish. The decoding algorithm is actually pretty simple — although it’s probably the most sophisticated when compared to newer variations.

To recover the contents, you need to take every second character of the obfuscated string and then reverse the result.

For example: if we take the “ss;w;o{d;nxi(W(” string and remove all odd numbered characters we’ll get “swodniW”. After reversing it, we’ll get “Windows” — this malware is interested in users on Windows computers and Android devices. (For fun, you can try to decode “5d;ijo(rqd,nrA(“ yourself).

The decoded URL of the SocGholish script that this particular sample loaded was: hxxps://track.amishbrand[.]com/s_code.js?cid=205&v=c40bfeff70a8e1abc00f

And furthermore, this particular variation of injection was used by many massive website infection campaigns, including the attacks following the infamous Drupalgeddon 2.


Moving ahead to 2021, the most common injection variation looked like this:

Typical SocGholish injection with Base64 encoding
Typical SocGholish injection with Base64 encoding

The only major difference from variants seen in 2018 is the string encoding algorithm. In this case, it’s simply Base64.

For example: “V2luZG93cw==” and “QW5kcm9pZA==” can be decoded to “Windows” and “Android” respectively.

The decoded SocGholish script URL is hxxps://flowers.netplusplans[.]com/report?r=dj1lNTMyNTM4ZWM4Y2RiODExNmY0OCZjaWQ9MjU5

And the decoded “r” URL parameter is “v=e532538ec8cdb8116f48&cid=259”.

This SocGholish script variant can still be found on over 700 websites by querying PublicWWW.

Double Base64

In 2022, however, SocGholish introduced double Base64 encoding of their strings. Here’s an example for this variant:

SocGholish injection with double base64 encoded strings
SocGholish injection with double base64 encoded strings

Decoding the target “Windows” string requires an additional step:

“VjJsdVpHOTNjdz09” ➔ “V2luZG93cw==” ➔ “Windows

It’s interesting to note that in this variation, they no longer check for Android user agents, indicating that target objectives have become solely Windows users.

The decoded URL in this sample is hxxps://hunter.libertylawaz[.]com/report?r=dj03MDgyZTc5ZmNhN2EwY2M2YjA3NCZjaWQ9MjYz. The decoded “r” parameter is “v=7082e79fca7a0cc6b074&cid=263

PublicWWW currently shows this variation of the script on over 560 sites.

Skipping Odd-Numbered Characters

This summer, the obfuscation technique changed yet again.

Now it resembles the original obfuscation seen 4-5 years ago, just a bit more simple. You need to remove every odd-numbered character from encoded strings without having to reverse them afterwards.

Typical SocGholish injection in August 2022
Typical SocGholish injection in August 2022

In this sample found in August 2022, the word “Windows” is represented as ‘yWsihnpdjokwxse’.

The SocGholish script URL is hxxps://amplifier.myjesusloves[.]me/report?r=dj0xYTAyMDFiNTJkN2NhOTk5NzE1MyZjaWQ9MjY4 and the decoded “r” parameter is “v=1a0201b52d7ca9997153&cid=268

While this obfuscation is less complex than the old 2018 version that included string reversal, it still has more benefits for the SocGholish operators than the previous base64 encodings. Base64-encoded strings never change and, as demonstrated above with PublicWWW queries, it’s easy to detect them.

This new obfuscation approach gives SocGholish operators more control over the obfuscated strings. Every time they update the script to serve a new URL, they also rename all variables and randomly change the filler characters in odd-numbered positions.

For example, here are some variations of the encoded “Windows” string that can currently be found in SocGholish scripts:


Other SocGholish variations

There are numerous other types of injections that eventually load SocGholish scripts, but I won’t be covering them today in this article. These variants can range from ultra wide-spread NDSW/DNSX infections to less prominent campaigns like the ones found injecting soendorg[.]top/jsquery.js scripts to serve the SocGholish payload.

The importance of securing your website against SocGholish

These SocGholish infections remind us about the responsibility website owners have to maintain a clean environment along with the numerous dangers of website malware.

Just a small piece of injected JavaScript code — which might be considered a mere nuisance for some webmasters — can lead to major business and operation disruptions if a person with access to corporate networks visits an infected site and activates a download. Regular website visitors are also at risk, as SocGholish is known to install malware that steals credentials from their online banks, cryptocurrency wallets, and social networks.

Users of our website monitoring services will be able to detect if their website has been infected with NDSW or SocGholish malware — and our alerting options will ensure timely response to any infection. However, since there are multiple active campaigns that use a wide range of approaches to compromise and infect websites, I can’t provide exact instructions on how to clean or secure your website against a SocGholish infection — but I can offer general advice.

The most viable approach for webmasters is to decrease the attack surface at every possible opportunity. That includes fully updating trusted software used in the environment, uninstalling unused or deprecated components and plugins, employing strong passwords, leveraging the principle of least privilege, and decluttering your servers. Equally as important is monitoring your websites for malware and unwanted changes. Clean, fresh backups of your website will help you restore your site even after the most complex hacks.

Webmasters can refer to our website security guide on best practices to harden and protect a website against infection. And as always, if you believe your site has been compromised and you need a hand, we’re always happy to help.


Get help removing malware from your website

You May Also Like