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

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

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

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

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

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

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

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

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

Малварь по шагам [№4] TrashGen

Сегодня мы поговорим про генераторы мусорного кода.

В быту встречаются 2 типа генераторов:

1)на уровне байткода
2)на уровне исходников

К первому типу движков можно отнести xTG 2, написанный на masm. Любители хардкора могут повторить его подвиг, но есть варианты проще, например генерация исходного asm-текста.

Генерация байткода применима только в «мобильных» генераторах, например вместе с мутирющим свое тело вирусом.

Помню, в своё время, меня поразила красота одного POC-генератора. Его код выглядел примерно так:
Код:
;псевдокод!
call trashgen
0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00
invoke MessageBoxA,0,"!!!","i am alive",0

После call было пустое место, и буквально через 1 инструкцию процесс упал бы на невалидных опкодах, но единственный вызов trashgen заполнял «овраг» случайным мусором всегда точно по его размеру и процесс, вопреки всему, выдавал радостное сообщение, о том что он жив. Особенную красоту коду придавал тот факт, что exe весил пару килобайт и сам генератор был опкодов на 10-15.

Это был очень простой генератор, его современные братья умеют:
  • работать с регистрами разной длины (rax\eax\ax\al\ah)
  • создавать разные бинарные представления одной и той же мнемоники (как пример — оптимизированный опкод для eax и его «длинный» вариант)
  • генерировать «мета»-команды, которые достигают одного результата разными способами, генерируя разный байткод для одного запланированного действия.
  • генерировать «логические» блоки команд, то есть не один опкод а их группу, организуя циклы, винапи вызовы, антидебаг трюки и т.п.
У этого подхода есть 2 весомых недостатка:
  1. ты берешь на себя работу компилятора, которую он делает лучше
  2. и как следствие из первого, ты не так хорошо оптимизируешь опкоды и выбираешь не те, которые создавал бы реальный компилятор, а стало быть выдаешь аверскому эвристику что код не «настоящий».
Детектирование генератора

Антивирусные решения, по понятной причине, плохо относятся к код созданному генератором. Главным оружием в борьбы с ним всегда являлась статистика появления опкодов. Особое внимание уделяется как общему числу (различных) опкодов, так и вероятности «встречи» конкретного опкода. Таким образом, у эвристика есть таблица: сколько (всего разных) и каких опкодов в норме должно быть в приложении. Подсчёт ведётся от точки входа эмулятора. По всей видимости, он собирает лог трейса на N опкодов и запускает эвристик.

Современные антивирусы поступают точно так же с WinApi-вызовами, собирая их лог (Напр. «Потрошим эмулятор касперского» ), после чего эвристик может найти «плохие» последовательности WinApi, вроде инжекта в процесс, или сверить со своими паттернами «правильного» (с точки зрения статистики встречи в приложениях) начала программы, как это любят делать клоны BitDefender.

Оптимизация — ахиллесова пята антивирусной системы. Просканировать весь диск — задача не из быстрых, даже на уровне чтения всех файлов в оперативку. Значит на сканер накладываются драконовские ограничения по глубине сканирования и подходу в принципе. Печать оптимизации есть на челе любого продукта. Может вы помните утилиту TauScaner (привет, Вазон!), она была написана после вброса на форумы информации о том что можно избежать эмуляции кода вообще (!) имея статистически хорошие pe32-хидеры и энтропию. Что ж, это очень близко к правде, глубина сканирования зависит от «подозрительности» внешних половых признаков .

Статистика же говорит, что большинство (взятых во внимание Av) приложений написаны на Си с использованием CRT, имеют все стандартные ресурсы (manifest,version_info, иконки, меню, диалоги, конфиги, и т.д.). Что привело к появленияю в крипторах генераторов этих самых ресурсов.

1608882996129.png

Выглядит криповато

Генерация WinApi

Теперь мой юный (или не очень) Друг, мы обсудим жемчужину любого генератора — мусорные апи вызовы.

Существует всего 2 пути создания WinApi базы:
  1. winapi брутер, который вызывает их со случайными параметрами и записывает что получилось в итоге.
  2. парсинг хидеров и ручное редактирование
Первый вариант хорош своей автоматизированностью: прогнав генератор на всех системах и сервиспаках (господи, сколько же их наплодил Билли), оставив только совпадающие результаты, можно найти не очевидные закономерности. Например, у некой WinApi на всех системах после вызова обнуляется регистр Ecx. Недокументированная особенность реализации. Так как в msdn это не описано, подобные приёмы становятся отличным антиэмулем.

Второй вариант более стабилен и гарантирует что ваш мусорный код не:
  • нарисует во время исполнения на десктопе лишний курсор
  • создаст рядом с собой файл
  • проиграет системный звук
  • ребутнет машину
  • или любым другим образом скомпрометирует свое исполнение
Генерация си кода

Принципиально не отличается от других типов генераторов. Есть таблица «кирпичиков» из которой выбирается генерируемый шаблон, типа: цикл, выражение с переменной, вызов дочерней функции, и т.д. Преимущество в том что используется реальный компилятор, вышеописанные 2 недостатка исключены. При желании можно делать асм-вставки.

Интересен этот подход из-за описанного в прошлой статье детектирования в памяти. Расставив по исходному коду специальные комментарии, которые обфускатор заменит на сгенерированный мусор, мы получим автоматическую очистку семпла от детектов.

Так же это избавит авторов от головой боли с отвязкой семпла, только реальный владелец исходных кодов сможет выкатить новую версию без детектов в памяти. Утечку можно будет идентифицировать по мусору, кроме того, морфинг исходных кодов СИЛЬНО усложнит жизнь аналитикам.

За криптором который нельзя снять не убив семпл — будущее. Только представьте, сколько веселых минут может доставить код скрещённый с крутым протектором!

1608883019836.png


Как и в прошлый раз, небольшой бонус

Заключение

Новые av-технологии повышают порог выживания малвари, но вместе с тем делают адаптированные семплы в разы опасней.
 
Последнее редактирование: