[New Rule] Multiple DHCP Servers Responding to the Same Transaction

[eric-forte-elastic]

Pull Request

Issue link(s):

Summary - What I changed

Adds a new network detection rule that flags two or more distinct DHCP servers sending an OFFER or ACK for the same DHCP transaction ID (xid) within a short window. This is likely a rogue DHCP server racing a legitimate one to deliver its response first.

This is the network signal may be used in exploiting CVE-2026-44815, a stack-based buffer overflow in the Windows DHCP Client service that is triggered by a malformed DHCP OFFER/ACK with crafted option fields, leading to unauthenticated remote code execution on the client. The same structural anomaly also covers classic DHCP spoofing / adversary-in-the-middle (T1557.003).

How To Test

Unit Tests, Data in shared stack, and RTA available.

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[Copilot]

Pull request overview

Adds a new ES|QL network detection rule to identify potentially rogue DHCP behavior by flagging cases where multiple distinct DHCP servers respond (OFFER/ACK) to the same DHCP transaction ID within a short time window, supporting detection of DHCP spoofing/Adversary-in-the-Middle activity and potential client-side exploitation scenarios.

Changes:

• Introduces a new rules/network detection rule for “multiple DHCP servers responding to the same transaction”.
• Adds an ES|QL query that aggregates DHCP OFFER/ACK traffic by transaction ID and time window to detect multiple responding servers.
• Includes Setup guidance and an Investigation Guide tailored to network sensor placement and response actions.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Multiple DHCP Servers Responding to the Same Transaction (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta