This question already has an answer here:

This is my first question here on the IT Security section of Stack Exchange, so if there is any problems with my question I apologize.


  • Suddenly Google says that my website contains Malware!

  • When I enter my website my antivirus program tells that a Trojan has been blocked and removed! The Trojan is categorized as a (Trojan:JS/Quidvetis.A) by the antivirus program, and if you look the Trojan up, it says that it currently is harmless and have no effect!

As Google said, yes my website does contain some new weird files which potentially could be Malware!

I found a file called 46ZqQVmc.php and I found it at the following path ROOT/css/46ZqQVmc.php I don't know at all how the file have gotten there!

Also inside my index.php I found this piece of code!

Edit: gowenfawr made me aware that some browsers, block the site because of the following code, so I changed it to pictures of the code as like gowenfawr said.

Code Before Click here to see the image in fullscreen

When the PHP file is processed that exact piece of code, becomes the following!

Code After Click here to see the image in fullscreen

Again I have no idea how my index.php file got edited!


  • Host: - I have contacted my host but there response was that my website didn't contain any Malware!
  • FTP Client: Filezilla - I am aware that Filezilla strores passwords, etc, as plain text!
  • Access: I'm the only person have all the passwords and access to the website itself!
  • Currently I have no file uploading or comment sections and things like that on the website itself!


Basically my question is, how does Malware get uploaded to my website? I know this is a really abstract question, but I'm asking if anybody have any kind of idea of how the Malware got uploaded or created on my website and also how my index.php file got edited!

I think that somehow someone have got the passwords, etc. to my website so that they can enter it and edit files and also upload files of course, though I have no idea how they've accomplished such thing.

Bottom line, my question is again, is there anybody that have any idea of how that file can have been uploaded to my website and also how my index.php file can have gotten edited!


If there is any more information you need to various things, just ask in a comment and I can add the information.


  • I don't use Wordpress, everything is custom coded by myself.
  • I use SQL for stuff like blogs and other content! (Though I have another website which functions like a File Browser for Notes, which uses no SQL at all, and that website is infected with this exact same thing as well)
  • I don't use Prepared Statements in MySQLi yet! (That could be the problem somehow, but I'm going to use them from now on)
  • My programming experience is 7 years and I'm self-taught, my main programming languages are C++, Java & C, my experience with PHP is only 1-2 years.

marked as duplicate by Adi, Rory Alsop Sep 16 '13 at 21:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Tell us more about what you have on your website. Do you have any platforms like Wordpress installed? Is it all custom PHP code you wrote yourself? How experienced are you (or whoever the author is) at writing PHP or any other language? – Kitsune Sep 16 '13 at 19:40
  • The code you've posted is sufficient to make my work web browser refuse to load it - if you want people to see your question, I recommend replacing your code blocks with images (e.g., .gif/.png) of the code. – gowenfawr Sep 16 '13 at 20:44
  • @Kitsune look at edited question. – Vallentin Sep 16 '13 at 20:44
  • @gowenfawr I've done as you suggested. – Vallentin Sep 16 '13 at 21:04
up vote 4 down vote accepted

Short version:

  1. However it got there, it's there. Your first step should be to contain the damage. I recommend setting up a temporary "site maintenance" page and setting your site to serve that, immediately, while you figure this out. Otherwise you'll get more blacklisted as the stuff stays out there.
  2. Congratulations, you put malware on Security.StackExchange. U R HAKR! More seriously, the amount that you posted is enough to trigger my web gateway's antivirus (it calls it EXP/JS.Expack.GQ) so I and presumably other people can't even read your question. (I'm posting this through a separate system because I was curious). If you want people to see your question, I recommend replacing your code blocks with images (e.g., .gif/.png) of the code.
  3. To your original question, the attacker probably abused a php script on your system to upload a command processor, and then used that command processor to insert the obfuscated code that you found. It's probably lots of other places too, not just index.php. You're going to need to revert to backup or otherwise recover your site before you can get un-blacklisted by Google.

Long version (or, Incident Recovery When You're the Watering Hole):

This type of code is consistent with what's called a "Watering Hole" attack - the attacker places attack code on web pages hosted by an innocent system. Web users innocently browse to your innocent system, and end up downloading malware from the hiddden iframe that the attacker put on your site.

Any method of compromising a host can be used to initiate a Watering Hole attack, but (IMHO) the most common is vulnerable web server scripts. Wordpress is particularly prone to being kicked over; a site I worked got bit by the Tim Thumb fiasco. Such attacks find some script on the site dumb enough to write a script to the site itself, and the attackers then execute the script they just uploaded in order to make changes throughout the site.

These attacks should be responded to with a combination of file and log timeline forensics. You have a file 46ZqQVmc.php that seems suspicious - what's the timestamp on that file? How does it compare to the timestamp on the index.php that was updated? How many other files in your web root have modification times similar to those two files? You can find a number of other files compromised in the same way using that correlation.

With those timestamps, take a look at your logs. Who hit your web site at the time that the 46ZqQVmc.php file showed up? What URI did they hit? That might tell you the script that was abused in order to upload the file. If my experience is any indicator, you can then find hits to the uploaded PHP file that correlate time-wise with the file modification of index.php and any other hacked files.

Once you've correlated file times with web logs, you've also learned the IP address(es) of your attacker. Now go through the logs and look for everything they did. You might find references to other files and URIs.

Your end goal in all this is to identify the file they abused to gain access to your system. In my case, they uploaded an image file with PHP in it, and when they hit it from a web browser they could upload PHP programs as part of the HTTP request and it would run it for them. They took advantage of a script already on the server called "thumb.php" to do this. You need to find what script of yours they took advantage of so that you can remove or update it to remove the security hole.

Your cleanup will consist at a minimum of closing the hole they used to get in, and removing the code that they injected into all your files (like index.php). Once you've done all that, take down your maintenance page, scan yourself with Sucuri, notify Google to scan you.

Traditional wisdom is that there is no such thing as a cleaned system, that the only way to be sure you're secure is to identify the root cause, and then build a new system with that corrected and restore from known good backups. That's not realistically possible for many people; they don't have backups at all. The good-ish news is that, if you were in fact hit in the manner I described, the attacker probably didn't bother to try and expand their compromise. They probably didn't elevate to root privileges, modify system files, or grab password hashes. (You should change all your passwords anyway, but...) In a limited scope breach like this, the limited measures I've described may be good enough.

You should also consider additional restrictions once you've cleaned up - file integrity monitor like AIDE, PHP lockdown to disable unnecessary and dangerous functions, restrictive file permissions to block the web server writing to the web root. It's all dependent on what web apps you're running, look for hardening guides.

Good luck.

  • Very good answer indeed. Could you mention bit more about the linux open source tools for Files Integrity checking, Malware scan tools, and scanning uploaded files to check if it contain any suspicious content in the file meta (before its used or executed by the attacker). – Muhammad Hannan May 30 at 0:21

The Trojan is categorized as a (Trojan:JS/Quidvetis.A) by the antivirus program, and if you look the Trojan up, it says that it currently is harmless and have no effect!

Er... not really. It's a file related to the Blackhole exploit kit, which is by no means harmless. If you browse a site infected with this and you don't have an up-to-date browser with up-to-date plugins, you're going to get infected. What exactly you get infected with depends on who is operating the exploit, who they're sending their install traffic to, who their partners are, what country you're coming from, what browser you use, and even random chance. If your client machine is not completely patched, it may already be housing a variety of trojans, rootkits, etc. that your AV hasn't been able to detect. (AV is not at all reliable.)

I have contacted my host but there response was that my website didn't contain any Malware!

A typical useless reaction; often they don't know what they're looking for and/or the infection can be stealthy (eg hiding and not appearing on the page again if accessed through the same IP address).

FTP Client: Filezilla - I am aware that Filezilla strores passwords, etc, as plain text!

FTP credential compromise is by far the most common cause of server hacks at the moment and so that is where I would start.

Scan your machine and any others that have been used to access the site with multiple AVs (because AV is unreliable), and if you find any infections take the opportunity to nuke it from orbit (install a fresh Operating System—because AVs' virus removal capabilities are massively unreliable).

Then change account passwords, wipe everything on the server and restore from backup, and in future use SFTP. (FTP is an archaic protocol that passes your passwords to the server completely unencrypted. This is a super-bad idea. There is no reason still to be using it in this century.) Also consider replacing Filezilla, since its authors sadly started bundling adware with it recently.

It is possible that the compromise was caused by an application vulnerability, but the FTP route is by far the more common for this kind of defacement so that is definitely where I would start. You should make sure that the OS service user that runs the PHP scripts (eg apache, nobody etc) does not have write access to the index.php file and css directory. If that is the case then even an execute-arbitrary-code exploit on the application wouldn't have been able to write the file and so it must have been FTP. If, on the other hand, you 777d the directory, or ifthe service user is the same as your administrative user, then you don't get that guarantee.

General background: How do I deal with a compromised server?

  • Thanks for this great explained answer, sadly for the SFTP, does not support that, damn. But again thanks for the answer I will change all passwords, and get a new FTP Client! – Vallentin Sep 16 '13 at 20:52
  • 1
    Wow, are deeply lame! :-( – bobince Sep 16 '13 at 20:56
  • Good answer, but will be nice and more helpful if you provide commands to disable write permissions for apache to index.php (one file, directory(ies), or all .php files). – Muhammad Hannan May 30 at 0:27

Does your site use a database connection? Do you work with http posts/gets that get used as variables for SQL queries?

Maybe SQL injection was the source of your injection. SQLi can go as far as root access to a webserver.

If you use SQL queries in your PHP code maybe take a look at the owasp top 10 for injection attacks. There's a lot of useful free information there!

  • Yes I do use SQL, but really, is it possible to edit/add code to my index.php and adding a file to the website, just by performing a SQL Injection? – Vallentin Sep 16 '13 at 20:55
  • Yes, that could have been the case. However above are already really detailed far more likely scenarios explained. But in the end even if you fix all of them and blindely post HTTP POST/GET Variables in your sql queries it might just be a matter of time till you get attacked successfully again. Do yourself a favour and read up on input validation and SQLi. – Sebastian B. Sep 17 '13 at 12:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.