В ИБ-комьюнити сформировалось представление о том, что социальная инженерия (SE) — это что-то гуманитарное и легкореализуемое: «Пару часов изучаем статьи из Google, ищем репозитории на GitHub — и готово!». На самом деле целевой фишинг — это симбиоз самых разных hard- и soft-навыков, технологий и масса сценариев реализации целевой фишинговой атаки. Чтобы развеять сложившийся миф, нужно погрузиться в тренды социальной инженерии. Само собой, в рамках одной статьи мы не сможем подробно описать все возможные механизмы SE, поэтому кратко пройдемся по самым интересным.

Почему вложения — моветон

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

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

Во-вторых, если blacklist не настроен или его удалось обойти, почтовый антивирус может обнаружить полезную нагрузку в статике или выдать false positive.

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

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

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

Также снижается эффективность фишинга с документами Microsoft Office. Это происходит на фоне следующих действий Microsoft:

1. Октябрь 2021 г.: блокировка макросов Excel 4.0 (XML-макросов) по умолчанию.

2. Февраль 2022 г.: начало блокировок VBA-макросов в полученных из интернета документах Microsoft Office, также по умолчанию.

В результате этих блокировок использование офисных документов с макросами в фишинговых рассылках значительно сократилось — в силу снижения их эффективности.

Кроме того, в марте 2023 г. в Microsoft уловили тренд на OneNote-векторы и собираются заблокировать возможность взаимодействия со 120 опасными файловыми расширениями. В итоге из интересной опции контейнера для хранения и доставки полезной нагрузки OneNote постепенно превращается в обычный фиолетовый блокнот.

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

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

Ситуация осложняется тем, что в России защита корпоративной почты резко перешла в руки локальных вендоров. К сожалению, песочницы, которые остались на нашем рынке, плохо справляются с анализом ссылок. Чаще всего механизм проверки реализован через контейнер, в котором содержимое HTML-страницы забирается с помощью Wget и отдается на сканирование YARA-правилам. Как результат — снова становятся актуальными старые проблемы и риски. Приведу несколько примеров:

• Оставшиеся на рынке sandbox-решения не умеют работать с векторами Steal Credentials: детектировать фишинговые формы, вводить тестовые учетные данные и блокировать доставку писем с такими ссылками.
• Если ссылка ведет на облачный сервис, на котором хостится полезная нагрузка, песочница просто скачает HTML-страницу.
• Оставшиеся на рынке sandbox-решения не умеют получать доступ к целевой странице с нагрузкой, на которую пользователя перенаправляют после ввода учетных данных, или в тех случаях, где требуется явная пользовательская активность, чтобы получить доступ к нагрузке.
• Сложности в анализе содержимого обфусцированных версий загруженных HTML-страниц. При сильной обфускации кода (например, использовании HTML Smuggling, BitB, BitM) возникают трудности в обнаружении атак, основанных на JavaScript.

Актуальные способы доставки и хранения полезной нагрузки

HTML Smuggling

Это техника скрытной доставки вредоносного ПО, в которой используются легитимные функции HTML5 и JavaScript. Закодированный JavaScript Blob-объект (например, методом Base64) помещается в специально созданный HTML-документ или веб-страницу. Когда атакуемый пользователь открывает HTML-страницу в своем браузере, тот, в свою очередь, декодирует хранимые в ней данные, в результате чего Blob-объект передает полезную нагрузку на узел пользователя.

Таким образом, полезная нагрузка компилируется локально на рабочей станции пользователя в обход стандартных средств защиты сетевого периметра, таких как прокси, IDS/IPS и анализаторы трафика. Они проверяют только подозрительные вложения (например, файлы с расширениями .exe, .zip или .docx) или только трафик. Поскольку вредоносные файлы создаются после того, как HTML-файл загружается на конечной точке через браузер, данные, которые фиксируются такими СЗИ, представляют собой легитимный HTML- и JavaScript-трафик. При этом вариант отключения работы JavaScript на хостах сотрудников является не лучшей идеей — это может остановить бизнес-процессы и работу других легитимных веб-приложений.

Распространенные варианты использования HTML Smuggling:

• Доставка .html-файла на хост в каком-либо контейнере (например, .zip или .zip + .iso), приложенном аттачментом к письму.
• Отправка ссылки на веб-приложение. Жертва переходит по ссылке, и нагрузка компилируется на стороне атакуемого хоста.

Облачные сервисы

Второй актуальный способ хранения и доставки полезной нагрузки связан с облачными сервисами — Yandex.Cloud, Облаком Mail.Ru, Google Диском, Dropbox и др. Схема проста: загружаем нужный файл, получаем ссылку и отправляем пользователю. Такой способ, к примеру, использует группировка OldGremlin.

Преимущества подхода:

• Пользователи доверяют ссылкам на знакомые облачные сервисы.
• Заблокировать домены mail.ru, yandex.ru и др. проблематично, а разделегировать невозможно.
• Доступность и простота размещения полезной нагрузки.
• Возможность проходить мимо правил корреляции и радаров средств защиты. Даже если СЗИ зафиксируют условное событие «Сотрудник перешел по ссылке из письма на Mail/Yandex/Google-диск», никто не придаст этому должного значения, пока не произойдет инцидент.

Тем не менее у данного способа существуют и недостатки:

1. Недостаточная операционная безопасность (OPSEC). Хранение полезной нагрузки не на своих мощностях и хостингах, а на сторонних сервисах несет риски для ее «здоровья». Потенциально сами сервисы могут получить доступ к хранимой нагрузке и отправить на анализ антивирусными решениями.
2. Оперативное удаление полезной нагрузки из облачного сервиса. Как-то мы использовали этот способ размещения полезной нагрузки на проекте: при расследовании инцидента специалистами SOC заказчика она была быстро удалена. Из-за этого пользователи, которые получили от нас письма со ссылками на облако с нагрузкой, не могли скачать файлы. В случае хостинга полезной нагрузки на своем сервере такое развитие событий, естественно, невозможно.
3. Предварительное отображение содержимого для пользователей.

WebDAV

Концептуально способы доставки удаленной нагрузки с сервера WebDAV сводятся к необходимости выполнения консольных команд на хосте (User Execution этап). Есть масса User Execution техник — от экзотичных до более распространенных и эффективных.

Из экзотики: в феврале 2023 г. хакеры, распространяющие вредоносное ПО IcedID, использовали URL-файлы для скачивания пользователем .bat-стейджеров, выполняющих CMD-команды по запуску удаленной нагрузки, размещенной на WebDAV-сервере.

Более распространенный и эффективный вариант — использование LNK-файлов для выполнения команды net use и запуска нагрузки, размещенной на сервере WebDAV. Данным способом, например, пользуется в своих атаках APT-группировка OldGremlin.

Преимущества подхода:

1. Готовая реализация сетевого взаимодействия на основе расширенного набора HTTP-команд и автоматическое распознавание корпоративного прокси-сервера (включая аутентификацию) для выхода в интернет.
2. Взаимодействие с WebDAV-сервером выглядит так, будто ОС просто выполняет сетевой запрос.

Недостатки подхода:

1. Возможен долгий процесс подключения виртуального сетевого диска и выполнения консольных команд (в зависимости от ресурсов атакуемого хоста), и все это время пользователь будет видеть CMD-окно, которое он может закрыть.
2. Вся полезная нагрузка, доступная или загружаемая по пути UNC, локально копируется в кэш клиента WebDAV (C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\), что может покрываться мониторингом SOC.
3. Недостаточная операционная безопасность (OPSEC): курсирование трафика через все СЗИ, прокси-серверы, анализаторы внешнего и внутреннего трафика, firewall и NGFW-решения.

Актуальные способы получения начального доступа

Контейнеризация

Kill chain состоит как минимум из двух компонентов — полезной нагрузки и User Execution техники. Все это нужно доставить без лишних браузерных предупреждений в интуитивно понятном виде для атакуемого пользователя. Для этого можно использовать разные виды контейнеризации полезной нагрузки:

1. архивы (RAR, ZIP, Gzip и т. п.);
2. образы дисков (ISO, IMG, VHD, VHDX);
3. CAB-файлы.

Кроме удобной доставки необходимых компонентов, контейнеры могут служить способом обхода технологии Mark-of-the-Web. Она создает альтернативный поток данных (ADS) с именем Zone.Identifier и добавляет к нему правильный ZoneId, чтобы указать, из какой зоны был получен файл. А также отображает предупреждение для пользователя, который хочет осуществить взаимодействие с полученным из интернета файлом.

Примеры обхода технологии Mark-of-the-Web с помощью контейнеров:

1. CVE-2022-41049: когда неправильно генерировался альтернативный поток данных, без добавления в поток Zone.Identifier правильного ZoneId из-за выставленного атрибута для упакованного файла Read-Only, что при извлечении вызывало ошибку Access Denied при попытке Windows выставить ZoneId для файла, полученного из интернета. Это приводило к тому, что разархивированные файлы не помечались как файлы, полученные из интернета, и пользователь мог запускать их без каких-либо предупреждений и в обход технологии SmartScreen.
2. CVE-2022-41091: проблема с проставлением правильного ZoneId файлам в образах диска публично известна давно и эксплуатируется еще со времен Windows 8. Она была связана с тем, что альтернативные потоки данных (ADS) — это функция NTFS, и идентификатор зоны не распространялся на другие типы файловых систем, например FAT32 и UDF. Поэтому MOTW не распространялся на файлы внутри ISO/IMG и других образов дисков.

Техники обхода MOTW будут появляться и дальше. Например, уже существует целое семейство уязвимостей, используемых для обхода проверки цифровой подписи SmartScreen (CVE-2022-44698 и CVE-2023-24880). Microsoft, конечно, выпустили патчи, но здесь остается огромное пространство для исследований, поскольку необходимую ошибку для проверки цифровой подписи можно вызвать и передать в SmartScreen разными способами.

LNK

Если nmap — швейцарский нож пентестера, то LNK — швейцарский нож социального инженера. В основном я сталкиваюсь с кейсами применения LNK-файлов в качестве техники выполнения команд по запуску полезной нагрузки, поэтому отношу их к User Execution техникам. Тем не менее они универсальны и в зависимости от контекста могут использоваться по-разному:

1. User Execution. При взаимодействии запускается нагрузка, доставленная вместе с файлом.
2. User Execution Dropper. При взаимодействии доставляется и запускается нагрузка с удаленного сервера. Либо с помощью EmbedExeLnk и аналогичных техник нагрузка встраивается внутрь LNK, затем извлекается из него и помещается в отдельный файл с последующим запуском.
3. Shortcut Modification. При взаимодействии модифицируются легитимные ярлыки. Например, на запуск браузера с вредоносными расширениями для модификации и перехвата трафика.
4. Persistence. При взаимодействии происходит закрепление в системе с помощью создания LNK в автозагрузке.

На мой взгляд, это самый эффективный и универсальный вид User Execution техники. Используя LNK в своих TTP, можно рассчитывать на единичный запуск файла для выполнения всей логики полезной нагрузки и получения результата, так как защита от LNK-файлов сильно недостаточна в сравнении с угрозой. При этом для конечного пользователя LNK выглядят максимально легитимно, потому что могут мимикрировать под PDF, любые документы Microsoft Office или бинарные файлы.

В качестве примера возьмем Bad Magic APT.

Все гениальное просто:

1. Жертва получает архив с LNK-файлом, в котором находится всего лишь одна команда на запуск размещенного удаленно MSI-дроппера с помощью msiexec.exe.
2. Затем MSI распаковывает и запускает другие дропперы, которые подготавливают систему и загружают основную полезную нагрузку.

Преимущества этого kill chain:

• Возможность эксплуатации LNK на всех Windows-целях. С помощью PS/CMD-команд можно реализовать сложную логику вектора kill chain на User Execution стадии.
• Возможность удаленного и локального запуска MSI.
• LNK позволяет использовать множество LOLBin-техник на User Execution стадии.
• MSI позволяет упаковать в себя все файлы, необходимые для установления обратного соединения с командным сервером.
• У MSI есть функция упорядочивания запуска извлекаемых файлов и возможность выполнения CMD/PS-команд для правильной отработки логики, заложенной в kill chain.
• Большая адаптивность под сценарий письма за счет мимикрирования LNK под легитимные документы и приложения.

MSI

MSI в контексте фишинговых TTP представляет собой универсальный многофункциональный контейнер с возможностью извлечения файлов в нужную директорию и выполнения различных консольных CMD- и PowerShell-команд.

MSI-файлы используют технологию Microsoft COM Structured Storage, которая позволяет им иметь структуру, аналогичную файловой системе компьютера. По сути, это контейнеры со взаимосвязанными таблицами, образующими реляционную базу данных. Таблицы позволяют управлять процессом установки и задавать логику с помощью отдельных действий и их последовательностей.

MSI содержит Main Stream (основной поток), который также называется потоком базы данных (Database Stream). Последний состоит из таблиц, которые образуют реляционную базу данных (то есть связаны между собой для выполнения заложенной логики установки).

Например, в таблицах может храниться следующая информация:

• File Table: содержит полный список исходных файлов с их атрибутами.
• Binary Table: содержит двоичные данные для таких элементов, как растровые изображения, анимации и значки. Двоичная таблица также используется для хранения данных пользовательских действий.
• CustomAction Table: предоставляет средства интеграции пользовательского кода и данных в установку. Источником выполняемого кода может быть поток, содержащийся в базе данных, недавно установленный файл или существующий исполняемый файл.

Другие таблицы содержат информацию о выполняемых пакетах последовательностей установки и выполнения.

Действия делятся на два типа:

Стандартные (Standard Action). Встроенные действия, которые позволяют разработчикам выполнять установку. Например:

1. InstallFiles: извлечь файлы, указанные в таблице File, в целевой каталог установки.
2. InstallFinalize: отмена всех установочных действий и удаление извлеченных файлов с диска.
3. WriteRegistryValues: добавить значение реестра для устанавливаемого ПО.

Пользовательские действия (Custom Action). Позволяют внедрять логику за пределами стандартных действий, запуская во время установки определенные двоичные файлы или скрипты. Например:

1. Исполняемые файлы, хранящиеся в файле MSI.
2. Экспортированные функции из DLL.
3. Скрипты JavaScript или VBS.

Как атакующих, нас интересуют оба типа действий.

Рассмотрим функциональные возможности Custom Action и MSI на примере использования фреймворка WiX для генерации установочных пакетов. Он раскрывает весь потенциал пользовательских действий и позволяет выполнять следующее:

• Сжимать и упаковывать файлы с полезной нагрузкой в .cab-контейнер с помощью Media Element. Контейнер с нашими файлами помещается в Media Table.
• Устанавливать целевой каталог для извлечения файлов из .cab-контейнера с помощью SetDirectory (в терминологии Microsoft — Custom Action Type 51).
• Выполнять консольные CMD/PowerShell-команды и запускать извлекаемые файлы в процессе установки с помощью атрибута ExeCommand пользовательских действий.
• Задавать права для выполнения логики MSI с помощью атрибута InstallPrivileges в Package Element, чтобы при наличии прав администратора все установочные действия выполнялись от привилегированного пользователя.
• Запускать JS/VBS-скрипты с помощью атрибутов Script, VBScriptCall и JScriptCall пользовательских действий.

Используя WiX-фреймворк для комбинации лучших возможностей Standard Action и Custom Action, мы получаем достаточно широкий набор возможностей:

• Упаковка и хранение файлов в MSI разными способами: в Base64 формате внутри Binary-таблицы и в сжатом виде в .cab-контейнере (с помощью Media Element в Media Table).
• Извлечение файлов в директории с помощью InstallFiles и SetDirectory вместе с Custom Action Type 23.
• Выполнение произвольных команд, в том числе по запуску файлов с помощью атрибута ExeCommand.
• Запуск скриптов для изучения системы атакуемого хоста с помощью атрибутов Script, VBScriptCall и JScriptCall.

Также для управления логикой и последовательностью действий при установке существует таблица последовательностей. В ней задаются условия и порядок выполнения стандартных и пользовательских действий.

Приведу пример таблицы последовательностей, задающей логику работы MSI, и кратко объясню взаимодействие таблиц между собой.

В начале установки Windows Installer изучит последовательности действий в InstallExecuteSequence Table. CustomAction1 с последовательностью 2 в InstallExecuteSequence Table перенаправит Windows Installer за инструкциями к CustomAction Table. Движение по заложенной в MSI последовательности действий будет выглядеть следующим образом:

CustomAction Table:

• CustomAction1 с помощью пользовательского действия Custom Action Type 51 инициализирует директорию [%LocalAppData]\vcredist в качестве каталога, в который будут извлечены файлы.
• CustomAction2 с помощью пользовательского действия Custom Action Type 1218 запустит ранее упакованную бинарную нагрузку, которая хранится в Binary Table.

• CustomAction3 с помощью пользовательского действия Custom Action Type 23 извлечет файл Payload.exe из .cab-архива в директорию, инициализированную CustomAction1.

• CustomAction4 с помощью пользовательского действия Custom Action Type 1250 выполнит консольную команду по запуску извлеченного файла Payload.exe при выполнении логики CustomAction3 в директорию, инициализированную CustomAction1.

File Table и Media Table

На основе ключа отношений <file_id1>, указанного в столбце Source, CustomAction Table обратится за информацией к File Table. В ней хранятся имя файла, размер и номер последовательности извлечения этого файла. В свою очередь, File Table на основе номера последовательности извлечения файла в столбце Sequence обратится к таблице Media Table для идентификации нужного .cab-архива, хранящего файл (на базе столбца LastSequence).

Как это происходит?

Каждая запись в File Table представляет собой файл для установки и содержит информацию о его порядке — столбец Sequence. Чем меньше значение Sequence, тем раньше будет установлен файл.

В Media Table содержатся записи о носителях (дисках или .cab-контейнерах) и информация о последовательности файлов (столбец LastSequence) на каждом носителе. Также здесь имеется столбец DiskId, который является идентификатором носителя.

Теперь разберем пример.

Файл Payload.exe имеет Sequence = 40. Это означает, что он должен быть установлен 40-м по порядку. Чтобы определить, на каком диске (или в каком .cab-контейнере) находится этот файл, установщик проверяет запись в таблице Media Table с наименьшим значением LastSequence, которое больше или равно 40. В нашем случае это DiskId = 1 с LastSequence = 80. Это означает, что на DiskId = 1 (в первом cab1.cab-контейнере) находится файл с Sequence = 40, а также все файлы с более ранними Sequence значениями.

Файл Decoy.pdf имеет Sequence = 60. Установщик снова проверяет записи в таблице Media Table. Наименьшее значение LastSequence, которое больше или равно 60, — это 80. Значит, Decoy.pdf тоже находится на DiskId = 1, потому что все файлы с Sequence = 80 и меньше содержатся на этом носителе.

Предположим, у нас был бы файл Stager.exe с Sequence = 20. Установщик проверил бы таблицу Media Table и увидел, что Stager.exe находится на DiskId = 2, потому что там содержатся файлы с Sequence = 30 и меньше.

Таким образом, Windows Installer использует поля Sequence в File Table и LastSequence в Media Table для определения порядка установки файлов и их распределения по .cab-контейнерам на носителях. Это позволяет эффективно организовать процесс установки и в правильном порядке извлекать файлы с носителей.

Мариуш Банах хорошо продемонстрировал в своей статье разные сценарии использования MSI на основе Binary-таблиц. Подход подразумевает, что исходный файл кодируется в Base64 и хранится внутри MSI в Binary-таблице. При установке MSI он декодируется обратно и извлекается в исходном виде в указанную директорию. У этого способа есть существенный минус: из-за того, что исходные файлы запускаются сабпроцессом из временного .tmp-файла C:\Windows\Installer\MSIXXXX.tmp, мы теряем к ним доступ.

Отмечу, что в ходе исследований наша команда обнаружила более универсальный, уже упомянутый способ хранения и извлечения файлов из MSI. Он основан на использовании Media Element и SetDirectory возможностей фреймворка WiX, с помощью которых будут осуществлены сжатие и упаковка файлов с полезной нагрузкой в .cab-контейнер и хранением его в Media Table, а с помощью SetDirectory (в терминологии Microsoft называется Custom Action Type 51) будет задан целевой каталог, в который Custom Action Type 23 извлечет наши файлы из .cab-архива.

Расшифровка опций написанного нашей командой инструмента для генерации установочных файлов MSI с помощью фреймворка WiX:

1. SetDirectory — инициализация директории, в которую будут извлечены упакованные в MSI файлы.
2. DropFiles — список файлов, которые будут сохранены на целевой системе во время работы MSI.
3. ExeCommand — выполнение консольных CMD-команд для реализации логики kill chain.
4. StartupShortcutSrc — указание, для какого файла необходимо создать LNK в папке автозагрузки пользователя (закрепление на хосте).
5. StartupShortcutName — указание имени LNK-файла.
6. ProductName, ProductVersion, Manufacturer — заполнение метаинформации об установщике MSI.

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

Новые векторы Steal Credentials

Атака Browser-in-the-Browser

Исследователь Mrd0x задался вопросом: можно ли снизить эффективность проверки URL-адресов со стороны пользователей? В марте 2022 г. он описал метод атаки Browser-in-the-Browser с имитацией всплывающего окна входа в систему с легитимным URL.

В динамике атака выглядит следующим образом:

1. Отправляем пользователю ссылку на веб-страницу с реализацией BitB-атаки, используя фишинговый домен.
2. Жертва переходит по ссылке и видит кнопку.
3. После нажатия кнопки перед пользователем появляется привычная форма аутентификации в имитируемом браузерном окне. При этом мы можем редактировать отображаемый контент (URL-адрес и др.).
4. Пользователь вводит учетные данные, которые мы логируем на своем сервере.  
    

Реализация:

1. Находим понравившуюся форму компании, клонируем и размещаем на своем веб-сервере.
2. Создаем еще одну аналогичную форму, но убираем из нее поля ввода логина и пароля — оставляем только кнопку «Войти».
3. С помощью JavaScript и iframe создаем функцию — обработчик кнопки, которая загрузит HTML-содержимое формы в пределах текущего окна браузера с возможностью перемещать это «псевдоокно». То есть выполняем загрузку удаленно размещенной страницы в текущей странице и отображаем ее пользователю.

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

Атака Browser-in-the-Middle

Новая, более интересная техника по обходу 2FA, которую также описал Mrd0x. Концептуально BitM-атака не отличается от MitM и MitB: суть в том, чтобы максимально легитимно и незаметно для пользователя вклиниться между его браузером и сервисом.  
 

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

Архитектура атаки Browser-in-the-Middle:

1. Виртуальная машина на базе одной из NIX ОС.
2. VNC-сервер на виртуальной машине (TightVNC или TigerVNC).
3. ПО для предоставления графического доступа к VNC-серверу в браузере. Например, noVNC, Apache Guacamole, TeamViewer или Chrome Remote Desktop.

Так как жертва попадает во вредоносный браузер в режиме киоска с открытой целевой страницей на хосте злоумышленника, у него есть масса вариантов апгрейда атаки и способов логирования на стороне сервера.

Однако у этой концепции есть много сырых моментов:

1. Ужасная операционная безопасность. Во время атаки мы предоставляем доступ к своему хосту, поэтому нужно настроить отправку залогированных данных на удаленный хост, чтобы не хранить их на BitM-платформе.
2. Kiosk bypass (Citrix style): пользователь может выйти из режима киоска и получить полноценный доступ к хосту. Нужно настраивать пользователей без привилегированных прав, из-под которых браузер будет запускаться в режиме киоска.
3. Не работает ПКМ, и есть проблемы с буфером обмена. Это может затруднить ввод сложных паролей и вызвать подозрение у пользователей. Например, из-за невозможности вставить пароль из KeePass.
4. URL всегда статичен и не меняется.
5. Кнопка «Назад» изменит навигацию в реальном браузере, а не в браузере на BitM-платформе.
6. Концепция пока не работает на мобильных устройствах.

Ключевые тренды

1. Классический фишинг эффективен и важен для развития атаки, перемещения внутри сети и получения привилегированных доступов без лишнего шума.
2. Прогресс в части frontend и JavaScript технологий порождает прогресс фишинговых техник.
3. Новые мощные концепции по обходу 2FA и фишингу.

Как хакеры повышают эффективность kill chain:

1. Служебные заголовки писем. Они могут многое рассказать об используемом стеке почтовых СЗИ и архитектуре компании. Эта информация вкупе со знанием типичных болячек конкретного почтового решения помогает в подготовке и выборе правильных TTP для реализации kill chain.
2. Спуфинг почтового домена. Благодаря наличию эффективных зарубежных решений на почтовых шлюзах, многие забыли, что спуфинг почтового корпоративного домена в принципе существует и от него нужно уметь защищаться. С уходом зарубежных вендоров стало понятно, что необходимы дополнительные комплексные меры для противодействия подобным угрозам.
3. Корпоративно-житейский сценарий. В целевых фишинговых атаках используются сценарии, которые мимикрируют под обычную корпоративную активность. К ней у пользователей по умолчанию должно быть больше доверия, нежели к сценариям про корпоративные скидки или каким-то ультимативно резким требованиям.
4. Telegram. Использование мессенджеров и прямой контакт с атакуемым пользователем заметно увеличивают результативность kill chain.
5. Вишинг в эпоху корпоративных мессенджеров. Наша практика показывает: если позвонить и объяснить сотруднику, что сейчас ему в Telegram или на почту придет сообщение, он будет считать его более легитимным.
6. Хостинг полезной нагрузки на взломанных внешних ресурсах. Не во всех организациях у сотрудников есть свободный доступ в интернет. Некоторые используют белый список для явного предоставления доступа к внешним корпоративным ресурсам, а черные списки — для блокировки потенциально опасных ресурсов. В случае компрометации одного из сервисов, входящих в whitelist, или при выборе ресурса, не попадающего в blacklist, можно хранить полезную нагрузку там и рассылать пользователям соответствующие ссылки, обходя установленные ограничения.
7. Spearphishing via Service. Если атакующие скомпрометировали корпоративный ресурс, который посещают много пользователей, с помощью встраивания своего JavaScript-кода в исходный код приложения, они могут разместить там сценарий-плашку. Например, о необходимости обновиться перед использованием ресурса. Пользователь обновляется, плашка исчезает, а атакующие получают пробив, то есть доступ к машине пользователя.