ShinyHunters заявили о взломе EY через подрядчика: чему учит атака на цепочку поставок

Коротко о главном

Аудиторско-консалтинговый гигант EY (Ernst & Young) подтвердил утечку данных: неизвестные получили доступ к стороннему сервису тикетов поддержки, которым пользовалась ИТ-служба компании, и с 28 марта по 12 апреля 2026 года выгрузили документы с персональными и финансовыми данными клиентов, включая сведения для подготовки налоговых деклараций. 27 июля 2026 года группировка ShinyHunters добавила EY на свой сайт утечек и заявила, что украденные учётные данные подрядчика открыли им путь во внутренние Jira, GitHub и облако Azure компании — эти утверждения EY публично не подтвердила.

Для команд разработки главный вывод не в самом бренде, а в векторе: взлом начался не с продукта EY, а со стороннего поставщика. Именно так всё чаще выглядит атака на цепочку поставок — периметр держит оборону, а вход находят через доверенного подрядчика с валидными доступами. Это ровно тот класс рисков, который закрывают услуги информационной безопасности и регулярный ИТ-аудит, а не только межсетевой экран на входе.

Действовать стоит по трём фронтам сразу: провести инвентаризацию подрядчиков и их доступов, включить в контур защиты сами инструменты разработки (таск-трекеры, репозитории, облачные среды) и проверить, что «валидный логин» из чужой инфраструктуры не даёт тихо ходить по вашей — здесь помогает регулярный пентест. Ниже — что именно произошло, что подтверждено, а что пока только заявлено.

Что именно произошло

По уведомлениям, которые EY разослала клиентам, неавторизованная третья сторона имела доступ к платформе тикетов поддержки в период с 28 марта по 12 апреля 2026 года. Аномальную активность компания зафиксировала 23 апреля, после чего запустила процедуры реагирования на инцидент: привлекла внешних экспертов по кибербезопасности, закрыла несанкционированный доступ и уведомила федеральные правоохранительные органы. Официальные уведомления об утечке EY подала генеральному прокурору штата Калифорния 15 июля 2026 года, а также регуляторам Вермонта и ряда других штатов.

В скомпрометированных документах, по данным EY, содержались персональные данные, связанные с инвестиционными активами клиентов институциональных клиентов фирмы, а также финансовая информация, использовавшаяся при подготовке налоговой отчётности. Точное число пострадавших компания не раскрыла. Пострадавшим предложены 24 месяца мониторинга кредитной истории через Experian. В своих заявлениях EY подчеркнула, что не располагает признаками того, что злоумышленники целенаправленно выбирали конкретных людей, и что на данный момент ей неизвестно о фактах злоупотребления данными.

Название стороннего сервиса поддержки EY не разглашает, и независимо оно пока не подтверждено. Ключевая деталь для оценки риска в том, что скомпрометирован был не внутренний продукт фирмы, а внешняя платформа, которой пользовалась её собственная ИТ-служба, — то есть звено на стыке компании и подрядчика.

Что заявляет ShinyHunters — и что пока не подтверждено

27 июля 2026 года группировка ShinyHunters, известная серией крупных краж данных и вымогательством, добавила EY в свой список жертв. По версии злоумышленников, речь идёт об атаке на цепочку поставок: учётные данные, полученные из стороннего сервиса тикетов, якобы дали доступ к внутренней платформе управления проектами Jira, репозиториям GitHub и облачным средам Azure компании. Иными словами, группировка утверждает, что от первоначального доступа к подрядчику удалось совершить боковое перемещение в ядро внутренней разработки и облачной инфраструктуры EY.

Здесь важна аккуратность: эти утверждения исходят от самой атакующей стороны и на момент публикации не подтверждены EY. Публичные заявления компании касаются только доступа к стороннему сервису и не затрагивают вопрос о том, действительно ли злоумышленники пробрались во внутренние Jira, GitHub и Azure. Заявления вымогателей на сайтах утечек нередко преувеличены — их стоит воспринимать как гипотезу, требующую проверки, а не как установленный факт.

Но даже как гипотеза этот сценарий полезен для моделирования угроз. Он описывает реалистичную и всё более частую цепочку: подрядчик → украденные учётные данные → таск-трекер и репозитории → облако. Если хотя бы часть заявленного верна, это классический пример того, как компрометация одного доверенного звена превращается в доступ к исходному коду, секретам и облачным ресурсам.

Почему это важно для команд разработки

Многие команды по-прежнему проводят границу безопасности по периметру продукта: защищают прод, CI/CD и клиентские данные, но относятся к таск-трекеру, вики и репозиториям как к «внутренней кухне» с более мягким режимом. Кейс EY напоминает, что именно эти инструменты — Jira, GitHub, облачные консоли — и есть привлекательная цель: там лежат исходный код, архитектурные схемы, токены, ключи и переписка о том, где что уязвимо.

Второй урок — про доверенных подрядчиков. Сервис поддержки, служба хелпдеска, подрядчик на аутсорсе или SaaS-инструмент получают легитимные доступы к вашим системам, и их компрометация выглядит для ваших средств защиты как действия «своего». Атака на цепочку поставок обходит периметр не взломом стены, а входом через дверь, которую вы сами открыли партнёру. Поэтому доступы подрядчиков должны жить по тем же правилам, что и собственные учётные записи: минимальные привилегии, отдельный мониторинг, быстрый отзыв.

Третий момент — реалистичный тайминг. В кейсе EY доступ длился около двух недель, обнаружение произошло примерно через полторы недели после его завершения, а публичные уведомления — спустя месяцы. Этот разрыв между компрометацией, обнаружением и раскрытием — норма, а не исключение, и именно он определяет, сколько данных успеет утечь. Сократить его помогает не разовая проверка, а постоянный мониторинг аномалий в доступах.

Как защитить цепочку поставок: практический чек-лист

Ниже — последовательность шагов, которую стоит пройти командам, не дожидаясь собственного инцидента. Она не привязана к конкретному вендору и одинаково применима к продуктовым компаниям и к тем, кто ведёт разработку с подрядчиками.

Инвентаризируйте подрядчиков и их доступы. Составьте живой реестр всех сторонних сервисов и партнёров, у которых есть учётные данные к вашим системам, — от хелпдеска и SaaS-инструментов до аутсорс-команд. Нельзя защитить доступ, о котором вы забыли.

Введите минимальные привилегии и сегментацию. Учётная запись подрядчика не должна открывать путь ко всему сразу. Разделяйте среды так, чтобы компрометация одного сервиса не давала бокового перемещения в репозитории и облако.

Включите инструменты разработки в контур защиты. Jira, GitHub/GitLab и облачные консоли требуют обязательного MFA, регулярного пересмотра прав, отзыва доступов уволившихся и подрядчиков, а также аудита секретов и токенов в коде.

Настройте мониторинг аномалий доступа. Логируйте вход и действия во внутренних системах и настраивайте оповещения на нетипичное поведение — вход из новой геолокации, массовую выгрузку, доступ в нерабочее время. Цель — сократить недели необнаруженного присутствия до часов.

Регулярно проверяйте оборону на практике. Периодический пентест и аудит кода показывают, действительно ли «валидный логин» из чужой инфраструктуры упирается в стену, а не открывает дорогу дальше. Проверяйте не только периметр, но и сценарии бокового перемещения.

Подготовьте план реагирования и уведомления. Заранее определите, кто и как действует при инциденте с подрядчиком, как быстро отзываются доступы и в какие сроки вы обязаны уведомлять клиентов и регуляторов. В кризис импровизировать поздно.

Часто задаваемые вопросы

Что произошло с EY? Компания подтвердила, что неавторизованная третья сторона имела доступ к стороннему сервису тикетов поддержки её ИТ-службы с 28 марта по 12 апреля 2026 года и выгрузила документы с персональными и финансовыми данными клиентов. Уведомления регуляторам EY подала 15 июля 2026 года.

При чём здесь ShinyHunters? 27 июля 2026 года группировка добавила EY на свой сайт утечек и заявила, что доступ подрядчика позволил проникнуть во внутренние Jira, GitHub и Azure компании. Эти утверждения исходят от атакующих и на момент публикации EY не подтверждены.

Что такое атака на цепочку поставок? Это компрометация не самой цели, а доверенного к ней звена — поставщика, подрядчика или SaaS-инструмента с легитимным доступом. Через него злоумышленник входит в системы жертвы, минуя периметр, потому что для средств защиты такой доступ выглядит легитимным.

Как командам разработки защититься? Инвентаризируйте доступы подрядчиков, введите минимальные привилегии и сегментацию, включите таск-трекеры, репозитории и облако в контур защиты с MFA и мониторингом аномалий, а оборону регулярно проверяйте пентестом и аудитом.

Источники

BleepingComputer — Ernst & Young discloses data breach after support system hack, июль 2026 года.

Security Affairs — Ernst & Young (EY) investigates data breach involving third-party support tickets, июль 2026 года.

Daily Security Review — ShinyHunters Claims Ernst & Young Breach via Third-Party System, 27 июля 2026 года.