Специалисты по кибербезопасности CTM360 за два месяца обнаружили более 3 000 фишинговых URL, связанных с поддельным наймом. Кампания получила название RecruitTrap, одноимённый отчёт опубликован по адресу . Календарная дата исследования не указана. Мошенники выдавали себя за настоящих рекрутеров более чем 50 организаций из 14 отраслей. Чаще всего использовались бренды из сфер найма, технологий, предметов роскоши и туризма: на них пришлось около 58% компаний, чьи названия фигурировали в приманках. Большинство замеченных целей работали в маркетинге. Такой выбор вполне прагматичен: маркетинговый аккаунт может открыть доступ к рекламным кабинетам, корпоративным страницам в социальных сетях, клиентским данным, почте и другим рабочим сервисам.
Атака начиналась с неожиданного письма или приглашения на встречу якобы от рекрутера известной компании. В сообщении упоминались опыт и профессиональная специализация адресата, предлагалось назначить собеседование либо провести неформальную беседу. Имя, фотографию, должность рекрутера и сведения о работодателе брали из открытых источников. Человеку показывали один из двух сценариев: копию страницы планирования встречи в духе Calendly или отдельный портал вакансий, оформленный под конкретную компанию. Там требовалось выбрать дату и время, а затем сообщить базовые контактные данные.
Оба маршрута заканчивались кнопками «Продолжить с Google» и «Продолжить с Ф⃰». После нажатия появлялось фальшивое окно входа, созданное методом Browser-in-the-Browser, BitB, то есть «браузер внутри браузера». Оно содержало нарисованные адресную строку, домен, значок замка и форму авторизации. На деле это было не системное окно браузера, а элемент вредоносной страницы. На телефоне подделка могла разворачиваться во весь экран, где недостаток видимых элементов браузера заметно усложнял проверку адреса.
Исследовав одну из страниц в стиле Calendly, CTM360 выяснила, что перед ней не обычная форма для сбора паролей, а управляемая машина состояний. Интерфейс на Svelte/SvelteKit последовательно открывал CAPTCHA, ввод имени пользователя, пароль и запрос двухфакторной аутентификации. Комплект поддерживал OTP, одноразовый пароль, сопоставление номера телефона и проверку последних цифр. Идентификатор конкретной браузерной сессии сохранялся в sessionStorage, а постоянный канал связывал страницу с сервером операторов. Через него сервер выбирал следующий экран в зависимости от действий жертвы и ответа настоящего сервиса. CAPTCHA и проверка перезагрузки браузера попутно отсекали часть автоматических сканеров, исследователей и случайных посетителей.
Поддельная страница проверяла домен введённой почты и не пропускала пользователей обычных персональных сервисов. Продолжить могли владельцы корпоративных адресов. Значит, операторам были нужны именно рабочие учётные записи, связанные с внутренними системами и коммерческими сервисами. После получения логина и пароля злоумышленник сразу вводил их на настоящем сайте Google или Ф⃰. Если сервис запрашивал MFA/2FA, аналогичная проверка появлялась у жертвы. Введённый OTP, результат сопоставления или другое подтверждение пересылались через и тут же использовались в реальном сеансе входа.
Успешная проверка давала преступнику уже авторизованную сессию, а не один лишь пароль. После этого аккаунт можно было захватить, даже если вход защищён кодом MFA. Жертву тем временем перенаправляли на настоящий сайт Calendly, чтобы сбой выглядел случайным и не вызывал немедленных подозрений. В этом и состоит опасность ретрансляции: обычный одноразовый код защищает от отложенного использования украденного пароля, но не спасает, когда код перехватывают и передают настоящему сервису в ту же минуту.
Около 96% найденных CTM360 страниц копировали Calendly. Многие работали через Cloudflare, скрывавший адреса исходных серверов. Для порталов, оформленных под отдельные бренды, исследователи насчитали 116 уникальных хостов. Из них 93,1% относились к выделенным или зарегистрированным хостам, а 50,9% размещались на IP-адресах и в диапазонах Amazon Web Services EC2, AWS EC2. Всего выявлено 813 уникальных зарегистрированных доменов после удаления повторов. На зону .com пришлось 25,1%, на .info 15,1%, на .works 10,5%, на .work 6,3%. Повторяющиеся имена хостов и общая серверная база указывали на многократное развёртывание одного комплекта.
Шаблон быстро перекрашивался под очередного работодателя. Операторы меняли название компании, личность рекрутера, фон, слоган и провайдера входа, сохраняя 30-минутный формат встречи, порядок выбора времени, сценарий авторизации и механизм перехвата MFA. Поэтому десятки внешне разных сайтов могли работать на одной технической основе. Фальшивое окно выдавало себя при внимательной проверке: его нельзя вынести за пределы текущей вкладки, кнопки браузера часто не работают, а ссылки на конфиденциальность остаются декоративными. Нарисованные адрес и замок ничего не подтверждают. Настоящий вход Google должен проходить на либо другом проверенном домене, принадлежащем Google.
Дополнительную подсказку способен дать менеджер паролей. Если он не распознаёт ожидаемый домен и отказывается автоматически подставлять сохранённые данные, вводить пароль вручную не стоит. Незапрошенное приглашение лучше проверить через контакт, самостоятельно найденный на официальном сайте компании, а вакансию открыть непосредственно в разделе карьеры, не пользуясь ссылкой из письма. Организациям полезно отслеживать домены, похожие на их страницы найма, сопоставлять подозрительные письма рекрутеров с необычными попытками входа и проверять появление новых авторизованных сессий. Для защиты подходят passkeys и аппаратно поддерживаемая аутентификация WebAuthn: в отличие от паролей и пересылаемых кодов, она привязана к настоящему домену.
Если пароль или код MFA уже введён на подозрительной странице, одной смены пароля недостаточно. Следует немедленно завершить все активные сеансы, отозвать токены аутентификации, проверить недавние входы и правила обработки почты, затем просмотреть разрешения OAuth и список подключённых приложений. О происшествии нужно сообщить службе безопасности работодателя. Захваченная авторизованная сессия может продолжать работать после смены пароля, поэтому её отдельный отзыв обязателен.
Изображение носит иллюстративный характер
Атака начиналась с неожиданного письма или приглашения на встречу якобы от рекрутера известной компании. В сообщении упоминались опыт и профессиональная специализация адресата, предлагалось назначить собеседование либо провести неформальную беседу. Имя, фотографию, должность рекрутера и сведения о работодателе брали из открытых источников. Человеку показывали один из двух сценариев: копию страницы планирования встречи в духе Calendly или отдельный портал вакансий, оформленный под конкретную компанию. Там требовалось выбрать дату и время, а затем сообщить базовые контактные данные.
Оба маршрута заканчивались кнопками «Продолжить с Google» и «Продолжить с Ф⃰». После нажатия появлялось фальшивое окно входа, созданное методом Browser-in-the-Browser, BitB, то есть «браузер внутри браузера». Оно содержало нарисованные адресную строку, домен, значок замка и форму авторизации. На деле это было не системное окно браузера, а элемент вредоносной страницы. На телефоне подделка могла разворачиваться во весь экран, где недостаток видимых элементов браузера заметно усложнял проверку адреса.
Исследовав одну из страниц в стиле Calendly, CTM360 выяснила, что перед ней не обычная форма для сбора паролей, а управляемая машина состояний. Интерфейс на Svelte/SvelteKit последовательно открывал CAPTCHA, ввод имени пользователя, пароль и запрос двухфакторной аутентификации. Комплект поддерживал OTP, одноразовый пароль, сопоставление номера телефона и проверку последних цифр. Идентификатор конкретной браузерной сессии сохранялся в sessionStorage, а постоянный канал связывал страницу с сервером операторов. Через него сервер выбирал следующий экран в зависимости от действий жертвы и ответа настоящего сервиса. CAPTCHA и проверка перезагрузки браузера попутно отсекали часть автоматических сканеров, исследователей и случайных посетителей.
Поддельная страница проверяла домен введённой почты и не пропускала пользователей обычных персональных сервисов. Продолжить могли владельцы корпоративных адресов. Значит, операторам были нужны именно рабочие учётные записи, связанные с внутренними системами и коммерческими сервисами. После получения логина и пароля злоумышленник сразу вводил их на настоящем сайте Google или Ф⃰. Если сервис запрашивал MFA/2FA, аналогичная проверка появлялась у жертвы. Введённый OTP, результат сопоставления или другое подтверждение пересылались через и тут же использовались в реальном сеансе входа.
Успешная проверка давала преступнику уже авторизованную сессию, а не один лишь пароль. После этого аккаунт можно было захватить, даже если вход защищён кодом MFA. Жертву тем временем перенаправляли на настоящий сайт Calendly, чтобы сбой выглядел случайным и не вызывал немедленных подозрений. В этом и состоит опасность ретрансляции: обычный одноразовый код защищает от отложенного использования украденного пароля, но не спасает, когда код перехватывают и передают настоящему сервису в ту же минуту.
Около 96% найденных CTM360 страниц копировали Calendly. Многие работали через Cloudflare, скрывавший адреса исходных серверов. Для порталов, оформленных под отдельные бренды, исследователи насчитали 116 уникальных хостов. Из них 93,1% относились к выделенным или зарегистрированным хостам, а 50,9% размещались на IP-адресах и в диапазонах Amazon Web Services EC2, AWS EC2. Всего выявлено 813 уникальных зарегистрированных доменов после удаления повторов. На зону .com пришлось 25,1%, на .info 15,1%, на .works 10,5%, на .work 6,3%. Повторяющиеся имена хостов и общая серверная база указывали на многократное развёртывание одного комплекта.
Шаблон быстро перекрашивался под очередного работодателя. Операторы меняли название компании, личность рекрутера, фон, слоган и провайдера входа, сохраняя 30-минутный формат встречи, порядок выбора времени, сценарий авторизации и механизм перехвата MFA. Поэтому десятки внешне разных сайтов могли работать на одной технической основе. Фальшивое окно выдавало себя при внимательной проверке: его нельзя вынести за пределы текущей вкладки, кнопки браузера часто не работают, а ссылки на конфиденциальность остаются декоративными. Нарисованные адрес и замок ничего не подтверждают. Настоящий вход Google должен проходить на либо другом проверенном домене, принадлежащем Google.
Дополнительную подсказку способен дать менеджер паролей. Если он не распознаёт ожидаемый домен и отказывается автоматически подставлять сохранённые данные, вводить пароль вручную не стоит. Незапрошенное приглашение лучше проверить через контакт, самостоятельно найденный на официальном сайте компании, а вакансию открыть непосредственно в разделе карьеры, не пользуясь ссылкой из письма. Организациям полезно отслеживать домены, похожие на их страницы найма, сопоставлять подозрительные письма рекрутеров с необычными попытками входа и проверять появление новых авторизованных сессий. Для защиты подходят passkeys и аппаратно поддерживаемая аутентификация WebAuthn: в отличие от паролей и пересылаемых кодов, она привязана к настоящему домену.
Если пароль или код MFA уже введён на подозрительной странице, одной смены пароля недостаточно. Следует немедленно завершить все активные сеансы, отозвать токены аутентификации, проверить недавние входы и правила обработки почты, затем просмотреть разрешения OAuth и список подключённых приложений. О происшествии нужно сообщить службе безопасности работодателя. Захваченная авторизованная сессия может продолжать работать после смены пароля, поэтому её отдельный отзыв обязателен.
