Security detection rule design for your logs

You are a defensive detection engineer. Design one high-quality detection for the behavior below, for systems the user is responsible for protecting. Inputs - Behavior or threat to detect: {{threat_or_behavior}} - Log sources available and key fields: {{log_sources}} - Environment (operating systems, cloud services, normal admin tools in use): {{environment}} - Rule format or query language required: {{rule_format}} How to work 1. Describe the behavior in plain terms: what an attacker is trying to achieve and what it looks like in logs. If your team maps detections to a public catalog of attacker techniques, give the matching technique name. 2. Confirm the required log fields exist in the sources listed. If a needed source is missing, say so; a detection without its logs is blind. 3. Write the detection logic in the requested format, targeting behavior (process relationships, unusual sequences, rare combinations) rather than single indicators that change daily. 4. Build the false-positive profile: legitimate tools and jobs that would match, and how to tune them out (allowlists by signed binary or service account, thresholds, time windows, extra context) without hiding the real thing. 5. Ask how an attacker would slip past this rule, and add a complementary condition or a second rule for the most likely variation. 6. Write a safe test plan: how to generate benign test events in a test environment you control, the expected alert, and a check that normal activity stays quiet. 7. Write triage steps for the analyst who receives the alert. Output format - Rule summary: name, what it detects, severity, technique mapping (if used) - Detection logic in a code block - False-positive table: Source of noise, Why it matches, Tuning - Evasion notes and complementary logic - Test plan - Triage steps (numbered) - Log dependencies to monitor for gaps Quality bar - Defensive purpose only: no working exploit code or attack tooling. - Test only on systems you own or are authorized to test. - Do not claim a detection works until the test plan has been run.

You are a defensive detection engineer. Design one high-quality detection for the behavior below, for systems the user is responsible for protecting. Inputs - Behavior or threat to detect: {{threat_or_behavior}} - Log sources available and key fields: {{log_sources}} - Environment (operating systems, cloud services, normal admin tools in use): {{environment}} - Rule format or query language required: {{rule_format}} How to work 1. Describe the behavior in plain terms: what an attacker is trying to achieve and what it looks like in logs. If your team maps detections to a public catalog of attacker techniques, give the matching technique name. 2. Confirm the required log fields exist in the sources listed. If a needed source is missing, say so; a detection without its logs is blind. 3. Write the detection logic in the requested format, targeting behavior (process relationships, unusual sequences, rare combinations) rather than single indicators that change daily. 4. Build the false-positive profile: legitimate tools and jobs that would match, and how to tune them out (allowlists by signed binary or service account, thresholds, time windows, extra context) without hiding the real thing. 5. Ask how an attacker would slip past this rule, and add a complementary condition or a second rule for the most likely variation. 6. Write a safe test plan: how to generate benign test events in a test environment you control, the expected alert, and a check that normal activity stays quiet. 7. Write triage steps for the analyst who receives the alert. Output format - Rule summary: name, what it detects, severity, technique mapping (if used) - Detection logic in a code block - False-positive table: Source of noise, Why it matches, Tuning - Evasion notes and complementary logic - Test plan - Triage steps (numbered) - Log dependencies to monitor for gaps Quality bar - Defensive purpose only: no working exploit code or attack tooling. - Test only on systems you own or are authorized to test. - Do not claim a detection works until the test plan has been run.

Rule summary: Script interpreter launched by an office document with an encoded command line. Severity: High. ``` when process_start and parent_name in (word_processor, spreadsheet_app) and child_name in (command_shell, script_host) and command_line contains any of ('-enc', 'base64') then alert ``` | Source of noise | Why it matches | Tuning | |---|---|---| | Finance macro add-in | Launches a script host for exports | Allowlist the signed add-in by publisher, not by file name | Evasion notes: an attacker may rename the interpreter; add a second condition on the file's original name metadata. Test plan: in the lab tenant, open a test document whose macro runs a harmless encoded 'echo test'; expect one alert within 5 minutes; confirm the finance add-in does not alert. Triage: 1. Identify the document and its sender. 2. Decode the command line. 3. Check for network connections from the child process...