8 minhigh
The Risk of Exposed Cloud Functions and How to Harden
Mandiant identifies publicly exposed serverless applications lacking authentication as a significant risk during security assessments. Attackers can exploit Local File Inclusion (LFI) or command injection vulnerabilities in custom code to read sensitive files, extract hardcoded secrets, and retrieve GCP service account bearer tokens from the metadata service. Stolen tokens enable lateral movement and potential full cloud project compromise, especially when Cloud Run services use over-privileged default service accounts. The blog provides hardening guidance including least-privilege IAM, Cloud Armor WAF policies, VPC Service Controls, and Secure SDLC practices.
Conf:high
Detection / Hunteropenrouter
What Happened
Security researchers found that many cloud-based serverless applications are publicly accessible without proper authentication, making them easy targets for attackers. If an attacker finds a vulnerability in the application code—such as the ability to read arbitrary files or execute commands—they can steal sensitive information like API keys and cloud service account tokens. With a stolen token, the attacker can take over the broader cloud environment, especially if the application runs with excessive permissions. Organizations running serverless workloads should review their code for vulnerabilities, restrict permissions to the minimum needed, use a web application firewall, and isolate public-facing services from internal systems.
Key Takeaways
- Publicly exposed serverless functions lacking authentication can be exploited via Local File Inclusion (LFI) and command injection to achieve full container compromise.
- Attackers can extract GCP service account bearer tokens from the metadata service after achieving RCE, enabling lateral movement and potential full cloud project takeover.
- Default Compute Engine service accounts with Editor permissions on Cloud Run services significantly amplify blast radius if the function is compromised.
- Cloud Armor preconfigured WAF rules (lfi-v33-stable, rce-v33-stable) can block common LFI and RCE attack patterns at the edge.
- Defense-in-depth including least-privilege IAM, VPC Service Controls, dedicated service projects, and Layer 7 ALB architecture is critical for publicly accessible serverless workloads.
Affected Systems
- Google Cloud Run services and functions
- Serverless/FaaS deployments (general)
- Python/Flask serverless applications
- GCP environments using default Compute Engine service accounts
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker targets publicly exposed serverless function lacking authentication
- Exploitation: Attacker exploits LFI to read source code, configuration files, and hardcoded secrets, or command injection to execute arbitrary commands
- Credential Access: Attacker queries the GCP metadata service to extract the service account OAuth 2.0 bearer token
- Privilege Escalation/Lateral Movement: Attacker uses the stolen token to authenticate to GCP via gcloud CLI under the Cloud Run service account's security context
- Impact: If the service account is over-privileged (e.g., default Compute Editor), attacker achieves full GCP project takeover including resource deletion, data exfiltration, and persistence via new service accounts or SSH keys
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Google Cloud Armor WAF policies, Google Cloud Security Command Center (SCC)
The article provides Cloud Armor preconfigured WAF rule configurations (lfi-v33-stable, rce-v33-stable) for blocking LFI and RCE attacks, and references Google Cloud SCC Cloud Run Threat Detection for detecting credential access, reconnaissance, and reverse shell execution. No custom detection rules (YARA, Sigma, etc.) are included.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | Serverless container instances are ephemeral and typically lack traditional EDR agents; runtime visibility depends on cloud-native monitoring tools rather than endpoint telemetry. |
| Network Visibility | Medium | GCP load balancer logs, VPC Flow Logs, and Cloud Run request logs can capture inbound requests and metadata service queries, but internal metadata API calls may not be logged by default network monitoring. |
| Detection Difficulty | Moderate | Detecting application-level exploits (LFI, command injection) requires WAF or application-layer inspection. Metadata service access detection requires Cloud Audit Logs and SCC. The ephemeral nature of serverless containers complicates forensic analysis. |
Required Log Sources
- GCP Cloud Audit Logs (Admin Activity and Data Access)
- Cloud Run request logs
- Cloud Armor security policy logs
- Layer 7 ALB access logs
- VPC Flow Logs
- Google Cloud SCC findings
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for HTTP requests to Cloud Run services containing path traversal sequences or file parameter patterns consistent with LFI attempts (T1083, T1190). | Cloud Armor logs, Cloud Run request logs, Layer 7 ALB access logs | Initial Access / Exploitation | Medium — legitimate file download endpoints may trigger similar patterns; tune based on expected application behavior. |
| Consider hunting for outbound network connections from Cloud Run instances to the GCP metadata service endpoint, which may indicate command injection leading to token theft (T1552.005). | VPC Flow Logs, Cloud Run instance network telemetry, SCC Cloud Run Threat Detection findings | Credential Access | Low — metadata service access from application code is uncommon and should be investigated. |
| Consider hunting for gcloud CLI API calls authenticated with Cloud Run service account tokens originating from IPs outside the GCP Cloud Run service range, indicating token theft and external use (T1078.004). | GCP Cloud Audit Logs (Admin Activity), IAM policy analysis, source IP geolocation | Lateral Movement / Privilege Escalation | Low — service account tokens used from non-GCP infrastructure are highly suspicious. |
| Consider hunting for creation of new service accounts, SSH keys, or deployment of new Cloud Run services by the Cloud Run compute service account, which may indicate persistence after compromise. | GCP Cloud Audit Logs (Admin Activity — iam.serviceAccounts.create, compute.instances.insert, run.services.create) | Persistence / Impact | Medium — legitimate CI/CD pipelines may perform similar actions; correlate with expected deployment patterns. |
Control Gaps
- Traditional EDR solutions provide no coverage for ephemeral serverless containers without cloud-native runtime monitoring.
- Network-level firewalls alone cannot detect or block application-layer exploits like LFI or command injection without a WAF.
- Default IAM configurations (e.g., Compute Editor role) provide no containment boundary between compromised serverless functions and the rest of the GCP project.
- Without VPC Service Controls, stolen service account tokens can be used from external systems to access GCP resources without network-level restrictions.
Key Behavioral Indicators
- HTTP requests to Cloud Run endpoints containing '../' traversal sequences or references to /etc/passwd, /proc/self/environ, .env files
- Subprocess or shell execution within serverless function runtime triggered by user-controlled input parameters
- GCP API calls authenticated with Cloud Run service account tokens from non-GCP IP addresses
- Unexpected service account creation or SSH key deployment by a Cloud Run service account
- Cloud Armor WAF rule matches for lfi-v33-stable or rce-v33-stable policies
False Positive Assessment
Low — the attack patterns described (path traversal in HTTP parameters, metadata service token extraction, external use of service account tokens) are highly indicative of malicious activity when observed against serverless endpoints.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing all publicly exposed Cloud Run services and serverless functions for authentication requirements and input validation.
- If your Cloud Run services use the default Compute Engine service account, consider replacing it with a custom service account following least-privilege principles.
- Consider implementing Cloud Armor security policies with lfi-v33-stable and rce-v33-stable preconfigured rules in front of publicly accessible serverless endpoints.
- Evaluate whether any Cloud Run services have over-privileged IAM roles (e.g., Editor) and restrict permissions to only what is required.
Infrastructure Hardening
- Consider hosting public-facing Cloud Run services in a dedicated, isolated GCP project to contain potential compromise blast radius.
- Evaluate restricting Cloud Run ingress to internal-only traffic and exposing services through a Layer 7 ALB with Cloud Armor, IAP, and SSL policy management.
- If using VPC egress or VPC Access connectors, consider implementing VPC Service Controls to restrict lateral movement and data exfiltration paths.
- Consider enabling Google Cloud SCC Cloud Run Threat Detection for runtime monitoring of credential access, reconnaissance, and reverse shell execution.
User Protection
- Consider integrating security scanning, code review, and least-privilege IAM checks into CI/CD pipelines before serverless function deployment.
- Evaluate enforcing strict data egress controls and sandbox isolation for AI-generated code ('vibe coding') environments.
- Consider restricting development environments to approved IDEs with human-in-the-loop review and verified plugins under least privilege.
Security Awareness
- Consider rolling into existing awareness programs training on the risks of hardcoding secrets in source code and the importance of using dedicated secrets management solutions.
- Consider establishing internal guidelines for permitted AI-generated code use cases and ensuring they follow S-SDLC controls.
- If applicable, consider educating development teams on LFI, command injection, and metadata service abuse risks specific to serverless architectures.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping6 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
Credential Access
Tactic
Discovery
Additional IOCs
- Command Lines:
- Purpose: Extracting GCP service account OAuth 2.0 bearer token from the metadata service via command injection | Tools:
curl| Stage: Credential Access - Purpose: Setting stolen bearer token as environment variable for gcloud CLI authentication | Tools:
export,gcloud| Stage: Lateral Movement |export CLOUDSDK_AUTH_ACCESS_TOKEN=
- Purpose: Extracting GCP service account OAuth 2.0 bearer token from the metadata service via command injection | Tools:
