Clientseitige Shellcode-Generierung: Threat Model ohne Marketing
Was im Browser lokal bleibt, was trotzdem leakt und wie autorisierte Tests ohne unnötige Spuren laufen.
lokale Browser-Generierung, WASM-Vertrauensgrenzen, Clipboard-Risiko, getrennte Profile und Audit-Nachweise sind keine abstrakten Themen. Sie tauchen auf, wenn ein autorisiertes Lab die saubere Demo verlässt und ein echtes Zielbinary trifft, mit echtem Parser, echtem Netzwerkpfad und einem Bericht, den jemand in zwei Monaten noch liest.
Der häufige Fehler ist, anzunehmen, clientseitig bedeute keine Leaks, obwohl Extensions, Endpoint-Agenten und Screenshots weiter existieren. Das ist langweilig, und genau deshalb bleibt es bestehen. Es sieht aus wie eine ungeprüfte Annahme im Builder, ein Wert vom VPN-Interface von gestern oder eine Bytefolge, die durch ein Tool kopiert wurde, das Text umschreibt.
Warum das in einem echten Lab zählt
Shellcode-Arbeit ist Byte-Arbeit. Der Exploit weiß nicht, dass die UI korrekt aussah. Er führt die Bytes aus, die im Speicher angekommen sind. Wenn der Payload durch eine Shell, ein Webformular, einen JSON-Body, Terminal-Scrollback oder ein Ticket geht, gibt es nicht mehr nur ein Problem. Es gibt den Payload plus jeden Parser auf dem Weg.
Ich bevorzuge explizite Prüfungen gegenüber Vertrauen: erwartete Größe, verbotene Bytes, Ziel-OS, Architektur, Payload-Familie, Exportformat und finaler Hash. Wenn etwas fehlschlägt, sollten die Notizen den Suchraum verkleinern, nicht eine neue Diskussion starten.
Ein Workflow, der Werkzeuge überlebt
Start from the smallest thing that proves the primitive. Then add constraints.
shasum -a 256 payload.bin
Dieser Befehl ist nicht der ganze Workflow. Er ist ein Anker. Daneben gehören ein bekannter Blob, sein SHA-256 und die exakten Builder-Einstellungen. Wenn LHOST, LPORT, Encoder-Reihenfolge, Bad-Char-Liste oder Exportformat geändert werden, ist das Ergebnis ein neues Artefakt.
Fehlerbilder, die getestet werden sollten
Das Fehlerbild, auf das ich achte: Payload-Bytes in geteilten Logs, uneinheitliche Retest-Hashes oder eine saubere Architektur, die an Bedienfehlern scheitert. Teste es vor der Integration, wenn möglich. Ein Payload, der in einem kleinen Harness fehlschlägt, ist billiger als einer, der in einem überwachten Ziel laut scheitert. Längenchecks nicht überspringen. Größenfehler sind unauffällig: Der Payload sieht weiter wie Shellcode aus, passt aber nicht mehr in die tatsächliche Primitive.
Was Defender sehen sollten
Aus Verteidigersicht ist der Generator selten das wichtigste Signal. Das Verhalten ist es. Achte auf unerwarteten Egress, ungewöhnliche Prozess-Abstammung, ausführbare Speicherübergänge, payloadgroße Buffer und wiederholte Crashes am selben Offset.
Runbook-Notizen
Speichere Konfiguration getrennt von rohen Bytes, wenn Richtlinien das verlangen, aber behalte genug Details für exakte Reproduktion. Ein gutes Runbook enthält Scope-Referenz, Zielkontext, Constraints, Hash und eine kurze Begründung für die Payload-Familie. Keine Magie. Nur weniger Orte, an denen Fehler versteckt bleiben.