Exploit Choosing Criteria

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

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)

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

The attack can be launched against a remote computer on the network, but authentication is required. A successful attack grants super user privileges on the target. (ex.: MS17-010/Eternal Romance)

Local, super user privileges

The attack requires a certain (not highly privileged) level of access to the target computer. A successful attack grants super user privileges on the target.

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

The attack requires a certain (not highly privileged) level of access to the target computer. A successful attack grants the privileges of a more privileged user (more privileged than the original privilege level) but not super 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

exploitable base — **Exploitable Installed Base =** *Operating system share* x *Application prevalence* x *Application version* x *Application 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)

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

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.