• ! Привет посетитель !

    Зачем данный ресурс нужен ?

    В рунете было много ресурсов с интересными обсуждениями и работами по вирусным технологиям, а также в область ИБ.

    Но со временем у людей меняются интересы, а кто-то просто не может держать такие сайты, сайты удаляются, я подумал а печему-бы не сделать такой архив со статьями на тематику вирусов и ИБ.

    Цель ресурса:

    Собрать какие-то актуальные утеренные обсуждения и работы.

    Пока-что поднял два сайта:

    1) https://archivevx.net/exelab/f/

    2)Vxlab.info - Тут просто сделаю перепост статей сюда:https://archivevx.net/index.php?forums/vxlab-info-Статьи-ресурса.4/

Малварь по шагам [№3] Детекты в памяти

Сравнительно новое явление, набирающее популярность у Av-вендоров. Я склонен рассматривать это как развитие проактивных методов. Как это работает?

По срабатыванию некоего тригера, обычно это ядерный вызов подозрительной WINAPI на подобии открытия чужого процесса, начинается скан памяти. Таким образом, сканер проходится по коду после снятия слоя криптора. Как пишут наши коллеги, по всей видимости, используется тот же сканер что и для обычных файлов. Это можно заключить по общности детектов: файл до криптовки и после скана в памяти будет иметь одно и тоже сигнатурное название.

Уже сейчас подобные технологии внедрили NOD32 и MSE (который, кстати, есть в составе windows под именем Windows Defender), возможно кто-то ещё. Следует ожидать, что со временем все вендоры оценят потенциал и заимеют свои аналоги.

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

ApiCall map

Насколько Я помню, NOD32 зачастую использует сигнатуры по карте апи-вызовов. Я не знаю как это называется на жаргоне, но давайте здесь будем использовать термин «Карта Апи вызвов».

Каким бы умным не был дизассемблирующий код, он не обрабатывает ситуации кроме стандартных API-call, которые может генерировать компилятор. Вызывайте апи через свою таблицу импорта или по хешу, тогда подобные сигнатуры станут бесполезны

Unique bytecode​


Если мне не изменяет память, MSE часто использует сигнатуры по байткоду. Для эксперимента, Я взял несколько детектируемых им семплов и убрал из них шаг за шагом, всё кроме сигнатуры. Во всех случаях это была группа редко встречающихся подряд ассемблерных инструкций.

Например, для Trojan:Win32/Swrort.A это следующий байткод по смещению 0x7BBF:

Код:
68 58 A4 53 E5 ;PUSH E553A458
FF D5 ;CALL EBP

//любое количество любых байт между

68 A6 95 BD 9D ;PUSH 9DBD95A6
90 ;NOP
E9 0E 00 00 00 ;JMP NEAR

//от нуля до 14 любых байт между

FF D5 ;CALL EBP

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

Сигнатуры по хидерам


Забодавший своими фолсами (!) «win32:evo-gen[susp]» от AVAST, базируется на заголовках pe32. Многие вендоры начинают сканирование и решают нужно ли его углубить исходя из хидеров, что сделано в целях оптимизации.

Во внимание принимается структура секций, их размер, порядок, имена, энтропия и характеристики (RWE\DATA\CODE), вкупе с размером стека и флагами из NtHeaders — это составляет единую сигнатуру.

Обход сводится к порче хидеров в памяти, после которой часть WinApi, их использующих перестанут корректно работать, что надо иметь в виду. Обычно это выглядит как удаление опорных точек для сканеров, таких как «PE00» и «MZ«.

Мойте семплы перед едой​


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

Для этого есть утилита SignFinder