Разбор подозрительного .js-файла: Гайд по анализу в песочнице

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

Вот где на сцену выходит песочница (sandbox). Это не просто «запустить и посмотреть». Это наблюдение за поведением программы в изолированной среде, когда она думает, что живет в реальной системе или браузере. В этой статье мы разберем, как правильно провести такой анализ, на что смотреть при выполнении JavaScript-файла и как отличить безобидный скрипт от вредоносного, не сломая при этом свой компьютер.

Зачем вообще нужна песочница для JS?

JavaScript стал языком не только для веба. Благодаря Node.js он работает и на серверах, и на десктопах. Злоумышленники это поняли давно. Они пишут вирусы, которые при запуске могут подключаться к C2-серверам, шифровать файлы или подменять содержимое буфера обмена.

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

Песочница позволяет:

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

Подготовка: Выбор инструментария

Прежде чем запустить что-либо, нужно выбрать правильную «лабораторию». Не все песочницы одинаково полезны. Всё зависит от того, что именно вы анализируете: браузерный скрипт или серверный (Node.js).

Если это Node.js скрипт

Здесь всё сложнее, так как у скрипта есть доступ к файловой системе. Вам нужна изолированная среда Node.js. Можно использовать Docker-контейнеры, предварительно настроенные с урезанными правами, или специализированные инструменты вроде JSandbox (если вы разработчик) и готовые VM-образы с установленным Node.js.

Если это браузерный скрипт

Для чистого JS, который работает в браузере, подойдут браузерные песочницы (например, JSFiddle, CodePen), но они часто блокируют сетевые запросы, что мешает увидеть вредоносную активность. Лучше использовать локальную виртуальную машину с браузером, где настроен перехват трафика.

Инструменты мониторинга

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

Инструмент	Для чего нужен	Плюсы	Минусы
Wireshark	Анализ сетевого трафика	Показывает каждый пакет, идущий в сеть. Видно, куда именно обращается скрипт.	Сложный интерфейс, много мусора от других программ.
Browser DevTools (F12)	Отладка кода и консоль	Встроено в браузер. Позволяет ставить точки останова (breakpoints) и смотреть переменные.	Работает только внутри браузера, не видит системных вызовов.
Process Monitor (ProcMon)	Мониторинг файлов и реестра	Показывает все попытки доступа к файлам и изменения в реестре Windows.	Требует прав администратора, генерирует много событий.
Hooking-framework (например, Frida)	Динамический анализ	Позволяет подменять функции на лету, расшифровывать строки в памяти.	Высокий порог входа, требует знаний программирования.

Пошаговый алгоритм анализа поведения

Допустим, у вас есть файл malicious_script.js. Вы не знаете, что он делает. Вот как я провожу разбор, чтобы понять, что внутри.

Шаг 1. Подготовка среды (Снимок)

Никогда не запускайте сомнительный код на чистой ОС без возможности отката. Создайте снапшот (снимок состояния) виртуальной машины. Это «точка сохранения» в играх. Если скрипт сломает систему или зашифрует диск, вы сможете мгновенно вернуть всё как было.

Установите на VM базовый набор программ: браузер, Node.js, Wireshark и блокнот. Отключите общий доступ к файлам между хостом и гостевой ОС, чтобы вредоносное ПО не ушло на ваш основной компьютер.

Шаг 2. Первичный запуск без отладки

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

Что мы ищем:

• Появились ли новые процессы в диспетчере задач?
• Загружается ли сеть (Wireshark покажет исходящие соединения)?
• Изменятся ли файлы в папке (появятся новые или старые станут недоступны)?
• Не появился ли новый ярлык на рабочем столе?

Если скрипт молчит — это тоже ответ. Возможно, он ждет какого-то условия (время, наличие конкретного файла, URL-адрес).

Шаг 3. Аналитика сети (Network Forensics)

Самый важный этап. Если скрипт делает что-то плохое, он почти наверняка должен передать данные куда-то или скачать полезную нагрузку. Откройте Wireshark и запустите фильтр http.request или dns.

Посмотрите на домены. Если вы видите запрос к странному адресу вроде 192.168.x.x (локальная сеть) — это попытка сканирования сети. Если запрос идет к домену, созданному вчера — это красный флаг.

Обратите внимание на User-Agent. Если скрипт отправляет запрос с надписью «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36», но при этом в заголовках есть подозрительные поля — это признак того, что скрипт пытается скрыть свою природу, притворяясь обычным браузером.

Шаг 4. Динамический разбор кода (Debugging)

Если скрипт не делает ничего заметного сразу, переходим к отладке. Открываем код в редакторе или браузере (если он запускается там). Ставим точки останова (breakpoints) в ключевых местах:

1. При создании объектов: new XMLHttpRequest, fetch(), new ActiveXObject. Это индикаторы попыток связи с сетью или запуска системных команд.
2. При работе с файловой системой: Методы fs.writeFile, fs.appendFile (в Node.js).
3. При выполнении кода: Функции eval() и Function(). Злоумышленники часто используют их, чтобы собрать код из кусочков строк и выполнить его.

Когда скрипт останавливается на точке, смотрите на стек вызовов (Call Stack). Откуда пришла инструкция? Если вы видите длинную цепочку вызовов, ведущую к eval, скорее всего, вы напали на след обфусцированного вредоносного модуля.

Шаг 5. Обход защиты от песочницы

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

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

• Убедитесь, что у вас подключена мышь и курсор двигается (можно использовать утилиты для авто-движения).
• Проверьте, что на диске есть файлы, похожие на пользовательские (документы, картинки).
• Измените Hosts-файл или используйте прокси, чтобы скрипт думал, что он в рабочей сети.
• Используйте инструменты, которые маскируют наличие виртуальной машины (например, VMProtect или специализированные настройки VMware/VirtualBox).

Типичные сценарии поведения: Что вы увидите?

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

Сценарий 1: Криптоджекинг (Cryptojacking)

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

Решение: Блокировка доменов пулов в файле hosts или на уровне фаервола.

Сценарий 2: Вредоносное расширение

Скрипт пытается внедриться в браузер. Он ищет пути к профилям Chrome или Firefox и модифицирует файл preferences.json или manifest.json. В сетевом трафике может быть запрос к серверу, который отдаст список сайтов для кражи данных.

Решение: Сброс настроек браузера, проверка списка установленных расширений.

Сценарий 3: Редирект и фишинг

Скрипт просто меняет настройки прокси или открывает новые вкладки с поддельными страницами входа (например, копия Google или Facebook). В консоли видно выполнение window.location = 'http://fake-site.com'.

Решение: Проверка списка закладок, очистка куки, смена паролей.

Сценарий 4: Шифровальщик (Ransomware)

Самый опасный вариант. Скрипт сканирует папки с документами, ищет файлы по расширениям (.docx, .pdf, .jpg) и начинает их шифровать. В логах ProcMon вы увидите массовое создание зашифрованных копий и удаление оригиналов.

Решение: Немедленно остановить процесс (Kill Process). Восстановление возможно только из бэкапа, если нет ключа шифрования.

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

Даже опытные аналитики иногда допускают ошибки. Вот чего стоит избегать, чтобы не получить ложные результаты или не заразить себя.

Ошибка 1: Запуск на чистой системе без снапшота.
Это классика. Вы запускаете скрипт, он делает «бэкап» реестра и перезагружает систему. Вы теряете время на переустановку. Всегда делайте снапшот перед запуском.

Ошибка 2: Игнорирование статического анализа.
Хотя песочница — это динамический анализ, не стоит сразу запускать файл «как есть». Посмотрите на структуру. Если файл весит 5 Мб и это один текстовый файл — это подозрительно (обычно это обфусцированный текст). Если внутри есть бинарные данные — он может содержать эксплойты. Используйте утилиты типа strings, чтобы вытащить из файла читаемые строки. Часто там встречаются домены, IP-адреса или пути к файлам, которые экономит время на запуск.

Ошибка 3: Недооценка «спящих» угроз.
Некоторые скрипты запрограммированы запускаться только в определенное время или при наличии определенных условий. Если вы запустили файл и он «спит», это не значит, что он безопасен. Он может ждать запуска в 18:00 или появления файла invoice.pdf.

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

Как выбрать стратегию анализа: Сценарии

В зависимости от вашей ситуации, подход может меняться. Вот краткий гид:

Ситуация А: Вы обычный пользователь, скачал файл «на всякий случай».
Вам не нужны сложные инструменты. Загрузите файл в онлайн-песочницу, например, Hybrid Analysis или Any.Run. Они сами выполнят скрипт в облаке и выдадут отчет. Если отчет чистый — файл безопасен. Если красный — удаляйте. Не запускайте его локально.

Ситуация Б: Вы веб-разработчик, получили код от фрилансера.
Вам нужно понять, не внедрена ли бэкдор-логика. Проведите статический анализ в IDE, используя плагин ESLint с правилами безопасности (например, eslint-plugin-security). Проверьте, нет ли там вызовов eval() или child_process.exec. Если код сложный — запустите его в локальном Docker-контейнере с отключенным интернетом и посмотрите, не пытается ли он выйти в сеть.

Ситуация В: Вы специалист по безопасности (SOC/IR).
Вам нужно собрать IOCs (индикаторы компрометации). Используйте полную песочницу с мониторингом сетевых пакетов, файловой системы и реестра. Настройте правила для выгрузки PCAP-файлов. Вам нужны хеши, IP-адреса и домены для блокировки в корпоративном периметре.

Практические рекомендации и подводные камни

Анализ поведения — это не всегда линейный процесс. Иногда скрипт ведет себя сложно. Вот несколько советов, которые я вынес из практики:

• Используйте прокси. Настройте в песочнице прокси-сервер (например, Burp Suite или Fiddler). Это позволит вам перехватывать HTTPS-трафик. Без расшифровки SSL/TLS вы увидите только зашифрованные пакеты, в которых может быть спрятана важная информация.
• Следите за временными интервалами. Вредоносный код часто использует таймеры (setTimeout, setInterval). Скрипт может ждать 5 минут, чтобы вы подумали, что он безопасен, и только потом начать действовать. В песочнице можно ускорить время, но это может сломать логику некоторых скриптов (например, проверки времени). Лучше просто ждать или использовать инструменты, которые позволяют «разбудить» таймеры.
• Проверяйте зависимости. Скрипт может быть безвредным сам по себе, но пытаться скачать и запустить вредоносный модуль из интернета. Если вы видите запрос к внешнему домену, попробуйте заблокировать его в файле hosts песочницы. Если скрипт зависнет или выдаст ошибку — значит, он ждал именно этот модуль.
• Обратите внимание на шрифты и графику. Некоторые скрипты используют canvas для отрисовки скрытой графики. Это может быть استеграфика (скрытие данных в картинке). Если скрипт использует canvas или webgl, проверьте, что именно он рисует.

Что делать, если скрипт не запускается?

Иногда скрипт выдает ошибку. Это не всегда значит, что он безопасен. Возможно, ему не хватает библиотеки или он сработал на защите. Попробуйте установить недостающие зависимости или пропустить проверку. Но если он просто падает без ошибок и ничего не делает — скорее всего, это «мертвый» код или он требует специфических условий.

Итог: Как действовать дальше?

Анализ поведения подозрительного .js-файла в песочнице — это не магия, а методичная работа. Вы не ищете «вируса», вы ищете «поведения». Если скрипт пытается выйти в сеть — это подозрительно. Если он меняет файлы — это опасно. Если он просто считает число Пи — скорее всего, это безобидно.

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

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

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