Ransomware Network Communication [Part 3]
[Ransomware Series Part 3]
Authored by: Alexander Sevtsov
This is the third installment of a multipart series on ransomware. While this segment stands on its own, the earlier posts offer additional details and information about ransomware and how it operates.
Part 1: Ransomware Delivery Mechanisms
Part 2: Ransomware: Too Overt to Hide
Ransomware continues to be a major concern for organizations worldwide. The recent WannaCry and NotPetya attacks are examples of the destructive nature of this type of malware and why we need to take immediate action to understand and defeat it.
In our first two installments, we covered how ransomware uses different delivery mechanisms to convey its payload to target victims. We also addressed the fundamental ways in which ransomware operates—including those characteristics that are common to all families and how security controls might use them to detect this threat. In this installment, we take a look at how ransomware communicates over the network with its C&C servers.
Since any network communication between malware and its C&C (command and control) servers reduces a malware’s stealth, ransomware authors try to keep network communications to a minimum. However, unless encryption keys are symmetrical and hard coded within the ransomware itself (now quite rare because malware defenders can reverse engineer the key with relative ease), most ransomware will at some point exchange keys with their C&C servers. When that occurs, malware detection systems can observe the traffic, and sometimes, intervene.
All ransomware implementations are different, but early variants that stored symmetrical keys within the ransomware itself have, for the most part, been weeded out and replaced by stronger versions. These improved renditions tend to use asymmetric cryptography that involve both a private and a public key. Since the ransomware uses only the public key to encrypt the victim’s files (or more precisely, encrypt the symmetrical keys used to encrypt the files), the private key required for decryption is not needed and never resides on the victim’s system unless the ransom is paid. More details about these types of encryption routines can be found in Part 2 of our blog series.
Although these advanced ransomware families do not need the private key to begin encrypting the victim’s files, they do require the public key. In most cases, the C&C server will transmit the public key to the ransomware on the victim’s device. This allows the C&C server to generate a unique key pair on the fly for each victim, but also generates network traffic that security products can detect. If a firewall, sandbox, or other malware protection system has blacklisted the C&C server’s IP address or domain name, or if it finds the traffic suspicious using some other heuristic, it can generate an alert that ransomware may exist, and block the network communication. This can prevent the ransomware from receiving the encryption key and stop the attack.
Network Activity Is Not Always Required to Retrieve Encryption Key
To guard against discovery by security tools and maximize stealth, modern ransomware families are shipped with built-in, public encryption keys, such as RSA. Moreover, the server’s private key can be protected by utilizing an additional layer of unique symmetric and asymmetric keys locally generated for each victim. This approach enables the encryption of the victim’s files without performing any network activity at all. Moreover, it does not allow different victims to use the same decryption tool if the key is leaked. Families, such as Spora, Sage, and Cerber, contain an offline encryption mode by default. Below is an analysis overview that demonstrates Lastline’s capabilities to detect this threat.
Recent versions of Cerber do perform minimal network activity, but transmit only statistics about the victim and ongoing encryption process, such as the OS version, processor architecture, if the encryption finished successfully or not, and the number of encrypted files. This data is sent over UDP (which doesn’t require any server response) to a wide range of IP addresses and thus minimizes the ability for security products to pinpoint the real location of C&C servers. Since the public key is hardcoded in the malware sample’s configuration, network connections are no longer required to start the encryption.
Multipronged Approach to Obtain Encryption Key
We have also observed an interesting technique for retrieving the public key in a recent variant of the Locky ransomware family. This sophisticated malware uses multiple fallback mechanisms to communicate with its C&C infrastructure.
Initially, Locky attempts to connect with hardcoded C&C servers. If that effort fails for any reason (either the server is down or the network traffic is blocked), the ransomware will try to reach several different C&C servers found at other domains. These domains are calculated in real-time using a Domain Generation Algorithm (DGA). The DGA generates the domains by using data returned from the GetSystemTime API, and hardcoded seed values.
If Locky is still unable to establish a connection with any of the domains generated via DGA, the ransomware switches into an offline mode, where an embedded RSA public key is used to complete the encryption process.
Analysis overview, Locky
Communications via Anonymity Networks and Blockchain
Following the encryption of a victim’s files, ransomware will often instruct the victim to transfer a particular amount of cryptocurrency (usually Bitcoins) to the attacker’s wallet in exchange for the private key required for decryption. The key is sent to the victim via anonymity networks (such as TOR) instead of the regular Internet to hide from law enforcement. Publicly available blockchain websites are used to keep track of each bitcoin transaction.
While security products can observe this network traffic, it takes place after the files have been encrypted, so it provides no value in terms of preventing the attack. It is, however, useful as security products can analyze the traffic to better understand the entire behavior chain of the ransomware.
Network Communication Summary
Ransomware has evolved significantly in the way it performs network communications. While the threat used to require network communication to deliver the key to trigger the encryption process, modern ransomware families are shipped with hardcoded public keys which allows the threat to fly under the radar of network-based security solutions by switching into offline mode.
Much to our displeasure, ransomware is generating a healthy return for cybercriminals, and we can expect to see it continue to grow in numbers and in sophistication. Recent advancements in stealth technologies are evident when we examine how its network communications have evolved.
It’s critical that the security industry takes aggressive steps to understand these and other advancements in ransomware. Only then can we begin to hold it at bay.
Watch for our next posting in this series, where we will dig deeper into evasion tricks used in modern ransomware families and how Lastline defeats them.
Latest posts by Alexander Sevtsov (see all)
- Uncovering Nation-Specific, Targeted Attacks ( . . . without Knowing Korean) - September 26, 2017
- Ransomware Network Communication [Part 3] - July 14, 2017
- Ransomware: Too Overt to Hide [Part 2] - April 13, 2017