Фишинг: первый этап в цепочке атаки
Главный секрет успеха фишинга — в социальной инженерии, в умении сыграть на человеческих слабостях и эмоциях. Для реализации этой техники злоумышленникам не нужны сложные дорогостоящие технологии.
Атакующие отправляют фейковые коммерческие и рекламные предложения, приглашают присоединиться к несуществующим благотворительным сборам, присылают письма якобы от коллег или руководителей жертвы. Фишинг используется не только в электронной почте, но и в СМС, мессенджерах, а также на поддельных сайтах.
Главная цель атакующих — обмануть жертву: они пытаются заставить пользователя запустить вредоносный файл, раскрыть конфиденциальную информацию, такую как пароли, номера банковских карт или другие личные данные. Получив доступ к этой информации, злоумышленники могут проводить дальнейшие операции: внедрять вредоносное ПО, похищать деньги, шантажировать или продавать украденную информацию третьим лицам.
Фишинг часто становится первым звеном в сложной многоуровневой цепи кибератаки, создавая серьезные риски для безопасности как компаний, так и обычных пользователей. Обучение сотрудников и использование специализированных средств защиты помогает снизить эти риски, но киберпреступники постоянно совершенствуют методы обмана, чтобы достичь своих целей.
В этой статье расскажем о работе аналитика SOC, когда он сталкивается с задачей проверить письмо на вредоносность.
По матрице MITRE ATT&CK фишинг (T1566) — одна из техник первоначального доступа. Она содержит следующие подтехники:
- T1566.001. Spearphishing Attachment (вредоносное вложение). В этом сценарии злоумышленники прикрепляют вредоносный файл к письму и обычно полагаются на открытие и запуск ВПО пользователем. Вредоносные вложения могут быть разными: документы Microsoft Office, исполняемые файлы, PDF‑файлы, архивы и т. д. При открытии вложения полезная нагрузка злоумышленника использует уязвимость или напрямую выполняется в системе пользователя. Текст фишингового письма обычно содержит правдоподобную причину, по которой файл следует открыть, и иногда даже инструкцию, как обойти защиту системы, чтобы сделать это. В письме также могут содержаться запароленные архивы, которые используются для обхода средств защиты электронной почты. В таких случаях пароль от архива часто находится в тексте письма.
- T1566.002. Spearphishing Link (вредоносные ссылки). В этом сценарии электронные письма содержат вредоносные ссылки. Как правило, они сопровождаются призывами к переходу. Атакующие рассчитывают, что пользователь кликнет по ссылке или скопирует ее и вставит в адресную строку браузера. Посещаемый сайт может скомпрометировать браузер с помощью эксплоита. Переход по ссылке также может привести к скачиванию приложения, документа, ZIP‑архива или исполняемого файла. Злоумышленники также включают ссылки в изображения или QR‑коды. В этом случае атакующие ждут, что жертва перепечатает ссылку с картинки самостоятельно или отсканирует QR‑код и в итоге перейдет по вредоносной ссылке.
Кроме того, киберпреступники используют ссылки со специальными символами, чтобы имитировать легитимные сайты. Такая техника известна как атака с использованием омографа IDN. В написании домена содержатся символы из разных алфавитов (допустим, латинские и кириллические символы, которые выглядят идентично). Например, в написании домена
catcat.ruможно заменить английскую «a» на русскую. Помимо перечисленного, вредоносные ссылки используются для кражи токенов доступа к приложениям. - T1566.003. Spearphishing via Service (фишинг через сервис). В этом сценарии злоумышленники отправляют фишинговые сообщения через различные каналы: соцсети, личную почту, мессенджеры. Например, атакующие под видом рекрутеров могут отправлять сообщения о вакансиях. Это дает им возможность в ходе диалога с жертвой получить информацию о службах, политиках и программном обеспечении, которое используется в компании, где работает адресат. Рассмотрим типичный пример. Первоначальный контакт злоумышленник устанавливает через соцсети. Затем отправляет вредоносное содержимое (например, под видом описания вакансии) на личную почту, которую сотрудник просматривает на своем рабочем компьютере. Это позволяет атакующему обойти средства периметральной защиты электронной почты. Пользователь с большей вероятностью откроет файл, поскольку видит тот документ, который он ожидал получить. И даже если полезная нагрузка не отработает должным образом (например, будет удалена антивирусным ПО), то злоумышленник может продолжить коммуникацию с жертвой и направить повторные письма с ВПО, чтобы вредоносная нагрузка все‑таки запустилась.
- T1566.004. Spearphishing Voice (так называемый вишинг, он же голосовой фишинг). В этом сценарии злоумышленники пытаются обмануть пользователя и заставить выполнить нужные им действия, общаясь с ним голосом. Например, атакующие могут убеждать жертву перейти по присланной в момент разговора ссылке, загрузить то или иное ПО, которое в итоге окажется вредоносным или позволит злоумышленникам получить удаленный доступ к устройству пользователя. Они также комбинируют голосовой фишинг с генерацией запросов на многофакторную аутентификацию, чтобы обманом заставить пользователей раскрыть учетные данные MFA или принять запросы на аутентификацию.
Мы сосредоточимся на анализе фишингового письма с вредоносным вложением либо ссылкой, т. к. это самые распространенные подтехники в корпоративной среде.
Для начала рассмотрим типы протоколов электронной почты. Без их понимания дальше будет сложно.
-
Simple Mail Transfer Protocol (SMTP). Используется для отправки сообщений от клиента на почтовый сервер или между почтовыми серверами. Данные электронной почты передаются через интернет по протоколу TCP/IP на портах 25, 465 (SSL) и 587 (TLS) для безопасной передачи. При отправке электронного письма SMTP направляет его с почтового клиента отправителя на почтовый сервер получателя.
Алгоритм работы протокола SMTP можно представить следующим образом:
- Пользователь указывает адрес отправителя и получателя. Это происходит при формировании сообщения в почтовом клиенте или веб‑сервисе, который передает данные на сервер.
- Клиент устанавливает соединение с SMTP‑сервером отправителя, передавая необходимые данные: адреса, тему, тело письма.
- SMTP-сервер определяет, куда направить письмо, и устанавливает соединение с сервером получателя.
- Если получатель доступен и соединение с нужным портом установлено, сервер принимает сообщение. В случае ошибки (например, если адрес не существует) отправитель получает уведомление о том, что сообщение не доставлено.
- Post Office Protocol Version v3 (POP3). Используется для получения писем с почтового сервера на локальное устройство. Работает на портах 110 (незашифрованный) и 995 (зашифрованный SSL/TLS). Главная отличительная черта протокола — его способность работать автономно. Как только корреспонденция загружается из почтового ящика, она остается на устройстве адресата, при этом навсегда удаляясь с почтового сервера. Иными словами, если письмо вдруг потеряется и на компьютере, восстановить его не получится. Доступ к электронным письмам возможен только с того устройства, на которое они были загружены.
-
Internet Message Access Protocol (IMAP). Также используется для получения писем с почтового сервера, однако IMAP позволяет пользователям получать доступ к электронной почте и управлять ею непосредственно на почтовом сервере, не загружая ее. Работает на портах 143 (незашифрованный) и 993 (шифрованный SSL/TLS).
Электронные письма хранятся на сервере, и пользователи могут получить к ним доступ с нескольких устройств.
Если проводить аналогию с реальной жизнью, то протокол SMTP можно сравнить с размещением заказа в сервисе доставки еды. Вы решаете, какой вид пиццы вам нужен и в каком ресторане, и размещаете заказ (действуете как SMTP‑клиент, отправляющий электронное письмо). Сервис доставки (SMTP‑сервер отправителя) получает ваш заказ, обрабатывает его и отправляет в ресторан (SMTP‑сервер получателя), который принимает заказ, передает на кухню и готовит вашу пиццу. Когда курьер привезет пиццу к вашей двери, вам будет отправлено уведомление или электронное письмо. Если ингредиентов для выбранного вида пиццы не окажется на кухне либо возникнут иные проблемы, вы получите уведомление о том, что выполнить заказ невозможно или доставка задерживается.В случае с POP3 можно провести аналогию с получением заказа еды навынос. Вы делаете заказ, а затем идете в ресторан за едой. Официанты ее забирают с кухни и передают вам. Если по дороге вы уроните или потеряете пакет с заказанной едой, в ресторане вам уже ничем помочь не смогут.IMAP скорее похож на шведский стол в ресторане. В таком формате вы оплачиваете посещение на входе и можете выбрать все, что хотите. Если по дороге до столика вы уроните поднос, то можете подойти и взять еду неограниченное количество раз.
Каждое электронное письмо состоит из двух основных частей:
- Заголовок (header) — набор полей с данными об отправителе, получателе, дате, теме и маршруте сообщения.
- Тело письма (body) — основное содержимое сообщения: текст, HTML‑разметка, вложения и т. д.
Сведения, содержащиеся в заголовке, используют SMTP‑серверы для маршрутизации сообщения. Приведем для примера минимальный набор SMTP‑команд для отправки электронного письма:
HELO— указывает IP‑адрес или доменное имя отправителя письма.MAIL FROM— начинает новую почтовую транзакцию и устанавливает адрес отправителя. Используется только SMTP для отправки уведомлений об ошибках и не будет включен в электронное письмо.RCPT TO— указывает, кому следует отправить электронное письмо; команду можно вызывать несколько раз подряд для нескольких получателей.DATA— информирует SMTP‑сервер о том, что следующие строки будут включать содержимое электронной почты.
Эти команды также называют «SMTP‑конвертом»: адрес на конверте определяет, куда письмо будет отправлено. Тело письма содержит информацию, которая предназначена для получателя. Само сообщение может быть создано в виде обычного текста или HTML‑документа, где используются теги для форматирования, вставки изображений, ссылок и других элементов.
Заголовки SMTP содержат очень много полезной для аналитика информации. Детальнее рассмотрим их ниже. Поля заголовка формируются в процессе передачи письма и нужны как для отображения пользователю, так и для технической обработки. Сервер SMTP добавляет свое поле Received при каждом этапе пересылки. Это позволяет проследить маршрут сообщения и подтвердить его доставку до нужного адреса. Команда Return‑Path фиксирует путь возврата и может быть использована для фильтрации или отклонения писем.
Рассмотрим следующую ситуацию. Пользователю поступило письмо, он решил, что оно выглядит подозрительно, и хочет направить его в SOC на более детальный анализ. В первую очередь нужно сохранить это письмо в формате EML или MSG, поскольку в таком виде файл будет содержать полный оригинал письма, в том числе все заголовки и вложения. В формате MSG можно сохранить письмо в почтовых клиентах MS Outlook. В формате EML можно скачать письмо из большинства почтовых клиентов. Таким образом пользователь передаст конверт со всеми «уликами» в руки аналитика SOC.
Как же, глядя на письмо, аналитик может понять, что оно фишинговое? У таких писем могут присутствовать определенные признаки. Рассмотрим их подробнее.
Подозрительный почтовый домен
Когда аналитик открывает письмо, он в первую очередь смотрит на адрес отправителя в заголовке письма в поле From. Главное в нем, конечно же, почтовый домен.
Как можно понять, что перед нами потенциально подозрительный почтовый домен:
- Он общедоступный, например
gmail.com,mail.ruи т. д. - Он похож по написанию на официальные имена компаний или организаций (например,
googie.com). - Он состоит из случайного набора букв и цифр.
- Он новый, т. е. недавно зарегистрирован.
Для проверки даты регистрации домена используют сервисы whois7 или nic.ru.
Также существуют сервисы для проверки домена на наличие различных проблем. Там можно проверить домен на наличие в черных списках, проверка DMARC, TLS, SMTP-баннера и т. д. О подобных инструментах поговорим ниже.
IP-адрес отправителя и серверы, через которые прошло письмо
Дальше аналитик смотрит на IP‑адрес отправителя, а также по возможности ищет информацию, через какие серверы прошло письмо. Найти это он может в следующих заголовках:
Received— информация о почтовых серверах и сетях, через которые прошло сообщение электронной почты на пути к получателю.Message-ID— уникальный идентификатор, присваиваемый каждому сообщению, чаще всего первым почтовым сервером, который встретится у него на пути. Некорректно сформированный заголовокMessage‑ID, в котором присутствует название хоста отправителя, много символов разного регистра и т. д., может указывать как на использование нестандартного ПО для отправки электронных писем (например, скрипта), так и на активность спам‑ботнетов, распространяющих спам и фишинговые рассылки.
Путь из серверов, через которые прошло письмо, также может показать какой‑то нетипичный маршрут в случае, если сообщения от этого отправителя мы встречали раньше. IP‑адрес отправителя может позволить определить, был ли подделан адрес отправителя письма, и пригодится для проверки SPF‑записи.
Заголовки Return‑Path и In‑Reply‑To
Return-Path — это заголовок, содержащий адрес электронной почты, на который отправляются недоставленные письма или ошибки в случае, если письмо возвращается из‑за неправильного адреса электронной почты или заблокированного почтового ящика.
SMTP-сервер может добавить этот заголовок, когда получает сообщение от клиента. Выходит, что Return‑Path обозначает настоящего отправителя, но только постфактум.
Кроме того, аналитик может проверить, что проставлено в поле In‑Reply‑To — так можно понять, подделан ли адрес отправителя, сравнив заголовки From и In‑Reply‑To.
Результаты проверки SPF‑записи
SPF расшифровывается как Sender Policy Framework — это DNS‑запись домена, отвечающая за проверку подлинности отправителя почты. Она содержит информацию о доверенных серверах, с которых разрешено отправлять письма.
SPF работает путем добавления записи DNS TXT в файл DNS‑зоны домена, в которой перечислены IP‑адреса или имена хостов, разрешенные для отправки электронной почты с данного доменного имени. Эта запись просматривается принимающими почтовыми серверами для проверки подлинности письма.
Пример:
v=spf1 ip4:10.20.30.40 ip4:50.60.70.80 -all
SPF-запись всегда начинается с v=spf1. Этот параметр не изменяется, сейчас поддерживается только spf1.
Далее указывается список авторизованных серверов. В нашем случае для отправки электронных писем от имени домена авторизованы серверы с IP‑адресами 10.20.30.40 и 50.60.70.80, а также сервер MX‑записи.
Параметр -all сообщает серверу, что адреса, не указанные в SPF‑записи, не авторизованы для отправки электронных писем и должны быть отклонены. Такая SPF‑запись является «строгой».
Другие варианты префиксов для параметра all:
~all— помечать письма, не прошедшие проверку, как небезопасные или спам («нестрогая» SPF‑запись).+all— любой сервер может отправлять электронные письма от имени вашего домена. Наименее безопасный вариант записи, который устанавливать не рекомендуется.
Важный момент: с доменом не может быть связано более одной SPF‑записи, запись должна заканчиваться параметром all или включать в себя redirect на другой домен.
Принимающий почтовый сервер проверяет, совпадает ли IP‑адрес сервера, отправившего письмо, с любым из авторизованных источников, перечисленных в записи SPF. Если есть совпадение, письмо проходит проверку SPF. Если совпадения нет, результат зависит от определенного в настройках почтового сервера параметра all и может повлиять на то, попадет ли письмо во входящие, в папку со спамом или будет отклонено. Особенно в сочетании с DMARС.
Посмотреть результат SPF‑проверки можно в поле SPF заголовка Authentication‑Results. Там же отображаются результаты других проверок подлинности, например DKIM.
Заголовок может принимать следующие возможные значения:
pass— сообщение прошло проверку SPF.fail— сообщение не прошло проверку SPF, в письме был указан IP‑адрес отправителя. Это значение будет появляться, когда сбой произошел при проверке «строгой» SPF‑записи.softfail— в записи SPF определено, что этому узлу не разрешена отправка, но SPF‑запись — «нестрогая».neutral— запись SPF явно указывает, что она не утверждает, разрешен ли IP‑адрес для отправки.none— для домена не задана запись SPF или нет результатов проверки.temperror— произошла временная ошибка. Например, ошибка DNS. В дальнейшем проверка может быть пройдена.permerror— произошла постоянная ошибка. Например, запись SPF для домена имеет неправильный формат.
Подпись письма (DKIM)
DKIM (DomainKeys Identified Mail) — второй способ проверить, подделан ли адрес отправителя у письма.
DKIM добавляет исходящей почте цифровой отпечаток, который дает принимающей стороне возможность проверить, имеет ли право используемый сервер отсылать письма с указанного домена. Это не то же самое, что S/MIME
DKIM основывается на асимметричном шифровании. Для каждого сервера генерируется пара (или несколько пар) из закрытого и открытого ключей шифрования.
- Закрытый ключ помещается на сервере отправителя и используется для создания соответствующих DKIM‑заголовков для всей исходящей почты клиента.
- Открытый ключ помещается владельцем домена в его файл DNS‑зоны в виде специальной TXT‑записи, и она становится доступна всем.
Итак, пользователь отправляет письмо, и его принимает почтовый сервер отправителя. Почтовый сервер добавляет новый заголовок DKIM‑Signature. Заголовок содержит подпись, составленную на основе закрытого ключа шифрования, тела письма, его заголовков, текущего времени и других параметров. Письмо с новым заголовком DKIM‑Signature пересылается получателю.
Почтовый клиент получателя письма анализирует DKIM‑заголовок и на основе открытого ключа (полученного с DNS‑сервера) выносит вердикт — признаются ли отправитель и письмо подлинными.
Этап проверки подписи письма представляет особый интерес:
- Почтовый клиент делает DNS‑запрос, содержащий доменное имя, с которого, предположительно, было отправлено письмо.
- Из тела ответа DNS‑сервера выбирается соответствующая TXT‑запись, содержащая публичный ключ шифрования.
- Каждый тег внутри заголовка дешифруется из Base64 в текстовое представление.
- Каждая полученная строка дешифруется с использованием ранее полученного публичного ключа.
- Последний этап — сравнение текста и заголовков письма с дешифрованной информацией из заголовка DKIM. При любом найденном несоответствии выносится вердикт
dkim=fail, а если содержимое совпадает —dkim=pass.
Структура DKIM‑заголовка
Типичный заголовок DKIM‑Signature состоит из списка тегов вида «тег = значение». Имена тегов короткие и в большинстве случаев состоят из 1–2 символов.
Пример:
DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; d=example.com; i=admin@example.com; s= smtpapi; c=relaxed/simple; t=1117574938; x=1118006938; h=from:to:subject:date; b=RXhhbW9sZUV4YW1wbGVFeGFtcGxlRXhhcGxlRXhhbXBsZQ==
Описание тегов:
b— содержимое письма (тело + заголовки, закодировано в Base64);bh— хеш‑сумма тела письма (также в Base64);d— доменное имя отправителя, проставившего подпись;h— список подписанных заголовков;a— алгоритм генерации подписи;v— версия DKIM;s— разделитель пространства имен для тегаd=;c— алгоритм для приведения тела письма и заголовков к каноническому виду;q— список алгоритмов для получения публичного ключа;x— срок действия подписи;i— подпись клиента, проставившего DKIM‑подпись;l— размер тела письма в количестве октетов, включенных в криптографический хеш;t— время проставления подписи;z— копии заголовков на момент проставления подписи.
DKIM-Signature содержится в заголовке Authentication‑Results аналогично SPF‑записи и может принимать следующие значения:
pass— проверка сообщения с помощью DKIM пройдена успешно.fail— подпись присутствует, но проверка DKIM не пройдена (подпись невалидна).none— сообщение не было подписано. Этот результат может указывать на то, что домен имеет запись DKIM или не удалось определить результат проверки DKIM.
Тема, контент и вложения: как фишинг цепляет внимание
Все перечисленные выше признаки фишингового письма аналитик может проверить, ориентируясь на заголовки, не заглядывая в тело письма и не читая его содержимое. Но этого не всегда достаточно, и нужно копнуть глубже. Поэтому иногда необходимо заглянуть внутрь письма и проверить остальные признаки.
Содержание фишинговых писем тоже имеет свои особенности. Если понимать принципы фишинга, становится гораздо проще его распознать.
Какие особенности фишинговых писем с точки зрения содержания аналитик может определить при открытии письма:
- Привлекающая внимание тема письма. Например, злоумышленники любят пугать пользователей сообщениями с темами «Срочно смените пароль», «Превышен лимит хранилища электронной почты». Могут упоминаться какие‑то громкие общественные события. Злоумышленники любят играть на эмоциях пользователей — любопытстве, страхе и сострадании.
- Побуждение пользователя к немедленному действию. Если злоумышленники убедили жертву открыть письмо, его текст должен заставить совершить необходимое действие — скачать файл, перейти по ссылке или отправить данные. Часто атакующие делают акцент на сжатых сроках.
- Обращение от лица известных компаний, однако с отличающимся доменом отправителя. Злоумышленники часто отправляют фишинговые рассылки от имени крупных и известных организаций. Узнаваемые логотипы и прочие элементы фирменного стиля повышают доверие со стороны пользователей, подталкивая их открыть письмо.
- Вредоносное содержимое. Это ключевой компонент фишингового письма, оно может содержать вредоносную ссылку, вредоносное вложение, QR‑код c вредоносной ссылкой.
Электронное письмо в формате EML состоит из двух частей — заголовка и тела сообщения. В заголовке представлена маршрутная информация сообщения. Он может содержать и другие сведения — тип контента, данные отправителя и адресата, дату получения, абсолютный адрес отправителя, адрес почтового сервера и реальный адрес электронной почты, с которого или на который было отправлено сообщение. Тело сообщения EML содержит основную информацию электронной почты в виде текста, гиперссылок и вложений. Тело письма может содержать простой читаемый текст, но это не обязательно. При этом тело сообщения может быть пустым или содержать зашифрованные данные вложений.
Поэтому аналитик, помимо содержания, также может ориентироваться на следующие заголовки:
Subject— заголовок содержит тему сообщения.Mime-Version— MIME‑заголовок, обозначающий версию MIME‑протокола, который использовался отправителем. MIME (Multipurpose Internet Mail Extensions) — стандарт, который описывает, как пересылать по электронной почте исполняемые, графические, мультимедийные и смешанные данные.
Вложение, расширение вложений, хеш
Переходим к ключевому моменту в проверке писем — анализу вложений.
Здесь нельзя не упомянуть MIME‑типы. За них отвечает Content‑Type — MIME‑заголовок, который сообщает почтовой программе о типе данных, хранящихся в сообщении.
В большинстве случаев MIME‑типом письма будет являться multipart, поскольку он используется для обозначения сообщений, состоящих из нескольких частей. Далее для каждого вложения указывается свой тип.
Администраторы могут настраивать фильтрацию вложений по расширениям и MIME‑типам. Например, можно настроить запрет пропускать письма с исполняемыми файлами. То же самое можно сделать с любыми типами.
В таблице приведены основные MIME‑типы:
| Категория системного файла | MIME‑типы |
|---|---|
| Видео и мультимедиа |
Начинается с |
| Музыка и аудио |
Начинается с |
| Изображение |
Начинается с |
| Текст |
Начинается с |
| Приложение |
Начинается с Например, |
| Сжатый файл |
|
| Файл Microsoft Office |
|
Примерно так может выглядеть multipart‑заголовок сообщения MIME с вложением формата Microsoft Word:
Пример заголовка письма с вложением в формате MS Word
Content-type: multipart/mixed; boundary="Boundary_any ascii character except some of the following special characters:
( )< > @ , ; : \ / [ ] ? = " " --Boundary_any ASCII character, except some special characters below: content-Type: text/plain;---- charset=iso-8859-1 Content-transfer-encoding: 7BIT --Boundary_ASCII characters Content-type: application/msword; name="message.doc" Content-Transfer-Encoding: base64
Аналитик SOC уделяет особое внимание анализу вложения. Для этого применяют базовые принципы анализа вредоносного ПО (да‑да, поначалу каждый файл воспринимается аналитиком как потенциально вредоносный). Эти принципы мы рассмотрим в следующих статьях цикла.
Кратко проговорим, в чем состоит главное отличие статического и динамического анализа.
В общем случае статический анализ не подразумевает запуск вредоносного ПО — его смысл в определении метаданных и статистических величин, которые характеризуют исследуемый файл и могут быть использованы в качестве индикаторов компрометации. Для вредоносного ПО предполагается получить хеш‑суммы образца.
Если у вредоносного ПО нет навесной защиты (упаковка или шифрование участков кода или данных), то к образцу применяют строковый анализ — выявляют и изучают строки в образце вредоносного ПО. Они могут содержать информацию о функциональности образца, используемых серверах управления и возможных выполняемых командах.
Динамический анализ же нацелен на получение расширенного списка IoC, установить которые можно только после запуска вредоносного ПО. В большинстве случаев динамический анализ позволяет также провести первичную атрибуцию образца вредоносного ПО, то есть установить его авторство, если это известная кибергруппировка.
Кроме определения системных изменений, на этом этапе накапливается информации о сетевой активности вредоносного ПО. Для этого используют перехватчики и обработчики трафика (Wireshark, Fiddler, Burp Suite). Фрагменты трафика позволяют выявить серверы управления вредоносным ПО и особенности передачи команд управления. Полученные данные расширяют список IoC и создают предпосылки для глубокого анализа вредоносного ПО.
Обычно аналитик использует для анализа вложений песочницы — системы для выявления вредоносных программ, которые запускают подозрительный объект в изолированной среде (виртуальная машина с полнофункциональной операционной системой), а для обнаружения признаков вредоносности анализируют поведение объекта.
Ниже мы рассмотрим такой анализ на примере открытых песочниц. Обычно их не используют в корпоративной среде, поскольку есть риск утечки конфиденциальной информации. Но в случае с лабораторным стендом таких рисков нет, и пример будет показательным.
Еще нужно упомянуть использование злоумышленниками трекинговых пикселей (они же web beacon).
На первый взгляд, это безобидный инструмент, который помогает маркетологам отслеживать эффективность рассылок. Трекинговые пиксели встраиваются в электронные письма и загружаются, когда получатель открывает письмо.
Отправитель может получать информацию о том, когда и кто открывает письмо, сколько раз были нажаты ссылки, какую платформу использует получатель и в каком статусе находится сообщение. Однако сбор таких данных обычно осуществляется без ведома или согласия получателей, поскольку большинство получателей не видят встроенный пиксель, т. к. он представляет собой просто пустое место в конце сообщения.
Отправляя электронные письма с трекинговым пикселем, злоумышленник может составить карту сети, узнать перечень устройств, используемых в компании, определить IP‑адреса, узнать, кто из получателей открыл письмо и может клюнуть на другую приманку. Также атакующий способен даже отследить рабочее время сотрудников.
Используя собранную информацию, киберпреступники могут проанализировать сетевую архитектуру организации, в том числе используемые операционные системы, характеристики сетевых устройств. На основе этого можно искать и эксплуатировать существующие уязвимости.
Также полученные данные будут полезны злоумышленникам для сбора статистики, чтобы сделать фишинговые кампании более эффективными.
Ссылки, домены, IP‑адреса из письма
В письме, помимо вредоносных вложений, могут содержаться вредоносные ссылки — в явном виде, внутри вложений, а также на изображениях или в виде QR‑кодов.
При переходе по ссылке возможны следующие угрозы:
- На хост пользователя будет загружено вредоносное ПО (в том числе майнеры или кейлоггеры).
- Пользователь перейдет на фишинговый сайт — например, поддельную страницу банка или организации, в которой работает получатель. Такие сайты предназначены для кражи учетных данных (либо иной личной информации), которые могут быть использованы в последующих атаках. В случае с поддельными интернет‑магазинами пользователь рискует сообщить данные своей банковской карты злоумышленникам.
Также атакующие могут использовать перенаправление (redirect): ссылка выглядит как легитимная, но при переходе пользователь проходит через одну или несколько промежуточных страниц и в итоге попадает на вредоносный или фишинговый ресурс.
Для маскировки вредоносных ссылок и обмана пользователей злоумышленники иногда используют поддельные UTM‑метки, выдавая их за легитимные источники, например utm_source=bank_of_america и utm_medium=email. Пользователь думает, что ссылка ведет на официальный сайт банка, хотя на самом деле это фишинговый сайт.
UTM-метки — это параметры, добавляемые к URL‑адресам, чтобы отслеживать источник трафика на сайтах. Они помогают понять, откуда приходят пользователи, и оценить эффективность различных рекламных кампаний. Они состоят из нескольких параметров:
utm_source— источник трафика (например, email‑рассылка);utm_medium— тип трафика (например, баннер);utm_campaign— название рекламной кампании;utm_term— ключевое слово (если применимо);utm_content— дополнительная информация о контенте (например, конкретный баннер).
Аналитик SOC использует специальные ресурсы для проверки ссылок, доменов, а также IP‑адресов, в которые резолвятся нужные домены. Некоторые мы приведем в следующих разделах статьи. Ссылки, как и вложения, могут быть проверены в песочницах.
Переходим к самой интересной для начинающих аналитиков части статьи — инструментарию при работе с фишинговыми письмами.
EML analyzer
EML analyzer — приложение для анализа писем (EML- и MSG‑файлов). Функциональные возможности приложения позволяют:
- проанализировать заголовки письма;
- проанализировать тело письма;
- найти индикаторы компрометации (URL‑адреса, домены, IP‑адреса) из текста письма;
- определить, содержат ли вложения подозрительные OLE‑объекты;
- проверить наличие вложений и загрузить их;
- проанализировать вложения в открытых песочницах типа ANY.RUN или Hybryd Analysis, поискать на VirusTotal (поиск осуществляется по хеш‑сумме).
На какие поля стоит обращать внимание при анализе:
-
Verdicts — вердикты SpamAssassin и oleid:
- SpamAssassin — почтовый фильтр, использует байесовскую фильтрацию, обработку DNSBL, Sender Policy Framework, DomainKeys, DKIM, Razor и другие методы распознавания спама. С помощью него можно легко определить подделку IP‑адреса.
- oleid — скрипт для анализа OLE‑файлов, таких как документы MS Office, позволяющий обнаружить определенные характеристики, которые обычно встречаются во вредоносных файлах. Позволяет обнаруживать:
- тип файла OLE по его внутренней структуре (например, MS Word, Excel, PowerPoint и т. д.);
- макросы VBA;
- встроенные flash‑объекты;
- встроенные OLE‑объекты;
- шифрование MS Office.
- Headers — все рассмотренные в разделе «Признаки фишингового письма» заголовки могут быть полезными. Можно получить адрес отправителя, через какие почтовые серверы прошло письмо. Есть возможность проверить, что проставлено в поле
In‑Reply‑To(также позволяет понять, подделан ли адрес отправителя, путем сравненияFromиIn‑Reply‑to). Результаты SPF и DKIM.
Bodies — текст письма отображается в поле Content. Также EML Analyzer в отдельные поля выводит все ссылки, доменные имена, IP‑адреса из текста письма.
Attachments (Filename, Hash) — здесь отображается информация для каждого вложения под номерами (#1, #2, #3 и т. д.). Нужно обратить внимание на имя вложения и его хеш. Также аналитик может загрузить вложение на компьютер для дальнейшего анализа (кнопка download).
Публичные песочницы (ANY.RUN, Triage, Hybrid Analysis и т. д.)
Многие организации, особенно крупные, используют в качестве одного из средств защиты информации песочницы. Чтобы выявить вредоносные программы, песочницы запускают подозрительный объект в виртуальной среде и проверяют, представляет ли он угрозу. Песочница позволяет проводить первичный анализ и сбор данных о поведении вредоносного ПО. Это помогает аналитику ускорить процесс и определиться с идеями для проведения более глубокого анализа.
Как уже было сказано выше, публичные песочницы обычно не применяют в корпоративной среде. Аналитики используют локально развернутые песочницы, чтобы избежать утечки конфиденциальной информации.
Риски при анализе писем в онлайн‑песочницах:
- При недостаточном обезличивании могут утечь данные из цепочки пересылаемых сообщений и подписи письма. Например, когда сотрудник пересылает подозрительное письмо, в него автоматически добавляется подпись, которая обычно содержит Ф. И. О., должность сотрудника, контактные данные.
- Конфиденциальная информация может содержаться во вложениях, т. к. на проверку могут быть загружены и рабочие документы.
- В общий доступ могут утечь данные об используемом в компании ПО, внутренних ресурсах и т. д.
Чтобы продемонстрировать основные функциональные возможности, расскажем про некоторые публичные песочницы, например ANY.RUN, Hybrid Analysis, Triage.
Все они предназначены для анализа вредоносных файлов в режиме реального времени. Платформы позволяют загружать подозрительные файлы или URL‑адреса и наблюдать за их поведением в изолированной среде. Hybrid Analysis также позволяет проверять подозрительные файлы с использованием нескольких антивирусных движков.
Проанализируем вредоносное вложение из приведенного выше письма с темой «Досудебная претензия» в Hybrid Analysis. Определенного перечня полей, которые точно позволят сделать вывод, нет, а критериев вредоносности при динамическом анализе довольно много, и они разнятся от случая к случаю. Наметим основные моменты, на которые чаще всего приходится обращать внимание.
Первым делом аналитик смотрит на структуру файла, его формат и хеш‑сумму (хеш‑сумму файла можно использовать для поиска готовых отчетов в других системах).
Так, например, будет виден вредоносный файл, который выглядит как PDF, однако является исполняемым файлом.
Большинство песочниц предоставляют снимки экрана, сделанные во время выполнения файла в виртуальной среде. Это позволяет узнать содержимое файла, то, как он выглядит для пользователя.
Так, в этом случае мы видим, что открывается пустой документ, в котором даже нет никакого маскировочного содержания.
Еще один важный аспект — анализ сетевой активности: DNS‑запросов, сетевых соединений, HTTP‑запросов.
На этапе проверки сетевой активности аналитик может получить много дополнительной полезной информации. Смена IP‑адресов и доменных имен чуть сложнее для злоумышленника, чем смена хеш‑суммы вредоносного файла. Поэтому иногда на этом этапе аналитик уже может связать активность с какой‑то вредоносной кампанией или конкретной группировкой.
Следующий шаг — анализ поведения вредоносного файла, проверка сработавших YARA- и Sigma‑правил, объектов, к которым обращается файл во время запуска в изолированной среде, измененных ключей реестра, запущенных процессов. Не будем описывать это в рамках статьи, поскольку тема очень объемная. Рассмотрим ее в материале, который будет посвящен песочницам.
А пока обратим внимание на итоговый вердикт и обнаруженные паттерны поведения вредоноса.
Анализируемый файл — вредоносный. При его открытии и включении содержимого с сайта ecols[.]ru загружается файл gogo.rtf, в котором записан вредоносный VBA‑скрипт, запускающий PowerShell‑скрипт с Base64‑командой. Последний предназначен для запуска Cobalt Strike Stager. Это компактный загрузчик, который используется в многоступенчатых кибератаках для установки соединения с командным сервером, доставки и последующего запуска более крупных вредоносных модулей.
Вердикт песочницы не всегда является 100%‑й гарантией, что файл не является вредоносным. Злоумышленники тоже не стоят на месте и учатся обходить песочницы. Так, после запуска загрузчика должно происходить обращение к С2‑серверу для скачивания вредоносной нагрузки. Но если страна или организация, в которой был запущен загрузчик, не интересует атакующих или если загрузчик был запущен в виртуальной среде, то загрузка вредоносного ПО не происходит. В таком случае подозрительной активности во время анализа файла в песочнице не наблюдается. При этом если загрузчик запустит пользователь из определенной страны или организации, то скачивается вредоносная нагрузка, которая приводит к компрометации.
VirusTotal
Этот ресурс позволяет получить информацию о вердиктах множества антивирусных движков, результаты динамического и статического анализа файла. Есть поиск по хеш‑сумме (как SHA256, так и MD5), URL, IP‑адресу, домену.
Приведем небольшое описание каждой из вкладок:
- Details — отображает дополнительную информацию о проверяемом объекте. Например, для файла Microsoft Office здесь будут перечислены импортируемые библиотеки, VBA-скрипты, обнаруженные в макросах документа, и другая информация, относящаяся к типу файла. Аналогичным образом в этом разделе также записываются метаданные VirusTotal, такие как даты первой и последней отправки, имена загруженных файлов и т. д.
- Relations — содержит информацию о доменах, IP‑адресах, с которыми взаимодействовал загруженный файл, о связанных файлах, а также файлах, которые были удалены во время анализа исходного. При анализе домена отображаются все поддомены, результаты Passive DNS и файлы, которые загружены на VirusTotal и взаимодействовали с указанным доменом. В нашем примере видим, что с данным доменом взаимодействовало множество файлов, классифицированных как вредоносные.
- Behavior — содержит результаты динамического анализа загруженного файла в песочницах (CAPE Sandbox, Zenbox и т. д.). На этой вкладке можно найти сработавшие Sigma‑правила, URL, к которым обращается файл во время запуска в изолированной среде, измененные ключи реестра, запущенные процессы. Также доступен список использовавшихся техник, тактик и процедур по MITRE ATT&CK.
- Community — содержит комментарии, оставленные участниками сообщества VirusTotal. Из интересного: на этой вкладке можно найти ссылки на отчеты публичных песочниц.
Инструменты и ресурсы для анализа писем и IoC
В сети есть множество ресурсов для проверки SPF‑записей, куда аналитик может вбить IP‑адрес отправителя письма из логов и домен отправителя. Например, MXToolbox, SPF‑Record.
Также SPF‑запись можно проверить вручную, запустив команды из консоли, например:
nslookup -type=txt example.ru dig example.ru txt
Если SPF‑запись существует, в ответ получим, например, v=spf1 ip4:1.1.2.2/28 ~all. Указанную подсеть остается сравнить с имеющимся адресом отправителя письма. Если в выводе команды SPF‑записи не обнаружено, значит, либо ее не существует, либо это произошло в результате проблем с ее получением.
Проверить правильность записи DMARC можно также через MXToolbox или через консоль с помощью nslookup или dig.
nslookup -type=txt _dmarc.example.ru dig txt +short _dmarc.example.ru
В выводе команд получим что‑то похожее на v=DMARC1; p=quarantine; sp=none; rua=mailto:postmaster@example.ru; ruf=mailto:postmaster@example.ru; fo=1.
v— указывает на то, что запись получена как запись DMARC. Это должен быть первый тег в списке.p— политика применения к электронным письмам, не прошедшим проверку DMARC. Допустимые значения: «нет», «карантин» или «отклонить».sp— запрошена политика почтового получателя для всех поддоменов. Допустимые значения: «нет», «карантин» или «отклонить».rua— адреса, на которые следует отправлять обратную связь.ruf— адреса, на которые следует отправлять информацию о сбоях при отправке сообщений.fo— предоставляет запрошенные параметры для создания отчетов о сбоях. Допустимые значения — любая комбинация символов01ds, разделенных знаком:.
AbuseIPDB
AbuseIPDB — открытый проект, позволяющий зарегистрированным пользователям пополнять базу данными по IP‑адресам с вредоносной и нежелательной активностью. Здесь можно проверить IP‑адреса и доменные имена.
Карточка IP‑адреса содержит:
- информацию по уровню достоверности (основан на отчетах зарегистрированных пользователей);
- комментарии по обнаруженной активности с конкретного адреса;
- категорию активности;
- Whois — информацию об IoC.
urlscan.io
urlscan.io — средство, которое позволяет пользователям сканировать и анализировать ссылки для определения потенциальных угроз безопасности и рисков, связанных с этими URL‑адресами.
В отчете содержится:
- краткая информация по IP‑адресу, домену и SSL‑сертификатам;
- скриншот отображения содержимого URL в песочнице;
- обнаруженные технологии реализации сайта;
- вердикты антивирусных вендоров;
- история предыдущих сканирований URL;
- список структурно похожих сайтов;
- история HTTP‑запросов на URL;
- поведенческий анализ содержимого URL;
- идентификаторы URL (являются IoC, если подтверждена вредоносная активность).
Итак, аналитик сделал вывод, что письмо является вредоносным. Что же дальше?
Теперь нужно определить индикаторы компрометации (IoC) для поиска потенциально зараженных хостов, дальнейшего расследования и реагирования. То есть все, что может быть заблокировано: например, загрузка документа с определенной хеш‑суммой — средствами АВПО, обращение к IP‑адресу или доменному имени — с помощью межсетевого экрана на периметре.
Возможные IoC для фишинговых писем:
- ссылки из письма;
- названия и хеш‑суммы файлов из вложений;
- непосредственно email отправителя письма, а также домен и его IP‑адрес.
Также перед аналитиком стоит задача сопоставить полученные индикаторы и предположить их принадлежность к семейству ВПО, к кибергруппировке. Безусловно, схожесть IoC известной вредоносной кампании и только что обнаруженной атаки не может служить достаточным основанием для атрибуции, но она всегда будет полезной зацепкой для дальнейшего расследования и реагирования.
Приведем тезисно план действий и список мер, поскольку он будет отличаться для каждого конкретного случая и для каждой организации.
- Как и при любом реагировании, локализовать инцидент и определить его масштаб: составить список получателей вредоносных писем, потенциально затронутых устройств и учетных записей.
- Уведомить пользователей о фишинге и выяснить, какие действия они выполняли с письмом (переходили по ссылкам, открывали вложения, вводили данные).
- Если пользователь не взаимодействовал с письмом, достаточно заблокировать связанные с атакой адреса и домены (пункт 3).
- Если пользователь открыл вложение, перешел по ссылке или ввел свои данные, нужно ограничить доступ с его устройства. Если есть EDR, необходимо изолировать устройство (сетевой карантин), если нет — ограничить сетевую активность через NAC, межсетевые экраны или сегментацию сети. Дополнительно стоит ограничить доступ учетной записи к критическим ресурсам (AD, VPN, корпоративные сервисы), завершить активные сессии и отозвать токены доступа.
- Устранить последствия: проверить устройство средствами антивирусного ПО, удалить вредоносные файлы и следы их активности, провести поиск следов закрепления или подозрительных процессов, сменить пароли пользователей, отозвать активные сессии. Если есть сомнения в чистоте системы, лучше ее переустановить.
- Заблокировать все выявленные индикаторы компрометации на уровне инфраструктуры: IP‑адреса, URL, доменные имена (FQDN), адрес и домен отправителя, хеши вложений, обновить правила на почтовом шлюзе, прокси, межсетевом экране и других средствах защиты.
На этапе постанализа инцидента важно сформировать список рекомендаций по доработке системы защиты. Так, после фишинговой атаки он может включать в себя следующие меры:
- Обратить внимание на защиту почты. Лучше использовать решения для фильтрации писем (например, BI.ZONE Mail Security), которые проверяют вложения, ссылки и анализируют письма на нескольких уровнях. Стоит ограничить типы вложений и блокировать потенциально опасные файлы: .exe, .scr, .dll и т. д.
- На почтовом шлюзе настроить SPF, DKIM и DMARC, чтобы отсекать письма с подмененным отправителем и снижать количество фишинга, доходящего до пользователей.
- Включить фильтрацию на уровне DNS- и веб‑трафика, чтобы пользователи не могли перейти на вредоносные или фишинговые сайты.
- На рабочих станциях использовать EDR (например, BI.ZONE EDR). Такие решения помогают вовремя заметить подозрительную активность и быстро среагировать: изолировать устройство или остановить вредоносные процессы.
- Для защиты учетных записей включить многофакторную аутентификацию, особенно для почты, VPN и других критических сервисов. Даже если пароль украдут, без второго фактора авторизоваться будет намного сложнее. Настроить парольную политику: применять сложные и уникальные пароли, без повторного использования.
- Проводить мониторинг: собирать логи, отслеживать подозрительную активность, использовать SIEM или похожие инструменты, чтобы быстрее замечать атаки.
- Регулярно обучать пользователей. Необходимо показывать, как выглядит фишинг, на что обращать внимание. Благодаря предупреждениям в письмах и учебным фишинговым рассылкам (например, через BI.ZONE Security Fitness) можно проверить киберграмотность.
- Придерживаться принципа минимальных прав: у пользователя должен быть только тот доступ, который ему реально нужен. Если учетную запись скомпрометируют, атакующие будут ограничены в своих возможностях.
По данным нашего исследования Threat Zone 2026, 64% целевых атак на компании из России и стран СНГ в 2025 году начинались с фишинговой рассылки. Проверка писем — не просто рутинная задача, а важная часть киберзащиты организации. Поэтому аналитик SOC должен разбираться в почтовых протоколах, заголовках и атрибутах писем, понимать разницу между проверками SPF и DKIM, уметь пользоваться песочницей и другими инструментами для проверки самих писем и почтовых вложений. Не менее важно знать актуальные методы злоумышленников и способы противостоять им.