Exploit Choosing Criteria | Core Impact

Exploit Choosing Criteria

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.

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?
Vulnerability priority diagram

Attack Prioritization Variables


The exploit choosing criteria is made up of a group of concepts that contains the following subsets:

  1. Vulnerability Properties: The CVE details, disclosure date, access mechanism, and privileges of a vulnerability.

  2. Exploitable Installed Base: The dimensions of systems that can be successfully exploited by a vulnerability.

  3. Value to the Product: How much value this vulnerability adds to the product from customer use case.

  4. Exploit Component Fit: How this vulnerability fits into the Impact exploit component--i.e., the support that Core Impact provides.

  5. 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

The attack can be performed against a remote computer on the network, with no authentication required. A successful attack grants super user privileges on the target. (ex.: MS17-010/eternal blue)

Exploitable Installed Base

exploitable base
Exploitable Installed Base = Operating system share x Application prevalenceApplication versionApplication configuration 

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)

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

  • 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.

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.

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

exploit choosing criteria workflow

Explore the Core Exploit Library

CTA Text
Search our continuously growing library to discover an exploit that will allow you to gain and retain access on the target host or application.
Explore the Library