159. Escalating Privileges (OBJ 3.7)
In this lesson, we’re going to talk about escalating privileges, which is something an attacker tries to do once they exploit a target system or network. This is known as privilege escalation. Simply put, privilege escalation is the practice of exploiting flaws in an operating system or other application to gain a greater level of access than was intended for the user application. This is important because often the initial intrusion vector is going to be something like a phishing campaign.
For example, if I can get a user to click on a link in my phishing campaign, they’re going to be able to let me into that system or application and I can actually start taking over their account, but that’s only going to be the account of a regular user. It’s not going to be strong enough for me to do some of the things that I want to do, and so, as an attacker or penetration tester, I’m going to try to escalate my privileges to be able to get to root on a Linux system or admin on a Windows system. When it comes to privilege escalation, we have horizontal privilege escalation and vertical privilege escalation.
Horizontal privilege escalation is focused on obtaining access to a regular user account of a different privilege level than the one currently in use. For example, if somebody was able to get access to my workstation using my user account, they could attempt to conduct horizontal privilege escalation to gain access to another user who also uses that system, and that way, they can access that user’s private resources. Since that user is also a standard user like me, this is considered horizontal privilege escalation. Conversely though, an attacker might try to use vertical privilege escalation to gain additional access rights too. With vertical privilege escalation, the attacker is trying to obtain access to an account of higher privileges than the one they currently have access to. For example, if the attacker was able to gain access to my regular user account known as Jason, they might try to vertically escalate their permissions to my administrative account known as Jason.admin.
This way, they can install software on that workstation as well. This is a higher level of permissions than a regular user would have, so they’re trying to get an administrative account, a root account or a system-level account using vertical privilege escalation techniques. Now let’s take a look at some privilege escalation techniques in both Linux and Windows. For Linux, when we talk about privilege escalation, we want to talk about the concept of how a user can run a program or process as a different user with additional permissions. When programs are run by default, they’re run out at the least privilege, or ring 3 layer. There are superusers, who are in ring 2, and then you have root users, who might be in ring 1, and as you get closer and closer down to the kernel, which is ring 0, that is the highest level of privilege, and so we want to work from an application to a device driver all the way down into the kernel and run our programs with as much privilege as possible because then we can have the most control. How can we do that inside of Linux? One of the ways that a user or an attacker can take advantage of a Linux system to be able to run things as a different user with higher permissions is by taking advantage of the SUID and the SGID. SUID is the set-user identification. In the white box, that’s the first column of ss with the red arrow pointing over it.
The SGID is the set-group identification, which is the second red arrow pointing to that s. The s in the permissions indicates that the program can be run as the user or group. If it’s the SUID column, the SUID column, that means that it can be run as that user. If it’s in the right column, like the top one is, you can see that tells us that we can run it as the group. For example, the top program, it is the password program. It allows somebody to change their password for their account. This can be run from a normal user as the root user because of the first s, the first column, which is the SUID, and it can also be run as the system, as the system group, because of that s in the second column, which is the SGID. The su program, or superuser program, does not have that capability. It only has an s in the SUID column, the SUID column, the first one, and so the superuser program will allow a normal user to execute the superuser program and run programs as the root user but not as the user group.
That’s the way this works and this can allow a program to be used for privilege escalation. If you want to find any applications that you can run as root on a Linux system, just open up your terminal and type in sudo find / dash perm dash 04000 and this will locate anything that has the SUID bit set. The next one we have is sticky bit. This is used for share folders like the temp directory. Users are allowed to create files, read and execute files owned by other users if the sticky bit is set.
The attacker cannot remove files owned by other users though, and so how do you know if a sticky bit has been set? If you look at the bottom here, with the superuser command, you’ll see that dash t. That is the sticky bit and that has been set for the superuser program but has not been set for the password program. Additionally, as you’re looking through shared folders, you should be looking for sensitive information that may be shared using Samba with Windows systems or inside of a Linux system. It’s very common for these type of shared folders and files to have very few or no restrictions. To be able to find these, you can use tools like enum4linux or using Metasploit modules like the auxiliary scanner for smb_enumshares. The next one we have is unsecure sudo. Sudo is superuser do command, is a program in Unix and Linux systems.
This allows users to run programs with the privileges of a different user. By default, if you just type in sudo and a command, it will run as root, but you could do sudo as some other user and a command if you wanted to. This works a lot like the run as administrator command you may be familiar with on a Windows system. Here, for example, I have somebody who is trying to do a removing of files. Sudo, execute this as the root user, rm, remove files, *.*, all the files, dash rf, which means recursively through all the folders, and so if I type this from the root directory of a Linux machine, it’s going to delete everything on the hard drive. That would be a really, really bad day, right? That would be very destructive, so don’t run this on your Linux machine, but that’s what that command is doing. It’s running it as the superuser, root, so that it has access to eliminate everything that it can on that Unix or Linux system. The next one we have is ret2libc, which stands for return to library C. This is an attack technique that relies on overwriting the program stack to create a new stack frame that calls the system function. Here on the left side, we have the stack of the programs that are being run.
We have the system, we have the return address, and then the pointer to a shell, and that return address, when it gets there, is going to push over to this return library and be able to run it. For the exam, I just want you to remember that if you see ret2libc, that is a privilege escalation attack to be able to be used inside of Linux. Other common privilege escalation attacks on Linux include going after the password or shadow files by obtaining a copy of those files and then cracking the root or privileged user passwords, as well as going after weak process permissions that will allow you to go and inject malicious code into those processes, or the ability to compromise a user application that is missing a security patch or plugin, something like OpenOffice, VNC, SSH, or any other tool on a Linux system that is missing a security patch. Additionally, you can go after services, and any service that’s running as root could be exploited so you can take control of that service and then have root permissions. To figure this out, you can go and look at all the processes owned by a particular user, such as ps dash x to find all the processes owned by you.
If you type in ps dash fU root, this will show you all the processes owned by the root user. Once you’ve identified those processes, you could try to find a weakness in there to take over or inject code into those processes and that will give you escalated privileges as the root user. Another area to look at on a Linux system is CronJobs. Anytime you find CronJobs, these are essentially scheduled tasks. If somebody has a CronJob that is scheduled and you can exploit that CronJob by putting malicious code into it, anytime the CronJob or scheduled task gets run, it’s going to run your malicious code as well. This is another common attack used in Linux to be able to escalate your privileges. All right, let’s go ahead and take a look at some Windows privilege escalation techniques now. In Windows, the first one we have is what’s called Cpassword. This is the name of an attribute that stores the passwords inside of a Group Policy preference item inside the Windows server. This is stored inside the SYSVOL folder on the domain controller in an encrypted XML file, but if you can get a copy of that file, it is easily decrypted by any authenticated user in the domain, and so you can see here is a PowerShell command called Get-DecryptedCpassword. You’ll put in that encrypted password, as you can see here, and it will immediately give you back the password, so it is not a very strong form of encryption, and so if you’re already on the domain as a regular user, this is a great way to try to capture that file or capture that username you need and password and then be able to decrypt it and use it yourself. Next, we have clear text credentials in LDAP, or LDAP. LDAP, if it’s not SSL enabled, is going to pass the credentials across the network in clear text, so if you have a sniffer set up, you’re going to be able to capture that data as it’s going across the network. This use of insecure LDAP binding is something that is very, very troublesome, and so there’s actually a PowerShell script that allows you to check for it. If you use this, it will actually run a script across your network and see if you have secure or insecure LDAP. If there’s insecure LDAP, you’ll be able to grab the results of that with a CSV file and see which accounts are vulnerable. In the example here, you’ll see I have two that are vulnerable. I have the Administrator account and the password is Simple. It was able to find it, grab it and give it to me, both on the local host as well as on its network address of 10.0.0.3, and so this is a very easy way to grab credentials very quickly if people are not securing their LDAP servers.
Next, we have Kerberoasting, which is a way to mess with the Kerberos ticketing system. This allows any domain user account that has a service principal name to set a service granting ticket, or a TGS. The tickets can be requested by any user in the domain and allows for offline cracking of the service account plain text password, and so Kerberoasting is a technique that you can use to really start grabbing those passwords, and if you can get that service account password, remember, service accounts tend to operate at ring 1 or ring 2, so they’re definitely lower down than the user, and so you can do a lot of damage with these things and gain yourself some good persistence.
Next, we have credentials in the LSASS, or LSASS, which is your Local Security Authority Subsystem Service. This is a process in Windows that enforces the security policy of a system, and so when a user tries to log into a computer, this is the verification that that user is authorized to get on that computer, and so this is where you also use it for password changes and it creates your access tokens by getting you ticket granting tickets or ticket granting service tickets, depending on what you need for Kerberos. All of that is handled by this LSASS service and so the credentials are stored in LSASS as well. If you can get a copy of those and you can decrypt them, you can now have usernames and passwords that you can use for privilege escalation. Next, we have the SAM database.
The SAM database is your Security Account Manager. That is a database file that stores the usernames and passwords in Windows as an LM hash or an LTLM hash. This is usually used on local machines as opposed to using it on a large Active Directory domain, but if you have backwards compatibility enabled, this will still be stored there too. Usually you’ll find this in the %SystemRoot%/system32/config folder called the SAM. This file is used to authenticate local users and remote users who are connecting to that machine, and these passwords can be taken offline and cracked if you get them. For example, here, I used a Meterpreter session and I did what’s called a hashdump, which dumps the SAM’s database to my screen. I can then take that Administrator account and that long hash of that, put that into something like crackstation.net and quickly get the password for that Administrator account, breaking into the network.
As you can see, there are lots of different ways to conduct credential attacks as a form of privilege escalation on a Windows system. Next, we have DLL hijacking. This is a dynamic link library that provides a method for code sharing and allows a program to upgrade its functionality over time without having to relink or recompile an application, so it’s just a library that you can reference over and over and over again. That is great from a software development perspective. Unfortunately, attackers have learned how to hijack those libraries and they’ll load a malicious DLL in place of the acceptable DLL, so instead, when the software, like Microsoft Word, tries to call that DLL, they’re actually calling the malware.
This is commonly used with malware to achieve persistence on a victim machine because every time somebody runs a program that calls that DLL, it loads that malware backup and it might initiate a reverse shell, for example, back to you as the pen tester. That being said, you can also use DLL hijacking to elevate privileges by exploiting weak folder permissions, unquoted service paths or applications that are running from network shares and this will replace the legitimate DLLs with malicious ones that give you additional privileges. Next, we have exploitable services. This is when an attacker uses the way that services normally operate to cause unintended programs to operate instead. For example, an unquoted path can be used in a file system call.
In Windows, it now supports spaces in file names, and so if there is a folder on my C drive called Dion and there’s two folders under that, one called My and one called MyFiles, and in each of those, I have server.exe, they both could be run depending on how I call it, and so if I am taking advantage of the fact that there’s that space there and that Windows doesn’t parse that space properly because I didn’t put quotes around it, instead, the malicious file on the bottom will be run. This is something that you can exploit the way that the program is normally supposed to operate to get it to do what you want. You can also do this with writeable services, something like PSExec. A service can be replaced with a custom service that will also run a command shell and give you a reverse shell so you can attack that system.
There are lots of ways to do this kind of stuff. It just depends on how creative you want to get as an attacker. Next, we have unsecure file and folder permissions. Older versions of Windows would allow administrators to have access over everything on the computer, including all non-admin users’ files and folders. Now with the newer versions of Windows, there are some protections have been put in place, but again, depending on what’s being run on that network, this can be something that you can attack. You can allow this to get DLL hijacking to occur by putting in corrupted DLLs in place of known good ones. You can install malicious files under a user so then that non-admin user is then targeted and runs those systems on their local machine.
You might be able to get it onto their profile, and if they’re using roaming profiles in the organization, that malware now travels with them from system to system as they log in. This can be something that’s useful if somebody hasn’t secured down the file and folder permissions adequately. Next, we have a keylogger. What’s a keylogger? It is a surveillance technology used to monitor and record the keystrokes of a victim user. These can be software based or a hardware dongle that’s connected between the USB keyboard and the back of the machine. Either way, it can capture this data into a text file and send it back to the attacker. On the screen, this is an example of the output of a software keylogger. You can see every time somebody typed in something, like what path they wanted to go to, their usernames, their passwords, the emails, all of that was captured and sent back to the attacker who can analyze it and then use that to get additional privileges because they now have more usernames and passwords. Now we’re going to talk about the privilege escalation techniques that are common to both operating systems. The first one is kernel exploits. If you have an unpatched operating system, like Windows or Linux, it is vulnerable to many different exploits.
Again, you’re going to go ahead and search the Common Vulnerability and Exposure database for that version of Windows or Linux. Once you find that, it’s going to tell you which ones have known exploits and you can then use those techniques to exploit that system. If you’re using Metasploit, it has a library of a lot of existing exploits. For example, here you can see there are over 1,600 exploits currently loaded in this version of Metasploit Framework that I can use.
Not all 1,600 are going to apply to a Linux or Windows system that you’re targeting, but there’s probably at least a couple that will be able to be used, and so you need to be able to match up those vulnerabilities to those exploits to gain your foothold into the network and then escalate privileges from there. Another common privilege escalation technique used in Windows is one that involves going after user applications and compromising them. Just like we talked about in Linux, you can go after applications in the Windows operating system, like Microsoft Word or PowerPoint or Excel or even Google Chrome or other applications that are on that system.
Any application that is installed on a Windows system can be compromised and that can give you user-level permissions and then you can conduct privilege escalation from there. Additionally, when you’re dealing with Windows systems, you can attempt to bypass local UAC, or User Access Control. One of the ways to bypass local UAC is to use process injection to leverage a trusted publisher certificate to able to gain access to those higher-level permissions instead of being blocked by UAC. Also, just like in Linux, you can find processes inside of Windows that have weak controls and this can allow you to inject malicious code into those processes to able to escalate your privileges to the system level or to the administrative level. Next, we have default account settings.
Again, sometimes administrators are lazy, and if they leave a default admin account that can be exploited with a username and password that’s been known to everyone, that’s a good thing for you as an attacker but a bad thing for the organization. Also, guest accounts should be disabled, but sometimes they are enabled by default, and so when you get a brand new system that’s installed, that guest account is there, waiting for you to take over, and if someone forgot to disable it, that’s another way for you to get into the system. As you can see, there are lots of different techniques you can use to escalate your privileges, both vertically and horizontally against Windows and Linux systems.
160. Upgrading Restrictive Shells (OBJ 3.7)
In this lesson, we’re going to talk about upgrading restrictive shells. Sometimes, when you first gain access to a network through an exploit, you’re going to be inside of a restricted shell or a non-interactive shell. If you find yourself in either of these, you need to find a way to get out of them. Now, what exactly is a restrictive shell? Now, a restrictive shell is a shell where you might be confined from being able to do certain functions, for example, you might not be able to change directories, you might not be able to use certain commands, you might have your output being redirected to a garbage file instead of back to you, so you can see the results of the commands you’re running.
All of these are things that are considered a restrictive shell, or even possibly a non-interactive shell, where you can send commands, but you can’t get any response and have it as a two-way conversation. So, in this lesson, we’re going to talk about how you can upgrade from a restrictive shell, or from a non-interactive shell, into one that’s more usable for you. First, let’s talk about what you do if you find yourself inside of a restrictive shell inside of a Linux target. Now, if you’re in a Linux target, there are lots of things you can do to be able to upgrade your restrictive shell.
You can use Python if it’s already installed on that server by typing python -c ‘import pty; pty.spawn(“/bin/bash”)’, this will allow you to import the PTY terminal, which is the way you can interact with something, and then spawn a new shell using the bin/bash command. This is a way of using Python to launch a bash shell, and now you’ll have a fully interactive bash shell. Another technique to do something similar is if they’re using Perl on that system. To do this within Perl, simply type in perl -e ‘exec”/bin/sh”;’, this will then execute the command bin/sh, which would launch a fully interactive shell. Similarly, you can change this from bin/sh to bin/zsh if you want a Z shell. If you want a C shell, you can use that, if you want to use bash, you can use that. Really, the point is that you can launch any of these type of interactive shells using commands from Python or Perl to be able to execute those, and give you a full interactive shell that is no longer restrictive. Now, if you look and there is no Python or Perl installed on that Linux server, you can instead use VI, which is installed on almost every version of Linux by default. Now, VI is normally a text editor, but VI can also run commands.
So, if you enter the VI environment, and then type in set shell=/bin/sh, and then type in shell, this will launch a fully interactive shell within the VI environment for you to utilize. The idea here is that you can really use any programing language, or any kind of scripting commands, to be able to launch an interactive shell by bringing up a full shell environment inside of Linux. Now, for Windows systems, the same type of restricted environments don’t really exist, instead, you’re either going to be in the Command Prompt or the PowerShell environment, or you’re going to be blocked from both of these. Now, if this happens to you, you’re going to have to come up with some kind of a creative way to launch a shell from these restricted environments. For example, there is a Shell Pack zip file that contains compiled and ready-to-use shells for bypassing AppLocker, GPO, and SRP restrictions inside of Windows environments that will allow you to run them from the Command Prompt if you can’t get into the full PowerShell environment, this includes things like Nopowershell, NPS, PowerLine, PowerOPS, and others. If you want to try these out on your own, you can find these located in the GitHub for InfosecMatter. The final type of shell I want to cover is a non-interactive shell.
Now, a non-interactive shell is one where the typical shell commands are not going to work for you. For instance, you can’t use the Up Arrow to display the history, you can’t use Tab for autocomplete, and sometimes, you’re not even getting a fully interactive shell, in the case of when you put in something like ls, you won’t see the response that comes back. In this case, you may be operating in the blind. If you find yourself in one of these type of situations, you may want to try to install a different shell for you to utilize.
For example, if you found yourself exploiting a Linux system, you can then enter a command like /bin/bash -i, which will then spawn a new interactive shell using the bash shell, instead of the non-interactive shell you’re currently inside of. If you’re on a Linux or Windows system, you can use the non-interactive shell and operate in the blind, where you’re putting information in, but not seeing the results. In these cases, you can actually enter different commands to create a script, then run that script to be able to create a reverse shell back to your system, or be able to open up some form of an interactive terminal, whether that’s the Command Prompt, PowerShell, or a bash shell in the case of Linux. Additionally, you can use this in the blind method to download files from a server you control that might be able to load something like a Meterpreter script, and then you can start running Meterpreter as your interactive shell, instead of relying on the Command Prompt, PowerShell, or a bash shell.
