There are dozens of terrific articles covering this topic from just about every angle. I benefit from writing this because every time I rehash this process it becomes more and more second nature to me. The only hope I have that you, dear reader, gain something valuable from this article is that I delve fairly deep into the hows and whys while going through an example CTF challenge. The exact name of the CTF wont be mentioned since this is not intended to be a direct walk-through but instead, a guide on how to think through a box like this as a complete beginner. That said, we begin…
We ping a box to make sure we can even see it and once confirmed, we begin with an nmap scan. Nmap is an open source tool used for network discovery and security auditing, used here to discover open ports and services. We do not have to worry about being evasive in these circumstances so we can use “loud” (easily detectable/ alert-causing on IDS/IPS systems) commands for our nmap scan and try to extract as much information as possible.
nmap -sC -sV <target IP>
Using the arguments -sC (to run a default script scan) and -sV (to determine service/ version information), nmap discovered that there were several recognizable ports open such as DNS on port 53, Kerberos on port 88, and LDAP on port 389. Kerberos and LDAP allow for positive identification that this is a Windows machine running Active Directory. We can also see LDAP is giving away this machine’s domain name as MEGABANK.LOCAL0.. Ports 139 and 445 are also important because they tell us that this machine is running the SMB (server message block) network sharing protocol.
Next we use enum4linux, a tool for enumerating information from Windows and Samba systems.
enum4linux -a <target IP> >> enum_output
With this tool we see two very useful pieces of information; several users and the password policy. We also see one helpful yet not helpful bit of information, that SMB1 is disabled. It seems we won’t be able to see shares if we’re unauthenticated.
Now it’s time to try and utilize those open SMB ports. The way we intend to interact with this Windows machine via our Linux machine is utilizing Samba, which acts as an intermediary in allowing the two to speak natively. Samba implements the Server Message Block (SMB) protocol and this protocol is used to access resources on a server, such as file shares and shared printers. Also, importantly and relevantly, you can use Samba to authenticate Active Directory (AD) domain users to a Domain Controller (DC). This understanding led us to try and see if there were shares we could see with another tool called smbmap, a tool that allows users to enumerate samba share drives across an entire domain.
smbmap -H <target IP>
However, we seem to have only confirmed that we cannot view shares unauthenticated.
It is at this point we decide to try and check for weak passwords among the users we identified. We use the popular Metasploit Framework, a tool largely used to house a robust repository of tools to aide in penetration tests called modules. It is with one such module, smb_logon, that we attempt to guess user’s passwords by setting their own username as a possible password. We set the RHOSTS to our Target IP address, and then set the USER_FILE and PASS_FILE to, in this case, the same file of usernames on individual lines. This was successful as SABatchJobs was found to be both user and password.
Now that we have credentials, we use the tool smbclient, a tool used to enumerate SMB shares on a target, to view shares and take a particular interest in one, users$.
smbclient -L <target IP> -U SABatchJobs
Within the users$ share we discover what we expected, a list of users. One such user directory, mhope, contained a file called azure.xml which contained this user’s password.
With this user’s password we are able to use the tool Evil-WinRM (Evil Windows Remote Management), which allows us to spawn a shell on the target machine so long as we have credentials.
evil-winrm -u mhope -p '4n0therD4y@n0th3r$' -i <target IP>
We navigate to the Desktop where we find the user hash. Now we need to escalate our level of privilege past this user into the administrators.
From within this user’s system we attempt to enumerate user and group information with the whoami /all command. This reveals a group call MEGABANK\Azure Admins. The privilege escalation in this example is a common scenario. We spend the bulk of our time googling things we can find with our user credentials and in this instance we found Azure Admins and got lucky. Often times its quite a bit more difficult to pinpoint the vector of how we’ll escalate. You’ll find yourself going through write-ups on more standard/ common methods of escalating your privilege based on the target OS. Based on seeing Azure Admins, the first auto-fill suggestion completes our google search with ‘group exploit’, leading us to believe we’re on the right path. We eventually find a github page containing a script called Azure-ADConnect.ps1. We use the upload function of Evil-WinRM to upload our script to the target and when executed, a new user is created and added to the administrator group.
The commands in order:
upload Azure-ADConnect.ps1 ./Azure-ADConnect.ps1 import-module ./Azure-ADConnect.ps1 Azure-ADConnect -server 127.0.0.1 -db ADSync
We see this new users credentials as output from our ps1 script.
We then login as that administrator with the same evcil-winrm command we used to login as mhope and browse to where the root hash is kept, completing the challenge.
I hope this beginners look was helpful to you. Please let me know how I can improve, as that is always our goal in information security. Thank you.
Fantastic articles I learned from:
As always I must thank Nick P. for where I am today.