Barracuda раскрыла детали атаки на часть своего облачного окружения. Злоумышленник получил доступ не через уязвимость, а по действующему облачному ключу, который компания выдала стороннему подрядчику и не отозвала после завершения проекта. В октябре инфраструктуру самого подрядчика, работающего в сфере ИИ, скомпрометировали, и ключ Barracuda оказался у атакующего.
По данным компании, активность началась 1 ноября и продолжалась около 44 часов. За это время атакующий прошёл примерно десять облачных аккаунтов: читал секреты, включая ключи AWS и секреты service principal в Azure, переходил от одной системы к другой, добрался до аналитики, токена доступа к исходному коду и кластеров Kubernetes. В одном случае он разместил контейнер, который монтировал файловую систему хоста и собирал с неё учётные данные.
Отдельно злоумышленник искал криптовалюту: переменные WALLET, MNEMONIC, SEED и PRIV, файлы keystore Ethereum, расширенные приватные ключи и секреты Kubernetes с «кошельковыми» именами. На тех серверах кошельков не было, но намерение компания зафиксировала. Она также не исключает, что целью были учётные данные AI-сервисов: подрядчик работает в этой сфере, а похожие атаки в октябре пережили ещё несколько AI-платформ.
По набору приёмов и манере работы Barracuda связывает атаку с ARTEX - открытым AI-фреймворком для пентеста, который вышел в июле. Он использует планировщика и worker-агентов, а в реальных атаках его применяли разные группы, поэтому совпадение говорит о способе действий, а не о конкретном заказчике. Barracuda подчёркивает, что расследование не установило факт доступа к учётным данным клиентов, но компания решила исходить из худшего и ротировала все секреты, которые могли быть в зоне доступа.
Главный вывод компании: стратегия «обнаружить и отреагировать» уже недостаточна, потому что атакующий успевает закончить за двое суток. Barracuda советует убирать долгоживущие ключи, особенно выданные подрядчикам, переходить на короткоживущие узкие учётные данные, сокращать радиус поражения и заранее готовиться к массовой ротации секретов и восстановлению из проверенного состояния.
Атаку заметили не по срабатыванию защитного средства, а после того, как инженер обратил внимание на подозрительную активность в своей учётной записи и сообщил о ней. В тот же день о собственном инциденте рассказал подрядчик: он не считал, что затронул Barracuda, но передал то, что знал. По словам компании, именно это ускорило разбор. К моменту обнаружения атакующий уже завершил работу - он потратил меньше двух суток.
Barracuda не нашла прямых доказательств доступа к интеграционным учётным данным клиентов, но признала, что журналирование в этой среде было недостаточно подробным, чтобы полностью исключить такой доступ. Компания уведомила клиентов Barracuda Managed XDR Cloud и Monitored Endpoint, чьи API-ключи могли быть в зоне риска, и попросила отозвать и пересоздать их. Остальным клиентам, по её словам, действия не требуются.
Источник: https://blog.barracuda.com/2026/11/11/anatomy-of-a-machine-speed-intrusion
