In this post we will go through the macro code for the excel file that was used to bait users into downloading and dropping the malware payload. The macros (ThisWB, Module1) that we extracted earlier appear to be obfuscated.
Since this is an excel macro when the user opens this xls file with macros enabled, it drops into function Workbook_Open() in the ThisWB macro.
This function does nothing malicious yet, besides setting a few strings that it extracts from the form within this xls archive.
The form is named ‘firm’ in this instance (there had been multiple files with the same characteristics in these attempts to infect machines with Locky ransomware during early December 2016). As we can see in the form Label1 has caption rundll32.exe and Label3 caption contains “Microsoft.XMLHTTPGRANDAdodb.streaMGRANDshell.ApplicationGRANDWscript.shellGRANDProcessGRANDGeTGRANDTeMPGRANDTypeGRANDopenGRANDwriteGRANDresponseBodyGRANDsavetofileGRAND\shtefans.spe”
Now we can formulate a hypothesis that this macro will load a DLL. The other longer string seems to be delimited by ‘GRAND’. This gives us many keywords that raise a red flag. These strings strongly suggest that this macro will download something and run it. We also see the filename ‘shtefans.spe’ similar to that found earlier in the temp directory of the infected machine. I will leave it to the reader to figure out why I suspect something is being downloaded since it is obvious by the Label3.Caption.
In the above line the variable shtileMurino2 is tokenized with the delimiter we specified and stored in another variable.
Now after all the strings are set in ThisWB macro, the function copyHeader() is called which is located in Module1 file.
Then it does a few redirections to other functions which create objects for shell.Application and Microsoft.XMLHTTP. This had been the consistent obfuscation technique by the author of the code to create objects with the string array taken out from the form at which we looked earlier. These objects would be used to download and run the payload.
delete_empty_entries creates another object for Wscript.shell and calls hub_path function. I mention this function because this contains the URLs that we mentioned in the previous blog post that were accessed for the payload.
However there were a few comments found in the code, they were left there just to add a pinch of confusion.
Eventually it reaches below function where it sets the HTTP request header. Now the header is important here as the author of this code, who may also be hosting the payload at the above URLs would have only allowed to download from the URL if the header is as shown below. In case a user accesses this URL he might find it inaccessible.
The code highlighted in gray is unreachable, again, to put naïve analysts off the track.
The code above is reached eventually which accesses the URL and in case it is inaccessible it errors out and stops. This means in case we don’t have internet connectivity the macro will stop running. It entirely depends on downloading the malware as it is not embedded in the xls.
Without going into much detail, I identified that the payload downloaded from the URL is saved as “C:\Users\REM\AppData\Local\Temp\lodka1” and then transformed to “C:\Users\REM\AppData\Local\Temp\shtefans1.spe” The algorithm for this is given below. For the readers who have any endpoint protection deployed in their organization can use this info to block creation of such files.
The md5 hash of the files are below
shtefans1.spe: 4179155d5c3953f0c3bfe1c41be18538.
loadka1: b83ae1ba2921a54156ce928af7f3b4cd
After running through the above algorithm the downloaded file is executed in the below line.
The above line calls Shell function which translates to command line:
rundll32.exe C:\Users\REM\AppData\Local\Temp\shtefans1.spe,plan 1
This will trigger the encryption. This ends our macro code analysis for Locky Osiris.
Macros are the most common vector for dropping, downloading and executing malwares as they usually come with rife office documents. I tried to cover the important parts of this evil code which was necessary to understand its working. In case, the reader thinks I missed something or went into unnecessary details please feel free to comment.
In the next post we will go into reverse engineering the DLL shtefans1.spe that was dropped and executed by this macro.
Evil Code Analysis 