Payload в реестре Windows: артефакты persistence и что проверять при расследовании

Реестр Windows — не только хранилище конфигурации, но и удобная среда для размещения исполняемого payload. Атакующий записывает shellcode в значение типа REG_BINARY, а на этапе исполнения считывает его обратно в память и запускает. Такой подход не оставляет файлов на диске, усложняет статический анализ и позволяет обойти часть сигнатурных средств защиты.

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

Механика: запись и чтение payload​

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

Фаза записи​

Атакующий открывает ключ реестра с правом KEY_SET_VALUE и записывает массив байтов shellcode как значение типа REG_BINARY. На уровне WinAPI это выглядит так:

// Открытие ключа
RegOpenKeyExA(HKEY_CURRENT_USER, "Control Panel", 0, KEY_SET_VALUE, &hKey);

// Запись payload как REG_BINARY
RegSetValueExA(hKey, "ValueName", 0, REG_BINARY, pShellcode, dwShellcodeSize);

// Закрытие дескриптора
RegCloseKey(hKey);

Ключ и имя значения выбираются произвольно. Часто используются имена, имитирующие легитимные параметры системы, чтобы не привлекать внимание при беглом осмотре.

Фаза чтения и исполнения​

Второй компонент (или тот же процесс на следующем этапе) читает данные обратно:

// Чтение payload из реестра
RegGetValueA(HKEY_CURRENT_USER, "Control Panel", "ValueName",
             RRF_RT_ANY, NULL, pBuffer, &dwBytesRead);

После чтения shellcode размещается в памяти через VirtualAlloc, права страницы меняются на исполняемые через VirtualProtect, и создаётся поток через CreateThread. Это стандартная цепочка для любого shellcode-раннера, независимо от источника данных.

Почему реестр привлекателен для атакующего​

Преимущество	Пояснение
Отсутствие файла на диске	Payload не появляется в файловой системе, что обходит файловые сканеры
Атомарность записи	Значение записывается одной операцией, нет временного файла
Доступность из user-mode	Не требуются привилегии администратора для записи в HKCU
Переживание перезагрузки	Данные в реестре сохраняются между сессиями
Маскировка под конфигурацию	REG_BINARY-значения выглядят как бинарные настройки приложения

Распространённые locations для хранения payload​

Атакующие выбирают ключи, которые редко проверяются вручную и не вызывают подозрений:

• HKCU\Control Panel — содержит множество бинарных значений легитимных приложений (темы, настройки мыши, клавиатуры). Дополнительное REG_BINARY-значение легко теряется среди них.
  
• HKCU\Software\<Vendor>\<Product> — имитация настроек несуществующего или реального ПО.
  
• HKLM\SOFTWARE\<Vendor> — требует прав администратора, но выглядит ещё более легитимно.
  
• HKCU\Software\Classes — используется для COM-объектов и ассоциаций файлов; payload может быть привязан к механизму автозапуска.
  

Размер значения — косвенный индикатор. Легитимные бинарные настройки обычно занимают десятки или сотни байтов. Shellcode даже минимального payload начинается от нескольких сотен байтов, а полноценный — от нескольких килобайт.

Артефакты для детектирования​

События Sysmon​

Sysmon (Event ID 12, 13, 14) логирует создание, изменение и удаление ключей и значений реестра. Для поиска payload в реестре релевантны:

• Event ID 13 (Registry value set) — фиксирует запись значения. Обращайте внимание на:
  
  • Тип данных REG_BINARY с размером > 512 байт
    
  • Запись в нетипичные ключи (Control Panel, Software\Classes)
    
  • Процессы, которые обычно не пишут в реестр (например, cmd.exe, powershell.exe, нестандартные исполняемые файлы)
    

EDR-телеметрия​

Большинство EDR-платформ отслеживают цепочку RegSetValueEx → RegGetValueEx → VirtualAlloc → VirtualProtect → CreateThread. Если один процесс записывает бинарные данные в реестр, а затем другой (или тот же) читает их и исполняет — это сильный индикатор.

Энтропия содержимого​

Shellcode, даже обфусцированный, обычно имеет высокую энтропию (близкую к максимуму для зашифрованных данных). Легитимные бинарные настройки (иконки, курсоры, палитры) имеют более низкую и структурированную энтропию.

Поведенческие паттерны​

Паттерн	Что искать
Запись REG_BINARY > 1 КБ в HKCU	Процесс-источник, время, родительский процесс
Чтение REG_BINARY + последующий VirtualAlloc	Один процесс выполняет обе операции
VirtualProtect с переходом в PAGE_EXECUTE_READWRITE	Классический индикатор shellcode-инъекции
CreateThread на адрес, не принадлежащий модулю	Поток исполняет код вне загруженных PE-образов

Что проверять при расследовании​

Шаг 1: Идентификация подозрительных значений​

Экспортируйте ветки реестра и проанализируйте REG_BINARY-значения:

## Поиск REG_BINARY значений размером более 512 байт в HKCU
Get-ChildItem -Path "HKCU:\Control Panel" -Recurse | ForEach-Object {
    $key = $_
    $key.GetValueNames() | ForEach-Object {
        $val = $key.GetValue($_, $null, 'DoNotExpandEnvironmentNames')
        if ($val -is [byte[]] -and $val.Length -gt 512) {
            [PSCustomObject]@{
                Key   = $key.PSPath
                Name  = $_
                Size  = $val.Length
            }
        }
    }
}

Аналогичный поиск стоит провести по HKCU:\Software и HKLM:\SOFTWARE.

Шаг 2: Анализ содержимого​

Если найдено подозрительное значение:

1. Экспортируйте байты и проверьте энтропию. Равномерное распределение байтов указывает на шифрование или сжатие.
   
2. Поиск сигнатур: даже в зашифрованном payload могут оставаться неизменённые фрагменты (заголовки PE, если payload — DLL, или характерные последовательности API-хешей).
   
3. Сравнение с известными образцами: загрузите дамп в песочницу или сравните хеш с базами IOC.
   

Шаг 3: Восстановление цепочки исполнения​

Определите, какой процесс читал значение и исполнял его:

• Sysmon Event ID 13 покажет, кто записал значение.
  
• Sysmon Event ID 1 (Process Creation) в сочетании с Event ID 10 (ProcessAccess) покажет, кто создал поток в целевом процессе.
  
• Если используется CreateThread внутри того же процесса — ищите аномальные потоки через memory dump или EDR-телеметрию.
  

Шаг 4: Проверка механизма persistence​

Payload в реестре сам по себе не обеспечивает автозапуск. Атакующий комбинирует его с одним из механизмов persistence Скрытое удалённое управление Windows: признаки C2, persistence и план расследования:

• Run/RunOnce ключи (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)
  
• Scheduled Tasks, которые запускают loader
  
• COM-объекты с hijacked CLSID
  
• Service DLL подмена
  

Проверьте, что именно триггерит чтение payload из реестра.

Ограничения техники​

• Размер значения реестра ограничен, но на практике shellcode редко превышает несколько сотен КБ.
  
• HKCU не требует повышения привилегий, но доступен только в контексте текущего пользователя. Для системного persistence нужен HKLM.
  
• EDR с kernel-драйвером видит операции с реестром на уровне callback'ов (CmRegisterCallbackEx), поэтому обход возможен только при отключении или обходе самого EDR.
  
• AMSI не контролирует чтение из реестра напрямую, но может перехватить этап исполнения, если payload проходит через скриптовый движок Попытки обхода AMSI: что контролирует Windows и какие артефакты помогают защитнику.
  

Связь с MITRE ATT&CK​

В классификации MITRE ATT&CK эта техника отображается на несколько тактик:

Тактика	Техника	ID	Примечание
Defense Evasion	Modify Registry	T1112	Запись и модификация значений реестра для сокрытия артефактов
Persistence	Boot or Logon Autostart Execution: Registry Run Keys	T1547.001	Относится к триггеру автозапуска, а не к хранению payload
Execution	Command and Scripting Interpreter	T1059	Если loader запускается через скриптовый интерпретатор

Хранение payload в реестре как таковое не имеет отдельного sub-technique в MITRE ATT&CK. T1547.001 описывает механизм автозапуска через Run-ключи, который может триггерить чтение payload, но не само хранение. T1112 покрывает модификацию реестра как способ сокрытия следов.

Чек-лист защитника​

• [ ] Sysmon Event ID 13 включён и логирует записи REG_BINARY в HKCU и HKLM
  
• [ ] Правило детектирования: REG_BINARY > 512 байт в нетипичных ключах
  
• [ ] Правило детектирования: цепочка RegGetValue → VirtualAlloc → VirtualProtect(PAGE_EXECUTE_READWRITE) → CreateThread в одном процессе
  
• [ ] Периодический аудит REG_BINARY-значений в Control Panel, Software\Classes, Software\<Vendor>
  
• [ ] Проверка механизмов автозапуска на предмет ссылок на loader, читающий payload из реестра
  
• [ ] При обнаружении: дамп значения, хеш, поиск по IOC, изоляция хоста, анализ loader-процесса
  

Дополнительно по теме: Payload и shellcode: чем отличаются, как исполняются и какие артефакты видит защитник раскрывает разницу между payload и shellcode на уровне концепции, Отображаемая память в Windows: mapped memory, инъекции и артефакты для анализа описывает артефакты отображаемой памяти, которые возникают на этапе исполнения.

Источники​

• Цикл статей "Изучение вредоносных программ" | Прячем Payload в реестре | Osint42.Org - Безопасность и код
  
• OWASP Top 10 | OWASP Foundation
  
• MITRE ATT&CK®