[EXP] Hosting Control-Plane Compromise Risk from cPanel KEV Exploitation

Report Type: EXP

Threat Category: Hosting Control-Plane Exploitation

Assessment Date: May 4, 2026

Assessment Date: June 16, 2026

Primary Impact Domain: Hosting Control-Plane Compromise

Secondary Impact Domains: Unauthorized Administrative Access; Multi-Tenant Hosting Impact; Hosted-Content Manipulation; Account and Credential Abuse; Suspicious Outbound Infrastructure Use; Customer-Facing Service Abuse

Affected Asset Class: Internet-Facing cPanel, WHM, DNSOnly, WP Squared, and Related Hosting-Control Systems

Threat Objective Classification: Unauthorized Control-Plane Access, Privilege Abuse, Tenant Impact Expansion, Persistence Enablement, Hosted-Content Manipulation, and Abuse Infrastructure Enablement

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

BLUF

‍ Hosting-control-plane exploitation and shared-hosting privilege escalation create material enterprise, hosting-provider, and customer-impact risk when attackers can convert exposed administrative services or lower-privileged hosting footholds into privileged server-side activity, hosted-content tampering, credential exposure, abuse infrastructure, or tenant-impacting compromise. The report is primarily driven by CVE-2026-41940, an authentication-bypass vulnerability affecting cPanel & WHM, including DNSOnly, and WP Squared, where exposed administrative services can become a path into hosted infrastructure. This amendment adds CVE-2026-54420 as a related coverage-with-adaptation lane affecting LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin environments, where symlink mishandling in shared-hosting deployments using CloudLinux/CageFS can allow a user with FTP or webshell access to escalate an existing foothold toward root-level or server-level exposure. The threat posture is elevated because both access models can undermine hosting administration, shared-hosting tenant boundaries, hosted-content integrity, credential trust, customer assurance, and downstream abuse prevention. Executive action is required to validate patch status, identify affected cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, and LiteSpeed WHM Plugin assets, preserve access and session telemetry, review FTP and webshell foothold evidence, validate CloudLinux/CageFS tenant-boundary assumptions, perform historical compromise review, and confirm detection coverage for unauthorized administrative access, symlink or tenant-boundary abuse, privileged server-side activity, hosted-content tampering, suspicious outbound communication, credential access, and tenant-impacting behavior.

Executive Risk Translation

This threat shifts business risk from isolated vulnerability exposure to loss of trust in the hosting administration and shared-hosting isolation layers. The primary concern is not only whether cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, or LiteSpeed WHM Plugin systems were vulnerable, but whether exposed hosting-control assets, shared-hosting plugin behavior, FTP-enabled tenant accounts, webshell-accessible paths, or CloudLinux/CageFS boundary conditions allowed attackers to gain unauthorized administrative access, escalate from a lower-privileged foothold, or affect hosted infrastructure before remediation. If compromise occurred, response may expand into server isolation, root-level integrity review, customer-site integrity review, symlink and permission review, credential rotation, webroot and database inspection, DNS and mail review, reseller-account validation, tenant-boundary scoping, abuse-infrastructure takedown, customer assurance, legal review, and executive incident governance. This creates financial, operational, customer-trust, regulatory, and reputational exposure beyond the initially affected control-plane service or plugin component.

S3 — Why This Matters Now

·        CVE-2026-41940 should be treated as an active hosting control-plane exploitation risk, not as a routine patch-management issue.

·        CVE-2026-54420 extends the same hosting-risk family into LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin environments, where symlink mishandling in shared-hosting deployments using CloudLinux/CageFS can allow a user with FTP or webshell access to escalate an existing foothold toward root-level or server-level exposure.

·        The affected technologies sit directly in the administrative and shared-hosting layers used to manage websites, reseller accounts, hosted content, databases, DNS records, mail services, tenant directories, and customer-facing web infrastructure.

·        Successful exploitation can create unauthorized administrative access, privileged server-side execution, or shared-hosting boundary failure that may affect more than one website, tenant, reseller, or customer environment.

·        Shared-hosting, reseller-hosting, MSP-operated hosting, and customer-facing web infrastructure require elevated prioritization because one compromised administrative surface, plugin component, tenant foothold, or root-level escalation path can produce multi-tenant impact.

·        Patch status alone does not prove that exposed systems, vulnerable plugins, shared-hosting tenants, or CloudLinux/CageFS boundary assumptions were uncompromised before remediation.

·        Historical compromise review is required for systems that were internet-facing, running affected hosting-control software, running affected LiteSpeed cPanel or WHM plugin versions, or exposed to FTP or webshell foothold conditions before patch validation.

·        Detection must focus on unauthorized administrative access, authentication or session mismatch, FTP or webshell foothold evidence, symlink or tenant-boundary abuse, privileged execution, hosted-content modification, suspicious outbound communication, and tenant blast-radius evidence.

·        Scan-only telemetry, exposure-only findings, or plugin-version inventory should support prioritization and hunting, but they must not be treated as confirmed compromise without stronger post-access, privilege-escalation, file-system, outbound, or tenant-impact evidence.

Organizations without reliable control-panel access logs, authentication or session telemetry, FTP logs, web access logs, process lineage, file and symlink telemetry, outbound DNS and network visibility, CloudLinux/CageFS tenant mapping, administrative-action logs, and tenant ownership context face elevated risk of delayed detection and incomplete scoping.

S4 — Key Judgments

·        CVE-2026-41940 creates a high-priority exposed hosting-control-plane compromise risk because successful exploitation can provide unauthorized administrative access to cPanel, WHM, DNSOnly, WP Squared, or related hosting administration surfaces.

·        CVE-2026-54420 extends the same hosting-risk family into LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin environments, where symlink mishandling in shared-hosting deployments using CloudLinux/CageFS can allow a user with FTP or webshell access to escalate an existing foothold toward root-level or server-level exposure.

·        The primary business risk is attacker control over, or privileged escalation within, hosting administration and shared-hosting environments that can affect customer sites, reseller accounts, mail, databases, DNS records, hosted content, credentials, tenant boundaries, and downstream customer trust.

·        The strongest enterprise risk signal is suspicious control-panel access, FTP activity, webshell activity, or tenant-context file activity followed by privileged execution, account modification, hosted-content tampering, symlink or permission abuse, DNS or mail changes, credential access, suspicious outbound communication, or multi-tenant activity.

·        Vulnerable or exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, or related hosting-control assets should drive patch prioritization and retrospective hunt scoping, but exposure, version status, or scan activity alone should not be treated as confirmed compromise.

·        Authentication and session telemetry remain central for CVE-2026-41940 because the exploitation model involves unauthorized access to hosting-control functionality.

·        FTP logs, web access logs, process lineage, file telemetry, symlink visibility, CloudLinux/CageFS tenant mapping, and root-context attribution become central for CVE-2026-54420 because the exploitation model depends on an existing lower-privileged foothold, shared-hosting boundary conditions, and privilege-escalation evidence.

·        Endpoint process telemetry is required to identify post-access execution, administrative tooling, staging, persistence, service changes, account-management activity, root-context behavior, and privilege-escalation outcomes.

·        Hosted-content, file-system, and tenant mapping are required to determine whether activity remained isolated to one site or expanded across customers, resellers, tenant directories, mailboxes, databases, DNS zones, webroots, or shared-hosting boundaries.

·        Outbound DNS, proxy, firewall, and network telemetry materially improve visibility into payload staging, command-and-control behavior, redirector use, phishing hosting, spam activity, malware distribution, abuse infrastructure, and post-escalation outbound activity.

·        Detection must remain behavior-led because public exploit artifacts, request formatting, scanning infrastructure, user agents, filenames, symlink paths, payloads, and attacker tooling can change quickly.

Executive risk reduction depends on emergency patch validation, exposed asset identification, LiteSpeed plugin version review, access-log preservation, FTP and webshell foothold review, CloudLinux/CageFS boundary validation, historical compromise review, tenant-impact scoping, credential containment, and validated detection coverage across control-plane, endpoint, file, account, network, and tenant telemetry.

S5 — Executive Risk Summary

Business Risk

Hosting-control-plane compromise and shared-hosting privilege escalation can create severe operational, customer-trust, and reputational risk when attackers gain unauthorized access to, or escalate within, cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, or related hosting administration environments. Risk increases when affected systems support shared hosting, reseller hosting, MSP-operated customer environments, customer-facing websites, managed DNS, mail hosting, databases, backups, webroots, FTP-enabled tenant access, webshell-accessible hosted paths, or high-value hosted applications.

Technical Cause

The risk is driven by two related hosting-infrastructure access models. CVE-2026-41940 represents an authentication-bypass condition affecting exposed hosting-control-plane software, enabling unauthorized access to administrative functions under active exploitation conditions. CVE-2026-54420 represents a LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin symlink-mishandling path in shared-hosting deployments using CloudLinux/CageFS, where a user with FTP or webshell access may escalate an existing foothold toward root-level or server-level exposure. The enterprise detection model should therefore focus on control-panel access anomalies, authentication or session-flow mismatch, FTP and webshell foothold evidence, symlink or tenant-boundary abuse, privileged execution from hosting-control or plugin-adjacent contexts, administrative account changes, hosted-content modification, DNS or mail manipulation, suspicious outbound communication, credential access, webshell placement, and tenant-spanning impact.

Threat Posture

The threat posture is elevated because successful exploitation can convert exposed hosting administration or lower-privileged shared-hosting access into privileged server-side activity, customer-site tampering, credential access, abuse infrastructure, malware hosting, phishing delivery, spam activity, redirector deployment, root-context modification, and broader downstream impact. Risk is amplified in multi-tenant hosting environments because one compromised control-plane path, plugin component, tenant foothold, or shared-hosting boundary failure can affect multiple customers, reseller-managed sites, hosted directories, mailboxes, databases, DNS zones, or webroots.

Executive Decision Requirement

Executives must require immediate validation of patch status, exposure state, LiteSpeed plugin version status, access-log retention, authentication/session telemetry, FTP and web access telemetry, endpoint process visibility, file and symlink telemetry, hosted-content integrity, CloudLinux/CageFS tenant mapping, account-change review, outbound communication monitoring, and tenant-impact scoping. Response leadership should also confirm that patched systems, updated plugins, and systems exposed before remediation receive historical compromise review rather than being closed solely on patch completion or vulnerable-version removal.

S6 — Executive Cost Summary

Hosting-control-plane exploitation and shared-hosting privilege escalation create financial exposure based on the number of exposed hosting-control assets, affected LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin deployments, shared-hosting density, CloudLinux/CageFS boundary conditions, whether unauthorized administrative access or privilege escalation occurred before patch validation, customer or tenant blast radius, hosted-content integrity, credential exposure, mail and DNS abuse, detection latency, telemetry completeness, containment burden, customer assurance requirements, regulatory review, and the degree to which compromised infrastructure was used for phishing, malware distribution, spam, redirectors, payload staging, or broader abuse.

Low Impact Scenario

Rapid assessment confirms that exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, or related hosting-control systems were patched or updated quickly, access logs are preserved, no suspicious administrative session behavior is observed, no FTP or webshell foothold evidence is identified, no symlink or CloudLinux/CageFS tenant-boundary abuse is observed, no privileged execution follows control-panel or tenant-context activity, no hosted-content tampering is identified, no customer sites show webshells or unauthorized redirects, and no abnormal outbound communication or abuse reports are linked to the affected systems. Response still requires emergency patch validation, exposed asset scoping, plugin version validation, access-log and session review, FTP and web access review, endpoint and file-system hunting, tenant-boundary validation, customer-impact review, and executive tracking because active exploitation conditions existed before remediation; estimated impact $2M to $8M.

Moderate Impact Scenario

Suspicious administrative access, authentication-flow mismatch, FTP or webshell foothold evidence, hosted-content changes, suspicious outbound communication, limited account modification, symlink or permission anomalies, or abuse-report correlation is identified on one or more exposed hosting-control or shared-hosting systems, but investigation indicates constrained blast radius and no broad customer data exposure, sustained abuse infrastructure, confirmed root-level compromise across shared-hosting boundaries, or confirmed multi-tenant compromise. Response requires server containment or controlled isolation, retrospective access review, endpoint and file-system forensics, symlink and permission review, CloudLinux/CageFS boundary validation, tenant mapping, credential rotation, DNS and mail review, customer-site integrity validation, abuse-report handling, detection tuning, SOC surge support, legal assessment, customer communications planning, and executive incident coordination; estimated impact $15M to $60M.

High Impact Scenario

Confirmed or strongly suspected control-plane compromise, plugin-mediated privilege escalation, or root-level shared-hosting boundary failure affects shared-hosting, reseller-hosting, MSP-operated, customer-facing, or high-volume web infrastructure, with evidence of multi-tenant hosted-content tampering, webshell placement, customer credential exposure, DNS or mail manipulation, phishing or malware hosting, spam activity, database access, backup exposure, outbound staging, CloudLinux/CageFS boundary failure, or incomplete historical telemetry. Response may require broad server isolation, root-level integrity review, tenant-by-tenant scoping, webroot and database integrity review, symlink and permission review, credential rotation at scale, customer notification and assurance, abuse-infrastructure takedown, DNS and mail remediation, forensic preservation, rebuilds or migrations, legal and regulatory review, cyber insurance engagement, revenue-impact management, and board-level incident governance; estimated impact $75M to $300M or higher.

S6A — Key Cost Drivers

·        Number of exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, and related hosting-control or shared-hosting assets.

·        Whether affected systems were internet-facing, running vulnerable hosting-control software, running vulnerable LiteSpeed plugin versions, or exposed to FTP or webshell foothold conditions before patch validation.

·        Whether unauthorized administrative access, abnormal session behavior, authentication-flow mismatch, FTP activity, webshell activity, symlink abuse, CloudLinux/CageFS boundary failure, or root-context privilege escalation was observed.

·        Whether suspicious access or tenant-context activity was followed by privileged execution, account changes, password resets, reseller changes, DNS changes, mail changes, database access, backup access, service modification, root-owned file changes, symlink or permission changes, or hosted-content modification.

·        Scope of hosted-content modification across customer webroots, reseller-managed sites, tenant directories, mailboxes, databases, DNS zones, web-accessible paths, plugin directories, and shared-hosting boundary paths.

·        Presence of webshells, suspicious scripts, hidden files, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, unexpected symlinks, abnormal writable paths, or permission changes that could support persistence or tenant-boundary abuse.

·        Evidence of outbound payload retrieval, command-and-control behavior, redirector infrastructure, exfiltration-like traffic, spam activity, botnet activity, suspicious VPS communication, or post-escalation outbound communication from affected hosting servers.

·        Ability to map file paths, symlinks, hosted accounts, reseller accounts, domains, mailboxes, databases, DNS zones, FTP accounts, webshell-accessible paths, plugin activity, and root-context changes to tenant identity.

·        Availability and retention of control-panel access logs, authentication logs, session telemetry, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, DNS logs, proxy logs, firewall logs, administrative action logs, abuse reports, and CloudLinux/CageFS tenant-mapping evidence.

·        Time from vulnerability disclosure or exposure identification to patch validation, plugin update validation, containment, historical compromise review, and tenant-boundary assurance.

·        Need for credential rotation across administrator accounts, reseller accounts, customer accounts, FTP accounts, SSH keys, API tokens, database users, mail accounts, backup credentials, automation accounts, and any secrets exposed through cross-tenant or root-context access.

·        Need for customer assurance, customer notification analysis, legal review, regulatory assessment, insurance reporting, abuse-report handling, and board-level governance.

·        Business dependency on affected hosting infrastructure, including revenue-generating websites, customer-managed environments, managed hosting services, MSP operations, reseller platforms, ecommerce sites, mail services, DNS infrastructure, shared-hosting platforms, or CloudLinux/CageFS-isolated tenant environments.

·        Degree to which incomplete telemetry, weak tenant mapping, missing symlink visibility, limited FTP or web access history, or uncertain CloudLinux/CageFS boundary integrity forces broader containment, rebuild, migration, or customer-by-customer validation.

Most Likely Scenario Justification

Moderate scenario is most likely when exposed hosting-control-plane assets, affected LiteSpeed plugin deployments, or shared-hosting environments were reachable or vulnerable during the active exploitation window and require historical compromise review, but available telemetry does not confirm broad multi-tenant compromise, confirmed customer data exposure, root-level shared-hosting boundary failure, or persistent abuse infrastructure. The estimate moves toward the lower end when access logs, authentication/session telemetry, FTP and web access logs, endpoint telemetry, file and symlink telemetry, tenant mapping, CloudLinux/CageFS boundary validation, and outbound network telemetry confirm rapid patching, plugin updating, no unauthorized administrative access, no foothold-to-root escalation, no post-access execution, no hosted-content tampering, and no customer-impact evidence. The estimate moves toward the upper end when systems are shared-hosting or reseller-hosting platforms, vulnerable LiteSpeed plugins were present, FTP or webshell foothold evidence exists, symlink or permission anomalies are observed, telemetry is incomplete, patch validation was delayed, suspicious administrative access occurred, hosted-content changes are present, outbound activity is abnormal, abuse reports exist, or tenant-by-tenant integrity review is required.

S6B — Compliance and Risk Context

Hosting-control-plane compromise and shared-hosting privilege escalation executive risk model showing the progression from exposed hosting administration or lower-privileged shared-hosting foothold activity to unauthorized control-plane access, tenant-boundary abuse, root-context server activity, hosted-content tampering, customer-site exposure, incomplete containment, and business exposure.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Hosting Control-Plane Compromise, Shared-Hosting Privilege Escalation, and Customer Infrastructure Exposure

Risk Description

Adversaries may exploit exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, or related hosting-control and shared-hosting environments to move from unauthorized administrative access or an existing FTP or webshell foothold into privileged server-side activity, shared-hosting tenant-boundary abuse, root-context file or process activity, hosted-content tampering, credential exposure, DNS or mail manipulation, customer-site modification, phishing or malware hosting, spam activity, redirector deployment, database access, backup exposure, or broader abuse infrastructure. This may increase business interruption, customer-site integrity exposure, reseller-platform exposure, managed-hosting exposure, credential-reset burden, mail and DNS trust impact, customer notification analysis, abuse-report handling, legal and compliance review, cyber-insurance scrutiny, public trust loss, and board-level concern around hosting-control resilience and tenant isolation. Compliance exposure should be driven by local evidence of unauthorized administrative access, suspicious session behavior, FTP or webshell foothold activity, symlink or permission abuse, CloudLinux/CageFS boundary failure, root-context execution, hosted-content modification, credential exposure, DNS or mail changes, database or backup access, suspicious outbound activity, abuse reporting, or tenant-impacting activity, not by vulnerable version status, internet exposure, plugin presence, or scan activity alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $15M - $60M for materially exposed hosting environments with internet-facing cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller-hosting dependency, shared-hosting density, FTP-enabled tenant workflows, webshell-accessible hosted paths, incomplete control-panel access logs, incomplete authentication or session telemetry, limited FTP or web access history, weak endpoint process visibility, limited file or symlink telemetry, incomplete CloudLinux/CageFS tenant mapping, unclear reseller ownership, delayed patch or plugin update validation, or inconsistent historical compromise review. Exposure may exceed $75M - $300M+ where hosting-control-plane compromise, plugin-mediated privilege escalation, root-level shared-hosting boundary failure, or multi-tenant compromise results in confirmed or suspected customer-site tampering, credential exposure, DNS or mail manipulation, phishing or malware hosting, spam activity, database access, backup exposure, persistent webshell placement, abuse-infrastructure use, customer notification analysis, legal escalation, cyber-insurance review, public communications response, customer churn, revenue-impact management, rebuild or migration activity, or board-level incident governance.

S7 — Risk Drivers

·        Active exploitation of a critical hosting control-plane authentication-bypass vulnerability increases near-term compromise likelihood for exposed cPanel, WHM, DNSOnly, WP Squared, and related hosting-control services.

·        LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin symlink mishandling extends the risk into shared-hosting environments where an existing FTP or webshell foothold may enable privilege escalation toward root-level or server-level exposure.

·        Exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, and related hosting-control or shared-hosting components create administrative, plugin-adjacent, and tenant-boundary attack surface.

·        Hosting-control access or shared-hosting privilege escalation can affect customer websites, reseller-managed sites, mailboxes, databases, DNS zones, backups, webroots, FTP accounts, tenant directories, and CloudLinux/CageFS-isolated hosting paths.

·        Shared-hosting and reseller-hosting environments create multi-tenant blast-radius risk when a single control-plane compromise path, vulnerable plugin component, FTP foothold, webshell foothold, or tenant-boundary failure can affect multiple customers or hosted sites.

·        Unauthorized administrative access may enable webshell placement, script modification, permission changes, archive staging, credential access, account modification, DNS or mail manipulation, hosted-content tampering, and abuse-infrastructure deployment.

·        Shared-hosting escalation may involve symlink abuse, permission anomalies, tenant-boundary bypass, root-context process activity, root-owned file changes, plugin-adjacent execution, or unexpected access to files outside the expected tenant scope.

·        Control-plane compromise or shared-hosting privilege escalation can support phishing hosting, malware delivery, redirector infrastructure, spam activity, SEO spam, credential harvesting, botnet activity, payload staging, and external abuse reports.

·        Patch validation and plugin update validation do not prove that systems were uncompromised before remediation.

·        Vulnerable version status, plugin presence, internet exposure, scan activity, or exploit-attempt telemetry should support prioritization and retrospective hunting, but should not be treated as confirmed compromise without stronger post-access, privilege-escalation, file-system, outbound, or tenant-impact evidence.

·        Missing control-panel access logs weakens exploit-attempt and unauthorized-access assessment.

·        Missing authentication or session telemetry weakens analysis of whether control-plane access followed a legitimate login path.

·        Missing FTP logs or web access logs weakens assessment of whether a lower-privileged shared-hosting foothold existed before suspected symlink or privilege-escalation activity.

·        Missing endpoint process telemetry weakens detection of privileged execution, staging, account management, persistence, service modification, plugin-adjacent execution, and root-context activity.

·        Missing file and symlink telemetry weakens detection of hosted-content tampering, webshell placement, permission changes, unexpected symlinks, hidden files, tenant-boundary abuse, root-owned file changes, and archive staging.

·        Missing CloudLinux/CageFS tenant mapping weakens analysis of whether file access, symlink behavior, process activity, or root-context changes crossed expected shared-hosting boundaries.

·        Missing DNS, proxy, firewall, or outbound network telemetry weakens detection of payload retrieval, command-and-control behavior, redirector use, exfiltration-like traffic, phishing or malware hosting, spam infrastructure, and other abuse operations.

·        Missing tenant mapping weakens blast-radius assessment, customer-impact scoping, reseller-impact validation, and customer assurance.

·        Legitimate hosting-provider support, reseller administration, patching, plugin updates, backups, migrations, certificate renewal, CMS updates, FTP workflows, customer maintenance, and CloudLinux/CageFS operations can resemble post-compromise behavior without strong operational context.

Over-reliance on CVE strings, public proof-of-concept artifacts, scanner names, known malicious IPs, user-agent strings, filenames, symlink paths, or payload indicators can miss evolved exploitation, foothold-to-root escalation, and post-access abuse.

S8 — Bottom Line for Executives

Hosting-control-plane compromise and shared-hosting privilege escalation should be treated as a high-priority hosting infrastructure, tenant-boundary, and customer-trust risk. The executive concern is not only whether cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, or LiteSpeed WHM Plugin systems were vulnerable, but whether exposed administrative services, FTP-enabled tenant access, webshell-accessible hosted paths, or CloudLinux/CageFS boundary conditions allowed attackers to gain unauthorized control, escalate privileges, tamper with hosted content, access credentials, modify DNS or mail services, create persistence, abuse outbound infrastructure, or affect multiple customers before remediation. Risk reduction depends on patch and plugin update validation, exposed asset scoping, historical compromise review, preserved access and session telemetry, FTP and web access review, endpoint and file-system hunting, symlink and tenant-boundary validation, outbound communication review, tenant-impact mapping, credential containment, and customer-assurance readiness.

S9 — Board-Level Takeaway

CVE-2026-41940 turns exposed hosting administration into a potential enterprise and customer-impact control-plane risk, while CVE-2026-54420 extends the same governance concern into LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin shared-hosting environments where an existing FTP or webshell foothold may escalate toward root-level or server-level exposure. The board-level concern is whether attackers gained unauthorized administrative access or escalated within shared-hosting boundaries on systems that manage customer websites, reseller accounts, DNS, mail, databases, hosted files, backups, FTP accounts, webroots, plugin paths, tenant directories, and public-facing content. Leadership should require evidence that exposed assets and affected plugin deployments were identified, emergency patches and plugin updates were validated, historical compromise review was performed, tenant-boundary and CloudLinux/CageFS scoping is possible, and response teams can detect suspicious administrative access, FTP or webshell foothold activity, symlink or permission abuse, root-context activity, hosted-content tampering, outbound abuse, and tenant-impacting behavior. This report supports governance decisions around hosting-platform risk, shared-hosting isolation, customer trust, exposure management, telemetry readiness, credential containment, abuse-infrastructure response, customer assurance, and executive oversight of multi-tenant compromise risk.

Figure 2

S10 — Threat Overview

Hosting control-plane compromise and shared-hosting privilege escalation describe adversary behavior in which exposed hosting administration, vulnerable hosting-control software, vulnerable plugin components, tenant-level footholds, FTP access, webshell access, symlink behavior, or shared-hosting boundary weaknesses are abused to obtain unauthorized administrative access, escalate privileges, tamper with hosted content, access credentials, manipulate customer infrastructure, or create multi-tenant impact. The behavior is most relevant when suspicious control-panel access, abnormal authentication or session context, FTP or web access anomalies, webshell activity, symlink or permission abuse, plugin-adjacent execution, root-context process activity, hosted-content changes, DNS or mail modification, outbound abuse, or tenant-impact evidence appears on systems supporting cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, or related shared-hosting services.

·        This is not only a single-CVE, patch-status, scanner, exposed-service, plugin-version, user-agent, request-path, filename, webshell-name, symlink-path, actor-name, or IOC-driven model.

·        The core threat behavior is movement from exposed hosting administration or lower-privileged shared-hosting foothold activity into unauthorized control-plane access, tenant-boundary abuse, privileged server-side execution, root-context activity, hosted-content tampering, credential exposure, DNS or mail manipulation, abuse-infrastructure deployment, or incomplete containment.

·        CVE-2026-41940 represents the exposed hosting-control-plane lane, where unauthenticated access to affected cPanel, WHM, DNSOnly, WP Squared, or related hosting-control services can create unauthorized administrative access risk.

·        CVE-2026-54420 represents the shared-hosting escalation lane, where LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin symlink mishandling in CloudLinux/CageFS environments may allow a user with FTP or webshell access to escalate an existing foothold toward root-level or server-level exposure.

·        The primary risk is reduced ability to determine whether activity remained limited to routine hosting administration, customer maintenance, plugin operation, FTP workflow, or tenant activity, or crossed into unauthorized access, privilege escalation, tenant-boundary failure, hosted-content compromise, credential exposure, outbound abuse, or multi-tenant impact.

·        Control-panel access logs, authentication logs, session telemetry, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, administrative action logs, DNS logs, mail logs, proxy logs, firewall logs, CloudLinux/CageFS tenant mapping, abuse reports, backup records, and customer-impact records may be incomplete or difficult to reconcile during active investigation.

·        The behavior can create uncertainty around hosting administration trust, shared-hosting isolation, customer-site integrity, reseller-account integrity, credential trust, DNS and mail integrity, database exposure, backup exposure, tenant blast radius, abuse-infrastructure use, customer assurance, legal review, and executive incident governance.

·        Public reporting on CVE exploitation, cPanel and WHM exposure, LiteSpeed plugin vulnerabilities, shared-hosting symlink abuse, CloudLinux/CageFS boundary concerns, webshell activity, and hosting abuse should support the relevance and urgency of the behavior class, but should not narrow the report into a CVE-only, plugin-only, exploit-string-only, actor-only, or IOC-only report.

S11 — Threat Classification and Type

Threat Type

Hosting control-plane compromise and shared-hosting privilege escalation exposure.

Threat Sub-Type

Unauthenticated hosting-control-plane access, cPanel and WHM administrative exposure, DNSOnly and WP Squared control-plane exposure, LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin symlink mishandling, FTP foothold escalation, webshell foothold escalation, shared-hosting tenant-boundary abuse, CloudLinux/CageFS boundary failure, root-context file or process activity, hosted-content tampering, credential exposure, DNS or mail manipulation, webshell placement, outbound abuse, and multi-tenant hosting impact.

Operational Classification

Hosting infrastructure compromise, shared-hosting isolation failure, and customer-impacting web infrastructure exposure.

Primary Function

Abuse exposed hosting-control services, vulnerable plugin behavior, existing FTP or webshell footholds, symlink behavior, or shared-hosting boundary conditions to move from external exposure or tenant-level access into unauthorized administration, privilege escalation, root-context server activity, hosted-content modification, credential exposure, DNS or mail manipulation, abuse-infrastructure deployment, customer-site compromise, or broader tenant-impacting activity, creating uncertainty around hosting-platform integrity, customer trust, containment completeness, and shared-hosting isolation.

S12 — Campaign or Activity Overview

Hosting control-plane compromise and shared-hosting privilege escalation activity model showing exposed cPanel, WHM, DNSOnly, or WP Squared administration, LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin shared-hosting exposure, FTP or webshell foothold activity, symlink or tenant-boundary abuse, root-context activity, hosted-content tampering, outbound abuse, and post-remediation containment validation.

This report assesses hosting control-plane compromise and shared-hosting privilege escalation as a durable behavior class rather than a single exploit string, scanner pattern, actor campaign, plugin artifact, or IOC set. The activity pattern involves adversaries attempting to use exposed hosting-control services, vulnerable hosting administration components, vulnerable LiteSpeed plugin behavior, existing FTP or webshell access, symlink mishandling, or shared-hosting boundary weaknesses as a starting point for unauthorized administrative access, privilege escalation, customer-site compromise, abuse-infrastructure use, and incomplete containment.

·        The activity is best understood as a hosting infrastructure and shared-hosting isolation threat rather than a routine vulnerability-management item, isolated web request, single authentication event, single FTP session, plugin inventory issue, or scan-only exposure finding.

·        Adversaries may target internet-facing cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller-hosting systems, shared-hosting platforms, MSP-operated hosting environments, customer-facing websites, FTP-enabled tenant accounts, webshell-accessible hosted paths, and CloudLinux/CageFS-isolated tenant environments.

·        The behavior may involve suspicious control-panel access, abnormal authentication or session context, unexpected administrative actions, FTP activity outside normal workflows, webshell access, unusual file writes, symlink creation or traversal, permission changes, plugin-adjacent execution, root-context process activity, hosted-content tampering, DNS or mail changes, credential access, archive staging, or suspicious outbound communication.

·        The activity may remain limited to scanning, blocked exploitation, failed authentication, benign plugin exposure, routine customer FTP workflow, or isolated tenant maintenance, or it may progress into unauthorized administrative access, webshell placement, customer-site modification, tenant-boundary abuse, privilege escalation, root-owned file changes, credential exposure, DNS or mail manipulation, phishing or malware hosting, spam activity, or multi-tenant compromise.

·        The activity becomes highest risk when affected systems support shared hosting, reseller hosting, MSP-operated customer environments, ecommerce sites, customer portals, managed DNS, mail hosting, databases, backups, high-value hosted applications, regulated customer content, or large numbers of tenant webroots.

Actor names, exploit references, scanner infrastructure, public proof-of-concept details, plugin version findings, webshell names, symlink paths, or campaign reporting may increase urgency, but they should enrich the report rather than replace local behavior-led evidence of unauthorized access, foothold activity, privilege escalation, file-system impact, outbound abuse, or tenant impact.

S13 — Targets and Exposure Surface

The exposure surface includes cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, hosting-control portals, reseller administration, shared-hosting platforms, CloudLinux/CageFS tenant isolation, FTP services, webroots, tenant directories, plugin paths, databases, mail services, DNS zones, backup locations, customer sites, and the endpoint, network, identity, and administrative telemetry needed to determine whether activity remained routine or became compromise.

·        Internet-facing cPanel, WHM, DNSOnly, WP Squared, reseller portals, hosting-control interfaces, administrative endpoints, authentication flows, session handling, account-management functions, package-management workflows, and administrative action paths.

·        LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, plugin-adjacent file paths, shared-hosting integration points, CloudLinux/CageFS-isolated environments, tenant directory structures, symlink behavior, file permission models, and root-context execution boundaries.

·        FTP services, FTP accounts, web-accessible upload paths, webshell-accessible hosted paths, customer maintenance workflows, CMS administration paths, customer webroots, reseller-managed sites, tenant directories, and hosted-content management paths.

·        Customer websites, ecommerce stores, customer portals, content-management systems, web applications, static content, scripts, media directories, hidden files, redirect logic, phishing pages, malware delivery content, SEO spam, and credential-harvesting pages.

·        DNS zones, mail services, mailboxes, MX records, SPF, DKIM, DMARC-related administration, mail routing, webmail access, spam activity, phishing delivery paths, and domain-trust dependencies.

·        Databases, database users, configuration files, API keys, application secrets, backup archives, staging archives, customer records, hosted application data, and secrets exposed through control-plane access, root-context access, or tenant-boundary failure.

·        Endpoint process activity, shell execution, service modification, account changes, root-owned file changes, persistence paths, administrative tooling, plugin-adjacent processes, and post-access execution on affected hosting servers.

·        Network and outbound telemetry involving payload retrieval, command-and-control behavior, redirector infrastructure, suspicious VPS communication, exfiltration-like traffic, spam operations, malware hosting, phishing delivery, botnet activity, and abuse-report correlation.

·        Control-panel logs, authentication logs, session telemetry, FTP logs, web access logs, endpoint telemetry, file and symlink telemetry, DNS logs, mail logs, proxy logs, firewall logs, administrative audit logs, backup records, abuse reports, help desk records, customer support records, and incident-response records.

Environments with incomplete access-log retention, weak authentication/session visibility, limited FTP or web access history, missing file and symlink telemetry, limited endpoint visibility, unclear tenant ownership, incomplete CloudLinux/CageFS mapping, weak reseller-account mapping, undocumented support workflows, or inconsistent historical compromise review.

S14 — Sectors / Countries Affected

Sectors Affected

·        Hosting providers, managed hosting providers, reseller-hosting operators, web-hosting platforms, and domain or web-service providers.

·        MSPs, MSSPs, digital agencies, web-development firms, ecommerce service providers, and organizations operating customer-facing hosting infrastructure.

·        Technology, software, SaaS, cloud-dependent, and platform-dependent enterprises with externally hosted web applications, customer portals, documentation sites, or managed web properties.

·        Retail, ecommerce, hospitality, logistics, media, professional services, education, nonprofit, healthcare, legal, financial services, public-sector, and small-business environments dependent on hosted websites, mail services, DNS administration, or managed web infrastructure.

·        Organizations using cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, FTP-enabled customer workflows, shared-hosting services, reseller hosting, hosted databases, managed DNS, mail hosting, or customer-facing web platforms.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because cPanel, WHM, LiteSpeed plugin deployments, shared hosting, reseller hosting, managed hosting, FTP workflows, customer-facing web infrastructure, and hosted web services are globally deployed.

·        Countries with large hosting-provider ecosystems, reseller-hosting markets, ecommerce dependency, small-business web-hosting dependency, digital-agency operations, MSP-managed hosting, or high use of shared-hosting platforms may face elevated operational exposure.

·        Country-specific impact should be assessed by affected hosting footprint, exposed control-plane services, LiteSpeed plugin deployment, shared-hosting density, CloudLinux/CageFS usage, tenant ownership, customer base, hosted-content sensitivity, regulatory obligations, abuse-report exposure, and incident-response maturity rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require enough technical capability to identify exposed hosting-control services, exploit authentication-bypass conditions, operate within hosting administration contexts, use FTP or webshell footholds, understand shared-hosting directory structures, manipulate files or symlinks, and translate access into meaningful hosting impact. Lower-complexity activity may involve scanning, opportunistic exploitation, basic administrative access, simple webshell placement, hosted-content modification, credential harvesting, spam setup, or phishing-page deployment. Higher-capability activity may involve selective targeting of reseller or multi-tenant hosting platforms, careful use of legitimate hosting workflows, symlink or permission abuse, CloudLinux/CageFS boundary testing, root-context activity, stealthier persistence, tenant-aware scoping, DNS or mail manipulation, abuse-infrastructure staging, and delayed or selective customer-site modification.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on commodity scanners, reused exploit tooling, simple webshells, disposable VPS infrastructure, basic FTP access, visible payload retrieval, mass defacement, phishing-page kits, spam tooling, or straightforward redirect infrastructure. Higher-maturity activity may use rotating source infrastructure, compromised servers, residential or anonymized access, staged payload retrieval, trusted hosting paths, legitimate administrator timing, customer-maintenance windows, reseller workflows, compromised tenant accounts, layered webshell access, and operational patterns designed to blend with hosting support, patching, CMS updates, backup activity, migrations, or plugin maintenance.

Operational Scale

Single hosted site to multi-tenant hosting-platform exposure

Operational scale ranges from suspicious activity affecting one hosted site, FTP account, tenant directory, or customer webroot to broader exposure involving multiple customer sites, reseller-managed accounts, tenant directories, mailboxes, databases, DNS zones, backup paths, or hosting servers. Within one environment, scale can expand from one control-panel session, one plugin-adjacent path, or one webshell to root-context server activity, shared-hosting boundary failure, customer-site tampering, abuse-infrastructure deployment, credential rotation at scale, and tenant-by-tenant integrity review.

Escalation Likelihood

Moderate to High

Escalation likelihood is moderate to high when suspicious control-panel access, FTP activity, webshell access, symlink behavior, permission changes, plugin-adjacent execution, or tenant-context file activity is followed by privileged execution, account modification, root-owned file changes, hosted-content tampering, credential access, DNS or mail changes, database access, backup access, outbound payload retrieval, suspicious external communication, phishing or malware hosting, spam activity, abuse reports, or evidence that activity crossed expected tenant boundaries. Escalation likelihood increases when affected systems support shared hosting, reseller hosting, MSP-operated hosting, customer-facing infrastructure, high-value websites, mail services, DNS administration, hosted databases, backups, or CloudLinux/CageFS-isolated tenant environments.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, shared hosting, reseller hosting, FTP workflows, webroots, DNS, mail, databases, and backups commonly support customer-facing business operations.

·        Hosting-control-plane access can provide attackers with high operational leverage because one administrative surface may influence multiple websites, accounts, domains, mail services, databases, or customer environments.

·        Shared-hosting privilege escalation can provide attackers with high blast-radius potential when a tenant foothold, FTP account, webshell, symlink issue, permission weakness, or CloudLinux/CageFS boundary condition creates access beyond the expected tenant scope.

·        Hosted websites and mail infrastructure have high abuse value because they can support phishing, malware delivery, redirector infrastructure, credential harvesting, SEO spam, spam operations, payload staging, and trust abuse.

·        Customer-facing hosted content has high business value because compromise can trigger customer trust loss, legal review, regulatory assessment, customer notification analysis, abuse-report handling, revenue impact, and public communications response.

·        Adversaries benefit from environments where access-log retention, authentication/session telemetry, FTP logs, web access logs, endpoint process visibility, file and symlink telemetry, outbound network visibility, tenant mapping, reseller ownership, CloudLinux/CageFS mapping, and historical compromise review are incomplete.

·        Normal hosting workflows, including support access, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail changes, tenant provisioning, and CloudLinux/CageFS operations, can make attacker-driven activity harder to classify quickly.

·        Targeting probability should be assessed through hosting dependency, exposed control-plane services, LiteSpeed plugin deployment, shared-hosting density, FTP and web access exposure, tenant-boundary controls, customer-site criticality, telemetry maturity, and local evidence of access-to-impact behavior rather than CVE names, plugin presence, scanner traffic, or actor labels alone.

Most Likely Targets

·        Internet-facing cPanel, WHM, DNSOnly, WP Squared, hosting-control portals, reseller portals, administrative endpoints, and related hosting-control services.

·        LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, plugin-adjacent paths, shared-hosting integrations, CloudLinux/CageFS tenant environments, symlink-sensitive paths, and shared-hosting boundary controls.

·        Shared-hosting platforms, reseller-hosting environments, MSP-operated hosting environments, customer-managed hosting accounts, FTP-enabled tenant accounts, webshell-accessible paths, customer webroots, and tenant directories.

·        Customer websites, ecommerce sites, customer portals, CMS platforms, hosted applications, scripts, static content, upload directories, plugin directories, media paths, and public-facing hosted content.

·        DNS zones, mail services, mailboxes, databases, backup paths, configuration files, API keys, application secrets, web application credentials, customer records, and hosted application data.

·        Organizations with broad hosting dependency, exposed administrative services, vulnerable plugin deployments, high shared-hosting density, incomplete access logs, limited FTP or web access visibility, weak endpoint telemetry, missing file or symlink visibility, unclear tenant ownership, incomplete CloudLinux/CageFS mapping, delayed patch validation, inconsistent plugin update validation, or weak customer-impact scoping.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1: Exposed Hosting-Control or Shared-Hosting Attack Surface

The adversary targets exposed hosting-control services, vulnerable hosting administration components, vulnerable plugin behavior, or shared-hosting access paths that can provide an entry point into customer-facing hosting infrastructure. This stage should be mapped when telemetry or exposure review supports attempted or successful exploitation of internet-facing hosting-control services, plugin-adjacent behavior, or web-facing hosting infrastructure.

·        T1190 Exploit Public-Facing Application.

Stage 2: Unauthorized Administrative Access or Existing Tenant Foothold

The adversary gains unauthorized access to hosting-control functionality or operates from an existing tenant-level foothold such as FTP access, webshell access, a compromised hosting account, or a compromised hosted path. This stage should be tied to evidence of successful control-panel access, valid FTP or hosting-account use, suspicious session behavior, webshell activity, hosted-path access, or other post-access behavior rather than scan activity alone.

·        T1078 Valid Accounts.

·        T1505.003 Server Software Component: Webshell.

Stage 3: Shared-Hosting Privilege Escalation or Boundary Abuse

The adversary attempts to move from lower-privileged tenant access, plugin-adjacent behavior, symlink mishandling, or shared-hosting boundary weakness into privileged server-side activity, root-context execution, or access outside the expected tenant scope. This stage should be mapped when file, process, permission, symlink, or CloudLinux/CageFS evidence supports escalation behavior, not merely plugin presence or vulnerable-version status.

·        T1068 Exploitation for Privilege Escalation.

Stage 4: Hosting Server Execution and Administrative Change

The adversary executes commands, modifies accounts, changes services, alters administrative state, or performs privileged server-side actions after obtaining control-plane access or escalating within the hosting environment. This stage should be tied to shell execution, administrative tooling, account creation or modification, service changes, root-context process activity, or other execution evidence on affected hosting systems.

·        T1059.004 Command and Scripting Interpreter: Unix Shell.

·        T1136 Create Account.

Stage 5: Hosted File, Credential, and Infrastructure Discovery

The adversary reviews hosted files, configuration data, credentials, databases, backups, mail content, DNS or mail administration data, tenant directories, or other information stored on affected hosting systems. This stage should be tied to observed file access, directory traversal, archive staging, configuration review, database access, backup access, credential exposure, mailbox access, or tenant-spanning review behavior.

·        T1005 Data from Local System.

·        T1083 File and Directory Discovery.

Stage 6: Hosted-Content Tampering, Abuse Infrastructure, or Data Movement

The adversary modifies hosted content, deploys phishing or malware pages, places redirectors, uses affected infrastructure for spam or payload staging, retrieves additional tooling, or moves data through web-service or outbound channels. This stage should be tied to hosted-content changes, phishing or malware hosting, redirect behavior, spam activity, payload retrieval, suspicious outbound communication, abuse reports, confirmed data movement, or exfiltration-like traffic.

·        T1105 Ingress Tool Transfer.

·        T1567 Exfiltration Over Web Service.

T1491.002 Defacement: External Defacement.

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

Hosting control-plane compromise and shared-hosting privilege escalation begin when an adversary targets exposed hosting administration, vulnerable hosting-control software, vulnerable plugin behavior, FTP-accessible tenant paths, hosted paths accessible through webshells, symlink behavior, or shared-hosting boundary weaknesses. The attacker’s objective is to move from external exposure or tenant-level foothold activity into unauthorized administrative access, privilege escalation, root-context server activity, hosted-content tampering, credential access, DNS or mail manipulation, abuse-infrastructure deployment, tenant-boundary failure, or multi-tenant impact. The attack path is defined by exposed hosting-control or shared-hosting attack surface, unauthorized administrative access or existing tenant foothold, shared-hosting privilege escalation or boundary abuse, hosting server execution and administrative change, hosted file, credential, and infrastructure discovery, and hosted-content tampering, abuse infrastructure, or data movement. Downstream ransomware, broad enterprise intrusion, cloud-control-plane impact, or cross-environment lateral movement should be treated as conditional amplification unless supporting telemetry confirms those behaviors.

Stage 1: Exposed Hosting-Control or Shared-Hosting Attack Surface

The adversary targets internet-facing hosting-control services, vulnerable hosting administration components, vulnerable LiteSpeed plugin behavior, FTP-enabled tenant workflows, hosted paths accessible through webshells, or shared-hosting boundary conditions. The exposed surface may include cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller portals, administrative endpoints, shared-hosting paths, plugin-adjacent paths, CloudLinux/CageFS-isolated tenant environments, and customer-facing web infrastructure. This stage is not sufficient by itself to establish compromise because exposed services, vulnerable versions, plugin presence, scanner traffic, or failed requests may exist without successful access. This stage becomes material when exposure evidence aligns with suspicious control-panel access, abnormal authentication or session context, FTP or web access anomalies, webshell activity, symlink or permission abuse, plugin-adjacent execution, hosted-content changes, or outbound activity.

Stage 2: Unauthorized Administrative Access or Existing Tenant Foothold

The adversary obtains unauthorized access to hosting-control functionality or operates from an existing tenant-level foothold such as FTP access, webshell access, a compromised hosting account, or a compromised hosted path. Observable evidence may include successful control-panel access outside normal patterns, suspicious session behavior, unexpected administrative actions, valid FTP or hosting-account use from abnormal context, webshell activity, unusual web-access patterns, customer-path access, or hosted-file activity outside expected workflows. This stage changes the event from exposure into possible compromise. The key signal is not login, FTP use, or web access by itself; it is access that aligns with abnormal source context, unusual timing, unexpected administrative behavior, suspicious file activity, webshell evidence, or follow-on privilege-escalation and tenant-impact signals.

Stage 3: Shared-Hosting Privilege Escalation or Boundary Abuse

The adversary attempts to move from lower-privileged tenant access, plugin-adjacent behavior, symlink mishandling, permission weakness, or shared-hosting boundary conditions into privileged server-side activity, root-context execution, or access outside the expected tenant scope. This stage is operationally important because routine customer FTP workflows, plugin maintenance, CMS updates, or support activity may resemble suspicious behavior unless file, symlink, process, permission, and tenant-mapping evidence is available. Symlink or boundary behavior should not be treated as confirmed compromise without context. It becomes materially significant when symlink creation or traversal, permission changes, root-owned file changes, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, or tenant-spanning access aligns with suspicious FTP activity, webshell activity, hosted-path access, or unexpected privileged execution.

Stage 4: Hosting Server Execution and Administrative Change

The adversary executes commands, modifies accounts, changes services, alters administrative state, stages tooling, or performs privileged server-side actions after obtaining control-plane access or escalating within the shared-hosting environment. Observable evidence may include shell execution, administrative tooling, service modification, account creation or modification, password reset activity, reseller-account changes, root-context process activity, root-owned file changes, plugin-adjacent process lineage, cron or service changes, or execution from directories associated with hosted content or plugin behavior. This stage increases business risk because it may indicate that the incident has moved beyond exposure or access into server-side control. The strongest signal is execution or administrative change that exceeds approved hosting support, patching, plugin update, backup, migration, CMS maintenance, reseller administration, or customer-maintenance baselines.

Stage 5: Hosted File, Credential, and Infrastructure Discovery

The adversary reviews hosted files, configuration data, credentials, databases, backups, mail content, DNS or mail administration data, tenant directories, reseller structures, or other information stored on affected hosting systems. This may occur through control-panel access, shell activity, FTP access, webshell activity, directory traversal, archive staging, database access, backup review, configuration-file access, mailbox access, or tenant-spanning file-system review. This stage increases business risk because it may expose where customer credentials, application secrets, database connection strings, customer records, hosted content, mail data, backups, or regulated information are stored. The strongest signal is discovery activity that exceeds expected user, tenant, reseller, support, backup, plugin, or maintenance baselines and occurs near suspicious control-plane access, FTP or webshell activity, symlink or permission abuse, root-context execution, or tenant-boundary anomalies.

Stage 6: Hosted-Content Tampering, Abuse Infrastructure, or Data Movement

The adversary modifies hosted content, places webshells, deploys phishing or malware pages, adds redirectors, manipulates DNS or mail settings, uses affected infrastructure for spam or payload staging, retrieves additional tooling, or moves data through web-service or outbound channels. This stage provides the clearest connection between hosting compromise and business impact when it follows suspicious administrative access, tenant foothold activity, shared-hosting boundary abuse, privileged execution, hosted-file discovery, credential exposure, or customer-site modification. Hosted-content changes or outbound activity should not be treated as confirmed data theft by itself because hosting environments support legitimate uploads, migrations, backups, customer changes, CDN updates, mail operations, and administrative workflows. It becomes materially significant when tampering or movement behavior aligns with webshell placement, phishing or malware hosting, redirect behavior, spam activity, suspicious DNS or mail changes, high-volume outbound activity, rare destinations, abuse reports, sensitive data access, customer-impact evidence, or inability to prove non-exposure.

S19 — Attack Chain Risk Amplification Summary

Hosting control-plane compromise and shared-hosting privilege escalation amplify risk because they target infrastructure that often concentrates customer websites, reseller administration, hosted content, DNS, mail services, databases, backups, FTP access, tenant directories, plugin behavior, credential material, and customer-facing trust. The chain becomes materially more dangerous when exposed hosting-control services, vulnerable LiteSpeed plugin deployments, FTP or webshell foothold activity, symlink or permission abuse, suspicious administrative access, root-context execution, hosted-content tampering, DNS or mail manipulation, suspicious outbound activity, abuse reporting, or tenant-impact evidence appears on the same affected hosting environment.

·        Broad hosting dependency increases exposure because cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller hosting, shared hosting, managed DNS, mail services, databases, backups, and customer webroots often support customer-facing business operations.

·        Exposed hosting-control services increase risk when internet-facing cPanel, WHM, DNSOnly, WP Squared, reseller portals, administrative endpoints, or related hosting-control services align with suspicious authentication, session activity, administrative actions, hosted-content changes, or outbound behavior.

·        LiteSpeed plugin exposure increases concern when LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin deployments align with FTP or webshell foothold evidence, symlink behavior, permission anomalies, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, or root-context activity.

·        FTP or webshell footholds amplify risk when lower-privileged access is followed by file-system changes, symlink creation or traversal, permission changes, unexpected process execution, hosted-content tampering, credential access, or evidence of access outside the expected tenant scope.

·        Shared-hosting boundary failure increases business impact because one compromised tenant path, plugin component, FTP account, webshell, symlink condition, or root-context change may affect multiple customers, reseller-managed sites, tenant directories, mailboxes, databases, DNS zones, or webroots.

·        Unauthorized administrative access becomes materially significant when control-panel activity, session behavior, account changes, DNS changes, mail changes, package changes, reseller modifications, or hosted-content changes deviate from approved hosting administration, support, patching, migration, or customer-maintenance baselines.

·        Root-context process activity increases concern when privileged execution follows suspicious control-panel access, FTP activity, webshell activity, symlink or permission anomalies, plugin-adjacent behavior, or tenant-context file activity.

·        Hosted-content tampering amplifies business impact when it involves webshell placement, phishing pages, malware delivery content, unauthorized redirects, SEO spam, credential-harvesting pages, suspicious scripts, hidden files, or customer-facing defacement.

·        DNS and mail manipulation increase exposure when affected hosting infrastructure is used to alter domain trust, redirect traffic, support phishing delivery, enable spam activity, modify mail routing, or undermine customer communications.

·        Credential and secret exposure increases risk when configuration files, database credentials, API keys, mail credentials, FTP credentials, SSH keys, backup credentials, reseller accounts, administrator accounts, or application secrets may have been accessed through control-plane compromise, root-context access, or tenant-boundary failure.

·        Outbound communication increases concern when payload retrieval, command-and-control behavior, suspicious VPS communication, redirector use, spam activity, malware hosting, phishing delivery, exfiltration-like traffic, or abuse reports follow suspicious access or privilege-escalation behavior.

·        Business exposure increases when affected systems support shared hosting, reseller hosting, MSP-operated customer environments, ecommerce sites, customer portals, managed DNS, mail hosting, databases, backups, regulated content, high-value hosted applications, or large numbers of customer webroots.

·        Incomplete access-log retention, weak authentication or session telemetry, limited FTP or web access history, missing endpoint process visibility, missing file or symlink telemetry, incomplete CloudLinux/CageFS tenant mapping, weak reseller ownership mapping, or limited outbound network visibility can force broader validation because the organization cannot quickly prove whether access remained isolated.

Response burden increases because teams must validate patch status, LiteSpeed plugin update status, exposed asset ownership, historical compromise, access and session activity, FTP and web access, webshell evidence, file and symlink behavior, endpoint execution, root-context activity, DNS and mail integrity, credential exposure, tenant impact, abuse reports, customer assurance, legal obligations, and executive incident governance.

Figure 3

S20 — Tactics, Techniques, and Procedures

Figure 3

Hosting control-plane compromise and shared-hosting privilege escalation attack-chain model showing exposed hosting administration, unauthorized control-plane access, FTP or webshell foothold activity, LiteSpeed plugin or shared-hosting boundary exposure, symlink or permission abuse, root-context execution, hosted-content tampering, outbound abuse, tenant-impact scoping, and post-remediation containment validation.

Exposed Hosting-Control and Shared-Hosting Attack Surface

Adversaries may target internet-facing cPanel, WHM, DNSOnly, WP Squared, reseller portals, hosting-control interfaces, administrative endpoints, LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin deployments, FTP-enabled tenant workflows, hosted paths accessible through webshells, plugin-adjacent paths, CloudLinux/CageFS-isolated tenant environments, and customer-facing web infrastructure. This behavior becomes risk-relevant when exposed services, vulnerable versions, plugin presence, scanner traffic, or failed requests align with suspicious control-panel access, abnormal authentication or session context, FTP or web access anomalies, symlink or permission abuse, plugin-adjacent execution, hosted-content changes, or outbound activity.

Unauthorized Hosting-Control Access

Adversaries may obtain unauthorized access to hosting-control functionality through exposed administrative services, authentication-bypass conditions, suspicious session behavior, or compromised hosting credentials. This behavior may appear as successful control-panel access outside normal patterns, unusual source context, unexpected administrative actions, reseller-account changes, package changes, password reset activity, DNS or mail modifications, hosted-content changes, or access occurring outside approved support, patching, migration, or customer-maintenance workflows. This behavior becomes high risk when administrative access is followed by privileged execution, file-system changes, account modification, hosted-content tampering, outbound activity, abuse reports, or tenant-impact evidence.

FTP or Webshell Foothold Activity

Adversaries may operate from lower-privileged access such as FTP accounts, compromised hosting accounts, webshell access, customer upload paths, CMS-accessible paths, or compromised hosted directories. This behavior may resemble legitimate customer maintenance, CMS updates, plugin changes, file uploads, or support activity without additional context. It becomes materially significant when FTP or webshell activity aligns with abnormal source context, unusual timing, unexpected file writes, suspicious scripts, hidden files, symlink creation or traversal, permission changes, plugin-adjacent execution, hosted-content tampering, outbound communication, or evidence of access outside the expected tenant scope.

LiteSpeed Plugin and Shared-Hosting Boundary Abuse

Adversaries may attempt to abuse vulnerable LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin behavior, symlink mishandling, permission weaknesses, plugin-adjacent file paths, or shared-hosting boundary conditions to move from tenant-level access toward privileged server-side activity. This behavior becomes high risk when symlink behavior, file permissions, root-owned file changes, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, or tenant-spanning access aligns with suspicious FTP activity, webshell activity, hosted-path access, or unexpected privileged execution. Plugin presence or vulnerable version status alone should support prioritization and hunting, but should not be treated as confirmed compromise without supporting behavior.

Root-Context Execution and Administrative Change

Adversaries may execute commands, modify accounts, change services, alter administrative state, stage tooling, or perform privileged server-side actions after obtaining control-plane access or escalating within the shared-hosting environment. Relevant behavior may include Unix shell execution, administrative tooling, service modification, account creation or modification, password reset activity, reseller-account changes, root-context process activity, root-owned file changes, plugin-adjacent process lineage, cron or service changes, or execution from directories associated with hosted content or plugin behavior. This behavior becomes high risk when execution or administrative change deviates from approved hosting support, patching, plugin updates, backups, migrations, CMS maintenance, reseller administration, or customer-maintenance baselines.

Hosted File, Credential, and Infrastructure Discovery

Adversaries may review hosted files, configuration data, credentials, databases, backups, mail content, DNS or mail administration data, tenant directories, reseller structures, or other information stored on affected hosting systems. This may occur through control-panel access, shell activity, FTP access, webshell activity, directory traversal, archive staging, database access, backup review, configuration-file access, mailbox access, or tenant-spanning file-system review. This behavior becomes materially significant when discovery exceeds expected user, tenant, reseller, support, backup, plugin, or maintenance baselines and occurs near suspicious control-panel access, FTP or webshell activity, symlink or permission abuse, root-context execution, or tenant-boundary anomalies.

Hosted-Content Tampering and Customer-Site Modification

Adversaries may modify customer websites, place webshells, alter scripts, add redirectors, create phishing pages, deploy malware delivery content, insert SEO spam, change hidden files, manipulate CMS content, or deface customer-facing web properties. This behavior becomes high risk when hosted-content modification follows suspicious administrative access, FTP or webshell foothold activity, symlink or permission anomalies, root-context execution, credential access, DNS or mail changes, outbound activity, or abuse reports. It is especially material when affected content supports ecommerce, customer portals, regulated workflows, customer communications, brand trust, or high-volume public traffic.

DNS, Mail, and Abuse-Infrastructure Manipulation

Adversaries may manipulate DNS zones, mail routing, webmail settings, mailbox access, MX records, SPF, DKIM, DMARC-related administration, redirect behavior, spam infrastructure, phishing delivery paths, malware-hosting paths, or payload-staging locations. This behavior becomes high risk when DNS or mail changes align with suspicious control-panel access, reseller-account changes, root-context activity, hosted-content tampering, outbound communication, phishing reports, spam reports, malware reports, or customer-impact evidence. The strongest signal is abuse activity that uses trusted customer or hosting-provider infrastructure to support phishing, malware delivery, redirectors, spam, credential harvesting, or other downstream abuse.

Outbound Communication and Payload Staging

Adversaries may retrieve tooling, stage payloads, communicate with suspicious external infrastructure, use affected hosting servers as redirectors, host malware, support phishing delivery, send spam, or move data through web-service or outbound channels. This behavior should be evaluated against approved backups, migrations, CDN activity, customer uploads, mail operations, monitoring, and administrative workflows before being treated as malicious. It becomes materially significant when outbound behavior follows suspicious control-panel access, FTP or webshell activity, symlink or permission abuse, root-context execution, hosted-file discovery, hosted-content tampering, abuse reports, rare destinations, suspicious VPS communication, high-volume transfer, or exfiltration-like patterns.

Operational Blending With Hosting Workflows

Adversaries may blend malicious behavior into normal hosting operations such as support access, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail changes, tenant provisioning, CloudLinux/CageFS operations, webroot maintenance, and customer-requested content changes. This blending is effective because legitimate hosting environments often involve administrative access, file changes, FTP workflows, plugin maintenance, service changes, DNS updates, mail operations, customer support, and outbound traffic.

Conditional Downstream Enterprise or Cloud Expansion

Adversaries may attempt to use compromised hosting infrastructure, exposed credentials, customer-site access, administrative accounts, scripts, backups, configuration files, or trusted hosted content to reach downstream enterprise systems, SaaS platforms, cloud resources, VPNs, customer applications, or privileged workflows. This behavior should remain conditional unless it follows suspicious hosting-control access, FTP or webshell activity, privilege escalation, credential exposure, hosted-content tampering, outbound communication, or tenant-impact evidence within a bounded time window.

S20A — Adversary Tradecraft Summary

Hosting control-plane compromise and shared-hosting privilege escalation target the trust relationship between hosting administration, shared-hosting isolation, customer-owned web content, plugin behavior, FTP workflows, hosted paths accessible through webshells, tenant boundaries, DNS and mail administration, credential material, and incident-response containment. The adversary objective is to convert exposed hosting-control access or lower-privileged tenant foothold activity into unauthorized administration, privilege escalation, root-context server activity, customer-site compromise, abuse infrastructure, tenant-impact uncertainty, or incomplete containment while blending into normal hosting workflows.

·        The core tradecraft pattern is suspicious hosting-control exposure, unauthorized administrative access, FTP or webshell foothold activity, LiteSpeed plugin or shared-hosting boundary abuse, symlink or permission anomalies, privileged execution, hosted-content tampering, outbound abuse, tenant-impact evidence, or post-remediation containment uncertainty.

·        The behavior is not dependent on a single CVE, exploit string, scanner name, actor name, request path, plugin version, webshell name, filename, symlink path, source IP, user agent, payload, domain, or static IOC.

·        Adversaries may use exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller portals, FTP accounts, compromised hosting accounts, hosted paths accessible through webshells, symlink behavior, CloudLinux/CageFS boundary conditions, root-context execution, DNS or mail changes, hosted-content tampering, and outbound infrastructure abuse.

·        The strongest operational risk occurs when suspicious access affects shared-hosting platforms, reseller-hosting environments, MSP-operated hosting, customer-facing sites, ecommerce properties, customer portals, managed DNS, mail hosting, databases, backups, high-value hosted applications, regulated customer content, or environments with many customer webroots.

·        Detection requires visibility into the hosting-control, authentication, session, FTP, web access, endpoint process, file, symlink, DNS, mail, proxy, firewall, CloudLinux/CageFS tenant-mapping, reseller ownership, abuse-report, backup, customer-support, and incident-response evidence that confirms or disproves impact.

·        Response requires treating suspected hosting-control-plane compromise or shared-hosting privilege escalation as a hosting infrastructure trust, tenant-isolation, customer-impact, credential-exposure, abuse-infrastructure, and containment-validation incident, not a routine patching issue, isolated scan event, single FTP session, plugin inventory finding, or customer-support issue.

·        The behavior remains durable because the adversary objective is to convert trusted hosting administration or tenant-level access into server-side control, customer-site impact, credential uncertainty, abuse-infrastructure use, or tenant-boundary failure regardless of the specific exploit artifact, plugin version, actor branding, source infrastructure, filename, symlink path, or campaign label used.

S21 — Detection Strategy Overview

Detection Philosophy

Detection for hosting control-plane compromise and shared-hosting privilege escalation must be behavior-led, telemetry-aware, and correlation-driven. The detection model should not treat a single exposed cPanel service, vulnerable LiteSpeed plugin version, scanner hit, failed request, successful login, FTP session, web request, file write, symlink event, outbound connection, or abuse report as sufficient proof of compromise. The strongest posture comes from linking suspicious hosting-control access, abnormal authentication or session context, FTP or webshell foothold evidence, symlink or permission abuse, plugin-adjacent execution, root-context process activity, hosted-content tampering, DNS or mail manipulation, outbound abuse, and tenant-impact evidence within a bounded investigation window.

The detection strategy should assume the adversary may follow either of two related hosting-infrastructure access paths. CVE-2026-41940 represents the exposed hosting-control-plane lane, where unauthorized access to affected cPanel, WHM, DNSOnly, WP Squared, or related hosting administration services can create administrative compromise risk. CVE-2026-54420 represents the shared-hosting escalation lane, where LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin symlink mishandling in CloudLinux/CageFS environments may allow an attacker with FTP or webshell access to escalate an existing foothold toward root-level or server-level exposure. Detection should prioritize access-to-impact continuity over CVE-string matching, scanner-name matching, plugin-version inventory, webshell filename matching, symlink-path matching, or static IOC coverage.

Compromise confirmation should require correlation between suspicious exposure, access, foothold, or escalation behavior and one or more downstream behaviors, including unauthorized administrative actions, abnormal session behavior, FTP activity outside expected workflows, webshell activity, symlink creation or traversal, permission changes, root-owned file changes, plugin-adjacent execution, hosted-content modification, account changes, DNS or mail changes, credential access, database or backup access, suspicious outbound communication, abuse reports, or tenant-impacting activity.

Attribution must remain conditional. Activity should not be attributed to a named actor, intrusion cluster, exploit kit, scanner, webshell family, or hosting-abuse campaign unless telemetry aligns with validated tradecraft, infrastructure, timing, victimology, tooling, exploit behavior, or operational pattern. The default detection posture should identify hosting-control-plane compromise and shared-hosting privilege-escalation risk without over-attributing exposed cPanel, LiteSpeed plugin, FTP, webshell, symlink, or outbound activity to a single campaign or tool.

Primary Detection Anchors

·        Hosting-control access events involving cPanel, WHM, DNSOnly, WP Squared, reseller portals, administrative endpoints, or related hosting-control services with abnormal source context, unusual session behavior, unexpected administrative actions, or activity outside approved support, patching, migration, or customer-maintenance workflows.

·        FTP, web access, or webshell activity involving abnormal source infrastructure, unusual timing, unexpected file writes, suspicious scripts, hidden files, hosted paths accessible through webshells, customer upload paths, CMS-accessible paths, or tenant directories outside expected workflows.

·        LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity that aligns with symlink creation or traversal, permission anomalies, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, tenant-spanning access, root-owned file changes, or unexpected privileged execution.

·        Endpoint process activity on affected hosting servers showing shell execution, administrative tooling, service changes, account creation or modification, root-context process activity, plugin-adjacent process lineage, cron changes, or execution from directories associated with hosted content or plugin behavior.

·        File and symlink telemetry showing hosted-content tampering, webshell placement, suspicious scripts, hidden files, unexpected symlinks, permission changes, root-owned file changes, archive staging, credential access, database access, backup access, or tenant-spanning file-system review.

·        DNS, mail, and hosting-control changes involving zone modification, mail routing changes, MX changes, SPF, DKIM, DMARC-related administration, webmail access, mailbox manipulation, reseller-account changes, package changes, or domain-trust changes near suspicious access or privilege-escalation behavior.

·        Outbound network, proxy, firewall, DNS, and abuse-report evidence showing payload retrieval, suspicious VPS communication, command-and-control-like behavior, redirector use, phishing hosting, malware hosting, spam activity, high-volume transfer, exfiltration-like traffic, or other abuse following suspicious hosting activity.

·        Tenant-impact evidence showing activity that affects multiple customer webroots, reseller-managed sites, tenant directories, mailboxes, databases, DNS zones, backup paths, hosted applications, or shared-hosting boundaries.

Detection Prioritization Model

Highest-priority detections should focus on correlated access-to-impact behavior rather than isolated exposure or single-event anomalies. The first priority is suspicious hosting-control access or tenant foothold activity followed by administrative change, privileged execution, hosted-content tampering, DNS or mail manipulation, outbound abuse, or tenant-impact evidence.

The second priority is shared-hosting escalation behavior. FTP or webshell foothold evidence should be treated as high risk when it is followed by symlink creation or traversal, permission changes, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, root-context activity, root-owned file changes, or access outside the expected tenant scope.

The third priority is customer-impact and abuse behavior. Webshell placement, phishing pages, malware delivery content, unauthorized redirects, SEO spam, credential-harvesting pages, spam activity, suspicious DNS or mail changes, and abuse reports should receive elevated priority when they appear near suspicious hosting-control access, FTP or webshell activity, privilege escalation, or root-context execution.

The fourth priority is tenant-scale behavior. Repeated suspicious access across multiple tenants, reseller accounts, customer webroots, hosted domains, FTP accounts, mailboxes, databases, DNS zones, or hosting servers should increase urgency even when each individual event appears explainable in isolation.

The fifth priority is enrichment from scanner activity, vulnerable-version inventory, public exploit reporting, abuse reports, customer tickets, support records, CDN logs, CMS telemetry, web application logs, or third-party notifications. These signals can support prioritization and triage but should not replace hosting-control, endpoint, file, symlink, network, and tenant-impact correlation.

Correlation Strategy (Strict Enforcement)

Correlation must enforce access-to-impact proximity. Exposed service, vulnerable plugin, scan, login, FTP, web access, file, symlink, process, DNS, mail, or outbound events should be correlated only when the activity involves the same affected server, same control-panel account, same hosting account, same FTP account, same tenant, same reseller, same domain, same webroot, related plugin path, related process lineage, related source infrastructure, related time window, or related customer-impact evidence.

Correlation windows should be narrow enough to reduce false positives while allowing for delayed operator staging and shared-hosting escalation. Short-window activity should be used for suspicious hosting-control access, abnormal session behavior, FTP or web access, webshell activity, symlink changes, permission changes, plugin-adjacent execution, and immediate hosted-content changes. Medium-window activity should be used for root-context execution, account changes, DNS or mail manipulation, credential access, database access, backup access, outbound payload retrieval, and abuse-infrastructure behavior. Longer-window activity should be reserved for tenant-impact scoping, historical compromise review, post-remediation validation, repeated access, abuse reports, and customer assurance.

Detection logic should require at least one suspicious access, foothold, or escalation signal and one downstream impact or control signal before producing high-confidence compromise alerts. Examples include:

·        Suspicious cPanel or WHM access followed by unexpected administrative actions, account changes, DNS changes, mail changes, or hosted-content modification.

·        FTP or webshell activity followed by symlink creation or traversal, permission changes, root-owned file changes, plugin-adjacent execution, or CloudLinux/CageFS boundary anomalies.

·        LiteSpeed plugin-adjacent file or process activity followed by privileged execution, tenant-spanning access, root-context process activity, or access outside expected tenant scope.

·        Hosted-content changes followed by outbound payload retrieval, phishing or malware hosting, redirect behavior, spam activity, abuse reports, or customer-impact evidence.

·        Suspicious access or escalation behavior followed by credential access, database access, backup access, archive staging, or tenant-by-tenant file-system review.

Hosting-control-only, FTP-only, web-only, file-only, symlink-only, endpoint-only, DNS-only, mail-only, outbound-only, or abuse-report-only anomalies must not be treated as confirmed hosting compromise unless they correlate back to suspicious access, foothold, privilege-escalation, file-system, outbound, or tenant-impact behavior.

Telemetry Prioritization

The highest-value telemetry sources are control-panel access logs, authentication logs, session telemetry, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, administrative action logs, DNS logs, mail logs, proxy logs, firewall logs, outbound DNS logs, CloudLinux/CageFS tenant mapping, reseller ownership mapping, backup records, abuse reports, customer support records, and incident-response records.

Where available, telemetry should preserve user, account, source IP, source ASN, geography, user agent, session identifier, authentication result, administrative action, FTP account, web request, file path, symlink path, file owner, permission state, process name, process command line, parent process, effective user, root-context indicator, plugin path, tenant identifier, reseller identifier, domain, webroot, database, mailbox, DNS zone, mail setting, destination domain, byte count, network action, abuse-report context, and remediation action.

Organizations with limited hosting telemetry should prioritize compensating sources from endpoint process telemetry, web server logs, FTP logs, WAF logs, proxy logs, DNS logs, firewall logs, EDR, file-integrity monitoring, backup records, abuse reports, customer tickets, hosting-provider records, and CloudLinux/CageFS tenant mapping. Hosting telemetry gaps reduce confidence but do not eliminate detection value when access, process, file, network, and tenant-impact evidence can be correlated.

Detection Design Constraints

Hosting environments include legitimate support access, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail changes, tenant provisioning, CloudLinux/CageFS operations, webroot maintenance, customer-requested content changes, monitoring workflows, and abuse-response activity. Detection content must account for approved hosting-provider workflows, known reseller accounts, expected FTP accounts, support windows, backup jobs, migration periods, plugin maintenance, customer maintenance, and business-approved exception groups.

Detection logic must avoid relying solely on public exploit strings, scanner names, actor names, webshell names, user agents, source IPs, request paths, filenames, symlink paths, plugin versions, or static indicators. The attack path should be modeled around suspicious hosting-control access, FTP or webshell foothold evidence, symlink or permission abuse, root-context execution, hosted-content tampering, DNS or mail manipulation, outbound abuse, and tenant-impact evidence.

Detection logic must also account for environments where telemetry is distributed across hosting control panels, Linux audit sources, EDR, file-integrity monitoring, web servers, FTP services, DNS platforms, mail services, proxy systems, firewalls, WAFs, CloudLinux/CageFS controls, backup platforms, support systems, and customer records. Correlation should use account identity, tenant identity, reseller identity, domain, server, webroot, file path, symlink path, process lineage, source infrastructure, administrative action, and remediation timeline to connect related events across services.

Because public reporting may evolve, detection should remain resilient to changes in exploit artifacts, request formatting, scanner infrastructure, webshell names, filenames, symlink paths, payloads, plugin versions, source infrastructure, and campaign branding. A detection model that only identifies a known exploit string or artifact will age poorly. A detection model that identifies hosting-control or tenant-foothold activity progressing into privilege escalation, customer-site impact, or abuse infrastructure will retain value across future hosting compromise activity.

Baseline and Deployment Requirements

Before production alerting, organizations should define the authoritative hosting and tenant scope, including cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, reseller portals, shared-hosting servers, CloudLinux/CageFS environments, FTP accounts, webroots, tenant directories, customer domains, DNS zones, mail services, databases, backups, high-value hosted applications, customer portals, ecommerce sites, and administrative accounts.

Organizations should baseline normal hosting-control access, administrative actions, reseller workflows, FTP activity, web access activity, CMS updates, plugin updates, support windows, backup jobs, migration activity, certificate renewal, DNS changes, mail changes, service changes, file ownership, permission patterns, symlink behavior, process execution, outbound communication, abuse reports, and CloudLinux/CageFS tenant behavior. The baseline should include customer maintenance, reseller administration, hosting-provider support, emergency patching, routine plugin updates, migrations, and change-control periods.

Detection engineering should validate:

·        Control-panel logs preserve user, source IP, session context, authentication result, administrative action, affected account, affected domain, reseller context, timestamp, and action outcome.

·        FTP logs preserve account, source IP, path, file operation, timestamp, transferred bytes, authentication result, and relationship to tenant identity.

·        Web access logs preserve source IP, host, URI, method, status code, user agent, request size, response size, timestamp, and relationship to hosted path or customer domain.

·        Endpoint process telemetry preserves process name, command line, parent process, effective user, working directory, file path, network connection, root-context indicator, and relationship to hosting-control, plugin, FTP, or webroot activity.

·        File and symlink telemetry preserves file path, symlink target where available, owner, group, permissions, inode or equivalent identifier where available, creating process, modifying process, timestamp, and tenant or reseller mapping.

·        DNS and mail telemetry preserves administrative changes, zone changes, mail routing changes, mailbox activity, MX changes, SPF, DKIM, DMARC-related administration, webmail access, spam activity, and relationship to affected domains.

·        Proxy, firewall, DNS, WAF, EDR, abuse-report, backup, customer-support, and incident-response telemetry can support outbound communication, abuse-infrastructure review, hosted-content integrity, customer-impact scoping, and containment validation.

·        Asset, tenant, reseller, domain, FTP account, webroot, plugin, database, mailbox, backup, and exception mappings accurately distinguish approved hosting activity from suspicious access or escalation behavior.

Initial deployment should begin in hunt mode. Alert mode should be enabled only after local field mappings, tenant-specific baselines, approved hosting workflows, account allowlists, support-window rules, plugin-maintenance expectations, CloudLinux/CageFS mappings, exception groups, false-positive patterns, remediation workflows, and SOC triage procedures are validated.

Variant Resilience Requirements

Detection must remain effective if attackers modify exploit artifacts, rotate infrastructure, use different scanners, change request paths, change user agents, use different webshell names, modify filenames, alter symlink paths, change payload staging, use different FTP accounts, compromise different hosting accounts, abuse different plugin paths, or shift between control-plane access and tenant-foothold escalation.

Variant-resilient detection should focus on:

·        Suspicious hosting-control access followed by administrative change, hosted-content tampering, outbound abuse, or tenant-impact evidence.

·        FTP or webshell activity followed by symlink or permission anomalies, plugin-adjacent execution, root-context process activity, or tenant-boundary anomalies.

·        Valid hosting-account activity from unfamiliar source, geography, ASN, user agent, time window, or workflow followed by unexpected file, administrative, or outbound behavior.

·        Hosted-content modification that exceeds expected customer, support, CMS, plugin, backup, or migration baselines.

·        DNS or mail changes that occur near suspicious access, root-context execution, hosted-content tampering, phishing reports, spam reports, malware reports, or customer-impact evidence.

·        Outbound communication that follows suspicious access, privilege escalation, hosted-file discovery, or hosted-content tampering.

·        Repeated suspicious activity across multiple tenants, webroots, reseller accounts, domains, FTP accounts, hosting servers, or customer environments.

The detection model should also support future hosting-control compromise, plugin-mediated escalation, shared-hosting boundary abuse, and tenant-impact techniques by abstracting from any specific CVE into a broader hosting access-to-impact framework. CVE-specific, actor-specific, exploit-specific, or infrastructure-specific logic can enrich the model, but the core detection strategy should remain behavior-led.

Operational Detection Model

The operational model should organize detections into a progressive triage chain.

·        Exposure and access identification should flag exposed hosting-control services, vulnerable plugin deployments, suspicious control-panel access, abnormal session behavior, unexpected administrative actions, suspicious FTP activity, webshell activity, and hosted-path access outside approved workflows.

·        Foothold and escalation identification should flag symlink creation or traversal, permission changes, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, root-owned file changes, root-context process activity, or tenant-spanning access.

·        Server execution and administrative-change identification should flag shell execution, administrative tooling, account creation or modification, service changes, reseller modifications, package changes, cron changes, DNS changes, mail changes, and root-context execution.

·        Hosted-content and credential-risk identification should flag webshell placement, suspicious scripts, hidden files, redirect changes, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, configuration-file access, database access, backup access, archive staging, and credential exposure.

·        Outbound abuse identification should flag payload retrieval, suspicious VPS communication, command-and-control-like behavior, redirector use, malware hosting, phishing delivery, spam activity, high-volume transfer, exfiltration-like traffic, and abuse-report correlation.

·        Tenant-impact identification should flag activity crossing expected tenant, reseller, domain, webroot, mailbox, database, DNS zone, or backup boundaries.

·        Containment-validation identification should flag continued suspicious access, process activity, file changes, outbound communication, DNS or mail manipulation, webshell recurrence, abuse reports, or tenant-impact evidence after patching, plugin update, credential rotation, account cleanup, or containment.

SOC triage should begin by confirming whether the affected system was exposed, whether the relevant hosting-control or plugin component was vulnerable, whether the source context matches approved behavior, whether FTP or webshell activity is expected, whether file and symlink behavior aligns with tenant ownership, whether process activity is root-context or plugin-adjacent, whether DNS or mail changes are approved, whether outbound activity is expected, and whether tenant-impact evidence exists. Analysts should then determine whether activity represents exposure only, suspicious access, probable compromise, privilege escalation, customer-site impact, abuse-infrastructure use, tenant-boundary failure, or containment failure.

Explicit Non-Deployment Guardrails

Do not deploy high-severity compromise alerts based only on a single exposed service, single vulnerable plugin version, single scanner hit, single failed request, single successful login, single FTP session, single web request, single file write, single symlink event, single outbound connection, or isolated abuse report.

Do not treat plugin presence, vulnerable version status, internet exposure, scanner traffic, proof-of-concept activity, or failed exploit attempts as confirmed compromise without supporting access, execution, file-system, outbound, or tenant-impact evidence.

Do not treat legitimate hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail changes, tenant provisioning, or CloudLinux/CageFS operations as malicious without abnormal context or follow-on impact.

Do not rely on CVE strings, scanner names, actor names, exploit strings, webshell names, filenames, symlink paths, source IPs, user agents, payloads, domains, or static IOCs as the primary detection basis.

Do not attribute activity to a named actor, campaign, scanner, webshell family, or exploit kit unless telemetry or validated intelligence supports that attribution.

Do not treat DNS, mail, outbound, web, file, FTP, endpoint, or abuse-report anomalies as hosting compromise unless they correlate to suspicious access, foothold, privilege escalation, hosted-content tampering, outbound abuse, or tenant-impact pathways.

Do not suppress suspicious activity solely because it used a valid hosting account, legitimate control panel, expected FTP service, common CMS path, approved hosting server, normal-looking web request, or known support workflow.

Do not enable alert mode until field mappings, indexes, sourcetypes, account mappings, tenant mappings, reseller mappings, plugin mappings, support workflows, exception groups, false-positive baselines, and SOC triage procedures are validated.

Do not promote detections from hunt mode to alert mode until false-positive behavior from customer maintenance, reseller administration, hosting-provider support, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail changes, tenant provisioning, and CloudLinux/CageFS operations has been reviewed.

Do not treat absence of malware telemetry, exploit-string evidence, or known IOCs as absence of compromise. Use hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, proxy, firewall, abuse-report, tenant-mapping, backup, and customer-support telemetry as compensating evidence while documenting visibility limitations.

S22 — Primary Detection Signals

Primary Detection Signals

The primary detection signals for hosting control-plane compromise and shared-hosting privilege escalation should focus on activity that links suspicious exposure, access, foothold, or escalation behavior to hosting impact, customer-site modification, abuse infrastructure, or tenant-boundary failure. These signals are highest value when they appear together within a bounded investigation window and map to the same server, account, tenant, reseller, domain, webroot, plugin path, process lineage, source infrastructure, outbound destination, or customer-impact record.

·        Hosting-control access events showing successful or attempted access to cPanel, WHM, DNSOnly, WP Squared, reseller portals, administrative endpoints, or related control-plane services from unfamiliar source IPs, geographies, ASNs, user agents, session contexts, or time windows.

·        Unexpected administrative actions after suspicious hosting-control access, including account creation or modification, password reset activity, reseller-account changes, package changes, DNS changes, mail changes, webroot changes, backup access, database access, or administrative setting changes.

·        FTP, web access, or webshell activity involving abnormal source context, unusual timing, unexpected file writes, suspicious scripts, hidden files, hosted paths accessible through webshells, customer upload paths, CMS-accessible paths, or tenant directories outside expected workflows.

·        LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity that aligns with symlink creation or traversal, permission anomalies, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, root-owned file changes, tenant-spanning access, or unexpected privileged execution.

·        Endpoint process activity showing Unix shell execution, administrative tooling, service changes, account creation or modification, root-context process activity, plugin-adjacent process lineage, cron changes, or execution from directories associated with hosted content or plugin behavior.

·        File and symlink telemetry showing webshell placement, suspicious scripts, hidden files, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, unexpected symlinks, permission changes, archive staging, root-owned file changes, or tenant-spanning file-system review.

·        DNS and mail telemetry showing zone changes, mail routing changes, mailbox activity, MX changes, SPF, DKIM, DMARC-related administration, webmail activity, spam activity, or domain-trust modification near suspicious hosting-control, FTP, webshell, or root-context behavior.

·        Outbound network, proxy, DNS, firewall, WAF, or abuse-report evidence showing payload retrieval, suspicious VPS communication, command-and-control-like behavior, redirector use, phishing hosting, malware hosting, spam activity, high-volume transfer, exfiltration-like traffic, or abuse infrastructure after suspicious hosting activity.

Supporting Detection Signals

Supporting signals increase confidence, establish access-to-impact continuity, and help distinguish approved hosting workflows from suspicious compromise activity. These signals should not normally be treated as standalone confirmation, but they are valuable when correlated with hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, outbound, or tenant-impact signals.

·        Vulnerable-version inventory, exposure management records, internet-facing service discovery, scanner telemetry, patch status, LiteSpeed plugin version status, and hosting-asset ownership records.

·        WAF, CDN, reverse-proxy, web server, and application telemetry showing suspicious request patterns, exploit attempts, abnormal paths, unusual methods, high-error bursts, request clustering, or access to hosted paths that later show file or process impact.

·        Customer support tickets, help desk records, abuse reports, defacement reports, spam reports, phishing reports, malware reports, customer complaints, or third-party notifications linked to affected domains or hosting servers.

·        Backup records, restore activity, archive creation, database access records, mailbox access records, or configuration-file access near suspicious hosting-control or root-context activity.

·        EDR, file-integrity monitoring, Linux audit, auditd, syslog, process accounting, or hosting-provider telemetry showing process, file, symlink, account, service, or permission activity on affected systems.

·        CloudLinux/CageFS tenant-mapping evidence showing tenant identity, expected isolation boundaries, path ownership, account ownership, and whether activity crossed expected tenant scope.

·        Reseller ownership, customer domain, FTP account, mailbox, database, DNS zone, backup, webroot, and hosted-application mappings that support blast-radius assessment.

·        SOC notes, incident-response records, remediation records, credential-rotation records, patch validation, plugin update validation, and containment-validation records.

Exploit Attempt and Instability Signals

Exploit attempt and instability signals are useful for identifying suspicious access attempts, failed exploitation, scan-driven exposure, plugin probing, or pre-compromise activity. These signals should be triaged carefully because hosting environments receive routine scanning, customer access, support activity, CMS traffic, FTP activity, and automated maintenance. They become more meaningful when they precede suspicious access, privilege escalation, file-system impact, outbound behavior, or tenant-impact evidence.

·        Repeated access attempts against cPanel, WHM, DNSOnly, WP Squared, reseller portals, administrative endpoints, or related hosting-control paths from unfamiliar or clustered source infrastructure.

·        Scanner traffic, request bursts, authentication failures, unusual HTTP methods, abnormal URI patterns, high-error activity, or repeated requests against administrative or plugin-adjacent paths.

·        FTP authentication failures, repeated FTP access from unusual source infrastructure, abnormal upload or download patterns, or FTP activity involving tenants that do not normally use FTP.

·        Web requests to unusual upload paths, hidden files, suspicious scripts, webshell-like paths, CMS plugin paths, or hosted directories that later show file changes or outbound activity.

·        Symlink creation or traversal attempts, permission errors, access-denied events, file-system warnings, or tenant-boundary anomalies near FTP, webshell, or plugin-adjacent activity.

·        Service errors, process crashes, web server errors, plugin errors, permission-denied bursts, or CloudLinux/CageFS-related anomalies near suspicious access or file activity.

·        Repeated suspicious activity clustered by common source IP, ASN, user agent, timig, request path, FTP account, tenant, reseller, domain, or hosting server.

·        Exploit-attempt telemetry followed by successful control-panel access, FTP access, webshell activity, root-context execution, hosted-content tampering, outbound communication, or abuse reports.

Outbound Communication Signals

Outbound communication signals are relevant because hosting compromise often becomes visible through payload retrieval, abuse infrastructure, redirector use, phishing elivery, malware hosting, spam operations, suspicious VPS communication, or exfiltration-like behavior. The most important outbound indicators are those that follow suspicious hosting-control access, FTP or webshell activity, symlink or permission abuse, root-context execution, hosted-file discovery, or hosted-content tampering.

·        DNS, proxy, firewall, WAF, EDR, and network telemetry showing payload retrieval, suspicious script downloads, tool staging, outbound HTTP or HTTPS activity, uncommon destinations, or suspicious VPS communication from affected hosting servers.

·        Outbound activity from web server, PHP, shell, plugin-adjacent, FTP-related, or root-context processes that does not match approved hosting, monitoring, backup, CDN, mail, or customer workflows.

·        Redirector behavior, phishing landing pages, malware delivery paths, credential-harvesting pages, SEO spam, spam infrastructure, or abuse reports linked to affected domains or customer webroots.

·        High-volume transfer, archive upload, unusual cloud-storage access, repeated outbound connections, exfiltration-like traffic, or rare destination activity following suspicious access or hosted-file discovery.

·        Mail telemetry showing spam activity, unusual outbound mail volume, new mail routing behavior, suspicious webmail activity, or domain-trust changes after suspicious hosting-control access

·        DNS telemetry showing suspicious domain resolution, newly observed destinations, dynamic DNS usage, suspicious hosting providers, rare geographies, or external infrastructure tied to payload staging or command-and-control-like behavior.

·        Abuse reports, blocklist entries, reputation hits, customer complaints, phishing takedown notices, malware-hosting reports, or spam complaints linked to affected hosting infrastructure.

·        Outbound activity continuing after patching, plugin update, credential rotation, webshell removal, hosted-content cleanup, or initial containment.

Persistence and Post-Exploitation Signals (Conditional)

Persistence and post-exploitation signals should be treated as conditional because hosting-control compromise or shared-hosting privilege escalation may not always produce durable persistence. These signals are valuable when they appear after suspicious access, foothold activity, privilege escalation, root-context execution, hosted-content tampering, or containment actions.

·        Webshell placement, hidden scripts, unauthorized backdoors, suspicious PHP files, cron entries, service modifications, startup changes, modified configuration files, or recurring file changes after cleanup.

·        New or modified hosting-control accounts, reseller accounts, FTP accounts, SSH keys, database users, mail accounts, webmail settings, API tokens, automation accounts, or backup credentials.

·        Root-owned file changes, permission changes, symlink persistence, unexpected writable paths, modified plugin files, altered CMS files, or file-integrity changes in customer webroots or plugin-adjacent paths.

·        DNS, mail, redirect, forwarding, webmail, package, or reseller changes that persist after patching, plugin update, account cleanup, or credential rotation.

·        Continued outbound communication, payload retrieval, spam activity, phishing hosting, malware hosting, redirector behavior, or abuse reports after initial remediation.

·        Recurrent FTP or web access from suspicious source infrastructure after password reset, credential rotation, or account cleanup.

·        Backup access, archive staging, database access, configuration access, or credential use after containment steps.

·        Customer reports or support tickets indicating recurring defacement, redirects, spam, webshell recurrence, malware alerts, or suspicious hosted-content changes.

Lateral Movement and Expansion Signals (Conditional)

Lateral movement and expansion signals should be treated as conditional because not every hosting-control or shared-hosting incident will expand beyond the initially affected system or tenant. These signals become high value when they follow suspicious access, privilege escalation, hosted-file discovery, credential exposure, outbound behavior, or tenant-impact activity.

·        Activity involving multiple customer webroots, reseller-managed sites, tenant directories, FTP accounts, domains, mailboxes, databases, DNS zones, backup paths, or hosting servers.

·        Access outside expected tenant scope, including file access across tenant directories, symlink traversal across tenant boundaries, root-context access to customer paths, or CloudLinux/CageFS boundary anomalies.

·        Use of exposed credentials, configuration files, API keys, database credentials, FTP credentials, SSH keys, mail credentials, backup credentials, or administrator accounts to access additional systems or services.

·        Cross-domain DNS or mail changes, reseller-account changes, package changes, or administrative actions affecting multiple customers or hosted domains.

·        Internal o customer-facing phishing, malware hosting, redirector deployment, spam activity, or abuse infrastructure that uses multiple affected domains or hosted paths.

·        Access to downstream SaaS, cloud resources, VPNs, customer applications, repositories, or business systems using credentials or secrets exposed through hosting compromise.

·        Repeated suspicious access across multiple hosting servers tied to common source infrastructure, account patterns, plugin paths, user agents, timing, outbound destinations, or abuse reports.

·        Data staging, archive movement, backup access, database access, or file transfer activity involving multiple tenants, customers, or hosted applications.

Signal Usage Constraints

Detection signals must be interpreted as part of a correlated hosting access-to-impact model. A single exposed service, vulnerable plugin, scanner hit, FTP event, web request, file write, symlink event, outbound connection, DNS change, mail event, or abuse report should not be treated as confirmed compromise without supporting context.

·        Treat exposed hosting-control services and vulnerable plugin deployments as prioritization signals, not confirmed compromise, unless they correlate with suspicious access, execution, file-system impact, outbound behavior, or tenant-impact evidence.

·        Treat successful hosting-control login or FTP use as insufficient proof of compromise unless source context, timing, account use, administrative behavior, file activity, or follow-on impact deviates from baseline.

·        Treat webshell evidence as high-risk, but still validate scope, account origin, file ownership, process lineage, outbound activity, and tenant impact.

·        Treat symlink or permission anomalies as higher confidence when they follow suspicious FTP, webshell, plugin-adjacent, or tenant-context activity.

·        Treat root-context execution as high-priority when it follows suspicious hosting-control access, FTP activity, webshell activity, symlink behavior, plugin-adjacent execution, or tenant-boundary anomalies.

·        Treat DNS, mail, hosted-content, outbound, and abuse-report ctivity as higher confidence when it follows suspicious access or privilege-escalation behavior.

·        Treat actor names, scanner names, exploit references, webshell names, source IPs, user agents, filenames, symlink paths, and public reporting labels as enrichment, not as the primary detection basis.

·        Treat absence of known exploit strings, malware telemetry, or public IOCs as expected for this behavior class and not as evidence that compromise did not occur.

·        Treat alerts as production-ready only after local hosting baselines, field mappings, source telemetry, account mappings, tenant mappings, reseller mappings, plugin mappings, support workflows, exception groups, and SOC triage criteria are validated.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry is required for high-confidence validation of privilege escalation, root-context execution, administrative tooling, service changes, account modification, plugin-adjacent execution, hosted-content tampering, and post-access behavior on affected hosting servers. This intrusion path may begin through exposed hosting-control services, FTP access, or webshell activity, but business impact is often confirmed through process, file, account, network, and tenant-impact evidence. Where full EDR coverage is unavailable, Linux audit sources, syslog, process accounting, file-integrity monitoring, hosting-provider telemetry, web server logs, FTP logs, and CloudLinux/CageFS tenant mapping should be used as compensating sources, with confidence reduced where process lineage cannot be reconstructed.

·        Process execution involving shells, scripting interpreters, administrative utilities, service-management tools, package-management tools, account-management commands, archive tools, database clients, mail utilities, DNS tools, backup tools, and network transfer utilities.

·        Process lineage involving web server processes, PHP, control-panel processes, FTP-related processes, plugin-adjacent processes, shell processes, cron processes, root-context processes, or execution from customer webroots, upload paths, temporary directories, or plugin paths.

·        Account creation or modification, password reset activity, reseller-account changes, FTP account changes, database user changes, mail account changes, SSH key changes, API token changes, automation-account changes, or administrative role changes.

·        Service changes, cron changes, startup changes, package changes, plugin changes, control-panel changes, DNS changes, mail changes, or changes to hosting-control services.

·        Endpoint network activity showing payload retrieval, suspicious VPS communication, outbound HTTP or HTTPS activity, DNS lookups, mail activity, cloud-storage access, or unusual external communication from hosting servers.

·        EDR, auditd, Linux audit, syslog, process accounting, file-integrity monitoring, or hosting-provider telemetry linking process activity to user, account, tenant, webroot, plugin path, effective user, and root-context behavior.

·        Host context needed to determine whether execution originated from approved support, patching, plugin update, backup, migration, customer maintenance, control-panel action, FTP activity, webshell activity, or suspicious escalation behavior.

Endpoint telemetry should preserve enough context to support hosting-led correlation. The minimum useful telemetry includes host name, server role, user, effective user, process name, command line, parent process, working directory, file path, timestamp, source account, tenant or reseller mapping, root-context indicator, network destination, and relationship to hosting-control, FTP, web, plugin, or file-system activity.

Memory and Execution Telemetry

Memory and execution telemetry is conditional for this report. Hosting-control compromise and shared-hosting privilege escalation do not require memory-resident malware, but this telemetry can increase confidence when webshells, in-memory tooling, credential access, process injection, suspicious interpreters, or unauthorized automation appear on affected hosting servers.

·        Suspicious web server, PHP, shell, interpreter, plugin-adjacent, or root-context process behavior near hosting-control access, FTP activity, webshell activity, symlink behavior, or hosted-content tampering.

·        Unauthorized tools, scripts, interpreters, or automation frameworks used to enumerate files, access databases, retrieve payloads, manipulate accounts, modify services, alter DNS or mail settings, or interact with external infrastructure.

·        Process behavior indicating credential access, configuration-file access, database access, backup access, token access, SSH key access, mail credential access, or API key exposure.

·        Runtime or behavioral detections associated with webshells, suspicious PHP execution, command execution through web-accessible paths, anomalous child processes, or root-context escalation.

·        Memory telemetry from high-risk hosting servers supporting shared hosting, reseller hosting, customer portals, ecommerce sites, managed DNS, mail services, databases, backups, or CloudLinux/CageFS tenant environments.

Memory telemetry should not be required for high-confidence detection unless local visibility depends on it. It should be used as a confidence enhancer when endpoint-based tooling, webshell execution, credential access, process manipulation, or unauthorized automation appears near suspicious hosting activity.

Crash and Fault Telemetry

Crash and fault telemetry is not a primary detection source for hosting-control compromise or shared-hosting privilege escalation, but it can identify failed exploitation, plugin instability, permission errors, service disruption, web server errors, process crashes, authentication loops, or file-system anomalies near suspicious activity. These signals are generally lower value than hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, and network telemetry.

·        Web server errors, control-panel errors, plugin errors, LiteSpeed plugin errors, permission-denied events, access-denied bursts, symlink errors, CloudLinux/CageFS boundary errors, or unexpected file-system warnings near suspicious access.

·        Process crashes, service restarts, web server instability, PHP errors, plugin faults, cron failures, or root-context execution errors near control-panel access, FTP activity, weshell activity, or hosted-content changes.

·        Authentication loops, repeated login failures, session errors, FTP errors, webmail errors, mail routing errors, DNS update failures, or administrative workflow failures near suspicious source context.

·        WAF, CDN, reverse-proxy, browser, support, or web telemetry showing blocked requests, interrupted exploitation, failed upload attempts, denied paths, blocked scripts, or abnormal request handling.

·        Customer support records showing broken websites, redirects, defacement, spam reports, malware alerts, phishing complaints, mail issues, DNS issues, or unexplained hosted-content changes.

Crash and fault telemetry should not be treated as proof of compromise by itself. It is most valuable when it aligns with suspicious hosting-control access, FTP or webshell activity, symlink or permission abuse, plugin-adjacent behavior, root-context execution, hosted-content tampering, outbound activity, or abuse reports.

File and Persistence Telemetry

File and persistence telemetry is required because hosting compromise and shared-hosting escalation often produce observable file-system, symlink, permission, webroot, plugin, credential, and persistence artifacts. This telemetry is especially important for determining whether activity remained isolated to one tenant or crossed shared-hosting boundaries.

·        Weshell files, suspicious PHP files, hidden files, altered scripts, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, modified CMS files, changed plugin files, and unexpected files in customer webroots.

·        Symlink creation or traversal, unexpected symlink targets, permission changes, root-owned file changes, writable-path changes, ownership changes, hidden directories, tenant-spanning access, or CloudLinux/CageFS boundary anomalies.

·        Configuration-file access, database credential exposure, API key exposure, FTP credential exposure, mail credential exposure, SSH key access, backup credential access, application secret exposure, or account-token exposure.

·        Archive creation, backup access, database export, mailbox access, staging directories, compressed files, temporary files, or unusual data aggregation near suspicious hosting-control, FTP, webshell, or root-context activity.

·        Persistence-like changes including cron entries, service changes, startup scripts, modified control-panel files, modified plugin files, recurring webshell placement, altered CMS files, account changes, SSH key additions, or recurring unauthorized file writes.

·        File activity involving unusual storage locations, upload paths, temporary directories, plugin paths, media directories, backup paths, mail directories, webroots, or directories outside expected tenant scope.

File telemetry should include file path, file name, extension, size, hash where available, owner, group, permissions, symlink target where available, creating process, modifying process, user, effective user, host, timestamp, tenant, reseller, domain, webroot, and relationship to hosting-control, FTP, web, plugin, or process activity.

Network and Outbound Communication Telemetry

Network and outbound communication telemetry is required to understand payload retrieval, command-and-control-like behavior, redirector use, phishing hosting, malware delivery, spam activity, cloud-storage access, data movement, and abuse-infrastructure exposure. The most important network signals are those that follow suspicious hosting-control access, FTP or webshell activity, symlink or permission abuse, root-context execution, hosted-file discovery, or hosted-content tampering.

·        DNS, proxy, secure web gateway, firewall, WAF, EDR, and network telemetry for outbound HTTP or HTTPS activity, payload retrieval, suspicious script downloads, uncommon destinations, suspicious VPS communication, dynamic DNS, rare geographies, and cloud-storage access.

·        Source host, process, user, effective user, destination domain, URL path where available, destination IP, ASN, geography, action, byte count, session duration, timestamp, and relationship to hosting server, tenant, domain, webroot, or process lineage.

·        Outbound activity from web server, PHP, shell, plugin-adjacent, FTP-related, cron, or root-context processes that does not match approved hosting, monitoring, backup, CDN, mail, or customer workflows.

·        Redirector behavior, phishing landing pages, malware delivery paths, credential-harvesting pages, SEO spam, spam infrastructure, or abuse reports linked to affected domains, customer webroots, or hosting servers.

·        Mail telemetry showing outbound spam, unusual mail volume, new mail routing behavior, webmail abuse, suspicious authentication, or domain-trust changes near suspicious hosting-control or root-context activity.

·        High-volume transfer, archive upload, unusual cloud-storage access, repeated outbound connections, exfiltration-like traffic, rare destination activity, or suspicious external communication following suspicious access or hosted-file discovery.

·        Network and abuse-report telemetry showing outbound activity continuing after patching, plugin update, credential rotation, webshell removal, hosted-content cleanup, or initial containment.

Network telemetry should be correlated with hosting-control, endpoint, file, symlink, DNS, mail, FTP, web, and tenant-mapping logs. Unusual outbound activity is higher confidence when it follows suspicious access, privilege escalation, hosted-file discovery, hosted-content tampering, or tenant-impact evidence.

Web and Application Telemetry (Conditional Availability)

Web and application telemetry is critical where available because the compromise path occurs through hosting-control services, web-facing applications, FTP-enabled workflows, plugin behavior, and shared-hosting infrastructure. Availability varies by hosting platform, logging configuration, retention settings, EDR deployment, WAF/CDN coverage, and provider maturity.

·        cPanel, WHM, DNSOnly, WP Squared, reseller portal, hosting-control, and administrative logs showing authentication, session behavior, account activity, administrative actions, package changes, DNS changes, mail changes, webroot changes, database access, backup access, and user context.

·        LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin telemetry, plugin logs where available, plugin-adjacent file paths, plugin execution context, update status, symlink-sensitive paths, and relationship to hosting-control or tenant activity.

·        FTP service logs showing account, source IP, authentication result, file operation, path, byte count, timestamp, tenant, reseller, domain, and relationship to hosted-content changes.

·        Web server logs showing host, source IP, URI, method, status code, user agent, request size, response size, timestamp, customer domain, webroot, and relationship to suspicious hosted paths or file changes.

·        WAF, CDN, reverse-proxy, and application logs showing suspicious request patterns, blocked exploitation, abnormal upload attempts, webshell access attempts, hidden-path access, CMS plugin access, redirect behavior, and customer-facing abuse.

·        DNS and mail application logs showing zone changes, MX changes, SPF, DKIM, DMARC-related administration, mailbox activity, mail routing, webmail access, spam activity, and administrative context.

·        CloudLinux/CageFS telemetry or administrative records showing tenant identity, expected isolation boundaries, path ownership, account ownership, and whether activity crossed expected tenant scope.

·        Customer support, abuse desk, SOC, incident-response, backup, and remediation records that add customer-impact, abuse-report, containment, restoration, and assurance context.

Where hosting application telemetry is limited, endpoint logs, web server logs, FTP logs, WAF/CDN logs, proxy logs, DNS logs, firewall logs, abuse reports, backup records, customer tickets, and CloudLinux/CageFS mapping should be used as compensating sources. The absence of complete hosting application telemetry should be recorded as a visibility limitation and should reduce confidence in tenant-impact scoping.

Telemetry Availability Requirements

Minimum viable detection requires enough telemetry to correlate suspicious hosting-control access, FTP or webshell activity, symlink or permission abuse, endpoint execution, file-system changes, outbound communication, or tenant-impact evidence. A detection program should not rely on a single telemetry source for high-confidence hosting compromise findings.

·        Hosting-control telemetry covering authentication, session behavior, administrative actions, account changes, package changes, DNS changes, mail changes, database access, backup access, and timestamped user context.

·        FTP telemetry covering authentication, source IP, account, path, operation, byte count, timestamp, tenant, reseller, and hosted domain.

·        Web access telemetry covering source IP, host, URI, method, status code, user agent, request size, response size, timestamp, customer domain, and webroot relationship.

·        Endpoint process telemetry covering process name, command line, parent process, effective user, working directory, network connections, root-context indicator, and relationship to hosting-control, FTP, web, plugin, or file-system activity.

·        File and symlink telemetry covering file path, file name, owner, permissions, symlink target where available, creating process, modifying process, timestamp, tenant, reseller, domain, webroot, and plugin relationship.

·        DNS and mail telemetry covering zone changes, mail routing, mailbox activity, webmail access, MX changes, SPF, DKIM, DMARC-related administration, outbound spam, and administrative context.

·        Network telemetry covering DNS, proxy, firewall, WAF, EDR, destination domain, destination IP, ASN, geography, byte count, session duration, process context where available, and relationship to affected hosting servers.

·        CloudLinux/CageFS tenant mapping, reseller ownership mapping, customer-domain mapping, FTP-account mapping, webroot mapping, database mapping, mailbox mapping, backup mapping, and exception mappings.

·        Abuse reports, customer support records, backup records, remediation records, patch validation, plugin update validation, credential-rotation records, and incident-response timelines.

·        Time synchronization and retention across hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, network, CloudLinux/CageFS, support, backup, and incident-response telemetry sources.

High-confidence detection requires at least one suspicious access, foothold, or escalation signal and one downstream impact or control signal. Downstream signals may include privileged execution, administrative change, hosted-content tampering, file or symlink impact, credential access, DNS or mail manipulation, outbound abuse, tenant-impact evidence, or containment failure.

Telemetry Limitations and Gaps

Telemetry limitations should be explicitly documented because hosting visibility varies by platform, provider, logging configuration, retention period, EDR coverage, WAF/CDN integration, tenant mapping, and operational maturity. These gaps can materially affect confidence, triage speed, tenant-impact scoping, customer assurance, and containment validation.

·        Hosting-control logs may not retain enough history to reconstruct unauthorized access, administrative actions, session behavior, or reseller activity.

·        FTP logs may be incomplete, rotated quickly, unavailable for some accounts, or insufficiently linked to tenant identity and hosted-content changes.

·        Web access logs may not preserve enough request body, authenticated user, source process, customer context, or file-system relationship to confirm webshell activity or hosted-content tampering.

·        Endpoint telemetry may be absent, limited, or inconsistently deployed on hosting servers, reducing visibility into shell execution, root-context behavior, process lineage, and account changes.

·        File and symlink telemetry may not preserve owner, permission, symlink target, creating process, modifying process, or tenant mapping needed to distinguish customer maintenance from boundary abuse.

·        CloudLinux/CageFS logs or administrative records may not provide enough detail to prove whether activity crossed tenant boundaries.

·        DNS and mail logs may show changes or abuse but may not preserve the initiating account, source context, or relationship to suspicious hosting-control access.

·        Proxy, DNS, WAF, firewall, and abuse-report telemetry may show outbound activity but may not preserve process, tenant, user, or file context.

·        Customer support, abuse desk, and help desk data may be inconsistently structured, timestamped, or linked to affected tenants, domains, or hosting servers.

·        Backup and restore records may not prove whether hosted content, databases, mailboxes, or configuration files were accessed or altered before remediation.

·        Approved hosting workflows, support access, reseller administration, FTP workflows, plugin updates, CMS updates, backup jobs, migrations, and customer maintenance may be poorly documented, increasing false-positive risk.

·        Short retention windows may prevent reconstruction once suspicious access, abuse reports, or customer impact is discovered days or weeks after initial exposure.

·        Lack of actor-specific indicators should not prevent behavior-led detection, but it should limit campaign attribution.

Where telemetry gaps exist, detections should remain in hunt or investigation mode until compensating data sources, account and tenant baselines, exception mappings, and containment-validation evidence support higher-confidence alerting.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

Hosting control-plane compromise and shared-hosting privilege escalation create strong detection opportunities when defenders can correlate suspicious hosting-control access, FTP or webshell foothold activity, LiteSpeed plugin or shared-hosting boundary behavior, symlink or permission abuse, root-context execution, hosted-content tampering, DNS or mail manipulation, outbound abuse, and tenant-impact evidence. The highest-value opportunities are not single indicators. They are behavior chains that show plausible movement from exposed hosting administration or lower-privileged tenant foothold activity into privileged server-side activity, customer-site impact, abuse infrastructure, or shared-hosting boundary failure.

·        Correlate exposed cPanel, WHM, DNSOnly, WP Squared, reseller portal, or related hosting-control access with abnormal source IPs, rare ASNs, unusual geographies, unexpected user agents, abnormal session behavior, unexpected administrative actions, or access outside approved support, patching, migration, or customer-maintenance workflows.

·        Correlate suspicious hosting-control access with account creation or modification, password reset activity, reseller-account changes, package changes, DNS changes, mail changes, database access, backup access, webroot changes, or administrative setting changes.

·        Correlate FTP activity, web access, or webshell activity with abnormal source context, unusual timing, unexpected file writes, suspicious scripts, hidden files, customer upload paths, CMS-accessible paths, hosted paths accessible through webshells, or tenant directories outside expected workflows.

·        Correlate LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity with symlink creation or traversal, permission anomalies, plugin-adjacent execution, CloudLinux/CageFS boundary anomalies, root-owned file changes, tenant-spanning access, or unexpected privileged execution.

·        Correlate file and symlink telemetry with webshell placement, suspicious PHP files, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, archive staging, configuration-file access, credential exposure, database access, backup access, or tenant-spanning file-system review.

·        Correlate endpoint process telemetry with shell execution, administrative tooling, service changes, account modification, root-context process activity, plugin-adjacent process lineage, cron changes, or execution from directories associated with hosted content, FTP activity, webshell activity, or plugin behavior.

·        Correlate DNS and mail changes with suspicious hosting-control access, FTP or webshell activity, root-context execution, hosted-content tampering, spam reports, phishing reports, malware reports, abuse reports, or customer-impact evidence.

·        Correlate outbound network activity with payload retrieval, suspicious VPS communication, command-and-control-like behavior, redirector use, phishing hosting, malware hosting, spam activity, high-volume transfer, rare destination activity, or exfiltration-like patterns after suspicious hosting activity.

·        Correlate repeated suspicious activity across multiple tenants, reseller accounts, customer webroots, FTP accounts, domains, mailboxes, databases, DNS zones, backup paths, or hosting servers.

·        Correlate customer support tickets, abuse desk records, defacement reports, phishing reports, spam reports, malware reports, blocklist entries, backup records, remediation records, and incident-response notes with hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, and network telemetry.

These opportunities are strongest when organizations maintain accurate mappings for affected hosting-control assets, LiteSpeed plugin deployments, FTP accounts, tenants, resellers, domains, customer webroots, DNS zones, mailboxes, databases, backups, support workflows, approved maintenance windows, CloudLinux/CageFS boundaries, exception groups, and business-critical hosted applications. Detection value drops when access-log retention is short, FTP activity is not baselined, file and symlink visibility is incomplete, endpoint process telemetry is missing, tenant ownership is unclear, CloudLinux/CageFS mapping is incomplete, or post-remediation validation is not performed.

High-Confidence Detection Conditions

High-confidence detection should require access-to-impact continuity. A single exposed service, vulnerable plugin version, scanner hit, failed request, successful login, FTP session, web request, file write, symlink event, outbound connection, DNS change, mail event, or abuse report should not be treated as confirmed compromise without supporting evidence. High-confidence conditions should combine suspicious access, foothold activity, escalation behavior, file-system impact, outbound behavior, tenant-impact evidence, or containment failure within a bounded window.

·        Suspicious cPanel, WHM, DNSOnly, WP Squared, reseller portal, or related hosting-control access followed by unexpected administrative actions, account changes, DNS changes, mail changes, backup access, database access, or hosted-content modification.

·        FTP or webshell activity from abnormal source context followed by unexpected file writes, suspicious scripts, hidden files, symlink creation or traversal, permission changes, plugin-adjacent execution, hosted-content tampering, or outbound communication.

·        LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity followed by symlink or permission anomalies, CloudLinux/CageFS boundary anomalies, root-owned file changes, tenant-spanning access, or root-context execution.

·        Suspicious hosting-control access or tenant foothold activity followed by Unix shell execution, administrative tooling, service changes, cron changes, account creation, password changes, reseller changes, or root-context process activity.

·        Hosted-content modification involving webshell placement, phishing pages, malware delivery content, unauthorized redirects, SEO spam, credential-harvesting pages, suspicious scripts, hidden files, or customer-facing defacement after suspicious access or escalation behavior.

·        DNS or mail manipulation following suspicious hosting-control access, root-context execution, reseller-account changes, hosted-content tampering, webmail activity, spam activity, phishing reports, malware reports, or customer-impact evidence.

·        Suspicious outbound communication following hosting-control access, FTP or webshell activity, symlink or permission abuse, root-context execution, hosted-file discovery, archive staging, or hosted-content tampering.

·        Activity crossing expected tenant, reseller, domain, webroot, database, mailbox, DNS zone, backup, or CloudLinux/CageFS boundaries after suspicious access or escalation behavior.

·        Continued suspicious access, file changes, outbound communication, webshell recurrence, DNS or mail manipulation, or abuse reports after patching, plugin update, credential rotation, hosted-content cleanup, or initial containment.

High-confidence alerts should remain behavior-led and should not depend on actor names, scanner names, exploit strings, webshell names, exact filenames, symlink paths, user agents, source IPs, domains, payload names, or static IOC matches. CVE-specific or campaign-specific intelligence may raise urgency, but it should not replace local access-to-impact evidence.

Moderate-Confidence Detection Conditions

Moderate-confidence detections identify suspicious activity that may represent hosting-control exploitation, shared-hosting escalation, FTP foothold abuse, webshell activity, tenant-boundary probing, customer-site compromise, or abuse-infrastructure preparation but lacks full attack-chain continuity. These conditions are useful for hunt workflows, investigation queues, exposure review, and prioritized triage.

·        Exposed cPanel, WHM, DNSOnly, WP Squared, reseller portals, administrative endpoints, or related hosting-control services with scanner activity, suspicious request patterns, failed authentication, unusual source infrastructure, or vulnerable-version evidence but no confirmed downstream impact.

·        LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin vulnerable-version findings or plugin exposure in CloudLinux/CageFS shared-hosting environments without confirmed symlink abuse, privilege escalation, or tenant-impact evidence.

·        Successful hosting-control login, FTP activity, or web access from unfamiliar source context without confirmed administrative change, file-system impact, outbound behavior, or tenant impact.

·        Webshell-like access, suspicious scripts, hidden files, abnormal upload paths, CMS-accessible path activity, or unusual customer webroot changes without confirmed process execution or outbound communication.

·        Symlink creation, permission changes, file ownership anomalies, or CloudLinux/CageFS boundary warnings near suspicious FTP, web access, or plugin-adjacent activity without confirmed root-context execution.

·        Endpoint process anomalies involving web server, PHP, shell, FTP-related, plugin-adjacent, or root-context processes without confirmed hosted-content tampering or tenant-boundary failure.

·        DNS or mail changes that deviate from baseline but are not yet linked to suspicious access, root-context execution, customer-site tampering, spam, phishing, malware hosting, or abuse reports.

·        Outbound communication from affected hosting servers to uncommon destinations without confirmed payload retrieval, abuse infrastructure, hosted-content tampering, or data movement.

·        Customer ticket, abuse report, blocklist entry, phishing report, spam report, malware report, or defacement report linked to a hosted domain but not yet correlated to hosting-control, FTP, web, file, process, or network evidence.

Moderate-confidence detections should remain in hunt or investigation mode until additional evidence establishes access-to-impact continuity. They should help analysts determine whether activity is exposure only, approved hosting activity, suspicious access, probable compromise, shared-hosting escalation, customer-site impact, abuse-infrastructure use, tenant-boundary failure, or containment failure.

Low-Confidence Detection Conditions

Low-confidence detections are useful for environmental awareness, exposure management, and retrospective review, but they should not generate high-severity compromise alerts without supporting signals. These conditions are common in hosting environments and can produce false-positive volume if not correlated.

·        A single exposed hosting-control service without suspicious access or follow-on behavior.

·        Single vulnerable LiteSpeed plugin version findings without FTP foothold, webshell, symlink, permission, root-context, or tenant-impact evidence.

·        Single scanner hits, failed requests, suspicious URI patterns, or proof-of-concept-like requests without successful access or downstream impact.

·        Single successful hosting-control logins from known administrators, support staff, customers, or reseller accounts without abnormal context or follow-on activity.

·        Single FTP sessions, file uploads, web requests, CMS updates, plugin updates, or customer maintenance actions without suspicious process, file, symlink, outbound, or tenant-impact behavior.

·        Single symlink events, permission changes, file writes, DNS changes, mail changes, or outbound connections without suspicious access or escalation context.

·        Routine support access, reseller administration, customer FTP workflows, CMS maintenance, plugin updates, backups, migrations, certificate renewal, DNS administration, mail administration, tenant provisioning, or CloudLinux/CageFS operations.

·        Actor-name, scanner-name, exploit-reference, webshell name, infrastructure, or public-report matching without local telemetry supporting compromise behavior.

Low-confidence signals should be retained for enrichment, baselining, and historical review. They become operationally useful when correlated with hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, network, tenant-impact, abuse-report, or containment evidence.

Detection Gaps

Detection gaps are most likely where hosting-control logs are incomplete, access-log retention is short, FTP activity is not preserved, web access logs lack useful context, endpoint process telemetry is absent, file and symlink telemetry is limited, CloudLinux/CageFS tenant mapping is incomplete, DNS or mail administrative logs are weak, outbound telemetry lacks process context, or support and abuse records are not linked to affected assets. These gaps reduce confidence and can delay identification of privilege escalation, customer-site compromise, tenant-boundary failure, and post-remediation activity.

·        Lack of complete hosting-control telemetry for authentication, session behavior, administrative actions, account changes, reseller changes, DNS changes, mail changes, database access, backup access, and webroot changes.

·        Limited FTP telemetry for account, source IP, authentication result, file operation, path, byte count, timestamp, tenant, reseller, and hosted domain.

·        Web access logs that do not preserve enough URI, method, status, user agent, authenticated context, request body where available, customer domain, hosted path, or file-system relationship to confirm webshell activity or hosted-content tampering.

·        Missing endpoint process telemetry, Linux audit sources, syslog, process accounting, or EDR coverage needed to reconstruct shell execution, root-context behavior, process lineage, service changes, and account modification.

·        Limited file and symlink telemetry for file path, owner, permissions, symlink target, creating process, modifying process, tenant mapping, reseller mapping, or plugin relationship.

·        Incomplete CloudLinux/CageFS telemetry or administrative records needed to determine whether activity crossed expected tenant boundaries.

·        DNS and mail telemetry that shows changes or abuse but does not preserve initiating account, source context, administrative path, or relationship to suspicious hosting-control access.

·        Proxy, DNS, WAF, firewall, and abuse-report telemetry that shows outbound activity but does not preserve process, tenant, user, domain, file, or webroot context.

·        Weak mappings for hosting assets, LiteSpeed plugin deployments, FTP accounts, reseller accounts, customer domains, mailboxes, databases, DNS zones, backup paths, webroots, tenant ownership, and exception groups.

·        Inconsistent patch validation, plugin update validation, credential rotation, webshell removal, hosted-content cleanup, DNS and mail review, abuse-response tracking, and containment-validation records.

·        Lack of time synchronization across hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, network, CloudLinux/CageFS, backup, support, abuse, and incident-response telemetry sources.

·        Short retention windows that do not cover the period between exposure, suspected access, tenant foothold activity, privilege escalation, customer impact, abuse reporting, containment, and post-remediation validation.

·        Lack of actor-specific indicators, which should limit attribution claims but should not prevent behavior-led detection.

Where these gaps exist, detections should be treated as investigation-ready but not fully production-confirmatory. Compensating telemetry should be documented, and alert confidence should reflect the visibility available in the local environment.

False-Positive Drivers

False positives are likely because hosting environments support legitimate administrative access, reseller workflows, FTP uploads, CMS maintenance, plugin updates, backups, migrations, certificate renewal, DNS changes, mail administration, customer-requested changes, tenant provisioning, CloudLinux/CageFS activity, support operations, and abuse-response work. Detection logic must account for approved business operations before alert promotion.

·        Hosting-provider support access, emergency maintenance, patching, plugin updates, migrations, backups, restores, and incident-response actions.

·        Reseller administration, customer account management, package changes, DNS updates, mail changes, webroot changes, database work, and customer-support workflows.

·        Customer FTP uploads, CMS updates, plugin updates, theme changes, media uploads, file cleanup, website redesigns, developer activity, and normal webroot maintenance.

·        Certificate renewal, CDN changes, WAF changes, redirect configuration, caching changes, domain migration, mail routing changes, and DNS administration.

·        Backup jobs, database exports, archive creation, restore workflows, file synchronization, storage migration, monitoring checks, and vulnerability scanning.

·        CloudLinux/CageFS tenant provisioning, isolation changes, package changes, resource-limit adjustments, tenant moves, and administrative troubleshooting.

·        Legitimate web server, PHP, shell, cron, package-management, service-management, backup, mail, DNS, and control-panel processes used by administrators or support teams.

·        Abuse-response activity, phishing takedown, malware cleanup, spam remediation, webshell removal, redirect cleanup, blacklist handling, and customer assurance work.

·        Automated vulnerability scanners, uptime monitoring, search engine crawlers, WAF probes, CDN probes, managed security testing, customer security scans, and third-party monitoring.

False-positive control should rely on approved hosting workflows, account allowlists, support-window rules, reseller ownership, tenant mappings, maintenance calendars, backup schedules, plugin-maintenance records, customer-change records, DNS and mail change-control records, CloudLinux/CageFS mappings, known administrative sources, and documented exception groups.

Detection Engineering Opportunities

Detection engineering should prioritize behavior chains that remain useful across CVE changes, exploit artifacts, scanner changes, webshell names, plugin versions, symlink paths, payload changes, source infrastructure changes, and future hosting-control or shared-hosting escalation patterns. The best opportunities combine hosting-control access, FTP activity, web access, endpoint process telemetry, file and symlink telemetry, DNS and mail changes, outbound network behavior, tenant mapping, abuse-report evidence, and containment validation into staged detections that begin in hunt mode and later promote to alert mode after validation.

·        Build suspicious hosting-control access detections that identify cPanel, WHM, DNSOnly, WP Squared, reseller portal, or related administrative access from abnormal source context, unusual session behavior, or unexpected administrative workflows.

·        Build hosting-control-to-impact detections that correlate suspicious control-panel access with account changes, reseller changes, DNS changes, mail changes, database access, backup access, webroot modification, or hosted-content tampering.

·        Build FTP or webshell foothold detections that correlate abnormal FTP, web access, hosted-path activity, or webshell evidence with unexpected file writes, suspicious scripts, hidden files, symlink behavior, permission changes, or outbound activity.

·        Build LiteSpeed plugin and shared-hosting escalation detections that correlate plugin-adjacent activity, symlink or permission anomalies, CloudLinux/CageFS boundary anomalies, root-owned file changes, tenant-spanning access, and root-context execution.

·        Build process-lineage detections that correlate web server, PHP, FTP-related, plugin-adjacent, shell, cron, or root-context processes with hosted-content paths, control-panel activity, suspicious file changes, or outbound communication.

·        Build hosted-content impact detections that identify webshell placement, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, suspicious scripts, hidden files, or defacement after suspicious access.

·        Build DNS and mail manipulation detections that correlate suspicious hosting activity with DNS zone changes, mail routing changes, webmail abuse, spam activity, MX changes, SPF, DKIM, DMARC-related administration, or domain-trust changes.

·        Build outbound abuse detections that correlate suspicious hosting activity with payload retrieval, suspicious VPS communication, redirector use, phishing hosting, malware hosting, spam activity, high-volume transfer, rare destinations, or exfiltration-like behavior.

·        Build tenant-impact detections that correlate suspicious activity across customer webroots, reseller-managed sites, tenant directories, FTP accounts, domains, mailboxes, databases, DNS zones, backups, or CloudLinux/CageFS boundaries.

·        Build containment-validation detections that identify continued suspicious access, recurring webshells, file changes, outbound communication, DNS or mail manipulation, abuse reports, or tenant-impact evidence after patching, plugin update, credential rotation, hosted-content cleanup, or initial containment.

These opportunities should be implemented with local field mappings, tenant-specific baselines, approved hosting workflows, account allowlists, support-window rules, reseller ownership, CloudLinux/CageFS mappings, plugin-maintenance expectations, customer-change records, exception groups, and SOC triage criteria. Alert mode should follow hunt validation, not precede it.

Residual Detection Risk

Residual detection risk remains even with strong telemetry because attackers may use legitimate hosting-control services, valid hosting accounts, FTP workflows, web-accessible paths, expected CMS structures, plugin-adjacent paths, normal-looking file names, and trusted customer infrastructure. They may avoid known exploit strings, rotate infrastructure, use different webshell names, alter symlink paths, hide behind customer maintenance patterns, and continue activity until access, files, credentials, DNS, mail, and outbound infrastructure are fully remediated.

·        Valid hosting-control or FTP activity may obscure the difference between approved user behavior and attacker-controlled access.

·        Routine customer maintenance, support access, CMS updates, plugin updates, backups, migrations, DNS changes, mail changes, and reseller administration may resemble attacker activity without strong baselines.

·        Plugin presence, vulnerable version status, scanner traffic, or failed requests may create urgency but may not prove compromise.

·        Webshell placement, hidden files, redirects, phishing pages, malware delivery content, SEO spam, or suspicious scripts may be removed before full evidence is preserved.

·        Symlink, permission, root-context, and CloudLinux/CageFS boundary evidence may be difficult to reconstruct without file, process, and tenant-mapping telemetry.

·        Outbound network telemetry may show suspicious communication without enough process, tenant, domain, or file context to prove scope.

·        Abuse reports may identify customer-facing impact before local telemetry can establish initial access or blast radius.

·        Short retention windows may prevent reconstruction of initial access, tenant foothold activity, escalation, hosted-file discovery, or post-remediation recurrence.

·        Incomplete tenant, reseller, domain, mailbox, database, DNS, backup, and webroot mappings may force broader customer-impact assumptions.

·        Actor-specific indicators may be absent, misleading, or stale, requiring behavior-led detection rather than campaign-led confirmation.

Residual risk should be communicated as a visibility and confidence issue, not as proof of non-compromise. Where gaps remain, organizations should prioritize access-log preservation, plugin update validation, historical compromise review, file and symlink telemetry, endpoint process visibility, CloudLinux/CageFS tenant mapping, DNS and mail review, outbound monitoring, credential rotation, customer-impact scoping, and containment validation before relying on alerting alone.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics is viable for this report as a supporting detection and correlation layer because hosting control-plane compromise and shared-hosting privilege escalation can produce observable access-path, DNS, proxy, WAF, CDN, FTP, outbound communication, abuse-report, and network-behavior patterns even when host telemetry is incomplete. NDR should not attempt to prove CVE-2026-41940 exploitation, CVE-2026-54420 exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS tenant-boundary failure, root-context execution, or file ownership change from a single login connection, DNS lookup, proxy event, FTP session, web request, or outbound connection. The highest-value NDR coverage comes from correlating unfamiliar hosting-control access, suspicious FTP or webshell access paths, rare source infrastructure, plugin-adjacent access, abnormal hosted-path access, outbound payload retrieval, redirector behavior, phishing or malware hosting, spam-related traffic, abuse reports, and post-remediation recurrence.

NDR coverage is strongest when enriched with proxy, DNS, WAF, CDN, firewall, FTP, web access, EDR, control-panel, mail, DNS-administration, abuse-report, customer-support, tenant-mapping, and SIEM asset context. Pure network telemetry is not sufficient to independently confirm authentication-bypass exploitation, symlink abuse, root-context execution, credential access, or tenant-spanning file-system impact. Network Behavioral Analytics should therefore be used to identify suspicious access paths, rare source context, hosting-asset clustering, outbound abuse behavior, and containment-failure indicators that require host, file, control-panel, FTP, web, DNS, mail, and CloudLinux/CageFS correlation.

One NDR / Network Behavioral Analytics rule is included for this report.

Rule

Hosting Control-Plane or Shared-Hosting Access Followed by Suspicious Outbound Abuse Behavior

Rule Format

NDR / Network Behavioral Analytics hosting-access-to-outbound-abuse correlation pattern.

Detection Purpose

Detect suspicious hosting-control, FTP, web-accessible hosted-path, or plugin-adjacent access followed by outbound behavior consistent with payload retrieval, command-and-control-like communication, redirector use, phishing hosting, malware hosting, spam-related traffic, rare destination access, archive transfer, or exfiltration-like movement from the same hosting asset, hosted workload, tenant-mapped asset, reseller-mapped asset, domain, or webroot.

Detection Logic

Trigger when suspicious access to hosting-control, shared-hosting, FTP, web-accessible hosted, or LiteSpeed plugin-adjacent services is followed by suspicious outbound or abuse-side behavior from the same hosting asset, tenant, reseller, domain, webroot, public IP, private IP, or workload identity within a bounded investigation window.

Require both conditions within a bounded investigation window:

·        Hosting-control, FTP, web, hosted-path, or plugin-adjacent access is observed from unfamiliar source context, including rare source IP, unusual geography, rare ASN, hosting provider, anonymization infrastructure, suspicious VPS infrastructure, unfamiliar user agent, unexpected access path, abnormal timing, or source context outside approved administrator, support, customer, scanner, monitoring, vulnerability-management, and maintenance baselines.

·        The same hosting server, shared-hosting system, hosted workload, tenant-mapped asset, reseller-mapped asset, hosted domain, webroot, public IP, private IP, or workload identity is followed by outbound behavior that deviates from normal hosting operations, including newly observed destination, rare ASN, dynamic DNS, suspicious VPS communication, repeated beacon-like HTTP or HTTPS traffic, payload retrieval, archive upload, high-volume transfer, phishing hosting, malware hosting, redirector behavior, spam-related traffic, or exfiltration-like movement.

Increase priority when enriched host, EDR, web, FTP, file, or SIEM telemetry shows outbound activity associated with web server, PHP, FTP-related, plugin-adjacent, cron, shell, interpreter, or root-context process behavior near the suspicious access.

Increase priority when the same asset also shows webshell evidence, hosted-content modification, symlink or permission anomalies, root-owned file changes, DNS or mail manipulation, abuse reports, customer tickets, phishing reports, malware reports, spam reports, blocklist entries, or post-remediation recurrence.

Do not treat exposed hosting-control services, vulnerable LiteSpeed plugin versions, scanner traffic, proof-of-concept-like requests, failed requests, single FTP sessions, single web requests, single outbound connections, or isolated abuse reports as confirmed compromise. Require access-to-impact correlation and local telemetry enrichment before escalating as probable hosting-control compromise, shared-hosting escalation, tenant-boundary failure, or customer-impacting abuse.

Required Telemetry

·        DNS, proxy, secure web gateway, firewall, WAF, CDN, reverse-proxy, load balancer, NDR, EDR, FTP, web access, control-panel, DNS-administration, mail, abuse-report, customer-support, incident-response, and SIEM-enriched asset telemetry where available.

·        Source IP, source ASN, source geography, source category, destination IP, destination domain, destination service, URL path where available, HTTP method where available, user agent where available, protocol, action, byte count, session duration, timestamp, direction, and destination reputation.

·        Hosting service categorization for cPanel, WHM, DNSOnly, WP Squared, reseller portals, FTP services, web servers, web-accessible hosted paths, CMS upload paths, hidden paths, LiteSpeed plugin-adjacent paths, DNS services, mail services, backup services, and customer-facing hosted infrastructure.

·        Asset, tenant, reseller, domain, webroot, FTP account, control-panel account, mail service, DNS zone, database, backup, cloud workload, public IP, private IP, NAT, CDN, load-balancer, and exception-group mappings.

·        Baselines for approved administrator access, hosting-provider support, reseller workflows, customer FTP workflows, CMS updates, plugin updates, backups, migrations, package repositories, CDN activity, mail flows, uptime monitoring, vulnerability scanning, managed security testing, and expected outbound destinations.

·        Time synchronization across NDR, DNS, proxy, firewall, WAF, CDN, EDR, FTP, web, control-panel, DNS-administration, mail, abuse-report, customer-support, backup, CloudLinux/CageFS, and SIEM telemetry sources.

Engineering Implementation Instructions

Create or validate authoritative reference sets for ENV_HOSTING_CONTROL_ASSETS, ENV_SHARED_HOSTING_ASSETS, ENV_RESELLER_HOSTING_ASSETS, ENV_FTP_SERVICES, ENV_WEB_SERVER_ASSETS, ENV_DNS_SERVICE_ASSETS, ENV_MAIL_SERVICE_ASSETS, ENV_CUSTOMER_FACING_HOSTING_ASSETS, ENV_CPANEL_ASSETS, ENV_WHM_ASSETS, ENV_DNSONLY_ASSETS, ENV_WP_SQUARED_ASSETS, ENV_LITESPEED_CPANEL_PLUGIN_ASSETS, ENV_LITESPEED_WHM_PLUGIN_ASSETS, ENV_CLOUDLINUX_CAGEFS_ASSETS, ENV_HOSTED_DOMAINS, ENV_CUSTOMER_WEBROOTS, ENV_TENANT_MAPPINGS, ENV_RESELLER_MAPPINGS, ENV_APPROVED_ADMIN_SOURCES, ENV_APPROVED_SUPPORT_SOURCES, ENV_APPROVED_SCANNERS, ENV_APPROVED_MONITORING_SOURCES, ENV_APPROVED_BACKUP_DESTINATIONS, ENV_APPROVED_CDN_PROVIDERS, ENV_APPROVED_MAIL_RELAYS, ENV_APPROVED_PACKAGE_REPOSITORIES, ENV_APPROVED_CUSTOMER_MAINTENANCE_WINDOWS, and ENV_HIGH_VALUE_HOSTED_APPLICATIONS.

Create hosting service categories for hosting-control access, reseller portal access, FTP access, web server access, CMS upload-path access, webshell-like hosted-path access, hidden-path access, LiteSpeed plugin-adjacent access, DNS service access, mail service access, backup service access, and customer-facing hosted-content access. Validate that DNS, proxy, WAF, CDN, firewall, NDR, FTP, web access, EDR, control-panel, and SIEM telemetry can associate network behavior with host, source, destination, domain, tenant, reseller, webroot, workload identity, and timestamp context.

Validate NAT, CDN, load-balancer, reverse-proxy, shared-IP hosting, tenant, reseller, and domain mappings before alert promotion. Where mapping is incomplete, route detections to hunt or investigation mode because the platform may not be able to prove whether inbound access and outbound behavior belong to the same affected tenant, hosted domain, or customer webroot.

Deploy initially in hunt mode for at least one business cycle that includes support access, reseller administration, FTP workflows, customer maintenance, CMS updates, plugin updates, backups, migrations, certificate renewal, DNS changes, mail operations, CDN activity, package updates, vulnerability scanning, uptime monitoring, managed security testing, abuse-response activity, and incident-response cleanup. Promote to alert mode only after approved access paths, expected outbound destinations, support sources, scanner allowlists, hosting service categories, NAT/CDN relationships, tenant mappings, and false-positive patterns are validated.

DRI Assessment

This rule has strong detection relevance as a network-behavioral correlation because hosting-control compromise and shared-hosting escalation become operationally meaningful when suspicious access is followed by outbound abuse behavior, hosted-content impact, or tenant-impact evidence. It is resilient to exploit-string changes, scanner changes, source-infrastructure rotation, webshell filename changes, symlink-path changes, and plugin-version drift because it focuses on access-to-outbound-abuse behavior rather than static indicators.

DRI

8.0

TCR Assessment

Operational telemetry confidence depends on NDR, DNS, proxy, WAF, CDN, firewall, FTP, web access, asset mapping, tenant mapping, reseller mapping, and outbound baseline availability. Confidence is lower where NDR lacks reliable asset attribution, where NAT/CDN/load-balancer relationships are not mapped, where tenant or reseller context is unavailable, where outbound destinations are not baselined, or where host/process enrichment cannot be correlated to network behavior.

Operational TCR

7.0

Full-Telemetry TCR

9.0

Limitations

This rule may produce false positives from legitimate support access, reseller administration, FTP workflows, customer uploads, CMS updates, plugin updates, backups, migrations, package updates, CDN activity, mail relay activity, uptime monitoring, vulnerability scanning, managed security testing, abuse-response work, and incident-response cleanup. NDR-only telemetry cannot independently confirm cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, root-context execution, credential access, or tenant-spanning file-system impact. This rule should trigger hosting-control, FTP, web, endpoint, file, symlink, DNS, mail, abuse-report, customer-support, and tenant-mapping correlation rather than stand alone as proof of compromise. It should not attribute activity to any named actor, scanner, webshell family, or exploit kit without separate campaign-specific evidence.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support DNS, proxy, WAF, CDN, firewall, hosting service categorization, asset enrichment, tenant enrichment, reseller enrichment, source baselining, destination baselining, and sequence logic. Host, file, FTP, web, control-panel, DNS-administration, mail, CloudLinux/CageFS, and incident-response fields should be treated as enrichment where available.

LET HOSTING_ASSETS =
ENV_HOSTING_CONTROL_ASSETS
OR ENV_SHARED_HOSTING_ASSETS
OR ENV_RESELLER_HOSTING_ASSETS
OR ENV_FTP_SERVICES
OR ENV_WEB_SERVER_ASSETS
OR ENV_DNS_SERVICE_ASSETS
OR ENV_MAIL_SERVICE_ASSETS
OR ENV_CUSTOMER_FACING_HOSTING_ASSETS

LET AFFECTED_TECH_ASSETS =
ENV_CPANEL_ASSETS
OR ENV_WHM_ASSETS
OR ENV_DNSONLY_ASSETS
OR ENV_WP_SQUARED_ASSETS
OR ENV_LITESPEED_CPANEL_PLUGIN_ASSETS
OR ENV_LITESPEED_WHM_PLUGIN_ASSETS
OR ENV_CLOUDLINUX_CAGEFS_ASSETS

LET APPROVED_HOSTING_CONTEXT =
ENV_APPROVED_ADMIN_SOURCES
OR ENV_APPROVED_SUPPORT_SOURCES
OR ENV_APPROVED_SCANNERS
OR ENV_APPROVED_MONITORING_SOURCES
OR ENV_APPROVED_BACKUP_DESTINATIONS
OR ENV_APPROVED_CDN_PROVIDERS
OR ENV_APPROVED_MAIL_RELAYS
OR ENV_APPROVED_PACKAGE_REPOSITORIES
OR ENV_APPROVED_CUSTOMER_MAINTENANCE_WINDOWS

LET suspicious_hosting_access =
network_access_events
WHERE destination_asset IN HOSTING_ASSETS
AND (
destination_asset IN AFFECTED_TECH_ASSETS
OR destination_domain IN ENV_HOSTED_DOMAINS
OR destination_webroot IN ENV_CUSTOMER_WEBROOTS
OR destination_tenant IN ENV_TENANT_MAPPINGS
OR destination_reseller IN ENV_RESELLER_MAPPINGS
)
AND destination_service IN ("cpanel", "whm", "dnsonly", "wp_squared", "reseller_portal", "ftp", "web_server", "cms_upload_path", "web_shell_like_path", "hidden_path", "litespeed_plugin_adjacent_path", "hosted_content")
AND (
source_ip NOT IN ENV_ASSET_BASELINE_SOURCE_IPS
OR source_asn NOT IN ENV_ASSET_BASELINE_ASNS
OR source_geo NOT IN ENV_ASSET_BASELINE_GEOS
OR source_network_type IN ("hosting_provider", "anonymizer", "residential_proxy", "suspicious_vps", "unknown")
OR user_agent NOT IN ENV_ASSET_BASELINE_USER_AGENTS
OR request_path IN ENV_SUSPICIOUS_HOSTED_PATH_PATTERNS
OR request_path IN ENV_PLUGIN_ADJACENT_PATHS
OR access_time NOT IN ENV_APPROVED_CUSTOMER_MAINTENANCE_WINDOWS
)
AND source_ip NOT IN ENV_APPROVED_ADMIN_SOURCES
AND source_ip NOT IN ENV_APPROVED_SUPPORT_SOURCES
AND source_ip NOT IN ENV_APPROVED_SCANNERS
AND source_ip NOT IN ENV_APPROVED_MONITORING_SOURCES

LET suspicious_outbound_abuse =
network_access_events
WHERE source_asset IN HOSTING_ASSETS
AND (
source_asset IN AFFECTED_TECH_ASSETS
OR source_domain IN ENV_HOSTED_DOMAINS
OR source_webroot IN ENV_CUSTOMER_WEBROOTS
OR source_tenant IN ENV_TENANT_MAPPINGS
OR source_reseller IN ENV_RESELLER_MAPPINGS
)
AND direction IN ("outbound", "egress")
AND (
destination_domain NOT IN ENV_ASSET_BASELINE_DESTINATIONS
OR destination_ip NOT IN ENV_ASSET_BASELINE_DESTINATION_IPS
OR destination_asn NOT IN ENV_ASSET_BASELINE_DESTINATION_ASNS
OR destination_geo NOT IN ENV_ASSET_BASELINE_DESTINATION_GEOS
OR destination_network_type IN ("hosting_provider", "anonymizer", "dynamic_dns", "suspicious_vps", "unknown")
OR destination_reputation IN ("suspicious", "malicious", "newly_observed", "poor")
OR dns_domain_age < ENV_NEW_DOMAIN_AGE_THRESHOLD
OR bytes_out > ENV_HOSTING_OUTBOUND_TRANSFER_BASELINE
OR connection_count > ENV_HOSTING_OUTBOUND_CONNECTION_BASELINE
OR network_behavior IN ("payload_retrieval", "beacon_like_http", "beacon_like_https", "archive_upload", "redirector_behavior", "phishing_hosting", "malware_hosting", "spam_related_traffic", "exfiltration_like_transfer")
)
AND destination_domain NOT IN ENV_APPROVED_BACKUP_DESTINATIONS
AND destination_domain NOT IN ENV_APPROVED_CDN_PROVIDERS
AND destination_domain NOT IN ENV_APPROVED_MAIL_RELAYS
AND destination_domain NOT IN ENV_APPROVED_PACKAGE_REPOSITORIES
AND destination_ip NOT IN ENV_APPROVED_MONITORING_SOURCES

SEQUENCE suspicious_hosting_access THEN suspicious_outbound_abuse
WHERE same_asset = true
OR same_public_ip = true
OR same_private_ip = true
OR same_domain = true
OR same_tenant = true
OR same_reseller = true
OR same_webroot = true
OR same_workload_identity = true
WITHIN ENV_HOSTING_ACCESS_TO_OUTBOUND_ABUSE_WINDOW

INCREASE_PRIORITY WHEN
process_name IN ("httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm", "pure-ftpd", "proftpd", "cron", "sh", "bash", "python", "perl", "curl", "wget")
OR process_context IN ("web_server", "php", "ftp_related", "plugin_adjacent", "cron", "shell", "interpreter", "root_context")
OR file_event IN ("web_shell_evidence", "hosted_content_change", "symlink_anomaly", "permission_anomaly", "root_owned_file_change")
OR dns_or_mail_event IN ("dns_zone_change", "mail_routing_change", "webmail_abuse", "spam_activity")
OR abuse_context IN ("phishing_report", "malware_report", "spam_report", "blocklist_entry", "customer_ticket")
OR remediation_context IN ("post_patch_recurrence", "post_plugin_update_recurrence", "post_credential_rotation_recurrence", "post_cleanup_recurrence")

LOWER_PRIORITY WHEN
finding_basis IN ("exposure_only", "scanner_only", "single_ftp_activity", "single_web_request", "single_outbound_connection", "vulnerable_version_only")
AND file_event IS NULL
AND process_context IS NULL
AND dns_or_mail_event IS NULL
AND abuse_context IS NULL
AND tenant_impact_context IS NULL

SUPPRESS WHEN
source_ip IN ENV_APPROVED_ADMIN_SOURCES
OR source_ip IN ENV_APPROVED_SUPPORT_SOURCES
OR source_ip IN ENV_APPROVED_SCANNERS
OR source_ip IN ENV_APPROVED_MONITORING_SOURCES
OR destination_domain IN ENV_APPROVED_BACKUP_DESTINATIONS
OR destination_domain IN ENV_APPROVED_CDN_PROVIDERS
OR destination_domain IN ENV_APPROVED_MAIL_RELAYS
OR destination_domain IN ENV_APPROVED_PACKAGE_REPOSITORIES
OR change_context IN ("approved_support_window", "approved_customer_maintenance", "approved_backup_job", "approved_migration", "approved_incident_response")

OUTPUT
source_asset,
destination_asset,
hosting_asset_role,
affected_technology,
source_ip,
source_asn,
source_geo,
source_network_type,
user_agent,
destination_service,
request_path,
access_time,
outbound_destination_domain,
outbound_destination_ip,
outbound_destination_asn,
outbound_destination_geo,
outbound_network_behavior,
bytes_out,
connection_count,
process_name,
process_context,
file_event,
dns_or_mail_event,
abuse_context,
tenant,
reseller,
domain,
webroot,
time_delta,
severity_reason‍ ‍

Suricata

Detection Viability Assessment

‍

Suricata has one conditional rule for this EXP report.

‍ ‍

·        Suricata is viable for network-layer exploit attempt activity, exposed control-plane probing, and suspicious administrative endpoint access where HTTP request-path visibility exists.

‍ ‍

·        Suricata is not viable as a standalone source for confirming authentication-bypass success, session validity, privileged execution, hosted-content modification, account change, outbound process attribution, or tenant blast radius.

‍ ‍

Rule 1

‍ ‍

Exposed Hosting Control-Plane Administrative Endpoint Probing

‍ ‍

Rule Format

‍ ‍

Suricata IDS/IPS signature.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious HTTP requests to exposed cPanel, WHM, WP Squared, or related hosting-control administrative paths where Suricata has HTTP request-path visibility.

‍ ‍

·        Identify exploit attempt or exposed control-plane probing activity without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success, session validity, privileged execution, hosted-content modification, tenant impact, or compromise.

‍ ‍

Detection Logic

‍ ‍

·        Identify inbound HTTP requests from external sources to scoped hosting-control-plane assets.

‍ ‍

·        Match request URIs associated with cPanel, WHM, webmail, sessionized control-panel paths, or API-style administrative access.

‍ ‍

·        Treat matching activity as network-layer early-warning evidence that requires correlation with authentication/session, endpoint, account, file-system, outbound network, or tenant-impact telemetry before escalation.

‍ ‍

·        Prioritize events involving exposed assets that were internet-facing before patch validation or that later show post-access behavior.

‍ ‍

·        Do not classify scan-only activity as probable compromise or confirmed compromise.

‍ ‍

Required Telemetry

‍ ‍

·        Suricata HTTP inspection visibility.

‍ ‍

·        HTTP request URI.

‍ ‍

·        HTTP method where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination IP.

‍ ‍

·        Destination port.

‍ ‍

·        Sensor identity.

‍ ‍

·        Timestamp.

‍ ‍

·        Scoped exposed hosting-control-plane asset list.

‍ ‍

·        Asset exposure status where available.

‍ ‍

·        Approved administrative source ranges where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate that Suricata can inspect HTTP request paths before deployment.

‍ ‍

·        Scope deployment to known internet-facing cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Define destination variables for exposed hosting-control-plane assets.

‍ ‍

·        Define destination port variables for the local hosting-control-plane inspection points.

‍ ‍

·        Add allowlists for approved vulnerability scanners, internal monitoring systems, hosting-provider support ranges, reseller administration ranges, and known management networks.

‍ ‍

·        Route alerts to SIEM correlation with authentication/session logs, endpoint process telemetry, file-system telemetry, DNS/proxy logs, and administrative action logs.

‍ ‍

·        Treat the destination system’s patch and exposure status as prioritization context, not as the only alert condition.

‍ ‍

·        Do not escalate this rule to probable compromise or confirmed compromise without post-access evidence.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

6.5 / 10

‍ ‍

·        The rule is behaviorally anchored to exposed hosting-control administrative endpoint probing rather than brittle artifact matching.

‍ ‍

·        The rule remains useful if public proof-of-concept code changes request formatting, user agent, source infrastructure, scanner name, or payload structure.

‍ ‍

·        The score is constrained because the rule observes access attempts only and cannot validate authentication state, session creation, endpoint execution, or tenant impact.

‍ ‍

·        The rule remains deployable when scoped to known exposed hosting-control-plane assets and tuned for approved administrative sources.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

4.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

6.5 / 10

‍ ‍

·        Operational confidence depends on HTTP request-path visibility, destination asset scoping, accurate source and destination metadata, and authorized-source allowlisting.

‍ ‍

·        Operational confidence is reduced because many cPanel and WHM administrative services are accessed over TLS, and Suricata may not see request paths without appropriate inspection visibility.

‍ ‍

·        Full-telemetry confidence improves when request paths are visible, hosting-control assets are accurately scoped, exposure context is available, and downstream SIEM correlation is present.

‍ ‍

·        Even under full telemetry conditions, Suricata remains a supporting early-warning source rather than a compromise-confirmation source.

‍ ‍

Limitations

‍ ‍

·        This rule detects exposed administrative endpoint probing, not confirmed exploitation.

‍ ‍

·        This rule does not validate authentication state, session legitimacy, or administrative authorization.

‍ ‍

·        This rule does not observe endpoint execution, account changes, hosted-content modification, DNS changes, outbound process attribution, or tenant blast radius.

‍ ‍

·        Encrypted traffic limits visibility unless Suricata receives HTTP request-path visibility.

‍ ‍

·        Legitimate vulnerability scanning, hosting-provider support, monitoring, reseller administration, customer support, migration activity, or patch validation activity may overlap with this behavior.

‍ ‍

·        Confirmation requires correlation with authentication/session anomalies, endpoint execution, account changes, hosted-content modification, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

alert http $EXTERNAL_NET any -> $CPANEL_CONTROL_PLANE_SERVERS $CPANEL_CONTROL_PLANE_PORTS (
    msg:"CYBERDAX EXP Hosting Control-Plane Administrative Endpoint Probing";
    flow:established,to_server;
    http.uri;
    pcre:"/^\/(?:cpanel|whm|webmail|json-api|cpsess[0-9]{5,})(?:\/|\?|$)/Ui";
    classtype:web-application-attack;
    metadata:attack_target Server, deployment Perimeter, confidence Medium, signature_severity Medium;
    sid:90070001;
    rev:1;
)

‍ ‍

SentinelOne

‍ ‍

Detection Viability Assessment

‍ ‍

SentinelOne has two rules for this EXP report.

‍ ‍

·        SentinelOne is viable for endpoint-level post-access behavior where hosting-control, web-service, account-management, mail, backup, or related service processes transition into suspicious execution or hosted-content modification.

‍ ‍

·        SentinelOne is not viable as a standalone source for confirming authentication-bypass success or control-panel session validity without application-layer access and session telemetry.

‍ ‍

·        SentinelOne is strongest when used to identify privileged execution, suspicious service-context activity, hosted-content modification, and persistence-relevant behavior after suspected control-plane compromise.

‍ ‍

Rule 1

‍ ‍

Hosting-Control Service Spawns Shell or Administrative Tooling

‍ ‍

Rule Format

‍ ‍

SentinelOne Deep Visibility query pattern suitable for STAR-style alerting after tenant field and event validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious process execution where hosting-control, web-service, mail-service, backup, account-management, or related service processes spawn shells, interpreters, administrative utilities, package tools, service-control commands, or staging utilities.

‍ ‍

·        Identify post-access endpoint behavior that may follow unauthorized control-plane access without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success, session validity, or control-panel authorization.

‍ ‍

Detection Logic

‍ ‍

·        Identify Linux process creation where the source or parent process is associated with hosting-control, web-service, mail-service, backup, account-management, or related service context.

‍ ‍

·        Prioritize child processes associated with shell execution, scripting, account administration, package activity, service control, archive staging, or outbound retrieval.

‍ ‍

·        Treat the alert as higher confidence when the affected host is a known exposed hosting-control-plane asset or when the process activity follows abnormal control-panel access, suspicious session behavior, account modification, hosted-content modification, or suspicious outbound communication.

‍ ‍

·        Suppress expected maintenance, patching, backup, migration, monitoring, support, and automation workflows only when process lineage, command line, execution user, host role, and time window are validated.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating authentication/session, account, file-system, outbound communication, or tenant-impact evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Linux process creation telemetry.

‍ ‍

·        Process ancestry.

‍ ‍

·        Command-line capture.

‍ ‍

·        Source process and target process names.

‍ ‍

·        Source process and target process paths.

‍ ‍

·        Source user and effective user context where available.

‍ ‍

·        Host role or asset context.

‍ ‍

·        Exposed hosting-control-plane asset context where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate SentinelOne tenant field names for endpoint operating system, event type, source process, target process, command line, user, process path, parent process, host identity, and timestamp before deployment.

‍ ‍

·        Scope to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Tune parent-process names and service paths to the customer’s actual hosting-control, web-service, mail-service, backup, and account-management process names.

‍ ‍

·        Add allowlists for approved patching, package-management, backup, migration, monitoring, vulnerability scanning, hosting-provider support, reseller administration, and automation workflows.

‍ ‍

·        Treat exposed hosting-control-plane status as prioritization context, not as the only alert condition.

‍ ‍

·        Use follow-on account modification, hosted-content modification, suspicious outbound communication, or persistence-relevant activity as triage evidence rather than assuming service-context execution equals compromise.

‍ ‍

·        Route alerts with exposed hosting-control-plane context, abnormal access context, or tenant-impact context at higher priority.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious service-context execution rather than brittle artifact matching.

‍ ‍

·        The rule remains useful if public proof-of-concept code changes request formatting, user agent, source infrastructure, scanner name, or payload structure.

‍ ‍

·        The score is supported by the rule’s focus on durable post-access behavior observable through endpoint process telemetry.

‍ ‍

·        The score is constrained by overlap with legitimate maintenance, patching, backup, migration, support, and automation workflows.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on process ancestry fidelity, command-line capture, user context, endpoint coverage, host role context, and maintenance baseline quality.

‍ ‍

·        Operational confidence is reduced where process lineage is incomplete, command-line capture is inconsistent, or hosting-provider workflows are poorly baselined.

‍ ‍

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with exposed asset state, control-panel access context, authentication/session context, file-system activity, and outbound network context.

‍ ‍

·        Even under full telemetry conditions, this rule requires correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious post-access execution behavior, not the original authentication-bypass event.

‍ ‍

·        Legitimate cPanel or WHM maintenance, package updates, backups, migrations, monitoring, support, and reseller administration may overlap with this behavior.

‍ ‍

·        This rule requires process lineage, command-line visibility, endpoint coverage, and server role scoping to remain reliable.

‍ ‍

·        Confirmation requires correlation with suspicious control-panel access, authentication/session anomalies, account modification, hosted-content modification, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

EndpointOS = "linux"
AND EventType = "Process Creation"
AND SrcProcName IN ANY (
  "cpsrvd",
  "cpaneld",
  "whostmgrd",
  "httpd",
  "apache2",
  "litespeed",
  "nginx",
  "php-fpm",
  "exim",
  "dovecot",
  "cron"
)
AND TgtProcName IN ANY (
  "sh",
  "bash",
  "dash",
  "zsh",
  "python",
  "python3",
  "perl",
  "php",
  "curl",
  "wget",
  "nc",
  "ncat",
  "socat",
  "useradd",
  "usermod",
  "passwd",
  "chpasswd",
  "yum",
  "dnf",
  "apt",
  "rpm",
  "systemctl",
  "service",
  "crontab",
  "tar",
  "zip",
  "gzip",
  "openssl"
)
AND NOT TgtProcCmdLine CONTAINS ANY (
  "/scripts/upcp",
  "/usr/local/cpanel/scripts/",
  "cpbackup",
  "backup",
  "yum update",
  "dnf update",
  "apt update",
  "apt upgrade"
)

‍ ‍

Rule 2

‍ ‍

Suspicious Hosted-Content Modification from Service Context

‍ ‍

Rule Format

‍ ‍

SentinelOne Deep Visibility query pattern suitable for STAR-style alerting after tenant field and event validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious hosted-content modification, script placement, permission change, archive staging, or persistence-relevant file activity from hosting-control, web-service, mail-service, backup, account-management, shell, or interpreter context.

‍ ‍

·        Identify post-access hosted-content behavior that may follow control-plane compromise without depending on static webshell signatures, CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not prove that a file is malicious without supporting context.

‍ ‍

Detection Logic

‍ ‍

·        Identify file creation, file modification, or file attribute changes in hosted-content, webroot, temporary, cron, SSH key, or service-relevant paths.

‍ ‍

·        Prioritize activity initiated by hosting-control, web-service, mail-service, backup, account-management, shell, scripting, or interpreter processes.

‍ ‍

·        Treat the alert as higher confidence when file activity affects script-like files, web-accessible paths, hidden files, writable staging paths, persistence-relevant paths, or multiple hosted accounts.

‍ ‍

·        Increase priority when activity follows abnormal control-panel access, suspicious session behavior, privileged execution, account modification, or suspicious outbound communication.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating webshell evidence, unauthorized access, persistence, outbound communication, or tenant-impact evidence.

‍ ‍

Required Telemetry

‍ ‍

·        SentinelOne file creation, file modification, or file attribute telemetry where available.

‍ ‍

·        Process ancestry for the modifying process.

‍ ‍

·        Command-line capture where available.

‍ ‍

·        File path.

‍ ‍

·        File extension where available.

‍ ‍

·        File owner and permission mode where available.

‍ ‍

·        Source user and effective user context where available.

‍ ‍

·        Host role or asset context.

‍ ‍

·        Tenant or hosted-path context where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate SentinelOne tenant field names for file path, file event type, source process, command line, user, host identity, and timestamp before deployment.

‍ ‍

·        Scope to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Validate local hosted-content paths, webroot paths, tenant directory structures, mail paths, temporary paths, cron paths, and SSH key paths before deployment.

‍ ‍

·        Add allowlists for approved customer updates, CMS updates, deployment automation, patching, backups, migrations, certificate renewal, hosting-provider support, reseller administration, and recovery workflows.

‍ ‍

·        Tune monitored paths to customer-specific hosting layouts rather than excluding broad webroot coverage.

‍ ‍

·        Treat multi-account or multi-tenant modification as higher priority than isolated single-file modification.

‍ ‍

·        Use control-panel access context, authentication/session context, account activity, outbound network activity, and tenant mapping as triage evidence.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.5 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious hosted-content and persistence-relevant file activity from service context rather than static webshell matching.

‍ ‍

·        The rule remains useful if attackers rename files, change extensions, alter webshell content, modify public exploit tooling, or use legitimate service context after gaining access.

‍ ‍

·        The score is supported by the rule’s focus on durable post-access behaviors such as webroot modification, script placement, archive staging, permission changes, and persistence-relevant file activity.

‍ ‍

·        The score is constrained by overlap with legitimate customer updates, CMS changes, backups, migrations, support workflows, and deployment automation.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.0 / 10

‍ ‍

·        Operational confidence depends on file-event visibility, process ancestry fidelity, command-line capture, hosted-path context, tenant mapping, and maintenance baseline quality.

‍ ‍

·        Operational confidence is reduced where file telemetry is incomplete, tenant mapping is unavailable, or frequent customer and CMS updates create high background change volume.

‍ ‍

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with exposed asset state, control-panel access context, authentication/session context, tenant mapping, and outbound network context.

‍ ‍

·        Even under full telemetry conditions, suspicious file activity requires correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious hosted-content modification or persistence-relevant file activity, not confirmed exploitation.

‍ ‍

·        Legitimate customer updates, CMS changes, plugin updates, backups, migrations, certificate renewal, deployment automation, support, and reseller administration may overlap with this behavior.

‍ ‍

·        This rule requires file telemetry, process lineage, hosted-path awareness, and operational context to remain reliable.

‍ ‍

·        Confirmation requires correlation with unauthorized access, suspicious execution, webshell evidence, account modification, outbound communication, or tenant-impact indicators.

‍ ‍

Detection Query Pattern

‍ ‍

EndpointOS = "linux"
AND EventType IN ANY (
  "File Creation",
  "File Modification",
  "File Attribute Change"
)
AND SrcProcName IN ANY (
  "cpsrvd",
  "cpaneld",
  "whostmgrd",
  "httpd",
  "apache2",
  "litespeed",
  "nginx",
  "php-fpm",
  "exim",
  "dovecot",
  "cron",
  "sh",
  "bash",
  "python",
  "python3",
  "perl",
  "php"
)
AND TgtFilePath CONTAINS ANY (
  "/home/",
  "/public_html/",
  "/www/",
  "/var/www/",
  "/usr/local/apache/htdocs/",
  "/etc/cron",
  "/var/spool/cron",
  "/.ssh/authorized_keys",
  "/tmp/",
  "/var/tmp/",
  "/dev/shm/"
)
AND (
  TgtFilePath ENDSWITH ANY (
    ".php",
    ".phtml",
    ".phar",
    ".pl",
    ".py",
    ".sh",
    ".cgi",
    ".js"
  )
  OR TgtFilePath CONTAINS ANY (
    "/uploads/",
    "/cache/",
    "/tmp/",
    "/var/tmp/",
    "/dev/shm/",
    "/cron",
    "/.ssh/authorized_keys"
  )
)
AND NOT SrcProcCmdLine CONTAINS ANY (
  "/scripts/upcp",
  "/usr/local/cpanel/scripts/",
  "cpbackup",
  "backup",
  "certbot",
  "acme.sh",
  "wp-cli",
  "composer install",
  "npm install"
)

‍Rule

Hosting-Control or Shared-Hosting Foothold Followed by Privileged Server-Side Activity

Rule Format

SentinelOne STAR behavioral detection pattern.

Detection Purpose

Detect endpoint-side behavior consistent with hosting-control-plane compromise or shared-hosting privilege escalation when suspicious web server, FTP, hosting-control, LiteSpeed plugin-adjacent, hosted-path, or tenant-path activity is followed by shell execution, privilege-sensitive command use, root-context behavior, account modification, persistence-like change, hosted-content tampering, archive staging, credential access, or outbound transfer from a managed hosting server.

Detection Logic

Trigger when a managed hosting server records suspicious hosting-control, FTP, web-accessible hosted-path, tenant-path, or LiteSpeed plugin-adjacent activity followed by unusual server-side execution, file-system change, account activity, service modification, or outbound tooling outside approved hosting workflows.

Require both conditions within a bounded investigation window:

·        Web server, FTP, hosting-control, hosted-content, CloudLinux/CageFS tenant-path, or LiteSpeed plugin-adjacent activity indicates possible unauthorized access, tenant foothold activity, webshell interaction, suspicious hosted-path access, unusual file upload, suspicious script execution, plugin-adjacent file activity, symlink-sensitive path activity, or activity from a source or context outside approved administrator, reseller, customer, support, maintenance, scanner, monitoring, and vulnerability-management baselines.

·        The same host, user context, effective user, process lineage, working directory, webroot, tenant path, plugin path, FTP path, or hosting-control-adjacent context then shows unusual shell execution, scripting activity, privilege-sensitive command use, root-context process behavior, account modification, service or cron change, suspicious file write, hosted-content tampering, symlink or permission anomaly, archive staging, credential-file access, outbound retrieval, or network transfer behavior outside approved support, patching, backup, migration, plugin update, customer maintenance, and incident-response workflows.

Increase priority when process lineage shows web server, PHP, FTP-related, hosting-control, LiteSpeed plugin-adjacent, cron, shell, interpreter, or root-context activity leading to command execution, outbound communication, account modification, hosted-content tampering, archive staging, credential access, or service modification.

Increase priority when the affected system is a cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, customer-facing web, DNS, mail, database, backup, ecommerce, customer portal, or high-value hosted application server.

Increase priority when downstream SIEM, NDR, proxy, DNS, WAF, CDN, FTP, web access, control-panel, mail, DNS-administration, file-integrity, abuse-report, customer-support, or incident-response correlation shows suspicious hosting-control access, FTP activity, webshell evidence, symlink or permission anomalies, hosted-content modification, DNS or mail manipulation, outbound abuse, phishing reports, malware reports, spam reports, blocklist entries, tenant-impact evidence, or post-remediation recurrence.

Do not treat web server activity, FTP use, customer file uploads, plugin updates, CMS updates, command-line administration, backup jobs, package updates, single symlink events, single file writes, single outbound connections, scanner traffic, or vulnerable-version findings alone as confirmed compromise. Require endpoint context plus hosting-control, FTP, web, file, network, tenant, or abuse-report correlation before escalating as probable hosting-control compromise, shared-hosting escalation, tenant-boundary failure, or customer-impacting abuse.

Required Telemetry

·        SentinelOne endpoint telemetry from managed hosting servers, shared-hosting servers, reseller-hosting servers, cPanel servers, WHM servers, DNSOnly servers, WP Squared systems, LiteSpeed cPanel Plugin systems, LiteSpeed WHM Plugin systems, CloudLinux/CageFS systems, web servers, FTP servers, DNS servers, mail servers, database servers, backup servers, and customer-facing hosted application servers.

·        Process name, parent process, command line, process path, process hash, user, effective user where available, host, device ID, working directory, file path, network destination, file activity, script execution, symlink or permission event where available, and timestamp.

·        Events involving web server processes, PHP, FTP-related processes, hosting-control processes, LiteSpeed or lshttpd activity, plugin-adjacent paths, customer webroots, upload paths, temporary paths, CloudLinux/CageFS tenant paths, cron, shell interpreters, scripting engines, archive tools, network transfer tools, account-management commands, service-management commands, database clients, mail utilities, DNS tools, and backup utilities.

·        Host role, asset group, tenant, reseller, domain, webroot, FTP account, control-panel account, plugin path, CloudLinux/CageFS context where available, high-value hosted application context, approved administrator workflow, approved support workflow, approved plugin update, approved CMS update, approved customer maintenance, approved backup job, approved migration, approved incident-response workflow, and exception-group mappings.

·        SIEM, NDR, proxy, DNS, WAF, CDN, FTP, web access, control-panel, DNS-administration, mail, file-integrity, abuse-report, customer-support, backup, CloudLinux/CageFS, and incident-response enrichment for downstream correlation where available.

Engineering Implementation Instructions

Create SentinelOne site, group, tag, or Deep Visibility filters for ENV_HOSTING_SERVER_ENDPOINTS, ENV_SHARED_HOSTING_ENDPOINTS, ENV_RESELLER_HOSTING_ENDPOINTS, ENV_CPANEL_ENDPOINTS, ENV_WHM_ENDPOINTS, ENV_DNSONLY_ENDPOINTS, ENV_WP_SQUARED_ENDPOINTS, ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS, ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS, ENV_CLOUDLINUX_CAGEFS_ENDPOINTS, ENV_WEB_SERVER_ENDPOINTS, ENV_FTP_SERVER_ENDPOINTS, ENV_DNS_SERVER_ENDPOINTS, ENV_MAIL_SERVER_ENDPOINTS, ENV_DATABASE_SERVER_ENDPOINTS, ENV_BACKUP_SERVER_ENDPOINTS, ENV_CUSTOMER_FACING_HOSTED_APP_ENDPOINTS, and ENV_HIGH_VALUE_HOSTING_ENDPOINTS.

Create reference lists for approved hosting-control processes, approved web server processes, approved FTP processes, approved LiteSpeed processes, approved plugin update workflows, approved CMS update workflows, approved backup processes, approved migration tooling, approved package-management activity, approved support tooling, approved customer-maintenance windows, approved administrator accounts, approved reseller workflows, approved network transfer destinations, approved mail utilities, approved DNS utilities, approved database utilities, approved incident-response tooling, approved scanners, approved monitoring tools, and known business workflows that legitimately perform hosting administration.

The engineer or admin must map local SentinelOne fields to the rule placeholders before deployment. At minimum, validate the local fields for endpoint name, endpoint tags, user name, process name, parent process name, command line, process path, file path, working directory, effective user, source IP, destination domain, event time, hash, process ancestry, file modification, network connection, and host role. If the local SentinelOne tenant does not capture command line, process ancestry, working directory, file path, symlink or permission activity, effective user, or destination domain, the rule must remain in hunt or investigation mode until compensating SIEM, EDR, Linux audit, syslog, file-integrity, web access, FTP, NDR, proxy, DNS, WAF, CDN, or control-panel telemetry is mapped.

The engineer or admin must create or validate customer-specific endpoint tags and asset groups for cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, web server, FTP server, DNS server, mail server, database, backup, customer-facing hosted application, and high-value hosting endpoints. Do not deploy against broad Linux server groups without confirming hosting role, expected administrative workflows, customer-maintenance behavior, backup schedules, plugin-update behavior, and approved support activity.

The engineer or admin must map customer-specific webroots, tenant paths, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, temporary paths, hosted-content paths, backup paths, database paths, mail paths, and control-panel-adjacent paths. Validate that these path lists distinguish expected customer activity from suspicious cross-tenant, plugin-adjacent, symlink-sensitive, root-context, or hosted-content tampering behavior.

The engineer or admin must define approved local baselines for hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. These baselines must feed the suppression and lowering logic before the rule is promoted from hunt mode to alert mode.

The engineer or admin must validate downstream correlation with hosting-control logs, FTP logs, web access logs, NDR, DNS, proxy, WAF, CDN, mail logs, DNS-administration logs, file-integrity telemetry, CloudLinux/CageFS mapping, abuse reports, customer tickets, backup records, and incident-response records. The rule should be treated as endpoint-side detection support unless these downstream data sources can confirm access-to-impact continuity, tenant scope, hosted-content impact, abuse infrastructure, or post-remediation recurrence.

Deploy initially in hunt mode. Promote to alert mode only after false positives from hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup have been baselined.

DRI Assessment

This rule has strong detection relevance because hosting-control compromise and shared-hosting privilege escalation become materially more actionable when endpoint telemetry shows suspicious hosted-path, FTP, web server, hosting-control, or plugin-adjacent activity followed by shell execution, root-context behavior, account modification, file-system impact, hosted-content tampering, outbound tooling, or persistence-like change. It is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on endpoint-side access-to-execution and access-to-impact behavior rather than static indicators.

DRI

8.0

TCR Assessment

Operational telemetry confidence depends on SentinelOne command-line capture, process ancestry, endpoint coverage on hosting servers, host-role tagging, file-path visibility, network destination visibility, user-to-host mapping, tenant or reseller mapping where available, and downstream correlation with hosting-control, FTP, web, DNS, mail, file, NDR, abuse-report, and incident-response telemetry. Confidence is reduced where endpoint coverage is missing from hosting servers, where command-line capture is incomplete, where webroot and plugin paths are not mapped, where CloudLinux/CageFS tenant context is unavailable, or where routine hosting workflows are poorly baselined.

Operational TCR

7.5

Full-Telemetry TCR

9.0

Limitations

This rule may produce false positives from legitimate hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, database maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response work, and approved incident-response cleanup. Endpoint telemetry cannot independently confirm cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, tenant-spanning access, or customer data exposure without hosting-control, FTP, web, file, symlink, DNS, mail, NDR, tenant-mapping, and abuse-report correlation. This rule should be used as endpoint-side investigation support and enrichment, not as standalone proof of compromise.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports process ancestry, command-line matching, endpoint tags, network destination visibility, file artifacts, and bounded correlation. Hosting-control, FTP, web, file-integrity, DNS, mail, CloudLinux/CageFS, NDR, abuse-report, and tenant-impact correlation should occur in the SIEM, XDR, or downstream investigation workflow where full context is available. The engineer or admin must replace all ENV_* placeholders with local SentinelOne tag names, site names, group names, Deep Visibility fields, SIEM enrichment fields, lookup lists, and exception lists before deployment.

LET HOSTING_ENDPOINT_TAGS =
(
"ENV_HOSTING_SERVER_ENDPOINTS",
"ENV_SHARED_HOSTING_ENDPOINTS",
"ENV_RESELLER_HOSTING_ENDPOINTS",
"ENV_CPANEL_ENDPOINTS",
"ENV_WHM_ENDPOINTS",
"ENV_DNSONLY_ENDPOINTS",
"ENV_WP_SQUARED_ENDPOINTS",
"ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS",
"ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS",
"ENV_CLOUDLINUX_CAGEFS_ENDPOINTS",
"ENV_WEB_SERVER_ENDPOINTS",
"ENV_FTP_SERVER_ENDPOINTS",
"ENV_DNS_SERVER_ENDPOINTS",
"ENV_MAIL_SERVER_ENDPOINTS",
"ENV_DATABASE_SERVER_ENDPOINTS",
"ENV_BACKUP_SERVER_ENDPOINTS",
"ENV_CUSTOMER_FACING_HOSTED_APP_ENDPOINTS",
"ENV_HIGH_VALUE_HOSTING_ENDPOINTS"
)

LET POSSIBLE_HOSTING_FOOTHOLD_OR_PLUGIN_ACTIVITY =
(
ProcessName IN ENV_WEB_FTP_HOSTING_CONTROL_OR_LITESPEED_PROCESSES
AND (
ParentProcessName IN ENV_WEB_FTP_HOSTING_CONTROL_OR_LITESPEED_PROCESSES
OR CommandLine CONTAINS ANY ENV_WEB_SHELL_OR_HOSTED_PATH_EXECUTION_PATTERNS
OR CommandLine CONTAINS ANY ENV_PLUGIN_ADJACENT_PATH_PATTERNS
OR CommandLine CONTAINS ANY ENV_SUSPICIOUS_UPLOAD_OR_TEMP_PATH_PATTERNS
OR FilePath CONTAINS ANY ENV_CUSTOMER_WEBROOTS
OR FilePath CONTAINS ANY ENV_FTP_UPLOAD_PATHS
OR FilePath CONTAINS ANY ENV_LITESPEED_PLUGIN_PATHS
OR FilePath CONTAINS ANY ENV_CLOUDLINUX_CAGEFS_TENANT_PATHS
OR SrcIP NOT IN ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES
)
)

LET SUSPICIOUS_SERVER_SIDE_IMPACT_ACTIVITY =
(
ProcessName IN ENV_SHELL_SCRIPTING_ADMIN_ARCHIVE_OR_NETWORK_TOOLS
OR CommandLine CONTAINS ANY ENV_PRIVILEGE_SENSITIVE_COMMAND_PATTERNS
OR CommandLine CONTAINS ANY ENV_ACCOUNT_SERVICE_CRON_OR_PERMISSION_CHANGE_PATTERNS
OR CommandLine CONTAINS ANY ENV_CREDENTIAL_FILE_ACCESS_PATTERNS
OR CommandLine CONTAINS ANY ENV_ARCHIVE_STAGING_PATTERNS
OR CommandLine CONTAINS ANY ENV_OUTBOUND_RETRIEVAL_OR_TRANSFER_PATTERNS
OR FilePath CONTAINS ANY ENV_WEB_SHELL_OR_SUSPICIOUS_HOSTED_CONTENT_PATTERNS
OR FilePath CONTAINS ANY ENV_SYMLINK_OR_PERMISSION_ANOMALY_PATHS
OR DestinationDomain IN ENV_RARE_SUSPICIOUS_OR_NEWLY_OBSERVED_DESTINATIONS
OR ProcessName IN ENV_UNAPPROVED_HOSTING_ADMIN_OR_NETWORK_TOOLS
)

FROM ProcessEvents OR NetworkEvents OR FileEvents
WHERE EndpointTags CONTAINS ANY HOSTING_ENDPOINT_TAGS
AND POSSIBLE_HOSTING_FOOTHOLD_OR_PLUGIN_ACTIVITY = true
FOLLOWED BY SUSPICIOUS_SERVER_SIDE_IMPACT_ACTIVITY
WITHIN ENV_HOSTING_FOOTHOLD_TO_SERVER_IMPACT_WINDOW
AND UserName NOT IN ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS
AND ProcessName NOT IN ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES
AND EventTime NOT IN ENV_APPROVED_SUPPORT_BACKUP_MIGRATION_PLUGIN_UPDATE_OR_CUSTOMER_MAINTENANCE_WINDOWS

INCREASE_PRIORITY WHEN
EndpointTags CONTAINS ANY (
"ENV_CPANEL_ENDPOINTS",
"ENV_WHM_ENDPOINTS",
"ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS",
"ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS",
"ENV_CLOUDLINUX_CAGEFS_ENDPOINTS",
"ENV_SHARED_HOSTING_ENDPOINTS",
"ENV_RESELLER_HOSTING_ENDPOINTS",
"ENV_HIGH_VALUE_HOSTING_ENDPOINTS"
)
OR ParentProcessName IN ENV_WEB_FTP_HOSTING_CONTROL_OR_LITESPEED_PROCESSES
OR ProcessName IN ENV_SHELL_SCRIPTING_ADMIN_ARCHIVE_OR_NETWORK_TOOLS
OR CommandLine CONTAINS ANY ENV_ROOT_CONTEXT_OR_PRIVILEGE_ESCALATION_PATTERNS
OR CommandLine CONTAINS ANY ENV_DNS_MAIL_ACCOUNT_OR_SERVICE_MANIPULATION_PATTERNS
OR FilePath CONTAINS ANY ENV_WEB_SHELL_OR_SUSPICIOUS_HOSTED_CONTENT_PATTERNS
OR FilePath CONTAINS ANY ENV_CUSTOMER_WEBROOTS
OR DestinationDomain IN ENV_RARE_SUSPICIOUS_OR_NEWLY_OBSERVED_DESTINATIONS
OR SIEMCorrelationContext CONTAINS ANY (
"web_shell_evidence",
"hosted_content_change",
"symlink_anomaly",
"permission_anomaly",
"root_owned_file_change",
"dns_zone_change",
"mail_routing_change",
"phishing_report",
"malware_report",
"spam_report",
"blocklist_entry",
"customer_ticket",
"post_remediation_recurrence"
)

LOWER_PRIORITY WHEN
FindingBasis IN (
"single_file_write",
"single_ftp_activity",
"single_web_request",
"single_outbound_connection",
"scanner_only",
"vulnerable_version_only",
"routine_customer_maintenance"
)
AND SIEMCorrelationContext IS NULL
AND DestinationDomain NOT IN ENV_RARE_SUSPICIOUS_OR_NEWLY_OBSERVED_DESTINATIONS
AND CommandLine NOT CONTAINS ANY ENV_PRIVILEGE_SENSITIVE_COMMAND_PATTERNS

SUPPRESS WHEN
UserName IN ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS
OR ProcessName IN ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES
OR DestinationDomain IN ENV_APPROVED_BACKUP_CDN_PACKAGE_MAIL_OR_MONITORING_DESTINATIONS
OR SrcIP IN ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES
OR EventTime IN ENV_APPROVED_SUPPORT_BACKUP_MIGRATION_PLUGIN_UPDATE_OR_CUSTOMER_MAINTENANCE_WINDOWS
OR ChangeContext IN (
"approved_support_window",
"approved_customer_maintenance",
"approved_backup_job",
"approved_plugin_update",
"approved_cms_update",
"approved_migration",
"approved_incident_response"
)

OUTPUT
EndpointName,
EndpointTags,
UserName,
ProcessName,
ParentProcessName,
CommandLine,
ProcessPath,
FilePath,
DestinationDomain,
SrcIP,
EventTime,
EffectiveUser,
WorkingDirectory,
Tenant,
Reseller,
Domain,
Webroot,
SIEMCorrelationContext,
ChangeContext ‍

Splunk

‍ ‍

Detection Viability Assessment

‍ ‍

Splunk has three rules for this EXP report.

‍ ‍

·        Splunk is viable for correlation across control-panel access, authentication or session telemetry, endpoint process telemetry, account activity, file-system events, DNS, proxy, and outbound network telemetry.

‍ ‍

·        Splunk is strongest where cPanel, WHM, WP Squared, endpoint, asset, and network telemetry are normalized into searchable fields with consistent host identity, source IP, user identity, session context, process lineage, file path, destination, and timestamp.

‍ ‍

·        Splunk is not a primary sensor by itself; rule quality depends on the completeness, retention, and normalization of ingested logs.

‍ ‍

Rule 1

‍ ‍

Control-Panel Access with Authentication or Session Flow Mismatch

‍ ‍

Rule Format

‍ ‍

Splunk SPL correlation search using normalized access, authentication, session, and asset fields.

‍ ‍

Detection Purpose

‍ ‍

·        Detect access to exposed cPanel, WHM, WP Squared, or related hosting-control administrative paths where access activity does not align with normal authentication or session flow.

‍ ‍

·        Identify suspected unauthorized access conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm compromise without post-access behavior or additional corroborating telemetry.

‍ ‍

Detection Logic

‍ ‍

·        Identify requests to hosting-control administrative paths from control-panel access logs.

‍ ‍

·        Correlate those requests with authentication or session telemetry for the same host, source IP, user identity where available, and time window.

‍ ‍

·        Prioritize access where privileged administrative paths are reached without corresponding successful authentication, expected session creation, approved administrator source, or known support workflow.

‍ ‍

·        Increase priority when the destination system was internet-facing before patch validation or when source, user agent, access window, or administrative identity deviates from baseline.

‍ ‍

·        Do not classify scan-only or malformed-request activity as probable compromise or confirmed compromise without post-access evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Control-panel access logs.

‍ ‍

·        Authentication logs.

‍ ‍

·        Session logs where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination host.

‍ ‍

·        Request path.

‍ ‍

·        HTTP method where available.

‍ ‍

·        User agent where available.

‍ ‍

·        User identity where available.

‍ ‍

·        Session identifier where available.

‍ ‍

·        Authentication result.

‍ ‍

·        Asset exposure status where available.

‍ ‍

·        Approved administrator source context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Splunk index names, sourcetypes, and normalized field names for control-panel access, authentication, session, asset exposure, source IP, request path, user identity, session identifier, user agent, and timestamp before deployment.

‍ ‍

·        Scope the search to known cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Normalize host identity across web access logs, authentication logs, session logs, and asset inventory.

‍ ‍

·        Maintain lookup tables for approved administrator source ranges, hosting-provider support ranges, reseller administration ranges, monitoring systems, and vulnerability scanners.

‍ ‍

·        Use asset exposure and patch status as prioritization context, not as the sole alert condition.

‍ ‍

·        Route output for correlation with endpoint process activity, account changes, hosted-content modification, DNS/proxy activity, and outbound communication.

‍ ‍

·        Do not escalate to confirmed compromise unless post-access behavior is present.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to authentication-flow mismatch rather than static exploit strings or known indicators.

‍ ‍

·        The rule remains useful if exploit request formatting, scanner names, source infrastructure, or user agents change.

‍ ‍

·        The score is supported by the rule’s focus on a primary exploitation outcome: administrative access that does not align with expected authentication behavior.

‍ ‍

·        The score is constrained by dependence on authentication and session log completeness, timestamp normalization, and field consistency.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on control-panel access logs, authentication logs, session context, asset scoping, source identity, and timestamp normalization.

‍ ‍

·        Operational confidence is reduced where session telemetry is incomplete, authentication fields are inconsistent, or support and reseller activity are not baselined.

‍ ‍

·        Full-telemetry confidence improves when access, authentication, session, asset, administrator baseline, and exposure context are normalized into consistent Splunk fields.

‍ ‍

·        Even under full telemetry conditions, this rule requires post-access correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects authentication or session-flow mismatch, not confirmed exploitation.

‍ ‍

·        Missing session telemetry may reduce confidence and require analyst review.

‍ ‍

·        Legitimate support, reseller administration, monitoring, vulnerability scanning, emergency access, or migration activity may overlap with suspicious access patterns.

‍ ‍

·        Confirmation requires correlation with endpoint execution, account modification, hosted-content change, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

index=hosting_control sourcetype IN ("cpanel:access","whm:access","hosting:control")
| eval control_host=coalesce(dest, host, dvc)
| eval src_ip=coalesce(src_ip, client_ip, src)
| eval access_user=coalesce(user, username, account, "-")
| eval session_id=coalesce(session_id, cookie_session, "-")
| where match(uri_path, "^/(cpanel|whm|webmail|json-api|cpsess[0-9]{5,})(/|\\?|$)")
| bin _time span=10m
| stats values(uri_path) as uri_paths values(http_method) as methods values(user_agent) as user_agents earliest(_time) as first_seen latest(_time) as last_seen by _time control_host src_ip access_user session_id
| append [
    search index=hosting_auth sourcetype IN ("cpanel:auth","whm:auth","hosting:session")
    | eval control_host=coalesce(dest, host, dvc)
    | eval src_ip=coalesce(src_ip, client_ip, src)
    | eval access_user=coalesce(user, username, account, "-")
    | eval session_id=coalesce(session_id, cookie_session, "-")
    | eval auth_success=if(match(action,"(?i)success|login_success|authenticated|session_created"),1,0)
    | bin _time span=10m
    | stats max(auth_success) as auth_success by _time control_host src_ip access_user session_id
]
| stats values(uri_paths) as uri_paths values(methods) as methods values(user_agents) as user_agents max(auth_success) as auth_success earliest(first_seen) as first_seen latest(last_seen) as last_seen by _time control_host src_ip access_user session_id
| eval auth_success=coalesce(auth_success,0)
| lookup hosting_control_plane_assets host as control_host OUTPUT exposed_status, patch_status
| lookup approved_admin_sources src_ip OUTPUT approved_source, source_type
| where auth_success=0 AND isnull(approved_source)
| eval severity=case(exposed_status="internet-facing" AND patch_status!="validated_patched","high",true(),"medium")
| table first_seen last_seen control_host src_ip access_user session_id uri_paths methods user_agents exposed_status patch_status severity

‍ ‍

Rule 2

‍ ‍

Suspicious Control-Plane Access Followed by Privileged Execution or Account Change

‍ ‍

Rule Format

‍ ‍

Splunk SPL correlation search using normalized access, process, account-change, and administrative action fields.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious control-plane access followed by privileged execution, administrative utility use, account modification, password reset activity, privilege change, or service modification on the same hosting-control asset.

‍ ‍

·        Identify probable compromise conditions when access anomalies are followed by post-access host or account behavior.

‍ ‍

·        This rule does not require another detection rule’s alert output and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

Detection Logic

‍ ‍

·        Identify suspicious access to hosting-control administrative paths from external or unfamiliar sources.

‍ ‍

·        Correlate access activity with endpoint process telemetry, account-change telemetry, or administrative action telemetry on the same host and time window.

‍ ‍

·        Prioritize process activity involving shell execution, scripting, account-management utilities, package tools, service-control commands, scheduled-task activity, archive staging, or outbound retrieval.

‍ ‍

·        Prioritize account activity involving new users, password resets, privilege changes, reseller changes, API token creation, SSH key placement, or service-account modification.

‍ ‍

·        Classify as confirmed compromise only when corroborating evidence shows unauthorized access plus post-access behavior that cannot be explained by approved maintenance, support, patching, backup, migration, or automation workflows.

‍ ‍

Required Telemetry

‍ ‍

·        Control-panel access logs.

‍ ‍

·        Endpoint process telemetry.

‍ ‍

·        Account-change telemetry.

‍ ‍

·        Administrative action logs where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination host.

‍ ‍

·        Request path.

‍ ‍

·        Process ancestry.

‍ ‍

·        Command line.

‍ ‍

·        Execution user.

‍ ‍

·        Account action.

‍ ‍

·        Target account.

‍ ‍

·        Host identity.

‍ ‍

·        Approved administrator or support-source context.

‍ ‍

·        Maintenance or automation context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Splunk index names, sourcetypes, and normalized field names for access logs, process events, account changes, administrative actions, host identity, source IP, user identity, command line, and timestamps before deployment.

‍ ‍

·        Scope the search to known cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Normalize host identity between access logs, endpoint telemetry, account-change logs, and administrative action logs.

‍ ‍

·        Maintain lookup tables for approved maintenance windows, package-update workflows, backup jobs, hosting-provider support sources, reseller administration ranges, and approved automation accounts.

‍ ‍

·        Use exposed asset state and patch validation as prioritization context.

‍ ‍

·        Do not require Rule 1 to fire before this rule can evaluate telemetry.

‍ ‍

·        Suppress only validated administrative workflows where source, user, command line, host role, and maintenance context match expected behavior.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious administrative access followed by privileged host or account behavior.

‍ ‍

·        The rule remains resilient if exploit format, public proof-of-concept content, source infrastructure, scanner names, or user agents change.

‍ ‍

·        The score is supported by the rule’s correlation of access anomalies with durable post-access activity.

‍ ‍

·        The score is constrained by the need for normalized host identity, process telemetry, account-change telemetry, and operational allowlists.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

·        Operational confidence depends on access log completeness, process lineage, command-line capture, account-change visibility, host identity normalization, and maintenance baseline quality.

‍ ‍

·        Operational confidence is reduced when endpoint telemetry is incomplete, account actions are not normalized, or support and maintenance workflows are not documented.

‍ ‍

·        Full-telemetry confidence improves when access, endpoint, account, administrative action, exposure, and operational context are normalized in Splunk.

‍ ‍

·        Even under full telemetry conditions, analyst or automated correlation must preserve separation between probable compromise and confirmed compromise.

‍ ‍

Limitations

‍ ‍

·        This rule does not prove the original authentication-bypass mechanism.

‍ ‍

·        Legitimate patching, package updates, support, backup, migration, account provisioning, reseller administration, and automation may overlap with the behavior.

‍ ‍

·        Weak host normalization can produce missed correlations or incorrect joins.

‍ ‍

·        Confirmation requires validation that the post-access behavior is unauthorized and not explained by approved operations.

‍ ‍

Detection Query Pattern

‍ ‍

index=hosting_control sourcetype IN ("cpanel:access","whm:access","hosting:control")
| eval control_host=coalesce(dest, host, dvc)
| eval src_ip=coalesce(src_ip, client_ip, src)
| where match(uri_path, "^/(cpanel|whm|webmail|json-api|cpsess[0-9]{5,})(/|\\?|$)")
| lookup approved_admin_sources src_ip OUTPUT approved_source, source_type
| where isnull(approved_source)
| eval access_time=_time
| table access_time control_host src_ip uri_path user user_agent
| append [
    search index=endpoint sourcetype IN ("edr:process","linux:process","sentinelone:dv","os:process")
    | eval control_host=coalesce(dest, host, dvc, endpoint_name)
    | eval follow_time=_time
    | eval evidence_type="privileged_execution"
    | eval proc_name=coalesce(process_name, TgtProcName, Image, process)
    | eval parent_name=coalesce(parent_process_name, SrcProcName, ParentImage)
    | eval cmdline=coalesce(command_line, TgtProcCmdLine, CommandLine)
    | where proc_name IN ("sh","bash","dash","zsh","python","python3","perl","php","curl","wget","nc","ncat","socat","useradd","usermod","passwd","chpasswd","yum","dnf","apt","rpm","systemctl","service","crontab","tar","zip","gzip","openssl")
       OR match(cmdline,"(?i)(useradd|usermod|passwd|chpasswd|crontab|systemctl|service|curl|wget|nc|ncat|socat|tar|zip|gzip)")
    | eval evidence_detail=coalesce(cmdline, proc_name)
    | table follow_time control_host evidence_type evidence_detail user
]
| append [
    search index=account sourcetype IN ("linux:account","cpanel:admin_action","whm:admin_action","hosting:account")
    | eval control_host=coalesce(dest, host, dvc)
    | eval follow_time=_time
    | eval evidence_type="account_or_admin_change"
    | eval account_action=coalesce(action, change_type, event_name)
    | where match(account_action,"(?i)(useradd|user_create|password_reset|passwd|privilege|reseller|api_token|ssh_key|service_account|account_modify)")
    | eval evidence_detail=coalesce(account_action, target_user, target_account)
    | table follow_time control_host evidence_type evidence_detail user
]
| eventstats values(access_time) as access_times values(src_ip) as access_src values(uri_path) as access_paths values(user_agent) as access_agents by control_host
| where isnotnull(follow_time) AND mvcount(access_times)>0
| mvexpand access_times
| where follow_time>=access_times AND follow_time<=relative_time(access_times,"+60m")
| lookup hosting_control_plane_assets host as control_host OUTPUT exposed_status, patch_status
| lookup approved_maintenance host as control_host OUTPUT approved_workflow
| where isnull(approved_workflow)
| eval severity=case(exposed_status="internet-facing" AND patch_status!="validated_patched","critical",true(),"high")
| table access_times follow_time control_host access_src access_paths evidence_type evidence_detail user exposed_status patch_status severity

‍ ‍

Rule 3

‍ ‍

Control-Plane Access Followed by Tenant Modification or Suspicious Outbound Communication

‍ ‍

Rule Format

‍ ‍

Splunk SPL correlation search using normalized access, file, tenant, DNS, proxy, network, and asset fields.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious control-plane access followed by hosted-content modification, tenant-impacting file activity, DNS or mail changes, abuse-related behavior, or suspicious outbound communication.

‍ ‍

·        Identify probable compromise conditions where administrative access anomalies are followed by downstream tenant, file, or network behavior.

‍ ‍

·        This rule does not prove exploitation without corroborating telemetry and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

Detection Logic

‍ ‍

·        Identify suspicious access to hosting-control administrative paths from unfamiliar or unapproved sources.

‍ ‍

·        Correlate access activity with file modification events, administrative action logs, DNS/proxy events, outbound network telemetry, or abuse indicators on the same host and time window.

‍ ‍

·        Prioritize changes affecting hosted directories, webroots, mailboxes, DNS zones, databases, customer domains, suspicious script files, archive staging, or writable paths.

‍ ‍

·        Prioritize outbound communication to newly observed domains, unusual infrastructure, payload-staging locations, or destinations inconsistent with historical server behavior.

‍ ‍

·        Do not classify activity as confirmed compromise without validation that the file, tenant, administrative, or outbound behavior is unauthorized and not part of approved operations.

‍ ‍

Required Telemetry

‍ ‍

·        Control-panel access logs.

‍ ‍

·        File creation or modification telemetry.

‍ ‍

·        Administrative action logs where available.

‍ ‍

·        DNS logs.

‍ ‍

·        Proxy or network logs.

‍ ‍

·        Tenant mapping where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination host.

‍ ‍

·        Request path.

‍ ‍

·        File path.

‍ ‍

·        File action.

‍ ‍

·        Destination domain.

‍ ‍

·        Destination IP.

‍ ‍

·        Host identity.

‍ ‍

·        Asset exposure context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Splunk index names, sourcetypes, and normalized field names for access logs, file events, administrative actions, DNS, proxy, network, tenant mapping, host identity, and timestamps before deployment.

‍ ‍

·        Scope the search to known cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Normalize host identity across control-panel access, file telemetry, administrative actions, DNS, proxy, network, and tenant mapping sources.

‍ ‍

·        Maintain lookup tables for tenant-to-path mapping, domain-to-account mapping, approved update workflows, approved backup or migration workflows, approved support ranges, and known administrative sources.

‍ ‍

·        Use exposed asset state and patch validation as prioritization context, not as the only alert condition.

‍ ‍

·        Do not require Rule 1 or Rule 2 to fire before this rule can evaluate telemetry.

‍ ‍

·        Suppress only validated customer updates, CMS updates, backups, migrations, support workflows, or known administrative actions.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious access followed by tenant-impacting or outbound behavior.

‍ ‍

·        The rule remains resilient if attackers modify exploit request format, source infrastructure, user agent, scanner name, or payload structure.

‍ ‍

·        The score is supported by correlation between access anomalies and downstream activity that reflects likely operational impact.

‍ ‍

·        The score is constrained by dependence on tenant mapping, file telemetry, DNS/proxy visibility, and operational context.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on access log completeness, file-event visibility, tenant mapping, DNS/proxy coverage, host identity normalization, and operational baseline quality.

‍ ‍

·        Operational confidence is reduced where tenant mapping is incomplete, file telemetry is limited, or customer update workflows create high background activity.

‍ ‍

·        Full-telemetry confidence improves when access, file, tenant, DNS, proxy, network, exposure, and operational context are normalized in Splunk.

‍ ‍

·        Even under full telemetry conditions, this rule requires validation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious post-access tenant, file, or outbound behavior, not the original authentication-bypass mechanism.

‍ ‍

·        Legitimate customer updates, CMS changes, migrations, backups, DNS administration, mail administration, support, and reseller activity may overlap with this behavior.

‍ ‍

·        Missing tenant mapping can weaken blast-radius assessment.

‍ ‍

·        Missing process-to-network attribution can reduce confidence in outbound communication findings.

‍ ‍

·        Confirmation requires correlation with unauthorized access, suspicious execution, hosted-content modification, account change, outbound behavior, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

index=hosting_control sourcetype IN ("cpanel:access","whm:access","hosting:control")
| eval control_host=coalesce(dest, host, dvc)
| eval src_ip=coalesce(src_ip, client_ip, src)
| where match(uri_path, "^/(cpanel|whm|webmail|json-api|cpsess[0-9]{5,})(/|\\?|$)")
| lookup approved_admin_sources src_ip OUTPUT approved_source, source_type
| where isnull(approved_source)
| eval access_time=_time
| table access_time control_host src_ip uri_path user user_agent
| append [
    search index=file sourcetype IN ("edr:file","linux:file","os:file","sentinelone:file")
    | eval control_host=coalesce(dest, host, dvc, endpoint_name)
    | eval follow_time=_time
    | eval evidence_type="file_or_tenant_change"
    | eval evidence_detail=coalesce(file_path, TgtFilePath, path)
    | where match(evidence_detail,"(?i)(/home/|/public_html/|/var/www/|/usr/local/apache/htdocs/|/tmp/|/var/tmp/|/dev/shm/|/etc/cron|/var/spool/cron)")
    | table follow_time control_host evidence_type evidence_detail user
]
| append [
    search index=network sourcetype IN ("dns","stream:dns","proxy","firewall","network:connection")
    | eval control_host=coalesce(src_host, host, dvc)
    | eval follow_time=_time
    | eval evidence_type="outbound_activity"
    | eval evidence_detail=coalesce(query, dest_domain, dest_ip, url)
    | where isnotnull(evidence_detail)
    | table follow_time control_host evidence_type evidence_detail user
]
| eventstats values(access_time) as access_times values(src_ip) as access_src values(uri_path) as access_paths values(user_agent) as access_agents by control_host
| where isnotnull(follow_time) AND mvcount(access_times)>0
| mvexpand access_times
| where follow_time>=access_times AND follow_time<=relative_time(access_times,"+120m")
| lookup hosting_control_plane_assets host as control_host OUTPUT exposed_status, patch_status
| lookup approved_change_windows host as control_host OUTPUT approved_workflow
| lookup tenant_path_map path as evidence_detail OUTPUT tenant_id, domain
| where isnull(approved_workflow)
| eval severity=case(exposed_status="internet-facing" AND patch_status!="validated_patched","critical",isnotnull(tenant_id),"high",true(),"medium")
| table access_times follow_time control_host access_src access_paths evidence_type evidence_detail tenant_id domain exposed_status patch_status severity

‍Rule 4

Hosting-Control or Shared-Hosting Foothold Followed by Privileged Server-Side Activity

Rule Format

Splunk SPL cross-source hosting endpoint, file, web, FTP, and network correlation pattern.

Detection Purpose

Detect suspicious hosting-control, FTP, web-accessible hosted-path, tenant-path, or LiteSpeed plugin-adjacent activity followed by server-side execution, root-context behavior, account modification, service or cron change, hosted-content tampering, archive staging, credential-file access, suspicious outbound retrieval, or network transfer behavior on affected hosting infrastructure.

Detection Logic

Trigger when suspicious activity associated with hosting-control services, FTP services, web server processes, hosted paths, CloudLinux/CageFS tenant paths, or LiteSpeed plugin-adjacent paths is followed by privileged server-side activity or suspicious outbound behavior on the same host, tenant, reseller, domain, webroot, source account, process lineage, file path, or workload identity.

Require both conditions within a bounded investigation window:

·        Endpoint, file, web, FTP, hosting-control, or network telemetry shows possible unauthorized access, tenant foothold activity, webshell interaction, suspicious hosted-path access, unusual file upload, suspicious script execution, plugin-adjacent file activity, symlink-sensitive path activity, abnormal FTP activity, suspicious web access, or activity outside approved administrator, reseller, customer, support, maintenance, scanner, monitoring, and vulnerability-management baselines.

·        The same host, correlation key, effective user, service account, process lineage, working directory, webroot, tenant path, plugin path, FTP path, control-panel account, FTP account, tenant, reseller, domain, or hosting-control-adjacent context then shows unusual shell execution, scripting activity, privilege-sensitive command use, root-context process behavior, account modification, service or cron change, suspicious file write, hosted-content tampering, symlink or permission anomaly, archive staging, credential-file access, outbound retrieval, or network transfer behavior outside approved support, patching, backup, migration, plugin update, customer maintenance, and incident-response workflows.

Increase priority when activity involves cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, customer-facing web, DNS, mail, database, backup, ecommerce, customer portal, or high-value hosted application infrastructure.

Increase priority when the correlated activity includes webshell evidence, hosted-content modification, symlink or permission anomalies, root-owned file changes, DNS or mail manipulation, abuse reports, customer tickets, phishing reports, malware reports, spam reports, blocklist entries, tenant-impact evidence, or post-remediation recurrence.

Do not treat web server activity, FTP use, customer file uploads, plugin updates, CMS updates, command-line administration, backup jobs, package updates, single symlink events, single file writes, single outbound connections, scanner traffic, or vulnerable-version findings alone as confirmed compromise. Require access-to-impact correlation and local telemetry enrichment before escalating as probable hosting-control compromise, shared-hosting escalation, tenant-boundary failure, or customer-impacting abuse.

Required Telemetry

·        Splunk indexes, sourcetypes, accelerated data models, or normalized summary indexes for SentinelOne or EDR telemetry, Linux audit, syslog, process accounting, file-integrity telemetry, web server logs, FTP logs, control-panel logs, DNS logs, mail logs, proxy logs, firewall logs, WAF logs, CDN logs, NDR telemetry, abuse-report records, customer-support records, backup records, CloudLinux/CageFS records where available, and incident-response records.

·        Normalized fields for host, endpoint, user, effective user where available, service account, process name, parent process name, command line, process path, working directory, file path, file owner, file permission, symlink target where available, source IP, destination domain, destination IP, URL path, HTTP method, user agent, FTP account, FTP operation, control-panel account, tenant, reseller, domain, webroot, plugin path, action, sourcetype, timestamp, and remediation context.

·        Lookup tables or KV-store collections for hosting endpoints, shared-hosting endpoints, reseller-hosting endpoints, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, web server endpoints, FTP server endpoints, DNS server endpoints, mail server endpoints, database servers, backup servers, customer-facing hosted applications, high-value hosting endpoints, hosted domains, customer webroots, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, tenant mappings, reseller mappings, approved administrators, approved support users, approved service accounts, approved support sources, approved scanners, approved monitoring sources, approved backup destinations, approved CDN providers, approved mail relays, approved package repositories, approved maintenance windows, approved incident-response workflows, and exception groups.

·        Baseline lookups or summary indexes for normal hosting-control activity, web server process behavior, FTP workflows, customer maintenance, CMS updates, plugin updates, backup activity, migration activity, package updates, DNS changes, mail operations, outbound destinations, administrator activity, reseller workflows, support activity, vulnerability scanning, managed security testing, and incident-response cleanup.

·        Time synchronization across EDR, Linux audit, syslog, process accounting, file-integrity, web, FTP, control-panel, DNS, mail, proxy, firewall, WAF, CDN, NDR, CloudLinux/CageFS, backup, support, abuse-report, and incident-response telemetry.

Engineering Implementation Instructions

Create and validate Splunk macros for local index and sourcetype scope, including hosting_endpoint_process_events, hosting_endpoint_file_events, hosting_endpoint_network_events, hosting_web_access_events, hosting_ftp_events, hosting_control_panel_events, hosting_dns_mail_events, hosting_abuse_support_events, hosting_asset_lookup_scope, hosting_foothold_candidate_summary, hosting_server_impact_candidate_summary, and hosting_post_remediation_activity. These macros should hide customer-specific indexes, sourcetypes, vendor connectors, accelerated data sources, summary indexes, CIM or non-CIM field names, and local naming conventions from the detection logic.

Create and validate Splunk lookups for ENV_HOSTING_ENDPOINTS, ENV_HOSTING_SERVER_ENDPOINTS, ENV_SHARED_HOSTING_ENDPOINTS, ENV_RESELLER_HOSTING_ENDPOINTS, ENV_CPANEL_ENDPOINTS, ENV_WHM_ENDPOINTS, ENV_DNSONLY_ENDPOINTS, ENV_WP_SQUARED_ENDPOINTS, ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS, ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS, ENV_CLOUDLINUX_CAGEFS_ENDPOINTS, ENV_WEB_SERVER_ENDPOINTS, ENV_FTP_SERVER_ENDPOINTS, ENV_DNS_SERVER_ENDPOINTS, ENV_MAIL_SERVER_ENDPOINTS, ENV_DATABASE_SERVER_ENDPOINTS, ENV_BACKUP_SERVER_ENDPOINTS, ENV_CUSTOMER_FACING_HOSTED_APP_ENDPOINTS, ENV_HIGH_VALUE_HOSTING_ENDPOINTS, ENV_HOSTED_DOMAINS, ENV_CUSTOMER_WEBROOTS, ENV_FTP_UPLOAD_PATHS, ENV_LITESPEED_PLUGIN_PATHS, ENV_CLOUDLINUX_CAGEFS_TENANT_PATHS, ENV_TENANT_MAPPINGS, ENV_RESELLER_MAPPINGS, ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS, ENV_APPROVED_SERVICE_ACCOUNTS, ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES, ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES, ENV_APPROVED_BACKUP_CDN_PACKAGE_MAIL_OR_MONITORING_DESTINATIONS, ENV_APPROVED_SUPPORT_BACKUP_MIGRATION_PLUGIN_UPDATE_OR_CUSTOMER_MAINTENANCE_WINDOWS, and ENV_HOSTING_EXCEPTION_GROUPS.

The engineer or admin must map local Splunk fields to the rule placeholders before deployment. At minimum, validate local fields for host, endpoint, user, effective user where available, service account, process name, parent process name, command line, process path, working directory, file path, file owner, file permission, symlink target where available, source IP, destination domain, destination IP, URL path, HTTP method, user agent, FTP account, FTP operation, control-panel account, tenant, reseller, domain, webroot, plugin path, event time, sourcetype, index, and remediation context. Where CIM data models are available, validate mappings against Endpoint.Processes, Endpoint.Filesystem, Network_Traffic, Web, Authentication, Change, and any locally normalized hosting or EDR data models.

The engineer or admin must create customer-specific mappings for webroots, tenant paths, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, backup paths, database paths, mail paths, temporary paths, webshell candidate paths, symlink-sensitive paths, and control-panel-adjacent paths. These mappings must distinguish expected customer maintenance from suspicious cross-tenant, plugin-adjacent, symlink-sensitive, root-context, or hosted-content tampering behavior.

The engineer or admin must configure command, path, process, destination, and behavior match lists as wildcard lookups, regex lookups, precomputed match flags, or normalized enrichment fields before deployment. Do not assume exact-match lookup behavior will identify command-line substrings, path fragments, webroot patterns, plugin paths, suspicious hosted-content patterns, credential-file paths, symlink-sensitive paths, or rare destination categories. If the local Splunk environment cannot support wildcard or regex lookups safely at scale, precompute candidate flags into summary indexes or accelerated datasets before using this rule for alerting.

The engineer or admin must define approved local baselines for hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. These baselines must feed lookup-output flags, exception logic, lowering logic, and suppression logic before the rule is promoted from hunt mode to alert mode.

The engineer or admin must validate a normalized correlation key before deployment. The key should not depend only on username because hosting servers may run activity under generic, blank, root, apache, nginx, nobody, cpanel, FTP service, web server, or support service contexts. Build correlation from the best available combination of host, endpoint, tenant, reseller, domain, webroot, FTP account, control-panel account, process lineage, file path, source IP, destination domain, and workload identity. Where user context is missing or generic, correlation should fall back to host plus webroot, tenant, reseller, domain, process lineage, file path, or FTP/control-panel account.

The engineer or admin must validate that summary indexes, accelerated data models, or scheduled intermediate searches can support the rule without unrestricted raw joins across high-volume endpoint, file, web, FTP, proxy, DNS, WAF, CDN, and NDR datasets. Correlate by normalized host, endpoint, correlation key, process lineage, file path, webroot, tenant, reseller, domain, source IP, and bounded time windows using sorted candidate streams, lookup-output match flags, baseline flags, carry-forward markers, and streamstats where needed. Validate query performance before alert promotion.

Deploy initially in hunt mode for at least one business cycle that includes hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. Promote to alert mode only after field mappings, macros, lookups, wildcard or regex match handling, correlation-key behavior, acceleration strategy, exception groups, query performance, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has strong detection relevance because hosting-control compromise and shared-hosting privilege escalation become materially actionable when suspicious hosted-path, FTP, web server, hosting-control, or plugin-adjacent activity is followed by shell execution, root-context behavior, account modification, file-system impact, hosted-content tampering, outbound tooling, abuse-report evidence, or persistence-like change. It is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on access-to-execution and access-to-impact behavior rather than static indicators.

DRI

8.5

TCR Assessment

Operational telemetry confidence depends on Splunk access to endpoint process telemetry, file telemetry, web logs, FTP logs, control-panel logs, DNS and mail logs, network telemetry, host-role tagging, tenant mapping, reseller mapping, webroot mapping, plugin-path mapping, normalized field mappings, wildcard or regex lookup handling, summary indexing, and baseline lookups. Confidence is reduced where endpoint coverage is missing from hosting servers, command-line capture is incomplete, webroot and plugin paths are not mapped, CloudLinux/CageFS tenant context is unavailable, generic service-account activity cannot be correlated, or routine hosting workflows are poorly baselined.

Operational TCR

8.0

Full-Telemetry TCR

9.0

Limitations

This rule may produce false positives from legitimate hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, database maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response work, and approved incident-response cleanup. The rule cannot independently confirm cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, tenant-spanning access, or customer data exposure without hosting-control, FTP, web, file, symlink, DNS, mail, NDR, tenant-mapping, and abuse-report correlation. It should not attribute activity to any named actor, scanner, webshell family, or exploit kit without separate validated intelligence. Query performance depends on local indexing strategy, field normalization, acceleration, summary indexing, lookup hygiene, wildcard or regex match handling, bounded time windows, and avoiding unrestricted joins across high-volume telemetry.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support endpoint process telemetry, file telemetry, web logs, FTP logs, control-panel logs, DNS, mail, proxy, WAF, CDN, NDR, asset enrichment, tenant enrichment, reseller enrichment, summary indexing, and accelerated data sources. Customer-specific indexes, sourcetypes, field names, accelerated data sources, local asset groups, local pattern matching, and local exception logic should be abstracted behind macros and lookups. The engineer or admin must replace all ENV_* placeholders with local Splunk macros, lookup tables, KV-store collections, summary indexes, field aliases, data-model fields, regex or wildcard match flags, and exception lists before deployment.

hosting_endpoint_process_events
| eval normalized_host=coalesce(host, dest, ComputerName, endpoint_name, device_name)
| eval normalized_user=coalesce(user, UserName, account, username, actor_user, "unknown")
| eval normalized_process=lower(coalesce(process_name, ProcessName, process, Image, process_exec))
| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, ParentImage))
| eval normalized_command=coalesce(command_line, CommandLine, process_command_line, cmdline)
| eval normalized_process_path=coalesce(process_path, ProcessPath, ImagePath)
| eval normalized_working_directory=coalesce(working_directory, WorkingDirectory, cwd)
| eval normalized_file_path=coalesce(file_path, FilePath, target_path, object_path)
| eval normalized_dest_domain=coalesce(dest_domain, DestinationDomain, url_domain, domain)
| eval normalized_src_ip=coalesce(src_ip, SourceIp, client_ip)
| eval normalized_time=_time
| eval source_branch="endpoint_process"
| append [
hosting_endpoint_file_events
| eval normalized_host=coalesce(host, dest, ComputerName, endpoint_name, device_name)
| eval normalized_user=coalesce(user, UserName, account, username, actor_user, "unknown")
| eval normalized_process=lower(coalesce(process_name, ProcessName, process, Image, process_exec))
| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, ParentImage))
| eval normalized_command=coalesce(command_line, CommandLine, process_command_line, cmdline)
| eval normalized_process_path=coalesce(process_path, ProcessPath, ImagePath)
| eval normalized_working_directory=coalesce(working_directory, WorkingDirectory, cwd)
| eval normalized_file_path=coalesce(file_path, FilePath, target_path, object_path)
| eval normalized_dest_domain=coalesce(dest_domain, DestinationDomain, url_domain, domain)
| eval normalized_src_ip=coalesce(src_ip, SourceIp, client_ip)
| eval normalized_time=_time
| eval source_branch="endpoint_file"
]
| append [
hosting_web_access_events
| eval normalized_host=coalesce(host, dest, server, web_server, endpoint_name)
| eval normalized_user=coalesce(user, username, authenticated_user, account, "unknown")
| eval normalized_process=lower(coalesce(process_name, ProcessName, process, "web_access"))
| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, "web_access"))
| eval normalized_command=coalesce(uri, url, request, http_request)
| eval normalized_process_path=coalesce(uri_path, url_path, request_path)
| eval normalized_working_directory=coalesce(webroot, document_root, site_root)
| eval normalized_file_path=coalesce(uri_path, url_path, request_path, file_path)
| eval normalized_dest_domain=coalesce(hostname, http_host, site_domain, domain)
| eval normalized_src_ip=coalesce(src_ip, client_ip, SourceIp)
| eval normalized_time=_time
| eval source_branch="web_access"
]
| append [
hosting_ftp_events
| eval normalized_host=coalesce(host, dest, ftp_server, endpoint_name)
| eval normalized_user=coalesce(user, ftp_user, username, account, "unknown")
| eval normalized_process=lower(coalesce(process_name, ProcessName, process, "ftp_service"))
| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, "ftp_service"))
| eval normalized_command=coalesce(action, operation, ftp_operation)
| eval normalized_process_path=coalesce(path, file_path, ftp_path)
| eval normalized_working_directory=coalesce(directory, cwd, ftp_directory)
| eval normalized_file_path=coalesce(path, file_path, ftp_path)
| eval normalized_dest_domain=coalesce(dest_domain, domain, host)
| eval normalized_src_ip=coalesce(src_ip, client_ip, SourceIp)
| eval normalized_time=_time
| eval source_branch="ftp_access"
]
| append [
hosting_endpoint_network_events
| eval normalized_host=coalesce(host, dest, ComputerName, endpoint_name, device_name)
| eval normalized_user=coalesce(user, UserName, account, username, actor_user, "unknown")
| eval normalized_process=lower(coalesce(process_name, ProcessName, process, Image, process_exec))
| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, ParentImage))
| eval normalized_command=coalesce(command_line, CommandLine, process_command_line, cmdline)
| eval normalized_process_path=coalesce(process_path, ProcessPath, ImagePath)
| eval normalized_working_directory=coalesce(working_directory, WorkingDirectory, cwd)
| eval normalized_file_path=coalesce(file_path, FilePath, target_path, object_path)
| eval normalized_dest_domain=coalesce(dest_domain, DestinationDomain, url_domain, domain)
| eval normalized_src_ip=coalesce(src_ip, SourceIp, client_ip)
| eval normalized_time=_time
| eval source_branch="endpoint_network"
]
| lookup ENV_HOSTING_ENDPOINTS normalized_host OUTPUT hosting_endpoint_match hosting_asset_role affected_technology tenant reseller domain webroot
| lookup ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS normalized_user OUTPUT approved_user_match
| lookup ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES normalized_process OUTPUT approved_process_match
| lookup ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES normalized_src_ip OUTPUT approved_source_match
| lookup ENV_CUSTOMER_WEBROOTS normalized_file_path OUTPUT webroot_path_match
| lookup ENV_FTP_UPLOAD_PATHS normalized_file_path OUTPUT ftp_path_match
| lookup ENV_LITESPEED_PLUGIN_PATHS normalized_file_path OUTPUT litespeed_plugin_path_match
| lookup ENV_CLOUDLINUX_CAGEFS_TENANT_PATHS normalized_file_path OUTPUT cagefs_path_match
| lookup ENV_PRIVILEGE_SENSITIVE_COMMAND_PATTERNS normalized_command OUTPUT privilege_command_match
| lookup ENV_ACCOUNT_SERVICE_CRON_OR_PERMISSION_CHANGE_PATTERNS normalized_command OUTPUT admin_change_match
| lookup ENV_CREDENTIAL_FILE_ACCESS_PATTERNS normalized_command OUTPUT credential_access_match
| lookup ENV_ARCHIVE_STAGING_PATTERNS normalized_command OUTPUT archive_staging_match
| lookup ENV_OUTBOUND_RETRIEVAL_OR_TRANSFER_PATTERNS normalized_command OUTPUT outbound_transfer_match
| lookup ENV_WEB_SHELL_OR_SUSPICIOUS_HOSTED_CONTENT_PATTERNS normalized_file_path OUTPUT hosted_content_match
| lookup ENV_SYMLINK_OR_PERMISSION_ANOMALY_PATHS normalized_file_path OUTPUT symlink_permission_match
| lookup ENV_RARE_SUSPICIOUS_OR_NEWLY_OBSERVED_DESTINATIONS normalized_dest_domain OUTPUT suspicious_destination_match
| where hosting_endpoint_match="true"
| eval service_user_context=if(normalized_user IN ("unknown", "root", "apache", "nginx", "nobody", "cpanel", "www-data", "ftp", "system"), "generic_or_service_user", "specific_user")
| eval normalized_correlation_key=coalesce(tenant, reseller, domain, webroot, normalized_host) . "::" . coalesce(webroot_path_match, ftp_path_match, litespeed_plugin_path_match, cagefs_path_match, normalized_file_path, normalized_process_path, normalized_host)
| eval foothold_candidate=if(
approved_user_match!="true"
AND approved_process_match!="true"
AND (
source_branch IN ("web_access", "ftp_access", "endpoint_file")
OR normalized_parent_process IN ("httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm", "pure-ftpd", "proftpd", "cpanel", "whostmgrd", "cpdavd", "cpsrvd")
OR normalized_process IN ("httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm", "pure-ftpd", "proftpd", "cpanel", "whostmgrd", "cpdavd", "cpsrvd")
OR webroot_path_match="true"
OR ftp_path_match="true"
OR litespeed_plugin_path_match="true"
OR cagefs_path_match="true"
OR approved_source_match!="true"
),
"true",
"false"
)
| eval impact_candidate=if(
approved_user_match!="true"
AND approved_process_match!="true"
AND (
normalized_process IN ("sh", "bash", "dash", "zsh", "python", "python3", "perl", "php", "php-fpm", "curl", "wget", "nc", "ncat", "socat", "tar", "gzip", "zip", "mysqldump", "mysql", "crontab", "chmod", "chown", "useradd", "usermod", "passwd", "systemctl", "service")
OR privilege_command_match="true"
OR admin_change_match="true"
OR credential_access_match="true"
OR archive_staging_match="true"
OR outbound_transfer_match="true"
OR hosted_content_match="true"
OR symlink_permission_match="true"
OR suspicious_destination_match="true"
),
"true",
"false"
)
| eval foothold_reason=mvappend(
if(source_branch="web_access", "web_access_context", null()),
if(source_branch="ftp_access", "ftp_access_context", null()),
if(source_branch="endpoint_file", "file_activity_context", null()),
if(normalized_parent_process IN ("httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm", "pure-ftpd", "proftpd", "cpanel", "whostmgrd", "cpdavd", "cpsrvd"), "hosting_process_lineage", null()),
if(webroot_path_match="true", "customer_webroot_path", null()),
if(ftp_path_match="true", "ftp_upload_path", null()),
if(litespeed_plugin_path_match="true", "litespeed_plugin_path", null()),
if(cagefs_path_match="true", "cloudlinux_cagefs_tenant_path", null()),
if(approved_source_match!="true", "unapproved_or_unbaselined_source", null())
)
| eval impact_reason=mvappend(
if(normalized_process IN ("sh", "bash", "dash", "zsh", "python", "python3", "perl", "php", "php-fpm", "curl", "wget", "nc", "ncat", "socat", "tar", "gzip", "zip", "mysqldump", "mysql", "crontab", "chmod", "chown", "useradd", "usermod", "passwd", "systemctl", "service"), "suspicious_server_side_process", null()),
if(privilege_command_match="true", "privilege_sensitive_command", null()),
if(admin_change_match="true", "account_service_cron_or_permission_change", null()),
if(credential_access_match="true", "credential_file_access", null()),
if(archive_staging_match="true", "archive_staging", null()),
if(outbound_transfer_match="true", "outbound_retrieval_or_transfer", null()),
if(hosted_content_match="true", "hosted_content_or_web_shell_path", null()),
if(symlink_permission_match="true", "symlink_or_permission_anomaly_path", null()),
if(suspicious_destination_match="true", "rare_suspicious_or_new_destination", null())
)
| eval event_kind=case(foothold_candidate="true", "foothold_candidate", impact_candidate="true", "impact_candidate", true(), "non_candidate")
| where event_kind!="non_candidate"
| sort 0 normalized_host normalized_correlation_key normalized_time
| eval foothold_time_marker=if(event_kind="foothold_candidate", normalized_time, null())
| eval foothold_process_marker=if(event_kind="foothold_candidate", normalized_process, null())
| eval foothold_parent_marker=if(event_kind="foothold_candidate", normalized_parent_process, null())
| eval foothold_path_marker=if(event_kind="foothold_candidate", normalized_file_path, null())
| eval foothold_reason_marker=if(event_kind="foothold_candidate", foothold_reason, null())
| streamstats current=f last(foothold_time_marker) as carry_foothold_time last(foothold_process_marker) as carry_foothold_process last(foothold_parent_marker) as carry_foothold_parent last(foothold_path_marker) as carry_foothold_path last(foothold_reason_marker) as carry_foothold_reason by normalized_host normalized_correlation_key
| where event_kind="impact_candidate"
| where isnotnull(carry_foothold_time)
| where normalized_time >= carry_foothold_time
| where normalized_time <= carry_foothold_time + ENV_HOSTING_FOOTHOLD_TO_SERVER_IMPACT_WINDOW_SECONDS
| lookup ENV_HOSTING_EXCEPTION_GROUPS normalized_host normalized_user normalized_process normalized_file_path normalized_dest_domain OUTPUT exception_match
| lookup ENV_APPROVED_SUPPORT_BACKUP_MIGRATION_PLUGIN_UPDATE_OR_CUSTOMER_MAINTENANCE_WINDOWS normalized_host normalized_time OUTPUT approved_window_match
| where exception_match!="true"
| where approved_window_match!="true"
| eval severity_reason=mvappend(carry_foothold_reason, impact_reason)
| table carry_foothold_time normalized_time normalized_host normalized_correlation_key service_user_context normalized_user hosting_asset_role affected_technology tenant reseller domain webroot carry_foothold_process carry_foothold_parent carry_foothold_path normalized_process normalized_parent_process normalized_command normalized_process_path normalized_working_directory normalized_file_path normalized_dest_domain source_branch severity_reason

Elastic

‍ ‍

Detection Viability Assessment

‍ ‍

Elastic has four rules for this EXP report.

‍ ‍

·        Elastic is viable for endpoint, web, authentication, file, DNS, and network telemetry correlation when Elastic Defend, web access logs, control-panel logs, and network data are normalized into consistent host, user, process, file, source, destination, and timestamp fields.

‍ ‍

·        Elastic is strongest for endpoint process behavior, control-panel access anomalies, hosted-content modification, and supporting outbound context when those telemetry sources are available in the same Elastic environment.

‍ ‍

·        Elastic is not a standalone confirmation source for authentication-bypass success unless application-layer access, authentication, or session telemetry is ingested and correlated with post-access behavior.

‍ ‍

Rule 1

‍ ‍

Control-Panel Access or Authentication-Flow Mismatch

‍ ‍

Rule Format

‍ ‍

Elastic KQL correlation pattern suitable for Elastic Security after index, field, exception-list, and data-stream validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect access to cPanel, WHM, WP Squared, or related hosting-control administrative paths where access activity does not align with normal authentication or session behavior.

‍ ‍

·        Identify suspected unauthorized access conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm compromise without post-access endpoint, account, file, outbound, or tenant-impact evidence.

‍ ‍

Detection Logic

‍ ‍

·        Identify requests to hosting-control administrative paths from web, proxy, or application access telemetry.

‍ ‍

·        Evaluate whether administrative path access aligns with expected authentication success, session creation, approved administrator source, or known support workflow.

‍ ‍

·        Prioritize access to privileged control-panel paths from unfamiliar source infrastructure, unexpected user identity, unusual user agent, abnormal access window, or missing expected authentication/session context.

‍ ‍

·        Treat exposed asset state and patch validation as prioritization context, not the only alert condition.

‍ ‍

·        Do not classify scan-only activity as probable compromise or confirmed compromise without stronger supporting evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Web or application access telemetry.

‍ ‍

·        Authentication logs.

‍ ‍

·        Session logs where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination host.

‍ ‍

·        URL path.

‍ ‍

·        HTTP method where available.

‍ ‍

·        User agent where available.

‍ ‍

·        User identity where available.

‍ ‍

·        Session identifier where available.

‍ ‍

·        Authentication result where available.

‍ ‍

·        Host or asset exposure context where available.

‍ ‍

·        Approved administrator source context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Elastic index patterns and field names for URL path, source IP, destination host, user identity, session identifier, user agent, authentication result, event action, event category, and timestamp before deployment.

‍ ‍

·        Scope to known cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Normalize host identity across access logs, authentication logs, session logs, endpoint events, and asset inventory.

‍ ‍

·        Maintain exception lists for approved administrator source ranges, hosting-provider support ranges, reseller administration ranges, monitoring systems, and vulnerability scanners.

‍ ‍

·        Use exposed asset state and patch status as prioritization context.

‍ ‍

·        Correlate output with endpoint process activity, account changes, hosted-content modification, DNS activity, proxy activity, and outbound communication.

‍ ‍

·        Do not escalate to confirmed compromise unless post-access behavior is present.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.5 / 10

‍ ‍

·        The rule is behaviorally anchored to administrative access and authentication-flow mismatch rather than static exploit matching.

‍ ‍

·        The rule remains useful if exploit request formatting, source infrastructure, user agent, scanner name, or public proof-of-concept content changes.

‍ ‍

·        The score is supported by its focus on a primary unauthorized-access behavior class.

‍ ‍

·        The score is constrained by authentication and session telemetry availability, field normalization, and administrator baseline quality.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.0 / 10

‍ ‍

·        Operational confidence depends on ingestion of control-panel access logs, authentication logs, session context, asset context, user identity, source IP, and timestamp fidelity.

‍ ‍

·        Operational confidence is reduced where session telemetry is incomplete, web logs are not normalized, or administrator and support activity is poorly baselined.

‍ ‍

·        Full-telemetry confidence improves when access, authentication, session, exposure, and administrator baseline context are normalized in Elastic.

‍ ‍

·        Even under full telemetry conditions, this rule requires post-access evidence before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious access-flow conditions, not confirmed exploitation.

‍ ‍

·        Missing authentication or session telemetry reduces confidence.

‍ ‍

·        Legitimate support, reseller administration, monitoring, vulnerability scanning, emergency access, migration, or patch validation activity may overlap with suspicious access patterns.

‍ ‍

·        Confirmation requires correlation with endpoint execution, account modification, hosted-content change, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

event.category : "web"
and host.name : ($HOSTING_CONTROL_PLANE_ASSETS)
and url.path : (
  "/cpanel*",
  "/whm*",
  "/webmail*",
  "/json-api*",
  "/cpsess*"
)
and not source.ip : ($APPROVED_ADMIN_SOURCES)
and not event.action : (
  "authentication_success",
  "session_created",
  "approved_support_access"
)

‍ ‍

Rule 2

‍ ‍

Hosting-Control Process Spawns Shell or Administrative Tooling

‍ ‍

Rule Format

‍ ‍

Elastic EQL process pattern suitable for Elastic Security after endpoint, field, exception-list, and index validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect hosting-control, web-service, mail-service, backup, account-management, or related service processes spawning shells, interpreters, administrative utilities, package tools, service-control commands, or staging utilities.

‍ ‍

·        Identify endpoint-observable post-access behavior that may follow unauthorized control-plane access without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success or control-panel session legitimacy.

‍ ‍

Detection Logic

‍ ‍

·        Identify Linux process creation where the parent process is associated with hosting-control, web-service, mail-service, backup, account-management, or related service context.

‍ ‍

·        Prioritize child processes associated with shell execution, scripting, account administration, package activity, service control, archive staging, or outbound retrieval.

‍ ‍

·        Treat events as higher confidence when the host is a known exposed hosting-control-plane asset or when activity follows abnormal control-panel access, suspicious session behavior, account modification, hosted-content modification, or suspicious outbound communication.

‍ ‍

·        Suppress approved maintenance, patching, backup, migration, monitoring, support, and automation workflows only when parent process, command line, execution user, host role, and time window are validated.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating authentication/session, account, file-system, outbound communication, or tenant-impact evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Elastic Defend or equivalent Linux process telemetry.

‍ ‍

·        Process parent name.

‍ ‍

·        Process name.

‍ ‍

·        Process command line.

‍ ‍

·        Process executable path.

‍ ‍

·        User name.

‍ ‍

·        Effective user where available.

‍ ‍

·        Host identity.

‍ ‍

·        Host role or asset context.

‍ ‍

·        Exposed hosting-control-plane asset context where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Elastic index patterns and field names for process parent, process name, command line, user, host identity, operating system, event type, event category, and timestamp before deployment.

‍ ‍

·        Scope to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Tune parent-process names and service paths to the customer’s actual hosting-control, web-service, mail-service, backup, and account-management processes.

‍ ‍

·        Add exceptions for approved patching, package management, backup, migration, monitoring, vulnerability scanning, hosting-provider support, reseller administration, and automation workflows.

‍ ‍

·        Treat exposed hosting-control-plane status as prioritization context, not as the only alert condition.

‍ ‍

·        Use follow-on account modification, hosted-content modification, suspicious outbound communication, or persistence-relevant activity as triage evidence.

‍ ‍

·        Route alerts with exposed hosting-control-plane context, abnormal access context, or tenant-impact context at higher priority.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious service-context execution rather than static exploit or artifact matching.

‍ ‍

·        The rule remains useful if public proof-of-concept code changes request formatting, user agent, source infrastructure, scanner name, or payload structure.

‍ ‍

·        The score is supported by durable post-access behavior observable through endpoint process telemetry.

‍ ‍

·        The score is constrained by legitimate maintenance, patching, backup, migration, support, and automation workflow overlap.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

·        Operational confidence depends on Elastic endpoint coverage, process ancestry fidelity, command-line capture, user context, host role context, and maintenance baseline quality.

‍ ‍

·        Operational confidence is reduced where process lineage is incomplete, command-line capture is inconsistent, or hosting-provider workflows are poorly baselined.

‍ ‍

·        Full-telemetry confidence improves when Elastic endpoint data is enriched with exposed asset state, control-panel access context, authentication/session context, file-system activity, and outbound network context.

‍ ‍

·        Even under full telemetry conditions, this rule requires correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious post-access execution behavior, not the original authentication-bypass event.

‍ ‍

·        Legitimate cPanel or WHM maintenance, package updates, backups, migrations, monitoring, support, and reseller administration may overlap with this behavior.

‍ ‍

·        This rule requires process lineage, command-line visibility, endpoint coverage, and server role scoping to remain reliable.

‍ ‍

·        Confirmation requires correlation with suspicious control-panel access, authentication/session anomalies, account modification, hosted-content modification, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

process where host.os.type == "linux"
  and event.type == "start"
  and process.parent.name in (
    "cpsrvd", "cpaneld", "whostmgrd", "httpd", "apache2",
    "litespeed", "nginx", "php-fpm", "exim", "dovecot", "cron"
  )
  and process.name in (
    "sh", "bash", "dash", "zsh", "python", "python3", "perl", "php",
    "curl", "wget", "nc", "ncat", "socat", "useradd", "usermod",
    "passwd", "chpasswd", "yum", "dnf", "apt", "rpm", "systemctl",
    "service", "crontab", "tar", "zip", "gzip", "openssl"
  )
  and not process.command_line like (
    "*/scripts/upcp*",
    "*/usr/local/cpanel/scripts/*",
    "*cpbackup*",
    "*backup*",
    "*yum update*",
    "*dnf update*",
    "*apt update*",
    "*apt upgrade*"
  )

‍ ‍

Rule 3

‍ ‍

Suspicious Hosted-Content Modification After Hosting-Control Service Activity

‍ ‍

Rule Format

‍ ‍

Elastic EQL sequence pattern suitable for Elastic Security after endpoint, file, field, exception-list, and index validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious hosted-content modification following hosting-control, web-service, mail-service, backup, account-management, shell, or interpreter activity on a hosting-control server.

‍ ‍

·        Identify probable compromise conditions where service-context activity is followed by tenant-impacting file modification, suspicious script placement, archive staging, writable-path abuse, or persistence-relevant file activity.

‍ ‍

·        This rule does not prove exploitation without corroborating telemetry and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

Detection Logic

‍ ‍

·        Identify suspicious service-context process activity on a hosting-control server.

‍ ‍

·        Correlate that activity with hosted-content, webroot, temporary-path, cron-path, SSH-key-path, or persistence-relevant file modification on the same host within a bounded time window.

‍ ‍

·        Prioritize file changes affecting hosted directories, customer webroots, script-like files, hidden files, writable staging paths, archive staging, cron locations, SSH key paths, or repeated file activity across hosted accounts.

‍ ‍

·        Treat multi-account or multi-tenant file modification as higher priority than isolated single-file modification.

‍ ‍

·        Do not classify activity as confirmed compromise without validation that the file activity is unauthorized and not part of approved customer updates, CMS updates, backups, migrations, support, or deployment automation.

‍ ‍

Required Telemetry

‍ ‍

·        Elastic endpoint process telemetry.

‍ ‍

·        File creation or modification telemetry.

‍ ‍

·        Host identity.

‍ ‍

·        Process parent name.

‍ ‍

·        Process name.

‍ ‍

·        Process command line where available.

‍ ‍

·        File path.

‍ ‍

·        File extension where available.

‍ ‍

·        File owner or user context where available.

‍ ‍

·        Tenant or hosted-path context where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Elastic index patterns and field names for endpoint process events, file events, host identity, process parent, process name, command line, file path, file event type, user context, tenant mapping, exception lists, and timestamps before deployment.

‍ ‍

·        Scope to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Normalize host identity across endpoint and file events.

‍ ‍

·        Validate local hosted-content paths, webroot paths, tenant directory structures, temporary paths, cron paths, SSH key paths, and service-relevant paths before deployment.

‍ ‍

·        Maintain exception lists for approved customer updates, CMS updates, patching, backups, migrations, certificate renewal, hosting-provider support, reseller administration, and deployment automation.

‍ ‍

·        Tune hosted paths to customer-specific hosting layouts rather than excluding broad webroot coverage.

‍ ‍

·        Do not require Rule 1 or Rule 2 to fire before this rule can evaluate its own telemetry.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious service-context activity followed by hosted-content or persistence-relevant file modification.

‍ ‍

·        The rule remains useful if attackers modify exploit request format, source infrastructure, user agent, scanner name, file names, extensions, or payload structure.

‍ ‍

·        The score is supported by correlation between service-context activity and downstream file behavior that can reflect tenant impact or persistence.

‍ ‍

·        The score is constrained by dependence on file telemetry, tenant mapping, hosted-path validation, and operational baselines.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on endpoint coverage, file-event visibility, host identity normalization, tenant mapping, hosted-path context, and operational baseline quality.

‍ ‍

·        Operational confidence is reduced where tenant mapping is incomplete, file telemetry is limited, or customer update workflows create high background activity.

‍ ‍

·        Full-telemetry confidence improves when endpoint, file, tenant, exposure, and operational context are normalized in Elastic.

‍ ‍

·        Even under full telemetry conditions, this rule requires validation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious post-access hosted-content or persistence-relevant file activity, not the original authentication-bypass mechanism.

‍ ‍

·        Legitimate customer updates, CMS changes, migrations, backups, certificate renewal, support, reseller administration, and deployment automation may overlap with this behavior.

‍ ‍

·        Missing tenant mapping can weaken blast-radius assessment.

‍ ‍

·        Missing file-event visibility can reduce confidence in hosted-content modification findings.

‍ ‍

·        Confirmation requires correlation with unauthorized access, suspicious execution, webshell evidence, account change, outbound behavior, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

sequence by host.name with maxspan=2h
  [process where host.os.type == "linux"
    and event.type == "start"
    and process.parent.name in (
      "cpsrvd", "cpaneld", "whostmgrd", "httpd", "apache2",
      "litespeed", "nginx", "php-fpm", "exim", "dovecot", "cron"
    )
    and process.name in (
      "sh", "bash", "dash", "zsh", "python", "python3", "perl", "php",
      "curl", "wget", "nc", "ncat", "socat", "tar", "zip", "gzip"
    )
  ]
  [file where host.os.type == "linux"
    and event.type in ("creation", "change")
    and file.path regex~ """.*(/home/|/public_html/|/www/|/var/www/|/usr/local/apache/htdocs/|/tmp/|/var/tmp/|/dev/shm/|/etc/cron|/var/spool/cron|/.ssh/authorized_keys).*"""
  ]

‍ ‍Rule 4

Hosting-Control or Shared-Hosting Foothold Followed by Privileged Server-Side Activity

Rule Format

Elastic EQL sequence pattern suitable for Elastic Security after endpoint, file, network, field, exception-list, value-list, enrichment-policy, transform, and index validation.

Detection Purpose

Detect suspicious hosting-control, FTP, web-accessible hosted-path, tenant-path, or LiteSpeed plugin-adjacent activity followed by server-side execution, root-context behavior, account modification, service or cron change, hosted-content tampering, archive staging, credential-file access, suspicious outbound retrieval, or network transfer behavior on affected hosting infrastructure.

This rule is intended to identify probable compromise conditions where web server, FTP, hosting-control, CloudLinux/CageFS tenant-path, or LiteSpeed plugin-adjacent activity is followed by behavior that may indicate shared-hosting privilege escalation, hosted-content impact, credential exposure, persistence-like change, outbound abuse, or tenant-impacting activity.

This rule does not prove exploitation without corroborating telemetry and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, user agents, webshell filenames, symlink paths, or one exploit implementation.

Detection Logic

Trigger when suspicious activity associated with hosting-control services, FTP services, web server processes, hosted paths, CloudLinux/CageFS tenant paths, or LiteSpeed plugin-adjacent paths is followed by privileged server-side activity, suspicious file impact, or suspicious outbound behavior on the same host within a bounded investigation window.

Require both conditions within a bounded investigation window:

·        Endpoint, file, web, FTP, hosting-control, or network telemetry shows possible unauthorized access, tenant foothold activity, webshell interaction, suspicious hosted-path access, unusual file upload, suspicious script execution, plugin-adjacent file activity, symlink-sensitive path activity, abnormal FTP activity, suspicious web access, or activity outside approved administrator, reseller, customer, support, maintenance, scanner, monitoring, and vulnerability-management baselines.

·        The same host, effective user, service account, process lineage, working directory, webroot, tenant path, plugin path, FTP path, control-panel account, FTP account, tenant, reseller, domain, or hosting-control-adjacent context then shows unusual shell execution, scripting activity, privilege-sensitive command use, root-context process behavior, account modification, service or cron change, suspicious file write, hosted-content tampering, symlink or permission anomaly, archive staging, credential-file access, outbound retrieval, or network transfer behavior outside approved support, patching, backup, migration, plugin update, customer maintenance, and incident-response workflows.

Increase priority when activity involves cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, customer-facing web, DNS, mail, database, backup, ecommerce, customer portal, or high-value hosted application infrastructure.

Increase priority when the correlated activity includes webshell evidence, hosted-content modification, symlink or permission anomalies, root-owned file changes, DNS or mail manipulation, abuse reports, customer tickets, phishing reports, malware reports, spam reports, blocklist entries, tenant-impact evidence, or post-remediation recurrence.

Do not treat web server activity, FTP use, customer file uploads, plugin updates, CMS updates, command-line administration, backup jobs, package updates, single symlink events, single file writes, single outbound connections, scanner traffic, or vulnerable-version findings alone as confirmed compromise. Require access-to-impact correlation and local telemetry enrichment before escalating as probable hosting-control compromise, shared-hosting escalation, tenant-boundary failure, or customer-impacting abuse.

Required Telemetry

·        Elastic endpoint process telemetry from managed hosting servers, shared-hosting servers, reseller-hosting servers, cPanel servers, WHM servers, DNSOnly servers, WP Squared systems, LiteSpeed cPanel Plugin systems, LiteSpeed WHM Plugin systems, CloudLinux/CageFS systems, web servers, FTP servers, DNS servers, mail servers, database servers, backup servers, and customer-facing hosted application servers.

·        File creation, modification, deletion, ownership, permission, symlink, and hosted-content telemetry where available.

·        Network telemetry from Elastic Agent, Elastic Defend, packet, proxy, DNS, firewall, WAF, CDN, NDR, or locally normalized network sources where available.

·        Web access, FTP, control-panel, DNS-administration, mail, abuse-report, customer-support, backup, CloudLinux/CageFS, and incident-response enrichment where available.

·        Normalized fields for host identity, host role, user, effective user where available, process name, parent process name, command line, executable path, working directory, file path, file extension, file owner, file permission, symlink target where available, source IP, destination domain, destination IP, URL path, HTTP method, user agent, FTP account, FTP operation, control-panel account, tenant, reseller, domain, webroot, plugin path, action, index, dataset, timestamp, and remediation context.

·        Elastic value lists, exception lists, data views, transforms, enrichment policies, ingest-pipeline fields, or runtime fields for hosting endpoints, shared-hosting endpoints, reseller-hosting endpoints, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, web server endpoints, FTP server endpoints, DNS server endpoints, mail server endpoints, database servers, backup servers, customer-facing hosted applications, high-value hosting endpoints, hosted domains, customer webroots, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, tenant mappings, reseller mappings, approved administrators, approved support users, approved service accounts, approved support sources, approved scanners, approved monitoring sources, approved backup destinations, approved CDN providers, approved mail relays, approved package repositories, approved maintenance windows, approved incident-response workflows, and exception groups.

Engineering Implementation Instructions

Create and validate Elastic data views, index patterns, event.dataset mappings, and field aliases for endpoint process events, file events, network events, web access events, FTP events, control-panel events, DNS and mail events, abuse-support events, asset-enrichment events, tenant-enrichment events, reseller-enrichment events, and post-remediation activity. These mappings should hide customer-specific index names, integration names, vendor connectors, Elastic Agent policies, and ECS or non-ECS field differences from the detection logic.

Create and validate Elastic value lists, exception lists, enrichment policies, transforms, ingest-pipeline fields, or runtime fields for ENV_HOSTING_ENDPOINTS, ENV_HOSTING_SERVER_ENDPOINTS, ENV_SHARED_HOSTING_ENDPOINTS, ENV_RESELLER_HOSTING_ENDPOINTS, ENV_CPANEL_ENDPOINTS, ENV_WHM_ENDPOINTS, ENV_DNSONLY_ENDPOINTS, ENV_WP_SQUARED_ENDPOINTS, ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS, ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS, ENV_CLOUDLINUX_CAGEFS_ENDPOINTS, ENV_WEB_SERVER_ENDPOINTS, ENV_FTP_SERVER_ENDPOINTS, ENV_DNS_SERVER_ENDPOINTS, ENV_MAIL_SERVER_ENDPOINTS, ENV_DATABASE_SERVER_ENDPOINTS, ENV_BACKUP_SERVER_ENDPOINTS, ENV_CUSTOMER_FACING_HOSTED_APP_ENDPOINTS, ENV_HIGH_VALUE_HOSTING_ENDPOINTS, ENV_HOSTED_DOMAINS, ENV_CUSTOMER_WEBROOTS, ENV_FTP_UPLOAD_PATHS, ENV_LITESPEED_PLUGIN_PATHS, ENV_CLOUDLINUX_CAGEFS_TENANT_PATHS, ENV_TENANT_MAPPINGS, ENV_RESELLER_MAPPINGS, ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS, ENV_APPROVED_SERVICE_ACCOUNTS, ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES, ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES, ENV_APPROVED_BACKUP_CDN_PACKAGE_MAIL_OR_MONITORING_DESTINATIONS, ENV_APPROVED_SUPPORT_BACKUP_MIGRATION_PLUGIN_UPDATE_OR_CUSTOMER_MAINTENANCE_WINDOWS, and ENV_HOSTING_EXCEPTION_GROUPS.

The engineer or admin must map local Elastic fields to the rule placeholders before deployment. At minimum, validate local fields for host.name, host.id, host.os.type, host.ip, user.name, user.id, process.name, process.parent.name, process.command_line, process.executable, process.working_directory, process.entity_id, process.parent.entity_id where available, file.path, file.extension, file.owner, file.group, file.mode, file.target_path where available, event.category, event.type, event.action, source.ip, destination.domain, destination.ip, url.path, http.request.method, user_agent.original, related.user, related.hosts, tenant, reseller, domain, webroot, plugin path, event.dataset, event.module, @timestamp, and remediation context.

The engineer or admin must create customer-specific mappings for webroots, tenant paths, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, backup paths, database paths, mail paths, temporary paths, webshell candidate paths, symlink-sensitive paths, and control-panel-adjacent paths. These mappings must distinguish expected customer maintenance from suspicious cross-tenant, plugin-adjacent, symlink-sensitive, root-context, or hosted-content tampering behavior.

The engineer or admin must configure command, path, process, destination, and behavior matching through Elastic value lists, exception lists, regex conditions, wildcard conditions, precomputed transform fields, ingest-pipeline fields, or enrichment-policy output fields before deployment. Do not assume exact keyword matching will identify command-line substrings, path fragments, webroot patterns, plugin paths, suspicious hosted-content patterns, credential-file paths, symlink-sensitive paths, or rare destination categories. If wildcard or regex evaluation is too expensive in the local Elastic environment, precompute candidate fields or normalized flags through transforms, ingest pipelines, or scheduled enrichment before alerting.

The engineer or admin must define approved local baselines for hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. These baselines must feed exception lists, rule exceptions, risk-score adjustment, investigation guidance, and alert suppression before the rule is promoted from hunt mode to alert mode.

The engineer or admin must validate the correlation model before deployment. The EQL pattern correlates by host.name because this is the most broadly deployable Elastic Security sequence key. Local enrichment should add host.id, process.entity_id, process.parent.entity_id, webroot, tenant, reseller, domain, FTP account, control-panel account, source IP, destination domain, and workload identity where available. If user.name is missing or generic, such as root, apache, nginx, nobody, cpanel, www-data, FTP service, web server, or support service context, triage must rely on host identity, process lineage, file path, tenant mapping, webroot mapping, and downstream correlation rather than user identity alone.

Validate query performance against candidate indices before production alerting. Use Elastic transforms, event enrichment, runtime fields, data-stream filtering, and index-level scoping to reduce high-volume endpoint, file, web, FTP, proxy, DNS, WAF, CDN, and NDR searches. Avoid broad cross-index correlation without bounded time windows, host scoping, asset scoping, and exception-list validation.

Deploy initially in hunt mode for at least one business cycle that includes hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. Promote to alert mode only after field mappings, data views, index scoping, value lists, exception lists, enrichment policies, transform logic, wildcard or regex match handling, correlation behavior, query performance, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has strong detection relevance because hosting-control compromise and shared-hosting privilege escalation become materially actionable when suspicious hosted-path, FTP, web server, hosting-control, or plugin-adjacent activity is followed by shell execution, root-context behavior, account modification, file-system impact, hosted-content tampering, outbound tooling, abuse-report evidence, or persistence-like change. It is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on access-to-execution and access-to-impact behavior rather than static indicators.

DRI

8.5

TCR Assessment

Operational telemetry confidence depends on Elastic access to endpoint process telemetry, file telemetry, web logs, FTP logs, control-panel logs, DNS and mail logs, network telemetry, host-role tagging, tenant mapping, reseller mapping, webroot mapping, plugin-path mapping, normalized field mappings, wildcard or regex handling, enrichment policies, transforms, and baseline exceptions. Confidence is reduced where endpoint coverage is missing from hosting servers, command-line capture is incomplete, webroot and plugin paths are not mapped, CloudLinux/CageFS tenant context is unavailable, generic service-account activity cannot be correlated, or routine hosting workflows are poorly baselined.

Operational TCR

8.0

Full-Telemetry TCR

9.0

Limitations

This rule may produce false positives from legitimate hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, database maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response work, and approved incident-response cleanup. The rule cannot independently confirm cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, tenant-spanning access, or customer data exposure without hosting-control, FTP, web, file, symlink, DNS, mail, NDR, tenant-mapping, and abuse-report correlation. It should not attribute activity to any named actor, scanner, webshell family, or exploit kit without separate validated intelligence. Query performance depends on local index strategy, ECS normalization, enrichment policies, transforms, exception-list hygiene, wildcard or regex match handling, bounded time windows, and avoiding unscoped high-volume cross-index correlation.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic Security environments that support endpoint process telemetry, file telemetry, network telemetry, web logs, FTP logs, control-panel logs, DNS, mail, proxy, WAF, CDN, NDR, asset enrichment, tenant enrichment, reseller enrichment, transforms, and exception lists. Customer-specific index patterns, data streams, field names, value lists, exception lists, enrichment fields, runtime fields, transforms, and local asset groups must be validated before deployment.

sequence by host.name with maxspan=2h
[any where host.os.type == "linux"
and event.category in ("process", "file", "web", "network")
and (
host.name in (ENV_HOSTING_ENDPOINTS)
or host.name in (ENV_SHARED_HOSTING_ENDPOINTS)
or host.name in (ENV_RESELLER_HOSTING_ENDPOINTS)
or host.name in (ENV_CPANEL_ENDPOINTS)
or host.name in (ENV_WHM_ENDPOINTS)
or host.name in (ENV_DNSONLY_ENDPOINTS)
or host.name in (ENV_WP_SQUARED_ENDPOINTS)
or host.name in (ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS)
or host.name in (ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS)
or host.name in (ENV_CLOUDLINUX_CAGEFS_ENDPOINTS)
or host.name in (ENV_HIGH_VALUE_HOSTING_ENDPOINTS)
)
and not user.name in (ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS)
and (
process.parent.name in (
"httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm",
"pure-ftpd", "proftpd", "cpanel", "whostmgrd", "cpdavd", "cpsrvd"
)
or process.name in (
"httpd", "apache2", "nginx", "lshttpd", "php", "php-fpm",
"pure-ftpd", "proftpd", "cpanel", "whostmgrd", "cpdavd", "cpsrvd"
)
or file.path : (
"/home//public_html/",
"/home//www/",
"/home//tmp/",
"/home//.ssh/",
"/var/www/",
"/usr/local/apache/htdocs/",
"/tmp/",
"/var/tmp/",
"/dev/shm/",
"/usr/local/lsws/",
"/usr/local/cpanel/",
"/var/cpanel/"
)
or url.path : (
"upload",
"tmp",
"cache",
"plugin",
"wp-content",
"public_html",
"cgi-bin"
)
or source.ip not in (ENV_APPROVED_ADMIN_SUPPORT_CUSTOMER_OR_SCANNER_SOURCES)
)
]
[any where host.os.type == "linux"
and event.category in ("process", "file", "network")
and (
host.name in (ENV_HOSTING_ENDPOINTS)
or host.name in (ENV_SHARED_HOSTING_ENDPOINTS)
or host.name in (ENV_RESELLER_HOSTING_ENDPOINTS)
or host.name in (ENV_CPANEL_ENDPOINTS)
or host.name in (ENV_WHM_ENDPOINTS)
or host.name in (ENV_DNSONLY_ENDPOINTS)
or host.name in (ENV_WP_SQUARED_ENDPOINTS)
or host.name in (ENV_LITESPEED_CPANEL_PLUGIN_ENDPOINTS)
or host.name in (ENV_LITESPEED_WHM_PLUGIN_ENDPOINTS)
or host.name in (ENV_CLOUDLINUX_CAGEFS_ENDPOINTS)
or host.name in (ENV_HIGH_VALUE_HOSTING_ENDPOINTS)
)
and not user.name in (ENV_APPROVED_HOSTING_ADMIN_OR_SUPPORT_USERS)
and not process.name in (ENV_APPROVED_HOSTING_CONTROL_WEB_FTP_BACKUP_OR_MAINTENANCE_PROCESSES)
and (
process.name in (
"sh", "bash", "dash", "zsh", "python", "python3", "perl", "php",
"php-fpm", "curl", "wget", "nc", "ncat", "socat", "tar", "gzip",
"zip", "mysqldump", "mysql", "crontab", "chmod", "chown", "useradd",
"usermod", "passwd", "systemctl", "service"
)
or process.command_line : (
"chmod",
"chown",
"crontab",
"useradd",
"usermod",
"passwd",
"authorized_keys",
"shadow",
"wp-config.php",
"configuration.php",
"database.php",
"tar ",
"zip ",
"mysqldump",
"curl ",
"wget "
)
or file.path : (
"/home//public_html/.php",
"/home//public_html/.phtml",
"/home//public_html/.php",
"/home//public_html/.",
"/home//www/.php",
"/var/www/.php",
"/tmp/.php",
"/var/tmp/.php",
"/dev/shm/",
"/etc/cron",
"/var/spool/cron/",
"/home//.ssh/authorized_keys",
"/usr/local/lsws/",
"/usr/local/cpanel/",
"/var/cpanel/*"
)
or destination.domain in (ENV_RARE_SUSPICIOUS_OR_NEWLY_OBSERVED_DESTINATIONS)
)
]

QRadar

‍ ‍

Detection Viability Assessment

‍ ‍

QRadar has three rules for this EXP report.

‍ ‍

·        QRadar is viable for correlation across control-panel access, authentication or session telemetry, endpoint process events, account activity, file events, DNS, proxy, and outbound network telemetry when log sources are normalized into reliable custom properties.

‍ ‍

·        QRadar is strongest for event-correlation use cases where exposed hosting-control-plane access can be connected to post-access behavior on the same host, source, user, or time window.

‍ ‍

·        QRadar is not a primary sensor by itself; rule quality depends on log source onboarding, custom property extraction, event normalization, reference sets, and offense tuning.

‍ ‍

Rule 1

‍ ‍

Control-Panel Access with Authentication or Session Mismatch

‍ ‍

Rule Format

‍ ‍

QRadar AQL and CRE correlation pattern suitable for deployment after log source, custom property, reference set, and offense rule validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect access to cPanel, WHM, WP Squared, or related hosting-control administrative paths where access activity does not align with expected authentication or session behavior.

‍ ‍

·        Identify suspected unauthorized access conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm compromise without post-access endpoint, account, file, outbound, or tenant-impact evidence.

‍ ‍

Detection Logic

‍ ‍

·        Identify requests to hosting-control administrative paths from web, proxy, or application access telemetry.

‍ ‍

·        Compare administrative path access against authentication success, session creation, approved administrator source, or known support workflow.

‍ ‍

·        Prioritize access to privileged control-panel paths from unfamiliar source infrastructure, unexpected user identity, unusual user agent, abnormal access window, or missing expected authentication/session context.

‍ ‍

·        Treat exposed asset state and patch validation as prioritization context, not the only alert condition.

‍ ‍

·        Do not classify scan-only activity as probable compromise or confirmed compromise without stronger supporting evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Control-panel access logs.

‍ ‍

·        Authentication logs.

‍ ‍

·        Session logs where available.

‍ ‍

·        Source IP.

‍ ‍

·        Destination host.

‍ ‍

·        Request path.

‍ ‍

·        HTTP method where available.

‍ ‍

·        User agent where available.

‍ ‍

·        User identity where available.

‍ ‍

·        Session identifier where available.

‍ ‍

·        Authentication result where available.

‍ ‍

·        Host or asset exposure context where available.

‍ ‍

·        Approved administrator source context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate QRadar log sources for cPanel, WHM, WP Squared, web access, proxy, authentication, and session telemetry before deployment.

‍ ‍

·        Validate custom properties for request path, source IP, destination host, user identity, session identifier, user agent, authentication result, event name, and timestamp.

‍ ‍

·        Scope the rule to known cPanel, WHM, WP Squared, or related hosting-control systems through reference sets or asset profiles.

‍ ‍

·        Maintain reference sets for approved administrator source ranges, hosting-provider support ranges, reseller administration ranges, monitoring systems, vulnerability scanners, and exposed hosting-control-plane assets.

‍ ‍

·        Use asset exposure and patch status as prioritization context.

‍ ‍

·        Route resulting offenses for correlation with endpoint process activity, account changes, hosted-content modification, DNS/proxy activity, and outbound communication.

‍ ‍

·        Do not escalate to confirmed compromise unless post-access behavior is present.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.5 / 10

‍ ‍

·        The rule is behaviorally anchored to authentication or session mismatch rather than static exploit strings or known indicators.

‍ ‍

·        The rule remains useful if exploit request formatting, source infrastructure, user agent, scanner name, or public proof-of-concept content changes.

‍ ‍

·        The score is supported by its focus on a primary unauthorized-access behavior class.

‍ ‍

·        The score is constrained by custom property quality, session telemetry availability, timestamp alignment, and administrator baseline quality.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.0 / 10

‍ ‍

·        Operational confidence depends on control-panel access logs, authentication logs, session context, QRadar custom property extraction, asset scoping, source identity, and timestamp fidelity.

‍ ‍

·        Operational confidence is reduced where session telemetry is incomplete, custom properties are inconsistent, or support and reseller activity are not baselined.

‍ ‍

·        Full-telemetry confidence improves when access, authentication, session, exposure, and administrator baseline context are normalized into QRadar custom properties and reference sets.

‍ ‍

·        Even under full telemetry conditions, this rule requires post-access evidence before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious access-flow conditions, not confirmed exploitation.

‍ ‍

·        Missing authentication or session telemetry reduces confidence.

‍ ‍

·        Weak custom property extraction can cause missed matches or incorrect offense grouping.

‍ ‍

·        Legitimate support, reseller administration, monitoring, vulnerability scanning, emergency access, migration, or patch validation activity may overlap with suspicious access patterns.

‍ ‍

·        Confirmation requires correlation with endpoint execution, account modification, hosted-content change, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

SELECT
  "startTime",
  "sourceIP",
  "destinationIP",
  "destinationHostName",
  "username",
  "requestPath",
  "httpMethod",
  "userAgent",
  "sessionId",
  "eventName"
FROM events
WHERE
  REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "destinationIP")
  AND NOT REFERENCESETCONTAINS('Approved_Admin_Sources', "sourceIP")
  AND LOGSOURCETYPENAME(logSourceTypeId) IN (
    'cPanel Access',
    'WHM Access',
    'Web Access Logs',
    'Proxy Logs',
    'Hosting Control Logs'
  )
  AND (
    "requestPath" ILIKE '/cpanel%'
    OR "requestPath" ILIKE '/whm%'
    OR "requestPath" ILIKE '/webmail%'
    OR "requestPath" ILIKE '/json-api%'
    OR "requestPath" ILIKE '/cpsess%'
  )
  AND NOT (
    "eventName" ILIKE '%authentication_success%'
    OR "eventName" ILIKE '%session_created%'
    OR "eventName" ILIKE '%approved_support_access%'
  )
LAST 10 MINUTES

‍ ‍

Rule 2

‍ ‍

Suspicious Control-Plane Access Followed by Post-Access Behavior

‍ ‍

Rule Format

‍ ‍

QRadar CRE correlation pattern supported by normalized AQL building blocks after log source, custom property, reference set, and offense rule validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious control-plane access followed by privileged execution, account modification, hosted-content modification, DNS change, suspicious outbound activity, or other post-access behavior.

‍ ‍

·        Identify probable compromise conditions where administrative access anomalies are followed by host, account, file, tenant, or network behavior.

‍ ‍

·        This rule does not require another detection rule’s alert output and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

Detection Logic

‍ ‍

·        Identify suspicious access to hosting-control administrative paths from unapproved or unfamiliar sources.

‍ ‍

·        Correlate access activity with endpoint process telemetry, account-change events, administrative action logs, file modification events, DNS/proxy events, or outbound network telemetry on the same host within a bounded time window.

‍ ‍

·        Prioritize post-access activity involving shell execution, administrative utility use, account changes, service changes, hosted-content modification, script placement, archive staging, DNS changes, or outbound communication inconsistent with normal server behavior.

‍ ‍

·        For outbound telemetry, evaluate the hosting-control asset as the source or local host and treat remote IP, destination IP, or destination domain as the external destination.

‍ ‍

·        Classify as confirmed compromise only when corroborating evidence shows unauthorized access plus post-access behavior that cannot be explained by approved maintenance, support, patching, backup, migration, customer update, reseller activity, or automation.

‍ ‍

Required Telemetry

‍ ‍

·        Control-panel access logs.

‍ ‍

·        Endpoint process telemetry.

‍ ‍

·        Account-change telemetry.

‍ ‍

·        Administrative action logs where available.

‍ ‍

·        File creation or modification telemetry.

‍ ‍

·        DNS logs where available.

‍ ‍

·        Proxy or network logs where available.

‍ ‍

·        Source IP.

‍ ‍

·        Source host.

‍ ‍

·        Destination host.

‍ ‍

·        Request path.

‍ ‍

·        Process name.

‍ ‍

·        Command line.

‍ ‍

·        Account action.

‍ ‍

·        File path.

‍ ‍

·        Destination domain or IP.

‍ ‍

·        Remote IP.

‍ ‍

·        Host identity.

‍ ‍

·        Asset exposure context.

‍ ‍

·        Maintenance or automation context.

‍ ‍

·        Timestamp normalization.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate QRadar log sources for control-panel access, endpoint process telemetry, Linux account activity, administrative actions, file events, DNS, proxy, firewall, and network events before deployment.

‍ ‍

·        Validate custom properties for request path, source IP, source hostname, destination IP, destination hostname, process name, command line, account action, file path, destination domain, remote IP, event name, username, and timestamp.

‍ ‍

·        Scope the rule to known cPanel, WHM, WP Squared, or related hosting-control systems through reference sets or asset profiles.

‍ ‍

·        Normalize host identity across control-panel access, endpoint, account, file, DNS, proxy, and network log sources.

‍ ‍

·        Maintain reference sets for approved administrator sources, support ranges, maintenance windows, update workflows, backup jobs, customer update workflows, reseller administration ranges, approved automation accounts, approved outbound destinations, and exposed hosting-control-plane assets.

‍ ‍

·        Use exposed asset state and patch validation as prioritization context, not as the only alert condition.

‍ ‍

·        Do not require Rule 1 to fire before this rule can evaluate telemetry.

‍ ‍

·        Suppress only validated operational workflows where source, user, command line, host role, destination, file path, or maintenance context matches expected behavior.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious administrative access followed by post-access host, account, file, tenant, or outbound behavior.

‍ ‍

·        The rule remains resilient if exploit format, public proof-of-concept content, source infrastructure, scanner names, or user agents change.

‍ ‍

·        The score is supported by correlation of access anomalies with durable post-access behavior.

‍ ‍

·        The score is constrained by custom property quality, host identity normalization, endpoint telemetry availability, tenant context, and operational allowlists.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on access log completeness, endpoint and account telemetry, file-event visibility, DNS/proxy coverage, QRadar custom property extraction, host identity normalization, and maintenance baseline quality.

‍ ‍

·        Operational confidence is reduced when endpoint telemetry is incomplete, account actions are not normalized, tenant mapping is missing, or support and maintenance workflows are not documented.

‍ ‍

·        Full-telemetry confidence improves when access, endpoint, account, file, DNS/proxy, network, exposure, and operational context are normalized into QRadar custom properties and reference sets.

‍ ‍

·        Even under full telemetry conditions, analyst or automated correlation must preserve separation between probable compromise and confirmed compromise.

‍ ‍

Limitations

‍ ‍

·        This rule does not prove the original authentication-bypass mechanism.

‍ ‍

·        Legitimate patching, package updates, support, backups, migrations, account provisioning, customer updates, DNS administration, reseller administration, and automation may overlap with the behavior.

‍ ‍

·        Weak custom property extraction or host normalization can produce missed correlations or incorrect offense grouping.

‍ ‍

·        Missing tenant mapping can weaken blast-radius assessment.

‍ ‍

·        Confirmation requires validation that the post-access behavior is unauthorized and not explained by approved operations.

‍ ‍

Detection Query Pattern

‍ ‍

-- Building Block A: Suspicious hosting-control access
SELECT
  "startTime",
  "sourceIP",
  "destinationIP",
  "destinationHostName",
  "username",
  "requestPath",
  "eventName"
FROM events
WHERE
  REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "destinationIP")
  AND NOT REFERENCESETCONTAINS('Approved_Admin_Sources', "sourceIP")
  AND LOGSOURCETYPENAME(logSourceTypeId) IN (
    'cPanel Access',
    'WHM Access',
    'Web Access Logs',
    'Proxy Logs',
    'Hosting Control Logs'
  )
  AND (
    "requestPath" ILIKE '/cpanel%'
    OR "requestPath" ILIKE '/whm%'
    OR "requestPath" ILIKE '/webmail%'
    OR "requestPath" ILIKE '/json-api%'
    OR "requestPath" ILIKE '/cpsess%'
  )
LAST 10 MINUTES;

-- Building Block B: Post-access behavior on hosting-control asset
SELECT
  "startTime",
  "sourceIP",
  "sourceHostName",
  "destinationIP",
  "destinationHostName",
  "username",
  "eventName",
  "processName",
  "commandLine",
  "accountAction",
  "filePath",
  "destinationDomain",
  "remoteIP"
FROM events
WHERE
  NOT REFERENCESETCONTAINS('Approved_Maintenance_Workflows', "sourceHostName")
  AND NOT REFERENCESETCONTAINS('Approved_Maintenance_Workflows', "destinationHostName")
  AND (
    (
      LOGSOURCETYPENAME(logSourceTypeId) IN (
        'Linux Process',
        'EDR Process',
        'SentinelOne Deep Visibility'
      )
      AND (
        REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "sourceIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "destinationIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "sourceHostName")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "destinationHostName")
      )
      AND (
        "processName" IN (
          'sh','bash','dash','zsh','python','python3','perl','php',
          'curl','wget','nc','ncat','socat','useradd','usermod',
          'passwd','chpasswd','yum','dnf','apt','rpm','systemctl',
          'service','crontab','tar','zip','gzip','openssl'
        )
        OR "commandLine" ILIKE '%useradd%'
        OR "commandLine" ILIKE '%usermod%'
        OR "commandLine" ILIKE '%passwd%'
        OR "commandLine" ILIKE '%crontab%'
        OR "commandLine" ILIKE '%systemctl%'
        OR "commandLine" ILIKE '%curl%'
        OR "commandLine" ILIKE '%wget%'
      )
    )
    OR (
      LOGSOURCETYPENAME(logSourceTypeId) IN (
        'Linux Account',
        'cPanel Admin Action',
        'WHM Admin Action',
        'Hosting Account Logs'
      )
      AND (
        REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "sourceIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "destinationIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "sourceHostName")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "destinationHostName")
      )
      AND (
        "accountAction" ILIKE '%user_create%'
        OR "accountAction" ILIKE '%password_reset%'
        OR "accountAction" ILIKE '%privilege%'
        OR "accountAction" ILIKE '%reseller%'
        OR "accountAction" ILIKE '%api_token%'
        OR "accountAction" ILIKE '%ssh_key%'
        OR "accountAction" ILIKE '%account_modify%'
      )
    )
    OR (
      LOGSOURCETYPENAME(logSourceTypeId) IN (
        'File Events',
        'Linux File Events',
        'EDR File Events'
      )
      AND (
        REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "sourceIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "destinationIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "sourceHostName")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "destinationHostName")
      )
      AND (
        "filePath" ILIKE '%/home/%'
        OR "filePath" ILIKE '%/public_html/%'
        OR "filePath" ILIKE '%/var/www/%'
        OR "filePath" ILIKE '%/usr/local/apache/htdocs/%'
        OR "filePath" ILIKE '%/tmp/%'
        OR "filePath" ILIKE '%/var/tmp/%'
        OR "filePath" ILIKE '%/dev/shm/%'
        OR "filePath" ILIKE '%/etc/cron%'
        OR "filePath" ILIKE '%/var/spool/cron%'
      )
    )
    OR (
      LOGSOURCETYPENAME(logSourceTypeId) IN (
        'DNS Logs',
        'Proxy Logs',
        'Firewall Logs',
        'Network Connection Logs'
      )
      AND (
        REFERENCESETCONTAINS('Hosting_Control_Plane_Assets', "sourceIP")
        OR REFERENCESETCONTAINS('Hosting_Control_Plane_Asset_Hostnames', "sourceHostName")
      )
      AND (
        "destinationDomain" IS NOT NULL
        OR "remoteIP" IS NOT NULL
        OR "destinationIP" IS NOT NULL
      )
      AND NOT REFERENCESETCONTAINS('Approved_Outbound_Destinations', "remoteIP")
      AND NOT REFERENCESETCONTAINS('Approved_Outbound_Destinations', "destinationIP")
    )
  )
LAST 120 MINUTES;

-- CRE correlation condition:
-- Trigger when Building Block B occurs on the same hosting-control asset as Building Block A within the configured correlation window.
-- For outbound telemetry, match the hosting-control asset as the source or local host and treat remoteIP, destinationIP, or destinationDomain as the external destination.

Rule 3

Hosting-Control or Shared-Hosting Foothold Followed by Privileged Server-Side Activity

Rule Format

QRadar CRE correlation rule with supporting AQL validation pattern suitable for deployment after log source, DSM parsing, custom property, reference set, reference map, building block, offense grouping, and rule-response validation.

Detection Purpose

Detect suspicious hosting-control, FTP, web-accessible hosted-path, tenant-path, or LiteSpeed plugin-adjacent activity followed by privileged server-side behavior, hosted-content modification, account or service change, symlink or permission anomaly, archive staging, credential-file access, suspicious outbound communication, or abuse-context evidence on affected hosting infrastructure.

This rule is intended to identify probable compromise conditions where hosting-control access, FTP activity, web access, CloudLinux/CageFS tenant-path activity, or LiteSpeed plugin-adjacent activity is followed by behavior that may indicate shared-hosting privilege escalation, hosted-content impact, credential exposure, persistence-like change, outbound abuse, or tenant-impacting activity.

This rule does not prove exploitation without corroborating telemetry and does not depend on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, user agents, webshell filenames, symlink paths, or one exploit implementation.

Detection Logic

Trigger when QRadar observes suspicious hosting-control, FTP, web, tenant-path, or plugin-adjacent activity against a known hosting asset and then observes privileged server-side activity, suspicious file impact, outbound communication, DNS or mail manipulation, abuse-report context, or post-remediation recurrence involving the same destination host, destination IP, hostname, tenant, reseller, domain, webroot, FTP account, control-panel account, source IP, or locally defined hosting incident key within a bounded investigation window.

Require both conditions within a bounded investigation window:

·        A suspicious hosting-access candidate is observed from hosting-control, FTP, web, file, or network telemetry. Candidate activity may include possible unauthorized access, tenant foothold activity, webshell interaction, suspicious hosted-path access, unusual file upload, suspicious script execution, plugin-adjacent file activity, symlink-sensitive path activity, abnormal FTP activity, suspicious web access, or access outside approved administrator, reseller, customer, support, maintenance, scanner, monitoring, and vulnerability-management baselines.

·        A suspicious server-impact candidate is observed against the same destination host, destination IP, hostname, tenant, reseller, domain, webroot, FTP account, control-panel account, source IP, or offense grouping context. Candidate activity may include unusual shell execution, privilege-sensitive command use, root-context behavior, account modification, service or cron change, suspicious file write, hosted-content tampering, symlink or permission anomaly, archive staging, credential-file access, outbound retrieval, suspicious network transfer, DNS or mail manipulation, abuse report, or post-remediation recurrence outside approved support, patching, backup, migration, plugin update, customer maintenance, and incident-response workflows.

Implement the deployable QRadar logic as CRE correlation using two building blocks and one offense-generating correlation rule:

·        Building Block 1 should identify suspicious hosting-access candidates from control-panel, FTP, web, hosted-path, tenant-path, or plugin-adjacent telemetry.

·        Building Block 2 should identify suspicious server-impact candidates from endpoint, Linux audit, syslog, file-integrity, DNS, mail, network, abuse-report, customer-support, or incident-response telemetry.

·        The offense-generating CRE rule should trigger when Building Block 1 is followed by Building Block 2 for the same destination host, destination IP, hostname, tenant, reseller, domain, webroot, FTP account, control-panel account, source IP, or locally defined hosting incident key within the configured investigation window.

Increase priority when activity involves cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, customer-facing web, DNS, mail, database, backup, ecommerce, customer portal, or high-value hosted application infrastructure.

Increase priority when the correlated activity includes webshell evidence, hosted-content modification, symlink or permission anomalies, root-owned file changes, DNS or mail manipulation, abuse reports, customer tickets, phishing reports, malware reports, spam reports, blocklist entries, tenant-impact evidence, or post-remediation recurrence.

Do not treat web server activity, FTP use, customer file uploads, plugin updates, CMS updates, command-line administration, backup jobs, package updates, single symlink events, single file writes, single outbound connections, scanner traffic, or vulnerable-version findings alone as confirmed compromise. Require access-to-impact correlation and local telemetry enrichment before escalating as probable hosting-control compromise, shared-hosting escalation, tenant-boundary failure, or customer-impacting abuse.

Required Telemetry

·        QRadar log sources for cPanel, WHM, DNSOnly, WP Squared, LiteSpeed, web server logs, FTP logs, Linux audit, syslog, EDR, file-integrity telemetry, DNS logs, mail logs, proxy logs, firewall logs, WAF logs, CDN logs, NDR telemetry, abuse-desk records, customer-support records, backup records, CloudLinux/CageFS records where available, and incident-response records.

·        DSM parsing and custom properties for source IP, destination IP, destination hostname, username, effective user where available, process name, parent process name where available, command line where available, file path, file owner where available, file permission where available, symlink target where available, request path, HTTP method, user agent, FTP account, FTP operation, control-panel account, tenant, reseller, domain, webroot, plugin path, event name, event category, event action, log source type, timestamp, and remediation context.

·        QRadar reference sets, reference maps, reference map of sets, or asset profiles for hosting-control assets, shared-hosting assets, reseller-hosting assets, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, web server assets, FTP server assets, DNS server assets, mail server assets, database servers, backup servers, customer-facing hosted applications, high-value hosting assets, hosted domains, customer webroots, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, tenant mappings, reseller mappings, approved administrators, approved support users, approved service accounts, approved support sources, approved scanners, approved monitoring sources, approved backup destinations, approved CDN providers, approved mail relays, approved package repositories, approved maintenance windows, approved incident-response workflows, and exception groups.

·        QRadar building blocks for suspicious hosting-access candidates, suspicious FTP or web-access candidates, suspicious hosted-path or plugin-adjacent candidates, suspicious server-side execution candidates, suspicious file-impact candidates, suspicious outbound communication candidates, DNS or mail manipulation candidates, abuse-context candidates, post-remediation recurrence candidates, approved maintenance context, and approved support context.

·        Time synchronization across web, FTP, hosting-control, endpoint, Linux audit, syslog, file-integrity, DNS, mail, proxy, firewall, WAF, CDN, NDR, CloudLinux/CageFS, backup, support, abuse-report, and incident-response telemetry.

Engineering Implementation Instructions

Create and validate QRadar log source groups for hosting endpoint telemetry, Linux audit telemetry, file-integrity telemetry, web access telemetry, FTP telemetry, hosting-control telemetry, DNS and mail telemetry, network telemetry, abuse-support telemetry, backup telemetry, CloudLinux/CageFS telemetry where available, and post-remediation activity. These log source groups should hide customer-specific log source names, DSM differences, collection methods, and vendor connector details from the CRE logic.

Create and validate QRadar reference sets for Hosting_Control_Assets, Shared_Hosting_Assets, Reseller_Hosting_Assets, cPanel_Assets, WHM_Assets, DNSOnly_Assets, WP_Squared_Assets, LiteSpeed_cPanel_Plugin_Assets, LiteSpeed_WHM_Plugin_Assets, CloudLinux_CageFS_Assets, Web_Server_Assets, FTP_Server_Assets, DNS_Server_Assets, Mail_Server_Assets, Database_Server_Assets, Backup_Server_Assets, Customer_Facing_Hosted_App_Assets, High_Value_Hosting_Assets, Approved_Hosting_Admin_Users, Approved_Support_Users, Approved_Service_Accounts, Approved_Admin_Support_Customer_or_Scanner_Sources, Approved_Backup_CDN_Package_Mail_or_Monitoring_Destinations, Approved_Maintenance_Windows, Approved_Incident_Response_Workflows, Approved_Hosting_Control_Web_FTP_Backup_or_Maintenance_Processes, and Hosting_Exception_Groups.

Create and validate QRadar reference maps or reference map of sets for Hosted_Domain_to_Host, Webroot_to_Tenant, FTP_Account_to_Tenant, Control_Panel_Account_to_Tenant, Tenant_to_Reseller, Domain_to_Reseller, LiteSpeed_Plugin_Path_to_Host, CloudLinux_CageFS_Path_to_Tenant, Hosting_Asset_to_Role, Hosting_Asset_to_Technology, and Hosting_Asset_to_Customer_Impact_Tier. These mappings are required so QRadar offenses can group by affected hosting asset, tenant, reseller, domain, and webroot rather than only by source IP or destination IP.

The engineer or admin must map local QRadar custom properties to the rule placeholders before deployment. At minimum, validate custom properties for request path, source IP, destination IP, destination hostname, username, effective user where available, process name, parent process name where available, command line where available, file path, source port, destination port, HTTP method, user agent, FTP account, FTP operation, control-panel account, tenant, reseller, domain, webroot, plugin path, event name, event category, event action, log source type, and timestamp. If command line, process lineage, file path, symlink, permission, tenant, reseller, or webroot context is unavailable, the rule must remain in hunt or investigation mode until compensating endpoint, file-integrity, web, FTP, NDR, proxy, DNS, WAF, CDN, control-panel, or CloudLinux/CageFS telemetry is mapped.

The engineer or admin must create customer-specific mappings for webroots, tenant paths, FTP upload paths, LiteSpeed plugin paths, CloudLinux/CageFS tenant paths, backup paths, database paths, mail paths, temporary paths, webshell candidate paths, symlink-sensitive paths, and control-panel-adjacent paths. These mappings must distinguish expected customer maintenance from suspicious cross-tenant, plugin-adjacent, symlink-sensitive, root-context, or hosted-content tampering behavior.

The engineer or admin must create QRadar building blocks before alert promotion. Building Block 1 should identify suspicious hosting-access candidates from control-panel, FTP, web, hosted-path, tenant-path, or plugin-adjacent telemetry. Building Block 2 should identify suspicious server-impact candidates from endpoint, Linux audit, syslog, file-integrity, DNS, mail, network, abuse-report, customer-support, or incident-response telemetry. The offense-generating CRE rule should correlate these building blocks by destination IP, destination hostname, host identity, tenant, reseller, domain, webroot, FTP account, control-panel account, source IP, or locally defined hosting incident key within a bounded window.

The engineer or admin must configure command, path, process, destination, and behavior matching through QRadar custom properties, building blocks, reference sets, reference maps, regular-expression custom property extraction, AQL support searches, or precomputed enrichment events before deployment. Do not assume simple string matching will identify command-line substrings, path fragments, webroot patterns, plugin paths, suspicious hosted-content patterns, credential-file paths, symlink-sensitive paths, or rare destination categories. If regular-expression matching is too expensive in the local QRadar environment, precompute candidate flags through parsing, enrichment, reference maps, or scheduled searches before alerting.

The engineer or admin must define approved local baselines for hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. These baselines must feed reference sets, building blocks, offense rule tests, exception handling, lowering logic, and suppression logic before the rule is promoted from hunt mode to alert mode.

The engineer or admin must validate offense grouping before deployment. The offense should not group only by source IP because hosting compromise may involve shared infrastructure, proxies, scanners, customer IPs, support sources, or rotating attacker infrastructure. Prefer grouping by destination host, destination IP, hosting asset, tenant, reseller, domain, webroot, FTP account, control-panel account, or a locally defined hosting incident key. Where username is missing or generic, such as root, apache, nginx, nobody, cpanel, www-data, FTP service, web server, or support service context, triage must rely on host identity, process lineage, file path, tenant mapping, webroot mapping, and downstream correlation rather than user identity alone.

Deploy initially in test or disabled-response mode for at least one business cycle that includes hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, webroot maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response activity, and approved incident-response cleanup. Promote to active offense generation only after log sources, custom properties, reference sets, reference maps, building blocks, offense grouping, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has moderate-to-strong detection relevance because hosting-control compromise and shared-hosting privilege escalation become materially actionable when suspicious hosting access, FTP activity, web activity, hosted-path activity, or plugin-adjacent activity is followed by privileged server-side behavior, file impact, outbound activity, abuse-report evidence, or post-remediation recurrence. It is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on QRadar-correlatable access-to-impact behavior rather than static indicators.

DRI

8.0

TCR Assessment

Operational telemetry confidence depends on QRadar access to hosting-control logs, FTP logs, web logs, endpoint or Linux audit telemetry, file-integrity telemetry, DNS and mail logs, network telemetry, DSM parsing, custom property extraction, reference sets, reference maps, building blocks, offense grouping, tenant mapping, reseller mapping, webroot mapping, and support-workflow baselines. Confidence is reduced where custom properties are incomplete, endpoint coverage is missing from hosting servers, command-line capture is unavailable, webroot and plugin paths are not mapped, CloudLinux/CageFS tenant context is unavailable, generic service-account activity cannot be correlated, or routine hosting workflows are poorly baselined.

Operational TCR

7.0

Full-Telemetry TCR

8.5

Limitations

This rule may produce false positives from legitimate hosting-provider support, reseller administration, customer FTP uploads, CMS updates, plugin updates, backups, migrations, package updates, certificate renewal, DNS changes, mail operations, database maintenance, CloudLinux/CageFS operations, vulnerability scanning, managed security testing, abuse-response work, and approved incident-response cleanup. The rule cannot independently confirm cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, tenant-spanning access, or customer data exposure without hosting-control, FTP, web, file, symlink, DNS, mail, NDR, tenant-mapping, and abuse-report correlation. It should not attribute activity to any named actor, scanner, webshell family, or exploit kit without separate validated intelligence. Rule quality depends on DSM parsing, custom property accuracy, reference-set hygiene, reference-map quality, timestamp alignment, offense grouping, bounded windows, and building-block validation.

Detection Query Pattern

Use this as a QRadar implementation pattern. The deployable rule should be implemented as CRE building-block correlation, with AQL used for validation, hunting, rule tuning, and SOC review. Customer-specific log source types, custom property names, reference set names, reference map names, and offense grouping logic must be validated before deployment.

CRE Building Block 1 should identify suspicious hosting-access candidates when events match all of the following local conditions:

·        Destination IP or destination hostname maps to Hosting_Control_Assets, Shared_Hosting_Assets, Reseller_Hosting_Assets, cPanel_Assets, WHM_Assets, DNSOnly_Assets, WP_Squared_Assets, LiteSpeed_cPanel_Plugin_Assets, LiteSpeed_WHM_Plugin_Assets, CloudLinux_CageFS_Assets, or High_Value_Hosting_Assets.

·        Log source type maps to cPanel access, WHM access, hosting-control logs, web access logs, proxy logs, FTP logs, WAF logs, CDN logs, Linux audit, syslog, EDR events, file-integrity events, firewall events, DNS events, or mail events.

·        The event contains hosting-control, FTP, web-accessible hosted-path, tenant-path, or plugin-adjacent context through request path, file path, FTP operation, process name, parent process name, command line, event name, or mapped custom property.

·        Source IP is not in Approved_Admin_Support_Customer_or_Scanner_Sources, username is not in Approved_Hosting_Admin_Users, and the event is not explained by approved support, scanner, monitoring, maintenance, backup, migration, plugin update, CMS update, customer-maintenance, or incident-response context.

CRE Building Block 2 should identify suspicious server-impact candidates when events match all of the following local conditions:

·        Destination IP or destination hostname maps to the same hosting asset groups, or the event maps to the same tenant, reseller, domain, webroot, FTP account, control-panel account, or locally defined hosting incident key.

·        The event contains privileged server-side behavior, suspicious file impact, outbound communication, DNS or mail manipulation, abuse-report context, or post-remediation recurrence through process name, command line, file path, file permission, symlink target, destination domain, event name, abuse context, customer ticket context, or mapped custom property.

·        The event is not explained by approved hosting-control, web, FTP, backup, package, CDN, mail, monitoring, support, scanner, customer-maintenance, migration, or incident-response context.

CRE Correlation Rule should generate an offense when:

·        Building Block 1 is followed by Building Block 2 within the locally defined hosting foothold-to-impact investigation window.

·        Events correlate by destination IP, destination hostname, hosting asset, tenant, reseller, domain, webroot, FTP account, control-panel account, source IP, or locally defined hosting incident key.

·        The correlated activity is not suppressed by Hosting_Exception_Groups, Approved_Maintenance_Windows, Approved_Incident_Response_Workflows, approved support context, approved scanner context, approved backup context, approved package context, approved CDN context, approved mail context, or approved customer-maintenance context.

Use the following AQL as a supporting validation and hunt pattern for the candidate event population. Field names must be mapped to local QRadar custom properties before use.

SELECT
"startTime",
"sourceIP",
"destinationIP",
"destinationHostName",
"username",
"eventName",
"logSourceTypeId",
"requestPath",
"httpMethod",
"userAgent",
"ftpAccount",
"ftpOperation",
"processName",
"parentProcessName",
"commandLine",
"filePath",
"destinationPort",
"destinationDomain",
"tenant",
"reseller",
"domain",
"webroot"
FROM events
WHERE
(
REFERENCESETCONTAINS('Hosting_Control_Assets', "destinationIP")
OR REFERENCESETCONTAINS('Shared_Hosting_Assets', "destinationIP")
OR REFERENCESETCONTAINS('Reseller_Hosting_Assets', "destinationIP")
OR REFERENCESETCONTAINS('cPanel_Assets', "destinationIP")
OR REFERENCESETCONTAINS('WHM_Assets', "destinationIP")
OR REFERENCESETCONTAINS('DNSOnly_Assets', "destinationIP")
OR REFERENCESETCONTAINS('WP_Squared_Assets', "destinationIP")
OR REFERENCESETCONTAINS('LiteSpeed_cPanel_Plugin_Assets', "destinationIP")
OR REFERENCESETCONTAINS('LiteSpeed_WHM_Plugin_Assets', "destinationIP")
OR REFERENCESETCONTAINS('CloudLinux_CageFS_Assets', "destinationIP")
OR REFERENCESETCONTAINS('High_Value_Hosting_Assets', "destinationIP")
)
AND NOT REFERENCESETCONTAINS('Approved_Admin_Support_Customer_or_Scanner_Sources', "sourceIP")
AND NOT REFERENCESETCONTAINS('Approved_Hosting_Admin_Users', "username")
AND LOGSOURCETYPENAME(logSourceTypeId) IN (
'cPanel Access',
'WHM Access',
'Web Access Logs',
'Proxy Logs',
'FTP Logs',
'Linux Audit',
'Syslog',
'EDR Events',
'File Integrity Events',
'Firewall Events',
'DNS Events',
'Mail Events',
'Hosting Control Logs'
)
AND (
"requestPath" ILIKE '/cpanel%'
OR "requestPath" ILIKE '/whm%'
OR "requestPath" ILIKE '/webmail%'
OR "requestPath" ILIKE '/json-api%'
OR "requestPath" ILIKE '/cpsess%'
OR "requestPath" ILIKE '%public_html%'
OR "requestPath" ILIKE '%wp-content%'
OR "requestPath" ILIKE '%upload%'
OR "requestPath" ILIKE '%tmp%'
OR "requestPath" ILIKE '%plugin%'
OR "filePath" ILIKE '/home/%/public_html/%'
OR "filePath" ILIKE '/home/%/www/%'
OR "filePath" ILIKE '/home/%/tmp/%'
OR "filePath" ILIKE '/home/%/.ssh/%'
OR "filePath" ILIKE '/var/www/%'
OR "filePath" ILIKE '/usr/local/lsws/%'
OR "filePath" ILIKE '/usr/local/cpanel/%'
OR "filePath" ILIKE '/var/cpanel/%'
OR "processName" IN (
'httpd',
'apache2',
'nginx',
'lshttpd',
'php',
'php-fpm',
'pure-ftpd',
'proftpd',
'cpanel',
'whostmgrd',
'cpdavd',
'cpsrvd',
'sh',
'bash',
'python',
'python3',
'perl',
'curl',
'wget',
'tar',
'zip',
'mysqldump',
'mysql',
'crontab',
'chmod',
'chown',
'useradd',
'usermod',
'passwd',
'systemctl',
'service'
)
OR "commandLine" ILIKE '%chmod%'
OR "commandLine" ILIKE '%chown%'
OR "commandLine" ILIKE '%crontab%'
OR "commandLine" ILIKE '%useradd%'
OR "commandLine" ILIKE '%usermod%'
OR "commandLine" ILIKE '%authorized_keys%'
OR "commandLine" ILIKE '%wp-config.php%'
OR "commandLine" ILIKE '%configuration.php%'
OR "commandLine" ILIKE '%database.php%'
OR "commandLine" ILIKE '%mysqldump%'
OR "commandLine" ILIKE '%curl %'
OR "commandLine" ILIKE '%wget %'
)
AND NOT (
REFERENCESETCONTAINS('Approved_Backup_CDN_Package_Mail_or_Monitoring_Destinations', "destinationDomain")
OR REFERENCESETCONTAINS('Approved_Hosting_Control_Web_FTP_Backup_or_Maintenance_Processes', "processName")
)
LAST 2 HOURS

SIGMA

‍ ‍

Detection Viability Assessment

‍ ‍

SIGMA has three rules for this EXP report.

‍ ‍

·        SIGMA is viable for portable endpoint and file-event detection logic where Linux process creation and hosted-content file telemetry are normalized into compatible backend fields.

‍ ‍

·        SIGMA is strongest for behavior patterns that can be expressed across platforms, including hosting-control service execution into suspicious tooling and suspicious hosted-content or persistence-relevant file modification on hosting-control servers.

‍ ‍

·        SIGMA is not viable as the primary source for authentication-bypass success, control-panel session validity, tenant blast-radius assessment, or complex multi-source correlation unless translated into a backend with the required telemetry and enrichment.

‍ ‍

Rule 1

‍ ‍

Hosting-Control Process Spawns Shell or Administrative Tooling

‍ ‍

Rule Format

‍ ‍

SIGMA rule suitable for backend conversion after field, log source, and platform mapping validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect hosting-control, web-service, mail-service, backup, account-management, or related service processes spawning shells, interpreters, administrative utilities, package tools, service-control commands, or staging utilities.

‍ ‍

·        Identify portable endpoint-observable post-access behavior that may follow unauthorized control-plane access without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success or control-panel session legitimacy.

‍ ‍

Detection Logic

‍ ‍

·        Identify Linux process creation where the parent process is associated with hosting-control, web-service, mail-service, backup, account-management, or related service context.

‍ ‍

·        Prioritize child processes associated with shell execution, scripting, account administration, package activity, service control, archive staging, or outbound retrieval.

‍ ‍

·        Treat events as higher confidence when the host is a known exposed hosting-control-plane asset or when activity follows abnormal control-panel access, suspicious session behavior, account modification, hosted-content modification, or suspicious outbound communication.

‍ ‍

·        Suppress approved maintenance, patching, backup, migration, monitoring, support, and automation workflows only when parent process, command line, execution user, host role, and time window are validated in the target backend.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating authentication/session, account, file-system, outbound communication, or tenant-impact evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Linux process creation telemetry.

‍ ‍

·        Parent process name.

‍ ‍

·        Child process name.

‍ ‍

·        Command-line capture.

‍ ‍

·        Process executable path where available.

‍ ‍

·        User context where available.

‍ ‍

·        Host identity.

‍ ‍

·        Host role or asset context.

‍ ‍

·        Exposed hosting-control-plane asset context where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate target backend field mappings for parent process, child process, command line, user, host identity, operating system, event type, and timestamp before deployment.

‍ ‍

·        Scope converted detections to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Tune parent-process names to match the customer’s actual hosting-control, web-service, mail-service, backup, and account-management process names.

‍ ‍

·        Add backend-specific exceptions for approved patching, package management, backup, migration, monitoring, vulnerability scanning, hosting-provider support, reseller administration, and automation workflows.

‍ ‍

·        Treat exposed hosting-control-plane status as prioritization context, not as the only alert condition.

‍ ‍

·        Use follow-on account modification, hosted-content modification, suspicious outbound communication, or persistence-relevant activity as triage evidence.

‍ ‍

·        Do not deploy the converted rule without confirming that the backend preserves parent-child process relationships and command-line content.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious service-context execution rather than static exploit or artifact matching.

‍ ‍

·        The rule remains useful if public proof-of-concept code changes request formatting, user agent, source infrastructure, scanner name, or payload structure.

‍ ‍

·        The score is supported by portable coverage of a durable post-access behavior class.

‍ ‍

·        The score is constrained by backend field mapping, parent-process fidelity, command-line visibility, and operational workflow overlap.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

·        Operational confidence depends on backend support for Linux process creation, process ancestry, command-line capture, host scoping, and exception handling.

‍ ‍

·        Operational confidence is reduced where SIGMA field translation loses parent-child relationships, command-line detail, or host role context.

‍ ‍

·        Full-telemetry confidence improves when the converted rule is enriched with exposed asset state, control-panel access context, authentication/session context, file-system activity, and outbound network context.

‍ ‍

·        Even under full telemetry conditions, this rule requires correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious post-access execution behavior, not the original authentication-bypass event.

‍ ‍

·        SIGMA conversion quality depends on the target backend, field mapping, and telemetry fidelity.

‍ ‍

·        Legitimate cPanel or WHM maintenance, package updates, backups, migrations, monitoring, support, and reseller administration may overlap with this behavior.

‍ ‍

·        Confirmation requires correlation with suspicious control-panel access, authentication/session anomalies, account modification, hosted-content modification, outbound communication, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

title: Hosting-Control Process Spawns Shell or Administrative Tooling
id: 5f86c9de-8dd9-4ef7-8e4f-2f5d7b9a1001
status: experimental
description: Detects hosting-control, web-service, mail-service, backup, account-management, or related service processes spawning shell, interpreter, administrative, package, service-control, or staging utilities on Linux hosting-control servers.
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '/cpsrvd'
      - '/cpaneld'
      - '/whostmgrd'
      - '/httpd'
      - '/apache2'
      - '/litespeed'
      - '/nginx'
      - '/php-fpm'
      - '/exim'
      - '/dovecot'
      - '/cron'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/php'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/useradd'
      - '/usermod'
      - '/passwd'
      - '/chpasswd'
      - '/yum'
      - '/dnf'
      - '/apt'
      - '/rpm'
      - '/systemctl'
      - '/service'
      - '/crontab'
      - '/tar'
      - '/zip'
      - '/gzip'
      - '/openssl'
  filter_known_cpanel_maintenance:
    CommandLine|contains:
      - '/scripts/upcp'
      - '/usr/local/cpanel/scripts/'
      - 'cpbackup'
      - 'backup'
      - 'yum update'
      - 'dnf update'
      - 'apt update'
      - 'apt upgrade'
  condition: selection_parent and selection_child and not filter_known_cpanel_maintenance
fields:
  - UtcTime
  - Hostname
  - User
  - ParentImage
  - Image
  - CommandLine
  - CurrentDirectory
falsepositives:
  - Approved cPanel or WHM maintenance
  - Package updates
  - Backup or migration workflows
  - Hosting-provider support
  - Reseller administration
  - Approved automation
level: high

‍ ‍

Rule 2

‍ ‍

Suspicious Hosted-Content or Persistence-Relevant File Modification on Hosting-Control Servers

‍ ‍

Rule Format

‍ ‍

SIGMA rule suitable for backend conversion after field, log source, host-scope, and platform mapping validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect suspicious hosted-content modification, script placement, permission change, archive staging, or persistence-relevant file activity on Linux hosting-control servers.

‍ ‍

·        Identify portable file-event behavior that may follow control-plane compromise without depending on static webshell signatures, CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, source process fidelity, or one exploit implementation.

‍ ‍

·        This rule does not prove that a file is malicious without supporting context.

‍ ‍

Detection Logic

‍ ‍

·        Identify file creation, file modification, or file attribute changes in hosted-content, webroot, temporary, cron, SSH key, or persistence-relevant paths.

‍ ‍

·        Prioritize script-like files, web-accessible paths, hidden files, writable staging paths, persistence-relevant paths, or repeated modification across hosted accounts.

‍ ‍

·        Treat events as higher confidence when source process context shows hosting-control, web-service, mail-service, backup, account-management, shell, scripting, or interpreter activity.

‍ ‍

·        Increase priority when activity follows abnormal control-panel access, suspicious session behavior, privileged execution, account modification, or suspicious outbound communication.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating webshell evidence, unauthorized access, persistence, outbound communication, or tenant-impact evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Linux file creation, modification, or attribute-change telemetry.

‍ ‍

·        File path.

‍ ‍

·        File extension where available.

‍ ‍

·        File owner or permission mode where available.

‍ ‍

·        User context where available.

‍ ‍

·        Host identity.

‍ ‍

·        Host role or hosting-control-plane asset scope.

‍ ‍

·        Tenant or hosted-path context where available.

‍ ‍

·        Source process context where available.

‍ ‍

·        Command-line capture where available.

‍ ‍

·        Timestamp.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate target backend field mappings for file path, file event type, user, host identity, host role, source process where available, command line where available, and timestamp before deployment.

‍ ‍

·        Scope converted detections to Linux servers running cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Validate local hosted-content paths, webroot paths, tenant directory structures, mail paths, temporary paths, cron paths, SSH key paths, and service-relevant paths before deployment.

‍ ‍

·        Add backend-specific exceptions for approved customer updates, CMS updates, deployment automation, patching, backups, migrations, certificate renewal, hosting-provider support, reseller administration, and recovery workflows.

‍ ‍

·        Tune monitored paths to customer-specific hosting layouts rather than excluding broad webroot coverage.

‍ ‍

·        Treat multi-account or multi-tenant modification as higher priority than isolated single-file modification.

‍ ‍

·        Treat source process context as confidence enrichment when available, not as a mandatory condition for rule viability.

‍ ‍

·        Do not deploy the converted rule as high confidence without validating hosted-path scope, file-event fidelity, operational update patterns, and tenant context where available.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

7.0 / 10

‍ ‍

·        The rule is behaviorally anchored to suspicious hosted-content and persistence-relevant file activity rather than static webshell signatures.

‍ ‍

·        The rule remains useful if attackers rename files, change extensions, alter webshell content, modify public exploit tooling, or use legitimate service context after gaining access.

‍ ‍

·        The score is supported by portable coverage of hosted-content modification and persistence-relevant file behavior.

‍ ‍

·        The score is constrained by backend file-event support, tenant-path mapping, source-process availability, and overlap with legitimate customer or CMS updates.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

6.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

7.5 / 10

‍ ‍

·        Operational confidence depends on backend support for file creation, file modification, file attribute changes, host scoping, hosted-path context, and exception handling.

‍ ‍

·        Operational confidence is reduced where SIGMA translation loses file-event type, hosted-path detail, tenant mapping, or source process context.

‍ ‍

·        Full-telemetry confidence improves when the converted rule is enriched with exposed asset state, control-panel access context, authentication/session context, endpoint process telemetry, source process context, and tenant mapping.

‍ ‍

·        Even under full telemetry conditions, suspicious file activity requires correlation before confirmed compromise classification.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious hosted-content modification or persistence-relevant file activity, not confirmed exploitation.

‍ ‍

·        SIGMA conversion quality depends on the target backend, field mapping, and telemetry fidelity.

‍ ‍

·        Some backends may not preserve source process context for file events, reducing confidence and requiring lower-severity deployment or supplemental correlation.

‍ ‍

·        Legitimate customer updates, CMS changes, plugin updates, backups, migrations, certificate renewal, deployment automation, support, and reseller administration may overlap with this behavior.

‍ ‍

·        Confirmation requires correlation with unauthorized access, suspicious execution, webshell evidence, account modification, outbound communication, or tenant-impact indicators.

‍ ‍

Detection Query Pattern

‍ ‍

title: Suspicious Hosted-Content or Persistence-Relevant File Modification on Hosting-Control Servers
id: 7c3a7e64-0f1e-4e3d-9c0e-6b9c2f45a8d1
status: experimental
description: Detects suspicious hosted-content or persistence-relevant file activity on Linux hosting-control servers without requiring source process context as a mandatory condition.
logsource:
  product: linux
  category: file_event
detection:
  selection_hosted_paths:
    TargetFilename|contains:
      - '/home/'
      - '/public_html/'
      - '/www/'
      - '/var/www/'
      - '/usr/local/apache/htdocs/'
      - '/etc/cron'
      - '/var/spool/cron'
      - '/.ssh/authorized_keys'
      - '/tmp/'
      - '/var/tmp/'
      - '/dev/shm/'
  selection_script_or_persistence:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.pl'
      - '.py'
      - '.sh'
      - '.cgi'
      - '.js'
  selection_staging_or_persistence_path:
    TargetFilename|contains:
      - '/uploads/'
      - '/cache/'
      - '/tmp/'
      - '/var/tmp/'
      - '/dev/shm/'
      - '/cron'
      - '/.ssh/authorized_keys'
  filter_known_maintenance:
    CommandLine|contains:
      - '/scripts/upcp'
      - '/usr/local/cpanel/scripts/'
      - 'cpbackup'
      - 'backup'
      - 'certbot'
      - 'acme.sh'
      - 'wp-cli'
      - 'composer install'
      - 'npm install'
  condition: selection_hosted_paths and (selection_script_or_persistence or selection_staging_or_persistence_path) and not filter_known_maintenance
fields:
  - UtcTime
  - Hostname
  - User
  - Image
  - CommandLine
  - TargetFilename
falsepositives:
  - Customer website updates
  - CMS plugin or theme updates
  - Approved deployment automation
  - Backup or migration workflows
  - Certificate renewal
  - Hosting-provider support
  - Reseller administration
level: medium

‍ ‍

YARA

‍ ‍

Detection Viability Assessment

‍ ‍

YARA has zero primary rules for this EXP report.

‍ ‍

·        YARA is not recommended for primary S25 detection because the governing detection model is behavior-led, not artifact-led.

‍ ‍

·        YARA can support optional webshell, payload, or suspicious script hunting, but it does not observe authentication-flow mismatch, session validity, privileged execution lineage, account changes, tenant blast radius, or outbound process attribution.

‍ ‍

·        Including a primary YARA rule would create unnecessary artifact dependency and would be weaker than the accepted endpoint, SIEM, network, and portable behavior rules.

‍ ‍

Final Disposition

‍ ‍

No primary YARA rule is included.

‍ ‍

Disposition Rationale

‍ ‍

·        YARA is better suited for artifact inspection than for detecting hosting control-plane compromise behavior.

‍ ‍

·        The highest-value detection opportunities for this report require access logs, authentication/session telemetry, endpoint process telemetry, file-event telemetry, account-change telemetry, DNS/proxy telemetry, network telemetry, and SIEM correlation.

‍ ‍

·        A YARA rule would likely depend on webshell strings, suspicious script fragments, filenames, encoded content, or payload patterns that attackers can easily modify.

‍ ‍

·        Artifact-only matching would not meet the behavior-first detection standard required for this EXP report.

‍ ‍

·        YARA may be considered later as an optional hunting appendix for customer-specific webshell or payload review, but it should not be treated as a primary S25 rule.

‍ ‍

AWS

‍ ‍

Detection Viability Assessment

‍ ‍

AWS has one conditional rule for this EXP report.

‍ ‍

·        AWS is viable for cloud-native visibility when cPanel, WHM, WP Squared, or related hosting-control systems are hosted on EC2 and AWS telemetry can identify exposed assets, inbound access context, outbound communication, DNS activity, WAF or load balancer activity, GuardDuty findings, or Security Hub findings.

‍ ‍

·        AWS is not viable as a standalone source for confirming authentication-bypass success, control-panel session validity, guest operating system execution, hosted-content modification, account changes inside cPanel, or tenant blast radius.

‍ ‍

·        AWS is strongest as a conditional exposure and network-behavior layer that supports triage and prioritization when paired with guest telemetry, application logs, endpoint telemetry, and SIEM correlation.

‍ ‍

Rule 1

‍ ‍

Exposed EC2 Hosting-Control Asset with Suspicious Outbound or Abuse Behavior

‍ ‍

Rule Format

‍ ‍

AWS Security Lake / Athena normalized query pattern suitable for deployment after account, region, table, field, asset tag, VPC Flow Log, DNS log, GuardDuty, Security Hub, WAF, and load balancer validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect internet-exposed EC2-hosted cPanel, WHM, WP Squared, or related hosting-control assets that show suspicious outbound communication, DNS activity, abuse-related behavior, or cloud-native security findings.

‍ ‍

·        Identify cloud-observable suspected compromise or high-priority triage conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success, guest-level execution, hosted-content modification, control-panel account change, or tenant impact without guest operating system, application, endpoint, or SIEM evidence.

‍ ‍

Detection Logic

‍ ‍

·        Identify EC2 instances, network interfaces, or load-balanced targets inventoried as cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Confirm that the asset is internet-facing through public IP assignment, internet-facing load balancer exposure, security group ingress, WAF activity, external reachability context, or exposure-management inventory.

‍ ‍

·        Correlate exposed hosting-control assets with outbound communication, DNS activity, GuardDuty findings, Security Hub findings, unusual destination behavior, or abuse-related activity inconsistent with expected hosting-control operations.

‍ ‍

·        Treat the alert as higher priority when the asset was exposed before patch validation or when AWS-native findings align with guest-level suspicious activity from endpoint, application, or SIEM telemetry.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating guest-level or application-layer evidence.

‍ ‍

Required Telemetry

‍ ‍

·        EC2 asset inventory.

‍ ‍

·        Hosting-control-plane asset tags or external asset inventory.

‍ ‍

·        Security group configuration.

‍ ‍

·        Public IP or internet-facing load balancer exposure context.

‍ ‍

·        VPC Flow Logs.

‍ ‍

·        Route 53 Resolver DNS query logs where available.

‍ ‍

·        AWS WAF logs where available.

‍ ‍

·        Application Load Balancer or Network Load Balancer logs where available.

‍ ‍

·        GuardDuty findings where available.

‍ ‍

·        Security Hub findings where available.

‍ ‍

·        Account, region, VPC, subnet, instance, network interface, source IP, destination IP, destination port, protocol, traffic direction, and timestamp.

‍ ‍

·        Approved outbound destination context where available.

‍ ‍

·        Approved administrator source and maintenance context where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate AWS account, region, VPC, subnet, security group, public IP, load balancer, network interface, instance tag, and hosting-control-plane inventory before deployment.

‍ ‍

·        Scope the rule to EC2 instances, network interfaces, or target groups known to host cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Validate that VPC Flow Logs, Route 53 Resolver DNS logs, WAF logs, load balancer logs, GuardDuty findings, and Security Hub findings are enabled where applicable.

‍ ‍

·        Normalize local asset identity across EC2 inventory, VPC Flow Logs, DNS logs, WAF logs, load balancer logs, GuardDuty, Security Hub, and SIEM asset records.

‍ ‍

·        Maintain approved outbound destinations, expected update repositories, backup destinations, monitoring destinations, hosting-provider support context, and known administrative sources.

‍ ‍

·        Treat AWS exposure state and cloud-native network behavior as prioritization context, not standalone proof of compromise.

‍ ‍

·        Route alerts to SIEM correlation with control-panel access logs, authentication/session telemetry, endpoint process telemetry, file-system telemetry, and administrative action logs.

‍ ‍

·        Do not escalate to confirmed compromise without guest-level or application-layer corroboration.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

6.5 / 10

‍ ‍

·        The rule is behaviorally anchored to exposed hosting-control assets showing suspicious cloud-observable network or abuse behavior.

‍ ‍

·        The rule remains useful if exploit request formatting, source infrastructure, scanner name, user agent, payload structure, or public proof-of-concept content changes.

‍ ‍

·        The score is supported by exposure-aware monitoring and cloud-native visibility into outbound communication, DNS activity, and security findings.

‍ ‍

·        The score is constrained because AWS-native telemetry cannot directly validate cPanel authentication state, control-panel sessions, guest process execution, hosted-content modification, or tenant impact.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

5.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

7.0 / 10

‍ ‍

·        Operational confidence depends on EC2 asset tagging, exposure inventory, VPC Flow Logs, DNS query logging, GuardDuty findings, Security Hub findings, WAF or load balancer telemetry, and approved-destination context.

‍ ‍

·        Operational confidence is reduced where cPanel systems are not accurately tagged, DNS logging is unavailable, flow logs lack useful context, WAF or load balancer logs are unavailable, or outbound destinations are not baselined.

‍ ‍

·        Full-telemetry confidence improves when AWS-native telemetry is enriched with guest endpoint telemetry, control-panel access logs, authentication/session logs, file-system telemetry, and SIEM correlation.

‍ ‍

·        Even under full telemetry conditions, AWS remains a supporting visibility layer rather than a standalone compromise-confirmation source.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious cloud-observable exposure and network behavior, not confirmed exploitation.

‍ ‍

·        AWS-native telemetry does not directly observe cPanel authentication flow, control-panel session validity, guest shell execution, hosted-content modification, control-panel account changes, or tenant-level impact.

‍ ‍

·        Legitimate patching, package updates, backups, monitoring, customer traffic, DNS resolution, content delivery, and hosting-provider support may overlap with suspicious network behavior.

‍ ‍

·        Missing DNS logs, incomplete VPC Flow Logs, weak asset tagging, absent WAF or load balancer telemetry, or missing approved-destination context can reduce confidence.

‍ ‍

·        Confirmation requires correlation with control-panel access, authentication/session anomalies, endpoint execution, account modification, hosted-content modification, outbound process attribution, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

-- AWS Security Lake / Athena normalized detection pattern
-- Validate table names, field names, account scope, region scope, asset tags, OCSF mappings, and log source availability before deployment.

WITH hosting_assets AS (
  SELECT
    instance_id,
    account_id,
    region,
    private_ip,
    public_ip,
    network_interface_id,
    host_name,
    exposure_status,
    patch_status
  FROM asset_inventory
  WHERE asset_role IN ('cpanel', 'whm', 'wp_squared', 'hosting_control_plane')
),

cloud_network_activity AS (
  SELECT
    time,
    account_id,
    region,
    src_endpoint.instance_uid AS instance_id,
    src_endpoint.ip AS source_ip,
    dst_endpoint.ip AS destination_ip,
    dst_endpoint.port AS destination_port,
    protocol_name AS protocol,
    traffic_direction,
    action,
    bytes_out
  FROM amazon_security_lake.amazon_security_lake_table
  WHERE activity_name IN ('Network Activity', 'DNS Activity')
    AND traffic_direction = 'Outbound'
    AND dst_endpoint.ip IS NOT NULL
),

suspicious_outbound AS (
  SELECT
    n.*
  FROM cloud_network_activity n
  LEFT JOIN approved_outbound_destinations a
    ON n.destination_ip = a.destination_ip
  WHERE a.destination_ip IS NULL
    AND NOT regexp_like(
      n.destination_ip,
      '^(10\.|127\.|169\.254\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)'
    )
),

guardduty_or_securityhub_context AS (
  SELECT
    time,
    account_id,
    region,
    resource_id AS instance_id,
    product_name,
    finding_type,
    severity,
    title
  FROM security_findings
  WHERE product_name IN ('GuardDuty', 'Security Hub')
    AND finding_type IS NOT NULL
)

SELECT
  o.time,
  h.account_id,
  h.region,
  h.instance_id,
  h.host_name,
  h.public_ip,
  h.exposure_status,
  h.patch_status,
  o.source_ip,
  o.destination_ip,
  o.destination_port,
  o.protocol,
  o.bytes_out,
  f.product_name,
  f.finding_type,
  f.severity,
  f.title
FROM hosting_assets h
JOIN suspicious_outbound o
  ON h.instance_id = o.instance_id
LEFT JOIN guardduty_or_securityhub_context f
  ON h.instance_id = f.instance_id
WHERE h.exposure_status = 'internet-facing'
  AND (
    h.patch_status != 'validated_patched'
    OR f.finding_type IS NOT NULL
  );

‍ ‍Rule

Hosting Server Foothold Followed by AWS Control-Plane or Cloud-Service Impact

Rule Format

AWS CloudTrail Lake, Athena, Security Lake, EventBridge, GuardDuty, VPC Flow Logs, Route 53, SES, S3, IAM, EC2, and SIEM correlation pattern suitable for deployment after account, organization, workload, role, tag, asset, identity, network, DNS, mail, storage, and exception validation.

Detection Purpose

Detect suspicious AWS control-plane, storage, DNS, mail, identity, compute, or network activity that occurs after suspicious activity on AWS-hosted or AWS-adjacent hosting infrastructure associated with cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, or customer-facing hosted application workloads.

This rule is intended to identify conditional downstream cloud-impact behavior where a hosting-server foothold, webshell interaction, FTP foothold, hosted-content tampering, shared-hosting escalation, control-panel-adjacent compromise, or post-remediation recurrence may lead to AWS credential use, role abuse, storage access, DNS manipulation, mail abuse, instance manipulation, network exposure change, snapshot activity, or other cloud-service impact.

This rule does not claim AWS compromise from hosting-server activity alone. AWS activity must be correlated with affected hosting assets, workload identities, IAM roles, access keys, instance profiles, public IPs, private IPs, VPC context, DNS zones, S3 buckets, SES identities, Route 53 records, EC2 instances, security groups, snapshots, or another locally validated cloud-lineage key.

Detection Logic

Trigger when suspicious AWS activity involving a hosting-related workload, identity, resource, network path, DNS zone, mail identity, storage location, or affected asset occurs after or near suspicious hosting-server activity, access-path evidence, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Require both conditions within a bounded investigation window:

·        A hosting-risk context is present. This may include suspicious hosting-control access, suspicious FTP activity, webshell evidence, hosted-content modification, symlink or permission anomaly, root-context activity, suspicious outbound communication, abuse report, customer ticket, phishing report, malware report, spam report, blocklist entry, post-remediation recurrence, or a validated affected AWS-hosted hosting workload.

·        AWS telemetry shows unusual or unauthorized cloud activity involving the same hosting workload, instance, instance profile, IAM role, IAM user, access key, public IP, private IP, VPC, subnet, security group, hosted zone, domain, S3 bucket, SES identity, EC2 snapshot, AMI, Elastic IP, load balancer, account, tenant, reseller, customer, or incident context outside approved support, backup, migration, deployment, mail, DNS, monitoring, scanning, incident-response, and maintenance workflows.

Prioritize IAM activity involving access key creation, access key use from unusual infrastructure, policy attachment, inline policy changes, privilege changes, role assumption, instance profile changes, user creation, group membership changes, permission-boundary changes, role trust-policy changes, PassRole activity, or credential-report anomalies.

Prioritize EC2 activity involving instance start, stop, reboot, launch, user-data modification, instance metadata option changes, instance-profile association, image creation, snapshot creation, snapshot sharing, volume attachment, security group changes, network exposure changes, Elastic IP association, load balancer changes, or AMI manipulation involving hosting-related workloads.

Prioritize Route 53 activity involving hosted-zone, record-set, DNS delegation, MX, TXT, SPF, DKIM, DMARC, name-server, or domain changes involving hosted customer domains, mail flows, control-panel-managed zones, or domains tied to affected hosting assets.

Prioritize S3 activity involving bucket policy changes, ACL changes, public-access-block changes, object access, object copy, object deletion, versioning changes, replication changes, lifecycle changes, or logging changes involving hosting backups, customer data, web content, logs, support artifacts, or incident-response artifacts.

Prioritize SES activity involving identity creation, sending authorization, DKIM changes, mail-from changes, identity policy changes, configuration-set changes, template creation, sending activity, bounce activity, complaint activity, suppression changes, or reputation anomalies involving hosted customer domains or suspected abuse infrastructure.

Prioritize GuardDuty, Security Hub, Detective, AWS Config, Access Analyzer, CloudTrail, VPC Flow Log, Route 53 Resolver, DNS, proxy, WAF, CDN, firewall, or NDR findings that align with affected hosting assets, unusual destinations, known abused services, unexpected regions, Tor, anonymization infrastructure, suspicious outbound transfer, credential misuse, or post-remediation recurrence.

Do not treat AWS activity as confirmed compromise when it consists only of routine deployment, scaling, patching, backup, migration, DNS administration, mail administration, infrastructure-as-code execution, monitoring, vulnerability scanning, or incident-response cleanup. Require reliable cloud-lineage correlation to the hosting-risk context before classifying the activity as probable downstream cloud impact from hosting-control or shared-hosting compromise.

Required Telemetry

·        AWS CloudTrail management events across all relevant accounts and regions.

·        AWS CloudTrail data events for S3, Lambda, and other relevant services where enabled.

·        AWS CloudTrail Lake, Athena, Security Lake, SIEM export, or equivalent queryable AWS audit repository.

·        AWS Organizations account inventory, account tags, workload tags, resource tags, region inventory, and account ownership metadata.

·        IAM identity, role, access key, instance profile, permission boundary, session context, source IP, user agent, MFA, role assumption, session issuer, policy-change, and trust-policy-change telemetry.

·        EC2 instance, AMI, snapshot, volume, security group, network ACL, Elastic IP, load balancer, user data, instance profile, VPC, subnet, route table, and workload metadata.

·        VPC Flow Logs, Route 53 Resolver logs, Route 53 hosted-zone audit logs, DNS logs, WAF logs, CDN logs, proxy logs, firewall logs, and NDR telemetry where available.

·        S3 bucket, object, access logging, object-level data event, public-access-block, ACL, policy, versioning, replication, and lifecycle telemetry where available.

·        SES identity, sending, DKIM, mail-from, configuration, reputation, bounce, complaint, suppression, and mail-flow telemetry where available.

·        GuardDuty, Security Hub, Detective, AWS Config, Access Analyzer, Inspector, Macie, CloudTrail Insights, and incident-response case telemetry where available.

·        Local enrichment for hosting workloads, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, shared-hosting assets, reseller-hosting assets, customer-facing hosted applications, hosted domains, customer webroots, FTP accounts, control-panel accounts, tenants, resellers, public IPs, private IPs, VPCs, subnets, IAM roles, instance profiles, access keys, S3 buckets, SES identities, Route 53 zones, approved administrators, approved support users, approved automation roles, approved deployment roles, approved CI/CD roles, approved backup roles, approved DNS workflows, approved mail workflows, approved scanners, approved monitoring systems, approved maintenance windows, and approved incident-response workflows.

Engineering Implementation Instructions

Create and validate AWS asset and identity mappings before deployment. At minimum, the engineer or admin must map AWS account IDs, organization units, regions, EC2 instance IDs, instance profiles, IAM roles, IAM users, access keys, public IPs, private IPs, security groups, VPCs, subnets, Route 53 hosted zones, hosted domains, SES identities, S3 buckets, workload tags, application tags, customer tags, tenant mappings, reseller mappings, and hosting-platform tags to the local detection schema.

Create and validate AWS asset groups for AWS_Hosting_Workloads, AWS_Shared_Hosting_Workloads, AWS_Reseller_Hosting_Workloads, AWS_cPanel_Workloads, AWS_WHM_Workloads, AWS_DNSOnly_Workloads, AWS_WP_Squared_Workloads, AWS_LiteSpeed_cPanel_Plugin_Workloads, AWS_LiteSpeed_WHM_Plugin_Workloads, AWS_CloudLinux_CageFS_Workloads, AWS_Customer_Facing_Hosted_Applications, AWS_High_Value_Hosting_Workloads, AWS_Hosted_Domains, AWS_Hosting_Route53_Zones, AWS_Hosting_SES_Identities, AWS_Hosting_Backup_Buckets, AWS_Hosting_Web_Content_Buckets, AWS_Hosting_Log_Buckets, AWS_Hosting_Instance_Profiles, AWS_Hosting_IAM_Roles, AWS_Hosting_Access_Keys, and AWS_Hosting_Public_IPs.

Create and validate approved-context lists for AWS_Approved_Hosting_Admins, AWS_Approved_Support_Roles, AWS_Approved_Automation_Roles, AWS_Approved_Deployment_Roles, AWS_Approved_CICD_Roles, AWS_Approved_Backup_Roles, AWS_Approved_DNS_Admin_Roles, AWS_Approved_Mail_Admin_Roles, AWS_Approved_Scanner_Roles, AWS_Approved_Monitoring_Roles, AWS_Approved_Source_Networks, AWS_Approved_Backup_Destinations, AWS_Approved_Package_Repositories, AWS_Approved_CDN_Providers, AWS_Approved_Mail_Relays, AWS_Approved_Maintenance_Windows, AWS_Approved_Incident_Response_Workflows, and AWS_Hosting_Exception_Groups.

The engineer or admin must establish cloud lineage between hosting-risk telemetry and AWS telemetry before promotion to alert mode. Acceptable lineage may include instance ID, public IP, private IP, IAM role, instance profile, access key, workload tag, Route 53 hosted zone, hosted domain, SES identity, S3 bucket, VPC, subnet, security group, tenant, reseller, customer, or incident key. Account ID alone should not be used as sufficient lineage because it can over-correlate unrelated cloud activity in large or shared AWS environments.

The engineer or admin must validate CloudTrail coverage across all relevant AWS accounts and regions. Confirm that CloudTrail management events are enabled and centralized, that data events are enabled for relevant S3 buckets and other critical services where needed, and that CloudTrail Lake, Athena, Security Lake, SIEM export, or the selected query backend preserves event time, event source, event name, source IP, user agent, user identity, assumed-role context, session issuer, access key ID, recipient account ID, region, request parameters, response elements, error code, and resource identifiers.

The engineer or admin must validate service-specific visibility for Route 53, SES, S3, EC2, IAM, VPC, GuardDuty, Security Hub, Config, Access Analyzer, Detective, Macie, Inspector, CloudTrail Insights, and relevant incident-response tooling. Missing data-event coverage, incomplete Route 53 visibility, disabled SES telemetry, untagged workloads, uncentralized CloudTrail, incomplete account inventory, or missing instance-profile mapping should keep this rule in hunt mode until compensating telemetry is available.

The engineer or admin must baseline approved AWS workflows before alert promotion. Baseline infrastructure-as-code deployments, Auto Scaling, patching, package updates, backups, migrations, DNS administration, mail administration, certificate renewal, image creation, snapshot creation, incident-response cleanup, vulnerability scanning, monitoring, managed service operations, and support workflows. Exceptions should require user, role, source network, account, region, resource, API pattern, and maintenance-window validation.

The engineer or admin must configure alert grouping by AWS account, hosting workload, instance ID, IAM role, access key, hosted domain, Route 53 hosted zone, SES identity, S3 bucket, VPC, security group, public IP, private IP, tenant, reseller, customer, or local incident key. Avoid grouping only by source IP because legitimate automation, support access, cloud service infrastructure, or attacker-controlled infrastructure may rotate source addresses or use shared service ranges.

The engineer or admin must validate query performance before production alerting. Avoid broad joins over all CloudTrail events. Scope candidate events by eventSource, eventName, account, region, hosting-related asset groups, resource IDs, access keys, roles, hosted zones, SES identities, S3 buckets, instance IDs, and bounded time windows. Where the query backend cannot safely search serialized requestParameters at scale, precompute resource identifiers, resource ARNs, hosted domains, bucket names, security group IDs, instance IDs, route table IDs, and identity fields into normalized columns before alerting.

The engineer or admin must validate that AWS findings are triaged as conditional downstream cloud-impact evidence unless the AWS telemetry independently supports unauthorized activity. Confirmed compromise requires corroborating evidence such as unauthorized IAM change, suspicious role assumption, abnormal access-key use, resource manipulation, storage access, DNS manipulation, mail abuse, instance modification, snapshot activity, outbound transfer, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Deploy initially in hunt mode for at least one business cycle that includes deployment, patching, backup, migration, DNS, mail, monitoring, scanning, support, incident-response, and customer-maintenance activity. Promote to alert mode only after cloud lineage, asset groups, identity mappings, exception lists, telemetry coverage, query performance, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has moderate-to-strong detection relevance because hosting-control compromise and shared-hosting escalation can create downstream risk to AWS identities, hosted domains, storage, mail, compute, snapshots, network exposure, and customer-facing cloud resources when the affected hosting workload has cloud credentials, instance profiles, DNS authority, mail authority, backup access, or customer-data access. The rule is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on AWS control-plane and cloud-service activity linked to hosting-risk context rather than static indicators. The score is constrained because AWS telemetry does not directly observe cPanel, WHM, LiteSpeed plugin, CloudLinux/CageFS, or tenant-boundary exploitation unless hosting telemetry or cloud-resource lineage is available.

DRI

7.5

TCR Assessment

Operational confidence depends on centralized CloudTrail, correct account and region coverage, IAM and instance-profile mapping, workload tagging, hosting asset enrichment, Route 53 visibility, SES visibility, S3 data-event coverage where needed, VPC and DNS telemetry, GuardDuty or Security Hub findings, and reliable linkage between hosting-risk telemetry and AWS resources. Confidence is reduced where hosting workloads are untagged, CloudTrail is not centralized, data events are not enabled, Route 53 or SES telemetry is incomplete, access keys are shared, instance profiles are poorly scoped, requestParameters are not normalized, or hosting-to-cloud lineage is unavailable.

Operational TCR

7.0

Full-Telemetry TCR

8.5

Limitations

This rule detects conditional AWS cloud-impact behavior, not direct cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, or tenant-spanning access. AWS telemetry cannot confirm hosting compromise without local hosting, endpoint, web, FTP, file, symlink, DNS, mail, abuse-report, or tenant-impact correlation. Legitimate infrastructure-as-code deployments, Auto Scaling, patching, backup, migration, DNS administration, mail administration, certificate renewal, image creation, snapshot creation, monitoring, vulnerability scanning, managed service operations, support, and incident-response cleanup may overlap with this behavior. Confirmation requires validated lineage and corroborating cloud activity involving identity, compute, network, DNS, storage, mail, customer data, abuse reports, or post-remediation recurrence.

Detection Query Pattern

Use this pattern as a CloudTrail Lake, Athena, Security Lake, or SIEM implementation guide. Customer-specific table names, field names, resource tags, account mappings, region mappings, asset groups, identity mappings, precomputed resource columns, and exception lists must be validated before deployment. Account ID alone should not be treated as sufficient lineage.

WITH hosting_context AS (
SELECT
account_id,
resource_id,
instance_id,
private_ip,
public_ip,
iam_role_arn,
instance_profile_arn,
access_key_id,
hosted_domain,
route53_zone_id,
ses_identity,
s3_bucket,
vpc_id,
subnet_id,
security_group_id,
tenant_id,
reseller_id,
customer_id,
incident_key,
first_seen,
last_seen
FROM customer_hosting_risk_context
WHERE
hosting_platform IN (
'cPanel',
'WHM',
'DNSOnly',
'WP Squared',
'LiteSpeed cPanel Plugin',
'LiteSpeed WHM Plugin',
'CloudLinux/CageFS',
'Shared Hosting',
'Reseller Hosting'
)
AND risk_context IN (
'suspicious_hosting_control_access',
'suspicious_ftp_activity',
'web_shell_evidence',
'hosted_content_modification',
'symlink_or_permission_anomaly',
'suspicious_outbound_activity',
'abuse_report',
'customer_ticket',
'post_remediation_recurrence',
'validated_affected_hosting_workload'
)
),

aws_candidate_events AS (
SELECT
eventTime,
recipientAccountId,
awsRegion,
eventSource,
eventName,
sourceIPAddress,
userAgent,
userIdentity.type AS identity_type,
userIdentity.arn AS principal_arn,
userIdentity.accountId AS principal_account_id,
userIdentity.accessKeyId AS access_key_id,
userIdentity.sessionContext.sessionIssuer.arn AS session_issuer_arn,
requestParameters,
responseElements,
errorCode,
resources,
resource_instance_id,
resource_private_ip,
resource_public_ip,
resource_role_arn,
resource_instance_profile_arn,
resource_hosted_domain,
resource_route53_zone_id,
resource_ses_identity,
resource_s3_bucket,
resource_vpc_id,
resource_subnet_id,
resource_security_group_id
FROM cloudtrail_events
WHERE
eventSource IN (
'iam.amazonaws.com',
'sts.amazonaws.com',
'ec2.amazonaws.com',
's3.amazonaws.com',
'route53.amazonaws.com',
'ses.amazonaws.com',
'elasticloadbalancing.amazonaws.com',
'cloudtrail.amazonaws.com',
'guardduty.amazonaws.com',
'securityhub.amazonaws.com',
'config.amazonaws.com',
'access-analyzer.amazonaws.com'
)
AND eventName IN (
'CreateAccessKey',
'UpdateAccessKey',
'DeleteAccessKey',
'AttachUserPolicy',
'AttachRolePolicy',
'PutUserPolicy',
'PutRolePolicy',
'CreateUser',
'AddUserToGroup',
'UpdateAssumeRolePolicy',
'PassRole',
'AssumeRole',
'AssociateIamInstanceProfile',
'ReplaceIamInstanceProfileAssociation',
'AuthorizeSecurityGroupIngress',
'AuthorizeSecurityGroupEgress',
'RevokeSecurityGroupIngress',
'ModifySecurityGroupRules',
'ModifyInstanceAttribute',
'ModifyInstanceMetadataOptions',
'ModifyImageAttribute',
'CreateImage',
'CreateSnapshot',
'CopySnapshot',
'ModifySnapshotAttribute',
'AttachVolume',
'RunInstances',
'StartInstances',
'StopInstances',
'RebootInstances',
'AssociateAddress',
'ChangeResourceRecordSets',
'CreateHostedZone',
'DeleteHostedZone',
'UpdateHostedZoneComment',
'PutBucketPolicy',
'PutBucketAcl',
'PutPublicAccessBlock',
'DeletePublicAccessBlock',
'GetObject',
'PutObject',
'CopyObject',
'DeleteObject',
'CreateEmailIdentity',
'CreateEmailTemplate',
'PutEmailIdentityDkimSigningAttributes',
'PutEmailIdentityMailFromAttributes',
'PutIdentityPolicy',
'SendEmail',
'SendRawEmail'
)
)

SELECT
a.eventTime,
a.recipientAccountId,
a.awsRegion,
a.eventSource,
a.eventName,
a.sourceIPAddress,
a.userAgent,
a.principal_arn,
a.session_issuer_arn,
a.access_key_id,
a.requestParameters,
h.incident_key,
h.instance_id,
h.public_ip,
h.private_ip,
h.iam_role_arn,
h.instance_profile_arn,
h.hosted_domain,
h.route53_zone_id,
h.ses_identity,
h.s3_bucket,
h.tenant_id,
h.reseller_id,
h.customer_id
FROM aws_candidate_events a
JOIN hosting_context h
ON a.recipientAccountId = h.account_id
AND (
a.access_key_id = h.access_key_id
OR a.principal_arn = h.iam_role_arn
OR a.session_issuer_arn = h.iam_role_arn
OR a.principal_arn = h.instance_profile_arn
OR a.session_issuer_arn = h.instance_profile_arn
OR a.resource_instance_id = h.instance_id
OR a.resource_private_ip = h.private_ip
OR a.resource_public_ip = h.public_ip
OR a.resource_role_arn = h.iam_role_arn
OR a.resource_instance_profile_arn = h.instance_profile_arn
OR a.resource_hosted_domain = h.hosted_domain
OR a.resource_route53_zone_id = h.route53_zone_id
OR a.resource_ses_identity = h.ses_identity
OR a.resource_s3_bucket = h.s3_bucket
OR a.resource_vpc_id = h.vpc_id
OR a.resource_subnet_id = h.subnet_id
OR a.resource_security_group_id = h.security_group_id
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.instance_id, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.public_ip, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.hosted_domain, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.route53_zone_id, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.ses_identity, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.s3_bucket, '%')
OR CAST(a.requestParameters AS VARCHAR) LIKE CONCAT('%', h.security_group_id, '%')
)
WHERE
a.eventTime BETWEEN h.first_seen - INTERVAL '2' HOUR AND h.last_seen + INTERVAL '24' HOUR
AND NOT EXISTS (
SELECT 1
FROM aws_approved_source_networks n
WHERE a.sourceIPAddress = n.source_ip
)
AND NOT EXISTS (
SELECT 1
FROM aws_approved_principals p
WHERE
a.principal_arn = p.principal_arn
OR a.session_issuer_arn = p.principal_arn
)
AND NOT EXISTS (
SELECT 1
FROM aws_approved_maintenance_windows m
WHERE
a.eventTime BETWEEN m.window_start AND m.window_end
AND (
a.recipientAccountId = m.account_id
OR h.instance_id = m.instance_id
OR h.hosted_domain = m.hosted_domain
OR h.s3_bucket = m.s3_bucket
OR h.route53_zone_id = m.route53_zone_id
OR h.ses_identity = m.ses_identity
OR h.incident_key = m.incident_key
)
)

Azure

‍ ‍

Detection Viability Assessment

‍ ‍

Azure has one conditional rule for this EXP report.

‍ ‍

·        Azure is viable for cloud-native visibility when cPanel, WHM, WP Squared, or related hosting-control systems are hosted on Azure virtual machines and Azure telemetry can identify exposed assets, outbound communication, DNS activity, firewall activity, load balancer activity, Defender for Cloud findings, or Microsoft Sentinel correlation.

‍ ‍

·        Azure is not viable as a standalone source for confirming authentication-bypass success, control-panel session validity, guest operating system execution, hosted-content modification, cPanel account changes, or tenant blast radius.

‍ ‍

·        Azure is strongest as a conditional exposure and network-behavior layer that supports triage and prioritization when paired with guest telemetry, application logs, endpoint telemetry, and SIEM correlation.

‍ ‍

Rule 1

‍ ‍

Exposed Azure Hosting-Control VM with Suspicious Outbound or Security Behavior

‍ ‍

Rule Format

‍ ‍

Azure Monitor / Microsoft Sentinel KQL detection pattern suitable for deployment after subscription, resource group, workspace, table, field, asset inventory, watchlist, NSG Flow Log, DNS, Azure Firewall, Application Gateway, Defender for Cloud, and Sentinel validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect internet-exposed Azure-hosted cPanel, WHM, WP Squared, or related hosting-control virtual machines that show suspicious outbound communication, DNS activity, Azure Firewall activity, Defender for Cloud findings, or other cloud-native security behavior.

‍ ‍

·        Identify cloud-observable suspected compromise or high-priority triage conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success, guest-level execution, hosted-content modification, control-panel account change, or tenant impact without guest operating system, application, endpoint, or SIEM evidence.

‍ ‍

Detection Logic

‍ ‍

·        Identify Azure virtual machines, network interfaces, public IPs, or load-balanced targets inventoried as cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Confirm that the asset is internet-facing through public IP assignment, internet-facing load balancer exposure, NSG ingress, Application Gateway exposure, Azure Firewall activity, external reachability context, or exposure-management inventory.

‍ ‍

·        Correlate exposed hosting-control assets with outbound communication, DNS activity, Defender for Cloud findings, Azure Firewall events, proxy events, or network activity inconsistent with expected hosting-control operations.

‍ ‍

·        Treat the alert as higher priority when the asset was exposed before patch validation or when Azure-native findings align with guest-level suspicious activity from endpoint, application, or SIEM telemetry.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating guest-level or application-layer evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Azure virtual machine inventory.

‍ ‍

·        Hosting-control-plane asset watchlist, CMDB export, Defender inventory table, Azure Resource Graph export, or custom asset table.

‍ ‍

·        Network interface and public IP context.

‍ ‍

·        NSG configuration and NSG Flow Logs where available.

‍ ‍

·        Azure Firewall logs where available.

‍ ‍

·        Azure DNS or DNS resolver logs where available.

‍ ‍

·        Application Gateway or load balancer logs where available.

‍ ‍

·        Defender for Cloud findings where available.

‍ ‍

·        Microsoft Sentinel incident or alert context where available.

‍ ‍

·        Subscription, resource group, VM name, network interface, private IP, public IP, source IP, destination IP, destination port, protocol, traffic direction, and timestamp.

‍ ‍

·        Approved outbound destination context where available.

‍ ‍

·        Approved administrator source and maintenance context where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate Azure subscription, resource group, virtual machine, network interface, public IP, load balancer, Application Gateway, NSG, Azure Firewall, Defender for Cloud, and Sentinel workspace inventory before deployment.

‍ ‍

·        Scope the rule to Azure virtual machines, NICs, public IPs, or backend pools known to host cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Use a validated asset inventory source such as a Sentinel watchlist, CMDB export, Azure Resource Graph export, Defender inventory table, or custom asset table to identify hosting-control-plane systems.

‍ ‍

·        Validate that NSG Flow Logs, Azure Firewall logs, DNS logs, Application Gateway logs, Defender for Cloud findings, and Sentinel alerts are enabled where applicable.

‍ ‍

·        Normalize local asset identity across VM inventory, NICs, public IPs, NSG Flow Logs, Azure Firewall logs, DNS logs, Application Gateway logs, Defender for Cloud, Sentinel, and SIEM asset records.

‍ ‍

·        Maintain approved outbound destinations, expected update repositories, backup destinations, monitoring destinations, hosting-provider support context, and known administrative sources.

‍ ‍

·        Treat Azure exposure state and cloud-native network behavior as prioritization context, not standalone proof of compromise.

‍ ‍

·        Route alerts to SIEM correlation with control-panel access logs, authentication/session telemetry, endpoint process telemetry, file-system telemetry, and administrative action logs.

‍ ‍

·        Do not escalate to confirmed compromise without guest-level or application-layer corroboration.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

6.5 / 10

‍ ‍

·        The rule is behaviorally anchored to exposed hosting-control assets showing suspicious cloud-observable network or security behavior.

‍ ‍

·        The rule remains useful if exploit request formatting, source infrastructure, scanner name, user agent, payload structure, or public proof-of-concept content changes.

‍ ‍

·        The score is supported by exposure-aware monitoring and cloud-native visibility into outbound communication, DNS activity, firewall activity, and Defender for Cloud findings.

‍ ‍

·        The score is constrained because Azure-native telemetry cannot directly validate cPanel authentication state, control-panel sessions, guest process execution, hosted-content modification, or tenant impact.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

5.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

7.0 / 10

‍ ‍

·        Operational confidence depends on Azure VM tagging or inventory accuracy, exposure inventory, NSG Flow Logs, DNS logging, Azure Firewall logs, Application Gateway logs, Defender for Cloud findings, Sentinel context, and approved-destination baselines.

‍ ‍

·        Operational confidence is reduced where hosting-control systems are not accurately inventoried, DNS logging is unavailable, flow logs lack useful context, Defender for Cloud coverage is incomplete, or outbound destinations are not baselined.

‍ ‍

·        Full-telemetry confidence improves when Azure-native telemetry is enriched with guest endpoint telemetry, control-panel access logs, authentication/session logs, file-system telemetry, and SIEM correlation.

‍ ‍

·        Even under full telemetry conditions, Azure remains a supporting visibility layer rather than a standalone compromise-confirmation source.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious cloud-observable exposure and network behavior, not confirmed exploitation.

‍ ‍

·        Azure-native telemetry does not directly observe cPanel authentication flow, control-panel session validity, guest shell execution, hosted-content modification, control-panel account changes, or tenant-level impact.

‍ ‍

·        Legitimate patching, package updates, backups, monitoring, customer traffic, DNS resolution, content delivery, and hosting-provider support may overlap with suspicious network behavior.

‍ ‍

·        Missing DNS logs, incomplete NSG Flow Logs, absent Azure Firewall or Application Gateway telemetry, weak asset inventory, incomplete Defender for Cloud coverage, or missing approved-destination context can reduce confidence.

‍ ‍

·        Confirmation requires correlation with control-panel access, authentication/session anomalies, endpoint execution, account modification, hosted-content modification, outbound process attribution, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

// Azure Monitor / Microsoft Sentinel normalized detection pattern.
// Validate workspace table names, field names, subscription scope, resource scope, asset inventory source, and log source availability before deployment.
// HostingControlPlaneAssets_CL may be replaced with a Sentinel watchlist, CMDB export, Azure Resource Graph export, Defender inventory table, or other validated asset inventory source.

let HostingAssets =
    HostingControlPlaneAssets_CL
    | extend VMResourceId = tolower(tostring(ResourceId))
    | extend VMName = tostring(Computer)
    | extend SubscriptionId = tostring(SubscriptionId)
    | extend ResourceGroup = tostring(ResourceGroup)
    | extend Location = tostring(Location)
    | extend AssetRole = tostring(AssetRole)
    | extend PatchStatus = tostring(PatchStatus)
    | extend ExposureStatus = tostring(ExposureStatus)
    | where AssetRole in~ ("cpanel", "whm", "wp_squared", "hosting_control_plane")
    | project
        VMResourceId,
        VMName,
        SubscriptionId,
        ResourceGroup,
        Location,
        AssetRole,
        PatchStatus,
        ExposureStatus;

let ApprovedOutbound =
    datatable(Destination:string)
    [
        // Populate with approved update repositories, backup destinations, monitoring destinations, and support infrastructure.
    ];

let SuspiciousOutbound =
    AzureNetworkAnalytics_CL
    | extend
        VMResourceId = tolower(tostring(ResourceId)),
        SourceIP = tostring(SrcIP_s),
        DestinationIP = tostring(DestIP_s),
        DestinationPort = tostring(DestPort_d),
        Protocol = tostring(L4Protocol_s),
        FlowDirection = tostring(FlowDirection_s),
        FlowTime = TimeGenerated
    | where FlowDirection =~ "Outbound"
    | where isnotempty(DestinationIP)
    | where ipv4_is_private(DestinationIP) == false
    | join kind=leftanti ApprovedOutbound on $left.DestinationIP == $right.Destination
    | project
        FlowTime,
        VMResourceId,
        SourceIP,
        DestinationIP,
        DestinationPort,
        Protocol;

let DefenderContext =
    SecurityAlert
    | where ProductName has_any ("Microsoft Defender for Cloud", "Azure Security Center")
    | extend EntitiesText = tostring(Entities)
    | extend VMResourceId = tolower(extract(@"(?i)(/subscriptions/[^""]+/resourceGroups/[^""]+/providers/Microsoft\.Compute/virtualMachines/[^""]+)", 1, EntitiesText))
    | extend FindingName = AlertName
    | extend FindingSeverity = AlertSeverity
    | extend FindingTime = TimeGenerated
    | where isnotempty(VMResourceId)
    | project
        FindingTime,
        VMResourceId,
        FindingName,
        FindingSeverity;

HostingAssets
| where ExposureStatus =~ "internet-facing"
| join kind=inner SuspiciousOutbound on VMResourceId
| join kind=leftouter DefenderContext on VMResourceId
| where PatchStatus !~ "validated_patched" or isnotempty(FindingName)
| project
    FlowTime,
    SubscriptionId,
    ResourceGroup,
    Location,
    VMName,
    VMResourceId,
    AssetRole,
    ExposureStatus,
    PatchStatus,
    SourceIP,
    DestinationIP,
    DestinationPort,
    Protocol,
    FindingName,
    FindingSeverity,
    FindingTime

Rule 2

Hosting Server Foothold Followed by Azure Control-Plane or Cloud-Service Impact

Rule Format

Microsoft Entra ID, Azure Activity, Microsoft Defender for Cloud, Microsoft Sentinel, Azure Monitor, Azure Resource Graph, Azure Storage, Azure DNS, Azure Network, Azure Key Vault, Azure Compute, and cloud workload correlation pattern suitable for deployment after tenant, subscription, workload, identity, resource, network, DNS, storage, key vault, tag, and exception validation.

Detection Purpose

Detect suspicious Azure control-plane, identity, storage, DNS, key vault, compute, network, or cloud-service activity that occurs after suspicious activity on Azure-hosted or Azure-adjacent hosting infrastructure associated with cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, or customer-facing hosted application workloads.

This rule is intended to identify conditional downstream cloud-impact behavior where a hosting-server foothold, webshell interaction, FTP foothold, hosted-content tampering, shared-hosting escalation, control-panel-adjacent compromise, or post-remediation recurrence may lead to Azure credential use, service principal abuse, managed identity abuse, role assignment change, storage access, DNS manipulation, key vault access, virtual machine manipulation, disk or snapshot activity, network exposure change, or other cloud-service impact.

This rule does not claim Azure compromise from hosting-server activity alone. Azure activity must be correlated with affected hosting assets, workload identities, managed identities, service principals, user accounts, public IPs, private IPs, subscriptions, resource groups, virtual networks, DNS zones, storage accounts, key vaults, virtual machines, disks, network security groups, application gateways, load balancers, or another locally validated cloud-lineage key.

Detection Logic

Trigger when suspicious Azure activity involving a hosting-related workload, identity, resource, network path, DNS zone, storage location, key vault, or affected asset occurs after or near suspicious hosting-server activity, access-path evidence, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Require both conditions within a bounded investigation window:

·        A hosting-risk context is present. This may include suspicious hosting-control access, suspicious FTP activity, webshell evidence, hosted-content modification, symlink or permission anomaly, root-context activity, suspicious outbound communication, abuse report, customer ticket, phishing report, malware report, spam report, blocklist entry, post-remediation recurrence, or a validated affected Azure-hosted hosting workload.

·        Azure telemetry shows unusual or unauthorized cloud activity involving the same hosting workload, virtual machine, managed identity, service principal, user, role assignment, public IP, private IP, subscription, resource group, virtual network, subnet, network security group, DNS zone, domain, storage account, key vault, disk, snapshot, image, load balancer, application gateway, tenant, reseller, customer, or incident context outside approved support, backup, migration, deployment, DNS, storage, key vault, monitoring, scanning, incident-response, and maintenance workflows.

Prioritize identity and access activity involving risky sign-in, unfamiliar source infrastructure, service principal credential addition, application secret or certificate addition, managed identity assignment, role assignment creation, privilege escalation, conditional-access bypass context, disabled security control, new owner assignment, privileged Entra role activation, abnormal token use, or activity involving identities linked to hosting workloads.

Prioritize compute activity involving virtual machine start, stop, restart, redeploy, run command, custom script extension, VMAccess extension, image creation, snapshot creation, disk export, disk attach, disk detach, boot diagnostics access, serial console activity, managed identity assignment, or extension modification involving hosting-related workloads.

Prioritize network activity involving network security group rule creation, inbound exposure changes, public IP association, route table changes, NAT gateway changes, load balancer changes, application gateway changes, firewall policy changes, private endpoint changes, unexpected region changes, subnet changes, or peering changes involving hosting-related workloads.

Prioritize Azure DNS activity involving DNS zone, record-set, NS, A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, or delegation changes involving hosted customer domains, mail flows, control-panel-managed zones, or domains tied to affected hosting assets.

Prioritize storage activity involving storage account key listing, key regeneration, SAS token creation, container access changes, blob access, blob copy, blob deletion, public access changes, firewall rule changes, diagnostic setting changes, versioning changes, lifecycle changes, replication changes, or logging changes involving hosting backups, customer data, web content, logs, support artifacts, or incident-response artifacts.

Prioritize Key Vault activity involving secret read, certificate read, key read, access policy change, RBAC assignment change, purge-protection change, soft-delete change, firewall change, diagnostic setting change, or unusual access by a hosting-related identity or workload.

Prioritize Microsoft Defender for Cloud, Sentinel, Entra ID Protection, Azure Monitor, Azure Activity, Azure Resource Graph, NSG Flow Log, DNS, proxy, WAF, CDN, firewall, or NDR findings that align with affected hosting assets, unusual destinations, known abused services, unexpected regions, anonymization infrastructure, suspicious outbound transfer, credential misuse, or post-remediation recurrence.

Do not treat Azure activity as confirmed compromise when it consists only of routine deployment, scaling, patching, backup, migration, DNS administration, storage administration, key vault administration, infrastructure-as-code execution, monitoring, vulnerability scanning, or incident-response cleanup. Require reliable cloud-lineage correlation to the hosting-risk context before classifying the activity as probable downstream cloud impact from hosting-control or shared-hosting compromise.

Required Telemetry

·        Microsoft Entra ID sign-in logs, audit logs, service principal activity, managed identity activity where available, risky user and risky sign-in telemetry where available, privileged identity activity where available, and conditional access context where available.

·        Azure Activity logs across all relevant tenants, subscriptions, resource groups, and regions.

·        Microsoft Defender for Cloud, Microsoft Sentinel, Azure Monitor, Azure Resource Graph, Azure Policy, Azure Advisor, Azure Network Watcher, NSG Flow Logs, Azure Firewall, Application Gateway, Front Door, CDN, WAF, DNS, and incident-response telemetry where available.

·        Azure Resource Manager activity for subscriptions, resource groups, virtual machines, disks, snapshots, images, VM extensions, managed identities, role assignments, network security groups, route tables, public IPs, load balancers, application gateways, private endpoints, storage accounts, key vaults, DNS zones, and diagnostic settings.

·        Azure Storage telemetry for storage accounts, containers, blobs, access keys, SAS tokens, public access settings, firewall settings, private endpoints, object access, copy, deletion, logging, lifecycle, and replication where available.

·        Azure Key Vault telemetry for secret, key, certificate, access-policy, RBAC, firewall, purge-protection, soft-delete, diagnostic-setting, and unusual-access events where available.

·        Local enrichment for hosting workloads, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, shared-hosting assets, reseller-hosting assets, customer-facing hosted applications, hosted domains, customer webroots, FTP accounts, control-panel accounts, tenants, resellers, public IPs, private IPs, subscriptions, resource groups, virtual networks, subnets, managed identities, service principals, user accounts, storage accounts, key vaults, DNS zones, virtual machines, disks, network security groups, approved administrators, approved support users, approved automation identities, approved deployment identities, approved CI/CD identities, approved backup identities, approved DNS workflows, approved scanners, approved monitoring systems, approved maintenance windows, and approved incident-response workflows.

Engineering Implementation Instructions

Create and validate Azure asset and identity mappings before deployment. At minimum, the engineer or admin must map tenant IDs, subscription IDs, resource groups, regions, Azure virtual machine IDs, managed identities, service principals, user accounts, app registrations, role assignments, public IPs, private IPs, network security groups, virtual networks, subnets, DNS zones, hosted domains, storage accounts, key vaults, disks, snapshots, image resources, workload tags, application tags, customer tags, tenant mappings, reseller mappings, and hosting-platform tags to the local detection schema.

Create and validate Azure asset groups for Azure_Hosting_Workloads, Azure_Shared_Hosting_Workloads, Azure_Reseller_Hosting_Workloads, Azure_cPanel_Workloads, Azure_WHM_Workloads, Azure_DNSOnly_Workloads, Azure_WP_Squared_Workloads, Azure_LiteSpeed_cPanel_Plugin_Workloads, Azure_LiteSpeed_WHM_Plugin_Workloads, Azure_CloudLinux_CageFS_Workloads, Azure_Customer_Facing_Hosted_Applications, Azure_High_Value_Hosting_Workloads, Azure_Hosted_Domains, Azure_Hosting_DNS_Zones, Azure_Hosting_Storage_Accounts, Azure_Hosting_Key_Vaults, Azure_Hosting_Managed_Identities, Azure_Hosting_Service_Principals, Azure_Hosting_User_Accounts, Azure_Hosting_Public_IPs, and Azure_Hosting_Private_IPs.

Create and validate approved-context lists for Azure_Approved_Hosting_Admins, Azure_Approved_Support_Identities, Azure_Approved_Automation_Identities, Azure_Approved_Deployment_Identities, Azure_Approved_CICD_Identities, Azure_Approved_Backup_Identities, Azure_Approved_DNS_Admin_Identities, Azure_Approved_Storage_Admin_Identities, Azure_Approved_Key_Vault_Admin_Identities, Azure_Approved_Scanner_Identities, Azure_Approved_Monitoring_Identities, Azure_Approved_Source_Networks, Azure_Approved_Backup_Destinations, Azure_Approved_Package_Repositories, Azure_Approved_CDN_Providers, Azure_Approved_Maintenance_Windows, Azure_Approved_Incident_Response_Workflows, and Azure_Hosting_Exception_Groups.

The engineer or admin must establish cloud lineage between hosting-risk telemetry and Azure telemetry before promotion to alert mode. Acceptable lineage may include virtual machine ID, public IP, private IP, managed identity, service principal, user account, workload tag, DNS zone, hosted domain, storage account, key vault, subscription, resource group, virtual network, subnet, network security group, tenant, reseller, customer, or incident key. Tenant ID, subscription ID, or resource group alone should not be used as sufficient lineage because it can over-correlate unrelated cloud activity in large or shared Azure environments.

The engineer or admin must validate Azure logging coverage across all relevant tenants, subscriptions, resource groups, and regions. Confirm that Azure Activity logs are centralized, Entra ID logs are retained, service principal and app activity is available, managed identity relationships are mapped, diagnostic settings are enabled for relevant resources, and the selected query backend preserves event time, operation name, category, caller, caller IP, user principal name, app ID, service principal ID, managed identity ID, resource ID, resource group, subscription ID, tenant ID, region, request body where available, response status, result type, correlation ID, and resource identifiers.

The engineer or admin must validate service-specific visibility for Entra ID, Azure Activity, Defender for Cloud, Sentinel, Resource Graph, Azure Monitor, Azure Storage, Azure DNS, Key Vault, Virtual Machines, Disks, Snapshots, Network Security Groups, Load Balancers, Application Gateways, Public IPs, Private Endpoints, Azure Firewall, Front Door, CDN, WAF, and relevant incident-response tooling. Missing diagnostic settings, incomplete Entra retention, untagged workloads, incomplete subscription inventory, missing managed identity mapping, or missing storage and key vault audit coverage should keep this rule in hunt mode until compensating telemetry is available.

The engineer or admin must baseline approved Azure workflows before alert promotion. Baseline infrastructure-as-code deployments, VM scale operations, patching, package updates, backups, migrations, DNS administration, certificate renewal, storage operations, key vault operations, image creation, snapshot creation, incident-response cleanup, vulnerability scanning, monitoring, managed service operations, and support workflows. Exceptions should require identity, role, source network, tenant, subscription, resource group, region, resource, operation pattern, and maintenance-window validation.

The engineer or admin must configure alert grouping by tenant, subscription, hosting workload, virtual machine ID, managed identity, service principal, user account, hosted domain, DNS zone, storage account, key vault, virtual network, network security group, public IP, private IP, tenant mapping, reseller mapping, customer mapping, or local incident key. Avoid grouping only by caller IP because legitimate automation, support access, cloud service infrastructure, or attacker-controlled infrastructure may rotate source addresses or use shared service ranges.

The engineer or admin must validate query performance before production alerting. Avoid broad joins over all AzureActivity, AuditLogs, SigninLogs, StorageBlobLogs, KeyVaultLogs, and network logs. Scope candidate events by operation name, category, tenant, subscription, region, hosting-related asset groups, resource IDs, identities, DNS zones, storage accounts, key vaults, virtual machines, public IPs, network security groups, and bounded time windows. Where the query backend cannot safely search serialized properties at scale, precompute resource identifiers, identity IDs, DNS zones, storage accounts, key vault names, VM IDs, public IPs, private IPs, network security group IDs, operation classes, and cloud-lineage fields into normalized columns before alerting.

The engineer or admin must validate that Azure findings are triaged as conditional downstream cloud-impact evidence unless the Azure telemetry independently supports unauthorized activity. Confirmed compromise requires corroborating evidence such as unauthorized role assignment, suspicious service principal credential use, abnormal managed identity activity, storage access, DNS manipulation, key vault access, VM modification, disk or snapshot activity, network exposure change, outbound transfer, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Deploy initially in hunt mode for at least one business cycle that includes deployment, patching, backup, migration, DNS, storage, key vault, monitoring, scanning, support, incident-response, and customer-maintenance activity. Promote to alert mode only after cloud lineage, asset groups, identity mappings, exception lists, telemetry coverage, query performance, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has moderate-to-strong detection relevance because hosting-control compromise and shared-hosting escalation can create downstream risk to Azure identities, hosted domains, storage accounts, key vaults, virtual machines, disks, snapshots, network exposure, and customer-facing cloud resources when the affected hosting workload has managed identities, service principals, privileged access, DNS authority, storage access, key vault access, backup access, or customer-data access. The rule is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on Azure control-plane and cloud-service activity linked to hosting-risk context rather than static indicators. The score is constrained because Azure telemetry does not directly observe cPanel, WHM, LiteSpeed plugin, CloudLinux/CageFS, or tenant-boundary exploitation unless hosting telemetry or cloud-resource lineage is available.

DRI

7.5

TCR Assessment

Operational confidence depends on centralized Azure Activity logs, Entra ID logging, correct tenant and subscription coverage, service principal and managed identity mapping, workload tagging, hosting asset enrichment, Azure DNS visibility, storage audit coverage, Key Vault audit coverage, network telemetry, Defender for Cloud or Sentinel findings, and reliable linkage between hosting-risk telemetry and Azure resources. Confidence is reduced where hosting workloads are untagged, diagnostic settings are missing, Entra logs are not retained, storage or key vault logs are incomplete, identities are shared, managed identities are poorly scoped, serialized properties are not normalized, or hosting-to-cloud lineage is unavailable.

Operational TCR

7.0

Full-Telemetry TCR

8.5

Limitations

This rule detects conditional Azure cloud-impact behavior, not direct cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, or tenant-spanning access. Azure telemetry cannot confirm hosting compromise without local hosting, endpoint, web, FTP, file, symlink, DNS, mail, abuse-report, or tenant-impact correlation. Legitimate infrastructure-as-code deployments, VM scaling, patching, backup, migration, DNS administration, certificate renewal, storage administration, key vault administration, image creation, snapshot creation, monitoring, vulnerability scanning, managed service operations, support, and incident-response cleanup may overlap with this behavior. Confirmation requires validated lineage and corroborating cloud activity involving identity, compute, network, DNS, storage, key vault, customer data, abuse reports, or post-remediation recurrence.

Detection Query Pattern

Use this pattern as a Microsoft Sentinel, Log Analytics, Azure Monitor, Azure Resource Graph, or SIEM implementation guide. Customer-specific table names, field names, resource tags, tenant mappings, subscription mappings, resource group mappings, asset groups, identity mappings, precomputed resource columns, and exception lists must be validated before deployment. Tenant ID, subscription ID, or resource group alone should not be treated as sufficient lineage.

let HostingContext =
customer_hosting_risk_context
| where hosting_platform in (
"cPanel",
"WHM",
"DNSOnly",
"WP Squared",
"LiteSpeed cPanel Plugin",
"LiteSpeed WHM Plugin",
"CloudLinux/CageFS",
"Shared Hosting",
"Reseller Hosting"
)
| where risk_context in (
"suspicious_hosting_control_access",
"suspicious_ftp_activity",
"web_shell_evidence",
"hosted_content_modification",
"symlink_or_permission_anomaly",
"suspicious_outbound_activity",
"abuse_report",
"customer_ticket",
"post_remediation_recurrence",
"validated_affected_hosting_workload"
)
| project
tenant_id,
subscription_id,
resource_group,
resource_id,
vm_id,
private_ip,
public_ip,
managed_identity_id,
service_principal_id,
user_principal_name,
dns_zone,
hosted_domain,
storage_account,
key_vault,
virtual_network_id,
subnet_id,
network_security_group_id,
tenant_mapping,
reseller_id,
customer_id,
incident_key,
first_seen,
last_seen;

let AzureApprovedSources =
Azure_Approved_Source_Networks
| project approved_source_ip = source_ip;

let AzureApprovedCallers =
union
(Azure_Approved_Hosting_Admins | project approved_caller = caller),
(Azure_Approved_Support_Identities | project approved_caller = caller),
(Azure_Approved_Automation_Identities | project approved_caller = caller),
(Azure_Approved_Deployment_Identities | project approved_caller = caller),
(Azure_Approved_Backup_Identities | project approved_caller = caller),
(Azure_Approved_DNS_Admin_Identities | project approved_caller = caller),
(Azure_Approved_Storage_Admin_Identities | project approved_caller = caller),
(Azure_Approved_Key_Vault_Admin_Identities | project approved_caller = caller);

let AzureCandidateEvents =
AzureActivity
| where OperationNameValue in (
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleDefinitions/write",
"Microsoft.ManagedIdentity/userAssignedIdentities/assign/action",
"Microsoft.Compute/virtualMachines/write",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/runCommand/action",
"Microsoft.Compute/virtualMachines/extensions/write",
"Microsoft.Compute/snapshots/write",
"Microsoft.Compute/disks/write",
"Microsoft.Compute/images/write",
"Microsoft.Network/networkSecurityGroups/securityRules/write",
"Microsoft.Network/publicIPAddresses/write",
"Microsoft.Network/loadBalancers/write",
"Microsoft.Network/applicationGateways/write",
"Microsoft.Network/routeTables/write",
"Microsoft.Network/privateEndpoints/write",
"Microsoft.Network/azureFirewalls/write",
"Microsoft.Network/frontDoors/write",
"Microsoft.Network/dnsZones/write",
"Microsoft.Network/dnsZones/A/write",
"Microsoft.Network/dnsZones/CNAME/write",
"Microsoft.Network/dnsZones/MX/write",
"Microsoft.Network/dnsZones/TXT/write",
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/regenerateKey/action",
"Microsoft.Storage/storageAccounts/blobServices/containers/write",
"Microsoft.Storage/storageAccounts/blobServices/containers/delete",
"Microsoft.KeyVault/vaults/write",
"Microsoft.KeyVault/vaults/accessPolicies/write"
)
| project
TimeGenerated,
TenantId,
SubscriptionId,
ResourceGroup,
ResourceId,
OperationNameValue,
ActivityStatusValue,
Caller,
CallerIpAddress,
CorrelationId,
Category,
ResourceProviderValue,
Properties,
resource_vm_id,
resource_private_ip,
resource_public_ip,
resource_managed_identity_id,
resource_service_principal_id,
resource_dns_zone,
resource_hosted_domain,
resource_storage_account,
resource_key_vault,
resource_virtual_network_id,
resource_subnet_id,
resource_network_security_group_id;

AzureCandidateEvents
| join kind=inner HostingContext on $left.TenantId == $right.tenant_id
| where TimeGenerated between ((first_seen - 2h) .. (last_seen + 24h))
| where SubscriptionId == subscription_id
| where (
ResourceId == resource_id
or resource_vm_id == vm_id
or resource_private_ip == private_ip
or resource_public_ip == public_ip
or resource_managed_identity_id == managed_identity_id
or resource_service_principal_id == service_principal_id
or Caller == user_principal_name
or resource_dns_zone == dns_zone
or resource_hosted_domain == hosted_domain
or resource_storage_account == storage_account
or resource_key_vault == key_vault
or resource_virtual_network_id == virtual_network_id
or resource_subnet_id == subnet_id
or resource_network_security_group_id == network_security_group_id
or tostring(Properties) has vm_id
or tostring(Properties) has public_ip
or tostring(Properties) has hosted_domain
or tostring(Properties) has dns_zone
or tostring(Properties) has storage_account
or tostring(Properties) has key_vault
or tostring(Properties) has network_security_group_id
)
| join kind=leftanti AzureApprovedSources on $left.CallerIpAddress == $right.approved_source_ip
| join kind=leftanti AzureApprovedCallers on $left.Caller == $right.approved_caller
| where not(
incident_key in (Azure_Approved_Incident_Response_Workflows)
or ResourceId in (Azure_Hosting_Exception_Groups)
)
| project
TimeGenerated,
TenantId,
SubscriptionId,
ResourceGroup,
ResourceId,
OperationNameValue,
ActivityStatusValue,
Caller,
CallerIpAddress,
CorrelationId,
incident_key,
vm_id,
public_ip,
private_ip,
managed_identity_id,
service_principal_id,
hosted_domain,
dns_zone,
storage_account,
key_vault,
tenant_mapping,
reseller_id,
customer_

GCP

‍

Detection Viability Assessment

‍ ‍

GCP has two conditional rule for this EXP report.

‍ ‍

·        GCP is viable for cloud-native visibility when cPanel, WHM, WP Squared, or related hosting-control systems are hosted on Compute Engine and GCP telemetry can identify exposed assets, outbound communication, DNS activity, Cloud Armor or load balancer activity, Security Command Center findings, or SIEM correlation.

‍ ‍

·        GCP is not viable as a standalone source for confirming authentication-bypass success, control-panel session validity, guest operating system execution, hosted-content modification, cPanel account changes, or tenant blast radius.

‍ ‍

·        GCP is strongest as a conditional exposure and network-behavior layer that supports triage and prioritization when paired with guest telemetry, application logs, endpoint telemetry, and SIEM correlation.

‍ ‍

Rule 1

‍ ‍

Exposed GCP Hosting-Control VM with Suspicious Outbound or Security Behavior

‍ ‍

Rule Format

‍ ‍

GCP Cloud Logging / BigQuery normalized detection pattern suitable for deployment after project, folder, organization, log sink, dataset, table, field, asset inventory, VPC Flow Log, Cloud DNS, Cloud Armor, load balancer, Security Command Center, and SIEM validation.

‍ ‍

Detection Purpose

‍ ‍

·        Detect internet-exposed GCP-hosted cPanel, WHM, WP Squared, or related hosting-control virtual machines that show suspicious outbound communication, DNS activity, Cloud Armor activity, load balancer activity, Security Command Center findings, or other cloud-native security behavior.

‍ ‍

·        Identify cloud-observable suspected compromise or high-priority triage conditions without depending on CVE strings, public proof-of-concept payloads, scanner names, attacker IP addresses, or one exploit implementation.

‍ ‍

·        This rule does not confirm authentication-bypass success, guest-level execution, hosted-content modification, control-panel account change, or tenant impact without guest operating system, application, endpoint, or SIEM evidence.

‍ ‍

Detection Logic

‍ ‍

·        Identify Compute Engine instances, network interfaces, external IPs, or load-balanced backends inventoried as cPanel, WHM, WP Squared, or related hosting-control systems.

‍ ‍

·        Confirm that the asset is internet-facing through external IP assignment, external load balancer exposure, firewall rule exposure, Cloud Armor activity, external reachability context, or exposure-management inventory.

‍ ‍

·        Correlate exposed hosting-control assets with outbound communication, DNS activity, Security Command Center findings, Cloud Armor events, load balancer events, or network activity inconsistent with expected hosting-control operations.

‍ ‍

·        Treat the alert as higher priority when the asset was exposed before patch validation or when GCP-native findings align with guest-level suspicious activity from endpoint, application, or SIEM telemetry.

‍ ‍

·        Do not classify the activity as confirmed compromise without corroborating guest-level or application-layer evidence.

‍ ‍

Required Telemetry

‍ ‍

·        Compute Engine asset inventory.

‍ ‍

·        Hosting-control-plane asset labels, CMDB export, Security Command Center asset inventory, Cloud Asset Inventory export, or custom asset table.

‍ ‍

·        Network interface and external IP context.

‍ ‍

·        Firewall rule exposure context.

‍ ‍

·        VPC Flow Logs where available.

‍ ‍

·        Cloud DNS logs where available.

‍ ‍

·        Cloud Armor logs where available.

‍ ‍

·        External HTTP(S) Load Balancer logs where available.

‍ ‍

·        Security Command Center findings where available.

‍ ‍

·        Project, folder, organization, instance name, zone, network interface, private IP, external IP, source IP, destination IP, destination port, protocol, traffic direction where available, and timestamp.

‍ ‍

·        Approved outbound destination context where available.

‍ ‍

·        Approved administrator source and maintenance context where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

·        Validate GCP organization, folder, project, Compute Engine instance, network interface, external IP, firewall rule, Cloud Armor, load balancer, Cloud DNS, Security Command Center, and logging sink coverage before deployment.

‍ ‍

·        Scope the rule to Compute Engine instances, network interfaces, external IPs, or backend services known to host cPanel, WHM, WP Squared, or related hosting-control services.

‍ ‍

·        Use a validated asset inventory source such as a BigQuery asset table, CMDB export, Security Command Center asset inventory, Cloud Asset Inventory export, or custom inventory table to identify hosting-control-plane systems.

‍ ‍

·        Validate that VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, load balancer logs, Security Command Center findings, and SIEM exports are enabled where applicable.

‍ ‍

·        Normalize local asset identity across Compute Engine inventory, network interfaces, external IPs, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, load balancer logs, Security Command Center, and SIEM asset records.

‍ ‍

·        Prefer local asset matching by project and private IP where VPC Flow Logs do not reliably preserve instance resource identifiers.

‍ ‍

·        Maintain approved outbound destinations, expected update repositories, backup destinations, monitoring destinations, hosting-provider support context, and known administrative sources.

‍ ‍

·        Treat GCP exposure state and cloud-native network behavior as prioritization context, not standalone proof of compromise.

‍ ‍

·        Route alerts to SIEM correlation with control-panel access logs, authentication/session telemetry, endpoint process telemetry, file-system telemetry, and administrative action logs.

‍ ‍

·        Do not escalate to confirmed compromise without guest-level or application-layer corroboration.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

6.5 / 10

‍ ‍

·        The rule is behaviorally anchored to exposed hosting-control assets showing suspicious cloud-observable network or security behavior.

‍ ‍

·        The rule remains useful if exploit request formatting, source infrastructure, scanner name, user agent, payload structure, or public proof-of-concept content changes.

‍ ‍

·        The score is supported by exposure-aware monitoring and cloud-native visibility into outbound communication, DNS activity, load balancer activity, Cloud Armor activity, and Security Command Center findings.

‍ ‍

·        The score is constrained because GCP-native telemetry cannot directly validate cPanel authentication state, control-panel sessions, guest process execution, hosted-content modification, or tenant impact.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

5.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

7.0 / 10

‍ ‍

·        Operational confidence depends on Compute Engine asset inventory accuracy, exposure inventory, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, load balancer logs, Security Command Center findings, SIEM context, and approved-destination baselines.

‍ ‍

·        Operational confidence is reduced where hosting-control systems are not accurately inventoried, DNS logging is unavailable, flow logs lack useful context, Security Command Center coverage is incomplete, or outbound destinations are not baselined.

‍ ‍

·        Full-telemetry confidence improves when GCP-native telemetry is enriched with guest endpoint telemetry, control-panel access logs, authentication/session logs, file-system telemetry, and SIEM correlation.

‍ ‍

·        Even under full telemetry conditions, GCP remains a supporting visibility layer rather than a standalone compromise-confirmation source.

‍ ‍

Limitations

‍ ‍

·        This rule detects suspicious cloud-observable exposure and network behavior, not confirmed exploitation.

‍ ‍

·        GCP-native telemetry does not directly observe cPanel authentication flow, control-panel session validity, guest shell execution, hosted-content modification, control-panel account changes, or tenant-level impact.

‍ ‍

·        Legitimate patching, package updates, backups, monitoring, customer traffic, DNS resolution, content delivery, and hosting-provider support may overlap with suspicious network behavior.

‍ ‍

·        Missing DNS logs, incomplete VPC Flow Logs, absent Cloud Armor or load balancer telemetry, weak asset inventory, incomplete Security Command Center coverage, or missing approved-destination context can reduce confidence.

‍ ‍

·        Confirmation requires correlation with control-panel access, authentication/session anomalies, endpoint execution, account modification, hosted-content modification, outbound process attribution, or tenant-impact evidence.

‍ ‍

Detection Query Pattern

‍ ‍

-- GCP Cloud Logging / BigQuery normalized detection pattern.
-- Validate dataset names, table names, field names, project scope, folder or organization scope, asset inventory source, and log source availability before deployment.
-- HostingControlPlaneAssets may be replaced with a CMDB export, Cloud Asset Inventory export, Security Command Center asset inventory, or another validated asset inventory table.

WITH hosting_assets AS (
  SELECT
    LOWER(instance_resource_id) AS instance_resource_id,
    project_id,
    zone,
    LOWER(instance_name) AS instance_name,
    private_ip,
    external_ip,
    asset_role,
    patch_status,
    exposure_status
  FROM `customer_secops.asset_inventory.HostingControlPlaneAssets`
  WHERE LOWER(asset_role) IN ('cpanel', 'whm', 'wp_squared', 'hosting_control_plane')
),

approved_outbound AS (
  SELECT
    destination
  FROM `customer_secops.reference.approved_outbound_destinations`
),

vpc_flow_events AS (
  SELECT
    timestamp AS flow_time,
    resource.labels.project_id AS project_id,
    LOWER(COALESCE(
      jsonPayload.src_instance.vm_name,
      jsonPayload.instance.vm_name,
      resource.labels.instance_id
    )) AS instance_name,
    jsonPayload.connection.src_ip AS source_ip,
    jsonPayload.connection.dest_ip AS destination_ip,
    jsonPayload.connection.dest_port AS destination_port,
    jsonPayload.connection.protocol AS protocol,
    jsonPayload.reporter AS reporter
  FROM `customer_secops.gcp_logs.vpc_flow_logs`
  WHERE jsonPayload.connection.src_ip IS NOT NULL
    AND jsonPayload.connection.dest_ip IS NOT NULL
),

suspicious_outbound AS (
  SELECT
    v.*
  FROM vpc_flow_events v
  LEFT JOIN approved_outbound a
    ON v.destination_ip = a.destination
  WHERE a.destination IS NULL
    AND NET.SAFE_IP_FROM_STRING(v.destination_ip) IS NOT NULL
    AND NOT NET.IP_IN_NET(NET.SAFE_IP_FROM_STRING(v.destination_ip), '10.0.0.0/8')
    AND NOT NET.IP_IN_NET(NET.SAFE_IP_FROM_STRING(v.destination_ip), '172.16.0.0/12')
    AND NOT NET.IP_IN_NET(NET.SAFE_IP_FROM_STRING(v.destination_ip), '192.168.0.0/16')
    AND NOT NET.IP_IN_NET(NET.SAFE_IP_FROM_STRING(v.destination_ip), '127.0.0.0/8')
    AND NOT NET.IP_IN_NET(NET.SAFE_IP_FROM_STRING(v.destination_ip), '169.254.0.0/16')
    AND (
      LOWER(v.reporter) IN ('src', 'source')
      OR v.reporter IS NULL
    )
),

security_context AS (
  SELECT
    event_time AS finding_time,
    LOWER(resource_name) AS instance_resource_id,
    finding_category,
    finding_severity,
    finding_state
  FROM `customer_secops.gcp_logs.security_command_center_findings`
  WHERE finding_state = 'ACTIVE'
)

SELECT
  o.flow_time,
  h.project_id,
  h.zone,
  h.instance_name,
  h.instance_resource_id,
  h.external_ip,
  h.exposure_status,
  h.patch_status,
  o.source_ip,
  o.destination_ip,
  o.destination_port,
  o.protocol,
  s.finding_category,
  s.finding_severity,
  s.finding_state,
  s.finding_time
FROM hosting_assets h
JOIN suspicious_outbound o
  ON h.project_id = o.project_id
  AND (
    LOWER(h.instance_name) = o.instance_name
    OR h.private_ip = o.source_ip
  )
LEFT JOIN security_context s
  ON h.instance_resource_id = s.instance_resource_id
WHERE h.exposure_status = 'internet-facing'
  AND (
    LOWER(h.patch_status) != 'validated_patched'
    OR s.finding_category IS NOT NULL
  );

‍GCP

Rule

Hosting Server Foothold Followed by GCP Control-Plane or Cloud-Service Impact

Rule Format

Google Cloud Audit Logs, Cloud Logging, Security Command Center, Cloud Asset Inventory, VPC Flow Logs, Cloud DNS, Cloud Storage, IAM, Compute Engine, Cloud KMS, Secret Manager, and SIEM correlation pattern suitable for deployment after organization, folder, project, workload, identity, service account, resource, network, DNS, storage, key, secret, label, and exception validation.

Detection Purpose

Detect suspicious GCP control-plane, identity, storage, DNS, key-management, secret-management, compute, network, or cloud-service activity that occurs after suspicious activity on GCP-hosted or GCP-adjacent hosting infrastructure associated with cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, CloudLinux/CageFS, shared-hosting, reseller-hosting, or customer-facing hosted application workloads.

This rule is intended to identify conditional downstream cloud-impact behavior where a hosting-server foothold, webshell interaction, FTP foothold, hosted-content tampering, shared-hosting escalation, control-panel-adjacent compromise, or post-remediation recurrence may lead to GCP credential use, service-account abuse, IAM policy change, storage access, DNS manipulation, KMS key access, Secret Manager access, virtual machine manipulation, disk or snapshot activity, network exposure change, or other cloud-service impact.

This rule does not claim GCP compromise from hosting-server activity alone. GCP activity must be correlated with affected hosting assets, workload identities, service accounts, user accounts, public IPs, private IPs, projects, folders, organization context, VPC networks, DNS zones, Cloud Storage buckets, Cloud KMS keys, Secret Manager secrets, Compute Engine instances, disks, snapshots, firewall rules, load balancers, or another locally validated cloud-lineage key.

Detection Logic

Trigger when suspicious GCP activity involving a hosting-related workload, identity, resource, network path, DNS zone, storage location, KMS key, Secret Manager secret, or affected asset occurs after or near suspicious hosting-server activity, access-path evidence, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Require both conditions within a bounded investigation window:

·        A hosting-risk context is present. This may include suspicious hosting-control access, suspicious FTP activity, webshell evidence, hosted-content modification, symlink or permission anomaly, root-context activity, suspicious outbound communication, abuse report, customer ticket, phishing report, malware report, spam report, blocklist entry, post-remediation recurrence, or a validated affected GCP-hosted hosting workload.

·        GCP telemetry shows unusual or unauthorized cloud activity involving the same hosting workload, Compute Engine instance, service account, service-account key, user account, IAM principal, public IP, private IP, project, folder, VPC network, subnet, firewall rule, DNS zone, domain, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, disk, snapshot, image, load balancer, tenant, reseller, customer, or incident context outside approved support, backup, migration, deployment, DNS, storage, KMS, Secret Manager, monitoring, scanning, incident-response, and maintenance workflows.

Prioritize identity and IAM activity involving service-account key creation, service-account key deletion, service-account impersonation, service-account token generation, IAM allow-policy changes, privileged role grant, owner or editor role assignment, workload identity changes, OAuth scope changes, API enablement, project owner changes, organization policy changes, folder policy changes, or activity involving identities linked to hosting workloads.

Prioritize Compute Engine activity involving instance start, stop, reset, insert, delete, metadata changes, startup-script changes, service-account attachment, access-scope changes, disk attachment, disk detachment, image creation, snapshot creation, serial-port interaction, guest-attribute changes, OS Login changes, SSH key metadata changes, instance template changes, or managed instance group changes involving hosting-related workloads.

Prioritize network activity involving firewall rule creation, firewall rule modification, ingress exposure changes, egress exposure changes, public IP assignment, route changes, load balancer changes, forwarding rule changes, Cloud Armor policy changes, VPC peering changes, VPN changes, NAT changes, or unexpected region, subnet, or network changes involving hosting-related workloads.

Prioritize Cloud DNS activity involving managed-zone, record-set, NS, A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, or delegation changes involving hosted customer domains, mail flows, control-panel-managed zones, or domains tied to affected hosting assets.

Prioritize Cloud Storage activity involving bucket IAM change, bucket ACL change, object access, object copy, object deletion, public access change, retention-policy change, lifecycle change, versioning change, logging change, or transfer activity involving hosting backups, customer data, web content, logs, support artifacts, or incident-response artifacts.

Prioritize Cloud KMS and Secret Manager activity involving decrypt operations, key policy changes, key-ring policy changes, secret access, secret version access, secret policy changes, rotation changes, disabled key changes, destroy or restore actions, or unusual access by a hosting-related identity or workload.

Prioritize Security Command Center, Event Threat Detection, Cloud Logging, VPC Flow Logs, DNS, proxy, WAF, CDN, firewall, Cloud Armor, or NDR findings that align with affected hosting assets, unusual destinations, known abused services, unexpected regions, anonymization infrastructure, suspicious outbound transfer, credential misuse, or post-remediation recurrence.

Do not treat GCP activity as confirmed compromise when it consists only of routine deployment, scaling, patching, backup, migration, DNS administration, storage administration, KMS administration, Secret Manager administration, infrastructure-as-code execution, monitoring, vulnerability scanning, or incident-response cleanup. Require reliable cloud-lineage correlation to the hosting-risk context before classifying the activity as probable downstream cloud impact from hosting-control or shared-hosting compromise.

Required Telemetry

·        GCP Admin Activity audit logs across all relevant organizations, folders, projects, and regions.

·        GCP Data Access audit logs for Cloud Storage, Cloud KMS, Secret Manager, and other relevant services where enabled.

·        Cloud Logging, BigQuery export, Security Command Center, Event Threat Detection, Cloud Asset Inventory, Cloud Monitoring, Cloud DNS logs, VPC Flow Logs, firewall logs, load balancer logs, Cloud Armor logs, proxy logs, CDN logs, and incident-response telemetry where available.

·        IAM activity for users, groups, service accounts, service-account keys, workload identity, role bindings, custom roles, organization policies, folder policies, project policies, API enablement, and service-account impersonation.

·        Compute Engine activity for instances, instance metadata, service accounts, OAuth scopes, startup scripts, serial port, OS Login, SSH key metadata, images, snapshots, disks, instance templates, managed instance groups, firewall rules, routes, public IPs, load balancers, forwarding rules, VPC networks, subnets, peering, VPN, NAT, and Cloud Armor.

·        Cloud Storage telemetry for buckets, objects, IAM policies, ACLs, public access prevention, retention, lifecycle, versioning, logging, object reads, object writes, object deletion, copy activity, and transfer activity where available.

·        Cloud DNS telemetry for managed zones, record sets, delegations, MX, TXT, SPF, DKIM, DMARC, and hosted domain changes.

·        Cloud KMS and Secret Manager telemetry for decrypt operations, key access, secret access, IAM policy changes, rotation changes, disabled key changes, destroy or restore actions, and unusual access where available.

·        Local enrichment for hosting workloads, cPanel assets, WHM assets, DNSOnly assets, WP Squared assets, LiteSpeed cPanel Plugin assets, LiteSpeed WHM Plugin assets, CloudLinux/CageFS assets, shared-hosting assets, reseller-hosting assets, customer-facing hosted applications, hosted domains, customer webroots, FTP accounts, control-panel accounts, tenants, resellers, public IPs, private IPs, projects, folders, service accounts, service-account keys, user accounts, Cloud Storage buckets, Cloud KMS keys, Secret Manager secrets, DNS zones, Compute Engine instances, disks, firewall rules, approved administrators, approved support users, approved automation identities, approved deployment identities, approved CI/CD identities, approved backup identities, approved DNS workflows, approved storage workflows, approved KMS workflows, approved Secret Manager workflows, approved scanners, approved monitoring systems, approved maintenance windows, and approved incident-response workflows.

Engineering Implementation Instructions

Create and validate GCP asset and identity mappings before deployment. At minimum, the engineer or admin must map organization IDs, folder IDs, project IDs, regions, zones, Compute Engine instance IDs, instance names, service accounts, service-account keys, user accounts, groups, IAM role bindings, public IPs, private IPs, firewall rules, VPC networks, subnets, Cloud DNS zones, hosted domains, Cloud Storage buckets, Cloud KMS keys, Secret Manager secrets, disks, snapshots, image resources, workload labels, application labels, customer labels, tenant mappings, reseller mappings, and hosting-platform labels to the local detection schema.

Create and validate GCP asset groups for GCP_Hosting_Workloads, GCP_Shared_Hosting_Workloads, GCP_Reseller_Hosting_Workloads, GCP_cPanel_Workloads, GCP_WHM_Workloads, GCP_DNSOnly_Workloads, GCP_WP_Squared_Workloads, GCP_LiteSpeed_cPanel_Plugin_Workloads, GCP_LiteSpeed_WHM_Plugin_Workloads, GCP_CloudLinux_CageFS_Workloads, GCP_Customer_Facing_Hosted_Applications, GCP_High_Value_Hosting_Workloads, GCP_Hosted_Domains, GCP_Hosting_DNS_Zones, GCP_Hosting_Storage_Buckets, GCP_Hosting_KMS_Keys, GCP_Hosting_Secrets, GCP_Hosting_Service_Accounts, GCP_Hosting_Service_Account_Keys, GCP_Hosting_User_Accounts, GCP_Hosting_Public_IPs, and GCP_Hosting_Private_IPs.

Create and validate approved-context lists for GCP_Approved_Hosting_Admins, GCP_Approved_Support_Identities, GCP_Approved_Automation_Identities, GCP_Approved_Deployment_Identities, GCP_Approved_CICD_Identities, GCP_Approved_Backup_Identities, GCP_Approved_DNS_Admin_Identities, GCP_Approved_Storage_Admin_Identities, GCP_Approved_KMS_Admin_Identities, GCP_Approved_Secret_Manager_Admin_Identities, GCP_Approved_Scanner_Identities, GCP_Approved_Monitoring_Identities, GCP_Approved_Source_Networks, GCP_Approved_Backup_Destinations, GCP_Approved_Package_Repositories, GCP_Approved_CDN_Providers, GCP_Approved_Maintenance_Windows, GCP_Approved_Incident_Response_Workflows, and GCP_Hosting_Exception_Groups.

The engineer or admin must establish cloud lineage between hosting-risk telemetry and GCP telemetry before promotion to alert mode. Acceptable lineage may include Compute Engine instance ID, instance name, public IP, private IP, service account, service-account key, user account, workload label, DNS zone, hosted domain, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, project, folder, VPC network, subnet, firewall rule, tenant, reseller, customer, or incident key. Organization ID, folder ID, or project ID alone should not be used as sufficient lineage because it can over-correlate unrelated cloud activity in large or shared GCP environments.

The engineer or admin must validate GCP logging coverage across all relevant organizations, folders, projects, regions, and zones. Confirm that Admin Activity audit logs are available, that Data Access audit logs are enabled for relevant services where needed, that Cloud Logging exports are centralized, that Security Command Center findings are collected, that Cloud Asset Inventory is available, and that the selected query backend preserves timestamp, project ID, organization ID, folder ID, method name, service name, principal email, service-account delegation, caller IP, user agent, resource name, resource labels, request fields where available, response fields where available, status, and authorization information.

The engineer or admin must validate service-specific visibility for IAM, Service Account Credentials API, Compute Engine, Cloud Storage, Cloud DNS, Cloud KMS, Secret Manager, VPC Firewall Rules, Cloud Armor, Cloud Load Balancing, Cloud NAT, VPC Flow Logs, Security Command Center, Event Threat Detection, Cloud Asset Inventory, Cloud Logging, Cloud Monitoring, and relevant incident-response tooling. Missing Data Access logs, incomplete Cloud Logging export, untagged workloads, incomplete project inventory, missing service-account mapping, or missing Cloud Storage, KMS, and Secret Manager audit coverage should keep this rule in hunt mode until compensating telemetry is available.

The engineer or admin must baseline approved GCP workflows before alert promotion. Baseline infrastructure-as-code deployments, VM scale operations, patching, package updates, backups, migrations, DNS administration, certificate renewal, storage operations, KMS operations, Secret Manager operations, image creation, snapshot creation, incident-response cleanup, vulnerability scanning, monitoring, managed service operations, and support workflows. Exceptions should require identity, role, source network, organization, folder, project, region, zone, resource, method pattern, and maintenance-window validation.

The engineer or admin must configure alert grouping by organization, folder, project, hosting workload, Compute Engine instance ID, service account, service-account key, user account, hosted domain, DNS zone, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, VPC network, firewall rule, public IP, private IP, tenant mapping, reseller mapping, customer mapping, or local incident key. Avoid grouping only by caller IP because legitimate automation, support access, cloud service infrastructure, or attacker-controlled infrastructure may rotate source addresses or use shared service ranges.

The engineer or admin must validate query performance before production alerting. Avoid broad joins over all Cloud Audit Logs, Data Access logs, Cloud Storage logs, Cloud KMS logs, Secret Manager logs, VPC Flow Logs, and network logs. Scope candidate events by method name, service name, project, region, hosting-related asset groups, resource names, identities, DNS zones, storage buckets, KMS keys, Secret Manager secrets, Compute Engine instances, public IPs, firewall rules, and bounded time windows. Where the query backend cannot safely search serialized payloads at scale, precompute resource identifiers, identity IDs, DNS zones, storage buckets, KMS keys, secret names, instance IDs, public IPs, private IPs, firewall rule IDs, method classes, and cloud-lineage fields into normalized columns before alerting.

The engineer or admin must validate that GCP findings are triaged as conditional downstream cloud-impact evidence unless the GCP telemetry independently supports unauthorized activity. Confirmed compromise requires corroborating evidence such as unauthorized IAM policy change, suspicious service-account credential use, abnormal service-account impersonation, storage access, DNS manipulation, KMS or secret access, VM modification, disk or snapshot activity, network exposure change, outbound transfer, customer-impact evidence, abuse-report evidence, or post-remediation recurrence.

Deploy initially in hunt mode for at least one business cycle that includes deployment, patching, backup, migration, DNS, storage, key-management, monitoring, scanning, support, incident-response, and customer-maintenance activity. Promote to alert mode only after cloud lineage, asset groups, identity mappings, exception lists, telemetry coverage, query performance, false-positive behavior, and SOC triage procedures are validated.

DRI Assessment

This rule has moderate-to-strong detection relevance because hosting-control compromise and shared-hosting escalation can create downstream risk to GCP identities, hosted domains, storage buckets, KMS keys, secrets, virtual machines, disks, snapshots, network exposure, and customer-facing cloud resources when the affected hosting workload has service accounts, privileged access, DNS authority, storage access, key access, secret access, backup access, or customer-data access. The rule is resilient to exploit-string changes, scanner changes, webshell filename changes, symlink-path changes, plugin-version drift, and source-infrastructure rotation because it focuses on GCP control-plane and cloud-service activity linked to hosting-risk context rather than static indicators. The score is constrained because GCP telemetry does not directly observe cPanel, WHM, LiteSpeed plugin, CloudLinux/CageFS, or tenant-boundary exploitation unless hosting telemetry or cloud-resource lineage is available.

DRI

7.5

TCR Assessment

Operational confidence depends on centralized Cloud Audit Logs, Data Access logging where needed, correct organization, folder, project, and region coverage, service-account and user mapping, workload labeling, hosting asset enrichment, Cloud DNS visibility, Cloud Storage audit coverage, KMS and Secret Manager audit coverage, network telemetry, Security Command Center or Event Threat Detection findings, and reliable linkage between hosting-risk telemetry and GCP resources. Confidence is reduced where hosting workloads are untagged, audit logs are incomplete, Data Access logs are not enabled, storage, KMS, or Secret Manager logs are incomplete, identities are shared, service accounts are poorly scoped, serialized payloads are not normalized, or hosting-to-cloud lineage is unavailable.

Operational TCR

7.0

Full-Telemetry TCR

8.5

Limitations

This rule detects conditional GCP cloud-impact behavior, not direct cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, or tenant-spanning access. GCP telemetry cannot confirm hosting compromise without local hosting, endpoint, web, FTP, file, symlink, DNS, mail, abuse-report, or tenant-impact correlation. Legitimate infrastructure-as-code deployments, VM scaling, patching, backup, migration, DNS administration, certificate renewal, storage administration, KMS administration, Secret Manager administration, image creation, snapshot creation, monitoring, vulnerability scanning, managed service operations, support, and incident-response cleanup may overlap with this behavior. Confirmation requires validated lineage and corroborating cloud activity involving identity, compute, network, DNS, storage, KMS, secrets, customer data, abuse reports, or post-remediation recurrence.

Detection Query Pattern

Use this pattern as a BigQuery, Cloud Logging, Security Command Center, or SIEM implementation guide. Customer-specific table names, field names, resource labels, organization mappings, folder mappings, project mappings, asset groups, identity mappings, precomputed resource columns, and exception lists must be validated before deployment. Organization ID, folder ID, or project ID alone should not be treated as sufficient lineage.

WITH hosting_context AS (
SELECT
organization_id,
folder_id,
project_id,
resource_id,
instance_id,
instance_name,
private_ip,
public_ip,
service_account_email,
service_account_key_id,
user_principal_email,
dns_zone,
hosted_domain,
storage_bucket,
kms_key,
secret_name,
vpc_network,
subnet_id,
firewall_rule_id,
tenant_mapping,
reseller_id,
customer_id,
incident_key,
first_seen,
last_seen
FROM customer_security.customer_hosting_risk_context
WHERE hosting_platform IN (
'cPanel',
'WHM',
'DNSOnly',
'WP Squared',
'LiteSpeed cPanel Plugin',
'LiteSpeed WHM Plugin',
'CloudLinux/CageFS',
'Shared Hosting',
'Reseller Hosting'
)
AND risk_context IN (
'suspicious_hosting_control_access',
'suspicious_ftp_activity',
'web_shell_evidence',
'hosted_content_modification',
'symlink_or_permission_anomaly',
'suspicious_outbound_activity',
'abuse_report',
'customer_ticket',
'post_remediation_recurrence',
'validated_affected_hosting_workload'
)
),

approved_principals AS (
SELECT principal_email FROM customer_security.gcp_approved_hosting_admins
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_support_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_automation_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_deployment_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_backup_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_dns_admin_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_storage_admin_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_kms_admin_identities
UNION DISTINCT
SELECT principal_email FROM customer_security.gcp_approved_secret_manager_admin_identities
),

gcp_candidate_events AS (
SELECT
timestamp,
organization_id,
folder_id,
project_id,
service_name,
method_name,
principal_email,
caller_ip,
user_agent,
resource_name,
resource_type,
request_payload,
response_payload,
authorization_info,
status_code,
resource_instance_id,
resource_instance_name,
resource_private_ip,
resource_public_ip,
resource_service_account_email,
resource_service_account_key_id,
resource_dns_zone,
resource_hosted_domain,
resource_storage_bucket,
resource_kms_key,
resource_secret_name,
resource_vpc_network,
resource_subnet_id,
resource_firewall_rule_id
FROM customer_security.gcp_audit_logs_normalized
WHERE service_name IN (
'iam.googleapis.com',
'cloudresourcemanager.googleapis.com',
'serviceusage.googleapis.com',
'compute.googleapis.com',
'dns.googleapis.com',
'storage.googleapis.com',
'cloudkms.googleapis.com',
'secretmanager.googleapis.com',
'logging.googleapis.com',
'securitycenter.googleapis.com'
)
AND method_name IN (
'google.iam.admin.v1.CreateServiceAccountKey',
'google.iam.admin.v1.DeleteServiceAccountKey',
'google.iam.admin.v1.SetIAMPolicy',
'google.iam.credentials.v1.GenerateAccessToken',
'google.iam.credentials.v1.SignBlob',
'google.iam.credentials.v1.SignJwt',
'SetIamPolicy',
'SetIAMPolicy',
'google.api.serviceusage.v1.ServiceUsage.EnableService',
'v1.compute.instances.insert',
'v1.compute.instances.start',
'v1.compute.instances.stop',
'v1.compute.instances.reset',
'v1.compute.instances.setMetadata',
'v1.compute.instances.setServiceAccount',
'v1.compute.instances.addAccessConfig',
'v1.compute.instances.setTags',
'v1.compute.disks.createSnapshot',
'v1.compute.snapshots.insert',
'v1.compute.images.insert',
'v1.compute.firewalls.insert',
'v1.compute.firewalls.patch',
'v1.compute.firewalls.update',
'v1.compute.routes.insert',
'v1.compute.forwardingRules.insert',
'v1.dns.changes.create',
'storage.buckets.setIamPolicy',
'storage.objects.get',
'storage.objects.create',
'storage.objects.delete',
'cloudkms.cryptoKeyVersions.useToDecrypt',
'cloudkms.cryptoKeys.setIamPolicy',
'secretmanager.versions.access',
'secretmanager.secrets.setIamPolicy'
)
)

SELECT
g.timestamp,
g.organization_id,
g.folder_id,
g.project_id,
g.service_name,
g.method_name,
g.principal_email,
g.caller_ip,
g.user_agent,
g.resource_name,
g.resource_type,
g.status_code,
h.incident_key,
h.instance_id,
h.instance_name,
h.public_ip,
h.private_ip,
h.service_account_email,
h.service_account_key_id,
h.hosted_domain,
h.dns_zone,
h.storage_bucket,
h.kms_key,
h.secret_name,
h.tenant_mapping,
h.reseller_id,
h.customer_id
FROM gcp_candidate_events g
JOIN hosting_context h
ON g.project_id = h.project_id
AND (
g.resource_name = h.resource_id
OR g.resource_instance_id = h.instance_id
OR g.resource_instance_name = h.instance_name
OR g.resource_private_ip = h.private_ip
OR g.resource_public_ip = h.public_ip
OR g.resource_service_account_email = h.service_account_email
OR g.resource_service_account_key_id = h.service_account_key_id
OR g.principal_email = h.user_principal_email
OR g.resource_dns_zone = h.dns_zone
OR g.resource_hosted_domain = h.hosted_domain
OR g.resource_storage_bucket = h.storage_bucket
OR g.resource_kms_key = h.kms_key
OR g.resource_secret_name = h.secret_name
OR g.resource_vpc_network = h.vpc_network
OR g.resource_subnet_id = h.subnet_id
OR g.resource_firewall_rule_id = h.firewall_rule_id
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.instance_id, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.public_ip, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.hosted_domain, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.dns_zone, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.storage_bucket, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.kms_key, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.secret_name, '%')
OR CAST(g.request_payload AS STRING) LIKE CONCAT('%', h.firewall_rule_id, '%')
)
WHERE
g.timestamp BETWEEN TIMESTAMP_SUB(h.first_seen, INTERVAL 2 HOUR)
AND TIMESTAMP_ADD(h.last_seen, INTERVAL 24 HOUR)
AND NOT EXISTS (
SELECT 1
FROM customer_security.gcp_approved_source_networks s
WHERE g.caller_ip = s.source_ip
)
AND NOT EXISTS (
SELECT 1
FROM approved_principals p
WHERE g.principal_email = p.principal_email
)
AND NOT EXISTS (
SELECT 1
FROM customer_security.gcp_approved_incident_response_workflows ir
WHERE h.incident_key = ir.incident_key
)
AND NOT EXISTS (
SELECT 1
FROM customer_security.gcp_hosting_exception_groups e
WHERE g.resource_name = e.resource_name
OR h.incident_key = e.incident_key

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on CVE strings, public proof-of-concept payloads, scanner names, source IP addresses, user-agent values, actor names, web shell filenames, symlink paths, plugin-version inventory, exploit-request formatting, or single indicators as the basis for coverage.

Coverage is strongest where hosting-control access logs, authentication and session telemetry, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, administrative action logs, DNS logs, mail logs, outbound network telemetry, abuse-report evidence, tenant mapping, reseller mapping, CloudLinux/CageFS context, cloud-resource lineage, and SIEM correlation can be joined into bounded behavioral sequences.

Traceability Standard

The S25 rule set provides coverage for the observable enterprise sequence associated with exposed hosting-control-plane compromise, unauthorized administrative access, lower-privileged shared-hosting foothold activity, LiteSpeed plugin-adjacent escalation risk, CloudLinux/CageFS tenant-boundary exposure, privileged server-side execution, hosted-content tampering, credential exposure, outbound abuse, tenant-impacting behavior, post-remediation recurrence, and conditional downstream cloud-impact activity.

The traceability model preserves the distinction between exploit attempt, suspected unauthorized access, probable compromise, confirmed compromise, related shared-hosting escalation, conditional cloud-impact evidence, and non-coverage conditions.

S25 Rule Inventory

Total Accepted Rules

25 rules

Accepted Rule Distribution

·        NDR / Network Behavioral Analytics: 2 rules

·        SentinelOne: 3 rules

·        Splunk: 4 rules

·        Elastic: 4 rules

·        QRadar: 3 rules

·        SIGMA: 3 rules

·        AWS: 2 conditional rules

·        Azure: 2 conditional rules

·        GCP: 2 conditional rules

YARA Disposition

Zero deployable YARA rules

YARA Coverage Determination

YARA has no deployable primary rules for this EXP report because the report’s detection model is behavioral, hosting-control focused, shared-hosting focused, telemetry-correlation based, cloud-lineage dependent, and tenant-impact oriented rather than static-file, malware-signature, or artifact-signature based.

YARA may provide supporting value only if a confirmed malicious artifact, web shell family, loader, dropper, credential-theft component, malicious script, memory artifact, archive artifact, or reusable malware family is recovered and independently validated. No such stable artifact basis is required for the current S25 detection set.

Traceability by Detection Objective

Objective 1 — Exposed Hosting-Control Access and Unauthorized Administrative Context

This objective covers suspicious access to cPanel, WHM, DNSOnly, WP Squared, reseller portals, webmail, sessionized administrative paths, API-style paths, or related hosting-control services where access does not align with expected authentication, session, administrator source, support workflow, reseller scope, or access-window behavior.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage identifies suspicious access to hosting-control services, abnormal administrative-path interaction, unusual source behavior, rare geography or ASN, direct control-panel access patterns, suspicious sessionized-path behavior, and scan-to-access sequencing where network telemetry can observe the traffic path.

·        SentinelOne coverage identifies endpoint-side evidence where hosting-control or web-service context transitions into suspicious local behavior after abnormal access or access-adjacent activity.

·        Splunk, Elastic, and QRadar coverage provides SIEM correlation across access logs, authentication logs, session context, administrator source context, asset groups, custom fields, lookup enrichment, reference sets, reference maps, and bounded access-to-impact windows.

·        SIGMA coverage provides portable endpoint event-rule templates for service-context behavior that should be correlated with suspicious hosting-control access in the target SIEM.

·        AWS, Azure, and GCP coverage is conditional and applies only when hosting-risk context can be linked to downstream cloud-resource activity through validated workload, identity, public IP, private IP, DNS, storage, key, secret, or incident-lineage keys.

Coverage Qualification

·        Exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed plugin presence, or vulnerable version status alone is not sufficient.

·        Scan-only activity alone is not sufficient.

·        Administrative-path access alone is not sufficient.

·        Successful login alone is not sufficient.

·        Coverage requires suspicious access context, authentication or session mismatch, abnormal source behavior, administrative action, post-access execution, hosted-content change, outbound activity, tenant-impact evidence, cloud-lineage evidence, or post-remediation recurrence.

·        Approved hosting-provider support, reseller administration, customer maintenance, vulnerability scanning, monitoring, patch validation, migration, backup, and incident-response workflows require local baseline suppression or downgrade.

Objective 2 — FTP Foothold, Web Shell Activity, LiteSpeed Plugin-Adjacent Activity, and Shared-Hosting Boundary Risk

This objective covers suspicious FTP activity, web access, web shell activity, hosted-path interaction, LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity, symlink-sensitive path behavior, CloudLinux/CageFS tenant-boundary context, and lower-privileged tenant foothold activity that may precede privilege escalation or server-level exposure.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage provides supporting visibility for unusual FTP, web, DNS, proxy, outbound, abuse, and hosted-service communication patterns tied to affected hosting infrastructure.

·        SentinelOne coverage identifies endpoint activity where FTP, web-service, PHP, LiteSpeed, plugin-adjacent, or tenant-path context leads to suspicious execution, file impact, permission changes, symlink-sensitive behavior, or outbound tooling.

·        Splunk and Elastic coverage correlates FTP logs, web logs, endpoint telemetry, file paths, symlink context, tenant mappings, webroot mappings, CloudLinux/CageFS context, and local enrichment into bounded foothold-to-impact patterns.

·        QRadar coverage uses CRE building blocks, custom properties, reference sets, reference maps, and offense grouping to correlate suspicious hosting-access candidates with server-impact candidates.

·        SIGMA coverage provides endpoint event-rule templates for service-context execution that may follow FTP foothold, web shell activity, LiteSpeed plugin-adjacent behavior, or shared-hosting escalation conditions.

·        Cloud rules do not directly detect FTP, web shell, symlink, or CloudLinux/CageFS boundary behavior. They provide conditional downstream coverage only when hosting-risk context is linked to AWS, Azure, or GCP resource activity.

Coverage Qualification

·        FTP activity alone is not sufficient.

·        Web access alone is not sufficient.

·        A single file write alone is not sufficient.

·        A single symlink event alone is not sufficient.

·        LiteSpeed plugin version status alone is not sufficient.

·        CloudLinux/CageFS presence alone is not sufficient.

·        Coverage requires correlation with abnormal source context, suspicious path behavior, web shell evidence, symlink or permission anomaly, root-context behavior, hosted-content impact, outbound activity, tenant-boundary evidence, or post-remediation recurrence.

Objective 3 — Privileged Server-Side Execution and Service-Context Tooling

This objective covers shell execution, interpreter use, administrative utilities, account-management tooling, permission-change tools, package tooling, service-control commands, cron modification, archive staging, database tooling, credential-file access, and outbound retrieval from hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, or cron context.

Mapped Coverage

·        SentinelOne coverage identifies suspicious process lineage, command execution, script activity, file impact, and outbound retrieval from hosting-control or hosting-service context.

·        Splunk coverage correlates process, file, web, FTP, and network telemetry across hosting endpoints using normalized fields, lookups, summaries, and bounded correlation windows.

·        Elastic coverage uses EQL sequence logic across endpoint, file, web, FTP, and network event categories where local data views, value lists, exception lists, transforms, and enrichment policies are validated.

·        QRadar coverage uses CRE building blocks to correlate suspicious hosting-access candidates with suspicious server-impact candidates involving process, file, DNS, mail, network, abuse-report, or incident-response telemetry.

·        SIGMA coverage provides portable Linux process-creation templates for service-context spawning of shell, interpreter, administrative, package, service-control, account-management, archive, database, and retrieval tools.

·        NDR / Network Behavioral Analytics provides supporting visibility when execution leads to outbound retrieval, staging, callback behavior, abuse infrastructure, or unusual DNS and network activity.

Coverage Qualification

·        Shell execution alone is not sufficient.

·        Use of curl, wget, tar, zip, mysqldump, chmod, chown, systemctl, service, useradd, or crontab alone is not sufficient.

·        Root-context process activity alone is not sufficient.

·        Coverage requires relationship to suspicious hosting access, FTP activity, web shell activity, plugin-adjacent activity, tenant-path context, abnormal source context, hosted-content impact, outbound activity, abuse evidence, or approved-workflow failure.

·        Approved patching, package management, backups, migrations, monitoring, hosting-provider support, reseller administration, customer maintenance, plugin updates, CMS updates, abuse-response, and incident-response cleanup require local exceptions.

Objective 4 — Hosted-Content, File-System, Symlink, Permission, and Persistence-Relevant Change

This objective covers hosted-content modification, webroot changes, suspicious scripts, web shell placement, hidden files, unauthorized redirects, phishing pages, malware delivery content, SEO spam, credential-harvesting pages, archive staging, symlink-sensitive behavior, permission changes, ownership changes, cron paths, SSH key paths, plugin paths, CMS files, and customer-facing hosted content.

Mapped Coverage

·        SentinelOne, Splunk, and Elastic coverage identifies suspicious file creation, modification, ownership changes, permission changes, path-sensitive writes, webroot tampering, temporary-path activity, plugin-path activity, and hosted-content changes on affected hosting endpoints.

·        QRadar coverage supports file-impact correlation where DSM parsing, custom properties, file-integrity telemetry, Linux audit, syslog, EDR telemetry, or SIEM-normalized endpoint logs are available.

·        SIGMA coverage supports endpoint-observable process activity that can produce hosted-content tampering, permission modification, archive staging, credential-file access, or outbound retrieval.

·        NDR / Network Behavioral Analytics supports follow-on detection where hosted-content tampering leads to redirector behavior, phishing hosting, malware hosting, suspicious DNS, suspicious outbound transfer, or abuse reports.

·        AWS, Azure, and GCP coverage is conditional where hosted content, backups, logs, DNS zones, storage buckets, storage accounts, key vaults, KMS keys, secrets, or cloud-hosted customer resources are linked to the affected hosting workload.

Coverage Qualification

·        A single file write alone is not sufficient.

·        A single permission change alone is not sufficient.

·        A single hidden file alone is not sufficient.

·        A web shell-like filename alone is not sufficient.

·        A single archive file alone is not sufficient.

·        Coverage requires suspicious access context, service-context execution, FTP or web shell foothold evidence, plugin-adjacent context, symlink or tenant-boundary context, hosted-content impact, outbound activity, abuse report, or tenant-impact evidence.

Objective 5 — Account, Administrative Action, DNS, Mail, Database, Backup, and Configuration Abuse

This objective covers account creation, account modification, password resets, reseller changes, SSH key placement, API token creation, database access, backup access, DNS changes, mail changes, forwarding changes, service changes, control-panel administrative actions, and configuration modifications that may follow unauthorized access or shared-hosting escalation.

Mapped Coverage

·        Splunk, Elastic, and QRadar coverage correlates administrative action logs, control-panel logs, authentication or session context, endpoint process telemetry, file activity, DNS logs, mail logs, tenant mappings, reseller mappings, and bounded time windows.

·        SentinelOne coverage identifies endpoint-side execution and file activity that may accompany account modification, service change, backup access, database access, or configuration manipulation.

·        NDR / Network Behavioral Analytics supports visibility into DNS, mail, outbound, abuse, and network behavior associated with administrative abuse.

·        AWS coverage identifies conditional downstream impact involving IAM, STS, EC2, Route 53, SES, S3, snapshots, security groups, instance profiles, and cloud-service manipulation when validated hosting-to-cloud lineage exists.

·        Azure coverage identifies conditional downstream impact involving Entra ID context, Azure Activity, role assignments, managed identities, service principals, VMs, disks, snapshots, Azure DNS, Storage, Key Vault, and network exposure changes when validated cloud lineage exists.

·        GCP coverage identifies conditional downstream impact involving IAM, service accounts, service-account keys, Compute Engine, Cloud DNS, Cloud Storage, Cloud KMS, Secret Manager, firewall rules, snapshots, images, and cloud-service manipulation when validated cloud lineage exists.

Coverage Qualification

·        Account change alone is not sufficient.

·        DNS change alone is not sufficient.

·        Mail change alone is not sufficient.

·        Database access alone is not sufficient.

·        Backup access alone is not sufficient.

·        Cloud role assignment, IAM event, service-principal activity, service-account activity, storage access, key access, or secret access alone is not sufficient.

·        Coverage requires suspicious upstream hosting context, abnormal administrative source, authentication or session mismatch, service-context execution, hosted-content impact, tenant-impact evidence, post-remediation recurrence, or validated cloud-lineage correlation.

Objective 6 — Suspicious Outbound Communication and Abuse Infrastructure Use

This objective covers payload retrieval, suspicious VPS communication, command-and-control-like behavior, redirector behavior, phishing hosting, malware hosting, spam activity, credential harvesting, SEO spam, suspicious DNS queries, rare destinations, newly observed domains, repeated callbacks, unusual TLS behavior, and abuse reports involving affected hosting assets.

Mapped Coverage

·        NDR / Network Behavioral Analytics provides primary network-supporting visibility for unusual DNS, proxy, firewall, TLS, outbound connection, rare destination, unusual ASN, unusual geography, and abuse-infrastructure behavior.

·        SentinelOne, Splunk, and Elastic coverage identifies outbound retrieval and network activity where process attribution, command-line context, host identity, and destination telemetry are available.

·        QRadar coverage correlates DNS, mail, firewall, proxy, WAF, CDN, NDR, abuse-report, and endpoint telemetry through building blocks, custom properties, and offense context.

·        SIGMA provides event templates for local process execution that may initiate outbound retrieval or staging.

·        AWS, Azure, and GCP coverage identifies conditional downstream cloud-service activity when hosting-risk context is linked to cloud identities, network paths, storage, DNS, mail, compute, key, secret, or customer resources.

Coverage Qualification

·        One outbound connection alone is not sufficient.

·        A newly observed domain alone is not sufficient.

·        DNS anomaly alone is not sufficient.

·        Abuse report alone is not sufficient.

·        Coverage requires correlation with suspicious access, FTP or web shell activity, service-context execution, hosted-content tampering, credential access, DNS or mail changes, tenant-impact evidence, or post-remediation recurrence.

Objective 7 — Tenant Blast Radius, Reseller Scope, Customer Impact, and Shared-Hosting Boundary Failure

This objective covers activity affecting multiple hosted accounts, reseller-managed accounts, customer webroots, domains, DNS zones, mailboxes, databases, FTP accounts, backup paths, plugin paths, CloudLinux/CageFS tenant paths, or unrelated tenants from the same suspected access path.

Mapped Coverage

·        Splunk, Elastic, and QRadar coverage is strongest where tenant, reseller, domain, webroot, FTP account, control-panel account, CloudLinux/CageFS, and hosting-asset mappings are normalized into local schema, lookups, reference maps, transforms, or enrichment fields.

·        SentinelOne coverage supports host-level and endpoint-level evidence of process, file, permission, path, and outbound behavior across affected hosting servers.

·        NDR / Network Behavioral Analytics supports cross-tenant and abuse-impact analysis where domains, server IPs, mail flows, DNS, proxy, and abuse reports can be tied to affected hosting infrastructure.

·        AWS, Azure, and GCP coverage is conditional where customer domains, storage, DNS zones, cloud-hosted workloads, public IPs, identities, keys, secrets, or incident keys map cloud activity back to affected hosting-risk context.

Coverage Qualification

·        One tenant event alone is not sufficient.

·        One customer ticket alone is not sufficient.

·        One abuse report alone is not sufficient.

·        Similar file activity across sites requires validation before confirmed multi-tenant compromise classification.

·        Coverage requires tenant mapping, reseller mapping, domain mapping, file-path mapping, cloud-resource mapping, or incident-key linkage sufficient to show impact beyond routine maintenance or isolated customer workflow.

Objective 8 — Conditional Downstream AWS, Azure, and GCP Cloud Impact

This objective covers AWS, Azure, and GCP activity that may follow hosting-server compromise when the affected hosting workload has cloud credentials, cloud identities, DNS authority, storage access, key access, secret access, backup access, mail authority, or customer-data access.

Mapped Coverage

·        AWS coverage identifies conditional downstream activity involving IAM, STS, EC2, S3, Route 53, SES, snapshots, security groups, instance profiles, access keys, GuardDuty, Security Hub, Config, Access Analyzer, and cloud-service activity linked to hosting-risk context.

·        Azure coverage identifies conditional downstream activity involving Entra ID context, Azure Activity, role assignments, service principals, managed identities, VMs, disks, snapshots, network security groups, public IPs, Azure DNS, Storage, Key Vault, Defender for Cloud, Sentinel, and Azure Monitor activity linked to hosting-risk context.

·        GCP coverage identifies conditional downstream activity involving IAM, service accounts, service-account keys, service-account impersonation, Compute Engine, Cloud DNS, Cloud Storage, Cloud KMS, Secret Manager, firewall rules, snapshots, images, Security Command Center, Event Threat Detection, and Cloud Logging activity linked to hosting-risk context.

·        Splunk, Elastic, and QRadar can also provide downstream cloud-impact coverage when cloud telemetry and hosting-risk context are ingested into the same analytics environment.

Coverage Qualification

·        AWS activity alone is not sufficient.

·        Azure activity alone is not sufficient.

·        GCP activity alone is not sufficient.

·        Cloud console access alone is not sufficient.

·        IAM, role assignment, service-principal, service-account, storage, DNS, key, secret, or network activity alone is not sufficient.

·        Cloud findings must not be attributed to hosting-control or shared-hosting compromise unless reliable hosting-to-cloud lineage exists through workload identity, public IP, private IP, resource ID, access key, managed identity, service principal, service account, DNS zone, hosted domain, storage resource, key vault, KMS key, secret, tenant, reseller, customer, or incident key.

Objective 9 — Post-Remediation Recurrence and Containment Validation

This objective covers continued suspicious access, file changes, outbound communication, DNS or mail manipulation, web shell recurrence, symlink or permission anomalies, cloud-resource activity, abuse reports, or customer-impact evidence after patching, plugin update, credential rotation, containment, hosted-content cleanup, tenant-boundary review, or incident-response activity.

Mapped Coverage

·        Splunk, Elastic, and QRadar coverage correlates remediation windows, incident-response records, host state, endpoint telemetry, file activity, access logs, DNS, mail, outbound telemetry, abuse reports, and cloud activity.

·        SentinelOne coverage identifies endpoint recurrence after containment, cleanup, isolation, or remediation.

·        NDR / Network Behavioral Analytics identifies continued suspicious outbound behavior or abuse infrastructure after remediation.

·        AWS, Azure, and GCP coverage identifies cloud activity after hosting-risk containment when validated cloud-lineage keys exist.

·        SIGMA coverage provides supporting event-level logic for post-remediation process activity where local remediation context is enriched into the backend.

Coverage Qualification

·        Patch completion alone does not prove non-compromise.

·        Plugin update alone does not prove non-compromise.

·        Credential rotation alone does not prove containment.

·        Cleanup activity alone is not suspicious when performed by approved incident-response workflows.

·        Coverage requires suspicious continued activity, unapproved source, affected host or tenant linkage, post-remediation recurrence, cloud-lineage evidence, abuse-report evidence, or customer-impact evidence.

Traceability by System

NDR / Network Behavioral Analytics

NDR / Network Behavioral Analytics provides supporting and correlation coverage for exposed hosting-control access, unusual access paths, suspicious FTP or web traffic, unusual DNS, rare destinations, outbound retrieval, abuse infrastructure, tenant-impact indicators, and post-remediation recurrence where network telemetry can be linked to affected hosting assets.

NDR cannot independently prove cPanel authentication-bypass success, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, web shell execution, tenant-spanning compromise, or customer data exposure without hosting, endpoint, file, authentication, administrative, or tenant telemetry.

SentinelOne

SentinelOne provides endpoint-centered coverage for service-context execution, suspicious process lineage, shell or interpreter activity, administrative tooling, account-management utilities, hosted-content modification, file-impact behavior, outbound retrieval, and post-remediation recurrence on affected hosting endpoints.

SentinelOne coverage depends on endpoint deployment, process lineage, command-line capture, file telemetry, host role tagging, and local mapping of hosting assets, LiteSpeed plugin assets, CloudLinux/CageFS assets, webroots, tenant paths, and approved workflows.

Splunk

Splunk provides broad SIEM correlation coverage across hosting-control access logs, authentication and session logs, FTP logs, web logs, endpoint events, file events, DNS, mail, proxy, firewall, abuse reports, tenant mappings, reseller mappings, cloud telemetry, and incident-response context.

Splunk coverage depends on normalized fields, macros, lookups, summary indexes or accelerated datasets, local exception lists, bounded time windows, correlation keys, false-positive baselines, and performance-safe implementation.

Elastic

Elastic provides sequence-oriented coverage across endpoint, file, web, FTP, network, and enrichment telemetry using EQL or equivalent Elastic Security workflows. Coverage supports suspicious hosting access followed by privileged execution, file impact, outbound activity, or post-remediation recurrence.

Elastic coverage depends on ECS or local field mapping, data views, index scoping, transforms, enrichment policies, value lists, exception lists, host identity, tenant context, webroot mapping, process lineage, and query-performance validation.

QRadar

QRadar provides deployable CRE correlation coverage through building blocks, custom properties, reference sets, reference maps, and offense grouping. Coverage supports suspicious hosting-access candidates followed by suspicious server-impact candidates within bounded windows.

QRadar coverage depends on DSM parsing, custom property extraction, log source groups, reference-set hygiene, reference-map quality, timestamp alignment, offense grouping, false-positive governance, and building-block validation.

SIGMA

SIGMA provides portable event-rule template coverage for Linux process creation and related endpoint-observable service-context behavior. It is useful for identifying suspicious hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, cron, shell, interpreter, administrative, account-management, archive, database, and outbound retrieval activity.

SIGMA is not a complete backend-independent temporal correlation layer for this report. Local field mapping, backend conversion, enrichment-field creation, exception validation, and SIEM-native correlation are required.

AWS

AWS provides conditional downstream cloud-impact coverage where hosting-risk context can be joined to AWS activity through account, workload, IAM role, access key, instance profile, EC2 instance, public IP, private IP, VPC, Route 53 zone, hosted domain, S3 bucket, SES identity, security group, snapshot, tenant, reseller, customer, or incident lineage.

AWS coverage must not treat account ID alone as sufficient lineage. AWS findings remain conditional downstream cloud-impact evidence unless AWS telemetry independently supports unauthorized activity.

Azure

Azure provides conditional downstream cloud-impact coverage where hosting-risk context can be joined to Azure activity through tenant, subscription, workload, VM ID, managed identity, service principal, user account, public IP, private IP, DNS zone, hosted domain, storage account, key vault, virtual network, network security group, tenant, reseller, customer, or incident lineage.

Azure coverage must not treat tenant ID, subscription ID, or resource group alone as sufficient lineage. Azure findings remain conditional downstream cloud-impact evidence unless Azure telemetry independently supports unauthorized activity.

GCP

GCP provides conditional downstream cloud-impact coverage where hosting-risk context can be joined to GCP activity through project, Compute Engine instance, service account, service-account key, user account, public IP, private IP, DNS zone, hosted domain, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, VPC network, firewall rule, tenant, reseller, customer, or incident lineage.

GCP coverage must not treat organization ID, folder ID, or project ID alone as sufficient lineage. GCP findings remain conditional downstream cloud-impact evidence unless GCP telemetry independently supports unauthorized activity.

YARA

YARA has zero deployable primary rules for this report.

YARA remains a non-coverage disposition unless a validated malicious artifact, web shell family, malware family, loader, dropper, script artifact, archive artifact, credential-theft component, memory artifact, or reusable file-based detection target is recovered.

Traceability Gaps Preserved

The S25 rule set does not directly prove cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, tenant-spanning compromise, customer data exposure, AWS compromise, Azure compromise, GCP compromise, or downstream cloud compromise by itself.

Coverage weakens under the following conditions:

·        Hosting-control access logs are unavailable, delayed, truncated, or not retained.

·        Authentication or session telemetry is unavailable or inconsistent.

·        FTP logs are unavailable, unparsed, or not tied to account, source, path, tenant, or timestamp context.

·        Web access logs do not preserve path, method, status, user agent, host, source, authenticated context, or hosted-path context.

·        Endpoint process telemetry is missing from hosting servers.

·        Parent process, command line, effective user, working directory, or process-to-network attribution is missing.

·        File, permission, ownership, timestamp, symlink, webroot, plugin-path, or hosted-content telemetry is incomplete.

·        CloudLinux/CageFS tenant mapping is unavailable or incomplete.

·        Tenant, reseller, domain, mailbox, database, backup, webroot, and DNS-zone mappings are unavailable.

·        DNS, mail, proxy, firewall, WAF, CDN, NDR, and outbound network telemetry is unavailable or cannot be tied to host, process, tenant, or time window.

·        Abuse-report, customer-support, help desk, backup, remediation, and incident-response records are not linked to affected assets.

·        Approved support, reseller, customer-maintenance, backup, migration, patching, plugin update, CMS update, vulnerability scanning, monitoring, and incident-response workflows are not baselined.

·        AWS, Azure, or GCP telemetry is unavailable, incomplete, uncentralized, not normalized, or cannot be linked to hosting-risk context.

·        Cloud resource lineage relies only on account, subscription, tenant, project, folder, or organization context without a workload, identity, resource, network, storage, DNS, customer, tenant, reseller, or incident key.

·        Data-event, storage, key, secret, DNS, mail, or cloud-service telemetry is disabled or incomplete.

·        Adversary activity blends into approved administrative, support, customer, automation, or incident-response workflows.

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across the key observable stages of hosting-control-plane compromise, shared-hosting privilege escalation, lower-privileged foothold conversion, privileged server-side execution, hosted-content tampering, credential and configuration exposure, outbound abuse, tenant-impacting behavior, post-remediation recurrence, and conditional downstream cloud-impact activity.

Coverage is strongest for suspicious hosting-control access, authentication or session mismatch, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent activity, symlink or permission anomalies, CloudLinux/CageFS tenant-boundary context, service-context execution, hosted-content modification, account or administrative action abuse, DNS or mail manipulation, suspicious outbound communication, abuse-report correlation, tenant blast-radius analysis, and AWS, Azure, or GCP activity when reliable cloud-lineage keys exist.

The rule set intentionally avoids CVE strings, public exploit artifacts, scanner names, actor names, web shell names, symlink paths, single source IPs, user-agent values, plugin-version inventory, and single-event conclusions as the basis for detection. Detection confidence depends on correlating suspicious access, foothold activity, service-context execution, file impact, outbound behavior, tenant mapping, abuse evidence, remediation context, and cloud-resource lineage rather than treating any single event category as proof of compromise.

S27 — Behavior & Log Artifacts

Artifact Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, traceability, and validation for hosting-control-plane compromise, shared-hosting privilege escalation, lower-privileged tenant foothold activity, LiteSpeed plugin-adjacent risk, CloudLinux/CageFS tenant-boundary exposure, privileged server-side activity, hosted-content tampering, credential exposure, abuse-infrastructure use, tenant-impacting behavior, post-remediation recurrence, and conditional downstream cloud-impact activity.

The artifacts below are behavior-led. They should not be treated as proof of cPanel authentication-bypass exploitation, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, root-level compromise, tenant-spanning compromise, customer data exposure, AWS compromise, Azure compromise, GCP compromise, or downstream cloud compromise unless they are correlated into a coherent sequence.

Artifact Collection Standard

Artifacts should preserve host identity, source IP, user identity, session context, request path, FTP account, webroot, process lineage, command line, file path, file owner, file permission, symlink target, tenant mapping, reseller mapping, domain mapping, destination domain, destination IP, cloud identity, cloud resource, timestamp, and remediation context where available.

Artifacts should support classification into exploit attempt, suspected unauthorized access, probable compromise, confirmed compromise, related shared-hosting escalation, conditional cloud-impact evidence, or non-coverage condition.

Primary Artifact Categories

·        Hosting-control access artifacts.

·        Authentication and session artifacts.

·        FTP, web access, web shell, and lower-privileged foothold artifacts.

·        LiteSpeed plugin, symlink, permission, and CloudLinux/CageFS tenant-boundary artifacts.

·        Endpoint process and service-context execution artifacts.

·        Account, administrative action, DNS, mail, database, backup, and configuration artifacts.

·        Hosted-content, webroot, file-system, and persistence-relevant artifacts.

·        Outbound network, DNS, proxy, firewall, abuse-report, and reputation artifacts.

·        Tenant, reseller, customer, domain, mailbox, database, backup, and blast-radius artifacts.

·        AWS, Azure, and GCP conditional downstream cloud-impact artifacts.

·        Remediation, containment, recovery, and post-remediation recurrence artifacts.

·        YARA non-coverage and conditional artifact disposition.

Hosting-Control Access Artifacts

Behavior Represented

Access to cPanel, WHM, DNSOnly, WP Squared, reseller portals, webmail, administrative paths, API-style paths, sessionized paths, control-panel services, or related hosting-control interfaces.

Relevant Artifacts

Request path, HTTP method, response code, source IP, destination host, destination IP, host header, user agent, cookie or session identifier where available, authenticated or claimed user where available, control-panel account, reseller account, administrative action, virtual host, service name, backend service, timestamp, and access result.

Useful Log Sources

·        cPanel access logs.

·        WHM access logs.

·        DNSOnly logs where available.

·        WP Squared logs where available.

·        Hosting-control service logs.

·        Webmail logs.

·        Web server access logs.

·        Reverse proxy logs.

·        WAF logs.

·        CDN logs.

·        Load balancer logs.

·        Firewall logs.

·        SIEM-normalized web and hosting-control telemetry.

Detection Use

These artifacts support detection when administrative access is inconsistent with expected authentication, session, administrator source, reseller scope, user agent, access window, support workflow, or tenant context.

Investigation Use

Investigators should reconstruct whether access followed a normal login path, whether the source is approved, whether the session context is expected, whether administrative actions followed access, and whether access is followed by endpoint execution, file changes, DNS or mail changes, outbound communication, abuse reports, or tenant-impact evidence.

Non-Coverage Conditions

Hosting-control access alone does not prove compromise. Scan-only access, failed requests, successful login, direct path access, or exposed administrative surface must be correlated with authentication/session mismatch, administrative action, endpoint execution, file impact, outbound behavior, or tenant-impact evidence before compromise classification.

Authentication and Session Artifacts

Behavior Represented

Authentication, session creation, session reuse, session mismatch, abnormal administrative context, or access-flow inconsistency involving hosting-control services.

Relevant Artifacts

Login attempt, login success, login failure, MFA result where available, session creation, session reuse, session expiration, cookie or session identifier, user identity, administrator identity, reseller identity, source IP, user agent, request path, authentication result, administrative action, host identity, timestamp, and correlation ID where available.

Useful Log Sources

·        cPanel authentication logs.

·        WHM authentication logs.

·        Hosting-control session logs.

·        Webmail authentication logs.

·        System authentication logs.

·        PAM logs where applicable.

·        Identity provider logs where applicable.

·        VPN logs.

·        Proxy logs.

·        SIEM-normalized authentication telemetry.

Detection Use

These artifacts support detection when administrative activity appears without expected authentication, when session state does not align with login records, or when access logs, authentication logs, and administrative action logs do not tell a consistent story.

Investigation Use

Investigators should determine whether administrative access followed expected login, MFA, support, reseller, customer, or automation workflows. They should compare source IP, user, session, access path, user agent, and administrative actions across the relevant time window.

Non-Coverage Conditions

Authentication anomaly alone is not sufficient. Session anomaly alone is not sufficient. Missing session context alone is not sufficient. These artifacts require correlation with suspicious access, administrative action, privileged execution, hosted-content modification, outbound behavior, or tenant-impact evidence.

FTP, Web Access, Webshell, and Lower-Privileged Foothold Artifacts

Behavior Represented

FTP activity, web access, web shell interaction, suspicious hosted-path activity, abnormal upload behavior, lower-privileged tenant foothold activity, or web-accessible execution that may precede shared-hosting escalation or server-level impact.

Relevant Artifacts

FTP account, FTP authentication result, FTP source IP, FTP operation, uploaded path, downloaded path, byte count, web request path, HTTP method, response code, user agent, source IP, hosted domain, webroot, tenant account, uploaded file name, file extension, file size, script execution path, request timestamp, and related process or file event where available.

Useful Log Sources

·        FTP logs.

·        SFTP logs where available.

·        Web access logs.

·        Web server error logs.

·        WAF logs.

·        CDN logs.

·        Reverse proxy logs.

·        Endpoint telemetry.

·        File integrity telemetry.

·        Linux audit telemetry.

·        SIEM-normalized web and file telemetry.

Detection Use

These artifacts support detection when FTP or web activity from abnormal source context is followed by suspicious file writes, script execution, hidden files, symlink-sensitive behavior, permission changes, plugin-adjacent activity, hosted-content modification, outbound retrieval, or tenant-boundary evidence.

Investigation Use

Investigators should determine whether FTP or web activity is expected for the tenant, customer, reseller, source, time window, and file path. They should compare uploaded or accessed files with endpoint process execution, file changes, outbound communication, abuse reports, and CloudLinux/CageFS context.

Non-Coverage Conditions

FTP activity alone is not sufficient. Web access alone is not sufficient. A file upload alone is not sufficient. A web shell-like path alone is not sufficient. These artifacts require suspicious source, unusual timing, unexpected file impact, service-context execution, outbound behavior, tenant-boundary evidence, or customer-impact context.

LiteSpeed Plugin, Symlink, Permission, and CloudLinux/CageFS Artifacts

Behavior Represented

LiteSpeed cPanel Plugin or LiteSpeed WHM Plugin activity, symlink-sensitive path behavior, shared-hosting boundary exposure, permission anomalies, root-owned file changes, CloudLinux/CageFS tenant-context anomalies, or plugin-adjacent execution.

Relevant Artifacts

LiteSpeed plugin version, plugin path, plugin action, file path, symlink path, symlink target, file owner, file group, permission mode, creating process, modifying process, effective user, tenant path, CloudLinux/CageFS context, cage boundary, root-owned file change, tenant account, reseller account, webroot, host identity, and timestamp.

Useful Log Sources

·        LiteSpeed logs.

·        cPanel plugin logs where available.

·        WHM plugin logs where available.

·        CloudLinux/CageFS logs and administrative records where available.

·        Linux audit logs.

·        File integrity telemetry.

·        EDR telemetry.

·        Syslog.

·        Endpoint process telemetry.

·        SIEM-normalized file and endpoint telemetry.

Detection Use

These artifacts support detection when LiteSpeed plugin-adjacent activity, symlink behavior, permission changes, tenant-path access, or CloudLinux/CageFS anomalies align with FTP foothold activity, web shell activity, hosted-content modification, root-context execution, or tenant-spanning access.

Investigation Use

Investigators should determine whether file access, symlink behavior, permission change, or process activity crossed expected tenant boundaries. They should validate whether affected paths map to one tenant, multiple tenants, reseller scope, plugin paths, webroots, backup paths, or root-owned server paths.

Non-Coverage Conditions

LiteSpeed plugin presence alone is not sufficient. Vulnerable plugin version alone is not sufficient. A single symlink event alone is not sufficient. A permission change alone is not sufficient. CloudLinux/CageFS presence alone is not sufficient. These artifacts require foothold, escalation, file-impact, tenant-boundary, root-context, or post-remediation recurrence evidence.

Endpoint Process and Service-Context Execution Artifacts

Behavior Represented

Service-context execution, shell activity, interpreter use, administrative tooling, account-management utilities, permission-change tools, package tooling, service-control commands, cron modification, archive staging, database tooling, credential-file access, or outbound retrieval on hosting infrastructure.

Relevant Artifacts

Process name, parent process name, command line, executable path, working directory, process ID, parent process ID, execution user, effective user where available, host identity, process start time, child process, parent service, hash where available, network destination where available, file path where available, and endpoint alert context where available.

Useful Log Sources

·        EDR telemetry.

·        Linux audit logs.

·        Syslog.

·        Process accounting.

·        Endpoint process creation logs.

·        File integrity telemetry.

·        Shell history where appropriate and legally available.

·        SIEM-normalized endpoint telemetry.

Detection Use

These artifacts support detection when hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, or cron context spawns shell, interpreter, administrative, package, service-control, account-management, archive, database, or retrieval tooling.

Investigation Use

Investigators should determine whether process lineage aligns with expected patching, backup, migration, support, customer maintenance, CMS update, plugin update, or incident-response workflows. They should correlate process events with access logs, FTP logs, file changes, DNS or mail changes, outbound activity, and tenant impact.

Non-Coverage Conditions

One suspicious command alone is not sufficient. One shell process alone is not sufficient. One administrative utility alone is not sufficient. These artifacts require relationship to suspicious access, foothold behavior, file impact, outbound behavior, administrative action, tenant impact, or approved-workflow failure.

Account and Administrative Action Artifacts

Behavior Represented

Control-panel, system, reseller, database, mail, DNS, backup, service, or local account actions that may follow unauthorized access or privilege escalation.

Relevant Artifacts

Account creation, account deletion, password reset, privilege change, reseller modification, API token creation, SSH key placement, service-account modification, database user change, mail account change, DNS change, backup access, file-manager action, service restart, actor identity, source IP, session ID, target account, tenant, reseller, domain, host identity, and timestamp.

Useful Log Sources

·        cPanel administrative action logs.

·        WHM administrative logs.

·        DNSOnly logs where available.

·        WP Squared logs where available.

·        System authentication logs.

·        Database logs.

·        Mail server logs.

·        DNS administrative logs.

·        Backup logs.

·        SIEM-normalized administrative telemetry.

Detection Use

These artifacts support detection when account or administrative action follows suspicious hosting-control access, authentication/session mismatch, FTP or web shell activity, endpoint execution, or post-remediation recurrence.

Investigation Use

Investigators should determine whether the action is expected for the actor, reseller scope, tenant scope, support workflow, maintenance window, customer request, or automation process. They should validate whether activity affected multiple tenants, customer domains, mailboxes, databases, DNS zones, or backup paths.

Non-Coverage Conditions

Account modification alone is not sufficient. DNS change alone is not sufficient. Mail change alone is not sufficient. Backup access alone is not sufficient. Database access alone is not sufficient. These artifacts require suspicious access context, abnormal actor context, post-access behavior, tenant-impact evidence, or approved-workflow failure.

Hosted-Content, Webroot, File-System, and Persistence-Relevant Artifacts

Behavior Represented

Hosted-content tampering, web shell placement, suspicious script creation, unauthorized redirect insertion, phishing page deployment, malware delivery content, SEO spam, credential-harvesting pages, archive staging, hidden files, permission changes, ownership changes, cron modifications, SSH key changes, and persistence-relevant hosted-path activity.

Relevant Artifacts

File path, file name, file extension, file owner, file group, permission mode, file size, hash where available, file creation time, file modification time, timestamp change, symlink target where available, creating process, modifying process, webroot, tenant, reseller, domain, CMS path, plugin path, upload path, temporary path, cron path, SSH key path, and remediation state.

Useful Log Sources

·        File integrity monitoring.

·        EDR file telemetry.

·        Linux audit logs.

·        Web server logs.

·        FTP logs.

·        CMS logs where available.

·        Backup comparison records.

·        Incident-response file review records.

·        SIEM-normalized file telemetry.

Detection Use

These artifacts support detection when hosted-content or file-system changes occur after suspicious access, FTP activity, web shell activity, service-context execution, symlink-sensitive behavior, or tenant-boundary anomalies.

Investigation Use

Investigators should determine whether changes align with customer maintenance, plugin updates, CMS updates, support work, backup restoration, migration, or incident-response cleanup. They should compare affected paths to tenant ownership, reseller scope, webroot mapping, hosted domains, backup records, and abuse reports.

Non-Coverage Conditions

File change alone is not sufficient. Webroot change alone is not sufficient. Suspicious extension alone is not sufficient. Hidden file alone is not sufficient. Archive creation alone is not sufficient. These artifacts require suspicious access, process lineage, tenant context, outbound activity, abuse evidence, or post-remediation recurrence.

DNS, Mail, Outbound Network, and Abuse Artifacts

Behavior Represented

DNS manipulation, mail manipulation, outbound retrieval, payload staging, command-and-control-like behavior, redirector behavior, phishing hosting, malware hosting, spam activity, credential harvesting, SEO spam, unusual DNS, rare destinations, suspicious VPS communication, abuse reports, blocklist entries, and reputation changes.

Relevant Artifacts

DNS query, DNS response, resolver, source host, destination domain, destination IP, destination port, protocol, byte count, connection duration, TLS metadata where available, process context where available, DNS zone, mail account, MX record, TXT record, SPF, DKIM, DMARC, outbound mail volume, spam report, phishing report, malware report, abuse notice, blocklist event, customer complaint, and timestamp.

Useful Log Sources

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        NDR telemetry.

·        VPC or cloud flow logs where applicable.

·        Mail server logs.

·        DNS administrative logs.

·        WAF logs.

·        CDN logs.

·        Abuse-desk records.

·        Customer-support records.

·        Blocklist and reputation feeds.

·        SIEM-normalized network and abuse telemetry.

Detection Use

These artifacts support detection when outbound activity, DNS change, mail change, or abuse report follows suspicious hosting-control access, FTP activity, web shell activity, hosted-content modification, service-context execution, or tenant-impact evidence.

Investigation Use

Investigators should determine whether outbound communication aligns with approved patching, package repositories, backup destinations, CDN providers, mail relays, monitoring systems, customer workflows, or incident-response activity. They should correlate abuse reports with affected host, domain, tenant, webroot, mail account, and time window.

Non-Coverage Conditions

Outbound connection alone is not sufficient. DNS change alone is not sufficient. Mail event alone is not sufficient. Abuse report alone is not sufficient. Reputation change alone is not sufficient. These artifacts require upstream suspicious access, file impact, process context, tenant mapping, customer-impact evidence, or post-remediation recurrence.

Tenant, Reseller, Customer, and Blast-Radius Artifacts

Behavior Represented

Activity crossing expected tenant, reseller, domain, mailbox, database, DNS zone, backup, customer, or CloudLinux/CageFS boundaries.

Relevant Artifacts

Tenant account, reseller account, hosted domain, webroot, mailbox, database, DNS zone, FTP account, backup path, plugin path, CloudLinux/CageFS tenant path, customer ID, business owner, affected service, affected server, account relationship, domain relationship, file-path relationship, administrative scope, ticket ID, incident key, and timestamp.

Useful Log Sources

·        Hosting-control inventory.

·        Tenant inventory.

·        Reseller inventory.

·        Domain inventory.

·        FTP account inventory.

·        DNS zone inventory.

·        Mailbox inventory.

·        Database inventory.

·        Backup inventory.

·        CloudLinux/CageFS records.

·        Customer-support records.

·        Abuse-desk records.

·        CMDB or asset inventory.

·        SIEM enrichment tables.

Detection Use

These artifacts support detection when activity affects multiple tenants, unrelated domains, reseller-managed accounts, customer webroots, mailboxes, databases, DNS zones, backup paths, or shared-hosting boundaries from the same suspected access path.

Investigation Use

Investigators should map affected files, accounts, domains, mailboxes, databases, DNS zones, backup paths, cloud resources, and support records to tenant ownership and business impact. They should determine whether activity remained isolated or crossed expected administrative, reseller, customer, or tenant boundaries.

Non-Coverage Conditions

Tenant mapping alone is not suspicious. Multiple affected assets require behavioral context. Customer ticket volume alone is not sufficient. Blast-radius claims require validated relationships among access, process, file, account, DNS, mail, network, cloud, support, or abuse artifacts.

Downstream AWS Cloud Artifacts

Behavior Represented

Conditional AWS cloud-impact activity after hosting-risk context where affected hosting workloads have AWS identities, instance profiles, access keys, DNS authority, mail authority, storage access, backup access, or customer-data access.

Relevant Artifacts

CloudTrail event time, event source, event name, source IP, user agent, principal ARN, session issuer, access key ID, recipient account ID, region, request parameters, response elements, error code, EC2 instance ID, instance profile, IAM role, public IP, private IP, VPC, subnet, security group, Route 53 zone, hosted domain, SES identity, S3 bucket, snapshot, AMI, GuardDuty finding, Security Hub finding, AWS Config change, Access Analyzer finding, tenant, reseller, customer, incident key, and timestamp.

Useful Log Sources

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where enabled.

·        CloudTrail Lake.

·        AWS Security Lake.

·        GuardDuty.

·        Security Hub.

·        Detective.

·        AWS Config.

·        Access Analyzer.

·        VPC Flow Logs.

·        Route 53 logs.

·        SES telemetry.

·        S3 access logs and data events.

·        SIEM-normalized AWS telemetry.

Detection Use

These artifacts support downstream AWS cloud-impact detection only when prior hosting-risk context is present and AWS activity is objectively suspicious.

Investigation Use

Investigators should determine whether AWS activity maps to the affected hosting workload, IAM role, access key, instance profile, public IP, private IP, hosted domain, Route 53 zone, SES identity, S3 bucket, security group, tenant, reseller, customer, or incident key.

Non-Coverage Conditions

AWS activity alone is not sufficient. AWS console access alone is not sufficient. IAM activity alone is not sufficient. Account ID alone is not sufficient lineage. AWS anomalies must not be attributed to hosting-control or shared-hosting compromise without reliable upstream hosting-risk context and cloud-lineage correlation.

Downstream Azure Cloud Artifacts

Behavior Represented

Conditional Azure cloud-impact activity after hosting-risk context where affected hosting workloads have managed identities, service principals, user accounts, DNS authority, storage access, key vault access, backup access, privileged access, or customer-data access.

Relevant Artifacts

Azure Activity event time, operation name, category, caller, caller IP, user principal name, app ID, service principal ID, managed identity ID, tenant ID, subscription ID, resource group, resource ID, region, result type, correlation ID, VM ID, public IP, private IP, managed identity, service principal, DNS zone, hosted domain, storage account, key vault, disk, snapshot, network security group, virtual network, subnet, Defender for Cloud finding, Sentinel context, tenant mapping, reseller ID, customer ID, incident key, and timestamp.

Useful Log Sources

·        Azure Activity logs.

·        Entra ID sign-in logs.

·        Entra ID audit logs.

·        Microsoft Defender for Cloud.

·        Microsoft Sentinel.

·        Azure Monitor.

·        Azure Resource Graph.

·        Azure Storage logs where enabled.

·        Azure Key Vault logs where enabled.

·        Azure DNS logs.

·        NSG Flow Logs.

·        Azure Firewall logs.

·        Application Gateway logs.

·        Front Door and CDN logs.

·        SIEM-normalized Azure telemetry.

Detection Use

These artifacts support downstream Azure cloud-impact detection only when prior hosting-risk context is present and Azure activity is objectively suspicious.

Investigation Use

Investigators should determine whether Azure activity maps to the affected hosting workload, virtual machine, managed identity, service principal, user account, public IP, private IP, DNS zone, storage account, key vault, network security group, tenant, reseller, customer, or incident key.

Non-Coverage Conditions

Azure activity alone is not sufficient. Azure portal access alone is not sufficient. Role assignment alone is not sufficient. Tenant ID, subscription ID, or resource group alone is not sufficient lineage. Azure anomalies must not be attributed to hosting-control or shared-hosting compromise without reliable upstream hosting-risk context and cloud-lineage correlation.

Downstream GCP Cloud Artifacts

Behavior Represented

Conditional GCP cloud-impact activity after hosting-risk context where affected hosting workloads have service accounts, service-account keys, user accounts, DNS authority, storage access, KMS access, Secret Manager access, backup access, privileged access, or customer-data access.

Relevant Artifacts

Cloud Audit Log timestamp, service name, method name, principal email, caller IP, user agent, resource name, resource type, project ID, folder ID, organization ID, authorization information, status code, Compute Engine instance ID, instance name, public IP, private IP, service account, service-account key ID, DNS zone, hosted domain, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, VPC network, subnet, firewall rule, Security Command Center finding, Event Threat Detection finding, tenant mapping, reseller ID, customer ID, incident key, and timestamp.

Useful Log Sources

·        GCP Admin Activity audit logs.

·        GCP Data Access audit logs where enabled.

·        Cloud Logging.

·        BigQuery export.

·        Security Command Center.

·        Event Threat Detection.

·        Cloud Asset Inventory.

·        Cloud DNS logs.

·        VPC Flow Logs.

·        Cloud Armor logs.

·        Cloud Storage logs.

·        Cloud KMS logs.

·        Secret Manager logs.

·        SIEM-normalized GCP telemetry.

Detection Use

These artifacts support downstream GCP cloud-impact detection only when prior hosting-risk context is present and GCP activity is objectively suspicious.

Investigation Use

Investigators should determine whether GCP activity maps to the affected hosting workload, Compute Engine instance, service account, service-account key, user account, public IP, private IP, DNS zone, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, firewall rule, tenant, reseller, customer, or incident key.

Non-Coverage Conditions

GCP activity alone is not sufficient. GCP console access alone is not sufficient. Service-account activity alone is not sufficient. Organization ID, folder ID, or project ID alone is not sufficient lineage. GCP anomalies must not be attributed to hosting-control or shared-hosting compromise without reliable upstream hosting-risk context and cloud-lineage correlation.

Remediation, Containment, and Post-Remediation Recurrence Artifacts

Behavior Represented

Patch validation, plugin update validation, credential rotation, server isolation, tenant containment, hosted-content cleanup, web shell removal, DNS and mail remediation, backup validation, cloud-resource containment, incident-response action, and suspicious recurrence after remediation.

Relevant Artifacts

Patch timestamp, plugin update timestamp, affected version, remediation record, credential rotation record, password reset, SSH key rotation, API token rotation, database credential rotation, mail credential rotation, server isolation event, webroot cleanup record, file removal record, DNS rollback, mail remediation, abuse-report closure, customer notification analysis, incident-response case ID, post-remediation access, post-remediation file change, post-remediation outbound activity, post-remediation cloud activity, and timestamp.

Useful Log Sources

·        Vulnerability management records.

·        Patch management systems.

·        Hosting-control update logs.

·        LiteSpeed plugin update records.

·        CloudLinux/CageFS administrative records.

·        EDR containment records.

·        SIEM cases.

·        SOAR records.

·        Help desk systems.

·        Incident-response case-management systems.

·        Backup and restore records.

·        DNS and mail administrative logs.

·        Cloud audit logs.

·        Abuse-desk records.

Detection Use

These artifacts support validation that patching, cleanup, containment, credential rotation, and incident-response actions reduced risk and did not leave recurrence or cloud-impact activity unresolved.

Investigation Use

Investigators should determine whether suspicious access, file changes, web shell recurrence, DNS or mail manipulation, outbound communication, abuse reports, or cloud-resource activity continued after remediation.

Non-Coverage Conditions

Patch completion alone does not prove non-compromise. Plugin update alone does not prove non-compromise. Credential rotation alone does not prove containment. Cleanup activity by approved incident-response teams should not be treated as attacker activity without suspicious source, actor, timing, or recurrence context.

YARA Artifact Disposition

YARA has no deployable primary artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is hosting-control focused, shared-hosting focused, endpoint-behavior focused, telemetry-correlation based, cloud-lineage dependent, and tenant-impact oriented rather than static-file or malware-signature based.

YARA may become useful only if a validated malicious artifact, web shell family, credential-theft component, loader, dropper, script artifact, archive artifact, memory artifact, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

Artifact Correlation Requirements

Minimum Correlation Set for Probable Compromise

Probable compromise should require at least one suspicious access or foothold artifact and at least one post-access behavior artifact within a bounded time window.

Acceptable pairings include:

·        Suspicious hosting-control access plus abnormal administrative action.

·        Authentication or session mismatch plus privileged server-side execution.

·        FTP or web shell activity plus suspicious file write, symlink behavior, permission change, or hosted-content tampering.

·        LiteSpeed plugin-adjacent activity plus symlink or CloudLinux/CageFS tenant-boundary anomaly.

·        Suspicious access plus account modification, DNS change, mail change, database access, backup access, or outbound retrieval.

·        Hosted-content modification plus suspicious outbound communication or abuse report.

·        Post-remediation activity plus continued access, file change, outbound communication, abuse report, or cloud-resource activity.

Minimum Correlation Set for Confirmed Compromise

Confirmed compromise should require stronger corroboration that demonstrates unauthorized access, post-access behavior, and impact or persistence.

Acceptable evidence may include:

·        Unauthorized administrative access confirmed through access, authentication, session, and administrative action telemetry.

·        Suspicious hosting-control access followed by privileged execution and hosted-content tampering.

·        FTP or web shell foothold followed by root-context execution, symlink or permission abuse, and tenant-impact evidence.

·        Hosted-content tampering involving web shell placement, phishing pages, malware delivery content, unauthorized redirects, credential-harvesting pages, or customer-facing defacement.

·        Account, DNS, mail, database, backup, or credential changes outside approved workflows.

·        Outbound payload retrieval, command-and-control-like behavior, abuse infrastructure, spam activity, or malware hosting tied to affected hosting infrastructure.

·        Tenant-spanning changes across unrelated accounts, webroots, domains, mailboxes, databases, DNS zones, or backups.

·        Conditional AWS, Azure, or GCP activity with validated hosting-to-cloud lineage and independent evidence of unauthorized cloud activity.

Artifacts Not Sufficient Alone

The following artifacts should not be treated as confirmed compromise by themselves:

·        CVE reference.

·        Vulnerable version.

·        Exposed service.

·        Plugin inventory.

·        Scanner hit.

·        Failed request.

·        Successful login.

·        Single FTP session.

·        Single web request.

·        Single file write.

·        Single symlink event.

·        Single permission change.

·        Single outbound connection.

·        Single DNS change.

·        Single mail event.

·        Single abuse report.

·        Single cloud event.

·        Actor-name reference.

·        Web shell filename.

·        Public proof-of-concept string.

·        Source IP match.

·        User-agent match.

·        Patch completion.

·        Plugin update completion.

Final S27 Determination

The artifact model supports behavior-led detection, triage, investigation, and validation for hosting-control-plane compromise, shared-hosting escalation, LiteSpeed plugin-adjacent risk, CloudLinux/CageFS tenant-boundary exposure, privileged server-side execution, hosted-content tampering, credential exposure, outbound abuse, tenant-impacting behavior, post-remediation recurrence, and conditional downstream cloud-impact activity.

The strongest artifact posture exists when access logs, authentication/session telemetry, FTP logs, web logs, endpoint process telemetry, file and symlink telemetry, DNS logs, mail logs, outbound telemetry, abuse reports, tenant mapping, reseller mapping, CloudLinux/CageFS context, cloud telemetry, remediation records, and incident-response context can be correlated into bounded attack-chain sequences.

The artifact model intentionally avoids treating static indicators, scanner activity, vulnerable versions, exploit strings, filenames, symlink paths, user agents, source IPs, actor names, or isolated cloud events as proof of compromise. Confidence depends on correlated behavior, validated lineage, tenant context, operational baseline failure, and post-access or post-remediation evidence.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Implementation Purpose

S28 defines how SOC teams should deploy, triage, correlate, and operationalize the Block 4 detection model. This section converts the detection strategy, primary signals, telemetry requirements, detection opportunities, S25 rules, S26 traceability, and S27 artifacts into SOC-ready execution guidance.

The implementation model is behavior-led and classification-aware. It preserves the distinction between exploit attempt, suspected unauthorized access, related shared-hosting escalation, probable compromise, confirmed compromise, post-remediation recurrence, and conditional downstream cloud-impact evidence.

Operational Detection Model

Stage 1

Exposure, Scope, and Hosting-Role Identification

·        Identify all exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, shared-hosting, reseller-hosting, CloudLinux/CageFS, and customer-facing hosting assets.

·        Validate public exposure through asset inventory, vulnerability management, external exposure management, firewall review, cloud inventory, load balancer configuration, WAF/CDN configuration, control-plane reachability, and hosting-provider records.

·        Confirm patch validation status separately from compromise assessment.

·        Confirm LiteSpeed plugin update status separately from compromise assessment.

·        Flag systems that were internet-facing before patch validation or plugin update validation for retrospective review.

·        Assign higher triage priority to internet-facing assets with incomplete patch validation, incomplete plugin update validation, incomplete telemetry, known administrative exposure, FTP-enabled tenant access, web shell evidence, shared-hosting role, reseller-hosting role, CloudLinux/CageFS boundary dependency, or multi-tenant customer impact potential.

Stage 2

Exploit-Attempt, Foothold, and Probing Monitoring

·        Monitor exposed hosting-control-plane assets for suspicious administrative endpoint probing, malformed access attempts, abnormal request sequences, repeated access attempts, unusual sessionized-path interaction, and activity against cPanel, WHM, DNSOnly, WP Squared, reseller portal, webmail, API-style, or control-panel paths.

·        Monitor FTP, SFTP, web access, webroot, upload-path, plugin-path, and hosted-content activity for abnormal source context, unusual timing, suspicious path access, unexpected file writes, web shell-like interaction, symlink-sensitive behavior, and tenant-boundary anomalies.

·        Use NDR / Network Behavioral Analytics and edge telemetry as early-warning and supporting visibility unless authentication/session, endpoint, file, administrative-action, outbound, or tenant-impact evidence is present.

·        Classify scan-only, malformed-request, exposure-only, vulnerable-version, or plugin-inventory activity as exploit attempt or exposure-prioritization activity unless stronger evidence exists.

·        Retain exploit-attempt and foothold-adjacent events for time-window correlation, historical review, post-patch assessment, plugin-update assessment, tenant-boundary review, and exposure-aware hunting.

Stage 3

Suspected Unauthorized Access and Shared-Hosting Escalation Identification

·        Correlate control-panel access logs with authentication logs, session logs, administrator source context, known support workflows, reseller scope, customer-request context, and expected operational behavior.

·        Prioritize administrative path access without corresponding expected login, MFA, session establishment, approved support source, normal administrator behavior, or expected reseller scope.

·        Correlate FTP, web access, web shell, LiteSpeed plugin-adjacent, symlink, permission, file, and CloudLinux/CageFS artifacts with expected tenant boundaries, customer workflows, support activity, and hosting-provider maintenance.

·        Classify abnormal access-flow evidence as suspected unauthorized access unless post-access behavior is present.

·        Classify suspicious FTP or web shell foothold activity, symlink-sensitive activity, plugin-adjacent behavior, or CloudLinux/CageFS boundary anomaly as related shared-hosting escalation evidence unless privileged execution, root-context behavior, tenant-spanning impact, or hosted-content compromise is present.

·        Preserve source IP, request path, FTP account, user identity where available, session identifier where available, user agent, destination host, file path, symlink target, tenant account, reseller account, host identity, and timestamp for correlation.

Stage 4

Probable Compromise Identification

·        Correlate suspected unauthorized access or shared-hosting foothold evidence with endpoint process execution, account changes, administrative actions, hosted-content modification, permission changes, symlink-sensitive access, DNS changes, mail changes, suspicious outbound communication, persistence activity, cloud activity, abuse reports, or tenant-impacting behavior.

·        Prioritize process lineage from hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, cron, package-management, shell, interpreter, or plugin-adjacent context.

·        Prioritize account and administrative action involving administrator modification, password reset, reseller changes, API token creation, SSH key placement, privilege change, service-account modification, mail account changes, database user changes, backup access, file-manager use, service restart, or DNS changes.

·        Prioritize file activity involving webroots, hosted directories, script files, writable paths, hidden files, archive staging, cron paths, SSH key paths, plugin directories, CMS paths, mail directories, symlink targets, permission changes, root-owned file changes, and repeated changes across hosted accounts.

·        Prioritize outbound behavior involving payload retrieval, suspicious VPS infrastructure, command-and-control-like activity, redirector behavior, phishing hosting, malware delivery, spam activity, unusual DNS, rare destinations, abuse reports, or suspicious reputation changes.

·        Classify correlated access anomaly, foothold evidence, or plugin-adjacent escalation evidence plus unauthorized post-access behavior as probable compromise.

Stage 5

Confirmed Compromise and Blast-Radius Scoping

·        Validate whether post-access activity is unauthorized and cannot be explained by approved maintenance, patching, plugin updates, backups, migrations, support activity, reseller administration, automation, customer updates, certificate renewal, abuse-response activity, or recovery workflows.

·        Scope affected hosts, tenants, accounts, resellers, domains, webroots, databases, mailboxes, DNS zones, files, symlinks, plugin paths, backups, cloud identities, cloud resources, destinations, administrative objects, and customer-impact evidence.

·        Classify as confirmed compromise only when evidence supports unauthorized access or foothold activity plus validated post-access behavior, tenant-impacting activity, persistence, abuse, credential exposure, or unauthorized downstream cloud activity.

·        Preserve all artifacts required for containment, eradication, recovery, tenant impact assessment, customer assurance, regulatory review, cloud-resource containment, and historical compromise review.

SOC Triage Workflow

Initial Alert Intake

·        Confirm the alert source and detection category.

·        Identify whether the alert represents network probing, access anomaly, authentication/session mismatch, FTP activity, web shell activity, LiteSpeed plugin-adjacent behavior, symlink or permission anomaly, endpoint execution, file modification, account change, administrative action, outbound communication, cloud activity, abuse report, post-remediation recurrence, or tenant-impacting activity.

·        Confirm whether the affected asset is a known hosting-control, shared-hosting, reseller-hosting, CloudLinux/CageFS, LiteSpeed plugin, or customer-facing hosting asset.

·        Confirm whether the asset was internet-facing before patch validation or plugin update validation.

·        Confirm whether the event occurred during approved maintenance, support, backup, migration, patching, plugin update, reseller, automation, incident-response, abuse-response, or customer-request activity.

Evidence Classification

·        Classify edge or request-path probing as exploit attempt unless additional evidence exists.

·        Classify exposed service or vulnerable version status as exposure-prioritization evidence unless suspicious access or post-access behavior exists.

·        Classify access without expected authentication/session context as suspected unauthorized access.

·        Classify suspicious FTP, web shell, symlink, permission, LiteSpeed plugin-adjacent, or CloudLinux/CageFS boundary activity as related shared-hosting escalation evidence unless post-access or tenant-impact evidence exists.

·        Classify suspicious access or foothold activity followed by process, account, file, outbound, abuse, cloud, or tenant-impacting behavior as probable compromise.

·        Classify unauthorized access plus validated post-access activity, tenant-impacting activity, persistence, abuse infrastructure, credential exposure, or unauthorized cloud activity as confirmed compromise.

·        Do not escalate based only on exposure, scanner activity, public exploit strings, CVE labels, user-agent strings, source IP reputation, actor references, web shell filenames, symlink paths, or plugin inventory.

Correlation Requirements

·        Correlate by host identity.

·        Correlate by source IP.

·        Correlate by request path.

·        Correlate by FTP account.

·        Correlate by user identity where available.

·        Correlate by session identifier where available.

·        Correlate by process lineage.

·        Correlate by file path.

·        Correlate by symlink path and symlink target where available.

·        Correlate by tenant account where available.

·        Correlate by reseller account where available.

·        Correlate by hosted domain, mailbox, database, DNS zone, webroot, and backup path where available.

·        Correlate by destination domain or destination IP.

·        Correlate by cloud identity, cloud resource, storage resource, key resource, secret resource, network resource, and incident key where available.

·        Correlate by timestamp.

·        Correlate by administrative action where available.

·        Correlation must use source telemetry and artifacts, not another rule’s alert output.

Prioritization Guidance

Critical Priority

·        Suspicious control-panel access followed by privileged execution and account change.

·        Suspicious control-panel access followed by hosted-content modification across multiple tenants.

·        Suspicious FTP or web shell activity followed by root-context execution, symlink or permission abuse, root-owned file changes, or tenant-boundary failure.

·        LiteSpeed plugin-adjacent activity followed by symlink-sensitive behavior, CloudLinux/CageFS boundary anomaly, root-context execution, or tenant-spanning file access.

·        Suspicious control-panel access, FTP foothold, or web shell activity followed by web shell placement, persistence artifact creation, SSH key placement, API token creation, reseller privilege change, DNS manipulation, mail manipulation, or database access.

·        Suspicious hosting activity followed by outbound staging, command-and-control-like behavior, exfiltration-like behavior, phishing hosting, malware delivery, redirector activity, spam abuse, or botnet participation.

·        Any validated unauthorized action affecting multiple customer sites, mailboxes, databases, DNS zones, backups, or reseller-managed accounts.

·        AWS, Azure, or GCP activity with validated hosting-to-cloud lineage and independent evidence of unauthorized cloud activity involving identity, compute, storage, DNS, key, secret, network, or security-control impact.

High Priority

·        Authentication/session mismatch involving exposed hosting-control-plane assets.

·        Service-context execution from hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, cron, package-management, shell, or interpreter context.

·        Hosted-content modification involving scripts, webroots, writable paths, archive staging, cron paths, SSH key paths, plugin files, CMS paths, or repeated changes across hosted accounts.

·        Symlink, permission, ownership, or tenant-path anomalies near FTP, web shell, LiteSpeed plugin, CloudLinux/CageFS, or hosted-content activity.

·        Exposed cloud-hosted hosting assets showing suspicious outbound, DNS, WAF, load balancer, cloud security finding, storage, key, secret, or abuse-related context with validated hosting lineage.

·        Systems exposed before patch validation or plugin update validation with suspicious access or post-access artifacts.

Medium Priority

·        Repeated endpoint probing against exposed administrative paths.

·        Malformed request activity against control-panel endpoints.

·        Suspicious access from unfamiliar infrastructure without post-access evidence.

·        FTP or web access from unfamiliar source context without confirmed file impact, execution, or tenant-boundary evidence.

·        Cloud-native suspicious outbound activity without guest-level or hosting-risk corroboration.

·        Exposure-only findings involving incomplete patch validation, plugin update validation, or missing telemetry.

Low Priority

·        Known scanner activity against exposed administrative paths with no authentication/session anomaly and no post-access behavior.

·        Exposure-only findings on patched systems with no suspicious access and adequate historical review.

·        Vulnerable plugin inventory with no FTP, web shell, symlink, permission, root-context, or tenant-impact evidence.

·        Cloud-native findings that align with expected update, backup, monitoring, support, content delivery, or maintenance behavior.

SOC Investigation Steps

Step 1

Validate Asset Scope

·        Confirm asset role as cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, shared-hosting, reseller-hosting, CloudLinux/CageFS, or customer-facing hosting infrastructure.

·        Confirm internet exposure status.

·        Confirm patch validation status.

·        Confirm LiteSpeed plugin update validation status where applicable.

·        Confirm hosting role, tenant density, reseller scope, customer impact potential, and cloud-resource dependency.

·        Confirm whether the system was exposed before patch validation or plugin update validation.

Step 2

Validate Access, FTP, Web, and Session Context

·        Review control-panel access logs.

·        Review authentication logs.

·        Review session logs where available.

·        Review FTP and SFTP logs.

·        Review web access logs.

·        Compare request path, source IP, FTP account, user identity, session identifier, user agent, hosted domain, file path, tenant account, reseller account, and timestamp.

·        Identify whether access followed a normal authentication path or approved FTP, web, support, reseller, customer-maintenance, or automation workflow.

Step 3

Validate Endpoint, Account, and Service-Context Behavior

·        Review process creation and parent-child process lineage.

·        Review command-line content.

·        Review execution user and privilege level.

·        Review account changes, password resets, privilege changes, reseller changes, SSH key placement, API token creation, service-account changes, database user changes, and mail account changes.

·        Review service changes, scheduled tasks, cron entries, package activity, archive staging, database tooling, permission changes, and outbound retrieval tooling.

·        Determine whether execution originated from hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, cron, package-management, shell, interpreter, or plugin-adjacent context.

Step 4

Validate File, Symlink, Hosted-Content, and Tenant Impact

·        Review webroot and hosted directory file creation, modification, deletion, permission change, ownership change, symlink creation, symlink target, and timestamp change.

·        Review suspicious scripts, hidden files, writable paths, archive staging, plugin changes, CMS changes, cron paths, SSH key paths, configuration files, root-owned file changes, and web shell-like artifacts.

·        Map affected file paths to tenants, domains, resellers, mailboxes, databases, DNS zones, backups, and customer ownership where available.

·        Validate whether activity crossed expected CloudLinux/CageFS, tenant, reseller, domain, webroot, database, mailbox, DNS zone, or backup boundaries.

·        Distinguish customer updates, CMS changes, deployment automation, backup, migration, certificate renewal, plugin update, support activity, and incident-response cleanup from unauthorized modification.

Step 5

Validate Outbound, Abuse, and Cloud Behavior

·        Review DNS queries, destination domains, destination IPs, destination ports, protocol, connection direction, byte count, and duration.

·        Review proxy, firewall, WAF, CDN, load balancer, NDR, mail, abuse-desk, and cloud-native security findings.

·        Review whether outbound communication follows suspicious access, execution, file modification, symlink behavior, account activity, hosted-content tampering, or tenant-impact evidence.

·        Review abuse complaints, blocklist events, phishing hosting, malware delivery, spam behavior, redirectors, botnet activity, customer reports, or suspicious reputation changes.

·        Review AWS, Azure, or GCP telemetry only as downstream cloud-impact evidence when validated hosting-to-cloud lineage exists.

Step 6

Scope Impact and Response

·        Scope affected host.

·        Scope affected tenant accounts.

·        Scope affected reseller accounts.

·        Scope affected domains and webroots.

·        Scope affected mailboxes, databases, DNS zones, API tokens, SSH keys, administrator accounts, FTP accounts, backups, plugin paths, and hosted-content paths.

·        Scope affected AWS, Azure, or GCP identities, resources, storage, DNS zones, keys, secrets, network paths, and cloud-security findings where validated lineage exists.

·        Preserve logs and evidence for systems exposed before patch validation or plugin update validation.

·        Escalate containment and recovery based on classification, tenant blast radius, customer impact, abuse infrastructure, and cloud-impact evidence.

Containment and Response Guidance

Exploit Attempt

·        Preserve access, edge, WAF, CDN, firewall, and proxy logs.

·        Confirm asset exposure and patch status.

·        Confirm plugin update status where applicable.

·        Validate whether later authentication/session, FTP, web shell, endpoint, file, outbound, cloud, or tenant-impact behavior occurred.

·        Review historical activity around the attempt window.

·        Harden access controls and monitor for recurrence.

Suspected Unauthorized Access

·        Preserve control-panel access, authentication, session, FTP, and web telemetry.

·        Review administrator source, user identity, FTP account, support workflow, reseller scope, tenant scope, and session context.

·        Expand search across endpoint, account, file, symlink, DNS, mail, proxy, outbound, abuse, cloud, and tenant telemetry.

·        Temporarily increase monitoring for the affected host and related tenant or reseller scope.

·        Prepare containment if post-access behavior is found.

Related Shared-Hosting Escalation Evidence

·        Preserve FTP, web, file, symlink, permission, LiteSpeed plugin, CloudLinux/CageFS, endpoint, and tenant-mapping telemetry.

·        Validate whether activity aligns with approved customer maintenance, CMS update, support workflow, plugin update, backup, migration, or incident-response cleanup.

·        Review for root-context execution, root-owned file changes, tenant-boundary crossing, unexpected symlink targets, hosted-content tampering, or repeated activity across tenants.

·        Prepare containment if escalation, tenant impact, or post-remediation recurrence is found.

Probable Compromise

·        Isolate or restrict affected administrative access paths where operationally feasible.

·        Review and suspend suspicious administrative sessions, FTP access, API tokens, SSH keys, service-account access, and unauthorized accounts.

·        Review endpoint execution, account changes, file modifications, symlink behavior, DNS changes, mail changes, outbound communication, cloud activity, abuse reports, and tenant-impact artifacts.

·        Scope affected tenants, resellers, domains, mailboxes, databases, DNS zones, backups, cloud resources, and hosted content.

·        Begin containment and eradication planning.

Confirmed Compromise

·        Contain affected control-plane assets, affected shared-hosting scope, and impacted tenant or reseller scope.

·        Remove unauthorized accounts, API tokens, SSH keys, scheduled tasks, persistence artifacts, web shells, malicious scripts, redirects, modified files, unauthorized DNS changes, unauthorized mail changes, and unapproved cloud credentials.

·        Reset affected credentials and rotate secrets, API tokens, database credentials, mail credentials, SSH keys, cloud keys, service-account keys, managed identities, service principals, and automation credentials where applicable.

·        Review mail, DNS, database, backup, reseller, tenant-level, and cloud-resource impact.

·        Conduct historical review for systems exposed before patch validation or plugin update validation.

·        Validate recovery and monitor for recurrence.

False Positive Governance

Expected Benign Overlap

·        Hosting-provider support.

·        Reseller administration.

·        Scheduled maintenance.

·        Patch activity.

·        Plugin updates.

·        CMS updates.

·        Package updates.

·        Backups.

·        Migrations.

·        Certificate renewal.

·        Customer support.

·        Customer FTP workflows.

·        Customer web maintenance.

·        Deployment automation.

·        Monitoring.

·        Vulnerability scanning.

·        Abuse-response activity.

·        Incident-response cleanup.

·        Cloud backup, storage, DNS, KMS, Secret Manager, identity, and infrastructure automation.

Required Suppression Standard

·        Suppress only when source, user, host role, FTP account, command line, file path, symlink target, destination, administrative action, tenant scope, reseller scope, cloud resource, and time window align with an approved workflow.

·        Do not suppress broad hosting-control activity without validating operational context.

·        Do not suppress all FTP, web shell-like, symlink, permission, or plugin-adjacent activity without tenant, path, source, and maintenance validation.

·        Do not suppress exploit-attempt signals entirely; retain them for exposure-aware hunting and retrospective correlation.

·        Review suppressions after patch cycles, plugin updates, migrations, major customer changes, support-provider changes, tenant migrations, cloud migrations, and incident-response activity.

Implementation Sequence

Phase 1

Minimum Visibility Readiness

·        Confirm exposed hosting-control-plane inventory.

·        Confirm LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin inventory where applicable.

·        Confirm CloudLinux/CageFS and shared-hosting tenant mapping where applicable.

·        Confirm control-panel access logging.

·        Confirm authentication or session logging where available.

·        Confirm FTP and web access logging.

·        Confirm endpoint process telemetry.

·        Confirm file, permission, ownership, and symlink telemetry where available.

·        Confirm DNS, mail, abuse, and outbound network telemetry.

·        Confirm account-change and administrative action telemetry where available.

·        Confirm AWS, Azure, or GCP cloud telemetry where hosting-to-cloud lineage may exist.

·        Confirm timestamp normalization, host identity alignment, and tenant/reseller/domain mapping.

Phase 2

Rule Deployment

·        Deploy NDR / Network Behavioral Analytics early-warning detections where request-path, DNS, proxy, firewall, or outbound visibility exists.

·        Deploy endpoint process and file-event behavior rules on scoped hosting-control, shared-hosting, LiteSpeed plugin, and CloudLinux/CageFS assets.

·        Deploy SIEM correlation rules after field, lookup, host identity, tenant identity, reseller identity, cloud-lineage, and timestamp validation.

·        Deploy QRadar CRE building-block correlation after custom property, reference set, reference map, and offense-grouping validation.

·        Deploy portable SIGMA detections only after backend conversion, field mapping, enrichment-field creation, exception validation, and SIEM-native correlation validation.

·        Deploy AWS, Azure, and GCP cloud-impact rules only as conditional downstream correlation controls requiring hosting-to-cloud lineage.

·        Do not deploy YARA as a primary S25 rule.

Phase 3

Correlation and Triage Enablement

·        Configure host identity normalization.

·        Configure source IP and administrator source context.

·        Configure FTP account, webroot, hosted-path, tenant, reseller, domain, mailbox, database, DNS zone, backup, and CloudLinux/CageFS mappings where available.

·        Configure LiteSpeed plugin path and version context where applicable.

·        Configure approved maintenance, support, backup, migration, patching, plugin update, automation, customer-update, reseller, abuse-response, and incident-response workflows.

·        Configure destination baselines and approved outbound destinations.

·        Configure AWS, Azure, and GCP lineage keys for cloud identities, public IPs, private IPs, DNS zones, storage resources, keys, secrets, network paths, and incident keys.

·        Validate correlation windows against normal hosting operations.

Phase 4

Operational Review and Historical Assessment

·        Review systems exposed before patch validation or plugin update validation.

·        Review access, authentication/session, FTP, web, process, file, symlink, account, DNS, mail, proxy, outbound, abuse, cloud, and tenant artifacts over the relevant exposure window.

·        Document telemetry gaps and avoid treating missing logs as evidence of no compromise.

·        Reassess detection confidence after telemetry improvements, operational baseline updates, or additional abuse/customer-impact evidence.

Final S28 Determination

S28 operationalizes the Block 4 detection strategy into a SOC implementation model that preserves classification discipline, telemetry realism, platform deployability, and behavior-first detection. The guidance aligns with the requirement that correlation must rely on independently observable telemetry and that detection output must preserve the distinction between exploit attempt, suspected unauthorized access, related shared-hosting escalation, probable compromise, confirmed compromise, post-remediation recurrence, and conditional downstream cloud-impact evidence.

S29 — Detection Coverage Summary

Coverage Purpose

S29 summarizes the detection coverage achieved by the Block 4 rule set and identifies where coverage is strong, conditional, limited, or unavailable. This section evaluates coverage by behavior, telemetry source, and detection system without expanding the S25 rule set.

Overall Coverage Determination

Block 4 provides strong behavior-led coverage for suspicious hosting-control access, authentication/session mismatch, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent activity, CloudLinux/CageFS tenant-boundary context, post-access endpoint execution, hosted-content modification, account or administrative action abuse, DNS or mail manipulation, suspicious outbound communication, tenant-impacting change, post-remediation recurrence, and SIEM-level correlation where telemetry is available.

Coverage is conditional for NDR / Network Behavioral Analytics and cloud platforms because those systems provide important early-warning, supporting, and downstream cloud-impact visibility but cannot independently confirm cPanel authentication-bypass success, LiteSpeed plugin symlink mishandling, CloudLinux/CageFS boundary failure, guest-level compromise, root-level compromise, tenant-spanning impact, or customer data exposure.

Coverage is intentionally unavailable for primary YARA detection because the report’s governing model is behavior-led, telemetry-correlation based, cloud-lineage dependent, and tenant-impact oriented rather than artifact-led.

Coverage by Detection Behavior

Exposed Hosting-Control Probing

Coverage Level

Conditional

Covered By

·        NDR / Network Behavioral Analytics.

·        Splunk.

·        Elastic.

·        QRadar.

·        AWS, Azure, and GCP where hosted cloud infrastructure and exposure telemetry exist.

Coverage Summary

·        Coverage exists where request-path visibility, web access logs, proxy logs, WAF logs, CDN logs, application logs, or hosting-control logs are available.

·        NDR / Network Behavioral Analytics provides early-warning and supporting visibility where network, proxy, DNS, WAF, or request-path telemetry is available.

·        SIEM and Elastic coverage improves when request path, source IP, destination host, user agent, asset exposure, host identity, and timestamp are normalized.

·        Cloud-native coverage supports prioritization for exposed hosted assets but does not inspect cPanel authentication flow, LiteSpeed plugin behavior, CloudLinux/CageFS tenant boundaries, or guest-level behavior.

Residual Gap

·        Encrypted traffic, missing request-path visibility, absent access logs, CDN or proxy obscuring, incomplete source attribution, short retention, and inconsistent host identity reduce coverage.

·        Scan-only activity remains exploit attempt unless correlated with stronger evidence.

Unauthorized Hosting-Control Access and Authentication-Flow Mismatch

Coverage Level

Strong where application-layer telemetry exists

Covered By

·        Splunk.

·        Elastic.

·        QRadar.

·        NDR / Network Behavioral Analytics as supporting source-context visibility.

Coverage Summary

·        Coverage is strong where control-panel access logs, authentication logs, session logs, source IP, user identity, session identifier, administrator source context, host identity, and timestamps are available.

·        Splunk, Elastic, and QRadar provide the strongest access-flow correlation paths when data is normalized.

·        Coverage supports suspected unauthorized access and can support escalation when post-access evidence is present.

·        NDR / Network Behavioral Analytics can support source, destination, timing, and access-path context but cannot independently validate authentication or session state.

Residual Gap

·        Missing session telemetry, inconsistent authentication fields, weak source identity, incomplete administrator baselines, incomplete reseller context, and undocumented support workflows reduce confidence.

·        This behavior cannot be confirmed by network-layer or cloud-native telemetry alone.

FTP Foothold, Web Shell Activity, and Shared-Hosting Escalation

Coverage Level

Moderate to strong where FTP, web, file, endpoint, and tenant telemetry exist

Covered By

·        SentinelOne.

·        Splunk.

·        Elastic.

·        QRadar.

·        SIGMA where endpoint fields are mapped.

·        NDR / Network Behavioral Analytics as supporting network and outbound visibility.

Coverage Summary

·        Coverage exists for suspicious FTP activity, web access, web shell interaction, abnormal upload paths, suspicious hosted-path access, webroot changes, symlink-sensitive behavior, permission anomalies, plugin-adjacent execution, and CloudLinux/CageFS tenant-boundary context.

·        Coverage is strongest when FTP logs, web logs, endpoint process telemetry, file telemetry, symlink telemetry, tenant mapping, reseller mapping, and CloudLinux/CageFS context are available.

·        SentinelOne and Elastic provide strong endpoint and file behavior visibility where host telemetry is deployed.

·        Splunk and QRadar provide correlation paths when FTP, web, file, endpoint, tenant, and operational context are normalized.

Residual Gap

·        Missing FTP logs, incomplete web logs, absent symlink telemetry, missing CloudLinux/CageFS context, weak tenant mapping, and high-volume customer maintenance reduce confidence.

·        FTP activity, web access, a single file write, a single symlink event, or plugin inventory alone does not prove compromise.

Post-Access Service-Context Execution

Coverage Level

Strong where endpoint process telemetry exists

Covered By

·        SentinelOne.

·        Elastic.

·        SIGMA.

·        Splunk.

·        QRadar.

Coverage Summary

·        Coverage is strong when endpoint telemetry preserves process ancestry, command line, execution user, privilege level, host identity, service context, and timestamp.

·        SentinelOne and Elastic provide strong endpoint-native behavior detection.

·        SIGMA provides portable event-rule template logic where backend conversion preserves process lineage, command-line content, host identity, and user context.

·        Splunk and QRadar provide correlation paths when endpoint telemetry is ingested and normalized.

Residual Gap

·        Missing process lineage, incomplete command-line capture, weak endpoint coverage, missing effective-user context, and overlap with maintenance, patching, plugin updates, backup, migration, support, and automation workflows reduce confidence.

·        Endpoint evidence does not prove the original authentication-bypass mechanism without application-layer telemetry.

Hosted-Content, File-System, Symlink, and Persistence-Relevant Modification

Coverage Level

Moderate to strong where file telemetry and hosted-path context exist

Covered By

·        SentinelOne.

·        Elastic.

·        SIGMA.

·        Splunk.

·        QRadar.

Coverage Summary

·        Coverage exists for suspicious file creation, modification, deletion, ownership changes, permission changes, symlink behavior, script placement, writable-path abuse, archive staging, cron-path modification, SSH key placement, plugin modification, CMS modification, hidden files, and hosted-content tampering.

·        SentinelOne and Elastic provide stronger coverage where file telemetry and source process context are available.

·        SIGMA provides portable endpoint event templates but requires local field mapping, backend conversion, and SIEM-native correlation for sequence context.

·        Splunk and QRadar provide correlation coverage where file telemetry, tenant mapping, access context, process lineage, and operational context are normalized.

Residual Gap

·        Customer updates, CMS changes, deployment automation, backups, migrations, certificate renewal, plugin updates, support, incident-response cleanup, and reseller administration create operational overlap.

·        Missing tenant mapping weakens blast-radius assessment.

·        Missing source process context reduces confidence but does not invalidate file-event triage.

Account Change, Administrative Action, DNS, Mail, Database, and Backup Activity

Coverage Level

Strong where account and administrative action telemetry is available

Covered By

·        Splunk.

·        QRadar.

·        SentinelOne where endpoint/account events are available.

·        Elastic where administrative or endpoint account telemetry is available.

·        AWS, Azure, and GCP for conditional downstream cloud-resource changes with validated hosting lineage.

Coverage Summary

·        Coverage exists for administrator changes, password resets, reseller modifications, privilege changes, API token creation, SSH key placement, service-account modification, account creation, DNS changes, mail changes, database changes, backup access, file-manager actions, service restarts, and cloud-resource administrative changes.

·        Splunk and QRadar provide the strongest correlation paths when account and administrative action logs are normalized.

·        Endpoint tools support host-level account and persistence artifacts.

·        Cloud platforms support downstream impact assessment only where hosting-to-cloud lineage is validated.

Residual Gap

·        Missing administrative action logs, weak account-action normalization, limited reseller context, absent tenant mapping, and undocumented customer-request workflows reduce confidence.

·        Legitimate support, account provisioning, migrations, customer requests, reseller administration, DNS administration, mail administration, backups, and automation must be validated before escalation.

Suspicious Outbound Communication and Abuse Infrastructure

Coverage Level

Moderate where DNS, proxy, network, abuse, endpoint, or cloud telemetry exists

Covered By

·        NDR / Network Behavioral Analytics.

·        Splunk.

·        QRadar.

·        Elastic where network or DNS telemetry is available.

·        SentinelOne where process-to-network context is available.

·        AWS.

·        Azure.

·        GCP.

Coverage Summary

·        Coverage exists for suspicious destinations, newly observed domains, unusual infrastructure, payload-staging locations, command-and-control-like behavior, redirector activity, exfiltration-like traffic, phishing hosting, malware hosting, spam behavior, abuse reports, and suspicious outbound network behavior.

·        NDR / Network Behavioral Analytics provides strong supporting visibility where DNS, proxy, TLS, firewall, outbound, or flow telemetry is available.

·        Splunk and QRadar support correlation between access anomalies, endpoint behavior, file impact, and outbound communication.

·        AWS, Azure, and GCP provide conditional cloud-native visibility for exposed assets with suspicious outbound, DNS, firewall, WAF, load balancer, storage, key, secret, or security-finding context.

·        Elastic and SentinelOne can contribute where DNS, proxy, endpoint-network, or process-to-network telemetry is ingested and normalized.

Residual Gap

·        Outbound activity without process attribution has reduced confidence.

·        Cloud-native outbound visibility does not prove guest-level compromise.

·        Approved update repositories, backups, monitoring, content delivery, support infrastructure, package repositories, CDNs, and normal hosting traffic require baselining.

Tenant Blast Radius and Downstream Customer Impact

Coverage Level

Conditional

Covered By

·        Splunk.

·        QRadar.

·        Elastic where tenant mapping is available.

·        SentinelOne where file and host context are available.

·        NDR / Network Behavioral Analytics where domain, mail, DNS, and abuse context is available.

·        SOC correlation using S27 artifacts.

Coverage Summary

·        Coverage exists where hosted paths, accounts, reseller scope, domains, mailboxes, databases, DNS zones, webroots, backup paths, CloudLinux/CageFS context, FTP accounts, cloud resources, and customer sites can be mapped to tenant identity.

·        SIEM correlation provides the strongest blast-radius assessment when tenant, domain, account, file, DNS, mail, database, backup, cloud-resource, and administrative action data is normalized.

·        File, account, DNS, mail, abuse, and cloud artifacts provide supporting evidence for multi-tenant or reseller-scope impact.

Residual Gap

·        Missing tenant mapping materially limits blast-radius assessment.

·        Cloud-native and network telemetry cannot provide tenant scope without enrichment.

·        YARA is not used as primary coverage because artifact matching does not provide reliable blast-radius visibility.

Conditional Downstream AWS, Azure, and GCP Cloud Impact

Coverage Level

Conditional

Covered By

·        AWS.

·        Azure.

·        GCP.

·        Splunk, Elastic, and QRadar where cloud telemetry and hosting-risk context are ingested into the same analytics environment.

Coverage Summary

·        Coverage exists where hosting-risk context can be linked to cloud activity through workload identity, public IP, private IP, resource ID, access key, managed identity, service principal, service account, DNS zone, hosted domain, storage resource, key vault, KMS key, Secret Manager secret, tenant, reseller, customer, or incident key.

·        AWS coverage supports conditional downstream detection involving IAM, STS, EC2, S3, Route 53, SES, snapshots, security groups, GuardDuty, Security Hub, Config, Access Analyzer, and related cloud-service activity.

·        Azure coverage supports conditional downstream detection involving Entra ID context, Azure Activity, role assignments, service principals, managed identities, VMs, disks, snapshots, Azure DNS, Storage, Key Vault, Defender for Cloud, Sentinel, Azure Monitor, and network exposure changes.

·        GCP coverage supports conditional downstream detection involving IAM, service accounts, service-account keys, Compute Engine, Cloud DNS, Cloud Storage, Cloud KMS, Secret Manager, firewall rules, snapshots, images, Security Command Center, Event Threat Detection, and Cloud Logging.

Residual Gap

·        Cloud activity alone is not sufficient.

·        Cloud console access alone is not sufficient.

·        IAM, role assignment, service-principal, service-account, storage, key, secret, DNS, or network events alone are not sufficient.

·        Account ID, tenant ID, subscription ID, resource group, project ID, folder ID, or organization ID alone is not sufficient lineage.

·        Cloud findings must not be attributed to hosting-control or shared-hosting compromise without reliable upstream hosting-risk context and cloud-lineage correlation.

Coverage by System

NDR / Network Behavioral Analytics

Coverage Level

Conditional supporting and early-warning coverage

Coverage Summary

·        Provides network-layer visibility into exposed administrative endpoint probing, suspicious source behavior, unusual FTP or web traffic, rare DNS destinations, unusual outbound behavior, abuse infrastructure, and post-remediation recurrence where network telemetry can be linked to affected hosting assets.

·        Supports exploit-attempt classification, time-window correlation, and outbound abuse triage.

·        Does not independently confirm authentication-bypass success, session validity, web shell execution, root-context execution, symlink exploitation, hosted-content modification, tenant-spanning compromise, or customer data exposure.

Coverage Status

Accepted with deployment conditions.

SentinelOne

Coverage Level

Strong endpoint behavior coverage

Coverage Summary

·        Covers service-context execution, suspicious process lineage, shell or interpreter activity, administrative tooling, account-management utilities, hosted-content modification, file-impact behavior, outbound retrieval, and post-remediation recurrence.

·        Supports post-access behavior identification where process lineage, command-line visibility, file telemetry, host scoping, and operational context are available.

·        Requires application-layer, FTP, web, tenant, or SIEM context for original access validation and blast-radius assessment.

Coverage Status

Accepted.

Splunk

Coverage Level

Strong SIEM correlation coverage

Coverage Summary

·        Covers authentication/session mismatch, suspicious hosting access followed by privileged execution or account change, tenant-impacting file activity, DNS or mail manipulation, outbound communication, cloud-impact correlation, and post-remediation recurrence.

·        Provides broad correlation coverage where access, FTP, web, endpoint, account, file, symlink, DNS, mail, proxy, network, tenant, reseller, cloud, and asset telemetry are normalized.

·        Depends on ingestion completeness, field consistency, macro validation, lookup quality, host identity alignment, timestamp normalization, summary or acceleration strategy, and false-positive governance.

Coverage Status

Accepted.

Elastic

Coverage Level

Strong endpoint and access-correlation coverage

Coverage Summary

·        Covers control-panel access or authentication-flow mismatch, endpoint service-context execution, suspicious hosted-content modification, file and symlink activity, outbound behavior, and post-remediation recurrence.

·        Supports endpoint and file behavior where Elastic Defend or equivalent telemetry is available.

·        Requires ECS or local field mapping, index and data-stream validation, exception-list governance, enrichment policies, value lists, transforms, host identity, tenant mapping, and query-performance validation.

Coverage Status

Accepted.

QRadar

Coverage Level

Strong event-correlation coverage where custom properties are mature

Coverage Summary

·        Covers access-flow mismatch and suspicious access followed by post-access behavior through CRE rules, building blocks, custom properties, reference sets, reference maps, and offense grouping.

·        Supports correlation across access, FTP, web, endpoint, account, file, DNS, mail, proxy, outbound, abuse, tenant, and cloud telemetry.

·        Depends on log source onboarding, custom property extraction, reference sets, reference maps, timestamp alignment, host normalization, offense tuning, and false-positive governance.

Coverage Status

Accepted.

SIGMA

Coverage Level

Portable conditional endpoint coverage

Coverage Summary

·        Covers portable endpoint process behavior and hosted-content or persistence-relevant service-context activity where backend conversion preserves required fields.

·        Useful for service-context execution, shell and interpreter activity, administrative tooling, archive staging, account-management tooling, and outbound retrieval.

·        Does not provide primary authentication-bypass confirmation, FTP context, web access correlation, tenant blast-radius assessment, cloud-impact correlation, or complex multi-source sequence logic by itself.

Coverage Status

Accepted with backend conversion conditions.

YARA

Coverage Level

No primary S25 coverage

Coverage Summary

·        No primary rule is included because YARA is artifact-led and does not align with the behavior-first detection model.

·        Optional artifact hunting may be considered outside primary S25 if a validated malicious artifact, web shell family, loader, dropper, script artifact, memory artifact, archive artifact, credential-theft component, or reusable malware family is recovered.

·        YARA does not observe authentication-flow mismatch, session validity, FTP foothold context, LiteSpeed plugin-adjacent behavior, CloudLinux/CageFS boundary failure, privileged execution lineage, account changes, tenant blast radius, outbound process attribution, or downstream cloud lineage.

Coverage Status

Excluded from primary S25.

AWS

Coverage Level

Conditional downstream cloud-impact coverage

Coverage Summary

·        Covers AWS activity linked to hosting-risk context through validated lineage involving workload, IAM role, access key, instance profile, EC2 instance, public IP, private IP, VPC, Route 53 zone, hosted domain, S3 bucket, SES identity, security group, snapshot, tenant, reseller, customer, or incident key.

·        Supports suspected downstream cloud impact and high-priority triage when AWS activity is objectively suspicious.

·        Requires hosting-risk context and reliable cloud-lineage correlation before attribution to hosting-control or shared-hosting compromise.

Coverage Status

Accepted with deployment conditions.

Azure

Coverage Level

Conditional downstream cloud-impact coverage

Coverage Summary

·        Covers Azure activity linked to hosting-risk context through validated lineage involving workload, VM ID, managed identity, service principal, user account, public IP, private IP, DNS zone, hosted domain, storage account, key vault, virtual network, network security group, tenant, reseller, customer, or incident key.

·        Supports suspected downstream cloud impact and high-priority triage when Azure activity is objectively suspicious.

·        Requires hosting-risk context and reliable cloud-lineage correlation before attribution to hosting-control or shared-hosting compromise.

Coverage Status

Accepted with deployment conditions.

GCP

Coverage Level

Conditional downstream cloud-impact coverage

Coverage Summary

·        Covers GCP activity linked to hosting-risk context through validated lineage involving project, Compute Engine instance, service account, service-account key, user account, public IP, private IP, DNS zone, hosted domain, Cloud Storage bucket, Cloud KMS key, Secret Manager secret, VPC network, firewall rule, tenant, reseller, customer, or incident key.

·        Supports suspected downstream cloud impact and high-priority triage when GCP activity is objectively suspicious.

·        Requires hosting-risk context and reliable cloud-lineage correlation before attribution to hosting-control or shared-hosting compromise.

Coverage Status

Accepted with deployment conditions.

Coverage Strengths

·        Strong behavior-led coverage across unauthorized hosting-control access, authentication/session mismatch, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent behavior, shared-hosting escalation, CloudLinux/CageFS tenant-boundary context, post-access execution, hosted-content modification, account change, tenant-impacting activity, suspicious outbound communication, post-remediation recurrence, and conditional cloud-impact activity.

·        Strong SIEM correlation coverage through Splunk, Elastic, and QRadar where telemetry is normalized.

·        Strong endpoint behavior coverage through SentinelOne and Elastic where process and file telemetry are available.

·        Portable endpoint behavior coverage through SIGMA where backend conversion preserves required fields.

·        Conditional cloud-impact coverage through AWS, Azure, and GCP where hosting-to-cloud lineage exists.

·        Clear exclusion of weak artifact-only YARA coverage from primary S25.

Coverage Limitations

·        Network-layer visibility cannot confirm successful authentication bypass.

·        NDR cannot independently prove web shell execution, symlink exploitation, CloudLinux/CageFS boundary failure, root-level compromise, hosted-content modification, or tenant impact.

·        Cloud-native visibility cannot directly confirm cPanel session validity, LiteSpeed plugin behavior, guest execution, hosted-content modification, account changes, web shell placement, root-context activity, or tenant impact.

·        Endpoint visibility cannot prove the initial access mechanism without application-layer, FTP, web, or SIEM context.

·        SIEM correlation depends on normalized telemetry, lookup quality, host identity alignment, timestamp alignment, tenant mapping, enrichment quality, retention, and query performance.

·        Tenant blast-radius assessment depends on tenant mapping, hosted-path ownership, reseller scope, domain-to-account mapping, mailbox mapping, database mapping, backup mapping, CloudLinux/CageFS mapping, and DNS-zone mapping.

·        Outbound communication without process attribution must be treated with lower confidence unless supported by additional artifacts.

·        Missing logs must be documented as detection gaps, not treated as evidence of absence.

Final Coverage Determination

The Block 4 coverage model is strong for behavior-led detection where control-panel access, authentication/session, FTP, web, endpoint process, file, symlink, account, DNS, mail, proxy, network, abuse, cloud, tenant, reseller, and asset telemetry are available.

Coverage is conditional for NDR / Network Behavioral Analytics and AWS, Azure, and GCP because those systems provide useful visibility but cannot confirm compromise without supporting telemetry and validated lineage. YARA is correctly excluded from primary S25 coverage.

This coverage profile remains consistent with S26, which validates that the 25 accepted S25 rules remain behavior-led, telemetry-supported, locally deployable after validation, and constrained to observable evidence.

S30 — Intelligence Maturity Assessment

Assessment Purpose

S30 evaluates the intelligence maturity of the Block 4 detection model for [EXP] Hosting Control-Plane Compromise Risk from cPanel KEV Exploitation. This section assesses whether the detection program can reliably move from exposure awareness to exploit-attempt visibility, suspected unauthorized access identification, shared-hosting escalation assessment, probable compromise detection, confirmed compromise validation, tenant-impact scoping, post-remediation recurrence review, and conditional downstream cloud-impact assessment.

Overall Intelligence Maturity

Maturity Rating

High with telemetry-dependent and lineage-dependent constraints.

Assessment Summary

The Block 4 detection model is mature because it is behavior-led, telemetry-supported, locally deployable after validation, and explicitly constrained against brittle exploit-string, IOC, actor-name, scanner-name, web shell filename, symlink-path, or plugin-inventory dependency. It defines clear detection anchors, telemetry requirements, detection opportunities, S25 rules, S26 traceability, S27 artifacts, S28 SOC workflows, and S29 coverage boundaries.

The model is strongest in environments that preserve control-panel access telemetry, authentication/session telemetry, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, account-change telemetry, administrative action telemetry, DNS and mail telemetry, proxy telemetry, outbound network telemetry, abuse-report evidence, tenant mapping, reseller mapping, CloudLinux/CageFS context, asset exposure context, cloud-resource lineage, remediation records, and operational baselines.

Maturity Drivers

Behavior-Led Detection Model

·        Detection is anchored to unauthorized hosting-control access, authentication/session anomaly, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent behavior, CloudLinux/CageFS tenant-boundary context, service-context execution, hosted-content modification, account change, DNS or mail manipulation, suspicious outbound communication, tenant-impacting behavior, post-remediation recurrence, and conditional downstream cloud-impact activity.

·        The model does not depend on CVE labels, public proof-of-concept strings, scanner names, attacker IP addresses, static web shell signatures, symlink paths, plugin-version inventory, or one exploit implementation.

·        The model remains useful if exploit formatting, infrastructure, timing, user agents, request sequences, payloads, filenames, symlink paths, source networks, or post-compromise timing change.

Telemetry-Backed Rule Set

·        The rule set maps each detection objective to observable telemetry.

·        Endpoint rules require process and file artifacts.

·        SIEM rules require normalized access, authentication/session, FTP, web, endpoint, account, file, symlink, DNS, mail, proxy, network, tenant, reseller, cloud, and asset context.

·        NDR / Network Behavioral Analytics rules require network, DNS, proxy, WAF, outbound, source, and host-role context.

·        Cloud rules require hosting-risk context, cloud audit telemetry, resource mapping, cloud identity mapping, storage, key, secret, DNS, network, and validated cloud-lineage keys.

·        YARA is excluded from primary coverage because artifact-led matching would weaken the behavior-led model.

Traceability and Classification Discipline

·        S26 validates the rule set against S21 through S25.

·        Detection classifications remain separated across exploit attempt, suspected unauthorized access, related shared-hosting escalation, probable compromise, confirmed compromise, post-remediation recurrence, and conditional cloud-impact evidence.

·        No rule requires another detection rule’s alert output as a prerequisite.

·        No rule claims confirmed compromise without corroborating post-access or independently suspicious downstream cloud evidence.

·        NDR / Network Behavioral Analytics and cloud rules are treated as early-warning, supporting, triage, prioritization, or conditional downstream controls rather than universal compromise-confirmation sources.

Operational Readiness

·        S27 defines the artifacts required for triage, correlation, validation, blast-radius assessment, and scoping.

·        S28 defines the SOC implementation model for exposure identification, probing detection, unauthorized access review, shared-hosting escalation assessment, probable compromise detection, confirmed compromise scoping, containment, and response prioritization.

·        S29 defines coverage strengths and limitations across behavior classes and detection systems.

·        The model supports historical review because patch validation and plugin update validation do not prove that compromise did not occur before remediation.

Maturity by Intelligence Function

Exposure Intelligence

Maturity Level

High

Assessment

·        The model requires identification of exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, shared-hosting, reseller-hosting, CloudLinux/CageFS, and customer-facing hosting assets.

·        It separates exposure from compromise and requires suspicious access, foothold activity, post-access behavior, or tenant-impact evidence before escalation.

·        It prioritizes systems exposed before patch validation or plugin update validation for retrospective review.

·        It incorporates cloud-hosted exposure visibility for AWS, Azure, and GCP while preserving the limitation that cloud-native telemetry does not confirm guest compromise.

Residual Limitation

Exposure intelligence depends on accurate asset inventory, external reachability context, patch validation, plugin update validation, hosting role mapping, cloud resource mapping, tenant ownership, reseller ownership, and service ownership data.

Access and Session Intelligence

Maturity Level

High where application telemetry exists

Assessment

·        The model prioritizes access-flow mismatch and authentication/session inconsistency as central detection objectives.

·        It supports identification of administrative access that does not align with expected login, session, MFA, source, user, support, reseller, customer, or operational context.

·        It provides SIEM correlation paths for access and session review across Splunk, Elastic, and QRadar.

·        It preserves classification discipline by treating access anomalies as suspected unauthorized access unless post-access behavior is present.

Residual Limitation

Access and session maturity is reduced where session telemetry is incomplete, authentication logs are inconsistent, administrator baselines are weak, reseller scope is unclear, customer maintenance is undocumented, or support activity is poorly documented.

FTP, Web Shell, and Shared-Hosting Escalation Intelligence

Maturity Level

Moderate to high where FTP, web, file, endpoint, and tenant telemetry exist

Assessment

·        The model supports assessment of lower-privileged foothold conditions through FTP logs, web access logs, web shell interaction, hosted-path activity, uploaded-file evidence, file telemetry, endpoint execution, symlink behavior, permission changes, and CloudLinux/CageFS context.

·        It treats LiteSpeed plugin-adjacent activity and CloudLinux/CageFS tenant-boundary evidence as related shared-hosting escalation context rather than standalone proof of compromise.

·        It supports escalation when foothold activity is correlated with root-context execution, hosted-content tampering, tenant-boundary failure, outbound communication, or post-remediation recurrence.

Residual Limitation

Maturity is reduced where FTP logs are unavailable, web logs lack hosted-path context, file and symlink telemetry is incomplete, CloudLinux/CageFS mapping is missing, customer maintenance volume is high, or tenant ownership cannot be mapped.

Endpoint Execution Intelligence

Maturity Level

High where EDR or endpoint telemetry exists

Assessment

·        The model provides strong coverage for service-context execution, suspicious shell activity, interpreter use, account-management utility execution, package activity, service-control commands, staging, archive activity, database tooling, and outbound retrieval tooling.

·        It supports durable post-access detection even when exploit request formatting, symlink paths, filenames, or attacker infrastructure changes.

·        SentinelOne, Elastic, SIGMA, Splunk, and QRadar provide complementary endpoint execution visibility depending on telemetry and normalization.

Residual Limitation

Endpoint execution maturity is reduced where process lineage, command-line capture, execution user, effective privilege context, process-to-network attribution, or host role scoping is incomplete.

File, Symlink, and Hosted-Content Intelligence

Maturity Level

Moderate to high where file telemetry and tenant mapping exist

Assessment

·        The model provides strong artifact coverage for hosted-content modification, suspicious script creation, web shell placement, writable-path abuse, archive staging, cron changes, SSH key placement, hidden files, plugin modification, CMS modification, symlink behavior, permission changes, ownership changes, and webroot tampering.

·        It supports tenant-impact assessment where hosted paths can be mapped to accounts, domains, resellers, mailboxes, databases, DNS zones, backups, and CloudLinux/CageFS context.

·        It treats file activity as stronger evidence when correlated with access anomalies, FTP or web shell activity, service-context execution, account change, outbound activity, abuse reports, or tenant impact.

Residual Limitation

Maturity is reduced where file telemetry lacks source process context, symlink telemetry is unavailable, tenant mapping is incomplete, customer update volume is high, or CMS, plugin, deployment, backup, and support workflows are not baselined.

Account and Administrative Action Intelligence

Maturity Level

Moderate to high

Assessment

·        The model covers administrator modification, password reset, privilege change, reseller modification, API token creation, SSH key placement, service-account modification, DNS changes, mail changes, database changes, backup access, service changes, and administrative action anomalies.

·        It supports escalation when suspicious access, FTP foothold, web shell activity, or shared-hosting escalation evidence is followed by unauthorized administrative action.

·        It supports persistence and blast-radius assessment when mapped to tenant, reseller, domain, mailbox, database, DNS, backup, and cloud-resource context.

Residual Limitation

Maturity is reduced where administrative action logs are incomplete, action names are not normalized, reseller scope is unclear, tenant context is missing, or support and customer-request workflows are poorly documented.

Outbound and Abuse Intelligence

Maturity Level

Moderate

Assessment

·        The model covers payload retrieval, staging, command-and-control-like behavior, redirector behavior, exfiltration-like traffic, phishing hosting, malware delivery, spam activity, botnet participation, abuse complaints, blocklist events, and reputation changes.

·        It supports NDR / Network Behavioral Analytics visibility and cloud-native visibility through AWS, Azure, and GCP for exposed assets with suspicious outbound or security context.

·        It treats outbound activity as stronger evidence when correlated with suspicious access, FTP or web shell activity, execution, file modification, account change, tenant impact, abuse reports, or post-remediation recurrence.

Residual Limitation

Maturity is reduced where DNS logs, proxy logs, flow logs, mail logs, process-to-network attribution, approved destination baselines, abuse-desk records, or tenant context are unavailable.

Tenant and Blast-Radius Intelligence

Maturity Level

Conditional

Assessment

·        The model provides a clear path for determining whether suspicious activity is isolated or spans multiple hosted accounts, reseller-managed sites, domains, mailboxes, databases, DNS zones, backups, FTP accounts, webroots, plugin paths, or CloudLinux/CageFS tenant boundaries.

·        It supports prioritization of multi-tenant impact, downstream customer exposure, and customer-assurance needs.

·        It avoids definitive tenant-impact conclusions where tenant mapping is unavailable.

Residual Limitation

Tenant and blast-radius maturity depends heavily on path-to-tenant, domain-to-account, mailbox-to-account, database-to-account, DNS-zone-to-tenant, backup-to-tenant, FTP-account-to-tenant, CloudLinux/CageFS-to-tenant, cloud-resource-to-tenant, and reseller-scope mappings.

Cloud-Lineage and Downstream Cloud-Impact Intelligence

Maturity Level

Conditional

Assessment

·        The model provides conditional downstream AWS, Azure, and GCP coverage when hosting-risk context can be joined to cloud activity through validated identity, workload, public IP, private IP, DNS, storage, key, secret, tenant, reseller, customer, or incident lineage.

·        It prevents overclaiming by treating cloud findings as conditional downstream evidence unless the cloud telemetry independently supports unauthorized activity.

·        It supports escalation when hosting-risk context is followed by suspicious IAM, role, service-principal, service-account, storage, key, secret, DNS, network, compute, snapshot, image, security-control, or cloud-resource behavior.

Residual Limitation

Cloud-lineage maturity is reduced where cloud telemetry is incomplete, cloud identities are shared, storage/key/secret data access logs are disabled, resource tagging is weak, hosted-domain mapping is incomplete, or lineage relies only on account, tenant, subscription, project, folder, or organization context.

System-Level Maturity

NDR / Network Behavioral Analytics

Maturity Rating

Conditional

Assessment

·        Mature as an early-warning and supporting visibility layer where request-path, DNS, proxy, firewall, WAF, TLS, flow, or outbound telemetry exists.

·        Not mature as a compromise-confirmation source.

·        Best used for exposure-aware monitoring, source-context analysis, outbound-abuse triage, and time-window correlation.

SentinelOne

Maturity Rating

High

Assessment

·        Mature for endpoint post-access execution, service-context process lineage, file impact, hosted-content modification, outbound retrieval, and post-remediation recurrence where process and file telemetry are complete.

·        Requires application-layer, FTP, web, tenant, or SIEM context for original access validation and blast-radius assessment.

·        Strong for durable behavior detection.

Splunk

Maturity Rating

High

Assessment

·        Mature as a broad SIEM correlation layer where access, authentication/session, FTP, web, endpoint, account, file, symlink, DNS, mail, proxy, network, tenant, reseller, cloud, and asset telemetry are normalized.

·        Requires strong field normalization, macro governance, lookup governance, host identity alignment, timestamp alignment, retention, acceleration or summary strategy, and performance validation.

Elastic

Maturity Rating

High

Assessment

·        Mature for endpoint behavior, access-flow anomaly detection, file and symlink activity, hosted-content modification, and sequence correlation where Elastic Defend and relevant access/file telemetry are available.

·        Requires index, field, data-stream, exception-list, value-list, enrichment, transform, host identity, tenant mapping, and query-performance validation.

QRadar

Maturity Rating

Moderate to high

Assessment

·        Mature for event-correlation use cases where log sources, custom properties, reference sets, reference maps, and CRE-supported building blocks are well implemented.

·        Maturity decreases where custom property extraction, host normalization, tenant enrichment, reference-set governance, timestamp alignment, or offense tuning is weak.

SIGMA

Maturity Rating

Moderate

Assessment

·        Mature as portable event-rule template logic for endpoint process and service-context behaviors when backend conversion preserves required fields.

·        Not mature as a standalone authentication-bypass, FTP-context, tenant-blast-radius, cloud-impact, or multi-source correlation layer.

·        Requires backend-specific field validation, enrichment-field creation, exception handling, and SIEM-native correlation.

YARA

Maturity Rating

Not applicable for primary S25 detection

Assessment

·        Excluded from primary S25 because artifact-led detection does not align with the governing behavior-led model.

·        May support optional customer-specific artifact hunting outside primary rules if a stable malicious artifact or reusable malware family is recovered and validated.

AWS

Maturity Rating

Conditional

Assessment

·        Mature as a conditional downstream cloud-impact layer where hosting-risk context can be reliably joined to AWS IAM, STS, EC2, S3, Route 53, SES, snapshots, security groups, GuardDuty, Security Hub, Config, Access Analyzer, or cloud-service activity.

·        Not mature as a guest-level compromise-confirmation source.

·        Requires validated hosting-to-cloud lineage and cloud telemetry coverage.

Azure

Maturity Rating

Conditional

Assessment

·        Mature as a conditional downstream cloud-impact layer where hosting-risk context can be reliably joined to Azure Activity, Entra ID context, role assignments, service principals, managed identities, VMs, disks, snapshots, DNS, Storage, Key Vault, Defender for Cloud, Sentinel, Azure Monitor, or network exposure activity.

·        Not mature as a guest-level compromise-confirmation source.

·        Requires validated hosting-to-cloud lineage and cloud telemetry coverage.

GCP

Maturity Rating

Conditional

Assessment

·        Mature as a conditional downstream cloud-impact layer where hosting-risk context can be reliably joined to GCP IAM, service accounts, service-account keys, Compute Engine, Cloud DNS, Cloud Storage, Cloud KMS, Secret Manager, firewall rules, snapshots, images, Security Command Center, Event Threat Detection, or Cloud Logging activity.

·        Not mature as a guest-level compromise-confirmation source.

·        Requires validated hosting-to-cloud lineage and cloud telemetry coverage.

Maturity Gaps

Telemetry Completeness

·        Incomplete access logs weaken exploit-attempt and suspected unauthorized access assessment.

·        Incomplete authentication or session telemetry weakens access-flow mismatch validation.

·        Incomplete FTP logs weaken lower-privileged foothold analysis.

·        Incomplete web logs weaken web shell and hosted-path analysis.

·        Incomplete process telemetry weakens post-access execution detection.

·        Incomplete file, permission, ownership, or symlink telemetry weakens hosted-content, persistence, and shared-hosting escalation detection.

·        Incomplete CloudLinux/CageFS mapping weakens tenant-boundary analysis.

·        Incomplete DNS, mail, proxy, network, or abuse telemetry weakens outbound and abuse-infrastructure detection.

·        Incomplete cloud telemetry weakens downstream AWS, Azure, and GCP cloud-impact assessment.

·        Incomplete tenant mapping weakens blast-radius and downstream customer impact assessment.

Operational Context

·        Missing support ranges, reseller scope, maintenance windows, patch windows, plugin update windows, backup workflows, automation accounts, customer-request context, incident-response workflows, and abuse-response workflows increase false positives.

·        Weak administrator baselines reduce confidence in access anomaly detection.

·        Weak FTP, web, customer-update, CMS, and plugin maintenance baselines reduce confidence in foothold and file-impact assessment.

·        Weak destination baselines reduce confidence in outbound communication findings.

·        Weak cloud identity, resource, storage, key, secret, DNS, and network baselines reduce confidence in conditional downstream cloud-impact findings.

Historical Review

·        Short log retention limits retrospective review for systems exposed before patch validation or plugin update validation.

·        Patch status alone does not prove absence of compromise.

·        Plugin update status alone does not prove absence of compromise.

·        Historical review maturity depends on retained access, authentication/session, FTP, web, process, file, symlink, account, DNS, mail, outbound, abuse, cloud, tenant, and remediation artifacts.

Maturity Improvement Priorities

Priority 1

Improve Control-Panel Access and Authentication/Session Telemetry

·        Ensure collection from cPanel, WHM, DNSOnly where applicable, WP Squared, and related hosting-control access logs.

·        Preserve request path, source IP, user identity where available, session identifier where available, user agent, authentication result, administrative action, host identity, and timestamp.

·        Improve ability to distinguish normal authentication flow from suspected unauthorized access.

Priority 2

Improve FTP, Web, File, Symlink, and CloudLinux/CageFS Visibility

·        Preserve FTP account, source IP, authentication result, file operation, uploaded path, downloaded path, byte count, tenant account, reseller account, host identity, and timestamp.

·        Preserve web request path, method, response code, user agent, hosted domain, webroot, source IP, file path, and timestamp.

·        Preserve file creation, modification, deletion, ownership change, permission change, symlink path, symlink target, file owner, permission mode, hash where available, modifying process where available, user, host identity, and timestamp.

·        Preserve CloudLinux/CageFS tenant-boundary context where available.

·        Improve visibility into lower-privileged foothold activity, web shell activity, LiteSpeed plugin-adjacent behavior, and shared-hosting escalation.

Priority 3

Improve Endpoint Process and Service-Context Telemetry

·        Preserve parent process, child process, command line, execution user, effective user, executable path, working directory, host identity, and timestamp.

·        Improve visibility into hosting-control, web-service, FTP-service, LiteSpeed, PHP, mail-service, backup, account-management, cron, package-management, shell, interpreter, and plugin-adjacent execution.

·        Improve confidence in post-access execution and outbound retrieval behavior.

Priority 4

Improve Tenant, Reseller, and Cloud-Lineage Mapping

·        Map hosted paths to tenant accounts.

·        Map domains to accounts.

·        Map mailboxes to tenants.

·        Map databases to tenants.

·        Map DNS zones to domains and accounts.

·        Map backup paths to tenants.

·        Map FTP accounts to tenants.

·        Map reseller accounts to managed tenants.

·        Map CloudLinux/CageFS paths to tenants.

·        Map cloud identities, cloud resources, DNS zones, storage resources, key resources, secret resources, public IPs, private IPs, and incident keys to hosting-risk context.

·        Improve blast-radius assessment, downstream customer impact scoping, and conditional cloud-impact confidence.

Priority 5

Improve DNS, Mail, Proxy, Network, Abuse, and Operational Baselines

·        Preserve queried domain, resolved IP, destination IP, destination port, protocol, direction, host identity, process context where available, byte count, duration, mail flow, abuse-report context, and timestamp.

·        Baseline approved update repositories, backup destinations, monitoring destinations, support infrastructure, mail relays, CDNs, package repositories, customer workflows, cloud service endpoints, and known hosting-provider destinations.

·        Maintain approved administrator source ranges, hosting-provider support ranges, reseller ownership scope, maintenance windows, patch windows, plugin update windows, backup and migration workflows, automation account inventories, customer-support context, incident-response workflows, and abuse-response context.

·        Review suppression logic periodically to avoid hiding unauthorized activity.

Final Intelligence Maturity Determination

The Block 4 detection model is mature and operationally defensible when required telemetry, tenant mapping, and cloud-lineage context are available. Its strongest intelligence value comes from behavior-led correlation across hosting-control access, authentication/session state, FTP and web activity, endpoint execution, file and symlink changes, hosted-content impact, account activity, DNS and mail behavior, outbound communication, abuse reports, tenant mapping, cloud-resource lineage, remediation context, and asset exposure context.

The primary residual maturity constraints are telemetry completeness, FTP and web visibility, file and symlink visibility, CloudLinux/CageFS mapping, tenant mapping, operational baselines, outbound attribution, cloud-lineage validation, and historical retention. The model should be treated as high maturity with telemetry-dependent and lineage-dependent deployment constraints, not as a universal compromise-confirmation capability.

S31 — Telemetry Dependencies

Control-Plane Evidence Dependency

·        Organizations must preserve access, authentication, session, administrative action, and service logs for cPanel, WHM, DNSOnly, WP Squared, webmail, API, sessionized paths, and related hosting-control services.

·        This dependency supports separation between scan activity, exploit attempts, suspected unauthorized access, probable compromise, and confirmed compromise.

·        Required operational ownership should sit with hosting platform, security engineering, SOC, and infrastructure teams because control-plane logs are often distributed across application, proxy, server, and provider-managed sources.

·        Retention must support historical compromise review for systems exposed before patch validation.

Endpoint and Server Behavior Dependency

·        Organizations must collect endpoint and Linux server telemetry capable of preserving process ancestry, command line, execution user, effective user, executable path, host identity, and timestamp.

·        This dependency supports identification of suspicious transitions from control-plane access into shell activity, account-management utilities, service modification, scheduled tasks, archive staging, package activity, or outbound retrieval.

·        Operational ownership should include endpoint security, Linux platform operations, hosting operations, and SOC teams.

·        Environments without reliable process lineage should avoid high-confidence compromise conclusions based on endpoint behavior alone.

Hosted-Content and File Integrity Dependency

·        Organizations must preserve file activity across webroots, tenant directories, reseller-managed paths, CMS paths, plugin directories, upload paths, cache paths, mail paths, temporary paths, cron paths, SSH key paths, and configuration paths.

·        This dependency supports detection and scoping of webshell-like files, suspicious scripts, unauthorized redirects, plugin modification, hidden files, writable paths, archive staging, permission changes, and tenant-spanning file activity.

·        Operational ownership should include hosting operations, web platform owners, security engineering, SOC, and customer-support teams where hosted content is customer-managed.

·        File visibility must be paired with tenant mapping to distinguish isolated hosted-content changes from multi-tenant impact.

Tenant, Reseller, and Asset Context Dependency

·        Organizations must maintain mapping between host identity, hosted account, reseller account, customer owner, domain, webroot path, mailbox, database, DNS zone, backup location, and business criticality.

·        This dependency supports blast-radius assessment, downstream customer scoping, priority containment, and customer assurance.

·        Operational ownership should include hosting platform teams, customer operations, reseller management, asset management, security operations, and incident response leadership.

·        Environments lacking tenant mapping should document blast-radius uncertainty as a material investigation limitation.

DNS, Outbound Network, and Abuse Visibility Dependency

·        Organizations must collect DNS, proxy, firewall, flow, and outbound connection telemetry sufficient to identify suspicious destinations, newly observed domains, payload-staging infrastructure, redirector behavior, command-and-control-like communication, phishing hosting, malware delivery, spam activity, and abuse infrastructure.

·        This dependency supports escalation when outbound activity follows suspicious control-plane access, privileged execution, hosted-content modification, account change, or tenant-impact evidence.

·        Operational ownership should include network security, cloud or infrastructure operations, abuse operations, SOC, and incident response teams.

·        External abuse reports, blocklist events, phishing complaints, spam complaints, malware-hosting reports, and reputation changes should feed into security triage.

Credential and Recovery Dependency

·        Organizations must maintain visibility into access to database configuration files, environment files, API keys, control-panel secrets, mail credentials, backup archives, SSH keys, automation credentials, and hosted account secrets.

·        This dependency supports credential containment, rotation decisions, restoration confidence, and customer-impact assessment.

·        Operational ownership should include identity teams, hosting operations, backup teams, incident response, and application owners.

·        Recovery decisions should account for credential exposure, hosted-content integrity, backup trust, and whether the affected system requires rebuild or migration.

S32 — Detection Limitations

Control-Plane Visibility Limitations

·        Encrypted traffic, incomplete access logs, short retention, reverse proxies, CDNs, NAT, load balancers, and inconsistent log normalization can obscure source identity, request path, session context, and host identity.

·        Missing control-plane access logs reduce confidence in exploit-attempt and unauthorized-access assessment.

·        Missing authentication or session telemetry reduces confidence in determining whether administrative access followed a normal login path.

·        These limitations can force analysts to rely more heavily on endpoint, file-system, account-change, outbound network, and tenant-impact evidence.

Authentication-Bypass Confirmation Limitations

·        Detection cannot always prove the exact authentication-bypass mechanism from enterprise telemetry alone.

·        Unauthorized administrative context may be inferred from access-flow mismatch, abnormal session behavior, suspicious source infrastructure, and post-access behavior.

·        Confirmation requires correlation across access logs, authentication or session telemetry, administrative action logs, endpoint process telemetry, file activity, account changes, outbound communication, and tenant impact.

·        Scan-only or malformed request activity must not be classified as confirmed compromise without stronger supporting evidence.

Endpoint and Process Visibility Limitations

·        Some hosting environments may lack complete command-line capture, parent-child process lineage, effective-user context, process-to-network attribution, file hash history, or EDR coverage.

·        Missing process lineage weakens detection of control-plane activity transitioning into shell execution, account-management activity, service modification, scheduled tasks, archive staging, or outbound retrieval.

·        Legitimate hosting operations can involve package activity, backups, migrations, service restarts, monitoring, support actions, customer updates, and reseller administration.

·        Endpoint findings must be evaluated with host role, process ancestry, command line, user context, maintenance windows, and operational baselines.

Hosted-Content and Tenant Attribution Limitations

·        File changes in webroots, CMS directories, plugin paths, upload directories, cache paths, mail paths, temporary paths, and customer directories may occur frequently during legitimate customer and provider operations.

·        Missing tenant mapping reduces confidence in determining whether suspicious activity affects one account, multiple customers, reseller-managed sites, mailboxes, databases, DNS zones, or webroots.

·        Without tenant mapping, organizations may underestimate blast radius or overstate impact.

·        Tenant-impact conclusions require mapping between file paths, hosted accounts, reseller accounts, domains, mailboxes, databases, DNS zones, server identities, and customer ownership.

Outbound Communication Limitations

·        DNS, proxy, firewall, and flow logs may not always identify the initiating process, local service context, tenant, or originating application.

·        Hosting servers legitimately communicate with update repositories, backup destinations, monitoring services, mail infrastructure, DNS resolvers, customer content destinations, and provider support services.

·        Outbound communication should not be treated as command-and-control or exfiltration without supporting context.

·        Confidence improves when outbound activity follows suspicious control-plane access, privileged execution, hosted-content modification, account change, archive staging, or abuse-report evidence.

Operational Context Limitations

·        Provider support, reseller administration, patching, backups, migrations, certificate renewal, CMS updates, customer support, and deployment automation can resemble post-compromise behavior.

·        Environments without documented administrator source networks, support ranges, reseller scope, maintenance windows, backup workflows, automation accounts, and approved outbound destinations will experience higher false-positive risk.

·        Suppression must be based on validated operational context, not broad assumptions.

·        Operational context gaps should be documented as investigation constraints and should not be used to lower evidence requirements.

Historical Review Limitations

·        Patch validation does not prove that exposed systems were uncompromised before remediation.

·        Short log retention can prevent reliable review of pre-patch activity.

·        Missing historical access logs, session telemetry, endpoint process history, file modification history, DNS queries, outbound network activity, and abuse reports can leave residual uncertainty.

·        Where historical review is incomplete, organizations should document residual risk, preserve available artifacts, and prioritize tenant-impact validation.

S33 — Defensive Control & Hardening Improvements

Patch and Exposure Control

·        Validate that all affected cPanel & WHM, DNSOnly, WP Squared, and related hosting-control systems are updated to supported patched versions.

·        Confirm patch state through authoritative system inventory, not only change tickets or administrative assumptions.

·        Restrict cPanel, WHM, DNSOnly, WP Squared, webmail, API, and related administrative interfaces to approved management paths.

·        Remove unnecessary public exposure of hosting-control services.

·        Review firewall rules, security groups, reverse proxy rules, load balancer exposure, public DNS records, and external reachability.

Administrative Access Hardening

·        Enforce MFA where available, least privilege, dedicated administrator accounts, and separation between provider, reseller, automation, emergency, and customer-support access.

·        Review dormant, rarely used, newly created, recently modified, or high-privilege accounts.

·        Validate reseller scope and remove privileges that exceed operational need.

·        Invalidate suspicious sessions and rotate credentials, API tokens, SSH keys, database passwords, mail credentials, and automation secrets where unauthorized access or credential exposure is suspected.

Server-Side Hardening

·        Restrict shell access, package-management access, service-control access, account-management utilities, and scheduled-task modification to approved workflows.

·        Harden cron paths, service files, startup scripts, SSH key locations, temporary directories, writable web paths, and web-accessible upload locations.

·        Reduce unnecessary write permissions in webroots, upload paths, cache directories, plugin directories, and shared hosting paths.

·        Validate hosting-control, web-service, mail-service, backup, and account-management process permissions against least-privilege expectations.

Hosted-Content Integrity Controls

·        Enable file integrity monitoring or equivalent hosted-content monitoring for webroots, CMS paths, plugin directories, upload directories, temporary paths, mail paths, DNS configuration paths, cron paths, and SSH key paths.

·        Prioritize review of new scripts, hidden files, unexpected writable paths, unauthorized redirects, suspicious include files, modified plugins, and repeated changes across tenants.

·        Baseline approved customer updates, CMS updates, deployment automation, certificate renewal, backup activity, provider support, and migration workflows.

·        Validate hosted-content integrity for customer sites affected by suspicious control-plane access or post-access behavior.

Tenant and Reseller Blast-Radius Controls

·        Maintain tenant-to-path, domain-to-account, mailbox-to-account, database-to-account, DNS-zone-to-account, reseller-to-customer, and host-to-customer mapping.

·        Use tenant mapping to scope suspicious file changes, account actions, DNS changes, mail changes, database access, and outbound abuse.

·        Prioritize containment and customer assurance where activity affects multiple tenants or reseller-managed sites.

·        Document scoping limitations when tenant mapping is incomplete.

Outbound Abuse and Recovery Controls

·        Baseline expected outbound destinations for updates, backups, monitoring, support, mail delivery, DNS resolution, customer workflows, and provider operations.

·        Monitor for newly observed domains, suspicious VPS infrastructure, unusual geographies, payload-staging destinations, redirector behavior, spam activity, malware hosting, phishing hosting, and blocklist events.

·        Preserve forensic artifacts before rebuild, migration, or restoration when operationally feasible.

·        Validate backups before restoration to avoid reintroducing webshells, malicious scripts, compromised plugins, altered permissions, or unauthorized redirects.

S34 — Defensive Control & Hardening Architecture

Figure 6

Architecture Overview

The defensive architecture for [EXP] Hosting Control-Plane Compromise Risk from cPanel KEV Exploitation must reduce exposed administrative attack surface, preserve control-plane evidence, detect post-access abuse, protect hosted content, and support tenant-level impact scoping. The architecture should assume that patching is necessary but insufficient for systems exposed before remediation. Historical compromise review, telemetry preservation, access restriction, credential containment, tenant mapping, and clean recovery capability are required to reduce residual risk.

Layer 1 — Exposure Control

·        Maintain authoritative inventory of cPanel, WHM, DNSOnly, WP Squared, and related hosting-control systems.

·        Identify internet-facing administrative services, public IPs, exposed ports, load balancers, reverse proxies, firewall rules, security groups, and DNS records.

·        Restrict administrative access to approved management paths.

·        Flag systems exposed before patch validation for historical compromise review.

Layer 2 — Identity and Administrative Governance

·        Enforce MFA where available, strong administrator authentication, least privilege, account separation, and reseller-scope governance.

·        Maintain approved administrator source networks, provider support ranges, reseller access ranges, automation accounts, and emergency access procedures.

·        Review dormant, modified, newly created, high-privilege, and out-of-scope administrative accounts.

·        Rotate credentials and tokens when suspicious access, account changes, hosted-content tampering, or credential access is suspected.

Layer 3 — Control-Plane Evidence Preservation

·        Preserve access logs, authentication logs, session telemetry, administrative action logs, and service logs.

·        Normalize source IP, user identity, session identifier, request path, host identity, administrative action, tenant context, and timestamp.

·        Retain telemetry long enough to support pre-patch historical review.

·        Protect logs from deletion or modification by compromised administrative context.

Layer 4 — Server Behavior and Hosted-Content Protection

·        Collect process lineage, command line, effective user, execution path, parent process, host identity, and timestamp from hosting-control servers.

·        Monitor hosting-control, web-service, mail-service, backup, account-management, package-management, cron, shell, and interpreter contexts.

·        Monitor webroots, hosted directories, CMS paths, plugin directories, upload locations, cache directories, temporary paths, mail paths, database configuration paths, cron paths, and SSH key paths.

·        Prioritize review of webshells, suspicious scripts, unauthorized redirects, phishing pages, credential-harvesting content, hidden files, writable paths, archive staging, and repeated tenant-spanning changes.

Layer 5 — Tenant, Network, and Abuse Correlation

·        Map file paths, domains, mailboxes, databases, DNS zones, reseller accounts, hosted accounts, and hosts to tenant identity.

·        Monitor DNS queries, outbound connections, destination domains, destination IPs, ports, protocols, traffic direction, process context where available, host identity, tenant context where available, and timestamp.

·        Baseline approved outbound destinations, update repositories, backup endpoints, monitoring destinations, support infrastructure, and mail flows.

·        Correlate abuse reports, reputation changes, blocklist events, phishing complaints, spam complaints, and malware-hosting reports with access anomalies, endpoint execution, hosted-content modification, account changes, and tenant-impact evidence.

Layer 6 — Recovery and Assurance

·        Preserve forensic evidence before rebuild or migration when operationally feasible.

·        Rebuild or migrate confirmed root-compromised systems to known-clean infrastructure.

·        Restore accounts only from validated backups and inspect restored content for webshells, suspicious scripts, redirects, altered permissions, and compromised plugins.

·        Confirm patch state, credential rotation, tenant-impact review, endpoint telemetry, outbound communication review, and customer assurance before returning systems to normal operation.

S35 — Defensive Control Mapping Matrix

Exposure Management

·        Maps to patch validation, public exposure inventory, administrative service restriction, firewall review, security group review, reverse proxy review, load balancer review, and external reachability validation.

·        Reduces attacker ability to reach vulnerable hosting-control services.

·        Supports prioritization of systems exposed before patch validation.

Identity and Access Management

·        Maps to MFA, least privilege, administrator account review, reseller-scope validation, emergency access governance, API token review, SSH key review, and credential rotation.

·        Reduces unauthorized administrative persistence and limits post-access account abuse.

·        Supports containment when authentication/session anomalies or account changes are observed.

Control-Plane Logging

·        Maps to access logs, authentication logs, session telemetry, administrative action logs, service logs, identity normalization, session normalization, host normalization, and timestamp normalization.

·        Supports separation of exploit attempt, suspected unauthorized access, probable compromise, and confirmed compromise.

·        Enables historical compromise review for systems exposed before remediation.

Endpoint and Server Monitoring

·        Maps to process ancestry, command-line capture, effective-user context, executable path, working directory, host identity, agent health, and server role context.

·        Supports identification of privileged execution, shell activity, service modification, scheduled-task creation, archive staging, and outbound retrieval.

·        Enables correlation between suspicious control-plane access and post-access host behavior.

Hosted-Content Integrity

·        Maps to webroot monitoring, CMS path monitoring, plugin directory monitoring, upload directory monitoring, temporary path monitoring, cron path monitoring, SSH key monitoring, permission change monitoring, ownership change monitoring, and file hash tracking where available.

·        Supports detection of webshell placement, suspicious scripts, unauthorized redirects, hidden files, writable paths, plugin backdoors, archive staging, and tenant-spanning modifications.

·        Enables hosted-content integrity review and customer-impact scoping.

Tenant and Reseller Context

·        Maps to tenant-to-path mapping, domain-to-account mapping, mailbox-to-account mapping, database-to-account mapping, DNS-zone-to-account mapping, reseller-to-customer mapping, and host-to-customer mapping.

·        Supports blast-radius assessment and customer-specific containment.

·        Reduces uncertainty when suspicious activity affects multiple accounts, domains, mailboxes, databases, or webroots.

Network, DNS, and Abuse Monitoring

·        Maps to DNS logs, proxy logs, firewall logs, flow logs, destination tracking, process-to-network attribution where available, abuse complaints, blocklist events, spam reports, phishing reports, and malware-hosting reports.

·        Supports identification of payload staging, command-and-control-like communication, redirector use, phishing hosting, malware distribution, spam activity, and abuse infrastructure.

·        Enables escalation when outbound activity follows access anomalies, hosted-content modification, account changes, or tenant-impact evidence.

Recovery and Governance

·        Maps to validated backups, clean rebuilds, operating system reinstall, controlled account restoration, credential rotation, forensic preservation, customer assurance, legal review, regulatory assessment, cyber insurance coordination, and board-level governance.

·        Reduces risk of restoring compromised hosted content or persistence artifacts.

·        Supports coordinated response when hosting-control compromise affects customers, tenants, hosted content, mail, DNS, or abuse infrastructure.

S36 — CyberDax Intelligence Maturity Assessment

Current Maturity Assessment

CyberDax assesses the intelligence maturity requirement for this threat as high because effective defense depends on correlating exposed hosting-control assets, authentication/session behavior, administrative actions, endpoint process telemetry, hosted-content changes, DNS and outbound communication, abuse reports, and tenant mapping. Organizations with strong telemetry and tenant context can separate scan-only exposure from suspected unauthorized access, probable compromise, and confirmed compromise. Organizations without that context may be forced into broader containment and lower-confidence customer-impact scoping.

Maturity Level 1 — Exposure-Aware but Telemetry-Limited

·        The organization can identify some exposed cPanel, WHM, DNSOnly, WP Squared, or related hosting-control systems.

·        Patch status may be tracked manually or inconsistently.

·        Access logs, authentication/session telemetry, endpoint process telemetry, file telemetry, outbound network telemetry, and tenant mapping are incomplete.

·        Detection is limited to exposure awareness, scan monitoring, manual review, and reactive response.

·        Compromise scoping is low confidence and may require broad containment assumptions.

Maturity Level 2 — Patch-Validated and Log-Aware

·        The organization maintains hosting-control asset inventory and validates patch status.

·        Access logs, authentication logs, and limited administrative action logs are available for key systems.

·        Endpoint process telemetry and file telemetry may exist but are not consistently correlated with control-plane activity.

·        Tenant mapping is partial or manually reconstructed.

·        The organization can identify suspicious access patterns but may struggle to confirm post-access behavior or tenant impact.

Maturity Level 3 — Behavior-Correlated and Tenant-Aware

·        The organization correlates control-plane access, authentication/session events, endpoint process activity, account changes, file modifications, DNS queries, outbound communication, and administrative actions.

·        Tenant-to-path, domain-to-account, mailbox-to-account, database-to-account, and reseller-to-customer mapping is available for most hosted environments.

·        Detection can distinguish exploit attempt, suspected unauthorized access, probable compromise, and confirmed compromise.

·        Historical compromise review is feasible for systems exposed before patch validation.

·        Customer-impact scoping is higher confidence but may still depend on analyst validation.

Maturity Level 4 — Integrated Control-Plane Defense and Response

·        The organization maintains complete hosting-control inventory, validated exposure controls, enforced administrative access restrictions, high-fidelity telemetry, and automated enrichment for tenant, reseller, customer, and asset context.

·        Security teams can correlate access anomalies with endpoint execution, hosted-content modification, account changes, outbound communication, abuse reports, and tenant impact.

·        Response workflows support rapid isolation, credential rotation, tenant-specific review, customer assurance, clean rebuild, and validated restoration.

·        Historical review, evidence preservation, and post-remediation assurance are part of standard operating procedure.

·        Detection and response are resilient to changes in exploit formatting, attacker infrastructure, user agents, payloads, and post-access timing.

Maturity Gaps to Prioritize

·        Incomplete inventory of exposed hosting-control systems.

·        Inconsistent patch-state validation.

·        Short retention for access logs, authentication logs, session telemetry, endpoint telemetry, file telemetry, DNS logs, and outbound network data.

·        Weak process lineage and command-line capture on hosting-control servers.

·        Incomplete tenant, reseller, domain, mailbox, database, and DNS-zone mapping.

·        Limited ability to distinguish support activity, reseller administration, customer updates, backups, migrations, and patching from attacker-driven administrative abuse.

·        Limited integration of abuse reports, blocklist events, phishing complaints, spam reports, and malware-hosting complaints into security triage.

·        Insufficient clean rebuild, validated restoration, and customer assurance playbooks for hosting-control compromise.

S37 — Strategic Defensive Improvements

Establish Hosting-Control Governance

·        Create a formal governance process for cPanel, WHM, DNSOnly, WP Squared, and related hosting-control systems.

·        Track owner, business role, customer density, reseller scope, exposure state, patch state, hosted account count, and telemetry coverage.

·        Require recurring executive visibility into public exposure, patch status, and historical compromise review for high-risk hosting-control assets.

·        Treat unknown or unmanaged hosting-control systems as priority exposure-management findings.

Institutionalize Administrative Surface Reduction

·        Define administrative access standards for hosting-control services across on-premises, cloud-hosted, MSP-operated, and reseller-managed environments.

·        Require management-path restrictions, approved source access, least privilege, MFA where available, and emergency access governance.

·        Establish exception review and expiration for temporary public exposure or support access.

·        Measure administrative exposure reduction as a recurring security program outcome.

Build Tenant-Aware Incident Response

·        Make tenant, reseller, domain, mailbox, database, DNS-zone, backup, and hosted-path mapping a required response capability.

·        Establish response thresholds for tenant-spanning activity, reseller-scope abuse, hosted-content tampering, mail abuse, DNS manipulation, and customer-impact uncertainty.

·        Prepare customer assurance workflows for shared-hosting, reseller-hosting, MSP-operated, and high-volume hosting environments.

·        Document residual risk when tenant mapping is incomplete or historical telemetry cannot support confident scoping.

Improve Hosting-Control Telemetry Readiness

·        Set minimum telemetry standards for hosting-control access logs, authentication/session telemetry, administrative action logs, endpoint process telemetry, file telemetry, DNS logs, outbound network telemetry, abuse reports, and tenant context.

·        Require retention sufficient to support historical compromise review after emergency patching.

·        Validate endpoint agent health, logging continuity, and evidence preservation during active exploitation windows.

·        Integrate external abuse intelligence into SOC triage and incident response workflows.

Strengthen Clean Recovery and Assurance

·        Establish known-clean rebuild, migration, credential rotation, backup validation, and hosted-content integrity review procedures for confirmed or strongly suspected hosting-control compromise.

·        Ensure recovery procedures prevent reintroduction of webshells, malicious scripts, compromised plugins, altered permissions, unauthorized redirects, or exposed credentials.

·        Require restoration gates for patch state, access restriction, credential rotation, tenant-impact review, outbound communication review, and customer assurance.

·        Preserve forensic evidence before rebuild or migration where operationally feasible.

Elevate Control-Plane Compromise to Executive Risk Governance

·        Treat hosting-control compromise as a customer-trust and business-continuity risk, not only a server security issue.

·        Define executive escalation criteria for multi-tenant impact, abuse infrastructure, regulated data exposure, incomplete scoping, customer notification analysis, cyber insurance reporting, and board-level incident governance.

·        Ensure leadership understands that patch completion does not eliminate historical compromise risk.

·        Track residual exposure, telemetry gaps, and remediation progress through the risk register until closure is evidence-based.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Economic Model Overview

[EXP] Hosting Control-Plane Compromise Risk from cPanel KEV Exploitation creates economic exposure because attackers can convert unauthorized access to exposed hosting-control systems into broader operational, customer, abuse-infrastructure, and trust-impacting consequences. The direct cost driver is not only the vulnerable software condition, but the administrative reach of cPanel, WHM, DNSOnly, WP Squared, and related hosting-control systems into hosted websites, reseller accounts, mail services, DNS zones, databases, backups, customer webroots, credentials, and server-side configuration.

The attack economics favor adversaries because exposed hosting-control systems provide high-value administrative leverage from a single internet-facing access path. When successful, attackers may gain the ability to alter hosted content, deploy webshells, modify accounts, manipulate DNS or mail settings, stage payloads, host phishing or malware content, create redirects, access credentials, or affect multiple tenants from one compromised control-plane environment. This creates asymmetric impact because the defender must validate patch state, preserve historical telemetry, scope tenant impact, review customer content, rotate credentials, respond to abuse reports, and restore trust across potentially many hosted accounts.

Adversary Cost Advantage

·        Attackers can target exposed hosting-control services at internet scale.

·        Exploitation requires no prior internal enterprise foothold when vulnerable administrative services are publicly reachable.

·        A single successful compromise can provide administrative access to multiple hosted sites, customer accounts, reseller-managed environments, mailboxes, databases, DNS zones, and hosted-content paths.

·        Attackers can use legitimate hosting-control functionality to blend with normal administration, increasing defender investigation cost.

·        Attackers can shift infrastructure value from one compromised server into phishing hosting, malware delivery, spam, redirector infrastructure, credential harvesting, payload staging, or broader abuse operations.

Defender Cost Burden

·        Defenders must validate emergency patch status across all exposed hosting-control assets.

·        Defenders must separate scan-only activity from unauthorized access, probable compromise, and confirmed compromise.

·        Defenders must preserve and review access logs, authentication/session telemetry, administrative action logs, endpoint process telemetry, file telemetry, outbound network telemetry, abuse reports, and tenant mappings.

·        Defenders must determine whether suspicious activity affected one account, multiple tenants, reseller-managed accounts, customer webroots, DNS zones, mailboxes, databases, backups, or credentials.

·        Defenders may need to coordinate containment, credential rotation, clean rebuilds, customer assurance, legal review, regulatory assessment, cyber insurance reporting, and board-level governance.

Low Impact Economic Outcome

Low impact occurs when exposed systems are rapidly patched, access and session telemetry is preserved, no unauthorized administrative access is observed, no privileged execution follows control-plane activity, no hosted-content tampering is identified, no tenant-spanning impact is detected, and no outbound abuse or external abuse reports are associated with the affected systems. Even in this scenario, cost remains material because emergency patch validation, exposure review, historical compromise assessment, customer-impact validation, and executive tracking are still required.

Estimated Organizational Impact

·        Estimated impact remains consistent with the Block 1 low scenario of $2M to $8M.

·        Cost concentration is driven by accelerated patch validation, access-log review, targeted hunting, administrative account review, and limited customer assurance.

·        Business disruption is limited when telemetry confirms no unauthorized administrative access or post-access behavior.

Moderate Impact Economic Outcome

Moderate impact occurs when suspicious administrative access, authentication-flow mismatch, hosted-content changes, suspicious outbound communication, limited account modification, or abuse-report correlation is identified on one or more exposed hosting-control systems, but the investigation does not confirm broad customer data exposure, persistent abuse infrastructure, or widespread multi-tenant compromise. This is the most likely economic scenario for organizations with exposed hosting-control assets during the active exploitation window because even limited suspicion can require significant scoping, tenant review, and assurance work.

Estimated Organizational Impact

·        Estimated impact remains consistent with the Block 1 moderate scenario of $15M to $60M.

·        Cost concentration is driven by server containment, forensic review, access and session reconstruction, endpoint and file-system analysis, tenant mapping, credential rotation, DNS and mail review, abuse-report handling, legal assessment, SOC surge support, and customer communications planning.

·        Business disruption increases when affected infrastructure supports customer-facing websites, reseller-hosting operations, ecommerce, mail services, or high-volume hosted environments.

High Impact Economic Outcome

High impact occurs when confirmed or strongly suspected control-plane compromise affects shared-hosting, reseller-hosting, MSP-operated, customer-facing, or high-volume web infrastructure with evidence of multi-tenant hosted-content tampering, webshell placement, credential exposure, DNS or mail manipulation, phishing or malware hosting, spam activity, database access, backup exposure, outbound staging, or incomplete historical telemetry. This scenario creates the highest organizational exposure because containment and assurance must extend beyond the vulnerable server into customer, tenant, reseller, domain, mail, database, and abuse-infrastructure scoping.

Estimated Organizational Impact

·        Estimated impact remains consistent with the Block 1 high scenario of $75M to $300M or higher.

·        Cost concentration is driven by broad server isolation, tenant-by-tenant validation, customer notification analysis, customer assurance, abuse-infrastructure takedown, DNS and mail remediation, credential rotation at scale, forensic preservation, rebuild or migration activity, legal and regulatory review, insurance engagement, revenue-impact management, and board-level incident governance.

·        Business disruption becomes severe when affected hosting-control systems support many customers, high-revenue sites, regulated content, authentication portals, ecommerce workflows, or reseller-managed environments.

Economic Amplification Factors

·        Number of exposed hosting-control assets.

·        Number of hosted accounts, customer domains, reseller accounts, mailboxes, databases, DNS zones, and webroots administered by affected systems.

·        Whether unauthorized administrative access occurred before patch validation.

·        Whether suspicious access was followed by privileged execution, account manipulation, hosted-content modification, outbound communication, or tenant-spanning behavior.

·        Whether telemetry can support historical compromise review.

·        Whether tenant mapping can support confident customer-impact scoping.

·        Whether affected infrastructure was used for phishing, malware delivery, spam, redirector infrastructure, credential harvesting, or other abuse operations.

·        Whether customer assurance, legal review, regulatory analysis, insurance reporting, or board-level governance is required.

·        Whether clean rebuild, migration, backup validation, credential rotation, or restoration gates are needed before returning systems to normal operation.

Organizational Impact Model

The organizational impact model should treat this threat as a control-plane trust problem. When hosting-control trust is weakened, the organization must validate not only software patch status, but also administrative access integrity, hosted-content integrity, credential exposure, tenant impact, outbound abuse, recovery trust, and customer assurance. The cost curve rises sharply when telemetry gaps prevent confident scoping, because uncertainty forces broader containment and more conservative customer-impact assumptions.

S39 — Economic Impact & Organizational Exposure

Organizational Exposure Overview

Hosting control-plane compromise and shared-hosting privilege escalation create organizational exposure by increasing uncertainty around administrative trust, customer-facing web integrity, tenant isolation, reseller scope, DNS authority, mail integrity, database access, backup integrity, credential exposure, cloud-resource lineage, abuse infrastructure, customer impact, and post-remediation confidence.

Exposure rises when suspicious activity affects cPanel, WHM, DNSOnly, WP Squared, LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, shared-hosting infrastructure, CloudLinux/CageFS isolation boundaries, reseller-managed accounts, hosted domains, webroots, FTP accounts, web shell-accessible paths, mailboxes, databases, DNS zones, backups, customer-facing content, abuse-report workflows, or cloud-connected hosting resources.

The business risk is not limited to a single CVE, exploit request, vulnerable version, scanner hit, source IP, user agent, web shell filename, symlink path, plugin inventory record, or actor label. The strategic exposure is that a trusted hosting administration surface or lower-privileged shared-hosting foothold can become a control path for customer websites, hosted applications, mail systems, databases, DNS records, backups, tenant boundaries, abuse infrastructure, and downstream cloud resources.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible estimate is tied to whether activity remains attempted or low-scope hosting-control probing, becomes confirmed or strongly suspected unauthorized access to a hosting-control or shared-hosting environment, or expands into customer-facing content compromise, multi-tenant impact, credential exposure, DNS or mail manipulation, abuse infrastructure, cloud-resource activity, legal review, customer assurance, regulatory assessment, cyber-insurance scrutiny, executive reporting, or board-level hosting trust restoration.

Low Impact Scenario

Estimated $350K - $2.5M.

This scenario applies when rapid investigation confirms exposed cPanel, WHM, DNSOnly, WP Squared, LiteSpeed plugin, shared-hosting, or CloudLinux/CageFS risk without evidence of unauthorized administrative action, endpoint execution, hosted-content modification, tenant-boundary failure, DNS manipulation, mail abuse, database access, backup access, credential exposure, outbound abuse, customer-impact evidence, or downstream cloud-resource activity.

Activity may involve scanner traffic, malformed request attempts, vulnerable-version discovery, blocked access attempts, exposure-management findings, exploit-attempt telemetry, plugin-inventory findings, isolated FTP activity, or isolated web access that does not lead to confirmed file, symlink, permission, root-context, tenant, outbound, abuse, or cloud-impact evidence. Response remains limited to patch validation, plugin update validation, targeted access-log review, administrative-session review, FTP and web log spot-checking, short-window endpoint and file review, customer-assurance messaging where needed, abuse-desk monitoring, and short-term recurrence monitoring.

Moderate Impact Scenario

Estimated $3M - $18M.

This scenario applies when confirmed or strongly suspected unauthorized access affects one or more hosting-control systems, shared-hosting servers, reseller scopes, customer webroots, FTP accounts, mailboxes, databases, DNS zones, backup paths, LiteSpeed plugin-adjacent shared-hosting environments, or CloudLinux/CageFS tenant-boundary assumptions. The organization cannot immediately determine whether suspicious access led to service-context execution, web shell activity, symlink abuse, permission changes, root-context behavior, hosted-content tampering, account modification, DNS manipulation, mail abuse, database access, backup access, outbound staging, abuse infrastructure, cloud-resource use, or tenant-spanning activity.

Response may require extended hosting-control log reconstruction, authentication and session review, FTP and web log review, endpoint process review, file and symlink review, CloudLinux/CageFS boundary review, tenant and reseller scoping, hosted-content integrity validation, DNS and mail review, database and backup review, abuse-report review, customer-impact assessment, credential and token rotation, cloud-resource correlation, legal and compliance consultation, cyber-insurance coordination, executive reporting, and enhanced monitoring for post-remediation recurrence.

High Impact Scenario

Estimated $20M - $95M+.

This scenario applies when hosting-control-plane or shared-hosting compromise becomes an enterprise-impact event involving confirmed or strongly suspected administrative control, root-context execution, tenant-spanning hosted-content modification, credential exposure, unauthorized DNS or mail changes, database exposure, backup compromise, web shell persistence, phishing or malware hosting, spam abuse, customer-facing defacement, CloudLinux/CageFS boundary failure, reseller-level impact, broad customer notification analysis, downstream AWS, Azure, or GCP activity, or uncertainty over whether customer-facing hosting trust can be restored without broad validation.

The organization may need to assume that hosted content, customer data, mailboxes, DNS authority, database content, backup integrity, secrets, keys, or connected cloud resources were exposed or manipulated until evidence proves otherwise. Response may require emergency containment, hosting-control lockdown, customer-impact scoping, tenant isolation review, broad credential and secret rotation, database and backup integrity validation, DNS and mail restoration, malicious content removal, abuse-infrastructure cleanup, external communications, customer or regulatory notification analysis, legal escalation, cyber-insurance engagement, executive and board reporting, and formal validation that hosting-control, tenant-boundary, customer-content, and cloud-resource trust paths can safely resume.

Annualized Risk Exposure

Estimated $3M - $22M+ for materially exposed hosting providers, enterprises, SaaS-supporting hosting environments, managed hosting environments, reseller-hosting environments, or organizations with broad dependency on cPanel, WHM, DNSOnly, WP Squared, LiteSpeed plugin-managed hosting, shared-hosting infrastructure, CloudLinux/CageFS isolation, customer-facing web applications, DNS authority, mail hosting, database hosting, backup workflows, or cloud-connected hosting resources.

Exposure may exceed $20M - $95M+ where hosting-control or shared-hosting compromise results in confirmed or suspected multi-tenant impact, customer-facing content compromise, regulated data exposure, DNS manipulation, mail abuse, credential exposure, backup compromise, cloud-resource impact, public abuse reporting, legal escalation, cyber-insurance review, customer notification assessment, communications response, executive reporting, or board-level trust restoration.

Operational Dependency

Operational dependency is high where cPanel, WHM, DNSOnly, WP Squared, LiteSpeed plugin workflows, shared-hosting servers, reseller accounts, FTP access, webroots, mailboxes, databases, DNS zones, backups, CloudLinux/CageFS tenant boundaries, customer support workflows, abuse-desk workflows, and cloud-connected resources support revenue-generating websites, customer portals, ecommerce services, business applications, email communication, DNS authority, customer data access, incident response, backup restoration, and service availability.

Dependency increases when affected hosting systems support customer-facing production websites, regulated workloads, executive communications, customer records, reseller operations, DNS authority, mail delivery, cloud storage, cloud DNS, key management, secrets, or downstream business workflows during containment and recovery.

Control Trust

Control trust is reduced when the organization cannot prove that hosting-control access logs, authentication and session records, FTP logs, web access logs, endpoint process telemetry, file and symlink telemetry, CloudLinux/CageFS tenant mappings, administrative action logs, DNS logs, mail logs, database logs, backup records, abuse-desk records, cloud audit logs, remediation evidence, and customer-impact evidence remained reliable during the exposure or compromise window.

Control trust is further reduced when downstream AWS, Azure, or GCP activity cannot be tied to legitimate hosting workflows, approved customer activity, approved administrator activity, approved reseller activity, or validated hosting-to-cloud lineage.

Visibility Confidence

Visibility confidence is highest when hosting-control access logs, authentication logs, session logs, FTP logs, web access logs, endpoint process telemetry, file telemetry, symlink telemetry, permission and ownership telemetry, DNS logs, mail logs, proxy logs, firewall logs, WAF/CDN logs, abuse reports, tenant inventory, reseller inventory, domain inventory, mailbox inventory, database inventory, backup inventory, CloudLinux/CageFS context, cloud audit telemetry, asset inventory, change-control records, remediation records, and incident-response records can be joined reliably.

Visibility confidence is reduced where access logs are missing, session context is incomplete, FTP or web logs are not retained, endpoint telemetry is absent from hosting servers, file and symlink telemetry is incomplete, tenant mapping is unavailable, reseller scope is unclear, abuse-desk records are disconnected, cloud telemetry is incomplete, or timestamp normalization is inconsistent.

Change-Control Confidence

Change-control confidence is high when patch validation, plugin update validation, LiteSpeed plugin updates, cPanel and WHM updates, DNSOnly updates, WP Squared updates, CloudLinux/CageFS configuration, WAF/CDN changes, firewall changes, reseller changes, customer maintenance, FTP changes, DNS changes, mail changes, database changes, backup activity, cloud-resource changes, support workflows, incident-response actions, and abuse-response actions are documented and attributable.

Confidence is reduced when change-control records are incomplete, delayed, inconsistent, unavailable, or disconnected from hosting-control, endpoint, file, tenant, DNS, mail, database, backup, abuse, cloud, remediation, and customer-support telemetry.

Downstream Dependency

Downstream dependency is high when affected hosting environments connect to AWS, Azure, GCP, SaaS platforms, CDN providers, DNS providers, mail providers, payment systems, customer portals, support platforms, developer environments, backup systems, monitoring services, secrets stores, key-management systems, storage services, or privileged administration workflows.

These dependencies increase the impact of even limited hosting-control or shared-hosting compromise when hosted content, DNS authority, mail integrity, database access, storage access, secrets, keys, cloud identities, service principals, service accounts, or automation credentials cannot be validated quickly.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious hosting-control or shared-hosting activity may affect customer websites, hosted applications, account data, mailbox data, database content, DNS records, backups, credentials, payment workflows, regulated files, legal records, support records, abuse reports, or customer-facing content.

Exposure also increases when incomplete telemetry prevents timely confirmation of whether webroot modification, web shell placement, symlink abuse, mail manipulation, DNS manipulation, database access, backup access, credential exposure, cloud-resource activity, phishing hosting, malware hosting, spam abuse, or customer data access was legitimate, malicious, or caused by approved operational activity.

Residual Economic Risk

Residual economic risk remains after containment if the organization cannot prove that affected hosting-control systems were patched, LiteSpeed plugins were updated, unauthorized sessions were terminated, unauthorized accounts were removed, FTP access was reviewed, API tokens were revoked, SSH keys were validated, web shells were removed, hosted content was restored, DNS changes were reviewed, mail changes were reviewed, database access was scoped, backup integrity was validated, CloudLinux/CageFS tenant boundaries were reviewed, cloud credentials were rotated where needed, cloud-resource activity was scoped, customer impact was assessed, and hosting trust was restored.

Residual risk is highest where hosting-control telemetry, FTP logs, web logs, endpoint process telemetry, file and symlink telemetry, tenant mapping, reseller mapping, DNS logs, mail logs, database logs, backup records, cloud audit logs, abuse reports, remediation evidence, or incident-response records are incomplete.

Behavioral Coverage Assessment

This report’s behavioral detection model directly covers hosting-control-plane compromise activity that aligns with exposed cPanel, WHM, DNSOnly, WP Squared, authentication bypass, unauthorized administrative access, authentication/session mismatch, service-context execution, hosted-content modification, account change, DNS manipulation, mail manipulation, suspicious outbound communication, abuse infrastructure, tenant-impact evidence, and post-remediation recurrence.

This report’s amended behavioral detection model also directly covers shared-hosting escalation activity involving LiteSpeed cPanel Plugin, LiteSpeed WHM Plugin, FTP or web shell foothold, symlink-sensitive behavior, permission anomalies, CloudLinux/CageFS tenant-boundary context, root-context behavior, tenant-spanning file or permission impact, hosted-content tampering, and post-remediation recurrence.

The report is behavior-led and should not be interpreted as limited to one exploit request, CVE string, scanner name, source IP, user agent, web shell filename, symlink path, plugin version, actor name, public proof-of-concept, hosting provider, or static IOC.

CVE / KEV Coverage Assessment

CVE-2026-54420

Direct coverage. Latest source date: 16 June 2026.

CVE-2026-54420 affects LiteSpeed cPanel Plugin and LiteSpeed WHM Plugin environments where symlink handling can be abused by a user with FTP or web shell access on a shared-hosting server running CloudLinux/CageFS. This report directly covers the amended shared-hosting escalation lane for this vulnerability, including FTP or web shell foothold evidence, LiteSpeed plugin-adjacent activity, symlink-sensitive behavior, permission anomalies, root-context behavior, CloudLinux/CageFS boundary evidence, tenant-spanning file impact, hosted-content tampering, suspicious outbound behavior, and post-remediation recurrence.

This CVE should be treated as direct coverage through the amended shared-hosting escalation lane. It should not be described as merely coverage with adaptation in the final amended report because the report now contains a specific detection model for the LiteSpeed plugin, FTP or web shell foothold, symlink, CloudLinux/CageFS, and tenant-boundary behavior.

CVE-2026-41940

Direct coverage. Latest source date: 30 April 2026.

CVE-2026-41940 affects cPanel and WHM, including DNSOnly and WP Squared environments, through an authentication-bypass condition that can allow unauthorized access to hosting-control functionality. This report directly covers the observable behavior associated with exposed hosting-control access, authentication/session mismatch, unauthorized administrative context, service-context execution, account or administrative action abuse, hosted-content modification, DNS or mail manipulation, suspicious outbound behavior, tenant-impact evidence, and post-remediation recurrence.

This CVE is the core direct-coverage vulnerability for the original hosting-control-plane authentication-bypass lane. Detection confidence still depends on telemetry and correlation; vulnerable version status, KEV status, scan activity, exploit-attempt strings, source IPs, user agents, or public reporting alone should not be treated as proof of compromise.

Known Exploited Vulnerability Coverage Assessment

CVE-2026-54420 and CVE-2026-41940 are represented in this coverage set as Known Exploited Vulnerability-relevant items.

KEV status should remain a remediation, urgency, exposure-management, and prioritization signal. KEV status is not detection proof by itself. A vulnerability should not be represented as covered solely because it appears in KEV, vendor advisories, public reporting, vulnerability roundups, exploit feeds, or scanner output.

CVEs Covered With Adaptation

CVE-2026-32993

Coverage with adaptation. Latest source date: 13 May 2026.

CVE-2026-32993 involves an unauthenticated cpsrvd endpoint condition that may allow insertion of arbitrary HTTP headers. This report covers the vulnerability with adaptation where observable behavior aligns with exposed hosting-control access, abnormal request handling, authentication or session inconsistency, header-manipulation evidence, administrative-path interaction, access-flow mismatch, service instability, or post-access behavior. It should not be treated as direct coverage unless the investigation confirms alignment with the report’s hosting-control access-to-impact model.

CVE-2026-32992

Coverage with adaptation. Latest source date: 13 May 2026.

CVE-2026-32992 involves incomplete SSL verification in the DNS Cluster system that could allow a malicious server to intercept requests and capture credentials. This report covers the vulnerability with adaptation where observable behavior aligns with DNS-control trust, credential exposure, control-plane communication anomalies, DNS administration activity, suspicious source or destination behavior, account or credential misuse, and follow-on hosting-control or tenant-impact activity.

CVE-2026-32991

Coverage with adaptation. Latest source date: 13 May 2026.

CVE-2026-32991 involves low-privilege team-user escalation to the owner account’s full capabilities through certain UAPI modules. This report covers the vulnerability with adaptation where observable behavior aligns with account privilege escalation, unauthorized administrative action, reseller or owner-scope expansion, account manipulation, service-context execution, hosted-content modification, tenant-impacting behavior, or post-remediation recurrence.

CVE-2026-29206

Coverage with adaptation. Latest source date: 13 May 2026.

CVE-2026-29206 involves SQL query injection in the sqloptimizer script. This report covers the vulnerability with adaptation where observable behavior aligns with database-impacting activity, SQL abuse, service-context execution, credential or configuration exposure, database tampering, hosted-data integrity impact, backup exposure, or post-access abuse in a cPanel, WHM, or WP Squared hosting environment.

CVE-2026-29205

Coverage with adaptation. Latest source date: 13 May 2026.

CVE-2026-29205 involves cpdavd arbitrary file-read exposure through privilege-dropping and path-filtering weaknesses. This report covers the vulnerability with adaptation where observable behavior aligns with sensitive-file access, credential exposure, configuration-file access, hosted-data exposure, service-context file access, account or tenant scoping, outbound staging, or follow-on administrative and hosted-content impact.

CVE-2026-29203

Coverage with adaptation. Latest source date: 8 May 2026.

CVE-2026-29203 involves unsafe symlink handling that may allow a user to change permissions on an arbitrary file, enabling denial of service and possible privilege escalation. This report covers the vulnerability with adaptation where observable behavior aligns with symlink-sensitive behavior, permission anomalies, authenticated tenant foothold activity, plugin-adjacent behavior, root-owned file changes, tenant-boundary evidence, hosted-content impact, or post-remediation recurrence.

CVE-2026-29202

Coverage with adaptation. Latest source date: 8 May 2026.

CVE-2026-29202 involves Perl code injection in the create_user API call that can allow privilege escalation. This report covers the vulnerability with adaptation where observable behavior aligns with API-driven account creation, service-context execution, code execution, account-management tooling, administrative action abuse, plugin parameter abuse, hosted-content impact, outbound retrieval, or tenant-impacting behavior.

CVE-2026-29201

Coverage with adaptation. Latest source date: 8 May 2026.

CVE-2026-29201 involves arbitrary file read in the feature::LOADFEATUREFILE adminbin call. This report covers the vulnerability with adaptation where observable behavior aligns with authenticated administrative-context file access, sensitive-file exposure, credential or configuration access, hosted-data review, account or tenant scoping, outbound staging, or follow-on hosting-control abuse.

Named Malware / Tooling / PhaaS Coverage

Filemanager backdoor

Coverage with adaptation. Latest source date: May 2026.

Filemanager backdoor activity is covered with adaptation where it produces observable web shell-like behavior, hosted-content tampering, suspicious script placement, server-side command execution, outbound retrieval, credential access, persistence, or post-remediation recurrence on affected hosting infrastructure. The report should not use a Filemanager name as a detection input by itself; coverage depends on observable behavior matching the S21 through S25 detection model.

China Chopper

Coverage with adaptation. Latest source date: stable public technique reference.

China Chopper-style web shell behavior is covered with adaptation where it produces web-accessible command execution, server-side script execution, file upload or download behavior, directory discovery, webroot interaction, suspicious outbound retrieval, hosted-content modification, or post-remediation recurrence. Coverage is behavioral rather than signature-based; a static China Chopper indicator alone should not be treated as sufficient.

WSO

Coverage with adaptation. Latest source date: stable public technique reference.

WSO-style commodity web shell behavior is covered with adaptation where it produces web shell access, command execution, file management, credential or configuration access, archive staging, outbound retrieval, hosted-content modification, or tenant-boundary impact. Coverage depends on behavior and telemetry rather than web shell name or file hash.

C99

Coverage with adaptation. Latest source date: stable public technique reference.

C99-style commodity web shell behavior is covered with adaptation where it produces observable command execution, file browsing, upload or download behavior, webroot modification, credential access, outbound retrieval, or persistence-relevant hosted-content activity. Coverage depends on correlated web, endpoint, file, tenant, and outbound evidence.

B374K

Coverage with adaptation. Latest source date: stable public technique reference.

B374K-style web shell behavior is covered with adaptation where it produces web-service command execution, suspicious file activity, hosted-content tampering, credential or configuration access, archive staging, outbound retrieval, or post-remediation recurrence. Detection should remain behavior-led because commodity web shells are easily modified.

R57

Coverage with adaptation. Latest source date: stable public technique reference.

R57-style commodity web shell behavior is covered with adaptation where it produces web shell access, command execution, file manipulation, hosted-content modification, credential access, or outbound staging activity that aligns with the report’s detection model.

Ransomware deployment following hosting-control compromise

Coverage with adaptation. Latest source date: May 2026.

Ransomware deployment following cPanel or hosting-control compromise is covered with adaptation where observable behavior aligns with service-context execution, archive or staging behavior, file modification, encryption-like impact, ransom-note placement, outbound communication, credential access, backup access, or post-compromise persistence. The report should not claim direct coverage for a specific ransomware family unless the family-specific artifacts and behavior are validated.

Botnet or cryptocurrency-mining deployment following hosting-control compromise

Coverage with adaptation. Latest source date: May 2026.

Botnet or cryptocurrency-mining behavior is covered with adaptation where observable activity aligns with suspicious process execution, outbound communication, payload retrieval, persistence, resource abuse, service modification, network abuse, or post-remediation recurrence on affected hosting infrastructure. Coverage should remain behavioral and should not rely on a miner name, botnet name, wallet, domain, or hash alone.

Named APT / Actor / Campaign Activity Coverage

No named APT, actor, ransomware group, intrusion set, or campaign is counted as direct coverage from the current source set.

Actor names, hosting-provider names, victim reports, infrastructure names, exploit-feed labels, scanner names, and campaign labels should remain enrichment only unless a future source identifies durable behavior that aligns with the report’s hosting-control access, shared-hosting escalation, tenant-impact, abuse-infrastructure, or cloud-lineage detection model.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage for hosting-control-plane compromise where observable activity falls inside the report’s detection model: exposed hosting-control access, authentication/session mismatch, unauthorized administrative action, service-context execution, hosted-content modification, account change, DNS or mail manipulation, suspicious outbound communication, tenant-impact evidence, post-remediation recurrence, and conditional downstream cloud-impact activity.

The S25 detection content also provides direct behavioral coverage for CVE-2026-54420 because the amended detection model explicitly covers LiteSpeed plugin-adjacent shared-hosting escalation involving FTP or web shell foothold evidence, symlink-sensitive behavior, permission anomalies, root-context behavior, CloudLinux/CageFS tenant-boundary context, hosted-content impact, tenant-spanning activity, and post-remediation recurrence.

The S25 detection content provides coverage with adaptation for adjacent cPanel, WHM, WP Squared, DNS Cluster, Nova plugin, adminbin, SQL optimizer, account-management, web shell, ransomware, botnet, cryptocurrency-mining, and backdoor activity only when observable behavior aligns with the report’s hosting-control, shared-hosting, endpoint, file, tenant, outbound, remediation, or cloud-lineage model.

The S25 detection content provides named malware, tooling, PhaaS, actor, and campaign coverage only as behavior-led coverage. Names should not be used as detection inputs unless they are locally approved enrichment fields supporting triage. Detection coverage remains based on observable hosting-control, shared-hosting, endpoint, file, tenant, abuse, remediation, and cloud-lineage behavior.

Direct Coverage

Direct behavioral coverage applies to the report’s first-class detection lanes and items that can be detected by the S21 through S25 strategy without requiring a separate detection model.

CVE-2026-54420

Directly covered.

CVE-2026-41940

Directly covered.

Hosting-control administrative abuse

Directly covered.

Shared-hosting escalation through FTP or web shell foothold, symlink-sensitive behavior, and CloudLinux/CageFS tenant-boundary context

Directly covered.

Web shell tradecraft in shared-hosting environments

Directly covered as behavior when correlated with suspicious access, file, endpoint, tenant, outbound, or post-remediation evidence.

Credential, key, secret, and configuration exposure from hosting-control or shared-hosting compromise

Directly covered.

Tenant-spanning hosted-content tampering

Directly covered.

Outbound abuse from compromised hosting infrastructure

Directly covered.

Coverage With Adaptation

Coverage with adaptation applies to related vulnerabilities, tradecraft, tooling, or activity that shares parts of the report’s hosting-control, shared-hosting, endpoint, file, tenant, outbound, remediation, or cloud-lineage model but requires local tuning for affected component, foothold requirement, privilege model, telemetry source, tenant boundary, file-system behavior, plugin path, cloud resource, or implementation context.

CVE-2026-32993

Covered with adaptation.

CVE-2026-32992

Covered with adaptation.

CVE-2026-32991

Covered with adaptation.

CVE-2026-29206

Covered with adaptation.

CVE-2026-29205

Covered with adaptation.

CVE-2026-29203

Covered with adaptation.

CVE-2026-29202

Covered with adaptation.

CVE-2026-29201

Covered with adaptation.

Filemanager backdoor

Covered with adaptation.

China Chopper

Covered with adaptation.

WSO

Covered with adaptation.

C99

Covered with adaptation.

B374K

Covered with adaptation.

R57

Covered with adaptation.

Ransomware deployment following hosting-control compromise

Covered with adaptation.

Botnet or cryptocurrency-mining deployment following hosting-control compromise

Covered with adaptation.

Future shared-hosting symlink, tenant-boundary, LiteSpeed plugin, CloudLinux/CageFS, web shell, FTP foothold, or hosting-plugin vulnerabilities where observable behavior aligns to the report’s detection model

Covered with adaptation after source validation and behavior-to-telemetry alignment.

Future hosting-control, reseller-control, DNSOnly, WP Squared, DNS Cluster, account-management, adminbin, or control-panel vulnerabilities where observable behavior aligns to the report’s hosting-control access-to-impact model

Covered with adaptation after source validation and behavior-to-telemetry alignment.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable suspicious hosting-control access, authentication/session mismatch, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent activity, CloudLinux/CageFS tenant-boundary evidence, service-context execution, hosted-content modification, account change, DNS or mail manipulation, database access, backup access, outbound abuse, tenant-impact evidence, post-remediation recurrence, or validated downstream cloud-resource activity.

Activity limited to unrelated endpoint malware, unrelated SaaS platforms, unrelated WordPress plugin exploitation, generic phishing without hosting-control or hosted-content impact, network-only anomalies, isolated cloud-control-plane activity without hosting lineage, unrelated DNS abuse, unrelated mail abuse, isolated public reporting, or unrelated CVE exploitation should not be represented as covered by this report.

A CVE should not be counted when it depends on an unrelated exploitation mechanism, lacks sufficient technical detail, produces no aligned hosting-control or shared-hosting telemetry, cannot be correlated through the report’s hosting-control access-to-impact or shared-hosting escalation model, or would require detection logic outside the S21 through S25 strategy.

A malware, tooling, PhaaS, actor, or campaign name should not be counted when coverage depends only on branding, infrastructure indicators, static IOCs, lure text, actor attribution, public reporting labels, scanner names, victim reports, or vendor naming rather than observable behavior aligned with the report’s detection model.

Current Coverage Count

Directly covered CVEs

2

CVEs covered with adaptation

8

Known Exploited Vulnerabilities represented in this coverage set

2

Directly covered malware / tooling / PhaaS / tradecraft names or named tooling patterns

0

Malware / tooling / PhaaS / tradecraft names covered with adaptation

8

Directly covered behavioral tradecraft classes

6

Behavioral tradecraft classes covered with adaptation

3

Directly covered APT / actor / campaign activity names or named activity patterns

0

APT / actor / campaign activity names covered with adaptation

0

Directly covered core behavior classes

2 core behavior classes: hosting-control-plane authentication-bypass compromise and shared-hosting escalation through FTP or web shell foothold, LiteSpeed plugin-adjacent symlink behavior, and CloudLinux/CageFS tenant-boundary exposure.

Coverage Qualification

This count is a living analytical note, not a universal cPanel, WHM, DNSOnly, WP Squared, LiteSpeed, CloudLinux/CageFS, shared-hosting, web shell, hosting-provider, cloud-hosting, malware, actor, campaign, or CVE coverage claim. A related CVE, malware family, web shell family, hosting-control flaw, shared-hosting flaw, control-panel plugin flaw, actor cluster, campaign report, proof-of-concept, or advisory should only be added when it shares enough observable behavior with the report’s detection model to support credible detection or detection-readiness coverage.

Direct coverage should remain limited to the report’s first-class detection lanes, including suspicious hosting-control access, authentication/session mismatch, unauthorized administrative action, service-context execution, FTP or web shell foothold evidence, LiteSpeed plugin-adjacent activity, symlink-sensitive behavior, CloudLinux/CageFS tenant-boundary context, hosted-content modification, account change, DNS or mail manipulation, suspicious outbound communication, abuse-report correlation, tenant-impact evidence, post-remediation recurrence, and conditional cloud-impact activity.

Covered-with-adaptation items should remain counted only when the activity can be correlated through hosting-control access logs, authentication logs, session logs, FTP logs, web logs, endpoint telemetry, file and symlink telemetry, LiteSpeed plugin context, CloudLinux/CageFS context, tenant mapping, reseller mapping, DNS logs, mail logs, database logs, backup records, abuse reports, cloud audit logs, remediation records, change-control evidence, and approved workflow evidence.

KEV status should be treated as an urgency and remediation-prioritization signal, not as the basis for coverage by itself. Malware, tooling, web shell, actor, and campaign names should be treated as coverage context only when their behavior aligns to the report’s S21 through S25 detection strategy.

A related CVE, proof-of-concept, malware family, web shell family, plugin flaw, actor cluster, or campaign report should not be counted when it depends on unrelated exploitation mechanics, lacks aligned telemetry, affects only unrelated application functionality, produces no hosting-control access, shared-hosting foothold, endpoint execution, file impact, tenant-boundary, DNS, mail, outbound, cloud-lineage, or remediation behavior, or requires a separate detection model.

Executive Exposure Statement

The organization’s economic exposure is highest when hosting-control or shared-hosting compromise creates uncertainty around whether administrative access, customer-facing hosted content, tenant isolation, reseller scope, DNS authority, mail integrity, database access, backups, cloud-connected resources, and remediation outcomes remain trustworthy.

The strategic risk is not one CVE, one KEV entry, one vulnerable version, one exploit request, one scanner hit, one source IP, one user agent, one symlink path, one web shell name, one plugin version, one actor report, or one customer ticket. The strategic risk is the possibility that attackers can convert trusted hosting administration or shared-hosting footholds into unauthorized control, customer-facing content compromise, tenant-boundary failure, abuse infrastructure, credential exposure, cloud-resource impact, legal and regulatory review, and executive uncertainty about hosting trust restoration.

S40 — References

Vendor / Platform Documentation

·        cPanel Support — Security: CVE-2026-41940 — cPanel & WHM / WP2 Security Update 04/28/2026 — hxxps://support[.]cpanel[.]net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

·        cPanel Support — Security: LiteSpeed cPanel Plugin — May 31, 2026 — hxxps://support[.]cpanel[.]net/hc/en-us/articles/40868195661207-Security-LiteSpeed-cPanel-Plugin-May-31-2026

·        LiteSpeed Blog — Security Update for LiteSpeed cPanel Plugin — hxxps://blog[.]litespeedtech[.]com/2026/06/01/security-update-for-litespeed-cpanel-plugin-2/

·        cPanel Support — Security: CVE-2026-29203 — cPanel & WHM / WP2 Security Update — May 08, 2026 — hxxps://support[.]cpanel[.]net/hc/en-us/articles/40311543760407-Security-CVE-2026-29203-cPanel-WHM-WP2-Security-Update-May-08-2026

·        cPanel Support — Security: CVE-2026-32993 — cPanel & WHM / WP2 Security Update — May 13, 2026 — hxxps://support[.]cpanel[.]net/hc/en-us/articles/40437313190295-Security-CVE-2026-32993-cPanel-WHM-WP2-Security-Update-May-13-2026

CVE / Vulnerability Records

·        NVD — CVE-2026-54420 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-54420

·        NVD — CVE-2026-41940 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41940

·        NVD — CVE-2026-32993 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-32993

·        NVD — CVE-2026-32992 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-32992

·        NVD — CVE-2026-32991 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-32991

·        NVD — CVE-2026-29206 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-29206

·        NVD — CVE-2026-29205 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-29205

·        NVD — CVE-2026-29203 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-29203

·        NVD — CVE-2026-29202 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-29202

·        NVD — CVE-2026-29201 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-29201

Threat Technique and Exploitation Catalogs

·        CISA Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        MITRE ATT&CK Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Threat Tradecraft and Intrusion Patterns

·        NSA / CISA — Detect and Prevent Web Shell Malware — hxxps://media[.]defense[.]gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422[.]PDF

Security Research and Technical Analysis

·        watchTowr — cPanel Authentication Bypass CVE-2026-41940 — hxxps://watchtowr[.]com/resources/2765-rapid-reaction-cpanel-authentication-bypass/

·        The Hacker News — cPanel CVE-2026-41940 Under Active Exploitation to Deploy Filemanager Backdoor — hxxps://thehackernews[.]com/2026/05/cpanel-cve-2026-41940-under-active[.]html