Stay organized with collections
Save and categorize content based on your preferences.
This document describes a threat finding type in Security Command Center. Threat findings are generated by
threat detectors when they detect
a potential threat in your cloud resources. For a full list of available threat findings, see Threat findings index.
Overview
Supported Log4j vulnerability scanners inject obfuscated JNDI lookups in HTTP
parameters, URLs, and text fields with callbacks to domains controlled by the
scanners. This finding is generated when DNS queries for the unobfuscated domains
are found. Such queries only occur if a JNDI lookup was successful, indicating
an active Log4j vulnerability.
How to respond
To respond to this finding, do the following:
Step 1: Review finding details
Open an Active Scan: Log4j Vulnerable to RCE finding, as directed in
Reviewing finding details. The details
panel for the finding opens to the Summary tab.
On the Summary tab, review the information in the following sections:
What was detected
Affected resource, especially the following field:
Resource full name: the
full resource name of the
Compute Engine instance that is vulnerable to the Log4j RCE.
Related links, especially the following fields:
Cloud Logging URI: link to Logging entries.
MITRE ATT&CK method: link to the MITRE ATT&CK documentation.
Related findings: links to any related findings.
In the detail view of the finding, click the JSON tab.
In the JSON, note the following fields.
properties
scannerDomain: the domain used by the scanner as part of the JNDI
lookup. This tells you which scanner identified the vulnerability.
sourceIp: the IP address used to make the DNS query
vpcName: the name of the network on the instance where the DNS query
was made.
Step 2: Check logs
In the Google Cloud console, go to Logs Explorer by clicking
the link in the Cloud Logging URI field from step 1.
On the page that loads, check the httpRequest fields for string tokens
like ${jndi:ldap:// that may indicate possible exploitation attempts.
Review related findings by clicking the link on the Related findings
on the Related findings row in the Summary tab of the
finding details.
Related findings are the same finding type and the same instance and network.
To develop a response plan, combine your investigation results with MITRE
research.
Step 4: Implement your response
The following response plan might be appropriate for this finding, but might also impact operations.
Carefully evaluate the information you gather in your investigation to determine the best way to
resolve findings.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["| Premium and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis document describes a threat finding type in Security Command Center. Threat findings are generated by\n[threat detectors](/security-command-center/docs/concepts-security-sources#threats) when they detect\na potential threat in your cloud resources. For a full list of available threat findings, see [Threat findings index](/security-command-center/docs/threat-findings-index).\n\nOverview\n\nSupported Log4j vulnerability scanners inject obfuscated JNDI lookups in HTTP\nparameters, URLs, and text fields with callbacks to domains controlled by the\nscanners. This finding is generated when DNS queries for the unobfuscated domains\nare found. Such queries only occur if a JNDI lookup was successful, indicating\nan active Log4j vulnerability.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Active Scan: Log4j Vulnerable to RCE` finding, as directed in\n [Reviewing finding details](/security-command-center/docs/how-to-investigate-threats#reviewing_findings). The details\n panel for the finding opens to the **Summary** tab.\n\n2. On the **Summary** tab, review the information in the following sections:\n\n - **What was detected**\n - **Affected resource** , especially the following field:\n - **Resource full name** : the [full resource name](/apis/design/resource_names) of the Compute Engine instance that is vulnerable to the Log4j RCE.\n - **Related links** , especially the following fields:\n - **Cloud Logging URI**: link to Logging entries.\n - **MITRE ATT\\&CK method**: link to the MITRE ATT\\&CK documentation.\n - **Related findings**: links to any related findings.\n3. In the detail view of the finding, click the **JSON** tab.\n\n4. In the JSON, note the following fields.\n\n - `properties`\n - `scannerDomain`: the domain used by the scanner as part of the JNDI lookup. This tells you which scanner identified the vulnerability.\n - `sourceIp`: the IP address used to make the DNS query\n - `vpcName`: the name of the network on the instance where the DNS query was made.\n\nStep 2: Check logs\n\n1. In the Google Cloud console, go to **Logs Explorer** by clicking the link in the **Cloud Logging URI** field from [step 1](#log4j_active_findings).\n2. On the page that loads, check the `httpRequest` fields for string tokens\n like `${jndi:ldap://` that may indicate possible exploitation attempts.\n\n See [CVE-2021-44228: Detecting Log4Shell exploit](/logging/docs/log4j2-vulnerability)\n in the Logging documentation for example strings to search\n for and for an example query.\n\nStep 3: Research attack and response methods\n\n1. Review the MITRE ATT\\&CK framework entry for this finding type: [Exploitation of Remote Services](https://attack.mitre.org/techniques/T1210/).\n2. Review related findings by clicking the link on the **Related findings** on the **Related findings** row in the **Summary** tab of the finding details. Related findings are the same finding type and the same instance and network.\n3. To develop a response plan, combine your investigation results with MITRE research.\n\nStep 4: Implement your response\n\n\nThe following response plan might be appropriate for this finding, but might also impact operations.\nCarefully evaluate the information you gather in your investigation to determine the best way to\nresolve findings.\n\n- Upgrade to the [latest version of Log4j](https://logging.apache.org/log4j/2.x/download.html).\n- Follow [Google Cloud's recommendations for investigating and responding\n to the \"Apache Log4j\" vulnerability](https://cloud.google.com/blog/products/identity-security/recommendations-for-apache-log4j2-vulnerability).\n- Implement the recommended mitigation techniques in [Apache Log4j Security Vulnerabilities](https://logging.apache.org/log4j/2.x/security.html).\n- If you use [Google Cloud Armor](/armor/docs), deploy the `cve-canary rule` into a new or existing Cloud Armor security policy. For more information, see [Google Cloud Armor WAF rule to help mitigate Apache Log4j vulnerability](https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability).\n\nWhat's next\n\n- Learn [how to work with threat\n findings in Security Command Center](/security-command-center/docs/how-to-investigate-threats).\n- Refer to the [Threat findings index](/security-command-center/docs/threat-findings-index).\n- Learn how to [review a\n finding](/security-command-center/docs/how-to-investigate-threats#reviewing_findings) through the Google Cloud console.\n- Learn about the [services that\n generate threat findings](/security-command-center/docs/concepts-security-sources#threats)."]]