Как следить за киберзлоумышленником: топ-3 пути использования Red Team с 2024 года

Незащищенные учетные данные остаются популярной проблемой. Красной команде (и противникам) гораздо легче проникнуть в дом, когда ключи от него лежат под ковриком. Вот причины, по которым эта проблема все еще существует:

• Команды не имеют доступа к специальному решению для управления паролями, поэтому они используют общую электронную таблицу для общих учетных данных (например, общую внешнюю учетную запись для выставления счетов).
• Администраторам необходимо регулярно выполнять одну и ту же задачу на разных хостах, поэтому они хранят сценарии PowerShell в общем репозитории, откуда их можно быстро извлечь и запустить. Сценарии содержат их строго закодированные учетные данные вместо того, чтобы запрашивать учетные данные.
• Резервные копии развернутого кода, в том числе внутренних веб-серверов, хранятся в общей папке команды разработчиков, к которой имеет доступ любой авторизованный пользователь. Код использует жестко закодированные значения для учетных данных или ключей, а не переменные значения, раскрывая секреты открытым текстом.
• Отдельные пользователи создают резервные копии своих папок «Рабочий стол» или «Документы» на общем диске и имеют неприятную привычку добавлять к ним файл «passwords.txt» или «reminders.docx».

SharePoint – это одно из тех мест, где учетные данные могут случайно попасть в общий доступ. Если компания использует Microsoft Teams, то файлы, к которым предоставляется совместный доступ в «каналах» (а не в индивидуальных прямых сообщениях), могут попасть в доступ ко всей команде из-за их связанной природы. Их можно найти на вкладке «Файлы» в папке «Вложения». Кто-то может поделиться конфиденциальным файлом, содержащим учетные данные, думая, что он ограничен определенной группой в приложении Teams, но на самом деле этот файл может быть доступен любому в SharePoint если не заблокирован должным образом.

Так где были найдены эти учетные данные? Как можно догадаться из приведенных выше примеров, главными источниками в этом году были SharePoint, сетевые файловые ресурсы и репозитории кода. Инструменты для управления процессами, такие как Jira, также получили почетное упоминание, поскольку люди (правильно) обновляли вопросы для управления проектами, но включали конфигурации или пароли как часть обновлений. Другие места, где часто скрываются учетные данные, включают истории развертывания (Azure, Jenkins и т. Д.) И книги запуска (Azure, Terraform, Ansible и т. Д.).

Потенциальные меры по снижению незащищенности учетных данных

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

• Внедрение подходящего (и безопасного) решения для управления паролями
• Выполнение регулярного сканирования сетевых ресурсов и SharePoint с помощью таких инструментов, как Snaffler
• Проведение обучения пользователей, особенно разработчиков и ИТ-персонала, которые имеют тенденцию писать скрипты или код со встроенными учетными данными служебных учетных записей
• Использование функции маскировки секретов в автоматизации (например, репозитории в Ansible)
• Обзор кода перед фиксацией и дополнение этого обзора с помощью поисковых систем репозиториев, таких как TruffleHog

Эти шаги не являются полным решением незащищенности, поскольку учетные данные не должны храниться в виде открытого текста, необходимо пересмотреть настройки доступа к общим сетевым ресурсам. Большие встроенные группы, такие как Authenticated Users, часто имеют доступ к большему количеству ресурсов, чем предполагалось, поскольку использование ресурсов со временем меняется или они быстро настраиваются. Инструмент Snaffler также можно использовать для обнаружения общих ресурсов, не копаясь в файлах для более быстрого обнаружения.

Те, кто злоупотребляет AD CS, почти мгновенно сожалеют об этом, поскольку пути атаки, часто называемые короткими именами пронумерованных вариантов эскалации (ESC1, ESC4 и т. Д.), Могут привести к немедленной компрометации домена при определенных обстоятельствах. И это, к сожалению, случается очень часто.

Как следует из названия, AD CS управляет добавлением криптографических сертификатов и инфраструктуры открытых ключей (PKI) в среду Active Directory. В сочетании с криптографией открытых ключей для начальной аутентификации (PKINIT) эти сертификаты можно использовать с Kerberos для аутентификации в качестве основного пользователя без пароля.

Даже если PKINIT не включен в среде, сертификаты все равно часто можно использовать для аутентификации в других протоколах, таких как Lightweight Directory Access Protocol (LDAP) через TLS. Но это может привести к вторичным атакам, таким как настройка ограниченного делегирования на основе ресурсов (Resource-based Constrained Delegation).

Из всех путей эскалации, которые CrowdStrike наблюдал в своих операциях, ESC1, ESC4 и ESC8 были самыми распространенными злоумышленниками.

ESC1

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

• Большие встроенные группы (обычно пользователи домена, компьютеры домена или аутентифицированные пользователи) могут регистрироваться с помощью шаблона и центра сертификации
• Одобрение менеджером отключено, хотя это не является решающим фактором при наличии небольшой социальной инженерии или везения (например, невнимательные менеджеры)
• Желаемый шаблон включен
• Расширенное использование ключа (Extended Key Usage, EKU) установлено на значение, которое позволяет определенную форму аутентификации Kerberos (например, аутентификацию клиента), EKU указывает «Любая цель», или EKU вообще отсутствует
• Шаблон сертификата имеет отметку ENROLLEE_SUPPLIES_SUBJECT, который позволяет запрашивающему указать дополнительного параметр при запросе сертификата

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

Если использовать инструмент Certipy с открытым исходным кодом для сбора данных AD CS, шаблон, показанный ниже, будет уязвим для ESC1.

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

Смягчение последствий: Чтобы защититься от ESC1, необходимо убедиться, что шаблоны сертификатов не содержат флажка ENROLLEE_SUPPLIES_SUBJECT. Если для других развернутых технологий абсолютно необходимо, чтобы другие субъекты предоставляли альтернативное имя субъекта, надо убедиться, что разрешения на регистрацию заблокированы только для других высокопривилегированных групп, таких как администраторы доменов и контроллеры доменов. Если это также не является возможным, стоит рассмотреть возможность требовать одобрения запросов менеджером, чтобы выявить нелегитимное использование.

Также, целесообразно пересмотреть шаблоны, в которых указана «Любая цель» или вообще отсутствует EKU. Как правило, «Любая цель» и отсутствующие EKU должны быть скорректированы таким образом, чтобы поддерживать только ограниченный набор приложений, необходимых для этого сертификата.

ESC4

Шаблоны сертификатов являются объектами Active Directory, как и все остальное в этой среде, и ESC4 злоупотребляет неправильно настроенными записями контроля доступа (ACE) в этих шаблонах. Имея возможность изменять шаблон, злоумышленник может намеренно сделать его уязвимым, используя настройки, описанные выше для ESC1.

При повторном использовании Certipy приведенный ниже шаблон будет уязвимым к ESC4.

Смягчение последствий: ESC4 использует более традиционный подход. Поскольку владельцы шаблонов/авторы смогут повысить статус до администратора домена, модифицировав шаблон, нужно пересмотреть разрешения на объекты шаблона и ограничить права собственности и другие разрешения на запись до администраторов домена, где это возможно. Такие инструменты, как Certipy, могут помочь идентифицировать этих владельцев, так же как и традиционные инструменты исследования Active Directory, такие как BloodHound.

ESC8

Вместо того, чтобы злоупотреблять шаблоном, ESC8 злоупотребляет возможностью веб-регистрации на самих центрах сертификации. Служба веб-регистрации в ЦС позволяет пользователям выполнять задачи с сертификатами в веб-интерфейсе пользователя ЦС, обращаясь к конечной точке http(s)://ca-name.example.com/certsrv.

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

Подписи SMB и LDAP являются вариантами защиты, которые могут предотвратить ретрансляционные атаки NTLM на соответствующие службы, но ESC8 нацелен на службу HTTP, которая не защищена этими средствами контроля.

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

Смягчение последствий: Для ESC8 стоит рассмотреть возможность полного удаления службы веб-регистрации. Если эта служба все еще нужна, Microsoft предоставила дополнительную защиту с помощью расширенной защиты для аутентификации (EPA). Также необходимо требовать HTTPS для доступа к конечной точке веб-регистрации, чтобы принудительно создать туннель TLS, а также, чтобы ограничить передачу учетных данных, можно отключить аутентификацию NTLM для информационных служб Интернета (IIS) на центре сертификации. Для получения дополнительной информации об этих шагах защиты необходимо обратиться к документации Microsoft.

Протокол аутентификации NTLM использует поток вызовов и ответов, в котором хэш пароля учетной записи используется для шифрования числа, которое используется только один раз («nonce»). Клиент получает одноразовый номер, шифрует его с помощью хэша пароля учетной записи (хэш NT) и возвращает в службу. Наконец, служба отправляет имя пользователя, одноразовый номер и зашифрованный ответ клиента на контроллер домена. Контроллер домена получает хэш пароля для предоставленного имени пользователя, шифрует сам nonce и сравнивает его с зашифрованным значением службы. Если все совпадает, учетная запись успешно прошла аутентификацию.

С помощью ретрансляционной атаки NTLM злоумышленник оказывается в центре процесса, где он может перехватить и/или намеренно вынудить аутентификацию, а затем перенаправить ее в нужное место. Как правило, для этого нужен доступ к порту 445 и ряд туннелей. Порт 445 автоматически связывается учетной записью SYSTEM при запуске для хостов Windows, что делает локальный административный доступ обязательным условием для большинства релейных атак NTLM в среде с интенсивным использованием Windows.

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

Чрезмерные разрешения в Active Directory являются еще одной вечной проблемой, которую может быть трудно полностью устранить в сложных средах из-за большого количества движущихся частей. Эта проблема сложна еще и потому, что она часто возникает по разным причинам, таким как недостаточное количество политик или их несоблюдение, а также постоянная борьба между целесообразностью и безопасностью.

CrowdStrike Professional Services Red Team часто сталкивается с неправильно настроенными, забытыми или объектами с чрезмерными разрешениями, которые дают нам возможность перепрыгивать, пропускать и перепрыгивать к контролю над средой.

Учетные записи с чрезмерным разрешением

Эта ошибка появлялась в большинстве сред, которые были протестированы командой CrowdStrike. Служебные учетные записи, которые являются членами администраторов домена или эквивалентных групп, являются одной из самых больших проблем. А проблема заключается в том, что служебные учетные записи часто слишком распространены в среде для выполнения своей работы. Кроме того, они составляют наибольшую долю учетных данных, которые были найдены в незащищенных местах. Даже если их нельзя найти в файлообменнике, то учетные данные потенциально можно получить через Kerberoasting или из реестра хоста – если учетная запись работает как служба на этом хосте.

Однако опасными могут быть не только права администрирования домена – мы можем использовать служебные учетные записи как ступеньку к статусу локального администратора на серверах, которые содержат другие пути.

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

Недостаточная многоуровневость учетных записей

Не вдаваясь в подробности, активы в сети часто можно представить в виде уровней, где уровень 0 — это сам домен и лица, которые могут работать с ним (например, администраторы домена и контроллеры домена). Уровень 1 часто включает большинство других серверов и их администраторов, уровень 2 – это, как правило, администраторы службы поддержки и вспомогательная инфраструктура, а уровень 3 охватывает все остальное.

Хотя многие компании все лучше отделяют учетные записи администраторов от обычных учетных записей пользователей, CrowdStrike Professional Services Red Team часто обнаруживает, что для администраторов не существует дальнейшего разделения на уровни, особенно между уровнями 0 и 1/2. Это означает, что учетные записи с полным контролем над доменом входят на рабочие станции и файловые серверы, где их учетные данные потенциально доступны в LSASS, или оставляют устаревшие RDP-сессии, которые могут быть перехвачены. Это сложнее и более заметно при эксплуатации, но все же это является проблемой.

Неправильно настроенные и забытые права контроля доступа

Еще одна распространенная находка Red Team – это группа пользователей домена, которая имеет такие права доступа, как AllExtendedRights, WriteDacl или GenericAll на нескольких компьютерных объектах, а иногда даже на других пользователях.

Что еще хуже, компьютерные объекты могут не соответствовать серверу, который доступен через сеть. Но если объект не был удален из Active Directory, злоумышленники могут злоупотреблять этими разрешениями, чтобы завладеть им. Это может привести к последующим атакам для получения доступа к чему-то другому или регистрации в AD CS, таким как цепной контроль доступа.

Два самых распространенных пути для неправильно настроенных ACE на компьютерных объектах — это теневые учетные данные и ограниченное делегирование на основе ресурсов (RBCD), которыми можно злоупотреблять, когда пользователи домена имеют права AllExtendedRights, GenericAll, GenericWrite, WriteDacl или Owner на компьютерном объекте.

Первый вариант, теневые учетные данные, требует одного из двух сценариев: 1) PKINIT включен для аутентификации или 2) наличие TLS с LDAP. Злоумышленник записывает новые учетные данные в атрибут msDS-KeyCredentialLink объекта, добавляя механизм беспарольной аутентификации для этого объекта.

RBCD немного сложнее. Протокол аутентификации Kerberos использует билеты для получения доступа к службам во всей среде. Если пользователь хочет получить доступ к веб-серверу, он получает служебный билет для HTTP-сервиса и отправляет его. Однако, если этой службе нужен доступ к внутренней базе данных, чтобы получить информацию для пользователя, предоставленный служебный билет не покрывает этого. Таким образом, возникает проблема двойного перехода.

Первоначально Microsoft решила эту проблему, введя неограниченное делегирование. При такой настройке пользователь отправляет переадресованный билет выдачи билетов (TGT) в дополнение к служебному билету. Затем веб-сервер (в этом примере) мог запросить служебный билет от имени пользователя, чтобы получить доступ к внутренней базе данных. Но в чем проблема? TGT – это то же самое, что иметь пароль пользователя для всего, что использует аутентификацию Kerberos. Поэтому скомпрометированный сервер приведет к компрометации всех пользователей, получающих к нему доступ.

Далее – ограниченное делегирование. Microsoft добавила Service for User to Self (S4U2Self) и Service for User to Proxy (S4U2Proxy). Теперь служба может запрашивать билет на обслуживание для любого пользователя в среде либо для себя (S4U2Self), либо для определенного списка служб (S4U2Proxy). Этот список состоит из имен объектов служб (SPN), которые хранятся в атрибуте msDS-AllowedToDelegateTo объекта. Этот вариант лучше, но все еще имеет свои недостатки.

И, наконец, RBCD. С RBCD парадигма меняется: back-end имеет список сервисов, которые могут ему делегировать, и эти сервисы хранятся как SPN в атрибуте msDS-AllowedToActOnBehalfOfOtherIdentity. Front-end-сервис все еще использует S4U2Proxy и все еще может запрашивать служебный билет от имени любого незащищенного пользователя, но только если back-end-сервис позволяет это делать. Это шаг вперед, потому что теперь цель (back-end) должна быть скомпрометирована первой.

Введите неправильно настроенные ACE. Используя что-то вроде GenericWrite над другим объектом, в этом случае главным образом учетными записями компьютера, учетная запись может изменить атрибут msDS-AllowedToActOnBehalfOfOtherIdentity, чтобы добавить SPN, которым она управляет. Этот SPN может возникнуть в результате другой атаки (например, Kerberoasting), с другого контролируемого компьютера или из-за злоупотребления квотой учетной записи компьютера по умолчанию, которая позволяет любому пользователю добавлять 10 объектов компьютера без вопросов. Эти компьютерные объекты всегда поставляются с SPN.

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

Потенциальные средства смягчения чрезмерных разрешений

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

Ключевые области, на которые стоит обратить внимание:

• GenericAll, GenericWrite, AllExtendedRights и WriteDacl для непривилегированных пользователей или групп над другим объектом: нормальных причин немного, поэтому стоит пересмотреть эти права для непривилегированных пользователей
• Несколько уровней вложенных групп, которые могут привести к непреднамеренным разрешениям
• Объекты Active Directory: в частности компьютеры, которые больше не существуют в сети, но не были полностью удалены из Active Directory

Еще один нетехнический подход заключается в том, чтобы иметь жесткие политики и процедуры для создания и уничтожения объектов Active Directory. Это гарантирует, что для объектов не будет настроен шаблон по умолчанию, включая разрешения, которые им не нужны, или они не останутся позади при выводе из эксплуатации. Учетные записи службы администратора домена нельзя предоставлять без законной необходимости.

С технической стороны необходимо хорошо использовать встроенную группу защищенных пользователей в Active Directory. Это поможет предотвратить делегирование этих пользователей, как во время атаки RBCD, и кэширование их учетных данных, где бы они ни входили. Такой подход будет особенно полезным для администраторов домена и любых конфиденциальных администраторов уровня 1. Но нужно помнить, что это может повлиять на функциональность, поэтому следует убедиться, что все последствия понятны, прежде чем применять это. Также возможно отдельно обозначить учетные записи как «конфиденциальные», но такой вариант будет применять только защиту делегирования.

Хотя специалисты регулярно сталкиваются (и злоупотребляют) другими вещами, такими как слабая реализация SCCM или отсутствие подписи LDAP, устранение этих трех проблем значительно улучшит общее состояние безопасности корпоративной сети и заставит Red Team (или настоящих злоумышленников) сидеть прямо и напрячься, чтобы копать глубже.