{"id":13746,"date":"2026-06-18T05:01:52","date_gmt":"2026-06-18T12:01:52","guid":{"rendered":"https:\/\/www.infoblox.com\/blog\/?p=13746"},"modified":"2026-06-18T09:22:24","modified_gmt":"2026-06-18T16:22:24","slug":"hot-take-operation-endgame-vs-socgholish","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/threat-intelligence\/hot-take-operation-endgame-vs-socgholish\/","title":{"rendered":"Hot Take: Operation Endgame VS SocGholish"},"content":{"rendered":"

A multinational law enforcement action, part of Operation Endgame<\/a>, has disrupted SocGholish, a notorious malware framework known for fake updates that provides initial access to other cybercriminals, including EvilCorp. This week, law enforcement and private-industry partners have taken down 106 servers and domains and remediated 14.971 compromised WordPress websites. These websites fuel SocGholish\u2019s fire.<\/p>\n

<\/p>\n

Infoblox Threat Intel is proud to be a partner in Operation Endgame. We believe that government-industry partnerships are both necessary and effective in combating cybercrime. SocGholish is used to target the very networks that we seek to protect. Modern data breach attacks rarely begin with ransomware: they begin with access, and SocGholish has played a major part in initial access for nearly a decade. This week Operation Endgame has dealt a major blow to TA569 by disrupting their SocGholish infrastructure and abolishing major sources of victim traffic.<\/p>\n

The effective control of tens of thousands of websites is not just a number. We found that nearly 55% of our cloud customers were exposed to SocGholish in 2026, demonstrating the true potential impact of the threat on enterprises and institutions worldwide. Our customer base not only has our protective DNS but typically also uses other defenses in their security arsenal. As a result, although the exposure to SocGholish was high, only a small number of customers appear to have progressed through to the final stage of the attack.<\/p>\n

Even with layered defenses, it only takes a single compromised device in a network to enable a data breach. Many organizations do not have sufficient protection from SocGholish and the criminals within the SocGholish ecosystem have proven their skills for nearly a decade. This is why disruption efforts like those of Operation Endgame matter.<\/p>\n

In this blog, we will explain how SocGholish operates and detail our analysis of the threat based on visibility at our DNS resolvers.<\/p>\n

What is Operation Endgame?<\/h3>\n

Operation Endgame was first announced in 2024 as a coordinated international law-enforcement campaign aimed at dismantling the infrastructure that underpins cybercrime at scale. What makes it especially relevant for defenders is its focus on the earlier stages of the intrusion chain. Rather than only pursuing the actors who deploy ransomware or extort victims at the end of an intrusion, Endgame targets the services that facilitate those crimes: droppers, loaders, botnets, traffic distribution systems (TDSs), and access-enabling malware.<\/p>\n

Earlier “seasons” of Operation Endgame focused on known malware families such as IcedID, Smokeloader, Pikabot, Bumblebee, QakBot, DanaBot, TrickBot, and, most recently in November 2025, the Rhadamanthys infostealer, VenomRAT, and the Elysium botnet. Like SocGholish, these previous targets are part of the service economy that enabled major intrusions and data breaches.<\/p>\n

Crucially, much of Operation Endgame\u2019s success also rests on its deep collaboration with private industry. Cybersecurity firms including Proofpoint, CrowdStrike, Microsoft, Bitdefender, ESET, Shadowserver, Spamhaus, Spycloud, Have I Been Pwned, and with this latest iteration, Infoblox, have contributed threat intelligence, infrastructure analysis, and victim remediation support, making Operation Endgame a successful model for how public-private partnership can disrupt cybercrime at scale.<\/p>\n

Why Does it Matter?<\/h3>\n

SocGholish is one of the longest operating web-inject frameworks known. First observed in 2017 and publicly documented in 2018, it uses compromised websites to show fake browser update prompts to website visitors and trick them into downloading a malicious JScript payload.<\/p>\n

The threat actor operating the SocGholish framework is TA569, also tracked as Mustard Tempest, Gold Prelude, or UNC1543. TA569 operates as a so-called initial access broker, which means that their main objective is the compromise of devices connected to a company-managed network environment with the objective of obtaining elevated access to corporate networks. This access is then sold off or handed over to other actors who leverage it to deploy additional malware, including ransomware, and use the access for extortion or data exfiltration.<\/p>\n

SocGholish-related initial access has been tied to over half a dozen ransomware families including DoppelPaymer, WastedLoocker, Hades Ransomware, LockBit, RansomHub<\/a> and more. Additionally, since its earliest days, the SocGholish framework has been used by one of the most notorious Russian cybercrime conglomerates: EvilCorp. A June 2022 report by Mandiant<\/a> stated that UNC2165, their moniker for EvilCorp, almost exclusively obtained initial access from TA569\u2019s SocGholish. Action against SocGholish will impact EvilCorp as well as others.<\/p>\n

How Does the SocGholish Framework Work?<\/h3>\n

SocGholish is a multi-stage Javascript framework used to convert compromised websites into drive-by download malware distribution vectors. These sites are often powered by WordPress. While sites may be vulnerable to different attacks, many compromises are accomplished through leak credentials. Operation Endgame found 1.4M leaked website credentials that could be used by SocGholish and other actors to infect systems.<\/p>\n

The framework consists of four stages: traffic acquisition, traffic filtering, payload lures, and on-device implant execution. We will briefly describe each stage, focusing on the most important aspects from an Infoblox perspective.<\/p>\n

Stage 1: Traffic Acquisition<\/h4>\n

The first step is to acquire website traffic. TA569 compromises a very large number of websites themselves: within the research community, it\u2019s believed they could have controlled a million sites during their history. But they also accept traffic from affiliates. It\u2019s a classic commercial relationship: when a user visits the site, the affiliate typically fingerprints them and then passes potential victims to SocGholish through an embedded link. In return, the affiliate will be paid for these “leads.” We consider these initial links to be the tier one infrastructure of the attack framework.<\/p>\n

A typical tier one link seen during recent years would look like this (Figure 1):<\/p>\n

<subdomain.domain.tld\/<loooooongbase64string><\/p>\n

\"Figure<\/p>\n

Figure 1. An example of a tier one SocGholish link used to deliver potential victims for further processing<\/p>\n

However, when looking back further at the initial days of SocGholish, it would look like this (Figure 2):<\/p>\n

<subdomain.domain.tld\/<filename>.js?cid=<int>&v=<random alphanumeric string><\/p>\n

\"Figure<\/p>\n

Figure 2. An example of a historical tier one SocGholish link used to deliver potential victims for further processing (source Malwarebytes<\/a>)<\/p>\n

People familiar with TDSs might recognize this pattern. The parameter “cid” is commonly referred to as a “client id” or “campaign id” and is commonly used in campaigns to attribute incoming traffic to a specific traffic provider or advertising campaign in affiliate advertising.<\/p>\n

SocGholish is set up in the exact same way. Different traffic providers embed the tier one link into compromised pages. Once the traffic reaches the tier one infrastructure, SocGholish takes over, filters the traffic and presents each visitor with a tailored payload. It is largely believed that the long base64 string observed in the later years of this operation still contains similar information; however, there is now a layer of encryption added that prevents reading those parameters.<\/p>\n

Because of the affiliate nature of SocGholish, one of the hardest parts of tracking the threat over the years was not identifying the fake update lure itself. It was tracking the many actors and systems that fed traffic into it and understanding how those sources changed over time.<\/p>\n

Many affiliates have sold traffic to the SocGholish framework over the years, most notably TA2726, ParrotTDS, and more recently, a TDS that we and threat researcher Randy McEoin have dubbed JunkyTDS. Multiple actors have utilized the commercial Keitaro tracker<\/a>, zTDS<\/a> and similar TDS frameworks to filter traffic for redirection to SocGholish. When the visitor to the compromised site did not match the criteria for SocGholish, they were either shown the original website or redirected to other content from which the affiliate could profit. See Figure 3.<\/p>\n

\"Figure<\/p>\n

Figure 3. A simplified view of affiliates that drive potential victims to SocGholish.<\/p>\n

Stage 2: Traffic Filtering<\/h4>\n

After the infected website redirects to the SocGholish TDS, the attack typically proceeds to the second stage: a fingerprinting script. As is common with TDS actors or those working with web traffic for drive-by downloads, the goal is to ensure that malicious payloads are only delivered to genuine victims. To do so, they filter out bots, security researchers, and devices outside SocGholish’s target profile. The fingerprinting stage is an evasion mechanism that runs several checks in sequence. WordPress admins and anyone who has already executed the payload are excluded, so they don’t receive it again. Visitors on an automated browser are redirected to one type of payload. Visitors with an unusually small screen\u2014a sign of a mobile phone or certain sandbox environments\u2014are redirected to a second type of payload. These two payloads are used only for logging endpoints.<\/p>\n

Only users who meet all the criteria are shown a fake update message.<\/p>\n

Stage 3: Fake Update Prompts<\/h4>\n

The fake update template is presented to the website visitor from the same tier one infrastructure as the fingerprinting script. It is important to realize that for the entire process, the victim is never diverted from the infected page they wanted to visit initially. The fake update template gets loaded within the same page the visitor wanted to see: it forcefully deletes the original content and replaces it with the template. This makes the fake update request more believable, since the update seems to be rendered while opening a trusted website, rather than through a shady redirect flow.<\/p>\n

To get the best coverage and make the lure more convincing, SocGholish can present different templates fitting the style and layout of all major browsers. An example of such a template and the downloaded payload file can be seen in Figure 4.<\/p>\n

\"Figure<\/p>\n

Figure 4. SocGholish Fakeupdate template triggered in Firefox on June 11, 2026<\/p>\n

Once the victim hits the “Download” button, the fake update template reaches out to the tier one server again, downloading a premade payload via an iframe injection. This way, the payload is not downloaded from an external server but from the compromised domain the user intended to visit.<\/p>\n

Stage 4: On-Device Stager<\/h4>\n

In recent years, SocGholish has used the fake update flow to trick victims into executing a deceptively simple, custom-made JScript file on their endpoint. Jscript is Windows own “interpretation” of ECMA Script, which is the same foundation JavaScript was built on.<\/p>\n

While most other actors are currently relying on large, heavily obfuscated scripts that can often be several hundred if not thousands of lines of code, a reformatted SocGholish stager only consists of about 6 lines of code, shown in Figure 5.<\/p>\n

\"Figure<\/p>\n

Figure 5. Deobfuscated SocGholish JScript payload downloaded via the SocGholish fake update template<\/p>\n

In short, the code creates an ActiveXObject, sends a base64 string to a hardcoded command-and-control (C2), then expects a response that will be directly executed as a new function.<\/p>\n

The hardcoded domains within the SocGholish stager can be understood as tier two hostnames. Unlike the tier one hostnames that are operated over a long period of time, the tier two hostnames change several times per week. This presents a unique challenge to defenders because the actor uses a technique called domain shadowing, which we will discuss in the following section.<\/p>\n

After execution of the JScript stager, the next stages depend on the victim device and how valuable it appears to the operators. That assessment is made through follow-up fingerprinting scripts or loaders delivered by the stager. In this context, domain-joined systems, that is, ones connected to a central directory service, are especially valuable because they are connected to a corporate identity and management environment, making them far more useful as an entry point into a wider enterprise network. Since SocGholish\u2019s primary purpose is to obtain and sell initial access to corporate environments, those systems are more likely to receive follow-on tooling intended to support deeper intrusion activity, data theft, or ransomware deployment. Lower-value systems, by contrast, such as devices that are not joined to a corporate domain, are commonly monetized through off-the-shelf infostealer malware.<\/p>\n

Domain Shadowing<\/h3>\n

One thing that makes SocGholish especially interesting is its use of domain shadowing for both the tier one and tier two hostnames. Domain shadowing is a technique in which threat actors gain access to the authoritative DNS provider or registrar account for a legitimate domain and then use that access to create rogue subdomains beneath it for nefarious purposes.<\/p>\n

For attackers, this offers several clear advantages. The malicious hostnames inherit the age, reputation, and apparent legitimacy of the parent domain, which can make them look benign at first glance and reduce the likelihood of immediate blocking. A defender investigating an alert may see a hostname under a long-established business domain and initially assume it is legitimate, even though the subdomain itself was created solely for malicious activity. In addition, the creation of new subdomains is often monitored less closely than the registration of entirely new domains, making shadowed infrastructure harder for defenders and threat intelligence products to identify early.<\/p>\n

In the SocGholish ecosystem, this technique fits naturally into a broader operating model built around traffic redirection, layered delivery, and rapid infrastructure churn. To make matters even harder for defenders, SocGholish rotates the shadowed tier two domains at high frequency, ranging from daily rotation to at least once per week. That rapid turnover amplifies all of the technique\u2019s existing advantages: it shortens the time defenders have to identify and investigate rogue subdomains, reduces the usefulness of static blocklists, and allows the actor to refresh trusted-looking C2 infrastructure before many defenders can confidently classify and respond to it.<\/p>\n

While the classification of who provided the traffic is difficult, defenders have one advantage when it comes to blocking attacks by SocGholish. It boils down to the fact that a multi-stage architecture also can be blocked at multiple stages. We leverage several ways to achieve that, which we showcase in the graph in Figure 6 below.<\/p>\n

\"Figure<\/p>\n

Figure 6. A view of how blocking resolution of domains impacts the SocGholish attack chain<\/p>\n

In practice, defenders can disrupt SocGholish at several points along the attack chain. Infoblox Threat Intel attempts to track and detect:<\/p>\n