Серия атак на финансовые компании, фонды прямых инвестиций и поставщиков профессиональных услуг связана с группой вымогателей UNC6671, которую CrowdStrike отслеживает под именем Cordial Spider. Кампанию изучали Google Threat Intelligence Group (GTIG), Mandiant, CrowdStrike, SOCRadar и Bridewell; подробности публиковало издание The Hacker News. По оценке Google, преступники не находили уязвимости в продуктах или инфраструктуре поставщиков. Они звонили сотрудникам, выдавали себя за корпоративную ИТ-поддержку и убеждали людей самостоятельно открыть доступ к рабочим системам.
Звонок часто поступал на личный мобильный телефон, хотя речь шла о корпоративной учётной записи. Номер настоящей службы поддержки могли подменить. Собеседнику сообщали об обязательной срочной миграции средств защиты, проблеме с аккаунтом, обновлении безопасности либо внутренней заявке, которую якобы нужно немедленно проверить. Такой канал удобен для злоумышленника: личный телефон обычно находится вне корпоративных средств наблюдения, а неожиданный разговор оставляет сотруднику мало времени на проверку легенды.
Жертву направляли на поддельный портал входа, работающий через инфраструктуру adversary-in-the-middle, или AitM: фальшивая страница в реальном времени передавала запрос настоящему сервису и перехватывала логин, пароль, код многофакторной аутентификации (MFA) и активный сеансовый токен. Поэтому обычный одноразовый код не всегда спасал. Получив действующую сессию, оператор входил в поставщик удостоверений IdP и превращал его в «единую точку входа» к приложениям SaaS. Доверие между IdP, единым входом SSO и подключёнными сервисами позволяло не взламывать каждую систему отдельно.
После проникновения UNC6671 удаляла законные устройства MFA, регистрировала собственные и повторно использовала украденные сессии. Даже завершив разговор и сменив пароль, сотрудник мог не закрыть уже выданный токен. Для массовой выгрузки сведений применялись сценарии Python и PowerShell. Данные забирали из корпоративных облаков, Microsoft 365, Okta и прочих сервисов SaaS. CrowdStrike описывала эту схему как быструю операцию по краже и вымогательству: один удачный звонок давал доступ к целой связке облачных приложений.
Google связывала UNC6671 с публичными марками Redact, Pink, она же CL-CRI-1147, Helix и Falcon, она же CL-CRI-1182. Ранее использовалось имя BlackFile, или CL-CRI-1116: под ним жертв атаковали через вишинг и компрометацию SSO, но 11 мая 2026 года бренд закрыли. После публикации Falcon отверг связь с UNC6671 и назвал себя «эксклюзивным партнёром Redact». Группа заявила, что не делит ни операторов, ни инфраструктуру, инструменты, каналы переговоров или доходы ни с кем, кроме Redact. Представитель Google сообщил The Hacker News, что компания знает об этих заявлениях, но дополнительных комментариев пока не даст.
Сходные приёмы и серверы ещё не означают единого командования. Google рассматривала несколько вариантов: UNC6671 могла распасться на самостоятельные команды, работать через партнёров, отколовшиеся группы или широкую криминальную сеть с общей фишинговой инфраструктурой. Основные операторы могли получать первоначальный доступ, захватывать облако и выгружать SaaS-данные, а переговорщики отдельно общались с жертвой и торговались о выкупе. Несколько вывесок помогают разделять переговоры, запутывать атрибуцию и ограждать техническую команду от лишнего внимания. Получается что-то вроде децентрализованной фирмы, где инфраструктура общая, а публичные лица меняются.
UNC6671 поддерживала высокий темп и атаковала десятки организаций в Северной Америке, Австралии и Великобритании. В апреле и мае 2026 года среди целей были крупные предприятия промышленности, недвижимости, здравоохранения и страхования. В июне интерес сместился к технологиям, транспорту и гостиничному бизнесу. В июле операторы занялись дорогими целями в финансовом и юридическом секторах; в более широкой кампании также фигурировали фонды прямых инвестиций и компании профессиональных услуг.
В июньском анализе 2026 года SOCRadar описала Pink как группу, занимающуюся Big Game Hunting, то есть охотой на крупные и платёжеспособные организации. Она использовала фишинговые комплекты, настроенные под Okta и Microsoft Entra ID. Входные шлюзы отсекали песочницы и исследователей кибербезопасности, а сайты размещались через Cloudflare и DDoS-Guard. Домены регистрировали у Tucows и Nicenic. Связка телефонной легенды с закрытой фишинговой площадкой была рассчитана на обход MFA и аутентификации с помощью ключей доступа, или Passkeys.
Панели для сбора учётных данных размещались на нейтрально выглядящих корневых доменах, связанных по смыслу с ключами доступа, MFA либо SSO. Среди примеров: passkeyhelpdesk[.]com, setupsso[.]com и idokta[.]com. К основе добавляли поддомен с названием конкретной жертвы. Иногда один домен одновременно обслуживал атаки на две не связанные между собой организации: ответственность за одну приписывала себе Falcon, за другую — Helix. Уже захваченные почтовые ящики использовали для сброса паролей в приложениях без SSO. Затем преступники удаляли письма о смене пароля и предупреждения безопасности, чтобы владелец аккаунта подольше ничего не замечал.
С 7 января по 12 мая 2026 года Google отследила более 10,6 миллиона долларов в биткоинах, поступивших на связанные с группой кошельки. Первоначальное требование могло превышать 3 миллиона долларов, но переговоры были вполне торгашескими: операторы соглашались снизить сумму на 50%, иногда на 75%. Более чем в 53% изученных случаев стороны сходились в среднем примерно на 750 тысячах долларов. Разница между стартовой и окончательной суммой показывает, что многомиллионная цифра служила точкой торга, а не жёсткой ценой.
За предшествующий год похожие вишинговые кампании пересекались по технике с активностью в стиле ShinyHunters. Их участники проникали в Salesforce, закреплялись в системе, выгружали данные и злоупотребляли доверенными связями OAuth. Доступ по цепочке поставок получали через привычные рабочие процессы и интеграции Salesloft, Gainsight и Klue. Это опасный участок: разрешённое OAuth-приложение может сохранить доступ без повторного ввода пароля. Некоторые признаки также совпадали с почерком Scattered LAPSUS$ Hunters (SLH), но общая инфраструктура фишинговых комплектов не даёт достаточных оснований считать всех операторов одной группой.
Bridewell зафиксировала неудачный звонок, подробности которого сообщил исследователь безопасности Joshua Penny. Сотруднику позвонили на личное устройство и предложили открыть предполагаемую поддельную страницу Okta ради внутренней заявки об инциденте. Он попросил перевести обращение в официальный Service Desk, однако звонивший отказался: якобы вызов специально направили именно этому человеку. Тогда собеседник предложил «альтернативный способ» просмотра заявки. Средства защиты заблокировали адрес до ввода учётных данных. Сотрудник сказал, что сначала соберёт дополнительную информацию, после чего злоумышленник отключился и больше не звонил. Bridewell допускала участие ShinyHunters либо другого оператора с инфраструктурой, похожей на инструменты SLH, но подтверждённой атрибуции нет.
Защита от такой схемы начинается с устойчивой к фишингу MFA, которую нельзя ретранслировать через AitM, и короткоживущих управляемых сессий. SaaS и облака стоит подключать к SSO ради единого контроля, одновременно жёстко защищая IdP: разрешать чувствительный доступ только с корпоративных устройств и доверенных сетей, проверять необычные входы, удаление законных факторов MFA и регистрацию новых. Полезны средства, замечающие ввод корпоративного пароля или его контрольного хеша на постороннем домене. Любой неожиданный звонок на личный номер по поводу срочной ИТ-задачи нужно перепроверять через официальный Service Desk. Именно такой простой шаг сорвал атаку, описанную Bridewell.[/final]
Изображение носит иллюстративный характер
Звонок часто поступал на личный мобильный телефон, хотя речь шла о корпоративной учётной записи. Номер настоящей службы поддержки могли подменить. Собеседнику сообщали об обязательной срочной миграции средств защиты, проблеме с аккаунтом, обновлении безопасности либо внутренней заявке, которую якобы нужно немедленно проверить. Такой канал удобен для злоумышленника: личный телефон обычно находится вне корпоративных средств наблюдения, а неожиданный разговор оставляет сотруднику мало времени на проверку легенды.
Жертву направляли на поддельный портал входа, работающий через инфраструктуру adversary-in-the-middle, или AitM: фальшивая страница в реальном времени передавала запрос настоящему сервису и перехватывала логин, пароль, код многофакторной аутентификации (MFA) и активный сеансовый токен. Поэтому обычный одноразовый код не всегда спасал. Получив действующую сессию, оператор входил в поставщик удостоверений IdP и превращал его в «единую точку входа» к приложениям SaaS. Доверие между IdP, единым входом SSO и подключёнными сервисами позволяло не взламывать каждую систему отдельно.
После проникновения UNC6671 удаляла законные устройства MFA, регистрировала собственные и повторно использовала украденные сессии. Даже завершив разговор и сменив пароль, сотрудник мог не закрыть уже выданный токен. Для массовой выгрузки сведений применялись сценарии Python и PowerShell. Данные забирали из корпоративных облаков, Microsoft 365, Okta и прочих сервисов SaaS. CrowdStrike описывала эту схему как быструю операцию по краже и вымогательству: один удачный звонок давал доступ к целой связке облачных приложений.
Google связывала UNC6671 с публичными марками Redact, Pink, она же CL-CRI-1147, Helix и Falcon, она же CL-CRI-1182. Ранее использовалось имя BlackFile, или CL-CRI-1116: под ним жертв атаковали через вишинг и компрометацию SSO, но 11 мая 2026 года бренд закрыли. После публикации Falcon отверг связь с UNC6671 и назвал себя «эксклюзивным партнёром Redact». Группа заявила, что не делит ни операторов, ни инфраструктуру, инструменты, каналы переговоров или доходы ни с кем, кроме Redact. Представитель Google сообщил The Hacker News, что компания знает об этих заявлениях, но дополнительных комментариев пока не даст.
Сходные приёмы и серверы ещё не означают единого командования. Google рассматривала несколько вариантов: UNC6671 могла распасться на самостоятельные команды, работать через партнёров, отколовшиеся группы или широкую криминальную сеть с общей фишинговой инфраструктурой. Основные операторы могли получать первоначальный доступ, захватывать облако и выгружать SaaS-данные, а переговорщики отдельно общались с жертвой и торговались о выкупе. Несколько вывесок помогают разделять переговоры, запутывать атрибуцию и ограждать техническую команду от лишнего внимания. Получается что-то вроде децентрализованной фирмы, где инфраструктура общая, а публичные лица меняются.
UNC6671 поддерживала высокий темп и атаковала десятки организаций в Северной Америке, Австралии и Великобритании. В апреле и мае 2026 года среди целей были крупные предприятия промышленности, недвижимости, здравоохранения и страхования. В июне интерес сместился к технологиям, транспорту и гостиничному бизнесу. В июле операторы занялись дорогими целями в финансовом и юридическом секторах; в более широкой кампании также фигурировали фонды прямых инвестиций и компании профессиональных услуг.
В июньском анализе 2026 года SOCRadar описала Pink как группу, занимающуюся Big Game Hunting, то есть охотой на крупные и платёжеспособные организации. Она использовала фишинговые комплекты, настроенные под Okta и Microsoft Entra ID. Входные шлюзы отсекали песочницы и исследователей кибербезопасности, а сайты размещались через Cloudflare и DDoS-Guard. Домены регистрировали у Tucows и Nicenic. Связка телефонной легенды с закрытой фишинговой площадкой была рассчитана на обход MFA и аутентификации с помощью ключей доступа, или Passkeys.
Панели для сбора учётных данных размещались на нейтрально выглядящих корневых доменах, связанных по смыслу с ключами доступа, MFA либо SSO. Среди примеров: passkeyhelpdesk[.]com, setupsso[.]com и idokta[.]com. К основе добавляли поддомен с названием конкретной жертвы. Иногда один домен одновременно обслуживал атаки на две не связанные между собой организации: ответственность за одну приписывала себе Falcon, за другую — Helix. Уже захваченные почтовые ящики использовали для сброса паролей в приложениях без SSO. Затем преступники удаляли письма о смене пароля и предупреждения безопасности, чтобы владелец аккаунта подольше ничего не замечал.
С 7 января по 12 мая 2026 года Google отследила более 10,6 миллиона долларов в биткоинах, поступивших на связанные с группой кошельки. Первоначальное требование могло превышать 3 миллиона долларов, но переговоры были вполне торгашескими: операторы соглашались снизить сумму на 50%, иногда на 75%. Более чем в 53% изученных случаев стороны сходились в среднем примерно на 750 тысячах долларов. Разница между стартовой и окончательной суммой показывает, что многомиллионная цифра служила точкой торга, а не жёсткой ценой.
За предшествующий год похожие вишинговые кампании пересекались по технике с активностью в стиле ShinyHunters. Их участники проникали в Salesforce, закреплялись в системе, выгружали данные и злоупотребляли доверенными связями OAuth. Доступ по цепочке поставок получали через привычные рабочие процессы и интеграции Salesloft, Gainsight и Klue. Это опасный участок: разрешённое OAuth-приложение может сохранить доступ без повторного ввода пароля. Некоторые признаки также совпадали с почерком Scattered LAPSUS$ Hunters (SLH), но общая инфраструктура фишинговых комплектов не даёт достаточных оснований считать всех операторов одной группой.
Bridewell зафиксировала неудачный звонок, подробности которого сообщил исследователь безопасности Joshua Penny. Сотруднику позвонили на личное устройство и предложили открыть предполагаемую поддельную страницу Okta ради внутренней заявки об инциденте. Он попросил перевести обращение в официальный Service Desk, однако звонивший отказался: якобы вызов специально направили именно этому человеку. Тогда собеседник предложил «альтернативный способ» просмотра заявки. Средства защиты заблокировали адрес до ввода учётных данных. Сотрудник сказал, что сначала соберёт дополнительную информацию, после чего злоумышленник отключился и больше не звонил. Bridewell допускала участие ShinyHunters либо другого оператора с инфраструктурой, похожей на инструменты SLH, но подтверждённой атрибуции нет.
Защита от такой схемы начинается с устойчивой к фишингу MFA, которую нельзя ретранслировать через AitM, и короткоживущих управляемых сессий. SaaS и облака стоит подключать к SSO ради единого контроля, одновременно жёстко защищая IdP: разрешать чувствительный доступ только с корпоративных устройств и доверенных сетей, проверять необычные входы, удаление законных факторов MFA и регистрацию новых. Полезны средства, замечающие ввод корпоративного пароля или его контрольного хеша на постороннем домене. Любой неожиданный звонок на личный номер по поводу срочной ИТ-задачи нужно перепроверять через официальный Service Desk. Именно такой простой шаг сорвал атаку, описанную Bridewell.[/final]
