« Exchange Mailbox Export via PowerShell PowerShell Keylogging Script »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.20

PowerShell Suspicious Script with Audio Capture Capabilities

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

PowerShell Suspicious Script with Audio Capture Capabilities

edit

Detects PowerShell script block content that invokes microphone capture routines or WinMM audio APIs. Adversaries may use audio recording to surveil users or capture sensitive conversations for theft or extortion.

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: Collection
  • Resources: Investigation Guide
  • Data Source: PowerShell Logs

Version: 217

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating PowerShell Suspicious Script with Audio Capture Capabilities

Possible investigation steps

  • Does the preserved script content show live microphone capture logic rather than inert reference text?
  • Focus: the preserved script text on the alert and any associated file.path.
  • Implication: supports concern when the content invokes recording routines, output paths, duration controls, or upload logic; carries less weight when the text is clearly inert example material, documentation, or recognized test content with no adjacent execution evidence.
  • Does reconstructing the full script reveal staging, timers, cleanup, or transfer behavior that changes urgency?
  • Why: script block logging can split one script across multiple records; later fragments often reveal save locations, loop logic, or exfiltration.
  • Focus: powershell.file.script_block_id, powershell.sequence, powershell.total, and powershell.file.script_block_length to rebuild adjacent fragments, then the reconstructed content for output paths, encoding steps, remote destinations, or cleanup logic. !{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"}}
  • Implication: supports active collection when reconstruction shows repeated capture loops, hidden staging paths, compression, upload, persistence, or cleanup after collection.
  • Does the user-host pairing fit recognized accessibility testing, media tooling, or security assessment?
  • Focus: the user.id and host.id pairing, whether the host role or asset classification supports microphone access, and any prior alert recurrence from this rule for the same pairing and launcher.
  • Implication: escalate when the user has no recurring pattern of audio access, the host handles privileged or sensitive workflows, or the timing falls outside scheduled testing.
  • Can you recover the PowerShell process and explain how it was launched?
  • Focus: the matching process start event via process.pid and host.id, recovering process.command_line, process.parent.executable, process.parent.command_line, and process.Ext.session_info.logon_type. !{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: if the process event cannot be found, keep later file and network review bounded to the same host and alert time rather than assuming a wider process scope.
  • Implication: supports concern when the recovered process is launched by a document, browser, chat client, scheduled task, remote session, or user-writable script path.
  • Do file events from the same process show recorded audio or staging artifacts?
  • Focus: file events for the same process.entity_id, with attention to file.path, file.extension, file.Ext.header_bytes, and file.Ext.original.path when media files or archives are renamed for staging.
  • Implication: supports active collection when media files, deceptive extensions, archives, or renamed payloads appear in user-writable or hidden paths, or when written artifacts are later executed or uploaded.
  • Do network events show outbound transfer or second-stage behavior from the same process?
  • Focus: network events for the same process.entity_id, separating dns.question.name / dns.resolved_ip from destination.ip / destination.port.
  • Implication: suggests follow-on transfer when the same process or host reaches rare public destinations, cloud storage, or messaging services. Missing network telemetry is unresolved, not benign.
  • If the local evidence stays suspicious, do related alerts or repeated script-block activity suggest broader compromise?
  • Focus: related alerts for the same user.id to find repeated collection, execution, or defense-evasion activity. !{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 related alerts for the same host.id and repeated preserved script substrings on this asset to look for persistence, repeated collection, follow-on staging, or renamed audio-capture variants. !{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: suggests broader compromise when either view shows collection, execution, defense-evasion, persistence, or transfer activity; stays localized when alerts are confined to the known script and host with no repeated collection or follow-on staging.
  • Escalate when script intent, launch context, artifacts, or network activity align on active collection; close only when all evidence supports a recognized benign workflow; if mixed or incomplete, preserve and escalate.

False positive analysis

  • Accessibility, QA, or red-team activity can legitimately trigger this rule. Confirm that the script content, writer identity, and host all belong to an authorized workflow.
  • Before creating an exception, validate that the same user.id, host.id, file.path, and a stable powershell.file.script_block_text substring recur across prior alerts. Avoid exceptions on audio API strings alone, user.name alone, or the host alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the script content, recovered launch chain, user-host scope, and any benign file or destination pattern that proved the confirmed workflow. Create an exception only if the same workflow recurs consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve the reconstructed script content, recovered process.entity_id, related file.path artifacts, and any dns.question.name or destination.ip values linked to transfer. Apply reversible containment such as temporary destination blocking or session restrictions. Escalate to host isolation only when active collection or transfer evidence is strong and the host role can tolerate it. Avoid destructive cleanup until scope is clearer.
  • If confirmed malicious, document the recovered process.entity_id, process.command_line, process.parent.executable, written file.path artifacts, and any confirmed dns.question.name or destination.ip values before initiating response actions. Use available endpoint response integrations to isolate the host (preferred over process termination for initial containment when the asset can tolerate it), then block confirmed malicious destinations and scripts. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. If the captured audio may have exposed sensitive conversations or privileged sessions, initiate access review for the affected accounts.
  • If recorded audio files or staging archives are identified, preserve them according to privacy and evidence-handling requirements. Review related users and hosts for the same powershell.file.script_block_text content, file.path pattern, or dns.question.name destinations before eradicating. Then remove the artifacts and any persistence or automation identified during reconstruction or host-scoping.
  • After containment, restrict the execution path that allowed the script to run, such as tightening PowerShell execution policies or script-path allowlists. Retain PowerShell script block logging and related endpoint telemetry.

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 : (
    "Get-MicrophoneAudio" or
    ("Get-AudioDevice" and "Recording" and "Set-AudioDevice") or
    "WindowsAudioDevice-Powershell-Cmdlet" or
    (
      "winmm.dll" and
      (
        "waveInGetNumDevs" or "waveInOpen" or "waveInStart" or
        "mciSendString" or "mciSendStringA" or "mciSendStringW"
      )
    )
  ) and
  not powershell.file.script_block_text : (
    "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators"
  )

Framework: MITRE ATT&CKTM

« Exchange Mailbox Export via PowerShell PowerShell Keylogging Script »