Skip to main content
Background Image

Arasaka - Hack Smarter

·661 words·4 mins
Brady McLaughlin
Author
Brady McLaughlin

This is a write-up for the easy-difficulty “Arasaka” machine from Hack Smarter’s new lab platform. This room is located at courses.hacksmarter.org and is available on a “pay what you can” basis as of the time of writing. I am documenting the process I used to find all information in this writeup WITHOUT including any flags, in the spirit of the game. However, following this process exactly should result in a full compromise of the target system.


Recon, Scanning, and Enumeration
#

My first step was to ping the box to ensure that it was alive and ready for enumeration.

Next, I ran a quick nmap scan to see which ports were responding on the host:

Note that the LDAP service reports the DNS name for this machine.

We can add the machine’s hostname and domain name to our /etc/hosts file, which is always helpful if we’re going to be interacting with Kerberos. I like to use the format <fully-qualified domain name> <NETBIOS name> <domain name> when denoting a domain controller:

Our nmap scan just looks like basic domain controller stuff, so I’ll move on to testing the assumed breach credentials provided in the instructions:

faraday:hacksmarter123

After checking for SMB shares, I’ll check certificate services to see if we have any quick wins with ADCS abuse:

Note that we can see that 12 templates are enabled, but we aren’t able to see any of them. This is because we used the -vulnerable flag and none of the enabled templates have any vulnerabilities that are exploitable in the context of the “faraday” user.

Moving on from ADCS, we’ll check for other quick wins with AS-REP roasting and Kerberoasting:

Looks like we are able to recover one TGT for a user with a SPN. Let’s see if we can crack that hash using hashcat and the “rockyou.txt” wordlist:

We can use netexec to confirm the recovered password is valid:

Without any other quick wins found here, let’s pull BloodHound data using one of our users:

Lateral Movement and Privilege Escalation
#

Reviewing our BloodHound data, we can see that the “alt.svc” user to which we have gained access has GenericAll rights over the “yorinobu” account, which in turn has GenericWrite over the “soulkiller.svc” account:

Because we know that we have a CA in the environment, we can perform a shadow credentials attack, since GenericWrite (which is included in GenericAll) includes the permissions to write to the “msDS-KeyCredentialLink” attribute. In my opinion, this is the most responsible use of this permission set, since shadow credentials are non-destructive, meaning they don’t cause any disruption for users or services that use this account:

Now that we have two more users and we are at the end of our discovered access control chain, we can revisit ADCS to see if any of our new users have more permissions than the “faraday” account did:

We find that a certificate template called “AI_Takeover” is vulnerable to ESC1. Full explanation is outside of the scope of this write-up, but we will be able to request and authenticate with a certificate with a SubjectAltName, granting us authentication as an arbitrary user. We will target the “the_emperor” account because it is a member of the “Domain Admins” group:

We can confirm that this ticket is valid for this new “the_emperor” account using netexec:

Now that we have control of a member of the “Domain Admins” group, we can dump the NTDS.dit file to prove full compromise of the domain:

Since this lab has a flag to prove completion, we can grab this now that we have full control of the domain. Since I am using evil-winrm, I am going to use netexec to generate the contents of /etc/krb5.conf. This is not needed if using another tool such as impacket-wmiexec, etc., but I wanted to include this step to show how to do it easily:

Thank you to Hack Smarter and the lab creator, Henry Lever, for the development and distribution of this challenge!