[EXP] RMM Tool Abuse for Initial Access, Persistence, and Post-Compromise Control

Report Type:

EXP

Threat Category:

Legitimate-tool abuse / trusted remote administration misuse

Assessment Date:

April 29, 2026

Primary Impact Domain:

Remote Administration Trust Boundary and Unauthorized Access Control

Secondary Impact Domains:

Endpoint control and persistence

Identity and privileged access exposure

Service-provider and support workflow trust

Cloud-native remote management control paths

Backup and recovery assurance

Data staging, exfiltration preparation, and ransomware preparation

Governance, compliance, and third-party risk exposure

Affected Asset Class:

Enterprise endpoints, servers, cloud-hosted workloads, privileged access workstations, identity infrastructure, backup systems, security tooling, executive endpoints, regulated-data systems, production-critical systems, helpdesk systems, endpoint management platforms, RMM tenants, and service-provider administration paths.

Threat Objective Classification:

Unauthorized remote control, persistence, and post-compromise operational enablement through legitimate RMM, remote support, service-provider, endpoint management, or cloud-native remote command pathways.

BLUF

 RMM tool abuse creates material enterprise risk by allowing adversaries to use legitimate remote administration software as an initial access, persistence, and post-compromise control channel. The risk is driven by trusted-tool misuse, where signed and commonly approved support platforms can bypass malware-centric assumptions, blend into administrative activity, and preserve attacker access after initial compromise. The threat posture is elevated because unauthorized RMM activity can support credential access, lateral movement, defense evasion, data staging, backup interference, and ransomware preparation while appearing similar to normal IT operations. Executive action is required to validate approved RMM use, restrict unauthorized remote access pathways, strengthen endpoint and identity visibility, and ensure response teams can rapidly identify RMM activity outside sanctioned administrative workflows.

Executive Risk Translation

RMM abuse shifts business risk from isolated endpoint compromise to loss of confidence in remote administration, helpdesk, service-provider, and endpoint management workflows. The primary concern is that attackers may use legitimate remote support tooling to establish interactive control, configure unattended access, move laterally, disable defenses, stage data, or prepare ransomware activity while appearing similar to approved support activity. If approved RMM use, tenant ownership, session ownership, endpoint authorization, and post-session activity cannot be validated quickly, response may expand into credential review, endpoint containment, remote access suspension, service-provider validation, and broader forensic scoping. This creates financial, operational, governance, and third-party-risk exposure beyond the first affected endpoint.

S3 — Why This Matters Now

·        RMM tools are widely used for IT support, service-provider administration, break-fix operations, endpoint management, and remote troubleshooting.

·        Adversaries benefit from using legitimate signed tools because trusted remote access software can reduce prevention, reputation, and static-detection effectiveness.

·        RMM abuse can begin through phishing, fake support lures, compromised helpdesk workflows, exposed RMM infrastructure, unauthorized tenant enrollment, or endpoint management misuse.

·        Persistent or unattended RMM access can allow attackers to preserve control after the initial access method is removed.

·        RMM-launched activity can support discovery, credential access, lateral movement, file staging, security-tool tampering, backup interference, exfiltration preparation, and ransomware staging.

·        Cloud-native remote management pathways such as AWS Systems Manager, Azure Run Command, and GCP VM Manager or OS Config can create RMM-equivalent control paths when used outside approved workflows.

·        Detection must be behavior-led because product names, vendor domains, hashes, signer data, and official relay infrastructure cannot reliably distinguish legitimate support from attacker-controlled access.

·        Organizations without approved RMM baselines, endpoint telemetry, identity context, tenant validation, and support workflow visibility face elevated risk of delayed detection and incomplete scoping.

S4 — Key Judgments

·        RMM tool abuse is a legitimate-tool intrusion behavior, not a malware-only problem.

·        The primary business risk is unauthorized remote control through trusted administrative pathways.

·        Product presence alone is not sufficient to determine compromise because many RMM tools are legitimate, signed, and operationally necessary.

·        The strongest risk signal is RMM activity outside approved workflow, especially when paired with suspicious execution context, persistence, restricted endpoint scope, tenant mismatch, outbound relay activity, or post-compromise commands.

·        Unauthorized unattended access materially increases risk because it can preserve attacker control after the initial access event.

·        RMM-launched post-compromise behavior is the strongest indicator that remote access has transitioned into active intrusion operations.

·        Network-only RMM visibility has limited confidence without endpoint, identity, asset, tenant, and support workflow context.

·        Cloud-native remote management abuse must be treated as conditional RMM-equivalent behavior where cloud audit logs show unauthorized remote command, metadata execution, or setup-to-control activity.

·        YARA and file-content matching are not production-viable for generic RMM abuse unless a malicious wrapper, trojanized installer, dropper, or campaign-specific artifact is recovered.

·        Executive risk reduction depends on approved RMM inventory, restricted endpoint policy, remote support governance, endpoint telemetry, identity monitoring, and rapid validation of support-session legitimacy.

S5 — Executive Risk Summary

Business Risk

RMM tool abuse can undermine confidence in the organization’s remote administration model by allowing adversaries to use legitimate support tooling for unauthorized access, persistence, command execution, lateral movement, and ransomware preparation. Risk increases when RMM activity occurs on identity systems, backup infrastructure, privileged access workstations, executive endpoints, security tooling, regulated-data systems, cloud workloads, or production-critical servers.

Technical Cause

The risk is driven by adversary use of legitimate remote support tools, unauthorized tenants, attacker-generated support sessions, unattended-access configuration, suspicious installation paths, compromised administrative workflows, or cloud-native remote command features to establish remote-control capability outside approved operations. Because these tools may be signed, vendor-hosted, encrypted, and commonly allowed, traditional malware-centric controls may not detect the activity until suspicious endpoint, identity, network, persistence, or post-compromise behavior appears.

Threat Posture

The threat posture is elevated because RMM abuse supports multiple intrusion phases, including initial access, persistence, command execution, discovery, credential access, lateral movement, defense evasion, data staging, and ransomware preparation. Adversaries can reduce visibility by using official vendor infrastructure, approved-looking binaries, renamed executables, compromised helpdesk accounts, service-provider pathways, endpoint management systems, or cloud-native administrative channels.

Executive Decision Requirement

Executives must require a current approved RMM inventory, explicit restrictions on where RMM is permitted, validation of support and service-provider workflows, centralized visibility into RMM execution and persistence, and detection coverage that distinguishes approved administration from unauthorized remote control. Response leadership should also require rapid procedures for validating tenant ownership, session ownership, endpoint authorization, command activity, and follow-on intrusion behavior.

S6 — Executive Cost Summary

RMM tool abuse creates financial exposure based on detection latency, endpoint criticality, persistence depth, credential exposure, lateral movement, service-provider involvement, cloud-native remote management misuse, and the ability to confirm whether activity was approved or attacker-controlled. Financial impact increases when unauthorized remote access affects restricted systems, creates unattended access, weakens recovery options, or forces the organization to validate trust across endpoints, identities, support workflows, cloud workloads, and third-party administration paths.

Low Impact Scenario

Suspicious RMM activity is detected early on a limited endpoint population, and investigation confirms no unauthorized unattended access, no credential access, no lateral movement, no data staging, no cloud-control misuse, no backup interference, and no ransomware-preparation behavior; estimated impact $150K to $500K.

Moderate Impact Scenario

Unauthorized RMM execution or persistence affects a limited but meaningful set of endpoints, requiring endpoint containment, support workflow validation, RMM tenant review, credential review, detection tuning, helpdesk or service-provider coordination, selective remediation, and executive incident coordination; estimated impact $750K to $5M.

High Impact Scenario

RMM abuse enables persistent remote control, credential access, lateral movement, security-tool tampering, backup interference, data staging, cloud-native remote command abuse, or ransomware preparation across high-value systems, requiring enterprise incident response, broad credential rotation, remote access suspension, service-provider validation, endpoint rebuilds, legal or regulatory review, recovery assurance, and executive incident governance; estimated impact $7.5M to $50M or higher.

S6A — Key Cost Drivers

·        Number and criticality of affected endpoints, servers, cloud workloads, or restricted systems.

·        Time from RMM introduction to detection and containment.

·        Whether unattended access, service creation, scheduled tasks, registry autoruns, or persistent agents were created.

·        Whether RMM activity occurred on identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, or production-critical workloads.

·        Evidence of RMM-launched discovery, credential access, lateral movement, security-tool tampering, backup interference, file staging, or ransomware preparation.

·        Scope of credential review, password reset, token revocation, session invalidation, or privileged access validation.

·        Ability to validate approved support workflow, support ticket, session owner, tenant association, management server, and deployment path.

·        Availability of endpoint process telemetry, command-line logging, software inventory, DNS or proxy logs, identity telemetry, cloud audit logs, and RMM platform audit logs.

·        Involvement of service providers, third-party support providers, downstream customer environments, or shared administrative infrastructure.

·        Need to suspend, restrict, replace, or re-baseline remote administration tooling during response.

·        Legal, regulatory, insurance, customer assurance, and board-level incident governance requirements.

Most Likely Scenario Justification

Moderate scenario is most likely for unauthorized RMM activity because legitimate-tool abuse often creates a meaningful validation burden even when enterprise-wide compromise is not confirmed. The estimate moves toward the lower end when telemetry confirms rapid containment, no persistence, no tenant mismatch, no credential access, no lateral movement, no backup interference, and no high-value system impact. The estimate moves toward the upper end when unattended access is configured, support workflow ownership is unclear, command-line visibility is incomplete, privileged systems are involved, service-provider access must be validated, recovery assurance is required, or post-compromise activity cannot be ruled out.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether RMM abuse results in unauthorized access to regulated data, privileged systems, customer environments, cloud workloads, endpoint management systems, or business-critical infrastructure.

Risk Register Entry

Risk Title

Unauthorized Remote Management Tool Abuse for Initial Access, Persistence, and Post-Compromise Control

Risk Description

Adversaries may use legitimate remote management and remote support tooling to establish unauthorized access, configure persistent unattended control, blend into approved administrative workflows, execute commands, move laterally, weaken defenses, stage data, or prepare ransomware activity.

Likelihood

High.

Impact

High.

Risk Rating

High.

Annualized Risk Exposure

Estimated $2M to $12.5M or higher based on RMM exposure, endpoint criticality, service-provider involvement, persistence depth, telemetry gaps, detection delay, credential review scope, recovery assurance requirements, and post-compromise activity.

S7 — Risk Drivers

·        Broad enterprise reliance on remote support, helpdesk, service-provider, endpoint management, and break-fix tooling.

·        Legitimate signed RMM binaries that may not trigger malware or reputation controls.

·        User-driven RMM installation through fake support lures, phishing, browser downloads, collaboration tools, or social engineering.

·        Unauthorized unattended-access configuration that preserves attacker control.

·        RMM execution from suspicious parent processes or user-controlled paths.

·        RMM activity on restricted systems where remote support is prohibited or tightly controlled.

·        Tenant mismatch, unknown management server, unauthorized support session, or attacker-generated installer activity.

·        RMM-launched discovery, credential access, lateral movement, file staging, backup interference, defense evasion, or ransomware-preparation commands.

·        Limited endpoint process visibility, command-line telemetry, software inventory, DNS or proxy logs, and RMM platform audit logging.

·        Incomplete approved RMM inventory, support workflow baseline, tenant ownership mapping, or service-provider governance.

·        Cloud-native remote command pathways that can provide RMM-equivalent control over workloads.

·        Network-only visibility that cannot reliably determine process, user, session owner, tenant, or authorization context.

·        Over-reliance on product allowlists rather than behavior, endpoint role, support context, and post-session activity.

S8 — Bottom Line for Executives

RMM tool abuse should be treated as a high-priority trusted-tool control risk because attackers can use legitimate remote support software to gain access, preserve control, and conduct post-compromise activity while appearing similar to normal administration. The key executive concern is not whether RMM tools exist in the environment, but whether their use is authorized, scoped, attributable, monitored, and separated from attacker-controlled remote access. Risk reduction depends on approved RMM inventory, restricted endpoint policy, support workflow validation, endpoint and identity telemetry, cloud audit visibility, and rapid detection of persistence or high-risk commands after RMM activity. Organizations should prioritize RMM governance as both a security operations issue and a business resilience issue because unauthorized remote access can quickly escalate into credential compromise, operational disruption, ransomware preparation, or third-party exposure.

S9 — Board-Level Takeaway

RMM tool abuse turns trusted remote administration into part of the attack surface. The board-level risk is that attackers may use legitimate support tools, approved-looking binaries, service-provider pathways, or cloud-native command features to establish remote control and delay detection. Leadership should require evidence that RMM use is inventoried, restricted, monitored, attributable, and validated against approved support workflows. This report supports governance decisions around remote administration risk, service-provider oversight, endpoint visibility, identity assurance, and detection readiness for legitimate-tool intrusion behavior.

Figure 2

S10 — Threat Overview

RMM tool abuse is a legitimate-tool intrusion behavior in which adversaries use remote monitoring, remote management, remote support, or remote-control software to gain, preserve, or operate interactive access inside an organization. The core threat is not the existence of RMM software itself. The core threat is unauthorized use of remote administration capability outside approved support, helpdesk, endpoint management, service-provider, or cloud administration workflows.

Adversaries may introduce RMM tooling through phishing, fake support lures, browser downloads, collaboration-tool links, software deployment abuse, exposed RMM infrastructure, compromised helpdesk identities, service-provider pathways, or cloud-native management actions. Once established, RMM access can provide interactive control, file transfer, remote shell access, unattended access, reboot capability, persistence, or an operational foothold for follow-on intrusion activity.

This threat is difficult to manage because RMM tools are often signed, vendor-hosted, encrypted, common in enterprise environments, and permitted for legitimate administration. Traditional malware controls may not block the software, and network activity may use official relay infrastructure. Detection and response therefore depend on whether the tool, tenant, user, endpoint, source, deployment path, persistence behavior, and follow-on commands align with approved administrative intent.

RMM abuse can support multiple intrusion phases. It can provide initial access when users are convinced to install a support tool. It can provide persistence when unattended access, services, scheduled tasks, or auto-start behavior are configured. It can provide post-compromise control when adversaries use the RMM session to execute commands, access credentials, move laterally, tamper with defenses, stage files, interfere with backups, or prepare ransomware activity.

Cloud-native remote management features can create similar risk when used outside approved workflows. AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata-based execution, and similar control-plane functions can provide remote command or management capability without a traditional third-party RMM binary. These pathways should be treated as RMM-equivalent behavior only when cloud telemetry shows unauthorized remote command, setup-to-control activity, metadata execution, or management action against workloads outside approved administrative scope.

S11 — Threat Classification and Type

Threat Type

Legitimate-tool abuse and trusted administrative channel misuse.

Threat Sub-Type

Remote monitoring and management tool abuse for unauthorized access, persistence, and post-compromise control.

Operational Classification

Enterprise intrusion-enabling behavior involving approved-looking remote administration tooling, service-provider workflows, endpoint management pathways, and cloud-native remote management channels.

Primary Function

The primary function is to provide adversaries with interactive or persistent remote control while blending into normal administrative operations. This control can support initial access, durable access, command execution, credential access, lateral movement, defense evasion, data staging, backup interference, and ransomware preparation.

S12 — Campaign or Activity Overview

RMM tool abuse is not limited to a single campaign, malware family, product, or intrusion set. It is a recurring operational pattern used across financially motivated intrusions, ransomware operations, business email compromise follow-on activity, helpdesk impersonation, social engineering, service-provider compromise, and hands-on-keyboard intrusions. The shared behavior is adversary use of legitimate remote administration capability to avoid obvious malware indicators and operate through trusted tooling.

Activity commonly begins with one of several access paths. In user-driven cases, the victim may be directed to download or run a remote support client through a fake support page, phishing message, collaboration-tool link, or social engineering interaction. In administrative-abuse cases, an adversary may use compromised credentials, helpdesk accounts, endpoint management systems, or service-provider access to push or enable remote-control tooling. In infrastructure-abuse cases, exposed or misconfigured RMM infrastructure may be used to generate installers, create support sessions, modify tenants, enroll agents, or reach downstream endpoints.

After RMM capability is established, the activity may remain low-noise while the adversary validates access, confirms host context, or waits for an operational window. Higher-risk activity occurs when the RMM session is used to create unattended access, install persistent agents, launch command shells, enumerate users and systems, access credentials, transfer tools, stage data, disable security controls, interfere with backup or recovery, or prepare ransomware deployment.

The same activity pattern can appear in cloud environments without a classic RMM product. An adversary with sufficient cloud permissions may use native remote command or workload management features to execute commands, change metadata, enable management access, or stage tooling on cloud-hosted workloads. These cases should be evaluated through the same control-channel lens: whether remote administration capability was used by an approved principal, against an approved target, through an approved workflow, and without suspicious follow-on behavior.

S13 — Targets and Exposure Surface

The primary exposure surface includes endpoints, servers, cloud workloads, identity systems, service-provider administration paths, and remote support workflows where RMM activity is permitted, partially permitted, poorly governed, or difficult to distinguish from attacker-controlled access.

High-value target classes include identity infrastructure, domain controllers, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, cloud management systems, virtual desktop environments, developer systems, production servers, and endpoints used by helpdesk or administrative personnel. Risk is elevated where these systems allow direct remote support, where RMM activity is not restricted by endpoint role, or where support sessions cannot be tied to an approved user, ticket, tenant, or workflow.

The exposure surface also includes authorized RMM tenants, management servers, relay infrastructure, support portals, endpoint management platforms, remote command features, service-provider workflows, and cloud-native workload management functions. These administrative paths can become intrusion channels if credentials are compromised, support workflows are impersonated, tenant associations are changed, or remote access is enabled outside approved processes.

Organizations with incomplete RMM inventories face higher exposure because they may not know which tools, tenants, endpoints, service providers, management servers, support users, or deployment paths are legitimate. Incomplete visibility into endpoint process telemetry, command-line activity, software inventory, DNS or proxy logs, identity telemetry, RMM platform audit logs, and cloud audit logs further expands the practical attack surface by making unauthorized use harder to validate.

S14 — Sectors / Countries Affected

Sectors Affected

RMM tool abuse can affect any sector that uses remote administration, helpdesk support, outsourced IT, endpoint management, cloud workloads, or service-provider access. Exposure is especially material in sectors with distributed workforces, regulated systems, high availability requirements, sensitive data, or heavy reliance on third-party administration.

The most exposed sectors include:

·        Healthcare and life sciences, where endpoint disruption, regulated data exposure, and operational continuity create high impact.

·        Financial services, where privileged endpoint access, customer data, fraud risk, and regulatory scrutiny increase consequence.

·        Government and public sector organizations, where remote administration misuse can affect mission systems and citizen services.

·        Education, where distributed endpoints, varied IT maturity, and broad remote support needs increase attack surface.

·        Manufacturing and industrial organizations, where remote support access can intersect with production systems, engineering workstations, and operational continuity.

·        Legal, professional services, and consulting organizations, where sensitive client data and third-party obligations increase impact.

·        Technology, software, and cloud service providers, where service-provider access, customer administration, and developer systems can create downstream exposure.

·        Retail, hospitality, and distributed enterprises, where remote management is often required across many locations and endpoints.

·        Managed service providers and IT service providers, where compromise or misuse can affect multiple customer environments.

·        Critical infrastructure operators, where remote administration pathways can intersect with sensitive operational, support, or monitoring environments.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because RMM, remote support, endpoint management, service-provider administration, cloud workload management, and remote troubleshooting platforms are broadly deployed across enterprise environments.

·        Countries with large enterprise technology footprints, regulated industries, distributed workforces, cloud-hosted workloads, service-provider ecosystems, or high-value public and private sector environments may face elevated operational exposure.

·        Country-specific impact should be assessed by remote administration governance, approved RMM inventory maturity, service-provider oversight, endpoint telemetry quality, identity controls, cloud audit visibility, support workflow validation, and incident response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High.

Technical Sophistication

RMM abuse does not always require advanced malware development, but effective operational use requires knowledge of remote support workflows, endpoint behavior, identity access, helpdesk processes, and post-compromise objectives. Lower-sophistication actors may rely on fake support lures or user-driven installation. More capable actors may abuse compromised administrative accounts, service-provider access, endpoint management systems, RMM tenants, cloud-native remote command features, or exposed RMM infrastructure.

Infrastructure Maturity

Moderate to High.

Adversaries can use official vendor infrastructure, legitimate cloud relay services, attacker-controlled tenants, temporary support sessions, compromised service-provider infrastructure, or cloud-native management channels. This reduces the need for custom command-and-control infrastructure and makes malicious activity harder to distinguish from legitimate administration. Mature actors may also use tool stacking, tenant switching, infrastructure rotation, or multiple remote access methods to preserve access.

Operational Scale

Moderate to High.

RMM abuse can occur as a single-user support-lure event, a limited endpoint intrusion, a targeted high-value system compromise, or a broader enterprise or service-provider intrusion. Scale increases when the actor controls administrative credentials, endpoint management systems, RMM tenant access, service-provider accounts, or cloud management permissions. In service-provider scenarios, impact can extend across multiple customer environments.

Escalation Likelihood

High when RMM activity includes unattended-access configuration, persistence creation, high-risk command execution, credential access, lateral movement, backup interference, security-tool tampering, or data staging. Escalation likelihood is also high when activity affects identity infrastructure, backup systems, privileged access workstations, executive endpoints, cloud management systems, service-provider administration paths, or production-critical workloads.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High.

RMM tool abuse has high targeting probability because remote administration tooling is common, trusted, and operationally necessary across enterprise environments. Adversaries can exploit this trust through user-driven installation, helpdesk impersonation, compromised credentials, service-provider workflows, endpoint management abuse, or cloud-native administrative channels. The behavior is attractive because it can reduce malware dependence, preserve interactive control, and blend into normal IT activity.

Targeting Drivers

·        Broad use of RMM and remote support platforms across enterprise IT operations.

·        Continued reliance on remote work, distributed endpoints, outsourced support, and service-provider administration.

·        Trust placed in signed remote support binaries and official vendor infrastructure.

·        Gaps in approved RMM inventory, tenant mapping, endpoint authorization, and support workflow validation.

·        Availability of phishing, fake support, and social engineering paths that can lead users to install remote support tools.

·        Potential for unattended access, persistent agents, and remote-control configuration to preserve adversary access.

·        Value of using RMM as a low-friction post-compromise control channel.

·        Opportunity to reach high-value systems through helpdesk, service-provider, endpoint management, or privileged support workflows.

·        Ability to use cloud-native remote command features where cloud identity and workload controls are weak.

·        Difficulty many organizations face in distinguishing legitimate support activity from attacker-controlled remote access.

Most Likely Targets

·        User workstations exposed to phishing, fake support lures, collaboration links, or browser-based downloads.

·        Helpdesk, IT support, and endpoint administration systems.

·        Privileged access workstations and administrative jump hosts.

·        Identity infrastructure and domain-connected systems.

·        Backup servers and recovery infrastructure.

·        Security tooling and monitoring infrastructure.

·        Executive endpoints and high-value user systems.

·        Regulated-data systems and sensitive business applications.

·        Cloud-hosted workloads with remote command or metadata execution exposure.

·        Virtual desktop infrastructure and remote work platforms.

·        Managed service providers, IT service providers, and organizations with delegated administration across customer environments.

·        Production servers where remote support is permitted or insufficiently restricted.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Access Path and RMM Introduction

The adversary establishes a path for remote administration capability through social engineering, fake support interaction, phishing, compromised support workflow, exposed RMM infrastructure, service-provider access, or endpoint management misuse. The objective is to introduce or enable a legitimate remote access tool or trusted administrative pathway that can reach the target environment.

·        T1566.002 — Spearphishing Link.

·        T1204.002 — Malicious File.

·        T1219 — Remote Access Software.

·        T1078 — Valid Accounts.

Stage 2 — Remote-Control Execution

The adversary runs or enables the RMM tool to create interactive access. Execution may occur from a user-controlled path, browser download location, temporary directory, collaboration-tool staging path, endpoint management action, or cloud workload management path. Maliciousness depends on context, authorization, tenant ownership, endpoint role, and workflow alignment rather than the binary alone.

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

Stage 3 — Persistence and Unattended Access

The adversary converts temporary access into durable control by installing an agent, creating or modifying services, registering scheduled tasks, configuring auto-start behavior, enabling unattended access, enrolling the endpoint into an unauthorized tenant, or establishing reconnect capability. This stage increases risk because remote access can survive user logout, reboot, tool removal attempts, or the end of the initial support session.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1547.001 — Registry Run Keys / Startup Folder.

Stage 4 — Discovery and Credential Targeting

After remote-control capability is established, the adversary uses the session to inspect the environment, enumerate users and systems, identify privileges, discover security tools, locate backup systems, or access credential material. This stage indicates that remote access has transitioned from tool presence into active intrusion operations.

·        T1087 — Account Discovery.

·        T1069 — Permission Groups Discovery.

·        T1003 — OS Credential Dumping.

Stage 5 — Lateral Movement and Expansion

The adversary uses information gathered through the RMM session to expand access through remote services, service creation, scheduled tasks, administrative shares, credential reuse, endpoint management systems, service-provider pathways, or cloud-native administrative channels. Expansion may remain within one organization or extend across downstream environments if service-provider access is involved.

·        T1021 — Remote Services.

·        T1078 — Valid Accounts.

·        T1543.003 — Windows Service.

Stage 6 — Defense Evasion and Recovery Interference

The adversary uses remote-control access to weaken defenses, stop services, alter logging, create exclusions, interfere with recovery, stage archives, transfer tools, or prepare data for exfiltration. This stage materially increases business impact because it can reduce response confidence, impair recovery, and support ransomware preparation.

·        T1562.001 — Impair Defenses.

·        T1070.001 — Clear Windows Event Logs.

·        T1490 — Inhibit System Recovery.

Stage 7 — Impact Preparation or Operational Impact

The adversary uses the remote-control channel and follow-on access to prepare ransomware deployment, support data theft, disrupt recovery, expand execution, or produce operational impact. RMM may remain the primary control channel or serve as one of several access methods used alongside scripts, remote services, cloud management features, or additional remote access tools.

·        T1486 — Data Encrypted for Impact.

·        T1490 — Inhibit System Recovery.

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Attack Path Overview

RMM tool abuse progresses through a control-channel sequence rather than a malware-only execution path. The adversary objective is to introduce or enable remote administration capability, convert that capability into reliable access, and use the resulting control channel to conduct discovery, credential access, lateral movement, defense evasion, data staging, backup interference, or ransomware preparation.

The key analytical distinction is that the RMM tool may be legitimate. Risk is created when remote administration activity occurs outside approved support workflow, endpoint authorization, tenant ownership, service-provider governance, cloud workload policy, or expected administrative behavior.

Stage 1 — Access Path Establishment

The adversary establishes a path to introduce or enable remote access. This may occur through phishing, fake support interaction, browser download, collaboration-tool delivery, compromised helpdesk identity, service-provider access, endpoint management misuse, exposed RMM infrastructure, or cloud-native workload management activity.

Relevant signals include user-driven download activity, RMM-themed support lures, execution from user-controlled paths, suspicious parent processes, unexpected support-session generation, exposed RMM management activity, endpoint management actions, or cloud audit events that precede remote-control enablement.

Stage 2 — RMM Execution or Remote-Control Enablement

The adversary executes a remote support client, installs an RMM agent, initiates a support session, enables cloud-native remote command capability, or uses an existing remote administration pathway. The activity may appear benign if viewed only as product execution because the binary may be signed, vendor-hosted, and common in enterprise environments.

Relevant signals include RMM execution from downloads, temporary directories, browser cache, cloud-synced folders, archive extraction paths, or non-standard administrative locations. Additional signals include execution by ordinary users, unexpected service accounts, non-standard support identities, suspicious parent processes, unauthorized tenant association, or activity on systems where RMM is prohibited.

Stage 3 — Persistence or Unattended Access

The adversary strengthens control by creating a durable remote access path. This may include service creation, scheduled task creation, registry autorun modification, auto-start behavior, unattended-access enablement, persistent agent installation, endpoint enrollment, reconnect behavior, or cloud-native setup-to-control changes.

Relevant signals include new RMM services, scheduled tasks, startup entries, unattended-access settings, agent registration, tenant changes, instance profile changes, managed identity changes, service-account changes, metadata changes, or remote management enablement followed by remote-control activity.

Stage 4 — Control Validation and Environment Discovery

The adversary validates remote-control access and begins assessing the environment. This may include enumerating local users, domain users, groups, sessions, privileges, host role, security tools, backup systems, network shares, cloud resources, or administrative scope.

Relevant signals include RMM-launched shells, discovery commands, user and group enumeration, domain queries, privilege checks, endpoint role inspection, cloud resource enumeration, and activity that occurs shortly after RMM execution, support-session creation, or remote command enablement.

Stage 5 — Credential Targeting and Expansion Preparation

The adversary uses the control channel to identify or access credentials, determine privileged access opportunities, and prepare expansion. This may include LSASS targeting, credential tool staging, browser credential access, service-account discovery, privileged group inspection, administrative share access, or validation of reusable credentials.

Relevant signals include credential-access process activity, suspicious handle access, credential file access, use of credential dumping utilities, administrative share activity, privileged authentication after RMM activity, unusual helpdesk or service-account use, and RMM-associated commands that inspect identity or access scope.

Stage 6 — Lateral Movement and Operational Expansion

The adversary expands from the initial access point to additional systems or administrative scopes. Expansion may use remote services, service creation, scheduled tasks, endpoint management platforms, service-provider pathways, cloud-native remote command features, or credential reuse.

Relevant signals include remote service creation, scheduled tasks against remote systems, privileged logons from RMM-associated endpoints, administrative share access, new RMM installations across multiple systems, tool stacking, endpoint management pushes, cross-account or cross-project cloud activity, and repeated remote-control activity across endpoint groups or customer environments.

Stage 7 — Defense Evasion, Recovery Interference, and Staging

The adversary uses the remote-control channel to reduce visibility, weaken response, interfere with recovery, or stage data and tools. This may include stopping services, clearing logs, weakening audit policy, creating exclusions, disabling recovery options, deleting shadow copies, interfering with backup agents, staging archives, or transferring tooling.

Relevant signals include RMM-launched service-control commands, logging changes, endpoint protection exclusions, backup interference commands, recovery setting changes, archive tooling, file staging, unusual upload behavior, and activity on backup systems, security tooling, identity systems, or production-critical workloads.

Stage 8 — Impact Preparation or Operational Impact

The adversary uses established access to prepare or execute final objectives. In ransomware-oriented activity, this may include payload staging, broad execution preparation, backup disruption, recovery inhibition, data theft support, or encryption activity. In non-ransomware activity, impact may include persistent unauthorized access, data exposure, operational disruption, downstream customer risk, or continued service-provider abuse.

Relevant signals include ransomware-preparation commands, mass file activity, broad remote execution, backup disruption, high-volume data staging, exfiltration support, encryption indicators, remote access across high-value systems, and unresolved RMM tenant, session, or service-provider ownership.

S19 — Attack Chain Risk Amplification Summary

Risk Amplification Overview

RMM tool abuse amplifies risk because the adversary operates through trusted administrative channels rather than clearly malicious tooling. Each stage of the attack chain increases business exposure when the organization cannot prove whether remote administration activity was authorized, attributable, scoped, and consistent with approved support workflow.

The primary amplification factor is control ambiguity. A signed RMM binary, official vendor relay, helpdesk session, service-provider connection, or cloud-native remote command event may appear legitimate until correlated with endpoint role, tenant ownership, support ticket, identity context, persistence state, and follow-on commands.

Amplification Factor 1 — Trusted Tool Execution

Legitimate RMM tools reduce the reliability of malware-centric controls. Signed binaries, official vendor infrastructure, and common enterprise use can allow remote access activity to avoid immediate prevention or appear operationally normal.

Business risk increases when the organization relies on product presence, vendor reputation, or allowlists rather than validating authorized use, endpoint scope, tenant ownership, and session context.

Amplification Factor 2 — Support Workflow Ambiguity

RMM activity can resemble helpdesk, service-provider, break-fix, or endpoint management activity. This creates triage delay when support tickets, session ownership, tenant identifiers, management servers, deployment paths, or approved support users are not clearly documented.

Business risk increases when analysts must spend time proving whether the activity was legitimate while the adversary may retain interactive control.

Amplification Factor 3 — Persistence Through Unattended Access

Temporary remote support becomes more dangerous when converted into durable control. Services, scheduled tasks, auto-start settings, unattended access, agent enrollment, or reconnect behavior can allow access to persist after user interaction ends.

Business risk increases because the organization must validate whether the access path survived reboot, user logout, support-session closure, or initial remediation.

Amplification Factor 4 — Privileged System Exposure

RMM activity on identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, cloud management systems, or production-critical workloads materially increases impact potential.

Business risk increases because these systems can support credential exposure, recovery disruption, monitoring impairment, business interruption, or broad operational compromise.

Amplification Factor 5 — Post-Compromise Command Execution

RMM-launched discovery, credential access, lateral movement, defense evasion, backup interference, file staging, or ransomware-preparation commands indicate that remote access has transitioned into active intrusion operations.

Business risk increases because the event is no longer limited to tool presence or support-session ambiguity; it becomes evidence of adversary-directed activity.

Amplification Factor 6 — Service-Provider and Downstream Exposure

RMM abuse involving service-provider access, delegated administration, shared support infrastructure, or downstream customer environments can expand impact beyond one organization.

Business risk increases because response may require service-provider validation, customer assurance, credential review, contractual review, and broader third-party-risk governance.

Amplification Factor 7 — Cloud-Native Remote Management Misuse

Cloud-native remote management features can provide RMM-equivalent control without a traditional third-party RMM binary. Unauthorized use of AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, or similar features can bypass assumptions that RMM abuse must appear as endpoint software.

Business risk increases when cloud audit logs, workload telemetry, identity context, and workload tagging are insufficient to prove whether remote command activity was authorized.

Amplification Factor 8 — Recovery and Assurance Burden

When RMM abuse involves persistence, credential exposure, backup interference, security-tool tampering, or service-provider ambiguity, response expands from containment to assurance. The organization must prove that access was removed, credentials were secured, endpoints are trustworthy, backups remain viable, and support workflows are not compromised.

Business risk increases because recovery confidence becomes dependent on telemetry quality, endpoint integrity, identity assurance, cloud audit visibility, and service-provider cooperation.

Figure 3

S20 — Tactics, Techniques, and Procedures

TTP Overview

RMM tool abuse uses legitimate remote administration capability to achieve intrusion objectives while reducing reliance on malware or custom command-and-control infrastructure. The procedures below describe the operational behaviors most relevant to this report and should be interpreted through authorization, endpoint role, tenant ownership, support workflow, identity context, persistence, and follow-on activity.

Initial Access Procedures

·        Use phishing, fake support pages, collaboration links, or social engineering to convince users to download and run a remote support client.

·        Abuse compromised helpdesk, technician, administrative, or service-provider credentials to initiate support sessions or deploy RMM tooling.

·        Exploit exposed or weakly controlled RMM infrastructure to generate installers, create sessions, modify tenants, or enroll endpoints.

·        Use endpoint management, virtual desktop, or cloud workload management paths to introduce remote-control capability.

Execution Procedures

·        Run signed RMM tools from downloads folders, temporary directories, user profiles, browser cache, archive extraction paths, or cloud-synced folders.

·        Launch RMM tooling through browsers, email clients, collaboration tools, archive utilities, document readers, shells, script interpreters, or endpoint management agents.

·        Use cloud-native remote command features to execute commands on workloads without deploying a traditional third-party RMM binary.

·        Use portable support clients or temporary session tools to reduce installation artifacts.

Persistence Procedures

·        Install persistent RMM agents or configure unattended access.

·        Create or modify services, scheduled tasks, registry autoruns, startup entries, launch agents, or remote-control configuration artifacts.

·        Enroll endpoints into unauthorized tenants, unknown management servers, or attacker-controlled support sessions.

·        Configure reconnect behavior, silent access, auto-start behavior, or persistent remote shell capability.

Privilege and Identity Procedures

·        Use valid accounts, compromised helpdesk identities, service-provider accounts, service accounts, managed identities, or cloud roles to legitimize remote administration activity.

·        Inspect local and domain users, groups, privileges, active sessions, and administrative scope after RMM access is established.

·        Use RMM-controlled access to validate credentials, identify privileged users, or access credential material.

·        Expand access through credential reuse, privileged authentication, or administrative workflow abuse.

Discovery Procedures

·        Enumerate local system information, domain membership, users, groups, sessions, network shares, installed tools, security products, backup systems, and cloud resources.

·        Use RMM-launched shells or scripts to identify high-value systems and reachable administrative targets.

·        Inspect endpoint role, user privileges, network connectivity, and security controls before lateral movement or staging.

·        Identify systems where RMM use is permitted, restricted, or poorly governed.

Lateral Movement Procedures

·        Use remote services, administrative shares, scheduled tasks, service creation, endpoint management platforms, or credential reuse to expand access.

·        Deploy RMM or secondary remote access tools to additional hosts.

·        Move through service-provider or delegated administration pathways when access spans multiple customer or business-unit environments.

·        Use cloud-native remote command or workload management functions to reach cloud-hosted systems.

Defense Evasion Procedures

·        Use trusted signed tools and official relay infrastructure to reduce suspicion.

·        Rename binaries, use portable clients, alter file paths, or run from user-controlled locations.

·        Stop services, weaken logging, create exclusions, interfere with endpoint security tooling, or reduce telemetry quality.

·        Operate through approved-looking helpdesk, service-provider, endpoint management, or cloud administration workflows.

Collection and Staging Procedures

·        Use RMM file transfer, remote shell, archive utilities, or cloud workload access to stage files and tools.

·        Collect data from user profiles, file shares, regulated-data locations, finance systems, source repositories, or business applications.

·        Prepare archives, move files, or stage data before exfiltration or ransomware deployment.

·        Use RMM sessions to transfer additional utilities, scripts, or payloads.

Impact Procedures

·        Interfere with backups, delete recovery artifacts, stop services, disable recovery settings, or weaken recovery options.

·        Prepare ransomware deployment through broad remote execution, payload staging, or security-tool tampering.

·        Use established remote-control access to support encryption, operational disruption, data theft, or continued unauthorized access.

·        Maintain alternate access through tool stacking or multiple remote administration pathways.

S20A — Adversary Tradecraft Summary

Tradecraft Overview

The defining tradecraft in this report is adversary use of legitimate remote administration capability to reduce detection friction, preserve access, and operate through trusted workflows. RMM abuse is effective because it exploits the gap between software legitimacy and session legitimacy. A tool can be approved, signed, and vendor-hosted while the specific user, tenant, endpoint, session, deployment path, or command activity is unauthorized.

Key Tradecraft Characteristics

·        The adversary uses trusted remote administration tooling rather than relying only on malware.

·        The adversary benefits from official vendor infrastructure, signed binaries, encrypted sessions, and normal helpdesk activity patterns.

·        The adversary may introduce RMM through user-driven installation, compromised support workflows, service-provider pathways, endpoint management systems, exposed RMM infrastructure, or cloud-native administrative channels.

·        The adversary seeks durable control through unattended access, persistence, reconnect behavior, tenant enrollment, or management configuration changes.

·        The adversary uses RMM sessions to launch post-compromise commands, inspect identity scope, move laterally, interfere with defenses, stage files, disrupt recovery, or prepare ransomware activity.

·        The adversary may stack multiple remote access tools to preserve access if one pathway is removed.

·        The adversary may shift between endpoint RMM, service-provider administration, endpoint management, and cloud-native remote command paths to maintain control.

Analytical Significance

The presence of an RMM tool is not enough to determine malicious activity. The decisive analytical question is whether the remote administration activity is authorized, attributable, scoped, and behaviorally consistent with approved operations. The strongest malicious indicators are unauthorized tenant association, suspicious execution context, persistence or unattended access, activity on restricted systems, RMM-launched high-risk commands, service-provider ambiguity, and remote management activity followed by credential access, lateral movement, defense evasion, backup interference, or ransomware preparation.

Defensive Interpretation

Defenders should treat RMM abuse as a control-channel and governance problem. Effective response requires validating the tool, tenant, user, endpoint, support ticket, session owner, deployment path, persistence state, source location, and follow-on activity. Where this context is missing, risk increases because analysts cannot quickly distinguish legitimate support from adversary-controlled access.

Tradecraft Assessment

RMM tool abuse is a high-value adversary tradecraft pattern because it turns trusted administration into an intrusion pathway. Its effectiveness comes from blending into normal operations, preserving access through legitimate tooling, and enabling post-compromise behavior without requiring obvious malware indicators. The most important defensive requirement is not to block all remote administration, but to prove that remote administration is authorized, monitored, bounded, attributable, and resilient against misuse.

S21 — Detection Strategy Overview

Detection Philosophy

RMM tool abuse must be detected as a behavior-driven control-channel problem rather than a static malware, product-name, or IOC problem. The adversary advantage comes from using legitimate, signed, trusted, and often allowlisted remote management software to establish interactive access, preserve persistence, bypass basic malware controls, and blend into normal administrative activity. Detection must therefore focus on unauthorized introduction, abnormal execution context, unexpected persistence creation, remote-control channel establishment, tool stacking, and post-compromise activity that follows RMM deployment.

The primary detection objective is to identify when remote management capability appears outside an approved administrative workflow. Tool names, vendor domains, file hashes, certificates, service names, and known infrastructure may support enrichment, but they must not be treated as the primary evidence of malicious activity. RMM platforms may be renamed, rehosted, bundled, staged through user-driven installation, deployed through official vendor infrastructure, pushed by compromised management tooling, or introduced through cloud-hosted workloads. Durable detection must use telemetry relationships: who initiated the tool, where it executed, how it persisted, what network destinations it contacted, whether the host or user had an approved RMM baseline, and what privileged or lateral activity occurred after remote-control capability was established.

This report treats RMM abuse as telemetry-observable intrusion behavior that may support initial access, persistence, command execution, credential access, lateral movement, data staging, exfiltration, and ransomware preparation. Detection engineering must prioritize behavior that remains valid across multiple RMM products, deployment paths, and evasion variants.

Primary Detection Anchors

·        Unauthorized RMM installer execution from browsers, email clients, archive utilities, collaboration tools, script interpreters, temporary directories, downloads folders, user profile paths, removable media, or other non-administrative launch contexts.

·        First-seen RMM agent, support client, remote-control binary, service, daemon, launch agent, scheduled task, startup item, enrollment artifact, or unattended-access configuration on an endpoint without an approved administrative baseline.

·        RMM process execution by non-administrative users, unexpected service accounts, recently compromised identities, unusual parent processes, recently created files, renamed binaries, unsigned wrapper components, abnormal working directories, or uncommon command-line parameters.

·        New or modified persistence mechanisms associated with remote-control tooling, including services, scheduled tasks, registry run keys, login items, launch daemons, management agents, remote-access configuration files, and unattended-access tokens.

·        Outbound connections to remote session brokers, vendor cloud relays, rare TLS/SNI values, newly observed RMM infrastructure, unexpected management servers, or long-lived encrypted sessions from endpoints not expected to use RMM.

·        RMM tool stacking, where more than one remote access, support, or management product appears on the same endpoint, user account, subnet, or administrative scope within a compressed operational window.

·        Post-RMM activity involving credential harvesting, local or domain discovery, privilege escalation, remote service creation, administrative share access, file staging, backup interference, security-tool tampering, exfiltration preparation, or ransomware staging.

·        Cloud-observable RMM deployment or remote-control enablement only where the activity intersects with cloud-hosted workloads, cloud identity, endpoint management, virtual desktop platforms, cloud-native run command features, or equivalent control-plane telemetry.

Detection Prioritization Model

Detection priority must follow the adversary’s control path rather than the RMM product name. The highest-priority detections identify unauthorized creation of durable remote-control capability, especially when installation, persistence, outbound control traffic, and follow-on intrusion behavior occur together. Single-signal detections may support hunting or triage, but production-priority rules should emphasize high-confidence behavioral combinations that separate malicious RMM deployment from legitimate IT administration.

·        First priority is unauthorized RMM introduction on endpoints, servers, virtual desktops, cloud-hosted workloads, identity infrastructure, backup infrastructure, or other systems where no approved RMM baseline exists.

·        Second priority is RMM persistence or unattended-access configuration created through suspicious parent processes, unusual users, abnormal paths, non-standard administrative workflows, or unexpected endpoint management actions.

·        Third priority is RMM control-channel establishment from endpoints, users, service accounts, or workloads that do not normally communicate with remote management infrastructure.

·        Fourth priority is post-compromise activity after RMM execution, including credential access, discovery, privilege escalation, lateral movement, exfiltration preparation, security-tool tampering, and ransomware staging.

·        Fifth priority is tool stacking, because adversaries may deploy multiple remote access tools to preserve access if one tool is removed or blocked.

·        Sixth priority is cloud-native deployment or remote execution behavior where RMM tooling is pushed to cloud workloads through cloud management planes, endpoint management platforms, virtual desktop infrastructure, or identity-backed administrative channels.

Correlation Strategy (Strict Enforcement)

Correlation may strengthen detection confidence, but it must not create cross-rule dependency or circular detection logic. A rule may correlate raw telemetry events within its own logic, but it must not depend on another detection rule firing first. Each rule must stand on direct observable evidence such as process execution, file creation, service creation, scheduled task registration, DNS query, proxy request, authentication event, identity change, software inventory delta, endpoint network connection, cloud audit event, or endpoint management action.

Correlation should connect raw signal relationships that represent adversary control progression.

·        RMM installer execution followed by new service creation, agent enrollment, scheduled task registration, startup persistence, or unattended-access configuration.

·        RMM binary execution followed by outbound connections to vendor relay infrastructure, remote session brokers, management servers, or rare external destinations.

·        First-seen RMM software followed by credential access, discovery commands, lateral movement, administrative share access, remote service execution, or security-tool tampering.

·        RMM activity from a non-administrative user followed by privileged authentication, group membership change, MFA modification, mailbox access, cloud resource access, or endpoint management action.

·        RMM deployment on a cloud-hosted workload followed by cloud identity activity, storage access, snapshot activity, run command use, cross-resource enumeration, or suspicious service-account activity.

·        Multiple RMM or remote-access tools appearing on the same host, user account, subnet, or administrative scope within the same intrusion window.

Correlation must not compensate for weak base telemetry. If telemetry cannot prove execution, persistence, communication, deployment, administrative misuse, or post-compromise behavior, the detection must remain a hunting opportunity rather than a production rule.

Telemetry Prioritization

Endpoint telemetry is the primary detection layer for this report. The strongest signals come from process execution, parent-child relationships, command-line arguments, file writes, service creation, persistence changes, software inventory deltas, endpoint network connections, and EDR behavioral context. SIEM correlation should combine these endpoint events with DNS, proxy, authentication, identity, software inventory, endpoint management, and cloud audit telemetry.

·        Endpoint and EDR telemetry is required for high-confidence detection of RMM installation, execution, persistence, renamed binaries, suspicious parentage, unusual user context, and post-compromise activity.

·        DNS and proxy telemetry are required to identify unusual RMM vendor traffic, rare remote session destinations, new outbound control paths, unexpected TLS/SNI values, and first-seen management infrastructure.

·        Authentication and identity telemetry are required to detect privileged access changes, unusual sign-ins, MFA manipulation, helpdesk impersonation patterns, service-account misuse, and identity activity after RMM access is established.

·        Software inventory and asset management telemetry are required to distinguish approved RMM deployments from unauthorized, newly introduced, or policy-violating remote management tools.

·        Endpoint management telemetry is required where RMM agents may be deployed through device management platforms, software distribution systems, remote command features, virtual desktop tooling, or administrative automation.

·        Cloud audit telemetry is conditional and should only drive rules where cloud control planes, virtual desktop platforms, workload management features, endpoint management tooling, or cloud-hosted systems directly observe relevant activity.

·        Network IDS telemetry is supportive and should not be treated as the primary detection source because encrypted RMM traffic, vendor relay infrastructure, and legitimate remote-support patterns reduce content visibility.

·        File scanning and YARA-style telemetry are supportive and should be limited to suspicious installers, repackaged tools, fake support software, bundled droppers, malicious wrappers, or organization-banned tools rather than clean signed RMM binaries.

Detection Design Constraints

Detection content must avoid treating legitimate RMM software as inherently malicious. Many organizations rely on these tools for IT support, MSP operations, software deployment, break-fix administration, remote troubleshooting, and endpoint management. Effective detection requires separating approved administrative use from unauthorized deployment, suspicious launch context, abnormal persistence, unexpected control channels, and adversary follow-on behavior.

·        Rules must not alert solely on the existence of a known RMM product unless the organization has explicitly banned that product.

·        Rules must not rely solely on vendor names, hashes, domains, certificates, process names, service names, or default installation paths.

·        Rules must account for renamed binaries, repackaged installers, signed tools, portable support clients, temporary support sessions, cloud relay infrastructure, legitimate vendor update paths, and compromised administrative deployment channels.

·        Rules must avoid broad domain blocking assumptions unless the environment has an approved RMM inventory and clearly defined remote-support policy.

·        Rules must distinguish managed administrative endpoints from ordinary user workstations, servers, domain controllers, privileged access workstations, kiosks, virtual desktops, and cloud-hosted workloads.

·        Rules must support allowlisting based on approved tool, approved tenant, approved management server, approved IT user group, approved service account, approved device group, approved deployment method, and approved business function.

·        Rules must preserve visibility into unexpected use even when the RMM vendor itself is approved for limited parts of the enterprise.

·        Rules must treat MSP, helpdesk, and emergency support workflows as high-value baseline inputs, not blanket suppressions.

Baseline and Deployment Requirements

A deployable RMM abuse detection strategy requires a known-good administrative baseline. Without baseline context, detections either become too noisy or too dependent on generic tool lists. The baseline does not need to be perfect before hunting begins, but production alerts require enough context to distinguish legitimate administration from suspicious remote-control enablement.

·        Maintain an approved RMM inventory covering vendor, product, agent name, service name, installation path, tenant identifier, management server, expected domains, expected ports, approved installer source, approved certificate or signer where applicable, and approved deployment mechanism.

·        Define approved RMM user groups, administrator roles, helpdesk identities, MSP accounts, service accounts, endpoint management identities, and emergency access accounts.

·        Identify authorized RMM deployment paths such as endpoint management platforms, software distribution systems, golden images, device management policies, virtual desktop images, cloud workload automation, or approved support workflows.

·        Define endpoint populations where RMM is expected, restricted, or prohibited, including workstations, servers, domain controllers, privileged access workstations, executive devices, developer systems, virtual desktops, cloud-hosted workloads, identity infrastructure, backup servers, and security tooling.

·        Establish first-seen software baselines for remote administration tools, remote support clients, unattended-access agents, remote desktop utilities, support wrappers, and portable support executables.

·        Maintain network baselines for expected RMM vendor relay domains, management servers, outbound ports, TLS/SNI patterns, administrative source networks, remote-support gateways, and endpoint populations authorized for RMM egress.

·        Integrate asset criticality so unauthorized RMM activity on domain controllers, finance systems, identity infrastructure, backup servers, security tooling, executive endpoints, cloud management systems, and regulated-data systems receives elevated priority.

Variant Resilience Requirements

Detection engineering must remain effective when adversaries change the specific RMM product, delivery method, process name, installation path, infrastructure, administrative identity, or post-compromise sequence. Durable detections should identify the operational purpose of the activity rather than one fixed artifact.

·        Detect unauthorized remote-control capability even when the adversary changes from one RMM platform to another.

·        Detect suspicious installation context even when the binary is signed, legitimate, downloaded from an official vendor source, or launched through user interaction.

·        Detect persistence behavior even when the service name, task name, configuration file, enrollment artifact, or install directory differs from known defaults.

·        Detect control-channel behavior through rarity, host role mismatch, first-seen destination, approved-inventory mismatch, and unexpected endpoint population rather than static domain lists alone.

·        Detect tool stacking even when each individual tool is legitimate or approved elsewhere in the enterprise.

·        Detect post-compromise behavior after RMM execution even when the RMM agent itself is approved, ambiguous, or already present.

·        Detect cloud-hosted workload deployment only where control-plane audit events, endpoint telemetry, or management platform logs prove remote execution, software staging, policy change, or identity-backed administrative action.

·        Preserve detections across phishing-led installation, exposed RMM server exploitation, fake support lures, MSP compromise, helpdesk impersonation, software deployment abuse, virtual desktop abuse, cloud workload management abuse, and living-off-the-land administrative deployment.

Operational Detection Model

The operational model should use layered detection with endpoint and SIEM rules as the backbone, DNS and proxy telemetry as supporting evidence, and cloud-native rules only where cloud telemetry directly observes relevant behavior. The SOC should triage RMM alerts by determining whether the tool, user, host, deployment path, persistence mechanism, outbound destination, tenant association, and follow-on activity match an approved administrative baseline.

Initial alert handling should answer the following questions:

·        Was the RMM tool approved for this endpoint, user, business unit, tenant, and deployment method?

·        Was the tool installed interactively by an end user, launched from a suspicious parent process, pushed through a compromised administrative channel, or staged through a non-standard path?

·        Did the activity create unattended access, a persistent service, scheduled task, startup item, remote session enrollment, or management configuration artifact?

·        Did the endpoint initiate new outbound connections to RMM vendor relay infrastructure, remote session brokers, management servers, or rare external control destinations?

·        Did additional remote access tools appear on the same host, user account, subnet, or administrative scope shortly afterward?

·        Did credential access, discovery, lateral movement, privilege escalation, security-tool tampering, data staging, exfiltration preparation, backup interference, or ransomware preparation follow the RMM activity?

·        Did cloud identity, endpoint management, virtual desktop, workload management, or service-account telemetry show related administrative misuse?

Alert severity should increase when unauthorized RMM deployment occurs on privileged systems, identity infrastructure, backup infrastructure, security tooling, executive endpoints, cloud workloads, or systems with sensitive business data. Severity should also increase when RMM execution is followed by credential access, discovery, lateral movement, tool stacking, security-tool tampering, backup interference, or data staging.

Explicit Non-Deployment Guardrails

The following detection approaches should not be deployed as standalone production rules unless they are explicitly scoped to a customer-approved policy condition or combined with stronger behavioral evidence:

·        Do not deploy a rule that alerts only because AnyDesk, TeamViewer, ScreenConnect, SimpleHelp, Atera, Splashtop, NinjaOne, Syncro, Zoho Assist, NetSupport, or another RMM tool exists on a host.

·        Do not deploy a rule that relies only on known malicious IP addresses, file hashes, vendor domains, certificates, process names, or default service names.

·        Do not deploy a rule that assumes official vendor infrastructure is malicious without local baseline deviation or supporting suspicious behavior.

·        Do not deploy a rule that treats all remote support sessions as malicious without considering approved IT, MSP, helpdesk, emergency support, endpoint management, or break-fix workflows.

·        Do not deploy a rule that requires another detection rule to fire before it can produce an alert.

·        Do not deploy cloud-native RMM detections unless cloud telemetry directly observes deployment, execution, identity misuse, endpoint management action, workload command execution, virtual desktop activity, or service-account misuse.

·        Do not deploy YARA or file-matching rules against clean signed RMM binaries unless the organization has banned the tool or the rule targets suspicious packaging, wrapper behavior, fake software, malicious bundling, or policy-prohibited software.

·        Do not deploy broad network signatures that cannot distinguish legitimate RMM traffic from unauthorized control-channel activity.

·        Do not lower evidence requirements for smaller environments; smaller environments may reduce deployment scope, but each rule must still require observable suspicious behavior.

·        Do not expose internal detection scoring methodology, rule-selection mechanics, tier mapping, wrapper logic, proprietary tuning thresholds, customer readiness models, or CyberDax implementation mechanics in public-facing detection content.

S22 — Primary Detection Signals

Primary Detection Signals

The primary detection signals for RMM tool abuse are telemetry-observable behaviors that show unauthorized remote management capability being introduced, enabled, persisted, remotely controlled, or used outside an approved administrative workflow. These signals must prioritize execution context, deployment path, tenant association, persistence creation, remote session enablement, outbound control-channel behavior, and post-compromise activity over static product names or known indicators.

·        First-seen RMM installer, support client, remote-control agent, service binary, daemon, launch agent, portable remote access executable, or unattended-access component on an endpoint without an approved RMM baseline.

·        RMM installer or agent execution from suspicious user-controlled locations, including downloads directories, temporary directories, desktop folders, browser cache paths, archive extraction paths, removable media, cloud-synced folders, or other non-standard administrative staging locations.

·        RMM execution launched by browsers, email clients, document readers, archive utilities, collaboration tools, script interpreters, command shells, remote command utilities, endpoint management actions, or LOLBin execution paths inconsistent with approved software deployment.

·        RMM agent installation, support-session initiation, or remote-control enablement by a non-administrative user, unexpected service account, newly active identity, suspicious helpdesk identity, MSP-linked identity, or account with no normal remote-support function.

·        Creation of new services, scheduled tasks, startup entries, registry run keys, launch daemons, login items, configuration files, accessibility permissions, screen-recording permissions, remote-control permissions, or unattended-access artifacts tied to remote management tooling.

·        RMM agent enrollment into an unknown tenant, unexpected management server, unauthorized relay, attacker-controlled support session, unmanaged MSP environment, or tenant association that does not match the organization’s approved inventory.

·        Endpoint network connections to first-seen RMM relay infrastructure, rare remote session brokers, unexpected vendor cloud relays, unmanaged support domains, newly observed management servers, or long-lived encrypted remote-control sessions from endpoints not expected to use RMM.

·        RMM process execution or network activity from systems where RMM should be restricted or prohibited, including domain controllers, identity infrastructure, backup servers, privileged access workstations, security tooling, executive endpoints, virtual desktop infrastructure, cloud workloads, and regulated-data systems.

·        Multiple RMM, remote access, remote desktop, support, tunneling, or screen-sharing tools appearing on the same endpoint, user account, subnet, device group, cloud workload group, MSP scope, or administrative scope within a compressed operational window.

·        RMM execution followed by discovery, credential access, privilege escalation, lateral movement, administrative share access, remote service creation, file staging, exfiltration preparation, security-tool tampering, backup interference, or ransomware staging.

·        Cloud, endpoint management, virtual desktop, or service-provider control-plane activity that deploys, enables, stages, enrolls, or configures RMM tooling on cloud-hosted workloads, virtual desktops, managed endpoints, or downstream customer environments.

Supporting Detection Signals

Supporting signals provide enrichment, severity context, triage value, and hunting pivots. They should not be treated as standalone production evidence unless the organization has explicitly prohibited the relevant tool, tenant, domain, or behavior.

·        Known RMM product names, process names, service names, display names, signer names, installation folders, tenant identifiers, vendor certificates, support session names, and remote-control configuration artifacts.

·        Known RMM vendor domains, relay domains, management URLs, TLS/SNI values, websocket paths, update paths, API endpoints, download locations, installer generation paths, and support-session infrastructure.

·        Software inventory deltas showing newly installed remote management, remote desktop, support, screen-sharing, file-transfer, tunneling, unattended-access, or remote command tools.

·        Endpoint detection context showing suspicious reputation, low prevalence, first-seen execution, abnormal parentage, unusual command-line parameters, abnormal working directory, or execution by non-standard users.

·        Certificate, signer, or file metadata inconsistent with approved deployment, including unexpected signer, missing signer, mismatched product metadata, suspicious version information, abnormal file description, modified icon, or renamed executable.

·        New firewall rules, proxy exceptions, local allow rules, service permissions, accessibility permissions, screen-recording permissions, remote-control permissions, browser consent grants, or endpoint protection exclusions associated with remote access tooling.

·        Newly observed support-session codes, enrollment tokens, unattended-access tokens, configuration files, tenant files, remote management policy files, agent registration artifacts, relay identifiers, or installer package identifiers.

·        Authentication events showing unusual privileged logon, helpdesk account use, service-account use, impossible travel, anomalous source geography, suspicious MFA activity, password reset activity, or access from endpoints recently associated with RMM activity.

·        Asset criticality context showing RMM activity on domain controllers, identity infrastructure, backup servers, finance systems, executive endpoints, security tooling, cloud management systems, regulated-data systems, or downstream customer administration systems.

·        Historical baseline deviation showing that the tool, tenant, user, host, business unit, network path, administrative scope, deployment method, or support workflow is new, rare, or inconsistent with approved remote-support operations.

Exploit Attempt and Instability Signals

Exploit attempt and instability signals are most relevant when adversaries target exposed RMM servers, vulnerable RMM appliances, self-hosted management platforms, internet-facing support infrastructure, or service-provider administration environments. These signals should not be treated as confirmed compromise by themselves. They become stronger when linked to successful authentication, administrative changes, agent deployment, remote session creation, endpoint-side artifacts, or downstream activity.

·        Unusual inbound requests to exposed RMM servers, support portals, management consoles, API endpoints, agent enrollment paths, installer generation paths, file upload paths, file download paths, or administrative login pages.

·        Authentication failures, password spraying, unusual session creation, abnormal administrative login attempts, token misuse, session reuse, or access attempts against RMM management interfaces from rare geographies, hosting providers, VPN nodes, or anonymization infrastructure.

·        Web application errors, path traversal attempts, malformed request patterns, unexpected file access, suspicious archive handling, abnormal API calls, unauthorized download attempts, or suspicious file upload attempts against RMM infrastructure.

·        Unexpected creation, modification, or deletion of RMM administrator accounts, support users, technician accounts, roles, tenants, agent groups, session policies, deployment packages, or unattended-access configurations.

·        RMM server instability, service crashes, process faults, unexpected restarts, web server errors, database errors, agent registration anomalies, installer generation anomalies, or management-console exceptions occurring near suspicious access attempts.

·        Sudden mass agent check-ins, re-enrollments, policy changes, remote session creation, command execution, file transfer, installer generation, or package deployment from an RMM management platform.

·        RMM server or management platform spawning abnormal child processes, shell commands, scripting engines, archive utilities, file-transfer tools, credential tools, discovery utilities, web shells, or system administration utilities inconsistent with normal platform behavior.

·        New web-accessible files, unexpected installer packages, suspicious exports, unknown plugins, unauthorized scripts, altered configuration files, or unknown integration artifacts on RMM management infrastructure.

·        Administrative activity against RMM infrastructure followed by endpoint-side agent deployment, remote-control session establishment, tenant reassignment, support-session generation, command execution, or downstream customer impact.

·        Patch-level mismatch, unsupported version exposure, internet-facing management service exposure, absent MFA, weak access control, or externally reachable RMM infrastructure with no compensating administrative restrictions.

Outbound Communication Signals

Outbound communication signals are essential because RMM abuse often depends on encrypted connections to vendor relays, remote session brokers, attacker-controlled management servers, or legitimate remote-support infrastructure. These signals must be based on baseline deviation, tenant mismatch, host-role mismatch, and timing relationships rather than broad assumptions that RMM vendor traffic is malicious.

·        First-seen outbound connections from an endpoint to RMM vendor relays, remote session brokers, support infrastructure, management servers, cloud-hosted remote-control endpoints, or newly observed remote administration destinations.

·        Long-lived encrypted sessions, repeated beacon-like connectivity, persistent websocket activity, unusual keepalive behavior, or high-duration TLS connections from endpoints not expected to use remote management tooling.

·        DNS queries, TLS/SNI values, proxy requests, firewall events, or endpoint network telemetry involving RMM infrastructure from user workstations, servers, virtual desktops, cloud workloads, or privileged systems outside approved support workflows.

·        Outbound RMM traffic from endpoints where no corresponding approved agent, service, software inventory record, deployment ticket, change record, endpoint management action, or support workflow exists.

·        Connections to RMM infrastructure shortly after suspicious installer execution, archive extraction, browser download, email attachment interaction, collaboration-tool download, removable media execution, cloud-synced file execution, or script execution.

·        Remote-control traffic initiated from privileged systems, domain controllers, identity infrastructure, backup servers, security tools, finance systems, executive endpoints, sensitive data repositories, or cloud management systems.

·        RMM traffic to tenant, relay, or management infrastructure that does not match approved organizational tenant identifiers, expected vendor paths, known MSP infrastructure, authorized management servers, or sanctioned support workflows.

·        RMM communication followed by unusual upload volume, archive transfer, file staging, remote shell activity, administrative share access, lateral movement, endpoint protection interference, backup interference, or security-tool tampering.

·        Network connections to multiple RMM vendors, tunneling services, remote desktop platforms, screen-sharing services, or remote access platforms from the same endpoint, user account, subnet, or administrative scope within a short operational window.

·        Cloud-hosted workload egress to RMM infrastructure after cloud control-plane remote command, startup script, extension deployment, endpoint management action, image modification, virtual desktop provisioning, or suspicious service-account use.

Persistence and Post-Exploitation Signals (Conditional)

Persistence and post-exploitation signals become high priority when they occur after RMM introduction, RMM server compromise, unauthorized support-session creation, suspicious agent enrollment, or abnormal remote management activity. These signals are conditional because some may occur during legitimate administration, but they become materially stronger when tied to unauthorized RMM control.

·        New service creation, service modification, service recovery configuration, scheduled task registration, startup entry creation, registry run key modification, launch daemon creation, login item creation, remote-control permission change, or agent persistence after RMM installer execution.

·        RMM configuration changes enabling unattended access, silent access, auto-start, reconnect behavior, hidden tray behavior, remote shell access, file transfer, clipboard synchronization, credential caching, remote reboot capability, or unattended session approval.

·        Remote management activity followed by execution of discovery commands, network enumeration, domain enumeration, privilege checks, local administrator group inspection, security software discovery, backup discovery, or remote session enumeration.

·        RMM-linked execution followed by credential access behavior, LSASS access, browser credential access, password store access, token access, suspicious credential tool staging, suspicious archive staging, or suspicious use of administrative credentials.

·        Creation of local administrator accounts, modification of privileged groups, suspicious service-account use, privilege assignment, remote logon rights changes, account enablement, password reset, MFA reset, or helpdesk-initiated identity change after RMM activity.

·        Security-tool tampering, EDR service interference, firewall rule modification, logging changes, endpoint protection exclusion creation, backup agent disruption, shadow copy deletion, recovery setting changes, or tamper-protection events after RMM activity.

·        File staging, archive creation, compression utility use, suspicious large file movement, data collection from user profiles, finance shares, database exports, source-code repositories, file servers, or regulated-data locations following RMM execution.

·        RMM activity followed by ransomware preparation signals such as backup discovery, backup deletion attempts, mass file enumeration, remote execution across hosts, payload staging, encryption tooling transfer, or policy changes that weaken recovery.

·        Persistence artifacts appearing on systems where RMM is prohibited, including domain controllers, privileged access workstations, backup servers, security tooling, executive endpoints, regulated-data systems, cloud management systems, and identity infrastructure.

·        Post-exploitation activity initiated by the same user, process lineage, endpoint, session, service account, tenant, management channel, or remote-control infrastructure associated with RMM deployment.

Lateral Movement and Expansion Signals (Conditional)

Lateral movement and expansion signals should be prioritized when RMM activity precedes or coincides with administrative access expansion, remote execution, new endpoint enrollment, credential reuse, cross-system propagation, or downstream customer impact. These signals are conditional because legitimate administrators may perform similar actions, but they become high-confidence when tied to unauthorized RMM introduction, tenant mismatch, abnormal support workflows, or suspicious remote-control behavior.

·        RMM deployment or execution followed by remote service creation, administrative share access, remote scheduled task creation, WMI execution, PowerShell remoting, SSH access, RDP access, SMB session expansion, remote command execution, or software deployment to additional systems.

·        Same user, service account, host, tenant, management server, or support channel initiating RMM activity on multiple endpoints outside an approved software deployment window or support workflow.

·        RMM agent installation spreading across device groups, subnets, business units, server tiers, virtual desktops, cloud-hosted workloads, or downstream environments without matching change-control or endpoint management records.

·        Privileged authentication from an endpoint recently associated with suspicious RMM execution to servers, domain controllers, identity systems, backup infrastructure, security tooling, cloud management systems, or regulated-data systems.

·        Remote-control session activity followed by credential reuse, new logon sessions, privilege escalation, group membership modification, administrative role assignment, MFA changes, or service-account activity across multiple systems.

·        RMM-enabled access followed by remote file copy, script staging, tool transfer, payload deployment, data collection, archive creation, or lateral execution on additional endpoints.

·        Multiple RMM tools deployed across the environment in a short window, especially when one tool appears after another is blocked, removed, quarantined, disconnected, or disabled.

·        Suspicious endpoint management or cloud control-plane activity used to push remote access tools to additional systems, including virtual desktops, cloud workloads, managed servers, high-value endpoints, or service-provider managed environments.

·        Cross-tenant, MSP, helpdesk, or service-provider access patterns that result in RMM deployment, support-session creation, tenant reassignment, or remote-control activity across multiple customer or business-unit environments.

·        Expansion behavior that moves from user workstation to server tier, identity infrastructure, backup environment, security tooling, cloud management plane, regulated-data environment, or downstream customer environment after RMM access is established.

Signal Usage Constraints

RMM-related signals must be deployed with strict operational constraints to avoid high noise, overblocking, or false assumptions about legitimate administration. The purpose of these signals is to identify unauthorized remote-control capability and post-compromise behavior, not to label all remote support activity as malicious.

·        Do not use RMM product names, process names, service names, signer names, domains, certificates, tenant identifiers, or file paths as standalone production detections unless the organization explicitly bans that tool, tenant, or artifact.

·        Do not treat vendor relay infrastructure as malicious without local baseline deviation, unauthorized tenant association, suspicious execution context, host-role mismatch, or supporting post-compromise behavior.

·        Do not suppress all activity from approved RMM tools; approved tools can still be abused through compromised accounts, unauthorized tenants, misused support sessions, attacker-generated installers, malicious unattended-access configuration, or compromised service-provider workflows.

·        Do not deploy broad detections without approved RMM inventory, authorized deployment paths, expected tenant identifiers, approved management servers, administrative user groups, endpoint populations, service-provider workflows, and known support processes.

·        Do not use correlation to compensate for weak base evidence. Each production detection must stand on direct raw telemetry showing execution, persistence, communication, deployment, identity misuse, endpoint management action, service-provider misuse, cloud control-plane activity, or post-compromise behavior.

·        Do not promote exploit-attempt signals into confirmed compromise without endpoint, server, identity, cloud, service-provider, or management-plane evidence showing successful deployment, access, persistence, tenant change, remote session creation, or downstream activity.

·        Do not force cloud-native detections unless AWS, Azure, GCP, virtual desktop, endpoint management, identity, workload, or service-provider telemetry directly observes relevant deployment, execution, remote command, enrollment, tenant association, or administrative misuse.

·        Do not deploy YARA or file-matching logic against clean signed RMM binaries as a standalone production control unless scoped to prohibited tools, suspicious bundles, malicious wrappers, fake software, repackaged installers, or altered deployment packages.

·        Do not deploy network-only detections that cannot distinguish legitimate RMM egress from unauthorized control-channel activity unless scoped to prohibited infrastructure, tenant mismatch, host-role mismatch, or confirmed baseline deviation.

·        Do not reduce evidence thresholds for smaller environments. Deployment scope may change, but the signal must still prove suspicious behavior.

·        Do not expose internal CyberDax scoring methodology, rule-selection mechanics, tier mapping, proprietary wrapper logic, tuning thresholds, readiness models, or implementation mechanics in public-facing detection content.

Notes Section

Audit Result

S22 passes the hardened adversarial engineering audit and hardened adversarial engineering pass. The section is telemetry-first, behavior-centered, adversarially resilient, and aligned to the RMM abuse control-channel model established in S21.

Corrections Applied

·        Strengthened detection coverage for tenant mismatch, service-provider misuse, MSP workflows, endpoint management abuse, virtual desktop deployment, cloud workload deployment, and downstream customer impact.

·        Added hardened coverage for official vendor downloads, signed tools, renamed binaries, suspicious support-session creation, attacker-generated installers, unauthorized unattended-access configuration, and compromised administrative channels.

·        Tightened exploit-attempt language so exposed RMM server activity is not overstated as compromise without follow-on endpoint, identity, server, cloud, or management-plane evidence.

·        Expanded outbound communication signals to include websocket activity, tenant mismatch, host-role mismatch, timing after suspicious staging, and cloud workload egress after control-plane actions.

·        Expanded persistence and post-exploitation signals to include permission changes, credential access behavior, endpoint protection exclusions, backup interference, recovery weakening, and ransomware preparation.

·        Expanded lateral movement and expansion signals to include tenant, management server, support channel, downstream environment, endpoint management, and cloud control-plane propagation paths.

·        Reinforced signal usage constraints so product names, vendor infrastructure, YARA matches, cloud telemetry, and network-only indicators do not become weak standalone production detections.

·        Preserved public-safe guidance and excluded proprietary CyberDax scoring, tuning, wrapper, tiering, readiness, and rule-selection mechanics.

Residual Limitations

·        S22 defines the validated signal universe but does not finalize rule logic, rule count, DRI/TCR scoring, or system-specific deployment posture.

·        Cloud signal viability remains conditional and must be validated in S23 and S24 before any AWS, Azure, or GCP rule is promoted in S25.

·        Product names, tenant identifiers, vendor infrastructure, and file metadata remain supporting examples only and must not become the governing detection basis in later sections.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry is the primary telemetry requirement for detecting RMM tool abuse. The strongest detections depend on proving that remote management tooling was introduced, executed, installed, persisted, remotely controlled, or used from a context inconsistent with approved administrative workflows. Endpoint telemetry must capture process lineage, user context, binary metadata, execution path, command-line activity, service creation, persistence changes, software inventory movement, and endpoint network activity with enough fidelity to distinguish approved support operations from adversary-controlled remote access.

·        Endpoint telemetry must capture process execution events for RMM installers, support clients, remote-control agents, remote desktop utilities, tunneling tools, portable support executables, unattended-access components, and secondary remote access tools deployed after initial RMM execution.

·        Process events must include timestamp, hostname, user, user SID or equivalent identity field, process name, full image path, parent process name, parent image path, command line, working directory, process hash, process signer, file creation time, original file name, process integrity level, and execution source where available.

·        Parent-child process telemetry must identify RMM execution launched from browsers, email clients, document readers, archive utilities, collaboration tools, command shells, scripting engines, LOLBins, endpoint management agents, remote command utilities, or cloud workload management actions.

·        Endpoint telemetry must support first-seen or low-prevalence identification for RMM binaries, installers, services, support clients, renamed executables, portable remote access tools, unsigned wrappers, and attacker-staged deployment packages.

·        Endpoint telemetry must capture file creation, file modification, and file execution from downloads folders, temporary directories, user profiles, archive extraction paths, cloud-synced folders, removable media, shared folders, and non-standard administrative staging locations.

·        Endpoint telemetry must capture service creation, service modification, scheduled task registration, registry autorun modification, launch daemon creation, launch agent creation, login item creation, startup folder changes, agent enrollment artifacts, unattended-access configuration, and remote-control permission changes.

·        Endpoint telemetry must identify execution by non-administrative users, unexpected service accounts, newly active identities, helpdesk accounts, MSP-linked accounts, endpoint management identities, privileged users, and accounts with no approved remote-support function.

·        Endpoint telemetry must capture endpoint network connections where possible, including destination IP, destination port, protocol, process association, DNS name, TLS/SNI value, proxy destination, connection duration, byte counts, and connection timing relative to execution.

·        Endpoint telemetry must support correlation between RMM execution and follow-on discovery, credential access, lateral movement, file staging, security-tool tampering, backup interference, data collection, exfiltration preparation, and ransomware staging.

·        Endpoint telemetry must retain enough historical depth to determine whether the tool, path, process, user, host, tenant association, management server, deployment method, and outbound destination are new, rare, prohibited, or baseline-approved.

Memory and Execution Telemetry

Memory and execution telemetry is supportive for this report. Most RMM abuse cases involve legitimate signed software, so memory telemetry should not be treated as the primary detection layer. It becomes valuable when RMM activity is followed by credential access, in-memory tooling, injected payloads, suspicious scripting, remote shell behavior, security-tool tampering, or post-compromise execution that does not produce reliable file-based artifacts.

·        EDR telemetry should capture process injection, suspicious handle access, credential-process access, remote thread creation, abnormal module loading, unsigned module loading, reflective loading indicators, suspicious child process creation, and abnormal process access after RMM execution.

·        Memory telemetry should support detection of credential access behavior involving LSASS access, browser credential store access, password manager access, token manipulation, session material access, or suspicious access to authentication material.

·        Execution telemetry must capture script block logging, shell command execution, PowerShell activity, WMI activity, remote service execution, command interpreter use, encoded commands, suspicious download cradles, LOLBin activity, and remote administration commands associated with RMM-enabled access.

·        EDR behavioral telemetry must identify remote shell activity, interactive command execution, file transfer, remote reboot, privilege checks, discovery commands, security tooling discovery, backup discovery, and recovery weakening initiated after RMM deployment or remote session establishment.

·        Memory and execution telemetry should support triage of tool stacking, including RMM activity followed by tunneling tools, credential tools, compression utilities, remote desktop tools, remote command utilities, or additional remote access platforms.

·        Memory telemetry should not be required for every production RMM detection. Rules that depend on memory telemetry must remain scoped to credential access, in-memory execution, injection, suspicious scripting, or post-compromise behavior where endpoint telemetry can directly observe the activity.

·        Memory telemetry must not be used to infer compromise solely because a legitimate RMM agent is running. It must be tied to suspicious process access, execution behavior, credential material access, remote shell activity, or adversary follow-on activity.

Crash and Fault Telemetry

Crash and fault telemetry is conditional. It is most relevant when adversaries target exposed RMM servers, vulnerable RMM appliances, self-hosted management infrastructure, support portals, agent enrollment services, installer generation workflows, management consoles, or service-provider administration systems. Crash telemetry can support exploit-attempt identification, but it must not be treated as confirmed compromise without follow-on evidence.

·        RMM server telemetry should capture application crashes, service restarts, process faults, web server errors, database errors, management-console exceptions, agent enrollment errors, installer generation failures, abnormal plugin failures, and abnormal integration failures.

·        Host telemetry for RMM servers must capture unexpected child processes from web services, management services, database services, update services, plugin services, integration services, or agent enrollment components.

·        Web and application logs must capture malformed requests, path traversal attempts, upload anomalies, unauthorized downloads, suspicious API calls, unexpected archive handling, failed authentication bursts, abnormal session creation, and unusual installer generation activity.

·        Administrative audit logs must capture unexpected creation or modification of technician accounts, administrator roles, tenants, agent groups, policy objects, deployment packages, unattended-access settings, support-session settings, and remote-control session controls.

·        Crash and fault telemetry should be correlated with external access attempts, authentication events, API activity, server-side file creation, new web-accessible files, unauthorized scripts, suspicious exports, tenant changes, and downstream endpoint-side deployment.

·        Crash telemetry must remain supporting evidence unless paired with successful authentication, administrative change, file write, command execution, agent deployment, tenant change, support-session creation, or endpoint-side compromise signal.

·        Crash and fault telemetry is not required for organizations that do not host internet-facing RMM infrastructure, but it is required where self-hosted RMM servers, MSP platforms, service-provider administration systems, or exposed support portals are in scope.

File and Persistence Telemetry

File and persistence telemetry is required because adversaries frequently rely on RMM installation, agent enrollment, service creation, unattended-access configuration, permission changes, and persistence modifications to preserve post-compromise control. This telemetry must distinguish approved software deployment from unauthorized remote-control enablement.

·        File telemetry must capture creation, modification, execution, quarantine, deletion, and reputation events for RMM installers, support clients, portable executables, remote-control agents, configuration files, tenant files, policy files, support-session artifacts, enrollment tokens, installer packages, and remote-control wrappers.

·        File metadata should include full path, filename, original filename, hash, signer, certificate subject, product name, file description, file version, compile timestamp where available, creation time, modification time, zone identifier, download source, referrer where available, and user context.

·        Persistence telemetry must capture service creation, service modification, service recovery changes, scheduled task registration, registry run key changes, startup folder entries, launch daemons, launch agents, login items, system extensions, agent enrollment settings, support-session persistence, and unattended-access configuration.

·        Endpoint telemetry must identify permission changes tied to remote access tooling, including accessibility permissions, screen-recording permissions, remote-control permissions, local firewall rules, proxy exceptions, endpoint protection exclusions, local allow rules, security prompts, and consent grants.

·        Software inventory telemetry must capture new RMM product installations, updates, tenant changes, agent enrollment changes, version changes, management server changes, support client deployments, unexpected removal, unexpected reinstallation, and replacement with a second remote access tool.

·        File and persistence telemetry must support comparison against approved RMM inventory, approved deployment paths, approved tenant identifiers, approved management servers, authorized signer context, approved support workflows, sanctioned endpoint populations, and known MSP administration paths.

·        Telemetry must preserve artifacts even when the RMM tool is uninstalled, removed, quarantined, renamed, or replaced by another tool. Historical visibility is required to detect tool stacking, post-removal access preservation, and adversary attempts to reset baseline context.

·        File and persistence telemetry should support elevated prioritization for activity on domain controllers, identity infrastructure, backup servers, privileged access workstations, executive endpoints, security tooling, cloud management systems, regulated-data systems, and downstream customer administration systems.

Network and Outbound Communication Telemetry

Network and outbound communication telemetry is required as supporting evidence for control-channel establishment and remote session activity. Because many RMM tools use encrypted vendor relay infrastructure and legitimate remote-support channels, network telemetry must be interpreted through baseline deviation, tenant mismatch, process association, host role, endpoint population, approved egress path, and timing relative to execution.

·        DNS telemetry must capture query name, response, resolver, client host, user association where available, timestamp, query frequency, first-seen status, and historical prevalence for RMM-related domains, relay infrastructure, management servers, and support portals.

·        Proxy telemetry must capture URL, domain, TLS/SNI value, HTTP method where available, user, source host, destination, category, request timestamp, response status, bytes sent, bytes received, user agent, referrer where available, and policy action.

·        Firewall and network flow telemetry must capture source host, source IP, destination IP, destination port, protocol, connection duration, bytes transferred, session frequency, directionality, and unusual upload behavior.

·        Endpoint network telemetry should associate outbound connections with the responsible process, user, command line, image path, signer, and binary metadata whenever possible.

·        TLS metadata should capture SNI, certificate subject, issuer, validity window, destination reputation, JA3 or equivalent fingerprint where available, destination hosting context, and first-seen timing.

·        Network telemetry must identify first-seen or rare outbound connections to RMM relays, remote session brokers, management servers, cloud-hosted remote-control endpoints, vendor infrastructure, and support infrastructure from hosts not expected to use RMM.

·        Network telemetry must support detection of long-lived encrypted sessions, repeated keepalive behavior, persistent websocket activity, unusual upload volume, remote file transfer, and control-channel behavior after RMM execution.

·        Network telemetry must support comparison against approved RMM egress paths, sanctioned management servers, approved tenants, known MSP infrastructure, expected support workflows, endpoint populations authorized for remote management, and prohibited endpoint groups.

·        Network telemetry alone must not be treated as sufficient for production compromise detection unless the organization has prohibited the destination, the destination represents confirmed tenant mismatch, or network evidence is paired with endpoint, identity, software inventory, RMM platform, or management-plane evidence.

·        Network telemetry must be retained long enough to validate whether RMM infrastructure, tenant association, endpoint egress, host role, or remote session behavior is new, rare, prohibited, or approved.

Web and Application Telemetry (Conditional Availability)

Web and application telemetry is conditionally required when the organization hosts RMM servers, support portals, management consoles, MSP platforms, service-provider administration systems, customer support portals, or internet-facing RMM infrastructure. It is also relevant when user-driven installation occurs through phishing pages, fake support portals, malicious download pages, collaboration links, QR-code redirection, or attacker-controlled software pages.

·        RMM server and application logs must capture administrator authentication, technician authentication, user creation, role modification, tenant modification, policy changes, agent group changes, remote session creation, support-session generation, installer generation, file transfer, command execution, and unattended-access changes.

·        Web server logs must capture source IP, user agent, request path, method, status code, referrer, session identifier where available, authentication result, file upload activity, file download activity, API endpoint access, administrative console access, and abnormal request patterns.

·        Application telemetry must capture failed and successful login attempts, MFA events, password resets, token creation, session reuse, API token activity, technician account changes, MSP tenant changes, downstream customer access, integration changes, and abnormal administrative activity.

·        Email and web security telemetry should capture RMM-themed phishing lures, fake support pages, remote support download links, suspicious collaboration links, URL click events, QR-code redirection, user interaction with RMM installer downloads, and file download outcomes.

·        Browser and endpoint web telemetry should capture download source, referring page, zone identifier, SmartScreen or reputation events, downloaded filename, downloaded hash, user interaction context, and post-download execution.

·        Web and application telemetry must support correlation between suspicious inbound activity against RMM infrastructure and endpoint-side deployment, remote-control session establishment, tenant reassignment, command execution, installer generation, or downstream access.

·        Web and application telemetry must not be treated as mandatory for organizations that only consume SaaS-based RMM through managed endpoints, but SaaS audit logs or vendor-side administrative logs should be collected where available.

·        Web and application telemetry is required for any environment where the report scope includes exposed RMM exploitation, MSP compromise, downstream customer impact, self-hosted RMM infrastructure, support portal abuse, or RMM server-side compromise.

Telemetry Availability Requirements

Production deployment requires enough telemetry to prove execution, persistence, communication, baseline deviation, and follow-on behavior without relying on assumptions. The minimum viable telemetry baseline for this report is endpoint process telemetry, file and persistence telemetry, software inventory, DNS or proxy telemetry, and identity or authentication telemetry. Stronger deployments add endpoint network telemetry, endpoint management logs, RMM platform audit logs, EDR behavioral telemetry, web and application logs, and conditional cloud audit logs.

·        Minimum required telemetry includes endpoint process execution, parent-child relationships, command line, user context, file path, file metadata, file hash, signer, service creation, scheduled task creation, software inventory, DNS or proxy activity, and authentication events.

·        High-confidence deployment requires endpoint network connections mapped to process context, EDR behavioral telemetry, software inventory deltas, approved RMM inventory, approved tenant identifiers, approved management servers, authorized deployment paths, endpoint population baselines, and asset criticality.

·        RMM platform audit logs are required where self-hosted RMM servers, MSP administration platforms, support portals, technician consoles, tenant management, installer generation, or downstream customer environments are in scope.

·        Endpoint management logs are required where RMM agents may be deployed through Intune, SCCM, Jamf, Workspace ONE, GPO, cloud workload automation, virtual desktop tooling, software distribution systems, RMM platform automation, or equivalent management channels.

·        Identity telemetry is required for detecting helpdesk impersonation, suspicious privileged access, MFA changes, password resets, service-account misuse, technician account misuse, cloud identity activity, and post-RMM privilege expansion.

·        Cloud audit telemetry is required only when AWS, Azure, GCP, virtual desktop platforms, cloud-hosted workloads, endpoint management integrations, service-provider administration paths, or cloud-native remote command features are in scope.

·        SIEM normalization must preserve host, user, process, file, service, network, identity, tenant, asset, endpoint management, RMM platform, service-provider, and cloud fields needed to correlate raw telemetry without depending on other detection rules.

·        Retention should support enough historical comparison to determine whether RMM tool use, tenant association, management server, endpoint population, user, support workflow, deployment path, outbound destination, or administrative scope is new or baseline-approved.

·        Production deployment should not proceed for a rule unless the environment collects the fields required by that rule and has a defined baseline for approved RMM tooling or a clearly stated policy prohibiting the observed behavior.

Telemetry Limitations and Gaps

RMM abuse detection has meaningful telemetry limitations because the tools are often legitimate, signed, encrypted, cloud-relayed, and administratively approved in some parts of the environment. These gaps do not make detection weak, but they require disciplined baseline management, careful rule design, and explicit treatment of incomplete visibility.

·        Clean signed RMM binaries may not trigger malware controls, static file detections, or reputation-based alerts.

·        Official vendor relay infrastructure may appear legitimate in DNS, proxy, firewall, and TLS telemetry unless tenant mismatch, endpoint mismatch, host-role mismatch, timing, or post-compromise behavior is visible.

·        Network-only visibility may not distinguish approved support traffic from unauthorized remote-control sessions because RMM tools commonly use encrypted TLS, websockets, and cloud relays.

·        Product-name, service-name, signer, certificate, hash, file path, and domain indicators are fragile and may produce false positives or miss renamed, repackaged, portable, or newly abused tooling.

·        Endpoint telemetry gaps, missing command lines, weak parent-process capture, incomplete file metadata, absent service creation events, or short retention can materially reduce detection confidence.

·        Lack of software inventory or approved RMM baseline can cause excessive noise and make it difficult to separate legitimate IT activity from unauthorized deployment.

·        Missing tenant identifiers, management server context, support-session IDs, installer generation records, SaaS audit logs, or RMM platform audit logs can weaken detection of unauthorized RMM enrollment.

·        MSP and service-provider workflows can create visibility gaps when remote access originates through third-party systems, shared support infrastructure, delegated administration, or downstream customer environments.

·        Endpoint management abuse may be missed if Intune, SCCM, Jamf, GPO, virtual desktop, or software distribution logs are not ingested and normalized with endpoint execution telemetry.

·        Cloud detection is limited unless cloud audit logs, endpoint telemetry on cloud workloads, endpoint management logs, identity logs, service-account logs, or virtual desktop telemetry directly observe deployment, execution, enrollment, or administrative misuse.

·        Crash and fault telemetry may indicate exploit attempts against RMM infrastructure but cannot prove compromise without follow-on evidence.

·        YARA and file-scanning telemetry are weak against clean legitimate tools and should be scoped to malicious wrappers, fake software, repackaged installers, altered deployment packages, or policy-prohibited tools.

·        Smaller environments may have less telemetry volume and fewer baselines, but they must not lower evidence requirements; scope can be reduced, but production detections still require observable suspicious behavior.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

RMM tool abuse creates strong detection opportunities when the environment can observe unauthorized remote-control capability being introduced, persisted, connected, or used outside an approved administrative workflow. The highest-value opportunities are not based on the mere presence of a known RMM product. They are based on the relationship between execution context, deployment path, tenant association, persistence, outbound communication, host role, user role, software inventory, and follow-on activity.

·        Detect first-seen RMM installers, support clients, remote-control agents, portable support tools, or unattended-access components on hosts without an approved RMM baseline.

·        Detect RMM execution from suspicious parent processes such as browsers, email clients, collaboration tools, archive utilities, document readers, command shells, scripting engines, endpoint management agents, remote command utilities, or LOLBins.

·        Detect RMM execution from suspicious paths such as downloads folders, temporary folders, user profile paths, archive extraction directories, removable media, cloud-synced folders, shared folders, or non-standard administrative staging locations.

·        Detect RMM agent installation, support-session initiation, or unattended-access enablement by non-administrative users, unusual service accounts, newly active identities, suspicious helpdesk accounts, MSP-linked identities, or accounts without approved remote-support duties.

·        Detect new persistence artifacts associated with remote access tooling, including services, scheduled tasks, registry autoruns, startup entries, launch agents, launch daemons, login items, system extensions, remote-control permissions, and unattended-access settings.

·        Detect RMM enrollment into unknown tenants, unauthorized management servers, unexpected relays, unmanaged MSP infrastructure, attacker-generated support sessions, or tenant associations that do not match approved inventory.

·        Detect first-seen or rare outbound RMM traffic from hosts not expected to use remote management, especially when associated with the responsible process, user, host role, endpoint population, and timing after suspicious execution.

·        Detect RMM tool stacking when multiple RMM, remote desktop, tunneling, screen-sharing, or support tools appear on the same endpoint, user account, subnet, cloud workload group, MSP scope, or administrative scope within a compressed window.

·        Detect RMM activity followed by discovery, credential access, privilege escalation, remote service creation, administrative share access, file staging, exfiltration preparation, backup interference, security-tool tampering, or ransomware staging.

·        Detect RMM activity on prohibited or high-risk systems such as domain controllers, identity infrastructure, backup servers, privileged access workstations, executive endpoints, security tooling, cloud management systems, regulated-data systems, and downstream customer administration systems.

·        Detect exposed RMM server abuse through suspicious administrative login patterns, abnormal technician account activity, tenant changes, installer generation, mass agent check-ins, remote session creation, command execution, policy changes, or downstream endpoint deployment.

·        Detect cloud or endpoint-management-assisted RMM deployment where logs show remote command execution, device management actions, virtual desktop changes, cloud workload automation, service-account misuse, startup script activity, or extension-based software staging.

High-Confidence Detection Opportunities

The strongest production opportunities are those that combine multiple raw telemetry signals into a single rule without depending on another detection rule. These opportunities should be prioritized in S25 because they are behaviorally durable and less dependent on static indicators.

·        Unauthorized RMM installer execution from suspicious user-controlled paths with suspicious parent process context and no approved software inventory baseline.

·        New RMM service, scheduled task, startup entry, launch daemon, login item, or unattended-access configuration created by a non-standard user or deployment path.

·        First-seen RMM process execution followed by outbound connections to remote session brokers, vendor relays, management servers, or tenant-mismatched infrastructure.

·        RMM deployment followed by credential access, discovery, lateral movement, security-tool tampering, backup interference, file staging, or ransomware preparation.

·        Multiple RMM or remote access tools appearing on the same endpoint or administrative scope within a short period, especially after tool removal, blocking, quarantine, or failed connection attempts.

·        RMM activity on high-value infrastructure where remote support is prohibited or tightly restricted, including domain controllers, identity systems, backup systems, privileged access workstations, and security tooling.

·        Exposed RMM management platform activity where suspicious administrative access is followed by installer generation, policy change, tenant modification, agent enrollment, remote session creation, command execution, or downstream endpoint activity.

·        Endpoint management, virtual desktop, or cloud control-plane actions that deploy or configure RMM tooling on workloads or endpoints outside approved change-control and support workflows.

Moderate Detection Opportunities

Moderate opportunities are useful for hunting, triage, correlation, or customer-specific production rules, but they require stronger baselines or additional supporting evidence before deployment as broad production detections.

·        RMM vendor domain or relay traffic from a host where process association is unavailable but host role, endpoint population, tenant mismatch, or baseline deviation is visible.

·        Known RMM process or service names appearing on endpoints where the organization has incomplete software inventory.

·        Suspicious file metadata, signer mismatch, altered product description, renamed executable, or missing certificate on a file that resembles remote support tooling.

·        Long-lived encrypted sessions or websocket behavior consistent with remote-control activity when endpoint process context is unavailable.

·        Support-session artifacts, enrollment tokens, tenant files, or configuration files without complete endpoint execution lineage.

·        Authentication anomalies from helpdesk, MSP, technician, or service accounts when no endpoint-side RMM activity is immediately visible.

·        RMM server crashes, web errors, malformed requests, authentication failures, or installer-generation anomalies without confirmed administrative change or endpoint-side deployment.

·        YARA or file-scanning matches against suspicious wrappers, fake support installers, repackaged tools, malicious bundles, or prohibited remote access packages.

·        Cloud audit events showing suspicious remote command, startup script, extension deployment, or device-management activity when endpoint execution telemetry is delayed or incomplete.

·        Network flow anomalies showing rare outbound management traffic where DNS, proxy, or endpoint process mapping is incomplete.

Low-Confidence or Non-Deployable Opportunities

Some RMM-related ideas may be useful as investigation pivots but should not become standalone production rules. These opportunities are fragile, noisy, or too dependent on assumptions about legitimate remote administration.

·        Alerting solely because an RMM product name, service name, process name, signer, certificate, file path, or vendor domain appears.

·        Alerting solely on traffic to official RMM vendor infrastructure without tenant mismatch, host-role mismatch, baseline deviation, suspicious execution context, or follow-on activity.

·        Alerting solely on clean signed RMM binaries without suspicious packaging, prohibited-tool policy, suspicious deployment path, or unauthorized configuration.

·        Alerting solely on generic remote desktop, screen-sharing, tunneling, or support-tool presence without baseline deviation or suspicious control behavior.

·        Alerting solely on exploit-attempt traffic against RMM infrastructure without evidence of successful authentication, file write, administrative change, command execution, agent deployment, or downstream endpoint activity.

·        Alerting solely on crash or fault telemetry from RMM servers without suspicious access patterns, administrative changes, or endpoint-side impact.

·        Alerting solely on YARA matches for legitimate RMM tools unless the tool is explicitly prohibited or the file is a suspicious wrapper, fake installer, altered package, or malicious bundle.

·        Alerting solely on cloud audit activity without proof that the action deployed, staged, enabled, enrolled, or configured RMM tooling or directly supported post-compromise control.

·        Alerting solely on MSP or helpdesk access without tenant mismatch, abnormal workflow, suspicious account activity, unsupported geography, unauthorized endpoint scope, or downstream behavior.

·        Alerting solely on rare network connections without process, DNS, proxy, identity, host-role, tenant, or timing context.

Telemetry-Driven Gaps

The main detection gaps come from missing telemetry, weak baselines, incomplete inventory, and limited visibility into SaaS RMM platforms or third-party service-provider operations. These gaps should be documented explicitly because they affect rule confidence, production deployment readiness, and SOC triage quality.

·        Missing endpoint command-line telemetry reduces confidence in distinguishing interactive support, script-driven installation, malicious staging, and legitimate deployment.

·        Weak parent-child process telemetry reduces the ability to detect RMM execution launched from browsers, email clients, collaboration tools, archive utilities, script interpreters, LOLBins, or endpoint management agents.

·        Incomplete software inventory weakens detection of first-seen RMM tools, unauthorized remote access clients, tool stacking, and post-removal reinstallation.

·        Missing service creation, scheduled task, autorun, launch agent, launch daemon, login item, and permission-change telemetry weakens detection of persistence and unattended access.

·        Missing tenant identifiers, management server details, support-session IDs, installer generation records, SaaS audit logs, and RMM platform audit logs weakens detection of unauthorized enrollment and service-provider misuse.

·        DNS-only or firewall-only visibility weakens detection when encrypted RMM traffic uses official vendor relays, cloud-hosted infrastructure, or shared remote-support services.

·        Missing endpoint process-to-network mapping weakens confidence in associating outbound RMM communication with the responsible binary, user, and execution context.

·        Missing identity telemetry weakens detection of helpdesk impersonation, technician account misuse, service-account abuse, MFA manipulation, privileged access changes, and post-RMM expansion.

·        Missing endpoint management logs weakens detection when RMM tooling is deployed through Intune, SCCM, Jamf, GPO, software distribution systems, virtual desktop tooling, or cloud workload automation.

·        Missing cloud audit, workload endpoint, service-account, and virtual desktop telemetry prevents reliable cloud-native detection of AWS, Azure, or GCP deployment paths.

·        Limited retention reduces the ability to establish first-seen status, baseline deviation, tenant mismatch, tool stacking, and sequence timing across initial access, persistence, control, and post-compromise activity.

·        Limited access to MSP, SaaS RMM, or service-provider logs can obscure cross-tenant administration, downstream customer impact, unauthorized support sessions, and attacker-generated deployment packages.

Adversary Evasion and Resilience Gaps

Adversaries can evade weak RMM detections by changing tools, using official vendor infrastructure, renaming binaries, relying on signed software, abusing approved accounts, or hiding inside legitimate service-provider workflows. Detection engineering must explicitly account for these gaps so S25 rules do not become brittle.

·        Adversaries may switch between RMM platforms to avoid product-specific detections.

·        Adversaries may use official vendor download links, official relay infrastructure, signed installers, and legitimate support clients to reduce malware and reputation signals.

·        Adversaries may rename binaries, alter file metadata, wrap installers, repackage tools, or deploy portable support clients to evade default process-name detections.

·        Adversaries may deploy RMM tooling through compromised helpdesk accounts, MSP workflows, endpoint management platforms, virtual desktop tooling, cloud workload automation, or service accounts.

·        Adversaries may enable unattended access, hidden tray behavior, reconnect behavior, credential caching, or remote shell features after installation to preserve control.

·        Adversaries may remove or replace the first RMM tool after gaining access, creating post-removal blind spots if historical telemetry is weak.

·        Adversaries may deploy multiple RMM tools to maintain alternate access paths after one tool is blocked or quarantined.

·        Adversaries may blend RMM traffic into normal encrypted outbound traffic, websocket activity, cloud relay traffic, or approved administrative egress paths.

·        Adversaries may use tenant mismatch, attacker-controlled support sessions, or unmanaged service-provider infrastructure that looks vendor-legitimate but is not organization-approved.

·        Adversaries may perform post-compromise actions through interactive remote sessions that produce fewer obvious malware artifacts than scripted intrusion paths.

·        Adversaries may exploit exposed RMM servers and use the legitimate platform to generate installers, push agents, create sessions, or reach downstream customer environments.

·        Adversaries may abuse cloud control planes or endpoint management tools to stage RMM on workloads without direct user interaction.

Cloud Detection Opportunities and Gaps

Cloud-native detection is conditionally viable for this report, but it must be anchored to directly observable cloud, workload, identity, endpoint management, virtual desktop, or service-provider telemetry. Cloud rules should not be forced where the attack path is purely endpoint, network, or SaaS RMM driven.

·        AWS opportunities exist when Systems Manager, EC2 user data, instance connect, startup automation, IAM activity, CloudTrail, VPC Flow Logs, EDR on EC2, or workload telemetry shows RMM staging, deployment, execution, or service-account misuse.

·        Azure opportunities are stronger where Entra ID, Microsoft Defender, Intune, Azure VM Run Command, Custom Script Extension, Azure Virtual Desktop, Microsoft 365 audit logs, service principals, or cloud-hosted Windows workloads show RMM deployment, identity misuse, or remote-control enablement.

·        GCP opportunities exist where Compute Engine metadata startup scripts, OS Config, IAM activity, service-account use, Cloud Audit Logs, VPC Flow Logs, or workload endpoint telemetry shows RMM staging, deployment, or execution.

·        Cloud detections are high value when a cloud control-plane action directly precedes RMM execution, endpoint enrollment, tenant mismatch, outbound RMM communication, or post-compromise behavior on a cloud-hosted workload.

·        Cloud detections are high value when identity activity after RMM access includes suspicious sign-ins, MFA changes, privileged role assignment, service-principal modification, mailbox access, storage access, snapshot activity, or cross-resource enumeration.

·        Cloud detections are weak when they only observe generic administrative actions without evidence of RMM deployment, execution, enrollment, control-channel communication, or post-compromise behavior.

·        Cloud-native detections should remain conditional for AWS and GCP unless the report scope explicitly includes cloud-hosted workloads, cloud workload automation, endpoint telemetry on cloud systems, or service-account misuse.

·        Azure has the strongest cloud opportunity because RMM abuse commonly intersects with Windows endpoints, Entra ID, Microsoft Defender, Intune, Microsoft 365, Azure Virtual Desktop, and enterprise identity telemetry.

·        Cloud control-plane telemetry must be paired with workload endpoint telemetry, identity telemetry, endpoint management logs, or network egress telemetry wherever possible.

·        If cloud telemetry cannot directly prove deployment, execution, enrollment, identity misuse, or control-channel behavior, the cloud item should remain a conditional detection opportunity rather than an S25 production rule.

System-Level Viability Outlook

The system-level viability outlook should guide S25 rule development without prematurely locking final rule counts. The highest-confidence systems are those that can observe endpoint execution, persistence, process lineage, software inventory, network communication, identity activity, and post-compromise behavior. Network-only, file-only, and cloud-only systems require tighter scoping.

·        SentinelOne has high viability because it can observe endpoint execution, process lineage, file activity, service creation, persistence changes, endpoint network activity, behavioral context, and post-compromise activity.

·        Splunk has high viability when it ingests endpoint, DNS, proxy, authentication, software inventory, endpoint management, and cloud audit logs with usable normalization.

·        Elastic has high viability where endpoint, process, file, persistence, network, authentication, and host telemetry are available through Elastic Agent, endpoint integrations, or normalized logs.

·        Sigma has high viability for portable behavior logic covering suspicious parentage, first-seen or unauthorized RMM execution, service creation, persistence, tool stacking, and post-RMM behavior.

·        QRadar has moderate-to-high viability where endpoint, identity, DNS, proxy, firewall, software inventory, and endpoint management telemetry are normalized with consistent host and user fields.

·        Suricata has moderate viability as a supporting network layer for known or suspicious RMM infrastructure, TLS/SNI, HTTP hostnames, unusual egress, and prohibited traffic, but it should not be the primary detection layer.

·        YARA has limited-to-moderate viability for suspicious installers, fake support software, repackaged tools, malicious wrappers, altered deployment packages, and prohibited software. It is weak against clean signed RMM binaries.

·        AWS has conditional viability and should only receive production rules when cloud control-plane or workload telemetry directly observes RMM staging, deployment, execution, identity misuse, or control-channel behavior.

·        Azure has moderate-to-high conditional viability and is the strongest cloud candidate when Entra ID, Microsoft Defender, Intune, Azure VM Run Command, Azure Virtual Desktop, Microsoft 365, or cloud-hosted workload telemetry is in scope.

·        GCP has conditional viability and should only receive production rules when Compute Engine, OS Config, IAM, service-account, cloud audit, VPC flow, or workload endpoint telemetry directly observes RMM staging, deployment, execution, or control behavior.

Detection Gap Disposition

Detection gaps should be handled through rule scoping, telemetry requirements, baselining, and conditional deployment rather than by weakening detection logic. A rule should not be promoted to S25 if it depends on missing fields, generic assumptions, product-name matching, or another rule firing first.

·        Promote opportunities to S25 only when the rule can stand on direct observable telemetry.

·        Keep weak product-name, domain-only, hash-only, signer-only, crash-only, and network-only concepts as hunting or enrichment unless tightly scoped to prohibited tools or policy-defined conditions.

·        Require approved RMM inventory, approved tenant identifiers, approved management servers, approved deployment paths, and authorized support workflows for production-quality baseline-driven rules.

·        Require endpoint process and persistence telemetry for the strongest RMM deployment and unauthorized access detections.

·        Require identity telemetry for helpdesk, MSP, technician, service-account, privileged access, and post-RMM expansion detections.

·        Require RMM platform, SaaS audit, or service-provider logs for exposed RMM server abuse, technician-console misuse, tenant changes, installer generation, and downstream customer impact.

·        Require cloud audit, workload endpoint, endpoint management, virtual desktop, or service-account telemetry before promoting AWS, Azure, or GCP opportunities into production rules.

·        Preserve Suricata as supporting visibility unless traffic can be tied to prohibited infrastructure, tenant mismatch, baseline deviation, host-role mismatch, or strong timing correlation.

·        Preserve YARA as narrow file-level support for suspicious packages, fake software, altered installers, wrappers, or prohibited tools.

·        Treat unsupported opportunities as documented gaps rather than forcing low-confidence rules.

S25 — Ultra-Tuned Detection Engineering Rules

Suricata

Detection Viability Assessment

Suricata has moderate detection viability for this report. It can provide useful supporting visibility into unauthorized outbound communication with RMM relay, remote support, and remote session infrastructure, but it cannot reliably determine whether the RMM session is authorized, whether the tool was installed by a legitimate administrator, whether the endpoint enrolled into an approved tenant, or whether post-compromise actions occurred after remote access was established.

Suricata should be used as a supporting network detection layer, not as the primary detection backbone for RMM abuse. Its strongest use case is identifying restricted or prohibited endpoint populations communicating with RMM infrastructure outside approved support workflows.

Suricata Rule 1

Unauthorized RMM Relay or Remote Support Infrastructure Access from Restricted Endpoint Populations

Detection Objective

Detect outbound network communication from restricted endpoint populations to known RMM relay, remote support, remote session, or management infrastructure where the source endpoint is not expected to initiate remote management traffic.

This rule is intended to identify unauthorized RMM control-channel establishment, suspicious support-session initiation, or remote management egress from systems where RMM use is prohibited or tightly restricted.

Behavioral Rationale

RMM abuse often depends on encrypted outbound connectivity to vendor relay infrastructure, remote session brokers, management servers, or cloud-hosted support infrastructure. Network telemetry alone cannot prove compromise, but unauthorized RMM egress from restricted systems is a strong supporting signal when the environment maintains an approved RMM inventory and defines which endpoint groups may use remote management tooling.

This rule detects baseline deviation and host-role mismatch. It does not treat legitimate RMM vendor infrastructure as inherently malicious. The detection becomes strongest when the source system is a domain controller, identity server, backup server, privileged access workstation, executive endpoint, security tool, regulated-data system, cloud management system, or other host class where direct RMM egress is prohibited.

Primary Telemetry Source

·        Network IDS telemetry from Suricata observing outbound TLS or HTTP traffic.

Required Suricata Data Elements

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol.

·        TLS SNI or HTTP Host value.

·        Flow direction.

·        Internal source network classification.

·        Approved RMM egress scope.

·        Restricted endpoint scope.

·        Alert timestamp.

Rule Logic Summary

·        Alert on outbound traffic from restricted endpoint populations.

·        Match TLS SNI or HTTP Host values associated with RMM, remote support, or remote session infrastructure.

·        Exclude approved RMM administration networks through deployment scoping, pass rules, or source network variables.

·        Treat the alert as a high-priority supporting signal when the source is a restricted or high-value system where direct RMM egress is prohibited.

System-Native Rule Format

Suricata rule format.

Engineering Implementation Instructions

·        Define $RESTRICTED_RMM_EGRESS_NETS before deployment. This variable should include endpoint populations where direct RMM traffic is prohibited or tightly restricted, such as ordinary user workstations, executive endpoints, privileged access workstations, domain controllers, identity systems, backup servers, security tooling, regulated-data systems, cloud management systems, and cloud workload subnets where RMM is not approved.

·        Do not define $RESTRICTED_RMM_EGRESS_NETS as the entire enterprise unless the organization has a mature RMM egress policy and validated approved support workflows.

·        Create Suricata pass rules or upstream exclusions for approved RMM administration networks, sanctioned MSP jump hosts, endpoint management servers, approved helpdesk systems, and known authorized support infrastructure.

·        Maintain an approved RMM inventory before production enforcement. The inventory should include approved vendors, approved tenant identifiers, approved relay domains, approved management servers, approved MSP infrastructure, approved support workflows, and expected endpoint populations.

·        Validate the RMM domain list against the customer’s authorized tooling. Remove vendors that are approved broadly across the restricted population and add vendors that are prohibited or high-risk in the customer environment.

·        Do not treat this rule as proof of compromise by itself. The alert should trigger endpoint, identity, software inventory, proxy, and helpdesk enrichment to determine whether the source host executed or installed RMM tooling, whether the tenant is approved, and whether post-compromise behavior followed.

·        Tune by source role first, not by disabling the rule globally. Expected tuning dimensions include source subnet, asset criticality, approved RMM vendor, approved MSP path, support workflow, tenant identifier, sanctioned deployment method, and approved remote-support population.

·        Prioritize alerts from domain controllers, backup servers, identity systems, security tools, cloud management systems, privileged access workstations, executive endpoints, and regulated-data systems.

·        Pair this rule with endpoint and SIEM detections in later S25 systems. Suricata should identify suspicious egress, while endpoint and SIEM telemetry should validate execution, persistence, tenant association, identity misuse, and post-compromise behavior.

·        Reassess the domain list regularly because RMM vendor infrastructure, relay domains, SaaS tenant patterns, and abused support platforms change over time.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy only against explicitly restricted or prohibited endpoint populations where the customer has defined direct RMM egress as unauthorized. Required customer data includes restricted subnet list, prohibited endpoint classes, approved support jump hosts, approved management servers, and approved RMM vendors. Do not deploy enterprise-wide at this tier.

·        Tier 2 deployment: Add approved RMM inventory, approved relay domains, approved management servers, sanctioned MSP infrastructure, approved support workflows, and known helpdesk routing paths. Use this tier for source-scoped production alerting with proxy, DNS, helpdesk, and software inventory enrichment.

·        Tier 3 deployment: Add asset criticality, endpoint role mapping, software inventory, identity context, proxy logs, DNS logs, endpoint process enrichment, and endpoint population baselines. Use this tier to prioritize alerts from identity systems, backup servers, privileged endpoints, security tooling, regulated-data systems, and executive endpoints.

·        Tier 4 deployment: Add tenant identifiers, RMM platform audit logs, endpoint management records, service-provider context, change-control data, SIEM correlation with endpoint detections, and post-compromise enrichment. Use this tier for mature enterprise deployment where alerts can be evaluated against approved tenants, approved deployment paths, authorized support workflows, and follow-on activity.

·        Tiering changes deployment scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require restricted-source RMM egress, approved-scope deviation, tenant mismatch, host-role mismatch, or prohibited-policy violation before production alerting.

·        If the customer lacks restricted endpoint mapping, approved RMM inventory, approved support infrastructure, and approved egress paths, keep this rule in hunting or pilot mode until the minimum baseline exists.

·        If the customer lacks tenant identifiers or RMM platform audit logs, production alerts may still be viable under restricted-source policy conditions, but incident confirmation must rely on endpoint, identity, software inventory, proxy, or helpdesk enrichment.

·        If the customer uses MSP or third-party support workflows, those workflows must be represented explicitly in the baseline. MSP access should not be used as a blanket suppression condition.

Expected False Positives

·        Legitimate IT support sessions from endpoints included in the restricted source scope.

·        MSP support activity routed directly from customer endpoints instead of approved jump hosts or management servers.

·        Emergency break-fix sessions using temporary RMM tools.

·        Software vendor support activity where a user is instructed to initiate a remote support session.

·        Legacy remote support workflows not represented in the approved RMM inventory.

·        Security, helpdesk, endpoint management, or SOC testing from restricted subnets.

False Positive Reduction

·        Require source population scoping before production deployment.

·        Exclude approved support jump hosts and management servers.

·        Exclude approved RMM relay domains only where the source population is authorized to use them.

·        Correlate with software inventory, endpoint process telemetry, proxy logs, identity logs, and helpdesk tickets during triage.

·        Escalate rather than suppress alerts from high-value systems where direct RMM use is prohibited.

·        Maintain separate handling for sanctioned emergency-support workflows so temporary legitimate support does not create recurring noise.

·        Use asset criticality to prioritize high-risk alerts and avoid over-escalation from low-risk lab or test systems.

Known Limitations

·        TLS SNI may be unavailable where encrypted client hello is used or where telemetry capture is incomplete.

·        The rule cannot determine whether the RMM tenant is approved unless tenant-specific domains or proxy enrichment are available.

·        The rule cannot prove local execution, installation path, persistence, identity misuse, or post-compromise behavior.

·        Official vendor infrastructure can be used for both legitimate and malicious sessions.

·        Broad deployment without source scoping can create unacceptable noise.

·        RMM vendors may use shared infrastructure, CDNs, cloud relays, or changing domain patterns.

·        The rule does not detect RMM activity over private management servers unless those domains or destinations are added.

·        The rule does not detect RMM tools that avoid visible RMM-branded infrastructure or use generic cloud hosting.

·        The rule does not identify attacker use of an approved RMM tenant unless additional tenant, endpoint, proxy, identity, or platform telemetry shows misuse.

DRI Score

·        DRI: 7.6

·        Rating: Survivor rule

·        Justification: The rule is behaviorally useful because it detects unauthorized RMM egress from restricted endpoint populations rather than matching RMM traffic across the entire enterprise. Its resilience is moderate because it can survive tool variation across multiple RMM vendors and is anchored to prohibited source scope and baseline deviation. Its score is limited by reliance on visible TLS SNI or HTTP Host values, vendor-domain coverage, and the inability of Suricata alone to prove execution, tenant authorization, persistence, identity misuse, or post-compromise activity.

TCR Score

·        Operational TCR: 6.7

·        Full-Telemetry TCR: 7.6

·        Operational TCR Justification: In normal environments, Suricata visibility may include partial TLS SNI, HTTP Host, and flow metadata, but may lack endpoint process mapping, tenant context, software inventory, and identity correlation. Operational confidence depends heavily on source scoping, approved egress baselines, and enrichment from other telemetry sources.

·        Full-Telemetry TCR Justification: Under stronger telemetry conditions, confidence improves when Suricata alerts are enriched with proxy logs, endpoint process-to-network mapping, software inventory, approved RMM inventory, identity telemetry, asset criticality, RMM platform audit logs, tenant context, and helpdesk workflow context. Even under ideal conditions, Suricata remains a supporting layer rather than the primary proof source.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1105 — Ingress Tool Transfer.

·        T1071.001 — Web Protocols.

·        T1572 — Protocol Tunneling.

·        T1090 — Proxy.

Rule Disposition

·        Include as one Suricata supporting network rule.

·        Do not promote additional Suricata rules unless a customer has tenant-specific RMM relay domains, private RMM management infrastructure, or prohibited-vendor egress policies that make additional signatures materially stronger.

·        Do not use this rule as a standalone compromise determination.

·        Treat this rule as a network-triggered investigation path that requires endpoint, identity, software inventory, proxy, RMM platform, helpdesk, or service-provider enrichment before incident confirmation.

Detection Code

alert tls $RESTRICTED_RMM_EGRESS_NETS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX EXP RMM Tool Abuse - Unauthorized outbound RMM relay or remote support infrastructure access from restricted endpoint population";
    flow:to_server,established;
    tls.sni;
    pcre:"/(^|\.)(anydesk\.com|teamviewer\.com|screenconnect\.com|connectwisecontrol\.com|simple-help\.com|splashtop\.com|atera\.com|ninjaone\.com|syncromsp\.com|zohoassist\.com|zoho\.com|beyondtrustcloud\.com|bomgarcloud\.com|logmein\.com|gotoassist\.com)$/i";
    classtype:policy-violation;
    sid:4252101;
    rev:1;
    metadata:
        attack_target Endpoint,
        deployment Perimeter,
        deployment Internal,
        signature_severity Major,
        created_at 2026_04_29,
        updated_at 2026_04_29,
        cyberdax_report "EXP RMM Tool Abuse",
        cyberdax_behavior "Unauthorized RMM control-channel egress",
        cyberdax_rule_role "Supporting network detection";
)

Optional Protocol Companion Signature

Use this companion signature only if the environment observes clear-text HTTP download or support-session traffic for RMM tooling. It should not be deployed as a separate CyberDax rule count item unless the environment explicitly treats HTTP Host telemetry as a separate detection objective.

alert http $RESTRICTED_RMM_EGRESS_NETS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX EXP RMM Tool Abuse - Unauthorized HTTP RMM or remote support infrastructure access from restricted endpoint population";
    flow:to_server,established;
http.host;
    pcre:"/(^|\.)(anydesk\.com|teamviewer\.com|screenconnect\.com|connectwisecontrol\.com|simple-help\.com|splashtop\.com|atera\.com|ninjaone\.com|syncromsp\.com|zohoassist\.com|zoho\.com|beyondtrustcloud\.com|bomgarcloud\.com|logmein\.com|gotoassist\.com)$/i";
    classtype:policy-violation;
    sid:4252102;
    rev:1;
    metadata:
        attack_target Endpoint,
        deployment Perimeter,
        deployment Internal,
        signature_severity Major,
        created_at 2026_04_29,
        updated_at 2026_04_29,
        cyberdax_report "EXP RMM Tool Abuse",
        cyberdax_behavior "Unauthorized RMM HTTP support infrastructure access",
        cyberdax_rule_role "Protocol companion for Suricata Rule 1";
)

Suricata Final Disposition

Suricata receives 1 audit-passing rule for this report. Additional Suricata concepts were not promoted because they would rely too heavily on generic RMM domain matching, encrypted traffic assumptions, static indicators, or network-only evidence without sufficient behavioral context.

SentinelOne

Detection Viability Assessment

SentinelOne has high detection viability for this report. It provides strong endpoint-level visibility into RMM installer execution, process lineage, command-line activity, file creation, service-oriented persistence, endpoint network activity, suspicious child processes, behavioral context, and post-compromise activity. This makes SentinelOne one of the strongest systems for detecting RMM tool abuse because the core behaviors occur directly on endpoints where SentinelOne can observe execution, persistence, control-channel activity, and follow-on intrusion behavior.

SentinelOne should be treated as a primary detection layer for this report. The strongest rules are behavior-driven and focus on unauthorized RMM introduction, suspicious deployment context, persistence or unattended-access enablement, and RMM-launched post-compromise activity. Product names and vendor identifiers are used as scoped selectors, but the detection strength comes from execution context, parent process, file path, user context, endpoint role, persistence behavior, and suspicious post-execution behavior.

The detection code below is written as SentinelOne Deep Visibility / STAR-ready query logic. Field names, operators, and available telemetry must be validated in the customer tenant before production deployment because SentinelOne schemas, package-level telemetry, and query behavior can vary.

SentinelOne Rule 1

Unauthorized RMM Execution from Suspicious Parent Process or User-Controlled Path

Detection Objective

Detect execution of known RMM, remote support, or remote-control tooling from suspicious parent processes or user-controlled staging paths inconsistent with approved software deployment.

This rule is intended to identify RMM tooling introduced through phishing, fake support lures, browser downloads, collaboration-tool downloads, archive extraction, user-initiated execution, or attacker staging rather than approved endpoint management workflows.

Behavioral Rationale

RMM abuse frequently begins when a user is induced to download and run a legitimate remote support tool, or when an adversary stages a legitimate RMM agent from a user-writable path after initial access. The tool may be signed and vendor-legitimate, so detection cannot rely on malware reputation. The stronger signal is the mismatch between the tool’s administrative function and the execution context, especially when the parent process is a browser, email client, document reader, archive utility, collaboration tool, shell, scripting engine, or remote command utility.

This rule detects unauthorized RMM introduction by combining RMM process, path, or command-line indicators with suspicious parentage or suspicious execution location. It is not intended to alert on approved RMM deployment from sanctioned endpoint management systems, software distribution tools, administrative management servers, or approved helpdesk automation.

Primary Telemetry Source

·        SentinelOne endpoint process execution and Deep Visibility telemetry.

Required SentinelOne Data Elements

·        Process name or equivalent image name field.

·        Process command line.

·        Process image path.

·        Parent process name.

·        Parent process image path where available.

·        User or initiating account.

·        Endpoint hostname or agent name.

·        Process start time.

·        Process hash where available.

·        Signer or publisher context where available.

·        Site, account, group, or endpoint scope.

·        File creation time or first-seen context where available.

Rule Logic Summary

·        Identify execution of RMM, remote support, remote-control, unattended-access, or support-client tooling.

·        Require suspicious parent process context or execution from user-controlled paths.

·        Exclude approved endpoint management, software deployment, helpdesk, or administrative management processes through customer-specific scoping.

·        Treat the alert as higher priority when the endpoint has no approved RMM baseline, the user is not part of an approved support workflow, or the host belongs to a restricted endpoint population.

System-Native Rule Format

SentinelOne Deep Visibility / STAR-ready query logic.

Engineering Implementation Instructions

·        Validate SentinelOne field names and operator behavior in the customer tenant before production deployment. The query uses normalized field names that may require local adjustment.

·        Scope the rule to Windows endpoints first unless the customer has mature macOS or Linux RMM baselines and SentinelOne telemetry coverage for those systems.

·        Build an approved RMM inventory before production deployment. The inventory should include approved RMM vendors, approved executable names, approved installation paths, approved tenants, approved management servers, approved deployment tools, and approved support workflows.

·        Exclude approved deployment processes such as sanctioned endpoint management agents, software distribution systems, administrative management servers, and approved helpdesk automation.

·        Do not exclude the RMM product globally. Approved RMM products can still be abused through user-driven installation, attacker-generated support sessions, tenant mismatch, or compromised support workflows.

·        Tune by endpoint role, user role, site, group, and approved deployment mechanism rather than suppressing the rule across all systems.

·        Prioritize alerts from ordinary user workstations, executive endpoints, privileged access workstations, domain controllers, identity systems, backup servers, security tooling, regulated-data systems, and cloud-hosted workloads.

·        Enrich alerts with software inventory, SentinelOne storyline context, DNS or proxy telemetry, helpdesk records, identity telemetry, and approved RMM tenant data.

·        Treat the alert as an unauthorized RMM introduction signal, not a complete compromise determination unless supported by persistence, outbound control traffic, identity misuse, or post-compromise behavior.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to endpoints where RMM execution is prohibited or tightly restricted. Required customer data includes restricted endpoint groups, approved RMM vendor list, approved deployment tools, and approved helpdesk accounts.

·        Tier 2 deployment: Add approved installation paths, approved parent processes, approved support workflows, software inventory, and helpdesk ticket context. Use this tier for production alerting on suspicious RMM execution from user-controlled paths or suspicious parent processes.

·        Tier 3 deployment: Add endpoint role mapping, asset criticality, identity context, RMM tenant identifiers, approved management servers, proxy enrichment, and endpoint process-to-network visibility. Use this tier to prioritize alerts from high-value endpoints and validate tenant mismatch or unauthorized relay use.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management logs, change-control data, service-provider context, and SIEM correlation with identity and network telemetry. Use this tier for mature enterprise deployment where SentinelOne alerts can be evaluated against approved deployment paths and follow-on behavior.

·        Tiering changes deployment scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM execution plus suspicious parentage, suspicious path, approved-scope deviation, or prohibited-policy violation.

·        If the customer lacks approved RMM inventory and endpoint role mapping, keep the rule in pilot mode for baseline development before production enforcement.

Expected False Positives

·        Legitimate break-fix support initiated by a user through a browser download.

·        Helpdesk-guided remote support sessions using temporary support clients.

·        Software vendor support activity initiated from a user workstation.

·        IT testing of portable RMM tools from downloads or temporary directories.

·        Approved support workflows not yet represented in the baseline.

·        Legacy remote support practices that bypass endpoint management tooling.

False Positive Reduction

·        Exclude approved software deployment tools and approved helpdesk automation paths.

·        Require suspicious parent process or suspicious path instead of alerting only on RMM process name.

·        Add approved RMM installation paths and approved support workflows to the baseline.

·        Validate alerts against helpdesk tickets, support-session records, identity context, and software inventory.

·        Keep alerts from high-value or prohibited systems even when similar activity is suppressed on ordinary support endpoints.

Known Limitations

·        The rule depends on process name, command-line, and path visibility.

·        Renamed RMM binaries may evade product-name selectors unless command-line, signer, path, tenant, or behavior still matches.

·        Approved RMM tools may legitimately execute from user paths during emergency support.

·        The rule does not prove persistence, tenant mismatch, network communication, or post-compromise activity by itself.

·        SentinelOne field availability and query syntax may vary by tenant, product package, and query language version.

·        The rule requires customer-specific allowlisting to avoid noise in environments with heavy helpdesk or MSP support activity.

DRI Score

·        DRI: 8.8

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it detects RMM execution in suspicious deployment contexts rather than simply matching a product name. It is resilient across multiple RMM vendors and delivery methods because it combines tool indicators with parent process, execution path, and approved-scope deviation. Its score is limited by dependence on recognizable RMM identifiers and customer baseline quality.

TCR Score

·        Operational TCR: 8.1

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: In normal SentinelOne deployments, endpoint process, parent process, command line, and path telemetry are commonly available, but local baseline quality and approved support workflow mapping may vary. Operational confidence depends on inventory, endpoint role mapping, and tuning of approved deployment paths.

·        Full-Telemetry TCR Justification: Under stronger telemetry conditions, confidence improves when SentinelOne alerts are enriched with software inventory, approved RMM tenant data, proxy telemetry, identity context, helpdesk records, asset criticality, and endpoint process-to-network context.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

·        T1566.002 — Spearphishing Link.

Rule Disposition

·        Include as one primary SentinelOne endpoint rule.

·        Use as the first SentinelOne detection layer for unauthorized RMM introduction.

·        Do not treat this rule as standalone proof of full compromise without persistence, network, identity, or post-compromise enrichment.

Detection Code

(
    ProcessName ContainsCIS "anydesk"
    OR ProcessName ContainsCIS "teamviewer"
    OR ProcessName ContainsCIS "screenconnect"
    OR ProcessName ContainsCIS "connectwise"
    OR ProcessName ContainsCIS "simplehelp"
    OR ProcessName ContainsCIS "splashtop"
    OR ProcessName ContainsCIS "atera"
    OR ProcessName ContainsCIS "ninja"
    OR ProcessName ContainsCIS "syncro"
    OR ProcessName ContainsCIS "zoho"
    OR ProcessName ContainsCIS "bomgar"
    OR ProcessName ContainsCIS "beyondtrust"
    OR ProcessName ContainsCIS "logmein"
    OR ProcessName ContainsCIS "gotoassist"
    OR ProcessName ContainsCIS "ultraviewer"
    OR ProcessName ContainsCIS "netsupport"
    OR ProcessCmd ContainsCIS "anydesk"
    OR ProcessCmd ContainsCIS "teamviewer"
    OR ProcessCmd ContainsCIS "screenconnect"
    OR ProcessCmd ContainsCIS "connectwise"
    OR ProcessCmd ContainsCIS "simplehelp"
    OR ProcessCmd ContainsCIS "splashtop"
    OR ProcessCmd ContainsCIS "atera"
    OR ProcessCmd ContainsCIS "ninjaone"
    OR ProcessCmd ContainsCIS "syncromsp"
    OR ProcessCmd ContainsCIS "zohoassist"
    OR ProcessCmd ContainsCIS "beyondtrust"
    OR ProcessCmd ContainsCIS "bomgar"
    OR ProcessCmd ContainsCIS "logmein"
    OR ProcessCmd ContainsCIS "gotoassist"
    OR ProcessCmd ContainsCIS "ultraviewer"
    OR ProcessCmd ContainsCIS "netsupport"
)
AND
(
    ParentProcessName ContainsCIS "chrome"
    OR ParentProcessName ContainsCIS "msedge"
    OR ParentProcessName ContainsCIS "firefox"
    OR ParentProcessName ContainsCIS "iexplore"
    OR ParentProcessName ContainsCIS "outlook"
    OR ParentProcessName ContainsCIS "winword"
    OR ParentProcessName ContainsCIS "excel"
    OR ParentProcessName ContainsCIS "powerpnt"
    OR ParentProcessName ContainsCIS "acrord"
    OR ParentProcessName ContainsCIS "teams"
    OR ParentProcessName ContainsCIS "slack"
    OR ParentProcessName ContainsCIS "zoom"
    OR ParentProcessName ContainsCIS "7z"
    OR ParentProcessName ContainsCIS "winrar"
    OR ParentProcessName ContainsCIS "powershell"
    OR ParentProcessName ContainsCIS "cmd"
    OR ParentProcessName ContainsCIS "wscript"
    OR ParentProcessName ContainsCIS "cscript"
    OR ParentProcessName ContainsCIS "mshta"
    OR ParentProcessName ContainsCIS "rundll32"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Downloads\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Desktop\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\AppData\\\\Local\\\\Temp\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\INetCache\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\AppData\\\\Local\\\\Packages\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\OneDrive\\\\"
    OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Dropbox\\\\"
    OR ProcessImagePath RegExp "\\\\ProgramData\\\\Temp\\\\"
)

SentinelOne Rule 2

Unauthorized RMM Persistence or Unattended Access Configuration

Detection Objective

Detect RMM-associated service creation, auto-start configuration, scheduled execution, unattended-access enablement, agent registration, or persistent installation behavior outside approved administrative deployment workflows.

This rule is intended to identify adversary efforts to preserve post-compromise control through persistent RMM agents, auto-start behavior, unattended access, reconnect capability, agent enrollment, service registration, or remote-control configuration changes.

Behavioral Rationale

RMM abuse becomes materially more dangerous when an attacker converts a temporary support session or staged installer into durable unattended access. Persistence may be created through services, scheduled tasks, registry autoruns, startup entries, remote-control configuration files, service installation commands, agent enrollment actions, or silent installation parameters.

This tightened rule separates high-confidence persistence behavior from broader installation terms. High-confidence persistence patterns can alert when paired with RMM indicators. Broader terms such as install, service, agent, enroll, or register require additional suspicious context such as suspicious parentage, user-controlled path execution, or restricted endpoint scope. This reduces noise in RMM-heavy environments while preserving the ability to catch adversary-driven persistent deployment.

Primary Telemetry Source

·        SentinelOne process execution, command-line, file path, and endpoint persistence-adjacent telemetry.

Required SentinelOne Data Elements

·        Process name or equivalent image name field.

·        Process command line.

·        Process image path.

·        Parent process name.

·        User or initiating account.

·        Endpoint hostname or agent name.

·        Process start time.

·        File path or file name where available.

·        Site, account, group, or endpoint scope.

·        Optional service, registry, scheduled task, or persistence fields if available in the tenant.

Rule Logic Summary

·        Identify RMM, remote support, remote-control, or unattended-access indicators in process name, command line, image path, or file path.

·        Alert on explicit persistence behavior such as service creation, service configuration, scheduled task creation, registry autorun modification, auto-start configuration, silent installation, unattended access, reconnect behavior, or agent enrollment.

·        For broad installation terms, require suspicious parent process, user-controlled execution path, restricted endpoint scope, or non-standard deployment context.

·        Exclude approved endpoint management and software deployment workflows through customer-specific scoping.

·        Prioritize persistence creation on high-value or restricted systems.

System-Native Rule Format

SentinelOne Deep Visibility / STAR-ready query logic.

Engineering Implementation Instructions

·        Validate whether the customer’s SentinelOne tenant captures the required command-line, image path, file path, service, registry, and scheduled task fields before production deployment.

·        Build approved persistence baselines for sanctioned RMM agents, including service names, install paths, tenant identifiers, management servers, deployment mechanisms, and authorized endpoint populations.

·        Exclude approved software deployment tools, endpoint management agents, and golden-image deployment processes only when they match approved deployment paths and support workflows.

·        Do not suppress persistence events for an approved RMM product when the persistence is created by an unusual user, suspicious parent process, user-writable path, or non-standard deployment channel.

·        Prioritize alerts where persistence appears on domain controllers, identity systems, backup servers, privileged access workstations, executive endpoints, security tooling, cloud management systems, and regulated-data systems.

·        Enrich alerts with software inventory, approved RMM tenant data, service inventory, endpoint role, helpdesk records, change-control data, and identity context.

·        Treat this rule as a high-priority persistence signal. Incident confirmation should evaluate whether the persistence was authorized, whether the tenant is approved, and whether post-compromise behavior followed.

·        Add customer-specific service, registry, and scheduled task fields only after validating they are available and consistently populated in the tenant.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to restricted endpoint groups where RMM persistence is prohibited. Required customer data includes restricted endpoint groups, prohibited host classes, approved RMM products, and known approved deployment tools.

·        Tier 2 deployment: Add approved service names, install paths, deployment tools, helpdesk workflows, and software inventory. Use this tier for production detection of unauthorized RMM persistence.

·        Tier 3 deployment: Add endpoint role mapping, identity context, approved tenant identifiers, approved management servers, service inventory, asset criticality, and optional service or registry telemetry. Use this tier to prioritize persistence on sensitive infrastructure and validate tenant or deployment mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management records, change-control data, service-provider context, and SIEM enrichment. Use this tier to validate whether persistence was created through an approved workflow or represents unauthorized unattended access.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require persistence or unattended-access behavior tied to RMM tooling and approved-scope deviation.

·        If the customer lacks service inventory, approved RMM deployment paths, or endpoint role mapping, use this rule in pilot mode until baseline quality supports production deployment.

Expected False Positives

·        Approved RMM agent installation or update creating services or auto-start behavior.

·        Helpdesk deployment of unattended-access tools during legitimate support.

·        MSP deployment through approved but undocumented workflows.

·        Endpoint management reinstalling or repairing a sanctioned RMM agent.

·        Vendor support sessions creating temporary persistence for troubleshooting.

·        Legacy RMM deployment mechanisms not represented in the approved baseline.

False Positive Reduction

·        Add approved RMM services, install paths, tenant identifiers, and deployment mechanisms to the baseline.

·        Exclude approved endpoint management tools only when the deployment path and endpoint population match policy.

·        Use endpoint role and asset criticality to prioritize restricted systems.

·        Validate against change-control records, helpdesk tickets, RMM platform logs, and software inventory.

·        Keep alerts where approved RMM persistence is created by unexpected users, suspicious parent processes, or user-writable paths.

·        Treat broad installation terms as lower-confidence unless they occur with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Known Limitations

·        Some legitimate RMM tools create services, auto-start behavior, and unattended-access settings during approved installation.

·        Service, registry, scheduled task, and persistence-specific fields may vary by SentinelOne tenant and telemetry configuration.

·        The rule may miss RMM tools that use uncommon persistence mechanisms not reflected in process command lines or file paths.

·        The rule may miss renamed tools if no recognizable RMM string appears in the process, path, command line, file metadata, or customer-specific selector list.

·        The rule does not independently prove outbound control-channel communication or post-compromise activity.

·        Production deployment requires customer-specific persistence baselines to avoid noise.

DRI Score

·        DRI: 8.7

·        Rating: Primary rule

·        Justification: The rule is strongly anchored to persistence and unattended-access behavior, which is central to RMM-enabled post-compromise control. The tightened logic improves resilience by separating explicit persistence behavior from broader installation terms and requiring additional suspicious context for lower-specificity patterns. Its score is limited by product-string dependence, variable persistence telemetry availability, and the need for accurate approved RMM baselines.

TCR Score

·        Operational TCR: 8.0

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: SentinelOne commonly provides process, command-line, and file path telemetry, but registry, scheduled task, and service-specific visibility may vary by deployment and configuration. Operational confidence depends on command-line completeness, persistence telemetry depth, and approved RMM baseline quality.

·        Full-Telemetry TCR Justification: Confidence improves when SentinelOne telemetry is enriched with service inventory, scheduled task data, registry changes, software inventory, approved RMM tenant context, endpoint role mapping, RMM platform logs, and change-control records.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1060 — Registry Run Keys / Startup Folder.

·        T1136 — Create Account.

Rule Disposition

·        Include as one primary SentinelOne endpoint rule.

·        Use as the SentinelOne persistence-focused detection for unauthorized RMM control preservation.

·        Do not suppress solely because the RMM product is approved elsewhere in the enterprise.

·        Treat optional service, registry, and scheduled task fields as customer-validated enhancements rather than universal requirements.

·        Treat broad install, service, agent, enroll, and register terms as production-safe only when combined with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Detection Code

(
    ProcessName ContainsCIS "anydesk"
    OR ProcessName ContainsCIS "teamviewer"
    OR ProcessName ContainsCIS "screenconnect"
    OR ProcessName ContainsCIS "connectwise"
    OR ProcessName ContainsCIS "simplehelp"
    OR ProcessName ContainsCIS "splashtop"
    OR ProcessName ContainsCIS "atera"
    OR ProcessName ContainsCIS "ninja"
    OR ProcessName ContainsCIS "syncro"
    OR ProcessName ContainsCIS "zoho"
    OR ProcessName ContainsCIS "bomgar"
    OR ProcessName ContainsCIS "beyondtrust"
    OR ProcessName ContainsCIS "logmein"
    OR ProcessName ContainsCIS "gotoassist"
    OR ProcessName ContainsCIS "ultraviewer"
    OR ProcessName ContainsCIS "netsupport"
    OR ProcessCmd ContainsCIS "anydesk"
    OR ProcessCmd ContainsCIS "teamviewer"
    OR ProcessCmd ContainsCIS "screenconnect"
    OR ProcessCmd ContainsCIS "connectwise"
    OR ProcessCmd ContainsCIS "simplehelp"
    OR ProcessCmd ContainsCIS "splashtop"
    OR ProcessCmd ContainsCIS "atera"
    OR ProcessCmd ContainsCIS "ninjaone"
    OR ProcessCmd ContainsCIS "syncromsp"
    OR ProcessCmd ContainsCIS "zohoassist"
    OR ProcessCmd ContainsCIS "beyondtrust"
    OR ProcessCmd ContainsCIS "bomgar"
    OR ProcessCmd ContainsCIS "logmein"
    OR ProcessCmd ContainsCIS "gotoassist"
    OR ProcessCmd ContainsCIS "ultraviewer"
    OR ProcessCmd ContainsCIS "netsupport"
    OR ProcessImagePath ContainsCIS "anydesk"
    OR ProcessImagePath ContainsCIS "teamviewer"
    OR ProcessImagePath ContainsCIS "screenconnect"
    OR ProcessImagePath ContainsCIS "connectwise"
    OR ProcessImagePath ContainsCIS "simplehelp"
    OR ProcessImagePath ContainsCIS "splashtop"
    OR ProcessImagePath ContainsCIS "atera"
    OR ProcessImagePath ContainsCIS "ninja"
    OR ProcessImagePath ContainsCIS "syncro"
    OR ProcessImagePath ContainsCIS "zoho"
    OR ProcessImagePath ContainsCIS "beyondtrust"
    OR ProcessImagePath ContainsCIS "bomgar"
    OR ProcessImagePath ContainsCIS "logmein"
    OR ProcessImagePath ContainsCIS "gotoassist"
    OR ProcessImagePath ContainsCIS "ultraviewer"
    OR ProcessImagePath ContainsCIS "netsupport"
)
AND
(
    (
        ProcessCmd RegExp "(?i)\\bsc\\s+create\\b"
        OR ProcessCmd RegExp "(?i)\\bsc\\s+config\\b"
        OR ProcessCmd RegExp "(?i)\\bschtasks\\b.*\\b/create\\b"
        OR ProcessCmd RegExp "(?i)\\breg\\s+add\\b.*\\\\CurrentVersion\\\\Run"
        OR ProcessCmd ContainsCIS "start= auto"
        OR ProcessCmd ContainsCIS "autostart"
        OR ProcessCmd ContainsCIS "auto-start"
        OR ProcessCmd ContainsCIS "unattended"
        OR ProcessCmd ContainsCIS "silent"
        OR ProcessCmd ContainsCIS "quiet"
        OR ProcessCmd ContainsCIS "reconnect"
        OR ProcessCmd ContainsCIS "persist"
    )
    OR
    (
        (
            ProcessCmd ContainsCIS "install"
            OR ProcessCmd ContainsCIS "service"
            OR ProcessCmd ContainsCIS "agent"
            OR ProcessCmd ContainsCIS "enroll"
            OR ProcessCmd ContainsCIS "register"
        )
        AND
        (
            ParentProcessName ContainsCIS "chrome"
            OR ParentProcessName ContainsCIS "msedge"
            OR ParentProcessName ContainsCIS "firefox"
            OR ParentProcessName ContainsCIS "iexplore"
            OR ParentProcessName ContainsCIS "outlook"
            OR ParentProcessName ContainsCIS "teams"
            OR ParentProcessName ContainsCIS "slack"
            OR ParentProcessName ContainsCIS "zoom"
            OR ParentProcessName ContainsCIS "powershell"
            OR ParentProcessName ContainsCIS "cmd"
            OR ParentProcessName ContainsCIS "wscript"
            OR ParentProcessName ContainsCIS "cscript"
            OR ParentProcessName ContainsCIS "mshta"
            OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Downloads\\\\"
            OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Desktop\\\\"
            OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\AppData\\\\Local\\\\Temp\\\\"
            OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\OneDrive\\\\"
            OR ProcessImagePath RegExp "\\\\Users\\\\[^\\\\]+\\\\Dropbox\\\\"
            OR ProcessImagePath RegExp "\\\\ProgramData\\\\Temp\\\\"
        )
    )
)
AND NOT
(
    ParentProcessName ContainsCIS "sccm"
    OR ParentProcessName ContainsCIS "ccmexec"
    OR ParentProcessName ContainsCIS "intune"
    OR ParentProcessName ContainsCIS "managementextension"
    OR ParentProcessName ContainsCIS "jamf"
    OR ParentProcessName ContainsCIS "kace"
    OR ParentProcessName ContainsCIS "tanium"
    OR ParentProcessName ContainsCIS "bigfix"
)

SentinelOne Rule 3

RMM Tool Launching High-Risk Shell, Credential, Lateral Movement, or Tampering Activity

Detection Objective

Detect RMM, remote support, or remote-control tooling spawning high-risk command shells, scripting engines, credential access behavior, lateral movement utilities, file staging tools, backup interference, or defense-tampering commands.

This rule is intended to identify interactive attacker activity conducted through an RMM session after remote-control access has been established.

Behavioral Rationale

A legitimate support session may involve remote interaction, but RMM-launched credential access commands, lateral movement utilities, backup interference, security-tool tampering, file staging, and high-risk remote administration behavior are materially stronger post-compromise signals than basic diagnostic commands. Adversaries commonly use RMM tools as an interactive control channel and then launch native operating system utilities to enumerate the environment, access credentials, move laterally, disable defenses, stage files, or prepare ransomware activity.

This rule does not alert on every RMM-spawned shell or basic troubleshooting command. It focuses on higher-risk child process behavior and command-line patterns, with deployment instructions requiring stronger severity for high-value systems and restricted endpoint populations.

Primary Telemetry Source

·        SentinelOne endpoint process lineage and behavioral telemetry.

Required SentinelOne Data Elements

·        Parent process name.

·        Process name or equivalent child image name.

·        Process command line.

·        Process image path.

·        User or initiating account.

·        Endpoint hostname or agent name.

·        Process start time.

·        Site, account, group, or endpoint scope.

·        Process group, storyline, or causality context where available.

·        Endpoint network context where available.

Rule Logic Summary

·        Identify RMM or remote support processes acting as the parent process.

·        Detect child execution or command-line activity associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or high-risk administrative activity.

·        Avoid alerting on low-risk diagnostic commands alone unless deployed to a prohibited endpoint population with strict policy.

·        Prioritize alerts from high-value systems, non-administrative users, unusual service accounts, and endpoints without approved RMM use.

System-Native Rule Format

SentinelOne Deep Visibility / STAR-ready query logic.

Engineering Implementation Instructions

·        Validate customer-specific RMM process names and add them to the parent process selector. Some RMM products use multiple service, agent, helper, and support process names.

·        Do not rely only on default product process names. Include customer-approved agent names, private management agent names, and known support client names where applicable.

·        Tune carefully for legitimate helpdesk workflows that use command shells for troubleshooting, but do not suppress high-risk child process categories from high-value or prohibited systems.

·        Prioritize alerts involving credential access, lateral movement, security-tool tampering, backup interference, archive staging, remote execution, or ransomware preparation.

·        Enrich alerts with SentinelOne storyline context, user role, endpoint role, approved support ticket, support-session metadata, identity logs, and network telemetry.

·        Treat this rule as a strong post-compromise signal when RMM-spawned activity occurs outside approved support workflows or on systems where interactive remote administration is prohibited.

·        Validate the query in hunting mode before enabling automated response actions because some helpdesk teams may legitimately run administrative commands during troubleshooting.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy in alert-only mode for restricted endpoint populations and high-value systems. Required customer data includes restricted endpoint groups, approved RMM products, and approved support teams.

·        Tier 2 deployment: Add approved helpdesk workflows, allowed troubleshooting commands, support-ticket context, and endpoint role mapping. Use this tier for production alerting on RMM-launched high-risk child process behavior outside approved support activity.

·        Tier 3 deployment: Add identity context, asset criticality, software inventory, RMM tenant identifiers, endpoint network telemetry, and SentinelOne storyline enrichment. Use this tier to separate legitimate troubleshooting from suspicious post-compromise activity.

·        Tier 4 deployment: Add RMM platform audit logs, service-provider context, change-control data, SIEM correlation, and post-compromise enrichment. Use this tier for mature enterprise deployment where RMM-launched activity can be tied to session ownership, approved tickets, and downstream impact.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM-associated parent process activity plus high-risk child execution or command behavior.

·        If the customer lacks approved support workflow documentation, deploy in pilot mode to baseline legitimate helpdesk command usage before enabling aggressive response actions.

Expected False Positives

·        Helpdesk technicians running administrative commands during legitimate support.

·        IT administrators using RMM to perform system repair or diagnostic work.

·        Approved vendor support sessions collecting system diagnostics or logs.

·        Endpoint management or remote support tools running health checks.

·        Security team testing RMM-launched command execution.

·        Legacy support workflows that allow interactive shell access.

False Positive Reduction

·        Baseline approved helpdesk troubleshooting commands and support workflows.

·        Require high-risk child process categories rather than alerting on all RMM child processes.

·        Prioritize credential access, lateral movement, security tampering, backup interference, archive staging, and file-transfer behavior over basic diagnostics.

·        Correlate with support tickets, user role, endpoint role, RMM platform session logs, and identity events.

·        Maintain higher severity for restricted systems even if similar behavior is common on helpdesk-managed endpoints.

Known Limitations

·        Some RMM tools legitimately spawn shells or scripts during authorized troubleshooting.

·        Parent-child process relationships may vary depending on how the RMM tool launches commands.

·        Some remote command activity may appear under a service process or helper process rather than the visible RMM client name.

·        The rule may miss post-compromise activity if the adversary pivots away from the RMM process lineage before executing commands.

·        The rule depends on customer-specific RMM process name coverage and SentinelOne process lineage fidelity.

·        Automated response should be carefully scoped to avoid interrupting legitimate emergency support activity.

DRI Score

·        DRI: 9.0

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it detects high-risk post-compromise actions launched through RMM control rather than the presence of RMM software alone. It is resilient across multiple RMM products because the core behavior is remote-control tooling spawning credential, lateral movement, defense evasion, backup interference, staging, or high-risk administration utilities. Its score is limited mainly by dependency on accurate parent-child telemetry and customer-specific RMM process name coverage.

TCR Score

·        Operational TCR: 8.3

·        Full-Telemetry TCR: 9.0

·        Operational TCR Justification: In normal SentinelOne deployments, process lineage and command-line telemetry are commonly available, making this rule operationally strong. Confidence may be reduced where RMM process naming varies, where helper processes obscure lineage, or where support workflows are poorly documented.

·        Full-Telemetry TCR Justification: Confidence improves when SentinelOne storyline context, support-session metadata, identity telemetry, endpoint role mapping, RMM platform logs, software inventory, and SIEM enrichment are available.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1018 — Remote System Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1105 — Ingress Tool Transfer.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one primary SentinelOne endpoint rule.

·        Treat as the strongest SentinelOne post-compromise control-channel rule in this system set.

·        Use higher severity where the child process indicates credential access, lateral movement, defense evasion, backup interference, data staging, or ransomware preparation.

·        Do not configure the rule to alert on low-risk diagnostic commands alone unless scoped to prohibited endpoint populations.

Detection Code

(
    ParentProcessName ContainsCIS "anydesk"
    OR ParentProcessName ContainsCIS "teamviewer"
    OR ParentProcessName ContainsCIS "screenconnect"
    OR ParentProcessName ContainsCIS "connectwise"
    OR ParentProcessName ContainsCIS "simplehelp"
    OR ParentProcessName ContainsCIS "splashtop"
    OR ParentProcessName ContainsCIS "atera"
    OR ParentProcessName ContainsCIS "ninja"
    OR ParentProcessName ContainsCIS "syncro"
    OR ParentProcessName ContainsCIS "zoho"
    OR ParentProcessName ContainsCIS "bomgar"
    OR ParentProcessName ContainsCIS "beyondtrust"
    OR ParentProcessName ContainsCIS "logmein"
    OR ParentProcessName ContainsCIS "gotoassist"
    OR ParentProcessName ContainsCIS "ultraviewer"
    OR ParentProcessName ContainsCIS "netsupport"
)
AND
(
    ProcessCmd RegExp "(?i)\\b(net\\s+user|net\\s+localgroup|net\\s+group|nltest|dsquery|setspn|quser|qwinsta)\\b"
    OR ProcessCmd RegExp "(?i)\\b(psexec|wmic|winrs|remote\\s+service|sc\\s+\\\\\\\\|schtasks\\s+/s)\\b"
    OR ProcessCmd RegExp "(?i)\\b(rundll32|regsvr32|mshta|wscript|cscript)\\b.*(http|https|script|javascript|vbscript)"
    OR ProcessCmd RegExp "(?i)\\b(vssadmin\\s+delete|wbadmin\\s+delete|bcdedit\\s+/set|reagentc\\s+/disable)\\b"
    OR ProcessCmd RegExp "(?i)\\b(wevtutil\\s+cl|auditpol\\s+/set|sc\\s+stop|taskkill\\s+/f)\\b"
    OR ProcessCmd RegExp "(?i)\\b(rclone|mega|winscp|7z|rar)\\b.*(copy|sync|archive|zip|password|finance|backup|users|share)"
    OR ProcessCmd RegExp "(?i)\\b(procdump|comsvcs\\.dll|lsass|sekurlsa|sam|ntds\\.dit)\\b"
    OR ProcessName ContainsCIS "psexec"
    OR ProcessName ContainsCIS "wmic"
    OR ProcessName ContainsCIS "rclone"
    OR ProcessName ContainsCIS "procdump"
    OR ProcessName ContainsCIS "vssadmin"
    OR ProcessName ContainsCIS "wbadmin"
    OR ProcessName ContainsCIS "wevtutil"
    OR ProcessName ContainsCIS "bcdedit"
)

SentinelOne Final Disposition

SentinelOne receives 3 audit-passing rules for this report. The final SentinelOne rule set covers unauthorized RMM introduction, unauthorized RMM persistence or unattended access, and RMM-launched high-risk post-compromise activity. Additional SentinelOne concepts were not promoted because the three selected rules provide the strongest behavior coverage without forcing redundant or lower-value detections.

Elastic

Detection Viability Assessment

Elastic has high detection viability for this report when Elastic Defend, Elastic Agent, Windows event integrations, Sysmon, DNS, proxy, identity, and endpoint inventory telemetry are normalized into Elastic Common Schema-compatible fields. Elastic is well suited for this report because RMM abuse produces endpoint-observable activity that can be expressed through EQL and KQL-style detection logic, especially around process execution, parent-child relationships, suspicious paths, persistence behavior, and post-RMM command execution.

Elastic should be treated as a primary endpoint and SIEM detection layer for this report. The strongest Elastic rules are behavior-driven and focus on unauthorized RMM introduction, RMM-associated persistence or unattended-access behavior, and RMM activity followed by high-risk post-compromise command behavior. Product names are used as scoped selectors, but detection strength comes from execution context, process lineage, file path, user context, endpoint role, persistence behavior, and sequence-based follow-on activity.

The detection code below is written as Elastic EQL detection-rule logic using Elastic Common Schema-style fields. Field names, index patterns, event categories, host identifiers, user fields, endpoint integration coverage, and exception lists must be validated in the customer environment before production deployment.

Elastic Rule 1

Unauthorized RMM Execution from Suspicious Parent Process or User-Controlled Path

Detection Objective

Detect known RMM, remote support, or remote-control tooling executing from suspicious parent processes or user-controlled staging paths inconsistent with approved software deployment.

This rule is intended to identify RMM introduction through phishing, fake support lures, browser downloads, collaboration-tool downloads, archive extraction, user-driven execution, command-line staging, or attacker placement rather than sanctioned endpoint management workflows.

Behavioral Rationale

RMM abuse frequently begins when a user is induced to download and execute a legitimate remote support tool, or when an adversary stages a legitimate RMM agent from a user-writable path after initial access. Because the tool may be signed and vendor-legitimate, the stronger signal is not the tool name alone. The stronger signal is the mismatch between the tool’s administrative function and the execution context, especially when the parent process is a browser, email client, document reader, collaboration tool, archive utility, shell, scripting engine, or remote command utility.

This rule detects unauthorized RMM introduction by combining RMM process, executable path, or command-line indicators with suspicious parentage or suspicious execution location. It is not intended to alert on approved RMM deployment from sanctioned endpoint management systems, software distribution tools, administrative management servers, or approved helpdesk automation.

Primary Telemetry Source

·        Elastic endpoint process telemetry from Elastic Defend, Elastic Agent, Sysmon, Windows event logs, or equivalent ECS-normalized endpoint sources.

Required Elastic Data Elements

·        event.category.

·        event.type.

·        host.name.

·        host.id where available.

·        user.name.

·        process.name.

·        process.executable.

·        process.command_line.

·        process.parent.name.

·        process.parent.executable where available.

·        process.hash.sha256 or equivalent hash where available.

·        process.code_signature.subject_name where available.

·        Endpoint role or asset category through enrichment.

·        Approved RMM inventory through exception list or lookup enrichment.

·        Restricted endpoint population through exception list, asset metadata, or host tagging.

Rule Logic Summary

·        Identify execution of RMM, remote support, remote-control, unattended-access, or support-client tooling.

·        Require suspicious parent process context or execution from user-controlled paths.

·        Exclude approved endpoint management, software deployment, helpdesk, or administrative management processes through customer-specific exceptions.

·        Treat the alert as higher priority when the endpoint has no approved RMM baseline, the user is not part of an approved support workflow, or the host belongs to a restricted endpoint population.

System-Native Rule Format

Elastic EQL detection rule.

Engineering Implementation Instructions

·        Validate endpoint data source coverage before production deployment. The rule requires process creation telemetry with parent process, command line, executable path, host, and user fields.

·        Validate Elastic Common Schema field mappings for process.name, process.command_line, process.executable, process.parent.name, host.name, host.id, and user.name.

·        Build an approved RMM inventory before production deployment. The inventory should include approved RMM vendors, approved executable names, approved installation paths, approved tenants, approved management servers, approved deployment tools, and approved support workflows.

·        Use Elastic exception lists or environment-specific enrichment to exclude approved deployment workflows only when tool, path, parent process, endpoint role, user, and support workflow match the approved baseline.

·        Do not suppress an approved RMM product globally. Approved RMM products can still be abused through user-driven installation, attacker-generated support sessions, tenant mismatch, or compromised support workflows.

·        Tune by endpoint role, user role, host group, site, deployment method, and approved support workflow rather than suppressing the rule across all endpoints.

·        Prioritize alerts from ordinary user workstations, executive endpoints, privileged access workstations, domain controllers, identity systems, backup servers, security tooling, regulated-data systems, and cloud-hosted workloads.

·        Enrich alerts with software inventory, DNS or proxy telemetry, identity telemetry, helpdesk records, endpoint management logs, and approved RMM tenant data.

·        Treat the alert as an unauthorized RMM introduction signal, not a complete compromise determination unless supported by persistence, outbound control traffic, identity misuse, or post-compromise behavior.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to endpoints where RMM execution is prohibited or tightly restricted. Required customer data includes restricted endpoint groups, approved RMM vendor list, approved deployment tools, and approved helpdesk accounts.

·        Tier 2 deployment: Add approved installation paths, approved parent processes, approved support workflows, endpoint role mapping, software inventory, and helpdesk ticket context. Use this tier for production alerting on suspicious RMM execution from user-controlled paths or suspicious parent processes.

·        Tier 3 deployment: Add asset criticality, identity context, proxy or DNS enrichment, endpoint process-to-network visibility, approved tenant identifiers, and approved management servers. Use this tier to prioritize high-risk endpoints and validate tenant or management scope mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management logs, change-control data, service-provider context, and SIEM correlation with identity and network telemetry. Use this tier for mature enterprise deployment where Elastic alerts can be evaluated against approved deployment paths and follow-on behavior.

·        Tiering changes deployment scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM execution plus suspicious parentage, suspicious path, approved-scope deviation, or prohibited-policy violation.

·        If the customer lacks approved RMM inventory and endpoint role mapping, keep the rule in pilot mode for baseline development before production enforcement.

Expected False Positives

·        Helpdesk-guided temporary remote support downloads.

·        Software vendor support sessions initiated by users.

·        IT testing of portable RMM tools from downloads or temporary directories.

·        Approved emergency break-fix support workflows.

·        Legacy remote support practices not yet represented in the approved RMM inventory.

·        Endpoint management activity mapped to unexpected parent processes.

False Positive Reduction

·        Require suspicious parent process, suspicious path, restricted endpoint scope, or approved-baseline deviation.

·        Use Elastic exception lists tied to approved RMM inventory rather than broad product suppression.

·        Validate alerts against helpdesk tickets, software inventory, endpoint role, approved tenant, user role, and deployment method.

·        Preserve alerts from high-value or restricted systems even if similar behavior is allowed on helpdesk-managed endpoints.

·        Review new exceptions periodically to avoid turning approved RMM tooling into a blanket suppression.

Known Limitations

·        Renamed RMM binaries may evade product-name selectors unless command line, path, signer, tenant, or behavior still matches.

·        Field availability depends on endpoint integration, ECS normalization, and data source quality.

·        User-driven legitimate support sessions may resemble suspicious introduction behavior.

·        The rule does not prove persistence, outbound control-channel activity, tenant mismatch, or post-compromise behavior by itself.

·        Production deployment requires customer-specific approved RMM inventory and endpoint population mapping.

DRI Score

·        DRI: 8.7

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it detects RMM execution in suspicious introduction contexts rather than product presence alone. It is resilient across multiple RMM products and delivery paths because it combines tool indicators with parent process, execution path, restricted endpoint scope, and baseline deviation. Its score is limited by dependence on recognizable RMM indicators and customer baseline quality.

TCR Score

·        Operational TCR: 8.0

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: In normal Elastic deployments, confidence depends on endpoint process telemetry quality, ECS normalization, parent process availability, command-line visibility, and approved RMM inventory completeness. Many environments can support this rule, but field consistency varies.

·        Full-Telemetry TCR Justification: Confidence improves when endpoint process telemetry is enriched with software inventory, endpoint role, approved tenant identifiers, identity telemetry, proxy or DNS telemetry, helpdesk context, asset criticality, and endpoint process-to-network context.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

·        T1566.002 — Spearphishing Link.

Rule Disposition

·        Include as one primary Elastic endpoint rule.

·        Use as the Elastic introduction-stage detection for unauthorized RMM execution.

·        Do not treat this rule as standalone proof of full compromise without persistence, network, identity, or post-compromise enrichment.

Detection Code

process where event.category == "process" and event.type in ("start", "process_started") and
(
process.name : (
    "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
    "*simplehelp*", "*splashtop*", "*atera*", "*ninja*", "*syncro*",
    "*zoho*", "*bomgar*", "*beyondtrust*", "*logmein*", "*gotoassist*",
    "*ultraviewer*", "*netsupport*"
  )
  or process.command_line : (
    "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
    "*simplehelp*", "*splashtop*", "*atera*", "*ninjaone*", "*syncromsp*",
    "*zohoassist*", "*beyondtrust*", "*bomgar*", "*logmein*", "*gotoassist*",
    "*ultraviewer*", "*netsupport*"
  )
)
and
(
process.parent.name : (
    "chrome.exe", "msedge.exe", "firefox.exe", "iexplore.exe",
    "outlook.exe", "winword.exe", "excel.exe", "powerpnt.exe",
    "acrord32.exe", "teams.exe", "slack.exe", "zoom.exe",
    "7z.exe", "winrar.exe", "powershell.exe", "pwsh.exe",
    "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe"
  )
  or process.executable : (
    "C:\\Users\\*\\Downloads\\*",
    "C:\\Users\\*\\Desktop\\*",
    "C:\\Users\\*\\AppData\\Local\\Temp\\*",
    "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\*",
    "C:\\Users\\*\\AppData\\Local\\Packages\\*",
    "C:\\Users\\*\\OneDrive\\*",
    "C:\\Users\\*\\Dropbox\\*",
    "C:\\ProgramData\\Temp\\*"
  )
)

Elastic Rule 2

Unauthorized RMM Persistence or Unattended Access Configuration

Detection Objective

Detect RMM-associated service creation, auto-start configuration, scheduled execution, unattended-access enablement, agent registration, or persistent installation behavior outside approved administrative deployment workflows.

This rule is intended to identify adversary efforts to preserve post-compromise control through persistent RMM agents, auto-start behavior, unattended access, reconnect capability, agent enrollment, service registration, or remote-control configuration changes.

Behavioral Rationale

RMM abuse becomes materially more dangerous when an adversary converts a temporary support session or staged installer into durable remote-control access. Persistence may be created through services, scheduled tasks, registry autoruns, startup entries, remote-control configuration files, service installation commands, agent enrollment actions, or silent installation parameters.

This rule separates high-confidence persistence behavior from broader installation terms. High-confidence persistence patterns can alert when paired with RMM indicators. Broader terms such as install, service, agent, enroll, or register require additional suspicious context such as suspicious parentage, user-controlled path execution, restricted endpoint scope, or non-standard deployment context. This reduces noise in RMM-heavy environments while preserving the ability to catch adversary-driven persistent deployment.

Primary Telemetry Source

·        Elastic endpoint process telemetry, Windows service creation telemetry, scheduled task telemetry, registry telemetry, and software inventory where available.

Required Elastic Data Elements

·        event.category.

·        event.type.

·        host.name.

·        host.id where available.

·        user.name.

·        process.name.

·        process.command_line.

·        process.executable.

·        process.parent.name.

·        process.parent.executable where available.

·        Service creation fields where available.

·        Registry modification fields where available.

·        Scheduled task fields where available.

·        Endpoint role or asset category through enrichment.

·        Approved RMM persistence baseline through exception list or lookup enrichment.

·        Approved deployment mechanism context.

Rule Logic Summary

·        Identify RMM, remote support, remote-control, or unattended-access indicators in process name, command line, or executable path.

·        Alert on explicit persistence behavior such as service creation, service configuration, scheduled task creation, registry autorun modification, auto-start configuration, silent installation, unattended access, reconnect behavior, or agent enrollment.

·        For broad installation terms, require suspicious parent process, suspicious path, restricted endpoint population, or non-standard deployment context.

·        Exclude approved deployment workflows only when tool, endpoint, user, deployment path, and support workflow match approved inventory.

·        Prioritize persistence creation on high-value or restricted systems.

System-Native Rule Format

Elastic EQL detection rule.

Engineering Implementation Instructions

·        Validate endpoint data source coverage for process creation, command-line telemetry, service creation, scheduled task creation, registry changes, and software inventory before production deployment.

·        Validate ECS field mappings and confirm whether the customer has service, registry, and scheduled task fields available. If those fields are not consistently available, rely on process and command-line behavior first.

·        Build approved RMM persistence baselines covering service names, service paths, install paths, scheduled task names, tenant identifiers, management servers, endpoint populations, and approved deployment tools.

·        Do not suppress persistence events for approved RMM products when persistence is created by an unusual user, suspicious parent process, user-writable path, or non-standard deployment mechanism.

·        Use Elastic exception lists for approved deployment workflows only when endpoint, user, deployment path, parent process, and support workflow match policy.

·        Enrich alerts with endpoint role, asset criticality, software inventory, RMM platform logs, identity telemetry, helpdesk records, and change-control data.

·        Treat this rule as a high-priority persistence signal. Incident confirmation should determine whether the persistence was authorized, whether the tenant is approved, and whether post-compromise activity followed.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to restricted endpoint groups where RMM persistence is prohibited. Required customer data includes restricted endpoint groups, prohibited host classes, approved RMM tools, and approved deployment mechanisms.

·        Tier 2 deployment: Add approved service names, install paths, scheduled task names, deployment tools, helpdesk workflows, and software inventory. Use this tier for production detection of unauthorized RMM persistence.

·        Tier 3 deployment: Add endpoint role mapping, asset criticality, identity context, approved tenant identifiers, approved management servers, service inventory, and registry or scheduled task telemetry. Use this tier to prioritize persistence on sensitive infrastructure and validate tenant or deployment mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management records, change-control data, service-provider context, and SIEM correlation with network and identity telemetry. Use this tier to validate whether persistence was created through an approved workflow or represents unauthorized unattended access.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require persistence or unattended-access behavior tied to RMM tooling and approved-scope deviation.

·        If the customer lacks service inventory, approved RMM deployment paths, or endpoint role mapping, use this rule in pilot mode until baseline quality supports production deployment.

Expected False Positives

·        Approved RMM installation or update creating services, scheduled tasks, or auto-start behavior.

·        Helpdesk deployment of unattended-access tools during legitimate support.

·        MSP deployment through approved but undocumented workflows.

·        Endpoint management repairing or reinstalling a sanctioned RMM agent.

·        Vendor support sessions creating temporary persistence for troubleshooting.

·        Legacy RMM deployment mechanisms not represented in the approved baseline.

False Positive Reduction

·        Add approved RMM service names, scheduled task names, install paths, tenant identifiers, and deployment mechanisms to the baseline.

·        Exclude approved endpoint management tools only when endpoint, user, deployment path, and support workflow match policy.

·        Use endpoint role and asset criticality to prioritize restricted systems.

·        Validate against change-control records, helpdesk tickets, RMM platform logs, software inventory, and identity telemetry.

·        Keep alerts where approved RMM persistence is created by unexpected users, suspicious parent processes, user-writable paths, or non-standard deployment channels.

·        Treat broad install, service, agent, enroll, and register terms as lower-confidence unless paired with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Known Limitations

·        Legitimate RMM tools commonly create services, scheduled tasks, auto-start entries, and unattended-access settings.

·        Source coverage for service creation, registry, scheduled task, and software inventory events varies by environment.

·        Missing command-line or weak ECS normalization can reduce confidence.

·        Renamed tools may evade product-string selectors unless service path, signer, tenant, inventory, or behavior still matches.

·        The rule does not independently prove outbound control-channel communication or post-compromise activity.

·        Production deployment requires approved RMM persistence baselines to avoid noise.

DRI Score

·        DRI: 8.8

·        Rating: Primary rule

·        Justification: The rule is strongly anchored to persistence and unattended-access behavior, which is central to RMM-enabled post-compromise control. Its tightened logic improves resilience by separating explicit persistence behavior from broad installation terms and requiring additional suspicious context for lower-specificity patterns. Its score is limited by source coverage variation and the need for accurate approved RMM persistence baselines.

TCR Score

·        Operational TCR: 8.0

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: Operational confidence depends on endpoint process telemetry, service creation logs, scheduled task or registry telemetry, software inventory, and ECS normalization. Many environments will have partial coverage, so customer validation is required.

·        Full-Telemetry TCR Justification: Confidence improves with complete process command-line telemetry, Windows service creation events, scheduled task telemetry, registry telemetry, software inventory, endpoint role mapping, approved RMM baseline data, RMM platform logs, and change-control records.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1060 — Registry Run Keys / Startup Folder.

·        T1136 — Create Account.

Rule Disposition

·        Include as one primary Elastic persistence rule.

·        Use as the Elastic persistence-focused detection for unauthorized RMM control preservation.

·        Do not suppress solely because the RMM product is approved elsewhere in the enterprise.

·        Treat broad install, service, agent, enroll, and register terms as production-safe only when combined with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Detection Code

process where event.category == "process" and event.type in ("start", "process_started") and
(
process.name : (
    "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
    "*simplehelp*", "*splashtop*", "*atera*", "*ninja*", "*syncro*",
    "*zoho*", "*bomgar*", "*beyondtrust*", "*logmein*", "*gotoassist*",
    "*ultraviewer*", "*netsupport*"
  )
  or process.command_line : (
    "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
    "*simplehelp*", "*splashtop*", "*atera*", "*ninjaone*", "*syncromsp*",
    "*zohoassist*", "*beyondtrust*", "*bomgar*", "*logmein*", "*gotoassist*",
    "*ultraviewer*", "*netsupport*"
  )
  or process.executable : (
    "*\\AnyDesk\\*", "*\\TeamViewer\\*", "*\\ScreenConnect\\*",
    "*\\ConnectWise\\*", "*\\SimpleHelp\\*", "*\\Splashtop\\*",
    "*\\Atera\\*", "*\\Ninja\\*", "*\\Syncro\\*", "*\\Zoho\\*",
    "*\\BeyondTrust\\*", "*\\Bomgar\\*", "*\\LogMeIn\\*", "*\\GoToAssist\\*",
    "*\\UltraViewer\\*", "*\\NetSupport\\*"
  )
)
and
(
  (
    process.command_line : (
      "*sc create*", "*sc config*", "*schtasks* /create*",
      "*reg add*\\CurrentVersion\\Run*", "*start= auto*",
      "*autostart*", "*auto-start*", "*unattended*",
      "*silent*", "*quiet*", "*reconnect*", "*persist*"
    )
  )
  or
  (
    process.command_line : ("*install*", "*service*", "*agent*", "*enroll*", "*register*")
    and
    (
process.parent.name : (
        "chrome.exe", "msedge.exe", "firefox.exe", "iexplore.exe",
        "outlook.exe", "teams.exe", "slack.exe", "zoom.exe",
        "powershell.exe", "pwsh.exe", "cmd.exe",
        "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe"
      )
      or process.executable : (
        "C:\\Users\\*\\Downloads\\*",
        "C:\\Users\\*\\Desktop\\*",
        "C:\\Users\\*\\AppData\\Local\\Temp\\*",
        "C:\\Users\\*\\OneDrive\\*",
        "C:\\Users\\*\\Dropbox\\*",
        "C:\\ProgramData\\Temp\\*"
      )
    )
  )
)

Elastic Rule 3

RMM Tool Followed by High-Risk Post-Compromise Activity

Detection Objective

Detect RMM execution followed by high-risk command execution associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation on the same endpoint within a defined operational window.

This rule is intended to identify adversary use of RMM as an interactive post-compromise control channel, including cases where the follow-on activity runs under a different user, service account, SYSTEM context, helper process, or RMM service context.

Behavioral Rationale

A legitimate RMM session may involve interactive support, but RMM activity followed by high-risk commands is a stronger post-compromise signal. Elastic EQL is well suited for this detection because the rule can express a sequence of RMM activity followed by high-risk process execution on the same host within a bounded time window. This detects the intrusion sequence directly rather than depending on another detection rule.

This tightened version correlates by host instead of requiring the same user. That is intentional because RMM tools may launch commands through services, helper processes, SYSTEM, local administrator context, technician accounts, or service accounts. Requiring the same user.name could miss real RMM abuse where the initial RMM process and the follow-on command activity occur under different execution contexts.

This rule does not alert on every RMM-spawned diagnostic command. It focuses on higher-risk command patterns associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, and ransomware preparation.

Primary Telemetry Source

·        Elastic endpoint process telemetry from Elastic Defend, Elastic Agent, Sysmon, Windows event logs, or equivalent ECS-normalized endpoint sources.

Required Elastic Data Elements

·        event.category.

·        event.type.

·        host.name.

·        host.id.

·        user.name where available.

·        process.name.

·        process.command_line.

·        process.executable.

·        process.parent.name where available.

·        Process start time.

·        Endpoint role or asset category through enrichment.

·        Approved support workflow context where available.

·        RMM platform or support-session context where available.

Rule Logic Summary

·        Identify RMM process execution on an endpoint.

·        Identify high-risk post-compromise command activity on the same endpoint within a short operational window.

·        Correlate by host identity rather than requiring the same user identity.

·        Use user identity, process ancestry, support-session context, and RMM platform context as enrichment where available.

·        Prioritize credential access, lateral movement, defense evasion, backup interference, file staging, and ransomware-preparation patterns.

·        Exclude approved support workflows only when endpoint, user, command category, support ticket, and RMM session context are authorized.

·        Treat activity on restricted or high-value systems as higher severity.

System-Native Rule Format

Elastic EQL sequence detection rule.

Engineering Implementation Instructions

·        Validate endpoint process telemetry and ECS normalization before deployment.

·        Use host.id as the primary sequence key where available because RMM execution and follow-on commands may run under different user contexts.

·        If host.id is unavailable or inconsistently populated, validate whether host.name or another stable endpoint identifier can be safely substituted.

·        Use user.name as enrichment rather than a required sequence key unless the environment has validated that RMM execution and follow-on commands consistently retain the same user identity.

·        Tune the operational window based on customer telemetry volume and support workflows. A 60-minute window is a reasonable starting point for correlation, but production use should be validated against local support activity.

·        Build an approved support workflow exception set covering approved RMM tools, approved support users, approved troubleshooting commands, endpoint populations where interactive administration is allowed, and support-ticket context where available.

·        Do not suppress high-risk post-compromise commands solely because a support ticket exists. Validate command category, endpoint role, user, and session ownership.

·        Prioritize alerts involving credential access, remote execution, backup interference, defense tampering, file staging, administrative share activity, and ransomware preparation.

·        Use identity telemetry, helpdesk records, RMM platform logs, process ancestry, and endpoint role mapping to separate legitimate support from suspicious post-compromise behavior.

·        Avoid automated disruptive response until the customer validates expected RMM-launched administrative command patterns.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy in alert-only mode for restricted endpoint populations and high-value systems. Required customer data includes restricted host groups, approved RMM products, and approved support users.

·        Tier 2 deployment: Add approved troubleshooting commands, helpdesk ticket context, endpoint role mapping, and approved support workflows. Use this tier for production alerting on high-risk post-RMM command activity.

·        Tier 3 deployment: Add identity context, asset criticality, RMM tenant identifiers, endpoint network telemetry, process ancestry enrichment, and RMM platform logs. Use this tier to separate legitimate support from suspicious post-compromise activity.

·        Tier 4 deployment: Add service-provider context, change-control data, RMM session ownership, SIEM correlation with network and identity telemetry, and post-compromise enrichment. Use this tier for mature enterprise deployment where activity can be validated against session ownership and downstream impact.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM activity followed by high-risk post-compromise command behavior.

·        If the customer lacks approved support workflow documentation, deploy in pilot mode to baseline legitimate helpdesk command usage before enabling aggressive response actions.

Expected False Positives

·        Helpdesk technicians running advanced troubleshooting commands.

·        IT administrators using RMM to repair services, collect logs, or inspect systems.

·        Approved vendor support sessions collecting diagnostics.

·        Security team testing RMM-launched command execution.

·        Endpoint management activity occurring near RMM support sessions.

·        Legacy support workflows that allow interactive shell access.

False Positive Reduction

·        Require high-risk command categories rather than all RMM-associated commands.

·        Correlate with helpdesk tickets, RMM session logs, user role, endpoint role, identity events, and process ancestry.

·        Prioritize credential access, lateral movement, backup interference, security tampering, archive staging, and data transfer over basic diagnostics.

·        Maintain higher severity for restricted systems even where similar behavior is allowed on helpdesk-managed endpoints.

·        Use allowed-command baselines for support teams, but do not suppress high-risk commands globally.

·        Review alerts where the RMM process and high-risk command run under different users, because this may represent service-context execution rather than benign user-driven support.

Known Limitations

·        Some legitimate support activity may involve administrative commands that resemble post-compromise behavior.

·        Correlation may miss activity if the adversary pivots to another host before executing high-risk commands.

·        Correlation by host can increase false positives in environments with frequent legitimate RMM administration unless approved support workflows are baselined.

·        Missing command-line telemetry materially reduces confidence.

·        RMM platform session ownership may require enrichment outside endpoint logs.

·        The operational window may need tuning to local support patterns.

·        Production deployment requires approved support workflow and endpoint role baselines.

DRI Score

·        DRI: 9.2

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it detects a sequence of RMM activity followed by high-risk post-compromise command behavior using raw telemetry correlation. The host-based sequence key improves adversarial resilience because it preserves detection when RMM activity shifts execution into SYSTEM, service, helper-process, or technician-account contexts. Its score is limited by reliance on command-line visibility, endpoint identity consistency, and support workflow baselines.

TCR Score

·        Operational TCR: 8.5

·        Full-Telemetry TCR: 9.1

·        Operational TCR Justification: Operational confidence is strong where Elastic ingests endpoint process telemetry with command line, host identity, process timing, and endpoint role context. Confidence decreases where command lines, stable host identifiers, endpoint role mapping, or support workflow context are incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with complete endpoint process telemetry, RMM platform session logs, identity context, helpdesk records, endpoint role mapping, asset criticality, network telemetry, process ancestry, and service-provider context.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1018 — Remote System Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1105 — Ingress Tool Transfer.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one primary Elastic post-compromise sequence rule.

·        Treat as the strongest Elastic rule in this system set because it correlates RMM activity with high-risk follow-on behavior.

·        Do not configure the rule to alert on low-risk diagnostic commands alone unless scoped to prohibited endpoint populations.

·        Use higher severity where the high-risk command behavior indicates credential access, lateral movement, backup interference, defense evasion, file staging, or ransomware preparation.

·        Use user identity and support-session metadata as enrichment, not mandatory sequence keys, unless the customer has validated same-user execution behavior.

Detection Code

sequence by host.id with maxspan=60m
  [process where event.category == "process" and event.type in ("start", "process_started") and
    (
process.name : (
        "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
        "*simplehelp*", "*splashtop*", "*atera*", "*ninja*", "*syncro*",
        "*zoho*", "*bomgar*", "*beyondtrust*", "*logmein*", "*gotoassist*",
        "*ultraviewer*", "*netsupport*"
      )
      or process.command_line : (
        "*anydesk*", "*teamviewer*", "*screenconnect*", "*connectwise*",
        "*simplehelp*", "*splashtop*", "*atera*", "*ninjaone*", "*syncromsp*",
        "*zohoassist*", "*beyondtrust*", "*bomgar*", "*logmein*", "*gotoassist*",
        "*ultraviewer*", "*netsupport*"
      )
    )
  ]
  [process where event.category == "process" and event.type in ("start", "process_started") and
    (
      process.command_line : (
        "*net user*", "*net localgroup*", "*net group*", "*nltest*",
        "*dsquery*", "*setspn*", "*quser*", "*qwinsta*",
        "*psexec*", "*wmic*", "*winrs*", "*schtasks /s*",
        "*vssadmin delete*", "*wbadmin delete*", "*bcdedit /set*",
        "*reagentc /disable*", "*wevtutil cl*", "*auditpol /set*",
        "*procdump*", "*comsvcs.dll*", "*lsass*", "*ntds.dit*",
        "*rclone*", "*winscp*", "*7z*", "*rar*"
      )
      or process.name : (
        "psexec.exe", "wmic.exe", "rclone.exe", "procdump.exe",
        "vssadmin.exe", "wbadmin.exe", "wevtutil.exe", "bcdedit.exe"
      )
    )
  ]

Elastic Final Disposition

Elastic receives 3 audit-passing rules for this report. The final Elastic rule set covers unauthorized RMM introduction, unauthorized RMM persistence or unattended access, and RMM activity followed by high-risk post-compromise behavior. No additional Elastic rules are included because additional concepts would be redundant, lower-confidence, or dependent on customer-specific telemetry conditions.

QRadar

Detection Viability Assessment

QRadar has moderate-to-high detection viability for this report when endpoint, DNS, proxy, authentication, software inventory, and endpoint-management telemetry are normalized into usable QRadar events with stable host, user, process, command-line, and asset fields. QRadar is strongest as a SIEM correlation layer for identifying RMM activity that occurs outside approved administrative workflows, especially when endpoint execution is paired with persistence, restricted endpoint scope, or high-risk post-compromise behavior.

QRadar should not be treated as the primary endpoint sensor unless the environment forwards detailed EDR, Sysmon, Windows process creation, service creation, registry, DNS, proxy, and identity telemetry into QRadar. The strongest QRadar detections are behavior-driven and correlation-based. Product names may be used as scoped selectors, but detection strength comes from process context, endpoint role, approved-baseline deviation, persistence behavior, and high-risk follow-on activity.

The detection code below is written as QRadar AQL-style validation logic and QRadar Custom Rule Engine-ready sequence logic. Field names, custom properties, log source mappings, reference sets, CRE rule tests, and offense behavior must be validated in the customer QRadar environment before production deployment.

QRadar Rule 1

Unauthorized RMM Execution or Persistence from Suspicious Context

Detection Objective

Detect RMM, remote support, or remote-control tooling executing or installing from suspicious parent processes, user-controlled paths, or persistence-oriented command activity outside approved administrative deployment workflows.

This rule is intended to identify unauthorized RMM introduction and persistence setup from phishing, fake support lures, browser downloads, collaboration-tool downloads, archive extraction, user-driven execution, command-line staging, or attacker placement rather than sanctioned endpoint management workflows.

Behavioral Rationale

RMM abuse often starts when a legitimate remote support tool is introduced through a user-driven workflow or attacker staging path. The tool may be signed and vendor-legitimate, so the detection should not rely on malware reputation or product name alone. The stronger signal is the combination of RMM indicators with suspicious process parentage, user-controlled execution paths, restricted endpoint scope, explicit persistence behavior, or broad install behavior paired with suspicious context.

QRadar can detect this behavior when endpoint logs include process name, command line, parent process, file path, host, user, and asset role. The rule intentionally combines introduction and persistence into one QRadar rule because QRadar deployments often receive these behaviors as normalized endpoint events rather than endpoint-native telemetry. Splitting them into separate QRadar rules would increase redundancy unless the customer has strong service creation, scheduled task, registry, and software inventory custom properties.

Primary Telemetry Source

·        QRadar events from EDR, Sysmon, Windows process creation logs, Windows service creation logs, endpoint management logs, or equivalent normalized endpoint telemetry.

Required QRadar Data Elements

·        Event time.

·        Source host or destination host.

·        Username.

·        Process name custom property.

·        Process command-line custom property.

·        Process path custom property.

·        Parent process name custom property.

·        Event name or QID category.

·        Log source type.

·        Asset role or restricted endpoint reference set.

·        Approved RMM tool reference set.

·        Approved deployment process reference set.

·        Approved RMM path or approved support workflow reference set.

Rule Logic Summary

·        Identify RMM, remote support, remote-control, unattended-access, or support-client indicators in process name, command line, or process path.

·        Require suspicious parent process, suspicious user-controlled path, explicit persistence behavior, or broad install behavior paired with suspicious context.

·        Exclude approved deployment workflows only when the tool, endpoint, user, parent process, path, and support workflow match approved reference data.

·        Prioritize alerts from restricted or high-value systems where direct RMM use is prohibited or tightly controlled.

System-Native Rule Format

QRadar AQL validation search and Custom Rule Engine-ready logic.

Engineering Implementation Instructions

·        Validate QRadar custom properties before production deployment. This rule requires reliable extraction of process name, process command line, process path, and parent process name from the customer’s endpoint log sources.

·        Validate the relevant log sources, such as EDR, Sysmon, Windows Security Event ID 4688, Windows service creation events, endpoint management logs, or equivalent endpoint telemetry.

·        Create reference sets for approved RMM tools, approved deployment processes, approved support users, approved support hosts, approved RMM paths, and restricted endpoint populations.

·        Create a restricted asset reference set covering domain controllers, identity systems, backup servers, privileged access workstations, executive endpoints, security tooling, regulated-data systems, cloud management systems, and other systems where direct RMM use is prohibited or tightly restricted.

·        Do not suppress an RMM product globally. Approved RMM tools can still be abused through unauthorized support sessions, user-driven execution, attacker-generated installers, tenant mismatch, or compromised support workflows.

·        Treat this rule as a combined QRadar introduction and persistence signal. If the customer has strong service creation, registry, scheduled task, and software inventory custom properties, this logic may be split into separate local QRadar rules during implementation.

·        Validate whether QRadar rule actions should create an offense immediately or contribute to an existing offense depending on local SOC workflow and event volume.

·        Enrich alerts with software inventory, proxy logs, DNS logs, identity telemetry, helpdesk records, RMM platform audit logs, endpoint role, and asset criticality.

·        Do not treat this rule as standalone proof of full compromise unless supported by outbound control traffic, identity misuse, tenant mismatch, or post-compromise activity.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted endpoint populations and prohibited RMM tools. Required customer data includes restricted asset reference sets, approved RMM vendor list, approved support hosts, and approved deployment processes.

·        Tier 2 deployment: Add approved RMM inventory, approved process names, approved installation paths, approved parent processes, endpoint role mapping, and software inventory. Use this tier for production alerting on suspicious RMM execution or persistence context.

·        Tier 3 deployment: Add asset criticality, identity context, DNS or proxy enrichment, endpoint process-to-network mapping, approved tenant identifiers, approved management servers, and helpdesk context. Use this tier to prioritize high-risk endpoints and validate tenant or management scope mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management logs, change-control data, service-provider context, and correlation with identity and network telemetry. Use this tier for mature QRadar deployment where alerts can be evaluated against authorized support workflows and follow-on activity.

·        Tiering changes deployment scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM activity plus suspicious context, restricted endpoint scope, explicit persistence behavior, or approved-baseline deviation.

·        If the customer lacks process command-line extraction, approved RMM inventory, or restricted endpoint reference sets, keep this rule in pilot mode until baseline quality supports production alerting.

Expected False Positives

·        Helpdesk-guided temporary remote support downloads.

·        Software vendor support sessions initiated by users.

·        IT testing of portable RMM tools from user-writable paths.

·        Approved emergency break-fix support workflows.

·        Legacy support practices not represented in QRadar reference sets.

·        Endpoint management activity mapped to incomplete or inconsistent custom properties.

·        Approved RMM updates or installations that create service-like or auto-start behavior.

False Positive Reduction

·        Require suspicious parent process, suspicious path, explicit persistence behavior, restricted endpoint scope, or approved-baseline deviation.

·        Use QRadar reference sets for approved RMM tools, approved deployment paths, approved support users, and restricted endpoint populations.

·        Validate alerts against helpdesk tickets, software inventory, asset role, approved tenant, user role, and deployment method.

·        Preserve alerts from high-value or restricted systems even if similar behavior is permitted on helpdesk-managed endpoints.

·        Treat broad terms such as install, service, agent, enroll, and register as lower-confidence unless paired with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

·        Review exceptions periodically to avoid converting approved RMM tooling into a blanket suppression.

Known Limitations

·        QRadar detection quality depends heavily on log source onboarding, custom property extraction, normalization, and reference set quality.

·        Missing command-line telemetry materially reduces confidence.

·        Renamed RMM binaries may evade product-name selectors unless command line, path, tenant, signer, inventory, or behavior still matches.

·        Legitimate support activity may resemble suspicious user-driven RMM introduction.

·        Legitimate RMM tools commonly create services, auto-start behavior, scheduled tasks, or unattended-access settings during approved installation.

·        The rule does not independently prove outbound control-channel communication, tenant mismatch, or post-compromise activity.

·        Production deployment requires customer-specific approved RMM inventory, endpoint population mapping, and QRadar field validation.

DRI Score

·        DRI: 8.3

·        Rating: Primary rule

·        Justification: The rule is behaviorally strong because it detects RMM introduction and persistence context through suspicious parentage, suspicious execution path, explicit persistence behavior, restricted endpoint scope, and approved-baseline deviation. It is resilient across multiple RMM products and deployment paths, but its score is limited by dependence on recognizable RMM indicators, QRadar custom property quality, and customer baseline maturity.

TCR Score

·        Operational TCR: 7.4

·        Full-Telemetry TCR: 8.5

·        Operational TCR Justification: In typical QRadar deployments, telemetry quality varies based on endpoint log source onboarding, command-line capture, custom property extraction, asset context, and reference set maintenance. Operational confidence is moderate-to-high when process name, command line, parent process, and path fields are consistently extracted.

·        Full-Telemetry TCR Justification: Confidence improves with complete endpoint process telemetry, service creation logs, software inventory, asset role mapping, approved RMM inventory, identity telemetry, proxy or DNS enrichment, RMM platform logs, and helpdesk workflow context.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1060 — Registry Run Keys / Startup Folder.

Rule Disposition

·        Include as one primary QRadar correlation rule.

·        Use as the QRadar introduction and persistence-stage detection for unauthorized RMM execution or unattended-access setup.

·        Do not treat this rule as standalone proof of full compromise without network, identity, tenant, persistence, or post-compromise enrichment.

·        Do not split into separate QRadar introduction and persistence rules unless the customer has validated high-quality service creation, scheduled task, registry, and software inventory custom properties.

Detection Code

-- QRadar Rule 1 AQL Selector
-- Purpose: Validate unauthorized RMM execution or persistence from suspicious context.
-- Production use: Convert this selector into QRadar CRE rule tests with customer-validated custom properties and reference sets.

SELECT
  starttime AS event_time,
  sourceip,
  destinationip,
  username,
  "Process Name" AS process_name,
  "Process CommandLine" AS process_commandline,
  "Process Path" AS process_path,
  "Parent Process Name" AS parent_process_name,
  QIDNAME(qid) AS event_name,
  LOGSOURCENAME(logsourceid) AS log_source
FROM events
WHERE
  (
    LOWER("Process Name") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninja|syncro|zoho|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
    OR LOWER("Process CommandLine") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninjaone|syncromsp|zohoassist|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
    OR LOWER("Process Path") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninja|syncro|zoho|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
  )
  AND
  (
    LOWER("Parent Process Name") MATCHES '.*(chrome|msedge|firefox|iexplore|outlook|winword|excel|powerpnt|acrord|teams|slack|zoom|7z|winrar|powershell|cmd|wscript|cscript|mshta|rundll32).*'
    OR LOWER("Process Path") MATCHES '.*\\\\users\\\\.*\\\\(downloads|desktop|appdata\\\\local\\\\temp|onedrive|dropbox)\\\\.*'
    OR LOWER("Process Path") MATCHES '.*\\\\programdata\\\\temp\\\\.*'
    OR LOWER("Process CommandLine") MATCHES '.*(sc create|sc config|schtasks.*/create|reg add.*currentversion\\\\run|start= auto|autostart|auto-start|unattended|silent|quiet|reconnect|persist).*'
    OR (
      LOWER("Process CommandLine") MATCHES '.*(install|service|agent|enroll|register).*'
      AND
      (
        LOWER("Parent Process Name") MATCHES '.*(chrome|msedge|firefox|iexplore|outlook|teams|slack|zoom|powershell|cmd|wscript|cscript|mshta|rundll32).*'
        OR LOWER("Process Path") MATCHES '.*\\\\users\\\\.*\\\\(downloads|desktop|appdata\\\\local\\\\temp|onedrive|dropbox)\\\\.*'
        OR LOWER("Process Path") MATCHES '.*\\\\programdata\\\\temp\\\\.*'
      )
    )
  )
LAST 24 HOURS

CRE Implementation Notes

·        Convert the AQL search into a QRadar event rule after validating custom properties and reference sets.

·        Use rule tests for events matching RMM indicators and suspicious context.

·        Add reference set tests for restricted endpoint population and approved deployment scope.

·        Add negative tests for approved deployment processes only when approved endpoint, user, process, path, and support workflow all match the approved baseline.

·        Configure offense creation according to local event volume and SOC triage workflow.

QRadar Rule 2

RMM Activity Followed by High-Risk Post-Compromise Behavior

Detection Objective

Detect RMM activity followed by high-risk command execution associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation on the same endpoint within a defined operational window.

This rule is intended to identify adversary use of RMM as an interactive post-compromise control channel.

Behavioral Rationale

A legitimate RMM session may involve interactive support, but RMM activity followed by high-risk commands is a stronger post-compromise signal. QRadar can detect this behavior when endpoint process events are normalized with reliable endpoint identity, process name, command line, parent process, user, and event timing fields.

This rule uses two simple AQL selectors and explicit QRadar Custom Rule Engine sequence logic. Stage 1 identifies RMM activity. Stage 2 identifies high-risk post-compromise behavior. The production rule should alert only when both stages occur on the same endpoint within the configured time window. Username should be used as enrichment rather than a required correlation key because RMM-launched activity may run under SYSTEM, a service account, a technician account, a helper process, or another administrative context.

Primary Telemetry Source

·        QRadar endpoint process telemetry from EDR, Sysmon, Windows process creation logs, or equivalent normalized endpoint telemetry.

Required QRadar Data Elements

·        Event time.

·        Normalized endpoint identifier.

·        Source host or destination host.

·        Username where available.

·        Process name custom property.

·        Process command-line custom property.

·        Parent process name custom property where available.

·        Process path custom property where available.

·        Event name or QID category.

·        Asset role or restricted endpoint reference set.

·        Approved support workflow reference set.

·        Approved support user reference set.

·        Helpdesk or RMM session context where available.

Rule Logic Summary

·        Stage 1 must identify RMM activity on an endpoint.

·        Stage 2 must identify high-risk post-compromise command behavior on the same endpoint.

·        The rule must require both stages within the configured operational window.

·        The primary correlation key should be endpoint identity, not username.

·        Username, parent process, RMM session context, support ticket context, and identity telemetry should be used as enrichment.

·        Prioritize credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, and ransomware-preparation patterns.

·        Exclude approved support workflows only when endpoint, user, command category, support ticket, and RMM session context are authorized.

System-Native Rule Format

QRadar AQL validation selectors with Custom Rule Engine sequence logic.

Engineering Implementation Instructions

·        Implement this as a QRadar CRE sequence or correlation rule, not as a single flat AQL event match.

·        Configure Stage 1 to match RMM process, command-line, or process-path indicators.

·        Configure Stage 2 to match high-risk post-compromise command behavior.

·        Use the same normalized endpoint identifier as the primary correlation key. Acceptable endpoint keys may include destination host, source host, asset ID, hostname, or another locally reliable endpoint identifier.

·        Use a 60-minute starting correlation window and tune based on local helpdesk behavior, telemetry volume, and support session duration.

·        Do not require the same username across both stages unless the customer has validated that RMM execution and follow-on command activity consistently preserve the same user context.

·        Create reference sets for approved RMM tools, approved support users, approved troubleshooting commands, restricted endpoint populations, approved support hosts, and approved support workflows.

·        Do not suppress high-risk post-compromise commands solely because a support ticket exists. Validate command category, endpoint role, user, session ownership, and business justification.

·        Prioritize alerts involving credential access, remote execution, backup interference, defense tampering, file staging, administrative share activity, and ransomware preparation.

·        Enrich alerts with identity telemetry, helpdesk records, RMM platform logs, process ancestry, endpoint role mapping, and network telemetry.

·        Avoid automated disruptive response until the customer validates expected RMM-launched administrative command patterns and offense volume.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy in alert-only mode for restricted endpoint populations and high-value systems. Required customer data includes restricted asset reference sets, approved RMM products, approved support users, and approved support hosts.

·        Tier 2 deployment: Add approved troubleshooting commands, helpdesk ticket context, endpoint role mapping, and approved support workflows. Use this tier for production alerting on high-risk post-RMM command activity.

·        Tier 3 deployment: Add identity context, asset criticality, RMM tenant identifiers, endpoint network telemetry, process ancestry enrichment, and RMM platform logs. Use this tier to separate legitimate support from suspicious post-compromise activity.

·        Tier 4 deployment: Add service-provider context, change-control data, RMM session ownership, correlation with network and identity telemetry, and post-compromise enrichment. Use this tier for mature QRadar deployment where activity can be validated against session ownership and downstream impact.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM activity followed by high-risk post-compromise command behavior on the same endpoint.

·        If the customer lacks approved support workflow documentation or command-line telemetry, deploy in pilot mode to baseline legitimate helpdesk command usage before enabling production offense creation.

Expected False Positives

·        Helpdesk technicians running advanced troubleshooting commands.

·        IT administrators using RMM to repair services, collect logs, or inspect systems.

·        Approved vendor support sessions collecting diagnostics.

·        Security team testing RMM-launched command execution.

·        Endpoint management activity occurring near RMM support sessions.

·        Legacy support workflows that allow interactive shell access.

False Positive Reduction

·        Require both RMM activity and high-risk command activity on the same endpoint within the configured window.

·        Require high-risk command categories rather than all RMM-associated commands.

·        Correlate with helpdesk tickets, RMM session logs, user role, endpoint role, identity events, and process ancestry.

·        Prioritize credential access, lateral movement, backup interference, security tampering, archive staging, and data transfer over basic diagnostics.

·        Maintain higher severity for restricted systems even where similar behavior is allowed on helpdesk-managed endpoints.

·        Use approved-command baselines for support teams, but do not suppress high-risk commands globally.

·        Review alerts where the RMM process and high-risk command run under different users because this may represent service-context execution rather than benign user-driven support.

Known Limitations

·        Some legitimate support activity may involve administrative commands that resemble post-compromise behavior.

·        Correlation may miss activity if the adversary pivots to another host before executing high-risk commands.

·        Host-based correlation can increase false positives in environments with frequent legitimate RMM administration unless support workflows are baselined.

·        Missing command-line telemetry materially reduces confidence.

·        Weak endpoint identity normalization can break same-endpoint correlation.

·        RMM platform session ownership may require enrichment outside endpoint logs.

·        The operational window may need tuning to local support patterns.

·        Production deployment requires approved support workflow and endpoint role baselines.

DRI Score

·        DRI: 8.9

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it requires a two-stage sequence of RMM activity followed by high-risk post-compromise command behavior on the same endpoint. It is resilient across RMM products because the detection focuses on control-channel use and attacker-like follow-on actions rather than product presence alone. Its score is limited by command-line telemetry dependence, endpoint identity normalization, QRadar custom property quality, and support workflow baseline requirements.

TCR Score

·        Operational TCR: 7.9

·        Full-Telemetry TCR: 8.9

·        Operational TCR Justification: Operational confidence is moderate-to-high where QRadar ingests endpoint process telemetry with command line, endpoint identity, process timing, and asset context. Confidence decreases where command lines, stable host identifiers, process extraction, or support workflow context are incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with complete endpoint process telemetry, RMM platform session logs, identity context, helpdesk records, asset role mapping, network telemetry, process ancestry, service-provider context, and validated QRadar reference sets.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1018 — Remote System Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1105 — Ingress Tool Transfer.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one primary QRadar post-compromise correlation rule.

·        Treat as the strongest QRadar rule in this system set because it correlates RMM activity with high-risk follow-on behavior.

·        Do not configure the rule to alert on low-risk diagnostic commands alone unless scoped to prohibited endpoint populations.

·        Use higher severity where the high-risk command behavior indicates credential access, lateral movement, backup interference, defense evasion, file staging, or ransomware preparation.

·        Use username and support-session metadata as enrichment, not mandatory sequence keys, unless the customer has validated same-user execution behavior.

Detection Code

-- Stage 1 AQL Selector: RMM Activity
-- Purpose: Validate events that indicate RMM, remote support, or remote-control activity.
-- Production use: Convert this selector into a QRadar CRE building block.

SELECT
  starttime AS event_time,
  sourceip,
  destinationip,
  username,
  "Hostname" AS hostname,
  "Destination Hostname" AS destination_hostname,
  "Source Hostname" AS source_hostname,
  "Process Name" AS process_name,
  "Process CommandLine" AS process_commandline,
  "Process Path" AS process_path,
  "Parent Process Name" AS parent_process_name,
  QIDNAME(qid) AS event_name,
  LOGSOURCENAME(logsourceid) AS log_source
FROM events
WHERE
  (
    LOWER("Process Name") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninja|syncro|zoho|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
    OR LOWER("Process CommandLine") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninjaone|syncromsp|zohoassist|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
    OR LOWER("Process Path") MATCHES '.*(anydesk|teamviewer|screenconnect|connectwise|simplehelp|splashtop|atera|ninja|syncro|zoho|bomgar|beyondtrust|logmein|gotoassist|ultraviewer|netsupport).*'
  )
LAST 60 MINUTES

-- Stage 2 AQL Selector: High-Risk Post-Compromise Activity
-- Purpose: Validate events that indicate credential access, lateral movement, defense evasion,
-- backup interference, file staging, remote execution, or ransomware preparation.
-- Production use: Convert this selector into a QRadar CRE building block.

SELECT
  starttime AS event_time,
  sourceip,
  destinationip,
  username,
  "Hostname" AS hostname,
  "Destination Hostname" AS destination_hostname,
  "Source Hostname" AS source_hostname,
  "Process Name" AS process_name,
  "Process CommandLine" AS process_commandline,
  "Process Path" AS process_path,
  "Parent Process Name" AS parent_process_name,
  QIDNAME(qid) AS event_name,
  LOGSOURCENAME(logsourceid) AS log_source
FROM events
WHERE
  (
    LOWER("Process CommandLine") MATCHES '.*(net user|net localgroup|net group|nltest|dsquery|setspn|quser|qwinsta).*'
    OR LOWER("Process CommandLine") MATCHES '.*(psexec|wmic|winrs|schtasks /s).*'
    OR LOWER("Process CommandLine") MATCHES '.*(vssadmin delete|wbadmin delete|bcdedit /set|reagentc /disable).*'
    OR LOWER("Process CommandLine") MATCHES '.*(wevtutil cl|auditpol /set|sc stop|taskkill /f).*'
    OR LOWER("Process CommandLine") MATCHES '.*(procdump|comsvcs\\.dll|lsass|ntds\\.dit).*'
    OR LOWER("Process CommandLine") MATCHES '.*(rclone|winscp|7z|rar).*'
    OR LOWER("Process Name") MATCHES '.*(psexec|wmic|rclone|procdump|vssadmin|wbadmin|wevtutil|bcdedit).*'
  )
LAST 60 MINUTES

CRE Sequence Logic

·        Rule type: Event sequence or correlation rule.

·        Stage 1: Match the Stage 1 RMM Activity building block.

·        Stage 2: Match the Stage 2 High-Risk Post-Compromise Activity building block.

·        Correlation requirement: Stage 1 and Stage 2 must occur on the same endpoint within 60 minutes.

·        Endpoint key: Use the most reliable normalized endpoint identifier available in the customer environment.

·        Preferred endpoint key order: Asset ID, hostname, destination hostname, source hostname, destination IP, or source IP, based on local reliability.

·        Username handling: Do not require the same username unless same-user behavior has been validated in the customer environment.

·        Required exclusions: Exclude only when approved support workflow, endpoint, user, command category, and support-session context all match.

·        Support-ticket constraint: Do not suppress high-risk commands solely because a support ticket exists.

·        Offense guidance: Create or add to an offense when both stages occur on the same endpoint within the configured window.

·        Severity guidance: Increase severity for restricted endpoints, identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, and systems where RMM use is prohibited.

·        Deployment state: Keep in alert-only or pilot mode until endpoint identity normalization, command-line extraction, and approved support workflows are validated.

QRadar Final Disposition

QRadar receives 2 audit-passing rules for this report. The final QRadar rule set covers unauthorized RMM execution or persistence from suspicious context and RMM activity followed by high-risk post-compromise behavior. No additional QRadar rules are included because additional concepts would be redundant, lower-confidence, or dependent on customer-specific telemetry conditions.

Sigma

Detection Viability Assessment

Sigma has high detection viability for this report as a portable detection-rule format when the target environment collects Windows process creation, command-line, parent process, service creation, scheduled task, registry, and endpoint telemetry with sufficient field fidelity. Sigma is strongest for expressing behavior-driven detections that can be converted into Splunk, Elastic, QRadar, Microsoft Sentinel, Chronicle, or other SIEM-native formats.

Sigma should be treated as a portable detection-content layer, not as a telemetry source by itself. The strongest Sigma detections for this report focus on unauthorized RMM introduction, persistence or unattended-access setup, and RMM-associated high-risk post-compromise command behavior. Product names are used as scoped selectors, but detection strength comes from suspicious parentage, suspicious execution path, persistence behavior, process lineage, restricted endpoint scope, and high-risk follow-on commands.

The rules below are written in Sigma YAML format. Field names, backend translation behavior, log source coverage, event IDs, command-line capture, case sensitivity, and exception handling must be validated in the customer SIEM before production deployment.

Sigma Rule 1

Unauthorized RMM Execution from Suspicious Parent Process or User-Controlled Path

Detection Objective

Detect known RMM, remote support, or remote-control tooling executing from suspicious parent processes or user-controlled staging paths inconsistent with approved software deployment.

This rule is intended to identify RMM introduction through phishing, fake support lures, browser downloads, collaboration-tool downloads, archive extraction, user-driven execution, shell staging, or attacker placement rather than sanctioned endpoint management workflows.

Behavioral Rationale

RMM abuse frequently begins when a user is induced to download and execute a legitimate remote support tool or when an adversary stages a legitimate RMM client from a user-writable path after initial access. The tool may be signed and vendor-legitimate, so the detection should not rely on malware reputation or product name alone. The stronger signal is the mismatch between the tool’s administrative function and the execution context.

This rule combines RMM indicators with suspicious parent processes or suspicious execution paths. It is not intended to alert on approved deployment from endpoint management systems, software distribution tools, administrative management servers, or approved helpdesk automation.

Primary Telemetry Source

·        Windows process creation telemetry from Sysmon Event ID 1, Windows Security Event ID 4688, EDR process telemetry, or equivalent SIEM-normalized endpoint process logs.

Required Sigma Data Elements

·        Image.

·        OriginalFileName where available.

·        CommandLine.

·        ParentImage.

·        ParentCommandLine where available.

·        User.

·        Computer or host identifier.

·        Process creation timestamp.

·        Hashes where available.

·        Signed or signature metadata where available.

·        Endpoint role or asset category through SIEM enrichment.

·        Approved RMM inventory through backend exception logic.

·        Restricted endpoint population through backend exception logic or asset tagging.

Rule Logic Summary

·        Identify execution of RMM, remote support, remote-control, unattended-access, or support-client tooling.

·        Require suspicious parent process context or execution from user-controlled paths.

·        Exclude approved endpoint management, software deployment, helpdesk, or administrative management processes through backend-specific exceptions.

·        Treat the alert as higher priority when the endpoint has no approved RMM baseline, the user is not part of an approved support workflow, or the host belongs to a restricted endpoint population.

System-Native Rule Format

Sigma YAML rule for Windows process creation telemetry.

Engineering Implementation Instructions

·        Validate Sigma backend translation before production deployment because field names and operators vary by SIEM and converter.

·        Deploy first against Windows process creation telemetry with command-line and parent-process visibility.

·        Build an approved RMM inventory before production deployment. The inventory should include approved RMM vendors, executable names, installation paths, tenants, management servers, deployment tools, support users, and approved support workflows.

·        Do not suppress an RMM product globally. Approved RMM products can still be abused through user-driven installation, attacker-generated support sessions, tenant mismatch, or compromised support workflows.

·        Tune through backend exception lists, SIEM lookups, asset groups, or rule exceptions rather than editing the behavioral core of the Sigma rule.

·        Prioritize alerts from ordinary user workstations, executive endpoints, privileged access workstations, domain controllers, identity systems, backup servers, security tooling, regulated-data systems, and cloud-hosted workloads.

·        Enrich alerts with software inventory, proxy or DNS telemetry, identity telemetry, endpoint role, helpdesk records, endpoint management logs, and approved RMM tenant data.

·        Treat this rule as an unauthorized RMM introduction signal, not as standalone proof of full compromise unless supported by persistence, outbound control traffic, identity misuse, or post-compromise behavior.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to endpoints where RMM execution is prohibited or tightly restricted. Required customer data includes restricted endpoint groups, approved RMM vendor list, approved deployment tools, and approved helpdesk accounts.

·        Tier 2 deployment: Add approved installation paths, approved parent processes, approved support workflows, endpoint role mapping, software inventory, and helpdesk ticket context. Use this tier for production alerting on suspicious RMM execution from user-controlled paths or suspicious parent processes.

·        Tier 3 deployment: Add asset criticality, identity context, proxy or DNS enrichment, endpoint process-to-network visibility, approved tenant identifiers, and approved management servers. Use this tier to prioritize high-risk endpoints and validate tenant or management scope mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management logs, change-control data, service-provider context, and SIEM correlation with identity and network telemetry. Use this tier for mature enterprise deployment where Sigma-translated alerts can be evaluated against approved deployment paths and follow-on behavior.

·        Tiering changes deployment scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM execution plus suspicious parentage, suspicious path, approved-scope deviation, or prohibited-policy violation.

·        If the customer lacks approved RMM inventory, command-line telemetry, or endpoint role mapping, keep the rule in pilot mode until baseline quality supports production enforcement.

Expected False Positives

·        Helpdesk-guided temporary remote support downloads.

·        Software vendor support sessions initiated by users.

·        IT testing of portable RMM tools from downloads or temporary directories.

·        Approved emergency break-fix support workflows.

·        Legacy remote support practices not represented in the approved RMM inventory.

·        Endpoint management activity mapped to unexpected parent processes.

False Positive Reduction

·        Require suspicious parent process, suspicious execution path, restricted endpoint scope, or approved-baseline deviation.

·        Use backend-specific exceptions tied to approved RMM inventory rather than broad product suppression.

·        Validate alerts against helpdesk tickets, software inventory, endpoint role, approved tenant, user role, and deployment method.

·        Preserve alerts from high-value or restricted systems even when similar behavior is allowed on helpdesk-managed endpoints.

·        Review exceptions periodically to avoid converting approved RMM tooling into a blanket suppression.

Known Limitations

·        Renamed RMM binaries may evade product-name selectors unless command line, path, signer, tenant, or behavior still matches.

·        Sigma translation quality depends on backend field mapping and converter behavior.

·        User-driven legitimate support sessions may resemble suspicious introduction behavior.

·        The rule does not prove persistence, outbound control-channel activity, tenant mismatch, or post-compromise behavior by itself.

·        Production deployment requires customer-specific approved RMM inventory and endpoint population mapping.

DRI Score

·        DRI: 8.6

·        Rating: Primary rule

·        Justification: The rule is behaviorally strong because it detects RMM execution in suspicious introduction contexts rather than product presence alone. It is resilient across multiple RMM products and delivery paths because it combines tool indicators with parent process and execution path context. Its score is limited by dependence on recognizable RMM indicators and backend-specific exception quality.

TCR Score

·        Operational TCR: 7.8

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: Operational confidence depends on process creation telemetry quality, command-line capture, parent process capture, host mapping, and backend Sigma conversion fidelity. Many environments can support this rule, but translation and normalization quality vary.

·        Full-Telemetry TCR Justification: Confidence improves when process telemetry is enriched with software inventory, endpoint role, approved tenant identifiers, identity telemetry, proxy or DNS telemetry, helpdesk context, asset criticality, and endpoint process-to-network context.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

·        T1566.002 — Spearphishing Link.

Rule Disposition

·        Include as one primary Sigma process-creation rule.

·        Use as the Sigma introduction-stage detection for unauthorized RMM execution.

·        Do not treat this rule as standalone proof of full compromise without persistence, network, identity, or post-compromise enrichment.

Detection Code

title: Unauthorized RMM Execution From Suspicious Parent Process Or User Controlled Path
id: 7cb05fc6-b4b7-4b8d-8cb9-8c1f5c9b7f01
status: experimental
description: Detects RMM or remote support tooling executing from suspicious parent processes or user-controlled paths inconsistent with approved deployment workflows.
references:
  - https://attack.mitre.org/techniques/T1219/
author: CyberDax
date: 2026-04-29
logsource:
  product: windows
  category: process_creation
detection:
  selection_rmm_image:
    Image|contains:
      - '\anydesk'
      - '\teamviewer'
      - '\screenconnect'
      - '\connectwise'
      - '\simplehelp'
      - '\splashtop'
      - '\atera'
      - '\ninja'
      - '\syncro'
      - '\zoho'
      - '\bomgar'
      - '\beyondtrust'
      - '\logmein'
      - '\gotoassist'
      - '\ultraviewer'
      - '\netsupport'
  selection_rmm_command:
    CommandLine|contains:
      - 'anydesk'
      - 'teamviewer'
      - 'screenconnect'
      - 'connectwise'
      - 'simplehelp'
      - 'splashtop'
      - 'atera'
      - 'ninjaone'
      - 'syncromsp'
      - 'zohoassist'
      - 'bomgar'
      - 'beyondtrust'
      - 'logmein'
      - 'gotoassist'
      - 'ultraviewer'
      - 'netsupport'
  selection_suspicious_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\outlook.exe'
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\acrord32.exe'
      - '\teams.exe'
      - '\slack.exe'
      - '\zoom.exe'
      - '\7z.exe'
      - '\winrar.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  selection_suspicious_path:
    Image|contains:
      - '\Downloads\'
      - '\Desktop\'
      - '\AppData\Local\Temp\'
      - '\AppData\Local\Microsoft\Windows\INetCache\'
      - '\AppData\Local\Packages\'
      - '\OneDrive\'
      - '\Dropbox\'
      - '\ProgramData\Temp\'
  condition: 1 of selection_rmm_* and 1 of selection_suspicious_*
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - Hashes
falsepositives:
  - Approved helpdesk-guided support sessions
  - Software vendor support activity
  - Emergency break-fix support
  - IT testing from temporary directories
level: high
tags:
  - attack.t1219
  - attack.t1204.002
  - attack.t1105
  - attack.t1059
  - attack.t1566.002

Sigma Rule 2

Unauthorized RMM Persistence or Unattended Access Configuration

Detection Objective

Detect RMM-associated service creation, auto-start configuration, scheduled execution, unattended-access enablement, agent registration, or persistent installation behavior outside approved administrative deployment workflows.

This rule is intended to identify adversary efforts to preserve post-compromise control through persistent RMM agents, auto-start behavior, unattended access, reconnect capability, agent enrollment, service registration, or remote-control configuration changes.

Behavioral Rationale

RMM abuse becomes materially more dangerous when an attacker converts a temporary support session or staged installer into durable unattended access. Persistence may be created through services, scheduled tasks, registry autoruns, startup entries, remote-control configuration files, service installation commands, agent enrollment actions, or silent installation parameters.

This rule separates high-confidence persistence behavior from broader installation terms. High-confidence persistence patterns can alert when paired with RMM indicators. Broad terms such as install, service, agent, enroll, or register require additional suspicious context such as suspicious parentage or user-controlled path execution. This reduces noise in RMM-heavy environments while preserving the ability to catch adversary-driven persistent deployment.

Primary Telemetry Source

·        Windows process creation telemetry from Sysmon Event ID 1, Windows Security Event ID 4688, EDR process telemetry, or equivalent SIEM-normalized endpoint process logs.

Required Sigma Data Elements

·        Image.

·        CommandLine.

·        ParentImage.

·        ParentCommandLine where available.

·        User.

·        Computer or host identifier.

·        Process creation timestamp.

·        Endpoint role or asset category through backend enrichment.

·        Approved RMM persistence baseline through backend exception logic.

·        Optional service creation, registry, scheduled task, or software inventory fields where available in the target SIEM.

Rule Logic Summary

·        Identify RMM, remote support, remote-control, or unattended-access indicators in process name, command line, or executable path.

·        Alert on explicit persistence behavior such as service creation, service configuration, scheduled task creation, registry autorun modification, auto-start configuration, silent installation, unattended access, reconnect behavior, or agent enrollment.

·        For broad installation terms, require suspicious parent process, suspicious path, restricted endpoint population, or non-standard deployment context.

·        Exclude approved deployment workflows only when tool, endpoint, user, deployment path, and support workflow match approved inventory.

·        Prioritize persistence creation on high-value or restricted systems.

System-Native Rule Format

Sigma YAML rule for Windows process creation telemetry.

Engineering Implementation Instructions

·        Validate Sigma backend translation before production deployment.

·        Validate endpoint data source coverage for process creation, command-line telemetry, parent process, service creation, scheduled task creation, registry changes, and software inventory where available.

·        Build approved RMM persistence baselines covering service names, service paths, install paths, scheduled task names, tenant identifiers, management servers, endpoint populations, and approved deployment tools.

·        Do not suppress persistence events for approved RMM products when persistence is created by an unusual user, suspicious parent process, user-writable path, or non-standard deployment mechanism.

·        Use backend exception lists for approved deployment workflows only when endpoint, user, deployment path, parent process, and support workflow match policy.

·        Enrich alerts with endpoint role, asset criticality, software inventory, RMM platform logs, identity telemetry, helpdesk records, and change-control data.

·        Treat this rule as a high-priority persistence signal. Incident confirmation should determine whether the persistence was authorized, whether the tenant is approved, and whether post-compromise activity followed.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy to restricted endpoint groups where RMM persistence is prohibited. Required customer data includes restricted endpoint groups, prohibited host classes, approved RMM tools, and approved deployment mechanisms.

·        Tier 2 deployment: Add approved service names, install paths, scheduled task names, deployment tools, helpdesk workflows, and software inventory. Use this tier for production detection of unauthorized RMM persistence.

·        Tier 3 deployment: Add endpoint role mapping, asset criticality, identity context, approved tenant identifiers, approved management servers, service inventory, and registry or scheduled task telemetry where available. Use this tier to prioritize persistence on sensitive infrastructure and validate tenant or deployment mismatch.

·        Tier 4 deployment: Add RMM platform audit logs, endpoint management records, change-control data, service-provider context, and SIEM correlation with network and identity telemetry. Use this tier to validate whether persistence was created through an approved workflow or represents unauthorized unattended access.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require persistence or unattended-access behavior tied to RMM tooling and approved-scope deviation.

·        If the customer lacks service inventory, approved RMM deployment paths, or endpoint role mapping, use this rule in pilot mode until baseline quality supports production deployment.

Expected False Positives

·        Approved RMM installation or update creating services or auto-start behavior.

·        Helpdesk deployment of unattended-access tools during legitimate support.

·        MSP deployment through approved but undocumented workflows.

·        Endpoint management repairing or reinstalling a sanctioned RMM agent.

·        Vendor support sessions creating temporary persistence for troubleshooting.

·        Legacy RMM deployment mechanisms not represented in the approved baseline.

False Positive Reduction

·        Add approved RMM service names, install paths, tenant identifiers, and deployment mechanisms to the baseline.

·        Exclude approved endpoint management tools only when endpoint, user, deployment path, and support workflow match policy.

·        Use endpoint role and asset criticality to prioritize restricted systems.

·        Validate against change-control records, helpdesk tickets, RMM platform logs, software inventory, and identity telemetry.

·        Keep alerts where approved RMM persistence is created by unexpected users, suspicious parent processes, or user-writable paths.

·        Treat broad install, service, agent, enroll, and register terms as lower-confidence unless paired with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Known Limitations

·        Legitimate RMM tools commonly create services, scheduled tasks, auto-start entries, and unattended-access settings.

·        Backend field availability for service creation, registry, scheduled task, and software inventory varies by SIEM and telemetry source.

·        Missing command-line telemetry materially reduces confidence.

·        Renamed tools may evade product-string selectors unless service path, signer, tenant, inventory, or behavior still matches.

·        The rule does not independently prove outbound control-channel communication or post-compromise activity.

·        Production deployment requires approved RMM persistence baselines to avoid noise.

DRI Score

·        DRI: 8.7

·        Rating: Primary rule

·        Justification: The rule is strongly anchored to persistence and unattended-access behavior, which is central to RMM-enabled post-compromise control. Its tightened logic improves resilience by separating explicit persistence behavior from broad installation terms and requiring additional suspicious context for lower-specificity patterns. Its score is limited by product-string dependence, backend translation variation, and approved RMM baseline quality.

TCR Score

·        Operational TCR: 7.7

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: Operational confidence depends on process creation telemetry, command-line visibility, parent process visibility, backend Sigma conversion fidelity, and approved persistence baseline quality. Confidence decreases where service, registry, scheduled task, or software inventory telemetry is unavailable.

·        Full-Telemetry TCR Justification: Confidence improves with complete process telemetry, service creation events, scheduled task telemetry, registry telemetry, software inventory, endpoint role mapping, approved RMM baseline data, RMM platform logs, and change-control records.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1060 — Registry Run Keys / Startup Folder.

·        T1136 — Create Account.

Rule Disposition

·        Include as one primary Sigma persistence rule.

·        Use as the Sigma persistence-focused detection for unauthorized RMM control preservation.

·        Do not suppress solely because the RMM product is approved elsewhere in the enterprise.

·        Treat broad install, service, agent, enroll, and register terms as production-safe only when combined with suspicious parentage, suspicious path, restricted endpoint scope, or non-standard deployment context.

Detection Code

title: Unauthorized RMM Persistence Or Unattended Access Configuration
id: 13f18949-e5e7-47b5-8a2d-9e32ad4e6b12
status: experimental
description: Detects RMM-associated persistence, unattended-access setup, service configuration, or persistent installation behavior outside approved deployment workflows.
references:
  - https://attack.mitre.org/techniques/T1219/
author: CyberDax
date: 2026-04-29
logsource:
  product: windows
  category: process_creation
detection:
  selection_rmm_command:
    CommandLine|contains:
      - 'anydesk'
      - 'teamviewer'
      - 'screenconnect'
      - 'connectwise'
      - 'simplehelp'
      - 'splashtop'
      - 'atera'
      - 'ninjaone'
      - 'syncromsp'
      - 'zohoassist'
      - 'bomgar'
      - 'beyondtrust'
      - 'logmein'
      - 'gotoassist'
      - 'ultraviewer'
      - 'netsupport'
  selection_rmm_image:
    Image|contains:
      - '\anydesk'
      - '\teamviewer'
      - '\screenconnect'
      - '\connectwise'
      - '\simplehelp'
      - '\splashtop'
      - '\atera'
      - '\ninja'
      - '\syncro'
      - '\zoho'
      - '\bomgar'
      - '\beyondtrust'
      - '\logmein'
      - '\gotoassist'
      - '\ultraviewer'
      - '\netsupport'
  persistence_service_create:
    CommandLine|contains|all:
      - 'sc'
      - 'create'
  persistence_service_config:
    CommandLine|contains|all:
      - 'sc'
      - 'config'
  persistence_scheduled_task_create:
    CommandLine|contains|all:
      - 'schtasks'
      - '/create'
  persistence_registry_run_key:
    CommandLine|contains|all:
      - 'reg add'
      - '\CurrentVersion\Run'
  persistence_auto_start:
    CommandLine|contains:
      - 'start= auto'
      - 'autostart'
      - 'auto-start'
  persistence_unattended_access:
    CommandLine|contains:
      - 'unattended'
      - 'reconnect'
      - 'persist'
  persistence_silent_install:
    CommandLine|contains:
      - 'silent'
      - 'quiet'
  selection_broad_install:
    CommandLine|contains:
      - 'install'
      - 'service'
      - 'agent'
      - 'enroll'
      - 'register'
  context_suspicious_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\outlook.exe'
      - '\teams.exe'
      - '\slack.exe'
      - '\zoom.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  context_suspicious_path:
    Image|contains:
      - '\Downloads\'
      - '\Desktop\'
      - '\AppData\Local\Temp\'
      - '\OneDrive\'
      - '\Dropbox\'
      - '\ProgramData\Temp\'
  filter_known_management_parent:
    ParentImage|contains:
      - '\ccmexec.exe'
      - '\Microsoft Intune Management Extension\'
      - '\Jamf\'
      - '\Tanium\'
      - '\BigFix\'
      - '\KACE\'
  condition: 1 of selection_rmm_* and (1 of persistence_* or (selection_broad_install and 1 of context_*)) and not filter_known_management_parent
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - Hashes
falsepositives:
  - Approved RMM installation or update
  - Approved endpoint management deployment
  - MSP deployment through approved workflows
  - Vendor support creating temporary persistence
level: high
tags:
  - attack.t1219
  - attack.t1543.003
  - attack.t1053.005
  - attack.t1060
  - attack.t1136

Sigma Rule 3

RMM Tool Launching High-Risk Post-Compromise Activity

Detection Objective

Detect RMM, remote support, or remote-control tooling launching or being closely associated with high-risk command execution, including credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

This rule is intended to identify adversary use of RMM as an interactive post-compromise control channel.

Behavioral Rationale

A legitimate RMM session may involve interactive support, but RMM-launched high-risk commands are stronger post-compromise signals than the presence of remote access software alone. Adversaries commonly use RMM tools to execute native operating system utilities for enumeration, credential access, lateral movement, defense tampering, backup interference, file staging, and ransomware preparation.

Sigma is less ideal than Elastic EQL or SIEM correlation SPL for multi-event sequence logic because Sigma rule support depends on backend translation. This rule therefore focuses on process lineage where RMM tooling appears as the parent process. If the target backend supports sequence correlation, a local implementation may also correlate RMM activity followed by high-risk commands on the same endpoint within a defined window.

Primary Telemetry Source

·        Windows process creation telemetry from Sysmon Event ID 1, Windows Security Event ID 4688, EDR process telemetry, or equivalent SIEM-normalized endpoint process logs.

Required Sigma Data Elements

·        Image.

·        CommandLine.

·        ParentImage.

·        ParentCommandLine where available.

·        User.

·        Computer or host identifier.

·        Process creation timestamp.

·        Endpoint role or asset category through backend enrichment.

·        Approved support workflow context through backend exceptions.

·        RMM platform or support-session context where available.

Rule Logic Summary

·        Identify high-risk child process execution where the parent process appears to be RMM, remote support, or remote-control tooling.

·        Detect command-line behavior associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

·        Avoid alerting on low-risk diagnostic commands alone.

·        Prioritize alerts from restricted or high-value systems.

·        Use backend-specific correlation where available to detect RMM activity followed by high-risk commands on the same endpoint when direct parent-child lineage is unavailable.

System-Native Rule Format

Sigma YAML rule for Windows process creation telemetry.

Engineering Implementation Instructions

·        Validate Sigma backend translation before production deployment.

·        Validate customer-specific RMM process names and add them to the parent process selector. Some RMM products use multiple agent, service, helper, and support process names.

·        Do not rely only on default product process names. Include customer-approved agent names, private management agent names, and known support client names where applicable.

·        Tune carefully for legitimate helpdesk workflows that use command shells for troubleshooting, but do not suppress high-risk child process categories from high-value or prohibited systems.

·        Prioritize alerts involving credential access, lateral movement, security-tool tampering, backup interference, archive staging, remote execution, or ransomware preparation.

·        Enrich alerts with user role, endpoint role, approved support ticket, support-session metadata, identity logs, network telemetry, and RMM platform logs.

·        Treat this rule as a strong post-compromise signal when RMM-associated activity occurs outside approved support workflows or on systems where interactive remote administration is prohibited.

·        Where the backend supports sequence correlation, implement a companion backend-native correlation that requires RMM activity followed by high-risk commands on the same endpoint within a defined window.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy in alert-only mode for restricted endpoint populations and high-value systems. Required customer data includes restricted endpoint groups, approved RMM products, and approved support users.

·        Tier 2 deployment: Add approved helpdesk workflows, allowed troubleshooting commands, support-ticket context, and endpoint role mapping. Use this tier for production alerting on RMM-launched high-risk child process behavior outside approved support activity.

·        Tier 3 deployment: Add identity context, asset criticality, software inventory, RMM tenant identifiers, endpoint network telemetry, and process ancestry enrichment. Use this tier to separate legitimate troubleshooting from suspicious post-compromise activity.

·        Tier 4 deployment: Add RMM platform audit logs, service-provider context, change-control data, SIEM correlation, and post-compromise enrichment. Use this tier for mature enterprise deployment where RMM-launched activity can be tied to session ownership, approved tickets, and downstream impact.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require RMM-associated parent process activity plus high-risk child execution or command behavior.

·        If the customer lacks approved support workflow documentation, deploy in pilot mode to baseline legitimate helpdesk command usage before enabling aggressive response actions.

Expected False Positives

·        Helpdesk technicians running advanced troubleshooting commands.

·        IT administrators using RMM to repair services, collect logs, or inspect systems.

·        Approved vendor support sessions collecting diagnostics.

·        Security team testing RMM-launched command execution.

·        Endpoint management activity occurring near RMM support sessions.

·        Legacy support workflows that allow interactive shell access.

False Positive Reduction

·        Require high-risk command categories rather than all RMM-associated commands.

·        Correlate with helpdesk tickets, RMM session logs, user role, endpoint role, identity events, and process ancestry.

·        Prioritize credential access, lateral movement, backup interference, security tampering, archive staging, and data-transfer behavior over basic diagnostics.

·        Maintain higher severity for restricted systems even where similar behavior is allowed on helpdesk-managed endpoints.

·        Use approved-command baselines for support teams, but do not suppress high-risk commands globally.

Known Limitations

·        Some RMM tools legitimately spawn shells or scripts during authorized troubleshooting.

·        Parent-child process relationships may vary depending on how the RMM tool launches commands.

·        Some remote command activity may appear under a service process or helper process rather than the visible RMM client name.

·        The rule may miss post-compromise activity if the adversary pivots away from the RMM process lineage before executing commands.

·        Sigma sequence support depends on backend conversion and may require backend-native implementation.

·        Production deployment requires customer-specific RMM process name coverage and support workflow baselines.

DRI Score

·        DRI: 8.8

·        Rating: Primary rule

·        Justification: The rule is strongly behavior anchored because it detects high-risk post-compromise actions launched through or associated with RMM control rather than RMM presence alone. It is resilient across multiple RMM products where process lineage is available and can be adapted with customer-specific RMM parent process names. Its score is limited by process-lineage variability and backend Sigma translation constraints.

TCR Score

·        Operational TCR: 7.8

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: Operational confidence is moderate-to-high where process lineage and command-line telemetry are consistently collected and translated into the target SIEM. Confidence decreases when RMM helper processes obscure parent-child lineage or when support workflows are poorly documented.

·        Full-Telemetry TCR Justification: Confidence improves with complete process lineage, command-line telemetry, support-session metadata, identity telemetry, endpoint role mapping, RMM platform logs, software inventory, and backend-native sequence support.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1018 — Remote System Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1105 — Ingress Tool Transfer.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one primary Sigma post-compromise rule.

·        Treat as the strongest Sigma post-compromise control-channel rule when process lineage is available.

·        Do not configure the translated rule to alert on low-risk diagnostic commands alone unless scoped to prohibited endpoint populations.

·        Use higher severity where high-risk command behavior indicates credential access, lateral movement, backup interference, defense evasion, file staging, or ransomware preparation.

·        Use backend-native sequence correlation as an implementation enhancement where available.

Detection Code

title: RMM Tool Launching High Risk Post Compromise Activity
id: e52f0df8-2f1a-48bb-9dd6-0dd45acdf947
status: experimental
description: Detects RMM or remote support tooling spawning high-risk commands associated with credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.
references:
  - https://attack.mitre.org/techniques/T1219/
author: CyberDax
date: 2026-04-29
logsource:
  product: windows
  category: process_creation
detection:
  selection_rmm_parent:
    ParentImage|contains:
      - '\anydesk'
      - '\teamviewer'
      - '\screenconnect'
      - '\connectwise'
      - '\simplehelp'
      - '\splashtop'
      - '\atera'
      - '\ninja'
      - '\syncro'
      - '\zoho'
      - '\bomgar'
      - '\beyondtrust'
      - '\logmein'
      - '\gotoassist'
      - '\ultraviewer'
      - '\netsupport'
  highrisk_discovery_and_identity:
    CommandLine|contains:
      - 'net user'
      - 'net localgroup'
      - 'net group'
      - 'nltest'
      - 'dsquery'
      - 'setspn'
      - 'quser'
      - 'qwinsta'
  highrisk_lateral_movement:
    CommandLine|contains:
      - 'psexec'
      - 'wmic'
      - 'winrs'
      - 'schtasks /s'
      - 'sc \\'
  highrisk_defense_backup_tampering:
    CommandLine|contains:
      - 'vssadmin delete'
      - 'wbadmin delete'
      - 'bcdedit /set'
      - 'reagentc /disable'
      - 'wevtutil cl'
      - 'auditpol /set'
      - 'sc stop'
      - 'taskkill /f'
  highrisk_credential_access:
    CommandLine|contains:
      - 'procdump'
      - 'comsvcs.dll'
      - 'lsass'
      - 'sekurlsa'
      - 'ntds.dit'
  highrisk_staging_transfer:
    CommandLine|contains:
      - 'rclone'
      - 'winscp'
      - '7z'
      - 'rar'
  highrisk_process:
    Image|endswith:
      - '\psexec.exe'
      - '\wmic.exe'
      - '\rclone.exe'
      - '\procdump.exe'
      - '\vssadmin.exe'
      - '\wbadmin.exe'
      - '\wevtutil.exe'
      - '\bcdedit.exe'
  condition: selection_rmm_parent and 1 of highrisk_*
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - Hashes
falsepositives:
  - Approved helpdesk troubleshooting
  - Approved vendor support diagnostics
  - Security testing
  - Legacy support workflows with interactive shell access
level: high
tags:
  - attack.t1219
  - attack.t1059
  - attack.t1087
  - attack.t1018
  - attack.t1003
  - attack.t1021
  - attack.t1105
  - attack.t1489
  - attack.t1490

Sigma Final Disposition

Sigma receives 3 audit-passing rules for this report. The final Sigma rule set covers unauthorized RMM introduction, unauthorized RMM persistence or unattended access, and RMM-associated high-risk post-compromise behavior. No additional Sigma rules are included because additional concepts would be redundant, lower-confidence, or dependent on backend-specific telemetry conditions.

YARA

Detection Viability Assessment

YARA has low production detection viability for this report. RMM tool abuse is primarily a behavioral and telemetry-driven threat pattern, not a malware-family or file-signature problem. The core risk comes from legitimate remote management tools being introduced, configured, persisted, or used as post-compromise control channels. Those conditions require endpoint process telemetry, SIEM correlation, network telemetry, identity telemetry, approved-tool baselines, endpoint role context, and support-workflow validation.

YARA should not be treated as a primary detection system for this report. A YARA rule that identifies common RMM products, vendor strings, signed binaries, static hashes, generic installers, or packed binaries would not reliably distinguish authorized remote administration from adversary-controlled RMM abuse. That type of detection would create high false positives in environments with legitimate support tooling and would not establish whether the activity was unauthorized.

The strongest detection opportunities for this report are already represented in endpoint and SIEM systems that can evaluate execution context, parent process, command line, persistence behavior, endpoint role, approved deployment path, tenant authorization, and high-risk follow-on activity. YARA cannot reliably determine whether a legitimate RMM binary was downloaded by a user, deployed by an approved management system, enrolled into an unauthorized tenant, configured for unattended access, or used to launch post-compromise commands.

Final YARA Rule Count

·        YARA final rule count: 0

·        Rule disposition: Do not include

·        Rule role: Conditional forensic or malware-triage capability only

·        Rule confidence: Low for standalone production detection

·        Deployment posture: Not recommended as a production rule set for this report’s primary detection objectives

YARA Rule Viability Decision

No YARA production rules are included for this report.

Rationale

YARA is not suitable as a standing production detection format for RMM tool abuse because the report’s detection objectives require behavioral context. The relevant questions are whether the tool executed from a suspicious path, whether the parent process indicates phishing or user-driven staging, whether persistence was created outside approved deployment workflows, whether the endpoint is restricted, whether the RMM tenant is authorized, and whether the tool was followed by high-risk post-compromise commands. YARA does not observe those conditions by itself.

A YARA rule that detects known RMM file content would not distinguish approved support software from attacker-abused support software. That would create a high-noise rule that is likely to be suppressed or ignored in environments where RMM tools are used legitimately. It would also be fragile because legitimate vendor updates, packed installers, localized builds, renamed binaries, web-based support clients, and cloud-delivered support modules can change file content without changing the underlying abuse pattern.

YARA Production Viability Limitation

YARA is not recommended as a standing production detection format for this report because generic file-content matching would not reliably distinguish legitimate RMM administration from adversary-controlled RMM abuse. Product-name, vendor-string, signer, hash, installer, or generic packed-binary matching would primarily identify the presence of legitimate remote support software or common installer traits rather than the unauthorized behavior that defines the threat.

YARA may still be useful during incident response if a specific malicious artifact is recovered, such as a trojanized RMM installer, malicious wrapper, loader, dropper, or campaign-specific file. In that case, YARA should target the malicious wrapper or campaign-specific artifact, not the legitimate RMM product itself.

Conditional YARA Use Case

YARA may be used only if an investigation produces a specific malicious file artifact that is not merely a legitimate RMM binary. Acceptable conditional use cases include:

·        A trojanized RMM installer.

·        A malicious wrapper that drops or launches an RMM tool.

·        A custom loader that retrieves or installs an RMM client.

·        A campaign-specific file containing stable malicious strings, resources, mutexes, metadata, or structural traits.

·        A signed but tampered artifact where the malicious file content is distinct from the legitimate vendor binary.

·        A compressed or staged payload with stable file-content characteristics tied to a confirmed intrusion.

In those cases, YARA should be written only against the malicious wrapper, loader, dropper, or campaign-specific artifact. It should not be written against the legitimate RMM product itself.

Primary Telemetry Gap

YARA lacks the operational context required to distinguish legitimate RMM administration from adversary-controlled RMM abuse. The missing context includes:

·        Parent process lineage.

·        Command-line execution context.

·        User and role context.

·        Approved deployment path.

·        Endpoint role and restricted system status.

·        Tenant or management-server authorization.

·        Persistence creation context.

·        RMM-launched post-compromise activity.

·        Helpdesk, change-control, or support-session validation.

·        Network control-channel context.

·        Identity activity following remote access.

Detection Coverage Impact

YARA does not materially improve production detection coverage for this report. Coverage should be carried by systems that observe behavior and context, including endpoint detection platforms, SIEM correlation systems, DNS/proxy telemetry, identity telemetry, asset context, and approved-RMM inventory enrichment.

YARA can remain available as a conditional forensic tool for sample-specific triage, but it should not be included as an S25 production rule set for this report.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

Rule Disposition

·        Do not include YARA production rules for this report.

·        Treat YARA as a conditional forensic or malware-triage capability only.

·        Do not create product-name-only, vendor-string-only, hash-only, signer-only, packed-installer-only, or generic RMM-binary YARA detections.

·        Use endpoint, SIEM, network, identity, asset, and approved-tool telemetry for production detection of RMM abuse.

·        Revisit YARA only if the investigation identifies a specific trojanized RMM installer, wrapper, loader, dropper, or campaign-specific file artifact.

YARA Final Disposition

YARA receives 0 audit-passing rules for this report. No YARA rules are included because the report’s core detection requirements are behavioral and context-dependent, while YARA is file-content oriented and would not reliably distinguish authorized RMM use from adversary-controlled RMM abuse.

AWS

Detection Viability Assessment

AWS has moderate detection viability for this report, but only for cloud-native remote management activity, Systems Manager abuse, EC2 control-plane abuse, IAM access enablement, and AWS-native command execution pathways. AWS should not be treated as a primary detection layer for third-party RMM binaries unless endpoint telemetry from EC2 workloads is forwarded into a SIEM, EDR platform, or AWS-native analytics pipeline.

AWS is strongest when detecting abuse of AWS Systems Manager Session Manager, Systems Manager Run Command, Automation execution, EC2 instance profile changes, IAM permission changes, and control-plane actions that enable remote administrative control. These cloud-native pathways can function like RMM when an adversary has sufficient IAM permissions or compromises an identity with Systems Manager or EC2 administrative access.

The strongest AWS detections for this report focus on unauthorized Systems Manager remote access, high-risk command execution through Systems Manager, and Systems Manager access enablement followed by remote-control activity. These detections are conditional because they require CloudTrail coverage, Systems Manager activity visibility, EC2 asset context, IAM identity context, approved role baselines, restricted workload tagging, approved source baselines, and support-workflow validation.

AWS Rule 1

Unauthorized Systems Manager Session or Remote Command Against Restricted EC2 Workloads

Detection Objective

Detect AWS Systems Manager session or remote command activity targeting restricted, high-value, or non-administrative EC2 workloads by an unapproved principal, unexpected role, non-standard source, or non-standard administrative workflow.

This rule is intended to identify AWS-native remote management activity that can provide interactive or command-based control of EC2 workloads outside approved operations.

Behavioral Rationale

AWS Systems Manager can provide legitimate administrative access to EC2 instances through Session Manager, Run Command, and Automation execution. In an intrusion, the same capability can function as a remote-control channel if an adversary obtains IAM permissions, assumes an administrative role, or abuses an automation path.

The strongest signal is not Systems Manager use alone. The stronger signal is Systems Manager activity against restricted workloads by principals, roles, source locations, or workflows that do not match approved administration. Restricted workload access by an approved principal from an approved source should be monitored and enriched, but it should not automatically be treated as unauthorized without additional approved-scope deviation.

This rule detects AWS-native remote-control behavior through cloud control-plane telemetry. It is distinct from endpoint RMM detections because it focuses on Systems Manager activity rather than third-party RMM binaries.

Primary Telemetry Source

·        AWS CloudTrail management events.

·        AWS Systems Manager session and command activity.

·        EC2 instance inventory and tag enrichment.

·        IAM identity and assumed-role context.

Required AWS Data Elements

·        Event time.

·        AWS account ID.

·        Region.

·        Event source.

·        Event name.

·        User identity ARN.

·        User identity type.

·        Assumed role ARN.

·        Source IP address.

·        Request parameters.

·        Target instance ID or target tags.

·        Systems Manager document name where available.

·        EC2 instance tags.

·        Asset criticality.

·        Approved administrator and automation role baselines.

·        Approved source baselines.

·        Restricted workload inventory.

Rule Logic Summary

·        Detect StartSession, SendCommand, or StartAutomationExecution.

·        Treat a principal as approved when either the direct user identity ARN or the assumed-role issuer ARN matches the approved baseline.

·        Alert when restricted workload access is paired with an unapproved principal, unapproved source, missing approved workflow, or other approved-scope deviation.

·        Alert on non-restricted workloads only when principal and source both deviate from approved baselines.

·        Exclude approved automation only when principal, role, source, document, target workload, and change or support workflow match policy.

·        Prioritize activity against identity systems, backup infrastructure, security tooling, privileged access workloads, production servers, regulated-data systems, and cloud management systems.

System-Native Rule Format

AWS CloudTrail Lake SQL / SIEM-ready query logic.

Engineering Implementation Instructions

·        Validate CloudTrail management event coverage for Systems Manager and EC2 across all relevant AWS accounts and regions.

·        Validate that StartSession, SendCommand, and StartAutomationExecution events are retained and searchable.

·        Build an approved AWS administrator and automation role baseline, including IAM roles, federated identities, CI/CD roles, break-glass roles, security operations roles, cloud operations roles, and SSM automation roles.

·        Treat assumed-role session ARNs and IAM role ARNs carefully. Approval should evaluate the assumed-role issuer ARN where present, not only the direct userIdentity.arn field.

·        Build approved source baselines for administrative access paths.

·        Build restricted EC2 workload inventory using tags, AWS Config, CMDB enrichment, asset inventory, or security tooling context.

·        Require same-account and cross-account role assumptions to be evaluated through assumed-role context.

·        Do not suppress Systems Manager activity globally. Approved SSM usage can still be abused through compromised IAM identities, unauthorized role assumption, or non-standard targets.

·        Enrich alerts with IAM Identity Center logs, GuardDuty findings, VPC Flow Logs, endpoint telemetry, change-management records, and Systems Manager session logs where available.

·        Treat this rule as a cloud-native remote-control signal. Incident confirmation should evaluate IAM compromise, role assumption path, target workload sensitivity, command content, and post-session activity.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted EC2 workloads and prohibited SSM principals. Required customer data includes restricted workload tags, approved administrator roles, approved automation roles, approved source locations, and approved support accounts.

·        Tier 2 deployment: Add approved SSM documents, approved target groups, approved source networks, change-control context, and IAM Identity Center user mapping. Use this tier for production alerting on non-standard Systems Manager access.

·        Tier 3 deployment: Add asset criticality, account tiering, cross-account role assumptions, security account context, VPC Flow Log enrichment, EDR telemetry, and session logging. Use this tier to prioritize high-value EC2 targets and distinguish approved administration from suspicious control.

·        Tier 4 deployment: Add centralized CloudTrail Lake, AWS Organizations account metadata, Systems Manager session transcript logging, change-management integration, ticket context, and SIEM correlation. Use this tier for mature enterprise deployment across multi-account AWS environments.

·        Tiering changes scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require Systems Manager remote activity plus restricted target, unapproved principal, unapproved source, non-standard workflow, or approved-scope deviation.

·        If the customer lacks restricted workload tagging, approved IAM role baselines, or approved source baselines, deploy in pilot mode until asset and identity baselines support production alerting.

Expected False Positives

·        Approved administrator troubleshooting through Session Manager.

·        Approved Run Command activity from patching, software deployment, or inventory automation.

·        Emergency break-glass support activity.

·        Security operations investigation on sensitive instances.

·        New automation roles not yet represented in the baseline.

·        Cross-account administration through approved but undocumented workflows.

False Positive Reduction

·        Baseline approved SSM roles, automation roles, source networks, documents, target tags, and support workflows.

·        Exclude approved activity only when principal, role, source, document, target, and support context all match.

·        Maintain high severity for restricted workloads when principal, source, role, or workflow deviates from baseline.

·        Validate alerts against change records, support tickets, IAM Identity Center logs, and Systems Manager session records.

·        Review exceptions periodically to avoid converting Systems Manager into a blanket suppression.

Known Limitations

·        CloudTrail may not include full command content for all Systems Manager activity depending on configuration and service behavior.

·        Session transcript logging requires explicit configuration.

·        EC2 instance tags and asset inventory quality directly affect prioritization.

·        Approved administration can resemble suspicious remote-control activity without support workflow context.

·        Cross-account role assumption can complicate identity attribution.

·        This rule does not detect third-party RMM binaries unless endpoint telemetry is forwarded and correlated separately.

DRI Score

·        DRI: 8.5

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects AWS-native remote management activity against restricted workloads by non-standard principals, sources, or workflows. It is resilient because it focuses on Systems Manager control behavior rather than third-party RMM product names. Its score is limited by dependence on accurate IAM baselines, assumed-role normalization, source baselines, workload tagging, and approved operations context.

TCR Score

·        Operational TCR: 7.8

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: Operational confidence is moderate-to-high where CloudTrail, IAM identity context, assumed-role issuer context, EC2 tags, approved source context, and approved role baselines are available. Confidence decreases when target workload inventory, source context, session logging, or support workflow data is incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with centralized CloudTrail Lake, complete account and region coverage, Systems Manager session logs, EC2 asset criticality, IAM Identity Center context, change records, VPC Flow Logs, and endpoint telemetry.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

Rule Disposition

·        Include as one conditional AWS cloud-native detection rule.

·        Use as the primary AWS rule for unauthorized Systems Manager remote management against EC2 workloads.

·        Do not treat this rule as standalone proof of compromise without identity, command, workload, session, or endpoint enrichment.

·        Do not suppress Systems Manager activity globally because approved SSM access can still be abused.

Detection Code

-- AWS Rule 1: Unauthorized Systems Manager session or remote command against restricted EC2 workloads
-- Deployment note: Replace placeholder values with customer-approved identity, role, source, account, and workload baselines.
-- Key implementation requirement: Treat the principal as approved when either the direct user ARN or the assumed-role issuer ARN matches the approved baseline.

WITH ssm_events AS (
  SELECT
    eventTime,
    recipientAccountId,
    awsRegion,
    eventSource,
    eventName,
    userIdentity.type AS user_identity_type,
    userIdentity.arn AS user_arn,
    userIdentity.sessionContext.sessionIssuer.arn AS assumed_role_arn,
    sourceIPAddress,
    requestParameters,
    CASE
      WHEN requestParameters LIKE '%<RESTRICTED_INSTANCE_ID_OR_TAG_VALUE>%'
        OR requestParameters LIKE '%<RESTRICTED_INSTANCE_TAG_KEY>%'
        OR requestParameters LIKE '%<RESTRICTED_INSTANCE_TAG_VALUE>%'
      THEN true
      ELSE false
    END AS is_restricted_workload,
    CASE
      WHEN userIdentity.arn IN (
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SSM_ADMIN_ROLE>',
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SSM_AUTOMATION_ROLE>',
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SECURITY_OPERATIONS_ROLE>'
      )
      OR userIdentity.sessionContext.sessionIssuer.arn IN (
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SSM_ADMIN_ROLE>',
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SSM_AUTOMATION_ROLE>',
        'arn:aws:iam::<ACCOUNT_ID>:role/<APPROVED_SECURITY_OPERATIONS_ROLE>'
      )
      THEN true
      ELSE false
    END AS is_approved_principal,
    CASE
      WHEN sourceIPAddress IN (
        '<APPROVED_ADMIN_SOURCE_IP_1>',
        '<APPROVED_ADMIN_SOURCE_IP_2>',
        '<APPROVED_AUTOMATION_SOURCE_IP>'
      )
      THEN true
      ELSE false
    END AS is_approved_source
  FROM cloudtrail_events
  WHERE eventSource = 'ssm.amazonaws.com'
    AND eventName IN ('StartSession', 'SendCommand', 'StartAutomationExecution')
    AND (
      requestParameters LIKE '%i-%'
      OR requestParameters LIKE '%InstanceIds%'
      OR requestParameters LIKE '%targets%'
    )
)
SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  user_identity_type,
  user_arn,
  assumed_role_arn,
  sourceIPAddress,
  requestParameters,
  is_restricted_workload,
  is_approved_principal,
  is_approved_source
FROM ssm_events
WHERE
  (
    is_restricted_workload = true
    AND (
      is_approved_principal = false
      OR is_approved_source = false
    )
  )
  OR
  (
    is_restricted_workload = false
    AND is_approved_principal = false
    AND is_approved_source = false
  );

AWS Rule 2

High-Risk Command Execution Through AWS Systems Manager

Detection Objective

Detect AWS Systems Manager Run Command or Automation activity executing high-risk operating system commands associated with discovery, credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

This rule is intended to identify adversary use of AWS-native management channels to execute post-compromise commands on EC2 workloads.

Behavioral Rationale

Systems Manager Run Command can legitimately execute administrative commands on EC2 instances. In an intrusion, an adversary with sufficient IAM permissions can use the same capability to run commands that resemble endpoint post-compromise behavior. The strongest signal is high-risk command content or suspicious document usage combined with sensitive target context, unexpected principal, non-standard source, or missing support workflow.

This rule is distinct from Rule 1 because it focuses on command intent rather than the fact that Systems Manager remote access occurred. It should be deployed in full-confidence mode only when command parameters, command output, endpoint telemetry, or equivalent command-content visibility is available. Where command content is unavailable, it should operate in reduced-confidence mode using document name, principal, target sensitivity, source location, and workflow deviation.

Primary Telemetry Source

·        AWS CloudTrail management events for Systems Manager.

·        Systems Manager command invocation logs where available.

·        CloudWatch Logs or S3 Systems Manager output logging where configured.

·        Endpoint telemetry where integrated.

·        EC2 instance inventory and tag enrichment.

Required AWS Data Elements

·        Event time.

·        AWS account ID.

·        Region.

·        Event source.

·        Event name.

·        User identity ARN.

·        Assumed role ARN.

·        Source IP address.

·        Request parameters.

·        Systems Manager document name.

·        Command parameters where available.

·        Command output where available.

·        Target instance ID or target tags.

·        EC2 asset criticality.

·        Approved SSM document and command baselines.

Rule Logic Summary

·        Detect SendCommand or StartAutomationExecution.

·        Identify high-risk command patterns where command content is available.

·        Treat sensitive target context, unapproved principal, non-standard source, or missing support workflow as severity amplifiers.

·        Use reduced-confidence mode when command content is unavailable.

·        Exclude approved automation only when principal, source, document, command category, target, and change context match approved workflow.

System-Native Rule Format

AWS CloudTrail Lake SQL / SIEM-ready query logic.

Engineering Implementation Instructions

·        Validate whether command parameters are captured in CloudTrail or available from Systems Manager command output logging in the customer environment.

·        Enable Systems Manager command output logging to CloudWatch Logs or S3 where appropriate and approved.

·        Where command content is unavailable in CloudTrail, correlate Systems Manager activity with endpoint telemetry, EDR, Sysmon, process telemetry, command output logging, or CloudWatch/S3 command-output records.

·        Build approved SSM document baselines, including approved patching, inventory, compliance, deployment, and security operations documents.

·        Build approved command-category baselines for expected administrative activity.

·        Treat shell and PowerShell documents as higher risk when used against restricted workloads or by non-standard principals.

·        Do not suppress AWS-RunShellScript or AWS-RunPowerShellScript globally because those documents can be used legitimately or maliciously.

·        Enrich with endpoint telemetry, VPC Flow Logs, IAM Identity Center context, change records, Systems Manager association data, and asset criticality.

·        If command content is unavailable, deploy this rule in reduced-confidence mode using document name, principal, target sensitivity, source location, and workflow deviation.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted EC2 workloads and high-risk SSM documents. Required customer data includes restricted workload tags, approved SSM admin roles, approved automation roles, approved source locations, and approved SSM documents.

·        Tier 2 deployment: Add approved command categories, source network baselines, target group baselines, and change-control context. Use this tier for production detection of high-risk Systems Manager command activity where command content is visible.

·        Tier 3 deployment: Add Systems Manager command output logging, endpoint telemetry, identity context, asset criticality, and VPC Flow Log enrichment. Use this tier to validate command intent and post-command behavior.

·        Tier 4 deployment: Add centralized CloudTrail Lake, CloudWatch or S3 command-output retention, ticketing integration, session ownership, and cross-account role context. Use this tier for mature multi-account AWS deployment.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require high-risk command behavior, high-risk document use, restricted target scope, or approved-workflow deviation.

·        If the customer lacks command content visibility, keep the rule conditional and prioritize document, principal, target, and workflow mismatch until command telemetry is improved.

Expected False Positives

·        Approved troubleshooting by cloud operations teams.

·        Security operations investigations using Run Command.

·        Patch, configuration, or inventory automation using shell commands.

·        Backup or recovery operations involving administrative commands.

·        Emergency break-glass remediation.

·        Approved scripts not yet represented in the baseline.

False Positive Reduction

·        Baseline approved documents, approved command categories, approved automation roles, approved source locations, and approved target groups.

·        Require high-risk command content, restricted workload scope, unapproved principal, non-standard source, or non-standard workflow.

·        Validate alerts against change records, support tickets, Systems Manager command output, endpoint telemetry, and IAM context.

·        Maintain high severity for credential access, backup interference, defense tampering, data staging, or lateral movement commands.

·        Avoid broad suppression of shell or PowerShell documents.

Known Limitations

·        Command content may not be available in CloudTrail for all environments or configurations.

·        Command output logging may be incomplete or disabled.

·        Approved automation can execute commands that resemble suspicious activity.

·        High-risk command lists require customer tuning.

·        This rule detects AWS-native remote command behavior, not third-party RMM binaries unless endpoint telemetry is integrated.

·        CloudTrail field structure may vary between raw events, CloudTrail Lake, SIEM normalization, and log pipelines.

DRI Score

·        DRI: 8.7

·        Rating: Primary conditional cloud rule

·        Justification: The rule is strongly behavior anchored because it detects high-risk command execution through a cloud-native remote management channel. It is resilient because it focuses on command intent, document usage, target sensitivity, and approved workflow deviation rather than product names. Its score is limited by command-content visibility and baseline maturity.

TCR Score

·        Operational TCR: 7.5

·        Full-Telemetry TCR: 8.9

·        Operational TCR Justification: Operational confidence depends on CloudTrail coverage, command parameter visibility, SSM output logging, EC2 tagging, endpoint telemetry, and approved document baselines. Confidence decreases where command content is unavailable.

·        Full-Telemetry TCR Justification: Confidence improves with complete Systems Manager command logging, CloudTrail Lake coverage, endpoint telemetry, asset criticality, IAM context, VPC Flow Logs, command output retention, and change-control records.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one conditional AWS cloud-native post-compromise command rule.

·        Use as the AWS rule for suspicious Systems Manager command execution.

·        Treat as higher confidence when command content, target sensitivity, and identity context are available.

·        Deploy in reduced-confidence mode if command content is unavailable.

·        Do not claim confirmed high-risk command execution when command parameters, command output, endpoint telemetry, and equivalent command-content visibility are unavailable.

Detection Code

-- AWS Rule 2: High-risk command execution through AWS Systems Manager
-- Deployment note: Full-confidence mode requires command parameters, command output, or endpoint telemetry.
-- Reduced-confidence mode should use document, principal, source, target sensitivity, and workflow deviation.

SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  userIdentity.arn AS user_arn,
  userIdentity.sessionContext.sessionIssuer.arn AS assumed_role_arn,
  sourceIPAddress,
  requestParameters
FROM cloudtrail_events
WHERE eventSource = 'ssm.amazonaws.com'
  AND eventName IN ('SendCommand', 'StartAutomationExecution')
  AND (
    requestParameters LIKE '%AWS-RunShellScript%'
    OR requestParameters LIKE '%AWS-RunPowerShellScript%'
    OR requestParameters LIKE '%AWS-RunRemoteScript%'
  )
  AND (
    LOWER(requestParameters) LIKE '%net user%'
    OR LOWER(requestParameters) LIKE '%net localgroup%'
    OR LOWER(requestParameters) LIKE '%net group%'
    OR LOWER(requestParameters) LIKE '%nltest%'
    OR LOWER(requestParameters) LIKE '%whoami /priv%'
    OR LOWER(requestParameters) LIKE '%vssadmin delete%'
    OR LOWER(requestParameters) LIKE '%wbadmin delete%'
    OR LOWER(requestParameters) LIKE '%bcdedit /set%'
    OR LOWER(requestParameters) LIKE '%reagentc /disable%'
    OR LOWER(requestParameters) LIKE '%wevtutil cl%'
    OR LOWER(requestParameters) LIKE '%auditpol /set%'
    OR LOWER(requestParameters) LIKE '%procdump%'
    OR LOWER(requestParameters) LIKE '%comsvcs.dll%'
    OR LOWER(requestParameters) LIKE '%lsass%'
    OR LOWER(requestParameters) LIKE '%ntds.dit%'
    OR LOWER(requestParameters) LIKE '%rclone%'
    OR LOWER(requestParameters) LIKE '%curl %'
    OR LOWER(requestParameters) LIKE '%wget %'
  );

Reduced-Confidence Deployment Logic

·        Use reduced-confidence mode only when command parameters, command output, endpoint telemetry, and equivalent command-content visibility are unavailable or incomplete.

·        In reduced-confidence mode, do not claim confirmed high-risk command execution.

·        Treat the alert as suspicious AWS-native remote command activity when Systems Manager command activity targets a restricted workload and the principal, role, source, document, workflow, or support context deviates from approved baselines.

·        Require at least one meaningful deviation beyond the existence of Systems Manager command activity.

·        Recommended reduced-confidence conditions include restricted workload plus unapproved principal, restricted workload plus unapproved source, restricted workload plus unusual document, unapproved principal plus unapproved source, or Systems Manager command activity with no approved change or support workflow.

·        Reduced-confidence alerts should be routed for investigation and enrichment rather than treated as confirmed post-compromise command execution.

·        Enrich reduced-confidence alerts with IAM Identity Center logs, endpoint process telemetry, Systems Manager command output logs, GuardDuty findings, VPC Flow Logs, change-management records, and support-ticket context.

·        Where command content later becomes available, reclassify the alert based on whether the command behavior maps to discovery, credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

AWS Rule 3

Systems Manager Access Enablement Followed by Remote Control Activity

Detection Objective

Detect IAM, EC2, or Systems Manager control-plane changes that enable Systems Manager access followed by Systems Manager session or remote command activity against EC2 workloads.

This rule is intended to identify adversary preparation for cloud-native remote control through permission changes, instance profile changes, role attachment, policy modification, or SSM enablement followed by remote access behavior.

Behavioral Rationale

Adversaries may not initially have Systems Manager access to a target EC2 workload. They may modify IAM permissions, attach an instance profile, update role policies, or enable management paths that allow Systems Manager control. When those enablement actions are followed by StartSession, SendCommand, or StartAutomationExecution, the sequence can indicate deliberate preparation for AWS-native remote command execution.

This rule is distinct from Rules 1 and 2 because it detects the setup-to-control sequence that enables remote access, not only remote access activity or command content.

Primary Telemetry Source

·        AWS CloudTrail management events.

·        IAM control-plane activity.

·        EC2 instance profile activity.

·        Systems Manager remote access activity.

·        AWS Config or asset inventory enrichment.

Required AWS Data Elements

·        Event time.

·        AWS account ID.

·        Region.

·        Event source.

·        Event name.

·        User identity ARN.

·        Assumed role ARN.

·        Source IP address.

·        IAM policy or role change details.

·        EC2 instance profile change details.

·        Systems Manager event details.

·        Target instance ID where available.

·        Asset criticality.

·        Approved IAM and EC2 administration baselines.

Rule Logic Summary

·        Stage 1 detects IAM or EC2 changes that can enable Systems Manager access.

·        Stage 2 detects StartSession, SendCommand, or StartAutomationExecution.

·        The production rule must require Stage 1 and Stage 2 within the configured time window.

·        Same-account-only matching is not sufficient for high-confidence production alerting.

·        Same-account matching should be used as a join boundary, not as a strong correlation signal.

·        Stronger correlation should use same principal, same assumed role, same target instance, same instance profile, same restricted workload group, or same approved change workflow where available.

·        Exclude approved automation only when principal, role, change request, target workload, and support workflow match policy.

System-Native Rule Format

AWS CloudTrail Lake SQL / SIEM correlation-ready query logic.

Engineering Implementation Instructions

·        Implement as a two-stage correlation rule where possible, using CloudTrail events as raw telemetry.

·        Stage 1 should detect Systems Manager access enablement actions, including instance profile association, instance profile replacement, IAM policy changes, role attachment, or service-linked access changes relevant to SSM.

·        Stage 2 should detect StartSession, SendCommand, or StartAutomationExecution.

·        Correlate using stronger keys where available, such as same principal, same assumed role, same instance profile, same target instance, same restricted workload group, or same approved change workflow.

·        Use a 24-hour starting correlation window and tune based on normal change and automation patterns.

·        Build approved baselines for IAM administrators, CI/CD roles, infrastructure-as-code roles, SSM administrators, EC2 instance profile workflows, and cloud operations roles.

·        Enrich with AWS Config, CloudTrail Lake, IAM Access Analyzer findings, change-management records, EC2 tags, and endpoint telemetry.

·        Treat this as a high-priority setup-to-control signal when activity involves restricted workloads or non-standard principals.

·        If only same-account correlation is available, keep the rule in hunting or pilot mode until stronger enrichment is available.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted EC2 workloads and high-risk IAM or EC2 changes. Required customer data includes restricted workload tags, approved IAM admin roles, approved infrastructure automation roles, approved instance profiles, approved SSM roles, and approved source locations.

·        Tier 2 deployment: Add change-control context, approved role attachment workflows, expected instance profile mappings, and approved SSM target groups. Use this tier for production alerting on non-standard setup-to-control sequences.

·        Tier 3 deployment: Add AWS Config snapshots, AWS Organizations account metadata, IAM Identity Center context, asset criticality, and VPC Flow Log enrichment. Use this tier to prioritize sensitive workloads and validate unauthorized enablement.

·        Tier 4 deployment: Add centralized CloudTrail Lake, infrastructure-as-code pipeline telemetry, ticketing integration, security account context, endpoint telemetry, and organization-wide asset context. Use this tier for mature multi-account AWS deployment.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require access-enabling control-plane change plus subsequent Systems Manager remote activity.

·        If the customer lacks CloudTrail centralization, EC2 tagging, approved role baselines, or stronger correlation keys, deploy in pilot mode before production alerting.

Expected False Positives

·        Approved infrastructure-as-code role changes.

·        Approved EC2 instance profile updates.

·        Systems Manager onboarding projects.

·        Patch-management or fleet-management automation.

·        Emergency remediation enabling temporary SSM access.

·        Cloud operations changes not represented in the baseline.

False Positive Reduction

·        Baseline approved IAM roles, instance profiles, automation roles, infrastructure-as-code pipelines, source locations, and SSM workflows.

·        Require subsequent Systems Manager remote access or command activity, not just IAM or EC2 change alone.

·        Correlate with change tickets, infrastructure-as-code pipeline records, user identity, target workload role, and asset criticality.

·        Maintain higher severity for restricted EC2 workloads and cross-account role activity.

·        Review newly approved exceptions to avoid suppressing unauthorized access enablement.

Known Limitations

·        Correlation may be difficult if IAM change events and SSM activity do not share a direct target identifier.

·        Infrastructure automation may legitimately perform similar sequences.

·        CloudTrail management event coverage must be centralized across accounts and regions.

·        Asset and role baselines must be maintained.

·        This rule detects AWS-native enablement of remote control, not third-party RMM software.

·        A 24-hour window may require tuning to reduce noise.

·        Same-account-only correlation should remain hunting or pilot mode unless additional correlation keys are available.

DRI Score

·        DRI: 8.4

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects a setup-to-control sequence rather than isolated administrative events. It is resilient because it focuses on AWS-native access enablement followed by remote management activity. Its score is limited by correlation complexity, baseline dependency, and potential overlap with legitimate infrastructure operations.

TCR Score

·        Operational TCR: 7.4

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: Operational confidence depends on centralized CloudTrail, IAM event visibility, EC2 instance profile mapping, asset tagging, approved source baselines, and approved role baselines. Confidence decreases when control-plane changes and target instances cannot be reliably correlated.

·        Full-Telemetry TCR Justification: Confidence improves with CloudTrail Lake, AWS Config, IAM Identity Center context, infrastructure-as-code pipeline telemetry, change records, account metadata, EC2 tags, VPC Flow Logs, and endpoint telemetry.

ATT&CK Mapping

·        T1098 — Account Manipulation.

·        T1078 — Valid Accounts.

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

Rule Disposition

·        Include as one conditional AWS cloud-native setup-to-control rule.

·        Use as the AWS rule for detecting enablement of Systems Manager remote-control capability followed by use.

·        Do not alert on IAM or EC2 changes alone unless paired with subsequent Systems Manager activity or restricted workload context.

·        Deploy only where CloudTrail, asset, IAM, source, and role baselines are sufficiently mature.

·        Keep in hunting or pilot mode if only same-account correlation is available.

Detection Code

-- AWS Rule 3: Systems Manager access enablement followed by remote-control activity
-- Deployment note: Same-account-only correlation is not sufficient for mature production alerting.
-- Production correlation should prefer same principal, same assumed role, same target instance,
-- same instance profile, same restricted workload group, or same approved change workflow where available.

-- Stage 1: SSM access enablement indicators
SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  userIdentity.arn AS user_arn,
  userIdentity.sessionContext.sessionIssuer.arn AS assumed_role_arn,
  sourceIPAddress,
  requestParameters
FROM cloudtrail_events
WHERE
  (
    eventSource = 'iam.amazonaws.com'
    AND eventName IN (
      'AttachRolePolicy',
      'PutRolePolicy',
      'CreatePolicyVersion',
      'AttachUserPolicy',
      'AttachGroupPolicy',
      'UpdateAssumeRolePolicy'
    )
    AND (
      requestParameters LIKE '%AmazonSSMManagedInstanceCore%'
      OR requestParameters LIKE '%ssm:%'
      OR requestParameters LIKE '%ssmmessages:%'
      OR requestParameters LIKE '%ec2messages:%'
    )
  )
  OR
  (
    eventSource = 'ec2.amazonaws.com'
    AND eventName IN (
      'AssociateIamInstanceProfile',
      'ReplaceIamInstanceProfileAssociation'
    )
  );

-- Stage 2: subsequent Systems Manager remote activity
SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  userIdentity.arn AS user_arn,
  userIdentity.sessionContext.sessionIssuer.arn AS assumed_role_arn,
  sourceIPAddress,
  requestParameters
FROM cloudtrail_events
WHERE eventSource = 'ssm.amazonaws.com'
  AND eventName IN ('StartSession', 'SendCommand', 'StartAutomationExecution');

Correlation Logic

·        Rule type: Two-stage CloudTrail correlation rule.

·        Stage 1: Match Systems Manager access enablement indicators.

·        Stage 2: Match Systems Manager remote activity.

·        Correlation requirement: Stage 1 and Stage 2 must occur within 24 hours.

·        Account handling: Same-account matching may be used as a join boundary, but it is not sufficient as the only production correlation key.

·        Strong correlation keys: Same principal, same assumed role, same target instance, same instance profile, same restricted workload group, or same approved change workflow.

·        Hunting mode: Keep the rule in hunting or pilot mode if only same-account correlation is available.

·        Required exclusions: Exclude only when approved change workflow, principal, role, source, target workload, and support context all match.

·        Offense guidance: Create or add to an incident when access enablement is followed by Systems Manager remote activity and at least one strong correlation key is present.

·        Severity guidance: Increase severity for restricted EC2 workloads, privileged roles, cross-account administration, identity systems, backup systems, security tooling, regulated-data systems, and missing approved change context.

AWS Final Disposition

AWS receives 3 audit-passing conditional cloud-native rules for this report. The final AWS rule set covers unauthorized Systems Manager session or remote command activity against restricted EC2 workloads, high-risk command execution through Systems Manager, and Systems Manager access enablement followed by remote-control activity. No additional AWS rules are included because additional concepts would be redundant, lower-confidence, or dependent on customer-specific telemetry conditions.

Azure

Detection Viability Assessment

Azure has moderate detection viability for this report, but only for cloud-native remote management activity, Azure control-plane abuse, and Azure-hosted workload administration paths. Azure should not be treated as a primary detection layer for third-party RMM binaries such as AnyDesk, TeamViewer, ScreenConnect, ConnectWise, Atera, NinjaOne, Syncro, or Splashtop unless endpoint telemetry from Azure VMs, Azure Arc-enabled servers, or Microsoft Defender for Endpoint is integrated into Microsoft Sentinel or another SIEM.

Azure is strongest when detecting abuse of Azure VM Run Command, Azure Arc Run Command, VM extensions, Azure RBAC, managed identities, automation identities, and administrative control-plane changes that enable remote command execution. These cloud-native paths can function like RMM when an adversary has sufficient Azure permissions or compromises an identity with access to remote administration features.

The strongest Azure detections for this report focus on unauthorized remote command initiation, high-risk command execution through Azure-native management paths, and control-plane enablement followed by remote command activity. These detections are conditional because they require Azure Activity logs, Microsoft Sentinel or Log Analytics ingestion, Azure VM or Azure Arc inventory, role assignment baselines, approved administrator baselines, source context, workload criticality tagging, and support-workflow validation.

Azure Rule 1

Unauthorized Azure Run Command Activity Against Restricted Workloads

Detection Objective

Detect Azure VM Run Command or Azure Arc Run Command activity targeting restricted, high-value, or non-administrative workloads by an unapproved principal, unexpected source, external identity path, or non-standard administrative workflow.

This rule is intended to identify cloud-native remote management activity that can provide command-based control of Azure VMs or Azure Arc-enabled servers outside approved operations.

Behavioral Rationale

Azure Run Command and Azure Arc Run Command can provide legitimate administrative access to managed workloads. In an intrusion, the same capability can function as a cloud-native remote control channel if an adversary obtains Azure permissions, compromises an administrator identity, assumes a privileged role, or abuses an automation path.

The strongest signal is not that Run Command was used. The stronger signal is Run Command activity against restricted workloads by identities, sources, roles, or workflows that do not match approved administration. Restricted workload access by an approved caller from an approved source should be monitored and enriched, but it should not automatically be treated as unauthorized without additional approved-scope deviation.

This rule detects cloud-native remote-control behavior through Azure control-plane telemetry. It is distinct from endpoint RMM detections because it focuses on Azure-native management activity rather than third-party RMM binaries.

Primary Telemetry Source

·        Azure Activity logs.

·        Microsoft Sentinel or Log Analytics.

·        Azure VM and Azure Arc resource inventory.

·        Azure RBAC and identity context.

·        Resource tags and asset criticality enrichment.

Required Azure Data Elements

·        TimeGenerated.

·        OperationNameValue.

·        OperationName.

·        ActivityStatusValue.

·        Caller.

·        CallerIpAddress.

·        ResourceId.

·        ResourceGroup.

·        SubscriptionId.

·        ResourceProviderValue.

·        CategoryValue.

·        Properties.

·        Claims or identity fields where available.

·        Resource tags or asset criticality enrichment.

·        Approved administrator and automation identity baselines.

·        Approved source location baselines.

·        Restricted workload inventory.

Rule Logic Summary

·        Detect Azure VM Run Command or Azure Arc Run Command activity.

·        Alert when restricted workload access is paired with an unapproved caller, unapproved source, missing approved workflow, or other approved-scope deviation.

·        Alert on non-restricted workloads only when both caller and source deviate from approved baselines.

·        Exclude approved automation only when caller, role, source, operation, target workload, and change or support workflow match policy.

·        Prioritize activity against domain controllers, identity systems, backup infrastructure, security tooling, privileged access workloads, production servers, regulated-data systems, and cloud management systems.

System-Native Rule Format

Microsoft Sentinel KQL / Azure Monitor Log Analytics query logic.

Engineering Implementation Instructions

·        Validate Azure Activity log ingestion across all relevant subscriptions, resource groups, and tenants before production deployment.

·        Validate operation names for Azure VM Run Command and Azure Arc Run Command in the customer environment because operation naming can vary by resource type, API path, and logging pipeline.

·        Build approved Azure administrator and automation identity baselines, including privileged users, break-glass accounts, managed identities, automation accounts, DevOps identities, cloud operations roles, security operations roles, and approved service principals.

·        Build approved source baselines for administrative access paths.

·        Build restricted workload inventory using tags, CMDB enrichment, Defender for Cloud context, Azure Resource Graph exports, or asset inventory.

·        Do not suppress Azure Run Command globally. Approved Azure-native remote administration can still be abused through compromised accounts, unauthorized role assignment, or non-standard targets.

·        Enrich alerts with Microsoft Entra ID sign-in logs, Azure RBAC role assignment context, Defender for Cloud alerts, Microsoft Defender for Endpoint telemetry, change-management records, and ticket context where available.

·        Treat this rule as a cloud-native remote-control signal. Incident confirmation should evaluate identity compromise, role assignment path, target workload sensitivity, command content where available, and post-command activity.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Azure workloads and prohibited remote-command identities. Required customer data includes restricted workload tags, approved cloud operations identities, approved automation identities, approved source locations, and approved support accounts.

·        Tier 2 deployment: Add approved resource groups, approved workload tags, support-ticket context, change-control context, and approved Run Command workflows. Use this tier for production alerting on non-standard Azure remote command access.

·        Tier 3 deployment: Add asset criticality, subscription tiering, managed identity context, Microsoft Entra ID sign-in context, Defender for Cloud enrichment, and endpoint telemetry. Use this tier to prioritize high-value workloads and distinguish approved administration from suspicious control.

·        Tier 4 deployment: Add centralized Microsoft Sentinel coverage, Azure Resource Graph enrichment, multi-subscription inventory, change-management integration, session ownership, and SIEM correlation with identity and endpoint telemetry. Use this tier for mature enterprise deployment across Azure estates.

·        Tiering changes scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require Azure-native remote command activity plus restricted target, unapproved principal, unapproved source, non-standard workflow, or approved-scope deviation.

·        If the customer lacks restricted workload tagging, approved identity baselines, or approved source baselines, deploy in pilot mode until asset and identity baselines support production alerting.

Expected False Positives

·        Approved administrator troubleshooting through Azure Run Command.

·        Approved automation or repair workflows.

·        Emergency break-glass support activity.

·        Security operations investigation on sensitive workloads.

·        New automation identities not yet represented in the baseline.

·        Cross-subscription administration through approved but undocumented workflows.

False Positive Reduction

·        Baseline approved cloud operations identities, automation identities, source locations, target workload tags, and support workflows.

·        Exclude approved activity only when caller, role, source, operation, target, and support context all match.

·        Maintain high severity for restricted workloads when caller, source, or workflow deviates from baseline.

·        Validate alerts against change records, support tickets, Microsoft Entra ID sign-in logs, and workload ownership context.

·        Review exceptions periodically to avoid converting Azure Run Command into a blanket suppression.

Known Limitations

·        Azure Activity logs may not always expose full script or command content.

·        Operation names and resource identifiers may vary by Azure service, API version, and logging pipeline.

·        Resource tagging and asset inventory quality directly affect prioritization.

·        Approved administration can resemble suspicious remote-control activity without support workflow context.

·        Cross-subscription and service principal activity can complicate identity attribution.

·        This rule does not detect third-party RMM binaries unless endpoint telemetry is forwarded and correlated separately.

DRI Score

·        DRI: 8.5

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects cloud-native remote command activity against restricted workloads by non-standard principals, sources, or workflows. It is resilient because it focuses on Azure-native remote-control behavior rather than third-party RMM product names. Its score is limited by dependence on accurate identity baselines, source baselines, workload tagging, and approved operations context.

TCR Score

·        Operational TCR: 7.8

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: Operational confidence is moderate-to-high where Azure Activity logs, identity context, workload tags, approved source context, and approved role baselines are available. Confidence decreases when target workload inventory, source context, command visibility, or support workflow data is incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with centralized Sentinel ingestion, complete subscription coverage, Azure Resource Graph enrichment, Microsoft Entra ID sign-in logs, Defender for Cloud context, endpoint telemetry, change records, and workload ownership metadata.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

Rule Disposition

·        Include as one conditional Azure cloud-native detection rule.

·        Use as the primary Azure rule for unauthorized remote command activity against Azure VMs and Azure Arc-enabled workloads.

·        Do not treat this rule as standalone proof of compromise without identity, command, workload, session, or endpoint enrichment.

·        Do not suppress Azure Run Command activity globally because approved native administration can still be abused.

Detection Code

// Azure Rule 1: Unauthorized Azure Run Command activity against restricted workloads
// Deployment note: Replace dynamic values with customer-approved identity, source, subscription, and workload baselines.

let Lookback = 24h;
let ApprovedCallers = dynamic([
    "approved.cloudops@example.com",
    "approved.securityops@example.com",
    "approved-automation-spn"
]);
let ApprovedSourceIPs = dynamic([
    "203.0.113.10",
    "203.0.113.11"
]);
let RestrictedResourceIndicators = dynamic([
    "domain-controller",
    "identity",
    "backup",
    "privileged-access",
    "security-tooling",
    "regulated-data",
    "production-critical"
]);
AzureActivity
| where TimeGenerated >= ago(Lookback)
| where ActivityStatusValue =~ "Success" or ActivityStatusValue =~ "Succeeded" or isempty(ActivityStatusValue)
| where OperationNameValue has_any (
    "Microsoft.Compute/virtualMachines/runCommand/action",
    "Microsoft.Compute/virtualMachines/runCommands/write",
    "Microsoft.HybridCompute/machines/runcommands/write",
    "Microsoft.HybridCompute/machines/runcommands/action"
)
or OperationName has_any (
    "Run Command",
    "RunCommand"
)
| extend CallerLower = tolower(tostring(Caller))
| extend ResourceLower = tolower(tostring(ResourceId))
| extend PropertiesText = tolower(tostring(Properties))
| extend IsApprovedCaller = CallerLower in~ (ApprovedCallers)
| extend IsApprovedSource = tostring(CallerIpAddress) in (ApprovedSourceIPs)
| extend IsRestrictedWorkload = ResourceLower has_any (RestrictedResourceIndicators) or PropertiesText has_any (RestrictedResourceIndicators)
| where
    (IsRestrictedWorkload and (IsApprovedCaller == false or IsApprovedSource == false))
    or (IsApprovedCaller == false and IsApprovedSource == false)
| project
    TimeGenerated,
    SubscriptionId,
    ResourceGroup,
    ResourceId,
    OperationNameValue,
    OperationName,
    ActivityStatusValue,
    Caller,
    CallerIpAddress,
    CategoryValue,
    Properties,
    IsRestrictedWorkload,
    IsApprovedCaller,
    IsApprovedSource

Azure Rule 2

High-Risk Command Execution Through Azure Run Command

Detection Objective

Detect Azure VM Run Command or Azure Arc Run Command activity executing high-risk operating system commands associated with discovery, credential access, lateral movement, defense evasion, backup interference, file staging, or ransomware preparation.

This rule is intended to identify adversary use of Azure-native remote command channels to execute post-compromise commands on managed workloads.

Behavioral Rationale

Azure Run Command can legitimately execute administrative scripts on VMs and Arc-enabled servers. In an intrusion, an adversary with sufficient Azure permissions can use the same capability to execute commands that resemble endpoint post-compromise behavior. The strongest signal is high-risk command content or suspicious script intent combined with sensitive target context, unexpected principal, non-standard source, or missing support workflow.

This rule is distinct from Rule 1 because it focuses on command intent rather than the fact that Azure-native remote access occurred. It should be deployed in full-confidence mode only when command content, script parameters, command output logs, VM guest logs, or endpoint telemetry are available. Where command content is unavailable, it should operate in reduced-confidence mode using operation, principal, target sensitivity, source location, and workflow deviation.

Primary Telemetry Source

·        Azure Activity logs.

·        Azure Run Command activity.

·        Log Analytics or Microsoft Sentinel.

·        VM guest logs or command-output logging where available.

·        Microsoft Defender for Endpoint telemetry where integrated.

·        Resource inventory and tag enrichment.

Required Azure Data Elements

·        TimeGenerated.

·        OperationNameValue.

·        OperationName.

·        Caller.

·        CallerIpAddress.

·        ResourceId.

·        SubscriptionId.

·        ResourceGroup.

·        Properties.

·        Command parameters where available.

·        Script content or script reference where available.

·        Target workload tags.

·        Approved command and support workflow baselines.

Rule Logic Summary

·        Detect Azure Run Command activity.

·        Identify high-risk command patterns where command content is available.

·        Treat sensitive target context, unapproved principal, non-standard source, or missing support workflow as severity amplifiers.

·        Use reduced-confidence mode when command content is unavailable.

·        Exclude approved automation only when caller, source, command category, target, and change context match approved workflow.

System-Native Rule Format

Microsoft Sentinel KQL / Azure Monitor Log Analytics query logic.

Engineering Implementation Instructions

·        Validate whether Run Command script content, parameters, or command output are available in Azure Activity logs, Log Analytics, command output destinations, or endpoint telemetry.

·        Where command content is unavailable in control-plane logs, correlate AzureActivity with VM guest logs, Defender for Endpoint process telemetry, Sysmon, or command output logging.

·        Build approved command-category baselines for expected administrative activity.

·        Treat PowerShell, shell script, backup manipulation, credential access, archive staging, and remote transfer commands as higher risk when executed through Azure-native remote management.

·        Do not suppress Run Command globally because it can be used legitimately or maliciously.

·        Enrich with Microsoft Entra ID sign-in context, Defender for Cloud alerts, Defender for Endpoint telemetry, Azure Resource Graph, change records, and workload ownership metadata.

·        If command content is unavailable, deploy this rule in reduced-confidence mode using operation type, principal, target sensitivity, source location, and workflow deviation.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Azure workloads and high-risk Run Command activity. Required customer data includes restricted workload tags, approved cloud operations identities, approved automation identities, and approved remote command workflows.

·        Tier 2 deployment: Add approved command categories, source location baselines, target workload groups, and change-control context. Use this tier for production detection of high-risk Azure remote command activity where command content is visible.

·        Tier 3 deployment: Add VM guest logs, Defender for Endpoint telemetry, identity context, asset criticality, command output logging, and network enrichment. Use this tier to validate command intent and post-command behavior.

·        Tier 4 deployment: Add centralized Sentinel ingestion, Azure Resource Graph, command-output retention, ticketing integration, workload ownership, and multi-subscription identity context. Use this tier for mature Azure deployment.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require high-risk command behavior, restricted target scope, or approved-workflow deviation.

·        If the customer lacks command content visibility, keep this rule conditional and prioritize documented operation, principal, target, and workflow mismatch until command telemetry is improved.

Expected False Positives

·        Approved troubleshooting by cloud operations teams.

·        Security operations investigations using Run Command.

·        Patch, configuration, repair, or inventory automation.

·        Backup or recovery operations involving administrative commands.

·        Emergency break-glass remediation.

·        Approved scripts not yet represented in the baseline.

False Positive Reduction

·        Baseline approved commands, approved automation identities, approved workload groups, and approved support workflows.

·        Require high-risk command content, restricted workload scope, unapproved principal, or non-standard workflow.

·        Validate alerts against change records, support tickets, VM guest telemetry, and endpoint telemetry.

·        Maintain high severity for credential access, backup interference, defense tampering, data staging, or lateral movement commands.

·        Avoid broad suppression of PowerShell, shell, or Azure Run Command operations.

Known Limitations

·        Command content may not always be available in Azure Activity logs.

·        VM guest logging or Defender for Endpoint telemetry may be required for full confidence.

·        Approved automation can execute commands that resemble suspicious activity.

·        High-risk command lists require customer tuning.

·        This rule detects Azure-native remote command behavior, not third-party RMM binaries unless endpoint telemetry is integrated.

·        Log structure may vary between Azure Activity, Log Analytics, Microsoft Sentinel, and downstream SIEM pipelines.

DRI Score

·        DRI: 8.6

·        Rating: Primary conditional cloud rule

·        Justification: The rule is strongly behavior anchored because it detects high-risk command execution through a cloud-native remote management channel. It is resilient because it focuses on command intent, target sensitivity, identity context, and approved workflow deviation rather than RMM product names. Its score is limited by command-content visibility and baseline maturity.

TCR Score

·        Operational TCR: 7.4

·        Full-Telemetry TCR: 8.8

·        Operational TCR Justification: Operational confidence depends on Azure Activity coverage, command parameter visibility, VM guest logging, endpoint telemetry, workload tagging, and approved command baselines. Confidence decreases where command content is unavailable.

·        Full-Telemetry TCR Justification: Confidence improves with complete Azure Activity ingestion, command output logging, Defender for Endpoint telemetry, VM guest telemetry, resource tags, Microsoft Entra ID context, network telemetry, and change-control records.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Rule Disposition

·        Include as one conditional Azure cloud-native post-compromise command rule.

·        Use as the Azure rule for suspicious Run Command command execution.

·        Treat as higher confidence when command content, target sensitivity, and identity context are available.

·        Deploy in reduced-confidence mode if command content is unavailable.

·        Do not claim confirmed high-risk command execution when command content, script parameters, command output, VM guest logs, and endpoint process telemetry are unavailable.

Detection Code

// Azure Rule 2: High-risk command execution through Azure Run Command
// Full-confidence mode requires command content, script parameters, command output, or endpoint telemetry.
// Reduced-confidence mode should use operation, principal, source, target sensitivity, and workflow deviation.

let Lookback = 24h;
let HighRiskCommandTerms = dynamic([
    "net user",
    "net localgroup",
    "net group",
    "nltest",
    "dsquery",
    "setspn",
    "whoami /priv",
    "quser",
    "qwinsta",
    "psexec",
    "wmic",
    "winrs",
    "schtasks /s",
    "vssadmin delete",
    "wbadmin delete",
    "bcdedit /set",
    "reagentc /disable",
    "wevtutil cl",
    "auditpol /set",
    "procdump",
    "comsvcs.dll",
    "lsass",
    "ntds.dit",
    "rclone",
    "curl ",
    "wget ",
    "7z",
    "rar"
]);
AzureActivity
| where TimeGenerated >= ago(Lookback)
| where ActivityStatusValue =~ "Success" or ActivityStatusValue =~ "Succeeded" or isempty(ActivityStatusValue)
| where OperationNameValue has_any (
    "Microsoft.Compute/virtualMachines/runCommand/action",
    "Microsoft.Compute/virtualMachines/runCommands/write",
    "Microsoft.HybridCompute/machines/runcommands/write",
    "Microsoft.HybridCompute/machines/runcommands/action"
)
or OperationName has_any (
    "Run Command",
    "RunCommand"
)
| extend PropertiesText = tolower(tostring(Properties))
| extend HasHighRiskCommandContent = PropertiesText has_any (HighRiskCommandTerms)
| extend UsesRemoteCommandOperation = true
| where HasHighRiskCommandContent
| project
    TimeGenerated,
    SubscriptionId,
    ResourceGroup,
    ResourceId,
    OperationNameValue,
    OperationName,
    ActivityStatusValue,
    Caller,
    CallerIpAddress,
    Properties,
    HasHighRiskCommandContent

Reduced-Confidence Deployment Logic

·        Use reduced-confidence mode only when command content, script parameters, command output, VM guest logs, and endpoint process telemetry are unavailable or incomplete.

·        In reduced-confidence mode, do not claim confirmed high-risk command execution.

·        Treat the alert as suspicious Azure-native remote command activity when Run Command targets a restricted workload and the caller, source, workflow, role, or support context deviates from approved baselines.

·        Require at least one meaningful deviation beyond the existence of Run Command activity.

·        Recommended reduced-confidence conditions include restricted workload plus unapproved caller, restricted workload plus unapproved source, unapproved caller plus unapproved source, or Run Command activity with no approved change or support workflow.

·        Reduced-confidence alerts should be routed for investigation and enrichment rather than treated as confirmed post-compromise command execution.

·        Enrich reduced-confidence alerts with Microsoft Entra ID sign-in logs, Defender for Endpoint process telemetry, VM guest logs, Defender for Cloud alerts, Azure Resource Graph, change-management records, and support-ticket context.

·        Where command content later becomes available, reclassify the alert based on whether the command behavior maps to discovery, credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

Azure Rule 3

Remote Command Enablement Followed by Azure Run Command Activity

Detection Objective

Detect Azure RBAC, VM extension, managed identity, automation, or control-plane changes that enable remote command execution followed by Azure Run Command activity against Azure VMs or Azure Arc-enabled workloads.

This rule is intended to identify adversary preparation for cloud-native remote control through permission changes, identity changes, extension changes, automation-path setup, or management-plane setup followed by remote command behavior.

Behavioral Rationale

Adversaries may not initially have direct Run Command access to a target workload. They may assign roles, update permissions, modify managed identities, deploy or modify extensions, alter automation paths, or otherwise create a management path that enables remote command execution. When those enablement actions are followed by Run Command activity, the sequence can indicate deliberate preparation for cloud-native remote control.

This rule is distinct from Rules 1 and 2 because it detects the setup-to-control sequence rather than only the remote command activity or the command content.

Primary Telemetry Source

·        Azure Activity logs.

·        Microsoft Sentinel or Log Analytics.

·        Azure RBAC activity.

·        VM extension activity.

·        Managed identity activity.

·        Azure Resource Manager control-plane events.

·        Resource inventory and tag enrichment.

Required Azure Data Elements

·        TimeGenerated.

·        OperationNameValue.

·        OperationName.

·        Caller.

·        CallerIpAddress.

·        ResourceId.

·        SubscriptionId.

·        ResourceGroup.

·        ActivityStatusValue.

·        Properties.

·        Target resource identity.

·        Role assignment or policy change details.

·        Extension change details.

·        Workload criticality tags.

·        Approved identity, automation, and change baselines.

Rule Logic Summary

·        Stage 1 detects Azure control-plane actions that may enable remote command or management access.

·        Stage 2 detects Azure Run Command activity.

·        The production rule must require Stage 1 and Stage 2 within the configured time window.

·        Same-subscription-only matching is not sufficient for high-confidence production alerting.

·        Stronger correlation should use same caller, same resource group, same resource identity family, same managed identity, same target workload group, or same approved change workflow where available.

·        Exclude approved automation only when principal, role, change request, target workload, and support workflow match policy.

System-Native Rule Format

Microsoft Sentinel KQL / Azure Monitor Log Analytics sequence-correlation logic.

Engineering Implementation Instructions

·        Implement as a two-stage KQL correlation rule where possible.

·        Stage 1 should detect access-enabling actions such as role assignment changes, policy assignment changes, managed identity changes, VM extension writes, automation account changes, or deployment activity relevant to remote command access.

·        Stage 2 should detect Azure VM Run Command or Azure Arc Run Command activity.

·        Correlate using stronger keys where available, such as same caller, same resource, same resource group, same subscription plus same caller, same managed identity, same target workload group, or same change workflow.

·        Use a 24-hour starting correlation window and tune based on normal infrastructure automation patterns.

·        Build approved baselines for Azure administrators, CI/CD identities, infrastructure-as-code roles, managed identities, automation accounts, security operations identities, and cloud operations roles.

·        Enrich with Azure Resource Graph, Microsoft Entra ID sign-in logs, Defender for Cloud, Defender for Endpoint, change-management records, and resource tags.

·        Treat this as a high-priority setup-to-control signal when activity involves restricted workloads or non-standard principals.

·        If only same-subscription correlation is available, keep the rule in pilot or hunting mode until stronger enrichment is available.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Azure workloads and high-risk control-plane changes. Required customer data includes restricted workload tags, approved Azure administrators, approved infrastructure automation identities, approved managed identities, and approved Run Command workflows.

·        Tier 2 deployment: Add change-control context, approved role assignment workflows, approved VM extension workflows, expected managed identity mappings, and approved workload groups. Use this tier for production alerting on non-standard setup-to-control sequences.

·        Tier 3 deployment: Add Azure Resource Graph enrichment, Microsoft Entra ID context, asset criticality, Defender for Cloud context, and endpoint telemetry. Use this tier to prioritize sensitive workloads and validate unauthorized enablement.

·        Tier 4 deployment: Add centralized Sentinel analytics, infrastructure-as-code pipeline telemetry, ticketing integration, multi-subscription metadata, security account context, and workload ownership data. Use this tier for mature Azure estates.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require access-enabling control-plane change plus subsequent Azure-native remote command activity.

·        If the customer lacks Azure Activity centralization, resource tagging, or approved identity baselines, deploy in pilot mode before production alerting.

Expected False Positives

·        Approved infrastructure-as-code role changes.

·        Approved VM extension deployment or repair.

·        Approved managed identity updates.

·        Run Command onboarding projects.

·        Patch-management or fleet-management automation.

·        Emergency remediation enabling temporary access.

·        Cloud operations changes not represented in the baseline.

False Positive Reduction

·        Baseline approved Azure roles, managed identities, automation accounts, infrastructure-as-code pipelines, VM extension workflows, and Run Command workflows.

·        Require subsequent Azure Run Command activity, not just RBAC, identity, deployment, or extension change alone.

·        Correlate with change tickets, IaC pipeline records, caller identity, target workload role, and asset criticality.

·        Maintain higher severity for restricted workloads and cross-subscription administrative activity.

·        Review newly approved exceptions to avoid suppressing unauthorized remote access enablement.

Known Limitations

·        Correlation may be difficult if access-enabling events and Run Command activity do not share a direct target identifier.

·        Infrastructure automation may legitimately perform similar sequences.

·        Azure Activity coverage must be centralized across relevant subscriptions and tenants.

·        Resource and identity baselines must be maintained.

·        This rule detects Azure-native enablement of remote control, not third-party RMM software.

·        A 24-hour window may require tuning to reduce noise.

DRI Score

·        DRI: 8.4

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects a setup-to-control sequence rather than isolated administrative events. It is resilient because it focuses on Azure-native access enablement followed by remote command activity. Its score is limited by correlation complexity, baseline dependency, and potential overlap with legitimate infrastructure operations.

TCR Score

·        Operational TCR: 7.4

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: Operational confidence depends on centralized Azure Activity logs, RBAC event visibility, resource identity mapping, workload tagging, and approved identity baselines. Confidence decreases when control-plane changes and target workloads cannot be reliably correlated.

·        Full-Telemetry TCR Justification: Confidence improves with centralized Sentinel coverage, Azure Resource Graph, Microsoft Entra ID context, infrastructure-as-code telemetry, change records, subscription metadata, resource tags, Defender for Cloud, and endpoint telemetry.

ATT&CK Mapping

·        T1098 — Account Manipulation.

·        T1078 — Valid Accounts.

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

Rule Disposition

·        Include as one conditional Azure cloud-native setup-to-control rule.

·        Use as the Azure rule for detecting enablement of remote command capability followed by use.

·        Do not alert on RBAC, identity, extension, or control-plane changes alone unless paired with subsequent Azure Run Command activity or restricted workload context.

·        Deploy only where Azure Activity, asset, identity, and role baselines are sufficiently mature.

·        Keep in hunting or pilot mode if only same-subscription correlation is available.

Detection Code

// Azure Rule 3: Remote command enablement followed by Azure Run Command activity
// Deployment note: This query requires stronger correlation than same-subscription-only matching.
// Production correlation should prefer same caller, same resource group, same resource identity family,
// same managed identity, same target workload group, or same approved change workflow where available.

let Lookback = 24h;
let EnablementEvents =
    AzureActivity
    | where TimeGenerated >= ago(Lookback)
    | where ActivityStatusValue =~ "Success" or ActivityStatusValue =~ "Succeeded" or isempty(ActivityStatusValue)
    | where OperationNameValue has_any (
        "Microsoft.Authorization/roleAssignments/write",
        "Microsoft.Authorization/roleDefinitions/write",
        "Microsoft.ManagedIdentity/userAssignedIdentities/write",
        "Microsoft.Compute/virtualMachines/extensions/write",
        "Microsoft.HybridCompute/machines/extensions/write",
        "Microsoft.Automation/automationAccounts/write",
        "Microsoft.Resources/deployments/write"
    )
    or OperationName has_any (
        "Create role assignment",
        "Update role assignment",
        "Create or Update Virtual Machine Extension",
        "Create or Update User Assigned Identity",
        "Create Deployment"
    )
    | extend EnablementTime = TimeGenerated
    | extend EnablementCaller = tolower(tostring(Caller))
    | extend EnablementResourceGroup = tolower(tostring(ResourceGroup))
    | extend EnablementSubscription = tostring(SubscriptionId)
    | extend EnablementResourceId = tolower(tostring(ResourceId))
    | extend EnablementResourceBase = tostring(split(tolower(tostring(ResourceId)), "/providers/")[0])
    | project
        EnablementTime,
        EnablementSubscription,
        EnablementResourceGroup,
        EnablementResourceId,
        EnablementResourceBase,
        EnablementCaller,
        EnablementOperation = OperationNameValue,
        EnablementCallerIp = CallerIpAddress,
        EnablementProperties = Properties;
let RunCommandEvents =
    AzureActivity
    | where TimeGenerated >= ago(Lookback)
    | where ActivityStatusValue =~ "Success" or ActivityStatusValue =~ "Succeeded" or isempty(ActivityStatusValue)
    | where OperationNameValue has_any (
        "Microsoft.Compute/virtualMachines/runCommand/action",
        "Microsoft.Compute/virtualMachines/runCommands/write",
        "Microsoft.HybridCompute/machines/runcommands/write",
        "Microsoft.HybridCompute/machines/runcommands/action"
    )
    or OperationName has_any (
        "Run Command",
        "RunCommand"
    )
    | extend RunCommandTime = TimeGenerated
    | extend RunCommandCaller = tolower(tostring(Caller))
    | extend RunCommandResourceGroup = tolower(tostring(ResourceGroup))
    | extend RunCommandSubscription = tostring(SubscriptionId)
    | extend RunCommandResourceId = tolower(tostring(ResourceId))
    | extend RunCommandResourceBase = tostring(split(tolower(tostring(ResourceId)), "/providers/")[0])
    | project
        RunCommandTime,
        RunCommandSubscription,
        RunCommandResourceGroup,
        RunCommandResourceId,
        RunCommandResourceBase,
        RunCommandCaller,
        RunCommandOperation = OperationNameValue,
        RunCommandCallerIp = CallerIpAddress,
        RunCommandProperties = Properties;
EnablementEvents
| join kind=inner RunCommandEvents on $left.EnablementSubscription == $right.RunCommandSubscription
| where RunCommandTime between (EnablementTime .. EnablementTime + Lookback)
| extend SameCaller = EnablementCaller == RunCommandCaller
| extend SameResourceGroup = EnablementResourceGroup == RunCommandResourceGroup
| extend SameResourceFamily =
    EnablementResourceBase == RunCommandResourceBase
    or EnablementResourceId == RunCommandResourceId
| extend StrongCorrelation = SameCaller or SameResourceGroup or SameResourceFamily
| where StrongCorrelation
| project
    EnablementTime,
    RunCommandTime,
    EnablementSubscription,
    EnablementResourceGroup,
    RunCommandResourceGroup,
    EnablementCaller,
    RunCommandCaller,
    EnablementOperation,
    RunCommandOperation,
    EnablementCallerIp,
    RunCommandCallerIp,
    EnablementResourceId,
    RunCommandResourceId,
    SameCaller,
    SameResourceGroup,
    SameResourceFamily,
    StrongCorrelation,
    EnablementProperties,
    RunCommandProperties

Azure Final Disposition

Azure receives 3 audit-passing conditional cloud-native rules for this report. The final Azure rule set covers unauthorized Azure Run Command activity against restricted workloads, high-risk command execution through Azure Run Command, and remote command enablement followed by Azure Run Command activity. No additional Azure rules are included because additional concepts would be redundant, lower-confidence, or dependent on customer-specific telemetry conditions.

GCP

Detection Viability Assessment

GCP has moderate detection viability for this report, but only for cloud-native remote management activity, Compute Engine control-plane abuse, VM Manager abuse, metadata-based execution, and access-enablement pathways. GCP should not be treated as a primary detection layer for third-party RMM binaries such as AnyDesk, TeamViewer, ScreenConnect, ConnectWise, Atera, NinjaOne, Syncro, or Splashtop unless endpoint telemetry from Compute Engine workloads is forwarded into Chronicle, Google Security Operations, BigQuery, Security Command Center integrations, or another SIEM.

GCP is strongest when detecting abuse of VM Manager, OS Config, OS policy assignments, patch jobs, Compute Engine metadata, startup scripts, SSH key metadata, OS Login-related access, serial console access, IAM policy changes, and service-account permission changes. These cloud-native mechanisms can function like remote management pathways when an adversary has sufficient IAM permissions or compromises an identity with administrative access to Compute Engine resources.

The strongest GCP detections for this report focus on unauthorized VM Manager or OS Config activity against restricted workloads, suspicious startup-script or metadata modification that enables execution or persistence, and control-plane access enablement followed by remote management activity. These detections are conditional because they require Cloud Audit Logs, Compute Engine asset inventory, VM labels or tags, IAM baselines, approved administrator baselines, service-account context, workload criticality enrichment, and support-workflow validation.

GCP Rule 1

Unauthorized VM Manager or OS Config Activity Against Restricted Compute Workloads

Detection Objective

Detect Google Cloud VM Manager, OS Config, OS policy assignment, or patch activity targeting restricted, high-value, or non-administrative Compute Engine workloads by an unapproved principal, unexpected service account, non-standard source, or non-standard administrative workflow.

This rule is intended to identify cloud-native remote management activity that can alter software configuration, execute maintenance workflows, or modify workload state outside approved operations.

Behavioral Rationale

VM Manager and OS Config provide legitimate administrative capabilities for Compute Engine workloads, including inventory, patching, and OS policy management. In an intrusion, these same capabilities can be abused to alter workload configuration, push software, run maintenance actions, or establish an administrative pathway similar to cloud-native RMM.

The strongest signal is not that VM Manager or OS Config was used. The stronger signal is VM Manager or OS Config activity against restricted workloads by identities, service accounts, sources, or workflows that do not match approved administration. Restricted workload activity by approved principals from approved sources should be monitored and enriched, but it should not automatically be treated as unauthorized without additional approved-scope deviation.

This rule detects cloud-native remote-management behavior through GCP control-plane telemetry and is distinct from endpoint RMM detections because it focuses on GCP-native management activity rather than third-party RMM binaries.

Primary Telemetry Source

·        Google Cloud Audit Logs.

·        VM Manager and OS Config audit logs.

·        Compute Engine instance inventory.

·        IAM identity and service-account context.

·        Resource labels, tags, folders, projects, and asset criticality enrichment.

Required GCP Data Elements

·        Timestamp.

·        Project ID.

·        Resource name.

·        Resource type.

·        Method name.

·        Principal email.

·        Service account delegation information where available.

·        Caller IP address where available.

·        Request metadata.

·        Request parameters or proto payload.

·        Target instance, zone, project, label, or policy assignment scope.

·        VM labels, tags, folder, or project metadata.

·        Approved administrator and automation identity baselines.

·        Approved source baselines.

·        Restricted workload inventory.

Rule Logic Summary

·        Detect OS Config, VM Manager, OS policy assignment, or patch-management activity.

·        Alert when restricted workload scope is paired with an unapproved principal, unapproved service account, unapproved source, missing approved workflow, or approved-scope deviation.

·        Alert on non-restricted workloads only when principal and source deviate from approved baselines.

·        Exclude approved automation only when principal, service account, source, operation, target workload, and change or support workflow match policy.

·        Prioritize activity against identity systems, backup infrastructure, security tooling, privileged access workloads, production servers, regulated-data systems, and cloud management systems.

System-Native Rule Format

Google Cloud Logging / BigQuery SQL-ready query logic.

Engineering Implementation Instructions

·        Validate Cloud Audit Log coverage for OS Config, VM Manager, Compute Engine, and IAM activity across all relevant projects, folders, and organizations.

·        Validate method names in the customer environment because OS Config and VM Manager method naming can vary by API path, log sink, and SIEM normalization.

·        Build approved GCP administrator and automation identity baselines, including privileged users, break-glass identities, service accounts, CI/CD identities, infrastructure-as-code identities, cloud operations groups, and security operations identities.

·        Build approved source baselines for administrative access paths.

·        Build restricted Compute Engine workload inventory using labels, tags, folders, projects, CMDB enrichment, Security Command Center context, or asset inventory.

·        Do not suppress OS Config or VM Manager activity globally. Approved cloud-native administration can still be abused through compromised accounts, unauthorized service-account use, or non-standard targets.

·        Enrich alerts with IAM policy history, service-account key activity, Identity-Aware Proxy logs where available, Security Command Center findings, endpoint telemetry, change-management records, and ticket context.

·        Treat this rule as a cloud-native remote-management signal. Incident confirmation should evaluate identity compromise, service-account delegation path, target workload sensitivity, policy or patch content, and post-action activity.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Compute Engine workloads and prohibited remote-management identities. Required customer data includes restricted workload labels, approved cloud operations identities, approved automation identities, approved service accounts, approved source locations, and approved support accounts.

·        Tier 2 deployment: Add approved projects, folders, labels, target groups, support-ticket context, change-control context, and approved VM Manager or OS Config workflows. Use this tier for production alerting on non-standard GCP remote-management access.

·        Tier 3 deployment: Add asset criticality, organization and folder context, service-account delegation context, identity context, Security Command Center enrichment, and endpoint telemetry. Use this tier to prioritize high-value workloads and distinguish approved administration from suspicious control.

·        Tier 4 deployment: Add centralized log sinks, BigQuery-backed detection, Cloud Asset Inventory enrichment, multi-project inventory, change-management integration, service-account ownership, and SIEM correlation with identity and endpoint telemetry. Use this tier for mature enterprise deployment across GCP estates.

·        Tiering changes scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require GCP-native remote-management activity plus restricted target, unapproved principal, unapproved service account, unapproved source, non-standard workflow, or approved-scope deviation.

·        If the customer lacks restricted workload labeling, approved identity baselines, approved source baselines, or approved service-account baselines, deploy in pilot mode until asset and identity baselines support production alerting.

Expected False Positives

·        Approved VM Manager patching or OS policy activity.

·        Approved cloud operations maintenance.

·        Approved fleet-management or compliance automation.

·        Security operations investigation on sensitive workloads.

·        New automation service accounts not yet represented in the baseline.

·        Cross-project administration through approved but undocumented workflows.

False Positive Reduction

·        Baseline approved cloud operations identities, automation service accounts, source locations, workload labels, and support workflows.

·        Exclude approved activity only when principal, service account, source, operation, target, and support context all match.

·        Maintain high severity for restricted workloads when principal, service account, source, or workflow deviates from baseline.

·        Validate alerts against change records, support tickets, IAM policy history, and workload ownership context.

·        Review exceptions periodically to avoid converting VM Manager or OS Config into a blanket suppression.

Known Limitations

·        Method names and request fields may vary across Cloud Audit Logs, BigQuery sinks, Chronicle, and downstream SIEM pipelines.

·        OS policy or patch content may require deeper inspection of request payloads or related resources.

·        Resource labeling and asset inventory quality directly affect prioritization.

·        Approved administration can resemble suspicious remote-management activity without support workflow context.

·        Cross-project and service-account activity can complicate identity attribution.

·        This rule does not detect third-party RMM binaries unless endpoint telemetry is forwarded and correlated separately.

DRI Score

·        DRI: 8.4

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects cloud-native remote-management activity against restricted workloads by non-standard principals, service accounts, sources, or workflows. It is resilient because it focuses on GCP-native management behavior rather than third-party RMM product names. Its score is limited by dependence on accurate identity baselines, service-account baselines, source baselines, workload labeling, and approved operations context.

TCR Score

·        Operational TCR: 7.7

·        Full-Telemetry TCR: 8.7

·        Operational TCR Justification: Operational confidence is moderate-to-high where Cloud Audit Logs, identity context, workload labels, service-account context, approved source context, and approved workflow baselines are available. Confidence decreases when target workload inventory, request payload detail, source context, or support workflow data is incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with centralized log sinks, BigQuery or Chronicle enrichment, complete project and folder coverage, Cloud Asset Inventory, IAM policy history, Security Command Center context, endpoint telemetry, change records, and workload ownership metadata.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

Rule Disposition

·        Include as one conditional GCP cloud-native detection rule.

·        Use as the primary GCP rule for unauthorized VM Manager or OS Config activity against Compute Engine workloads.

·        Do not treat this rule as standalone proof of compromise without identity, request-content, workload, session, or endpoint enrichment.

·        Do not suppress VM Manager or OS Config activity globally because approved native administration can still be abused.

Detection Code

-- GCP Rule 1: Unauthorized VM Manager or OS Config activity against restricted Compute workloads
-- Deployment note: Replace placeholder values with customer-approved identity, service-account, source, project, and workload baselines.

DECLARE lookback_hours INT64 DEFAULT 24;

WITH approved_principals AS (
  SELECT principal FROM UNNEST([
    'approved.cloudops@example.com',
    'approved.securityops@example.com',
    'approved-automation-sa@PROJECT_ID.iam.gserviceaccount.com'
  ]) AS principal
),
approved_source_ips AS (
  SELECT source_ip FROM UNNEST([
    '203.0.113.10',
    '203.0.113.11'
  ]) AS source_ip
),
restricted_indicators AS (
  SELECT indicator FROM UNNEST([
    'domain-controller',
    'identity',
    'backup',
    'privileged-access',
    'security-tooling',
    'regulated-data',
    'production-critical'
  ]) AS indicator
),
candidate_events AS (
  SELECT
    timestamp,
    resource.type AS resource_type,
    resource.labels.project_id AS project_id,
    protoPayload.methodName AS method_name,
    protoPayload.authenticationInfo.principalEmail AS principal_email,
    protoPayload.requestMetadata.callerIp AS caller_ip,
    protoPayload.resourceName AS resource_name,
    TO_JSON_STRING(protoPayload.request) AS request_json,
    TO_JSON_STRING(protoPayload.metadata) AS metadata_json
  FROM `PROJECT_ID.DATASET_ID.cloudaudit_googleapis_com_activity_*`
  WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_hours HOUR)
    AND (
      protoPayload.serviceName LIKE '%osconfig.googleapis.com%'
      OR protoPayload.methodName LIKE '%OSPolicy%'
      OR protoPayload.methodName LIKE '%Patch%'
      OR protoPayload.methodName LIKE '%osconfig%'
    )
)
SELECT
  timestamp,
  resource_type,
  project_id,
  method_name,
  principal_email,
  caller_ip,
  resource_name,
  request_json,
  metadata_json,
  is_restricted_workload,
  is_approved_principal,
  is_approved_source
FROM (
  SELECT
    *,
    EXISTS (
      SELECT 1
      FROM restricted_indicators
      WHERE LOWER(resource_name) LIKE CONCAT('%', indicator, '%')
         OR LOWER(request_json) LIKE CONCAT('%', indicator, '%')
         OR LOWER(metadata_json) LIKE CONCAT('%', indicator, '%')
    ) AS is_restricted_workload,
    LOWER(principal_email) IN (
      SELECT LOWER(principal) FROM approved_principals
    ) AS is_approved_principal,
    caller_ip IN (
      SELECT source_ip FROM approved_source_ips
    ) AS is_approved_source
  FROM candidate_events
)
WHERE
  (
    is_restricted_workload
    AND (is_approved_principal = FALSE OR is_approved_source = FALSE)
  )
  OR
  (
    is_restricted_workload = FALSE
    AND is_approved_principal = FALSE
    AND is_approved_source = FALSE
  );

GCP Rule 2

Suspicious Startup Script or Metadata-Based Execution Against Compute Engine Workloads

Detection Objective

Detect Compute Engine metadata changes that introduce or modify startup scripts, Windows startup scripts, SSH keys, OS Login-related access behavior, or serial console enablement against restricted or high-value workloads outside approved administrative workflows.

This rule is intended to identify adversary use of Compute Engine metadata as a cloud-native execution, persistence, or remote-access pathway.

Behavioral Rationale

Compute Engine startup scripts can run commands when a VM boots, and instance or project metadata can influence access and behavior for Compute Engine workloads. In an intrusion, an adversary with sufficient permissions may modify metadata to add startup scripts, alter SSH access paths, enable serial console access, or create execution that runs on reboot.

The strongest signal is not metadata modification alone. The stronger signal is high-risk metadata modification affecting startup execution, SSH access, OS Login behavior, or serial console access on restricted workloads by identities, service accounts, sources, or workflows that do not match approved administration.

This rule is distinct from Rule 1 because it focuses on metadata-driven execution and access persistence rather than VM Manager or OS Config management activity.

Primary Telemetry Source

·        Google Cloud Audit Logs.

·        Compute Engine audit logs.

·        Compute Engine instance and project metadata changes.

·        IAM identity and service-account context.

·        Resource labels, tags, projects, folders, and workload criticality enrichment.

Required GCP Data Elements

·        Timestamp.

·        Project ID.

·        Resource name.

·        Resource type.

·        Method name.

·        Principal email.

·        Service account delegation information where available.

·        Caller IP address where available.

·        Request metadata.

·        Request payload or metadata keys.

·        Target instance or project metadata scope.

·        VM labels, tags, folder, or project metadata.

·        Approved metadata-management baselines.

·        Approved source baselines.

·        Restricted workload inventory.

Rule Logic Summary

·        Detect Compute Engine metadata modifications.

·        Identify metadata keys or request content related to startup scripts, Windows startup scripts, SSH keys, OS Login behavior, serial console access, or execution-enabling configuration.

·        Alert when high-risk metadata changes affect restricted workloads and are performed by unapproved principals, unapproved service accounts, unapproved sources, or non-standard workflows.

·        Alert on non-restricted workloads only when both principal and source deviate from approved baselines.

·        Exclude approved automation only when principal, service account, source, metadata key, target workload, and change context match approved workflow.

System-Native Rule Format

Google Cloud Logging / BigQuery SQL-ready query logic.

Engineering Implementation Instructions

·        Validate Cloud Audit Log coverage for Compute Engine metadata modifications across projects, folders, and organizations.

·        Validate method names for instance metadata and project metadata changes in the customer environment.

·        Build approved baselines for metadata administration, startup-script deployment, OS Login configuration, SSH-key management, serial console use, infrastructure-as-code pipelines, and break-glass workflows.

·        Build approved source baselines for metadata-management access paths.

·        Build restricted Compute Engine workload inventory using labels, tags, folder structure, project naming, CMDB enrichment, or asset inventory.

·        Do not suppress metadata changes globally. Legitimate infrastructure automation can be compromised or misused.

·        Prioritize startup-script changes, SSH key metadata changes, OS Login-related changes, and serial console enablement on restricted workloads.

·        Enrich alerts with IAM policy changes, service-account activity, Identity-Aware Proxy logs where available, Security Command Center findings, endpoint telemetry, VM boot events, serial console audit logs, and change-management records.

·        Treat this rule as a cloud-native execution or access-persistence signal. Incident confirmation should evaluate who made the change, what metadata changed, whether the VM rebooted, whether the script executed, and whether follow-on activity occurred.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Compute Engine workloads and prohibited metadata-management identities. Required customer data includes restricted workload labels, approved cloud operations identities, approved automation service accounts, approved metadata workflows, and approved source locations.

·        Tier 2 deployment: Add approved startup-script workflows, approved SSH access workflows, OS Login policy baselines, serial console policy baselines, support-ticket context, and change-control context. Use this tier for production alerting on suspicious metadata-based execution or access enablement.

·        Tier 3 deployment: Add asset criticality, organization and folder context, IAM policy history, service-account context, Security Command Center enrichment, and endpoint telemetry. Use this tier to validate execution risk and target criticality.

·        Tier 4 deployment: Add centralized audit log sinks, BigQuery-backed analytics, Cloud Asset Inventory, infrastructure-as-code pipeline telemetry, workload ownership, ticketing integration, and SIEM correlation with identity and endpoint telemetry. Use this tier for mature multi-project GCP deployment.

·        Tiering changes scope, enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require metadata-based execution or access change plus restricted target, unapproved principal, unapproved service account, unapproved source, non-standard workflow, or approved-scope deviation.

·        If the customer lacks metadata baselines, approved source baselines, or restricted workload labeling, deploy in pilot mode until asset and administrative baselines support production alerting.

Expected False Positives

·        Approved startup-script deployment.

·        Approved infrastructure-as-code changes.

·        Approved SSH key or OS Login administration.

·        Emergency break-glass access setup.

·        Serial console troubleshooting.

·        New automation service accounts not yet represented in the baseline.

False Positive Reduction

·        Baseline approved metadata keys, approved automation service accounts, approved administrators, source locations, and change workflows.

·        Exclude approved activity only when principal, service account, source, metadata key, target, and support context all match.

·        Maintain high severity for restricted workloads when startup-script, SSH, OS Login, or serial console metadata changes deviate from baseline.

·        Validate alerts against change records, infrastructure-as-code pipeline records, support tickets, and workload ownership context.

·        Review exceptions periodically to avoid converting execution-capable metadata changes into blanket suppression.

Known Limitations

·        Metadata request content and key names may vary across log sinks, APIs, and SIEM normalization.

·        Startup-script execution may require VM reboot or guest-agent behavior depending on configuration.

·        Approved infrastructure automation can resemble suspicious metadata change behavior.

·        Resource labels and asset inventory quality directly affect prioritization.

·        This rule does not confirm script execution by itself.

·        This rule does not detect third-party RMM binaries unless endpoint telemetry is integrated separately.

DRI Score

·        DRI: 8.7

·        Rating: Primary conditional cloud rule

·        Justification: The rule is strongly behavior anchored because it detects execution-capable or access-enabling metadata changes rather than generic Compute Engine administration. It is resilient because it focuses on startup-script, SSH, OS Login, serial console, and metadata-based control paths that can enable remote control or persistence. Its score is limited by metadata payload visibility, baseline quality, and the need to confirm execution or access after the change.

TCR Score

·        Operational TCR: 7.8

·        Full-Telemetry TCR: 8.9

·        Operational TCR Justification: Operational confidence is moderate-to-high where Cloud Audit Logs capture metadata modifications with principal, source, request content, resource identity, and workload labels. Confidence decreases when metadata payloads, asset labels, change context, or endpoint execution telemetry are incomplete.

·        Full-Telemetry TCR Justification: Confidence improves with centralized log sinks, BigQuery or Chronicle enrichment, Cloud Asset Inventory, IAM policy history, VM boot telemetry, endpoint telemetry, serial console audit logs, change records, and workload ownership metadata.

ATT&CK Mapping

·        T1098 — Account Manipulation.

·        T1078 — Valid Accounts.

·        T1059 — Command and Scripting Interpreter.

·        T1021 — Remote Services.

·        T1547 — Boot or Logon Autostart Execution.

Rule Disposition

·        Include as one conditional GCP cloud-native metadata execution and access-enablement rule.

·        Use as the GCP rule for detecting suspicious startup-script, SSH, OS Login, or serial-console-related metadata changes.

·        Do not treat this rule as standalone proof of compromise without identity, metadata-content, reboot, execution, access, or endpoint enrichment.

·        Do not suppress Compute Engine metadata changes globally because approved metadata workflows can still be abused.

Detection Code

-- GCP Rule 2: Suspicious startup script or metadata-based execution against Compute Engine workloads
-- Deployment note: Replace placeholder values with customer-approved identity, source, metadata, and workload baselines.

DECLARE lookback_hours INT64 DEFAULT 24;

WITH approved_principals AS (
  SELECT principal FROM UNNEST([
    'approved.cloudops@example.com',
    'approved.securityops@example.com',
    'approved-iac-sa@PROJECT_ID.iam.gserviceaccount.com'
  ]) AS principal
),
approved_source_ips AS (
  SELECT source_ip FROM UNNEST([
    '203.0.113.10',
    '203.0.113.11'
  ]) AS source_ip
),
high_risk_metadata_terms AS (
  SELECT term FROM UNNEST([
    'startup-script',
    'windows-startup-script',
    'ssh-keys',
    'enable-oslogin',
    'serial-port-enable',
    'block-project-ssh-keys'
  ]) AS term
),
restricted_indicators AS (
  SELECT indicator FROM UNNEST([
    'domain-controller',
    'identity',
    'backup',
    'privileged-access',
    'security-tooling',
    'regulated-data',
    'production-critical'
  ]) AS indicator
),
candidate_events AS (
  SELECT
    timestamp,
    resource.type AS resource_type,
    resource.labels.project_id AS project_id,
    protoPayload.methodName AS method_name,
    protoPayload.authenticationInfo.principalEmail AS principal_email,
    protoPayload.requestMetadata.callerIp AS caller_ip,
    protoPayload.resourceName AS resource_name,
    TO_JSON_STRING(protoPayload.request) AS request_json,
    TO_JSON_STRING(protoPayload.metadata) AS metadata_json
  FROM `PROJECT_ID.DATASET_ID.cloudaudit_googleapis_com_activity_*`
  WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_hours HOUR)
    AND protoPayload.serviceName = 'compute.googleapis.com'
    AND (
      protoPayload.methodName LIKE '%setMetadata%'
      OR protoPayload.methodName LIKE '%instances.setMetadata%'
      OR protoPayload.methodName LIKE '%projects.setCommonInstanceMetadata%'
    )
    AND EXISTS (
      SELECT 1
      FROM high_risk_metadata_terms
      WHERE LOWER(TO_JSON_STRING(protoPayload.request)) LIKE CONCAT('%', term, '%')
         OR LOWER(TO_JSON_STRING(protoPayload.metadata)) LIKE CONCAT('%', term, '%')
    )
)
SELECT
  timestamp,
  resource_type,
  project_id,
  method_name,
  principal_email,
  caller_ip,
  resource_name,
  request_json,
  metadata_json,
  is_restricted_workload,
  is_approved_principal,
  is_approved_source
FROM (
  SELECT
    *,
    EXISTS (
      SELECT 1
      FROM restricted_indicators
      WHERE LOWER(resource_name) LIKE CONCAT('%', indicator, '%')
         OR LOWER(request_json) LIKE CONCAT('%', indicator, '%')
         OR LOWER(metadata_json) LIKE CONCAT('%', indicator, '%')
    ) AS is_restricted_workload,
    LOWER(principal_email) IN (
      SELECT LOWER(principal) FROM approved_principals
    ) AS is_approved_principal,
    caller_ip IN (
      SELECT source_ip FROM approved_source_ips
    ) AS is_approved_source
  FROM candidate_events
)
WHERE
  (
    is_restricted_workload
    AND (is_approved_principal = FALSE OR is_approved_source = FALSE)
  )
  OR
  (
    is_restricted_workload = FALSE
    AND is_approved_principal = FALSE
    AND is_approved_source = FALSE
  );

GCP Rule 3

Remote Management Enablement Followed by GCP-Native Management Activity

Detection Objective

Detect IAM, service-account, OS Login, metadata, serial console, or VM Manager enablement actions followed by GCP-native remote management activity against Compute Engine workloads.

This rule is intended to identify adversary preparation for cloud-native remote control through permission changes, metadata changes, service-account access changes, or management-plane setup followed by VM Manager, OS Config, serial console, or metadata-based control activity.

Behavioral Rationale

Adversaries may not initially have direct cloud-native management access to a target Compute Engine workload. They may grant IAM roles, modify service-account permissions, add SSH metadata, enable serial console access, change OS Login posture, or deploy OS Config policy changes that allow remote management. When those enablement actions are followed by VM Manager, OS Config, serial console, or metadata-based management activity, the sequence can indicate deliberate preparation for cloud-native remote control.

This rule is distinct from Rules 1 and 2 because it detects the setup-to-control sequence rather than only management activity or metadata modification.

Primary Telemetry Source

·        Google Cloud Audit Logs.

·        IAM policy change logs.

·        Compute Engine metadata and serial console audit logs.

·        OS Config and VM Manager audit logs.

·        Cloud Asset Inventory or asset enrichment.

·        Service-account and identity context.

Required GCP Data Elements

·        Timestamp.

·        Project ID.

·        Resource name.

·        Resource type.

·        Method name.

·        Principal email.

·        Caller IP address where available.

·        IAM policy or service-account change details.

·        Compute Engine metadata change details.

·        OS Config or VM Manager method details.

·        Target workload identity.

·        Resource labels, folders, projects, or asset criticality.

·        Approved identity, automation, service-account, and change baselines.

Rule Logic Summary

·        Stage 1 detects access-enabling or remote-management-enabling actions.

·        Stage 2 detects GCP-native remote management activity.

·        The production rule must require Stage 1 and Stage 2 within the configured time window.

·        Same-project-only matching is not sufficient for high-confidence production alerting.

·        Same-project matching should be used as a join boundary, not as a strong correlation signal.

·        Stronger correlation should use same principal, same service account, same resource, same workload group, same metadata target, same policy assignment target, or same approved change workflow where available.

·        Exclude approved automation only when principal, service account, change request, target workload, and support workflow match policy.

System-Native Rule Format

Google Cloud Logging / BigQuery SQL sequence-correlation logic.

Engineering Implementation Instructions

·        Implement as a two-stage BigQuery or SIEM correlation rule where possible.

·        Stage 1 should detect access-enabling actions such as IAM role grants, service-account policy changes, service-account key creation, Compute Engine metadata changes, OS Login-related changes, serial console enablement, or OS Config management enablement.

·        Stage 2 should detect OS Config, VM Manager, serial console, metadata-based execution, or related remote-management activity.

·        Correlate using stronger keys where available, such as same principal, same service account, same resource, same project plus same principal, same workload label, same metadata target, same policy target, or same change workflow.

·        Use a 24-hour starting correlation window and tune based on normal infrastructure automation patterns.

·        Build approved baselines for GCP administrators, CI/CD identities, infrastructure-as-code service accounts, cloud operations groups, security operations identities, service-account owners, and break-glass workflows.

·        Enrich with Cloud Asset Inventory, IAM policy history, Security Command Center findings, endpoint telemetry, infrastructure-as-code pipeline telemetry, ticketing data, and workload labels.

·        Treat this as a high-priority setup-to-control signal when activity involves restricted workloads or non-standard principals.

·        If only same-project correlation is available, keep the rule in pilot or hunting mode until stronger enrichment is available.

Deployment Tiering and Customer Data Instructions

·        Tier 1 deployment: Deploy against restricted Compute Engine workloads and high-risk control-plane changes. Required customer data includes restricted workload labels, approved GCP administrators, approved infrastructure automation service accounts, approved VM Manager or OS Config identities, and approved metadata-management workflows.

·        Tier 2 deployment: Add change-control context, approved role assignment workflows, approved service-account workflows, expected metadata workflows, and approved workload groups. Use this tier for production alerting on non-standard setup-to-control sequences.

·        Tier 3 deployment: Add Cloud Asset Inventory, folder and organization metadata, IAM policy history, Security Command Center context, service-account ownership, and endpoint telemetry. Use this tier to prioritize sensitive workloads and validate unauthorized enablement.

·        Tier 4 deployment: Add centralized log sinks, BigQuery analytics, infrastructure-as-code pipeline telemetry, ticketing integration, multi-project metadata, security account context, workload ownership data, and SIEM correlation. Use this tier for mature GCP estates.

·        Tiering changes enrichment, routing, and prioritization. It must not weaken the evidence requirement. The rule must still require access-enabling control-plane change plus subsequent GCP-native remote-management activity.

·        If the customer lacks Cloud Audit Log centralization, workload labels, or approved identity baselines, deploy in pilot mode before production alerting.

Expected False Positives

·        Approved infrastructure-as-code role changes.

·        Approved service-account permission changes.

·        Approved VM Manager onboarding.

·        Approved metadata or startup-script deployment.

·        Approved serial console troubleshooting.

·        Patch-management or fleet-management automation.

·        Emergency remediation enabling temporary access.

·        Cloud operations changes not represented in the baseline.

False Positive Reduction

·        Baseline approved GCP roles, service accounts, infrastructure-as-code pipelines, metadata workflows, OS Config workflows, serial console workflows, and VM Manager workflows.

·        Require subsequent GCP-native remote-management activity, not just IAM, service-account, metadata, or control-plane change alone.

·        Correlate with change tickets, infrastructure-as-code pipeline records, caller identity, service-account ownership, target workload role, and asset criticality.

·        Maintain higher severity for restricted workloads and cross-project administrative activity.

·        Review newly approved exceptions to avoid suppressing unauthorized remote-access enablement.

Known Limitations

·        Correlation may be difficult if enablement events and remote-management activity do not share a direct target identifier.

·        Infrastructure automation may legitimately perform similar sequences.

·        Cloud Audit Log coverage must be centralized across relevant projects, folders, and organizations.

·        Resource and identity baselines must be maintained.

·        This rule detects GCP-native enablement of remote control, not third-party RMM software.

·        A 24-hour window may require tuning to reduce noise.

·        Same-project-only correlation should remain hunting or pilot mode unless additional correlation keys are available.

DRI Score

·        DRI: 8.3

·        Rating: Primary conditional cloud rule

·        Justification: The rule is behaviorally strong because it detects a setup-to-control sequence rather than isolated administrative events. It is resilient because it focuses on GCP-native access enablement followed by remote-management activity. Its score is limited by correlation complexity, baseline dependency, and potential overlap with legitimate infrastructure operations.

TCR Score

·        Operational TCR: 7.3

·        Full-Telemetry TCR: 8.6

·        Operational TCR Justification: Operational confidence depends on centralized Cloud Audit Logs, IAM event visibility, service-account context, resource identity mapping, workload labeling, and approved identity baselines. Confidence decreases when control-plane changes and target workloads cannot be reliably correlated.

·        Full-Telemetry TCR Justification: Confidence improves with centralized log sinks, Cloud Asset Inventory, IAM policy history, service-account ownership data, infrastructure-as-code telemetry, change records, organization and folder metadata, workload labels, Security Command Center, and endpoint telemetry.

ATT&CK Mapping

·        T1098 — Account Manipulation.

·        T1078 — Valid Accounts.

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

Rule Disposition

·        Include as one conditional GCP cloud-native setup-to-control rule.

·        Use as the GCP rule for detecting enablement of remote-management capability followed by use.

·        Do not alert on IAM, service-account, metadata, or control-plane changes alone unless paired with subsequent GCP-native remote-management activity or restricted workload context.

·        Deploy only where Cloud Audit Logs, asset, identity, service-account, and role baselines are sufficiently mature.

·        Keep in hunting or pilot mode if only same-project correlation is available.

Detection Code

-- GCP Rule 3: Remote management enablement followed by GCP-native management activity
-- Deployment note: Same-project-only correlation is not sufficient for mature production alerting.
-- Production correlation should prefer same principal, same service account, same resource, same workload group,
-- same policy target, same metadata target, or same approved change workflow where available.

DECLARE lookback_hours INT64 DEFAULT 24;

WITH audit_events AS (
  SELECT
    timestamp,
    resource.type AS resource_type,
    resource.labels.project_id AS project_id,
    protoPayload.serviceName AS service_name,
    protoPayload.methodName AS method_name,
    protoPayload.authenticationInfo.principalEmail AS principal_email,
    protoPayload.requestMetadata.callerIp AS caller_ip,
    protoPayload.resourceName AS resource_name,
    TO_JSON_STRING(protoPayload.request) AS request_json,
    TO_JSON_STRING(protoPayload.metadata) AS metadata_json
  FROM `PROJECT_ID.DATASET_ID.cloudaudit_googleapis_com_activity_*`
  WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_hours HOUR)
),
enablement_events AS (
  SELECT
    timestamp AS enablement_time,
    project_id AS enablement_project,
    LOWER(principal_email) AS enablement_principal,
    caller_ip AS enablement_caller_ip,
    service_name AS enablement_service,
    method_name AS enablement_method,
    LOWER(resource_name) AS enablement_resource,
    LOWER(request_json) AS enablement_request,
    LOWER(metadata_json) AS enablement_metadata
  FROM audit_events
  WHERE
    (
      service_name = 'iam.googleapis.com'
      AND (
        method_name LIKE '%SetIamPolicy%'
        OR method_name LIKE '%CreateServiceAccountKey%'
        OR method_name LIKE '%serviceAccounts.setIamPolicy%'
      )
    )
    OR
    (
      service_name = 'compute.googleapis.com'
      AND (
        method_name LIKE '%setMetadata%'
        OR method_name LIKE '%instances.setMetadata%'
        OR method_name LIKE '%projects.setCommonInstanceMetadata%'
      )
      AND (
        LOWER(request_json) LIKE '%ssh-keys%'
        OR LOWER(request_json) LIKE '%enable-oslogin%'
        OR LOWER(request_json) LIKE '%serial-port-enable%'
        OR LOWER(request_json) LIKE '%startup-script%'
        OR LOWER(metadata_json) LIKE '%ssh-keys%'
        OR LOWER(metadata_json) LIKE '%enable-oslogin%'
        OR LOWER(metadata_json) LIKE '%serial-port-enable%'
        OR LOWER(metadata_json) LIKE '%startup-script%'
      )
    )
),
management_events AS (
  SELECT
    timestamp AS management_time,
    project_id AS management_project,
    LOWER(principal_email) AS management_principal,
    caller_ip AS management_caller_ip,
    service_name AS management_service,
    method_name AS management_method,
    LOWER(resource_name) AS management_resource,
    LOWER(request_json) AS management_request,
    LOWER(metadata_json) AS management_metadata
  FROM audit_events
  WHERE
    service_name LIKE '%osconfig.googleapis.com%'
    OR method_name LIKE '%OSPolicy%'
    OR method_name LIKE '%Patch%'
    OR method_name LIKE '%osconfig%'
    OR (
      service_name = 'compute.googleapis.com'
      AND (
        method_name LIKE '%connect%'
        OR method_name LIKE '%setMetadata%'
        OR method_name LIKE '%instances.setMetadata%'
      )
    )
)
SELECT
  e.enablement_time,
m.management_time,
  e.enablement_project,
m.management_project,
  e.enablement_principal,
m.management_principal,
  e.enablement_method,
m.management_method,
  e.enablement_caller_ip,
m.management_caller_ip,
  e.enablement_resource,
m.management_resource,
  e.enablement_request,
m.management_request,
  e.enablement_metadata,
m.management_metadata,
  e.enablement_principal = m.management_principal AS same_principal,
  e.enablement_resource = m.management_resource AS same_resource,
  (
    e.enablement_resource = m.management_resource
    OR e.enablement_principal = m.management_principal
  ) AS strong_correlation
FROM enablement_events e
JOIN management_events m
  ON e.enablement_project = m.management_project
WHERE m.management_time BETWEEN e.enablement_time AND TIMESTAMP_ADD(e.enablement_time, INTERVAL lookback_hours HOUR)
  AND (
    e.enablement_principal = m.management_principal
    OR e.enablement_resource = m.management_resource
  );

GCP Final Disposition

GCP receives 3 audit-passing conditional cloud-native rules for this report. The final GCP rule set covers unauthorized VM Manager or OS Config activity against restricted Compute workloads, suspicious startup-script or metadata-based execution against Compute Engine workloads, and remote-management enablement followed by GCP-native management activity. No additional GCP rules are included because additional concepts would be redundant, lower-confidence, or dependent on customer-specific telemetry conditions.

S26 — Threat-to-Rule Traceability Matrix

Traceability Overview

This section maps the RMM tool abuse threat model to the final S25 detection rule set. The traceability model confirms that each included detection rule maps to a defined adversary behavior, telemetry source, ATT&CK-aligned activity, and operational detection purpose.

The final rule set is behavior-driven. It prioritizes unauthorized RMM introduction, suspicious execution context, persistence or unattended-access setup, outbound control behavior, RMM-associated post-compromise command execution, and cloud-native remote management abuse. Product names are used only as scoped selectors where needed. Detection confidence comes from behavior, context, telemetry, and approved-baseline deviation.

Traceability does not imply equal confidence across all systems. Each rule remains governed by its own telemetry availability, normalization quality, deployment constraints, DRI, Operational TCR, and Full-Telemetry TCR.

Final S25 Rule Coverage Summary

·        Suricata final rule count: 1

·        SentinelOne final rule count: 3

·        Splunk final rule count: 3

·        Elastic final rule count: 3

·        QRadar final rule count: 2

·        Sigma final rule count: 3

·        YARA final rule count: 0

·        AWS final rule count: 3

·        Azure final rule count: 3

·        GCP final rule count: 3

Primary Threat Behaviors Traced

·        Unauthorized RMM or remote support tool introduction.

·        RMM execution from suspicious parent process or user-controlled path.

·        RMM persistence, service creation, auto-start behavior, or unattended-access configuration.

·        Unauthorized outbound RMM relay or remote-support infrastructure access.

·        RMM-associated high-risk command execution.

·        RMM-enabled credential access, discovery, lateral movement, defense evasion, backup interference, file staging, and ransomware preparation.

·        Cloud-native remote management activity through AWS Systems Manager.

·        Cloud-native remote command activity through Azure Run Command.

·        Cloud-native remote management, metadata-based execution, and access enablement through GCP control-plane activity.

·        Detection-system non-viability where the system cannot observe the required behavior with acceptable precision.

Traceability Item 1

Unauthorized RMM Introduction from User-Driven or Suspicious Execution Context

Threat Behavior

RMM or remote support tooling is introduced through phishing, fake support lures, browser downloads, collaboration-tool downloads, archive extraction, user-controlled paths, shell staging, or attacker placement rather than an approved endpoint-management workflow.

Mapped Rules

·        SentinelOne Rule 1: Unauthorized RMM execution from suspicious parent process or user-controlled path.

·        Splunk Rule 1: Unauthorized RMM execution from suspicious parent process or user-controlled path.

·        Elastic Rule 1: Unauthorized RMM execution from suspicious parent process or user-controlled path.

·        QRadar Rule 1: Unauthorized RMM execution or persistence from suspicious context.

·        Sigma Rule 1: Unauthorized RMM execution from suspicious parent process or user-controlled path.

Primary Telemetry

·        Endpoint process creation.

·        Parent process lineage.

·        Command line.

·        File path.

·        User context.

·        Endpoint role.

·        Approved RMM inventory.

·        Approved deployment baseline.

Detection Purpose

Identify the initial misuse of legitimate remote support tooling before it becomes durable control, lateral movement, or post-compromise execution.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

·        T1566.002 — Spearphishing Link.

Coverage Disposition

Covered across endpoint, SIEM, and portable Sigma detection layers. QRadar intentionally combines introduction and persistence because QRadar receives normalized endpoint telemetry and is strongest as a correlation layer.

Traceability Item 2

RMM Persistence or Unattended-Access Configuration

Threat Behavior

RMM tooling is configured for durable access through service creation, scheduled task creation, registry autorun modification, auto-start behavior, unattended access, reconnect capability, silent installation, agent enrollment, or persistent installation.

Mapped Rules

·        SentinelOne Rule 2: Unauthorized RMM persistence or unattended-access configuration.

·        Splunk Rule 2: RMM persistence or unattended-access setup.

·        Elastic Rule 2: RMM persistence or unattended-access configuration.

·        QRadar Rule 1: Unauthorized RMM execution or persistence from suspicious context.

·        Sigma Rule 2: Unauthorized RMM persistence or unattended-access configuration.

Primary Telemetry

·        Endpoint process creation.

·        Service creation.

·        Scheduled task creation.

·        Registry modification.

·        Command line.

·        Parent process.

·        Process path.

·        Software inventory.

·        Approved RMM persistence baseline.

Detection Purpose

Identify adversary attempts to convert temporary RMM access into persistent remote control.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1543.003 — Windows Service.

·        T1053.005 — Scheduled Task.

·        T1060 — Registry Run Keys / Startup Folder.

·        T1136 — Create Account.

Coverage Disposition

Covered through endpoint, SIEM, and portable Sigma detection. QRadar covers this behavior within its combined introduction and persistence rule to avoid redundant lower-value QRadar rules.

Traceability Item 3

Unauthorized RMM Relay or Remote-Support Infrastructure Access

Threat Behavior

An endpoint communicates with RMM relay, broker, remote-support, or remote-control infrastructure in a way that deviates from approved support workflows, restricted endpoint policy, or expected administrative access.

Mapped Rules

·        Suricata Rule 1: Unauthorized RMM relay or remote support infrastructure access from restricted endpoint populations.

·        Splunk Rule 3: RMM-associated outbound infrastructure access with endpoint or process context, where endpoint-network correlation is available.

Primary Telemetry

·        DNS telemetry.

·        Proxy telemetry.

·        TLS or HTTP metadata.

·        Network flow metadata.

·        Endpoint-to-network correlation.

·        Restricted asset inventory.

·        Approved RMM destination inventory.

·        Approved support workflow context.

Detection Purpose

Identify RMM control-channel access from systems where direct remote support is prohibited, unexpected, or not tied to approved support activity.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1105 — Ingress Tool Transfer.

·        T1071.001 — Web Protocols.

·        T1021 — Remote Services.

Coverage Disposition

Covered primarily through Suricata and SIEM correlation where network and endpoint context can be joined. Network-only detection is intentionally limited because RMM infrastructure may be legitimate and high-volume in enterprise environments. Elastic is not mapped here unless the locked Elastic Rule 3 explicitly includes endpoint-network correlation in the final S25 assembly.

Traceability Item 4

RMM Activity Followed by High-Risk Post-Compromise Commands

Threat Behavior

RMM activity is followed by high-risk command execution associated with discovery, credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware preparation.

Mapped Rules

·        SentinelOne Rule 3: RMM tool launching high-risk shell, credential, lateral movement, or tampering activity.

·        Splunk Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        Elastic Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        QRadar Rule 2: RMM activity followed by high-risk post-compromise behavior.

·        Sigma Rule 3: RMM tool launching high-risk post-compromise activity.

Primary Telemetry

·        Endpoint process creation.

·        Parent process lineage.

·        Command line.

·        Process timing.

·        Endpoint identity.

·        User context.

·        RMM process or session context.

·        SIEM correlation.

·        Approved support workflow context.

Detection Purpose

Identify adversary use of RMM as an interactive control channel after access has been established.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1059 — Command and Scripting Interpreter.

·        T1087 — Account Discovery.

·        T1018 — Remote System Discovery.

·        T1003 — OS Credential Dumping.

·        T1021 — Remote Services.

·        T1105 — Ingress Tool Transfer.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Coverage Disposition

Covered across endpoint, SIEM, and Sigma. QRadar uses staged AQL selectors plus CRE sequence logic. Sigma uses process-lineage detection and recommends backend-native sequence correlation where available.

Traceability Item 5

Credential Access and Identity Discovery Through RMM-Launched Activity

Threat Behavior

An adversary uses RMM-launched shells, scripts, or remote command execution to enumerate users, groups, sessions, domains, privileges, or credential targets.

Mapped Rules

·        SentinelOne Rule 3: RMM tool launching high-risk shell, credential, lateral movement, or tampering activity.

·        Splunk Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        Elastic Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        QRadar Rule 2: RMM activity followed by high-risk post-compromise behavior.

·        Sigma Rule 3: RMM tool launching high-risk post-compromise activity.

Primary Telemetry

·        Command line.

·        Parent process.

·        Child process.

·        User context.

·        Endpoint identity.

·        RMM process context.

·        Identity telemetry enrichment.

Detection Purpose

Detect early post-compromise activity where RMM is used to assess identity scope, privileges, user sessions, and credential targets.

ATT&CK Mapping

·        T1087 — Account Discovery.

·        T1033 — System Owner/User Discovery.

·        T1069 — Permission Groups Discovery.

·        T1003 — OS Credential Dumping.

·        T1059 — Command and Scripting Interpreter.

·        T1219 — Remote Access Software.

Coverage Disposition

Covered through post-compromise behavior rules. Detection depends heavily on command-line visibility and process lineage.

Traceability Item 6

Lateral Movement Preparation and Remote Execution Through RMM-Launched Activity

Threat Behavior

An adversary uses RMM-controlled access to prepare or execute lateral movement through remote execution utilities, service manipulation, scheduled tasks, administrative shares, or remote management tools.

Mapped Rules

·        SentinelOne Rule 3: RMM tool launching high-risk shell, credential, lateral movement, or tampering activity.

·        Splunk Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        Elastic Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        QRadar Rule 2: RMM activity followed by high-risk post-compromise behavior.

·        Sigma Rule 3: RMM tool launching high-risk post-compromise activity.

Primary Telemetry

·        Process creation.

·        Command line.

·        Parent-child process lineage.

·        Service control commands.

·        Scheduled task commands.

·        Remote execution utility usage.

·        Endpoint identity.

·        User context.

Detection Purpose

Detect when RMM access is being used as a staging platform for expansion beyond the initially accessed endpoint.

ATT&CK Mapping

·        T1021 — Remote Services.

·        T1053.005 — Scheduled Task.

·        T1543.003 — Windows Service.

·        T1059 — Command and Scripting Interpreter.

·        T1219 — Remote Access Software.

Coverage Disposition

Covered by high-risk follow-on behavior rules. Higher confidence requires endpoint process telemetry and same-endpoint or process-lineage correlation.

Traceability Item 7

Defense Evasion, Backup Interference, and Ransomware Preparation Through RMM-Controlled Access

Threat Behavior

An adversary uses RMM-controlled access to stop services, clear logs, weaken audit policy, delete shadow copies, interfere with backups, disable recovery, stage archive tooling, or prepare ransomware deployment.

Mapped Rules

·        SentinelOne Rule 3: RMM tool launching high-risk shell, credential, lateral movement, or tampering activity.

·        Splunk Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        Elastic Rule 3: RMM activity followed by high-risk post-compromise behavior.

·        QRadar Rule 2: RMM activity followed by high-risk post-compromise behavior.

·        Sigma Rule 3: RMM tool launching high-risk post-compromise activity.

Primary Telemetry

·        Command line.

·        Process name.

·        Parent process.

·        Endpoint process events.

·        Service control events.

·        Backup and recovery command usage.

·        Endpoint role.

·        Asset criticality.

Detection Purpose

Detect escalation from remote access into destructive or ransomware-preparatory activity.

ATT&CK Mapping

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

·        T1070.001 — Clear Windows Event Logs.

·        T1562.001 — Impair Defenses.

·        T1059 — Command and Scripting Interpreter.

·        T1219 — Remote Access Software.

Coverage Disposition

Covered through post-compromise command rules. High severity should be applied when observed on backup systems, identity systems, security tooling, executive endpoints, regulated-data systems, or production-critical assets.

Traceability Item 8

AWS-Native Remote Management Abuse Through Systems Manager

Threat Behavior

An adversary uses AWS Systems Manager Session Manager, Run Command, or Automation execution as a cloud-native remote management path against EC2 workloads.

Mapped Rules

·        AWS Rule 1: Unauthorized Systems Manager session or remote command against restricted EC2 workloads.

·        AWS Rule 2: High-risk command execution through AWS Systems Manager.

·        AWS Rule 3: Systems Manager access enablement followed by remote-control activity.

Primary Telemetry

·        AWS CloudTrail.

·        Systems Manager activity.

·        IAM identity context.

·        Assumed-role issuer context.

·        Source IP address.

·        EC2 instance tags.

·        AWS Config.

·        Systems Manager session and command output logs where available.

·        Endpoint telemetry where integrated.

Detection Purpose

Detect AWS-native remote control and post-compromise command execution where Systems Manager functions as a cloud-native RMM pathway.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Coverage Disposition

Covered by 3 conditional AWS rules. AWS detection does not cover third-party RMM binaries unless endpoint telemetry is integrated. AWS Rule 3 remains hunting or pilot mode if only same-account correlation is available.

Traceability Item 9

Azure-Native Remote Command Abuse Through Azure Run Command

Threat Behavior

An adversary uses Azure VM Run Command, Azure Arc Run Command, RBAC changes, managed identity changes, or VM extension workflows as a cloud-native remote command and control path.

Mapped Rules

·        Azure Rule 1: Unauthorized Azure Run Command activity against restricted workloads.

·        Azure Rule 2: High-risk command execution through Azure Run Command.

·        Azure Rule 3: Remote command enablement followed by Azure Run Command activity.

Primary Telemetry

·        Azure Activity logs.

·        Microsoft Sentinel or Log Analytics.

·        Azure VM inventory.

·        Azure Arc inventory.

·        Microsoft Entra ID sign-in context.

·        RBAC activity.

·        Managed identity activity.

·        Defender for Cloud.

·        Defender for Endpoint where integrated.

Detection Purpose

Detect Azure-native remote control, high-risk command execution, and setup-to-control sequences against Azure VMs or Azure Arc-enabled workloads.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

·        T1489 — Service Stop.

·        T1490 — Inhibit System Recovery.

Coverage Disposition

Covered by 3 conditional Azure rules. Azure detection does not cover third-party RMM binaries unless endpoint telemetry is integrated. Azure Rule 3 requires stronger correlation than same-subscription-only matching.

Traceability Item 10

GCP-Native Remote Management, Metadata Execution, and Setup-to-Control Abuse

Threat Behavior

An adversary uses GCP-native VM Manager, OS Config, metadata changes, startup scripts, SSH key metadata, OS Login-related access, serial console enablement, IAM changes, or service-account changes to establish remote management or execution capability.

Mapped Rules

·        GCP Rule 1: Unauthorized VM Manager or OS Config activity against restricted Compute workloads.

·        GCP Rule 2: Suspicious startup script or metadata-based execution against Compute Engine workloads.

·        GCP Rule 3: Remote management enablement followed by GCP-native management activity.

Primary Telemetry

·        Google Cloud Audit Logs.

·        VM Manager logs.

·        OS Config logs.

·        Compute Engine audit logs.

·        IAM policy history.

·        Service-account context.

·        Compute Engine metadata changes.

·        Cloud Asset Inventory.

·        Security Command Center.

·        Endpoint telemetry where integrated.

Detection Purpose

Detect GCP-native remote management, metadata-based execution or access persistence, and setup-to-control sequences against Compute Engine workloads.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1021 — Remote Services.

·        T1059 — Command and Scripting Interpreter.

·        T1078 — Valid Accounts.

·        T1098 — Account Manipulation.

·        T1547 — Boot or Logon Autostart Execution.

Coverage Disposition

Covered by 3 conditional GCP rules. GCP detection does not cover third-party RMM binaries unless endpoint telemetry is integrated. GCP Rule 3 requires stronger correlation than same-project-only matching.

Traceability Item 11

File-Content Detection Non-Viability for Generic RMM Abuse

Threat Behavior

The adversary uses legitimate RMM tools, signed remote support binaries, portable clients, installers, or vendor-provided software as the control mechanism.

Mapped Rules

·        YARA: 0 production rules.

Primary Telemetry

·        File content only where sample-specific malware analysis is available.

·        Conditional forensic artifacts only.

·        No standing production telemetry recommendation for generic RMM binary detection.

Detection Purpose

Avoid weak product-name, vendor-string, signer, hash, generic installer, or packed-binary YARA detections that would identify legitimate software presence rather than adversary-controlled abuse.

ATT&CK Mapping

·        T1219 — Remote Access Software.

·        T1204.002 — Malicious File.

·        T1105 — Ingress Tool Transfer.

·        T1059 — Command and Scripting Interpreter.

Coverage Disposition

No production YARA rules are included. YARA remains conditional for incident response if a malicious wrapper, loader, dropper, trojanized installer, or campaign-specific file artifact is recovered.

Cross-System Traceability Summary

Initial Access and Tool Introduction

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Supported by Suricata when outbound RMM infrastructure access is observed.

·        Not covered by YARA as a standing production rule.

·        Covered by AWS, Azure, and GCP only when the behavior occurs through cloud-native remote management pathways or when endpoint telemetry is integrated into those platforms or downstream SIEM workflows.

Persistence and Unattended Access

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Covered in cloud-native form by AWS, Azure, and GCP where remote-management enablement or metadata-based persistence is observable.

·        Not covered by Suricata unless persistent activity produces observable network behavior.

·        Not covered by YARA as a generic RMM file-content rule.

Post-Compromise Command Execution

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Covered by AWS Rule 2, Azure Rule 2, and GCP Rule 2 when cloud-native command or metadata execution is visible.

·        Supported by Suricata only where outbound transfer, relay, or infrastructure access is observable.

·        Not covered by YARA without sample-specific malicious artifacts.

Cloud-Native Remote Management Abuse

·        Covered by AWS, Azure, and GCP conditional cloud-native rules.

·        Covered by Splunk, Elastic, QRadar, SentinelOne, or Sigma only when the relevant cloud logs, endpoint telemetry, or cloud workload telemetry are ingested and normalized into those systems.

·        Detection depends on cloud audit logs, identity context, workload tagging, approved-role baselines, source context, and support-workflow context.

Detection Gaps and Constraints

·        Generic RMM product detection is intentionally avoided because legitimate tools are common and frequently authorized.

·        Cloud detections are conditional and only cover cloud-native remote management behavior unless endpoint telemetry is integrated.

·        Network-only RMM detection has limited confidence without endpoint, identity, asset, and support-workflow context.

·        Same-account, same-subscription, or same-project correlation alone is insufficient for high-confidence setup-to-control cloud detections.

·        Command-content visibility materially affects AWS, Azure, and GCP high-risk command detection confidence.

·        Approved RMM, support, MSP, break-fix, and cloud operations workflows must be baselined before full production enforcement.

 S27 — Behavior & Log Artifacts

Artifact Overview

This section identifies the primary behavior and log artifacts expected from RMM tool abuse, cloud-native remote management abuse, and post-compromise control-channel activity. Artifacts are grouped by telemetry source so detection engineers and SOC analysts can validate whether the required signals are available, normalized, and usable before production deployment.

The artifacts below are not indicators of compromise by themselves. They become meaningful when correlated with suspicious execution context, unapproved support workflow, restricted endpoint scope, persistence behavior, outbound control-channel activity, high-risk command execution, or cloud-native remote-management misuse.

Endpoint Process Artifacts

·        RMM executable launch from user-controlled locations such as Downloads, Desktop, AppData, Temp, OneDrive, Dropbox, or other user-writable paths.

·        RMM execution with browser, email, document, archive utility, collaboration tool, script interpreter, or shell parent process.

·        Remote support client execution by ordinary user accounts outside approved helpdesk workflow.

·        RMM process spawning cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, wmic.exe, schtasks.exe, sc.exe, net.exe, nltest.exe, whoami.exe, vssadmin.exe, wbadmin.exe, bcdedit.exe, wevtutil.exe, rclone.exe, archive utilities, or credential-access tooling.

·        RMM helper, agent, service, or support process running under SYSTEM, service account, technician account, or unexpected administrative context.

·        RMM activity followed by discovery, credential access, lateral movement, defense evasion, backup interference, file staging, or remote execution commands.

Persistence and Configuration Artifacts

·        Service creation or service reconfiguration associated with RMM tooling.

·        Scheduled task creation associated with RMM tooling.

·        Registry autorun modification associated with RMM tooling.

·        Silent, quiet, unattended, reconnect, persist, enroll, register, or agent-install command-line parameters.

·        RMM agent installation outside approved deployment path.

·        Unattended-access configuration created outside approved support workflow.

·        New or modified startup entries related to remote support tooling.

·        Approved RMM product installed by an unexpected user, parent process, source path, or deployment mechanism.

Network and Control-Channel Artifacts

·        Outbound communication to RMM relay, broker, remote-support, or remote-control infrastructure from restricted endpoint populations.

·        DNS queries for remote support or relay infrastructure from systems where RMM use is prohibited or unexpected.

·        TLS, HTTP, or proxy activity associated with RMM infrastructure without corresponding approved support context.

·        Endpoint-to-network correlation showing RMM process execution near outbound relay or broker communication.

·        Repeated RMM infrastructure access from identity systems, backup systems, executive endpoints, security tooling, privileged access workstations, regulated-data systems, or production-critical servers.

·        Remote-support communication from endpoints without approved RMM inventory, support ticket, or session ownership metadata.

Identity and User Artifacts

·        RMM activity initiated by ordinary users outside approved support workflow.

·        RMM activity initiated by privileged users from unexpected endpoints or source networks.

·        RMM-launched activity under SYSTEM, service account, technician account, or unexpected administrative context.

·        Cloud-native remote-management activity from unapproved principals, unapproved assumed roles, service principals, managed identities, service accounts, or automation identities.

·        Remote-management activity after unusual sign-in behavior, impossible travel, anomalous source IP, or newly assigned privilege.

·        Remote-management activity without matching helpdesk ticket, change record, or approved support session.

Cloud-Native AWS Artifacts

·        AWS Systems Manager StartSession, SendCommand, or StartAutomationExecution against restricted EC2 workloads.

·        Systems Manager command activity from unapproved principal, unapproved assumed role, unapproved source, or missing approved workflow.

·        Systems Manager command content containing discovery, credential access, backup interference, defense evasion, file staging, or transfer commands where command visibility exists.

·        IAM policy change, role attachment, instance profile association, or instance profile replacement followed by Systems Manager remote activity.

·        Same-principal, same-assumed-role, same-target-instance, same-instance-profile, same restricted workload group, or same change-workflow correlation between access enablement and Systems Manager use.

·        Systems Manager command or session activity without session transcript, command output, ticket context, or approved change record.

Cloud-Native Azure Artifacts

·        Azure VM Run Command or Azure Arc Run Command against restricted workloads.

·        Run Command activity from unapproved caller, unapproved source, unexpected role, or missing approved workflow.

·        Run Command activity containing high-risk command content where script content, parameters, command output, guest telemetry, or endpoint telemetry is available.

·        RBAC change, managed identity change, VM extension write, automation account change, or deployment activity followed by Run Command activity.

·        Same-caller, same-resource-group, same-resource-family, same managed identity, same workload group, or same change-workflow correlation between access enablement and Run Command use.

·        Run Command activity without matching change record, support ticket, workload owner approval, or identity context.

Cloud-Native GCP Artifacts

·        VM Manager, OS Config, OS policy assignment, or patch activity against restricted Compute Engine workloads.

·        OS Config or VM Manager activity from unapproved principal, service account, source, or workflow.

·        Compute Engine metadata changes involving startup scripts, Windows startup scripts, SSH keys, OS Login behavior, serial console access, or execution-capable metadata.

·        IAM policy change, service-account permission change, service-account key creation, metadata change, OS Login change, or serial console enablement followed by GCP-native management activity.

·        Same-principal, same-resource, same service-account, same metadata target, same policy target, same workload group, or same change-workflow correlation between enablement and management activity.

·        Metadata changes without matching infrastructure-as-code record, change ticket, support workflow, or workload owner approval.

SIEM and Correlation Artifacts

·        Same-endpoint correlation between RMM activity and high-risk command activity within the configured window.

·        Same-endpoint correlation between RMM execution and outbound relay or broker communication.

·        Same-user correlation only where validated locally; user context should otherwise be treated as enrichment.

·        Restricted endpoint match combined with RMM execution, RMM network activity, persistence behavior, or high-risk command behavior.

·        Approved support workflow mismatch involving endpoint, user, command category, support ticket, session ownership, deployment mechanism, or source location.

·        Correlation failure caused by missing endpoint identity normalization, inconsistent host naming, incomplete process telemetry, missing command-line capture, or missing cloud-resource enrichment.

Forensic and Conditional File Artifacts

·        Trojanized RMM installer.

·        Malicious wrapper that drops or launches an RMM client.

·        Custom loader that retrieves or installs RMM tooling.

·        Campaign-specific dropper, staged payload, or signed but tampered artifact.

·        Stable malicious strings, resources, mutexes, metadata, or structural traits tied to a confirmed intrusion.

·        Legitimate RMM binaries are not treated as standalone malicious file artifacts without behavioral or contextual evidence.

Artifact Interpretation Constraints

·        RMM product presence alone is not sufficient to determine compromise.

·        Signed RMM binaries can be used legitimately or maliciously.

·        Cloud-native remote-management activity can be legitimate administrative activity unless paired with identity, workflow, target, source, command, or sequence deviation.

·        Network communication to RMM infrastructure is lower-confidence without endpoint, asset, identity, and support-workflow context.

·        Command-line visibility is critical for high-confidence post-compromise behavior detection.

·        Same-account, same-subscription, or same-project correlation alone is not sufficient for high-confidence cloud setup-to-control detection.

·        Missing approved support workflow documentation materially reduces triage confidence.

Figure 5

S28 — Detection Strategy and SOC Implementation Guidance

Detection Strategy Overview

The detection strategy for this report should prioritize behavior, context, and approved-baseline deviation over product-name matching. RMM tools are often legitimate, signed, and operationally necessary, so production detection must distinguish approved administration from attacker-controlled remote access.

The SOC should treat RMM activity as suspicious only when it is paired with unauthorized introduction, suspicious execution path, suspicious parent process, persistence behavior, restricted endpoint scope, outbound control-channel deviation, high-risk follow-on commands, cloud-native remote-management abuse, or missing approved support context.

SOC Operating Model

·        Treat unauthorized RMM execution from user-controlled paths as an initial access or social-engineering-driven support-lure signal.

·        Treat unattended-access setup, service creation, scheduled task creation, registry autorun modification, or silent installation as persistence or durable-control behavior.

·        Treat RMM activity followed by discovery, credential access, lateral movement, defense evasion, backup interference, file staging, remote execution, or ransomware-preparation commands as post-compromise control-channel abuse.

·        Treat AWS Systems Manager, Azure Run Command, and GCP VM Manager, OS Config, metadata, or startup-script activity as cloud-native RMM-equivalent behavior when used outside approved workflow.

·        Treat YARA as conditional forensic support only, not as standing production detection for generic RMM abuse.

Alert Triage Priorities

·        Prioritize alerts involving identity systems, backup infrastructure, security tooling, privileged access workstations, executive endpoints, regulated-data systems, production-critical servers, cloud management systems, and systems where RMM use is prohibited.

·        Prioritize alerts where RMM execution originates from browser, email, document, archive utility, collaboration tool, shell, or script interpreter parent process.

·        Prioritize alerts where RMM activity is followed by high-risk command activity.

·        Prioritize alerts where remote management is initiated by unapproved users, unapproved roles, unapproved service accounts, unapproved source locations, or unexpected automation identities.

·        Prioritize alerts with missing support ticket, missing change record, missing session ownership, or mismatch between endpoint, user, command category, and approved workflow.

Initial SOC Validation Steps

·        Confirm whether the RMM tool, remote support platform, cloud-native command path, or remote management mechanism is approved.

·        Identify the endpoint, workload, user, source, process, parent process, command line, session owner, and target asset role.

·        Determine whether the activity occurred on a restricted endpoint or high-value workload.

·        Validate whether a support ticket, change record, approved session, or approved deployment workflow exists.

·        Review whether the activity included persistence, unattended access, relay communication, high-risk command execution, or cloud-native access enablement.

·        Determine whether the observed activity is part of a broader sequence across endpoint, network, identity, or cloud telemetry.

Escalation Criteria

·        Escalate immediately when RMM activity occurs on identity systems, backup systems, security tooling, privileged access workstations, executive endpoints, regulated-data systems, or production-critical workloads without approved workflow.

·        Escalate immediately when RMM activity is followed by credential access, lateral movement, defense evasion, backup interference, data staging, remote execution, or ransomware-preparation commands.

·        Escalate immediately when AWS Systems Manager, Azure Run Command, or GCP-native management activity is used by unapproved principals against restricted workloads.

·        Escalate immediately when remote-management enablement is followed by remote command activity and a strong correlation key exists.

·        Escalate immediately when an RMM session lacks valid support ownership and originates from suspicious identity or source context.

Containment Guidance

·        Validate alert confidence before disruptive containment where legitimate support activity is plausible.

·        Isolate endpoint or workload when RMM activity is paired with high-risk command execution, credential access, backup interference, or ransomware-preparation behavior.

·        Disable unauthorized RMM session, revoke session tokens, or terminate remote support connection where supported.

·        Remove unauthorized unattended-access configuration, services, scheduled tasks, registry autoruns, or startup mechanisms.

·        Revoke or rotate credentials associated with suspicious RMM or cloud-native remote-management activity.

·        Revoke unauthorized IAM roles, service accounts, managed identities, access keys, session permissions, or policy assignments used to enable remote management.

·        Preserve logs, command history, session metadata, cloud audit logs, and endpoint artifacts before remediation where feasible.

Investigation Workflow

·        Start with the initial rule trigger and identify the detection anchor.

·        Determine whether the activity represents introduction, persistence, outbound control, post-compromise command execution, or cloud-native remote-management abuse.

·        Build the event timeline from RMM execution or cloud-native remote command initiation through follow-on activity.

·        Correlate endpoint process events with DNS, proxy, network flow, identity, helpdesk, ticketing, EDR, cloud audit, and asset context.

·        Review process ancestry and command-line behavior for staging, enumeration, credential access, lateral movement, service control, backup interference, or file transfer.

·        Validate whether activity is consistent with approved support workflow.

·        Identify whether activity remained on one endpoint or expanded to other systems.

·        Determine whether the RMM or cloud-native management pathway was used to deploy additional tooling, modify persistence, access credentials, or prepare ransomware activity.

Cloud Implementation Guidance

·        Deploy AWS, Azure, and GCP rules only where cloud audit logs, identity context, source context, workload tagging, and approved administrative baselines are available.

·        Treat cloud-native rules as conditional detections, not as evidence of third-party RMM binary execution.

·        Keep setup-to-control cloud rules in hunting or pilot mode when only same-account, same-subscription, or same-project correlation is available.

·        Require stronger cloud correlation through same principal, same assumed role, same managed identity, same resource, same target workload, same instance profile, same service account, same workload group, or same approved change workflow.

·        Do not claim confirmed high-risk command execution where command content, command output, guest logs, endpoint telemetry, or equivalent command visibility is unavailable.

·        Use reduced-confidence cloud alerts for triage and enrichment when command content is unavailable.

Tuning and Baseline Guidance

·        Build an approved RMM inventory covering products, executables, paths, tenants, management servers, support users, support hosts, and deployment mechanisms.

·        Build restricted endpoint and workload inventories covering identity systems, backup systems, security tooling, privileged access workstations, executive endpoints, regulated-data systems, cloud management systems, and production-critical workloads.

·        Build approved support workflow baselines including ticket context, user roles, endpoint roles, session ownership, command categories, and approved source locations.

·        Build cloud administrative baselines for IAM roles, managed identities, service accounts, source locations, approved automation identities, workload tags, and change workflows.

·        Review exceptions periodically to prevent approved tools or approved identities from becoming blanket suppressions.

·        Preserve high-risk command detections even where RMM tooling is approved elsewhere in the organization.

Non-Deployment Guardrails

·        Do not deploy product-name-only RMM detections as high-confidence production rules.

·        Do not suppress all activity from approved RMM tools.

·        Do not suppress high-risk commands solely because a support ticket exists.

·        Do not treat cloud-native Run Command, Systems Manager, OS Config, or metadata activity as malicious without identity, source, target, workflow, or command context.

·        Do not treat YARA product-string or signer-based RMM detections as production coverage.

·        Do not rely on same-account, same-subscription, or same-project matching alone for setup-to-control cloud detections.

·        Do not require same-user correlation for RMM-launched activity unless validated in the customer environment.

Operational Success Criteria

·        Alerts identify unauthorized RMM introduction or control-channel activity with actionable context.

·        Analysts can determine whether activity is approved, unauthorized, suspicious, or confirmed malicious.

·        Alerts include endpoint, user, asset role, process, command line, source, destination, support context, and rule rationale where available.

·        Cloud alerts include principal, role, source, target resource, workload criticality, operation, command context where available, and correlation key.

·        False positives are reduced through approved-baseline validation without suppressing high-risk behavior.

·        Detection content remains deployable across different maturity tiers without weakening evidence requirements.

S29 — Detection Coverage Summary

Coverage Overview

The S25 rule set provides strong behavioral coverage for RMM abuse where endpoint process telemetry, command-line visibility, SIEM correlation, network telemetry, cloud audit logs, identity context, and approved support baselines are available. Coverage is strongest for unauthorized introduction, suspicious execution context, RMM-associated persistence, RMM-associated post-compromise command execution, and cloud-native remote-management abuse.

Coverage is intentionally limited for generic file-content detection, product-name-only matching, and network-only control-channel detection because those approaches do not reliably distinguish legitimate support tooling from adversary-controlled RMM abuse.

Overall Coverage Assessment

·        Overall detection coverage: High for endpoint and SIEM-observable RMM abuse.

·        Network-only coverage: Conditional.

·        Cloud-native coverage: Moderate to high where cloud logs and workload baselines are mature.

·        File-content coverage: Low for standing production detection.

·        Operational confidence: Dependent on telemetry quality, command-line visibility, endpoint identity normalization, cloud audit log completeness, approved support workflows, and asset criticality mapping.

Coverage by Threat Stage

Initial Access and RMM Introduction

·        Coverage level: High.

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Supported by Suricata when outbound infrastructure access is present.

·        Primary dependency: Endpoint process telemetry, parent process, command line, execution path, user context, and approved RMM baseline.

·        Residual gap: User-driven legitimate support sessions may resemble unauthorized introduction without support workflow context.

Persistence and Unattended Access

·        Coverage level: High.

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Covered in cloud-native form by AWS, Azure, and GCP setup-to-control or metadata rules.

·        Primary dependency: Service creation, scheduled task, registry, install, command-line, software inventory, metadata, IAM, and cloud control-plane telemetry.

·        Residual gap: Approved RMM tools commonly create persistence, so workflow and baseline context are required.

Outbound RMM Control-Channel Activity

·        Coverage level: Conditional.

·        Covered by Suricata and SIEM correlation where network context can be tied to endpoint or asset context.

·        Primary dependency: DNS, proxy, TLS, HTTP, network flow, restricted asset inventory, approved RMM destination inventory, and support workflow context.

·        Residual gap: Network-only RMM infrastructure access has limited confidence because legitimate RMM relay traffic may be common.

Post-Compromise Command Execution

·        Coverage level: High where command-line telemetry is available.

·        Covered by SentinelOne, Splunk, Elastic, QRadar, and Sigma.

·        Covered by AWS, Azure, and GCP when cloud-native command or metadata execution is visible.

·        Primary dependency: Command-line telemetry, process lineage, endpoint identity, RMM process context, cloud command content, guest logs, endpoint telemetry, and correlation windows.

·        Residual gap: Missing command-line visibility materially reduces confidence.

Credential Access and Discovery

·        Coverage level: Moderate to high.

·        Covered by high-risk post-compromise command rules.

·        Primary dependency: Command line, parent process, endpoint identity, process timing, identity telemetry, and RMM process context.

·        Residual gap: Commands launched through helper processes, service context, or cloud-native tooling may require enrichment to preserve attribution.

Lateral Movement Preparation

·        Coverage level: Moderate to high.

·        Covered by high-risk post-compromise command rules.

·        Primary dependency: Remote execution utility use, service control, scheduled task commands, administrative tool usage, endpoint identity, and process lineage.

·        Residual gap: Lateral movement may occur outside RMM process lineage after the adversary pivots.

Defense Evasion, Backup Interference, and Ransomware Preparation

·        Coverage level: High where endpoint or cloud command telemetry exists.

·        Covered by endpoint, SIEM, Sigma, and cloud-native command rules.

·        Primary dependency: Command-line telemetry, process events, service control events, backup and recovery command usage, endpoint role, workload criticality, and command output where available.

·        Residual gap: Some destructive actions may be executed through approved administrative scripts or automation tooling.

Cloud-Native Remote Management Abuse

·        Coverage level: Moderate to high where cloud telemetry is mature.

·        Covered by AWS, Azure, and GCP conditional rules.

·        Primary dependency: Cloud audit logs, identity context, source context, resource tags, workload criticality, IAM or RBAC baselines, service-account or managed identity context, command visibility, and approved workflow data.

·        Residual gap: Cloud detections do not cover third-party RMM binaries unless endpoint telemetry is integrated.

File-Content Detection

·        Coverage level: Low for standing production detection.

·        YARA rule count: 0.

·        Primary dependency: Sample-specific malicious artifact availability.

·        Residual gap: Legitimate RMM binaries are not meaningfully distinguishable as malicious through generic YARA matching.

Coverage by Detection System

Suricata

·        Coverage level: Conditional.

·        Strength: Network visibility into unauthorized RMM relay or remote-support infrastructure access from restricted endpoint populations.

·        Limitation: Cannot reliably determine user, process, session ownership, or authorization without enrichment.

·        Final rule count: 1.

SentinelOne

·        Coverage level: High for endpoint-observable execution, persistence, and post-compromise behavior.

·        Strength: Endpoint process, parent-child, command, persistence, and behavioral context.

·        Limitation: Requires accurate RMM process coverage, customer-specific approved support baselines, and validation of local SentinelOne field availability.

·        Final rule count: 3.

Splunk

·        Coverage level: High where endpoint, network, identity, and cloud logs are normalized.

·        Strength: Correlation across process, command, network, identity, and support workflow data.

·        Limitation: Requires field normalization, lookup quality, and approved baseline maintenance.

·        Final rule count: 3.

Elastic

·        Coverage level: High where endpoint and SIEM telemetry are available.

·        Strength: Endpoint process behavior, persistence logic, sequence-style behavior, and correlation.

·        Limitation: Network correlation should only be claimed where endpoint-network telemetry is explicitly available.

·        Final rule count: 3.

QRadar

·        Coverage level: Moderate to high where custom properties and reference sets are mature.

·        Strength: SIEM correlation, CRE sequence logic, endpoint process normalization, and approved workflow context.

·        Limitation: Detection quality depends on custom property extraction, endpoint identity normalization, and reference set quality.

·        Final rule count: 2.

Sigma

·        Coverage level: High as portable detection content.

·        Strength: Cross-platform rule portability for Windows process creation behavior.

·        Limitation: Backend translation and field mapping must be validated.

·        Final rule count: 3.

YARA

·        Coverage level: Low for production detection.

·        Strength: Conditional forensic use for malicious wrappers, loaders, droppers, trojanized installers, or campaign-specific artifacts.

·        Limitation: Not suitable for generic RMM abuse detection.

·        Final rule count: 0.

AWS

·        Coverage level: Moderate to high for AWS-native remote management abuse.

·        Strength: Systems Manager, IAM, EC2 instance profile, and setup-to-control detection.

·        Limitation: Does not cover third-party RMM binaries without endpoint telemetry; command visibility and strong correlation are required.

·        Final rule count: 3 conditional cloud-native rules.

Azure

·        Coverage level: Moderate to high for Azure-native remote command abuse.

·        Strength: Azure Run Command, Azure Arc Run Command, RBAC, managed identity, VM extension, and setup-to-control detection.

·        Limitation: Does not cover third-party RMM binaries without endpoint telemetry; command visibility and strong correlation are required.

·        Final rule count: 3 conditional cloud-native rules.

GCP

·        Coverage level: Moderate to high for GCP-native remote management and metadata-based execution.

·        Strength: VM Manager, OS Config, Compute metadata, startup scripts, IAM, service accounts, and setup-to-control detection.

·        Limitation: Does not cover third-party RMM binaries without endpoint telemetry; request visibility and strong correlation are required.

·        Final rule count: 3 conditional cloud-native rules.

Coverage Gaps

·        Generic product-name RMM detection is intentionally avoided.

·        Third-party RMM binaries on cloud workloads require endpoint telemetry integration.

·        Network-only detection cannot reliably establish authorization or user intent.

·        Missing command-line telemetry reduces confidence across endpoint and cloud rules.

·        Missing endpoint identity normalization weakens same-endpoint correlation.

·        Missing support ticket, session ownership, and change-control context increases false positives.

·        Cloud setup-to-control rules require stronger correlation than same-account, same-subscription, or same-project matching.

·        YARA is not production viable without a sample-specific malicious artifact.

Coverage Improvement Priorities

·        Improve endpoint process creation and command-line logging.

·        Normalize endpoint identity across EDR, SIEM, DNS, proxy, and cloud telemetry.

·        Maintain approved RMM inventory, tenant identifiers, support users, support hosts, deployment paths, and session workflows.

·        Maintain restricted asset and workload inventories.

·        Integrate helpdesk, ticketing, change-control, and RMM platform audit logs.

·        Enable cloud audit logs across accounts, subscriptions, projects, regions, and folders.

·        Improve cloud command-content visibility through session logs, command output logging, guest logs, or endpoint telemetry.

·        Improve approved IAM, RBAC, service-account, managed identity, and source-location baselines.

·        Use strong setup-to-control correlation keys rather than broad cloud account, subscription, or project matching.

S30 — Intelligence Maturity Assessment

Maturity Overview

The intelligence maturity assessment evaluates how well the detection strategy converts RMM abuse tradecraft into actionable, deployable, and operationally useful detection coverage. The report demonstrates strong maturity where behavior and telemetry are observable, but maturity remains dependent on customer telemetry quality, baseline completeness, cloud audit visibility, support workflow documentation, and SOC enrichment capability.

RMM abuse is not a single-indicator threat. Mature detection requires combining endpoint behavior, network context, identity context, support workflow validation, asset criticality, cloud audit activity, and post-compromise command behavior.

Overall Intelligence Maturity Rating

·        Intelligence maturity rating: High.

·        Operational maturity dependency: Moderate to high.

·        Primary maturity strength: Behavior-driven detection across endpoint, SIEM, Sigma, and cloud-native systems.

·        Primary maturity constraint: Approved workflow and telemetry dependency.

·        Assessment: Mature detection strategy with deployment confidence dependent on environment-specific telemetry and baseline readiness.

Threat Understanding Maturity

·        Rating: High.

·        The report correctly treats RMM abuse as legitimate-tool misuse rather than malware-family behavior.

·        The report distinguishes product presence from unauthorized control.

·        The report separates introduction, persistence, outbound control, post-compromise execution, and cloud-native remote-management abuse.

·        The report preserves YARA as conditional forensic support rather than forcing weak file-content detection.

·        The report recognizes that AWS, Azure, and GCP detections are cloud-native equivalents rather than third-party RMM binary detections.

Telemetry Maturity

·        Rating: Moderate to high.

·        Endpoint and SIEM detections are strong where process creation, command line, parent process, endpoint identity, and asset role data are available.

·        Network detection is conditional because RMM infrastructure may be legitimate and requires endpoint, asset, identity, and support context.

·        Cloud detection is strong where CloudTrail, Azure Activity, Google Cloud Audit Logs, resource tags, identity context, and approved baselines are available.

·        YARA maturity is intentionally low for production use because file-content matching does not solve the primary detection problem.

Detection Engineering Maturity

·        Rating: High.

·        The S25 rule set avoids weak product-name-only detection.

·        The rule set prioritizes behavioral anchors, suspicious context, persistence behavior, high-risk follow-on commands, and cloud-native setup-to-control sequences.

·        The rule set avoids forced rule counts where detection would be weak.

·        The rule set uses system-native formats and system-appropriate logic.

·        The rule set includes conditional handling for reduced-confidence cloud command detection.

·        The rule set maintains rule boundaries between endpoint, SIEM, network, Sigma, YARA, and cloud-native systems.

Operationalization Maturity

·        Rating: Moderate to high.

·        Operationalization is strongest where approved RMM inventory, restricted asset inventory, helpdesk context, change-control data, RMM platform logs, identity telemetry, and endpoint telemetry are integrated.

·        SOC triage is viable because the rule set produces contextual alerts rather than simple product matches.

·        Production deployment requires baseline maintenance and exception governance.

·        Cloud setup-to-control detections should remain hunting or pilot mode where strong correlation keys are unavailable.

·        Reduced-confidence cloud detections should be used for enrichment and investigation rather than confirmed high-risk command execution.

Adversary Resilience Maturity

·        Rating: High.

·        The strategy remains useful if attackers use legitimate signed RMM tools.

·        The strategy remains useful if attackers use multiple RMM vendors.

·        The strategy remains useful if attackers avoid malware and rely on cloud-native remote management.

·        The strategy remains useful when RMM is launched from social-engineering, browser download, collaboration-tool, or script-based workflows.

·        The strategy is less resilient where command-line telemetry is missing or where attackers move outside observable process lineage.

Baseline and Context Maturity

·        Rating: Moderate.

·        Detection value depends heavily on approved RMM inventory, support workflow documentation, endpoint role mapping, cloud role baselines, source baselines, and workload tagging.

·        Weak baseline maturity increases false positives.

·        Strong baseline maturity enables the rules to distinguish approved support from unauthorized control.

·        Baseline quality is the largest driver of operational confidence after command-line and cloud audit log availability.

Cloud Intelligence Maturity

·        Rating: Moderate to high.

·        AWS, Azure, and GCP coverage correctly focuses on cloud-native remote management pathways.

·        The report avoids treating cloud platforms as generic third-party RMM binary sensors.

·        Cloud rules properly require identity, source, target, resource, role, and workflow context.

·        Setup-to-control cloud rules correctly reject weak same-account, same-subscription, or same-project correlation as sufficient production evidence.

·        Cloud command-detection maturity depends on command content, command output, guest logs, endpoint telemetry, or equivalent visibility.

Residual Intelligence Gaps

·        Limited visibility where command-line telemetry is absent.

·        Limited visibility where endpoint-to-network correlation is unavailable.

·        Limited visibility where cloud command content or command output is unavailable.

·        Limited visibility where support workflows are undocumented.

·        Limited visibility where RMM platform audit logs are not ingested.

·        Limited visibility where asset criticality, endpoint role, workload labels, or restricted asset inventories are incomplete.

·        Limited visibility where service-account, managed identity, or assumed-role attribution is incomplete.

·        Limited ability to use YARA without sample-specific malicious artifacts.

Maturity Improvement Recommendations

·        Improve endpoint command-line and parent-process capture.

·        Normalize endpoint identity across SIEM, EDR, DNS, proxy, and cloud telemetry.

·        Maintain a current approved RMM inventory and approved deployment baseline.

·        Maintain restricted endpoint and cloud workload inventories.

·        Integrate helpdesk, ticketing, change-control, and RMM platform audit logs into detection workflows.

·        Enable and centralize AWS CloudTrail, Azure Activity logs, and Google Cloud Audit Logs across all relevant scopes.

·        Improve cloud command visibility through session transcripts, command output logging, guest telemetry, and endpoint telemetry.

·        Maintain IAM, RBAC, service-account, managed identity, assumed-role, and source-location baselines.

·        Pilot setup-to-control cloud detections until strong correlation keys are validated.

·        Reserve YARA for sample-specific malicious wrappers, loaders, droppers, or trojanized artifacts.

Executive Intelligence Assessment

The report is intelligence-mature because it aligns detection to how RMM abuse actually occurs: through legitimate remote administration tools, approved-looking binaries, cloud-native remote command channels, and post-compromise use of trusted management paths. The detection strategy is strongest when organizations can correlate endpoint process behavior, identity activity, cloud audit logs, network context, and approved support workflows. The primary maturity risk is not lack of detection design; it is incomplete telemetry, weak baselines, and insufficient operational context.

S31 — Telemetry Dependencies

Telemetry Dependency Overview

Effective detection and response for RMM tool abuse depend on whether the organization can connect remote administration activity to authorization, ownership, endpoint scope, identity context, support workflow, and follow-on behavior. This section defines the operational dependencies required to make the detection model reliable in production. It does not restate every telemetry requirement; it identifies which telemetry relationships must exist for the SOC to prove whether RMM activity is approved, suspicious, or attacker-controlled.

The central dependency is correlation. RMM execution alone may show tool presence, but not tenant legitimacy. Network telemetry may show relay communication, but not session ownership. Identity telemetry may show account activity, but not command behavior. Cloud telemetry may show remote command activity, but not endpoint process effects unless workload or guest telemetry is available. A reliable detection model therefore depends on layered evidence across endpoint, identity, network, cloud, RMM platform, asset, and support workflow sources.

Primary Dependency Relationships

·        RMM execution must be correlated with endpoint role, user context, parent process, execution path, tenant ownership, and approved deployment path.

·        RMM persistence must be correlated with approved installation workflow, endpoint authorization, service or task creation, unattended-access settings, and support or change records.

·        RMM outbound communication must be correlated with process context, endpoint identity, restricted asset status, approved destination inventory, and support workflow metadata.

·        RMM-launched command activity must be correlated with parent process, command line, user or service context, endpoint role, timing, and approved support purpose.

·        Cloud-native remote management activity must be correlated with principal, role, source, target workload, workload tag, change record, command visibility, and approved administrative scope.

·        Service-provider activity must be correlated with named account, delegated access scope, target environment, support ticket, session ownership, and customer authorization.

·        Alerts must be enriched with asset criticality, restricted endpoint classification, identity risk, support context, and prior related activity before escalation decisions.

Endpoint Telemetry Dependencies

·        Process creation telemetry with parent process, child process, command line, executable path, user context, integrity level, signature context, and endpoint identity.

·        Service creation and service modification telemetry.

·        Scheduled task creation and modification telemetry.

·        Registry autorun and startup-location telemetry.

·        File creation, download, extraction, installation, and execution-path telemetry.

·        Software inventory showing installed RMM tools, remote support clients, agents, versions, tenants, management servers, and deployment paths where available.

·        Endpoint role and asset criticality context, including identity systems, backup servers, privileged access workstations, executive endpoints, security tooling, regulated-data systems, cloud management systems, and production-critical workloads.

·        Endpoint security telemetry showing tampering, exclusions, sensor degradation, disabled protections, logging changes, or abnormal remediation behavior.

Identity and Access Telemetry Dependencies

·        User authentication and sign-in telemetry.

·        Privileged account activity.

·        Helpdesk, technician, service-provider, service-account, and administrative identity activity.

·        Identity provider logs with source location, device, risk, session, and conditional access context where available.

·        Privileged access management records, just-in-time access approvals, break-glass usage, and administrative role activation.

·        Service-provider and delegated administration identity logs.

·        Cloud role, service-account, managed identity, and assumed-role activity.

·        Credential reset, token revocation, session invalidation, and privileged access review telemetry during response.

Network and Outbound Communication Telemetry Dependencies

·        DNS telemetry for RMM relay, broker, support, or remote-control infrastructure.

·        Proxy telemetry with URL, domain, category, user, endpoint, and request metadata.

·        TLS and HTTP metadata where available.

·        Network flow telemetry for outbound session timing, destination, volume, and endpoint correlation.

·        Firewall and secure web gateway telemetry.

·        RMM destination inventory, approved relay infrastructure, support portals, management servers, and known tenant infrastructure where available.

·        Restricted endpoint network policy context for systems where RMM communication is prohibited or tightly controlled.

RMM Platform and Support Workflow Telemetry Dependencies

·        RMM platform audit logs, including session creation, technician identity, tenant, target endpoint, connection time, file transfer, remote shell, script execution, policy change, and unattended-access configuration where available.

·        Support ticket, helpdesk, and change-management records.

·        Approved support workflow metadata, including ticket owner, endpoint owner, technician identity, support reason, command category, session approval, and expected time window.

·        Approved RMM inventory, including tools, executables, tenants, management servers, support users, deployment paths, source locations, and endpoint scopes.

·        Service-provider access records and delegated administration approvals.

·        Exceptions and allowlists tied to tool, user, endpoint, tenant, source, and workflow rather than product name alone.

Cloud Telemetry Dependencies

·        AWS CloudTrail, Systems Manager activity, IAM role activity, assumed-role issuer context, EC2 instance profile events, AWS Config, EC2 tags, Systems Manager command output logs, and session transcript logs where enabled.

·        Azure Activity logs, Azure Run Command activity, Azure Arc activity, RBAC changes, managed identity activity, VM extension events, Microsoft Entra ID context, Log Analytics, and Defender telemetry where available.

·        Google Cloud Audit Logs, VM Manager logs, OS Config logs, Compute Engine metadata changes, IAM policy history, service-account context, Cloud Asset Inventory, and Security Command Center telemetry where available.

·        Cloud workload tags, asset criticality, account, subscription, project, folder, and organization metadata.

·        Cloud command-content visibility through script parameters, command output, guest logs, endpoint telemetry, or equivalent control-plane and workload telemetry.

Correlation and Normalization Dependencies

·        Stable endpoint identity across EDR, SIEM, DNS, proxy, identity, cloud, and RMM platform telemetry.

·        Normalized usernames, service accounts, privileged identities, cloud principals, and service-provider accounts.

·        Consistent timestamps and time-zone normalization across telemetry sources.

·        Field normalization for process name, parent process, command line, executable path, host, user, source IP, destination domain, cloud resource, tenant, and support workflow identifiers.

·        Asset inventory enrichment for endpoint role, restricted system classification, business owner, data sensitivity, and production criticality.

·        Correlation windows that support RMM execution, persistence, outbound relay activity, post-compromise commands, and cloud setup-to-control sequences.

Telemetry Dependency Priority

·        Highest priority dependencies are endpoint process telemetry, command-line visibility, approved RMM inventory, restricted asset inventory, identity context, and support workflow validation.

·        High priority dependencies include DNS, proxy, network flow, software inventory, RMM platform audit logs, cloud audit logs, and service-provider access records.

·        Conditional dependencies include cloud command output, Systems Manager session transcripts, Azure guest telemetry, GCP guest or OS Config telemetry, and service-provider platform logs.

·        Forensic dependencies include file artifacts, recovered installers, malicious wrappers, trojanized packages, and sample-specific YARA use cases.

S32 — Detection Limitations

Detection Limitation Overview

Detection limitations for RMM tool abuse are primarily driven by the legitimate nature of the tools, the ambiguity of support workflows, and the uneven availability of endpoint, identity, network, cloud, and RMM platform telemetry. The largest risk is not that RMM activity is invisible in every environment. The largest risk is that available telemetry may show remote administration activity without enough context to prove whether it is authorized or attacker-controlled.

Detection should therefore be interpreted as a confidence-building process. Product execution, vendor relay traffic, signed binaries, cloud remote command events, or support-session creation are not sufficient alone. Higher confidence requires suspicious context, restricted endpoint scope, unauthorized tenant association, persistence, post-compromise commands, identity deviation, source deviation, or support workflow mismatch.

Tool Legitimacy Limitations

·        Legitimate RMM tools are often signed, vendor-hosted, encrypted, and commonly used for approved administration.

·        Product-name matching alone cannot distinguish approved support from adversary-controlled remote access.

·        Hash-based detection is brittle because legitimate RMM products update frequently.

·        Signer-based detection does not establish whether the session, tenant, endpoint, user, or workflow is authorized.

·        Vendor relay or broker infrastructure may be used for both legitimate and malicious sessions.

Workflow and Authorization Limitations

·        Support tickets may be incomplete, delayed, generic, or disconnected from actual session activity.

·        Approved support workflows may not include command-level detail, session ownership, or endpoint authorization.

·        Helpdesk and service-provider accounts may be shared, poorly attributed, or insufficiently governed.

·        Tenant ownership may be difficult to validate if RMM inventory is incomplete.

·        A support ticket alone should not suppress high-risk commands, persistence creation, or activity on restricted systems.

·        Same-user correlation should not be required unless validated locally because RMM activity may execute under SYSTEM, service accounts, or technician context.

Endpoint Visibility Limitations

·        Missing command-line telemetry reduces confidence in post-compromise command detection.

·        Missing parent-child process telemetry weakens attribution between RMM execution and follow-on activity.

·        Missing service, scheduled task, registry, or software inventory telemetry weakens persistence detection.

·        Endpoint identity inconsistencies can break correlation across EDR, SIEM, DNS, proxy, and RMM platform logs.

·        Sensor tampering, telemetry degradation, endpoint exclusions, or security-tool interference can reduce detection quality during the most important response window.

Network Visibility Limitations

·        Network-only RMM detection cannot reliably determine process, user, tenant, support-session owner, or authorization status.

·        DNS or proxy visibility may identify RMM infrastructure but not whether the session is approved.

·        Official relay infrastructure may be shared across many legitimate customers.

·        Encrypted sessions may limit content inspection.

·        Network visibility is strongest when correlated with endpoint process context, restricted asset inventory, identity context, and support workflow metadata.

Cloud Visibility Limitations

·        Cloud-native remote management detections are conditional and do not prove third-party RMM binary execution.

·        Cloud control-plane logs may not include full command content, output, or guest-level process behavior.

·        Same-account, same-subscription, or same-project correlation alone is insufficient for high-confidence setup-to-control detection.

·        Cloud command visibility depends on service configuration, command output logging, guest telemetry, endpoint telemetry, and audit log retention.

·        Stronger cloud attribution requires principal, assumed role, managed identity, service account, source, target resource, workload tag, and approved change context.

Correlation Limitations

·        Correlation accuracy depends on consistent endpoint names, user identities, timestamps, source IPs, cloud resource identifiers, and tenant metadata.

·        RMM-launched activity may occur under different execution contexts than the initial user session.

·        Tool stacking can make it difficult to determine which remote access path drove follow-on activity.

·        Delayed execution can weaken short correlation windows.

·        Broad correlation windows may increase false positives if approved support and automation are not well baselined.

YARA and File-Content Limitations

·        Generic YARA rules are not production viable for ordinary RMM abuse because legitimate RMM binaries are not inherently malicious.

·        Product strings, signer names, installer names, and generic packed-binary traits are weak signals for this report.

·        YARA is useful only when a malicious wrapper, trojanized installer, dropper, loader, or campaign-specific artifact is recovered.

·        File-content detection should support incident response and forensic validation, not replace behavioral detection.

Operational Limitation Summary

·        Detection confidence is highest when RMM activity is tied to suspicious execution context, unauthorized tenant association, persistence, restricted endpoint activity, high-risk commands, identity deviation, source deviation, or support workflow mismatch.

·        Detection confidence is lower when only product presence, signed binary execution, relay traffic, or generic support activity is observed.

·        Production deployment requires customer-specific baselines for approved RMM use, restricted assets, service-provider workflows, identity context, source locations, cloud workloads, and endpoint roles.

S33 — Defensive Control & Hardening Improvements

Control Improvement Overview

Defensive improvement for RMM tool abuse should focus on governing remote administration as a privileged control channel. The objective is not to block all remote support activity. The objective is to ensure remote administration is inventoried, authorized, attributable, monitored, bounded, and resilient against misuse.

Hardening should reduce unauthorized RMM introduction, prevent durable unattended access where not required, restrict RMM use on high-value systems, improve visibility into post-compromise activity, and ensure service-provider and cloud-native remote management pathways are governed with the same rigor as privileged access.

Remote Administration Governance Improvements

·        Maintain an approved RMM and remote support inventory covering tools, tenants, management servers, executables, support users, deployment paths, source locations, and permitted endpoint groups.

·        Define where RMM is allowed, restricted, or prohibited by endpoint role and business function.

·        Require documented ownership for each RMM tenant, management server, support account, and service-provider pathway.

·        Review RMM exceptions periodically to prevent approved tooling from becoming blanket authorization.

·        Require support workflow alignment for RMM sessions, including ticket, endpoint, user, technician, purpose, source, and time window.

Endpoint Hardening Improvements

·        Restrict RMM execution from user-controlled paths such as Downloads, Temp, AppData, browser cache, archive extraction paths, and cloud-synced folders where operationally feasible.

·        Block unauthorized RMM installers, portable clients, and remote support tools on restricted systems.

·        Require administrative approval for RMM installation, service creation, scheduled tasks, auto-start entries, and unattended-access configuration.

·        Monitor and restrict persistence mechanisms associated with remote administration tools.

·        Harden privileged access workstations, identity systems, backup servers, security tooling, and production-critical servers against direct remote support where not explicitly required.

Identity and Privileged Access Improvements

·        Enforce multi-factor authentication for helpdesk, technician, service-provider, cloud, and privileged administrative accounts.

·        Use least privilege for remote support accounts and endpoint management roles.

·        Require just-in-time or time-bound access for privileged remote administration where possible.

·        Separate ordinary user accounts from support, administrative, and service-provider roles.

·        Monitor privileged access activation, role changes, service-account use, managed identity activity, and cloud role assumption.

·        Revoke or rotate credentials when RMM activity cannot be tied to approved workflow.

RMM Platform and Support Workflow Improvements

·        Enable RMM platform audit logging for session creation, technician identity, target endpoint, file transfer, remote shell, script execution, policy changes, and unattended-access configuration.

·        Require session ownership and ticket linkage for remote support activity.

·        Disable unattended access by default where not required.

·        Restrict file transfer, remote shell, script execution, and clipboard transfer based on endpoint role and support need.

·        Review tenant membership, technician accounts, downstream customer access, and service-provider delegation.

·        Require alerting for new tenant enrollment, new agent installation, unknown management server association, and unattended-access changes.

Network and Egress Hardening Improvements

·        Restrict outbound RMM relay, broker, or remote-support infrastructure access from systems where RMM is prohibited.

·        Use DNS, proxy, firewall, and secure web gateway controls to monitor and govern approved RMM destinations.

·        Require endpoint or user context for remote support network access where possible.

·        Alert on RMM relay communication from identity systems, backup servers, security tooling, executive endpoints, regulated-data systems, and production-critical workloads.

·        Review remote support traffic that occurs outside approved support hours, source locations, or workflows.

Cloud-Native Remote Management Improvements

·        Govern AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, and equivalent remote command features as privileged remote administration pathways.

·        Restrict cloud-native remote command capability to approved roles, approved sources, approved workloads, and documented change workflows.

·        Enable cloud audit logging across all relevant accounts, subscriptions, projects, regions, and folders.

·        Enable command output logging, session transcript logging, guest telemetry, or endpoint telemetry where supported and appropriate.

·        Require stronger setup-to-control correlation using principal, role, resource, workload group, service account, managed identity, or approved change workflow rather than broad account-level matching alone.

Detection and Response Improvements

·        Correlate RMM execution, persistence, outbound relay activity, identity context, restricted endpoint scope, and post-compromise commands.

·        Treat high-risk commands after RMM activity as escalation triggers even when the RMM tool is approved elsewhere.

·        Integrate helpdesk, ticketing, change-control, RMM platform audit logs, endpoint telemetry, network telemetry, and cloud audit logs into investigation workflows.

·        Build response playbooks for unauthorized RMM execution, unattended access, tenant mismatch, service-provider ambiguity, and cloud-native remote command misuse.

·        Preserve logs, session records, command history, and endpoint artifacts before remediation when feasible.

Figure 6

S34 — Defensive Control & Hardening Architecture

Architecture Overview

The defensive architecture for RMM tool abuse should treat remote administration as a governed access layer that spans endpoints, identity systems, support workflows, service-provider access, network egress, cloud control planes, and SOC response. The architecture should not rely on product blocklists alone. It should combine policy, visibility, enforcement, correlation, and response readiness.

The target state is a remote administration control model where authorized RMM use is known, bounded, attributable, logged, and reviewable, while unauthorized remote access is detected through behavioral deviation, restricted asset scope, persistence attempts, suspicious execution context, and high-risk follow-on activity.

Architecture Layer 1 — Approved RMM Governance

·        Maintain authoritative inventory of approved RMM tools, tenants, management servers, support users, service-provider pathways, deployment mechanisms, and permitted endpoint groups.

·        Define approved, restricted, and prohibited RMM usage by endpoint role.

·        Require documented ownership for RMM tenants and management servers.

·        Require ticket or change linkage for support sessions and remote administration activity.

·        Review exceptions, tenants, support users, and service-provider access on a scheduled basis.

Architecture Layer 2 — Endpoint Control and Execution Policy

·        Restrict execution of unauthorized RMM tools and portable clients.

·        Enforce application control or endpoint policy for restricted systems.

·        Monitor RMM execution from user-controlled paths and suspicious parent processes.

·        Restrict service creation, scheduled tasks, registry autoruns, and unattended-access configuration to approved workflows.

·        Protect high-value systems from direct remote support unless explicitly authorized.

Architecture Layer 3 — Identity and Privileged Access Control

·        Require strong authentication for support, technician, service-provider, and cloud administration identities.

·        Separate user, helpdesk, administrator, and service-provider accounts.

·        Use least privilege and time-bound access for remote administration roles.

·        Monitor role activation, privilege changes, service-account use, managed identity activity, and assumed-role activity.

·        Revoke or rotate credentials when remote administration legitimacy cannot be proven.

Architecture Layer 4 — Network Egress and Relay Governance

·        Restrict RMM relay and remote-support infrastructure access from prohibited endpoint groups.

·        Monitor DNS, proxy, TLS, HTTP, and flow telemetry for RMM infrastructure activity.

·        Correlate network activity with endpoint process and support workflow context.

·        Maintain approved RMM destination inventory where feasible.

·        Escalate RMM network activity from identity systems, backup systems, security tooling, regulated-data systems, and production-critical workloads.

Architecture Layer 5 — Cloud Remote Management Governance

·        Treat cloud-native remote command and workload management as privileged remote administration.

·        Restrict AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, and equivalent capabilities to approved identities and workflows.

·        Require cloud audit logging, workload tagging, command visibility, and change-management linkage.

·        Monitor setup-to-control sequences involving IAM, RBAC, service accounts, managed identities, instance profiles, metadata, or extension changes followed by remote command activity.

·        Keep cloud setup-to-control detection in pilot or hunting mode until strong correlation keys are validated.

Architecture Layer 6 — SIEM and Detection Correlation

·        Correlate endpoint process telemetry, persistence artifacts, DNS or proxy activity, identity telemetry, RMM platform logs, cloud audit logs, and support workflow data.

·        Build reference data for approved RMM tools, support users, tenants, management servers, restricted assets, and approved source locations.

·        Prioritize alerts where RMM activity intersects with restricted endpoints, persistence, high-risk commands, cloud remote command activity, or workflow mismatch.

·        Preserve detection logic that identifies high-risk follow-on behavior even when the RMM tool is approved elsewhere.

Architecture Layer 7 — Incident Response and Recovery Assurance

·        Maintain playbooks for unauthorized RMM execution, tenant mismatch, unattended-access setup, RMM-launched high-risk commands, service-provider ambiguity, and cloud-native remote command misuse.

·        Preserve session logs, RMM audit records, command history, endpoint artifacts, identity logs, network records, and cloud audit logs.

·        Validate removal of unauthorized agents, services, scheduled tasks, startup entries, tenants, support sessions, and cloud remote command access.

·        Verify credential security, endpoint trust, backup integrity, and service-provider access after suspicious RMM activity.

·        Require executive escalation when RMM abuse affects restricted systems or cannot be confidently scoped.

S35 — Defensive Control Mapping Matrix

Mapping Overview

The control mapping below connects major RMM abuse risk areas to defensive control objectives, primary implementation actions, and expected risk reduction. It is written as a matrix-style control map without relying on product-specific assumptions.

Control Area 1 — Approved RMM Inventory

Risk Addressed

Unknown or unauthorized RMM tools, tenants, support users, deployment paths, or management servers.

Primary Control Actions

·        Maintain approved RMM inventory.

·        Map tenants, tools, management servers, support accounts, deployment paths, and endpoint groups.

·        Review inventory and exceptions regularly.

·        Tie approved use to support workflows and endpoint role.

Expected Risk Reduction

Reduces ambiguity between legitimate support activity and attacker-controlled remote access.

Control Area 2 — Restricted Endpoint Policy

Risk Addressed

RMM activity on identity systems, backup servers, privileged access workstations, executive endpoints, security tooling, regulated-data systems, or production-critical workloads.

Primary Control Actions

·        Define restricted endpoint populations.

·        Prohibit or tightly control RMM on high-value systems.

·        Alert on RMM execution, network activity, persistence, or remote command activity on restricted systems.

·        Require explicit approval for exceptions.

Expected Risk Reduction

Limits remote-control exposure on systems where compromise would create high business impact.

Control Area 3 — Execution and Persistence Control

Risk Addressed

User-driven RMM installation, suspicious execution paths, persistent agents, unattended access, services, scheduled tasks, and startup mechanisms.

Primary Control Actions

·        Restrict execution from user-controlled paths.

·        Monitor suspicious parent processes and installation paths.

·        Control service creation, scheduled tasks, registry autoruns, and unattended-access configuration.

·        Require administrative approval for persistent RMM installation.

Expected Risk Reduction

Reduces unauthorized RMM introduction and prevents temporary access from becoming durable control.

Control Area 4 — Identity and Privileged Access Governance

Risk Addressed

Compromised helpdesk accounts, service-provider accounts, technician accounts, service accounts, cloud roles, and managed identities.

Primary Control Actions

·        Enforce multi-factor authentication.

·        Use least privilege and time-bound access.

·        Separate user, support, administrative, and service-provider identities.

·        Monitor role activation, privilege changes, source deviations, and unusual session behavior.

Expected Risk Reduction

Reduces adversary ability to legitimize remote administration through compromised or overprivileged accounts.

Control Area 5 — RMM Platform Audit Logging

Risk Addressed

Lack of session ownership, tenant validation, remote shell visibility, file transfer tracking, and unattended-access change history.

Primary Control Actions

·        Enable RMM platform audit logging.

·        Capture session owner, target endpoint, technician identity, file transfer, script execution, remote shell, policy changes, and unattended-access configuration.

·        Integrate RMM logs into SIEM and case management.

·        Review tenant and technician activity.

Expected Risk Reduction

Improves attribution and reduces time required to distinguish approved support from unauthorized remote control.

Control Area 6 — Network and Egress Governance

Risk Addressed

Unauthorized RMM relay, broker, or remote-support infrastructure access from prohibited systems.

Primary Control Actions

·        Monitor DNS, proxy, TLS, HTTP, and flow telemetry.

·        Maintain approved RMM destination context.

·        Restrict RMM infrastructure access from prohibited endpoint populations.

·        Correlate network activity with endpoint and support workflow data.

Expected Risk Reduction

Improves visibility into remote-control activity and limits unauthorized outbound support channels.

Control Area 7 — Cloud Remote Management Governance

Risk Addressed

Unauthorized use of cloud-native remote command, metadata execution, workload management, or setup-to-control activity.

Primary Control Actions

·        Restrict AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, and equivalent features.

·        Enforce approved roles, approved sources, workload tagging, and change workflows.

·        Enable cloud audit logs and command visibility where available.

·        Correlate access enablement with subsequent remote command activity.

Expected Risk Reduction

Reduces RMM-equivalent control risk in cloud workloads and improves attribution of cloud-native remote administration.

Control Area 8 — SOC Correlation and Response

Risk Addressed

Delayed triage, false positives, incomplete scoping, and missed post-compromise behavior.

Primary Control Actions

·        Correlate endpoint, identity, network, cloud, RMM platform, and support workflow telemetry.

·        Prioritize high-risk commands after RMM activity.

·        Use playbooks for unauthorized RMM execution, tenant mismatch, unattended access, service-provider ambiguity, and cloud remote command misuse.

·        Preserve artifacts before remediation.

Expected Risk Reduction

Improves detection confidence, response speed, containment quality, and recovery assurance.

S36 — CyberDax Intelligence Maturity Assessment

CyberDax Implementation Readiness Overview

This assessment evaluates whether the organization can operationalize the intelligence and detection strategy in this report. S30 assessed intelligence maturity at the report level. S36 focuses on implementation readiness: whether governance, telemetry, detection deployment, SOC workflows, escalation paths, and improvement cycles are mature enough to convert the report’s findings into durable defensive capability.

For RMM tool abuse, CyberDax maturity is measured by the organization’s ability to prove that remote administration is authorized, attributable, bounded, monitored, and resilient against misuse. A mature program can quickly determine whether an RMM session, tenant, endpoint, user, support workflow, service-provider connection, or cloud remote command action is legitimate. An immature program may see the same activity but remain unable to decide whether it represents approved support or adversary control.

Governance Readiness

Maturity Rating

Moderate.

Governance readiness depends on whether approved RMM tools, tenants, management servers, support users, deployment paths, service-provider access, and permitted endpoint groups are documented and actively maintained. Many organizations rely on remote administration but do not maintain enough ownership, tenant, exception, or endpoint-scope data to support rapid incident decisions.

Telemetry Readiness

Maturity Rating

Moderate to High.

Telemetry readiness is strong where endpoint process telemetry, command-line capture, identity logs, RMM platform audit logs, DNS or proxy telemetry, cloud audit logs, and support workflow data are integrated. Readiness decreases when telemetry sources exist in isolation and cannot be correlated by endpoint, user, tenant, source, resource, or ticket context.

Detection Deployment Readiness

Maturity Rating

High where baselines are available; moderate where baselines are immature.

Detection deployment readiness depends on approved RMM inventory, restricted endpoint classification, service-provider mapping, cloud workload tagging, source baselines, and support workflow validation. The strongest detection content in this report is behavior-driven and deployable, but low-noise production operation requires local baselines and normalization.

SOC Workflow Readiness

Maturity Rating

Moderate to High.

SOC workflow readiness depends on whether analysts can validate tool legitimacy, tenant ownership, session ownership, endpoint authorization, support ticket context, command activity, and persistence state without lengthy manual investigation. Mature SOC workflows should include triage paths for unauthorized RMM execution, tenant mismatch, unattended access, service-provider ambiguity, RMM-launched high-risk commands, and cloud-native remote command misuse.

Escalation and Response Readiness

Maturity Rating

Moderate.

Escalation readiness depends on whether the organization has predefined thresholds for restricted endpoint activity, unattended-access configuration, high-risk command execution, credential access, service-provider exposure, cloud remote command abuse, backup interference, and unresolved ownership ambiguity. RMM incidents can escalate quickly when the organization cannot prove scope, remove access, validate credentials, or confirm recovery integrity.

Continuous Improvement Readiness

Maturity Rating

Moderate.

Continuous improvement readiness depends on whether RMM exceptions, support workflows, service-provider access, detection logic, tenant inventories, cloud permissions, and restricted endpoint classifications are reviewed after alerts and incidents. Mature programs use RMM-related incidents to improve governance data, telemetry coverage, playbooks, and support workflow controls.

Overall CyberDax Readiness Assessment

Overall CyberDax readiness is Moderate to High. The report provides a mature behavior-driven detection and hardening model, but implementation success depends on governance and operational proof. The priority is to convert remote administration from an implicitly trusted workflow into an explicitly governed control channel with defined ownership, visibility, authorization, enforcement, and response assurance.

S37 — Strategic Defensive Improvements

Strategic Improvement Overview

Strategic improvement should focus on reducing the organization’s dependence on implicit trust in remote administration tooling. RMM and cloud-native remote management should be treated as privileged access pathways that require inventory, authorization, monitoring, segmentation, and response assurance.

The strongest long-term improvement is not a single detection rule or product blocklist. The strongest improvement is a remote administration governance model that clearly defines which tools are allowed, which systems may be reached, which users may initiate sessions, which tenants are authorized, which support workflows are valid, and which activities require immediate escalation.

Strategic Improvement 1 — Establish Remote Administration Governance

·        Create an enterprise-owned remote administration standard.

·        Define approved RMM tools, tenants, management servers, support roles, source locations, and deployment mechanisms.

·        Classify endpoint groups where RMM is approved, restricted, or prohibited.

·        Require periodic review of tenants, support users, service-provider access, and exceptions.

·        Treat cloud-native remote command features as part of the remote administration governance model.

Strategic Improvement 2 — Restrict RMM on High-Value Systems

·        Prohibit or tightly control RMM on identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, cloud management systems, and production-critical workloads.

·        Require documented exception approval for remote support on restricted systems.

·        Alert on RMM execution, persistence, outbound relay activity, or remote command behavior involving restricted systems.

·        Use separate administrative pathways for high-value systems where feasible.

Strategic Improvement 3 — Mature Service-Provider Oversight

·        Maintain service-provider access inventories.

·        Require named accounts and strong authentication for service-provider access.

·        Review delegated administration permissions regularly.

·        Require logging and notification for service-provider remote support sessions.

·        Validate downstream customer exposure where service-provider compromise or misuse is suspected.

Strategic Improvement 4 — Improve Telemetry and Correlation Readiness

·        Improve endpoint command-line, parent process, service, scheduled task, registry, and software inventory telemetry.

·        Integrate RMM platform audit logs into SIEM and investigation workflows.

·        Normalize endpoint identity across EDR, SIEM, DNS, proxy, identity, cloud, and RMM sources.

·        Integrate helpdesk, ticketing, change-control, and support workflow data.

·        Improve cloud audit logging, workload tagging, command visibility, and identity context.

Strategic Improvement 5 — Strengthen RMM-Specific Detection and Response

·        Maintain detection for suspicious RMM execution, unauthorized persistence, restricted endpoint activity, outbound relay behavior, post-compromise commands, tenant mismatch, and cloud-native remote command misuse.

·        Use response playbooks for unauthorized RMM introduction, unattended-access configuration, service-provider ambiguity, and RMM-launched high-risk activity.

·        Treat high-risk commands after RMM activity as escalation triggers.

·        Preserve session logs, endpoint artifacts, identity records, network records, and cloud audit logs before remediation.

Strategic Improvement 6 — Reduce Recovery and Assurance Burden

·        Define procedures for removing unauthorized RMM agents, services, scheduled tasks, startup entries, tenants, sessions, and cloud remote command access.

·        Validate endpoint trust after suspicious remote administration activity.

·        Confirm backup integrity and recovery readiness after RMM-associated defense evasion or backup interference.

·        Require credential review, token revocation, and privileged access validation when RMM legitimacy cannot be proven.

·        Conduct post-incident review of remote administration governance and service-provider controls.

Strategic Improvement 7 — Align Executive Oversight to Remote Access Risk

·        Report RMM governance status as part of privileged access and third-party-risk oversight.

·        Track approved RMM inventory maturity, restricted endpoint coverage, telemetry completeness, and service-provider access review status.

·        Require evidence that remote support activity is attributable, bounded, logged, and tied to approved workflow.

·        Escalate unresolved RMM ownership, tenant mismatch, or unauthorized persistence as business-risk issues rather than routine endpoint alerts.

Strategic Improvement Priorities

·        First priority: establish approved RMM inventory, restricted endpoint policy, and support workflow validation.

·        Second priority: integrate endpoint, identity, RMM platform, network, cloud, and ticketing telemetry for correlation.

·        Third priority: restrict unattended access and persistence on systems where it is not required.

·        Fourth priority: mature service-provider access governance and downstream exposure validation.

·        Fifth priority: improve cloud-native remote management governance, logging, and setup-to-control detection.

·        Sixth priority: strengthen incident response playbooks for unauthorized RMM use, tenant mismatch, persistence, and high-risk follow-on activity.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Economic Impact Overview

RMM tool abuse changes intrusion economics by allowing adversaries to use legitimate remote administration pathways instead of relying exclusively on malware, custom command-and-control infrastructure, or noisy exploitation chains. This lowers attacker friction while increasing defender validation burden. The organization may see signed tooling, official relay infrastructure, support-session activity, service-provider activity, or cloud-native remote command events but still need to prove whether the activity was authorized, attributable, scoped, and consistent with approved workflow.

The organizational impact is driven by ambiguity and control. When RMM activity cannot be quickly tied to an approved tool, tenant, support user, endpoint, session, ticket, source, or administrative workflow, response expands beyond endpoint containment. The organization must validate access legitimacy, determine whether unattended access was created, assess credential exposure, review service-provider involvement, inspect post-compromise commands, and confirm whether cloud-native remote management pathways were misused.

Attacker Economic Advantages

·        RMM abuse reduces the need for custom malware by using legitimate remote support and administration tools.

·        Signed binaries and official vendor infrastructure can reduce prevention friction.

·        Existing enterprise allowlists and support workflows may make RMM activity appear operationally normal.

·        Temporary support sessions can provide rapid interactive control.

·        Unattended access can preserve control after the initial access method is removed.

·        Service-provider pathways can expand reach beyond one endpoint or one organization.

·        Cloud-native remote command features can provide RMM-equivalent control without a third-party RMM binary.

·        Tool stacking allows adversaries to maintain alternate access if one remote access pathway is removed.

Defender Economic Burden

·        Analysts must validate whether the tool, tenant, user, endpoint, source, and session are approved.

·        Incident responders must determine whether RMM access was temporary or persistent.

·        Security teams must inspect follow-on activity for discovery, credential access, lateral movement, defense evasion, data staging, backup interference, or ransomware preparation.

·        Identity teams may need to review privileged accounts, service-provider accounts, service accounts, managed identities, cloud roles, tokens, and active sessions.

·        Infrastructure teams may need to remove unauthorized agents, services, scheduled tasks, startup entries, cloud remote command access, or tenant associations.

·        Legal, compliance, and customer assurance teams may become involved if sensitive data, customer environments, regulated systems, or service-provider access are affected.

·        Recovery teams may need to validate endpoint trust, backup integrity, remote access configuration, and service-provider governance before returning systems to normal operation.

Economic Impact Model

Low Impact Scenario

Suspicious RMM activity is detected early, scoped to a limited endpoint population, and investigation confirms no unauthorized unattended access, no credential access, no lateral movement, no data staging, no cloud-control misuse, no backup interference, and no ransomware-preparation behavior. Organizational impact is primarily investigation, validation, limited containment, support workflow review, and detection tuning. Estimated impact is $150K to $500K.

Moderate Impact Scenario

Unauthorized RMM execution or persistence affects a limited but meaningful set of endpoints. Response requires endpoint containment, tenant validation, support workflow review, credential review, detection tuning, service-provider coordination, selective remediation, and executive incident coordination. Organizational impact includes operational disruption, analyst surge effort, validation of remote administration workflows, and temporary restrictions on support activity. Estimated impact is $750K to $5M.

High Impact Scenario

RMM abuse enables persistent remote control, credential access, lateral movement, security-tool tampering, backup interference, data staging, cloud-native remote command abuse, or ransomware preparation across high-value systems. Response requires enterprise incident response, broad credential rotation, remote access suspension, service-provider validation, endpoint rebuilds, legal or regulatory review, recovery assurance, and executive incident governance. Estimated impact is $7.5M to $50M or higher.

Organizational Impact Drivers

·        Number and criticality of affected endpoints, servers, cloud workloads, or restricted systems.

·        Whether RMM activity affected identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, cloud management systems, or production-critical workloads.

·        Whether unattended access, persistent agents, service creation, scheduled tasks, registry autoruns, startup entries, or reconnect behavior were created.

·        Whether RMM activity launched discovery, credential access, lateral movement, defense evasion, backup interference, data staging, or ransomware-preparation commands.

·        Whether service-provider access, delegated administration, downstream customer environments, or shared support infrastructure were involved.

·        Whether the organization can validate tenant ownership, session ownership, support ticket, endpoint authorization, source location, and administrative purpose.

·        Whether endpoint process telemetry, command-line visibility, RMM platform logs, identity telemetry, network logs, cloud audit logs, and support workflow data are available.

·        Whether cloud-native remote management was used through AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, or equivalent capabilities.

·        Whether credential rotation, token revocation, session invalidation, endpoint rebuilds, backup validation, or customer assurance are required.

·        Whether legal, regulatory, insurance, contractual, or board-level governance obligations are triggered.

Attack Economics Assessment

RMM tool abuse is economically favorable for adversaries because it exploits normal business operations and trusted administrative tooling. The attacker can gain interactive control, preserve access, and conduct post-compromise activity while reducing dependence on obvious malware indicators. The defender’s cost is amplified by the need to prove legitimacy, scope access, validate credentials, inspect persistence, review service-provider exposure, and restore confidence in remote administration controls.

S39 — Economic Impact & Organizational Exposure

Exposure Overview

Organizational exposure from RMM tool abuse is determined by how broadly remote administration is used, how tightly it is governed, and how quickly the organization can distinguish approved support from adversary-controlled access. The exposure is not limited to endpoints where RMM tools are installed. It extends to support workflows, tenants, management servers, service-provider access, identity systems, cloud workloads, network egress paths, and incident response processes.

The highest exposure occurs when remote administration is widely permitted but weakly inventoried, when service-provider access is broadly trusted, when unattended access is common, when restricted systems allow direct support connections, or when cloud-native remote command features are enabled without strong identity, source, workload, and change-control governance.

Primary Organizational Exposure Areas

Endpoint and Server Exposure

RMM activity on ordinary endpoints creates investigation burden, but RMM activity on high-value systems can materially increase business impact. Identity systems, backup servers, security tooling, privileged access workstations, executive endpoints, regulated-data systems, production-critical workloads, and cloud management systems should be treated as restricted remote administration zones.

Identity and Credential Exposure

RMM abuse can create identity exposure when adversaries use helpdesk accounts, technician accounts, service-provider identities, privileged accounts, service accounts, managed identities, or cloud roles to legitimize remote access. Credential review becomes broader when RMM activity is followed by discovery, credential access, lateral movement, or unclear support-session ownership.

Service-Provider Exposure

Service-provider access can expand organizational exposure because support pathways may connect multiple environments, customers, business units, or downstream systems. If service-provider access is involved, the organization may need to validate delegated permissions, named account ownership, tenant boundaries, support sessions, customer exposure, contractual obligations, and downstream impact.

Cloud Workload Exposure

Cloud-native remote command and workload management features can create RMM-equivalent exposure when used outside approved workflows. AWS Systems Manager, Azure Run Command, GCP VM Manager, OS Config, metadata execution, and similar capabilities can enable remote administration without a traditional third-party RMM binary. Exposure increases when cloud roles are overprivileged, workload tagging is incomplete, command visibility is limited, or setup-to-control activity cannot be strongly correlated.

Recovery and Continuity Exposure

RMM abuse can affect recovery confidence when adversaries interfere with backups, stop services, disable recovery options, weaken security tooling, or create alternate remote access paths. Even when ransomware is not executed, the organization may need to validate backup integrity, endpoint trust, credential security, and remote administration controls before returning to normal operations.

Governance and Compliance Exposure

Compliance exposure depends on whether RMM abuse results in unauthorized access to regulated data, privileged systems, customer environments, cloud workloads, endpoint management systems, or business-critical infrastructure. Governance exposure increases when the organization cannot show that remote administration is inventoried, monitored, attributable, restricted, and tied to approved support workflows.

Financial Exposure Bands

Limited Exposure

Limited exposure applies when suspicious RMM activity is quickly detected, remains confined to low-criticality endpoints, does not create unattended access, and does not produce credential access, lateral movement, data staging, cloud-control misuse, backup interference, or ransomware-preparation behavior. Financial impact is primarily investigation, validation, containment, and detection improvement.

Material Exposure

Material exposure applies when unauthorized RMM execution, persistence, tenant mismatch, service-provider ambiguity, or cloud-native remote command misuse affects a limited but meaningful system population. Financial impact includes containment, credential review, support workflow validation, endpoint remediation, service-provider coordination, and executive incident coordination.

Severe Exposure

Severe exposure applies when RMM abuse affects high-value systems, enables persistence, supports credential access, expands laterally, interferes with backups, weakens defenses, stages data, or prepares ransomware activity. Financial impact may include enterprise incident response, broad credential rotation, endpoint rebuilds, remote access suspension, service-provider validation, legal or regulatory review, customer assurance, and recovery assurance.

Business Exposure Indicators

·        RMM activity on restricted or high-value systems.

·        Unknown RMM tenant, management server, support user, or deployment source.

·        RMM activity without a valid support ticket, change record, session owner, or approved workflow.

·        New unattended-access configuration, service creation, scheduled task creation, startup entry, agent enrollment, or reconnect behavior.

·        RMM-launched discovery, credential access, lateral movement, security-tool tampering, backup interference, data staging, or ransomware-preparation commands.

·        Privileged account, service-provider account, service account, managed identity, or cloud role involvement.

·        RMM relay or remote-support infrastructure access from prohibited endpoint populations.

·        Cloud-native remote command activity against restricted workloads.

·        Incomplete endpoint telemetry, command-line visibility, RMM platform audit logs, identity context, cloud audit logs, or support workflow records.

·        Unresolved tenant ownership, session ownership, service-provider scope, or downstream customer exposure.

Organizational Exposure Assessment

RMM tool abuse should be treated as material organizational exposure when remote administration governance is incomplete or when RMM activity cannot be rapidly validated against approved workflow. The primary exposure is not only technical compromise. It is the loss of confidence in the organization’s ability to prove who controlled a system, why remote access occurred, whether persistence was created, whether credentials were exposed, and whether recovery can be trusted.

Organizations with mature RMM governance, restricted endpoint policy, telemetry correlation, service-provider oversight, cloud audit visibility, and response playbooks can reduce exposure significantly. Organizations without those controls may face elevated cost even from limited RMM activity because uncertainty itself expands investigation, containment, and assurance requirements.

S40 — References

Vendor / Platform Documentation

·        AWS Documentation — AWS Systems Manager Session Manager — hxxps://docs[.]aws[.]amazon[.]com/systems-manager/latest/userguide/session-manager.html

·        AWS Documentation — AWS Systems Manager Run Command — hxxps://docs[.]aws[.]amazon[.]com/systems-manager/latest/userguide/run-command.html

·        Microsoft Learn — Run scripts in a Windows or Linux VM in Azure with Run Command — hxxps://learn[.]microsoft[.]com/en-us/azure/virtual-machines/run-command-overview

·        Google Cloud Documentation — VM Manager documentation — hxxps://cloud[.]google[.]com/compute/vm-manager/docs

·        Google Cloud Documentation — OS Config / OS policies — hxxps://cloud[.]google[.]com/compute/vm-manager/docs/os-policies

Threat Technique Framework

·        MITRE ATT&CK — Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Security Vendor Analysis

·        Microsoft Security Blog — Threat actors misusing Quick Assist in social engineering attacks leading to ransomware — hxxps://www[.]microsoft[.]com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/

·        Sophos — DragonForce actors target SimpleHelp vulnerabilities to attack MSP customers — hxxps://www[.]sophos[.]com/en-us/blog/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers

·        Red Canary — Storm-1811 exploits RMM tools to drop Black Basta ransomware — hxxps://redcanary[.]com/blog/threat-intelligence/storm-1811-black-basta/

Threat Tradecraft and Intrusion Patterns

·        CISA, NSA, and MS-ISAC — Protecting Against Malicious Use of Remote Monitoring and Management Software — hxxps://www[.]cisa[.]gov/news-events/cybersecurity-advisories/aa23-025a

·        CISA — JCDC Remote Monitoring and Management Cyber Defense Plan — hxxps://www[.]cisa[.]gov/topics/partnerships-and-collaboration/joint-cyber-defense-collaborative/jcdc-remote-monitoring-and-management-cyber-defense-plan

·        CISA — Ransomware Actors Exploit Unpatched SimpleHelp Remote Monitoring and Management to Compromise Utility Billing Software Provider — hxxps://www[.]cisa[.]gov/news-events/cybersecurity-advisories/aa25-163a

·        CISA — StopRansomware Guide — hxxps://www[.]cisa[.]gov/resources-tools/resources/stopransomware-guide