Итак, жизнь возвращается в привычное русло, а я к вам - с презентациями:

1. Как мы искали следы компрометации нашей сети, или немного про нашу методологию проведения Compromise Assessment
2. На примерах из реальных кейсов, где и чего полезного можно найти в ошибках при расследовании инцидентов

#present

Вывели в свет,
причесали,
накрасили,
поспрашивали о нашей работе тушения пожаров

Маркерные слова культуры инженерного упадка в компании 😅

(доклад без записи)

Что-то захотелось напомнить, что вообще-то мы тут как бы за форензику двигаемся. Публикаций по теме маловато в канале, поэтому пришло время это исправить (да простят меня подписчики с другим бэкграундом, я совсем немножко)

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

Есессна, позже опубликую правильный ответ с комментариями

Правильные варианты ответа на вопрос: 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, если хотите), поэтому одной записи может не хватать. В таком случае, чтобы хранить все, выделяется несколько записей, и тогда первая считается базовой, а остальные - небазовыми дополнительными. В дополнительных указывается ссылка на базовую запись, а в базовой - все допы указываются в другом специальном атрибуте. Так вот, в этих самых дополнительных записях атрибутов $SI и $FN попросту нет

Далее. Возможно, вы замечали, что иногда у файлов их имя отображается как EXAMPL~1.TXT, и это тоже неспроста. Если у файла длинное имя, например, "Example of too long file name.txt", то для обратной совместимости с DOS и хранения как длинного, так и короткого имени файла, по умолчанию будет создано два атрибута $FN (так как именно $FN хранит имя файла). Соответственно, + еще четверка временных меток. 12, получается

Нюансов, на самом деле, и правда много. Например, если задать вопрос, сколько временных меток в целом можно найти у одного файла в NTFS, ответ будет несколько иным, и насчитываться их может и 12, и 16, и даже больше. Но это уже другая история

Ах да, небольшая бонусная часть. Если вы парсите $MFT каким-нибудь MFTECmd, можно столкнуться с тем, что часть временных меток пустует в табличке после парсинга. Это происходит не потому, что их нет, а потому, что множество меток идентичны, и чтобы не перегружать и без того сложную структуру, Эрик убрал в выводе по умолчанию абсолютные дубли (вернуть можно, добавив отдельный флаг к команде). Ну и всегда можно перепроверить себя, например, через istat

Под утренний кофе читала про 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

Когда даже мама вдумчиво читает каждый пост 🤌🏼

Второе издание той самой книги

Мне кажется, уже просто все неоднократно подтвердили, что это - однозначный must

В тему и не в тему, еще раз добавлю свою любимую и заезженную песню про сетевые модели. Казалось бы, это тоже база, но тем не менее она часто вызывает страдания и мучения, а на тех же собесах выглядит, как будто вас проверяют на какую-то скучную теорию из универа. Но поверьте, это не так, и сейчас я объясню почему

Знание моделей OSI или TCP/IP нужно не для того, чтобы просто знать ответ на вопрос, какой порт использует утилита ping для работы и успешно пройти собес. А, опять же, для того, чтобы понимать, с чем ты имеешь дело

Те же файерволлы могут работать на уровне L3 или L7, и смысл давать рекомендацию "заблокируйте вредоносный домен на файерволле", когда он просто не оперирует такими сущностями? Или другая ситуация: аналитик видит через netstat соединение с подозрительным айпи, но рядом стоит статус FIN-WAIT и для него это ни о чем не говорит. Какие выводы он сможет сделать? С адресной строкой в браузере тоже хороший пример, и таких ситуаций масса и не только с сетями

Нельзя быть экспертом во всем. Безопасникам вообще не повезло: операционные системы, сети, базы данных, аппсек и прочее-прочее, и везде надо что-то да понимать. Тем не менее, есть какие-то фундаментальные знания, без которых будет крайне сложно