Kings of Google gun for supersoaker: SoakSoak WordPress malware warning

happygeek 2 Tallied Votes 669 Views Share

Google has been quick to blacklist domains implicated, most often unwittingly, in the distribution of what has become known as the SoakSoak malware campaign courtesy of soaksoak.ru being the first domain in the redirection path it used. With 11,000 domains blocked over the weekend, you might be forgiven for thinking that it's another WordPress hosting sites security problem sorted before it can do any harm. However, most experts I have spoken to would seem to agree that 11,000 domains is just the tip of this particular iceberg and the actual number of soaksoak impacts on WordPress specific sites is in the hundreds of thousands spectrum.

70e06738e64d01ec2e92f97d1a377c5d

According to security outfit Sucuri, which has been leading the analysis of this outbreak, it would appear that the attack vector can be that Sucuri disclosed some months back now. Unfortunately, as is the way with such things, many WordPress site operators do not seem to have addressed the issue and continue to use premium plugin. This isn't surprising given, as Sucuri points out "it’s not something everyone can easily upgrade and that in itself becomes a disaster for website owner". What's more, the plugin is bundled with themes and so some owners won't even know they have it.

Whatever, the supersoaker effect is quite clear: this is a local file inclusion attack methodology which means that a remote attacker can download any local file they fancy from the target server. In the case of soaksoak itself it would appear that a malicious theme is uploaded to the target site and a backdoor (Filesman) is then injected into the site followed by a secondary backdoor to modify the swfobject.js file itself which ultimately injects the malware which initially had a payload of site redirection to soaksoak.ru. I say initially because the bad guys are quick to morph both payload and attack methodology, so expect to see new redirection targets along with new backdoor payloads. I have heard that some are now being injected into images to help evade detection, for example, while others add malicious admins into the mix to ensure reinfection control if the original malware is not properly removed and the site efficiently cleaned up.

Amichai Shulman, CTO at security vendor Imperva, advises that "the first concern of each organization that uses 3rd party platforms such as WordPress is to make sure all known vulnerabilities of such a platform are virtually patched and that known and unknown application layer attacks (such as the one through which SOAKSOAK was introduced into those sites) are being mitigated at one time."

Dani AI

Generated

As noted, this outbreak shows how vulnerable third‑party code can leave persistent backdoors that survive cursory fixes. The addition below focuses on practical, low-risk detection and cleanup steps plus short-term hardening so an infected WordPress install can be returned to a verifiable, known-good state.

Quick checks and scans (run from the site root; make a full backup first):

# search common obfuscation patterns (skip uploads)
grep -Rni "base64_decode" --exclude-dir=wp-content/uploads .

# find PHP files accidentally placed in uploads
find wp-content/uploads -type f -name "*.php" -print

# list files changed in the last 30 days
find . -type f -mtime -30 -ls

# if WP-CLI available: list admins and verify core
wp user list --role=administrator --format=table
wp core verify-checksums

Recommended cleanup workflow (safe order): take the site offline or restrict access; export full file + DB backups; rotate all credentials (hosting panel, FTP/SFTP, DB, WP admin); replace WordPress core with a fresh download and reinstall plugins/themes from trusted sources; remove any unknown files or PHP in uploads; scan and clean the DB for injected content (posts/options). Check scheduled tasks (system cron and WP cron) and any .htaccess rules added after the compromise. After cleanup, re-run the scans above to confirm no remainders.

Short-term hardening and monitoring: disable in-dashboard file editing (define('DISALLOW_FILE_EDIT', true); in wp-config.php), regenerate WP salts (use the WordPress secret-key service), restrict PHP execution in uploads (deny PHP files via .htaccess), apply least-privilege file permissions, remove unused plugins/themes, enable a WAF and file-change monitoring, and keep automatic updates where feasible. Hosts that provide immutable snapshots or filesystem integrity checking can dramatically reduce rebuild time.

Caution: always work from backups or a staging copy; deleting files without verification can break custom functionality.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.