Red Team Diaries: #1

Intro

Ever wondered how adversaries move from zero domain access to domain admin ???

As a Penetration Tester / Red Team Operator I’ve been doing exactly that For the past 3 years. starting from basic recon and escalating all the way to domain/enterprise admin. It isn’t just about tools and methodologies—it’s about understanding the system, spotting weaknesses, chaining techniques and using the right tactics to move forward.

TL;DR

In this series, I'll share my experience in real-world adversary emulation scenarios targeting Active directory environments and showing how attackers can exploit common misconfigurations to gain control, even in fully patched environments with security products in place.

Assume Breach Model

This first post is about a real-world scenario from an assume breach (AB) assessment which is a common adversary emulation model in internal penetration tests and red team engagements. here is a good definition for this model by TRUSTEDSEC:

Assumed Breach (AB) assessments are designed to mimic a threat scenario in which an attacker has already gained access to the internal network via some manner of compromise.

This simply means that the bad guys are inside the network, either from spreading malware through a phishing campaign, pwning the wireless network, dropping a DropBox somewhere in the building, exploiting a 0day/Nday in VPN or public services or some other technique.

This photo from Microsoft’s “Enterprise Cloud Red Teaming” whitepaper, shows the difference between traditional “Prevent Breach“ and modern “Assume Breach” assessment models.

Why Bother ?

Because in a red team engagements, RTOs don’t have the luxury of time (at least, not as much as adversaries do) to phish the target for weeks or spend months trying to find a zero day in different services and infrastructure.

The other main reason is that initial compromise eventually happens and no one can deny that, the only thing we can do, is to apply and assess defense-in-depth mechanisms and procedures to prevent the attackers from advancing inside the network and reaching their final objectives.

Domain Recon

First things first, recon is everything. when it comes to Active Directory, enumerating domain-joined systems is the first thing to do. since SMB is the most critical protocol used in AD environments, we can start by performing an SMB enumeration using crackmapexec or netexec tools. but we have to be careful not to trigger SOC alarms by sending a huge amount of SMB traffic in the network or even worse, causing an IPS rule on the gateway firewall to kick off and block our network traffic.

LLMNR Poisoning to MSSQL Admin

One of my favorite initial access techniques that works about 80% of the time due to default configurations in AD that most system administrators don’t even know about.

LLMNR (Link-Local Multicast Name Resolution) poisoning is a network attack targeting Windows devices that use LLMNR for hostname resolution when DNS fails. It involves an attacker listening for multicast requests sent by devices attempting to resolve hostnames. When a victim sends a request, the attacker responds with a forged reply, impersonating the requested device and providing their own IP address. This trickery causes the victim to communicate with the attacker's machine, allowing the attacker to capture hashes, clear-text credentials or even redirecting traffic.

Setting up responder and listening for broadcast name resolution traffic will kindly hand us some credentials after a few minutes:

As you can see, responder has poisoned an answer to a name resolution request for a host name which is then used for authenticating to MSSQL service using the default sa account (default administrator account of SQL service) and its clear-text password.

Using these credentials, we can authenticate to the SQL server machine with admin access using sqlmap and a connection string:

from here on, we can either dump all databases from the server:

dump all database user hashes:

or we can try to get a system shell :)

SQL to System Shell

Since we have admin access to MSSQL service, we can enable some functionalities and use them for our malicious purposes. one of these functionalities is the infamous XP_CMDSHELL function which will enable cmd command execution from SQL service.

To do this, we can use our current sqlmap access, or use SQL Server Management Studio. from my experience, sqlmap can be a little tricky and fail in some cases. to use the management studio client, we should setup a dynamic reverse ssh tunnel from out attacker machine inside the company network to a windows machine under our control:

ssh -D [remote_port] [user]@[remote_server_ip]

after setting up the tunnel, we connect to database server through the tunnel using sa credentials and enable XP_CMDSHELL :

then we go back to sqlmap and get a system shell:

and BOOM!, we have system level access to the server.

System Shell to RDP

Since we are on a red team engagement, we have to provide some strong evidence of breach as a proof of concept (POC). the usual way to do that is gaining graphical access to desktop environment and taking some juicy screenshots for our report.

To do this, the simplest way is to use our system level access and create a new user with RDP enabled and then use our ssh tunnel to remotely connect to the server using RDP. but after executing net command in sqlmap OS shell console, we get the following error:

This is the EDR preventing use from executing specific cmd commands in the context of SQL service process, even though we have the highest possible privileges on the system. its terminating a call to CreateProcess API which is responsible for creating a new cmd process and executing net command.

A Quick Bypass

A quick workaround for this is to chain our commands. instead of executing this:

net user w4lk3r password /add

we simply do this:

powershell net user w4lk3r password /add

and you see it works like a charm:

After that, we can RDP to the server:

Manual SAM Dump

Most EDR Products are very sensitive to credential dumping techniques specially if you use automated tools or touch LSASS process. since we have GUI access to this system, we can try to dump SAM database manually by saving the SAM, SECURITY and SYSTEM registry keys and then transferring them to our system to extract user hashes:

after transferring the files, we can dump the hashes using impacket secretsdump tool:

Pass-the-Hash to Domain Admin

Now that we have some windows credentials, it’s time for lateral movement, and the most used technique for this is pass-the-hash (PtH) attack which means we use hashes instead of clear-text password for authenticating to domain-joined systems in order to gain more access and hopefully move up in the domain. the SQL server SAM contained some domain-joined users as well as a local admin account. if company security policies are weak, there is a high chance of credential reuse which will drastically increase our success rate in pass-the-hash, pass-the-ticket and other similar credential attacks.

Using crackmapexec and some of the hashes dumped earlier, we start shooting targets. but again, we don’t want to be detected so we go low and slow. starting with the local admin account hash, we quickly hit the jackpot:

As you can see in the image above, the same local admin hash worked on domain controller as domain admin account. we have successfully gained domain admin access in just a couple of hours and dumped the NTDS.dit database which contains all the domain credentials we can get.

Outro

This was the first post of these series, i’ll try to post more red team stories and introduce you to different techniques and scenarios as we move on.

Till we meet again, happy hacking :)