ESET researchers describe the structure
of the virtual machine used in samples of Wslink and suggest a possible
approach to see through its obfuscation techniques.
ESET researchers recently described Wslink, a unique and previously undocumented malicious loader that runs as a
server and that features a virtual-machine-based obfuscator. There are no code,
functionality or operational similarities that suggest this is likely to be a
tool from a known threat actor.
In our white paper, linked below, we
describe the structure of the virtual machine used in samples of Wslink and
suggest a possible approach to see through the obfuscation techniques used in
the analyzed samples. We demonstrate our approach on chunks of code of the
protected sample. We were not motivated to fully deobfuscate the code, because
we discovered a non-obfuscated sample.
Obfuscation techniques are a kind of software protection intended to make code hard to understand and hence conceal its objectives; obfuscating virtual machine techniques have become widely misused for illicit purposes such as obfuscation of malware samples, since they hinder both analysis and detection. The ability to analyze malicious code and subsequently improve our detection capabilities is the driving force behind our motivation to overcome these techniques.
Virtualized Wslink samples do not contain
any clear artifacts, such as specific section names, that easily link it to a
known virtualization obfuscator. During our research, we were able to
successfully design and implement a semiautomatic solution capable of
significantly facilitating analysis of the underlying program’s code.
This virtual machine introduced a diverse
arsenal of obfuscation techniques, which we were able to overcome to reveal a
part of the deobfuscated malicious code that we describe in this blogpost. In
the last sections of our white paper, we present parts of the code we developed
to facilitate our research.
Our white paper also provides an overview
of the internal structure of virtual machines in general, and introduces some
important terms and frameworks used in our detailed analysis of the Wslink
virtual machine.
In an earlier white paper, we described
the structure of a custom virtual machine, along with our techniques to
devirtualize the machine. That virtual machine contained an interesting
anti-disassembly trick, previously utilized by FinFisher – spyware with extensive
spying capabilities, such as live surveillance through webcams and microphones,
keylogging, and exfiltration of files. We additionally presented an approach
for its deobfuscation.
This blogpost consists of excerpts from the
Under the hood of Wslink’s multilayered virtual machine white paper; we
encourage everyone interested in virtual machines and obfuscation techniques to
go through the original white paper, as it contains detailed information on various
steps required to see through the obfuscation techniques used in Wslink.
Overview of virtual machine structures
Before diving into the analysis of Wslink’s
virtual machine (VM), we provide an overview of the internal structure of
virtual machines in general, describe known approaches to deal with such
obfuscation, and introduce some important terms and frameworks used in our
detailed analysis of the Wslink VM.
General structure of virtual machines
Virtual machines can be divided into two
main categories:
1. System virtual machines – support execution of complete operating
systems (e.g., various VMWare products, VirtualBox)
2. Process virtual machines – execute individual programs in an
OS-independent environment (e.g., Java, the .NET Common Language Runtime)
Here, we are interested only in the second
category – process virtual machines – and we will briefly describe certain
parts of their internal anatomy necessary to understand the rest of this paper.
Process virtual machines run as normal
applications on their host OSes, and in turn run programs whose code is stored
as OS-independent bytecode (Figure
1) that
represents a series of instructions – an application – of a virtual instruction
set architecture (ISA).
Full article on www.welivesecurity.com from 28 March onwards.
