Evilginx Phishing Framework: MitM-Angriffe verstehen und abwehren

„Unser 2FA ist doch sicher“ – ein Satz, den ihr als Security-Verantwortliche oder Developer sicher schon gehört habt. Doch mit Tools wie Evilginx wird deutlich: Zwei-Faktor-Authentifizierung allein reicht nicht mehr aus. Nach über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting zeigen wir euch heute, warum ihr Evilginx kennen solltet – nicht um anzugreifen, sondern um eure Systeme besser zu schützen.

Warum Evilginx für eure Security-Strategie relevant ist

Evilginx ist ein Man-in-the-Middle Phishing-Framework, das Session-Cookies abfängt und damit selbst moderne 2FA-Schutzmechanismen umgeht. Das klingt bedrohlich – und das ist es auch. Aber genau deshalb müsst ihr als Developer und Entscheider verstehen, wie diese Angriffe funktionieren.

Für euer Team bedeutet das:

• Red Teaming: Realistische Penetrationstests eurer Authentication-Flows
• Security Awareness: Aufklärung für Mitarbeiter über moderne Phishing-Methoden
• Architektur-Entscheidungen: Bessere Auswahl von Authentifizierungs-Mechanismen
• Incident Response: Schnellere Erkennung und Reaktion bei Angriffen
• Compliance: Erfüllung von Security-Audits und Penetrationstests

Das Team von Never Code Alone hat in zahlreichen Security-Assessments erlebt, wie Unternehmen von modernen Phishing-Angriffen überrascht wurden. Mit dem richtigen Verständnis könnt ihr eure Systeme proaktiv absichern.

Die 10 wichtigsten Fragen zu Evilginx – direkt beantwortet

1. Was genau ist Evilginx und wie unterscheidet es sich von klassischem Phishing?

Evilginx ist ein Reverse-Proxy-Framework, das als Man-in-the-Middle zwischen Nutzer und legitimer Website agiert. Im Gegensatz zu klassischem Phishing, das gefälschte Login-Seiten nutzt, proxy-t Evilginx die echte Website in Echtzeit.

Der entscheidende Unterschied:

• Klassisches Phishing: Statische HTML-Kopien, leicht erkennbar
• Evilginx: Live-Proxy der echten Website, HTTPS-Zertifikat inklusive
• Ergebnis: Nutzer sehen die originale Website, Angreifer fangen Credentials UND Session-Cookies ab

Technisch gesehen arbeitet Evilginx in Go und bringt einen eigenen HTTP- und DNS-Server mit. Das macht die Installation extrem einfach – ein zweischneidiges Schwert.

Praxis-Tipp aus über 15 Jahren Consulting: Schult euer Team darauf, nicht nur auf das grüne Schloss zu achten, sondern aktiv die Domain zu überprüfen. Evilginx kann HTTPS, aber nicht eure echte Domain replizieren!

2. Wie funktioniert der 2FA-Bypass bei Evilginx technisch?

Der 2FA-Bypass ist das, was Evilginx so gefährlich macht. Das Framework fängt nicht nur Username und Passwort ab, sondern vor allem die Session-Cookies, die nach erfolgreicher Authentifizierung gesetzt werden.

So läuft der Angriff ab:

1. Opfer klickt auf Phishing-Link zu Evilginx-Server
2. Evilginx proxy-t Login-Page der echten Website
3. Opfer gibt Credentials ein – Evilginx leitet sie weiter
4. Echte Website fordert 2FA an – Opfer gibt Code ein
5. Nach erfolgreicher 2FA sendet Website Session-Cookie
6. Evilginx fängt Session-Cookie ab – das ist der Schlüssel
7. Angreifer kann Cookie importieren und ist eingeloggt

Der Cookie enthält die bereits validierte Session – 2FA ist bereits durchlaufen. Der Angreifer muss sich nicht erneut authentifizieren.

Security-Architektur-Tipp: Implementiert zusätzlich IP-basierte Anomalie-Erkennung, Device-Fingerprinting und kurze Session-Timeouts. Das erschwert den Missbrauch gestohlener Cookies erheblich.

3. Welche rechtlichen Rahmenbedingungen gelten für Evilginx-Nutzung?

Evilginx ist ein Dual-Use-Tool – legitim für Security-Testing, illegal für echte Angriffe. Die rechtliche Situation ist klar, aber komplex:

Erlaubte Nutzung:

• Autorisierte Penetrationstests mit schriftlicher Genehmigung
• Red-Team-Assessments im eigenen Unternehmen
• Security-Research in kontrollierten Umgebungen
• Training und Awareness-Schulungen

Verboten:

• Jeglicher nicht-autorisierter Zugriff auf fremde Systeme
• Phishing-Kampagnen ohne Einwilligung
• Weitergabe an unberechtigte Dritte

Evilginx Pro unterliegt sogar Export-Kontrollen (Wassenaar Arrangement) als Dual-Use-Gut. Das zeigt, wie ernst die Technologie genommen wird.

Consulting-Erfahrung: In unseren Red-Team-Assessments arbeiten wir immer mit detaillierten Scope-Dokumenten und Rules-of-Engagement. Das schützt beide Seiten rechtlich und fachlich.

4. Wie installiert man Evilginx für legitime Penetrationstests?

Die Installation ist bewusst einfach gehalten. Für autorisierte Tests benötigt ihr:

Voraussetzungen:

• Ubuntu/Debian VPS (DigitalOcean, AWS EC2, etc.)
• Eigene Domain mit Zugriff auf DNS-Einstellungen
• Go-Installation (mindestens Version 1.14)
• Freie Ports: TCP 443, 80 und UDP 53

Installation von Evilginx2 (Open Source):

sudo apt-get update
sudo apt-get install git make golang
git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2
make
sudo ./bin/evilginx -p ./phishlets/

Basis-Konfiguration:

config domain yourphishingdomain.com
config ip YOUR_SERVER_IP
phishlets hostname o365 yourphishingdomain.com
phishlets enable o365
lures create o365
lures get-url 0

Best Practice aus der Praxis: Nutzt Screen oder Tmux, damit Evilginx nach SSH-Logout weiterläuft. Und dokumentiert jeden Schritt für eure Pen-Test-Reports!

5. Was sind Phishlets und wie erstellt man sie?

Phishlets sind YAML-Konfigurationsdateien, die Evilginx mitteilen, wie eine bestimmte Website zu proxy-en ist. Sie sind das Herzstück des Frameworks.

Ein Phishlet definiert:

• Welche Subdomains benötigt werden (z.B. login.microsoft.com, account.microsoft.com)
• Welche Cookies abgefangen werden sollen
• Welche Strings in der Response ersetzt werden müssen
• JavaScript-Injektionen für zusätzliche Funktionalität

Beispiel-Struktur:

name: 'example'
min_ver: '3.0.0'
proxy_hosts:
  - {phish_sub: 'login', orig_sub: 'login', domain: 'example.com', session: true}
  - {phish_sub: 'www', orig_sub: 'www', domain: 'example.com', session: false}

auth_tokens:
  - domain: '.example.com'
    keys: ['session_token']

Fertige Phishlets gibt es für Office 365, Google, LinkedIn, GitHub und viele mehr in der Community.

Developer-Perspektive: Phishlets zu verstehen hilft euch, eure eigenen Login-Flows sicherer zu gestalten. Wo sind die kritischen Session-Cookies? Welche Subdomains sind involviert? Das sind wichtige Architektur-Fragen!

6. Wie unterscheidet sich Evilginx Pro von der Open-Source-Version?

Evilginx Pro ist die kommerzielle Variante, die seit Februar 2025 verfügbar ist. Die Unterschiede sind signifikant:

Evilginx2 (Open Source):

• Kostenlos, GPL3-Lizenz
• Community-Support via GitHub
• Basis-Anti-Detection-Features
• BuntDB für Datenspeicherung
• Manuelle Konfiguration notwendig

Evilginx Pro:

• Kostenpflichtig (Zugang über BREAKDEV RED Community)
• Professioneller Support
• Erweiterte Anti-Phishing-Evasion (umgeht Chrome Enhanced Protection)
• SQLite-Datenbank für bessere Performance
• Vereinfachtes DNS-Management
• Bessere Gophish-Integration
• Regelmäßige Updates mit neuen Evasion-Techniken

Compliance-Hinweis: Evilginx Pro hat strenge Verification-Prozesse. Ihr müsst nachweisen, dass ihr in der Cybersecurity-Branche arbeitet. Das ist gut – es hält das Tool aus den falschen Händen.

Entscheider-Perspektive: Für professionelle Red Teams lohnt sich Pro. Für Lern- und Verständniszwecke reicht die Open-Source-Variante völlig aus.

7. Welche Schutzmaßnahmen funktionieren gegen Evilginx-Angriffe?

Evilginx ist mächtig, aber nicht unbesiegbar. Es gibt effektive Gegenmaßnahmen:

Was NICHT schützt:

• ❌ Traditionelle 2FA (SMS, Authenticator-Apps)
• ❌ Nur auf HTTPS achten
• ❌ Email-Security-Gateways allein

Was tatsächlich schützt:

• ✅ Hardware-Keys (FIDO2/U2F): Prüfen die Domain kryptographisch
• ✅ Conditional Access Policies: IP-Whitelisting, Device-Compliance
• ✅ Anomalie-Erkennung: Impossible Travel, neue Devices
• ✅ Security Awareness: Geschulte Mitarbeiter prüfen URLs aktiv
• ✅ Certificate Transparency Monitoring: Erkennt verdächtige Zertifikate
• ✅ Kurze Session-Timeouts: Limitiert die Nutzungsdauer gestohlener Cookies

Technische Implementierung:

• Aktiviert Azure AD Conditional Access mit Device-Compliance
• Implementiert Risk-Based Authentication
• Nutzt Passkeys/WebAuthn statt klassischer 2FA
• Monitort Session-IDs auf ungewöhnliche Zugriffsmuster

Aus der Praxis: Wir haben bei Clients gesehen, dass die Kombination aus Hardware-Keys für Admins und Conditional Access die effektivste Verteidigung ist. User-Training kommt danach.

8. Wie integriert man Evilginx mit Gophish für realistische Kampagnen?

Gophish ist ein Phishing-Framework für Email-Kampagnen. In Kombination mit Evilginx wird daraus ein mächtiges Pen-Test-Toolkit:

Die Rolle von Gophish:

• Email-Versand und Tracking
• Template-Management für Phishing-Mails
• Statistiken über Klick- und Submission-Rates
• Landing-Page-Management

Die Rolle von Evilginx:

• Session-Cookie-Harvesting
• Live-Proxying der echten Website
• 2FA-Bypass-Funktionalität

Integration:
Seit Evilginx 3.3 gibt es eine offizielle Gophish-Integration. Das ermöglicht:

• Automatisches Tracking von Evilginx-Lures in Gophish
• Koordinierte Kampagnen-Verwaltung
• Zentrale Statistiken

Setup-Workflow:

1. Gophish installieren und Email-Templates erstellen
2. Evilginx mit entsprechendem Phishlet konfigurieren
3. Lure-URLs aus Evilginx in Gophish-Campaign einbinden
4. Apache/Nginx als Reverse-Proxy für beide Tools nutzen

Red-Team-Best-Practice: Nutzt separate Subdomains für Gophish (tracking) und Evilginx (phishing). Das trennt die Funktionen sauber und verbessert die Stealth.

9. Wie erkennt und analysiert man Evilginx-Angriffe im Log?

Forensische Analyse von Evilginx-Angriffen erfordert detaillierte Log-Analyse:

Typische Indikatoren:

• Anomale IP-Adressen: Logins aus ungewöhnlichen Geolocations
• User-Agent-Spoofing: Evilginx kopiert den User-Agent des Opfers
• Identische Session-IDs: Zwei verschiedene IPs nutzen die gleiche Session
• Kurze Zeitabstände: Login vom Opfer, unmittelbar danach vom Angreifer
• Certificate Transparency Logs: Neue Zertifikate für ähnliche Domains

Log-Analyse-Beispiel (Azure AD):

Time: 10:15:23 - IP: 198.51.100.50 - User: victim@company.com - SessionID: abc123
Time: 10:15:45 - IP: 203.0.113.75 - User: victim@company.com - SessionID: abc123

Gleiche SessionID, unterschiedliche IPs in 22 Sekunden – klarer Indikator!

Detection-Strategien:

• Implementiert SIEM-Rules für Session-ID-Anomalien
• Monitort DNS-Anfragen auf Typosquatting
• Nutzt Threat Intelligence Feeds für bekannte Phishing-Domains
• Aktiviert Azure AD Identity Protection

Incident-Response-Tipp: Bei Verdacht sofort alle Sessions des betroffenen Users invalidieren. Nicht nur die verdächtige – Angreifer könnten mehrere Cookies abgefangen haben.

10. Welche Entwicklungen gibt es bei Evilginx und ähnlichen Tools?

Das Ökosystem entwickelt sich rasant weiter – ihr müsst am Ball bleiben:

Aktuelle Trends:

• Browser-In-The-Middle (BitM): Evilginx startet einen Headless-Browser, der JavaScript komplett rendert – umgeht Client-Side-Security
• Dynamic Device Code Phishing: OAuth 2.0 Device Authorization Grant wird missbraucht
• Consent Phishing: Statt Credentials zu stehlen, Permissions für OAuth-Apps erlangen
• Cloudflare-Integration: Nutzt CDN für bessere Stealth und DDoS-Protection

Neue Detection-Methoden:

• JA3/JA3S-Fingerprinting: Erkennt TLS-Anomalien von Proxy-Tools
• Content-Based-Detection: Analysiert minimal unterschiedliche Responses
• Certificate Transparency Monitoring: Automatische Alerts bei verdächtigen Certs

Framework-Alternativen:

• Modlishka: Ähnliches Reverse-Proxy-Framework
• CredSniper: Fokus auf Office 365
• Muraena: Modular und erweiterbar

Zukünftige Entwicklungen:
Browser-Hersteller entwickeln aktiv Anti-Evilginx-Features. Chrome’s Enhanced Protection erkennt bereits einige Proxy-Patterns. Der Wettlauf zwischen Angriff und Verteidigung geht weiter.

Strategische Empfehlung: Plant mindestens quartalsweise Security-Updates eurer Authentication-Infrastruktur ein. Was heute schützt, ist morgen vielleicht schon umgangen.

Best Practices aus über 15 Jahren Security-Consulting

Nach unzähligen Penetrationstests und Red-Team-Assessments haben wir bei Never Code Alone folgende Security-Standards etabliert:

✅ Hardware-Keys für privilegierte Accounts: FIDO2-Keys für Admins, Entwickler mit Production-Access
✅ Conditional Access ist Pflicht: Device-Compliance, IP-Whitelisting, Risk-Based-Auth
✅ Security Awareness-Training: Quartalsweise Phishing-Simulationen mit Evilginx-Szenarien
✅ Session-Management überdenken: Kurze Timeouts, Reauthentifizierung bei kritischen Actions
✅ Certificate-Monitoring: Automatische Alerts bei neuen Certs für eure Domains
✅ Incident-Response-Playbooks: Dokumentierte Prozesse für Session-Hijacking-Verdacht

Der entscheidende Vorteil für eure Security-Posture

Evilginx zu verstehen bedeutet nicht, es zu nutzen. Es bedeutet, eure Systeme aus Angreifer-Perspektive zu sehen:

• Wo sind eure kritischen Session-Cookies? Sind sie HttpOnly, Secure, SameSite?
• Wie lange sind eure Sessions gültig? Stunden? Tage? Weeks?
• Erkennt ihr Device-Wechsel? Neue IPs? Unmögliche Reisezeiten?
• Nutzen eure Admins Hardware-Keys? Oder SMS-2FA?

Diese Fragen machen den Unterschied zwischen „wir haben 2FA“ und „wir sind wirklich geschützt“.

Direkte Unterstützung für eure Security-Strategie

Ihr wollt eure Authentication-Architektur gegen moderne Phishing-Angriffe absichern? Oder benötigt ihr ein professionelles Red-Team-Assessment eurer Systeme? Mit über 15 Jahren Expertise in Softwarequalität und Security Consulting helfen wir euch gerne weiter.

Kontakt: roland@nevercodealone.de

Gemeinsam entwickeln wir Security-Konzepte, die funktionieren – keine theoretischen Modelle, sondern praxiserprobte Lösungen die eure Systeme tatsächlich schützen. Von der Security-Analyse über Penetrationstests bis zur Implementierung von Zero-Trust-Architekturen.

Fazit: Angriff verstehen heißt besser verteidigen

Evilginx ist kein Spielzeug – es ist ein professionelles Tool, das die Schwächen moderner Authentication-Systeme gnadenlos aufzeigt. Genau deshalb müsst ihr es verstehen. Nur wer weiß, wie Angreifer denken und arbeiten, kann effektive Verteidigungsstrategien entwickeln.

Die gute Nachricht: Mit den richtigen Maßnahmen – Hardware-Keys, Conditional Access, Security Monitoring – könnt ihr euch effektiv schützen. Die schlechte Nachricht: Diese Maßnahmen erfordern Investment, Training und kontinuierliche Anpassung.

Startet heute: Überprüft eure aktuellen 2FA-Mechanismen. Sind Hardware-Keys für privilegierte Accounts implementiert? Habt ihr Conditional Access aktiviert? Nutzt ihr Session-Anomalie-Erkennung? Jeder Schritt in die richtige Richtung erhöht eure Security-Posture signifikant.

Never Code Alone – Gemeinsam für bessere Software-Sicherheit und resiliente Systeme!