Operation HookedWing — фишинговая кампания, активная с 2022 года. Исследователи нашли более 2000 украденных учётных данных из более чем 500 организаций. Жертвами стали авиация, энергетика, госструктуры, критическая инфраструктура, логистика, финансы и ИТ. Атака использовала GitHub Pages и похожие платформы для посадочных страниц, имитировала Outlook, подставляла почту и домен организации, затем динамически загружала PHP-форму для кражи пароля, IP-адреса и геоданных.
Исследователи раскрыли многолетнюю фишинговую кампанию Operation HookedWing, которая работала с 2022 года и затронула более 500 организаций. В восстановленных логах нашли более 2000 украденных учётных данных. Среди жертв — компании и учреждения из авиации, энергетики, критической инфраструктуры, логистики, госсектора, финансов и технологий. Кампания оставалась активной к моменту публикации исследования 7 мая 2026 года.
HookedWing не похожа на разовую рассылку «проверьте вложение». Оператор годами менял инфраструктуру, добавлял новые языки и приманки, но сохранял узнаваемую логику набора: письмо с просьбой открыть документ, переход на страницу через GitHub Pages или похожий хостинг, имитация загрузки Outlook, подстановка названия организации и форма входа, которая забирает пароль вместе с IP-адресом, геолокацией и доменом компании.
SecurityWeek кратко описал выводы отчёта: кампания использовала темы Microsoft и Outlook, ссылки на GitHub-репозитории, компрометированные серверы и персонализированные страницы входа. В 2024–2025 годах появились франкоязычные варианты, а с 2025 года выросло число активных площадок, тем и промежуточных страниц.
Главная особенность HookedWing — не новая уязвимость в Microsoft, GitHub или браузере. Это хорошо собранная схема кражи паролей. Злоумышленники использовали легитимные платформы как первый слой доставки, потому что домены github.io, Vercel, Netlify и похожие сервисы часто выглядят для фильтров менее подозрительно, чем свежезарегистрированные домены. Уже после перехода жертвы форма входа подтягивалась с серверов управления, среди которых были взломанные сайты компаний и специально созданная инфраструктура.
Чаще всего письма выдавали себя за сообщение от HR, коллеги или сервиса для обмена документами. Встречались темы Microsoft, Outlook, Google Drive, Google Docs, PDF и «защищённых» файлов. Тон — срочный, но без сложной верстки: пользователю предлагали открыть документ или выполнить действие по ссылке. Такая простота здесь работает на атаку: письмо не выглядит как перегруженный шаблон из массового фишинга.
Ссылка часто содержала адрес получателя после символа #, например в формате github.io/.../#user@company. Важно, что фрагмент URL после # не уходит на сервер в обычном HTTP-запросе. GitHub не получает этот кусок как часть обращения к странице, а фишинговый набор считывает адрес уже в браузере жертвы. Такой приём усложняет пассивную привязку конкретной жертвы к промежуточному домену по серверным логам.
После открытия страницы пользователь видел полноэкранный экран загрузки, похожий на поведение Outlook. В это время JavaScript проверял наличие почты в URL, извлекал домен организации, связывался с сервером управления и получал данные для персонализации. В одном из описанных сценариев страница показывала название организации перед появлением формы. Это не взлом корпоративного портала, а психологический трюк: человек видит знакомое имя и охотнее вводит пароль.
Сама форма входа не лежала в GitHub-репозитории. Её динамически подгружал PHP-скрипт с серверной части. Такой разнос ролей затрудняет разбор: на статической странице можно увидеть только загрузчик и внешние скрипты, а поле для пароля появляется уже после обращения к серверу управления. В коде набора исследователи нашли повторяющиеся элементы, включая пространство имён stef, переменную window.stef.srv_loc, путь /genl/и характерные PHP-эндпоинты. Эти признаки помогли связать отдельные домены в одну кампанию.
Форма собирала не только логин и пароль, но и адрес почты, IP-адрес, данные про страну, город, координаты, исходный URL и домен организации. Дополнительно набор обращался к публичному API для получения геоданных. В ряде случаев фейковая форма показывала ошибку после первой попытки входа, заставляя пользователя ввести пароль повторно. Такой приём повышает шанс получить корректный пароль, если человек в первый раз ошибся или набрал его на автопилоте.
Масштаб инфраструктуры тоже заметный. Исследователи нашли более 20 серверов управления, более 100 доменов распространения на GitHub и ещё 15–20 доменов на других платформах. Часть серверов управления размещалась на взломанных легитимных сайтах компаний и организаций. В отчёте упоминаются площадки в Пакистане, Бразилии, Чили, Сенегале и Афганистане, а также общие хостинги, где под угрозой могли оказаться сразу несколько доменов.
Целевые отрасли показывают, что кампания не ограничивалась случайными пользователями. Больше всего пострадавших нашли в авиации, госуправлении, энергетике и критической инфраструктуре. Второй круг — логистика, транспорт, производство и технологические компании. Украденные корпоративные учётные записи ценны сами по себе: их можно использовать для входа в почту, доступа к документам, рассылки фишинга от имени реального сотрудника, продажи другим группам или подготовки более глубокой атаки.
Исследователи пишут, что фишинговый набор на момент публикации не привязан к известной группе. Но масштаб и выбор отраслей говорят о подготовленном операторе, но не доказывают конкретного заказчика или страну происхождения.
APWG ведёт регулярные отчёты по фишинговым атакам и с 2004 года отдельно отслеживает уникальные почтовые приманки и сайты для сбора данных. Это хорошо описывает эволюцию проблемы: фишинг давно перестал быть только письмом с кривой ссылкой, теперь это связка почты, легитимного хостинга, динамических форм, персонализации и серверной логики.
Для защитников HookedWing интересна устойчивыми признаками. Блокировать только отдельные домены недостаточно: оператор менял инфраструктуру годами. Полезнее искать цепочку поведения — ссылки на github.io или похожие статические хостинги с почтой после #, страницы с имитацией Outlook, запросы к PHP-эндпоинтам вроде /genl/, формы с предзаполненной почтой, странные обращения к внешним геосервисам и повторяющиеся JavaScript-артефакты из набора.
Практический минимум для компаний: включить многофакторную аутентификацию без SMS там, где это возможно, настроить защиту от фишинга с проверкой целевой страницы, ограничить входы из нетипичных стран, следить за массовыми ошибками входа, проверять OAuth-согласия, анализировать пересылки почты и быстро сбрасывать пароли после срабатываний. Для почтовой защиты полезно отдельно проверять ссылки, где адрес пользователя спрятан после #: это не всегда атака, но для корпоративной почты такой паттерн должен вызывать вопросы.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
