Что, по данным GTIG, делает BlackFile#
Google Threat Intelligence Group сообщает, что отслеживает кампанию вымогательства, которую ведет UNC6671 — threat actor, работающий под брендом «BlackFile». Группа атакует организации через voice phishing, или vishing, а затем компрометирует учетные записи single sign-on.
Эта кампания не описывается как эксплуатация уязвимости вендора. GTIG прямо подчеркивает этот момент. Наблюдаемые компрометации происходят через social engineering, adversary-in-the-middle перехват учетных данных и злоупотребление легитимным доступом к identity- и SaaS-сервисам после того, как жертва проходит аутентификацию.
Это важно, потому что цепочка атаки построена вокруг обычного корпоративного доверия. Пользователь получает звонок. Звонивший представляется внутренней IT-службой или help desk. Предлог выглядит правдоподобно: миграция на passkey, enrollment MFA или обязательное обновление аутентификации. Жертву отправляют на похожую на настоящую страницу SSO. Учетные данные и ответы MFA перехватываются в реальном времени. Затем атакующий использует живую сессию, чтобы войти в cloud applications и украсть данные для вымогательства.
GTIG сообщает, что UNC6671 с момента появления в начале 2026 года атаковал десятки организаций в Северной Америке, Австралии и Великобритании. В одном случае группа также использовала бренд ShinyHunters, чтобы добавить угрозам убедительности. GTIG оценивает активность BlackFile и ShinyHunters как независимую, указывая на отдельные TOX-каналы связи, разные паттерны регистрации доменов и собственный data leak site BlackFile.
Точка входа — телефонный звонок, а не malware drop#
Первый шаг — массовый vishing. По данным GTIG, звонящих часто нанимает сам threat actor. Они связываются с целевыми сотрудниками по личным мобильным телефонам, что помогает увести разговор из контролируемых корпоративных каналов и стандартных процессов поддержки.
Сценарий прост, потому что ему не нужно быть экзотическим. Звонивший выдает себя за IT. Сотруднику говорят, что enrollment passkey или миграция MFA обязательны. Такой предлог дает жертве причину открыть новую страницу, ввести учетные данные, ответить на MFA prompts и воспринимать предупреждения как часть процесса настройки.
GTIG отмечает, что UNC6671 менял свою инфраструктуру для credential harvesting. В более ранней активности использовались домены, сильнее адаптированные под конкретные организации. В недавних кампаниях группа перешла к модели subdomain: домены часто регистрировались через Tucows, а subdomains ссылались на темы вроде passkeys, enrollment или настройки SSO. В отчете приведены такие паттерны:
<organization>.enrollms[.]com<organization>.passkeyms[.]com<organization>.setupsso[.]com
Смысл не в том, что именно эти домены навсегда останутся полезными indicators. Важна логика именования. Инфраструктура спроектирована так, чтобы выглядеть как поспешно сделанная, но правдоподобная страница миграции identity.
Как работает обход MFA#
Это workflow adversary-in-the-middle. Он не ломает криптографию MFA. Он использует жертву, чтобы завершить процедуру аутентификации за атакующего.
Жертва открывает фальшивый SSO portal. Она вводит username и password. Атакующий перехватывает эти значения и сразу отправляет их настоящему SSO provider. Когда реальный сервис запрашивает MFA, атакующий ретранслирует challenge обратно через social engineering flow. Жертва подтверждает push, вводит SMS code или предоставляет TOTP code, потому что считает, что завершает enrollment.
После входа, по данным GTIG, actor быстро переходит в security settings пользователя и регистрирует новое MFA device, контролируемое атакующим. Это создает persistence. Окно между первичным логином и устойчивым доступом может быть настолько коротким, что security operations center не успевает заметить аномалию до того, как аккаунт закреплен.
Именно поэтому стандартный MFA — не то же самое, что phishing-resistant MFA. Push prompts, SMS codes и TOTP все еще можно ретранслировать во время живого звонка. Phishing-resistant methods, например правильно развернутые passkeys или hardware-backed authentication, привязанные к легитимному origin, гораздо сложнее повторно использовать на контролируемом атакующим lookalike-сайте.
Что происходит после доступа к SSO#
После аутентификации кампания смещается от компрометации identity к краже данных из SaaS. GTIG сообщает, что actors фокусируются на средах Microsoft 365 и Okta, а затем используют скомпрометированные аккаунты для доступа к SharePoint, OneDrive и подключенным приложениям, таким как Zendesk и Salesforce.
В некоторых случаях actors искали во внутренних системах строки вроде «confidential» и «SSN». Это прямой метод triage. Они ищут данные, которые помогут подкрепить требование выкупа, а не пытаются понять всю компанию целиком.
GTIG также наблюдал переход от browser-based reconnaissance к programmatic exfiltration. В нескольких расследованиях scripts использовались для сбора данных из SharePoint и OneDrive. Среди упомянутых инструментов и методов были Microsoft Graph, Python requests, PowerShell и прямой HTTP GET request.
Практический вывод для защиты#
Главный вывод для defenders: такую атаку нельзя закрыть только обучением пользователей или обычным MFA. Нужно уменьшить вероятность успешного звонка, ограничить возможность закрепления после первого входа и быстрее видеть массовый доступ к SaaS-данным.
Приоритетные меры:
- Перевести критичные роли и группы риска на phishing-resistant MFA: passkeys, FIDO2/security keys или другие методы, проверяющие легитимный origin.
- Запретить или жестко контролировать самостоятельную регистрацию новых MFA devices после входа. Для смены MFA требовать step-up, trusted device, help desk verification или отдельный approval workflow.
- Настроить alerts на добавление MFA device, изменение authentication methods, вход с нового устройства сразу после звонка в help desk или необычной географии.
- Проверить Okta, Microsoft 365 и IdP logs на цепочки: успешный SSO login, быстрое изменение MFA, затем доступ к SharePoint, OneDrive, Zendesk или Salesforce.
- Ограничить доступ приложений и tokens по least privilege. Отдельно контролировать Microsoft Graph permissions и аномальные download patterns.
- Ввести понятный внутренний процесс: IT не просит по телефону вводить пароль, подтверждать push или переходить на неизвестный домен для enrollment. Любая миграция MFA должна подтверждаться через официальный портал и заранее объявленный канал.
- Мониторить домены и subdomains, похожие на корпоративный SSO, особенно с темами enroll, passkey, setup, sso, mfa и helpdesk.
Для GigaTap-подхода эта история особенно показательна: после компрометации identity злоумышленник выглядит как обычный пользователь SaaS. Поэтому полезно сопоставлять identity events с сетевыми и application-level сигналами: кто вошел, откуда, когда сменил MFA, какие SaaS endpoints начал опрашивать и не превратился ли нормальный доступ к OneDrive или SharePoint в массовую выгрузку данных.