Расписание начинают подгружать на сайт: 4 дня фестиваля, и спикеров в этом году так много, что процесс получился небыстрым. Честно, рада быть в списке рядом с такими талантливыми людьми!
Ну и удобное я название взяла для второго доклада, конечно, титульный слайд вот можно взять с любого модного сайта с цитатами,а говорить будем вообще про BSOD и сбои в работе всяких приложух
В общем, до встречи в Лужниках :)
upd: изменила линк на свой профиль
Ну и удобное я название взяла для второго доклада, конечно, титульный слайд вот можно взять с любого модного сайта с цитатами,
В общем, до встречи в Лужниках :)
upd: изменила линк на свой профиль
По этим фоткам можно понять, что за год у меня добавилась как минимум одна татуировка 😂
В общем, если где-то увидите меня и захотите пообщаться, не стесняйтесь подходить, буду рада :)
В общем, если где-то увидите меня и захотите пообщаться, не стесняйтесь подходить, буду рада :)
README.hta
Photo
Итак, жизнь возвращается в привычное русло, а я к вам - с презентациями:
1. Как мы искали следы компрометации нашей сети, или немного про нашу методологию проведения Compromise Assessment
2. На примерах из реальных кейсов, где и чего полезного можно найти в ошибках при расследовании инцидентов
#present
1. Как мы искали следы компрометации нашей сети, или немного про нашу методологию проведения Compromise Assessment
2. На примерах из реальных кейсов, где и чего полезного можно найти в ошибках при расследовании инцидентов
#present
Что-то захотелось напомнить, что вообще-то мы тут как бы за форензику двигаемся. Публикаций по теме маловато в канале, поэтому пришло время это исправить (да простят меня подписчики с другим бэкграундом, я совсем немножко)
Собственно, о наболевшем. Проводя собесы, заметила удивительную тенденцию, что многих кандидатов, при чем и с релевантным опытом тоже, вводит в тупик следующий вопрос. Может, уже расставим все точки над е?
Есессна, позже опубликую правильный ответ с комментариями
Собственно, о наболевшем. Проводя собесы, заметила удивительную тенденцию, что многих кандидатов, при чем и с релевантным опытом тоже, вводит в тупик следующий вопрос. Может, уже расставим все точки над е?
Есессна, позже опубликую правильный ответ с комментариями
Сколько временных меток может содержать одна запись (англ. MFT Entry, File Record) в $MFT? Не берем в расчет $I30, можно выбрать несколько вариантов ответа
Final Results
3%
0
4%
1
2%
2
6%
3
9%
4
30%
8
9%
12
2%
16+
52%
Не шарю, я только посмотреть
Правильные варианты ответа на вопрос:
Давайте по порядку, но будет много буков :)
$MFT - это, по сути, сердце NTFS, так как содержит информацию обо всех файлах и директориях в системе. Каждый файл или директория имеет как минимум одну запись в MFT-таблице по умолчанию размером 1 КБ (1024 байт) и у каждой есть структура: заголовок самой MFT-записи, далее идут атрибуты со своими заголовками, и оставшееся неиспользуемое пространство. Основных атрибутов насчитывается порядка 16, все они начинаются со знака $. В данном контексте это число сейчас непринципиально, главное понимать, что не все из них обязательно должны присутствовать в одной MFT-записи, или наоборот, на каждую запись может быть несколько идентичных типов атрибутов
Ну и тут мы подошли к самому интересному. Вопрос:
Сколько временных меток может содержаться в одной MFT-записи, не учитывая атрибуты $I30?
Судя по тому, что вариант с цифрой 8 все-таки в лидерах, тут особо объяснять не нужно. Речь идет о $STANDART_INFORMATION ($SI, значение 0х10) и $FILE_NAME ($FN, 0х30). В них хранятся не только временные метки, тем не менее, в каждом из них имеем по 4 таймстампа
и есть они почти у каждой записи. Необходимо знать принципиальную разницу этих атрибутов, так как это - основополагающий момент при криминалистическом анализе, то есть программа минимум. Дальше начинаются нюансы
Как было сказано ранее, атрибутов у каждой записи может быть много (2^16, если хотите), поэтому одной записи может не хватать. В таком случае, чтобы хранить все, выделяется несколько записей, и тогда первая считается базовой, а остальные -небазовыми дополнительными. В дополнительных указывается ссылка на базовую запись, а в базовой - все допы указываются в другом специальном атрибуте. Так вот, в этих самых дополнительных записях атрибутов $SI и $FN попросту нет
Далее. Возможно, вы замечали, что иногда у файлов их имя отображается как EXAMPL~1.TXT, и это тоже неспроста. Если у файла длинное имя, например, "Example of too long file name.txt", то для обратной совместимости с DOS и хранения как длинного, так и короткого имени файла, по умолчанию будет создано два атрибута $FN (так как именно $FN хранит имя файла). Соответственно, + еще четверка временных меток. 12, получается
Нюансов, на самом деле, и правда много. Например, если задать вопрос, сколько временных меток в целом можно найти у одного файла в NTFS, ответ будет несколько иным, и насчитываться их может и 12, и 16, и даже больше. Но это уже другая история
Ах да, небольшая бонусная часть.Если вы парсите $MFT каким-нибудь MFTECmd, можно столкнуться с тем, что часть временных меток пустует в табличке после парсинга. Это происходит не потому, что их нет, а потому, что множество меток идентичны, и чтобы не перегружать и без того сложную структуру, Эрик убрал в выводе по умолчанию абсолютные дубли (вернуть можно, добавив отдельный флаг к команде). Ну и всегда можно перепроверить себя, например, через istat
0, 8, 12
Давайте по порядку, но будет много буков :)
$MFT - это, по сути, сердце NTFS, так как содержит информацию обо всех файлах и директориях в системе. Каждый файл или директория имеет как минимум одну запись в MFT-таблице по умолчанию размером 1 КБ (1024 байт) и у каждой есть структура: заголовок самой MFT-записи, далее идут атрибуты со своими заголовками, и оставшееся неиспользуемое пространство. Основных атрибутов насчитывается порядка 16, все они начинаются со знака $. В данном контексте это число сейчас непринципиально, главное понимать, что не все из них обязательно должны присутствовать в одной MFT-записи, или наоборот, на каждую запись может быть несколько идентичных типов атрибутов
Ну и тут мы подошли к самому интересному. Вопрос:
Сколько временных меток может содержаться в одной MFT-записи, не учитывая атрибуты $I30?
Судя по тому, что вариант с цифрой 8 все-таки в лидерах, тут особо объяснять не нужно. Речь идет о $STANDART_INFORMATION ($SI, значение 0х10) и $FILE_NAME ($FN, 0х30). В них хранятся не только временные метки, тем не менее, в каждом из них имеем по 4 таймстампа
M (Modify) - изменение содержимого файла,
A (Access) - доступ,
C (Change) - изменение метаданных файла,
B (Birth) - создание файла,
и есть они почти у каждой записи. Необходимо знать принципиальную разницу этих атрибутов, так как это - основополагающий момент при криминалистическом анализе, то есть программа минимум. Дальше начинаются нюансы
Как было сказано ранее, атрибутов у каждой записи может быть много (2^16, если хотите), поэтому одной записи может не хватать. В таком случае, чтобы хранить все, выделяется несколько записей, и тогда первая считается базовой, а остальные -
Далее. Возможно, вы замечали, что иногда у файлов их имя отображается как EXAMPL~1.TXT, и это тоже неспроста. Если у файла длинное имя, например, "Example of too long file name.txt", то для обратной совместимости с DOS и хранения как длинного, так и короткого имени файла, по умолчанию будет создано два атрибута $FN (так как именно $FN хранит имя файла). Соответственно, + еще четверка временных меток. 12, получается
Нюансов, на самом деле, и правда много. Например, если задать вопрос, сколько временных меток в целом можно найти у одного файла в NTFS, ответ будет несколько иным, и насчитываться их может и 12, и 16, и даже больше. Но это уже другая история
Ах да, небольшая бонусная часть.
Под утренний кофе читала про Scriptblock Smuggling, или как обходить AMSI на лету и скрывать скрипты PowerShell. Выглядит прям хорошо, в классическом редтимерском стиле (потно и действительно эффектно ), но во время прочтения меня не покидала мысль
Нормально логируй, нормально будет: ведь в поше доступно несколько «уровней» логирования себя самого, не говоря уже про другие источники для обнаружения. А вот то, используете ли вы это на своей стороне, это уже другой вопрос :)
https://cloud.google.com/blog/topics/threat-intelligence/greater-visibility
https://woshub.com/powershell-commands-history/
https://www.powershellcenter.com/wp-content/uploads/2020/09/Hunting-For-PowerShell-Abuse.pdf
Нормально логируй, нормально будет: ведь в поше доступно несколько «уровней» логирования себя самого, не говоря уже про другие источники для обнаружения. А вот то, используете ли вы это на своей стороне, это уже другой вопрос :)
https://cloud.google.com/blog/topics/threat-intelligence/greater-visibility
https://woshub.com/powershell-commands-history/
https://www.powershellcenter.com/wp-content/uploads/2020/09/Hunting-For-PowerShell-Abuse.pdf