Client-side shellcode generation: a threat model that is not marketing
What stays local in a browser-native shellcode builder, what still leaks, and how to run authorized tests without polluting your ticket trail.
Every security product claims "we do not store your data". For shellcode tooling, that line is meaningless unless you define what "data" means and who your adversary is.
I break it down for two audiences: the pentester trying not to leak client context, and the defender evaluating whether browser generation changes risk.
What client-side generation actually removes
When generation runs in WASM in the browser and does not POST bytes to a backend:
- Payload bytes never traverse a vendor API
- Server access logs do not get a hex dump
- A compromised SaaS database is not in your blast radius
That matters for boutique assessments where the client's name never belongs on a third-party disk.
What it does not remove
Local generation is not amnesia.
- Browser extensions with broad permissions can read page state
- Endpoint agents on corporate laptops still see memory and clipboard
- Screen capture during a demo is still a leak
- Shared machines keep clipboard history unless you harden the OS
If your threat model includes a managed endpoint with full telemetry, "client-side" does not hide the engagement from your employer's DLP stack. It hides it from mine.
WASM and supply chain
Browser engines execute WASM with sandboxing, but you still trust:
- the WASM module you loaded
- the JS glue that feeds it parameters
- the update channel that ships new hashes
Pin versions for repeatability. If today's build and tomorrow's build differ, your retest notes should say so.
Comparison to msfvenom-on-SSH habits
Classic workflow: SSH to a team server, run msfvenom, copy bytes back. Convenient. Also:
- shell history captures arguments
- backups retain home directories longer than people think
- multi-tenant jump boxes become archaeology sites of old engagements
Browser-local workflows trade one leak channel for another. I prefer local generation for draft iterations, then controlled export once parameters stabilize.
Operational policies that actually help
- Separate browser profile for client labs
- Disable cloud sync on that profile
- Paste into a scratch buffer, not Slack
- Store runbooks (IP, port, encoder chain) separately from raw bytes when filing reports
Defender angle
Client-side builders do not make attacks undetectable. They move artifact creation to the operator workstation. Detection still hinges on behavior: unexpected egress, unsigned code injection, memory permissions changes.
If you are blue team, log the outcomes, not the generator brand.
Honest limitation
Browser tooling is great for iteration speed. It is not a replacement for scope, rules of engagement, and written authorization. No architecture choice fixes a missing letter.