[HackerNotes Ep. 188] DEF CON War Stories: Chat XSS to Spyware, Token Shuffles, and Camera Hijacks

What came up in a hotel room at DEF CON, from stored XSS to cloud pivots

Author

Aituglo ‎
August 20, 2026

Hacker TL;DR

  • Stored XSS in a chat app is not where you should stop. If the product ships an Electron client, push the same XSS through the IPC handlers to get persistence, process listing, per-window screenshots, and JS execution as the victim.

  • If you find embedded AWS creds on a device, do not run a permission brute-forcer first. Read the binaries and the design to understand why the creds exist, then use a token exchange to reach the secrets manager that the whole fleet shares.

  • postMessage handlers that do not check the origin are still common. If the app already has camera, mic or geolocation permission, one click can start streaming that data to the attacker. It still pays high or critical.

  • Going to DEF CON is worth it. Wait times are long and morale is low right now, but being around people who are finding bugs gets you motivated again. Go, keep your schedule open, and talk to people.

Today's Sponsor: The Adobe Program is moving to Intigriti! Head to our Discord and type "Ready to Hack Adobe" in the giveaway channel and paste your Intigriti profile for a chance to win a Lifetime CT Membership!

This Week in Bug Bounty

YesWeHack is introducing Credits to fight AI slop reports. The goal is to make low-effort, AI-generated submissions cost something, so the people spamming noise get filtered out and real reports get through. Details are in their help center.

Wormable Chat XSS to Full Spyware

Nick Copi walked through a bug in a chat application that no longer exists, so it stays undisclosed. The app was React, and messages were sent as a JSON body. The rich poll feature let you set props on a React component, and one of those props was dangerouslySetInnerHTML with an __html value. So you send a chat message and you get stored, wormable XSS in everyone's DOM.

The program paid it very low, which does not make sense for a wormable stored XSS. So instead of arguing about severity, he escalated. The app had an Electron client, so the XSS became a way into the desktop.

Here is the chain. Note this was done before AI, by hand:

  • He audited the Electron IPC handlers and found no direct file-write or require-style RCE. The old Chrome bug had already been patched.

  • There was an IPC method that set the default page the app opens to. He pointed it at a public message that held the XSS payload, so the payload runs every time the app launches.

  • Another IPC call opened a hidden window, kept the XSS running there, then sent the main app back to normal. The victim cannot tell anything happened.

  • From that context he could list all running processes, take a screenshot of the desktop and of each process window, refresh every 60 seconds, and run JS over a websocket as the victim.

So one chat message adds itself to the config, sets up persistence, and leaks the victim's screens and process list on a loop. It was built from a single JSON prop and an IPC listener. It got paid as a low on the program's high-end scale, which shows how badly stored client-side bugs still get triaged.

Pro Tip: when a program pays a client-side bug too low, do not only argue severity. Look for the desktop client. Electron IPC is a second attack surface behind the same XSS, and persistence plus screen capture turns a "low" into something they cannot ignore.

postMessage Camera and Mic Hijacks

busfactor has a bug class he is actively hunting. Think of any app where sharing your camera, mic or geolocation is a normal feature, so the user has already granted the permission to that origin. The idea: the victim clicks a link, and when the page opens it starts sending their camera and mic feed to the attacker.

It is not a Chrome zero day. It is a developer mistake, the same postMessage problem we have seen for years. The handlers exist, but the origin is not checked correctly. This is the area Frans Rosen has covered a lot. Programs are paying it at least high, usually critical.

Pro Tip: grep the target for addEventListener("message" and check if the app asks for camera, mic or geolocation. A missing or weak event.origin check plus an already-granted permission is the whole bug.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

Need a Pentest? We just launched CTBB Pentests!

Hack full time? Check out the Full-Time Hunter’s Guild!

Device to Cloud: The Token Shuffle

gr3pme spent this event on a hardware scope with Matt Brown, who dumped the firmware and passed it over. The focus was device to cloud pivots, which fit the threat model. The interesting part is how you go from a device with no root access to the tenant's cloud.

Working from a low-privileged dev shell (no root on the device), the goal is to understand where and when tokens are exchanged, and what claims each token carries. gr3pme found a spot to do a token exchange: send one token to a credentials endpoint and get back a blob. Decode the blob and it is temporary AWS credentials.

Here is the important part. When you find embedded AWS creds, the first instinct is to run a cloud permission brute-forcer. That is usually the wrong move. Those tools fail as soon as a permission needs a specific resource ARN or ID, because you will not guess the exact DynamoDB table it is scoped to. Instead, Codex read the binaries and pulled out permission names and the resources the device actually used. A small script then checked what was reachable, and it disclosed data from a secrets manager that was shared across the whole fleet, not just that one device. He found two of these. We will see how they are rated.

Pro Tip: before you brute-force embedded creds, answer "why do these creds exist" using the design and the binaries. The source usually tells you what the token is for, and that points you at the fleet-wide resource a brute-forcer would never find.

Hacking VS Code Extensions

Nick Copi's talk was a workshop on hacking IDE extensions, specifically the VS Code extensions that activate without requiring workspace trust. That detail matters: if the extension runs without workspace trust, the threat model is clean and the bug is easy to argue.

The demo was an extension he vibecoded and called "no pilot" (like Copilot, but with nobody in control), with bugs that lead to RCE. Since it was mostly vibecoded, he did not fully know how it worked either, so the session was real debugging: read the context, reproduce the bug, and get the RCE on stage. He also mentioned a query param injection bug where an ampersand taken from document.location.pathname changed a GET request made by a page component and led to an XSS chain. A CTBB version of the extensions workshop is planned for the next couple of months.

Pro Tip: IDE extensions are an underlooked target. Filter for extensions that activate without workspace trust, then treat them like any Node app: check the activation events, the message passing, and anywhere they run or evaluate untrusted project content.

The Talks Worth Catching

Nobody had time for talks, but a few kept coming up:

  • Beyond Normalization: The Expanding Unicode Attack Surface by Ryan Barnett and Isabella Barnett (Akamai). Lots of small Unicode differences across processing pipelines that lead to real impact. The useful part was seeing it from the defender side, including their example of two backticks decoding into malware hidden in a JavaScript library. This one may come to CTBB later.

  • HTTP Terminator by James Kettle. The question was whether AI can produce genuinely new research. The answer is yes, but with a lot of human in the loop. His harnesses were too strict at first and filtered out the interesting behaviors, so it took many iterations. The system found hundreds of live desyncs, a new bug class he calls shared-parser confusion, a real API key from a bank, and a zero day in Apache Traffic Server, now tracked as CVE-2026-63078. The blog post is out, and the repo, prompts, and methodology are open source.

  • Cache poisoning showed up a lot. Alex Brumen on cache key injection, and a TikTok cache poisoning to account takeover talk. There was also an agentic AI session on hacking human-in-the-loop systems.

  • Caido plus AI. busfactor did a talk with Emile from Caido. The point was not Caido itself but connecting AI to your workflow, like having AI build custom Caido plugins for specific program behavior. A simple Codex prompt produced a full protobuf and gRPC "RPC mapper" with every function, input and output mapped.

  • The BT6 panel. "Bots, Bounties and BS," hosted by NahamSec, with busfactor, Ads, Joey Melo, Mike and Dustin. An hour and a half of detailed answers based on real hands-on work. Ads had a busy week: prompt injecting a Unitree robot dog into attacking a human, wormable dog-to-dog zero days, a panel on offensive AI agents, and exfil bugs on Meta in Taipei.

Why DEF CON Is Worth It

The main point across the whole episode: bug bounty wait times are long and morale has been low, and events like this help. The value is not the talks you sleep through. It is the fresh research, the ideas, and seeing people you only meet once a year. There were groups of people finding critical bugs in the hallway, some of them minutes before going on stage.

The XSSDoctor story is a good example. He practiced soldering every morning for a month before a hardware event, was worried about desoldering a device he only had one of, and ended up with a critical bug that was so good he had to spend a week afterward learning how it actually worked.

If you are unsure about going to DEF CON or any conference, go. Keep your schedule open and talk to people.

Resources

That's it for the week, keep hacking!