Wazuh custom rules / decoders not triggering ?

193 views
Skip to first unread message

Adrien Di Cristofaro

unread,
Aug 28, 2025, 7:55:14 AMAug 28
to Wazuh | Mailing List
Hello,

I've started to implement a Pulse Secure (Ivanti) Sylog Integration on our Wazuh server.

Here's my decoders : 

<decoder name="pulsesecure_host_checker_compliance">
  <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* - Host Checker Compliance Result</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) - Host Checker Compliance Result - (.*) on host (.*) from address (.*) for user (.*), passed_hc_policies:(.*), failed_hc_policies:(.*), failed_reasons: (.*).</regex>
  <order>timestamp,scrInfo,compliance,hostip,srcmac,srcuser,passed_policies,failed_policies,failed_reasons</order>
</decoder>

<decoder name="pulsesecure_passed_policy">
  <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* - Host Checker policy .* passed on host</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) - Host Checker policy (.*) passed on host (.*) address (.*) for user (.*)</regex>
  <order>timestamp,scrInfo,policy,hostip,srcmac,srcuser</order>
</decoder>

<decoder name="pulsesecure_failed_policy">
   <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* - Host Checker policy .* failed on host</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) - Host Checker policy (.*) failed on host (.*) address (.*) for user (.*) reason (.*)</regex>
  <order>timestamp,scrInfo,policy,hostip,srcmac,srcuser,reason</order>
</decoder>

<decoder name="pulsesecure_web_request">
  <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* .* - WebRequest completed</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) (.*) - WebRequest completed, (.*)</regex>
  <order>timestamp,scrInfo,srcuser,webrequest</order>
</decoder>

<decoder name="pulsesecure_web_request_ok">
  <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* .* - WebRequest ok</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) (.*) - WebRequest ok (.*)</regex>
  <order>timestamp,scrInfo,srcuser,webrequest</order>
</decoder>

<decoder name="pulsesecure_unauthenticated_request">
  <prematch type="pcre2">PulseSecure: - - - .* - vpn - .* .* - Unauthenticated request url</prematch>
  <regex type="pcre2">PulseSecure: - - - (.*) - vpn - (.*) (.*) - Unauthenticated request url (.*)</regex>
  <order>timestamp,scrInfo,srcuser,webrequest</order>
</decoder>

<decoder name="pulsesecure_default">
  <prematch type="pcre2">PulseSecure: .*</prematch>
  <regex type="pcre2">PulseSecure: (.*)</regex>
  <order>default</order>
</decoder>



Here's my rules :


<group name="Pulse Secure Info">
 
  <rule id="100021" level="3">
    <decoded_as>pulsesecure_host_checker_compliance</decoded_as>
    <description>Pulse Secure log — TimeStamp: $(timestamp), UserInfo: $(scrInfo), Compliance: $(compliance), IP: $(hostip), Mac: $(srcmac), User: $(srcuser), passedPolicies: $(passed_policies), failedPolicies: $(failed_policies), failedReasons: $(failed_reasons)</description>
  </rule>
 
  <rule id="100022" level="3">
    <decoded_as>pulsesecure_passed_policy</decoded_as>
    <description>Pulse Secure Passed Policy — TimeStamp: $(timestamp), UserInfo: $(scrInfo), Host Checker Policy: $(policy), IP: $(hostip), Mac: $(srcmac), User: $(srcuser)</description>
  </rule>
 
  <rule id="100023" level="5">
    <decoded_as>pulsesecure_failed_policy</decoded_as>
    <description>Pulse Secure Failed Policy — TimeStamp: $(timestamp), UserInfo: $(scrInfo), Host Checker Policy: $(policy), IP: $(hostip), Mac: $(srcmac), User: $(srcuser), Reasons: $(reason)</description>
  </rule>
 
  <rule id="100024" level="3">
    <decoded_as>pulsesecure_web_request</decoded_as>
    <description>Pulse Secure Web Request — TimeStamp: $(timestamp), UserInfo: $(scrInfo), User: $(srcuser), WebRequest: $(webrequest)</description>
  </rule>
 
  <rule id="100025" level="3">
    <decoded_as>pulsesecure_web_request_ok</decoded_as>
    <description>Pulse Secure Web Request OK — TimeStamp: $(timestamp), UserInfo: $(scrInfo), User: $(srcuser), WebRequest: $(webrequest)</description>
  </rule>
 
   <rule id="100026" level="5">
    <decoded_as>pulsesecure_unauthenticated_request</decoded_as>
    <description>Pulse Secure Unanthenticated Request — TimeStamp: $(timestamp), UserInfo: $(scrInfo), User: $(srcuser), WebRequest: $(webrequest)</description>
  </rule>
 
  <rule id="100030" level="3">
    <decoded_as>pulsesecure_default</decoded_as>
    <description>Pulse Secure Default Log : $(default)</description>
  </rule>
 
</group>




Problem is that all rules except 100030 is not working.

When i use the wazuh log tester on CLI, decoders and rules seems to work.
When i test decoder / rules on the GUI, they seems to work too.


But there is not 100021 -> 100026 Triggered on the alerts in the dashboard.
There is a lot of 100030 alerts triggered, often when there isn't a specific decoder for the PulseSecure event.

What am I missing ?

BR,

Adrien

Adrien Di Cristofaro

unread,
Sep 9, 2025, 8:42:38 AMSep 9
to Wazuh | Mailing List
Up :)

Here's some logs : 

1 2025-08-26T10:46:00+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-26 10:46:00 - vpn - [85.201.154.27] sboo(AlwaysOn)[AlwaysOnVPN][d9049d47e7] - Host Checker Compliance Result - ['Fully Compliant'] on host ['85.201.154.27'] from address ['20-c1-9b-58-35-1d'] for user ['sboo'], passed_hc_policies:['Check_IRE_PC$$AOV_Registry_Key'], failed_hc_policies:['DD'], failed_reasons: ['DD'].

1 2025-08-26T12:36:31+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-26 12:36:31 - vpn - [193.74.19.208] EKIM(IRE LDAP Realm Vasco (Pulse Secure Client))[RDP Administrative (VPN Tunneling), Antivirus Upgrade (VPN Tunneling), HomeWork Administrative (VPN Tunneling)][5ddb5d7159] - Host Checker Compliance Result - ['Fully Compliant'] on host ['193.74.19.208'] from address ['fc-b0-de-61-34-95'] for user ['EKIM'], passed_hc_policies:['Check_IRE_PC'], failed_hc_policies:[''], failed_reasons: [''].

1 2025-08-27T10:05:44+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-27 10:05:44 - vpn - [109.140.36.169] ILAH(AlwaysOn)[][] - Login failed for 'Secondary' authentication using auth server 'esa' ('Radius Server').  Reason: 'Failed'

1 2025-08-27T10:02:37+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-27 10:02:37 - vpn - [87.64.43.31] MHEY(AlwaysOn)[][] - Host Checker policy 'AOV_Registry_Key' passed on host '87.64.43.31' address 'd8-80-83-3f-50-7d'  for user 'MHEY' .

1 2025-08-27T15:15:22+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-27 15:15:22 - vpn - [178.144.160.137] xxx.local\nfol()[ActiveSync][] - WebRequest completed, POST to [https://xxx-xxx-xxx.local:443//Microsoft-Server-ActiveSync?Cmd=Sync&User=xxx.local%5Cnfol&DeviceId=mdmxxAndroid00c4364255cf1aa7&DeviceType=Android] from [192.168.73.65] result=[200] sent=[53] received=[0] in [1] seconds

1 2025-08-27T15:58:13+02:00 xxx.xxx.xx PulseSecure: - - - 2025-08-27 15:58:13 - vpn - [178.51.58.44] BTAI(AlwaysOn)[AlwaysOnVPN][727b56cf25] - Host Checker policy 'AOV_Registry_Key' failed on host '178.51.58.44' address '20-c1-9b-57-8c-58'  for user 'BTAI' reason 'Server has not received any information for this policy.'  session 'side82334109e4f1ab5b7cfecaf76dc77bf50f809ff00000000'.

Chukwudalu Chisimdi Okonkwo

unread,
Sep 10, 2025, 8:29:28 AMSep 10
to Wazuh | Mailing List
Hello Adrien, 

Apologies for the delayed response, as I was having some issues with the Google Groups platform. However, kindly allow me some time to look into this, as the custom rules may have been written better to have the generic rule as the parent and the other specific rule sets as the child using the <if_sid> statement.

Feedback will be provided once the test is completed.

Chuks

Chukwudalu Chisimdi Okonkwo

unread,
Sep 11, 2025, 7:06:46 PMSep 11
to Wazuh | Mailing List
Hello Adrien, 

Thanks for your patience. I have conducted the required testing, and it appears that the logs are indeed matching the required decoders. I attempted ingesting them into my own lab and noticed that the logs could not be indexed due to a time format that was not supported.

However, to confirm that, I will need to run the command on your Wazuh manager  : cat /var/log/filebeat/filebeat | grep -i warn. If you can view the pulsesecure logs starting with the WARN log " 2025-09-11T22:09:33.819Z WARN [elasticsearch] elasticsearch/client.go:408 Cannot index event publisher.Event{Content:beat.Event{Timestamp:time.Time "  then kindly share with me the entire og so i can confirm if it is a similar error affecting the timestamp and then provide you with the fix.

Awaiting your feedback.

Chuks Okonkwo

Adrien Di Cristofaro

unread,
Sep 12, 2025, 2:56:29 AMSep 12
to Wazuh | Mailing List
Hello Chuks,

Yes it seems there's a lot. here are some :

WARN    [elasticsearch] elasticsearch/client.go:408     Cannot index event publisher.Event{Content:beat.Event{Timestamp:time.Time{wall:0xc228d4ddc33a5a0e, ext:790915572125227, loc:(*time.Location)(0x42417a0)}, Meta:{"pipeline":"filebeat-7.10.2-wazuh-alerts-pipeline"}, Fields:{"agent":{"ephemeral_id":"182d7ef8-c893-4902-a686-735dbed53994","hostname":"vm-3-wazuh-1","id":"e5c63829-169a-415e-8ba6-d5bebaf1a589","name":"vm-3-wazuh-1","type":"filebeat","version":"7.10.2"},"ecs":{"version":"1.6.0"},"event":{"dataset":"wazuh.alerts","module":"wazuh"},"fields":{"index_prefix":"wazuh-alerts-4.x-"},"fileset":{"name":"alerts"},"host":{"name":"vm-3-wazuh-1"},"input":{"type":"log"},"log":{"file":{"path":"/var/ossec/logs/alerts/alerts.json"},"offset":898166848},"message":"{\"timestamp\":\"2025-09-11T16:25:58.043+0200\",\"rule\":{\"level\":3,\"description\":\"Pulse Secure Host Checker Compliance\",\"id\":\"100031\",\"firedtimes\":4734,\"mail\":false,\"groups\":[\"Pulse Secure Info\"]},\"agent\":{\"id\":\"000\",\"name\":\"vm-3-wazuh-1\"},\"manager\":{\"name\":\"vm-3-wazuh-1\"},\"id\":\"1757600758.1041752176\",\"full_log\":\"1 2025-09-11T16:25:58+02:00 xxx.xxx.xx PulseSecure: - - - 2025-09-11 16:25:58 - vpn - [81.241.188.237] VDRU(AlwaysOn)[AlwaysOnVPN][b977640777] - Host Checker Compliance Result - ['Fully Compliant'] on host ['81.241.188.237'] from address ['a0-80-69-a3-38-b5'] for user ['VDRU'], passed_hc_policies:['Check_IRE_PC$$AOV_Registry_Key'], failed_hc_policies:[''], failed_reasons: [''].\",\"decoder\":{\"name\":\"pulsesecure_default\"},\"data\":{\"srcuser\":\"['VDRU']\",\"timestamp\":\"2025-09-11 16:25:58\",\"scrInfo\":\"[81.241.188.237] VDRU(AlwaysOn)[AlwaysOnVPN][b977640777]\",\"compliance\":\"['Fully Compliant']\",\"hostip\":\"['81.241.188.237']\",\"srcmac\":\"['a0-80-69-a3-38-b5']\",\"passed_policies\":\"['Check_IRE_PC$$AOV_Registry_Key']\",\"failed_policies\":\"['']\",\"failed_reasons\":\"['']\"},\"location\":\"192.168.246.50\"}","service":{"type":"wazuh"}}, Private:file.State{Id:"native::3672084-64512", PrevId:"", Finished:false, Fileinfo:(*os.fileStat)(0xc00059d040), Source:"/var/ossec/logs/alerts/alerts.json", Offset:898167945, Timestamp:time.Time{wall:0xc2289b1922816f2d, ext:731761096877440, loc:(*time.Location)(0x42417a0)}, TTL:-1, Type:"log", Meta:map[string]string(nil), FileStateOS:file.StateOS{Inode:0x380814, Device:0xfc00}, IdentifierName:"native"}, TimeSeries:false}, Flags:0x1, Cache:publisher.EventCache{m:common.MapStr(nil)}} (status=400): {"type":"mapper_parsing_exception","reason":"failed to parse field [data.timestamp] of type [date] in document with id 'iQkrOZkB0zoZBJQMQGD5'. Preview of field's value: '2025-09-11 16:25:58'","caused_by":{"type":"illegal_argument_exception","reason":"failed to parse date field [2025-09-11 16:25:58] with format [strict_date_optional_time||epoch_millis]","caused_by":{"type":"date_time_parse_exception","reason":"Failed to parse with all enclosed parsers"}}}
2025-09-11T16:26:00.066+0200    

WARN    [elasticsearch] elasticsearch/client.go:408     Cannot index event publisher.Event{Content:beat.Event{Timestamp:time.Time{wall:0xc228d4ddc33af0be, ext:790915572163804, loc:(*time.Location)(0x42417a0)}, Meta:{"pipeline":"filebeat-7.10.2-wazuh-alerts-pipeline"}, Fields:{"agent":{"ephemeral_id":"182d7ef8-c893-4902-a686-735dbed53994","hostname":"vm-3-wazuh-1","id":"e5c63829-169a-415e-8ba6-d5bebaf1a589","name":"vm-3-wazuh-1","type":"filebeat","version":"7.10.2"},"ecs":{"version":"1.6.0"},"event":{"dataset":"wazuh.alerts","module":"wazuh"},"fields":{"index_prefix":"wazuh-alerts-4.x-"},"fileset":{"name":"alerts"},"host":{"name":"vm-3-wazuh-1"},"input":{"type":"log"},"log":{"file":{"path":"/var/ossec/logs/alerts/alerts.json"},"offset":898169325},"message":"{\"timestamp\":\"2025-09-11T16:25:58.283+0200\",\"rule\":{\"level\":3,\"description\":\"Pulse Secure Host Checker Compliance\",\"id\":\"100031\",\"firedtimes\":4735,\"mail\":false,\"groups\":[\"Pulse Secure Info\"]},\"agent\":{\"id\":\"000\",\"name\":\"vm-3-wazuh-1\"},\"manager\":{\"name\":\"vm-3-wazuh-1\"},\"id\":\"1757600758.1041753960\",\"full_log\":\"1 2025-09-11T16:25:58+02:00 xxx.xxx.xx PulseSecure: - - - 2025-09-11 16:25:58 - vpn - [87.66.158.80] IMEU(AlwaysOn)[AlwaysOnVPN][3684e60ce4] - Host Checker Compliance Result - ['Fully Compliant'] on host ['87.66.158.80'] from address ['20-c1-9b-5a-9d-ad'] for user ['IMEU'], passed_hc_policies:['Check_IRE_PC$$AOV_Registry_Key'], failed_hc_policies:[''], failed_reasons: [''].\",\"decoder\":{\"name\":\"pulsesecure_default\"},\"data\":{\"srcuser\":\"['IMEU']\",\"timestamp\":\"2025-09-11 16:25:58\",\"scrInfo\":\"[87.66.158.80] IMEU(AlwaysOn)[AlwaysOnVPN][3684e60ce4]\",\"compliance\":\"['Fully Compliant']\",\"hostip\":\"['87.66.158.80']\",\"srcmac\":\"['20-c1-9b-5a-9d-ad']\",\"passed_policies\":\"['Check_IRE_PC$$AOV_Registry_Key']\",\"failed_policies\":\"['']\",\"failed_reasons\":\"['']\"},\"location\":\"192.168.246.50\"}","service":{"type":"wazuh"}}, Private:file.State{Id:"native::3672084-64512", PrevId:"", Finished:false, Fileinfo:(*os.fileStat)(0xc00059d040), Source:"/var/ossec/logs/alerts/alerts.json", Offset:898170414, Timestamp:time.Time{wall:0xc2289b1922816f2d, ext:731761096877440, loc:(*time.Location)(0x42417a0)}, TTL:-1, Type:"log", Meta:map[string]string(nil), FileStateOS:file.StateOS{Inode:0x380814, Device:0xfc00}, IdentifierName:"native"}, TimeSeries:false}, Flags:0x1, Cache:publisher.EventCache{m:common.MapStr(nil)}} (status=400): {"type":"mapper_parsing_exception","reason":"failed to parse field [data.timestamp] of type [date] in document with id 'jAkrOZkB0zoZBJQMQGD5'. Preview of field's value: '2025-09-11 16:25:58'","caused_by":{"type":"illegal_argument_exception","reason":"failed to parse date field [2025-09-11 16:25:58] with format [strict_date_optional_time||epoch_millis]","caused_by":{"type":"date_time_parse_exception","reason":"Failed to parse with all enclosed parsers"}}}


If you need more, tell me.

Br,

Adrien

Chukwudalu Chisimdi Okonkwo

unread,
Sep 12, 2025, 7:52:44 AMSep 12
to Wazuh | Mailing List
Hello Adrien,

Thanks for the prompt response. The issue as suspected is due to the timestamp format not following the ISO8601 that has been defined in the filebeat pipelines. The data processor is expecting the decoded timestamp field to be written in the format of ISO 8601 instead if shows up as  yyyy-MM-dd HH:mm:ss".

To fix this
1. Take a backup of the filebeat pipeline json
cp /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json.bak

2. Modify the existing pipeline JSON using any text editor, eg nano, vim or vi. Then, add it before the next Date processor (image attached for better illustration) Ensure it is well idented
nano /usr/share/filebeat/module/wazuh/alerts/ingest/pipeline.json

  {
      "date": {
        "field": "data.timestamp",
        "target_field": "data.timestamp",
        "formats": ["yyyy-MM-dd HH:mm:ss"],
        "ignore_failure": true
      }
    },

3.  Run the command to load the pipelines
filebeat setup --pipelines --modules wazuh

Let me know if this helped resolve the issue.

Chuks
filebeat processor.png

Adrien Di Cristofaro

unread,
Sep 12, 2025, 8:30:01 AMSep 12
to Wazuh | Mailing List
Hello Chuks,

Thanks for the precious epxplanation. 

I've made the change, i'll let you know next week if it's working.

Br,

ADrien

Adrien Di Cristofaro

unread,
Sep 29, 2025, 10:01:53 AM (yesterday) Sep 29
to Wazuh | Mailing List
Hello Chuks,

It seems to be working great for now !

Sorry for the delay, was so busy at work these weeks.

Thanks again for your help.

Br,

Adrien
Reply all
Reply to author
Forward
0 new messages