Vulnerability report details

Navigating a Vulnerability Report in Google Threat Intelligence: A Deep Dive

At Google Threat Intelligence, our mission is to provide security professionals with the timely, accurate, and contextualized intelligence they need to protect their organizations. A core component of our platform is the in-depth vulnerability report. These reports go beyond a simple CVE score, aggregating vast amounts of data into a single, actionable view.

To help you get the most out of our platform, this article will walk you through each section of a vulnerability report, using the report for CVE-2010-3765 as our guide.

Summary header

Every vulnerability report begins with a high-level summary header, designed to give you the most critical information in seconds.

• Vulnerability Identifier: The report is centered around a specific vulnerability, in this case, CVE-2010-3765. We also include the creation and last updated dates for the report itself.
• Key Attributes Bar: This is your first stop for prioritization.
  • Risk Rating: Our internal assessment of the vulnerability's overall risk. High indicates a significant threat.
  • Exploit Availability: Shows if exploit code is available to attackers. Publicly Available means the barrier to entry for exploitation is low.
  • Exploitation State: Confirms whether we have evidence of this vulnerability being successfully exploited. Confirmed is a strong signal to take action.
  • Exploited As Zero Day: Indicates if the vulnerability was exploited before a patch was available.
  • Exploited in the Wild: The most critical indicator. Yes confirms active, real-world attacks are leveraging this vulnerability.
• Actions: A set of tools to Follow, Share, Download IOCs, visualize relationships in the Graph, or Add your own IOCs.

The Main Tabs: A Section-by-Section Breakdown

The report is organized into logical tabs, allowing you to pivot based on your specific needs, whether you're a SOC analyst, threat hunter, or part of a vulnerability management team.

1. Summary Tab

This is the narrative and dashboard view of the vulnerability.

• Summary & Analysis: A human-readable abstract written by our analysts. It explains what the vulnerability is, its potential impact (e.g., remote code execution), and the typical attack scenario.
• Details: Key-value pairs of essential data points, including the original exploit release date, attack vectors (Email, Web), and mitigation advice (Patch).
• Associated Reporting: This powerful section links the vulnerability to our long-form threat intelligence reports. Here, CVE-2010-3765 is directly linked to a report on the threat actor APT19, providing immediate context that this isn't just a vulnerability, but a tool used by a known adversary.
• CVSS Score: We provide both the Base Score (9.3 Critical), representing the vulnerability's intrinsic severity, and the Temporal Score (6.9 Medium), which adjusts the score based on factors like the availability of a fix.
• Vulnerable Products: A donut chart giving a quick overview of the most affected product families (e.g., Firefox, Fedora, Red Hat).

Some important definitions:

• Priority Rating (P0 – P4): When using Google Threat Intelligence Group (GTIG) vulnerability intelligence data to prioritize remediation efforts, we encourage users to consider three data points: Risk Rating (or Predictive Risk Rating), Exploitation State, and Exploit Availability. Our Priority Rating factors merge these three data points together to help customers clearly understand the threat and potential impact each vulnerability poses, and therefore better prioritize remediations. For our Priority scores, we utilize a traditional P0 through P4 model, with P0 being the highest criticality and P4 being the lowest:

  • P0:
    • Vulnerabilities with Risk Rating Critical.
    • Vulnerabilities with Risk Rating High and Exploitation State Wide, Confirmed, or Reported.
    • Vulnerabilities with Risk Rating Medium and Exploitation State Wide.
  • P1:
    • Vulnerabilities with Risk Rating High and Exploitation State Suspected.
    • Vulnerabilities with Risk Rating High, Exploitation State No Known, and Exploit Availability other than No Known.
    • Vulnerabilities with Risk Rating Medium and Exploitation State Confirmed, Reported, or Suspected.
    • Vulnerabilities with Risk Rating Low and Exploitation State Wide or Confirmed.
  • P2:
    • Vulnerabilities with Risk Rating High, Exploitation State No Known, and Exploit Availability No Known.
    • Vulnerabilities with Risk Rating Medium, Exploitation State No Known, and Exploit Availability Trivial, Publicly Available, Privately Held, or Unverified.
    • Vulnerabilities with Risk Rating Low and Exploitation State Reported or Suspected.
  • P3:
    • Vulnerabilities with Risk Rating Medium, Exploitation State No Known, and Exploit Availability Interest Observed or No Known.
    • Vulnerabilities with Risk Rating Low, Exploitation State No Known, and Exploit Availability Trivial, Publicly Available, Privately Held, or Unverified.
  • P4:
    • Vulnerabilities with Risk Rating Low, Exploitation State No Known, and Exploit Availability Interest Observed or No Known.

• Exploitation State: Indicates our knowledge of actual exploitation activity in the threat landscape:

  • No Known: No reports or observations of exploitation for this vulnerability.
  • Suspected: Exploitation has not been formally confirmed, but evidence indicates that exploitation may have occurred or be occurring in the wild.
  • Reported: Public or external reports of active exploitation exist, although Google Threat Intelligence Group has not confirmed it firsthand.
  • Confirmed: Google Threat Intelligence Group has directly observed exploitation or verified credible reports of active exploitation.
  • Wide: Exploitation of the vulnerability is occurring on a wide scale.

• Exploit Availability: Indicates the availability, interest, or development of code capable of exploiting the vulnerability:

  • No Known: No exploit code is available, nor claims of privately held exploits or proof-of-concepts (PoC), nor walkthroughs with enough details to produce an exploit.
  • Interest Observed: No exploit code or privately held exploit is available, but threat actors have been observed asking about or requesting exploits, or researchers have been observed attempting to develop an exploit/PoC.
  • Unverified: An exploit sample is alleged to exist in the wild, but Google Threat Intelligence Group has not yet validated its legitimacy or functionality.
  • Privately Held: Credible reports of researchers possessing a PoC/exploit exist, or exploitation has been observed but the code for the exploit is not publicly available.
  • Publicly Available: Exploit or PoC code exists and is publicly accessible.
  • Trivial: Exploitation of this vulnerability does not require specialized code or complex tooling.

• Risk Rating and Predictive Risk Rating (PRR): An assessment of the potential impact an attacker would have on a targeted organization if they exploit the vulnerability:

  • Low: Little to no security impact on targeted systems (e.g., leak or modification of low-value information, temporary or local denial-of-service (DoS), cross-site scripting (XSS) without critical context).
  • Medium: Enables attackers to perform additional actions or have a direct impact, but requires notable mitigating factors to be overcome (e.g., privilege escalation excluding root/system-level roles, persistent network DoS, code execution requiring user interaction or elevated privileges).
  • High: Enables attackers to have a direct and notable impact on targeted systems without needing to overcome major mitigating factors (e.g., DoS with safety concerns under IEC 61508, remote code execution (RCE) with little to no mitigating factors, privilege escalation to root).
  • Critical: Fundamentally undermines security at scale, enabling trivial remote attacks with high reliability (e.g., Log4Shell CVE-2021-44228, CVE-2024-1709).
  • Predictive Risk Rating (PRR): A predictive algorithm based on CWE, attack vectors, consequences, CVSS, and risk factors for vulnerabilities pending manual analysis. A PRR of "High" escalates the vulnerability for expert analyst review.
  • Unrated: Vulnerabilities currently undergoing analysis or with insufficient information to assign a Risk Rating.

• CVSS Score:

  • CVSS v4 BT (Base and Threat): This metric group represents the intrinsic characteristics of a Vulnerability that are constant over time but not across user environments as well as the current state of exploit techniques or code availability for a vulnerability.
  • CVSS 3.1 Base Score: Filter based on a range of CVSS 3.1 Base Score metrics.
  • CVSS 3.1 Temporal Score: Filter based on a range of CVSS 3.1 Temporal Score metrics.
  • CVSS 2.0 Base Score: Filter based on a range of CVSS 2.0 Base Score metrics.
  • CVSS 2.0 Temporal Score: Filter based on a range of CVSS 2.0 Temporal Score metrics.

• EPSS Score Range: Filter based on a range of EPSS Score metrics.

ℹ️

The Exploit Prediction Scoring System (EPSS) model is updated daily. When that data gets pushed to Google Threat Intelligence depends on a few factors:

• If the vulnerability receives an EPSS score for the first time, the data is updated and immediately sent to Google Threat Intelligence.
• If a new EPSS score is a significant change from the previous score (+/- 10%), the data is updated and immediately sent to Google Threat Intelligence.
• Otherwise, on the next update to the vulnerability (new source/exploit added, updated analysis/description, new exploitation info, and so on), the most recent EPSS score is sent to Google Threat Intelligence.

2. IOCs (Indicators of Compromise) Tab

IOCs Sub-Tab

This tab is the home for all technical indicators associated with the vulnerability, crucial for threat hunting and detection. It is divided into sub-tabs for clarity.

Commonalities Sub-Tab

This is one of the most powerful views for threat hunting and campaign analysis. Instead of a simple list, the Commonalities tab aggregates all IOCs related to this CVE and identifies shared characteristics. It helps answer the question: "What other malicious behaviors, files, and infrastructure are connected to the exploitation of this vulnerability?"

Key sections that could be included, depending on the specific example:

• Detections
  • Top threat category
  • Top threat name
  • Sandbox verdicts
  • Tags
• Distribution Vectors
  • In The Wild URLs
  • Compressed Parents
  • PCAP Parents
• Threat network infrastructure
  • Contacted Domains
  • Parent contacted Domains
  • Contacted IP Addresses
  • Embedded URLs
  • Embedded Domains
• Similarity hashes
  • Feature hash (vhash)
  • Dynamic analysis feature hash (behash)
  • TLSH hash
  • Filecondis dhash
• MITRE ATT&CK
  • Attack Tactics
  • Attack Techniques
• Execution tracing
  • Mutexes created
  • Registry keys opened
  • Registry keys set
• Static analysis
  • File Types

Telemetry Sub-Tab

Here, you can visualize real-world "lookups and submissions" related to the CVE, sourced from Google's global sensor network. The chart and map show temporal and geographic trends, helping you understand where the vulnerability is generating the most interest or activity.

Exploits Sub-Tab

This view lists specific exploit files we have observed. For each file, you see:

• File Hash (SHA256): A unique identifier for the exploit code.
• Exploit Name: Often includes the file name and associated tags like metasploit or exploit, indicating its origin or purpose.
• Exploit Grade: Our assessment of the exploit's reliability.
  • unevaluated
    • The exploit has not been evaluated by an analyst. This is to only be used when an exploit is ingested through automation.
  • proof-of-concept
    • This code is intended to demonstrate that exploitation of the vulnerability is possible and can potentially deploy a non-payload, such as 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 commands to execute upon exploitation, but contains all of the logic required to execute them when the user defines them. Note that if a non-malicious payload is included, such as opening the calculator or notepad, it would still be a non-weaponized exploit.
  • weaponized
    • This code contains a malicious payload or specific code or command to perform malicious actions against a vulnerable system, such as overwrites or reads a critical file, spawns a reverse shell, deploys known malware, or causes a DoS (denial of service) condition. The code can typically be used as-is and does not require the further development to perform malicious actions.
      • It will still be weaponized if you can override the default payload so long as any non-benign payload is included by default. IE, if it would spawn a reverse shell by default, but you can override it with your own command, it would still be weaponized as it has a non-benign default payload.
      • If there is a malicious payload which is included in the code but commented out, it would still be considered weaponized as enabling that malicious code would be trivial.
  • scanner
    • A scanner does not deploy any malicious payloads against a target, but instead determines whether the target is vulnerable 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 instead simply used to determine if the system is vulnerable. The payloads executed by a scanner must be benign, and may not affect the future security of the scanned system. See below for more details and examples.
  • fake
    • The code is intentionally fake or misleading. This can be done by researchers determining which vendors are reporting on un-analyzed exploit code or by malicious actors to distract researchers. There is no legitimate functionality, and the code may not even pertain to the vulnerability in question.
• Size & Release Date: Additional metadata for identification.

3. Products and Fixes Tab

This tab is essential for vulnerability management and patching prioritization.

• Vulnerable Products: A comprehensive, searchable list of every affected vendor, product, and version. This allows you to precisely identify vulnerable assets in your environment.

• Vendor Fix Details: Direct links to official vendor advisories and patch information from sources like Red Hat, Debian, and Mozilla. This provides an authoritative path to remediation.

4. Sources Tab

For transparency and further research, the Sources tab lists every source of information that contributed to our report. This includes NVD entries, security advisories, vendor bug trackers, news articles, and security research blogs.

5. History Tab

Our reports are living documents. The History tab provides a complete changelog of every update made to the report by our systems and analysts. This shows you how our understanding of the threat has evolved, such as when it was first marked as "exploited in the wild" or when new YARA rules were added.

6. TTPs (MITRE ATT&CK) Tab

Understanding how a vulnerability is used is as important as knowing what it is. This tab maps the exploitation of the CVE to the MITRE ATT&CK® framework.

For CVE-2010-3765, we see it mapped to Tactics like Discovery and Command and Control, and specific Techniques like Application Layer Protocol (T1071). This helps defenders align their controls and detections with known adversary behaviors (TTPs).

ℹ️

Techniques can match with the collection itself or with individual IoCs.

• For individual IoC matches, a tag with the number of matches and an eye icon appears.
• For collection-wide matches, this tag is not included, and an engine icon is displayed instead.

7. Reporting Tab

This tab provides insight into the global activity and high-level reporting related to the vulnerability.

8. Community Tab

Security is a collaborative effort. The Community tab provides a space for verified users to share comments, ask questions, and contribute their own findings related to the vulnerability, fostering a shared understanding of the threat.