Over the past 30 days, we have seen a surge of Excel4 Macro (XLM) malware in our feeds, and on the 25th of January, there were quite a few detections from XF/Kryptik.B.gen!Camelot.
The existence of short-lived malware attacks have dated back to as early as 2009, which includes the use of time-limited malware and one-day web sites to either evade detection or overload security solutions. This particular surge of malware shown in the graph above is a good example of how threat actors still use this method in their campaigns to go under the radar and evade being detected after a specific number of days.
The use of short-lived malware mostly targets security solutions that leverage sand-boxing to identify the malicious intent of incoming files,
We begin our investigation from one of the samples in our most recent feed being detected by XF/Kryptik.B.gen!Camelot, with the SHA256 hash of 1f3276354d4d7c2e2ed474f89f52134f92da9cb358c62bd7602d568614a9469d.
Opening the sample with Microsoft Excel show the following characteristics of a malicious Excel workbook:
- The first sheet already shows tell-tale signs of suspicious characteristics, mostly asking the user to enable the execution of macro content
- It does contain auto-executable Excel4 Macro formula as shown below:
- The Excel4 Macro is suspiciously encrypted
Running the code as-is appears to show that the code is not working properly, so in order to check why it doesn’t execute, we check all the named cells and find out how they are used.
The sheet containing the Auto_Open formula cell appears to contain the decryption part, and simply looking at the code does not show any readable strings. When this happens, we usually look into the other sheets and check for named cells, apparently, the first cell containing the suspicious prompt does contain named cells as shown below, and the named cell OFfZUHoU contains a string which appears to be a cipher of some sort:
One of the named cells in the first sheet shows a clue why the code is not running properly:
Basically, the code makes use of the current date as part of its decryption routine, so it makes sense that the code doesn’t work off the bat. So how do we know which date is supposed to work? The answer lies in the time when the Excel worksheet was created, which can be extracted from the sample using olemeta as the create_time property.
To check whether this works, we simply set the system date and time to Jan 28, 2021, and run the Excel4 macro again.
And indeed that code did execute properly this time, but after a few seconds, a message box prompts an error and the Excel application is closed after.
This piqued my curiosity to figure out how to extract the malicious code, and it’s surprisingly doable with a few lines of code.
There are three Excel4 macro functions that can solve this problem, namely:
- and FCLOSE
In cell $D$68 on the macro sheet, it shows the following code, which simply sets the value of cell $D$78 with the decrypted strings:
On cell $D$80, you will find the code which executes the decrypted string stored in $D$78 as a FORMULA
Given the above info, we can then insert our own code to dump the value of the formula string from cell $D$78 into a file.
Below are the lines of code to be inserted into the second sheet:
- At the Auto_Open cell, which in this case is blank, we insert:
=SET.VALUE($A$91, FOPEN("C:dump.log", 3))
- On cell just before the formula is executed ($D$79 in this case), insert:
- On cell $D$105, we replace the HALT() formula with
- And lastly, add =HALT() on cell $D106
The updated Excel4 macro should look like this:
Set the date back to January 28, 2021, and enable the macro.
If our injected code works, you will find a file in C:dump.log which should contain the decrypted malware code as shown below:
In this case, the malicious code attempts to download a DLL executable from a remote PHP page, which is then registered as a service and also drops.
Before proceeding it displays a fake alert message to trick the user into thinking that the workbook is corrupted, then closes the Excel application so the user will not be able to see the decrypted Excel4 macro.
It also drops and executes a VBS script at C:UsersPublicDocuments, which performs the same malicious behavior as the Excel4 macro code.
Unfortunately, the payload download links already redirect to google.com, which means that the PHP server is possibly employing either GeoIP filtering or a date triggered response.
The use of short-lived malware and malicious web sites have existed and have been taken leverage of by threat actors dating back to more than ten (10) years ago, this only proves that the re-appropriation of old methods and techniques in malware campaigns will continue to be seen the current and future threat landscape. Such method mostly takes advantage of time constraints to prevent security solutions using sandboxing technologies to identify malicious behavior, having a security solution that includes a good malware detection engine will greatly help block such threats from wreaking havoc on your systems. It is very important to protect your systems during these times where livelihood highly depend on online activities and transactions.
Indicators of Compromise
|1f3276354d4d7c2e2ed474f89f52134f92da9cb358c62bd7602d568614a9469d||Malicious Excel Workbook||XF/Kryptik.B.gen!Camelot|
|hxxps://fiberswatch.com/kk.php||Payload download link|