Building Detection Rules Using Dynamic Fields

Once your decoder extracts dynamic fields, the next step is using those fields to build powerful detection rules.

Dynamic fields give you much greater flexibility than traditional static fields because rules can evaluate application-specific attributes rather than being limited to a predefined schema.

Separating decoding from detection also makes your rules easier to maintain.

If a log format changes, you can often update the decoder without rewriting every detection rule.

Matching Extracted Values

The most common use of dynamic fields is matching specific values extracted during decoding.

For example, if your decoder extracts:

authentication.user = alice
authentication.result = failed
network.source.ip = 203.0.113.25

a rule can trigger whenever a failed authentication is detected.

Example:

<rule id="100500" level="5">
  <field name="authentication.result">failed</field>
  <description>Failed authentication detected</description>
</rule>

Because the decoder has already organized the data into meaningful fields, the rule remains simple and easy to understand.

For additional rule development examples, see How to Create Custom Detection Rules in Wazuh (With Examples).

Creating Severity Levels

Not every event deserves the same alert level.

Dynamic fields make it easy to assign different severities depending on the extracted values.

For example:

Instead of creating separate decoders, multiple rules can reference the same dynamic fields while assigning different severity levels based on the context.

This layered approach reduces duplication and improves long-term maintainability.

Correlating Multiple Fields

Dynamic fields become even more powerful when rules evaluate several fields simultaneously.

Consider this decoded event:

authentication.user = alice
authentication.result = failed
network.source.ip = 203.0.113.25
geo.country = Russia
authentication.mfa = false

Rather than evaluating each field independently, a rule can combine them to identify higher-risk scenarios.

Examples include:

• Failed login and MFA disabled
• Administrative account and foreign IP address
• Sensitive endpoint and unexpected HTTP method
• Cloud API call and unknown account
• Firewall deny event and suspicious application

Using multiple fields reduces false positives because alerts require several conditions to be met before firing.

Using Field Comparisons

Many detection strategies rely on comparing field values instead of simply matching fixed strings.

Examples include:

• HTTP response code greater than 499
• Risk score above a defined threshold
• Request duration exceeding expected values
• Authentication attempts greater than a specified count
• Session duration longer than normal

Depending on the rule logic, dynamic fields can support numeric comparisons that make detections far more precise than simple keyword matching.

For detection engineering guidance, the MITRE ATT&CK framework emphasizes combining multiple telemetry sources and contextual attributes to improve detection quality.

Triggering Alerts from Dynamic Values

Once a rule matches, the extracted dynamic fields become part of the generated alert.

A typical alert might include:

authentication.user = alice
authentication.result = failed
network.source.ip = 203.0.113.25
geo.country = Russia
risk.score = 91

Having this additional context directly in the alert helps analysts answer important questions without searching through the original log.

For example:

• Who initiated the activity?
• Where did it originate?
• Which resource was targeted?
• Was MFA enabled?
• How risky was the event?

This richer context significantly reduces investigation time.

Parent-Child Rule Integration

Dynamic fields integrate naturally with Wazuh’s parent-child rule model.

A common workflow looks like this:

Incoming Log
      │
      ▼
Parent Decoder
      │
      ▼
Child Decoder
      │
      ▼
Dynamic Fields Created
      │
      ▼
Parent Rule Matches
      │
      ▼
Child Rules Evaluate Specific Fields
      │
      ▼
Alert Generated

For example:

• Parent rule identifies an authentication event.
• Child rule detects a failed login.
• Another child rule identifies failed administrator logins.
• A third child rule detects repeated failures from the same country.

This hierarchy minimizes duplicated rule logic while allowing increasingly specific detections.

To learn more, see How to Map Complex Log Fields Using Wazuh Parent Child Rules.

Testing Dynamic Fields with Wazuh Logtest

Before deploying new decoders and rules into production, validate them using wazuh-logtest.

Testing ensures that fields are extracted correctly, rules match as expected, and configuration errors are identified before they impact your monitoring environment.

Using Logtest throughout development is one of the most effective ways to reduce troubleshooting time.

Running wazuh-logtest

Start the Logtest utility on your Wazuh Manager and paste a representative log entry.

Logtest processes the event using the same decoding and rule engine as the manager, allowing you to verify exactly how Wazuh interprets the log.

A typical workflow is:

1. Launch wazuh-logtest.
2. Paste a sample log.
3. Review the matched decoder.
4. Inspect extracted fields.
5. Confirm rule matches.
6. Repeat with additional logs.

See How to Use Wazuh Logtest for a detailed walkthrough.

Verifying Extracted Fields

After decoding, confirm that every expected dynamic field appears in the output.

Example:

authentication.user = alice
network.source.ip = 203.0.113.25
network.destination.ip = 10.0.0.15
http.request.method = POST
url.path = /login
http.response.status_code = 403

Verify that:

• Field names are correct.
• Values are assigned to the proper fields.
• No fields are missing.
• No unexpected values are captured.
• Hierarchical names use the intended dot notation.

If values appear under the wrong field names, the issue is often an incorrect <order> mapping or misplaced regex capture group.

Testing Multiple Log Samples

Never validate a decoder using only one log entry.

Instead, test examples that include:

• Successful events
• Failed events
• Missing fields
• Optional values
• Different application versions
• Malformed logs
• Unexpected whitespace
• Edge cases

Comprehensive testing helps ensure that your decoder remains reliable as log formats evolve over time.

Validating Rule Matches

Once field extraction is verified, ensure your custom rules trigger only when expected.

Check that:

• Correct rules match.
• Incorrect rules do not match.
• Alert levels are appropriate.
• Child rules inherit from the proper parent rules.
• Dynamic fields are available during rule evaluation.

Testing both positive and negative cases helps reduce false positives before deployment.

If you’re new to custom rule development, see How to Test Wazuh Rules.

Debugging Failed Extractions

If Logtest doesn’t produce the expected fields, troubleshoot systematically.

Common causes include:

• Incorrect regular expressions
• Capture group mismatches
• Incorrect <order> definitions
• Decoder loading failures
• Parent decoder not matching
• XML syntax errors
• Unexpected log formatting
• Typographical errors in field names

Begin by confirming that the correct decoder matched the log.

If it didn’t, review the decoder’s <prematch> and <regex> elements before examining the extraction logic itself.

For additional troubleshooting guidance, see:

• Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive
• Troubleshooting wazuh-logtest: Why Alerts Are Missing from JSON Output

Advanced Dynamic Field Techniques

As your environment grows, you’ll likely need decoders that handle multiple log formats, optional fields, nested structures, and evolving applications.

The following techniques help you build scalable decoder libraries that remain maintainable over time.

Reusing Parent Decoders

Many log formats share common prefixes while differing only in their payloads.

Instead of duplicating similar regular expressions, create a parent decoder that identifies the log source and delegate detailed parsing to child decoders.

Benefits include:

• Less duplicated code
• Easier maintenance
• Faster updates
• Improved readability
• Better scalability

If a vendor changes its log format, you often need to update only the relevant child decoder rather than every decoder in the library.

For a detailed guide, see How to Map Complex Log Fields Using Wazuh Parent Child Rules.

Parsing Variable-Length Logs

Some applications generate logs where optional attributes appear only under certain conditions.

For example:

User=alice Action=Login

or

User=alice Action=Login Device=Laptop MFA=True Location=Canada

Rather than writing multiple decoders for every variation, design your decoder to accommodate different log lengths while extracting the fields that are present.

This approach keeps your decoder library smaller and easier to maintain.

Optional Capture Groups

Regular expressions support optional capture groups, allowing a single decoder to process multiple variations of the same log format.

This is especially useful when applications add new fields in later software releases.

Examples include optional:

• Device identifiers
• MFA status
• Session tokens
• Geographic information
• Risk scores
• User agent strings

Carefully testing optional groups with representative logs helps prevent incorrect field mappings.

Conditional Decoding Strategies

Large environments often ingest logs from many different products that share similar prefixes.

Conditional decoding allows Wazuh to route logs through different child decoders depending on the content.

For example:

• Authentication events
• Administrative actions
• API requests
• Database activity
• Audit records

Each decoder extracts only the fields relevant to that event type, resulting in simpler regular expressions and easier maintenance.

Combining Static and Dynamic Fields

Dynamic fields are not intended to replace static fields entirely.

In many cases, using both provides the best results.

For example:

Static fields maintain compatibility with existing rules and dashboards, while dynamic fields preserve richer context for custom detections.

Choosing the right balance depends on your environment, existing ruleset, and reporting requirements.

Organizing Large Decoder Libraries

As organizations integrate more applications, the number of custom decoders can grow rapidly.

To keep your decoder library manageable:

• Group related decoders by application or vendor.
• Use consistent naming conventions for dynamic fields.
• Reuse parent decoders whenever possible.
• Document expected log formats and extracted fields.
• Store decoder files in version control.
• Validate every change using wazuh-logtest.
• Review decoders after Wazuh upgrades to ensure continued compatibility.

Following these practices reduces maintenance effort and makes it easier for other team members to understand and extend your decoder library.

For general recommendations on validating and maintaining decoders, see Wazuh Decoder Guide.

Performance Considerations

Dynamic fields provide significant flexibility, but poorly designed decoders can introduce unnecessary processing overhead, especially in environments receiving millions of events per day.

Every log processed by Wazuh passes through decoding, field extraction, and rule evaluation stages.

Optimizing your decoder design ensures that dynamic field extraction improves visibility without negatively affecting manager performance.

Optimizing Regular Expressions

Regular expressions are one of the most important performance factors when creating custom decoders.

Poorly designed regex patterns can consume excessive CPU resources, especially when processing large volumes of logs.

Avoid patterns that:

• Use excessive wildcard matching
• Contain unnecessary nested quantifiers
• Scan entire log messages when only a small section is needed
• Use ambiguous matching patterns

For example, this pattern can be inefficient:

.*User=(.*).*IP=(.*).*Action=(.*)

A more efficient approach is:

User=([^ ]+)\s+IP=([^ ]+)\s+Action=([^ ]+)

The optimized version:

• Limits matching scope
• Uses precise capture boundaries
• Reduces unnecessary backtracking
• Extracts only required values

When developing complex patterns, test them against realistic log volumes rather than only individual examples.

Minimizing Decoder Complexity

Large, complicated decoders are harder to maintain and can increase processing overhead.

A decoder should focus on extracting only the information required for:

• Detection rules
• Investigations
• Dashboards
• Compliance reporting

Avoid creating dynamic fields for every value in a log unless those fields provide operational or security value.

For example, extracting:

authentication.user
authentication.result
network.source.ip

is usually more valuable than extracting dozens of insignificant application metadata fields.

A smaller, focused decoder is easier to troubleshoot and performs better.

Reducing Unnecessary Captures

Every regex capture group requires additional processing.

Avoid capturing values that will not be used.

For example:

Timestamp=(\S+) User=(\S+) Application=(\S+) Status=(\S+)

If the timestamp is already handled by Wazuh’s pre-decoding process, capturing it again creates unnecessary work.

Instead:

User=(\S+) Application=(\S+) Status=(\S+)

Only capture fields that will become dynamic fields or influence detection logic.

Efficient Decoder Ordering

Wazuh evaluates decoders in sequence, so decoder organization affects processing efficiency.

Place more specific decoders before broad generic decoders whenever possible.

For example:

A specific decoder:

<decoder name="aws-cloudtrail-login">

should generally be evaluated before:

<decoder name="generic-json-event">

A broad decoder that matches too many events can prevent more specific decoders from processing logs correctly.

Efficient decoder ordering helps:

• Reduce unnecessary matching attempts
• Avoid decoder conflicts
• Improve processing speed
• Increase extraction accuracy

Testing Performance Under Heavy Log Volume

A decoder that works correctly on a single test event may behave differently under production workloads.

Before deploying complex dynamic field decoders, test them with realistic traffic volumes.

Consider evaluating:

• Events per second
• CPU utilization
• Memory consumption
• Decoder processing time
• Alert generation delays
• Queue growth

High-volume environments should test new decoders before production rollout, especially when parsing:

• Firewall logs
• Cloud audit events
• Kubernetes audit streams
• Application access logs

Performance testing helps identify inefficient patterns before they impact security monitoring.

Common Problems and Troubleshooting

Even well-designed dynamic field decoders can fail due to syntax issues, incorrect mappings, or conflicts with existing Wazuh configurations.

The following troubleshooting techniques help identify and resolve common problems.

Dynamic Fields Not Appearing

One of the most common issues is that the decoder matches successfully but expected dynamic fields do not appear.

Common causes include:

• Incorrect <order> configuration
• Missing capture groups
• Field names containing typos
• Decoder changes not loaded
• Incorrect decoder file location

Start troubleshooting by running the event through wazuh-logtest and confirming whether the decoder extracted any fields.

If the decoder matches but fields are empty, inspect the regex capture groups and <order> mapping.

See How to Use Wazuh Logtest.

Decoder Never Matches

If Wazuh cannot identify your decoder, the issue usually occurs before field extraction.

Common causes include:

• Incorrect <prematch> condition
• Regex does not match the log format
• Parent decoder failed
• Log contains unexpected formatting
• Decoder file was not loaded

Example:

Log:

AUTH User=alice Result=Failed

Decoder:

<prematch>LOGIN</prematch>

The decoder will never execute because the required text does not exist in the event.

Verify the raw log exactly matches the conditions defined in your decoder.

For advanced troubleshooting, see Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive.

Incorrect Field Values Extracted

Sometimes dynamic fields appear but contain incorrect information.

Example:

Expected:

network.source.ip = 192.168.1.10

Received:

network.source.ip = Failed

This usually indicates a mismatch between regex capture groups and the <order> element.

Example:

Regex:

User=(\S+) Status=(\S+) IP=(\S+)

Order:

authentication.user,network.source.ip,authentication.status

The values will be assigned incorrectly because the order does not match the capture sequence.

Always ensure:

Capture group position = Field position

Rule Cannot Reference Dynamic Fields

A rule may fail to match even though the decoder extracted the field correctly.

Common causes include:

• Incorrect field name
• Typographical errors
• Rule evaluated before decoding
• Field exists under a different namespace
• Parent rule relationship is incorrect

Example:

Extracted field:

authentication.result

Rule checks:

<field name="authentication.status">failed</field>

The rule will fail because the names do not match.

Always copy field names directly from Logtest output when creating rules.

For rule troubleshooting, see How to Test Wazuh Rules.

Regex Capture Group Mismatches

A frequent decoder problem occurs when the number of regex groups does not match the number of fields defined in <order>.

Example:

Regex:

User=(\S+) IP=(\S+)

Contains:

2 capture groups

But:

<order>
authentication.user,network.source.ip,session.id
</order>

Contains:

3 fields

The mapping will fail because Wazuh does not have enough captured values.

Always verify that:

Number of capture groups = Number of dynamic fields

JSON Fields Missing

When parsing JSON logs, missing fields usually indicate one of the following:

• Incorrect JSON path
• Invalid JSON syntax
• Unexpected field names
• Nested objects not handled correctly
• Arrays requiring different processing

Example:

Actual log:

{
 "user": {
   "name": "alice"
 }
}

Expected:

user

But the correct dynamic field path is:

user.name

Always inspect the original JSON structure before writing your decoder.

Nested Fields Parsed Incorrectly

Nested JSON structures can become difficult when applications use inconsistent schemas.

Example:

One event:

{
 "cloud":{
   "region":"us-east-1"
 }
}

Another event:

{
 "region":"us-east-1"
}

These produce different field structures:

cloud.region

versus:

region

Create decoder logic that accounts for expected variations rather than assuming all events follow the same structure.

Decoder Conflicts with Built-In Decoders

Custom decoders can sometimes conflict with Wazuh’s built-in ruleset.

Symptoms include:

• Wrong decoder selected
• Missing dynamic fields
• Unexpected alerts
• Different extraction results after upgrades

Common causes include:

• Generic custom decoders matching too broadly
• Duplicate decoder names
• Overlapping regex patterns

To avoid conflicts:

• Use unique decoder names
• Use specific <prematch> conditions
• Avoid replacing built-in decoder files
• Store custom decoders separately

For decoder customization guidance, see Wazuh Decoder Guide.

Best Practices for Using Wazuh Dynamic Fields

Following consistent development practices ensures that your dynamic field implementation remains reliable, scalable, and easy to maintain.

Use Descriptive Field Names

Dynamic field names should clearly describe the information they contain.

Good:

authentication.user
network.source.ip
cloud.region
http.response.status_code

Poor:

field1
data
value
custom1

Descriptive naming improves:

• Rule readability
• Investigation speed
• Dashboard usability
• Team collaboration

Keep Decoder Logic Modular

Avoid creating one massive decoder that attempts to parse every possible event type.

Instead:

• Create focused decoders
• Separate applications by decoder
• Use child decoders for specific events
• Extract only relevant fields

Modular designs are easier to test and troubleshoot.

Reuse Parent Decoders Whenever Possible

Parent-child decoder relationships reduce duplication and simplify maintenance.

A shared parent decoder can identify common characteristics while child decoders handle event-specific extraction.

Benefits include:

• Smaller configurations
• Easier updates
• Better organization
• Reduced regex duplication

See How to Map Complex Log Fields Using Wazuh Parent Child Rules.

Validate Every Decoder with Logtest

Never deploy a decoder without testing it.

Use wazuh-logtest to verify:

• Decoder matching
• Field extraction
• Rule execution
• Alert generation

Testing prevents configuration errors from reaching production environments.

See How to Use Wazuh Logtest.

Optimize Regex for Performance

Efficient regex improves both reliability and scalability.

Follow these practices:

• Avoid unnecessary wildcards
• Limit capture groups
• Use precise matching
• Test against large samples
• Avoid overly complex expressions

Performance matters most in environments processing high event volumes.

Follow Consistent Naming Conventions

Standardized naming makes large decoder libraries easier to manage.

Example:

authentication.*
network.*
cloud.*
http.*
container.*
kubernetes.*

Consistent namespaces help analysts quickly understand new fields without reviewing decoder files.

Document Custom Field Mappings

Maintain documentation for every custom decoder.

Include:

• Source application
• Sample logs
• Extracted fields
• Decoder purpose
• Related detection rules
• Expected field values

Documentation becomes especially important when multiple security engineers maintain the environment.

Store Custom Decoders Separately from Built-In Rules

Never directly modify Wazuh’s default decoder files.

Custom changes should be stored separately so they survive:

• Wazuh upgrades
• Ruleset updates
• Configuration changes

This also makes troubleshooting easier because you can quickly identify which custom components were added.

Version Control Decoder Changes

Store decoder XML files in a version control system.

Benefits include:

• Change history
• Code review
• Rollback capability
• Team collaboration
• Safer deployments

Treat decoder development like software development rather than manual configuration editing.

Re-Test After Wazuh Upgrades

Wazuh upgrades may introduce changes to:

• Decoder behavior
• Built-in rules
• JSON parsing
• Field mappings
• Alert formats

After upgrading:

1. Run existing Logtest samples.
2. Confirm dynamic fields still populate.
3. Verify custom rules still trigger.
4. Review decoder conflicts.
5. Update documentation if necessary.

Regular validation ensures your detection pipeline continues operating correctly after platform changes.

For upgrade planning, see How to Upgrade a Wazuh Agent.

Real-World Example

Scenario

A security operations team manages a hybrid infrastructure that includes Linux servers, Windows endpoints, Kubernetes clusters, cloud workloads, and a custom customer-facing web portal.

The organization already uses Wazuh to monitor operating system events, authentication activity, vulnerability data, and infrastructure security events.

However, the customer portal generates proprietary authentication logs that are not supported by Wazuh’s built-in decoders.

The application produces events similar to:

{
  "event_type": "authentication",
  "username": "jane.smith",
  "customer_id": "CUST-48291",
  "session_id": "9f8a7d12345",
  "device_fingerprint": "dfp-8a92bc",
  "api_endpoint": "/api/account/login",
  "geo": {
    "country": "Canada",
    "city": "Toronto"
  },
  "risk_score": 87,
  "authentication_result": "success"
}

The default Wazuh ruleset cannot automatically understand fields such as:

customer_id
session_id
device_fingerprint
risk_score
geo.country
api_endpoint

Without custom parsing, valuable security context remains trapped inside raw log messages.

To solve this problem, the security team creates custom dynamic field decoders that extract each important attribute and convert them into searchable Wazuh fields.

The resulting fields become:

authentication.user = jane.smith
customer.id = CUST-48291
session.id = 9f8a7d12345
device.fingerprint = dfp-8a92bc
api.endpoint = /api/account/login
geo.country = Canada
geo.city = Toronto
risk.score = 87
authentication.result = success

Creating Custom Dynamic Field Decoders

The security team begins by analyzing the portal’s log format and identifying the fields required for detection and investigation.

They create a custom decoder that:

• Matches authentication events from the portal
• Extracts user information
• Captures session identifiers
• Parses geographic information
• Extracts risk scoring data
• Maps proprietary application fields into meaningful dynamic fields

Instead of modifying the customer portal to produce a different format, the team adapts Wazuh to understand the existing logs.

This approach reduces application development effort while still providing full security visibility.

Validating Dynamic Fields with wazuh-logtest

Before deploying the decoder into production, the team tests it using wazuh-logtest.

The validation process confirms that:

• The correct decoder matches the event
• Dynamic fields are extracted correctly
• Nested JSON values are parsed properly
• Rules can reference the extracted fields
• Alerts contain the expected information

Example Logtest output:

Decoder: customer-portal-authentication

authentication.user = jane.smith
customer.id = CUST-48291
session.id = 9f8a7d12345
device.fingerprint = dfp-8a92bc
geo.country = Canada
risk.score = 87
authentication.result = success

Testing before deployment prevents incorrect field mappings from generating inaccurate alerts.

See How to Use Wazuh Logtest.

Building Detection Rules for Suspicious Authentication Activity

Once the dynamic fields are available, the security team creates custom rules that use the extracted values.

Examples include:

Detecting Account Takeover Attempts

A rule identifies suspicious login behavior when:

authentication.result = success
risk.score > 80
device.fingerprint = unknown

This indicates a successful login that may have originated from a suspicious device.

Detecting Impossible Travel

The team combines authentication events with geographic information.

Example:

Previous login:

geo.country = Canada

New login minutes later:

geo.country = Germany

Combined with:

device.fingerprint changed

the system can identify potentially compromised accounts.

Detecting Repeated Failed Authentication Attempts

Dynamic fields allow the team to track:

authentication.user
authentication.result
network.source.ip
device.fingerprint

This enables detections for:

• Password spraying
• Credential stuffing
• Brute-force attacks
• Automated login attempts

For brute-force detection strategies, see Wazuh Brute Force Detection Guide.

Identifying High-Risk Sessions

The security team creates alerts for sessions where:

risk.score >= 90

Additional context is included:

Customer ID
Username
Location
Device fingerprint
API endpoint
Session ID

This allows analysts to immediately understand why the session was considered suspicious.

Improving Alert Quality and Investigations

Before implementing dynamic fields, analysts had to manually search raw application logs to find important details.

After implementing dynamic fields, alerts contain structured information:

Alert:
High-risk customer portal authentication detected

User:
jane.smith

Customer:
CUST-48291

Risk Score:
87

Location:
Toronto, Canada

Device:
dfp-8a92bc

Endpoint:
/api/account/login

This provides several operational improvements:

• Faster incident investigations
• Better analyst decision-making
• More accurate threat detection
• Reduced manual log searching
• Improved incident response times

Creating Richer Dashboards

Because dynamic fields become searchable attributes, the security team can build dashboards showing:

• Failed authentication trends
• High-risk sessions
• Login activity by country
• Suspicious devices
• Customer account targeting
• API authentication patterns

Instead of viewing unstructured log messages, analysts can interact with organized security data.

This improves visibility across the entire hybrid environment, including:

• Linux servers
• Windows endpoints
• Kubernetes workloads
• Cloud services
• Custom applications

Avoiding Application Changes

One of the biggest advantages of dynamic fields is that the security team does not need to modify the customer portal.

The application continues producing its existing logs while Wazuh handles the translation layer.

This approach provides:

• Faster security integration
• Lower development effort
• Reduced application risk
• Flexible detection engineering

Dynamic fields allow organizations to adapt Wazuh to their environment instead of forcing every application to conform to a fixed logging format.

Frequently Asked Questions (FAQ)

Question: What are Wazuh Dynamic Fields?

Wazuh Dynamic Fields are custom fields created during the decoding process that allow Wazuh to extract and store information using flexible field names.

They enable organizations to parse custom application logs, JSON events, cloud logs, and proprietary formats without being limited to predefined fields.

Question: How are dynamic fields different from static fields?

Static fields are predefined fields supported by Wazuh, such as:

srcip
dstip
user
hostname

Dynamic fields allow organizations to create custom fields such as:

cloud.region
customer.id
authentication.mfa
device.fingerprint
risk.score

Dynamic fields provide greater flexibility for modern structured logs.

Question: Can dynamic fields be used in custom rules?

Yes.

Custom Wazuh rules can reference dynamic fields extracted by decoders.

For example:

<field name="risk.score">90</field>

Rules can combine multiple dynamic fields to create highly specific detections.

See How to Create Custom Detection Rules in Wazuh (With Examples).

Question: Do dynamic fields support JSON logs?

Yes.

Dynamic fields are especially useful for JSON logs because they can preserve nested structures.

Examples:

cloud.region
user.name
kubernetes.namespace
http.request.method

This makes them ideal for cloud platforms, Kubernetes environments, APIs, and modern applications.

Question: Is there a limit to the number of dynamic fields?

Dynamic fields are not restricted to a small predefined list like static fields.

However, practical limitations still exist:

• Storage capacity
• Indexing performance
• Search performance
• Dashboard complexity
• Overall event volume

Only extract fields that provide security or operational value.

Question: Can dynamic fields contain nested values?

Yes.

Dynamic fields commonly represent nested data using dot notation.

Example JSON:

{
  "user": {
    "name": "alice"
  }
}

Can become:

user.name = alice

This structure makes complex events easier to search and analyze.

Question: How do I test dynamic field extraction?

Use the Wazuh Logtest utility.

The testing process:

1. Provide a sample log.
2. Verify decoder matching.
3. Review extracted fields.
4. Confirm rule execution.
5. Correct any parsing issues.

Always validate custom decoders before deploying them into production.

Question: Why are my dynamic fields not appearing in alerts?

Common causes include:

• Decoder did not match the log
• Regex capture groups are incorrect
• <order> fields do not match captures
• Rule references the wrong field name
• Decoder changes were not loaded
• JSON paths are incorrect

Start troubleshooting with wazuh-logtest to confirm whether the fields are extracted before investigating the rule.

Conclusion

Wazuh Dynamic Fields provide a flexible way to extract, organize, and analyze custom log data from modern security environments.

Unlike traditional static fields, dynamic fields allow organizations to adapt Wazuh to almost any data source, including:

• Cloud provider logs
• Kubernetes audit events
• Web applications
• API gateways
• SaaS platforms
• Proprietary business applications

By creating custom dynamic field decoders, security teams can preserve valuable context that would otherwise remain hidden inside raw logs.

When combined with custom detection rules, dynamic fields enable:

• More accurate threat detection
• Richer security alerts
• Faster investigations
• Better dashboards
• Improved incident response
• Scalable monitoring across complex environments

Before deploying custom decoders, always validate extraction logic with wazuh-logtest.

Testing ensures that fields are mapped correctly and that detection rules behave as expected.

A well-designed dynamic field strategy transforms Wazuh from a simple log monitoring platform into a highly adaptable security analytics solution capable of understanding any organization’s unique data sources.