В октябре 2019 года Ryuk зашифровал системы отслеживания посылок Pitney Bowes - логистической компании, которая, по собственным заявлениям, обслуживает 90% Fortune 500. Компания привлекла консультантов, восстановила инфраструктуру, выпустила пресс-релиз. Через семь месяцев Maze проник в ту же сеть и предъявил 11 скриншотов каталогов внутренних серверов. А в 2026-м ShinyHunters слили 8,2 миллиона записей из их Salesforce.
Три группировки, три вектора, один и тот же исход: postmortem, который никто не превратил в инженерную задачу. Ниже - разбор TTPs каждой атаки, анализ системных провалов в incident response и detection-чеклист, чтобы не стать хронической жертвой.
Почему компании взламывают повторно: бизнес-логика рецидива
Повторная кибератака на компанию - не случайность. Это рациональный выбор атакующего, и он опирается на три вещи.Ценность данных. Pitney Bowes обрабатывает корпоративную логистику для тысяч enterprise-клиентов. Одна утечка - и атакующий получает верифицированную базу с именами, должностями, телефонами и адресами для целевого фишинга (T1566, Initial Access) против этих клиентов. Причём утечка зацепила и госорганы: по данным из открытых источников, атака привела к компрометации персональных данных сотрудников ирландской налоговой службы - для неё Pitney Bowes был поставщиком почтовых услуг.
Сигнал слабости. Первый успешный взлом показывает: IR-процесс у жертвы незрелый, remediation неполный, вероятность повторного успеха выше среднего. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные (T1078, Valid Accounts). Для Pitney Bowes использование T1078 публично подтверждено только в инциденте 2026 года (ShinyHunters); для Ryuk и Maze - гипотеза. Но если после первого инцидента компания не провела полную ротацию credentials, вектор сохраняется.
Экономика вымогательства. Жертва, которая уже потратилась на forensic-расследование, уведомление регуляторов и восстановление систем, более склонна заплатить выкуп. По данным Verizon DBIR 2025, медианный выкуп ransomware составил $46 000 в 2024 году, но для крупных enterprise-жертв суммы могут быть на порядок выше.
Хронология Pitney Bowes: три инцидента за семь лет
2019: Ryuk - шифрование и незавершённый IR-цикл
В октябре 2019 года Pitney Bowes сообщил, что "ransomware зашифровал файлы на ряде систем, сделав некоторые сервисы недоступными для пользователей". По данным SecurityWeek, инцидент затронул продукты почтовых систем, портал Your Account, магазин расходных материалов и сервисы Presort. Компания утверждала, что "нет свидетельств доступа к данным клиентов или сотрудников".Вектор initial access публично не раскрыт. Эксперт KnowBe4 Роджер Граймс, процитированный SecurityWeek, указал на два наиболее вероятных варианта: фишинг (T1566) или эксплуатация непатченного ПО (T1133, External Remote Services) - "фишинг участвует в 70-90% успешных взломов, а непатченное ПО - в 20-40%". Ryuk - human-operated ransomware: оператор вручную управляет развёртыванием для максимального покрытия систем перед шифрованием (T1486, Data Encrypted for Impact).
И вот что интересно: какой контроль должен был сработать? Если initial access через фишинг - почему email gateway не перехватил? Если через непатченный сервис - почему vulnerability management не закрыл окно?
2020: Maze - повторная кибератака через семь месяцев
Понедельник, 11 мая 2020 года. Группировка Maze публикует заявление о взломе Pitney Bowes и выкладывает 11 скриншотов каталогов внутренней сети в качестве доказательства. Компания подтвердила инцидент и заявила, что "атака была остановлена до того, как злоумышленникам удалось зашифровать данные", а объём скомпрометированных данных "оказался весьма ограниченным".Тут стоит задать неудобный вопрос. 11 скриншотов с каталогами внутренних серверов - это результат lateral movement по нескольким хостам. Если атаку "остановили до шифрования", это говорит лишь о том, что phase Impact (T1486) не завершилась. А вот Credential Access, Discovery и Lateral Movement к тому моменту уже отработали. Это как сказать "мы поймали грабителя до того, как он вынес телевизор" - но он уже обошёл весь дом и сфотографировал содержимое шкафов.
Maze отличался от Ryuk тактикой double extortion: шифрование плюс угроза публикации данных на leak-сайте. Сам факт публикации скриншотов означает: атакующие уже эксфильтровали артефакты (T1005, Data from Local System) до обнаружения.
Семь месяцев между Ryuk и Maze - окно, в которое должен был уместиться полный IR-цикл: containment, eradication, root cause analysis, lessons learned, remediation. Факт повторного проникновения означает: либо remediation был неполным, либо root cause analysis не выявил реальную точку входа.
2026: ShinyHunters - утечка 8,2 млн записей из Salesforce
В апреле 2026 года группировка ShinyHunters скомпрометировала Salesforce CRM Pitney Bowes. По верифицированным данным Have I Been Pwned, утечка затронула 8 243 989 записей: email-адреса, должности, ФИО, номера телефонов и физические адреса. Dexpose.io сообщает, что ShinyHunters заявили о доступе к 25 млн записей Salesforce - расхождение с подтверждёнными данными типично для заявлений ransomware-групп (любят приврать).По данным yellowcom.co.uk, вектор атаки - фишинг, через который была скомпрометирована учётная запись сотрудника. Цепочка: Phishing (T1566) -> Valid Accounts (T1078) -> доступ к Salesforce CRM -> Data from Local System (T1005) -> эксфильтрация. После неудачных попыток вымогательства ShinyHunters публично слили базу.
Этот инцидент - часть масштабной кампании. По данным infowatch.ru, ShinyHunters в 2026 году опубликовали данные 40 компаний, включая Zara, 7-Eleven, Carnival Corporation. Как описывает pkware.com, группировка целенаправленно атакует SaaS и CRM-платформы через социальную инженерию и перехват SSO-токенов. В мае 2026 года Charter Communications (Spectrum) был скомпрометирован через vishing-звонок, позволивший получить доступ к Microsoft Entra - аналогичный паттерн.
Принципиальное отличие от двух предыдущих инцидентов: вектор сместился из on-premise в облако. Даже если Pitney Bowes укрепил серверную инфраструктуру после Maze, облачная поверхность атаки - Salesforce CRM с миллионами записей - осталась вне scope мониторинга.
TTPs трёх атак через MITRE ATT&CK
Сравнение TTPs показывает эволюцию атакующих - и стагнацию защиты.
| Этап kill chain | Ryuk (2019) | Maze (2020) | ShinyHunters (2026) |
|---|---|---|---|
| Initial Access | Фишинг или непатченное ПО (T1566 / T1133) | Не раскрыт - вероятно, T1566 или T1078 | Фишинг -> компрометация email (T1566) |
| Persistence | Не раскрыт | Не раскрыт | Valid Accounts к Salesforce (T1078) |
| Collection | Не подтверждён | Каталоги внутренней сети (T1005) | Массовая выгрузка из Salesforce CRM (T1005) |
| Impact | Шифрование систем (T1486) | Попытка шифрования + double extortion (T1486) | Публикация данных + вымогательство |
| Defense Evasion | Не раскрыт | Не раскрыт | Легитимные credentials обходят сетевые контроли |
Неизменный паттерн: initial access через фишинг или скомпрометированные учётные данные. По данным IBM X-Force Threat Intelligence Index 2025, количество атак с использованием действительных учётных данных выросло на 71% год к году. Verizon DBIR 2025 фиксирует: 36% инцидентов начинаются с фишинга, 38% - с кражи credentials. Pitney Bowes попал в обе категории трижды.
Для пентестера хронология Pitney Bowes - учебник рационального выбора вектора. Зачем искать 0-day, если фишинг работает три раза подряд? Для security engineer - сигнал: если SIEM не коррелирует фишинговые алерты с последующими аномальными логинами в SaaS-платформы, SOC слеп к самому распространённому kill chain.
Провалы incident response: где сломался процесс реагирования
Один инцидент - событие. Три за семь лет - системный IR-провал. Разберём причины.Разорванный цикл lessons learned
Полноценный IR-цикл по NIST CSF v2.0 включает анализ инцидента (RS.AN-01) и восстановление с учётом полученного опыта (RC.CO-01). Lessons learned - не факультативный шаг, а обязательная часть процесса. Без него каждый следующий инцидент начинается с тех же дыр.Реконструируем таймлайн после Ryuk (октябрь 2019):
- Неделя 3-4. Eradication: ротация всех учётных данных - доменные аккаунты, сервисные, API-ключи, токены SaaS-интеграций.
- Месяц 2. Root cause analysis: конкретный вектор initial access, конкретный хост, конкретная учётная запись. Не "возможно, фишинг" - а какое письмо, от кого, кому.
- Месяц 2-3. Lessons learned report с задачами: detection gap X - создать правило корреляции Y, baseline Z отсутствует - внедрить UEBA.
- Месяц 3-6. Remediation: реализация задач из отчёта.
- Месяц 7 (май 2020). Maze проникает в сеть.
Неполная ротация credentials
Если Maze использовал те же или смежные учётные данные, что и операторы Ryuk, - полная ротация credentials не состоялась. В enterprise-средах это классическая ошибка: ротируют пароли доменных администраторов, но забывают сервисные аккаунты, API-токены интеграций и учётные записи в SaaS.К 2026 году проблема вышла на уровень облака: ShinyHunters получили доступ к Salesforce через скомпрометированную учётную запись сотрудника. MFA на Salesforce CRM либо отсутствовала, либо была обойдена - pkware.com описывает перехват SSO-токенов как характерную тактику ShinyHunters в кампании 2026 года.
Слепая зона: облачная поверхность атаки
Первые два инцидента - on-premise. Третий - SaaS. Даже если Pitney Bowes вложился в hardening серверов и сегментацию сети после Maze, облачные платформы не вошли в scope.По NIST CSF v2.0, ID.AM-01 предполагает актуальную инвентаризацию управляемых активов. Salesforce CRM с 8+ млн записей - критический актив. Если его нет в asset inventory как объекта мониторинга с detection-правилами в SIEM, он невидим для SOC. А невидимый актив - подарок для атакующего.
Detection-чеклист: корреляционные правила против повторных атак
Разбирая хронологию Pitney Bowes, я вижу не три отдельных инцидента - а один непрерывный провал организационного мышления. Технические контроли здесь вторичны. Ни один SIEM не компенсирует ситуацию, когда findings из postmortem не превращаются в задачи с дедлайнами и ответственными.
В разборах post-breach расследований я раз за разом натыкаюсь на один и тот же корень: lessons learned report пишут, но выполнение рекомендаций никто не отслеживает. Через полгода приходит новая группировка - и обнаруживает те же gaps, потому что отчёт лежит в корпоративной wiki, а задачи в трекере так и висят в статусе Open.
Факт, который редко озвучивают: многие корпоративные SOC не имеют формализованного процесса post-incident review с обязательным аудитом выполнения рекомендаций. Detection rules пишутся под конкретный IOC, а не под класс TTPs. Credentials ротируются частично - домен сбросили, а Salesforce API-токен остался с теми же правами. MFA внедряется на VPN, но не на CRM с восемью миллионами записей.
Pitney Bowes - не исключение, а норма. Разница в том, что их ломали публично трижды и это попало в заголовки. Если у вас был хотя бы один инцидент - откройте lessons learned report и проверьте: сколько рекомендаций реально реализовано? Сколько задач закрыто, а сколько протухло в бэклоге? По свежим инцидентам этого типа на форуме codeby.net разбираем подобное на ежемесячной основе.
Последнее редактирование модератором:
