Building Audit Trails for Zoho Mail: Real-Time Admin Monitoring with Wazuh

PrerequisitesSection titled Prerequisites

• Zoho Mail with admin access and webhook capabilities (SIEM logs are unavailable on free accounts)
• Wazuh 4.x+ (tested on 4.14.0)
• A dedicated Linux VM for Logstash (RockyLinux 9+ or Ubuntu 22.04+), placed in a DMZ
• Wazuh agent installed on the receiver VM
• SSL/TLS certificate for the webhook endpoint (Let’s Encrypt or commercial — self-signed won’t work)
• Network connectivity:
  • Inbound HTTPS (port 443) from the internet to the Logstash VM
  • Outbound Wazuh agent connectivity from Logstash to Wazuh
• Admin access to the Zoho Mail Admin Console and firewall management
• 30 to 60 minutes to complete the integration

ArchitectureSection titled Architecture

Following the principle of defense in depth, Logstash sits on a separate, internet-facing VM rather than on the Wazuh Manager itself. If this receiver is ever compromised, the attacker still can’t reach the SIEM or tamper with historical logs already in Wazuh’s immutable archives.

Step 1: Firewall ConfigurationSection titled Step%201%3A%20Firewall%20Configuration

Zoho uses a push-based event system, meaning it requires an endpoint where to deliver the generated events. The first step is allowing web traffic to reach the Logstash VM.

If you’re using MikroTik RouterOS, you can use the following snippet to forward traffic from port 443 to Logstash’s port 5000:

1
/ip firewall nat
2
   add action=dst-nat \
3
   chain=dstnat \
4
   dst-port=443 \
5
   protocol=tcp \
6
   to-addresses=10.x.x.x to-ports=5000

Step 2: Install and Configure LogstashSection titled Step%202%3A%20Install%20and%20Configure%20Logstash

Install Logstash:

1
# Ubuntu/Debian
2
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | \
3
  sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
4
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | \
5
  sudo tee /etc/apt/sources.list.d/elastic-8.x.list
6
sudo apt update && sudo apt install logstash
7
sudo systemctl enable --now logstash

1
# RockyLinux/RHEL
2
sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
3
cat <<EOF | sudo tee /etc/yum.repos.d/elastic-8.x.repo
4
[elastic-8.x]
5
name=Elastic repository for 8.x packages
6
baseurl=https://artifacts.elastic.co/packages/8.x/yum
7
gpgcheck=1
8
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
9
enabled=1
10
autorefresh=1
11
type=rpm-md
12
EOF
13
sudo dnf install logstash
14
sudo systemctl enable --now logstash

Set up certificates:

1
sudo mkdir -p /etc/logstash/certs
2
sudo cp /path/to/zoho.yourdomain.com.crt /etc/logstash/certs/
3
sudo cp /path/to/zoho.yourdomain.com.key /etc/logstash/certs/
4
sudo chown logstash:logstash /etc/logstash/certs/*
5
sudo chmod 600 /etc/logstash/certs/*.key

Input

The input settings configure Logstash to listen on the specified port. Enabling SSL ensures the event data is encrypted during transmission, protecting it against interception.

1
input {
2
  http {
3
    port => 5000
4
    ssl_enabled => true
5
    ssl_certificate => "/etc/logstash/certs/zoho.yourdomain.com.crt"
6
    ssl_key => "/etc/logstash/certs/zoho.yourdomain.com.key"
7
    codec => json
8
    add_field => { "[@metadata][input_type]" => "zoho_webhook" }
9
    ecs_compatibility => disabled
10
  }
11
}

Note: In my testing, Zoho’s webhook only delivered events to ports 80 and 443 — attempts to use non-standard ports failed silently. I couldn’t find any documentation confirming this limitation, but the behavior was consistent enough that I ended up forwarding port 443 on the firewall to Logstash’s listener on port 5000. If you’re planning to run Logstash on a high port, expect to need either a NAT rule or a reverse proxy in front of it.

Filters

The filter validates the secret token, adds the "source": "zoho-mail" field for Wazuh decoder matching, normalizes timestamps from Unix milliseconds, and parses nested JSON strings (data and previousData fields) into structured objects.

1
filter {
2
  if [@metadata][input_type] == "zoho_webhook" {
3

4
    # ── Webhook authentication ──────────────────────────────────
5
    if [headers][x_zoho_webhook_token] != "YOUR_SECRET_TOKEN_HERE" {
6
      drop { }
7
    }
8

9
    # ── Source identifier (Wazuh decoder prematch) ──────────────
10
    mutate {
11
      add_field => {
12
        "source" => "zoho-mail"
13
        "[@metadata][beat]" => "zoho-mail"
14
      }
15
    }
16

17
    # ── Timestamp normalization ─────────────────────────────────
18
    if [requestTime] {
19
      date {
20
        match => ["requestTime", "UNIX_MS"]
21
        target => "@timestamp"
22
        timezone => "UTC"
23
      }
24
    }
25

26
    # ── Parse nested JSON strings ───────────────────────────────
27
    # Zoho sends data/previousData as JSON strings within the
28
    # payload. Wazuh's JSON_Decoder flattens these into dotted
29
    # fields (dataDetails.domain, previousDataDetails.mailid, etc.)
30
    # which the rules reference in descriptions.
31
    if [data] {
32
      json {
33
        source => "data"
34
        target => "dataDetails"
35
        skip_on_invalid_json => true
36
      }
37
    }
38

39
    if [previousData] {
40
      json {
41
        source => "previousData"
42
        target => "previousDataDetails"
43
        skip_on_invalid_json => true
44
      }
45
    }
46

47
    # ── GeoIP enrichment ────────────────────────────────────────
48
    if [clientIp] {
49
      geoip {
50
        source => "clientIp"
51
        target => "geoip"
52
      }
53
    }
54

55
    # ── Cleanup ─────────────────────────────────────────────────
56
    mutate {
57
      remove_field => ["headers", "host", "@version", "[event][original]", "data", "previousData"]
58
    }
59
  }
60
}

Replace x_zoho_webhook_token with your preferred header name and set your-secret-token-here to a strong, unique secret.

Output

Once Logstash finishes processing the incoming data and enriching it with tags and GeoIP information, the logs are written to disk.

1
output {
2
  if [@metadata][input_type] == "zoho_webhook" {
3
    file {
4
      path => "/var/log/logstash/zoho-mail.log"
5
      codec => json_lines
6
    }
7
  }
8
}

Create the log directory and test the configuration:

1
# these should already exist, in case they don't create them
2
sudo mkdir -p /var/log/logstash
3
sudo chown logstash:logstash /var/log/logstash
4

5
# Validate configuration
6
sudo /usr/share/logstash/bin/logstash \
7
  --config.test_and_exit -f /etc/logstash/conf.d/
8

9
sudo systemctl restart logstash
10

11
# Confirm it's listening
12
sudo ss -tlnp | grep 5000

Step 3: Configure Zoho Mail WebhooksSection titled Step%203%3A%20Configure%20Zoho%20Mail%20Webhooks

With the receiving infrastructure in place we now need to configure Zoho Mail Admin to send the event logs.

1. Log into the Zoho Mail Admin Console
2. Navigate to Other App Settings > SIEM > Security Information and Event Management (this feature is in beta at the time of writing — exact path may vary)
3. Click Webhooks and select the event categories you want (I chose all 43)
4. Name the webhook and select a data format (JSONArray or NDJSON)
5. Enter your webhook URL: https://your-logstash-domain.com
6. Configure the secret token and header name:
   • Customize the header name (e.g., X-Zoho-Webhook-Secret-Name-Token), this is the header name that Logstash will look for to validate that the data comes from Zoho
   • Set a strong random token (avoid characters that break HTTP headers)
7. Save — Zoho will send a validation token to your endpoint

Important: Check the Logstash logs for the validation token, similar to this: {"otp":"12345678"}. Zoho won’t activate the webhook until you input this code back into the Admin Console.

If the connection fails, verify the the DNS resolves to your Logstash VM, the certificate is valid and from a trusted CA, Logstash is listening on the correct port, and the secret token matches exactly.

Step 4: Configure Wazuh to Receive LogsSection titled Step%204%3A%20Configure%20Wazuh%20to%20Receive%20Logs

Install the agent on the Logstash VM and add to its configuration:

1
<ossec_config>
2
  <localfile>
3
    <log_format>json</log_format>
4
    <location>/var/log/logstash/zoho-mail.log</location>
5
  </localfile>
6
</ossec_config>

Step 5: Verify the PipelineSection titled Step%205%3A%20Verify%20the%20Pipeline

Check Logstash is receiving webhooks:

1
sudo tail -f /var/log/logstash/logstash-plain.log
2
sudo tail -f /var/log/logstash/zoho-mail.log

Trigger a test event by creating a new policy in the Zoho Mail Admin Console.

Verify Wazuh ingestion:

1
sudo tail -f /var/ossec/logs/ossec.log | grep zoho
2
sudo tail -f /var/ossec/logs/archives/archives.json | grep zoho-mail

Check the Wazuh Dashboard: Navigate to Explore > Discover, select the wazuh-archives-* index, and search for data.source:"zoho-mail".

If nothing appears: check for token validation failures in Logstash logs, verify agent connectivity, and review ossec.log for errors.

Step 6: Decoders and RulesSection titled Step%206%3A%20Decoders%20and%20Rules

1
{
2
  "source": "zoho-mail",
3
  "category": "ORGMAILPOLICY",
4
  "subCategory": "ORGMAILPOLICY_GENERAL",
5
  "operationType": "ADD",
6
  "operation": "ORG_MAILPOLICY_ADD",
7
  "mainCategory": "Email Policy",
8
  "performedBy": "[email protected]",
9
  "performedTime": "2025-07-15T09:23:41.000Z",
10
  "clientIp": "203.0.113.42",
11
  "dataDetails": {
12
    "policyName": "Restrict external forwarding",
13
    "associatedGroups": [],
14
    "associatedUsers": []
15
  }
16
}

1
<!-- Parent decoder — identifies Zoho Mail logs -->
2
<decoder name="zoho_mail_audit">
3
  <prematch>"source":"zoho-mail"</prematch>
4
</decoder>
5

6
<!-- JSON decoder — extracts all fields -->
7
<decoder name="zoho_mail_audit_json">
8
  <parent>zoho_mail_audit</parent>
9
  <plugin_decoder>JSON_Decoder</plugin_decoder>
10
</decoder>
11

12
<!-- Timestamp decoder -->
13
<decoder name="zoho_mail_audit_timestamp">
14
  <parent>zoho_mail_audit</parent>
15
  <regex type="pcre2">"eventTime":"(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{3})?Z?)"</regex>
16
  <order>event_timestamp</order>
17
</decoder>

1
sudo /var/ossec/bin/wazuh-logtest
2
# Paste a sample Zoho event and verify fields are extracted correctly

1
<group name="zoho_mail,">
2

3
  <!-- Base rule — all Zoho Mail events -->
4
  <rule id="120050" level="3">
5
    <field name="source">zoho-mail</field>
6
    <description>Zoho Mail: Audit event - $(mainCategory) - $(operation) by $(performedBy)</description>
7
    <group>zoho_mail,audit,</group>
8
    <options>no_full_log</options>
9
  </rule>
10

11
  <!-- Admin role assignment — privilege escalation (level 12, email alert) -->
12
  <rule id="120115" level="12">
13
    <if_sid>120050</if_sid>
14
    <field name="category">ROLES_AND_PREVILEGES</field>
15
    <field name="operationType">ADD</field>
16
    <description>Zoho Mail: Admin role '$(dataDetails.addedRole)' assigned to $(dataDetails.USERLIST) by $(performedBy) - ISO 27001:2022 A.8.2</description>
17
    <group>zoho_mail,user_lifecycle,privilege_escalation,audit,pci_dss_10.2.5,nist_800_53_AC.6,gdpr_IV_35.7.d,</group>
18
    <mitre><id>T1098.003</id></mitre>
19
    <options>alert_by_email</options>
20
  </rule>
21

22
  <!-- Shared mailbox access granted — data access monitoring -->
23
  <rule id="120140" level="10">
24
    <if_sid>120050</if_sid>
25
    <field name="category">SHAREDRESOURCES</field>
26
    <field name="subCategory">SHARE_MAILBOX</field>
27
    <field name="operationType">ADD</field>
28
    <description>Zoho Mail: Shared mailbox access GRANTED to $(dataDetails.userEmailId) by $(performedBy) - ISO 27001:2022 A.8.3</description>
29
    <group>zoho_mail,data_access,delegation_grant,audit,pci_dss_10.2.5,nist_800_53_AC.3,gdpr_IV_35.7.d,</group>
30
    <mitre><id>T1098</id></mitre>
31
    <options>no_full_log</options>
32
  </rule>
33

34
  <!-- Domain added — critical infrastructure change -->
35
  <rule id="120181" level="12">
36
    <if_sid>120050</if_sid>
37
    <field name="category">DOMAINS</field>
38
    <field name="operation">ORG_DOMAIN_ADD</field>
39
    <description>Zoho Mail: Domain $(dataDetails.domain) ADDED to organization by $(performedBy) from $(clientIp) - ISO 27001:2022 A.8.9</description>
40
    <group>zoho_mail,configuration,domain_management,critical,audit,pci_dss_10.2.5,nist_800_53_CM.3,gdpr_IV_35.7.d,</group>
41
    <mitre><id>T1584.001</id></mitre>
42
    <options>alert_by_email</options>
43
  </rule>
44

45
  <!-- Catch-all for unclassified events — ensures no blind spots -->
46
  <!--
47
    This rule fires for any Zoho Mail event that doesn't match a more specific rule above.
48
    It sits at the bottom intentionally: Wazuh evaluates child rules of 120050 and matches
49
    the most specific one first. If no specific rule matches, 120099 catches it at level 3.
50
    Review these hits regularly to identify categories that need dedicated rules.
51
  -->
52
  <rule id="120099" level="3">
53
    <if_sid>120050</if_sid>
54
    <description>Zoho Mail: Unclassified audit event - $(category) / $(subCategory) $(operationType) by $(performedBy)</description>
55
    <group>zoho_mail,audit,unclassified,</group>
56
    <options>no_full_log</options>
57
  </rule>
58

59
  <!-- Correlation: Multiple security controls removed within 5 minutes -->
60
  <rule id="120240" level="13" frequency="3" timeframe="300">
61
    <if_matched_group>security_degradation</if_matched_group>
62
    <description>Zoho Mail: ALERT - Multiple security controls removed within 5 minutes by $(performedBy) - Possible security tampering</description>
63
    <group>zoho_mail,correlation,security_degradation,critical,audit,</group>
64
    <mitre><id>T1562</id></mitre>
65
    <options>alert_by_email</options>
66
  </rule>
67

68
  <!-- Correlation: Multiple domain operations — possible domain takeover -->
69
  <rule id="120245" level="14" frequency="2" timeframe="600">
70
    <if_matched_group>domain_management</if_matched_group>
71
    <description>Zoho Mail: CRITICAL - Multiple domain management operations within 10 minutes - Possible domain takeover</description>
72
    <group>zoho_mail,correlation,domain_takeover,critical,audit,</group>
73
    <mitre><id>T1584.001</id></mitre>
74
    <options>alert_by_email</options>
75
  </rule>
76

77
</group>

Compliance MappingSection titled Compliance%20Mapping

Every administrative action is logged with who, what, when, and from where — providing the audit trails, access accountability, change management records, and data protection evidence that auditors expect.

Testing & ValidationSection titled Testing%20%26%20Validation

Generate test events by performing admin actions in Zoho: create a test user, assign an admin role, set up a forwarding rule, export a mailbox, modify a retention policy.

Watch alerts in real-time:

1
sudo tail -f /var/ossec/logs/alerts/alerts.json | jq 'select(.rule.groups[] | contains("zoho"))'

In the Wazuh Dashboard, navigate to Threat Hunting > Events and filter by rule.groups: zoho_mail. Verify each test event triggered the correct rule at the appropriate severity, then fine-tune thresholds and correlation timeframes to match your risk appetite.

TroubleshootingSection titled Troubleshooting

Zoho’s OTP validation times out: After saving the webhook in the Zoho Admin Console, Zoho sends a one-time validation code to your endpoint. You have a limited window (typically a few minutes) to paste it back. If you miss it, refresh the page, go to Webhook and click Validate. Before retrying, confirm Logstash is actually receiving requests by watching the Logstash log:

1
sudo tail -f /var/log/logstash/logstash-plain.log

Certificate chain issues: Zoho’s webhook client validates the full certificate chain. If you’re using Let’s Encrypt, make sure you’re providing the full chain file (fullchain.pem), not just the certificate.

Events appear in Logstash logs but not in Wazuh: Check these in order: the Wazuh agent is running on the Logstash VM (systemctl status wazuh-agent), the localfile configuration in agent.conf points to the correct log path, and the agent has restarted since you added the configuration. Then check ossec.log for file monitoring errors.

Fields don’t match in rules: Zoho’s payload field names are case-sensitive and occasionally inconsistent (note ROLES_AND_PREVILEGES — that’s Zoho’s spelling, not a typo in the rules). If a rule isn’t matching, paste a raw event into wazuh-logtest and compare the extracted field names against what your rule expects. The most common issue is referencing dataDetails.fieldName when the field is actually nested differently.

Alerts fire in wazuh-logtest but not in production: Usually a rule ordering issue. If a general rule (like 120122 for MAILGROUP) matches before your specific rule, the specific rule never fires. Check rule order in the file and confirm with wazuh-logtest using the verbose flag (-v).

What This Integration Doesn’t CoverSection titled What%20This%20Integration%20Doesn%u2019t%20Cover

This integration focuses on administrative audit logs pushed via Zoho’s SIEM webhook. There are several adjacent areas it doesn’t address, each of which could be a future extension:

• Historical log backfill — Zoho’s webhook only sends events going forward. If you need historical data, you’d need to build a separate collector against Zoho’s Admin Audit API.
• Zoho Workplace logs beyond Mail — Zoho Docs, Zoho Connect, and other Workplace apps have their own audit events that aren’t included in the Mail SIEM webhook.
• End-user mailbox activity — These are admin audit logs, not user activity logs. Individual user actions (reading emails, creating filters) aren’t captured here.
• Multi-organization setups — If you manage multiple Zoho organizations, each one needs its own webhook. The rules work as-is, but you’d want to add orgId-based filtering to distinguish between orgs in your alerts.

Next StepsSection titled Next%20Steps

With the pipeline operational, consider: scheduled compliance reports, ITSM integration for high-severity alerts, cross-source correlation with AD/VPN/EDR logs, and quarterly rule tuning as Zoho evolves its webhook format.

ConclusionSection titled Conclusion

This integration gives you real-time visibility into Zoho Mail admin actions — user lifecycle changes, mailbox delegation, domain modifications, and policy updates — with events mapped to ISO 27001 controls and flowing through a hardened, isolated pipeline into Wazuh.

The detection rules included here cover the security relevant categories, but they’re a starting point. Your environment will have its own risk profile: you might need tighter correlation windows, additional rules for categories currently on the catch-all, or custom severity levels based on which admin roles are most sensitive in your organization. The catch-all rule (120099) is there specifically so nothing slips through silently while you iterate.

If you’re running this in production, I’d recommend two things early on: enable alert_by_email on rules 120115 (admin role assignment) and 120181 (domain additions) which are some of the highest-impact events, and review your catch-all hits weekly for the first month to identify patterns worth promoting to dedicated rules.

The full ruleset, Logstash configuration, and compliance mapping documentation are on GitHub. If you’ve extended the rules or found edge cases in Zoho’s payload format, I’d welcome contributions — or just drop a note about what worked and what didn’t.