What can we observe?

The evidence shows how a PowerShell signal can mix legitimate administration with activity labelled malicious and how a pwsh.exe variant is missed when only powershell.exe is searched.

Synthetic process-creation events from the powershell dataset with a Sysmon logsource.

Availability in this example: available

Collection prerequisites: Enable and retain Sysmon Process Create events with Image and ParentImage; retain CommandLine and User when available, without transforming paths.

Image · rule condition

Literal executable path; it is the shared condition in the preset and improved rules.

ParentImage · rule condition

Literal parent-process path; the improved variant needs it to narrow launches from WINWORD.EXE.

CommandLine · context

Command line retained as event context; it is absent from PS-07 and is not treated as a label.

User · context

Synthetic event user for administrative and activity context; it does not prove intent.

The dataset is a synthetic, simplified sample, not production telemetry. PS-07 lacks CommandLine and PS-08 is DNS; the rule performs no temporal correlation, executes no commands, and does not by itself prove an intrusion.

Legitimate activity to consider

• Authorized inventory launched by an administrator from Explorer.
• Approved maintenance with an encoded command from taskeng.exe.
• Activity from another source, such as a DNS query, outside process creation.

What this does not demonstrate

• Events, labels, and paths are synthetic and support condition comparison rather than an estimate of real protection.
• Searching only for powershell.exe misses the pwsh.exe variant; adding a parent process reduces noise in this dataset but does not cover every variant.
• Missing CommandLine context does not make an event a true negative; if a condition field is absent, the matcher does not match and the result remains limited by the labels.

Synthetic example traceability

• detection / powershell / v1.0
  PS-01, PS-02, PS-03, PS-04, PS-05, PS-06, PS-07, PS-08

Documentation references; not logs from a real environment:

• PowerShell technique in MITRE ATT&CK
• PowerShell logging in Microsoft documentation
• Sysmon in Microsoft Sysinternals
• Open bench and choose “PowerShell: context matters”

The entry shows that task creation is a concrete signal, while simplified TaskContent can narrow a hypothesis and also miss another path; the Public path has legitimate uses.

Synthetic security events for task creation from the scheduled-task dataset.

Availability in this example: available

Collection prerequisites: Enable task-creation auditing and retain event 4698 with the action and task name; preserve complete content where the platform provides it.

EventID · rule condition

Textual 4698 identifier used by the preset rule and improved variant.

TaskContent · rule condition

Task action as a simplified path; the improved variant uses it to narrow the example.

TaskName · context

Task name for reviewing persistence and distinguishing examples.

SubjectUserName · context

User recorded in the synthetic event; it does not show that the account is malicious.

TaskContent is a simplified text path, not complete Windows XML. TASK-05 loses the action and TASK-06 is a schtasks process event outside this source; the example does not prove real persistence or intent.

Legitimate activity to consider

• Approved backup task with a path under Program Files.
• Authorized trainer demonstration using the Users\Public path.
• A task query through schtasks.exe, which belongs to another event source.

What this does not demonstrate

• The sample is synthetic; creating a task is not enough to declare an incident and a specific path can change.
• The example TaskContent field does not represent complete XML or every way a task action can be recorded.
• An event without an action remains without a reliable label; that missing field is not a true negative.

Synthetic example traceability

• detection / scheduled-task / v1.0
  TASK-01, TASK-02, TASK-03, TASK-04, TASK-05, TASK-06

Documentation references; not logs from a real environment:

• Scheduled Task technique in MITRE ATT&CK
• Windows event 4698
• Open bench and choose “Scheduled tasks: persistence or maintenance”

Synthetic records show that LogonType 10 can include authorized support and activity labelled malicious; one address narrows this example but does not replace account investigation.

Synthetic Windows authentication events from the authentication dataset.

Availability in this example: available

Collection prerequisites: Collect the Security authentication log and retain EventID, LogonType, IpAddress, and TargetUserName with authorization context.

LogonType · rule condition

Textual logon type; 10 is the shared condition for the remote interactive signal.

IpAddress · rule condition

Source address used by the improved variant; fixture addresses are documentation-only.

EventID · context

Textual identifier that separates 4624 success from 4625 failure in the example.

TargetUserName · context

Target account retained to review who appears in the event; it does not prove misuse.

The sample is synthetic and each event is evaluated in isolation: it does not correlate session, time, MFA, or owner. AUTH-06 lacks IpAddress and AUTH-07 is another source; a remote logon does not prove abuse.

Legitimate activity to consider

• Approved support RDP session for the support account.
• A service network access with LogonType 3, outside the remote interactive signal.
• A technician password typo recorded as 4625.

What this does not demonstrate

• This exercise's label depends on fictional context; LogonType 10 alone does not identify an attacker.
• The 192.0.2.0/24 and 198.51.100.0/24 addresses are documentation ranges, not user locations.
• The event without an IP and the incompatible source are outside scored scope; that absence is not evidence of absence.

Synthetic example traceability

• detection / authentication / v1.0
  AUTH-01, AUTH-02, AUTH-03, AUTH-04, AUTH-05, AUTH-06, AUTH-07

Documentation references; not logs from a real environment:

• Valid Accounts technique in MITRE ATT&CK
• Windows event 4624
• Open bench and choose “Windows sign-ins: signal and noise”

This entry preserves which operation and parameters appear in an Exchange audit record from the mailbox-change case; it is documentary evidence for investigation, not a detection evaluation.

Synthetic Exchange audit records from the identity mailbox-change case.

Availability in this example: available

Collection prerequisites: Request the Exchange/Purview audit export with its scope and retention, and retain original AuditData and Parameters with time and authorized context.

Operation · context

Audit operation, such as New-InboxRule, needed to describe the observed change.

Parameters · context

Original parameters; the Name=ForwardTo item documents the configured destination.

ResultStatus · context

Textual operation result retained as audit context.

CreationTime · context

Synthetic creation time for ordering the window review.

ClientIP · context

Client IP from the synthetic record; it is documentation-only and does not verify a network origin.

SessionId · context

Fixture session identifier for comparing records, without equating it to other sources.

AuditData · context

Serialized original payload retaining the example's complete audit fields.

The records are synthetic and documentary. ForwardTo describes configuration, not delivery, reading, or exfiltration; this entry runs no detector and calculates no metrics.

Legitimate activity to consider

• Routine rule moving newsletters to an internal folder with MoveToFolder.
• Filter change within an authorized maintenance window.
• Aggregated MailItemsAccessed access retained as independent context, not delivery.

What this does not demonstrate

• The source is a synthetic audit reproduction; it is not a tenant log or forensic evidence.
• ForwardTo does not prove that a message reached the external recipient, was read, or was exfiltrated.
• Temporal proximity or a matching IP guides investigation but does not automatically join an identity session to the operation.
• There are no detection results, performance metrics, or associated detector for a documentary source.

Synthetic example traceability

• identity / mailbox-change / v1
  mailbox-exchange-forwarding, mailbox-exchange-routine-rule, mailbox-owner-denial

Documentation references; not logs from a real environment:

• Email Forwarding Rule technique in MITRE ATT&CK
• New-InboxRule ForwardTo parameter
• Exchange audit properties
• Review the identity lab

Headers and body help structure a provenance and context review; the example comes from an educational case and contains no detector or incident decision.

Synthetic plain-text email from the case mailbox-change-notice example.

Availability in this example: available

Collection prerequisites: Retain the original message and complete headers with timezone, separated from attachments or active content; review provenance before sharing.

From · context

Sender header retained to review the declared identity and documentation domain.

To · context

Recipient header for delimiting the case context.

Subject · context

Plain-text subject for comparing the declared topic, without treating it as a classification.

Date · context

Declared date with an explicit zone for ordering the email within the synthetic window.

Received · context

Sample Received headers for reviewing a described, unverified route.

Message-ID · context

Synthetic message identifier for retaining the case reference.

Content-Type · context

Fixture text/plain type; confirms the scope of the sample content.

This is a synthetic plain-text sample: Received describes invented text and the IPs are documentation-only. Headers guide review but do not prove phishing, delivery, authorship, or compromise.

Synthetic mailbox-change case context with an owner note and an authorized window.

Availability in this example: available

Collection prerequisites: Retain notes and editorial provenance separately; confirm authorization and scope with the corresponding source before relating them to headers.

kind · context

Synthetic note type separating ticket and authorized change.

statement · context

Owner statement retained as supplied context, not a Microsoft log.

requestedAction · context

Requested action in the note to guide preservation and review.

window · context

Authorized change window for keeping an alternative explanation open.

scope · context

Textual scope of the authorized change in the fixture.

The context is invented and is not a Microsoft ticket or log. A temporal or IP match only guides review; it does not turn the email into phishing or establish causality.

Legitimate activity to consider

• Internal filter-review notice sent from an authorized change desk.
• Documentation headers with reserved domains and IPs, without an executable attachment.
• A maintenance note that keeps a legitimate explanation open for the window.

What this does not demonstrate

• The email and context are synthetic educational material; they are not captured mail, a real ticket, or forensic evidence.
• The relationship to T1566 is indicative: headers and proximity do not prove successful phishing, delivery, a click, credential theft, or compromise.
• The owner note and authorized window are distinct contexts; they must not be mixed into an automatic classification.
• There is no detector, detection result, or performance metric for this documentary evidence.

Synthetic example traceability

• email / mailbox-change-notice / v1
  message
• identity / mailbox-change / v1
  mailbox-owner-denial, mailbox-authorized-change

Documentation references; not logs from a real environment:

• Phishing technique in MITRE ATT&CK
• Microsoft anti-phishing protection
• Open workspace and select “Open guided example”