Important elements of the analysis:

• Use of the Go language
• Enumeration of disks on the infected machine
• Main.wipe function
• Windows\\NTDS destruction
• Environment information discovery and logging
• Use of threads
• Executions of external processes and commands
• Executions of commands to change permissions and accesses

Summary

INTRODUCTION:……………………………….. 1

STATIC ANALYSIS:…………………………..2

DECOMPILING, DEBUGGING AND DYNAMIC ANALYSIS:……………………………24

References:……………………………42

IOCs.:………………………42

YARA Rule:…………………………..42

CONCLUSIONS:…………………………….42

INTRODUCTION:

SwiftSlicer is a new wiper malware, developed by Russian cybercrime groups to attack Ukrainian targets, yet another cyberthreat element that goes hand in hand with the current geopolitical crisis between the two countries. It is evident that these cyber gangs no longer only have as their goal the encryption of victims’ data and the demand of a ransom for their decryption, but also, as was also seen with Hermetic Wiper, the complete destruction of files and system domains of the affected target infrastructures.

SwiftSlicer TTPs Matrix:

STATIC ANALYSIS

In the present analysis, a SwiftSlicer sample with hash fee7c379f3a555c821e872ec384a91 was analysed, developed and compiled with Go 1.15.0, a programming language not very common in malware development.

Here are the details of the entropy of the SwiftSlicer sections:

Below are some details of a disassembling list of the threat, where you can see several INT3 instructions, which can be used in some contexts to arrange anti-debugging through the generation of execution exceptions, but also jump instructions, as well as calls to JE (Jump Equal) and JNE (Jump Not Equal) instructions with the addition of “compare” instructions, to check

Here are some details of the threat memory mapping:

Within the .text and .data sections are precise references to the ID of the Go build used to compile the artifact:

Strings relating to permissions, random generations and sockets routines can be found in the .rdata section:

In the .idata section, there are references to calls for managing virtual memory addresses and writing files via the WriteFile function:

By observing the strings that can be extracted from the threat, it is possible to highlight the presence of disk enumerations of the infected machine:

Among the extracted strings, important symbols can be noted, including for example chmod (which allows access permissions to be managed), bitLen, delete, privileges, threadLock, timersLock and numerous references to the GoLang *os. library, used for example to manage the execution and launch of processes or external DLL libraries. This allows SwiftSlicer to implement multistaging infection type executions.

There are several references to CPU options and statistics, due to the fact that the threat pays attention to multithreaded executions and concurrency:

Below are some details of calls to the GoLang *.runtime library, which can be used to manage and retrieve environment variables and allows interaction with the GoLang runtime system:

Following is a fundamental detail representing how SwiftSlicer performs environment information discovery, in this specific case we can observe the use of the function GetUserProfileDirectory, which allows us to obtain information of the root directory of the user in question:

Following, highlighted, are some strings worth noting: winCallbackKey (called from the runtime library) allows information and details to be obtained concerning the keystrokes recorded on board the compromised machine, as well as the presence of the *exec.Cmd function call, which allows external commands to be executed:

Here are some details referring to zombie processes, which, although potentially terminated, possess PIDs and process control blocks, and evidence calling up the LockFileEx function, which allows exclusive access to files taken over by the source process:

Here is a detail that allows the origin of SwiftSlicer to be associated with Russia, since among the specified timezones is precisely that of Russia:

The runtime library is also used to allocate cached memory within the GoLang execution superstructure:

This is followed by details of calls to the netpoll library, which can be used for network polling tasks, specifically a call to the runtime.pollInfo.expiredWriteDeadLine function, for write operations, is highlighted below.

Here is some evidence inherent to the runtime.isAsyncSafePoint function, which allows us to check whether the current stack conditions and registers might allow asynchronous function calls.

SwiftSlicer makes use of the function runtime.gosched_m in order to place scheduled executions at the point when they reach the callback point in question:

The following are important references to the execution of the threat, where calls to the loading of external system libraries and the execution of processes can be observed, and in particular the function syscall.makeCmdLine allows the setting of process execution command attributes within the infection cycle:

Here we see the use of the syscall library in the contexts of file finding, creation of processes via user instances and enumeration of registry keys:

Following are references to FileMode, which can be used during file enumeration and wiping, as well as the check performed to verify that a specific element is a directory. Here, too, various details on the handling of mutexes and process waiting:

SwiftSlicer calls the function exec.lookExtensions in order to identify executable files within a specific directory, given as a parameter. It also calls the function os.(*Process).kill to terminate processes.

Here are some basic strings inherent to the core of the threat under consideration: the function main.wipe, which deals with the destruction of files and system elements; at the same time, there are references to process tokens, process privileges, including the function main.enableDisableProcessPrivilege, and the enumeration of system drives with main.drives and main.paths:

This is followed by references to executable.go, which returns the path to the executable that launched the current process:

DECOMPILING, DEBUGGING AND DYNAMIC ANALYSIS

Here are the details of the extraction of the most interesting strings from the malicious artifact from the .rdata section, which have already been carried out previously.

Here are the details of references to the chmod and chown commands, which can be used to manage access and permissions to certain files:

Below is evidence of references to WriteBuffers:

Here timers and threads objects:

In the screenshots below you can see references to a Logger object for logging executions, processes, DLLs, directories and file attributes:

Here you can highlight a call to the FindNextFile function, which can be used for file enumeration actions:

Below is a detail referring to user tokens, which can be used for privilege management:

Below is a call to the function *syscall.RawSockaddr, referring to the use of sockets objects for connection routines:

This is followed by the particularities of what appears to be a GoLang configuration and declarations of variables and values, for example the variable “p”, including attributes of maximum and the extension “.exe3125”:

This is followed by a further reference to the performance and indicators of the CPU and zombie processes:

Here the sockets connection functions, such as WSARecv, WSASend, getsockname and getpeername:

SwiftSlicer destroys the contents of Windows\\NTDS, following the reference in question:

Here is a reference to the AddDllDirectory function, which can be used to add a directory to the process DLL search path and references to registry keys usage functions:

Below is a reference to what appears to be a skipping operation of a directory among those enumerated:

A curious detail is a reference to the following figure, which represents a value inherent in algebraic operations of modular exponential, relating to RSA encryption algorithms:

The following highlighted string reference, inherent to MMX support, is related to the GoLang compilation:

This is followed by a further reference to the main.wipe infection function:

By carrying out a static malware inspection session, the following suspicious features can be observed: compilation of timestamps corresponding to Unix year 0 (31 December 1969), network discovery, file management, memory (management of virtual memory addresses and memory cache allocation), environment information gathering, keyboard logging and encoding elements:

Sections of the threat also include “.symtab”, which can be used to save and locate definitions and references of symbols called by the malware.

Among the called functions we can have the evidence of the SuspendThread function, used to suspend specific threads:

Here is a reference to the LoadLibraryA function:

Following is a disassembling detail of the .text section, where a calling instruction to the Kernel32.dll WriteFile library function can be inferred:

Performing a SwiftSlicer debugging and decompiling session there is evidence of obtaining information of ComputerName, current threads, filepaths:

Here you can see further evidence of the configuration, which includes the extensions .INF, .bat, .cmd, .com and .exe:

This is followed by several references to resources locking and CPU information gathering:

Note the pointer of the variable “p” to the attribute “status”, in which execution elements such as stacks and globals are checked:

From the following decompilation instance, the above mentioned enumeration file cycles can be observed:

During the debugging session, a kind of injection of the following mutex locking and polling executions could be observed:

Here we can see the entrypoint address of the Portable Executable:

Within the hexadecimal code of the sample, we can notice references to XOR operations, CmdLine and executions via the syscall library:

This is followed by other references within the hexadecimal code, including CmdLine, algebraic executions with complex numbers and floating numbers, and executions of external processes. esecuzioni di processi esterni.

The screenshots below show decompiling details inherent in the main.wipe function. In the decompiling session in question, loop instructions can be observed in conjunction with call 0x00402526:

Within functions identifiable in such execution contexts, there are nop, loop and decrementation instructions:

References:

[0] (image): Microsoft PowerPoint – Module-3-NumberTheory-RSA (jsums.edu)

IOCs:

• fee7c379f3a555c5c821e872ec384a91
• m=+Inf-Inf.bat.cmd.com.exe3125
• main.wipe
• 45474735088646411895751953125

YARA Rule:

rule SwiftSlicerRule {   

 strings:        

$swift_string = “main.wipe”

$swift_hex = { 6d 3d 2b 49 6e 66 2d 49 6e 66 2e 62 61 74 2e 63 6d 64 2e 63 6f 6d 2e 65 78 65 33 31 32 35}     

condition:        

$swift_string or $swift_hex

 }

CONCLUSIONS:

SwiftSlicer has a specific objective: the complete destruction of target files and system domains of affected infrastructures. It is interesting to note references to algebraic executions, configuration parameters specifying types of executable files, as well as the presence of references to sockets and propagation functions. Among the threat’s peculiarities, there is also evidence of hooking executions and keylogging functions, so it can be assumed that SwiftSlicer performs not only wiping tasks, but also environment and information discovery and logging.

By checking the entropy and possible encoding status of the source code and Portable Executable sections, it was possible to observe that the malcoders did not pay much attention to masking and hiding malware features. This is probably due to the fact that, unlike ransomware threats, masking and shuffling of attributes is not crucial in this case, since there are no critical subroutines for the infection chain that must be as inviolable as possible, such as the use of RSA key objects in a vulnerable execution context.

As described above, the threat was developed in GoLang, probably due to the fact that development using this programming language allows for simplified management of external third party libraries, as well as faster and more multiplatform implementation.

In conclusion, this type of threat is extremely devastating because, unlike ransomware, where the malicious action (the encryption of files) is potentially reversible, here we are faced with a malicious code whose sole purpose is to destroy the victim’s files.