IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

PowerShell Invoke-NinjaCopy script

edit

Detects PowerShell script block content containing Invoke-NinjaCopy or related Stealth* functions used for direct volume file access. Attackers use NinjaCopy to read locked system files such as NTDS.dit or registry hives for credential dumping.

Rule type: query

Rule indices:

  • logs-windows.powershell*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: PowerShell Logs
  • Resources: Investigation Guide

Version: 113

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating PowerShell Invoke-NinjaCopy script

Possible investigation steps

  • Does the alert-preserved script content show active NinjaCopy direct-volume access rather than inert reference text?
  • Focus: powershell.file.script_block_text, powershell.file.script_block_length, and file-backed file.path or file.name.
  • Implication: escalate sooner when the fragment shows Invoke-NinjaCopy, StealthOpenFile, StealthReadFile, credential-store targets, output destinations, or cleanup logic; lower concern only for inert example or recognized validation content that later recovery does not contradict.
  • Does full script reconstruction reveal target, destination, or cleanup behavior that the matching fragment did not show?
  • Why: Script Block Logging can split one script across events; later fragments often contain output paths, loops, or cleanup logic that change urgency.
  • Focus: reconstruct on host.id + powershell.file.script_block_id, ordering by powershell.sequence / powershell.total; read powershell.file.script_block_text for "-Path", "-ComputerName", "-LocalDestination", or "-RemoteDestination". !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: if powershell.sequence is missing or never reaches powershell.total, record the gap before treating the script as understood.
  • Implication: escalate when reconstruction adds remote targets, credential stores (NTDS.dit, SAM, SYSTEM, SECURITY), temp/share destinations, large copy buffers, archive paths, encoding, or delete-after-copy logic; lower concern when the full script is confirmed lab, forensic, or validation content with no hostile follow-on behavior.
  • Does the script provenance and reconstructed target fit a recognized workflow?
  • Focus: file.path, file.name, user.id, host.id, and reconstructed "-Path", "-ComputerName", "-LocalDestination", or "-RemoteDestination".
  • Hint: if file.path is absent, treat content as inline, generated, interactive, or remote; do not close on path absence alone.
  • Implication: escalate when source is temp, downloads, or user-writable shares, or parameters name remote servers, NTDS.dit, registry hives, or staging destinations; lower concern when source, targets, and destinations match one recognized forensic, IR, lab, or validation workflow.
  • Do surrounding script blocks from the same user and host show staging, retries, or variant logic?
  • Focus: manually search the same execution window for user.id, host.id, powershell.file.script_block_text, and adjacent powershell.file.script_block_id values.
  • Hint: renamed wrappers may omit Invoke-NinjaCopy; still check Stealth* helpers and reconstructed target or destination values.
  • Implication: escalate when adjacent fragments show retries, renamed helpers, alternative raw-volume logic, output-file reuse, or follow-on compression and cleanup.
  • Can process telemetry recover the PowerShell process and explain how it was launched?
  • Focus: match the PowerShell PID on host.id, process.pid, and @timestamp; record process.entity_id, then interpret process.command_line, process.parent.command_line, and process.Ext.token.integrity_level_name. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: recover the matching process via host.id + process.pid before using process.* or process.parent.*. If no process start event appears, expand the window because PowerShell can predate the script block; if still absent, bound file review to host.id, user.id, process.pid, and alert time.
  • Implication: escalate when recovery shows encoded commands, remote-admin launchers, Office/browser ancestry, or unexpected high-integrity execution; unresolved process recovery does not make direct-volume script content benign.
  • Do file events confirm copied credential stores or staging artifacts?
  • Focus: endpoint file events scoped to host.id, process.pid, and alert time; review file.path, file.directory, and file.name. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when file activity confirms copied hives, NTDS.dit, archives, or renamed staging files; missing file telemetry is unresolved, not benign.
  • If the local script, launch, or artifact answers remain suspicious or unresolved, is this script block isolated, or part of broader suspicious activity for the same user or host?
  • Focus: related user.id alerts for repeated credential access, execution, or post-compromise behavior. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare host.id alerts for credential access, persistence, or staging. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broaden scope when either view shows adjacent credential-access or post-compromise behavior; keep it local only when both are quiet and the local evidence fits one recognized workflow.
  • Escalate when script content, reconstruction, target parameters, launch context, or artifacts show unauthorized direct-volume access or credential-store targeting; close only when source path, targets, destinations, launch context, and artifacts align with one recognized forensic, IR, lab, or validation workflow; preserve and escalate if mixed or incomplete.

False positive analysis

  • Recognized red-team, security-validation, forensic-acquisition, or IR workflows can legitimately include NinjaCopy-derived code. Confirm only when powershell.file.script_block_text, reconstructed targets/destinations, file.path, user.id, host.id, and recovered launch context align with the same workflow. If records are unavailable, prior recurrence can support but not replace local telemetry proof; first occurrences stay candidate exceptions.
  • Build exceptions from user.id, host.id, stable file.path, recovered parent-launch pattern when available, and the powershell.file.script_block_text pattern. Avoid exceptions on "Invoke-NinjaCopy", user.name, or host alone.

Response and remediation

  • If confirmed benign, reverse containment and document the recognized workflow: user.id, host.id, file.path, powershell.file.script_block_id, recovered launch context, and reconstructed target or destination values. Create an exception only if the same pattern recurs across prior alerts.
  • If suspicious but unconfirmed, preserve reconstructed powershell.file.script_block_text, powershell.file.script_block_id, powershell.sequence, process.pid, recovered launch context, target or destination values, and file.path before cleanup. Apply reversible containment first; escalate to host isolation only if copied credential artifacts, staging, or broader post-compromise activity appears.
  • If confirmed malicious, preserve the reconstructed script, launch context, targets, destinations, copied stores, and related alerts first. Then use reversible endpoint response to isolate the host when needed; if unavailable, escalate with the preserved artifact set to the team that can act. Record all evidence before terminating processes or deleting files.
  • If "NTDS.dit", "SAM", "SYSTEM", or "SECURITY" targeting is confirmed with copied artifacts, follow the organization’s credential-exposure playbook and prioritize privileged-account hygiene.
  • Before eradicating, review related hosts for the same script pattern, file.path destinations, and recovered parent-launch pattern. Then remove unauthorized scripts, copied stores, archives, and persistence mechanisms and remediate the delivery path.
  • Post-incident hardening: restrict direct-volume-copy tooling to controlled acquisition hosts, retain PowerShell Script Block Logging and endpoint file/process telemetry, and document the recognized workflow pattern for future analysts.

Setup

edit

Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). Setup instructions: https://ela.st/powershell-logging-setup

Rule query

edit
event.category:process and host.os.type:windows and
  powershell.file.script_block_text : (
    "StealthReadFile" or
    "StealthReadFileAddr" or
    "StealthCloseFileDelegate" or
    "StealthOpenFile" or
    "StealthCloseFile" or
    "Invoke-NinjaCopy"
   ) and
  not powershell.file.script_block_text : (
    "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators"
  )

Framework: MITRE ATT&CKTM