Фишинговые рассылки стали заметно умнее: теперь они умеют определять устройство и операционную систему жертвы еще до выдачи вредоносной нагрузки. Адаптивный фишинг больше не работает по схеме «разослали всем один и тот же файл и посмотрели, кто клюнет»; он подбирает сценарий под Windows, macOS и другие платформы, а значит, повышает вероятность взлома и окупаемость кампании.
Об этом 1 июля сообщает Dark Reading со ссылкой на исследование Cofense Intelligence. По данным компании, злоумышленники все чаще собирают данные о жертве уже после клика по ссылке или открытия вложения: они анализируют user-agent браузера и на его основе строят профиль устройства. В этот профиль могут входить адрес электронной почты, тип браузера, сведения об устройстве, язык, локальное время, размер экрана и окна, а также геолокация. После этого человеку показывают не просто фальшивую страницу, а тот вариант атаки, который лучше всего подходит именно для его среды.
Ключевая деталь в том, что развилка происходит не на этапе письма, а уже после взаимодействия пользователя с приманкой. Cofense отмечает, что все чаще встречается схема с блокировкой и перенаправлением по user-agent через Cloudflare: трафик уходит на разные страницы в зависимости от того, какую ОС распознал сервис. Для атакующих это удобный вариант. Не нужно писать собственные скрипты распознавания, а доставка «правильной» нагрузки начинает работать почти автоматически. Если жертва заходит с Mac, ей показывают один сценарий; если с Windows, другой. В результате одна и та же инфраструктура начинает выжимать больше пользы из каждого клика.
В исследовании приводится конкретный пример: одна фишинговая страница выдавала FleetDeck для macOS или Tiflux RAT для Windows в зависимости от того, что увидели атакующие при первичном fingerprinting. Сам по себе ход довольно показательный. Вместо универсального вредоноса, который может сломаться на половине устройств, жертве приносят то, что лучше ляжет именно в ее стек. При этом часть инструментов, которые используются в таких кампаниях, технически выглядят как легитимные средства удаленного доступа, просто переупакованные в трояны удаленного администрирования. Для сигнатурной защиты это плохая новость: когда инструмент на бумаге похож на обычный remote access software, автоматическая фильтрация начинает ошибаться чаще, чем хотелось бы ИБ-команде.
Отдельно Cofense указывает на рост использования Telegram для вывода и хранения украденных данных. Это тоже логичный сдвиг в экономике атак. Чем меньше у злоумышленников собственной инфраструктуры, тем ниже порог входа и тем меньше точек, по которым их можно быстро вычислить или заблокировать. Параллельно меняется и визуальная часть атаки. Фишинговые лендинги уже не ограничиваются абстрактной формой логина: они подстраивают обманный интерфейс под телеметрию браузера и имитируют экраны загрузки Google, DocuSign, Microsoft Teams, Adobe или Zoom. Пользователь получает страницу, похожую не просто на знакомый бренд, а на привычный сценарий именно для своей платформы. Это не магия и не «киберпанк 2030», а довольно прагматичная оптимизация конверсии.
Контекст у этой истории понятный. За последние годы фишинг стал заметно профессиональнее сразу по нескольким причинам. Большие языковые модели сняли проблему с неграмотными письмами и деревянным английским. Фишинг-киты дали начинающим злоумышленникам инструменты, которые раньше требовали квалификации и времени. Социальная инженерия тоже усложнилась: достаточно вспомнить рост популярности техник вроде ClickFix, где пользователя аккуратно подталкивают самому выполнить опасное действие под видом исправления ошибки или настройки доступа. На этом фоне адаптивный фишинг выглядит не как экзотика, а как следующая итерация старого рынка, где все крутится вокруг одной метрики: сколько полезного можно извлечь из одного перехода по ссылке.
Для бизнеса и ИТ-команд здесь важен не сам факт «фишинг стал хитрее»; это давно не новость. Важнее то, что защита, завязанная только на фильтрацию письма на входе, становится еще менее достаточной. Max Gannon из Cofense прямо говорит, что руководителям ИБ нужно закрывать разрыв в наблюдаемости между Windows, Mac и мобильными устройствами, чтобы видеть не набор разрозненных инцидентов, а единую кампанию. Иначе компания будет смотреть на атаку кусками: на почтовом шлюзе увидят одно, на Mac-ноутбуках другое, на мобильных устройствах третье, а общая картина соберется слишком поздно. Вторая практическая рекомендация касается того, что происходит после клика. Если мониторинг заканчивается в момент доставки письма в ящик, команда пропускает самое интересное: цепочки редиректов, платформенную развилку и момент выдачи специфической нагрузки.
Для разработчиков, DevOps- и продуктовых команд это тоже не чужая тема. Во многих компаниях парк устройств давно неоднородный: часть сотрудников работает на Windows, часть на macOS, мобильный доступ к корпоративным сервисам стал нормой, а подрядчики часто заходят со своей техники. В такой среде адаптивный фишинг опасен именно тем, что превращает эту разнородность в преимущество для атакующего. Если раньше неподдерживаемая платформа означала потерю трафика, теперь это просто еще одна ветка сценария. Отсюда и довольно приземленные выводы: фишингоустойчивая аутентификация вроде FIDO2 остается актуальной, обучение сотрудников нужно обновлять под более современные приемы, а пользователей стоит рассматривать не как «последнюю линию обороны», а как важный источник сигнала. Когда в компании внезапно появляется непривычный инструмент удаленного доступа, заметить неладное первым нередко способен именно человек, а не очередной сканер с красивым дашбордом.
Следующий логичный шаг для рынка очевиден: фишинговые кампании будут еще плотнее склеивать контент письма, платформенную развилку, легитимные инструменты удаленного доступа и внешние сервисы для эксфильтрации в одну конвейерную схему. Вопрос уже не в том, дойдут ли такие приемы до массового сегмента, а в том, насколько быстро компании перестроят защиту с уровня «поймать плохое письмо» на уровень «понять, что именно случилось после клика». Подробности исследования можно проверить в материале .