The SOC files: Chasing the web shell

Web shells have evolved far beyond their original purpose of basic remote command execution, and many now function more like lightweight exploitation frameworks. These tools often include features such as in-memory module execution and encrypted command-and-control (C2) communication, giving attackers flexibility while minimizing their footprint.

This article walks through a SOC investigation where efficient surface-level analysis led to the identification of a web shell associated with a well-known toolset commonly associated with Chinese-speaking threat actors. Despite being a much-discussed tool, it is still used by the attackers for post-exploitation activities, thanks to its modular design and adaptability. We’ll break down the investigative process, detail how the analysts uncovered the web shell family, and highlight practical detection strategies to help defenders identify similar threats.

Onset

It’s early Monday morning, almost 4am UTC time, and the apparent nighttime calm inside the SOC is abruptly interrupted by an alert from our SIEM. It indicates that Kaspersky Endpoint Security’s heuristic engine has detected a web shell (HEUR:Backdoor.MSIL.WebShell.gen) on the SharePoint server of a government infrastructure in Southeast Asia, a warning that no SOC analyst would want to ignore.

The night shift team springs into action, knowing that the web shell could be the beginning of much worse activity, and that every second counts. Initial analysis of the telemetry suggests that the attackers exploited the affected web server, either by taking advantage of another web shell or a command injection vulnerability.

From the listing above, where the process tree that triggered the first detection is reported, it is possible to observe an attempt to deploy a web shell disguised as a 404 page. The certutil utility was used to download the ASPX payload, which was hosted by abusing Bashupload. This web service, which is used to upload files from the command line and allows one-time downloads of samples, is no stranger to being abused as an ingress tool transfer technique.

As is common practice, the command has been slightly obfuscated by using escape characters (such as ^ and “) to break up the keywords “certutil” and “urlcache” in order to bypass basic detection rules based on simple pattern matching.
As part of our MDR service, we are required to operate within pre-established boundaries that are tailored to the customer’s business continuity needs and risk tolerance. In this case, the customer retains ownership of decisions regarding sensitive assets, including the isolation of compromised hosts, so we can’t instantly block the attack and must continue to observe and perform a preliminary threat analysis.

A manual reconnaissance and discovery activity by an operator starts appearing, and despite the tension, an occasional typo (“localgorup”) manages to draw a smile:

Aftermath

To gain system privileges, the threat actors used several variants of the well-known Potato tools, either as memory-only modules or as standalone executables:

To bring standalone binaries into the environment, the attackers again used the Bashupload free web service, which we saw in the initial web shell alert. Of all the tools, the GodPotato standalone binary ultimately succeeded in gaining system privileges.

With elevated access, the attackers moved on to domain trust enumeration, mapping relationships between domains and identifying potential targets for lateral movement. But let’s get back to the main question: What kind of web shell are we dealing with here?

Identifying the threat

Unfortunately, we were unable to retrieve the web shell sample used during the initial access phase. However, starting with the privilege escalation phase, several .NET modules began to appear in the memory of the IIS worker process ( w3wp.exe), ranging from popular tools like Potato to other lesser known ones. One set of libraries in particular caught our attention, so we decided to investigate further by performing a manual inspection.

Fortunately, the libraries were not obfuscated and lent themselves to quick static analysis:

Example of a library detected in IIS process memory (0x0B593115C273A90886864AF7D4973EED)

In the image above, if you look at the orange method names in the Assembly Explorer on the left, you can observe some peculiarities that can be used to identify similar samples. Although many of the methods names are very generic, there is one that is quite unique, EnjsonAndCrypt. A quick Google search of this name yields no results, which means it may be sample-specific.

The getExtraData method is also interesting: although it has a non-specific name, there is a sequence of bytes [126, 126, 126, 126, 126, 126] that is used to parse key:value pairs whose value is base64 encoded:

The “extraData” structure example

Threat actors need to use the same byte sequence if they want to maintain backward compatibility across different implant versions, but since it is also very generic, we should combine both indicators, the getExtraData name and this byte array, to define a sufficiently precise detection condition that can be used in conjunction with EnjsonAndCrypt to create a detection rule.

Uncovering modules and variants

By feeding our newly created YARA rule to a multi-AV platform such as VirusTotal, we can identify additional samples that differ from those observed in the targeted infrastructure. It is worth noting that some of these have a poor detection rate:

Poorly detected BasicInfo.dll (32865229279DE31D08166F7F24226843) sample

Below are the most common names of libraries that match the rule:

Module filenames

Those familiar with the toolkit used may have already identified it by looking at these filenames, but if not, it is also possible to infer the relationship by simply pivoting to the samples available on VT:

Sample FC793D722738C7FCDFE8DED66C96495B relations on VT

Behinder, also known as Rebeyond, Ice Scorpion, 冰蝎 (Bīng xiē), is known as a cross-platform web shell designed to be compatible with most popular web servers running PHP, Java or ASP.NET as in our investigation. Although the web shell sample itself is very lightweight and somewhat basic, the tool includes a powerful GUI for operators with numerous capabilities including loading additional modules and giving them full control over compromised environments.

Its built-in AES-encrypted communication allows threat actors to maintain stealthy control over a compromised web server, often bypassing traditional network detection mechanisms, and its modular, flexible nature allows malicious actors to use it as a base for customization even though it is only available as a pre-built tool on GitHub. Moreover, the presence of several step-by-step Chinese language tutorials on CSDN (Chinese Software Developer Network) makes it widely accessible to opportunistic bad actors.

The bigger picture

Taking a step back, the relationship between the memory artifacts observed on the customer’s server during the post-exploitation phase and the web shell source code becomes evident. The web shell is not just a foothold, it’s a fully functional backdoor that facilitates encrypted communication with the operators’ infrastructure, allowing them to call built-in or custom-loaded libraries, deploy additional tools, conduct reconnaissance and exfiltrate data while remaining hidden:

ASPX web shell side by side with .NET payload

Although the Behinder web shell has been widely discussed in the past, especially the PHP and JSP variants, it is still a current and evolving cyberweapon. Even if attackers make mistakes or act carelessly by reusing the same encryption keys or exhibiting the same patterns, we can’t afford to let our guard down. In the incident described in this article, if we had not taken the time to dig deeper into the artifacts observed in memory, we likely would have missed the toolkit altogether.

Threats evolve quickly, and signature-based malware detection only catches what we already know. Underestimating the potential of memory-based payloads can lead to a false sense of security. Teams may assume that if they haven’t detected any suspicious files, they are safe, when in fact threats may be actively operating in memory.

For SOC teams, continuous learning, proactive threat hunting, and refining detection techniques are essential to staying ahead of adversaries.

Happy hunting and see you on the next mission!

YARA rule

Indicators of compromise

Payloads
EF153E1E216C80BE3FDD520DD92526F4                          god.exe
B8A468615E0B0072D2F32E44A7C9A62F                          BadPotato.dll
B5755BE4AAD8D8FE1BD0E6AC5728067B                          SweetPotato.dll
578A303D8A858C3265DE429DB9F17695                         BasicInfo.dll
EA19D6845B6FC02566468FF5F838BFF1                          FileOperation.dll
CD56A5A7835B71DF463EC416259E6F8F                          Cmd.dll
5EA7F17E75D43474B9DFCD067FF85216                          Echo.dll

File paths

C:\ProgramData\DRM\
C:\Users\Default\Videos\