Содержание
Представьте, что кто-то проводит атаку на корпоративную сеть Windows. Вначале у злоумышленника либо мало привилегий в домене, либо их вовсе нет. Поэтому искать учетные записи и службы он будет без повышенных привилегий, то есть не от имени администратора домена или локального администратора. О том, как производится разведка в среде Active Directory, мы и поговорим в этой статье.
Еще по теме: Захват Active Directory на виртуальной машине с HackTheBox
Рассмотренные в данной статье примеры применимы для следующих версий Windows: 7, 8, 10, Server 2008, Server 2012 и Server 2016; другие не проверяли. Также для работы примеров в системе должен быть PowerShell с указанными модулями.
Сканирование SPN
Когда нужно повысить привилегии, злоумышленники обычно используют учетные записи служб, поскольку у таких учеток больше прав, но нет строгой политики смены пароля через заданный промежуток времени. То есть если скомпрометировать их, то потом можно долго оставаться незамеченным.
Service Principal Names (SPN) — идентификаторы служб, запущенных на доменной машине. Не зная их, вы не сможете искать службы, которые используют проверку подлинности Kerberos. SPN уникальный в пределах леса. Когда компьютер добавляют в домен, у его учетной записи автоматически указывается host SPN, что позволяет службам на этой машине запускаться из-под локальных учетных записей, таких как Local System и Network Service.
SPN — строка следующего формата:
1 |
SPN="serviceclass"/"hostname[:port]"[/"servicename"] |
- Serviceclass — строка, которая идентифицирует класс службы, например ldap — идентификатор для службы каталогов;
- Hostname — строка, где указывается полное доменное имя системы, а иногда и порт;
- Servicename — строка, которая представляет собой уникальное имя (DN), GUID объекта или полностью определенное доменное имя (FQDN) службы.
Сканирование SPN — это первое, что обычно делает злоумышленник или пентестер при поиске служб в среде Active Directory. Основное преимущество этого метода по сравнению со сканированием сетевых портов в том, что не требуется взаимодействие с каждым узлом сети для проверки служебных портов. Сканирование SPN позволяет обнаружить службы с помощью запросов LDAP к контроллеру домена. Так как запросы SPN — нормальное поведение проверки подлинности Kerberos, этот способ сканирования обнаружить очень сложно, даже почти нереально в отличие от сканирования портов.
Выполнить сканирование SPN можно с помощью скрипта на PowerShell.
Наиболее интересные службы:
- SQL — MSSQLSvc/adsmsSQLAP01.ads.org:1433
- Exchange — exchangeMDB/adsmsEXCAS01.ads.org
- RDP — TERMSERV/adsmsEXCAS01.adsecurity.org
- WSMan/WinRM/PS Remoting — WSMAN/adsmsEXCAS01.ads.org
- Hyper-V — Microsoft Virtual Console Service/adsmsHV01.ady.org
- VMware VCenter — STS/adsmsVC01.ads.org
Хочу поделиться с вами и еще одним интересным скриптом, который покажет вам все SPN для всех пользователей и всех компьютеров.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"") $search.filter = "(servicePrincipalName=*)" $results = $search.Findall() foreach($result in $results){ $userEntry = $result.GetDirectoryEntry() Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black" Write-host "DN = " $userEntry.distinguishedName Write-host "Object Cat. = " $userEntry.objectCategory Write-host "servicePrincipalNames" $i=1 foreach($SPN in $userEntry.servicePrincipalName) { Write-host "SPN(" $i ") = " $SPN $i+=1 } Write-host "" } |
Сбор данных
Общие ресурсы
В среде Active Directory часто используются сетевые папки и файловые серверы. Эти команды отобразят список общих ресурсов на локальном хосте, список сетевых компьютеров и список шар на удаленном компьютере:
1 2 3 |
> net share > net view > net view COMPUTER_NAME /all |
Но что делать, если политика безопасности запрещает использовать сетевые команды? В этом случае нас выручит wmic. Список общих ресурсов на локальном хосте и список общих ресурсов на удаленном компьютере можно посмотреть с помощью команд
1 2 |
> wmic share get /format:list > wmic /node: COMPUTER_NAME share get |
Полезный инструмент для поиска данных — PowerView. Он автоматически обнаруживает сетевые ресурсы и файловые серверы с помощью команд Find-DomainShare и Get-DomainFileServer.
Кстати, PowerView встроен в фреймворк PowerShell Empire и представлен двумя модулями:
- situational_awareness/network/powerview/share_finder;
- situational_awareness/network/powerview/get_fileserver.
Базы данных
В среде Active Directory, как правило, несколько серверов баз данных. PowerUpSQL — отличный инструмент для обнаружения, перечисления и атак на серверы Microsoft SQL.
Найти все локальные экземпляры SQL можно командой Get-SQLInstanceLocal -Verbose. Чтобы найти все экземпляры SQL в сети или домене, используйте команды Get-SQLInstanceDomain -Verbose, Get-SQLInstanceBroadcast -Verbose и Get-SQLInstanceScanUDP -Verbose.
После поиска собираем информацию об экземплярах SQL:
- Get-SQLInstanceLocal | Get-SQLServerInfo — для локальных;
- Get-SQLServerInfo -Instance «COMPUTER_NAME» — для удаленных.
Когда мы нашли все экземпляры SQL и собрали информацию о них, мы можем:
- получить список экземпляров SQL, в которые разрешен вход текущему пользователю домена
1 |
Get-SQLInstanceDomain –Verbose | Get-SQLConnectionTestThreaded –Verbose -Threads 10 |
- Попытаться получить права администратора для экземпляра SQL:
1 |
Invoke-SQLEscalatePriv -Verbose -Instance "COMPUTER_NAME" |
- Перечислить экземпляры SQL по всему домену с использованием паролей по умолчанию:
1 |
Get-SQLInstanceDomain -Verbose | Get-SQLServerLoginDefaultPw -Verbose |
- Сдампить информацию о SQL Server и базе данных в файлы CSV или XML:
1 |
Invoke-SQLDumpInfo -Verbose -Instance "COMPUTER_NAME" |
- Запустить функции аудита для сервера SQL:
1 |
Invoke-SQLAudit -Verbose -Instance "COMPUTER_NAME" |
Network Attached Storage
Network Attached Storage (NAS) — сервер для хранения данных на файловом уровне. Поскольку там сложены файлы, нередко это и есть цель злоумышленника. NAS не нужна полноценная операционка, поэтому на них часто ставят FreeNAS или NAS4Free на базе FreeBSD. Большинство NAS можно администрировать через веб или SSH. В таком случает следует перебрать дефолтные связки логин — пароль.
Вот пятерка самых распространенных:
- admin:admin;
- admin:password;
- root:nasadmin;
- nasadmin:nasadmin;
- admin:»no pass».
Пользовательские данные при наличии привилегий
Учетные данные пользователей
Для охоты на пользователей отлично подходит BloodHound — инструмент для активного поиска каталогов.
Определить, где конкретный пользователь или группа пользователей вошли в систему, можно с помощью команд PowerView и модуля PowerShell Empire.
1 2 3 4 |
>Find-DomainUserLocation -UserIdentity USER_NAME >Find-DomainUserLocation -UserGroupIdentity GROUP_NAME situational_awareness/network/powerview/user_hunter |
Локальные данные
После компрометации учетных данных пользователей появляется много возможностей: запись на рабочий стол, получение картинки с веб-камеры, сброс паролей, установка кейлоггеров. Большая часть этих возможностей автоматизирована в инструментах Metasploit Framework, PowerShell Empire и Cobalt Strike.
Многие — может быть, даже вы — позволяют браузерам сохранять свои пароли. И часто мы используем одни и те же пароли для разных сервисов, так что найденные в браузере пароли нам еще, скорее всего, пригодятся.
Вот модули Metasploit, которые помогают в этом.
1 2 3 4 5 |
post/windows/gather/enum_chrome post/multi/gather/firefox_creds post/firefox/gather/cookies post/firefox/gather/passwords post/windows/gather/forensics/browser_history |
Модули PowerShell Empire.
1 2 |
collection/ChromeDump collection/FoxDump |
Вытащить пароли можно и вручную. Для этого сохраните профиль браузера, импортируйте его на виртуальную машину, откройте браузер и посмотрите пароли.
Файлы профилей Firefox лежат в:
1 |
C:\Users\TARGET\AppData\Roaming\Mozilla\Firefox\Profiles |
Профилей Google Chrome в:
1 |
C:\Users\TARGET\AppData\Local\Google\Chrome\User Data\Default |
Чтобы узнать данные удаленного доступа, можно использовать модуль Metasploit post/windows/gather/enum_putty_saved_sessions или модули Empire collection/netripper и credentials/sessiongopher.
Пользовательские файлы
Часто цель атакующего — это пользовательские файлы. Для их поиска есть очень удобный скрипт на PowerShell — WMImplant. Он позволяет использовать фильтры. Например, чтобы найти файл с именем wmimplant, выполним команды
1 2 |
$filefilter = "Filename = 'wmimplant' AND Drive='C:'" Get-WMIObject -Class CIM_Datafile -filter $filefilter |
Также можно настроить фильтр по расширению файла.
1 2 |
> $filefilter = "Extensios = 'ps1' AND Drive='C:'" > Get-WMIObject -Class CIM_Datafile -filter $filefilter |
Для поиска файлов на удаленной машине указывай для Get-WMIObject параметр -ComputerName.
Microsoft Exchange и Outlook при наличии привилегий
Если у злоумышленника есть учетные данные пользователей, то почтовые ящики, считай, тоже скомпрометированы. Если вы выступаете на атакующей стороне, открывайте панель Outlook и делайте запросы, по которым могут найтись полезные данные. Например, логин, пароль, password, pass, credentials, vpn, ssh, root, confidential.
Этот процесс можно автоматизировать при помощи инструмента MailSniper. Для автоматического обнаружения целевого сервера Exchange и поиска в почтовом ящике user@example.com используйте такую команду:
1 |
> Invoke-SelfSearch -OutputCsv local-results.csv -Mailbox user@example.com |
Если ящик известен, то такую:
1 |
> Invoke-SelfSearch -Remote -ExchHostname outlook.office365.com -OutputCsv local-results.csv -Mailbox user@example.com |
Если у вас уже есть права администратора Exchange, можно искать по всем почтовым ящикам:
1 |
> Invoke-GlobalMailSearch -ImpersonationAccount TARGET_USER -ExchHostname Exch01 -OutputCsv global-results.csv |
Учетные данные
Учетные записи администраторов домена
Существует два эффективных метода искать учетные записи с повышенными правами в Active Directory. Первый — стандартный метод перечисления групп, который идентифицирует всех членов обычных групп администраторов Active Directory. В большинстве организаций есть пользовательские группы администраторов — схемы именования могут быть разными, но если искать по слову admin, то, скорее всего, не промахнетесь.
1 2 3 4 5 6 7 8 9 |
> get-adgroup -filter {GroupCategory -eq ‘Security’ -AND Name -like “admin”} DistinguishedName : CN=Server Admins,OU=AD Management,DC=lab,DC=adsecurity,DC=org GroupCategory : Security GroupScope : Global Name : Server Admins ObjectClass : group ObjectGUID : 3877c311-9321-41c0-a6b5-c0d88684b335 SamAccountName : ServerAdmins SID : S-1-5-21-1581655573-3923512380-696647894-2628 |
Второй метод — искать учетки, у которых атрибут AdminCount равен единице.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
> get-aduser -filter {AdminCount -eq 1} -Properties Name,AdminCount,ServicePrincipalName,MemberOf AdminCount : 1 DistinguishedName : CN=ADSAdministrator,CN=Users,DC=lab,DC=ads,DC=org Enabled : True MemberOf : {CN=Administrators,CN=Builtin,DC=lab,DC=ads,DC=org, CN=Schema Admins,CN=Users,DC=lab,DC=ads,DC=org, CN=Group Policy Creator Owners,CN=Users,DC=lab,DC=ads,DC=org, CN=Enterprise Admins,CN=Users,DC=lab,DC=ads,DC=org…} Name : ADSAdministrator ObjectClass : user ObjectGUID : 72ac7731-0a76-4e5a-8e5d-b4ded9a304b5 SamAccountName : ADSAdministrator SID : S-1-5-21-1581655573-3923512380-696647894-500 Surname : UserPrincipalName : |
Но учтите, что в числе прочего получите учетки, у которых прав администратора нет. Дело в том, что это значение не сбрасывается автоматически после удаления учетной записи из групп администраторов.
Скрытая учетная запись администратора
Скрытая учетная запись администратора — это учетная запись домена, которая предоставляет администратору доступ к контроллеру домена, серверу обмена или серверу баз данных. Но эта запись не принадлежит к привилегированным группам Active Directory, то есть администраторам домена. Разрешения для таких учеток назначаются напрямую с помощью списков контроля доступа (ACL) для объектов Active Directory.
Еще по теме: Утилиты аудита безопасности Windows
Часто это учетные записи служб. Они обычно имеют доступ к нескольким системам в среде. При этом такие учетки не получают столько же внимания и таких же строгих политик безопасности, как администраторы домена. В результате они становятся главной целью злоумышленников при «движении вбок» или повышении привилегий.
Для поиска скрытых учетных записей администратора используйте инструмент BloodHound. Полную инструкцию по установке этого инструмента можете найти в вики проекта.
После настройки базы данных и входа в веб-интерфейс BloodHound можно начинать собирать данные Active Directory с помощью BloodHound PowerShell. Вот как запустить команды для поиска доменов в лесу и сохранить CSV в указанную папку:
1 2 |
> . .\SharpHound.ps1 > Invoke-BloodHound -SearchForest -CSVFolder C:\Users\Public |
После загрузки файла у вас есть большой выбор дальнейших действий. Можно просмотреть всех администраторов домена, глянуть список пользователей с правами локальных администраторов, определить машины с правами администраторов и многое другое.
Таким образом, при просмотре «карты доверительных отношений» и «10 пользователей с большинством прав локальных администраторов» мы сможем определить учетные записи, которые имеют доступ к большинству систем, а также узнать, существуют ли двусторонние отношения доверия между внешними доменами, которые могли бы расширить круг доступных ресурсов.
Другой способ найти скрытые учетные записи администратора — поиск контроллера домена.
- Ищем группу Domain Controllers.
- Выбираем «Прямые участники» в разделе «Участники группы»: там отображены все узлы системы контроллера домена в этой группе.
- Ткнув на один из узлов системы в разделе «Местные администраторы», выбираем «Производные локальные администраторы».
Как видите, есть две учетные записи, которые имеют локальный доступ администратора к контроллеру домена. Они не входят в группу «Администраторы домена». Поздравляю, мы только что обнаружили две скрытые учетные записи администратора!
Группы Active Directory
Группы Active Directory бывают двух типов.
- Группы распространения — используются для списков рассылки электронной почты и не могут служить для контроля доступа к ресурсам, поэтому они нам неинтересны.
- Группы безопасности — могут применяться для контроля доступа и добавлены в списки контроля доступа.
Независимо от того, к какому типу относится группа, она задается битом в свойстве groupType.
Группы безопасности могут иметь одну из трех областей действия. Область действия группы влияет на то, какие типы групповых объектов могут быть добавлены в нее и в какие другие группы группа может быть вложена.
- Глобальные группы могут быть вложены в локальные группы домена, универсальные группы и другие глобальные группы в одном домене.
- Универсальные группы могут быть вложены в локальные группы домена и другие универсальные группы в любом домене.
- Локальная группа домена не может быть вложена в глобальную или универсальную группу.
Найти все группы какого-то типа можно с помощью PowerView.
- Get-DomainGroup -GroupScope DomainLocal — найти локальные группы;
- Get-DomainGroup -GroupScope NotDomainLocal — найти нелокальные группы;
- Get-DomainGroup -GroupScope Global — найти глобальные группы;
- Get-DomainGroup -GroupScope NotGlobal — найти неглобальные группы;
- Get-DomainGroup -GroupScope Universal— найти универсальные группы;
- Get-DomainGroup -GroupScope NotUniversal — найти неуниверсальные группы;
- Get-DomainGroup -GroupProperty Security — найти группы безопасности;
- Get-DomainGroup -GroupProperty Distribution — найти группы распространения;
- Get-DomainGroup -GroupProperty CreatedBySystem — найти группы, созданные системой.
Информация из локальных групп Active Directory
Найти локальных администраторов можно с помощью команды Invoke-EnumerateLocalAdmin | ft -autosize.
Получить список всех пользователей поможет модуль PowerShell activedirectory, достаточно выполнить команду Get_ADUser -filter *. Получить список групп, в которых числится определенный пользователь, можно командой Get-NetGroup -UserName [user].
Также есть возможность узнать список компьютеров, к которым имеет доступ конкретный пользователь или группа. Для этого используйте команды Find-GPOLocation -UserName [user] и Find-GPOLocation -GroupName [group]. Но можно вернуть и список объектов, имеющих доступ к определенному компьютеру. Для этого есть команда Find-GPOComputerAdmin -ComputerName [computer] -Recurse.
Еще очень важная информация, которую мы можем получить: какие объекты групповой политики применяются к конкретной машине. Делается это командой Get-DomainGPO -ComputerIdentity [PC_id] -Properties displayname.
Важно, что все эти функции позволяют запрашивать информацию без повышенных привилегий.
Local Administrator Password Solution
Local Administrator Password Solution (LAPS) — система, предназначенная для управления паролями локальных администраторов на компьютерах домена. Она позволяет администратору домена периодически менять пароль учетной записи локальных администраторов, делегировать права на чтение и сброс пароля для пользователей или групп Active Directory, а также обеспечивает хранение паролей в расширенном атрибуте объекта компьютера в Active Directory. Система состоит из трех компонентов: агента, модуля PowerShell для настройки системы, Active Directory для хранения паролей.
Есть два способа обнаружить LAPS.
- На всех хостах, где установлен LAPS, в папке C:\Program Files\LAPS\CSE\ будет файл AdmPwd.dll.
- Конфигурации LAPS определяются в объектах групповой политики. Командой Get-DomainGPO -Identity «*LAPS*» можно поискать любой объект групповой политики, у которого есть слово LAPS в отображаемом имени.
1 2 3 4 5 |
displayname : LAPS ... gpcfilesyspath : \\test.local\SysVol\test.local\Policies\{C3801BA8-56D9-4F54-B2BD-FE3BF1A71BAA} distinguishedname : CN={C3801BA8-56D9-4F54-B2BD-FE3BF1A71BAA},CN=Policies,CN=System,DC=testlab,DC=local ... |
1 |
Parse-PolFile "\\test.local\SysVol\test.local\Policies\{C8701BA8-56D9-4123-B6B2-FE3FA5031BAA}\Machine\Registry.pol" |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
KeyName : Software\Policies\Microsoft Services\AdmPwd ValueName : PasswordComplexity ValueType : REG_DWORD ValueLength : 4 ValueData : 4 KeyName : Software\Policies\Microsoft Services\AdmPwd ValueName : PasswordLength ValueType : REG_DWORD ValueLength : 4 ValueData : 8 KeyName : Software\Policies\Microsoft Services\AdmPwd ValueName : PasswordAgeDays ValueType : REG_DWORD ValueLength : 4 ValueData : 30 KeyName : Software\Policies\Microsoft Services\AdmPwd ValueName : AdminAccountName ValueType : REG_SZ ValueLength : 26 ValueData : localfish KeyName : Software\Policies\Microsoft Services\AdmPwd ValueName : AdmPwdEnabled ValueType : REG_DWORD ValueLength : 4 ValueData : 1 |
Теперь найдем все компьютеры, к которым применен этот объект групповой политики. Для этого нам нужно знать GUID этого объекта. Сначала определим подразделения, а потом в каждом подразделении найдем рабочие станции.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
> Get-DomainOU -GPLink "C3801BA8-56D9-4F54-B2BD-FE3BF1A71BAA" -Properties distinguishedname distinguishedname ----------------- OU=Workstations,DC=testlab,DC=local OU=Servers,DC=testlab,DC=local > Get-DomainComputer -SearchBase "LDAP://OU=Workstations,DC=testlab,DC=local" -Properties distinguishedname distinguishedname ----------------- CN=WKSTN02,OU=Workstations,DC=testlab,DC=local CN=WKSTN01,OU=Workstations,DC=testlab,DC=local CN=WKSTN03,OU=Workstations,DC=testlab,DC=local CN=WKSTN04,OU=Workstations,DC=testlab,DC=local > Get-DomainComputer -SearchBase "LDAP://OU=Servers,DC=testlab,DC=local" -Properties distinguishedname distinguishedname ----------------- CN=FS01,OU=Servers,DC=testlab,DC=local |
Мы нашли все компьютеры, на которые распространяется эта конфигурация LAPS. Компонент LAPS PowerShell дает много возможностей. Например, вот такой командой мы можем определить, что LAB\Workstation Admins и LAB\Server Admins имеют расширенные права в подразделениях Workstations и Servers:
1 2 3 4 5 6 7 |
> Find-AdmPwdExtendedRights -Identity "Workstations" | fl ObjectDN : OU=Workstations,DC=testlab,DC=local ExtendedRightHolders : {NT AUTHORITY\SYSTEM, LAB\Domain Admins, LAB\Workstation Admins} > Find-AdmPwdExtendedRights -Identity "Servers" | fl ObjectDN : OU=Servers,DC=testlab,DC=local ExtendedRightHolders : {NT AUTHORITY\SYSTEM, LAB\Domain Admins, LAB\Server Admins} |
Теперь легко получить пароль.
1 2 3 4 5 |
> Get-AdmPwdPassword -ComputerName wkstn02 | fl ComputerName : WKSTN02 DistinguishedName : CN=WKSTN02,OU=Workstations,DC=testlab,DC=local Password : !qP)iyT ExpirationTimestamp : |
AppLocker
AppLocker — технология, которая позволяет системному администратору блокировать выполнение определенных исполняемых файлов на компьютерах в сети. То есть можно создать правила, по которым будет выдаваться разрешение на выполнение или отказ. Например, можно проверять уникальные идентификаторы файлов и разрешать запуск только определенным пользователям или группам.
Еще по теме: Как обойти AppLocker при атаке на Active Directory
Обычно конфигурация AppLocker применяется через объект групповой политики. В таком случае легко извлечь конфигурацию из SYSVOL, если у нас есть доступ на чтение к общему ресурсу. Как просмотреть объекты групповой политики и к каким машинам они применяются, смотрите в разделе LAPS. Отличается только путь:
1 |
Software\Policies\Microsoft\Windows\SrpV2\%ext%\xxxxxxxx-xxx-xxx-xxx-xxxxxxxxxxxx |
Есть три способа применения запрещающего правила: Publisher, Path и File Hash.
На месте %ext% используйте ключи: Appx, Exe, Dll, Msi, Script.
Azure Active Directory
Azure Active Directory (Azure AD) — облачная служба управления удостоверениями и доступом. Она нужна для создания учетных записей пользователей и управления ими и применяется в облачных сервисах Microsoft, таких как Azure, Office 365, SharePoint. Если в AD для аутентификации пользователей служит Kerberos, то здесь в той же роли используется OAuth 2.0.
Синхронизация AD и Azure AD происходит по трем сценариям.
- Сценарий синхронизации каталога. Он позволяет синхронизировать с облаком новые учетные записи пользователей и групп, при этом логин у пользователя синхронизируется с AD, а пароль придется сменить, так как он не синхронизируется.
- Сценарий синхронизации паролей дает возможность пользователям логиниться в облачный сервис с паролем от локальной учетной записи AD. При этом синхронизируется логин и хеш пароля.
- Сценарий единого входа обеспечивает проверку подлинности пользователей в локальном каталоге AD и позволяет реализовать сценарий единого входа с использованием корпоративных учетных данных — за счет синхронизации токенов доступа.
Про атаку на сценарий единого входа много рассказать не могу, и для него нужны права администратора. Так как пароль в данном случае передается между Azure AD Connect и Azure ServiceBus в открытом виде, то есть возможность его перехватить. FileAzureadHookDLL позволяет внедрить DLL и получить пароль пользователя во время соединения. В качестве параметра данное приложение принимает PID процесса AzureADConnectAuthenticationAgentService[*].
Сценарий синхронизации паролей
Для нас особенно интересен сценарий синхронизации паролей (PHS). Для синхронизации данных в AD есть приложение Azure AD Connect, которое извлекает данные из AD и передает их в AAD. За синхронизацию отвечает служба DCSync.
При создании соединения на хосте заводится новая база данных, при этом используется LocalDB для SQL Server. Мы можем просмотреть информацию о работающем экземпляре с помощью инструмента SqlLocalDb.exe.
База данных поддерживает Azure AD Sync — в ней хранятся метаданные и конфигурации для службы. Зашифрованный пароль находится в таблице ADSync.dbo.mms_management_agent в поле encrypted_configuration, и для его расшифровки используется библиотека C:\Program Files\Microsoft Azure AD Sync\Binn\mcrypt.dll. Расшифровывать можно при помощи AzureadDecryptorMsol.ps1.
Как видите из конфигурации безопасности, если получится скомпрометировать сервер с Azure AD Connect и получить доступ либо к ADSyncAdmins, либо к локальным группам администраторов, то открывается возможность заполучить учетку, которая может выполнять DCSync.
Сценарий синхронизации каталога
В этом сценарии к одной и той же учетной записи в AD и AAD применяются разные пароли, что делает неактуальной атаку на сессию синхронизации. Но так как остальные учетные данные в случае синхронизации будут совпадать, мы можем провести разведку для AAD, и ее результаты в большинстве будут актуальны для AD.
Для удобства будем использовать Azure CLI, это инструмент для Linux, который используют в сетях Windows. Начинаем с команды az login — она сгенерирует локальные токены OAuth, откроет окно браузера на странице авторизации, и вы сможете войти под уже имеющимся пользователем. Следующая команда позволяет получить список пользователей, параметр output определяет формат представления данных, а query — какие данные выводить.
1 |
az ad user list --output=json --query='[].{UPN:userPrincipalName,Name:displayName,Email:mail,UserId:mailNickname,Enabled:accountEnabled}' |
Вот некоторые другие возможности.
Список групп:
1 |
az ad group list --output=json --query='[].{Group:displayName,Description:description}' |
Список пользователей в определенной группе:
1 |
az ad group member list --output=json --query='[].{UPN:userPrincipalName, Name:displayName, UserId:mailNickname, Enabled:accountEnabled}' --group='<group name>' |
Список приложений:
1 |
az ad app list --output=json --query='[].{Name:displayName,URL:homepage}' |
Все службы:
1 |
az ad sp list --output=json --query='[].{Name:displayName,Enabled:accountEnabled,URL:homepage}' |
Информация о конкретной службе:
1 |
az ad sp list --output=json --display-name='<display name>' |
Заключение
Теперь вы знаете все лазейки и методы, с помощью которых можно получить информацию для проведения атак на пользователей, повышения привилегий, бокового продвижения и захвата сети в целом. Используйте эти знания с умом!
Еще по теме: Взлом и защита Active Directory