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
This finding is generated when Java Naming and Directory Interface (JNDI)
lookups
within headers or URL parameters are detected. These lookups may indicate
attempts at Log4Shell exploitation.
How to respond
To respond to this finding, do the following:
Step 1: Review finding details
Open an Initial Access: Log4j Compromise Attempt 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
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
loadBalancerName: the name of the load balancer that received
the JNDI lookup
requestUrl: the request URL of the HTTP request. If present,
this contains a JNDI lookup.
requestUserAgent: the user agent that sent the HTTP request.
If present, this contains a JNDI lookup.
refererUrl: the URL of the page that sent the HTTP request. If
present, this contains a JNDI lookup.
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-03 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\nThis finding is generated when Java Naming and Directory Interface (JNDI)\n[lookups](https://logging.apache.org/log4j/2.x/manual/lookups.html)\nwithin headers or URL parameters are detected. These lookups may indicate\nattempts at Log4Shell exploitation.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Initial Access: Log4j Compromise Attempt` 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**\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.\n - In the detail view of the finding, click the **JSON** tab.\n - In the JSON, note the following fields.\n\n - `properties`\n\n - `loadBalancerName`: the name of the load balancer that received the JNDI lookup\n - `requestUrl`: the request URL of the HTTP request. If present, this contains a JNDI lookup.\n - `requestUserAgent`: the user agent that sent the HTTP request. If present, this contains a JNDI lookup.\n - `refererUrl`: the URL of the page that sent the HTTP request. If present, this contains a JNDI lookup.\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_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: [Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190/).\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)."]]