Foreign user
Last updated
Configuring
Login to
DC01with theAdministratoruser and the passwordWelcome01!.Open the "Active Directory Users and Computers" administration tool.
3. Open the "Users" directory and right click it, then select "New" and then "Users".
4. Create a new user with the name secure_admin and the password rFKbUJrDu$sz*36ffKr6.
5. Make sure "Password never expires" is checked and "User must change password at next logon" is unchecked when creating the user.
6. to DC03 with the Administrator user and the password Welcome01!.
7. Open the "Active Directory Users and Computers" administration tool.
8. Open the "Users" directory and right click it, then select "New" and then "Group".
9. Make a new group with the name Local admin data and select group scope "Domain Local".
10. Right click the group and select "Properties". Click on the "Members" tab and click on "Add"
11. Click on "Locations" and select bank.local.
12. Enter the username secure_admin and click "Check Names" and then click "OK".
13. Click "Apply" and then "OK".
14. To make the group local admin to the DATA01 server there are two options
Login to the machine and use the net command to add the group to the local administrators group.
Deploy a GPO to make the group local admin on the machine.
15. We will go with the first step since its just easier for the lab setup, but normally IT would deploy it with GPO. So login with the username Administrator and password Welcome01! to DATA01 and execute the following command:
Attacking
How it works
If there is a trust between two forests, it is possible to add a user of domain A to a group in domain B. If for example this group gives local admin privileges to a system in forest B then after taking over that user it is possible to gain access to domain B using that account. Depending on the trust flow configured between the domains(one way or two way trust), they can both add other users or only one domain can add users.
Meaning that if you take over domain A you can easily access domain B by enumerating the groups which have a foreign user from domain A. I see this often used for having one admin account to manage both domains for example.
Tools
Executing the attack
This attack is executing from the perspective of already gaining Enterprise Admin privileges within the bank.local admin.
To easily execute the attack login on
DC01with the userAdministratorand the passwordWelcome01!.Start PowerShell and load an amsi and PowerView into memory:
3. With the PowerView cmdlet Get-DomainForeigGroupMember we can query the target domain for users in groups that aren't from their domain.
4. The output shows us that there is a foreign user in the Local admin data group and that the member is S-1-5-21-320929719-844265543-1524670925-1602. To get the user name we can use the ConvertFrom-SID cmdlet from PowerView:
5. The user bank\secure_admin from bank.local is member of local admin data in secure.local. We can also see this in bloodhound after collecting the data for both domains and loading it into the BloodHound GUI.
After clicking on "Users with Foreign Domain Group Membership" and selecting Secure.local under the "Dangerous Rights" section in the "Analysis" tab we see:
6. Since we are already domain admin we could simply reset the password for the secure_admin user. But this isn't OPSEC safe, so we can execute a dcsync to grab its NTLM hash and then use it to spray against the other domain computers to check if the user has access to any machine. To execute the DCSync load MimiKatz into memory and use the following command:
7. The next step would be to spray this hash against all systems of the secure.local domain. But its just easier to spray it against the whole subnet with crackmapexec. To do this we use the following command:
8. The user secure_admin from bank.local is local admin to the DATA01 machine from secure.local.
Defending
Recommendations
I would recommend to not add users from other domains in privileged groups if you don't FULLY trust the other domain to be secure. But this is a risk based decision to make.
