MartiniAD
Challenge Lab (Easy) - by Ross
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Objective
An adult beverage company "Martini Bars" recently had a corporate breach and the compliance and risk team dictates they perform a penetration test at one of their branch offices. The Hack Smarter team has been authorized to perform an internal black box pentest.
Initial Access
The client has provided you with VPN access to their internal network, but no credentials.
Summary
Summary
In MartiniAD, we begin without credentials against a Windows Domain Controller DC01.DRY.MARTINI.BARS. Initial enumeration via NetExec reveals that guest SMB authentication is permitted, exposing a writable notes share and allowing a RID brute force against IPC$ to extract the domain user list. The notes share contains a notes.txt file with the plaintext credentials of mprice, granting our first set of valid credentials and authenticated SMB access to the domain.
With mprice, we pivot to LDAP enumeration and launch a Kerberoasting attack through NetExec's --kerberoast module, retrieving a TGS-REP blob for the ATHENA_SVC service account. The hash is cracked offline with Hashcat mode 13100, yielding valid credentials for the service account. Recalling the RID brute force output, we notice that a t0 account has a name similar to the service account. Password reuse is confirmed, and authentication as athena.t0 grants local administrator rights, which we then use to dump SAM and LSA secrets via secretsdump.py and retrieve the krbtgt hash.
Recon
We use rustscan -b 500 -a 10.1.16.162 --top -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.

The target 10.1.99.8 is a Domain Controller DC01.DRY.MARTINI.BARS. DNS is exposed on port 53 and Kerberos on port 88, alongside Kerberos password change on port 464. LDAP and LDAPS services are available on ports 389 and 636. SMB is exposed via ports 139 and 445 with message signing enabled but not required. Remote management and access are available through RDP on port 3389 and WinRM on port 5985. The host also exposes a .NET Message Framing service on port 9389, RPC over HTTP on ports 593, and several MSRPC endpoints on ports 135, 49664, 49667+.

We begin by enumerating the domain controller's SMB service via Netexec.
We'll follow the orange-cyberdefense mindmap. Since we do not have any users yet, we try to authenticate as guest or anonymously.

We are able to successfully authenticate as guest and immediately find a share called notes that we are authorized to read from and write. Furthermore we have read access to the IPC$ share, which allows us to perform a rid brute force.

We perform the aformentioned rid brute force and are able to enumerate some users.


We add those users to our users.txt file.
Finally, we'll create an entry for our /etc/hosts file.

Access as mprice
Next, we'll connect to the share Notes and see what we find. It contains a file named notes.txt, which we download.

The note contains the plaintext credentials of the user mprice.

We test the credentials using NetExec and are able to successfully authenticate.

BloodHound Enumeration
Next, we try to enumerate the domain, but in my case my collector did not work properly, so we need to continue blind.

Access as ATHENA_SVC
With valid credentials we can try to perfrom some Kerberoasting

When asking the KDC (Key Distribution Center) for a Service Ticket (ST), the requesting user needs to send a valid TGT (Ticket Granting Ticket) and the service name (
sname) of the service wanted. If the TGT is valid, and if the service exists, the KDC sends the ST to the requesting user.Multiple formats are accepted for the
snamefield: servicePrincipalName (SPN), sAMAccountName (SAN), userPrincipalName (UPN), etc. (see Kerberos tickets "cname formats").The ST is encrypted with the requested service account's NT hash. If an attacker has a valid TGT and knows a service (by its SAN or SPN), he can request a ST for this service and crack it offline later in an attempt to retrieve that service account's password.
In most situations, services accounts are machine accounts, which have very complex, long, and random passwords. But if a service account, with a human-defined password, has a SPN set, attackers can request a ST for this service and attempt to crack it offline. This is Kerberoasting.
We make use of the NetExec module and are able to retrieve the Kerberos 5, etype 23, TGS-REP blob from ATHENA_SVC.

Fortunately, this could be cracked using hashcat.

We test the credentials using NetExec and are able to successfully authenticate.

Access as athena.t0
We recall the list of users we generated using the RID brute force method. It may not be complete, but we can already use it to test whether the credentials have been reused. It's worth noting that the service account has a name similar to the t0 account. Based on its name, the t0 account appears to be an admin account. We'll check that right away. With a larger user list, we could now perform a password spray using nxc smb DC01.DRY.MARTINI.BARS -u users.txt -p 'REDACTED' --shares. But let's try it manually first with the t0 account.
We are able to authenticate as athena.t0 with the ATHENA_SVC password. An we confirmed, that this account is indeed an administrator account.

Next, we try to dump the SAM and LSA secrets using impackets secretsdump.py. And we are able to retrieve the KRBTGT hash.

Last updated