Я у мамы джентльмен, или почему базовые правила защиты почты не работают без экспертизы

Проверка подлинности отправителя

Владелец почтового домена защищает его от подделки с помощью трех механизмов: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) и DMARC (Domain-based Message Authentication, Reporting and Conformance).

SPF публикует список серверов, которые имеют право отправлять почту от имени домена. DKIM добавляет к письмам цифровую подпись, подтверждающую, что они не были изменены в пути. DMARC указывает получателю, что делать с сообщениями, не прошедшими проверку, и присылает владельцу домена отчеты о них. Почтовый шлюз анализирует входящие письма на соответствие правилам — сегодня такая верификация стала обязательной.

Однако проверки SPF, DKIM и DMARC работают только с доверенными отправителями. Мы привыкли, что они соблюдают правила, и поэтому легко выявляем подделку со стороны. Но если злоумышленник регистрирует домен специально для кибератаки, ему не составит труда выполнить все требования, и письма пройдут базовые фильтры. Добавьте к этому техники визуальной подмены доменного имени — и количество потенциально опасных адресов становится безграничным. В таких случаях нужны дополнительные проверки домена отправителя:

• Время создания домена. Злоумышленник использует новые домены до тех пор, пока их не внесли в реестры вредоносных индикаторов. Чем моложе домен, тем выше риск.

• Приватность WHOIS и RDAP. Крупные компании редко скрывают данные о владельце в открытых полях. Злоумышленник, наоборот, включает приватность, чтобы не светить связь между фишинговыми доменами.

• Юридический статус владельца. В поле Registrant Organization добросовестные компании указывают название юридического лица. Злоумышленник этого сделать не может — ему просто нечего вписывать.

Такие истории хорошо ловятся через потоки данных об угрозах (фиды). Поиск свежих фишинговых доменов и страниц — важная часть охоты за угрозами (threat hunting). Команды безопасности наполняют фиды сетевыми индикаторами, которые затем загружают в средства защиты, чтобы обнаруживать атаки.

Проверка содержимого письма на соответствие стандартам

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

Важная категория проверок — поиск нарушений стандарта EML. К ним относятся:

• Отсутствие обязательных или важных заголовков. Стандарт определяет перечень заголовков и минимальное количество раз, которое каждый из них должен встретиться в письме. Например, From: и Date: обязательны. Заголовок Message-ID: рекомендован стандартом, так как содержит идентификатор письма, на который можно ссылаться при пересылках и ответах. Отсутствие таких заголовков указывает на самописные скрипты для рассылки. Там пожертвовали корректным формированием сообщения в пользу простоты и скорости.
• Дублирование заголовков, уникальных по стандарту. Это тоже признак софта, который не учитывает требования формата. Второй сценарий — злонамеренный: манипуляция заголовками с целью обойти средства защиты и ввести получателя в заблуждение. Самый наглядный случай — дублирование заголовка From:. Если почтовые серверы и клиенты не смогут однозначно определить отправителя, у атакующего появится лазейка для подмены.
• Проверка значений заголовков. Здесь много сценариев. Текстовые заголовки должны иметь кодировку, понятную почтовым клиентам. MIME-заголовки должны содержать набор данных для корректного разбора тела письма и вложений. Из заголовков также можно понять, каким клиентом сформировано письмо, и проверить присущие ему паттерны.

Но не все проверки в этой категории очерняющие. В письме могут встретиться пользовательские X-заголовки с результатами проверок, полученными от других решений на предыдущих этапах. При определенном уровне доверия к ним мы можем снизить требования к содержимому и обработать трафик быстрее.

Проверка сетевых активов

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

Некоторые провайдеры разделяют репутационные списки по причинам попадания в них активов. Это может быть явная жалоба на фишинг, вредоносное ПО или указание на спам-рассылку с IP-адреса или домена, от которого такой активности не ждали.

Отличный инструмент — проверка сетевых активов в потоках данных об угрозах. Например, PT Feeds агрегирует знания экспертов PT ESC, полученные в ходе расследований инцидентов и изучения деятельности хакерских группировок.

Важное замечание о работе с источниками

Добавлять новые фиды с разными категориями активов нужно строго по описанию. Если природа списка не подразумевает явно вредоносных индикаторов, не стоит подключать такой источник в блокирующем режиме. Потоки серых доменов — хостингов, прокси-серверов, Tor-нод — лучше использовать для обогащения контекста.

И еще один совет: любому новому источнику полезно дать поработать в режиме мониторинга, без блокирующих вердиктов. Затем нужно проанализировать возможные ложные срабатывания и только потом решать, можно ли доверить его автоматике.

Проверка содержимого почтового сообщения

Первое, что нужно анализировать в письме, — URL-ссылки, которые встречаются как в обычном тексте, так и в кликабельных элементах HTML-части. Отдельный канал доставки фишинга — графические элементы. Злоумышленник может вставить в письмо обычную текстовую ссылку, но убедить жертву перепечатать ее будет сложно. Другое дело — изображение с QR-кодом, тем более что сейчас почти у каждого под рукой есть смартфон для его считывания. Поэтому средство защиты должно уметь распознавать текст и коды в пересылаемых картинках.

Все методы анализа можно разделить на статические и динамические. Статическая проверка не требует перехода по ссылке и работает с ней как с объектом:

• Репутационные списки. Проверка наличия ссылки и сетевых активов из нее в статических базах с возможностью выборочной блокировки по категориям.

• Базы данных об угрозах. Проверка наличия ссылки и сетевых активов из нее в базах данных об угрозах.

• Подозрительные конструкции. Поиск чрезмерно длинных доменных имен, а также других URL и адресов электронной почты в query-параметрах — части URL после знака ?.

К динамическим методам можно отнести анализ информации, полученной в результате перехода по ссылке:

• Цепочки перенаправлений. Статический анализ всех промежуточных ссылок, по которым переходит пользователь.

• Контент по прямой ссылке. Например, если ссылка ведет не на веб-страницу, а на скачивание файла.

• HTML-контент. Имеется в виду разбор полученной веб-страницы, и здесь важны инструменты анализа. Браузерный эмулятор обрабатывает JavaScript-ловушки: обфускацию, паузы и перенаправления, реализованные в коде, а не в заголовках HTTP-ответа.

Антивирусная проверка вложений

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

Самый примитивный способ антивирусной проверки — сверка по индикаторам угроз (для файлов это хеши MD5, SHA-256 и другие). Базы индикаторов могут храниться локально или в облаке, но минус очевиден: хеш меняется при любой модификации файла. Злоумышленники ежедневно генерируют новые семплы ВПО в промышленных масштабах, и ни одна система не успевает собрать индикаторы по всему, что еще не «засветилось». Плюс техники — в простоте и точности: если хеш уже есть в базе как вредоносный, блокировка сработает мгновенно, даже когда файл не успели проанализировать эксперты.

Для обнаружения нового ВПО обычно применяют статические эвристические методы. Это сигнатурный анализ (поиск характерных строк, последовательностей байтов, подозрительных конструкций в коде) и эмуляция (выполнение машинного кода в изолированной среде, чтобы поймать вредоносные конструкции). Как правило, классические почтовые средства защиты этим и ограничиваются. Но сегодня даже массовые атаки используют продвинутые методы маскировки, и этого набора уже недостаточно. Нужны более глубокие техники — продвинутый статический анализ и проверка в песочнице.

Продвинутый статический анализ включает распаковку и глубокий разбор файлов с извлечением всех внутренних объектов. В случае антивирусной проверки документов это, например, касается активных элементов, таких как скрипты, макросы и ссылки.

Извлеченные из текста или из QR-кодов ссылки можно проверить репутационно (по индикаторам угроз) или динамически, с рекурсивной проверкой артефактов по ссылке. Вот примерная схема углубленного анализа вложения.

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

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

Мы понимаем, что почте нужна многоуровневая защита, поэтому создали PT Email Security — продукт, объединяющий антифишинг и антиспам с антивирусной проверкой вложений и глубоким поведенческим анализом в песочнице.

Пользовательские правила проверки

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

Белые списки отправителей — рискованная история, так как компании не всегда следят за собственной спам-гигиеной и редко настраивают почтовые сервисы идеально. Поэтому средство защиты должно позволять гибко управлять политиками для доверенных контрагентов. Например, пропустить проверку аутентичности письма и проверку на спам, но при этом не обелить отправителя полностью — антифишинг и антивирус должны отработать в полном объеме.

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

Почему защита почты требует многоуровневого подхода

Почтовым технологиям уже много лет, но динамичное развитие IT приводит к появлению новых способов атак через, казалось бы, устаревшие протоколы. Это создает вызов для службы ИБ практически любой организации и требует такого же динамичного развития экспертизы в средствах защиты почты.

В статье мы перечислили как базовый минимум, так и продвинутые актуальные технологии. Использовать все описанные проверки централизованно можно только в многоуровневых решениях, объединяющих функции антифишинговой и антиспам-защиты с продвинутыми методами борьбы с ВПО, включая проверку вложений в песочницах. Потому что в современных реалиях защита почты либо работает комплексно, либо не работает вообще.

Авторы:

Фёдор Гришаев, ведущий специалист группы исследования фишинговых угроз, Positive Technologies.

Шаих Галиев, руководитель отдела экспертизы PT Sandbox антивирусной лаборатории PT ESC.