Detection rules › Panther
GCP.Privilege.Escalation.By.Deployments.Create
Detects privilege escalation in GCP by taking over the deploymentsmanager.deployments.create permission
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Privilege Escalation | T1548 Abuse Elevation Control Mechanism |
Rule body yaml
AnalysisType: rule
RuleID: "GCP.Privilege.Escalation.By.Deployments.Create"
DisplayName: "GCP.Privilege.Escalation.By.Deployments.Create"
Description: "Detects privilege escalation in GCP by taking over the deploymentsmanager.deployments.create permission"
Enabled: true
Filename: gcp_privilege_escalation_by_deployments_create.py
LogTypes:
- GCP.AuditLog
Severity: High
DedupPeriodMinutes: 60
Threshold: 1
Reference: https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/
Runbook:
Confirm this was authorized and necessary behavior. This is not a vulnerability in GCP, it is a vulnerability
in how GCP environment is configured, so it is necessary to be aware of these attack vectors and to defend against
them. It’s also important to remember that privilege escalation does not necessarily need to pass through the
IAM service to be effective. Make sure to follow the principle of least-privilege in your environments to help
mitigate these security risks.
Reports:
MITRE ATT&CK:
- TA0004:T1548
Tests:
- Name: privilege-escalation
ExpectedResult: true
Log:
protoPayload:
authorizationInfo:
- granted: true
permission: deploymentmanager.deployments.create
methodName: v2.deploymentmanager.deployments.insert
serviceName: deploymentmanager.googleapis.com
receiveTimestamp: "2024-01-19 13:47:19.465856238"
resource:
labels:
name: test-vm-deployment
project_id: panther-threat-research
type: deployment
severity: NOTICE
timestamp: "2024-01-19 13:47:18.279921000"
- Name: fail
ExpectedResult: false
Log:
protoPayload:
authorizationInfo:
- granted: афдиу
permission: deploymentmanager.deployments.create
methodName: v2.deploymentmanager.deployments.insert
serviceName: deploymentmanager.googleapis.com
receiveTimestamp: "2024-01-19 13:47:19.465856238"
resource:
labels:
name: test-vm-deployment
project_id: panther-threat-research
type: deployment
severity: NOTICE
timestamp: "2024-01-19 13:47:18.279921000"
Detection logic
Condition
protoPayload.authorizationInfo is_not_null
protoPayload.authorizationInfo array_any
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
protoPayload.authorizationInfo | is_not_null |
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
project | resource.labels.project_id |
principal | protoPayload.authenticationInfo.principalEmail |
caller_ip | protoPayload.requestMetadata.callerIP |
methodName | protoPayload.methodName |
resourceName | protoPayload.resourceName |
serviceName | protoPayload.serviceName |