☑️Additional Techniques
Interacting with Users
Traffic Capture
If Wireshark is installed, unprivileged users may be able to capture network traffic, as the option to restrict Npcap driver access to Administrators only is not enabled by default.
Here we can see a rough example of capturing cleartext FTP credentials entered by another user while signed into the same box. While not highly likely, if Wireshark is installed on a box that we land on, it is worth attempting a traffic capture to see what we can pick up.
If possible, we should run tcpdump or wireshark on the network for a while to see what kind of traffic is there and find anything interesting. The tool net-creds can be run from our attack box to sniff passwords and hashes from a live interface or a pcap file.
Monitoring Process Command Lines
When getting a shell as a user, there may be scheduled tasks or other processes being executed which pass credentials on the command line. We can look for process command lines using something like this script below. It captures process command lines every two seconds and compares the current state with the previous state, outputting any differences.
Running and executing remotely
We can host the script on our attack machine and execute it on the target host as follows.
This might reveal credentials or sensitive information passed through commands by processes.
Vulnerable Services
We may also encounter situations where we land on a host running a vulnerable application that can be used to elevate privileges through user interaction. CVE-2019–15752 is a great example of this. This was a vulnerability in Docker Desktop Community Edition before 2.1.0.1. When this particular version of Docker starts, it looks for several different files, including docker-credential-wincred.exe, docker-credential-wincred.bat, etc., which do not exist with a Docker installation. The program looks for these files in the C:\PROGRAMDATA\DockerDesktop\version-bin\. This directory was misconfigured to allow full write access to the BUILTIN\Users group, meaning that any authenticated user on the system could write a file into it (such as a malicious executable).
Any executable placed in that directory would run when a) the Docker application starts and b) when a user authenticates using the command docker login. While a bit older, it is not outside the realm of possibility to encounter a developer's workstation running this version of Docker Desktop, hence why it is always important to thoroughly enumerate installed software. While this particular flaw wouldn't guarantee us elevated access (since it relies on a service restart or user action), we could plant our executable during a long-term assessment and periodically check if it runs and our privileges are elevated.
SCP on a File Share
A Shell Command File (SCF) is used by Windows Explorer to move up and down directories, show the Desktop, etc. An SCF file can be manipulated to have the icon file location point to a specific UNC path and have Windows Explorer start an SMB session when the folder where the .scf file resides is accessed. If we change the IconFile to an SMB server that we control and run a tool such as Responder, Inveigh, or InveighZero, we can often capture NTLMv2 password hashes for any users who browse the share. This can be particularly useful if we gain write access to a file share that looks to be heavily used or even a directory on a user's workstation. We may be able to capture a user's password hash and use the cleartext password to escalate privileges on the target host, within the domain, or further our access/gain access to other resources.
Malicious SCP File
In this example, let's create the following file and name it something like @Inventory.scf (similar to another file in the directory, so it does not appear out of place). We put an @ at the start of the file name to appear at the top of the directory to ensure it is seen and executed by Windows Explorer as soon as the user accesses the share. Here we put in our tun0 IP address and any fake share name and .ico file name.
Starting Responder
Next, start Responder on our attack box and wait for the user to browse the share. If all goes to plan, we will see the user's NTLMV2 password hash in our console and attempt to crack it offline.
Cracking it with hashcat
Capturing Hashes with a Malicious .lnk File
Using SCFs no longer works on Server 2019 hosts, but we can achieve the same effect using a malicious .lnk file. We can use various tools to generate a malicious .lnk file, such as Lnkbomb, as it is not as straightforward as creating a malicious .scf file. We can also make one using a few lines of PowerShell:
Pillaging
Pillaging is the process of obtaining information from a compromised system. It can be personal information, corporate blueprints, credit card data, server information, infrastructure and network details, passwords, or other types of credentials, and anything relevant to the company or security assessment we are working on.
Data Sources
Below are some of the sources from which we can obtain information from compromised systems:
Installed applications
Installed services
Websites
File Shares
Databases
Directory Services (such as Active Directory, Azure AD, etc.)
Name Servers
Deployment Services
Certificate Authority
Source Code Management Server
Virtualization
Messaging
Monitoring and Logging Systems
Backups
Sensitive Data
Keylogging
Screen Capture
Network Traffic Capture
Previous Audit reports
User Information
History files, interesting documents (.doc/x,.xls/x,password./pass., etc)
Roles and Privileges
Web Browsers
IM Clients
Example Scenario
Let's assume that we have gained a foothold on the Windows server mentioned in the below network and start collecting as much information as possible.
Installed Applications
We may encounter a lot of unknown applications on the systems we compromised. Learning and understanding how these applications connect to the business are essential to achieving our goal.
An alternative is to use PowerShell and read the Windows registry to collect more granular information about installed programs.
We can see the mRemoteNG software is installed on the system. mRemoteNG is a tool used to manage and connect to remote systems using VNC, RDP, SSH, and similar protocols. Let's take a look at mRemoteNG.
mRemoteNG
mRemoteNG saves connection info and credentials to a file called confCons.xml. They use a hardcoded master password, mR3m, so if anyone starts saving credentials in mRemoteNG and does not protect the configuration with a password, we can access the credentials from the configuration file and decrypt them.
By default, the configuration file is located in %USERPROFILE%\APPDATA\Roaming\mRemoteNG.
Let's look at the contents of the confCons.xml file.
This XML document contains a root element called Connections with the information about the encryption used for the credentials and the attribute Protected, which corresponds to the master password used to encrypt the document. We can use this string to attempt to crack the master password. We will find some elements named Node within the root element. Those nodes contain details about the remote system, such as username, domain, hostname, protocol, and password. All fields are plaintext except the password, which is encrypted with the master password.
if the user didn't set a custom master password, we can use the script mRemoteNG-Decrypt to decrypt the password.
If it was encrypted with a non default password
We can pass it like this:
From here, we can even create a loop to crack the master password:
Abusing Cookies to Get Access to IM Clients
Companies use many Instant Messaging applications like Slack or MS Teams. If we can get access to them we might be able to steal sensitive information. There are two ways to get access. We can use the users credentials and log into the cloud version of the app. Or if we dont have the credentials we can steal the cookie and log in that way to the cloud.
There are often tools that may help us automate the process, but as the cloud and applications constantly evolve, we may find these applications out of date, and we still need to find a way to gather information from the IM clients. Understanding how to abuse credentials, cookies, and tokens is often helpful in accessing web applications such as IM Clients.
Slack - Extracting from Firefox
Let's use Slack as an example. Multiple posts refer to how to abuse Slack such as Abusing Slack for Offensive Operations and Phishing for Slack-tokens. We can use them to understand better how Slack tokens and cookies work, but keep in mind that Slack's behavior may have changed since the release of those posts.
There's also a tool called SlackExtract released in 2018, which was able to extract Slack messages. Their research discusses the cookie named d, which Slack uses to store the user's authentication token. If we can get our hands on that cookie, we will be able to authenticate as the user. Instead of using the tool, we will attempt to obtain the cookie from Firefox or a Chromium-based browser and authenticate as the user.
Firefox saves the cookies in an SQLite database in a file named cookies.sqlite. This file is in each user's APPDATA directory %APPDATA%\Mozilla\Firefox\Profiles\<RANDOM>.default-release. There's a piece of the file that is random, and we can use a wildcard in PowerShell to copy the file content.
Next, we can use cookieextractor.py to extract the cookies:
Now that we have the cookie, we can use any cookie editor browser extension to use the cookie.
Now we are logged in as the user and can click on Launch Slack. We may get a prompt for credentials or other types of authentication information; we can repeat the above process and replace the cookie d with the same value we used to gain access the first time on any website that asks us for information or credentials.
Once we complete this process for every website where we get a prompt, we need to refresh the browser, click on Launch Slack and use Slack in the browser.
After gaining access, we can use built-in functions to search for common words like passwords, credentials, PII, or any other information relevant to our assessment.
Chromium Based Browsers
The chromium-based browser also stores its cookies information in an SQLite database. The only difference is that the cookie value is encrypted with Data Protection API (DPAPI).
To get the cookie value, we'll need to perform a decryption routine from the session of the user we compromised. Thankfully, a tool SharpChromium does what we need. It connects to the current user SQLite cookie database, decrypts the cookie value, and presents the result in JSON format.
Let's use Invoke-SharpChromium, a PowerShell script created by S3cur3Th1sSh1t which uses reflection to load SharpChromium.
We got an error because the cookie file path that contains the database is hardcoded in SharpChromium, and the current version of Chrome uses a different location.
We can modify the code of SharpChromium or copy the cookie file to where SharpChromium is looking.
SharpChromium is looking for a file in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies, but the actual file is located in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies with the following command we will copy the file to the location SharpChromium is expecting.
We can now try extracting again and it'll work this time:
We can now use this cookie with cookie-editor as we did with Firefox.
Clipboard
In many companies, network administrators use password managers to store their credentials and copy and paste passwords into login forms. As this doesn't involve typing the passwords, keystroke logging is not effective in this case. The clipboard provides access to a significant amount of information, such as the pasting of credentials and 2FA soft tokens, as well as the possibility to interact directly with the RDP session clipboard.
We can use the Invoke-Clipboard script to extract user clipboard data. Start the logger by issuing the command below.
The script will start to monitor for entries in the clipboard and present them in the PowerShell session. We need to be patient and wait until we capture sensitive information.
Roles and Services
Services on a particular host may serve the host itself or other hosts on the target network. It is necessary to create a profile of each targeted host, documenting the configuration of these services, their purpose, and how we can potentially use them to achieve our assessment goals. Typical server roles and services include:
File and Print Servers
Web and Database Servers
Certificate Authority Servers
Source Code Management Servers
Backup Servers
Let's take Backup Servers as an example, and how, if we compromise a server or host with a backup system, we can compromise the network.
Typically backup systems need an account to connect to the target machine and perform the backup. Most companies require that backup accounts have local administrative privileges on the target machine to access all its files and services.
restic
Let's use restic as an example. Restic is a modern backup program that can back up files in Linux, BSD, Mac, and Windows.
To start working with restic, we must create a repository (the directory where backups will be stored). Restic checks if the environment variable RESTIC_PASSWORD is set and uses its content as the password for the repository. If this variable is not set, it will ask for the password to initialize the repository and for any other operation in this repository.
We will use restic 0.13.1 and back up the repository C:\xampp\htdocs\webapp in E:\restic\ directory. To download the latest version of restic, visit https://github.com/restic/restic/releases/latest. On our target machine, restic is located at C:\Windows\System32\restic.exe.
First lets create the repository where backups will be saved.
Now lets create our first backup.
Backing up C:/Windows
If we want to back up a directory such as C:\Windows, which has some files actively used by the operating system, we can use the option --use-fs-snapshot to create a VSS (Volume Shadow Copy) to perform the backup.
If the user doesn't have the rights to access or copy the content of a directory, we may get an Access denied message. The backup will be created, but no content will be found.
We can also check which backups are saved in the repository using the snapshot command.
We can restore a backup using the ID.
If we navigate to C:\Restore, we will find the directory structure where the backup was taken. To get to the SampleFolder directory, we need to navigate to C:\Restore\C\SampleFolder.
We need to understand our targets and what kind of information we are looking for. If we find a backup for a Linux machine, we may want to check files like /etc/shadow to crack users' credentials, web configuration files, .ssh directories to look for SSH keys, etc.
If we are targeting a Windows backup, we may want to look for the SAM & SYSTEM hive to extract local account hashes. We can also identify web application directories and common files where credentials or sensitive information is stored, such as web.config files. Our goal is to look for any interesting files that can help us achieve our goal.
Note: restic works similarly in Linux. If we don't know where restic snapshots are saved, we can look in the file system for a directory named snapshots. Keep in mind that the environment variable may not be set. If that's the case, we will need to provide a password to restore the files.
Hundreds of applications and methods exist to perform backups, and we cannot detail each. This restic case is an example of how a backup application could work. Other systems will manage a centralized console and special repositories to save the backup information and execute the backup tasks.
As we move forward, we will find different backup systems, and we recommend taking the time to understand how they work so that we can eventually abuse their functions for our purpose.
Miscellaneous Techniques
LOLBAS
Living Off The Land Binaries and Scripts (LOLBAS), documents binaries, scripts, and libraries that can be used for "living off the land" techniques on Windows systems. Each of these binaries, scripts and libraries is a Microsoft-signed file that is either native to the operating system or can be downloaded directly from Microsoft and have unexpected functionality useful to an attacker. Some interesting functionality may include:
Persistence
UAC bypass
Credential theft
Dumping process memory
Keylogging
Evasion
DLL hijacking
Basically, GTFObins for Windows.
Transferring File with Certutil
One classic example is certutil.exe, whose intended use is for handling certificates but can also be used to transfer files by either downloading a file to disk or base64 encoding/decoding a file.
We can also encode decode files:
Always Install Elevated
This setting can be set via Local Group Policy by setting Always install with elevated privileges to Enabled under the following paths.
Computer Configuration\Administrative Templates\Windows Components\Windows InstallerUser Configuration\Administrative Templates\Windows Components\Windows Installer
Let's enumerate this setting.
If it returns the key AlwaysInstallElevated then we will know that this policy is enabled.
Exploitation
We can exploit this by generating a malicious MSI package and execute it via the command line to obtain a reverse shell with SYSTEM privileges.
We can upload this MSI file to our target, start a Netcat listener and execute the file from the command line like so:
If all goes to plan, we will receive a connection back as NT AUTHORITY\SYSTEM.
CVE-2019-1388
CVE-2019-1388 was a privilege escalation vulnerability in the Windows Certificate Dialog, which did not properly enforce user privileges. The issue was in the UAC mechanism, which presented an option to show information about an executable's certificate, opening the Windows certificate dialog when a user clicks the link. The Issued By field in the General tab is rendered as a hyperlink if the binary is signed with a certificate that has Object Identifier (OID) 1.3.6.1.4.1.311.2.1.10. This OID value is identified in the wintrust.h header as SPC_SP_AGENCY_INFO_OBJID which is the SpcSpAgencyInfo field in the details tab of the certificate dialog. If it is present, a hyperlink included in the field will render in the General tab. This vulnerability can be exploited easily using an old Microsoft-signed executable (hhupd.exe) that contains a certificate with the SpcSpAgencyInfo field populated with a hyperlink.
When we click on the hyperlink, a browser window will launch running as NT AUTHORITY\SYSTEM. Once the browser is opened, it is possible to "break out" of it by leveraging the View page source menu option to launch a cmd.exe or PowerShell.exe console as SYSTEM.
First right click on the hhupd.exe executable and select Run as administrator from the menu.
Next, we go back to the General tab and see that the Issued by field is populated with a hyperlink. Click on it and then click OK, and the certificate dialog will close, and a browser window will launch.
If we open Task Manager, we will see that the browser instance was launched as SYSTEM.
Next, we can right-click anywhere on the web page and choose View page source. Once the page source opens in another tab, right-click again and select Save as, and a Save As dialog box will open.
At this point, we can launch any program we would like as SYSTEM. Type c:\windows\system32\cmd.exe in the file path and hit enter. If all goes to plan, we will have a cmd.exe instance running as SYSTEM.
Microsoft released a patch for this issue in November of 2019. Still, as many organizations fall behind on patching, we should always check for this vulnerability if we gain GUI access to a potentially vulnerable system as a low-privilege user.
This link lists all of the vulnerable Windows Server and Workstation versions.
Scheduled Tasks
We can use the schtasks command to enumerate scheduled tasks on the system.
We can also enumerate scheduled tasks using the Get-ScheduledTask PowerShell cmdlet.
By default, we can only see tasks created by our user and default scheduled tasks that every Windows operating system has. Unfortunately, we cannot list out scheduled tasks created by other users (such as admins) because they are stored in C:\Windows\System32\Tasks, which standard users do not have read access to. It is not uncommon for system administrators to go against security practices and perform actions such as provide read or write access to a folder usually reserved only for administrators. We (though rarely) may encounter a scheduled task that runs as an administrator configured with weak file/folder permissions for any number of reasons. In this case, we may be able to edit the task itself to perform an unintended action or modify a script run by the scheduled task.
User/Computer Description Field
Though more common in Active Directory, it is possible for a sysadmin to store account details (such as a password) in a computer or user's account description field. We can enumerate this quickly for local users using the Get-LocalUser cmdlet.
We can also enumerate the computer description field via PowerShell using the Get-WmiObject cmdlet with the Win32_OperatingSystem class.
Mount VHDX/VMDK
During our enumeration, we will often come across interesting files both locally and on network share drives. We may find passwords, SSH keys or other data that can be used to further our access. The tool Snaffler can help us perform thorough enumeration that we could not otherwise perform by hand. The tool searches for many interesting file types, such as files containing the phrase "pass" in the file name, KeePass database files, SSH keys, web.config files, and many more.
Three specific file types of interest are .vhd, .vhdx, and .vmdk files. These are Virtual Hard Disk, Virtual Hard Disk v2 (both used by Hyper-V), and Virtual Machine Disk (used by VMware). Let's assume that we land on a web server and have had no luck escalating privileges, so we resort to hunting through network shares. We come across a backups share hosting a variety of .VMDK and .VHDX files whose filenames match hostnames in the network. One of these files matches a host that we were unsuccessful in escalating privileges on, but it is key to our assessment because there is an Active Domain admin session. If we can escalate to SYSTEM, we can likely steal the user's NTLM password hash or Kerberos TGT ticket and take over the domain.
If we encounter any of these three files, we have options to mount them on either our local Linux or Windows attack boxes. If we can mount a share from our Linux attack box or copy over one of these files, we can mount them and explore the various operating system files and folders as if we were logged into them using the following commands.
On Windows, we can use Disk Manager
Why do we care about a virtual hard drive (especially Windows)? If we can locate a backup of a live machine, we can access the C:\Windows\System32\Config directory and pull down the SAM, SECURITY and SYSTEM registry hives. We can then use a tool such as secretsdump to extract the password hashes for local users.
Last updated