Как тестировать подозрительные .msu-пакеты обновлений Windows в виртуальной машине

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

Зачем вообще проверять .msu-файлы

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

Типичные ситуации, когда нужно тестировать:

• Файл скачан не с официального каталога Microsoft Update
• Обновление распространяется через сторонний сайт или торрент
• Антивирус ругается на файл, но не факт, что это реальная угроза — может, ложное срабатывание
• Нужно понять, что именно делает обновление, перед установкой на продакшен-сервер

Что понадобится

Минимальный набор инструментов:

• Гипервизор: VirtualBox (бесплатно) или VMware Workstation Player
• Образ Windows — та же версия, для которой предназначен .msu
• 7-Zip или встроенная утилита expand для распаковки
• Process Monitor (Sysinternals) для отслеживания изменений
• Wireshark или Fiddler для проверки сетевой активности
• Sandboxie или Windows Sandbox для быстрого запуска инсталляторов

Шаг 1. Готовим изолированную среду

Первое правило — VM должна быть полностью отрезана от хост-системы и локальной сети. Создаём снапшот чистой ВМ сразу после установки Windows и настройки базовых инструментов. Это ваша точка отката.

1. Установите гостевые дополнения (Guest Additions), но не включайте общие папки и двусторонний буфер обмена.
2. Переведите сетевой адаптер в режим «Не подключён» или используйте изолированную внутреннюю сеть без шлюза.
3. Отключите автоматическое подключение съёмных носителей в настройках гипервизора.
4. Сделайте снапшот с понятным названием: «Clean_MSU_test_before».

Если работаете с VMware, дополнительно проверьте настройки VMX-файла — убедитесь, что отключены все каналы взаимодействия с хостом, включая drag-and-drop и copy-paste.

Шаг 2. Распаковываем и смотрим, что внутри

MSU — это контейнер. Внутри всегда лежит CAB-архив с реальным содержимым обновления. Распаковать можно двумя способами:

Через командную строку:

expand -F:* "C:\updates\KB123456.msu" "C:\updates\KB123456_extracted"

Через 7-Zip: просто открываете .msu как архив и извлекаете содержимое.

После распаковки вы увидите структуру примерно такого вида:

• WSUSSCAN.cab — вспомогательный компонент для сканирования
• Несколько .cab-файлов с реальными файлами обновления
• XML-манифест с описанием пакета и правилами установки

Открываем манифест и смотрим: какие файлы будут заменены, какие ключи реестра изменены, какие компоненты затронуты. Если в манифесте фигурируют подозрительные пути вроде AppData, Temp или сторонние директории — это красный флаг.

Шаг 3. Анализируем содержимое CAB-архивов

Извлекаем файлы из внутренних CAB-архивов тем же expand или 7-Zip. Теперь перед нами набор файлов, которые должны быть заменены или добавлены в систему.

На что смотрим:

• Цифровые подписи каждого файла — правый клик → Свойства → Цифровые подписи
• Названия файлов — совпадают ли с тем, что должно быть в легитимном обновлении
• Расширения — особенно .exe, .dll, .ps1, .bat, .cmd в нестандартных местах
• Версии файлов — сравниваем с известными легитимными версиями

Быстрый способ проверки подписи через PowerShell:

Get-AuthenticodeSignature -FilePath "C:\updates\KB123456_extracted\some_file.dll"

Если подпись отсутствует, не соответствует Microsoft, или файл подписан неизвестным сертификатом — это повод остановиться и не устанавливать пакет.

Шаг 4. Запускаем в песочнице и наблюдаем

Если статический анализ не выявил явных проблем, переходим к динамическому. Устанавливаем .msu в VM и смотрим, что происходит.

Запуск Process Monitor (Procmon):

1. Запускаем Procmon от администратора ещё до установки обновления
2. Устанавливаем фильтр: операция — «Process Create», «WriteFile», «RegSetValue»
3. Запускаем установку .msu через командную строку: wusa.exe "C:\updates\KB123456.msu" /quiet /norestart
4. После завершения останавливаем запись и анализируем

На что обращаем внимание в логе Procmon:

• Запуск дочерних процессов из нестандартных мест (Temp, AppData, корень диска)
• Запись в автозагрузку реестра (Run, RunOnce)
• Изменение системных файлов, которые не относятся к заявленному назначению обновления
• Обращение к подозрительным внешним IP-адресам

Запуск сетевого мониторинга:

Даже если сетевой адаптер в VM отключён, полезно запустить Wireshark перед включением сети. Включаем адаптер на время теста, смотрим, куда идут запросы. Легитимное обновление Microsoft будет обращаться к серверам с доменами *.update.microsoft.com, *.windowsupdate.com, *.delivery.mp.microsoft.com. Всё остальное — подозрительно.

Шаг 5. Сравниваем систему до и после

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

Я обычно делаю так:

1. Перед установкой — снапшот VM или экспорт реестра: reg export HKLM "C:\before_update_registry_hklm.reg"
2. Устанавливаем .msu
3. После установки — аналогичный экспорт с суффиксом _after
4. Сравниваем через WinMerge или любой diff-инструмент

Также полезно сравнить список файлов в системных директориях. Можно использовать встроенную утилиту DISM для просмотра установленных пакетов:

dism /online /get-packages | findstr "KB123456"

Сравнение подходов к тестированию

В зависимости от ваших целей и доступных ресурсов, выбирается подход:

Подход	Что даёт	Сложность	Когда использовать
Статический анализ (распаковка + проверка подписей)	Быстрое понимание содержимого без рисков	Низкая	Первичная проверка любого подозрительного файла
Установка в VM с мониторингом (Procmon + Wireshark)	Полная картина поведения пакета	Средняя	Глубокая проверка перед установкой на рабочую систему
Сравнение снапшотов до/после	Точный список всех изменений в системе	Средняя	Аудит изменений, документирование для команды
Автоматический анализ в песочнице (Any.Run, Joe Sandbox)	Быстрый отчёт о поведении с минимумом усилий	Низкая	Экспресс-проверка, но файл уходит во внешний сервис
Установка на реальную машину без проверки	Ничего полезного, только риски	—	Никогда для непроверенных файлов

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

Если всё чисто — подпись Microsoft, файлы в ожидаемых местах, нет подозрительной активности:

Можно устанавливать на рабочую систему. Но я всё равно рекомендую сначала проверить на одной тестовой машине в вашей среде, особенно если это критичный сервер.

Если подпись отсутствует или не от Microsoft:

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

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

Сохраните логи Procmon и Wireshark. Откатите VM на снапшот. Если файл был получен из внешнего источника — сообщите туда, откуда скачали. При необходимости — загрузите файл на VirusTotal для проверки антивирусами.

Если обновление легитимное, но вы не уверены в его необходимости:

Проверьте номер KB на сайте support.microsoft.com. Почитайте описание — иногда обновления содержат известные баги, которые могут сломать вашу рабочую конфигурацию.

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

• Тестирование на хост-машине вместо VM. Даже если кажется, что «ничего страшного не случится», один плохой .msu может скомпрометировать всю систему. ВМ — обязательно.
• Забывают отключить сеть в VM. Вредоносное обновление может отправить данные наружу за секунды. Сетевой адаптер должен быть отключён по умолчанию.
• Не делают снапшот перед тестом. Без снапшота откат к чистому состоянию — это переустановка всей VM. Потратьте минуту на снапшот — сэкономите час.
• Проверяют только цифровую подпись .msu, но не содержимое. Подпись может быть валидной, но внутри — модифицированные файлы. Всегда проверяйте каждый файл отдельно.
• Используют VM с общими папками. Это канал утечки данных и потенциальный путь заражения хоста. Общие папки должны быть отключены во время тестирования.
• Игнорируют сетевую активность. Даже если файлы выглядят чисто, вредоносное ПО может проявить себя только при обращении к серверу управления. Wireshark обязателен.

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

Вот мой стандартный чек-лист, который я прохожу с каждым неофициальным .msu:

1. Проверить размер файла — сравнить с типичным размером для данного типа обновления
2. Распаковать и проверить цифровые подписи всех файлов
3. Открыть манифест, убедиться, что пути и компоненты соответствуют заявленному KB
4. Установить в изолированную VM с запущенным Procmon
5. Проанализировать лог на предмет подозрительных операций
6. Включить сеть и проверить сетевую активность через Wireshark
7. Сравнить реестр и файловую систему до и после
8. Если всё чисто — установить на целевую машину

Для удобства я держу одну чистую VM с Windows 10 и одну с Windows Server, с которых делаю клоны для каждого теста. Это экономит время на подготовку.

Подведём итог

Тестирование подозрительных .msu-пакетов — это не разовое действие, а небольшой процесс. Распаковать, проверить подписи, установить в изолированную VM, понаблюдать за поведением, сравнить до и после. Если на каком-то этапе что-то вызывает сомнения — не устанавливайте пакет на рабочую систему.

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

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