0% found this document useful (0 votes)
172 views

Module 3-Final

This module discusses protecting privileged accounts in Windows. The document covers identifying privileged accounts, using Windows features to mitigate credential theft, and contains a disclaimer about third-party tools used in the labs only being for educational purposes in a controlled test environment. At the end of the exercises, users will be able to identify privileged accounts and utilize Windows features to strengthen security against credential theft attacks.

Uploaded by

camotillo
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
172 views

Module 3-Final

This module discusses protecting privileged accounts in Windows. The document covers identifying privileged accounts, using Windows features to mitigate credential theft, and contains a disclaimer about third-party tools used in the labs only being for educational purposes in a controlled test environment. At the end of the exercises, users will be able to identify privileged accounts and utilize Windows features to strengthen security against credential theft attacks.

Uploaded by

camotillo
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Module 3

This module is about protecting privileged accounts thanks to Windows features.

At the end of these exercises you will be able to identify privileged accounts and use windows
features to mitigate credential theft attacks.

DISCLAIMER
These labs contain third-party tools. Please be aware of the following guidelines:

• These tools are for research purposes only. Microsoft does not own these tools nor
can it guarantee their behavior.
• These tools should only be run in a test lab environment.
• They are tools that are used by both hackers and penetration testers, and need to
be treated with caution and with clear policies and permissions.
• The trainer is authorized to describe in details how the tools work and to show
recorded videos of the tools to the attendees.
• The trainer is giving guidance to the attendees on how to better defend Active
Directory against those tools. This includes demonstration of the tools in the
workshop’s labs.
• The lab machines used in the offering have those tools pre-installed. Those
machines are not connected to any network else then the lab network. Those
machines are not connected to the Internet.
• The attendees cannot keep a copy of the lab machines. Through your agreement to
attend the training, Microsoft disclaims any liability for the misuse of these tools,
either accidentally or intentionally. Use of these tools in this environment is for
training purposes only.

Now, if you agree, you can click Next.

Last update - 2019-03-08


A. Default administrative groups
Scenario
Hello Norma. As a new transferee to the brand-new identity and security team of Contoso, you
decided to get a better understanding of who has privileges in the forest. You will start your day
by looking at all default group memberships and remove some of the crazy legacy accesses you
find.

1. Log on to CONTOSO - WIN10.

Use the following credentials:

Username CONTOSO\NormaLuser
Password Pa$$w0rd

2. Right-click on the start button and click Windows PowerShell. In the Windows
PowerShell console type the following commands:
3. cd \Tools\Scans
.\FGSn.ps1

4. Once the script has finished running, open an Explorer window and navigate to
C:\Tools\Scans. You should see two HTML files such as:

The actual names will vary as they start with a timestamp of the execution of the script. Double-
click on (TIMESTAMP)_Forest_Report. Note the number of detected admins and scroll down
the page to see the details per domain. Minimize the window.

4. Double-click on (TIMESTAMP)_Domain_Report. On the contoso.com domain, click


on the Administrators link (or scroll down the page until you find it). What do you think
about the list of members?

If you hover over the Zzz sign with your mouse, you should see the last time the user logged on.

You will review and comment the content of this group with your instructor.
5. Scroll all the way up the page, then on the contoso.com domain, click on the Account
Operators link (or scroll down the page until you find it). Who are the members of this
group? Do you think it is a risky configuration?
6. Scroll all the way up the page, then click the Show/Hide link next to the contoso.com
domain. Then in the emea.contoso.com section, click on Administrators. Who is the
first member of that group? What are the consequences of such a configuration?

If you click the Show/Hide additional information link next to the name of the
group, it will show when the member has been added.
If you click the icon at the beginning of the line of each member, it will link you
to the collected information about this object. This link you to:

7. Scroll all the way up the page, then click the Show/Hide link next to the contoso.com
domain. Then in the contoso.com section, click on Administrators. Who is the first
member of that group? What are the consequences of such a configuration?

The domain administrator has been instructed to remove some of the suspicious membership you
have identified. You are now the domain administrator…
8. Switch to CONTOSO - DC01 and log on using the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

9. Right-click on the start button and click Run. In the Run window, type dsac.exe and
click OK.
10. On the left part of the Active Directory Administrative Center, click Global Search. In
the Global Search section, do a search for Account Operators. Then double-click on
the Account Operators group in the results section.
11. On the left of the Account Operators window, click Members. Then click on
ANONYMOUS LOGON and click Remove. Click OK to close the window.
12. In the Global Search section, do a search for Backup Operators. Then double-click on
the Backup Operators group in the results section.
13. On the left of the Backup Operators window, click Members. Then click on
ANONYMOUS LOGON and click Remove. Click OK to close the window.
14. In the Global Search section, do a search for Print Operators. Then double-click on
the Print Operators group in the results section.
15. On the left of the Print Operators window, click Members. Then click on
ANONYMOUS LOGON and click Remove. Click OK to close the window.
16. In the Global Search section, do a search for Administrators. Then double-click on the
Administrators group in the results section.
17. On the left of the Administrators window, click Members. Then, if necessary, click on
ANONYMOUS LOGON and click Remove. Click OK to close the window.
To have the PowerShell equivalent of what you've just done, you can click on the small ^ icon
on the bottom right of the Active Directory Administrative Center console. If you also check the
Show All box, it will list all commands since you opened the console (including the searches).

18. A colleague of you (who also plays basketball with you at lunch break on Fridays) is
asking you for a favor. Adding his service account into the Domain Admins group just
for few seconds so he can back up a bunch of his production servers. And well, he is a
good basketball player, there is no reason not to trust him. In the Global Search section,
do a search for Domain Admins. Then double-click on the Domain Admins group in the
results section.
19. On the left of the Domain Admins window, click Members. Then click Add. In the pop-
up, type svc-tsm and click Check Names. Then click OK to close the popup and OK to
close the Domain Admins window.
20. Your guy just sent you a mail saying he is done with his backup. Time to remove it from
the Domain Admins group. In the Global Search section, do a search for Domain Admins.
Then double-click on the Domain Admins group in the results section.
21. On the left of the Domain Admins window, click Members. Then click on svc-tsm and
click Remove. Click OK to close the window. Hopefully nobody noticed…

If you are about to take a break, save your labs before!

B. Ephemeral admins
Scenario
Welcome back Norma! With the recent creation of the identity and security team (which starts
looking at groups more closely), you suspect that some operators are taking advantage of their
misconfigured permissions to add accounts into the Domain Admins group for a few seconds and
then take them out when they are done with their task. You do not have access to the security
logs of the domain controllers, yet you'd like to know if that rumor is true.

1. Log on to CONTOSO - WIN10.

Use the following credentials:

Username CONTOSO\NormaLuser
Password Pa$$w0rd

2. Right-click on the start button and click Windows PowerShell. In the Windows
PowerShell console type the following code:
3. Get-ADGroup -Identity "Domain Admins" | `
4. Get-ADReplicationAttributeMetadata -Server DC01.contoso.com -
ShowAllLinkedValues | `
5. Where-Object { $_.AttributeName -eq "member" -and $_.AttributeValue -
isnot [array] } | ` Select-Object AttributeValue,
FirstOriginatingCreateTime,LastOriginatingChangeTime,@{Name="Deleted";E
xpression={ If ($_.LastOriginatingDeleteTime -eq "1601-01-
01T00:00:00Z") { "Active" } Else { $_.LastOriginatingDeleteTime}
}},Version | `
Out-GridView -Title "Domain Admins members"
You see the following:

What we are looking at here are replication metadata. It is information the domain
controllers stores in order to replicate it. When you add a user into a group, we
need to replicate this new membership. When you remove the membership, we
also need to replicate it. Ask your instructor if you want to know more about
replication metadata. And yes, as you realized, a normal user can read metadata
and long as they can read the object.

6. OPTIONAL: If you are connected on a machine without the PowerShell module, but you
have the repadmin.exe utility, you can display the same information with repadmin
/showobjmeta dc01.contoso.com "CN=Domain
Admins,CN=Users,DC=contoso,DC=com".

If you are about to take a break, save your labs before!

C. RDP /RestrictedMode
Scenario
You just got out of a meeting with Norma and you don't look good. The new team has performed
a bunch of pentests and they were always able to rapidly steal your credentials. But you have a
plan. From now on, you will only use the /RestrictedAdmin mode of RDP to connect to servers
which are not domain controllers.

1. Log on to CONTOSO - SRV01.

Use the following credentials:

Username CONTOSO\Administrator (the domain account, not the local Administrator)


Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type regedit and
click OK.
3. Expand HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa then
create a new DWORD (32-bits) Value. Use the following information:

Name DisableRestrictedAdmin
Data 0 (which is the default data when you create a new DWORD value)

4. Close the Registry Editor and sign out of SRV01.


5. Switch to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

6. Right-click on the start button and click Run. In the Run window, type mstsc
/restrictedadmin and click OK. In the Remote Desktop Connection window, type
SRV01 and click Connect.
7. Once connected on SRV01, right-click on the start button and click Command Prompt
(Admin).
8. Run whoami. The output will show it is you: CONTOSO\Administrator. Try to remotely
list one administrative drive on a domain controller running dir
\\dc01.contoso.com\c$. You should see an access denied message.
9. Still on the same command prompt, run the following:
10. cd \Tools\Creds &
11. mode 120,400 &
mimikatz.exe

12. In the mimikatz prompt, type privilege::debug. You should see the output Privilege
'20' OK. If not, make sure you ran the command prompt as an admin and retry.

13. Still in the mimikatz prompt, type sekurlsa::msv. In the output, look for the session
RemoteInteractive for the Administrator account:

You do have a hash, but that is not yours! It is the computer account's hash (SRV01). So if Peter
(the local admin from module 2) was trying to steal your hash, he would not be able to get it,
instead, it will have the computer's hash that he already has since he is a locally admin.

8. Sign out of your RDP session.


If you are about to take a break, save your labs before!

D. Protected Users
Scenario
Now that you know about the /restrictedadmin, you use it all the time! But you hit an issue on
that exchange server… You want to use it on the EXCH1, but it seems that nobody enabled it
there. Well, let's use the Protected Users group then, and see what mitigation it brings to the
table!

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type mstsc
/restrictedadmin and click OK. In the Remote Desktop Connection window, type
EXCH1 and click Connect. But this happens:
3. Click OK. You are now back on DC01. Close the Remote Desktop Connection client
window.
4. Right-click on the start button and click Run. In the Run window, type dsac.exe and
click OK.
5. On the left part of the Active Directory Administrative Center, click Global Search. In
the Global Search section, do a search for Protected Users. Then double-click on the
Protected Users group in the results section.
6. On the left of the Protected Users window, click Members. Then click Add. In the pop-
up, type Administrator and click Check Names. Then click OK to close the popup and
OK to close the Protected Users window.
7. Right-click on the start button and click Run. In the Run window, type mstsc (without
the /restrictedadmin parameter) and click OK. In the Remote Desktop Connection
window, type EXCH1 and click Connect. When prompted for Password, use Pa$$w0rd.
8. Once connected on EXCH1, right-click on the start button and click Command Prompt
(Admin). Then run the following:
9. cd \Tools\Creds &
10. mode 120,400 &
mimikatz.exe
11. In the mimikatz prompt, run privilege::debug. You should see the output Privilege
'20' OK. If not, make sure you ran the command prompt as an admin and retry.

12. Still in the mimikatz prompt, run sekurlsa::msv. In the output, look for the
Administrator's session: Nothing to steal.
13. In the mimikatz prompt, run exit. Back in the command prompt, run dir
\\10.0.0.10\c$. Does this work? What is the error message?
14. Sign out from EXCH1. Once back on DC01, open the Active Directory Administrative
Center and remove the Administrator account from the Protected Users group.
15. Sign out of DC01.

If you are about to take a break, save your labs before!

E. Fine Grained Password Policy


Scenario
Norma and her team just came back from a something hat conference. One of the "demo hits"
was about Kerberos roasting. Contoso has a ton of service accounts which never change their
passwords and which would be vulnerable to such an attack. As the Contoso domain
administrator, you have been tasked with ensuring that newly created service accounts have a
very long password. To achieve this, you will create a new password policy.

1. Log on to CONTOSO - DC01.

Use the following credentials:


Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type dsac.exe and
click OK.

3. In the Active Directory Administrative Center, enable the Tree view by clicking this icon:

4. Now expand contoso (local)/System/Password Settings Container. On the task section


(right side of the console), click New then Password Settings.
5. Enter the following information:

Name Service Account Password Policy


Precedence 10
Minimum password length 32

6. Leave all the rest with the default setting.


In the Directly Applies To section, click Add. Type svc-tsm and click Check Names.
Then click OK. Click OK to create the password policy.
7. Right-click on the start button and click Run. In the Run window, type powershell and
click OK.
8. In the PowerShell console, run the following:
9. Set-Location \
Get-ADUserResultantPasswordPolicy -Identity "CN=svc-tsm,OU=Service
Accounts,OU=_Admins,DC=contoso,DC=com"
The cmdLet Get-ADUserResultantPasswordPolicy returns nothing is there is no
FGPP applied on the account. In that case the domain policy is applying. And you
can get the details of that one with the command Get-
ADDefaultDomainPasswordPolicy.

10. Still in the PowerShell console, run Set-ADAccountPassword -Identity "CN=svc-


tsm,OU=Service Accounts,OU=_Admins,DC=contoso,DC=com" -Reset -
NewPassword (ConvertTo-SecureString -AsPlainText
"T90*JhgaGrb@;llJh8rhaNBF99ffCON" -Force). It does not work because the
condition of 32 characters minimum is not met.
11. Now run Set-ADAccountPassword -Identity "CN=svc-tsm,OU=Service
Accounts,OU=_Admins,DC=contoso,DC=com" -Reset -NewPassword (ConvertTo-
SecureString -AsPlainText "14Tyy9(gaGrb@;daertyhaNBF9sJhhhad" -Force)
12. Sign out of DC01.

If you are about to take a break (again? seriously?) save your labs before!

F. Azure AD Password Protection


Scenario
Password spray attack is a big issue. And to address it, the security team bought Azure AD
Premium P1 licenses for all the synchronized users. You have just installed the on-premises part
of Azure AD Password Protection. Here is what the configuration looks like in Azure AD:
Let's see it in action!

1. Log on to CONTOSO - DC01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type powershell and
click OK.
3. In the PowerShell console, run the following:
4. New-ADUser -Name AzureADTest1
Set-ADAccountPassword -Identity AzureADTest1 -Reset -NewPassword
(ConvertTo-SecureString -AsPlainText "welcome1!" -Force)

This will fail because this password has been added to your banned passwords list.

5. Run Set-ADAccountPassword -Identity AzureADTest1 -Reset -NewPassword


(ConvertTo-SecureString -AsPlainText "Welcome1!!" -Force). This still fails
because this password is not far enough from one of your banned passwords.
6. Run Set-ADAccountPassword -Identity AzureADTest1 -Reset -NewPassword
(ConvertTo-SecureString -AsPlainText "Micros0ft!" -Force). This fails
because this password is using a seed that was banned by default.
7. Right-click on the start button and click Event Viewer. Expand Applications and
Services Logs/Microsoft/AzureADPasswordProtection/DCAgent and click Admin.

8. Open one of the events 10017. They should look like this one:

9. Now, let's check the statistics on the Azure AD Password Protection proxy. In here, it has
been installed on EXCH1. Normally, you could locate all proxies by running the
following in your PowerShell console:

PowerShell
$scp = "serviceConnectionPoint"
$keywords = "{EBEFB703-6113-413D-9167-9F8DD4D24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and
keywords -like $keywords }

And the DistinguishedName would show it is EXCH1. But because our environment is
disconnected from the Internet, EXCH1 stopped updating the SCP.

10. Close all windows and sign out of DC01.


11. Log on to CONTOSO - EXCH1.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

12. Right-click on the start button and click Run. In the Run window, type powershell and
click OK.
13. In the PowerShell console, run the following:
14. Set-Location "C:\Program Files\Azure AD Password Protection
Proxy\Modules\AzureADPasswordProtection"
15. Import-Module AzureADPasswordProtection
Get-AzureADPasswordProtectionSummaryReport

Here are the stats so far:

16. Close all the windows and sign out of EXCH1.

If you are about to take a break, save your labs before!


G. Group Managed Service Account
Scenario
Your environment is getting more and more secure. As a part of your domain administrator role,
you need to regularly backup your group policies. This task will run from SRV01 as non-domain
admins needs to be able to modify it. We already have the script C:\Tools\GPO\gpobackup.cmd,
we will need to create the task and the account to run it.

1. Log on to CONTOSO - SRV01.

Use the following credentials:

Username CONTOSO\Administrator
Password Pa$$w0rd

2. Right-click on the start button and click Run. In the Run window, type powershell and
click OK.
3. First, we prepare the domain for gMSA. In the PowerShell console, run Add-KdsRootKey
-EffectiveTime ((get-date).addhours(-10)).
4. Then we create the account, run New-ADServiceAccount -Name svc-gpo -
Description "Account for GPO backup." -DNSHostName srv01.contoso.com -
PrincipalsAllowedToRetrieveManagedPassword SRV01$.

We have to specify the DNSHostName parameter although it will not be used in


our case. It would be used if the account was running a service for which users
have to authenticate against. In our case, the account will only be used for a
scheduled task, hence the value is irrelevant.

5. And finally we install the account on the local system, run Install-ADServiceAccount
svc-gpo.
6. Now we create the scheduled task. Still on the PowerShell console, run the following
commands:
7. $action = New-ScheduledTaskAction "C:\Tools\GPO\gpobackup.bat" ;
8. $trigger = New-ScheduledTaskTrigger -At 22:00 -Daily ;
9. $principal = New-ScheduledTaskPrincipal -UserID CONTOSO\svc-gpo$ -
LogonType Password ;
Register-ScheduledTask "GPO Backup" –Action $action –Trigger $trigger –
Principal $principal

10. Open explorer and browse to C:\Tools. Right-click on GPO and click Properties. Click
the Security tab and click the Edit. In the Permissions for GPO window, select the Users
(SRV01\Users) ACE and check the Allow Full Control checkbox.
11. Right-click on the start button and click Run. In the Run window, type taskschd.msc
and click OK.
12. On the middle section of the Task Scheduler window, right-click on GPO Backup and
click Run.
13. In the explorer window, browse to C:\Tools\GPO. There should be a log file
gpobackup.log if the task has been executed successfully.

This was the last exercise for this module.

Thank you for protecting your accounts!

See you in the next module!

You might also like