Digital Attack Surface (Networks, Apps, Cloud, APIs)

#Every Exposed Service Is a Welcome Mat#link

Module 2 taught us who attacks and how they get in. Now we shift to what they attack: the attack surface — every point where an unauthorized actor can attempt to enter or extract data from your environment. The digital attack surface has exploded with cloud adoption, microservices, and API-first architectures. An organization that believes it has 200 internet-facing assets often discovers 2,000 when it runs a comprehensive external scan. Shadow IT, forgotten development servers, and misconfigured S3 buckets all expand the attack surface silently.

Network Attack Surface: Beyond Open Ports

The network attack surface includes all internet-facing IP addresses, open ports, exposed services, VPN gateways, and network devices with management interfaces. Shodan and Censys continuously scan the entire IPv4 space, cataloging every exposed service. An SSH server on port 22 with password authentication enabled is not just a service — it is an attack surface element being actively brute-forced by thousands of bots daily. Even 'hidden' services on non-standard ports are found quickly through full-port scans.

The Shodan results above reveal several critical findings: an SSH port open on the same host as the production application (unnecessary), RDP (port 3389) exposed to the internet (extremely dangerous), and an internal hostname leaked via a development Jenkins server that was inadvertently made public. Each of these represents an independent entry point for attackers. The internal hostname `jenkins-dev.yourcompany.internal` also leaks internal naming conventions useful for further reconnaissance.

Application & API Attack Surface: Logic Lives Here

Web applications and APIs represent the most dynamic and frequently vulnerable portion of the digital attack surface. Every API endpoint — documented or not — is an attack surface element. Every user input field is a potential injection point. GraphQL endpoints without query depth limits expose entire data models to unauthenticated introspection queries. REST APIs with broken object-level authorization (BOLA) allow users to access other users' data by simply incrementing an ID parameter.

{
  "finding": "Broken Object Level Authorization (BOLA) in REST API",
  "scenario": "Authenticated user can access other users' private data",
  "example_request": {
    "method": "GET",
    "endpoint": "/api/v1/users/12345/invoices",
    "headers": {
      "Authorization": "Bearer eyJhbGciOi...<victim_user_token>"
    }
  },
  "test": "Change /users/12345/ to /users/12346/ — if data returns, BOLA exists",
  "impact": "Data exfiltration of all user records via sequential ID enumeration",
  "remediation": "Verify object ownership server-side on every request — never trust client-provided IDs"
}

Cloud Attack Surface: Infrastructure as Code, Misconfigurations as Breaches

Cloud environments introduce new attack surface dimensions: S3 buckets with public read/write ACLs, security groups with 0.0.0.0/0 rules, exposed Kubernetes dashboards, and hardcoded credentials in Terraform state files or environment variables. The 2019 Capital One breach resulted from a misconfigured AWS WAF that allowed an attacker to execute a Server-Side Request Forgery (SSRF) attack, retrieve AWS metadata credentials, and exfiltrate 100 million customer records. The entire attack surface was cloud-native.

• ▪Continuously discover your digital attack surface — you cannot protect what you don't know exists
• ▪Close all non-essential ports; every open port is an invitation to attack
• ▪Treat APIs as first-class attack surface elements — they are just as vulnerable as web UIs
• ▪Enforce 'deny by default' for cloud resources; only open what is explicitly required
• ▪Monitor for shadow IT — unsanctioned services bypass all your security controls