 as “very inspiring”, “ well written” and “another example of why deprecated tools need to be disconnected or segregated to a sub platform with no sensitive data”. 💡 ‘Skull’, a Singapore-based hunter, 

, the exploit chain was also praised by PortSwigger’s James Kettle, who 

 “the use of a DoS flaw to make the attack stealthier!” 💀

The next writeup in our monthly research roundup – which is initially published as a 

 – features a similarly large-scale target: a buffer over-read vulnerability in the 

Great Wall of China’s DNS injection subsystem

Documented by researchers from GFW Report

, a censorship monitoring platform, the ‘Wallbleed’ bug “caused certain nation-wide censorship middleboxes to reveal up to 125 bytes of their memory when censoring a crafted DNS query”. The researchers used a novel side channel to monitor injector processes, reverse-engineered the injector’s parsing logic and assessed the leaked information’s impact on users, among other things. The research “afforded a rare insight into one of the Great Firewall’s well-known network attacks, namely DNS injection, in terms of its internal architecture and the censor’s operational behaviors,” wrote the research team. 🇨🇳

Superstitious readers might believe that important things happen in threes, so with that in mind we'll present a third security issue affecting a potentially colossal number of users, this time related to 

. Specifically, researchers from the Florida Institute for Cybersecurity Research 

 that could potentially have resulted in persistent denial of cell service to an entire metropolitan area or city. Moreover, asserted the researchers, some security flaws could have been abused to remotely compromise and access the cellular core. The researchers found vulnerabilities in all seven LTE implementations and all three 5G implementations that they tested. 📡

Burp Suite’s best feature – but no one uses it!

is pure catnip to hackers given the popularity of Burp, but the strength of the content backs up the tantalising promise of the video title.Kicking off our inaugural roundup of advice videos from around the web (well, YouTube), this 15-minute tutorial demonstrates how to use this feature step-by-step on a target to accelerate your bug hunt. 🐛

In video #2, Ben ‘NahamSec’ Sadeghipour shares a 

“proven framework” for consistently finding high-impact bugs

, one that is accumulating traffic and likes at a rapid clip. Among other insights, the legendary hacker and keynote speaker explains why relying on tools alone isn’t enough, how to choose targets wisely, and how to streamline your hacking workflow for maximum results. 💡

Finally, NahamSec also stars in this 17-minute tutorial by the UnixGuy channel, with host Ben R Truong turning to the hacker to help him outline a 

practical roadmap for aspiring bug bounty hunters

“Brevity is the soul of wit,” said Polonius in Shakespeare’s Hamlet. This isn’t universally true, unfortunately, since we’ll conclude our roundup with a concise and humour-free bullet-point summary of other notable InfoSec content:

Hacking high-profile Bug Bounty targets: deep dive into a client-side chain

Nginx/Apache path confusion to auth bypass in PAN-OS (CVE-2025-0108)

Hacking a software supply chain to achieve RCE on developers, pipelines and production servers for a $50k bounty

 – research by Roni ‘Lupin’ Carta and Snorlhax

Shadow Repeater: AI-powered variation testing on Burp

 – Gareth Heyes unveils PortSwigger’s latest tool

 – bug-hunting advice from verylazytech

As per usual, we’d humbly like to flag some of our content too. Bug Bounty hunters often alternate between feast and famine when it comes to unearthing vulnerabilities, says 

 below to see Leo – hacker alias ‘Leorac’ – also reflect on the changes he’s witnessed in our digital ecosystem over the past 20 years, and offers some tips to up-and-coming hacking talents. 🇮🇹

It’s a double header for hunter interviews this month, with our second featured hacker, 

 about the impact of increasingly secure development practices on the number and discoverability of vulnerabilities out in the wild. For those unfamiliar with the Polish ethical hacker, he documents his impressive exploits on his hugely popular YouTube channel, 

 – it’s definitely work checking out. 🇵🇱

Like Gregxsunday, we try and do our bit to inspire and educate aspiring and inexperienced hunters. To this end, we’re publishing how-to guides to learning foundational hacking skills. Most recently this includes 

, which explains various active and passive techniques, supported by examples performed on a real public Bug Bounty Program. We’ve also recently published an 

 (XSS), which examines how to detect and exploit common variants of this pervasive bug type, from reflected to blind vulnerabilities. 🕵️

The current monthly Dojo CTF challenge, '

', invites hunters to "use only JSON to build your hacker profile. The developer claims their application is fully secure. Prove them wrong by reading the 

 file on the server." The challenge is open for submissions until 17 April, with the three best writeups winning exclusive YesWeHack swag as usual.

Pwnii (aka pwnwithlove) revisits the previous monthly challenge, ‘Phishing’. She walks us through the solution, which involves mounting a homographic attack using punycode, as well as explaining why NodeJS’ VM module sandboxes aren’t as secure as they might seem. Kudos to the overall winners of the phishing challenge by the way: Sto, MerleSurLeToit and thepotata. Check out the 

The hunter community is making short work of our 

targets, with only four items left to go. Congratulations to HakuPiku for 

, and winning himself a six-month voucher for Caido Pro and an exclusive swag pack, via an OS command injection report accepted on a public program. 🎁

Finally on the YesWeHack community front, 

 for climbing into second place on our all-time leaderboard. The top two for 

 precisely mirrors the all-time leaderboard (rabhi and Xel), while Xavoppa is a rising star in third (this hunter only joined YesWeHack in 2024), Noam is in fourth (all time #13) and Pocsir occupies fifth spot (al time #15). 🏆

Three upcoming events to highlight if you want to meet the YesWeHack team (and get some free swag!): 

And that’s about it for this month… happy hacking! 👋

Read this monthly roundup of content aimed at ethical hackers even sooner by subscribing to 

Are you a CISO, other security professional or security-conscious dev? Check out our CISO-focused sister newsletter, 

 – bringing you news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

YouTube email leak exploit, Great ‘Wallbleed’ of China, Burp’s overlooked ‘best feature’ – ethical hacker news roundup

No industry is immune from the transformative disruption being wrought by artificial intelligence – least of all the Bug Bounty industry. Offensive security practitioners – boundary-pushers by definition – are enjoying the benefits, navigating the challenges and reckoning with the risks sooner than most.

In terms of operational efficiency, AI tools are enhancing decision-making with data-driven intelligence and, through automation, liberating security researchers and security teams alike to focus on areas where they can add the greatest value.

Of course, AI applications are themselves increasingly the subject of security testing. When ChatGPT first wowed the world in 2023 it prefigured a paradigm shift in how applications behave – with profound implications for vulnerability discovery, reproduction and remediation.

In summary, the age of AI likely heralds a supercharging of Bug Bounty fundamentals:

Ever-more innovative, automated, scalable hacking – for ethical and malicious hackers alike

Accelerating evolution of attack techniques as AI-specific CWEs continue to emerge

Novel complexities in validating, reproducing and mitigating AI vulnerabilities

Streamlining of vulnerability management will reduce time-to-fix, but amid shrinking time-to-exploitation by adversaries

Increasingly scalable risk mitigation amid accelerating software development and even-faster-growing attack surfaces

This article explores how the intrinsic benefits of Bug Bounty, such as continuous testing, will become even 

 as cybercriminals also up their game with the help of AI. Similarly, you’ll learn how the ability to rapidly crowdsource any hacking skill, however niche, is 

 as AI spawns novel attack techniques amid an 

acute shortage of cyber skills around emerging technologies

We’ll also examine the security-testing implications of the spread of AI; what AI cybersecurity tooling means for detecting and handling traditional vulnerabilities like cross-site scripting (XSS), SQL injection and improper access control; and some common AI testing techniques, mitigations and real-world case studies. (And of course, it only seemed appropriate to intersperse the text with AI-generated images!)

#1 The AI explosion in modern applications

AI-powered functionality has become as rapidly integral to modern applications as, for instance, responsive design did before it. Here at YesWeHack, we are already managing several AI-focused programs and dozens of scopes with AI elements.

But the AI rollout is arguably proceeding faster than security practices can keep up with – especially given the technology introduces a set of head-spinning new problems for security testers:

Probabilistic/non-deterministic behaviour

 and emergent (not explicitly programmed) properties

Daunting scale – potentially billions of parameters and near-limitless range of adversarial scenarios

Particularly difficult to distinguish intended/benign behaviour from unintended/insecure behaviour

Complex new failure modes and novel vulnerability types

These AI security concerns make validating, reproducing and mitigating AI-related vulnerabilities particularly complex.

The challenges vary according to the type of system. For instance, machine learning behaviour is at least somewhat inferable. Autonomous agents pose an additional difficulty (autonomous decision-making). A small number of systems, such as spam filters or fraud detection tools, might ‘learn’ in real time – meaning the validity of PoCs might not persist over time.

How has generative AI affected security​ testing?

The fastest-spreading subtype, gen AI, also happens to be the most challenging to secure. On the testing side, AI systems generally – but especially systems that generate text, images, video and audio – might require:

Testers with high-level skills, sometimes in niche, complex, relatively new areas of security research

A patient, careful approach, unencumbered by time constraints given that complex exploits might take weeks or months to bear fruit

Ability to rapidly launch testing programs, test assets continuously, and be agile in adapting targets, testing conditions and testing coverage to align with ever-shifting testing goals

Traditional pentests, where small numbers of testers conduct snapshot-in-time tests within tight parameters, cannot satisfy these demands, at least not alone. Bug Bounty Programs by contrast subject digital assets to continuous testing by diversely talented hackers, with no time constraints. These bug hunters are either handpicked for their skills and track record (in the case of private programs) or (for public programs) number in the tens of thousands.

Bug Bounty Programs can also be continuously optimised, by tweaking variables such as scopes, rewards and invited hunters, to align with AI assets’ unique and fast-changing security needs (and the organisation’s budgetary constraints). The Bug Bounty platform should provide extensive support in this endeavour, as well as with validating and prioritising (ie, triaging) vulnerabilities.

#2 XSS is here to stay: testing AI scopes for classic vulns and hybrid exploits

While AI has spawned novel CWEs such as data poisoning, model inversion attacks and adversarial machine learning, classic vulnerabilities remain as relevant as ever.

Indeed, pre-AI vulnerabilities – such as 

 that both exposed chat histories – still account for the majority of validated vulnerabilities associated with AI assets.

The attack surface of AI applications after all still comprises conventional assets such as servers, databases, login pages, APIs and caching mechanisms.

The complex interplay between AI and non-AI components means an insecure AI feature can compromise the wider web application, and vice versa. Consider, for instance, 

 in AI component GraphCypherQAChain, which processes natural language queries for LangChain, the framework for integrating large language models (LLMs) into applications. Conversely, imagine a broken authentication mechanism that allows unauthenticated users to access internal API endpoints. If a chatbot interacts with users via one such endpoint, that could leave the chatbot open to Denial of Service (DoS) attacks, model poisoning or the malicious triggering of unintended actions.

Will AI take over cybersecurity attack​ testing?

While traditional testing around, for instance, input validation, access controls or APIs remains as valid as ever, AI tooling is helping hunters find bugs of all kinds more quickly and at greater scale. For instance, a hacker might use AI security tools to deploy multiple instances that test many parts of a target simultaneously. Nevertheless, the most innovative, impactful exploits still require human persistence, creativity and lateral thinking – and indeed, some of the most successful hunters even 

#3 Hacking AI: Testing for advanced AI and LLM vulnerabilities and risks

As with classic vulnerabilities, ethical hackers typically hunt for AI-specific bugs by emulating the tactics, techniques, and procedures (TTPs) of threat actors. This adversarial testing involves crafting inputs in a bid to induce behaviour that poses legitimate security risks, such as exposing sensitive data about users or the AI model, or enabling attackers to poison or reverse engineer models.

Below are some common types of AI security testing. The applicability of these AI hacking techniques in any given context depends on the nature of the target and the testing goals of the security team:

Crafting prompts that induce large language models (LLMs) into running malicious commands, leaking sensitive data, or emitting biased, inaccurate or offensive outputs.

Delimiter confusion, context boundary testing, role-playing, hidden text, nested injection.

Input sanitisation, context-aware filtering, robust instruction parsing, fine-tuning models to recognise and resist malicious prompts, using human-in-the-loop validation.

 the system hosting MathGPT, the AI maths tutor, and thereafter a sensitive API key; a student 

 Microsoft’s Bing Chat into revealing its own confidential system instructions (both 2023).

Repeatedly querying an AI model and using the responses to train a replica model.

Query-based attacks to infer model structure, gradient-based attacks that exploit APIs to approximate gradients, transfer learning or model inversion techniques to extract sensitive information.

Rate-limiting on API queries, differential privacy (adding ‘noise’ to outputs), returning rounded confidence scores or top-k predictions only, employing model watermarking.

 from Vercel’s AI chat service, potentially exposing sensitive logic, guardrails or proprietary instructions; researchers 

 that GPT-3-like models could be partially extracted using API queries (both 2024).

Also known as indirect prompt injection, this injects malicious data into the training set in a bid to corrupt a model’s behaviour and embed backdoors.

Poisoning training data with mislabelled or malicious samples, backdoor attacks that embed misbehaviour triggers in data, submitting poisoned updates into federated learning systems.

Data validation and sanitisation techniques, making training algorithms less sensitive to outliers, monitoring for anomalous patterns in training data. Federated learning systems might use secure aggregation and anomaly detection to filter out malicious updates.

 an 11-word 4D jailbreak” of an open-source SOTA model after seeding the internet with custom protocols six months earlier (2025); researchers 

 feasibility of poisoning extremely large models with access to only a very small part of their training data (2024).

Inducing models into inadvertently leaking sensitive information, whether users’ personal data or training data.

: Differential privacy testing plus model inversion, membership inference, attribute inference and gradient leakage attacks.

Differential privacy, decentralising data with federated learning, data anonymisation, stronger access control mechanisms.

 an ‘Imprompter’ algorithm that generated ostensibly nonsensical prompts instructing LLMs to find personal information entered by users and then relay them to threat actors.

Evaluating whether specific data points were part of a machine learning model’s training dataset in order to identify risks of sensitive-data exposure.

Attacks based on thresholds, prediction confidence gaps, shadow models, Bayesian membership inference and entropy.

Differential privacy (adding ‘noise’ to training process), regularisation methods to reduce overfitting, data anonymisation and access control mechanisms.

 (PDF) a membership inference attack against Google's Cloud Vision API, where confidence scores revealed if specific images were part of the model’s training dataset (2020).

Eliciting incorrect, nonsensical or contradictory outputs – especially egregious where trustworthiness is paramount, such as for applications offering legal advice or diagnosing medical conditions.

: Fact-checking, contradictory and self-consistency prompts; retrieval augmented testing; prompt perturbation; negation testing; and chain-of-thought or time-based logical consistency testing.

Fine-tuning with high-quality datasets, fact-checking mechanisms, human-in-the-loop validation, reinforcement learning with human feedback (RLHF).

 LLMs into hallucinating URLs, code libraries and dubious CVE fixes. Technique could potentially spread malicious packages into developer environments (2023).

Assessing whether decision-making models’ confidence scores align with actual accuracy. Overconfident models could lead to poor human or AI decision-making (such as for autonomous driving or financial forecasting).

: Brier score analysis, gradient-based attacks, softmax entropy reduction attacks, Monte Carlo dropout testing, out-of-distribution testing.

Temperature scaling, Bayesian methods, ensemble models, regular evaluation of diverse datasets.

Tesla's Autopilot system was involved in 

 allegedly due to ‘overconfident’ misclassification of road scenarios (2024).

Testing for discriminatory or unfair AI outputs, especially where models disproportionately disfavour specific groups based on attributes like race, gender or socioeconomic status.

Dataset bias, algorithmic fairness metrics, counterfactual fairness, bias detection and model explainability testing.

Reweighting’ influence of certain datapoints, making datasets more diverse and representative, implementing fairness-aware algorithms.

The COMPAS tool, used by US courts to predict likelihood of prisoners reoffending, 

 by disproportionately labelling Black defendants as posing a high risk of recidivism.

AI does not alter the basics of Bug Bounty management – in fact, the fundamentals become only 

For instance, it’s even more imperative to continually align program parameters – scopes, rewards, testing conditions, participating hunters – with the testing needs of a technology that evolves rapidly and unpredictably. And with increasingly complex attack surfaces expanding and in-the-wild exploitation accelerating, the same applies to risk-based prioritisation, time-based SLAs, and leveraging remediation feedback loops to optimise testing conditions and make application development more secure.

These goals require productive input from not only security teams but the Bug Bounty platform’s customer success and triage support teams (increasingly aided, of course, by the judicious use of AI tools).

AI scopes typically reference the same classic qualifying vulnerabilities as non-AI scopes – such as authentication, server-side request forgery (SSRF) and improper access control issues – as well as familiar out-of-scope techniques like denial of service or social engineering attacks.

But the dynamic nature of AI means novel vulnerability categories will continue to quickly emerge and evolve, making it more important than ever to regularly review and update testing guidelines and qualifying vulnerabilities.

A ‘vulnerability’ is not a vulnerability unless a legitimate security impact has been demonstrated, and AI scopes are usually no exception. Qualifying vulnerabilities might therefore include prompt injection attacks that leak user data or execute malicious code, as well as model extraction issues that facilitate adversarial attacks or compromise intellectual property rights.

On the other hand, hallucination ‘vulnerabilities’ tend to be designated as non-qualifying because they are trivially easy to induce and near impossible to definitively fix, while security impacts are difficult to demonstrate (if a model 

 to run malicious code, you have no exploit). If hallucination testing 

 permitted, it should be in the context of a private program; via a 

 program it could trigger an avalanche of spammy ‘vulnerability’ reports.

 tend to also be out of scope for similar reasons. This even applies to grave safety issues, such as eliciting bombmaking instructions from an LLM. OpenAI for instance requires that model safety issues are reported via a 

. Although this is not a hard-and-fast rule, model safety testing requires a skillset that only partially overlaps with that of the archetypal ethical hacker. Nevertheless, the Federation of American Scientists has 

 more algorithmic bug bounties for AI safety as well as better legal protections for AI researchers.

Whether AI assets are developed in-house, off-the-shelf components or adapted from third-party models is another significant variable. Fully third-party assets might be ruled out of scope, since only the vendor can mitigate vulnerabilities. Some organisations, however, might accept reports in order to coordinate with the AI vendor and apply any upstream updates. Exploits in third-party components that affect in-house assets might also be accepted as valid. This ambiguity is one 

 why having a Vulnerability Disclosure Policy (VDP) with a much broader scope is wise.

Mitigating AI cybersecurity risks with Bug Bounty Programs: A deep dive

HTTP fingerprinting is an invaluable way to discover the underlying technologies powering a web application.

From analysing HTTP headers to performing malformed HTTP requests, these reconnaissance techniques help offensive security professionals pinpoint a target’s hidden weaknesses.

The upshot: more targeted attacks and an increased likelihood of uncovering vulnerabilities – as well as lucrative Bug Bounty rewards.

In this article, we’ll explore how HTTP fingerprinting reveals hidden components that may be vulnerable due to misconfigurations or outdated software. Vulnerabilities, especially those related to Common Vulnerability Enumeration (CVE) records, can be overlooked without robust fingerprinting – making this an essential skill for bug bounty hunters and security researchers.

Banner-grabbing and reverse proxy identification

Inferring server banner based on header order

Identifying default file and directory structures

Passive fingerprinting via third-party services

Conclusion: a more targeted approach to bug hunting

HTTP fingerprinting is a recon technique for gathering information about HTTP servers and their related components, such as programming languages, frameworks, proxies, content delivery networks (CDN) and web application firewalls (WAFs). Armed with this information, security researchers can learn how a target’s infrastructure is configured, which in turn sheds light on potential weaknesses.

Understanding the underlying technology stack often gives a direct path to known vulnerabilities or misconfigurations, since each technology comes with its own security history. By ascertaining which software version is in use, you can identify any related CVEs or vulnerability to publicly available exploits.

HTTP fingerprinting involves analysing different aspects of HTTP traffic to pinpoint unique attributes. Many technologies leave unique ‘fingerprints’ – such as special headers or default error pages – which can reveal clues about the environment. Knowing how to interpret these signs enables you to make your attack strategy more targeted and discover flaws more rapidly.

You can learn a lot about a target’s technologies by analysing the HTTP response headers. Common headers that typically expose server or proxy details include 

. Many technologies also use their own custom headers that expose the same details. For instance, with a header structure like 

, you can easily collect these types of headers using extensions or custom-written 

. This type of HTTP header analysis is invaluable, because even a single header can reveal a misconfiguration or an outdated and potentially exploitable software version.

, where servers are induced into revealing information about software banners, provides direct evidence of installed software and its version numbers – which helps security researchers assess which known vulnerabilities might be present in an environment. To grab the banner of a web server or reverse proxy, you can send a HTTP 

 request to the web server and then analyse the HTTP response.

Here are some HTTP responses generated by real Bug Bounty targets that expose their reverse proxy banner:

In these scenarios, detecting the version of the reverse proxy being used for a specific web server was easy.

But what if this fingerprinting method fails to explicitly expose these details? Fortunately, subtle implementation details can give you additional clues about the proxy’s identity.

It might be possible to make an educated guess at the reverse proxy banner based on what order the HTTP response headers are presented in, although this depends on the proxy using default configurations.

Look again at the HTTP response examples given above – can you discern a pattern based on the order of the headers?

If we look closely, we can see that Apache responses put the 

As for the Nginx responses, we can see that the 

 the server header. Nginx is less likely than the Apache reverse proxy to maintain a strict header order, but often follows the header order: 

Armed with this knowledge, we might be able to infer which reverse proxy is being used by a particular web server based on the response below – any ideas which one it could be?

However, since header order can be also affected by different configurations, software versions or security mechanisms that obscure server information, inferring banners based on header order should be combined with other fingerprinting techniques to obtain a clear picture.

We can also fingerprint a server’s proxy or web server by analysing its default error pages. These are revealed when you trigger HTTP status codes like 404 (not found), 500 (server error) or 403 (forbidden). Default error responses often expose distinctive elements from original templates used by the technology. For instance, Apache Tomcat, Spring Boot, Apache, Nginx and IIS all display default pages for specific HTTP status codes that reveal telltale signs about the technology stack.

Even with modest customisation, it is possible to fingerprint the technology used by analysing HTML tag structures, embedded comments or specific phrasing used within the page.

Sending malformed HTTP requests to a web server typically triggers error responses that expose identifying details about the underlying technology. This tactic effectively turns an inadvertent server misconfiguration into a golden opportunity to discover vulnerabilities within that environment.

For example, a malformed HTTP request might involve sending a request with an invalid HTTP version or method, as shown in the examples below:

If the web server is not configured to handle such requests, they can trigger an error in the technology used by the web server that potentially exposes the banner. As such, this technique can be an effective way to gather intelligence on the server’s configuration, despite its attempts to hide its identity.

Default file and directory structures also play a major role in HTTP fingerprinting. Analysing directory naming conventions is a great way to discover which framework the web server is using, while file extensions can reveal the underlying programming language. 

 often contain version details that confirm elements of the technology stack. Once these structures are mapped, you can strategically focus your HTTP recon efforts on known vulnerabilities tied to the identified framework or language.

Web servers and frameworks implement unique session cookie parameters that reliably indicate which programming language or framework is being used, even when hidden behind a reverse proxy. The complexity of configuring and masking these identifiers across diverse environments makes analysing cookie parameters a consistently reliable way to fingerprint a server.

By pinpointing the back-end architecture in place, you can focus your pentesting strategy on technology-specific vulnerabilities rather than wasting time on irrelevant exploits.

Examples of cookie parameter names used by various technologies:

Third-party services Wappalyzer and Shodan are excellent fingerprinting resources, in part thanks to their large databases of technology signatures collected from a wide range of web applications. They can be used to efficiently fingerprint your target's web server by aggregating historical data and patterns that might not otherwise be obviously visible, saving you significant time and effort.

Shodan provides useful insights about a web application’s open ports and running services. Also storing HTTP responses from the web application, Shodan is a great tool for leveraging the techniques described earlier to analyse HTTP response headers.

Wappalyzer, on the other hand, detects the underlying technology stack of a web application. This browser extension reveals frameworks, programming languages and third-party services powering websites. Lookups might confirm suspicions you had about the presence of certain technologies, or reveal components that would have stayed entirely hidden if you relied on manual inspection.

By combining this passively-collected data with your active findings, you gain a full-spectrum view of the target’s architecture and give yourself the best chance of spotting inconsistencies that signal potential misconfigurations.

A crucial first step for protecting against HTTP fingerprinting is to suppress or customise server headers. Removing or rewriting version information in 

 headers should hide the real server banner. Creating misleading values forces adversaries to expend additional effort guessing or probing for system details, and complicates any automated exploits that rely on easily accessible version data.

Default responses supplied by technologies such as Tomcat or Nginx often include logos or text that reveals a server’s identity. Replacing these default pages – or at least deleting the exposed version – makes HTTP fingerprinting significantly more difficult for the attacker.

To give some specific scenarios, with Apache, administrators can modify the 

. In Nginx, similar results can be achieved by setting the 

 file. For Tomcat, achieving this involves editing the 

Another defensive layer can come in the form of web application firewalls that intercept and modify outbound HTTP headers.

Removing unnecessary files and directories is also advisable. Items such as 

 can contain explicit technology references or version details. If these files are no longer needed, they should be deleted; if they 

 needed, then an access control should be configured to prevent unauthorised users from viewing their contents.

Regularly reviewing server configurations and conducting periodic vulnerability assessments can ensure that header customisations and file restrictions remain effective against evolving fingerprinting techniques. Automated monitoring tools like intrusion detection systems and continuous compliance scanners can also alert administrators to any configuration drifts or the resurfacing of sensitive default responses.

Conclusion: A more targeted approach to bug hunting

So now you’re familiarised with an essential recon technique in the arsenal of security researchers and Bug Bounty hunters.

The YesWeHack Blog

Recon series #3: HTTP fingerprinting – sleuthing for a web application’s hidden vulnerabilities

YouTube email leak exploit, Great ‘Wallbleed’ of China, Burp’s overlooked ‘best feature’ – ethical hacker news roundup

Mitigating AI cybersecurity risks with Bug Bounty Programs: A deep dive

Recon series #3: HTTP fingerprinting – sleuthing for a web application’s hidden vulnerabilities

YouTube email leak exploit, Great ‘Wallbleed’ of China, Burp’s overlooked ‘best feature’ – ethical hacker news roundup

US House passes bill mandating vulnerability disclosure policies for federal contractors

Dojo challenge #39 - Phishing winners & writeup

Junior devs ‘can’t actually code’, AI coding risks, security researchers decry inscrutable AI – OffSec roundup for CISOs

US House passes bill mandating vulnerability disclosure policies for federal contractors

Recon Series #2: Subdomain enumeration – expand attack surfaces with active, passive techniques

Bounty Grid Boost: Ethical Hackers Invited to Strengthen the Security of the French Government’s Digital Services

Top web hacking techniques of 2024, McDelivery hijack, 4D SOTA jailbreak – ethical hacker news roundup

Recon Series #2: Subdomain enumeration – expand attack surfaces with active, passive techniques

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous