Application Security , Breach Notification , Critical Infrastructure Security
MosesStaff Attacks Israeli Government, Other OrganizationsGroup Uses Ransomware-Like Encryption Attack, Makes No Ransom Demand
Politically motivated hacker group MosesStaff has been targeting Israeli organizations with encryption attacks since September, according to researchers.
See Also: Live Webinar | Education Cybersecurity Best Practices: Devices, Ransomware, Budgets and Resources
The attackers state their primary motivate for the targeted campaigns "is to cause damage by leaking the stolen sensitive data and encrypting the victim networks, with no ransom demand," according to Check Point Research.
As the ongoing attacks do not leverage zero-day vulnerabilities, "potential victims can protect themselves by immediately patching all publicly facing systems," the researchers say.
While the researchers did not specify the victims, archived records from Monday, accessed by Information Security Media Group, show that at least 16 Israeli organizations - including the Israel Post, the Ministry of Defense, Israeli Intelligence Corps Unit 8200, Matitiahu Bruchim law office, and private organizations, such as Epsilor and David Engineers, that are associated with Israeli government projects - have been targeted by the MosesStaff threat group.
The group also claims to have cumulatively attacked more than 172 servers and 257 websites and successfully captured more than 34 terabytes worth of data, according to the statistics on the homepage of its website.
The group tweets details of its latest victims on @moses_staff_se. The account was created in October and the first tweet, posted on Oct. 21, mentions Israeli oppression and seeking revenge.
The currently active account posted its latest tweet on Sunday, saying that it had successfully penetrated the cyber infrastructure of the Israeli government and exfiltrated 22 terabytes worth of 3D maps with an accuracy of up to 5 centimeters.
We’ve been able to penetrate cyber infrastructure of the criminal Zionist government and found 22 terabyte 3D photos of all Israel areas taken by themselves to an accuracy of 5cm.— Moses Staff (@moses_staff_se) November 14, 2021
For more information, visit our website and Telegram channel. pic.twitter.com/2ncDKZ0bNH
The group also has a dedicated Telegram channel, according to the tweets and archived weblinks accessed by ISMG.
Decoding the Malwares
The group achieves initial access to victim networks by exploiting known vulnerabilities in external-facing infrastructure such as Microsoft Exchange Servers, the researchers note.
The researchers did not respond to ISMG's request seeking further details on the vulnerabilities exploited.
The webshell used in the initial infection is obfuscated, but is based on one of the freely available webshells in GitHub, the researchers say.
After successful intrusion, the attackers collect information on the machines in the network and combine it into a victim information list, they say, adding, "This contains a domain name, machine names, and administrator credentials that are later used to compile a specially-crafted PyDCrypt malware."
The PyDCrypt malware is an executable written in Python and compiled with PyInstaller with encryption. It is usually run from the C:UsersPubliccsrss.exe path and is responsible for replicating itself inside the network with Powershell, PSExec, or WMIC and then supporting the proper execution of the main encryption payload DCSrv, the researchers note.
DCSrv is the main customized payload that masquerades as a legitimate svchost.exe process and has only one motive: "to encrypt all computer volumes, and deny any access to the computer," they say.
This malware has a three-part execution flow that includes driver installation, volume encryption and boot loader installation, as shown in the above image. During driver installation, two services, named DCUMSrv and DCDrv, are created. The former provides a persistence mechanism on startups, while the latter runs the supplied filter driver DCDrv.sys, which further deploys the encryption, according to the researchers.
"When the malware installs the driver, it performs a reboot after a few minutes to make the driver operational," they say. "On the second run, the malware waits for the exact time given in the configuration before it detonates its encryption mechanism. This is yet another proof that the payloads are targeted and created per victim."
This core encryption mechanism is based on the DiskCryptor open-source library, which allows volume encryption "and lock[s] the victims' computers with a bootloader that won't allow the machines to boot without the correct password,” according to the researchers.
Established threat actors, including the Conti, REvil and LockBit ransomware gangs, always ensure "their encryption system is well-designed and unassailable. However, for whatever reasons, including non-financial motivation, lack of experience with ransomware, or amateur coding skills, the MosesStaff group didn’t make as much of an effort," the researchers say.
The research describes two methods of decryption:
- The first decryption method involves looking up EDR product logs. These logs record all process creations together with their command line parameters. This will show whether the malware is installed in the environment or not, and will also act as the key to decrypting it, the researchers note.
The second method involves reverse-engineering the PyDCrypt malware, and it is a bit difficult to execute as the malware deletes the code after finishing its run, the researchers say. But if it is successful, they add, it enables extraction of the crafted hashing function that generates the keys per computer.
To help decode the malware, the researchers provided a PyDCrypt payload decryption script in their report.
"By using the extracted keys from each of these methods, we can insert them into the boot login screen, and unlock the computer," the researchers say. "This way, we can restore access to the operating system, but the disks remain encrypted and the DiskCryptor boot loader is active on every restart. This can be solved by creating a simple program that initiates proper IOCTL (input/output control) to the DiskCryptor driver, and eventually, removes it from the system."