Article
Surtr Ransomware Pays Tribute to REvil
Combating Ransomware
Arete Analysis

Summary
Surtr ransomware, a significant threat in the current cyber landscape, paid tribute to the now defunct REvil (aka Sodinokibi) group through its sophisticated techniques, although the developers of Surtr ransomware likely do not have a direct connection to REvil.
In February 2022, Arete investigated a Surtr ransomware incident where the ransomware author(s) paid tribute to the now defunct REvil (aka Sodinokibi) group by making a registry key change to the infected host. REvil was an infamous Russian-speaking Ransomware-as-a-Service (RaaS) operation known for the Kaseya attack. In October 2021, a multinational effort disrupted REvil’s operations, followed by Romanian and Russian law enforcement largely dismantling the group by arresting individuals and seizing millions in cash and cryptocurrency.
Arete notes that the developers of Surtr ransomware likely do not have a direct connection to the now defunct REvil ransomware group. However, it is likely that the developers of Surtr are leveraging their REvil tribute to gain popularity. Arete also notes that multiple ransomware groups and affiliates work in a closed ecosystem, sharing source code, strategies, initial access brokers, functionality, and development resources. Thus, it is possible a Surtr developer previously worked with the REvil ransomware group.
Research revealed that Surtr ransomware
Changes the victim’s system manufacturer name with a sentence paying tribute to REvil.
Uses a message box to warn affiliates not to run the malware in the Commonwealth of Independent States (CIS) — a group of countries in Eastern Europe and Asia formed by Russia and other republics after the dissolution of the Soviet Union — or they will be banned.
Displays messages not common on mature ransomware, which could indicate that the ransomware’s development is still in the early stages.
Like other ransomware, encrypts files in network shares, deletes volume shadow copies, clears Windows event logs, and has a list of whitelisted file extensions, file names, and folders.
Has multilayer obfuscation.
Creates persistence through registry key changes to start as a service, in registry run keys, and make a copy of itself in the StartUp directory.
Creates a mutex value to prevent another copy of the process from running in the system.
Background
Surtr is a new RaaS operation, first observed in December 2021. Like many other ransomware groups, Surtr avoids its execution in the CIS countries and adopts the double extortion scheme of stealing and threatening to leak data if ransom demands are not met. In this investigation, the ransomware targeted Windows systems and employed several anti-debugging/anti-sandboxing techniques. At present, there are no public decryptors or logical flaws to recover files encrypted by Surtr.
Technical Analysis
Surtr ransomware is packed and has an entropy value of 7.62115. The malware has multilayer obfuscation. The native Windows Application Programming Interface (API) “CryptDecrypt” unpacks the first layer of packed content. The packer used Microsoft Enhanced RSA and Advanced Encryption Standard (AES) Cryptographic Provider (CALG_AES_256) to decrypt the data. The unpacked sample is once again UPX packed, which drops the actual payload.

Figure 1. Decrypt function

Figure 2. Decrypting PE file in the memory (encrypted vs decrypted)
Upon decrypting the Portable Executable (PE) file, the packer spawns the same as a new child process with the original packed executable name. Using Windows API “VirtualAllocEx”, it allocates an address space in the spawned child process and writes the process memory with newly decoded binary, later resuming the child process.

Figure 3. Process injection
The decrypted sample shown in Figure 2 is UPX packed. Upon successful unpacking, the analyst gets the Surtr ransomware payload.
Surtr ransomware retrieves file attributes for a specified file or directory “NoRunAnyWay”. If the file or directory does not exist, the program continues creating a folder “Service” at “%ProgramData%”. Later, the sample checks for “config.txt” at the same directory. It appears the ransomware stores its configuration at the “C:\ProgramData\Services” folder at a later point in time.
The ransomware tries to open a mutex by the name “SurtrMUTEX”. If the mutex does not exist, it continues the execution or the ransomware terminates the current program. This activity ensures that a single instance of the program is running.

Figure 4. Creating Mutex
Similar to other ransomware, Surtr avoids execution in the CIS countries, which include Armenia, Azerbaijan, Belarus, Kazakhstan, Kirghizstan, Moldavia, Uzbekistan, Russia, Tajikistan, Turkmenistan, Ukraine, to avoid infecting users where the operators and affiliates most likely reside and visit to prevent arrest by local authorities. Initially, the sample checks the IP address of the victim’s machine and collects IP-related information using ip-api[.]com, which returns a JSON file containing the country of IP origin. Later, this is compared against the list of countries hardcoded in the sample. If there is a match, it avoids execution, leaving a comment “WARNING. Surtr does not run in this country if you do it again you will be banned.” Note: The ransomware also works without proper response from the ip-api[.]com.
Here is the list of countries the ransomware avoids:

Figure 5. Comparing CIS name to avoid execution
Ransomware anti-sandboxing techniques are shown below
The ransomware keeps track of anti-sandboxing techniques using a counter. As shown below, the sample initially checks for API Hooks “E9” for the Windows function “CreateProcessA”. The counter is updated accordingly.

Figure 6. Anti-Sandbox-1
The ransomware checks if the total physical memory (RAM) of the host machine is less than 500MB using the API “GlobalMemoryStatus”. If the victim’s hardware passes this check, the counter is incremented.
Later, using DeviceIOControl, the ransomware gets the geometry (File size) of the C:\ drive and compares it with a hardcoded constant. If the victim’s hardware passes this check, the counter is incremented.[1]

Figure 7. Anti-Sandbox-2, 3
Ransomware anti-debugging techniques are shown below.
Initially, the ransomware checks if any hardware breakpoints (DR0, DR1, DR2, DR3) are set. If the condition satisfies the debugging, the counter is incremented.

Figure 8. Anti-Debugging-1
It also leverages the Windows API “IsDebuggerPresent” to check if the process is being debugged or not and updates the counter accordingly.

Figure 9. Anti-Debugging-2
It appears the program accesses the “Configuration Directory” itself and checks if “GlobalFlagsClear” is set to 0. If yes, the counter is updated.

Figure 10. Anti-Debugging-3
The ransomware checks for the NtGlobalFlag value of the Process Environment Block, which is set to the default value “0” by the operating system. When debugging the malware with a software debugger, the NTGlobalFlag value would be set to 0x70. Passing this check would indicate the presence of a debugger and the counter would be updated [2].

Figure 11. Anti-Debugging-4
Upon these checks, the ransomware compares these calculated individual counters of anti-debugging/anti-sandboxing with the value 2. If either of these counters is more than 2, the ransomware exits with a message box saying, “WARNING. SandBox/Debugger Detected!!!”
The key characteristic of the program is using multithreading for file encryption. Arete observed that multiple threads were created during the execution process, which delays malware analysis and hastens data encryption.
The program makes sure to remove system backups, shadow copies, and system logs.

Figure 12. Removing system backups, Shadowcopies, System logs.
As part of the initial encryption process, the ransomware creates and assigns a random ID to the victim’s machine. The ID is later stored in “c:\ProgramData\Services\ID.surt” and used in further file encryption.

Figure 13: Creating victim ransomware ID
The ransomware checks mounted drives from (A to Z) using Windows native API “GetDriveTypeW”. Once the ransomware enumerates all mounted drives and shares, it encrypts all files except the following:
File Extensions: “.exe”, “.DLL”, “.lnk”, “.surt”
File Names: “surt”, “NTUSER.DAT”, “WIN.INI”, “UsrClass.dat”, “Pagefile.sys”, “hiberfil.sys”, “DumpStack.log.tmp”, “Config.msi”, “boot”
Folders: “Windows”, “Microsoft”, “Windows.old”, “Windows kits”, “WindowsApps”, “Tor Browser”, “Google”, “Mozilla”, “DropBox”
The ransomware uses the “net use” command to connect the remote host device’s share “ADMIN$”. If the connection is successful, the share is added to the encryption list.

Figure 14. Enumerating network shares
The ransomware acquires a targeted file’s handle. Later, it generates a 64-bit random value using a Windows Native API “CryptGenRandom” as shown in Figure 15.
Figure 15. Generating 64-bit random value
The generated random value creates XOR keys, which are used to further encrypt the file contents. Upon encryption of the file, the ransomware encrypts the generated random value using asymmetric encryption and stores the encrypted key at the end of the file as shown in Figure 17.

Figure 16. File encryption loop

Figure 17. Dissecting encrypted file
Figure 17.1 “SURTR” – The attacker identifies if the file was encrypted by the Surtr ransomware using the keyword.
Figure 17.2 Asymmetric encrypted 64-bit random generated values.
Figure 17.3 Delimiter.
The ransomware achieves persistence by copying itself to the “StartUp” folder, creating scheduled tasks that execute the ransomware “ONLOGON” and adding a registry value in “Run” and “RunOnce” key to make the ransomware restart on a system reboot.

Figure 18. Achieving persistence
Arete found that the threat actor also updates the system manufacturer name to “Tribute to the REvil <3” by adding/modifying the “OEMInformation” registry value.
Figure 19. Adding “Tribute to REvil” registry entry
The registry changes mentioned above are shown below.

Figure 20. Updating the system manufacturer
The ransomware further tries to hide by updating its file attributes, thus complicating forensic investigations to identify the same.
Figure 21. Updating file attributes
Upon successful execution of the ransomware, Surtr changes the background of the victim’s machine as shown below and reboots the system.

Figure 22. Changes desktop background
Ransom note name: SURTR_README.hta, SURTR_README.txt.

Figure 23. Ransomware note
Conclusion
A new ransomware on the scene, Surtr could be one to keep an eye on as it mentions REvil’s name in its operations. As more information unfolds, Arete could assess the future of Surtr ransomware. Arete has countermeasures coverage to detect Surtr payloads and artifacts via Arsenal Threat Management and Threat-ID.
Countermeasure
Yara Rule
rule Surtr_ransomware_executable
IOCs:
MD5 Sample B7966CCA3C6FE9B9C64D772EC7DF804C Packed
460FDD0198A286067211BFCF47825B11 UPX Packed
FD16AC037269708C1AB135653483E891 Payload
URL 2i74xfkhsu4zd6qv5aiifv3wznj6vq3jo6mle3zxux6vpftyuezxhmad[.]onion
References:
Back to Blog Posts
Article
LiteLLM Supply-Chain Compromise
A software supply-chain attack compromised the release pipeline of LiteLLM, a widely used open-source Python SDK and AI gateway. Attackers leveraged the compromised pipeline on October 21st to publish a malicious LiteLLM version through PyPI and associated Docker registries. The affected release, LiteLLM 1.107.0, contained malware designed to steal credentials, sensitive configuration data, private keys, browser information, and other secrets from compromised systems.
What’s Notable and Unique
The incident is particularly significant because LiteLLM provides a common API for applications to interact with AI models from multiple providers. It is reported that the project had approximately 61,800 GitHub stars and 92 million monthly PyPI downloads.
Rather than modifying the core LiteLLM application source code, the threat actors reportedly tampered with the installation package itself. The malware was designed for broad credential and information theft and encrypted the collected data before uploading it to the attacker's endpoint.
The compromise went beyond one-time credential theft. A malicious Python component launched a detached loader that checked a GitHub-hosted pointer every hour and could download Python code from an external server for execution on the compromised machine. This provided threat actors with a mechanism for subsequent remote code execution.
Analyst Comments
Although the malicious packages were subsequently removed, simply uninstalling or deleting the affected LiteLLM package may not be sufficient, because malicious Python startup files or the detached loader could remain on the host. All exposed information should be rotated immediately, and infected systems should be isolated and rebuilt from clean backups. The most recent clean release prior to the attack, LiteLLM 1.106.2, is currently the suggested recovery version.
Sources
LiteLLM release pipeline hacked to distribute info-stealer malware
LiteLLM 1.107.0 Compromised: Python Startup Hooks Steal Cloud, AI, and Proxy Credentials
The Collector Reaches Beyond Provider API Keys
Article
French Supermarket Cyberattack Highlights Risks in Exposed Refrigeration Controllers
Hundreds of French supermarkets were reportedly affected by a cyberattack in which threat actors compromised internet-connected refrigeration controllers and manipulated temperature and defrost settings, which caused refrigeration units to overheat, resulting in widespread food spoilage and significant financial loss. Impacted refrigeration systems were associated with Danfoss, Copeland, and Dixell, and demonstrated how vulnerabilities in industrial control systems (ICS) can disrupt physical operations without relying on conventional data theft or encryption. The attack also raised concerns about the wider exposure of similar devices, as thousands of refrigeration management interfaces remain accessible from the public internet. The incident highlights the growing risk posed by insecure operational technology (OT), particularly where legacy equipment and remote-management interfaces lack adequate security controls.
What’s Notable and Unique
Researchers identified approximately 2,765 internet-accessible Danfoss AK-SM 800A interfaces during assessment. This figure reflects the scope of that research and should not be interpreted as a current count of exposed devices. Publicly accessible management interfaces increase the opportunity for unauthorized access to industrial equipment.
Research also identified several security flaws in the Danfoss AK-SM 800A platform, including an authentication bypass command injection that could enable remote code execution and a weakness involving web-server configuration changes. Danfoss addressed these findings through firmware updates.
Authorities reported compromised Danfoss AK-SM and AK-SC systems, alongside Copeland XWEB and Dixell XWEB monitoring platforms.
Analyst Comments
The incident demonstrates the business consequences of insufficiently secured industrial infrastructure and reinforces the need to integrate OT security into enterprise risk management. Organizations operating connected facility systems should establish clear ownership of industrial assets, enforce secure remote-access policies, and prioritize remediation based on exposure and operational criticality. The findings also highlight the importance of coordinating security teams with facilities and engineering personnel to ensure that protective measures do not compromise essential operations. A risk-based approach to OT security can help organizations reduce exposure while maintaining the availability and reliability of critical equipment.
Sources
France Supermarket Hacks Expose Risks of Internet-Facing Refrigeration Systems
Freeze the Controller, Defrost the Food: Uncovering Vulnerabilities in Danfoss Refrigeration Controllers
Attackers Heat French Supermarket Fridges Up to 50°C by Hijacking Danfoss Controllers
Article
FortiBleed Campaign Remains Active
The FBI and Secret Service recently warned that the FortiBleed credential-harvesting campaign remains an active threat targeting internet-facing Fortinet FortiGate firewalls and secure socket layer (SSL) virtual private network (VPN) gateways. The agencies report that attackers continue to scan internet-exposed Fortinet firewalls using previously obtained credentials. This has reinforced assessments made by other security researchers, who have stated that “FortiBleed should be treated as an active access operation, not as a one-time credential leak.”
What’s Notable and Unique
FortiBleed, active since February 2026, begins with widespread reconnaissance to identify internet-facing FortiGate firewalls and SSL-VPN services. Once potential targets are identified, operators attempt to gain initial access through credential stuffing, password spraying, and dictionary attacks using previously compromised credentials.
Following successful access, the attackers deploy the Go-based FortigateSniffer tool on compromised appliances. The tool leverages native FortiOS diagnostic functionality to passively intercept authentication traffic across 24 protocols, enabling the collection of cleartext credentials and password hashes passing through the device.
Successfully recovered credentials are reused to expand access, including Active Directory enumeration, Kerberos validation, SMB authentication, and network share discovery, enabling threat actors to move deeper into the victim environment.
Reporting indicates that initial access brokers (IABs) leveraging the FortiBleed attack chain have facilitated access for downstream ransomware operations, including the INC Ransom/Lynx and Payload ransomware groups. This aligns with Arete’s observations of ransomware groups, including INC, Qilin, and DragonForce, targeting Fortinet FortiGate and VPN infrastructure as an initial access vector.
Remediation
Organizations should restrict internet-facing FortiGate management interfaces, rotate administrative and VPN credentials, review local and privileged accounts, and enforce MFA for remote access. If a potential compromise is detected, organizations should isolate affected systems, conduct threat hunting to determine the scope and identify compromised accounts and devices, and preserve relevant logs and artifacts. Organizations should also report the incident to appropriate authorities and implement targeted eviction measures based on identified threat actor activity.
Analyst Comments
FortiBleed represents an ongoing access-enablement threat, rather than a one-time credential exposure. The campaign’s ability to harvest, validate, and reuse credentials can provide sustained access to victim environments and create opportunities for downstream ransomware activity. Organizations with suspected FortiGate exposure should treat the activity as a potential active compromise and investigate for persistent access, compromised accounts, and lateral movement.
Sources
FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts
FBI Warns FortiBleed Remains Active After Amassing 86,644 Fortinet Device Credentials
Article
Threat Actors Exploiting Critical FortiMail Zero-Day Vulnerability
Fortinet has disclosed a critical vulnerability in FortiMail, tracked as CVE-2026-104286, that is currently being exploited as a zero-day in the wild. The flaw, which carries a Critical CVSS score of 9.8, affects the FortiMail management interface and can allow unauthenticated attackers to write arbitrary files to affected systems, potentially leading to unauthorized code execution and full system compromise. Fortinet has confirmed active exploitation and urged customers to implement mitigations immediately while awaiting security updates.
What’s Notable and Unique
The vulnerability stems from improper restriction of file paths combined with improper neutralization of NULL byte characters. An unauthenticated attacker can exploit the flaw via specially crafted HTTP or HTTPS requests to write arbitrary files on the underlying operating system.
Organizations running FortiMail 7.2 can remediate the vulnerability by upgrading to 7.4 or newer. For customers using affected FortiMail 7.4, 7.6, and 8.0 versions, fixes have not yet been released. However, Fortinet has confirmed that the issue will be addressed in the upcoming 7.4.9, 7.6.7, and 8.0.2 releases.
Until the patched versions become available, Fortinet recommends mitigating risk by disabling the Identity-Based Encryption (IBE) feature. As an additional safeguard, administrators should restrict access to the FortiMail management interface, either by removing internet exposure altogether or limiting access to trusted internal networks only. The advisory also includes log entries that administrators can use to identify potentially compromised appliances.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-104286 to its Known Exploited Vulnerabilities (KEV) catalog and directed federal agencies to perform forensic triage and mitigation by October 4th.
Analyst Comments
Impacted organizations should review their FortiMail instances to ensure there are no unauthorized logins, examine device settings, evaluate all configurations as potentially compromised, and carry out the necessary recovery procedures. Defenders should immediately implement Fortinet's recommended mitigations, review systems for IOC matches, and prepare to deploy the forthcoming security updates as soon as they become available. It is strongly advised that all enterprises assess their setups to reduce risk, as protecting publicly accessible management interfaces is a fundamental security best practice.
Sources
Improper limitation of a pathname to a restricted directory



