Слив Как хакеры обходят антивирусы

1911froct

Публикатор
Элита форума
29 Сен 2020
187
118
Статья предоставлена в образовательных целях. Мы не несём ответственность за ваши действия!

Салют, Аноним!

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

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

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

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

Packer-as-a-service
До конца 2020 года RTM регулярно распространялся через массовые фишинговые рассылки с вредоносными вложениями. Этот процесс, само собой, происходил автоматически.







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







Подобная особенность — естественное следствие применения крипторов.

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







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







Далее мы рассмотрим конкретные примеры крипторов, которые были применены для RTM.

Rex3Packer

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







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

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

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

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

  • В промежутках между исполнением полезных команд делаются вызовы различных функций WinAPI. Их результаты сохраняются, но не используются, а сами функции выбираются так, чтобы не влиять на работу программы.
  • Характерная особенность данного криптора — наличие циклов (не выполняющих полезных операций), которые реализуются через рекурсивную функцию.
  • Для дополнительного запутывания в исполняемый файл добавляется несколько десятков случайно сгенерированных функций. Они могут ссылаться друг на друга, но в процессе работы ни одна из них не получает управления.
Использование
Кроме экземпляров RTM, Rex3Packer используется для крипта других вредоносов из стран СНГ

  • Phobos Ransomware
  • Zeppelin Ransomware
  • Raсcoon Stealer
  • KPOT Stealer
  • Predator The Thief
  • QakBot
И это далеко не все случаи использования Rex3Packer.

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

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







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







Так же, как и в случае с Rex3Packer, мы имеем дело с массовым использованием HellowinPacker для упаковки различной малвари.

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

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

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







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

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

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





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




Пример обфускации на уровне ассемблерного кода

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

  • Cerber Ransomware
  • ZLoader
  • Dridex
  • Bunitu
  • QakBot
Заключение
Как ты видишь, дорогой друг, разделение обязанностей существует и в хакерской среде. Разработка вредоносной нагрузки, ее защита от антивирусов (крипт) и доставка жертве может выполняться совершенно не связанными между собой хакерами, при этом каждый элемент в этой цепочке может предоставляться как сервис. Такой подход снижает порог входа для технически не подготовленных киберпреступников: для проведения массовой атаки достаточно обладать лишь необходимой суммой денег на оплату всех сервисов.

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

Звучит сложно? Не бойся, не все так страшно, ведь при использовании криптора тебе необходимо лишь нажать кнопку и подсунуть файл со зловредом. А захочешь - в дальнейшем вникнешь в техническую сторону вопроса.
 
  • Симпатия
Реакции: MRX_101001