Что такое песочница и как она работает: внутренняя кухня автоматического анализа
Песочница — это виртуальная среда, имитирующая реальную операционную систему. В песочнице можно безопасно запускать и анализировать вредоносное ПО (ВПО), открывать подозрительные URL, не причиняя вреда основной системе. Этот инструмент может собирать данные о сетевом трафике, системных вызовах и изменениях файлов, которые позволяют определить поведение вредоносного ПО, выявить признаки компрометации и определить потенциальное воздействие на реальную систему.
Чтобы обнаружить вредоносное ПО, многие организации используют классические антивирусы. Но их работа часто ограничена методами статического анализа с использованием сигнатур или статической эвристики. Такой подход эффективен против известных вредоносных программ и частично — против их вариаций. Но бессилен против угроз, использующих 0‑day‑уязвимости, или APT‑атак, которые, как правило, до инцидента не встречались исследователям и не анализировались в антивирусных лабораториях. Песочница видит аномальное поведение, даже если файл не был детектирован ни одним вендором, что делает ее эффективной защитой именно против неизвестных угроз.
Принцип работы
Базовый принцип песочницы — поведенческий анализ. Образец запускается в изолированной среде, все действия логируются, а по окончании анализа проверяется, есть ли в логах типичные вредоносные паттерны поведения.
Песочницы различаются по степени эмуляции:
- Использующие виртуальные машины (VM). Эмулируют ОС конечного пользователя. Это самый распространенный тип, но он уязвим к техникам обнаружения и обхода песочниц (sandbox evasion).
- Основанные на полной эмуляции системы. Имитируют физическое оборудование и ОС хост‑системы. Этот тип сложнее в реализации, зато менее уязвим к техникам обнаружения и обхода.
Песочницы должны предоставлять возможность анализа всех основных форматов файлов: документов, скриптов, архивов, драйверов, исполняемых файлов и URL‑адресов.
Однако главная сложность в работе с песочницами заключается в определении критериев вредоносности. Необходимо понять, какое поведение в виртуальной среде считать нормальным, а какое — вредоносным.
Решение заключается в поиске баланса между двумя полярными задачами:
- Максимальная детализация. Песочница должна фиксировать с высокой точностью, вплоть до уровня вызовов функций, каждое взаимодействие между подозрительными файлами или URL‑адресами и системной средой. Это важно, поскольку при реагировании на инциденты, цифровой криминалистике и поиске угроз требуется очень высокий уровень детализации отчета.
- Фильтрация шума. Отчеты песочниц содержат много ненужного шума, например легитимных обращений к DNS, системных вызовов легитимных библиотек или штатных обновлений ПО. Это размывает и скрывает важную информацию, на которую опираются аналитики, когда реагируют на инциденты и принимают меры по устранению последствий.
Для поиска баланса используются ML‑ и LLM‑алгоритмы, позволяющие выявлять закономерности в поведении вредоносных программ. Например, метод машинного обучения позволяет обнаруживать незначительные изменения в сетевом трафике или системных вызовах, которые могут указывать на присутствие нового типа вредоносного ПО.
Однако полностью перекладывать на ML задачи по классификации вредоносного поведения пока рано. Алгоритмы часто дают ложные срабатывания на нестандартном, но легитимном софте, поэтому им требуется качественное обучение и разметка данных.
Роль песочниц в работе аналитика SOC
Песочница дает аналитику доказательную базу для принятия решений. Специалисты SOC могут быстро проанализировать отчет песочниц и определить, какую угрозу представляет ВПО для их организации, а также выработать соответствующие меры по реагированию.
Если гипотеза о вредоносности файла подтвердится, аналитик сразу получает отчет с перечнем IoC. На основе этих данных он может изолировать зараженный хост, заблокировать вредоносные IP‑адреса или доменные имена.
Кроме того, использование песочниц позволяет организациям извлекать уроки из прошлых инцидентов и совершенствовать защиту от будущих атак. Например, написать новые правила для выявления аналогичных атак на ранних этапах.
Песочница помогает обнаружить недочеты в существующей защите. Например, вредоносное почтовое вложение проходит через почтовый шлюз, антивирус на рабочей станции не обнаруживает его из‑за обфускации, а злоумышленник использует легитимный процесс для внедрения кода (code injection). Проанализировав такую атаку в песочнице, аналитик может разработать меры по предотвращению аналогичных инцидентов: создать новые правила корреляции, внедрить EDR или скорректировать политики запуска скриптов.
Три основных способа, как аналитики используют песочницы:
- Триаж. Чаще применяют аналитики L1, чтобы выяснить, вредоносный файл или нет, то есть подтвердить или опровергнуть гипотезу о вредоносности. А также понять, требуется ли эскалация или повышение приоритета инцидента.
- Глубокий анализ. Более актуально для аналитиков L2 и L3, которые изучают поведение вредоносного ПО, идентифицируют C2‑коммуникации, проводят начальный реверс‑инжиниринг, пишут корреляционные правила и сигнатуры.
- Threat intelligence. TI‑специалисты на основе отчетов песочниц собирают IoC (IP‑адреса, домены, хеши) от вредоносных файлов для обогащения данных в SIEM и TI‑платформах. Это помогает более эффективно выявлять повторные атаки того же кластера злоумышленников.
Варианты развертывания песочниц
Рассмотрим виды песочниц по способу развертывания:
- Локальная (self‑hosted). Устанавливается в собственной инфраструктуре организации, позволяет выявлять потенциальные угрозы, не передавая данные за пределы корпоративной сети. У такой песочницы широкие возможности для настройки, например способность использовать «золотые образы»
и специфичное ПО. Настройка изолированной среды, приближенной к инфраструктуре организации, позволяет точнее оценить потенциальные угрозы и риски. Это связано с тем, что подозрительный файл выполняется в окружении, которое максимально соответствует реальной системе, а значит, его поведение будет ближе к тому, что проявилось бы при реальной атаке. К недостаткам относятся высокая стоимость оборудования (песочницы и серверной инфраструктуры), затраты времени и ресурсов на внедрение, а также необходимость постоянного обслуживания. Кроме того, локальные песочницы плохо масштабируются.
- Облачная (cloud). Не требует покупки оборудования, внедрения и обслуживания, проще масштабируется. Но полученные данные обрабатываются за пределами сетевой среды организации, что требует специальных мер защиты и не подходит компаниям с высокими требованиями к безопасности.
- Гибридная. Модель, при которой локальная песочница используется для хранения критически важных данных внутри компании, а облачная — для масштабирования. Главный недостаток такого подхода — сложность в развертывании и необходимость классифицировать, какие данные можно отправлять в облако, а какие — нет.
Пример анализа вредоносного ПО в песочнице
Рассмотрим реальный кейс. На хосте одного из пользователей обнаружили загрузку подозрительного файла. На момент срабатывания алерта запуск объекта не зафиксирован. Аналитик L1 выгрузил файл с помощью EDR и собирается провести первичный триаж. Его задача — определить, является ли файл вредоносным.
Рассмотрим анализ отчета на примере открытой песочницы Any.run. В реальной работе аналитики L1 используют локальные песочницы, чтобы не передавать конфиденциальные данные во внешние сервисы. Так как в отчете Any.run есть вся необходимая для анализа информация в понятном виде, а рассматриваемый файл не содержит важных сведений, мы используем эту песочницу для примера.
Список полей для анализа зависит от целей исследования и уровня подготовки аналитика. В рамках этой статьи рассмотрим те, которые чаще всего используют аналитики L1 при первичном анализе вредоносного ПО.
Имя файла: pzawovtjthaq.exe.
Хеш‑сумма: a8ae600d922f800e997019b60fe446a5a4d7b126981791963616bb0e3fa470b5.
Ниже разберем каждый блок отчета песочницы: выясним, какую полезную информацию он несет и на что нужно обращать внимание.
General Info
Блок General Info содержит базовую информацию об образце и вердикт песочницы.
Аналитика интересуют следующие поля:
Verdict (вердикт). Проставляется на основе результатов статического и динамического анализа, бывает:
- Malicious activity — вредоносное поведение подтверждено.
- Suspicious activity — зафиксировано подозрительное поведение, но нет однозначного результата.
- No threats detected — вредоносная активность не выявлена.
Threats (классификация угрозы). Позволяет понять, к какому классу (дропперам, инъекциям, загрузчикам и др.) относится образец на основе наблюдаемого поведения.
- Analysis date (дата анализа). Позволяет понять, как давно этот образец распространяется в сети.
- MD5, SHA256 (имя файла и хеш‑суммы). Указывают на идентификаторы файла.
Эти поля могут пригодиться для обогащения карточки инцидента в SIEM или SOAR.
Process information
В этом блоке отображаются все процессы, создаваемые при запуске анализируемого файла. В Any.run они также представлены в виде графа, что позволяет быстро проанализировать дерево процессов.
В нашем примере при запуске файла pzawovtjthaq.exe наблюдается следующее поведение:
- Запускается процесс
dialer.exe. - Запускается
powershell.exeиcmd.exe. - Через утилиту
SC.exeсоздаются и запускаются множество сервисов (типичное поведение для майнеров, стремящихся закрепиться в системе).
Network activity
Блок позволяет проанализировать сетевую активность образца: IP‑адреса, домены, протоколы и DNS‑запросы. Это помогает определить взаимодействие со сторонними сервисами и C2‑серверами.
Основные поля для анализа:
- IP‑адрес и порт, по которым они происходили, — информация, с каким удаленным хостом и по какому порту идет соединение.
- PID — ID процесса, который создал эти обращения.
- URL‑адреса и HTTP‑код — определение успешности запроса (200 OK, 404, 403 и т. д.).
- DNS‑запрос и список IP‑адресов, соответствующих этому доменному имени.
Результаты анализа образца pzawovtjthaq.exe:
Dropped files
Во время выполнения образец может создавать, изменять или записывать файлы на диск. Блок Dropped files фиксирует все такие действия. Это один из ключевых источников информации, как вредоносное ПО закрепляется в системе, какие компоненты разворачивает и какие артефакты оставляет после выполнения.
При первичном триаже стоит обращать внимание на следующие аспекты:
- Имена созданных файлов. Они часто маскируются под легитимные (например,
svchost.exe,winupdate.exe). - Путь размещения. Нужно отслеживать появление новых файлов во временных папках (
%TEMP%), системных директориях (System32), папке автозагрузки (Startup). - Хеш‑суммы (MD5, SHA‑256). Позволит пополнить базу IoC и проверить файл по открытым базам, которые служат для обмена образцами вредоносного ПО, и онлайн‑сервисам, по которым проверяют файлы и ссылки (например, VirusTotal).
- Тип файла: PE (EXE или DLL), скрипт (PS1, VBS, BAT). Указывает, для какой ОС предназначен файл, а также помогает понять, требуется ли более глубокий анализ (например, распаковка или динамическое ручное тестирование в изолированной среде).
Этот образец вредоносного ПО относится к семейству Coinminer, которое использует вычислительные мощности жертвы (в основном процессор и оперативную память) для майнинга криптовалюты (например, Monero или Zcash). ВПО закрепляется в системе, добавляя один из опенсорсных майнеров в автозагрузку на хосте.
Обход песочниц
Обнаружение вредоносных программ на основе поведения эффективно только в том случае, если во время поведенческого анализа файл действительно проявляет вредоносную активность. Если этого не происходит, песочница может ошибочно классифицировать исследуемый образец как безопасный. Поэтому злоумышленники разрабатывают разные способы обхода песочниц, скрывая реальное поведение своих программ во время анализа.
Классификация техник обхода песочниц по MITRE ATT&CK
В матрице MITRE ATT&CK техника обхода песочниц обозначена номером T1497 — Virtualization/Sandbox Evasion.
Также есть три подтехники:
-
T1497.001 — обход на основе системных данных (проверки оборудования, процессов, драйверов, запущенных служб, реестра). В этой подтехнике выделяются два класса:
- Heaven’s Gate. Суть подхода в переходе из 32‑битного процесса в 64‑битное пространство ядра, что позволяет обойти WOW64‑хуки
, которые большинство песочниц ставят на этом уровне. - Direct syscall. При таком подходе вредоносное ПО обращается напрямую к
ntdll.dll, минуя перехваченные функции user mode. Поскольку хуки EDR и песочниц работают именно на уровне user mode, прямой вызовNtCreateFileчерез syscall stub вместо стандартного пути позволяет обойти их: хуки просто не срабатывают.
- Heaven’s Gate. Суть подхода в переходе из 32‑битного процесса в 64‑битное пространство ядра, что позволяет обойти WOW64‑хуки
-
T1497.002 — обход на основе активности пользователей (наличие мыши, кликов, окон, запущенных приложений). Примеры:
- Анализ prefetch‑файлов и числа записей EventLog. В свежей виртуальной машине, которая запускается песочницей, их почти нет, у реального пользователя таких файлов множество.
- Проверка геолокации и языка системы. Вредоносное ПО активируется только в целевом регионе, а в песочницах с нейтральной локацией молчит.
-
T1497.003 — обход на основе временных меток (задержки, системное время). Можно выделить:
- Детектирование ускорения функции
Sleep. Многие песочницы перехватывают вызовSleep(), искусственно сокращая задержку до нескольких миллисекунд. Вредоносное ПО может выявить это, вызвавSleep(5000) и сравнив ожидаемое время с фактически прошедшим, например, с помощьюGetTickCount(). Если вместо пяти секунд проходит значительно меньше времени, это указывает на выполнение в песочнице. - RDTSC timing attack. Метод основан на измерении числа тактов CPU между двумя точками. На гипервизоре этот временной промежуток аномально большой из‑за VMExit‑издержек.
- Детектирование ускорения функции
Важно понимать, что техника T1497 не в полной мере покрывает все способы обхода песочниц.
Самое важное — не перечень отдельных подтехник, а общий архитектурный паттерн: многоступенчатая доставка (T1027). На первом этапе вредоносное ПО может не выполнять никаких подозрительных действий. Если в пределах окна анализа его активность остается незаметной, песочница, скорее всего, сделает вывод об отсутствии признаков вредоносности.
При этом полезная нагрузка может быть загружена позднее с C&C‑сервера, извлечена из зашифрованного ресурса или скрыта внутри контейнера (изображения, аудио‑, видео‑ или текстового файла, а также сетевого потока) с использованием техник стеганографии. Такой способ обхода не относится ни к одной из подтехник T1497, но функционально решает ту же задачу.
Общая классификация подходов к обходу песочниц
Песочницы обычно тратят на проверку каждого файла всего несколько минут. Так что ВПО может остаться незамеченным, если отложить выполнение вредоносного кода на некоторое время. Помимо триггеров по времени, оно может использовать и другие события, которые обычно не происходят в изолированной среде. Например, перезагрузку системы или взаимодействие с пользователем. Кроме того, вредоносное ПО может искать на целевом компьютере определенные артефакты, например приложение или настройки локализации.
Рассмотрим многоуровневую классификацию методов обхода песочниц. В ее основе лежат три основных подхода.
Обнаружение признаков активности песочницы
В этом случае вредоносное ПО при запуске выполняет ряд проверок, после чего перестает выполнять вредоносные действия на хосте. Это позволяет определить, не работает ли образец в виртуальной машине, песочнице или другой искусственной среде. Рассмотрим основные типы таких проверок.
1. Определение виртуализации/гипервизора
Сейчас этот подход считается малоактуальным: виртуальные машины используют не только исследователи и аналитики вредоносного ПО, но и специалисты, работающие в производственных средах. Тем не менее злоумышленники все еще применяют эту технику.
Для выявления виртуальной среды вредоносное ПО может использовать различные признаки, включая:
- Артефакты популярных гипервизоров виртуальных машин через обращения к специфичным портам.
- Общие артефакты гипервизора (например,
CpuidилиRDTSCдля определения временных задержек). - Ключи реестра (поиск в
HKLM\SOFTWARE\строк, связанных с VMWare или VirtualBox). - Значения регистров IDTR и GDTR, которые сложно полностью эмулировать.
2. Обнаружение артефактов песочниц
Метод основан на выявлении признаков того, что ВПО запускается в песочнице. Для этого используются три подхода.
Поиск специфичных файлов, процессов, драйверов или учетных записей, характерных для песочниц
Также можно искать общие папки, открытые порты на прослушивание или использование в системе определенных утилит. Например, Deep Freeze — утилиты, предназначенной для восстановления системы.
Перехват функции (hooking)
Многие песочницы и инструменты, анализирующие вредоносное ПО, внедряют DLL для перехвата системных вызовов. Для этого в пространство памяти легитимной DLL внедряется фрагмент кода — перехватчик. Он перехватывает вызовы API‑функций, изменяет их поведение или перенаправляет выполнение, после чего передает управление исходной функции. Перехватчик часто представляет собой модуль, обычно в виде библиотеки DLL, который отслеживает работу образца.
На схеме выше песочница с помощью внедрения DLL перехватывает запущенный вредоносный процесс. Песочница изменяет первые несколько байтов перехватываемой функции (внутри user32.dll) и вставляет инструкцию перехода (jmp). Теперь при любом вызове функции в библиотеке user32.dll происходит переход к коду перехвата в перехватывающей DLL песочницы. Установленный перехватчик позволяет песочнице отслеживать вызовы функций, а при необходимости изменять параметры вызова или возвращаемые значения.
Большинство песочниц используют эмуляцию. Однако и ее можно обнаружить, например выполнив малоизвестную инструкцию процессора, которая не реализована в эмуляторе. Если инструкция не выполнится, вредоносное ПО сделает вывод, что работает в эмулированной среде.
Обнаружение песочниц на основе временных меток
Злоумышленники могут использовать временные метки, чтобы скрыть свое присутствие. Например, откладывать выполнение вредоносного ПО при первом запуске с помощью команд перехода в спящий режим или встроенных в систему функций планирования (например, запланированная задача или задание). Задержки также могут быть связаны с ожиданием выполнения определенных условий (например, наступление конкретного времени, событий и т. д.) или использованием запланированных многоэтапных каналов для предотвращения анализа и проверки.
Чтобы замедлить выполнение вредоносного ПО, также могут использоваться безобидные команды или другие операции. Например, циклы или другие ненужные повторы команд, таких как Ping.
Время также используется в качестве метрики для обнаружения песочниц и аналитических сред, особенно если они изменяют работу временных механизмов, пытаясь имитировать более длительные промежутки времени. Например, злоумышленник может определить, что песочница ускоряет время. Для этого ему нужно сравнить значения временных меток до и после вызова функции Sleep и сопоставить полученную разницу с ожидаемой. Поэтому песочница должна обнаруживать подключения к внешним источникам времени, таким как NTP, а также использовать RDTSC — счетчик временных меток.
3. Обнаружение запуска в искусственной среде
Песочницы создаются специально для анализа ВПО, поэтому отличаются от обычной рабочей станции. Их основные отличия можно поделить на следующие группы:
- Аппаратные: низкое разрешение экрана (800x600), отсутствие USB 3.0, один процессор, небольшой объем жесткого диска и оперативной памяти.
- Программные: установлено только базовое ПО — MS Office, PDF‑ридер, нет почтового клиента или мессенджеров.
- Системные: маленький аптайм хоста, специфичный сетевой трафик, нет принтера.
- Пользовательские: чистый рабочий стол, нет недавно созданных файлов, cookie‑файлов, истории браузера.
Использование уязвимостей песочниц (или мисконфигураций при развертывании)
Вредоносное ПО может использовать и другие приемы для обхода песочниц. Они не связаны с обнаружением артефактов самих песочниц, но позволяют избежать выполнения файла в среде анализа:
- Неподдерживаемые форматы — малоизвестные типы файлов, которые песочница не умеет анализировать.
- Ограничения по размеру — файлы, превышающие лимит песочницы.
- Microsoft COM — COM‑объекты, которые многие песочницы не могут корректно анализировать.
Действия вредоносного ПО при обнаружении песочницы
Если песочница обнаружена, ВПО может:
- Немедленно завершиться. Само по себе это подозрительно, но анализ остановится.
- Вести себя легитимно. Будут выполняться только безопасные операции, имитирующие работу нормальной программы.
- Показать ложное сообщение об ошибке. Появятся уведомления: «Отсутствует системная библиотека» или «Файл поврежден».
Примеры из практики
По данным портала BI.ZONE Threat Intelligence, кластер активности Paper Werewolf использовал загрузчик Infinity, который довольно долго выжидает перед выполнением основного кода, чтобы затруднить анализ в песочнице.
Другой кластер — Silent Werewolf — использовал загрузчик, который обращался к серверу злоумышленников, чтобы определить местоположение жертвы и загрузить следующий компонент ВПО. Если страна или организация, где запущен загрузчик, не интересовали атакующих, вместо вредоносной программы загружался легитимный файл языковой модели Llama. Из‑за этого песочница неверно классифицировала загрузчик как невредоносный. Если загрузчик запускал пользователь из организации, представляющей интерес для злоумышленников, скачивалась вредоносная нагрузка, которая приводила к компрометации системы.
Также команда BI.ZONE Threat Intelligence фиксировала рассылку загрузчика GuLoader, который злоумышленники использовали для атак на российские организации. Инструмент загружал на скомпрометированные устройства широкий спектр вредоносных программ. Вредоносная полезная нагрузка запускалась только после того, как GuLoader предварительно проверял среду запуска, чтобы избежать отладки, выполнения в песочнице или в виртуализированных средах. Так, загрузчик проверял наличие в памяти строк, характерных для виртуальных машин, перечислял и подсчитывал количество окон в системе, а также вычислял время выполнения определенного участка кода между двумя вызовами RDTSC после Cpuid. Если система и среда выполнения не распознавались как виртуальная машина или песочница, GuLoader загружал зашифрованную вредоносную нагрузку с удаленного ресурса.
Еще один пример обхода песочниц: кластер Clubfoot Wolf анализировал параметры системы, включая оборудование, процессы, число ядер CPU, объем диска и памяти, разрешение экрана и количество файлов в системе, чтобы определить, не работает ли вредоносный код в виртуальной среде. Перед запуском следующего этапа ВПО использовало LNK‑ярлык, который проверял, не запущено ли это оно в виртуальной среде, выявляя работающие отладочные и мониторинговые инструменты, количество логических процессоров и разрешение экрана.
Рекомендации при развертывании локальных песочниц
Чтобы снизить риск обнаружения и обхода локальной песочницы вредоносным ПО, при ее развертывании рекомендуется придерживаться следующих правил. Они помогут сделать песочницу максимально похожей на реальную рабочую станцию пользователя.
Правила развертывания локальной песочницы
- Используйте большой объем жесткого диска (более 100 ГБ), поскольку маленький диск выдает виртуальную машину.
- Увеличьте объем оперативной памяти виртуальной машины: он должен быть не менее 4 ГБ, т. к. у реальных пользователей редко бывает 1–2 ГБ RAM.
- Используйте два или более ядра vCPU. Одно ядро — явный признак виртуализации.
- Не устанавливайте образ гостевых дополнений виртуальной машины (VMware Tools, VirtualBox Guest Additions). Они оставляют характерные артефакты (процессы, драйверы, службы), которые легко обнаружить.
- Составьте похожий на пользовательский набор программ: пакет Microsoft Office, браузеры, почтовые клиенты, мессенджеры и т. д.
- Разместите на рабочем столе и в пользовательских папках множество случайных файлов, такие как документы (PDF, DOCX, XLSX), изображения, видео или даже простые игры.
- Перед запуском вредоносного ПО откройте несколько файлов и приложений, чтобы повысить активность ОС в последнее время и создать недавние файлы.
- Измените названия всех использующихся инструментов анализа вредоносных программ на такие, которые с меньшей вероятностью будут обнаружены анализируемым ВПО. Например, имя исполняемого файла Wireshark можно заменить на
obsidian.exe. - Создайте УЗ, выглядящие как обычные логины пользователей, в принятом в организации стиле. Например, Ivanov_Ivan_Ivanovich, а не admin или sandbox‑user. Аналогично задайте имя хоста.
Пошаговое создание виртуальной машины для анализа вредоносного ПО
Создание виртуальной машины
Для этого подходит инструмент VMware Workstation. Если нет особых требований к конфигурации, достаточно использовать основные настройки по умолчанию.
Выбор операционной системы
Поскольку большинство вредоносных программ работают на Windows, эту ОС чаще выбирают и для виртуальной машины.
Установка сетевых настроек для анализа вредоносного ПО
Многие вредоносные программы, например сетевые черви, используют сетевое взаимодействие для распространения, атакуя другие устройства в сети. Поэтому для виртуальной машины важно настроить изолированную сеть. Это позволит избежать заражения других устройств, сохранив возможность отслеживать сетевые запросы и действия вредоносной программы. Такой подход помогает понять цели злоумышленников, а также собрать данные для дальнейшего анализа и разработки сигнатур обнаружения.
Рассмотрим несколько вариантов настройки:
-
Настройка режима «только для хоста»:
Этот режим создает изолированную частную локальную сеть между основной и гостевой ОС. Он широко используется при анализе вредоносного ПО, поскольку такая сеть не имеет доступа к интернету. Это позволяет ограничить распространение ВПО, сохранив возможность сетевого взаимодействия внутри виртуальной среды.
При активации режима VMware создает виртуальный сетевой адаптер как на хосте, так и на виртуальной машине, обеспечивая их соединение без физического сетевого адаптера хоста. Это позволяет гарантировать, что виртуальная машина будет иметь сетевое соединение, но не сможет выходить в интернет.
Чтобы снизить риск распространения вредоносного ПО, рекомендуется настроить ограничительный брандмауэр между хостом и виртуальной машиной. Это поможет предотвратить попадание ВПО на основной компьютер, если оно пытается распространиться.
-
Конфигурация Custom: Specific virtual network. Она позволяет точно настроить виртуальную сеть под нужды анализа:
Обычно в такой конфигурации одна виртуальная машина используется для анализа вредоносного ПО, а другая — для предоставления сервисов, необходимых для анализа. Обе машины подключены к одному виртуальному коммутатору VMNet, что позволяет им взаимодействовать внутри изолированной сети. Хостовая система остается подключенной к внешней сети, но не имеет связи с виртуальной машиной, на которой выполняется вредоносное ПО.
Чтобы детальнее исследовать поведение ВПО, важно симулировать все сетевые сервисы, от которых оно может зависеть. Например, многие вредоносные программы пытаются подключиться к HTTP‑серверам для загрузки дополнительных файлов. Поэтому следует предоставить вредоносному ПО доступ к серверу DNS для разрешения IP‑адресов, а также к HTTP‑серверу для обработки запросов.
В рамках конфигурации Custom: Specific virtual network одна из виртуальных машин будет выполнять роль сервера, предоставляя необходимые сервисы, такие как DNS или HTTP, чтобы имитировать реальное сетевое взаимодействие с вредоносным ПО. Так можно точно анализировать сетевое поведение программы, ее попытки подключений и загрузки дополнительных файлов.
-
Предоставление доступа виртуальной машине к интернету. Иногда для более реалистичного анализа необходимо подключить виртуальную машину, на которой работает вредоносное ПО, к интернету. Наибольшая угроза заключается в том, что компьютер может начать выполнять вредоносные действия, например распространять ВПО на другие хосты, участвовать в распределенных атаках отказа в обслуживании (DDoS) или рассылать спам. Также есть риск, что автор вредоносного ПО заметит подключение к серверу и попытается избежать обнаружения, меняя поведение программы или адреса, что усложнит последующий процесс реагирования.
Подключать машину к сети можно только в том случае, если вы готовы принять последствия, которые могут возникнуть в ходе анализа. -
Подключение через мостовой режим и NAT. Самый распространенный способ подключить виртуальную машину к интернету — использовать адаптер с мостовым подключением (Bridged). Это позволяет ей использовать тот же сетевой интерфейс, что и у физической машины, обеспечивая прямой доступ к сети.
Другой вариант — режим сетевого адресного перевода (NAT), в котором хост делится своим IP‑соединением с виртуальной машиной. В этом случае хост выполняет роль маршрутизатора, и запросы от виртуальной машины выглядят как исходящие с IP‑адреса хоста. Этот режим полезен, если подключение виртуальной машины к сети затруднено или невозможно из‑за сетевых ограничений. Например, если хост использует беспроводной адаптер или подключен к сети, которая разрешает подключение только определенным устройствам, NAT позволяет виртуальной машине подключаться через хост, обходя настройки контроля доступа сети.
Подключение и отключение периферийных устройств
Использование периферийных устройств, таких как CD‑ROM или внешние USB‑накопители, может создать дополнительные риски при анализе вредоносного ПО в виртуальной машине. Когда USB‑устройство подключено к машине, а окно виртуальной машины активно, устройство будет автоматически подключено к гостевой системе, а не к хосту. Это нежелательно, поскольку вирусы и черви могут распространяться через USB‑накопители.
Чтобы предотвратить автоматическое подключение новых USB‑устройств, нужно зайти в настройки виртуальной машины, где выбрать VM → Settings → USB Controller, затем снять галочку с опции Automatically connect new USB devices. Это позволит избежать подключения устройств, позволяющих распространять вредоносное ПО.
Имитация пользовательской среды
Чтобы усложнить детектирование виртуальной машины, необходимо составить похожий на пользовательский набор программ: пакет Microsoft Office, браузеры, почтовые клиенты, корпоративные мессенджеры. Следует подготовить множество случайных файлов в пользовательских папках и на рабочем столе: документы PDF, DOCX, XLSX и т. д., изображения, видео, небольшие игры. Перед запуском вредоносного ПО полезно открыть несколько файлов и приложений, чтобы повысить активность ОС и создать недавние файлы.
Создание снимков состояния
После всех настроек важно создать базовый снимок состояния системы, чтобы использовать его как точку отсчета. Когда вы запустите вредоносное ПО для анализа, все изменения в системе можно будет отследить и проанализировать. После завершения работы можно вернуться к базовому снимку, тогда все изменения, связанные с работой ВПО, будут отменены.
Это делает анализ более безопасным и гибким, позволяя многократно проводить эксперименты без необходимости заново настраивать систему с нуля.
Этапы анализа вредоносного ПО с использованием песочниц
Основные шаги, которые помогут понять процесс анализа вредоносного ПО в песочнице, основаны на подходе, который использовал бы специалист при ручном анализе:
- Создание эталонного снимка системы. Он послужит базой для дальнейшего анализа, на основе которой будет легко вернуть систему в исходное состояние после завершения работы.
- Перенос вредоносного ПО на виртуальную машину. Файл с потенциально вредоносным ПО следует перенести безопасным методом на виртуальную машину, чтобы исключить возможность заражения хостовой системы.
- Анализ на виртуальной машине. Перемещенный файл запускается в виртуальной машине, и аналитик внимательно следит за его поведением. В случае ручного анализа это делается с помощью инструментов для мониторинга, таких как Process Explorer, Wireshark и др., чтобы зафиксировать все сетевые запросы и изменения в системе.
- Запись данных и сбор информации. Во время анализа песочница логирует все действия, делает снимки экрана, собирает логи и другие данные, полезные для дальнейшего исследования. Важно, чтобы все данные сохранялись не внутри виртуальной машины, а на физическом компьютере, чтобы они не потерялись в случае сбоя виртуальной машины.
- Возврат к эталонному снимку. После анализа следует вернуть виртуальную машину к исходному состоянию, восстановив ее из ранее сделанного снимка. Это гарантирует, что все следы работы вредоносного ПО будут удалены, а система готова к новому анализу.
Рекомендации по обнаружению техник обхода песочниц
Даже идеально настроенная песочница не гарантирует, что вредоносное ПО не попытается ее обойти. Необходимо отслеживать следующие аномалии:
- Проверки системного времени и даты установки ОС. Позволяют злоумышленнику определить, не запущено ли ПО в недавно созданной виртуальной машине, а также дождаться определенной даты или времени суток.
- Аномальные задержки выполнения кода. Используются для искусственного увеличения времени выполнения, например с помощью
Sleep, циклов илиping ‑n 10, чтобы переждать анализ. - Проверки наличия индикаторов виртуализации. Выявляют признаки работы в виртуальной среде с помощью инструкций
CPUID,RDTSC, обращений к портам VMware/VirtualBox, а также проверки числа CPU‑ядер, объема RAM, размера диска, MAC‑адресов из диапазонов виртуальных адаптеров VMware/VirtualBox/Hyper‑V и серийных номеров дисков и материнских плат, которые у виртуальных машин часто содержат характерные строки. - Выполнение команд обнаружения или вызовов API для поиска артефактов виртуализации. Позволяет обнаружить ключи реестра, драйверы устройств и службы, характерные для виртуальных машин.
- Приостановка или пропуск выполнения. Позволяет завершить выполнение сразу после запуска или пропустить вредоносную активность при обнаружении песочницы. Если файл запустился и сразу завершился, это может указывать на успешное обнаружение среды анализа.
- Использование DLL перед развертыванием полезной нагрузки. Позволяет обойти пользовательские хуки с помощью прямых системных вызовов (
syscall), прямых обращений кntdll.dllв обход перехваченных функций user‑mode, а также перехода с 32‑ на 64‑битный режим для обхода мониторинга WOW64. - Взаимодействие с пользователем. Позволяет убедиться в наличии реального пользователя по движениям мыши, скроллингу, нажатиям клавиш и изменениям буфера обмена. Автоматизированные песочницы обычно не генерируют такую активность или делают ее слишком равномерной.
- Перечисление запущенных процессов. Позволяет обнаружить не только артефакты VM, но и средства мониторинга и отладки, такие как Wireshark, Procmon, Fiddler, PEStudio, OllyDbg и x64dbg.
- Подозрительное сетевое поведение. Позволяет проверить доступ к интернету с помощью DNS‑запросов к легитимным ресурсам, определить географическое расположение системы по геолокационным запросам, а также выявить признаки изолированной среды по отсутствию сети или другого сетевого трафика.
- Признаки антифорензики. Затрудняет post‑mortem‑анализ за счет самоудаления ПО, очистки журналов событий и подмены временных меток файлов, а также может служить признаком попытки уклонения от анализа.
- Обфускация. Скрывает вредоносную активность на первых этапах выполнения, откладывает доставку полезной нагрузки и использует техники изменения хеша при запуске, полиморфные коды и стеганографию.
Примеры песочниц
В таблице ниже приведены некоторые открытые песочницы. Многие из них позволяют загружать файлы бесплатно, но в некоторых есть ограничения, например на количество загружаемых файлов. CAPE и Cuckoo некоммерческие, поэтому для использования нужно скачать проекты с GitHub и развернуть их самостоятельно.
Все, что отправляется в публичную песочницу, сразу же становится доступным другим исследователям по всему миру. Поэтому проверьте, что файл, который вы отправляете, не содержит конфиденциальную личную или деловую информацию. Также помните, что загрузка вредоносного файла в публичную песочницу может повлиять на расследование, если образец станет общедоступным и атакующий это обнаружит.
Некоторые открытые песочницы:
| Название | Тип | Ссылка | Комментарий |
|---|---|---|---|
| CAPE |
|
https://capev2.readthedocs.io/en/latest/ | |
| Cuckoo |
|
https://github.com/cuckoosandbox |
Больше не поддерживается, но авторы проекта работают над новой версией |
| Hatching Triage |
|
https://tria.ge/ | |
| Hybrid Analysis |
|
https://www.hybrid-analysis.com/ | |
| Joe Sandbox |
|
https://www.joesandbox.com/ |
Недоступна из России |
| VMRay |
|
https://www.vmray.com/ | |
| Any.run |
|
https://any.run/ | |
| Filescan.io |
|
https://www.filescan.io/ |
Мы разобрали, как устроены песочницы, какие задачи они решают на разных уровнях аналитики (от триажа L1 до threat intelligence), с какими проблемами специалисты сталкиваются при их развертывании и, главное, как злоумышленники пытаются обойти этот механизм защиты.
Чек‑лист для аналитика SOC при работе с песочницей:
- Проверить вердикт и классификацию угрозы (general info).
- Изучить граф процессов: нет ли подозрительных дочерних процессов (PowerShell, cmd, wmic, sc).
- Проанализировать сетевую активность: есть ли обращения к редким доменам, пулам для майнинга, C2‑серверам.
- Извлечь IoC (IP‑адреса, домены, хеши, пути к файлам) для блокировки и обогащения SIEM/SOAR.
- Проверить наличие техник обхода: задержки, проверки среды, завершения процессов.
- Зафиксировать вердикт и передать образец на более глубокий анализ (L2/L3) при необходимости.
Песочница не выносит однозначный вердикт об опасности файла, а позволяет вредоносному ПО раскрыть свою суть. Чтобы сделать правильные выводы, важно не только грамотно настроить среду, но и понимать техники обхода песочниц, а также анализировать результаты с учетом контекста.
Инструменты меняются, злоумышленники совершенствуют методы, но неизменным остается одно: лучше защищен тот, кто понимает и способен предсказать поведение атакующего в своей инфраструктуре. И песочница — один из самых сильных союзников аналитика.