Alles, was Sie über Evil-Proxy-Angriffe und MFA-Bypass wissen müssen

Evil-Proxy-863x300-1.png

Angreifer nutzen bösartige Proxy-Server, um die Kommunikation zwischen einem Client und einem legitimen Server abzufangen, zu überwachen und zu manipulieren – häufig mit dem Ziel, Anmeldedaten, Session-Tokens oder andere sensible Informationen zu stehlen.

Einige Dienste bieten sogenanntes „Phishing-as-a-Service“ (PhaaS) an. Diese Services stellen Angreifern vorgefertigte Tools und Infrastrukturen zur Verfügung, um Phishing-Kampagnen durchzuführen. Damit wird es erheblich einfacher, Benutzer zu täuschen und sie zur Preisgabe sensibler Informationen wie Benutzernamen, Passwörter oder Finanzdaten zu verleiten – da zentrale Schritte des Angriffs automatisiert ablaufen.

Evil Proxies nutzen Methoden wie Reverse Proxy und Cookie Injection, um selbst Zwei-Faktor-Authentifizierungen (2FA bzw. MFA) großer Anbieter wie GitHub, Apple, Okta, Microsoft oder Google zu umgehen.

So funktioniert der Angriff

Evil-Proxies basieren auf dem Reverse-Proxy-Prinzip: Der Angreifer bringt das Opfer dazu, auf einen manipulierten Link zu klicken, der scheinbar auf eine legitime Login-Seite verweist.

Sobald das Opfer versucht, sich anzumelden, wird die Authentifizierungsanfrage vom Evil Proxy an den echten Dienst weitergeleitet. Gleichzeitig fängt der Proxy jedoch die 2FA-Zugangsdaten mithilfe von Cookie Injection ab. Bei der Cookie Injection manipulieren oder platzieren Angreifer Session-Cookies, um sich als legitimer Benutzer auszugeben und Authentifizierungsmechanismen zu umgehen.

Um ihre Erfolgschancen zu erhöhen, geben sich Angreifer als vertrauenswürdige Dienste und Apps wie Concur Solutions, DocuSign und Adobe aus, indem sie legitime Registrierungsprozesse nutzen, die öffentlich verfügbar sind.

Die Phishing-URL mit DocuSign wird von VirusTotal nicht erkannt.

Ein weiteres Beispiel, wie eine vom Angreifer erstellte Phishing-URL (über einen legitimen DocuSign-Absender verschickt wird) das Sicherheits-Gateway für E-Mails umgeht, indem die Anwendung „DocuSign“ als Absender genutzt wird.

EvilProxy-image5.pngDas E-Mail-Sicherheits-Gateway stuft die Phishing-URL als unbedenklich ein.

Evil-Proxy in Aktion

Um zu zeigen, wie einfach und effektiv Evil-Proxy-Angriffe sind, demonstrieren wir einen Angriffsablauf mit dem Phishing-Framework evilginx2. Dieser Angriff zeigt, wie Benutzer zur Preisgabe ihrer Zugangsdaten verleitet werden – selbst bei aktivierter Zwei-Faktor-Authentifizierung. Das sind die Angriffsphasen:

  1. Erstellen einer gefälschten Login-Seite – Nachbildung der echten Login-Oberfläche eines vertrauenswürdigen Dienstes.
  2. Einrichten des Proxy-Servers – Konfiguration von Evilginx2, um den Netzwerkverkehr abzufangen – mit oder ohne Man-in-the-Middle-Attacke (MitM).
  3. Versenden des Phishing-Links über eine legitime App – Täuschend echte Links (z. B. docusign.com) werden durch die Ausnutzung legitimer, öffentlich zugänzlicher Registrierungsprozesse erzeugt und über offiziell aussehende E-Mails an das Opfer versendet (z.B. dse_na2@docusign.net).
  4. Weiterleitung zur Fake-Seite – Das Opfer klickt auf den Link und landet auf der gefälschten Login-Seite.
  5. Eingabe der Zugangsdaten – Das Opfer trägt seine Anmeldedaten ein, in der Annahme, es handle sich um eine echte Seite.
  6. Abgreifen der Anmeldedaten – Evil Proxy protokolliert die eingegebenen Daten.
  7. Weiterleitung der MFA-Anfrage – Falls MFA aktiviert ist, wird die Abfrage an den Angreifer weitergeleitet.
  8. Abrufen des MFA-Codes – Der Angreifer fängt den Code ab (z. B. per MitM) oder täuscht das Opfer, damit es den Code preisgibt.
  9. Eingabe des MFA-Codes – Der Angreifer verwendet den Code, um den Login-Vorgang abzuschließen.
  10. Login beim echten Dienst – Weiterleitung der Zugangsdaten und des MFA-Codes an die echte Plattform.
  11. Datenexfiltration – Zugriff auf das echte Benutzerkonto und Diebstahl sensibler Informationen.
  12. Session Cookies abgreifen – Session-Cookies aus dem Fake-Login werden vom Proxy gesammelt.
  13. Einfügen der Cookies in echte Sitzung – Die gestohlenen Cookies werden genutzt, um Zugriff auf das Konto zu behalten – ohne erneute Anmeldung.

 

Klicken Sie auf „Play“, um das Codebeispiel zu sehen und wie ahnungslose Nutzer dazu gebracht werden, ihre Zugangsdaten preiszugeben.

Der gesamte Angriff lässt sich anhand des folgenden Flussdiagramms leicht visualisieren:

Flussdiagramm zu den Phasen eines Phishing-Angriffs.

So erkennen und blockieren Sie einen Evil Proxy-Angriff

Okta Identity Threat Hunting

Nutzen Sie Ihre Identity-Management-Logs, um Phishing-Versuche zu identifizieren. Nachfolgend finden Sie Erklärungen zu Okta-Nachrichten, die bei der Erkennung potenzieller Bedrohungen helfen:

  • Okta – AiTM-Phishing-Versuch durch FastPass blockiert
    Diese Meldung zeigt an, dass die Phishing-Erkennung von Okta in Kombination mit dem FastPass-Origin-Check ausgelöst wurde. Okta bietet plattformweite Erkennung, wenn sich Benutzer, die bei FastPass registriert sind, nicht authentifizieren können – durch einen Echtzeit-Attacker-in-the-Middle-(AiTM)-Proxy.Event-Eigenschaften:
    Cloud-Plattform: Okta
    okta.outcome.reason: „FastPass declined phishing attempt“
  • Okta – Ungewöhnliche Sitzung mit identischem dtHash/2FA-Token
    Diese Regel erkennt einen Session-Hijacking-Angriff, bei dem ein Angreifer auf Browser-Cookies eines authentifizierten Okta-Nutzers zugreift, indem er nach einem dtHash sucht, der auch bei anderen Nutzern verwendet wurde.Event-Eigenschaften:
    Cloud-Plattform: Okta
    Eventname: („policy.evaluate_sign_on“ ODER „user.session.start“)
    Fehlerausgang: „Success“
    Schwellenwert: Ergebnisse gruppiert nach okta.debug_context.debugData.dtHash >= 2
  • Okta – Benutzer hat Rate-Limit bei fehlgeschlagenen MFA-Versuchen erreicht
    Diese Meldung bedeutet, dass ein Okta-Benutzerkonto das Rate-Limit nach mehreren fehlgeschlagenen MFA-Versuchen erreicht hat. Innerhalb eines rollierenden 5-Minuten-Zeitraums sind maximal fünf fehlgeschlagene Authentifizierungsversuche erlaubt.Event-Eigenschaften:
    Cloud-Plattform: Okta
    Eventname: system.operation.rate_limit.violation
    Fehlermeldung: „Too many OTP verification attempts for Enter a code factor“

EvilProxy-image3.pngOkta ist in der Regel erfolgreich bei der Erkennung und Blockierung von Phishing-Versuchen.

Web-Traffic-Logs

Auch das Monitoring der Netzwerkprotokolle Ihres Unternehmens ist entscheidend, um Authentifizierungsanfragen zu analysieren. Achten Sie darauf, ob sich die Domain der Anfrage von der im Parameter iss (issuer) angegebenen Domain unterscheidet – ein potenzielles Sicherheitsrisiko.

Beispiel zweier aufeinanderfolgender Anfragen:

Erste Anfrage:

okta.loginmt.com/app/userhome?iss=https://okta.loginmt.com&session_hint=AUTHENTICATED
Diese Anfrage erscheint legitim, da die Domain der Anfrage mit der im iss-Parameter übereinstimmt..

Zweite Anfrage:

malicious-okta.com/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED
In der zweiten Anfrage ist malicious-okta.com nicht gleich okta.com, obwohl „okta“ im Namen enthalten ist – es handelt sich um eine völlig andere Domain, die für böswillige Zwecke verwendet werden kann.

Nachfolgend ein einfaches Python-Skript zur Überprüfung, ob die Domain der Anfrage mit der im iss-Parameter angegebenen Domain übereinstimmt:


   import re

   # Example URLs to test
   urls = [
       "https://okta.loginmt.com/app/userhome?iss=https://okta.loginmt.com&session_hint=AUTHENTICATED",  # Legitimate
       "https://malicious-okta.com/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED",       # Potential Malicious
       "https://secure-okta.io/app/userhome?iss=https://secure-okta.io&session_hint=AUTHENTICATED",     # Legitimate
       "https://fake-okta.net/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED"             # Potential Malicious
   ]

   # Improved regex to extract host and iss domains
   pattern = r"^(?:https?:\/\/)?([a-zA-Z0-9.-]+)(?:\/|$).*?[&?]iss=https?:\/\/([a-zA-Z0-9.-]+)"

   print("Malicious URLs:")
   for url in urls:
       match = re.search(pattern, url)
       if match:
           host_domain = match.group(1)
           iss_domain = match.group(2)
           # Flag malicious if host and iss domains don't match
           if host_domain != iss_domain:
               print(f"- {url} (Host: {host_domain}, Iss: {iss_domain})")


 

Threat Intelligence und OSINT

Eine weitere Methode zur Eindämmung potenzieller Bedrohungen ist die Nutzung von Threat-Intelligence-Quellen zur Identifizierung böswilliger Akteure und zur Risikobewertung verdächtiger Domains. Dabei werden bekannte, mit schädlichen Aktivitäten verknüpfte Domains untersucht sowie Domains gesucht, die der URL Ihrer Organisation ähneln.

Die Integration von Indicators of Compromise (IoCs) in verschiedene Systeme wie SIEM, SOAR, E-Mail-Gateways und EDR innerhalb der Sicherheitsinfrastruktur eines Unternehmens ist entscheidend, um die Bedrohungserkennung zu verbessern und eine schnelle Reaktion zu ermöglichen.

  • Indicators of Compromise (IoCs) – Evil Proxy
    Die Indicators of Compromise (IoCs) für Evil Proxy werden laufend aktualisiert, sobald neue Bedrohungen erkannt werden. Für aktuelle Informationen nutzen Sie bitte diesen direkten Link zu den IoCs.

Ablauf, wie Angriffe, die anfangs unauffällig erscheinen, später als bösartig erkannt werden.

Die E-Mail-Gateway- und Web-Traffic-Überwachungssysteme stuften die Angriffs-Domain zunächst als „unbedenklich“ ein. Das Identity-Management-System erkannte jedoch verdächtige Aktivitäten im Zusammenhang mit dieser Domain und blockierte diese teilweise aufgrund festgestellter Anomalien.

Auf Basis dieser Informationen kann das SOAR-System die Domain dynamisch als „bösartig“ klassifizieren und Maßnahmen zur vollständigen Blockierung einleiten – was die Reaktionsfähigkeit der Sicherheitsinfrastruktur deutlich erhöht.

Microsoft 365

Es gibt mehrere Maßnahmen, um potenzielle Angriffe durch eine sichere Konfiguration von Microsoft Office zu verhindern:

  • Implementierung von bedingtem Zugriff über die Microsoft-Office-Lizenz zur Einschränkung des Zugriffs auf bestimmte Geräte, Standorte oder Ressourcen.
  • Konfiguration von Microsoft Intune zur Verweigerung des Zugriffs von nicht vertrauenswürdigen Geräten.

Sensibilisierung der Mitarbeitenden erhöhen

Die Aufklärung der Mitarbeitenden über Sicherheitsrisiken wie Phishing- und Smishing-Methoden trägt wesentlich dazu bei, erfolgreiche Angriffe zu verhindern. Regelmäßige Schulungen, spielerische Lernformate und simulierte Angriffe können das Risiko signifikant senken.

Zudem sollten Mitarbeitende in der Lage sein, Warnsignale zu erkennen – etwa Zertifikatsfehler im Browser, die auf Man-in-the-Middle-Angriffe hinweisen könnten.

Prinzip der geringsten Rechte (“Least-Privilege-Principle”)

Dieses Konzept besagt, dass Nutzern, Prozessen und Systemen nur jene Zugriffsrechte eingeräumt werden, die zur Erfüllung ihrer Aufgaben unbedingt notwendig sind. Vorteile dieses Ansatzes:

  • Zugriff nur auf für die jeweilige Rolle erforderliche Ressourcen
  • Minimierung potenzieller Schäden im Falle einer Kompromittierung
  • Verbesserung der Gesamtsicherheit durch Reduzierung unbefugten Zugriffs
  • Verringerung der Angriffsfläche für Bedrohungsakteure
  • Erfordert regelmäßige Überprüfung und Anpassung von Zugriffsrechten bei sich ändernden Rollen und Zuständigkeiten

Durch diese Begrenzung lassen sich mögliche Schäden bei Kompromittierungen deutlich reduzieren.

Fazit

Bedrohungsakteure suchen ständig nach neuen Wegen, um legitime Zugangsdaten zu stehlen und sich Zugriff auf Benutzerkonten zu verschaffen – mit dem Ziel, an sensible Informationen zu gelangen. Dabei werden laufend neue Methoden entwickelt, um moderne Sicherheitsmechanismen wie Multi-Faktor-Authentifizierung zu umgehen.

Wie gezeigt, gibt es keine Schutzmaßnahme – auch keine MFA –, die absolut sicher ist. Deshalb lohnt es sich, eine Tour zu machen oder eine persönliche Demo zu vereinbaren, um zu sehen, wie JFrogs Advanced Security-Lösungen Ihre Organisation heute und in Zukunft vor potenziellen Angriffen schützen können.