Как анализировать подозрительный .js-файл в браузерной песочнице — пошаговое руководство для тех, кто не хочет заразить сайт

Как анализировать подозрительный .js-файл в браузерной песочнице — пошаговое руководство для тех, кто не хочет заразить сайт

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

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

Почему именно браузерная песочница?

Многие думают: «Зачем усложнять? Я просто открою его в Notepad++ и посмотрю». Проблема в том, что вредоносные скрипты не пишутся как читаемый код. Они запутаны, сжаты, закодированы, переписаны через несколько слоёв шифрования. Даже если вы увидите строку eval(atob("...")) — это не значит, что вы поняли, что происходит. Это как прочитать «нажми кнопку» на языке, которого не знаете.

Песочница — это как лаборатория для вирусов. Она даёт скрипту всё, что ему нужно: доступ к DOM, к сетевым запросам, к локальному хранилищу — но всё это происходит в изолированной среде. Если скрипт попытается загрузить вредоносный код с внешнего сервера, вы это увидите. Если он попытается украсть cookies — вы это заметите. Если он начнёт создавать скрытые iframe с фишингом — вы это поймаете. И всё это без риска для вашей машины.

Как выбрать песочницу: три варианта, которые реально работают

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

Если вы новичок — начните с Any.Run. Если вы работаете с большим количеством файлов — настройте JSFiddle с DevTools. Не используйте «песочницы» вроде CodePen или Replit — они слишком защищены, и скрипт может просто не запуститься, не показав ничего полезного.

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

Вот как я действую, когда беру подозрительный .js-файл:

1. Откройте песочницу — например, Any.Run. Загрузите файл. Не копируйте код вручную — загружайте как файл. Это важно: если скрипт проверяет, откуда он загружен, ручной ввод может его обмануть.
2. Запустите и ждите 10–15 секунд. Не торопитесь. Многие скрипты спят 5–10 секунд перед тем, как начать действовать. Это чтобы обойти автоматические системы.
3. Смотрите в раздел «Network». Что делает скрипт? Запрашивает ли он что-то с неизвестного домена? Например, hxxp://a1b2c3d4[.]xyz/track.js — это красный флаг. Домены с цифрами и случайными буквами — почти всегда вредоносные.
4. Проверьте «DOM». Появился ли новый iframe? Скрытый элемент с текстом? Ссылка на фишинговый сайт? Иногда скрипт просто вставляет <iframe src="https://fake-bank-login[.]com"> — и вы это видите в дереве элементов.
5. Смотрите на «Processes» или «Memory». Если скрипт создаёт 3–5 новых процессов или резко увеличивает использование памяти — это не нормально. Это может быть майнер, или он пытается загрузить бинарник через WebAssembly.
6. Проверьте «Files». Создал ли скрипт временные файлы? Загрузил ли что-то в localStorage или IndexedDB? Если да — это может быть кража данных или бэкдор.

Если вы используете JSFiddle — откройте DevTools (F12), перейдите на вкладку «Network», включите «Preserve log», запустите скрипт и смотрите, какие запросы появляются. Если видите POST на api.datacollector[.]ru — это не просто «аналитика». Это сбор данных. И если в теле запроса есть document.cookie — это кража сессии.

Что искать: 5 признаков вредоносного скрипта

Не все подозрительные скрипты выглядят как «вирусы». Вот что я ищу, когда анализирую:

• eval(), Function(), new Function() — если вы видите это в коде, почти 90% шансов, что там скрыт вредоносный код. Это основной способ обфускации.
• atob() + btoa() — если строка выглядит как набор случайных символов, а потом она передаётся в atob() — это декодирование. Часто используется, чтобы спрятать URL или ключи.
• document.write() — в 2024 году это почти всегда признак вредоносного действия. Современные сайты не используют это. Если он вставляет скрипт динамически — это попытка внедрить что-то в страницу.
• XMLHttpRequest или fetch() на подозрительные домены — особенно если домен не связан с вашим сайтом. Проверяйте, какие заголовки отправляются. Если есть Authorization или Cookie — это кража сессии.
• setTimeout() с очень большим интервалом — например, 300 000 мс (5 минут). Это не «задержка». Это попытка обойти автоматические системы анализа. Скрипт ждёт, пока вы закроете инструменты, а потом начинает действовать.

Пример: я однажды получил файл, который выглядел как «аналитика Google». В нём было 12 строк. Потом я запустил его в Any.Run — и обнаружил, что через 3 минуты он создал скрытый iframe, загрузил фишинговую форму с домена secure-login-bank[.]xyz, и отправил все cookies на http://[.]api-data[.]ru/collect. Ни один человек не увидел бы это, просто посмотрев на код. Только песочница показала реальное поведение.

Частые ошибки — и как их избежать

Вот что делают новички — и почему это опасно:

• Копируют код в консоль браузера. Это как зажигать спичку в гараже с бензином. Даже если вы не нажали Enter — браузер может частично выполнить код.
• Проверяют только на своей машине. Если скрипт не запускается — вы думаете, что он безвредный. Нет. Он может работать только в определённой среде — например, только если на компьютере установлен Chrome 118.
• Игнорируют сетевые запросы. Думают: «Ага, вижу eval() — значит, вредоносный». Но если он не делает ни одного HTTP-запроса — он просто бесполезен. А если он делает запрос — это уже угроза.
• Не проверяют динамические изменения. Скрипт может ничего не делать в первые 10 секунд. Если вы закрыли анализ через 5 — вы ничего не увидите.
• Доверяют «обфускаторам». Есть сервисы, которые «деобфусцируют» JS. Они работают — но не всегда. Некоторые скрипты проверяют, запущены ли они в таком сервисе, и ведут себя иначе.

Моя правило: если вы не видите сетевой запрос, DOM-изменение или файл — значит, вы не видите всё. Проверяйте минимум 15 секунд. И не полагайтесь на «обфускаторы» — они дают ложное ощущение безопасности.

Что делать в зависимости от ситуации

Вот как я решаю, что делать, в зависимости от того, что нашёл:

• Скрипт делает запрос на домен, который я не знаю, но ничего не крадёт — блокирую домен на уровне фаервола или хостов. Не удаляю файл — сохраняю как образец для анализа.
• Скрипт крадёт cookies или localStorage — немедленно удаляю его с сайта. Проверяю, не был ли он загружен на другие страницы. Сбрасываю все сессии пользователей. Уведомляю команду безопасности.
• Скрипт создаёт iframe с фишингом — проверяю, как он попал на сайт. Возможно, это уязвимость в CMS. Настраиваю WAF (веб-брандмауэр) на блокировку подобных скриптов.
• Скрипт использует WebAssembly для майнинга — удаляю его, проверяю, не запущен ли он на других сайтах. Устанавливаю ограничение на использование WebAssembly в настройках сервера.
• Скрипт ничего не делает — просто пустой или с ошибкой — сохраняю. Может быть, это тестовый файл, или попытка внедрения, которая не сработала. Но он остался — значит, кто-то его загрузил. Это сигнал: у вас есть уязвимость в загрузке файлов.

Если вы админ сайта — не просто удаляйте файл. Найдите, как он попал туда. Часто это: устаревший плагин, слабый пароль к FTP, или уязвимость в WordPress. Без этого — он вернётся.

Как лучше делать: мои рекомендации

Вот что я делаю регулярно — и это работает:

• Все .js-файлы, которые приходят извне (от клиентов, партнёров, из сторонних сервисов) — анализирую в Any.Run до загрузки на сайт.
• На сервере настраиваю скрипт, который автоматически проверяет все новые .js-файлы через Any.Run API (есть бесплатный тариф на 10 анализов в день).
• Если файл пришёл от клиента — прошу его предоставить исходник без обфускации. Если отказывается — не принимаю. Это не «недоверие» — это стандарт.
• Все скрипты, которые я не могу объяснить — удаляю. Не пытаясь «починить». Лучше переписать с нуля, чем тащить чужой код.
• Если скрипт пришёл в письме — не открывайте его. Передайте его в ИБ-отдел. Это не ваша задача — это задача команды безопасности.

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

Итог: что делать прямо сейчас

Если вы держите подозрительный .js-файл в руках — сделайте следующее:

1. Не открывайте его в блокноте, не копируйте в консоль, не запускайте на своей машине.
2. Зайдите на Any.Run (бесплатно, без регистрации).
3. Загрузите файл — не копируйте код.
4. Запустите анализ. Ждите 15 секунд.
5. Проверьте: есть ли сетевые запросы? Есть ли изменения в DOM? Создаются ли файлы?
6. Если что-то подозрительное — удалите файл. Уведомите команду. Заблокируйте домен.
7. Если ничего не происходит — всё равно удалите. Не храните подозрительные файлы. Они — потенциальный вектор атаки.

Это не «дополнительная мера безопасности». Это базовый уровень защиты. Если вы работаете с веб-сайтами — вы несёте ответственность за то, что на них запускается. И если вы не проверяете .js-файлы — вы просто играете в рулетку.

Один раз вы сделаете это — и больше не будете паниковать, когда кто-то присылает «обновление скрипта». Вы будете знать, как проверить. И это даст вам не только спокойствие — но и реальную защиту.

Информация в этой статье носит ознакомительный характер. Анализ вредоносного кода требует опыта и понимания рисков. Если вы не уверены — обратитесь к специалисту по кибербезопасности.