_bhamza

A short, non-technical piece, born from a late-night conversation with a friend struggling to find his first vulnerability: Draft of a night walk: the diagnosis of a researcher’s quest for success zhero-web-sec.github.io/thoughts/draft…

Trail of Bits Tribune: our hot take on vibe coding with LLMs - mailchi.mp/trailofbits/de…

🔥 Just shipped a new tool, GitAudit! It helps you make sense of large open-source GitHub repos by surfacing patterns, stale issues, and insights that matter during triage. 🚀 Check it out👇 riad.blog/2025/12/22/git…

Big milestone: HTTP Toolkit just crossed one million downloads! 🚀 Honestly I didn't think it'd ever get this far, I'm blown away. A huge thanks to all the users, contributors & supporters over the years ❤️. Onwards!

(Automated) Pentesting is already dead I found it interesting how many people misunderstood and ignored the context of my earlier post here, which was about (Tenzai) securing a $75M seed round, and more specifically AI powered automated penetration testing. I’ve been doing a wide range of pentests & audits (over 400 gigs) for about 22 years now. So I know a thing or two about it. But I still consider automated pentesting dead. Not in the way you might have thought though. I initially wrote a longer draft, but eventually folded and let Gemini shorten and polish it, because why not? :) Why Automated Pentesting is Dead It’s dead in the same way that running automated tools like Nessus and delivering 50-page reports were already dead 10 years ago. The new era of AI-powered automation is reviving that exact, low-value approach. I’m not against AI—it will get better. I’m occasionally paying over $1k/month for tokens myself. It’s already working for many things, but it’s not yet scalable for efficient pentesting. Not because tokens are too expensive (they’ll get cheaper) or models aren’t reliable (they’ll improve, XBow is an example). It’s dead for two interconnected reasons: The Problem of Noise and Fatigue The same way old Nessus reports filled with tens or hundreds of valid findings were ignored, this new era of AI-generated issues will also be ignored. Right now, a report might have 2-3 golden findings. Soon, AI minion agents will tear your network apart and deliver 100 perfectly valid and severe issues. If you’ve done quarterly tests against Fortune-50/500 customers for half a decade and delivered similar results over and over, you know what I mean. Remediation prioritization and fatigue are a serious issue. You eventually realize that what we sell (hacking, tests, security) is not the priority of money-making corporations. It's an obligation, often for compliance reasons, among other things. Don't judge a CISO for archiving your all-red report and fixing only five issues by next day, week, month, year. Your “critical finding” is simply a business decision. The way it works is more like: “Will it cost us $1M if exploited?” If the answer is no, it’s not categorized, prioritized, or handled as critical, because doing so initiates a complicated chain of internal actions that itself costs time and money. So in many cases the reason pentests are not efficient is not due to lack of proof, but lack of business priority. You don’t need a functional PoC (human or LLM generated) to address that. A shell (vs plain text finding) on a system that inherently is not business critical in an infrastructure, will not magically make it a priority. This is a big promise deliverable by AI automated pentest startups. It sure works, and they can make it rain shells, but that won’t solve any problem that’s not already been addressed by typical pentests. The Real Bottleneck The security industry has just started giving customers a break from all that automated testing report noise by focusing on deep, manual labor research. It's finally the norm to deliver just half a dozen findings that really matter—not some HSTS header missing nonsense. I’m just hoping that the new wave and era of AI powered automated testing will not bring back those now-just-more-accurate Nessus or Core Impact reports. Ah, I forgot to mention; we have already started, enjoyed and wrapped up an era focused on automatic finding,exploit based validation and reporting of vulns. I’m not saying where we’re heading is the same, but it looks too damn similar. Just way more reliable and way cooler than a python script reasoning with an IF loop, whether to sling an SMB1 exploit or not. Does that mean we should stop finding and reporting things this way? Not really. The biggest issue isn't the accuracy of results. Well, it was, for a period in the mid 2000s. but we got better at it and tools were improved. It's that the receiving end of these automations and reports are not automated. The pipeline and people who handle those findings have not improved as much as the tools have. It doesn’t matter how many critical issues are found and exploited; they are still handled by humans, treated as business decisions, and reviewed case-by-case. Black-box testing is inefficient Delivering 50 valid findings via Nessus, Burp Scanner, or their LLM-powered equivalent is simply not efficient. A black-box test is inherently inefficient nowadays because it’s not finding and reporting problems at their core and root. It just finds and reports symptoms that resurface over and over. Ever logged in to an enterprise’s Qualys or Tenable vulnerability management platform? It’s not a pretty scene, I can tell you! That is peak automated pentesting results at scale! For as long and as many times as you repeat a black-box pentest, you will find new and repetitive issues. Don’t believe me? Ask Fortinet. They still consistently deliver you SQLi, CMDi and vanilla mem-corruption patches on a monthly basis, all year and every year. All found and exploited via black-box testing by your favorite APTs. Yes, that's also a form of testing. They just don’t deliver their findings to the vendor. Fortinet is hardly an isolated case and vendor. If it was meant to be fixed this way, Bug bounty platforms and similar businesses would not be doing so well. They print money, for themselves and hunters, relying on the fact that for over two decades we as an industry have failed to properly and fundamentally fix some of those issues. And btw, if a company has actually followed the proper (security) maturity path before they expose themselves to Bug Bounty platforms, it means that they have already gone through multiple rounds of all sorts of pentests.Yet people still find good stuff, a lot of them actually! Let’s not go down the “we were aware of the issue” or duplicate rabbit holes there. Moreover, if AI based automated testing is so good and the future (well, it is the future), it begs the question of why are they getting banned to operate autonomously on bug bounty platforms? Is it the noise? Are these platforms monopolizing “the market” for their own future agent implementations? The Efficient Way: Security Engineering Ok, what’s the more efficient way of doing things then? I’m glad you asked. Security engineering is the very short answer.? Check in with any respected pentesting and consulting shop. You will find the majority of their customer engagements are not black-box tests. Typical consulting shops prefer white-box audits—reviewing your code, configurations, infra-as-code, or cloud security posture. They basically sell security engineering as a service. The idea is to deliver the most bang for the buck in the shortest time possible, often a week or two. People don’t hire them for low-hanging fruit; they hire them to go deep. They find logical issues or complicated chains of problems that have an unexpected impact. Their JIRA is likely already full of findings from their own automated tools. Interestingly, if you review some of their reports, PoC or actual demonstration of successful exploitation is absent in those security engineering focused reports. The proof is already in the code. Exploitation is a redundant and time consuming task with no real added value for the customer. In Red Team engagement? Absolutely! But in pentests, not really. Statistically, and from personal experience, you find more and better vulnerabilities when you can read the code or reverse-engineer the system, compared to blindly poking something exposed over the network. You focus on key components and narrow down to the root cause. When you notice a pattern, you stop reporting individual cases and write about the nature of the repeated insecure practice. You put your finger on the root cause in the code. If you’ve got time and the customer is also capable of consuming it, you may also deliver long-term detection and mitigation solutions. A fuzzing harness, a CodeQL query, a CI/CD change recommendation, etc. You explain to them the variant analysis playbook. Fill up that Executive Summary section! Typical security engineering workflow. You know the drill. THAT IS MORE EFFICIENT! It lasts beyond your two weeks of pentest, and it can actually reduce work on the customer side in the long run. In contrast, typical black-box pentests can be summarized in a few sentences: Patch your stuff, update your dependencies, audit your passwords, don't get phished, and follow hardening guidelines. Then fix this, this, this, this, this, this, this, and this. You’ll be good, until next year, when we come to redo the test and tell you the same things again, in our updated report template and with slightly improved language. AI + SAST: The Real Game Changer This is where things are actually starting to look bright. We have never been so efficient and reasonably reliable at scale at studying, understanding the code and finding issues in the code and config! We’ve gone through multiple iterations of SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) solutions. They scaled up, but so did their false-positives and the human resources needed to review the results. CodeQL, Semgrep, and similar tools have gotten much better and are now part of most engagements because they work well when fine-tuned. So how is AI-powered SAST different from AI-powered automated pentest? In the case of classic (automated) pentests, we had a semi-working solution that scaled but didn't solve root causes—it pointed out symptoms at scale. In the case of AI-powered SAST, because of the nature of white-box tests and how good models are becoming at understanding code, they can dig deep at a very reasonable cost and time: find the root cause of issues, find all variants of it, produce a Proof of Concept, and, as the cherry on top, also deliver a patch for it! That still needs some human intervention, but the value is immense. We have token-eating monsters at Google, OpenAI, and other places doing exactly that. Many have experimented with similar pipelines at home, winning at a 10x, 50x, or 100x ROI in potential bug value compared to the cost of used tokens. Compare that to the black-box approach: “I sent 100 requests at this endpoint, after a few hours of poking blindly, to confirm a SQLi. Here’s an OWASP link and a Python PoC. To save tokens, I leave it to you and your developers to find the other 100 variants of this issue.” Turns out with $200 worth of tokens you can either bang your blackbox testing agent around until it finds a few bugs remotely and exploit them and call it a win, or spend the same amount of money and a fraction of time to find, triage, exploit, variant analysis, patch and report a dozen of them by consuming code. These token-eating monsters will, and have already, create their own chain of bottlenecks and noise problems. Most of you have probably heard or participated in one revision of the FFMPEG vs Google AI debate. But on the bright side, we already have a (mostly) functional solution for that. It is less freakish to let an LLM send a pull request, than letting it manage your network infrastructure and wipe a database or two on its way. Conclusion Please don’t be mad at me when I say pentesting, in the classical form we know it, even with an AI engine swap, is dead. It’s not completely dead. Different testing approaches should still co-exist, and bug bounty platforms will keep growing. But at the end, if we measure the outcomes, especially with the trajectory that AI-powered SAST and DAST is going, it will be very hard for the black-box approach to catch up in terms of long-term efficiency and impact. In 2025, after watching all sorts of crazy feats APTs pull off, if you’re still trying to answer the question of whether your network can be hacked, you need a wake-up call. The answer is ALWAYS yes. You’re in a much better state if the question is more about HOW, on a case-by-case basis, which is the typical black-box focus. But if you’re aiming for a more long-term and effective approach to identifying and fixing issues, black-box (automated) testing is probably among the least efficient ways to get there. Knowing that we’re doomed to get breached one way or another doesn't make those tests irrelevant. It just means it's better to focus on what happens after a breach and improve there instead. LLM-powered SOC? Token-eating XDRs? AI-powered deployment following security best practices? And just when I was about to wrap up this draft, Google announced their Agentic SOC! That should mean something, looking at the direction they are taking. Whatever is coming down the pipe, I’m curious about it. I just wouldn't put my money on LLM agents running Nmap and blindly slinging payloads until one sticks. If they automatically identify the target, fetch a local copy to reverse or audit, find a bug, and then exploit it (Hello XBow)? Hell yeah! I’m in for that. But then again, isn’t that sliding into the SAST side of things? As a bonus data point, I asked ChatGPT to review the entire history of OWASP-TOP10 for as long as it has been a thing. Apparently bug classes just swap ranks. New ones occasionally emerge, but they never disappear! How many more pentests and exploits do we need to teach people how to properly handle ../../.. ?

Syzkaller now supports VirtualBox 🚀 I’ve open-sourced my work to help push fuzzing and kernel security research forward. github.com/google/syzkall…

Runtime Mobile Security (RMS) 📱🔥 v1.5.24 is out 🚀 #MobileSecurity @fridadotre #AndroidSecurity #iOSsecurity Huge thanks to @n0ps13d Check the changelog 👇👇👇 github.com/m0bilesecurity…

release of our new paper (w/ @inzo____) which resulted in CVE-2025-64525: Astro framework and standards weaponization from path-based middleware protection bypass to potential SSRF & XSS + full bypass of CVE-2025-61925 on @astrodotbuild zhero-web-sec.github.io/research-and-t…

TOOL RELEASE: Detect plagiarized code even when variable names change and comments disappear. Vendetect uses semantic fingerprinting to catch copied code that traditional tools miss. blog.trailofbits.com/2025/07/21/det…

Sometimes, SQL injection is still possible, even when prepared statements are being used. Our researcher @hash_kitten has written up a blog post about a novel technique for SQL Injection in PDO’s prepared statements: slcyber.io/assetnote-secu…

Get your FREE RankSight Score! With actionable plan Unveil your site's future visibility & get your definitive blueprint for top ranking in AI Search. No more blind spots. #RankSight #AISEO #LLMViz #DigitalMarketing

إطلاق النسخة التجريبية من منصة آجُرّوم، منصة لإعراب الجمل والنصوص العربية بالذكاء الاصطناعي مع التدقيق النحوي. تطوير هيثم بن حليمة. ajroum.vercel.app

After 2 years from the last release, APKiD v3.0.0 is out !🔥 - "Black Hawk edition" 📃 Changelog: github.com/rednaga/APKiD/… 🐍 Pypi package: `$ pip install --upgrade apkid` Thanks to @AbhiTheModder for the stunning work 🙌

When choosing a new habit many people seem to ask themselves, “What can I do on my best days?” The trick is to ask, “What can I stick to even on my worst days?” Start small. Master the art of showing up. Scale up when you have the time, energy, and interest.

🖥️Learn about root detection techniques on Android and how to bypass them in our latest blog: 8ksec.io/advanced-root-… ☑️Found this interesting? Our courses offer more in-depth insights. Check them out here: academy.8ksec.io/course/practic… #MobileSecurity #AndroidSecurity #Jailbreak #Magisk

🚀 To celebrate the upcoming Azure Red Team Expert cert, we're launching the first Cloud PEASS: Azure PEASS! 🔎 It gets Azure/Entra tokens, finds all your permissions, highlights sensitive ones HackTricksAI and tells you how to privesc! 👉 github.com/carlospolop/cl… #hacktricks

Introducing github.com/apkunpacker/Ro…, a small POC code that detects known root-related apps by attempting to launch their activities and monitoring security exceptions. Strengthen your app’s security by identifying potential root access attempts. #AndroidSecurity #RootDetection

I've talked to enough web3 SRs to know that your auditing methodology is your bread and butter. This means that you are not only focusing on understanding new bugs. But also make sure that the bugs you've found once upon a time will be found every single time. On your worst days, you will fall back to the sturdiness of your systems. And what good would it be to realize that you found a complex bug only to realize that you let a simple re-entrancy attack that you've seen 1000+ times slip through? Bugs don't discriminate.

First project in the line: A software cost estimator based on Figma design files: considering nb of screens and the complexity, other factors will be added by time