A security dashboard might show 10,000 open findings. The challenge is determining which of them could help an attacker reach customer data, interrupt operations, or take control of a critical service.
ThreatWell's approach starts by examining what attackers can learn about a company from its public digital footprint, then using that information to guide security testing. The aim is to reduce repetitive investigation and give security and engineering teams a clearer basis for deciding what to fix first.
When a serious finding remains open, security reviews should establish what protects the affected system while a permanent fix is underway. Depending on the weakness, interim measures might include restricting access, disabling an affected feature, or isolating the system. Teams should check whether those measures block the identified attack path, assign an owner and deadline for the permanent fix, and repeat the relevant security test after remediation.
Start With What an Attacker Can Discover
Open-source intelligence, or OSINT, turns publicly available information into useful insight about an organization. During reconnaissance, attackers connect clues about its people, technology, and infrastructure to identify potential ways in. That investigation may begin with public records and progress to direct interaction with systems, but identifying a possible entry point does not by itself prove that it can be exploited. [1]
An attacker may connect domains, certificates, public repositories, business relationships, and technology clues into a fuller picture of the company. Together, these observations suggest where valuable systems might be exposed. Public records can be outdated, however: an old record may identify a server the company no longer operates. Analysts should confirm that the system still belongs to the organization and remains in use before treating it as a current exposure. [1]
Build a Dossier That Preserves the Evidence
For a defensive assessment, the dossier should be a maintained record of observations and unanswered questions, organized around business services and the agreed scope. Analysts record candidate assets and relationships alongside the original source and collection date, distinguishing confirmed ownership from inferred associations.
Each entry should explain what is known, why it matters, and what needs verification. Historical records may point to retired assets. Shared hosting can make unrelated companies appear connected. A useful dossier makes those uncertainties visible before they become testing targets or executive claims.
Begin Passively and Validate Deliberately
Passive reconnaissance uses existing information without directly probing the target infrastructure. Examples include certificate transparency records, historical DNS datasets, and existing third-party observations. Reading a live company website still generates requests to that site, while active scanning directly probes the infrastructure. The distinction depends on what an activity does, not simply how quiet it appears. [1]
This distinction gives defenders a practical sequence: collect available evidence, confirm asset ownership and scope, assess the most relevant leads, and validate selected attack hypotheses. Passive research is a sensible starting point, although real adversaries do not all follow the same sequence.
Before active testing, the assessment team and system owners agree on targets, permitted techniques, operating windows, and stop conditions. Active assessment checks whether suspected conditions are present; exploitation validation tests whether a weakness can produce the specified result under those conditions. Results should distinguish prevention, detection, and alerting, because an alert does not mean access was prevented.
An unsuccessful attempt may reflect a protective control, an unsuitable technique, missing prerequisites, or an incomplete test. The report should explain what was attempted and observed so that an unproven finding is not mistaken for a safe system. Urgent mitigation should not depend on obtaining exploit proof.
AI Can Accelerate the Work Around an Attack
In May 2025, the UK National Cyber Security Centre (NCSC) assessed that threat actors were almost certainly already using AI to enhance reconnaissance, vulnerability research, exploit development, and other established techniques. Its outlook to 2027 anticipated further improvements to existing cyber intrusion methods. [2]
For defenders, large language models can assist with organizing observations, comparing records, and drafting explanations for analyst reviews. Automating these recurring tasks may leave more time for investigation and validation. The benefit depends on source quality, tool coverage, and how much correction the outputs require.
When an authorized test window opens, agents can be assigned bounded tasks against the prepared scope. Their recommendations should link back to the evidence supporting them, and their actions should remain observable. An AI-generated explanation remains a hypothesis until evidence supports it.
The business case should account for analyst hours, data subscriptions, model and infrastructure costs, review effort, and retesting. Comparing the time needed to produce a reviewed dossier and verify remediation against a similar manual assessment gives teams a basis for measuring improvement. Generating findings faster alone does not establish a cheaper or more effective assessment.
Turn a Large Backlog Into Defensible Priorities
An illustrative backlog of 10,000 findings may contain repeated instances of the same vulnerability across many assets. Important exposures can also involve permissions or configurations without any Common Vulnerabilities and Exposures (CVE) identifier. The count alone therefore says little about which actions would reduce the most risk.
A Common Vulnerability Scoring System (CVSS) Base score describes technical severity, but it does not establish the risk to a particular organization. Prioritization also requires information about the affected system, how an attacker could reach it, existing protections, and the potential business impact. [3]
The Known Exploited Vulnerabilities (KEV) catalog identifies vulnerabilities with evidence of exploitation in the wild. The Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the wild over the next 30 days. Neither establishes that a specific company is exploitable, and absence from KEV or a low EPSS score should not be interpreted as proof of safety. [4, 5]
A defensible priority answers five questions, each with evidence:
Teams can use this evidence to produce a short action list, such as the ten highest-priority remediation decisions. Ten is a communication choice, not a limit on urgent work. The remaining backlog still needs accountable owners, reasons for deferral, and reassessment when access, threats, or controls change.
In an illustrative scenario, a reachable administration service affecting a critical business process might take priority over a higher-severity finding on an isolated test host. Analysts need to confirm those conditions before assigning the order: the isolated host could still matter if another access path or dependency makes it reachable.
How ThreatWell Supports the Attacker Perspective
The ThreatWell platform brings together source-side analysis and testing of running systems. Codex focuses on source code and dependency analysis, while Command handles reconnaissance, assessment, exploitation, and reporting against live targets. [6]
Command's published capabilities include intelligence correlation, priority scoring, campaign scope and timeline tracking, and relationships among domains, IP addresses, and certificates. These capabilities support assembling an outside view and selecting targets for further assessment. Coverage depends on the deployment and the scope of testing. [6]
The workflow proposed here is to use that intelligence as the starting point for investigation, then carry confirmed evidence into remediation decisions. A target worth investigating first is not automatically the vulnerability that engineering should fix first. The latter decision also needs validation results, business context, ownership, and the effect of the proposed change.
A useful demonstration follows one approved business service from public observations through a scoped test and into a remediation decision. The evidence should explain the priority, establish what the test showed, and record whether the fix passed retesting. This gives teams a concrete way to evaluate the workflow.
Keep This Workflow Inside the CTEM Program
Continuous Threat Exposure Management (CTEM) connects ongoing assessment of accessibility, exposure, and exploitability to business priorities. OSINT contributes to an external perspective, while a broader assessment considers internal identities, systems, and business dependencies that public research cannot reveal. [7]
CTEM connects five recurring stages: scoping, discovery, prioritization, validation, and mobilization. The process begins by identifying the business services and assets that matter most, then discovering their exposures. Teams prioritize those exposures using threat evidence and business context, while validation tests the assumptions behind those decisions. Mobilization turns the findings into assigned remediation work, with retesting and changes in the environment informing the next cycle. ADCL's CTEM 101 explainer describes each stage in plain language. [8]
Security teams already use adversary emulation, penetration testing, and threat-informed analysis. The operational challenge is making that perspective repeatable and accessible to the teams making daily decisions. ThreatWell's role should be judged by the quality of evidence it contributes and the actions that evidence enables.
Ask for Evidence of the Exposures That Matter
Security reviews should establish which routes to critical services remain plausible, which have been tested, and what action would interrupt them. Each action needs an owner and a plan for checking its effectiveness. Unknown and untested areas should remain visible alongside confirmed results.
See your company through the eyes of an attacker, then give defenders the evidence and ownership needed to act. Start a conversation with the ThreatWell team about demonstrating that workflow against an agreed scope.
Public Sources
Numbered citations correspond to the sources below. ADCL product descriptions are first-party statements; they do not constitute independent performance validation.
- MITRE. MITRE ATT&CK: Reconnaissance (TA0043). Supports passive and active reconnaissance, organizational intelligence, and the distinction between existing information and direct probing.
- NCSC. Impact of AI on cyber threat from now to 2027. May 7, 2025. Supports the assessment of AI assisting existing attacker techniques. Forecasts are attributed and are not ADCL results.
- FIRST. CVSS v4.0 User Guide. Supports the distinction between Base severity and risk assessment.
- CISA. Known Exploited Vulnerabilities Catalog. Supports known exploitation as a prioritization input.
- FIRST. Exploit Prediction Scoring System. Defines the 30-day probability of exploitation in the wild; it does not estimate compromise of a particular organization.
- ADCL. ThreatWell platform. Supports the public descriptions of Codex, Command, recon intelligence, and priority scoring. Numerical marketing claims were not adopted.
- Gartner. Gartner Identifies the Top 10 Strategic Technology Trends for 2024. October 16, 2023. The CTEM section supports continual exposure assessment and business alignment.
- ADCL Research. CTEM 101: Reducing Security Exposure. October 14, 2026. First-party related reading on the five CTEM stages; supports the five-stage terminology used in this article.