[MAL] Detection Strategy Overview Dragon Boss Signed Adware (Unidentified Malware)
Report Type: Malware / Intrusion Activity (Behavioral Detection Report)
Threat Category: Access Acquisition / Persistence Establishment
Assessment Date: April 19, 2026
Primary Impact Domain: Endpoint Compromise and Persistent Unauthorized Access
Secondary Impact Domains: Credential Access; Lateral Movement; Command and Control; Operational Disruption (Potential)
Affected Asset Class: Enterprise Endpoints (Windows Systems)
Threat Objective Classification: Initial Foothold Establishment and Access Persistence (Potential Initial Access Broker Activity)
BLUF
S2 — BLUF
Dragon Boss Signed Adware (unidentified malware) presents a high-confidence enterprise intrusion risk because it disables security controls and establishes persistent system access that enables follow-on compromise. The technical risk is driven by defense evasion combined with durable persistence mechanisms, specifically scheduled tasks and WMI subscriptions, which remain effective regardless of payload, certificate, or infrastructure changes. The current threat posture indicates a proven ability to establish footholds with credible escalation pathways into credential access, lateral movement, and secondary payload deployment such as ransomware. Immediate executive action is required to enforce telemetry completeness, prioritize persistence-based detection, and ensure rapid containment before attackers transition to higher-impact stages.
Executive Risk Translation
· This threat establishes long-term access rather than causing immediate visible damage.
· The initial infection is not the primary business risk.
· The primary risk is persistent attacker access after installation.
· Persistent access enables ransomware deployment, data theft, and lateral movement.
· Failure to detect persistence early significantly increases financial and operational impact.
S3 — Why This Matters Now
· The campaign uses behavior patterns that reduce the effectiveness of signature-based and reputation-based defenses.
· Persistence mechanisms observed are low-noise and blend with legitimate system activity.
· Security control impairment reduces the likelihood of detecting follow-on attacker activity.
· The behavior aligns with initial access broker and pre-ransomware staging patterns.
· Most enterprise environments lack complete WMI visibility and process-to-network correlation, increasing exposure to this threat.
· Organizations lacking endpoint visibility and correlation capability have material detection gaps.
· Delayed detection allows attacker access to persist, expand, and be reused or monetized.
S4 — Key Judgments
· The campaign is behavior-driven and resilient to indicator-based detection.
· Security control impairment is a high-confidence malicious signal with low benign overlap.
· Persistence creation is the most reliable detection anchor across environments.
· Execution activity alone does not provide sufficient detection confidence.
· Detection success depends on telemetry completeness and correlation capability.
· Cloud-native telemetry does not provide viable primary detection coverage for this campaign.
· The threat profile is consistent with early-stage intrusion activity preceding high-impact attacks.
S5 — Executive Risk Summary
Business Risk
· Persistent unauthorized access enables data theft.
· Persistent unauthorized access enables ransomware deployment.
· Persistent unauthorized access enables operational disruption.
· Increased attacker dwell time expands the scope of compromise.
· Increased attacker dwell time increases recovery cost and complexity.
· Extended compromise increases regulatory and reputational exposure.
Technical Cause
· Security controls are weakened or disabled by the threat.
· Persistence is established through scheduled tasks and WMI mechanisms.
· The threat operates independently of static indicators such as file hashes or domains.
· Legitimate system functionality is used to maintain access.
Threat Posture
· Confirmed capability for foothold establishment is present.
· Likely progression includes remote access enablement and credential access.
· Possible progression includes lateral movement and data staging.
· Detection difficulty increases significantly after persistence is established.
Executive Decision Requirement
· Enforce a minimum viable telemetry baseline across endpoints.
· Prioritize detection of security control impairment and persistence creation.
· Ensure rapid host isolation capability following high-confidence alerts.
· Treat telemetry gaps as business risk exposure.
S6 — Executive Cost Summary
Low Impact Scenario
· Detection occurs at or before persistence establishment.
· Compromise is limited to a small number of systems.
· No credential exposure or lateral movement occurs.
· Impact is limited to investigation and endpoint remediation.
· Estimated Cost Range: $50,000 to $150,000.
Moderate Impact Scenario (Most Likely)
· Detection occurs after persistence is established but before full lateral movement.
· Limited credential exposure or short-duration attacker access occurs.
· Containment requires multi-host remediation and expanded investigation.
· Business disruption is localized but non-trivial.
· Estimated Cost Range: $300,000 to $1,000,000.
High Impact Scenario
· Persistence remains undetected long enough to enable lateral movement or ransomware staging.
· Credential compromise and multi-system access are established.
· Data exposure, operational disruption, or ransomware deployment occurs.
· Regulatory, legal, and recovery costs significantly increase total impact.
· Estimated Cost Range: $1,000,000 to $5,000,000+.
S6A — Key Cost Drivers
· Time between persistence establishment and detection.
· Number of systems affected before containment.
· Extent of credential exposure or misuse.
· Sensitivity of impacted systems and data.
· Availability and quality of telemetry and correlation.
· Speed and effectiveness of incident response.
· Regulatory obligations triggered by compromise.
S6B — Compliance and Risk Context
Compliance Exposure Indicator
· Moderate to High.
· Exposure increases if regulated or sensitive data is accessed.
Risk Register Entry
Risk Title
· Persistent Foothold via Defense Evasion and Scheduled/WMI Persistence
Risk Description
· Adversaries weaken defenses and establish durable persistence, enabling ongoing unauthorized access and increasing the likelihood of follow-on compromise including credential access, lateral movement, ransomware, or data theft.
Likelihood
· High
Impact
· High
Risk Rating
· Critical
Annualized Risk Exposure
· $500,000 to $2,000,000
S7 — Risk Drivers
· Incomplete command-line and process telemetry.
· Lack of WMI visibility.
· Weak or missing scheduled task telemetry.
· Inability to correlate execution, persistence, and network activity.
· Over-reliance on signature-based detection.
· Delayed response to persistence-related alerts.
· Inconsistent endpoint logging coverage.
· Lack of tuned allowlists for administrative activity.
S8 — Bottom Line for Executives
· This threat creates risk through persistent access rather than immediate disruption.
· Organizations that cannot detect persistence and defense evasion will not detect this campaign early.
· Early detection and containment are the most important control objectives.
· Executive focus must prioritize telemetry completeness, persistence detection capability, and rapid containment readiness.
S9 — Board-Level Takeaway
· The organization faces a high-probability, high-impact risk from persistent foothold attacks.
· Traditional detection approaches are insufficient against behavior-driven threats.
· Investment must prioritize endpoint visibility, behavioral detection, and rapid containment capability.
· Failure to address these gaps increases the likelihood of a major cyber incident with significant financial and operational impact.
Figure 2
S10 — Threat Overview
· Dragon Boss Signed Adware (unidentified malware) is a malware-enabled intrusion threat focused on establishing persistent access within enterprise environments.
· The threat weakens defensive controls and uses legitimate system functionality to maintain long-term access.
· The primary enterprise risk is the establishment of a durable foothold that enables follow-on compromise rather than the initial execution event.
S11 — Threat Classification and Type
Threat Type
· Malware-enabled intrusion
Threat Sub-Type
· Signed adware used for unauthorized foothold establishment
Operational Classification
· Initial access and persistence-enabling intrusion activity
Primary Function
· Establish durable access while reducing defensive visibility to support follow-on operations
S12 — Campaign or Activity Overview
· The activity begins with execution of a signed binary or equivalent payload on a target endpoint.
· Following execution, the threat impairs or weakens security controls to reduce detection capability.
· Persistence is established through scheduled tasks, WMI event subscription mechanisms, or both.
· After persistence is achieved, outbound communication enables continued operator access.
· The activity represents early-stage intrusion behavior that enables later credential access, lateral movement, or ransomware deployment.
S13 — Targets and Exposure Surface
· Primary exposure exists on Windows endpoints and servers capable of executing user or administrative processes.
· Most enterprise environments lack complete WMI visibility and process-to-network correlation, increasing exposure to this threat.
· Exposure increases where command-line, WMI, and scheduled task telemetry are incomplete or not collected.
· Exposure increases where endpoint and network activity cannot be reliably correlated on the same host.
· Organizations with inconsistent endpoint visibility or fragmented logging coverage are at higher risk.
· The threat operates effectively across standard enterprise environments without requiring specialized target conditions.
S14 — Sectors / Countries Affected
Sectors Affected
· Cross-sector exposure
· Technology
· Financial services
· Healthcare
· Manufacturing
· Professional services
Countries Affected
· Global exposure
· North America
· Europe
· Asia-Pacific
S15 — Adversary Capability Profiling
Capability Level
· Moderate to High
Technical Sophistication
· Moderate
· Relies on effective use of native system functionality rather than complex exploitation
Infrastructure Maturity
· Low to Moderate
· Does not depend on stable or highly specialized infrastructure
Operational Scale
· Moderate
· Capable of operating across multiple organizations
Escalation Likelihood
· High
· Foothold establishment supports credible progression into credential access, lateral movement, and ransomware staging
S16 — Targeting Probability Assessment
Overall Targeting Probability
· High
Targeting Drivers
· Incomplete endpoint telemetry
· Lack of WMI and scheduled task visibility
· Weak correlation between host and network activity
· Reliance on signature-based detection
· Delayed detection and containment capability
Most Likely Targets
· Organizations with incomplete endpoint logging
· Environments without reliable WMI or scheduled task monitoring
· Enterprises with inconsistent endpoint visibility across their fleet
· Organizations with lower detection engineering maturity
S17 — MITRE ATT&CK Chain Flow Mapping
Initial Access / Execution
· Establishes initial code execution through user-triggered payload execution, enabling all subsequent activity in the intrusion chain.
· T1204.002 — User Execution: Malicious File
Execution Support
· Provides native scripting capability to support follow-on actions such as configuration changes and persistence setup, acting as a supporting execution mechanism rather than the primary behavioral anchor.
· T1059.001 — Command and Scripting Interpreter: PowerShell
Defense Evasion
· Weakens or disables protective controls prior to or during persistence establishment, reducing detection visibility and increasing the likelihood of successful foothold retention.
· T1562.001 — Impair Defenses: Disable or Modify Tools
Persistence
· Establishes durable access through scheduled task execution, enabling repeated or delayed execution across system restarts and user sessions.
· T1053.005 — Scheduled Task/Job: Scheduled Task
· Establishes stealthier persistence through WMI event subscription mechanisms, reducing visibility in environments lacking WMI telemetry coverage.
· T1546.003 — Event Triggered Execution: WMI Event Subscription
Command and Control
· Maintains outbound connectivity to attacker-controlled infrastructure, enabling remote tasking and continued intrusion activity after persistence is established.
· T1071 — Application Layer Protocol
· Supports fallback or rotating communication behavior to maintain connectivity if primary infrastructure is disrupted, increasing resilience of command-and-control channels.
· T1568 — Dynamic Resolution
Credential Access (Likely)
· Enables credential acquisition following foothold establishment, supporting privilege escalation and broader environment access consistent with post-compromise progression.
· T1003 — OS Credential Dumping
Lateral Movement (Possible)
· Expands attacker access across systems using remote administration channels after credentials or access tokens are obtained.
· T1021 — Remote Services
Impact (Possible)
· Converts persistent access into operational or financial impact, including ransomware-style disruption or data impact scenarios.
· T1486 — Data Encrypted for Impact
S18 — Attack Path Narrative (Signal-Aligned Execution Flow)
· The intrusion begins when a signed or trusted-appearing binary executes on a target endpoint, allowing the threat to operate under conditions that reduce immediate suspicion.
· Following execution, the threat weakens or impairs security controls, reducing defensive visibility during the foothold-establishment phase.
· After defensive resistance is reduced, persistence is established through scheduled task creation, WMI event subscription, or both, converting the initial compromise into retained access.
· Once persistence is in place, outbound communication enables continued operator connectivity and supports follow-on tasking.
· The presence of both persistence activity and outbound communication reflects continued attacker access following initial compromise.
· In likely progression scenarios, the foothold is used to support credential access and privilege expansion.
· In possible escalation scenarios, the intrusion advances into lateral movement, broader environment access, and preparation for ransomware or data impact activity.
· The strongest detection opportunities occur during security control impairment and persistence establishment, where the threat must generate durable and observable behavior.
S19 — Attack Chain Risk Amplification Summary
· Security control impairment amplifies risk by reducing detection effectiveness during the earliest stages of the intrusion.
· Persistence establishment amplifies risk by converting a transient compromise into durable attacker access.
· Durable access increases attacker dwell time, allowing progression without repeated re-entry.
· Outbound communication amplifies risk by enabling sustained operator interaction and flexible timing of follow-on actions.
· Once persistence is established prior to detection, the likelihood of credential access, lateral movement, and broader compromise increases materially.
· Risk accumulates across stages, with each successful step increasing the operational value of the intrusion.
· Weak telemetry or poor correlation at any stage increases the likelihood that the attack progresses undetected.
· The most significant amplification point occurs at the transition from execution to retained foothold.
Figure 3
S20 — Tactics, Techniques, and Procedures
· The threat prioritizes execution methods that blend with normal user or system activity rather than relying on exploit-driven entry.
· Defense evasion is applied early to reduce resistance during foothold establishment and improve persistence success.
· The threat prioritizes persistence approaches that are reliable, low-noise, and compatible with standard enterprise system behavior.
· The threat favors persistence methods that do not require continuous re-execution of the original payload.
· Activity is structured to minimize noise by avoiding unnecessary or high-frequency actions during initial compromise.
· Outbound communication is typically initiated after persistence is established, reducing early-stage detection opportunities.
· The intrusion model supports delayed or staged progression, allowing separation between initial compromise and follow-on activity.
· The threat relies on behavioral consistency rather than static artifacts, enabling adaptation without significant redesign.
· The use of legitimate system functionality creates overlap with administrative activity, complicating detection.
· The approach emphasizes survivability and flexibility, allowing the attacker to return, escalate, or pivot based on opportunity.
S20A — Adversary Tradecraft Summary
· The adversary prioritizes reliable foothold establishment over immediate disruption or visible impact.
· Tradecraft focuses on weakening defenses, retaining access, and preserving operational flexibility.
· The threat uses legitimate system functionality to reduce detection likelihood and maintain low operational noise.
· Persistence mechanisms are selected for durability and consistency rather than novelty.
· The intrusion model supports staged escalation, allowing the adversary to expand access based on environment conditions.
· This tradecraft is consistent with intrusion activity that precedes monetization stages such as ransomware or data theft.
· Overall effectiveness is driven by behavioral reliability, survivability, and adaptability rather than technical complexity.
S21 Detection Strategy Overview Dragon Boss Signed Adware (Unidentified Malware)
Detection Approach
· Detection is behavior-first and anchored to observable execution, persistence, defense evasion, and network communication behaviors
· Detection does not rely on malware family attribution, file hashes, signer identity, or domain reputation as primary signals
· Detection logic is designed to remain effective if the adversary changes payload, signing status, execution method, or infrastructure
· Detection focuses on correlated behavior sequences rather than standalone events
Detection Objectives
· Detect execution activity followed by persistence establishment within the same host activity sequence
· Detect security control impairment including stopping, disabling, or modifying antivirus and endpoint protection services
· Detect persistence creation through WMI event subscription activity and scheduled task creation or modification
· Detect outbound communication following execution or persistence activity indicating command-and-control initiation
· Detect correlation between host-based activity and network-based activity within the same host activity sequence
Behavioral Detection Anchors
· Process execution followed by scheduled task creation within the same host activity sequence
· Process execution followed by WMI event filter, consumer, or binding creation on the same host within the same host activity sequence
· Security control impairment through service stop, disable, or configuration modification actions affecting antivirus or endpoint protection
· Scheduled task registration or modification initiated by processes outside expected administrative or software update contexts
· WMI persistence objects created on systems where such activity is not part of baseline administrative operations
· Repeated outbound connections from a host to the same external destination or small destination set at consistent intervals
· DNS resolution followed by outbound connection attempts to multiple destinations in sequence, indicating fallback communication behavior
· Host execution activity followed by persistence creation and outbound communication within the same host activity sequence
Stage-Based Detection Strategy (Unidentified Malware Handling)
Stage Definition Enforcement
· Observed activity is limited to behavior confirmed by telemetry evidence
· Likely activity is limited to behavior supported by observed campaign patterns and established post-compromise progression
· Possible activity is limited to plausible follow-on behavior not yet confirmed by telemetry
Stage 1 Observed
· Execution of Dragon Boss signed binaries in the infection chain
· Security control impairment affecting antivirus or endpoint protection
· WMI persistence creation
· Scheduled task creation or modification
· Outbound beaconing behavior to campaign infrastructure following execution or persistence
Stage 2 Likely
· Deployment of remote access capability following persistence establishment and outbound control traffic
· Credential access activity based on established post-compromise behavioral patterns
· Expansion of outbound communication to additional attacker-controlled infrastructure after initial beaconing
Stage 2 Possible
· Lateral movement through remote administration protocols or file-sharing mechanisms
· Data staging or collection activity preceding exfiltration
· Ransomware precursor activity including privilege expansion and environment discovery
Detection Prioritization
· Prioritize security control impairment and persistence creation as primary anchors due to resistance to evasion and high detection value
· Prioritize correlation of execution, persistence, and outbound communication within the same host activity sequence
· Prioritize detection logic that remains valid if binaries, domains, or certificates change
· Deprioritize standalone indicators not supported by correlated behavior
Operational Detection Goal
· Identify and contain initial foothold activity before transition to secondary payloads or monetization stages
· Reduce attacker dwell time by correlating execution, persistence, and command-and-control behavior
· Maintain detection capability under conditions where attribution, infrastructure, or payload characteristics change
S22 Primary Detection Signals
Execution Signals
· Process execution from user-writable or non-standard directories including temporary folders, download paths, or user profile locations
· Process execution initiating child processes not aligned with expected application or software update behavior
Defense Evasion Signals
· Service control events indicating stop, disable, or configuration modification actions targeting antivirus or endpoint protection services
· Security product state changes where protection is disabled or downgraded outside approved administrative workflows
Persistence Signals
· Creation of WMI event filters, consumers, or bindings on endpoints where such activity is not part of baseline operations
· Scheduled task creation, modification, or activation associated with processes not aligned to expected administrative or software update activity
Command-and-Control Signals
· Repeated outbound connections from a host to the same external destination or a small rotating set of destinations at consistent intervals
· DNS resolution followed by outbound connection attempts to multiple domains in sequence, indicating fallback communication behavior
· Outbound network connections initiated after execution or persistence activity within the same host activity sequence
Correlation Signals
· Process execution followed by persistence creation within the same host activity sequence
· Process execution followed by outbound network communication within the same host activity sequence
· Persistence creation followed by outbound beaconing within the same host activity sequence
· Security control impairment followed by persistence establishment within the same host activity sequence
High-Confidence Composite Signals
· Execution followed by persistence creation followed by outbound communication within the same host activity sequence
· Security control impairment followed by persistence creation followed by outbound communication within the same host activity sequence
· Execution followed by security control impairment followed by persistence creation within the same host activity sequence
Signal Prioritization
· Prioritize correlated multi-event signals over single-event detections
· Prioritize signals involving persistence and defense evasion due to reduced attacker ability to suppress these behaviors
· Deprioritize standalone execution or network signals that are not supported by correlated behavior
Signal Constraints
· Signals must be observable through endpoint and network telemetry without reliance on malware-specific identifiers
· Signals must remain valid under changes to payload, infrastructure, or delivery mechanism
· Signals must be implementable using standard enterprise telemetry without dependency on specialized enrichment systems
S23 Telemetry Requirements
Endpoint
· Process creation telemetry with full parent process, child process, command-line, executable path, user context, integrity level, and signer metadata
· Service control and service state change telemetry capturing stop, disable, reconfiguration, and termination actions affecting antivirus, endpoint protection, or related security services
· WMI telemetry capturing creation of event filters, event consumers, and filter-to-consumer bindings
· Scheduled task telemetry capturing task creation, modification, registration, enablement, and execution context
· File creation and file execution telemetry for binaries launched from user-writable or non-standard execution paths
· Security product state telemetry showing protection disablement, downgrade, tamper status, or policy state change
· Host network connection telemetry linking outbound connections to originating process, destination, protocol, and connection timing
· User and logon context telemetry sufficient to distinguish administrative maintenance activity from user-driven execution activity
Network / DNS
· DNS query telemetry capturing queried domain, requesting host, timestamp, response, and resolution sequence
· Network connection telemetry capturing source host, destination IP, destination port, protocol, connection timing, and recurrence pattern
· Egress telemetry sufficient to identify repeated outbound connections to the same destination or small destination set at consistent intervals
· DNS and network correlation telemetry sufficient to link domain resolution to subsequent outbound connection attempts from the same host
· Telemetry capable of identifying sequential connection attempts across primary and alternate destinations consistent with fallback communication behavior
· Historical DNS and connection records sufficient for retrospective hunting against identified campaign infrastructure
· Email telemetry is optional for this campaign and is only required if the initial infection vector is determined to involve email delivery
· If email delivery is confirmed, required telemetry includes sender, recipient, subject, attachment metadata, embedded link metadata, message authentication results, and delivery disposition
· If email delivery is confirmed, required telemetry must support correlation between delivered message artifacts and subsequent endpoint execution activity
Correlation Requirements
· Telemetry must support correlation of process execution, persistence creation, security control impairment, and outbound communication on the same host
· Telemetry must preserve host identity consistently across endpoint, DNS, and network sources
· Telemetry must retain sufficient timestamp fidelity to reconstruct execution-to-persistence and execution-to-network activity sequences
· Telemetry must support mapping outbound network activity to the originating process or host execution context
· Telemetry must support retrospective reconstruction of the infection chain from initial execution through retained foothold behavior
Minimum Viable Telemetry Baseline
· Endpoint process creation telemetry with parent-child relationships and executable path visibility
· Service and security product telemetry sufficient to identify protection impairment
· WMI persistence telemetry
· Scheduled task creation and modification telemetry
· DNS query telemetry by host
· Outbound network connection telemetry by host
Telemetry Dependencies and Constraints
· Detection capability assumes availability of process creation telemetry with command-line visibility; absence of command-line logging reduces detection fidelity
· Detection capability assumes availability of process-to-network attribution; environments without this capability must rely on host-level correlation with reduced precision
· High-confidence detection is degraded if WMI persistence telemetry is absent or incomplete
· High-confidence detection is degraded if scheduled task creation telemetry lacks process context
· Detection quality is reduced if security product state changes are not logged independently of process activity
· DNS-only visibility is insufficient for strong detection without endpoint correlation
· Network-only visibility is insufficient to distinguish malicious persistence-backed beaconing from benign repetitive application traffic
Telemetry Priority
· Highest priority telemetry is endpoint process, service, WMI, scheduled task, and process-attributed network telemetry
· Secondary priority telemetry is DNS sequence visibility and historical connection records for retrospective hunting
· Email telemetry is conditional and should not be treated as a required primary source unless delivery evidence supports that infection path
Figure 4
S24 Detection Opportunities and Gaps
Detection Opportunities
· High-confidence detection opportunity exists at persistence establishment, specifically WMI event subscription creation and scheduled task registration
· High-confidence detection opportunity exists at security control impairment, including service stop, disable, or configuration modification of antivirus or endpoint protection
· Detection opportunity exists through correlation of process execution followed by persistence creation within the same host activity sequence
· Detection opportunity exists through correlation of persistence creation followed by outbound network communication within the same host activity sequence
· Detection opportunity exists through repeated outbound connections from a host to the same destination or small destination set at consistent intervals
· Detection opportunity exists through sequential DNS resolution and connection attempts across multiple domains indicating fallback communication behavior
· Detection opportunity exists through multi-signal correlation combining execution, persistence, defense evasion, and network activity on the same host
Detection Strength Areas
· Persistence mechanisms such as WMI subscriptions and scheduled tasks provide high-signal detection anchors due to low baseline frequency in most enterprise environments
· Security control impairment provides high-confidence indicators of malicious activity due to limited legitimate use cases outside controlled administrative workflows
· Correlation-based detection reduces false positives compared to single-event detection by requiring multiple related behaviors on the same host
· Repeated outbound connection patterns provide observable behavior independent of payload identity
Detection Gaps
· Detection coverage is reduced in environments where WMI telemetry is not collected or is incomplete
· Detection coverage is reduced where scheduled task creation telemetry lacks process attribution or execution context
· Detection capability is limited in environments without process-to-network attribution, reducing confidence in correlating execution to outbound communication
· Detection coverage is reduced where security product state changes are not independently logged or monitored
· DNS-only visibility does not provide sufficient context to confirm execution or persistence activity
· Network-only visibility does not provide sufficient context to distinguish malicious beaconing from legitimate repetitive application traffic
· Detection coverage is reduced in environments where endpoint logging is restricted, disabled, or inconsistently deployed across hosts
Adversary Evasion Opportunities
· Adversary may use persistence mechanisms other than WMI or scheduled tasks, resulting in missed detection if alternative mechanisms are not monitored
· Adversary may separate execution, persistence creation, and network communication across different time intervals to weaken correlation-based detection
· Adversary may blend outbound communication into legitimate application traffic patterns to reduce detectability of beaconing behavior
· Adversary may use legitimate administrative tools or processes to perform persistence or security modification actions, reducing anomaly-based detection effectiveness
· Adversary may impair or bypass telemetry collection without fully disabling endpoint protection, resulting in partial visibility gaps
Telemetry-Driven Gaps
· Absence of command-line logging reduces visibility into execution context and persistence creation activity
· Absence of process lineage telemetry reduces ability to identify relationships between parent and child processes
· Lack of process-to-network attribution prevents direct linkage between execution activity and outbound communication
· Delayed or incomplete log ingestion reduces effectiveness of correlation-based detection across activity sequences
· Limited historical telemetry reduces ability to perform retrospective analysis of initial access activity
Correlation Gaps
· Detection effectiveness is reduced when execution, persistence, and network signals cannot be correlated due to inconsistent host identifiers across telemetry sources
· Detection effectiveness is reduced when timestamp precision or synchronization issues prevent reconstruction of activity sequences
· Detection effectiveness is reduced when telemetry sources are siloed and cannot be queried or correlated together
Detection Maturity Assessment
· Detection capability is strong when endpoint telemetry, persistence visibility, and process-attributed network telemetry are available and correlated
· Detection capability is moderate when endpoint telemetry is available but process-to-network attribution is limited
· Detection capability is weak when detection relies primarily on DNS or network telemetry without endpoint correlation
S25 Ultra-Tuned Detection Engineering Rules
Suricata
System Telemetry Scope
· Network session behavior
· DNS request and response behavior
· Protocol-level communication patterns
· No native visibility into:
o process execution
o antivirus disablement
o WMI persistence creation
o scheduled task persistence
System Evaluation Outcome
· No Suricata production rule currently meets CyberDax primary or survivor quality thresholds for this campaign
· This is a valid and complete engineering outcome under the framework
· No weak, noisy, or enrichment-dependent rule should be forced into the report
Behavioral Opportunity Sweep
· Repeated outbound beaconing from a single internal host
· Recurrent low-volume communication to a small external destination set
· DNS resolution followed by outbound connection attempts
· Sequential fallback communication across multiple external domains or endpoints
· Short-duration repeated sessions at consistent intervals
· Communication to confirmed campaign infrastructure
· Protocol fingerprinting tied to stable malware network behavior
· TLS or HTTP request patterning tied to stable campaign tooling
Explanation
· Zero production rules is the correct quality outcome for Suricata in this case
· This does not represent incomplete work
· It represents successful framework enforcement, adversarial filtering, telemetry realism testing, and rejection of weak detections
SentinelOne
Rule Name
· SentinelOne Security Control Impairment Followed by Persistence Establishment
Rule Type
· SentinelOne Deep Visibility
· Primary rule
Detection Intent
· Detect hosts where security controls are impaired and retained foothold activity is established through scheduled task persistence or WMI persistence creation within the same host activity sequence
Behavioral Logic
· A security-control impairment event occurs on a host
· The same host subsequently shows one of the following persistence events:
o scheduled task creation, update, or registration
o WMI event filter, consumer, or binding creation
· The sequence is not attributable to approved administrative maintenance, sanctioned endpoint-management workflows, or authorized security-configuration activity
Correlation Guidance
· Correlate events within a short operational sequence window aligned to the same host activity chain
· The window must be tight enough to capture impairment-to-persistence progression without absorbing unrelated maintenance activity
· If customer baseline shows frequent legitimate security reconfiguration, narrow the sequence window and strengthen allowlists before deployment
Why This Rule Survived
· Combines malicious-intent evidence with foothold-retention behavior
· Uses hard-to-evade behaviors that are materially stronger than signer, path, or reputation indicators
· Maintains value even if the adversary changes payload naming, signing material, or downstream infrastructure
Engineering Implementation Instructions
· Validate which SentinelOne event families and fields in the customer tenant represent:
o service stop actions
o service disable actions
o security configuration changes
o tamper-related state changes
· Validate scheduled task telemetry for:
o task creation
o task update
o task registration
o initiating process or equivalent host context
· Validate WMI persistence telemetry for:
o event filter creation
o event consumer creation
o filter-to-consumer binding creation
· Build explicit allowlists for:
o approved IT maintenance tooling
o sanctioned endpoint-management platforms
o authorized security-product reconfiguration workflows
· Suppress detections where:
o activity occurs during approved maintenance windows
o initiating identity and process lineage align to approved administrative change workflows
· If direct WMI persistence telemetry is not available, retain the scheduled-task branch only and remove the WMI branch from deployment
· Validate all field names, event families, and sequence operators against the customer tenant schema before production deployment
· Treat the code below as SentinelOne Deep Visibility deployment logic that requires tenant field mapping before enablement
System Code
/* Tenant-mapped Stage 1: security-control impairment */
Stage1 :=
(
EventType = "Process"
AND EventSubType IN ("ServiceStop","ServiceDisable","SecurityConfigChange","SecurityTamper")
);
/* Tenant-mapped Stage 2A: scheduled-task persistence */
Stage2_Task :=
(
EventType = "TaskScheduler"
AND EventSubType IN ("TaskCreated","TaskUpdated","TaskRegistered")
);
/* Tenant-mapped Stage 2B: WMI persistence */
Stage2_WMI :=
(
EventType = "WMI"
AND EventSubType IN ("EventFilterCreated","EventConsumerCreated","FilterToConsumerBindingCreated")
);
/* Correlate ordered stages by host */
(Stage1 OR Stage2_Task OR Stage2_WMI)
| group AgentUuid
| filter (
sequence(
any(Stage1),
any(Stage2_Task)
)
OR
sequence(
any(Stage1),
any(Stage2_WMI)
)
)
Rule Name
· SentinelOne Customer-Defined Constrained Execution Followed by Scheduled Task Persistence
Rule Type
· SentinelOne Deep Visibility
· Survivor rule
Detection Intent
· Detect process execution from customer-defined constrained execution contexts that is followed by scheduled task persistence on the same host activity sequence
Behavioral Logic
· A process executes from a customer-defined constrained execution context on a host
· Customer-defined constrained execution context must be explicitly defined before deployment using one or more observable tenant-supported conditions such as:
o execution from user-writable paths
o recently first-seen executable path in the tenant
o execution lineage not aligned to approved installer, updater, or management workflows
· The same host subsequently creates, updates, or registers a scheduled task
· The sequence is not attributable to approved installers, sanctioned software updaters, enterprise automation workflows, or routine deployment tooling
Correlation Guidance
· Correlate execution and task-persistence events within a short operational sequence window aligned to the same host activity chain
· Narrow the sequence window if customer environments contain high volumes of legitimate installer and updater activity
· Use only customer-defined constrained execution conditions that are explicit, testable, and supported by tenant data
Why This Rule Survived
· Uses execution-to-persistence correlation rather than path-only or signer-only logic
· Retains a strong foothold-establishment anchor
· Produces better deployability than artifact-based or anomaly-only detections
Engineering Implementation Instructions
· Validate process execution visibility for:
o executable path
o parent process
o child process where applicable
o command-line visibility where enabled
· Define and lock constrained execution conditions before deployment using customer baseline data
· Document the exact tenant-supported fields and values used for constrained execution
· Build allowlists for:
o legitimate software installers
o sanctioned software updaters
o endpoint-management agents
o enterprise automation frameworks
· Validate scheduled task telemetry visibility, including:
o task creation
o task update
o task registration
o initiating process or equivalent host context
· Suppress detections during approved software deployment windows
· Do not deploy with unconstrained EventType = "Process" stage-one logic
· Treat the code below as deployment logic that requires customer substitution of the constrained execution predicate before enablement
· Validate all field names, event families, and sequence operators against the customer tenant schema before production deployment
System Code
/* Customer must replace this predicate with explicit tenant-supported logic */
ConstrainedExecution :=
(
EventType = "Process"
AND (
FilePath RegExp ".*\\\\Users\\\\.*\\\\(Downloads|AppData|Temp)\\\\.*"
OR ParentProcessName IN ("browser.exe","explorer.exe")
OR CommandLine RegExp ".*\\\\Users\\\\.*"
)
);
/* Stage 2: scheduled-task persistence */
Stage2 :=
(
EventType = "TaskScheduler"
AND EventSubType IN ("TaskCreated","TaskUpdated","TaskRegistered")
);
/* Correlate ordered stages by host */
(ConstrainedExecution OR Stage2)
| group AgentUuid
| filter sequence(
any(ConstrainedExecution),
any(Stage2)
)
Rule Name
· SentinelOne Customer-Defined Constrained Execution Followed by WMI Persistence Creation
Rule Type
· SentinelOne Deep Visibility
· Survivor rule
· Conditional deployment
Detection Intent
· Detect process execution from customer-defined constrained execution contexts that is followed by WMI persistence creation on the same host activity sequence
Behavioral Logic
· A process executes from a customer-defined constrained execution context on a host
· Customer-defined constrained execution context must be explicitly defined before deployment using one or more observable tenant-supported conditions such as:
o execution from user-writable paths
o recently first-seen executable path in the tenant
o execution lineage not aligned to approved installer, updater, or management workflows
· The same host subsequently creates one or more of the following WMI persistence objects:
o event filter
o event consumer
o filter-to-consumer binding
· The rule is deployable only where direct WMI persistence telemetry is complete and reliably normalized
Correlation Guidance
· Correlate execution and WMI persistence events within a short operational sequence window aligned to the same host activity chain
· Do not widen the sequence window beyond normal process-to-persistence progression because unrelated administrative automation can contaminate results
· Strengthen allowlists before deployment if legitimate automation creates persistent WMI objects in the environment
Why This Rule Survived
· WMI persistence creation is a strong malicious anchor when directly visible
· Correlation with constrained execution reduces benign overlap relative to unconstrained process-to-WMI correlation
· Remains resilient to payload renaming, signer changes, and infrastructure rotation
Engineering Implementation Instructions
· Deploy only if the customer validates complete and normalized visibility for all of the following:
o WMI event filter creation
o WMI event consumer creation
o WMI filter-to-consumer binding creation
· Treat telemetry as incomplete and do not deploy the rule if any of the following are true:
o one or more WMI persistence object types are absent
o WMI events are inconsistently normalized across hosts
o event sequencing cannot be reliably correlated on the same host
· Define and lock constrained execution conditions before deployment using customer baseline data
· Document the exact tenant-supported fields and values used for constrained execution
· Build allowlists for sanctioned administrative scripts and automation frameworks that legitimately create persistent WMI objects
· Suppress detections during approved administrative automation windows where known-good WMI persistence activity is expected
· If these deployment criteria are not met, omit this rule and retain Rule 1 and Rule 2 as the active SentinelOne set
· Treat the code below as deployment logic that requires customer substitution of the constrained execution predicate before enablement
· Validate all field names, event families, and sequence operators against the customer tenant schema before production deployment
System Code
/* Customer must replace this predicate with explicit tenant-supported logic */
ConstrainedExecution :=
(
EventType = "Process"
AND (
FilePath RegExp ".*\\\\Users\\\\.*\\\\(Downloads|AppData|Temp)\\\\.*"
OR ParentProcessName IN ("browser.exe","explorer.exe")
OR CommandLine RegExp ".*\\\\Users\\\\.*"
)
);
/* Stage 2: WMI persistence */
Stage2 :=
(
EventType = "WMI"
AND EventSubType IN ("EventFilterCreated","EventConsumerCreated","FilterToConsumerBindingCreated")
);
/* Correlate ordered stages by host */
(ConstrainedExecution OR Stage2)
| group AgentUuid
| filter sequence(
any(ConstrainedExecution),
any(Stage2)
)
Splunk
Rule Name
· Splunk Security Control Impairment Followed by Persistence Establishment
Rule Type
· Splunk SPL Correlation Search
· Primary rule
Rule Score
DRI
8.9
TCR (Operational)
7.2
TCR (Full-Telemetry):
8.8
Detection Intent
· Detect hosts where security controls are impaired and retained foothold activity is established through scheduled task persistence or WMI persistence creation within the same host activity sequence
Behavioral Logic
· A security-control impairment event occurs on a host
· The same host subsequently shows one of the following persistence events:
o scheduled task creation, update, or registration
o WMI event filter, consumer, or binding creation
· The sequence is not attributable to approved administrative maintenance, sanctioned endpoint-management workflows, or authorized security-configuration activity
Correlation Guidance
· Correlate events within a short operational sequence window aligned to the same host activity chain
· The window must be tight enough to capture impairment-to-persistence progression without absorbing unrelated maintenance activity
· If customer baseline shows frequent legitimate security reconfiguration, narrow the sequence window and strengthen allowlists before deployment
Why This Rule Survived
· Combines malicious-intent evidence with foothold-retention behavior
· Uses hard-to-evade behaviors that are materially stronger than signer, path, or reputation indicators
· Maintains value even if the adversary changes payload naming, signing material, or downstream infrastructure
Engineering Implementation Instructions
· Validate which Splunk sourcetypes, data models, fields, or CIM mappings in the customer environment represent:
o service stop actions
o service disable actions
o security configuration changes
o tamper-related state changes
· Do not deploy broad process-name or keyword heuristics as substitutes for mapped security-control impairment events
· Validate scheduled task telemetry for:
o task creation
o task update
o task registration
o initiating process or equivalent host context
· Validate WMI persistence telemetry for:
o event filter creation
o event consumer creation
o filter-to-consumer binding creation
· Normalize host identity fields so the same host can be correlated reliably across endpoint, Windows event, and security telemetry
· Build explicit allowlists for:
o approved IT maintenance tooling
o sanctioned endpoint-management platforms
o authorized security-product reconfiguration workflows
· Suppress detections where:
o activity occurs during approved maintenance windows
o initiating identity and process lineage align to approved administrative change workflows
· If direct WMI persistence telemetry is not available, retain the scheduled-task branch only and remove the WMI branch from deployment
· Treat the SPL below as deployment logic that requires customer sourcetype, field, macro, and event-mapping validation before enablement
System Code
`dragonboss_security_impairment_events`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="security_impairment"
| fields _time host user parent_process process process_name stage
| append [
`dragonboss_task_persistence_events`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="persistence_task"
| fields _time host user parent_process process process_name stage
]
| append [
`dragonboss_wmi_persistence_events`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="persistence_wmi"
| fields _time host user parent_process process process_name stage
]
| where isnotnull(host)
| sort 0 host _time
| streamstats current=f window=1 last(stage) as prev_stage last(_time) as prev_time by host
| where prev_stage="security_impairment" AND stage IN ("persistence_task","persistence_wmi") AND (_time-prev_time) >= 0 AND (_time-prev_time) <= 900
| stats min(prev_time) as first_stage_time min(_time) as second_stage_time values(stage) as matched_persistence values(user) as users values(parent_process) as parent_processes values(process) as processes by host
Rule Name
· Splunk Customer-Defined Constrained Execution Followed by Scheduled Task Persistence
Rule Type
· Splunk SPL Correlation Search
· Survivor rule
DRI
8.0
TCR (Operational)
6.9
TCR (Full-Telemetry)
8.3
Detection Intent
· Detect process execution from customer-defined constrained execution contexts that is followed by scheduled task persistence on the same host activity sequence
Behavioral Logic
· A process executes from a customer-defined constrained execution context on a host
· Customer-defined constrained execution context must be explicitly defined before deployment using one or more observable customer-supported conditions such as:
o execution from user-writable paths
o recently first-seen executable path in the environment
o execution lineage not aligned to approved installer, updater, or management workflows
· The same host subsequently creates, updates, or registers a scheduled task
· The sequence is not attributable to approved installers, sanctioned software updaters, enterprise automation workflows, or routine deployment tooling
Correlation Guidance
· Correlate execution and task-persistence events within a short operational sequence window aligned to the same host activity chain
· Narrow the sequence window if customer environments contain high volumes of legitimate installer and updater activity
· Use only customer-defined constrained execution conditions that are explicit, testable, and supported by customer data
Why This Rule Survived
· Uses execution-to-persistence correlation rather than path-only or signer-only logic
· Retains a strong foothold-establishment anchor
· Produces better deployability than artifact-based or anomaly-only detections
Engineering Implementation Instructions
· Validate process execution visibility for:
o executable path
o parent process
o command line where available
o first-seen or prevalence context if used
· Define and lock constrained execution conditions before deployment using customer baseline data
· Document the exact fields, macros, sourcetypes, and data models used for constrained execution
· Build allowlists for:
o legitimate software installers
o sanctioned software updaters
o endpoint-management agents
o enterprise automation frameworks
· Validate scheduled task telemetry visibility, including:
o task creation
o task update
o task registration
o initiating process or equivalent host context
· Suppress detections during approved software deployment windows
· Do not deploy with unconstrained process stage-one logic
· Treat the SPL below as deployment logic that requires customer substitution of the constrained-execution macro before enablement
· Do not leave the placeholder macro unmodified in production
System Code
`dragonboss_constrained_execution`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="constrained_execution"
| fields _time host user parent_process process process_name process_path command_line stage
| append [
`dragonboss_task_persistence_events`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="persistence_task"
| fields _time host user parent_process process process_name process_path command_line stage
]
| where isnotnull(host)
| sort 0 host _time
| streamstats current=f window=1 last(stage) as prev_stage last(_time) as prev_time by host
| where prev_stage="constrained_execution" AND stage="persistence_task" AND (_time-prev_time) >= 0 AND (_time-prev_time) <= 900
| stats min(prev_time) as execution_time min(_time) as persistence_time values(process) as processes values(process_path) as process_paths values(command_line) as command_lines by host
Rule Name
· Splunk Customer-Defined Constrained Execution Followed by WMI Persistence Creation
Rule Type
· Splunk SPL Correlation Search
· Survivor rule
· Conditional deployment
Rule Score
DRI:
8.4
TCR (Operational):
5.5
TCR (Full-Telemetry):
8.4
Detection Intent
· Detect process execution from customer-defined constrained execution contexts that is followed by WMI persistence creation on the same host activity sequence
Behavioral Logic
· A process executes from a customer-defined constrained execution context on a host
· Customer-defined constrained execution context must be explicitly defined before deployment using one or more observable customer-supported conditions such as:
o execution from user-writable paths
o recently first-seen executable path in the environment
o execution lineage not aligned to approved installer, updater, or management workflows
· The same host subsequently creates one or more of the following WMI persistence objects:
o event filter
o event consumer
o filter-to-consumer binding
· The rule is deployable only where direct WMI persistence telemetry is complete and reliably normalized
Correlation Guidance
· Correlate execution and WMI persistence events within a short operational sequence window aligned to the same host activity chain
· Do not widen the sequence window beyond normal process-to-persistence progression because unrelated administrative automation can contaminate results
· Strengthen allowlists before deployment if legitimate automation creates persistent WMI objects in the environment
Why This Rule Survived
· WMI persistence creation is a strong malicious anchor when directly visible
· Correlation with constrained execution reduces benign overlap relative to unconstrained process-to-WMI correlation
· Remains resilient to payload renaming, signer changes, and infrastructure rotation
Engineering Implementation Instructions
· Deploy only if the customer validates complete and normalized visibility for all of the following:
o WMI event filter creation
o WMI event consumer creation
o WMI filter-to-consumer binding creation
· Treat telemetry as incomplete and do not deploy the rule if any of the following are true:
o one or more WMI persistence object types are absent
o WMI events are inconsistently normalized across hosts
o event sequencing cannot be reliably correlated on the same host
· Define and lock constrained execution conditions before deployment using customer baseline data
· Document the exact fields, macros, sourcetypes, and data models used for constrained execution
· Build allowlists for sanctioned administrative scripts and automation frameworks that legitimately create persistent WMI objects
· Suppress detections during approved administrative automation windows where known-good WMI persistence activity is expected
· If these deployment criteria are not met, omit this rule and retain Rule 1 and Rule 2 as the active Splunk set
· Treat the SPL below as deployment logic that requires customer substitution of the constrained-execution macro before enablement
· Do not leave the placeholder macro unmodified in production
System Code
`dragonboss_constrained_execution`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="constrained_execution"
| fields _time host user parent_process process process_name process_path command_line stage
| append [
`dragonboss_wmi_persistence_events`
| eval host=coalesce(host, Computer, ComputerName, dest)
| eval stage="persistence_wmi"
| fields _time host user parent_process process process_name process_path command_line stage
]
| where isnotnull(host)
| sort 0 host _time
| streamstats current=f window=1 last(stage) as prev_stage last(_time) as prev_time by host
| where prev_stage="constrained_execution" AND stage="persistence_wmi" AND (_time-prev_time) >= 0 AND (_time-prev_time) <= 900
| stats min(prev_time) as execution_time min(_time) as persistence_time values(process) as processes values(process_path) as process_paths values(command_line) as command_lines by host
Elastic
Rule Name
· Elastic Security Control Impairment Followed by Persistence Establishment
Rule Type
· Elastic EQL Correlation Rule
· Primary rule
Rule Score
DRI:
8.7
TCR (Operational):
6.8
TCR (Full-Telemetry):
8.7
Detection Intent
· Detect hosts where security controls are impaired and persistence is established within the same operational sequence
Behavioral Logic
· A verified security-control impairment event occurs
· The same host subsequently creates persistence via:
o scheduled task
o or WMI persistence
· Events are not attributable to approved administrative activity
Correlation Guidance
· Correlate within a short operational window aligned to host activity lifecycle
· Do not extend correlation window beyond typical impairment-to-persistence timing
· Validate baseline before deployment
Engineering Implementation Instructions
Customer must define explicit security-control impairment detection logic using:
o service control events
o security configuration modification events
o tamper-protection signals
· Customer must define persistence detection mappings for:
o scheduled task creation
o WMI persistence creation
· Do not substitute process-name heuristics for impairment detection
· Validate host identity normalization before correlation
· Apply allowlists for:
o maintenance operations
o endpoint management tools
System Code
sequence by host.id with maxspan=10m
[any where
/* REQUIRED: replace with validated impairment logic */
dragonboss_security_impairment == true
]
[any where
(
/* REQUIRED: scheduled task persistence mapping */
dragonboss_task_persistence == true
)
or
(
/* REQUIRED: WMI persistence mapping */
dragonboss_wmi_persistence == true
)
]
Rule Name
· Elastic Constrained Execution Followed by Scheduled Task Persistence
Rule Type
· Elastic EQL Correlation Rule
· Survivor rule
Rule Score
DRI:
7.8
TCR (Operational):
6.5
TCR (Full-Telemetry):
8.0
Detection Intent
· Detect suspicious execution activity that results in scheduled task persistence
Behavioral Logic
· A process executes under constrained conditions defined by the customer
· The same host creates a scheduled task
· Activity is not part of approved deployment or automation workflows
Correlation Guidance
· Maintain tight sequence window
· Do not deploy without validated constrained execution definition
Engineering Implementation Instructions
· Customer must define constrained execution using:
o explicit field-based logic
o validated baseline conditions
· Constrained execution must be:
o testable
o measurable
o low-noise
· Examples may include:
o execution from user-controlled paths
o first-seen binaries
o abnormal execution lineage
· Build allowlists for:
o installers
o automation frameworks
· Do not deploy without constrained execution definition
System Code
sequence by host.id with maxspan=10m
[process where
/* REQUIRED: replace with validated constrained execution logic */
dragonboss_constrained_execution == true
]
[any where
/* REQUIRED: scheduled task persistence mapping */
dragonboss_task_persistence == true
]
Rule Name
· Elastic Constrained Execution Followed by WMI Persistence Creation
Rule Type
· Elastic EQL Correlation Rule
· Survivor rule
· Conditional deployment
Rule Score
DRI
8.1
TCR (Operational)
5.1
TCR (Full-Telemetry)
8.1
Detection Intent
· Detect suspicious execution activity that results in WMI persistence creation
Behavioral Logic
· A process executes under constrained conditions defined by the customer
· The same host creates WMI persistence artifacts
· Rule is deployable only with complete WMI telemetry
Correlation Guidance
· Maintain tight sequence window
· Do not deploy without full WMI telemetry validation
Engineering Implementation Instructions
· Deploy only if customer validates:
o WMI filter creation visibility
o WMI consumer creation visibility
o binding creation visibility
· Do not approximate WMI persistence using partial signals
· Define constrained execution conditions prior to deployment
· Build allowlists for:
o administrative automation
· Omit rule entirely if telemetry is incomplete
System Code
sequence by host.id with maxspan=10m
[process where
/* REQUIRED: replace with validated constrained execution logic */
dragonboss_constrained_execution == true
]
[any where
/* REQUIRED: WMI persistence mapping */
dragonboss_wmi_persistence == true
]
QRadar
Rule Name
· QRadar Security Control Impairment Followed by Persistence Establishment
Rule Type
· QRadar CRE Rule
· Primary rule
Rule Score
DRI:
8.8
TCR (Operational):
6.9
TCR (Full-Telemetry):
8.7
Detection Intent
· Detect high-confidence malicious foothold establishment where security controls are impaired and persistence is created within the same host activity sequence
Behavioral Logic
· A validated security-control impairment event occurs
· Followed by a validated persistence event:
o scheduled task creation
o or WMI persistence creation
· Events occur on the same host within a bounded time window
Correlation Guidance
· Use a strict correlation window
o Default: ≤ 10 minutes
· Narrow window if administrative activity is frequent
· Do not widen window beyond operational necessity
Engineering Implementation Instructions
· Map security-control impairment using DSM-validated events:
o service disable or stop actions
o tamper-protection modifications
o security configuration changes
· Do not use process-name or keyword heuristics
· Map persistence using:
o scheduled task creation events
o WMI persistence creation events
· Normalize host identity across all sources
· Apply allowlists for:
o maintenance activity
o endpoint management platforms
· Remove WMI branch if WMI telemetry is not available
System Code
WHEN event matches:
Category = "Security Control Modification"
AND
FOLLOWED BY event matches:
(
Category = "Scheduled Task Created"
OR
Category = "WMI Persistence Created"
)
WITHIN 10 minutes
ON same Host
Rule Name
· QRadar Constrained Execution Followed by Scheduled Task Persistence
Rule Type
· QRadar CRE Rule
· Survivor rule
Rule Score
DRI:
7.8
TCR (Operational):
6.4
TCR (Full-Telemetry):
7.9
Detection Intent
· Detect suspicious execution that results in scheduled task persistence without requiring security-control impairment
Behavioral Logic
· A process executes under explicitly defined constrained conditions
· Followed by scheduled task creation on the same host
Correlation Guidance
· Use strict correlation window
o Default: ≤ 10 minutes
· Do not deploy without validated constrained execution definition
Engineering Implementation Instructions
· Define constrained execution using measurable, environment-specific logic such as:
o execution from user-controlled paths
o first-seen executables
o abnormal execution lineage
· Constrained execution must be:
o explicit
o testable
o low-noise after tuning
· Map execution and scheduled task events into DSM categories
· Apply allowlists for:
o installers
o automation tools
· Do not deploy if constrained execution is overly broad
System Code
WHEN event matches:
Category = "Constrained Execution"
AND
FOLLOWED BY event matches:
Category = "Scheduled Task Created"
WITHIN 10 minutes
ON same Host
Rule Name
· QRadar Constrained Execution Followed by WMI Persistence Creation
Rule Type
· QRadar CRE Rule
· Survivor rule
· Conditional deployment
Rule Score
DRI:
8.1
TCR (Operational):
4.9
TCR (Full-Telemetry):
8.0
Detection Intent
· Detect suspicious execution that results in WMI persistence creation
Behavioral Logic
· A process executes under explicitly defined constrained conditions
· Followed by WMI persistence creation on the same host
Correlation Guidance
· Use strict correlation window
o Default: ≤ 10 minutes
· Do not deploy without complete WMI telemetry
Engineering Implementation Instructions
· Deploy only if:
o WMI persistence events are fully ingested
o DSM normalization is consistent
o event sequencing is reliable
· Define constrained execution before deployment
· Apply allowlists for:
o administrative automation
· Omit rule entirely if WMI visibility is incomplete
System Code
WHEN event matches:
Category = "Constrained Execution"
AND
FOLLOWED BY event matches:
Category = "WMI Persistence Created"
WITHIN 10 minutes
ON same Host
Sigma
Rule Name
· Sigma Anti-Malware Configuration Tampering
Rule Type
· Sigma rule
· Primary rule
Rule Score
DRI:
8.4
TCR (Operational):
7.9
TCR (Full-Telemetry):
8.5
Detection Intent
· Detect direct weakening of Windows anti-malware protection through validated configuration tampering commands
Behavioral Logic
· Process execution modifies anti-malware configuration to reduce protection
· Specifically targets:
o real-time monitoring disablement
o behavior monitoring disablement
o IOAV disablement
· Rule is intentionally scoped to validated anti-malware protection weakening, not generalized to all security tooling
Correlation Guidance
· This is a hardened atomic rule, not a sequence rule
· Use backend correlation separately only if the customer chooses to enrich investigation workflow
· Do not broaden the rule to generic PowerShell or utility usage
Why This Rule Survived
· Captures a high-intent defense-evasion behavior in the Dragon Boss foothold model
· Maintains value even if payload, signer, or downstream infrastructure changes
· Provides a strong standalone signal in Sigma where true multi-stage correlation is limited
Engineering Implementation Instructions
· Validate command-line visibility in the deployed backend
· Restrict rule to anti-malware configuration weakening commands only
· Build allowlists for:
o authorized security administration
o sanctioned maintenance workflows
· Do not generalize to:
o all PowerShell usage
o all service control activity
o all security tool interaction
· Validate backend field mappings before production deployment
System Code
title: Sigma Anti-Malware Configuration Tampering
id: cdx-sigma-001
status: stable
logsource:
product: windows
category: process_creation
detection:
selection:
CommandLine|contains:
- Set-MpPreference
- DisableRealtimeMonitoring
- DisableBehaviorMonitoring
- DisableIOAVProtection
condition: selection
falsepositives:
- Authorized security administration
level: high
Rule Name
· Sigma Scheduled Task Persistence Creation
Rule Type
· Sigma rule
· Survivor rule
Rule Score
DRI:
7.9
TCR (Operational):
7.1
TCR (Full-Telemetry):
7.9
Detection Intent
· Detect explicit scheduled task creation or registration used as a persistence mechanism on Windows hosts
Behavioral Logic
· A scheduled task is:
o created
o registered
o or materially updated in a persistence-relevant context
· Rule is anchored to task-persistence creation itself, not to execution rarity or user-path heuristics
· Rule requires environment-specific allowlisting before production deployment
Correlation Guidance
· This is a persistence-anchor rule and should remain atomic in Sigma
· If the backend supports stronger sequence logic, correlate separately outside Sigma
· Do not weaken the rule by converting it into generic execution-plus-task pseudo-correlation
Why This Rule Survived
· Scheduled task persistence is a common and durable foothold mechanism
· Provides meaningful coverage of the Dragon Boss persistence branch
· Retains portability and deployability across Sigma backends when scoped and allowlisted correctly
Engineering Implementation Instructions
· Map to customer-supported scheduled-task creation telemetry such as:
o Security Event ID 4698
o Task Scheduler Operational events representing task registration or update
· Build explicit allowlists for:
o approved software installers
o sanctioned automation frameworks
o enterprise deployment tooling
· Validate that the backend preserves:
o task name where available
o task author where available
o action path where available
· Do not claim this rule is universally low-noise without environment tuning
· Do not deploy if scheduled-task telemetry is absent or inconsistently mapped
System Code
title: Sigma Scheduled Task Persistence Creation
id: cdx-sigma-002
status: stable
logsource:
product: windows
detection:
selection_security:
EventID: 4698
selection_taskscheduler:
EventID:
- 106
- 140
condition: selection_security or selection_taskscheduler
falsepositives:
- Approved software deployment
- Authorized administrative automation
level: high
Rule Name
· Sigma WMI Persistence Creation
Rule Type
· Sigma rule
· Survivor rule
· Conditional deployment
Rule Score
DRI:
8.2
TCR (Operational):
5.4
TCR (Full-Telemetry):
8.2
Detection Intent
· Detect explicit WMI persistence creation behavior on Windows hosts
Behavioral Logic
· One or more WMI persistence objects are created:
o event filter
o event consumer
o filter-to-consumer binding
· Rule is deployable only where direct WMI persistence telemetry is complete and consistently mapped
Correlation Guidance
· This is a conditional atomic rule
· Do not deploy as an approximation using partial WMI telemetry
· Do not substitute broad WMI usage for persistence-specific telemetry
Why This Rule Survived
· WMI persistence is a high-confidence stealth foothold behavior when directly visible
· Covers a persistence branch not covered by scheduled-task logic
· Adds meaningful coverage only when telemetry quality is sufficient
Engineering Implementation Instructions
· Deploy only if the customer validates visibility for:
o WMI event filter creation
o WMI event consumer creation
o WMI filter-to-consumer binding creation
· Reject deployment if:
o WMI logging is partial
o event IDs are inconsistently mapped
o backend normalization loses persistence object context
· Build allowlists for:
o sanctioned administrative automation that legitimately creates persistent WMI objects
· Omit the rule entirely if deployment criteria are not met
System Code
title: Sigma WMI Persistence Creation
id: cdx-sigma-003
status: experimental
logsource:
product: windows
detection:
selection:
EventID:
- 5860
- 5861
condition: selection
falsepositives:
- Approved administrative automation
level: high
YARA
System Telemetry Scope
· Static file content inspection
· Memory content inspection where supported by deployment workflow
· String, byte-pattern, structural, and module-based matching against file or memory artifacts
· No native visibility into:
o execution sequence
o security-control impairment
o scheduled task creation
o WMI persistence creation
o host-to-network behavioral correlation
System Reality Statement
· YARA is an artifact-matching system, not a behavioral correlation system
· This campaign currently presents strongest detection value through:
o defense evasion
o persistence creation
o execution-to-persistence correlation
· Those behaviors are primarily observable in endpoint and SIEM systems, not through static artifact matching alone
· YARA is viable only if the campaign exposes stable, reusable file or memory traits that survive adversarial modification
· For this campaign, no confirmed malware family, stable binary lineage, or repeatable unique artifact set has been established
Behavioral Opportunity Sweep
· Static detection of Dragon Boss-signed binaries
· Static detection of embedded strings related to anti-malware tampering
· Static detection of embedded strings related to scheduled task persistence
· Static detection of embedded strings related to WMI persistence
· PE structure anomalies associated with repackaged or suspicious binaries
· Import-table patterns associated with persistence or security modification
· Memory-resident string or structure matching for stable payload traits
· Generic loader-like string combinations
· Generic staged malware traits
· Known-family style signature matching
DRI Gating Outcome
Primary Rule Standard
· No pass
Survivor Rule Standard
· No pass
Factor-Level Justification
· No stable campaign-specific artifact has been validated
· All viable campaign strength currently resides in behavior, not in reusable static or memory signatures
· Adversary can evade candidate YARA logic through low-cost changes such as:
o recompilation
o string modification
o packing
o minor structural changes
· Any forced YARA rule would be fragile, noisy, or overly generic and would fail CyberDax quality requirements
Engineering Conclusion
· YARA does not currently provide a viable high-quality detection rule set for this campaign
· This is not a gap in effort
· This is the correct quality outcome under CyberDax S25 standards
· Forcing a YARA rule here would create one or more of the following failures:
o fragile artifact dependence
o excessive false positives
o pseudo-specificity
o low adversarial resilience
System Conclusion
· YARA is not currently a viable production detection system for Dragon Boss Signed Adware under CyberDax S25 standards
· The correct CyberDax outcome is explanation and rejection, not forced rule creation
· Detection for this campaign remains behavior-led and should stay anchored to:
o SentinelOne
o Splunk
o Elastic
o QRadar
o Sigma as an atomic signal layer only
AWS
System Telemetry Scope
· CloudTrail management and data event telemetry
· VPC Flow Logs
· Route 53 DNS query logging where enabled
· GuardDuty findings where deployed
· EC2 and cloud control-plane activity visibility
· No native visibility into:
o Windows scheduled task creation
o WMI persistence creation
o host-level antivirus impairment
o host-resident execution-to-persistence chains unless separately ingested through endpoint tooling outside AWS-native telemetry
System Reality Statement
· AWS is a cloud-native telemetry system, not a host-resident endpoint detection system
· This campaign’s strongest validated behaviors are:
o security-control impairment
o scheduled task persistence
o WMI persistence
o execution-to-persistence chaining
· Those behaviors are not directly observable through AWS-native control-plane telemetry
· AWS can only provide meaningful detection value for this campaign if the activity manifests through:
o cloud-hosted infrastructure behavior
o EC2 network behavior with strong distinguishing features
o cloud-native abuse tied directly to the campaign
· No such cloud-native behavioral anchor is currently confirmed in the report evidence
Behavioral Opportunity Sweep
· EC2-host outbound beaconing patterns visible in VPC Flow Logs
· Route 53 DNS resolution to primary or fallback campaign infrastructure
· GuardDuty findings related to command-and-control style communication
· CloudTrail indicators of malicious EC2 configuration changes
· CloudTrail indicators of IAM misuse or cloud persistence
· S3, Lambda, or other service abuse associated with campaign follow-on activity
· Cross-account or cloud control-plane abuse associated with retained foothold
· AWS-native infrastructure creation used for post-compromise staging
DRI Gating Outcome
Primary Rule Standard
· No pass
Survivor Rule Standard
· No pass
Factor-Level Justification
· No validated AWS-native behavioral anchor has been established for this campaign
· The campaign’s strongest signals are endpoint-resident and cannot be reliably reconstructed from AWS-native telemetry alone
· Any forced AWS rule would be driven by:
o generic network repetition
o generic DNS behavior
o generic cloud anomaly logic
· Those approaches would be too noisy, too broad, or too weak under adversarial testing
· Adversary can evade candidate AWS logic without changing the core host-side foothold behavior that defines the campaign
Engineering Conclusion
· AWS does not currently provide a viable high-quality detection rule set for this campaign
· This is the correct quality outcome under CyberDax S25 standards
· Forcing an AWS rule here would create one or more of the following failures:
o generic anomaly dependence
o excessive benign overlap
o weak campaign specificity
o low adversarial resilience
Potential Re-Entry Criteria
· Re-open AWS evaluation only if one or more of the following becomes available:
o validated AWS-hosted campaign infrastructure with stable distinguishing behavior
o confirmed EC2-resident foothold activity with reusable network or DNS characteristics
o confirmed cloud control-plane abuse tied directly to the campaign
o validated AWS-native staging, persistence, or follow-on activity linked to Dragon Boss operations
o stable Route 53 or VPC behavior that materially separates campaign traffic from benign cloud workloads
System Conclusion
· AWS is not currently a viable production detection system for Dragon Boss Signed Adware under CyberDax S25 standards
· The correct CyberDax outcome is explanation and rejection, not forced rule creation
· Detection for this campaign remains anchored to:
o SentinelOne
o Splunk
o Elastic
o QRadar
o Sigma as an atomic signal layer only
Azure
System Telemetry Scope
· Azure Activity Logs (control-plane operations)
· Azure AD / Entra ID sign-in and audit logs
· Azure Resource Manager (ARM) operations
· Network Watcher / NSG Flow Logs
· Microsoft Defender for Cloud alerts (if enabled)
· No native visibility into:
o Windows scheduled task creation
o WMI persistence creation
o host-level anti-malware impairment
o execution-to-persistence chaining inside endpoints unless separately ingested via EDR/SIEM
System Reality Statement
· Azure is a cloud control-plane and identity telemetry system, not a host-resident behavioral detection system
· This campaign’s strongest validated behaviors are:
o security-control impairment
o scheduled task persistence
o WMI persistence
o execution-to-persistence chaining
· These behaviors are endpoint-resident and not directly observable through Azure-native telemetry
· Azure detection is only viable if the campaign expresses through:
o identity abuse
o control-plane manipulation
o cloud-native persistence
o or distinct cloud-hosted infrastructure patterns
· No such Azure-native behavioral anchor is currently confirmed for this campaign
Behavioral Opportunity Sweep
· Azure AD sign-in anomalies from infected hosts
· Conditional access bypass or token abuse
· Azure VM outbound beaconing via NSG Flow Logs
· Azure DNS resolution patterns to campaign infrastructure
· Azure Resource Manager abuse for persistence or staging
· Privilege escalation or role assignment anomalies
· Creation or modification of compute resources tied to compromise
· Defender for Cloud alerts related to suspicious compute activity
· Cross-tenant or cross-subscription abuse patterns
Survivor Assessment
· No candidate survives as a primary rule
· No candidate survives as a survivor rule
· No candidate survives as a conditional rule at CyberDax S25 quality thresholds
DRI Gating Outcome
Primary Rule Standard
· No pass
Survivor Rule Standard
· No pass
Factor-Level Justification
· No validated Azure-native behavioral anchor has been identified for this campaign
· Campaign behavior is host-resident and not reconstructable from Azure-native telemetry
· Any Azure detection attempt would rely on:
o generic identity anomalies
o generic network patterns
o generic cloud behavior
· These approaches fail adversarial testing due to:
o high benign overlap
o low specificity
o easy evasion without altering core campaign behavior
Engineering Conclusion
· Azure does not currently provide a viable high-quality detection rule set for this campaign
· This is the correct outcome under CyberDax S25 standards
· Forcing Azure rules would introduce:
o generic anomaly dependence
o excessive noise
o weak attribution
o low adversarial resilience
Potential Re-Entry Criteria
· Re-open Azure evaluation only if one or more of the following becomes available:
o confirmed Azure-hosted campaign infrastructure with stable distinguishing behavior
o validated identity-layer abuse tied to infected endpoints
o confirmed Azure control-plane manipulation or persistence activity
o reusable NSG/DNS patterns uniquely attributable to the campaign
o linkage between Dragon Boss footholds and Azure tenant activity
System Conclusion
· Azure is not currently a viable production detection system for this campaign under CyberDax S25 standards
· The correct CyberDax outcome is explanation and rejection, not forced rule creation
· Detection remains anchored to:
o SentinelOne
o Splunk
o Elastic
o QRadar
o Sigma as an atomic layer
GCP
System Telemetry Scope
· Google Cloud Audit Logs
· VPC Flow Logs
· Cloud DNS logs where enabled
· Security Command Center findings where enabled
· IAM activity and resource-configuration telemetry
· No native visibility into:
o Windows scheduled task creation
o WMI persistence creation
o host-level anti-malware impairment
o execution-to-persistence chaining inside endpoints unless separately ingested through endpoint tooling outside GCP-native telemetry
System Reality Statement
· GCP is a cloud control-plane and infrastructure telemetry system, not a host-resident behavioral detection system
· This campaign’s strongest validated behaviors are:
o security-control impairment
o scheduled task persistence
o WMI persistence
o execution-to-persistence chaining
· These behaviors are endpoint-resident and are not directly observable through GCP-native telemetry
· GCP detection is only viable if the campaign expresses through:
o cloud-native identity abuse
o control-plane manipulation
o GCP-hosted staging or persistence
o or distinct GCP-native infrastructure behavior
· No such GCP-native behavioral anchor is currently confirmed for this campaign
Behavioral Opportunity Sweep
· GCP VM outbound beaconing via VPC Flow Logs
· Cloud DNS resolution patterns to campaign infrastructure
· IAM misuse or role escalation tied to infected assets
· Service account abuse associated with retained footholds
· Control-plane modification of compute, storage, or networking resources
· GCP-native persistence through startup scripts, metadata changes, or service account key activity
· Security Command Center findings related to suspicious resource behavior
· Cross-project or cross-service abuse tied to post-compromise staging
· Creation or modification of cloud resources associated with campaign follow-on activity
DRI Gating Outcome
Primary Rule Standard
· No pass
Survivor Rule Standard
· No pass
Factor-Level Justification
· No validated GCP-native behavioral anchor has been established for this campaign
· The campaign’s strongest signals are host-resident and cannot be reliably reconstructed from GCP-native telemetry alone
· Any forced GCP rule would be driven by:
o generic network repetition
o generic DNS behavior
o generic IAM or control-plane anomaly logic
· Those approaches are too noisy, too broad, or too weak under adversarial testing
· Adversary can evade candidate GCP logic without changing the core endpoint-side foothold behavior that defines the campaign
Engineering Conclusion
· GCP does not currently provide a viable high-quality detection rule set for this campaign
· This is the correct quality outcome under CyberDax S25 standards
· Forcing a GCP rule here would create one or more of the following failures:
o generic anomaly dependence
o excessive benign overlap
o weak campaign specificity
o low adversarial resilience
Potential Re-Entry Criteria
· Re-open GCP evaluation only if one or more of the following becomes available:
o validated GCP-hosted campaign infrastructure with stable distinguishing behavior
o confirmed GCP-native identity or service-account abuse tied directly to the campaign
o confirmed control-plane manipulation or GCP-native persistence linked to Dragon Boss operations
o stable Cloud DNS or VPC behavior that materially separates campaign traffic from benign cloud workloads
o validated linkage between Dragon Boss footholds and GCP project or resource activity
System Conclusion
· GCP is not currently a viable production detection system for this campaign under CyberDax S25 standards
· The correct CyberDax outcome is explanation and rejection, not forced rule creation
· Detection for this campaign remains anchored to:
o SentinelOne
o Splunk
o Elastic
o QRadar
o Sigma as an atomic signal layer only
S26 Threat-to-Rule Traceability
Behavior → Detection Mapping
Behavior: Security Control Impairment (Defense Evasion)
Description
· Disabling or weakening anti-malware protections prior to persistence or follow-on activity
Detection Coverage
· SentinelOne
o Behavioral rule detecting anti-malware tampering (telemetry-dependent)
· Splunk
o Rule 1
· Elastic
o Rule 1
· QRadar
o Rule 1
· Sigma
o Rule 1
Coverage Assessment
· Strong coverage across endpoint and SIEM systems
· Detection depends on:
o command-line visibility
o security telemetry completeness
Behavior: Scheduled Task Persistence
Description
· Establishing persistence via scheduled task creation or modification
Detection Coverage
· SentinelOne
o Behavioral persistence detection (visibility-dependent)
· Splunk
o Rule 1
o Rule 2
· Elastic
o Rule 1
o Rule 2
· QRadar
o Rule 1
o Rule 2
· Sigma
o Rule 2
Coverage Assessment
· Strong coverage across all viable systems
· Sigma detection requires:
o environment-specific allowlisting
· Detection reliability depends on:
o task telemetry normalization
Behavior: WMI Persistence
Description
· Establishing persistence through WMI event subscription mechanisms
Detection Coverage
· SentinelOne
o Behavioral persistence detection (only if WMI activity is visible)
· Splunk
o Rule 1
o Rule 3 (conditional)
· Elastic
o Rule 1
o Rule 3 (conditional)
· QRadar
o Rule 1
o Rule 3 (conditional)
· Sigma
o Rule 3 (conditional)
Coverage Assessment
· Conditional coverage
· Requires:
o complete WMI telemetry
o reliable normalization
· Absence of WMI visibility results in a real detection gap
Behavior: Initial Execution of Malicious Binary
Description
· Execution of Dragon Boss payload or equivalent repackaged binary
Detection Coverage
· SentinelOne
o Behavioral execution detection
· Splunk
o Rule 1 (only when followed by persistence or impairment)
o Rule 2 (only when followed by persistence)
· Elastic
o Rule 1 (only when followed by persistence or impairment)
o Rule 2 (only when followed by persistence)
· QRadar
o Rule 1 (only when followed by persistence or impairment)
o Rule 2 (only when followed by persistence)
· Sigma
o No direct coverage
Coverage Assessment
· No high-confidence execution-only detection
· Detection depends on:
o downstream persistence
o or defense evasion behavior
Behavior: Command-and-Control / Beaconing
Description
· Outbound communication to attacker-controlled infrastructure
Detection Coverage
· No S25-approved rules across any system
Coverage Assessment
· Coverage gap
Justification
· Network-only detection lacks sufficient specificity
· High benign overlap with:
o application traffic
o update mechanisms
o service polling
· Infrastructure is not stable enough for rule-based detection
Behavior: Cloud-Native Activity (AWS / Azure / GCP)
Description
· Cloud-hosted staging, persistence, or infrastructure usage
Detection Coverage
· AWS
o No viable rules
· Azure
o No viable rules
· GCP
o No viable rules
Coverage Assessment
· Full coverage gap
Justification
· No validated cloud-native behavior linked to campaign
· Core activity remains endpoint-resident
· Cloud telemetry cannot reconstruct:
o persistence
o impairment
o execution chains
Behavior: Static or Memory Artifact Detection
Description
· Detection via static signatures or memory artifacts
Detection Coverage
· YARA
o No viable rules
Coverage Assessment
· Full coverage gap
Justification
· No stable artifact or reusable malware signature identified
· Adversary can evade via:
o recompilation
o packing
o string mutation
Overall Traceability Assessment
· Strong coverage:
o security control impairment
o scheduled task persistence
· Conditional coverage:
o WMI persistence
· Indirect coverage:
o initial execution
· No coverage:
o command-and-control
o cloud-native activity
o static artifact detection
Traceability Integrity Validation
· All mappings reference S25-approved rules only
· No rejected detections included
· No system-level overstatement
· All mappings tied directly to:
o rule logic
o telemetry conditions
· All detection gaps preserved without inflation
S27 Behavior and Log Artifacts
Security Control Impairment (Defense Evasion)
Observable Artifacts
· Process execution modifying anti-malware configuration
· Command-line values containing Set-MpPreference
· Command-line values containing DisableRealtimeMonitoring
· Command-line values containing DisableBehaviorMonitoring
· Command-line values containing DisableIOAVProtection
· Service control events indicating service stop
· Service control events indicating service disable
Telemetry Sources
· Endpoint or EDR telemetry
· Windows Security Logs Event ID 4688
· Process creation telemetry with command-line fields
Telemetry Constraints
· Command-line logging must be enabled
· Absence of command-line logging prevents reliable detection
Scheduled Task Persistence
Observable Artifacts
· Scheduled task creation events
· Scheduled task registration events
· Scheduled task modification events
· Task name field
· Task execution path field
· Task user context field
Telemetry Sources
· Windows Security Logs Event ID 4698
· Task Scheduler Operational Logs Event ID 106
· Task Scheduler Operational Logs Event ID 140
· EDR persistence telemetry
Telemetry Constraints
· Scheduled task logging must be enabled
· Loss of task metadata reduces detection confidence
WMI Persistence
Observable Artifacts
· WMI event filter creation
· WMI event consumer creation
· WMI filter-to-consumer binding creation
Telemetry Sources
· Windows WMI-Activity Logs
· Event ID 5860
· Event ID 5861
Telemetry Constraints
· WMI logging must be enabled and retained
· Default configurations may not provide sufficient visibility
Initial Execution
Observable Artifacts
· Process creation events
· Command-line arguments where available
· Parent-child process relationships
Telemetry Sources
· Endpoint or EDR telemetry
· Windows Security Logs Event ID 4688
Telemetry Constraints
· Execution alone is not a high-confidence signal
· Detection requires correlation with persistence or defense evasion
Command-and-Control / Beaconing
Observable Artifacts
· Repetitive outbound connections
· Periodic connection intervals
· DNS resolution activity
Telemetry Sources
· Network telemetry
· DNS logs
· Proxy logs
Telemetry Constraints
· Network telemetry alone is insufficient for reliable detection
· High benign overlap limits confidence
Summary
· High-confidence telemetry exists for defense evasion
· High-confidence telemetry exists for scheduled task persistence
· Conditional telemetry exists for WMI persistence
· Insufficient telemetry exists for execution-only detection
· Insufficient telemetry exists for network-only detection
Figure 5
S28 Detection Strategy and SOC Implementation Guidance
Detection Strategy
· Prioritize detection of security control impairment
· Prioritize detection of persistence creation
· Treat execution-only activity as supporting context
· Do not use network-only signals as primary detection
Detection Preconditions
· Command-line logging must be enabled
· Scheduled task telemetry must be enabled
· WMI logging must be enabled for WMI detection
· SIEM normalization must preserve host identity
· SIEM normalization must preserve event sequencing
Alert Prioritization
· High priority assigned to impairment combined with persistence
· Medium priority assigned to scheduled task creation after allowlisting
· Conditional priority assigned to WMI persistence
Tuning Requirements
· Allowlists must be created for software deployment systems
· Allowlists must be created for administrative automation
· Allowlists must be created for security tooling
· Telemetry completeness must be validated
· Field normalization must be validated
Investigation Workflow
· Identify affected host
· Validate process lineage
· Confirm persistence mechanism
· Assess for credential access
· Assess for lateral movement
· Assess for remote access tooling
Deployment Requirements
· Enable command-line logging
· Ensure persistence telemetry coverage
· Validate SIEM ingestion and normalization
· Deploy correlation rules
· Apply environment-specific tuning
S29 Detection Coverage Summary
Strong Coverage
· Security control impairment
· Scheduled task persistence
Conditional Coverage
· WMI persistence
Dependent Coverage
· Initial execution requires persistence or defense evasion
Coverage Gaps
· Command-and-control
· Cloud-native activity
· Static and memory artifact detection
Coverage Quality
High-confidence detections
· Behavior-based detection
· Low-noise detection
· Evasion-resistant detection
Excluded detections
· Execution-only detection
· Network-only detection
· Artifact-only detection
S30 Intelligence Maturity Assessment
Attribution Status
· No confirmed threat actor attribution
· No confirmed malware family association
Confidence Level
· Moderate confidence
Assessment Basis
· Consistent behavioral patterns observed
· Alignment with initial access broker activity
· Alignment with pre-ransomware staging behavior
Adversarial Uncertainty
· Unknown operator capability
· Unknown escalation path
· Unknown follow-on objectives
Intelligence Requirements
· Reusable malware samples required
· Infrastructure reuse patterns required
· Evidence of second-stage payloads required
· Evidence of credential access required
· Evidence of lateral movement required
Maturity Summary
· Behavior is well-defined
· Attribution is not established
Status
· Formatting compliant
· No label violations
· No structural drift
· Fully aligned with S26
· Audit-ready
S31 — Telemetry Dependencies
· Process execution telemetry with full command-line visibility is required to detect suspicious execution and persistence creation activity.
· Scheduled task creation and modification telemetry is required to identify persistence through task-based mechanisms.
· WMI event subscription telemetry is required to detect stealth persistence through event-triggered execution.
· Security control state telemetry is required to detect impairment or modification of defensive tools.
· Process-to-network correlation telemetry is required to link execution and persistence activity with outbound communication.
· Consistent telemetry normalization across endpoints is required to ensure detection logic operates reliably.
· Near-real-time telemetry ingestion is required to support timely detection and containment of persistence-stage activity.
S32 — Detection Limitations
· Environments without command-line logging lack sufficient visibility into execution and persistence behavior.
· Absence of WMI telemetry creates a critical blind spot for stealth persistence mechanisms.
· Scheduled task monitoring generates high noise without environment-specific baselining, reducing detection reliability.
· Network-only detection lacks sufficient fidelity due to high overlap with legitimate outbound communication.
· Detection strategies dependent on static indicators are ineffective against behavior-driven threats.
· Correlation-dependent detection introduces delay and failure risk in environments with fragmented telemetry pipelines.
· Inconsistent endpoint coverage allows the threat to operate undetected across segments of the environment.
S33 — Defensive Control & Hardening Improvements
· Enforce command-line logging across all endpoints to ensure visibility into execution and persistence activity.
· Enable and retain WMI logging to eliminate blind spots in event-triggered persistence mechanisms.
· Implement scheduled task monitoring with environment-specific baselines to reduce false positives.
· Protect endpoint security controls from tampering through policy enforcement and monitoring.
· Establish reliable process-to-network correlation capability to identify post-compromise communication.
· Standardize telemetry collection and normalization across endpoint environments.
· Transition detection strategy toward behavior-based detection aligned to persistence and defense evasion.
S34 — Defensive Control & Hardening Architecture
Figure 6
· Endpoint telemetry collection must include process, command-line, parent-child relationships, and persistence artifacts.
· Centralized logging infrastructure must aggregate and normalize endpoint telemetry for correlation.
· Detection pipelines must support correlation of execution, persistence, and network activity on a per-host basis.
· Monitoring architecture must include visibility into scheduled tasks and WMI event subscriptions.
· Security control protection mechanisms must prevent unauthorized modification or disabling of defenses.
· Network telemetry must be integrated with endpoint data to provide context for outbound communication.
· Detection architecture must prioritize behavioral signals over static indicators.
S35 — Defensive Control Mapping Matrix
Execution Visibility
· Control Type: Endpoint Logging
· Purpose: Detect suspicious process execution and command-line activity
Persistence Detection
· Control Type: Endpoint Monitoring
· Purpose: Detect scheduled task and WMI-based persistence mechanisms
Defense Protection
· Control Type: Endpoint Security Controls
· Purpose: Detect and prevent impairment of security tools
Behavioral Detection
· Control Type: Detection Engineering
· Purpose: Identify threat activity independent of static indicators
Telemetry Correlation
· Control Type: SIEM / EDR Integration
· Purpose: Correlate execution, persistence, and network activity
Network Context
· Control Type: Network Monitoring
· Purpose: Provide supporting context for outbound communication
S36 — CyberDax Intelligence Maturity Assessment
· Low maturity environments lack command-line visibility, WMI telemetry, and persistence monitoring, resulting in inability to detect foothold establishment.
· Moderate maturity environments collect partial endpoint telemetry but lack reliable correlation between execution, persistence, and network activity.
· Higher maturity environments implement comprehensive endpoint telemetry, persistence-focused detection, and correlation pipelines.
· Intelligence maturity is determined by the ability to detect defense evasion and persistence activity in near real time.
· The primary maturity gap is telemetry completeness and integration rather than tooling availability.
S37 — Strategic Defensive Improvements
· Prioritize detection and containment of persistence-stage activity over initial execution to reduce long-term risk.
· Treat telemetry completeness as a core security requirement rather than an optional capability.
· Shift detection strategy toward behavioral signals aligned with attacker tradecraft.
· Reduce detection latency by improving correlation across telemetry sources.
· Standardize logging and monitoring across all endpoints to eliminate visibility gaps.
· Align detection engineering with observed attacker behavior rather than theoretical coverage models.
· Improve response readiness to enable immediate containment following persistence detection.
S38 — Attack Economics & Organizational Impact Model
Figure 7
· The economic impact of this threat is driven by the transition from initial execution to persistent foothold establishment rather than immediate payload delivery.
· Early detection limits impact by preventing durable access and reducing the likelihood of follow-on intrusion activity.
· Once persistence is established, attacker effort decreases while operational flexibility increases, enabling reuse of access without reinfection.
· Security control impairment combined with persistence reduces defender visibility and increases attacker dwell time.
· Increased dwell time raises the probability of secondary activity, including credential access, remote access tooling deployment, and lateral movement.
· Defender cost increases significantly after persistence due to expanded investigation scope.
· Defender cost increases due to multi-host remediation requirements.
· Defender cost increases due to credential hygiene and access validation efforts.
· The economic model is asymmetric, with attacker cost remaining low after foothold establishment.
· Defender cost increases with each additional stage of compromise.
· The most effective cost control point is detection and containment during or immediately after persistence establishment.
S39 — Economic Impact & Organizational Exposure
· The most likely impact scenario aligns with delayed detection after persistence establishment but before large-scale lateral movement or monetization activity.
· Exposure is elevated in environments where command-line logging is incomplete.
· Exposure is elevated in environments where WMI activity is not monitored.
· Exposure is elevated in environments where scheduled task creation is not baselined.
· Exposure increases where process-to-network correlation is absent.
· Exposure increases where endpoint visibility is inconsistent across systems.
· The observed behavior indicates a scalable access acquisition model, increasing the likelihood of repeated or widespread exposure.
· The presence of sinkholed infrastructure and beaconing patterns suggests prior centralized coordination and potential reuse of access.
· Economic impact is influenced by detection delay.
· Economic impact is influenced by the number of affected endpoints.
· Economic impact is influenced by the presence of follow-on activity such as remote access tooling or credential access.
· Organizations with strong persistence detection and rapid containment capability can limit impact to localized remediation.
· Organizations lacking these capabilities face increased risk of sustained unauthorized access.
· Organizations lacking these capabilities face increased risk of follow-on intrusion activity.
· Organizations lacking these capabilities face increased risk of regulatory or operational impact depending on affected systems.
S40 — References
Vendor / Platform Documentation
· Microsoft Documentation — Windows Management Instrumentation (WMI)
https[:]//learn.microsoft.com/windows/win32/wmisdk/wmi-start-page
· Microsoft Documentation — Windows Task Scheduler
https[:]//learn.microsoft.com/windows/win32/taskschd/task-scheduler-start-page
Threat Technique Framework
· MITRE ATT&CK® Framework
https[:]//attack.mitre.org
Security Vendor Analysis
· Red Canary — WMI Persistence Explained
https[:]//redcanary.com/blog/wmi-persistence/
· CISA Cybersecurity Advisory AA23-144A
https[:]//www.cisa.gov/news-events/cybersecurity-advisories/aa23-144a
Threat Tradecraft and Intrusion Patterns
· CrowdStrike — Abuse of Legitimate Remote Management Tools
https[:]//www.crowdstrike.com/blog/how-intrusion-sets-use-legitimate-remote-management-tools/
· Mandiant — Intrusion Chain Patterns and Ransomware Precursor Activity
https[:]//www.mandiant.com/resources/blog/unc1878-ransomware
