[New Rule] Threat Intel Email Indicator Match

[w0rk3r]

Issues

Resolves #2890

Summary

Adds a new Indicator match rule for email IoCs, configured to match the relevant ECS email fields.

Alert Fired:

How to test

As I didn't had any email related logs, tests can be done using synthetic data:

1- Create the test indexes:

PUT logs-ti_test
PUT _data_stream/logs-test-rule

2- Ingest an indicator with the needed data

POST logs-ti_test/_doc
{
  "threat.indicator.email.address": "[email protected]",
  "event": {
    "category": "threat",
    "kind": "enrichment",
    "type": "indicator",
    "module": "threatintel",
    "ingested": "2025-04-04T17:00:00.162825789Z"
  },
  "@timestamp": "2025-04-04T17:00:00.162825789Z"
}

3- Ingest an event to be matched (Modify the timestamps to be within 1h less than current time)

POST logs-test-rule/_doc
{
  "email.from.address": "[email protected]",
  "event": {
    "kind": "event",
    "ingested": "2025-04-03T17:01:00.162825789Z"
  },
  "@timestamp": "2025-04-03T17:01:00.162825789Z"
}

4- Import the rule and enable it:

Rename it back to ndjson and import it in the SIEM
20250404T155029L.json

[github-actions]

Enhancement - Guidelines

These guidelines serve as a reminder set of considerations when addressing adding a new schema feature to the code.

Documentation and Context

• Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
• Include additional context or screenshots.
• Ensure the enhancement includes necessary updates to the documentation and versioning.

Code Standards and Practices

• Code follows established design patterns within the repo and avoids duplication.
• Code changes do not introduce new warnings or errors.
• Variables and functions are well-named and descriptive.
• Any unnecessary / commented-out code is removed.
• Ensure that the code is modular and reusable where applicable.
• Check for proper exception handling and messaging.

Testing

• New unit tests have been added to cover the enhancement.
• Existing unit tests have been updated to reflect the changes.
• Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
• Validate that any rules affected by the enhancement are correctly updated.
• Ensure that performance is not negatively impacted by the changes.
• Verify that any release artifacts are properly generated and tested.

Additional Schema Related Checks

• Ensure that the enhancement does not break existing functionality. (e.g., run make test-cli)
• Review the enhancement with a peer or team member for additional insights.
• Verify that the enhancement works across all relevant environments (e.g., different OS versions).
• Confirm that all dependencies are up-to-date and compatible with the changes.
• Link to the relevant Kibana PR or issue provided
• Exported detection rule(s) from Kibana to showcase the feature(s)
• Converted the exported ndjson file(s) to toml in the detection-rules repo
• Re-exported the toml rule(s) to ndjson and re-imported into Kibana
• Updated necessary unit tests to accommodate the feature
• Applied min_compat restrictions to limit the feature to a specified minimum stack version
• Executed all unit tests locally with a test toml rule to confirm passing
• Included Kibana PR implementer as an optional reviewer for insights on the feature
• Implemented requisite downgrade functionality
• Cross-referenced the feature with product documentation for consistency
• Incorporated a comprehensive test rule in unit tests for full schema coverage
• Conducted system testing, including fleet, import, and create APIs (e.g., run make test-remote-cli)
• Confirm that the proper version label is applied to the PR patch, minor, major.

[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

• ❌ Threat Intel Email Indicator Match (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Threat Intel Email Indicator Match (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Threat Intel Email Indicator Match (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Threat Intel Email Indicator Match (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta