This week I’ve had to do another malware analysis, again with a phising email as entry vector. Due to in my personal malware analysis lab I don’t have Outlook and the malware was attached in a .msg, first of all I had to looking for the way to extract it. To do that, I found the script msg-extractor which I was able to use in the Windows machine. The files extracted was two .ace compressed files that had two identical PE Windows executables but with different name. Despite the fact that the analysis was deep, I was not able to know exactly what the malware do but different things could be determined:

Both executables are written in Visual Basic 5.0 or Visual Basic 6.0 and no presence of packers that could obfuscate their code is detected (neither by the result thrown by PeID nor judging by the comparison of sizes between the raw size and the virtual size):

As it can be checked, the executable has GUI interface but no form was shown:

I was able to get the images stored in the .rsrc section, but they were not be relevant for the analysis. The executable has a compilation date of 10/25/2017, which I can not corroborate whether it is real or not (it would be interesting to compare it with the date of the message in which it came). What can be concluded is that both executables had as their internal name at the time of execution “Udskriftskommandoernes1.exe” (I have not found references on Internet about it):

Both executables are signed by DigiCert certificate and that was very important to get the first, and unique, IOC. They were able to be extracted with disitool.py (included in Remnux) and openssl tools:

disitool.py extract Consignee\ Details.exe consignee-sig.der
openssl pkcs7 -inform DER -print_certs -text -in consignee-sig.der > consignee-sig.txt

Looking at the certificate, the rsa public key (both 2048 and 4096 bits) is present inside of the binary, more specifically as from 0047ae0 memory direction:

And I´ve used that hexadecimal strings to do a Yara rule for detection purposes (which works really fine XD).

rule DHL_CCG_malware
{
	meta:
		author="Alvaro Trigo"
		description="Yara rule for DHL malware detection"
	strings:
		$cert_2048_consignee_hex = { 00 F8 D3 B3 1C 7F 0E 11 AF 67 77 07 D3 0B 31 }
		$cert_4096_consignee_hex = { 00 BA E2 11 62 42 F6 28 91 98 E8 73 69 CA 7C }
		$cert_2048_dhlairbill_hex = { 00 AD 0E 15 CE E4 43 80 5C B1 87 F3 B7 60 F9 }
	condition:
		$cert_2048_consignee_hex or $cert_4096_consignee_hex or $cert_2048_dhlairbill_hex
}

Once the malware is executed, it does a computer scanning looking for different services, specially FTP and .ini config files. It seems to create some DLL files in different directory locations, but this was not able to be corroborated. This behaviour is tipical in spyware family (recover information to do further malicious actions):

When this scanning process finish, the malware creates and executes a random numeric .bat file in %APPDATA%\Local\Temp directory for just few seconds. The most frustrate thing of this analysis was the capture and posterior analysis of that .bat file. I´ve tried to recover it manually and hooking the proccess, but it was impossible.

Regarding to persistance characteristics of the malware, I´ve not found any indicator of that (registry Windows keys was not be modified with this purpose). Other registry keys, with relationship with IE8, was be modified and alert me about capture network IOC. Specially “UNCAsIntranet” and “AutoDetect” keys changed their values during malware execution and, according to official Windows documentation, these two registry keys are involved in the start proccess of IE8:

For that reasons, I sniffed web traffic in order to know whether the binary tried to do some internet connections. Only I could detect a HTTP connection to ocsp.digicert.com domain (with american IP) but this probably not be a malicious behaviour and the binary just want to check if their certificate is revocated or not. Just indicate that ocsp.digicert.com domain is categorized in some web sites as a possible spyware, but in my opinion that assumption is incorrect.

In short, it can not be determined 100% that it is a spyware, although both the manual analysis and the results obtained by VirusTotal seems to indicate this. The binaries have a high detection rate and thanks to the fact that it is signed by a DigiCert certificate, it has been possible to generate a rule in Yara for its detection. Both executables seem written in Visual Basic 5.0 or 6.0 and do not use registry keys to gain persistence. At the level of indicators, when executing the binary it generates a bat file in% APPDATA% \ Local \ Temp that could not be captured for further analysis. Regarding to network level, the executable does a GET to an IP in the US but we can not determine exactly if it is legitimate or not (probably the executable try to check its certificate status).