Откройте свой плейбук по реагированию на скомпрометированные учетные записи и изучите первые 15 минут. Большинство центров оперативной безопасности (SOC) начинают реагирование с телефонного звонка или сообщения пользователю через Teams с вопросом, действительно ли он совершал вход в систему в 2 часа ночи из незнакомой страны. Дальнейшие действия зависят от ответа пользователя.
Попробуйте проделать то же самое с учетной записью службы, и вы будете ждать очень долго. То же самое касается API-ключа, спрятанного в конвейере сборки, или токена OAuth, который кто-то предоставил интеграции SaaS в 2022 году и с тех пор не вспоминал. Как только один из них будет украден, ваши аналитики запустят скрипт, написанный с учетом человеческого фактора, и трещины проявятся задолго до первой смены.
Их также гораздо больше, чем осознает большинство советов директоров. Исследование CyberArk ставит машинные идентификаторы примерно в 82 раза больше, чем человеческие. Очень немногие из них защищены многофакторной аутентификацией (MFA), и немалое количество обладает гораздо большими правами доступа, чем требуется для выполняемой ими задачи. Я бы добавил проблему, которой уделяется меньше внимания: их трафик теряется в фоновом шуме, который ваша система мониторинга настроена фильтровать.
Где человеческий плейбук дает сбой
Владение — это обычно первое, что замедляет вас. Когда учетная запись человека скомпрометирована, HR может сообщить вам, кто это, и кто его менеджер, еще до того, как вы выпьете свой кофе. Учетная запись службы, извлекающая не те данные, не имеет такого короткого пути, поэтому аналитик тратит первый час, выясняя, какая команда ее создала. Чаще, чем кто-либо хотел бы признать, этот след ведет к подрядчику, который покинул компанию годом ранее.
Допустим, вы нашли владельца; сдерживание все еще не является таким простым шагом, как для человека. Заблокируйте пользователя, и один сотрудник потеряет полдня. Однако, если вы извлечете учетные данные, от которых зависит платежная интеграция, вы можете вывести из строя клиентский сервис, что ни один аналитик не захочет иметь на своем счету в 23:00 без разрешения. Поэтому они ищут кого-то достаточно высокопоставленного, чтобы одобрить сбой, пока злоумышленник продолжает действовать.
Обнаружение — это то, что люди недооценивают. Злоумышленник с действительным токеном совершает аутентифицированные вызовы к тем же конечным точкам, к которым интеграция обращается каждый день, и терпеливый злоумышленник будет даже придерживаться обычного времени. Ваши правила «невозможного путешествия» были разработаны для людей, перемещающихся между городами, поэтому здесь им не с чем сравнивать.
Что показывают недавние взломы
Отчет Cloudflare о своем инциденте безопасности на День благодарения 2023 года стоит пятнадцати минут времени любого CISO. Злоумышленники проникли с одним токеном доступа и тремя учетными данными учетных записей служб, полученными во время предыдущего взлома поддержки Okta. Cloudflare ротировала тысячи учетных данных после Okta, но упустила эти четыре, потому что команда ошибочно полагала, что их никто не использует. Оповещение, которое наконец сработало, пришло более чем через неделю после того, как злоумышленники впервые вошли в систему, когда они добавили одну из этих учетных записей служб в группу администраторов.
Дело Microsoft было связано с тестовым приложением, которое никто не удалил. Их руководство для специалистов по реагированию на атаку «Midnight Blizzard» описывает перебор паролей против устаревшей тестовой учетной записи арендатора без MFA. Внутри этого арендатора находилось старое тестовое приложение OAuth, которое все еще имело повышенный доступ к корпоративной среде, и злоумышленники использовали его для получения доступа к корпоративным почтовым учетным записям.
«Drift» — это случай, который я бы представил совету директоров. В августе 2025 года злоумышленники получили токены OAuth, которые чат-бот Drift от Salesloft использовал для связи с Salesforce, и в течение примерно десяти дней они извлекали записи из одной клиентской инсталляции Salesforce за другой. Команда Google по анализу угроз, которая внимательно отслеживала кампанию, пришла к выводу, что злоумышленники в основном искали учетные данные. После извлечения данных они начали искать в них ключи доступа AWS и пароли, все, что могло бы помочь им проникнуть в следующую компанию.
Я не думаю, что кому-либо из этих трех потребовался хитрый злоумышленник у парадной двери. В каждом случае учетные данные выдавались для выполнения работы, а затем оставлялись без внимания задолго после того, как работа была завершена.
Подготовка фундамента
Создать плейбук — относительно простая задача. Однако плейбук опирается на инвентаризацию. Во многих организациях эта инвентаризация состоит из списка учетных записей служб, сгенерированного из Active Directory, где половина полей описания оставлена пустыми. Каждый раз, когда вы идентифицируете нечеловеческий идентификатор с высокими привилегиями, документируйте команду, ответственную за этот идентификатор, и предоставьте краткое объяснение (одно-два предложения), описывающее, что произойдет, если вы удалите этот идентификатор. Многие люди не включают объяснение, почему что-то перестанет работать при удалении, поскольку получение этой информации требует обращения к команде приложения за разъяснениями; этот контакт иначе был бы инициирован вашим аналитиком в 3:00 ночи, пока злоумышленник остается активным в вашей сети.
Далее отсортируйте эти идентификаторы по радиусу поражения. Я бы не ставил токен только для чтения для отчетности на тот же путь реагирования, что и главный администратор облака, и я сомневаюсь, что ваши аудиторы тоже. Для высшего эшелона заранее определите, кто имеет право авторизовать немедленную отмену, даже если это приведет к сбою чего-либо, и укажите эту роль в плейбуке по имени. Руководители должны принять это решение. Если вы оставите это на усмотрение дежурного, вы получите вежливое ожидание разрешения, пока токен остается активным. Для организаций, регулируемых SOCI, это дает дополнительное преимущество, поскольку 12-часовое окно для сообщения о значительном инциденте кибербезопасности в ASD может истекать, пока этот разговор затягивается.
Сортировка, подходящая для машины
Никто не может дать ответ на вопрос «это были вы?», поэтому замените его вопросами, на которые можно ответить с помощью лог-файлов. Быстрым способом проверки является местоположение: откуда обычно входят учетные данные и откуда они входят в настоящее время? Логирование легко доступно через Cloud Audit Logs и Workload Identity Platforms, если кто-то включил логирование.
Разрешения занимают больше времени, но дают больше информации. Сопоставьте то, что имеет идентификатор, с тем, что он использовал за последние несколько месяцев, поскольку злоумышленники, как правило, напрямую нацеливаются на высокорисковые области, которые простаивали. Я бы уделил такое же внимание устойчивости. Имея в руках привилегированный главный идентификатор службы, злоумышленник часто создает новые секреты или регистрирует собственное приложение, и ничего из этого не исчезает при отзыве исходных учетных данных.
Сдерживание без ущерба для бизнеса
«Триггер» для ротации и отзыва должен быть написан отдельно в плейбуке. Ротация будет уместна, когда вы достаточно уверены, что злоумышленник не эскалировал свои действия, и организация не может позволить себе потерять интеграцию. Отзыв — очевидный выбор, если вы обнаружите доказательства продолжающейся атаки; это будет достаточно ясно, чтобы не было споров в полночь.
Предварительная подготовка учетных данных для замены сделает отзыв терпимым. Когда команда, владеющая приложением, ранее протестировала, как сгенерировать новые учетные данные, а затем сохранить их в своей системе управления секретами, отзыв старых учетных данных может обойтись вам примерно в десять минут простоя вместо полного дневного сбоя. Попросите команду попрактиковаться в генерации и сохранении новых учетных данных в неделю с низкой нагрузкой. Не выясняйте в середине инцидента, что в руководстве по эксплуатации ссылается на расположение хранилища, которое было переименовано в прошлом году.
Оценка масштаба и восстановление
Чтобы понять полный масштаб инцидента, рассмотрите весь жизненный цикл машинных учетных данных, а не только период после генерации оповещения. Поскольку машины могут оставаться незамеченными как скомпрометированные в течение многих месяцев до обнаружения, первая необычная активность, о которой сообщается, скорее всего, не будет первой выполненной необычной активностью. Также имейте в виду, что «дрейф» — это отличный способ запомнить, какие данные доступны идентификатору, и были ли в него помещены какие-либо учетные данные. Если да, то каждое добавление секрета потребует от вас добавления новой ротации в ваш список.
Восстановление — это исправление первопричины проблемы. Например, если статический секрет был скомпрометирован, определите, может ли эта рабочая нагрузка использовать краткосрочные токены с помощью федерации идентификаторов рабочей нагрузки; или, возможно, краткосрочный токен может быть сгенерирован по запросу (Just-In-Time) и автоматически истечет. Восстановление — это утомительная, неинтересная задача, и в большинстве случаев она требует финансовой поддержки от организации за пределами Центра оперативной безопасности (SOC).
Перед окончательным утверждением плейбука проведите имитационное учение с участием владельцев приложений и Центра оперативной безопасности (SOC). Выберите вашу интеграцию с наивысшими привилегиями и смоделируйте событие кражи токена (от первого оповещения до восстановления). Во время симуляции, когда необходимо принять решение о том, кто утверждает отзыв токена, и отзыв токена приведет к сбою производства, наблюдайте, сколько времени потребуется команде, чтобы определить, кто должен принять это одобрение.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ashish Mishra
