Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Definition of 'overkill' - using 130 MB executable to hide 24 kB malware

Published: 2020-08-14
Last Updated: 2020-08-14 06:46:03 UTC
by Jan Kopriva (Version: 1)
1 comment(s)

One of our readers, Lukas, shared an unusual malicious executable with us earlier this week – one that was 130 MB in size. Making executables extremely large is not an uncommon technique among malware authors[1], as it allows them to easily avoid detection by most AV solutions, since the size of files which AVs will check is usually fairly low (tens of megabytes at most). In order to increase the size of their creations, malware authors commonly embed images in the executables or include large chunks of “empty space” (i.e. null bytes) in them.

Authors of our executable, which turned out to be a Visual Basic .NET application originally called cvcv.exe, decided to use both techniques. They embedded 54 GIFs (or rather one GIF, which you may see bellow, with a healthy 1.12 MB size 54 times) among resources of the application and added more than 75 MB of null bytes after the end of the executable.

If all of this unnecessarily filled space was freed, the 130 MB executable would be just over 260 kB in size. The story doesn’t end there though.

.NET malware can sometimes be quite unpleasant and difficult to analyze, but after a while, it became clear that our executable only used elementary name obfuscation so it wasn’t too hard to get to the bottom of what it was supposed to do. The entire massive file turned out to be a simple injector for a second stage payload - another VB .NET executable, originally called j.exe, with a much smaller size of 24 kB.

This second executable was embedded (in an encrypted form) as another resource in the original EXE. After the massive application was executed, it would wait for 35 seconds, decrypt the second executable/payload using a simple XOR-based algorithm and then launch it.

The smaller executable turned out to surprisingly be a bit more complex then the large one. After it was executed, it would first ensure that the malware remained persistent. Doubly – it would copy the original massive file to the Start Menu Startup folder as “77e41643eabac0c55a13f8b8e793e845.exe” and to the AppData folder as “jossej.exe”. It would also create a new value in registry (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) which would ensure that the latter file was executed at startup as well. It would then run the jossej executable which would reconfigure internet security zones and add an allow rule for itself to the Windows firewall.

The malicious process would then try to contact a server at the (DDNS) domain lexy[.]hopto[.]org.

The domain was inaccessible by the time of the analysis, so we can’t be completely sure what communication would follow. Going by the contents of the executable however, it would seem that the malware is supposed to function mainly as an infostealer/keylogger.

This would more or less agree with the results for the sample on Virus Total, as according to it, most AVs seem to detect the file as a version of Razy Trojan[2].

The following chart shows a summary of the main activities performed by the malware. As we may see, it is nowhere near as complex as it could have been for a 130 MB executable.


Indicators of Compromise (IoCs)

cvcv.exe / jossej.exe / 77e41643eabac0c55a13f8b8e793e845.exe (130 MB)
MD5 - f1c3d28ebaf180367591fa5d31e3febf
SHA1 - b1cfa019684fcd293eeca557aa523312837ea37d

j.exe (24 kB)
MD5 - 9690a3f2a3d0f84244d41e4aefae0a16
SHA1 - 4631ba4467eee1380f0e847c4f56dddbaed7196c



Jan Kopriva
Alef Nula

1 comment(s)
Diary Archives