Quote:

‘Multi-process malware’ Eluding TTPC and Behavioral-Based detection

Heimdal™ Security’s cybercrime research unit has recently uncovered a criminal infrastructure that employs multiple domains in order to release malware into the wild. Despite the domains being taken offline, per request, the malicious software distributed through them appears to elude any known simple behavioral-based detection methodology. This type of malicious activity, which has yet to be named, focuses on machines running on multi-core architecture. Evidence suggests that gangs hiding behind multiple domains may be responsible for this new attack wave.

‘Multi-process malware’ : terminology, classification, dispersal pattern, and ‘tainting’ mechanism

Heimdal™ Security has ascertained that a new variety of malware may have been released into the wild. More worrisome is the fact that controlled, sandboxing-type tests performed on the sample have yielded some interesting results. The infection appears to be targeting multi-core machines and has so far evaded most behavioral and some simple threat detection tools.

Overview

The multi-process malware has been observed to spawn what we refer to as ‘mirrored processes’ – whereas canonical malware has a single-process viral dispersal pattern, multi-process malware create multiple system processes that register as safe when the behavioral analysis is applied. Code- or signature-based approaches have proved just as ineffective as heuristic analysis.

On their own, these continuously-spawned processes have the same properties as regular OS processes, and will therefore not impact the system in a malicious way. However, the ensemble, which is triggered by an exterior compiler, can be just as viral and damaging as single-process malware.

Proposed terminology

In analyzing the dispersal and tainting mechanism of multi-process malware, we propose the following terminology:

1) Polymorphism: considering that multi-process malware can change its form in order to evade detection, it would be only fair to include it in this larger category.

2) System call dependency: in existing malware detection methodology, a process can be flagged down as either “malicious” or “safe” based on the way it is interacting with various OS functions. Sandboxed malware samples perform very specific system call sequences and/or graphs.

3) TTPC: Threat-to-Process Correlation acronym. Our new method in behavioral analysis that aims to establish a connection between the malware and the process it is attempting to access on the infected machine.

4) Malware “Download-Execution” algorithm. In a typical malware propagation schema, the malicious process beings by queuing two types of operations: recv (instructs FPT that a file transfer will ensue) and open. In turn, this will trigger a write operations and finally, the malicious package executes itself on the target machine.

5) Multi-process malware ‘internal’ C&C (coordination and communication). To coordinate malicious code dissemination, all ‘mirrored’ processes communicate between them. Furthermore, an ‘overseer’ type of entity is warranted for malicious package recompilation.

Example of possible multi-process malware execution in a controlled environment

On executing the malware sample in a sandbox environment, we have observed the following behavior.

A) D&E (download & execute) behavior

File-manipulation operations are commencing – a recv command is issued at the same time as a write operation. Concomitantly, the targeted processes’ kernels are opened before the write command is executed.

This primary dyad is processed & executed along with a secondary one: recv before write and write before execute. The entire sequence allows the multi-process malware sample to tamper with a key system call sequence that would ultimately allow it to commit modifications to sensitive registry entries.

B) Proxy behavior

On the proxy side, the malware begins by piping data from a socket to a buffer. After that, it will simply store the data from a compromised comm socket into the same buffer.

C) Registry modification

As far as registry modification is concerned, there are two possible outcomes:

* The malware can execute a registry key creation command before deleting the value of a preexisting registry key.

* The malware can execute a registry-creation key command before closing the value-modification process for that key.

This is how the malware sample behaved in a sandbox-type environment. Further research has revealed that once the multi-process strain is released into the wild, it employs rogue domains in order to call up various system processes, which further reinforces the hypothesis of a criminal infrastructure hiding behind malicious domains.
...