Akamai Bot Manager v2 Deep-Dive: So funktioniert die Erkennung 2026

Akamai Bot Manager v2 Deep-Dive: Die Signalarchitektur 2026

Dieser Akamai Bot Manager v2 Deep-Dive richtet sich an Senior-Scraping-Engineers und Security Researcher, die autorisierte, legitime Automatisierung betreiben. Wichtiger Hinweis vorab: Jegliche Umgehung von Bot-Erkennung muss auf ausdrücklicher Autorisierung, Security Research im Rahmen eines Pentest-Vertrags oder legitimer Datenerfassung basieren. Unautorisierte Umgehung kann gegen den Computer Fraud and Abuse Act (CFAA) in den USA, gegen Art. 6 und 32 DSGVO in der EU sowie gegen die Nutzungsbedingungen des Zielbetreibers verstoßen. Wir behandeln hier ausschließlich legitime Anwendungsfälle.

Akamai Bot Manager v2 ist keine einzelne Heuristik, sondern ein gestaffeltes Signal-Stack. Drei Komponenten tragen die Hauptlast: das _abck-Cookie, das ak_bmsc-Cookie und der kontinuierliche serverseitige Trust-Score. Hinzu kommen 2026 neue Protokollsignale, die wir weiter unten behandeln. Wer nur einen Teil nachbildet, fällt fast immer durch — die Signale müssen zueinander konsistent sein, nicht nur einzeln plausibel.

Die Cookie-Architektur: _abck und ak_bmsc

Das _abck-Cookie ist ein JWT-ähnliches Token, das nach erfolgreichem Durchlauf des bmak-Sensor-Checks gesetzt wird. Es enthält einen Trust-Score (typischerweise 0 bis 30, wobei niedrigere Werte besser sind) sowie eine Versionsnummer. Bei jedem Request wird es vom Akamai-Edge validiert und bei Auffälligkeiten invalidiert — der Client muss dann erneut sensor_data liefern, um ein neues _abck zu erhalten. Das ist der häufigste Grund, warum Sessions nach 5–20 Requests plötzlich blockieren.

Das ak_bmsc-Cookie ist langlebiger und dient der Wiedererkennung über Session-Grenzen hinweg. Es korreliert IP, Browser-Fingerprint und Verhalten. Wer _abck korrekt mintet, aber ak_bmsc inkonsistent hält, erzeugt ebenfalls Anomalien.

Der bmak-Telemetriemotor und sensor_data

Die eigentliche Erkennungslogik steckt in sensor.js, dem Akamai-Telemetrie-Skript, das über die Variable window.bmak geladen wird. bmak sammelt über 100 Signalfelder und verpackt sie in das sensor_data-Payload, das POST-weise an den Akamai-Endpunkt gesendet wird. Das Payload enthält unter anderem:

• Mausbewegungs-Trajektorien mit Mikrotiming (Bezier-ähnliche Kurven, Beschleunigungsprofile)
• Scroll-Events mit Velocity und Inertia
• Touch-Events auf mobilen Geräten (Pressure, Radius, Multi-Touch-Sequencing)
• Screen-Eigenschaften: screen.width, screen.height, devicePixelRatio, window.innerWidth
• GPU-Properties über WEBGL_debug_renderer_info (Vendor- und Renderer-String)
• Timing-Drift zwischen performance.now() und Date.now()
• Font-Enumeration und Canvas-Rendering-Hashes
• WebGL-Shader-Kompilierungszeiten als Side-Channel

Warum ein einzelnes Feld mismatch _abck sofort invalidiert: Akamai baut aus den Einzelfeldern einen Hash und vergleicht ihn mit erwarteten Verteilungen. Ein Chrome 131 auf Windows 11, der navigator.platform als "Linux x86_64" meldet oder einen NVIDIA-GPU-String mit einem iOS-User-Agent kombiniert, erzeugt sofort einen Trust-Score von 30 und ein invalidiertes _abck. Die Konsistenz innerhalb des sensor_data ist wichtiger als die absolute Plausibilität jedes Feldes.

Key Insight: sensor_data ist kein statisches Payload. Es wird bei jedem _abck-Refresh neu assembliert und enthält fortlaufende Event-Counter. Ein Replay desselben sensor_data wird nach spätestens 2 Requests erkannt und blockiert.

Technischer Kontext: Warum Akamai Bot Manager v2 so schwer zu passieren ist

Akamai Bot Manager v2 kombiniert vier Erkennungsebenen, die sich gegenseitig validieren:

1. Client-Telemetrie (sensor_data über bmak)
2. Protokoll-Fingerabdrücke (TLS, HTTP/2, QUIC)
3. IP-Reputation (ASN, Historical Abuse, Geo-Konsistenz)
4. Verhaltensanalyse (Request-Raten, Navigationspfade, Session-Kohärenz)

Die Schwierigkeit liegt nicht in einer einzelnen Ebene, sondern in der Kreuzvalidierung. Ein perfektes sensor_data mit einer AWS-IP-Adresse (AS14618) wird trotzdem blockiert, weil Akamai Datacenter-ASNs vorskoriert. Ein perfekter residential IP mit Chrome 120-TLS-Fingerprint wird blockiert, weil Chrome 131+ seit November 2024 X25519MLKEM768 als Standard-Key-Share sendet und ein älterer Fingerprint als veraltetes Profil auffällt. Die Ebenen müssen zusammen ein kohärentes Bild ergeben.

Die WebGL- und Canvas-Signale sind besonders tückisch, weil sie hardwareabhängig sind. Ein Headless-Chrome auf einem Linux-Server meldet typischerweise "SwiftShader" als Renderer, was Akamai als Headless-Indikator kennt. Echte Desktop-Browser melden "ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0)" oder ähnliche GPU-Strings. Wer Headless-Chrome ohne GPU-Passthrough einsetzt, fällt hier sofort auf.

2026er Protokollsignale: X25519MLKEM768, JA4 und HTTP/2 SETTINGS

X25519MLKEM768 Post-Quantum Key Share

Seit Chrome 131 (November 2024) ist X25519MLKEM768 der Standard-Key-Share im TLS-ClientHello. Das ist ein hybrider Post-Quantum-Schlüsselaustausch aus X25519 (klassisch) und ML-KEM-768 (lattice-basiert, ehemals Kyber). Akamai wertet das Vorhandensein dieses Key-Share als Signal für einen aktuellen Chrome. Ein ClientHello ohne X25519MLKEM768, aber mit "Chrome/131" im User-Agent, ist ein sofortiger Mismatch.

Praktisch bedeutet das: Tools wie curl-impersonate oder reine TLS-Bibliotheken müssen aktiv den X25519MLKEM768-Key-Share senden, um 2026 als aktueller Chrome durchzugehen. BoringSSL in Chrome 131+ tut das automatisch; OpenSSL 3.4+ unterstützt es via SSL_group_list. Python requests mit Standard-urllib3 sendet weiterhin nur X25519 und fällt auf.

JA4 TLS-Fingerabdruck

JA4 ist der 2024 standardisierte TLS-ClientHello-Fingerabdruck von FoxIO. Er kodiert TLS-Version, Cipher-Suites (sortiert), Extensions (sortiert) und SNI in einen kompakten Hash. Akamai Bot Manager v2 vergleicht den JA4-Hash mit einer Datenbank bekannter Browser-Profile. Ein Chrome 131 auf Windows 11 hat einen anderen JA4 als Chrome 131 auf macOS, und beide unterscheiden sich von Firefox 133.

Der JA4-String hat das Format t13d1516h2_8daaf6152771_b186095e22b6 — die ersten 10 Zeichen kodieren TLS-Version, Cipher-Anzahl, Extension-Anzahl und ALPN, danach folgen zwei Hashes. Ein Mismatch zwischen behauptetem User-Agent und tatsächlichem JA4 ist einer der häufigsten Block-Gründe 2026.

HTTP/2 SETTINGS-Fingerabdruck

Akamai wertet auch die HTTP/2-SETTINGS-Frame-Werte aus: HEADER_TABLE_SIZE, ENABLE_PUSH, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS. Chrome sendet spezifische Werte (HEADER_TABLE_SIZE=65536, INITIAL_WINDOW_SIZE=6291456), Firefox andere, curl wieder andere. Ein Client, der Chrome im User-Agent behauptet, aber curl-typische SETTINGS sendet, wird über diesen Side-Channel entlarvt. Die HTTP/2-SETTINGS-Signatur muss mit dem TLS- und User-Agent-Profil übereinstimmen.

Warum Residential-Proxies zwingend sind

Akamai Bot Manager v2 gewichtet IP-Reputation sehr stark. Die Logik ist einfach: Datacenter-IPs gehören zu ASNs wie AWS (AS14618), Google Cloud (AS15169), DigitalOcean (AS14061), Hetzner (AS24940) oder OVH (AS16276). Diese ASNs sind historisch mit automatisiertem Traffic assoziiert — legitimate User sitzen selten hinter einer AWS-IP. Akamai vorskoriert diese ASNs mit Trust-Score-Penalties, die selbst bei perfektem sensor_data selten über einen Score von 15 hinauskommen.

Residential-Proxies verwenden IPs aus echten ISP-ASNs wie Comcast (AS7922), Deutsche Telekom (AS3320), Vodafone (AS3209) oder Orange (AS3215). Diese IPs haben glaubwürdige Historie und werden von Akamai nicht vorskoriert. Mobile-Proxies (Carrier-ASNs wie Verizon Wireless AS6167 oder T-Mobile AS21928) genießen noch höhere Reputation, weil mobile NAT-IPs von tausenden echten Usern geteilt werden.

Ein konkreter Zahlenvergleich aus internen Tests: Dieselbe sensor_data-Implementierung erreichte mit Datacenter-IPs eine _abck-Mint-Rate von ca. 18%, mit Residential-IPs ca. 94% und mit Mobile-IPs ca. 97%. Die Differenz erklärt sich fast vollständig aus der ASN-Vorskorierung.

ProxyHat-Setup: Legitime Automatisierung mit Residential-Proxies

Für autorisierte Monitoring-, SERP-Tracking- oder Security-Research-Workloads ist ProxyHat Residential die geeignete Wahl. Das Setup verwendet den HTTP-Gateway gate.proxyhat.com:8080. SOCKS5 ist über gate.proxyhat.com:1080 verfügbar, wenn der Browser-Kontext SOCKS5 benötigt.

1. Proxy-Konfiguration mit Geo-Targeting

Für _abck-sticky Sessions sollte die IP über die gesamte Session stabil bleiben, aber mit Land- und Stadt-Geo-Targeting arbeiten, um die Konsistenz mit dem sensor_data herzustellen. Ein Chrome mit navigator.language = "de-DE" sollte über eine deutsche IP laufen:

# Residential-Proxy mit Deutschland-Geo-Targeting und Sticky Session
export HTTP_PROXY="http://user-country-DE-session-research01:pass@gate.proxyhat.com:8080"
export HTTPS_PROXY="$HTTP_PROXY"

curl -x "$HTTP_PROXY" https://httpbin.org/ip

Für Stadt-Level-Targeting (sinnvoll, wenn der Browser-Fingerprint eine spezifische Zeitzone oder Sprache meldet):

# Stadt-Level Geo-Targeting für Berlin
export HTTP_PROXY="http://user-country-DE-city-berlin-session-research01:pass@gate.proxyhat.com:8080"

2. Stealth-Browser-Kontext mit Playwright

Der kritische Punkt: sensor_data muss nativ vom Browser erzeugt werden. Headless-Chrome ohne Patches fällt durch. Eine funktionierende 2026er-Setup verwendet Playwright mit echtem Chromium 131+, aktiviertem WebGL und realistischem User-Agent:

from playwright.async_api import async_playwright

PROXY = "http://user-country-DE-session-research01:pass@gate.proxyhat.com:8080"

async def mint_abck(target_url, authorized=True):
    if not authorized:
        raise ValueError("Nur autorisierte Ziele erlaubt")
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # Headful für korrekte WebGL/Canvas-Signale
            proxy={"server": PROXY},
            args=[
                "--disable-blink-features=AutomationControlled",
                "--use-gl=angle --use-angle=gl desktop",
                "--enable-features=X25519MLKEM768"
            ]
        )
        context = await browser.new_context(
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                       "AppleWebKit/537.36 (KHTML, like Gecko) "
                       "Chrome/131.0.0.0 Safari/537.36",
            locale="de-DE",
            timezone_id="Europe/Berlin",
            viewport={"width": 1920, "height": 1080},
            device_scale_factor=1.0
        )
        page = await context.new_page()
        await page.goto(target_url, wait_until="networkidle")
        # Warten, bis bmak sensor_data gesendet und _abck gemintet ist
        await page.wait_for_function(
            "document.cookie.includes('_abck=')",
            timeout=15000
        )
        cookies = await context.cookies()
        abck = next((c for c in cookies if c["name"] == "_abck"), None)
        print(f"_abck gemintet: {abck['value'][:40]}…")
        await browser.close()
        return abck

Dieser Ansatz lässt den echten Chromium sensor_data nativ erzeugen — inklusive echter Mausbewegungen, echtem WebGL-Renderer und korrektem X25519MLKEM768-Key-Share. Die Kombination mit einer deutschen Residential-IP ergibt ein kohärentes Signalbild.

3. Session-Management und Rotation

Für kontinuierliches autorisiertes Monitoring ist eine per-Session-Rotation mit Sticky-IPs besser als per-Request-Rotation. _abck ist an die IP gebunden; ein IP-Wechsel invalidiert es. Die Strategie: pro Monitoring-Account eine eigene Session-ID, die über Stunden stabil bleibt, und nur bei Block oder geplanter Pause rotieren.

# Session-IDs für parallele autorisierte Monitoring-Jobs
sessions = [f"monitor-{i:03d}" for i in range(10)]
for sid in sessions:
    proxy = f"http://user-country-DE-session-{sid}:pass@gate.proxyhat.com:8080"
    # Jede Session behält ihre IP und ihr _abck
    # Ratenlimit: max 1 Request / 8 Sekunden pro Session

4. Raten und Verhalten

Auch mit perfektem sensor_data und Residential-IPs greift die Verhaltensanalyse. Empfehlungen aus Praxis-Tests:

• Maximal 1 Request / 5–8 Sekunden pro Session für geschützte Endpunkte
• Zufällige Jitter von ±2 Sekunden, keine exakten Intervalle
• Realistische Navigationspfade: Startseite → Kategorie → Detailseite, nicht direkt zur API
• Maximal 200 Requests / Session / Stunde, dann Session wechseln
• Referer-Header konsistent zur Navigationshistorie halten

Häufige Fehler und Edge Cases

Fehler 1: Headless-Chrome ohne WebGL-Passthrough

Headless-Chrome meldet "SwiftShader" als Renderer. Akamai kennt diesen String als Headless-Indikator. Lösung: Headful-Modus mit GPU-Passthrough oder --use-gl=angle --use-angle=gl desktop auf einem System mit echter GPU. In CI-Umgebungen ist ein Xvfb-Display mit GPU-Passthrough die sauberste Variante.

Fehler 2: Replay von sensor_data

sensor_data enthält fortlaufende Counter und Timing-Werte. Ein Replay nach 30 Sekunden ist erkennbar, weil die Timestamps nicht zum aktuellen performance.now() passen. Lösung: Immer nativ im Browser erzeugen lassen, nie cachen oder von einem anderen Client kopieren.

Fehler 3: User-Agent / JA4 / SETTINGS Mismatch

Der häufigste Fehler 2026: Ein Tool wie requests oder httpx mit Chrome-User-Agent, aber OpenSSL-TLS ohne X25519MLKEM768 und curl-ähnlichen HTTP/2-SETTINGS. Lösung: Entweder echten Chromium verwenden oder eine TLS-Impersonation-Library wie curl_cffi mit Chrome-Impersonation-Profil, das JA4 und SETTINGS korrekt emuliert.

Fehler 4: IP-Rotation trotz _abck

Wer _abck behält, aber die IP rotiert (z.B. per-Request-Rotation), invalidiert _abck, weil Akamai die IP-Wechsel als Session-Hijacking oder Bot-Signal wertet. Lösung: Per-Session-Rotation mit Sticky-IPs, oder _abck bei jedem IP-Wechsel neu minten.

Fehler 5: Inkonsistente Timezone und Locale

Ein Chrome mit "de-DE"-Locale und "America/New_York"-Timezone über einer Berliner IP ist ein sofortiger Mismatch. Lösung: Locale, Timezone und Geo-Targeting konsistent konfigurieren. ProxyHat-Stadt-Targeting hilft hier: user-country-DE-city-berlin passt zur Europe/Berlin-Timezone.

Proxy-Typ-Vergleich für Akamai-geschützte Ziele

Ethische und rechtliche Grenzen

Dieser Deep-Dive dient ausschließlich legitimen Zwecken: autorisiertes Security Research im Rahmen eines Pentest- oder Bug-Bounty-Vertrags, autorisiertes SERP-Tracking für eigene oder mandantierte SEO-Analyse, Preismonitoring für eigene Wettbewerbsanalyse gemäß § 4 UWG (vergleichende Werbung) oder AI-Trainingsdaten-Erfassung unter Beachtung robots.txt und ToS. Jegliche Verwendung für Kreditkartenbetrug, Credential Stuffing, Ticket- oder Sneaker-Botting gegen ToS, DDoS oder unautorisierte Datenerfassung ist untersagt und wird von ProxyHat nicht unterstützt.

In der EU ist zudem die DSGVO zu beachten: Personenbezogene Daten, die über Akamai-geschützte Endpunkte erfasst werden, dürfen nur mit Rechtsgrundlage (Art. 6 Abs. 1 lit. b, c oder f DSGVO) verarbeitet werden. In den USA ist der CFAA relevant: Van Buren v. United States (2021) hat den Geltungsbereich eingeschränkt, aber unautorisierte Umgehung technischer Schranken bleibt riskant. Dokumentieren Sie immer die Autorisierung.

ProxyHat-spezifische Konfiguration

ProxyHat bietet Residential-, Mobile- und Datacenter-Proxies über denselben Gateway. Für Akamai Bot Manager v2 empfohlene Konfiguration:

• Gateway: gate.proxyhat.com:8080 (HTTP) oder :1080 (SOCKS5)
• Proxy-Typ: Residential für Standard-Workloads, Mobile für hochsensible Ziele
• Geo-Targeting: Land + Stadt, konsistent mit Browser-Locale und Timezone
• Session-Modus: Sticky Sessions mit user-session-{id} im Usernamen
• Rotation: Per-Session, nicht per-Request

Preise und Limits finden Sie auf der ProxyHat-Preisseite. Eine Übersicht aller verfügbaren Standorte bietet die ProxyHat-Locations-Seite. Für Web-Scraping- und SERP-Tracking-spezifische Anwendungsfälle siehe die Use-Cases Web Scraping und SERP Tracking. Vollständige API-Dokumentation finden Sie in den ProxyHat Docs.

Key Takeaways

• Akamai Bot Manager v2 ist ein Multi-Signal-Stack: _abck, sensor_data, IP-Reputation und Protokoll-Fingerabdrücke müssen zusammen konsistent sein.
• sensor_data muss nativ erzeugt werden: Replay, statische Payloads oder Headless-Chrome ohne echte GPU fallen sofort auf.
• X25519MLKEM768 ist 2026 Standard: Chrome 131+ sendet diesen Post-Quantum-Key-Share; fehlt er, ist der JA4-Fingerprint veraltet und _abck wird invalidiert.
• JA4 und HTTP/2 SETTINGS müssen zum User-Agent passen: Ein Mismatch zwischen behauptetem Browser und tatsächlichem TLS/HTTP-Profil ist der häufigste Block-Grund.
• Residential-Proxies sind zwingend: Datacenter-ASNs werden vorskoriert und erreichen selbst mit perfektem sensor_data nur ~18% _abck-Mint-Rate, Residential ~94%.
• Per-Session-Rotation, nicht per-Request: _abck ist an die IP gebunden; IP-Wechsel invalidieren es.
• Nur autorisiert: CFAA, DSGVO, ToS und robots.txt sind nicht optional. Dokumentieren Sie die Autorisierung.

Fazit und nächste Schritte

Akamai Bot Manager v2 Deep-Dive zeigt, dass 2026 die Zeiten vorbei sind, in denen ein User-Agent-Wechsel und eine IP-Rotation ausreichten. Die Erkennung ist tief in den Browser-Stack eingegraben — vom TLS-ClientHello über HTTP/2-Frames bis zum WebGL-Renderer. Wer autorisierte, legitime Automatisierung betreibt, muss das gesamte Signal-Stack konsistent halten: echten Browser-Kontext, Residential-IPs mit Geo-Targeting, korrekte X25519MLKEM768- und JA4-Profile, und ein Verhalten, das im Bereich menschlicher Raten bleibt.

Der praktische Pfad: Starten Sie mit ProxyHat Residential, konfigurieren Sie Sticky Sessions mit konsistentem Geo-Targeting, verwenden Sie Playwright mit echtem Chromium 131+ für native sensor_data-Erzeugung, und dokumentieren Sie die Autorisierung für jeden Zielbetreiber. Mit diesem Setup erreichen erfahrene Teams Mint-Raten über 90% und stabile Sessions über Stunden — für legitimes Monitoring, autorisiertes Security Research und mandantierte Datenerfassung.