The Case Of Misleading Timestamps

Recently, we had an .htaccess file show up in the SiteLock research queue. This isn’t particularly unusual, as .htaccess files are one of the more common files that an attacker will change to allow access to files or redirect users. In this case, the .htaccess file contained the following code:

On the surface, this is simply odd. It is not only denying access to files that end in php, php5, py, and phtml, which are all reasonable standard file extensions, but it also denies access to files that end in ‘suspected’. That’s certainly unusual, too. It makes sense to deny access to files that contain PHP (.php, .php5, and .phtml) and Python (.py) in places where you don’t want users to go, such as upload folders. However, there was no corresponding section that allowed access to specific files, such as an index.php that would be able to handle attempts to reach those locations. Another odd characteristic of this .htaccess file, for sure.

Based on experience, we already knew that this FilesMatch directive, specifically denying access to these five file extensions is bad, so there was no question that we’re looking at a file injection in the site. The only real question was “Have we found everything that was related to the injection?”

That meant painstakingly searching the customer files, which revealed that the .htaccess files were almost everywhere. So where do we start?

Starting The Investigation

The first step was to make sure we detected and removed the .htaccess files. Once that was done, we searched for and found some older 0-byte files. Files that are zero bytes in size are left behind by SiteLock’s SMART® product when it cleans the full contents of a malicious file. This gave us a starting point for looking for more malicious files.

The first interesting file we noticed was a zero-byte index.php file buried deep in the site’s Slider Revolution (RevSlider) plugin, but in an odd location:

wp-content/plugins/revslider/admin/includes/shortcode_generator/wpbakery/wpbakery

WPBakery is a page builder plugin for WordPress that has integrations with a variety of other plugins, including Slider Revolution. These integrations usually add a directory of their own, but the existence of a wpbakery directory nested within another wpbakery directory is unusual.

Examining the directory lead to the discovery of the empty index.php file along with another htaccess file:

wp-content/plugins/revslider/admin/includes/shortcode_generator/wpbakery/wpbakery

WPBakery is a page builder plugin for WordPress that has integrations with a variety of other plugins, including Slider Revolution. These integrations usually add a directory of their own, but the existence of a wpbakery directory nested within another wpbakery directory is unusual.

Examining the directory lead to the discovery of the empty index.php file along with another htaccess file:

Much like the first htaccess file, this one blocks access to all files ending in .php, .php5, and .phtml. However, it then allows access to index.php and system_log.php. Since index.php is currently zero bytes in size, we can assume that it was cleaned by SMART. The system_log.php file is a relatively common name for backdoors that hackers want to disguise and use as an access point. The combination of system_log.php and index.php as the only files that are allowed to be accessed is a good indication that this directory is entirely bad.

Aside from several similar instances throughout the site, the only other “interesting” location was the root directory. There were three zero-byte files in the document root. Additionally, there was an images directory that had one of the original malicious htaccess files.

The images/ Directory

Looking at the images/ directory, there was only a single .jpg file aside from the .htaccess file, not a whole lot to it really. But strangely enough, the modification date on the .jpg was in 1995.

If you’re not familiar with timestamps on files, there are three timestamps that the filesystem keeps track of. The first is the access time, which is the timestamp that the file was last accessed by another program. This gets updated every time the file is read. The second is the modify time, which is the last time that the file contents were changed. On Linux and Unix systems, the modify time is the default timestamp displayed by the ls command. Lastly, there is the change time, which is the last time the filesystem metadata was updated. This can be the time the file was created or the time the file permissions were changed.

For a file’s modification time to be dated in 1995, one of several things would have needed to happen. First, the file would have to have been uploaded to the website and never moved. Second, the file would have needed to have been moved as part of an archive that was preserving the timestamps on them all the time. Over a 26-year period, it’s unlikely that this would’ve been done every single time. Lastly, it is possible to use Linux commands or PHP functions to change the modification time to whatever we want. The touch command (and PHP’s touch function) allows the user to provide a date that will be used to set the access time or modification time of the file.

As such, we can view this 26-year-old timestamp as highly suspect. If we look at the history of this file, as viewed by our scans, the modify time has changed numerous times, ranging from 1995 to 2007 to 2012. Clearly, something was odd about this file.

Decoding The File

The next step is looking at the file content. “It’s a JPG file, though. What would be in there?” JPG files, as well as PNG and GIF files, are often used as containers for malware with the malicious code either directly embedded in the image or embedded in the metadata of the image. There are two commands that are available on almost every Linux system that can help us here: strings and cat.

The strings command pulls all the printable strings from a file that are four or more characters long and displays them. They aren’t necessarily malicious code, but it can make hidden code easier to see.

Similarly, the cat command simply dumps the file contents to the screen. With certain command-line options (in particular, the -v option), it will also turn non-printable characters into plaintext representations of them. For instance, the Ctrl-C character would be displayed as ^C.

On this file, however, you can imagine my surprise when the entire file was displayed and there was no image at all. It was a pipe-delimited file with three fields: an MD5 hash, a series of punctuation marks, and a long string of letters, numbers, plus symbols and forward slashes. That set of characters fits perfectly with the base64 character set, but when I attempted to decode it, I got back gibberish.

However, I felt confident that the long string was base64 text. The character set was right and while the output was gibberish, it included several characters that you don’t see if the output is compressed data.

Following that line of thought, my next step was to use str_rot13 before decoding the text. The str_rot13 function rotates the letters by 13 positions in the alphabet. This means that ‘C’ becomes ‘P’, and so on.

On decoding the string this time, I came face to face with the malware:

Even though this was encoded, a little work on my behalf, I was able to reveal its true nature.

It was an injector, pulling data from a remote site and injecting it into every web request that the site received.

Summary

Fortunately, SiteLock already has signatures for this type of injection malware and the customer site had already been cleaned of the malicious code in the PHP files. This “image file” was all that was left and while it contains malicious code, it is not active malware and SiteLock is able to detect and remove it.

As for the timestamps, they are one more item in the checklist of things to look for when investigating sites. Do they make sense? If not, then they may indicate an issue that prompts further investigation.

Want to learn more about misleading timestamps or other interesting types of malware that can harm websites? Follow Behind the Code today and get informative insights into malware and how they deceptively find their way into websites.

About The Author

Maarten Broekman has worked as a system administrator and systems engineer for over 25 years, primarily in the shared web-hosting space. One of the main concerns for web-hosting providers is being able to serve their customers’ websites as quickly and efficiently as possible. As a result, anything that detracts from performance needed to be examined closely and this is where his interest in malware and code analysis sprang from. For over a decade, finding, decoding, and removing malware (and automating that process) has been his primary focus.