DS‐ Week 2 ‐ Windows Local Privilege Escalation Submission - 229300/SEC-335-01 GitHub Wiki

Screenshot of WinPEAS banner and initial execution:

Screenshot of the color-coded output summary:

Output file saved as winpeas_output_[yourname].txt:

What hash algorithm does WinPEAS use for verification? What is the file hash?

  1. WinPEAS uses SHA256 for its verification

What does the RED/YELLOW/GREEN color coding indicate?

  1. Red- Indicates special privilege over an object or misconfiguration
  2. Yellow- Indicates links
  3. Green- Indicates protection is enabled or something is well configured

How long did the full scan take? What factors affect scan duration? It took about 5-8 minutes, for the scan to freeze.

  1. Document the bypass method:
  1. Document the 10 vulnerabilities to explain how it elevates privileges. This should explain what specific weakness is being exploited.
  1. Provide links to resources that show how to exploit the vulnerabilities.
  1. Write a short summary on how to exploit each vulnerability.

V1. The service path has spaces and no quotes, so Windows tries each partial path in turn. Drop a payload named for an earlier path segment in a writable folder, and it runs as SYSTEM when the service restarts.

V2. AlwaysInstallElevated: Both the HKLM and HKCU keys are set to 1, so any MSI installs as SYSTEM. Build a malicious MSI (e.g. with msfvenom) and run it with msiexec /i evil.msi to get code execution as SYSTEM.

V3. Weak Service Permissions (WeakSvc): The low-priv account can reconfigure the service. Use sc config WeakSvc binPath= to point it at the payload, then restart it so the payload runs as SYSTEM.

V4. Weak Registry Permissions (RegSvc): The service's registry key is writable, and ImagePath controls which binary it launches. Overwrite ImagePath with your payload's path and restart the service to run as SYSTEM.

V5. DLL Hijacking (DLLHijackSvc): The service loads a DLL from a location you can write to. Plant a malicious DLL with the expected name there, and it loads into the SYSTEM service process on restart.

V6. Missing Service Binary (MissingBinSvc): The service points to a binary that doesn't exist in a writable folder. Create your payload at that exact path and start the service to execute as SYSTEM.

V7. Writable PATH Directory: A folder on the system PATH is user-writable. Plant a binary named after something a privileged process calls without a full path, and it gets executed in that higher-privilege context.

V8. Startup Folder Permissions: The All-Users startup folder is writable, and anything in it runs at logon. Drop a payload there and it executes in the next user's context, full privesc if an admin logs in.

V9. Unattend.xml with Credentials: A leftover answer file contains admin credentials that are only base64 encoded. Read the file, decode the password, and log in or run commands as that privileged account.

V10. Scheduled Task (VulnScheduledTask): A task runs as SYSTEM but executes a file you can modify. Overwrite that file with your payload and let the task trigger to run as SYSTEM.

  1. Write a short summary on how to fix each vulnerability.

V1. Unquoted Service Path: Wrap the service's binary path in quotes so it can't be hijacked. Remove standard user write access from the parent directories.

V2. AlwaysInstallElevated: Set both the HKLM and HKCU keys to 0 and disable the "Always install with elevated privileges" Group Policy. This policy should never be enabled in production.

V3. Weak Service Permissions: Reset the service's DACL (Discretionary Access Control List) so only Administrators and SYSTEM can reconfigure it. Standard users should have read-only access at most.

V4. Weak Registry Permissions: Fix the service key's ACL so non-admins can't write to it. Users should be limited to read-only.

V5. DLL Hijacking: Have the application load DLLs by absolute path and ship every DLL it needs. Remove write access from the service's binary directory and any PATH folders it searches.

V6. Missing Service Binary: Delete the orphaned service if it's not needed, or restore the correct signed binary to a protected location. Lock down the directory so users can't write to it.

V7. Writable PATH Directory: Remove standard user write access from the directory, or drop it from the system PATH entirely. Never put user-writable folders on the machine PATH.

V8. Startup Folder Permissions: Restore the default permissions so only Administrators and SYSTEM can write to the common startup folder. Monitor startup locations for unexpected entries.

V9. Unattend.xml with Credentials: Delete answer files after imaging is finished and never store real credentials in them. Use LAPS for rotating, per-machine local admin passwords instead.

V10. Scheduled Task: Lock down the ACL on any file the task executes so only admins and SYSTEM can modify it. Run the task with the least privilege it actually needs rather than as SYSTEM.

Always keep track of the type of payload, LHOST, and LPORT used with msfvenom. It is required for the Metasploit listener. You might get an error popup screen when the service starts, it is okay

  1. LHOST- Kali VM and c2 server- 10.0.17.15
  2. LPORT- Must be root to open ports below 1024
  • Create a video showing that you’ve exploited the vulnerability and obtained SYSTEM level access within Metasploit.
  • You can use the command “whoami” to show your current user permissions on Windows and then the same command to show you obtained SYSTEM

Videos:

I couldn't get the third vulnerability after many tries.