Анализ подозрительного JS-файла в браузерной песочнице: пошаговый разбор

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

Зачем вообще анализировать JS-файлы

JavaScript — это исполняемый код, который работает прямо в браузере. Теоретически он ограничен песочницей браузера, но на практике вредоносный скрипт может:

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

Поэтому анализ JS — это не академическое упражнение, а рабочая задача. И главный принцип: никогда не запускайте незнакомый скрипт там, где вам жалко данные.

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

Есть два принципиально разных способа разобраться в JS-файле:

• Статический анализ — читаем код без запуска, ищем подозрительные паттерны, структуры, вызовы.
• Динамический анализ — запускаем в изолированной среде и смотрим, что он реально делает во время выполнения.

Статический — быстрее и безопаснее, но хуже работает с обфусцированным (запутанным) кодом. Динамический — показывает реальное поведение, но требует подготовки изолированной среды.

Когда какой подход выбирать

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

Этап 1: Быстрый статический осмотр

Первое, что делаем — открываем файл в любом текстовом редакторе. Не в браузере, не двойным кликом — в редакторе кода. VS Code, Notepad++, даже блокнот подойдут для начала.

Что ищем глазами

1. Строки, похожие на URL — ищем что-то вроде http://, https://, /api/, xmlhttprequest. Если скрипт куда-то отправляет данные — это первое, что бросится в глаза.
2. Обращение к localStorage и sessionStorage — нормальные скрипты иногда используют хранилище, но если файл претендует на аналитику или виджет, а пишет в storage ключи со странными именами — это красный флаг.
3. Доступ к document.cookie — явный признак, что скрипт пытается вытащить куки. Для аналитических скриптов это не обязательно, а для вредоносных — типично.
4. eval, Function(), setTimeout/setInterval с текстовым аргументом — всё это способы выполнить код, который хранится в строке. Часто используются, чтобы скрыть реальные действия от визуального осмотра.
5. PostMessage — если скрипт что-то передаёт через window.postMessage, значит он пытается общаться с другими окнами или iframe на странице.

Если код обфусцирован

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

Этап 2: Настройка безопасной среды

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

Три варианта песочницы

Минимальная безопасная конфигурация

Что обязательно нужно сделать перед запуском подозрительного JS:

• Отключите сеть или переведите ВМ в изолированный режим (Host-Only или вообще без адаптера). Если скрипт не может отправлять данные наружу — его вредоносность сильно ограничена.
• Никаких ваших данных — заведите отдельный чистый браузер или чистый профиль, без сохранённых паролей, кук, расширений.
• Установите расширения для отслеживания — NoScript, uBlock Origin в режиме полного запрета скриптов, инструменты разработчика (Chrome DevTools / Firefox Developer Tools) с открытой вкладкой Network.
• Подготовьте систему мониторинга — если ВМ позволяет сеть (вы решили включить для наблюдения за запросами), запустите Wireshark или Fiddler для перехвата трафика.

Этап 3: Динамический анализ с помощью DevTools

Это основной рабочий инструмент при анализе JS в браузере. Открываем Developer Tools (F12) и работаем по шагам.

Шаг 1: Вкладка Network — что скрипт отправляет наружу

1. Откройте вкладку Network (Сеть).
2. Поставьте галочку «Preserve log» — чтобы запросы не терялись при переходе между страницами.
3. Отфильтруйте по типу запросов: XHR, Fetch, WebSocket — именно здесь обычно прячется отправка данных.
4. Загрузите или выполните подозрительный JS-файл на тестовой странице.
5. Наблюдайте за всеми исходящими запросами.

На что смотреть:

• Запросы на незнакомые домены, особенно с подозрительными именами вроде tracker-xyz123.top или data-collector.icu.
• Размер отправляемых данных — если скрипт отправляет килобайт данных из пустой формы, значит он собирает что-то с самой страницы.
• WebSocket-соединения — их сложнее заметить, но они позволяют постоянно сливать данные.

Шаг 2: Вкладка Sources — пошаговое выполнение

1. Откройте вкладку Sources, найдите загруженный скрипт в дереве файлов.
2. Поставьте точки останова (breakpoints) на ключевых строках — обращения к cookie, localStorage, отправка запросов, обработчики событий.
3. Используйте пошаговое выполнение (F10 — step over, F11 — step into), чтобы пройти через логику скрипта.
4. В панели Watch отслеживайте значения переменных — что скрипт сохраняет, что передаёт.

Шаг 3: Вкладка Console — что скрипт выводит

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

Этап 4: Специализированные инструменты

Ручной анализ через DevTools — это хорошо, но есть инструменты, которые автоматизируют часть работы и дают дополнительную информацию.

• Browserling — онлайн-песочница, где можно запустить браузер в виртуальной машине через сеть. Удобно для быстрого теста без настройки своей ВМ.
• Any.Run — интерактивная песочница для анализа вредоносного ПО и скриптов. Показывает сетевые запросы, изменения в системе, запущенные процессы. Бесплатная версия позволяет запускать на несколько минут.
• Hybrid Analysis (hybrid-analysis.com) — загружаете файл, получаете отчёт о поведении в песочнице. Показывает, какие домены скрипт пытается достучаться, какие API вызывает.
• Box.js — Node.js песочница, которая перехватывает вызовы API JavaScript-движка. Удобна, когда вы хотите проанализировать сетевую активность скрипта без реального браузера.
• JSDetox — специализированный инструмент для анализа вредоносного JavaScript, позволяет отслеживать взаимодействие скрипта с DOM.

Этап 5: Декодирование и деобфускация

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

Типичные методы обфускации и что с ними делать:

• Hex/Base64-строки — \x68\x65\x6C\x6C\x6F или aGVsbG8=. Просто прогоняйте через консоль: console.log(decodeURIComponent(escape(atob('aGVsbG8='))).
• String array rotation — массив строк и функция, которая по индексам собирает нужный текст. Найдите этот массив и функцию, пропишите значения вручную или запустите в безопасной консоли для получения расшифрованных строк.
• eval() и new Function() — скрипт собирает код из строк и запускает. Замените eval на console.log или присваивайте результат в переменную вместо выполнения — так вы увидите, что он попытался сделать, не запуская это.

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

Красные флаги: что сразу выдаёт вредоносный скрипт

Вот список признаков, которые при статическом осмотре должны насторожить:

• Scoping-функции с минимумом логики, но максимумом строк — обычно это признак самораспаковывающегося кода.
• Множественные слои eval() один внутри другого.
• Доступ к document.cookie в скрипте, который по описанию не имеет отношения к авторизации.
• Отправка данных через POST с сериализованным содержимым всей формы.
• Код, который перехватывает нажатия клавиш (keylogger) — document.addEventListener('keydown', ...).
• Динамическая загрузка дополнительных скриптов с внешних ресурсов.
• Перехват отправки форм (form.addEventListener('submit', ...)) с модификацией данных.

Один признак — ещё не приговор. Но если вы видите три и более из списка — скрипт с высокой вероятностью вредоносный.

Частые ошибки при анализе

1. Запуск скрипта на рабочей машине. Даже если «просто посмотреть». Скрипт может успеть отправить данные, пока вы думаете, что безопасны.
2. Анализ в том же браузере, где вы залогинены. Скрипт может делать запросы с вашими куками. Используйте чистый профиль без авторизаций.
3. Пропуск динамической подгрузки. Скрипт может сам не содержать вредоносный код, а только загружать его с внешних ресурсов. Если отключить сеть и скрипт выглядит безобидно — это не значит, что он безопасен.
4. Доверие к домену. Даже если скрипт шлёт данные на знакомый домен — убедитесь, что этот домен действительно принадлежит ожидаемому сервису. Подмена домена — простая и эффективная техника.
5. Игнорирование контекста. Один и тот же код может быть легитимной аналитикой и вредоним скриптом в зависимости от того, кто его запускает и на какой странице.

Как документировать результаты анализа

Если вы анализируете скрипт не для себя — например, для отчёта или передачи коллегам — зафиксируйте:

• Что именно делает скрипт (какие данные читает, куда отправляет, какие элементы создаёт на странице).
• Подозрительные домены и IP-адреса, на которые скрипт делает запросы.
• Методы обфускации, если они использовались.
• Скриншоты из DevTools — Network с запросами, Console с выводом, критические строки кода.
• Вердикт: вредоносный, подозрительный, легитимный (с обоснованием).

Итоговый алгоритм действий

Когда перед вами встаёт задача проверить подозрительный JS-файл, действуйте так:

1. Откройте файл в текстовом редакторе, выполните быстрый визуальный осмотр на наличие красных флагов.
2. Если код читаемый — проанализируйте ключевые вызовы (сеть, хранилище, DOM) без запуска.
3. Если код обфусцирован — загрузите в онлайн-песочницу (Any.Run, Hybrid Analysis) и проанализируйте поведение в динамике.
4. Для глубокого анализа используйте виртуальную машину с чистым браузером и DevTools. Откройте вкладку Network, отслеживайте все запросы, поставьте breakpoints на подозрительных участках.
5. Проверьте, не загружает ли скрипт дополнительные ресурсы с внешних источников.
6. Задокументируйте результаты и примите решение: блокировать, удалить, пропустить.

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