Common Network Service Attacks

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: A network service is a program that answers the network — and every one of them is a potential way in. Most service compromises are not the result of brilliant exploits; they are the result of services left misconfigured: default credentials, anonymous access enabled, weak settings, outdated versions. Page 3.1 found the doors. This page is about the doors that were left unlocked.

Part 1: The Problem

Your scan from 3.1 produced a list of services — SSH here, SMB there, FTP, a database, a mail service. Each is a separate program, with its own configuration, its own authentication, its own history of vulnerabilities. Each is an independent target.

The uncomfortable truth, echoing Security Misconfiguration from 2.9: most services are compromised not through clever exploitation but through carelessness. A file share with anonymous access enabled. A database exposed to the network with a default password. An admin service reachable when it should be internal-only. An old service version with a publicly known flaw. The attacker’s job here is often less “exploit” and more “notice what was left open.”

Part 2: The Concept — Every Service Is an Attack Surface

A service exposed on the network presents several distinct things an attacker probes:

   FOR EACH SERVICE, an attacker asks:
   ┌─────────────────────────────────────────────┐
   │ • Authentication — can I get in? Default     │
   │   creds? Anonymous access? Weak passwords?   │
   │ • Configuration — is it set up insecurely?   │
   │ • Version — does this version have known     │
   │   vulnerabilities? (→ 2.10, 3.3)             │
   │ • Information — what does it leak just by     │
   │   being queried? (users, shares, structure)  │
   │ • Exposure — should this even be reachable    │
   │   from where I'm standing?                    │
   └─────────────────────────────────────────────┘

That last question matters a lot. Many services are perfectly fine internally but should never face the wider network — a database, an admin interface. A service being reachable from the wrong place is itself a serious finding, independent of any flaw in the service.

This page surveys the most common services. The goal is the pattern, not exhaustive per-service detail — once you see how to think about a service, you can approach any service, including ones you’ve never met.

Part 3: The Usual Suspects — Common Services and Their Weak Points

A practical tour of services you’ll repeatedly encounter, and the categories of weakness each commonly has. (Ports are from the 0.4 table.)

SMB / file sharing (Windows file sharing, port 445). A historically major attack surface. Common issues: shares accessible without proper authentication; anonymous/guest access revealing files or user lists; weak permissions on shares; older versions with serious known vulnerabilities. SMB enumeration often reveals usernames and network structure — valuable for later steps (3.4, 3.5).

FTP (file transfer, port 21). An old protocol, still around. Classic issue: anonymous FTP access enabled — anyone can connect and browse/download files, sometimes upload. Also: credentials sent in plaintext on plain FTP (sniffable, recall 1.3), and exposed sensitive files.

SSH (secure remote login, port 22). SSH itself is solid encryption — the weaknesses are usually around it: weak or default passwords allowing brute force; password authentication enabled where keys would be safer; outdated versions; sometimes overly informative banners. SSH is a high-value target — success means a remote shell on the machine.

Remote Desktop (RDP, Windows graphical remote access, port 3389). A high-value target — access means a full graphical session. Common issues: exposure to the internet (it should not be); weak passwords brute-forceable; outdated versions with known vulnerabilities.

Databases (e.g. MySQL on 3306, and others). A database is where the data lives — the crown jewels. The cardinal sins: the database exposed to the network at all when it should only be reachable by the application; default or weak credentials; default configurations.

Mail and other services (SMTP on 25, etc.). Mail services can leak information (e.g. confirming which users exist) and, if misconfigured, be abused to relay mail. The general principle holds: enumerate it, check its configuration, check its version.

The recurring themes across all of them: default credentials, anonymous access, weak passwords, outdated versions, and improper exposure. Learn to check those five things against any service and you have a universal method.

Part 4: The Core Techniques

How attackers actually work a service, in practical terms:

Banner grabbing and enumeration (from 3.1). First, interrogate the service for its version and any information it volunteers. Many service-specific enumeration tools exist; Nmap’s scripts cover a great deal.

Checking for anonymous / default access. The fastest wins. Try connecting to FTP anonymously. Try the documented default credentials for the identified database or device. Try guest access on SMB. This requires no exploit — just knowing the defaults and checking.

Password attacks against services. Where a service has a login and no good protection, attackers attempt brute force or credential-based attacks against it — conceptually the same credential attacks as 2.6 (brute force, credential stuffing, password spraying), now aimed at network services rather than a web login. Specialized tools automate login attempts against many service types. This works precisely when services lack the protections from 2.6: rate limiting, lockout, strong passwords.

Exploiting known vulnerabilities. If version detection (3.1) reveals a service version with a known CVE (2.10), that’s a direct path — covered in depth in 3.3.

Acting on leaked information. Usernames from SMB, structure from a directory service, files from an open share — feed directly into later steps. Information gathered from one service often unlocks another.

⚖️ A reminder with teeth: password attacks against services are active and noisy and can lock out real accounts or disrupt services. Brute-forcing a service is unambiguously an attack. Your lab and authorized targets only — and even then, mind the rules of engagement (1.0).

Part 5: From a Service to a Foothold

The point of attacking a service is usually to gain a foothold — an initial point of access on a machine inside the target environment. The progression:

   3.1  scan  ──►  found: SSH, SMB, FTP, a database
                          │
   3.2  attack a service ─┤  e.g. weak SSH password
                          │     → a remote shell on the machine
                          ▼
                   FOOTHOLD: you have access on one machine,
                             usually as a LOW-privileged user
                          │
   3.3  exploitation  ────┤  (alternative route to a foothold:
                          │   exploiting a known vulnerability)
                          ▼
   3.4  privilege escalation → from low-privileged user → admin/root
                          │
   3.5  Active Directory  → from one machine → the whole domain

This page is the “get a foothold” step. Notice it’s rarely the end — a foothold is typically a low-privileged one, and the real impact comes from what follows (3.4, 3.5). But you can’t escalate from access you don’t have. The service attack is the way in.

And note the honest reality this progression shows: a single weak service — one default database password, one guessable SSH login — can be the first link in a chain that ends in total compromise. That is exactly why defenders must secure every service, not just the obvious ones (the chaining lesson from 2.11, now at the infrastructure level).

Part 6: The Defense — A Preview of Phase 4.4

The offense/defense mirror. Defending services is a central part of hardening, built fully in Phase 4.4. The shape, mapping directly onto this page’s attacks:

• Don’t expose what doesn’t need exposing. The single biggest win. A database reachable only by its application, admin services internal-only, RDP never facing the internet. This is attack surface reduction (0.4) and firewall/segmentation work (4.4) — fewer reachable services, fewer doors.
• Change every default; disable anonymous access. No default credentials, anywhere. No anonymous FTP or guest SMB unless genuinely intended. (This is Security Misconfiguration’s fix from 2.9, applied to services.)
• Strong authentication and protection. Strong passwords or, better, key-based authentication for SSH; MFA where supported; rate limiting and lockout on service logins (the 2.6 defenses, for services).
• Keep services patched and updated. Outdated service versions with known CVEs are reliably exploitable (2.10). Patch them.
• Harden each service’s configuration. Every service has a hardening baseline — disable unneeded features, remove informative banners, restrict access by source.
• Remove services you don’t need. A service that isn’t running cannot be attacked (0.4). Uninstall the unnecessary.

🔑 The lesson: most service compromise is preventable with configuration discipline, not exotic defenses. Don’t expose it if you don’t need to; change the defaults; authenticate strongly; patch it; harden it; or remove it. Boring, and overwhelmingly effective.

📓 Key Terms

🧪 Hands-On Lab

Your own lab VMs (Phase 0.5) and authorized practice platforms only. Service attacks are active, noisy, and can lock accounts or disrupt services.

Task 1 — Start from your map. Open the “Infrastructure Map” you built in 3.1. Pick your vulnerable victim VM and its list of services and versions.

Task 2 — Enumerate each service. For each service on the victim VM, do deeper enumeration — banner grabbing, service-specific Nmap scripts. Record everything each service reveals.

Task 3 — Check for anonymous access. If the victim runs FTP, try connecting anonymously. If it runs SMB, check for guest/anonymous access and list any accessible shares. Note what’s reachable without credentials.

Task 4 — Check for default credentials. For any database or service on the victim VM, identify the software (from your map) and look up its documented default credentials. Test whether defaults are in place.

Task 5 — Service password attack (lab only). On a service with a login, use a password-attack tool against it with a small wordlist — on your own victim VM only. Observe how a weak password falls, and connect this to the missing 2.6 defenses (no rate limiting, weak password).

Task 6 — Gain a foothold. Using whatever worked — anonymous access, default creds, a weak password — gain actual access to the victim machine (e.g. a shell via SSH, or access via another service). You now have a foothold. Note which user you are — almost certainly a low-privileged one (that sets up 3.4).

Task 7 — Act on leaked information. Did one service reveal usernames or details useful against another? Document any such link — this is how real chains form.

Task 8 — Write the defensive counterpart. For every weakness you used, write the Phase 4.4 fix from Part 6. Add these to the hardening checklist you started in 2.9.

⚠️ Common Mistakes

• Brute-forcing services on unauthorized targets. Loud, active, account-locking — and a crime off your own lab. Authorized targets only.
• Checking only the “interesting” services. The forgotten FTP server or exposed database is often the way in. Enumerate every service.
• Skipping the free wins. Anonymous access and default credentials require no exploit and frequently succeed. Always check them first.
• Forgetting “should this be reachable at all?” A perfectly patched database is still a serious finding if it’s exposed to the network. Exposure itself is a weakness.
• Treating the foothold as the goal. A foothold is usually low-privileged — the start of the chain, not the end. 3.4 and 3.5 are where impact is realized.
• Ignoring leaked information. Usernames and structure from one service unlock the next. Information gathered is an asset; record it.

✅ Recap & What’s Next

• Every network service is an independent attack surface; for each, attackers check authentication, configuration, version, leaked information, and exposure.
• Most service compromise comes from carelessness — default credentials, anonymous access, weak passwords, outdated versions, improper exposure — not exotic exploits; the goal is usually a foothold (often low-privileged).
• Defense (Phase 4.4) is configuration discipline: don’t expose what you needn’t, change defaults, authenticate strongly, patch, harden, or remove.

Next (3.3): Sometimes the way in isn’t a weak password but a vulnerability in the service itself. Page 3.3 covers exploitation — how a known vulnerability becomes a working compromise — and the Metasploit Framework.