Как выявить и разобрать подозрительные .vbs-скрипты в Outlook-плагинах

Ко мне периодически приходят с одной и той же проблемой: «В Outlook появился странный файл с расширением .vbs, плагин стал себя странно вести — что это и насколько опасно?». Иногда это легитимный скрипт для автоматизации обработки писем. Чаще — закрепившийся в макросах или дополнении вредоносный код, который пытается рассылать себя контактам или запускать сторонние процессы. Ниже я рассказываю, как такой скрипт разобрать, что в нём искать и как принять решение — оставить или удалить.

Почему .vbs в Outlook вообще появляется

Visual Basic Script — это встроенный в Windows скриптовый язык. Outlook умеет выполнять макросы на VBA (Visual Basic for Applications), но чистые .vbs-файлы обычно не являются частью стандартной функциональности почтовика. Они могут появиться несколькими путями:

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

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

Где физически лежат подозрительные скрипты

Прежде чем анализировать код, нужно понять, от чьего имени он запускается и где хранится. Типичные места:

• Папка макросов Outlook — обычно внутри %userprofile%\AppData\Roaming\Microsoft\Outlook. Если там есть файлы .vbs или .vbe, они могут подгружаться при старте.
• Рабочая папка плагина — часто в Program Files или AppData конкретного дополнения. Сторонние плагиновые скрипты иногда лежат рядом с .dll или .exe этого плагина.
• Автозагрузка Windows — скрипт может запускаться не из Outlook напрямую, а через планировщик задач или раздел реестра Run, а уже оттуда взаимодействовать с почтовым клиентом через COM-объект Outlook.Application.
• Вложения в письмах — классический вектор. Пользователь открыл письмо, дважды кликнул по .vbs-файлу, и тот выполнился вне Outlook, но получил доступ к адресной книге.

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

Как безопасно открыть и прочитать .vbs-файл

Никогда не открывайте такой файл двойным кликом — он выполнится. Вместо этого:

1. Скопируйте файл в изолированную папку на диске, желательно без доступа к сети.
2. Откройте его в текстовом редакторе: Notepad++, VS Code или хотя бы в Блокноте. Подойдёт любой редактор, который показывает код как текст, а не запускает его.
3. Если файл зашифрован или представляет собой «мусор» — это плохой признак. Легитимные скрипты редко обфусцируют.
4. Если есть возможность — откройте файл в виртуальной машине без корпоративного доступа, чтобы исключить случайное выполнение при ошибке.

Что искать в коде: краткий чек-лист

Когда я открываю подозрительный .vbs-скрипт, я прохожуся по нескольким контрольным точкам. Вот на что обращать внимание:

• Работа с адресной книгой Outlook. Строки вроде GetNamespace("MAPI"), Recipients, AddressEntries — это признак, что скрипт читает ваши контакты. Само по себе это не зло, но повод насторожиться, если плагин не должен этого делать.
• Отправка писем. Вызовы CreateItem(0), .Send, особенно в цикле по всем контактам — классический признак почтового червя.
• Работа с файловой системой. Использование Scripting.FileSystemObject для записи в системные папки, автозагрузку, подмену файлов.
• Запуск внешних процессов. WScript.Shell.Run, CreateObject("Wscript.Shell") с командами cmd, powershell, wmic — почти всегда подозрительно в скрипте для Outlook-плагина.
• Сетевые запросы. MSXML2.XMLHTTP или WinHttp.WinHttpRequest — скрипт что-то отправляет наружу. Обратите внимание, на какие адреса идут запросы.
• Обфускация. Длинные строки из случайных символов, Chr() с набором чисел, кодировки Base64 внутри — попытка скрыть реальные действия.
• Отсутствие цифровой подписи. Легитимные скрипты в корпоративной среде часто подписаны. Если подпись отсутствует и вы не знаете автора — доверия нет.

Типичные паттерны вредоносных скриптов

За годы практики я выделил несколько повторяющихся сценариев. Они помогают быстро оценить уровень угрозы:

1. Рассылка себя дальше. Скрипт открывает адресную книгу, выбирает получателей и отправляет им письмо с вложением или ссылкой. Часто использует ваше имя и тему Re: или Fwd:, чтобы письмо выглядело легитимным.
2. Сбор данных. Скрипт читает тела писем, вложения, контакты и сохраняет их в файл, после чего отправляет на внешний сервер. Ищите в коде обращения к свойствам .Body, .Attachments, .Subject.
3. Бэкдор. Скрипт остаётся в системе и периодически проверяет внешний ресурс на наличие команд для выполнения. Это самый опасный сценарий, потому что может существовать незаметно месяцами.
4. Саботаж. Скрипт удаляет письма, изменяет настройки учётной записи, блокирует отправку. Встречается реже, но тоже бывает.

Сравнение: легитимный скрипт vs вредоносный

Не каждый подозрительный с виду скрипт опасен. Вот таблица, которую я использую при быстрой сортировке:

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

Когда перед вами файл и вы его открыли, двигайтесь в таком порядке:

1. Определите точку входа. Найдите первую выполняемую строку или подпрограмму. Часто это Sub Main() или код в обработчике события Application_Startup.
2. Пройдитесь по цепочке вызовов. Если скрипт вызывает другие процедуры — проследите, что каждая из них делает. Не закапывайтесь в каждую строку, держите в голове общую схему.
3. Выделите все обращения к внешним ресурсам. Сетевые запросы, запуск программ, запись файлов — это ключевые точки для анализа.
4. Проверьте адреса и пути. Если в коде есть URL или IP — пробейте их через VirusTotal или любой другой сервис репутации. Если путь к файлу ведёт в автозагрузку — это подозрительно.
5. Оцените объём и сложность. Скрипт на 10 строк, который просто показывает окно с текстом — не то же самое, что на 500 строк с обфускацией и сетевыми запросами.
6. Сравните с известными сигнатурами. Если есть доступ к антивирусной лаборатории или сервисам анализа — загрузите туда файл. Даже бесплатный VirusTotal может подсказать, видели ли этот скрипт раньше.

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

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

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

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

Не существует универсального рецепта, но есть сценарии, в которых я обычно действую так:

• Скрипт найден, но вы не знаете, откуда он. Не удаляйте сразу. Сделайте копию в архив, проанализируйте код. Если код чистый и нужный — оставьте. Если подозрительный — удалите и проверьте систему антивирусом.
• Скрипт пришёл во вложении и вы его открыли. Немедленно отключите сеть, запустите полную проверку антивирусом, смените пароли от почты и корпоративных сервисов. Если на компьютере есть важные данные — свяжитесь с ИБ-отделом.
• Скрипт является частью платного плагина. Свяжитесь с разработчиком плагина и запросите объяснение. Если разработчик не может внятно объяснить, зачем нужен скрипт — от плагина лучше отказаться.
• Скрипт обнаружен на нескольких компьютерах в сети. Это признак массовой рассылки или заражения. Нужно централизованно собрать образцы, проверить их и принять решение об удалении одновременно на всех машинах.

Инструменты, которые я использую

Для быстрого анализа не нужны сложные средства. Достаточно:

• Notepad++ или VS Code — для просмотра кода с подсветкой синтаксиса.
• VirusTotal — для проверки файла или ссылок из скрипта через десятки антивирусов одновременно.
• Process Monitor (Sysinternals) — чтобы увидеть, какие процессы запускает Outlook и куда обращается.
• Autoruns (Sysinternals) — для проверки автозагрузки, если скрипт запускается не из Outlook напрямую.
• Песочница или виртуальная машина — если нужно наблюдать за поведением скрипта в безопасной среде.

Как предотвратить появление таких скриптов в будущем

Лучшее лечение — профилактика. Несколько практических мер:

• Устанавливайте плагины для Outlook только из проверенных источников и проверяйте их цифровую подпись.
• Отключите выполнение макросов в Outlook по умолчанию — оставьте только для подписанных или доверенных.
• Настройте политику безопасности Outlook так, чтобы вложения с расширениями .vbs, .vbe, .js, .jse блокировались или сохранялись в изолированную папку.
• Регулярно проверяйте список установленных надстроек и удаляйте те, которыми не пользуетесь.
• Обучайте коллег или близких: не открывать вложения с расширениями скриптов, даже если письмо пришло от знакомого человека — его аккаунт мог быть скомпрометирован.

Итог

Подозрительный .vbs-скрипт в Outlook-плагине — это не повод для паники, но и не повод закрывать глаза. Сначала разберите его содержимое, определите источник и оцените, какие действия он выполняет. Если скрипт читает контакты, отправляет письма или обращается к внешним ресурсам без вашего ведома — это инцидент, который нужно расследовать. Если код чистый и нужный — оставьте, но убедитесь, что он подписан и документирован.

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