Кратко
- Подтверждено:Twilio пришла к выводу, что злоумышленники разослали сотни SMS-фишинговых сообщений действующим и бывшим сотрудникам, собрали учётные данные на поддельных страницах входа и использовали скомпрометированные учётные записи сотрудников для входа во внутренние административные инструменты и приложения. Последняя замеченная несанкционированная активность датирована 9 августа 2022 года. В итоге Twilio насчитала 209 затронутых клиентских аккаунтов и 93 затронутые учётные записи конечных пользователей Authy.
- Влияние ниже по цепочке:цифра 209 — не общее число конечных пользователей. Signal, один из затронутых клиентов, выявил около 1900 телефонных номеров, по которым злоумышленник мог узнать статус регистрации или увидеть SMS-код регистрации; один из трёх явно проверенных аккаунтов, по сообщениям, был перерегистрирован. Положение Twilio в цепочке услуг умножило последствия небольшого числа скомпрометированных сотрудников.
- Вывод о средствах контроля:злоумышленникам не пришлось взламывать шифрование или красть API-ключ клиента Twilio. Они убедили сотрудников пройти аутентификацию на сайте-имитации, а затем использовали полученные полномочия. Обучение и быстрое удаление фишинговых страниц важны, но решающий контроль — аутентификация, которая не выдаёт пригодный к повторному использованию ответ для чужого сайта, в сочетании с узкими административными привилегиями и короткими сессиями.
- Ответственность:за обман и несанкционированный доступ отвечают злоумышленники. Twilio контролировала аутентификацию сотрудников, внутренние инструменты, объём доступа к данным клиентов, срок жизни сессий, обнаружение инцидента и уведомление клиентов. Клиенты контролировали, насколько их нижестоящая идентификация зависела от Twilio и какие независимые меры защиты они выстраивали вокруг регистрации. Операторы связи, регистраторы, хостинг-провайдеры и поставщики решений для идентификации контролировали части возобновляемой инфраструктуры кампании. Ответственность распределена по всей цепочке, но она не равная и не взаимозаменяемая.
Небольшое число клиентов может скрывать масштабную зависимость
В итоговом отчёте Twilio об инциденте приводятся два соотношения, которые легко повторить и легко неверно истолковать: 209 клиентов из более чем 270 000 и 93 пользователя Authy из примерно 75 миллионов. Обе дроби малы. Ни одна из них не описывает всю совокупность людей, чьи данные или аккаунты могли оказаться под угрозой из-за затронутого клиента Twilio. Клиент Twilio — это часто организация, предоставляющая услуги собственным пользователям. Одна скомпрометированная клиентская связь может поэтому содержать тысячи, миллионы или избирательно ценные единицы нижестоящих идентичностей.
Signal сделал этот множитель видимым. Он использовал Twilio для проверки телефонных номеров и установил, что примерно у 1900 пользователей номер мог быть раскрыт как зарегистрированный в Signal или мог быть раскрыт SMS-код регистрации. Злоумышленник явно искал три номера, и Signal получил сообщение о том, что один из этих аккаунтов был перерегистрирован. Signal подчеркнул, что история переписки, списки контактов, данные профиля, чёрные списки и PIN-код Signal через Twilio доступны не были. Это важное ограничение, а не повод отмахнуться от события.
В окно доступа успешная перерегистрация могла позволить злоумышленнику отправлять и получать новые сообщения Signal от имени затронутого номера. Signal отменил регистрацию всех 1900 потенциально затронутых аккаунтов, потребовал повторной регистрации и уведомил пользователей по SMS 15 и 16 августа. (Уведомление Signal об инциденте)
Сравнение 209 клиентов Twilio и 1900 потенциально затронутых пользователей Signal показывает, почему для инцидентов в сфере программного обеспечения как услуги нужны несколько знаменателей. Провайдер должен подсчитывать затронутые клиентские аккаунты. Каждый клиент должен подсчитывать затронутых конечных пользователей, записи, идентификаторы и транзакции. Расследователи должны различать просмотренные и изменённые данные, раскрытый код регистрации и перерегистрированный аккаунт, возможное действие и наблюдаемое. Сжатие этих состояний в одну сумму лишает информации, необходимой для устранения последствий.
Twilio также заявила, что нет доказательств того, что злоумышленники получили доступ к учётным данным консоли клиента, токенам аутентификации или API-ключам. Эта граница существенно сужает множество подтверждаемых утверждений. Это значит, что открытые доказательства не устанавливают, что злоумышленники могли совершать произвольные API-вызовы Twilio от имени каждого затронутого клиента. Это не означает, что полученные административные данные безвредны, и не стирает того, что Signal независимо обнаружил в системе поддержки. Внутренний инструмент может раскрывать операционно решающую информацию, даже если собственный секрет клиента не тронут.
Это определяющая облачная зависимость в данном деле. Клиент делегировал функцию связи или проверки. Сотрудникам Twilio была нужна некоторая возможность поддерживать эту функцию. Атака превратила полномочия сотрудника в путь к информации клиента, а в случае Signal эта информация находилась внутри процесса регистрации аккаунта. Граница идентификации рабочей силы провайдера стала частью границы аутентификации клиента, независимо от того, видел ли клиент эту зависимость на архитектурной диаграмме.
Два инцидента социальной инженерии, затем расширившееся расследование
Финальная хронология сложнее первоначального августовского раскрытия. Расследование Twilio связало широко освещавшуюся SMS-кампанию с более ранним событием. 29 июня 2022 года сотрудника обманули по телефону и выманили учётные данные. Злоумышленник получил контактную информацию клиентов для ограниченного числа клиентов. Twilio заявила, что обнаружила и устранила этот доступ в течение 12 часов и уведомила затронутых клиентов 2 июля. Позже компания пришла к выводу, что, вероятно, за обоими событиями стояли одни и те же злоумышленники, но «вероятно» остаётся следственной оценкой, а не судебным приговором.
В середине июля злоумышленники начали рассылать сотни текстовых сообщений действующим и бывшим сотрудникам Twilio. Сообщения выдавали себя за ИТ-отдел или администратора и использовали обычные рабочие тревоги: истёкший пароль, изменённое расписание или другая причина войти в систему. Ссылки вели на домены, содержащие знакомые слова, такие как Twilio, Okta или SSO, и на страницы, имитировавшие настоящий вход Twilio. Некоторые сотрудники ввели учётные данные. Затем злоумышленники вошли во внутренние административные инструменты и приложения и добрались до информации клиентов.
Twilio узнала о несанкционированном доступе 4 августа. Первое уведомление она опубликовала 7 августа, первоначально описав ограниченное число клиентских аккаунтов. Публичная цифра менялась по ходу расследования: раннее обновление называло около 125 клиентов; к 24 августа Twilio сообщила о 163 клиентах и 93 пользователях Authy; в заключении от 27 октября приводилась итоговая цифра 209 клиентов и сохранялась цифра 93 пользователя Authy. Последняя замеченная несанкционированная активность датирована 9 августа. Сводныйотчёт об инциденте и заключение расследования Twilio— основной источник для этой последовательности.
Меняющиеся цифры сами по себе не доказывают, что раннее заявление было обманным. Масштаб инцидента обычно расширяется по мере того, как следователи восстанавливают идентичности, сессии, инструменты, запросы и записи клиентов. Вопрос подотчётности в том, определена ли каждая цифра и датирована ли. «Клиенты, выявленные на сегодняшний день» — не то же самое, что «итоговые затронутые клиенты». Затронутый организационный аккаунт отличается от физического лица. Пользователи Authy — снова другое.
Обновления Twilio в целом отмечали этот процесс, но итоговый публичный отчёт всё равно не публиковал категории данных, действия с доступом или нижестоящую совокупность для каждого затронутого клиента.
Отчётность компании по ценным бумагам добавила несколько полезных границ. Twilio заявила, что злоумышленники получили имена сотрудников и номера мобильных телефонов из неизвестных источников; что она уведомила затронутых клиентов и работала с ними; что уведомила соответствующих регуляторов и ответила на их вопросы; и что отраслевые отчёты помещали эту активность в организации из сфер технологий, телекоммуникаций и криптовалют. Еёформа 10-Q за третий квартал 2022 годаи более поздняяформа 10-K за 2022 годтакже повторяют цифру 209 клиентов и резюмируют меры по устранению последствий.
Эти документы — заявления компании, сделанные под обязательствами законодательства о ценных бумагах. Это более веские доказательства того, что Twilio официально раскрыла, чем анонимные сообщения, но это не независимый судебно-медицинский аудит и не вывод регулятора о соответствии. Публичный архив, изученный для этой статьи, не содержит постановления о правоприменении, которое распределяло бы юридическую ответственность за инцидент. Поэтому он поддерживает операционные суждения о контроле и доказательствах, а не утверждение о том, что суд или регулятор вынес окончательный вердикт о небрежности.
Сотрудник был целью, а не исчерпывающей первопричиной
Верно, что некоторые сотрудники ввели учётные данные на поддельной странице. Остановиться на этом — значит дать слабое объяснение. Социальная инженерия рассчитана на то, чтобы эксплуатировать тот факт, что легитимная работа уже требует от людей читать сообщения, переходить по ссылкам, реагировать на изменения расписания и проходить аутентификацию. Злоумышленники выбрали канал, который сотрудники носят с собой, язык, связанный с их работодателем, и страницу, имитировавшую знакомого поставщика идентификации. У них также было достаточно данных, чтобы связать имена сотрудников с номерами телефонов, включая номера бывших работников.
Действие сотрудника стало взломом только потому, что система аутентификации приняла то, что захватил злоумышленник, и потому что полученная сессия могла достичь чувствительных внутренних инструментов. Полная цепочка: сбор целей, доставка сообщения, доверие к ссылке, ввод учётных данных, захват или удовлетворение второго фактора, принятие поставщиком идентификации, создание сессии приложения, административная авторизация, доступ к данным клиентов и запоздалое аннулирование. Каждый переход после клика был машинным или политическим решением под контролем организации.
Это различие важно и для справедливости, и для инженерии. Обвинение сотрудника побуждает замалчивать инциденты в момент, когда сообщения наиболее ценны. Оно также направляет деньги на кампании по повышению осведомлённости, оставляя на месте повторно используемый протокол аутентификации. Twilio добавила дополнительное обязательное обучение, но более значимым ответом стала раздача FIDO2-ключей безопасности всем сотрудникам и усиление мер двухфакторной аутентификации. FIDO-аутентификатор привязывает свой ответ к реальному сайту или проверяющей стороне.
Убедительный домен-имитация всё ещё может собрать пароль, но не может получить криптографический ответ, необходимый легитимному сервису.
Руководство CISA поустойчивой к фишингу MFAназывает FIDO/WebAuthn широко доступным вариантом, устойчивым к фишингу, и отличает его от методов, которые просят человека передать код. Текущееруководство NIST по аутентификацииобъясняет механизм точнее: вводимые вручную одноразовые коды не устойчивы к фишингу, потому что их может передать мошенник, тогда как криптографическая аутентификация может привязать вывод аутентификатора к проверяющей стороне или каналу. Эти более поздние стандарты не доказывают, какую именно конфигурацию факторов Twilio использовала для каждого приложения в июле 2022 года.
Они объясняют, почему раздача токенов FIDO2 после инцидента устраняла задокументированный путь атаки прямее, чем очередное предупреждение о подозрительных ссылках.
Оставшийся тест — правоприменение. Владение ключами не то же самое, что требование их использовать. Путь восстановления, легаси-VPN, административное исключение, неуправляемое приложение, сброс через службу поддержки или запасной фактор могут сохранить старый путь атаки. Заслуживающий доверия отчёт об исправлении показал бы процент рабочих и привилегированных приложений, для которых устойчивая к фишингу аутентификация обязательна, порядок работы с подрядчиками и аварийными аккаунтами, количество и срок исключений и результаты учений против запасных и восстановительных процессов.
Cloudflare даёт полезное сравнение контроля, а не моральную притчу
Примерно в то же время сотрудники Cloudflare получили кампанию с похожими характеристиками. 20 июля 2022 года как минимум 76 сотрудников менее чем за минуту получили текстовые сообщения на личные и рабочие телефоны; некоторые сообщения дошли до членов семей. Трое сотрудников ввели свои учётные данные. Cloudflare сообщила, что злоумышленнику затем не удалось пройти обязательный шаг с аппаратным ключом FIDO2, поэтому её системы не были скомпрометированы.
Её круглосуточная команда по инцидентам сравнила получателей с активностью входа, сбросила затронутые учётные данные и сессии, просканировала устройства, заблокировала инфраструктуру и поделилась разведданными с другими целями.
(Технический отчёт Cloudflare)
Сравнение полезно, потому что оно удерживает человеческий фактор примерно постоянным. Сотрудники обеих компаний столкнулись с убедительной SMS-приманкой; сотрудники обеих взаимодействовали с ней. Исходы разошлись на уровне протокола и правоприменения. Ключи Cloudflare не сделали её сотрудников менее людьми. Они сделали человеческую ошибку недостаточной для удовлетворения настоящего проверяющего.
Было бы упрощением заключить, что Twilio должна была скопировать каждый элемент архитектуры Cloudflare или что один контроль гарантирует безопасность. Отчёт Cloudflare самооценочный, кампании были похожими, а не доказанно идентичными во всех деталях, и решительный злоумышленник может пойти по пути контроля конечных точек, восстановления аккаунта, кражи сессии или по другому пути. Урок уже и точнее: провайдер, имеющий административный доступ к данным клиентов, не должен делать успех реалистичного фишингового упражнения зависимым в первую очередь от того, распознает ли каждый сотрудник приманку.
Cloudflare также демонстрирует ценность централизованной видимости. Она смогла определить попытки аутентификации, в которых использовались верные украденные пароли, но не был пройден шаг с аппаратным ключом, связать их с сообщениями сотрудников, завершить сессии и запросить журналы доступа. Эти доказательства превратили разрозненные текстовые сообщения в кампанию.
Для Twilio эквивалентный вопрос подотчётности — не просто, генерировал ли поставщик идентификации журналы, а могла ли компания быстро ответить, какие учётные записи сотрудников проходили аутентификацию, какие факторы использовались, какие приложения выдавали сессии, каких записей клиентов касались эти сессии и была ли аннулирована каждая связанная сессия.
0ktapus превратил простую инфраструктуру в масштабируемую кампанию
В итоговом отчёте Twilio цитируются независимые исследователи, назвавшие более широкую активность 0ktapus или Scatter Swine. Исследование кампании Group-IB выявило 169 фишинговых доменов, 9 931 скомпрометированную запись с учётными данными, 5 441 скомпрометированный MFA-код и жертв, связанных со 136 уникальными почтовыми доменами. Её исследователи описали статичный фишинговый набор, который имитировал специфичные для организаций страницы Okta, собирал имена пользователей, пароли и коды и отправлял захваченный материал в Telegram-канал. Злоумышленникам приходилось быстро использовать короткоживущие коды, но им не нужны были редкие вредоносные программы или нераскрытый криптографический прорыв. (Анализ 0ktapus от Group-IB)
Цифры уровня кампании не следует переносить в счёт жертв Twilio. Корпус Group-IB охватывал многие организации и период, начинавшийся за месяцы до августовского обнаружения Twilio. Это доказательство экономики злоумышленников и общих методов, а не подтверждение того, что каждые учётные данные в наборе были использованы или что каждая перечисленная организация понесла те же последствия.
Экономическая асимметрия всё равно очевидна. Злоумышленники могли зарегистрировать домен, клонировать страницу входа, арендовать хостинг, разослать пачку сообщений и заменить инфраструктуру после удаления. Twilio заявила, что работала с операторами связи США, чтобы остановить вредоносные сообщения, и с хостинг-провайдерами, чтобы закрыть аккаунты, но злоумышленники меняли операторов и хостов и возобновляли атаки. Каждое защитное действие требовало, чтобы сообщение дошло до нужного провайдера, было достаточно доказательств для его процедуры, было принято решение и выполнена реализация.
Злоумышленнику нужны были лишь ещё один дешёвый аккаунт или домен.
Это экономика контактов для сообщений о злоупотреблениях: цена и задержка, связанные с превращением внешнего предупреждения в защитное действие. Цена — не просто отправка формы. Она включает обнаружение ответственного провайдера, оформление доказательств, преодоление фильтров ложных срабатываний, сохранение приватности, корреляцию дублирующихся сообщений, решение о юридических полномочиях, уведомление клиентов и отслеживание того, не вернулся ли вредоносный ресурс в другом месте. Злоумышленники могут автоматизировать поставку инфраструктуры для злоупотреблений; защитники часто обрабатывают сообщения как изолированные заявки.
Описание Twilio сообщений действующим и бывшим сотрудникам поднимает дополнительную проблему с сообщениями. Действующих работников можно научить использовать внутреннюю кнопку, чат-канал или горячую линию. У бывших работников может не быть аутентифицированного внутреннего маршрута. Члены семьи, получившие сообщение, могут не знать, какой работодатель имитируется или как безопасно передать доказательства. Зрелая программа нуждается в публичном, низкопороговом канале для подозрительных сообщений, связанных с компанией, а не только в службе поддержки для сотрудников.
Twilio сейчас публикует отдельные маршруты длясообщений об уязвимостях безопасностиижалоб на злоупотребления в переписке. Первый принимает сообщения от исследователей, партнёров, поставщиков, клиентов и консультантов; второй собирает сведения о нежелательных звонках или сообщениях. Это полезные публичные поверхности, но их существование сегодня не устанавливает, как сообщение о смишинге сотрудника в июле 2022 года направлялось или как быстро оно дошло до команды реагирования. Уязвимости, злоупотребления продуктом, компрометация клиентского аккаунта, фишинг сотрудников и активная разведка об инцидентах пересекаются, но это не идентичные очереди. Система должна уметь их объединять.
RFC 9116 стандартизировалsecurity.txtотчасти потому, что поиск контакта по безопасности сам по себе является источником задержки. Он даёт сайту предсказуемое, машиночитаемое место для публикации каналов сообщений и политики раскрытия. (RFC 9116) Файл контактов не может расследовать сообщение, а веб-форма не может заставить оператора или регистратора действовать. Их ценность в том, чтобы снизить фиксированную стоимость начала координации. Более сильная мера — то, что происходит после приёма: время подтверждения, назначение аналитика, корреляция перекрёстных сообщений, порог эскалации, время удаления, отслеживание повторений и обратная связь с заявителем.
Консоль поддержки была частью системы аутентификации Signal
В уведомлении Signal указывается консоль поддержки клиентов Twilio как система, до которой добрались через фишинг. Эта деталь важна, потому что инструменты поддержки часто считаются операционным удобством, а не границей производственной безопасности. Представителю поддержки может понадобиться проверить статус доставки, номера телефонов, события проверки или конфигурацию аккаунта, чтобы решить легитимную проблему. Та же видимость может помочь злоумышленнику определить зарегистрированный аккаунт или перехватить мимолётный код.
Поэтому фразу «непроизводственные системы» в итоговом отчёте Twilio следует толковать осторожно. Инструменту не нужно передавать живой трафик или размещать приложение клиента, чтобы влиять на производственное решение об идентификации. Если он отображает данные, порождённые производственными коммуникациями, позволяет искать по записям клиентов или помогает оператору изменить состояние, он находится внутри эффективной границы доверия сервиса. Ярлыки вроде «поддержка», «бэк-офис» или «непроизводственная система» не снижают чувствительность доступных там полномочий.
Правильный вопрос дизайна — не должен ли персонал поддержки иметь нулевой доступ. Платформа коммуникаций не может расследовать проблемы доставки и аккаунтов без доказательств. Вопрос в том, сколько данных видно по умолчанию, какие поля требуют повышения привилегий, нужны ли для особо чувствительных поисков причина или одобрение, как доступ ограничивается арендатором, как ограничены массовые запросы и может ли клиент видеть, что сотрудник провайдера обращался к его аккаунту.
Текущая документация TwilioMonitor Eventsописывает записи событий об изменениях, сделанных через API, пользователями консоли и даже сотрудниками Twilio. События могут включать тип субъекта действия, источник, IP-адрес источника, ресурс и данные события; срок хранения зависит от пакета аккаунта. Это доказательство того, что клиенты могут получать значимые записи активности платформы сейчас, а не подтверждение того, что просмотры консоли поддержки 2022 года, относящиеся к Signal, были видны клиенту или сохранялись в рамках этого продукта. Инцидент подчёркивает, почему объём аудита должен включать чтение и поиск, а не только изменения конфигурации.
Клиент, интегрирующий провайдера в восстановление аккаунта или проверку, должен запросить точную модель доступа поддержки. Может ли сотрудник провайдера увидеть живой одноразовый код? Может ли он раскрыть, зарегистрирован ли номер? Маскируется ли этот доступ до явного повышения? Истекает ли повышение? Требуется ли второе лицо для целевого поиска по аккаунту с высоким риском? Получит ли клиент событие почти в реальном времени? Может ли провайдер хранить эти записи достаточно долго, чтобы клиент успел выполнить собственный срок уведомления?
Эти вопросы напрямую следуют из влияния на Signal, без допущения, что каждый продукт Twilio раскрывает одни и те же данные.
Authy показал вторую форму нижестоящих полномочий
93 затронутых пользователя Authy принадлежали другой границе. Twilio сообщила, что злоумышленники добавили дополнительные устройства к этим аккаунтам, затем удалили несанкционированные устройства и связались с пользователями. Компания посоветовала пользователям проверить связанные аккаунты, просмотреть устройства, удалить всё незнакомое и отключить поддержку нескольких устройств после настройки резервного устройства.
Это была не просто утечка контактных данных. Добавление устройства Authy могло дать злоумышленнику продолжающийся доступ к одноразовым кодам аутентификации для связанных сервисов, в зависимости от конфигурации аккаунта и мер защиты этих сервисов. Рекомендация Twilio проверить связанные аккаунты отражала этот потенциал. Публичный отчёт не говорит, что все 93 пользователя пострадали от компрометации связанного сервиса, поэтому корректное состояние — «несанкционированное устройство зарегистрировано», за которым следует расследование для каждого клиента.
Signal и Authy вместе показывают два вида усиления облачных сервисов. В случае Signal представление поддержки коммуникационного провайдера пересеклось с потоком регистрации нижестоящего сервиса. В случае Authy механизм регистрации устройств в продукте для идентификации мог расширить возможность аутентификации злоумышленника на другие аккаунты. Ни тот, ни другой вред плохо измеряется подсчётом только организаций-клиентов Twilio.
Они также показывают ценность дизайна, который сдерживает взлом провайдера. Сервер Signal не хранил историю переписки, контакты или данные профиля, которые злоумышленник из Twilio мог бы получить. Его PIN-код Signal и блокировка регистрации обеспечивали ещё одну границу помимо обладания SMS-кодом, хотя блокировка регистрации была опциональной, и Signal призывал пользователей включить её. Сервис всё равно зависел от Twilio на чувствительном шаге, но его архитектура ограничивала то, что эта зависимость могла раскрыть. Облачную зависимость редко удаётся устранить; её можно сузить.
Минимизация данных должна распространяться на административные представления
Провайдеры часто описывают минимизацию данных в терминах хранения в базах данных. Это событие добавляет ещё одно измерение: минимизацию представления. Поле может легитимно храниться для доставки, борьбы с мошенничеством, выставления счетов или диагностики и при этом не должно появляться полностью перед каждой учётной записью поддержки. Интерфейс может показывать замаскированный номер, результат доставки или односторонний статус проверки, не показывая полный секрет или каждую связанную запись.
В отчёте об инциденте не публиковался пофайловый отчёт о том, что потерял каждый затронутый клиент Twilio. Это упущение может отражать конфиденциальность клиентов, ограничения расследования или разнообразие продуктов и представлений поддержки. Тем не менее оно создаёт разрыв в гарантиях. Клиенты не могут вывести собственную подверженность риску из агрегированного числа Twilio, а внешние читатели не могут проверить, был ли доступ надлежащим образом минимизирован.
Подотчётный провайдер должен уметь собрать для каждого клиента пакет доказательств с идентичностью сотрудника, приложением, сессией, временными метками, запросами или объектами, представленными полями, экспортами, изменениями и уровнем уверенности. Клиент затем может сопоставить доказательства провайдера со своими пользователями и обязательствами. Если точных журналов нет, провайдер должен сказать об этом и принять консервативную оценку затронутой совокупности, а не тихо превращать отсутствующую телеметрию в «отсутствие влияния».
Текущая документация Twilio отличает ограниченные API-ключи от более широких учётных данных и рекомендует использовать минимальный конкретный доступ. (Обзор API-ключей Twilio) Этот принцип минимальных привилегий должен действовать для инструментов поддержки так же строго, как для клиентских API-клиентов. Узкий ключ клиента мало что защищает, если внутренняя универсальная учётная запись поддержки может видеть всех арендаторов и все чувствительные поля после одного фишингового входа.
Административный дизайн должен также отделять наблюдение от действия. Просмотр статуса сообщения, изменение конфигурации аккаунта, создание учётных данных, регистрация устройства и просмотр одноразового кода имеют разные последствия. Они должны требовать разных авторизаций и однозначных событий аудита. Для действий с высоким риском можно требовать недавнюю повторную аутентификацию, устойчивую к фишингу, состояние управляемого устройства, одобренную клиентом сессию поддержки или двойной контроль. Цель — не сделать поддержку непригодной. Цель — заставить компрометацию сотрудника истечь до того, как она станет инцидентом клиента.
Уведомление — это распределённый контроль реагирования на инциденты
Twilio уведомила затронутые организации-клиентов индивидуально. Затем эти клиенты должны были определить, какие из их пользователей затронуты, какое состояние представляют данные и какое защитное действие пропорционально. Signal мог действовать, потому что получил достаточно информации, чтобы идентифицировать примерно 1900 номеров, проверить активность по трём и сообщение о перерегистрации по одному. Он начал прямое уведомление к 15 августа, через одиннадцать дней после того, как Twilio обнаружила несанкционированный доступ, и завершил процесс на следующий день.
Эта последовательность показывает, почему уведомление провайдера не может состоять только из фразы «ваш аккаунт затронут». Нижестоящей организации нужны временные метки в общем часовом поясе, поля доступных данных, идентификаторы, пригодные для сопоставления, выполненные действия, границы сессий, уровень уверенности, статус локализации и продолжающиеся индикаторы. Ей также нужен безопасный способ получить пакет. Расплывчатое или запоздалое уведомление переносит издержки расследования на клиента и может сделать невозможным соблюдение собственных юридических или контрактных сроков клиента.
Руководство Федеральной торговой комиссии (FTC) пореагированию на утечки данныхговорит компаниям, хранящим данные для других, уведомлять затронутые компании и советует организациям убедиться, что поставщик услуг действительно исправил уязвимость. Оно также подчёркивает документирование расследования, сохранение доказательств, проверку затронутой информации и совокупности и предоставление людям деталей, которые помогают им защититься. Это руководство — не вывод о правоприменении против Twilio, но оно отражает операционный стандарт, применимый к цепочке провайдеров.
Текущиерекомендации NIST по реагированию на инцидентыпомещают обработку инцидентов в подготовку, обнаружение, реагирование, восстановление и улучшение, а не рассматривают её как событие команды безопасности, начинающееся после подтверждения. Для облачного провайдера коммуникация с клиентами принадлежит этой операционной модели. Качество уведомлений следует отрабатывать до инцидента: генерировать образец пакета доказательств для конкретного арендатора и проверять, может ли клиент действовать на его основе.
Текущее дополнение Twilio о защите данных говорит, что компания будет без неоправданной задержки уведомлять клиентов о покрываемых инцидентах безопасности и оказывать разумное содействие, когда клиенты должны уведомлять органы власти или субъектов данных. Оно также описывает конфиденциальные аудиторские отчёты и обязанности клиента по конфигурации. (Дополнение Twilio о защите данных) Поскольку связанная версия обновлена в 2026 году, её не следует ретроспективно читать как точный контракт для каждого клиента в 2022 году. Она полезна как текущее заявление о том, как распределяются уведомление, содействие, аудит и разделённая ответственность.
Фактические права зависят от соглашения и закона, применимого к каждому клиенту.
Устранение последствий затронуло путь входа, но доказательства остаются неполными
Twilio сообщила о четырёх немедленных действиях по искоренению: сброс скомпрометированных учётных данных сотрудников, аннулирование активных сессий, связанных со скомпрометированными приложениями, интегрированными с Okta, блокировка известных индикаторов и запрос на удаление поддельных доменов Twilio. Затем она перечислила пять долгосрочных мер: более строгие меры двухфакторной аутентификации и токены FIDO2 для всех сотрудников, дополнительные меры контроля VPN, удаление или ограничение функций в административных инструментах, более частое обновление токенов для приложений, интегрированных с Okta, и дополнительное обязательное обучение.
Это вполне конкретный список мер по устранению. Он соответствует нескольким стадиям атаки, а не обещает лишь «воспринимать безопасность всерьёз». FIDO2 решает проблему имитации проверяющего. Более короткий срок жизни токенов сокращает полезное окно после компрометации учётных данных или сессии. Контроль VPN добавляет ещё одну границу политики. Ограничение административных функций снижает радиус поражения. Обучение и предупреждения улучшают распознавание и сообщение об инцидентах.
Список также показывает, о чём клиентам стоит спрашивать дальше. Стал ли FIDO2 обязательным для каждой аутентификации сотрудников и привилегированных учётных записей, с восстановлением, не допускающим фишинг? Надёжно ли аннулирование сессий отменяло сессии приложений, а не только сессию поставщика идентификации? Какие административные функции были удалены, какие лишь скрыты и какое одобрение теперь ими управляет? Насколько коротки обновляемые токены и может ли команда по инцидентам аннулировать их глобально за минуты?
Были ли номера бывших сотрудников удалены из внутренних справочников и программ адресных предупреждений с сохранением маршрута, по которому они могут сообщить об имитации?
Twilio заявила, что видит немедленные выгоды от улучшений. Публичный отчёт не определил эти выгоды метриками и не предоставил независимой оценки эффективности операций. Текущийобзор безопасности компанииописывает команду реагирования на инциденты безопасности, меры контроля доступа, тестирование, сертификаты и другие элементы программы.Trust Center Twilioпредоставляет контролируемый доступ к документам гарантий, таким как отчёты SOC 2. Эти источники могут помочь клиенту провести должную проверку сейчас, но текущий сертификат не следует рассматривать как судебно-медицинский вердикт о контроле июля 2022 года.
Объём аудита, период, проверенные критерии, исключения и дополнительные клиентские меры контроля — всё это имеет значение.
Заслуживающая доверия публичная карта устранения последствий могла бы защитить чувствительные детали и при этом раскрыть результаты:
| Контрольный вопрос | Доказательство, подтверждающее закрытие | Публичный статус |
|---|---|---|
| Может ли клонированная страница входа дать работоспособный вход в систему? | Обязательная устойчивая к фишингу аутентификация для сотрудников, подрядчиков, администраторов, восстановления и легаси-приложений; число исключений и результаты учений | Раздача FIDO2 объявлена; охват и запасные пути не публичны |
| Может ли одна сессия сотрудника достичь чрезмерного объёма данных клиентов? | Разграничение ролей и арендаторов, маскирование полей, повышение привилегий по требованию, двойной контроль для чувствительных представлений, периодический пересмотр прав | Административная функциональность ограничена; точный объём не публичен |
| Может ли украденная идентичность сохранить доступ после локализации? | Измеренное время глобального аннулирования сессий, короткие токены, результаты тестов по каждому интегрированному приложению | Сессии аннулированы, частота обновления повышена; операционная метрика не публична |
| Могут ли клиенты реконструировать доступ провайдера? | Видимые арендатору журналы чтения и записи, экспортируемые события, достаточный срок хранения, протестированные пакеты доказательств | Текущие функции мониторинга задокументированы; охват представлений поддержки 2022 года не публичен |
| Могут ли разрозненные внешние сообщения быстро стать одним инцидентом? | Публичный приём, круглосуточная сортировка, корреляция очередей, уровни обслуживания эскалации, отслеживание повторений | Публичные маршруты для уязвимостей и злоупотреблений существуют; метрики обработки 2022 года не публичны |
| Могут ли нижестоящие пользователи действовать своевременно? | Уведомление на уровне полей и идентификаторов с временными метками и безопасной доставкой; ежегодное учение по уведомлению | Индивидуальная связь подтверждена; полное время и содержание уведомлений не публичны |
Отсутствие публичных доказательств — не доказательство отсутствия контроля. Это повод оценивать гарантии отдельно от реализации. Twilio может предоставлять конфиденциальные доказательства корпоративным клиентам или аудиторам, которые нельзя безопасно публиковать. Закупочная команда должна их запросить. Публичная подотчётность всё же может улучшиться через агрегированные показатели охвата и производительности, не раскрывающие ни идентичность клиента, ни защитные секреты.
У клиентов была ответственность, но не контроль над рабочей силой Twilio
Разделённую ответственность часто призывают после облачного инцидента так, что это размывает границу. Клиенты Twilio отвечали за дизайн своих приложений, локальные учётные данные, уведомление пользователей и чувствительность данных, которые они решили отправлять через сервис. Они не выбирали аутентификатор сотрудников Twilio, не решали, какие поля поддержки видны, не настраивали её внутренний VPN и не аннулировали скомпрометированные сессии сотрудников. Это были меры контроля провайдера.
Клиенты всё же могли уменьшить последствия сбоя провайдера. Сервис, использующий SMS для регистрации, может добавить PIN-код, специфичный для приложения, задержать изменения в аккаунтах с высоким риском, уведомить существующее устройство, обнаруживать перерегистрацию и требовать более сильного пути восстановления для чувствительных пользователей. Он может минимизировать данные в содержимом сообщений, избегать использования коммуникационного события как единственного доказательства личности и нанести на карту каждого внешнего провайдера, участвующего в регистрации и восстановлении.
Клиенты Twilio также могут разделять проекты и учётные данные, использовать ограниченные API-ключи, ротировать раскрытые секреты и экспортировать события платформы.Руководство компании по борьбе с мошенничеством для разработчиковрекомендует триггеры использования, географические ограничения, субакаунты и быструю ротацию ключей для защиты от злоупотреблений на стороне клиента. Эти меры в основном нацелены на компрометацию или мошенничество в собственном аккаунте клиента, а не на просмотр внутреннего инструмента сотрудником Twilio. Они всё же уменьшают смежный радиус поражения и дают клиенту независимый сигнал, если злоумышленник перейдёт от доступа к данным к генерации трафика.
Проверка зависимостей предприятия должна прослеживать функции, а не имена поставщиков. «Мы используем Twilio» — слишком широко. Одна команда может использовать программируемый голос, другая — SMS-оповещения, третья — разовую проверку, четвёртая — поддержку клиентов, а пятая — Authy. У каждой функции разные хранимые данные, доступ поддержки, поведение при сбое и средства защиты пользователей. Закупки должны требовать карту потоков данных и полномочий для каждого использования.
Краткое руководство NIST по управлению рисками кибербезопасности цепочки поставокрассматривает поставщиков технологических услуг как часть цепочки поставок и связывает риск поставщика с управлением, а не с разовой закупкой. В применении к этому делу клиенты должны инвентаризировать зависимости от провайдеров, определять критичные функции и данные, устанавливать требования к уведомлению об инцидентах, получать гарантийные доказательства и планировать альтернативы. Это более требовательно, чем добавление общего пункта об утечке, но оно делает облачные отношения управляемыми.
Распределение ответственности в цепочке Twilio
Злоумышленникиотобрали сотрудников, получили сопоставления номеров телефонов, имитировали внутренние системы, собирали учётные данные и коды, входили в системы без авторизации и искали данные клиентов. Их ответственность за атаку прямая. Описание кампании как организованной или методичной объясняет возможности; оно не снимает ответственности ни с одного владельца контроля.
Команды безопасности и идентификации Twilioконтролировали протоколы аутентификации, политику поставщика идентификации, жизненный цикл сессий, VPN, мониторинг, корреляцию инцидентов и механизмы аннулирования. Они отвечали за то, чтобы украденный секрет сотрудника был недостаточен, за обнаружение необычного доступа и за отсечение каждой производной сессии.
Руководители продуктов и поддержки Twilioконтролировали, что административные инструменты показывали и разрешали. Они отвечали за границы арендаторов, маскирование данных, повышение привилегий, журналирование чтения, чувствительные действия и за то, может ли поддержка клиентов работать с меньшими постоянными полномочиями.
Руководители Twilio и наблюдательный советконтролировали инвестиции, принятие рисков, гарантии и стимулы вокруг отчётности. Их задача была не в том, чтобы ни один сотрудник никогда не кликнул. Она заключалась в требовании доказательств того, что клик не может открыть широкие полномочия клиента и что инцидент можно быстро восстановить и сообщить о нём.
Затронутые клиентыконтролировали нижестоящую архитектуру приложений и реакцию пользователей. Аккаунт Signal показывает ответственное сдерживание: он сопоставил данные провайдера с пользователями, ограничил, что было и не было раскрыто, заставил пройти повторную регистрацию, уведомил пользователей и продвигал блокировку регистрации. Обязанности других клиентов зависели от их данных и использования продукта.
Посредники — поставщики идентификации, операторы связи, хостинг-провайдеры, регистраторы и платформы— контролировали части инфраструктуры атаки. Быстрые действия могли сократить кампанию, но изолированные удаления не могли решить проблему способности противника ротировать ресурсы. Эти провайдеры нуждались в совместимых доказательствах, доверенных контактах для эскалации и анализе повторений, а не в последовательности несвязанных заявок о злоупотреблениях.
Регуляторы и государственные органынесли ответственность за приём уведомлений, координацию там, где законы пересекаются, расследование подтверждённых нарушений и публикацию материальных выводов, когда это юридически возможно. Twilio утверждает, что уведомила соответствующих регуляторов и ответила на вопросы. Изученный публичный архив не показывает окончательного публичного регуляторного постановления по этому конкретному инциденту, поэтому его нельзя использовать ни для заявления об одобрении регулятора, ни о доказанном нарушении.
Что публичный архив всё ещё не может ответить
Самый сильный анализ подотчётности отмечает неизвестное, а не заполняет его уверенными формулировками. Twilio публично не объяснила, как были собраны номера телефонов сотрудников. Group-IB предположила, что ранний таргетинг телекоммуникационных организаций мог дать часть номеров, но это гипотеза о кампании, а не доказанный источник, специфичный для Twilio.
Публичный архив не сообщает, сколько сотрудников ввели учётные данные, какие факторы использовал каждый затронутый аккаунт, захватывали ли злоумышленники одноразовые коды в реальном времени и был ли задействован какой-либо путь восстановления. Он не даёт посессионной хронологии от первой успешной аутентификации до 9 августа.
В нём не опубликован полный набор внутренних инструментов, до которых добрались, права каждой учётной записи сотрудника или пофайловый список просмотренных полей и действий для каждого клиента. Signal предоставляет детали по своей совокупности, но эти детали не следует обобщать на остальные 208 клиентов.
В нём не показано, получил ли каждый затронутый клиент достаточно информации для завершения нижестоящего уведомления, как быстро уведомили каждого клиента и сколько конечных пользователей в итоге оповестили по всему инциденту. Цифра 209 не может быть преобразована в совокупность физических лиц.
В нём нет независимой публичной проверки завершённого развёртывания FIDO2, запасных путей, аннулирования токенов, ограничений VPN или сокращений административных инструментов. Более поздние гарантийные документы могут конфиденциально покрывать часть контроля, но их объём и исключения нужно изучать, а не предполагать.
Наконец, он не устанавливает, что был сбой платформы Twilio, что злоумышленники получили доступ к содержимому сообщений всех затронутых клиентов, что API-ключи клиентов украдены или что каждый потенциально подвергшийся риску пользователь Signal был перерегистрирован. Такие утверждения вышли бы за пределы доказательств.
Главный тест — сколько полномочий может купить одно правдоподобное сообщение
Инцидент Twilio иногда сводят к SMS-фишингу, затронувшему крошечную долю клиентов. Это описание арифметически защитимо и операционно неполно. Важной единицей был не процент клиентских аккаунтов. Это был объём нижестоящих полномочий, доступных после того, как сотрудник прошёл аутентификацию не в том месте.
Для одного клиента полученный доступ коснулся процесса регистрации телефонных номеров, которым пользуются около 1900 потенциально затронутых человек. Для 93 пользователей Authy к продукту для аутентификации были добавлены несанкционированные устройства. В более широкой кампании недорогие домены, клонированные страницы, текстовые сообщения и быстро передаваемые коды достигли более сотни организаций. Злоумышленники тратили немного, чтобы создать ещё одну точку контакта. Защитники многократно платили за выявление, сообщение, проверку, отключение, расследование, уведомление и доказательство.
Объявленный ответ Twilio двинулся в правильном техническом направлении. Ключи FIDO2 изменили предложение аутентификации. Более короткие сессии и более широкое аннулирование ограничили время. Сокращённая административная функциональность ограничила полномочия. Обучение, публичные каналы сообщений и скоординированные удаления улучшили человеческий и межпровайдерный уровни. Эти меры заслуживают большего веса, чем общие извинения.
Однако подотчётность не заканчивается развёртыванием. Клиентам нужны доказательства того, что устойчивая к фишингу аутентификация применяется без слабых запасных путей, что инструменты поддержки раскрывают только то, что требует задача, что каждое чувствительное чтение атрибутируется, что подозрительные сессии можно аннулировать во всех приложениях и что доказательства по инциденту для конкретного клиента могут двигаться быстрее, чем обязанность клиента уведомлять. Советам директоров нужны показатели охвата, исключений, учений и времени реагирования.
Регуляторам нужно достаточно фактов, чтобы отличать неудачный клик от неразумного дизайна контроля.
Устойчивый урок не в том, что людям нельзя доверять или что облачные коммуникации уникально небезопасны. Он в том, что доверие к облачному провайдеру включает его сотрудников, административные интерфейсы, протоколы идентификации, контакты для злоупотреблений и механизм уведомлений. Правдоподобное сообщение рано или поздно дойдёт до кого-то в неподходящий момент. Подотчётная система — та, которая спроектирована так, что сообщение покупает почти ничего, порождает немедленный сигнал и оставляет запись, которой может воспользоваться каждый затронутый клиент.

