Palo Alto Unit 42 - Облачные угрозы.

Введение.

Без наличия эффективных политик управления идентификацией и доступом (IAM) организация не может рассчитывать на высокий уровень облачной безопасности в силу самой природы облаков: рассредоточенности, стремительного развития и динамических колебаний внутри организации.

С вызванным пандемией переходом на облачные платформы за последние несколько лет злоумышленникам стало легче, чем когда-либо, атаковать облачную инфраструктуру. Согласно отчету The 2022 State of Cloud Native Security Report, «во время пандемии наблюдалось значительное расширение облачных рабочих нагрузок: в целом, в среднем до 59% рабочих нагрузок размещалось в облаке, по сравнению с 46% в 2020 году. Кроме того, 69% организаций размещают более половины своих рабочих нагрузок в облаках, по сравнению с 31% в 2020 году». IAM - одна из самых важных, комплексных и подверженных ошибкам служб в облаке. Несмотря на то, что CSP создала многочисленные барьеры для проверки и верификации IAM-конфигураций, пользователи все еще могут непреднамеренно вносить небезопасные настройки в политики IAM. Зная об этом, злоумышленники используют неправильно сконфигурированные облачные ресурсы и быстро находят себе подходящие цели для атак.

Рис. 1. Процентное изменение объема облачных рабочих нагрузок с 2020 года

Если вы внимательно следите за исследованиями Unit 42 в области облачных угроз, то, возможно, помните, что не так давно мы подготовили отчет о важности IAM при построении стратегии безопасности облака. Сервис IAM снова занял центральное место в мире облачной безопасности - но на этот раз в еще большей степени, поскольку внедрение облачных технологий резко возросло и не планирует возвращаться к до-пандемическому уровню использования.

Как вы увидите, этот отчет построен вокруг вопросов «кто, что и как» IAM на счет злоумышленников в облаках. Эта триада вопросов имеет первостепенное значение для изучения и понимания того, как идентификационные данные используются и становятся объектом атак в облачных средах. Задавая вопросы «Кто атакует облака?», «Как они это делают?» и «На что они нацелены?», специалисты по безопасности смогут научиться эффективно создавать, контролировать и защищать свою облачную инфраструктуру.

Когда наши исследователи самостоятельно изучили эти вопросы, они не только обнаружили серьезные проблемы, связанные с чрезмерно разрешительными политиками IAM (например, почти 99% политик IAM являются чрезмерно разрешительными), но и смогли составить первый в отрасли «рейтинг» злоумышленников, атакующих облачные среды, который представляет собой живой набор досье на тех, кто именно организует большинство кибер-атак.

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

Джон Морелло Вице-президент, Prisma Cloud Palo Alto Networks.

Неправильные конфигурации по-прежнему находятся в центре почти всех известных инцидентов, связанных с безопасностью облачных сред. Однако если внимательно посмотреть «под капот», то во многих случаях это результат нескольких плохо написанных политик по управлению идентификацией и доступом. IAM - это самый важный и сложный компонент, который регулирует аутентификацию и авторизацию каждого ресурса в облачной среде. Проще говоря, IAM - это первая линия обороны большинства облачных сред. Для данного отчета исследователи Unit 42 проанализировали 680 000+ идентификационных данных 18 000 облачных учетных записей и более 200 различных организаций, их конфигурацию и характер использования. Исследование показало, что почти все облачные учетные записи имеют слишком широкие полномочия, и многим из них предоставлены разрешения, которые никогда не используются. Кроме того, 53% облачных учетных записей допускают использование слабых паролей, а 44% - повторное использование паролей. К сожалению злоумышленники, похоже, тоже знают об этом. Исследователи Unit 42 создали первый в отрасли индекс «Cloud Threat Actor (CTA) Index», который отражает тактики групп злоумышленников, нацеленных на облачную инфраструктуру. Важно отметить, что исследователи также обнаружили, что каждая хакерская группа нацелена на учетные данные IAM в облаке. В целом, результаты исследования показывают, что когда дело доходит до IAM, организациям трудно обеспечить надлежащее управление, что часто открывает злоумышленникам широкий доступ к облачным средам.

Облачные учетные записи имеют слишком широкие привилегии.

Исследователи Unit 42 отметили высокий процент слишком широких прав доступа идентификаторов в средах всех поставщиков облачных услуг. Существует большой разрыв между реальностью и принципом наименьших привилегий: ошеломляющие 99% пользователей, ролей, сервисов и ресурсов в облаке были наделены чрезмерными полномочиями, которые остались неиспользованными. При компрометации идентификационных данных атакующие могут использовать эти неиспользуемые разрешения для латерального перемещения и расширения ландшафта атаки. Удаление излишних прав может значительно снизить риски, которым подвергается каждый облачный ресурс, и минимизировать поверхность атаки для облачной среды в целом. Самое главное - правильное изменение политик разрешений может быть достигнуто с практически нулевыми затратами и без снижения производительности.

Настройка политик IAM поставщика облачных услуг.

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

Неправильно настроенный IAM открывает двери для облачных угроз.

Большинство известных инцидентов, связанных с безопасностью в облаках, начинаются с неправильной настройки IAM или утечки учетных данных (например, открытые системы хранения или жестко закодированные учетные данные). Наше исследование показало, что 65% известных инцидентов безопасности в облаках были вызваны неправильной конфигурацией. Этими векторами атак постоянно пытаются воспользоваться злоумышленники. Все выявленные нами субъекты облачных угроз (CTA) пытались получить учетные данные при компрометации сервера, контейнера или ноутбука. Утечка учетных данных с избыточными полномочиями может дать злоумышленникам ключ ко всей инфраструктуре. Исследователи уже выявили CTA, использующих учетные данные  самих облачных провайдеров, что свидетельствует о том, что они нацелены не только на взломанные сервера, но и на все инстансы в скомпрометированных облачных инфраструктурах.

Хакеры используют уникальные техники эскалации.

Из пяти групп злоумышленников, перечисленных в индексе Cloud Threat Actor Index, три CTA-группы выполняли специфические для контейнеров операции, включая обнаружение разрешений (на уровне пользователей и групп) и разведку ресурсов контейнеров. Две CTA-группы также были замечены как выполняющие операции по выходу из контейнера. Кроме того, все пять CTA-групп собирали учетные данные облачной или контейнерной платформы в рамках своих стандартных операционных процедур. Собирая учетные данные, могут переместиться в сторону самой платформы облачного сервиса, что позволит CTA-группам обойти изолированные инструменты мониторинга безопасности контейнеров или виртуальных ресурсов облака. Только платформа защиты приложений в облаке (CNAPP) с надлежащей конфигурацией способна выявлять и устранять такие угрозы.

Кто атакует облака?

Кто такие облачные злоумышленники?

Созданный Unit 42 индекс Cloud Threat Actor предназначен для помощи оперативным группам безопасности, охотникам за угрозами, исследователям и специалистам по разведке в отслеживании кибер-атак, нацеленных на облачную инфраструктуру. Содержащиеся в индексе CTA данны, соответствуют матрицам MITRE ATT&CK® для облачных и контейнерных сред, что дает специалистам по безопасности общую основу для общения и обсуждения тактик, методов и процедур, применяемых злоумышленниками. Индекс CTA также использует сервис Unit 42 ATOM для предоставления специалистам по безопасности всех известных индикаторов компрометации, используемых хакерами, упакованных в стандартный формат STIX/TAXII. Этот формат позволяет легко интегрировать его с инструментами и платформами облачной безопасности.

NIST 800-150 определяет злоумышленника как «лицо или группу, представляющие угрозу». Раньше злоумышленники компрометировали системы и устройства, физически расположенные в организации, но теперь организации размещают ту же инфраструктуру у поставщиков облачных услуг и на облачных контейнерных платформах. Это не только меняет методы интеграции и использовании этой инфраструктуры, но и то, как атакующие будут пытаться скомпрометировать эту инфраструктуру. Переход к облакам может затруднить защиту виртуализированной инфраструктуры, поскольку каждый экземпляр облака имеет возможность прямого публичного доступа. В результате группы, нацеленные на облачные инфраструктуры, разработали специальные тактики, методы и процедуры. Поэтому, по мнению команды Unit 42, жизненно важно классифицировать этот новый тип злоумышленников как субъектов облачных угроз (CTA).

Исследователи Unit 42 определили CTA как «лицо или группу, представляющую угрозу для организаций посредством направленного и устойчивого доступа к ресурсам облачной платформы, сервисам или встроенным метаданным». Исследователи обнаружили, что, хотя CTA в целом следуют тем же рабочим процессам, что и традиционные злоумышленники, таким как разведка с последующей первичной компрометацией, сохранение присутствия, латеральное перемещение, эскалация привилегий, уклонение и извлечение данных, CTA начали использовать принципиально иной набор тактик. Например - одновременное выполнение операций латерального перемещения и повышения привилегий, используя украденные у облачного провайдера ключи доступа и секретные ключи, взятые из доступных метаданных скомпрометированных контейнеров или виртуальных машин, или локальных файлов учетных данных.

Учитывая, что 99% ролей, групп и учетных записей IAM имеют привилегии, превышающие их целевое назначение, а также тот факт, что подавляющее большинство украденных доступов и секретных ключей будут иметь излишние права доступа, CTA могут напрямую изменять, создавать или удалять ресурсы облачной среды.

Возможности злоумышленников в облаках.

За последние годы CTA стали более зрелыми и изощренными. Они расширили свои технические возможности, пройдя эволюцию от простого доступа к открытым или неправильно настроенным контейнерам облачного хранилища или компрометации открытых и уязвимых облачных приложений, таких как виртуальные машины и контейнеры Redis, WebLogic и ThinkPHP. Сегодня CTA используют эксплойты нулевого дня, такие как Log4j, для получения важных метаданных облачной платформы, доступа к CSP и секретных ключей от взломанных облачных ресурсов. В следующих примерах мы рассмотрим две уникальные операции по атаке на облако, которые подчеркивают растущую изощренность хакерских групп в борьбе с защитой облачной инфраструктуры.

TeamTNT атакует облачные платформы и нативные облачные приложения.

TeamTNT является широко известной CTA, по крайней мере, с 17 августа 2020 года, когда был обнаружен «первый криптомайнинговый червь, крадущий учетные данные облачных провайдеров» В ходе последних операций по разведке облаков они активно атаковали сервисы и ресурсы облачных платформ. 30 ноября 2021 года группа объявила о своем намерении прекратить атаки, однако до 23 января 2022 года она все еще активно публиковала и ретвитила комментарии, причем большинство ее поздних твитов было посвящено политике Германии. За 28 месяцев активной деятельности TeamTNT операции выросли от сбора учетных данных CSP с одного скомпрометированного хоста до:

• Поддержки криптоджекинг-червя на Docker.
• Создания надежной CnC-инфраструктуры IRC-ботнета.
• Интеграции сбора данных из памяти с помощью mimipy и mimipeguins.
• Атак на облачные сервисы и ресурсы с использованием краденных учетных данных из взломанных облачных инстансов.

Кульминацией растущих операций TeamTNT стало создание репозитория Chimaera, который содержал функцию отслеживания, документирующую общее количество взломанных инстансов Docker, Kubernetes и Weave Scope. Наибольшее задокументированное количество скомпрометированных экземпляров составило 5 104 на 8 сентября 2021 года. На рисунке 2 показано, как участники TeamTNT собирали учетные данные CSP и приложений со взломанного облачного сервиса. Затем эти учетки можно было использовать для доступа к облачным ресурсам.

Рис. 2. Операции TeamTNT по сбору облачных учетных данных

Аккаунт TeamTNT (HildeGard) был очень активен в Twitter, злоумышленник постоянно насмехался над исследователями и высмеивал почти каждый отчет, в котором упоминались операции TeamTNT. Кроме того, другие группы CTA заметили успех TeamTNT и активно копировали и имитировали тактики TeamTNT, изменяя скрипты инициализации и даже пытаясь совместно компрометировать CnC-хост TeamTNT, чтобы лучше имитировать их операции. Успешное продвижение атак TeamTNT подчеркивает все более расширяющийся и углубляющийся характер облачного ландшафта угроз, на который должны обратить внимание как группы по обеспечению безопасности облачных сред, так и разработчики методологий оповещения и обнаружения продуктов для обеспечения безопасности облачных сред.

CTA использует Log4j для получения доступа к учетным данным облачных провайдеров.

Эксплуатация новых векторов атак уже давно является постоянным источником серьезных угроз. Однако потенциальное использование недавней уязвимости Log4j заслуживает особого внимания. 9 декабря 2021 года была обнаружена уязвимость удаленного выполнения кода (RCE) в Apache Log4j 2. Был выпущен публичный код доказательства концепции (PoC), и последующее расследование показало, что эксплуатация уязвимости не требует особых усилий. Появились сообщения о том, что инструмент с открытым исходным кодом на языке Go – interactsh - предназначенный для обнаружения уязвимостей, вызывающих внешнее взаимодействие - столкнулся с большим количеством запросов на создание инструментов для обнаружения Log4j. Многие из этих запросов были прямым результатом попыток злоумышленников найти уязвимые компьютерные системы.

Еще 10 декабря 2021 года сообщалось, что неизвестная группа CTA включила уязвимость Log4j в свой арсенал. Использование Log4j позволило операторам использовать возможности уклонения от обнаружения, что значительно усложнило выявление этих атак. Использование методов уклонения от защиты и обнаружения также указывает на то, что CTA объединяют методы эксплуатации с методами латерального перемещения и эскалации привилегий, что позволяет группе в большей степени использовать облачные инстансы и сигнализирует о том, что в операциях используется прямая атака на учетные данные IAM облака.

На рисунке 3 показана эксплуатация Log4j - первый этап. За сбором идентифицированных ключей доступа (шаг второй) следует разведка облачных сервисов, разрешенных политикой IAM, назначенной для украденного ключа (шаг третий).

Рис. 3. Операции TeamTNT по сбору облачных учетных данных

Роль IAM в операциях хакерских группировок.

Активный сбор данных и разведка облачных ресурсов с использованием украденных у CSP ключей доступа и секретных ключей представляет собой риск для облачных платформ, доступ к которым основан на идентификационных данных. Неправильная конфигурация политик идентификации пользователей, ролей или групп в облачном сервисе может значительно увеличить угрозу облачной архитектуре организации. В связи с активным сбором и непосредственным использованием секретных ключей доступа и ключей доступа к платформе облачных сервисов, осуществляемым TeamTNT и Kinsing, а также другими пока неизвестными группами, возникает вопрос: почему? В следующих трех примерах показано, как целевое использование ключей доступа CSP и секретных ключей может оказать разрушительное воздействие на организацию.

Идентификация: входной билет в вашу облачную инфраструктуру.

Облачные провайдеры предлагают детальный контроль над тем, как можно получить доступ к каждому облачному сервису или ресурсу. Количество доступных действий для каждого сервиса варьируется от 10 до более 500. В среднем, каждый сервис имеет 50 действий, которые могут быть выборочно предоставлены идентификатору. Каким бы гранулированным ни был контроль доступа в облаке, никто не может полностью охватить все действия в каждом облачном сервисе. В современной нативной облачной среде с сотнями или тысячами рабочих нагрузок каждая машинная (не-человеческая) идентификация, связанная с рабочими нагрузками, представляет риск для облачной инфраструктуры. С внедрением гибридной и мультиоблачной инфраструктуры количество учетных данных, необходимых для различных сервисов, значительно возрастает. Расширение границ безопасности делает контроль доступа к идентификационным данным более сложным, а также более критичным.

Рис. 4. Сервисы AWS, классифицированные по количеству доступных разрешений

Рис.5.Сервисы Azure, классифицированные по количеству доступных разрешений.

Факт: 99% облачных идентификаторов имеют излишние права доступа.

Мы считаем права чрезмерными, если учетной записи предоставлены разрешения, которые не использовались в течение последних 60 дней. Из 680 000 облачных пользователей, ролей и учетных записей сервисов, которые мы изучили, только 1% идентификаторов имеют разрешения в соответствии с принципом минимально необходимых привилегий.

Факт: В 62% организаций облачные ресурсы находятся в открытом доступе.

Публично открытый облачный ресурс позволяет любому человеку в интернете получить к нему доступ без аутентификации. Политики IAM, прикрепленные к облачным ресурсам определяют кто может получить доступ к ресурсам и какие действия можно выполнять на них. Истории об утечке данных из облачных хранилищ часто происходят из-за неправильно настроенных политик IAM, которые разрешают доступ к данным всем желающим. Существуют и легальные случаи выдачи подобных прав - например, хостинг веб-контента, который необходимо сделать общедоступным - но многие ресурсы становятся общедоступными непреднамеренно. Любой, кто знает конечную точку - обычно URL - может получить доступ к открытым ресурсам. Конфиденциальные данные могут быть прочитаны из открытых сервисов или баз данных, а вредоносный код может быть интегрирован в открытые функции или очереди.

Факт: Политики провайдеров предоставляют в 2,5 раза больше разрешений, чем политики, разработанные самим клиентом.

Каждый поставщик облачных сервисов предлагает набор встроенных политик разрешений, которые можно быстро применить к идентификатору, нуждающемуся в доступе к определенным облачным ресурсам. Эти политики помогают пользователям быстро запустить собственное облачное приложение, не имея дело с сотнями разрешений, необходимых для запуска рабочих нагрузок. Исследование, проведенное с использованием внутренних данных Prisma Cloud, показывает, что пользователи различных CSP используют больше политик, предоставленных провайдером, чем политик, разработанных клиентом. Однако, чтобы удовлетворить потребности различных приложений и пользователей, разрешения в провайдерских политиках должны быть широкими. Политика CSP может предоставлять пользователю сто разрешений, даже если ему нужно лишь десяток. Такие чрезмерные разрешения создают ненужные риски для облачной среды. Как показано на рисунке 6, 43% политик IAM в средах AWS были встроенными, управляемыми AWS, а 87% политик в средах Azure были встроенными ролями IAM, управляемыми Azure. Эти результаты показывают, что политики, управляемые CSP, являются предпочтительным выбором для большинства пользователей облачных сред.

Рис. 6. Распределение типов предоставленных политик

На рисунке 7 показано среднее количество разрешений, предоставляемых различными типами политик. AWS_CUSTOMER_MANAGED_POLICY и AZURE_BUILT_IN_ROLE - это политики, управляемые CSP от AWS и AZURE. AWS_CUSTOMER_MANAGED_POLICY, AWS_INLINE_POLICY и AZURE_CUSTOM_ROLE - это политики, созданные и управляемые пользователями. Наши данные показывают, что в среднем политики, управляемые CSP, предоставляют в 2,5 раза больше разрешений, чем политики, созданные клиентами. Обратите внимание, что CSP предоставляют пользователям опции для уменьшения разрешений в политиках CSP, но многие пользователи не используют эту возможность в полной мере для повышения уровня безопасности.

Рис. 7. Среднее количество разрешений, предоставляемых каждым типом политики

На рисунке 8 показан процент предоставленных разрешений, которые были фактически использованы за последние 60 дней. Мы сравниваем этот процент, или коэффициент использования, между различными типами политик. Наши данные показывают, что коэффициент использования политик, управляемых CSP, в 2,3 раза ниже, чем коэффициент использования политик, разработанных клиентами.

Рис. 8. Коэффициент использования разрешений для каждого типа политики

AWS	Azure
ReadOnlyAccess	Contributor
AWS­Lambda­VPC­Access­Execution­Role	Owner
Administrator­Access	Storage Blob Data Contributor
AWSSupportAccess	Billing Reader
AWSConfig­Rules­Execution­Role	Virtual Machine Contributor

Табл. 1. Топ-5 наиболее часто используемых управляемых CSP политик

Как видно из таблицы 1, политика AdministratorAccess в AWS и роль Owner в Azure являются двумя наиболее используемыми политиками. К сожалению, обе эти политики также предоставляют полный доступ к подключенным идентификаторам. Идентификаторы с ролью AdministratorAccess или Owner получают все разрешения на каждую облачную службу и ресурс. Эти доступы должны предоставляться клиентом с осторожностью, и только минимальное количество идентификаторов должно иметь такие привилегии.

Факт: Большинство (53%) облачных аккаунтов допускают использование слабых паролей IAM (<14 символов), а 44% аккаунтов допускают повторное использование паролей.

Слабые пароли уязвимы для перебора или атак с подстановкой учетных данных. Администраторы облачных сред должны внедрять политики, запрещающие пользователям создавать слабые пароли или повторно использовать старые пароли. Также лучше не хранить в облачных средах постоянные учетные данные, такие как пароли и ключи доступа. Если эти учетные данные случайно утекут, атакующие смогут получить прямой доступ к конфиденциальным ресурсам. Более безопасно использовать федеративные идентификаторы или SSO, чтобы сократить количество имен пользователей/паролей.

Основные действующие лица в атаках на облака.

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

В следующих таблицах вы найдете конкретные тактики, используемые самыми активными группами CTA.

Легенда таблиц:

Специфич­ные тактики для облачных сред

Тактики разведки и эксплуата­ции облачных учетных данных

Специфич­ные тактики для контейнер­ных сред

Тактики выхода за пределы контейне­ра

 

TeamTNT.

Группа TeamTnT стала первым известным CTA, активно использовавшим облачные файлы учетных данных на взломанных облачных сервисах. Их операции включают разведку сервисов облачных платформ, латеральное перемещение внутри кластеров Kubernetes, создание IRC-ботнетов и захват ресурсов скомпрометированных облачных рабочих нагрузок для майнинга криптовалюты Monero (XMR).

Ключевой вывод: TeamTNT считается наиболее изощренной группировкой в плане разведки идентификационных данных в облаке.

Табл. 2. Облачные тактики хакерской группы TeamTNT

WatchDog.

WatchDog - это CTA, ориентированный на облачные сервисы, который занимается криптоугоном, а также подбором учетных данных для платформ облачных сервисов. Впервые об их деятельности стало известно 27 января 2019 года. Они используют различные Go-скрипты, созданные на заказ, а также переработанные скрипты криптоугона других групп, включая TeamTNT. В настоящее время они рассматриваются как оппортунистическая хакерская группа, нацеленная на открытые облачные инстансы и приложения.

Ключевой вывод: воры, технически грамотные программисты, однако готовы пожертвовать мастерством ради легкого заработка.

Табл. 3. Облачные тактики хакерской группы WatchDog

Kinsing.

CTA, использующий имя Kinsing в качестве местоположения каталога для семейства вредоносных программ для добычи криптовалюты и вспомогательных файлов инициализации. Группа атакует открытые API Docker Daemon, используя вредоносные процессы на базе GoLang, запущенные в контейнерах Ubuntu, и начала расширять свою деятельность за пределы Docker-контейнеров, нацеливаясь на файлы учетных данных контейнеров и облачных сред, содержащиеся на скомпрометированных облачных рабочих нагрузках.

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

Табл. 4. Облачные тактики хакерской группы Kinsing

Rocke.

Группа Rocke - CTA, специализирующийся на операциях по распространению шифровальщиков и криптоугону в облачных средах. Эта группа известна тем, что использует вычислительную мощность взломанных систем на базе Linux, как правило, размещенных в облачной инфраструктуре. Rocke была первоначально идентифицирована в 2016 году и называлась Iron Group, они в основном фокусировались на атаках шифровальщиками с использованием своего набора инструментов Iron Ransomware и вредоносной программы IronStealer с бэкдором. В мае 2018 года они развили возможности ботнета с помощью своего набора инструментов XBash. В августе 2018 года группа снова усовершенствовала свои атаки, добавив возможность отключения и удаления облачных средств защиты из взломанных систем. В феврале 2019 года добавлен новый инструмент, позволяющий выполнять сценарии Proxy, Shell и Lua, в свой арсенал. В августе 2019 года сообщалось, что Rocke скомпрометировала 28,1% организаций с облачной инфраструктурой.

Ключевой вывод: Старожилы, медленно наращивающие методы разведки на облачных конечных точках, еще не добрались до контейнеров.

Табл. 5. Облачные тактики хакерской группы Rocke

8220.

8220 - это хакерская группа, ориентированная на облачные вычисления и действующая как минимум с 2017 года. Инструменты, обычно используемые в их операциях - PwnRig или DBUsed - являются адаптированными вариантами программного обеспечения для майнинга XMRig Monero. Считается, что майнинговая группа 8220 возникла из «форка» группы Rocke на GitHub. 8220 повысила эффективность своих майнинговых операций с помощью кражи учетных данных на платформе облачных сервисов посредством использования эксплойта Log4j, начиная с декабря 2021 года.

Ключевой вывод: «двоюродный брат» старожила (Rocke), внедряющий контейнеры в свой набор целей, возвращается из отставки все быстрее.

Табл. 6. Облачные тактики хакерской группы 8220

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

Потенциальные будущие разработки атакующих.

Учитывая недавний рост кибер-активности, связанный со специальной операцией России на Украине, важно отметить, что российские хакеры исторически использовали облачную инфраструктуру для размещения вредоносного контента для своих наступательных операций. Есть также свидетельства того, что эти группы специально нацелились на облачную инфраструктуру. Следующие три примера показывают, как облачная инфраструктура использовалась или была мишенью в операциях, проводимых хакерскими группами, которые некоторые связывают с государственными службами. Передовые хакерские группировки (APT) всегда использовали кражу учетных данных из взломанных систем, и облачные среды не являются исключением.

APT 28 (Fancy Bear).

Использовала инфраструктуру Kubernetes для проведения атак методом брутфорса.

APT 29 (Cozy Bear).

Атака SolarWinds в декабре 2020 года, первоначально начатая с использованием SolarStorm, была связана с APT 29, также известной как Cozy Bear или Nobelium. Хакеры APT 29 смогли скомпрометировать по меньшей мере 140 организаций, внедрив бэкдор в подписанный хотфикс SolarWinds Orion. Хотя платформа Solarwinds Orion не считается облачным приложением, существуют легальные образы облачных контейнеров, которые позволяют организациям создавать приложения в динамической облачной среде. Атаки на такие приложения представляют собой новый подход в мире кибер-угроз.

APT 41 (Gadolinium).

Использовала облачную платформу Microsoft Azure для размещения CnC-инфраструктуры во время своих операций. Использование легитимной платформы для размещения вредоносных ресурсов может позволить хакерам сделать свою инфраструктуру более легитимной на вид. Если взломанная организация увидит, что ее виртуальные машины Azure взаимодействуют с другим ресурсом Azure,  эти схемы взаимодействия легко принять за легитимные, даже если вредоносные действия будут обнаружены и выданы предупреждения.

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

Заключение и рекомендации.

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

Для защиты облачных сред организациям следует использовать следующие методики:

1. Интеграция CNAPP Suite: Мониторинг и оповещение о событиях безопасности в рамках единой платформы, включающей поддержку приложений во время выполнения, а также интеграцию безопасности в рабочие процессы разработки, имеет важное значение для обеспечения комплексной безопасности. По данным Gartner платформы защиты облачных нативных приложений (CNAPP) - это интегрированный набор возможностей безопасности и соответствия нормативным требованиям, предназначенный для обеспечения безопасности и защиты облачных нативных приложений в процессе разработки и функционирования. CNAPP объединяют многие ранее разрозненные возможности, включая:

• Сканирование артефактов разработки, включая контейнеры.
• Управление облачной структурой безопасности.
• Сканирование IaC.
• Управление правами в облачной инфраструктуре.
• Платформа защиты облачных рабочих нагрузок во время выполнения.

Учитывая уровень доступа, который могут получить CTA после компрометации облачной среды, атакующий может успешно обойти изолированный набор средств облачной безопасности, таких как механизмы мониторинга и обнаружения Cloud Workload Protection (CWP), получив доступ к самой облачной платформе. Организация, использующая только CWP, не сможет обнаружить события на уровне облачной платформы, которые можно было бы обнаружить с помощью управления положением безопасности облака (CSPM). Аналогично, если организация использует только CSPM, она не сможет обнаружить события, происходящие на отдельных рабочих станциях. Только при использовании набора инструментов в рамках CNAPP можно обнаружить CTA, перемещающего свой доступ непосредственно из скомпрометированного облачного экземпляра на саму платформу облачного сервиса. Исследователи рекомендуют использовать набор инструментов CNAPP, включающий как инструмент CSPM, так и инструмент CWP, чтобы поддерживать работу облачных контейнеров и консоли.

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

• Минимизируйте использование учетных данных администратора. Чем реже предоставляются или используются учетные данные администратора, тем меньше вероятность их взлома.
• Минимизируйте использование долгосрочных учетных данных, таких как пароли пользователя, ключи доступа и ключи учетных записей сервисов.
• Обеспечьте применение многофакторной аутентификации для учетных записей, изменяющих доступ к критичным для бизнеса действиям - таким как удаление баз данных, удаление бекапов и обновление ключей шифрования.
• Настройте политику надежности паролей. Национальный институт стандартов и технологий (NIST) рекомендует минимальную длину пароля в восемь символов и отказ от правил композиции символов, поскольку они болезненны для пользователей.
• Используйте федеративное управление идентификацией (FIM) для централизованного управления контролем доступа.
• Предоставляйте каждой учетной записи только те разрешения, которые необходимы для работы. (Принцип наименьших привилегий). Постоянно проводите аудит всех идентификационных данных в облачной среде с помощью таких инструментов, как AirIAM и Cloud Infrastructure Entitlement Management (CIEM).
• Внедрите мониторинг IAM. Все основные облачные провайдеры имеют сервисы, которые отслеживают использование IAM. Эти сервисы помогают выявить аномальные действия, такие как атаки методом перебора и запись логов с нераспознанных разделов или локаций.
• Автоматически устраняйте чрезмерные привилегии. Аудит прав доступа не должен проводиться вручную, поскольку рабочие нагрузки в облачных средах быстро и часто меняются.

3. Повышение автоматизации безопасности:  В отчете «The State of Cloud Native Security Report 2022» компании Palo Alto Networks показано, что организации с высоким уровнем автоматизации безопасности в два раза чаще имеют надежную защиту. Поскольку внедрение облачных вычислений продолжает расти, команды безопасности должны быть в состоянии успевать за уязвимостями облачных вычислений в масштабах компании. Внедрение автоматизации везде, где это возможно, позволяет значительно сократить количество ручных операций, обычно выполняемых для решения проблем безопасности. Кроме того, команды безопасности могут быстрее устранять больше рисков безопасности, как при разработке, так и при эксплуатации, а также на всех промежуточных этапах жизненного цикла приложений.

Готовы ли вы выявить угрозы в вашем облаке?

Prisma® Cloud анализирует более 10 миллиардов событий каждый месяц. Благодаря проактивному обнаружению неверных конфигураций безопасности и проблем соответствия нормативным требованиям, а также запуску автоматизированных рабочих процессов, Prisma Cloud помогает непрерывно и безопасно удовлетворять требования динамичных облачных архитектур. Чтобы начать работу с Prisma Cloud, запросите бесплатную пробную версию уже сегодня.

Методология исследования.

В период с января 2022 года по март 2022 года исследователи команды Unit 42 отслеживали и анализировали конфигурации IAM и действия по использованию всех клиентов Prisma Cloud. Данные содержат 680 000 идентификационных данных в 18 000 облачных аккаунтах 200 различных организаций, что позволяет оценить текущее состояние безопасности IAM-систем. Используя уникальные возможности платформы Cloud Infrastructure Entitlement Management, исследователи смогли рассчитать эффективные разрешения для каждой облачной учетной записи, просмотреть историю использования каждого разрешения и выявить ошибки в политиках разрешений. Имея представление об истории использования каждого эффективного разрешения, мы можем узнать, как каждое разрешение использовалось в каждой идентификации. Все показатели в этом отчете были получены путем агрегирования конфигураций IAM и журналов идентификации сотен различных организаций.

Исследователи также изучили сотни образцов вредоносного ПО в облачных средах, подробно описав действия атакующих в рамках нескольких кампаний с применением различных наборов инструментов. Исследователи использовали продукты Palo Alto Network для помощи в сборе, анализе и сборе метаданных для каждого из образцов вредоносных программ, применяемых CTA.

Palo Alto Networks Prisma Cloud.

Данные о тенденциях Prisma® Cloud используют многочисленные источники информации об угрозах. Исследователи Unit 42 использовали собственные источники данных для сбора информации об оповещениях и событиях в организации. Данные были анонимизированы, а затем проанализированы и сопоставлены с результатами предыдущих аналитических отчетов по облачным угрозам для получения информации о трендах.

Palo Alto Networks WildFire.

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

Palo Alto Networks AutoFocus.

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

Об авторах.

Prisma Cloud.

Prisma® Cloud - это комплексная платформа безопасности облачных приложений, данных и всего стека облачных технологий на протяжении всего жизненного цикла разработки, а также в гибридных и мультиоблачных средах. Интегрированный подход Prisma Cloud позволяет командам по обеспечению безопасности и DevOps оставаться гибкими, эффективно сотрудничать и ускорять разработку и безопасное развертывание облачных приложений.

Модуль управления правами в облачной инфраструктуре (CIEM) Prisma Cloud предоставляет пользователям широкую видимость эффективных разрешений, постоянно отслеживает многооблачные среды на предмет рискованных и неиспользуемых прав и автоматически дает рекомендации по обеспечению принципа наименьших привилегий. Пользователи получают простую, но мощную информацию о чистых эффективных разрешениях для каждой роли, включая разрешения, связанные с IdP-провайдером - все это легко интегрируется в Prisma Cloud.

Unit 42.

Команда Unit 42 объединяет наших всемирно известных исследователей угроз с элитной командой консультантов по безопасности для создания организации, ориентированной на разведку и реагирование на угрозы. Команда Unit 42 Threat Intelligence проводит исследования угроз, которые позволяют командам безопасности понять намерения атакующих и их атрибуцию, а также усилить защиту, предлагаемую нашими продуктами и сервисами, чтобы остановить передовые атаки. По мере эскалации угроз подразделение Unit 42 готово проконсультировать клиентов о последних рисках, оценить их готовность и помочь им восстановиться, когда произойдет худшее. Команда Unit 42 Security Consulting выступает в качестве надежного партнера, обладающего самыми современными знаниями в области киберрисков и возможностями реагирования на инциденты, помогая клиентам сосредоточиться на своем бизнесе до, во время и после взлома.

Авторы.

• Джей Чен, главный исследователь, отдел безопасности публичных облаков, Palo Alto Networks.
• Натаниэль «Кью» Квист, главный исследователь, отдел безопасности публичных облаков, Palo Alto Networks.

Соавторы.

Этот отчет был бы невозможен без огромной работы и усилий всей команды Palo Alto Networks. Следующие люди оказали значительную помощь в его создании:

• Редактура: Эйми Савран, Эрика Наоне, Грейс Чунг, Келли Кейн.
• Проверка данных: Бар Шварц, Большая команда Prisma Cloud IAM.
• Проверка достоверности информации об угрозах: группа ARES команды Unit 42.
• Первоначальное видение отчета: Мэтью Чиодию.

Источник: https://www.paloaltonetworks.com/resources/research/unit-42-cloud-threat-report-volume-6