An educational research note. Not a customer case study or a detection rule validated in production.
Define the behavior to investigate
A useful rule starts with a question an analyst can answer: which actor performed which behavior on which system? A newly created scheduled task may warrant investigation; software updates and maintenance tools also create tasks. A task name or a single event ID does not explain intent.
This note describes an educational approach; it is neither a customer case study nor a production-validated rule. Writing down the objective and excluded behaviors establishes what subsequent tests should demonstrate.
Verify the telemetry chain
Windows Security event 4698 records task creation; the relevant audit configuration and collection pipeline must be verified. The source event, collector, parser, index and search are separate checkpoints.
- Check that an authorized test event reaches both the source log and the SIEM.
- Compare event time, host, account and task fields with the raw record.
- Document missing fields, alternative extraction names and collection delays.
An empty search result alone does not demonstrate that the behavior did not occur. Check visibility and retention first.
Build an initial view with SPL
The SPL below is a baseline template, not an attack detection rule. Replace YOUR_WINDOWS_INDEX, EventCode and the other fields with your parser's schema. Do not publish sensitive records.
index=YOUR_WINDOWS_INDEX EventCode=4698 earliest=-7d@d latest=now
| eval task_name=coalesce(TaskName, Task_Name, "(missing)")
| eval actor=coalesce(SubjectUserName, Subject_User_Name, "(missing)")
| stats count min(_time) AS first_seen max(_time) AS last_seen BY host actor task_name
| sort -countcoalesce selects the first non-NULL value; it does not validate conflicting fields. stats groups records. -7d@d snaps the start to a day boundary; the time window is specified in the search. The first and last time values are returned as numeric epoch timestamps.
Test detection logic under three conditions
Write the expected outcome before testing a rule developed from the baseline. Testing only matching events conceals false alarms and visibility gaps.
| Scenario | Check |
|---|---|
| Positive test | Does an authorized synthetic event satisfy the defined condition and produce the expected evidence? |
| Negative test | Can approved maintenance using the same name or tool be distinguished? |
| Missing data | Is the result marked as not reliably assessable when a required field or source is unavailable? |
Record exceptions and decision limits
Do not base exceptions solely on a process name. Narrow them using the account, host group, executed command and approved change context. Review execution frequency, lookback and alert grouping together.
The output should include the schema used, test results, known gaps and the analyst's next query. AI may suggest a draft; it becomes a validated rule only after parser checks, test evidence and human review are complete.