Цифровой злоумышленник проник в облачную среду AWS и менее чем за 10 минут, благодаря ускорению на базе ИИ, прошел путь от первоначального доступа до административных привилегий.
Команда Sysdig Threat Research Team сообщила, что они зафиксировали взлом 28 ноября, отметив, что он выделялся не только скоростью, но и «множественными индикаторами», указывающими на то, что преступники использовали большие языковые модели для автоматизации большинства этапов атаки: от разведки и повышения привилегий до горизонтального перемещения, написания вредоносного кода и LLMjacking — использования скомпрометированной учетной записи облака для доступа к облачным LLM.
«Злоумышленник получил административные привилегии менее чем за 10 минут, скомпрометировал 19 различных сущностей AWS и злоупотребил моделями Bedrock, а также вычислительными ресурсами GPU», — заявили директор отдела исследований угроз Sysdig Майкл Кларк и исследователь Алессандро Брукато в посте в блоге об облачном взломе. «Сгенерированный LLM код с сербскими комментариями, несуществующие идентификаторы учетных записей AWS и несуществующие ссылки на репозитории GitHub — все это указывает на наступательные операции с помощью ИИ».
Первоначально злоумышленники получили доступ, похитив действительные тестовые учетные данные из общедоступных бакетов Amazon S3. Учетные данные принадлежали пользователю службы управления идентификацией и доступом (IAM) с множеством разрешений на чтение и запись в AWS Lambda и ограниченными разрешениями в AWS Bedrock. Кроме того, в бакете S3 также содержались данные Retrieval-Augmented Generation (RAG) для ИИ-моделей, которые позже пригодились во время атаки.
Чтобы предотвратить такой тип кражи учетных данных, не оставляйте ключи доступа в общедоступных бакетах. Sysdig рекомендует использовать временные учетные данные для ролей IAM, а организациям, которые настаивают на предоставлении долгосрочных учетных данных пользователям IAM, следует периодически их ротировать.
После безуспешных попыток использовать имена пользователей, такие как «sysadmin» и «netadmin», обычно связанные с административными привилегиями, злоумышленник в конечном итоге добился повышения привилегий путем инъекции кода в функцию Lambda, злоупотребив разрешениями UpdateFunctionCode и UpdateFunctionConfiguration скомпрометированного пользователя:
Они трижды заменили код существующей функции Lambda под названием EC2-init, итеративно меняя целевого пользователя. Первая попытка была нацелена на adminGH, которому, несмотря на название, не хватало административных привилегий. Последующие попытки в конечном итоге увенчались успехом в компрометации администратора frick.
Специалисты по безопасности отмечают, что комментарии в коде написаны на сербском языке — вероятно, указывая на происхождение злоумышленника — сам код перечислял всех пользователей IAM и их ключи доступа, создавал ключи доступа для frick, а также выводил список бакетов S3 с их содержимым.
Написание кода для LLM 101
Кроме того, код злоумышленника содержал «комплексную» обработку исключений, по словам специалистов по безопасности, включая логику для ограничения перечисления бакетов S3 и увеличение времени выполнения Lambda с трех секунд до 30 секунд.
Эти факторы, в сочетании с коротким временем от кражи учетных данных до выполнения кода в Lambda, «убедительно свидетельствуют» о том, что код был написан LLM, по мнению исследователей угроз.
Далее злоумышленник занялся сбором идентификаторов учетных записей и попытками получить роль OrganizationAccountAccessRole во всех средах AWS. Интересно, что он включил идентификаторы учетных записей, которые не принадлежали организации жертвы: два с возрастающими и убывающими цифрами (123456789012 и 210987654321) и один идентификатор, который, по-видимому, принадлежал законной внешней учетной записи.
«Такое поведение соответствует шаблонам, часто приписываемым галлюцинациям ИИ, предоставляя дополнительные потенциальные доказательства деятельности с помощью LLM», — написали Кларк и Брукато.
В общей сложности злоумышленник получил доступ к 19 идентификаторам AWS, включая шесть различных ролей IAM в 14 сессиях, а также пять других пользователей IAM. Затем, используя новую созданную учетную запись администратора, преступники украли множество конфиденциальных данных: секреты из Secrets Manager, параметры SSM из EC2 Systems Manager, журналы CloudWatch, исходный код функций Lambda, внутренние данные из бакетов S3 и события CloudTrail.
Атаки LLMjacking
Затем они перешли к части атаки LLMjacking, чтобы получить доступ к облачным LLM жертвы. Для этого они злоупотребили доступом пользователя к Amazon Bedrock для вызова нескольких моделей, включая Claude, DeepSeek, Llama, Amazon Nova Premier, Amazon Titan Image Generator и Cohere Embed.
Sysdig отмечает, что «вызов моделей Bedrock, которые никто в учетной записи не использует, является тревожным сигналом», и предприятия могут создавать политики контроля служб (SCP) для разрешения вызова только определенных моделей.
После Bedrock злоумышленник сосредоточился на EC2, запрашивая образы машин, подходящие для приложений глубокого обучения. Он также начал использовать бакет S3 жертвы для хранения, и один из размещенных там скриптов выглядит так, будто он был разработан для обучения ML — но он использует несуществующий репозиторий GitHub, что предполагает, что LLM сгенерировал код, «галлюцинируя» репозиторий.
Хотя исследователи заявляют, что не могут определить цель злоумышленника — возможно, обучение моделей или перепродажа доступа к вычислениям — они отмечают, что скрипт запускает общедоступный сервер JupyterLab на порту 8888, предоставляя бэкдор к экземпляру, который не требует учетных данных AWS.
Однако по неизвестным причинам они завершили работу экземпляра через пять минут.
Это последний пример того, как злоумышленники все чаще полагаются на ИИ практически на каждом этапе цепочки атак, и некоторые руководители служб безопасности предупреждают, что это лишь вопрос времени, когда преступники смогут полностью автоматизировать атаки в больших масштабах.
Существуют меры, которые организации могут предпринять для защиты от подобных вторжений, и большинство из них включают усиление безопасности идентификации и управления доступом. Прежде всего: применяйте принципы минимальных привилегий ко всем пользователям и ролям IAM.
Sysdig также рекомендует ограничить разрешения UpdateFunctionConfiguration и PassRole в Lambda, ограничить разрешения UpdateFunctionCode для конкретных функций и назначать их только тем идентификаторам, которым для выполнения их работы требуются возможности развертывания кода.
Кроме того, убедитесь, что бакеты S3, содержащие конфиденциальные данные, включая данные RAG и артефакты ИИ-моделей, не являются общедоступными.
Также рекомендуется включить ведение журнала вызовов моделей для Amazon Bedrock для обнаружения несанкционированного использования.
Мы обратились к Amazon за комментарием, но они сообщили, что не смогут предоставить информацию к моменту публикации. Мы обновим эту статью любой соответствующей информацией, которую получим от них. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Jessica Lyons
