После запуска подозрительного проекта: как собрать факты и ограничить ущерб

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

У этой задачи две линии работы. Первая — реагирование: изоляция, защита доступов, восстановление. Вторая — расследование: какой процесс запускался, что получил по сети и какие изменения оставил. Они связаны, но ни одна не требует придумывать недостающие события.

Сначала устанавливаем, что известно

Фраза «нашёл вредоносный файл» может описывать совершенно разные ситуации. Архив лежит в загрузках. Либо команда пыталась стартовать и завершилась ошибкой. Либо неизвестный код действительно исполнялся в рабочем окружении.

Для первой записи достаточно нескольких строк:

1
2
3
4
5

Объект: компьютер и учётная запись.
Время: когда получен проект, с указанием часового пояса.
Действия: что пользователь действительно делал.
Свидетельства: журнал, процесс, файл, сетевое событие.
Неизвестно: что пока не удалось установить.

Слова пользователя сохраняют как сообщение пользователя. Событие из журнала — как событие из конкретного журнала. «Я ничего не запускал» может означать «не нажимал кнопку запуска приложения», поэтому уточняют установку, задачи редактора и команды проверки.

Ограничить связь, не уничтожив следы

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

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

Руководство CISA по реагированию отдельно подчёркивает изоляцию и сохранение изменчивых данных. Оно посвящено вымогательским атакам; здесь мы используем общий принцип сохранения свидетельств, а не приписываем рассматриваемому проекту функции шифровальщика. [1]

Минимальный сбор на macOS

На изолированном компьютере можно сохранить исходные результаты чтения процессов и соединений. Команды выполняют из обычного терминала, не через задачи или скрипты подозрительного проекта. Это не полноценный криминалистический образ, а первичная фиксация:

1
2
3
4
5
6
7

umask 077
TRIAGE_DIR="$(/usr/bin/mktemp -d "${TMPDIR:-/tmp}/repo-triage.XXXXXX")" || exit 1
/bin/date -u '+%Y-%m-%dT%H:%M:%SZ' > "$TRIAGE_DIR/collected-at-utc.txt"
/usr/bin/sw_vers > "$TRIAGE_DIR/macos.txt"
/bin/ps -axww -o pid,ppid,user,lstart,command > "$TRIAGE_DIR/processes.txt"
/usr/sbin/lsof -nP -i > "$TRIAGE_DIR/connections.txt" 2> "$TRIAGE_DIR/lsof-errors.txt"
printf 'Сведения сохранены: %s\n' "$TRIAGE_DIR"

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

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

Где искать продолжение цепочки

Рабочие записи исходного случая упоминали пути ~/node/main.js и ~/Programs_X64/main.js. Это ориентиры для поиска по определённым образцам, а не универсальные признаки заражения. Каталог с таким именем может существовать по другой причине; отсутствие каталога не доказывает отсутствия исполнения.

Сначала сравнивают содержимое, хэши, время появления и связь с процессом. Затем смотрят места фонового запуска. Для macOS к ним относятся пользовательские и системные LaunchAgents/LaunchDaemons; формат launchd и роль этих каталогов описаны Apple. [2]

1
2
3

~/Library/LaunchAgents/
/Library/LaunchAgents/
/Library/LaunchDaemons/

Проверка этих каталогов не исчерпывает возможные механизмы закрепления. И сам файл .plist, даже запускающий Node.js, не обязательно вредоносен. Нужны его происхождение, команда, связанный файл и сведения о загрузке задания.

Доступы защищают с доверенного устройства

Если неизвестный код мог исполняться с правами пользователя, составляют перечень доступных ему секретов и активных сессий. Это оценка возможного доступа, а не доказательство, что всё было украдено.

Приоритет определяют полномочия: доступ к почте и управлению учётными записями, инфраструктуре, репозиториям, платёжным системам и другим критичным ресурсам. Действующие сессии и токены отзывают, ключи заменяют, журналы входов проверяют с доверенного устройства. Универсальный порядок «сначала Git, потом SSH, пароли в конце» здесь не подходит: почта для восстановления может быть важнее любого отдельного токена.

Новые секреты не возвращают на ещё не восстановленную машину. Переустановка также не отзывает доступ, который уже существует в облачном сервисе: восстановление компьютера и защита учётных записей — разные задачи.

Когда восстанавливать систему заново

Сам факт наличия опасного файла в скачанном архиве не является автоматическим основанием для стирания системы. Но при подтверждённом исполнении неизвестной следующей стадии и значимых доступах доверие к окружению может быть невозможно восстановить одной точечной очисткой.

В таком случае после необходимого сбора рассматривают восстановление из доверенного источника и осторожный возврат данных. Это не обещание абсолютной гарантии. Решение зависит от масштаба, полноты наблюдений, допустимого риска и возможностей расследования.

Отсутствие находок при поверхностном поиске означает именно отсутствие найденных следов, а не доказанную чистоту.

Задача: что подтверждают события?

Даны учебные события:

1
2
3
4

10:02 — пользователь открыл папку;
10:03 — журнал содержит запуск node с аргументом .vscode/helper.dict;
10:03 — зарегистрировано исходящее соединение этого процесса;
10:04 — процесс завершился; тело ответа не сохранено.

Составьте короткое заключение: что подтверждено и какие сведения о возможной следующей стадии отсутствуют?

Источники

[1] CISA, FBI, NSA и MS-ISAC: #StopRansomware Guide, Part 2 — изоляция и сохранение свидетельств; копия на сайте FBI/IC3.

[2] Apple: Creating Launch Daemons and Agents.

Связанный материал сайта: основы форензики. Все события в упражнении синтетические; это не журнал компьютера участника исходного случая.