I have a Debian 7 VPS that runs Nginx, PHP5-FPM and MariaDB. This server runs a couple of WordPress installations, phpMyAdmin and Roundcube Webmail. One is my personal blog running WP 3.9.1 and another runs the latest WP trunk version 4.0-beta1 for development purposes.

I am the only person to have SSH access as well as wp-admin access. Root login via SSH is disabled and so is logging in using passwords.

Today I found the following files inside /tmp.

# ls -l /tmp
total 8
-rw------- 1 www-data www-data 1551 Jul  9 03:22 php9Lg8Js
-rw------- 1 www-data www-data 1551 Jul  9 03:23 phpQNsW36

stat output for the files

# stat /tmp/phpQNsW36
  File: `/tmp/phpQNsW36'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337356      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:23:03.000000000 +0530
Modify: 2014-07-09 03:23:03.000000000 +0530
Change: 2014-07-09 03:23:03.000000000 +0530
 Birth: -

# stat /tmp/php9Lg8Js
  File: `/tmp/php9Lg8Js'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337355      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:22:27.000000000 +0530
Modify: 2014-07-09 03:22:27.000000000 +0530
Change: 2014-07-09 03:22:27.000000000 +0530
 Birth: -

Both these files contain the same base64 encoded PHP code. I replaced the eval() with print() to find it was a PHP shellcode which emails the HTTP_HOST and REQUEST_URI to two Gmail addresses as well as prints an input box for the exploiter to run shell commands and upload files.

I can post this code here if it required for analysis and if I am allowed to do so.

Searching the Nginx access log based on the timestamp I could only find the following POST requests. - - [09/Jul/2014:03:22:27 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)" - - [09/Jul/2014:03:23:03 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"

This server does NOT run Joomla

My understanding is that a BOT was randomly scanning the web for Joomla installations with the JCE exploit. It POSTed some file content and closed the request (Nginx status 499 - Client closed request). This POSTed content ended up with a tmp_name in the /tmp directory as the request did not complete.

Is this correct?

What else should I check to see if this was just a failed attempt or something more than that?

Let me know if more information is required.

2 Answers 2


Your assessment sounds correct. It's impossible, of course, to say that your server has not been compromised, but by default, PHP receives all the data before executing the script, so it writes file uploads to /tmp and provides that filename to the running script.

If your /tmp is mounted with atime enabled, the fact that atime==mtime is reassuring. If the attacker found a way to execute those scripts after their upload (LFI vulnerability, for example), that would change the atime, so the fact that it wasn't updated indicated they weren't executed (again, if atime support is enabled on /tmp).


Did you say something about running phpMyAdmin? Is its directory standard and/or publicly available? (even if [you think] nobody has the password).

phpMyAdmin is usually an attack vector on web and database servers, and its existence is widely searched for on automated crawlers.

Is the server compromised? As David said, we can't tell whether it was or not, but in a good configuration, the user running nginx shouldn't have access to more than it really needs (the Principle of least privilege), and permissions should've been set accordingly - that should contain most damages, in the event your server executes arbitrary PHP code.

You probably want to consider any passwords set in config files as being compromised.

Timestamps are easy to change. While they are likely a good indicator, don't rely too much on them. Always search the logs thoroughly.

  • Yes, timestamps can be changed... So if mtime=atime, that's positive, but not definitive. Commented Oct 13, 2022 at 20:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .