DIGITALES TÄUSCHUNGSSYSTEM

Canary Tokens

Kryptographisch eindeutige Täuschungs-Beacons in DNS-Records, HTTP-Responses und Dokumenten eingebettet — erkennen Recon-Aktivitäten, Credential-Harvesting und laterale Bewegungen mit null False Positives.

0False Positives

HMACToken-Authentisierung

DNS+HTTPCallback-Kanäle

<50msAlert-Latenz

// Token-Generierung & kryptographische Eindeutigkeit

Jeder Canary-Token wird als 32-Byte HMAC-SHA256-Wert generiert, geschlüsselt mit dem eindeutigen Signing-Secret des Tenants und einem monoton steigenden Counter. Das garantiert globale Eindeutigkeit über Tenants hinweg, Resistenz gegen Brute-Force-Enumeration und deterministische Attribution — ein auslösender Token lässt sich immer zum exakten Ziel, Token-Typ und Tenant zurückverfolgen.

def generate_canary_token(
    tenant_id: str,
    target_domain: str,
    token_type: CanaryType,
    counter: int
) -> CanaryToken:
    signing_key = _get_tenant_signing_key(tenant_id)  # 32-Byte-Secret aus DB
    payload = f"{tenant_id}:{target_domain}:{token_type.value}:{counter}"
    raw_token = hmac.new(signing_key, payload.encode(), hashlib.sha256).hexdigest()

    # Als DNS-sicheres 32-Zeichen-Label kodieren (Lowercase-Hex)
    dns_label = raw_token[:32]   # 128-Bit DNS-Label
    http_token = raw_token       # Volle 64 Zeichen für HTTP-Header / Dokument-Embed

    return CanaryToken(
        token=raw_token,
        dns_label=dns_label,
        http_token=http_token,
        target_domain=target_domain,
        token_type=token_type,
        tenant_id=tenant_id,
    )

DNS-Canary (MX-Record)

Ein Canary-MX-Record wird in die DNS-Zone des Ziels injiziert. Jeder DNS-Resolver, der nach dem MX-Record fragt, löst einen Callback über den autoritativen NS aus. Der MX-Wert zeigt auf <token>.canary.yads-security.com — YADS loggt die abfragende IP und den Zeitstempel. Erkennt:

OSINT-E-Mail-Harvesting-Tools
Phishing-Kit-Setup (Angreifer fragt MX ab)
Massen-DNS-Recon-Sweeps

HTTP-Header-Canary

Ein synthetischer X-Canary-Token-Response-Header wird zur HTTP-Antwort des Ziels hinzugefügt. Token wird auch als HTML-Kommentar injiziert. Jede spätere Anfrage mit diesem Token in Referrer oder kopiertem Credential signalisiert aktive Exfiltration. Erkennt:

Credential-Harvesting aus exfiltriertem HTML
Automatisierte Tools die erfasste Header wiedergeben
Insider-Threats die Page-Source kopieren

Dokument-Canary (PDF/DOCX)

Bettet eine eindeutige URL in generierte Reports und PDF-Exporte ein. Wenn das Dokument auf einem nicht autorisierten Gerät geöffnet wird, ruft der PDF-Renderer die URL ab — Callback mit Geolocation, User-Agent und IP. Erkennt:

Exfiltrierte Reports auf Angreifer-Maschinen geöffnet
Dokument-Sharing mit unauthorisierten Dritten
Credential-geernteter Dokumentzugriff

// Callback-Infrastruktur

Alle Canary-Callbacks werden über YADS-kontrollierte Infrastruktur geleitet. DNS-Callbacks verwenden einen dedizierten autoritativen Nameserver; HTTP-Callbacks nutzen einen leichtgewichtigen HTTPS-Endpoint, der loggt und sofort 204 zurückgibt. Keine Daten verlassen die YADS-Instanz — Tokens enthalten niemals Kundendaten.

Kanal	Mechanismus	Geloggte Daten	Latenz
DNS	Autoritativer NS für `*.canary.yads-security.com`	Abfragende IP, Query-Typ, Zeitstempel, Token-ID	< 100 ms
HTTP	HTTPS GET zu `https://c.yads-security.com/t/<token>`	Client-IP, User-Agent, Referer, Accept-Language, Zeitstempel	< 50 ms
SMTP	MX-Record zeigt auf Canary-Mail-Handler	EHLO-Hostname, Sender-Envelope, Quell-IP	~1 s (SMTP)
Dokument	Eingebettete URL durch PDF/Office-Renderer abgerufen	Client-IP, Renderer-String, Geolocation, Zeitstempel	< 500 ms

// Alert-Pipeline & Deduplizierung

Ein einzelner Canary-Trigger kann mehrere Callback-Hits erzeugen. Die Alert-Pipeline dedupliziert nach Quell-IP innerhalb eines 5-Minuten-Fensters und reichert jeden Alert mit GeoIP, ASN und Threat-Intelligence-Kontext an, bevor ein SecurityFinding erstellt wird.

class CanaryAlertPipeline:
    DEDUP_WINDOW = 300  # Sekunden

    def process(self, callback: CanaryCallback) -> Optional[SecurityFinding]:
        # Dedup: gleicher Token + gleiche Quell-IP im Fenster = überspringen
        dedup_key = f"canary:dedup:{callback.token_id}:{callback.source_ip}"
        if self.redis.get(dedup_key):
            return None  # bereits verarbeitet
        self.redis.setex(dedup_key, self.DEDUP_WINDOW, "1")

        # Mit GeoIP + ASN + Threat Intel anreichern
        enrichment = self.enricher.lookup(callback.source_ip)

        return SecurityFinding(
            rule_id="CANARY-001",
            severity=Severity.HIGH,
            title=f"Canary-Token ausgelöst: {callback.token_type}",
            target_id=callback.target_id,
            tenant_id=callback.tenant_id,
            data={
                "token_type": callback.token_type,
                "source_ip": callback.source_ip,
                "country": enrichment.country,
                "asn": enrichment.asn,
                "asn_org": enrichment.asn_org,
                "is_tor": enrichment.is_tor,
                "is_vpn": enrichment.is_vpn,
                "user_agent": callback.user_agent,
            },
        )

// Token-Lebenszyklus & Rotation

Eigenschaft	Wert
Token-Gültigkeit	90 Tage standardmäßig (pro Tenant konfigurierbar)
Rotationsstrategie	Counter-basiert — jeder neue Token hat erhöhten Counter, alte Tokens bleiben während Überlapp-Fenster gültig
Widerruf	Sofort via `DELETE /canary/tokens/{id}` — widerrufene Token-Callbacks werden still verworfen
Audit-Log	Alle Token-Erstellungen, -Rotationen und -Auslösungen in `CanaryEvent`-Tabelle mit vollem Kontext geloggt
Volumenlimit	500 aktive Tokens pro Tenant (CE: 50)
Speicherung	Token-Index in PostgreSQL; Callback-Queue in Redis (TTL 24h für Dedup-Keys)