How Threat Actors Regain Access After a Ransomware Attack

Prepared by: Sarah Jordan, DFIR Analyst | Last update: 10 February 2026

Understanding persistence techniques that allow attackers to return days, months or even years after an incident. 

Many organisations believe a ransomware incident is over once systems are restored and operations resume. In practice, this is often the most dangerous phase. Threat actors frequently leave behind hidden persistence mechanisms that allow them to regain access long after the initial compromise, turning recovery into reinfection. Understanding how persistence works is essential for any organisation responsible for incident response, system restoration or security assurance.

Why ransomware attackers return after recovery

Imagine successfully containing a ransomware incident, restoring from backups and bringing systems online only to be reinfected 72 hours later. This scenario is more common than you might expect and the reason for this is simple, Threat Actors left hidden “backdoors” in your environment.

These backdoors, known as persistence mechanisms, are like spare keys that Threat Actors hide throughout your environment. So even if you lock the front door by resetting user accounts, they can simply use one of these spare keys to walk right back in.

This blog explains common ways that Threat Actors maintain hidden access to compromised environments, including:

• Remote access tools disguised as legitimate IT software

• Web shells hidden on internet facing servers

• Compromised user accounts that blend in with normal employee access

• Malicious software designed to survive system reboots and restarts. 

What is persistence in a ransomware attack?

When a Threat Actor gains access to a victim’s environment their goal is usually not to cause immediate damage, it’s to maintain long-term access. Think of this like a burglar who doesn’t just steal from your house once but also makes a copy of your keys so they can return later.

The term “Persistence” is used by security professionals to refer to the various methods that Threat Actors use to keep their access to a victim’s environment. Triskele Labs have investigated hundreds of ransomware incidents and have observed Threat Actors typically deploying multiple persistence mechanisms in a victim’s environment during their period of access. This redundancy ensures that even if one mechanism is discovered and removed several others remain active.

What makes persistent mechanisms particularly dangerous is that many of them involve legitimate tools or normal system processes that are used in malicious ways. This makes them harder to detect than traditional malware because they often look like routine IT operations or normal user activity.

Common persistence techniques used after initial compromise

Threat Actors use various methods to maintain hidden access to compromised environments. While these may vary, they generally fall into a few main categories. These include Remote Monitoring and Management (RMM) tools, Web Shells, Remote Access Trojans (RATs) and Account-based persistence. Below is an in-depth analysis of some of these mechanisms to help security teams identify and remove them from an environment.

▫️How legitimate tools are abused for persistent access

Remote Monitoring and Management Tools (RMM) tools are commonly used legitimately by Information Technology (IT) teams to remotely access hosts for technical response and troubleshooting. However, they are often abused by Threat Actors for persistent access to a victim’s environment.

Triskele Labs has also observed Threat Actors using a technique called living-off-the-land. This occurs when a Threat Actor uses an existing RMM tool deployed in a victim’s environment. Living-off-the-Land is hard to detect as the Threat Actors activity blends in with legitimate internal usage.

It is critical when investigating an incident to analyse native RMM logs available to determine where the source of a connection originated from.

Table 1

RMM tool comparison below shows an in-depth comparison of different RMM tools and their log file locations, which can be used a checklist to review potential Treat Actor activity related to the RMM tool.

▫️Web shells and long-term access to internet-facing servers

Web shells are a common initial access vector and persistence mechanism created on externally facing exchange servers and web servers. They are usually created on these servers due to exploitation of an unpatched vulnerability and provide Threat Actors with command-line access to the impacted host.

With this access, Threat Actors have been observed executing commands to create additional accounts for remote authentication or deploying RMM tools to escalate their access from a shell to a remote session. This privilege escalation to a remote session would give Threat Actors the same level of access to a device as if you were accessing it directly using a keyboard and mouse.

In August 2021, the vulnerability known as Proxy Shell was publicly disclosed under the Common Vulnerabilities and Exposures (CVEs) CVE-2021-31207, CVE-2021-34523 and CVE-2021-34473. Since its disclosure, Triskele Labs has investigated several incidents where Web Shells were created due to the Proxy Shell vulnerability on Exchange server versions 2013, 2016 and 2019.

One of these incidents occurred in 2023, where it was identified that the Threat Actor created a web shell back in 2021 on an exchange server due to the Proxy Shell vulnerability. This web shell remained dormant on the impacted server until it was used one (1) year later to regain access to the environment. Following their re-entry, the Threat Actor was observed escalating their privileges from command-line access to a session, laterally moving to other hosts and deploying ransomware to encrypt files within the victim’s environment.

To detect for web shells look for recently created or unusual files, often contain the extensions .php, .asp and .aspx. On Windows-based Web Servers, web shells are commonly created in the root directory C:\inetpub\wwwroot\ and its subdirectories. In addition to this, Internet Information Services (IIS) logs should be investigated to identify any post-compromise activity or further interaction with the web shell. These logs can be found in the file path C:\inetpub\logs\LogFiles\.

For Linux-based Web Servers running Apache or Nginx, web shells are commonly created in the directories /var/www/html/ or /usr/share/nginx/html/ and their subdirectories. To investigate post-compromise activity, navigate to Apache logs located in the file paths /var/log/apache2/ or /var/log/httpd/. Nginx logs can be found in the file path /var/log/nginx/.

For Exchange Servers, web shells are often created in the Outlook Web Access (OWA) and Exchange Control Panel (ECP) directories and subdirectories. These can be found in the directories C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa and C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp. Additionally, as Microsoft Exchange uses IIS, Threat Actors also commonly place web shells in the directory C:\inetpub\wwwroot\aspnet_client and its subdirectories.

▫️Remote access trojans used for ongoing control

Remote Access Trojans (RATs) are a type of malicious software with multiple functionalities that allows Threat Actors to access systems remotely, collect information, communicate with command and control (C2) infrastructure and evade detection.

Triskele Labs investigated an incident where NjRat was deployed in the victim’s environment alongside several RMM tools. This RAT, also known as Bladabindi contained functionality to remotely access impacted hosts, communicate with the Threat Actors C2 infrastructure, gather passwords and record user activity via a keylogger.

▫️Account-based persistence and credential misuse

After gaining access to a victim’s environment, Threat Actors often create new user accounts to escalate their privileges and maintain access to the environment. Depending on the level of access the Threat Actor has to the environment, either Local orDomain Administrator accounts can be created. These usually follow naming conventions to mimic legitimate accounts or services to avoid detection. Examples include support, admin, svc_backup and backup_admin.

Credential harvesting is often performed during the early stages of an incident to compromise additional valid accounts within the environment. While credential harvesting can be performed across multiple accounts or the whole organisation, accounts that are commonly targeted include dormant accounts, service accounts, shared and administrative accounts.

Threat Actors can use additional created or compromised accounts for persistence access by leveraging legitimate authentication mechanism into the environment such as RDP, VPN orRMM tools. Due to this, detection of account-based persistence can be difficult.However, Windows Event Logs can be used to detect newly created accounts, password changes to existing accounts and account membership changes.

How attackers ensure malicious tools survive reboots

Aside from maintaining access to an environment, persistence is also used by ThreatActors to ensure that their tools continuously run. It is relatively common for tools to stop running and for servers to unexpectedly shutdown from time to time. Common persistence mechanisms in tools include Scheduled Tasks, Windows Services and Registry Autorun Keys.

Triskele Labs has observed several incidents where Threat Actors have created scheduled tasks to maintain consistent communications with their Command and Control (C2) infrastructure.

One example observed was the installation of Cloudflare tunnel as a Windows service to automatically start after system reboot. Cloudflare tunnel is a legitimate tool that creates a secure tunnel between a local system and Cloudflare’s network. This would provide the Threat Actor with a persistent tunnel to their C2 infrastructure that bypasses inbound firewall rules and blends with legitimate HTTPS traffic, making detection more difficult.

Another trend identified by Triskele Labs is the inclusion of persistence in the ransomware deployment process to ensure that it continues after the Threat Actor has left the environment. This has been observed through the creation of autorun items which executes the ransomware binary every time at system startup.

For context, when a ransomware incident is first identified by a victim organisation, usually the irfirst action is to immediately shutdown all systems to prevent further encryption of files. By creating an auto run task to execute on system start-up, the Threat Actor ensures that hosts that are rebooted later are also impacted by the ransomware.

Why restoring from backups can reintroduce attackers

Following ransomware deployment in a victim’s environment, the main priority for most organisations is to bring the business back to an operational state as soon as possible. One of the priority actions performed during this stage is restoring impacted servers from backups. However, it is critical that backups are investigated and cleared prior to being brought back into production.

From all historical investigations performed by Triskele Labs there has been an average Threat Actor dwell time of approximately 33 days in a victim’s environment. Triskele Labs have observed that servers recovered from backups prior to 33 days have a very high likelihood of still having persistence on them. If backups are not investigated and cleared of persistence mechanisms, then there is a high risk of re-entry to the environment.

Detecting persistence during incident response and recovery

Having Endpoint Detection and Response (EDR) tooling on all devices in the environmentis critical for identifying persistence as well as other Threat Actor activity.

Unlike standard antivirus, which relies on known signature-based detections, EDR candetect behavioural anomalies, fileless malware, and advanced persistentthreats, often serving as an early indicator of a security incident.

All log sources, including data from EDR tooling, should be ingested into a Security Information and Event Management (SIEM) solution. SIEM products play a criticalrole in centralising, correlating, and analysing security related data fromacross an organisation’s IT environment.

This ensures that critical data such as security and network logs are available and not overwritten.

As Threat Actor activity often occurs outside of typical Australian business hours,EDR and SIEM platforms should ideally be monitored 24x7x365 either through an internal Security Operations Centre (SOC) or a trusted Managed Detection and Response (MDR) provider.

Application allowlisting is another important security control for preventing the execution of unauthorised or malicious software within the environment. Application allowlisting involves defining a list of approved applications that are permitted to run, while all other executables are blocked by default.