Форензика on CTF.MSK.RU

От HTTP-ответа к выполнению кода: читаем опасную цепочку в JavaScript

Fri, 13 Nov 2026 00:00:00 +0300

Поиск по репозиторию нашёл Function.constructor. Кажется, подозрение подтвердилось. Но что именно мы доказали? Динамическое создание функции разрешено языком JavaScript. Чтобы объяснить опасность, нужно показать, откуда пришёл её текст, будет ли она вызвана и какие возможности получит.

Это обычная задача на чтение потока данных. В CTF такой подход помогает найти уязвимость; при проверке внешнего проекта — восстановить устройство загрузчика и условия его работы.

Что превращается в код

Рассмотрим сокращённый учебный фрагмент. Он дан для чтения, не для запуска: функция объявлена, но не вызывается; реальный HTTP-клиент и адрес не заданы. Предположим, что при вызове клиент вернул бы текст ответа в response.data:

1
2
3
4
5
6


async function loadSettings(client, endpoint) {
 const response = await client.get(endpoint);
 const body = response.data;
 const apply = new Function("require", body);
 apply(require);
}

Название loadSettings обещает загрузку настроек. Реальная последовательность другая. Ответ HTTP-запроса попадает в body. Эта строка становится телом новой функции. Затем функция вызывается с аргументом require.

Конструктор Function компилирует переданную строку как тело функции; само создание функции ещё не исполняет её тело. В примере выполнение происходит на последней строке. Новая функция не захватывает локальную область видимости создавшей её функции так, как обычное замыкание. Поэтому явная передача require — существенная деталь. [1]

В типичном CommonJS-окружении Node.js это даёт переданному коду возможность обращаться к доступным модулям. Но пределы действий определяются реальной средой и правами процесса, а не словом RCE в отчёте. [2]

В реальном разборе нужно проверить и тип response.data: HTTP-клиент может вернуть уже разобранный объект, а не исходную строку. Function приводит аргумент тела к строке, после чего проверяет синтаксис. Ошибка на этом этапе не даст дойти до apply. Это ещё одна причина не объявлять успешное исполнение по одному имени свойства. [1]

Как оформить доказательство

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

1
2
3
4
5


Источник: тело HTTP-ответа.
Преобразование: response.data передаётся без проверки в конструктор функции.
Исполнение: созданная функция вызывается.
Возможности: ей передаётся require текущего CommonJS-модуля.
Неизвестно: была ли вызвана loadSettings и какой ответ получил этот хост.

Последняя строка не обесценивает находку. Она отделяет установленный механизм от событий, для которых пока нет свидетельств.

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

`eval`, `Function` и `Function.constructor`

eval и Function различаются по области видимости и правилам выполнения, однако обе конструкции могут превратить строку в код. Поэтому при аудите важнее происхождение строки, чем выбор одного из этих механизмов. [1][3]

Выражение Function.constructor в обычной, не изменённой среде JavaScript обращается к тому же конструктору Function. Но автоматическое правило, ищущее только new Function(, может пропустить эту запись. Поиск текста полезен как первый фильтр; он не равен анализу семантики. [1][4]

Отдельная ошибка — смешивать браузер и Node.js. Браузерные строковые таймеры и политика CSP относятся к веб-среде. В Node.js setTimeout ожидает функцию и при передаче другого типа выдаёт ошибку. Браузерная CSP не защищает запущенный на ноутбуке Node-процесс. [5][6]

Деталь API может изменить вывод

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

1

axios.post(url, { headers: { "x-secret-header": "secret" } });

В стандартном API Axios второй аргумент post — данные запроса, а конфигурация передаётся третьим. Следовательно, такой фрагмент сам по себе не устанавливает отправку HTTP-заголовка x-secret-header: он описывает объект в теле запроса. Заголовки могут добавляться другими настройками, но это нужно проверить отдельно. [7]

Для расследования различие практическое. Искомая строка может оказаться в другом месте сетевого обмена, а ожидаемый сервером заголовок вообще не отправиться. Это не делает вызов динамического кода безопасным, но влияет на то, могла ли сработать конкретная ветвь.

Что делать с находкой

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

В собственном приложении загрузку настроек обычно стоит проектировать как получение данных: разбор JSON, проверка схемы и явное применение допустимых полей. Замена eval на new Function не решает проблему доверия.

Если действительно требуется исполнение внешних программ, нужна отдельная архитектура ограничения полномочий. node:vm не следует считать защитной песочницей: документация Node.js прямо предупреждает, что этот модуль не предназначен для безопасного выполнения недоверенного кода. [8]

Задача: исполнение или только подготовка?

Файлы для самостоятельного разбора доступны в синтетическом практикуме.

Сравните три учебные строки независимо друг от друга. Предполагаются обычные встроенные функции JavaScript и CommonJS-окружение с доступным require; при разборе C учитывайте, что создание функции может завершиться ошибкой:

1
2
3


const a = JSON.parse(response.data);
const b = new Function("return 2 + 2");
const c = new Function("require", response.data)(require);

Показать разбор

Разбор. В A строка разбирается как JSON; само это действие не исполняет её как JavaScript, хотя дальнейшее использование данных тоже требует проверки. В B создаётся функция с постоянным телом, но в показанной строке не вызывается. В C ответ передаётся конструктору как тело функции; если создание функции успешно, она сразу вызывается. Для C нужно выяснить происхождение response, достижимость строки и среду выполнения.

Ни одному из этих выводов не требуется слово «почти всегда». Достаточно назвать конкретное действие и его условия.

Источники

[1] ECMAScript: конструктор Function и CreateDynamicFunction.

[2] Node.js: CommonJS modules.

[3] ECMAScript: eval.

[4] ECMAScript: свойства Function.prototype.

[5] Node.js: Timers.

[6] W3C: Content Security Policy.

[7] Axios: сигнатуры методов в официальном репозитории, документация API.

[8] Node.js: VM — предупреждение о границах безопасности.

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

Fri, 13 Nov 2026 00:00:00 +0300

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

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

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

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

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

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.

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

Проверка репозитория до запуска: как устроить безопасный статический контроль

Fri, 13 Nov 2026 00:00:00 +0300

После нескольких разборов хочется автоматизировать проверку: искать автозадачи, установочные хуки и динамическое исполнение. Но возникает неприятная ловушка. Команда «сначала запустим линтер» сама может выполнить код из проверяемого проекта.

Поэтому задача этой статьи — не собрать максимальный список запретов. Нужно устроить процесс так, чтобы проверяемые файлы оставались данными, а решения о запуске принимались отдельно.

Кто управляет проверкой?

У ESLint есть конфигурации eslint.config.js, .mjs, .cjs и другие поддерживаемые варианты. Конфигурация может импортировать модули и плагины. Значит, запуск линтера с настройками неизвестного проекта — это не просто чтение текста: он включает загрузку исполняемой конфигурации. [1]

Сначала проверяющий инструмент, его правила и зависимости должны находиться в доверенном окружении. Подозрительный репозиторий передаётся туда только как материал. Это относится и к скрипту под названием security-check, и к предложенному README вызову npx, и к конфигурации CI из самого репозитория.

Особенно опасно переносить непроверенный код на постоянный CI-исполнитель с секретами или доступом во внутреннюю сеть. Документация GitHub прямо предупреждает, что self-hosted runners могут быть скомпрометированы недоверенным кодом и сохранить изменения между запусками. [2]

Три слоя проверки

Первый слой — состав материала. Получаем перечень файлов, размеры, ожидаемые форматы и контрольные суммы. Для архивов заранее задаём пределы количества и суммарного размера распакованных данных, проверяем пути, ссылки и повторяющиеся имена. Открытие архива не равно исполнению его скриптов, но само распаковывание тоже требует аккуратности. [3]

Второй слой — признаки исполнения. Читаем .vscode, package.json, .npmrc, точки входа и конфигурации инструментов. Не ограничиваемся расширениями .js: предыдущая статья о поддельном шрифте как раз показывает, почему такой фильтр недостаточен.

Третий слой — связная проверка находки. Для подозрительной конструкции устанавливаем источник данных и достижимость вызова. Этот этап нельзя полностью заменить поиском слова eval.

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

Простой поиск: полезный, но ограниченный

В небольшой, уже безопасно подготовленной копии можно начать с доверенного rg:

1
2
3
4


rg --no-config --hidden --no-ignore --text --files-with-matches \
 --glob '!.git' --max-filesize 2M \
 'Function\s*\.\s*constructor|new\s+Function\s*\(|eval\s*\(|"runOn"\s*:\s*"folderOpen"|"(preinstall|install|postinstall|prepare)"\s*:' \
 -- /analysis/input

Путь /analysis/input здесь обозначает копию материала в подготовленной среде. Команда показывает имена файлов с совпадениями, а не запускает их. Она включает скрытые файлы и ищет текст независимо от расширения. Шаблон !.git исключает каталоги и файлы с этим именем, в том числе при передаче абсолютного пути. Символические ссылки по умолчанию не обходятся; их наличие проверяют при подготовке копии. Поведение параметров описано в документации ripgrep. [4]

Предел размера — осознанное ограничение примера, не способ объявить большие файлы безопасными. Их нужно учесть отдельно. Как и ошибки чтения, неподдержанные кодировки, многослойную обфускацию и конструкции, записанные иначе. У rg код 0 означает найденные совпадения, 1 — отсутствие совпадений, 2 — ошибку. Ошибку нельзя выдавать за чистый результат; отсутствие совпадений тоже не превращает поиск в антивирус.

Что делать с результатом

Полезно разделить два типа правил.

Политика процесса: «В принимаемом тестовом задании запрещён автозапуск при открытии». Нарушение может блокировать приём, даже если задача безобидна. Причина блокировки — несоответствие политике, не доказанная малварь.

Техническая находка: «Ответ внешнего сервера передаётся в исполняемое тело функции и вызывается из импортируемого модуля». Здесь требуется разбор конкретной цепочки.

Исключения должны утверждаться вне проверяемого изменения. Комментарий eslint-disable или nosemgrep, добавленный автором подозрительного кода, не может сам себе разрешить опасное поведение. Для доверенных проектов линтеры с правилами no-eval и no-new-func полезны как часть обычной разработки. Для недоверенного материала сначала устанавливается граница между данными и инструментом. [1][5]

Semgrep позволяет задавать правила анализа структуры кода и текстовые шаблоны. Но готовое правило нужно проверять на своих примерах, включая переименованные файлы и заведомо легитимный код. Наличие названия инструмента в CI ещё ничего не говорит о покрытии. [6]

Задача: проверьте проверяющего

Предложены три способа:

1
2
3


А. Запустить npm run security-check из присланного проекта.
Б. Передать копию файлов локальному сканеру вне проекта, с доверенными правилами.
В. Собрать проект на постоянном CI-сервере, а потом просканировать результат.

Для отдельной проверки поискового шаблона возьмите literal-positive.txt, literal-negative.txt и flow.js.txt из практикума. Предскажите, какие файлы совпадут с шаблоном, и проверьте себя поиском. Для каждого совпадения укажите, откуда берётся тело функции и при каких условиях оно могло бы исполниться. Читайте примеры как текст.

Показать разбор

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

Шаблон совпадает в literal-positive.txt и flow.js.txt. В первом тело функции задано строковым литералом, а сама функция в этом фрагменте не вызывается. Во втором тело берётся из данных ответа. До вызова программа должна получить и разобрать ответ, прочитать нужное поле и успешно создать функцию. Поиск показывает место для проверки. Из текста можно вывести условия вызова, но для утверждения о состоявшемся исполнении понадобятся наблюдения за запуском. В literal-negative.txt есть только присваивание числа.

Что стоит запомнить

Автоматизация полезна тогда, когда экономит внимание и сохраняет проверяемость. Хороший результат статического контроля — список находок с причинами, ограничениями покрытия и решениями о допуске. Формулировка «угроз не найдено» без описания того, что проверялось, слишком мало сообщает следующему человеку.

Источники

[1] ESLint: Configuration Files.

[2] GitHub Actions: Secure use reference — self-hosted runners.

[3] Python: zipfile — предупреждения о распаковке и ограничениях.

[4] ripgrep: руководство по параметрам.

[5] ESLint: no-new-func.

[6] Semgrep: Rule syntax.

Репозиторий как ловушка: от настроек VS Code к запуску кода

Fri, 13 Nov 2026 00:00:00 +0300

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

С такой истории начался этот цикл. В январе 2026 года мы обсуждали три архива репозиториев Bitbucket. По сообщению участника разбора, один проект успели запустить на MacBook; два других изучали без запуска. Рабочие записи описывали автозадачи редактора, JavaScript под видом шрифта или словаря и получение исполняемого кода из сети. Само сообщение о запуске ещё не устанавливает, какая часть цепочки сработала и что произошло дальше.

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

С чего начинается проверка

В CTF полезно сначала спросить: какие данные нам дали и что именно требуется доказать? Здесь исходные данные — файлы проекта. Вопрос — может ли какой-либо из них привести к исполнению команд до обычного запуска приложения?

Начнём с .vscode/tasks.json. Это конфигурация задач VS Code. Задачи могут вызывать внешние инструменты, а значение runOptions.runOn: "folderOpen" задаёт запуск при открытии содержащей их папки. Однако автоматическое выполнение зависит от разрешений: в недоверенной рабочей области такие задачи не запускаются; в доверенной отдельно учитывается разрешение автоматических задач. [1]

Поэтому формула «открыл папку — заразился» пропускает существенную часть условий. Нужно установить, была ли папка доверенной, были ли разрешены автозадачи и смогла ли команда выполниться. Workspace Trust мог быть задан раньше, в том числе для родительского каталога. [2]

В нынешнем VS Code автоматическими задачами управляет task.allowAutomaticTasks. Явно заданное значение off запрещает их запуск; on разрешает запуск в доверенной рабочей области без нового вопроса. Если выбор для неё ещё не сделан, редактор предлагает разрешить или запретить автозадачи. Поэтому отсутствие диалога при конкретном открытии папки само по себе ничего не доказывает. [1]

Читаем задачу как программу

Ниже одна задача из массива tasks, а не полный файл конфигурации. Фрагмент нужно читать, а не сохранять в действующий .vscode/tasks.json:

1
2
3
4
5
6
7


{
 "label": "Prepare preview",
 "type": "process",
 "command": "node",
 "args": ["webfonts/preview.woff2"],
 "runOptions": { "runOn": "folderOpen" }
}

Название Prepare preview ничего не доказывает: это подпись в интерфейсе. Значимые сведения находятся в других полях. Исполняемой программой указан node; аргумент похож на путь к шрифту; повод для запуска — открытие папки.

Из этого пока следует один вывод: конфигурация предлагает передать файл с расширением .woff2 интерпретатору Node.js. У задачи необычное назначение, и целевой файл нужно исследовать. Но утверждение «из компьютера уже украли ключи» здесь не имеет опоры.

В настоящем проекте также проверяют рабочий каталог задачи, зависимости от других задач и отдельные варианты команд для разных операционных систем. Один просмотр строки command может не показать всей последовательности. [1]

Три разных вопроса вместо одного

Разбор становится точнее, когда мы разделяем возможность, событие и последствие.

Что умеет делать проект? Ответ дают конфигурация, вызываемые файлы и доступные ветви кода.

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

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

Это разделение пригодится во всём цикле. Оно позволяет серьёзно отнестись к риску, не превращая вероятный сценарий в установленный факт.

Как осматривать внешний проект

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

Если используется VS Code, оставьте проект в Restricted Mode и проверьте, не наследует ли каталог доверие. Этот режим ограничивает определённые возможности редактора, но не изолирует команду, которую вы сами затем запустите в терминале. [2]

Для незнакомого проекта важны не только настройки IDE. В следующих статьях мы отдельно посмотрим на содержимое «ассетов», импорты JavaScript и хуки установки. Удаление одной подозрительной задачи не гарантирует, что других путей запуска нет.

Задача: какой вывод выдерживает проверку?

Файлы для самостоятельного разбора доступны в синтетическом практикуме.

Вам дали фрагмент выше и три сообщения:

1
2
3


А. Архив скачан. Папка в редакторе не открывалась.
Б. Папка открывалась в Restricted Mode. Задачи не разрешали.
В. Сохранилась запись запуска: node webfonts/preview.woff2.

Что можно утверждать в каждом случае?

Показать разбор

Разбор. В случае А известен только факт получения архива. В случае Б описанный механизм автозадачи должен быть заблокирован режимом доверия; это не универсальное заключение о любых возможных действиях на машине. В случае В есть свидетельство запуска интерпретатора с конкретным аргументом. Для вывода об успешном выполнении файла нужны результат запуска и последующие события.

Следующий шаг для всех трёх случаев одинаков: проверить содержимое preview.woff2. Следующий шаг для расследования компьютера — разный: в случае В потребуется восстановить ход выполнения.

Что стоит запомнить

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

Источники

[1] VS Code: Tasks — настройка задач и управление автоматическим запуском.

[2] VS Code: Workspace Trust — Restricted Mode и наследование доверия.

История происхождения цикла основана на сообщениях участников и рабочих записях разбора от 12 января 2026 года. Повторная проверка исходных архивов не входит в эту редакцию. Поведение редактора сверено с документацией при редакции 13 ноября 2026 года; для расследования старого запуска нужна версия редактора того времени.

Следы в сети: как связать процесс, запрос и файл — и не додумать лишнего

Fri, 13 Nov 2026 00:00:00 +0300

В подозрительном проекте найден сетевой адрес. В журнале есть обращение к похожему домену. Возникает соблазн сразу написать: «Загрузчик связался с командным сервером и похитил данные».

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

Что сообщает каждый источник

DNS-журнал может показать запрос имени и ответ резолвера. Сам по себе он не устанавливает успешное HTTP-соединение, получение полезной нагрузки или исполнение ответа. Процесс мог запросить имя и завершиться с ошибкой; запрос мог выполнить другой компонент.

Сетевой поток показывает соединение и, в зависимости от источника, адреса, время и объём передачи. Для HTTPS путь URL, заголовки и тело запроса защищены TLS. Обычный пассивный захват без ключей расшифрования не позволяет искать в них x-secret-header. Такие сведения могут быть доступны в журнале приложения, на узле завершения TLS или в разрешённой системе инспекции. [1]

Имя из SNI иногда помогает, но его наблюдаемость нельзя считать обязательной: ECH предназначен для шифрования внутреннего ClientHello, включая целевое имя. При его использовании наблюдаемое внешнее имя может относиться к общей инфраструктуре, а не к целевому сайту. При этом ECH сам по себе не скрывает IP-адрес назначения и открытые DNS-запросы. [2]

Журнал процессов связывает событие с программой, аргументами и родительским процессом. Для корреляции желательно иметь не только PID, но и время создания либо устойчивый идентификатор процесса: один числовой PID может использоваться повторно. Точный состав полей зависит от средства сбора.

Собираем цепочку

Для учебной задачи полезна следующая схема:

1
2
3
4
5


действие в рабочем проекте
 → процесс и его родитель
 → сетевое событие того же процесса
 → полученный или созданный файл
 → запуск этого файла либо другое последующее действие

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

Хорошая корреляция использует один компьютер, согласованное время, устойчивую связь процессов и содержание артефактов. Совпадение «где-то запущен Node.js» и «кто-то обратился к облачному сервису» слишком широко для вывода о вредоносном поведении.

Учебный журнал

Файлы для самостоятельного разбора доступны в синтетическом практикуме.

Ниже синтетические данные одного компьютера за один день; время приведено в UTC. Имя delivery.invalid и идентификаторы придуманы для упражнения; обращаться к ним не нужно. Поле entity обозначает устойчивый идентификатор экземпляра процесса, а status=connected в этом условном формате — успешно установленное TLS-соединение.

1
2
3
4
5
6
7


10:00:02 host=lab-1 event=process entity=p17 parent=editor-1
 command="node webfonts/preview.woff2"
10:00:03 host=lab-1 event=dns process=p17 query=delivery.invalid
10:00:04 host=lab-1 event=tls process=p17 status=connected
10:00:05 host=lab-1 event=file-write process=p17 path=/lab/stage.js
10:00:06 host=lab-1 event=process entity=p18 parent=p17
 command="node /lab/stage.js"

Сформулируйте подтверждённые события и укажите, каких данных не хватает для вывода о доставке кода и краже секретов.

Показать разбор журнала

Что подтверждено при условии достоверности журнала? Процесс p17 запущен с необычным аргументом, ему сопоставлены сетевые события и запись файла. Затем зарегистрирован дочерний процесс Node.js с путём к этому файлу в аргументах.

Чего не хватает? В событии TLS нет адреса назначения или идентификатора, связывающего его с DNS-ответом: даже один и тот же процесс может параллельно обращаться к разным серверам. Без содержимого сетевого ответа нельзя утверждать, что файл целиком получен именно из этого соединения. Для связи записанного файла с исполненным также нужны сведения о его содержимом и изменениях между событиями: одно совпадение пути не устанавливает тождество байтов. Без содержимого stage.js и дальнейших следов неизвестно, выполнилась ли кража данных. Даже успешный запуск интерпретатора не доказывает, что программа дошла до нужной исследователю ветви.

Итоговая запись может звучать так: «Зафиксирована последовательность запуска, сети, записи файла и запуска дочернего процесса; предполагаемая доставка следующей стадии требует подтверждения содержимым артефактов».

Как использовать индикаторы

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

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

Для публичного текста подозрительные адреса удобно обезвреживать записью вида hxxps://host[.]example/path. Это защита от случайного перехода, не способ изменить смысл индикатора. Для машинного использования исходное значение хранят отдельно, с контролем доступа и отметкой источника.

Особенно осторожно следует обращаться с общей инфраструктурой. Наблюдение одного подозрительного поддомена не делает вредоносными весь vercel.app, все соседние проекты или общий IP-адрес. Блокировка должна соответствовать доказанному объекту и учитывать сопутствующий ущерб.

MITRE ATT&CK описывает действия, а не заменяет доказательства

Если установлен контекст атаки, исполнение JavaScript можно соотнести с T1059.007, а подтверждённую доставку дополнительного инструмента или файла в скомпрометированную среду — с T1105. Обычные загрузки и запуск легитимного JavaScript сами по себе не становятся техниками атакующего. Но запрос имени ещё не доказывает передачу, а наличие кода загрузки показывает возможность, а не обязательно наблюдённое действие на конкретном компьютере. [3][4]

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

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

Задача: уберите лишнее из заключения

Исследователь пишет: «В архиве найден URL. Компьютер обращался к этому домену. Значит, пароль от облака украден».

Показать разбор

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

Завершение цикла

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

Проверить файл — не то же самое, что проверить его расширение. Найти загрузчик — не то же самое, что установить его исполнение. Зафиксировать соединение — не то же самое, что доказать утечку. Умение удерживать эти различия делает технический разбор полезным и для решения CTF-задачи, и для реального расследования.

Источники

[1] RFC 8446: TLS 1.3.

[2] RFC 9849: TLS Encrypted Client Hello.

[3] MITRE ATT&CK: T1059.007 — JavaScript.

[4] MITRE ATT&CK: T1105 — Ingress Tool Transfer.

Тестовое задание на отдельной машине: порядок приёма внешнего кода

Fri, 13 Nov 2026 00:00:00 +0300

Тестовое задание создаёт понятное ожидание: кандидат должен показать, что умеет работать с проектом. Этим можно воспользоваться, подменив проверку навыков просьбой запустить неизвестный код в рабочем окружении.

Такие сценарии описаны исследователями Unit 42 на примере Contagious Interview: злоумышленники выдавали себя за участников процесса найма и предлагали разработчикам заражённое программное обеспечение. Это подтверждает существование вектора, но не позволяет автоматически отнести любой подозрительный репозиторий к той же кампании. [1]

Разумный порядок приёма задания защищает обе стороны. Кандидату не нужно оправдываться за осторожность, а компания получает воспроизводимый результат вместо случайного запуска на чьём-то ноутбуке.

Проверяем связь, а не впечатление

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

Это не техническая экспертиза кода. Подтверждённый сотрудник тоже может прислать ошибочный или скомпрометированный материал. Поэтому проверка личности отправителя и проверка артефакта решают разные задачи.

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

До запуска нужно определить условия

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

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

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

Изоляция определяется доступами

Для заведомо подозрительного проекта разумнее отдельная одноразовая виртуальная машина с чистым состоянием. В ней не должно быть рабочих секретов, подключённого домашнего каталога, перенаправленного SSH-agent, профиля основного браузера или свободного доступа во внутреннюю сеть. Обмен папками и буфером обмена включают только при обоснованной необходимости. Для первоначального разбора сеть отключают. Если динамическое исследование требует сетевого обмена, отдельно готовят контролируемую лабораторную сеть с журналированием и подменой внешних сервисов; соединения с адресами из образца не разрешают автоматически.

Контейнер может быть частью такой среды, но слово Docker не даёт гарантии. Проброшенный каталог, доступ к Docker socket и избыточные полномочия способны разрушить ожидаемую изоляцию. В Linux контейнеры обычно используют ядро хоста, поэтому их граница отличается от границы отдельной виртуальной машины. Docker Desktop на macOS запускает контейнеры в виртуальной машине, но разрешённые общие каталоги и доступ к демону остаются существенны. [4] Документация Docker отдельно разбирает последствия этих доступов. [2]

Готовый контейнер, предоставленный отправителем задания, тоже содержит недоверенный код. Проверять нужно и способ его запуска: образ, параметры, тома, сеть, переменные среды. Он не становится доверенным только потому, что его удобно запускать одной командой.

Когда остановиться

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

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

Короткий ответ отправителю

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

Формулировка не обвиняет собеседника и не перечисляет случайные «страшные слова». Она устанавливает понятный порядок работы.

Как сообщить о подозрительном репозитории

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

Atlassian принимает сообщения о вредоносном содержимом Bitbucket через поддержку и адрес abuse@atlassian.com. В инструкции предлагается указать ссылку на материал и описание проблемы; отрицательный или неопределённый результат сканирования не препятствует сообщению. [3]

Не нужно публиковать секреты, персональные данные или весь архив только ради убедительности. Наличие eval без контекста — слабый отчёт. Небольшой фрагмент с доказанной цепочкой и аккуратным описанием значительно полезнее.

Задача: что спросить у «рекрутера»?

Вам пишут: «Сначала выполните все команды из README на своём основном компьютере. Виртуальную машину не используйте. Если редактор покажет предупреждение, разрешите всё — иначе тест не работает».

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

Показать разбор

Возможный ответ. «Какие конкретно разрешения нужны и каким шагам? Почему задание не работает в виртуальной машине? По какому результату вы будете оценивать выполнение? Я могу выполнить задание в одноразовой среде без личных данных и предоставить результат и журнал запуска».

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

Что стоит запомнить

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

Источники

[1] Unit 42: Hacking Employers and Seeking Employment — исследование Contagious Interview.

[2] Docker: Engine security.

[3] Atlassian: Report malware hosted on Bitbucket Cloud.

[4] Docker Desktop for Mac: разрешения и контейнеры внутри Linux VM.

Что выполняется при npm install: хуки, зависимости и границы ignore-scripts

Fri, 13 Nov 2026 00:00:00 +0300

«Я только поставил зависимости, приложение не запускал». Для JavaScript-проекта это важное уточнение, но ещё не ответ на вопрос об исполнении кода.

npm поддерживает скрипты жизненного цикла. В зависимости от команды, версии и типа пакета установка может вызвать preinstall, install, postinstall, prepare и связанные этапы. Такие скрипты встречаются в обычной разработке: например, для подготовки сборки. Их наличие требует проверки назначения, а не автоматического обвинения в распространении вредоносного кода. [1]

Где заканчивается «скачивание файлов»

Рассмотрим учебный фрагмент корневого package.json. Для этой цепочки и задачи в конце статьи используем npm 11 с разрешёнными скриптами жизненного цикла:

1
2
3
4
5
6
7


{
 "scripts": {
 "start": "node server/app.js",
 "postinstall": "npm start",
 "prepare": "node tools/build.js"
 }
}

Здесь postinstall вызывает команду запуска приложения. Чтобы понять риск, нужно прочитать server/app.js, затем проследить его импорты. Название tools/build.js тоже не гарантирует, что файл только собирает проект.

Важен весь путь:

1
2
3
4
5
6


установка с разрешёнными lifecycle scripts
 → postinstall
 → npm start
 → server/app.js
 → импорт модуля
 → действие на верхнем уровне этого модуля

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

Почему недостаточно корневого package.json

Проверка начинается с корневого файла, но продолжается в рабочих пакетах монорепозитория и зависимостях. Отдельного внимания требуют Git-зависимости и операции подготовки пакета: условия вызова prepare отличаются от простого запуска произвольного скрипта. Точную последовательность нужно сверять с документацией используемой версии npm. [1]

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

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

Что даёт `--ignore-scripts`

При установке этот параметр отключает выполнение скриптов из package.json. Но явная команда вроде npm start, npm test или npm run build запускает выбранный скрипт даже при действующем ignore-scripts; подавляются только сопутствующие pre/post-этапы. Это прямо описано в документации npm. [2]

Флаг одного вызова не становится постоянной настройкой: после npm ci --ignore-scripts отдельный npm start не наследует его. Если запрет не задан в конфигурации или окружении, вместе со start могут сработать и prestart/poststart.

Следовательно, сочетание «установил с --ignore-scripts, затем сразу запустил npm start» не сохраняет запрет на выполнение кода. Оно только переносит момент исполнения.

Для анализа известного снимка с согласованным lockfile в отдельной подготовленной среде возможна команда:

1

npm ci --ignore-scripts

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

OWASP рекомендует ограничивать установочные скрипты и проверять чужой проект до их разрешения. [3]

Почему lockfile не выдаёт сертификат безопасности

npm ci требует lockfile, проверяет согласованность с package.json и не обновляет его по ходу установки. Но команда не запрещает lifecycle scripts сама по себе. [4]

Фиксация версии и контроль целостности помогают установить, какие именно байты получены. Они не доказывают, что эти байты доброкачественны. Зафиксированная вредоносная версия воспроизводится не хуже обычной.

То же относится к результату проверки известных уязвимостей. npm audit запрашивает сведения об известных проблемах зависимостей; отсутствие отчёта не является экспертизой произвольного JavaScript, скрытого в файлах проекта. [5]

Разрешение скриптов как отдельное решение

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

При редакции в ноябре 2026 года документация npm 12 уже описывает политику allowScripts: установочные скрипты зависимостей без соответствующего разрешения пропускаются. Это важное отличие от прежних выпусков, но оно не отменяет проверку корневого проекта. Его собственные хуки при обычном локальном npm install обрабатываются отдельно и не становятся безопасными из-за запрета скриптов зависимостей. [6][7]

В этой статье мы намеренно ограничиваемся npm. У Yarn и pnpm есть собственные настройки и меняющееся между версиями поведение. Переносить один флаг и считать результат одинаковым без проверки документации не стоит.

Задача: что изменится в трёх запусках?

Файлы для самостоятельного разбора доступны в синтетическом практикуме.

Для фрагмента выше рассматриваются действия:

1
2
3


А. npm ci
Б. npm ci --ignore-scripts
В. npm ci --ignore-scripts, затем npm start

В упражнении предполагаются npm 11, согласованный lockfile, разрешённые политикой окружения lifecycle scripts и отсутствие дополнительных ограничений.

Показать разбор

Разбор. В А разрешена цепочка lifecycle scripts, поэтому postinstall может запустить приложение. В Б эта автоматическая цепочка подавлена. В В отдельная команда npm start всё же вызывает приложение. Ни один ответ не устанавливает, что именно приложение сделало: для этого нужно продолжить чтение и сопоставить его с журналами.

Что стоит запомнить

Установка, сборка и тестирование — разные команды, но каждая может стать точкой исполнения. Проверять нужно не название действия, а программу, до которой оно доводит управление.

Источники

[1] npm: Scripts — lifecycle events и условия prepare.

[2] npm: Config — ignore-scripts и другие параметры.

[3] OWASP: NPM Security Cheat Sheet.

[4] npm: npm ci.

[5] npm: npm audit.

[6] npm 12: управление разрешениями установочных скриптов зависимостей.

[7] npm CLI: реализация install и отдельный вызов root lifecycle scripts.

Установочное поведение следует проверять для фактической версии npm. Статья не переносит возможности нынешних выпусков на событие января 2026 года.

Шрифт, который оказался скриптом: проверяем формат и назначение файла

Fri, 13 Nov 2026 00:00:00 +0300

В конфигурации проекта обнаружена команда, передающая Node.js файл webfonts/preview.woff2. Название похоже на веб-шрифт. Но имя файла и его содержимое — разные источники сведений.

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

Расширение — подсказка, а не доказательство

У формата WOFF2 есть обязательная сигнатура: первые четыре байта должны быть 77 4f 46 32, то есть wOF2. Это требование спецификации. Если сигнатуры нет, файл не соответствует WOFF2. Обратное заключение неверно: наличие четырёх правильных байтов ещё не доказывает корректность всего шрифта и тем более его безопасность. [1]

Для первичного просмотра в подготовленной среде достаточно:

1
2


file -- webfonts/preview.woff2
xxd -g 1 -l 32 webfonts/preview.woff2

file помогает определить предполагаемый тип. xxd показывает сами байты, на которых можно проверить гипотезу. Не нужно передавать файл Node.js, открывать в просмотрщике шрифтов или запускать приложение.

Предположим, начало выглядит так:

1

00000000: 63 6f 6e 73 74 20 6d 61 72 6b 65 72 20 3d 20 22 const marker = "

Сигнатуры WOFF2 нет. Мы видим начало текстовой конструкции, похожей на JavaScript. Корректная промежуточная запись: «Файл с расширением .woff2 не соответствует обязательному заголовку WOFF2 и содержит текст, похожий на исходный код».

Здесь важно не перескочить сразу к слову «заражение». Можно столкнуться с ошибочно названным файлом, учебным примером или намеренной маскировкой. Назначение проясняется вместе с окружающим кодом.

Добавляем контекст запуска

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

Расширение .woff2 само по себе не запрещает такой запуск. Загрузчик CommonJS в Node.js может читать файл с неизвестным расширением как JavaScript. Но это не универсальное правило: стандартный загрузчик ES modules отвергает неизвестные расширения, а выбор загрузчика зависит, в частности, от type в ближайшем package.json и флагов запуска. Для конкретной команды нужно проверить режим и версию Node.js. Здесь важна попытка передать файл интерпретатору; успешность исполнения ещё предстоит установить. [3][4][5]

Следующий вопрос — что делает программа. Ищем обращения к сети, запись файлов, создание дочерних процессов и превращение полученных строк в код. Само слово require ничего не доказывает; интерес представляет связная последовательность действий.

В исходных рабочих записях этого цикла аналогичную роль играл файл webfonts/fa-brands-regular.woff2. Это описание маскировки JavaScript расширением шрифта, а не доказательство эксплуатации уязвимости в обработчике настоящих шрифтов. Различать эти механизмы необходимо: у них разные точки исполнения и способы проверки.

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

А что со «словарём»?

Файл .vscode/spellright.dict выглядит как вспомогательный словарь редактора. Но расширение .dict без указания конкретного формата не даёт такой же универсальной проверки, как заголовок WOFF2.

Здесь полезнее сопоставить предполагаемое назначение и содержимое. Список слов согласуется с ролью словаря. Сложный JavaScript, который устанавливает пакеты и запускает другой файл, — нет. Особенно значимо, если в задаче редактора прямо указан этот путь.

Не следует делать отдельным правилом «любой .dict подозрителен». Иначе проверка будет наказывать нормальную конфигурацию, не объясняя, где именно обнаружена опасность.

Почему похожая история не всегда подтверждает нашу

В одном из исследований Huntress WOFF2 использовался для подмены отображаемых символов: специально подобранные глифы превращали нечитаемую последовательность в правдоподобное имя файла на странице. Это другой приём. Он не доказывает, что в рассматриваемом здесь «шрифте» исполнялся JavaScript, и не связывает два случая с одной группой. [2]

Ссылка на исследование полезна лишь тогда, когда подтверждает именно сформулированный тезис. Общего слова WOFF2 недостаточно.

Ограничиваем просмотр неизвестных данных

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

1
2
3


python3 -I -S -c \
'import sys; f=open(sys.argv[1], "rb"); print(repr(f.read(256))); f.close()' \
webfonts/preview.woff2

Команда читает данные и печатает их представление; она не интерпретирует содержимое как JavaScript. Здесь предполагаются заранее подготовленные доверенные инструменты. Даже статический анализ неизвестных файлов разумно выполнять в отдельной среде с ограниченными ресурсами.

Задача: четыре байта и две гипотезы

Файлы для самостоятельного разбора доступны в синтетическом практикуме.

Даны два начала файлов:

1
2


A: 77 4f 46 32 00 01 00 00
B: 63 6f 6e 73 74 20 78 20

Для файла B дополнительно найдена задача, передающая его Node.js. Для файла A сведений об использовании нет.

Вопросы: какой файл прошёл проверку обязательной сигнатуры? Какой требует проверки назначения? Можно ли по этим данным объявить A безопасным, а B — уже исполненным вредоносом?

Показать разбор

Разбор. A прошёл только проверку первых четырёх байтов. B её не прошёл; начало читается как const x , а задача указывает предполагаемый путь исполнения. B требует дальнейшего анализа кода. О состоявшемся запуске эти данные не сообщают. Безопасность A также не установлена.

Что стоит запомнить

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

Источники

[1] W3C: WOFF File Format 2.0, раздел 3.2 — заголовок и сигнатура.

[2] Huntress: Gootloader и обфускация имён с помощью WOFF2.

[3] Node.js: CommonJS — обработка расширений файлов.

[4] Node.js: выбор загрузчика точки входа.

[5] Node.js: ES modules — разрешение и загрузка.

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

Форензика on CTF.MSK.RU

От HTTP-ответа к выполнению кода: читаем опасную цепочку в JavaScript

Что превращается в код

Как оформить доказательство

eval, Function и Function.constructor

Деталь API может изменить вывод

Что делать с находкой

Задача: исполнение или только подготовка?

Источники

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

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

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

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

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

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

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

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

Источники

Проверка репозитория до запуска: как устроить безопасный статический контроль

Кто управляет проверкой?

Три слоя проверки

Простой поиск: полезный, но ограниченный

Что делать с результатом

Задача: проверьте проверяющего

Что стоит запомнить

Источники

Репозиторий как ловушка: от настроек VS Code к запуску кода

С чего начинается проверка

Читаем задачу как программу

Три разных вопроса вместо одного

Как осматривать внешний проект

Задача: какой вывод выдерживает проверку?

Что стоит запомнить

Источники

Следы в сети: как связать процесс, запрос и файл — и не додумать лишнего

Что сообщает каждый источник

Собираем цепочку

Учебный журнал

Как использовать индикаторы

MITRE ATT&CK описывает действия, а не заменяет доказательства

Задача: уберите лишнее из заключения

Завершение цикла

Источники

Тестовое задание на отдельной машине: порядок приёма внешнего кода

Проверяем связь, а не впечатление

До запуска нужно определить условия

Изоляция определяется доступами

Когда остановиться

Короткий ответ отправителю

Как сообщить о подозрительном репозитории

Задача: что спросить у «рекрутера»?

Что стоит запомнить

Источники

Что выполняется при npm install: хуки, зависимости и границы ignore-scripts

Где заканчивается «скачивание файлов»

Почему недостаточно корневого package.json

Что даёт --ignore-scripts

Почему lockfile не выдаёт сертификат безопасности

Разрешение скриптов как отдельное решение

Задача: что изменится в трёх запусках?

Что стоит запомнить

Источники

Шрифт, который оказался скриптом: проверяем формат и назначение файла

Расширение — подсказка, а не доказательство

Добавляем контекст запуска

А что со «словарём»?

Почему похожая история не всегда подтверждает нашу

Ограничиваем просмотр неизвестных данных

Задача: четыре байта и две гипотезы

Что стоит запомнить

Источники

`eval`, `Function` и `Function.constructor`

Что даёт `--ignore-scripts`