There is a Steam profile somewhere with comments that look like ordinary gamer chatter. Maybe a few ASCII art drawings. A handful of random characters. Nothing that would catch a moderator's eye. Inside those comments, encoded in invisible Unicode characters that humans cannot see but a script can read, is a URL. That URL points to a malicious server. And every time one of approximately 2,000 compromised WordPress websites loads a page, it quietly fetches that comment, decodes the hidden URL, and executes whatever the attackers want.
GoDaddy security researchers documented this campaign in early June 2026, after first detecting it in July 2025. It has been running quietly for almost a year. The technique is one of the more creative pieces of malware infrastructure to surface recently. By hiding command-and-control (C2) instructions inside legitimate Steam Community profile comments, the attackers have built a system that is nearly invisible to traditional security monitoring. There is no malicious server to take down. There is no suspicious domain to block. There is just a gaming platform comment, getting read by infected websites, pointing to wherever the attackers currently want their malware to call home.
This is what modern web malware looks like in 2026. Not crude payloads on shady servers. Steganography inside legitimate platforms, served through trusted infrastructure, controlled by hijacking the comment sections of services nobody thinks to monitor. Here is exactly how the campaign works, why it is so hard to detect, what it means for the 2,000 affected sites and their visitors, and how IP and network intelligence can actually catch these attacks despite the obfuscation.
What happened: the campaign in plain language
The discovery timeline is straightforward. The mechanics are not.
July 2025. Attackers begin a malware campaign that targets WordPress sites with weak security. The initial infection vector is not fully confirmed but appears to include compromised admin credentials, vulnerable themes and plugins, FTP/SFTP credential theft (often via infostealer malware), and occasional supply-chain compromises through plugin updates.
Throughout late 2025 and early 2026. The campaign quietly spreads to roughly 1,980 WordPress sites. The infected sites continue to operate normally from the visitor's perspective. The site owners are largely unaware of the compromise. The malware is engineered specifically to avoid the kinds of behavior that would prompt complaints, takedowns, or investigation.
June 1-2, 2026. GoDaddy Security publishes a technical report on the campaign. Coverage spreads through BleepingComputer, Hackread, TechRadar, SC Media, and most major cybersecurity outlets over the next several days.
The infection model has two stages, both clever in different ways:
Stage one: a frontend injection. The malware injects malicious JavaScript into the public-facing pages of compromised WordPress sites. When a visitor loads any page on the infected site, the injected script executes in their browser, fetching content from external sources and potentially serving malware, phishing prompts, scam redirects, or whatever payload the attackers currently want to deliver. The visitor never sees anything obviously wrong, but their browser is being used as a vector for the attacker's downstream goals.
Stage two: a server-side backdoor. A PHP backdoor is planted on the compromised site that gives attackers persistent access to modify themes, plugins, and core files at will. Even if a site owner notices and removes the visible malware, the backdoor remains, ready to redeploy. This is the part that makes the infections sticky. Cleaning a single site without finding the backdoor results in reinfection within hours or days.
The truly novel part of the campaign is how the malware decides what to do, where to fetch its payloads, and which servers to communicate with. That part is hidden inside Steam.
The clever part: how Steam profile comments become C2 infrastructure
This is the section that has captured everyone's attention, and it is worth understanding because the technique generalizes well beyond this one campaign.
Command-and-control infrastructure is the part of a malware operation that tells infected systems what to do. Traditionally, C2 is a server the attacker controls. Infected machines call home to that server, receive instructions, and execute. Defensive systems detect malware partly by watching for outbound connections to known malicious servers, by analyzing traffic patterns, and by blocking communication with flagged infrastructure.
The problem with traditional C2 from the attacker's perspective is that it leaves a clear trail. The server has an IP address. The IP has an owner. The domain has a registrar. Security companies index known C2 infrastructure and block it. Hosting providers take down servers when complaints arrive. Maintaining C2 is expensive in a cat-and-mouse sense.
Steam profile comments solve all of those problems at once.
Here is how it works in this campaign:
- The attackers maintain one or more Steam Community profiles. These profiles look like normal gamer accounts. They have games. They have play time. They have profile pictures. Nothing obviously suspicious.
- The attackers post comments to these profiles that contain encoded payloads. The encoding uses invisible Unicode characters (called zero-width characters, things like U+200B zero-width space, U+200C zero-width non-joiner, etc.). A human reading the comment sees something like "GG nice game" or some ASCII art. A script reading the same comment sees a sequence of invisible bytes that decode to a URL or other instructions.
- The malware on compromised WordPress sites makes an HTTP request to the Steam Community profile page (using cURL or similar). This request looks identical to a normal user visiting Steam. The traffic goes to steamcommunity.com, which is one of the most-visited domains on the entire internet. No security system flags traffic to Steam.
- The malware parses the page HTML, extracts comment text, and decodes the hidden Unicode payload. This gives it a URL pointing to wherever the attackers currently want their actual malicious content served from.
- The malware then fetches the actual payload from that URL and either delivers it to visitors via the injected JavaScript or uses it to update the server-side backdoor.
The result is that the attackers can change their entire delivery infrastructure by editing a comment on a Steam profile. They never have to update the malware on 2,000 infected sites. They never have to maintain stable C2 servers. They piggyback on Valve's infrastructure for the communication layer, and they swap out the malicious content servers as needed without touching the malware itself.
Why this is genuinely hard to detect
Security professionals reading this section will immediately understand the problem. Everyone else, here is why this technique is so effective.
Traffic to Steam looks normal. Steam Community is one of the most-trafficked gaming platforms on the internet. Anyone running a WordPress site (a hosting provider, a security service, an automated scanner) sees outbound HTTPS connections to steamcommunity.com all day. It is unremarkable. There is no signature. There is no anomaly. Blocking it would break thousands of unrelated legitimate operations.
The C2 content is on Valve's servers, not the attacker's. Even if a security researcher identifies the malware and wants to take down its C2 infrastructure, there is no attacker-owned server to take down. The C2 is a comment on Valve's platform. To shut it down, you have to convince Valve to remove a specific comment from a specific profile. That is slow, requires explanation, and the attackers can simply post a new comment on a different profile within minutes.
The encoding is invisible to humans. A Steam moderator scrolling through reports of suspicious profiles sees comments that look like benign gaming chatter. The malicious content is in zero-width characters that produce no visible output. Manual review almost certainly misses it.
There is no obvious anomaly in the malware traffic itself. The infected WordPress site makes one HTTPS connection to Steam, just like a user clicking a Steam link from a webpage might. The request returns HTML. The HTML contains the (invisibly encoded) instruction. No part of this looks unusual to a network monitoring tool.
Even discovering the campaign required specific research. GoDaddy's researchers found it by analyzing the malware on infected sites, reverse-engineering the obfuscated code, and tracing the call chain back to Steam. It is not the kind of thing that would have shown up in routine traffic analysis or IDS alerts.
This is steganography applied to malware infrastructure. The communications are hidden in plain sight, on a platform that nobody monitors for C2, encoded in characters that nobody can see. It is the kind of campaign that can run for years if nobody happens to dig into the specific malware variant.
This is not the first time attackers have done this
The pattern, while novel in this specific implementation, is not new. Hiding C2 communications inside legitimate public platforms has been a recurring tactic for at least a decade. The Steam case is the latest, not the first.
A few historical examples worth remembering:
In June 2017, ESET researchers documented Russian hackers from the Turla group using comments on Britney Spears' official Instagram account as a C2 channel for a malware family called "Trojan.Win32.Turla." The malware would fetch specific Instagram comments, extract a hidden URL through a hashing algorithm, and then connect to whatever the attackers had pointed it at. Same principle, different platform.
Throughout 2019 and 2020, various campaigns used Twitter, GitHub gists, and Pastebin as C2 channels. Twitter accounts that posted seemingly random tweets contained encoded commands. GitHub commits with carefully crafted commit messages controlled malware fleets.
In 2022, researchers documented a campaign using Slack workspace messages as C2.
In 2023, the OneDrive folder structures of compromised cloud accounts were used to deliver payloads to malware running in corporate networks.
The pattern is durable because it works. Public platforms with comment sections, post histories, or any user-generated content can carry encoded data. As long as the platform itself is trusted and widely accessed, the C2 traffic blends in. Steam is just the latest variation on a theme that goes back to bulletin board systems hiding messages in classified ads.
The implication is that this category of attack is going to keep happening, on different platforms, with different encodings. Defenders cannot block Steam, or Twitter, or Instagram, or GitHub. The defensive game has to shift toward detection at the endpoint level (what the malware does on the infected server) rather than at the network level (what traffic it generates).
What an infected WordPress site actually does to its visitors
For the operators of the 1,980 compromised sites, the technical details matter less than the practical impact. Here is what visitors to an infected site might experience.
Malicious script injection on every page load. Every visitor to an infected site has external JavaScript loaded into their browser. That script can do almost anything: fingerprint the browser, redirect to phishing sites, deliver browser exploits, mine cryptocurrency in the background, inject affiliate codes into legitimate links, or harvest form data the visitor submits.
SEO poisoning. Many of these campaigns inject content specifically designed to manipulate search engine rankings. The compromised site starts appearing in search results for terms it never targeted, often related to pharmaceuticals, gambling, or counterfeit goods. The site owner sees traffic patterns shift in ways they cannot explain.
Redirect chains. Some visitors get redirected through a chain of intermediate servers to a final landing page that may be a scam store, a fake antivirus prompt, a malware download, or an explicit-content site. The redirects are often conditional based on user agent, country, time of day, or referrer, which makes them hard to reproduce when investigating reports.
Form data theft. If the infected site has any forms (login, contact, checkout), the injected JavaScript may be skimming form data and sending it back to attacker infrastructure. WooCommerce sites are particularly attractive targets for this kind of payment card harvesting.
Backdoor persistence. Even after the visible malware is removed, the server-side PHP backdoor allows the attackers to come back. Some site owners spend months in a cycle of clean-reinfect-clean before realizing they need to find and remove the underlying backdoor.
For visitors, the practical advice is the same as always. Keep browsers and antivirus updated. Be skeptical of unexpected prompts. If a familiar site suddenly behaves differently, prompts for unusual permissions, or redirects you somewhere unexpected, leave and come back later. The compromised sites are not always malicious to every visitor, but the trust assumption you made when you typed the URL is no longer valid.
How IP and network intelligence catches what other defenses miss
This is the part of the story that matters for anyone running a service, a website, or a security operation. The Steam C2 technique is hard to detect at the platform level. It is much easier to detect at the network level if you know what to look for.
Outbound connection profiling. A clean WordPress installation does not normally make HTTP requests to Steam Community from server-side PHP. WordPress fetches updates from wordpress.org, contacts a few specific update endpoints, and otherwise mostly serves traffic rather than making outbound requests. A server making cURL requests to steamcommunity.com from PHP execution context is an anomaly worth flagging, even though the destination itself is legitimate.
Reverse IP intelligence on outbound destinations. When malware redirects visitors or fetches payloads, it does eventually connect to attacker-controlled infrastructure somewhere. A reverse IP lookup on the destinations called by suspicious processes reveals whether those IPs host other malicious activity. Attacker infrastructure tends to cluster. One known-bad IP on a server usually means more known-bad infrastructure on the same hosting provider, sometimes on the same IP block.
Blacklist correlation in real time. The attacker servers that the Steam comments eventually point to are not random. They are part of broader malicious infrastructure that gets reported to threat intelligence feeds. Running outbound destinations through a blacklist checker before allowing a request to complete catches many of these calls, because the destination has often been flagged by other defenders. This kind of real-time IP reputation checking is the modern equivalent of antivirus signature detection: it does not catch novel attackers, but it catches almost everyone using shared or recycled infrastructure.
Vulnerability scanning of your own properties. The initial infection vector for this campaign was almost always a vulnerability in the WordPress site itself: outdated plugins, weak admin credentials, exposed admin endpoints, or supply-chain issues. Running periodic checks against your own sites with a website security scanner identifies the issues that let attackers in before they get used. Most of the compromised sites in this campaign had at least one identifiable security issue that a basic scan would have flagged.
Unusual file changes on the server. PHP backdoors and JavaScript injections involve modifying files on the WordPress installation. File integrity monitoring (manual or via security plugins like Wordfence, Sucuri, or MalCare) catches these changes within minutes. If your themes or plugins suddenly contain code you did not write, that is the alert.
Server-side logs. Most cPanel and managed WordPress hosts log every outbound request from PHP processes. Reviewing those logs (or having them automatically alert on requests to unexpected destinations) catches Steam C2 calls in the act. Most site owners never look at these logs. The data is there.
What WordPress site owners should do right now
If you run a WordPress site, the practical defensive actions are clear and they apply whether you have been hit by this specific campaign or not. The same hygiene that catches Steam C2 catches almost every other WordPress compromise.
Audit your plugins and themes. Remove anything you are not actively using. Update everything to the latest version. Plugins with no updates in over a year are particularly risky. Themes downloaded from sources other than the official WordPress repository or trusted commercial vendors should be replaced.
Lock down admin access. Use strong, unique passwords on admin accounts. Enable two-factor authentication on the WP admin login. Limit login attempts (Wordfence, Limit Login Attempts Reloaded, or similar). Restrict admin access to specific IP ranges if your team works from consistent locations. Block admin endpoint scanning at the firewall.
Disable file editing from the admin panel. Add define('DISALLOW_FILE_EDIT', true); to your wp-config.php. This stops attackers (and admins) from modifying themes and plugins through the WordPress admin UI, removing one common path attackers use after compromising admin credentials.
Check for unexpected files and modifications. Run a security scanner (Wordfence, Sucuri SiteCheck, MalCare) against your site monthly. These tools flag modified core files, unexpected PHP files in plugin directories, and known malware signatures. The Steam C2 malware specifically should be detectable by current security plugins as of the GoDaddy disclosure.
Monitor outbound connections. If your host gives you access to PHP process logs or outbound network logs, look at what your site is connecting to. WordPress does not normally call Steam, Twitter, or random short-link services. Anomalies in outbound destinations are often the clearest sign of compromise.
Have backups. Daily backups stored in a separate location are not a defense against compromise, but they are what makes recovery survivable. The cleanest way to recover from a deep WordPress infection is often to restore a known-good backup, then immediately patch whatever let the attackers in originally.
Suspect your developers and contractors. Many WordPress compromises start with credentials harvested from a developer's machine (often via infostealer malware downloaded along with a "free template" or "premium plugin nulled version"). If anyone with site access has been browsing those kinds of resources, treat their credentials as potentially compromised.
The bigger lesson: trusted platforms as attack infrastructure
The Steam case is not an isolated curiosity. It is part of a sustained trend that has been gaining momentum for years. Attackers increasingly host pieces of their infrastructure on platforms that defenders cannot block.
Defenders cannot block Steam. Defenders cannot block GitHub. Defenders cannot block Twitter, Instagram, Slack, Discord, Telegram, or any of the dozens of other widely-used platforms that have hosted C2 traffic in recent years. The cost to legitimate operations of blocking these services is far higher than the security benefit. So the platforms get used.
The strategic implication is that perimeter defense, the model where you decide what traffic to allow and block based on destination, is becoming less useful for catching modern threats. The malicious traffic looks identical to legitimate traffic. The destinations are legitimate. The content is encoded invisibly. There is nothing at the network boundary to flag.
What does work is behavioral detection at the endpoint and behavioral analysis of patterns over time. A WordPress server that has never called Steam suddenly making consistent Steam Community requests is anomalous, even though every individual request looks fine. A user account that has never logged in from Brazil suddenly being active from a Brazilian residential IP is anomalous, even though Brazilian residential IPs are legitimate. The signal is in the deviation from baseline, not in any individual fact.
Building that kind of detection requires actually knowing your baseline. Most organizations do not. They know what their stack is supposed to do, not what it actually does. The Steam C2 campaign succeeded for almost a year because nobody noticed the baseline shift on 1,980 WordPress sites.
Wrap up
Two thousand WordPress sites have been quietly serving malicious content to thier visitors for the better part of a year, controlled by comments on Steam profiles that nobody noticed. The attackers chose the technique well. There is no malicious server to take down, no domain to blacklist, no obvious anomaly in the traffic. Steam is one of the most legitimate destinations on the internet. The C2 instructions are encoded in characters that produce no visible output. Everything about the campaign is designed to be invisible.
The technique is novel in this specific implementation but the pattern is old. Britney Spears' Instagram in 2017. GitHub commits in 2019. Slack messages in 2022. The endless parade of trusted platforms repurposed as attack infrastructure is going to continue, because it works.
The defenses that work against this kind of threat are not at the network perimeter. They are at the endpoint, at the file system, at the user behavior layer, at the integrity of the code running on your servers. Knowing what your systems are supposed to do is the only way to notice when they are doing somthing else. The 1,980 WordPress sites that got infected almost certainly had warning signs that nobody was watching for. By the time GoDaddy's researchers connected the dots, the campaign had been running long enough to generate substantial revenue for the operators and seperate hundreds of site owners from the trust their visitors used to place in them.
Knowing how it works is the first step toward not being part of the next round.
Sources include GoDaddy Security's technical analysis published in early June 2026, follow-up coverage by BleepingComputer, Hackread, TechRadar, SC Media, and Cyber Security News. Historical context on legitimate-platform C2 patterns draws on ESET's 2017 documentation of the Turla group's Instagram campaign and multiple later research reports on similar techniques.
Comments 0