2 сентября 2026 года Unit 42 компании Palo Alto Networks опубликовала подробности расследования взлома корпоративной сети. Цифра, на которой держался отчёт: злоумышленник начал с общедоступного веб-сервиса и закончил root-доступом ко всей инфраструктуре менее чем за десять часов, тогда как команде людей на такую работу нужно примерно две недели.

Важнее другое: чего в этой истории не было. Никакого zero-day. Никаких редких приёмов. Вторжение использовало более 50 техник, уже описанных во фреймворке MITRE ATT&CK, то есть задокументированных и опубликованных техник, которые защитникам известны. Изменился не метод, а темп. Вместо того чтобы выполнять каждый этап вручную, оператор управлял ИИ-агентами, которые наблюдали, оценивали, действовали и перепланировали в едином непрерывном цикле, без пауз и без сна.

Что произошло за эти десять часов

Последовательность, как её описывает отчёт:

  1. Проникновение. Был взломан общедоступный веб-сервис, после чего через туннель был получен доступ во внутреннюю сеть.
  2. Разведка. Автоматизированный агент составил карту внутренних микросервисов без участия человека.
  3. Сбор секретов. Субагенты прочесали репозитории кода в поисках токенов доступа и паролей сервисов, записанных прямо в код.
  4. Повышение привилегий. Эти токены открыли систему управления секретами, которая выдала главные административные учётные данные с root-доступом ко всей инфраструктуре.
  5. Конвейеры. Конвейеры сборки и развёртывания были захвачены через собственные рабочие процессы, чтобы вывести наружу ключи доступа к облаку.
  6. Разворот. С помощью этих ключей собственные ИИ-эндпоинты жертвы были превращены в постэксплуатационную инфраструктуру злоумышленника.

Перечитайте последний шаг. Собственная ИИ-подписка компании стала инструментом в руках того, кто проник внутрь, и работала на её аккаунте и за её счёт. Это новый сценарий, который стоит внести в реестр рисков: каждый API-ключ к ИИ-модели одновременно и операционный актив, и статья расходов.

Важная для вас цифра — не десять часов

Десять часов впечатляют, но это данные одного инцидента. Цифра, которая действительно должна изменить ваше планирование, приведена в CrowdStrike 2026 Global Threat Report, где измеряется время прорыва (breakout time): промежуток между первым доступом злоумышленника и моментом, когда он начинает продвигаться к другим системам внутри сети.

  • Среднее время прорыва в eCrime сократилось до 29 минут, то есть скорость выросла на 65% за год.
  • Самый быстрый зафиксированный случай: 27 секунд.
  • Рост на 89% числа атак, приписываемых злоумышленникам, использующим ИИ.
  • 82% обнаружений в 2025 году были без вредоносного ПО: злоумышленник входит с действительными учётными данными, а не внедряет вирус.
  • Рост на 266% числа облачно-ориентированных вторжений со стороны групп, связанных с государствами.

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

Почему это сработало: секреты, записанные в коде

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

Это проблема не только крупных компаний. Пройдитесь по этому списку применительно к своим проектам:

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

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

Что сделать на этой неделе

Пять шагов. Первый не требует ни бюджета, ни внешнего подрядчика:

  1. Просканируйте репозитории на наличие секретов. Инструменты сканирования секретов доступны и встроены в крупные платформы для кода. Запускайте их по всей истории, а не только по текущей версии.
  2. Сделайте ротацию ключей рутиной, а не экстренной мерой. Ключ, который не менялся два года, — это утёкший ключ, о котором вы пока не знаете. И когда меняете ключ после утечки, меняйте его везде, где он использовался, а не в одном месте.
  3. Подготовьте единый сценарий отзыва доступа. Это прямая рекомендация Unit 42: уметь выполнить синхронизированное сдерживание, при котором одновременно отзываются учётные данные, сессии OAuth, конвейеры CI/CD и облачные аккаунты. Отзовёте только половину — дадите злоумышленнику время вернуться через другую половину.
  4. Управляйте ИИ как ключевой инфраструктурой. Ведите реестр всех используемых моделей и ключей, задайте ограничения частоты запросов, применяйте принцип минимальных привилегий и включите диагностическое журналирование. Отчёт прямо это рекомендует, и именно это превращает описанный выше инцидент из тихой катастрофы в раннее предупреждение.
  5. Требуйте ревью кода несколькими людьми и защиту веток. Особенно в репозиториях инфраструктуры как кода, поскольку именно через эту дверь изменение в одну строку внедряет бэкдор. Параллельно отслеживайте поведение, а не сигнатуры: всплески API-запросов и быстрые смены состояния — это отпечаток автоматизированного агента.

В саудовском контексте эти шаги — не факультативная хорошая практика. Основные средства контроля кибербезопасности Национального управления кибербезопасности (NCA) содержат отдельные домены по управлению идентификацией и доступом и по безопасности изменений и разработки, а ответственность за защиту персональных данных согласно Закону о защите персональных данных (PDPL) лежит на организации. Взлом, начавшийся с ключа, записанного в исходном коде, эту ответственность никак не уменьшает.

Взгляд Origami

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

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

Заключение

Метод атаки не изменился. Изменилась её скорость. Более 50 известных техник были выполнены менее чем за десять часов, потому что автоматизированные агенты выполняли их без остановки, а среднее время прорыва внутри сети теперь составляет 29 минут. Защиты, которая зависит от того, что кто-то вовремя заметит, больше недостаточно. Начните с самого простого и самого трудного вопроса: знаете ли вы, где прямо сейчас находятся ваши ключи и кто может их прочитать?

Источники