Во время анализа системы Linux, подвергшейся взлому, обнаружен файл snif-ferlog-l.dat, содержащий сетевые пакеты. Другие файлы каталога обладают именами вида log-001.dat и не содержат сетевых данных. Содержимое каталога выглядит так:

# fis -f linux-ext3 ext3-8.dd 1840555

г/г 1840556: log-001.dat

г/г 1840560: log-002.dat

г/г 1840566: log-003.dat

г/г 1840569: log-004.dat

г/г 32579: snifferlog-l.dat

г/г 1840579: log-005.dat

г/г 1840585: log-006.dat

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

У родительского каталога и остальных файлов адреса индексных узлов находятся где-то около 1 840 500, но файл snifferlog-l.dat обладает адресом 32 579. Согласно стратегии выделения, используемой в Linux, файлы обычно создаются в индексных узлах той же группы, к которой принадлежит родительский каталог. Следовательно, либо файл snifferlog-l.dat был изначально создан в другом родительском каталоге, а потом перемещен в текущий каталог, либо он был создан в текущем каталоге, а группа блоков была заполнена до предела.

По результатам fsstat мы определяем, что каталог журналов принадлежит к группе блоков 113, в которой 99 % индексных узлов и 48 % блоков свободны. Маловероятно, чтобы группа была заполнена в момент создания файла, если только с того момента не произошло массовое удаление файлов:

Group: 113:

Inode Range: 1840545 - 1856832 Block Range: 3702784 - 3735551 Free Inodes: 16271 (99«)

Free Blocks: 15728 (48«)

Более подробный анализ индексного узла snifferlog-l.dat (32 579) показывает, что узел входит в группу блоков 2:

Group: 2:

Inode Range: 32577 - 48864 Block Range: 65536 - 98303 Free Inodes: 16268 (99%)

Free Blocks: 0 (0%)

Напрашивается предположение, что файл был создан в каталоге группы блоков 2, а затем перемещен в группу блоков 113. Таким образом, мы попробуем найти в группе блоков 2 каталоги, которые могли бы быть родительскими каталогами по отношению к snifferlog-l.dat. В пакете TSK для решения этой задачи используется программа ils, выводящая подробную информацию об индексных узлах из заданного интервала. При запуске мы задаем интервал для группы блоков, в которой производится поиск, и отфильтровываем все результаты, не относящиеся к каталогам. Ключ -т преобразует данные режима в наглядный формат, понятный для пользователя, а ключ -а ограничивает поиск используемыми индексными узлами. Утилита grep отфильтровывает все результаты, не относящиеся к каталогам (по содержимому пятого столбца).

# ils -f linux-ext3 -ш -a ext3-8.dd 32577-48864 grep "d"

<ext3-8.dd-al1ve-32577>03257716893drwxrwxr-x4[50050004096

<ext3-8.dd-al1ve-32655>(03265516893drwxrwxr-x250050004096

<ext3-8.dd-ali ve-32660>101325771168771drwxr-xr-x121500150010140961

Первый столбец содержит фиктивное имя для каждой записи. Свободные записи помечаются строкой «dead», а выделенные - строкой «alive». Третий столбец содержит адрес индексного узла. Обычно результаты ils обрабатываются утилитой mactime для построения временных диаграмм, поэтому их формат не слишком удобен для пользователя.

Для просмотра трех каталогов мы воспользуемся программой fis. Каталог в индексном узле 32577 представляется наиболее перспективным.

# fis -f linux-ext3 ext3-8.dd 32577 r/r 32578: onlyjive_twice.mp3

r/r 32582: goldfiлдег.шрЗ

г/г 32580: 1 ic_to_kil 1 .гпрЗ

r/r 32581: diamonds_forever.mp3

На первый взгляд похоже на невинный каталог с музыкой из фильмов о Джеймсе Бонде в формате МРЗ... но обратите внимание на индексные узлы и вспомните, что мы знаем о стратегиях выделения индексных узлов и записей каталогов. При выделении индексных узлов используется стратегия поиска первого доступного узла в группе блоков. Файл с содержимым сетевых пакетов находился в индексном узле 32 579, расположенном между only_live_twice.mp3 и lic_to_kill.mp3. Также обратите внимание, что goldfinger.mp3 обладает большим номером индексного узла, чем остальные файлы, и находится в середине каталога. Более того, длина имени goldfinger.mp3 равна 14 символам, а длина snifferlog-l.dat - 16 символам; это означает, что оба файла поместились бы в записи каталога одного размера.

При анализе файлов выясняется, что файл only_live_twice.mp3 является исполняемым, а другие файлы содержат журналы сетевых пакетов в том же формате, что и snifferlog-l.dat. Кроме того, временные штампы only_live_twice.mp3 предшествуют временным штампам snifferlog-l.dat, а временные штампы lic_to_kill.mp3 следуют за snifferlog-l.dat.

Рис. 14.12. Файл snifferlog-l.dat перемещен из каталога в группу блоков 2

На основании собранной информации выдвигается следующая гипотеза: файл snifferlog-l.dat был создан после файла onlyJ.ive_twice.mp3, после чего был создан файл Ііс_І:о_кіІІ.трЗ. Через некоторое время после создания файла diamonds_for-

ever.mp3 файл snifferlog-l.dat был перемещен в каталог, находящийся в группе блоков ИЗ. После его перемещения был создан файл goldfinger.mp3, который заменил запись каталога и получил следующий доступный индексный узел. М-и С-время индексного узла 32 577 совпадают с данными файла goldfinger.mp3, причем в обоих случаях они следуют за временными штампами файла snifferlog-

l.dat. Ситуация показана на рис. 14.12: запись каталога в группе ИЗ ссылается на индексный блок в группе 2. Мы все еще не знаем, как произошло перемещение файла и всегда ли он существовал под текущим именем или ранее он был замаскирован под МРЗ-файл. Возможно, анализ исполняемого файла прольет свет на эти вопросы.

Хеш-деревья | Криминалистический анализ файловых систем | Порядок удаления файлов


Криминалистический анализ файловых систем



Новости за месяц

  • Март
    2020
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс