Monday, August 24, 2015
Today in our #NoHacked campaign, we’ll be discussing how to fix the injected gibberish URL hack we
wrote about last week. Even if your site is not infected with this specific type of hack, many of
these steps can be helpful for fixing other types of hacks. Follow along with discussions on
Twitter
and Google+ using the
#NoHacked tag.
(Part 1,
Part 2,
Part 3,
Part 4)
Temporarily Take your Site Offline
Taking your site offline temporarily will prevent your site’s visitors from going to hacked pages
and give you time to properly fix your site. If you keep your site online, you run the risk of
getting compromised again as you clean up your site.
Treating your Site
The next few steps require you to be comfortable making technical changes to your site. If you
aren’t familiar or comfortable enough with your site to make these changes, it might be best to
consult with or hire someone who is. However, reading through these steps will still be helpful.
Before you start fixing your site, we advise that you back up your site. (This backed up version
will still contain hacked content and should only be used if you accidentally remove a critical
file.) If you’re unsure how to back up your site, ask your hosting provider for assistance or
consult your content management system (CMS) documentation. As you work through the steps, any
time you remove a file, make sure to keep a copy of the file as well.
Checking your .htaccess file
In order to manipulate your site, this type of hack creates or alters the contents of your
.htaccess file.
If you’re not sure where to find your .htaccess file, consult your server or CMS
documentation.
Check the contents of your .htaccess file for any suspicious content. If you’re not
sure how to interpret the contents of the .htaccess file, you can read about it on
the Apache.org
documentation, ask in a help forum, or you can consult an expert. Here is an example of a
.htaccess modified by this hack:
Identifying other malicious files
The most common types of files that are modified or injected by this hack are JavaScript and PHP
files. Hackers typically take two approaches: The first is to insert new PHP or JavaScript files
on your server. The inserted files can sometimes be named something very similar to a legitimate
file on your site like wp-cache.php versus the legitimate file
wp_cache.php. The second approach is to alter legitimate files on your server and
insert malicious content into these files. For example, if you have a template or plugin
JavaScript file on your site, hackers might add malicious JavaScript to the file.
For example, on www.example.com a malicious
file named happypuppy.php, identified earlier in the .htaccess file, was
injected into a folder on the site. However, the hackers also corrupted a legitimate JavaScript
file called json2.js by adding malicious code to the file. Here is an example of a
corrupted json2.js file. The malicious code is highlighted in red and has been added
to the very bottom of the json2.js file:
To effectively track down malicious files, you’ll need to understand the function of the
JavaScript and PHP files on your site. You might need to consult your CMS documentation to help
you. Once you know what the files do, you should have an easier time tracking down malicious files
that don’t belong on your site.
Also, check your site for any recently modified files. Template files that have been modified
recently should be thoroughly investigated. Tools that can help you interpret obfuscated PHP files
can be found in the Appendix.
Removing malicious content
As mentioned previously, back up the contents of your site appropriately before you remove or
alter any files. If you regularly make backups for your site, cleaning up your site might be as
easy as restoring a clean backed-up version.
However, if you do not regularly back up your site, you have a few alternatives. First, delete any
malicious files that have been inserted on your site. For example, on www.example.com, you would
delete the happypuppy.php file. For corrupted PHP or JavaScript files like
json2.js, you’ll have to upload a clean version of those files to your site. If you
use a CMS, consider reloading a fresh copy of the core CMS and plugin files on your site.
Identifying and Fixing the Vulnerability
Once you’ve removed the malicious file, you’ll want to track down and fix the vulnerability that
allowed your site to be compromised, or you risk your site being hacked again. The vulnerability
could be anything from a stolen password to outdated web software. Consult
Google Webmaster Hacked Help
for ways to identify and fix the vulnerability. If you’re unable to figure out how your site was
compromised, you should change your passwords for all your login credentials,update all your web
software, and seriously consider getting more help to make sure everything is ok.
Next Steps
Once you’re done cleaning your site, use the Fetch as Google tool to check if the hacked pages
still appear to Google. You’ll need to bring your site back online to test with Fetch as Google.
Don’t forget to check your home page for hacked content as well. If the hacked content is gone,
then, congratulations, your site should be clean! If the Fetch as Google tool is still seeing
hacked content on those hacked pages, you still have work to do. Check again for any malicious PHP
or JavaScript files you might have missed.
Bring your site back online as soon as you’re sure your site is clean and the vulnerability has
been fixed. If there was a
manual action
on your site, you’ll want to file a
reconsideration request
in Search Console. Also, think about ways to protect your site from future attacks. You can read
more about how to secure your site from future attacks in the
Google Hacked Webmaster Help Center.
We hope this post has helped you gain a better understanding of how to fix your site from the
injected gibberish URL hack. Be sure to follow our social campaigns and share any tips or tricks
you might have about staying safe on the web with the #nohacked hashtag.
If you have any additional questions, you can post in the
Webmaster Help Forums
where a community of webmasters can help answer your questions. You can also join our
Hangout on Air about Security
on August 26.
Appendix
These are tools that may be useful. Google doesn’t run or support them.
PHP Decoder,
UnPHP: Hackers will often distort PHP files
to make them harder to read. Use these tools to clean up the PHP files so you understand better
what the PHP file is doing.
How we apply this
We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.
Related services