HakuPiku’s skillset and perspectives as a 

 hunter have been shaped by his experiences as a former developer, ex-pentester and participation in capture-the-flag (CTF) competitions.

 earlier this year (video and transcript below), the Swedish ethical hacker (real name Eldar Zeynalli) reflects on his Bug Bounty career so far. He talks about how he got into hacking, compares Bug Bounty to pentesting, discusses his preference for Android apps and open-source code, revisits his most critical find so far, and explains which (non-IT related) profession bug hunting most resembles.

 is a full-time security researcher and bug hunter and finds time to also play CTFs with the 

 team, which has won numerous events over the years.

HakuPiku on how he acquired his hacker alias…

Back in high school I guess. Like 8-9 years ago, I was super interested in Japanese anime novels. There was this novel that I liked, and I got the name ‘Hako’ from that. Hako means ‘box’ in Japanese. And I started using Hako as a nickname everywhere and my university friends started calling me Hako as well. But one of them just out of nowhere said ‘HakuPiku’ because Piku was Pikachu from anime, so he just combined the two into something [new]…

And then when I was looking for a nickname, I was like: “I don’t want to use Hako because I’ve used that everywhere and I want something fresh.” I was like: “Why not use HakuPiku?” Because it was so easy to remember.

I was studying computer science at KTH [Royal Institute of Technology] in Sweden. I had several friends there who were into security hacking, and one of them specifically was doing a lot of CTFs [capture-the-flag competitions]. And after a session of drinking together, we went to his place, he started doing a CTF. I joined him and I realised it was fun. And that’s how I got more into CTFing and from that thereon, I got more into Bug Bounty and so on.

On whether CTF competitions are useful training for Bug Bounty…

I think it depends on what level of CTFs we’re talking about.

With top-level CTF teams, you’ll see quite unique methods, quite unique tools that you can definitely use in Bug Bounty.

You get a lot of challenges that are like… whoever wrote the challenge found a zero day and made a challenge out of that, and you have to find that same zero day. That teaches you a lot [about how] to read code, and the better you are at reading and writing code in my opinion, the easier it is to hack as well.

On whether coding experience make you a better hunter…

I’ve worked as a developer before and currently I’m working as a cybersecurity consultant, so I do hacking as a job as well on top of Bug Bounty. It definitely helps to have coded because I think my first big bug on YesWeHack was on an open-source project. I just read through the code, found a bug and reported it.

The closer you get to the code I feel like the easier it is, the more you can find, the more you familiarise yourself with it, so that’s why I like being close to the code. And if you like that, that comes from being a developer or working with the code.

Most of what I do is web pentests, so it’s quite similar to Bug Bounty. But the one difference is why I like Bug Bounty more: you have however [long] you want to spend on a target, to spend on a bug.

Let’s say I want to find some XSS through 

 or something like that. That is going to take hours of looking through the JavaScript to find some gadget here and there. I can’t do that at a pentest job, because it’s 48 hours of pentest. I have a list of stuff to go through to find the most important stuff.

And I think that’s why Bug Bounty makes you get better as well, because oftentimes, if you’re hunting on a big target that hundreds of hunters have been through already, you need to find something really hard to find.

I’ll go for a lot of projects that have some sort of 

. Also, I spend a bit more time on Android applications, reversing them and looking through the code.

Most people just look at basically API endpoints – that’s making API calls from their mobile app – and since everyone does that it’s hard to find bugs of that kind. But I try to look more at native app bugs basically, like Android app bugs, try to learn from others and look at those.

On his most critical bug discovery so far…

Most critical was recently. I was testing some random application on a random scope on a random program.

And I saw some weird error message when I sent something. I was like: “hmm what could this be”. When I googled the error message, I got to a super popular open-source web framework. It was an error from that, and I started looking through what could go wrong when this happens. Then looking through the code, I found something interesting, and I just modified it and sent it in the URL of the website I was testing – and I got 

And then I was like, “let me try and scan the web for this”, and I found that same vulnerability on at least three [programs] – one bank and two top companies – and they paid quite a bit for those. It was a zero day I found on something accidentally.

On the profession (not IT-related) bug hunting most similar to…

I like looking for bugs because it feels like you have these clues, and you are trying to piece together these clues to solve a mystery. And I love mystery novels: it makes me feel like a detective, so I love that rush I get from it.

Learn more about hunting through YesWeHack

, or learn about the latest hacking tools and techniques 

‘I like Android apps and open-source code’: HakuPiku on Bug Bounty, CTFs and his favourite targets

Bug Bounty often beats pentesting in terms of both the 

 of their deployment, according to TeamViewer’s senior project manager for security.

“The program provides us with a broad access to talent”, said Michael Gillig in a recent YesWeHack webinar about TeamViewer’s Bug Bounty journey.

In particular, he said he valued how hunters often hyper-specialise in specific technologies, such as certain authentication methods. “They are digging really deep into our products,” he said.

 (BBP) went public, “a few things were revealed that were missed by a pentest before. That was partly surprising,” recounted Mr Gillig, who oversees BBPs at 

, whose remote access/control software has been installed on more than 2.5 billion devices worldwide.

Nevertheless, the Germany-headquartered company still does a lot of pentesting. “I would like to shift some capacity away from classic black-box pentesting towards Bug Bounty – and I’m pretty sure I could,” said Mr Gillig, pointing out that a BBP “is like a continuous, never-ending pentest with a large number of resources.”

Given “our software has very high security requirements, because of the special nature of remote-control software,” customers request pentest reports for assurance of cyber resilience, said Mr Gillig.

 is gaining more credibility as the testing model becomes more widely understood. “Customers really like that we run a Bug Bounty Program. It generates trust and shows strong commitment to security,” he says. “There is nothing to hide” when you run a public program. “If you discover and report a vulnerability, we will give you a reasonable financial reward.”

TeamViewer, an official global partner of Manchester United, began its YesWeHack partnership in 2021 with the launch of a 

, which Mr Gillig said “you can spin it up in a few hours”. Hunters are recognised for their contributions through a hall of fame and, sometimes, small gifts.

], which is becoming more important to customers and prospects,” said Mr Gillig.

The first private Bug Bounty Program was launched in 2022 and went public in 2024. The rewards – now up to €10,000 – have grown steadily since launch. A second private program is now underway for another product.

Initially very narrow, the public scope now covers the entirety – web domain, desktop clients, Login service, management console and smartphone apps – of 

, the popular remote control software for IT technicians.

TeamViewer’s first scope was pentested immediately before the BBP launch. “In retrospect, that was unnecessary,” conceded Mr Gillig. “A private program is a kind of pentest,” he said – and a particularly effective one.

“Today, I would not be afraid to start with a less mature scope,” he added, noting that the bug flow could have been kept manageable by inviting fewer hunters and offering smaller rewards at the outset.

And even if the workload had become unmanageable, he added, “you can pause the private program at any time”.

TeamViewer began with 50 hunters and reached around 300 before the first program went public.

Joining Mr Gillig on the webinar, YesWeHack’s Selim Jaafar, TeamViewer’s dedicated customer success manager, said his team helps 

 (and all customers) invite the right hunters based on their requirements, but also “how many hunters should be involved at this time, depending on the scope, challenges, constraints”.

TeamViewer only opened its scopes to all registered ethical hackers – numbering tens of thousands – once their internal bug-management processes were sufficiently stress-tested and optimised. “We had working processes and received vulnerability reports from external hunters before Bug Bounty – but not on this scale,” said Mr Gillig.

Fine-tuning the remediation process and improving internal Service Level Agreements (SLAs) were particularly important for eliminating bottlenecks. “When you receive a vulnerability report with a high CVSS score, development teams sometimes need to interrupt their sprints to fulfil the SLAs,” explained Mr Gillig.

Bug Bounty has enhanced handling and communication – both internal and external – of 

 from all sources, said the security project manager. He also said 

becoming a CVE Numbering Authority (CNA) in 2021

“Amazing support from YesWeHack” helped too. “Really helpful, direct communication,” added Mr Gillig, who said their customer service manager was always available for a call when needed to discuss any issues and answer their questions – even the “stupid” ones they asked early on, he added jokingly.

Previously averaging six a month, the number of reports “exploded” once the first program went public – vindicating the extensive preparation. Yet it still took the 

 by some surprise. “We prepared a lot, but we didn’t expect that, to be honest,” Mr Gillig recalled. By reallocating resources internally, the volume of reports was soon reduced to a more manageable level.

Thankfully, according to Mr Gillig’s estimates YesWeHack’s in-house triage team filters out around 30% of reports, whether as duplicates, out-of-scope reports or because they are missing a Proof of Concept (PoC) or other key information.

“That is the big value of the triage team: we don’t do anything that is not worth our time to look into,” said Mr Gillig. “And the reports come to us with valuable information added by the triage team during their assessment.”

It helps that “these guys really know our products,” he added. “We gave them subscriptions so they can look deep into the product without limits .”

‘Determining CVSS is not always easy’

At first TeamViewer prioritised findings based solely on the CVSS score, but later also took account of other variables. Mr Gillig said the triage service helpfully corrects the CVSS when hunters inadvertently overestimate or underestimate the severity, although TeamViewer has the final say on how the score is set.

“Determining the CVSS is not always easy” and is a matter of interpretation, he said. “There are always discussions, with the hunter but also internally.” Given these challenges and the importance of severity, he recommends that anyone launching a BBP should “train your people in how to determine a CVSS”.

TeamViewer is planning to add new private programs given the success of its YesWeHack partnership so far. “Bug Bounty has made our products more secure and resilient – that’s a fact,” said Mr Gillig.

TeamViewer will soon be launching a private program for 

, a cloud-based remote connectivity solution for PCs, phones, headless devices, OT machinery and embedded platforms.

“What I like the most about Bug Bounty: It is a much larger scope and often more efficient than pentesting,” concluded Mr Gillig in wrapping up the webinar. “It also generates less management overhead.”

As for certain perceived ‘risks’ of Bug Bounty, Selim reminded attendees that internet-facing applications are, by definition, open to attack. “So you don’t take more risks by inviting people to hunt with a mandate, with rules, after background checks, to test it within a more secure framework,” he said. He also pointed out that clients can “set limitations depending on the nature of the asset,” such as on the tools or number of requests permitted.

Mr Gillig agreed that Bug Bounty is a low-risk undertaking: “My advice is don’t be scared, just do it – it will benefit you in many ways, you can be sure of that.”

 for further details on rules, rewards and scopes.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management platform? 

 to schedule a demo with one of our experts.

‘More efficient than a pentest and it generates trust’: TeamViewer’s Bug Bounty story so far

This is a guide to performing white box penetration testing on a JavaScript web application running within a Docker container. In testing a web application vulnerable to 

inside Visual Studio Code in order to track our payloads throughout the code process and learn how security filters can hide vulnerabilities from view.

Improve future black-box testing with code analysis

Visual Studio Code (VS Code) (or your preferred IDE)

JavaScript debugger (built-in inside VS Code)

Since Visual Studio Code has an effective JavaScript debugger built in, we only need to 

 to install Docker. The installation process may differ depending on your operating system.

The vulnerable web application that we will use can be found at YesWeHack's Github repository: Vulnerable Code Snippets 

Our project will use the following file structure:

Certain particularly important files must be added or modified. The files below contain the final file content:

This is the main JavaScript file of our vulnerable web application, which we will run in a dockerised environment.

The only thing we need to modify in our supervisord.conf file is the ‘command’ argument in the program ‘node-app’. We will set the command to ‘npm run start:debug’ to ensure that both our web application and debugger start running.

This will serve as the configuration that tells VS Code how to connect to JavaScript’s debugger, which is running in a docker container.

As well as building the docker image, the Dockerfile installs the dependencies used by the vulnerable web application.

This file allows us to connect and communicate with JavaScript’s debugger when it is running in the Docker container. Port 1337 makes it possible for us to access the web application through our host, while port 9229 will be used for our debugging communication.


To make sure our setup works as intended, we should launch our docker container, set up breakpoints in VS code and start the debugger. Then we can submit a request to the web application to see if the debugger stops at our breakpoints.

Navigate to the project file’s root folder (see header: 

Ordinarily you would begin this command in the background (with the 

 argument). However, if you’re fairly new to Docker, we recommend using the command above, which omits the 

When the docker has finished the build process and is up and running, we’re ready to send a request to our vulnerable web application on the port running on 

The response above means that our Docker launched successfully and that the JavaScript debugger is now listening for a connection.

Time to set up some breakpoints inside VS Code. You can do this by clicking on the red dot that appears when you hover over the relevant line number. Breakpoints can be inserted inside the web application's main file: 

Go to VS Code’s debugger section on the left-side panel (or press 

 for a shortcut), then press the green arrow icon at the top:

With our debugger connected, it’s time to perform a HTTP request to trigger the Visual Studio Code breakpoints. We can use the command line interface (CLI) tool cURL to send a GET request to our web application:

Unless something goes wrong, you should not get a response back directly. Instead, some code will be flagged inside VS Code that shows the debugger stopped at the first breakpoint and is therefore functioning properly:

With everything up and running and seemingly functioning correctly, it’s time to start probing the application for JavaScript vulnerabilities!

First, we will focus on how the web application handles our JSON data. This is an important step since it allows us to properly perform our attack.

We start by setting up our breakpoints in VS Code:

Once we have setup our breakpoints, we start our debugger inside VS Code by pressing 

 and pressing the green arrow in the debug window.

Our debugger is now listening for incoming connections. We trigger it by sending a HTTP POST request to our vulnerable web application with the following cURL command:

Our debugger intercepts the request. We can now see how our vulnerable web application is handling the JSON data provided in the post body by analysing the code workflow:

In the debug window to the left, we can see that the 

 variable, which we tried to set to the value: 

. This means we won’t be able to access the restricted area with the JSON data that we provided in our HTTP POST request.

With this in mind, we now need to perform a new JavaScript debug where we carefully analyse how the 

 function handling our JSON data works. First, we need to set up new breakpoints to properly analyse the code workflow in the 

We know the web application is vulnerable to prototype pollution, so we use a simple prototype pollution payload: 

. Hence we send a HTTP POST request with this command:

In theory, our payload should be added to the 

 user. Since it's a prototype pollution attack, the 

 should appear in all object prototypes used by the application.

 function to see how it handles our new payload. We continue debugging the JavaScript until we spot our first JSON element: 

In the code, we can see that the if statement triggered was checking whether our provided value was an object property. The code determined that 

 function inside itself again, but this time using the 

We continue the debugging process until we see our 

This time, we triggered the else statement, which adds the 

, we should now have polluted other objects within the application with our 

 property and its value. Let's continue the debugging process and see if we succeeded:

 object, which holds the admin configurations. It now contains the 

We succeeded: we polluted the vulnerable web application, which granted us access to the admin configurations!

As a side note, if we run the process again with JSON data, we still have a successful prototype pollution!

Below are three of the most common weaknesses associated with the JavaScript programming language.

: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Prototype pollution occurs when user input is mishandled and inserted as a property of an object in an incorrect way. This allows attackers to exploit and ‘pollute’ JavaScript's prototype structure, which is used by objects. A successful exploit allows the attacker to modify or overwrite properties of objects, which can lead to serious consequences such as improper access, file access or full server compromise.

: Access of Resource Using Incompatible Type ('Type Confusion')

Type confusion occurs when a program assumes that a resource is a particular type, but actually handles it as another type.As a result, type confusion can result in improper access by bypassing certain restrictions. Dynamically typed languages, such as JavaScript, are particularly vulnerable to type confusion.

: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Cross-Site Scripting (XSS) allows attackers to inject malicious JavaScript code into web pages. XSS vulnerabilities mainly occur in the front-end and execute in the victim's browser. This type of vulnerability can enable attackers to hijack a user’s sessions or steal their data.

This white-box testing process offers lessons that can also enhance your black-box testing. Most notably, you can see the value of testing multiple, subtly different payloads in attempts to unearth the same vulnerability. Trying a range of payloads is an effective means of discovering changes from the back-end server and to prevent false negatives. 

This writeup also shows that a proper understanding of how a web application handles our payloads is essential to deploying them effectively. These are useful lessons to recall next time you face a similar scenario but in a black-box environment.

We’ve shown how you can more effectively track executed code triggered by the client (attacker) by effectively debugging an application’s source code. Replicate the steps detailed above to optimise your testing flow and uncover behaviours that can reveal how user input is being handled or mishandled.

White-box penetration testing: How to debug for JavaScript vulnerabilities

We start our latest roundup for CISOs with Forrester advice about making supply chain security, securing business-critical IT assets and tackling tech sprawl your top priorities for 2025.

“While security leaders say budgets will increase this year, so will tech sprawl, with software costs doubling up spend on hardware and also outpacing personnel costs,” observes the market research firm in its 

2025 Budget Planning Guide For Security And Risk Leaders

 of the results if you don’t want to trawl the full report. 📰

Also in this roundup (originally published as our 

 from IANS Research and Artico Search similarly observes increases to cybersecurity budgets, albeit the days of double-digit growth are over and a significant minority of security teams are having to perform increasingly complex jobs with either flat or falling budgets. 📉

Clearly, handling myriad threats – not to mention the growing compliance burden and 

 – in the context of tight budgets makes for a stressful vocation. 😓 It seems appropriate then to bring to your attention a 

Q&A between Intelligent CIO and Steve Bray

, head of Australia & New Zealand for Cloudflare, about the prevalence of CISO burnout, the factors at play and how to protect security executives from mental overload. 🧠🛡️

Malta considers national VDP… while citizen bug reporters await court date

public consultation has concluded in Malta

 on a government proposal for a national 

coordinated vulnerability disclosure policy (VDP)

. While we must confess to bias insofar as we have a VDP product to pitch, such a policy is surely necessary when you consider the 

arrest of three computer science students

 over their reporting (which they assert was in good faith) of a vulnerability in Malta’s largest student application, FreeHour, to the vendor. The university students had asked for a bug bounty reward but were reportedly ‘rewarded’ instead with being strip-searched, having their computer equipment seized and a court date in March 2025 (their lecturer is also being charged as an accomplice). 🚔

The consultation ran concurrently with another consultation over Malta’s transposition of the NIS 2 Directive, which has just entered into force. NIS 2 is intended to achieve “a high common level of security of network and information systems across the Union” more effectively than its predecessor from 2016, NIS 1. We’ve just published a 

 explaining why NIS 2 has global implications and ramifications for our area of expertise: security testing and vulnerability management.

In reassuring news about open source security, project maintainers are 

spending three times as much time on security

 than they did three years ago and have become less credulous of contributors following the 

, according to a report from open source security firm Tidelift. 🔒 Less reassuringly, they remain mostly unpaid and overworked. Moreover, given how discouraging this status quo is, they are ageing as a cohort. 😓

This is precisely why in 2023 the Sovereign Tech Fund launched the 

, which helps time-poor open source maintainers prevent and patch vulnerabilities through technical debt reduction, secure code audits and Bug Bounty Programs managed by yours truly, YesWeHack. 🛠️ Our army of bug hunters have been 

entrusted with hardening a number of open source libraries

 that are benefitting from STF funding, including the near-ubiquitous 

, the site of possibly the most impactful vulnerability of all time, no less. 🐞

Relatedly, Stephanie Domas, CISO of Canonical, the makers of open-source Linux operating system Ubuntu, has written about 

The potential impact of AI in almost every human endeavour is both mind-blowing and unpredictable – and with unpredictability, comes all manner of risk. Organisations should therefore be mindful of the safety and security risks of using AI in any use case, and this includes AI cyber-defense tools – especially now that the US Department of Justice (DoJ) has updated  (PDF) aimed at enterprise compliance officers with instructions to start evaluating the potential harms of their AI applications and how to mitigate these risks. Organisations, the rules make clear, will be held accountable for the misdeeds of their AIs. 🤖⚠️

A dispute between Automattic and WP Engine, which has been banned from WordPress.org, has “left “thousands of end-users without security updates and, by extension, millions of internet users exposed to potential hacks”, 

 that “WordPress has banned its user groups from accepting sponsorship from WP Engine” as the multifaceted dispute continues to escalate.

And Eugenio Benincasa, senior researcher in the Cyberdefense Project at the Center for Security Studies (CSS) at ETH Zurich, discussed the 

 of Chinese vulnerability researchers and the geopolitical implications in 

Our latest customer success story sees the cybersecurity chief of a Swedish betting brand ATG reveal that, through Bug Bounty, they have received “really serious reports we would never get from a traditional pentest”. ATG, which powers Sweden’s horse racing industry, has enjoyed a more-than-satisfactory return on investment, according to Erik Täfvander. In the 

 below, Erik discusses why ATG decided to crowdsource security testing, the process of launching and growing the program, and the benefits and challenges encountered along the way. 🐎🔍

, Guillaume Kermarrec, who oversees L’Oréal’s Bug Bounty Program, discusses the iconic cosmetics brand's preparations and hopes for a live Bug Bounty shortly before the event began during leHACK in Paris, over the summer. 💄 Incidentally, we’ve also previously published a 

video highlights of the hacking competition

! Watch highlights below from the live Bug Bounty, featuring targets from Ferrero, the Italian sweet-packaged food giant.

“Vulnerabilities exist in increasingly complex modern applications,” said Guillaume Vassault-Houlière, CEO and co-founder of YesWeHack. “A 

 helps organisations find and fix many vulnerabilities in a short period of time. Hacking against the clock, ethical hackers collaborate and compete to achieve eye-catching results, as well as giving developers and security teams advice that reduces the risk of new vulnerabilities being created in future.”

We’re gearing up for another live hacking event on a different continent entirely, taking place at Ekoparty in Buenos Aires next month (14 November). As usual, the identity of the vendor providing targets will be kept confidential until the event kicks off. YesWeHack will also be showcasing our vulnerability management solutions at Ekoparty, as well as at 

Read this monthly roundup even sooner by subscribing to 

 – our LinkedIn newsletter curating news, insights and inspiration around offensive security topics like Bug Bounty, vulnerability disclosure and management, pentest management and attack surface protection.

Are you a bug hunter or do you have an interest in ethical hacking? Check out our ethical hacking-focused sister newsletter, 

 – offering hunting advice, interviews with hunters and CTF-style challenges, among other things.

Tackling tech sprawl, CISO burnout, NIS 2 now enforceable – OffSec roundup for CISOs

 is now enforceable across the EU amid uncertainty about its implementation with most member states missing the deadline for transposing the regulation into national law.

Today was the deadline for member states to implement the wide-ranging cybersecurity legislation into national law. The EU’s two biggest economies, France and Germany, are among the countries to have missed this cut-off date. According to a 

 from the DNS Research Federation, Estonia and Portugal have yet to start the process for Article 28 ('Database of domain name registration data').

Confusion persists about the obligations entailed for in-scope entities. Some 38% of qualifying Irish businesses have yet to update their cybersecurity polices, for instance, and 67% cited complexity as the primary concern about implementation, 

according to a survey by Mason Hayes & Curran

With NIS 2 violations punishable by fines of up to €10 million or 2% of an entity’s total annual turnover, and senior management potentially held liable, the stakes for getting NIS 2 compliance right are high.

This NIS 2 explainer summarises the state of play, why NIS 2 has global implications, and outlines notable changes versus NIS 1, in particular ramifications for our area of expertise: security testing and vulnerability management.

NIS 2 Directive summary: changes versus NIS 1

Like its 2016 predecessor, the second iteration of the NIS (Network and Information Security) Directive is intended to achieve “a high common level of security of network and information systems across the Union”.

For member states, this means adopting national cybersecurity strategies, designating competent authorities and computer security incident response teams (CSIRTs), and providing tools and support to qualifying entities. Regulated organisations meanwhile must implement a raft of cybersecurity risk-management measures.

The headline changes versus NIS 1 include a wider range of in-scope sectors and their division into “essential” and “important” categories. Regulated sectors include banking, energy, transport and digital service providers such as online marketplaces, search engines and social networks. It has been estimated that around 300,000 institutions will be within scope, compared to just 20,000 under NIS 1.

Other notable changes include a 24-hour incident reporting deadline and stronger information-sharing measures.

There is also an emphasis, almost entirely absent from NIS 1, on securing supply chains and facilitating coordinated vulnerability disclosure (CVD). This reflects a changed threat environment amid the seemingly inexorable surge in new vulnerabilities since NIS 1 (see chart below). Among other measures, NIS 2 prescribes the creation of a European vulnerability database, while entities are instructed to undertake risk-management measures related to “vulnerability handling and disclosure”.

The YesWeHack Blog

‘I like Android apps and open-source code’: HakuPiku on Bug Bounty, CTFs and his favourite targets

‘More efficient than a pentest and it generates trust’: TeamViewer’s Bug Bounty story so far

White-box penetration testing: How to debug for JavaScript vulnerabilities

‘I like Android apps and open-source code’: HakuPiku on Bug Bounty, CTFs and his favourite targets

Tackling tech sprawl, CISO burnout, NIS 2 now enforceable – OffSec roundup for CISOs

The NIS 2 Directive is now enforceable: What are the implications for vulnerability management?

YesWeHack and Ferrero inaugurate Italy’s first live hacking event

Tackling tech sprawl, CISO burnout, NIS 2 now enforceable – OffSec roundup for CISOs

Top 5 hacking tools for white-box pentesting

Web timing attacks, Apache HTTP confusion attacks, email parsing discrepancies – ethical hacker news roundup

Dojo challenge #35 winners!

Top 5 hacking tools for white-box pentesting

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous