Введение
Мы уже писали о целевом фишинге (Spear Phishing) в одной из статей, в которой разобрали общие аспекты целевых рассылок электронных писем. В этой статье мы предлагаем подробнее ознакомиться с нашим опытом в тренировочных целевых рассылках, содержащих в себе условно вредоносные вложения.
Как правило, целевые рассылки включают в себя следующие этапы:
- предварительный поиск учетных записей сотрудников в различных источниках данных
- предварительное обучение сотрудников
- обсуждение и утверждение с заказчиком шаблонов рассылаемых писем
- подготовка к рассылке
- целевая рассылка по сотрудникам, прошедшим обучение, и, возможно, сотрудникам, не прошедшим обучение (контрольная группа)
- сбор данных, полученных в результате рассылки в наборы данных
- обработка наборов данных для понимания текущей ситуации
- предложение конкретных рекомендаций для заказчика
- закрепление результатов и повторное обучение сотрудников
В рамках этой статьи мы сосредоточимся на этапе подготовки к целевой рассылке.
Если рассылка проводится в рамках работ, связанных с пентестом и RedTeam, то этап поиска учетных записей сотрудников занимает достаточно большое количество времени и человеческих ресурсов. Далее полученный список учетных записей должен быть сформирован в целевые группы для рассылки, после чего формируются шаблоны писем для каждой группы.
Исходя из специфики работы компании и специфики целевой группы, нужно составить наиболее правдоподобные шаблоны для писем, которые получат сотрудники. Иногда мы прибегаем к шаблонам с «обновлением» какого-либо руководящего документа.
На данном этапе также нужно выбрать какие типы вложений в письма мы будем использовать. По нашему опыту это обычно следующие типы файлов:
- .docx, .doc
- .xlsx, .xls
- .exe
Файлы MS Office имеют преимущество в том, что они привычны для пользователя и их скорее всего откроют, чтобы просмотреть (если спам фильтр не порежет их как вредоносные). Минусы в том, что способов для запуска условно вредоносной нагрузки и организации обратной связи с управляющим сервером не так много:
- макросы
- известные уязвимости (DDE и т.д.)
- SMB (вложенные в файл MS Office по ссылке внешние файлы, документы)
С макросами всё относительно просто, существуют инструменты автоматизации создания таких макросов, ими можно пользоваться с некоторыми доработками. Вложение может быть готово к рассылке за несколько часов или в худшем случае дней, если антивирус, который предполагается установленным у жертвы, “ругается” на нагрузку.
С SMB так же всё достаточно легко, есть инструменты автоматизации процесса, однако необходимо, чтобы у пользователя соблюдалось условие отсутствия блокировки исходящего SMB трафика на 445 порт. Некоторые компании и провайдеры блокируют такой трафик.
Уязвимостей, приводящих к выполнению кода в MS Office не так много, но нужно понимать, что не у всех компаний и не на всех рабочих станциях есть возможность обновить офисное ПО. Если мы знаем, что у какого-то конкретного сотрудника заказчика устаревший набор ПО на компьютере, то можно попробовать задействовать и такие векторы, в надежде, что антивирусное ПО так же не обновлено.
Если бы мы работали на рынке, где распространено другое офисное ПО, как, например, просмотрщик файлов Urdu InPage распространенный в Азии, то мы бы выбрали другие типы файлов для такого офисного приложения и воспользовались известными уязвимостями в нем.
С форматом PDF тоже можно рассматривать несколько вариантов создания нагрузки:
- JS
- известные уязвимости
- SMB (вложенные в файл по ссылке внешние файлы, документы)
В движке просмотрщика PDF существует возможность включения JS кода внутрь документа для большей кастомизации. Это позволяет включить в документ JS код и исполнить его на компьютере пользователя. Этот метод достаточно хорошо детектируется антивирусами и поэтому не очень подходит для наших задач, мы не рекомендуем его использовать. Точно такая же ситуация с известными уязвимостями, антивирусы хорошо детектируют код, приводящий к триггеру уязвимости.
С SMB ситуация менее радужная, чем в MS Office, утечка NetNTLM-хешей в наиболее распространенных Adobe Reader и FoxitReader считается уязвимостью и она была исправлена, например, в Adobe Reader в 2018 году (CVE-2018-4993). Поэтому при подготовке нагрузки в виде PDF нужно рассчитывать на другие просмотрщики PDF документов или сильно устаревшие версии выше обозначенных.
Исполняемые файлы (.exe и др.) имеют плюс в том, что способы связи с организатором рассылки ограничиваются в основном протоколами, разрешенными в компании для компьютеров сотрудников (tcp, udp, http, icmp и т.д.), и в том, что можно собрать достаточно много информации о пользователе, который откроет такой файл. Минусы, естественно, состоят в том, что антивирусное ПО может пометить распространяемый файл как вредоносный и вся рассылка может быть порезана еще на этапе доставки почты антиспам фильтром с интегрированным антивирусным ПО. Дополнительным минусом является то, что современные операционные системы Windows помечают файл, скаченный из интернета, помещая дополнительную информацию в альтернативный поток NTFS, и при запуске файла предлагают пользователю согласиться с запуском приложения.
Почему возникла надобность в собственной разработке программы для тренинговых рассылок?
Все образцы исследованного нами свободного ПО для организации рассылок (SpearPhisher, King Phisher, Gophish) не предлагают автоматическое создание условно вредоносной нагрузки в виде исполняемого файла по шаблону, встроенному в ПО. Они оставляют это, так сказать, для «упражнения любознательного читателя».
Разработка
Подойдем к разработке ПО с описания функций которые оно должно выполнять.
Основной функцией ПО будет идентификация пользователя целевой компании, который «проглотит приманку» и запустит приложение, поэтому в первую очередь нужно определиться с данными, которые должно собрать приложение, запущенное на компьютере. Насколько полный это набор, покажет практика, если вы считаете, что мы выбрали не все идентификаторы, позволяющие установить пользователя из целевой компании, напишите нам об этом в комментариях.
Для себя мы определили эти данные так:
- имя пользователя
- имя компьютера
- LOGONSERVER
- внешний и внутренний IP адрес (если возможно)
Затем определим по каким каналам связи мы будем отдавать собранные данные. Мы выбрали два:
- HTTP
- DNS
HTTP выбрали с целью проверки доступа к интернету из сети, где запускают наше ПО. Если для доступа к интернету не требуется использование прокси или иных условий, то это повышает риск заражения организации.
DNS был выбран как резервный канал передачи данных, поскольку достаточно редко в компании ограничивается доступ к DNS серверам и трафику, который проходит через DNS канал. В DNS мы выбрали А-записи как наиболее вероятный канал утечки информации.
Также не стоит забывать о том, что на целевом компьютере может быть установлено антивирусное ПО, HIPS. И это также накладывает на разработку ПО свой отпечаток. Необходимо добавить в цикл разработки ПО пункт, сопряженный с тестированием детектирования ПО популярными антивирусами. Для себя мы определили минимум тестирования как один антивирус — Defender, поскольку он является включенным в сборку Windows 10 по умолчанию.
Для сбора данных, полученных по DNS каналу, мы специальным образом настроили А-записи у регистратора нашего домена. Суть настроек сводится к тому, чтобы все запросы на поддомены нашего домена отправлялись на наш NS, где мы просто установили tcpdump на порт 53. Это минимальные усилия, необходимые для регистрации данных, отправленных нашим приложением.
Интересные моменты на пути к релизу
Оказалось, что в пакеты, предназначенные для передачи А-записей по DNS каналу, не стоит включать не ASCII символы. А значит, что имена пользователей или компьютеров, записанные в кириллице, фарси, и т.д., превращаются в каракули :) Мы решили выбрать кодирование символов в кодировке base32, поскольку все символы, входящие в нее, могут быть использованы для передачи по DNS в А-записях. Хотя при поиске существующих решений мы натыкались на тот факт, что использование base64 так же приемлемо для большинства современных DNS серверов. Также данные длиннее 63 символов нужно разбивать на несколько пакетов или поддоменов. Конечно, достаточно редка такая ситуация, при которой имя пользователя или имя компьютера будет длиннее 63 символов, но, если в дальнейшем захочется проводить эксфильтрацию большего количества данных, чем мы указали в пожеланиях к программе, придется учесть этот факт.
Для определения внешнего IP адреса приходится полагаться либо на неподконтрольные ресурсы, что также может повлиять на качество собираемых результатов, если такой ресурс заблокирован в целевой компании или регионе, либо полагаться на собственные ресурсы. Поэтому по договоренности с Заказчиком нужно использовать для эксфильтрации данных внешние хосты, которые не блокируются в сети исследуемой организации, или использовать сервисы из маловероятно блокируемых сетей (Azure, Amazon, DO), полагаясь на удачу.
Поскольку внутренних адресов на целевом компьютере может быть несколько, мы всё же решили сосредоточиться на первом в списке и собирать только его. Данное предположение сделано на основе того факта, что фишинговая воронка скорее всего пройдет обычного сотрудника с обычным компьютером, на котором 1 сетевой адрес.
Тестирование
После запуска нагрузки на целевом хосте получили запросы, пришедшие из ASN, принадлежащей Microsoft во Франции, однако, после этого, через некоторое время информация о запуске нашего приложения начала поступать из ASN стран Азии — Кореи, Китая, Индии. В очередной раз подтвердилось, что современные антивирусные и антифишинговые решения отправляют подозрительные с их точки зрения файлы в свое облако и там прогоняют тесты на собственных виртуальных машинах, чтобы убедиться во вредоносности этих файлов.
Идентификаторы виртуальных машин из облака MS все типовые, произвольное имя компьютера, такое же имя пользователя. А вот идентификаторы компьютеров из Азии представляют собой более человекочитаемые данные (Computer, Admin-PC, USERPC и т.д.). С одной стороны, это может означать, что наши файлы открывали из локации, спрятанной за VPN, с другой стороны то, что антивирусные компании делятся свежими файлами друг с другом.
Поскольку мы создавали не персонализированные сборки приложений, отследить какие конкретно файлы были отправлены в облако не представилось возможным. Может быть, все файлы с рассылки, а возможно, только те, что были отправлены первыми. С высокой вероятностью, в будущих релизах мы продумаем механизм патчинга для каждого аттачмента и будем отправлять приложение с идентификатором пользователя, которому адресовано письмо — так будет проще отслеживать файлы, которые проверяются на облачных виртуальных машинах. Это необходимо для исключения false positive данных, полученных сервером, собирающим информацию.
Заключение
Успеху фишинг-атак способствует низкий уровень осведомленности пользователей о правилах работы с почтой в компании. Основной защитой от массового фишинга остаются спам-фильтры, но это не спасает от spear phishing (таргетированного фишинга).
На мой взгляд, не стоит списывать со счетов значимость социальной инженерии в контексте работ, связанных с тестированием на проникновение. Человеческий фактор всегда будет лазейкой для злоумышленников в системе безопасности даже самой крупной компании. В случае если даже незначительный процент сотрудников запустит вредоносное ПО в сети организации (особенно это касается привилегированных сотрудников — ТОП-менеджмента, системных администраторов), то это будет означать компрометацию всей компании.
Терещенко Вадим
Старший специалист направления анализа защищенности, Акрибия