Hunting Webshell Activity

Posted on October 9, 2022 by m365guy Leave a comment

A Webshell is a malicious script that an attacker can drop on a webserver to launch additional attacks and establish persistence. Before a Webshell is dropped, it is usually the case that an attacker has successfully obtained SYSTEM level access on the targeted server in order to upload the Webshell. A Webshell may provide a set of functions to execute or a command-line interface on the system that hosts the Web server.

Over the years, we have seen attackers leveraging Webshells to establish persistence on servers with the likes of Exchange or IIS for example. Here we have a few examples of APT groups using Webshells:

NOTE: This blog post will be primary focusing on Webshells that are associated with Exchange and IIS.

**Source:** https://attack.mitre.org/techniques/T1505/003/

Functionality of a Webshell

There is a lot of confusion in general about the functionality of a Webshell. In overall, the functionality ‘depends’ on each individual Webshell. However, there are folks out there having the perception that it can only be used to execute commands on a host. This is a bit inaccurate, which is why I want to kick-off with using real examples. I’ve decided to spin up a lab and will demonstrate the functionalities of two Webshells.

ASPXSPY – Webshell

The first example will be covering the ASPXSPY Webshell. We are going to explore all the different capabilities that it has and map it to the MITRE ATT&CK framework.

File and Directory Discovery – T1083

At this example, we can see that there is a ‘File Manager’ functionality which can be used to explore files and directories. We can explore literally every file and even more important. Majority of these files can be downloaded as well, because this Webshell has this functionality.

Stage Capabilities – T1608

An attacker will usually stage its tools somewhere in a particular directory. This Webshell has an ‘upload’ feature, which allows an attacker to upload files to the target server. As an example, we are going to upload SharpHound to the C:\Temp directory.

Here we can see that SharpHound.exe has now been on disk and staged in the C:\Temp directory.

Command and Scripting Interpreter – T1059

An attacker may abuse command and script interpreters to execute commands, scripts, or binaries. This looks a bit like this. In simple terms, the attacker has like a command prompt in a web browser.

In the previous step, we uploaded SharpHound.exe in the C:\Temp directory. We can now use this CmdShell functionality to execute SharpHound directly via our Webshell.

Process Discovery – T1057

List of running processes can be enumerated through this Webshell.

System Service Discovery – T1007

List of all the system services that are running or stopped can be enumerated through this Webshell.

Account Discovery – T1087

List of local as well as Domain accounts can be enumerated through this Webshell. This includes information about whether the account is disabled, the SID of the account, and more.

Network Service Discovery – T1046

This Webshell contains the functionality to perform port scanning.

DevilzShell – Webshell

This is another publicly available Webshell which contains similar functionalities as the previous one.

File and Directory Discovery – T1083

All the files and directories can be accessed.

The option to download files exists as well.

Stage Capabilities – T1608

Tools can be uploaded and staged in certain directories. As example, we will be uploading ProcDump to the C:\Temp directory.

We can now see ProcDump in the C:\Temp directory.

Command and Scripting Interpreter – T1059

We have uploaded ProcDump in the C:\Temp directory. Let’s use ProcDump to dump the LSASS process now.

Hunting Exchange Webshell Activity

This section will cover in detail on how to hunt for Exchange Webshell activity. We will be primary focusing on the IIS logs and the traditional Windows Security event logs.

IIS Logs

First, we should consider looking at the IIS logs. This is often overlooked when it comes down to hunting Exchange Webshell activity. Let’s start with the ASPXSPY Webshell first.

ASPXSPY Webshell

2022-10-08 17:18:54

A GET request was made from 10.0.0.5 (DC.contoso.com) to 10.0.0.11 (Exchange.contoso.com) which is the internal IP address of the Exchange server. The exact URL that was visited is hxxps://exchange.contoso.com/aspnet_netclient/4_0_30319/ and the URI stem that was accessed is /aspnet_netclient/4_0_30319/ASPXspy2.aspx

2022-10-08 17:18:54 10.0.0.11 GET /aspnet_netclient/4_0_30319/ASPXspy2.aspx - 443 - 10.0.0.5 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.34 https://exchange.contoso.com/aspnet_netclient/4_0_30319/ 200 0 0 4

2022-10-08 17:18:57

A POST request was made from 10.0.0.5 (DC.contoso.com) to 10.0.0.11 (Exchange.contoso.com) which is the internal IP address of the Exchange server. The exact URL that was visited is hxxps://exchange.contoso.com/aspnet_netclient/4_0_30319/ and the URI stem that was accessed is /aspnet_netclient/4_0_30319/ASPXspy2.aspx

2022-10-08 17:18:57 10.0.0.11 POST /aspnet_netclient/4_0_30319/ASPXspy2.aspx - 443 - 10.0.0.5 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.34 https://exchange.contoso.com/aspnet_netclient/4_0_30319/ASPXspy2.aspx 200 0 0 4

In the IIS logs, we are able to see all the requests that were made. However, as we can see in the logs. All of these requests came from internal IP addresses. What if the Exchange server had OWA exposed to the internet? This can be captured as well in the IIS logs!

2022-10-08 17:47:42

A GET request was made from 20.106.209.84 (External IP) to 10.0.0.11 (Exchange.contoso.com) which is the internal IP address of the Exchange server. The exact URL that was visited is hxxps://20.62.174.61/aspnet_netclient/4_0_30319/ and the URI stem that was accessed is /aspnet_netclient/4_0_30319/ASPXspy2.aspx

The URL contains the external IP address of the server, which is something to look out for. Since this indicates that the server was public facing to the internet and a request from outside was made to access the Webshell.

2022-10-08 17:47:42 10.0.0.11 GET /aspnet_netclient/4_0_30319/ASPXspy2.aspx - 443 - 20.106.209.84 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.37 https://20.62.174.61/aspnet_netclient/4_0_30319/ 200 0 0 4

2022-10-08 17:47:44

A POST request was made from 20.106.209.84 (External IP) to 10.0.0.11 (Exchange.contoso.com) which is the internal IP address of the Exchange server. The exact URL that was visited is hxxps://20.62.174.61/aspnet_netclient/4_0_30319/ and the URI stem that was accessed is /aspnet_netclient/4_0_30319/ASPXspy2.aspx

Typically, a POST request indicates that the Webshell was utilized to perform some action. It’s hard to figure out based on the current logs what exactly was done though.

2022-10-08 17:47:44 10.0.0.11 POST /aspnet_netclient/4_0_30319/ASPXspy2.aspx - 443 - 20.106.209.84 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.37 https://20.62.174.61/aspnet_netclient/4_0_30319/ASPXspy2.aspx 200 0 0 5

DevilzShell

DevilzShell is not OpSec friendly since every action that we are performing will generate a new GET request that contains data in the URL. This makes it easier to figure out what commands or actions were initiated.

2022-10-08 16:21:18

A GET request was made from 10.0.0.5 (DC.contoso.com) to 10.0.0.11 (Exchange.contoso.com) where the CmdShell functionality was used to execute ProcDump from the C:\Temp directory to dump the LSASS process.

2022-10-08 16:21:18 10.0.0.11 GET /aspnet_netclient/4_0_30319/devilzShell.aspx dir=C:\ 443 - 10.0.0.5 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.34 https://exchange.contoso.com/aspnet_netclient/4_0_30319/devilzShell.aspx?dir=C%3A%5CTemp%5C&cmd=procdump.exe+-ma+lsass.exe+lsass.log&btnCommand=Execute 200 0 0 10

2022-10-08 16:36:55

A GET request was made from 10.0.0.5 (DC.contoso.com) to 10.0.0.11 (Exchange.contoso.com) where the CmdShell functionality was used to execute SharpHound from the C:\Temp directory to enumerate information within AD.

2022-10-08 16:36:55 10.0.0.11 GET /aspnet_netclient/4_0_30319/devilzShell.aspx dir=C%3A%5CTemp%5C&cmd=sharphound.exe+-d+contoso.com&btnCommand=Execute 443 - 10.0.0.5 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.34 https://exchange.contoso.com/aspnet_netclient/4_0_30319/devilzShell.aspx?dir=C:\Temp\ 200 0 0 48702

As we can see in the IIS logs. It does provide useful data that we can use to hunt for Exchange Webshell activity. Most folks often ignore this and directly go to the Windows security event logs. However, you are missing lots of useful stuff if you’re doing this.

Suspicious IIS Worker Process (w3wp)

An IIS Worker Process (w3wp.exe) handles the web requests sent to the IIS web server for the configured IIS application pool. An application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Every time when we are seeing w3wp spawning suspicious child processes such as cmd.exe, powershell.exe, etc. We should mark this as suspicious, since it’s very unlikely that it should do that.

Here is an example when we are executing SharpHound directly through the Webshell. We can recognize the parent process w3wp.exe that is spawning SharpHound.exe

Windows Security Event Logs

Since we know that once we are seeing w3wp process is spawning suspicious child processes like cmd.exe, nltest.exe, net.exe, powershell.exe, and so on. We can start hunting for it. When it comes down to Windows Security event logs. The best way to hunt for this would be to have event ID 4688 with command-line being enabled.

Another example where we can see w3wp.exe spawning cmd.exe to enumerate all the domain trusts via nltest.exe

Last example that we’re going to discuss is w3wp.exe spawning powershell.exe and then importing the Active Directory PowerShell module to enumerate all the users and writing the output to disk.

Sysmon

This is more of a bonus section but if Sysmon is in place. We can start hunting for suspicious w3wp process spawning child processes as well as other activities.

Another example is to look for w3wp.exe spawning cmd.exe. At this example, we were spawning a child process cmd.exe that invokes the nltest utility to enumerate all the domain trusts.

At this example, we have w3wp.exe spawning powershell.exe to enumerate all the users within AD and then write the output to disk.

As we discussed in this blog post. Webshells may have the functionality to do port scanning. When we are scanning a target via our Webshell, and it turns out that our target has a port open. Sysmon will generate an event for this.

This will generate something like this:

We have also discussed that it is possible to upload files via a Webshell. In this example, we can see that when we are uploading AdFind.exe to the C:\Temp directory via our Webshell. The process that initiated this action has been w3wp.exe