Source-linked AI summary
Using Software-Defined Networking for Ransomware Mitigation: the Case of CryptoWall
Krzysztof Cabaj, Wojciech Mazurczyk
TL;DR
Ransomware threatens users by encrypting important data, while conventional security solutions may lack the flexibility and responsiveness to react in time. The paper analyzes CryptoWall and proposes two SDN-based mitigation applications that use network monitoring and control rules. Experiments report feasible, effective mitigation, with reaction time no more than 100 ms even for tens of thousands of blacklisted domains.
Problem
Ransomware encrypts important data, and existing security solutions may lack the flexibility and responsiveness needed to detect and react to malicious activity in time.
Source: RANSOMWARE BASICS · p. 2, MITGATION OF RANSOMWARE THREATS USING… · p. 4Method
The authors analyze CryptoWall and propose two SDN applications that monitor network activity and use control rules to block ransomware communication or infected hosts.
Source: INTRODUCTION · p. 1, PROPOSED MITIGATION METHODS · p. 6Results
Reaction time did not exceed 100 ms even for tens of thousands of blacklisted domains, and both methods were reported feasible and effective.
Source: EXPERIMENTAL TEST-BED & ANALYSIS · p. 7, CONCLUSIONS · p. 8Takeaways & Limitations
The authors’ CryptoWall findings suggest that disrupting communication between a victim and the C&C can make encryption impossible.
Source: CONCLUSIONS · p. 8The proposed methods assume an up-to-date list of proxy servers is available.
Source: PROPOSED MITIGATION METHODS · p. 6
Abstract
from arXiv · showhide
Currently, different forms of ransomware are increasingly threatening Internet users. Modern ransomware encrypts important user data and it is only possible to recover it once a ransom has been paid. In this paper we show how Software-Defined Networking (SDN) can be utilized to improve ransomware mitigation. In more detail, we analyze the behavior of popular ransomware - CryptoWall - and, based on this knowledge, we propose two real-time mitigation methods. Then we designed the SDN-based system, implemented using OpenFlow, which facilitates a timely reaction to this threat, and is a crucial factor in the case of crypto ransomware. What is important is that such a design does not significantly affect overall network performance. Experimental results confirm that the proposed approach is feasible and efficient.
INTRODUCTION
The paper uses SDN’s centralized control and real-time traffic rules to address ransomware mitigation, presenting two CryptoWall-informed applications and evaluating proof-of-concept implementations.
INTRODUCTION
- SDN separates control and data planes, letting an external controller manage network-device flow tables and apply traffic rules in real time.OpenFlow is described as the de facto standard for implementing SDN.Source: INTRODUCTION · p. 1
- Existing SDN security work addressed anomaly detection, network attacks, mobile-malware behavior, and dynamic cloud monitoring.The cited examples include a general anomaly-detection system proposed by Mehdi et al. in 2011.Source: INTRODUCTION · p. 1
- The paper proposes monitoring network traffic for suspicious activity and using real-time SDN control rules to block infected hosts.The authors argue that disrupting attacker-server communication can prevent encryption when ransomware uses asymmetric cryptography.Source: INTRODUCTION · p. 1
- Its contributions are SDN-based crypto-ransomware mitigation, two real-time algorithms informed by CryptoWall behavioral analysis, and evaluated proof-of-concept implementations.The paper first presents ransomware basics and CryptoWall analysis, then evaluates the mitigation applications.Source: INTRODUCTION · p. 1
RANSOMWARE BASICS
Ransomware generates revenue by denying access to machines or data, while crypto ransomware encrypts valuable files and has increasingly targeted organizations with sensitive information.
RANSOMWARE BASICS
- Ransomware is described as an emerging revenue-generating threat, with a construction kit enabling even inexperienced criminals to create customized malware as a service.The TOX service retained 20% of each ransom paid.Source: RANSOMWARE BASICS · p. 2
- After infection, ransomware may lock a machine or its data, and modern variants can encrypt accessible cloud and shared network drives.A single infection can therefore compromise multiple systems; payment does not guarantee that files or machines will be unlocked.Source: RANSOMWARE BASICS · p. 2
- Locker ransomware denies machine access, whereas crypto ransomware encrypts valuable files that remain inaccessible until a ransom is paid and a decryption key is obtained.The infected machine can continue to work because critical system files are not encrypted.Source: RANSOMWARE BASICS · p. 2
- Ransomware targets have shifted from individual users toward companies and institutions, whose sensitive or critical data may support higher ransom demands.The paper gives police departments and hospitals as examples of organizations whose victims paid ransoms.Source: RANSOMWARE BASICS · p. 2
CRYPTO RANSOMWARE BASICS: THE CASE OF CRYPTOWALL
CryptoWall’s asymmetric encryption keeps its private key off the infected machine, but its communication with attacker infrastructure creates a potential mitigation point. The authors analyze its protocols and proxy infrastructure to characterize that opportunity.
CRYPTO RANSOMWARE BASICS: THE CASE OF CRYPTOWALL
- With asymmetric cryptography, CryptoWall’s C&C generates a key pair, sends only the public key to the infected machine, and keeps the private key off-host.The paper identifies CryptoWall 3.0 as a prominent early ransomware family to introduce asymmetric keys.Source: CRYPTO RANSOMWARE BASICS: THE CASE OF… · p. 2, Figure 1 · p. 3
- CryptoWall 3.0 communicates through HTTP POSTs to proxy servers; its exchanges deliver victim details, a public key and ransom information, then instructions and encrypted files.CryptoWall 4.0 retains the main communication principles with data randomization and simplifies the protocol to three message exchanges.Source: CRYPTO RANSOMWARE BASICS: THE CASE OF… · p. 3, Figure 2 · p. 3
- Analysis of 359 samples, executed more than 3,700 times, found that domains usually map to one IP address, but more complex mappings and later domain or URL reuse also occur.The study captured more than 5 GB of traffic traces; the proxy-list/domain relationships are illustrated in Fig. 3.Source: CRYPTO RANSOMWARE BASICS: THE CASE OF… · pp. 3–4, Figure 3 · p. 4
- The 359 samples yielded 59 proxy-server lists, averaging about 40 servers each; public-key downloads took 3.76–27.38 seconds in the stated worst case.The largest list had 70 servers, and the average key-download time was 9.28 seconds.Source: CRYPTO RANSOMWARE BASICS: THE CASE OF… · p. 4
MITGATION OF RANSOMWARE THREATS USING CURRENT SECURITY SOLUTIONS: PERFORMANCE ISSUES
The paper argues that growing traffic volumes make timely ransomware response difficult for conventional security systems. Experiments show that large firewall rule sets can increase delays and exhaust hardware resources.
MITGATION OF RANSOMWARE THREATS USING CURRENT SECURITY SOLUTIONS: PERFORMANCE ISSUES
- Growing network traffic and the need to react quickly to malicious activity challenge conventional firewalls and intrusion detection/prevention systems.Source: MITGATION OF RANSOMWARE THREATS USING… · p. 4
- Above 10,000 active rules, iptables delays rose sharply; adding 1,000 rules also took longer as the active rule count increased.At up to 10,000 rules, the impact on network performance was negligible.Source: MITGATION OF RANSOMWARE THREATS USING… · p. 5, Figure 4 · p. 5
- More than 500 rules on the Cisco 3560 exhausted TCAM, shifting packet processing to the switch processor and harming forwarding and device performance.Source: MITGATION OF RANSOMWARE THREATS USING… · p. 5
PROPOSED MITIGATION METHODS
The proposed SDN1 and SDN2 methods dynamically blacklist proxy servers that relay ransomware communications. They rely on identifying those proxies in advance and differ in how DNS traffic is inspected and blocked.
PROPOSED MITIGATION METHODS
- The authors state that the mitigation principle also applies to Locky: without a successful connection to its malicious server, encryption cannot proceed.Locky can query domains generated by a domain generation algorithm after its hardcoded C&C addresses stop responding.Source: PROPOSED MITIGATION METHODS · p. 5
- Both proof-of-concept methods use dynamic blacklisting of ransomware proxy servers, which can prevent access to the attacker’s server and the public encryption key.Their effectiveness depends on previously identifying the proxy servers; the paper assumes an up-to-date list.Source: PROPOSED MITIGATION METHODS · pp. 5–6
- SDN1 sends all DNS traffic to the controller, checks responses against the proxy database, and discards a response matching a listed domain.After detecting a blacklisted proxy, it blocks further communication from that host and alerts the administrator.Source: PROPOSED MITIGATION METHODS · p. 6
- SDN2 forwards DNS queries to their recipient while sending a copy to the controller, avoiding added query delay while the domain is checked.If a hostile domain is found, the controller installs an OpenFlow rule to block traffic between the victim and C&C server.Source: PROPOSED MITIGATION METHODS · p. 6
EXPERIMENTAL TEST-BED & ANALYSIS
The evaluation compares two SDN applications in an OpenFlow testbed and measures DNS delays and mitigation response time. SDN2 adds almost no DNS-response delay, and its reaction time is far shorter than CryptoWall’s public-key download time.
EXPERIMENTAL TEST-BED & ANALYSIS
- The testbed used Xen-managed virtual machines, OpenFlow-controlled Open Virtual Switches, and a POX controller implementing both applications.Figure 5 depicts the SDN1 and SDN2 designs alongside the testbed used for evaluation.Source: Figure 5 · p. 6, EXPERIMENTAL TEST-BED & ANALYSIS · p. 6
- SDN can evaluate only the first packet of a flow, and the applications install rules only for addresses a host actually tries to contact.CryptoWall analyses found more than 2,100 proxy domains, while a particular infected machine contacted about 40 on average.Source: EXPERIMENTAL TEST-BED & ANALYSIS · p. 7
- The evaluation measured DNS response delays over twenty queries, omitting the first query, and used malicious domains supplied by Bambenek Consulting.The first query was omitted because it was often directed to remote DNS servers and could take longer.Source: EXPERIMENTAL TEST-BED & ANALYSIS · p. 7
- About 37 times shorter than CryptoWall’s shortest public-key download time, SDN2’s reaction time was under 100 ms even with tens of thousands of blacklisted domains.The figure presents DNS query-response delay and the time for adding 1,000 new domains and reacting to a hostile domain.Source: Figure 6 · p. 7, EXPERIMENTAL TEST-BED & ANALYSIS · p. 7
- With 70,000 domains, SDN response-time increase stayed at or below 50%, whereas firewall downloads almost tripled with a rule list of around 30,000 IP addresses.SDN2 introduced almost no additional DNS-response delay and was faster than SDN1; SDN1’s delay depended on the number of blacklisted domains.Source: EXPERIMENTAL TEST-BED & ANALYSIS · p. 7
CONCLUSIONS
The paper concludes that disrupting CryptoWall’s connection to its C&C server is sufficient to make encryption impossible. It reports that two SDN applications using an up-to-date proxy database are feasible and effective, and identifies additional SDN detection approaches as ongoing research.
CONCLUSIONS
- The authors’ CryptoWall findings suggest that disrupting the victim’s connection to C&C is sufficient to make encryption impossible.Source: CONCLUSIONS · p. 8
- The two SDN security applications rely on an up-to-date database of malicious ransomware proxy servers, and experiments support their feasibility and efficacy relative to popular security solutions.Source: CONCLUSIONS · p. 8
- The authors identify hybrid, classification-based, and pattern-based SDN methods as possible additions, and say these approaches are part of ongoing research.Source: CONCLUSIONS · p. 8
BIOGRAPHY
The biographies describe the authors’ academic backgrounds, university roles, and research interests.
BIOGRAPHY
- Krzysztof Cabaj earned computer science degrees at Warsaw University of Technology and is an assistant professor there.He also instructs Cisco Academy courses at the International Telecommunication Union Internet Training Centre.Source: BIOGRAPHY · p. 8
- Cabaj’s research interests include network security, honeypots, and data-mining techniques.He has authored or co-authored more than 30 information-security publications.Source: BIOGRAPHY · p. 8
- Wojciech Mazurczyk is an associate professor at Warsaw University of Technology whose interests include network security, bio-inspired cybersecurity, networking, and information hiding.He has served as an associate technical editor of IEEE Communications Magazine since 2013.Source: BIOGRAPHY · pp. 8–9