Перевод: Ransomware в облаке

Выводы из практического опыта

Предыстория

Недавно к нам обратилась одна компания после того, как она подверглась атаке ransomware в своей среде AWS. В этой статье мы хотим показать вам, что произошло и как мы смогли собрать картину на основе имеющихся записей.

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

Обзор атаки

Общая активность атаки сопоставлена с этапами MITRE ATT&CK, как показано на рисунке ниже:

Первоначальный доступ

Угроза смогла проникнуть в среду благодаря случайно раскрытым долгосрочным учетным данным. Первая вредоносная активность произошла за пределами 90-дневного периода хранения данных в CloudTrail. Однако на основе анализа последующих событий и анализа открытых источников мы смогли определить, что использовался определенный ключ доступа, который был публично раскрыт. К счастью, ключ доступа был для учетной записи, которая имела права только на определенный S3 bucket.

Разведка

После получения первоначального доступа угроза выполнила следующие действия для разведки.

Большинство действий не требуют пояснений и представляют собой попытки составить список других пользователей, buckets и любых доступных ключей доступа.

Более интересные вызовы связаны с квотами: события ListServiceQuotas и GetSendQuota относятся к службе AWS Simple Email Solution (SES). Мы видели, что SES представляет собой интересный вектор атаки для угроз, поскольку они могут использовать SES для рассылки спама и (spear)phishing-кампаний. Поскольку ключи доступа, которые использовались для выполнения этих вызовов, имели ограниченные разрешения, все эти вызовы привели к событиям AccessDenied, как показано в примере ниже.

В приведенном выше примере мы видим, что агент обработки также использует пакет AWS CLI на хосте Windows и использует командуaws s3 ls. (ссылка)

Персистенс

Угроза попыталась создать несколько дополнительных пользователей, что было зафиксировано в CloudTrail под именем события CreateUser. Были предприняты попытки создания следующих пользователей:

• root
• adminz
• deploy
• s3mize
• ses-smtp-user.<дата-время-создания>

Все вышеперечисленные действия снова были отклонены. Обратите внимание, что пользователь SES имеет стандартное соглашение об именовании, которое подскажет вам дату и время (попытки) создания. Также интересна попытка создания пользователя root, поскольку каждая учетная запись AWS по умолчанию имеет пользователя root. Создание пользователя IAM с именем root может быть способом остаться незамеченным. Нам не удалось найти никаких интересных сведений о других учетных записях пользователей в публичных репозиториях кода, но, возможно, кто-то знает больше.

Эксфильтрация

Хотя большинство попыток не увенчались успехом, используя ключ доступа, угроза получила полный доступ к S3 bucket. Угроза использовала этот доступ для эксфильтрации данных. Мы смогли подтвердить это с помощью биллинговой информации AWS, содержащей запись об операции GetObject, которая регистрируется при загрузке файла из S3 bucket. Биллинг AWS может быть полезным инструментом для обнаружения эксфильтрации данных, поскольку любые данные, покидающие AWS buckets, влекут за собой расходы на доставку, которые отражаются в биллинге.

Если вы хотите исследовать это самостоятельно, используйте следующий процесс:

• Перейдите в раздел AWS billing, затем выберите Cost & Usage Reports;
• Выберите ссылку Create a Usage Report в разделе AWS Usage Report и выберите период времени инцидента и службу S3;
• Откройте CSV-файл в каком-нибудь Excel и отсортируйте по столбцу UsageValue от большого к маленькому;
• Отфильтруйте по DataTransfer-Out или C3DataTransfer-Out Bytes в столбце UsageTypecolumn;
• Выполните поиск GetObjectOperation, который содержит загрузки файлов;
• Вы получите одну или несколько записей с агрегированными данными за период в 1 час, относящимися к исходящим передачам данных.

В случае утечки данных из bucket вы можете увидеть нечто подобное в биллинговом отчете:

В приведенном выше примере данные были переданы из региона ЕС из bucket с именем Invictus-test-bucket. Благодаря этой информации мы знаем период времени, в течение которого происходила передача, и количество переданных байтов. Биллинговая информация не показывает, куда была передана информация, но она может помочь выяснить, была ли произведена утечка данных, особенно если в CloudTrail нет никаких записей об этом.

Воздействие

После утечки данных угрожающий агент отключил версионность bucket, удалил данные из нескольких buckets и оставил записку с требованием выкупа.

Как уже упоминалось ранее, события данных не аудировались в CloudTrail для этой среды, поэтому мы не можем видеть отдельные события удаления, но данные из bucket были удалены. Также интересно посмотреть, что делал агент угрозы перед удалением файлов. В CloudTrail были зарегистрированы следующие события GetBucketVersioning и PutBucketVersioning.

Версионирование в Amazon S3 - это способ хранения нескольких вариантов объекта в одном bucket. Вы можете использовать функцию S3 Versioning для сохранения, извлечения и восстановления каждой версии каждого объекта, хранящегося в ваших bucket. С помощью версионирования можно легче восстанавливать данные как после непреднамеренных действий пользователя, так и после сбоев в работе приложений. Источник

Угроза использовала вызов GetBucketVersioning, чтобы определить, включено ли версионирование для bucket S3. Версионность позволила бы нашему клиенту легко восстановить данные, если бы они были удалены. В данном случае версионность была включена, следующим вызовом было изменение настроек версионности с помощью PutBucketVersioning, как показано на рисунке ниже.

Мы засекретили некоторые конфиденциальные данные, такие как bucket и пользователь, выполнивший действие. Важно знать, что поле userName будет содержать пользователя, ответственного за это действие, а bucketNamew будет содержать bucket, для которого была изменена версионность. В разделе Status мы видим, что версионирование было "приостановлено".

Заметка о вымогательстве

В пострадавших bucket была оставлена следующая заметка о вымогательстве.

События CloudTrail

В таблице ниже представлены события CloudTrail, с которыми мы столкнулись в данном случае. Вы можете использовать эти события для ручного оповещения в CloudWatch или настроить правила в SIEM. Мы добавили примечание об удобстве использования событий для обнаружения угроз на основе нашего опыта, в вашей среде он может быть иным.

https://gist.github.com/invictus-ir/2e892e19aad49eafe449fae91b2ff25b#file-cloudtrail-csv

Рекомендации

• Следующие рекомендации предназначены для предотвращения, обнаружения, реагирования и восстановления инцидента с ransomware в AWS.
• Включите отслеживание в CloudTrail для хранения данных в S3 bucket, что позволяет дольше сохранять данные;
• Включите CloudTrail для событий данных, это может генерировать много событий и влечет за собой дополнительные расходы, определите приоритеты на основе того, где хранятся наиболее важные данные;
• Ограничьте использование ключей долгосрочного доступа, по возможности используйте роли IAM. Например, используйте роль IAM для приложения, размещенного на EC2, которому необходимо хранить данные в S3 bucket, а не ключ доступа;
• Защищайте ключи доступа путем их регулярной ротации и мониторинга на предмет злоупотреблений, следуйте руководству по лучшей практике AWS;
• Включите версионирование bucket с удалением MFA, это ограничит возможность изменения настроек версионирования bucket, поскольку требуется MFA;
• Используйте AWS Backup для неизменяемых резервных копий, отличная статья AWS здесь.

Заключение

Ransomware - это угроза для всех организаций, а не только для локальных сред. Угрозы будут преследовать вас в облаке, а неправильную конфигурацию в облаке очень легко сделать с очень серьезными последствиями, как было показано в данном случае.

Индикаторы компрометации (IOCs)

Ниже приведен список признаков компрометации, с которыми мы столкнулись во время этой атаки.

https://gist.github.com/invictus-ir/db567088fe4333796a4354dde37712d3#file-iocs-csv

О компании Invictus Incident Response

Мы являемся компанией по реагированию на инциденты, работаем в облаке ❤️ и специализируемся на поддержке организаций, столкнувшихся с кибер-атакой. Мы помогаем нашим клиентам оставаться непобежденными!

🆘 Поддержка по вопросам реагирования на инциденты: cert@invictus-ir.com или посетите сайт https://www.invictus-ir.com/247.

📧 Вопросы и предложения направляйте нам по адресу info@invictus-ir.com.

Обновление 17-04-2023:

Внесено обновление в статью, так как мы неправильно указали, что невозможно создать пользователя с именем пользователя root, на самом деле это возможно. Из-за того, что это IAM пользователь с именем root, а не фактическая учетная запись root, которая присутствует в каждой учетной записи AWS. Спасибо, Натан!

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

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

• 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
• 🔥 @Ent_Translate - Инстаграм проекта