Lateral Movement & Privilege Escalation
Last updated
Last updated
After pillaging the host DEV01, we found the following set of credentials by dumping LSA secrets:
hporter:Gr8hambino!
The Active Directory Enumeration & Attacks module demonstrates various ways to enumerate AD from a Windows host. Since we've got our hooks deep into DEV01 we can use it as our staging area for launching further attacks. We'll use the reverse shell that we caught on the dmz01 host after exploiting PrintSpoofer for now since it's rather stable. At a later point, we may want to perform some additional "port forwarding gymnastics" and connect via RDP or WinRM, but this shell should be plenty.
We'll use the SharpHound collector to enumerate all possible AD objects and then ingest the data into the BloodHound GUI for review. We can download the executable (though in a real-world assessment, it's best to compile our own tools) and use the handy DNN file manager to upload it to the target. We want to gather as much data as possible and don't have to worry about evasion, so we'll use the -c All flag to use all collection methods.
This will generate a tidy Zip file that we can download via the DNN file management tool again (so convenient!). Next, we can start the neo4j service (sudo neo4j start), type bloodhound to open the GUI tool, and ingest the data.
Searching for our user hporter and selecting First Degree Object Control, we can see that the user has ForceChangePassword rights over the ssmalls user.
As an aside, we can see that all Domain Users have RDP access over the DEV01 host. This means that any user in the domain can RDP in and, if they can escalate privileges, could potentially steal sensitive data such as credentials. This is worth noting as a finding; we can call it Excessive Active Directory Group Privileges and label it medium-risk. If the entire group had local admin rights over a host, it would definitely be a high-risk finding.
We can use PowerView to change the ssmalls user's password. Let's RDP to the target after checking to ensure the port is open. RDP will make it easier for us to interact with the domain via a PowerShell console, though we could still do this via our reverse shell access.
To achieve this, we can use another SSH port forwarding command, this type Local Port Forwarding. The command allows us to pass all RDP traffic to DEV01 through the dmz01 host via local port 13389.
Once this port forward is set up, we can use xfreerdp to connect to the host using drive redirection to transfer files back and forth easily.
We notice that we only get console access as this server does not have the the Desktop Experience role installed, but all we need is a console. We can type net use to view the location of our redirected drive and then transfer the tool over.
Next, type powershell to drop into a PowerShell console, and we can use PowerView to change the ssmalls user's password as follows:
We can switch back to our attack host and confirm that the password was changed successfully. Generally, we would want to avoid this type of activity during a penetration test, but if it's our only path, we should confirm with our client. Most will ask us to proceed so they can see how far the path will take us, but it's always best to ask. We want to, of course, note down any changes like this in our activity log so we can include them in an appendix of our report.
Digging around the host and AD some more, we don't see much of anything useful. BloodHound does not show anything interesting for the ssmalls user. Turning back to the Penetration Tester Path content, we remember that both the Credentialed Enumeration from Windows and the Credentialed Enumeration from Linux sections covered hunting file shares with Snaffler and CrackMapExec respectively. There have been many times on penetration tests where I have had to turn to digging through file shares to find a piece of information, such as a password for a service account or similar. I have often been able to access departmental shares (such as IT) with low privileged credentials due to weak NTFS permissions. Sometimes I can even access shares for some or all users in the target company due to the same issue. Frequently users are unaware that their home drive is a mapped network share and not a local folder on their computer, so they may save all sorts of sensitive data there. File share permissions are very difficult to maintain, especially in large organizations. I have found myself digging through file shares often during penetration tests when I am stuck. I can think of one specific pentest where I had user credentials but was otherwise stuck for a few days and resorted to digging through shares. After a while, I found a web.config file that contained valid credentials for an MSSQL service account. This gave me local admin rights on a SQL server where a Domain Admin was logged in, and it was game over. Other times I have found files containing passwords on user drives that have helped me move forward. Depending on the organization and how their file permissions are set up, there can be a lot to wade through and tons of "noise." A tool like Snaffler can help us navigate that and focus on the most important files and scripts. Let's try that here.
First, let's run Snaffler from our RDP session as the hporter user.
This doesn't turn up anything interesting, so let's re-run our share enumeration as the ssmalls user. Users can often have different permissions, so share enumeration should be considered an iterative process. To avoid having to RDP again, we can use the CrackMapExec spider_plus module to dig around.
This creates a file for us in our /tmp directory so let's look through it.
The file SQL Express Backup.ps1 in the private IT share looks very interesting. Let's download it using smbclient. First, we need to connect.
Checking out the file, we see that it's some sort of backup script with hardcoded credentials for the backupadm, another keyboard walk password. I'm noticing a trend in this organization. Perhaps the same admin set it as the one that set the password we brute-forced with Hydra earlier since this is related to development.
Before trying to use this account somewhere, let's dig around a bit more. There is an interesting .vbs file on the SYSVOL share, which is accessible to all Domain Users.
We can download it once again with smbclient.
Digging through the script we find another set of credentials: account:L337^p@$$w0rD
Checking in BloodHound, we do not find an account user, so this may just be an old password. Based on the year in the script comments, it likely is. We can still add this to our findings regarding sensitive data on file shares and note it down in the credentials section of our project notes. Sometimes we will find old passwords that are still being used for old service accounts that we can use for a password spraying attack.
To cover all our bases, let's check if there are any Kerberoastable users. We can do this via Proxychains using GetUserSPNs.py or PowerView. In our RDP session, we'll load PowerView and enumerate Service Principal Name (SPN) accounts.
There are quite a few. Let's export these to a CSV file for offline processing.
We can download this file via the RDP drive redirection we set up earlier: copy .\ilfreight_spns.csv \\Tsclient\Home. Open up the .csv file using LibreOffice Calc or Excel and pull out the hashes and add them to a file. We can now run them through Hashcat to see if we can crack any and, if so, if they are for privileged accounts.
One hash cracks, but checking in BloodHound, the account does not seem to be helpful to us. We can still note down another finding for Weak Kerberos Authentication Configuration (Kerberoasting) and move on.
Another lateral movement technique worth exploring is Password Spraying. We can use DomainPasswordSpray.ps1 or the Windows version of Kerbrute from the DEV01 host or use Kerbrute from our attack host via Proxychains (all worth playing around with).
We find a valid password for two more users, but neither has interesting access. It's still worth noting down a finding for Weak Active Directory Passwords allowed and moving on.
Let's try a few more things to cover all our bases. We can search the SYSVOL share for Registry.xml files that may contain passwords for users configured with autologon via Group Policy.
This doesn't turn up anything useful. Moving on, we can search for passwords in user Description fields in AD, which is not overly common, but we still see it from time to time (I have even seen Domain and Enterprise Admin account passwords here!).
We find one for the account frontdesk, but this one isn't useful either. It's worth noting that there are many multiple ways to obtain a user account password in this domain, and there is the one host with RDP privileges granted to all Domain Users. Though these accounts do not have any special rights, it would be a client fixing these issues because an attacker often only needs one password to be successful in AD. Here we can note down a finding for Passwords in AD User Description Field and continue onwards.
At this point, we have dug into the domain pretty heavily and have found several sets of credentials but hit a bit of a brick wall. Going back to the basics, we can run a scan to see if any hosts have WinRM enabled and attempt to connect with each set of credentials.
The host 172.16.8.50, or MS01 is the only one left that we haven't gotten into aside from the Domain Controller, so let's give it a try using evil-winrm and the credentials for the backupadm user.
It works, and we're in!
At this point, we could use this evil-winrm shell to further enumerate the domain with a tool such as PowerView. Keep in mind that we'll need to use a PSCredential object to perform enumeration from this shell due to the Kerberos "Double Hop" problem ( Active Directory Enumeration & Attacks). Practice this technique and see what other AD enumeration tools you may be able to use in this way.
Back to the task at hand. Our user is not a local admin, and whoami /priv does not turn up any useful privileges. Looking through the Windows Privilege Escalation (Windows Privilege Escalation) module, we don't find much interesting so let's hunt for credentials. After some digging around, we find an unattend.xml file leftover from a previous installation.
Let's check to see if it contains any passwords, as they sometimes do.
We find credentials for the local user ilfserveradm, with the password Sys26Admin.
This isn't a domain user, but it's interesting that this user has Remote Desktop access but is not a member of the local admins group. Let's RDP in and see what we can do. After RDPing in and performing additional enumeration, we find some non-standard software installed in the C:\Program Files (x86)\SysaxAutomation directory. A quick search yields this local privilege escalation exploit. According to the write-up, this Sysax Scheduled Service runs as the local SYSTEM account and allows users to create and run backup jobs. If the option to run as a user is removed, it will default to running the task as the SYSTEM account. Let's test it out!
First, create a file called pwn.bat in C:\Users\ilfserveradm\Documents containing the line net localgroup administrators ilfserveradm /add to add our user to the local admins group (sometime we'd need to clean up and note down in our report appendices). Next, we can perform the following steps:
Open C:\Program Files (x86)\SysaxAutomation\sysaxschedscp.exe
Select Setup Scheduled/Triggered Tasks
Add task (Triggered)
Update folder to monitor to be C:\Users\ilfserveradm\Documents
Check Run task if a file is added to the monitor folder or subfolder(s)
Choose Run any other Program and choose C:\Users\ilfserveradm\Documents\pwn.bat
Uncheck Login as the following user to run task
Click Finish and then Save
Finally, to trigger the task, create a new .txt file in the C:\Users\ilfserveradm\Documents directory. We can check and see that the ilfserveradm user was added to the Administrators group.
Next, we'll perform some post-exploitation on the MS01 host. We do see a couple of interesting files in the root of the c:\ drive named budget_data.xlsx and Inlanefreight.kdbx that would be worth looking into and potentially reporting to the client if they are not in their intended location. Next, we can use Mimikatz, elevate to an NT AUTHORITY\SYSTEM token and dump LSA secrets.
We find a set password but no associated username. This appears to be for an account configured with autologon, so we can query the Registry to find the username.
Now we have a new credential pair: mssqladm:DBAilfreight1!.
Before we move on, let's check for any other credentials. We see Firefox installed, so we can grab the LaZagne tool to try to dump any credentials saved in the browser. No luck, but always worth a check.
It's also worth running Inveigh once we have local admin on a host to see if we can obtain password hashes for any users.
We've now enumerated the domain inside and out, moved laterally, and pillaged what we could find on the target hosts. At this point, we have credentials for the mssqladm user and can continue hunting a path to domain compromise.
To recap, we dug through the Active Directory environment and obtained the following credential pair:
mssqladm:DBAilfreight1!
Digging into the BloodHound data we see that we have GenericWrite over the ttimmons user. Using this we can set a fake SPN on the ttimmons account and perform a targeted Kerberoasting attack. If this user is using a weak password then we can crack it and proceed onwards.
Let's go back to the DEV01 machine where we had loaded PowerView. We can create a PSCredential object to be able to run commands as the mssqladm user without having to RDP again.
Next we'll use Set-DomainObject to set a fake SPN on the target account. We'll create an SPN named acmetesting/LEGIT which we'll of course delete later and note in the appendices of our report.
Next we can go back to our attack host and use GetUserSPNs.py to perform a targeted Keberoasting attack.
Next we'll fire up Hashcat and see if the user is using a weak password.
They are! Now we have yet another credential pair, time for the ttimmons user. Let's check and see what type of access this user has. Looking in BloodHound again we see that we have GenericAll over the SERVER ADMINS group.
Looking a bit further we see that the SERVER ADMINS group has the ability to perform the DCSync attack to obtain NTLM password hashes for any users in the domain.
We use abuse this by first adding the ttimmons user to the group. First we'll need to create another PSCredential object.
Once this is done, we can add the user to the target group and inherit the DCSync privileges.
Finally, we can use Secretsdump to DCSync all NTLM password hashes from the Domain Controller.
After making sure to document all of our steps we could perform a number of actions, many of which are detailed in the next section. Its definitely a good idea to dump the entire NTDS database and perform offline password cracking to give the client an idea of their overall password strength and other metrics. You could also show evidence of being able to authenticate to a Domain Controller and running a few commands as this may drive the point home more than seeing secretsdump output, which they may not be familiar with. Connecting to the Domain Controller via RDP and including a screenshot to the report showing a console open with the results of the hostname, whoami, and ipconfig /all commands can be a great visual. There is also a lot of extra value we can add after Domain Admin by performing additional audit steps of AD, attacking domain and forest trusts (if in scope) and, finally, testing the client's alerting by either creating a new Domain Admin and Enterprise Admin or adding an account we control into each of these groups. Ideally they are monitoring these highly privileged groups and will catch this and either manually, or, even better, have something automated in place to remove the accounts from the groups. If you do this definitely include this action in the report as a configuration change in the appendices and also give the client kudos if they do detect it and action it appropriately. Giving credit for the good things you see in the network/the client does is important and goes a long way towards building good will.
Once we've compromised the domain, depending on the assessment type, our work is not over. There are many things we can do to add additional value to our clients. If the goal of the assessment was to reach Domain Admin and nothing further, then we are done and should make sure we have all of our command/log output, scan data, and screenshots and continue drafting the report. If the assessment was goal focused (i.e., gain access to a specific database) we should continue working towards that goal. Domain Admin rights may be just the start as there could be other networks, domains, or forests in play that we will need to find our way into. If the assessment is more open ended and the client asked us to demonstrate as much impact as possible there are quite a few things we can do to add value and help them improve their security posture.
After we have dumped the NTDS database we can perform offline password cracking with Hashcat. Once we've exhausted all possible rules and wordlists on our cracking rig we should use a tool such as DPAT to perform a domain password analysis. This can nicely compliment findings such as Weak Active Directory Passwords Allowed, which we noted down after a successful password spraying attack earlier. This analysis can help drive the point home and can be a power visual. Our analysis can be included in the appendices of the report with metrics such as:
Number of password hashes obtained
Number of password hashes cracked
Percent of password hashes cracked
Top 10 passwords
Password length breakdown
Number of Domain Admin passwords cracked
Number of Enterprise Admin passwords cracked
As discussed in the Active Directory Enumeration & Attacks module, we can provide extra value to our clients by digging deeper into Active Directory and finding best practice recommendations and delivering them in the appendices of our report. The tool PingCastle is excellent for auditing the overall security posture of the domain and we can pull many different items from the report it generates to give our client recommendations on additional ways they can harden their AD environment. This type of "above and beyond the call of duty" work can build good will with our customers and lead to both repeat business and referrals. Its a great way to set ourselves apart and demonstrate the risks that plague AD environments and show our deep understanding of the client's network.
Once we've gained access to the Domain Controller we can likely access most any resources in the domain. If we want to demonstrate impact for our clients a good spot to start is going back to the file shares to see what other types of data we can now view. As discussed in the Documentation & Reporting module, we should make sure to just take screenshots showing a file listing if we find a particularly sensitive file share, and not open individual files and take screenshots or remove any files from the network.
Let's go back to the Department Shares share and see what else we can find.
Depending on the client industry and business, there are various things we can go after to demonstrate impact. HR data such as salaries and bonuses should be well-protected, R&D information could potentially hurt a company if it is leaked so they should have extra controls in place. It can be a good practice to not allow Domain Admins to have blanket access to all data, because if one account is compromised then everything will be. Some companies will have a separate site or non-domain joined file share or backup server to house sensitive data. In our case Inlanefreight has asked us to test if we can gain access to any hosts in the 172.16.9.0/23 subnet. This is their management network and houses sensitive servers that should be not directly accessible from hosts in the principal domain and gaining Domain Admin rights should not lead to immediate access.
Within the private IT share we can see two subdirectories: Development and Networking. The Development subdirectory houses the backup script that we obtained earlier. Let's take a look in the Networking subdirectory.
We can see SSH private keys for three different users. This is interesting.
Can any of these users be leveraged to access a host in the protected network?
Looking at the network adapters on the Domain Controllers we can see that it has a second NIC in the 172.16.9.0 network.
Typing arp -a to view the arp table does not yield anything interesting. We can use PowerShell to perform a ping sweep and attempt to identify live hosts.
We can see one live host, 172.16.9.25, that perhaps one of the SSH private keys will work against. Let's get to work. First download the SSH keys via our evil-winrm connection to the Domain Controller.
Now there are a few ways to do this next part, we'll take the long route so we can ultimately SSH directly into the 172.16.9.25 host from our attack box, performing a bit of a mindbending double pivot in the process. Here is what we are trying to achieve, starting from our attack host and pivoting through the dmz01 and DC01 hosts to be able to SSH directly into the MGMT01 host two hops away directly from our attack host.
Attack host --> dmz01 --> DC01 --> MGMT01
We'll need to establish a reverse shell from the dmz01 box back to our attack host. We can do this the same we way did in the Internal Information Gathering section, creating an ELF payload, uploading it to the target and executing it to catch a shell. Start by creating the ELF payload and uploading it back to the dmz01 host via SCP if you removed it.
Next, set up the Metasploit exploit/multi/handler.
Once again, execute the shell.elf file on the target system:
Catch the Meterpreter shell using the multi/handler.
Next, set up a local port forwarding rule to forward all traffic destined to port 1234 on dmz01 to port 8443 on our attack host.
Next, create an executable payload that we'll upload to the Domain Controller host.
Upload the payload to the DC.
Background the Meterpreter session
Start another multi/handler in the same msfconsole session to catch the shell from the DC.
Execute the payload on the DC and, if all goes to plan, we'll catch it in our handler.
Checking on our handler and we see the incoming connection. It appears to come from 0.0.0.0 because our port forwarding rule set earlier has specified that all traffic destined for our host on port 1234 should be directed to (our listener) on port 8443.
For our next trick we'll set up a route to the 172.16.9.0/23 subnet.
We can confirm this by checking the MSF routing table.
Now we need to set up a socks proxy which is the final step before we can communicate directly with the 172.16.9.0/23 network from our attack host.
Edit the /etc/proxychains.conf file to use port 9050 that we specified above. If you already have a line in there from earlier, comment it out or replace the port number.
Now we can test this out by running Nmap against the target, and we confirm that we are able to scan it.
Finally, we can try each SSH key with proxychains to attempt to connect to the host. We can collect each username by the SSH key filename. In our case the key for ssmallsadm works (don't forget to chmod 600 the file or we won't be able to connect).
As a final step we'll enumerate the target system, checking for local privilege escalation opportunities. If we can get root-level access we'll have fulfilled the client's main goal, as they stated that this server holds their "crown jewels", or most important data. During our enumeration we do a Google search based off of the Kernel version and see that it's likely vulnerable to the DirtyPipe, CVE-2022-0847. We can read an excellent explanation of this vulnerability on the Hack The Box blog.
We'll use exploit-2 from this GitHub repo. Since we have SSH access to the system, we can create a file with Vim and paste the exploit code in. We then must compile it, and luckily gcc is present on the system.
We must run the exploit against a SUID binary to inject and overwrite memory in a root process. So first we need to search SUID binaries on the system.
Finally, we'll run the exploit against the /usr/lib/openssh/ssh-keysign SUID binary and drop into a root shell.
From here we could perform post-exploitation of the file system to prove the level of access we achieved.
Some clients may want to test their Data Loss Prevention (DLP) capabilities, so we could experiment with various ways to exfiltrate mock data from their network to see if we are detected. We should work with the client to understand what types of data they are trying to protect and proceed accordingly. It's best to use mock data so we don't have to deal with any highly sensitive client data on our testing system.
If there are any domain trusts we could use our skills to enumerate these relationships and exploit either a child --> parent trust relationship, intra-forest trust, or an external forest trust. Before doing so, we should check with the client to make sure the target domain is in scope for testing. Sometimes we'll compromise a less import domain and be able to use this access to fully take over the principal domain. This can provide a lot of value to the client as they may have set up trust relationships hastily as the result of a merger & acquisition or connecting to some other organization. Their domain may be well-hardened, but what if we are able to Kerberoast across a forest trust, compromise a partner forest, and then find an account in the partner forest that has full admin rights in our current domain. In this situation we could demonstrate to our client that the main weakness isn't in the domain we are testing in but another so they can proceed accordingly.
This section showed a sampling of the things we can do AFTER achieving Domain Admin in a client environment. Showing up, pwning the client and showing off how fast you got DA does no good for the client and does not help you and your firm retain clients and spread a solid reputation around. What we do after achieving Domain Admin is extremely important and this is where we can set ourselves apart from other testers who just run Responder, a few other tools and scripts, a Nessus scan, and issue a stock report and call it a day. Your report deliverable should demonstrate the worth of the penetration test your client is paying for and we can make sure they are happy and come back in the following years if we go above and beyond. This is not always possible due to contract restrictions and time-boxed assessments, but even if we can provide a little extra we're ahead of the pack. Keep in mind that the things we identify in our report can impact a client's funding for the following year and that funding likely includes penetration tests. We don't want to inflate the report with nonsensical findings, of course, but we can often identify many things that our client had never even considered and they and you will be better for it.
