HTML-smuggling в почте опасен тем, что файл на входе выглядит почти безобидно: HTML-страница, архив, документ с ссылкой или безобидный на вид вложение. А уже после открытия браузер собирает вредоносный payload из частей и запускает скачивание или выполнение файла. Поэтому обычная проверка «на вирусы» часто молчит, а пользователь получает уже готовую угрозу на компьютере.
Не считайте HTML-файл безопасным только потому, что это «просто веб-страница». В контексте почты HTML с JavaScript — это исполняемая среда, а не картинка и не текст.
- Почему обычные фильтры пропускают такие вложения
- Что именно нужно проверять во вложениях
- Как разные уровни фильтрации работают против HTML-smuggling
- Какие правила стоит включить в почтовом фильтре
- Как выбрать схему защиты под вашу ситуацию
- Что проверить при выборе фильтра или сервиса
- Типовые ошибки, из-за которых защита не работает
- Рабочая схема настройки защиты
- Как реагировать, если письмо с HTML-smuggling всё же дошло
- Как лучше сделать: короткий чек-лист
- Итог
Почему обычные фильтры пропускают такие вложения
Большинство почтовых фильтров хорошо видят то, что лежит на поверхности: имя файла, размер, MIME-тип, сигнатуру известного вируса, ссылку на подозрительный домен. С HTML-smuggling проблема в другом: вредоносная часть может быть спрятана внутри JavaScript, закодирована в base64, собрана из нескольких фрагментов или упакована в архив.
Например, письмо приходит с вложением invoice.html. Антивирус проверяет файл, не находит известного вредоноса и пропускает его. Пользователь открывает файл в браузере, страница запускает скрипт, собирает из закодированных данных другой файл и предлагает его открыть или сохранить. На этом этапе почтовый фильтр уже не при делах.
Именно поэтому защита строится не на одном правиле, а на цепочке: фильтр на входе, глубокое сканирование вложений, анализ JavaScript, песочница, запрет опасных типов файлов и контроль конечных устройств.
Что именно нужно проверять во вложениях
Если цель — закрыть именно HTML-smuggling в электронной почте, фильтр должен смотреть глубже имени файла. Минимально полезный набор проверок такой:
- Имя файла и расширение: .html, .htm, .mhtml, .js, .svg, .zip, .rar, .7z, .iso, .img, .lnk и другие подозрительные типы.
- MIME-тип: имя файла легко подделать, поэтому нужно проверять реальное содержимое.
- Встроенный JavaScript: особенно если в HTML есть скрипты, скрытые формы, iframe, window.open, document.write, Blob, URL.createObjectURL, atob, fromCharCode, msSaveBlob или download.
- Кодированные данные: base64, hex, Unicode-маскировка, разбитые строки, необычные пробелы и переносы.
- Вложенные архивы: злоумышленники часто кладут HTML-файл внутрь zip, rar или 7z, чтобы обойти простые правила по расширениям.
- Ссылки внутри HTML: даже если payload собирается локально, в странице могут быть внешние URL для загрузки следующей стадии.
- Размер и структура: слишком маленький файл с большим количеством кода или странные вложения часто вызывают подозрение.
На практике я бы не строил защиту только на списке запрещённых расширений. Это хороший первый слой, но не основной. HTML-smuggling как раз умеет обходить такие простые правила.
Как разные уровни фильтрации работают против HTML-smuggling
| Подход | Что делает | Что хорошо ловит | Где слабое место | Как использовать |
|---|---|---|---|---|
| Правила по расширениям | Блокирует или помещает в карантин файлы .html, .htm, .mhtml, .js, .vbs, .jsm и похожие типы. | Самые простые атаки и случайные открытия опасных вложений. | Не спасает от архивов, подмены MIME и легитимных HTML-файлов от партнёров. | Использовать как базовый фильтр, но не как единственную защиту. |
| Статический анализ HTML и JavaScript | Распаковывает вложение, декодирует данные, ищет подозрительные конструкции и признаки сборки payload. | HTML-smuggling без запуска файла, закодированные скрипты, подозрительные DOM-операции. | Может давать ложные срабатывания и пропускать обфусцированный код. | Подключать к почтовому шлюзу или API-фильтру, настраивать правила под свои письма. |
| Песочница для вложений | Открывает файл в изолированной среде и смотрит, что он реально делает. | Скачивание файлов, запуск скриптов, попытки обращения к подозрительным доменам. | Если песочница отключает JavaScript или не имитирует действия пользователя, атака может не проявиться. | Использовать для подозрительных вложений и внешних отправителей. |
| CDR или очистка вложений | Пересобирает файл без скриптов или конвертирует HTML в безопасный формат. | Активные элементы, JavaScript, скрытые загрузки. | Может ломать форматирование или делать файл непригодным для части бизнес-процессов. | Хорошо подходит для входящих счетов, заявок и файлов от внешних организаций. |
| URL rewriting и проверка ссылок | Проверяет ссылки в письме и внутри HTML при открытии пользователем. | Переходы на фишинговые или вредоносные сайты. | Не решает проблему, если payload собирается локально из данных внутри HTML. | Добавлять как дополнительный слой, но не рассчитывать только на него. |
| Контроль конечных устройств | Блокирует запуск подозрительных файлов, скриптов и несанкционированных процессов. | Случаи, когда вложение всё же дошло до пользователя. | Не заменяет почтовый фильтр, а снижает ущерб. | Обязателен для пользователей с доступом к почте и чувствительным данным. |
Какие правила стоит включить в почтовом фильтре
Если вы настраиваете защиту от HTML-smuggling в корпоративной почте, начните с правил, которые дают быстрый эффект и не ломают работу отделов.
- Помещайте .html, .htm и .mhtml извне в карантин. Не обязательно сразу удалять такие письма. Часто безопаснее отправить их администратору или пользователю на подтверждение.
- Запрещайте вложения с активным JavaScript. Для большинства бизнес-задач HTML-файл со скриптами не нужен. Если скрипты есть — это повод для проверки.
- Сканируйте архивы вглубь. Настройте проверку zip, rar, 7z и других архивов, но задайте лимиты по глубине и размеру, чтобы фильтр не зависал.
- Проверяйте MIME-тип, а не только имя файла. Файл invoice.pdf может внутри оказаться HTML. Файл document.html может иметь поддельное расширение.
- Отправляйте подозрительные HTML-файлы в песочницу. Песочница должна открывать файл в реальном браузере, с включённым JavaScript и контролируемым доступом в сеть.
- Конвертируйте HTML-вложения в безопасный формат. Если пользователю нужно увидеть содержание, лучше дать PDF или текстовый предпросмотр без скриптов.
- Логируйте не только факт блокировки. В журнале должны быть отправитель, получатель, имя файла, MIME-тип, причина срабатывания, найденные признаки и результат песочницы.
Такой набор правил закрывает большую часть типовых сценариев: внешний HTML-файл не дойдёт до пользователя напрямую, архив будет проверен, подозрительный скрипт попадёт в карантин, а администратор увидит, почему письмо остановлено.
Как выбрать схему защиты под вашу ситуацию
| Ситуация | Что делать | Почему так |
|---|---|---|
| Малая компания, нет отдельного SOC | Включить блокировку внешних .html/.htm/.mhtml, проверку архивов, базовую песочницу и обучение пользователей. | Нужен простой набор правил, который быстро снижает риск без сложной настройки. |
| Финансы, юристы, закупки, HR или другие уязвимые отделы | Добавить строгий карантин HTML-вложений, CDR, расширенный анализ JavaScript и отдельные правила для внешних отправителей. | Эти команды чаще получают документы от партнёров и чаще становятся целью атак. |
| Пользователям часто нужны HTML-файлы от контрагентов | Не разрешать всё подряд. Настройте отдельный процесс подтверждения, безопасный предпросмотр или загрузку через защищённый портал. | Бизнес-процесс нельзя ломать, но прямой запуск HTML из почты лучше исключить. |
| Есть почтовый шлюз, но нет анализа JavaScript | Добавить API-фильтр, облачную песочницу или отдельный модуль статического анализа HTML. | Без анализа скриптов HTML-smuggling часто проходит как обычный безопасный файл. |
| Песочница уже есть, но атаки всё равно проходят | Проверьте, включён ли JavaScript, открываются ли скачанные файлы, симулируются ли действия пользователя и есть ли доступ к сети в контролируемом режиме. | Песочница без браузера или без скачанного файла не увидит главную часть атаки. |
Что проверить при выборе фильтра или сервиса
Когда выбираете почтовый фильтр, не спрашивайте только «ловит ли он вирусы». Для HTML-smuggling нужны конкретные возможности.
- Фильтр должен понимать MIME-структуру письма, а не только смотреть на имя вложения.
- Должна быть распаковка архивов с настройкой лимитов по глубине и размеру.
- Нужен анализ JavaScript внутри HTML, включая декодирование и поиск подозрительных функций.
- Песочница должна открывать HTML в браузере, а не только проверять файл как статический объект.
- Фильтр должен уметь помещать письмо в карантин, а не просто удалять его без объяснения.
- Нужны понятные журналы: что найдено, где найдено, почему файл заблокирован.
- Должна быть возможность настроить исключения для доверенных отправителей, но с отдельным контролем.
- Желательно иметь API или интеграцию с SIEM/SOAR, чтобы реагировать на инциденты быстрее.
Хороший фильтр не обязан быть самым дорогим. Но он должен показывать, как именно он принимает решение. Если в логе только «malware detected» без деталей, администратору будет сложно понять, что произошло и как донастроить правила.
Типовые ошибки, из-за которых защита не работает
- Блокируют только расширение .html. Файл может лежать в архиве, иметь другое расширение или быть вложен в документ.
- Доверяют антивирусной сигнатуре. Новый HTML-smuggling может не иметь известной сигнатуры, но поведение у него подозрительное.
- Не анализируют JavaScript. Именно скрипт обычно собирает payload и запускает скачивание.
- Песочница запускается без JavaScript. Тогда файл выглядит безопасным, потому что атака просто не стартует.
- Не проверяют архивы. Это один из самых частых обходных путей.
- Разрешают HTML от «прошедших SPF/DKIM/DMARC» отправителей. Проверки домена полезны, но они не доказывают, что конкретное вложение безопасно.
- Удаляют письма без карантина. Пользователь может ждать важный документ, а администратор потом не сможет восстановить контекст.
- Не тестируют правила на реальных примерах. После настройки полезно проверить фильтр на безопасных тестовых образцах и посмотреть, что именно он видит.
Рабочая схема настройки защиты
Если нужно выстроить защиту с нуля, я бы шёл не от модного продукта, а от последовательной схемы.
- Сначала определите, кому в компании вообще нужны HTML-вложения. Чаще всего оказывается, что почти никому. Для таких отделов можно ставить жёсткий запрет.
- Включите карантин для внешних .html, .htm и .mhtml. Это сразу отсекает самые очевидные атаки.
- Настройте глубокое сканирование архивов. Укажите лимиты: сколько уровней вложенности проверять, какой максимальный размер архива разбирать, что делать с зашифрованными архивами.
- Добавьте статический анализ JavaScript. Ищите не только известные вредоносные строки, но и подозрительные сценарии: декодирование, сборка Blob, скрытые ссылки, автоматическое скачивание.
- Подключите песочницу для подозрительных писем. Особенно для отправителей вне домена, новых контрагентов и писем с вложениями нестандартного типа.
- Настройте безопасный предпросмотр. Если файл нужен пользователю, лучше дать очищенную версию без скриптов.
- Проверьте конечные устройства. Даже при хорошем фильтре часть писем может пройти. EDR или похожий контроль должен блокировать запуск подозрительных файлов.
- Проведите короткий тест после настройки. Проверьте, видят ли администраторы причину блокировки, доходят ли легитимные письма и не создали ли вы лишнюю нагрузку на пользователей.
Такой подход удобнее, чем сразу включать десятки правил. Сначала закрываете самый рискованный вектор, потом смотрите журналы и только после этого тонко настраиваете исключения.
Как реагировать, если письмо с HTML-smuggling всё же дошло
Если пользователь сообщил о подозрительном HTML-файле или система уже выявила инцидент, не ограничивайтесь удалением одного письма. Нужно убрать угрозу из всех мест, куда она могла попасть.
- Найдите все копии письма в почтовых ящиках.
- Проверьте, открывал ли пользователь вложение и скачивал ли созданный файл.
- Посмотрите журналы браузера, EDR и сетевые логи на предмет подозрительных загрузок.
- Заблокируйте найденные домены, URL, хэши файлов и имена вложений в фильтрах.
- Обновите правила почтового шлюза, чтобы похожие письма не доходили повторно.
- Сохраните образец письма и вложения для разбора, но не пересылайте его обычной почтой.
Главная ошибка в такой ситуации — удалить письмо только у одного пользователя. Если атака массовая, она может лежать в ящиках других сотрудников и сработать позже.
Как лучше сделать: короткий чек-лист
- Внешние HTML-вложения — в карантин или безопасный предпросмотр.
- JavaScript внутри HTML — повод для отдельной проверки.
- Архивы — сканировать обязательно, с лимитами.
- Песочница — только с браузером, JavaScript и контролем скачанных файлов.
- URL-фильтры — полезны, но не заменяют анализ вложений.
- Пользовательское обучение — нужно, но не должно быть единственным барьером.
- EDR на конечных устройствах — обязательный последний слой защиты.
Итог
HTML-smuggling в электронной почте обходит простые фильтры, потому что использует браузер как инструмент сборки и запуска вредоносного файла. Поэтому защита должна смотреть не только на имя вложения, но и на содержимое HTML, JavaScript, архивы, MIME-тип и поведение файла в песочнице.
Практичный минимум: заблокировать или помещать в карантин внешние HTML-вложения, включить глубокое сканирование архивов, анализ JavaScript, песочницу с реальным браузером и контроль конечных устройств. Если в компании есть отделы, которые постоянно получают документы от внешних организаций, добавьте CDR или безопасный предпросмотр.
Самое надёжное решение — не искать один идеальный фильтр, а собрать несколько слоёв: почтовый шлюз отсекает очевидные угрозы, анализ вложений ловит подозрительные скрипты, песочница проверяет поведение, а EDR не даёт запустить вредоносный файл, если письмо всё-таки дошло до пользователя.