Module 07
Last updated
Last updated
On the host FS1 we were able to retrieve a file containing a password. The password was "Winter2019", which looks very much like a default password as it might be assigned by a service desk on a password reset.
A common attack technique is to now try this password for all users within the domain. This is called "password spraying".
There are a lot of tools to automate password spraying. While there are some tools which directly connect to the Active Directory to retrieve a list of all users, for others you might have to provide this information yourself.
In this case, we are going to use a tool called kerbrute, which requires a user list. To retrieve this list, we can use the tool GetADUsers.py from the Impacket collection.
On your Linux attack host, navigate to the tools directory:
cd /home/lab_admin/tools
Then, run the following command to collect a list of AD users and write the output to getadusers.out:
GetADUsers.py -hashes :9859340265d3b3c1eb628ece70ebc238 -dc-ip 10.0.1.100 winattacklab.local/aalfort | tee getadusers.out
Now we just need to parse the usernames from this output with the following command:
awk '/winattacklab.local/{print $1}' getadusers.out | tee usernames.txt
An important thing to consider when performing password spraying is to not lock out user accounts due to too many failed logins.
Let's check the active lockout policy in our Windows attack lab. Open a command prompt as tmassie on the Windows 10 client and type the following command:
net accounts /domain
As you can see in the output above, the property Lockout threshold is set to Never, which means there is no lockout configured (lucky us).
Note: when spraying with just one password, you will almost never cause a lockout, as this would mean the user's account is locked after just one failed attempt. A more common value might be 5 or 10 attempts.
If this would be the case, we would have to consider the value of Lockout observation window (minutes), which is set to 30.
This translates to: "Lock the account if 5 invalid attempts are observed within 30 minutes".
To avoid a lockout, we would just have to stay under this threshold and perform up to a maximum of 4 failed attempts every 30 minutes.
cd /home/lab_admin/tools/
We will have to provide the tool with some additional information:
IP address of the domain controller: 10.0.1.100
Domain name: winattacklab.local
List of users: usernames.txt
Password to test: Winter2019
We put it all together like this:
./kerbrute passwordspray --dc 10.0.1.100 -d winattacklab.local usernames.txt Winter2019
As we can see, kerbrute detected a successful login for the user cclear@winattacklab.local!
We now have found credentials for another user, namely "cclear@winattacklab.local". Let's update this information in our Bloodhound instance and see if we can (ab)use it.
Let's check if this user has any interesting properties or connections to other systems. The Group Delegated Local Admin Rights look promising:
We can see that this user has local admin privileges on the host WS1!
With the user "cclear" now marked as "owned", we can again check if Bloodhound can find a path to the domain administrators.
Click on "Shortest Paths to Domain Admins from Owned Principals" in the "Queries" menu and select our domain admin group:
And suddenly, we are presented with a quite "short" attack path:
What is the difference between Password Spraying and Brute Force attacks?
Why do we care about the lockout policy?
If we stay below the lockout threshold, are we sure that the attack cannot be detected?
Do I need admin rights in order to list all users in an active directory environment?
How do we know the IP address of the domain controller?
We “guessed” the credentials of user Cclear – nice, but what is the underlaying security problem here?
Finally the query "Shortest Paths to Domain Admins from Owned Principals" provides a result – why?
What is the next step to become domain admin?
Password Spraying:
check one known password against several users
Brute Force:
check user account with known username and guess password based on password lists
2. Otherwise the user get locked out and will be visible on the radar (log entries -> failed attempts). Furthermore the Lockout duration prevents us for further tries during this time.
3. No, the following events can be an indicator:
several login attempts from the same source for several users (main indicator)
login attempts from unknown source (more difficult to detect)
4. No admin rights are required. The list was performed with user tmassie.
get-netuser | select samaccountname
5. We got the information from the nmap scan in step 2 But we can also extract the information with the following nslookup command:
nslookup set type=all _ldap._tcp.dc._msdcs.winattack.local
6. The main security issue is the users reuse the same password for several accounts.
7. The user CClear has the permission as WS1ADMIN to access WS1 and user FFAST has an active session on WS1.
8. access to WS1 credential dumping to get logon information from FFAST
