Microsoft Dissects FinFisher’s Complex Infection Process
Windows Defender Advanced Threat Protection (Windows Defender ATP) is capable of detecting behavior associated with the sophisticated FinFisher spyware, Microsoft says, after performing an in-depth analysis of the malware’s infection process.
FinFisher is a lawful interception solution built by Germany-based FinFisher GmbH, which sells it exclusively to governments. Also referred to as FinSpy, the malware has been around for over half a decade and has been associated with various surveillance campaigns.
In September last year, after the malware was observed exploiting a .NET Framework zero-day (CVE-2017-8759) for infection, ESET warned that Internet service providers (ISPs) might be involved in FinFisher’s distribution process.
According to Microsoft, FinFisher is complex enough to require “special methods to crack it” but, despite its sophistication, the malware cannot go unnoticed by its security tools. These include Office 365 Advanced Threat Protection (Office 365 ATP) and Windows Defender ATP, which is set to arrive on Windows 7 and Windows 8.1 devices this summer.
Packed with various detection, evasion and anti-analysis capabilities, including junk instructions and “spaghetti code,” multi-layered virtual machine detection, and several anti-debug and defensive measures, FinFisher wasn’t easy to tear apart and analyze, Microsoft says.
Through the addition of continuous code jumps (spaghetti code), FinFisher’s authors ensured that the program flow is difficult to read and can confuse disassembly programs. While reversing plugins that may help in such situations exist, none was found to work with this malware, and Microsoft had to come up with their own.
The first thing the company discovered was an array of opcode instructions that a custom virtual machine program can interpret. 32 different routines were discovered, each implementing a different opcode and functionality that the malware program may execute.
Not only does the use of virtualized instruction blocks ensure that analysis using regular tools is not possible, but anti-debug and anti-analysis tricks in the virtualized code attempt to evade dynamic analysis tools as well.
“Each virtual instruction is stored in a special data structure that contains all the information needed to be properly read and executed by the VM. […] The VM handler is completely able to generate different code blocks and deal with relocated code due to address space layout randomization (ASLR). It is also able to move code execution into different locations if needed,” the software giant explains.
The first stage of FinFisher is a loader meant to detect sandbox environments. If it passes the initial set of checks, the loader reads four imported libraries from disk (ntdll.dll, kernel32.dll, advapi32.dll, and version.dll) and remaps them in memory, rendering debuggers and software breakpoints useless.
Next, the malware performs additional anti-sandbox checks, likely in an attempt to avoid specific sandbox or security products, and also checks for virtualized environments (VMWare or Hyper-V) and if it is running under a debugger.
Only if all these checks are passed, the loader moves to the next step, which represents a second multi-platform virtual machine.
“The 32-bit stage 2 malware uses a customized loading mechanism (i.e., the PE file has a scrambled IAT and relocation table) and exports only one function. For the 64-bit stage 2 malware, the code execution is transferred from the loader using a well-known technique called Heaven’s Gate,” Microsoft explains.
The 64-bit stage 2 implements another loader and virtual machine, featuring an architecture similar to those in the previous stage, but using slightly different opcodes (which Microsoft lists on their site). The virtual machine extracts and decrypts the stage 3 malware. After decryption, the payload is remapped and executed in memory.
Stage 3, which represents the installation and persistence stage of the malware, is the setup program for FinFisher and no longer employs a VM or obfuscation. The code can install the malware in a UAC-enforced environment with limited privileges, or with full-administrative privileges enabled. However, no privilege escalation code was found in the malware.
During this installation step, stage 4, stage 5, and stage 6 payloads, along with additional files, are potentially dropped under a folder located in C:\ProgramData or in the user application data folder. Stage 4 is a loader for UAC bypass or installation with admin rights, stage 5 is a payload injected into explorer.exe or winlogon.exe, while stage 6 is the main malware executable.
The stage 5 malware only provides one more layer of obfuscation for the final payload (through the VM) and sets up a special Structured Exception Hander routine to ensure stealthy operations. After checking the environment once again, it proceeds to extract and execute the final payload into the injected process (it uses RunDll to implement the spyware).
to read the orignal article: