disk space reduction, rule fixes, and dashboard query alignment

- wazuh_manager.conf: disable logall_json (was 14 GB of archives.json growth);
  add log rotation block (daily, 7-day retention, compressed)
- OpenSearch ISM policy applied externally (wazuh-alerts-* / wazuh-archives-*,
  delete after 30d)
- soc-a2/a3/a4, soc-c1-c3 rules: fix if_sid chaining (if_group=fortigate broken
  in Wazuh 4.x), add production profile rules (110xxx range), align with real
  archive field names (srccountry, dstport, logonType, etc.)
- local_decoder.xml: decoder updates to support new field extractions
- appendix-c dashboard: fix query rule.id:1005* → rule.groups: appendix_c
  (old query matched simulation IDs only, returned nothing for prod rules)
- appendix-ab dashboard: narrow query soc_prod* → appendix_a OR appendix_b
  (excludes C1/C2/C3 rules from A+B panels)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

wazuh-docker/single-node/config/wazuh_cluster/local_decoder.xml

@@ -2,8 +2,36 @@
   SOC custom decoders (production-focused baseline)
   - Decodes real correlation payloads produced by SOC Integrator
   - Decodes real DNS IOC payloads
+  - Decodes modern ESXi 7/8 syslog format (groups: vmware)
 -->
 
+<!--
+  Modern VMware ESXi / vCenter syslog decoder
+  Matches ESXi 7.x and 8.x syslog output (built-in vmware decoder only handles old ESX 4.x format).
+
+  How if_group=vmware works: rule 19100 (decoded_as vmware) fires first and places the event in
+  the vmware group. Our B1 rules then match via if_group=vmware.
+  To hook into this chain, our decoder must also be NAMED "vmware" (Wazuh allows multiple
+  decoders with the same name — they are evaluated in order).
+
+  ESXi 7.x format:  <ISO-TS> <HOSTNAME> <PROCESS>: <SEV> <proc[pid]> [<meta>] <msg>
+  ESXi 8.x format:  <ISO-TS> <HOSTNAME> <process[pid]>: [<sev>] <msg>
+
+  Known process names seen from FPVM70-H1/H2 (ESXi 7) and ESXi 8.0:
+    Hostd, Vpxa, Rhttpproxy, vmkernel, vmkwarning, healthd, healthdPlugins,
+    hostd-probe, net-cdp, vdtc, envoy-access, fdm, kmxa, sandboxd, crond
+-->
+<decoder name="vmware">
+  <program_name type="pcre2">(?i)^(Hostd|Vpxa|Rhttpproxy|vmkernel|vmkwarning|vmkdump|healthd|healthdPlugins|hostd-probe|net-cdp|vdtc|envoy-access|fdm|kmxa|sandboxd|vpxd|dcui|crond|ImageConfigManager|sysboot|sfcb|vsanmgmtd)$</program_name>
+</decoder>
+
+<decoder name="vmware-esxi-severity">
+  <parent>vmware</parent>
+  <prematch type="pcre2">^(?:verbose|info|warning|error|critical|debug) </prematch>
+  <regex type="pcre2">^(verbose|info|warning|error|critical|debug)</regex>
+  <order>status</order>
+</decoder>
+
 <decoder name="soc-prod-dns">
   <prematch>soc_event=dns_ioc</prematch>
   <regex type="pcre2">event_type=(\S+)(?:.*?src_ip=([\d.]+))?</regex>

wazuh-docker/single-node/config/wazuh_cluster/rules/soc-a2-fortigate-fw-rules.xml

@@ -1,110 +1,136 @@
 <!--
   SOC Proposal Rules — Appendix A2: FortiGate IPS/IDS & Firewall
-  Simulation profile rule IDs : 100311-100320
   Production profile rule IDs : 110311-110320
 
   Severity mapping:
     High   → level 12
     Medium → level 8
     Low    → level 5
+
+  Parent SID reference (built-in Wazuh FortiGate rules):
+    81603 — Fortigate messages grouped (universal FortiGate base)
+    81606 — Fortigate: Login failed  (action=login status=failed)
+    81608 — Fortigate: Configuration changed (Configuration is changed in the admin session)
+    81612 — Fortigate: Firewall configuration changes (action=Edit, type=event)
+    81618 — Fortigate: Traffic to be aware of (type=traffic)
+    81622 — Fortigate: VPN user connected (action=tunnel-up)
+    81628 — Fortigate attack detected
+    81629 — Fortigate attack dropped
+
+  Fix history:
+    2026-03-19: Changed all if_group=fortigate → if_sid=81603/81618/81628/81629
+                if_group=fortigate does not chain rules correctly in Wazuh 4.x;
+                correct approach is if_sid pointing to a built-in parent rule.
+    2026-03-20: Changed 110311/110320 from if_sid=81618 → if_sid=81603 with explicit
+                type=traffic match. Wazuh 4.x does not evaluate grandchild if_sid chains
+                (81603 → 81618 → 110311 fails); sibling pattern (81603 → 110311) works.
 -->
 <group name="soc_mvp,appendix_a,a2,fortigate,">
 
-  <!-- ── Simulation profile ── -->
-
-
-
-
-
-
-
-
-
-
-
-  <!-- ── Production profile (if_group=fortigate, no soc_mvp_test required) ── -->
-
+  <!-- A2-01: RDP traffic allowed through firewall
+       Parent: 81603 (FortiGate base — NOT 81618 to avoid 3-level chain depth limit)
+       81618 uses if_sid=81603; chaining from 81618 creates a 3-level chain that
+       Wazuh 4.x does not evaluate. Use sibling pattern: if_sid=81603 + type=traffic.
+       Real data: dstport=3389, action="accept" confirmed in archives -->
   <rule id="110311" level="12">
-    <if_group>fortigate</if_group>
+    <if_sid>81603</if_sid>
+    <match>type="traffic"|type=traffic</match>
     <match>dstport=3389</match>
-    <match>action="accept"</match>
+    <match>action="accept"|action=accept</match>
     <description>A2-01 [PROD] FortiGate: RDP (3389) traffic allowed</description>
     <group>soc_prod,a2,rdp,</group>
     <mitre><id>T1021.001</id></mitre>
   </rule>
 
+  <!-- A2-02: Admin password changed
+       Parent: 81603 (generic base — admin events vary by FW model/version)
+       FortiGate logs action="password-change" under type=event subtype=system -->
   <rule id="110312" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="password-change"</match>
+    <if_sid>81603</if_sid>
+    <match>action="password-change"|action=password-change</match>
     <description>A2-02 [PROD] FortiGate: admin account password changed</description>
     <group>soc_prod,a2,admin_change,</group>
     <mitre><id>T1098</id></mitre>
   </rule>
 
+  <!-- A2-03: New admin account created
+       Parent: 81603 (generic base) -->
   <rule id="110313" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="create-admin"</match>
+    <if_sid>81603</if_sid>
+    <match>action="create-admin"|action=create-admin</match>
     <description>A2-03 [PROD] FortiGate: new admin account created</description>
     <group>soc_prod,a2,admin_change,</group>
     <mitre><id>T1136</id></mitre>
   </rule>
 
+  <!-- A2-04: Alerting/notification disabled via config change
+       Parent: 81608 (Configuration changed) or 81612 (Firewall config changes) -->
   <rule id="110314" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="config-change"</match>
-    <match>config_value=disable</match>
+    <if_sid>81608, 81612</if_sid>
+    <match>config_value=disable|"disable"</match>
     <description>A2-04 [PROD] FortiGate: alerting/notification disabled via config change</description>
     <group>soc_prod,a2,defense_evasion,</group>
     <mitre><id>T1562</id></mitre>
   </rule>
 
+  <!-- A2-05: Firewall configuration file downloaded
+       Parent: 81603 (generic base) -->
   <rule id="110315" level="5">
-    <if_group>fortigate</if_group>
-    <match>action="download-config"</match>
+    <if_sid>81603</if_sid>
+    <match>action="download-config"|action=download-config</match>
     <description>A2-05 [PROD] FortiGate: firewall configuration file downloaded</description>
     <group>soc_prod,a2,config,</group>
     <mitre><id>T1005</id></mitre>
   </rule>
 
+  <!-- A2-06: Multiple critical/high IPS signatures triggered
+       Parent: 81628 (attack detected) or 81629 (attack dropped)
+       Note: requires FortiGate IPS UTM logs to be forwarded -->
   <rule id="110316" level="8">
-    <if_group>fortigate</if_group>
-    <match>subtype="ips"</match>
-    <match>attack="Multiple.Critical</match>
-    <description>A2-06 [PROD] FortiGate IPS: multiple critical signatures triggered</description>
+    <if_sid>81628, 81629</if_sid>
+    <match>severity="critical"|severity="high"|severity=critical|severity=high</match>
+    <description>A2-06 [PROD] FortiGate IPS: critical/high attack signature triggered</description>
     <group>soc_prod,a2,ips,</group>
     <mitre><id>T1595</id></mitre>
   </rule>
 
+  <!-- A2-07: TCP port scan from external IP
+       Parent: 81628 or 81629 (IPS/anomaly attack events)
+       Note: requires FortiGate anomaly detection to be enabled -->
   <rule id="110317" level="5">
-    <if_group>fortigate</if_group>
-    <match>subtype="anomaly"</match>
-    <match>attack="TCP.Port.Scan"</match>
+    <if_sid>81628, 81629</if_sid>
+    <match>attack="TCP.Port.Scan"|TCP.Port.Scan</match>
     <description>A2-07 [PROD] FortiGate: TCP port scan from external IP</description>
     <group>soc_prod,a2,recon,</group>
     <mitre><id>T1046</id></mitre>
   </rule>
 
+  <!-- A2-08: IOC-based IP detection via IPS
+       Parent: 81628 or 81629 -->
   <rule id="110318" level="8">
-    <if_group>fortigate</if_group>
-    <match>subtype="ips"</match>
-    <match>ioc_type=ip</match>
+    <if_sid>81628, 81629</if_sid>
+    <match>ioc_type=ip|ioc_type="ip"</match>
     <description>A2-08 [PROD] FortiGate IPS: IOC-based IP indicator detected</description>
     <group>soc_prod,a2,ioc,</group>
     <mitre><id>T1071.001</id></mitre>
   </rule>
 
+  <!-- A2-09: Internal port scan from private source IP
+       Parent: 81628 or 81629 -->
   <rule id="110319" level="8">
-    <if_group>fortigate</if_group>
-    <match>subtype="anomaly"</match>
-    <match>attack="Internal.Port.Scan"</match>
+    <if_sid>81628, 81629</if_sid>
+    <match>attack="Internal.Port.Scan"|Internal.Port.Scan</match>
     <description>A2-09 [PROD] FortiGate: internal port scan from private source IP</description>
     <group>soc_prod,a2,recon,</group>
     <mitre><id>T1046</id></mitre>
   </rule>
 
+  <!-- A2-10: Traffic to known C2/malicious IP
+       Parent: 81603 (FortiGate base — sibling pattern, same fix as 110311) -->
   <rule id="110320" level="8">
-    <if_group>fortigate</if_group>
-    <match>threat_label="known-c2"</match>
+    <if_sid>81603</if_sid>
+    <match>type="traffic"|type=traffic</match>
+    <match>threat_label="known-c2"|threat_label=known-c2</match>
     <description>A2-10 [PROD] FortiGate: traffic to known C2/malicious IP allowed</description>
     <group>soc_prod,a2,ioc,c2,</group>
     <mitre><id>T1071.001</id></mitre>

wazuh-docker/single-node/config/wazuh_cluster/rules/soc-a3-fortigate-vpn-rules.xml

@@ -1,64 +1,84 @@
 <!--
   SOC Proposal Rules — Appendix A3: FortiGate VPN
-  Simulation profile rule IDs : 100331-100335
   Production profile rule IDs : 110331-110335
 
   Severity mapping:
     High → level 12
     Low  → level 5
--->
-<group name="soc_mvp,appendix_a,a3,vpn,fortigate,">
-
-  <!-- ── Simulation profile ── -->
-
 
+  Environment: FoodProject uses IPsec site-to-site VPN (IKEv1/IKEv2) and L2TP.
+  No SSL-VPN (FortiClient) traffic observed in archives as of 2026-03-20.
 
+  IPsec VPN parent SIDs (built-in Wazuh):
+    81622 — Fortigate: VPN user connected (action=tunnel-up, level=information)
+    81624 — Fortigate: VPN user disconnected
+    81636 — Fortigate: VPN related information (type=event subtype=vpn level=notice)
+    81637 — Fortigate: VPN related error   (type=event subtype=vpn level=error)
+    81614 — Fortigate: SSL VPN user failed login (ssl-login-fail) — kept for SSL-VPN if enabled
 
+  SSL-VPN rules (110331-110334) are retained but require SSL-VPN to be enabled on FortiGate.
+  IPsec/L2TP rules (110335) adapted to match actual tunnel-up events with srccountry != Thailand.
+  Field: srccountry (decoded as root-level field, NOT data.srccountry)
 
+  Fix history:
+    2026-03-19: Changed if_group=fortigate → if_sid; adapted A3-05 for IPsec tunnel-up
+-->
+<group name="soc_mvp,appendix_a,a3,vpn,fortigate,">
 
-  <!-- ── Production profile (if_group=fortigate) ── -->
-
+  <!-- A3-01: VPN authentication success by guest account (SSL-VPN)
+       Requires SSL-VPN to be enabled on FortiGate.
+       Parent: 81603 (generic base — ssl-login-success is in the raw log) -->
   <rule id="110331" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-success"</match>
-    <match>user="guest"</match>
-    <description>A3-01 [PROD] VPN authentication success by guest account</description>
+    <if_sid>81603</if_sid>
+    <match>ssl-login-success</match>
+    <match>user="guest"|user=guest</match>
+    <description>A3-01 [PROD] SSL-VPN: authentication success by guest account</description>
     <group>soc_prod,a3,vpn_guest,</group>
     <mitre><id>T1078.001</id></mitre>
   </rule>
 
+  <!-- A3-02: SSL-VPN success from different country than last login
+       Requires SSL-VPN and FortiGate geo-login tracking -->
   <rule id="110332" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-success"</match>
+    <if_sid>81603</if_sid>
+    <match>ssl-login-success</match>
     <match>previous_country=</match>
-    <description>A3-02 [PROD] VPN success from different country than last login</description>
+    <description>A3-02 [PROD] SSL-VPN: success from different country than last login</description>
     <group>soc_prod,a3,vpn_geo,</group>
     <mitre><id>T1078</id></mitre>
   </rule>
 
+  <!-- A3-03: SSL-VPN success after prior failures (brute-force indicator)
+       Requires SSL-VPN -->
   <rule id="110333" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-success"</match>
+    <if_sid>81603</if_sid>
+    <match>ssl-login-success</match>
     <match>failed_attempts_before_success=</match>
-    <description>A3-03 [PROD] VPN success after multiple prior failures (brute-force indicator)</description>
+    <description>A3-03 [PROD] SSL-VPN: success after multiple prior failures (brute-force indicator)</description>
     <group>soc_prod,a3,vpn_bruteforce,</group>
     <mitre><id>T1110.001</id></mitre>
   </rule>
 
+  <!-- A3-04: SSL-VPN multiple account failures from single source IP
+       Parent: 81614 (Fortigate: SSL VPN user failed login attempt)
+       Requires SSL-VPN -->
   <rule id="110334" level="5">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-fail"</match>
-    <match>failed_accounts=</match>
-    <description>A3-04 [PROD] VPN multiple account failures from single source IP</description>
+    <if_sid>81614</if_sid>
+    <description>A3-04 [PROD] SSL-VPN: authentication failure (multiple accounts from 1 source)</description>
     <group>soc_prod,a3,vpn_bruteforce,</group>
     <mitre><id>T1110.003</id></mitre>
   </rule>
 
-  <rule id="110335" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-success"</match>
-    <match>expected_country=TH</match>
-    <description>A3-05 [PROD] VPN authentication success from outside Thailand</description>
+  <!-- A3-05: VPN tunnel connected from outside Thailand (IPsec + SSL-VPN)
+       Parent: 81622 (VPN user connected / action=tunnel-up level=information)
+       Real data confirmed: srccountry field present in VPN events
+       Fires when IPsec tunnel-up occurs from srccountry != Thailand (Reserved = private/RFC1918)
+       Level 13 (> C1 rule 110501 level 12) so this more-specific rule takes priority
+       when both conditions are met. Both rules share if_sid=81622. -->
+  <rule id="110335" level="13">
+    <if_sid>81622</if_sid>
+    <field name="srccountry" negate="yes" type="pcre2">^Thailand$|^Reserved$</field>
+    <description>A3-05 [PROD] VPN: tunnel connected from outside Thailand</description>
     <group>soc_prod,a3,vpn_geo,</group>
     <mitre><id>T1078</id></mitre>
   </rule>

wazuh-docker/single-node/config/wazuh_cluster/rules/soc-a4-windows-ad-rules.xml

@@ -10,7 +10,13 @@
     60109       → events 4720/4722 (account create/enable)
     60113       → events 4728/4732 (group membership change)
     67027       → event 4688 (new process created)
-    60103       → event 4794 (DSRM password set)
+    60103       → event 4794 (DSRM password set) — must add eventID=4794 constraint!
+    67017       → event 5140 (network share access, non-IPC$)
+    60103       → event 4771 (Kerberos pre-auth failure) — constrained with eventID field
+
+  Real event volumes observed (2026-03-20):
+    4624: 209K | 4625: 1.5K | 4688: 138K | 5140: 26K | 4776: 25K
+    4771: 281  | 4648: 6K   | 4740: 7
 -->
 <group name="soc_mvp,appendix_a,a4,windows,">
 
@@ -163,7 +169,43 @@
     <mitre><id>T1078</id></mitre>
   </rule>
 
-  <!-- ── Production normalized key=value path (soc-mvp production profile) ── -->
+  <!-- A4-05: Network share access (file share enumeration / lateral movement)
+       Event 5140 — A network share object was accessed
+       Parent: 67017 (WEF baseline: network share accessed, non-IPC$/NetLogon)
+       Real data: 26,202 events/day observed; admin shares (D$, C$, ADMIN$) accessed by
+       both machine accounts ($) and user accounts — alert on user accounts accessing admin shares.
+       Excludes machine accounts (ending in $) to reduce service/replication noise. -->
+  <rule id="110355" level="8">
+    <if_sid>67017</if_sid>
+    <field name="win.eventdata.shareName" type="pcre2">(?i)\\\\[A-Z]\$|\\\\ADMIN\$|\\\\C\$|\\\\D\$|\\\\E\$</field>
+    <field name="win.eventdata.subjectUserName" negate="yes" type="pcre2">\$$</field>
+    <description>A4-05 [PROD] Windows: user account accessing admin share (5140) — lateral movement indicator</description>
+    <group>soc_prod,a4,lateral_movement,share,</group>
+    <mitre><id>T1021.002</id></mitre>
+  </rule>
 
+  <!-- A4 (supplemental): Kerberos pre-authentication failure (event 4771)
+       Event 4771 — Kerberos pre-authentication failed (similar to 4625 but Kerberos-specific)
+       Parent: 60103 (Windows audit success — constrained to eventID 4771)
+       Real data: 281 events observed; status=0x18 = bad password
+       Note: Wazuh has no dedicated built-in parent for 4771 in the base ruleset. -->
+  <rule id="110356" level="5">
+    <if_sid>60103</if_sid>
+    <field name="win.system.eventID">^4771$</field>
+    <description>A4-supplemental [PROD] Windows: Kerberos pre-authentication failure (4771)</description>
+    <group>soc_prod,a4,auth_fail,kerberos,</group>
+    <mitre><id>T1110.001</id></mitre>
+  </rule>
+
+  <!-- A4 (supplemental): Account lockout (event 4740)
+       Parent: 60103 (Windows audit events — constrained to eventID 4740)
+       Real data: 7 events observed — indicates repeated auth failures triggering lockout policy -->
+  <rule id="110357" level="8">
+    <if_sid>60103</if_sid>
+    <field name="win.system.eventID">^4740$</field>
+    <description>A4-supplemental [PROD] Windows: user account locked out (4740)</description>
+    <group>soc_prod,a4,auth_fail,lockout,</group>
+    <mitre><id>T1110.001</id></mitre>
+  </rule>
 
 </group>

wazuh-docker/single-node/config/wazuh_cluster/rules/soc-c1-c3-rules.xml

@@ -7,7 +7,9 @@
   Simulation profile rule IDs : 100501, 100511-100514, 100521-100524
   Production profile rule IDs : 110501, 110502, 110511-110514, 110521-110524
 
-  C1 prod: if_group=fortigate (VPN) or if_sid=100260 (soc-integrator)
+  C1 prod: if_sid=81622 (VPN tunnel-up / user connected) or if_sid=100260 (soc-integrator)
+           Environment uses IPsec site-to-site VPN (no SSL-VPN observed in archives 2026-03-20)
+           if_group=fortigate was broken in Wazuh 4.x → fixed to if_sid
   C2/C3 prod: specific built-in Wazuh SIDs to avoid N×M explosion:
     60106 → event 4624 (auth success / logon)
     60113 → events 4728/4732 (group membership change)
@@ -19,10 +21,15 @@
        ================================================================ -->
 
 
+  <!-- C1-01 VPN candidate: fires on every VPN tunnel-up (IPsec) or SSL-VPN success
+       Parent: 81622 (Fortigate: VPN user connected / action=tunnel-up)
+       The srccountry field is present in real VPN events; soc-integrator handles
+       geo correlation and emits c1_impossible_travel to trigger rule 110502.
+       Fix 2026-03-19: if_group=fortigate broken → if_sid=81622;
+                       action="ssl-login-success" → IPsec tunnel-up via 81622 -->
   <rule id="110501" level="12">
-    <if_group>fortigate</if_group>
-    <match>action="ssl-login-success"</match>
-    <description>C1-01 [PROD] VPN login success with geo context — impossible travel candidate</description>
+    <if_sid>81622</if_sid>
+    <description>C1-01 [PROD] VPN tunnel connected — impossible travel geo candidate</description>
     <group>soc_prod,c1,impossible_travel,identity,</group>
     <mitre><id>T1078</id></mitre>
   </rule>

wazuh-docker/single-node/config/wazuh_cluster/wazuh_manager.conf

@@ -3,7 +3,7 @@
     <jsonout_output>yes</jsonout_output>
     <alerts_log>yes</alerts_log>
     <logall>yes</logall>
-    <logall_json>yes</logall_json>
+    <logall_json>no</logall_json>
     <email_notification>no</email_notification>
     <smtp_server>smtp.example.wazuh.com</smtp_server>
     <email_from>wazuh@example.wazuh.com</email_from>
@@ -22,6 +22,13 @@
   <!-- Choose between "plain", "json", or "plain,json" for the format of internal logs -->
   <logging>
     <log_format>plain</log_format>
+    <rotation>
+      <enabled>yes</enabled>
+      <max_size>500M</max_size>
+      <interval>1d</interval>
+      <compress>yes</compress>
+      <saved>7</saved>
+    </rotation>
   </logging>
 
   <remote>