IIS rules
George Paun
George Paun
Matias Ezequiel Latorre
Hi George,
From the screenshot it appears the event is currently being decoded by web-accesslog, which suggests that your custom IIS decoder is not matching the incoming log entry. When that happens, any rules depending on fields produced by the IIS decoder or on a specific SID will not trigger.
Before modifying the decoders or rules further, the most useful step is to verify the exact format of the log that the manager is receiving. The recommended way to do this is with wazuh-logtest.
On the Wazuh manager, please run:
Then paste a sanitized sample line from the original log (you can replace IPs, hostnames, or URLs if necessary). The output will show:
-
which decoder is matching
-
which fields are extracted
-
which rules are triggered
It would also help to see the relevant part of the agent configuration, especially the localfile block used to ingest the IIS logs, for example:
<log_format>...</log_format>
<location>...</location>
</localfile>
With that information it will be easier to determine why the custom decoder is not matching and whether the rules should reference the existing web access decoder or a custom IIS decoder.
Thanks.
George Paun
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/ossec/logs/active-responses.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/secure</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/maillog</location>
</localfile>
Matias Ezequiel Latorre
George,
Thanks for sharing the agent configuration.
From what you posted, that agent is only collecting system logs (audit, messages, secure, etc.), and there is no localfile entry configured to read IIS access logs. This suggests that the web logs you showed earlier are reaching the Wazuh manager through another pipeline (for example syslog forwarding, Filebeat, Logstash, or another log collector).
In the screenshot you shared earlier the events are being decoded with web-accesslog, which means the log is matching the generic web access decoder rather than your custom IIS decoder.
To understand why your decoder is not matching, could you clarify:
-
How the IIS logs are being forwarded to the Wazuh manager
-
A sanitized sample of the raw log line as received by the manager (you can test it with /var/ossec/bin/wazuh-logtest)
Once we see the exact log format reaching the manager, we can determine whether the existing web-accesslog decoder should be used or if the IIS decoder needs to be adjusted.
Thanks.
Matias Ezequiel Latorre
Hi George,
Thanks for sharing the wazuh-logtest output — that helps clarify what is happening.
-
The log line you shared matches a standard web access log format, which is why it is correctly decoded by the web-accesslog decoder. Because of this, using:
will prevent the event from being decoded properly, as the IIS decoder expects IIS W3C format logs.
-
Your rules are triggering correctly. In the output you shared we can see that rule 140007 fired as expected during Phase 3.
-
Regarding the full URL: the url field only contains the request path because the hostname is not included directly in that part of the log line. Since those values are logged separately, Wazuh cannot automatically reconstruct a full URL such as https://host/path. This limitation comes from the log format itself.
-
If you need to extract additional information from the URL or adjust the parsing, a recommended approach is to extend or modify an existing child decoder instead of replacing the default one. For example, you could modify or extend a specific child decoder in 0380-windows_decoders.xml to adjust the extracted fields.
You can find the documentation on modifying default decoders here:
This approach preserves the normal decoder flow while allowing you to adjust the parsing logic safely.
One additional small note: rule 140007 shows the group iisiis in the output, which looks like it might be a typo (iis). You may want to review that in your rules file.
Thanks.
George Paun
Thx,
George Paun
<!--
<decoder name="web-accesslog-iis5">
<parent>windows-date-format</parent>
<type>web-log</type>
<use_own_name>true</use_own_name>
<prematch offset="after_parent">^\S+ \S+ W3SVC</prematch>
<regex offset="after_parent">^(\S+) \S+ \S+ \S+ \S+ </regex>
<regex>\d+ \S+ (\S+ \S+) (\d+) </regex>
<order>srcip,url,id</order>
</decoder>
<decoder name="web-accesslog-iis6">
<parent>windows-date-format</parent>
<type>web-log</type>
<use_own_name>true</use_own_name>
<prematch offset="after_parent">^W3SVC\d+ \S+ \S+ \S+ </prematch>
<regex offset="after_prematch">^(\S+ \S+) \d+ \S+ (\S+) </regex>
<regex>\S+ \S+ \S+ \S+ \S+ (\d+) </regex>
<order>url, srcip, id</order>
</decoder>
<decoder name="web-accesslog-iis-default">
<parent>windows-date-format</parent>
<type>web-log</type>
<use_own_name>true</use_own_name>
<prematch offset="after_parent">^\S+ GET |^\S+ POST</prematch>
<regex offset="after_parent">^\S+ (\w+) (\S+ \S+) (\S+) \S+ (\S+) (\S+) \.*(\d\d\d) </regex>
<order>action, url, srcport, srcip, user_agent, id</order>
</decoder>
-->
Matias Ezequiel Latorre
Hi George,
Thanks for the additional details.
Based on the sample log and the wazuh-logtest output you shared earlier, the events are already being correctly decoded by the web-accesslog decoder. Because of that, creating separate IIS decoders may not be necessary for this log format.
Regarding your question: yes, it is fine to reference rule 31100 when building custom rules for web access logs. Many custom rules are implemented as children of that rule.
If you'd like to experiment with custom rules, a simple starting point could look like this:
<if_sid>31100</if_sid>
<match>example-pattern</match>
<description>Custom web request detected: $(url) from $(srcip)</description>
<group>web,custom,</group>
</rule>
From there you can adjust the <match> or <regex> conditions depending on the pattern you want to detect in the request.
Also, if you need to adjust how certain fields are decoded, the recommended approach is to extend or modify an existing decoder rather than replacing the default ones. The following documentation explains how to safely modify default decoders:
You may want to try adapting your rules following that approach and test them with wazuh-logtest. If something still does not behave as expected, feel free to share the results and we can take another look.
Regards,
George Paun
Hi Matias,
I apologize for the confusion earlier ( i am an idiot) - I realized I was testing with the wrong log format (not from the actual archive).
I've now grabbed a proper sanitized log sample from the real IIS logs and attached :
wazuh-logtest output
The specific rule that's not triggering
And the full log
the decoder
Matias Ezequiel Latorre
Hi George,
No need to apologize, the additional context was very helpful.
Looking at the wazuh-logtest output you shared, the real IIS logs are arriving through Windows Event Channel and your custom decoder is matching them correctly. In your test, the decoder chain shows your custom iis decoder firing, and rule 190051 is triggered as expected.
In this case, the important difference is that the IIS request data is already available under the win.eventdata fields, for example:
-
win.eventdata.cs-uri-stem
-
win.eventdata.c-ip
-
win.eventdata.cs-method
-
win.eventdata.sc-status
Because of that, the recommended approach is to build your custom rules against those extracted fields, rather than against the web-accesslog fields used earlier in the thread.
So yes — for this decoder flow, it makes more sense to link your custom rules to your IIS base rule (for example 190050) rather than to 31100, since 31100 belongs to a different web access decoding path.
As a simple example template, a rule could follow this pattern:
<if_sid>190050</if_sid>
<field name="win.eventdata.sc-status">^(401|403)$</field>
<description>IIS unauthorized access: $(win.eventdata.cs-uri-stem) from $(win.eventdata.c-ip)</description>
<group>web,unauthorized_access,</group>
</rule>
If you need to adjust the decoding further, the recommended approach is still to extend or modify the existing decoder flow rather than replacing the default ones completely. This documentation may be useful:
You may want to adapt your rules following that structure and test them with wazuh-logtest. If a specific field or condition is still not behaving as expected, feel free to share a sanitized example and the test output.
BR
George Paun
Matias Ezequiel Latorre
Hi George,
Thanks for sharing the files and the wazuh-logtest output.
From the test results you provided, the decoder and rules are actually working correctly. The output shows that the event is decoded with your iis decoder and that rule 140001 is triggered successfully:
parent: iis
rule 140001 fired
So the decoder chain itself appears to be functioning as expected.
One important detail to consider is that these IIS logs are coming through Windows EventChannel, and most of the request information is already extracted into JSON fields under win.eventdata (for example cs-method, cs-uri-stem, c-ip, sc-status, etc.).
Because of that, it is generally more reliable to build rules using <field> conditions rather than matching raw strings in the log. For example:
<if_sid>140000</if_sid>
<field name="win.eventdata.cs-method">GET</field>
<description>IIS GET request detected</description>
<group>iis,web</group>
</rule>
This approach avoids relying on string matches in the raw event and instead uses the structured fields already parsed by Wazuh.
One thing also worth clarifying: the first log you pasted into wazuh-logtest was the full processed alert JSON (with timestamp, agent, manager, and cluster fields). That format is already post-processed, which is why logtest decoded the outer wrapper and showed decoder: json instead of your iis decoder.
For accurate testing, always paste the raw event in this format:
That is the correct input format for wazuh-logtest.
You may want to try adapting your rules using the win.eventdata.* fields and test them again with wazuh-logtest using the correct raw format.
Also, if possible, could you share a few raw IIS log entries directly from the IIS source (sanitized if necessary), for example lines taken directly from the IIS log files under:
Having the raw entries helps reproduce the decoding behavior locally with wazuh-logtest.
If something still behaves differently in the manager compared to logtest, feel free to share the updated output and we can take another look.
BR.
Matias Ezequiel Latorre
Hi George,
Yes, exactly. For wazuh-logtest you should use the raw log line exactly as it arrives to the Wazuh manager, not the already processed alert JSON.
Looking at the samples you shared, there are actually two different IIS log formats:
1. W3SVC file logs (first two samples)
Example:
These are standard IIS W3C text log files written to disk under:
2. Event Viewer log (third sample)
Example:
This format comes from the Windows Event Viewer channel (Microsoft-IIS-Logging/Logs).
Based on the configuration and examples you shared earlier, your current decoders and rules are designed for the EventChannel format, so they will only match that third format and not the W3SVC file logs.
For accurate testing with wazuh-logtest, you should therefore paste the raw EventChannel event, similar to the Event Viewer example you provided.
If you also want to collect and parse the W3SVC file logs from C:\inetpub\logs\LogFiles\, that would require a separate localfile configuration and a different decoder, since those logs follow a different format.
For now, I would recommend focusing on testing with the Event Viewer format to confirm the decoder and rule behavior.
Thanks.