Клиенты ASOS, открыв свои телефоны, обнаружили нежелательное пуш-уведомление, отправленное через собственное приложение ретейлера. В сообщении утверждалось, что среда Snowflake компании была скомпрометирована, и содержался призыв к ASOS связаться с отправителем через Telegram. Позже ASOS подтвердила Sky News, что было отправлено несанкционированное уведомление для клиентов, и заявила, что расследует активность, связанную со сторонними платформами, используемыми для связи с клиентами. Компания также сообщила, что могла быть получена утечка базовой личной информации, включая имена и контактные данные, в то время как данные платежных карт и пароли от учетных записей, как предполагается, не пострадали.
Более масштабные заявления злоумышленников остаются неподтвержденными, и Snowflake сообщила Sky News, что ее расследование на тот момент не выявило никаких компрометаций платформы Snowflake. Тем не менее, даже без понимания полного пути проникновения в среду ASOS, это уведомление поднимает важный вопрос для команд безопасности: что происходит, когда злоумышленник получает возможность общаться через канал, которому клиенты уже доверяют?
Когда сообщение поступает из настоящего приложения
Большинство рекомендаций по повышению осведомленности о безопасности исходят из того, что получатель заметит что-то подозрительное. Отправитель может быть незнакомым, домен — немного искаженным, а запрос — неестественным. Эти проверки становятся гораздо менее полезными, когда сообщение поступает через подлинное приложение, установленное на чьем-то телефоне.
Злоумышленники уже движутся в этом направлении и в других областях. Исследование Rapid7, посвященное фишингу на основе календарей, показало, как вредоносный контент может появляться внутри привычных рабочих процессов, в то время как наш предыдущий материал об эволюции социальной инженерии исследовал растущее использование инструментов для совместной работы и других повседневных платформ, чтобы сделать атаки привычными.
Инцидент с ASOS переносит эту проблему в среду взаимодействия с клиентами. Как только злоумышленник получает доступ к системе, которая может говорить от имени бизнеса, доверие, выстроенное вокруг этой системы, также начинает работать в пользу злоумышленника.
«По правде говоря, злоумышленник предпочтет заимствовать уже существующее доверие, чем тратить время на создание собственного. Наше недавнее исследование Zimbra — отличный пример: как только вы получаете возможность выдавать себя за отправителя или редактировать календарь изнутри платформы, все, что проверяет жертва, находится в системе, в которой у нее нет причин сомневаться. Я не могу сказать, как это произошло в данном случае, но уведомление из реального приложения дает злоумышленнику ту же фору. Здесь нет странного домена или незнакомого отправителя, способного привлечь внимание, поэтому активность может выглядеть как обычный вторник после обеда», — Дуглас МакКи (Douglas McKee), директор по анализу уязвимостей в Rapid7.
Как выглядит подозрительная активность внутри легитимных сервисов
Злоумышленнику не всегда нужна очевидно вредоносная инфраструктура, чтобы нанести ущерб. Легитимная учетная запись, интеграция или SaaS-платформа, используемые неожиданным образом, могут обеспечить доступ к сотрудникам, клиентам или партнерам, генерируя при этом активность, которая при отдельном рассмотрении может выглядеть относительно рядовой.
Если сервис коммуникации с клиентами внезапно отправляет необычное уведомление, службе безопасности необходимо понять, что произошло вокруг него: кто получил доступ к платформе, изменились ли учетные данные или права доступа, какие подключенные сервисы были задействованы и появилась ли подозрительная активность в других частях среды.
Компания ASOS заявила, что эта активность затрагивала сторонние платформы, используемые для коммуникации с клиентами, в то время как TechRadar сообщил, что заявленная связь со Snowflake потенциально могла быть косвенной — через сервисы, работающие на этой платформе, а не свидетельствовать о компрометации самой Snowflake. Подобная среда может заставить следователей работать с несколькими поставщиками, учетными записями и системами, прежде чем у них сложится полная картина произошедшего.
MDR должна отслеживать активность по всей среде
Когда злоумышленники используют легитимные учетные записи, интеграции, облачные службы или коммуникационные платформы, аналитикам необходимо связывать поведение между системами, а не полагаться на известный вредоносный IP-адрес или сигнатуру малвари. Неожиданная аутентификация, изменение прав, сторонний доступ или необычная активность со стороны ориентированного на клиентов сервиса могут быть недостаточны для того, чтобы поднять тревогу сами по себе, но их последовательность может выявить гораздо более четкий паттерн.
Упреждающий подход MDR объединяет эти сигналы на конечных точках, в учетных записях, облачных средах и других частях поверхности атаки, чтобы аналитики могли исследовать активность в контексте. Предприятия теперь полагаются на растущее число SaaS-сервисов и внешних платформ, которые могут действовать от их имени, и хотя команды безопасности могут управлять не каждым из таких систем напрямую, им все равно необходимо понимать, каким доступом они обладают, как они подключаются к общей среде и как будет проявляться их нецелевое использование.
Это становится особенно актуально, когда сторонний сервис может осуществлять внешнюю коммуникацию от имени организации. Доступ к платформе — это лишь часть картины; командам также необходима видимость того, как этот доступ используется и не свидетельствует ли активность в других местах о компрометации учетной записи или интеграции.
Первое сообщение может создать вторую волну риска
Заметный инцидент может предоставить другим злоумышленникам полезный материал. Как только клиентам становится известно о происшествии, фишинговое письмо или текстовое сообщение с предложением обновить учетную запись, получить возврат средств, сбросить пароль или пройти проверку безопасности мгновенно обретает под собой достоверное событие.
Исследование Rapid7, посвященное утечкам цифровых следов, показало, как скомпрометированная информация может сочетаться с общедоступными данными для поддержки более убедительного фишинга, выдачи себя за другое лицо и мошенничества. Имена и контактные данные могут казаться относительно ограниченными по сравнению с паролями или платежной информацией, но они все равно могут стать ценными в сочетании с реальным инцидентом и узнаваемым брендом.
Поэтому расследование должно поддерживать принятие сразу нескольких решений: понимание технического масштаба, определение того, какие данные клиентов или бизнеса могли быть затронуты, взаимодействие со сторонними провайдерами, оценка регуляторных обязательств и подготовка к возможности того, что этот инцидент будет использован повторно в последующих атаках.
Поскольку все больше коммуникаций с клиентами переносится в приложения, на SaaS-платформы, в автоматизированные рабочие процессы и сторонние сервисы, командам безопасности необходима прозрачность в отношении того, как используются эти каналы и кто имеет к ним доступ. Чем раньше удастся связать необычную активность в этих системах, тем больше времени у аналитиков будет на расследование и реагирование до того, как доверенный канал станет частью гораздо более крупного инцидента.
