Operation Endgame Cleaned 14,971 WordPress Sites. SocGholish Will Refill Them.

The numbers from the June 18 takedown read like a finish line. Law enforcement from four countries cleaned SocGholish malware off 14,971 compromised WordPress sites and pulled 106 servers and 101 domains offline in a coordinated strike under Operation Endgame. That is a real dent in a long-running criminal service. It is also a rounding error against the size of the problem.

One of the partners that supported the cleanup, the Shadowserver Foundation, counted 1,441,695 compromised WordPress instances that SocGholish had available to it between May 2023 and May 2026, spread across more than 1.1 million domains and 271,000 unique IP addresses in 187 countries. Roughly fifteen thousand sites scrubbed is the visible edge of a campaign that has been recruiting websites by the million for years. The infrastructure took a hit on June 18. The business that built it kept its customer list.

Who this hits, and who can close the tab

SocGholish, tracked since 2017 and also known as FakeUpdates, is an initial-access operation run by a group most vendors call TA569 (and variously Gold Prelude, Mustard Tempest, or UNC1543). It does not care what your company does for a living. It cares that you run a website a stranger might visit, or that your staff browse the web on machines that touch your network. Those are two different exposures, and most organizations own at least one of them.

If you run a WordPress, Joomla, or Drupal site - the marketing site, the customer portal, the old microsite nobody has logged into since 2022 - you are a candidate to become the compromised host that serves the lure to someone else's employees. If your people browse the web on Windows endpoints, you are a candidate to be the victim who runs the fake update. The reader who can safely stop here is the all-Mac shop with no public CMS: the delivered payload is overwhelmingly Windows Script Host, and the lure is seeded almost entirely through CMS platforms. Everyone else holds at least one side of this, and plenty of small businesses hold both.

How a fake update becomes a ransomware foothold

The mechanism is old, cheap, and effective, which is exactly why it has outlived flashier malware. It runs in two halves: get onto a legitimate website, then convert that website's visitors into infected machines.

The first half is unglamorous intrusion work. Shadowserver attributes the compromises to password spraying and credential reuse against site logins, exploitation of vulnerable CMS plugins and themes, credential theft by other malware, and a quieter technique called domain shadowing - where the attacker gets into a domain's DNS or registrar panel and creates malicious subdomains under an otherwise reputable apex domain. Once inside, the operator injects a small block of JavaScript into the site.

The second half is social engineering delivered by code. When a visitor loads the page, the injected script fingerprints them - geography, whether they are a first-time visitor, browser and operating system - and only the ones who match the operator's filter get the payload. Those visitors watch the page get overwritten with a clean, convincing prompt that says their browser needs an update. Security researchers who have mapped TA569's role as an access broker describe the elegance of the trick: it borrows the trust of a site the visitor chose to go to. Download and run the file, and the machine is enrolled.

What lands is a JavaScript file - names like Update.js or homoglyph-disguised archives such as Сhrome.Updаte.zip that mix Cyrillic and Latin letters to dodge a quick glance. From there the operator runs reconnaissance, establishes command and control, and then hands the foothold off. SocGholish has fed next-stage malware to Evil Corp, LockBit, and RansomHub, among others. The group breaks in; somebody else brings the ransomware. That division of labor is the whole point of an access broker, and it is why this one access broker shows up behind so many unrelated incidents.

The myth that a takedown ends a botnet like this

The comfortable reading of June 18 is that a major ransomware feeder got switched off. The dates and the structure argue against it. This was the latest phase of Operation Endgame, the same iterative effort that has knocked over droppers and loaders before, and the organizers were explicit that the action was about depriving the operators of access rather than declaring the threat finished. Maikel Rollman of the Netherlands National High Tech Crime Unit framed it plainly: the goal was to take away the criminals' access to infected systems, not to claim the model was dead.

Two things make a SocGholish-style operation resilient. First, the supply of vulnerable websites is effectively unlimited; a few thousand cleaned sites are replaced by the next round of credential-sprayed logins and unpatched plugins, and a site that is disinfected but not actually secured gets reinfected. Second, an access broker is a business relationship, not a single server. Seizing 106 machines disrupts delivery for a while; it does not retire the intrusion playbook, the affiliate connections, or the operators themselves. The honest posture is to treat this as a window of reduced volume, useful for catching up on hygiene, rather than as a reason to relax the controls that actually stop the technique.

Detect the execution chain on your endpoints

The good news for defenders is that the delivered payload behaves in a way normal software does not. The single most reliable signal is a web browser spawning the Windows Script Host. Real applications rarely have chrome.exe or msedge.exe launch wscript.exe to run a downloaded .js file that then reaches out to the internet. Red Canary's threat detection research puts this browser-to-script-host chain at the center of catching SocGholish, and it maps cleanly to a hunt you can run today against endpoint telemetry.

Flag browser-spawned Windows Script Host

// Microsoft Defender Advanced Hunting (KQL).
// A browser launching wscript/cscript on a downloaded script is the SocGholish tell.
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe","brave.exe")
| where FileName in~ ("wscript.exe","cscript.exe")
| where ProcessCommandLine has_any (".js",".jse",".zip")
| project Timestamp, DeviceName, InitiatingProcessFileName,
          FileName, ProcessCommandLine, AccountName
| order by Timestamp desc

The follow-on behavior is just as detectable. SocGholish reconnaissance leans on built-in Windows tooling - whoami for context and nltest to map domain trusts before deciding whether the host is worth selling to a ransomware affiliate. Domain trust discovery from a workstation is a high-value, low-noise signal in most small environments.

Catch the domain-trust reconnaissance

DeviceProcessEvents
| where FileName =~ "nltest.exe"
| where ProcessCommandLine has_any ("/domain_trusts","/all_trusts")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

These map to MITRE ATT&CK techniques T1059.007 (JavaScript via Windows Script Host), T1033 and T1482 (system and domain-trust discovery), and T1583 (command and control). If you have no endpoint detection product, the same chain is visible in Sysmon Event ID 1 process-create logs with a parent-process filter on the browser.

Take away the double-click

The strongest single mitigation is to stop Windows from executing script files on a double-click at all. Change the default handler for .js and .jse so they open in an editor instead of running, and push it across the fleet by Group Policy.

:: Push via GPO (Group Policy Preferences > Registry, or a startup script).
:: After this, double-clicking a .js drops the user into Notepad, not execution.
ftype JSFile="%SystemRoot%\System32\notepad.exe" "%1"
ftype JSEFile="%SystemRoot%\System32\notepad.exe" "%1"

That one change breaks the SocGholish delivery model for the common case, and almost no legitimate business workflow depends on a user double-clicking a loose .js file to run it.

If you run the CMS, assume you are a candidate host

The other side of this is your own websites. Shadowserver's remediation guidance for compromised site owners is short and worth doing whether or not you were on the cleanup list: change the site login credentials, turn on multi-factor authentication for every administrator, delete any administrator account you did not create, and patch the CMS core along with every plugin and theme. Because domain shadowing is in the playbook, also review your DNS records for subdomains you do not recognize.

Audit a WordPress install for the SocGholish pattern

# Run on the WordPress host (or over SSH).
# 1) List admin accounts and flag any you did not create.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 2) Search stored content/options for injected external script tags.
wp db query "SELECT option_id, option_name FROM wp_options \
  WHERE option_value LIKE '%<script%';"

# 3) Surface theme/plugin files changed in the last 30 days - a common
#    injection point for the loader JavaScript.
find wp-content/themes wp-content/plugins -type f \( -name '*.php' -o -name '*.js' \) \
  -mtime -30 -printf '%Tc  %p\n' | sort

If you find an injected script or a rogue admin, treat the cleanup as the start, not the end. Rotate every credential associated with the site and its hosting account, rebuild from a known-good backup where you can rather than hand-editing files, and keep watching, because a site that gets reinfected within days is the norm for this campaign, not the exception. The infected WordPress sites in this operation skewed heavily toward the United States, then Germany, France, India, and Brazil, which is to say they tracked where small businesses run unattended CMS installs.

Hunt the dwell window before you trust the cleanup

If a machine on your network ran a fake browser update at any point this year, the takedown did nothing for you - the foothold predates June 18, and the access may already have been sold. Pull your endpoint telemetry for the browser-to-script-host chain across the last several months, check any hit for the nltest and whoami recon that follows, and rotate the credentials reachable from any host that lit up. On the web side, audit your own CMS for rogue admins and injected script, and harden the logins so a disinfected site does not simply get re-recruited. The point of the exercise is to learn which group you are in - untouched, or quietly brokered - rather than to find out when a ransomware affiliate decides your foothold is worth using. If your team does not have the hours or the runbook to work that hunt across endpoints and websites at once, that is the kind of incident-response readiness we build and test with small and mid-size organizations before an attacker forces the question.