Какая основная функция в технике atom bombing

Обновлено: 07.07.2024

Атаки на Active Directory

Специалисты IBM X-Force обнаружили новую, четвертую версию известного банковского трояна Dridex. Как оказалось, Dridex v4 — это первая малварь, взявшая на вооружение технику AtomBombing, которую в конце 2016 года представили специалисты компании enSilo.

Методика enSilo получила название «атомная бомбардировка» (AtomBombing), так как атака концентрируется вокруг использования таблиц атомов (atom table). По сути, атака не эксплуатирует никаких багов, но полагается на слабые стороны Windows. AtomBombing эксплуатирует особенности самой ОС, так как Windows позволяет модифицировать таблицы атомов и внедрять в них какой-либо код (в том числе вредоносный), который в итоге будет выполнен легитимным приложением. А внедрившись в легитимный процесс, малварь может легко остаться незамеченной для защитных механизмов.

Исследователи IBM X-Force пишут, что изучение новой версии трояна позволило им лучше понять основные этапы развития Dridex и установить время выхода разных версий. Так, Dridex v1 был запущен в конце 2014 года и просуществовал лишь до начала 2015 года. Затем ему на смену пришел Dridex v2, который тоже «прожил» недолго – до апреля 2015 года. Наиболее стабильной версией трояна стала Dridex v3, которая работала и понемногу обновлялась на протяжении двух последующих лет. По словам экспертов, за это время троян прошел огромный путь, если сравнивать начальные версии Dridex с наиболее свежими на данный момент, это практически два разных решения.

В целом Dridex v4 мало отличается от третьей версии. Малварь по-прежнему полагается на redirection-атаки, чтобы перехватить трафик пользователя, и с помощью локального прокси-сервера перенаправляет своих жертв на поддельные сайты, имитирующие настоящие банковские порталы. Кроме того, троян все еще использует hVNC (Hidden VNC – Virtual Network Computing) для установки скрытого соединения с нужными хостами, которые контролируют зараженные устройства.

По словам экспертов, одним из наиболее заметных изменений в коде Dridex v4 стало то, как банкер загружает вредоносный код в память устройства. Раньше операторы малвари полагались на вызовы различных функций Windows API, загружали фрагменты своего кода в память, а затем внедрялись в процессы браузера. Защитные решения давно научились следить за вызовами Windows API и замечать вредоносную активность Dridex и других семейств малвари, работающих по схожему принципу. Однако Dridex v4 теперь использует другую методику: «атомную бомбардировку», описанную специалистами enSilo.

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

Теперь авторы Dridex действительно взяли «атомную бомбардировку» на вооружение. Причем хакеры воспользовались proof-of-concept эксплоитом enSilo, но использовали лишь первую его часть. Вторую часть злоумышленники написали сами. В итоге атака по-прежнему эксплуатирует атомные таблицы для загрузки вредоносного кода в RWX, но использует другие вызовы API и функций, так что методы обнаружения таких атак, созданные на базе исследования enSilo, здесь бесполезны.

Эксперты IBM X-Force сообщают, что пока Dridex v4 атакует только пользователей некоторых британских банков, однако такая ситуация вряд ли сохранится долго. Ожидается, что вскоре троян, как обычно, распространит свои атаки, и вредоносная кампания охватит другие страны и другие финансовые учреждения.

Подробный анализ Dridex v4 доступен в блоге IBM X-Force. Подробнее о методике AtomBombing, в свою очередь, можно почитать в докладе специалистов enSilo.

Несколько дней назад эксперт по безопасности Тал Либерман из компании enSilo показал новую технику внедрения кода, которая влияет на все версии Windows вплоть до Windows 10. В силу природы данной техники, к сожалению, вряд ли он может быть пропатчен. В данной статье я хотел бы пролить свет на данную атаку и на ее последствия, а также рассказать, что можно сделать, чтобы защитить себя.

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

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

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

Лучшее описание, которое Вы можете найти на данный момент, — это это материал Тала в своем блоге "AtomBombing: A Code Injection that Bypasses Current Security Solutions."

Если не существует патча, а угроза заражает все версии Windows, означает ли это, что мы оказались перед лицом большой опасности?

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

Действительно что-то новенькое?

Способ, которым выполняется атака для внедрения кода, является новым, хотя, как я упоминал ранее, вредоносные программы уже многие годы используют техники внедрения вредоносного кода (например, такой подход Вы можете видеть во многих семействах шифровальщиков).

Новый, но не опасный… почему же паника?

Как я говорил, сперва вредоносная программа должна быть выполнена на машине, но мы-то знаем, что в какой-то момент это обязательно произойдет (вопрос заключается не в том, что ЕСЛИ, а в том, что КОГДА).

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

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

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

Что мы можем сделать для защиты своей корпоративной сети?

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

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

Является ли лучшим вариантом использование традиционного антивируса + антивируса следующего поколения?

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

Какие корпоративные решения сочетают возможности традиционных антивредоносных решений и техник машинного обучения?

На мой взгляд, наилучший способ — это решение, которое сочетает в себе возможности двух таких классов решений (например, Adaptive Defense 360), т.е. мощность традиционных антивредоносных решений, а также многолетний опыт использования техник машинного обучения в сочетании с Большими данными и облаком. Такой подход позволяет обоим классам решений работать вместе, обмениваться информацией, осуществлять непрерывный мониторинг всех запущенных процессов, классифицируя все программы, выполняемые на любом компьютере в Вашей корпоративной сети, и предоставляя экспертные данные в реальном времени в случае любых нарушений безопасности. В этом случае на конечные машины будет внедряться небольшой агент, который позаботится обо всем, используя облако для ресурсоемких процессов, чтобы достичь лучшего уровня производительности на рынке.

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

Действительно что-то новенькое?

Новый, но не опасный… почему же паника?

Что мы можем сделать для защиты своей корпоративной сети?

Является ли лучшим вариантом использование традиционного антивируса + антивируса следующего поколения?

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

Dridex — это банковский троян, известный своей сложностью и способностью оставаться незамеченным на устройствах, которые он заражает. Эти устройства, будучи зараженными, встраиваются в модульную бот-сеть, в которой вредоносные характеристики (внешние или свои собственные) могут быть свободно добавлены к ним через модули или библиотеки.

Первая версия появилась в конце 2014 года. В начале 2015 года было выпущено новое крупное обновление, давшее жизнь второй версии. При просмотре более ранних версий Dridex, самой стабильной и устойчивой из них стала третья версия, которая появилась в апреле 2015 года и использовалась в хорошо известных кибератаках вплоть до четвертой версии – последней известной версии, появившейся в феврале 2017 года.

Никаких других крупных обновлений для Dridex со времен демонтажа основных компонентов бот-сети, выполненного спецслужбами в 2015 году, обнаружено не было.[1]

Этот новый вариант банковского трояна содержит новые функциональные возможности. Одна из них называется AtomBombing – это функционал, предназначенный для встраивания кода без вызова подозрительных API во избежание обнаружения со стороны систем мониторинга. Она содержит технику взлома DLL для повышения своей «живучести». Наконец, были оптимизированы различные криптографические методы, используемые для получения конфигурации. [2]

2. ХАРАКТЕРИСТИКИ ТРОЯНА

Ниже приведены некоторые статические свойства анализируемого файла. Хэш трояна:

Внутренняя дата создания анализируемого образца – 16 мая 2017 года. Рассматриваемый файл был скомпилирован для исполнения в 64-битных окружениях с целью имитации легальной dll от Microsoft.

Рис 1. Свойства файла

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

Было установлено, что исполняемый файл имеет довольно большое количество разделов (всего – 11), что мы можем увидеть на рисунке 2:

Рис 2. Статичная информация анализируемого бинарного файла

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

Рис. 3. Переход к шелкоду

Первое, что делает код, — получает адреса функций, которые он будет использовать. Он делает это с помощью динамического поиска через библиотеки, загруженные программой. Для выполнения этой задачи он выполняется через структуру PEB_LDR_DATA и структуры LDR-MODULE, чтобы найти основной адрес загружаемых dll. Он обращается к начальному адресу таблицы экспорта для того, чтобы выполнить все функции, экспортируемые dll, и найти адрес искомой функции в памяти компьютера.

Рис. 4. Перечисление загруженных модулей

Шелкод, в свою очередь, проверяет, есть ли «хук» в недокументированной функции LdrLoadDll, обращаясь к ее адресу и проверяя, является ли первый бит таким же как E9 (эквивалент jmp ассемблера).

Рис. 5. Верификация хука

Если предыдущая верификация прошла успешно, он переходит к распаковке процесса памяти dll с названием “snxhk.dll”, которая является библиотекой Avast и AVG, создающей «хуки» для мониторинга процессов, происходящих в песочнице.

Рис. 6. Библиотека: snxhk.dll

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

Рис. 7. Расшифрованный исполняемый файл

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

Рис. 8. Полный процесс распаковки

3. ПРОЦЕСС ЗАРАЖЕНИЯ

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

3.2. Взаимодействие с зараженной системой
После запуска троян проверяет, является ли он единственным экземпляром вредоносной программы, запущенной на устройстве, а также проверяет, был ли он уже внедрен в процесс explorer.exe.

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

Рис. 9. Вычисление хэша

Затем, он добавляет квадратные скобки в начале и конце и разделяет их черточками, подобно COM-объекту.

Рис 10. Мьютекс, созданный в системе

Используя данный алгоритм, можно разработать вакцину, которая создает эти мьютексы в системах, чтобы избежать заражения трояном Dridex. Вредоносная программа, которая не запущена, создает папку в %WINDOWS%\system32\4

Рис. 11. Созданная папка

Вредоносная программа копирует легальный .exe в папку вместе с соответствующими .dll или .cpl. Этот .dll или .cpl не является легитимным — это и есть троян. После запуска .exe из папки, загружается вредоносный .dll или .cpl с помощью техники, известной как hijacking.

Он также программирует задачу со случайным названием (в нашем примере на рисунке 12 — это “Domitxtdoi”), которая будет запускаться каждые 60 минут.

Рис. 12.Создание задачи

В данном примере мы видим, что запускается tcmsetup.exe, после чего загружается вредоносная dll (TAPI32.dll) и начинается процесс заражения.

После программирования задачи запускается набор команд и создается правило в файерволе для explorer.exe:
netsh advfirewall firewall add rule name=«Core Networking — Multicast Listener Done (ICMPv4-In)» program=«C:\Windows\Explorer.EXE» dir=in action=allow protocol=TCP localport=any

Создание вредоносной задачи

schtasks.exe /Create /F /TN «Utdcm» /SC minute /MO 60 /TR «C:\Windows\system32\3007\tcmsetup.exe» /RL highest

Во время этого процесса вредоносная .dll будет встроена в процесс explorer.exe, используя технику AtomBombing. Затем она будет ожидать момента, когда пользователь откроет браузер (Internet Explorer, Firefox, Chrome и т.д.).

В момент, когда пользователь откроет браузер, новый шелкод будет внедрен из explorer.exe в браузер, используя ту же самую технику AtomBombing.

4. ПРИСУТСТВИЕ В СИСТЕМЕ

Для обеспечения своего присутствия в системе, выполняется ряд следующих действий. Он создает папку с четырьмя случайными цифрами в C:\Windows\System32, внутрь которой он копирует легитимный исполняемый файл Windows (не всегда один и тот же) и .dll, которая должна загружаться данным исполняемым файлом. Как раз эта .dll и будет модифицирована вредоносным кодом.

Рис. 13. Присутствие в системе

Данная техника известна как DLL-hijacking. Она использует команду, которая позволяет системе искать библиотеки/файлы, которые она собирается загрузить/использовать. В случае с рисунком выше, исполняемый файл «SystemPropertiesPerformance.exe» загрузит «SYSDM.CPL» среди других библиотек. По умолчанию, поиск файла «SYSDM.CPL» сперва будет осуществляться в той папке, где было запущено приложение. В нашем примере — это C:\Windows\ System32\1365. Если данный файл там не будет найден, то его поиск будет осуществляться в других папках в зависимости от того, как в системе настроен порядок поиска .dll файлов.

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

Чтобы выполнить файл, он создает запланированную задачу, чтобы запускать его в папке со случайными цифрами (C:\Windows\System32\1365) каждый час, как показано в предыдущей главе.

Рис. 14. Создание запрограммированной задачи

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

Продолжая наш анализ, мы видим, что он действует следующим образом:

Он перечислит все исполняемые файлы в «C:\Windows\System32\»
Он схэширует название каждого исполняемого файла и сравнит его со значением, которое было сохранено ранее. Если они совпадают, то он продолжит работу с этим исполняемым файлом.
Он прочитает IAT выбранного исполняемого файла и оттуда выберет .dll для последующей модификации.
Он прочитает IAT .dll, выбранной в п.3.
Он создаст копию вредоносного кода (саму .dll) и добавит в конце раздел со случайным названием, чтобы скопировать IAT, полученный в п.4.
Он скопирует выбранный исполняемый файл (п. 3) и модифицированную вредоносную .dll (п. 5) в случайную папку.

Вредоносная программа также создаст копию самой себя в исполняемом формате вместе с ключом реестра в AppData\Roaming\[random folder name] с маршрутом в «HKCU\Software\Microsoft\Windows\CurrentVersion\Run».

Рис. 15. Ключ реестра

5. ВНЕДРЕНИЕ ЧЕРЕЗ ATOMBOMBING

Dridex использует технику AtomBombing для записи шелкода в другие процессы, при этом не вызывая каких-либо подозрений. Это достигается через вызовы APC и одного из наиболее часто используемых объектов Windows Executive Objects под названием Atoms. Ниже представлены различные этапы внедрения в другой процесс.

5.1. Поиск целевого процесса

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

Рис. 16. Перечисление процессов

Как только он найдет процесс explorer.exe, он вызовет функцию OpenProcess для начала перечисления alertable-потоков.

5.2. Поиск alertable-потоков

Рис. 17. Alertable-потоки

На этом этапе вредоносная программа будет пытаться найти какой-нибудь поток в состоянии alertable, т.к. это позволит ей осуществить вызовы APC, чтобы выполнить код в целевом процессе.

Чтобы найти alertable-поток, троян сперва получает дескриптор для каждого потока в explorer.exe. Затем он запускает вызов в NtQueueApcThread как NtSetEvent, и ждет любой из потоков для ответа.

Если все работает корректно, то он получает первый поток, который ответил на вызов, после чего начинает внедрение кода.

5.3. Внедрение шелкода в целевой процесс

Во-первых, вредоносная .dll делает вызов в GlobalAddAtomW и создает новый Atom с тем содержимым, которое она хочет внедрить в целевой процесс (в данном случае — в explorer.exe).

Во-вторых, вредоносная .dll вызывает NtQueueApcThread, а затем отправляет в качестве параметра функцию, которая должна быть запущена процессом explorer.exe.

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

Рис. 18. Очистка памяти

Важно указать, что зона, которую Dridex выбрал для копирования шелкода, находится в ntdll, как мы можем увидеть в R8. Это вызвано тем, что ntdll всегда загружается в один и тот же начальный номер во всех процессах вне зависимости от ASLR.

В следующих итерациях функция, переданная в качестве параметра NtQueueApcThread, станет GlobalAtomGetAtomNameW, в результате чего целевой процесс получит Atom, который только что был создан вредоносной .dll, и запишет его в указанную зону таким образом, что запись его содержимого во внутрь explorer.exe не будет вызывать каких-либо подозрений.

Во-первых, он создаст IAT для шелкода.

Рис. 19. Создание IAT в explorer.exe

А после некоторых итераций он полностью скопирует шелкод в explorer.exe.

Рис. 20. Шелкод в explorer.exe

5.4. Выполнение шелкода в целевом процессе

После того как шелкод скопирован в explorer.exe, он должен быть выполнен. Для этого Dridex модифицирует функцию GlobalAtomGetAtomNameA точно так же, как был внедрен шелкод, используя Atoms. Исходный код функции:

Рис. 21. Исходная функция

Вот как была модифицирована функция:

Рис. 22. Модифицированная функция

Как Вы можете видеть, когда вы вызываете GlobalAtomGetAtomNameA в explorer.exe, программа будет выполнять шелкод. После модификации из вредоносной .dll будет осуществлен вызов в GlobalAtomGetAtomNameA, используя NtQueueApcThread.

Рис. 23. Удаленное выполнение шелкода

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

6. СЕТЕВЫЕ СОЕДИНЕНИЯ

Рис. 24. Открытый порт 443

7. ИНДИКАТОРЫ КОМПРОМЕТАЦИИ

Чтобы проверить, был ли компьютер скомпрометирован данной версией Dridex, следует учитывать следующие моменты:

Читайте также: