A problem with a shared hosting account

Hi there!

Has anyone encountered a web-hosting compromise where the attacker gained access months before the main malicious activity became visible?

I'm investigating a compromised shared-hosting/cPanel account and trying to understand the timeline.

The pattern I'm seeing is roughly this:

possible initial compromise in January
relatively little visible activity for several months
increasing signs of compromise later in the year
much more aggressive activity in September
some activity appears to happen on Sundays

There was also a directory containing PHP code disguised as image files, consistent with a webshell/backdoor. After I neutralised part of the behaviour, the malicious content appeared to become active again. I was eventually able to observe and remove it when it reappeared.

I'm wondering about two things:

Is it common for an attacker to establish persistence and then remain relatively quiet for months before becoming more active?
Has anyone encountered attackers deliberately timing activity for weekends, holidays, or other periods when the victim's support/IT response is likely to be slower?

I'm particularly interested in real incident-response cases rather than general speculation.

I am not assuming that the January activity and September activity necessarily came from the same actor. I'm trying to determine whether this kind of "low-and-slow persistence followed by later activation" is a known pattern.

Since I don't know have a root access and a hosting company does not want to provide such information as they 'have been too busy solving the problem and getting lots of emails from others' I'm (I guess) left with this by myself.

Also, if the malicious files can recreate themselves after deletion, what persistence mechanisms would you investigate first in a cPanel/shared-hosting environment?

I have found a few interesting articles but am not sure how much they are related to my case:

Impact

The impact includes persistent unauthorized access to shared hosting accounts, enabling attackers to execute arbitrary PHP code stealthily. This can lead to data compromise, website defacement, or further lateral movement within the hosting environment. The use of cookie-controlled webshells reduces detection likelihood and complicates incident response. Although root access is not typically achieved, the attacker can maintain durable control over the compromised account and its web content. The low-and-slow activity pattern can delay discovery and remediation.

Defensive guidance

Mitigation should focus on detecting and removing cookie-controlled webshells by monitoring for unusual cookie-triggered execution patterns and scheduled tasks within hosting accounts. Incident responders should investigate persistence mechanisms such as cron jobs registered via hosting control panels. Since this technique leverages legitimate account-level features, restricting and auditing user-level scheduled tasks and file modifications is recommended. Hosting providers should enhance monitoring for anomalous cookie usage and provide timely support to affected customers.

Summary

Threat actors abuse HTTP cookies as a covert control channel for PHP-based webshells on Linux shared hosting environments. These webshells do not expose command execution through visible URL parameters or request bodies but rely on attacker-supplied cookie values to activate malicious functionality. This cookie-controlled execution reduces visibility and logging, enabling persistent post-compromise access. Variants include loaders with layered obfuscation, direct cookie-driven payload staging, and cookie-gated interactive shells. Persistence is often achieved by registering cron jobs via legitimate hosting control panel interfaces, allowing recurring execution of malicious code within the account's isolated environment. This approach allows attackers to maintain access without root-level compromise and evade many traditional detection mechanisms.

A problem with a shared hosting account

Discussion

Links cited in the discussion

Impact

Defensive guidance

Summary

References

Community reviews

Discussion

Links cited in the discussion

AI analysisMachine-generated, updated 15 Sep 2026, 12:16 UTC

Technical details

References

Community reviews