DOSSIER 2

Encoded PowerShell and a scheduled task

When does the name of a process or a path stop being enough to judge an alert?

Synthetic case for educational purposes. Not real telemetry nor an audit.

Context

Two independent scenarios from the detection bench: a PowerShell process with an encoded command launched under an Office macro, and the creation of a scheduled task pointing to a public write folder. Both share the same underlying problem: the most visible indicator also appears in legitimate activity within the same set.

Cited evidence

Each citation points to a concrete record in a versioned dataset. You can open it in its lab and see the same thing.

  1. Detection bench · powershell · version 1.0 · PS-01

    Event labeled malicious: PowerShell with an encoded fragment, launched by WINWORD.EXE.

  2. Detection bench · powershell · version 1.0 · PS-05

    Variant of the same pattern using pwsh.exe (PowerShell 7): a rule anchored to the name powershell.exe does not reach it.

  3. Detection bench · powershell · version 1.0 · PS-02

    Benign event with the same process (powershell.exe) but a different parent process (explorer.exe) and documented administrative use.

  4. Detection bench · scheduled-task · version 1.0 · TASK-01

    Event labeled malicious: task creation (EventID 4698) pointing to a public write folder.

  5. Detection bench · scheduled-task · version 1.0 · TASK-03

    Variant of the same incident with a different folder: a rule anchored to a single path does not cover it.

  6. Detection bench · scheduled-task · version 1.0 · TASK-04

    Benign event that uses the same public write path family in an authorized training demonstration.

Reasoning

  1. Event PS-01 shows powershell.exe with an encoded argument (-enc), launched by WINWORD.EXE: the process chain is the most informative data point, not the fragment itself.

    Based on: citation 1

  2. Event PS-02 uses the same binary (powershell.exe) benignly, launched from explorer.exe by an administrator with a documented change: the process name alone does not distinguish the two cases.

    Based on: citation 3

  3. Event PS-05 repeats the same pattern (macro followed by encoded PowerShell) but with pwsh.exe: a rule that literally searches for "powershell.exe" misses this variant.

    Based on: citation 2

  4. Event TASK-01 records a scheduled task creation (EventID 4698) whose action points to a public write folder, a common persistence pattern after initial execution.

    Based on: citation 4

  5. Event TASK-03 documents the same kind of persistence with a different folder: the same incident does not reduce to a single path.

    Based on: citation 5

  6. Event TASK-04 uses that same path family in an authorized training demonstration: the path, like the process name in the PowerShell case, does not discriminate on its own either.

    Based on: citation 6

Alternatives I ruled out

An honest investigation also shows what it could have been, and why it was not.

The powershell.exe process also appears in a benign event launched from explorer.exe, and the public write folder also appears in a legitimate training demonstration; each indicator, in isolation, could look sufficient to alert on.
Ruled out by: In the benign PowerShell event, the parent process is explorer.exe and the user is an administrator with a documented change, not WINWORD.EXE; in the training task, the subject is the trainer in a recorded training action, not the incident. The isolated indicator is not enough without the parent process or the action's subject and context.

Decision

Investigate · medium confidence

Both scenarios confirm that a process name or a path alone does not separate malicious from legitimate activity; the parent process or task content is needed, and gaps remain even so (a pwsh.exe variant, a different persistence folder) that call for human review before trusting a rule.

The detection I built

Requires the process to be powershell.exe AND its parent process to be WINWORD.EXE, instead of flagging any PowerShell.

Result over the labeled dataset powershell
True positives False positives True negatives False negatives
2 0 3 1

Adding the parent process removes the administrator's two false positives (precision 50%->100%), but the rule still misses the pwsh.exe variant (recall stays at 66.7%): anchoring to the binary name does not generalize across interpreter versions. On the scheduled-task scenario, adding only the public write folder does not help as much: it still flags the trainer's demonstration and also stops catching the variant that uses a different folder.

MITRE ATT&CK

What this dossier does NOT prove

  • The PowerShell and scheduled-task events are synthetic and belong to two independent scenarios in the test bench; they are not telemetry from a single incident or a single host.
  • The two scenarios using a similar username (ana) does not imply the same person, host, or incident: they are independent rule-tuning exercises, not a correlated case.
  • Only one rule was evaluated and verified, on the PowerShell scenario; the comparison with the scheduled-task scenario is a reading of the same bench, not a metric verified in this dossier.

Reproduce it yourself

The same data, in its lab. No signup needed.

← All dossiers