Multi-Service Infrastructure OSINT Chain: LDAP, OAuth, Kubernetes and Git Pivot Sequence

Why This Matters

The full infrastructure intelligence chain — from a single exposed directory service through authentication infrastructure to container orchestration, source code, and public credential dumps — represents the complete attack surface of a modern cloud-native organization. In the 2021 Microsoft Exchange Server breach attributed to Hafnium, the initial foothold was a single exposed LDAP endpoint whose anonymous bind allowed user enumeration, leading to targeted credential attacks against Exchange OWA portals and ultimately full internal network access. For defenders, understanding how an attacker chains LDAP exposure through each infrastructure layer to arrive at Pastebin-posted tokens is essential for threat modeling and detection engineering. For red teams, this chain demonstrates how a low-severity finding (anonymous LDAP read access) becomes a critical exposure when the infrastructure relationships are fully mapped. This five-pivot chain is among the most comprehensive passive reconnaissance workflows available to intelligence practitioners.

Core Concept

The five-pivot infrastructure chain treats each discovered infrastructure component as a pivot point to the next. The value is not in any single finding but in the chain's ability to transform limited initial access into comprehensive infrastructure knowledge.

Pivot 1 — LDAP Exposure: The Lightweight Directory Access Protocol (LDAP) operates on port 389 (TCP/UDP) for unencrypted connections and port 636 for LDAPS (TLS). Anonymous bind is an LDAP authentication mode that allows unauthenticated clients to query directory contents. When enabled on an internet-exposed LDAP server (a misconfiguration), it allows enumeration of user accounts, groups, organizational units, email addresses, and organizational hierarchy without any credentials. Shodan indexes LDAP banners on port 389 with the query port:389 org:target. Tools including ldapsearch (OpenLDAP client), nmap with the ldap-search script, and recon-ng modules enumerate user objects via anonymous bind.

Pivot 2 — LDAP Users to OAuth SSO: Usernames and email addresses harvested from LDAP directly target the organization's SSO portal. Modern organizations federate LDAP/Active Directory with OAuth providers (Azure AD Entra ID, Okta). LDAP userPrincipalName attributes ([email protected]) are the exact format expected by OAuth username fields. The organizational unit (OU) structure reveals team names and roles, enabling targeted spear-phishing or credential validation against the SSO portal. Additionally, LDAP description attributes sometimes contain OAuth application names or internal tool names that expose the SSO environment.

Pivot 3 — OAuth App Registrations to Kubernetes: OAuth application registrations in Azure AD or Okta sometimes include reply URLs (redirect URIs) that expose internal infrastructure: https://k8s-cluster-name.internal.company.com/oauth/callback reveals the Kubernetes cluster name and internal DNS structure. Kubernetes clusters configured for OIDC authentication reference the OAuth provider's issuer URL, creating a bidirectional linkage. Application names in OAuth registrations often directly encode the Kubernetes namespace or cluster name following internal naming conventions.

Pivot 4 — Kubernetes Cluster Names to Git: Kubernetes cluster names discovered via OAuth registrations or Shodan appear in developer commit messages, CI/CD pipeline configurations, and infrastructure-as-code repositories. GitHub code search for the cluster name returns deployment manifests containing namespace names, service account names, and Docker image references — all of which extend the infrastructure map. kubeconfig files in repositories reference the cluster by name and provide the API endpoint and credentials needed for cluster access.

Pivot 5 — Git Commit Authors to Pastebin: Git commit metadata includes the committer's name and email address, which may differ from their public GitHub username. Developer emails and usernames from git log output (recoverable from any cloned repository) are searchable on Pastebin via site:pastebin.com "[email protected]" Google dorks and via Pastebin's own search. Developers who accidentally paste debugging output, configuration snippets, or error logs to Pastebin sometimes include tokens, kubeconfig fragments, or API keys in the pasted content. Google dorks using site:pastebin.com "company-cluster-name" or site:pastebin.com "company.okta.com" recover these public pastes.

Technical Deep-Dive

# Pivot 1: LDAP anonymous bind enumeration
# Shodan: find exposed LDAP servers
shodan search 'port:389 org:"Target Corp"' --fields ip_str,port,org | head -20

# ldapsearch: anonymous bind user enumeration
LDAP_HOST="ldap.target.com"
ldapsearch -x -H "ldap://${LDAP_HOST}" -b "dc=target,dc=com" 
  "(objectClass=person)" 
  cn mail userPrincipalName sAMAccountName department 2>/dev/null | 
  grep -E '^(cn|mail|userPrincipalName|sAMAccountName|department):' | head -50

# nmap LDAP script (anonymous)
nmap -p 389 --script ldap-search 
  --script-args "ldap.base='dc=target,dc=com'" 
  ${LDAP_HOST}

# Pivot 2: Harvest emails from LDAP output, target SSO
# Extract email addresses from ldapsearch output
ldapsearch -x -H "ldap://${LDAP_HOST}" -b "dc=target,dc=com" 
  "(objectClass=person)" mail 2>/dev/null | 
  grep "^mail:" | awk '{print $2}' | sort -u > user_emails.txt

wc -l user_emails.txt
# => 847 — full employee email list from anonymous LDAP bind

# Validate email format against known SSO pattern
# (Azure AD tenant discovery — no auth required)
head -5 user_emails.txt | while read email; do
  domain=$(echo "$email" | cut -d@ -f2)
  curl -s "https://login.microsoftonline.com/$domain/.well-known/openid-configuration" | 
    python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('issuer','unknown'))"
done

# Pivot 3: Extract Kubernetes cluster names from OAuth reply URLs
# Azure AD application registrations — public tenant app list (if readable)
TENANT_ID="discovered-tenant-uuid"
curl -s "https://graph.microsoft.com/v1.0/applications?$select=displayName,replyUrls" 
  -H "Authorization: Bearer $GRAPH_TOKEN" | 
  python3 -c "
import json, sys, re
data = json.load(sys.stdin)
for app in data.get('value', []):
    name = app.get('displayName', '')
    for url in app.get('replyUrls', []):
        # Extract internal hostnames from OAuth callback URLs
        hosts = re.findall(r'https?://([a-zA-Z0-9-.]+)', url)
        for h in hosts:
            if 'internal' in h or 'k8s' in h or 'cluster' in h:
                print(f"{name}: {h}")
"

# Pivot 4: Search GitHub for discovered cluster name
CLUSTER_NAME="prod-us-east1-k8s"
gh search code "$CLUSTER_NAME" --owner=target-org --limit=30 
  --json path,repository | python3 -m json.tool | grep -E '"path"|"nameWithOwner"'

# Extract kubeconfig server URLs from search results
gh search code "server: https" --owner=target-org --limit=20 
  --json textMatches | python3 -c "
import json, sys, re
for r in json.load(sys.stdin):
    for tm in r.get('textMatches', []):
        servers = re.findall(r'server:s*(https://S+)', tm.get('fragment',''))
        for s in servers: print(s)
"

# Pivot 5: Git commit author enumeration + Pastebin search
# Extract all unique author emails from a cloned repository's full history
git -C ./cloned-repo log --all --format="%ae" | sort -u > commit_authors.txt
cat commit_authors.txt
# => [email protected], [email protected], [email protected]

# Google dork for each email on Pastebin (automate in a loop)
while read email; do
  query="site:pastebin.com+"${email}""
  echo "Dork: $query"
  # Manual execution in browser or via a search API
done < commit_authors.txt

# Pastebin direct search (pastebin.com has basic public search)
CLUSTER="prod-us-east1-k8s"
curl -s "https://pastebin.com/search?q=${CLUSTER}" | 
  grep -oP 'href="/K[A-Za-z0-9]+'  | head -20 | while read paste_id; do
  echo "=== Paste: https://pastebin.com/${paste_id} ==="
  curl -s "https://pastebin.com/raw/${paste_id}" | head -30
  echo ""
done

# holehe: check if developer email is registered on paste/code sharing sites
pip install holehe
holehe [email protected] 2>/dev/null | grep -v "not found"

Intelligence Collection Methodology

1. Initiate with Shodan LDAP discovery: Query port:389 org:"Target Organization" and port:636 org:"Target Organization" on Shodan. For each discovered LDAP server, attempt an anonymous bind with ldapsearch -x -H ldap://TARGET -b "dc=target,dc=com" "(objectClass=*)". Document whether anonymous bind succeeds and what base DN is accessible.
2. Enumerate LDAP user objects: If anonymous bind succeeds, enumerate all person objects: ldapsearch -x -H ldap://TARGET -b "dc=target,dc=com" "(objectClass=person)" cn mail userPrincipalName sAMAccountName department. Extract all email addresses and usernames to a clean list. Use theHarvester with the -b linkedin and -b google sources to cross-validate the user list against publicly available sources.
3. Identify the OAuth/SSO provider and tenant: From the harvested email domain, query the OpenID Connect discovery endpoint for Azure AD (https://login.microsoftonline.com/DOMAIN/.well-known/openid-configuration), Okta (https://COMPANY.okta.com/.well-known/openid-configuration), or Auth0. Record the tenant ID and issuer URL.
4. Map OAuth application registrations to infrastructure: If graph API access is available (or through indirect means such as published OAuth consent screens), enumerate OAuth application reply URLs for internal hostname patterns. Search for k8s, cluster, internal, kube in reply URL hostnames to identify Kubernetes cluster endpoints.
5. Correlate cluster names with Shodan: Search Shodan for the discovered cluster hostname patterns: hostname:cluster-name.company.com port:6443. Test discovered endpoints for anonymous API access with curl -k https://ENDPOINT/api/v1/namespaces.
6. Search GitHub for cluster-specific configurations: Use gh search code "cluster-name" --owner=target-org to find deployment manifests, Helm values files, and Terraform configurations referencing the cluster. These files contain namespace names, service account names, Docker image repositories, and secret references.
7. Extract git commit author identities: Clone all relevant repositories and run git log --all --format="%an|%ae" | sort -u to extract all commit author names and emails across the full git history. This list includes contractors and former employees whose accounts may still exist in systems.
8. Search Pastebin and code-sharing sites: For each discovered developer email and username, construct Google dorks: site:pastebin.com "[email protected]", site:gist.github.com "cluster-name", site:jsfiddle.net "company.okta.com". Run holehe against each developer email to identify which paste/sharing platforms they are registered on.
9. Compile the full infrastructure map: Assemble all findings into a single linked intelligence picture: LDAP server → user enumeration → SSO tenant → OAuth app registrations → Kubernetes cluster endpoints → git repositories → developer identities → Pastebin credential exposures. This map constitutes the complete intelligence product of the five-pivot chain.

Common Intelligence Collection Errors

• Stopping after confirming anonymous LDAP bind without full enumeration: Anonymous bind confirmation is only the starting condition. The intelligence value lies in the full user enumeration — email addresses, OU structure, department attributes, and description fields. Many analysts stop after confirming the vulnerability without harvesting its full intelligence yield.
• Ignoring LDAP operational attributes: Standard LDAP enumeration retrieves user attributes, but operational attributes (returned only when explicitly requested with + in ldapsearch) include whenCreated, whenChanged, lastLogonTimestamp, and pwdLastSet. These timestamps reveal which accounts are active and which have not logged in recently — critical for prioritizing targets.
• Treating OAuth tenant ID as a secret: The Azure AD tenant ID (UUID) is not secret — it appears in every OAuth redirect URL and is required by all OAuth clients. However, it enables discovery of all applications registered in the tenant via the Microsoft identity platform's public endpoints, so it is an intelligence starting point, not a finding in itself.
• Missing Pastebin alternatives: Pastebin.com is the most searched site, but developers also use Hastebin, Ghostbin, ix.io, dpaste.org, and GitHub Gist. Infrastructure strings (cluster names, internal hostnames, tenant IDs) should be searched across all major paste sites. Google dorks with site: for each platform are more reliable than platform-specific search APIs.
• Not accounting for LDAP referrals: Large organizations use LDAP referrals — pointers from one LDAP server to another for different organizational units or geographic regions. An anonymous bind that returns few results may be due to referrals pointing to other servers. The ldapsearch -C flag follows referrals automatically; omitting it produces an incomplete user list.
• Conflating git commit email with current corporate email: Developers change employers and email addresses. A git commit from 2019 may list a @contractor.com email for a person who now has a @target-company.com account. Always cross-reference commit author emails against the current LDAP user list to identify which historical committers remain current employees with active accounts.

NICE Framework Alignment

Further Reading

• The Hacker Playbook 3: Practical Guide to Penetration Testing — Peter Kim, Chapter 4: Active Directory and LDAP Attacks (Secure Planet LLC)
• Hacking the Cloud — AWS and Kubernetes Attack Chains — Nick Frichette (hackingthe.cloud)
• Penetration Testing: A Hands-On Introduction to Hacking — Georgia Weidman, Chapter 14: Attacking Authentication (No Starch Press)