stihl не предоставил(а) никакой дополнительной информации.
В этой статье я расскажу про необычный кейс фишинговой атаки: поскольку жертвы не поддавались на простой фишинг, нам с коллегами пришлось создать поддельную персону разработчика, а также троянское приложение, якобы созданное им. И вот оно наконец‑то сделало свое дело.
Это исследование получило третье место на Для просмотра ссылки Войдиили Зарегистрируйся в категории «Ловись, рыбка». Соревнование ежегодно проводится компанией Awillix.
Все это происходило в рамках редтиминга и по контракту. Перед началом тестирования заказчик предоставил нам:
Когда разобрались со сторонним сервисом для доставки писем, взяли открытую AITM‑платформу Evilginx, слегка адаптировали ее (выпилили пасхалки из кода) и настроили редирект на фишинговую страницу логина Gmail.
В арсенале у нас был Evilginx с кастомным фишлетом для обхода MFA в экосистеме Google: через подход Browser-in-the-Middle он ворует сессионные куки Gmail после ввода кода и умеет обходить и статические, и эвристические проверки Chrome, включая Google Safe Browsing. Фишинговую страницу мы собрали и прогнали на актуальных защитах Chrome и Firefox.
Внешний вид фишинговой страницы авторизации
Чтобы не палиться перед ботами и снизить риск, что домен отметят как фишинговый, мы подняли сервис на Microsoft Azure Functions. Он маскирует фишинговую страницу, обфусцируя JavaScript и редиректы, и злоупотребляет доверием к домену Azure App Service (*.azurewebsites.net).
В редиректоре тоже были «канарейки» (canary links) — ссылки, которые нужны только для фиксации клика. Их использовали для отслеживания взаимодействий вместо других механизмов вроде magic byte.
Чтобы слать письма от домена заказчика, мы использовали встроенный инструмент платформы для email‑уведомлений. Он не ограничивал содержимое, так что через почтовые сервисы заказчика можно было отправлять любые сообщения.
Кампания строилась на рассылке автоматизированных приглашений ключевым сотрудникам компании заказчика с призывом завершить регистрацию. Ниже — образец письма из теста: оно стабильно обходило спам- и контент‑фильтры Gmail.
Пример фишингового письма
На следующий день после рассылки домен пометили как фишинговый, внутреннюю команду предупредили: не открывать ссылки и не вводить данные.
Итог: один клик по ссылке, ноль перехватов данных.
Мы дополнительно выяснили, какую стороннюю платформу Web3‑аналитики использует заказчик: подсказку нашли в описании вакансии на их сервере Discord.
Дальше мы попытались сыграть на доверии к легитимному сайту. При разборе нашли пачку уязвимостей (их потом передали компании) и утечки внутренней инфы. По ним стало ясно, что сотрудники заказчика авторизуются через Google Workspace SSO: у корпоративных профилей — аватарки из Gmail. На бэкенде торчала устаревшая почтовая служба уведомлений, через нее можно было настраивать боевые каналы оповещения по почте.
Изначально сервис умел слать только специально сформатированные письма, но из‑за уязвимости в валидации ввода можно было перезаписать шаблон и подсунуть произвольный HTML — по сути, собрать любое письмо. Эти письма уходили с основного почтового домена заказчика, так что выглядели полностью легитимно.
Текст письма мы собрали из того, что нашли во время первичной и дополнительной разведки, плюс из утечек, выявленных при разборе сайта заказчика. Ниже — пример фишингового письма из кампании. Оно стабильно проходило мимо спам‑фильтров Gmail.
Пример фишингового письма
После второй кампании мы сменили вектор: по итогам двух запусков заказчик уверенно держит оборону против email‑фишинга.
Итог: один переход по ссылке, ноль перехваченных данных.
На этот раз мы сделали ставку на простую механику: у заказчика свой Discord‑сервер, где любой участник может подать заявку через форму на сервере и по пути накапливать бонусы в комьюнити. Мы разобрали все анкеты и увидели тренд: чаще всего побеждали заявки с понятной инфой и цифрами.
Мы решили, что стабильный доступ с возможностью выполнять команды на рабочих машинах сотрудников заказчика — самый прямой путь к критическим системам их инфраструктуры. Плюс такой подход убирает из уравнения фишинг и охоту за валидными учетками.
В итоге мы собрали приложение на TypeScript — корпоративный дашборд. С его помощью ты отслеживаешь баллы и их накопление, смотришь таблицы лидеров и ищешь пользователей по уникальному адресу. Ниже — скриншот интерфейса.
Пример скриншота из фишингового приложения
Исходники приложения были чистыми — ни бэкдоров, ни прочей шелухи. Зато пайплайн сборки пакета npm включал доставку малвари — C2‑импланта для macOS. План был выдать это за community‑приложение от стороннего автора, якобы для упрощения работы в компании. Имплант — наша сборка на базе модифицированного фреймворка Sliver от Bishop Fox.
Вот вопросы, которые всплыли по ходу дела и которые пришлось решать:
После запуска стартовый пейлоад стучался на конкретный URL на редиректоре. Первый редир сразу кидал 302 на другой URL с рандомным MD5-хешем для маскировки. Дальше запрос проксировался на реальный C2‑сервер, доступный только через этот шлюз. Многоуровневая цепочка редиректоров требовала знания точных уникальных путей, так что детектить ее было сложно.
Кроме C2‑сервера, на конечном хосте лежали и Bash‑скрипты, которые тоже выполнялись, например:
Сценарий сначала проверяет, не крутится ли уже имплант. Если нет — ставит и запускает новый. Если да — просто перезапускает, чтобы держать соединение с C2-сервером. Такой подход дает хорошую живучесть и дополнительно прячет C2‑инфраструктуру.
Плюс мы написали скрипт очистки: запускаешь его на зараженном хосте — и он сразу удаляет подложенные скрипты и бинарник загрузчика. Перед любыми правками он автоматически делает бэкапы всех файлов профиля, которые собирается менять.
В итоге мы ловили новую C2-сессию каждый раз, когда пользователь запускал интерактивную оболочку: открывал терминал, перезагружал машину или логинился. Реальное местоположение импланта оставалось скрытым.
Доступ к C2-серверу мы прикрыли облачным файрволом DigitalOcean: пропускали трафик только с редиректора и IP-адресов редтимеров. Это отрезало внешних любопытных от любых чувствительных данных.
Заявку на участие отправили от фейковой личности разработчика, собранной вокруг старого аккаунта GitHub редтимера; последний след там — 2019 год. Чтобы создать видимость жизни, накрутили активность: наштамповали фиктивные коммиты в приватные репы, подбустили contribution graph и прочее.
История коммитов использованного аккаунта
Мы создали зеркальные аккаунты фейкового разработчика в X и Telegram. Некоторое время они только ретвитили и репостили, в основном твиты компании‑заказчика, чтобы аккаунты выглядели легитимно.
На этапе доставки, чтобы не выпустить вредонос в паблик, мы использовали Для просмотра ссылки Войдиили Зарегистрируйся. Ссылкой GitFront можно делиться: по ней клонируют приватный репозиторий без приглашений в GitHub. Этот шаг нужен, чтобы не заразить непричастных пользователей.
Заявку отправили через Typeform из Discord-сообщества заказчика: коротко рассказали о команде, объяснили цель и добавили детали о приложении. Параллельно по договоренности с заказчиком сразу после отправки пингнули их техконтакт. Так мы исключили утечку заявки за пределы компании и риск случайно заразить посторонних.
Через какое‑то время на нашем C2 всплыла сессия: кто‑то из техподдержки, разбирая нашу заявку, поставил собранное нами приложение по инструкции. На скрине ниже — первые импланты, успешно отрабатывающие на macOS‑хостах разработчиков. Новый имплант стартовал каждый раз, когда разработчик открывал новую сессию терминала.
Активные импланты на хостах разработчиков компании‑заказчика
Это исследование получило третье место на Для просмотра ссылки Войди
Все это происходило в рамках редтиминга и по контракту. Перед началом тестирования заказчик предоставил нам:
- список ключевых технических специалистов компании;
- контактные данные сотрудников: имена, адреса электронной почты, никнеймы в Telegram.
Кампания 1
Этап разведки показал, что у заказчика почта на Google Workspace (корпоративном Gmail). У Gmail жесткие антиспам‑фильтры, плюс сейчас в Web3 тему фишинга не игнорят. Поэтому мы искали варианты для точечных рассылок с реальных почтовых сервисов сторонних платформ, которыми пользуется заказчик. Письма с легитимных доменов вызывают больше доверия и реже летят в спам.Когда разобрались со сторонним сервисом для доставки писем, взяли открытую AITM‑платформу Evilginx, слегка адаптировали ее (выпилили пасхалки из кода) и настроили редирект на фишинговую страницу логина Gmail.
В арсенале у нас был Evilginx с кастомным фишлетом для обхода MFA в экосистеме Google: через подход Browser-in-the-Middle он ворует сессионные куки Gmail после ввода кода и умеет обходить и статические, и эвристические проверки Chrome, включая Google Safe Browsing. Фишинговую страницу мы собрали и прогнали на актуальных защитах Chrome и Firefox.
Чтобы не палиться перед ботами и снизить риск, что домен отметят как фишинговый, мы подняли сервис на Microsoft Azure Functions. Он маскирует фишинговую страницу, обфусцируя JavaScript и редиректы, и злоупотребляет доверием к домену Azure App Service (*.azurewebsites.net).
В редиректоре тоже были «канарейки» (canary links) — ссылки, которые нужны только для фиксации клика. Их использовали для отслеживания взаимодействий вместо других механизмов вроде magic byte.
Чтобы слать письма от домена заказчика, мы использовали встроенный инструмент платформы для email‑уведомлений. Он не ограничивал содержимое, так что через почтовые сервисы заказчика можно было отправлять любые сообщения.
Кампания строилась на рассылке автоматизированных приглашений ключевым сотрудникам компании заказчика с призывом завершить регистрацию. Ниже — образец письма из теста: оно стабильно обходило спам- и контент‑фильтры Gmail.
На следующий день после рассылки домен пометили как фишинговый, внутреннюю команду предупредили: не открывать ссылки и не вводить данные.
Итог: один клик по ссылке, ноль перехватов данных.
Кампания 2
После провала первой фишинговой кампании мы решили действовать точнее: протестировали несколько сценариев — доставку ссылок на фишлет для Google через Telegram и другие трюки. Но ни один вариант не получился достаточно убедительным.Мы дополнительно выяснили, какую стороннюю платформу Web3‑аналитики использует заказчик: подсказку нашли в описании вакансии на их сервере Discord.
Дальше мы попытались сыграть на доверии к легитимному сайту. При разборе нашли пачку уязвимостей (их потом передали компании) и утечки внутренней инфы. По ним стало ясно, что сотрудники заказчика авторизуются через Google Workspace SSO: у корпоративных профилей — аватарки из Gmail. На бэкенде торчала устаревшая почтовая служба уведомлений, через нее можно было настраивать боевые каналы оповещения по почте.
Изначально сервис умел слать только специально сформатированные письма, но из‑за уязвимости в валидации ввода можно было перезаписать шаблон и подсунуть произвольный HTML — по сути, собрать любое письмо. Эти письма уходили с основного почтового домена заказчика, так что выглядели полностью легитимно.
Текст письма мы собрали из того, что нашли во время первичной и дополнительной разведки, плюс из утечек, выявленных при разборе сайта заказчика. Ниже — пример фишингового письма из кампании. Оно стабильно проходило мимо спам‑фильтров Gmail.
После второй кампании мы сменили вектор: по итогам двух запусков заказчик уверенно держит оборону против email‑фишинга.
Итог: один переход по ссылке, ноль перехваченных данных.
Кампания 3
Эту кампанию мы запустили еще до завершения предыдущей. Кампания 3 вышла намного удачнее: мы получили доступ к хостам сотрудников компании‑заказчика и закрепились на них.На этот раз мы сделали ставку на простую механику: у заказчика свой Discord‑сервер, где любой участник может подать заявку через форму на сервере и по пути накапливать бонусы в комьюнити. Мы разобрали все анкеты и увидели тренд: чаще всего побеждали заявки с понятной инфой и цифрами.
Мы решили, что стабильный доступ с возможностью выполнять команды на рабочих машинах сотрудников заказчика — самый прямой путь к критическим системам их инфраструктуры. Плюс такой подход убирает из уравнения фишинг и охоту за валидными учетками.
В итоге мы собрали приложение на TypeScript — корпоративный дашборд. С его помощью ты отслеживаешь баллы и их накопление, смотришь таблицы лидеров и ищешь пользователей по уникальному адресу. Ниже — скриншот интерфейса.
Исходники приложения были чистыми — ни бэкдоров, ни прочей шелухи. Зато пайплайн сборки пакета npm включал доставку малвари — C2‑импланта для macOS. План был выдать это за community‑приложение от стороннего автора, якобы для упрощения работы в компании. Имплант — наша сборка на базе модифицированного фреймворка Sliver от Bishop Fox.
Вот вопросы, которые всплыли по ходу дела и которые пришлось решать:
- Скрытность и живучесть: добиться, чтобы имплант и инфраструктура C2 не палились и продолжали работать при EDR/AV, сканерах кода и после обновлений macOS.
- Незаметность доставки: скрыть механизм доставки импланта на машину цели так, чтобы разработчики заказчика, анализируя исходный код, ничего не заподозрили.
После запуска стартовый пейлоад стучался на конкретный URL на редиректоре. Первый редир сразу кидал 302 на другой URL с рандомным MD5-хешем для маскировки. Дальше запрос проксировался на реальный C2‑сервер, доступный только через этот шлюз. Многоуровневая цепочка редиректоров требовала знания точных уникальных путей, так что детектить ее было сложно.
Кроме C2‑сервера, на конечном хосте лежали и Bash‑скрипты, которые тоже выполнялись, например:
- Первый скрипт определял ОС хоста: macOS или Linux.
- Второй прописывал постоянный Bash-скрипт в профиль пользователя: в ~/.zprofile (Zsh на macOS) или ~/.profile (Linux).
Сценарий сначала проверяет, не крутится ли уже имплант. Если нет — ставит и запускает новый. Если да — просто перезапускает, чтобы держать соединение с C2-сервером. Такой подход дает хорошую живучесть и дополнительно прячет C2‑инфраструктуру.
Плюс мы написали скрипт очистки: запускаешь его на зараженном хосте — и он сразу удаляет подложенные скрипты и бинарник загрузчика. Перед любыми правками он автоматически делает бэкапы всех файлов профиля, которые собирается менять.
В итоге мы ловили новую C2-сессию каждый раз, когда пользователь запускал интерактивную оболочку: открывал терминал, перезагружал машину или логинился. Реальное местоположение импланта оставалось скрытым.
Доступ к C2-серверу мы прикрыли облачным файрволом DigitalOcean: пропускали трафик только с редиректора и IP-адресов редтимеров. Это отрезало внешних любопытных от любых чувствительных данных.
Заявку на участие отправили от фейковой личности разработчика, собранной вокруг старого аккаунта GitHub редтимера; последний след там — 2019 год. Чтобы создать видимость жизни, накрутили активность: наштамповали фиктивные коммиты в приватные репы, подбустили contribution graph и прочее.
Мы создали зеркальные аккаунты фейкового разработчика в X и Telegram. Некоторое время они только ретвитили и репостили, в основном твиты компании‑заказчика, чтобы аккаунты выглядели легитимно.
На этапе доставки, чтобы не выпустить вредонос в паблик, мы использовали Для просмотра ссылки Войди
Заявку отправили через Typeform из Discord-сообщества заказчика: коротко рассказали о команде, объяснили цель и добавили детали о приложении. Параллельно по договоренности с заказчиком сразу после отправки пингнули их техконтакт. Так мы исключили утечку заявки за пределы компании и риск случайно заразить посторонних.
Через какое‑то время на нашем C2 всплыла сессия: кто‑то из техподдержки, разбирая нашу заявку, поставил собранное нами приложение по инструкции. На скрине ниже — первые импланты, успешно отрабатывающие на macOS‑хостах разработчиков. Новый имплант стартовал каждый раз, когда разработчик открывал новую сессию терминала.