Skip to content
Brand Protect Docs

Overview

Brand Protect is a brand impersonation monitoring platform. It continuously watches the threat surface around a brand’s online assets — owned domains, brand keywords, and social media handles — and detects impersonation attempts before they cause damage.

What it detects

Section titled “What it detects”
  • Lookalike domains — typosquats (oktoboo.co), homoglyphs (oktoboot.com with lookalike unicode), TLD abuse (oktoboot.org), and keyword variants (oktoboot-wallet.com).
  • Impersonating social profiles — handles that closely resemble a brand’s official handles, found through handle permutation, search dorking, and active platform probing, then matched against the brand with embedding-based identity comparison.

What it does with a finding

Section titled “What it does with a finding”
  1. Discovers candidate lookalikes and impersonating profiles.
  2. Enriches them with DNS, WHOIS/RDAP, TLS, HTTP content, screenshots, and hosting-infrastructure intelligence (IP, ASN, JARM, co-hosting).
  3. Scores them with a weighted model of 29 signals across registration, DNS, brand overlap, TLS, content, visual, infrastructure, and campaign categories — cross-referenced against public threat feeds.
  4. Audits medium+ findings with an LLM that can adjust scores (within bounded knobs), flag false positives, surface overlooked details, and recommend responses.
  5. Reports automatically — a full client PDF and a one-page executive summary are generated at the end of every scan, plus takedown email drafts and completion webhooks.
  6. Learns — analyst triage feedback is fed into a Bayesian learner that adapts the scoring weights over time.

High-level architecture

Section titled “High-level architecture”

Two cooperating applications communicate over a token-authenticated REST API and are orchestrated with Docker Compose.

┌──────────────────────────┐        ┌──────────────────────────────────┐
│   Rails 8.1 web app      │        │   Python 3.14 microservice       │
│   UI, orchestration,     │  REST  │   discovery, enrichment,         │
│   admin, triage,         │◄──────►│   scoring, AI audit, PDF/takedown│
│   reports                │        │   generation                     │
└──────────────────────────┘        └──────────────────────────────────┘
          │                                    │
          ▼                                    ▼
     PostgreSQL 16 ──────────────── Redis 7 ──► GlitchTip (Sentry)
  • The Rails application is the user-facing surface — dashboard, brand profile, triage, admin, and reports — and the orchestration point for scans.
  • The Python microservice performs the heavy network, AI, and document-generation work: domain generation, enrichment, severity scoring, AI audit, PDF reports, and takedown emails.
  • The service-to-service bridge is protected by a shared bearer token (INTERNAL_API_TOKEN) and carries scan status, scoring weights, feedback samples, campaign stats, AI configuration, keyword expansion, report generation, and audit data.
  • Redis carries real-time progress and findings between the Python worker and the Rails consumer via pub/sub, which are then streamed to the browser over ActionCable.

The scan pipeline

Section titled “The scan pipeline”

A scan moves through eight stages:

# Stage Purpose
1 Domain enumeration Generate lookalike permutations from owned domains and inferred keywords
2 Record information RDAP (with WHOIS fallback) registration data
3 Fingerprinting DNS, HTTP, TLS, screenshots, tech detection, infrastructure intelligence
4 Handle enumeration Social handle permutation and platform availability probing (parallel with 2–3)
5 Identity matching Match discovered social profiles to the brand via embeddings
6 Severity assessment Weighted scoring, false-positive suppression, campaign clustering
7 Auditing LLM review of medium+ findings with bounded adjustments
8 Report generation Full + summary PDFs, webhook delivery

Read more in the Scan Pipeline section.

Continue reading

Section titled “Continue reading”