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
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.
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.
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.
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.
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.
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.
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.
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.
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).
Figure 10. Code comparison between the unmapped executable loaded by core.dll and the original MicroBackdoor client.dll
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.
Figure 12. Code within ‘ignit.vbs’ that decodes and creates the third stage VBScript ‘desktop.ini’.
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.
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.
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.
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.
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’.
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.
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':
|
To search for creation of the third stage VBscript, “desktop.ini”:
|
To search for creation of the microbackdoor, “core.dll”:
|
To search for creation of 'Windows Prefetch.lNk' in the StartUp folder:
|
To search for hh.exe spawning wscript.exe to execute desktop.ini:
|
To search for hh.exe spawning wscript.exe to execute desktop.ini or any vbs file:
|
To search for hh.exe creating vbs or img files (ignit.vbs or image.jpg):
|
To search for connection to the C2 server:
|
To search for loading “core.dll” library using regasm.exe:
|
To search for regasm.exe spawning conhost.exe to execute 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 |
