The ACCDFISA malware family – Ransomware targeting Windows servers

A few weeks ago our colleagues over at BleepingComputer approached us asking for help with a recent malware outbreak that specifically targets Windows servers. Several companies as well as individuals found their servers being locked by a malware that claims to originate from the “Anti Cyber Crime Department of Federal Internet Security Agency” or short “ACCDFISA”. Of course such an institution does not exist and even if it did, it surely wouldn’t ask the owner of the server to submit a certain dollar amount using PaySafeCard or MoneyPak codes. The affected servers fell prey to a new malware family that is currently on the loose.

The ACCDFISA malware family belongs to a malware category called “ransomware”. Ransomware is a special kind of malware that takes a system and its data hostage in an attempt to extort money from its owner in exchange for returning control back to him. What makes the ACCDFISA family special is the unorthodox way in which systems get infected as well as how various third party tools are used to accomplish the malware family’s goals.

How are systems infected?

Unlike most malware nowadays, ACCDFISA does not use drive-by or social engineering attacks to infect a system. It is instead installed manually by the attacker himself. The attacker targets Windows systems running the Remote Desktop or Terminal Services, which is usually the case for remotely maintained Windows servers. Based on traces found on some of the infected machines, the attacker is using a tool called “DUBrute” to find systems running either of the aforementioned services. The tool will then go ahead and launch a dictionary based brute force attack on those systems. Based on log files of infected systems it seems the following user accounts are attacked:

If the brute force attack is successful and a set of valid user credentials is found, the attacker will remote log in into the system where he will then download and execute the malware. Due to the fact that the attacker uses a regular remote desktop connection, installed anti-virus or anti-malware software may prove to be ineffective as the attacker can just disable the software or allow the malware to run in case a warning message pops up.

Commonalities across all ACCDFISA variants

We received the very first ACCDFISA sample on February 23. Since then there have been at least 3 new major variants of the malware. Those variants differ slightly in the ways passwords are generated and certain behaviors are implemented. File, service and application names used by the different variants changed as well.

Example for an ACCDFISA WinRAR SFX setup script. Taken from the ACCDFISA variant 3 dropper.

All variants are written in Pure Basic and are installed using a 2-stage installer. Stage 1 consists of a WinRAR SFX archive with a little WinRAR setup script that will unpack the malware files to predetermined locations inside the 32bit Windows system directory (C:\Windows\System32 or C:\Windows\SysWOW64). The second stage is triggered by the WinRAR setup script and executes the various malware components with special command line parameters which will cause the malware components to copy themselves to their intended locations and install themselves properly.

The ACCDFISA malware itself can usually be split into three major parts:

A screen locker that will display the ransom notice to the user and locks the user out from using the system.

A crypto malware that is installed as a service and that deletes backups and encrypts files found on the system.

A decryption tool that the user is supposed to use to decrypt the data on the system after he paid the ransom.

All ACCDFISA variants use various third party tools like WinRAR, sdelete, NoSafeMode or netsh to implement some of the their functionality.

Screen locker

The code used to create and switch to a new desktop as used by ACCDFISA screen locker.

The screen locker used by the ACCDFISA family is rather simple. It uses the following registry auto start entry to ensure its execution on each reboot:

Once executed it essentially creates and switches over to a new desktop, where it displays its ransom notice. This will effectively prevent the user from using the system, unless he puts in the correct unlock code, which will cause the screen locker to switch back to the real desktop and terminate.

Crypto malware

Example code of the crypto malware service installation routine. Taken from the fourth variant.

The crypto malware is implemented as a Windows service. The names and descriptions used to register the service vary from variant to variant. The malicious service will search all connected drives for files that it will either delete or move to encrypted RAR archives using the command line version of WinRAR.

To determine which files to delete the malware uses the following rules:

Check if the file path contains the following string. If it does, do not delete the file:

bootsect

Check if the file path contains any these strings. If it does, delete the file:

backup, recycle.bin, temp

Check if the file name ends in any of these extensions. If it does, delete the file:

The malware maintains a list of all files it moved to encrypted RAR archives. The exact name of the list varies from variant to variant.

After the first encryption run is finished the malware will cause the system to reboot.

Decryption tool

An example for an ACCDFISA decryption tool. This was taken from the third ACCDFISA variant which uses two different passwords.

The decryption tool will use the list of encrypted files generated by the crypto malware to unpack all encrypted files, assuming the user provided the correct password. To run the decryption tool, the user needs to execute one of the many short cuts labeled “how to decrypt aes files” or “how to decrypt files” that are placed in various locations by the crypto malware. Since the encrypted files are essentially encrypted RAR archives we recommend to use WinRAR or 7-zip to unpack the encrypted files instead of using the decryption tool.

Variant 1 – “ACCDFISA Protection Program”

Screen locker used in the first ACCDFISA variant.

The first variant was first seen on February 23. The name used by this variant is “ACCDFISA Protection Program”. The following files and services found on a system are an indication that your system is infected with this variant:

C:\ProgramData\local\aescrypter.exe (command line WinRAR)

C:\ProgramData\local\crdfoftrs.dll

C:\ProgramData\local\svchost.exe (screen locker)

C:\ProgramData\local\undxkpwvlk.dll

C:\ProgramData\local\vpkswnhisp.dll

C:\Decrypt\Decrypt.exe (decryption tool)

%system%\csrsstub.exe (screen locker)

%system%\dcomcnfgui.exe (crypto malware, installed as a service called “WdiServiceSysHost”)

%system%\tcpsvcss.exe (decryption tool)

%system%\tracerpts.exe (command line WinRAR)

%system%\ucsvcsh.exe (network disabler, installed as a service called “netprofms”)

%system%\wcmtstcsys.sss (encrypted files list)

Encrypted files will have the “.aes” extension. Files are encrypted using the static password “1a2vn57b348741t92451sst0a391ba72”, so you should be able to unpack all files using this as a password. The unlock code used by the screen locker is static as well. It is “7534919801679213”.

The routine used by the first ACCDFISA variant to delete the SafeBoot registry key. It uses the Windows "reg" utility to do its dirty work.

This variant deletes the SafeBoot registry key located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ to prevent the user from booting the system into safemode.

Variant 2 – “Malware Protection”

Screen locker used in the second ACCDFISA variant.

This variant was first seen on March 12. The name it uses is “Malware Protection”. Unlike variant 1 that deleted the SafeBoot registry key this and all other future variants use the tool “NoSafeMode” to prevent the user from booting into safe mode. Safe mode can be unlocked using NoSafeMode and the code “Yrs5S2z1”. The following files and services found on a system are an indication that a system is infected with this variant:

C:\decrypt lock\decrypt.exe (decryption tool)

C:\security lock\svchost.exe (screen locker)

C:\ProgramData\system files\vpkswnhisp.dll

C:\ProgramData\mssupport\aes256crypter.exe (command line WinRAR)

%system%\csrss32.exe (screen locker)

%system%\csrss64.exe (decryption tool)

%system%\svschost.exe (Crypter, installed as a service called “ProfSvcs”)

%system%\nsf.exe (NoSafeMode)

%system%\NoSafeMode.dll (NoSafeMode)

%system%\cfwin32.dll (command line WinRAR)

%system%\unsvmklrtszs.vvv (encrypted files list)

Like in the first variant, encrypted files will have the “.aes” extension.

Part of the substitution cipher routine used in the second ACCDFISA variant to convert the numeric system id to a password string.

Unlike the first variant though, the password for the encrypted files and the screen locker are no longer static. They are now generated based on the boot drive’s volume id. A small tool to generate both the decryption password as well as the unlock code is available for download.

Variant 3 – “Malware Protection” the second

Screen locker used in the third ACCDFISA variant.

The third variant uses the same name as the second variant. It was first seen on March 25. The following files and services found on a system are an indication that the system is infected with this variant:

%desktop%\rvid1000.txt (system id and numeric string used for password generation)

%system%\cfwin32.dll (command line WinRAR)

%system%\csrss32.dll (screen locker)

%system%\csrss64.dll (decryption tool)

%system%\default2.sfx (custom WinRAR SFX stub)

%system%\NoSafeMode.dll (NoSafeMode)

%system%\nsf.exe (NoSafeMode)

%system%\svschost.exe (crypto malware, installed as a service called “fdPHosts”)

%system%\uwnmspwks.rrr (Encrypted files list)

This code fragment shows how the third ACCDFISA variant assembles and executes the exact command line used to add files into the self-extracting and encrypted RAR archives.

Variant 3 is the first variant that uses self-extracting RAR archives with a custom WinRAR SFX stub instead of RAR archives with a custom extension (“.aes”). Encrypted files are named using the following scheme:

Beside the transition from RAR archives to RAR SFX archives, the password generation has changed significantly as well. Up to this point passwords were either static or could be generated based on certain system parameters. Starting with this variant, ACCDFISA uses randomly generated passwords instead. On its first execution the crypto malware will randomly generate a numeric string. The generated string is consequently stored inside “rvid1000.txt” as well as “msdadiags.dll” for future executions to ensure that consecutive runs use the same string. It is used in combination with a substitution cipher and a static password prefix to generate the actual encryption password. So unless the numeric string is available, it is almost impossible to reconstruct the password.

This fact is exploited by the attacker. After the initial infection the attacker will transfer both files containing the numeric string off the system. This will cause the crypto malware to generate and use a new numeric string on its next execution. As a result the files on the system will be encrypted using two different passwords. Files that existed at the time of infection are encrypted using the password that was generated with the first numeric string, which was moved off the system by the attacker. Files that were added to the system later are encrypted using the password that was generated with the second numeric string, which stays on the system. Since the second numeric id stays available on the system, it is possible to recover the second encryption password. In order to recover the first encryption password though, it is necessary to recover the deleted “rvid1000.txt” or “msdadiags.dll” file.

The screen locker unlock code is generated differently as well. The code to unlock the system is essentially “5352341682” followed by the displayed ID. If the displayed ID is for example 117675559 the password to unlock the system would be “5352341682117675559”.

Variant 4 – “Anti-Child Porn Spam Protection”

Screen locker used in the fourth ACCDFISA variant.

The newest ACCDFISA variant was seen first on April 8. The name changed again to “Anti-Child Porn Spam Protection”. The following files and services found on a system are an indication that the system is infected with this variant:

c:\dvsdlk\svchost.exe (screen locker)

c:\ProgramData\rbnedwdels\svchost.exe (sdelete)

c:\ProgramData\sgcvsap\svchost.exe (command line WinRAR)

c:\ProgramData\tcvedwdcv\ghzsrwhbfg.dlls

c:\ProgramData\tcvedwdcv\udsjaqsksw.dlls (stores part of the first password)

c:\ProgramData\thcgds\dkpslqhnsoa.dll

c:\ProgramData\thcgds\dkpslqhnsoa2.dll

c:\ProgramData\thcgds\retcgvxcvuwszs.dll

c:\ProgramData\thcgds\rspivswszxc.dll (encrypted files list)

c:\ultimatedecrypter\dc.exe (decryption tool)

%desktop%\fvd31234.txt (stores system id and part of the first password)

%desktop%\fvd31234.bat (batch script to securely delete fvd31234.txt)

%system%\cfwin32.dll (command line WinRAR)

%system%\csrss32.dll (screen locker)

%system%\csrss64.dll (decryption tool)

%system%\default2.sfx (custom WinRAR SFX stub)

%system%\NoSafeMode.dll (NoSafeMode)

%system%\nsf.exe (NoSafeMode)

%system%\sdelete.dll (sdelete)

%system%\svschost.exe (crypto malware, installed as a service called “fdPHosts”)

%system%\bfsdrtsdsqsd.dll (encrypted files list)

Like in variant 3 encrypted files are stored in self-extracting RAR archives. The naming scheme used for encrypted files is almost identical to the one used by variant 3 as well. Only the email address was updated to reflect the changed contact mail address:

The biggest change in this variant is the usage of Sysinternals’ “sdelete” tool instead of the “DeleteFile” Windows API to delete files. With older variants it was possible to recover some of the deleted unencrypted files or the files storing the numeric ids using undelete tools like Recuva. This is now no longer feasible.

This routine is used to generate the first password used by the fourth ACCDFISA variant.

Password generation changed again as well. Similar to variant 3 two different passwords are used to encrypt the files on the system. To generate the first password the crypto malware will generate a 50 character long random string. The string is then saved to fvd31234.txt as well as udsjaqsksw.dlls. The random string is than prefixed with a static string to create the first password. As usual the fvd31234.txt file is copied by the attacker to his system and then securely deleted using the fvd31234.bat script. On the next boot the service will securely delete “udsjaqsksw.dlls” as well if still present and fall back to a second password generation algorithm. The second algorithm will calculate the second password based on the boot drive’s volume id, similar to variant 2. While it is possible to generate the second password with ease, it is almost impossible to recover the first password due to the random nature and secure deletion.

The screen locker unlock code is generated exactly like in variant 3 with the exception that the static prefix is now “7234745624”. So if the displayed id is 117675559 the unlock code would be “7234745624117675559”.

Last but not least, the malware changes the ClearPageFileAtShutdown registry value to cause Windows to clear the page file on shutdown eliminating all traces that might be left due to disk swapping.

How can systems be protected from this kind of malware?

Due to the nature of the attack protection software is rather ineffective. If the attacker manages to get access to the system via remote control, he can simply disable any protection software installed or add the malware to the protection software’s exclusion list. It therefore is imperative to prevent the attacker from gaining access to the system to begin with.

The most important line of defense is a proper password policy that is enforced for all user accounts with remote access to the system. This does apply to rarely used accounts created for testing purposes or by applications as well.

Even better would be to disable Remote Desktop or Terminal Services completely if not required or at least to use IP address based restrictions to allow the access to these services from trusted networks only.

Although there is no hard evidence that suggests the recently found Remote Desktop Protocol vulnerability was ever used to compromise a system, we suggest to make sure you have patch KB2621440 installed as well.