Прогосударственые хакерские группы уже давно и успешно используют буткиты — специальный вредоносный код для BIOS/UEFI, который может очень долго оставаться незамеченным, контролировать все процессы и успешно пережить как переустановку ОС, так и смену жесткого диска. Благодаря тому, что подобные атаки сложно выявить (вендорам ИБ удалось лишь дважды самостоятельно обнаружить такие угрозы!), наблюдается рост интереса к подобному методу заражения компьютеров и среди финансово мотивированных преступников — например, операторов TrickBot. Семен Рогачев, специалист по исследованию вредоносного кода Group-IB, рассказывает как охотиться за подобными угрозами в локальной сети и собрать свой тестовый стенд с последним из обнаруженных UEFI-буткитов Mosaic Regressor. Бонусом - новые сетевые индикаторы компрометации, связанные с инфраструктурой Mosaic Regressor, и рекомендации по защите в соответсвии с MITRE ATT&CK и MITRE Shield.
Давайте начнем с небольшой исторической справки.
> В 2013 году Себастьен Качмарек (Sebastien Kaczmarek) из QuarksLab создал PoC-буткит Dreamboot, использующий UEFI для атаки на загрузчик ОС. Его исходный код доступен на GitHub. Следует отметить, что данный буткит работал только при отключенном механизме Secure Boot, и в том же году на конференции BlackHat USA 2013 был представлен доклад "A Tale of One Software Bypass of Windows 8 Secure Boot", в котором авторы описали первый публичный способ обхода этого механизма.
> В 2014 году Рафаль Войтчук (Rafal Wojtczuk) и Кори Калленберг (Corey Kallenberg) опубликовали информацию об уязвимости Darth Venamis в механизме S3 Resume. Это механизм, определяющий продолжение работы компьютера после выхода из состояния сна. В результате исследования выяснилось, что область памяти, в которой хранится S3 BootScript (список команд, проводящих инициализацию устройств после выхода из состояния сна), не защищена от модификации, что приводит к различным уязвимостям. Эта же уязвимость использовалась, предположительно, ЦРУ для установки имплантов. Почитать об этом можно здесь, здесь и здесь.
> В 2015 году Кори Калленберг и еще один исследователь, Ксено Ковах (Xeno Kovah), представили LightEater — руткит, позволяющий получать различную важную информацию (ключи шифрования и прочее) за счёт прямого доступа к физической памяти и постраничного поиска с использованием сигнатур.
> В том же году, после утечки данных из компании HackingTeam, был обнаружен фреймворк Vector-EDK, разработанный для внедрения имплантов в UEFI-based прошивки. Этот же фреймворк использовался для разработки Mosaic Regressor.
> В 2016 году Дмитро Олексюк (Dmytro Oleksiuk) создал PeiBackdoor — первый публично доступный UEFI-руткит, загружаемый на этапе PEI (Pre-EFI Initialization).
> В том же году из-за утечки документов Equation Group (по некоторым источникам, связана с АНБ США) появилась информация о существовании BIOS-модуля BANANABALLOT, загружающего некий имплант для взаимодействия с роутерами CISCO.
> В 2017-м WikiLeaks опубликовали информацию о DerStarke — UEFI-версии бэкдора Triton для macOS.
> В 2018-м компания ESET нашла и проанализировала UEFI-руткит LoJax — первый UEFI-буткит, обнаруженный ИБ-компаниями in the wild.
> В октябре 2020 года Лаборатория Касперского в процессе расследования атаки обнаружила Mosaic Regressor — UEFI-буткит, созданный с использованием инструментов, полученных из утечки данных HackingTeam.
> В декабре 2020-го зафиксирована новая версия TrickBot, которая обладает функциональными возможностями по внедрению кода UEFI. На данный момент нет свидетельств активного внедрения UEFI-имплантов in the wild TrickBot’ом, но сам факт появления подобного функционала говорит о том, что злоумышленники интересуются подобными атаками.
Даже этот неполный список прекрасно демонстрирует, насколько актуальны и опасны атаки, связанные с UEFI. В последние несколько лет количество публично выявленных уязвимостей в прошивках удваивается каждый год, что приводит к явному увеличению интереса со стороны киберпреступников и активному росту количества выявленных таргетированных атак.
Создание стенда с UEFI-буткитом
Mosaic Regressor состоит из нескольких модулей, которые описаны в таблице.
Имя модуля | GUID | Тип модуля | Описание |
SmmInterfaceBase | F50258A9-2F4D-4DA9-861E-BDA84D07A44C | DXE-драйвер | Драйвер, запускающий приложение SmmAccessSub перед передачей управления загрузчику ОС (после получения события EFI_EVENT_GROUP_READY_TO_BOOT) |
Ntfs | F50258A9-2F4D-4DE9-86AE-BDA84D07A41C | DXE-драйвер | Драйвер, позволяющий взаимодействовать с файловыми системами формата NTFS |
SmmReset | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0C | EFI-приложение | Приложение, создающее индикатор заражения прошивки — UEFI-переменную «fTA» |
SmmAccessSub | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B | EFI-приложение | Приложение, сохраняющее файл IntelUpdate.exe (вредоносная нагрузка) в директорию %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup |
Для создания тестового стенда произведем заражение прошивки виртуальной машины QEMU, в которой для эмуляции прошивки используется Open Virtual Machine Firmware, представленный файлом OVMF_CODE.fd.
Таким образом, чтобы модифицировать прошивку виртуальной машины, необходимо внести изменения в файл OVMF_CODE.fd. Для этого используем кроссплатформенную утилиту с открытым исходным кодом UEFITool. Она позволяет проводить анализ прошивки, извлекать из неё модули и многое другое.
Для заражения прошивки надо добавить в неё два DXE-драйвера и два UEFI-приложения. Сначала находим раздел, в котором содержатся все используемые DXE-драйверы (в данном случае раздел с GUID 8C8CE578-8A3D-4F1C-9935-896185C32DD3 в формате FFSv2):
Перед записью каждый из имеющихся EFI-файлов надо представить в виде файла FFS (Firmware File System). Каждый файл в формате FFS состоит из секций (для создания стенда — из двух). Первая будет содержать исполняемый код, вторая — имя модуля в понятном для человека виде. Все драйверы будут собраны в файлы типа EFI_FV_FILETYPE_DRIVER, все приложения — в файлы типа EFI_FV_FILETYPE_APPLICATION. Для сборки используем утилиты GenSec и GenFfs из EDK II (доступны в репозитории EDK II).
Генерация секции с кодом:
GenSec.exe -o pe32.sec .\Ntfs.efi -S EFI_SECTION_PE32
Генерация секции с именем:
GenSec.exe -o name.sec -S EFI_SECTION_USER_INTERFACE -n "NTFS"
Создание из секций файла в формате FFS:
GenFfs -g "F50258A9-2F4D-4DE9-86AE-BDA84D07A41C" -o ntfs_driver.ffs -i pe32.sec -i name.sec -t EFI_FV_FILETYPE_DRIVER
При создании секции с именем необходимо изменять имя файла, передаваемое после аргумента -n, а при создании секции с кодом — путь до EFI-файла (в примере — .\Ntfs.efi).
При создании FFS-файлов надо менять GUID (аргумент -g), тип создаваемого файла (аргумент -t для драйверов должен принимать значение EFI_FV_FILETYPE_DRIVER, а для приложений — EFI_FV_FILETYPE_APPLICATION) и имя выходного файла (аргумент -o).
В результате мы получим четыре файла в формате FFS, которые можно добавить в прошивку с использованием UEFITool. При добавлении нужно убедиться, что в разделе хватает свободного места. В результате модифицированная прошивка выглядит приблизительно так:
После замены файла прошивки и запуска виртуальной машины происходит создание файлов Mosaic Regressor’ом, что указывает на успешную модификацию прошивки. Это файлы %WINDIR%\setupinf.log и %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe. Первый является индикатором компрометации компьютера (файл IntelUpdate.exe будет создан, только если файла setupinf.log не существует), второй скачивает полезную нагрузку с сервера:
Несмотря на то, что в данном случае производилось заражение виртуальной машины, схожим способом возможно заражать компьютеры с некорректной конфигурацией и за счет этого добиваться гарантированного запуска вредоносных программ на компьютере.
Охота на Mosaic Regressor
Выявить Mosaic Regressor можно несколькими способами:
поиск индикаторов в прошивке или сравнение с эталонным образом UEFI;
поиск индикаторов на уровне ОС;
анализ сетевой активности.
Разберем каждый способ подробнее.
Поиск индикаторов в прошивке
После анализа EFI-файла SmmReset мы получили индикатор компрометации прошивки. Этот исполняемый файл создаёт NVRAM-переменную с именем "fTA". Переменная с таким же именем и функциональной нагрузкой использовалась в rkloader, разработанном HackingTeam, поэтому поиск по этому индикатору позволит найти и Mosaic Regressor, и rkloader, и другие буткиты, основанные на rkloader.
Для поиска этого и других индикаторов компрометации можно использовать многофункциональную утилиту Chipsec, распространяемую и поддерживаемую компанией Intel. Она умеет проверять прошивки на защищённость, получать дампы прошивок и многое другое. Утилиту Chipsec можно использовать из ОС или загрузившись в UEFI Shell, в данном случае был выбран второй вариант. Для создания загрузочного флеш-накопителя, с которого будет запускаться Chipsec, надо выполнить следующие действия:
Отформатировать флеш-накопитель в файловую систему FAT-32;
Сохранить на него UEFI Shell, который будет получать управление после загрузки компьютера. Для этого необходимо скачать файл UEFI Shell и сохранить его в директорию /efi/boot под именем "Bootx64.efi".
Скачать репозиторий Chipsec.
Извлечь содержимое архива _instal_/UEFI/chipsec_uefi_x64.zip в корневую директорию флеш-накопителя.
Оставшееся содержимое репозитория скопировать в корневую директорию флеш-накопителя.
После загрузки в UEFI Shell выполняем команду mount, которая покажет список доступных устройств. В данном случае флеш-карта обозначена как FS0 (это можно понять по надписи "USB" в описании устройства):
После перехода в директорию Chipsec, с помощью команды python chipsec_util.py uefi var-find fTA можно проверить, есть ли переменная с таким именем в прошивке. Если эта переменная существует — её дамп будет сохранён в файл:
Если нужен более глубокий анализ прошивки, Chipsec позволяет получить её дамп. Для этого нужно выполнить команду python chipsec_util.py spi dump rom.bin:
Полученный дамп можно открыть в уже упомянутом UEFITool и, например, извлечь модули, которые кажутся подозрительными:
Если есть эталонный образ прошивки, Chipsec позволяет использовать его для поиска модификаций в прошивке. Для этого сначала нужно сгенерировать список модулей эталонного образа с помощью команды python chipsec_main.py -i -m tools.uefi.scan_image -a generate,list_of_variables.json,firmware.bin, где list_of_variables.json — файл, в который будет записан результат выполнения команды, а firmware.bin — дамп эталонной прошивки.
После получения данных об эталоне можно проводить сравнение с помощью команды python chipsec_main.py -i -m tools.uefi.scan_image -a check,list_of_variables.json,suspected_firmware.bin, гдеsuspected_firmware.bin — имя файла дампа проверяемой прошивки.
Как мы уже сказали, утилиту Chipsec можно использовать из ОС. Для этого нужно установить драйвер Chipsec, после чего можно запускать .py-файлы с помощью интерпретатора Python. Таким образом можно автоматизировать сбор образов прошивок для их дальнейшего анализа.
Поиск индикаторов на уровне ОС
В этом разделе уделим немного внимания тому, как детектировать заражение прошивки Mosaic Regressor’ом на уровне операционной системы. После загрузки операционной системы полезная нагрузка Mosaic Regressor'а — файл IntelUpdate.exe — ведёт себя как самая обычная вредоносная программа. Для её детектирования можно использовать данные, полученные при анализе EFI-файлов — хеш файла, сохраняемого в %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup, его имя и прочие индикаторы. Однако стоит отметить, что поиск события создания файла не увенчается успехом, поскольку файл создается до загрузки ОС, а значит, событие не будет обнаружено с помощью EDR или аналогичных решений (одним из вариантов детектирования создания файлов видится сохранение информации о состоянии файловой системы перед выключением или гибернацией компьютера и сравнение сохраненного состояния с состоянием после загрузки ОС).
Аналогичная ситуация наблюдается с файлом %WINDIR%\setupinf.log, который используется Mosaic Regressor’ом как дополнительный индикатор заражения — наряду с переменной UEFI. Файл IntelUpdate.exe будет сохранен, только если файла setupinf.log не существует.
С помощью следующего запроса в Huntbox можно обнаружить следы запуска полезной нагрузки, которую сохранил EFI-модуль Mosaic Regressor'а:
event_type: "Process creation" AND Payload.CommandLine: "Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe"
Файл IntelUpdate.exe создается с немодифицированными временными атрибутами, поэтому если вы видите запуск файла из автозагрузки без событий созданий этого файла, то это хороший повод для проведения дальнейшего исследования.
Все создаваемые файлы в автозагрузке следует проверять в песочницах или системах детонации вредоносных файлов. В нашем случае Huntpoint отправит файлы на анализ в Polygon, где он будет обнаружен как вредоносный, и, как следствие, запуск этого файла будет блокироваться на всех хостах.
Использование комбинации систем класса EDR и Malware Detonation — достаточно универсальное решение, но не всегда есть возможность устанавливать агенты на всех рабочих местах. В этом случае поможет анализ сетевого трафика на наличие соединений с уже известными вредоносными хостами.
А таким образом можно проверить наличие сетевых соединений с сервером, отдающим полезную нагрузку:
event_type: "Network connection opening" AND Payload.RemoteAddress: "103.56.115.69"
dns_query: "myfirewall.org"
Для более эффективного обнаружения таких угроз в трафике необходимы качественные индикаторы. Для этих целей в Group-IB мы создали систему External Threat Hunting, которая позволяет выявлять аналогичную инфраструктуру атакующих за счет анализа уже известных вредоносных хостов. Все новые найденные хосты автоматически конвертируются в правила для обнаружения этой угрозы в сетевом трафике. Более расширенный список сетевых индикаторов мы приводим в конце, в разделе «Индикаторы».
Потенциальные векторы заражения
Существует 3 варианта заражения UEFI:
Удалённое заражение.
Заражение при наличии физического доступа.
Заражение через цепочку поставок.
Для удалённого заражения атакующему надо получить повышенные привилегии, позволяющие установить полезную нагрузку, которая будет работать на уровне ядра ОС. После этого он должен проэксплуатировать уязвимость SMM (например, такую). Это позволит исполнять код в режиме SMM, обходить различные механизмы защиты прошивки (Flash Write Protection) и получить прямой доступ к памяти прошивки.
В случае заражения при наличии физического доступа злоумышленник может проэксплуатировать ошибки в конфигурации UEFI (например, такие) или механизме обновления прошивки.
В случае заражения цепочки поставок преступник может добавить собственный имплант в прошивку или её обновление, что позволит обойти существующие методы защиты. Для подобной атаки необходимо скомпрометировать производителя и, например, получить доступ к исходным кодам прошивки.
Утилиту Chipsec также можно использовать для базовой проверки UEFI на предмет неправильной конфигурации или наличия уязвимостей. Для этого достаточно запустить основной модуль командой python chipsec_main.py, которая запустит различные проверки безопасности, например, проверку на защиту от перезаписи.
Следует отметить, что успешное прохождение данного теста не значит, что ваша система не заражена, поскольку Chipsec предоставляет лишь базовый набор проверок безопасности. Однако провал теста свидетельствует о том, что нужно как минимум поставить последние обновления UEFI или разобраться, почему базовые механизмы безопасности прошивки нарушены.
Заключение
Угрозы UEFI являются одними из самых серьезных, и индустрия безопасности только начинает адаптировать свои решения для качественного обнаружения этих угроз.
Точно не стоит ждать серебряной пули или уповать на встроенные механизмы доверенной загрузки операционной системы. Чтобы защитить свою инфраструктуру и эффективно охотиться за такими угрозами, необходимо использовать данные киберразведки. Кроме коммерческих продуктов, реализующих компенсационные меры, можно использовать и бесплатные аналоги, например, Chipsec, которая расширяет возможности охоты по индикаторам и позволяет проверять правильность конфигурации UEFI.
Индикаторы
Модули UEFI
Имя модуля | GUID | MD5 РЕ-файла из EFI_SECTION_PE32-секции |
SmmInterfaceBase | F50258A9-2F4D-4DA9-861E-BDA84D07A44C | F5B320F7E87CC6F9D02E28350BB87DE6 |
Ntfs | F50258A9-2F4D-4DE9-86AE-BDA84D07A41C | DD8D3718197A10097CD72A94ED223238 |
SmmReset | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0C | 91A473D3711C28C3C563284DFAFE926B |
SmmAccessSub | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B | 0C136186858FD36080A7066657DE81F5 |
Хеши
9F13636D5861066835ED5A79819AAC28
FA0A874926453E452E3B6CED045D2206
72C514C0B96E3A31F6F1A85D8F28403C
0D386EBBA1CCF1758A19FB0B25451AFE
B53880397D331C6FE3493A9EF81CD76E
7B213A6CE7AB30A62E84D81D455B4DEA
A69205984849744C39CFB421D8E97B1F
08ECD8068617C86D7E3A3E810B106DCE
89527F932188BD73572E2974F4344D46
9E182D30B070BB14A8922CFF4837B94D
61B4E0B1F14D93D7B176981964388291
7908B9935479081A6E0F681CCEF2FDD9
3D2835C35BA789BD86620F98CBFBF08B
1732357D3A0081A87D56EE1AE8B4D205
233B300A58D5236C355AFD373DABC48B
36B51D2C0D8F48A7DC834F4B9E477238
DC14EE862DDA3BCC0D2445FDCB3EE5AE
0EFB785C75C3030C438698C77F6E960E
1C5377A54CBAA1B86279F63EE226B1DF
328AD6468F6EDB80B3ABF97AC39A0721
AE66ED2276336668E793B167B6950040
E2F4914E38BB632E975CFF14C39D8DCD
C63D3C25ABD49EE131004E6401AF856C
12B5FED367DB92475B071B6D622E44CD
B23E1FE87AE049F46180091D643C0201
7C3C4C4E7273C10DBBAB628F6B2336D8
3B58E122D9E17121416B146DAAB4DB9D
70DEF87D180616406E010051ED773749
88750B4A3C5E80FD82CF0DD534903FC0
D273CD2B96E78DEF437D9C1E37155E00
3B3BC0A2772641D2FC2E7CBC6DDA33EC
AFC09DEB7B205EADAE4268F954444984
6E949601EBDD5D50707C0AF7D3F3C7A5
92F6C00DA977110200B5A3359F5E1462
D197648A3FB0D8FF6318DB922552E49E
74DB88B890054259D2F16FF22C79144D
449BE89F939F5F909734C0E74A0B9751
67CF741E627986E97293A8F38DE492A7
CFB072D1B50425FF162F02846ED263F9
Пути до файлов
%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup \IntelUpdate.exe
%TEMP%\RepairC.dll
%APPDATA%\Microsoft\Windows\SendTo\load.dll
%APPDATA%\Microsoft\Windows\load.rem
%APPDATA%\Microsoft\Internet Explorer\FileD.dll
%TEMP%\wrtreg_32.dll
%APPDATA%\Microsoft\Internet Explorer\FileOutA.dat
%APPDATA%\Microsoft\Internet Explorer\%Computername%.dat
%COMMON_APPDATA%\Microsoft\Windows\user.rem
%TEMP%\RepairB.dll
%APPDATA%\sdfcvb.dll
%TEMP%\RepairA.dll
%APPDATA%\Microsoft\subst.tbl
%appdata%\return.exe
%APPDATA%\Microsoft\Windows\SendTo\cryptui.sep
%appdata%\dwhost.exe
%appdata%\msreg.exe
%APPDATA%\newplgs.dll
%APPDATA%\Microsoft\Windows\LnkClass.dat
%APPDATA%\Microsoft\Internet Explorer\FileB.dll
%APPDATA%\rfvtgb.dll
%APPDATA%\Microsoft\Network\DFileC.dll
%APPDATA%\Microsoft\Internet Explorer\FileA.dll
%APPDATA%\Microsoft\exitUI.rs
%APPDATA%\Microsoft\Network\subst.sep
%APPDATA%\Microsoft\Network\DFileD.dll
%TEMP%\BeFileA.dll
%APPDATA%\Microsoft\Network\DFileA.dll
%APPDATA%\Microsoft\sppsvc.tbl
%APPDATA%\msreg.dll
%TEMP%\wrtreg_64.dll
%APPDATA%\Microsoft\Internet Explorer\FileC.dll
%APPDATA%\Microsoft\WebC.dll
%appdata%\winword.exe
%APPDATA%\Microsoft\Windows\mapisp.dll
%APPDATA%\Microsoft\WebB.dll
%APPDATA%\Microsoft\WebA.dll
%APPDATA%\Microsoft\Credentials\MSI36C2.dat
%TEMP%\BeFileC.dll
%TEMP%\RepairD.dll
Мьютексы
set instance state
single UI
Office Module
foregrounduu state
process attach Module
Сетевые индикаторы
Известные индикаторы | Дополнительные индикаторы от Group-IB External Threat Hunting |
menjitghyukl.myfirewall[.]org 103[.]39[.]109[.]252 117[.]18[.]4[.]6 103[.]229[.]1[.]26 43[.]252[.]228[.]252 103[.]82[.]52[.]18 103[.]195[.]150[.]106 43[.]252[.]230[.]180 43[.]252[.]228[.]179 144[.]48[.]241[.]32 43[.]252[.]228[.]84 150[.]129[.]81[.]21 43[.]252[.]228[.]75 103[.]30[.]40[.]116 103[.]39[.]109[.]239 103[.]243[.]26[.]211 103[.]56[.]115[.]69 103[.]39[.]110[.]193 103[.]243[.]24[.]171 103[.]30[.]40[.]39 144[.]48[.]241[.]167 | 103[.]215[.]80[.]1 103[.]229[.]126[.]101 103[.]229[.]126[.]246 103[.]39[.]109[.]231 103[.]56[.]113[.]61 103[.]96[.]72[.]148 103[.]96[.]74[.]144 122[.]10[.]82[.]30 144[.]48[.]240[.]101 144[.]48[.]240[.]145 185[.]216[.]117[.]91 212[.]64[.]6[.]161 216[.]241[.]155[.]120 43[.]224[.]248[.]143 43[.]251[.]17[.]187 43[.]252[.]229[.]32 43[.]252[.]229[.]33 43[.]252[.]230[.]146 43[.]252[.]231[.]135 45[.]116[.]78[.]238 45[.]116[.]79[.]186 45[.]64[.]75[.]178 52[.]174[.]139[.]136 69[.]6[.]23[.]85 |
MITRE ATT&CK и MITRE Shield
Тактика | Техника | Описание | Методы защиты и противодействия | Продукты Group-IB, позволяющие защититься от подобных угроз |
Persistence/Defence Evasion | T1542.001 - Pre-OS Boot: System Firmware | Модули SmmInterfaceBase, Ntfs, SmmReset и SmmAccessSub являются частью UEFI и выполняются перед загрузкой ОС | M1046 - Boot Integrity M1026 - Privileged Account Management M1051 - Update Software | |
Persistence | T1547.001 - Registry Run Keys / Startup Folder | Файл IntelUpdate.exe сохраняется в директорию %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup EFI-приложением SmmAccessSub | Threat Hunting Framework | |
Execution | T1559.001 - Inter-Process Communication: Component Object Model
| Файл IntelUpdate.exe использует COM-библиотеки | M1048 - Application Isolation and Sandboxing M1026 - Privileged Account Management | Threat Hunting Framework |
Defense Evasion | T1197 - BITS Jobs | Mosaic Regressor использует BITS для получения и передачи данных | M1037 - Filter Network Traffic M1028 - Operating System Configuration M1018 - User Account Management | Threat Hunting Framework |
Defense Evasion | T1027 - Obfuscated Files or Information | Часть строк в файле IntelUpdate.exe зашифрованы | M1049 - Antivirus/Antimalware | Threat Hunting Framework |
Command and Control | T1105 - Ingress Tool Transfer | Файл IntelUpdate.exe скачивает DLL-файлы и вызывает в них функции CallA, CallB, CallC, CallD и CallE | M1031 - Network Intrusion Prevention | Threat Hunting Framework |
msuhanov
Вы это серьезно? Запущенный файл может удалить себя.
EditorGIB Автор
В данном случае подразумевалось детектирование создания файлов из UEFI-имплантов, а не всех файлов.
Предлагаемая концепция достаточно проста — создаётся некий модуль ядра, который занимается мониторингом определённых директорий (в данном случае — директории Startup).
Перед завершением работы ОС он получает управление и сохраняет либо контрольную сумму, либо список файлов, данная концепция обсуждаема. Этот же модуль получает управление после загрузки ОС, но до того, как запустятся программы из директории Startup.
Таким образом получаем возможность получить информацию о наличии файла, созданного до загрузки ОС до того, как он будет удалён.
msuhanov
Я прекрасно понимаю, о чем шла речь. И потому не понимаю, как можно заявлять то, что было процитировано в моем комментарии выше. Ну и этот Ваш комментарий еще.
Мониторинг определенных директорий? Хорошо, будет автозапуск через реестр.
Будет работать какой-то драйвер? Хорошо, будет более ранний запуск вредоносного драйвера. Тогда и мониторинг директорий можно будет обойти.
Хотите перехватить запуск вредоносного драйвера? Если использовать стандартные интерфейсы, то это к ELAM. Но читать данные с тома нельзя, в итоге детектирование все равно будет по урезанным сигнатурам.
Как же сравнить эталонный список с тем, что есть в томе сейчас? А никак.
EditorGIB Автор
Вы сейчас просто пытаетесь доказать, что на любые защитные решения злоумышленники рано или поздно найдут свои собственные атакующие решения? Никто с этим не спорит. Только вот VectorEDK слили в 2015, а злоумышленники не удосужились даже поменять имя переменной, являющейся индикатором компрометации. Это так, для демонстрации того, что злоумышленники часто ленивы и поэтому даже самые простые решения для защиты вполне себе могут работать.
На всякий случай ещё раз мысль, а то вы куда-то в сторону уводите — описанный способ (гипотетический, просто размышления на тему, смысл статьи не в том, чтобы рассказать всем как строить ИДЕАЛЬНЫЕ защитные решения для подобных угроз) защиты от конкретного, самого простого способа запуска через размещение вредоносного файла в директории автозапуска. Нужно ли думать о том, что делать с подобными угрозами и усложнением используемых злоумышленниками техник? Да, нужно. Статья про то, как построить решение, которое защитит раз и навсегда от ВСЕХ возможных способов заражения через UEFI и должна включать все возможные действия, которыми злоумышленники могут запустить полезную нагрузку через UEFI-имплант? Нет, не про это, нет, не должна
msuhanov
Разумеется, это хорошая причина писать плохие сигнатуры (нет). Или, быть может, кто-то название переменной поменял, но сигнатуры как раз из-за этого у кого-то не сработали?
EditorGIB Автор
Про какие сигнатуры вы говорите? Я на всякий случай повторю, что цель статьи не в написании сигнатур. Это во-первых.
Во-вторых, чем плох тот подход, который вы почему-то назвали сигнатурой? Он что не в состоянии ловить часть атак, которые используют именно такой метод (сохранение файла в директорию автозагрузки)? В состоянии. Таких атак нет? Есть. Он плох тем, что он не ловит ВСЕ возможные методы атак? Да, а что «серебряную пулю» изобрели уже?
Я ещё раз обращаю внимание, что написание сигнатур и советы по разработке защитных решений — это не есть цель написания статьи. А вы, как будто, упрекаете, что в статье не раскрыты все возможные вектора атаки. За «серебряной пулей» точно не сюда, извините. А то ваша логика выглядит, как будто если ты не можешь написать ИДЕАЛЬНУЮ сигнатуру, не надо писать никакую…
msuhanov
Простите, но конкретно по имени переменной (этой самой) уже достаточно прошлись в соответствующих дискуссиях.
Конечно, на каком-то начальном этапе вполне разумно писать сигнатуры по строкам, которые атакующему легко изменить. Но потом гораздо разумнее сделать что-то более универсальное. Есть много мануалов про написание хороших YARA-правил и Snort/Suricata-сигнатур, где этот принцип так или иначе описан.
А здесь идет 2021 год, а детектирование как будто по состоянию на 2015 год. Тем более, что под него подгоняется какое-то новое техническое решение.