It’s surprising to see how quickly attackers make use of new vulnerabilities in malware campaigns. Microsoft recently patched a very interesting vulnerability in their monthly Patch Tuesday update for January 2020. It’s a spoofing vulnerability in Windows CryptoAPI (Crypt32.dll) validation mechanism for Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed certificate to sign a malicious executable, making it appear as if the file was from a trusted, legitimate source. The end-user would have no way of knowing the file was malicious. As almost all users and many security vendors rely on the Digital Certificates of executable files to validate the genuineness and authenticity of files, this vulnerability poses a big threat to the basic trust mechanism itself. This vulnerability is being referred as “Curveball” and “Chain of Fools”.
While we were just pondering around this vulnerability, we came across ransomware – HorseDeal leveraging this vulnerability and making use of a spoofed ECC certificate to evade detections.
While HorseDeal pretends to be signed by Microsoft ECC TS Root Certificate Authority 2018, it has the publisher name of a genuine AV-vendor. The certificate is valid for 1 year starting from 16 Jan 2020.
Filename used here is that of the AV vendor’s process name i.e. avgdiagex.exe. Even though in this scenario, the spoofed certificate is used for fake AV process, malware authors can spoof certificate of any other genuine software, including software published by Microsoft itself.
Fig. 1: Spoofed ECC Certificate
Behavior:
As of now, the infection vector for this ransomware is not known. The main payload is packed with the UPX-3.94 packer. Upon execution, the payload first queries for the Language ID of machine using GetUserDefaultLangID() API. The retrieved Language ID is then compared with multiple languages to identify the country of the victim. These IDs include: Kazakh (0x043F), Belarusian (0x0423), Kyrgyz (0x0440), Tatar (0x0444), Azerbaijani (0x082C), Armenian (0x042B), Tajik (0x0428).
Once confirmed that the victim is not from any of the above locations, it deletes shadow copies from the system. This directly or indirectly indicates the possibility of malware authors having nationality in this region. Similar tactics were previously seen in other ransomware to exclude these regions along with Syria and other countries. Using bcdedit, the payload disables the automatic repair feature and sets bootstatus policy to ignore errors if there is any failure in the boot process. Along with that, it turns off the firewall using netsh advfirewall. These steps confirm that the victim won’t be able to recover the system state using any internal windows tools.
Fig. 2: Turn Off Recovery And Protection
After this, the payload tries to check for particular processes running on the victim machine. It retrieves information about running processes using CreateToolhelp32Snapshot(). The process names are then cross-checked with process list in payload, and if the process found, it is supposed to terminate that process. Here, it is using lstrcmpiw() API to compare these names. But mistakenly, HorseDeal authors have put space i.e. 0x20 to separate strings in buffers instead of using 0x00(null byte for string termination). So, every-time each process is compared with the whole buffer of strings, it always fails even if the current process name is in the buffer.
Fig. 3: Process Name Compare
Processes To Be Terminated Include:
Fig. 4: Process Name List
After this, an RSA key-pair is generated locally using MS crypto-API CryptGenKey().
Fig. 5: CryptGenKey RSA
The payload itself carries another base64 encoded RSA key within itself. Locally generated RSA private key is encrypted in 0x200 bytes buffer using this key. Again, the initial 0x5F bytes of this encrypted key are encrypted one more time with the same public key in another 0x200 bytes buffer.
Both the buffers are then encoded using base64 encoding and are written into file _uninstalling_.png at directory %AppData%\Roaming. This data in the file is then appended with previously locally generated RSA Key.
Fig. 6: _uninstalling_.png RSA key
The Ransom note is written in #Decryption#.txt. An image named 7F58.tmp.jpg is dropped at directory %AppData%\Local\Temp. This image is used as desktop wallpaper using API SystemParametersInfoW() with the first parameter as SPI_SETDESKWALLPAPER.
After execution payload deletes itself using command “/c timeout 1 && del \”C:\\Users\\Test\\Desktop\\avgdiagex.exe\” >> NUL”.
File Encryption:
For each logical drive, a separate thread for encryption is created. The files are encrypted using the Salsa algorithm for faster encryption. The Salsa key is different for each encrypted file. 0x24 Bytes are generated using CryptGenRandom(). The first 0x20 bytes are used as a Salsa key. Only initial 0x2800 bytes of file data are encrypted with Salsa. After encrypted data, a dword encryption marker DEC0ADD3 is inserted.
The randomly generated 0x24 bytes are then encrypted with local RSA public key and are appended to encrypted files after the encryption marker.
Fig. 7: File Encryption
Ransom Note:
Fig. 8: Ransom Note
Unlike other ransomware, HorseDeal uses jabber and ICQ for communication. The instructions to use jabber are also included in the ransom note. No ransom amount and wallets are mentioned in the ransom note. The unique ID mentioned in the ransom note is actually the base64 encoded encrypted RSA private key which was previously written to _uninstalling_.png.
Conclusion:
As expected, within a very short period after disclosure of critical vulnerability CVE-2020-0601, malware authors started exploiting it aggressively before users patch their systems. Having a genuine name and valid trust certificate, the user is likely to allow these files to execute. Though it was yet another ransomware with no extravagant behavior, the use of this critical vulnerability, “CurveBall” has made it special.
IOC:
716C502BA250F742FC935B3CB223CA4A
Preventive Measures:
No Comments, Be The First!