😴 Выходные в тишине провели и теперь начнем с интересного кейса 🧰

🔥 Azure Functions как C2: свежая малварь с DLL-sideload и инжектом в chakra.dll

Поймали любопытный образ: ISO Servicenow-BNM-Verify.iso, низкие детекты на VT, внутри — легит PanGpHip.exe (Palo Alto), легит libeay32.dll и спрятанная зло-libwaapi.dll. Классика DLL sideloading: ярлык .lnk запускает легит-EXE, тот подхватывает зловредную DLL рядом и уже она рулит сценой.

🧩 Цепочка атаки (коротко)
• Приманка: ISO с ярлыком servicenow-bnm-verify.lnk → запускает PanGpHip.exe. Метаданные LNK подсвечивают окружение сборки автора.
• Sideload: PanGpHip.exe грузит libwaapi.dll → экспорт wa_api_setup прячет консоль, ставит мьютекс 47c32025, зовёт инжектор.
• Инжект в память:
- RC4-ключ = SHA-256 от строки rdfY*&689uuaijs;
- Расшифровывает имя chakra.dll, грузит системный C:\Windows\System32\chakra.dll;
- Находит первую RX-секцию, переводит в RW через ZwProtectVirtualMemory, затирает, кладёт payload (base64→RC4), проверяет SHA-256 целостности и исполняет.
• Шеллкод → финальный DLL: шеллкод содержит сжатый (LZNT1 0x102) DLL; распаковка через RtlDecompressBuffer. Экспорт DllUnload с модуль-анти-хукингом. Метка времени подменена (1984-05-05).
• C2: периодические POST на logsapi.azurewebsites[.]net/api/logs (Azure Functions). Шлёт XML-профиль жертвы: имя ПК/пользователя, аптайм, процесс/родитель, билд ОС, протокол и пр.

🤔 Что здесь интересного
• Бесшумный хостинг C2: Azure Functions (serverless, триггеры/биндинги) — дешёво, эластично, выглядит «белым» трафиком в логах.
• Инжект в Chakra: выбор популярной системной DLL + подмена секции уменьшает сигнатурный шум и ломает простые проверки целостности.
• Двойная проверка целостности: RC4 ключ из SHA-256 + отдельный hard-coded SHA-256 по payload — защита от порчи.

🛡 Для синих (hunt & hardening)
Хантинг:
• ImageLoad/Section-tamper: системный chakra.dll с неожиданно изменяемыми секциями, вызовы ZwProtectVirtualMemory рядом с base64/RC4-артефактами (Sysmon EID 7/10/11, ETW/EDR).
• Sideload следы: PanGpHip.exe грузит libwaapi.dll из локальной папки (несоответствие подписи/пути).
• Сеть: исходящие к *.azurewebsites.net/api/logs (особенно POST с нестандартным XML).
Харденинг:
• WDAC/AppLocker: запрет загрузки несанкционированных DLL рядом с подписанными EXE.
• Мониторинг целостности системных DLL (по секциям) и блокировка RW→RX на легит-модулях.
• Egress-контроль к azurewebsites.net из серверных сегментов; инспекция POST-тел к Functions.

🧾 IOCs (из статьи)
• ISO: 0ba328aeb0867def650694c5a43fdd47d719c6b3c55a845903646ccdbf3ec239
• LNK: 9e312214b44230c1cb5b6ec591245fd433c7030cb269a9b31f0ff4de621ff517
• Mal DLL libwaapi.dll: b03a2c0d282cbbddfcf6e7dda0b4b55494f4a5c0b17c30cd586f5480efca2c17
• C2: logsapi.azurewebsites[.]net/api/logs

👀 TL;DR
ISO-приманка → DLL-sideload на PanGpHip.exe → инжект в секцию chakra.dll (base64+RC4, integrity SHA-256) → сжатый шеллкод → финальный DLL → C2 на Azure Functions с POST XML телеметрии. Ловим по sideload, мутированию секций Chakra и трафику на azurewebsites.net.

🏁 Финалка: «В облаке прячутся не только наши бэкапы». Следим за телеметрией — и всё будет 👍.

👾 Malware Anatomy

#InfoSec #CyberSecurity #MalwareAnalysis #WindowsSecurity #ThreatIntel #MalwareAnatomy

😒 LLM vs 🔒obfuscation — пока не конец для RE

Наткнулся на сильный материал от Elastic Security Labs: они гоняли Claude Opus 4.6 по crackme, обфусцированным через Tigress, и смотрели не только на “решил / не решил”, но и на цену, время и масштабируемость такого RE.

😊 Самый интересный момент
На 22 таргетах 2 вообще зависли инфраструктурно, а из оставшихся 20 модель решила только 40%.
Без обфускации baseline был решён за $0.43 и 1m55s, а уже на JIT задача падала в failure при $5.90 и 32m18s.
`JitDynamic` и тяжёлые multi-layer кейсы тоже в основном заканчивались kill по бюджету/токенам.

⚠️ Что ещё зацепило
Даже там, где модель не доходила до финального ответа, она нередко делала часть работы правильно.
Например, в JIT-кейсах она всё равно находила структуры движка и LCG-логику, но ломалась на восстановлении нужных констант.
То есть проблема уже не всегда в “модель тупая”, а в том, что цена понимания резко растёт.

😮 Ещё один интересный вывод
Elastic отдельно отмечают, что связка control-flow flattening + MBA местами била по модели даже эффективнее, чем virtualization + MBA.
Причина забавная: VM-хендлеры у Tigress часто остаются маленькими и относительно удобными для анализа, а вот CFF раздувает размер функций и сильнее бьёт по контексту модели.

😬 А дальше пошли уже совсем неприятные для LLM идеи
Они собрали loader authd, где спрятан 4.4 MB encrypted blob, а реальный crackme внутри всего 16 KB.
Парольный путь там завязан на 100,000 stages в обратном порядке: на каждом шаге расшифровывается только маленький header, вытаскивается следующий фрагмент ключа, и только в конце из хвоста буфера появляется plaintext ELF, который потом передаётся через memfd_create + execve.
Для статического анализа LLM это уже очень неудобная история.

👀 И это не всё
Они ещё прятали loader так, чтобы IDA не нашла его по обычным prologue/epilogue-эвристикам, а полезную нагрузку грузили в заранее выделенный RWX-сегмент .note.fips, который должен был выглядеть менее подозрительно при статике.
Плюс патчили libgcrypt и даже маскировали версию библиотеки под более новую, чтобы усложнить diffing.

👨‍⚖️ Мой вывод как аналитика
LLM уже реально полезны в RE.
Но статья хорошо показывает главное: обфускация не обязана делать анализ “невозможным” — ей достаточно сделать его дорогим, долгим и плохо масштабируемым.
И вот тут у automation-пайплайнов начинаются настоящие проблемы.

📖 Источник:
Elastic Security Labs

👾 Malware Anatomy

#LLM #ReverseEngineering #Obfuscation #MalwareAnalysis #ElasticSecurity #Tigress #JIT #Virtualization