Вторжения сочетали эксплуатацию веб-приложений с действиями в AWS
Открытый фреймворк для агентного пентеста AntiFox связывали с вторжениями, исходившими с инфраструктуры в Alibaba Cloud. Активность включала эксплуатацию доступных из интернета веб-приложений и операции в AWS, в том числе проверку учётных данных, перечисление облачных сервисов, доступ к секретам и работу с объектами S3. Точную уязвимость, использованную для компрометации приложений IIS, установить не удалось. В некоторых случаях активность начиналась с применения действительных учётных данных AWS, полученных неизвестным способом.
Действия на серверах IIS
На скомпрометированных серверах IIS процесс w3wp.exe создавал веб-шеллы ASPX и запускал команды whoami и icacls. С их помощью проверяли контекст выполнения, каталоги и разрешения. PowerShell обращался к классам конфигурации .NET, чтобы извлечь настройки из web.config и строки подключения к базам данных.
Команды также искали журналы и резервные копии конфигураций, а файлы копировали в каталоги, доступные через веб. Полученные учётные данные баз данных применялись для попыток подключения к внутренним производственным базам данных.
Запросы к облачным сервисам
В AWS использовали действительных пользователей IAM и, в некоторых случаях, предположительно роли EC2. Один источник мог переключаться между несколькими идентификаторами и выполнять сотни запросов API примерно за полчаса. Сначала обнаруживали идентификаторы и разрешения, затем быстро отправляли запросы List, Get и Describe к IAM, EC2, S3, Lambda, Secrets Manager, KMS и RDS.
Многие запросы получали отказ, но в тех же последовательностях были и успешные вызовы, в том числе GetSecretValue для производственного секрета. Другая активность использовала API S3 для перечисления бакетов и объектов, получения и копирования объектов, а также их удаления.
Рекомендации по обнаружению и реагированию
Авторы отчёта рекомендуют расследовать активность в AWS, исходящую от неизвестной хостинговой инфраструктуры, особенно быстрые запросы к нескольким сервисам или использование нескольких учётных данных из одного источника. Ответы об отказе в доступе сами по себе не подтверждают, что вторжение не удалось. На конечных точках следует отслеживать запуск оболочек или интерпретаторов процессами рабочих процессов IIS, а также создание непредвиденных файлов ASPX. Активность веб-шеллов нужно сопоставлять с последующим использованием облачных API.
Для обнаружения и реагирования авторы рекомендуют:
- включить события управления CloudTrail и события данных S3 для чувствительных хранилищ;
- настроить оповещения о доступе к секретам с новой инфраструктуры;
- незамедлительно изолировать затронутые серверы;
- проверить и удалить несанкционированные веб-файлы, сохранив соответствующие доказательства;
- обновить скомпрометированные учётные данные и отозвать затронутые сеансы и ключи;
- применить политики минимальных привилегий к идентификаторам приложений.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
