ADINT Stack Hypothesis
Use official careers pages and public ATS feeds to map the backend, platform, data, identity, mobile, cloud, and delivery technologies a target is hiring for, then turn those clues into dated stack hypotheses that must survive a live in-scope discriminator.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
Choose the evidence path that fits the boundary.
No lane is automatically stronger. Pick the least intrusive path that can distinguish the hypothesis, then confirm through an independent method before reporting.
Passive source merge
The asset graph is incomplete or stale.Combine certificate transparency, passive DNS or approved APIs, archives, public repositories, and first-party documentation into an append-only source ledger.
- Tradeoff
- Low target traffic, but historical names, shared infrastructure, and vendor data are candidates rather than current scope.
- Advance when
- Every candidate retains source and time, then survives live brief, ownership, DNS, and wildcard checks.
Low-rate active confirmation
The live program permits resolution or probing of already approved candidates.Resolve explicit DNS record types, then probe the current DNS view at a bounded rate for TLS and HTTP state with known wildcard controls.
- Tradeoff
- Establishes current behavior, but sends traffic and can misclassify shared edges or transient failures.
- Advance when
- A second resolver or repeat observation supports the state and the asset remains in scope.
Source assisted
Public docs, client code, contracts, archives, or authorized local source can narrow the test.Extract operation names, routes, fields, versions, and trust decisions without executing untrusted artifacts, then test only the supported live hypothesis.
- Tradeoff
- Low traffic and high context, but sources can be stale, client-only, generic, or unrelated to the deployed product area.
- Advance when
- A current in-scope response or operation corroborates the source claim.
Independent replay
A candidate survives its first control and is nearing report status.Repeat the smallest claim in a fresh session, browser profile, account pair, token set, or second tool while keeping the security-sensitive variable constant.
- Tradeoff
- Costs another clean setup, but catches cache, session, extension, proxy, and operator confounders.
- Advance when
- Fresh evidence supports the same primitive without relying on the first tool's interpretation.
Define the claim before collecting
Choose one question tied to the approved product, such as which backend language, API style, identity provider, cloud, database, queue, framework, build system, or observability stack may affect it. Set a source date window and avoid collecting applicant fields, names, contact details, or unrelated employee information.
printf 'observed_at source_type source_url claim product_area confidence contradiction next_check
' > recon/adint-ledger.tsvFind the official careers and ATS sources
Start from the target's own careers page and follow only the job-board links it publishes. When the board uses Greenhouse, Lever, or Ashby, prefer that provider's documented public GET endpoint over brittle HTML scraping. Record the company board token from the official link instead of guessing tokens or enumerating other tenants. Never call application-submission endpoints.
# Pick only the provider and board token observed on the official careers page
curl -fsSL 'https://boards-api.greenhouse.io/v1/boards/BOARD/jobs?content=true'
curl -fsSL 'https://api.lever.co/v0/postings/SITE?mode=json'
curl -fsSL 'https://api.ashbyhq.com/posting-api/job-board/BOARD'Build a role-to-stack evidence matrix
Prioritize backend, platform, SRE, infrastructure, data, identity, mobile, developer-experience, release, and security engineering roles. Extract technology plus sentence context, role family, team, product or business unit, location, posting URL, observed date, updated date when supplied, and lifecycle verb. Useful lifecycle verbs include build, operate, maintain, migrate, replace, deprecate, standardize, and modernize.
printf 'observed_at\tupdated_at\trole_family\tteam\tproduct_area\ttechnology\tlifecycle\trequirement\tsource_url\tconfidence\n' > recon/careers-stack-matrix.tsvSeparate hiring wish lists from deployed facts
Label every mention as required, preferred, current operation, migration target, legacy maintenance, vendor integration, or generic experience. 'Operate Kafka in production' is stronger than 'Kafka experience is a plus.' A recruiter template, evergreen role, acquired-company posting, corporate IT role, consulting role, or vendor case study can be stale or unrelated to the bounty asset.
Attribute the clue to a product boundary
Do not flatten the whole company into one stack. Separate customer product, internal corporate IT, data platform, mobile, regional deployment, acquired product, and central infrastructure. Keep team and business-unit wording when public, but collect no employee identities. Promote a clue only when the role can plausibly touch an in-scope product family.
Corroborate across independent public sources
Raise confidence only when a second source supports the same product area and time window. Public repository releases, OpenAPI documents, package metadata, status components, current client artifacts, response behavior, and dated engineering material are stronger corroborators than duplicated job-board copies. Multiple openings copied from one template are one source, not independent confirmation.
Translate the stack claim into a control boundary
Map each supported hiring clue to a likely boundary. Examples include React or mobile client to GraphQL gateway, OAuth client to issuer, Kubernetes ingress to service mesh, producer to Kafka consumer, upload service to media parser, ORM to database authorization layer, CI runner to artifact registry, or cache key to origin response. The role tells you where to look, not what vulnerability exists.
Run the cheapest live discriminator
Use current in-scope responses, headers, script metadata, source maps, public API schemas, OIDC discovery, documented endpoints, error shapes, or a single safe request to support or reject the hypothesis. Do not scan for a technology solely because a job advertisement mentioned it, and do not turn a careers clue into a technology-specific payload queue until reachability is supported.
httpx -l in-scope-urls.txt -json -silent -rl 5 -sc -title -tech-detect -server -o recon/adint-live-evidence.jsonlRecord contradictions and decay
A useful ledger keeps contradictory evidence, first seen, last reviewed, current confidence, and the next review trigger. Downgrade claims when the source disappears, the product changes, or live evidence points elsewhere.
Common guidance
- Careers ADINT is architecture hypothesis generation. It does not establish ownership, scope, liveness, deployment, or vulnerability.
- Hiring language can reveal migrations and mixed generations. Phrases such as replace, modernize, consolidate, and maintain often matter more than a flat list of technologies.
- Count independent sources, not repeated postings or job-board mirrors.
- Technology transitions are often more valuable than static stack labels because mixed generations create inconsistent controls.
- Status-page component names and deprecation notices can reveal product boundaries without probing hidden infrastructure.
- Do not contact employees, scrape personal profiles, or turn the method into social engineering.
Mapped workflow tools
References
- https://developer.greenhouse.io/job-board.html ↗
- https://github.com/lever/postings-api ↗
- https://developers.ashbyhq.com/docs/public-job-posting-api ↗
- https://docs.github.com/en/rest/repos ↗
- https://spec.openapis.org/oas/v3.1.1.html ↗
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/10-Map_Application_Architecture/ ↗
Version history: normalized permanent page created 2026-08-20.