Mert SARICA
The DDE-based phishing attacks that started in 2017 have been replaced by Microsoft Excel 4.0 Macro (XLM) phishing attacks as of 2020. A little research would show that XLM macros have been introduced to the world since 1992, with the release of Microsoft Excel 4.0. VBA macros, which are frequently misused by threat actors, were first introduced with Excel 5.0 and are still supported in the latest version of Microsoft Office.
If my memory serves me correctly, the first technical article I read about XLM macros was this blog post from Outflank. As research on XLM macros started to reveal their existence, it began to attract attention not only from offensive security experts but also from threat actors. Soon enough, organizations began to experience phishing attacks that contained XLM macros. Due to the difficulty of detecting and analyzing XLM macros as compared to VBA macros, it is not an easy task.
The difficulty in analyzing an Office file containing XLM macros, as I stated in my blog post titled “Microsoft Office Macro Analysis“, is caused by the fact that they cannot be easily viewed from the Microsoft Office interface. As a result, the possibility of malicious XLM macro-containing Office files going unnoticed by inexperienced cybersecurity professionals (such as “This Office file is corrupted” or “Does not contain macros”) increases. In order to show cybersecurity analysts how XLM macro-containing Microsoft Office files can be analyzed and to raise awareness about XLM macro-containing Microsoft Office files, I decided to write a blog post based on a real-life incident.
In May 2020, alarms began to be generated for many SMTP IP addresses from which hundreds of emails with sender addresses ending in @wp.pl were sent and blocked by security systems. Upon inspection, the emails had attachments with XLS extension, Excel files that have been randomly named. In such cases, one of the most important steps for cybersecurity analysts to take is to identify the addresses of the command and control centers in the malicious document, search for them in web traffic records, and block access throughout the organization.
Of course, when the issue at hand is an Office file containing XLM macros, it’s possible that static and dynamic analysis performed by sandbox systems may be insufficient in the face of anti-sandbox techniques (e.g. Sandbox Detection). If the malicious Excel file in question is designed to detect when it is running in a sandbox, then the address of the command and control center will not be revealed during these analyses (VirusTotal, Hybrid-Analysis). In this case, the cybersecurity analyst’s job should be to take the malicious Excel file, copy it to a virtual system created for the purpose of malware analysis, and analyze it there.
When running the Excel file in a virtual system, we are presented with two pages (Sheet1 and Sheet2). The first page contains a fake image/message indicating that we need to activate the macro to achieve its malicious intent, while the second page shows empty cells (which are not actually empty). Although Excel may warn us that there is a macro in the file, when we view the macro, it appears to be empty.
This kind of macro-based attack often called “Fileless attack” or “Living-off-the-land attack” because it doesn’t involve in injecting code into the system or download any malicious file. Instead, it makes use of the system’s legitimate tools in order to perform its malicious action, thus it’s harder to detect.
When opening the file with any hex editor and looking at the character strings contained within, we can see that, as suspected from the Excel 4.0 Macros series, it contains XLM macros. To be sure that the file contains a macro, when we analyzed the file with the mraptor tool, we could see that the file had a cell named Auto_Open, which was capable of running automatically, similar to the AutoOpen() function in a VBA macro. To learn the name of the cell and view and analyze it, I used Didier STEVENS‘ oledump tool. And by using (oledump.py -p plugin_biff.py –pluginoptions “-o LABEL -s” C:\Users\Mert\Desktop\ea74b9a274c0c73cad990ddd089927b6.xls) I found that the cell that was first run was named Auto_OpencfitK. This is a clever technique used by the malware developer to evade detection. Knowing that an analyst would use Go To (CTRL-G) in Excel to go to the cell named Auto_Open to start the analysis, the developer changed the name of the cell to Auto_OpencfitK
After we found out that the initial cell was an obfuscated macro consisting of 42 FORMULA statements and CHAR functions throughout the file, analyzing and solving each one of them one by one would have taken a significant amount of time. So I decided to proceed with debugging. By going to the Auto_OpencfitK cell and pressing ALT + F8, I then pressed the Step Into button, and Excel prompted me to allow the macro to run and then close and re-open the file. As soon as the file was opened, Excel quickly moved to the Auto_OpencfitK cell. To avoid missing this step, I changed the formula =SET.VALUE(FG22029, -490-GET.CELL(17,HX17320)) in that cell to =HALT() and this caused the macro to end. After this, I changed the =HALT() formula to =SET.VALUE(FG22029, -490-GET.CELL(17,HX17320)) and then by pressing the ALT + F8 on the cell, I was able to dynamically analyze the macro from the initial cell without any issues.
As I continued analyzing by using Step Into and Evaluate buttons, and decoding the hidden cells, I saw that the macro uses various controls against debugging and sandbox environments by using Excel 4.0 Macro Functions Reference document. When I reached the AT41104 cell, which is performing the debugging control, to bypass this control, I copied the =GOTO(AY23948) value in the next cell where it would continue if debugging is not detected.
=IF(GET.WORKSPACE(31),GOTO(HV23758),) Is the macro in debugging mode? (Anti-debugging)
=IF(GET.WORKSPACE(19),,GOTO(HV23758),) Is a mouse present on the system? (Anti-sandbox)
=IF(GET.WORKSPACE(42),,GOTO(HV23758),) Can the system play sound? (Anti-sandbox)
These statements or functions checks whether macro is running in a sandbox environment or on a real machine or if it’s in debugging mode.It also try to detect other anti-sandbox evasions like Mouse or sound. These checks used by malware developer to avoid detection, and prevent the macro from running when it’s running in an environment that the attacker doesn’t want it to run in.
As I continued debugging, I noticed that the macro attempts to connect to https://docs.microsoft.com/en-us/officeupdates/office-msi-non-security-updates to check for internet connection and stops running if it encounters an error. I also observed that macro checks for permission for macro usage via registry, After that it try to contact with https://dehabadi[.]ir/wp-keys[.]php and https://eleventalents[.]com/wp-keys[.]php. Although these addresses were not active during my analysis, my research led me to suspect that these addresses are command and control servers associated with the Zloader malware. Even though I couldn’t continue my analysis, my aim was reached successfully by revealing these addresses.
With this explanation you have a basic understanding of the subject matter, now you can use a tool such as XLMMacroDeobfuscator to quickly solve the hidden XLM macro and save time. With this article I hope to provide insight for analysts who want to analyze XLM macros.
Hope to see you in the following articles.
Note: For those looking for more resources on XLM macro analysis, I recommend looking at these articles (#1, #2, #3, #4, #5) as well. These articles will give more information about the analysis of XLM macros and methods that you can use.
Mert SARICA
