Хотя фишинговая рассылка не новый и не единственный метод использования социальной инженерии, она хорошо работает и применима практически всегда. Но для успеха важна каждая деталь, полученная на этапе OSINT, — начиная от непосредственно самих email-адресов и заканчивая принятым в компании стилем корпоративной переписки (как в прямом смысле — оформление текста, так и в переносном — речевые обороты и подписи в письмах).
Если ты планируешь использовать свой IP-адрес или домен после завершения тестирования, не забудь проверить их отсутствие в DNSBL (DNS Black Lists) — это еще один распространенный способ борьбы со спамом. Если собираешься разворачивать выделенный сервер, нужно также заранее проверить свой VDS на профпригодность с помощью этих списков.
Ну а в остальном, как говорится, все зависит от тебя. Доверчивые и не слишком внимательные пользователи — не мамонты, они не вымрут, а потому пентестеры с навыками социальных инженеров отыщут слабое звено в любом, даже самом надежном коллективе.
Тестирование методом социальной инженерии может либо быть отдельным мероприятием (сюда входит проверка осведомленности сотрудников или проверка работы ИТ- и ИБ-службы), либо стать одним из способов проникновения в сеть в рамках внешнего пентеста. Бывает, что заказчик просто захотел исключить возможность проникновения через этот вектор либо это направление оказывается последней надеждой, поскольку тестировщик не сумел попасть в сеть без «помощи» сотрудников заказчика. Какими бы ни были причины, в любом случае необходимо продумать стратегию для социальной инженерии на основе имеющийся информации (полученной от заказчика или собранной на этапе OSINT).
Стратегия атаки может строиться по-разному в зависимости от различных факторов: желания заказчика в принципе проводить сценарии социальной инженерии, наличия ограничений на проведение социнженерии, достаточности информации, собранной на этапе OSINT. Предположим, что заказчик одобрил сценарий, при котором мы рассылаем нежелательные сообщения по электронной почте — то есть спам. В сегодняшней статье речь пойдет о том, какие проблемы будут ждать при распространении подобных сообщений и как правильно решать эти проблемы, чтобы сообщения дошли до сотрудников с вероятностью, близкой к ста процентам.
Для начала нужно решить, какие вообще векторы атаки применимы к текущей ситуации. Почтовые рассылки в основном используются для двух целей:
Для рассылки электронной почты необходимо как минимум наличие почтового сервера. На самом деле тут возможно два варианта доставки писем в сеть заказчика: изнутри и снаружи.
Под доставкой изнутри подразумевается использование почтового сервера в тестируемой сети (при удачной его компрометации) — но опустим этот вариант, так как специальной подготовки там практически не требуется, по сравнению с рассылкой снаружи. Решив, что почтовый сервер заказчика скомпрометировать не получится, мы приходим к выводу, что нужно либо использовать готовые почтовые сервисы, либо поднимать собственный почтовый сервер и покупать свой домен. Готовые почтовые сервисы плохи тем, что сообщения с них не внушают доверия, к тому же ИТ/ИБ-служба заказчика может не согласиться ослаблять системы защиты для доменов этих служб, поскольку ими пользуется не только тестировщик.
А вот если поднять сервер на своем домене, который очень сильно напоминает домен заказчика, это убьет сразу обоих зайцев: у невнимательных пользователей это может снизить бдительность до нуля, да и пользоваться доменом будем только мы. При этом важно помнить, что технологии не стоят на месте и для подобных вещей давным-давно придуманы антиспам-фильтры.
Итак, на данный момент мы установили для себя следующие цели:
В статье упоминаются некоторые основополагающие для социальной инженерии вещи, но информация не претендует на полноту. Если ты только начинаешь свой путь, то почитай статьи в журнале по соответствующему запросу в поиске (но не ограничивайся только ими). Для новичков особенно хочу отметить статью «Социальная инженерия как часть тестирования на проникновение».
После того как мы определились с атакой, необходимо подготовить нужные для этого инструменты: очертить круг получателей, придумать заголовок письма, его текст и способ, при помощи которого мы будем закрепляться в сети.
Немалую роль в выборе нужного инструмента играет информация, полученная на этапе разведки, — прежде всего список email-адресов сотрудников, используемые ими системы защиты (для тестирования детекта вредоносных вложений) и различные конфигурации инфраструктуры. Последние два аспекта могут помочь как минимум в следующих случаях:
тестирование может проводиться при минимальном содействии со стороны ИТ- и ИБ-персонала: это означает, что в конфигурации систем защиты не будут вносить исключения для наших писем. Информация о конфигурации систем защиты поможет нам узнать, какую стратегию выбрать и как правильно ей следовать;
в случае с доставкой вредоносных вложений, которые, как ты догадываешься, могут активно детектироваться теми самыми системами защиты, нужно знать хотя бы названия используемого ПО. Это уже поможет в тестировании вредоноса и, как следствие, повысит шансы на успех.
Из списка email-адресов надо исключить некоторых пользователей, например выбрав только определенный отдел (или несколько, но разделив при этом фишинговую атаку на этапы с индивидуальным подходом для каждой группы получателей). Лучше исключить из списка ИТ- и ИБ-персонал, который с гораздо большей вероятностью распознает фишинговую рассылку (потому что эти люди технически подкованы) и своевременно предупредит своих коллег. Также неплохо будет персонализировать письмо, то есть писать не обезличенно, а в стиле «Добрый день, ». Рассылку и персонализацию, конечно, надо будет автоматизировать, но об этом позже, сейчас для будущей автоматизации мы просто составим общий шаблон письма, в который потом подставим имя пользователя, его адрес и прочие значения.
Затем нужно собрать информацию, которая придаст письму правдоподобность. Например, узнать, проводятся ли в фирме какие-нибудь внутрикорпоративные мероприятия, или уточнить, с какими клиентами и партнерами компания заказчика активно ведет переписку. В общем, те вещи, с которыми можно связать тему и текст письма.
После этого в ход идет информация, используемая для «шлифовки» письма — стиль переписки сотрудников, их корпоративная подпись и прочее. Надо хвататься за любые сведения — так повысятся шансы на успех.
А теперь важный момент: «шлифовка» письма нужна также и для того, чтобы сообщение меньше всего походило на спам. Спам-фильтры используют несколько показателей, чтобы составить рейтинг письма. Среди прочего анализируется и содержимое, и заголовок. В основе алгоритма анализа содержимого могут использоваться разные, обычно комбинированные способы (искусственный интеллект, жалобы от пользователей, собственные исследования сотрудников почтового сервиса), но цель одна — определить вероятность, что сообщение принадлежит к вредоносной рассылке.
Крупные почтовые сервисы привлекают сложные ноу-хау. Тестируемая нами компания также может использовать коммерческие спам-фильтры (о настройке своего фильтра можно прочитать, например, в статье про Email Security Gateway). О подробностях работы антиспама у атакующего часто не будет никакой информации (в том числе — что он есть), поэтому стоит соблюдать общие советы, как преодолеть спам-фильтры:
С этим все просто: придумываем домен, максимально похожий на домен тестируемой компании. В идеале отличие должно заключаться в одном символе и замена должна быть малозаметной (например, замена o на 0 или замена на ту же букву с другим кодом в кодировке Unicode). Если с фантазией туго или у тебя нет времени даже обдумать имя домена, то можешь использовать инструмент catphish. Заодно он проверит доступность генерируемых доменов. После выбора домена и проверки его доступности надо купить его у твоего любимого регистратора. В настройках зоны необходимо добавить MX-запись (например, mx.yourdomain.com), а для нее, в свою очередь, A-запись с указанием IPv4-адреса, на котором в будущем мы поднимем почтовый сервер. Также нужно добавить PTR-запись, потому что ее отсутствие может снизить рейтинг письма.
Следующая цель — подготовка инфраструктуры для рассылки, то есть почтового сервера. Если быть точнее, то необходим как минимум SMTP-сервер для отправки писем. Также неплохо бы завести POP3/IMAP-сервер на случай, если придется общаться с пользователями дальше. Можешь поднять свой любимый почтовик, но чаще всего для этих целей используют связки exim + dovecot или postfix + dovecot. Это отличный выбор, если ты ни разу не настраивал свой сервер, потому что в Сети можно найти кучу статей по настройке этих серверов и решению проблем, возникающих при их конфигурировании. Сейчас же поговорим о том, как с готовым почтовым сервером не угодить в спам.
Помимо содержимого письма, есть и другие индикаторы добропорядочности почтовых сообщений. Анализ содержимого может принести какие-то результаты, но антиспам-фильтры считают, что сам администратор почтового сервера также должен доказать легальность отсылаемых писем. Можно усыпить бдительность фильтров, добавив пару ресурсных DNS-записей: SPF и DKIM.
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 (DomainKeys Identified Mail) — это метод, помогающий аутентифицировать электронные сообщения. Если быть более точным, то DKIM позволяет серверу-получателю убедиться, что письмо было отправлено действительно с того домена, который указан в заголовках. Работает метод на асимметричной криптографии, и его суть в том, что электронное сообщение подписывается ЭЦП, открытый ключ должен быть связан с доменом отправителя и быть доступным для всех желающих. Для этих целей тоже идеально подходит DNS. А принимающий сервер затем будет проверять ЭЦП с помощью открытого ключа. На картинке ниже показана схема работы DKIM.
На этой схеме происходит следующее.
Эта упрощенная схема приведена просто, чтобы понимать общий процесс, за подробностями можешь снова обратиться к документу 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.
Есть компании, предлагающие так называемую защиту бренда. В эту услугу обычно входит защита от фишинга, то есть защита компании от действий, при которых может пострадать ее репутация. Обычно под этим подразумевается:
Подобные компании также предлагают для браузеров расширения, которые неоднозначно намекают пользователю об опасности того или иного сайта. В MS Edge, например, совместная работа разных веб-сервисов и фильтра SmartScreen может привести к тому, что на определенный сайт, считающийся «потенциально фишинговым», будет невозможно зайти.
Слово «потенциально» здесь используется потому, что от подобных блокировок могут пострадать и вполне легитимные сайты.
Такие расширения выпускаются для разных браузеров, но, помимо этого, и сами браузеры (например, Firefox) имеют механизмы защиты, основанные на отзывах и рейтингах. Не исключено, что будут совершенствоваться и использоваться разные сервисы для мониторинга фишинговой деятельности.
Чтобы обойти все эти ловушки, придерживайся следующих правил:
Если ты решил подготовить вредоносы для закрепления в сети, то тут тоже есть несколько важных нюансов:
Конечно, это не дает стопроцентной гарантии успеха, потому что политики систем защиты могут быть настроены чересчур параноидально, но как минимум увеличит вероятность, что твое письмо не будет заблокировано или отправлено в спам.
Итак, мы составили письмо, подготовили список рассылки, подняли и настроили сервер. Что дальше?
Теперь надо это дело автоматизировать. Можно написать скрипт для командной строки, который будет использовать 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.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…