
A relatively new ransomware operation named Interlock attacks organizations worldwide, taking the unusual approach of creating an encryptor to target FreeBSD servers.
Launched at the end of September 2024, Interlock has since claimed attacks on six organizations, publishing stolen data on their data leak site after a ransom was not paid. One of the victims is Wayne County, Michigan, which suffered a cyberattack at the beginning of October.
Not much is known about the ransomware operation, with some of the first information coming from incident responder Simo in early October, who found a new backdoor [VirusTotal] deployed in an Interlock ransomware incident.
Soon after, cybersecurity researcher MalwareHunterTeam found what was believed to be a Linux ELF encryptor [VirusTotal] for the Interlock operation. Sharing the sample with BleepingComputer, we attempted to test it on a virtual machine, where it immediately crashed.
Examining the strings within the executable indicated that it was compiled specifically for FreeBSD, with the Linux "File" command further confirming it was compiled on FreeBSD 10.4.
interlock.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=c7f876806bf4d3ccafbf2252e77c2a7546c301e6, for FreeBSD 10.4, FreeBSD-style, not stripped
However, even when testing the sample on a FreeBSD virtual machine, BleepingComputer was unable to get the sample to properly execute.
While it is common to see Linux encryptors created to target VMware ESXi servers and virtual machines, it is rare to see ones created for FreeBSD. The only other ransomware operation known to have created FreeBSD encryptors is the now-defunct Hive ransomware operation, which was disrupted by the FBI in 2023.
This week, researchers from cybersecurity firm Trend Micro shared on X that they found an additional sample of the FreeBSD ELF encryptor [VirusTotal] and a sample of the operation's Windows encryptor [VirusTotal].
Trend Micro further said that the threat actors likely created a FreeBSD encryptor as the operating system is commonly used in critical infrastructure, where attacks can cause widespread disruption.
"Interlock targets FreeBSD as it's widely utilized in servers and critical infrastructure. Attackers can disrupt vital services, demand hefty ransoms, and coerce victims into paying," explains Trend Micro.
It goes without saying that the Interlock ransomware operation is not linked to the cryptocurrency token of the same name.
The Interlock ransomware
While BleepingComputer could not get the FreeBSD encryptor working, the Windows version ran without a problem on our virtual machine.
According to Trend Micro, the Windows encryptor will clear Windows event logs, and if self-deletion is enabled, will use a DLL to delete the main binary using rundll32.exe.
When encrypting files, the ransomware will append the .interlock extension to all encrypted file names, and create a ransom note in each folder.

Source: BleepingComputer
This ransom note is named !__README__!.txt and briefly describes what happened to the victim's files, makes threats, and links to the Tor negotiation and data leak sites.

Source: BleepingComputer
Each victim has a unique "Company ID" that is used along with an email address to register on the threat actor's Tor negotiation site. Like many other recent ransomware operations, the victim-facing negotiation site just includes a chat system that can be used to communicate with the threat actors.

Source: BleepingComputer
When conducting attacks, Interlock will breach a corporate network and steal data from servers while spreading laterally to other devices. When done, the threat actors deploy the ransomware to encrypt all of the files on the network.
The stolen data is used as part of a double-extortion attack, where the threat actors threaten to publicly leak it if a ransom is not paid.

Source: BleepingComputer
BleepingComputer has learned that the ransomware operation demands ransoms ranging from hundreds of thousands of dollars to millions, depending on the size of the organization.
Break down IAM silos like Bitpanda, KnowBe4, and PathAI
Broken IAM isn't just an IT problem - the impact ripples across your whole business.
This practical guide covers why traditional IAM practices fail to keep up with modern demands, examples of what "good" IAM looks like, and a simple checklist for building a scalable strategy.





Comments
ZeroYourHero - 1 year ago
They will fail. Never attack anything less than 33% of the total.
h_b_s - 1 year ago
Apparently a highly targeted attack. FreeBSD does have good backwards binary compatibility, but it's not installed for any given version of FreeBSD by default. Each release version has its own compatibility library for user space that has to be deliberately installed from Ports. It won't run on anything newer without the proper compatibility support installed. So it makes sense that if this is built for v. 10.4 then they're deliberately targeting an installation of version 10.4. Version 10.4 was officially EOL in 2017. Any organization's infrastructure still using this version without being properly internally supported by someone that knows what they're doing is practically criminally negligent at this point.
... assuming the file utility returned a valid response. It sometimes makes mistakes.
daschr - 1 year ago
Took a look at the binary, they seem to compile the ransomware for each victim. The routine which encrypts the files generates a new random key every time for each file and stores the encrypted (using a public RSA key) file's key at the beginning of the encrypted version of the file. The public RSA key used for key encryption is embedded statically inside the binary. And the "Company ID" too. Seems like the attacker will provide the private RSA key to decrypt each key of the encrypted files. Since the embedded public key is not generated at runtime of the binary, the attacker must compile the ransomware for each target. I wont be suprised if the attacker compiles the binary on the victim machine itself, this way, the binary is built for the specific machine of the victim (library version, ABI version etc.). Which guarantees that the ransomware will work. And I also wont be surprised if the attacker derives the private RSA key from the "Company ID".
Screenshots for reference:
https://ibb.co/PFMQzHP
https://ibb.co/2M77mkh
https://ibb.co/b7mnSb8
https://ibb.co/QDnP264
https://ibb.co/6XCQtbQ
h_b_s - 1 year ago
This appears to make a lot more sense. The BSDs require more environment matching if you're trying to get as many on the hook as possible. Packages built for 10.x won't work for 11.x or 14.x without the compatibility libraries which aren't going to be there by default. For OpenBSD (not a target, but as an example) you have to recompile plus make sure your program actually still complies with whatever the current version allows. They're constantly tightening or adjusting features and system calls every release. Point being, you can't mix and match like you can with Windows and Linux where the user space ABI tends to remain somewhat stable across versions.