Как стать автором
Обновить

Мастера перевоплощений: охотимся на буткиты

Время на прочтение14 мин
Количество просмотров6.8K
Всего голосов 13: ↑13 и ↓0+13
Комментарии9

Комментарии 9

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


Вы это серьезно? Запущенный файл может удалить себя.
В данном случае подразумевалось детектирование создания файлов из UEFI-имплантов, а не всех файлов.

Предлагаемая концепция достаточно проста — создаётся некий модуль ядра, который занимается мониторингом определённых директорий (в данном случае — директории Startup).

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

Таким образом получаем возможность получить информацию о наличии файла, созданного до загрузки ОС до того, как он будет удалён.
В данном случае подразумевалось детектирование создания файлов из UEFI-имплантов, а не всех файлов.


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

Предлагаемая концепция достаточно проста — создаётся некий модуль ядра, который занимается мониторингом определённых директорий (в данном случае — директории Startup).


Мониторинг определенных директорий? Хорошо, будет автозапуск через реестр.
Будет работать какой-то драйвер? Хорошо, будет более ранний запуск вредоносного драйвера. Тогда и мониторинг директорий можно будет обойти.

Хотите перехватить запуск вредоносного драйвера? Если использовать стандартные интерфейсы, то это к ELAM. Но читать данные с тома нельзя, в итоге детектирование все равно будет по урезанным сигнатурам.

Как же сравнить эталонный список с тем, что есть в томе сейчас? А никак.
Вы сейчас просто пытаетесь доказать, что на любые защитные решения злоумышленники рано или поздно найдут свои собственные атакующие решения? Никто с этим не спорит. Только вот VectorEDK слили в 2015, а злоумышленники не удосужились даже поменять имя переменной, являющейся индикатором компрометации. Это так, для демонстрации того, что злоумышленники часто ленивы и поэтому даже самые простые решения для защиты вполне себе могут работать.

На всякий случай ещё раз мысль, а то вы куда-то в сторону уводите — описанный способ (гипотетический, просто размышления на тему, смысл статьи не в том, чтобы рассказать всем как строить ИДЕАЛЬНЫЕ защитные решения для подобных угроз) защиты от конкретного, самого простого способа запуска через размещение вредоносного файла в директории автозапуска. Нужно ли думать о том, что делать с подобными угрозами и усложнением используемых злоумышленниками техник? Да, нужно. Статья про то, как построить решение, которое защитит раз и навсегда от ВСЕХ возможных способов заражения через UEFI и должна включать все возможные действия, которыми злоумышленники могут запустить полезную нагрузку через UEFI-имплант? Нет, не про это, нет, не должна
Разумеется, это хорошая причина писать плохие сигнатуры (нет). Или, быть может, кто-то название переменной поменял, но сигнатуры как раз из-за этого у кого-то не сработали?
Про какие сигнатуры вы говорите? Я на всякий случай повторю, что цель статьи не в написании сигнатур. Это во-первых.

Во-вторых, чем плох тот подход, который вы почему-то назвали сигнатурой? Он что не в состоянии ловить часть атак, которые используют именно такой метод (сохранение файла в директорию автозагрузки)? В состоянии. Таких атак нет? Есть. Он плох тем, что он не ловит ВСЕ возможные методы атак? Да, а что «серебряную пулю» изобрели уже?

Я ещё раз обращаю внимание, что написание сигнатур и советы по разработке защитных решений — это не есть цель написания статьи. А вы, как будто, упрекаете, что в статье не раскрыты все возможные вектора атаки. За «серебряной пулей» точно не сюда, извините. А то ваша логика выглядит, как будто если ты не можешь написать ИДЕАЛЬНУЮ сигнатуру, не надо писать никакую…
А то ваша логика выглядит, как будто если ты не можешь написать ИДЕАЛЬНУЮ сигнатуру, не надо писать никакую…


Простите, но конкретно по имени переменной (этой самой) уже достаточно прошлись в соответствующих дискуссиях.

Конечно, на каком-то начальном этапе вполне разумно писать сигнатуры по строкам, которые атакующему легко изменить. Но потом гораздо разумнее сделать что-то более универсальное. Есть много мануалов про написание хороших YARA-правил и Snort/Suricata-сигнатур, где этот принцип так или иначе описан.

А здесь идет 2021 год, а детектирование как будто по состоянию на 2015 год. Тем более, что под него подгоняется какое-то новое техническое решение.
Отлично, очень интересный материал.
Современная поверхность атаки такая огромная, софт, железо, софт в железе, что никакой админ не удержит всё в голове. Производитель ОС — гигант, но тоже не успевает. Экзистенциальный страх тем больше одолевает, чем больше узнаёшь.
современная поверхность атаки такая же как и была, и собственно большая часть скорее даже не из-за ошибок, а из-за осознанных бекдоров, которые теперь выдают за найденные «уязвимости»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий