How to Explore Vulnerabilities

Google Threat Intelligence helps you prioritize patching and mitigation efforts by providing empirical risk scoring, highly contextualized correlations to other indicators of compromise (IOCs, or simply "indicators"), and continuously updated reporting for Vulnerabilities.

Explore Vulnerabilities

1. To explore Vulnerabilities, click Vulnerability Intelligence.

2. The dashboard displays the Vulnerabilities List: A filterable and sortable list of over 100K Vulnerabilities being tracked by Google Threat Intelligence.

   

3. See the Vulnerability Summary of a vulnerability on the results list.

4. Click on the name of a vulnerability to explore the complete Vulnerability profile across several tabs as detailed in the following bullets.

ℹ️

Any aliases for the Vulnerability are listed beneath its CVE ID, including its MVE ID. MVEs are Google Threat Intelligence's unique IDs for Vulnerabilities, similar to CVEs (Common Vulnerabilities and Exposures).

• Summary: Displays information like an executive summary, description, details of the vulnerability and more information if available. It also adds contextual visualizations.

  • Details: Provides some information related to if the vulnerability affects cloud, if it requires media attention, if it is discovered by Google TI, mitigation information and exploitation information.

    • Exploitation:
      • Exploitation availability: Indicates our knowledge of the current availability, interest, or development of code capable of exploiting a vulnerability.
        • No known: No exploit code is available. No claims of privately held exploits or proof-of-concepts (PoC). No walkthroughs exist with enough details to produce an exploit.
        • Interest Observed: No exploit code is available. No claims of privately held exploits or PoCs. Threat actors have been observed asking about or requesting exploits. Researchers have been observed attempting to write an exploit/PoC.
        • Unverified: An exploit sample is alleged to exist in the wild. However, Google TI has not evaluated this exploit to verify its legitimacy or functionality.
        • Privately Held: Credible reports of researchers possessing a PoC/exploit exist. Exploitation has been observed but the code for the exploit is not available.
        • Publicly Available: Exploit or PoC code exists and is (or was) available in the open.
        • Trivial: Exploitation of this vulnerability does not require specialized code.

  • Vulnerable Products: This graph displays the products affected by the Vulnerability, broken down by percentage of total products. The details of the products can be found on the Product and fixes tab

    ℹ️

    For Vulnerabilities with a high number of affected products, not all vulnerable products may be included in the display.

  

  • CVSS Score:
    • CVSS v3.1 Base: This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time and across user environments.
    • CVSS v3.1 Temporal: This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time but not across user environments.
    • CVSS v2.0 Base: This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time and across user environments.
    • CVSS v2.0 Temporal: This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time but not across user environments.

• IoCs: Provides information related to IoCs, commonalities, telemetry and exploits related to the vulnerability across several tabs:

  • IoCs: Displays a sortable and filterable table of all affected IoCs broken down by IoC Type.
  • Commonalities: Displays the Commonalities of the vulnerability broken down by IoC Type.
  • Telemetry: Provides information about the lookups and submissions.
  • Exploits: Lists code samples and metasploit modules that can be used for proof-of-concept (PoC) testing of this Vulnerability in your environment. These are broken down by Vendor (with links to code samples), the associated Hashes, Exploit Reliability, Exploit Grade, File Size, and Release Date.
    • Exploit Reliability: The degree of analysis performed by Google Threat Intelligence.
      • Unreviewed: The exploit has not been reviewed for legitimacy by an analyst.
      • Reviewed: Analysts have reviewed the exploit code, but have not tested it.
      • Tested: Analysts have tested the code to confirm functionality.
    • Exploit Grade: The state in which the code exists and its current capability.
      • Unevaluated: The exploit has not been evaluated by an analyst. This is used when an exploit is ingested through automation and is the only grade automation can assign.
      • Proof-of-Concept: This code is intended to demonstrate that exploitation of the Vulnerability is possible and can potentially deploy a non-payload. Non-payload examples include opening the calculator or a raw request that can trigger the Vulnerability without any consequences. The entry has limited or no functionality in its current state, and further development must be made for exploitation to occur.
      • Non-Weaponized: The code can perform exploitation; however, it does not come weaponized by default. It can exploit the Vulnerability; however, an external payload (which is not part of the code) must be specified to carry out the malicious actions. This may also pertain to exploit code with no predefined code or command to execute upon exploitation, but contains all of the logic required to execute the code or command when the user defines them.
      • Weaponized: This code contains a malicious payload or specific code or command to perform malicious actions against a vulnerable system. Examples include overwriting or reading a critical file, spawning a reverse shell, deploying known malware, or causing a Denial-of-Service (DoS) condition. The code can typically be used as-is and does not require further development to perform malicious actions.
      • Scanner: A scanner does not deploy any malicious payloads against a target. Instead, it determines whether the target is exposed to a given Vulnerability and reports this back to an operator. While some scanners do execute a payload (such as running the whoami command), execution of the payload is not the goal but rather to determine if the system is vulnerable.
      • Fake: The code is intentionally fake or misleading. This can be done by researchers attempting to determine which vendors are reporting on unanalyzed exploit code, or by malicious actors attempting to distract researchers. There is no legitimate functionality, and the code may not even pertain to the Vulnerability in question.

• Products and Fixes: Provides information related to the vulnerable products and the vendor fixes.

  • Vulnerable products: Displays a table of all affected products broken down by Vendor, Product, and Version.

  ℹ️

  Vulnerable products are described using Common Platform Enumeration (CPE) format, so changes to these records appear in the History tab as CPE updates.

  • Vendor Fix Details: Provides a sortable table of all vendor fixes broken down by Name (with links to patch packages), Source ID, and Date of Patch.

  • Exploits: Lists code samples and metasploit modules that can be used for proof-of-concept (PoC) testing of this Vulnerability in your environment. These are broken down by Exploit Name, Exploit Reliability, Exploit Grade, Size, and Release Date.

    • Exploit Reliability: The degree of analysis performed by Google Threat Intelligence.
      • Unreviewed: The exploit has not been reviewed for legitimacy by an analyst.
      • Reviewed: Analysts have reviewed the exploit code, but have not tested it.
      • Tested: Analysts have tested the code to confirm functionality.
    • Exploit Grade: The state in which the code exists and its current capability.
      • Unevaluated: The exploit has not been evaluated by an analyst. This is used when an exploit is ingested through automation and is the only grade automation can assign.
      • Proof-of-Concept: This code is intended to demonstrate that exploitation of the Vulnerability is possible and can potentially deploy a non-payload. Non-payload examples include opening the calculator or a raw request that can trigger the Vulnerability without any consequences. The entry has limited or no functionality in its current state, and further development must be made for exploitation to occur.
      • Non-Weaponized: The code can perform exploitation; however, it does not come weaponized by default. It can exploit the Vulnerability; however, an external payload (which is not part of the code) must be specified to carry out the malicious actions. This may also pertain to exploit code with no predefined code or command to execute upon exploitation, but contains all of the logic required to execute the code or command when the user defines them.
      • Weaponized: This code contains a malicious payload or specific code or command to perform malicious actions against a vulnerable system. Examples include overwriting or reading a critical file, spawning a reverse shell, deploying known malware, or causing a Denial-of-Service (DoS) condition. The code can typically be used as-is and does not require further development to perform malicious actions.
      • Scanner: A scanner does not deploy any malicious payloads against a target. Instead, it determines whether the target is exposed to a given Vulnerability and reports this back to an operator. While some scanners do execute a payload (such as running the whoami command), execution of the payload is not the goal but rather to determine if the system is vulnerable.
      • Fake: The code is intentionally fake or misleading. This can be done by researchers attempting to determine which vendors are reporting on unanalyzed exploit code, or by malicious actors attempting to distract researchers. There is no legitimate functionality, and the code may not even pertain to the Vulnerability in question.

• Sources: Provides links to external sources for additional Vulnerability advisories and reports, broken down by Source Title, Source ID, Source Name, and Publish Date.

• History: Lists Version Notes and associated Dates for updates to this Vulnerability record by Google Threat Intelligence.

• Reporting: The latest reports generated by Google Threat Intelligence that are related to or explicitly mention the selected Vulnerability.

• Rules: Lists Version Notes and associated Dates for updates to this Vulnerability record by Google Threat Intelligence.

• TTPs: A filterable visualization with the Mitre Att&ck of the related vulnerability, breaking down into types.

• Community: Displays the community comments related to this vulnerability.

Filtering Vulnerabilities

1. Go to Vulnerability Intelligence.

2. In the Filters pane, select the desired filters based on the following options:

• Creation Date: Date when information on the Vulnerability was created.
• Last Modification Date: Date when Google Threat Intelligence last published updates regarding the Vulnerability.
• Risk Rating
  • Critical: Exploitation of these Vulnerabilities fundamentally undermines the security of affected devices and networks. These vulnerabilities enable actors to perform significant attacks with minimal effort, impacting a wide number of systems, often with little to no mitigating factors to overcome. Reliability of exploitation is most likely very high and can almost certainly be performed effectively at scale.
  • High: Exploitation of these Vulnerabilities would enable attackers to have a notable, direct impact to the security of targeted devices and networks without needing to overcome any major mitigating factors. Reliability of exploitation is expected to be high and can typically be done on a wide scale.
  • Medium: Exploitation of these Vulnerabilities would either enable attackers to perform additional activities on the targeted device or network, or could allow attackers to have a direct impact on the security of the targeted device or network. These Vulnerabilities would require notable additional factors to be performed or mitigated. Reliability of exploitation is likely questionable and may or may not be able to be performed on a wide scale.
  • Low: Exploitation of these Vulnerabilities would have little to no security impact on targeted systems. This means that while technically a Vulnerability, there is little to no direct security impact an attacker can have on the targeted system or network. Reliability of exploitation is likely low and unlikely to be performed on a wide scale.
  • Unrated: Some Vulnerabilities do not have a Google Threat Intelligence risk rating but do have the other Vulnerability intelligence context included. This is usually because there is insufficient information to determine the risk rating, or it's still being analyzed.
• Exploitation State: Google Threat Intelligence's Exploitation State indicates our knowledge of the current exploitation landscape, and whether a vulnerability is known or suspected to be exploited.
  • Wide: Exploitation of this vulnerability is occurring on a wide scale.
  • Confirmed: Google TI has observed exploitation of this vulnerability or has observed credible reporting that indicates that vulnerability is being actively exploited.
  • No Known: Google TI is unaware of reports of exploitation of this vulnerability. Google TI has not observed exploitation of this vulnerability.
  • Suspected: Exploitation of this vulnerability has not been confirmed or reported, but we are aware of evidence that indicates explotiation may have occured or be occuring in the wild.
  • Reported: Reports of this vulnerability being exploited exist, although Google TI has yet to confirm the exploitation.
• Vulnerability Filters
  • CISA Exploited: The Vulnerability appears in the Known Exploited Vulnerabilities Catalog of the Cybersecurity & Infrastructure Security Agency (CISA).
  • Zero-Day: The Vulnerability was known to be exploited prior to a patch being made available.
  • Observed In The Wild: Google Threat Intelligence has either observed malicious exploitation of a Vulnerability or has received information regarding confirmed exploitation from a reliable or confirmed source.
  • Affects Operational Technologies: The Vulnerability is known to affect operational technology (OT) and/or industrial control systems (ICS).
  • Affects Cloud: The Vulnerability is known to affects cloud services.
  • Requires User Interaction: The Vulnerability can only be exploited with the direct interaction from a potential target.
• Exploitation Consequences
  • Code Execution: Malicious code is injected and executed by the targeted application.
  • Command Execution: Malicious commands are executed by the host operating system, typically using the privileges of the target application.
  • Data Loss: Data is exfiltrated or wiped from the target system.
  • Data Manipulation: Data is inserted, deleted, or altered to hide activities, influence outcomes, or disrupt operations.
  • Denial-Of-Service (DoS): A machine, service, or network is temporarily or permanently rendered unavailable to intended users, typically by flooding it with traffic.
  • Information Disclosure: A system fails to protect sensitive and confidential information from exposure.
  • Privilege Escalation: A Vulnerability is exploited to enable elevated privileges to access resources that would otherwise be protected.
  • Security Bypass: The authentication or other security mechanisms of a device or system are circumvented to enable unauthorized access.
• Exploitation Vectors
  • Email: An attacker could exploit the Vulnerability using a maliciously crafted email.
  • File Share: A malicious, specially crafted file in a file share could be used to exploit the Vulnerability.
  • General Network Connectivity: Exploitation can be conducted over remote access over a computer network with a vulnerable system.
  • Local Access: Exploitation requires direct login access or command shell access to the target system.
  • Local Network Access: Attackers could exploit the Vulnerability on another system if they are on the same local network.
  • Open Port: Exploitation can occur over exposed ports, whether due to misconfigurations or poor security practices.
  • Physical Access: Direct, physical access to a vulnerable system is required to exploit the Vulnerability.
  • Web: Exploitation can occur by a user visiting malicious or compromised websites.
• Available Mitigations
  • Anti-Virus Signatures: Anti-virus signatures capable of detecting exploitation attempts exist.
  • Firewall: Specific firewall rules can be used to prevent exploitation attempts.
  • Intrusion Prevention Signatures:  Intrusion prevention signatures exist capable of preventing exploitation attempts.
  • Patch: Vendor fixes exist that mitigate the Vulnerability.
  • Mitigated by vendor: A solution was provided by vendor.
  • Workaround: A solution exists that can mitigate some exploitation attempts, but is not intended to be a full or permanent fix.
• CVSS 3.X Base Score: Filter based on a range of CVSS 3.1 Base Score metrics.
• CVSS 3.X Temporal Score: Filter based on a range of CVSS 3.1 Temporal Score metrics.
• CVSS 2.X Base Score: Filter based on a range of CVSS 2.0 Base Score metrics.
• CVSS 2.X Temporal Score: Filter based on a range of CVSS 2.0 Temporal Score metrics.

Vulnerabilities Overview

The following video provides a quick overview of navigating the Vulnerabilities web interface:

Vulnerabilities Deep Dive

The following recording from one of our Principal Architects provides a deep dive into getting the most from Google TI's Vulnerability intelligence: