Category Archives: Ransomware

Recovering custom hashes for the Petya/Notpetya malware

During our malware analysis, we often come across samples that contain (custom) hashes in stead of cleartext. Hashing is done in an effort to bypass detection and hinder malware analysts. There are tools to recover cleartext from known hashing methods (like John the Ripper and hashcat). But for custom hashing methods, you’ll have to write some code. In this blog post, we illustrate a method to recover the custom hashes of a non-croptygraphic hashing method used by malware to obfuscate its behavior.

The Petya/Notpetya malware contains code to check which processes are running on a victim machine, and change its behavior accordingly. Microsoft has explained this in detail, with the custom hashing function and hash values to identify processes, however without reporting the process names the malware looks for.

At NVISO, we like to share knowledge and this blog post is no different. We will explain you how we recovered the process names, so that you can use this method in your own malware analysis endeavors.

The names of the processes are not hardcoded in the malware code, but a custom hash function is used to identify the processes of interest:

The custom hash function clears bits in variable v10 if process names that match custom hash values 0x2E214B44, 0x6403527E and 0x651B3005 are found.

A (cryptographic) hash function is not reversible, so we will need to figure out another way to match these hashes with actual process names. Cracking hashes is done with dictionary and brute force attacks: a trial and error method where the hash function is used with input values from the dictionary/brute-force generator until a matching hash is found. Remark that this custom hash function is not a cryptographic hash function and that the hash value is 4 bytes long, so many collisions will be found when brute forcing.

We suspected that the process names of interest are security related: antivirus software, firewalls, … Meterpreter has a killav function that contains a list of process names of security software.  We used this list in our dictionary attack.

Next step is to write a program to perform the attack. Because execution speed could be crucial, we wrote it in C. We took the decompiled custom hash function source code and modified it a bit to be compiled with Visual Studio:

void ConfigCheckProcesses(_TCHAR* processname)
{
unsigned int v0; // ebx@3
unsigned int v1; // kr00_4@3
unsigned int v2; // edx@4
unsigned int v3; // esi@5
char *v4; // ecx@6
char v5; // al@6
int v9; // [esp+230h] [ebp-8h]@3
int v10; // [esp+234h] [ebp-4h]@1

v10 = -1;
v9 = 0x12345678;
v0 = 0;
v1 = _tcslen(processname);
do
{
v2 = 0;
if (v1)
{
v3 = v0;
do
{
v4 = (char *)&v9 + (v3 & 3);
v5 = (*v4 ^ LOBYTE(processname[v2++])) - 1;
++v3;
*v4 = v5;
} while (v2 < v1);
}
++v0;
} while (v0 < 3);
if (v9 == 0x2E214B44)
{
_tprintf_s(TEXT("0x2E214B44: %s\n"), processname);
}
else if (v9 == 0x6403527E)
{
_tprintf_s(TEXT("0x6403527E: %s\n"), processname);
}
else if (v9 == 0x651B3005)
{
_tprintf_s(TEXT("0x651B3005: %s\n"), processname);
}
}

While performing a dictionary attack with our customized hash function and Meterpreter’s list as dictionary, we recovered one hash: 0x2E214B44 is avp.exe (Kaspersky). When we searched Twitter for avp.exe, we found one interesting tweet. We looked at this person other tweets to see if they had recovered the other hashes, unfortunately they did not.

So the next step was to perform a brute-force attack. We generated process names with characters a-z, A-Z (the custom hash function is case sensitive), 0-9 and . – _ and assumed the extension would be .exe.
Here is the result:

Hash 0x651B3005 is NS.exe (Norton Security). That left us with hash 0x6403527E to recover. Since these two hashes are used to clear the same bit, we assumed that the processes might somehow be related. Googling for process names related to NS.exe, we came upon different process names for Norton and Symantec software. A short dictionary attack with these names revealed that 0x6403527E is ccSvcHst.exe (Symantec).

Conclusion

When you have a decompiler available to recover the source code of custom hash functions, one can quickly transform that source code in a working program to perform dictionary attacks and (small) brute force attacks. Larger brute force attacks will require more complex code to speed up the recovery process: multi-threaded code or code that uses GPUs.

Wcry ransomware – Additional analysis

Introduction
Since May 12, a large number of organisations has fallen victim to the “wcry” (or “Wanacry”) ransomware, which abuses the SMB exploits / vulnerabilities that were famously released in the Shadow Brokers data dump in April 2017. Our aim in this short blog post is not to repeat existing information, but communicate some additional information that was derived by our NVISO CERT.

Note that our analysis is still ongoing and we will update our post with additional information, our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be.

In short, the ransomware appears to initially enter the environment by traditional phishing (or via systems exposing SMB to the Internet), after which it leverages aforementioned SMB RCE (Remote Code Execution) vulnerabilities (MS17-010) to spread in the network like wildfire. The combination of “standard” ransomware with a recent remote code execution exploit make for a very effective attack, which is evidenced by the impact it has caused on a global scale.

On 13 May, it was reported that wcry, before starting its encryption process, attempts to connect to a seemingly random domain name (www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com) (EDIT: On May 15th, a second kill-switch domain was found in a new sample: www[.]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com).

If these domains can be contacted, the malware stops its operations. This is most likely a kill-switch that was built in, but not effectively used, as the domain name had not been registered by the attackers. It has been registered by security researches in the meantime, hindering the ransomware’s advance. Note that the kill-switch is not proxy aware and is thus ineffective in environments where a proxy is used to access the Internet (NVISO’s analyst Didier Stevens published a quick-post on the killswitch here).

For additional background information, the following articles & blog post provide a good description of the observed wcry activity:

The main recommendations to prevent / limit the impact of wcry:

  • Ensure Microsoft’s patch (MS17-010) is rolled out throughout your organisation (also in the internal network) to prevent the spread of the malware using the SMB exploit;
  • If you cannot install the patch timely, TearSt0pper (developed by Rendition InfoSec) can be deployed to prevent the encryption from taking place;
  • Ensure Windows SMB services (typically TCP port 445) are not directly exposed to the Internet;
  • Implement network segmentation between different trust zones in the network;
  • Ensure recent back-ups are available offline and can be easily restored;
  • Upon infection: isolate any infected hosts from the network;
  • Continue end-user awareness to prevent the initial compromise through phishing;
  • Implement mail sandboxing solutions to block incoming malicious mail attachments.

Additional analysis
Throughout the weekend, our analysts further investigated the attack, noticing only 2 known variants of the “wcry” ransomware were uploaded from Belgium on VirusTotal. Given the global scale of the attack, this is a surprisingly low number of hits.

From an analyst perspective, the malware does not take big efforts to obfuscate itself and a simple static analysis (e.g. looking for strings) comes up with a large number of strings that could be used in YARA rules:

  • The ransomware manual language files that are dropped: (*.wnry)
  • It uses icacls to change permissions, using the following hard-coded command: “icacls . /grant Everyone:F /T /C /Q
  • Unicode string in the executable “WanaCrypt0r”
  • The ransomware creates a Windows registry value to ensure persistence (survival upon reboot). We observed different variants of this behaviour, 2 examples are below:

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v obsbeuqp321″ /t REG_SZ /d “\”C:\WINDOWS\system32\tasksche.exe\”” /f

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v “mzaiifkxcyb819” /t REG_SZ /d “\”C:\tasksche.exe\”” /f

Note the creation of the “taschsche.exe” executable, which is different from the normal “taschsche.exe” (part of Windows).

Update 1

As stated, on networks where a proxy is the only way to access the Internet (e.g. corporate networks), the killswitch will not work because the code is not proxy aware. This means that the malware will attempt to resolve the killswitch domain name with internal DNS, and if it receives a DNS reply with an IP address, it will proceed with an HTTP request. It will not connect to the proxy.

Corporations are configuring internal DNS with the killswitch domain name and an internal sinkhole as mitigation. This prevents the sample from activating, provided that the sinkhole server sends a reply.

The reply can be a 404, that will work too. It can even be a single character x send via the TCP connection, that is fine too. But something has to be replied, just opening the connection and closing it, without sending anything to the malware, will result in activation of the malware.

FYI: this was tested via dynamic analysis with sample 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec and with our own custom code simulating the killswitch test in the malware.

Our analysis is still ongoing and we will update our post with additional information, as our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be. We would be happy to help!