MDE, MotW и SmartScreen: защита от фишинговых полезных нагрузок

Фишинг, MotW и SmartScreen: почему контекст решает всё

Новое исследование, посвящённое взаимодействию защитных механизмов при фишинговых атаках, выявило критическую разницу между лабораторными тестами и реальными сценариями доставки вредоносного кода. Специалисты провели серию испытаний, чтобы оценить, как Microsoft Defender for Endpoint (MDE), Mark of the Web (MotW) и SmartScreen влияют на выполнение конечной нагрузки. Результаты оказались неожиданными: один и тот же payload, легко обошедший MDE при прямом запуске, был бессилен против многоуровневой защиты Windows, когда его доставили, имитируя классическую phishing-кампанию.

От C2-implant до двойной блокировки: методология эксперимента

В ходе работы был разработан кастомный C2-implant, способный обходить сигнатуры и поведенческий анализ MDE. Однако стоило поместить этот implant в контекст, приближенный к реальному — загрузка через браузер и запуск пользователем, — как он немедленно блокировался. Это расхождение наглядно демонстрирует, что тесты в «стерильной» среде прямого выполнения не учитывают целый пласт защит, активируемых при типовой доставке через интернет. Ключевыми фигурантами сценария стали Mark of the Web и использующий его SmartScreen.

Mark of the Web — не приговор, а лишь ярлык

Одним из главных заблуждений, которые развенчало расследование, стало представление о MotW как о самостоятельном блокирующем факторе. Технически Mark of the Web — это всего лишь классификатор, добавляемый к файлам, полученным из небезопасных источников. Наличие у файла идентификатора ZoneId=3 (проверяется через PowerShell) лишь сигнализирует системе о его происхождении, но не вызывает запрета на запуск. Истинным «стражем» выступает SmartScreen, использующий эту метку как триггер для собственных проверок. Без MotW механизм SmartScreen останется пассивным, но и сама по себе метка без SmartScreen не остановит вредонос.

SmartScreen: репутация имеет значение, контекст — тем более

Когда пользователь пытается открыть файл с MotW через Windows Shell (например, двойным щелчком в Проводнике), SmartScreen инициирует reputation check, сверяясь с облачной базой данных Microsoft. При отсутствии у файла устоявшейся репутации запуск блокируется. Именно этот механизм пресёк выполнение загруженного через браузер C2-implant’а.

Однако исследование подтвердило, что контекст выполнения критичен. Запуск того же файла через PowerShell, как выяснилось, способен обойти проверку SmartScreen, поскольку защита завязана на инициацию проверки оболочкой Windows. Таким образом, срабатывание и MotW, и SmartScreen напрямую зависит от способа вызова.

7-Zip и потеря MotW: брешь, о которой молчат

Отдельного внимания заслуживает поведение сторонних архиваторов. Тестирование методов доставки показало: файлы, извлечённые с помощью инструментов вроде 7-Zip, не наследуют атрибут MotW (ZoneId=3). В отличие от встроенного в Windows обработчика, 7-Zip оставляет извлечённые объекты «чистыми». Как следствие, при запуске такого файла SmartScreen не активируется — метка, необходимая для запуска reputation check, попросту отсутствует. Это создаёт значительный security gap в средах, где персонал массово использует альтернативные утилиты для работы с архивами, и демонстрирует неспособность SmartScreen защитить сценарий, если конвейер доставки разрушил исходный контекст.

blob: и data: URL — панацеи для обхода не существует

Ещё один миф, разобранный в отчёте, касается экзотических схем доставки через blob: и data: URL. Ранее в сообществе циркулировало мнение, что использование этих механизмов позволяет избежать присвоения файлу метки MotW. Практические тесты опровергли это утверждение: даже файлы, доставленные подобными путями, получали въевшийся ZoneId=3, гарантируя, что SmartScreen всё равно будет вызван при попытке выполнения.

Дополнительный нюанс выявило сравнение браузеров. Microsoft Edge оказался в более выигрышном положении благодаря глубокой интеграции со SmartScreen — проверка производится ещё на этапе загрузки файла, а не постфактум. Другие же браузеры, такие как Chrome, полагаются исключительно на проверку на уровне операционной системы, запуская защиту только после сохранения файла на диск.

Code Signing: репутация как ресурс, а не абсолютный щит

Затрагивая тему сертификатов подписи кода, исследователи подчеркнули: хотя наличие валидной подписи способно сформировать положительную репутацию и снизить пристальность SmartScreen, это не делает двоичный код неуязвимым. Процесс подписания содержит известные уязвимости, позволяющие злоумышленникам успешно эксплуатировать подписанные (signed binaries) для проникновения вредоносного контента. Репутация, даруемая сертификатом, — лишь временное преимущество, а не полноценная блокировка атаки.

Выводы: слоёный пирог безопасности

Обобщённые результаты подводят к парадоксальному, но важному для практической защиты заключению:

• MDE может быть обойдён на этапе полезной нагрузки в изолированных тестах, но это не гарантирует успех атаки в реальном мире.
• Механизмы вроде SmartScreen, активируемые контекстом доставки через интернет, демонстрируют высокую устойчивость к техникам уклонения и обеспечивают значимый эшелон защиты.
• Корректно сконструированная phishing-атака всё равно столкнётся с многоуровневой проверкой, где контекст выполнения, инструменты распаковки и тип оболочки могут как спасти, так и погубить всю операцию.

Исследование наглядно показывает: при оценке защищённости конечных точек нельзя ограничиваться тестами прямого запуска. Только всестороннее понимание нюансов — от присвоения ZoneId=3 сторонними архиваторами до зависимости SmartScreen от оболочки — позволяет выстроить действительно эффективную стратегию киберустойчивости.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.