ralvarez
Staff
Staff

Introduction

 

In early March CERT-UA identified a spear-phishing campaign targeting government organizations within Ukraine that results in the deployment of the open-source backdoor ‘MicroBackdoor’. CERT-UA attributed this campaign to UAC-0051/UNC1151/Ghostwriter suspected to be aligned with the Belarusian government. The campaign starts with a .zip file entitled ‘reference.zip’ which contains a Microsoft Compiled HTML Help file (.chm) named ‘dovidka.chm’ (translates to ‘help’ in Bulgarian). This help file serves as the first stage loader that gradually unpacks and executes a MicroBackdoor payload giving the adversary remote access to a victim endpoint. The attack chain from this help file has a number of layers which are visualized in Figure 1 below.

 

Whilst the spear-phishing campaign analyzed in this article did target Ukrainian victims this analysis aims to provide insight into the TTPs employed rather than focus on the targeting and strategic outcomes associated with this campaign. The TTPs combine a simple phish based execution method chained with the use of an open-source backdoor, TTPs that could easily be repurposed by any threat actor with even a low level of technical skill.

 

This article describes the attack chain as well as a more technical dive into the various layers of VBScript that lead to the execution of the MicroBackdoor payload, and see how FortiEDR protects endpoints from this malware.

 

Attack Chain

 

microbackdoor01.png

Figure 1. UNC1151 MicroBackdoor attack chain

 

Initial Execution

 

As outlined above the attack chain starts with an email containing a zip file. Contained within the zip file is a single Microsoft Compiled HTML help file (.chm). Files of this type contain a number of internal resources stored in a compressed HTML format. The hosting process for execution of the .chm file by default is Microsoft® HTML Help Executable or ‘hh.exe’ which resides at ‘C:\Windows\hh.exe’ by default. This HTML Help Executable is a signed Microsoft binary and the use of this executable for proxy execution is tracked by MITRE as ‘T1218.001 – System Binary Proxy Execution: Compiled HTML File’. Figure 2 below shows the files embedded in the chm document. From the list of the files, focus on the 'file.htm' that contains the initial stage VBScript that will execute when the file is opened.

microbackdoor02.png

Figure 2. files within the chm file

 

Once the sample .chm file (dovidka.chm) is opened, the hosting hh.exe process will write and display the decoy document ‘image.jpg’ in a help window as shown in Figure 2 below. The decoy document contains information relating to ‘Information on the procedure for frequent artillery shelling’ and contains various Ukraine government insignia.

 

microbackdoor03.png

 Figure 3. Displayed decoy document/image displayed when opening the chm file. Note the image is shown as part of a default help window.

 

The ‘file.htm’ contains obfuscated VBScript that generates a second stage VBScript file named ‘ignit.vbs’ and drops it to ‘C:\Users\Public’ folder. The figure below (Figure 4) shows some of the obfuscated VBScript within the ‘file.htm’. The first function defined in the VBScript (‘oollllo1l0’) is the first stage decryptor for the rest of the code.

 

microbackdoor04.png

 Figure 4. VBScript contained within the ‘file.htm’ file embedded within the ‘dovidka.chm’ compiled help file. The first function seen in this sample is the first stage decryptor (‘oollllo1l0’).

 

Running the decryptor function produces the more readable VBScript code shown in Figure 5 below. The VBScript checks for a file ‘C:\Users\Public\Favourites\desktop.ini’ and if present it drops the second stage VBScript file, ‘ignit.vbs’, and executes it along with the VBScript within the previously mentioned ‘desktop.ini’ file.

 

microbackdoor05.png

Figure 5. Decrypted version of the first stage VBScript contained within the ‘file.htm’ file embedded within the ‘dovidka.chm’ compiled help file. Note the calls to execute the ‘ignit.vbs’ and ‘desktop.ini’ files.

 

Second stage VBscript - ignit.vbs

 

The second stage VBScript contains several functions, and most of them are used to decrypt/Deobfuscate embedded executables and additional VBScript payloads. A sample of the VBScript contained in the ‘ignit.vbs’ file is shown below in Figure 6.

 

microbackdoor06.png

 Figure 6. VBScript excerpt taken from the ‘ignit.vbs’ file dropped following execution of ‘dovidka.chm’. Note the reversed string path outlining one of the files it will write on execution

 

On execution this second stage VBScript, ‘ignit.vbs’ generates and drops the following files: 'c:\UsErs\pUbLIc\LIbRARiES\core.dll', '(Startup folder)\Windows Prefetch.lNk' and 'C:\usErs\puBLIC\fAVORIteS\desktop.ini'. Execution of this VBScript file is detected by FortiEDR as a ‘Suspicious Script Execution’ event despite its proxy execution from the signed ‘hh.exe’ executable. This detection would prevent the second stage ‘ignit.vbs’ script from executing and writing its embedded payloads to disk. A snapshot of the related FortiEDR security event is shown below in Figure 7.

 

microbackdoor07a.png

 microbackdoor07b.png

Figure 7. FortiEDR detects anomalous ‘ignit.vbs’ VBScript execution. This activity would be blocked in ‘Protect’ mode preventing this attack from progressing.

 

MicroBackdoor Loader – core.dll

 

The first file generated and dropped from ‘ignit.vbs’ is ‘c:\UsErs\pUbLIc\LIbRARiES\core.dll’, which is a .NET binary that acts as a loader for the final MicroBackdoor payload. This loader is created from 5 char arrays within the ‘ignit.vbs’ script which are decoded by the ‘RvsJvhGamf5XD’ function shown below in Figure 8.

 

microbackdoor08.png

 Figure 8. Internal function within the ‘ignit.vbs’ file that reconstructs and drops the ‘core.dll’ executable in the ‘c:\UsErs\pUbLIc\LIbRARiES\’ directory.

 

The core.dll is a .NET executable that contains an encrypted copy of the client-side code for MicroBackdoor containing a hardcoded C2 domain. When the core.dll is executed, it decrypts the embedded MicroBackdoor payload and reflectively loads it in memory and directly executes it. The encrypted payload can be seen in Figure 9 below stored as various resources within the core.dll executable.

 

microbackdoor09.png

Figure 9. Partial code from the ‘core.dll’ .NET executable showing parts of the encrypted MicroBackdoor payload that is decrypted, loaded and executed at runtime.

 

MicroBackdoor is an open source backdoor written by Dmytro Oleksiuk aka ‘Cr4sh’. The open source project (https://github.com/Cr4sh/MicroBackdoor) has both client and server components readily available on GitHub. The unmapped executable loaded by core.dll is the same as the sample client.dll code available through the projects main GitHub page. The figures below show similar code from the unmapped executable loaded by core.dll and the MicroBackdoor’s original client.dll taken from its GitHub page. Figure 10 shows a call to gethostbyname and inet_addr APIs to get the internet address of the C2 server, ‘xbeta[.]online’. Figure 11 shows the actual connections to ‘xbeta[.]online’ using the equivalent IP address (194[.]195.211.98).

microbackdoor10.png

 Figure 10. Code comparison between the unmapped executable loaded by core.dll and the original MicroBackdoor client.dll

 

microbackdoor11.png

Figure 11. Another code comparison between the unmapped executable loaded by core.dll and the original MicroBackdoor client.dll.

 

Third stage VBScript – desktop.ini

 

Another file generated and dropped by ‘ignit.vbs’ is ‘C:\usErs\puBLIC\fAVORIteS\desktop.ini’. This file contains a third VBScript that is eventually used to execute the microbackdoor, ‘core.dll’. The desktop.ini VBScript executes the core.dll file through the Assembly Registration tool (regasm.exe), another Windows binary used for proxy execution, this time for .NET executables (tracked by MITRE as T1218.009 – System Binary Proxy Execution: Regsvcs/Regasm). Figure 12 below shows the functions within ‘ignit.vbs’ that generate the ‘desktop.ini’ file, while Figure 13 shows the content of ‘desktop.ini’ that eventually calls regasm.exe.

 

microbackdoor12.png

 Figure 12. Code within ‘ignit.vbs’ that decodes and creates the third stage VBScript ‘desktop.ini’.

 

microbackdoor13.png

Figure 13. Content of the ‘desktop.ini’ file showing instructions to execute core.dll.

 

FortiEDR detects and blocks the execution of the third stage VBScript, ‘desktop.ini’, as shown in Figure 14 below.

 

microbackdoor14a.png

 microbackdoor14b.png

Figure 14. FortiEDR security events generated as a result of ‘desktop.ini’ VBScript execution. This behavior will be detected and blocked by FortiEDR out of the box (default policies).

 

As highlighted above ‘Desktop.ini’, executes regasm.exe to run ‘core.dll’, the MicroBackdoor loader. FortiEDR detects and blocks this proxy execution of the ‘core.dll’ .NET executable from the wscript process as a ‘Suspicious Script Execution’ event, as shown in Figure 15 below.

 

microbackdoor15a.png

 microbackdoor15b.png

 Figure 15. ForitEDR detects ‘regasm.exe’ proxy execution from wscript. This behavior will be detected and blocked by FortiEDR out of the box (default policies).

 

Following successful loading of the MicroBackdoor client into the regasm host process, the MicroBackdoor attempts to connect to its C2 server for command and control. The MicroBackdoor sample analysed in this article contained a single hardcoded domain ‘xbeta[.]online’ as its C2. FortiEDR detects and blocks the unmapped MicroBackdoor client’s attempts establish a network connection to this C2 domain as shown in Figure 16 below.

 

microbackdoor16a.png

 microbackdoor16b.png

 Figure 16. FortiEDR security event related to the unmapped executable (MicroBackdoor ‘regasm.exe’ execution triggered by the VBscript connecting to the C2 server

 

The ‘xbeta[.]online’ domain currently resolves to the IP address ‘194[.]195.211.98’. The IP address will likely be different from the time of the writing of this article as it has already changed numerous times since being first reported by CERT-UA.

 

FortiGuard’s Central Threat System (CTS) shows that ‘xbeta[.]online’ is related to Ghostwriter/UNC1151, as shown in the figure below.

 

microbackdoor17.png

Figure 17. CTS showing FortiGuard threat intelligence related to the ‘xbeta[.]online’ domain.

 

Fourth stage – ‘Windows Prefetch.lNk’

 

The third stage VBscript, ‘desktop.ini’, is executed via ‘Windows Prefetch.lNk’ shortcut file, which was dropped in the Windows StartUp folder. This is a form of persistence tracked by MITRE as T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder’. Whenever the computer restarts, the executables and shortcut links found in the Startup folder will be executed.

 

Looking back at Figure 5 it can be seen that when the original chm file executes the initial VBScript, it will trigger the execution of the last stage VBScript, ‘desktop.ini’. After this initial execution, the placement of 'Windows Prefetch.lNk' in the Windows StartUp folder will ensure the backdoor is restarted when the victim endpoint is rebooted.

 

Figure 18 below shows the functions that generate the ‘Windows Prefetch.lNk’.

 

microbackdoor18.png

 Figure 18. VBScript within ‘ignit.vbs’ that generates and drops ‘Windows Prefetch.lNk’ in the Windows StartUp directory for persistence.

 

The figure below shows the use of the lnk file target field to execute the VBScript contained in the ‘desktop.ini’ file. In recent months this technique has grown in popularity being employed as a part of new Bumblebee and Emotet campaigns across the globe. It is expected that the prevalence of this TTP being used to execute payloads will continue to grow and may become the primary execution methods for phishing campaigns as Microsoft moves to block macro execution by default in Windows 11.

 

microbackdoor19.png

 Figure 19. Properties of ‘Windows Prefetch.lNk’ file used for persistence as part of this campaign. Notice the ‘Target’ field contains instructions to execute the contents of the 'desktop.ini' as VBScript.

 

Threat Hunting

To search for creation of the second stage VBscript, 'ignit.vbs':

Type: ("File Create") AND Target.File.Path: ("Users\\Public") AND Target.File.Name: ("ignit.vbs")

To search for creation of the third stage VBscript, “desktop.ini”:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe") AND Target.File.Path: ("Users\\Public\\Favorites") AND Target.File.Name: ("desktop.ini")

To search for creation of the microbackdoor, “core.dll”:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe") AND Target.File.Path: ("Users\\Public\\Libraries") AND Target.File.Name: ("core.dll")

To search for creation of 'Windows Prefetch.lNk' in the StartUp folder:

Type: ("File Create") AND Source.Process.Name: ("wscript.exe")  AND Target.File.Path: ("Startup") AND Target.File.Name: ("Windows Prefetch.lNk")

To search for hh.exe spawning wscript.exe to execute desktop.ini:

Type: ("Process Creation") AND Source.Process.Name: ("hh.exe") AND Target.Process.File.Name: ("wscript.exe") AND Target.Process.CommandLine: ("\/\/B \/\/E\:vbs C\:\\Users\\Public\\Favorites\\desktop.ini")

To search for hh.exe spawning wscript.exe to execute desktop.ini or any vbs file:

Type: ("Process Creation") AND Source.Process.Name: ("hh.exe") AND Target.Process.File.Name: ("wscript.exe")

To search for hh.exe creating vbs or img files (ignit.vbs or image.jpg):

Type: ("File Create") AND Source.Process.Name: ("hh.exe") AND Target.File.Ext:("vbs" or "jpg")

To search for connection to the C2 server:

Type: ("Socket Connect") AND Source.Process.Name: ("RegAsm.exe") AND Source.Process.CommandLine: ("\/U C\:\\Users\\Public\\Libraries\\core.dll") AND RemoteIP: ("194.195.211.98")

To search for loading “core.dll” library using regasm.exe:

Type: ("Library Loaded") AND Source.Process.Name: ("RegAsm.exe") AND Source.Process.CommandLine: ("\/U C\:\\Users\\Public\\Libraries\\core.dll") AND Target.Executable.File.Name: ("core.dll") AND Target.Executable.File.Path: ("Users\\Public\\Libraries")

To search for regasm.exe spawning conhost.exe to execute core.dll:

Type: ("Process Creation") AND Source.Process.Name: ("RegAsm.exe") AND Target.Process.File.Name: ("conhost.exe") AND Source.Process.CommandLine: ("\/U C\:\\Users\\Public\\Libraries\\core.dll")

 

MITRE ATT&CK

 

TA0001 – Initial Access

Technique ID

Technique Description

Observed Activity

T1566

Phishing

Phishing email is the initial access method employed as part of this campaign. Phishing email was related to safety information associated with ‘artillery strikes’ and contained a .zip file containing malicious VBScript embedded within a .chm file.

 

TA0002 - Execution

Technique ID

Technique Description

Observed Activity

T1059.005

Command and Scripting Interpreter: Visual Basic

The malware uses three stages of VBScript execution.

 

TA0003 - Persistence

Technique ID

Technique Description

Observed Activity

T1547.001

Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder

The malware drops ‘Windows Prefetch.lNk’ to the Windows Startup folder.

 

Technique ID

Technique Description

Observed Activity

T1547.009

Boot or Logon Autostart Execution: Shortcut Modification

The malware drops ‘Windows Prefetch.lNk’ to the Windows Startup folder. This lnk file executes the ‘desktop.ini’ file which then executes core.dll with regasm.exe.

 

TA0005 - Defense Evasion

Technique ID

Technique Description

Observed Activity

T1027

Obfuscated Files or Information

The malware has obfuscated VBScripts. The VBScripts has obsfuscated code to hide the actual content of the files to be dropped as ‘desktop.ini’, ‘core.dll’, and ‘Windows Prefetch.lNk’.

 

Technique ID

Technique Description

Observed Activity

T1218.009

System Binary Proxy Execution: Regsvcs/Regasm

The malware use Regasm to run Microbackdoor’s loader, core.dll.

 

Technique ID

Technique Description

Observed Activity

T1218.001

System Binary Proxy Execution: Compiled HTML File

The malware arrived as zip file that contains the malicious chm file. This file is executed through hh.exe, standard Windows binary.

 

Technique ID

Technique Description

Observed Activity

T1620

Reflective Code Loading

Core.dll loads the Microbackdoor main code in memory within the hosting regasm.exe process without a corresponding file mapped to disk.

 

TA0011 – Command and Control

Technique ID

Technique Description

Observed Activity

T1071.001

Application Layer Protocol: Web Protocols

MicroBackdoor attempts to connect to C2 domain through web requests.

 

IOCs

 

Indicator Description

Indicator

Indicator Type

Associated Tactic

Notes

dovidka.zip

11f8ff086184c60b8d4e7d15ea458014cbbd349d

SHA1 Hash

Initial Access

Zip file containing malicious .chm file

dovidka.chm

affc2b19d9fb8080a7211c3ed0718f2c3d3887df

SHA1 Hash

Execution

Malicious chm file

core.dll

491214cc496f4a358856801d0381eb4926c07c59

SHA1 Hash

Execution

MicroBackdoor loader

Windows Prefetch.lNk

679e8f21c473a0551ff828e164a7ae3e26ca9d2a

SHA1 Hash

Execution

Shortcut file that runs desktop.ini

desktop.ini

50fe3b38324258ede2a1fd41f8cc78f12158a3e1

SHA1 Hash

Execution

Runs the core.dll using regasm.exe

C2 server

xbeta[.]online

Domain

Command and Control

Hardcoded C2 domain

C2 server

194[.]195.211.98

IP address

Command and Control

IP address associated with malicious domain at time of analysis

Contributors