{
	"id": "6e306d91-ac7e-4bbe-a69f-4684933ea603",
	"created_at": "2026-04-06T00:14:40.974519Z",
	"updated_at": "2026-04-10T03:25:23.261939Z",
	"deleted_at": null,
	"sha1_hash": "a87fca2a697ac1045abaca6f7e63591d68187dbe",
	"title": "Как буткиты внедряются в современные прошивки и чем UEFI отличается от Legacy BIOS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1839936,
	"plain_text": "Как буткиты внедряются в современные прошивки и чем\r\nUEFI отличается от Legacy BIOS\r\nBy ptsecurity\r\nPublished: 2022-05-27 · Archived: 2026-04-05 15:38:05 UTC\r\nПривет, Хабр! На связи Антон Белоусов и Алексей Вишняков, и мы продолжаем вместе с вами изучать\r\nбуткиты — наиболее опасный класс вредоносного ПО. Гонка вооружений между разработчиками решений\r\nв области ИБ и вирусописателями не останавливается ни на секунду: первые активно внедряют новые\r\nмеханизмы противодействия киберугрозам, а вторые — инструменты их обхода. Как раз с точки зрения\r\nбезопасности нас заинтересовал современный стандарт предзагрузки операционных систем UEFI.\r\nПоэтому в этом посте мы решили:\r\nразобраться, чем загрузка в режиме UEFI отличается от загрузки в режиме Legacy BIOS;\r\nрассказать о новых экземплярах буткитов, нацеленных на компрометацию UEFI;\r\nвыяснить, похожи ли они на своих предшественников (обширную группу так называемых legacy-буткитов мы подробно изучили в прошлый раз);\r\nрассмотреть используемые злоумышленниками техники и слабые места систем на платформе UEFI.\r\nКто не хочет читать много букв, может ознакомиться с этой же информацией в формате\r\nвебинара. Такой же уровень полезности гарантируем!\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 1 of 11\n\nБуткиты бывают двух типов. Первые заточены на более ранние платформы, так называемые Legacy BIOS.\r\nВторые адаптированы под современные решения, которые имеют универсальный интерфейс UEFI для\r\nсвязи ОС с программами, которые управляют низкоуровневыми функциями устройств (далее — UEFI,\r\nпрошивка).\r\nНесмотря на более современный подход к обеспечению безопасности UEFI, в коде его прошивок\r\nрегулярно обнаруживают уязвимости. Например, в феврале этого года наши коллеги из компании Binarly\r\nвыявили более двух десятков брешей в UEFI, которые затрагивают миллионы устройств от крупнейших\r\nпроизводителей. Злоумышленники, конечно же, не дремлют и стараются их активно эксплуатировать.\r\nПоэтому актуальность исследования защищенности платформы только растет. Большинство буткитов\r\nуниверсальны. Например, ESPecter и FinSpy умеют заражать как старые, так и новые платформы. Одним\r\nиз недавно обнаруженных UEFI-буткитов стал MoonBounce.\r\nАрхитектура UEFI\r\nUEFI (Unified Extensible Firmware Interface, единый интерфейс расширяемой прошивки) — это небольшая\r\nоперационная система, которая начинает работать при включении компьютера. Она пришла на замену\r\nустаревшей модели BIOS. UEFI позволяет унифицировать процесс разработки и создавать отдельные\r\nмодули, а не только прошивку целиком. Фреймворк имеет хорошо читаемый и документированный код на\r\nC. Многие пользователи отмечают удобный интерфейс, который разрешает пользоваться мышью. Среди\r\nдругих преимуществ платформы — поддержка сети «из коробки» и возможность работать с дисками\r\nобъемом более 2 ТБ. Все это позволяет ускорить процесс разработки и сделать его безопаснее.\r\nИнтерфейс UEFI\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 2 of 11\n\nВычисление размера диска\r\nПо требованиям платформы диск должен быть размечен в формате GPT. Соответственно, длина адреса\r\nблока будет равна 64 битам. Опираясь на эти данные, давайте вычислим гипотетический размер диска,\r\nкоторый можно адресовать с помощью этого формата. Если использовать сектор размером 512 байтов,\r\nполучим более 9 зеттабайт.\r\nКод для инициализации оборудования, в том числе код для загрузки ОС, разумеется, важный элемент\r\nплатформы, однако наибольший интерес для нас представляет интерфейс, который позволяет\r\nвзаимодействовать с UEFI.\r\nВысокоуровневый взгляд на UEFI\r\nПриложения и драйвера UEFI имеют две таблицы для работы с API-интерфейсом — EFI Boot Services\r\nTable (службы доступны в процессе загрузки) и EFI Runtime Services Table (службы доступны и в процессе\r\nзагрузки, и в процессе работы ядра ОС). API-интерфейс необходим, чтобы взаимодействовать с\r\nоборудованием, выделять память и выполнять другие простые функции по аналогии с WinAPI.\r\nEFI Boot Services Table и EFI Runtime Services Table\r\nКак мы уже говорили ранее, прошивку UEFI можно дополнять модулями. Утилита UEFI Tool позволяет\r\nпарсить файлы прошивок различных вендоров. Например, файл прошивки Asus содержит множество\r\nдрайверов и модулей. С помощью этой утилиты в процессе разработки можно менять, удалять или\r\nдобавлять модули в зависимости от случая.\r\nФайл прошивки Asus, открытый в UEFI Tool\r\nНапомним схему цепочки программ в Legacy BIOS (ее мы рассматривали в прошлой статье).\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 3 of 11\n\nПри переходе к UEFI такие компоненты, как MBR и VBR, исчезают, и их функции частично берут на себя\r\nдругие модули.\r\nВ UEFI процессор тоже стартует в реальном режиме, но переключение происходит на раннем этапе\r\nисполнения кода прошивки. За счет этого компоненты, которые находятся в файловой системе и\r\nзатрагивают ОС, сразу работают в защищенном режиме.\r\nКод UEFI достаточно сложный. Он включает семь стадий работы прошивки: Security, Pre-EFI Initialization,\r\nDriver Execution Environment, Boot Device Selection, Transient System Load, Runtime и Afterlife. Что\r\nинтересно, работа на стадии SEC происходит во временной памяти, формирующейся из кэша процессора.\r\nНа этом уровне прошивка становится корнем доверия всей системы.\r\nНа стадии DXE выполняются DXE-драйверы для устройств. Именно на данном этапе злоумышленникам\r\nудобнее всего встраивать вредоносные сущности в полезную нагрузку. BDS — стадия выбора загрузочного\r\nустройства, которое отвечает за запуск ОС. Runtime — стадия работы ОС. Afterlife — стадия завершения\r\nработы компьютера.\r\nСтадии кода UEFI Источник: https://edk2-docs.gitbook.io/edk-ii-build-specification/2_design_discussion/23_boot_sequence\r\nNVRAM-переменные помогают UEFI понимать, с какого устройства требуется загрузиться. Они хранятся\r\nв энергонезависимой памяти. Есть стандартные переменные и те, которые определяют разработчики\r\nплатформ. Например, переменные db и dbx используются Secure Boot, они содержат базу данных с\r\nключами и хешами.\r\nНам интересна переменная BootOrder, определяющая порядок загружаемых устройств, и переменная\r\nBoot#### с номером устройства.\r\nЕсли рассмотреть дамп переменной Boot004 (она относится к первому устройству в списке BootOrder),\r\nможно обнаружить путь к менеджеру загрузки bootmgfw.efi. Так переменная указывает прошивке, где\r\nискать менеджер загрузки. В переменной также есть отсылка в виде GUID на хранилище параметров\r\nзагрузки BCD (Boot Configuration Data). В зависимости от системы важные данные можно сохранять\r\nнепосредственно в NVRAM-область.\r\nНиже представлена схема диска, размеченного с помощью GPT. В нулевом секторе расположен Protective\r\nMBR. Его формат предполагает всего один раздел, описывающий весь диск. Намеренно указывается\r\nспециальный диск этого раздела: это необходимо, чтобы компьютер без поддержки UEFI мог распознать\r\nдиск формата GPT и случайно не затер его.\r\nВ первом секторе размещен заголовок. Он содержит параметры диска, разметку и адреса смещения\r\nданных.\r\nСхема диска, размеченного GPT\r\nЗа первым сектором следует таблица разделов. В ней 128 элементов, каждый из которых описывает\r\nопределенный логический раздел на диске.\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 4 of 11\n\nСтруктура элемента таблицы\r\nБольше всего интересен первый элемент — type (член структуры, описывающей раздел), который\r\nпозволяет найти раздел EFI System Partition. Там расположен менеджер загрузки.\r\nРаздел EFI System Partition\r\nРаздел EFI System Partition имеет структуру формата FAT32, содержит таблицы кластеров, адрес корневой\r\nдиректории и древовидную структуру расположения всех файлов. Его можно распарсить, прочитать и\r\nнайти все необходимые файлы. Например, для Windows есть специальная утилита mountvol.exe,\r\nпозволяющая смонтировать по умолчанию скрытый раздел EFI System Partition и посмотреть его\r\nсодержимое. Для этого необходимо указать ключ /S и букву диска, куда его следует смонтировать. В\r\nдиректории, которая была в NVRAM-переменной, находится файл менеджера загрузки. Помимо него, там\r\nесть и другие файлы: модуль, отвечающий за работу отладчика, и файл BCD (куст реестра с BCD-параметрами). Параметры будут необходимы в процессе работы менеджера загрузки и инициализации\r\nсистемы.\r\nИспользование утилиты mountvol.exe\r\nМенеджер загрузки является UEFI-приложением, поэтому должен соответствовать соглашению о точке\r\nвхода. Точка входа менеджера загрузки имеет определенную сигнатуру. Ее второй параметр — SystemTable\r\n— указывает на структуру, которая, в свою очередь, содержит указатели на таблицу RuntimeServices и\r\nтаблицу BootServices. Их задача — предоставить API-интерфейс для работы с оборудованием.\r\nТочка входа менеджера загрузки\r\nДавайте обобщим ключевые отличия загрузки в режиме UEFI от загрузки в режиме Legacy BIOS:\r\nпереключение режимов выполняется UEFI на ранней стадии;\r\nдля работы с оборудованием используется API-интерфейс, в частности RuntimeServices и\r\nBootServices;\r\nменеджер загрузки (bootmgf.efi) инициализирует механизм проверки целостности кода (Code\r\nIntegrity);\r\nзагрузчик ОС winload.efi заворачивает UEFI-сервисы для использования ядром через HAL.\r\nИзучаем Secure Boot\r\nНа наш взгляд, самый интересный компонент прошивки UEFI — Secure Boot. Его архитектура хорошо\r\nописана и проиллюстрирована в книге «Руткиты и буткиты. Обратная разработка вредоносных программ и\r\nугрозы следующего поколения» (12+) за авторством Алекса Матросова, Евгения Родионова и Сергея\r\nБратуся.\r\nВ основе Secure Boot лежит набор ключей разного уровня. Самый важный среди них — platform key (PK),\r\nкоторый содержится в прошивке. Начальный PK верифицирует key exchange key (KEK).\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 5 of 11\n\nСтоит отметить, что существует две базы ключей:\r\ndb — база ключей для аутентификации, отвечает за проверку подписей модулей;\r\ndbx — база запрещенных ключей и хешей.\r\nСогласно алгоритму работы Secure Boot, при загрузке нового модуля проверяется не только его подпись,\r\nно и хеш. Дело в том, что бывают модули UEFI-драйверов с абсолютно легитимными подписями. При\r\nобнаружении критически опасной уязвимости, даже если модуль пройдет проверку подписи, но его хеш\r\nбудет отмечен в базе исключений, он не будет допущен к загрузке и исполнению.\r\nUEFI-модули могут быть двух форматов:\r\n·       Portable Executable (привычный для Windows);\r\n·       Terse Executable. Этот формат похож на Portable Executable, но лишен части полей и имеет\r\nдругие сигнатуры. \r\nАлгоритм работы Secure Boot Источник: https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot\r\nКак работает UEFI-буткит\r\nЕсть два варианта заражения:\r\n1.     Заражение прошивки\r\n2.     Заражение в EFI System Partition, в частности:\r\n·       подмена bootmgfw.efi\r\n·       добавление нового модуля\r\nИзвестны успешные атаки, в ходе которых злоумышленникам удавалось перезаписать код в SPI-чипе, то\r\nесть, по сути, заразить его. Позднее появилась пара буткитов, нацеленных на компрометацию менеджера\r\nзагрузки.\r\nНа данный момент мы можем выделить два вектора атаки на UEFI-платформу: перепрошивка SPI и\r\nмодификация менеджера загрузки. Касательно второго вектора следует выделить частный случай\r\nдобавления нового модуля в раздел EFI System Partition и последующего изменения пути в NVRAM-переменной, которая указывает, с какого устройства необходимо загрузиться.\r\nПервая ласточка — буткит LoJax\r\nПервый UEFI-буткит был найден и описан специалистами ESET. В LoJax использовался подход\r\nперезаписи содержимого прошивки. Другими словами, он считывал прошивку, находил маркеры, что-то\r\nдобавлял и записывал обратно.\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 6 of 11\n\nСхема работы буткита LoJax Источник: https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf\r\nВажно понимать, что чип SPI представляет собой некое PCI-устройство. Следовательно, чтобы с ним\r\nвзаимодействовать нужен особый интерфейс. Поэтому чтение и запись содержимого чипа — это\r\nмногоступенчатая и сложная операция, включающая работу с различными флагами и параметрами. Если\r\nизучить код одного из модулей LoJax, умеющих читать и писать в SPI, можно убедиться, что это\r\nдействительно PCI-устройство. В модуле прописан PCI-адрес устройства, а с устройством этот модуль\r\nвзаимодействует посредством драйвера с помощью функции DeviceIoControl.\r\nИнтерфейс работы с SPI непрозрачен. Кроме того, механизмы безопасности защищают его от простого\r\nсчитывания. В случае LoJax в основу подхода по компрометации легла эксплуатация уязвимости race\r\ncondition. Стоит отметить, что данная уязвимость присутствует не во всех системах. У SPI-чипа есть набор\r\nфлагов, управляющих не только разрешением на запись, но и его блокировкой. Один из флагов можно\r\nсбросить с помощью кода, работающего в режиме System Management Mode (SMM). Это\r\nпривилегированный режим, в котором приостанавливается исполнение другого кода, в том числе кода ОС\r\nи гипервизора. Как только происходит попытка записи, SMM блокирует возможность записывать. Поэтому\r\nсоздатели буткитов используют два потока. Таким способом они одновременно пытаются сбросить\r\nзащитные флаги и записать что-то в чип.\r\nСхема эксплуатации race condition для перезаписи SPI Источник:\r\nhttps://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf\r\nЧтобы взаимодействовать c PCI-устройством, LoJax использует драйвер в составе\r\nутилиты Read \u0026 Write Everything. Утилита позволяет работать с низкоуровневыми компонентами системы:\r\nфизической памятью, устройствами ввода-вывода и другими. Чтобы выполнять функции чтения-записи\r\nфизической памяти, взаимодействия с устройствами и различными низкоуровневыми подсистемами и\r\nнастройками, она имеет подписанный легитимный драйвер, который как раз и использовали разработчики\r\nLoJax.\r\nОтметим, что PCI-устройства должны следовать соглашениям и в том числе иметь в своем составе блок\r\nданных PCI Configuration Space. PCI Configuration Space находится непосредственно в PCI-устройстве.\r\nЧтобы читать этот блок или записывать в него, есть два порта ввода-вывода: 0xCF8 и 0xCFC.\r\nСтруктура PCI Configuration Space Источник: https://en.wikipedia.org/wiki/PCI_configuration_space\r\nЧерез порт PCI_COFIG_ADDRESS указывается адрес внутри блока данных, откуда можно считать (read)\r\nили записать (write) данные. Так, можно считать данные из PCI Configuration Space, например\r\nидентификатор устройства или его производителя, а также специфические для этого устройства значения.\r\nПорт PCI_CONFIG_DATA используется для считывания и записи данных. Направление зависит от\r\nприменяемой инструкции: IN — считывание, OUT — запись.\r\nКроме того, у PCI-устройства есть Base Address Registers — область, содержащая специфические значения\r\nдля данного устройства. Например, адрес в физической памяти, куда отображены управляющие регистры\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 7 of 11\n\nSPI. По сути, за счет взаимодействия с PCI-регистрами, отображенными в физической памяти, и\r\nвыполняется чтение прошивки и запись в нее.\r\nФункция записи и чтения прошивки\r\n Обращаем внимание, что в памяти отображается не содержимое чипа, а, например, четыре или восемь\r\nбайтов, каждый из которых может быть либо флагом, либо управляющим значением. Эти значения\r\nизменяются — и выполняется взаимодействие. Если расписать последовательность шагов, то сначала мы:\r\nсчитываем PCI-регистры из Base Address Registers с помощью портов CF8 и CFC;\r\nполучаем адрес регистров, отображенных в физической памяти;\r\nпишем в отображенные регистры команды управления, в частности указываем адрес, откуда\r\nнеобходимо считать новую прошивку.\r\nВсе перечисленные операции выполняются в цикле. Он включает установку контрольного флага, начало\r\nчтения (или записи) и изменение дополнительных параметров.\r\nМанипуляция с байтами в сегменте физической памяти\r\nЭти, на первый взгляд, сложные манипуляции помогают буткиту LoJax достичь цели: записать\r\nвредоносный код в прошивку, заменить модуль с легитимным кодом на свой и исполнить его на ранней\r\nстадии загрузки системы. Так он будет недосягаем для антивирусов и других средств защиты, а атакующие\r\nсмогут получить необходимый им persist.\r\nЗнакомьтесь: MosaicRegressor\r\nЕще один интересный буткит — MosaicRegressor, исследованный специалистами «Лаборатории\r\nКасперского». В его случае начальный вектор заражения неизвестен, то есть никто не знает, как буткит\r\nбыл установлен.\r\nВ зараженной прошивке исследователи обнаружили четыре модуля, два драйвера и два приложения,\r\nисполняющих вредоносную нагрузку. Рассмотрим их подробнее. Первым исполняется модуль\r\nSmmInterfaceBase. В его задачу входит создание c помощью API-функции CreateEventEx события\r\nEVENT_GROUPR_READY_TO_BOOT. Это событие наступает перед тем, как управление передается\r\nменеджеру загрузки. Тогда же вызывается обратный вызов NotifyFunction.\r\nСостав модулей MosaicRegressor\r\nИнтересно, что происходит внутри callback? Давайте посмотрим. С помощью уникального\r\nидентификатора приложения (GUID) обнаруживается модуль SmmAccessSub. Затем он запускается.\r\nВ этом модуле SmmAccessSub, по нашему мнению, довольно тривиальный подход к persist. Он\r\nзаключается в сбросе пользовательского модуля в папку Startup. При этом никаких действий с драйверами\r\nили подмен не происходит. \r\nЕще одним модулем в зараженной прошивке был SmmReset. Он сбрасывает значение EFE до нуля.\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 8 of 11\n\nБуткит MosaicRegressor не использует SmmReset, однако модуль для работы с точно такой же переменной\r\nесть в утекшем репозитории Hacking Team и применяется, чтобы определить, заражена прошивка или нет.\r\nФрагмент кода из репозитория vector-edk. Установка флага заражения прошивки Источник:\r\nhttps://github.com/hackedteam/vector-edk/\r\nMoonBounce — самый примечательный экземпляр\r\nMoonBounce можно назвать новинкой в списке буткитов, угрожающих UEFI. Его обнаружили в конце\r\nянваря 2022 года. Вредонос отличает сложная и интересная схема заражения. Так же, как и в случае с\r\nMosaicRegressor, начальный вектор проникновения неизвестен.\r\nВ прошивке буткит начинает работать до стадии исполнения драйверов. При этом вредоносные действия\r\nвыполняются не в драйвере, а непосредственно в коде прошивки — в начале стадии DXE. Принцип работы\r\nMoonBounce следующий: буткит перехватывает несколько функций Boot-сервисов. Первая функция\r\nразмещает в памяти шеллкод уровня Ring 0, другая — перехватывает функцию, которая передает\r\nуправление ядру ОС, а затем перехватывает функцию выделения памяти внутри ядра ExAllocatePool. Все\r\nэто MoonBounce делает, чтобы исполнить шеллкод, который был «замаплен» еще на стадии работы\r\nпрошивки. Дальше в дело вступает сам шеллкод: он загружает и вызывает вредоносный драйвер, который\r\nобладает возможностями руткита. Как вы, наверное, уже поняли, необычно здесь то, что случилось не\r\n«аккуратное внедрение» модуля, а заражение всей прошивки.\r\nПринцип работы MoonBounce Источник: https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/\r\nАтаки на Boot-менеджеры\r\nАтаки на Boot-менеджеры рассмотрим на примере буткитов FinSpy и ESPecter. FinSpy, также известный\r\nкак FinFisher, подменяет оригинальный менеджер загрузки на вредоносный. В частности, при передаче\r\nуправления от UEFI к менеджеру загрузки вызывается вредоносный менеджер, который выполняет\r\nнекоторые функции (например, перехватывает функции передачи управления ядру или патчит код,\r\nответственный за проверку цифровых подписей), а затем загружается оригинальный Boot-менеджер.\r\nСодержимое зараженного EFI System Partition и код для монтирования EFI System Partition Источник:\r\nhttps://securelist.com/finspy-unseen-findings/104322/\r\nДля заражения раздела EFI System Partition злоумышленникам достаточно воспользоваться банальным\r\nнабором API. Это позволяет им смонтировать раздел и в дальнейшем работать с ним, как с любым другим\r\nдиском.\r\nАлгоритм работы FinSpy выглядит так:\r\nподмененный Boot-менеджер загружает оригинальный Boot-менеджер;\r\nподменный менеджер патчит в оригинальном функцию, передающую управление сначала\r\nзагрузчику, а затем ядру.\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 9 of 11\n\nВторое действие позволяет перехватить ядерную функцию создания системного потока. Она, в свою\r\nочередь, дает возможность сбросить вредоносную нагрузку. Прошивка UEFI в этой атаке затронута не\r\nбыла.\r\nESPecter замыкает пятерку буткитов, на текущий момент известных исследователям. Его корни уходят как\r\nминимум в 2012 год. В процессе своей работы ESPecter патчит менеджер загрузки, чтобы заменить\r\nлегитимный драйвер (либо beep.sys, либо winsys.dll) на вредоносный. Кроме того, загрузчик буткита\r\nпатчит проверку целостности загрузчика (да-да, загрузчик проверяет сам себя на пропатченность).\r\nЛогика работы ESPecter Источник: https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nБуткит ESPecter отключает проверку цифровой подписи драйверов, чтобы загрузить в систему подменный\r\nbeep.sys или winsys.dll и запустить его.\r\nВредоносный код, позволяющий обойти проверку цифровой подписи Источник:\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nПодмена легитимного драйвера на вредоносный при выключенной проверке подписи драйверов Источник:\r\nhttps://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/\r\nВ ядре Windows предусмотрена функция, отвечающая за инициализацию проверки целостности. Если ее\r\nзапатчить и приравнять к нулю переменную CiOptions, проверки будут проходить так, словно драйверы\r\nподписаны. Этот подход ESPecter применяет для legacy-систем.\r\nЧто это за зверь такой — System Management Mode\r\nРассказывая о буткитах, нельзя не упомянуть System Management Mode — привилегированный режим\r\nработы процессора. Он необходим для управления электропитанием и проприетарными функциями (их\r\nопределяют сами вендоры).\r\nРасширенная схема уровней привилегий в ПК Источник: https://medium.com/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831\r\nРежим SMM, который часто еще называют Ring -2, непрозрачен для ОС. Переходя в него, процессор\r\nможет выполнять код. Код обычно находится в области памяти SMRAM. Она начинается с адреса\r\nSMBASE. SMBASE по дефолту имеет фиксированный адрес, но также может меняться с помощью\r\nспециальных MSR-регистров. В режиме SMM процессор сохраняет весь свой контекст (значения почти\r\nвсех регистров в верхней области памяти).\r\nПерейти в режим SMM процессор может несколькими способами. Например, он может выполнить\r\nпрерывание (System Management Interrupt, SMI). Выделяют три вида прерывания:\r\n·       аппаратное,\r\n·       системное,\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 10 of 11\n\n·       программное.\r\nС позиции атакующего системные прерывания сложны в реализации. Тогда как программные вполне\r\nможно вызвать кодом на уровне драйвера. Для этого на порты b3 и b2 необходимо отправить определенное\r\nзначение (оно отличается для разных устройств), и процессор переключится в режим SMM.\r\nФрагмент кода из фреймворка CHIPSEC для вызова программного SMI Источник:\r\nhttps://github.com/chipsec/chipsec/blob/main/drivers/win7/amd64/cpu.asm\r\nВысокоуровневое представление процесса обновления BIOS из ОС Источник: Rootkits and Bootkits by Alex\r\nMatrosov, Eugene Rodionov, and Sergey Bratus (No Starch Press, 2019)\r\nРежим SMM опасен еще и тем, что имеет доступ ко всей памяти системы. Из этого вырисовывается\r\nнесколько возможных вариантов эксплуатации: использование руткита с доступом к системе либо\r\nперезапись содержимого чипа SPI. SMM имеет много уязвимостей, преимущественно\r\nвендороспецифичных, например, SMM Callout, которая позволяет выполнить код в режиме SMM за\r\nпределами SMRAM. Убедиться в неиллюзорности угроз можно, ознакомившись со списком уязвимостей.\r\nПо большей части они характерны либо для конкретного девайса, либо фреймворка.\r\nРезюме\r\nВ заключение кратко перечислим главные моменты статьи:\r\nUEFI-буткиты могут обойти все механизмы защиты и получить контроль над всей системой;\r\nSPI-буткит невозможно удалить ни переустановкой ОС, ни форматированием жесткого диска;\r\nдля борьбы с буткитами есть механизмы защиты, такие как Secure Boot и Intel Boot Guard, но они не\r\nпанацея;\r\nнаибольшую опасность сегодня представляют уязвимости в режиме SMM и подсистеме Intel ME.\r\nКак эффективно обнаруживать UEFI-буткиты, расскажем на следующем вебинаре. Stay tuned!\r\nПосмотреть видеоверсию статьи и скачать презентацию вы можете на сайте Positive Technologies.\r\nАвторы:\r\nАнтон Белоусов, старший специалист отдела обнаружения вредоносного ПО экспертного центра\r\nбезопасности Positive Technologies\r\nАлексей Вишняков, руководитель отдела обнаружения вредоносного ПО экспертного центра\r\nбезопасности Positive Technologies\r\nSource: https://habr.com/ru/amp/post/668154/\r\nhttps://habr.com/ru/amp/post/668154/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "RU",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://habr.com/ru/amp/post/668154/"
	],
	"report_names": [
		"668154"
	],
	"threat_actors": [
		{
			"id": "a3687241-9876-477b-aa13-a7c368ffda58",
			"created_at": "2022-10-25T16:07:24.496902Z",
			"updated_at": "2026-04-10T02:00:05.010744Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "ETDA:Hacking Team",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e90c06e4-e3e0-4f46-a3b5-17b84b31da62",
			"created_at": "2023-01-06T13:46:39.018236Z",
			"updated_at": "2026-04-10T02:00:03.183123Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "MISPGALAXY:Hacking Team",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434480,
	"ts_updated_at": 1775791523,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a87fca2a697ac1045abaca6f7e63591d68187dbe.pdf",
		"text": "https://archive.orkl.eu/a87fca2a697ac1045abaca6f7e63591d68187dbe.txt",
		"img": "https://archive.orkl.eu/a87fca2a697ac1045abaca6f7e63591d68187dbe.jpg"
	}
}