Description
Develop and evaluate detection rules based on behaviors observed in the deception environment, then deploy them through the organization's normal testing and change-control process. Observations provide useful context but do not guarantee rule accuracy in production.
Rationale
Observed deception interactions can provide concrete examples for detection engineering. Rules derived from them should still be tested against representative production data, tuned for benign overlap, and treated as hypotheses about reusable behavior rather than automatically high-confidence detections.
Supporting Basis
Literature-informed designATT&CK supports detection-analytic development and MITRE Engage discusses signatures, YARA rules, and mitigations derived from collected evidence; the record is a ShadowMatrix formulation.
- The MITRE Corporation. A Practical Guide to Adversary Engagement, version 1.0. 2022.Technical guide
- Strom, B.E. et al. MITRE ATT&CK: Design and Philosophy. The MITRE Corporation, revised 2020.Technical report
These sources establish design lineage and scope. They do not validate this record's operational effectiveness, planning estimates, environment labels, or ATT&CK relationships.
Implementation Steps
Review TTP analysis outputs
Examine the TTP catalog and ATT&CK mappings from the analysis phase. Identify techniques that are not currently covered by production detection rules.
Develop detection logic
For each uncovered technique, develop detection rules using the specific procedures, tools, and indicators observed in the deception environment.
Test against deception data
Validate new detection rules against the deception telemetry that prompted their creation. Confirm they would have detected the observed activity.
Deploy to production
Deploy validated rules to production SIEM, EDR, and network detection systems. Monitor for false positives during the initial tuning period.
Technical Implementation Examples(1)
Sigma Detection Rule from Observed TTP
Detection rule developed directly from adversary behavior observed in the deception environment
# sigma/rules/shadow-cdf/observed-config-file-access.yml
# Derived from deception engagement SHD-2026-0042
# Adversary read application config files to harvest DB credentials.
# This pattern was NOT detected by existing production rules.
title: Application Config File Access - Credential Harvesting
id: b2c3d4e5-f678-4901-2345-6789abcdef01
status: stable
description: >
Detects process accessing application configuration files that
commonly contain database credentials and API keys. Derived from
observed adversary behavior in ShadowMatrix CDF engagement SHD-2026-0042
where the adversary read database.yml to harvest production
database credentials.
references:
- https://shadow-cdf-matrix.internal/reports/SHD-2026-0042
author: ShadowMatrix CDF - Deception Intelligence
date: 2026/03/28
tags:
- attack.credential_access
- attack.t1552.001
- shadow_cdf.deception_derived
logsource:
product: linux
category: file_access
detection:
selection_files:
TargetFilename|endswith:
- '/database.yml'
- '/database.yaml'
- '/db_credentials.cfg'
- '/.env'
- '/production.json'
- '/secrets.yml'
TargetFilename|contains:
- '/config/'
- '/etc/'
- '/.aws/'
selection_processes:
Image|endswith:
- '/cat'
- '/less'
- '/more'
- '/head'
- '/tail'
- '/vim'
- '/nano'
- '/python'
- '/python3'
- '/curl'
filter_legitimate:
User:
- 'root'
- 'www-data'
- 'deploy'
ParentImage|endswith:
- '/cron'
- '/systemd'
- '/ansible'
condition: selection_files and selection_processes
and not filter_legitimate
falsepositives:
- Developers reading config files during troubleshooting
- Deployment automation reading configs
level: high
fields:
- User
- Image
- TargetFilename
- ParentImage
- CommandLineConsiderations
- Detection rules should target the behavioral pattern, not just specific IOCs. Adversaries change their infrastructure frequently, but their operational patterns evolve more slowly.
- Test rules for false positive rates against production data before full deployment. High-confidence deception observations may still generate noise in noisier production environments.
- Document the provenance of each rule. Knowing that a rule was derived from observed adversary behavior helps prioritize it during triage.
Supported Environments
Tools & Resources
- SIEM rule engines (Sigma, Wazuh rules, Splunk SPL)
- EDR detection capabilities
- Detection rule testing frameworks
- Sigma rule converter
Related Techniques
Quick Stats
- Phase
- Respond
- Difficulty
- advanced
- Detection Value
- critical
- Cost
- low
- Time
- 3-7 days
- ATT&CK Mappings
- 0