[TTD] GigaWiper Destructive Backdoor and Fake-Ransomware Wiper Behavior

Report Type: Threat-to-Detection (TTD)
Threat Category: Destructive Backdoor and Fake-Ransomware Wiper
Assessment Date: July 12, 2026
Primary Impact Domain: Destructive System and Data Impact
Secondary Impact Domains: Operational Continuity, Recovery Readiness, Forensic Visibility, Endpoint and Server Trust
Affected Asset Class: Windows Endpoints, Windows Servers, Shared Storage, Backup and Recovery Systems, Administrative Systems, and Critical Business Services
Threat Objective Classification: Post-Compromise Remote Control, Evidence Reduction, Recovery Sabotage, and Irreversible Destructive Impact

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 12, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍  [TTD] GigaWiper Destructive Backdoor and Fake-Ransomware Wiper Behavior

S2 BLUF

GigaWiper exposes Windows environments to a post-compromise destructive-malware path where a modular backdoor can maintain remote operator access, monitor user activity, transfer files, wipe physical disks, destroy partition structures, irreversibly encrypt and delete files, disable recovery, sabotage boot functionality, and reduce local forensic evidence. The executive concern is not only whether a GigaWiper artifact has been identified, but whether affected Windows systems, shared data, backup and recovery infrastructure, administrative activity, security telemetry, and downstream business services can still be trusted after the exposure window.

Executive Risk Translation

This threat converts an existing Windows foothold into a remote-control and destructive-impact problem. If attackers operate GigaWiper successfully, they may observe the endpoint, execute commands, administer processes and services, alter firewall or Registry settings, transfer files, and select one or more destructive actions after maintaining access.

For organizations that depend on Windows systems for production services, identity administration, shared storage, backup and recovery, security operations, operational technology, engineering, regulated processing, or customer-facing applications, the risk is not limited to malware removal. It includes irreversible data loss, physical-disk and partition damage, recovery failure, boot failure, evidence destruction, large-scale system rebuilding, business interruption, customer impact, and reduced confidence in whether affected systems and restored environments remain trustworthy.

S5 Executive Risk Summary

Business Risk

GigaWiper can undermine endpoint and server availability, data integrity, backup and recovery confidence, operational continuity, forensic visibility, and trust in administrative activity. Business impact increases where affected Windows systems support production operations, customer services, identity administration, privileged access, shared storage, backup infrastructure, recovery systems, security tooling, engineering workflows, operational technology, regulated services, or other functions that cannot be isolated or rebuilt without material disruption.

Technical Cause

The primary issue addressed by this TTD is a modular Go-based Windows backdoor that combines command-and-control, surveillance, remote administration, file transfer, persistence, evidence reduction, and destructive-impact capabilities.

The documented behavior includes scheduled-task persistence, RabbitMQ command tasking, Redis command-status and output handling, shell execution, screen capture and recording, VNC-like remote interaction, keyboard and mouse control, process and service administration, Registry and firewall modification, system and security discovery, MinIO-based file transfer, raw physical-drive access, partition destruction, repeated disk overwriting, irreversible file encryption, source-file deletion, recovery disablement, boot sabotage, event-log clearing, direct event-log file deletion, and forced restart or system failure.

The fake-ransomware behavior should not be treated as ordinary recoverable encryption. The malware can transform and rename files while deleting the original data without preserving a reliable victim-recovery mechanism.

Threat Posture

This threat is strategically significant because it affects the trust boundary between endpoint execution, remote operator control, administrative activity, local and shared data, recovery infrastructure, backup systems, forensic evidence, and business-service availability.

GigaWiper should be treated as a detection-worthy post-compromise destructive platform even where destructive execution has not been confirmed. Its pre-impact capabilities allow an operator to maintain access, perform discovery, monitor the user, administer the endpoint, move files, and select destructive actions later.

Current reporting does not establish a universal initial-access mechanism, confirmed credential theft, a separate privilege-escalation capability, lateral movement, automatic enterprise propagation, Active Directory compromise, cloud-control-plane abuse, virtualization-layer compromise, or successful data exfiltration in every deployment. Those behaviors should be added only when incident-specific evidence supports them.

Executive Decision Requirement

Leadership should require immediate validation of Windows endpoint exposure, scheduled-task activity, RabbitMQ and Redis communication, unapproved inbound listeners, remote-control behavior, object-storage transfer activity, raw physical-drive access, partition and recovery changes, boot-configuration modification, destructive file activity, event-log clearing, and endpoint-health loss.

Organizations should also require application-control review, remote telemetry retention, protected backup validation, raw-disk and recovery-administration restrictions, endpoint-isolation authority, destructive-malware incident-response procedures, and tested bare-metal recovery where affected-system trust cannot be proven.

S6 Executive Cost Summary

GigaWiper creates financial exposure because the organization must determine whether affected Windows systems were only exposed to the implant, whether persistent remote access was established, whether an operator used surveillance or administrative functions, whether files were transferred, whether local evidence was destroyed, and whether destructive disk, partition, file, recovery, or boot activity occurred.

Response cost is driven by endpoint isolation, malware analysis, process and command reconstruction, network and remote-session review, file-transfer investigation, raw-disk and partition analysis, backup and recovery validation, system rebuilding, credential review, production restoration, customer-impact assessment, legal and regulatory review, cyber-insurance engagement, and restoration of confidence in affected systems and downstream services.

Low Impact Scenario

Estimated $75K - $500K.

This scenario applies where GigaWiper-related activity is identified quickly, affected systems are limited to a small number of noncritical endpoints or isolated servers, scheduled-task persistence and network activity can be reconstructed, no destructive disk or file activity is confirmed, recovery controls remain functional, backups remain intact, central telemetry is preserved, and affected systems can be rebuilt without material customer or production interruption.

Moderate Impact Scenario

Estimated $500K - $5M.

This scenario applies where confirmed or strongly suspected GigaWiper activity affects multiple endpoints, shared storage, production servers, administrative systems, identity-adjacent systems, backup infrastructure, recovery systems, or an important business service. Response may require multi-system isolation, forensic reconstruction, file and disk recovery, backup validation, credential rotation, system rebuilding, legal and compliance review, customer or partner assessment, external incident-response support, and extended post-restoration monitoring.

High Impact Scenario

Estimated $10M - $75M+.

This scenario applies where physical-disk wiping, partition destruction, broad irreversible file encryption, source-file deletion, backup or recovery impairment, boot sabotage, event-log destruction, production interruption, customer-service loss, operational-technology impact, or multi-system compromise is confirmed or cannot be ruled out. Response may require enterprise-scale investigation, emergency containment, broad system replacement, bare-metal rebuilding, large-scale data restoration, backup-platform validation, production recovery, customer remediation, contractual response, regulatory review, litigation support, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of operational trust.

S6A Key Cost Drivers

·        Number and importance of affected Windows endpoints, servers, file shares, administrative systems, identity-adjacent systems, backup systems, recovery systems, operational-technology support systems, and customer-facing services

·        Whether affected systems support production operations, shared storage, privileged administration, security operations, regulated processing, engineering, customer services, or other critical business dependencies

·        Evidence of scheduled-task persistence, RabbitMQ command tasking, Redis command-status or output handling, unapproved inbound listeners, interactive remote control, screen capture, file transfer, firewall modification, raw physical-drive access, partition destruction, recovery disablement, boot sabotage, event-log clearing, or destructive file activity

·        Whether physical-drive contents were overwritten, partition metadata was destroyed, source files were deleted, recovery controls were disabled, boot files were modified or removed, or affected systems became unbootable

·        Availability and retention of endpoint telemetry, Windows event logs, EDR data, network metadata, file events, raw-disk telemetry, backup logs, recovery logs, asset inventory, change-control records, and incident-response evidence

·        Completeness of approved RabbitMQ, Redis, remote-support, object-storage, scheduled-task, administrative-tooling, backup, recovery, imaging, and storage-management inventories

·        Availability and integrity of offline, immutable, or independently administered backups

·        Scope of endpoint rebuilding, bare-metal restoration, credential rotation, firewall review, scheduled-task review, service review, Registry review, backup validation, and downstream-system testing

·        Business disruption caused by isolating systems, suspending production services, restoring shared data, replacing endpoints or servers, validating backups, and rebuilding operational confidence

·        Customer, contractual, regulatory, legal, safety, privacy, or insurance exposure where data destruction, file transfer, service interruption, evidence loss, or incomplete containment cannot be ruled out

S6B Compliance and Risk Context

GigaWiper activity may create compliance, contractual, privacy, operational-resilience, customer-service, records-retention, cyber-insurance, or data-protection exposure when regulated data, production services, shared storage, administrative systems, backup infrastructure, recovery systems, security controls, operational technology, or customer-facing applications may have been affected.

Malware presence alone is not sufficient for breach determination. The governance question is whether the organization can prove that affected systems, administrative activity, data, backups, recovery controls, security telemetry, and downstream services remained legitimate, available, and trustworthy during the exposure window.

Risk Register Entry

Risk Title

GigaWiper Destructive Backdoor and Irrecoverable Windows System Impact

Risk Description

Attackers may deploy GigaWiper after gaining execution on a Windows system and use the implant to maintain scheduled-task persistence, receive remote tasking, monitor the user, administer system functions, transfer files, destroy physical-drive contents, damage partition structures, irreversibly encrypt and delete files, disable recovery, sabotage boot functionality, clear event logs, and force system failure.

A successful event may result in irrecoverable data loss, prolonged service interruption, loss of forensic evidence, failed recovery mechanisms, large-scale system rebuilding, customer impact, regulatory review, and reduced confidence in affected systems, backups, administrative activity, and downstream business services.

Likelihood

Moderate for organizations with exposed Windows systems, incomplete application control, weak scheduled-task monitoring, broad messaging or remote-access allowances, limited process-to-network attribution, insufficient raw-disk visibility, weak recovery-administration controls, locally retained evidence, or untested backup and restoration procedures.

Impact

High to Critical depending on affected-system criticality, data concentration, backup integrity, recovery capability, administrative trust, production dependency, customer-service impact, operational-technology exposure, and ability to reconstruct the pre-destruction activity window.

Risk Rating

High

Annualized Risk Exposure

Estimated $1M - $12M+ for organizations with substantial Windows operational dependency, incomplete application control, broad administrative tooling, weak raw-disk restrictions, limited remote evidence retention, concentrated backup dependencies, or incomplete destructive-malware recovery readiness.

Exposure may exceed $12M and approach the high-impact scenario where GigaWiper affects critical production, identity, backup, recovery, security, operational-technology, regulated, shared-storage, or customer-facing systems, or where physical-disk destruction, broad file loss, boot failure, evidence destruction, prolonged outage, enterprise rebuilding, customer remediation, legal escalation, or board-level response is required.

S10 Threat Overview

GigaWiper creates a practical destructive-malware risk by converting a compromised Windows system into a persistent platform for remote control, surveillance, administration, file transfer, and operator-selected destructive impact.

The threat addressed by this TTD is a modular Go-based Windows backdoor that uses scheduled-task persistence, RabbitMQ command tasking, and Redis command-status and output handling to support continuing operator control. The implant can execute shell commands, capture or record the screen, provide VNC-like remote interaction, control keyboard and mouse input, administer processes and services, modify Registry and firewall settings, perform system and security discovery, and transfer files through MinIO tooling.

The destructive components allow an operator to select different impact paths after access has been established. Those paths include raw physical-drive access, partition-metadata destruction, repeated disk overwriting, irreversible file encryption, source-file deletion, Windows recovery disablement, boot-configuration changes, critical boot or kernel-file deletion, event-log clearing, forced restart, and system failure.

The fake-ransomware behavior should be treated as destructive file impact rather than ordinary recoverable ransomware. Files may be transformed, renamed, and deleted without preserving a reliable victim-recovery mechanism.

This TTD treats GigaWiper as a Windows backdoor-to-destruction behavior family, not as a narrow filename, hash, scheduled-task name, Registry artifact, infrastructure address, communication port, file extension, or malware-signature problem.

S13 Targets and Exposure Surface

Primary Targets

·        Windows user endpoints

·        Windows servers

·        Administrative workstations

·        Identity-adjacent systems

·        File servers and shared-storage systems

·        Backup and recovery infrastructure

·        Security-administration systems

·        Engineering and development systems

·        Operational-technology support systems

·        Production application servers

·        Customer-facing Windows systems

·        Cloud-hosted Windows guest systems

·        Systems holding sensitive, regulated, or operationally critical data

Higher-Risk Deployment Conditions

·        Unknown, unsigned, newly observed, or low-prevalence executables can run without restriction

·        Execution from user-writable, temporary, download, or staging paths is broadly permitted

·        Scheduled-task creation and recurring execution are weakly monitored

·        RabbitMQ, AMQP, or Redis communication is broadly allowed from Windows endpoints

·        Endpoint-to-network process attribution is unavailable

·        Asset-role and approved-destination inventories are incomplete

·        New or role-inconsistent inbound listeners are not monitored

·        Remote-support and screen-recording applications are not inventoried

·        Windows Firewall changes are not centrally controlled

·        Raw physical-drive and partition-management activity is not monitored

·        Recovery, boot, backup, and shadow-copy administration is weakly restricted

·        File-event telemetry lacks responsible-process attribution

·        Event logs and EDR evidence are retained only on the affected endpoint

·        Backups remain accessible through the same administrative plane as production systems

·        Backup restoration and bare-metal recovery are untested

·        Critical systems cannot be isolated rapidly

·        Destructive activity can complete before alert review and containment

Exposure Surface

·        Windows executable loading

·        User-writable and temporary paths

·        Windows Task Scheduler

·        RabbitMQ and AMQP communication

·        Redis communication

·        New or unapproved inbound TCP listeners

·        Remote shell execution

·        Screen capture and recording

·        VNC-like remote interaction

·        Keyboard and mouse control

·        Process and service administration

·        Registry administration

·        Windows Firewall administration

·        MinIO and other object-storage clients

·        Physical-drive device paths

·        Raw-disk and partition-control interfaces

·        Volume Shadow Copy administration

·        Backup-catalog administration

·        Windows Recovery Environment controls

·        Boot Configuration Data

·        Critical boot and kernel files

·        Windows event logs

·        High-volume file creation, modification, rename, replacement, encryption, and deletion

·        Restart, crash, boot-failure, and endpoint-health controls

S17 MITRE ATT&CK Chain Flow Mapping

Stage 1: Scheduled-Task Persistence

GigaWiper establishes recurring execution through a Windows scheduled task.

·        T1053.005 Scheduled Task/Job: Scheduled Task — Observed

Stage 2: Command-and-Control and Remote Tasking

The implant uses RabbitMQ for publish/subscribe command-and-control, while Redis supports task and state management.

·        T1071.005 Application Layer Protocol: Publish/Subscribe Protocols — Observed

Stage 3: Surveillance

The operator can capture screenshots and record endpoint activity before selecting additional administrative or destructive actions.

·        T1113 Screen Capture — Observed

Stage 4: Destructive File and System Impact

GigaWiper can destroy files, overwrite physical-drive contents, damage partition structures, disable recovery, clear event logs, and force system restart or failure.

·        T1485 Data Destruction — Observed

·        T1486 Data Encrypted for Impact — Observed

·        T1490 Inhibit System Recovery — Observed

·        T1561.001 Disk Wipe: Disk Content Wipe — Observed

·        T1561.002 Disk Wipe: Disk Structure Wipe — Observed

·        T1070.001 Indicator Removal: Clear Windows Event Logs — Observed

·        T1529 System Shutdown/Reboot — Observed

Conditional Technique Notes

Do not map this TTD to a specific initial-access technique because the current GigaWiper behavior model begins after execution has already been obtained.

Do not map credential access, privilege escalation, lateral movement, Active Directory compromise, automatic enterprise propagation, cloud-control-plane compromise, virtualization-layer compromise, or threat-actor attribution unless incident-specific telemetry establishes those behaviors.

Do not treat file-transfer capability as proof of successful data exfiltration without supporting object-access, transfer, destination, and outcome evidence.

Do not add broader discovery, administration, Registry, service, firewall, or remote-access techniques to the compact attack-chain view unless they materially contribute to a specific incident sequence.

S18 Attack Path Narrative

An attacker first gains the ability to execute GigaWiper on a Windows system.

The current behavior model does not establish one required initial-access method. Delivery may occur through exploitation, credentialed access, remote administration, user execution, tool transfer, or another intrusion path supported by incident-specific evidence.

The implant establishes recurring execution through a Windows scheduled task.

GigaWiper then uses RabbitMQ for publish/subscribe command tasking while Redis handles command-status and output reporting.

The attacker can maintain remote operator access and use the backdoor for shell execution, screen capture, screen recording, VNC-like interaction, keyboard and mouse control, system administration, discovery, and MinIO-based file transfer.

This pre-impact activity allows the attacker to observe the endpoint, understand its operational role, administer system functions, move files, and delay visible destruction until the chosen time.

The attacker may then select one or more destructive paths.

The disk-destruction path can enumerate physical drives, access raw physical-drive devices, damage partition metadata, and repeatedly overwrite disk contents.

The fake-ransomware path can transform and rename files while deleting the original data without preserving a reliable recovery mechanism.

The recovery and boot-sabotage path can disable Windows recovery, remove shadow copies or backup catalogs, modify boot configuration, alter permissions on critical boot or kernel files, delete critical files, and force a restart or system failure.

GigaWiper can also clear Windows event logs or attempt direct deletion of event-log files, reducing local evidence available for incident reconstruction.

The resulting impact may include irrecoverable data loss, unbootable systems, failed recovery, unavailable production services, loss of local forensic evidence, broad system rebuilding, and uncertainty about whether affected systems, backups, administrative activity, and downstream services remain trustworthy.

Defenders should detect this through correlated executable execution, scheduled-task persistence, role-inconsistent RabbitMQ or Redis communication, unapproved inbound sessions, remote-control activity, file-transfer behavior, destructive administrative commands, physical-drive access, partition changes, recovery disablement, boot sabotage, high-volume file destruction, event-log clearing, and endpoint-health loss.

S20 TTP Analysis

Initial Access

The initial-access mechanism is not established within the current GigaWiper behavior model.

Possible delivery paths include exploitation, credentialed access, remote administration, user execution, tool transfer, or another post-compromise execution mechanism. None should be presented as a confirmed GigaWiper requirement without incident-specific evidence.

Execution

GigaWiper executes as a Windows PE implant and exposes operator-selectable commands for shell execution, surveillance, remote control, system administration, file transfer, and destructive impact.

Execution may occur through the scheduled task or another process that launches the implant.

Filename, hash, path, signer, Go build characteristics, and documented sample artifacts are investigative attributes rather than durable execution requirements.

Persistence

Persistence is established through Windows scheduled-task creation and recurring task execution.

The documented OneDrive-themed task is useful for investigation but should not govern the detection model because the task name, executable path, trigger, and associated metadata can be changed.

The documented Registry location tracks execution-related state and should not be treated as the confirmed persistence mechanism.

Privilege Escalation

A separate privilege-escalation mechanism is not established.

Several destructive and administrative functions may require elevated privileges. Current evidence does not establish whether GigaWiper elevates privileges directly, inherits a privileged execution context, or is launched after administrative access has already been obtained.

Defense Evasion

GigaWiper can reduce defensive and investigative visibility through event-log clearing, attempted event-log file deletion, firewall modification, recovery disablement, local evidence destruction, boot sabotage, and deceptive task naming. Its use of legitimate enterprise and Windows administration technologies may also make malicious activity more difficult to distinguish from authorized operations.

Golang, RabbitMQ, Redis, MinIO, PowerShell, and native Windows functions are not independently malicious and should be treated as supporting context only.

Credential Access

Credential theft is not established as a documented GigaWiper capability.

Credential-access techniques should be added only where incident telemetry confirms collection, dumping, interception, theft, or misuse.

Discovery

GigaWiper supports system, firmware, network, user, process, service, security-product, physical-drive, and working-directory discovery.

This allows the operator to understand the endpoint, identify security controls, administer system functions, and select appropriate remote-control or destructive actions.

Command and Control / Tool Transfer

GigaWiper uses RabbitMQ for publish/subscribe command tasking.

Redis handles command-status and output reporting within the operator workflow.

The implant can receive commands, maintain task status, return output, and support continuing operator-selected activity.

VNC-like functionality may expose an inbound listener for interactive remote control.

MinIO tooling supports file movement through object storage.

File-transfer capability should not be treated as proof of successful data exfiltration without supporting transfer, destination, object-access, and outcome evidence.

Impact

GigaWiper can overwrite physical-drive contents, damage partition structures, irreversibly encrypt and delete files, disable recovery, remove backup and shadow-copy data, sabotage boot functionality, clear local evidence, force restart or failure, and create extended rebuilding and restoration requirements.

File destruction, disk-content wiping, disk-structure destruction, recovery sabotage, and boot sabotage affect different recovery layers and should remain separately investigated.

S20A — Adversary Tradecraft Summary

The durable tradecraft pattern is post-compromise backdoor-to-destruction conversion: a Windows implant establishes recurring execution, receives remote tasking, supports surveillance and administration, transfers files, reduces evidence, and allows the operator to select one or more destructive outcomes.

The behavior should be detected through the relationship between scheduled-task persistence, role-inconsistent messaging traffic, remote-control activity, system administration, destructive disk access, partition changes, recovery sabotage, boot modification, high-volume file destruction, event-log clearing, and endpoint failure.

Detection should not depend on one filename, hash, task name, Registry path, infrastructure address, port, file extension, Go symbol, sample identifier, or malware-family signature.

S21 Detection Strategy Overview

GigaWiper detection should identify a Windows backdoor-to-destruction behavior chain rather than depend on a malware name, filename, hash, infrastructure address, scheduled-task name, registry path, network port, or file extension. The governing model covers backdoor execution, persistence, command-and-control, remote tasking, surveillance, system administration, evidence reduction, and destructive impact.

Detection should operate across three related behavior lanes:

·        Backdoor execution and persistence

·        Remote control and command execution

·        Destructive file, disk, boot, and recovery activity

The primary early-stage opportunity is an uncommon, newly observed, or low-prevalence Windows PE executable followed by one or more of these behaviors:

·        Registry execution-state tracking by an uncommon process

·        High-frequency or startup-triggered scheduled-task creation

·        RabbitMQ, AMQP, or Redis communication inconsistent with the endpoint’s role

·        PowerShell or command-shell execution

·        Screen capture or recording

·        Process, service, Registry, or firewall administration

The primary destructive opportunity is a process performing one or more of these behaviors:

·        Physical-disk enumeration

·        Raw physical-drive access

·        Partition-metadata modification

·        Repeated direct writes to physical disks

·        High-volume file encryption and source-file deletion

·        Recovery disablement

·        Boot or kernel-file permission changes and deletion

·        Event-log clearing or direct event-log file deletion

·        Forced reboot, crash, or endpoint-health loss

Current artifacts such as the OneDrive Update scheduled task, HKCU\SOFTWARE\OneDrive\Environment, C:\ProgramData\output, and the .candy extension should be used as enrichment. They must not govern the strategy because an actor can alter these artifacts without changing the underlying behavior.

Scheduled-task confidence should be based on the task action, executable path, registration process, trigger frequency, startup behavior, signer, user context, asset role, and approved-change context rather than the task name alone.

Detection confidence should increase as independent behaviors converge:

·        An uncommon executable alone is a candidate event

·        An uncommon executable followed by persistence or rare protocol use is a suspicious event

·        Persistence followed by remote tasking, screen recording, service manipulation, Registry manipulation, or firewall changes is a high-priority compromise event

·        Raw-disk modification, recovery disablement, boot sabotage, destructive encryption, or evidence destruction is a critical event even when earlier activity is unavailable

Correlation should use the endpoint, executable, process lineage, user, scheduled task, registry activity, network destination, firewall rule, service operation, file activity, disk target, recovery action, and reboot or crash behavior within bounded time windows.

Administrative suppression must be narrowly tied to approved software, validated signers, known binaries, expected asset roles, accountable users, and authorized change windows. Broad suppression for PowerShell, scheduled tasks, RabbitMQ, Redis, remote-support tools, disk utilities, or administrative activity would create material coverage gaps.

This strategy does not claim direct coverage for initial access, credential theft, privilege escalation, lateral movement, Active Directory compromise, cloud abuse, virtualization impact, or enterprise deployment because those behaviors are not established within the current GigaWiper behavior model.

Figure

S22 Primary Detection Signals

Backdoor Execution

·        Execution of an unsigned, newly observed, uncommon, or low-prevalence Windows PE executable

·        Execution from a user-writable, temporary, download, staging, or nonstandard path

·        First-seen execution followed by network communication, persistence, shell execution, or administrative activity

·        Golang build characteristics used only as supporting enrichment where reliable metadata is available

Registry Execution Tracking and Scheduled-Task Persistence

·        Creation or modification of HKCU\SOFTWARE\OneDrive\Environment for execution-state tracking by an uncommon process

·        Creation or modification of a task named OneDrive Update

·        Scheduled execution every minute, at startup, or through another unusually frequent trigger

·        A scheduled task launching an uncommon executable from a nonstandard path

·        Task registration through PowerShell or another unexpected process

·        Repeated execution of the same low-prevalence executable through Task Scheduler

The task name or registry path alone is insufficient. Confidence depends on the task configuration, executable path, responsible process, recurrence, signer, user, asset role, and approved-change context.

Command-and-Control

·        RabbitMQ or AMQP communication from endpoints that do not normally use those protocols

·        Redis communication from endpoints outside approved application or infrastructure roles

·        RabbitMQ and Redis connections to the same rare or external destination

·        Connections on uncommon ports initiated by the suspected backdoor process

·        First-seen or low-prevalence destinations followed by command execution or administrative activity

·        Repeated tasking, status, or output traffic where network metadata supports identification

Shell and Remote Task Execution

·        PowerShell or command-shell execution initiated by the suspected implant

·        Repeated command execution maintaining or changing working-directory state

·        Shell activity followed by file, process, service, Registry, firewall, recovery, or boot changes

·        Administrative commands launched by a scheduled-task process or uncommon executable

Screen Capture and Recording

·        Screenshot creation across one or more active displays

·        Timestamped screenshot directories created by an unapproved process

·        Repeated screen-recording output under C:\ProgramData\output

·        Screen capture or recording followed by staging, archive creation, transfer, or deletion

·        Screen-recording behavior by software absent from the approved application inventory

VNC-Like Remote Control

·        An uncommon executable creating a TCP listener

·        Creation or replacement of inbound and outbound firewall rules for the same executable

·        Firewall-rule names imitating legitimate Windows components

·        A listener port supplied dynamically rather than defined by approved software policy

·        Remote-control activity combined with screen access or user-interaction behavior where telemetry supports that visibility

System and Process Administration

·        Process creation, suspension, resumption, termination, or enumeration by an uncommon executable

·        Service creation, deletion, restart, start, stop, or executable-path modification by an unapproved process

·        Interactive Registry enumeration, navigation, key creation, value modification, or deletion by the suspected implant

·        Collection of system, firmware, network, user, or antivirus information by an uncommon process

External File Transfer

·        Execution of mc.exe or another MinIO client by the suspected backdoor

·        MinIO alias or endpoint creation for a rare or external destination

·        Command-line or process-context credentials associated with object-storage access

·        File upload from a source path selected by an uncommon parent process

·        File transfer following screen capture, discovery, or suspicious file staging

External file transfer is a supporting behavior lane rather than a required stage of the GigaWiper chain.

Physical-Disk Discovery and Destruction

·        WMI or CIM enumeration of physical disks by an uncommon executable

·        Access to \\.\PHYSICALDRIVE*

·        Disk or partition-control operations by software outside approved imaging, recovery, forensic, or storage-management inventories

·        Partition-metadata reinitialization or removal

·        Large or repeated direct writes to physical drives

·        Multi-pass overwrite behavior

·        Raw-disk activity followed by immediate reboot or endpoint-health loss

Destructive File Encryption

·        High-volume file reads followed by encrypted rewrites

·        Source-file deletion after transformation

·        Broad file renaming or extension changes

·        Creation of .candy files as current enrichment

·        Wallpaper replacement associated with destructive file activity

·        Rapid file transformation, deletion, and renaming across multiple directories or volumes

Recovery and Boot Sabotage

·        Windows recovery disablement

·        Boot-configuration modification

·        Ownership or permission changes involving critical boot or kernel files

·        Deletion of critical boot or kernel components

·        Forced crash or blue-screen behavior following destructive preparation

·        Boot failure or abrupt endpoint-health loss after destructive activity

Evidence Destruction

·        Sequential clearing of multiple Windows event-log channels

·        wevtutil.exe launched by the suspected implant or a related shell process

·        Attempted direct deletion of Security.evtx

·        Abrupt logging or EDR telemetry loss following destructive or administrative activity

Critical Severity Conditions

Any of the following should be independently eligible for critical handling when not associated with approved recovery, imaging, forensic, security-testing, or storage-administration activity:

·        Raw physical-drive writes

·        Partition-table destruction

·        Multi-pass system-drive wiping

·        Recovery disablement followed by boot-file deletion

·        High-volume destructive encryption and source-file deletion

·        Direct event-log file deletion

·        Forced restart, crash, or endpoint-health loss following destructive activity

S23 Telemetry Requirements

Core Endpoint Telemetry

·        Process creation

·        Parent and child process relationships

·        Command line

·        Executable path

·        File hash

·        Digital-signature status

·        User and integrity context

·        Process prevalence or first-seen context

·        Process-to-network attribution

·        File creation, modification, rename, and deletion

·        Registry key and value activity

·        Scheduled-task creation, modification, execution, and deletion

·        Service creation, modification, start, stop, restart, and deletion

·        Windows Firewall rule creation, modification, and deletion

·        PowerShell execution and script-block content where enabled

·        WMI or CIM activity

·        Windows event-log clear events

·        Recovery and boot-configuration commands

·        Reboot, crash, boot-failure, and endpoint-health events

Core endpoint telemetry supports detection across the primary persistence, command-execution, system-administration, evidence-reduction, and destructive-behavior lanes. Each S25 rule must identify the specific subset it requires for deployment.

Core Network Telemetry

·        Source and destination address

·        Source and destination port

·        Protocol

·        Connection direction

·        Connection start time and duration

·        Bytes sent and received

·        DNS resolution

·        Process-attributed network activity

·        Rare or first-seen destination context

·        Baselines for RabbitMQ, AMQP, Redis, and externally accessible endpoint listeners

·        Firewall, proxy, or NDR disposition

Payload inspection is not required for the core model. Where communication is encrypted or opaque, detection should rely on process attribution, protocol, destination rarity, port use, timing, and correlated endpoint behavior.

Required Context and Enrichment

·        Endpoint and server inventory

·        Asset criticality

·        Approved RabbitMQ and Redis systems

·        Approved remote-support and screen-recording applications

·        Approved scheduled tasks

·        Approved software-deployment tools

·        Approved disk-imaging, recovery, forensic, and storage-management utilities

·        Approved backup and recovery workflows

·        Approved MinIO or object-storage activity

·        Approved administrative users and service accounts

·        Software signer and organizational prevalence data

·        Maintenance windows and change-control records

·        Authorized penetration-testing, adversary-simulation, and incident-response activity

The listed context and enrichment sources collectively support deployment, tuning, suppression, severity assignment, and differentiation of malicious behavior from legitimate administration across the complete detection program. Each S25 rule requires only the specific context sources identified within that rule.

Each S25 rule must identify which required context sources it consumes and how unavailable context affects deployment, confidence, suppression, or alert severity. A rule must not be treated as fully deployable when its required contextual data is unavailable.

Supporting Telemetry

·        PE metadata and reliable Golang build characteristics

·        Screenshot or display-capture API telemetry

·        Monitor enumeration

·        Session-lock and user-idle checks

·        Object-storage client configuration

·        Archive creation

·        Data-loss-prevention events

·        Endpoint application inventory

·        Network certificate or application-protocol metadata

·        File-entropy changes

Supporting telemetry increases detection confidence but is not required for every rule.

Enhanced Low-Level Visibility

·        Raw device-handle creation

·        Access to \\.\PHYSICALDRIVE*

·        Disk and partition-control operations

·        Relevant DeviceIoControl or IOCTL activity

·        High-volume direct physical-drive writes

·        Multi-pass overwrite patterns

·        Kernel or driver telemetry associated with storage access

·        Keyboard, mouse, screen-streaming, or remote-input telemetry where natively available

These data sources are platform-dependent and must not be assumed to exist. Where direct device visibility is unavailable, detection should use physical-disk discovery, responsible process, disk-management events, reboot behavior, endpoint-health loss, and downstream destructive impact as compensating signals.

Evidence-Preservation Telemetry

·        Centralized Windows event forwarding

·        Remote EDR event retention

·        SIEM ingestion-health monitoring

·        Endpoint sensor-health status

·        Logging-service state

·        Alerts for abrupt telemetry loss

·        Backup and recovery platform events stored outside the affected endpoint

Remote retention is required because local Windows logs and endpoint evidence may be cleared or destroyed.

Minimum Viable Telemetry

The absolute deployment floor for the initial S25 rule build is:

·        Process creation

·        Parent and child process relationships

·        Command line

·        Executable path

·        File creation, modification, rename, and deletion

·        Registry activity

·        Scheduled-task activity

·        Process-attributed network activity

·        PowerShell and administrative-command visibility

·        Windows event-log clear events

·        Reboot and endpoint-health telemetry

This minimum telemetry supports baseline detection of implemented persistence, command activity, network communication, evidence-reduction, and destructive-file behaviors. It also supports investigation and correlation of implant execution, reboot behavior, and endpoint-health loss, but the completed S25 rule set does not provide standalone detections for those behaviors.

It does not provide complete visibility into raw-disk destruction, partition modification, firewall manipulation, service activity, screen capture, remote input, or boot and recovery sabotage.

Rules requiring service telemetry, firewall-change telemetry, raw-disk visibility, screen-capture visibility, or other enhanced data must state those dependencies explicitly and must not be treated as deployable when the required telemetry is unavailable.

S24 Detection Opportunities and Gaps

Detection Opportunities

GigaWiper exposes multiple independent behavior classes, allowing detection before and during destructive execution.

The strongest early-stage correlation is:

·        Uncommon executable execution

·        Registry-based execution tracking

·        High-frequency or startup-triggered scheduled-task persistence

·        Rare RabbitMQ, AMQP, or Redis communication

The strongest remote-control correlation is:

·        Uncommon executable execution

·        Screen capture or recording

·        New TCP listener activity

·        Paired inbound and outbound firewall rules associated with the same executable

The strongest destructive correlation is:

·        Physical-disk discovery

·        Raw-disk or partition modification

·        High-volume direct writes

·        Recovery or boot sabotage

·        Event-log destruction

·        Immediate reboot, crash, or endpoint-health loss

Process lineage substantially improves confidence. Shell execution, service operations, Registry changes, firewall manipulation, screen recording, event-log clearing, and destructive commands should be treated as more significant when they originate from the same uncommon executable, scheduled task, or related process chain.

Detection must also operate when the complete backdoor chain is absent. Standalone wiper execution may produce raw-disk destruction, boot sabotage, evidence destruction, or destructive file encryption without preceding persistence, command-and-control, or remote-control activity.

Detection Gaps

The initial-access method is not established by the current behavior model. This TTD cannot provide direct initial-access coverage without additional evidence and telemetry.

Credential theft, privilege escalation, lateral movement, domain compromise, cloud abuse, virtualization impact, and enterprise propagation are outside direct coverage.

Endpoints without process, command-line, Registry, Task Scheduler, network, firewall, service, file, event-log, recovery, and endpoint-health telemetry may expose only late-stage destructive effects.

Raw physical-drive access and partition-control activity may not be available through standard Windows logs. Coverage will be weaker where EDR, kernel, storage, driver, or device telemetry is unavailable.

RabbitMQ, AMQP, Redis, VNC-like, and object-storage traffic may be encrypted, proxied, encapsulated, or otherwise opaque. Network-only detection may identify anomalous communication without establishing command content.

Screen streaming, keyboard control, mouse control, and low-level capture APIs are not visible in every endpoint platform. Detection may need to rely on listener creation, firewall changes, output-file creation, process behavior, and network correlation.

Destructive commands can complete faster than centralized collection, correlation, analyst review, and manual containment. Detection alone cannot guarantee prevention.

Event-log clearing and direct event-log file deletion may remove local evidence before collection. Centralized telemetry and remote EDR retention are required to preserve investigative visibility.

Legitimate use of RabbitMQ, Redis, PowerShell, scheduled tasks, remote-support tools, screen-recording applications, MinIO, service administration, Registry management, disk utilities, or recovery tools can create false positives without asset, process, signer, user, and change-control context.

Compensating Controls

·        Restrict unknown and low-prevalence executables through endpoint application control or trusted-application policy

·        Enable EDR behavioral blocking and retain endpoint telemetry remotely

·        Restrict unauthorized external RabbitMQ, AMQP, Redis, and object-storage communication

·        Centrally control and monitor host-firewall changes

·        Alert on high-frequency or startup-triggered tasks launching uncommon executables

·        Restrict raw-disk and partition-management activity to approved tools and administrators

·        Protect boot, recovery, backup, and logging infrastructure from endpoint-local compromise

·        Maintain approved inventories for remote-support, screen-recording, disk-management, recovery, messaging, and storage tools

·        Test rapid host isolation and destructive-malware response procedures

These controls address detection gaps. The complete defensive-control and hardening program belongs in S33.

Non-Coverage Conditions

Reliable early-stage coverage is unavailable when the endpoint lacks telemetry needed to associate executable activity with persistence, network communication, administrative actions, and destructive preparation.

Attribution to GigaWiper is not reliable when only one generic behavior is present, such as PowerShell execution, scheduled-task creation, screen capture, service administration, event-log clearing, file encryption, or disk management.

Protocol-level command visibility is not guaranteed when network traffic is encrypted, proxied, encapsulated, or unavailable to the monitoring platform.

Standalone wiper execution may not produce the Registry execution-tracking, scheduled-task, RabbitMQ, Redis, screen-recording, system-management, or remote-control signals associated with the larger backdoor.

Detection does not guarantee interruption when raw-disk wiping, boot sabotage, or destructive encryption occurs before collection and response controls can act.

Detection does not guarantee restoration after partition destruction, multi-pass wiping, boot-file deletion, recovery disablement, or destructive encryption.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

NDR provides viable production coverage for role-inconsistent RabbitMQ, AMQP, or Redis communication and for unapproved inbound listener activity followed by meaningful remote-session behavior. Two rules meet the production threshold.

Rule

Role-Inconsistent RabbitMQ AMQP or Redis Communication

Rule Format

NDR or Network Behavioral Analytics correlation rule using canonical endpoint identity, Windows asset-role context, service-family classification, destination prevalence, approved dependency mapping, bounded aggregation, and alert deduplication.

Detection Purpose

Identify Windows endpoints communicating through RabbitMQ, AMQP, or Redis when the service family, destination, or communication pattern is inconsistent with the endpoint’s assigned role and approved application dependencies.

The rule does not depend on a known address, domain, port, certificate, executable, scheduled-task name, registry path, or malware identifier.

Detection Logic

Alert when a Windows endpoint initiates RabbitMQ, AMQP, or Redis communication and all of the following conditions are met:

·        The source endpoint, source asset role, and destination resolve to stable identities.

·        The communication is not an approved dependency for the source endpoint or assigned asset role.

·        The service family is unexpected for the source role, or the destination is new or rare for the source endpoint.

·        At least three connections occur within 15 minutes when service identification is derived from destination-port mapping.

·        A single external and newly observed connection may qualify only when RabbitMQ, AMQP, or Redis is identified through application or destination-service metadata.

Generate one alert per source endpoint, destination, and service family within 30 minutes.

Endpoint evidence involving an uncommon executable, scheduled-task execution, PowerShell, command-shell activity, screen capture, service manipulation, Registry manipulation, firewall changes, recovery disablement, boot modification, event-log clearing, raw-disk activity, destructive file behavior, forced reboot, crash, or endpoint-health loss should increase investigation priority but is not required for the network rule to alert.

Required Telemetry

·        NDR, firewall, proxy, or flow telemetry.

·        Canonical source endpoint identity.

·        Windows operating-system and asset-role context.

·        Canonical destination identity.

·        Destination address and port.

·        Transport protocol.

·        Application or destination service-family metadata.

·        Destination scope.

·        Destination first-seen or prevalence context.

·        Approved RabbitMQ, AMQP, and Redis dependencies.

·        Connection count, bytes sent, bytes received, and event time.

Process-attributed network activity and endpoint behavior are optional enrichment.

Engineering Implementation Instructions

Use canonical endpoint identity rather than source IP alone.

Require a resolved source asset role. Events without asset-role context may support hunting or inventory remediation but must not satisfy the production alert.

Prefer validated application or destination service metadata for RabbitMQ, AMQP, or Redis identification. When only destination-port mapping is available, require destination rarity and at least three connections within 15 minutes.

Scope approved dependencies to the source endpoint or assigned asset role and the expected destination. Do not suppress all traffic by protocol family, destination port, subnet, or endpoint category.

Treat null or unknown dependency states as unapproved until validated. Null values must not silently suppress an event.

Aggregate connections across a 15-minute window. Deduplicate repeated alerts for the same source endpoint, destination, and service family for 30 minutes.

Preserve a new alert when the destination or service family changes.

DRI Assessment

The rule detects durable role-inconsistent messaging and datastore communication without depending on a fixed destination, port, executable, task name, registry path, or malware identifier. Canonical endpoint resolution, enforced asset-role context, destination-prevalence analysis, approved-dependency mapping, and stronger conditions for port-derived service classification provide strong resilience to superficial implementation changes.

DRI

8.6

TCR Assessment

Operational confidence depends on complete network visibility, canonical endpoint attribution, accurate Windows asset roles, reliable service-family classification, destination-prevalence context, and maintained RabbitMQ, AMQP, and Redis dependency inventories. Full-telemetry confidence improves with process-attributed network activity and endpoint evidence involving persistence, command execution, firewall modification, recovery disablement, boot sabotage, evidence destruction, raw-disk activity, destructive file behavior, reboot, crash, or endpoint-health loss.

Operational TCR

8.0

Full-Telemetry TCR

9.0

Limitations

·        Network telemetry cannot establish command content or destructive intent.

·        Encrypted, proxied, tunneled, or encapsulated traffic may prevent reliable service classification.

·        Port-derived mapping can misclassify traffic and requires stronger anomaly conditions.

·        Legitimate application dependencies may resemble malicious communication when inventories are incomplete.

·        Events without resolved asset-role context cannot satisfy the production rule.

·        NAT, VPN, DHCP, and address reuse can corrupt baselines without canonical endpoint identity.

·        Use of another protocol, an approved dependency, or a trusted relay may bypass the rule.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support canonical endpoint identity, Windows asset-role context, service-family mapping, destination prevalence, approved dependency mapping, bounded aggregation, and deduplication.

LET normalized_connections =

ndr_firewall_proxy_or_flow_events

EVAL canonical_source_endpoint =

RESOLVE_CANONICAL_ENDPOINT_ID(

source_asset_id,

source_host_id,

source_hostname,

source_ip

)

EVAL canonical_destination =

RESOLVE_CANONICAL_DESTINATION_ID(

destination_asset_id,

destination_host_id,

destination_hostname,

destination_domain,

destination_ip

)

EVAL normalized_service_family =

COALESCE(

application_service_family,

destination_service_family,

MAP_PORT_PROTOCOL_TO_SERVICE_FAMILY(

destination_port,

transport_protocol

)

)

EVAL service_identification_source =

CASE

WHEN application_service_family IS NOT NULL

THEN "application"

WHEN destination_service_family IS NOT NULL

THEN "destination_service"

ELSE "port_mapping"

END

EVAL approved_dependency =

COALESCE(

connection_path IN ENV_APPROVED_MESSAGING_DEPENDENCIES,

FALSE

)

EVAL unexpected_for_role =

normalized_service_family

NOT IN ENV_EXPECTED_SERVICE_FAMILIES_BY_ASSET_ROLE

EVAL rare_destination =

destination_first_seen_status IN (

"new",

"rare"

)

OR source_destination_prevalence

<= ENV_LOW_PREVALENCE_THRESHOLD

WHERE canonical_source_endpoint IS NOT NULL

AND source_asset_role IS NOT NULL

AND canonical_destination IS NOT NULL

AND source_operating_system = "windows"

AND normalized_service_family IN (

"rabbitmq",

"amqp",

"redis"

)

AND approved_dependency = FALSE

AND (

unexpected_for_role = TRUE

OR rare_destination = TRUE

)

AND (

service_identification_source IN (

"application",

"destination_service"

)

OR (

service_identification_source = "port_mapping"

AND rare_destination = TRUE

)

)

LET aggregated_suspicious_connections =

normalized_connections

GROUP BY

canonical_source_endpoint,

source_asset_role,

canonical_destination,

destination_scope,

destination_first_seen_status,

normalized_service_family,

service_identification_source

WITHIN 15 MINUTES

CALCULATE

COUNT(*) AS connection_count,

SUM(bytes_sent) AS total_bytes_sent,

SUM(bytes_received) AS total_bytes_received,

MIN(event_time) AS first_seen,

MAX(event_time) AS last_seen

WHERE (

service_identification_source = "port_mapping"

AND connection_count >= 3

)

OR (

service_identification_source IN (

"application",

"destination_service"

)

AND (

connection_count >= 3

OR (

destination_scope = "external"

AND destination_first_seen_status = "new"

)

)

)

LET deduplicated_suspicious_connections =

DEDUP aggregated_suspicious_connections

BY

canonical_source_endpoint,

canonical_destination,

normalized_service_family

WITHIN 30 MINUTES

OUTPUT deduplicated_suspicious_connections

canonical_source_endpoint,

source_asset_role,

canonical_destination,

destination_scope,

destination_first_seen_status,

normalized_service_family,

service_identification_source,

connection_count,

total_bytes_sent,

total_bytes_received,

first_seen,

last_seen

Rule

Unapproved Windows Endpoint Listener with Remote Session Activity

Rule Format

NDR or Network Behavioral Analytics correlation rule using canonical destination identity, Windows asset-role context, accepted inbound-session telemetry, first-seen destination-port context, source trust classification, approved inbound-service mapping, bounded aggregation, and alert deduplication.

Detection Purpose

Identify a Windows endpoint accepting inbound TCP connections on a new or role-inconsistent port and then maintaining meaningful remote-session activity.

The rule does not depend on a fixed listener port, firewall-rule name, executable, process name, remote-access product, protocol banner, or known infrastructure.

Detection Logic

Alert when a Windows endpoint accepts inbound TCP communication and all of the following conditions are met:

·        The destination endpoint and destination asset role resolve to stable identities.

·        The destination port is new, rare, or unexpected for the endpoint’s assigned role.

·        The connection path is not an approved inbound service.

·        At least two accepted sessions occur within 15 minutes.

·        At least one accepted session lasts 30 seconds or longer.

Exclude blocked connections, rejected connections, incomplete handshakes, failed sessions, and isolated scanning activity.

Generate one alert per destination endpoint and destination port within 30 minutes.

Include the observed source addresses and source-trust context in the alert output so the activity can be investigated and blocked.

Endpoint evidence involving an uncommon process opening the listener, related firewall-rule creation, screen capture, remote-input behavior, shell execution, scheduled-task activity, service manipulation, Registry manipulation, recovery disablement, boot modification, event-log clearing, raw-disk activity, destructive file behavior, forced reboot, crash, or endpoint-health loss should increase investigation priority but is not required for the network rule to alert.

Required Telemetry

·        NDR, firewall, or bidirectional flow telemetry.

·        Canonical destination endpoint identity.

·        Windows operating-system and asset-role context.

·        Source and destination address.

·        Destination port.

·        Transport protocol.

·        Connection direction and result.

·        Session duration.

·        Bytes sent and bytes received.

·        First-seen or prevalence context for the destination port.

·        Source trust or prevalence classification.

·        Approved inbound-service paths.

Process-to-network attribution, firewall-rule changes, screen capture, remote-input activity, and endpoint behavior are optional enrichment.

Engineering Implementation Instructions

Resolve the destination to a canonical endpoint identity before evaluating port novelty or role inconsistency.

Require a resolved destination asset role. Events without asset-role context may support hunting or inventory remediation but must not satisfy the production alert.

Require accepted or established inbound communication. Do not treat outbound communication, blocked attempts, rejected attempts, incomplete handshakes, failed sessions, or isolated probes as listener activity.

Use first-seen destination-port context and role-aware expected inbound-port mappings. Servers, jump hosts, development systems, and approved remote-support endpoints must not share the same baseline as user workstations.

Scope approved inbound services to the destination endpoint or assigned asset role and the expected source path. Do not suppress all activity associated with a common port, remote-support vendor, subnet, or source network.

Treat null or unknown approved-service states as unapproved until validated.

Aggregate accepted sessions across a 15-minute window. Deduplicate repeated alerts for the same destination endpoint and destination port for 30 minutes.

Preserve a new alert when the destination port changes.

Include distinct observed source addresses and source-trust classifications in the alert output.

DRI Assessment

The rule detects durable unapproved listener and remote-session behavior without depending on a fixed port, executable, process path, firewall-rule name, remote-access product, source address, or GigaWiper-specific artifact. Canonical endpoint resolution, enforced asset-role context, role-aware inbound-service baselining, accepted-session enforcement, first-seen port context, source-trust classification, and bounded correlation provide strong resilience to common implementation changes.

DRI

8.5

TCR Assessment

Operational confidence depends on complete inbound-session visibility, canonical destination attribution, accurate Windows asset roles, reliable connection-result data, first-seen destination-port context, source-trust classification, and maintained approved inbound-service inventories. Full-telemetry confidence improves when listener activity can be attributed to a process and correlated with firewall changes, screen capture, remote-input activity, command execution, recovery disablement, boot sabotage, evidence destruction, raw-disk activity, destructive file behavior, reboot, crash, or endpoint-health loss.

Operational TCR

7.8

Full-Telemetry TCR

8.9

Limitations

·        Some flow platforms cannot directly confirm that the destination process opened a listening socket.

·        NAT, reverse proxies, VPN concentrators, load balancers, and port forwarding may obscure the true endpoint.

·        Encrypted traffic may prevent remote-control classification.

·        Legitimate remote-support, development, testing, administrative, and application services may resemble unauthorized listeners.

·        Events without resolved destination asset-role context cannot satisfy the production rule.

·        Outbound reverse tunnels, approved remote-support products, existing approved listeners, and brokered relays may bypass the rule.

·        Network telemetry may establish unauthorized remote interaction without identifying screen capture, keyboard control, mouse control, or executed commands.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support canonical endpoint identity, accepted inbound-session visibility, first-seen destination-port context, Windows asset-role baselines, source trust classification, approved inbound-service mapping, bounded aggregation, source collection, and deduplication.

LET normalized_inbound_sessions =

ndr_firewall_or_bidirectional_flow_events

EVAL canonical_destination_endpoint =

RESOLVE_CANONICAL_ENDPOINT_ID(

destination_asset_id,

destination_host_id,

destination_hostname,

destination_ip

)

EVAL approved_inbound_service =

COALESCE(

connection_path IN ENV_APPROVED_INBOUND_SERVICE_PATHS,

FALSE

)

EVAL unexpected_destination_port =

destination_port_first_seen_status IN (

"new",

"rare"

)

OR destination_port

NOT IN ENV_EXPECTED_INBOUND_PORTS_BY_ASSET_ROLE

WHERE canonical_destination_endpoint IS NOT NULL

AND destination_asset_role IS NOT NULL

AND destination_operating_system = "windows"

AND transport_protocol = "tcp"

AND connection_direction = "inbound"

AND connection_result IN (

"accepted",

"established"

)

AND approved_inbound_service = FALSE

AND unexpected_destination_port = TRUE

LET aggregated_remote_sessions =

normalized_inbound_sessions

GROUP BY

canonical_destination_endpoint,

destination_asset_role,

destination_port,

destination_port_first_seen_status

WITHIN 15 MINUTES

CALCULATE

COUNT(*) AS accepted_session_count,

COUNT_DISTINCT(source_ip) AS unique_source_count,

COLLECT_DISTINCT(source_ip, 20) AS observed_source_ips,

COLLECT_DISTINCT(

source_trust_classification,

10

) AS observed_source_trust_classifications,

MAX(session_duration) AS maximum_session_duration,

SUM(bytes_sent) AS total_bytes_sent,

SUM(bytes_received) AS total_bytes_received,

MIN(event_time) AS first_seen,

MAX(event_time) AS last_seen

WHERE accepted_session_count >= 2

AND maximum_session_duration >= 30 SECONDS

LET deduplicated_remote_sessions =

DEDUP aggregated_remote_sessions

BY

canonical_destination_endpoint,

destination_port

WITHIN 30 MINUTES

OUTPUT deduplicated_remote_sessions

canonical_destination_endpoint,

destination_asset_role,

destination_port,

destination_port_first_seen_status,

accepted_session_count,

unique_source_count,

observed_source_ips,

observed_source_trust_classifications,

maximum_session_duration,

total_bytes_sent,

total_bytes_received,

first_seen,

last_seen

SentinelOne

Detection Viability Assessment

SentinelOne can provide strong behavior-driven coverage for the GigaWiper backdoor-to-destruction model through Deep Visibility and STAR when Windows process command-line, executable, user, endpoint, and process-group telemetry are available.

Three behavior-based rule opportunities survive validation:

·        Scheduled-task persistence command execution

·        User-context autorun Registry persistence command execution as broader Windows persistence coverage

·        Physical-drive, recovery, boot, backup, or evidence-destruction command execution

Each rule is independently deployable. No rule depends on another CyberDax rule firing first. The rules use direct process-event conditions and customer-maintained approved-workflow exclusions rather than unsupported multi-event correlation, synthetic event sources, or invented helper functions.

Rule

Scheduled-Task Persistence Command Execution

Rule Format

SentinelOne Deep Visibility process query deployed as a STAR custom detection rule using Windows process name, command line, executable hash, executable path, user, endpoint, and process-group telemetry.

Detection Purpose

Detect command execution that creates or modifies a Windows scheduled task for persistence or recurring execution.

The rule identifies behavior consistent with backdoor installation or persistence without depending on a specific task name, executable filename, hash, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows process activity

·        Match schtasks.exe task-creation or task-change commands

·        Match Register-ScheduledTask only when executed through powershell.exe or pwsh.exe

·        Require a populated process command line, executable hash, and process-group identifier

·        Exclude activity only when the executable hash, executable path, user, endpoint, and complete command collectively match an approved deployment, administration, configuration-management, incident-response, or security-testing workflow

·        Generate one alert per endpoint and process group

·        Suppress repeated matches from the same endpoint and process group for 60 minutes

Required Telemetry

·        Windows process creation telemetry

·        Process name, executable path, command line, and SHA-1 hash

·        Process-group identifier

·        User context

·        Endpoint name, site, and group

·        Approved executable hashes, executable paths, users, endpoints, and complete scheduled-task command patterns

Engineering Implementation Instructions

·        Deploy the query as a STAR custom detection rule

·        Replace each environment placeholder with a validated customer-maintained value

·        Maintain narrow approved combinations of executable hash, executable path, user, endpoint, and complete command pattern

·        Require Register-ScheduledTask to originate from powershell.exe or pwsh.exe

·        Do not suppress all schtasks.exe, PowerShell, administrative-user, or Microsoft-signed activity

·        Validate approved task commands against the complete normalized command line

·        Use alert-only mode during initial tuning

·        Apply a 60-minute suppression period for repeated matches sharing the same AgentName and ProcessGroupId

·        Present the alert as scheduled-task persistence activity, not confirmed GigaWiper activity

DRI Assessment

The rule detects durable scheduled-task persistence behavior rather than task names, executable filenames, hashes, or campaign-specific artifacts. Process-name anchoring, command-line anchoring, and complete-workflow exclusions provide strong resistance to superficial implementation changes and reduce matches caused by unrelated processes containing PowerShell cmdlet text.

DRI

8.8

TCR Assessment

Operational confidence depends on complete process-name, process command-line, executable, user, endpoint, and process-group telemetry. Full-telemetry confidence improves with parent-process, task-creation audit, endpoint-role, and approved-change context.

Operational TCR

8.6

Full-Telemetry TCR

9.2

Limitations

·        Scheduled tasks created through direct APIs without visible command-line activity may not match

·        Approved deployment and administration tools may produce similar commands

·        Obfuscated PowerShell may evade exact command-pattern matching

·        Renamed or copied PowerShell binaries may evade process-name anchoring unless equivalent executable classification is implemented

·        Missing process-group, process-name, or command-line telemetry reduces coverage

·        The rule does not independently establish GigaWiper attribution

Detection Query Pattern

Use this Deep Visibility query as the STAR event condition. Replace the environment placeholders with validated customer values.

AgentOS = "windows"
AND ProcessCmd Is Not Empty
AND ProcessImageSha1Hash Is Not Empty
AND ProcessGroupId Is Not Empty
AND
(
(
ProcessName = "schtasks.exe"
AND
(
ProcessCmd RegExp "(?i)(^|\s)/create(\s|$)"
OR ProcessCmd RegExp "(?i)(^|\s)/change(\s|$)"
)
)
OR
(
(
ProcessName = "powershell.exe"
OR ProcessName = "pwsh.exe"
)
AND ProcessCmd ContainsCIS "Register-ScheduledTask"
)
)
AND NOT (
ProcessImageSha1Hash In (
ENV_APPROVED_SCHEDULED_TASK_PROCESS_HASHES
)
AND ProcessImagePath In (
ENV_APPROVED_SCHEDULED_TASK_PROCESS_PATHS
)
AND User In (
ENV_APPROVED_SCHEDULED_TASK_USERS
)
AND AgentName In (
ENV_APPROVED_SCHEDULED_TASK_ENDPOINTS
)
AND ProcessCmd RegExp ENV_APPROVED_SCHEDULED_TASK_COMMAND_REGEX
)

Rule

User-Context Autorun Registry Persistence Command Execution

Rule Format

SentinelOne Deep Visibility process query deployed as a STAR custom detection rule using Windows process name, command line, executable hash, executable path, user, endpoint, and process-group telemetry.

Detection Purpose

Detect command execution that creates or modifies user-context Windows autorun Registry values used to launch a program during user logon or startup.

The rule identifies durable Windows autorun Registry persistence behavior without depending on a specific Registry value name, payload filename, hash, malware family, or campaign identifier. It provides broader behavior-based persistence coverage but does not directly detect GigaWiper’s documented Registry execution-state tracking.

Detection Logic

·        Scope the rule to Windows process activity

·        Match reg.exe add commands targeting supported user-context autorun locations

·        Match Set-ItemProperty or New-ItemProperty only when executed through powershell.exe or pwsh.exe

·        Require a populated process command line, executable hash, and process-group identifier

·        Exclude activity only when the executable hash, executable path, user, endpoint, and complete command collectively match an approved deployment, administration, configuration-management, incident-response, or security-testing workflow

·        Generate one alert per endpoint and process group

·        Suppress repeated matches from the same endpoint and process group for 60 minutes

Required Telemetry

·        Windows process creation telemetry

·        Process name, executable path, command line, and SHA-1 hash

·        Process-group identifier

·        User context

·        Endpoint name, site, and group

·        Approved executable hashes, executable paths, users, endpoints, and complete Registry command patterns

Engineering Implementation Instructions

·        Deploy the query as a STAR custom detection rule

·        Replace each environment placeholder with a validated customer-maintained value

·        Maintain narrow approved combinations of executable hash, executable path, user, endpoint, and complete command pattern

·        Require Set-ItemProperty and New-ItemProperty to originate from powershell.exe or pwsh.exe

·        Do not suppress all reg.exe, PowerShell, administrative-user, or Microsoft-signed activity

·        Validate approved Registry commands against the complete normalized command line

·        Keep the targeted Registry locations limited to validated autorun or execution-trigger locations

·        Use alert-only mode during initial tuning

·        Apply a 60-minute suppression period for repeated matches sharing the same AgentName and ProcessGroupId

·        Present the alert as user-context Registry persistence activity, not confirmed GigaWiper activity

DRI Assessment

The rule detects durable autorun Registry persistence behavior rather than value names, payload filenames, hashes, or malware-specific strings. Process-name anchoring, command-line anchoring, and complete-workflow exclusions provide strong resistance to superficial artifact changes and prevent unrelated processes containing PowerShell cmdlet text from satisfying the PowerShell branch.

DRI

8.8

TCR Assessment

Operational confidence depends on complete process-name, process command-line, executable, user, endpoint, and process-group telemetry. Full-telemetry confidence improves with Registry-event, parent-process, endpoint-role, and approved-change context.

Operational TCR

8.6

Full-Telemetry TCR

9.2

Limitations

·        Registry persistence created through direct APIs without visible command-line activity may not match

·        Persistence through services, WMI, startup folders, or unsupported Registry locations is outside this rule

·        Approved software deployment and administration may produce similar commands

·        Obfuscated PowerShell may evade exact command-pattern matching

·        Renamed or copied PowerShell binaries may evade process-name anchoring unless equivalent executable classification is implemented

·        The rule does not independently establish GigaWiper attribution

Detection Query Pattern

Use this Deep Visibility query as the STAR event condition. Replace the environment placeholders with validated customer values.

AgentOS = "windows"
AND ProcessCmd Is Not Empty
AND ProcessImageSha1Hash Is Not Empty
AND ProcessGroupId Is Not Empty
AND
(
(
ProcessName = "reg.exe"
AND ProcessCmd RegExp "(?i)(^|\s)add(\s|$)"
AND
(
ProcessCmd ContainsCIS "\Software\Microsoft\Windows\CurrentVersion\Run"
OR ProcessCmd ContainsCIS "\Software\Microsoft\Windows\CurrentVersion\RunOnce"
OR ProcessCmd ContainsCIS "\Software\Microsoft\Windows NT\CurrentVersion\Windows"
)
)
OR
(
(
ProcessName = "powershell.exe"
OR ProcessName = "pwsh.exe"
)
AND
(
ProcessCmd ContainsCIS "Set-ItemProperty"
OR ProcessCmd ContainsCIS "New-ItemProperty"
)
AND
(
ProcessCmd ContainsCIS "\Software\Microsoft\Windows\CurrentVersion\Run"
OR ProcessCmd ContainsCIS "\Software\Microsoft\Windows\CurrentVersion\RunOnce"
OR ProcessCmd ContainsCIS "\Software\Microsoft\Windows NT\CurrentVersion\Windows"
)
)
)
AND NOT (
ProcessImageSha1Hash In (
ENV_APPROVED_REGISTRY_PERSISTENCE_PROCESS_HASHES
)
AND ProcessImagePath In (
ENV_APPROVED_REGISTRY_PERSISTENCE_PROCESS_PATHS
)
AND User In (
ENV_APPROVED_REGISTRY_PERSISTENCE_USERS
)
AND AgentName In (
ENV_APPROVED_REGISTRY_PERSISTENCE_ENDPOINTS
)
AND ProcessCmd RegExp ENV_APPROVED_REGISTRY_PERSISTENCE_COMMAND_REGEX
)

Rule

Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

Rule Format

SentinelOne Deep Visibility process query deployed as a STAR custom detection rule using Windows process name, command line, executable hash, executable path, user, endpoint, and process-group telemetry.

Detection Purpose

Detect command execution that references a Windows physical-drive device, deletes shadow copies or backup catalogs, disables Windows recovery, alters boot-recovery settings, or clears Windows event logs.

The rule does not depend on a specific wiper filename, executable hash, disk number, ransom artifact, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows process activity

·        Match command lines referencing \\.\PHYSICALDRIVE

·        Match supported wmic.exe and vssadmin.exe shadow-copy deletion commands

·        Match supported wbadmin.exe backup-catalog deletion commands

·        Match supported reagentc.exe Windows Recovery Environment disablement commands

·        Match supported bcdedit.exe boot-recovery configuration changes

·        Match supported wevtutil.exe event-log clearing commands

·        Match Clear-EventLog only when executed through powershell.exe or pwsh.exe

·        Do not treat diskpart.exe /s or DiskPart process creation as proof that a destructive clean operation occurred

·        Require a populated process command line, executable hash, and process-group identifier

·        Exclude activity only when the executable hash, executable path, user, endpoint, and complete command collectively match an approved imaging, recovery, forensic, storage-management, incident-response, administration, or security-testing workflow

·        Generate one alert per endpoint and process group

·        Suppress repeated matches from the same endpoint and process group for 60 minutes

Required Telemetry

·        Windows process creation telemetry

·        Process name, executable path, command line, and SHA-1 hash

·        Process-group identifier

·        User context

·        Endpoint name, site, and group

·        Approved executable hashes, executable paths, users, endpoints, and complete destructive-administration command patterns

Raw device-access, disk-control, boot-state, event-log, restart, and endpoint-health telemetry increase confidence where available but are not required for this process-command rule.

Direct confirmation of DiskPart clean or clean all requires script-content visibility or confirmed disk or partition state-change telemetry that is not implemented by this SentinelOne process-command query.

Engineering Implementation Instructions

·        Deploy the query as a STAR custom detection rule

·        Replace each environment placeholder with a validated customer-maintained value

·        Maintain narrow approved combinations of executable hash, executable path, user, endpoint, and complete command pattern

·        Do not broadly suppress wmic.exe, vssadmin.exe, wbadmin.exe, reagentc.exe, bcdedit.exe, wevtutil.exe, PowerShell, command-shell, administrative-user, or Microsoft-signed activity

·        Require Clear-EventLog to originate from powershell.exe or pwsh.exe

·        Do not search a diskpart.exe process command line for clean or clean all

·        Do not alert on diskpart.exe /s alone under this process-command rule

·        Treat DiskPart execution without script-content or resulting-state visibility as suspicious supporting activity rather than confirmed destructive disk activity

·        Do not treat ordinary restart or shutdown commands as sufficient detection conditions

·        Validate approved commands against the complete normalized command line

·        Use alert-only mode during initial tuning

·        Apply a 60-minute suppression period for repeated matches sharing the same AgentName and ProcessGroupId

·        Assign critical severity to physical-drive references, recovery disablement, or boot sabotage on production and high-value endpoints

·        Present the alert as destructive physical-drive, recovery, boot, backup, or evidence-destruction command activity, not confirmed GigaWiper activity

DRI Assessment

The rule detects durable physical-drive references and destructive recovery, boot, backup, and evidence-reduction commands without depending on a particular executable copy, disk number, filename, hash, or malware identity. Process-name anchoring for PowerShell event-log clearing and removal of the unreliable DiskPart command-line branch improve technical validity. Direct DiskPart destruction remains outside this process-command rule unless script content or resulting disk-state telemetry is available through another control.

DRI

8.8

TCR Assessment

Operational confidence depends on complete process-name, process command-line, executable, user, endpoint, and process-group telemetry. Full-telemetry confidence improves with raw-device, disk-control, boot-state, event-log, recovery, backup, restart, and endpoint-health telemetry. DiskPart destruction confidence specifically requires script-content visibility or confirmed disk or partition state-change telemetry outside this process-command query.

Operational TCR

8.6

Full-Telemetry TCR

9.3

Limitations

·        Direct device access performed without a visible process command line may not match

·        DiskPart clean or clean all commands entered interactively or supplied through a script are not detected by this process-command rule unless script content or resulting disk-state telemetry is separately collected

·        Custom drivers, direct API calls, or in-memory code may bypass command-based detection

·        Approved imaging, recovery, forensic, and storage-management activity may produce similar commands

·        Obfuscated PowerShell or renamed utility copies may evade process-name-specific branches

·        Renamed or copied PowerShell binaries may evade the Clear-EventLog branch unless equivalent executable classification is implemented

·        Destructive activity may complete before endpoint isolation occurs

·        The rule does not guarantee recovery or independently establish GigaWiper attribution

Detection Query Pattern

Use this Deep Visibility query as the STAR event condition. Replace the environment placeholders with validated customer values.

AgentOS = "windows"
AND ProcessCmd Is Not Empty
AND ProcessImageSha1Hash Is Not Empty
AND ProcessGroupId Is Not Empty
AND
(
ProcessCmd ContainsCIS "\\.\PHYSICALDRIVE"
OR ProcessCmd RegExp "(?i)\bwmic(?:\.exe)?\b.*\bshadowcopy\b.*\bdelete\b"

OR ProcessCmd RegExp "(?i)\bvssadmin(?:\.exe)?\b.*\bdelete\b.*\bshadows\b"

OR ProcessCmd RegExp "(?i)\bwbadmin(?:\.exe)?\b.*\bdelete\b.*\bcatalog\b"

OR ProcessCmd RegExp "(?i)\breagentc(?:\.exe)?\b.*(?:^|\s)/disable(?:\s|$)"

OR ProcessCmd RegExp "(?i)\bbcdedit(?:\.exe)?\b.*(?:^|\s)/set(?:\s|$).*\brecoveryenabled\b.*\bno\b"

OR ProcessCmd RegExp "(?i)\bbcdedit(?:\.exe)?\b.*(?:^|\s)/set(?:\s|$).*\bbootstatuspolicy\b.*\bignoreallfailures\b"

OR ProcessCmd RegExp "(?i)\bwevtutil(?:\.exe)?\b.*(?:^|\s)cl(?:\s|$)"
OR
(
(
ProcessName = "powershell.exe"
OR ProcessName = "pwsh.exe"
)
AND ProcessCmd ContainsCIS "Clear-EventLog"
)
)
AND NOT (
ProcessImageSha1Hash In (
ENV_APPROVED_DESTRUCTIVE_ADMIN_PROCESS_HASHES
)
AND ProcessImagePath In (
ENV_APPROVED_DESTRUCTIVE_ADMIN_PROCESS_PATHS
)
AND User In (
ENV_APPROVED_DESTRUCTIVE_ADMIN_USERS
)
AND AgentName In (
ENV_APPROVED_DESTRUCTIVE_ADMIN_ENDPOINTS
)
AND ProcessCmd RegExp ENV_APPROVED_DESTRUCTIVE_ADMIN_COMMAND_REGEX
)

Splunk

Detection Viability Assessment

Splunk can provide strong behavior-driven coverage for the GigaWiper backdoor-to-destruction model when normalized Windows process, Registry, scheduled-task, file, disk, recovery, boot, event-log, endpoint, and asset-context telemetry are available.

Three rule opportunities survive validation:

·        Confirmed Windows persistence establishment through scheduled tasks or autorun Registry locations

·        Destructive disk, recovery, boot, backup, or evidence-degradation activity

·        High-volume destructive file transformation with source deletion or rename activity

Each rule is independently deployable. No rule requires another CyberDax rule to fire first. The implementation patterns normalize branch-specific telemetry, apply customer-maintained approved-workflow exceptions, preserve endpoint and process lineage, and generate one result per actionable behavior group.

Rule

Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

Rule Format

Splunk correlation search using normalized Windows process, Registry, and scheduled-task telemetry with process lineage, confirmed modification outcomes, branch-specific approved exceptions, and endpoint enrichment.

Detection Purpose

Detect confirmed scheduled-task creation or modification and confirmed autorun Registry modification associated with an unapproved process or command.

The rule identifies durable Windows persistence behavior without depending on a specific task name, Registry value name, payload filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Normalize Windows process, Registry, and scheduled-task telemetry into a common field model.

·        Require a confirmed scheduled-task creation or modification event, a confirmed autorun Registry modification event, or a process command that directly performs one of those actions.

·        Preserve the responsible process, parent process, command line, user, process identifier, and persistence target.

·        Require successful, confirmed, or state-changing outcomes for Registry and scheduled-task event branches.

·        Apply branch-specific approved exceptions for scheduled-task activity and Registry persistence activity.

·        Enrich the result with endpoint role, exposure class, and asset criticality.

·        Generate one result per endpoint, process identity, process, user, persistence type, and persistence target within 15 minutes.

·        When native process identity is unavailable, construct a fallback identity from endpoint, process hash, user, and correlation bucket rather than substituting the process hash alone.

Required Telemetry

·        Windows process creation telemetry

·        Registry modification telemetry

·        Scheduled-task creation and modification telemetry

·        Process name, executable path, command line, hash, parent process, and unique process identifier where available

·        User context

·        Registry path, task name, and task path

·        Event outcome

·        Endpoint identifier, hostname, asset role, exposure class, and asset criticality

·        Approved scheduled-task and Registry-persistence activity mappings

Engineering Implementation Instructions

·        Replace each macro with a validated customer-specific search when it is not already implemented.

·        Map only confirmed scheduled-task and Registry modification events into the corresponding event branches.

·        Maintain separate approved-activity lookups for scheduled tasks and Registry persistence.

·        Do not broadly suppress PowerShell, schtasks.exe, reg.exe, administrative users, Microsoft-signed software, deployment systems, or remote-support tools.

·        Require a complete approved-workflow match rather than suppressing activity because one field is approved.

·        Use a separate 15-minute correlation-bucket field so the original event time remains available for accurate first_seen and last_seen calculation.

·        Prefer native process-group, Storyline, process-GUID, entity, or process-ID values.

·        When native process identity is unavailable, construct the fallback from endpoint, process hash, user, and correlation bucket.

·        Generate one notable event per endpoint, normalized process identity, persistence type, and persistence target.

·        Assign high priority when the endpoint is critical, identity-adjacent, administrative, operational-technology, or externally exposed.

·        Present the result as confirmed or command-observed persistence establishment, not confirmed GigaWiper activity.

DRI Assessment

The rule detects durable scheduled-task and autorun Registry persistence behavior rather than campaign-specific artifacts. Separate telemetry branches, confirmed outcomes, process lineage, target mapping, and branch-specific exceptions provide strong resistance to filename, hash, task-name, and Registry-value changes.

DRI

9.0

TCR Assessment

Operational confidence depends on normalized process, Registry, scheduled-task, event-outcome, process-lineage, endpoint, and approved-workflow telemetry. Full-telemetry confidence improves with task-creation audit data, Registry value data, executable prevalence, endpoint role, user-session, and software-inventory context.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Direct API persistence may not match when responsible-process or target telemetry is unavailable.

·        Command-observed branches may indicate attempted activity when no corresponding modification event is collected.

·        Obfuscated PowerShell or alternate persistence mechanisms may evade the command branches.

·        Incomplete event-outcome normalization can reduce confidence.

·        Constructed process identities can combine separate executions when endpoint, process hash, user, and correlation bucket are identical and no native process identifier is available.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Windows process, Registry, scheduled-task, endpoint, and asset-context telemetry; confirmed modification outcomes; process lineage; persistence-target mappings; and branch-specific approved exceptions. The macros must be replaced with validated customer-specific searches when they are not already implemented.

`windows_process_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature))

| eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

| eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

| eval normalized_registry_path=null()

| eval normalized_task_name=null()

| eval normalized_task_path=null()

| eval telemetry_branch="process_command"

| append [

    search `windows_registry_events`

    | eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

    | eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

    | eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

    | eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

    | eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature,registry_action))

    | eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

    | eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

    | eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

    | eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

    | eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

    | eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

    | eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

    | eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

    | eval normalized_registry_path=lower(coalesce(registry_path,registry_key_path,registry_key,TargetObject))

    | eval normalized_task_name=null()

    | eval normalized_task_path=null()

    | eval telemetry_branch="registry_event"

]

| append [

    search `windows_scheduled_task_events`

    | eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

    | eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

    | eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

    | eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

    | eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature,task_action))

    | eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

    | eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

    | eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

    | eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

    | eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

    | eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

    | eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

    | eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

    | eval normalized_registry_path=null()

    | eval normalized_task_name=lower(coalesce(task_name,scheduled_task_name,TaskName))

    | eval normalized_task_path=lower(coalesce(task_path,scheduled_task_path,TaskPath))

    | eval telemetry_branch="scheduled_task_event"

]

| lookup ENV_WINDOWS_MONITORED_ASSETS normalized_endpoint OUTPUT windows_asset_match asset_role exposure_class asset_criticality

| lookup ENV_WINDOWS_AUTORUN_REGISTRY_PATHS normalized_registry_path OUTPUT autorun_registry_match persistence_family

| lookup ENV_APPROVED_SCHEDULED_TASK_ACTIVITY normalized_endpoint normalized_user normalized_process_name normalized_process_path normalized_command_line normalized_task_name normalized_task_path normalized_time OUTPUT approved_scheduled_task_activity

| lookup ENV_APPROVED_REGISTRY_PERSISTENCE_ACTIVITY normalized_endpoint normalized_user normalized_process_name normalized_process_path normalized_command_line normalized_registry_path normalized_time OUTPUT approved_registry_activity

| eval windows_asset_match=coalesce(windows_asset_match,"false")

| eval autorun_registry_match=coalesce(autorun_registry_match,"false")

| eval approved_scheduled_task_activity=coalesce(approved_scheduled_task_activity,"false")

| eval approved_registry_activity=coalesce(approved_registry_activity,"false")

| eval scheduled_task_command=if(

    telemetry_branch="process_command"

    AND (

        (

            normalized_process_name="schtasks.exe"

            AND match(normalized_command_line,"(?i)(^|\\s)/(create|change)(\\s|$)")

        )

        OR like(normalized_command_line,"%register-scheduledtask%")

    ),

    "true",

    "false"

)

| eval registry_persistence_command=if(

    telemetry_branch="process_command"

    AND (

        (

            normalized_process_name="reg.exe"

            AND match(normalized_command_line,"(?i)(^|\\s)add(\\s|$)")

        )

        OR like(normalized_command_line,"%set-itemproperty%")

        OR like(normalized_command_line,"%new-itemproperty%")

    )

    AND (

        like(normalized_command_line,"%\\software\\microsoft\\windows\\currentversion\\run%")

        OR like(normalized_command_line,"%\\software\\microsoft\\windows\\currentversion\\runonce%")

        OR like(normalized_command_line,"%\\software\\microsoft\\windows nt\\currentversion\\windows%")

    ),

    "true",

    "false"

)

| eval confirmed_scheduled_task_change=if(

    telemetry_branch="scheduled_task_event"

    AND normalized_event_type IN ("task_created","task_registered","task_modified","scheduled_task_created","scheduled_task_registered","scheduled_task_modified")

    AND normalized_event_outcome IN ("confirmed","success","successful","succeeded","created","modified","state_changed"),

    "true",

    "false"

)

| eval confirmed_registry_persistence=if(

    telemetry_branch="registry_event"

    AND autorun_registry_match="true"

    AND normalized_event_type IN ("registry_value_created","registry_value_set","registry_value_modified","registry_key_created","registry_modified")

    AND normalized_event_outcome IN ("confirmed","success","successful","succeeded","created","modified","state_changed"),

    "true",

    "false"

)

| eval persistence_type=case(

    confirmed_scheduled_task_change="true" OR scheduled_task_command="true","scheduled_task_persistence",

    confirmed_registry_persistence="true" OR registry_persistence_command="true","autorun_registry_persistence"

)

| eval persistence_target=case(

    persistence_type="scheduled_task_persistence",coalesce(normalized_task_path,normalized_task_name,"command_observed_scheduled_task"),

    persistence_type="autorun_registry_persistence",coalesce(normalized_registry_path,"command_observed_autorun_registry")

)

| eval approved_event=case(

    persistence_type="scheduled_task_persistence",approved_scheduled_task_activity,

    persistence_type="autorun_registry_persistence",approved_registry_activity,

    true(),"false"

)

| where windows_asset_match="true"

| where normalized_os="windows"

| where confirmed_scheduled_task_change="true" OR confirmed_registry_persistence="true" OR scheduled_task_command="true" OR registry_persistence_command="true"

| where approved_event!="true"

| eval correlation_bucket=normalized_time

| bin correlation_bucket span=15m

| eval normalized_process_identity=if(

    isnotnull(native_process_identity) AND tostring(native_process_identity)!="",

    tostring(native_process_identity),

    normalized_endpoint."|".coalesce(normalized_process_hash,"no_hash")."|".coalesce(normalized_user,"no_user")."|".tostring(correlation_bucket)

)

| stats earliest(normalized_time) as first_seen latest(normalized_time) as last_seen values(normalized_host) as normalized_host values(normalized_parent_process_name) as normalized_parent_process_name values(normalized_command_line) as normalized_command_line values(normalized_event_type) as normalized_event_type values(normalized_event_outcome) as normalized_event_outcome values(asset_role) as asset_role values(exposure_class) as exposure_class values(asset_criticality) as asset_criticality count by correlation_bucket normalized_endpoint normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_user persistence_type persistence_target

| eval priority=case(

    mvfind(asset_criticality,"critical")>=0 OR mvfind(asset_criticality,"high")>=0,"high",

    mvfind(asset_role,"identity_adjacent_system")>=0 OR mvfind(asset_role,"administrative_workstation")>=0 OR mvfind(asset_role,"operational_technology")>=0,"high",

    true(),"medium"

)

| eval event_kind="confirmed_or_command_observed_windows_persistence"

| table first_seen last_seen normalized_endpoint normalized_host normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_parent_process_name normalized_command_line normalized_user persistence_type persistence_target normalized_event_type normalized_event_outcome asset_role exposure_class asset_criticality count priority event_kind

Rule

Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

Rule Format

Splunk correlation search using normalized Windows process, disk, recovery, boot, backup, event-log, and endpoint telemetry with destructive-command mappings, confirmed state-change outcomes, approved-workflow exceptions, and asset enrichment.

Detection Purpose

Detect physical-drive access, disk-clean activity, recovery disablement, shadow-copy or backup-catalog deletion, destructive boot-configuration modification, and confirmed Windows event-log clearing.

The rule identifies destructive administration and wiper-enabling behavior without depending on a specific executable copy, disk number, filename, hash, malware family, or campaign identifier.

Detection Logic

·        Normalize Windows process and destructive-control telemetry.

·        Match validated destructive disk, recovery, boot, backup, and event-log commands.

·        Match confirmed disk, recovery, boot, backup, or event-log state changes where direct control telemetry is available.

·        Preserve process, command, user, endpoint, target, event outcome, and process identity.

·        Exclude only complete approved imaging, recovery, forensic, storage-management, administration, incident-response, or security-testing workflows.

·        Assign high priority to physical-drive, disk-clean, recovery-disablement, and boot-sabotage activity.

·        Generate one result per endpoint, process identity, destructive behavior, and target within 15 minutes.

·        When native process identity is unavailable, construct a fallback identity from endpoint, process hash, user, and correlation bucket rather than substituting the process hash alone.

Required Telemetry

·        Windows process creation telemetry

·        Disk and partition activity where available

·        Recovery and boot-configuration telemetry where available

·        Backup and shadow-copy telemetry where available

·        Event-log clearing telemetry

·        Process name, executable path, command line, hash, parent process, and unique process identifier where available

·        User and endpoint context

·        Target device, service, control, or log

·        Event outcome

·        Asset role, exposure class, and asset criticality

·        Approved destructive-administration workflow mappings

Engineering Implementation Instructions

·        Replace each macro with a validated customer-specific search when it is not already implemented.

·        Maintain a validated destructive-command lookup rather than embedding customer-specific command variants throughout the search.

·        Require confirmed outcomes for direct disk, recovery, boot, backup, and event-log control events.

·        Do not treat ordinary restart or shutdown activity as a sufficient detection condition.

·        Do not broadly suppress signed utilities, administrative users, Microsoft tools, imaging systems, or recovery systems.

·        Use complete approved-workflow matching that includes endpoint, user, process, command or control target, and time context.

·        Use a separate 15-minute correlation-bucket field so the original event time remains available for accurate first_seen and last_seen calculation.

·        Prefer native process-group, Storyline, process-GUID, entity, or process-ID values.

·        When native process identity is unavailable, construct the fallback from endpoint, process hash, user, and correlation bucket.

·        Generate one notable event per endpoint, normalized process identity, destructive behavior, and target.

·        Assign critical severity to confirmed physical-drive destruction, disk cleaning, recovery disablement, or boot sabotage on critical assets.

·        Present the result as destructive disk, recovery, boot, backup, or evidence-degradation activity, not confirmed GigaWiper activity.

DRI Assessment

The rule detects durable destructive administration and wiper-enabling behavior across command and confirmed-control branches. It remains effective against renamed utilities, copied binaries, changed disk numbers, and malware-family changes when the destructive action remains observable.

DRI

9.3

TCR Assessment

Operational confidence depends on complete process command-line, destructive-command, control-event, event-outcome, process-lineage, endpoint, and approved-workflow telemetry. Full-telemetry confidence improves with raw-device, disk-control, boot-state, recovery, backup, event-log, restart, and endpoint-health data.

Operational TCR

9.0

Full-Telemetry TCR

9.6

Limitations

·        Direct API or driver-based destruction may not match when command and control telemetry are unavailable.

·        Destructive actions may complete before isolation or response occurs.

·        Approved imaging, recovery, forensic, or storage-management workflows can resemble malicious activity.

·        Incomplete event-outcome data can prevent confirmed-control branches from matching.

·        Constructed process identities can combine separate executions when endpoint, process hash, user, and correlation bucket are identical and no native process identifier is available.

·        The rule does not guarantee recovery or independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Windows process, disk, recovery, boot, backup, event-log, endpoint, and asset-context telemetry; destructive-command mappings; confirmed control outcomes; and approved destructive-administration exceptions. The macros must be replaced with validated customer-specific searches when they are not already implemented.

`windows_process_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature))

| eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

| eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

| eval normalized_target=null()

| eval telemetry_branch="process_command"

| append [

    search `windows_destructive_control_events`

    | eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

    | eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

    | eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

    | eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

    | eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature,control_action))

    | eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

    | eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

    | eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

    | eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

    | eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

    | eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

    | eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

    | eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

    | eval normalized_target=lower(coalesce(target_device,target_disk,target_volume,target_service,target_log,target_control,target_object))

    | eval telemetry_branch="control_event"

]

| lookup ENV_WINDOWS_MONITORED_ASSETS normalized_endpoint OUTPUT windows_asset_match asset_role exposure_class asset_criticality

| lookup ENV_WINDOWS_DESTRUCTIVE_COMMANDS normalized_command_line OUTPUT destructive_command_match destructive_behavior destructive_severity

| lookup ENV_WINDOWS_DESTRUCTIVE_CONTROL_EVENTS normalized_event_type normalized_target OUTPUT destructive_control_match destructive_behavior_from_control destructive_severity_from_control

| lookup ENV_APPROVED_DESTRUCTIVE_ADMIN_ACTIVITY normalized_endpoint normalized_user normalized_process_name normalized_process_path normalized_command_line normalized_event_type normalized_target normalized_time OUTPUT approved_destructive_activity

| eval windows_asset_match=coalesce(windows_asset_match,"false")

| eval destructive_command_match=coalesce(destructive_command_match,"false")

| eval destructive_control_match=coalesce(destructive_control_match,"false")

| eval approved_destructive_activity=coalesce(approved_destructive_activity,"false")

| eval confirmed_control_event=if(

    telemetry_branch="control_event"

    AND destructive_control_match="true"

    AND normalized_event_outcome IN ("confirmed","success","successful","succeeded","deleted","disabled","modified","cleared","state_changed"),

    "true",

    "false"

)

| eval destructive_behavior=coalesce(destructive_behavior,destructive_behavior_from_control)

| eval destructive_severity=coalesce(destructive_severity,destructive_severity_from_control,"medium")

| where windows_asset_match="true"

| where normalized_os="windows"

| where destructive_command_match="true" OR confirmed_control_event="true"

| where approved_destructive_activity!="true"

| eval correlation_bucket=normalized_time

| bin correlation_bucket span=15m

| eval normalized_process_identity=if(

    isnotnull(native_process_identity) AND tostring(native_process_identity)!="",

    tostring(native_process_identity),

    normalized_endpoint."|".coalesce(normalized_process_hash,"no_hash")."|".coalesce(normalized_user,"no_user")."|".tostring(correlation_bucket)

)

| stats earliest(normalized_time) as first_seen latest(normalized_time) as last_seen values(normalized_host) as normalized_host values(telemetry_branch) as telemetry_branch values(normalized_parent_process_name) as normalized_parent_process_name values(normalized_command_line) as normalized_command_line values(normalized_event_type) as normalized_event_type values(normalized_event_outcome) as normalized_event_outcome values(normalized_target) as normalized_target values(asset_role) as asset_role values(exposure_class) as exposure_class values(asset_criticality) as asset_criticality values(destructive_severity) as destructive_severity count by correlation_bucket normalized_endpoint normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_user destructive_behavior

| eval priority=case(

    destructive_behavior IN ("physical_drive_access","disk_clean","disk_partition_destruction","recovery_disabled","boot_recovery_sabotage"),"critical",

    mvfind(asset_criticality,"critical")>=0 OR mvfind(asset_criticality,"high")>=0,"high",

    mvfind(destructive_severity,"high")>=0 OR mvfind(destructive_severity,"critical")>=0,"high",

    true(),"medium"

)

| eval event_kind="destructive_disk_recovery_boot_backup_or_evidence_activity"

| table first_seen last_seen normalized_endpoint normalized_host normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_parent_process_name normalized_command_line normalized_user telemetry_branch destructive_behavior destructive_severity normalized_event_type normalized_event_outcome normalized_target asset_role exposure_class asset_criticality count priority event_kind

Rule

High-Volume Destructive File Transformation With Source Deletion or Rename Activity

Rule Format

Splunk correlation search using normalized Windows file and process telemetry with process lineage, affected-path context, file-action counts, extension diversity, source-deletion or rename requirements, role-aware thresholds, and approved-workflow exceptions.

Detection Purpose

Detect a process performing high-volume file creation, modification, rename, replacement, or deletion activity while also deleting or renaming source files across multiple paths or extensions.

The rule identifies destructive file-transformation behavior without depending on a particular extension, ransom note, wallpaper, executable filename, hash, encryption implementation, malware family, or campaign identifier.

Detection Logic

·        Normalize Windows file activity and responsible-process context.

·        Require file creation, modification, rename, replacement, or deletion events attributed to a process.

·        Require at least one file rename or deletion event within the correlated process activity.

·        Count matching file events, distinct affected paths, distinct directories, and valid file extensions within five minutes.

·        Exclude extensionless filenames from the distinct-extension count.

·        Apply lower thresholds to user endpoints and higher role-aware thresholds to file servers, backup systems, synchronization systems, deployment infrastructure, and development systems.

·        Exclude validated backup, synchronization, encryption, migration, archiving, deployment, indexing, recovery, and security-testing workflows.

·        Preserve endpoint, process identity, process details, user, affected paths, action types, and asset role.

·        Generate one result per endpoint, process identity, process, and user within five minutes.

·        When native process identity is unavailable, construct a fallback identity from endpoint, process hash, user, and correlation bucket rather than substituting the process hash alone.

Required Telemetry

·        Windows file creation, modification, rename, replacement, and deletion telemetry

·        File name, full path, directory, and extension

·        Responsible process name, executable path, command line, hash, parent process, and unique process identifier where available

·        User context

·        Endpoint role, exposure class, and asset criticality

·        Approved high-volume file-workflow mappings

·        File-server, backup-server, synchronization-server, deployment-system, and development-system role mappings

File entropy, write volume, backup state, recovery state, and endpoint-health telemetry improve confidence but are not required.

Engineering Implementation Instructions

·        Replace each macro with a validated customer-specific search when it is not already implemented.

·        Require responsible-process attribution for every included file event.

·        Maintain narrow approved-workflow mappings that include endpoint, user, process identity, target path, action, and time context.

·        Do not suppress activity solely because the process is signed, the endpoint is a server, or the user is an administrator.

·        Use a separate five-minute correlation-bucket field so the original event time remains available for accurate first_seen and last_seen calculation.

·        Use an initial five-minute threshold of 50 matching file events for standard user endpoints.

·        Use higher customer-validated thresholds for file servers, backup servers, synchronization systems, deployment infrastructure, indexing systems, and development platforms.

·        Require at least one rename or deletion event and activity across multiple affected paths or valid file extensions.

·        Do not count extensionless filenames as distinct extensions.

·        Prefer native process-group, Storyline, process-GUID, entity, or process-ID values.

·        When native process identity is unavailable, construct the fallback from endpoint, process hash, user, and correlation bucket.

·        Generate one notable event per endpoint, normalized process identity, process, and user.

·        Assign high priority when the process affects multiple directories or extensions on a critical or high-value endpoint.

·        Present the result as high-volume destructive file activity, not confirmed ransomware or GigaWiper activity.

DRI Assessment

The rule detects durable high-volume destructive file behavior rather than fixed extensions, filenames, ransom artifacts, hashes, or encryption libraries. Process identity, action diversity, affected-path breadth, valid extension diversity, role-aware thresholds, and approved-workflow exclusions provide strong variant resistance.

DRI

9.1

TCR Assessment

Operational confidence depends on complete file-event attribution, process identity, path fidelity, file-action normalization, endpoint-role mapping, and approved-workflow tuning. Full-telemetry confidence improves with entropy, write volume, backup state, recovery state, endpoint health, and centralized evidence retention.

Operational TCR

8.9

Full-Telemetry TCR

9.5

Limitations

·        Slow or selectively targeted file destruction may remain below the threshold.

·        Incomplete file telemetry may undercount file changes, renames, or deletions.

·        Backup, synchronization, encryption, migration, archiving, deployment, indexing, and recovery tools can produce similar activity.

·        Trusted or signed software may be abused.

·        Constructed process identities can combine separate executions when endpoint, process hash, user, and correlation bucket are identical and no native process identifier is available.

·        Detection may occur after files have already been damaged.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support normalized Windows file and process telemetry; responsible-process attribution; endpoint-role mappings; file-action, directory, and extension normalization; role-aware thresholds; and approved high-volume file-workflow exceptions. The macros must be replaced with validated customer-specific searches when they are not already implemented.

`windows_file_events`

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_host=coalesce(hostname,host,dest,dvc,device_name)

| eval normalized_endpoint=coalesce(endpoint_id,agent_id,device_id,host_id,normalized_host)

| eval normalized_os=lower(coalesce(os,host_os,operating_system,platform))

| eval normalized_event_type=lower(coalesce(event_type,EventType,action,operation,signature,file_action))

| eval normalized_event_outcome=lower(coalesce(event_outcome,outcome,result,status))

| eval normalized_process_name=lower(coalesce(process_name,process,ImageName,exe_name))

| eval normalized_process_path=lower(coalesce(process_path,process_exec,Image,exe))

| eval normalized_process_hash=lower(coalesce(process_sha256,process_hash,sha256,process_sha1,sha1))

| eval normalized_parent_process_name=lower(coalesce(parent_process_name,parent_process,ParentImageName,parent_name))

| eval normalized_command_line=lower(coalesce(process_command_line,command_line,CommandLine,cmdline))

| eval normalized_user=lower(coalesce(user,dest_user,account_name,subject_user_name))

| eval native_process_identity=coalesce(process_group_id,storyline_id,process_guid,process_entity_id,process_id,ProcessId,pid)

| eval normalized_file_path=lower(coalesce(file_path,target_path,TargetFilename,path))

| eval normalized_file_name=lower(coalesce(file_name,TargetFilename,name))

| eval normalized_file_extension=lower(

    coalesce(

        file_extension,

        extension,

        if(

            match(normalized_file_name,"\\.[^.]+$"),

            replace(normalized_file_name,"^.*\\.([^.]*)$","\\1"),

            null()

        )

    )

)

| eval normalized_directory=lower(coalesce(file_directory,directory,replace(normalized_file_path,"\\\\[^\\\\]+$","")))

| lookup ENV_WINDOWS_MONITORED_ASSETS normalized_endpoint OUTPUT windows_asset_match asset_role exposure_class asset_criticality

| lookup ENV_APPROVED_HIGH_VOLUME_FILE_ACTIVITY normalized_endpoint normalized_user normalized_process_name normalized_process_path normalized_process_hash normalized_file_path normalized_event_type normalized_time OUTPUT approved_file_activity

| lookup ENV_WINDOWS_HIGH_VOLUME_FILE_THRESHOLDS asset_role OUTPUT minimum_file_events minimum_distinct_paths minimum_distinct_directories minimum_distinct_extensions

| eval windows_asset_match=coalesce(windows_asset_match,"false")

| eval approved_file_activity=coalesce(approved_file_activity,"false")

| eval minimum_file_events=coalesce(minimum_file_events,50)

| eval minimum_distinct_paths=coalesce(minimum_distinct_paths,20)

| eval minimum_distinct_directories=coalesce(minimum_distinct_directories,3)

| eval minimum_distinct_extensions=coalesce(minimum_distinct_extensions,3)

| where windows_asset_match="true"

| where normalized_os="windows"

| where normalized_file_path!=""

| where normalized_event_type IN ("file_created","file_written","file_modified","file_replaced","file_renamed","file_deleted")

| where normalized_event_outcome IN ("confirmed","success","successful","succeeded","created","written","modified","replaced","renamed","deleted","state_changed") OR isnull(normalized_event_outcome)

| where approved_file_activity!="true"

| eval correlation_bucket=normalized_time

| bin correlation_bucket span=5m

| eval normalized_process_identity=if(

    isnotnull(native_process_identity) AND tostring(native_process_identity)!="",

    tostring(native_process_identity),

    normalized_endpoint."|".coalesce(normalized_process_hash,"no_hash")."|".coalesce(normalized_user,"no_user")."|".tostring(correlation_bucket)

)

| stats earliest(normalized_time) as first_seen latest(normalized_time) as last_seen values(normalized_host) as normalized_host values(normalized_parent_process_name) as normalized_parent_process_name values(normalized_command_line) as normalized_command_line values(normalized_event_type) as file_actions values(normalized_file_path) as affected_file_paths values(asset_role) as asset_role values(exposure_class) as exposure_class values(asset_criticality) as asset_criticality max(minimum_file_events) as minimum_file_events max(minimum_distinct_paths) as minimum_distinct_paths max(minimum_distinct_directories) as minimum_distinct_directories max(minimum_distinct_extensions) as minimum_distinct_extensions count as file_event_count dc(normalized_file_path) as distinct_file_paths dc(normalized_directory) as distinct_directories dc(normalized_file_extension) as distinct_file_extensions count(eval(normalized_event_type="file_renamed")) as rename_event_count count(eval(normalized_event_type="file_deleted")) as deletion_event_count by correlation_bucket normalized_endpoint normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_user

| where file_event_count>=minimum_file_events

| where distinct_file_paths>=minimum_distinct_paths

| where distinct_directories>=minimum_distinct_directories OR distinct_file_extensions>=minimum_distinct_extensions

| where rename_event_count>0 OR deletion_event_count>0

| eval priority=case(

    (mvfind(asset_criticality,"critical")>=0 OR mvfind(asset_criticality,"high")>=0) AND distinct_directories>=minimum_distinct_directories AND distinct_file_extensions>=minimum_distinct_extensions,"high",

    file_event_count>=(minimum_file_events*2),"high",

    true(),"medium"

)

| eval event_kind="high_volume_destructive_file_transformation"

| table first_seen last_seen normalized_endpoint normalized_host normalized_process_identity normalized_process_name normalized_process_path normalized_process_hash normalized_parent_process_name normalized_command_line normalized_user file_actions file_event_count rename_event_count deletion_event_count distinct_file_paths distinct_directories distinct_file_extensions affected_file_paths asset_role exposure_class asset_criticality minimum_file_events minimum_distinct_paths minimum_distinct_directories minimum_distinct_extensions priority event_kind

Elastic

Detection Viability Assessment

Elastic can provide strong behavior-driven coverage for the GigaWiper backdoor-to-destruction model when normalized Windows process, Registry, scheduled-task, disk, recovery, boot, backup, event-log, file, endpoint, and asset-context telemetry are available.

Three rule opportunities survive validation:

·        Confirmed Windows persistence establishment through scheduled tasks or autorun Registry locations

·        Destructive disk, recovery, boot, backup, or evidence-degradation activity

·        High-volume destructive file rename or deletion activity

Each rule is independently deployable. No rule requires another CyberDax rule to fire first. The implementation patterns use branch-specific approved exceptions, confirmed outcomes where required, endpoint and process enrichment, and rule types suited to the behavior being detected.

Rule

Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

Rule Format

Elastic Security EQL event-correlation rule using normalized Windows process, Registry, scheduled-task, endpoint, process-lineage, event-outcome, and persistence-target telemetry.

Detection Purpose

Detect confirmed scheduled-task creation or modification, confirmed autorun Registry modification, or command execution that directly performs one of those persistence actions.

The rule identifies durable Windows persistence behavior without depending on a specific task name, Registry value name, payload filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows endpoints.

·        Match schtasks.exe commands that create or modify scheduled tasks.

·        Match PowerShell or PowerShell Core execution of Register-ScheduledTask.

·        Match reg.exe commands that add supported autorun Registry values.

·        Match PowerShell or PowerShell Core execution of Set-ItemProperty or New-ItemProperty against supported autorun Registry locations.

·        Match confirmed scheduled-task creation, registration, or modification events.

·        Match confirmed Registry value creation or modification in supported autorun locations.

·        Require successful, confirmed, or state-changing outcomes for scheduled-task and Registry event branches.

·        Preserve process identity, parent-process context, command line, user, task target, Registry target, endpoint role, and asset criticality where available.

·        Apply separate approved exceptions to scheduled-task and Registry-persistence branches.

·        Treat an absent approved-workflow field as unapproved rather than excluding the event.

·        Generate one alert for each matching persistence event.

·        Suppress repeated alerts by endpoint and process identity for 60 minutes when both suppression fields are populated.

·        Configure alerts missing either suppression field to remain unsuppressed.

Required Telemetry

·        Windows process-start telemetry

·        Registry creation and modification telemetry

·        Scheduled-task creation, registration, and modification telemetry

·        Process name, executable, command line, hash, entity identifier, process identifier, and parent-process context

·        User identity

·        Registry path, task name, and task path

·        Event action, type, and outcome

·        Endpoint identifier and hostname

·        Asset role, exposure class, and asset criticality where available

·        Approved scheduled-task and Registry-persistence exception lists

Engineering Implementation Instructions

·        Map the neutral implementation fields to the customer’s Elastic Common Schema and locally enriched fields.

·        Use optional-field syntax for branch-specific or locally enriched fields that may be absent from one or more searched data streams.

·        Use null-safe exception conditions so an absent exception field does not prevent a legitimate match.

·        Map only confirmed scheduled-task and Registry modification events into the corresponding event branches.

·        Maintain separate exception lists for scheduled-task and Registry-persistence activity.

·        Do not broadly suppress PowerShell, schtasks.exe, reg.exe, administrative users, Microsoft-signed software, deployment systems, or remote-support tools.

·        Require PowerShell persistence cmdlets to originate from powershell.exe or pwsh.exe.

·        Require a complete approved-workflow match rather than suppressing activity because one attribute is approved.

·        Configure alert suppression using host.id and process.entity_id for 60 minutes.

·        Configure alerts missing host.id or process.entity_id to remain unsuppressed.

·        Do not claim target-specific suppression unless the local ingest pipeline provides a consistently populated target field across every matched branch.

·        Use asset criticality and endpoint role for severity or routing after the base behavior matches.

·        Present command-only matches as command-observed persistence activity.

·        Present confirmed event matches as confirmed persistence establishment.

·        Do not present either branch as confirmed GigaWiper activity.

DRI Assessment

The rule detects scheduled-task and autorun Registry persistence behavior rather than campaign-specific artifacts. Separate telemetry branches, confirmed outcomes, process lineage, persistence-target matching, process-name anchoring, and branch-specific exceptions provide strong resistance to filename, hash, task-name, and Registry-value changes.

DRI

9.0

TCR Assessment

Operational confidence depends on normalized process, Registry, scheduled-task, process-lineage, event-outcome, endpoint, and approved-workflow telemetry. Full-telemetry confidence improves with Registry value data, scheduled-task audit data, executable prevalence, endpoint role, user-session, and software-inventory context.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Direct API persistence may not match when responsible-process or target telemetry is unavailable.

·        Command-observed branches may represent attempted activity when no corresponding modification event is collected.

·        Obfuscated PowerShell or alternate persistence mechanisms may evade the command branches.

·        Renamed or copied PowerShell binaries may evade process-name anchoring unless equivalent executable classification is implemented.

·        Incomplete event-outcome normalization can reduce confidence.

·        Alerts without host.id or process.entity_id are not deduplicated through process-based alert suppression.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support Windows process, Registry, scheduled-task, endpoint, asset-context, and process-lineage telemetry; confirmed modification outcomes; persistence-target classification; branch-specific approved exceptions; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where

host.os.type == "windows" and

(

  (

    event.category == "process" and

    event.type == "start" and

    (

      ?exception.approved_scheduled_task_activity == null or

      ?exception.approved_scheduled_task_activity != true

    ) and

    (

      (

        ?process.name : "schtasks.exe" and

        ?process.command_line : (

          "*/create *",

          "* /create *",

          "*/change *",

          "* /change *"

        )

      ) or

      (

        ?process.name : (

          "powershell.exe",

          "pwsh.exe"

        ) and

        ?process.command_line : "*Register-ScheduledTask*"

      )

    )

  ) or

  (

    event.category == "process" and

    event.type == "start" and

    (

      ?exception.approved_registry_persistence_activity == null or

      ?exception.approved_registry_persistence_activity != true

    ) and

    (

      (

        ?process.name : "reg.exe" and

        ?process.command_line : (

          "* add *",

          "* add"

        )

      ) or

      (

        ?process.name : (

          "powershell.exe",

          "pwsh.exe"

        ) and

        ?process.command_line : (

          "*Set-ItemProperty*",

          "*New-ItemProperty*"

        )

      )

    ) and

    ?process.command_line : (

      "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run*",

      "*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce*",

      "*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows*"

    )

  ) or

  (

    event.category == "configuration" and

    ?scheduled_task.change.confirmed == true and

    (

      ?exception.approved_scheduled_task_activity == null or

      ?exception.approved_scheduled_task_activity != true

    ) and

    ?scheduled_task.action in (

      "task_created",

      "task_registered",

      "task_modified",

      "scheduled_task_created",

      "scheduled_task_registered",

      "scheduled_task_modified"

    ) and

    ?event.outcome in (

      "success",

      "successful",

      "succeeded"

    )

  ) or

  (

    event.category == "registry" and

    ?registry.change.confirmed == true and

    (

      ?exception.approved_registry_persistence_activity == null or

      ?exception.approved_registry_persistence_activity != true

    ) and

    ?registry.action in (

      "registry_value_created",

      "registry_value_set",

      "registry_value_modified",

      "registry_key_created",

      "registry_modified"

    ) and

    ?event.outcome in (

      "success",

      "successful",

      "succeeded"

    ) and

    ?registry.path : (

      ENV_WINDOWS_AUTORUN_REGISTRY_PATHS

    )

  )

) and

(

  ?process.entity_id != null or

  ?process.pid != null or

  ?scheduled_task.id != null or

  ?registry.path != null

)

Rule

Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

Rule Format

Elastic Security EQL event-correlation rule using normalized Windows process, DiskPart script classification, disk, recovery, boot, backup, event-log, endpoint, control-outcome, and asset-context telemetry.

Detection Purpose

Detect physical-drive access, confirmed destructive DiskPart script execution, recovery disablement, shadow-copy or backup-catalog deletion, destructive boot-configuration modification, and confirmed Windows event-log clearing.

The rule identifies destructive administration and wiper-enabling behavior without depending on a specific disk number, script filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows endpoints.

·        Match command lines that reference physical-drive device paths.

·        Match diskpart.exe /s execution only when locally enriched script-content telemetry confirms that the supplied script contains clean or clean all.

·        Treat diskpart.exe /s without confirmed destructive script content as suspicious staging that does not independently satisfy this rule.

·        Treat confirmed disk_cleaned or disk_partition_destroyed control telemetry as the authoritative DiskPart destruction branch.

·        Match wmic.exe shadow-copy deletion.

·        Match vssadmin.exe shadow-copy deletion.

·        Match wbadmin.exe backup-catalog deletion.

·        Match reagentc.exe /disable.

·        Match bcdedit.exe /set changes that disable recovery or configure IgnoreAllFailures.

·        Match PowerShell or PowerShell Core execution of Clear-EventLog.

·        Match wevtutil.exe cl event-log clearing.

·        Match confirmed disk, recovery, boot, backup, or event-log state changes where direct control telemetry is available.

·        Require successful or confirmed outcomes for direct control-event branches.

·        Preserve process identity, parent process, command line, user, endpoint, control target, destructive classification, and asset criticality where available.

·        Exclude complete approved imaging, recovery, forensic, storage-management, administration, incident-response, and security-testing workflows.

·        Treat an absent approved-workflow field as unapproved rather than excluding the event.

·        Do not treat ordinary restart, shutdown, or unclassified DiskPart script execution as sufficient.

·        Generate one alert for each matching destructive event on any Windows endpoint.

·        Suppress repeated alerts by endpoint and process identity for 60 minutes when both suppression fields are populated.

·        Configure alerts missing either suppression field to remain unsuppressed.

·        Use asset criticality and endpoint role for severity escalation and routing rather than as detection requirements.

Required Telemetry

·        Windows process-start telemetry

·        DiskPart process execution and script-content classification where the DiskPart process branch is enabled

·        Disk and partition control telemetry where available

·        Recovery and boot-configuration telemetry where available

·        Backup, shadow-copy, and catalog telemetry where available

·        Windows event-log clearing telemetry

·        Process name, executable, command line, hash, process entity identifier, process identifier, and parent-process context

·        User identity

·        Target device, disk, volume, boot setting, recovery setting, backup object, or event log

·        Event action, type, and outcome

·        Endpoint identifier and hostname

·        Asset role, exposure class, and asset criticality where available

·        Approved destructive-administration exception lists

Engineering Implementation Instructions

·        Map the neutral implementation fields to the customer’s ECS and locally enriched fields.

·        Use optional-field syntax for branch-specific or locally enriched fields that may be absent from one or more searched data streams.

·        Use null-safe exception conditions so an absent exception field does not prevent a legitimate match.

·        Do not search the diskpart.exe process command line for clean or clean all.

·        Detect diskpart.exe /s as destructive only when an ingest pipeline, endpoint integration, script collector, or equivalent enrichment confirms destructive script content.

·        Map confirmed disk cleaning or partition destruction to the direct control-event branch whenever that telemetry is available.

·        Do not alert on diskpart.exe /s alone under this destructive rule.

·        Require /set in the bcdedit.exe branches.

·        Require Clear-EventLog to originate from powershell.exe or pwsh.exe.

·        Implement customer-specific destructive command variants through locally validated wildcard patterns or equivalent ingest-time classification.

·        Require confirmed outcomes for direct disk, recovery, boot, backup, and event-log control events.

·        Do not broadly suppress signed utilities, administrative users, Microsoft tools, imaging systems, recovery systems, or forensic systems.

·        Require a complete approved-workflow match that includes endpoint, user, process, command or target, and time context.

·        Configure alert suppression using host.id and process.entity_id for 60 minutes.

·        Configure alerts missing host.id or process.entity_id to remain unsuppressed.

·        Do not claim destructive-behavior or target-based suppression unless those fields are consistently populated across every matched branch.

·        Allow the base rule to detect qualifying behavior on all Windows endpoints.

·        Apply high or critical severity through rule configuration, alert enrichment, or downstream workflow when the endpoint is critical, identity-adjacent, administrative, operational-technology, backup, or recovery infrastructure.

·        Present unconfirmed command matches as destructive command execution.

·        Present confirmed control matches as confirmed destructive state change.

·        Do not present either branch as confirmed GigaWiper activity.

DRI Assessment

The rule detects durable destructive-administration and wiper-enabling behavior across command, enriched DiskPart-script, and confirmed-control branches. It remains effective against changed disk numbers, altered script filenames, and malware-family changes when the destructive command, script classification, or control action remains observable.

DRI

9.2

TCR Assessment

Operational confidence depends on complete process command-line, process-lineage, destructive-command, DiskPart script-classification, control-event, event-outcome, endpoint, target, and approved-workflow telemetry. Full-telemetry confidence improves with raw-device, disk-control, boot-state, recovery, backup, event-log, script-content, and endpoint-health data.

Operational TCR

8.9

Full-Telemetry TCR

9.6

Limitations

·        Direct API or driver-based destruction may not match when command and control telemetry are unavailable.

·        Interactive DiskPart use may not expose the entered commands in process telemetry.

·        Scripted DiskPart destruction is not identified by the process branch unless script-content or equivalent destructive classification is available.

·        Destructive activity may complete before isolation or response occurs.

·        Approved imaging, recovery, forensic, or storage-management workflows can resemble malicious activity.

·        Incomplete control-outcome data can prevent confirmed-event branches from matching.

·        Command-only matches indicate execution but may not prove completion.

·        Renamed utilities may evade branches that depend on the original process name unless equivalent executable classification is implemented.

·        Alerts without host.id or process.entity_id are not deduplicated through process-based alert suppression.

·        The rule does not guarantee recovery or independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support Windows process, DiskPart script-classification, disk, recovery, boot, backup, event-log, endpoint, control-outcome, and asset-context telemetry; destructive-command classification; confirmed control changes; branch-specific approved exceptions; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where

host.os.type == "windows" and

(

  (

    event.category == "process" and

    event.type == "start" and

    (

      ?exception.approved_destructive_admin_activity == null or

      ?exception.approved_destructive_admin_activity != true

    ) and

    (

      ?process.command_line : "*\\\\.\\PHYSICALDRIVE*" or

      (

        ?process.name : "diskpart.exe" and

        ?process.command_line : (

          "*/s *",

          "* /s *"

        ) and

        ?diskpart.script.destructive == true and

        ?diskpart.script.action in (

          "clean",

          "clean_all"

        )

      ) or

      (

        ?process.name : "wmic.exe" and

        ?process.command_line : (

          "*shadowcopy*delete*",

          "*shadowcopy delete"

        )

      ) or

      (

        ?process.name : "vssadmin.exe" and

        ?process.command_line : (

          "*delete*shadows*",

          "*delete shadows*"

        )

      ) or

      (

        ?process.name : "wbadmin.exe" and

        ?process.command_line : (

          "*delete*catalog*",

          "*delete catalog*"

        )

      ) or

      (

        ?process.name : "reagentc.exe" and

        ?process.command_line : (

          "*/disable*",

          "* /disable*"

        )

      ) or

      (

        ?process.name : "bcdedit.exe" and

        ?process.command_line : (

          "*/set *",

          "* /set *"

        ) and

        ?process.command_line : "*recoveryenabled*" and

        ?process.command_line : "* no*"

      ) or

      (

        ?process.name : "bcdedit.exe" and

        ?process.command_line : (

          "*/set *",

          "* /set *"

        ) and

        ?process.command_line : "*bootstatuspolicy*" and

        ?process.command_line : "*ignoreallfailures*"

      ) or

      (

        ?process.name : "wevtutil.exe" and

        ?process.command_line : (

          "* cl *",

          "* cl",

          "*cl *"

        )

      ) or

      (

        ?process.name : (

          "powershell.exe",

          "pwsh.exe"

        ) and

        ?process.command_line : "*Clear-EventLog*"

      )

    )

  ) or

  (

    event.category in (

      "configuration",

      "host",

      "process"

    ) and

    ?destructive_control.change.confirmed == true and

    (

      ?exception.approved_destructive_admin_activity == null or

      ?exception.approved_destructive_admin_activity != true

    ) and

    ?destructive_control.action in (

      "physical_drive_accessed",

      "disk_cleaned",

      "disk_partition_destroyed",

      "shadow_copies_deleted",

      "backup_catalog_deleted",

      "recovery_disabled",

      "boot_recovery_modified",

      "event_log_cleared"

    ) and

    ?destructive_control.outcome in (

      "confirmed",

      "success",

      "successful",

      "succeeded",

      "state_changed"

    )

  )

) and

(

  ?process.entity_id != null or

  ?process.pid != null or

  ?destructive_control.target != null

)

Rule

High-Volume Destructive File Rename or Deletion Activity

Rule Format

Elastic Security ES|QL aggregation rule using normalized Windows file and responsible-process telemetry, process identity, customer-maintained role-aware thresholds, affected-file cardinality, endpoint context, approved high-volume file-workflow exceptions, and endpoint-and-process alert suppression.

Detection Purpose

Detect a process performing a high volume of file rename or deletion activity across numerous distinct file paths within a five-minute period.

The rule identifies destructive file activity without depending on a particular extension, ransom note, wallpaper, executable filename, hash, encryption implementation, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to monitored Windows endpoints.

·        Match confirmed or successfully observed file rename and deletion events.

·        Require both endpoint identity and responsible-process identity.

·        Treat an absent approved-workflow value as unapproved rather than excluding the event.

·        Exclude validated backup, synchronization, encryption, migration, archiving, deployment, indexing, recovery, and security-testing workflows.

·        Enrich each event with customer-maintained event-count and distinct-path thresholds based on the normalized endpoint role.

·        Apply default standard-endpoint thresholds when no role-specific threshold exists.

·        Group matching events by endpoint, process entity, asset role, and the applied thresholds.

·        Require the aggregated event count and distinct affected-path count to meet the applicable thresholds.

·        Generate one alert for each qualifying endpoint and process group.

·        Preserve the aggregated time range, asset role, event count, distinct-path count, and applied thresholds in the alert result.

·        Suppress repeated alerts by endpoint and process identity for 60 minutes.

·        Use fixed initial severity and perform asset-based severity escalation through alert enrichment or a downstream workflow keyed to the retained host identifier.

Required Telemetry

·        Windows file rename and deletion telemetry

·        File path, name, extension, directory, and action

·        Responsible process name, executable, command line, hash, process entity identifier, process identifier, and parent-process context

·        User identity where available

·        Endpoint identifier, hostname, role, exposure class, and asset criticality

·        Event outcome

·        Mandatory host.id, monitored-asset classification, and normalized asset-role classification

·        Customer-maintained asset-role threshold enrichment policy

·        Approved high-volume file-workflow exception mapping

File entropy, write volume, backup state, recovery state, and endpoint-health telemetry improve confidence but are not required.

Engineering Implementation Instructions

·        Implement this detection as one Elastic Security ES|QL rule.

·        Replace ENV_WINDOWS_FILE_ACTIVITY_THRESHOLDS with a validated Elastic enrichment policy that maps the normalized asset role to minimum_file_events and minimum_distinct_paths.

·        Execute and validate the enrichment policy before enabling the detection rule.

·        Map the neutral implementation fields to the customer’s ECS and locally enriched fields.

·        Ensure exception.approved_high_volume_file_activity has a compatible mapping across every source index selected by the ES|QL query.

·        Use null-safe handling so an absent approved-workflow value does not suppress a legitimate event.

·        Require host.id, process.entity_id, asset.windows.monitored, and asset.role to be populated before an event contributes to the aggregation.

·        Group by host.id, process.entity_id, asset.role, minimum_file_events, and minimum_distinct_paths.

·        Do not substitute a process hash for process.entity_id.

·        Use default thresholds of 50 matching events and 20 distinct file paths when no role-specific threshold is returned.

·        Configure higher customer-validated thresholds in the enrichment policy for file servers, shared storage, backup systems, synchronization systems, deployment systems, indexing systems, and development platforms.

·        Maintain narrow approved-workflow mappings that include endpoint, user, process identity, affected path, action, and workflow context.

·        Do not suppress activity solely because the process is signed, the endpoint is a server, or the user is an administrator.

·        Configure the rule to run every five minutes with a customer-validated additional look-back allowance.

·        Configure alert suppression using host.id and process.entity_id for 60 minutes.

·        Assign a fixed initial severity of medium.

·        Enrich the generated alert by host.id or another retained endpoint identifier before applying asset-based severity escalation.

·        Escalate to high through alert enrichment or a downstream workflow when the endpoint is critical, identity-adjacent, administrative, operational-technology, backup, recovery, or other high-value infrastructure.

·        Present the result as high-volume destructive file activity, not confirmed ransomware or GigaWiper activity.

DRI Assessment

The rule detects high-volume destructive file behavior rather than fixed extensions, filenames, ransom artifacts, hashes, or encryption libraries. Process grouping, affected-path cardinality, role-aware threshold enrichment, endpoint context, null-safe exception handling, and approved-workflow exclusions provide strong variant resistance.

DRI

9.0

TCR Assessment

Operational confidence depends on complete file-event attribution, endpoint identity, process identity, path fidelity, file-action normalization, monitored-asset classification, asset-role enrichment, threshold enrichment, and approved-workflow tuning. Full-telemetry confidence improves with user context, extension diversity, directory diversity, entropy, write volume, backup state, recovery state, endpoint health, and centralized evidence retention.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Slow or selectively targeted file destruction may remain below the applicable threshold.

·        Activity divided among multiple process identities may evade individual process-group thresholds.

·        Events without host.id or process.entity_id do not contribute to the aggregation.

·        Incomplete file telemetry may undercount renames or deletions.

·        Backup, synchronization, encryption, migration, archiving, deployment, indexing, and recovery tools can produce similar volumes.

·        Incorrect or missing asset-role classification can apply an inappropriate threshold.

·        Missing or incorrect threshold-enrichment values can reduce sensitivity or increase noise.

·        Incompatible or unmapped exception fields across the selected source indices can prevent successful query execution.

·        Trusted or signed software may be abused.

·        Aggregated alerts do not retain every original source-event field.

·        User identity may not be retained in the aggregated alert unless the local implementation explicitly preserves or enriches it.

·        Asset-based severity escalation depends on successful post-alert endpoint enrichment.

·        Detection may occur after files have already been damaged.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support ES|QL detection rules; normalized Windows file and responsible-process telemetry; mandatory endpoint, monitored-asset, and asset-role classification; process identity; event-outcome normalization; customer-maintained role-aware threshold enrichment; approved high-volume file-workflow exceptions; and endpoint-and-process alert suppression. Customer-specific source indices, data streams, ECS mappings, enrichment policies, exception fields, and local enriched field names must be implemented locally.

FROM logs-*

| WHERE host.os.type == "windows"

  AND asset.windows.monitored == true

  AND event.category == "file"

  AND event.type IN ("change", "deletion")

  AND file.action IN ("renamed", "deleted")

  AND event.outcome IN ("success", "successful", "succeeded")

  AND host.id IS NOT NULL

  AND process.entity_id IS NOT NULL

  AND asset.role IS NOT NULL

  AND file.path IS NOT NULL

  AND COALESCE(exception.approved_high_volume_file_activity, false) != true

| ENRICH ENV_WINDOWS_FILE_ACTIVITY_THRESHOLDS

  ON asset.role

  WITH minimum_file_events, minimum_distinct_paths

| EVAL minimum_file_events = COALESCE(minimum_file_events, 50)

| EVAL minimum_distinct_paths = COALESCE(minimum_distinct_paths, 20)

| STATS

    first_seen = MIN(@timestamp),

    last_seen = MAX(@timestamp),

    file_event_count = COUNT(*),

    distinct_file_paths = COUNT_DISTINCT(file.path, 1000)

  BY host.id,

     process.entity_id,

     asset.role,

     minimum_file_events,

     minimum_distinct_paths

| WHERE file_event_count >= minimum_file_events

  AND distinct_file_paths >= minimum_distinct_paths

| KEEP

    first_seen,

    last_seen,

    host.id,

    process.entity_id,

    asset.role,

    file_event_count,

    distinct_file_paths,

    minimum_file_events,

    minimum_distinct_paths

QRadar

Detection Viability Assessment

QRadar can provide strong behavior-driven coverage for the GigaWiper backdoor-to-destruction model when Windows process, Registry, scheduled-task, disk, recovery, boot, backup, event-log, file, endpoint, and asset-context events are parsed into stable DSM properties and custom event properties.

Three rule opportunities survive validation:

·        Confirmed Windows persistence establishment through scheduled tasks or autorun Registry locations

·        Destructive disk, recovery, boot, backup, or evidence-degradation activity

·        High-volume destructive file rename or deletion activity

Each rule is independently deployable. No rule requires another CyberDax rule or offense to fire first. The implementation patterns use behavior-specific properties, complete approved-workflow exceptions, composite workflow keys, short search windows, and CRE conditions suited to the detected activity.

Rule

Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

Rule Format

QRadar AQL saved search and CRE rule using normalized Windows process, Registry, scheduled-task, endpoint, process-lineage, event-outcome, persistence-target, and composite approved-workflow properties.

Detection Purpose

Detect confirmed scheduled-task creation or modification, confirmed autorun Registry modification, or command execution that directly performs one of those persistence actions.

The rule identifies durable Windows persistence behavior without depending on a specific task name, Registry value name, payload filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows endpoints

·        Match schtasks.exe commands that create or modify scheduled tasks

·        Match PowerShell or PowerShell Core execution of Register-ScheduledTask

·        Match reg.exe commands that add supported autorun Registry values

·        Match PowerShell or PowerShell Core execution of Set-ItemProperty or New-ItemProperty against supported autorun Registry locations

·        Match confirmed scheduled-task creation, registration, or modification events

·        Match confirmed Registry value creation or modification in supported autorun locations

·        Require successful or confirmed outcomes for direct scheduled-task and Registry modification events

·        Preserve process identity, parent-process context, command line, user, task target, Registry target, endpoint role, exposure state, and asset criticality where available

·        Exclude activity only when a populated composite persistence-workflow key matches a complete customer-approved scheduled-task or Registry-persistence workflow

·        Generate one CRE offense contribution for each qualifying event

·        Use CRE response limiting by endpoint and process identity for 60 minutes where both properties are available

·        Do not suppress qualifying events solely because the endpoint, user, process, signer, or administrative tool is independently approved

Required Telemetry

·        Windows process-start events

·        Registry creation and modification events

·        Scheduled-task creation, registration, and modification events

·        Process name, path, command line, hash, process identifier, and process entity identifier

·        Parent-process name, path, command line, and identifier

·        User identity

·        Registry path, value name, task name, and task path

·        Event action and outcome

·        Endpoint identifier and hostname

·        Host operating system

·        Asset role, exposure state, and asset criticality where available

·        A normalized composite persistence-workflow key

·        Customer-maintained approved persistence-workflow key reference data

Engineering Implementation Instructions

·        Map all property names to parsed DSM fields or validated custom event properties in the target QRadar environment

·        Confirm that every selected and filtered property is populated by the intended Windows log sources

·        Create a normalized Approved Persistence Workflow Key custom property before deploying the saved search

·        Construct the key from the complete authorized workflow context available to the branch, including hostname, process identity or process name, user, normalized command or persistence target, action, and authorized change-window identifier

·        Use the same normalization and field order when generating customer-approved keys for the Approved_Windows_Persistence_Workflow_Keys reference set

·        Maintain separate authorized key entries for scheduled-task and Registry-persistence workflows where their required context differs

·        Treat a null, empty, incomplete, or unrecognized workflow key as unapproved

·        Do not replace the composite key with separate hostname, process, user, or signer allowlists

·        Do not broadly suppress PowerShell, schtasks.exe, reg.exe, administrative accounts, Microsoft-signed binaries, deployment systems, or remote-support tools

·        Require PowerShell persistence cmdlets to originate from powershell.exe or pwsh.exe

·        Configure the saved search to run over a ten-minute window

·        Configure the CRE rule to test qualifying events independently

·        Limit repeated rule responses by hostname and process identity for 60 minutes where both properties are available

·        Allow events without process identity to remain eligible for detection

·        Use asset role, exposure state, and asset criticality for offense magnitude or routing after the base behavior matches

·        Present command-only matches as command-observed persistence activity

·        Present confirmed scheduled-task or Registry events as confirmed persistence establishment

·        Do not present either branch as confirmed GigaWiper activity

DRI Assessment

The rule detects scheduled-task and autorun Registry persistence behavior rather than campaign-specific artifacts. Separate process and confirmed-event branches, persistence-target matching, process-name anchoring, process lineage, and complete composite approved-workflow validation provide strong resistance to filename, hash, task-name, and Registry-value changes while reducing the risk of suppressing malicious use of approved hosts, users, or tools.

DRI

9.0

TCR Assessment

Operational confidence depends on normalized process, Registry, scheduled-task, process-lineage, event-outcome, endpoint, persistence-target, and composite approved-workflow properties. Full-telemetry confidence improves with Registry value data, scheduled-task audit data, executable prevalence, user-session context, software inventory, asset role, exposure-state enrichment, and maintained authorized-workflow keys.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Direct API persistence may not match when responsible-process or target telemetry is unavailable

·        Command-observed branches may represent attempted activity when no corresponding modification event is collected

·        Obfuscated PowerShell or alternate persistence mechanisms may evade command-line matching

·        Renamed or copied PowerShell binaries may evade process-name anchoring unless equivalent executable classification is implemented

·        Incomplete DSM parsing or custom-property extraction can reduce coverage

·        Incorrectly normalized, stale, or overbroad composite workflow keys can suppress malicious activity

·        Events with null, empty, incomplete, or unmatched workflow keys remain eligible for detection and may require tuning

·        The rule does not independently establish GigaWiper attribution

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search and map all property names, reference sets, DSM fields, asset profiles, search intervals, composite workflow properties, and CRE offense conditions to the target QRadar environment before deployment.

SELECT
"starttime" AS event_time,
"Hostname" AS host,
"Username" AS user_name,
"Process Entity ID" AS process_entity_id,
"Process ID" AS process_id,
"Process Name" AS process_name,
"Process Path" AS process_path,
"Process Command Line" AS process_command_line,
"Parent Process Name" AS parent_process_name,
"Parent Process Path" AS parent_process_path,
"Parent Process Command Line" AS parent_process_command_line,
"Event Action" AS event_action,
"Event Outcome" AS event_outcome,
"Scheduled Task Name" AS scheduled_task_name,
"Scheduled Task Path" AS scheduled_task_path,
"Registry Path" AS registry_path,
"Registry Value Name" AS registry_value_name,
"Approved Persistence Workflow Key" AS approved_persistence_workflow_key,
"Asset Role" AS asset_role,
"Exposure State" AS exposure_state,
"Asset Criticality" AS asset_criticality
FROM events
WHERE
"Host OS" ILIKE '%windows%'
AND (
(
"Process Name" ILIKE '%schtasks.exe%'
AND (
"Process Command Line" ILIKE '%/create%'
OR "Process Command Line" ILIKE '%/change%'
)
)
OR (
(
"Process Name" ILIKE '%powershell.exe%'
OR "Process Name" ILIKE '%pwsh.exe%'
)
AND "Process Command Line" ILIKE '%Register-ScheduledTask%'
)
OR (
"Process Name" ILIKE '%reg.exe%'
AND "Process Command Line" ILIKE '% add %'
AND (
"Process Command Line" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\Run%'
OR "Process Command Line" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\RunOnce%'
OR "Process Command Line" ILIKE '%\Software\Microsoft\Windows NT\CurrentVersion\Windows%'
)
)
OR (
(
"Process Name" ILIKE '%powershell.exe%'
OR "Process Name" ILIKE '%pwsh.exe%'
)
AND (
"Process Command Line" ILIKE '%Set-ItemProperty%'
OR "Process Command Line" ILIKE '%New-ItemProperty%'
)
AND (
"Process Command Line" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\Run%'
OR "Process Command Line" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\RunOnce%'
OR "Process Command Line" ILIKE '%\Software\Microsoft\Windows NT\CurrentVersion\Windows%'
)
)
OR (
"Scheduled Task Change Confirmed" = 'true'
AND "Scheduled Task Action" IN (
'task_created',
'task_registered',
'task_modified',
'scheduled_task_created',
'scheduled_task_registered',
'scheduled_task_modified'
)
AND "Event Outcome" IN (
'success',
'successful',
'succeeded'
)
)
OR (
"Registry Change Confirmed" = 'true'
AND "Registry Action" IN (
'registry_value_created',
'registry_value_set',
'registry_value_modified',
'registry_key_created',
'registry_modified'
)
AND "Event Outcome" IN (
'success',
'successful',
'succeeded'
)
AND (
"Registry Path" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\Run%'
OR "Registry Path" ILIKE '%\Software\Microsoft\Windows\CurrentVersion\RunOnce%'
OR "Registry Path" ILIKE '%\Software\Microsoft\Windows NT\CurrentVersion\Windows%'
)
)
)
AND (
"Approved Persistence Workflow Key" IS NULL
OR "Approved Persistence Workflow Key" = ''
OR NOT REFERENCESETCONTAINS(
'Approved_Windows_Persistence_Workflow_Keys',
"Approved Persistence Workflow Key"
)
)
LAST 10 MINUTES

Rule

Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

Rule Format

QRadar AQL saved search and CRE rule using normalized Windows process, DiskPart script classification, disk, recovery, boot, backup, event-log, control-outcome, endpoint, asset-context, and composite approved-workflow properties.

Detection Purpose

Detect physical-drive access, confirmed destructive DiskPart script execution, recovery disablement, shadow-copy or backup-catalog deletion, destructive boot-configuration modification, and confirmed Windows event-log clearing.

The rule identifies destructive administration and wiper-enabling behavior without depending on a specific disk number, script filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to Windows endpoints

·        Match command lines that reference physical-drive device paths

·        Match diskpart.exe /s only when script-content classification confirms clean or clean all

·        Treat unclassified diskpart.exe /s execution as suspicious staging that does not independently satisfy this destructive rule

·        Match confirmed disk cleaning or partition destruction events

·        Match wmic.exe shadow-copy deletion

·        Match vssadmin.exe shadow-copy deletion

·        Match wbadmin.exe backup-catalog deletion

·        Match reagentc.exe /disable

·        Match bcdedit.exe /set changes that disable recovery or configure IgnoreAllFailures

·        Match PowerShell or PowerShell Core execution of Clear-EventLog

·        Match wevtutil.exe cl event-log clearing

·        Match confirmed recovery, boot, backup, shadow-copy, disk, partition, or event-log state changes

·        Require successful or confirmed outcomes for direct control events

·        Preserve process identity, parent-process context, command line, user, destructive target, action, endpoint role, exposure state, and asset criticality where available

·        Exclude activity only when a populated composite destructive-administration workflow key matches a complete customer-approved workflow

·        Generate one CRE offense contribution for each qualifying destructive event

·        Limit repeated rule responses by hostname and process identity for 60 minutes where both properties are available

·        Use asset context for offense magnitude and routing rather than as a detection prerequisite

Required Telemetry

·        Windows process-start events

·        DiskPart script-content classification where the DiskPart process branch is enabled

·        Disk and partition control events where available

·        Recovery and boot-configuration events

·        Backup, shadow-copy, and catalog events

·        Windows event-log clearing events

·        Process name, path, command line, hash, process identifier, and process entity identifier

·        Parent-process context

·        User identity

·        Target device, disk, volume, boot setting, recovery setting, backup object, shadow-copy object, or event log

·        Event action and outcome

·        Endpoint identifier and hostname

·        Host operating system

·        Asset role, exposure state, and asset criticality where available

·        A normalized composite destructive-administration workflow key

·        Customer-maintained approved destructive-administration workflow key reference data

Engineering Implementation Instructions

·        Map all property names to parsed DSM fields or validated custom event properties in the target QRadar environment

·        Confirm that destructive control actions and outcomes represent actual state changes rather than requested actions

·        Do not search the diskpart.exe command line for clean or clean all

·        Match diskpart.exe /s only when QRadar receives an associated script-content or destructive-script classification property

·        Treat confirmed disk-clean or partition-destruction control events as authoritative

·        Require /set in bcdedit.exe command branches

·        Require Clear-EventLog to originate from powershell.exe or pwsh.exe

·        Create a normalized Approved Destructive Workflow Key custom property before deploying the saved search

·        Construct the key from the complete authorized workflow context, including hostname, process identity or process name, user, normalized command or destructive target, destructive action, and authorized change-window identifier

·        Use the same normalization and field order when generating customer-approved keys for the Approved_Destructive_Admin_Workflow_Keys reference set

·        Treat a null, empty, incomplete, or unrecognized workflow key as unapproved

·        Do not replace the composite key with separate hostname, process, user, signer, or utility allowlists

·        Do not broadly suppress signed utilities, administrative users, Microsoft tools, imaging systems, recovery systems, forensic systems, or security-testing platforms

·        Configure the saved search to run over a ten-minute window

·        Configure the CRE rule to test qualifying events independently

·        Limit repeated rule responses by hostname and process identity for 60 minutes where both properties are available

·        Allow events without process identity to remain eligible for detection

·        Apply high or critical offense magnitude when the endpoint is critical, identity-adjacent, administrative, operational-technology, backup, recovery, or other high-value infrastructure

·        Present command matches as destructive command execution

·        Present confirmed control events as confirmed destructive state changes

·        Do not present either branch as confirmed GigaWiper activity

DRI Assessment

The rule detects durable destructive-administration and wiper-enabling behavior across command, classified DiskPart-script, and confirmed-control branches. It remains effective against changed disk numbers, altered script names, and malware-family changes when the destructive command, script classification, or resulting state change remains observable. Composite approved-workflow validation prevents an approved host, user, or utility from independently suppressing an otherwise qualifying destructive event.

DRI

9.2

TCR Assessment

Operational confidence depends on complete process command-line, process-lineage, destructive-command, DiskPart script-classification, control-event, event-outcome, endpoint, target, and composite approved-workflow properties. Full-telemetry confidence improves with raw-device, disk-control, boot-state, recovery, backup, event-log, script-content, endpoint-health, asset-context, and maintained authorized-workflow data.

Operational TCR

8.9

Full-Telemetry TCR

9.6

Limitations

·        Direct API or driver-based destruction may not match when process and control telemetry are unavailable

·        Interactive DiskPart commands may not appear in process telemetry

·        Scripted DiskPart destruction is not identified by the process branch without script-content classification

·        Destructive activity may complete before an offense is reviewed or response occurs

·        Approved imaging, recovery, forensic, or storage-management workflows can resemble malicious activity

·        Incomplete DSM parsing or custom-property extraction can reduce coverage

·        Command matches indicate execution but may not prove completion

·        Renamed utilities may evade process-name-dependent branches

·        Incorrectly normalized, stale, or overbroad composite workflow keys can suppress malicious activity

·        Events with null, empty, incomplete, or unmatched workflow keys remain eligible for detection and may require tuning

·        The rule does not guarantee recovery or independently establish GigaWiper attribution

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search and map all property names, reference sets, DSM fields, asset profiles, search intervals, composite workflow properties, and CRE offense conditions to the target QRadar environment before deployment.

SELECT
"starttime" AS event_time,
"Hostname" AS host,
"Username" AS user_name,
"Process Entity ID" AS process_entity_id,
"Process ID" AS process_id,
"Process Name" AS process_name,
"Process Path" AS process_path,
"Process Command Line" AS process_command_line,
"Parent Process Name" AS parent_process_name,
"Parent Process Path" AS parent_process_path,
"Parent Process Command Line" AS parent_process_command_line,
"DiskPart Script Action" AS diskpart_script_action,
"Destructive Control Action" AS destructive_control_action,
"Destructive Control Target" AS destructive_control_target,
"Event Action" AS event_action,
"Event Outcome" AS event_outcome,
"Approved Destructive Workflow Key" AS approved_destructive_workflow_key,
"Asset Role" AS asset_role,
"Exposure State" AS exposure_state,
"Asset Criticality" AS asset_criticality
FROM events
WHERE
"Host OS" ILIKE '%windows%'
AND (
"Process Command Line" ILIKE '%\\.\PHYSICALDRIVE%'
OR (
"Process Name" ILIKE '%diskpart.exe%'
AND "Process Command Line" ILIKE '%/s %'
AND "DiskPart Script Destructive" = 'true'
AND "DiskPart Script Action" IN (
'clean',
'clean_all'
)
)
OR (
"Process Name" ILIKE '%wmic.exe%'
AND "Process Command Line" ILIKE '%shadowcopy%'
AND "Process Command Line" ILIKE '%delete%'
)
OR (
"Process Name" ILIKE '%vssadmin.exe%'
AND "Process Command Line" ILIKE '%delete%'
AND "Process Command Line" ILIKE '%shadows%'
)
OR (
"Process Name" ILIKE '%wbadmin.exe%'
AND "Process Command Line" ILIKE '%delete%'
AND "Process Command Line" ILIKE '%catalog%'
)
OR (
"Process Name" ILIKE '%reagentc.exe%'
AND "Process Command Line" ILIKE '%/disable%'
)
OR (
"Process Name" ILIKE '%bcdedit.exe%'
AND "Process Command Line" ILIKE '%/set%'
AND "Process Command Line" ILIKE '%recoveryenabled%'
AND "Process Command Line" ILIKE '% no%'
)
OR (
"Process Name" ILIKE '%bcdedit.exe%'
AND "Process Command Line" ILIKE '%/set%'
AND "Process Command Line" ILIKE '%bootstatuspolicy%'
AND "Process Command Line" ILIKE '%ignoreallfailures%'
)
OR (
"Process Name" ILIKE '%wevtutil.exe%'
AND "Process Command Line" ILIKE '% cl %'
)
OR (
(
"Process Name" ILIKE '%powershell.exe%'
OR "Process Name" ILIKE '%pwsh.exe%'
)
AND "Process Command Line" ILIKE '%Clear-EventLog%'
)
OR (
"Destructive Control Change Confirmed" = 'true'
AND "Destructive Control Action" IN (
'physical_drive_accessed',
'disk_cleaned',
'disk_partition_destroyed',
'shadow_copies_deleted',
'backup_catalog_deleted',
'recovery_disabled',
'boot_recovery_modified',
'event_log_cleared'
)
AND "Event Outcome" IN (
'confirmed',
'success',
'successful',
'succeeded',
'state_changed'
)
)
)
AND (
"Approved Destructive Workflow Key" IS NULL
OR "Approved Destructive Workflow Key" = ''
OR NOT REFERENCESETCONTAINS(
'Approved_Destructive_Admin_Workflow_Keys',
"Approved Destructive Workflow Key"
)
)
LAST 10 MINUTES

Rule

High-Volume Destructive File Rename or Deletion Activity

Rule Format

QRadar AQL aggregate saved search and CRE rule using normalized Windows file and responsible-process events, endpoint identity, process identity, affected-path cardinality, asset context, and composite approved high-volume file-workflow properties.

Detection Purpose

Detect a process performing a high volume of file rename or deletion activity across numerous distinct file paths within a five-minute period.

The rule identifies destructive file activity without depending on a specific extension, ransom note, wallpaper, executable filename, hash, encryption implementation, malware family, or campaign identifier.

Detection Logic

·        Scope the rule to monitored Windows endpoints

·        Match successfully observed file rename and deletion events

·        Require endpoint identity, responsible-process identity, and file path

·        Exclude activity only when a populated composite file-workflow key matches a complete customer-approved backup, synchronization, encryption, migration, archiving, deployment, indexing, recovery, or security-testing workflow

·        Group events by endpoint, process entity, process name, and asset role

·        Require at least 50 matching file events within five minutes

·        Require at least 20 distinct affected file paths

·        Generate one aggregate search result for each qualifying endpoint and process group

·        Use the saved-search result or corresponding CRE building block to create an offense contribution

·        Limit repeated rule responses by hostname and process identity for 60 minutes

·        Use asset role, exposure state, and asset criticality for offense magnitude and routing after the base threshold is met

Required Telemetry

·        Windows file rename and deletion events

·        File path, name, extension, directory, and action

·        Responsible process name, path, command line, hash, process identifier, and process entity identifier

·        Parent-process context

·        User identity where available

·        Endpoint identifier and hostname

·        Host operating system

·        Asset role, exposure state, and asset criticality

·        Event outcome

·        Monitored Windows asset reference data

·        A normalized composite high-volume file-workflow key

·        Customer-maintained approved high-volume file-workflow key reference data

File entropy, write volume, backup state, recovery state, and endpoint-health telemetry improve confidence but are not required.

Engineering Implementation Instructions

·        Map all property names to parsed DSM fields or validated custom event properties in the target QRadar environment

·        Require hostname, process entity identifier, file path, asset role, and successful event outcome before an event contributes to aggregation

·        Use COUNT(*) for total qualifying file events

·        Use UNIQUECOUNT("File Path") for affected-path cardinality

·        Group by hostname, process entity identifier, process name, and asset role

·        Set the event threshold to 50 and the distinct-path threshold to 20 over five minutes

·        Validate thresholds against the customer’s file-server, backup, synchronization, deployment, indexing, development, and endpoint activity

·        Create a normalized Approved High-Volume File Workflow Key custom property before deploying the saved search

·        Construct the key from the complete authorized workflow context, including hostname, process identity or process name, user where available, normalized target path or approved path scope, file action, workflow identifier, and authorized time-window identifier

·        Use the same normalization and field order when generating customer-approved keys for the Approved_High_Volume_File_Workflow_Keys reference set

·        Treat a null, empty, incomplete, or unrecognized workflow key as unapproved

·        Do not replace the composite key with separate hostname, process, user, signer, server-role, or utility allowlists

·        Do not suppress activity solely because a process is signed, the endpoint is a server, or the user is an administrator

·        Require monitored Windows endpoints to appear in the applicable asset reference set

·        Configure the aggregate saved search to run over a five-minute window

·        Configure the CRE response or offense rule to limit repeated responses by hostname and process identity for 60 minutes

·        Assign a moderate initial offense magnitude

·        Escalate offense magnitude when the affected endpoint is critical, identity-adjacent, administrative, operational-technology, backup, recovery, or other high-value infrastructure

·        Present the result as high-volume destructive file activity, not confirmed ransomware or GigaWiper activity

DRI Assessment

The rule detects high-volume destructive file behavior rather than fixed extensions, filenames, ransom artifacts, hashes, or encryption libraries. Process grouping, affected-path cardinality, endpoint context, and complete composite approved-workflow validation provide strong variant resistance while preventing an approved host, user, or process from independently suppressing qualifying destructive file activity.

DRI

9.0

TCR Assessment

Operational confidence depends on complete file-event attribution, endpoint identity, process identity, path fidelity, file-action normalization, asset-role mapping, and composite approved-workflow tuning. Full-telemetry confidence improves with user context, extension diversity, directory diversity, entropy, write volume, backup state, recovery state, endpoint health, centralized evidence retention, and maintained authorized-workflow keys.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Slow or selectively targeted file destruction may remain below the threshold

·        Activity divided among multiple process identities may evade individual process-group thresholds

·        Events without endpoint identity, process identity, or file path do not contribute to aggregation

·        Incomplete file telemetry may undercount renames or deletions

·        Backup, synchronization, encryption, migration, archiving, deployment, indexing, and recovery tools can produce similar volumes

·        Incorrectly normalized, stale, or overbroad composite workflow keys can suppress malicious activity

·        Events with null, empty, incomplete, or unmatched workflow keys remain eligible for detection and may require tuning

·        Trusted or signed software may be abused

·        Aggregated results do not retain every original event property

·        Detection may occur after files have already been damaged

·        The rule does not independently establish GigaWiper attribution

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL aggregate search and map all property names, reference sets, DSM fields, asset profiles, search intervals, aggregation thresholds, composite workflow properties, and CRE offense conditions to the target QRadar environment before deployment.

SELECT
"Hostname" AS host,
"Process Entity ID" AS process_entity_id,
FIRST("Process Name") AS process_name,
FIRST("Process Path") AS process_path,
FIRST("Process Command Line") AS process_command_line,
FIRST("Username") AS user_name,
FIRST("Approved High-Volume File Workflow Key") AS approved_file_workflow_key,
FIRST("Asset Role") AS asset_role,
FIRST("Exposure State") AS exposure_state,
FIRST("Asset Criticality") AS asset_criticality,
MIN("starttime") AS first_seen,
MAX("starttime") AS last_seen,
COUNT(*) AS file_event_count,
UNIQUECOUNT("File Path") AS distinct_file_paths
FROM events
WHERE
"Host OS" ILIKE '%windows%'
AND "Hostname" IS NOT NULL
AND "Process Entity ID" IS NOT NULL
AND "File Path" IS NOT NULL
AND "Asset Role" IS NOT NULL
AND "File Action" IN (
'renamed',
'deleted'
)
AND "Event Outcome" IN (
'success',
'successful',
'succeeded'
)
AND REFERENCESETCONTAINS(
'Monitored_Windows_Endpoints',
"Hostname"
)
AND (
"Approved High-Volume File Workflow Key" IS NULL
OR "Approved High-Volume File Workflow Key" = ''
OR NOT REFERENCESETCONTAINS(
'Approved_High_Volume_File_Workflow_Keys',
"Approved High-Volume File Workflow Key"
)
)
GROUP BY
"Hostname",
"Process Entity ID",
"Process Name",
"Asset Role"
HAVING
"file_event_count" >= 50
AND "distinct_file_paths" >= 20
LAST 5 MINUTES

Sigma

Detection Viability Assessment

Sigma can provide strong behavior-driven coverage for the GigaWiper backdoor-to-destruction model when normalized Windows process, Registry, scheduled-task, disk, recovery, boot, backup, event-log, file, endpoint, and locally enriched asset-context telemetry are available.

Three rule opportunities survive validation:

·        Confirmed Windows persistence establishment through scheduled tasks or autorun Registry locations

·        Destructive disk, recovery, boot, backup, or evidence-degradation activity

·        High-volume destructive file rename or deletion activity

Each rule is independently deployable. No rule depends on another CyberDax alert or detection output. The first two opportunities use Sigma event rules. The high-volume file-activity opportunity uses a Sigma distinct-value correlation package because affected-path cardinality cannot be expressed as a standard single-event selection.

Rule

Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

Rule Format

Sigma event rule using normalized Windows process, Registry, scheduled-task, event-outcome, endpoint, process-lineage, persistence-target, and approved-workflow enrichment fields.

Detection Purpose

Detect confirmed scheduled-task creation or modification, confirmed autorun Registry modification, or command execution that directly performs one of those persistence actions.

The rule identifies durable Windows persistence behavior without depending on a specific task name, Registry value name, payload filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Match schtasks.exe execution that creates or modifies a scheduled task.

·        Match PowerShell or PowerShell Core execution of Register-ScheduledTask.

·        Match reg.exe execution that adds a value under supported autorun Registry locations.

·        Match PowerShell or PowerShell Core execution of Set-ItemProperty or New-ItemProperty against supported autorun Registry locations.

·        Match confirmed scheduled-task creation, registration, or modification events.

·        Match confirmed Registry creation or modification events affecting supported autorun locations.

·        Require successful outcomes for confirmed scheduled-task and Registry modification branches.

·        Exclude only events marked as complete approved persistence workflows.

·        Retain events without approved-workflow enrichment as eligible matches.

·        Preserve process, parent-process, user, task, Registry target, endpoint, and asset context where available.

·        Present command-observed matches as persistence-command execution.

·        Present confirmed scheduled-task or Registry events as confirmed persistence establishment.

·        Do not present either branch as confirmed GigaWiper activity.

Required Telemetry

·        Windows process-creation events

·        Registry creation and modification events

·        Scheduled-task creation, registration, and modification events

·        Process image, command line, process identifier, and stable process identity where available

·        Parent-process image and command line

·        User identity

·        Scheduled-task action, name, and path

·        Registry action, target path, and value name

·        Event outcome

·        Endpoint identifier and hostname

·        Asset role and asset criticality where available

·        Approved persistence-workflow enrichment

Engineering Implementation Instructions

·        Map all generic and local enrichment fields to the target SIEM or EDR before deployment.

·        Confirm that the selected Sigma backend preserves the Boolean selection structure and field modifiers.

·        Remove or remap selections whose required telemetry is unavailable.

·        Require ApprovedPersistenceWorkflow to represent a complete approved activity context.

·        Do not broadly exclude PowerShell, schtasks.exe, reg.exe, administrative users, Microsoft-signed binaries, deployment platforms, or remote-support tools.

·        Require PowerShell persistence cmdlets to originate from powershell.exe or pwsh.exe.

·        Preserve events without approved-workflow enrichment as eligible matches.

·        Apply endpoint role and asset criticality after the base detection matches.

·        Validate command-line casing, path normalization, and local field naming through the selected backend.

·        Treat command-line matches as observed execution rather than proof that the requested persistence action succeeded.

·        Require reliable action and outcome normalization before enabling confirmed-event selections.

DRI Assessment

The rule detects scheduled-task and autorun Registry persistence behavior rather than campaign-specific artifacts. Separate process and confirmed-event selections, process anchoring, persistence-target matching, and complete-workflow filtering provide strong resistance to filename, hash, task-name, and Registry-value changes.

DRI

8.9

TCR Assessment

Operational confidence depends on normalized process, Registry, scheduled-task, event-outcome, endpoint, and approved-workflow telemetry. Full-telemetry confidence improves with process lineage, Registry value data, task audit data, user-session context, executable prevalence, software inventory, and asset enrichment.

Operational TCR

8.7

Full-Telemetry TCR

9.3

Limitations

·        Direct API persistence may not match when responsible-process or target telemetry is unavailable.

·        Command-observed branches may represent attempted activity.

·        Obfuscated PowerShell or alternate persistence mechanisms may evade command-line matching.

·        Renamed or copied PowerShell binaries may evade process-name anchoring unless equivalent executable classification is implemented.

·        Missing scheduled-task or Registry modification telemetry can reduce coverage.

·        A generic Windows log source must resolve to every data source required by the enabled selections.

·        Overbroad approved-workflow enrichment can suppress malicious activity.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM or EDR before deployment.

title: Confirmed Windows Scheduled Task

id: c4a2f6d8-8e17-4b34-9a65-1f7c2d8e4001

status: test

description: Detects command-observed or confirmed Windows persistence through scheduled tasks or supported autorun Registry locations.

references:

  - Internal CyberDax detection model for GigaWiper backdoor-to-destruction behavior

author: CyberDax

date: 2026-07-12

logsource:

  product: windows

  definition: Requires normalized process-creation, Registry modification, or scheduled-task modification telemetry.

detection:

  selection_schtasks:

    Image|endswith: '\schtasks.exe'

    CommandLine|contains:

      - '/create'

      - '/change'

  selection_powershell_scheduled_task:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains: 'Register-ScheduledTask'

  selection_reg_command_run:

    Image|endswith: '\reg.exe'

    CommandLine|contains|all:

      - ' add '

      - '\Software\Microsoft\Windows\CurrentVersion\Run'

  selection_reg_command_runonce:

    Image|endswith: '\reg.exe'

    CommandLine|contains|all:

      - ' add '

      - '\Software\Microsoft\Windows\CurrentVersion\RunOnce'

  selection_reg_command_windows:

    Image|endswith: '\reg.exe'

    CommandLine|contains|all:

      - ' add '

      - '\Software\Microsoft\Windows NT\CurrentVersion\Windows'

  selection_powershell_set_registry_run:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'Set-ItemProperty'

      - '\Software\Microsoft\Windows\CurrentVersion\Run'

  selection_powershell_new_registry_run:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'New-ItemProperty'

      - '\Software\Microsoft\Windows\CurrentVersion\Run'

  selection_powershell_set_registry_runonce:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'Set-ItemProperty'

      - '\Software\Microsoft\Windows\CurrentVersion\RunOnce'

  selection_powershell_new_registry_runonce:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'New-ItemProperty'

      - '\Software\Microsoft\Windows\CurrentVersion\RunOnce'

  selection_powershell_set_registry_windows:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'Set-ItemProperty'

      - '\Software\Microsoft\Windows NT\CurrentVersion\Windows'

  selection_powershell_new_registry_windows:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains|all:

      - 'New-ItemProperty'

      - '\Software\Microsoft\Windows NT\CurrentVersion\Windows'

  selection_confirmed_task:

    ScheduledTaskChangeConfirmed: true

    ScheduledTaskAction:

      - 'task_created'

      - 'task_registered'

      - 'task_modified'

      - 'scheduled_task_created'

      - 'scheduled_task_registered'

      - 'scheduled_task_modified'

    EventOutcome:

      - 'success'

      - 'successful'

      - 'succeeded'

  selection_confirmed_registry:

    RegistryChangeConfirmed: true

    RegistryAction:

      - 'registry_value_created'

      - 'registry_value_set'

      - 'registry_value_modified'

      - 'registry_key_created'

      - 'registry_modified'

    EventOutcome:

      - 'success'

      - 'successful'

      - 'succeeded'

    TargetObject|contains:

      - '\Software\Microsoft\Windows\CurrentVersion\Run'

      - '\Software\Microsoft\Windows\CurrentVersion\RunOnce'

      - '\Software\Microsoft\Windows NT\CurrentVersion\Windows'

  filter_approved_workflow:

    ApprovedPersistenceWorkflow: true

  condition: 1 of selection_* and not filter_approved_workflow

fields:

  - UtcTime

  - Computer

  - User

  - Image

  - CommandLine

  - ParentImage

  - ParentCommandLine

  - ProcessId

  - ProcessGuid

  - ScheduledTaskAction

  - ScheduledTaskName

  - ScheduledTaskPath

  - RegistryAction

  - TargetObject

  - Details

  - EventOutcome

  - AssetRole

  - AssetCriticality

falsepositives:

  - Approved scheduled-task administration

  - Approved software deployment

  - Approved autorun Registry administration

  - Approved remote-support activity

level: high

tags:

  - attack.persistence

  - attack.t1053.005

  - attack.t1547.001

Rule

Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

Rule Format

Sigma event rule using normalized Windows process, destructive-script classification, disk, recovery, boot, backup, event-log, state-change, endpoint, and approved-workflow enrichment fields.

Detection Purpose

Detect physical-drive access, classified destructive DiskPart script execution, recovery disablement, shadow-copy or backup-catalog deletion, destructive boot-configuration modification, event-log clearing, or confirmed destructive state changes.

The rule identifies destructive administration and wiper-enabling behavior without depending on a specific disk number, script filename, executable hash, malware family, or campaign identifier.

Detection Logic

·        Match command lines that reference physical-drive device paths.

·        Match diskpart.exe /s only when local script-content classification confirms clean or clean all.

·        Do not treat unclassified diskpart.exe /s execution as confirmed destructive activity.

·        Match wmic.exe shadow-copy deletion.

·        Match vssadmin.exe shadow-copy deletion.

·        Match wbadmin.exe backup-catalog deletion.

·        Match reagentc.exe /disable.

·        Match bcdedit.exe /set changes that disable recovery.

·        Match bcdedit.exe /set changes that configure IgnoreAllFailures.

·        Match PowerShell or PowerShell Core execution of Clear-EventLog.

·        Match wevtutil.exe cl event-log clearing.

·        Match confirmed disk, partition, shadow-copy, backup-catalog, recovery, boot, or event-log state changes.

·        Require successful or confirmed outcomes for confirmed-control selections.

·        Exclude only events marked as complete approved destructive-administration workflows.

·        Retain events without approved-workflow enrichment as eligible matches.

·        Apply asset role and asset criticality after the base detection matches.

·        Present command matches as destructive command execution.

·        Present confirmed control matches as confirmed destructive state changes.

·        Do not present either branch as confirmed GigaWiper activity.

Required Telemetry

·        Windows process-creation events

·        Process image, command line, process identifier, and stable process identity where available

·        Parent-process context

·        DiskPart script-content classification where that selection is enabled

·        Disk and partition state-change telemetry where available

·        Recovery and boot-configuration telemetry

·        Shadow-copy and backup-catalog telemetry

·        Event-log clearing telemetry

·        Event action, target, and outcome

·        Endpoint identity and hostname

·        Asset role and asset criticality where available

·        Approved destructive-administration workflow enrichment

Engineering Implementation Instructions

·        Map all generic and local enrichment fields to the target SIEM or EDR before deployment.

·        Confirm that the selected Sigma backend preserves field modifiers and Boolean conditions.

·        Disable or remap selections whose custom telemetry is unavailable.

·        Require DiskPartScriptDestructive and DiskPartScriptAction to derive from validated script-content or equivalent destructive-script classification.

·        Do not classify diskpart.exe /s as destructive based on /s alone.

·        Require ApprovedDestructiveAdminWorkflow to represent a complete approved workflow.

·        Do not broadly exclude signed utilities, administrative users, Microsoft tools, imaging systems, recovery platforms, forensic tools, or security-testing platforms.

·        Require /set in the bcdedit.exe selections.

·        Require Clear-EventLog to originate from powershell.exe or pwsh.exe.

·        Retain events without approved-workflow enrichment as eligible matches.

·        Apply asset criticality and endpoint role after the base behavior matches.

·        Treat command-line observations as execution evidence rather than proof of successful completion.

·        Enable confirmed-control selections only when action and outcome fields represent validated state changes.

·        Implement equivalent executable classification where coverage for renamed native utilities is required.

DRI Assessment

The rule detects durable destructive-administration and wiper-enabling behavior across command, classified DiskPart-script, and confirmed-control selections. It resists changes to disk numbers, script filenames, executable hashes, and campaign labels when the underlying destructive behavior remains observable.

DRI

9.1

TCR Assessment

Operational confidence depends on process command lines, destructive-script classification, state-change actions, event outcomes, endpoint identity, and approved-workflow enrichment. Full-telemetry confidence improves with raw-device, disk-control, boot, recovery, backup, event-log, process-lineage, and endpoint-health data.

Operational TCR

8.8

Full-Telemetry TCR

9.5

Limitations

·        Direct API or driver-based destruction may not match when process and control telemetry are unavailable.

·        Interactive DiskPart commands may not appear in process telemetry.

·        Scripted DiskPart destruction is not identified without script-content or equivalent classification.

·        Destructive activity may complete before investigation or containment.

·        Legitimate imaging, recovery, forensic, backup, and storage-management activity can resemble malicious behavior.

·        Command matches do not prove completion.

·        Incomplete custom-field classification can reduce coverage.

·        Renamed native utilities may evade process-name-dependent selections.

·        Overbroad approved-workflow enrichment can suppress malicious activity.

·        The rule does not guarantee recovery or independently establish GigaWiper attribution.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM or EDR before deployment.

title: Destructive Windows Disk Recovery Backup or Evidence Degradation

id: c4a2f6d8-8e17-4b34-9a65-1f7c2d8e4002

status: test

description: Detects destructive Windows commands, classified DiskPart scripts, or confirmed state changes affecting disks, recovery, backups, boot configuration, or event logs.

references:

  - Internal CyberDax detection model for GigaWiper backdoor-to-destruction behavior

author: CyberDax

date: 2026-07-12

logsource:

  product: windows

  definition: Requires normalized Windows process-creation or destructive state-change telemetry.

detection:

  selection_physical_drive:

    CommandLine|contains: '\\.\PHYSICALDRIVE'

  selection_diskpart_script:

    Image|endswith: '\diskpart.exe'

    CommandLine|contains: '/s '

    DiskPartScriptDestructive: true

    DiskPartScriptAction:

      - 'clean'

      - 'clean_all'

  selection_wmic_shadow_delete:

    Image|endswith: '\wmic.exe'

    CommandLine|contains|all:

      - 'shadowcopy'

      - 'delete'

  selection_vssadmin_shadow_delete:

    Image|endswith: '\vssadmin.exe'

    CommandLine|contains|all:

      - 'delete'

      - 'shadows'

  selection_wbadmin_catalog_delete:

    Image|endswith: '\wbadmin.exe'

    CommandLine|contains|all:

      - 'delete'

      - 'catalog'

  selection_recovery_disable:

    Image|endswith: '\reagentc.exe'

    CommandLine|contains: '/disable'

  selection_bcd_recovery_disable:

    Image|endswith: '\bcdedit.exe'

    CommandLine|contains|all:

      - '/set'

      - 'recoveryenabled'

      - ' no'

  selection_bcd_ignore_failures:

    Image|endswith: '\bcdedit.exe'

    CommandLine|contains|all:

      - '/set'

      - 'bootstatuspolicy'

      - 'ignoreallfailures'

  selection_wevtutil_clear:

    Image|endswith: '\wevtutil.exe'

    CommandLine|contains: ' cl '

  selection_powershell_clear:

    Image|endswith:

      - '\powershell.exe'

      - '\pwsh.exe'

    CommandLine|contains: 'Clear-EventLog'

  selection_confirmed_control:

    DestructiveControlChangeConfirmed: true

    DestructiveControlAction:

      - 'physical_drive_accessed'

      - 'disk_cleaned'

      - 'disk_partition_destroyed'

      - 'shadow_copies_deleted'

      - 'backup_catalog_deleted'

      - 'recovery_disabled'

      - 'boot_recovery_modified'

      - 'event_log_cleared'

    EventOutcome:

      - 'confirmed'

      - 'success'

      - 'successful'

      - 'succeeded'

      - 'state_changed'

  filter_approved_workflow:

    ApprovedDestructiveAdminWorkflow: true

  condition: 1 of selection_* and not filter_approved_workflow

fields:

  - UtcTime

  - Computer

  - User

  - Image

  - CommandLine

  - ParentImage

  - ParentCommandLine

  - ProcessId

  - ProcessGuid

  - DiskPartScriptAction

  - DestructiveControlAction

  - DestructiveControlTarget

  - EventOutcome

  - AssetRole

  - AssetCriticality

falsepositives:

  - Approved disk imaging

  - Approved recovery operations

  - Approved backup administration

  - Approved forensic activity

  - Approved storage maintenance

  - Approved incident-response activity

  - Approved security testing

level: critical

tags:

  - attack.impact

  - attack.defense_evasion

  - attack.t1485

  - attack.t1490

  - attack.t1562.001

  - attack.t1070.001

Rule

High-Volume Destructive File Rename or Deletion Activity

Rule Format

Sigma distinct-value correlation package using normalized Windows file events, endpoint identity, stable responsible-process identity, affected-file paths, event outcomes, and approved high-volume workflow enrichment.

Detection Purpose

Detect one process renaming or deleting at least 20 distinct file paths on one Windows endpoint within five minutes.

The rule identifies high-volume destructive file activity without depending on a specific extension, ransom note, wallpaper, executable filename, hash, encryption implementation, malware family, or campaign identifier.

Detection Logic

·        Match successful Windows file rename or deletion events.

·        Require endpoint identity, stable responsible-process identity, and target-file path.

·        Exclude only events marked as complete approved high-volume file workflows.

·        Retain events without approved-workflow enrichment as eligible matches.

·        Group qualifying events by endpoint and stable responsible-process identity.

·        Count distinct target-file paths within five minutes.

·        Generate a correlation match when one endpoint and process pair affects at least 20 distinct paths.

·        Do not deploy the component event rule as an independent production alert.

·        Present the result as high-volume destructive file activity.

·        Do not present the result as confirmed encryption, ransomware, or GigaWiper activity.

Required Telemetry

·        Windows file rename and deletion events

·        File action and target path

·        Endpoint identifier

·        Stable responsible-process identity

·        Process image and command line where available

·        User identity where available

·        Event outcome

·        Approved high-volume file-workflow enrichment

·        Asset role and asset criticality where available

Engineering Implementation Instructions

·        Convert and deploy the complete multi-document Sigma correlation package together.

·        Confirm that the selected backend supports Sigma value_count correlation.

·        Map Computer to stable endpoint identity.

·        Map ProcessGuid to stable responsible-process identity.

·        Preserve Computer, ProcessGuid, and TargetFilename through correlation.

·        Require successful rename or deletion activity before an event contributes to correlation.

·        Require populated endpoint identity, process identity, and target-file path.

·        Require ApprovedHighVolumeFileWorkflow to represent a complete approved workflow.

·        Do not deploy the component event rule as an independent production alert.

·        Group by endpoint and stable process identity.

·        Count distinct target-file paths during a five-minute window.

·        Apply endpoint role and asset criticality after the correlation matches.

·        Implement equivalent native grouping and distinct-value logic where the backend does not support Sigma correlations.

·        Preserve the 20-path threshold unless customer validation supports a deliberate tuning change.

DRI Assessment

The rule detects high-volume destructive file behavior rather than fixed extensions, filenames, ransom artifacts, hashes, or encryption libraries. Endpoint-and-process grouping, distinct-path cardinality, successful file-action requirements, and complete-workflow filtering provide strong variant resistance.

DRI

8.9

TCR Assessment

Operational confidence depends on complete file-event attribution, stable process identity, path fidelity, action normalization, event outcome, endpoint identity, and approved-workflow enrichment. Full-telemetry confidence improves with user context, extension diversity, directory diversity, entropy, write volume, backup state, recovery state, process lineage, and endpoint health.

Operational TCR

8.7

Full-Telemetry TCR

9.3

Limitations

·        Slow or selectively targeted file destruction may remain below the threshold.

·        Activity divided across multiple process identities may evade the process-group threshold.

·        Missing file-event telemetry can reduce event counts.

·        Missing or unstable process identity can reduce grouping accuracy.

·        Direct disk or storage destruction may occur without file events.

·        The portable correlation counts distinct paths rather than enforcing a separate total-event threshold.

·        Legitimate backup, synchronization, encryption, migration, deployment, indexing, recovery, or security-testing workflows can produce similar activity.

·        Detection may occur after files have already been damaged.

·        Distinct-path correlation does not prove encryption.

·        Overbroad approved-workflow enrichment can suppress malicious activity.

·        The rule does not independently establish GigaWiper attribution.

Detection Query Pattern

Use this as a Sigma correlation-rule package. Map all fields and local enrichment fields to the target SIEM or EDR, and confirm that the selected Sigma backend supports value_count correlation before deployment.

title: Successful Windows File Rename or Deletion Event

name: gigawiper_file_rename_delete_event

logsource:

  product: windows

  definition: Requires normalized Windows file rename or deletion telemetry with stable endpoint and responsible-process identity.

detection:

  selection_file_action:

    FileAction:

      - 'renamed'

      - 'deleted'

    EventOutcome:

      - 'success'

      - 'successful'

      - 'succeeded'

  selection_required_fields:

    Computer|exists: true

    ProcessGuid|exists: true

    TargetFilename|exists: true

  filter_approved_workflow:

    ApprovedHighVolumeFileWorkflow: true

  condition: selection_file_action and selection_required_fields and not filter_approved_workflow

---

title: High-Volume Destructive File Rename or Deletion Activity

id: c4a2f6d8-8e17-4b34-9a65-1f7c2d8e4003

status: test

description: Detects one process renaming or deleting at least 20 distinct file paths on one Windows endpoint within five minutes.

references:

  - Internal CyberDax detection model for GigaWiper backdoor-to-destruction behavior

author: CyberDax

date: 2026-07-12

correlation:

  type: value_count

  rules:

    - gigawiper_file_rename_delete_event

  group-by:

    - Computer

    - ProcessGuid

  timespan: 5m

  condition:

    gte: 20

    field: TargetFilename

falsepositives:

  - Approved backup operations

  - Approved synchronization activity

  - Approved encryption or migration workflows

  - Approved deployment or indexing activity

  - Approved recovery operations

  - Approved security testing

level: high

tags:

  - attack.impact

  - attack.t1485

YARA

Detection Viability Assessment

YARA can provide narrowly scoped artifact detection for GigaWiper because public analysis identifies stable function names and distinctive embedded operational strings retained within unstripped Go-based Windows PE samples.

One rule opportunity survives validation:

·        GigaWiper backdoor and embedded destructive-module artifact detection

A separate standalone-wiper rule is not included because the available public reporting does not provide enough standalone-specific artifact material to distinguish it confidently from the embedded wiper implementation or related predecessor tooling.

Rule

GigaWiper Backdoor and Embedded Destructive Modules

Rule Format

YARA file-scanning rule using Windows PE validation, retained Go function and package symbols, and distinctive embedded GigaWiper operational strings.

Detection Purpose

Detect GigaWiper backdoor binaries containing retained Go symbols associated with the malware’s destructive modules and embedded operational strings associated with persistence, disk wiping, command handling, or event-log destruction.

The rule is designed to identify the GigaWiper backdoor family without depending on a specific file name, hash, C2 address, scheduled-task name, encryption extension, or campaign label.

Detection Logic

·        Require the scanned object to begin with a valid Windows PE header.

·        Require at least two retained GigaWiper-associated Go function or package symbols.

·        Require at least two distinctive operational strings documented in analyzed GigaWiper samples.

·        Require at least one persistence or event-log destruction string.

·        Match ASCII and wide-string representations where appropriate.

·        Do not trigger solely on generic Go runtime strings.

·        Do not trigger solely on WipeMain, GRAT, .candy, PHYSICALDRIVE, RabbitMQ, Redis, or other individually reusable artifacts.

·        Do not use C2 addresses or hashes as mandatory conditions.

·        Treat a match as a high-confidence GigaWiper artifact lead requiring sample validation.

·        Do not use the YARA result alone to establish actor attribution or confirmed execution.

Required Telemetry

·        File content collected from endpoints, malware repositories, email or web gateways, forensic images, quarantine stores, or sandbox submissions

·        Complete or substantially complete Windows PE files

·        Access to uncompressed or unpacked file content

·        YARA engine support for ASCII and wide-string matching

·        File hash, source path, host, collection time, and signer context where available

Engineering Implementation Instructions

·        Deploy the rule against files, quarantine objects, forensic collections, sandbox submissions, and memory-extracted PE images where full string content is preserved.

·        Validate the rule against known GigaWiper samples before production deployment when samples are available.

·        Validate the rule against a representative corpus of legitimate Go-based Windows applications.

·        Preserve the multi-anchor condition requiring function symbols, operational strings, and persistence or evidence-destruction strings.

·        Do not weaken the condition to a single function name or a single operational string.

·        Do not make the published C2 address, scheduled-task name, Registry path, .candy extension, or known hashes mandatory.

·        Do not add generic Go strings as independent detection anchors.

·        Retain ASCII matching for Go symbol names.

·        Retain wide matching only for operational strings that may be represented in Windows-oriented string data.

·        Scan unpacked or memory-resident content when packing or runtime decryption prevents file-level string recovery.

·        Record which string groups satisfied the condition so analysts can distinguish strong family matches from incomplete or damaged samples.

·        Route matches for malware-analysis confirmation before automated deletion when the source or file context is uncertain.

DRI Assessment

The rule combines multiple independent artifact classes rather than depending on one fragile indicator. Retained Go function and package symbols provide implementation-level anchors, while distinctive persistence, command, disk-wiping, and event-log strings provide operational anchors.

The condition resists changes to filenames, hashes, C2 infrastructure, task names, Registry value names, and encryption extensions. Coverage will decrease if the malware is stripped, packed, heavily obfuscated, or rebuilt with renamed functions and removed diagnostic strings.

DRI

8.8

TCR Assessment

Operational confidence is strong when complete unstripped GigaWiper binaries are scanned. Confidence decreases when only partial files, packed samples, corrupted objects, or memory fragments are available.

Full-telemetry confidence improves when YARA matches are enriched with file hashes, signer information, execution history, process lineage, source host, acquisition path, sandbox behavior, and endpoint detection telemetry.

Operational TCR

8.8

Full-Telemetry TCR

9.4

Limitations

·        Stripped or obfuscated builds may remove the retained Go symbols required by the rule.

·        Modified variants may rename functions or remove diagnostic strings.

·        Packers or encrypted loaders may conceal strings until runtime.

·        Partial or corrupted files may not contain enough anchors to satisfy the condition.

·        The rule may not detect the standalone wiper if it lacks the backdoor-specific symbols and operational strings.

·        Some symbols originate from destructive components related to earlier malware families, so the rule requires multiple GigaWiper-associated symbol and operational-string groups rather than one shared function.

·        A match identifies a likely GigaWiper artifact but does not prove execution.

·        A match does not independently establish threat-actor attribution.

·        Known hashes remain useful for confirmation but are not variant-resistant detection anchors.

Detection Query Pattern

Use this as a YARA file-rule template. Validate the rule against known GigaWiper samples and a representative clean corpus of Go-based Windows executables before production deployment.

import "pe"

rule MAL_GigaWiper_Backdoor_Destructive_Modules

{

    meta:

        description = "Detects GigaWiper backdoor binaries using retained Go symbols and distinctive destructive or operational strings"

        author = "CyberDax"

        date = "2026-07-12"

        status = "test"

        threat_name = "GigaWiper"

        alternative_name = "BLUERABBIT"

        source = "Microsoft Threat Intelligence analysis of GigaWiper"

        scope = "file"

        confidence = "high"

    strings:

        $func_wipe_main =

            "rabbit_tools_tool_wipe_main.WipeMain"

            ascii

        $func_wipec_main =

            "rabbit_tools_tool_wipec_main.WipeCMain"

            ascii

        $func_ran_main =

            "rabbit_tools_tool_ran_main_cmd_extort.RanMain"

            ascii

        $func_extort_main =

            "rabbit_tools_tool_ran_main_bin.BigBangExtortMain"

            ascii

        $func_registry_main =

            "rabbit_bin.RunOnceRegistryMain.gowrap1"

            ascii

        $op_partitions_removed =

            "Partitions removed successfully."

            ascii wide

        $op_task_created =

            "Task created. Original process exiting."

            ascii wide

        $op_task_scheduler =

            "Running from Task Scheduler"

            ascii wide

        $op_wipe_file =

            "Exec cmd wipe-file"

            ascii wide

        $op_keylog =

            "Exec cmd keylog"

            ascii wide

        $op_security_log_failure =

            "Failed to clear Security with wevtutil. Attempting manual removal"

            ascii wide

        $op_eventlog_marker =

            "kharbvnmhkjbkjb"

            ascii wide

        $op_shell_delimiter =

            "|?????|"

            ascii wide

    condition:

        uint16(0) == 0x5A4D

        and uint32(uint32(0x3C)) == 0x00004550

        and 2 of ($func_*)

        and 2 of ($op_*)

        and 1 of (

            $op_task_created,

            $op_task_scheduler,

            $op_security_log_failure,

            $op_eventlog_marker

        )

}

AWS

AWS Coverage Disposition

AWS has zero deployable rules for this TTD report.

AWS is not viable as a primary S25 cloud detection system because the documented GigaWiper detection model is Windows guest-operating-system based, process-context based, scheduled-task-persistence and Registry-activity based, recovery and boot-configuration based, disk and partition destruction based, event-log clearing based, file-impact based, and endpoint-telemetry driven rather than AWS control-plane, cloud-identity, EC2 management API, Systems Manager, snapshot, storage-service, or other AWS-native activity based.

AWS may provide limited supporting value when affected Windows workloads are hosted on Amazon EC2 and the required guest process, Registry, scheduled-task, recovery, boot, disk, event-log, and file telemetry is collected through an endpoint platform, SIEM, CloudWatch-compatible pipeline, or other guest-monitoring architecture. That telemetry remains covered by the endpoint, Sigma, QRadar, and YARA detection content in this report and does not justify a separate AWS-native rule.

A platform-specific AWS guest-workload adaptation may be appropriate in a broader EXP report, cloud-workload implementation package, or customer deployment model that explicitly addresses EC2 telemetry collection, AWS resource identity, account and Region enrichment, workload criticality, cloud recovery architecture, and native alert routing.

Final AWS Outcome

No AWS rules survive.

Azure

Azure Coverage Disposition

Azure has zero deployable rules for this TTD report.

Azure is not viable as a primary S25 cloud detection system because the documented GigaWiper detection model is Windows guest-operating-system based, process-context based, scheduled-task-persistence and Registry-activity based, recovery and boot-configuration based, disk and partition destruction based, event-log clearing based, file-impact based, and endpoint-telemetry driven rather than Azure control-plane, managed-identity, Azure Resource Manager, VM Run Command, VM extension, managed-disk, snapshot, Recovery Services, storage-service, or other Azure-native activity based.

Azure may provide limited supporting value when affected Windows workloads are hosted on Azure Virtual Machines and the required guest process, Registry, scheduled-task, recovery, boot, disk, event-log, and file telemetry is collected through Microsoft Defender for Endpoint, Microsoft Sentinel, Azure Monitor, Log Analytics, or another guest-monitoring architecture. That telemetry remains covered by the endpoint, Sigma, QRadar, and YARA detection content in this report and does not justify a separate Azure-native rule.

A platform-specific Azure guest-workload adaptation may be appropriate in a broader EXP report, cloud-workload implementation package, or customer deployment model that explicitly addresses Azure VM telemetry collection, subscription and resource-group enrichment, VM resource identity, workload criticality, cloud recovery architecture, and native alert routing.

Final Azure Outcome

No Azure rules survive.

GCP

GCP Coverage Disposition

GCP has zero deployable rules for this TTD report.

GCP is not viable as a primary S25 cloud detection system because the documented GigaWiper detection model is Windows guest-operating-system based, process-context based, scheduled-task-persistence and Registry-activity based, recovery and boot-configuration based, disk and partition destruction based, event-log clearing based, file-impact based, and endpoint-telemetry driven rather than Google Cloud control-plane, service-account, OS Login, instance-metadata, Compute Engine API, persistent-disk, snapshot, Cloud Storage, or other GCP-native activity based.

GCP may provide limited supporting value when affected Windows workloads are hosted on Compute Engine and the required guest process, Registry, scheduled-task, recovery, boot, disk, event-log, and file telemetry is collected through an endpoint platform, SIEM, Google Cloud Ops Agent, Cloud Logging pipeline, or another guest-monitoring architecture. That telemetry remains covered by the endpoint, Sigma, QRadar, and YARA detection content in this report and does not justify a separate GCP-native rule.

A platform-specific GCP guest-workload adaptation may be appropriate in a broader EXP report, cloud-workload implementation package, or customer deployment model that explicitly addresses Compute Engine telemetry collection, project and instance enrichment, zone and resource identity, workload criticality, cloud recovery architecture, and native alert routing.

Final GCP Outcome

No GCP rules survive.

S26 Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary GigaWiper behaviors and artifact conditions established in S21 through S24 to the S25 detection rules implemented across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA, AWS, Azure, and GCP.

The traceability model distinguishes direct detection coverage, supporting visibility, conditional coverage, and residual gaps. A behavior described in the threat model is not treated as directly covered unless a surviving S25 rule implements that behavior.

The model remains behavior-led except for the YARA rule, which uses multiple documented GigaWiper implementation and operational anchors. No behavioral rule depends on a specific malware name, filename, hash, infrastructure address, scheduled-task name, Registry value name, network port, file extension, disk number, or ransom artifact.

Generic autorun Registry rules retained within S25 provide broader Windows persistence coverage but are not counted as direct GigaWiper coverage because the documented GigaWiper Registry location tracks execution state rather than establishing persistence.

Coverage Scope

The completed S25 rule set provides direct GigaWiper-aligned coverage for:

·        Role-inconsistent or unapproved RabbitMQ, AMQP, or Redis communication

·        Unapproved inbound listener and accepted remote-session activity

·        Scheduled-task persistence command execution

·        Confirmed scheduled-task creation or modification where supported telemetry exists

·        Physical-drive references

·        Destructive disk and partition activity where command, script-classification, or confirmed control telemetry is available

·        Shadow-copy deletion

·        Backup-catalog deletion

·        Windows Recovery Environment disablement

·        Destructive boot-recovery configuration changes

·        Windows event-log clearing

·        High-volume destructive file activity attributed to a responsible process

·        Recoverable GigaWiper PE artifacts containing the required implementation and operational anchors

The completed S25 rule set provides supporting or conditional visibility for:

·        Backdoor execution

·        Registry execution-state tracking

·        Shell and remote task execution

·        Screen capture and recording

·        VNC-like remote-control behavior

·        Broader system and process administration

·        External file transfer and object-storage activity

·        Firewall modification

·        Service administration

·        Process suspension or termination

·        Forced crash, reboot, boot failure, or abrupt endpoint-health loss

AWS, Azure, and GCP have zero deployable cloud-native rules because the documented threat model concerns Windows guest-operating-system behavior rather than cloud control-plane activity.

Windows workloads hosted on those platforms remain eligible for endpoint, network, SIEM, Sigma, and YARA coverage when the required guest telemetry is collected.

Threat-to-Rule Mapping

Backdoor Execution

Threat Condition

An unsigned, newly observed, uncommon, or low-prevalence Windows PE executable launches from a user-writable, temporary, download, staging, or nonstandard path and is followed by persistence, network communication, shell execution, surveillance, system administration, or destructive behavior.

Mapped Coverage

·        Supporting NDR coverage where the endpoint performs role-inconsistent RabbitMQ, AMQP, or Redis communication

·        Supporting NDR coverage where the endpoint accepts qualifying unapproved inbound remote sessions

·        Supporting SentinelOne coverage where the executable or a related process performs scheduled-task persistence or destructive administration

·        Supporting Splunk, Elastic, QRadar, or Sigma coverage where the process performs an implemented scheduled-task, destructive-system, or destructive-file behavior

·        YARA coverage where the file retains the required GigaWiper implementation and operational anchors

Coverage Qualification

No surviving S25 rule directly detects generic first-seen, unsigned, uncommon, or low-prevalence executable execution as an independent alert condition.

Executable prevalence, path, signer, parent process, and first-seen status may strengthen investigation and correlation but do not independently satisfy the implemented rules.

Residual Gap

A backdoor may execute without triggering an implemented persistence, network, destructive, file-impact, or artifact rule.

An uncommon executable alone does not establish GigaWiper activity.

Role-Inconsistent RabbitMQ, AMQP, or Redis Communication

Threat Condition

A Windows endpoint communicates through RabbitMQ, AMQP, or Redis in a manner inconsistent with its assigned role, approved dependencies, or historical destination use.

Mapped Coverage

·        NDR / Network Behavioral Analytics through Role-Inconsistent RabbitMQ AMQP or Redis Communication

·        Supporting endpoint and SIEM correlation where the same system also exhibits scheduled-task or destructive command activity

·        Supporting YARA context where a related GigaWiper artifact is recovered

Coverage Qualification

The NDR rule requires canonical source and destination identity, Windows asset-role context, unapproved dependency status, and either role inconsistency or destination rarity.

Where service identification is derived only from destination-port mapping, the rule also requires destination rarity and at least three connections within 15 minutes.

A single external and newly observed connection may qualify only when RabbitMQ, AMQP, or Redis is identified through application or destination-service metadata.

The rule does not implement dual-channel RabbitMQ and Redis correlation, periodic beacon analysis, or multi-endpoint destination convergence.

Residual Gap

Encrypted, tunneled, proxied, encapsulated, misclassified, or unavailable traffic may evade detection.

The rule does not establish command content, endpoint execution, destructive intent, or GigaWiper attribution.

Unapproved Windows Endpoint Listener and Remote-Session Activity

Threat Condition

A Windows endpoint accepts inbound TCP sessions on a destination port that is new, rare, or unexpected for its assigned role and is not part of an approved inbound service path.

Mapped Coverage

·        NDR / Network Behavioral Analytics through Unapproved Windows Endpoint Listener with Remote Session Activity

·        Supporting endpoint and SIEM context where the same endpoint exhibits firewall changes, scheduled-task persistence, shell execution, destructive commands, or other suspicious activity

·        Supporting YARA context where a related artifact is recovered

Coverage Qualification

The rule requires accepted or established inbound TCP communication, at least two accepted sessions within 15 minutes, and at least one session lasting 30 seconds or longer.

The destination endpoint and destination role must resolve to stable identities. The destination port must be new, rare, or role-inconsistent.

Blocked, rejected, failed, incomplete, and isolated scanning activity does not satisfy the rule.

Residual Gap

The rule does not prove VNC use, identify the responsible process, or establish screen capture, screen recording, keyboard control, mouse control, executed commands, or GigaWiper attribution.

Outbound reverse connections, brokered remote-support channels, approved listeners, trusted relays, NAT, VPN concentrators, load balancers, and port forwarding may reduce visibility.

Scheduled-Task Persistence

Threat Condition

A process executes a command that creates or modifies a Windows scheduled task, or confirmed task telemetry records a successful creation, registration, or modification.

Mapped Coverage

·        SentinelOne through Scheduled-Task Persistence Command Execution

·        Splunk through the scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Elastic through the scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        QRadar through the scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Sigma through the scheduled-task branches of Confirmed Windows Scheduled Task

·        Supporting YARA artifact coverage where the file retains the required GigaWiper anchors

Coverage Qualification

SentinelOne provides command-observed coverage for supported scheduled-task creation and modification commands.

Splunk, Elastic, QRadar, and Sigma provide command-observed and confirmed task-change coverage where the required telemetry, event outcomes, process identity, and approved-workflow context are available.

Only the scheduled-task branches of the combined SIEM and Sigma persistence rules are counted as direct GigaWiper coverage.

Residual Gap

Direct API task creation, obfuscated commands, unsupported task methods, missing command lines, and absent task-change telemetry may reduce coverage.

The SentinelOne rule does not require an uncommon executable or uncommon path.

Registry Execution-State Tracking

Threat Condition

The documented HKCU\SOFTWARE\OneDrive\Environment location is created or modified to track GigaWiper execution state.

Mapped Coverage

·        Supporting endpoint and SIEM visibility where Registry activity is collected and attributed to the suspected implant or a related process

·        Supporting investigative enrichment through the documented Registry path

·        Supporting YARA artifact context where the file retains the required implementation anchors

Coverage Qualification

The documented Registry behavior tracks execution state and does not independently establish persistence.

Generic autorun Registry rules retained in S25 do not directly map to this GigaWiper behavior and are not counted as direct GigaWiper coverage.

Registry modification may increase confidence when it converges with scheduled-task persistence, anomalous messaging traffic, remote-control activity, destructive commands, or a matching GigaWiper artifact.

Residual Gap

Execution-state tracking may be absent, altered, moved to another location, or performed without observable Registry telemetry.

Registry activity alone does not establish GigaWiper execution or persistence.

Shell and Remote Task Execution

Threat Condition

The implant or a related operator-controlled process launches PowerShell, a command shell, administrative utilities, or other task execution.

Mapped Coverage

·        SentinelOne, Splunk, Elastic, QRadar, and Sigma when shell activity performs an implemented scheduled-task or destructive action

·        Supporting NDR context where shell activity occurs on an endpoint with anomalous messaging or unapproved remote-session behavior

·        Supporting YARA context where a related artifact is recovered

Coverage Qualification

No surviving S25 rule directly governs arbitrary PowerShell, command-shell, or remote-task execution.

Shell activity is directly detected only when it performs one of the implemented scheduled-task or destructive behaviors.

Residual Gap

Generic shell or remote-task execution may remain undetected when it does not satisfy another rule.

Screen Capture and Recording

Threat Condition

The implant captures screenshots or records endpoint display activity.

Mapped Coverage

·        Supporting NDR context

·        Supporting endpoint, SIEM, file, or YARA evidence where available

Coverage Qualification

No surviving S25 rule directly detects screen capture or screen recording.

The NDR listener rule detects qualifying unapproved remote-session activity but does not prove screen access.

Residual Gap

Screen capture or recording may occur without a qualifying listener, visible output file, associated transfer event, or implemented endpoint detection.

VNC-Like Remote Control

Threat Condition

The implant creates or uses an inbound listener to support interactive remote access, screen interaction, keyboard control, or mouse control.

Mapped Coverage

·        NDR / Network Behavioral Analytics through Unapproved Windows Endpoint Listener with Remote Session Activity

·        Supporting endpoint and SIEM context where listener creation, firewall changes, remote-input activity, or related process behavior is available

Coverage Qualification

The NDR rule detects qualifying accepted inbound-session behavior.

It does not directly prove that the session used GigaWiper, VNC-like functionality, screen access, keyboard control, or mouse control.

Residual Gap

Outbound reverse connections, brokered remote-control channels, approved listeners, short sessions, unavailable session-result telemetry, or missing endpoint attribution may evade coverage.

System and Process Administration

Threat Condition

The implant or operator creates, modifies, starts, stops, suspends, resumes, terminates, or enumerates processes, services, Registry content, firewall rules, or other system controls.

Mapped Coverage

·        Direct coverage only where the activity satisfies an implemented scheduled-task or destructive-system rule

·        Supporting endpoint and SIEM visibility for broader administrative activity

·        Supporting NDR context where administration follows anomalous messaging or remote-session activity

·        Supporting YARA context where a related artifact is recovered

Coverage Qualification

No surviving S25 rule directly covers the full GigaWiper system-administration capability set.

Registry, service, process, and firewall activity may strengthen correlation but does not independently satisfy the implemented rules unless it performs a directly covered behavior.

Residual Gap

Broader service, process, Registry, firewall, and system administration may occur without triggering a surviving S25 rule.

External File Transfer and Object-Storage Activity

Threat Condition

The implant uses MinIO tooling or another object-storage client to move files to or from an external or unapproved storage destination.

Mapped Coverage

·        Supporting network visibility where the destination or service is rare, external, or role-inconsistent

·        Supporting endpoint and SIEM visibility where object-storage client execution, command lines, file staging, or transfer events are collected

·        Supporting YARA context where a related artifact is recovered

Coverage Qualification

No surviving S25 rule directly detects MinIO execution, alias creation, credential use, file upload, file download, or successful data exfiltration.

File-transfer capability and object-storage access must not be treated as proof that sensitive data was successfully transferred.

Residual Gap

Encrypted traffic, approved storage destinations, alternate transfer tools, missing command lines, missing object-access logs, or unavailable file-transfer outcomes may prevent detection.

Physical-Drive, Disk, and Partition Destruction

Threat Condition

A process references a physical-drive device, performs destructive disk or partition commands, executes a confirmed destructive DiskPart script, or produces confirmed disk or partition state changes.

Mapped Coverage

·        SentinelOne through Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

·        Splunk through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Elastic through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        QRadar through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Sigma through Destructive Windows Disk Recovery Backup or Evidence Degradation

·        Supporting YARA artifact coverage

Coverage Qualification

SentinelOne provides command-observed coverage for physical-drive references and supported destructive commands.

Splunk, Elastic, QRadar, and Sigma provide command-observed and confirmed control-event coverage where required telemetry exists.

DiskPart destruction requires script-content classification or confirmed disk or partition state-change telemetry. DiskPart process creation or /s use alone does not prove destruction.

Residual Gap

Direct API, custom-driver, kernel-level, in-memory, interactive, or otherwise unobserved destructive disk activity may evade command-based detection.

Destructive actions may complete before collection, alerting, or isolation.

Recovery, Boot, Backup, and Evidence Degradation

Threat Condition

A process deletes shadow copies or backup catalogs, disables Windows recovery, changes boot-recovery configuration, clears Windows event logs, or produces a confirmed related state change.

Mapped Coverage

·        SentinelOne through Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

·        Splunk through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Elastic through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        QRadar through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Sigma through Destructive Windows Disk Recovery Backup or Evidence Degradation

·        Supporting YARA artifact coverage

Coverage Qualification

The implemented rules provide command-observed coverage for supported Windows utilities and confirmed-event coverage where the required state-change telemetry is available.

Ordinary restart or shutdown activity does not independently satisfy the destructive-system rules.

Residual Gap

Direct API activity, renamed utilities, obfuscated commands, missing command lines, unavailable control outcomes, direct event-log file deletion, and unsupported recovery or boot methods may evade coverage.

High-Volume Destructive File Activity

Threat Condition

A process performs high-volume file transformation, rename, replacement, or deletion activity across multiple files, paths, directories, or extensions.

Mapped Coverage

·        Splunk through High-Volume Destructive File Transformation With Source Deletion or Rename Activity

·        Elastic through High-Volume Destructive File Rename or Deletion Activity

·        QRadar through High-Volume Destructive File Rename or Deletion Activity

·        Sigma through High-Volume Destructive File Rename or Deletion Activity

·        Supporting YARA artifact coverage

Coverage Qualification

The SIEM and Sigma rules require responsible-process attribution, file-event volume, affected-path breadth, and customer-maintained role-aware thresholds or backend-equivalent correlation.

Splunk includes broader file-transformation activity with source deletion or rename requirements.

Elastic, QRadar, and Sigma focus on high-volume rename or deletion behavior.

Residual Gap

Slow, selective, distributed, multi-process, below-threshold, or poorly attributed file destruction may evade coverage.

Detection may occur after files have already been damaged.

GigaWiper Artifact Identification

Threat Condition

A recoverable Windows PE file retains the required combination of documented GigaWiper implementation and operational anchors.

Mapped Coverage

·        YARA through GigaWiper Backdoor and Embedded Destructive Modules

Coverage Qualification

The YARA rule provides direct artifact coverage where the required content remains present and scannable.

A YARA match does not prove execution, persistence, remote control, successful file transfer, destructive completion, or actor attribution.

Residual Gap

Packed, stripped, encrypted, modified, incomplete, memory-only, or substantially rebuilt samples may evade the rule.

Standalone destructive modules that do not retain the required backdoor anchors may not match.

Platform Coverage Disposition

NDR / Network Behavioral Analytics

Provides direct coverage through:

·        Role-Inconsistent RabbitMQ AMQP or Redis Communication

·        Unapproved Windows Endpoint Listener with Remote Session Activity

SentinelOne

Provides direct GigaWiper-aligned endpoint command coverage through:

·        Scheduled-Task Persistence Command Execution

·        Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

The User-Context Autorun Registry Persistence Command Execution rule remains generic Windows persistence coverage and is not counted as direct GigaWiper coverage.

SentinelOne does not provide a destructive-file event rule in the completed S25 set.

Splunk

Provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Transformation With Source Deletion or Rename Activity

The autorun Registry branches remain generic Windows persistence coverage and are not counted as direct GigaWiper coverage.

Elastic

Provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches remain generic Windows persistence coverage and are not counted as direct GigaWiper coverage.

QRadar

Provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches remain generic Windows persistence coverage and are not counted as direct GigaWiper coverage.

Sigma

Provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Scheduled Task

·        Destructive Windows Disk Recovery Backup or Evidence Degradation

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches remain generic Windows persistence coverage and are not counted as direct GigaWiper coverage.

YARA

Provides direct artifact coverage through:

·        GigaWiper Backdoor and Embedded Destructive Modules

AWS

No AWS-native rules survive.

Azure

No Azure-native rules survive.

GCP

No GCP-native rules survive.

Residual Traceability Gaps

·        Generic backdoor execution

·        Registry execution-state tracking as a standalone detection

·        Arbitrary shell and remote task execution

·        Screen capture and recording

·        Keyboard and mouse control

·        External file transfer and object-storage activity

·        Broader service and process administration

·        Firewall modification outside supporting context

·        Direct event-log file deletion

·        Forced crash, reboot, boot failure, and endpoint-health loss as standalone detections

·        Initial access

·        Credential theft

·        Privilege escalation

·        Lateral movement

·        Active Directory compromise

·        Enterprise propagation

·        Cloud-control-plane abuse

·        Virtualization impact

·        Direct API activity without command or state-change telemetry

·        Slow or distributed destructive file activity below configured thresholds

·        Artifact variants that remove the required YARA anchors

·        Actor attribution

Traceability Conclusion

The completed S25 rule set provides strong behavior-led and artifact-supported coverage for anomalous RabbitMQ, AMQP, or Redis communication; qualifying unapproved inbound listener and remote-session activity; scheduled-task persistence; physical-drive, disk, partition, recovery, boot, backup, and event-log destruction; high-volume destructive file activity; and retained GigaWiper artifact characteristics.

NDR / Network Behavioral Analytics provides the strongest direct network coverage.

SentinelOne provides direct GigaWiper-aligned endpoint command coverage for scheduled-task persistence and destructive disk, recovery, boot, backup, or evidence-destruction activity.

Splunk, Elastic, QRadar, and Sigma provide broad scheduled-task, destructive-system, and high-volume file-impact coverage.

YARA provides narrowly scoped artifact coverage where the required file content remains available.

The generic autorun Registry rules retained in S25 are not counted as direct GigaWiper coverage. The documented GigaWiper Registry activity is execution-state tracking and remains supporting investigative context.

Backdoor execution, Registry execution-state tracking, arbitrary shell activity, screen capture, screen recording, external file transfer, broader system administration, direct event-log file deletion, forced crash behavior, and endpoint-health loss remain supporting or limited coverage areas unless they converge with an implemented S25 rule.

Detection confidence depends on correlating endpoint identity, responsible process, process lineage, user, scheduled-task target, Registry activity, command line, event outcome, network behavior, destructive target, file-impact breadth, asset role, approved-workflow context, and artifact evidence rather than treating any single event or artifact as proof of GigaWiper compromise.

S29 Detection Coverage Summary

Coverage Purpose

This section summarizes the detection coverage achieved by the completed GigaWiper S25 rule set and identifies where coverage is strong, conditional, limited, supporting, or unavailable.

The assessment evaluates coverage by behavior and detection system without creating new rules, changing the surviving rule inventory, or representing supporting telemetry as direct detection coverage.

Generic autorun Registry rules retained within S25 provide broader Windows persistence coverage but are not counted as direct GigaWiper coverage because the documented GigaWiper Registry behavior tracks execution state rather than establishing persistence.

Overall Coverage Determination

The completed detection package provides strong behavior-led coverage for GigaWiper’s most observable network, scheduled-task persistence, destructive-system, file-impact, and artifact behaviors.

Strong direct coverage exists for:

·        Role-inconsistent or unapproved RabbitMQ, AMQP, or Redis communication

·        Qualifying unapproved inbound listener and remote-session activity

·        Scheduled-task persistence

·        Physical-drive references

·        Destructive disk and partition activity

·        Recovery disablement

·        Boot-recovery sabotage

·        Shadow-copy and backup-catalog deletion

·        Windows event-log clearing

·        High-volume destructive file activity

·        Recoverable GigaWiper PE artifacts containing multiple documented implementation and operational anchors

Coverage is supporting or limited for:

·        Generic backdoor execution

·        Registry execution-state tracking

·        Arbitrary shell and remote task execution

·        Screen capture

·        Screen recording

·        Keyboard and mouse control

·        External file transfer

·        Object-storage use

·        Broader system administration

·        Firewall modification

·        Direct event-log file deletion

·        Forced crash behavior

·        Reboot

·        Boot failure

·        Endpoint-health loss

Coverage is conditional where detection depends on complete command-line telemetry, stable process identity, confirmed state-change events, file-event attribution, network classification, endpoint and destination identity, asset-role baselines, approved-workflow context, or recoverable file content.

AWS, Azure, and GCP have no deployable cloud-native rules in this TTD because the documented activity occurs inside the Windows guest operating system rather than through cloud control-plane APIs.

Windows workloads hosted on those platforms remain eligible for endpoint, network, SIEM, Sigma, and YARA coverage when the required guest telemetry is collected.

Coverage by Detection Behavior

Backdoor Execution

Coverage Level

Supporting and limited.

Covered By

·        Supporting NDR visibility where the endpoint performs anomalous RabbitMQ, AMQP, or Redis communication

·        Supporting NDR visibility where the endpoint accepts qualifying unapproved inbound sessions

·        Supporting endpoint and SIEM coverage when the process performs an implemented scheduled-task or destructive behavior

·        YARA where the artifact retains the required GigaWiper anchors

Coverage Summary

No surviving S25 rule directly alerts on generic first-seen, unsigned, uncommon, or low-prevalence executable execution.

Executable prevalence, signer, path, parent process, and first-seen status strengthen correlation and investigation but do not independently satisfy the implemented rules.

Residual Gap

A backdoor may execute without triggering an implemented network, persistence, destructive, file-impact, or artifact rule.

Messaging-Based Command and Status Communication

Coverage Level

Strong where network classification, endpoint attribution, destination identity, destination prevalence, asset-role context, and approved dependency mappings are available.

Covered By

·        NDR / Network Behavioral Analytics through Role-Inconsistent RabbitMQ AMQP or Redis Communication

·        Supporting endpoint, SIEM, and YARA context

Coverage Summary

The NDR rule detects RabbitMQ, AMQP, or Redis communication from Windows endpoints when the communication is not an approved dependency and the service family is unexpected for the endpoint role or the destination is new or rare.

Port-derived service identification requires destination rarity and at least three connections within 15 minutes.

A single external and newly observed connection may qualify only when the service family is identified through application or destination-service metadata.

Residual Gap

The rule does not directly detect dual-channel messaging, periodic beaconing, command content, or multi-endpoint convergence.

Encrypted, tunneled, proxied, encapsulated, misclassified, or unavailable traffic may evade detection.

Unapproved Listener and Remote-Session Activity

Coverage Level

Strong where accepted inbound-session telemetry, endpoint identity, port history, asset-role context, session duration, and approved-service mappings are available.

Covered By

·        NDR / Network Behavioral Analytics through Unapproved Windows Endpoint Listener with Remote Session Activity

·        Supporting endpoint and SIEM context

Coverage Summary

The rule detects Windows endpoints accepting inbound TCP sessions on new, rare, or role-inconsistent destination ports.

It requires at least two accepted sessions within 15 minutes and at least one session lasting 30 seconds or longer.

Blocked, rejected, failed, incomplete, and isolated scanning activity does not satisfy the rule.

Residual Gap

The rule does not prove VNC use, screen access, keyboard control, mouse control, command execution, or GigaWiper attribution.

Scheduled-Task Persistence

Coverage Level

Strong where command-line or confirmed task-change telemetry is available.

Covered By

·        SentinelOne through Scheduled-Task Persistence Command Execution

·        Splunk, Elastic, QRadar, and Sigma through the scheduled-task branches of their implemented persistence rules

·        Supporting YARA artifact coverage

Coverage Summary

SentinelOne provides command-observed coverage for supported scheduled-task creation and modification commands.

Splunk, Elastic, QRadar, and Sigma provide broader command-observed and confirmed task-change coverage.

Only the scheduled-task branches of the combined persistence rules are counted as direct GigaWiper coverage.

Residual Gap

Direct API task creation, obfuscated commands, unsupported methods, and missing task-change telemetry may reduce coverage.

The SentinelOne rule does not require an uncommon executable or uncommon path.

Registry Execution-State Tracking

Coverage Level

Supporting and limited.

Covered By

·        Supporting endpoint and SIEM Registry telemetry

·        Supporting responsible-process and process-lineage correlation

·        Supporting YARA artifact context where the required anchors remain present

Coverage Summary

The documented HKCU\SOFTWARE\OneDrive\Environment activity tracks execution state and does not independently establish persistence.

Generic autorun Registry rules retained in S25 do not directly map to this documented GigaWiper behavior and are not counted as direct GigaWiper coverage.

Registry activity may increase confidence when it converges with scheduled-task persistence, anomalous messaging traffic, destructive commands, remote-control behavior, or a matching artifact.

Residual Gap

Registry execution-state tracking may be absent, altered, relocated, or performed without observable telemetry.

Registry activity alone does not establish GigaWiper execution or persistence.

Shell and Remote Task Execution

Coverage Level

Supporting and limited.

Covered By

·        SentinelOne, Splunk, Elastic, QRadar, and Sigma when shell activity performs an implemented scheduled-task or destructive action

·        Supporting NDR context where shell activity occurs on an endpoint with anomalous messaging or unapproved remote-session behavior

Coverage Summary

No surviving S25 rule directly governs arbitrary PowerShell, command-shell, or remote-task execution.

Shell activity is directly detected only when it performs one of the implemented scheduled-task or destructive behaviors.

Residual Gap

Generic shell or remote-task execution may remain undetected when it does not satisfy another rule.

Screen Capture and Recording

Coverage Level

Limited.

Covered By

·        Supporting NDR context

·        Supporting endpoint, SIEM, file, or YARA evidence where available

Coverage Summary

No surviving S25 rule directly detects screen capture or screen recording.

The NDR listener rule detects qualifying unapproved remote-session activity but does not prove screen access.

Residual Gap

Screen capture or recording may occur without a qualifying listener, visible output file, associated transfer event, or implemented endpoint detection.

VNC-Like Remote Control

Coverage Level

Conditional and supporting.

Covered By

·        NDR / Network Behavioral Analytics through Unapproved Windows Endpoint Listener with Remote Session Activity

·        Supporting endpoint and SIEM context

Coverage Summary

The NDR rule detects qualifying unapproved accepted inbound-session behavior.

It does not directly establish VNC-like interaction, screen access, keyboard control, mouse control, or GigaWiper attribution.

Residual Gap

Outbound reverse connections, approved listeners, brokered remote-support paths, short sessions, missing session-result data, and unavailable endpoint attribution may evade coverage.

System and Process Administration

Coverage Level

Supporting and limited.

Covered By

·        Direct coverage only where the activity satisfies an implemented scheduled-task or destructive-system rule

·        Supporting endpoint and SIEM visibility

·        Supporting NDR and YARA context

Coverage Summary

No surviving S25 rule directly covers the complete process, service, Registry, firewall, and system-administration capability set.

Administrative activity may strengthen correlation but does not independently satisfy the implemented rules unless it performs a directly covered behavior.

Residual Gap

Broader system administration may occur without triggering a surviving S25 rule.

External File Transfer and Object-Storage Activity

Coverage Level

Supporting and limited.

Covered By

·        Supporting endpoint and SIEM visibility

·        Supporting network anomaly context

·        Supporting YARA context

Coverage Summary

No surviving S25 rule directly detects MinIO execution, alias creation, object-storage credential use, file upload, file download, or successful exfiltration.

File-transfer capability does not prove that sensitive data was successfully transferred.

Residual Gap

Approved storage destinations, alternate transfer tools, encrypted traffic, missing command lines, unavailable object-access logs, and missing transfer outcomes may prevent detection.

Physical-Drive, Disk, and Partition Destruction

Coverage Level

Strong where command, script-classification, or confirmed control telemetry is available.

Covered By

·        SentinelOne through Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

·        Splunk through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Elastic through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        QRadar through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Sigma through Destructive Windows Disk Recovery Backup or Evidence Degradation

·        Supporting YARA artifact coverage

Coverage Summary

The rules detect physical-drive references, supported destructive commands, classified destructive DiskPart scripts, and confirmed disk or partition state changes where the required telemetry is available.

DiskPart process creation or /s execution alone does not prove destructive disk activity.

Residual Gap

Direct API, driver, kernel-level, in-memory, interactive, or unobserved disk destruction may evade command-based detection.

Destructive activity may complete before alerting or isolation.

Recovery, Boot, Backup, and Evidence Degradation

Coverage Level

Strong where supported command-line or confirmed state-change telemetry is available.

Covered By

·        SentinelOne through Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

·        Splunk through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Elastic through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        QRadar through Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        Sigma through Destructive Windows Disk Recovery Backup or Evidence Degradation

·        Supporting YARA artifact coverage

Coverage Summary

The rules provide command-observed coverage for supported shadow-copy, backup-catalog, recovery, boot, and event-log operations.

Splunk, Elastic, QRadar, and Sigma also support confirmed control-event coverage where required state-change telemetry is available.

Ordinary restart or shutdown activity does not independently satisfy the destructive rules.

Residual Gap

Direct API activity, renamed utilities, obfuscated commands, missing command lines, unavailable outcomes, direct event-log file deletion, and unsupported recovery or boot methods may evade coverage.

High-Volume Destructive File Activity

Coverage Level

Strong where complete file-event attribution, process identity, path fidelity, role-aware thresholds, and approved-workflow mappings are available.

Covered By

·        Splunk through High-Volume Destructive File Transformation With Source Deletion or Rename Activity

·        Elastic through High-Volume Destructive File Rename or Deletion Activity

·        QRadar through High-Volume Destructive File Rename or Deletion Activity

·        Sigma through High-Volume Destructive File Rename or Deletion Activity

·        Supporting YARA artifact coverage

Coverage Summary

The rules identify high-volume file transformation, rename, replacement, or deletion activity associated with a responsible process.

Splunk supports broader transformation coverage with source deletion or rename requirements.

Elastic, QRadar, and Sigma focus on high-volume rename or deletion activity.

Residual Gap

Slow, selective, distributed, multi-process, below-threshold, or poorly attributed file destruction may evade coverage.

Detection may occur after files have already been damaged.

GigaWiper Artifact Identification

Coverage Level

Strong for supported artifact conditions.

Covered By

·        YARA through GigaWiper Backdoor and Embedded Destructive Modules

Coverage Summary

The YARA rule identifies recoverable PE files retaining the required combination of documented implementation and operational anchors.

The rule does not prove execution, persistence, command-and-control, file transfer, destructive completion, or actor attribution.

Residual Gap

Packed, stripped, encrypted, modified, incomplete, memory-only, or substantially rebuilt artifacts may evade detection.

Standalone wiper modules that do not retain the required backdoor anchors may not match.

Coverage by Detection System

NDR / Network Behavioral Analytics

Coverage Level

Strong for the implemented network behaviors.

Coverage Summary

NDR provides direct coverage through:

·        Role-Inconsistent RabbitMQ AMQP or Redis Communication

·        Unapproved Windows Endpoint Listener with Remote Session Activity

SentinelOne

Coverage Level

Strong for the implemented GigaWiper-aligned command behaviors.

Coverage Summary

SentinelOne provides direct GigaWiper-aligned coverage through:

·        Scheduled-Task Persistence Command Execution

·        Physical-Drive, Recovery, Boot, Backup, or Evidence-Destruction Command Execution

The User-Context Autorun Registry Persistence Command Execution rule remains generic Windows persistence coverage and is not counted as direct GigaWiper coverage.

SentinelOne does not provide a destructive-file event rule in the completed S25 set.

Splunk

Coverage Level

Strong.

Coverage Summary

Splunk provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Transformation With Source Deletion or Rename Activity

The autorun Registry branches are not counted as direct GigaWiper coverage.

Elastic

Coverage Level

Strong.

Coverage Summary

Elastic provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches are not counted as direct GigaWiper coverage.

QRadar

Coverage Level

Strong where DSM parsing, custom properties, approved-workflow reference data, and CRE implementation are validated.

Coverage Summary

QRadar provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Persistence Establishment Through Scheduled Tasks or Autorun Registry Locations

·        Destructive Disk, Recovery, Boot, Backup, or Evidence-Degradation Activity

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches are not counted as direct GigaWiper coverage.

Sigma

Coverage Level

Strong where the selected backend supports the required event and correlation features.

Coverage Summary

Sigma provides direct GigaWiper-aligned coverage through:

·        The scheduled-task branches of Confirmed Windows Scheduled Task

·        Destructive Windows Disk Recovery Backup or Evidence Degradation

·        High-Volume Destructive File Rename or Deletion Activity

The autorun Registry branches are not counted as direct GigaWiper coverage.

YARA

Coverage Level

Strong for supported artifact conditions.

Coverage Summary

YARA provides direct artifact coverage through GigaWiper Backdoor and Embedded Destructive Modules.

YARA does not observe live network activity, scheduled-task establishment, destructive execution, remote-session behavior, or file-impact volume.

AWS

Coverage Level

No deployable AWS-native coverage.

Coverage Summary

The documented behavior is Windows guest-operating-system based rather than AWS control-plane based.

Azure

Coverage Level

No deployable Azure-native coverage.

Coverage Summary

The documented behavior is Windows guest-operating-system based rather than Azure control-plane based.

GCP

Coverage Level

No deployable GCP-native coverage.

Coverage Summary

The documented behavior is Windows guest-operating-system based rather than Google Cloud control-plane based.

Coverage Strengths

·        Behavior-led coverage independent of one filename, hash, task name, Registry value, extension, disk number, infrastructure address, or campaign label

·        Direct NDR coverage for anomalous RabbitMQ, AMQP, or Redis communication

·        Direct NDR coverage for qualifying unapproved inbound listener and remote-session activity

·        Direct SentinelOne command coverage for scheduled-task persistence and destructive administration

·        Broad Splunk, Elastic, QRadar, and Sigma scheduled-task and destructive-system coverage

·        High-volume destructive-file coverage across Splunk, Elastic, QRadar, and Sigma

·        GigaWiper artifact coverage using multiple independently documented anchors

·        Separation between command-observed activity and confirmed state changes

·        Narrow approved-workflow handling

·        Explicit distinction between direct, supporting, conditional, limited, and unavailable coverage

·        No forced cloud-native rules where the threat model does not support them

Coverage Limitations

·        No standalone rule for generic backdoor execution

·        Registry execution-state tracking is supporting context rather than direct persistence coverage

·        Generic autorun Registry rules retained in S25 are not direct GigaWiper coverage

·        No standalone rule for arbitrary shell or remote-task execution

·        No direct rule for screen capture, screen recording, keyboard control, or mouse control

·        No direct rule for MinIO, object-storage alias creation, credential use, or external file upload

·        No complete direct coverage for broader service, process, Registry, firewall, or system-administration activity

·        No direct rule for direct event-log file deletion

·        No standalone detection for forced crash, reboot, boot failure, or endpoint-health loss

·        Messaging and remote-session traffic may be encrypted, proxied, tunneled, brokered, encapsulated, misclassified, or unavailable

·        Endpoint identity may not map reliably to network addresses

·        Process command lines may be missing, truncated, delayed, obfuscated, or normalized incorrectly

·        Process identity may be unstable, reused, missing, or lost during aggregation

·        Direct API activity may occur without observable commands

·        Interactive or unclassified DiskPart activity may not expose destructive commands

·        Direct driver, kernel-level, in-memory, or renamed-utility execution may bypass command-based detection

·        File events may be incomplete or lack responsible-process attribution

·        Slow or distributed destructive activity may remain below thresholds

·        Security-control degradation may remove evidence needed to confirm later actions

·        Legitimate administration, backup, recovery, imaging, forensic, synchronization, migration, indexing, deployment, remote-support, incident-response, or security-testing activity may resemble malicious behavior

·        Broad allowlists or reference data may suppress malicious use of trusted tools, users, or systems

·        Packed, stripped, encrypted, modified, or incomplete samples may evade YARA

·        The completed package does not establish initial access, credential compromise, privilege escalation, lateral movement, Active Directory compromise, enterprise propagation, cloud-control-plane abuse, virtualization compromise, or actor attribution

Final Coverage Determination

The completed GigaWiper detection package provides strong direct coverage for the threat’s most observable network, scheduled-task persistence, destructive-system, high-volume file-impact, and recoverable artifact behaviors.

NDR / Network Behavioral Analytics provides direct coverage for role-inconsistent RabbitMQ, AMQP, or Redis communication and qualifying unapproved inbound listener and remote-session activity.

SentinelOne provides direct command coverage for scheduled-task persistence and destructive physical-drive, recovery, boot, backup, and evidence-degradation activity.

Splunk, Elastic, QRadar, and Sigma provide direct coverage through their scheduled-task branches, destructive-system rules, and high-volume destructive-file rules.

The autorun Registry branches retained within those broader persistence rules provide generic Windows persistence coverage but are not counted as direct GigaWiper coverage.

The documented GigaWiper Registry location remains supporting execution-state evidence rather than a confirmed persistence mechanism.

YARA provides direct artifact coverage when the required file content remains recoverable and intact.

Coverage remains supporting, limited, or unavailable for generic backdoor execution, Registry execution-state tracking, arbitrary shell tasking, surveillance, remote-input control, object-storage transfer, broader system administration, direct event-log file deletion, forced crash behavior, boot failure, endpoint-health loss, initial access, credential theft, privilege escalation, lateral movement, enterprise propagation, cloud-control-plane abuse, virtualization compromise, and actor attribution.

The final coverage determination is strong for the implemented behaviors but does not represent universal GigaWiper detection, universal Windows backdoor detection, or guaranteed interruption before destructive impact.

S33 Defensive Control & Hardening Improvements

Restrict execution of unknown, unsigned, newly observed, or low-prevalence Windows executables through application control, trusted-application policy, and controlled software-deployment workflows.

Block executable launches from user-writable, temporary, download, staging, and other nonstandard paths unless the activity is explicitly approved.

Require centralized review and approval for scheduled-task creation, modification, and high-frequency or startup-triggered execution.

Maintain an approved scheduled-task inventory by endpoint role, task owner, executable path, signer, trigger, purpose, and authorized change window.

Alert on scheduled tasks that launch uncommon executables, execute from nonstandard paths, recur at unusually short intervals, or are registered through unexpected processes.

Restrict outbound RabbitMQ, AMQP, and Redis communication from Windows endpoints to approved destinations, ports, applications, and asset roles.

Maintain approved RabbitMQ, Redis, and messaging-service dependency inventories by source endpoint, asset role, destination, service family, owner, purpose, and expected communication pattern.

Block RabbitMQ, AMQP, Redis, MinIO, and other object-storage communication to external or otherwise unauthorized destinations unless explicitly required by an approved business workflow.

Restrict inbound listener creation and externally reachable endpoint services to approved remote-support, administration, development, and application workflows.

Maintain an approved inbound-service inventory by endpoint, asset role, process, port, source path, owner, and business purpose.

Centrally manage Windows Firewall rules and alert on unapproved inbound or outbound rule creation, replacement, or modification.

Restrict remote-support, screen-recording, VNC-like remote-interaction, keyboard and mouse control, and interactive administration capabilities to approved software, authorized users, and validated business purposes.

Require process attribution for endpoint network activity so messaging, listener, object-storage, and remote-session behavior can be tied to the responsible executable.

Restrict PowerShell, command-shell, service-control, Registry-administration, and system-management activity through constrained administration, signed scripts, application control, and privileged-access workflows.

Maintain narrow approved inventories for administrative utilities, imaging tools, recovery tools, storage-management tools, forensic tools, backup utilities, remote-support products, and security-testing software.

Do not broadly allowlist Microsoft-signed utilities, administrative users, deployment systems, recovery systems, or trusted software without command, endpoint, user, purpose, and change-window validation.

Restrict raw physical-drive access, partition-control operations, storage-driver installation, and disk-management activity to approved administrators, tools, and maintenance workflows.

Block or alert on access to physical-drive device paths by processes outside approved imaging, recovery, forensic, and storage-management inventories.

Protect Windows recovery settings, Boot Configuration Data, critical boot files, kernel files, shadow copies, and backup catalogs from unauthorized modification or deletion.

Require separate administrative controls for production systems, backup systems, recovery infrastructure, and security tooling so compromise of one administrative plane does not expose all recovery mechanisms.

Maintain offline, immutable, or independently administered backups for critical Windows systems and shared data.

Prevent identities used to administer production endpoints or servers from also administering immutable backup infrastructure.

Test file-level restoration, system-state recovery, bare-metal rebuilding, and critical-service recovery on a defined schedule.

Document recovery time objectives, recovery point objectives, restoration dependencies, responsible owners, and escalation paths for destructive-malware incidents.

Validate that backup copies, recovery media, boot images, configuration baselines, and restoration credentials remain available when production identity or endpoint infrastructure is unavailable.

Retain Windows event logs, EDR telemetry, network metadata, scheduled-task events, Registry events, service events, firewall changes, recovery activity, boot changes, file activity, and endpoint-health data outside the affected endpoint.

Enable centralized Windows event forwarding and remote EDR retention for critical endpoints and servers.

Monitor SIEM ingestion health, endpoint-sensor health, logging-service state, and abrupt telemetry loss.

Alert on event-log clearing, direct event-log file deletion, logging-service interruption, EDR degradation, and sudden endpoint disappearance following administrative or destructive activity.

Enable file-event telemetry with responsible-process attribution for critical servers, shared storage, backup systems, and high-value workstations.

Apply role-aware thresholds for high-volume file creation, modification, rename, replacement, encryption, and deletion activity.

Exclude backup, synchronization, migration, deployment, indexing, encryption, recovery, and administrative workflows only through complete approved-workflow validation.

Preserve artifact hashes, executable metadata, process lineage, command lines, scheduled-task definitions, Registry changes, network destinations, file-impact records, and recovery-state evidence before rebuilding affected systems.

Isolate suspected systems immediately when raw-disk access, partition destruction, recovery disablement, boot sabotage, event-log destruction, or high-volume destructive file activity is detected.

Preauthorize endpoint isolation for security operations when critical destructive conditions are met.

Define emergency containment procedures for systems that cannot be safely isolated without operational, safety, or customer impact.

Review historical scheduled-task activity, messaging traffic, inbound listener activity, object-storage access, destructive administration, and file-impact events during the suspected exposure window.

Rebuild systems from trusted media where system integrity, boot integrity, recovery configuration, administrative activity, or malware removal cannot be proven.

Rotate privileged, service, administrative, remote-support, backup, and recovery credentials associated with affected systems when credential exposure or misuse cannot be excluded.

Validate restored systems against approved software, scheduled-task, service, Registry, firewall, boot, recovery, backup, and network baselines before returning them to production.

Require post-restoration monitoring for recurring scheduled tasks, anomalous messaging traffic, unapproved listeners, destructive commands, file-impact activity, evidence loss, and endpoint-health degradation.

Document destructive-malware response authority, containment thresholds, system-owner responsibilities, legal and regulatory escalation, customer-impact assessment, executive reporting, and recovery acceptance criteria.

Exercise GigaWiper-like scenarios through tabletop and technical simulations covering remote backdoor activity, scheduled-task persistence, destructive disk access, recovery sabotage, boot failure, evidence destruction, and large-scale file loss.

S39 Economic Impact & Organizational Exposure

GigaWiper increases organizational exposure by creating uncertainty about whether an existing Windows compromise progressed from execution into scheduled-task persistence, remote tasking, surveillance, interactive control, system administration, file transfer, evidence reduction, physical-disk destruction, partition damage, irreversible file encryption, recovery disablement, boot sabotage, or endpoint failure.

The governing risk is not limited to one sample, filename, hash, task name, Registry path, Go symbol, infrastructure address, communication port, file extension, destructive module, or threat actor.

The material question is whether an existing endpoint foothold was converted into continuing remote operator control and whether that control enabled destructive activity before containment.

Economic exposure increases when affected Windows systems support production services, identity administration, privileged access, file sharing, backup and recovery, security operations, operational technology, engineering, regulated workloads, customer-facing applications, or other business-critical dependencies.

Exposure is highest when defenders cannot distinguish preparatory activity from confirmed persistence, remote operator access, destructive command execution, raw-disk modification, partition destruction, recovery sabotage, file destruction, evidence loss, or system failure.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed.

The most defensible enterprise estimate depends on whether activity remains limited to suspicious executable execution, scheduled-task persistence, Registry execution-state tracking, unusual RabbitMQ or Redis communication, inbound listener activity, system administration, screen capture, or file transfer; progresses into suspected or confirmed destructive-system activity; or expands into physical-disk destruction, partition loss, broad file destruction, backup impairment, boot failure, evidence loss, production disruption, customer impact, or multi-system rebuilding.

Economic exposure increases when the organization cannot quickly determine:

·        Whether the implant executed successfully

·        Whether scheduled-task persistence was established

·        Whether Registry execution-state tracking occurred

·        Whether remote tasking occurred

·        Whether an operator used interactive control

·        Whether screenshots or recordings were captured

·        Whether keyboard or mouse control was used

·        Whether files were transferred externally

·        Whether raw physical-drive access occurred

·        Whether partition metadata changed

·        Whether recovery was disabled

·        Whether backup catalogs or shadow copies were deleted

·        Whether critical boot or kernel files were changed or removed

·        Whether source files were irreversibly destroyed

·        Whether local evidence was cleared before collection

·        Whether affected systems can be restored or must be rebuilt

·        Whether endpoint, network, file, disk, recovery, boot, backup, event-log, asset, change-control, and incident-response evidence can be joined into a reliable sequence

Low Impact Scenario

Estimated $75K–$500K.

This scenario applies when investigation confirms suspicious executable execution, scheduled-task activity, Registry execution-state tracking, RabbitMQ or Redis communication, listener activity, shell execution, screen capture, file transfer, or system administration without evidence of physical-disk writes, partition destruction, recovery disablement, boot sabotage, high-volume destructive file activity, source-file deletion, event-log destruction, or critical-service interruption.

Available evidence supports a failed, contained, preparatory, or non-impacting event.

The organization can confirm that critical systems were not materially affected, destructive commands did not complete, backups remained intact, recovery controls remained functional, central evidence was preserved, no material customer or production interruption occurred, and affected endpoints can be rebuilt through standard procedures.

Response remains limited to targeted host isolation, malware analysis, evidence preservation, persistence review, network investigation, file-transfer review, credential precaution, endpoint rebuilding, detection tuning, short-term monitoring, and executive assurance that critical operational trust was not materially affected.

Moderate Impact Scenario

Estimated $500K–$5M.

This scenario applies when confirmed or strongly suspected GigaWiper activity affects multiple endpoints or one or more production, administrative, identity-adjacent, file, backup, recovery, security, engineering, operational-technology, or other high-value Windows systems.

Suspicious execution aligns with scheduled-task persistence, remote tasking, unapproved messaging traffic, inbound remote sessions, system administration, recovery-control commands, event-log clearing, destructive file behavior, raw-disk activity, or endpoint failure.

The organization cannot immediately determine whether remote control was used, files were transferred externally, physical-disk modification completed, recovery or backup capability was impaired, file destruction can be reversed, local evidence remains complete, administrative trust remains intact, affected systems require rebuilding, or related systems were exposed through shared dependencies.

Response may require multi-system isolation, process and command reconstruction, network and remote-session analysis, file-transfer investigation, raw-disk and partition review, backup and recovery validation, administrative-access review, credential rotation, system rebuilding, legal and compliance review, customer or partner assessment, cyber-insurance coordination, executive reporting, and strengthened post-restoration monitoring.

High Impact Scenario

Estimated $10M–$75M+.

This scenario applies when GigaWiper becomes an enterprise-impact event involving confirmed or strongly suspected physical-disk wiping, partition destruction, broad irreversible file encryption, source-file deletion, backup or recovery impairment, boot sabotage, event-log destruction, production disruption, customer-service interruption, operational-technology impact, or multi-system compromise.

The organization may need to treat affected endpoints, servers, shared data, backup systems, recovery systems, administrative accounts, remote-support paths, operational dependencies, and connected services as untrusted until reliable evidence proves otherwise.

Response may require enterprise-scale forensic investigation, emergency network and endpoint isolation, broad credential and administrative-access review, large-scale system replacement, bare-metal rebuilding, backup-platform validation, recovery-environment reconstruction, production restoration, customer remediation, contractual response, privacy and regulatory escalation, litigation support, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of endpoint, server, backup, recovery, and operational trust.

Annualized Risk Exposure

Estimated $1M–$12M+.

This estimate applies to materially exposed enterprise environments with recurring Windows threat exposure, production-critical systems, administrative workstations, backup or recovery infrastructure, file servers, operational-technology support systems, incomplete application control, weak raw-disk restrictions, incomplete process lineage, limited file attribution, poor asset-role mapping, short telemetry retention, or concentrated operational dependencies.

Exposure may exceed $12M and approach the high-impact scenario when suspected or confirmed GigaWiper activity results in physical-disk destruction, partition loss, broad file destruction, backup or recovery impairment, boot failure, extended production interruption, customer-service loss, operational-technology impact, multi-system rebuilding, incomplete containment, legal escalation, communications response, cyber-insurance review, or board-level reporting.

Operational Dependency

Operational dependency is high where Windows systems support production applications, customer services, identity administration, privileged access, shared storage, backup and recovery, security operations, engineering workflows, operational technology, regulated services, business-critical administration, remote management, or other systems that cannot be isolated or rebuilt without disruption.

Even one affected system can create broad investigation and recovery requirements when it administers downstream assets, stores shared data, holds backup authority, supports identity operations, manages security controls, or connects to multiple production environments.

Dependency increases when the affected system cannot be isolated, restarted, rebuilt, replaced, or removed from service without operational impact.

Dependency is highest when a small number of Windows systems concentrate administrative, recovery, production, or customer-service functions.

Control Trust

Control trust is reduced when the organization cannot prove that process execution, scheduled tasks, Registry activity, services, firewall policy, recovery configuration, boot configuration, critical operating-system files, event logs, backup catalogs, shadow copies, security controls, remote sessions, and raw-disk activity remained authorized and reliable during the activity window.

The documented GigaWiper persistence mechanism is scheduled-task execution. Its documented Registry activity supports execution-state tracking rather than confirmed persistence.

The S25 autorun Registry rules remain valid behavior-based compensating coverage for broader Windows persistence activity, but they are not treated as direct detection of GigaWiper’s documented Registry behavior.

Trust is further reduced when suspicious execution originated from a user-writable or nonstandard path, when an uncommon process created persistence, when the endpoint communicated through unapproved messaging infrastructure, when an unapproved listener accepted remote sessions, or when destructive administration occurred without complete approved-change context.

A trusted signer, native Windows utility, approved administrative account, known protocol, or recognized endpoint must not independently suppress qualifying destructive behavior.

A system that has been wiped, partially overwritten, made unbootable, or stripped of local evidence may require known-good rebuilding rather than ordinary malware removal.

Visibility Confidence

Visibility confidence is highest when Windows process, parent-process, command-line, file, Registry, scheduled-task, service, firewall, PowerShell, WMI, network, raw-device, disk, partition, recovery, boot, backup, event-log, endpoint-health, YARA, asset, and change-control evidence can be correlated through stable endpoint and process identities.

Visibility confidence is reduced when process ancestry is incomplete, command lines are missing or truncated, process identity is unstable, file events lack responsible-process attribution, Registry or scheduled-task outcomes are not captured, raw-device or partition telemetry is unavailable, inbound-session results cannot distinguish accepted from blocked activity, network protocols are encrypted or misclassified, asset roles are missing, approved dependencies are incomplete, approved workflows are stale, local logs are destroyed before forwarding, EDR sensors fail before remote retention, or retention is insufficient to reconstruct the pre-destruction activity window.

S25 depends on validated endpoint identity, process lineage, command normalization, persistence-target mapping, network-service classification, destination prevalence, asset-role baselines, approved dependencies, approved-workflow context, file-event attribution, destructive-control outcomes, and bounded-time correlation.

The behavior rules do not depend on one malware name, filename, hash, task name, Registry value, extension, disk number, infrastructure address, or campaign label.

The YARA rule is deliberately narrower because it provides artifact coverage through multiple implementation and operational anchors.

Change-Control Confidence

Change-control confidence is high when scheduled-task deployment, Registry modification, service administration, firewall changes, disk imaging, partition maintenance, backup administration, recovery operations, boot-configuration changes, security testing, incident response, software deployment, and remote-support activity can be tied to complete and time-bounded authorization records.

Confidence is reduced when approvals are incomplete, stale, overly broad, normalized differently from monitoring data, or based only on an endpoint, user, utility, signer, or maintenance window.

A complete approved-workflow match should include the endpoint, responsible user or service account, process or utility, command or target, action, and authorized time context.

Null, empty, incomplete, or unrecognized approval states should remain eligible for investigation rather than silently suppressing activity.

Downstream Dependency

A compromised Windows system may create downstream exposure even when GigaWiper does not automatically propagate.

Dependency risk may arise from:

·        Shared files and storage

·        Application hosting

·        Administrative trust

·        Backup relationships

·        Synchronization

·        Service dependencies

·        Production scheduling

·        Identity services

·        Remote-management relationships

·        Security-management relationships

·        Operational-technology support functions

·        Access to additional customer or production environments

The organization must determine whether affected endpoints administered, authenticated to, synchronized with, backed up, restored, monitored, or otherwise influenced downstream systems during the activity window.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when GigaWiper affects regulated data, customer-facing systems, partner-facing services, workforce authentication systems, shared file services, production platforms, backup infrastructure, recovery systems, administrative systems, operational technology, or systems holding sensitive credentials or records.

Exposure also increases when telemetry gaps prevent timely confirmation of whether protected data was viewed, files were transferred, records were altered or destroyed, production integrity changed, services became unavailable, recovery controls failed, containment was complete, or required security safeguards remained effective.

Malware detection alone does not establish a notification obligation.

Legal and compliance teams must evaluate the actual systems, data, jurisdictions, contracts, interruption duration, operational consequences, and available evidence.

Residual Economic Risk

Residual economic risk remains after malware removal, process termination, host isolation, credential rotation, network blocking, system restoration, or endpoint rebuilding when the pre-remediation activity window cannot be reconstructed.

Removing the implant does not prove that scheduled-task persistence was never established, remote tasking did not occur, screens were not captured, keyboard or mouse control was not used, files were not transferred, system settings were not altered, physical-drive writes did not occur, partition metadata remained intact, recovery remained enabled, backups remained trustworthy, files remained recoverable, logs remained complete, destructive commands failed, or related systems were unaffected.

Residual risk should remain elevated until historical endpoint, network, file, disk, partition, recovery, boot, backup, event-log, asset, change-control, incident-response, and restoration evidence has been reviewed.

Behavioral Coverage Assessment

The completed S25 package provides behavior-led coverage for the most observable GigaWiper persistence, network, destructive-system, destructive-file, and artifact behaviors.

Implemented direct or strongly aligned coverage includes:

·        Role-inconsistent RabbitMQ, AMQP, or Redis communication

·        Qualifying unapproved inbound listener and remote-session activity

·        Scheduled-task persistence

·        Physical-drive references and destructive administration commands

·        Confirmed disk or partition destruction where required telemetry exists

·        Recovery disablement

·        Destructive boot-configuration activity

·        Backup-catalog and shadow-copy degradation

·        Windows event-log clearing

·        High-volume destructive file rename, deletion, replacement, or transformation

·        Recoverable GigaWiper PE artifacts retaining the required YARA anchors

Implemented broader behavior-based compensating coverage includes:

·        User-context autorun Registry persistence

That Registry rule family remains valid for detecting durable Windows persistence behavior but does not directly detect GigaWiper’s documented Registry execution-state tracking.

Coverage remains limited or supporting for:

·        Generic backdoor execution

·        Registry execution-state tracking

·        Arbitrary shell and remote-task execution

·        Screen capture and recording

·        Keyboard and mouse control

·        External file transfer

·        Object-storage use

·        Broader process, service, Registry, and firewall administration

·        Direct event-log file deletion

·        Forced crash behavior

·        Reboot

·        Boot failure

·        Endpoint-health loss

The package does not directly cover initial access, credential theft, privilege escalation, lateral movement, Active Directory compromise, automatic enterprise propagation, cloud-control-plane abuse, virtualization-layer compromise, or actor attribution.

Detection Engineering Coverage Interpretation

Detection confidence is strongest when independent evidence converges across endpoint, network, persistence, file, disk, recovery, boot, backup, event-log, and artifact telemetry.

A single generic behavior does not independently establish GigaWiper.

Examples that require additional context include:

·        PowerShell execution

·        Scheduled-task creation

·        Registry modification

·        RabbitMQ traffic

·        Redis traffic

·        Screen capture

·        Service administration

·        Firewall changes

·        Event-log clearing

·        File encryption

·        Disk administration

·        Object-storage use

Confidence increases when the same endpoint, process identity, user, or process lineage produces multiple relevant behaviors outside an approved workflow.

The endpoint, NDR, SIEM, and Sigma rules identify durable behavior rather than a malware family by name.

The YARA rule provides narrowly scoped artifact coverage. A YARA match does not prove execution, successful destruction, or actor attribution.

Cloud-hosted Windows guest systems remain eligible for endpoint, SIEM, NDR, Sigma, and YARA coverage when the required guest-operating-system telemetry is collected.

AWS, Azure, and GCP do not receive separate cloud-native detection rules because the documented activity occurs within the Windows guest operating system rather than through cloud-control-plane APIs.

Non-Coverage Conditions

Reliable coverage is unavailable or materially reduced when activity does not produce an implemented persistence, network, destructive-system, destructive-file, or artifact condition.

Non-coverage applies when activity remains limited to:

·        Generic backdoor execution without implemented follow-on behavior

·        An uncommon executable without additional qualifying behavior

·        Registry execution-state tracking without correlated qualifying activity

·        Arbitrary shell execution outside an implemented rule

·        Remote tasking without qualifying process or network evidence

·        Screen capture or recording without implemented telemetry or correlation

·        Keyboard or mouse control without remote-input visibility

·        File transfer without sufficient destination, path, process, or outcome evidence

·        Broader process, service, Registry, firewall, discovery, or system administration outside implemented rules

·        Direct API or in-memory activity without command or state-change telemetry

·        Interactive DiskPart activity without script-content or resulting-state visibility

·        Direct driver or kernel activity without low-level storage telemetry

·        Slow, selective, distributed, or below-threshold file destruction

·        Forced crash, reboot, boot failure, or endpoint-health loss without correlated destructive evidence

·        Stripped, packed, encrypted, incomplete, rebuilt, memory-only, or substantially modified artifacts that lack the YARA anchors

·        Standalone wiper samples that do not retain the required backdoor-specific YARA anchors

·        Environments where endpoint identity, process identity, command lines, file attribution, network classification, asset roles, approved dependencies, approved workflows, destructive-control outcomes, or required retention are unavailable

Detection does not guarantee interruption when disk wiping, boot sabotage, or destructive file activity completes before collection and response controls can act.

Detection does not guarantee restoration after physical-disk overwriting, partition destruction, recovery disablement, boot-file deletion, or irreversible file encryption.

Coverage Qualification

Coverage is strongest where endpoint identity, process identity, process lineage, user context, persistence target, command line, event outcome, network behavior, destructive target, file-impact breadth, asset role, approved-workflow context, and artifact evidence can be joined into one bounded sequence.

Coverage is weaker for generic backdoor execution, Registry execution-state tracking, direct API activity, in-memory execution, missing command lines, missing process identity, incomplete file attribution, unavailable raw-device telemetry, encrypted or tunneled communication, shared egress, missing asset-role context, incomplete approved-dependency data, missing screen or remote-input telemetry, short-lived destructive activity, evidence destruction before forwarding, slow or distributed file impact, packed or modified artifacts, and cloud-hosted systems without guest telemetry.

The report does not claim:

·        Universal GigaWiper detection

·        Universal Windows backdoor detection

·        Universal wiper detection

·        Universal ransomware detection

·        Universal remote-access detection

·        Universal raw-disk detection

·        Complete screen-capture detection

·        Complete keyboard or mouse-control detection

·        Complete object-storage transfer detection

·        Complete destructive-file detection

·        Complete cloud-hosted Windows detection without guest telemetry

·        Initial-access coverage

·        Credential-compromise coverage

·        Lateral-movement coverage

·        Enterprise-propagation coverage

·        Actor attribution

Detection confidence depends on telemetry completeness, field mapping, process-lineage integrity, endpoint identity, asset inventory, role-aware baselines, approved dependencies, approved workflows, query validation, retention, performance testing, false-positive testing, and SOC readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when GigaWiper creates uncertainty about whether endpoint, server, data, backup, recovery, administrative, security, and operational trust remained intact.

The strategic risk is not only that a GigaWiper binary, hash, task name, Registry artifact, infrastructure address, Go symbol, or file extension exists.

The material risk is that an adversary may have converted an existing Windows foothold into persistent remote control, observed user activity, administered system functions, transferred files, weakened defensive evidence, destroyed physical-disk or partition data, disabled recovery, sabotaged boot capability, irreversibly destroyed files, or interrupted critical operations.

The completed detection package materially improves visibility into the most observable persistence, messaging, inbound-session, destructive-system, destructive-file, and artifact behaviors.

Residual exposure remains significant because generic backdoor execution, arbitrary tasking, surveillance, remote input, broader administration, object-storage transfer, direct API activity, low-level disk access, rapid destructive execution, and local evidence loss may occur before detection and containment.

Organizational resilience ultimately depends on rapid isolation authority, remotely retained telemetry, application control, restricted destructive administration, independently protected backups, known-good rebuilding capability, and tested destructive-malware recovery procedures.

S40 References

Primary Technical Analysis

Microsoft Threat Intelligence — GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware
hxxps://www.microsoft[.]com/en-us/security/blog/2026/07/09/gigawiper-anatomy-of-a-destructive-backdoor-assembled-from-multiple-malware/

Malware Detection and Classification

Microsoft Security Intelligence — DoS:Win32/GigaWiper.A!dha
hxxps://www.microsoft[.]com/en-us/wdsi/threats/malware-encyclopedia-description?Name=DoS%3AWin32%2FGigaWiper.A%21dha

Threat Technique Framework

MITRE ATT&CK Framework — Enterprise Matrix
hxxps://attack.mitre[.]org/matrices/enterprise/