Криптор это: Криптор — это… Что такое Криптор?

Что такое криптор и стаб ?

06.12.2016 00:55 Давность: 5 yrs
Категория: Безопасность

Криптор (aka cryptor) — это тулза, которая предназначена для скрытия троянов, ботов и прочей нечисти от детектирования антивирусами.

Хорошие крипторы работают очень просто, быстро и надёжно, хоть и не безглючно. Они дописывают свой код (в контексте таких крипторов этот код называется стабом) в криптуемую программу и шифруют код самой программы. При запуске первым стартует стаб, он восстанавливает оригинальный код и программа начинает работать. Если криптор свежий (или просто хороший, об этом ниже), то закриптованная программа не будет детектироваться антивирусами.

Чаще всего такие крипторы полиморфны — т.е. код криптора в криптуемой программе каждый раз уникален, заполнен случайными инструкциями и бессмысленными вызовами функций API. Такие крипторы достаточно долго остаются недетектируемыми в силу уникальности каждого закриптованного файла. Такие крипторы тоже со временем детектируются, и если автор не чистит свой продукт, то криптор перестает быть уникальным.

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

Т.е. надеюсь поняли отличия в первом случае шифруется код программы, и стаб расшифровывает уже команды программы, а во втором случае шифруется сам файл программы и расшифровывается тоже сам файл, ну и понятно, что второй тип криптора это не что иное как ерунда, т.к. практически любой антивирусник спалит вирус при расшифровке ! 😉

Некоторые крипторы напрямую файл на диск не пишут, а запускают его из памяти, но это их не оправдывает, т.к. продвинутый антивирус словит это при запуске.

В таких крипторах уникальность каждого закриптованного файла достигается разными стабами. Но такой подход весьма ограничен — в хороших криптах это всего-лишь код, и его можно сгенерировать, а со стабами в плохих крипторах уже сложнее, поэтому авторы чаще всего создают под каждого клиента отдельный стаб. Подход глуп до безобразия, ведь ежели спалится антивирусами один закриптованный файл — за ним полетят и все остальные.

Ну, антивирус, погоди! Создаем EXE-криптор на Python’е — «Хакер»

Содержание статьи

Web мы спасли от антивирусов несколько месяцев назад. Это было нетрудно — область относительно новая, не освоенная. С исполнимыми же файлами антивирусы борются уже десятилетиями. Побороть EXE-модуль будет сложнее, но… мы справимся :).

Выпуск 1. Ознакомительный

Ты уже знаешь, что я считаю антивирусы абсолютно бесполезными — хотя бы по той причине, что они помогают только от самых примитивных зверьков, которые в условиях современного денежного малварьбизнеса встречаются не так часто. Современные злокодеры, подогретые денежными вливаниями, научились программировать довольно жестко, но есть у них одна маленькая проблема — криптовка — достаточно сложная штука, для написания которой нужны глубокие знания PE-формата, ассемблера и системного программирования. Из-за высокого «входного барьера» в этой области мало профессионалов.

И найти хорошего криптора ой как сложно.

Но решение проблемы есть! Как мы знаем, антивирусные компании обмениваются технической информацией и создают специальные ресурсы, посредством которых мы сами отсылаем им сэмплы (типа VirusTotal’а). Но ведь и вирмейкеры тоже могут обмениваться информацией! Необязательно палить приватные мазы — публичные технологии тоже сгодятся. Например, было бы круто, если бы в каком-то одном месте лежали функции для генерации PE-файла, генерации импорта, шифрования ресурсов, рабочие функции определения SandBox’ов, тогда мы могли бы создавать крипторы так же непринужденно, как домики из кубиков Лего.

Идеальным местом для обмена, наверное, будет GitHub, и туда я залью исходники написанного нами сегодня криптора — он будет доступен по адресу http://github.com/presidentua/ExePacker.

Кроме того, в решении проблемы здорово помогло бы использование высокоуровневых языков программирования. В паблике сейчас валяются исходники крипторов на С++ или VisualBasic’е, но ведь от этого проще не становится, поскольку разобраться в написанном коде — ой как непросто. На Python’е все выглядит в разы лучше, поэтому именно его мы сегодня и будем использовать. В общем, заложим фундамент этой благородной миссии. Присоединяйся!

Выпуск 2. PE-файл

Структура PE-файла довольно сложная, поэтому подробная документация будет ждать тебя на диске, а здесь я представлю твоему вниманию лишь избранные моменты.

PE-файл представляет набор разных служебных структур, связанных между собой, и набор данных, которые размещены в секторах. Загрузчик Windows’a читает структуры, обрабатывает их (например, импортирует DLL’ки) и потом передает управление на инструкцию, указанную в поле «Entry Point».

Теперь посмотрим, что же нужно нам сделать, чтобы изменить файл и при этом не испортить его.

Выпуск 3. Теоретический криптор

Для начала выберем файл, который будет у нас исполнять функции лабораторной мыши. Чтобы сделать приятное Андрюшку :), мы, пожалуй, будем издеваться над Putty.exe. Упрощенно его структура будет выглядеть так:

1. Служебные данные
2. Первая кодовая секция
3. Другие секции с данными

Алгоритм криптора следующий. Создать две ассемблерные программы. Первая будет косить под обычную прогу и проверять, что мы не в эмуляторе, а потом передаст управление на вторую программу. Вторая же восстановит оригинальную структуру файла и передаст управление на оригинальную точку входа Putty. И записать эти программы в файл.

В результате получится следующая структура:

1. Служебные данные
2. Первая кодовая секция
   1. Наша первая программа, которая передаст управление на 4.2
   2. Шифрованный код первой секции
3. Другие секции с данными
4. Добавленная секция
   1. Часть кодовой секции, перезаписанной программой 2.1
   2. Вторая программа, которая оригинальный код из 4.1 поместит на 2.1, а потом расшифрует кодовую секцию и передаст на нее управление.

Выпуск 4. Практический криптор

Ну наконец-то мы добрались до сердца нашей статьи. Для работы криптора нам понадобится модуль pefile (будем использовать несколько модифицированную версию), и с помощью либы откроем Putty:

import pefile
pe = pefile.PE("putty.exe")

Теперь, если ты напишешь «print pe», то увидишь подробную инфу обо всех характеристиках файла, по этой инфе я советую искать нужные для изменения поля в файле. А о внутренней работе модуля обязательно прочитай во врезке. Теперь немного математики. У нас будут две программы, которые нужно внедрить в файл. Они будут занимать где-то по 512 байт каждая максимум. Поэтому для размещения добавим новую секцию в 1024 килобайт вызовом:

pe.add_last_section(size=1024)

Закриптуем первую секцию XOR’ом с ключом «1»:

pe.sections[0].xor_data(code=1)

Магия, правда? :). А теперь прикинь, что все это пришлось бы писать на С++!

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

pe.data_copy(pe.sections[0].PointerToRawData, pe.sections[-1].PointerToRawData, 512)

Оригинальный код сохранен, и мы приступим к написанию первой программы. Конечно же, писать мы ее будем на ассемблере, используя FASM для компиляции. Создадим файлик pack.tpl.asm с содержанием:

use32
mov eax, {{ go }}
jmp eax

Ты, наверное, уже догадался, что это не готовый исходник, это лишь шаблон для шаблонизатора из TornadoWeb, а его мы уже отлично знаем, ведь именно его мы использовали при написании HTML-морфера. Сгенерируем первую программу:

asm = Template(open("pack.tpl.asm", "r").read()).generate(
go=pe.OPTIONAL_HEADER.ImageBase + pe.sections[-1].VirtualAddress+512,
)
with open("pack.asm", "w") as f:
f.write(asm)
os.system(r"c:fasmwFASM.EXE pack.asm")

В переменной go мы передаем адрес в памяти, где будет наша вторая программа — то есть, в последней секции, начиная с 512 байта. А в последней строчке компилим результат на FASM’е. Теперь запишем получившийся код в начало первой секции:

new_pack = open("pack.bin", "rb").read()
pe.data_replace(offset=pe.sections[0].PointerToRawData, new_data=new_pack)

Вторую программу запишем в файл copy.tpl.asm. Размер у нее более внушительный, поэтому полный код смотри на диске. Там содержится два цикла, один скопирует 512 байт оригинальной программы с последней секции в первую, а второй цикл расшифрует всю первую секцию. После этого передается управление на оригинальную программу.

При компиляции темплейта нужно передать туда параметры для циклов копирования и расшифровки:

copy_from = pe.OPTIONAL_HEADER.ImageBase+pe.sections[-1].VirtualAddress


copy_to = pe.OPTIONAL_HEADER.ImageBase+pe.sections[0].VirtualAddress
oep = pe.OPTIONAL_HEADER.ImageBase+pe.OPTIONAL_HEADER.AddressOfEntryPoint
asm = Template(open("copy.tpl.asm", "r").read()).generate( copy_from=copy_from, copy_to=copy_to, copy_len=512, xor_len=pe. sections[0].Misc_VirtualSize, key_encode=1, original_oep=oep,)

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

new_copy = open("copy.bin", "rb").read()
pe.data_replace(offset=pe.sections[-1].PointerToRawData+512, new_data=new_copy)


Выпуск 5. Завершающий

Если собрать кусочки кода вместе, то будет у нас всего 50 строк. Всего лишь 50 — и криптор готов! А теперь прикинь, сколько строк содержала бы программа на С? Конечно, это еще далеко не готовый продукт, над ним нужно работать и работать. Чтобы довести систему до реального криптора, нужно добавить как минимум шифрование ресурсов и импорта, а также антиэмуляцию.

Желательный функционал 1. Обход песочниц

В крипторе нужно делать проверки на запуск в виртуальной машине, SandBox’е или анализаторе типа анубиса. Чтобы их зедетектить, нужно провести небольшое исследование и написать программу, которая будет на экран выводить разные внутренние параметры системы, а дальше — проверить этот файл на том же анубисе и в скриншоте посмотреть параметры, которые показала наша прога. Дальше все просто — при запуске на системе с подобными параметрами — просто уходим в цикл.

Обязательный функционал 2. Шифрование ресурсов и импорта

Для шифрования ресурсов мы должны пройтись по секции ресурсов и сохранить оттуда важные для запуска файла — иконки и манифест. Дальше создаем новые ресурсы с важными ресурсами, а остальное шифруем. После запуска криптора восстанавливаем все обратно.

Несколько сложнее получается с импортом, ведь его также нужно сначала зашифровать, потом сгенерировать липовый импорт, но после восстановления импорт еще нужно вручную проинициализировать, то есть — загрузить DLL’ки и сохранить в таблицу импорта реальные указатели на функции.

Обязательный функционал 1. АнтиЭмуляция

Кроме избавления от внешних сигнатур, очень важно, чтобы антивирус в своем эмуляторе не добрался до исходного файла. Для этого нужна антиэмуляция. Раньше были очень популярны приемы, основанные на предположении, что эмулятор не понимает все инструкции процессора. Сейчас же ситуация изменилась, и самые эффективные приемы основаны на использовании Windows API. Согласись, что антивирус вряд ли сможет эмулировать все API.

Вот тебе такая идейка для реализации:

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

PS:Никогда не останавливай программу с ошибкой, это лишь прибавит криптору лишний вес. Вечный цикл получения сообщений от Windows — лучший способ.

Внутренности Антивирусов

В упрощенном виде, антивирус — это набор правил (сигнатур) и система, которая проверяет файл по этим правилам.

К примеру, пусть в антивирусе будут такие сигнатуры:

• секция с кодом, записываемая +10;
• после запуска прописывается в авторан +30;
• вторая секция с именем Zeus +30;
• меньше 4 энтропия кодовой секции +20;
• есть сертификат от майкрософта -10.

Дальше антивирь проверяет те правила, которые возможно проверить без запуска EXE, потом в эмуляторе запускает файл и проверяет все остальные правила. А после этого подсчитывает сумму, если она больше 100, значит вирус, если меньше — значит не вирус.

Как работает pefile

При загрузке в pefile экзэхи, библиотека сохраняет сам файл в pe.data, а потом обрабатывает его и создает массив структур pe.structures. Структура — это объект, у которого есть адрес. Адрес, по которому она находится в файле, и есть набор полей.

При сохранении файла pe.write(filename=»result. exe») либа проходит по всем структурам и сохраняет их по указанным адресам. Чтобы что-то добавить, например, в ту же секцию, нам сначала нужно найти адрес в памяти. Это можно посчитать так: адрес в памяти последней секции + размер секции. Дальше заполняем все поля в структуре и добавляем ее в массив pe.structures. Вот и все :).

Links

Криптор

Итак, Вы решили стать крутым хакером и вирусописателем, и уже даже купили себе самую нужную книгу «Как стать хакером для чайников»? Быть хакером – это конечно круто, но прочитав книгу подобного рода, максимум, кем Вы станете, это хакером чайников.
В данной статье мы постараемся объяснить некоторые аспекты программирования некоего программного обеспечения, касающегося именно хакерских сторон деятельности – как написать вирус, чтобы его не палили антивирусы, какие программы при этом использовать и где эти программы брать.
Криптор (от английского слова «Cryptor» — шифровщик) – это название одного из вида программных продуктов, которые используются программистами-вирусописателями для того, чтобы скрыть вредоносную сущность написанного ими программного обеспечения от антивирусных программ.
Криптор, используя шифрование программы, содержащей вирус, маскирует и защищает ее от антивирусных программ, которые работают методами поиска по сигнатурам.
Различают два вида крипторов: обычный и полиморфный. Обычные крипторы имеют статическую сигнатуру декриптора-расшифровщика, а у полиморфных данная сигнатура динамическая, и каждый раз при компиляции они (файлы, упакованные такими крипторами) выглядят по иному.
Как же работают крипторы? Все довольно просто: берется исходный оригинальный файл вредоносной программы, затем данная программа шифруется каким-либо криптором, при этом в начало вновь полученного файла записывается код для расшифровки программы. Чтобы было более понятно, объясним на простейшем примере: берется некая троянская программа и архивируется архиватором WinRAR, причем архивируется не просто так, а с парольной защитой. После выполнения данных действий ни одна антивирусная программа не сможет добраться до данного трояна, так как расшифровывать пароли к архивам они не умеют.
Здесь присутствует один небольшой подводный камень. Антивирусы добавляют в свои базы сигнатур коды расшифровки наиболее распространенных программ-крипторов, но если Вы создали какую-либо программу, которая совсем не является вирусом, а выполняет какие-либо только полезные действия, но при этом запаковали ее для уменьшения размера каким-либо популярным криптором, то зачастую может так случиться, что антивирус при попытке скопировать данную программу на компьютер или запустить ее начнет ругаться, что в данной программе содержится страшный вирус. Ну, от этого никуда не деться, если Вы пользуетесь общедоступными крипторами.
Вообще, по типу доступности крипторы подразделяют на Публичные (Public) и Приватные (Private).
Первый вид крипторов является общедоступным, они широко распространены на просторах Интернета и при наличии желания их может скачать любой пользователь. Основной отрицательной стороной таких крипторов является то, что по истечении совсем небольшого срока они начинают палиться практически всеми антивирусами (ведь антивирусные лаборатории тоже не дремлют и стараются отловить свежие виды крипторов, тем более как их не отлавливать, если они лежат в свободном доступе).
Со вторым же видом все не так просто. Эти крипторы доступны только избранному сообществу людей либо же их можно приобрести за вполне реальные деньги (электронные в основном). Данный тип крипторов является более устойчивым к проверке их антивирусами благодаря как постоянно совершенствующимся алгоритмам шифрования, так и постоянно обновляемому стабу. Что такое стаб, спросите Вы? Ответим. Стаб – та часть кода криптора, которая используется для расшифровки данных вредоносной программы, которая и была зашифрована данным криптором.
Часто в раделах форумов, где представлены крипторы, присутствуют аббревиатуры FUD и semiFUD. Расшифруем эти аббревиатуры, чтобы Вам было более понятно. Что же это такое.
1)FUD — Full Undetected — «полностью не определяется антивирусами»
2)semiFUD — Semi-full undetected — «почти не определяется антивирусами».
Помимо крипторов, при написании вредоносного программного обеспечения (вирусов и троянских программ), используются и некоторые другие виды программ. Вкратце перечислим их названия и расскажем, для чего они служат.
Для кражи номеров ICQ, логинов и паролей к аккаунтам электронной почты и социальным сетям используются особые тоянские программы, которые называются пинчи и ксинчи.
Для приема и обработки полученной ворованной информации используются специальные php-скрипты, которые называются гейтами.
Для соединения в один файл безопасной программы и какого-либо вируса служат джойнеры. При этом функциональность как первого (допустим, фотографии), так и второго (например, троянского вируса), остается на высшем уровне.
Вот в принципе и вся основная теоретическая информация по крипторам, которую мы хотели Вам представить.

криптор, который любит держаться в тени / Блог компании Group-IB / Хабр

Ни один атакующий не хочет, чтобы его инструменты обнаружили и раскрыли раньше времени. Поэтому, как правило, в чистом виде никто вредоносные программы не распространяет. Например, пользователю прилетело фишинговое письмо от имени известной транспортной компании и просят проверить документы во вложении. Подобные письма достаточно часто являются началом атаки, так было и на этот раз. Внутри архива находился исполняемый файл Cassandra Crypter — популярный криптор, полезной нагрузкой которого могут выступать различные семейства вредоносного программного обеспечения. Алексей Чехов, аналитик CERT-GIB, рассказывает, как Cassandra проникает на компьютер жертвы и приводит с собой других незваных гостей.

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

Первая стадия

Cassandra маскируется под легитимное приложение. В точке входа располагается стандартная для приложений Windows Forms функция запуска.

Конструктор формы также выглядит стандартным, ничем не отличающимся от легитимного приложения.

При детальном анализе был обнаружен вызов функции aaa(), которая содержит вредоносный функционал. Ее вызов приводит к расшифровке и подгрузке вспомогательной dll.

Для расшифровки используется алгоритм AES.

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

Вторая стадия содержится в изображении, в зашифрованном виде, в исходной сборке.

Для расшифровки используется операция XOR, ключом для расшифровки являются первые 16 байтов исходного изображения.

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

Вторая стадия

Вторая стадия представляет собой исполняемый файл .Net Framework.

Конфигурационный файл

Полезная нагрузка

Полезная нагрузка содержится в крипторе в зашифрованном виде. Расшифровка проходит в два этапа:

1. В цикле осуществляется побайтовый XOR шифрограммы, ключа и значения операции XOR от последнего элемента байта шифрограммы и 112. Полученные значения сохраняются в созданный массив. Ключ для первой стадии содержится в конфигурационном файле.

2. Осуществляется дешифрование, аналогичное тому, что было на первой стадии: используется операция XOR, в качестве ключа используются первые 16 байтов массива, полученного на первом этапе.

Закрепление в системе

Закрепление в системе осуществляется через создание отложенной задачи. Файл копируется в директорию AppData//{имя файла, заданное в конфиге}+”.exe”. После этого исходный файл удаляется и создается задача на выполнение.

Anti-VM

В функции осуществляется поиск виртуальных видеоадаптеров и специфических ключей реестра, свойственных для виртуальных машин.

Anti-Sandbox

Реализованы три функции противодействия песочнице:

• Детект изолированной среды. Функция проверяет путь до исполняемого файла и ищет в нём специфические строки, таких как \\VIRUS, SAMPLE, SANDBOX и т.д. Также осуществляется поиск окна, свойственного WindowsJail, и библиотеки SbieDll.dll, загруженной в процесс.

Защита от повторного запуска

Реализована путем создания мьютекса с заданным именем в системе.

Функционал

Downloader

Реализована функция загрузки пейлоада из сети.

Запуск полезной нагрузки

Содержит два варианта запуска пейлоада:

1. Загрузка в память при помощи функций .Net Framework.

2. Инжект полезной нагрузки в запущенный процесс. Есть возможность выбора из нескольких процессов.

На данный момент Cassandra — достаточно распространенный тип крипторов. Как правило, злоумышленники используют его в массовых рассылках, чтобы незаметно запускать на машине пользователя вредоносное ПО. Cassandra позволяет запускать даже хорошо изученные семейства ВПО.

Исследователи обнаружили и изучили распространенный криптор OnionCrypter

С 2016 года OnionCrypter широко используется одними из самых известных и наиболее распространенных семейств вредоносных программ, таких как Ursnif, Lokibot, Zeus, AgentTesla и Smokeloader.

Исследователи Avast Threat Labs, подразделения компании Avast, мирового лидера в области цифровой безопасности и решений защиты, обнаружили криптор, который с 2016 года широко используется одними из наиболее распространенных семейств вредоносных программ, таких как Ursnif, Lokibot, Zeus, AgentTesla и Smokeloader. За последние три года Avast защитила почти 400 000 пользователей по всему миру от вредоносных программ, содержащих этот криптор.

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

Исследователи лаборатории угроз Avast Threat Labs изучили одну из «деталей» вредоносных программ, которая называется «криптор». Это инструмент, который скрывает вредоносные части кода с помощью шифрования — таким образом, код может на первый взгляд показаться безвредным, и его будет сложнее прочитать. Так создатели вирусов могут скрыть всю сущность программы от исследователей, антивируса и решений защиты. Для разработчиков вредоносных программ криптор — важный инструмент для противодействия защите. В то же время для исследователей обнаружение криптора позволяет быстрее находить и идентифицировать новое вредоносное ПО, которое его содержит.

Исследователи Avast изучили криптор, который они назвали OnionCrypter: как и лук, он состоит из множества слоев шифрования, защищающих информацию от исследователей, антивируса и решений безопасности. Именно благодаря своей «многослойности» OnionCrypter так необычен. Стоит подчеркнуть, что его название никак не связано с браузером или сетью Tor.

Исследователи лаборатории угроз Avast также отмечают, что OnionCrypter активно используется с 2016 года в самых известных и распространенных семействах вредоносных программ, таких как Ursnif, Lokibot, Zeus, AgentTesla и Smokeloader. За последние три года Avast защитила почти 400 000 пользователей со всего мира от вредоносного ПО, содержащего OnionCrypter. Диаграмма ниже показывает, какие семейства вредоносного ПО, использующие OnionCrypter, были обнаружены Avast.

Учитывая достаточно долгое время использования и распространенность OnionCrypter, исследователи сделали вывод, что разработчики продают его в качестве услуги. За последнее время рынок вредоносного ПО значительно вырос, и вполне объяснимо, почему некоторые люди и компании начали предлагать специализированные услуги. Кроме того, развитость этого рынка свидетельствует о том, что создатели OnionCrypter предлагают покупателям настройку, чтобы сделать его еще менее заметным. В рекламе на форумах OnionCrypter часто называют «совершенно незаметным».

Информация, предоставленная исследователями Avast, упростит задачу по обнаружению OnionCrypter и любого вредоносного ПО, которое его использует.

Возвращаясь к аналогии с автомобилем, можно сказать, что исследователи лаборатории угроз Avast обнаружили важную деталь в двигателе множества вредоносных программ. Теперь ее проще найти и изучить, если она окажется в неизвестном коде — как показывает исследование Avast, в большинстве случаев это новое вредоносное ПО. Результаты работы команды Avast помогают не только клиентам компании – найденной информацией исследователи делятся и с другими разработчиками защитных решений.

По материалам  Avast

PaaS, или Как хакеры ускользают от антивирусов

Одним из главных инструментов любой хакерской группировки является вредоносное ПО. В зависимости от уровня квалификации хакеров и особенностей операции, они могут использовать как массовые, зачастую публично доступные инструменты (типичным примером может быть фреймворк Cobalt Strike), так и собственные разработки.

Создание уникального набора инструментов для каждой атаки требует большого количества ресурсов, поэтому вредоносное ПО так или иначе переиспользуется как в различных операциях одной группы, так и среди дружественных группировок. Массовое использование одного и того же инструмента неизбежно приводит к его попаданию на радары антивирусных компаний, и, как следствие, к снижению его эффективности.

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

Packer-as-a-service

Хакерская группа, стоящая за распространением RTM, до конца 2020 года регулярно проводила массовые фишинговые рассылки с вредоносными вложениями. Этот процесс, по всей видимости, происходил автоматически.

Каждое такое вложение содержало существенно отличающиеся друг от друга файлы, при этом итоговая полезная нагрузка практически не менялась.

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

При исследовании по-новому упакованных образцов нам удалось обнаружить множество другого ВПО, которое было защищено аналогичным образом. Пересечения с другими вредоносами с учетом автоматизации процесса упаковки, на наш взгляд, позволяют говорить об использовании злоумышленниками модели packer-as-a-service. В этой модели упаковка вредоносных файлов делегируется специальному сервису, которым управляет третья сторона.

Доступ к таким сервисам часто продается на хакерских форумах.

Далее мы рассмотрим конкретные примеры крипторов, которые были применены группой RTM.

Rex3Packer

Первое использование этого пакера группой RTM, которое нам удалось обнаружить, относится к ноябрю 2019 года. Активное же его применение, по нашим данным, приходится на период апрель—май 2020 года. Единичные случаи использования этого пакера для распространения старых версий трояна RTM мы также наблюдали в конце января 2021 года.

Нам не удалось связать этот упаковщик с каким-либо из ранее описанных публично, поэтому мы дали ему свое название по трем особенностям его устройства: наличию рекурсии (recursion), реверса битов (reverse), и рефлективной загрузки PE-файлов (reflection) — Rex3Packer.

Алгоритм распаковки

Общий алгоритм извлечения полезной нагрузки выглядит так:

1. С помощью VirtualAlloc выделяется заранее определенное количество памяти с правами на чтение, запись и исполнение.
2. В выделенный буфер копируется содержимое образа текущего процесса в памяти (в частности, секция .text).
3. Управление передается на функцию внутри буфера.
4. Вычисляется разница между положением одних и тех же данных в буфере и в образе PE-файла (разность между адресами в буфере и виртуальными адресами в образе). Эта разность заносится в регистр ebx. Все обращения к виртуальным адресам в коде проиндексированы содержимым этого регистра. За счет этого, везде, где это необходимо, к адресам из PE-образа добавляется поправка, которая позволяет получить соответствующий адрес в буфере. Рис. 6. Обращения к функциям и переменным с учетом поправки в регистре ebx
5. Выделяется еще один буфер под упакованные данные.
6. Через вызов VirtualProtect устанавливаются права RWX на весь регион памяти с образом PE-файла.
7. Упакованные данные копируются в свой буфер.
8. Происходит декодирование упакованных данных.
9. Регион памяти с образом PE заполняется нулевыми байтами.
10. Декодированные данные представляют собой исполняемый файл — PE-нагрузку. Эта полезная нагрузка рефлективно загружается на место исходного PE-образа, и управление передается на ее точку входа.

Отдельный интерес представляет специфический алгоритм декодирования упакованных данных. В данном случае некорректно говорить об упаковке, как о сжатии: алгоритм устроен так, что размер упакованных данных всегда больше размера исходных.

Непосредственно упакованным данным предшествует заголовок размером 16 байт, который содержит 4 поля по 4 байта:

• размер самого заголовка,
• размер исходных данных (PE-нагрузки),
• позиция в исходных данных (*), по которой происходит их разделение (об этом ниже),
• режим кодирования (1, 2, либо 4).

Декодирование выполняется следующим образом:

1. Внутри каждого байта выполняется реверс порядка битов (к примеру, 10011000 становится 00011001).
2. В зависимости от режима кодирования (1, 2, 4) данные разбиваются на блоки размером N = 9, 5, либо 3 байта соответственно. Результат декодирования блока — это (N – 1) байт (то есть 8, 4, или 2).
3. В первых N-1 байтах блока отсутствует часть битов: их значения всегда равны нулю. Чтобы восстановить оригинальные байты, с помощью масок вида 00000001, 00010001 или 01010101 из последнего байта блока извлекаются недостающие биты. При этом для каждого следующего байта маска сдвигается. То есть последний байт блока фактически составлен из объединенных логической операцией OR битов, которые извлечены из предыдущих байтов.

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

   Рис. 7. Схема получения исходных байтов в режиме 4
4. После операции по восстановлению битов во всех блоках полученные данные представляют собой исходный PE-файл, который был разделен по позиции (*) на две части. Эти части, в свою очередь, были переставлены между собой. Обратная перестановка с учетом значения (*) позволяет получить оригинальный файл.

Обфускация

Чтобы усложнить анализ, в пакере применяются несколько техник добавления «мусорного» кода :

• В промежутках между исполнением полезных команд делаются вызовы различных функций WinAPI. Их результаты сохраняются, но не используются, а сами функции выбираются так, чтобы не влиять на работу программы.

  Рис. 8. Примеры вызова функций WinAPI

• Характерная особенность данного пакера — наличие циклов (не выполняющих полезных операций), которые реализуются через рекурсивную функцию.

  Рис. 9. Функция с рекурсивным вызовом (вариант без обфускации)

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

  Рис. 10. Пример сгенерированной функции

Использование

Кроме экземпляров RTM, мы обнаружили использование Rex3Packer для упаковки различного ВПО, в основном имеющего происхождение из стран СНГ. Ниже расположен список некоторых примеров таких вредоносов.

Также мы отметили использование пакера для упаковки экземпляров ВПО из семейств Nemty, Pony, Amadey. Безусловно, приведенные нами примеры — это далеко не все случаи использования Rex3Packer.

HellowinPacker

В мае 2020 группа RTM переключилась на использование нового упаковщика, который продолжала активно использовать до начала 2021 года. Мы назвали его HellowinPacker из-за встречающихся в некоторых экземплярах строк с именем файла hellowin.wav.

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

На примере выше можно увидеть сравнение образцов 5b5f30f7cbd6343efd409f727e656a7039bff007be73a04827cce2277d873aa0 (слева) и 1f9a8b3c060c2940a81442c9d9c9e36c31ad37aaa7cd61e1d7aec2d86fe1c585 (справа).

Второй уровень меняет лишь отдельные детали при неизменной в целом структуре кода. При этом изменения главным образом затрагивают ассемблерные инструкции и не влияющие на работу программы константы. В результате в декомпилированном виде код выглядит практически идентичным.

Так же, как и в случае с Rex3Packer, мы имеем дело с массовым использованием HellowinPacker для упаковки различного ВПО. При этом вредоносное ПО из одного семейства, как правило, имеет в упакованном виде одну и ту же структуру. Это можно пронаблюдать, по крайней мере, на протяжении некоторого времени — затем структура может измениться.

Все эти особенности хорошо согласуются с описанием одного из сервисов упаковки, доступ к которому продается на хакерских форумах:

[Уникальность]Для клиента дается уникальный криптор, который не зависит от других клиентов. Если ваши файлы спалились, то только от ваших же прогрузов. Мы не набираем >10000 клиентов, только аккуратная Premium-поддержка, клиенты единичные. We make only unique stubs for a customer.

По всей видимости, в каждый такой уникальный криптор закладывается собственная структура генерируемого кода. При этом сам криптор также умеет изменять код, но уже на более низком уровне, не меняя структуру программы в целом. В любом случае содержание «полезного» исполняемого кода остается одинаковым.

Алгоритм распаковки

Одни из первых действий, которые встречаются во всех упакованных файлах — это попытки открыть ключ реестра HKEY_CLASSES_ROOT\Interface\{b196b287-bab4-101a-b69c-00aa00341d07} (регистр символов в конкретном случае может отличаться) и запросить в нем значение по умолчанию (Default). От успешности этих операций в некоторых модификациях генерируемого кода зависит корректное продолжение работы программы.

GUID интерфейса в разных случаях также может отличаться. Вот некоторые из возможных вариантов:

• {3050f1dd-98b5-11cf-bb82-00aa00bdce0b}
• {aa5b6a80-b834-11d0-932f-00a0c90dcaa9}
• {683130a6-2e50-11d2-98a5-00c04f8ee1c4}
• {c7c3f5a1-88a3-11d0-abcb-00a0c90fffc0}
• {b8da6310-e19b-11d0-933c-00a0c90dcaa9}

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

Этот блок начинается с четырехбайтного числа, которое хранит размер исходных данных (тех, которые будут получены после декодирования). Вызовом VirtualAlloc под расшифрованные данные выделяется блок памяти нужного размера с правами RWX. В выделенную память блоками по X байт копируются зашифрованные данные. При этом в оригинальном файле между этими блоками располагаются пропуски длиной Y байт.

Затем происходит процесс дешифровки блоками по 4 байта:

• очередной блок интерпретируется как целое число (DWORD),
• к его значению прибавляется индекс первого байта в блоке,
• выполняется операция XOR между полученным значением и суммой индекса и фиксированного ключа, числа Z.

Пример реализации алгоритма на Python:

def decrypt(data, Z):
    index = 0
    while index < len(data):
        dword = struct.  (index + Z)
        data[index:index + 4] = struct.pack("<I", dword)
        index += 4

Значения X, Y и Z варьируются в зависимости от конкретного упакованного экземпляра.

Внутри дешифрованных данных располагается следующая стадия извлечения полезной нагрузки — шеллкод. Он получает управление после окончания расшифровки.

Шеллкод самостоятельно загружает необходимые для своей работы функции, имена которых прописаны в таблице импорта, находящейся в начале дешифрованных данных.

Для большей вариативности строки в таблице импорта могут частично заполняться посторонними символами. Так, в примере выше, первое имя функции — GetProcAddress — полностью заменено на строку aaa45678901234; кроме того, повреждены имена VirtualAlloc и VirtualProtect. Непосредственно перед обработкой таблицы шеллкод восстанавливает корректные значения для всех символов.

Полезная нагрузка (на этот раз, это PE-файл) извлекается шеллкодом из оставшейся части дешифрованных данных. Она вновь зашифрована, причем тем же алгоритмом, который описан выше. В качестве ключа Z всегда используется число 1001.

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

Обфускация

Как и в случае с Rex3Packer, в экземплярах с HellowinPacker встречаются вызовы функций WinAPI, не относящихся к основной логике программы. Однако в данном случае они используются скорее как способ затруднить поведенческий анализ и детектирование в песочницах. В пользу этого предположения говорит то, что в большинстве случаев разнообразные функции вызываются подряд в самом начале программы.

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

При работе с различными числовыми значениями часто встречается некоторая арифметическая обфускация: необходимые константы представляются в виде суммы или разности других констант (в определенных случаях равной нулю). При этом для получения констант могут быть использованы и вызовы функций WinAPI, дающие предсказуемый результат (например, 0 в случае неудачи).

Пример такой обфускации приведен на рис. 17: единственная задача данной функции — присвоить глобальной переменной, на которую указывает target, значение аргумента source. В данном случае результат вызова GetStockObject(789644) всегда будет равняться нулю, поскольку функции передан заведомо некорректный аргумент.

Разного рода мутации встречаются и на ассемблерном уровне: вставка «мусорных» команд, непрозрачные предикаты (opaque predicates), передача неиспользуемых аргументов в функции и повторные вызовы функций, изменение инструкций на эквивалентные.

Использование

HellowinPacker существует по крайней мере с 2014 года. За это время он был использован в различном массовом вредоносном ПО. Вот лишь несколько примеров:

Пакер неоднократно упоминался в отчетах других исследователей. Самое раннее упоминание, которое нам удалось найти, относится к 2015 году. В своей статье о крипторах специалисты Malwarebytes в качестве примера исследуют образцы с HellowinPacker. Другие исследователи позже напишут о нем, как об упаковщике Emotet: (1, 2). Уже в 2020 году наши коллеги из NCC Group дадут ему название CryptOne и опишут его применение для упаковки вымогателя WastedLocker. По данным NCC Group, он также использовался в таких семействах ВПО, как Netwalker, Gozi ISFB v3, ZLoader, Smokeloader.

Заключение

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

Описанные нами упаковщики, конечно же, далеко не единственные из существующих на рынке. При этом они хорошо демонстрируют общие свойства подобного рода инструментов: в результате их работы получается исполняемый файл с обфусцированным полиморфным кодом распаковщика и шифрованной тем или иным образом полезной нагрузкой. Мутации в коде и переиспользование одних и тех же крипторов делают практически невозможным статическое детектирование полезной нагрузки. Однако поскольку эта нагрузка так или иначе расшифровывается в память и начинает свою вредоносную деятельность, поведенческий анализ с использованием песочниц (таких, как PT Sandbox) позволяет обнаруживать ВПО и давать точные вердикты даже для упакованных файлов. Помимо этого, нужно отметить, что упаковщики никак не влияют на взаимодействие вредоносов с управляющими серверами. Это даёт возможность определять присутствие ВПО в сети, используя инструменты анализа трафика – такие, как PT Network Attack Discovery.

Вердикты наших продуктов

PT Sandbox

• Trojan. Win32.RTM.a

• Trojan.Win32.RTM.b

• Trojan-Banker.Win32.RTM.a

• Trojan-Banker.Win32.RTM.b

• Trojan-Banker.Win32.RTM.c

• Trojan-Banker.Win32.RTM.d

• Trojan-Banker.Win32.RTM.e

• Trojan-Banker.Win32.RTM.f

PT Network Attack Discovery

• REMOTE [PTsecurity] TeamBot/RTM
  sid: 10004412;

• BACKDOOR [PTsecurity] TeamBot/RTM
  sid: 10004415;

• MALWARE [PTsecurity] RTM Banker CnC POST
  sid: 10000765;

• MALWARE [PTsecurity] RTM. N (Redaman)
  sid: 10005556; 10005557;

• MALWARE [PTsecurity] Spy.RTM.AF
  sid: 10005468;

• MALWARE [PTsecurity] Trojan[Banker]/RTM
  sid: 10004855; 10004875;

• MALWARE [PTsecurity] Win32/Spy.RTM.N (Redaman)
  sid: 10003414; 10004754; 10005555;

• PAYLOAD [PTsecurity] RTM.Payload.xor
  sid: 10005585;

IOCs (RTM)

Дата обнаружения	Криптор	SHA256	SHA1	MD5
19.04.2020	RTM	a4229a54f76815ac30a2a878eadf275e199c82da657dbc5f3fc05fe95603c320	ad22ceb309dd30dc769f63174292657fe07f0ced	80b116708f75de212b49ff994ad8b43e
22. 04.2020	Rex3Packer	9b88e8143e4452229dac7fdcc3d9281d21390f286c086f09aec410f120dc4325	f881729f6a5ca6fe80f385a2b0f8583b19214466	3965b819eb945a9c0defc746bbc8ed7a
13.05.2020	HellowinPacker	43e8ebacfa319ff7d871eef3cc35266cfa7c6f44dd787f27a48311e39727e10f	8a28b75285409c55d5bbeca62e3819c83c8e663f	afd18be08d135f7bf07007c1c9041126
28.01.2021	Rex3Packer (2 слоя)	fbf5974daee93bf5a2ed1816a4edbb108ceccb264d3e3f72d0aed268dd45e315	2e3352c6341ce57a03aaf2c4fbf484f3a0a4bfe3	6e0c8510443586cdc8f84330e447aae5

Статья — Современные крипторы в 2020 году — Какие они должны быть

Итак, что ждет вас в этой статье (Оглавление):

1. Введение. Теория. Что есть крипторы в 2020 году и для чего они нужны.
2. Какие они, должны-быть эти крипторы.
3. Маленький демонстрационный проект и описание как и что делается.
4. Супер-мега блокбастер. Вирус против антивирусов. Итоги.

В далекие наверно уже 2000 – 2010 года, крипторы делали для скрытия уже известного в базе вируса, смысл был такой, есть вирус, который детектится сигнатурно, для его скрытия делали следующее:

Писался загрузчик (stub) – Это минимальная программа, который из оверлея, специально созданной секции, или ресурсов загружала шифрованного зверька, делала антиэмуляцию и запускала зверька в памяти.

По сути криптор состоит из двух частей:

• Билдер – Это специальная программа, по сути отдельный проект, который шифрует зверька, помещает его в оверлей стаба, или в ресурсы, либо в специальную секцию.
• Стаб – Это уже часть криптора, который как написано выше, расшифровывает зверька, делает антиэмуляцию и запускает зверька в памяти.

Что-бы дальше было понятно, немного расскажу про виды детекта, а потом про виды крипторов уже в 2020 году и какие они должны быть)

1. Сигнатурный детект

​

Тут всё и просто, и сложно. Сигнатура может-быть по определённой контрольной сумме, например антивирус считает контрольную сумму файла (CRC32, MD5 и т. д.), и в случае если такая сумма совпала в базе. То выдаётся детект.​

​

Это называется «точечный детект» и используется часто в «облаках», что позволяет быстро выявить угрозу и нейтрализовать её.​

​

Но а действительно удобно, та-же автоматика может задетектить угрозу по каким-то признакам и быстро добавить контрольную сумму в базу.​

Но возникает проблема, что обойти это может даже трёхлетний ребёнок, добавив например один байт в конец файла и контрольная сумма уже будет другой.​

​

Также, сигнатурный детект может-быть и на часть файла, например на какую-то функцию зверька.​

По простому, антивирус исполняет ваш код в момент сканирования и если находит какие-то касяки, например «Непонравилась API» или обнаружена сигнатура вируса, или кусок такой сигнатуры, то будет детект.​

Ещё пример (мы этот пример разберём ниже, чуть позже), вы можете написать протектор, который например из дата-секции будет брать шифрованный вирус, а далее расшифровывать его, например в какой-то буфер в оперативной памяти. Казалось-бы, вирус шифрованый и антивирус его не должен детектить.​

А-нет, эмулятор расшифрует код и задетектит вирус. В общем-то для этого и нужен эмулятор кода.​

Всё-что выше, мы разбирали так-называемый «статический детект», т.е. детект, который выдаётся до запуска файла, такой детект будет если вы просканируете файл сканером, или зальёте например на вирустотал и т.д.​

​

Но нужно ещё сказать и про динамический детект. Это детект при запуске файла. Как он формируется ?​

​

У всех антивирусов по разному, например у касперского есть критерии по которому может-быть детект при запуске, например часть таких критериев: Создаёт-ли вирус процессы и как делает это, добавляется-ли вирус в автозапуск, как дербанит сеть вирус и т.д.​

​

Ну тут понятно, что даже при обходе сигнатурного детекта и эмулятора, если вирус по тупому крадёт пароли, создаёт скрытые процессы, всё это пересылает по сети, делает хук на клавиатуру, да ещё и добавляет себя в автозагрузку, то думаю детект не заставит себя ждать !​

​

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

Ошибочно думать, что облако – Это только детект по контрольной сумме. Нет это достаточно сложная система, основанная на ИИ.​

​

Например антивирус может отсылать полностью зверька в «виртуальную лабораторию», где произойдет запуск зверька и ИИ определит вирус-ли это или нет, по разным критериям, будь это репутация, где распространяется зверек и т.д.​

​

Также например, как у касперского может происходить и автоматическое помещение программы в определенную группу, например «программа для удаленного управления» и т.д., также автоматически происходит и установка «репутации программы».​

​

Поэтому у современных АВ, аналитики выполняют либо анализ по запросу, либо если у ИИ возникает какие-то спорные моменты, то зверек перейдет аналитику уже. )))​

2) Какие они, должны-быть эти крипторы.

Фу-фу, наконец-то перейдем к самим крипторам уже.

Итак вначале виды крипторов в 2020 году:

1. Натив крипторы:

Ну это крипторы, которые должны криптовать зверьков, которые написаны на нативных языках, таких-как С/С++, ассемблер, Delphi и т.д.​

​

Также крипторы могут криптовать разные разрядности зверьков, например есть крипторы для x86, а есть x64.​

​

Мы рассмотрим на практике именно такой вид криптора, для других крипторов, должны писаться отдельные статьи.​

Как видно из названия, эти крипторы криптуют только .NET и C#. (ремарка: используя модуль RunPE появится возможность крипта нативных файлов)​

​

Хорошо будет, если после этой статьи появятся статьи по крипторам C# и .NET.​

​

На самом деле на том-же C#, можно писать хорошую малварь, ничего против шарпов не имею, но я низкоуровневый программист, поэтому мало что скажу про шарпы и дот нет, максимум что там писал, это гуй…)​

​

Это по сути обфускаторы, например попадались на глаза обфускаторы батников, java и т.д.​

​

Интересно, что в таких крипторах также используют антиэмуляцию, в виде задержек sleep и т.д.)))​

​

Много про эти виды крипторов тоже писать не буду, т.к. это дело отдельной статьи.​

Итак, 2020 год, какие должны-быть крипторы, чтобы выжить:

Современные антивирусы, даже уровня виндового дефендера, имеют не хилые технологии, что-бы свести на нет распространение практически любого вируса.

Но тем не менее, если использовать крипторы правильно, это максимально усложнит детект автоматики, а соответственно увеличит время жизни зверька и уменьшит время чистки следующего билда зверька.

Если раньше крипторы использовались для обхода детекта, то в 2020 году, криптор нужно использовать уже для усложнения детектов автоматики, смысл сделать так что-бы автоматика не добралась до самого зверька, при этом под детект попадала минимальная часть криптора, для автоматизации и ускорения чистки самого криптора.
Как-же это сделать?

Есть концепт использования шелл-кодов и обфускаторов кодов.

Основная идея — это шифровка и скрытие основных частей криптора, например можно пошифровать модуль криптора, который отвечает за запуск зверька в памяти, пошифровать модуль антиэмуляции и т.д.

Эти шифрованные части можно хранить в ресурсах, дата-секции, или вообще загружать по сети.)))

Тем самым стаб будет минимален, а все остальное — это пошифрованные шелл-коды…

Шифрованные части можно прятать например в картинку и размещать на каком-то ресурсе, либо на ломанном сайте.

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

В итоге детект будет на часть криптора, которая отвечает за запуск уже шелл-кода, а это как праило 15-30 строк Си-кода, тут уже выходит на первый план обфускаторы и генераторы мусорного Си-кода.

Если все это автоматизировать, билды зверьков будут жить долго и чистка будет происходить достаточно быстро. )))

3) Маленький демонстрационный проект и описание как и что делается.

Итак, что получилось:

Решение состоит из двух проектов:
1. Первый проект LoadPeToShell — Переводит в шифрованный шелл-код модуль LoadPe, по сути создаёт заголовочный файл «loadpe.h», с шифрованным шелл-кодом.

LoadPe — Это основной модуль криптора, по сути там все.)

Антиэмуляция происходит путем вызова функции close по её хешу, то-что должна возвратить функция, это код ошибки ESTALE, на основе этого формируется ключ для расшифровки и расшифровывается пейлоад и запускается…

Немного каснусь тему антиэмуляции, вообще по хорошему также написать отдельную статью про это дело.)

Итак антиэмуляция бывает, как интеллектуальная с точки зрения реализации, так и дерьмовая.

Дерьмовая антиэмулция по моему мнению, это то-что использует атаки на ресурсы эмулятора, да у эмулятора антивируса ограничены ресурсы и если сделать задержку например 2 секунды, или делать какие-то ресурсоемкие расчёты, для получения ключа расшифровки, то скорей-всего эмулятор антивируса пропустит эту задержку и если использовать этот прием, то будет фуд. )

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

Да и интеллектуального тут ничего нет, если говорить про малварь, как искусство, какое-то извините говно…)

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

Есть и другие методы, но обсуждение антиэмуляции, лучше вынести в отдельную статью.)))

Также в LoadPeToShell шифруется пейлоад и создается заголовочный файл «payload.h».

Алгоритм шифрования RC4.

2. Второй проект. Stub — Это уже сам проект криптора.

Где происходит расшифровка шелл-кода из дата секции и запуск этого шелл-кода, пример:

— Расшифровка шелл-кода:

— Запуск шелл-кода:

В сам шелл-код нужно передать буфер шифрованного зверька и размер.

Антиэмуляция, расшифровка и запуск, уже в шелл-коде. )))

Как это сделано, можно глянуть в исходнике, который выложен на гитхабе: https://github.com/XShar/shell_crypor_framework
Как пользоваться:

• В Release положить файл, который нужно закриптовать с именем PayloadExe.exe.
• Запустить файл «LoadPeToShell.exe».
• Собрать проект в Visual Studio C++.
• Получится файл в Release «stub.exe».

*Доработка, кто хочет использовать в комерсе:

• Нужно создать генератор мусора для стаба и обфускатор си-кода. Можно использовать готовые движки, ну собственно если автоматизировать этот процесс, чистка будет весьма быстрой.
• В стабе для скрытия VirtualAlloc я использую проект lazy_importer, рекомендую отказаться от него и вообще нужно отрефакторить код, писалось на скорую руку, опять-же качество кода желает лучшего, но для демонстрации концепта подойдет.
• Сам шелл-код, как и криптованного зверька можно прятать в картинках на сайта, или в любом другом месте, тут просто опять-же для демонстрации концепта, в дата секции.

Статик детект на DarkComet (Изначально детектят все):

EGACryptor — Европейский архив генома-фенома EGA

EGACryptor

Ega-Cryptor v. 2.0.0 — это приложение на основе JAVA, которое позволяет отправителям создавать зашифрованные файлы, совместимые с EGA, а также файлы для зашифрованной и незашифрованной md5sum для каждого отправляемого файла. Приложение сгенерирует выходную папку, которая по умолчанию будет отражать структуру каталогов, содержащую исходные файлы.Эта выходная папка может быть впоследствии загружена в промежуточную область FTP EGA через клиент FTP или Aspera. Это зеркальное отображение структуры каталогов предназначено для помощи в ассоциации метаданных на портале отправителя.

Загрузить EgaCryptor

Необходимые файлы jar можно получить, загрузив файл jar EgaCrytptor

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

Новый Cryptor был создан для работы со средами выполнения Java версии 6 и выше, а также со средой OpenJDK. Пожалуйста, обратитесь к соответствующим ресурсам за инструкциями по установке. При установке последней версии OpenJDK будут включены файлы JCE. Если ваша установка Java JRE меньше 1.8.0_151, потребуется ручная установка файлов политики JCE. Вы можете проверить версию установленной Java, используя команду:

$ java -версия

 java -jar ../EGA-Cryptor_2_0_0.jar -i example1.bam 

 java -jar ../EGA-Cryptor_2_0_0.jar -i "example1.bam, example2.bam" 

 java -jar../EGA-Cryptor_2_0_0.jar -i путь / к / target / каталог 

 java -jar ../EGA-Cryptor_2_0_0.jar -i / путь / к / целевому / каталогу -o / путь / к / выходному / каталогу 

 Таблица: список параметров командной строки, встроенных в EGA-Cryptor v2.0,0. 

Параметр командной строки Действие
--------------------- -----------
-f Установите этот параметр, чтобы разрешить приложению создавать максимум
                         потоки для использования полной мощности ядер / процессоров
                         доступно на машине
-h Используйте эту опцию для просмотра встроенного меню справки
* -i Файл (ы) для шифрования. Укажите путь к файлу / папке или запятую
                         разделенный путь к файлу, если несколько файлов в двойных кавычках
-l Установите этот параметр, чтобы разрешить приложению создавать максимум
                         потоков равняется 50% мощности ядер / процессоров
                         доступно на машине
-m Установите этот параметр, чтобы разрешить приложению создавать максимум
                         потоков равняется 75% мощности ядер / процессоров
                         доступно на машине
-o Путь к выходному файлу.Это необязательно. Если не
                         при условии, что выходные файлы будут сгенерированы в
                         тот же путь, что и у исходного файла (по умолчанию: output-
                         файлы)
-t Установите этот параметр, если пользователь хочет управлять приложением в
                         создать максимальное количество потоков, как указано. Приложение будет
                         рассчитать нет. ядер / процессоров, доступных на машине
                         & создаст потоки соответственно
 

 UnixFileSystem.createFileExclusively (собственный метод) 

 Установить файлы политики юрисдикции неограниченной силы JCE 

 % cd <путь-клону>
% быстрая сборка
  

 % cd <путь-клону>
% быстрая сборка
% быстрый тест
  

  зависимости: [
.Package (url: "https://github.com/IBM-Swift/BlueCryptor.git", majorVersion: , minor: )
]
  

  github "IBM-Swift / BlueCryptor" ~> .<второстепенный>
  

  платформа: ios, '10 .0 '

    цель "MyApp" делать
        use_frameworks!
        под "BlueCryptor"
    конец
  

 let key = CryptoUtils.byteArray (fromHex: "2b7e151628aed2a6abf7158809cf4f3c")
let iv = CryptoUtils.byteArray (fromHex: «00000000000000000000000000000000»)
let plainText = CryptoUtils.byteArray (fromHex: "6bc1bee22e409f96e93d7e117393172a")

var textToCipher = plainText
if plainText.count% Cryptor.Algorithm.aes.blockSize! = 0 {
textToCipher = CryptoUtils.zeroPad (byteArray: plainText, blockSize: Cryptor.Algorithm.aes.blockSize)
}
делать {
let cipherText = попробуйте Cryptor (операция: .encrypt, алгоритм:.aes, параметры: .none, key: key, iv: iv) .update (byteArray: textToCipher) ?. final ()

print (CryptoUtils.hexString (от: cipherText!))

let decryptedText = try Cryptor (операция: .decrypt, algorithm: .aes, options: .none, key: key, iv: iv) .update (byteArray: cipherText!) ?. final ()

print (CryptoUtils.hexString (от: decryptedText!))
} catch let error {
охранник let err = error as? CryptorError else {
// Обработка ошибки, не связанной с шифрованием ...
возвращение
}
// Обработка ошибки Cryptor ... (Типы выдаваемых ошибок см. В Status.swift)
} 

 let qbfBytes: [UInt8] = [0x54,0x68,0x65,0x20,0x71,0x75,0x69,0x63,0x6b, 0x20,0x62,0x72,0x6f, 0x77,0x6e, 0x20,0x66,0x6f, 0x78,0x20,0x6a , 0x75,0x6d, 0x70,0x73,0x20,0x6f, 0x76,0x65,0x72,0x20,0x74,0x68,0x65,0x20,0x6c, 0x61,0x7a, 0x79,0x20,0x64,0x6f, 0x67,0x2e]
let qbfString = "Быстрая коричневая лисица перепрыгивает через ленивую собаку."

// Нить...
let md5 = Digest (используя: .md5)
md5.update (строка: qfbString)
пусть digest = md5.final ()

// NSData с использованием необязательной цепочки ...
пусть qbfData = CryptoUtils.data (от: qbfBytes)
let digest = Digest (используя:.md5) .update (данные: qbfData) ?. final () 

 let myKeyData = "0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b"
let myData = "4869205468657265"
пусть ключ = CryptoUtils.byteArray (fromHex: myKeyData)
пусть данные: [UInt8] = CryptoUtils.byteArray (fromHex: myData)

let hmac = HMAC (используя: HMAC.Algorithm.sha256, key: key) .update (byteArray: data) ?. final () 

 let password = "пароль"
пусть соль = соль
пусть раунды: UInt = 2
пусть производноеKeyLen = 20
делать {
let key = PBKDF.deriveKey (fromPassword: пароль, соль: соль, prf: .sha1, раунды: раунды, производная длина ключа: производная длина ключа)
пусть keyString = CryptoUtils.hexString (от: ключ)
} catch let error {
охранник let err = error as? CryptorError else {
// Обработка ошибки, не связанной с шифрованием ...
возвращение
}
// Обработка ошибки шифратора ... (см. Состояние.swift для типов выдаваемых ошибок)
} 

 пусть numberOfBytes = 256 * 256
делать {
let randomBytes = попробуйте Random.generate (byteCount: numberOfBytes)
} ловить {
  print ("Ошибка генерации случайных байтов")
}