MonkeHacks #57

Zero Days 2025, Ansible, Triage Efficiency

MonkeHacks #57

I’m back in Scotland now - I flew back earlier this week. I’m here until early April, when I have my trip to Japan for an upcoming LHE and to visit my relatives there. The weather was really good this week, which is always a great mood booster.

One of my best friends from Ireland is visiting me with his girlfriend this week, so that took up some of my time. I made some CTF challenges for the upcoming Zero Days CTF in Dublin - I can’t attend in-person this year, so I’m sending my brother up to Dublin to staff the event in my place. My company, Simian Security, is a sponsor.

I did some hacking this week, but nothing too intense. I thought of some new attack vectors for AI hacking, so I spent some time testing them out. I also made good progress on automation, and added secrets management as well as declarative VPS deployment. Consistent progress on all fronts, but nothing groundbreaking.

Edinburgh Castle in the distance.

Weekly Ideas / Notes 

  • I added some new things to my cloud deployment this week. First, I set up Ansible and set up some playbooks for scans that need to run on VPSes. I also centralised secrets management to be encrypted-at-rest on my local machine, and wrote playbooks that sync the secrets to the VPSes and Kubernetes cluster at the same time. I’m very happy with the end state of this small project now, as it cleaned up a major pain point of mine.

  • I started doing some prep work on Google - I have some ideas for new AI hacking attack vectors. It’s still way, way too early to elaborate on this though. If they work, you’ll find out about them eventually.

  • I’m also giving a talk virtually next week to the cybersecurity club in Rochester Institute of Technology in New York.

  • I started listening to the Bug Bounty JP podcast. It’s in Japanese, so it may not be for everyone. It’s run by some notable hackers such as Ryotak.

  • This is something I’ve discussed with other hackers, but I want to generate some discourse around it here: it’s frustrating when triagers downgrade vulnerabilities without proper reasoning (or based on flawed CVSS scores), or struggle to reproduce issues despite clear instructions (such as demanding video POCs in cases where the Steps to Reproduce are very clear).

    • It makes no sense to have that triage layer apply to hackers with proven track records. The purpose of managed triage is to filter out the invalid reports, and verify the validity of the report, before it’s passed along to the program. It therefore makes no sense to apply this layer to hackers with proven track records of being extremely reliable (for example, Zseano on Amazon). I believe that in these cases, reports should be set to “Pending Program Review” directly.

    • I don’t want this to come across as arrogance, but in my case, I’ve submitted over 150 vulnerabilities with near-perfect signal—no N/As aside from a few self-closes. When over 99% of my reports are valid, it’s a waste of triage resources to examine them. In particular, if reports are very critical, then the triage layer actually causes a delay that could have serious consequences.

    • Bug bounty is my main income, and flawed decisions or triage delays directly affect me, and even in the last quarter, triage has simply increased my workload with meaningless NMIs (I’d like to point out that triagers are generalists, and it’s not their fault that they need NMIs). Triage teams are stretched thin, and platforms should reconsider the current level of scrutiny for consistently reliable hackers. The current system offers minimal benefit in these cases.

    • archangel proposed a potential solution here a few years ago in this blog post. It’s worth a read. If you work for one of the platforms - I hope this stirs some debate! I really do appreciate the work that triagers do - I want this to help triagers, and not put them down in any way.

Resources