What to look for

The three most common forms of badware that StopBadware sees on compromised sites are:

1. Malicious scripts
2. .htaccess redirects
3. Hidden iframes

Malicious scripts

Malicious scripts are often used to redirect site visitors to a different website and/or load badware from another source. These scripts will often be injected by an attacker into the content of your web pages, or sometimes into other files on your server, such as images and PDFs. Sometimes, instead of injecting the entire script into your web pages, the attacker will only inject a pointer to a .js or other file that the attacker saves in a directory on your web server.

Many malicious scripts use obfuscation to make them more difficult for anti-virus scanners to detect:

Many malicious scripts use obfuscation to make them more difficult for anti-virus scanners to detect:

picture of obfuscated script

Some malicious scripts use names that look like they’re coming from legitimate sites (note the misspelling of “analytics”):

picture of deceptive script

.htaccess redirects

The Apache web server, which is used by many hosting providers, uses a hidden server file called .htaccess to configure certain access settings for directories on the website. Attackers will sometimes modify an existing .htaccess file on your web server or upload new .htaccess files to your web server containing instructions to redirect users to other websites, often ones that lead to badware downloads or fraudulent product sales.

picture of an htaccess redirect

Hidden iframes

An iframe is a section of a web page that loads content from another page or site. Attackers will often inject malicious iframes into a web page or other file on your server. Often, these iframes will be configured so they don’t show up on the web page when someone visits the page, but the malicious content they are loading will still load, hidden from the visitor’s view.

picture of a hidden iframe injected in a web page

How to look for it

If your site was reported as a badware site by Google, you can use Google’s Webmaster Tools to get more information about what was detected. This includes a sampling of pages on which the badware was detected and, using a Labs feature, possibly even a sample of the bad code that was found on your site. Certain information can also be found on the Google Diagnostics page, which can be found by replacing example.com in the following URL with your own site’s URL: www.google.com/safebrowsing/diagnostic?site=example.com

There exist several free and paid website scanning services on the Internet that can help you zero in on specific badware on your site. There are also tools that you can use on your web server and/or on a downloaded copy of the files from your website to search for specific text. StopBadware does not list or recommend such services, but the volunteers in our online community will be glad to point you to their favorites.
Removing the badware behavior

Once you have located the code that is causing the badware behavior, removing it is often as simple as deleting the offending code from all files in which it appears. Sometimes, it is easier, if you have a clean backup of your site’s contents, to re-upload all of the site’s files, though be careful about overwriting files that may have changed since your last backup. In some cases, the bad content may be stored in one or more database records, in which case restoring a recent backup of the database or manually editing the relevant records may be necessary.
Preventing future infection

Preventing badware on your website requires protecting three things: your site itself, the password(s) used to upload content to the site, and the computer(s) used to upload content to the site. The site itself must be protected because attackers often look for vulnerable software to exploit so they can modify your site’s contents. The passwords are critical because, if they are guessed or stolen, they can be used to modify the site. Finally, computers are important because badware on your computer can steal your password and/or modify the contents that you are uploading.
Protect your site

* Ensure that any software you use (e.g., blogging software like WordPress, third party scripts, etc.) is kept up to date with the latest security fixes, either by you (if you installed the software) or by your hosting provider.
* Remove any scripts, services, or other software that you are no longer using.
* Change any default passwords that come with the software you are using.
* Use appropriate file permissions on your web server.

Protect your password

Use a strong password and change it occasionally, especially if you have reason to think it has been compromised.

If we Hosting Marketers contacted you because your site has been hacked we request you to take the following security measures:
Update your script to the latest version!

1) Scan your computer with a good anti virus for virus, Trojans and key-loggers, don’t type passwords, copy and paste.
2) Change the password for you control panel and ftp accounts, if possible change the password for your database as well.
3) Check for the file/folder permission in your control panel. File permissions should be set to 644 and folder permissions should be set to 755.
4) You can scan you Mail, Entire Home Directory, Public Web Space, Public FTP Space using Virus Scanner present in your control panel under Advanced section.

You can also add the below lines to your .htaccess file to protect a site against some of the most common vulnerabilities:

# prevent access from santy webworm a-e
RewriteCond %{QUERY_STRING} ^(.*)highlight=\%2527 [OR]
RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
RewriteCond %{QUERY_STRING}% s:(.*)252echr [OR]
RewriteCond %{QUERY_STRING} ^(.*)esystem(.*) [OR]
RewriteCond %{QUERY_STRING} ^(.*)rush=\%65\%63\%68 [OR]
RewriteCond %{QUERY_STRING} ^(.*)rush=echo [OR]
RewriteCond %{QUERY_STRING} ^(.*)wget\%20 [OR]
RewriteCond %{QUERY_STRING}% s:(.*)wget
RewriteRule ^.*$ [R,L] 

# prevent pre php 4.3.10 bug
RewriteCond %{HTTP_COOKIE}% s:(.*):\%22test1\%22\%3b
RewriteRule ^.*$ [R,L]  

# this ruleset is to "stop" stupid attempts to use MS IIS Web Server expolits on us
RewriteCond %{REQUEST_URI} /(admin|cmd|httpodbc|nsiislog|root|shell)\.(dll|exe) [NC]
RewriteRule .* - [F,L]

RewriteCond %{REQUEST_URI} /default\.(ida|idq)$ [NC,OR]
RewriteCond %{REQUEST_URI} /.*\.printer$ [NC]
RewriteRule .* - [F,L]

# IE's "make available offline" mode
RewriteCond %{HTTP_USER_AGENT} MSIECrawler [OR]

# unknown bot
RewriteCond %{HTTP_USER_AGENT} ^NG [OR]

# You may want to enable these lines below to disallow php and perl scripts to access your site
 RewriteCond %{HTTP_USER_AGENT} ^.*PHP.*$ [OR]
 RewriteCond %{HTTP_USER_AGENT} ^.*libwww-perl [NC,OR]

# Ignorant user trying to edit my site
RewriteCond %{HTTP_USER_AGENT} FrontPage [OR]
#this one will ban everything microsoft. Use with caution.
RewriteCond %{HTTP_USER_AGENT} ^(Microsoft|MFC).(Data|URL|WebDAV|Foundation).(Access|Control|MiniRedir|Class) [NC,OR]

# MSOffice
RewriteCond %{REQUEST_URI} ^/(MSOffice|_vti) [NC,OR]

# Various
RewriteCond %{REQUEST_URI} ^/(bin/|cgi/|cgi\-local/|cgi\-bin/|sumthin) [NC,OR]
RewriteCond %{THE_REQUEST} ^GET\ http [NC,OR]
RewriteCond %{REQUEST_URI} /sensepost\.exe [NC,OR]

# Cyveillance is a spybot that scours the web for copyright violations and ?damaging information? on
# behalf of clients such as the RIAA and MPAA. Their robot spoofs its User-Agent to look like Internet
# Explorer, and it completely ignores robots.txt. I have
# banned it by IP address.
RewriteCond %{REMOTE_ADDR} ^63\.148\.99\.2(2[4-9]|[34][0-9]|5[0-5])$ [OR]
RewriteCond %{REMOTE_ADDR} ^63\.226\.3[34]\. [OR]
RewriteCond %{REMOTE_ADDR} ^63\.212\.171\.161$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.118\.41\.(19[2-9]|2[01][0-9]|22[0-3])$ [OR]

# NameProtect peddles their ?online brand monitoring? to unsuspecting and gullible companies
# looking for people to sue. Despite the claims on their robot information page, they do not
# respect robots.txt; in fact, they spoof their User-Agent in multiple ways to avoid detection.
# I have banned them by User-Agent and IP address.
RewriteCond %{REMOTE_ADDR} ^12\.148\.196\.(12[8-9]|1[3-9][0-9]|2[0-4][0-9]|25[0-5])$ [OR]
RewriteCond %{REMOTE_ADDR} ^12\.148\.209\.(19[2-9]|2[0-4][0-9]|25[0-5])$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^NPBot	[NC,OR]

# Web Content International
RewriteCond %{REMOTE_ADDR} ^65\.102\.12\.2(2[4-9]|3[01])$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.102\.17\.(3[2-9]|[4-6][0-9]|7[01]|8[89]|9[0-5]|10[4-9]|11[01])$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.102\.23\.1(5[2-9]|6[0-7])$ [OR]

# dumb bot
RewriteCond %{HTTP_USER_AGENT} "^Mozilla/4.0$" [OR]

# Wordtracker
RewriteCond %{REMOTE_ADDR} ^128\.242\.197\.101$ [OR]

# Unknown
# unknown.Level3.net
RewriteCond %{REMOTE_ADDR} ^64\.156\.198\.(6[89]|7[0-9]|80)$ [OR]

# host25x.keebler.com
RewriteCond %{REMOTE_ADDR} ^65\.223\.250\.25[0-3]$ [OR]

# Turnitin spybot
RewriteCond %{REMOTE_ADDR} ^64\.140\.49\.6([6-9])$ [OR]
RewriteCond %{HTTP_USER_AGENT} TurnitinBot [OR]

# this ruleset is for formmail script abusers...
# we don't use Perl for Postnuke so this is not really needed.
RewriteCond %{REQUEST_URI} (mail.?form|form|form.?mail|mail|mailto)\.(cgi|exe|pl)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$
RewriteRule .* - [F,L]

# dumb bot
RewriteCond %{HTTP_USER_AGENT} "^Mozilla/3.0$"
RewriteRule .* - [F,L]

<FILES .htaccess>
order allow,deny
deny from all