[IIS]: Enhance Grok Pattern to Support HTTP Methods Containing Hyphens

### Integration Name

IIS [iis]

### Dataset Name

iis.access

### Integration Version

1.24.4

### Agent Version

8.15.3

### OS Version and Architecture

Windows Server 2022

### User Goal

Ingest and parse Microsoft IIS access logs that contain non-standard but valid HTTP request methods that include hyphens (-) in their names. Specifically, Nessus Scanners have been observed using the following methods to probe IIS environments, all of which fail to parse correctly using the default `logs-iis.access-1.24.4` ingest pipeline:
- `X-MS-ENUMATTS` - A Microsoft Exchange WebDAV extension method used to enumerate email attachments
- `VERSION-CONTROL` - A WebDAV method defined in [RFC 3253](https://datatracker.ietf.org/doc/html/rfc3253)
- `BASELINE-CONTROL` - A WebDAV method also defined in [RFC 3253](https://datatracker.ietf.org/doc/html/rfc3253)

The goal is for these methods to be parsed and ingested successfully through the default managed pipeline (`logs-iis.access-`) without requiring direct modification of the managed pipeline, which is overwritten on integration upgrades.

### Existing Features

The Grok processor in the `logs-iis.access-1.24.4` managed ingest pipeline uses the pattern `%{WORD:http.request.method}` to capture the HTTP request method from IIS access log entries.

The `WORD` Grok pattern resolves to the regex `\b\w+\b`, where `\w` matches only 'word characters'. These are letters, digits, and underscores. **Hyphens** are not matched by `\w`, which causes Grok to fail entirely for any HTTP method containing a hyphen.

Additionally, because the Grok failure occurs at the **second** processor of the managed pipeline, the document never reaches the final `pipeline` processor that would invoke the `logs-iis.access@custom` pipeline. This means that the custom pipeline hook is unreachable for affected documents. There's no upgrade-safe workaround available, and modifying the managed pipeline is the only viable option.

### What did you see?

The following sanitized IIS access log entry was used to replicate the failure. Tested directly against the `logs-iis.access-1.24.4` pipeline, this entry consistently fails at the Grok processor:

**Sample Log Line**
```log
2026-04-07 15:00:00 W3SVC1 MYHOST123 10.10.10.24 X-MS-ENUMATTS /example.htm - 80 - 10.10.10.45 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0) - - 10.10.10.45 404 0 2 1400 300 0
```

**Test Document**
```json
[
{
"_source": {
"message": "2026-04-07 15:00:00 W3SVC1 MYHOST123 10.10.10.24 X-MS-ENUMATTS /example.htm - 80 - 10.10.10.45 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0) - - 10.10.10.45 404 0 2 1400 300 0"
}
}
]
```

**Observed Behavior:** The Grok processor fails to match the `X-MS-ENUMATTS` method value, causing the entire pipeline to abort for this document. The same failure is reproduced with `VERSION-CONTROL` and `BASELINE-CONTROL`.

**Expected Behavior:** The HTTP request method field should be captured successfully regardless of whether the method name contains hyphens, and the document should continue through the remainder of the pipeline normally.

### Anything else?

**Suggested Fixes:**

Two potential approaches are suggested, either of which would resolve the issue:

1. **Replace `%{WORD:http.request.method}` with `%{NOTSPACE:http.request.method}`** in the existing Grok patterns within the managed pipeline. Since `NOTSPACE` resolves to any non-whitespace character, it would correctly capture all known HTTP method formats including those with hyphens. In the context of an IIS access log, the method field is clearly bounded by whitespace, so this substitution carries minimal risk of over-matching.
2. **Add an additional Grok pattern** as a fallback that uses `%{NOTSPACE:http.request.method}` in place of `%{WORD:http.request.method}`. Since Grok evaluates patterns in order and stops at the first match, the existing behavior for standard methods would be preserved, and the fallback would only apply when the primary patterns fail.

**Verified Workaround:**

The third Grok pattern in the `logs-iis.access-1.24.4` pipeline was successfully modified to use `NOTSPACE` instead of `WORD` for the `http.request.method` field and confirmed to parse all three methods correctly. The full modified pattern is as follows:
```grok
%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{NOTSPACE:iis.access.site_name}) (?:-|%{NOTSPACE:iis.access.server_name}) (?:-|%{IPORHOST:destination.address}) (?:-|%{NOTSPACE:http.request.method}) (?:-|%{NOTSPACE:_temp_.url_path}) (?:-|%{NOTSPACE:_temp_.url_query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|HTTP/%{NUMBER:http.version}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NOTSPACE:iis.access.cookie}) (?:-|%{NOTSPACE:http.request.referrer}) (?:-|%{NOTSPACE:destination.domain}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:http.response.body.bytes:long}) (?:-|%{NUMBER:http.request.body.bytes:long}) (?:-|%{NUMBER:_temp_.duration:long})( (?:-|%{IP:network.forwarded_ip}))?
```

Note that this modification was made directly to the managed pipeline, which is not upgrade-safe. This is just provided as reference for validation.

**Additional Context:**

- All three methods observed in this case were issued by a **Nessus vulnerability scanner** probing the IIS servers. None of them reflect intentional use by the server or any application. This is the primary real-world trigger for this issue.
- Vulnerability scanners such as Nessus routinely probe web servers by issuing a wide variety of HTTP methods, both standard and non-standard, against arbitrary endpoints. This means the parsing failure can be triggered on **any** IIS server that undergoes a vulnerability scan, regardless of whether Exchange, WebDAV, or any related extensions are present. This significantly widens the population of affected users beyond niche WebDAV environments.
- `VERSION-CONTROL` and `BASELINE-CONTROL` are IETF Proposed Standard methods (RFC 3253, March 2002). The full specifications can be found here: https://datatracker.ietf.org/doc/html/rfc3253
- `X-MS-ENUMATTS` is a proprietary Microsoft Exchange WebDAV extension. Documentation can be found here: https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa126042(v=exchg.65)
- The `logs-iis.access@custom` pipeline is not a viable workaround because the Grok failure prevents documents from ever reaching the custom pipeline processor at the end of the managed pipeline.