фишинговая рассылка

Что такое фишинговая рассылка и как это устроить!

Хотя фишинговая рассылка не новый и не единственный метод использования социальной инженерии, она хорошо работает и применима практически всегда. Но для успеха важна каждая деталь, полученная на этапе OSINT, — начиная от непосредственно самих email-адресов и заканчивая принятым в компании стилем корпоративной переписки (как в прямом смысле — оформление текста, так и в переносном — речевые обороты и подписи в письмах).

Если ты планируешь использовать свой IP-адрес или домен после завершения тестирования, не забудь проверить их отсутствие в DNSBL (DNS Black Lists) — это еще один распространенный способ борьбы со спамом. Если собираешься разворачивать выделенный сервер, нужно также заранее проверить свой VDS на профпригодность с помощью этих списков.

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

фишинговая рассылка

Зачем нужны фишинговые рассылки

 

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

Тестирование методом социальной инженерии может либо быть отдельным мероприятием (сюда входит проверка осведомленности сотрудников или проверка работы ИТ- и ИБ-службы), либо стать одним из способов проникновения в сеть в рамках внешнего пентеста. Бывает, что заказчик просто захотел исключить возможность проникновения через этот вектор либо это направление оказывается последней надеждой, поскольку тестировщик не сумел попасть в сеть без «помощи» сотрудников заказчика. Какими бы ни были причины, в любом случае необходимо продумать стратегию для социальной инженерии на основе имеющийся информации (полученной от заказчика или собранной на этапе OSINT).

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

 
 

Этап 0. Постановка целей

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

  • с помощью текста письма и полей для ввода (например, на фишинговом сайте или в программе, имитирующей внутрикорпоративное ПО) заставить пользователя выдать конфиденциальную информацию, не вызвав при этом подозрений;
  • заставить пользователя скачать файл (из письма, с сайта, торрента) и что-то с ним сделать (например, запустить приложение, открыть в Word документ и включить макросы), также не вызвав при этом подозрений. Скачиваемый вредоносный файл при этом может как эксплуатировать уязвимости в системе пользователя, так и просто быть стилером.

Для рассылки электронной почты необходимо как минимум наличие почтового сервера. На самом деле тут возможно два варианта доставки писем в сеть заказчика: изнутри и снаружи.

Под доставкой изнутри подразумевается использование почтового сервера в тестируемой сети (при удачной его компрометации) — но опустим этот вариант, так как специальной подготовки там практически не требуется, по сравнению с рассылкой снаружи. Решив, что почтовый сервер заказчика скомпрометировать не получится, мы приходим к выводу, что нужно либо использовать готовые почтовые сервисы, либо поднимать собственный почтовый сервер и покупать свой домен. Готовые почтовые сервисы плохи тем, что сообщения с них не внушают доверия, к тому же ИТ/ИБ-служба заказчика может не согласиться ослаблять системы защиты для доменов этих служб, поскольку ими пользуется не только тестировщик.

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

Итак, на данный момент мы установили для себя следующие цели:

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

В статье упоминаются некоторые основополагающие для социальной инженерии вещи, но информация не претендует на полноту. Если ты только начинаешь свой путь, то почитай статьи в журнале по соответствующему запросу в поиске (но не ограничивайся только ими). Для новичков особенно хочу отметить статью «Социальная инженерия как часть тестирования на проникновение».

 

Этап 1. Изготавливаем стрелы

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

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

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

  • в случае с доставкой вредоносных вложений, которые, как ты догадываешься, могут активно детектироваться теми самыми системами защиты, нужно знать хотя бы названия используемого ПО. Это уже поможет в тестировании вредоноса и, как следствие, повысит шансы на успех.

Из списка email-адресов надо исключить некоторых пользователей, например выбрав только определенный отдел (или несколько, но разделив при этом фишинговую атаку на этапы с индивидуальным подходом для каждой группы получателей). Лучше исключить из списка ИТ- и ИБ-персонал, который с гораздо большей вероятностью распознает фишинговую рассылку (потому что эти люди технически подкованы) и своевременно предупредит своих коллег. Также неплохо будет персонализировать письмо, то есть писать не обезличенно, а в стиле «Добрый день, ». Рассылку и персонализацию, конечно, надо будет автоматизировать, но об этом позже, сейчас для будущей автоматизации мы просто составим общий шаблон письма, в который потом подставим имя пользователя, его адрес и прочие значения.

Затем нужно собрать информацию, которая придаст письму правдоподобность. Например, узнать, проводятся ли в фирме какие-нибудь внутрикорпоративные мероприятия, или уточнить, с какими клиентами и партнерами компания заказчика активно ведет переписку. В общем, те вещи, с которыми можно связать тему и текст письма.

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

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

Крупные почтовые сервисы привлекают сложные ноу-хау. Тестируемая нами компания также может использовать коммерческие спам-фильтры (о настройке своего фильтра можно прочитать, например, в статье про Email Security Gateway). О подробностях работы антиспама у атакующего часто не будет никакой информации (в том числе — что он есть), поэтому стоит соблюдать общие советы, как преодолеть спам-фильтры:

  • гугли каждый раз список слов, часто встречающихся в спаме, потому что такие списки могут обновляться. Старайся не использовать эти слова в письме;
  • не злоупотребляй знаками препинания (особенно идущими подряд);
  • не пытайся сделать письмо «разнообразным», иными словами — не используй разные сочетания размеров шрифта, цветов текста, стилей, слова, написанные в верхнем регистре. Короче, старайся не украшать текст подобными выкрутасами без необходимости (исключением может быть, например, соответствие стилю корпоративной переписки);
  • не используй множество ссылок в письме, особенно на разные домены;
  • если вставляешь ссылки, то не укорачивай их;
  • не добавляй слишком много изображений без необходимости;
  • письмо не должно быть пустым и содержать только вложения;
  • не используй leet-стилистику текста;
  • если письмо включает ссылки на сайт с вредоносным содержимым, то не прикрепляй ссылку на файл напрямую — системы могут оповестить ИТ- или ИБ-персонал, и атака сойдет на нет при должной реакции этих сотрудников;
  • хорошенько подумай перед тем, как вкладывать вредонос напрямую в письмо. Даже если он будет запакован в архив и зашифрован, это не гарантирует успех — в системах защиты может использоваться политика не пропускать входящие зашифрованные файлы с чужих почтовых доменов;
  • старайся не вкладывать в сообщения файлы больших размеров. Размер самого письма тоже должен быть небольшой;
  • мониторь требования популярных почтовых сервисов к рассылкам. Например, требования Мейла, Яндекса и Гугла;
  • подумай, насколько правдоподобным показалось бы это письмо, если бы оно пришло тебе;
  • не лишним будет воспользоваться сервисами наподобие mail-tester, чтобы проверить рейтинг письма.
 

Этап 2. Изготавливаем лук

 

Выбираем домен

С этим все просто: придумываем домен, максимально похожий на домен тестируемой компании. В идеале отличие должно заключаться в одном символе и замена должна быть малозаметной (например, замена o на 0 или замена на ту же букву с другим кодом в кодировке Unicode). Если с фантазией туго или у тебя нет времени даже обдумать имя домена, то можешь использовать инструмент catphish. Заодно он проверит доступность генерируемых доменов. После выбора домена и проверки его доступности надо купить его у твоего любимого регистратора. В настройках зоны необходимо добавить MX-запись (например, mx.yourdomain.com), а для нее, в свою очередь, A-запись с указанием IPv4-адреса, на котором в будущем мы поднимем почтовый сервер. Также нужно добавить PTR-запись, потому что ее отсутствие может снизить рейтинг письма.

 

Почтовый сервер

Следующая цель — подготовка инфраструктуры для рассылки, то есть почтового сервера. Если быть точнее, то необходим как минимум SMTP-сервер для отправки писем. Также неплохо бы завести POP3/IMAP-сервер на случай, если придется общаться с пользователями дальше. Можешь поднять свой любимый почтовик, но чаще всего для этих целей используют связки exim + dovecot или postfix + dovecot. Это отличный выбор, если ты ни разу не настраивал свой сервер, потому что в Сети можно найти кучу статей по настройке этих серверов и решению проблем, возникающих при их конфигурировании. Сейчас же поговорим о том, как с готовым почтовым сервером не угодить в спам.

Помимо содержимого письма, есть и другие индикаторы добропорядочности почтовых сообщений. Анализ содержимого может принести какие-то результаты, но антиспам-фильтры считают, что сам администратор почтового сервера также должен доказать легальность отсылаемых писем. Можно усыпить бдительность фильтров, добавив пару ресурсных DNS-записей: SPF и DKIM.

SPF

SPF (Sender Policy Framework) — это метод, позволяющий администраторам составлять белые списки IP-адресов, с которых отправляется почта. Если вспомнить принципы работы почты и SMTP, то выясняется, что отправитель почты в поле MAIL FROM может указать любой домен (то есть устроить спуфинг). На борьбу с этим и направлен SPF.

Суть метода состоит в том, что любой желающий может получить информацию, связанную с доменом отправителя и содержащую указания о том, кто может отсылать почту, — для этих целей прекрасно подходит DNS. Конфигурирование SPF выполняется следующим образом: администратор почтового сервера добавляет в настройках DNS-зоны ресурсную TXT-запись (к TXT-записи опционально также можно добавить ресурсную SPF-запись, придуманную специально для SPF) в определенном формате, где написано, какие IP-адреса могут использовать домен, связанный с этой записью. После этого принимающий почтовый сервер сверяет IP-адрес отправителя с адресами, указанными в ресурсной записи, и в случае успеха передает письмо дальше. При этом в заголовках письма можно будет увидеть примерно такой заголовок:

Authentication-results: spf=pass

 

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

@yourdomain TXT "v=spf1 ip4:1.2.3.4 -all"` или `yourdomain.com TXT "v=spf1 ip4:1.2.3.4 ~all"

 

  • @yourdomain — указание нижнего домена относительно текущей зоны (то есть если запись добавляется в зону example.ru, то относиться она будет к yourdomain.example.ru). На некоторых хостингах знак @ не указывается — изучай синтаксис в справке хостинга;
  • v=spf1 — версия SPF, на данный момент используется только первая;
  • ip4 — указание IP-адреса хоста для белого списка (прошу заметить: именно ip4, а не ipv4);
  • -all — указание на то, чтобы отклонить письмо. В синтаксисе SPF есть два способа это сделать: тильда указывает на «мягкое» отклонение письма (письмо дойдет, но попадет в спам), а дефис (как в примере) на «жесткое» отклонение.

DKIM

DKIM (DomainKeys Identified Mail) — это метод, помогающий аутентифицировать электронные сообщения. Если быть более точным, то DKIM позволяет серверу-получателю убедиться, что письмо было отправлено действительно с того домена, который указан в заголовках. Работает метод на асимметричной криптографии, и его суть в том, что электронное сообщение подписывается ЭЦП, открытый ключ должен быть связан с доменом отправителя и быть доступным для всех желающих. Для этих целей тоже идеально подходит DNS. А принимающий сервер затем будет проверять ЭЦП с помощью открытого ключа. На картинке ниже показана схема работы DKIM.

Схема работы DKIM
Схема работы DKIM

На этой схеме происходит следующее.

  1. Перед началом работы на почтовом сервере генерируются открытый и закрытый ключи. Закрытый, естественно, сохраняется в надежном месте, а открытый ключ располагается в ресурсной TXT-записи почтового домена.
  2. На сервере настраивается ПО для подписи сообщения при каждой его отправке (можно использовать программу с открытыми исходниками— OpenDKIM).
  3. Каждый раз, когда отправляется сообщение, с помощью закрытого ключа оно подписывается. То есть создается DKIM-подпись, которая вставляется в заголовок сообщения (высчитываются хеши от заголовков и тела сообщения, которые потом шифруются асимметричным алгоритмом шифрования).
  4. Принимающий сервер с помощью открытого ключа проверяет ЭЦП с предыдущего шага, и если все окей, то, скорее всего, сообщение дойдет до получателя.

Эта упрощенная схема приведена просто, чтобы понимать общий процесс, за подробностями можешь снова обратиться к документу RFC 6376.

Если все прошло успешно, то получающая сторона в значении заголовка Authenication-results среди прочего увидит строку dkim=pass.

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

Если настраивать сервер на своем выделенном IP-адресе, то проблем нет, но при настройке почтового сервера на VDS есть определенные нюансы — о них можно почитать в статье про настройку SPF/DKIM (там же можно узнать и про подробности настройки связки Postfix + OpenDKIM). Еще один момент, который стоит обязательно учесть: длина открытого ключа может оказаться слишком большой, а хостинг-провайдеры могут запрещать добавление слишком длинных ресурсных записей. На этот случай OpenDKIM любезно разбивает ключ на несколько частей, заключенных в кавычки.

Есть как минимум два способа обойти эту проблему: добавить несколько последовательных TXT-записей или одну TXT-запись, разбитую на части. В последнем случае символом разбиения служит перенос строки. OpenDKIM весь ключ помещает в круглые скобки, а каждую его часть оборачивает в двойные кавычки и разделяет пробелом. Таким образом, надо удалить кавычки и круглые скобки (некоторые хостинг-провайдеры допускают наличие в DNS-записях круглых скобок), затем весь оставшийся текст с переносами строки поместить в TXT-запись.

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

 

Фишинговый сайт

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

Если ты решил использовать в своей фишинговой компании веб-сайт, то тут также есть пара нюансов.

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

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

  • мониторинг веб-ресурсов компании на предмет дефейса или угона доменного имени;
  • мониторинг сети компании на предмет фишинговых рассылок;
  • мониторинг доменов, сильно похожих на домены компании, и всего, что может быть связано с этими похожими доменами (в первую очередь ищут веб-сайты и почтовые серверы);
  • мониторинг продуктов компании, которые могут позволить злоумышленникам действовать от ее имени (использование динамически подгружаемых изображений, JS-библиотек и прочего).

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

Блокировка потенциально фишингового сайта в браузере MS Edge
Блокировка потенциально фишингового сайта в браузере MS Edge
Блокировка потенциально фишингового сайта в браузере Chrome
Блокировка потенциально фишингового сайта в браузере Chrome

Слово «потенциально» здесь используется потому, что от подобных блокировок могут пострадать и вполне легитимные сайты.

Такие расширения выпускаются для разных браузеров, но, помимо этого, и сами браузеры (например, Firefox) имеют механизмы защиты, основанные на отзывах и рейтингах. Не исключено, что будут совершенствоваться и использоваться разные сервисы для мониторинга фишинговой деятельности.

Чтобы обойти все эти ловушки, придерживайся следующих правил:

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

Отладка полезной нагрузки

Если ты решил подготовить вредоносы для закрепления в сети, то тут тоже есть несколько важных нюансов:

  • тестируй малварь в изолированной сети;
  • при тестировании реакции систем защиты обрубай выход в интернет — иначе сигнатуры твоего вредоноса быстро окажутся в базах антивирусов;
  • не загружай образцы на публичные сервисы вроде VirusTotal;
  • в качестве метода доставки лучше использовать веб-сайт, поскольку передача подобных вещей по почте в открытом виде приведет к стопроцентной неудаче, а зашифрованный архив могут не пропустить системы защиты в сети заказчика.

Конечно, это не дает стопроцентной гарантии успеха, потому что политики систем защиты могут быть настроены чересчур параноидально, но как минимум увеличит вероятность, что твое письмо не будет заблокировано или отправлено в спам.

 

Этап 3. Натягиваем тетиву

Итак, мы составили письмо, подготовили список рассылки, подняли и настроили сервер. Что дальше?

Теперь надо это дело автоматизировать. Можно написать скрипт для командной строки, который будет использовать CLI нашего почтового сервера для отправки писем, но это сродни изобретению велосипеда. Лучше использовать популярные инструменты автоматизации рассылок. Среди бесплатных решений самое популярное — Gophish. Он помогает не только автоматизировать процесс с помощью встроенных скриптов рассылки и шаблонизатора для автоматической подстановки текста в электронное сообщение, но и собирать статистику.

Среди отслеживаемых метрик — открытие письма (в сообщение вставляется невидимое изображение с атрибутом src, указывающим на специальный скрипт на веб-сервере), открытие ссылки. В «Хакере» уже выходила статья про настройку этого инструмента, там нет ничего сложного. Gophish предназначен для рассылки почты через сторонний почтовый сервер, который нужно указать среди параметров, но при этом он не позволяет читать присланную почту (иначе это была бы какая-то смесь почтового недоклиента и фишингового фреймворка).

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

Самое популярное (и бесплатное) решение — это beefXSS, browser exploitation framework (фреймворк для эксплуатации браузера). Суть его работы проста: ты добавляешь на свой фишинговый сайт скрипт, который будет соединяться с поднятым заранее командным сервером. Если все пройдет успешно, то на командном сервере через веб-интерфейс в панели администратора ты сможешь совершить различные действия, начиная от простой разведки (например, узнать открытые порты на хосте клиента и на соседних хостах, выяснить IP-адреса хоста и его соседей) до эксплуатации уязвимостей в браузере. В «Хакере» также выходил мануал по работе с beefXSS.

Стоит учесть пару важных моментов.

Во-первых, если фишинговый сайт работает через HTTPS, а командный сервер beef поднят на HTTP, то современные браузеры не дадут подгрузить на HTTPS-сайт скрипт по протоколу HTTP. Поэтому надо будет сначала включить в конфигурационном файле config.yaml поддержку HTTPS и указать будущее наименование ключа и сертификата. Таким образом, в конфиге должны быть примерно такие строки:

https: 
	enable: true 
	key: "your_key.pem" 
	cert: "your_cert.pem"

 

Во-вторых, для командного сервера beef нужно выделить домен (можно поддомен для уже купленного домена) и снова через letsencrypt выпустить сертификат. Ключ и сертификат при этом нужно будет поместить в папку с beefxss.

Click to rate this post!
[Total: 1 Average: 5]

Специалист в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз. Цель данного блога - простым языком рассказать о сложных моментах защиты IT инфраструктур и сетей.

Leave a reply:

Your email address will not be published.