Речь идет в любом случае про согласованное состояние, когда файлы для копии берутся на определенный момент времени.
Нет же. Содержимое файлов читается "на лету", без их заморозки.
В WIndows уже давно, начиная с Server 2003 (и XP начиная с какого-то Service Pack) для этого есть поддержка снимков (“теневых копий”), доступная через команды vssadmin и diskshadow: делаете теневую копию и забираете файлы с нее.
Создание теневой копии — это слишком "шумно" (flush для приложений, затем flush для драйвера NTFS), да и можно потерять самую старую (и самую нужную, по закону подлости) теневую копию. Плюс, в теневых копиях не в серверных вариантах операционной системы может быть мусор вместо нужного содержимого файлов (в copy-on-write не включены по умолчанию пользовательские файлы начиная с Windows 8, это теперь фича для отката изменений системных файлов, а не для восстановления всяких документов).
ESE поддерживает транзакции, так что БД, полученные в состоянии Dirty Shutdown можно восстановить утилитой работы с БД (eseutil / esentutl) в согласованнное состояние, применив к ним нужные файлы журнала транзакций
Все зависит от причин, по которым возникло "грязное" состояние. При копировании файлов путем прямого доступа к физическому диску — есть редкий шанс попасть в ситуацию, когда логи транзакций не спасут (они рассчитаны на сбой при записи, а не на медленное копирование одного файла, когда захватываются два его состояния: одно в начале копирования, другое в конце копирования).
Впрочем, любителей читать данные напрямую с диска C: (а не с PHYSICALDRIVE<X>) это не затрагивает — в современных версиях Windows попытка парсинга NTFS с логического диска приводит к тому, что драйвер переводит том в состояние, эквивалентное созданию теневой копии, когда некоторое время данные на диске "стабильны" (разумеется, при этом часть метаданных NTFS теряется).
Babuk ransomware (я всю историю называл его бабадуком по ассоциации с дебильным фильмом ужасов). Шифрует все стойким алгоритмом ChaCha20. Через сервис https://id-ransomware.malwarehunterteam.com после загрузки зашифрованного файла и письма диагноз MB подтверждается. В открытом доступе ключей не обнаружено, расшифровка невозможна. Но так как атака была проведена, скорее всего, без участия живой силы, то теплится надежда вытащить хоть какие-то данные.
Babuk шифрует только начало виртуального диска. В ряде случаев диск C: виртуальной машины либо начинается в незашифрованной области (т. е. данные, считай, не тронуты), либо зашифровано лишь начало файловой системы (а это, главным образом, заголовок, бекап которого есть в конце раздела, и индексы директорий, которые из $MFT можно восстановить).
Ряд пострадавших вообще "спасают" кучу данных через chkdsk (разумеется, запускать в отношении копии виртуального диска, а не оригинала).
Хуже, если внутри виртуальной машины поработал другой шифровальщик.
Только в том случае, если вы сами "проставили нужные галочки" (читай: разрешили сохранение ключа восстановления в облако). В условиях организации (если компьютер в домене) — ключи восстановления пойдут в Active Directory. При настройке руками — в текстовый файл или на печать.
ещё он может слетать при обновления требуя recovery key
Он "слетает" из-за того, что "загрузочные условия" изменились, при профиле валидации на базе Secure Boot должен "слетать" реже, значительно реже. Не нравится — отключайте TPM и включайте PIN или USB-ключ, но тогда ваш уровень защиты будет ниже.
Вы сравниваете BitLocker в режиме "TPM only" и токен с PIN. Если же будет BitLocker в режиме "TPM + PIN", то это гораздо лучше этих ваших токенов: хотя бы из-за того, что после ввода PIN TPM не отдаст расшифрованный VMK, если загрузочные компоненты имеют некорректную подпись, а токен просто возьмет и отдаст расшифрованный ключ.
Да, тут вы можете вспомнить про модули доверенной загрузки, но они не работают, увы.
Как сообщил разработчик в приватном тикете по двум другим (намного более старым) уязвимостям (CVE-2023-52168, CVE-2023-52169), через три месяца после релиза исправлений:
Probably the problem is unknown still. If we open it now, it will increase the risks for possible attacks as I suppose. I suppose it's not so simple to find problem via source code analys, if you don't know what thing to search. Such good description will show the place to search for attack ways.
There are third-party programs for Windows/Linux that use old 7-zip code. Some programs will update their code for new 7-zip soon. But probably it can get big amount of time for some programs to update source code from latest 7-zip.
I think it's more safer not to open it now. There are many projects (that use 7-zip) that have different speed of moving to new code. But main projects will move to new code at some time without any advisories.
What are your purposes related this bug? Why do you want to open right now?
В Windows создание симлинка - привилегированная операция (непонятно, почему)
Не совсем:
Now in Windows 10 Creators Update, a user (with admin rights) can first enable Developer Mode, and then any user on the machine can run the mklink command without elevating a command-line console.
Уязвимость заключается в том, что при распаковке файлов из скачанного архива на них не проставляется метка Mark-of-the-Web. Поэтому запуск распакованного зловреда не будет блокироваться механизмами безопасности Windows. Если помните, в январе была похожая уязвимость CVE-2025-0411. Там проблема была с запуском файлов из интерфейса архиватора, её пофиксили. А в данном случае проблема с полностью распакованными архивами. И эту проблему ИСПРАВЛЯТЬ НЕ БУДУТ! 🤷♂️
Сколько раз эту "уязвимость" (RCE, не иначе) будут переоткрывать в контексте 7-Zip?
Подсказка: Zone.Identifier — необходимый, но не единственный признак того, что файл был загружен из Интернета. Отсутствие вызовов GetStorageDependencyInformation() и GetZoneFromAlternateDataStreamEx() равно уязвимость, в вашей системе координат. И опять почти все архиваторы "уязвимы", как так! А ведь именно проверка и через GetStorageDependencyInformation() реализована для MotW в Windows (кто не понял: так проверяется MotW в смонтированном контейнере VHD/VHDX, признак наследуется от файла-контейнера, даже если внутри у файла нет ADS)!
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Атака "подобная" потому что, описана вами, в этом заключается все подобие?
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Извините, но я с вами не согласен.
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
В каталогах должны также лежать файлы %Реестр%.LOG1 и %Реестр%.LOG2, для корректного парсинга сырых данных.
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Запуск RECmd для необходимых файлов реестра, который выгружает только необходимые ветки
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
"file.name": "(default)",
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Посоветовавшись, мы решили, почему нет, скорее всего, SANS явно вне всех этих политических игр.
Еще в 21 году начались проблемы.
Знающие люди поймут, что знать наизусть изменения всех временных меток в NTFS при различных манипуляциях в разных версиях винды – это задачка не из легких. Когда я решала свой тест, я без задней мысли эти вопросы просто смотрела в Windows Forensic Poster.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Куда хуже, если применяются программы типа BitLocker и выполняется полнодисковое шифрование. Сбор криминалистических артефактов затрудняется. Вся надежда на то, что киберпреступник наследил по оплошности. [...] Или же где-то остались незашифрованные диски. Если же такая атака затронула абсолютно все хосты организации, шансы достать артефакты ничтожно малы.
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Некоторые клиенты просят лишь восстановить зашифрованные файлы, чтобы не платить выкуп. [...] К тому же большинство современных программ-вымогателей работают так, что шифрование необратимо и без приватного ключа с ним не справится даже гений криптографии. Стараемся объяснить это клиенту, а дальше все зависит от его понимания ситуации и приоритетов.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
После этого с https://app-ins-001.amscloudhost[.]com:443/dn01 осуществляется загрузка RedCurl.FSABIN, который сохраняется в папку C:\Users[user]\AppData\Local\VirtualStore</code>с именем [...]
Отслеживайте запуск подозрительных файлов из папки C:\Users[user]\AppData\Local через планировщик заданий Windows.
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?
Нет, не проводил. Но совершенно точно такого поведения раньше (во времена XP/Vista/7) не было.
Нет же. Содержимое файлов читается "на лету", без их заморозки.
Создание теневой копии — это слишком "шумно" (flush для приложений, затем flush для драйвера NTFS), да и можно потерять самую старую (и самую нужную, по закону подлости) теневую копию. Плюс, в теневых копиях не в серверных вариантах операционной системы может быть мусор вместо нужного содержимого файлов (в copy-on-write не включены по умолчанию пользовательские файлы начиная с Windows 8, это теперь фича для отката изменений системных файлов, а не для восстановления всяких документов).
Все зависит от причин, по которым возникло "грязное" состояние. При копировании файлов путем прямого доступа к физическому диску — есть редкий шанс попасть в ситуацию, когда логи транзакций не спасут (они рассчитаны на сбой при записи, а не на медленное копирование одного файла, когда захватываются два его состояния: одно в начале копирования, другое в конце копирования).
Впрочем, любителей читать данные напрямую с диска C: (а не с PHYSICALDRIVE<X>) это не затрагивает — в современных версиях Windows попытка парсинга NTFS с логического диска приводит к тому, что драйвер переводит том в состояние, эквивалентное созданию теневой копии, когда некоторое время данные на диске "стабильны" (разумеется, при этом часть метаданных NTFS теряется).
Babuk шифрует только начало виртуального диска. В ряде случаев диск C: виртуальной машины либо начинается в незашифрованной области (т. е. данные, считай, не тронуты), либо зашифровано лишь начало файловой системы (а это, главным образом, заголовок, бекап которого есть в конце раздела, и индексы директорий, которые из $MFT можно восстановить).
Ряд пострадавших вообще "спасают" кучу данных через chkdsk (разумеется, запускать в отношении копии виртуального диска, а не оригинала).
Хуже, если внутри виртуальной машины поработал другой шифровальщик.
Только в том случае, если вы сами "проставили нужные галочки" (читай: разрешили сохранение ключа восстановления в облако). В условиях организации (если компьютер в домене) — ключи восстановления пойдут в Active Directory. При настройке руками — в текстовый файл или на печать.
Он "слетает" из-за того, что "загрузочные условия" изменились, при профиле валидации на базе Secure Boot должен "слетать" реже, значительно реже. Не нравится — отключайте TPM и включайте PIN или USB-ключ, но тогда ваш уровень защиты будет ниже.
Из них несколько находил я (CVE-2025-21214, CVE-2025-21210, CVE-2024-43513, CVE-2025-21202). Но я могу смело сказать, что BitLocker уже давно впереди всех аналогов.
Вы сравниваете BitLocker в режиме "TPM only" и токен с PIN. Если же будет BitLocker в режиме "TPM + PIN", то это гораздо лучше этих ваших токенов: хотя бы из-за того, что после ввода PIN TPM не отдаст расшифрованный VMK, если загрузочные компоненты имеют некорректную подпись, а токен просто возьмет и отдаст расшифрованный ключ.
Да, тут вы можете вспомнить про модули доверенной загрузки, но они не работают, увы.
Если AES — это защитное преобразование, то и вместо "хеш" давайте пишите "контрольная сумма".
Как сообщил разработчик в приватном тикете по двум другим (намного более старым) уязвимостям (CVE-2023-52168, CVE-2023-52169), через три месяца после релиза исправлений:
Делайте выводы.
Не совсем:
Есть: FILE_FLAG_OPEN_REPARSE_POINT.
Сколько раз эту "уязвимость" (RCE, не иначе) будут переоткрывать в контексте 7-Zip?
Подсказка: Zone.Identifier — необходимый, но не единственный признак того, что файл был загружен из Интернета. Отсутствие вызовов GetStorageDependencyInformation() и GetZoneFromAlternateDataStreamEx() равно уязвимость, в вашей системе координат. И опять почти все архиваторы "уязвимы", как так! А ведь именно проверка и через GetStorageDependencyInformation() реализована для MotW в Windows (кто не понял: так проверяется MotW в смонтированном контейнере VHD/VHDX, признак наследуется от файла-контейнера, даже если внутри у файла нет ADS)!
Гораздо проще: отсортировать файлы по значениям LSN или USN. Они возрастают вне зависимости от показаний системных часов.
Это не так. Flush — это запись в файл транзакции, все.
NtFreezeRegistry. Или создание теневой копии, под капотом там такой же вызов.
https://github.com/msuhanov/regf/blob/master/Windows registry file format specification.md
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
Еще парсер реестра Windows в systemd есть.
https://github.com/systemd/systemd/blob/main/src/boot/efi/bcd.c
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Но зачем? RECmd и Registry Explorer восстанавливают меньше удаленных данных, чем реально есть.
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Еще в 21 году начались проблемы.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?