Аналитики Cisco Talos зафиксировали рост кампаний социальной инженерии, в которых злоумышленники используют легитимные системы автоматических уведомлений популярных SaaS-платформ (SaaS, модель программного обеспечения как услуги) для доставки спама и фишинговых писем. Атаки нацелены на злоупотребление инфраструктурой таких сервисов, как GitHub и Atlassian Jira, что позволяет вредоносным сообщениям беспрепятственно проходить проверки электронной почты на основе репутации отправителя. Этот метод, который эксперты называют "платформа как прокси" (Platform-as-a-Proxy, PaaP), представляет серьёзную угрозу, поскольку эксплуатирует базовое доверие организаций к уведомлениям от проверенных корпоративных инструментов.
Описание
Суть атаки заключается в том, что злоумышленники используют встроенные функции платформ для генерации автоматических оповещений, в тело которых внедряют фишинговые приманки. Поскольку письмо отправляется непосредственно с серверов GitHub или Atlassian, оно успешно проходит все стандартные механизмы аутентификации - SPF, DKIM и DMARC. Эти протоколы предназначены для проверки подлинности отправителя и целостности письма, но в данном случае они лишь подтверждают, что сообщение легитимно с технической точки зрения, так как исходит от доверенного источника. В результате фишинговое письмо получает "печать одобрения" инфраструктуры платформы, которую большинство почтовых шлюзов безопасности не настроены оспаривать.
В случае с GitHub механизм основан на злоупотреблении системой уведомлений о коммитах. Злоумышленники создают репозитории и делают коммиты, в сообщения к которым встраивают вредоносный контент. Платформа предоставляет два поля для текста: краткое обязательное описание и расширенное необязательное. В кратком описании злоумышленники размещают социальный триггер, например, тему срочного счета, чтобы привлечь внимание. Основной фишинговый контент, такой как поддельные реквизиты для оплаты или номера службы поддержки, помещается в расширенное описание. При отправке коммита система автоматически рассылает уведомления всем наблюдателям репозитория, доставляя вредоносную приманку через доверенный канал. Согласно отчёту Cisco Talos, в ходе одной из кампаний 17 февраля 2026 года около 2,89% всех писем, отправленных с адресов GitHub, были связаны с подобной злонамеренной активностью.
Атака через Jira использует несколько иной вектор, а именно функцию приглашения пользователей в проекты Service Management. Злоумышленник создаёт проект, вводя фишинговое название и описание в соответствующие поля конфигурации. Затем, используя функцию приглашения клиентов, он указывает электронные адреса жертв. Платформа Atlassian автоматически генерирует и отправляет официальное приглашение, подставляя введённые злоумышленником данные в свои шаблоны писем. Для получателя такое письмо выглядит как стандартное автоматическое уведомление от корпоративного инструмента, что резко повышает его доверительность и снижает бдительность.
Стратегическая проблема таких атак кроется в парадоксе доверия. Организации полагаются на SaaS-платформы для критически важных бизнес-процессов, и их инфраструктура по умолчанию считается безопасной. Злоумышленники используют эту репутацию для "отмывания" вредоносного контента. GitHub привлекает их высоким доверием в среде разработчиков, в то время как Jira служит инструментом для имитации внутренних ИТ-оповещений и уведомлений службы поддержки, на которые сотрудники привыкли реагировать быстро и без проверки.
Традиционные средства защиты на уровне почтового шлюза оказываются неэффективными против модели PaaP, поскольку они проверяют подлинность отправителя, а не намерение, стоящее за сообщением. Для противодействия требуется сдвиг парадигмы от бинарной модели "доверенный - недоверенный" к архитектуре, основанной на принципах Zero Trust (нулевого доверия). Во-первых, необходима верификация на уровне экземпляра и идентичности. Это означает, что следует принимать уведомления только с конкретных адресов или IP-диапазонов, связанных с корпоративными аккаунтами компании в этих сервисах. Любое письмо, даже с платформы GitHub, но инициированное внешним или непроверенным пользователем, должно автоматически помещаться в карантин.
Более эффективным подходом является мониторинг на уровне API SaaS-платформ. Прежде чем отправить фишинговое уведомление, злоумышленник должен выполнить на платформе ряд подготовительных действий: создать репозиторий, сконфигурировать проект, массово добавить пользователей. Интеграция журналов аудита (например, из GitHub или Atlassian) в SIEM-систему (Security Information and Event Management, система управления событиями и информацией безопасности) позволяет выявлять такие аномальные события в реальном времени - например, создание проекта с нестандартным названием из нехарактерной географической зоны. Это даёт возможность заблокировать вредоносный аккаунт до того, как фишинговые письма будут разосланы.
Дополнительный слой защиты может обеспечить анализ семантического соответствия. Каждая платформа имеет ожидаемый шаблон использования: GitHub - для совместной работы над кодом, Jira - для управления проектами. Системы безопасности можно настроить на обнаружение "семантического разрыва", когда содержание уведомления (например, требование срочной оплаты счета) противоречит основному назначению платформы. Такие сообщения должны маркироваться как подозрительные. Наконец, важно бороться с "усталостью от автоматизации", приучая пользователей не слепо доверять системным оповещениям. Для операций с высоким риском, таких как новые приглашения в проекты, следует вводить дополнительную проверку, например, через код подтверждения в самом интерфейсе платформы.
Таким образом, защита от атак, использующих модель PaaP, требует переноса фокуса с вопроса "Аутентифицировано ли это письмо?" на вопрос "Авторизована ли эта активность на платформе и соответствует ли она бизнес-логике?". Только комплексный подход, сочетающий контроль доступа, мониторинг действий и анализ контекста, может лишить злоумышленников главного преимущества - слепого доверия к легитимным каналам доставки.
Индикаторы компрометации
URLs
- https://github.com/Client-Billing-Desk/Accounts-Receivable/commit/a690ad2fd9d93ad9b8e51b842aca860352e1d8ed
- https://github.com/Client-Billing-Desk/Customer-Billing/commit/3f7962dc34f1b3a5c3ac5d8f5f637e351a4f9cca
- https://github.com/Invoice-Info/Billing0/commit/5c235a673469bfc29723bc0deb5eaa81b4cb8b89
- https://github.com/Invoice-Info/Payment/commit/5447f517b9cd54c490a8c2c843f115d73735ae11
- https://github.com/Invoice-Info/Receipt01/commit/1c96b6638bab2a53468669670ddb592995ef4216
- https://github.com/Invoice-Info00/Admin/commit/79e605e88b2d89f4b91931cf49328368317ad05c
- https://github.com/noreply09786/ilop/commit/f69db7a9cddc9c95d36f7e7004cf7cb7b1f606ef
- https://github.com/noreply09786/-Payment-Procseed-765/commit/4e4498fde87899b28199c6735f9a40432ca0ca73
- https://github.com/Receipt-Team/Payment/commit/5417ae6e83dc9a1fdbe985e9d7c1f47655ffa16f
- https://github.com/Receipt-Team/Services/commit/70eb76fcd9ed325202de908c2021fe52eee0c19d
