Was ist Cyber Deception?

Cyber Deception ist eine präventive und proaktive IT-Strategie, die darauf abzielt, einen potenziellen Angreifer in eine Falle zu locken, bevor er Schaden anrichten kann. Der Fokus dieses Beitrags ist die Implementierung einer „Low Tech“ und kostengünstigen Cyber Deception-Maßnahme.

Die vorgestellte Maßnahme wird

1. einen messbaren Effekt haben,
2. kein Betriebsteam erfordern und
3. kein spezielles Security-Tool benötigen.

Zum dritten Punkt ist allerdings anzumerken, dass ein Informationskanal vorhanden sein muss, z. B. E-Mail, Grafana oder SIEM, wenn jemand über das sicherheitsrelevante Ereignis informiert werden soll.

Nun aber die Frage, was ist diese Maßnahme überhaupt und was soll sie bewerkstelligen. Wir wollen Webseiten-Kloning erkennen und darauf reagieren. Sei es, um die Mitarbeiter zu warnen oder die Angreiferdomäne schlicht zu blocken.

Webseiten-Kloning wird gerne bei Phishing- oder als Red Team getarnte Phishing-Kampagnen eingesetzt. Mit dieser Maßnahme kann darauf reagiert und eine beliebte Angriffsfläche geschlossen werden.

Als Ergebnis der Maßnahme sind naiv zwei Szenarien denkbar, entweder man erkennt den Angriff, bevor er gestartet wird oder man erhält die Information, dass ein Angriff im Gange ist. Im Idealfall erkennt man auch, welches Asset betroffen ist.

Was ist Low-Tech?

Ich behaupte, dass Cyber Deception eine Low-Tech-Maßnahme sein kann, die leicht vom IT-Betrieb umsetzbar ist. Bevor ich wie ein Zauberer eine komplexe Lösung mit verschiedenen Tools aus dem Hut ziehe und als „Low-Tech“ anpreise, möchte ich an dieser Stelle kurz darauf eingehen, was eigentlich damit gemeint ist.

Mit „Low-Tech“ ist gemeint, dass keinerlei hoch spezialisiertes Know-how oder Programmierkenntnisse notwendig sind, um das System zu konfigurieren. Die Konfiguration ist ein reines: Parameter rein, Funktionalität raus. Es werden ebenso fertige und erprobte Komponenten verwendet, die aufgrund ihrer Beschaffenheit kein User-Management benötigen.

Es wird in dieser Demonstration ebenfalls auf den Einsatz von externen CDN-Anbietern wie Akamai, Microsoft, AWS etc. verzichtet. Grundsätzlich ist es zwar möglich, einen dieser externen Anbieter zu integrieren, aber es ist nicht zwingend notwendig.

Fallbeispiel: Phishing

Zunächst gibt es verschiedene Formen des Phishing. Um nur einige zu nennen: Smishing (per SMS), über den Kundenservice per Telefon, CEO-Fraud per Mail, Mails mit dubiosen Links und Anhängen, manchmal erpresserisch, manchmal nett. Manchmal mit dem Ziel, Zugangsdaten von Mitarbeitern zu stehlen, manchmal um Zugriff auf Systeme über Malware zu erhalten. Meistens zielgerichtet gegen einzelne Personen (Spear-Phishing).

An dieser Stelle konzentriere ich mich auf Phishing-Mails, die vermeintlich interne Links enthalten und Webseiten-Kloning von Unternehmensseiten nutzen. Die geklonte Webseite sieht dann in der Regel aus wie das Original und nutzt ähnliches CSS. Es wird für die Domäne Punycode oder ähnliche aussehende Namen des Unternehmens verwendet, um den Link und die Webseite echter aussehen zu lassen. Beispielsweise wird aus google.com, ein goolge.com oder gooogle.com.

Aufbau

Das Setup zur Erprobung sieht wie folgt aus:

Wir nehmen an, es gibt eine Angreiferseite, die unsere legitime Seite klonen möchte. Unsere legitime Webseite nutzt einen „CDN“-Server, dies kann auch einfach ein normaler Webserver sein. Beim Klonen der Webseite werden genutzte CSS-URLs üblicherweise nicht angepasst, somit nutzen sowohl unsere legitime Seite als auch die Webseite der Angreifer dasselbe Webseiten-Styling.

Diese Eigenschaft machen wir uns zunutze, um die Cyber Deception-Maßnahme zu implementieren. Auf unseren CDN-Server richten wir Logging ein, um den Ursprung der Anfrage durch das Auslesen des "Referer"-Headers zu erhalten.

Umsetzung

Für die eigentliche Umsetzung der Cyber Deception-Maßnahme müssen nur drei Komponenten betrachtet werden:

• Erweiterung oder Anpassung des CSS unserer Webseite,
• Konfiguration des Webservers, um uns zielgerichtet Logs zu erstellen,
• Einrichtung und Konfiguration eines Tools für das Log-Forwarding, sodass die Logs durch eine Lösung verarbeitet werden können.

Ich nutze als Webserver caddy, da die Konfiguration ausreichend gut dokumentiert ist, ohne Stackoverflow durchsuchen zu müssen. Für das Log-Forwarding ist meine Wahl auf vector von Datadog gefallen. Der Agent ist leichtgewichtig, schnell, die Installation denkbar einfach und die Dokumentation ist ausgezeichnet.

Beide Tools sind Open Source.

CSS-Konfiguration

Damit ein potenzieller Angreifer in unsere kleine Falle tappt, muss das CSS der Webseite angepasst werden. Die folgende Konfiguration des body-Elements stellt sicher, dass sie immer ausgelöst wird. Es können aber auch andere HTML-Elemente verwendet werden.

body {
    background: url('https://cdn.WEBSITE.de/background.png') !important;
}

Wenn eine Website geklont wird, wird in der Regel auch die URL des CSS-Stylings kopiert. Die gängigen Social-Engineering-Toolkits passen URLs im CSS nicht an. Hiermit ist sichergestellt, dass bei jedem Aufruf der geklonten Website der CDN-Server angefragt wird. Bei der Anfrage durch die Fake-Site wird üblicherweise der Referer-Header durch den Browser gesetzt, wodurch wiederum unser Log-Eintrag geschrieben wird.

Diese Konfiguration stellt sicher, dass wir Logs erzeugen, die dann im folgenden Schritt durch eine Observability-Pipeline verarbeitet werden können. Einfachheitshalber schicke ich meine Logs an eine Loki-Instanz mit Grafana; andere Kommunikationskanäle sind ebenfalls möglich.

Caddy-Konfiguration

Zunächst konfigurieren wir Caddy dahingehend, dass eine Log-Datei geschrieben wird, wenn der Referer-Header nicht unserer Domain entspricht. Der Referer-Header wird durch den Browser gesetzt, jedes Mal, wenn ein Bild der Webseite über CSS angefragt wird.

cdn.WEBSITE.de {
    root * /usr/share/caddy
    file_server
    
    @bad_referer {
    	header Referer "https://WEBSITE.de/"
    }
	
    log {
        output file /var/log/caddy/referer.log
    }
    # `log_skip` with newer versions
    skip_log @bad_referer
}

Es gibt einen Edge-Case in der Konfiguration. Der CDN-Server wird direkt angefragt, somit ist der Referer-Header nicht gesetzt. In diesem Fall wird dann ebenfalls ein Log-Eintrag geschrieben. Dieser Sonderfall kann über einen Observability-Agenten behandelt werden.

Caddy schreibt standardmäßig Log-Dateien im JSON-Format. Dieses Format hat keinen besonderen Vorteil gegenüber anderen. Die meisten Observability- oder SIEM-Agenten unterstützen verschiedene Formate.

{
    "level": "error",
    "ts": 1739190378.4174354,
    "logger": "http.log.access.log0",
    "msg": "handled request",
    "request": {
        "remote_ip": "<IP>",
        "remote_port": "43776",
        "proto": "HTTP/2.0",
        "method": "GET",
        "host": "cdn.WEBSITE.de",
        "uri": "/background.png",
        "headers": {
            "Referer": ["https://attacker.ru/"],
            "Sec-Fetch-Mode": ["no-cors"],
            "Priority": ["u=4, i"],
            "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"],
            "Accept": ["image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5"],
            "Accept-Encoding": ["gzip, deflate, br, zstd"],
            "Te": ["trailers"],
            "Accept-Language": ["de,en;q=0.5"],
            "Dnt": ["1"],
            "Sec-Fetch-Dest": ["image"],
            "Sec-Fetch-Site": ["same-site"]
        },
        "tls": {
            "resumed": false,
            "version": 772,
            "cipher_suite": 4865,
            "proto": "h2",
            "server_name": "cdn.WEBSITE.de"
        }
    },
    "user_id": "",
    "duration": 0.000100842,
    "size": 0,
    "status": 404,
    "resp_headers": {
        "Server": ["Caddy"],
        "Alt-Svc": ["h3=\":443\"; ma=2592000"]
    }
}

Vector-Konfiguration

Abschließend betrachten wir noch die vector Konfiguration. Nach Installation des Tools liegt die Konfigurationsdatei üblicherweise unter /etc/vector/vector.toml.

Exkurs: Gängige Begrifflichkeiten bei Observability-Agenten. Ein Observability Agent hat Sources, Transformationen und Sinks. Also eine Verarbeitung an Daten nach dem EVA-Prinzip (Eingabe-Verarbeitung-Ausgabe).

Unsere Source ist die Log-Datei, die Caddy schreibt. Hierzu konfigurieren wir in vector die Source caddy_referer_log, die diese Datei einliest. Wie nachfolgend:

[sources.caddy_referer_log]
type = "file"
exclude = []
file_key = "file"
ignore_not_found = true
include = ["/var/log/caddy/*.log"]
line_delimiter = """

"""

Unser Transformator skip_empty_referer hat als Eingabe unsere Source caddy_referer_log. Der Transformator verarbeitet den Inhalt des .message-Felds. Zunächst wird das JSON unseres Log-Eintrags geparst und falls der Referer-Header nicht gesetzt ist, wird die Verarbeitung abgebrochen. Hiermit wird die korrekte Behandlung des zuvor erwähnten Edge-Case umgesetzt.

[transforms.skip_empty_referer]
type = "remap"
inputs = ["caddy_referer_log"]
source = '''
. = parse_json!(.message)
if !exists(.request.headers.Referer) {
        abort
}
'''

Abschließend wird der Sink grafana_loki definiert. Hier wird die Eingabe des Sinks auf die Ausgabe des Transformators skip_empty_referer konfiguriert. Ebenfalls legen wir das Label service="phishing-detection" fest. Der Codec für die Übermittlung des Log-Eintrags an Loki wird JSON sein.

[sinks.grafana_loki]
type = "loki"
inputs = ["skip_empty_referer"]
endpoint = "https://loki.WEBSITE.de"
labels = {service="phishing-detection"}

[sinks.grafana_loki.encoding]
codec = "json"

[sinks.grafana_loki.auth]
password = "PASS"
user = "USER"
strategy = "basic"

Die vollständige Konfiguration:

data_dir = "/var/lib/vector/"

[sources.caddy_referer_log]
type = "file"
exclude = []
ignore_not_found = true
include = ["/var/log/caddy/*.log"]
line_delimiter = """

"""

[transforms.skip_empty_referer]
type = "remap"
inputs = ["caddy_referer_log"]
source = '''
. = parse_json!(.message)
if !exists(.request.headers.Referer) {
        abort
}
'''

[sinks.grafana_loki]
type = "loki"
inputs = ["skip_empty_referer"]
endpoint = "https://loki.WEBSITE.de"
labels = {service="phishing-detection"}

[sinks.grafana_loki.encoding]
codec = "json"

[sinks.grafana_loki.auth]
password = "PASS"
user = "USER"
strategy = "basic"

Wie geht es weiter?

Nach Durchführung dieser Konfiguration ist die Maßnahme bereits vollständig. Das CSS der eigenen Website wurde angepasst, der Webserver schreibt gezielt Logs, wenn Anfragen mit Referer-Header eingehen und ein Log-Forwarding-Agent wurde deployt. Abschließend muss nur noch eine Alarmierung eingerichtet werden, damit auch jemand informiert wird.

In weiteren Teilen dieser Blogserie werden noch weitere webbasierte Techniken vorgestellt und anschließend Maßnahmen zur Erkennung von Angreifern, wenn diese bereits in das eigene Netz eingedrungen sind.

Ben Stuart (M.Sc.) ist zertifizierter Pentester (OSCP, OSEP, OSWE), Entwickler und IT-Security Berater. Er bringt branchenübergreifende, mehrjährige Erfahrung in der IT-Security mit. Er verfolgt das Ziel, die Herausforderungen der IT-Security Hands-On und pragmatisch zu lösen.

Hat dir der Beitrag gefallen oder hast Anmerkungen, suchst Austausch oder benötigst Unterstützung? Nimm gerne unverbindlich Kontakt auf! Wirf ebenfalls einen Blick auf die Dienstleistungen.