Akamai Bot Manager v2 Deep-Dive: Signale, sensor_data und saubere Automation 2026

Akamai Bot Manager v2 Deep-Dive: Was 2026 anders ist

Akamai Bot Manager v2 ist 2026 einer der anspruchsvollsten Client-Side- und Server-Side-Bot-Schilde im Enterprise-Umfeld. Ein Akamai Bot Manager v2 Deep-Dive lohnt sich für jeden, der autorisierte Automation, SERP-Tracking oder Sicherheitsforschung an geschützten Zielen betreibt — denn die Detection hat sich von simplen Header-Checks zu einem kontinuierlichen, mehrschichtigen Trust-Modell entwickelt. Wer akamai bot detection 2026 ernst nimmt, muss verstehen, dass ein einzelner Fingerabdruck-Fehler genügt, um eine Session dauerhaft zu markieren.

Wichtiger Hinweis: Dieser Artikel richtet sich an autorisierte Sicherheitsforschung, legitimes Monitoring und Compliance-gerechte Automation. Jede Form von unbefugtem Zugriff kann unter den Computer Fraud and Abuse Act (CFAA) und die DSGVO/GDPR fallen. Prüfen Sie vor jedem Einsatz die Nutzungsbedingungen des Ziels und holen Sie bei kommerziellem Scraping rechtlichen Rat ein.

Der Kern von Bot Manager v2 besteht aus drei Komponenten, die zusammenwirken: dem _abck-Cookie als primärem Trust-Token, dem ak_bmsc-Cookie als Session-Bootstrapper und dem sensor.js / bmak-Telemetriemodul, das kontinuierlich Verhaltens- und Umgebungsdaten sammelt. Anders als bei v1 gibt es keinen einmaligen „Challenge bestanden“-Zustand — der Trust-Score wird serverseitig fortlaufend neu berechnet. Das bedeutet: Selbst nach einer erfolgreichen _abck-Mintung kann eine spätere Anomalie den Score kippen und nachfolgende Requests blockieren.

Wer einen akamai bot manager bypass anstrebt, sollte diesen Begriff weniger als „Hacking“ und mehr als „korrektes Nachahmen eines legitimen Clients“ verstehen. Akamai sucht nicht nach einem einzelnen Bösewicht-Signal, sondern nach Kohärenz: Müssen alle Signale — TLS, HTTP/2, JavaScript-Umgebung, Verhalten und IP-Reputation — zu einem konsistenten Bild eines menschlichen Nutzers auf einem echten Endgerät passen.

Die Signal-Stack: _abck, ak_bmsc und der serverseitige Trust-Score

Akamai Bot Manager v2 nutzt eine mehrschichtige Cookie- und Telemetrie-Architektur. Die wichtigsten Komponenten:

• ak_bmsc: Wird beim ersten Request gesetzt, typischerweise mit einer Lebensdauer von ca. 7 Tage. Es dient als Session-ID und verweist serverseitig auf den bisherigen Trust-Verlauf.
• _abck: Das zentrale Trust-Token. Es wird nach der Ausführung von sensor.js gesetzt und enthält einen kryptografischen Hash, der aus der sensor_data berechnet wird. Ein gültiges _abck mit dem Wert ~-1~-1~-1 oder ähnlich bedeutet „Challenge ausstehend“; erst wenn der Hash korrekt ist, gilt die Session als vertrauenswürdig.
• bmak / sensor.js: Ein stark obfuskatiertes JavaScript-Modul, das im Browser läuft und kontinuierlich Telemetrie sammelt. Es wird bei jedem Page-Load und bei jedem relevanten User-Event ausgeführt.

Der serverseitige Trust-Score ist kontinuierlich. Akamai bewertet nicht nur den initialen Page-Load, sondern jede nachfolgende Anfrage anhand von Geschwindigkeit, Konsistenz und Abweichung vom bisherigen Verhaltensprofil. Eine Session, die 5 Minuten lang menschlich aussieht und dann plötzlich 40 Requests in 2 Sekunden feuert, wird sofort herabgestuft — selbst wenn _abck initial gültig war.

Wie sensor_data assembliert wird — und warum ein Feld _abck invalidiert

Das sensor_data-Payload ist das Herzstück der Akamai-Detection. Es wird von bmak im Browser als verschlüsselter, base64-kodierter String erzeugt und bei jedem sensor.js-Submit an den Server gesendet. Die sensor_data akamai-Assembly zieht Daten aus Dutzenden von Quellen:

Verhaltenssignale

• Mausbewegungen: X/Y-Koordinaten, Geschwindigkeit, Beschleunigung, Bezier-Kurven-Charakteristik.
• Scroll-Events: Geschwindigkeit, Richtung, „flüssig“ vs. „treppenartig“.
• Touch-Events (mobil): Druck, Fläche, Multi-Touch-Muster.
• Tastatur-Events: Key-Down/Up-Timing, Inter-Key-Delay.

Umgebungs- und Geräte-Eigenschaften

• Screen-Eigenschaften: screen.width, screen.height, devicePixelRatio, colorDepth.
• GPU-Properties via WEBGL_debug_renderer_info: Renderer-String, Vendor-String. Ein Headless-Browser, der „SwiftShader“ meldet, ist sofort entlarvt.
• Canvas-Fingerprint: Ein gerenderter Text-String, der hardware-spezifische Pixelabweichungen enthält.
• AudioContext-Fingerprint: Unterschiede in der Sample-Rate und DSP-Verarbeitung.
• Navigator-Eigenschaften: navigator.platform, navigator.hardwareConcurrency, navigator.deviceMemory, navigator.languages, Plugin-Liste.

Timing-Signale

• performance.now()-Auflösung: Headless-Browser liefern oft ganzzahlige Millisekunden, echte Browser Sub-Millisekunden.
• Zeit zwischen sensor.js-Ladebeginn und Submit: Zu schnell (< 200 ms) ist genauso verdächtig wie zu langsam.
• requestAnimationFrame-Timing: Ein echtes Display rendert bei ~16,67 ms pro Frame (60 Hz); ein virtueller Display kann abweichen.

Die sensor_data wird in einem spezifischen Feld-Layout assembliert, das Akamai regelmäßig rotiert. Jedes Feld hat eine Position und eine erwartete Wertemenge. Ein einziger Feld-Mismatch — etwa ein navigator.platform-Wert von „Win32“ kombiniert mit einem Canvas-Fingerprint, der auf eine ARM-GPU hindeutet — invalidiert das gesamte _abck-Cookie sofort. Der Server setzt dann ein neues _abck mit „Challenge ausstehend“ und erzwingt einen erneuten sensor.js-Durchlauf, der bei wiederholtem Mismatch zur dauerhaften Blockade führt.

Die wichtigste Erkenntnis: Akamai sucht nicht nach „gut genug“, sondern nach interner Konsistenz. Ein Browser-Profil, das in 47 von 48 Feldern korrekt ist und in einem Feld widersprüchlich, ist verdächtiger als ein komplett neutrales Profil.

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

Im Jahr 2026 reicht es nicht mehr, nur die JavaScript-Umgebung zu fälschen. Akamai Bot Manager v2 korreliert die behauptete User-Agent-Identität mit Protokoll-Fingerabdrücken, die der Client nicht ohne weiteres manipulieren kann. Die wichtigsten drei:

1. X25519MLKEM768 — Post-Quantum Key Share

Seit Chrome 131+ ist der hybride Post-Quantum-Key-Share X25519MLKEM768 in der TLS-ClientHello standardmäßig aktiviert. Das bedeutet, dass ein echter Chrome-131+-Client in der key_share-Extension einen 768-Byte-ML-KEM-Public-Key plus einen 32-Byte-X25519-Public-Key sendet. Ein Scraping-Tool, das einen Chrome-131-User-Agent behauptet, aber eine ältere OpenSSL/BoringSSL-Bibliothek ohne ML-KEM-Support nutzt, sendet keinen solchen Key-Share — und ist sofort entlarvt. Der IETF-Draft zu X25519MLKEM768 spezifiziert die genaue Encoding-Form.

Konkret: Wenn Ihr HTTP-Client einen UA-String von Mozilla/5.0 ... Chrome/131.0.0.0 ... sendet, aber die TLS-ClientHello keinen X25519MLKEM768-Key-Share enthält, weiß Akamai sofort: Dieser Client lügt über seine Identität.

2. JA4 TLS-Fingerprint

Der JA4-Fingerprint ist der de facto Standard für TLS-Client-Profiling im Jahr 2026. Er kodiert in einem String wie t13d1516h2_8daaf6152771_b186095e22b6 die TLS-Version, die Cipher-Suite-Liste, die Extensions und die ALPN-Protokolle. Akamai pflegt eine Datenbank bekannter JA4-Strings pro Browser-Version. Ein Chrome-131 auf Windows 10 hat einen anderen JA4 als ein Chrome-131 auf macOS 14 — und ein Python-requests-Client mit gefälschtem Chrome-UA hat wieder einen völlig anderen JA4.

3. HTTP/2-SETTINGS-Fingerprint

Neben TLS wertet Akamai auch die HTTP/2-SETTINGS-Frame aus. Die Reihenfolge und Werte der Parameter (HEADER_TABLE_SIZE, ENABLE_PUSH, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_FRAME_SIZE, MAX_HEADER_LIST_SIZE) sind pro Client-Implementierung charakteristisch. Chrome sendet eine bestimmte Sequenz; Firefox eine andere; requests mit hyper oder httpx wieder eine andere. Wenn der UA Chrome behauptet, die HTTP/2-SETTINGS aber von hyper stammen, ist das ein sofortiger Mismatch.

Fazit: Alle drei Signale — TLS-ClientHello (JA4), Post-Quantum-Key-Share und HTTP/2-SETTINGS — müssen mit dem behaupteten User-Agent übereinstimmen. Ein konsistentes Profil bedeutet: Wenn Sie Chrome 131 auf Windows simulieren, muss Ihr TLS-Stack tatsächlich Chrome-131-Cipher-Reihenfolge, Chrome-131-Extensions, Chrome-131-ALPN und Chrome-131-HTTP/2-SETTINGS produzieren. Das geht nur mit einem echten Chromium-basierten Browser oder einem sorgfältig kalibrierten TLS-Library wie utls plus HTTP/2-Fingerprint-Matching.

Warum Residential Proxies bei Akamai unverzichtbar sind

Akamai Bot Manager v2 gewichtet die IP-Reputation massiv. Die IP-Adresse ist nicht das einzige Signal, aber sie ist ein Hard-Filter: Wenn die ASN bereits als Datacenter oder Hosting-Provider klassifiziert ist, wird der Trust-Score von vornherein niedrig angesetzt — unabhängig davon, wie perfekt die sensor_data ist. Datacenter-ASNs wie AWS, Hetzner, OVH oder DigitalOcean werden von Akamai vorgeschlagen als Bot-Ursprünge markiert, typischerweise mit einem Basis-Trust-Score, der unter dem Schwellwert für ungestörten Zugriff liegt.

Die folgende Tabelle vergleicht die drei Proxy-Typen im Kontext von Akamai Bot Manager v2:

Proxy-Typ	IP-Reputation bei Akamai	ASN-Profil	Typische Erfolgrate	Einsatz bei Akamai
Residential	Hoch (echte ISP-Adressen)	Tausende ASNs verteilt	90–98 %	Primärwahl für geschützte Ziele
Mobile	Sehr hoch (Carrier-IPs)	~50 Carrier-ASNs weltweit	95–99 %	App-API-Tracking, mobile Endpunkte
Datacenter	Niedrig (vordefiniert als Bot)	Bekannte Hosting-ASNs	< 30 %	Nicht empfohlen für Akamai-geschützte Ziele

Residential Proxies sind nicht nur wegen der ASN wichtig. Akamai korreliert auch Geo-Konsistenz: Wenn der UA de-DE behauptet, die IP aber in Brasilien registriert ist, ist das ein weiterer Mismatch. Mit ProxyHat können Sie das Land — und in vielen Fällen die Stadt — explizit setzen, sodass IP-Geo und behauptetes Browser-Locale übereinstimmen.

Praktische Implementierung mit ProxyHat und einem Stealth-Browser

Um Akamai Bot Manager v2 sauber zu passieren, benötigen Sie drei Dinge: einen echten oder echtnahen Browser-Kontext (damit sensor.js korrekt läuft), konsistente Protokoll-Fingerabdrücke (damit JA4 und HTTP/2 zum UA passen) und Residential Proxies mit Geo-Targeting (damit die IP-Reputation stimmt). Im Folgenden ein praktischer Ansatz mit ProxyHat.

Schritt 1: ProxyHat-Residential-Proxy via curl testen

Zuerst ein einfacher Test, ob die Proxy-Verbindung funktioniert und eine saubere IP liefert:

curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
  -s https://api.ipify.org

Wenn die zurückgegebene IP eine US-Residential-Adresse ist (prüfbar via WHOIS/ASN-Lookup), ist der Proxy einsatzbereit.

Schritt 2: Python mit Playwright und Stealth-Konfiguration

Playwright mit einem echten Chromium-Browser ist die zuverlässigste Methode, da sensor.js in einem echten V8-Kontext läuft und alle Canvas/WebGL/AudioContext-Fingerabdrücke nativ erzeugt werden:

from playwright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US",
    "password": "pass",
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy=PROXY,
        headless=True,
        args=[
            "--disable-blink-features=AutomationControlled",
        ],
    )
    context = 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"
        ),
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
    )
    page = context.new_page()
    page.goto("https://example.com/", timeout=30000)

    # sensor.js benötigt Zeit zum Laden und Ausführen
    page.wait_for_timeout(5000)

    cookies = context.cookies()
    abck = [c for c in cookies if c["name"] == "_abck"]
    print(f"_abck gesetzt: {bool(abck)}")
    print(f"_abck Wert: {abck[0]['value'] if abck else 'nicht vorhanden'}")

    browser.close()

Wichtig: Der user_agent, locale, timezone_id und die Proxy-Geo (user-country-US) müssen alle übereinstimmen. Ein US-Proxy mit timezone_id="Europe/Berlin" und locale="de-DE" ist ein sofortiger Konsistenz-Bruch.

Schritt 3: Node.js mit Puppeteer-Stealth

Alternativ in Node.js mit puppeteer-extra und dem Stealth-Plugin, das bekannte Headless-Indikatoren patcht:

const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');
puppeteer.use(StealthPlugin());

(async () => {
  const browser = await puppeteer.launch({
    headless: 'new',
    args: [
      '--proxy-server=http://user-country-US:pass@gate.proxyhat.com:8080',
      '--disable-blink-features=AutomationControlled',
    ],
  });

  const page = await browser.newPage();
  await page.setUserAgent(
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64) ' +
    'AppleWebKit/537.36 (KHTML, like Gecko) ' +
    'Chrome/131.0.0.0 Safari/537.36'
  );
  await page.setViewport({ width: 1920, height: 1080 });

  await page.goto('https://example.com/', { waitUntil: 'networkidle2' });
  await page.waitForTimeout(5000);

  const cookies = await page.cookies();
  const abck = cookies.find(c => c.name === '_abck');
  console.log('_abck:', abck ? abck.value : 'nicht gesetzt');

  await browser.close();
})();

Schritt 4: Sticky Sessions für Multi-Request-Konsistenz

Akamai trackt die IP über die gesamte Session. Wenn Sie für jeden Request eine neue IP verwenden, wird das als Bot-Verhalten interpretiert. Verwenden Sie Sticky Sessions, um dieselbe IP für die Dauer einer logischen Session zu halten:

# Session-ID in der Username-Flag
# Alle Requests mit derselben session-abc123 nutzen dieselbe IP
http://user-session-abc123-country-US:pass@gate.proxyhat.com:8080

In Playwright:

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-session-abc123-country-US",
    "password": "pass",
}

Weitere Details zu Session-Flags und Geo-Targeting finden Sie in der ProxyHat-Dokumentation. Eine Übersicht aller verfügbaren Standorte finden Sie auf der ProxyHat-Locations-Seite.

Häufige Fehler und Edge Cases

Fehler 1: requests/httpx mit gefälschtem UA

Der häufigste Fehler ist der Einsatz von requests oder httpx mit einem manuell gesetzten Chrome-User-Agent. Das funktioniert bei Akamai nie, weil der JA4-Fingerprint von Python's SSL-Stack nicht mit Chrome übereinstimmt. Selbst curl-impersonate muss exakt auf die Ziel-Browser-Version kalibriert sein.

Fehler 2: Headless-Browser ohne Stealth-Patches

Ein nackter puppeteer.launch({headless: true}) verrät sich durch navigator.webdriver === true, fehlende Plugins, window.chrome-Abwesenheit und „SwiftShader“ als WebGL-Renderer. Der puppeteer-extra-plugin-stealth patcht die meisten dieser Signale, aber nicht alle — insbesondere der Canvas-Fingerprint bleibt hardware-abhängig.

Fehler 3: Zu schnelle Interaktion

Wenn der Browser nach dem Page-Load sofort Buttons klickt oder Formulare absendet, ohne dass Mausbewegungen oder Scroll-Events stattfanden, ist die sensor_data verhaltensleer. Akamai erwartet mindestens minimale Mausbewegung. Simulieren Sie realistische Interaktion:

# Playwright: Mausbewegung simulieren
page.mouse.move(500, 300)
page.mouse.move(520, 310)
page.wait_for_timeout(800)
page.mouse.click(520, 310)

Fehler 4: IP-Rotation mid-Session

Wenn Sie mitten in einer Akamai-Session die Proxy-IP wechseln (z. B. durch rotierende Residential Proxies ohne Sticky-Session), invalidiert das _abck sofort. Die IP ist Teil des serverseitigen Trust-Profils. Verwenden Sie immer Sticky Sessions für die Dauer einer logischen Interaktion.

Fehler 5: Inkonsistente Timezone und Locale

JavaScript kann Intl.DateTimeFormat().resolvedOptions().timeZone abfragen. Wenn der Proxy in den USA sitzt, die Timezone aber Europe/Berlin ist und das Locale en-US, ist das ein dreifacher Mismatch. Setzen Sie alle drei konsistent:

context = browser.new_context(
    locale="en-US",
    timezone_id="America/New_York",
    geolocation={"latitude": 40.7128, "longitude": -74.0060},
    permissions={"geolocation": "granted"},
)

Einsatzbereiche: Wo das legitim ist

Die Techniken in diesem Artikel sind legitim für:

• Autorisierte Sicherheitsforschung: Penetration Testing mit schriftlicher Erlaubnis des Zielbetreibers.
• Marktpreismonitoring: Verfolgung öffentlich sichtbarer Preise bei eigenen Partnern oder Wettbewerbern, wo die ToS es erlauben oder wo eine API-Vereinbarung besteht.
• SERP-Tracking: Ranglisten-Monitoring für SEO-Zwecke — siehe unsere SERP-Tracking-Anwendung.
• Web-Scraping für Forschung: Akademische Datenerhebung unter Einhaltung von robots.txt und ethischen Richtlinien — mehr dazu auf unserer Web-Scraping-Seite.

Nicht legitim ist der Einsatz für: Credential-Stuffing, Ticket-Fraud, Sneaker-Botting gegen ToS, DDoS-ähnliche Lastsimulationen oder das Umgehen von Paywalls. In den USA kann unbefugter Zugriff strafrechtlich nach 18 U.S.C. § 1030 (CFAA) verfolgt werden; in der EU greifen DSGVO-Artikel 6 (Rechtmäßigkeit) und 32 (Verarbeitungssicherheit).

Key Takeaways

• Konsistenz schlägt Perfektion: Akamai sucht nach internen Widersprüchen, nicht nach einzelnen „guten“ Werten. Alle Signale — TLS, HTTP/2, JS-Umgebung, Verhalten, IP — müssen ein kohärentes Bild ergeben.
• _abck ist kein Dauer-Token: Der Trust-Score wird kontinuierlich berechnet. Eine anomale Aktion nach 10 Minuten kann die gesamte Session invalidieren.
• Protokoll-Fingerabdrücke sind 2026 entscheidend: JA4, X25519MLKEM768 und HTTP/2-SETTINGS müssen zum behaupteten User-Agent passen. Ein gefälschter UA ohne passenden TLS-Stack ist sofort entlarvt.
• Residential Proxies sind Pflicht: Datacenter-ASNs werden von Akamai vorgeschlagen als Bot-Ursprünge markiert. Residential Proxies mit Geo-Targeting sind die einzige zuverlässige IP-Basis.
• Sticky Sessions verhindern IP-Brüche: Verwenden Sie user-session-XYZ in der ProxyHat-Username-Flag, um die IP für die gesamte logische Session konstant zu halten.
• Legalität zuerst: Autorisierte Forschung und legitimes Monitoring sind in Ordnung; unbefugter Zugriff ist rechtlich riskant.

Bereit, Akamai-geschützte Ziele mit sauberen Residential Proxies anzugehen? Schauen Sie sich unsere ProxyHat-Preise an oder konsultieren Sie die ProxyHat-Dokumentation für erweiterte Konfiguration.