Pantheress Vault

How I Got Into Apple's Hall of Fame 5 Times

When I started hunting on Apple, I had about three months of experience working as a pentester. I was new to bug bounty and did not even know how to do recon properly, so much of it was learning as I went.

I had always wanted to become an OSINT investigator or work in the blue team. I never imagined I would end up on the red team, but I grew to enjoy hacking. There is a rush of excitement when I finally find a vulnerability after spending time figuring out an application. Alongside that excitement, I feel relieved knowing that reporting it gives the company a chance to fix the issue before an attacker exploits it.

Why Apple?

At the beginning of November 2025, my boss told me to get an Apple Hall of Fame recognition by the end of that month.

I was a little taken aback. Apple? I was still learning the basics and did not even know whether I could find a vulnerability there.

I still clearly remember finding the first one. I was browsing through crt.sh and picked a host almost at random to explore. You can probably tell from that how little I understood recon back then 😂

During that time, I read a lot of bug bounty write ups and tried to apply what I was learning. There was plenty of trial and error, but things slowly started making sense.

Funnily enough, all five vulnerabilities were found between November 2025 and January 2026, although the triage process took longer! I certainly did not expect that when I started, and I am grateful that it eventually led to five Hall of Fame recognitions.

What I found

I will not go into depth about the individual findings, but they included broken access control, IDORs, version disclosure, and issues I uncovered while reviewing JavaScript files. The reported issues have since been fixed.

One of the IDORs came from manually exploring an application. That was a pretty surprising find for me, especially with how little experience I had at the time.

Some of the other findings came from modifying requests, such as changing GET to another HTTP method and checking how the application responded. I was still learning, so it surprised me that a small change could reveal an issue.

Some people found it hard to believe that I had found five vulnerabilities that led to Apple Hall of Fame recognitions as a beginner. I was surprised too! It is possible, but this was my experience, and every hunt will be different.

The tools I used

My setup was simple:

A small note: ffuf paired with OneListForAll helped me a lot, including finding a subdomain that subfinder had missed.

I tested manually, spending time exploring applications, reviewing requests, and reading JavaScript.

Recon and choosing what to explore

For my first finding, I started by browsing crt.sh. For the subsequent findings, I used subfinder to collect subdomains and httpx to check which hosts were live. I also used ffuf with OneListForAll to explore further.

Some applications seemed very secure, while others looked like older sites that were no longer actively maintained. I spent time exploring both, but the seemingly forgotten ones often gave me more to investigate.

My recon approach was fairly basic back then. If you are starting out, I would suggest exploring recon more thoroughly than I did. Learn what different sources cover and take time to review what you find.

Apple owns the 17.0.0.0/8 IP address range, so there are plenty of assets to look at. Check the applicable program scope and testing rules before investigating a host.

If you are new, try not to feel overwhelmed or discouraged. You do not need to look at everything at once. Start with one application and take your time getting familiar with it.

Reading the JavaScript

Back then, I did not use a dedicated tool like LinkFinder. I used a browser extension called FindSomething to help identify things worth investigating.

One of the clues it surfaced actually led me to a good bug! I still had to investigate and validate the behaviour manually, but the extension helped me notice something I could have otherwise missed.

JavaScript files gave me references to endpoints and parameters that were not immediately obvious from browsing the application. From there, I could look at how those endpoints behaved and whether anything needed a closer look.

How I approached the testing

I spent time browsing each application with Burp running and reviewing the requests it generated.

I looked at the available features, parameters, identifiers, and endpoints. As I became more familiar with an application, I started asking questions about its behaviour:

An unexpected response was only a starting point. I still needed to understand what it meant and whether it demonstrated a security issue.

Reading other researchers’ write ups helped me develop those questions. I tried to understand why they tested something and how they confirmed the impact, rather than just copying the requests.

Reporting the findings

When I found an issue, I documented what was affected, the steps to reproduce it, and the impact supported by my testing.

Writing the reports was part of the learning process too. I wanted the person reviewing them to understand what I had observed and reproduce it without having to guess.

The reports took longer to work through triage, so the recognitions did not all arrive at once.

What I learned

I learned how to use a lot of recon tools, find subdomains, and explore assets beyond what I could see by simply browsing. My methodology has improved since then, and I have put together a dedicated article sharing some of the tools I find useful:

Cool Recon Tools for Bug Hunting

Do check it out! When I have time, I will write another article showing an easier way to collect domains too.

Reading other bug hunters’ write ups is a MUST! Their techniques and explanations helped me understand what to look for and gave me new ideas to try.

And of course, manual testing is still the GOAT 😂 Tools helped me discover things to investigate, and manual testing was what helped me turn those clues into findings.

Give yourself room to explore

Another tip is to approach bug hunting in a relaxed mood. I find it easier to explore and notice things when I am not putting pressure on myself to find a bug immediately.

Some of my findings came when I was simply poking around and following my curiosity. I was not expecting a discovery every time I opened an application, and that made the process more enjoyable.

Take breaks when you need them, and give yourself time. Not finding anything during a session does not mean you have learned nothing.

What I would do differently

I would organise my recon results and notes better. It was easy to lose track of what I had already checked or why I had saved a particular endpoint.

I would also spend more time learning what my tools could and could not find. Running a command was straightforward, but understanding its coverage and interpreting the output took practice.

I still have plenty to learn. These findings gave me confidence to keep going, but they certainly did not mean I had everything figured out.

A little thank you

A lot of this came from reading bug bounty articles written by other hunters. Their write ups helped me understand different techniques and gave me ideas to explore when I was still finding my feet.

Thank you to the bug hunters who take the time to share their findings, techniques, and thought processes. Your write ups helped me learn when I had very little experience, and I hope sharing my own journey can offer someone else a little encouragement too.

If you are new to bug bounty and feel intimidated, I understand. I started without knowing how to do recon properly, and much of what I learned came from reading, experimenting, and making mistakes.

Finding something is never guaranteed. But being new does not mean you cannot find something worth reporting. Give yourself time to learn, stay curious, and get to know the applications you are testing. Oh and lastly, make sure you are enjoying too 😎

#hacking