Exploit Choosing Criteria
Save time and resources with exploits that pen testers can trust
Core Impact's Exploit Library contains thousands of exploits sand is updated on an ongoing basis. But how does the team decide which exploits to work on? This page describes the evaluation criteria, including input variables and mechanisms, used to determine which vulnerabilities are good candidates to be analyzed by our Exploit Writing Team. This process enables us to develop critical, relevant exploits, adding them directly to our exploit library for immediate use by Core Impact users.
Why Choose Core Impact's Exploit Library?
- Core Impact exploits are selected using detailed selection criteria to provide access to the most serious and applicable serious exploits.
- Exploits are written and validated by experienced professionals who specialize in penetration testing to ensure that the exploits are reliable, effective, and safe to use.
- Enterprise libraries are not accessible to malicious actors. This provides a unique competitive edge, as attackers cannot purchase these exploit libraries for their own malicious purposes.
Exploit Selection Goals
Our prioritization model is based on the lens of modern-day threat actors. The main goal is to answer these questions:
- Which attacks are most important (from an attacker’s perspective)?
- Which new vulnerabilities are most likely to be used in real attacks (today and in the near future)?
- Which exploits add value to Core Impact?

Attack Prioritization Variables
The exploit choosing criteria is made up of a group of concepts that contains the following subsets:
- Vulnerability Properties: The CVE details, disclosure date, access mechanism, and privileges of a vulnerability.
- Exploitable Installed Base: The dimensions of systems that can be successfully exploited by a vulnerability.
- Value to the Product: How much value this vulnerability adds to the product from customer use case.
- Exploit Component Fit: How this vulnerability fits into the Impact exploit component--i.e., the support that Core Impact provides.
- Technical Cost/Benefit: The technical cost/benefit of creating an exploit for this vulnerability.
Vulnerability Properties
- CVE: The Common Vulnerabilities and Exposures (CVE) program features a catalog that provides definitions for publicly disclosed cybersecurity vulnerabilities and exposures. The goal of the CVE program is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services) with these definitions. CVE entries are comprised of an identification number, a description, and at least one public reference. For our purposes, the CVE date and CVSS Score are particularly useful to rate the vulnerability value.
- Disclosure Date: This is the date on which vulnerability information was made available to the public, published by a trusted source. Newer exploits tend to be more active and are therefore more valuable.
Access Mechanism and Privileges
Remote, without authentication, super user privileges
Remote, without authentication, other user privileges
The attack can be launched against a remote computer on the network, with no authentication required. A successful attack grants a non-privileged user (not a super user) on the target. (ex.: CVE 2019-3396)
Remote, with authentication, super user privileges
Local, super user privileges
Remote, with authentication, other user privileges
The attack can be launched against a remote computer on the network, but authentication is required. A successful attack grants a non-privileged user (not a super user) on the target.
Local, other user privileges
Client-Side
The attack requires a certain amount of user interaction or the execution of certain unpredictable events on the client side (usually workstation) to be successful. Typical client-side attacks grant the end user privileges inside a restricted environment, where additional exploitation is needed in order to bypass these restrictions. We also must take into account that this vector has been mitigated in a way that requires more actions than other methods. For example, OS/AV/EDR underlying mitigation mechanisms or auto patch functionality. Ultimately, the necessity of more interactions makes it the lowest variable value in this list.
Exploitable Installed Base

This vector provides the dimension of systems that can be successfully exploited by a vulnerability. To estimate the probability of target availability, we break down the target into the following categories:
Operating system share
The share of the target installed base that is running an exploitable operating system: Windows, Linux, FreeBSD, MacOSX, AIX, etc. (See also Microsoft Windows support Life Cycle)
Application prevalence
How prevalent the vulnerable application or service is in the universe of only exploitable operating systems. This variable can take one of six different values:
- Always present: The exploitable application is always present on default installation of the exploitable operating system.
- Very popular: The exploitable application is not always present, but it is a very popular application on the exploitable operating systems.
- Somewhat popular: The exploitable application is sometimes present on the exploitable operating systems.
- Not common: The exploitable application is not very common on the exploitable operating systems (ex. Sun ONE web server).
- Rarely: The exploitable application is uncommon on the exploitable operating systems (ex. Veritas Backup Exec).
- Almost never: The exploitable application is nearly non-existent on the exploitable operating systems (ex.: Pepe FTP).
Application configuration
Whether the application requires a certain configuration setting to be exploited. This variable can take one of two values:
- Default application install: A default install of the application can be exploited.
- Needs special configuration: An exploitable application needs a certain non-default configuration setting to be activated to be exploited.
Application version
This variable can take one of two values:
- Specific version: The last or a specific version before the patched one is vulnerable.
- Series of versions: Several versions older than a specific one are vulnerable.
Need of event not controlled by the attacker
- Needs special event: Needs a special event not controlled by the attacker to be exploitable.
- No special event: Does not require a special event to be exploited.
Value to the Product
Independently of the other variables, the value of having an exploit for a certain vulnerability (or a set of vulnerabilities), can be weighted by business necessities where, for instance, a customer (or potential customer) requests a very specific exploit. The prioritization of this request should also be contrasted with the analysis of the other variables.
Another factor to consider is the support that Core Impact currently has for the platform that is being targeted by the vulnerability (or the set of vulnerabilities). Targeting unsupported platforms might lead to additional technical cost and maintenance.
Additionally, there might be cases where an exploit is not technically able to achieve code execution in order to install an IMPACT agent. In such cases, a Vulnerability Checker or information leak module can be developed as an alternative (e.g.: bluekeep, conficker, heartbeat, meltdown/spectre, etc.).
We do not release zero-day exploits (recent, still unpatched vulnerabilities) unless there is public information to develop the exploit, such as public blogposts, published advisories, or PoCs.
How a Vulnerability Fits into the Exploit Component
How an exploit is implemented is also taken into account. For Core Impact, we focus mostly on code execution to deploy a Core Impact Agent and take control of the vulnerable target.
We should note that there are some border cases:
- For vulnerabilities that allow code execution which are present in libraries or frameworks, we can leverage this kind of case only through the front-end application (consumer of the library). It is not possible to build a generic exploit for libraries, it must target an application.
- Vulnerabilities that allow to bypass protection mechanisms are not candidates to develop an exploit, ( e.g.: CVE-2020-0601 ). However, it’s possible they could be part of a chaining of vulnerabilities exploitation in order to achieve code execution.
Technical Cost/Benefit
The technical cost of the necessary invested effort required to build an exploit is also evaluated using the following considerations:
- Time required to research a vulnerable scenario based on:
- Analysis of the public information related to the vulnerability (or vulnerabilities)
- Reproduction of the vulnerability exploitation by performing:
- Deployment of the vulnerable scenario
- Reverse engineering
- Black box fuzzing
- Static patch analysis
- Dynamic analysis
- Deployment of the vulnerable scenario
- Analysis of the public information related to the vulnerability (or vulnerabilities)
- Code and QA required to integrate it into the product
If these steps were successful, a new exploit can be packed and shipped to customers.
In analyzing a vulnerability, we expect the following possible outputs:
- The exploit to be shipped to customers
- The increase in team knowledge/expertise after the research process. This may subsequently lead to:
- Internal knowledge transfer
- Internal research topics documented for further analysis
- External documentation/publications, as blog posts, papers, advisories, etc.
- Internal knowledge transfer
External Information/Indexes
External information is valuable when prioritizing vulnerabilities. This information should be analyzed, while also factoring in “where and how” this information has been consolidated.
- Advisories and security bulletins
- Vendor patch publications, such as Microsoft Patch Tuesday
- Publications from government or government-sponsored security agencies in the US, as Mitre, CISA, etc.
- Blogposts from security companies: ZDI, bleepingcomputer, seclists.org/fulldisclosure, etc.
- Social networks and independent researchers from Twitter (X), Telegram, lists, etc.
Backlog Triage
As time passes, the value of exploits can decrease. On the other hand, public information could become more detailed and, using our own research, we can better evaluate the vulnerability candidates. This could lead to reprioritizing backlogs in recurrent meetings.
Exploit Choosing Criteria Workflow
