Websites open to external access from off-campus are exposed to frequent hacking attempts, with successful attacks leading to undesired effects from hosting spam pages and links, to hosting malware and more. If you suspect that your website may be compromised, the following information may be of use.
Identifying Compromised Sites
Outside of more complicated detection/verification methods, such as network IDS systems, full packet captures, etc., there are several simple methods of detection of a compromised web application:
- It may be the case that your website’s compromise is first discovered by someone else. In order to assist them in contacting you about the issue make adequate contact information (email address, phone number, contact person, etc) clearly available on your website.
- A common attack on websites is to have spam ad pages added to your website by malicious actors whose goal is to have those pages crawled by Google, Bing, and other popular search engines.
- You can check what Google is indexing on your website by using the
site:prefix in a search. - For example, assuming your website’s hostname is
www.something.gatech.eduyou can search for spam ads on your site that may be advertising online gambling, you could search for ad-related language on your site via a Google search for:site:www.something.gatech.edu "online casino"
- You can check what Google is indexing on your website by using the
- You can often find malicious scripts by looking for signs of common code obfuscation techniques in the files of your website.
- For a PHP-based application (assuming your website’s document root is in /var/www/html), running a search like the below may find files that you will want to inspect for possible altered code.
find /var/www/html/ -type f -name '*.php' -exec egrep -H 'eval\s*\(\s*gzinflate|eval\s*\(\s*\S+4_deco|eval\s*\(\s*\$\{|preg_replace\s*\(\s*\"\/.*\/e\".*\\x|FilesMan' {} \;
- For a PHP-based application (assuming your website’s document root is in /var/www/html), running a search like the below may find files that you will want to inspect for possible altered code.
- Compare all the files of your application to a known-to-be-valid, released version by downloading the source of your application again and recursively comparing that source with what is on your site as well as any of those files that you find to have been added or changed (especially those containing code).
- Examine the list of users allowed to access your website to see if any unauthorized users have been created. Likewise, look in the application for recently created or modified posts or pages.
- Assuming you have access to web server logs, you could look for successful off-campus POSTS to unusual URLs.
- Both of the requests below would be considered suspicious:
- …an oddly-named file that *most likely* shouldn’t normally exist in your application
172.16.34.2 - - [17/Dec/2015:16:14:33 -0500] "POST /ryuyh2u2.php HTTP/1.1" 200 5037 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML" "-" "-/-"
- …in the case of WordPress, 404 pages are not normally POSTed to, especially if accessed out of the context of regular request flow
172.16.0.99 - - [17/Dec/2015:17:12:11 -0500] "POST /wp-content/themes/twentyfifteen/404.php HTTP/1.1" 200 34892 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
- …an oddly-named file that *most likely* shouldn’t normally exist in your application
If You Suspect Compromise
If you think your website might be compromised, please:
- Do not delete, move, or modify files or directories that you suspect to be malicious, as doing so may impede the ability to later determine exactly how your site was compromised.
- Establish contact with Georgia Tech Cyber Security immediately via email to incident@security.gatech.edu (please do not send sensitive information in your request); if off-hours or urgent, additionally contact OIT Operations at 404-894-4669.
- Stop the web server process if you believe your website is distributing malware (either through direct experience or user reports). If you are unable to stop the web server process, if possible, remove network access to the website (e.g. firewall setting, unplugging the network cable, downing network interfaces, etc). Failing those options, consider shutting the machine down.