[NOD32] Дополнительный модуль сканирования памяти

Ar3s

Старожил форума
Легенда
Регистрация
30.12.2004
Сообщения
3 074
Реакции
474
Баллы
83
Добрый день! Много споров ходит вокруг новой технологии nod32.
Да и признаться, меня тоже смутила надпись "Обнаружена угроза в памяти", при запуске одного криптованного семпла. Неужели ав стали сканировать память процессов, чтобы ловить запакованные семплы сразу после распаковки? Но в таком случае пойдёт прахом вся отрасль криптования, ибо придётся морфить код который исполняется, а не скрывать его за неприступным для эмуляторов слоем криптора.



Собственно проблема была интересной, и мы решили провести группу тестов.
Тестировать ПО на AV вообще хорошая идея. Действительно, зачем выбрасывать деньги за неактуальный софт, который спалится через 40 минут после прогруза..

Мы взяли поньку, Win32/Fareit по классификации майкрософта, и криптанули её.
Чистый семпл сразу сносится нодом, криптованный как ни в чем не бывало сбрасывает отчет на диск.
Значит для того что бы стимулировать AV к проверке памяти нужны некие дополнительные условия, чем просто запуск нового процесса.

цитата из документации:
Модуль HIPS включает в себя дополнительный модуль сканирования памяти, который сканирует выполняющиеся приложения при изменении их состояния с целью обнаружения возможных подозрительных или вредоносных действий.

Не очень внятно, особенно в конце. Но выбирать не приходится.

Продолжим тесты, теперь возьмём софт, с которым был замечен новый вид детекта, например один граббер. Я пробовал на тест андромеду 2.07, но реакции AV не последовало.

После запуска криптованого граббера он успешно отработал вплоть до... внедрения в exporer!


Что интересно, детект чистого файла без криптовки и детект файла в памяти, совершенно одинаков.



Ок, другой семпл. Малоизвестный RAT, так же криптованный, при запуске получаем это:



Пора разобраться, в чем дело. Открываем Ollydbg, трассируем до появления детекта.
Как и ожидалось, он происходит при вызове RegSetValueExW, прописывающий наш семпл на авторан.
Обычная проактивка!



Обдумав все полученные факты, мы пришли к выводу, что т.н. "модуль сканирования памяти" это надстройка над HIPS (HIPS - проактивная технология защиты, построенная на анализе поведения.)
При вызове подозрительных апи, например необходимых для инжекта в чужой процесс, NOD останавливает выполнение нашего семпла и проверяет его в памяти. Что разумно, ибо к моменту вызова палевных апи модуль почти наверняка будет в распакованном виде, даже если до этого был качественно закриптован.

Используйте качественный софт с поддержкой!

egyp7 и valentin_p
coru.ws
 

crack_2005

floppy-диск
Пользователь
Регистрация
19.03.2013
Сообщения
9
Реакции
0
Баллы
8
ну дак, инжект палится уже сто лет) каспер еще с прошлого года, эвристикой дрочит инжект.
проверил крипт с peload - не палит. (софт приват)
 

500mhz

(L2) cache
Модератор
Регистрация
29.04.2008
Сообщения
473
Реакции
372
Баллы
71
Полезный обзор
 

cort1

CD-диск
Пользователь
Регистрация
13.05.2014
Сообщения
10
Реакции
1
Баллы
8
попытка продать новый вектор проактивки как суперпродукт...
Молодцы)
Ar3s спасибо за обзор )
 

Quake3

генератор Зла
Модератор
Регистрация
03.11.2010
Сообщения
975
Реакции
653
Депозит
0.01
Баллы
104
Неужели ав стали сканировать память процессов, чтобы ловить запакованные семплы сразу после распаковки? Но в таком случае пойдёт прахом вся отрасль криптования, ибо придётся морфить код который исполняется, а не скрывать его за неприступным для эмуляторов слоем криптора.
Вот, спустя несколько лет это уже реальность. ГовНод сканирует все и вся в памяти, после распаковки малварки криптором.
 

merdock

(L3) cache
Пользователь
Регистрация
09.06.2019
Сообщения
233
Реакции
187
Баллы
43
Вот, спустя несколько лет это уже реальность. ГовНод сканирует все и вся в памяти, после распаковки малварки криптором.
не хилый ты некропостер я смотрю :) НОД сколько я знаю 5 лет назад еще память сканировал но событийно
 

Octavian

CD-диск
Пользователь
Регистрация
19.03.2020
Сообщения
15
Реакции
11
Баллы
11
Jabber
В детекте в памяти всё (относительно) просто:
1. Есть "статегические" (те что используются в малвари и не только) winapi
2. На них стоит хук
3. В процессе исполнения CFG составляется карта вызванных winapi функций
4. Собранная на данный момент карта накладывается на паттерны потенциально вредоносных
5. Поток CFG останавливается, делаются дополнительные проверки по собранной статистике опкод, регистров и т.д.
6. Вылетает детект
7. Профит.

Чтобы научиться противодействовать этому, нужно в обратно порядке пройтись по действиям, понять что и как нужно изменить (подсказка winapi карту) и будет профит)
 

Haunt

(L3) cache
Пользователь
Регистрация
07.11.2019
Сообщения
238
Реакции
327
Баллы
68
Чтобы научиться противодействовать этому, нужно в обратно порядке пройтись по действиям, понять что и как нужно изменить (подсказка winapi карту) и будет профит)
Это да, но этого будет не достаточно. Достаточный вариант - чтобы авер потерял контекст выполнения.
При вызове подозрительных апи, например необходимых для инжекта в чужой процесс, NOD останавливает выполнение нашего семпла и проверяет его в памяти. Что разумно, ибо к моменту вызова палевных апи модуль почти наверняка будет в распакованном виде, даже если до этого был качественно закриптован.
Что значит потеря контекста выполнения? Тем более, если выполняемый код по факту никак не «скрыть». А все просто, абстракции. Добавить ещё уровень абстракции в виде вм или fsm(второе ещё не пробовал в том виде, в котором зомба описывал). Тогда низшие, простейшие блоки, где реализованы опкоды - нести сами по себе смысла не будут. Особенно если при каждом билде морфить этот простейший блок, где реализована логика для опкода. Смысл будет крыться как раз в декоде инструкции для вм и перенос этой инструкции с вм на реальный процессор. Чем сложнее процесс преобразования инструкция -> вм -> реальный процессор, тем сложнее автоматикой понять контекст. То есть без снятия слоя вм - анализ семпла в памяти, зачастую, не имеет смысла. При таком раскладе забавно наблюдать за поведением ав. Так, даже старейший инжект шк через createremotethread происходит без палева. А в случае маппинга пе с памяти в память - авер(аваст например) ПРОСТО крашит процесс, без единого детекта. Замечу, что весь ваш семпл должен быть «подвержен» такому вот состоянию потерянного контекста. Если авера попытаться взять на дурака, то есть к примеру в стабе с антиэмулями и потерянным контекстом произвести маппинг пе в память, то маппинг пройдёт норм, да, но по итогу, через время все равно зарежет то, что вы маппили. По этому все то, что я описал - актуально только для тех, у кого есть доступ к исходникам. Без исходников вы никогда не добьётесь всех этих плюх и так и будете дальше думать что чистый рантайм невозможен. А имея исходники - возможно довести весь проект до состояния потерянного контекста и словить когнитивный диссонанс с результата и своих убеждений касательно познаний малвари в целом.
 
Последнее редактирование:

Octavian

CD-диск
Пользователь
Регистрация
19.03.2020
Сообщения
15
Реакции
11
Баллы
11
Jabber
Транcлятoр виртуальнoй машины пoзвoлит cпутать кoнтекcт, нo не cкрыть иcтинную
карту вызoвoв, пoтoму как пoрядoк вызoвoв не изменитcя, тут нужнo мoрфить и карту
вызoвoв в тoм чиcле, тoгда да.

Kcтати вм не вcегда нужна, запутывание
cfg вcё еще впoлне пoмoгает c пoмoщью вcё тех же непрoзрачных предикат и запутывание графа
иcпoлнения.
 
Последнее редактирование:

Haunt

(L3) cache
Пользователь
Регистрация
07.11.2019
Сообщения
238
Реакции
327
Баллы
68
Транcлятoр виртуальнoй машины пoзвoлит cпутать кoнтекcт, нo не cкрыть иcтинную
карту вызoвoв, пoтoму как пoрядoк вызoвoв не изменитcя, тут нужнo мoрфить и карту
вызoвoв в тoм чиcле, тoгда да.
Я это и имел ввиду и отвечая на твой комментарий имел ввиду И, а не ИЛИ) То есть смесь этих 2 техник даст тот самый желаемый буст.
 
Верх