The SessionManager IIS backdoor

Following on from our earlier Owowa discovery, we continued to hunt for more backdoors potentially set up as malicious modules within IIS, a popular web server edited by Microsoft. And we didn’t come back empty-handed…

In 2021, we noticed a trend among several threat actors for deploying a backdoor within IIS after exploiting one of the ProxyLogon-type vulnerabilities within Microsoft Exchange servers. Dropping an IIS module as a backdoor enables threat actors to maintain persistent, update-resistant and relatively stealthy access to the IT infrastructure of a targeted organization; be it to collect emails, update further malicious access, or clandestinely manage compromised servers that can be leveraged as malicious infrastructure.

In early 2022, we investigated one such IIS backdoor: SessionManager. In late April 2022, most of the samples we identified were still not flagged as malicious in a popular online file scanning service, and SessionManager was still deployed in over 20 organizations.

SessionManager has been used against NGOs, government, military and industrial organizations in Africa, South America, Asia, Europe, Russia and the Middle East, starting from at least March 2021. Because of the similar victims, and use of a common OwlProxy variant, we believe the malicious IIS module may have been leveraged by the GELSEMIUM threat actor, as part of espionage operations.

SessionManager: there’s yet another unwanted module in your web server

Developed in C++, SessionManager is a malicious native-code IIS module whose aim is to be loaded by some IIS applications, to process legitimate HTTP requests that are continuously sent to the server.

Such malicious modules usually expect seemingly legitimate but specifically crafted HTTP requests from their operators, trigger actions based on the operators’ hidden instructions if any, then transparently pass the request to the server for it to be processed just like any other request (see Figure 1).

As a result, such modules are not easily spotted by usual monitoring practices: they do not necessarily initiate suspicious communications to external servers, receive commands through HTTP requests to a server that is specifically exposed to such processes, and their files are often placed in overlooked locations that contain a lot of other legitimate files.

SessionManager offers the following capabilities that, when combined, make it a lightweight persistent initial access backdoor:

• Reading, writing to and deleting arbitrary files on the compromised server.
• Executing arbitrary binaries from the compromised server, also known as “remote command execution”.
• Establishing connections to arbitrary network endpoints that can be reached by the compromised server, as well as reading and writing in such connections.

We identified several variants of the SessionManager module, all including remains of their development environment (PDB paths) and compilation dates that are consistent with observed activity timeframes. This demonstrates a continuous effort to update the backdoor:

• V0: the compilation date of the oldest sample we identified (MD5 5FFC31841EB3B77F41F0ACE61BECD8FD) is from March 2021. The sample contains a development path (PDB path): “C:\Users\GodLike\Desktop\t\t4\StripHeaders-master\x64\Release\sessionmanagermodule.pdb”. This indicates the SessionManager developer might have used the public source code of the StripHeaders IIS module as a template to first design SessionManager.
• V1: a later sample (MD5 84B20E95D52F38BB4F6C998719660C35) has a compilation date from April 2021, and a PDB path set as “C:\Users\GodLike\Desktop\t\t4\SessionManagerModule\x64\Release\sessionmanagermodule.pdb”.
• V2: another sample (MD5 4EE3FB2ABA3B82171E6409E253BDDDB5) has a compilation date from August 2021, and a PDB path which is identical to the previous V1, except for the project folder name which is “SessionManagerV2Module”.
• V3: finally, the last sample we could identify (MD5 2410D0D7C20597D9B65F237F9C4CE6C9) is dated from September 2021 and has a project folder name set to “SessionManagerV3Module”.

SessionManager command and control protocol details

SessionManager hooks itself in the HTTP communications processing of the web server by checking HTTP data just before IIS answers to an HTTP request (see Figure 2). In this specific step of HTTP processing, SessionManager can check the whole content of the HTTP request from a client (an operator), and modify the answer that is sent to the client by the server (to include results from backdoor activities)

Commands are passed from an operator to SessionManager using a specific HTTP cookie name. The answer from the backdoor to an operator will usually be inserted in the body of the server HTTP response. If the expected cookie name and value format are not found in an HTTP request from a client, the backdoor will do nothing, and processing will continue as if the malicious module did not exist.

The specific HTTP cookie name that is checked by SessionManager is “SM_SESSIONID” in variants before V2 (excluded), and “SM_SESSION” after. Formatting the exact command names and arguments also depends on the backdoor variant:

• Before V2 (excluded), most of the commands and associated parameters are all passed as a value^[1] of the required SessionManager HTTP cookie, such as for a file reading command:
  1	Cookie: SM_SESSIONID=ReadFile–afile.txt

  The remote execution and the file writing functionalities require additional command data to be passed within the HTTP request body.

• After V2 (included), only the command name is passed as a value of the required SessionManager HTTP cookie. Command parameters are passed using names and values^[2] of additional cookies, while some commands still require data to be passed within the HTTP body as well. For example, the HTTP cookies definition for a file-reading command looks like this:
  1	Cookie: SM_SESSION=GETFILE;FILEPATH=afile.txt;

The results of executed commands are returned as body data within HTTP responses. Before V2 (excluded), SessionManager did not encrypt or obfuscate command and control data. Starting with V2 (included), an additional “SM_KEY” cookie can be included in HTTP requests from operators: if so, its value will be used as an XOR key to encode results that are sent by SessionManager.