Yikes, I've been hacked! Now what?

[Joachim Müller]

Hidden files
On Linux/Unix driven webservers (most webservers are Linux/Unix-driven, which is great in terms of stability and performance), hidden files/folders have a leading dot in their names. This is different on Windows, but easy to understand.
As the name suggests, hidden files usually are not being displayed. That's a fact that legitimate applications like the webserver "Apache" use: the configuration file for that webserver usually is a hidden file named .htaccess (mind the leading dot). The presence of a .htaccess file (and even several of them) is not a bad thing in itself, nor is it an indication of a hacking attempt if  there are one or more of those .htaccess files on your server. Your server and the FTP application you use to control it usually is configured not to display hidden files (remember: they start with a dot in their name), so you won't be aware of .htaccess-file(s) existing on your webspace. However, with such a webserver configuration file, hackers can do all kinds of unwanted things to happen, like redirecting. Hackers often use the fact that their victims are not very experienced and therefor hardly know about the power of .htaccess files.
There is an exploit (the payload of a hack) that drops a .htaccess file into the gallery folder that redirects all images to google, which results in all images embedded into your gallery appearing to be broken.
Therefor: before starting the sanitization by downloading the working copy to your PC, make sure that hidden files (if they exist) are being transfered from your webspace to your local working copy: this way, you can examine .htaccess files that may exist on your webspace. Those .htaccess files are plain-text files that you can view with any plain-text editor (notepad.exe will be fine). If you're not sure about what a particular .htaccess file does, just temporarily remove it from your server (i.e. keep a backup somewhere) and test if anything works as expected. You might just as well rename it (e.g. from .htaccess to htaccess_renamed) to check. There may be .htaccess files on your webspace that your webhost put there, so don't panic if you see such a file. When in doubt, ask your webhost for support - ask them if they put the file there. Alternatively, post the content of your .htaccess file on the support board if you're not sure and ask for help with it.
Coppermine itself doesn't come with a .htaccess file, so if neither you nor your webhost have created a particular .htaccess file, it probably is the payload of a hacking attempt, so try to delete it (keep a backup!) and see what happens then.

[Joachim Müller]

No support
I'm not ready to support this thread, it comes as-is, as a courtesy for those who find it helpful. Please do not start new threads that refer to this thread with further question. Under no circumstances are you allowed to contact me individually (by PM or email).

[Joachim Müller]

Jeff aka onthepike has come up with an excellent summary as well

Steps in attempting to identify a potential threat and/or embedded malware.

First and foremost, a few things bear repeating: You, as a webmaster, regardless of skill level, are responsible for your website, and responsible for the safe passage of visitors to and from your web space. You are responsible for maintaining a safe environment, which means, but by no means is limited to, keeping whatever applications/scripts/programs you have running (or available) as up-to-date as possible. Do not expect your web host, a volunteer or anyone else to come to your rescue should disaster strike. A good webmaster understands these basic principles and takes steps towards that end.

These steps include keeping all scripts up-to-date by regularly visiting that programs homepage and/or support forum and subscribing to their newsletter (if applicable). These steps include setting proper permissions on files and directories. These steps include removing old or unused scripts from the web space (or removing read/write access to these scripts if they are necessary for documentation purposes).  These steps include backing-up. It cannot be stressed enough how important it is to regularly back-up your files. While it can be very time consuming to fully back-up your web space, consider the alternative -- being directed to this thread overwhelmed with fear, frustration, anxiety, stress and confusion. Weighing these, backing up really isn't that bad after all! And in some cases, may be your only recourse in reviving a site that's been infected with malware, etc.

The above topics have been covered within this Yikes thread. This post deals with actually identifying a (hidden or otherwise) threat that's embedded in your web space. The webmaster, of course, has (or should have) full and complete access to the servers file and directory structure. As a site visitor, options are much more limited and restricting. Still, there are available tools to help identify potential threats. Some are outlined below:

• Unmask Parasites: Scans entered website seeking embedded malware, known signatures and potential unsafe links and redirects.
• Norton Safe Web: Similar to above, however relies on cached results based upon prior automated scanning. Also allows comments from registered users, which can prove helpful.
• Google Safe Browsing Diagnostic: Cached results of malware scanning.
• McAfee Site Adviser: Uses a cached database to display results of previously scanned websites.
  Trend Micro Web Reputation Search: Similar to Norton Safe Web and uses cached results.
• Virus Total*: Virus Total is a service that analyzes suspicious files  and facilitates the quick detection of viruses, worms, Trojans, and all kinds of malware detected by anti-virus engines. Works in real-time as well as cached results. *Note however, this tool is best suited for webmasters in most cases.

In addition, an excellent supplemental article to this Yikes thread, and a generally informative outline regarding repairing an infected website can be found here: How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions. Extremely large galleries with many hundreds or thousands of files and folders may benefit from utilizing cron to list all the files in your (Linux) website, where the output may be visually inspected to verify no rogue files/folders and their permissions.

Important: Before attempting to resolve a website issue, it is imperative that you first activate the anti-virus program of your choice and update it to the latest definitions. Activate your backup anti-malware program (such as Malware Bytes and/or SpyBot Search & Destroy's IE Resident -- if applicable) and fully scan your computer to identify and resolve threats there before accessing an infected website. It makes no sense to cleanse a website of an infection that your own PC may re-infect upon access. Resolve your PC issue(s) first, then move onto your website issue. After successful scanning of your virus-free computer, and using each of the tools listed above, carefully scan the infected website.

As a visitor, I begin with Unmask Parasites, a scanner that uses both cached results from previous scans as well as real-time scanning to identify possible threats and suspicious links (to known malware sites).  The scanner will display results as well as potential suspicious links and scripts. Viewing the source code of a given page will accomplish some of what Unmask Parasites accomplishes, but doesn't "red flag" anything. A supporter or helper has no way of knowing what external links are legitimate and what external links are problematic. Unmask Parasites (as well as the rest of the tools) will highlight these for you for later review -- or in some cases -- provide an in-depth explanation of the type of risk identified. Or both. Note any suspicious links or scripts and rescan again using the rest of the above tools. Upon scan completion, we should now have a pretty good idea of where to begin. Compile the list of suspicious items and head to your favorite search engine and begin the process of identifying each suspicious link and script.

Armed with whatever knowledge learned from searching, begin the process of removing potential threats.

Identify the obvious first, if possible. Visually inspect the directory structure in question (and in some respects, in general) and scan for blatantly obvious files and/or folders that aren't part of the Coppermine directory structure. Coppermine utilizes a meta-redirect within index.php files, so unless the webmaster has explicitly added them, there should be no .htaccess files; especially under the /albums directory tree. Some legitimate plugins do include an .htaccess file; verify these by inspecting with Notepad (or any other equivalent plain-text editor). In general however, an .htaccess file usually resides within the /www or /public_html directories and is usually legitimate. Note however, this file can be hijacked as well, so a visual scan and inspection of this file is a must, if such file exists. If an .htaccess file is indeed found within the /albums directory tree, delete it/them. And all others found under this directory.

If, after inspection, files and/or folders are found that shouldn't be there, delete them. If, after inspection, files and/or folders are found that shouldn't be there and can't be deleted or modified, the webmaster's options are limited.

The first step is to verify file ownership and permissions. The file in question should be "owned" by the domain name (or name that your host has given you). Verify ownership from the web host's control panel (usually cPanel or similar) file manager. While FTP apps prove extremely useful for most website publishing needs, most FTP apps do not furnish the required authentication necessary to take ownership of a rogue file or folder. So it's best to utilize the online file manager that comes as part of your domain package. Attempt to delete the folder in question. If this fails, attempt to change the permissions of the file in question to 755 (0755). If this fails, you will need to contact your web host and seek assistance in deleting the file.

Once the rogue file/folder has been removed, website cleansing may resume. Upon completion, gallery restoration, including database manipulation, if necessary, may begin.