Decoding a Zimbra Log

[Giovanni Sciacca]

Hi,
I am trying to create a custom decoder for a Zimbra log, but I am having an issue with how Wazuh decodes the log line.

I am using the following custom decoder:

<decoder name="zimbra_full">

  <prematch type="pcre2">^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d+)\s+(\w+)\s+\[</prematch>

  <regex type="pcre2">^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d+)\s+(\w+)\s+\[([^\:]+):(https\:\/\/[^\]]+)\]\s+\[name=([^;]+);ip=([^;]+);port=([^;]+);ua=([^;]+);.*?EWSOperation=([^;]+);Folder=([^;]+);EwsClientReqSyncState=([^;]+);EwsClientRespSyncState=([^;]+);.*?\]\s+[^\-]*-\s+(.*)$</regex>

  <order>log_timestamp,level,thread,url,name,ip,port,ua,ewsoperation,folder,ewsclientreqsyncstate,ewsclientrespsyncstate,message</order>

</decoder>

And this is the sample log line:

2026-06-17 00:00:38,826 INFO  [qtpNNNNNN-NNNN:https://zimbra.customtest.it/ews/Exchange.asmx] [name=te...@domain.com;ip=XX.XX.XX.XX;port=XXXXX;ua=AppleExchangeWebServices/AddressBookSourceSync/;EWSOperation=syncFolderItem;Folder=7;EwsClientReqSyncState={XXXXX}0;EwsClientRespSyncState={XXXXX}0;] ews - End syncFolderItem: 19

In the Wazuh UI, it looks like the decoding stops right after https:, and I am trying to understand why this happens.

My suspicion is that the issue may be related to how the regex handles the section:

[qtpNNNNNN-NNNN:https://zimbra.customtest.it/ews/Exchange.asmx]

especially because the thread name and URL are both inside the same brackets and separated by a colon.

Has anyone experienced something similar, or can anyone help me understand why Wazuh stops parsing after https:?

Any help would be greatly appreciated. Thanks in advance.

[Olamilekan Abdullateef Ajani]

Hello Sciacca,

I tested this, and the issue appears to be with the regex being too strict towards the https:// portion itself. The URL and thread fields can be extracted successfully. In my testing, the decoder worked once the child regex was simplified to start at the first bracketed section ([thread:url]) instead of matching the entire log line from the timestamp, the actual log from my test seems to begin from there based on the log you shared. Also note that timestamp has already been predecoded, so you can focus the custom decoder on the application-specific payload rather than the full log line. This also makes the decoder more tolerant of formatting changes such as additional spaces or different log levels.

Decoder I used:

<decoder name="zimbra-test">
  <prematch type="pcre2">https://zimbra\.</prematch>
</decoder>

<decoder name="zimbra-2">
  <parent>zimbra-test</parent>
  <regex type="pcre2">\[([^:]+):(https?://[^\]]+)\]\s+\[name=([^;]+);ip=([^;]+);port=([^;]+);ua=([^;]+);EWSOperation=([^;]+);Folder=([^;]+);EwsClientReqSyncState=([^;]+);EwsClientRespSyncState=([^;]+);\]\s+(\S+)\s+-\s+(.*)$</regex>
  <order>thread,url,user,srcip,srcport,user_agent,ews_operation,folder,ews_client_req_sync_state,ews_client_resp_sync_state,service,message</order>
</decoder>

Kindly refer to the screenshot for test results, and please let me know if you require further assistance on this.