Malicious URL Troubleshooting and Guidelines

Issue Description

Usually the hosting of malicious content is not intentional and is instead the result of a vulnerability of a service (such as a website, a user account etc.) or the operating system.  Malicious content must not only be removed but the method used by third parties (such as exploiting an unpatched software, weak permissions, a weak password or a vulnerable feature) to publish the material must be corrected as well.  The process is generally the same regardless of if the material is phishing related or actual malware.

Be careful not to visit a URL that may contain malicious content as it may infect your workstation computer.

Suggestions for Resolution

It is recommended to take the reported website offline until you are sure it has been cleaned.  You may have to bring the site back online for part of the following process but generally it should remain offline until the cleaning process is completed.

  • Investigate and collect information about the infection
  1. Identify the involved user account, domain, and the malicious file location
  2. Note all timestamps, permissions, ownership related to the malicious content
  3. In some cases, the malicious content could have been uploaded on the website, or injected inside a legitimate files code. Make sure to list any files that might have been modified but are legitimate files on the site.
  4. As you review the content, look for any of the following:
    1. Spammy text and links. These may be obvious, but if not, try searching for common spammy keywords like the names of pharmaceutical products or words like "cheap," "free," "casino," and "amateur."
    2. Obfuscated spammy text, links, or meta refreshes (which can be harder to detect). Try searching the page code for words like base_64. For example, text like eval(base_64_decode("aisiYSlbYlaws...")) might be used for cloaking.
  5. Both system accounts and accounts configured within the website's application might be affected.  Check that no new user accounts have been created.  If you do find any note the usernames for later reference.
  6. While looking for malicious content try to discover the malicious user's intent.  Did they just want to trick end users into providing personal information while posing as another business (ie. phishing) or were they trying to drive traffic to another site using your site's good reputation in search results?
  7. If your site uses a database you should inspect the database records on your server and look for suspicious content in the database.  Check for 'splash damage' such as unexpectedly created users on the site itself and other modifications in the database.
    1. If the content found in the database isn't 'escaped' or strongly 'typed' and thus would restrict how it is output then it's likely true that it was inserted using an SQL injection and a vulnerability exists on the site that allows this activity. SQL injection happens when a user intentionally uses poorly written or out-dated code to insert records into a site's database which will later be displayed on your site as rogue content containing spam, URLs or objectionable content.  Malicious users can also use your database to store illegally obtained data to other hackers for later retrieval.
  8. If you believe you have a clean backup of the site you can compare the files using "diff" or "md5sum". Any files that are different but should not be should be added to your list of suspicious files for later cleanup.
  • Clean the identified malicious content
  1. If you have a clean and current backup you can simply restore that backup.
  2. Using a clean and current backup may reintroduce whatever vulnerability allowed the material to be published in the first place.  Updates and site user password changes should take place after a backup is restored.
  3. If you do not have a clean and current backup a more manual approach must be taken to remove the malicious content.
  4. Check for other malicious content (review files with the same timestamp or same location)
  5. Remove any illegitimate user accounts or databases.
  6. Verify other websites hosted on the server to see if they have also been affected. You can search for similar content in the other websites. Investigation and cleanup should occur on those sites in just the same way.


  • Fix the vulnerability and secure the website/account

Identify the vulnerability that lead to the publishing of the malicious material.

  1. Out of date software must be updated.  This includes both out of date operating system software and utilities as well as software on the actual site such as the content management system, blogging platform, applications, plugins, etc.
  2. Change the passwords for all accounts related to that web-site.  This includes SSH/FTP accounts as well as accounts within the site's application (ie. Wordpress). Cracking a weak password can be easy for hackers considering they can attempt to crack a password for days at a time before being noticed.  It is extremely important that all users have strong passwords.  A reasonably strong password is upper and lower case and uses both alpha and numeric characters.  The length of a decent password should be at least 8 characters long but using more characters and punctuation or symbols (!@#$%) is even better.
  3. Check the directory and sub-directories of the site for insecure permissions
    1. Example:
      find <your-dir> -type d -not -perm 755 -exec ls -ld {} \;
  4. Check the files of the site for insecure permissions
    1. Example:
      find <your-dir> -type f -not -perm 644 -exec ls -la {} \;
  5. Check for viral infections on the administrator's workstation as well as the server itself
    1. Use several virus scanners for this purpose.  It is also useful to reboot the workstation into safe-mode or single-user mode before using the virus scanner in order to ensure extensions used to hide the virus are not loaded by the operating system.
  6. Permissive coding practices must be removed.  For example one can disable remote file includes in PHP by limiting fopen to local files only.  Abusing this kind of vulnerability can not only load remote code to be executed by your server but it can also result in the redirection of visitors to other sites.


Article is closed for comments.
Powered by Zendesk