← research log

entry

Mapping attack surfaces

date
2026-04-11
tags
reconnaissance · methodology · fundamentals

What is an attack surface?

An attack surface is every point where someone unauthorized can try to enter or pull data out. Network services, web apps, APIs, input fields, auth, and the people who run the system all count.

When I started I thought offensive work was mostly running tools and hunting exploits. That was backwards. You need to know what you're looking at before you start poking.

Why mapping matters

If I fire up Nmap with no plan I get a long list of open ports and then sit there guessing. Better to map the surface first, then decide what is worth time.

A map helps with:

  1. Coverage - you know what exists before you choose what to test
  2. Prioritization - not every service is interesting
  3. Documentation - notes you can hand to someone else
  4. Reproducibility - they can pick up where you stopped

The layers

I think of attack surfaces from the outside in.

Network layer

Where most people start. Open ports, services, versions.

# Initial discovery - fast sweep
nmap -sn 10.10.10.0/24

# Service enumeration on a specific host
nmap -sC -sV -p- -oA full_scan 10.10.10.x

Worth writing down:

  • Unusual ports - why is SSH on 2222? what's on 8443?
  • Version numbers - old software is usually the easy path
  • Filtered vs closed - filtered often means a firewall, which tells you about the setup

Web application layer

If there's a web server, spend time here.

# Directory enumeration
gobuster dir -u http://target -w /usr/share/wordlists/dirb/common.txt

# Technology fingerprinting
whatweb http://target

Look for:

  • Admin panels - /admin, /dashboard, /login
  • API endpoints - /api/v1/, /graphql
  • File upload - often weak
  • Error pages - verbose errors leak useful detail

Authentication and authorization

How does the system check identity? How does it gate access?

  • Password policies (or none)
  • Session management (cookies, tokens, JWTs)
  • MFA present or not
  • Role checks that are wrong or missing

Human layer

Social engineering is out of scope for most lab boxes. In real engagements it's often the shortest path. Phishing, pretexting, and physical access all sit on the human surface.

Building the map

I keep maps boring on purpose: a markdown file with a section per layer, updated as I find things.

# Target: 10.10.10.x

## Network
- Port 22: OpenSSH 8.2p1 (Ubuntu)
- Port 80: Apache 2.4.41
- Port 3306: MySQL 5.7 (filtered)

## Web Application
- CMS: WordPress 5.8.1
- Plugins: Contact Form 7, WooCommerce
- Admin: /wp-admin (login page accessible)
- Interesting: /uploads directory listing enabled

## Authentication
- Default WordPress login (no lockout policy observed)
- No MFA detected

## Notes
- Apache version has known CVEs
- Directory listing suggests misconfiguration
- MySQL filtered but present - possible pivot target

Findings go here first. Then they go into the writeup.

What I've learned so far

Three months in: rushing past enumeration is how I waste time on HTB. The boxes that clicked were the ones where I spent about 30 minutes mapping before I tried an exploit.

Recon is dull. It's also how I stop guessing.

Resources

First post in the security log. Next: web application enumeration.