admin/elastic-detection-rules
1
0
Fork 0
mirror of https://github.com/elastic/detection-rules synced 2026-06-08 14:00:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

[Rule Tuning] PowerShell Rules Revamp - 2 (#5623)

Browse Source 
* [Rule Tuning] PowerShell Rules Revamp - 2

* Update credential_access_mimikatz_powershell_module.toml

* Apply suggestions from code review

(cherry picked from commit 2f9dc7af53)
This commit is contained in:
Jonhnathan
2026-01-26 19:35:05 -03:00
committed by tradebot-elastic
parent 545cb33ffc
commit 42461ba5fc
5 changed files with 446 additions and 198 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/windows/collection_posh_screen_grabber.toml
+101 -42
View File
@@ -2,13 +2,13 @@
creation_date = "2021/10/19"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/01/26"
[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that can take screenshots, which is a common feature in post-exploitation kits and remote
access tools (RATs).
Detects PowerShell script block content that uses CopyFromScreen with .NET bitmap classes to capture screenshots.
Attackers use screen capture to collect on-screen information and credentials.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
@@ -17,63 +17,103 @@ license = "Elastic License v2"
name = "PowerShell Suspicious Script with Screenshot Capabilities"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating PowerShell Suspicious Script with Screenshot Capabilities
PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, which makes it available for use in various environments and creates an attractive way for attackers to execute code.
This rule identifies PowerShell scripts that includes screenshot collection logic using `CopyFromScreen` together with bitmap classes. This pattern is commonly used to capture the interactive desktop and may indicate collection of sensitive on-screen data (for example, application content, authentication prompts, or remote session activity).
Attackers can abuse PowerShell capabilities and take screen captures of desktops to gather information over the course of an operation.
Prioritize alerts on endpoints used for privileged administration or sensitive workflows, and alerts tied to accounts that do not typically run interactive PowerShell automation.
#### Key alert fields to review
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
#### Possible investigation steps
- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Examine file or network events from the involved PowerShell process for suspicious behavior.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Evaluate whether the user needs to use PowerShell to complete tasks.
- Determine whether the script stores the captured data locally.
- Investigate whether the script contains exfiltration capabilities and identify the exfiltration server.
- Assess network data to determine if the host communicated with the exfiltration server.
- Establish alert scope and execution context:
- Identify the affected system using `host.name` and `host.id`. Determine if the host is expected to have an interactive desktop session for the associated user at the time of the alert.
- Identify the initiating account using `user.name`, `user.domain`, and `user.id`. Assess whether the account is a typical interactive user for the host and whether the activity aligns with the user role.
- Review the alert time (`@timestamp`) and determine whether the timing aligns with normal business operations for the user and host.
- Review and interpret the script block content:
- Examine `powershell.file.script_block_text` to understand what is being captured:
- Identify whether the capture targets the full screen or a specific region (for example, use of coordinates and dimensions passed into `CopyFromScreen`).
- Identify whether capture is repeated (for example, loops, timers, repeated invocations) which may indicate ongoing collection.
- Identify any logic that targets specific monitors, window bounds, or desktop layout.
- Determine how captured images are handled:
- Look for references indicating local image creation or saving (for example, image format usage such as PNG/JPEG/BMP, file extensions, or save routines).
- Look for encoding/staging behavior (for example, Base64 conversion, compression, or in-memory serialization) that could facilitate transfer.
- Note any referenced paths, filenames, or remote destinations embedded in the script, and capture unique strings for scoping and hunting.
- Reconstruct full script logic when split across events:
- Use `powershell.file.script_block_id` to collect all related fragments.
- Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.
- Re-review the reconstructed script for supporting capabilities beyond capture (for example, environment checks, staging, cleanup, or transfer logic).
- Use `powershell.file.script_block_length` to help identify unusually large or complex script blocks that may warrant deeper review.
- Identify script source and provenance:
- If `file.path`, `file.directory`, or `file.name` are present, treat the script as file-backed:
- Validate whether the location is expected for administrative or support scripts in your environment.
- Collect the referenced file for review and compare it to known-good versions or approved repositories where applicable.
- If file fields are not present, treat the activity as potentially inline or dynamically generated:
- Pay close attention to download, decode, or dynamic compilation patterns visible in `powershell.file.script_block_text`.
- Scope for related PowerShell activity using available pivots:
- On the same `host.id` and `user.id`, review surrounding script blocks near the alert time to identify related actions (for example, staging, transfer preparation, or artifact cleanup).
- Search for similar `powershell.file.script_block_text` patterns across other hosts to determine prevalence and potential lateral spread.
- If `file.name` or `file.path` are present, search for additional execution of the same script file across the environment.
- Correlate with adjacent telemetry to determine initiation and outcomes:
- Using `host.id`, `host.name`, `user.id`, and the alert time window, correlate with available endpoint and security telemetry to identify:
- How PowerShell was initiated (interactive use vs. application-driven execution) and whether there is an unusual execution chain.
- Evidence of screenshot artifacts being written, moved, archived, or deleted, especially in locations referenced in `powershell.file.script_block_text`.
- Any outbound communication or data movement that could indicate transfer of captured images or related content.
- Assess potential impact:
- Determine whether the host and user context suggests access to sensitive information that could have been exposed via screenshots.
- If screenshot artifacts are identified, preserve copies and metadata for exposure assessment and downstream response actions.
### False positive analysis
- Regular users do not have a business justification for using scripting utilities to take screenshots, which makes false positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.
### Related rules
- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889
- Legitimate scenarios may include authorized troubleshooting, remote support workflows, UI testing, or automation that captures screenshots.
- Validate benign explanations by confirming that the involved `user.name`/`user.id` and `host.name`/`host.id` align with expected operational ownership and that the script content in `powershell.file.script_block_text` matches known, approved implementations.
- File-backed scripts with stable, approved locations (`file.path`/`file.name`) and consistent content are more likely to be benign. Inline or frequently changing script content, especially with staging or transfer logic, should be treated as higher risk even if screenshot capture is a documented capability.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
- If the activity is confirmed malicious or remains suspicious after triage:
- Contain the affected host to limit further collection and potential data transfer.
- Preserve evidence:
- Export and retain all related script block fragments for the same `powershell.file.script_block_id` and reconstruct the full script using `powershell.sequence` and `powershell.total`.
- Collect any file-backed script referenced by `file.path`/`file.name`, along with any identified screenshot output paths from `powershell.file.script_block_text`.
- Scope and eradicate:
- Hunt for the same screenshot capture indicators across the environment using distinctive strings from `powershell.file.script_block_text`, as well as the involved `user.id` and `file.name` (if present).
- Review correlated telemetry for signs of staging or transfer and identify any additional affected hosts or accounts.
- Credential and access hygiene:
- If screenshots may have captured credentials or privileged activity, follow your incident response process for credential reset and access review for the involved account(s).
- Review access to sensitive systems from the affected host and user context during the relevant time window.
- If the activity is confirmed benign:
- Document the legitimate business process, script ownership, and expected execution scope (approved users, hosts, and typical timing).
- Ensure the script source is controlled (when `file.path`/`file.name` are present) and that execution is limited to authorized accounts and systems.
- Continue monitoring for deviations in script content or execution context using the same pivots (`host.id`, `user.id`, and distinctive content in `powershell.file.script_block_text`).
"""
references = ["https://docs.microsoft.com/en-us/dotnet/api/system.drawing.graphics.copyfromscreen"]
risk_score = 47
risk_score = 73
rule_id = "959a7353-1129-4aa7-9084-30746b256a70"
setup = """## Setup
The 'PowerShell Script Block Logging' logging policy must be enabled.
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Administrative Templates >
Windows PowerShell >
Turn on PowerShell Script Block Logging (Enable)
```
Steps to implement the logging policy via registry:
```
reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
```
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
"""
severity = "medium"
severity = "high"
tags = [
"Domain: Endpoint",
"OS: Windows",
@@ -124,3 +164,22 @@ id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
rules/windows/collection_posh_webcam_video_capture.toml
+75 -37
View File
@@ -2,13 +2,13 @@
creation_date = "2023/07/18"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/01/26"
[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that can be used to record webcam video. Attackers can capture this information to extort or
spy on victims.
Detects PowerShell script block content that references webcam capture APIs or video capture device objects.
Attackers use webcam recording to surveil victims or collect sensitive footage for extortion.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
@@ -22,33 +22,66 @@ note = """## Triage and analysis
### Investigating PowerShell Script with Webcam Video Capture Capabilities
PowerShell, a powerful scripting language in Windows, can interface with system components like webcams for legitimate tasks such as video conferencing. However, adversaries exploit this by crafting scripts to covertly record video, infringing on privacy. The detection rule identifies suspicious script patterns and API calls linked to webcam access, flagging potential misuse for further investigation.
This alert indicates PowerShell script block content on a Windows host that references webcam or video capture components. The matched content may represent device enumeration, frame handling, or capture routines used to record from an attached camera. Because webcam collection has privacy and regulatory impact, prioritize confirming intent, scope, and whether any recordings were produced or transferred.
### Possible investigation steps
#### Key alert fields to review
- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or API calls, such as "NewFrameEventHandler" or "VideoCaptureDevice".
- Check the process execution details, including the parent process, to determine how the PowerShell script was initiated and if it was part of a legitimate application or task.
- Investigate the user account under which the PowerShell script was executed to assess if the account has a history of suspicious activity or if it has been compromised.
- Examine the host's recent activity logs for any other unusual behavior or alerts that might correlate with the webcam access attempt, such as unauthorized access attempts or data exfiltration.
- Verify if the host has any legitimate applications that might use webcam access, and cross-reference with the script's behavior to rule out false positives.
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
#### Possible investigation steps
- Analyze the script content in `powershell.file.script_block_text` to understand its functionality:
- Identify references to webcam or video capture APIs, classes, or methods (for example, `VideoCaptureDevice`, `NewFrameEventHandler`, `DirectX.Capture.Filters`, `VideoCompressors`, or calls to `avicap32.dll` functions).
- Look for logic that initializes the camera, configures capture settings, handles frame events, and starts/stops recording.
- Note any output handling, such as saving recordings to disk or preparing data for transmission.
- Reconstruct the complete script when content is split across multiple events:
- Group by `powershell.file.script_block_id` and order by `powershell.sequence` through `powershell.total`.
- Preserve the reconstructed content as an investigation artifact and note `powershell.file.script_block_length` for context (very large blocks may contain additional functionality beyond capture).
- Identify likely collection intent and potential artifacts by inspecting the script content:
- Look for device enumeration and selection logic (for example, listing available devices, choosing a specific camera, or referencing device indices).
- Look for capture start/stop logic, timers, or loops that control duration and frequency.
- Look for references to output locations, file names, or post-processing steps (encoding, compression, or transformation of captured frames).
- Look for indications of onward handling of recordings (archiving, encryption, or transfer).
- Determine script origin and reuse:
- If `file.path` and `file.name` are present, treat the script as file-backed content and assess whether the location in `file.directory` is expected for the user and host.
- Pivot on `file.path` or `file.name` to identify additional script block events that reference the same file, and whether the same content appears on other hosts.
- Establish user and host context:
- Validate whether `user.name` and `user.domain` align with expected webcam usage on `host.name` (for example, support, QA, or multimedia testing roles) and whether the timing is consistent with normal activity.
- Pivot on `host.id` and `user.id` in a narrow time window around `@timestamp` to identify related PowerShell script blocks that suggest staging, repeated attempts, or follow-on activity.
- Correlate with adjacent telemetry in your environment to confirm execution and impact:
- Process telemetry: determine how PowerShell was launched (interactive use vs. launched by another program) and whether the activity was isolated or part of a broader execution chain.
- File telemetry: identify creation or modification of video artifacts and any additional scripts written or fetched around the alert time.
- Network telemetry: identify outbound connections that could support remote tasking or transfer of captured content.
- Authentication telemetry: verify whether the user context was local, remote, or recently authenticated in an unusual way during the alert window.
### False positive analysis
- Legitimate video conferencing applications may trigger the detection rule due to their use of similar API calls and script patterns. Users can create exceptions for known and trusted applications by whitelisting their process names or script signatures.
- Security testing tools that simulate webcam access for vulnerability assessments might be flagged. To handle this, users should exclude these tools from monitoring during scheduled testing periods.
- System diagnostics or maintenance scripts that access webcam components for hardware checks can be mistaken for malicious activity. Users should document and exclude these scripts if they are part of routine system operations.
- Educational or training software that uses webcam access for interactive sessions may be incorrectly identified. Users can mitigate this by adding these applications to an allowlist after verifying their legitimacy.
- Custom scripts developed in-house for specific business needs that involve webcam access should be reviewed and, if deemed safe, excluded from the detection rule to prevent unnecessary alerts.
- Benign camera diagnostics or hardware validation scripts may reference capture devices, frame handlers, and compressor lists without performing unauthorized recording.
- Development and testing environments may include sample or proof-of-concept code that imports or references capture libraries during troubleshooting or application development.
- Enterprise imaging, kiosk build, or A/V workstation provisioning workflows may temporarily stage scripts that validate camera availability and driver functionality.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious PowerShell processes identified by the detection rule to stop ongoing webcam recording activities.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software.
- Review and revoke any unauthorized access permissions or credentials that may have been compromised during the incident.
- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious script.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for PowerShell activities across the network to detect and respond to similar threats more effectively in the future."""
- If activity is unexpected or violates policy, treat as a potential privacy-impacting collection incident:
- Escalate according to your incident response and privacy handling procedures.
- Preserve the full script content (reconstructed if needed) and record key identifiers: `@timestamp`, `host.name`, `host.id`, `user.name`, `user.id`, and any `file.path`/`file.name` present.
- Contain potential ongoing collection:
- Isolate the affected host using standard endpoint response controls.
- Restrict the suspected user account and investigate for additional malicious activity associated with `user.id` and `host.id` during the same period.
- If appropriate for your environment, temporarily restrict access to the camera device on the affected host until legitimacy is confirmed.
- Eradicate and recover:
- Remove or quarantine unauthorized scripts referenced by `file.path`/`file.name` and any related artifacts identified during triage.
- If recordings were created, locate and secure them as evidence, and assess whether any transfer occurred.
- Reset credentials for impacted accounts if compromise is suspected and review for additional access paths.
- Post-incident actions:
- Increase monitoring for similar PowerShell script block content on the scoped hosts and accounts to detect recurrence.
- Review endpoint hardening and least-privilege controls for camera access and script execution where feasible.
"""
references = [
"https://github.com/EmpireProject/Empire/blob/master/lib/modules/powershell/collection/WebcamRecorder.py",
]
@@ -56,21 +89,8 @@ risk_score = 47
rule_id = "eb44611f-62a8-4036-a5ef-587098be6c43"
setup = """## Setup
The 'PowerShell Script Block Logging' logging policy must be enabled.
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Administrative Templates >
Windows PowerShell >
Turn on PowerShell Script Block Logging (Enable)
```
Steps to implement the logging policy via registry:
```
reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
```
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
"""
severity = "medium"
tags = [
@@ -132,3 +152,21 @@ id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
rules/windows/credential_access_mimikatz_powershell_module.toml
+91 -51
View File
@@ -2,14 +2,14 @@
creation_date = "2020/12/07"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/01/26"
[rule]
author = ["Elastic"]
description = """
Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many
other features that make it useful for testing the security of networks. This rule detects Invoke-Mimikatz PowerShell
script and alike.
other features that make it useful for testing the security of networks. This rule detects PowerShell script content
associated with Invoke-Mimikatz or Mimikatz.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
@@ -18,77 +18,98 @@ license = "Elastic License v2"
name = "Potential Invoke-Mimikatz PowerShell Script"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential Invoke-Mimikatz PowerShell Script
[Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to move laterally and pivot across a network.
This alert identifies PowerShell script block content on a Windows host that contains strings commonly associated with Mimikatz or Invoke-Mimikatz activity. The matched content is consistent with attempts to access credentials from memory and/or enumerate and export certificates, which can enable rapid privilege escalation and lateral movement.
This rule looks for PowerShell scripts that load mimikatz in memory, like Invoke-Mimikataz, which are used to dump credentials from the Local Security Authority Subsystem Service (LSASS). Any activity triggered from this rule should be treated with high priority as it typically represents an active adversary.
#### Key alert fields to review
More information about Mimikatz components and how to detect/prevent them can be found on [ADSecurity](https://adsecurity.org/?page_id=1821).
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
#### Possible investigation steps
- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Examine file or network events from the involved PowerShell process for suspicious behavior.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Invoke-Mimitakz and alike scripts heavily use other capabilities covered by other detections described in the "Related Rules" section.
- Evaluate whether the user needs to use PowerShell to complete tasks.
- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host.
- Examine network and security events in the environment to identify potential lateral movement using compromised credentials.
- Establish basic context and prioritize:
- Use `@timestamp` to define the initial investigation window and identify surrounding activity on the same `host.name` and for the same `user.name`.
- Review `host.name` and `host.id` to determine whether the host is a high-value asset (e.g., administrative workstation, authentication infrastructure, file server) and whether it is expected to run high-risk administrative scripts.
- Review `user.name`, `user.domain`, and `user.id` to determine whether the account is privileged, shared, or service-related, and whether its use on this host is expected.
- Analyze what the script block indicates:
- Review `powershell.file.script_block_text` and categorize the intent based on the matched strings:
- Credential dumping indicators (e.g., `sekurlsa::logonpasswords`, `DumpCreds`) suggest an attempt to extract authentication material from memory.
- Certificate access indicators (e.g., `crypto::certificates`, `CERT_SYSTEM_STORE_LOCAL_MACHINE`, `DumpCerts`) suggest enumeration and potential export of certificates/keys.
- Determine whether the content appears to be:
- Tool staging (function or module definitions, large scripts) versus
- Direct execution (explicit commands, parameters, or output handling).
Use `powershell.file.script_block_length` as a quick signal for full-module loading versus a short invocation.
- Extract and record any embedded scope details from `powershell.file.script_block_text` (usernames, domains, hostnames, file paths, share paths, or remote endpoints) to guide scoping.
- Reconstruct full script content when split across multiple events:
- Pivot by `powershell.file.script_block_id` and order by `powershell.sequence` to rebuild the full script block.
- Validate completeness using `powershell.total` (when present) and identify missing fragments that may require expanding the time window or searching for additional related script blocks.
- After reconstruction, re-review the consolidated content for follow-on actions such as output to disk, remote targeting, or additional credential/certificate collection logic.
- Determine the likely script source and propagation risk:
- If `file.path`, `file.directory`, or `file.name` are present, treat the activity as file-backed PowerShell content:
- Identify whether the path and name align with known administrative scripts in your environment.
- Look for other script blocks referencing the same `file.path` or `file.name` on the same `host.name` to understand reuse and execution frequency.
- If file context is absent, treat the activity as inline/interactive or dynamically generated content and prioritize identifying the initiating execution chain using adjacent telemetry.
- Scope for additional related activity:
- Search for other occurrences of the same `powershell.file.script_block_text` keywords across the environment, focusing on the same `user.name`/`user.id` and `host.name`/`host.id` first, then widening to other hosts and users.
- Identify whether multiple distinct `powershell.file.script_block_id` values appear for the same user/host within a short period, which can indicate iterative testing, staging, or repeated execution.
- Correlate with adjacent telemetry in the same time window (if available in your environment):
- Process activity: identify the PowerShell host process and its parent process on `host.name` around `@timestamp` to determine whether execution was interactive, scheduled, or remotely initiated.
- File activity: look for evidence of exported data (credential output, dumps, certificate files) and for newly created or modified scripts consistent with the `file.path` context or references found in `powershell.file.script_block_text`.
- Network activity: review outbound and internal connections from `host.name` around `@timestamp`, especially if the script text references remote systems or suggests staging/exfiltration behavior.
- Authentication activity: review successful and failed authentications involving `user.name` and other accounts referenced in the script text after the alert time to identify potential credential reuse or lateral movement.
### False positive analysis
- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
### Related rules
- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe
- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad
- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a
- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d
- Mimikatz Memssp Log File Detected - ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6
- Modification of WDigest Security Provider - d703a5af-d5b0-43bd-8ddb-7a5d500b7da5
- Authorized security testing and adversary simulation can legitimately execute Mimikatz-related tooling. Validate with the owning team, documented approval, and expected targets and timing.
- Training, lab, or malware analysis environments may execute or store Mimikatz-related scripts for educational purposes. Confirm the host purpose and ensure activity is confined to approved non-production systems.
- Some defensive, auditing, or instructional PowerShell content may include these strings as examples or test cases. Confirm the surrounding script context in `powershell.file.script_block_text` and whether the content represents active execution versus reference text. Unexpected use on production endpoints or by standard users should be treated as suspicious.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
- Validate that cleartext passwords are disabled in memory for use with `WDigest`.
- Look into preventing access to `LSASS` using capabilities such as LSA protection or antivirus/EDR tools that provide this capability.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
- If activity is confirmed or strongly suspected malicious:
- Contain the affected host (`host.name`) according to your incident response process to limit further credential access and lateral movement.
- Preserve evidence:
- Save the full reconstructed script content (all fragments associated with `powershell.file.script_block_id`) and retain relevant logs around `@timestamp`.
- If `file.path` is present, preserve the referenced script file and any related artifacts identified during triage.
- Assume credential exposure may have occurred when credential dumping indicators are present:
- Initiate credential resets for the involved `user.name` and any other accounts referenced in `powershell.file.script_block_text`, prioritizing privileged and service accounts.
- Review for follow-on authentications and lateral movement originating from `host.name`.
- If certificate access indicators are present:
- Identify potentially impacted certificates and keys, restrict use as appropriate, and coordinate revocation and re-issuance based on your PKI and incident response procedures.
- Expand hunting:
- Search for the same keywords and related script blocks across other hosts and users to determine spread and identify additional affected systems.
- If activity is determined to be authorized:
- Document the business justification, responsible parties, and approved scope (hosts and users).
- Apply preventive controls to reduce risk of misuse, such as limiting where high-risk tools can run, restricting PowerShell usage to approved accounts and hosts, and enhancing monitoring for future occurrences.
"""
references = [
"https://attack.mitre.org/software/S0002/",
"https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1",
"https://www.elastic.co/security-labs/detect-credential-access",
]
risk_score = 73
risk_score = 99
rule_id = "ac96ceb8-4399-4191-af1d-4feeac1f1f46"
setup = """## Setup
The 'PowerShell Script Block Logging' logging policy must be configured (Enable).
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Administrative Templates >
Windows PowerShell >
Turn on PowerShell Script Block Logging (Enable)
```
Steps to implement the logging policy via registry:
```
reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
```
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
"""
severity = "high"
severity = "critical"
tags = [
"Domain: Endpoint",
"OS: Windows",
@@ -130,3 +151,22 @@ id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
rules/windows/credential_access_posh_invoke_ninjacopy.toml
+97 -20
View File
@@ -2,13 +2,14 @@
creation_date = "2023/01/23"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/01/26"
[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that contain the default exported functions used on Invoke-NinjaCopy. Attackers can use
Invoke-NinjaCopy to read SYSTEM files that are normally locked, such as the NTDS.dit file or registry hives.
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.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
@@ -17,35 +18,92 @@ license = "Elastic License v2"
name = "PowerShell Invoke-NinjaCopy script"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating PowerShell Invoke-NinjaCopy script
PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making it available for use in various environments, creating an attractive way for attackers to execute code.
This rule identifies PowerShell script block content referencing `Invoke-NinjaCopy` or related `Stealth*` helper functions. These functions are commonly used to perform direct volume file reads that can bypass normal file locking and access controls, enabling copies of sensitive credential stores (for example, `NTDS.dit` or registry hives like `SAM`, `SYSTEM`, and `SECURITY`). The presence of these strings can represent tool staging (definition/import) or active execution, so focus on determining intent, targeted artifacts, output locations, and surrounding activity.
Invoke-NinjaCopy is a PowerShell script capable of reading SYSTEM files that were normally locked, such as `NTDS.dit` or sensitive registry locations. It does so by using the direct volume access technique, which enables attackers to bypass access control mechanisms and file system monitoring by reading the raw data directly from the disk and extracting the file by parsing the file system structures.
#### Key alert fields to review
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
#### Possible investigation steps
- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Examine file or network events from the involved PowerShell process for suspicious behavior.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Evaluate whether the user needs to use PowerShell to complete tasks.
- Determine whether the script stores the captured data locally.
- Check if the imported function was executed and which file it targeted.
- Triage the alert context:
- Identify the affected `host.name` / `host.id` and the account (`user.name`, `user.domain`, `user.id`).
- Determine whether the host is expected to store credential material (for example, a directory services server) and whether the user is expected to perform privileged maintenance on it.
- Use the alert time (`@timestamp`) to define an initial correlation window and expand as needed.
- Analyze `powershell.file.script_block_text` to understand what was staged or executed:
- Determine whether the content is primarily function definitions/module code (tool load) or includes direct invocation of `Invoke-NinjaCopy` and `Stealth*` functions.
- Extract any referenced source artifacts (for example, `NTDS.dit` or registry hives) and any destination/output file names, directories, or remote paths.
- Look for indicators of direct volume access, such as device/volume path handling, low-level file handle usage, delegates, or logic intended to bypass normal file locking.
- Identify follow-on logic that would support collection and handling (copy loops, chunking, archiving, encoding, renaming, or cleanup).
- Use script block metadata to reconstruct full content when logged in multiple parts:
- Pivot on `powershell.file.script_block_id` for the same `host.id`.
- Order fragments by `powershell.sequence` and confirm the final part count matches `powershell.total`.
- If parts are missing, treat the content as incomplete and continue scoping for additional fragments.
- Preserve the reconstructed content and the original fragment events for case evidence.
- Determine script provenance when file context is present:
- Review `file.path` / `file.name` (and `file.directory` if populated) to identify where the script was executed from.
- Treat execution from user-writable or temporary locations as higher risk, and scope for other executions originating from the same path or directory on the host.
- If file context is not present, consider interactive execution or remote delivery and expand scoping to other script blocks from the same `host.id` and `user.id` around the alert time.
- Scope for related PowerShell activity on the endpoint:
- Review additional Script Block Logging events for the same `host.id` and `user.id` around the alert time to identify staging, retries, and post-collection actions.
- Use `powershell.file.script_block_length` to prioritize larger blocks that may contain full tooling, embedded functions, or post-processing logic.
- Prioritize script blocks that reference the same artifact names or output locations observed in the matched content.
- Assess prevalence across the environment:
- Search for the same keywords within `powershell.file.script_block_text` (for example, `Invoke-NinjaCopy` and `StealthOpenFile`) across other hosts to identify broader deployment.
- If `file.path` or `file.name` is present, use it to identify reuse of the same script file across multiple hosts or users.
- Correlate with adjacent telemetry (if available) using `host.name`, `host.id`, `user.id`, and the alert time:
- Process activity to identify the PowerShell host process and the parent/source that initiated it, and whether execution aligns with expected administrative workflows.
- File activity to confirm whether copies of targeted artifacts were created, where they were written, and whether they were later archived or moved.
- Network activity to identify outbound transfers or remote access shortly after script execution.
- Authentication activity to identify suspicious logons, privilege use, or lateral movement following potential credential material collection.
- Determine impact:
- If the script indicates attempted access to directory services database files or registry hives, treat this as potential credential exposure until corroborating telemetry shows otherwise and respond accordingly.
### False positive analysis
- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.
- Approved security testing, adversary emulation, or controlled red team activity that includes NinjaCopy-derived code.
- Authorized incident response, forensic acquisition, or recovery workflows that require copying locked system files.
- Administrative tooling that embeds similar helper functions for troubleshooting or backup operations (uncommon); validate ownership, expected hosts, and change control.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
- If the activity is not expected or cannot be attributed to an approved task:
- Isolate the affected host to prevent additional collection, staging, or lateral movement.
- Take immediate steps to prevent further use of the implicated account (`user.id`) until legitimacy is confirmed.
- Preserve and collect evidence:
- Save the full `powershell.file.script_block_text` and reconstruct missing fragments using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total` where applicable.
- Record `@timestamp`, `host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, and any available `file.path` / `file.name` context.
- Identify any destination/output locations referenced in the script content and preserve related artifacts (copied files, archives, temporary staging).
- Assess credential exposure and potential follow-on activity:
- Use available endpoint telemetry to determine whether credential stores were successfully copied or staged.
- If credential stores may have been accessed or copied, follow your credential containment process and prioritize rotation of impacted and privileged credentials.
- Eradicate and scope:
- Remove unauthorized scripts and supporting artifacts identified from `file.path` / `file.name` and from any output locations referenced in the script.
- Hunt for additional NinjaCopy-related script blocks across endpoints and for subsequent suspicious authentication activity associated with the same user and host context.
- Recover and harden:
- Restore affected systems as needed and validate that no persistence remains.
- Reduce recurrence by tightening administrative scripting governance for PowerShell (least privilege, controlled script deployment locations, and application control where feasible) and by restricting access to systems that store credential material.
"""
references = [
"https://github.com/BC-SECURITY/Empire/blob/main/empire/server/data/module_source/collection/Invoke-NinjaCopy.ps1",
@@ -134,3 +192,22 @@ id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
rules/windows/credential_access_posh_kerb_ticket_dump.toml
+82 -48
View File
@@ -2,13 +2,13 @@
creation_date = "2023/07/26"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/01/26"
[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that have the capability of dumping Kerberos tickets from LSA, which potentially indicates an
attacker's attempt to acquire credentials for lateral movement.
Detects PowerShell script block content that references LSA Kerberos ticket retrieval APIs and Kerb* message types.
Attackers dump Kerberos tickets from memory to reuse credentials and move laterally.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
@@ -17,69 +17,84 @@ license = "Elastic License v2"
name = "PowerShell Kerberos Ticket Dump"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating PowerShell Kerberos Ticket Dump
Kerberos is an authentication protocol that relies on tickets to grant access to network resources. Adversaries may abuse this protocol to acquire credentials for lateral movement within a network.
This alert identifies PowerShell script block content referencing the LSA Kerberos authentication package API `LsaCallAuthenticationPackage` along with Kerberos ticket cache query and ticket retrieval message types. This pattern is consistent with tooling that enumerates, extracts, or manipulates Kerberos tickets from memory, which can enable credential reuse and lateral movement.
This rule indicates the use of scripts that contain code capable of dumping Kerberos tickets, which can indicate potential PowerShell abuse for credential theft.
#### Key alert fields to review
### Possible investigation steps
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate if the script was executed, and if so, which account was targeted.
- Identify the account involved and contact the owner to confirm whether they are aware of this activity.
- Check if the script has any other functionality that can be potentially malicious.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate other potentially compromised accounts and hosts. Review login events (like 4624) for suspicious events involving the subject and target accounts.
#### Possible investigation steps
- Reconstruct and preserve the full script content:
- Use `powershell.file.script_block_id` to gather all related fragments and order them by `powershell.sequence` up to `powershell.total`.
- Preserve the reconstructed content from `powershell.file.script_block_text` for case notes and to support environment-wide scoping.
- Use `powershell.file.script_block_length` to understand whether the content is a full implementation, a loader/stager, or a small inline snippet that may be part of a larger sequence of script blocks.
- Identify the specific Kerberos capability referenced:
- Review `powershell.file.script_block_text` and note which message types are present. Use this to prioritize severity and intent:
- Cache enumeration indicators: `KerbQueryTicketCacheMessage`, `KerbQueryTicketCacheExMessage`, `KerbQueryTicketCacheEx2Message`
- Ticket retrieval/export indicators: `KerbRetrieveTicketMessage`, `KerbRetrieveEncodedTicketMessage`
- Ticket-related decryption indicators: `KerbDecryptDataMessage`
- Determine whether the script only defines interop types/functions or includes invocation logic that executes ticket operations and processes results.
- Look for signs that output is being prepared for reuse or transfer (e.g., structured serialization, encoding, or explicit output handling). If `file.path` is populated, assess whether the script is associated with a specific on-disk source.
- Validate execution context and plausibility:
- Review `@timestamp`, `host.name`/`host.id`, and `user.name`/`user.domain`/`user.id` to confirm where and under which identity the activity occurred.
- Assess whether the user and host context align with expected administrative or troubleshooting activity in your environment. Unexpected use by standard users, or on endpoints where administrative scripting is uncommon, should be treated as higher risk.
- If `file.path`/`file.name` (and `file.directory`, if present) indicate an on-disk origin, evaluate whether the location is consistent with approved scripts. Treat user-writable and temporary locations as higher risk, especially when combined with ticket retrieval/decryption indicators.
- Scope for additional PowerShell activity on the same host and user:
- Pivot on `host.id` and `user.id` to review other script block activity near `@timestamp` to identify precursors (staging, discovery) and follow-on actions (additional credential access attempts, lateral movement preparation).
- Check for repeated execution patterns: multiple script blocks with similar content, repeated `powershell.file.script_block_id` occurrences, or the same `file.name` appearing multiple times in a short window.
- Assess prevalence across the environment:
- Search for the same or highly similar `powershell.file.script_block_text` content (or distinctive substrings) across hosts to determine whether this is isolated or widespread.
- If `file.name` is present, look for the same script name used across multiple hosts. Consistent, predictable use may indicate managed tooling; sporadic or single-host use may indicate targeted activity.
- Correlate with adjacent telemetry (when available):
- Process telemetry: identify the PowerShell execution instance that produced the script block and determine the initiating process to establish whether execution was interactive, scheduled, or launched by another application.
- File telemetry: review for newly created or modified artifacts near `@timestamp` that could store extracted ticket material or related output.
- Network and authentication telemetry: review subsequent outbound activity and authentication attempts associated with the same host and/or user to identify potential ticket reuse and rapid lateral movement following the script execution.
### False positive analysis
- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of file path and user ID conditions.
- Some legitimate Kerberos troubleshooting and diagnostics workflows can reference LSA Kerberos APIs to query ticket cache state. Validate whether the script source (`file.path`/`file.name`), execution context (`user.id`, `host.id`), and timing align with an approved operational process.
- Administrative automation or security tooling may include Kerberos interop code for visibility or health checks. Benign usage is typically repeatable (consistent script content, consistent script origin, predictable execution patterns) and tied to known administrative accounts.
- Prioritize deeper investigation when the activity is one-off, appears only on a single host, is executed by unexpected users, or includes retrieval/decryption indicators rather than simple cache query logic.
### Related Rules
### Response and remediation
- PowerShell Kerberos Ticket Request - eb610e70-f9e6-4949-82b9-f1c5bcd37c39
- If the activity is unexpected or cannot be validated as authorized:
- Isolate the affected host to reduce the risk of credential theft and lateral movement.
- Preserve evidence for scoping: retain the reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, host identifiers, user identifiers, and any on-disk script context (`file.path`, `file.name`).
- Treat as a potential credential access incident and initiate environment-wide scoping for similar script content and related activity from the same user and host.
### Response and Remediation
- If Kerberos ticket theft or export is confirmed:
- Remove the script source (as identified by `file.path`/`file.name`) and any related artifacts identified during triage.
- Reset or rotate credentials for impacted accounts and review privileged access paths associated with the affected host and user.
- Investigate for lateral movement following `@timestamp`, identify affected systems, and remediate access pathways used.
- Initiate the incident response process based on the outcome of the triage.
- If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Disable or limit involved accounts during the investigation and response.
- If the triage identified malware, search the environment for additional compromised hosts.
- Implement temporary network rules, procedures, and segmentation to contain the malware.
- Stop suspicious processes.
- Immediately block the identified indicators of compromise (IoCs).
- Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Reimage the host operating system or restore the compromised files to clean versions.
- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
- Post-incident hardening:
- Ensure PowerShell script block logging coverage and retention support reconstruction and historical scoping.
- Review administrative scripting controls and monitoring for unauthorized use of authentication-package APIs in PowerShell, and align execution permissions with least-privilege practices.
"""
references = ["https://github.com/MzHmO/PowershellKerberos/blob/main/dumper.ps1"]
risk_score = 73
rule_id = "fddff193-48a3-484d-8d35-90bb3d323a56"
setup = """## Setup
The 'PowerShell Script Block Logging' logging policy must be enabled.
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Administrative Templates >
Windows PowerShell >
Turn on PowerShell Script Block Logging (Enable)
```
Steps to implement the logging policy via registry:
```
reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
```
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
"""
severity = "high"
tags = [
@@ -144,3 +159,22 @@ id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]