Heimdal™ Security Discovers Gangs Hiding Behind Multiple Domains to Avoid TTPC Detection
‘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.
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.
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
. 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
This primary dyad is processed & executed along with a secondary one:
. 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.
Modus operandi, hits, and process calls.
Heimdal™ Security’s internal data has yielded that a single domain can call up to 35 different system processes. Here are the highlights of Heimdal™ Security’s investigation.
Case Study A – Kamburnk
A malicious domain named “tracking.kamburnk.com” (domain blocked and sanitized by Heimdal™ Security) called up urbanvpnserv.exe no less than 2,400 times.
The process in question is a PE32 executable (GUI) Intel 80386 for Microsoft Windows, developed by Urban Security. It has been designed to install a VPN service called UrbanVPN. The malicious pattern was later established after the executable attempted to drop a viral payload and/or rewrite itself.
The same domain called up various other system processes such as chrome.exe, net_svc.exe, hola_svc.exe, firefox.exe, and HD-Player.exe.
Regular behavioral-based analysis returned inconclusive results. No attack pattern could have been established. TTPC analysis indicated a high probability of malicious activity based on system processes opened concurrently.
Multi-process malware attack pattern established, prompting the agent to sever communications to C&C servers.
Case Study B – TVPASSPORT
A malicious domain, called “tvmds.tvpassport.com” (domain blocked and sanitized by Heimdal™ Security), attempts to open chrome.exe.
Hit count has been estimated at around 270. The same domain called up additional system processes. Sorted by hit count, the processes are firefox.exe, iexplore.exe, System Idle, brave.exe, node.exe, dragon.exe, msedge.exe, and browser.exe. Applied behavioral-based analysis has rendered inconclusive results. No attack pattern could have been established.
TTPC detects a high probability of malicious activity, based on the holistic analysis performed on accessed processes’ log trail. Multi-process malware attack pattern established. C&C connection severed.
Case Study C – U11929015 Sendgrid
A malicious domain, call sign “u11929015.ct.sendgrid.net” (domain blocked and sanitized by Heimdal™ Security) attempts to open OUTLOOK.exe.
Hit count estimated at around 35. Concomitantly, the same domain attempts to open other system processes.
Sorted by hit count, the processes are as follows: System Idle, chrome.exe, HxOutlook.exe (32-bit executable that serves various Outlook functions such as task managing, note-making, calendar, and journaling), postbox.exe, MicrosoftEdgeCP.exe, and msedge.exe.
Behavioral analysis performed on sample marked the connection as safe. Subsequent TTPC analysis established multi-process malware-type behavior. The connection to C&C servers was severed.
Case Study D – Update Sbis\Saby
A malicious domain called “update1.sbis.ru” (domain blocked and sanitized by Heimdal™ Security) attempts to open several system processes, including svchost.exe.
Low hit count on the first pass – one time for svchost.exe and around 15 times for sbis3plugin.exe. Polymorphic pathology established. Domain mutates into “update5.sbis.ru” (blocked & sanitized by Heimdal™ Security).
On the second pass, the hit count and the accessed processes are as follows: 14 registered attempts for sbi3plugin.exe and one attempt for svchost.exe. Second mutation – attack launched from “update6.saby.ru” (blocked & sanitized by Heimdal™ Security). Remark the subdomain permutation (. sbis→.saby); same two processes are targeted (svchost.exe and sbis3plugin.exe).
Hit count grows exponentially – around 28 times for the Service Process Host and once for the sbis3 plugin.
Upon establishing beachhead, the subdomain is again changed (. saby→ .sbis). From “updade6.sbis.ru”, svchost and sbi3plugin are again called up. Hit count reaches 1,400 for the sbi plugin and around 800 for the Service Process Host. Other processes are called up during this second wave: SbisMon.exe and Launcher.exe. The fourth pass – subdomain and form are changed again.
The new call sign is “update7.saby.ru” (blocked & sanitized by Heimdal™ Security). Subdomain targeting attempts to access the sbi3 plugin, with a hit count of 35.
Once the foray has seized, the subdomain is changed once more (.saby →.sbis); “update7.sbis.ru” (blocked and sanitized by Heimdal™ Security) aims for sbi3plugin.exe, svchost.exe, and other processes. A pattern variation can be observed: the attack launched upon subdomain shift would have commenced with a different system process.
This time, the attack starts by accessing sbis3, as opposed to the last round, before moving on to svc host and other system processes.
Hit count is over 1,000 of sbi3, followed by 856 for System Idle, and 43 for Service Process Host. Fifth pass (“update8.saby.ru” and “update8.sbis.ru”, both blocked & sanitized by Heimdal™ Security) is symmetrical to the last: sbi3 is the round-opener; subdomain switch (.saby→.sbis).
Hit count for the sbi3 plugin is 37 on “.saby” pass, and over 1,000 from the .sbis subdomain. Other ‘tainted’ system processes: SbisMon.exe, sbis.exe, and chrome.exe.
Behavioral analysis has yielded inconclusive results. TTPC indicated a high probability of malware activity. Given the attack pattern and the number of domains and subdomains used to deploy the malware, it stands to reason that a criminal infrastructure may be at work. Polymorphic and multi-process malware pathologies confirmed. Connections to C&C servers had been severed.
- A total of 3,148,815 attacks have been observed in the last three months.
- 13,24% of attacks originated from a domain called “pixel.yabidos.com” (blocked & sanitized by Heimdal™ Security).
- In 62.39% of cases, the attackers targeted the System Idle Process, Chrome.exe – 10.16%, firefox.exe – 1.57%, and iexplore.exe -1.49%.
- Top 10 malware processes (based on hit count):
|Malware process||No. of hits|
|Auto FTP Manager.ex||11271
- 1,665 system processes have been targeted within the last three months.
- Total hit count for svc.exe and svchost was 28,185. In only 3,27% of cases, the attackers attempted to tamper with svchost.
Considering the sheer amount of factual data, we can safely conclude that a criminal infrastructure is using multiple domains to coordinate malicious attacks. In all instances, behavioral-, code-, and signature-based would have returned conflicting results. None of the access attempts appear to be malicious in nature.
However, once intercommunication is established, the malware would have executed a multi-pronged attack that would have more than likely cripple key processes.
Heimdal™ Threat Prevention - Endpoint
- Machine learning powered scans for all incoming online traffic;
- Stops data breaches before sensitive info can be exposed to the outside;
- Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
- Protection against data leakage, APTs, ransomware and exploits;
The discovery of this APT has been facilitated by correlating the data fromHeimdal™ Threat Prevention’s TTPC backlog with the number of connections severed by DarkLayer Guard™, Heimdal™ Security’s DNS traffic-filtering solution.
Is multi-process malware the next stage in APT’s evolutionary process? Most definitely, considering that it’s far easier to deploy compared to single-process malware and has a higher stealth factor.