Формально это не «взлом» в привычном смысле — никто не подбирал пароль и не эксплуатировал уязвимость в коде. Но по последствиям для бизнеса разница невелика: доступ к критичной инфраструктуре пропал в одностороннем порядке, без предупреждения, и восстановить его через техподдержку было невозможно в принципе — решение принималось не на уровне компании-клиента, а на уровне геополитики.
Формальный повод — новость с июля 2026 года: Adobe начала отключать действующие подписки российских пользователей, приобретённые по программам VIP и VIP Marketplace, спустя четыре года после остановки продаж новых лицензий. Под отключение попали и корпоративные аккаунты, которые исправно оплачивались всё это время. В нашем кейсе студия узнала об этом не из новости, а по факту — программы просто перестали открываться.
Как это эксплуатируется
Здесь стоит разделить два сценария: как «падает» сам вендор-лок, и как этим фактом дополнительно пользуются злоумышленники, зная, что тысячи компаний одновременно оказались в панике.
Сценарий 1. Технический механизм отключения
Adobe Creative Cloud — это не «программа на диске», а тонкий клиент, который на каждом запуске проверяет статус лицензии через облачный API. Проверка идёт на домены вида lm.licenses.adobe.com и ims-na1.adobelogin.com по 443 порту. Если сменить регион аккаунта в биллинге на «отключён» — приложение при следующей проверке токена получает отказ:
curl -s -o /dev/null -w "%{http_code}\n" \
https://lm.licenses.adobe.com/v3/license/status \
-H "Authorization: Bearer <expired_token>"
403
{"licenseError":"LICENSE_EXPIRED","region":"RU","gracePeriod":0}Никакого локального обхода нет — Photoshop, Illustrator, InDesign не умеют работать в офлайн-режиме дольше короткого grace-периода, а он тоже управляется удалённо. Файлы в форматах .psd/.ai/.indd открываются только внутри экосистемы, доступ к облачным библиотекам (Creative Cloud Libraries) обрывается вместе с лицензией — то есть отключается не только редактор, но и хранилище с проектами.
Сценарий 2. Как этим пользуются злоумышленники — уже на следующий день
Массовые новости об отключении подписок — идеальный повод для фишинга. Схема развёртывается быстро и типично:
- Регистрируется домен-двойник вроде
adobe-license-restore.ruилиcreative-cloud-support-ru.com— через сервисы автоматической выдачи SSL (Let's Encrypt), чтобы в браузере был замок. - С помощью Gophish или Social-Engineering Toolkit (SETOOLKIT) за час собирается фишинговая рассылка «Восстановите доступ к вашей лицензии Adobe» с точной копией страницы логина Adobe ID.
- Письмо уходит на корпоративные адреса, найденные через Hunter.io или банальный OSINT по домену компании (
theHarvester -d studio-example.ru -b google,bing). - Сотрудник в панике (дедлайн через два дня!) вводит логин, пароль и данные карты для «продления» — учётка и платёжные данные утекают.
Дальше эта учётка используется для доступа к реальным проектным файлам в Creative Cloud (если она ещё жива у других сотрудников студии), либо перепродаётся на теневых форумах как «рабочий аккаунт с подпиской».
Как аудит вскрыл масштаб зависимости
При разборе инцидента я не искал уязвимость в коде — я искал точки единой зависимости от одного поставщика. Порядок был такой:
# инвентаризация исходящих соединений с рабочих машин
tcpdump -i any -n host adobelogin.com or host licenses.adobe.com
# поиск захардкоженных токенов и API-ключей в локальных проектах и репозиториях
gitleaks detect --source ./studio-projects --report-path gitleaks-report.json
trufflehog filesystem ./studio-projects --json
# проверка, где физически лежат "единственные копии" файлов
rclone lsd remote:CreativeCloudFiles
rclone size remote:CreativeCloudFilesРезультат: локальных копий активных проектов не было вообще — 100% рабочих файлов лежали только в облаке вендора. Аналогичная картина обнаружилась с почтой (иностранный хостинг без резервной выгрузки) и с бухгалтерским архивом (синхронизация только в один облачный диск без второй копии).
Что и почему сработало бы дальше
Если бы студия попыталась «решить проблему быстро» без аудита, у сценария развития было минимум три плохих ветки:
- Установка пиратской версии. Кряки для Adobe часто идут с трояном или майнером внутри exe — типичный вектор через модифицированный
amtlib.dll, который заодно открывает reverse shell атакующему. - Ввод платёжных данных на фишинговом «восстановлении лицензии» — прямая потеря денег и доступа к почте, если пароль переиспользовался.
- Срыв контракта на 600 000 ₽ из-за невозможности сдать проект в срок — с репутационными потерями кратно выше суммы контракта, если заказчик был ключевым.
Отдельно стоит учитывать CVE в самом продукте: даже бесплатный Adobe Reader, который тоже попадал под ограничения, регулярно фигурирует в бюллетенях (например, use-after-free уязвимости класса CVE-2023-26369 в Acrobat/Reader, эксплуатируемые через специально сформированный PDF). Компании, которые в панике ставят «неофициальные обновления» или альтернативные сборки с форумов, чтобы не потерять функциональность, реально расширяют поверхность атаки.
Как закрыли
Работа шла в двух плоскостях — немедленное восстановление доступа к текущему проекту и системное снижение зависимости от единой точки отказа.
- Перенос файлов на отечественное облако с версионированием. Настроена синхронизация через
rcloneна Яндекс.Диск/VK WorkDocs с ежедневным снапшотом:rclone sync /home/studio/projects yadisk:projects-backup \ --backup-dir yadisk:projects-backup-archive/$(date +%F) \ --log-file /var/log/rclone-sync.log - Локальные копии активных проектов на рабочих станциях через
cron-задачу каждые 2 часа, чтобы отключение облака не блокировало текущую работу мгновенно:0 */2 * * * rsync -av --delete /mnt/cloud/active-projects/ /home/studio/local-cache/ - Частичный переход на российские аналоги для верстки и обработки изображений там, где формат файлов позволял безболезненную миграцию.
- Мониторинг статуса подписок в реальном времени — простой скрипт опрашивает биллинг-API используемых сервисов и шлёт алерт в Telegram при смене статуса:
#!/bin/bash STATUS=$(curl -s -H "Authorization: Bearer $TOKEN" \ https://api.vendor.example/subscription/status | jq -r .state) if [ "$STATUS" != "active" ]; then curl -s -X POST https://api.telegram.org/bot$BOT_TOKEN/sendMessage \ -d chat_id=$CHAT_ID -d text="Внимание: статус подписки изменился на $STATUS" fi - Регламент проверки писем от вендоров — все сообщения о «продлении лицензии» проверяются через заголовки (
Received, SPF/DKIM) и никогда не открываются по прямой ссылке из письма, только через закладку в браузере.
Удобный иностранный сервис — это не проблема, пока вы не поймёте, что решение о вашей работе принимаете не вы.
После перенастройки повторное отключение любого зарубежного сервиса — а это уже не гипотетический, а регулярно повторяющийся сценарий с 2022 года — обходится студии в пару часов простоя вместо недели без файлов и контракта на 600 000 ₽.