Quick analysis of the Sepsis ransomware

This quick analysis presents the main features and elements regarding the ransomware Septis. I will not explain exactly how it was cracked, because nobody wants to help a ransomware author to fix his vile creation. There are, however, enough elements to guide any further analysis by curious minds to reach the core of its vulnerability.

Sample: Virusbay

Generic malware elements

This is by no means a sophisticated malware, as it lacks any sort of obfuscation or anti-analysis feature. It copies itself as a fake svchost.exe, and uses the registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell to achieve persistence. To scan for files to encrypt a new thread is created for each logical drive that is found. Each of these characteristics are slightly different, depending on the elevation of the process:

  • Normal: copy inside Temp directory, use the HKEY_CURRENT_USER key hive, avoid encrypting “Program Files” and “Program Files (x86)”
  • Elevated: copy inside Windows directory, use the HKEY_LOCAL_MACHINE key give, do not avoid those directories

File encryption

The encryption algorithm of choice is AES-128 in CBC mode. The only peculiar aspect of this ransowmare is that it uses a custom implementation of the algorithm. Here we have one of (the many) errors that are present in the malware: the generate key (see later) is of 0x20 bytes, but instead of using it completely in a AES-256 algorithm, only the first 0x10 bytes are used.

VM directory

The most typical way of accessing files in ransomware is via the ReadFile and WriteFile functions. Sepsis instead employs file mapping. This is the root cause of another error, and the most damaging one for the victim’s files. NOTE: remember that AES works on blocks of 16 bytes. The file mapping is created with the same size of the original file; in the case of a file size that is not a multiple of 16, the last block is truncated when written back to the disk. This makes it impossible, even with the correct key, to recover the last bytes. Unfortunately errors regarding final bytes and padding are way too common in low-tier ransomware.

Key generation

At 0x401EF0 we find the key generation function that creates the AES key and IV. First, generate_string is called twice to generate the two strings of 0x20 and 0x10 bytes respectively. The key and the IV are then concatenated and encrypted with an hardcoded public RSA key. In this case the Windows Crypto API is used.

VM directory

Finally, the encrypted buffer is Base64 encoded, resulting in a string that is appended at the end of each encrypted file.

generate_string

The string generation function is really simple. The string is built from three sets of characters, lowercase alphabet, uppercase alphabet and a subset of symbols. The default MSVCRT implementation of rand is used to create a random choice between the three sets, and then a second time to choose a specific character in the selected set.

VM directory

Before starting with the string generation, rand is seeded via srand in an “unorthodox” way; for example, the seed is computed using the address of a stack variable instead of its value. Here is a C version of the function:

void generate_string(int size, char* buffer) {
	int value;
	int seed;
	int i;
	uint choice;
	char c;
	char low[] = "abcdefghijklmnopqrstuvwxyz";
	char upp[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
	char sym[] = "!@#$%^&*()-=+.,:;?";

	seed = &value + 4 * (rand() % 0xc6aea155);
	srand(seed);

	for (i = 0; i < size; i++) {
		choice = rand() % 0x64;
		if (choice > 0x32)
			c = low[rand() % 26];
		else if (choice - 0x15 > 0x1d)
			c = sym[i % 18];
		else 
			c = upp[i % 26];

		buffer[i] = c;
	}
}

This is a cleaned up version, as in the malware fnction there are also some calls to rand and one to malloc that are actually never used.

Conclusion

It is clear that this was the work of an amateur developer, but that is not a conforting thought, because even with such low level of skill the author can cause considerable damage - even irreparable damage, as for problem with the last bytes. As always, thanks to demonslay335 for the cooperation on developing the decrypter for this ransomware.

Written on June 23, 2018