Even though I thought you were using phpBB, as that was what the cached version said, if you're using vBulletin, there's a few things to check in case of compromises:
1) Go through ALL plugins, there may be new ones that contain malicious code / backdoors.
2) Scan all templates for "eval" or similar commands. A PHP backdoor in vBulletin templates often begins with { or eval( , I think in vB4 backdoors can look like this: {vb:raw eval($_GET['haxx']) } (Not 100% sure but I've seen backdoors hidden in templates. It is _even_ possible to make a template look like it was never modified, meaning you can't assume a "red" color on a template means it was edited by a hacker.)
3) Make sure HTML is still disabled for all forum sections (this can pose a threat too).
4) Even if you have removed all backdoors from the admincp, INCLUDING the "cron" scripts, they can still be in a "cache" version of the entire site which I've experienced. This often occurs when one performs manual edits of the database as it seems vBulletin also uses the somewhat confusing "datastore" table as well for almost everything.
Okay, you've gone through templates, plugins, forum sections, cron scripts, and perhaps even the database. What now?
5) Now, you look for .php files that shouldn't be there, or altered php files that contains backdoors. Don't use the timestamps as a method of finding out whether a file was changed or not, as that can easily be tampered with as well. If the hackers weren't smart, they didn't change the timestamp to match the rest of the files. Sometimes, they also set the timestamp to a random date, where you perhaps, wasn't even near a computer. Such files should be checked.
6) You're not done yet, as some hackers change or add .htaccess files to make other extensions, often in subdirectories, executable as PHP. Meaning if you find a .htaccess file that shouldn't be there, it could contain a "php-handler" setting that all .jpg files in that directory should be executed as php, and the actual directory, could be new as well, but named something that could be a part of the original installation.
7) You've gone through almost everything, well, almost. There's also the php.ini file, where the setting auto_append_file appears to be the newest trick they're using. The setting appears to be "Off", even though it is set to be "0ff" (Zero f f), meaning it reads a file named "0ff" in /tmp/..
Reference: http://blog.sucuri.net/2011/12/malware-getting-called-from-php-ini.htmlAs you can see, it's often better to start with a fresh set of PHP files, and delete _everything_ from the HTTP directory.
First and always, you take
backup of the files, even if they're backdoored. It's a good learning experience, and it gives you insight into how the hackers work too, esp. if you study the access.log's which are often only deleteable by the root user, which are somewhat often left behind and not deleted.
The access.log is huge. Which is why you should always determine a point in time, where the attack may have occurred. Often a couple of hours if possible is best, and then you study the log, often for strange GET requests, or POST requests to files that shouldn't accept POST-requests at all, which may take time as well
Merry X-mas, I hope you enjoyed this info as these are most of the tricks I've seen used
General Certification : CPT Practical Submission
