It’s been a month since I joined the company as part of the IT support team at least, that’s the official story. I’ve already met the guys in the Office, great crew, but that’s beside the point because my real objective is very different. This kind of situation we simulate during the insider penetration tests.

I’m rolling out my plan step by step. First came a quick environment recon. Because I’m still the new guy, my privileges are very limited. I get into the network through a VPN, and I found that the RDP box I land on will happily make outbound connections. Perfect: an SSH reverse tunnel from that machine gives my Linux box full access to the internal network. That makes my offensive traffic much harder to spot.

First observation: the network is quirky, a Windows Active Directory connected with Linux AD. While doing routine tasks and my own scans, I noticed a couple of anomalies. BloodHound graphs showed that some users never showed up at all.

The second anomaly appeared when I tried to take over the domain controller via Active Directory Certificate Service (AD CS). Certipy highlighted an ESC8 misconfiguration. This vulnerability is quite interesting cuz it’s using NTLM relaying eg.: by coercing forced authorization to obtain certificate for relayed object in this situation for Domain Controller. “Piece of cake,” I thought. Step one: can I relay an NTLM hash to my host? Responder plus PetitPotam, first will catch NTLM, second will force authorization to my system – step successful, hash appears in seconds. Looks good. I configure Certipy in relay mode, fire up PetitPotam… nothing. I ran responder again, and hash arrives but with Certipy it’s silence. I swap in impacket-ntlmrelayx. Same thing.

Wireshark shows that when relay tools are running, the server never even dials my box, yet with standalone Responder it does. I hack up my own SMB server in Python in case the legit tools are fingerprinted - no luck. Fine, that path goes on the shelf for now.

Next up – the file shares. I dig up a few credentials, but they belong to „normal” users with no special privileges. Days pass during the pentest and the trail goes cold. Then I decided to check again domain logons to Linux hosts, since I’ve seen that misconfiguration before in other pentest. A quick scan, and in one subnet I spot two Linux servers.

I tried ssh "user@domain"@IP. Entered the password - the prompt shows a hostname containing “dc.” Wait - this is a domain controller?! Immediate adrenaline rush.
This could be gold, a Linux DC often hides juicy stuff and compromising it could mean a full-domain takeover.
First, I poke around, standard directories, sudo -l, SUID/SGID binaries so nothing unusual. I grep for “password” across /home, and it was a bingo! I found a replication script with a hard-coded password.
That account wasn’t found during BloodHound scan. Typically, all Active Directory users should be visible in this type of scan. Despite that weird behaviour I SSH to the DC, run id and it turned out that it is low-priv user.

Time for /etc. In /etc/cron.hourly/replicates/ I find the same script, but owned by a different user: It’s also missing from BloodHound. I wonder to which groups this user will be assigned. I log in with those creds, run id…

ENTERPRISE ADMIN. I half expected it, but it’s still a thrill.

Finally. It took some digging, but I’m in. With an Enterprise Admin account, my covert op is essentially done high-privileged access secured. But my curiosity didn’t stop me here. I also made NTDS.DIT dump and performed offline brute force attack. Surprisingly I was able to recover only few precents of all the password but in case I could be caught I have good backup.

Logout. See you next time…