Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author's of this post created a Hackbot together. They have found 126 confirmed bugs in the last 5 months, with 88 of those being critical or high. Of these, 77 were accepted, 35 were duplicates, and 15 were NA. They thought this was just going to be hooking up their Claude Skills to run autonomously but it ended up being a lot harder than they realized.

After eight hours of running the initial hackbot, they had bugs a lot of tokens, and their bugs were bad. They realized that the constant steering that they did really mattered. The agent would get distracted by low-signal things, or give up too quickly. From the issues they had, they generated a few rules... Rule 1 is always keep logs. Commands ran, requests sent... everything! This makes it possible to see where it's going wrong and make changes.

The first mistake the bot made was closing up shop too early. Even with a good prompt it would stop hacking very quickly; it would look for the first plausible explanation and then stop. If a request failed, it moved on. if the bug almost worked, it didn't continue pushing on it. So, the second rule is keep the bot hacking. They settled on a Ralph Loop: perform task, evaluate result, and generate new tasks based on this. The bot treated every finding as the beginning of a new investigation. The longer the loop ran, the more the system began to resemble a real hacker.

On the flip side, they ran into the other side of persistence: staying around too long. After a while, they removed the Ralph loop (because it doesn't know when to stop), and added an orchestrator architecture to judge the target. If the attack surface was weak, it would move onto the next target. If it looked good, it would continue working on it longer. This made the bot keep hacking but not for too long.

Initially, they had a false positive rate of 80% or about 1 in 5 bugs was real. The AI was constantly hallucinating and this was the main problem. This led to rule number three: always validate. They created a validation agent to aggressively disprove findings. The bot was appeasing us by removing findings, but by proving them. The validator would look at an SSRF report, and look for evidence that the request left the network boundary. This dropped it from 80% to 60%.

The final boss for them was authentication. 80% of tokens spent were originally on authentication. They use headless Chrome browsers for the hackbot but would get held up by CAPTCHAs. They tried various services to bypass this but it just wasn't consistent enough. Eventually, they took a physical computer with real Chrome to login and used those tokens. They created an Agent whose job was to act like a normal user on the browser. The hackbot no longer had to login; it was magically given sessions. Most attack surface is behind auth.

They list a few bugs they found. One of them was a real good recon game. They found a Google API key from somewhere, and used it to leak various projects associated with Google partners. One of them partnerdri.com, allowed for email/password signup without email verification, where they found an API that leaked email domains, and parnter orgs. From there, they found a domain takeover via old DNS registrations, that gave them access to other accounts to give them partner admin access. Finally, the bot found a privilege escalation from partner admin to super admin that allowed them to see everyone's data. A long chain!

On the same partner website, a bad OTP returned the bcrypt hash of the real OTP in the error response. After some effort, they realized they could crack the password reset OTP is about 30 minutes of intense computing. On Western Union, they found a vulnerability that (unauthenticated) could be reached via phone number or first/last name prefixes. This leaked all customer data; this was identified via reverse engineering JavaScript bundles.

On Raydium, they found an XSS on the frontend from some token metadata information. Crazily enough, all it takes is reviewing a specific token mint, and the XSS occurs. The XSS occurs on a detached node. They believe the developers thought that using .innerHTML was safe on the node because it wasn't connected to the DOM tree. However, the browser will still do the rendering if it's linked to in JavaScript, such as with an onerror event.

Overall, a great post on the troubles, and solutions that had to running a hackbot. Thanks for the release!