Attack Surface Management (ASM) - Angriffsflächen-Management

Attack Surface Management (ASM) beantwortet die Frage die Angreifer täglich beantworten: “Was kann ich bei diesem Unternehmen angreifen?” Viele Organisationen kennen ihre eigene externe Angriffsfläche schlechter als erfahrene Angreifer. ASM gibt der Verteidigung den gleichen Überblick - kontinuierlich und automatisiert.

Externe vs. Interne Angriffsfläche

EASM (External Attack Surface Management):
  → Perspektive: was sieht ein Angreifer im Internet?
  → Umfang: Domains, Subdomains, IP-Adressen, Zertifikate, E-Mail-Setup,
             Cloud-Ressourcen, exponierte Dienste, Technology-Fingerprints
  → Quellen: DNS, Shodan, Certificate Transparency Logs, WHOIS, Wayback Machine
  → Frage: Was ist von außen erreichbar? Ist es sicher konfiguriert?

CASM (Cyber Asset Attack Surface Management) / Internes ASM:
  → Perspektive: was kann ein Angreifer nach Initial Access tun?
  → Umfang: interne Assets, AD-Strukturen, Angriffspfade (BloodHound)
  → Frage: Welche Lateral-Movement-Pfade existieren?

Typische EASM-Entdeckungen:
  □ Vergessene Subdomains (dev.firma.de läuft noch auf veralteter Software!)
  □ Exponierte Development/Staging-Umgebungen
  □ Alte IP-Adressen die noch auf Unternehmens-Dienste zeigen
  □ Subdomain Takeover (sub.firma.de zeigt auf gelöschten Heroku-App)
  □ Expiredkte SSL-Zertifikate
  □ Schwache E-Mail-Konfiguration (kein DMARC!)
  □ Cloud-Storage öffentlich zugänglich (S3, Blob)
  □ VPN- und Remote-Access-Portale erkennbar (Angreifer-Ziel!)
  □ Legacy-Dienste: FTP, Telnet, RDP direkt aus Internet

ASM-Methoden und Tools

EASM Durchführung:

1. Passives Reconnaissance (keine Interaktion!):
   Certificate Transparency Logs:
     → crt.sh: alle ausgestellten TLS-Zertifikate für *.firma.de
       curl "https://crt.sh/?q=%.firma.de&output=json" | jq '.[].name_value'
     → Entdeckt: alle Subdomains die jemals ein Zertifikat hatten

   DNS-Enumeration:
     → amass enum -passive -d firma.de  # Passiv, kein DNS-Bruteforce
     → subfinder -d firma.de  # Aggregiert viele Passive Sources
     → DNSDumpster: dnsdumpster.com (Web, kostenlos)

   Shodan/Censys:
     → org:"Firma GmbH" Shodan-Query: alle IPs die Shodan kennt
     → ssl.cert.subject.CN:firma.de  # Zertifikats-basierte Suche
     → netblock:"ip-range" Port-Scan-Ergebnisse von Shodan

   OSINT-Quellen:
     → VirusTotal Passive DNS: virustotal.com/ui/domains/firma.de/subdomains
     → SecurityTrails: historische DNS-Daten
     → Wayback Machine: alte URLs und Pfade (oft noch zugänglich!)

2. Aktives Scanning (mit Erlaubnis - eigene Assets!):
   nmap -sV -p- firma.de  # Full Port Scan + Version Detection
   nuclei -u https://firma.de -t exposed-panels/  # Exposed Admin Panels
   testssl.sh --full firma.de  # TLS-Konfiguration

3. Automatisierte ASM-Plattformen:
   → Censys Search + ASM Platform: kontinuierlich Neue Assets entdecken
   → Shodan Monitor: Alert bei neuen offenen Ports (per E-Mail!)
   → IONIX (ehem. Cyberpion): vollautomatisches EASM
   → Mandiant Advantage ASM: Enterprise-Lösung
   → Detectify: Web Security + EASM kombiniert

Kostenloser Einstieg:
  1. crt.sh: alle Subdomains per Zertifikat
  2. Shodan Monitor (kostenlos für 1 Ziel)
  3. SecurityHeaders.com: HTTP-Header aller entdeckten Webserver
  4. SSL Labs: TLS-Rating aller Webserver
  5. MX Toolbox: E-Mail-Sicherheit (SPF, DMARC, DKIM)

Subdomain Takeover

Subdomain Takeover - häufiges EASM-Finding:

Funktionsweise:
  1. Unternehmen nutzte früher: blog.firma.de → Hosted auf Heroku
  2. Heroku-App wurde gelöscht (CNAME blieb in DNS!)
  3. CNAME: blog.firma.de → firma.herokudapp.com
  4. Angreifer registriert firma.herokudapp.com → kontrolliert nun blog.firma.de!
  5. Angreifer kann: beliebigen Content unter blog.firma.de hosten
  6. Phishing: "firma.de/blog" sieht legitim aus!

Betroffene Services:
  → Heroku, GitHub Pages, Azure CDN, CloudFront, Fastly, Shopify, HubSpot...
  → Tool: subjack (GitHub) - scannt CNAME-Einträge auf Takeover-Potential

  subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json

Prüfung:
  dig CNAME blog.firma.de  # Was zeigt der CNAME?
  curl https://blog.firma.de  # Zeigt "repository does not exist"? → DANGER!

Prävention:
  □ Alle CNAMEs inventarisieren und prüfen
  □ Bei Dienstabschaltung: CNAME-Eintrag aus DNS löschen!
  □ Monitoring: subjack/nuclei regelmäßig auf eigene Domains laufen lassen
  □ ASM-Plattform: automatische Erkennung

ASM in der Security-Strategie

ASM als Grundlage für andere Programme:

ASM → Vulnerability Management:
  → ASM entdeckt alle Assets
  → VM scannt alle Assets auf Schwachstellen
  → Priorisierung: Internet-facing Systeme zuerst!
  → CTEM nutzt ASM + VM als Basis

ASM → Penetrationstest:
  → Pentest-Scope basiert auf ASM-Ergebnissen
  → "Alle Internet-facing IPs und Domains sind in Scope"
  → Angreifer startet genau hier

ASM → Incident Response:
  → Nach Incident: welche anderen Assets könnten betroffen sein?
  → ASM zeigt: welche Systeme haben ähnliche Konfiguration?

ASM Governance:
  → ASM-Owner: IT-Security (nicht IT-Operations!)
  → Reporting: monatlich an CISO
  → Neue Assets: within 24h nach Go-Live in ASM
  → Alert: neues Internet-facing Asset ohne Sicherheits-Review

KPIs für ASM:
  → Anzahl Internet-facing Assets (Trend: sinkend = Angriffsfläche reduziert)
  → Mean Time to Remediate bei ASM-Findings
  → Unbekannte Assets entdeckt pro Monat (Shadow IT!)
  → SSL-Ablaufzertifikate: 0 Tage sollte Ziel sein
  → DMARC/SPF Coverage: % der Domains mit korrekter E-Mail-Security