DEV Community: Rxkov

Username OSINT Is a Graph of Attested Pages

Rxkov — Sat, 03 Oct 2026 22:18:33 +0000

A hunt that stops at https://twitter.com/{handle} is a template. It is not evidence. The page may 404. The same handle may belong to three people. A desk that stores that URL as a node is lying to the operator.

MAGO ships username hunts as an identity graph on mago.team. Nodes are attested pages. Edges are same-person relations pulled from JSON the platforms already publish.

Templates are not identity

HEAD requests against a guessed profile URL tell you the host answered. They do not tell you the person exists. GitHub, GitLab, Reddit, Hacker News, and Keybase each expose a JSON document for a named account. That document is the record. The HTML chrome is decoration.

GitHub's user payload includes blog, twitter_username, and social_accounts. Those fields are the operator's next hops. They are not guessed. They are claimed by the account owner on GitHub's API.

GitLab users, Reddit about.json, HN Algolia hits, and Keybase proofs follow the same rule. Fetch the document. Parse fields. Keep the URL only if the document names the handle.

The documents you actually fetch

GitHub: GET https://api.github.com/users/{handle}. Read login, blog, twitter_username, html_url. Then GET /users/{handle}/social_accounts for {provider, url} pairs. Dev.to also publishes GET https://dev.to/api/users/by_username?url={handle}.

GitLab: GET https://gitlab.com/api/v4/users?username={handle}. The first object is the person if the list is not empty. Website and bio sit on that object.

Reddit: GET https://www.reddit.com/user/{handle}/about.json. The live handle is data.name. Subreddit title and public description are extra labels, not extra people.

Hacker News: GET https://hn.algolia.com/api/v1/users/{handle}. A 404 is a missing user. A hit is a named account with karma and about text.

Keybase: GET https://keybase.io/_/api/1.0/user/lookup.json?usernames={handle}. Proofs in that payload name GitHub, X, Reddit, and a website. Those proofs are the edges.

None of these calls need a browser. None of them need a 200 from twitter.com/{handle}.

A HEAD probe misses four things. First, a parked profile that still 200s. Second, a renamed handle whose old URL 301s to someone else. Third, a display name that is not the login. Fourth, social links that live only in JSON. The graph records the document. It does not record the folklore.

Same person is a relation, not a vibe

Two nodes share a person when a document on one platform names the other. GitHub twitter_username pointing at X. A Keybase proof pointing at GitHub. A blog URL that matches a GitLab website field.

Confidence is not a slider. It is whether the source page was fetched and parsed. MAGO stores that as an attested page record on the investigation. The graph is the present step of collect, extract, correlate, present.

A list of green ticks is a scanner. An investigation is a workspace that keeps those relations next to the hunt that produced them.

Sherlock-style checkers enumerate sites. MAGO correlates claimed accounts. Enumeration is a list. Correlation is a graph. Operators already have lists. They need the second thing on a desk that already holds the hunt. The hunt that produced the GitHub node is the same hunt that billed milliscale credits. The graph does not fork that billed order.

What the desk actually does

Open an investigation on mago.team. Name it. Hunt a username from that case. The scan still quotes, queues, and writes a report. The identity graph is extra surface on the same order: nodes for GitHub, GitLab, Reddit, HN, Keybase when the JSON exists.

Edges carry labels such as same-handle or claimed-account. The canvas lives in the investigation workspace. It is not a marketing force graph on the home page.

The hunt bar stays hunt. Creating a case is a title and Open. Mixing those verbs is how desks turn into SaaS forms.

Credits still debit by module. Email hunts and domain hunts keep their own spell costs. Username identity is one more surface on the same milliscale wallet. You do not buy a second product to keep the person.

Why this belongs on mago.team

Operators buy a hunt, then they need a place to keep the person they found. A report is a snapshot. An investigation is the file that survives the next pivot.

Run the next username from https://mago.team. Open an investigation first. Let the graph fill from attested pages, not from URL folklore.

An Email Is a Hash, a Commit, and a Mailbox Policy

Rxkov — Tue, 29 Sep 2026 20:45:48 +0000

Most email OSINT tutorials start at a breach index. Start at the mailbox string itself. Three public facts fall out of one address before anyone pays for a dump.

The local part plus the domain is a Gravatar hash. Git stores the same string as a commit author. The domain publishes SPF and DMARC. Together they tell you who the person is, where they commit, and whether anyone can spoof the name.

Hash the mailbox, do not guess the face

Gravatar still keys profiles on a digest of the trimmed, lowercased address. Automattic documents the identifier in the REST hash guide. The public JSON is https://en.gravatar.com/{hash}.json.

import hashlib, json, urllib.request

email = "user@example.com".strip().lower()
digest = hashlib.md5(email.encode("utf-8")).hexdigest()
url = f"https://en.gravatar.com/{digest}.json"
with urllib.request.urlopen(url, timeout=10) as resp:
    profile = json.load(resp)
entry = profile["entry"][0]
print(entry.get("displayName"), entry.get("preferredUsername"))
print(entry.get("thumbnailUrl"))

A 200 with displayName is a public card. Display name, username, about text, and linked accounts are opt-in. A 404 means no public profile for that hash. It does not mean the mailbox is fake.

hashtray and similar tools reverse the hash by generating candidate addresses from the public card and hashing them until one matches. That is a dictionary attack on a public MD5. It is not a Gravatar "decrypt". Treat a reversed mailbox as a hypothesis until another source repeats it.

Git already published the author

Every Git commit embeds author and committer as name plus email. GitHub shows that metadata on public repos unless the user enabled email privacy. The GitHub API exposes it on commit objects.

GET https://api.github.com/search/commits?q=author-email:user@example.com

Accept header must be application/vnd.github+json. A personal token raises the rate limit. Hits return repo, SHA, and the author login GitHub attached to that email.

GitHub documents two noreply forms. ID+login@users.noreply.github.com and login@users.noreply.github.com. Both name the login. A corporate mailbox on public commits is a stronger identity signal than a handle match on a signup page.

The commit search API is preview-stable under application/vnd.github+json. Sort by committer-date if you need the last live use of that mailbox. A 2019 commit and a 2026 commit are different leads.

Do not treat one commit as same-person proof. Shared CI bots, rewritten history, and --author spoofing exist. Two repos, a Gravatar card, and a matching login is a working cluster. One hit is a lead.

The domain tells you if the name can be forged

Look up the registrable domain, not the person, for mail policy.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

v=spf1 ... -all is an explicit fail. ~all is softfail. A missing SPF record is not a pass. DMARC p=none is monitor-only. p=quarantine and p=reject are the policies that stop spoofed From headers at receiving MTAs.

A mailbox on a domain with p=none can be impersonated in a phishing wave even when the person is real. That fact belongs in the identity report next to the Gravatar photo. It is not a side quest.

WHOIS on the same domain is registrar data. RU-CENTER, GoDaddy, and Squarespace abuse inboxes are not the human. Put those rows in infrastructure. Keep them out of the name field.

One selector, three hops

The useful first pass is boring on purpose.

Hash the mailbox. Read the Gravatar JSON.
Search public commits for author-email.
Read SPF and DMARC on the domain.

Stop there if all three are empty. Pay for a breach index only when the public graph is thin and the case still needs it. Have I Been Pwned and similar services are keyed APIs. They are not the first hop.

mago.team runs this identity pack on a pasted mailbox. Gravatar, GitHub, and mail policy sit in the same report. Credits follow the spell table. The hunt is the mailbox. The dump is optional.

What not to mix into the name field

WHOIS registrant_name is often the registrar. "Regional Network Information Center, JSC dba RU-CENTER" is not a human identity. Squarespace abuse-complaints@ and NIC.RU tld-abuse@ are role mailboxes. Put them under registrar. Keep them out of the person's card.

GitHub handle collision is the other trap. A 200 on https://github.com/alice for mailbox alice@brand.com is a page, not same-person proof. The commit search with author-email is the join key. The handle is a maybe.

Disposable domains fail this pipeline on purpose. No Gravatar card. No corporate DMARC. No commit graph. That emptiness is the finding. Do not pad it with unconfirmed social URLs.

The first-pass identity report should be short. Photo if Gravatar has one. Login if commits join. Mail policy if the domain publishes it. Everything else is a pivot with a cost.

GitHub Dorks Still Work When You Scope Them to One Org

Rxkov — Tue, 29 Sep 2026 20:45:12 +0000

GitGuardian counted 28,649,024 new hardcoded secrets in public GitHub commits in 2025. That is a 34 percent rise from 2024, the largest jump in their series. Teams still treat a global filename:.env password search as recon. It is a firehose.

The index still holds the secrets. The query has to name an org, a user, or a domain. Unscoped dorks produce a feed. Scoped dorks produce a target.

Two search languages, one trap

GitHub now ships two code-search dialects. The website uses the 2023 code search syntax. Qualifiers are path:, org:, repo:, language:, and NOT is:fork. filename: is not in that table.

The REST endpoint GET /search/code still speaks the legacy search API. There filename:.env and user:acme still work. A token is required. Rate limits are 10 requests per minute on the core search route.

Paste a 2018 cheat sheet into github.com/search and the hits look empty. The operator did not die. The qualifier did. path:/(^|\/)\.env$/ is the current way to pin a basename. path:*.pem is the glob form.

mago.team github_dorks talks to the REST search API. It scopes user:{target} for a handle, or "domain.tld" as a quoted term for a company site. The spell needs a free GH_TOKEN. Without it the job is skipped, not faked.

Queries that still hit in 2026

Keep the org in every query. Drop the rest of GitHub.

org:TARGET path:/(^|\/)\.env$/ AWS_SECRET
org:TARGET path:*.pem "BEGIN PRIVATE KEY" NOT is:fork
org:TARGET "AKIA" NOT is:fork NOT path:test
org:TARGET path:*.npmrc _authToken
org:TARGET "xoxb-" OR "xoxp-" NOT is:fork

REST equivalents for a script:

filename:.env AWS_SECRET user:TARGET
filename:.pem "BEGIN PRIVATE KEY" user:TARGET
AWS_SECRET "TARGET.com"

GitGuardian's 2026 report put AI-assisted commits at roughly twice the leak rate of the GitHub-wide baseline. Generic secrets remain the majority class. Partner push protection still misses DATABASE_URL, home-grown bearer tokens, and .npmrc _authToken lines.

A 2025 InfoQ write-up of the prior report put generic credentials at 58 percent of detected leaks. A regex that only fires on Stripe and AWS misses most of the volume. Scoped .env search still pays.

What a hit is not

A code-search hit is a public string in a default-branch blob under 384 KB. It is not proof the secret is live. It is not proof the repo is still the company's. Forks copy history. Vendored trees copy other people's keys.

GitHub documents is:fork, is:archived, is:vendored, and is:generated. Exclude them on the first pass.

org:TARGET path:/(^|\/)\.env$/ NOT is:fork NOT is:archived

Do not open the credential. Rotate if it is yours. File a disclosure if it is not. Pasting a live key into a chat is a second leak.

Run it as a pipeline

A useful pass is three buckets, not 200 dorks.

Env and config: .env, .npmrc, credentials, docker-compose*.yml.
Key material: PEM, AKIA, Slack xoxb-, Stripe sk_live_.
Company string: the apex domain next to password or api_key.

Record the query, the total_count, and three sample paths. That is enough to decide the next hop: rotate, disclose, or ignore.

mago.team runs that pass as github_dorks on a handle or org. Hits land in the same report as DNS, WHOIS, and JS. The hunt is one selector. The dorks are one spell, not a weekend of curl.

Why the 2018 lists still circulate

Cheat sheets keep listing filename:.env password with no org. That query searches the planet. GitHub code search ranks recent public blobs. The first page is random startups, course repos, and copied Docker samples.

GitGuardian's 2026 public-relations note added two numbers that matter for hunters. Secret leak rates in AI-assisted commits ran about double the GitHub-wide baseline across 2025. MCP config files in the study exposed 24,008 unique secrets. Copilot-enabled public repos in the 2025 report leaked at 6.4 percent, against 4.6 percent overall.

Those are volume stats. They do not tell you which org is yours. An unscoped dork of AKIA will show AWS keys that are not in your incident. An org:TARGET AKIA query either hits or it does not. That is the difference between a feed and a case.

The 2025 report also said 70 percent of secrets leaked in 2022 were still valid years later. Rotation is the control. Search is how you find the copy that nobody rotated. Scope the search or you will rotate the wrong tenant.

REST search indexes default branches and files under 384 KB. History-only leaks need git log -p on a clone, or a tool that walks commits. Code search will not see a key that lived in one commit and was rewritten out of HEAD. Say that in the report. Do not claim "GitHub is clean" because total_count was zero.

Global cheat sheets will keep circulating. They search the planet. The incident is in one org.

Your JS Secret Scanner Is Reading webpack Polyfills

Rxkov — Tue, 29 Sep 2026 20:44:37 +0000

Keyword secret scanners love the word password inside JavaScript. Next.js ships a URL polyfill that parses username and password off every URL. The password is often an empty string. The scanner still screams CRITICAL.

The finding is a parser, not a credential. If the report attributes it to the target, the grade is a lie.

Where the empty password comes from

The WHATWG URL Standard stores userinfo as username and password. new URL("https://example.com/path") has an empty password. Polyfills copy that object into the bundle so old browsers can parse URLs.

Chromium and Node both expose url.password as a string. Empty is valid. A scanner that flags any identifier named password cannot tell a URL field from const password = "hunter2". The second is a secret. The first is the platform.

Next.js has long inlined those polyfills in a polyfills-*.js chunk under /_next/static/chunks/. The minified code still contains the property name password and the helper cannotBeABaseURL. A naive password_in_code rule fires on that chunk for every Next site on the internet.

Google Tag Manager and Shopify pixels produce the same class of hit. A third-party shop page in urlscan mentions the target in a query string. The JS job then "finds" an OAuth client id that belongs to the shop, not the seed domain.

First-party or it does not count

A JS finding is on-target when the script URL is the apex or a subdomain of the seed. app.example.com is in. cdn.shopify.com is out. accounts.google.com is out.

def is_first_party(script_host: str, apex: str) -> bool:
    host = script_host.lower().rstrip(".")
    root = apex.lower().rstrip(".")
    return host == root or host.endswith("." + root)

Drop the finding when every extracted URL in the blob sits off-apex. Keep it when the bundle is https://example.com/_next/static/chunks/main-*.js and the secret is a real AKIA or sk_live_ value.

Polyfill markers that have no business in a customer HUD:

cannotBeABaseURL
password:""
password\":\"\"

Those strings are URL parser furniture. They are not a dumped admin password.

What the HUD should show instead

A useful JS section lists endpoints and real secrets on first-party hosts.

/api/v1/forms on https://example.com is an endpoint. INFO.
AKIA plus 16 more chars in https://example.com/static/app.js is a key. HIGH or CRITICAL after a shape check.
password="" in polyfills-*.js is noise. Delete it.

mago.team js_analyzer follows only HTTP 200 origins on the scanned selector. Off-target urlscan neighbours do not get queued. The report builder then drops polyfill and off-apex js_secret rows so they cannot tank the aggregate score.

A recon grade of A+ next to a page of CRITICAL JS hits is how you lose the operator. The polyfill was never a credential. The empty password was never a dump.

How to verify on one host

Fetch the homepage. Collect script src values. Keep hosts on the apex. Scan those bodies for key shapes, not the word password.

AKIA[0-9A-Z]{16}
sk_live_[0-9a-zA-Z]{8,}
-----BEGIN (RSA )?PRIVATE KEY-----

If the only hit is password next to cannotBeABaseURL, the scanner is reading the platform. Switch the rule. Paste the same host into mago.team and compare the JS section. The pipeline should stay quiet unless a first-party bundle leaked a key.

Why this wrecks a domain grade

A typical Next marketing site has one polyfill chunk and a GTM snippet. A keyword scanner emits 20 CRITICAL js_secret rows. The aggregate score falls off a cliff. The operator sees "compromised." The page is a stock create-next-app output.

mago.team dropped those rows after they showed up as CRITICAL on properties that were not breached. The filter lives in the report builder. New scans do not store the polyfill hit. Old reports still show it until a rescan.

urlscan adds a second lie. A neighbour page with a 200 can mention the seed in a Google tag. If the follow-up JS job uses that URL as origin, Shopify pixels and Keycloak query strings land in the customer HUD. Restrict follow-ups to HTTP 200 on the seed apex and its subdomains.

Header-grade D and DMARC p=none are real. They should move the ring. A polyfill password should not. Mix them and nobody trusts the number.

The test is simple. If the same CRITICAL fires on every Next.js site you scan, it is the framework. Delete the rule. Keep the AKIA rule. Keep the first-party host check. Then the JS section is short enough to read.

GitHub Push Protection Is a Pattern Match, Not a Secrets Boundary

Rxkov — Thu, 17 Sep 2026 21:06:07 +0000

GitGuardian counted 28,649,024 new hardcoded secrets in public GitHub commits in 2025. That is a 34 percent rise from 2024, the largest single-year jump in their series. Teams still treat GitHub secret scanning as if it made a public repository safe for credentials. It did not. It delayed a subset of partner-shaped tokens.

Push protection is a pattern match at the remote. Generic secrets, git history, gists, and a one-click bypass sit outside that match. Partner notification buys minutes for AWS and Stripe. It does not inventory what you already committed.

What GitHub actually blocks

Secret scanning on public repositories is free and automatic. GitHub documents the scope: git history on all branches, issues, pull requests, Discussions, wikis, and secret gists. Partner patterns get forwarded to the issuer. GitHub personal access tokens leaked in public repos are revoked by GitHub itself.

Push protection is the earlier check. It refuses a push that contains a detector GitHub has high confidence in. The June 2026 changelog added default push-protection for Cloudflare tokens, OpenRouter keys, Supabase PATs, and others. The list grows every few months. That is the product working as designed.

The list is also the limit. GitHub's pattern table splits detectors into partner, user-alert, push-protection-default, and configurable. Generic connection strings and home-grown API keys sit in the generic or custom buckets. Those are not the default push-protection set. GitGuardian's 2025 report, covering 2024, put generic credentials at 58 percent of detected leaks. A regex that only fires on Stripe and AWS will miss most of the volume.

Validity checks are a second product, not the same as partner notification. Partner notification tells Stripe or AWS that a public repo just received their token. Validity checks tell you whether a secret in your alert is still live. GitHub documents the split. Mix the two and the team waits for a vendor. The vendor never sees a custom API key.

The four holes that remain

The first hole is generic secrets. A DATABASE_URL with a password. A Postman PMAK- key that is not yet a default detector. A bearer token with no vendor prefix. Push protection does not block what it cannot name.

Code search still finds the leftovers. These queries are boring on purpose:

path:.env password
filename:.npmrc _authToken
"Authorization: Bearer" extension:md
filename:mcp.json env

None of those strings is a partner detector. All of them are how internal APIs, package registries, and agent configs actually ship credentials. GitHub will index the file. It will not refuse the push.

The second hole is history. Secret scanning will alert on an old commit. Push protection will not un-commit it. Rotation is the fix. Rewriting history is optional and often skipped. GitGuardian retested secrets first seen in 2022. 64 percent were still valid in January 2026.

The third hole is the bypass. A developer with write access can push through protection by giving a reason. Organizations can lock this down with delegated bypass. Most public repos never turn that lock on. The control then becomes a dialog, not a gate.

The fourth hole is the private-to-public flip. Push protection on private repos is a paid GitHub Secret Protection feature. Secrets committed while the repo was private become public the moment visibility changes. GitGuardian found internal repositories six times more likely to contain hardcoded secrets than public ones. The day you open-source the prototype, you publish the leftover keys.

AI commits doubled the leak rate

GitGuardian scanned public commits through 2025. Secret leak rates in AI-assisted code were roughly double the GitHub-wide baseline. Leaks tied to AI services rose 81 percent year over year, to 1,275,105. MCP server docs often tell people to put credentials in config files. The same report attributes more than 24,000 exposed secrets to that pattern.

GitHub is adding detectors after the fact. Lovable Labs joined the partner program in August 2026. GitGuardian detected 113,000 new DeepSeek API keys in 2025, before a detector existed. The gap between a new SaaS token format and a default push-protection rule is measured in months. Agents generate the config in seconds.

What a practitioner actually does

Turn on push protection and leave it on. That is table stakes, not a strategy. Then treat GitHub as one surface among several.

Scan for generic patterns, not only partner prefixes. gitleaks and trufflehog still catch connection strings GitHub will not block. Run them on history, not only HEAD.

Assume every public gist and every fork is in scope. GitHub scans secret gists. It does not make the gist private for you. A gist created to debug a webhook is still a public document with a guessable URL until you delete it.

Forks copy the blob. If the parent later rotates, the fork keeps the old value until someone force-pushes or deletes the repo. Secret scanning on the parent does not fan out a revoke to every fork. That is your job.

Rotate on alert. Do not wait for a rewrite of git history. The credential is the asset. The commit is the evidence.

If the work is a bounty or a vendor review, search what GitHub will not. Filename filters, .env remnants, Authorization: Bearer in examples, MCP json with env blocks. Related method on this site: GitHub OSINT and [five leak surfaces HIBP will not show](https://blog.mago.team/post/five-credential-leak-surfaces-hibp-wont-show).

mago.team runs that pass as a pipeline. The local encoding of the same idea is spy. Neither replaces rotation. Both keep the first hop honest.

GitHub's scanner is a good delay. It is not a boundary. Plan the inventory as if the delay failed, because for generic secrets it already did.

The OPSEC of OSINT Tooling - s.py

Rxkov — Thu, 17 Sep 2026 19:40:05 +0000

Every OSINT query has two audiences: you, and whoever operates the resolver, the API, and the log pipeline behind it.

If collection runs in someone else's cloud, your target list is shared. That can be acceptable, but it is an OPSEC choice that must be intentional. The industry default is convenience: analysts paste a domain into a web form, then debate TTPs in the final report. The primary TTP—where the query actually executed—gets ignored.

A local toolkit keeps the first hop honest. DNS, WHOIS, certificate transparency, and passive IP enrichment rely on public data. There is no technical reason this data must transit a third-party vendor before reaching your notes.

spy runs these checks locally:

python3 s.py run dns_deep example.com
python3 s.py run whois_osint example.com
python3 s.py run cert_transparency example.com
python3 s.py intel 1.2.3.4 --json

Active probes are gated. Without a defined scope, execution is blocked. This applies the same principle used in senior agent harnesses: no tool call without limits.

Use a hosted scanner like mago.team when you need broad coverage without managing infrastructure. Use a local pipeline when target lists are sensitive or when methodologies must survive vendor lock-in.

Convenience is not a strategy. Choose your approach deliberately.

rxkov / spy

OSINT and reconnaissance toolkit

spy

OSINT and reconnaissance. The method is the pipeline.

spy encodes DNS, WHOIS, certificate transparency, identity correlation, and public threat feeds as named passes that run on your machine. No account No SaaS hop unless you choose one.

Authorized targets only.

Why spy

Most OSINT is still a shopping list in someone's head. Open this registrar. Query that CT log. Remember SPF. The sequence dies when the analyst is tired.

A checklist that cannot be executed the same way twice is folklore.

spy treats collection as a pipeline: stable order, stable output, inspectable steps. You can drop a stage. You can rerun last quarter and diff the JSON. You can refuse to send the target to a third party.

That last point is OPSEC, not preference. Every query has two audiences: you, and whoever logs the resolver.

Install

Python 3.11+.

git clone https://github.com/rxkov/spy.git
cd spy
python3 -m venv .venv

…

View on GitHub

Your S3 Bucket Might Be Public Right Now. We'll Tell You First.

Rxkov — Sun, 06 Sep 2026 05:59:53 +0000

Your S3 Bucket Might Be Public Right Now. We'll Tell You First.

GrayhatWarfare's public index holds 470,600 open buckets today. An attacker searches your company name, filters by .env or backup.sql, and has a working target list in under a minute — no cost, no advanced technical skill, no trace in your logs.

Cloud storage misconfiguration is the number one cause of cloud data exposure. Not zero-days, not provider failures — wrong configuration. Public S3 buckets, Firebase databases left in test mode, Azure containers with anonymous read enabled: all discoverable by anyone with an internet connection. The gap between "configured" and "audited" is where breaches happen — and GrayhatWarfare fills that gap within two weeks.

The Problem Is Visibility, Not Technology

AWS, Google, and Microsoft ship robust controls to block public access. The issue isn't the provider. It's what happens between the moment a developer spins up a bucket in test mode to speed up development and the moment someone notices that configuration went to production.

In most organizations, nobody notices. Not because the team is incompetent — but because proactive cloud storage audits aren't part of the standard operational flow. When the alert arrives, if it arrives, it's an external incident report, a researcher notification, or a headline.

This isn't a hypothetical. In 2019, Chtrbox — an influencer marketing firm — left their Firebase database in test mode in production. Result: data on 49 million Instagram users exposed publicly, including emails, phone numbers, and location data. The disclosure reached TechCrunch before it reached the company's own security team.

In another incident, a single S3 misconfiguration exposed 273,000 bank transfer PDFs — routing numbers, account numbers, full transaction records. Discovered through passive reconnaissance. No active exploitation. No warning.

Gartner projects that 99% of cloud security failures through 2026 will be customer-side configuration failures. The question isn't whether you have a misconfiguration. It's whether you find it first.

What intel.mago.team Does for Your Team

intel.mago.team scans your cloud infrastructure across the same vectors attackers look for — S3, Firebase, Azure Blob, GCS — and delivers an exposure report before the problem appears in a public index like GrayhatWarfare.

Every exposure found comes with full context: which resource is exposed, what type of data is accessible, severity level, and the specific remediation step. No manual analysis on your end. You open the report, prioritize by severity, act.

The vectors covered are exactly those behind the largest cloud data breaches in the last five years:

S3 buckets with public read or write permissions
Firebase rules in test mode that survived past their 30-day window
Azure Blob containers with anonymous read enabled
GCS buckets with IAM bindings open to all users
Configuration files, API keys, and .env files in public storage

The Difference Between Finding and Being Found

Teams that scan proactively find the exposure on their own schedule, with time to act before data is copied. Teams that don't scan receive notification from the outside — from a researcher who already accessed the files, or worse.

The difference between the two scenarios isn't technical sophistication. It's knowing the problem exists while it's still yours to resolve.

Run a scan at intel.mago.team against your infrastructure today. If there's an exposure, you'll know before any attacker does. If there isn't, you have auditable evidence that the check was done — not just the hope that everything is fine.

Your S3 bucket might be public right now. Find out first.

API Security Testing: OWASP Top 10 for APIs

Rxkov — Sun, 06 Sep 2026 05:58:41 +0000

T-Mobile, Peloton, and Optus all had active security programs. All three were breached through API vulnerabilities that existing tests never caught, because the exploited endpoints were not in anyone's inventory.

Security teams that rely on pre-deploy testing pass audits and still get breached. API attack surface drifts after deploy. No static scanner can test what it doesn't know exists.

Your OpenAPI Spec Is Not Your Attack Surface

Production APIs diverge from documentation within weeks. Shadow endpoints accumulate through feature flags, deprecated versions that were never deactivated, and side-channel leaks in microservices. None of these endpoints are visible to scanners that operate on code.

Security teams running comprehensive discovery for the first time consistently find more endpoints than documented — the gap between the specification and what runs in production is substantial. Shadow APIs account for a significant share of API traffic at mid-to-large enterprises, with security teams unaware they exist.

The 2022 Cequence report recorded 5 billion malicious requests out of 16.7 billion total, all targeting unknown and unmanaged APIs. OWASP API9:2023 names this Improper Inventory Management: beta endpoints frequently lack the rate limiting and authentication equivalent to production, and the absence of documentation lets them be exploited without the security team knowing they exist.

The 2022 Optus breach made the cost concrete. An undocumented, unauthenticated endpoint exposed data on 9.7 million customers. The endpoint appeared in no OpenAPI spec. SAST and DAST inherit the developer's endpoint list and never test what they don't know exists.

BOLA Has Led the List for Five Years Because Auth Only Breaks at Runtime

Object-level authorization failures are not detectable through static analysis. They require real user IDs, real objects in the database, and runtime context. Every static scanner misses this category by design.

The 2021 Peloton breach exposed more than 4 million user records, including accounts configured as private. Authenticated users could access any other user's data by swapping the ID in the request path. Peloton had authentication working. It had no per-object authorization check on each endpoint.

T-Mobile in 2023 saw 37 million customers affected by an API without adequate authorization checks. The class action settlement reached 350 million dollars. OWASP has ranked BOLA as API1:2023 for five consecutive years, and the category appears in roughly 40 percent of all documented API attacks.

The technical reason is straightforward: BOLA requires active runtime context. A valid user session, real objects in the database, and a sequence of requests that crosses ownership boundaries between users. No code scanner can simulate that context. The vulnerability is not in the source code -- it lives in business logic executing with production data. That structural gap is why BOLA has led the list since 2019.

JWT Misconfigs Survive Code Review Because They Are Config Bugs, Not Code Bugs

The most critical JWT vulnerabilities exist in the deployed configuration, independent of source code. Updating the library version does not fix a misconfigured token validation endpoint in the API gateway.

CVE-2024-31033 affects JJWT: incorrectly configured signing keys allow token forgery with weaker authentication than expected. CVE-2026-29000 affects pac4j-jwt in versions before 4.5.9, 5.7.9, and 6.3.3. An attacker with access only to the RSA public key can forge JWTs with arbitrary claims and authenticate as any user, including administrators.

The alg:none attack works as follows: the attacker removes the token signature and sets the algorithm field to none. The server accepts the token if it does not explicitly reject that value in configuration. The RS256-to-HS256 confusion attack uses the RSA public key as an HMAC secret. An attacker who knows the public key signs tokens that the server accepts as valid.

SAST sees the JWT library import in the code. It does not see the token validation configuration deployed in the API gateway or server environment variables. The code can be correct while the configuration is wrong. That distinction is what makes this vulnerability class survive complete code reviews. Tools that test active endpoints, like the jwt_scanner at intel.mago.team, detect these misconfigurations at runtime.

The OWASP API Top 10 Is a Taxonomy, Not a Detection Workflow

Most practitioners use the OWASP Top 10 as a code review checklist. The actual detection workflow requires active endpoint discovery, runtime probing, and drift comparison against inventory. No static tool executes these steps.

The major API security vendor blogs follow the same pattern: they explain the categories with generic examples and provide no end-to-end detection methodology. SAST identifies code patterns but does not detect authorization gaps, configuration drift, or undocumented endpoints. DAST tests running applications but needs a known endpoint list, so shadow APIs are never tested.

Authorization failures, business logic abuse, and multi-step flow exploitation depend on runtime context and sequencing that static analysis cannot see. The fundamental gap is this: knowing which vulnerability categories exist is not the same as knowing whether your deployed API is vulnerable to them. The taxonomy describes what can happen. The detection workflow determines what is happening now, with your active endpoints.

The Detection Workflow Starts with Discovery, Not Scanning

Effective API security testing follows a fixed sequence: passive discovery to find what exists, fingerprinting to understand the stack, targeted probing for each category. Skipping the first step means scanning a fraction of the real surface.

Step 1: discovery via subdomain enumeration, JavaScript bundle extraction, path traversal on API gateways, and fingerprinting with Shodan and Censys. Step 2: inventory baseline, mapping discovered endpoints against the documented spec and flagging shadow endpoints and deprecated versions still active. Step 3: authentication probing on each endpoint, testing auth bypass, alg:none acceptance in JWT, and missing required authentication headers.

Step 4: BOLA and BFLA testing. For each endpoint that handles objects, probe with valid authentication but a different user context and verify whether the response is 403 or 200 with another user's data. Step 5: continuous comparison, re-running discovery weekly and generating a diff against the last known inventory to detect drift. Each step depends on the previous one. Without full discovery, scanning tests only the endpoints you already documented.

Runtime and Development Posture Diverge at Deploy Time

Protecting production APIs requires continuous external testing against active endpoints, from the same perspective an attacker has. Internal testing from the development side does not detect the configuration, routing, and endpoint drift that emerges in production.

The scenario documented in OWASP API9:2023 is direct: a beta API without rate limiting was used to brute-force password reset tokens. The production API had rate limiting. The beta version did not. The security team tested the production version and passed the audit.

The scale of the problem is growing faster than review cycles can track. Organizations with more than 100 API endpoints went from 4 percent in 2024 to 38 percent in 2025. 84 percent of security professionals reported API-related incidents in the past 12 months, most involving endpoints unknown to the internal team.

External API testing, conducted from outside the network perimeter, detects routing misconfigurations, exposed internal endpoints, and authentication gaps that internal tools cannot reach. Each new API version creates shadow endpoints until the documentation is updated. The intel.mago.team approach combines continuous external discovery with jwt_scanner and technology fingerprinting on active endpoints, not on code.

The scanner testing your pipeline doesn't know what the deploy delivered.

Threat Intelligence 101: From Raw Data to Actionable Insights

Rxkov — Sun, 06 Sep 2026 05:58:01 +0000

The SOC got the alert at 2 a.m. By the time the analyst correlated the IOC with the logs and confirmed relevance, the attacker had already moved laterally into three internal servers. The intelligence was right. The pipeline was the problem.

Most organizations already pay for threat intelligence feeds. The gap is not data: it is operationalization. IOCs arrive in dashboards and PDFs that never automatically translate into detection rules, blocklists, or playbooks. The speed advantage that intelligence should deliver gets destroyed by manual correlation that no team can sustain at scale.

The Operationalization Gap

Organizations that suffered breaches in 2024 and 2025 were not operating without intelligence. They had feed subscriptions. The pattern documented in security research is consistent: intelligence arrives, operations cannot absorb it within the relevant time window, the moment passes, and the lesson disappears without a record.

An IOC that fires without an associated playbook is a documented detection gap. CISA demonstrated with the AIS (Automated Indicator Sharing) program that machine-speed sharing is a solved problem: STIX 2.1 for structure, TAXII 2.1 for transport. What AIS does not solve is the last mile: mapping indicators to SIEM rules and EDR actions, a step that most teams still handle manually.

Automating the conversion of CTI reports into detection rules exists as an active research field, but adoption in SOC teams has not kept pace with the volume of intelligence produced. Organizations continue paying for intelligence that never reaches the detector.

What Threat Intelligence Actually Is

Intelligence is not the same as data. STIX 2.1, ratified by OASIS in June 2021, defines structured objects with 18 domain objects and 18 cyber-observable objects to represent context, relationships, and relevance. A CSV list of IPs has none of that.

The practical distinction splits intelligence into three layers: strategic informs long-term decisions, operational supports campaign planning, and tactical provides IOCs for immediate detection. Most commercial feeds deliver exclusively the tactical layer, which also has the shortest shelf life.

MITRE ATT&CK v18 (October 2025) catalogs 14 tactics, 216 techniques, and 475 sub-techniques for the Enterprise environment. Adversary techniques change on a quarterly timescale. IOCs change on an hourly timescale. Building detections based on ATT&CK TTPs produces rules that survive attacker infrastructure rotation.

Commercial Feeds Solve the Wrong Problem

Commercial feeds deliver what is easy to deliver: IP addresses, file hashes, and domains. The problem is that attackers rotate IPs within hours, and half of fresh feed indicators generate false positives from legitimate business traffic, requiring manual triage before any application. With each new batch of indicators, analysts must filter before applying, destroying the automation gain.

The result is context loss at delivery: the SOC receives values, not intelligence. An IP address without information about which campaign, which actor, and which technique it represents is noise dressed as signal.

IP blocklists have a shelf life of 24 to 72 hours under normal conditions, and shorter when the attacker notices they are being blocked. Relying exclusively on tactical feeds anchors detection in infrastructure-centric thinking, while the approach that survives is behavior-centric. ATT&CK was built precisely for that paradigm shift.

Underused Passive Sources: What You Already Have

Operationalizing threat intelligence does not require depending exclusively on external feeds: the organization's own attack surface already generates primary intelligence that no vendor can see. Certificate Transparency logs are public and free. When an attacker registers a typosquat domain for a phishing campaign, they need an SSL certificate before launching the infrastructure. That certificate gets logged in CT logs and is available for query before the attack starts. IOC feeds only capture the domain after the campaign is active and observed by third parties.

SecYbers documents that CT logs combined with DNS and WHOIS data enable full adversary infrastructure mapping before the active phase of the campaign. Subdomain drift, the creation of unmanaged subdomains on the organization's own domains, exposes attack surface that no external feed can see because it is internal. Technology fingerprinting reveals exposed services before attackers discover them through their own scans.

These sources are continuous intelligence generated by the organization's own attack surface. Tools like intel.mago.team/spells monitor CT logs and infrastructure detection automatically as intelligence sources; for point-in-time queries, crt.sh offers free search and SSLMate's Cert Spotter provides continuous monitoring with a free tier. Most teams outsource intelligence generation to external feeds while already operating high-quality primary sources without processing them.

How Automation Closes the Gap

The minimum functional pipeline has four stages: ingestion of structured sources, enrichment with context, mapping to ATT&CK TTPs, and automatic delivery to SIEM or EDR. The gap lives between mapping and delivery, which is exactly where manual work intervenes and destroys the speed that automation should provide.

TAXII 2.1 solves the transport layer: feeds that publish via TAXII allow automated ingestion without manual CSV parsing. STIX 2.1 solves structure: typed objects with explicit relationships let downstream systems process indicators without human intervention. CISA provides AIS access via TAXII to any organization that wants to start with government-sourced intelligence.

Research published on arXiv in 2026 (From IOCs to Regex, arXiv:2604.12228) demonstrates that LLMs can convert CTI reports into regex expressions for detection with a significant degree of automation. The problem is not technological: teams that do not define what they need to detect before buying feeds have no way to evaluate what to automate.

Building the Minimum Pipeline

The most common mistake is starting with the feed and working back to requirements. The functional pipeline reverses that order.

Step one is defining intelligence requirements based on realistic threats for the organization's sector, size, and technology stack. Without that, any feed generates noise. Step two is an attack surface inventory, because you cannot prioritize intelligence without knowing what to protect. Step three is structured ingestion: feeds in STIX format via TAXII enable automation; raw CSVs do not. Step four is TTP mapping, building detections based on adversary behavior rather than point-in-time indicators that expire. Step five is the feedback loop: measure how many alerts generated by last quarter's intelligence produced an actual security decision change.

The 2025 arXiv research on MITRE ATT&CK applications (arXiv:2502.10825) identifies automated TTP extraction from reports as a critical gap. Most organizations perform that mapping manually, making the most time-consuming pipeline stage also the most error-prone.

What to Operationalize First

Operationalization priority follows immediate impact with minimal configuration friction.

Credential exposure monitoring detects when organizational accounts appear in public dumps before attackers use them. Certificate issuance monitoring via CT logs detects phishing infrastructure before campaign launch. Subdomain drift detection exposes attack surface that was never inventoried.

All three share one property: they produce actionable alerts, not reports. The output is a suspect domain to block, a credential to rotate, a subdomain to disable. Define your requirements before buying the next feed. Set up CT log monitoring for your domains. Map your detections to ATT&CK TTPs, not IP lists. Intelligence that never reaches the detector is indistinguishable from having no intelligence.

Web Application Reconnaissance: Mapping the Attack Surface

Rxkov — Sun, 06 Sep 2026 05:57:25 +0000

Subfinder returns 1,247 subdomains in 19 minutes. Amass adds 340 more from passive sources. The pentest report covers 12 of them.

That gap is where most critical bugs survive. Not because the team missed the assets, but because there was no layer to decide which ones to test first.

Recon produces lists. Practitioners who find critical vulnerabilities first treat those lists as input to a risk scoring layer, not as a final deliverable. The difference between an attack surface report and an actual attack map lives in that intermediate step: internet exposure, known CVE surface, and business criticality.

Recon Data Is Not Intelligence: The Volume Problem

Modern subdomain enumeration tools deliver impressive scale in minutes. Subfinder queries 103 passive sources simultaneously; Amass adds active brute-force enumeration over wordlists of one million entries. The problem that volume creates is a filtering problem.

The OWASP Attack Surface Management Top 10 places "unknown and unmanaged external assets" at the top of the risk list. Organizations frequently don't know the full extent of their own exposed surface. An annual pentest scoped to the main domain leaves the rest untouched.

The distinction that matters is between attack surface and exploitable surface. A list of 1,247 subdomains is an attack surface. Exploitable surface is the subset with active DNS, a stack with a public CVE and CVSS above 7.0, and a path that touches authentication or sensitive data. The gap between those two numbers is where tools stop and judgment begins.

Technical reports without business context are not actionable. A subdomain running Apache 2.4.49 with public exposure is priority zero: CVE-2021-41773 carries CVSS 9.8 and widely documented public exploits. A subdomain running Apache 2.4.53 on staging with no active DNS is a candidate for deprioritization. Risk scoring makes that distinction; the raw list does not.

Passive Discovery: Mapping Without Touching

Certificate Transparency logs are the most underrated resource for passive discovery. Every TLS certificate issued by a trusted CA appears in a public, immutable log within minutes of issuance. Before a new subdomain even has full DNS propagation, it is already visible in the CT history.

crt.sh exposes that history through a direct SQL API. A query for %.empresa.com returns every subdomain that has ever received a certificate, including admin panels provisioned once and never formally decommissioned. A certificate issued in 2019 for dev-api.empresa.com stays in the log even if the subdomain was later disabled.

Google and Bing surface accidentally indexed content through search operators. site:empresa.com filetype:env finds published .env files. inurl:empresa.com admin login finds panels exposed to crawlers. The OWASP WSTG operator collection covers 40 distinct search patterns for sensitive data indexed without intent.

Passive DNS databases like SecurityTrails and VirusTotal store resolution history for years. SecurityTrails /v1/domain/{domain}/subdomains returns up to 10,000 historical subdomains via API; VirusTotal /domains/{domain}/subdomains supplements that with resolution data from threat intelligence feeds. A corporate acquisition that brought in domains from a purchased company shows up in that history before any public announcement. WHOIS and RDAP expose ownership records that link seemingly independent domains to the same registrant.

Public repositories on GitHub and GitLab routinely expose internal hostnames, API tokens, and environment keys in commit history — the dork site:github.com 'company.com' 'password' is standard practice in passive reconnaissance.

The operational advantage of all these methods is zero interaction with the target infrastructure. No packets sent means no IDS alerts, no access logs, no anomalous monitoring window. The passive phase is where information asymmetry exists before any contact is made.

All of that data arrives as raw lists — the resulting volume is precisely what makes the scoring layer non-optional.

Stack Fingerprinting: Disclosed Versions as a CVE Shortlist

Every version string a server leaks is a direct lookup against CVE databases. Fingerprinting does not find vulnerabilities; it narrows the search space to confirmed candidates with documented exploits.

HTTP headers are the first signal layer. Server: Apache/2.4.49 identifies the exact version. X-Powered-By: PHP/8.0.1 does the same for the runtime. X-AspNet-Version: 4.0.30319 and X-AspNetMvc-Version: 5.2 reveal the full stack in two response lines. These headers are enabled by default in standard configurations and rarely disabled in production.

Session cookie names identify frameworks without any response body analysis. PHPSESSID indicates PHP; JSESSIONID indicates Java EE or Spring; ASP.NET_SessionId indicates .NET. Combined with the Set-Cookie header value, these names build a partial stack map without any vulnerability scanner.

Error pages are immediate visual signatures. Apache Tomcat's default 404 has specific HTML with the Jakarta logo. Spring Boot's 500 exposes "Whitelabel Error Page" by default through version 2.x. IIS 7.5 has an error page with a proprietary HTML structure. Any of these patterns connects the asset to a specific CVE history.

Default framework files frequently remain accessible. changelog.txt in WordPress exposes the exact version without authentication. composer.json in PHP applications lists dependencies with versions. package.json in Node.js applications does the same. These files are found through direct path guessing, no scanner required.

The intel.mago.team tech_detector automates the collection of these signals from a URL, without a browser extension, making the process scalable for mass enumeration pipelines. The output maps each detected signal to a stack profile that feeds the NVD query by version.

The operational chain is straightforward: disclosed version, NVD lookup by exact CPE, filter by CVSS greater than or equal to 7.0, filter by available public exploit. The asset that passes that filter is a priority test candidate before any manual analysis.

Subdomain Enumeration: The Perimeter Extends Beyond the Main Domain

Staging and development subdomains represent the most common class of forgotten assets. OWASP ASM Top 10 #7 catalogs "exposed debug and test environments" as a distinct risk because these instances exist on subdomains that never go through security review. dev-api.empresa.com, staging-admin.empresa.com, test.empresa.com: each tends to have weaker authentication, real data for environment validation, and no WAF in front.

CT logs cover historical subdomains that passive DNS databases may not have. The combination of crt.sh, SecurityTrails, and Subfinder maximizes coverage before any active contact with the target. OWASP Amass adds integration with threat intelligence APIs and pastebins to capture accidental references to internal subdomains.

Subdomain takeover is the direct risk from dangling CNAME records. A subdomain cdn.empresa.com with a CNAME pointing to a decommissioned cloud service can be claimed by an attacker who provisions the same URL on the target platform. The result is a legitimate company subdomain serving attacker-controlled content, with valid cookie scope on the parent domain. OWASP ASM Top 10 #8 documents this scenario as insecure DNS configuration.

Active brute-force enumeration over wordlists captures subdomains that never received a TLS certificate and do not appear in passive databases. Wordlists like those from SecLists cover common patterns: api, admin, dev, staging, beta, internal. The critical distinction is authorization: active enumeration sends DNS packets to the target's authoritative server and is only legal with an explicit pentest scope.

Each subdomain added to the list through this process strengthens the case for scoring before testing.

The Synthesis Layer: Scoring Findings Before Testing Them

Raw recon without scoring is output, not intelligence. The risk matrix operates on three factors: internet exposure, known CVE surface, and business criticality. Applying that matrix converts a subdomain list into an attack map with a defined test sequence.

Factor 1: Internet exposure. An asset counts as exposed when three conditions hold: it appears in CT logs or passive DNS, it resolves DNS at the time of assessment, and it has port 443 or 80 open. A historical subdomain in crt.sh with no active DNS resolution has low exposure; monitoring is worthwhile, but immediate test priority is not.

Factor 2: CVE surface. Stack fingerprinting produces a version tuple. That tuple goes to the NVD as a CPE query. The relevant filter is CVSS greater than or equal to 7.0 with a documented public exploit. EPSS (Exploit Prediction Scoring System) complements CVSS by estimating the actual probability of active exploitation within 30 days. A CVE with CVSS 9.8 and EPSS 0.02 is less urgent than one with CVSS 7.5 and EPSS 0.87.

Factor 3: Business criticality. Path analysis and form inspection identify what the asset processes. A login form indicates authentication. Credit card fields indicate a payment flow. user_id or account_id parameters in responses indicate personal data. An admin panel with HTTP Basic Auth on public exposure is maximum priority regardless of how uninteresting it appears.

Concrete example. Assess status.empresa.com discovered in CT logs. The subdomain resolves DNS; port 443 responds. The Server: nginx/1.14.0 header appears in the response. The NVD lists CVE-2019-9511 (HTTP/2 DoS, CVSS 7.5) and CVE-2019-9516 (CVSS 7.5) for that version. The /admin path returns HTTP 200 without authentication, with a visible login form. EPSS for CVE-2019-9511 is 0.94 in 30 days. Composite score: high exposure, CVE with elevated EPSS, exposed admin path. Result: immediate testing, ahead of any host in the main scope.

What gets deprioritized: historical subdomains in CT with no active DNS resolution; updated stacks with no public CVE with relevant EPSS; services with no confirmed internet exposure. The OWASP Relative Attack Surface Quotient weights attack points by access level, damage potential, and reproducibility — the result is a numerical metric comparable across assets (OWASP ASM).

Operationalizing: The Attack Surface Changes Every Day

A recon audit done today is a snapshot of yesterday's risk. TLS certificates are issued continuously. A new subdomain provisioned at 2:00 PM has its certificate in the CT log by 2:05 PM, before any human security review. Annual or monthly audit cadences cannot keep pace with that speed.

CT log streaming is the operational solution. Tools like certstream subscribe to logs from multiple CAs and deliver real-time events for monitored domains. A new certificate for *.empresa.com triggers an event; the pipeline runs fingerprinting, DNS check, and port scan automatically; the alert arrives with context before the subdomain is in full production.

Delta checking formalizes the process: for each newly discovered asset, the pipeline compares against the existing inventory, runs the full fingerprinting and CVE lookup chain, and ranks by risk score. Alerts with a configurable threshold ensure the team receives actionable context, not another raw log to interpret manually.

intel.mago.team provides continuous stack and subdomain monitoring, closing the gap between audit cycles. New assets enter the pipeline with automated fingerprinting and scoring, without requiring manual re-execution of every tool each week.

The attack surface is not a list to generate and file away. It is a living map that requires a scoring layer between raw discovery and actual testing. Built once, that layer makes any tool output immediately actionable.

JWT Security: How Misconfigured Tokens Expose Your APIs

Rxkov — Sun, 06 Sep 2026 05:56:49 +0000

JWT Security: How Misconfigured Tokens Expose Your APIs

A JWT with a forged signature. No password needed, no exploit chain, just a change to the base64-encoded header and a stolen session. Auth0 shipped this bug to production. Attackers exploited it at scale. The token looked valid. The API accepted it.

The problem is not the JWT format itself. The only real protection the token has, signature verification, can be disabled by misconfiguration. And popular libraries have made it trivially easy to get wrong.

JWTs Are Trusted by Design. That Is the Problem

A JWT has three parts: header, payload, and signature. The signature is the only security control. Without it, anyone who decodes the token sees the claims in plaintext and can modify them freely.

The design is stateless by nature. The server holds no session state and cannot revoke individual tokens without additional infrastructure. Who signed the token and when are the only verifiable facts.

Decoding a JWT is trivial. Verifying the signature requires an explicit library call. The distinction between those two operations is where most bugs live.

Historically, jsonwebtoken and jose accepted alg:none by default. An unsigned token was valid. The library decoded the payload and returned it as authenticated without verifying anything. That was not an obscure bug. It was the default behavior of libraries used in millions of applications.

The second structural problem: many languages separate decode from verify into distinct functions. Python has jwt.decode() and jwt.decode(options={"verify_signature": False}). PHP has Firebase\JWT\JWT::decode(), which accepts an array of allowed algorithms. When documentation shows incomplete examples or a developer is rushing, the verification step disappears silently. The application works. Tests pass. The vulnerability persists.

Three Misconfigurations That Break Authentication Completely

alg:none

Change the alg field in the header to none, remove the signature, and send the token. In vulnerable implementations, the server accepts it. No key required. No access to the private key. Just base64 editing.

# Decode the original header
echo "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d
# {"alg":"RS256","typ":"JWT"}

# Build a new header with alg:none
echo -n '{"alg":"none","typ":"JWT"}' | base64 | tr -d '='
# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0

# Assemble the token without a signature (trailing empty dot)
TOKEN="eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0IiwicGF5bG9hZCI6ImFkbWluIn0."
curl -H "Authorization: Bearer $TOKEN" https://api.alvo.com/admin

Auth0 had this problem in production. The variant alg:nonE (uppercase E) bypassed the simple string check that would normally block none. A case-sensitive comparison broke the entire protection.

Algorithm Confusion: RS256 to HS256

RS256 uses a private key to sign and a public key to verify. The public key is, by definition, public and frequently exposed at the application's JWKS endpoint.

HS256 uses a symmetric key. The same secret signs and verifies.

When an API configured for RS256 accepts HS256 tokens, the attacker uses the server's public key as the HMAC secret. The signature is valid because the server uses that same public key to verify. CVE-2024-54150 documents exactly this pattern in Comcast's xmidt platform, published in 2024. Not in 2010. In 2024. The vector has existed for over a decade and keeps getting introduced into production.

Weak Secrets in HS256

Hashcat in mode 16500 attacks HS256 tokens directly. A captured token with a 12-character dictionary-based secret falls in minutes on modern hardware.

hashcat -a 0 -m 16500 captured.jwt /usr/share/wordlists/rockyou.txt

Red Sentry documented that 16-character secrets are crackable in under 24 hours with current hardware. That includes secrets that look strong but follow predictable patterns like MyAppSecret2024 or jwt-secret-prod. Secrets derived from product names, dates, or any human-readable string fall into that category.

Missing Claims

A missing exp claim means the token never expires. Compromised credentials cannot be rotated. An account compromised six months ago still holds a valid token today.

A missing aud claim means a token issued for service A is accepted by service B. Lateral movement with no additional exploit. Just token reuse across microservices in the same organization.

Each of these four vectors alone enables complete authentication bypass. Production APIs frequently present more than one at the same time. The team that got alg:none wrong probably also skipped aud validation.

Not Theoretical: CVEs With Real Production Impact

CVE-2022-21449 affected Java 15, 16, 17, and 18 before the April 2022 patch. The bug was in the JVM's ECDSA implementation. A signature with r=0, s=0 passed mathematical validation. Any JWT signed with ES256, ES384, or ES512 on a vulnerable JVM was forgeable with those two values. CVSS 7.5, remotely exploitable, no authentication required. com.nimbusds.jose fixed it in version 9.22. com.auth0:java-jwt fixed it in 3.19.2. Applications running earlier versions stayed vulnerable for months after the public patch because security dependency updates are not automatic.

CVE-2018-6873 in Auth0. The aud parameter was not validated. An attacker with any Auth0 account used their own token to access any account on the platform. All they needed was the target's email address. (CVE-2018-6874, from the same API, is a distinct CSRF vulnerability — not to be confused with the audience bypass.) Complete admin takeover without knowing any victim credentials. It affected every application protected by Auth0 during that period. The impact was not limited to a bug in one specific application. It was systemic across the platform's entire customer base.

CVE-2024-54150 in Comcast's xmidt-org/cjwt. Classic algorithm confusion, the same RS256/HS256 pattern. Published in 2024, confirming that this vector keeps getting introduced into production. Comcast's code likely went through review. It likely has tests. The vulnerability existed anyway because functional tests do not detect algorithm confusion.

Red Sentry counted multiple new critical JWT-related CVEs in 2025 alone (Red Sentry, 2025), affecting cloud platforms and enterprise systems. This vulnerability class is not going away. It keeps reproducing because every new JWT implementation reinvents the same mistakes.

How to Detect Before Attackers Do

Manual testing requires base64 and curl. Nothing else.

Test alg:none:

Capture a valid JWT from any authenticated response
Decode the header: echo "<header_part>" | base64 -d
Build a new header with "alg":"none" and encode it back
Assemble the token with the original payload but without a signature (end with an empty dot)
Send it to the protected endpoint. If it accepts, the endpoint is vulnerable.

Test algorithm confusion:

Obtain the server's public key (JWKS endpoint, .well-known/jwks.json, or documentation)
Re-sign the token with HS256 using the public key as the HMAC secret
Send it to the endpoint

For automation, jwt_tool covers these vectors and more in batch mode:

python3 jwt_tool.py <token> -X a               # algorithm confusion
python3 jwt_tool.py <token> -X n               # none attack
python3 jwt_tool.py <token> -C -d wordlist.txt  # crack HS256 secret
python3 jwt_tool.py <token> -I -hc alg -hv none # manual header injection

Burp JWT Scanner detects CVE-2022-21449 passively. It intercepts tokens in responses and tests attack variants in active mode. In an API assessment, running the active scanner against every endpoint that returns a JWT takes minutes and covers known classes without manual configuration.

The kid (Key ID) field deserves separate attention. It is frequently used as a parameter in database queries without sanitization. SQLi via the kid header is a documented vector with public PoCs. Variants include JKU and X5U header injection for key substitution, where the attacker points the token at an external JWKS under their control. TrustedSec has a complete methodology covering these advanced attacks.

The jwt_scanner (intel.mago.team/spells) automates detection of those three vectors in a single scan: it crawls exposed endpoints, detects JWTs in the Authorization header and Set-Cookie, applies algorithm confusion and alg:none tests, and correlates with the CVE database to identify affected libraries by version.

JWT Is Not the Problem. Implementation Is.

JWT is not inherently insecure. The strongest argument against this analysis is that the same blind-trust vector exists in session tokens: a compromised Redis instance exposes sessions the same way a weak secret exposes tokens. Misconfiguration, not the format, is the attack surface in both cases. The difference is that JWT externalizes state. Any service that accepts the token without verifying the algorithm becomes a failure point independent of the issuer. Centralized sessions fail at one point. Poorly verified tokens fail at every service that consumes them.

Remediation: The Checklist That Closes the Surface

Four controls. All mandatory.

1. Algorithm pinning on the server

Never read the alg field from the token to decide which algorithm to use for verification. The server hardcodes the algorithm. The token has no say in that decision.

// WRONG: client dictates the algorithm
jwt.verify(token, secret)

// CORRECT: server decides
jwt.verify(token, publicKey, { algorithms: ['RS256'] })

# PyJWT
jwt.decode(token, public_key, algorithms=["RS256"])
# Never:
# jwt.decode(token, public_key, algorithms=jwt.get_unverified_header(token)["alg"])

2. Real entropy for HS256 secrets

Minimum 256 bits generated cryptographically. No passwords, phrases, or human-readable strings.

openssl rand -base64 32

Store it in a secrets manager (AWS Secrets Manager, HashiCorp Vault, or equivalent). Rotate every 90 days. Never commit it to a repository.

3. Explicit validation of all claims

jwt.verify(token, publicKey, {
  algorithms: ['RS256'],
  issuer: 'https://auth.sua-api.com',
  audience: 'https://api.sua-api.com',
  clockTolerance: 30
})

Reject tokens without exp. Reject tokens with exp in the past. Reject tokens with an aud that does not match your service. Reject tokens with an unknown iss. The library does not do this automatically. You configure it explicitly or you skip it.

4. Short lifetime and revocation for critical cases

Access token: maximum 15 minutes. Refresh token: maximum 24 hours. Both require a mandatory exp.

For security events (logout, password change, privilege de-escalation), maintain a jti (JWT ID) blocklist with TTL equal to the token lifetime. Stateless is convenient, not dogma. Redis with TTL handles selective revocation without complex architecture.

Asymmetric over symmetric in multi-service architectures

If more than one service consumes your tokens, use RS256 or ES256. The private key stays only in the issuer service. Consumer services verify with the public key. RS256/HS256 algorithm confusion is not possible in this architecture when each service hardcodes the expected algorithm.

JWT security is not a library decision. It is operational discipline. The attack surface closes when algorithm pinning, secret hygiene, and claims validation are verified continuously. The same vulnerabilities reappear in 2024 because teams do not scan what they have implemented. Scanning is the missing step between implementing and trusting.

GitHub OSINT: What Developers Expose Without Realizing It

Rxkov — Sun, 06 Sep 2026 05:56:13 +0000

GitHub OSINT: What Developers Expose Without Realizing It

In September 2022, Toyota discovered that an access key to the database of 296,019 customers had been public on GitHub since December 2017. Five years. Anyone could have used it at any point during its public existence.

Attackers collect exposed credentials on GitHub in under 5 minutes. The median remediation time for teams is 94 days. The 89-day gap between those two numbers is the window where any attacker already has what they need. Any security policy that ignores this gap is theater.

The 5-Minute Window That Invalidates Your Security Policy

Reactive controls are ineffective by design. The gap between a credential exposure and automated collection by attackers is under 5 minutes; the median remediation time for teams is 94 days.

Unit 42 (Palo Alto Networks) documented automated collection of IAM credentials in under 5 minutes after exposure on GitHub. The Verizon DBIR 2025 reported that the median time to remediate a leaked secret is 94 days. The real exposure window before any internal action is 89 days.

GitHub found 39 million leaked secrets in 2024. GitGuardian reported 28.65 million new leaks in 2025, up 34% from the previous year. These numbers describe a system where the rate of production of new attack vectors consistently outpaces detection and response capacity.

A security policy that doesn't address the gap between exposure and detection isn't a security policy. It's compliance documentation.

What You're Exposing Right Now (and Probably Don't Know)

The exposure isn't limited to carelessly committed .env files. The real surface includes complete database connection strings (DATABASE_URL, MONGO_URI), API keys for critical services (AWS, GCP, OpenAI, Stripe, Twilio) committed in configuration files, SSH private keys and TLS certificates in infrastructure repositories, and JWT secrets hardcoded to make local development easier.

The 2025 data records one rapidly growing vector: AI service credentials increased 81% from the prior year. GitGuardian detected 113,000 DeepSeek API keys exposed in a single year. Each new AI service a team adopts adds a potential credential vector with no monitoring history configured.

The most underrated vector is git history. A secret deleted in the current commit exists in every prior revision of the repository. The GitHub API exposes this history for public repositories without authentication.

Reverting a commit doesn't remove the credential from history. The exposure window starts at the moment of the first commit, not at the moment of the attempted fix. Attackers monitoring the event stream collect the credential at the time of the original push; the subsequent revert is irrelevant to them.

Internal URLs and staging endpoints in configuration files complete the surface. They reveal the internal infrastructure architecture to anyone indexing the repository, including internal services that were never designed to be publicly accessible.

How Attackers Find Your Keys in Minutes Using the GitHub API

The GitHub Search API turns the platform into a credential surveillance system accessible to anyone. Queries like filename:.env DB_PASSWORD, extension:sql mysql dump, and api_key language:python return results in seconds, without authentication.

The GitHub Events API (api.github.com/events) broadcasts a public stream of every commit made on the platform. Automated tools consume this stream and scan each diff for known credential patterns. The time between a push and detection by an external monitoring system is less than the average code review.

In October 2025, the OffSeq Threat Radar documented an active mass reconnaissance campaign. Ghost accounts abuse the GitHub API to map entire organizations using user agents that mimic legitimate tools. The requests return HTTP 200 without triggering alerts in conventional monitoring systems.

Tools like gitrob automate complete surface mapping of an organization: repositories, members, configuration files, and commit history. The combination of GitHub Search with event stream monitoring and history scanning covers the entire public surface of an organization without any credentials on the attacker's side. Exposed credentials are consumed within a window shorter than a status meeting.

Three Incidents That Cost More Than Any Monitoring Tool

Toyota, Uber, and Twitch demonstrate that exposure via public repositories isn't an anomaly: it's the default mode of operation for teams without continuous monitoring. In none of these cases was detection internal.

Toyota is the most documented case. In December 2017, a subcontractor committed a symmetric key to a customer database in a public repository. The key remained exposed for five years. In September 2022, GitGuardian detected the exposure and notified the company; Toyota had not identified the issue internally.

The Uber breach in 2022 followed the same pattern. Credentials found in a public repository were part of the attack chain that exposed data from 57 million riders and drivers. The settlement reached USD 148 million. The original commit wasn't malicious: it was a developer who considered the repository secure.

Twitch and Samsung suffered similar exposures of source code and internal credentials via public repositories. The pattern is consistent: unintentional commit, detection always external. The root cause isn't isolated human error. It's the absence of continuous monitoring that would have made the error immediately visible.

Detection Tools Exist, But Arrive Too Late When Used Only in CI/CD

Gitleaks and TruffleHog are effective, but when run only in the CI/CD pipeline, they detect exposures that are already indexed, collected, and potentially exploited.

Gitleaks uses regex patterns with TOML configuration, operates without a network connection, and runs as a pre-commit hook in milliseconds. It blocks the commit before the secret reaches the repository. TruffleHog adds entropy analysis and makes real API calls to verify whether the detected credential is still active.

The configuration that provides layered coverage combines Gitleaks at pre-commit (prevention) with TruffleHog in CI/CD (detection of secrets that passed the first layer). AWS Labs' git-secrets configures local hooks to block specific AWS service patterns before the commit. The three tools combined have over 51,000 stars on GitHub and cover the most common credential patterns in production.

The critical gap in all three: none monitors what's already public in forks, gists, or third-party code that copied the repository. GitHub Secret Scanning (Advanced Security), even when enabled for the organization, covers only the repository where it's configured. When a developer creates a public fork of a repository that contains credentials in its history, those credentials fall outside the scope of any CI/CD scanner configured on the original repository.

Continuous Monitoring Is the Only Response That Closes the 89-Day Gap

The difference between proactive and reactive detection determines whether a leaked secret becomes a contained incident or a breach requiring regulatory notification. Continuous monitoring means active scanning of GitHub search, event streams, and paste sites in real time, not a weekly scan of the main repository.

The surface to monitor includes the organization name, corporate domains, proprietary API key patterns, and corporate email addresses. Any of these identifiers can appear in third-party repositories, gists, Pastebin, or leak forums. An operationally useful alert arrives in minutes, not days.

intel.mago.team automatically monitors the exposure surface: GitHub, GitLab, paste sites, and leak forums, with alerts that allow credential rotation before the exploitation window closes. Knowing about an exposure the same day is the difference between a contained incident and a breach report that goes to the regulator.

The Checklist That Closes the Immediate Gaps

Durable remediation doesn't depend on consistent human discipline. It depends on automation that blocks the vector before the commit and on visibility into what's already outside your control.

The audit starts with the existing history: git log --all -p | grep -iE 'api_key|password|secret|token' on the current repository identifies past exposures. Every credential with suspected exposure needs to be rotated before any other action, even if the commit has already been reverted.

For history rewriting, git-filter-repo removes committed secrets permanently and replaces the deprecated git filter-branch. Installing Gitleaks as a pre-commit hook via the pre-commit framework takes two commands and blocks commits matching the configured patterns.

Environment variables in a local .env with a global .gitignore configured eliminate the most common vector for accidental exposure. GitHub Secret Scanning enabled at the organization level is free for public repositories. External continuous monitoring covers the gap that none of these internal measures can reach: what has already been copied, forked, or indexed before any remediation action.

The commit has been made. The question is: who found it before you did?