Пожалуйста, обратите внимание, что пользователь заблокирован
Automated Derivative Administrator Search
Intro
Эскалация домена Active Directory является важной частью большинства пентестеров. Хотя получение прав администратора домена / предприятия не является конечной целью оценки, это часто делает достижение целей тестирования намного проще.
Типичный процесс эскалации домена вращается вокруг возможности собирать простые учетные данные или токены пользователей, зарегистрированных в системах, которые у вас есть, и могут привести к повышенные привилегий, - способность, наиболее известная для mimikatz. Найдите администратора домена, зарегистрированного в системе, на которой у вас есть права администратора, с помощью этой системы и получения учетных данных администратора.
Но что, если вы находитесь в более сложной ситуации, когда у вас сразу нет прав администратора в системе, где находится администратор домена? Вы можете быть одном, двух, трёх или более шагах от возможности компрометации администратора домена, и вам нужно будет сделать довольно небольшой анализа (или просто методом проб и ошибок), чтобы найти вектор.
Давайте посмотрим на гипотетическую ситуацию: мы получили права пользователя на уровне домена в среде с сотнями тысяч рабочих станций серверов, подключенных к лесу Active Directory с несколькими доменами с разным доверием. Наша цель состояла в том, чтобы повысить наши права до Администратора предприятия. К счастью, топология сети была практически плоской; Тем не менее, клиент применял чрезвычайно строгие методы с наименьшими привилегиями. После борьбы, чтобы найти средство для повышения наших прав, мы, наконец, смогли скомпрометировать учетную запись администратора сервера, которую мы будем называть «Steve-Admin».
«Steve-Admin» был локальным администратором на серверах, в которых он должен был быть администратором, и нигде больше. Мы возьмем этот список серверов и узнаем, какие пользователи были зарегистрированы на этих серверах. Однако в этот момент нам нужно было решить, с какими пользователями мы будем работать идти. Ни один из зарегистрированных пользователей, с которыми мы могли бы что-то сделать не были администраторами в блоках, где были зарегистрированы Domain Admins. Нам нужно было выбрать учетную запись, найти системы, на которых были права администратора, перечислить пользователей на этих машинах и продолжить, пока мы не найдем путь, который сработал. В среде с сотнями тысяч компьютеров и пользователей этот процесс может занять несколько дней или даже недель.
В этом посте я объясню и продемонстрирую доказательство концепции автоматизации этого процесса.
Предварительная работа
Это доказательство концепции в значительной степени зависит от существующих инструментов и концепций, любезно предоставленных публикой некоторыми очень умными, очень трудолюбивыми людьми:
Представьте себе, что вместо того, чтобы искать путь от «Steve-Admin» до Enterprise Admin, мы пытались найти путь из Сиэтла, штат Вашингтон, в Портленд, штат Орегон. Как человек, вы можете взглянуть на карту и довольно легко определить, что Interstate 5 доставит вас туда. Компьютер может найти путь между Сиэтлом и Портлендом (и между «Steve-Admin» и Enterprise Admin, если таковой существует)
Графический дизайн
Доказательство концепции, которую я придумал для этой проблемы, было разработано с одной целью - автоматизировать процесс поиска кратчайшего пути к компрометации администратора домена, не записывая ничего на диск или не требуя автономного анализа. Таким образом, дизайн этого графика может оказаться неприемлемым для других
Каждый пользователь и компьютер являются вершинами. Оранжевые цвета говорят нам, что учетная запись администратора имеет права администратора на две системы. Синеватый край говорит нам, что «mnelson» зарегистрирован на HR-WS-002. В этом дизайне ребро всегда означает, что исходная вершина может скомпрометировать целевую вершину. Администратор может скомпрометировать HR-WS-002, а HR-WS-002 (т.е.: учетная запись SYSTEM на этом компьютере) может скомпрометировать mnelson.
Создание графика
Найти вершины для нашего графика не могло быть проще. Поскольку мы рассматриваем каждого пользователя и компьютер как узел, это так же просто, как использование двух командлетов
Визуальное представление графика в этот момент может выглядеть так:
При подготовке к выполнению Алгоритма Дейкстры мы даем каждой вершине следующие свойства:
Идентификация краев каждой вершины несколько больше. Опять же, мы можем использовать командлет PowerView - на этот раз это Get-NetSession . Этот командлет возвращает информацию о сеансе для каждого компьютера, на котором мы запускаем его, что позволяет нам видеть, что у пользователей есть сеансы на этом компьютере и откуда происходит этот сеанс, что позволяет нам определять, что пользователи регистрируют, где все - без лишних прав. Используя эту информацию, мы можем заполнить вершины компьютеров ребрами для зарегистрированных пользователей. Далее, для каждого компьютера у нас есть информация для входа в систему для пользователей, мы рекурсивно перечислим пользователей локального администратора на этом компьютере. Эта информация позволяет нам заполнить соответствующие пользовательские вершины ребрами с указанием прав локального администратора на этом компьютере.
В моей тестовой лаборатории завершенный график со всеми краями можно визуально представить следующим образом:
Напомним, что user -> computer обозначает права администратора, а край computer -> user - зарегистрированный пользователь.
Очевидно, что учетная запись «Администратор» является администратором каждого из трех компьютеров. Пользователь «mnelson» является администратором OPS-WS-002. Пользователь jwarner является администратором на IT-SRV-002.
HR-WS-002 имеет одного пользователя, которого вы вошли в систему: mnelson. OPS-WS-002, один пользователь: jwarner. Наконец, IT-SRV-002 с тремя зарегистрированными пользователями: rwinchester, jfrank и Administrator. Пользователь jdimmock не является ни администратором, ни зарегистрирован нигде (он, вероятно, на PTO).
Теперь у нас есть все необходимое, чтобы найти кратчайший путь от любой вершины к любой другой.
Вспомните сценарий, который я изложил ранее. Из «Steve-Admin» у нас есть десятки компьютеров и пользователей для таргетинга, ни одна из которых не дает нам немедленного доступа к учетной записи администратора домена. Вместо того, чтобы проводить часы, дни или даже недели, анализируя каждый вариант (или, что еще хуже: используя наши варианты в методологии проб и ошибок), мы можем использовать алгоритм, чтобы найти этот путь для нас за считанные минуты.
Алгоритм Дейкстры
Как только алгоритм завершится, значение расстояния каждой вершины скажет нам, можно ли достичь вершины. Вершины источника и сколько шагов необходимо . Кроме того, у нас есть хлебная крошка назад к нашему источнику благодаря свойству предшественника в каждой вершине:
Вывод и доказательство концепции
Мы едва затронули поверхность того, что здесь возможно. Есть некоторые очень интересные возможности применения теории графов к атакам и защите Active Directory (ознакомьтесь с этой замечательной записью от Brandon Helms aka cr0n1c: https://cr0n1c.wordpress.com/2016/01/27/use-sccm-to-violate-best-practices/). Например, изменив направление каждого края на этом графе и используя права администратора, чтобы получить больше данных.
В пользовательских данных, мы могли бы указать пользователя «Администратор» в качестве источника и определить с одной итерацией Алгоритма Дейкстры все учетные записи в AD, которые могут поставить под угрозу учетную запись «Администратор».
Здесь вы можете найти доказательство сценария:
https://github.com/andyrobbins/PowerPath
Источник: https://wald0.com/?p=14
Intro
Эскалация домена Active Directory является важной частью большинства пентестеров. Хотя получение прав администратора домена / предприятия не является конечной целью оценки, это часто делает достижение целей тестирования намного проще.
Типичный процесс эскалации домена вращается вокруг возможности собирать простые учетные данные или токены пользователей, зарегистрированных в системах, которые у вас есть, и могут привести к повышенные привилегий, - способность, наиболее известная для mimikatz. Найдите администратора домена, зарегистрированного в системе, на которой у вас есть права администратора, с помощью этой системы и получения учетных данных администратора.
Но что, если вы находитесь в более сложной ситуации, когда у вас сразу нет прав администратора в системе, где находится администратор домена? Вы можете быть одном, двух, трёх или более шагах от возможности компрометации администратора домена, и вам нужно будет сделать довольно небольшой анализа (или просто методом проб и ошибок), чтобы найти вектор.
Давайте посмотрим на гипотетическую ситуацию: мы получили права пользователя на уровне домена в среде с сотнями тысяч рабочих станций серверов, подключенных к лесу Active Directory с несколькими доменами с разным доверием. Наша цель состояла в том, чтобы повысить наши права до Администратора предприятия. К счастью, топология сети была практически плоской; Тем не менее, клиент применял чрезвычайно строгие методы с наименьшими привилегиями. После борьбы, чтобы найти средство для повышения наших прав, мы, наконец, смогли скомпрометировать учетную запись администратора сервера, которую мы будем называть «Steve-Admin».
«Steve-Admin» был локальным администратором на серверах, в которых он должен был быть администратором, и нигде больше. Мы возьмем этот список серверов и узнаем, какие пользователи были зарегистрированы на этих серверах. Однако в этот момент нам нужно было решить, с какими пользователями мы будем работать идти. Ни один из зарегистрированных пользователей, с которыми мы могли бы что-то сделать не были администраторами в блоках, где были зарегистрированы Domain Admins. Нам нужно было выбрать учетную запись, найти системы, на которых были права администратора, перечислить пользователей на этих машинах и продолжить, пока мы не найдем путь, который сработал. В среде с сотнями тысяч компьютеров и пользователей этот процесс может занять несколько дней или даже недель.
В этом посте я объясню и продемонстрирую доказательство концепции автоматизации этого процесса.
Предварительная работа
Это доказательство концепции в значительной степени зависит от существующих инструментов и концепций, любезно предоставленных публикой некоторыми очень умными, очень трудолюбивыми людьми:
- PowerView by Will Schroeder ( @ harmj0y ) - https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1
- Derivative Local Admin от Justin Warner ( @sixdub ) - http://www.sixdub.net/?p=591
- Реализация алгоритма Дейкстры в PowerShell Джим Трухером (@jwtruher) - https://jtruher3.wordpress.com/2006/10/16/dijkstra/
- Пути управления Active Directory от Emmanuel Gras и Lucas Bouillot - https://github.com/ANSSI-FR/AD-control-paths
- Узальный анализ Доверенных Доверов Юстином Уорнером ( @sixdub ) - http://www.sixdub.net/?p=285
Представьте себе, что вместо того, чтобы искать путь от «Steve-Admin» до Enterprise Admin, мы пытались найти путь из Сиэтла, штат Вашингтон, в Портленд, штат Орегон. Как человек, вы можете взглянуть на карту и довольно легко определить, что Interstate 5 доставит вас туда. Компьютер может найти путь между Сиэтлом и Портлендом (и между «Steve-Admin» и Enterprise Admin, если таковой существует)
может предоставить нам большую часть данных, необходимых для автоматизации процесса поиска пути от «Steve-Admin» до Enterprise Admin. Остальное приходит из области теории графовPowerView
- Вершины(Vertices) . Вершина (или узел) - это точка, используемая для представления отдельного элемента представляемой системы. Вы можете думать о городах на карте как о вершинах.
- Края(Edges ) - ребро используется для соединения вершин. Края могут быть направлены (то есть: в одну сторону) или неориентированы (то есть: двунаправленные). Края в общем случае представляют собой взаимосвязь. Если Сиэтл и Портленд можно рассматривать как вершины, I-5 можно рассматривать как двунаправленный край, соединяющий эти города.
- Путь(Path ) - путь - это набор ребер и узлов, соединяющих один узел с другим, являются ли эти узлы смежными или нет.
- Adjacency - Вершины, которые разделяют ребро, говорят, что они смежны.
Графический дизайн
Доказательство концепции, которую я придумал для этой проблемы, было разработано с одной целью - автоматизировать процесс поиска кратчайшего пути к компрометации администратора домена, не записывая ничего на диск или не требуя автономного анализа. Таким образом, дизайн этого графика может оказаться неприемлемым для других
- Каждый пользователь и компьютер являются вершинами.
- Все ребра направлены и невзвешены.
- Ориентированный край от пользователя к компьютеру указывает права локального администратора.
- Ориентированный край от компьютера к пользователю указывает зарегистрированного пользователя.
Каждый пользователь и компьютер являются вершинами. Оранжевые цвета говорят нам, что учетная запись администратора имеет права администратора на две системы. Синеватый край говорит нам, что «mnelson» зарегистрирован на HR-WS-002. В этом дизайне ребро всегда означает, что исходная вершина может скомпрометировать целевую вершину. Администратор может скомпрометировать HR-WS-002, а HR-WS-002 (т.е.: учетная запись SYSTEM на этом компьютере) может скомпрометировать mnelson.
Создание графика
Найти вершины для нашего графика не могло быть проще. Поскольку мы рассматриваем каждого пользователя и компьютер как узел, это так же просто, как использование двух командлетов
PowerView - Get-NetUser и Get-NetComputer :
Визуальное представление графика в этот момент может выглядеть так:
При подготовке к выполнению Алгоритма Дейкстры мы даем каждой вершине следующие свойства:
- Имя - имя вершины. Пример: «mnelson» или «HR-WS-002»
- Ребра - Массив вершин эта вершина имеет преимущество в. Первоначально установлено значение $ Null.
- Расстояние - количество переходов, необходимых для получения из исходной вершины в эту вершину. Первоначально установлено значение Infinity. Обратите внимание, что это невзвешенный график.
- Посещение - Определено ли кратчайшее расстояние до этого узла. Первоначально установлено значение $ False.
- Предшественник - имя предыдущей вершины в пути от исходной вершины к этой вершине. Первоначально установлено значение $ Null.
Идентификация краев каждой вершины несколько больше. Опять же, мы можем использовать командлет PowerView - на этот раз это Get-NetSession . Этот командлет возвращает информацию о сеансе для каждого компьютера, на котором мы запускаем его, что позволяет нам видеть, что у пользователей есть сеансы на этом компьютере и откуда происходит этот сеанс, что позволяет нам определять, что пользователи регистрируют, где все - без лишних прав. Используя эту информацию, мы можем заполнить вершины компьютеров ребрами для зарегистрированных пользователей. Далее, для каждого компьютера у нас есть информация для входа в систему для пользователей, мы рекурсивно перечислим пользователей локального администратора на этом компьютере. Эта информация позволяет нам заполнить соответствующие пользовательские вершины ребрами с указанием прав локального администратора на этом компьютере.
В моей тестовой лаборатории завершенный график со всеми краями можно визуально представить следующим образом:
Напомним, что user -> computer обозначает права администратора, а край computer -> user - зарегистрированный пользователь.
Очевидно, что учетная запись «Администратор» является администратором каждого из трех компьютеров. Пользователь «mnelson» является администратором OPS-WS-002. Пользователь jwarner является администратором на IT-SRV-002.
HR-WS-002 имеет одного пользователя, которого вы вошли в систему: mnelson. OPS-WS-002, один пользователь: jwarner. Наконец, IT-SRV-002 с тремя зарегистрированными пользователями: rwinchester, jfrank и Administrator. Пользователь jdimmock не является ни администратором, ни зарегистрирован нигде (он, вероятно, на PTO).
Теперь у нас есть все необходимое, чтобы найти кратчайший путь от любой вершины к любой другой.
Вспомните сценарий, который я изложил ранее. Из «Steve-Admin» у нас есть десятки компьютеров и пользователей для таргетинга, ни одна из которых не дает нам немедленного доступа к учетной записи администратора домена. Вместо того, чтобы проводить часы, дни или даже недели, анализируя каждый вариант (или, что еще хуже: используя наши варианты в методологии проб и ошибок), мы можем использовать алгоритм, чтобы найти этот путь для нас за считанные минуты.
Алгоритм Дейкстры
- Определите исходную вершину. Установите его расстояние до 0. Установите расстояние каждой другой вершины до бесконечности.
- Определите невидимую вершину с наименьшим значением расстояния и отметьте ее как Текущую вершину.
- Рассмотрим ребра текущей вершины. Для каждой вершины, прилегающей к текущей вершине, сравните ее расстояние с расстоянием Текущая вершина плюс один - обновите расстояние соседней вершины, если это вычисленное расстояние ниже текущего значения и обновите значение предшествующего предшественника соседнего имени Текущая вершина.
- Перейдите к шагу 2 до тех пор, пока не будут посещены все вершины.
Как только алгоритм завершится, значение расстояния каждой вершины скажет нам, можно ли достичь вершины. Вершины источника и сколько шагов необходимо . Кроме того, у нас есть хлебная крошка назад к нашему источнику благодаря свойству предшественника в каждой вершине:
- Возьмите имя целевой вершины и добавьте ее в наш массив путей.
- Возьмите последнюю добавленную вершину в массиве путей и найдите ее предшественницу. Добавьте предшественника в массив путей.
- Повторяйте, пока не будет предшественников. В этот момент мы достигли нашей исходной вершины.
Вывод и доказательство концепции
Мы едва затронули поверхность того, что здесь возможно. Есть некоторые очень интересные возможности применения теории графов к атакам и защите Active Directory (ознакомьтесь с этой замечательной записью от Brandon Helms aka cr0n1c: https://cr0n1c.wordpress.com/2016/01/27/use-sccm-to-violate-best-practices/). Например, изменив направление каждого края на этом графе и используя права администратора, чтобы получить больше данных.
В пользовательских данных, мы могли бы указать пользователя «Администратор» в качестве источника и определить с одной итерацией Алгоритма Дейкстры все учетные записи в AD, которые могут поставить под угрозу учетную запись «Администратор».
Здесь вы можете найти доказательство сценария:
https://github.com/andyrobbins/PowerPath
Источник: https://wald0.com/?p=14
Последнее редактирование:
