Zammad Zero-Days Exploited in Agentic AI-Powered Attack on DIVD — Detection and Remediation Guide for Helpdesk Defenders

The Dutch Institute for Vulnerability Disclosure (DIVD) — an organization whose entire mission is finding and responsibly disclosing vulnerabilities before criminals abuse them — has publicly revealed that it was targeted in an attack leveraging two zero-day vulnerabilities in Zammad, the open-source ticketing and helpdesk platform. What makes this incident stand apart from the hundreds of exploitation events crossing my desk every quarter is the reported tradecraft: the attackers employed agentic AI capabilities to automate and accelerate the attack chain.

Let that sink in. The adversary didn't just find unpatched helpdesk software — they pointed autonomous, AI-driven tooling at it. This is the operationalization of a threat model many of us in the IR community have been warning about since agentic AI frameworks went mainstream: machine-speed reconnaissance, exploit adaptation, and post-exploitation decision-making with minimal human oversight.

If your organization runs Zammad — self-hosted or otherwise — this is an immediate patch-and-hunt event. If you run any externally reachable ticketing platform, this is your quarterly reminder that helpdesk systems are tier-zero assets holding credential resets, internal hostnames, user PII, and privileged workflow integrations. Here's what we know, and what you need to do.

Technical Analysis

The Target: Zammad

Zammad is a widely deployed open-source helpdesk and customer support platform, typically self-hosted on Linux (Ruby on Rails application stack, commonly fronted by Nginx or Apache, with Elasticsearch for indexing and PostgreSQL/MySQL for persistence). Its default deployment model creates an attractive attack surface:

• Publicly exposed by design — ticket submission, customer portals, and inbound email-to-ticket pipelines must accept unauthenticated input
• Rich integration surface — LDAP/AD sync, email connectors, webhooks, and a REST API with API-token authentication
• High-value data at rest — internal communications, credentials shared by users, attachment stores, and directory information
• Privileged service account context — the Zammad application frequently authenticates to mail servers and directory services, meaning a host compromise often yields reusable credentials

The Attack Chain (Defender's View)

Based on DIVD's disclosure, the intrusion leveraged two previously unknown vulnerabilities in Zammad. While the full technical root cause has not been publicly detailed at the time of writing, the reported pattern is consistent with the web-application exploitation class we repeatedly see against ticketing platforms:

1. Initial access via the public-facing application — exploitation of a zero-day in the Zammad web tier (unauthenticated or low-authentication attack surface: ticket creation, attachment handling, or API endpoints)
2. Code execution or privilege escalation in application context — the second zero-day reportedly chained to extend access beyond the initial foothold (a classic one-two: entry bug plus an escalation/auth-bypass bug)
3. Agentic AI-driven post-exploitation — automated tooling performing reconnaissance, data identification, and adaptive decision-making inside the environment at machine tempo

The Agentic AI Dimension — Why This Matters for Detection

The use of agentic AI changes the timing signature of the intrusion, and that's where defenders can fight back. Human-operated intrusions have rhythm: pauses, mistakes, working hours. Agentic attacks exhibit:

• Abnormally high request velocity — dozens to hundreds of API calls per minute from a single session or source, with perfectly regular inter-request timing
• Systematic endpoint enumeration — sequential probing of /api/v1/ resources (tickets, users, organizations, groups) with no exploratory meandering
• Instant exploit adaptation — failed requests immediately reformulated, consistent with an LLM-in-the-loop fuzzing or parameter-tampering cycle
• Machine-consistent session behavior — no mouse/UX artifacts, uniform header ordering, API-only interaction with no corresponding browser page loads

This means your behavioral detections on API telemetry are now first-class controls, not nice-to-haves. If your Zammad instance is only logged at the Nginx level with default formats, you are flying blind against exactly this attacker profile.

Exploitation Status

• Confirmed in-the-wild exploitation: Yes — DIVD has publicly stated it was attacked using these zero-days
• Public PoC: Not confirmed at time of writing
• CVE identifiers: Not yet publicly assigned in the reporting available to us; monitor the Zammad security advisories page and CISA KEV for updates
• Patch status: Check the official Zammad release notes and security advisories immediately — treat all internet-facing Zammad instances as potentially exposed until patched

Detection & Response

The following detections target the observable behaviors of this attack class: web-tier exploitation of the Zammad Rails application, agentic-speed API enumeration, and post-exploitation command execution from the web application context. Tune thresholds to your environment baseline.

Sigma Rules

---
title: Zammad Web Application Spawning Shell or Script Interpreter
id: 8f2a1c47-3b9e-4d61-a702-5e6c8d9f0a1b
status: experimental
description: Detects the Zammad web application process (Puma/Ruby under the zammad user) spawning shell interpreters or common post-exploitation tools, consistent with web-tier remote code execution against the ticketing platform.
references:
  - https://www.infosecurity-magazine.com/news/zerodays-dutch-institute/
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/ruby'
      - '/puma'
      - '/ruby3.1'
      - '/ruby3.2'
      - '/ruby3.3'
    ParentCommandLine|contains:
      - 'zammad'
      - 'puma'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Zammad scheduled job processing invoking system utilities (rare; baseline and allowlist known job commands)
  - Legitimate integrations calling scripts via the Zammad scheduler
level: high
---
title: High-Velocity Zammad API Enumeration Consistent with Agentic Automation
id: 3c7d9e15-8a42-4f6b-b913-2d4e7a8c1f5d
status: experimental
description: Detects abnormally high request rates against Zammad REST API endpoints from a single source, a timing signature consistent with agentic AI-driven reconnaissance and data harvesting as reported in the DIVD intrusion.
references:
  - https://www.infosecurity-magazine.com/news/zerodays-dutch-institute/
  - https://attack.mitre.org/techniques/T1213/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1213
  - attack.discovery
logsource:
  category: webserver
detection:
  selection:
    cs-uri|contains:
      - '/api/v1/tickets'
      - '/api/v1/users'
      - '/api/v1/organizations'
      - '/api/v1/groups'
      - '/api/v1/ticket_articles'
  condition: selection | count() by c-ip > 100
  timeframe: 5m
falsepositives:
  - Legitimate API integrations and reporting scripts (allowlist known service account source IPs)
  - Load balancer health checks (typically hit a single endpoint only)
level: medium
---
title: Suspicious Ticket Creation with Attachment or External URL Payload
id: 61b4e8a2-2f37-4c95-d806-9a1b3e7c2f48
status: experimental
description: Detects inbound ticket-creation requests containing archive, script, or executable attachment references, a common delivery mechanism for helpdesk-targeted exploitation and social engineering of agents.
references:
  - https://www.infosecurity-magazine.com/news/zerodays-dutch-institute/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri|contains:
      - '/api/v1/tickets'
      - '/api/v1/ticket_attachment'
      - '/api/v1/upload_cache'
    cs-body|contains:
      - '.js'
      - '.vbs'
      - '.ps1'
      - '.hta'
      - '.iso'
      - '.html'
      - '.svg'
      - 'base64'
  condition: selection
falsepositives:
  - Legitimate user attachments (tune against attachment allowlist policies)
level: medium

KQL Hunt — Microsoft Sentinel

This query assumes Zammad front-end (Nginx/Apache) access logs are ingested into CommonSecurityLog or Syslog. It hunts for the two key behavioral signatures: exploitation-style probing and agentic-velocity API enumeration.

// Hunt 1: Agentic-velocity API enumeration against Zammad endpoints
let zammad_api = dynamic(["/api/v1/tickets","/api/v1/users","/api/v1/organizations","/api/v1/groups","/api/v1/ticket_articles","/api/v1/search"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any (zammad_api)
| summarize RequestCount=count(), DistinctEndpoints=dcount(RequestURL), Endpoints=make_set(RequestURL, 20), Methods=make_set(RequestMethod) by SourceIP, bin(TimeGenerated, 5m)
| where RequestCount > 100 or DistinctEndpoints > 4
| project TimeGenerated, SourceIP, RequestCount, DistinctEndpoints, Endpoints, Methods
| order by RequestCount desc;
// Hunt 2: Exploitation-style probing — encoded payloads, traversal, template injection markers in Zammad requests
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL contains "zammad" or RequestURL has "/api/v1/"
| where RequestURL has_any ("%2e%2e","..;/","%3c","%7b%7b","${","/etc/passwd","%00","' OR ','sleep(") or AdditionalExtensions has_any ("%2e%2e","%7b%7b","${")
| project TimeGenerated, SourceIP, RequestMethod, RequestURL, AdditionalExtensions, DeviceAction
| order by TimeGenerated desc;
// Hunt 3: Process execution from web application context on Zammad hosts (Defender for Endpoint onboarded hosts)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessCommandLine has_any ("puma","zammad","ruby")
| where FileName in~ ("sh","bash","dash","python3","perl","curl","wget","nc","ncat","base64")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc;

Velociraptor VQL — Endpoint Hunt on Zammad Hosts

If you suspect a Zammad host may have been compromised, this artifact hunts for shell and tooling processes spawned from the Rails/Puma application context, plus recently modified web-tier files (webshell staging).

-- Hunt: Zammad web-tier compromise indicators
-- 1. Shells/tools spawned by Ruby/Puma application processes
-- 2. Recently modified files in Zammad application and upload directories
LET suspicious_children = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(/bin/(ba)?sh|curl|wget|ncat? |python|perl|base64|chmod \+x|/tmp/|/dev/shm)'
  AND Name =~ '(?i)sh|bash|python|perl|curl|wget|nc'

LET parent_procs = SELECT Pid, Name, CommandLine, Username
FROM pslist()
WHERE CommandLine =~ '(?i)(puma|zammad|ruby)'

SELECT s.Pid AS ChildPid, s.Name AS ChildName, s.CommandLine AS ChildCmdline,
       s.Username AS ChildUser, s.CreateTime AS ChildStart,
       p.Name AS ParentName, p.CommandLine AS ParentCmdline
FROM suspicious_children s
JOIN parent_procs p ON s.Ppid = p.Pid

-- Hunt: Recently modified files in Zammad web root and upload stores (potential webshell staging)
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/opt/zammad/app/**/*.rb','/opt/zammad/public/**/*','/opt/zammad/storage/**/*','/tmp/**'])
WHERE Mtime > now() - (7 * 24 * 3600)
  AND NOT IsDir
ORDER BY Mtime DESC

Remediation & Verification Script

Run on Zammad hosts (Debian/Ubuntu package installs; adapt paths for source installs). The script checks your Zammad version, pulls the latest security updates, validates no shells are spawned by the app, and audits API token hygiene.

#!/bin/bash
# Zammad Zero-Day Response: Patch, Verify, Hunt (Debian/Ubuntu package installs)
set -euo pipefail

echo "=== [1] Current Zammad version ==="
dpkg -l zammad 2>/dev/null | tail -n 1 || echo "Package not found - check source install"

echo "=== [2] Apply pending Zammad security updates ==="
apt-get update
apt-get install --only-upgrade -y zammad
echo "Post-upgrade version:"
dpkg -l zammad | tail -n 1

echo "=== [3] Restart and verify service health ==="
systemctl restart zammad
sleep 10
systemctl is-active zammad && echo "Zammad service: ACTIVE"

echo "=== [4] Hunt: shells spawned by zammad/puma processes (last 24h) ==="
journalctl _COMM=zammad --since "24 hours ago" --no-pager 2>/dev/null | grep -iE '(/bin/(ba)?sh|curl |wget |nc |base64)' || echo "No suspicious child-process log entries found"
ps aux | grep -E '(puma|ruby)' | grep -v grep | awk '{print $1, $2, $11, $12}'

echo "=== [5] Audit: recently modified files in web root / upload store ==="
find /opt/zammad/public /opt/zammad/storage /opt/zammad/app -type f -mtime -7 2>/dev/null | head -50

echo "=== [6] Audit: Zammad API tokens (rotate any unexpected entries) ==="
sudo -u zammad bash -c 'cd /opt/zammad && RAILS_ENV=production bundle exec rails runner "Token.where(persistent: true).each { |t| puts [t.id, t.name, t.user_id, t.created_at].join(%q{ | }) }"' 2>/dev/null || echo "Manual token audit required via Rails console"

echo "=== [7] Verify inbound exposure: is the instance internet-facing? ==="
ss -tlnp | grep -E ':(80|443|3000|6042)' || echo "No listeners on expected ports"

echo "=== DONE. Review output; rotate tokens, review tickets for attacker-created artifacts. ==="

Remediation

Immediate (today):

1. Patch Zammad. Upgrade to the latest release from the official Zammad repositories and verify against the vendor security advisories at https://zammad.com/en/releases and https://zammad.org/security. Do not assume your instance is unaffected because you haven't seen alerts — agentic intrusions are fast and quiet. If a fixed version addressing these zero-days is published, treat it as an emergency change.
2. Inventory exposure. Enumerate every internet-facing Zammad instance (including forgotten staging/dev portals). If an instance does not need to be public, put it behind VPN or an authenticated reverse proxy today.
3. Rotate secrets. Rotate all Zammad API tokens, mail connector credentials, and any LDAP/AD bind accounts used by the application. Assume tokens readable from the application context are compromised if exploitation is suspected.

Short-term (this week):

4. Deploy the detections above. At minimum, the "web app spawning shell" Sigma rule and the API-velocity KQL hunt. Helpdesk compromise frequently goes undetected for weeks; these two controls close the most common blind spot.
5. Enable verbose application logging. Ensure Nginx/Apache access logs capture request bodies for POST endpoints (or deploy a WAF that does), and ship Zammad production logs to your SIEM. You cannot hunt agentic behavior with default logging.
6. Retroactive hunt. Pull 30–90 days of access logs and hunt for the enumeration and probing patterns above. DIVD's disclosure implies exploitation predates public knowledge — assume dwell time.
7. Review ticket stores for attacker artifacts — attacker-created tickets, suspicious attachments in storage/, and new admin/agent accounts.

Strategic (this quarter):

8. Recategorize helpdesk platforms as tier-zero. Ticketing systems hold credentials, internal topology, and privileged integrations. They deserve the same segmentation, monitoring, and patch SLA as your identity infrastructure.
9. Prepare for machine-speed attacks. Agentic AI tradecraft compresses the reconnaissance-to-impact window. If your IR playbooks assume human-tempo intrusions, retest them against burst-velocity scenarios. Update your tabletop exercises accordingly.
10. Track attribution of CVEs and CISA KEV additions. When CVE identifiers are published for these zero-days, validate your asset inventory mapping and document remediation against any CISA-mandated deadlines.

The Bottom Line

DIVD being breached is not an indictment of DIVD — it's a demonstration that disciplined vulnerability researchers get hit by the same zero-days as everyone else, and that transparency after the fact is the model to follow. The harder lesson is the adversary's tooling: agentic AI has crossed from conference-talk hypotheticals into operational intrusions. Your compensating control is telemetry and behavioral detection tuned for machine-tempo abuse, because you will not win a speed contest with an autonomous agent — you win by seeing it in the first five minutes.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub