Атаки на финансовый сектор глазами PT SWARM: социальная инженерия 2025

Мы в PT SWARM, как сейчас модно говорить, любим челленджи — ставить перед собой большие и сложные задачи, которые решаем путем их разбивки на небольшие компоненты, позволяющие шаг за шагом достигать нашей цели. Один из самых любимых челленджей — это проведение Red Team проектов для крупных финансовых компаний. Такие кейсы позволяют задействовать весь спектр наших тактик, техник и процедур (TTP), а также всю имеющуюся экспертизу. К тому же в процессе мы выявляем собственные слабые стороны, совершенствуем инструментарий и развиваемся как offensive-команда.

В этом материале я расскажу о нашем подходе к решению Red Team задачи по получению начального доступа к инфраструктуре финансовой компании с использованием методов социальной инженерии. В частности, материал продемонстрирует эффективность техник и тактик, о которых я рассказывал на Positive Hack Days и в Positive Research (материал 1 / материал 2). 

Я поделюсь своим видением построения таргетированной социотехнической атаки, включая этапы ее подготовки и реализации. Опишу технические приемы, с помощью которых мы решаем SE-задачи: DLL Side Loading, хостинг полезной нагрузки в CDN GitHub, отправку фишинговых писем через EWS-эндпоинт Exchange-сервера, Telegram RAT и SIM-карты для вишинга. Будучи объединенными в одну атакующую цепочку, эти методы позволяют достигать результатов в самых масштабных и сложных Red Team операциях.

Экосистема фишинговой атаки

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

При верхнеуровневом рассмотрении атаку можно разделить на три этапа: разведка, подготовка и реализация (см. рис. 1).

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

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

Кубик «Разведка»

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

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

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

Пассивная разведка (без взаимодействия с инфраструктурой и сотрудниками компании)

1. Анализ утечек данных

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

• учетные и аутентификационные данные;
• внутренние имена серверов и сервисов;
• паттерны учетных записей;
• исходные коды приложений;
• FQDN — полное доменное имя внутреннего домена Active Directory компании.

Особое внимание уделяется поиску в логах инфостилеров, публичных утечках данных и сервисах хранения кода (GitHub, GitLab и др.), валидных учетных данных, внутренних наименований серверов и сервисов, почтовых адресов, а также персональных данных сотрудников (ФИО, телефонные номера и др.).

На этом этапе в логах инфостилеров нередко обнаруживаются действительные учетные данные администратора Bitrix или других уязвимых веб-приложений, в которых возможно удаленное выполнение кода. Также находятся доменные учетные данные, позволяющие получить доступ к корпоративной почте (при наличии доступной OWA на внешнем периметре компании или EWS-эндпоинта Exchange-сервера) или извлечь GAL (Global Address List) с Exchange-сервера, получив всю адресную книгу почтового сервера с информацией о сотрудниках.

2. Анализ технологического стека компании

На этом этапе необходимо получить информацию:

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

Ценными источниками такой информации служат вакансии компании и описание деятельности сотрудников на LinkedIn, где специалисты часто подробно перечисляют используемые технологии и системы для демонстрации своей квалификации. Например, из описаний вакансий и профилей LinkedIn можно получить сведения о средствах защиты информации и составить представление об архитектуре Anti-APT-решений компании.

Корпоративные инструкции и информацию о внутренних процессах компании можно обнаружить как в исходном коде на GitHub (в описаниях функций), так и в утечках различных корпоративных документов.

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

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

Обнаружить беспроводные сети возможно двумя способами:

1. Использовать сервис Wigle, позволяющий искать беспроводные сети по SSID.

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

Для определения имени внутреннего домена Active Directory можно воспользоваться доступностью типичных служб сервера Exchange.

Эта информация полезна как для проведения атак password spraying на подбор паролей к доменным учетным записям, так и для использования имени домена при проверке окружения в полезных нагрузках. Кроме того, доступность службы /EWS открывает возможность чтения корпоративной почты и рассылки внутреннего фишинга при наличии действующих учетных данных.

3. Сбор почтовых адресов

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

Мой любимый вариант сбора почтовых адресов — выгрузка Global Address List (GAL) или Offline Address Book (OAB) с Exchange-сервера после успешно проведенной атаки password spraying. Нигде не найти более полной и актуальной информации о почтовых адресах и сотрудниках, чем в корпоративной адресной книге. 

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

4. Профилирование сотрудников

Профилирование подразумевает обогащение фокус-группы персональной информацией: ФИО, номер мобильного телефона, должность и департамент сотрудника. Это особенно актуально, если не удалось выгрузить с Exchange-сервера GAL, содержащий необходимую информацию.

Зачем это нужно? 

• Чем больше информации о жертве мы имеем, тем эффективнее будет атака. Персональное обращение по имени в сценарии повышает уровень доверия и минимизирует количество отправленных писем в сторону технически подкованных пользователей.
• Знание мобильного номера телефона значительно увеличивает вероятность успеха социально-инженерной кампании, поскольку открывает доступ к социальным сетям и профилю Telegram сотрудника (при отсутствии ограничений поиска по номеру). Это позволяет проанализировать профиль для составления психологического портрета потенциальной жертвы, а также визуализировать возможный диалог. И главное — таким образом создается возможность для проведения вишинг-атак через телефонные звонки и фишинг в мессенджерах, что становится решающим фактором в SE.

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

Активная разведка

1. Скриншоты веб-страниц внешнего периметра компании

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

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

Если требуется реализовать нечто более сложное, чем обычную форму, записывающую введенные учетные данные в файл на сервере, стоит освежить знания о таких концептах атак, как Browser in the Browser (BitB) и Browser in the Middle (BitM).

2. Получение Global Address List / Offline Address Book

Как упоминалось выше, получение Global Address List (GAL) или Offline Address Book (OAB) с Exchange-сервера организации — это существенный пререквизит, позволяющий оперировать актуальными данными о сотрудниках и формировать точечные фокус-группы. Подробнее об атаках на интерфейсы MS Exchange можно узнать в исследовании нашей команды PT SWARM, а сейчас сосредоточимся на полезной для подготовки фишинговой атаки информации в GAL.

Прежде всего необходимо отметить, что для этого требуются действительные доменные учетные данные и сетевая видимость Exchange-сервера организации. Откуда же взять доменные учетные данные до проведения фишинговых атак? Для этого в современных SE-кампаниях часто используются результаты других «пентестовых» активностей. Рассмотрим несколько эффективных векторов помимо фишинга.

A) Анализ утечек данных

Используя команду «grep» и зная почтовый/доменный паттерн учетной записи, проводим поиск утекших учетных данных сотрудников компании. Наиболее результативными являются логи с инфостилеров, где нередко обнаруживаются актуальные данные сотрудников.

B) Password Spraying

Подбор учетных данных на интерфейсах MS Exchange или любых других веб-интерфейсах, позволяющих работать с доменными учетными записями, — источник примерно 90% валидных учеток, которые можно использовать для развития разных векторов атак. Для взаимодействия с доменной инфраструктурой и эскалации привилегий всегда требуются учетные данные. 

C) Атака Evil Twin на WPA-Enterprise-сети

WPA-Enterprise считается более безопасным методом по сравнению с WPA-PSK. Вместо предварительно распределенного ключа (PSK) здесь используется аутентификация по протоколу 802.1x на сервере RADIUS, который проверяет учетные данные пользователей и централизованно управляет всеми процессами (более подходящий вариант для корпоративной среды). Снижение рисков компрометации учетных данных происходит благодаря тому, что у каждого пользователя есть собственный идентификационный ключ для доступа к сети — в виде доменной учетной записи и пароля.

Для нас представляет интерес использование компанией корпоративной беспроводной сети на основе EAP-PEAP без применения сертификатов для проверки подлинности точки доступа. До сих пор часто встречаются крупные компании, которые используют аутентификацию в беспроводной сети только на основе учетных данных, игнорируя более защищенные методы с применением сертификатов, например EAP-TLS. Как пентестеры, мы только рады таким «низко висящим фруктам» и возможности быстро получить учетные записи, но, как специалисты по кибербезопасности, огорчаемся, что компании пренебрегают повышением безопасности своих беспроводных сетей и не используют несложные передовые архитектурные практики.

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

Атака Evil Twin основывается на предположении, что многие сотрудники заказчика используют беспроводную сеть на мобильных телефонах или корпоративных ноутбуках без проверки сертификата сети. Это позволяет понизить метод аутентификации клиента и перехватить учетные данные.

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

Легитимные точки доступа при установлении соединения предлагают клиенту методы аутентификации в порядке от наиболее до наименее защищенного. В противоположность этому наши поддельные точки доступа предлагают методы аутентификации от наименее к наиболее защищенному. В результате происходит понижение метода аутентификации, например с PEAP-EAP-MSCHAPv2 до EAP-GTC.

Извлечение GAL по протоколу MS-OXNSPI

Благодаря продуктивной охоте к началу стадии активной разведки мы получаем набор действующих доменных учетных записей, которые можно использовать для развития атак. Например, можно выполнить выгрузку глобальной адресной книги с Exchange-сервера с помощью инструмента exchanger.py, разработанного нашей командой.

Сначала необходимо подключиться к серверу MS Exchange по протоколу MS-OXNSPI и осуществить запрос на получение информации о глобальном списке адресов на сервере.

В выгруженной адресной книге мы можем обнаружить общее количество почтовых адресов в глобальной адресной книге, а также имена адресных книг, которые компания использует для группировки почтовых адресов, составляющих Global Address List. В стандартном пользовательском интерфейсе OWA (Outlook Web Access) данные отображаются как набор контактных листов.

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

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

Таким образом, мы получаем максимально достоверную информацию о сотруднике и знаем:

• когда он пришел в компанию (атрибут «whenCreated»);
• почтовый адрес сотрудника (атрибут «mail») и почтовые алиасы (атрибут «proxyAddresses»);
• мобильный телефон (поле «mobile»);
• департамент и должность (поля «title» и «department»);
• ФИО;
• физическое расположение (атрибуты «st» и «physicalDeliveryOfficeName»).

Нам остается лишь тщательно подобрать фокус-группу на основе анализа содержимого GAL и приступить к подготовке фишингового сценария.

3. EWS (Exchange Web Services)

Несколько лет назад даже в крупных компаниях OWA (Outlook Web Access) часто был доступен на внешнем периметре без двухфакторной аутентификации и сертификатов. При наличии учетных данных это позволяло легко войти в корпоративную почту, проанализировать стиль переписки, корпоративные подписи, рассылки и встроиться в диалог для проведения внутреннего фишинга.

Такая архитектура удобна для сотрудников, но небезопасна для компании. Сейчас свободный доступ к OWA встречается реже. В основном для доступа к почте используются:

• 2FA (пуш-уведомления, OTP-коды);
• доступ по сертификатам (или через VPN) с 2FA, обеспечивающий сетевую видимость OWA только после подключения.

На первый взгляд защита кажется надежной, поскольку соответствует современным best practice, предписывающим размещать все ресурсы за двухфакторной аутентификацией. Что делать в такой ситуации хакеру? Стоит разобраться в устройстве корпоративной почты на базе Exchange и в том, как фактически осуществляется управление почтовым ящиком «под капотом». Это может открыть множество интересных векторов по обходу 2FA и управлению ящиком — благодаря легитимному функционалу и возможностям Exchange-сервера.

Чем интересен EWS 

При активной разведке мы уделяем особое внимание доступности веб-службы /EWS/Exchange.asmx. EWS (Exchange Web Services) — это API, который предоставляет доступ к функциям и данным Microsoft Exchange Server. Он позволяет взаимодействовать с серверами Exchange для управления почтой, календарями и другими объектами (фактически позволяет управлять почтовым ящиком сотрудника).

При наличии учетных данных EWS позволяет выполнять следующие действия:

• чтение почты — доступ к входящим и исходящим сообщениям;
• отправка сообщений — возможность отправки email’ов;
• управление календарем — создание, изменение и удаление событий;
• работа с задачами и контактами — добавление, изменение и удаление;
• поиск данных — возможность поиска по почте, календарю и другим объектам.

Таким образом, даже если компания использует 2FA, сертификаты и VPN, мы можем получить доступ к почте легитимными методами, используя возможности и функционал самого Exchange-сервера.

EWSdelivery

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

Сначала необходимо проверить валидность полученных учетных данных (с этапа password spraying / фишинга / Wi-Fi).

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

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

Анализ корпоративной почты через EWS

В контексте почтового фишинга основной интерес представляют:

• корпоративная подпись;
• этика общения;
• типичные корпоративные рассылки;
• наличие корпоративного мессенджера;
• корпоративная ВКС;
• внутренняя корпоративная жизнь и процессы компании.

Если с корпоративной подписью и ВКС/мессенджерами в целом все понятно, то что такое «этика общения», «типичные рассылки» и «корпоративная жизнь»?

Этика общения

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

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

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

Типичные корпоративные рассылки

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

Что может быть более обыденным в корпоративной почте, чем рассылки от ИТ или ИБ, службы поддержки, HR-команд, а также технические уведомления от разных сервисов? Следует проанализировать подобные письма и по возможности использовать их в качестве основы для сценария, чтобы повысить уровень мимикрии.

Внутренняя корпоративная жизнь и процессы компании

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

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

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

Итог анализа корпоративной почты

После сбора всей необходимой информации можно подготовить HTML-версию фишингового письма и использовать EWS для его отправки от имени сотрудника потенциальным жертвам (включая вложения с полезной нагрузкой).

Остается только ждать, когда жертва прочитает письмо и примет решение, от которого зависит успех получения начального доступа к инфраструктуре.

4. Корпоративная подпись и плашка «Внешний отправитель»

Добываем корпоративную подпись

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

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

Таким образом, выделим следующие векторы для получения корпоративной подписи:

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

Плашка «Внешний отправитель»

Получив ответное письмо с корпоративной подписью, можно обнаружить в нем специальную плашку, предупреждающую сотрудника: письмо пришло с внешнего адреса. Такая плашка может размещаться как в начале, так и в конце письма. Также в тему письма могут добавляться соответствующие заголовки ([Внешний отправитель], [Potential SPAM] и др.), но эта практика встречается гораздо реже. В последнее время подобные правила все чаще внедряются на Exchange-серверах компаний для защиты корпоративной почты.

Давайте разберемся, что собой представляет эта плашка и как она реализована технически. По сути, это HTML-код, который вставляется в тело письма в соответствии с настройками правила, созданного на Exchange-сервере через панель администрирования ECP. Чаще всего используется правило, которое применяется сразу ко всем внешним почтовым адресам и доменам, не входящим в список доверенных («accepted domains»).

Итак, плашка — это просто дополнительный HTML-код, добавляемый в содержимое письма на основе правил о внешнем отправителе.

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

5. Физический пентест

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

Физическое проникновение в офис компании рассматривается только в случаях, когда туда можно попасть на законных основаниях без особых проблем. То есть если там есть общедоступная зона или компания проводит в офисе публичные митапы и семинары.

Митап как вектор проникновения

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

Тематика мероприятий не имеет существенного значения, поскольку наша основная цель — легально попасть в офис и провести разведку. Например, для этого можно использовать специальные устройства (LAN Turtle, Raspberry Pi, USB-накопители и др.) для взаимодействия с сетевыми розетками, принтерами и прочей офисной инфраструктурой. 

Flash-drive-атаки на секретарей

Помимо подключения специализированных устройств к сетевым розеткам, митап позволяет реализовать социальную атаку на секретарей ресепшен, рабочие станции которых обычно имеют определенную видимость доменной инфраструктуры. Мероприятие органично обосновывает просьбу распечатать ваше резюме с USB-накопителя для передачи одному из выступающих. При подключении подобных накопителей к рабочим устройствам их содержимое считается доверенным, поэтому на него не распространяются защитные механизмы вроде Mark-of-the-Web и карантина. Это позволяет реализовывать относительно простые цепочки для запуска полезной нагрузки.

Инфраструктурная разведка

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

• анализируем сегментацию сети, доступные протоколы (TCP, HTTPS, DNS, ICMP) для C2-туннелей;
• проверяем доступ к облачным хранилищам и различным внешним ресурсам («Яндекс.Диск», Google Drive, Облако Mail, Telegram).

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

• ищем незаблокированные устройства, которые сотрудники оставили без присмотра;
• пробуем подключиться к доменной сети через ранее скомпрометированные учетные записи.

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

• сегментация сети;
• возможности выхода во внешнюю сеть по различным сетевым протоколам для построения C2-туннелей (TCP, HTTPS, DNS, ICMP и др.);
• доступность облачных хранилищ и ресурсов («Яндекс.Диск», Google Drive, Облако Mail, Telegram и т. д.).

Эти данные рассеивают туман войны и позволяют адаптировать фишинговые сценарии и C2-инфраструктуру атаки под особенности инфраструктуры компании.

Кубик «Подготовка»

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

Условно подготовку можно разбить на два взаимосвязанных этапа:

• формирование атакующей фишинговой цепочки,
• формирование качественной фокус-группы.

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

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

Фишинговый чейн

Сценарий

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

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

Что делать, если атакуемый сотрудник не отреагировал? Да в целом ничего — искать следующего кандидата и пытаться вызвать нужную эмоцию. Не повезло с одним — повезет с другим. Для меня предпочтительнее сценарий, когда пользователь просто игнорирует фишинговое письмо, а не обращается в службу ИБ или же начинает задавать уточняющие вопросы, которые могут привести к раскрытию кампании. Лучше не вызывать у жертв эмоций, которые запустят сарафанное радио или приведут к оповещению центра безопасности, поскольку такие реакции сложно контролировать и сглаживать.

При формировании сценария стоит подготовить несколько вариантов текста для благоприятных и неблагоприятных ситуаций. Если с первыми все понятно (получение обратного соединения на C2), то в случае неблагоприятного развития событий необходим набор готовых ответов для оперативного решения различных проблем (например, проблемы со ссылкой или запуском файла, уточняющие вопросы о личности отправителя и многое другое). Как предугадать и продумать все заранее? Подготовиться ко всему практически невозможно, но 90% ситуаций можно предусмотреть путем эмуляции: поставить себя на место жертвы, задать себе потенциальные вопросы и подготовить логичные ответы. Чем больше у вас проектного опыта, тем проще решается эта задача.

Вектор доставки и коммуникации

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

• А что, если наше письмо не достигнет корпоративной почты сотрудника или будет проигнорировано? Значит, необходимо подготовить альтернативный канал коммуникации и доставки фишингового сценария. Например, через Telegram или EWS, используя возможность проведения внутреннего фишинга.
• А что, если сотрудник не сможет перейти по нашей ссылке? Тогда, помимо собственного хостинга полезной нагрузки на внешнем сервере с привязанным доменом, следует рассмотреть использование легитимных внешних ресурсов: они должны находиться в белых списках или доступ ним должен быть разрешен на основе ACL. В первую очередь это Google, «Яндекс», Dropbox, Github и другие подобные сервисы. Также эффективным решением может быть использование ранее скомпрометированного внешнего ресурса компании, на котором можно разместить нагрузку и формировать ссылки с легитимным доменным именем организации. 
• А что, если текстовая коммуникации не убедит атакуемого сотрудника? В этом случае используем фишинговую SIM- или eSIM-карту и инициируем голосовую коммуникацию на основе заранее подготовленного сценария. Применение «ядерной триады»: фишинг через почту или EWS + фишинг в Telegram + вишинг — неизменно приводит к результату.

Главное — заложить и подготовить в сценарии сразу несколько векторов доставки нагрузки и коммуникации с сотрудником: корпоративная почта, мессенджеры, телефон, ссылки на облачные хранилища и другие каналы. Имея на руках планы A, B и C, вы сможете их чередовать: «Не сработал план А? Пробуем план В! Снова не получилось? Попробуем план А на другой цели или переходим к плану С».

Резюмируем.

Векторы доставки полезной нагрузки:

• ссылки на собственный хостинг;
• облачные сервисы;
• легитимные внешние серверы компании, к которым был получен доступ.

Векторы коммуникации и доставки фишингового сценария:

• корпоративная почта (через EWS и с помощью внешних почтовых сервисов и доменов); 
• мессенджеры; 
• телефонная связь.

Полезная нагрузка

Remote Administration Tool

Вишенка на фишинговом торте, определяющая итог всей кампании. В первую очередь полезная нагрузка представляет собой средство удаленного администрирования (RAT), которое при успешном запуске устанавливает обратное соединение с С2 для туннелирования трафика во внутренний сегмент корпоративной сети. Контейнеры, файловые расширения и другие аспекты — отдельная тема. Все-таки ключевой элемент нагрузки — многофункциональный инструмент, обеспечивающий обратное соединение из корпоративной инфраструктуры с внешним С2-сервером через различные сетевые протоколы: TCP, HTTPS, DNS, ICMP, IMAP, MAPI и другие.

Эффективность нагрузки во многом зависит от арсенала туннелирования и разрешенных в компании сетевых протоколов, которые не блокируются на границе внутреннего периметра (например, с помощью NGFW). В любом случае необходимо задаться вопросом: а что, если не получится установить обратное соединение по прямому TCP-соединению с С2? Здесь важно предусмотреть альтернативные варианты: «Через TCP не получилось? Не проблема — мы также настроили DNS и ICMP, они идут следующими по приоритету для установления обратного соединения».

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

Sandbox/VM evasions

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

Persistence

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

Post-exploitation

Если у вас есть собственный агент постэксплуатации, позволяющий работать с доменной инфраструктурой из контекста пользователя и выполнять консольные команды без вызова стандартных консолей, включите его в начинку полезной нагрузки для запуска в памяти или извлечения на диск. При исследовании атакуемой рабочей станции и Active Directory это позволит вам не создавать в системе процессов, привлекающих внимание защитных механизмов (например, cmd.exe и powershell.exe).

Execution

Далее необходимо определить логику выполнения для конкретной ОС и выбрать соответствующий тип файла: что и как запустит основную полезную нагрузку. Для Windows это могут быть файлы Microsoft Office с макросами, различные исполняемые файлы пользовательского уровня (.LNK, .CMD, .BAT, .URL и др.) или векторы DLL Side-Loading — итоговый выбор зависит от вашей экспертизы, предпочтений и сценарных задумок.

Семь раз оттесть — один раз отправь

Теперь-то всё? Можно отправлять? Ну почти... 

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

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

Фокус-группы

На этом этапе необходимо сформировать два вида фокус-групп:

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

При этом мы закладываем несколько сценариев в контексте имеющихся у нас предварительных условий.

Благоприятный сценарий

Итак, у нас на руках есть GAL со всеми почтовыми адресами сотрудников, ФИО, должностями и номерами телефонов. Какие кандидатуры можно считать подходящими для фишинговых фокус-групп? Я использую набор базовых критериев:

• Недавно пришел в компанию. Это важно, так как чем меньше времени сотрудник работает в компании, тем более вероятно, что он еще не знаком с типичными корпоративными процессами и имеет ограниченный круг контактов внутри организации. 
• Младший специалист. Джуны не просто так джуны. Они обладают меньшим набором компетенций и являются наиболее уязвимой целью. Часто можно услышать шутку: «джуны в ИТ не нужны». Но нам они еще как нужны :)
• Не является сотрудником технического департамента. Мы неоднократно успешно атаковали ИТ-специалистов, но я все же предпочитаю выбирать менее подкованных в техническом плане сотрудников: менеджеров, финансистов, HR, секретарей и других специалистов, которые не будут задавать много лишних вопросов.
• Рабочая деятельность связана с компьютером. Нет смысла включать в фокус-группу шоферов, кассиров, кладовщиков и других сотрудников, деятельность которых не связана с использованием доменного рабочего компьютера. 
• Большой поток рабочих писем в почте. Нас интересуют сотрудники, которые активно пользуются почтой. Это повышает вероятность того, что наше письмо заметят и прочтут.
• Указан номер мобильного телефона. Лучше сразу заложить несколько векторов коммуникации с атакуемым сотрудником и доставки нагрузки.
• Можно идентифицировать мессенджеры. В первую очередь речь идет о Telegram: это самая удобная платформа для фишинга в силу ее распространенности и глубокой интеграции в бизнес-процессы многих компаний. Если в настройках конфиденциальности не запрещен поиск по номеру телефона, мы легко найдем профиль сотрудника в мессенджере.
• Минимум сотрудников в отделе. Важно избежать эффекта сарафанного радио — когда знакомым друг с другом сотрудникам приходят одинаковые письма. Роевой интеллект неоднократно доказывал, что он может быть намного эффективнее, чем разные СЗИ.

Неприятный сценарий

Если нам по каким-то причинам не удалось получить GAL, нужно провести профилирование сотрудников методами OSINT — идентифицировать ФИО, должности и номера телефонов (то есть вернуться на этап разведки). Особое внимание стоит уделить поиску на hh.ru (с помощью функционала «для работодателей -> поиск по резюме») и Linkedin, а также публичным утечкам, в которых можно провести поиск на основе почтового домена компании.

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

• Доступность профиля Telegram. Необходима для клонирования профиля с реальными фотографиями сотрудника. Обеспечивает защиту при возможной проверке жертвой соответствия фото в Telegram и корпоративных ресурсах.
• Наличие публичных социальных сетей. Альтернативный источник фотографий для создания правдоподобного фейкового профиля при отсутствии данных из Telegram.
• Релевантные департамент и должность. Важно соблюдать логику при распределении сценариев: технические должны исходить от ИТ-специалистов и службы поддержки, а корпоративные и организационно-бытовые сценарии — от сотрудников HR и специалистов по работе с персоналом. Согласитесь, предложение установить ПО от имени бухгалтера выглядело бы подозрительно.

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

Кубик «Реализация»

Этапы разведки и подготовки в среднем занимают от недели до двух — иногда чуть больше, иногда меньше. После этого наступает час Х, когда требуется приступить к реализации и начать таргетированную фишинговую кампанию. Возможно, ваша атака будет обнаружена командой защитников, домен заблокирован на почтовом шлюзе или разделегирован, полезная нагрузка отправлена на Virus Total с добавлением хеш-сумм на антивирусные решения, а полученные обратные соединения разорваны в одностороннем порядке. В этом случае придется откатиться обратно на кубики «Разведка» и «Подготовка». Ничего не поделаешь — таков путь :)

Каких-то революционных подходов на этапе реализации не потребуется: при качественной разведке и подготовке все должно пройти как по маслу. Единственное, не рекомендуется рассылать «письма веером». Лучшей практикой является таргетированная отправка писем или звонки сотрудникам: таким образом вы не запустите сарафанное радио собственноручно и не привлечете внимание команды SOC.

Массовая рассылка — моветон

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

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

• завал — банально нет времени на наше письмо;
• пометили письмо, но забыли к нему вернуться;
• не проверяют почту или пропустили письмо в ленте;
• в отпуске;
• не восприняли сценарий;
• …

Конечно, принято считать, что активность рода «переход по ссылке из письма или вложения» должна происходить в первые минуты кампании, однако ее отсутствие — это тоже абсолютно нормально (при условии, что мы уверены в доставке письма). Проектный опыт показывает, что иногда нужно немного подождать и дать сотрудникам больше времени либо напомнить о себе дополнительным письмом спустя пару дней. Не стоит проявлять излишнюю поспешность, увеличивая объемы отправленных писем. В некоторых проектных кейсах мы получали активность в виде запуска нашей полезной нагрузки спустя несколько дней и даже недель с момента отправки письма. Триада «фишинг в почту, фишинг в мессенджерах и вишинг» обязательно принесет результат, если действовать подготовленно, уверенно и тихо.

Как мы финансовые компании ломаем

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

Для таргетированного фишинга мы выбираем в качестве SE-тарана следующую триаду: 

• фишинг в почту через EWS;
• фишинг в мессенджеры;
• вишинг.

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

Этап первый — разведка

Одним из ключей к проникновению в инфраструктуру являются действительные доменные учетные данные. Есть несколько эффективных векторов их получения:

• фишинг, нацеленный на перехват вводимых учетных данных;
• атаки Evil Twin на корпоративные беспроводные сети;
• Password Spraying;
• анализ общедоступных утечек, логов инфостилеров и иные виды утечек.

Обычно мы сознательно ограничиваем себя и исключаем Password Spraying и фишинг на начальных этапах проекта. Это решение продиктовано нежеланием преждевременно раскрывать адресные пространства нашей внешней инфраструктуры команде SOC заказчика. Мы стремимся максимально долго сохранить «туман войны» для защитников и увеличить показатели TTD (Time to detect) и TTR (Time to respond), чтобы обеспечить себе больше пространства для маневра.

Анализ логов инфостилеров

На первом этапе пассивной разведки мы концентрируемся на анализе слитых общедоступных логов инфостилеров по FQDN-значению домена Active Directory нашего заказчика. Этот метод пассивной разведки позволяет оперативно обнаружить валидные учетные данные, которые можно использовать для извлечения с доступного на внешнем периметре Exchange-сервера Global Address List (GAL) — важного пререквизита для подготовки таргетированного фишинга.

Каким же образом учетные данные сотрудников крупных компаний попадают в утечки инфостилеров и оказываются в открытом доступе? Механизм достаточно прост:

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

Чем крупнее компания, тем выше вероятность обнаружения учетных данных ее сотрудников в логах инфостилеров. Одновременно возрастает шанс, что команда Threat Intelligence организации либо не успела проанализировать, либо просто не обнаружила очередную утечку.

На некоторых Red Team проектах для компаний из финансового сектора нам удавалось выявить действующие доменные учетные данные после тщательного анализа значительного объема логов инфостилеров. Эти данные позволяли установить подключение к серверу MS Exchange по протоколу MS-OXNSPI и выполнить запрос для получения информации о глобальном списке адресов на сервере:

Затем мы осуществляли выгрузку GAL для последующего детального анализа на нашей рабочей станции:

В результате мы получили доступ ко всем действующим именам доменных учетных записей сотрудников компании и их почтовым адресам. Эти данные как минимум позволяют провести более эффективный и целенаправленный Password Spraying с использованием словарных паролей (например, Zydfhm2025!, Atdhfkm2025! и др.) для получения дополнительных учетных записей.

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

Evil Twin

Единичные учетные данные, обнаруженные в логах инфостилера, не обеспечивают достаточного охвата для запланированных нами действий на внешнем периметре компании и проведения SE-атак через службу EWS Exchange-сервера. Поэтому следующим этапом нашей credentials-охоты обычно является физическая вылазка в сторону офисных зданий заказчика с целью изучения ландшафта беспроводных сетей и проведения целенаправленных атак.

Ландшафт корпоративных Wi-Fi-сетей

В базовом сценарии мы ожидаем обнаружить следующие стандартные Wi-Fi-сети:

• WPA/WPA2-PSK (Pre-Shared Key) — беспроводная сеть с доступом по общему паролю;
• WPA/WPA2-EAP (Extensible Authentication Protocol) — сеть, в которой аутентификация происходит на основе уникальных учетных данных клиента (чаще всего доменные логин/пароль, сертификат).

Беспроводные PSK-сети обычно используются в качестве гостевых Wi-Fi или в сетях с сегментацией, изолированных от основной корпоративной доменной инфраструктуры. Поскольку качество такой сегментации и изоляции зачастую оставляет желать лучшего, для PSK-сетей наша стратегия включает проведение широко известных атак:

• перехват значения Handshake — принудительная деаутентификация клиента точки доступа и перехват значения 4-way Handshake при обмене сообщениями между устройством и точкой доступа для генерации ключей шифрования;
• атака PMKID (Pairwise Master Key Identifier) — уникальный идентификатор, передаваемый некоторыми точками доступа в первом сообщении Handshake, который позволяет определить значение PSK без наличия активного клиента точки доступа и принудительной деаутентификации.

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

Однако в рамках наших проектов такие низко висящие фрукты встречаются редко. Чаще всего в офисах компаний из финансового сектора можно встретить большое количество корпоративных EAP-сетей, в которых используется метод аутентификации PEAP. Это открывает возможность для проведения атаки Evil Twin на потенциальных клиентов сети: если они обнаружат знакомый SSID точки доступа, то будут подключаться без проверки сертификата сервера (см. рис. 16.1 и 16.2).

Беспроводная засада

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

Классические варианты расположения поддельной точки доступа и реализации Wi-Fi-засады:

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

Регулярное повторение атаки Evil Twin в ходе Red Team проекта обеспечивает нас актуальными доменными учетными записями сотрудников компании. Особая ценность этого подхода заключается в том, что сторона защиты не может отследить компрометацию учетных данных до момента их фактического использования при преодолении внешнего периметра организации и при работе с почтовыми ящиками сотрудников через веб-сервис EWS.

Митап как вектор физического проникновения

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

Для подобных случаев у нас есть отработанный план действий:

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

Знакомство с местом проведения митапа

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

Дополнительная задача, успешное решение которой может обеспечить нам получение начального доступа к домену с минимальными усилиями, — это проведение социотехнических атак на секретарей. Здесь используем классический вектор: просим распечатать резюме с флешки. Несмотря на кажущуюся банальность, этот метод остается эффективным, поскольку содержимое подключаемых внешних USB-устройств становится доверенным для Windows и MacOS. Оно минует ограничения Mark-of-the-Web/SmartScreen (Windows) и карантин доверенных приложений (MacOS), что позволяет проводить атаки без особых трудозатрат.

Например, наиболее распространенный чейн на наших проектах подразумевает использование LNK-файла, запуск которого инициирует открытие PDF-файла резюме и одновременно запускает в фоновом режиме DLL Side-Loading в уязвимом бинарном файле. При этом полезная нагрузка устанавливает обратное соединение с нашим C2-сервером и закрепляется в системе.

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

Обычно в ходе первичной разведки на площадке нам удается подметить:

• свободные переговорные комнаты с сетевыми розетками;
• принтеры;
• лестницы и лифты, ведущие в рабочие пространства сотрудников.

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

Принтер, в свою очередь, является хорошей целью для подключения LAN Turtle (компактное устройство для проведения сетевых атак). Либо можно воспользоваться его MAC-адресом для потенциального обхода протокола 802.1x, ограничивающего подключение к сети устройств с неизвестными MAC-адресами.

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

Боевой поход

К следующему митапу мы готовим внушительный арсенал пентест-оборудования. В него могут входить:

• несколько собственноручно собранных ИБП с SIM-картами, замаскированных под обычные удлинители;
• LAN Turtle;
• набор Raspberry Pi с различным функционалом, включая Crazyradio для проведения атаки mousejack, которая нацелена на беспроводные клавиатуры и мыши, работающие на частоте 2,4 ГГц и использующие фирменные (не Bluetooth) протоколы, что позволяет перехватывать и отправлять консольные команды через радиоканал.

При повторном посещении митапа мы уже не дожидаемся его начала, а сразу следуем в уединенную переговорку для подключения к сетевой розетке и оценке ее сетевой видимости. При этом можно столкнуться с суровой DMZ-реальностью: после подключения через ethernet-кабель обнаружить FQDN вида dmz-wifi.tech без сетевой видимости основной доменной инфраструктуры компании или каких-нибудь послаблений в отношении внешних корпоративных ресурсов (например, отсутствия 2FA). Это свидетельствует о тщательной предварительной работе сетевых инженеров и системных администраторов, которые выполнили требования ИБ и исключили сетевую связность с основной инфраструктурой. 

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

• проверить доступность внешних ресурсов (облачные хранилища, Telegram, GitHub, произвольные внешние адреса нашей C2-инфраструктуры);
• определить разрешенные сетевые протоколы на периметре для построения туннелей и эксфильтрации данных;
• исследовать политики безопасности для конечных точек, стандартные ACL и средства защиты (антивирусы, EDR, AppLocker).

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

Итоги митап-разведок

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

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

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

Этап второй — подготовка

Теперь можно приступить к формированию нашего SE-вектора. Пора начинать готовить:

• сценарий;
• фокус-группу;
• фокус-группу мимикрии под подходящих сотрудников;
• фишинговые TG-профили;
• фишинговые SIM-карты;
• вектор доставки;
• полезную нагрузку.

Сборка фишингового чейна

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

Вектор доставки и коммуникации

С векторами доставки и коммуникации мы определились в самом начале планирования SE-операции:

• первичный метод: отправка фишинговых писем через EWS на почтовые адреса жертв с использованием учетных данных, полученных на Wi-Fi-этапе;
• резервные каналы коммуникации (при отсутствии активности): обращение к сотруднику через Telegram или звонок на мобильный телефон.

Вместо сложного построения SIP-инфраструктуры мы проводим переговоры с представителями сотовых операторов у станций метро, которые раздают всем желающим бесплатные комплекты SIM-карт. Также используем для регистрации фишинговых профилей в Telegram разные публичные сервисы аренды телефонных номеров.

PDF Luring

Это техника для манипуляции PDF-файлами с целью привлечения и обмана пользователей. Контент в PDF Luring может быть разным, но идея сводится к тому, чтобы повысить уровень доверия жертвы и убедить ее перейти по ссылке в архиве или, например, воспользоваться паролем к зашифрованному архиву/файлу (который либо был доставлен жертве ранее, либо скачивается при переходе по ссылке).

Так как чаще всего мы размещаем полезную нагрузку на облачных сервисах и CDN («Яндекс.Диск», Google Drive, GitHub CDN) или собственных внешних веб-хостингах, то и доставлять нагрузку предпочитаем с помощью ссылок внутри PDF-инструкции, а не вложенными ссылками в теме письма.

PDF содержит не только ссылки на полезную нагрузку, но и детальное руководство с иллюстрациями, пошагово объясняющее пользователям Windows и MacOS процесс необходимого «обновления» клиента приложения. 

Сценарий

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

В ходе пассивной OSINT-разведки мы определяем список используемого корпоративного ПО и сервисов. Например, выявляем корпоративную систему ВКС и командный мессенджер на основе историй сотрудников в соцсетях (на мониторах могут быть видны знакомые интерфейсы) или путем анализа внешних ресурсов компании.

Но все-таки при выборе сценария нужно остановиться на одном ПО, которое мы будем использовать. Как это сделать? Очень просто: ищем уязвимости нулевого дня типа DLL Side-Loading в доступных для скачивания desktop-клиентах корпоративной ВКС и мессенджере компании. 

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

Например, бинарный файл корпоративного мессенджера имеет цифровую подпись, не являющуюся доверенной для Microsoft и ОС Windows, что вызывает появление синего диалогового окна при запуске. В таком случае мы выбираем desktop-клиент ВКС или другого приложения, чья цифровая подпись позволит обойти SmartScreen и запустить нашу полезную нагрузку (vksname.exe + payload.dll) простым двойным кликом, без предупреждений.

Полезная нагрузка

При выборе в качестве основной полезной нагрузки 0-day DLL Side-Loading (например, в клиенте ВКС) нам необходимо модифицировать DLL-библиотеку, загружаемую при запуске исполняемого файла клиента, и внедрить в нее следующую функциональность:

• запуск в памяти процесса собственного инструмента удаленного администрирования и установление защищенного соединения с C2-сервером по протоколам HTTPS/DNS;
• перемещение DLL с полезной нагрузкой в заданную директорию в целевой системе;
• обеспечение персистентности на скомпрометированной системе в соответствии с полученными пользовательскими привилегиями;
• реализация механизмов противодействия динамическому анализу в Sandbox-среде, предотвращение запуска на виртуальных машинах и блокировка исполнения вне доменной инфраструктуры компании;
• отображение графического UI-интерфейса (имитирующего, к примеру, процесс обновления клиента ВКС) для логичного завершения сценария атаки.

Remote Administration Tool

Мы всегда ставим операционную безопасность во главу угла, поэтому принципиально не используем публичные С2-фреймворки (Havoc, Empire, Mythic), утекшие версии коммерческих решений (Cobalt Strike, Brute Ratel) или коммерческие инструменты по подписке (вроде Nighthawk и OST Outflank C2). Мы не можем подвергать инфраструктуру заказчиков гипотетическому риску в виде потенциальной закладки в коде публичных или коммерческых инструментов, которые могут тайно отправить данные на чужие серверы и скомпрометировать чувствительную информацию. Поэтому мы вкладываем значительные ресурсы в разработку собственных инструментов, отвечающих стандартам оперативной безопасности и обладающих нужной функциональностью для проведения Red Team операций. 

Для туннелирования и управления скомпрометированной системой мы используем собственный RAT-агент, обеспечивающий выполнение консольных команд и коммуникацию по TCP/DNS/HTTPS-протоколам между целевой машиной и нашим командным сервером.

Persistence via COM-objects

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

Техник закрепления на Windows достаточно много: мы выбираем COM-объекты. Это очень обширная тема, которую невозможно полностью раскрыть в одной статье, но есть много хороших материалов — почитайте.

Итак, COM (Component Object Model) — это разработанная Microsoft технология, которая позволяет программам взаимодействовать друг с другом, даже если они написаны на разных языках программирования.

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

Приоритеты системы: HKCU > HKLM

Ключевыми местами для хранения информации о COM-объектах являются разделы реестра Windows HKLM, HKCU и HKCR. Давайте рассмотрим их подробнее:

• HKLM (HKEY_LOCAL_MACHINE). Хранит общесистемную информацию о COM-объектах, которая применяется ко всем пользователям компьютера. Включает такие детали, как местонахождение кода объекта и способы его использования, что важно для операций системного уровня.
• HKCU (HKEY_CURRENT_USER). Хранит информацию о COM-объектах, специфичную для пользователя. Включает настройки и конфигурации, уникальные для текущего пользователя, что позволяет использовать персонализированные настройки и предпочтения.
• HKCR (HKEY_CLASSES_ROOT). Объединяет информацию из HKLM и HKCU. Комбинирует данные, упрощая приложениям доступ к необходимым сведениям без необходимости проверки нескольких мест.

Эти разделы включают ключи реестра, которые важны для нас, как для атакующих:

• InProcServer32 — указывает путь к DLL, которая выполняется в памяти процесса текущего приложения, вызываемого COM-объектом.
• LocalServer32 — задает путь к EXE-файлу, который запускается как отдельный процесс для работы с COM-объектом.
• TreatAs — перенаправляет запросы на другой COM-объект по его CLSID-идентификатору.

Ключевой момент, касающийся разделов и ключей реестра, заключается в том, что они имеют разные приоритеты в системе. Так, раздел HKCU имеет приоритет над конфигурациями в разделе HKLM. Это сделано для того, чтобы пользовательская конфигурация (HKCU) определяла персональные настройки активного пользователя. Более того, ключи реестра тоже имеют свой приоритет: TreatAs приоритетнее, чем InProcServer32, а InProcServer32 приоритетнее, чем LocalServer32. 

Подводя итог, получаем шкалу приоритетов для поиска COM-объектов в системе:

Здесь для нас, как для атакующих, начинается все самое интересное, потому что мы видим, что ключ реестра InProcServer32 в разделе HKCU имеет приоритет над аналогичным ключом реестра в разделе HKLM. Это означает, что мы можем обеспечить закрепление на машине жертвы без использования административных привилегий, найдя нужный COM-объект. 

Векторы и способы закрепления с помощью COM-объектов

Рассмотрим два основных вектора: через разделы реестра HKCU и HKLM. У каждого из них есть свои особенности:

• Путь через HKCU не требует прав администратора, однако необходимо найти «магический» COM-объект с идентификатором, который регулярно вызывается действиями пользователя (например, при запуске приложений Microsoft Office).
• Для использования HKLM требуются административные привилегии, а для некоторых COM-объектов даже права TrustedInstaller (хотя повышение привилегий с администратора до TrustedInstaller не представляет большой сложности — это просто дополнительный шаг и логика в полезной нагрузке). Закрепление через HKLM надежнее и не зависит от пользовательских действий.

Наиболее эффективные векторы поиска включают:

• фантомные COM-объекты, ссылающиеся на несуществующие DLL/EXE;
• отсутствующие в HKCU COM-объекты, для которых можно создать значения, указывающие на наши файлы;
• часто используемые COM-объекты.

Оптимальный подход — комбинировать отсутствующие в HKCU и часто используемые COM-объекты. Логика нашей полезной нагрузки опирается именно на этот подход.

Execution

Как было отмечено ранее, для запуска полезной нагрузки мы выбираем вектор DLL Side-Loading. 

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

Итоговая вариация атакующего чейна

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

Фокус-группы

Фокус-группа фишинга

Имея на руках Global Address List, приступаем к формированию фокус-группы для таргетированного фишинга. Ориентируемся на следующие критерии:

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

А что, если…

На стадии формирования фокус-группы мы сразу применяем проактивный подход «А что, если…?», предусматривая различные сценарии и подбирая кандидатуры, с которыми сможем взаимодействовать по нескольким каналам коммуникации.

Так, мы учитываем риск «А что, если сотрудники знакомы между собой?» и соблюдаем баланс между представителями разных подразделений. Это снижает вероятность обсуждения нашего сценария при общении между сотрудниками, что может привести к запуску сарафанного радио или уведомлению SOC о фишинговой атаке.

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

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

Фокус-группа мимикрии

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

Итоговый список фокус-групп

Мимикрия:

whenCreated: 2024-03-21 13:35:47
whenChanged: 2025-01-07 09:30:45
mail: i.i.voronov@bank.ru
displayNamePrintable: i.i.voronov
mailNickname: i.i.voronov
givenName: Ivan
cn: Voronov Ivan Ivanovich
sn: Voronov
company: «Банк»
title: Старший специалист
department: Управление безопасности приложений
mobile: +79001112233
PR_TRANSMITABLE_DISPLAY_NAME: Ivan voronov
st: Office Location
proxyAddresses: ['smtp:i.i.voronov@bank.ru', 'SMTP:i.i.voronov@againbank.ru']
name: Voronov Ivan Ivanovich

Фишинг:

whenCreated: 2024-11-21 13:37:47
whenChanged: 2025-01-07 19:12:31
mail: p.moskvina@bank.ru
displayNamePrintable: p.moskvina
mailNickname: p.moskvina
givenName: Polina
cn: Москвина Полина Павловна
sn: Moskvina
company: «Банк»
title: Младший аналитик
department: Отдел аналитики
mobile: +79203334455
description: ['Дата выхода: 21.11.2024']

Этап третий — реализация

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

«Доверяй, но проверяй»

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

В качестве меры предосторожности можно связаться с первой жертвой из фокус-группы по телефону, используя заранее подготовленный сценарий претекста.

Имя отчество, добрый день!)
Это <имя фамилия> из Управления безопасности приложений <название компании> беспокоит.
Коллеги из безопасности оставили нам заявку на обновление <название ВКС> на твоем компьютере.
Подскажи, тебе письмо от коллег не приходило на твою почту по поводу обновления с адреса infosecurity@bank.ru?
А какая у тебя почта? <почта> правильно?
Хорошо, попрошу коллег повторно выслать письмо, но могу для оперативности тебе в телеграм выслать PDF-инструкцию.
Там ничего сложного, но будет явно быстрее, сможем закрыть заявку и не ждать коллег.

В рамках вишинг-сценария мы намеренно создаем проблемную ситуацию для жертвы в виде вопроса «Не приходило ли тебе письмо?» и обосновываем важность заявки от коллег из информационной безопасности. А затем сами предлагаем решение: «Могу для оперативности отправить инструкцию в Telegram». Таким образом формируется ситуация win-win: сотрудник не испытывает дискомфорта от срочности и важности вопроса, а мы достигаем своей цели, поскольку жертва соглашается на оперативную помощь с новой проблемой — закрытием заявки. В процессе разговора мы анализируем степень вовлеченности сотрудника в сценарий и его отзывчивость, чтобы принять итоговое решение о целесообразности отправки PDF Luring файла в Telegram. Если ответы сотрудника вызывают сомнения в его доверии к сценарию, лучше поискать другую цель.

Распространенные проблемы при доставке полезной нагрузки

Наиболее часто встречающиеся проблемы (помимо игнорирования сообщений) при отправке PDF Luring файлов:

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

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

Try Harder

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

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

• недоступность URL-адреса с полезной нагрузкой;
• блокировку запуска полезной нагрузкой со стороны AppLocker’а;
• уведомления от средств защиты конечных точек (AV, EDR).

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

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

Я могу ошибиться?

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

После ряда попыток фишинга нам стали очевидны следующие технические нюансы:

• Доставка нашей полезной нагрузки с помощью ссылок на облачные хранилища оказалась невозможной. Перебор различных облачных хранилищ представлялся нецелесообразным, поскольку это было бы равносильно тыканью пальцем в небо. Требовалось разработать более жизнеспособный концепт и вектор атаки.
• Имеющийся арсенал транспортов RAT и его функциональные возможности оказались недостаточными. Для достижения результата и установления обратного соединения из инфраструктуры требовалось придумать и разработать что-то новое, так как типичный набор TCP/DNS/HTTPS не позволял организовать соединение с нашими С2-серверами.
• На рабочих компьютерах сотрудников разрешен и установлен Telegram, трафик которого не ограничивается с помощью NGFW на границе сети.

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

Payload Delivery via abuse GitHub&GitLab CDN

Новый вектор доставки с помощью ссылок был придуман достаточно быстро. Концепция заключается в использовании штатной функциональности комментариев на GitHub&GitLab, которые позволяют загружать файлы в CDN и получать ссылку для скачивания без публикации самого комментария.

Наша идея основывалась на предположении, что GitHub как легитимный сервис, активно используемый R&D-подразделениями компаний, вероятно находится в белом списке или не имеет ограничений при обращении по URL. Это потенциально позволяло доставлять архивы через ссылки на GitHub.

Однако мы столкнулись с проблемой: CDN GitHub'а ограничивает загрузку файлов свыше 25 МБ, тогда как наш боевой архив из-за объемного уязвимого EXE-файла (клиента ВКС в 150 МБ) достигал объема около 80 МБ. В этом случае требуется использовать более легковесный DLL Side-Loading для загрузки в CDN и использования ссылок на GitHub.

«Яндекс Телемост»: CVE-2024-12168

У нас есть туз в рукаве в виде разных легковесных DLL Side-Loading чейнов. Например, на тот момент это был 0-day DLL Side-Loading в клиенте ВКС «Яндекс Телемост», бинарный файл которого весит всего 7,5 МБ, что соответствует требованиям GitHub.

Таким образом, наш архив с полезной нагрузкой весит 8,8 МБ и включает в себя EXE-файл клиента «Яндекс Телемост», а также DLL-библиотеку с полезной нагрузкой. Компактный размер обеспечивает возможность загрузки в CDN с генерацией ссылки для скачивания, которую затем можно внедрить в PDF Luring файлы с инструкциями.

Pavlo Du Rove

Вопрос с вектором доставки полезной нагрузки мы решили. Но все еще остается незакрытой задача по разработке нового транспорта для создания туннеля из инфраструктуры компаний, в корпоративной сети которых нельзя использовать наш штатный набор TCP/DNS/HTTPS-протоколов.

Здесь важно правильно анализировать предварительные итоги фишинга. Например, факт успешной доставки zip-архива через Telegram указывал на то, что этот мессенджер вероятно разрешен к использованию у многих других сотрудников. Это также означало, что в NGFW данный трафик разрешен для выхода во внешний мир и считается легитимным. Бинго! Соответственно, нам всего лишь нужно было быстро доработать TG RAT.

Однако придумать решение всегда проще, чем его реализовать. Нам требовался не просто beacon-агент с возможностью выполнения команд на атакованном хосте, а полноценный SOCKS5 over Telegram с агентом и сервером на нашей стороне. В интернете достаточно много готовых фрагментов кода для работы TG RAT в режиме выполнения консольных команд, у нас также имелись собственные наработки, однако функционал SOCKS5 в них отсутствовал.

Превращаем Telegram в RAT

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

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

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

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

Наша реализация состояла из клиента (агент TG RAT на машине жертвы) и сервера (на нашей стороне):

• При запуске на стороне жертвы клиент оповещает сервер через Telegram-канал, после чего сервер открывает SOCKS-порт. 
• При подключении к этому порту клиент устанавливает TCP-соединение с нужной системой. 
• Весь трафик, приходящий на открытый порт, нарезается и преобразуется в формат, необходимый для корректной передачи клиенту путем отправки Telegram-сообщений. Сервер упаковывает данные в сообщения, клиент их распаковывает и направляет в TCP-соединение, а ответы пересылает обратно тем же способом. 

По сути, мы создали SOCKS-туннель, где Telegram работает как транспорт.

В целях ускорения процесса первая боевая версия была написана на С#, но потом мы переписали ее на С++ для оптимизации и устранения определенных недостатков.

В свою очередь, трафик в чате с ботом выглядел как бесконечный поток эмодзи:

Час SE

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

Итак, все готово к финалу: новый вектор доставки, новый транспортный канал через Telegram и действующие учетные данные для работы с почтовым ящиком через EWS.

Давление в одну точку

Если вы увлекаетесь литературой о военном искусстве и стратегических принципах, то можете найти некоторые параллели в проведении Red Team-операций с тезисами из книги «On War» прусского генерала Карла фон Клаузевица: «Силы должны быть сконцентрированы в подавляющую массу. Это фундаментальная мысль. Всегда готовьтесь ко всему и как можно заранее». Эта аналогия особенно актуальна в контексте социальной инженерии: нецелесообразно распылять ресурсы на проведение множества атак с разными TTP без четкого понимания их эффективности. Например, нет смысла перебирать векторы получения начального доступа — от офисных документов с макросами до экспериментов с разными файловыми расширениями, позволяющими выполнять консольные команды (.bat, .cmd, .vbs и др.). Более грамотным решением будет сконцентрироваться на тщательной подготовке и сборе всех сил на одном эффективном векторе: нужно атаковать инфраструктуру на самом узком участке киберфронта, заставляя принцип силы и концентрации усилий работать на вас. 

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

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

На стороне жертвы отправленное нами письмо выглядит следующим образом:

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

Развитие атаки

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

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

Для наших целей достаточно возможности туннелирования трафика в направлении контроллеров домена для сбора:

• слепка LDAP через ADExplorer или BloodHound — для формирования графового представления структуры Active Directory и определения вектора получения максимальных привилегий в инфраструктуре;
• информации о шаблонах сертификатов службы Active Directory Certificate Services — для обнаружения путей получения максимальных привилегий на основе уязвимых шаблонов для ESC-атак.

Если со сбором информации о шаблонах сертификатов службы Active Directory Certificate Services проблем не возникло, то при формировании слепка LDAP мы несколько раз сталкивались с нестабильной работой Telegram-канала передачи данных при обработке больших объемов информации. Нестабильность выражалась в виде переподключения агента к серверу, что приводило к прерыванию процесса сбора слепка LDAP.

Безусловно, TG RAT прошел предварительное тестирование в нашей лаборатории и на доменной инфраструктуре Positive Technologies. Однако количество объектов в доменной структуре компаний из финансового сектора и Позитива — это принципиально разные масштабы. То, что TG RAT демонстрировал стабильную работу при сборке BloodHound и функционировании наших инструментов в нашей корпоративной инфраструктуре, не гарантировало аналогичной производительности в боевых условиях в инфраструктуре заказчиков, хотя мы очень на это рассчитывали.

SOC наносит ответный Virus Total удар

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

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

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

Повторяем упражнение

Нащупав слабую точку, нужно продолжать давить, однако важно анализировать первый успешный опыт получения начального доступа и устранять выявленные недостатки. Иными словами, нужно «найти слабость в нашей силе» перед последующими фишинговыми атаками, так как сторона защиты будет лучше готова к новым атакам.

Устранение недостатков TTP

Например, помимо нестабильной работы TG RAT, мы обнаружили следующие просчеты на одном из проектов:

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

• Несмотря на стремление к диверсификации инструментов туннелирования, мы упустили из виду ранее проверенный инструмент для создания туннеля на основе TCP-протокола к С2-серверу облачного провайдера с использованием технологии Domain Fronting, который успешно применяли на других проектах.

Возвращение в инфраструктуру

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

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

При этом мы понимаем, что продолжительно работать через корпоративное устройство сотрудника вероятно уже не сможем. К тому моменту команда реагирования заказчика может разработать специфические сигнатуры на наши TTP и характерное ПО, сократив показали TTD и TTR. 

Чаще всего мы используем первичное получение начального доступа к корпоративной инфраструктуре с помощью социальной инженерии, чтобы провести разведку и выгрузить результаты сбора графового представления доменной инфраструктуры с помощью BloodHound/SharpHound/ADExplorer для последующего локального анализа и выявления вектора получения максимальных привилегий в домене. Поэтому первоочередной задачей после повторного получения начального доступа к инфраструктуре с помощью таргетированного фишинга становится реализация «блицкрига» по получению максимальных привилегий в корпоративной сети. Но это уже совсем другая история...

Заключение

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

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

Мы убеждены в том, что Red Team проект должен приносить пользу обеим сторонам — как атакующим, так и защитникам. Именно поэтому мы вкладываем значительные ресурсы и усилия в проведение уникальных Red Team операций для наших заказчиков: не ограничиваемся эмуляцией общеизвестных TTP хакерских группировок, а демонстрируем более сложные сценарии, нацеленные на верификацию недопустимых событий.