Fraudulent Domain Monitoring

Fraudulent Domain Monitoring ist ein akademisches Teamprojekt zur automatischen Analyse verdächtiger Domains. Lexikalische Merkmale, Unicode, visuelle Ähnlichkeit, JavaScript-Entropie und VirusTotal-Reputation werden zu einem heuristischen Risiko-Score kombiniert. Ein hoher Score ist ein Untersuchungssignal, kein Beweis für Bösartigkeit.

Imitations- und Phishing-Domains unterscheiden sich häufig nur durch Typosquatting, Unicode-Confusables, Punycode, irreführende Subdomains oder auffällige TLD- und Labelkombinationen von vertrauenswürdigen Zielen. Kein einzelnes Merkmal reicht zuverlässig aus; deshalb speichert und gewichtet das System mehrere voneinander unabhängige Teil-Scores.

flowchart LR
    Client --> Server[REST-Server]
    Server --> DB[(MariaDB)]
    Worker --> DB
    Worker --> Pipeline[Scoring Pipeline]
    Pipeline --> Domain[DomainScore]
    Pipeline --> Similarity[WebsiteSimilarityScore]
    Pipeline --> VT[VirusTotalScore]
    Pipeline --> Entropy[JSEntropyScore]
    DB --> Grafana

1. Ein Client übermittelt eine Domain an die REST API.
2. Der Server persistiert einen Analyseauftrag.
3. Ein Worker übernimmt den Auftrag und ruft die Website ab.
4. Die Scoring-Komponenten laufen nebenläufig.
5. Der Score Handler gewichtet und begrenzt das Gesamtergebnis.
6. Status, Gesamtscore und Teil-Scores stehen über API und Grafana bereit.

• DomainScore: Domainstruktur, Markenbezug, Unicode und Typosquatting
• WebsiteSimilarityScore: pHash, SSIM und Histogrammvergleich
• JSEntropyScore: Entropie extrahierter JavaScript-Inhalte
• VirusTotalScore: externe Reputationsinformationen, sofern konfiguriert

Fehler eines externen Dienstes werden als Komponentenfehler behandelt und beenden nicht automatisch die gesamte Analyse.

DomainScore normalisiert Eingaben mit Unicode NFKC, verarbeitet internationalisierte Domains und bewertet Brand-, Token-, Label-, TLD-, Struktur- und Zufallsmerkmale. Enthalten sind unter anderem Homograph-Erkennung, Mixed-Script-Prüfung, Edit Distance, Transpositionen, Punycode und auffällige Zeichenfolgen. Das Ergebnis wird vor der Gewichtung auf 0.0 bis 1.0 begrenzt.

Synthetisches Beispiel: thw5-security-login.test

Interpretation: Die Domain enthält mehrere lexikalische Auffälligkeiten und sollte manuell geprüft werden. Das synthetische Ergebnis behauptet keine tatsächliche Bösartigkeit.

curl --request POST \
  --header "Content-Type: text/plain" \
  --data "example.test" \
  http://127.0.0.1:8080/submit

curl --include http://127.0.0.1:8080/order_status/42

Die API ist ein Hochschulprototyp und keine öffentlich gehärtete Production API.

Die Provisioning-Dateien erzeugen ein Dashboard für Aufträge, Gesamtrisiken, Teil-Scores und Verarbeitungsstatus. Veröffentlicht werden keine Screenshots mit realen Domains oder lokalen Infrastrukturinformationen.

Voraussetzungen: Docker mit Compose v2 und GNU Make.

cp docker/.env_TEMPLATE docker/.env
# VT_API_KEY ausschließlich lokal setzen
make build
make up

Weitere Befehle:

make test
make server_shell
make worker_shell
make down

Die Compose-Konfiguration enthält reine Development-Zugangsdaten und bindet für Worker-Funktionen den Docker Socket ein. Sie darf nicht unverändert in einer nicht vertrauenswürdigen Umgebung betrieben werden.

make test

Der erneut ausgeführte Stand umfasst 424 erfolgreiche Tests für REST API, Persistenz, Scraper, Scorer, Score Handler und Website Similarity. Einige Integrationstests benötigen Docker und die lokale MariaDB-Umgebung.

Dieses Repository dokumentiert ein Teamprojekt. Meine Beiträge umfassten insbesondere:

• Entwicklung und Erweiterung des DomainScore;
• Unicode- und Punycode-Normalisierung;
• Homograph- und Typosquatting-Erkennung;
• Brand-, Token-, Label-, TLD- und Strukturmerkmale;
• Score Handler und Gewichtung;
• Integration des JavaScript-Entropy-Scores;
• Unit- und Integrationstests; sowie
• Grafana-Widgets und Dashboard-Konfiguration.

Weitere Server-, Persistenz-, Scraping-, Similarity- und Betriebsanteile wurden im Team entwickelt.

• Heuristiken können False Positives und False Negatives erzeugen.
• Externe Dienste und VirusTotal-Rate-Limits beeinflussen die Analyse.
• Dynamische Inhalte und Consent-Dialoge begrenzen visuelle Vergleiche.
• Hohe JavaScript-Entropie ist nicht automatisch bösartig.
• Ein hoher Score garantiert keine tatsächliche Bösartigkeit.
• Die Development-Konfiguration ist nicht für direkten Produktivbetrieb gedacht.

Das System entstand als akademisches Teamprojekt an der THWS. Der öffentliche Export enthält keine vollständigen Kopien fremder Websites, fremde Markenassets oder geheime Konfiguration. Eine Lizenz wird ohne gemeinsame Teamentscheidung nicht vergeben.