Vulnlab - Heron
Heron is a medium-difficulty lab. The scenario assumes an initial compromise on a Linux machine attached to a domain, requiring a pivot to a domain controller in an attempt to compromise it.
Enumeration
Let’s start with the usual Nmap scan:
The scan shows that 10.10.168.69 has no accessible ports, probably due to a firewall. On the other hand, 10.10.168.70 has port 22 open. This suggests that we should start by connecting to the Linux machine via SSH.
The Wiki page tells us that this is a supposed compromise scenario. Heron Corp provides us with login credentials for the penetration test:
SOCKS proxy to DC
As mentioned above, the first step is to examine the Linux machine attached to the domain and identify ways of gaining root access. Once root access has been obtained, we should be able to use the machine account and the /etc/krb5.keytab file (containing the NTLM hash of the machine account) to compromise the domain controller.
Having explored the machine’s files, I notice that there’s not much to exploit. We have no access to other users and no binary is exploitable as the pentest user. On the other hand, we can retrieve the names of two users from directories in the /home folder:
Since we have these two users, we can attempt an ASREPRoasting attack to try and obtain their password hash if pre-authentication is not active on these accounts.
As we don’t have direct access to the domain controller, we first need to set up a proxy. To do this, there are several methods available (ligolo, revsocks) but here the easiest way is to do it via ssh with the following command:
1 | ssh [email protected] -D 1080 |
This command redirects traffic from port 1080 on our local machine to 10.10.168.70.
Then, using proxychains, we can interact with the DC:
Next, I tried to run an nmap scan with proxychains to identify the ports open on the DC, but this took far too long. So I decided to enumerate the DC directly, passing through the linux machine and using the fscan tool:
This enabled me to identify a web service on the DC. By accessing it with the proxy, we can identify other domain accounts:
Then I made a list of subdomains to make sure I didn’t miss anything:
But you need to be authenticated to access this subdomain, so it’s not usable at the moment.
ASREPRoasting
Using the recovered users, we can perform ASREPRoasting with impacket :
1 | proxychains -q impacket-GetNPUsers heron.vl/ -no-pass -usersfile users -dc-ip 10.10.168.69 -request |
We then manage to recover the password hash of the samuel.davies account:
Which we manage to break with rockyou :
Domain listing
With the recovered account, we can use bloodhoun to enumerate the domain via proxychains. Unfortunately, the account we’ve retrieved doesn’t have any special rights, but we can see that the SVC-WEB-ACCOUNTIG account has an SPN and that it has GenericWrite rights on the linux machine:
On the other hand, it is not possible to retrieve the password for the SVC-WEB-ACCOUNTING account after kerberoasting and trying to break it with rockyou.
SMB share enumeration
Using smbclient with samuel.davies’ credentials, we can list the shares accessible on the dc:
You can then retrieve a gpp password using the dedicated module on nxc :
Spray this password on the user list to compromise the svc-web-accounting-d account
Note that this account has write-once rights on the dc accounting share:
Access to accounting application
A list of files in the accountig directory reveals the libraries and files used by the application:
In particular, you can modify the web.config file, which defines the libraries and executables launched when the application is run. To do this, change the file as follows:
1 | <?xml version="1.0" encoding="utf-8"?> |
By accessing the application’s /execute.now path, you can obtain a reverse shell:
Search for passwords on the DC
Once you’ve obtained a shell, you can browse the various DC files. An unusual feature is a scripts folder in C:\Windows. In the latter, we discover a file ssh.ps1 containing the credentials for the _local account used to connect to frajmp via ssh:
Extract secrets from linux machine
With the _local account, you can easily gain root access:
By becoming root, you can then retrieve the krb5.keytab file and recover the machine account hash with the keytabextract.py tool:
By spraying the password recovered above, you can also compromise the julian.pratt account
You can then access julian.pratt’s directory on the DC :
We can see that the latter seems to use the lnk files to automatically connect to Putty. So, by downloading these and displaying them, we can retrieve the password adm_prju :
You can then spray it to check that it is not being used by another user:
RBCD attack
With bloodhound, we learn that adm_prju has write access to MUCDC$.
This right can be exploited to perform an RBCD attack. To cut a long story short, we’re going to add a machine (in this case, the Linux machine) to the list of trusted DC machines, enabling it to authenticate itself to the DC, pretending to be any user on the domain.
To do this, we use impacket-rbcd :
1 | proxychains -q impacket-rbcd heron.vl/adm_prju:ayDMWV929N9wAiB4 -delegate-to 'MUCDC$' -delegate-from 'FRAJMP$' -dc-ip 10.10.168.69 -action write |
Next, you can retrieve a service ticket from the DC as _admin :
1 | proxychains -q impacket-getST heron.vl/'FRAJMP$' -impersonate _admin -hashes :6f55b3b443ef192c804b2ae98e8254f7 -spn 'cifs/mucdc.heron.vl' |
For this to work, a spn must be specified, as this attack allows us to retrieve a service ticket. As DC shares are accessible, we can retrieve a ticket from the SMB cifs (Common Internet File System) service, which allows access to SMB shares.
We can then use the ticket after caching it on our machine with the command :
1 | export KRB5CCNAME=_admin@[email protected] |
If the ticket was for a machine account, you’d have to change the name, as the $ can cause caching problems.
Finally, with nxc, you can use this ticket with the following command:
1 | proxychains -q nxc smb ips --use-kcache |
This allows us to compromise the DC and retrieve the NTDS database: