In the last two weeks, a new hack has made the rounds. This exploits a weakness in either the hosting or the security of a WordPress blog and adds malicious code to every JavaScript file (.js). The code can vary a bit but typically starts like this (with a unique identifier):
/*3395379449f353892757e0b699dd2159*/;window["\\x64\\x6f"+"\\x63\\x75"+"\\x6d\\x65"
And ends like this (with the same unique identifier, which varies per site):
["\\x31\\x32\\"]].join(""));/*3395379449f353892757e0b699dd2159*/
Why This Hack Is Particularly Problematic
As this malicious code gets injected into all JavaScript files, it’s particularly tricky to remove. To date, the normal security tools do not detect this vulnerability (including Sucuri), but I am sure with the next major update they will incorporate detection.
The exact cause isn’t yet known, but most likely it’s due to out-of-date plugins which allow unauthorised modification of files. Once that vulnerability is exploited, the infection seeks out JavaScript files and appends the malicious code to the end of each one.
Cleaning Your WordPress Installation
Cleaning the infected files is not easy; in-situ it is almost impossible. If you have access to a Linux-based computer or a Mac (based on FreeBSD), these instructions can help you clean up your site. You should still update your plugins and WordPress version afterwards to prevent re-infection.
Step 1: Backup
Download all your files, including everything, to ensure a complete eradication is possible. Once downloaded, compress the files into a ZIP archive (keep a copy to work on; the ZIP is there in case you need to restore anything).
Step 2: Clean
The easiest way to clean is to restore an old backup from before the infection. If you have one, upload it (overwriting existing files) and proceed to the hardening step below.
If you don’t have a backup, or your backup was also compromised, you can try using the sed command. This command differs slightly between macOS and Linux:
For macOS (FreeBSD) users:
LC_ALL=C find /PATH_TO_YOUR_HACKED_FILES/ -type f -exec sed -i '' -E "s/(\/\*.{32}\*\/\;window\[.*\/\*.{32}\*\/)/ /" {} +
The LC_ALL=C prefix ensures it will work on Macs with a non-US locale. The expression looks for the starting window string with the unique comment identifier, then finds the matching ending comment and removes everything in between.
For Linux users:
find /PATH_TO_YOUR_HACKED_FILES/ -type f -exec sed -i -E "s/(\/\*.{32}\*\/\;window\[.*\/\*.{32}\*\/)/ /" {} +
Note that for Linux, you remove both the LC_ALL=C prefix and the empty quotes ('') after -i. In FreeBSD (macOS), these empty quotes prevent the creation of backup files, which aren’t needed in this case.
This approach could potentially affect legitimate code; however, as the malicious code is deliberately obfuscated, it’s generally safer to remove anything matching this pattern that you can’t easily read or verify.
Step 3: Upload & Hardening
Now upload your cleaned files, overwriting all existing files. Your site is (for now) clean. To harden your WordPress installation against future attacks, I recommend the following steps:
- Update your WordPress core to the latest version
- Update your themes (a more common vector for attack than most people realise)
- Update all your plugins to their latest versions
Finally, install security plugins to help prevent modifications. These can also warn you if someone logs into your blog and alert you to other important changes.
I recommend Sucuri Security. It has a free version with premium additions. The free version is sufficient for most sites, but if your site generates revenue, I recommend considering the paid version for enhanced protection.
Once installed, go through the setup process and enable as many protective features as feasible for your site, especially directory protection.
Troubleshooting: “My Site Stopped Working After Hardening”
Don’t panic! This usually happens because one of your plugins needs more access than the security settings allow. To identify the problematic plugin:
- Disable all plugins
- Re-enable them one by one
- When you find the one that doesn’t work with the security measures, you can create an exception rule for it
Final Check
After cleaning and hardening, it’s worth performing a quick check to see if you have any unrecognised directories or files that might indicate other compromises. Review your site structure carefully and look for anything unusual or unexpected.
By following these steps, you should be able to recover from this JavaScript hack and better protect your WordPress site against future attacks. Remember that security is an ongoing process—regular updates and monitoring are essential to keeping your site safe.