A Framework for Threats Analysis Using Software-Defined Networking
AA Framework for Threats AnalysisUsing Software-Defined Networking
Francisc Moldovan ∗† , Ciprian Opris¸a ∗†∗ Bitdefender † Technical University of Cluj-Napoca { fmoldovan, coprisa } @bitdefender.com Abstract —The ability to analyze network threats is veryimportant in security research. Traditional approaches, involvingsandboxing technology are limited to simulating a single host,missing local network attacks. This issue is addressed by de-signing a threat analysis framework that uses software-definednetworking for simulating arbitrary networks. The presentedsystem offers flexibility, allowing a security researcher to definea virtual network that is able to capture malicious actions and tobe restored to the initial state afterwards. Both the frameworkdesign and common usage scenarios are described. By providingthis framework, we aim to ease the analysis effort in combatingcyberthreats.
I. I
NTRODUCTION
Most cyberthreats nowadays propagate through computernetworks, bypassing the borders of a single host. Modernthreat intelligence must consider this aspect while analyzingnew threats or new malware. Observing the behavior of agiven threat, isolated on a single host is not enough, as somemalicious actions are only performed in a real-world network.Traditional malware research uses virtual machines fordynamic analysis [1]. Virtual machines are handy because theyrepresent a controlled environment, where suspicious softwarecan be run and the system changes can be observed, whilehaving the ability to restore the environment to the originalstate.For instance, we can analyze a ransomware sample [2],[3] by running it in a virtual machine. The ransomware willperform some malicious actions, like encrypting files andleaving ransom notes. The analysis (automated or manual)can detect these actions, either by monitoring the ransomwareactions or by comparing the state of the machine after theinfection with the initial state. After the analysis have beenperformed, the original snapshot can be restored, preparingthe VM for another analysis. In case of a backdoor or bot [4],besides the actions performed on the infected host, a completeanalysis should also examine the network interactions, as thistype of malware communicates with a Command and Controlserver located on the Internet.However, there are malware samples and hacking toolsthat are not only directed towards the Internet but also lookinside the local network for potential targets. If the simulatedenvironment is limited to a single host, connected or not tothe Internet, little information can be gathered regarding the network behavior of the analyzed threat. The current paperproposes a framework designed to overcome this limitation, byextending the sandbox machine concept to a sandbox network.We achieve the proposed goal by employing software-defined networking [5], a concept that allows defining avirtual network programmatically, offering both elasticity andscalability.The next section presents similar approaches that we cameacross while designing the framework presented in this paper.Section III presents the framework architecture, both network-wise and functionality-wise. The experimental results follow,where we present some common network attacks successfullydetected by our framework and some considerations regardingperformance. The paper ends with the conclusions section.Among our contributions, worth mentioning are the factthat virtual networks created using the framework reside onthe system itself with high level of interaction with hostOS firewall, routes and interfaces, while still preserving themuch entailed level of isolation of the host from potentiallymalicious virtual network activity. Also, easy configuration ofhosts prior to network creation proves facile by using highlevel abstraction at the created framework level.II. R
ELATED W ORK
The mininet
SDN Framework[6], appeared in 2012, and asits authors concisely affirm: ”Mininet creates virtual networksusing process-based virtualization and network namespaces -features that are available in recent Linux kernels. In Mininet,hosts are emulated as bash processes running in a networknamespace, so any code that would normally run on a Linuxserver (like a web server or client program) should run justfine within a Mininet ”Host”.” . It became quite popular andmature, hence already being available for usage as both astandalone, custom built virtual machine, and as a softwarepackage available on official Linux repositories, such as the apt , used by Debian-based distributions. As the official page of mininet shows, a considerable number of publications surfacedin the domain of SDN thanks to their implementation.By comparing and contrasting our approach with [6], aseries of obvious differences emerge. While [6] provides avast range of functionalities, our emphasis on security researchusing SDN fails to benefit greatly from the framework. Firstof all, bypassing network isolation proves a difficult task,and the user needs to rely solely on the
APIs available in (cid:13) a r X i v : . [ c s . CR ] J u l he framework itself. While we also assured isolation of avirtual network, our solution also focuses on comprehensiveinteraction between a virtual network and the underlyinghost operating system. More exactly, our focus lead to thefollowing: enabling easy addition to the network of virtualmachines or real ones, toggling Internet connectivity of thenetwork, easy reconfiguration of network structure withoutan impact on performance. An analysis on scalability with mininet has been carried out in [7], proving the efficiency ofusing lightweight virtualization for creating virtual networks,an encouraging aspect in validation of our implementation.The authors of [8] place emphasis on utility of SDN insecurity research, and also shed light upon the fact that popu-larity of SDN increases faster among networking professionalsthan with security researchers. Their publication brings strongarguments backed up by existing examples from the SDNsecurity community, showing the advantages of using virtualnetworks in securing networks in a novel manner. Among theSDN systems that bring novelty to security, worth mentioningare dynamic control of malicious or suspicious network flows,a centralized monitoring system for detection of networkflooding or network anomalies, and even the development ofnetwork programming languages for easy deployment. Whileour approach utilizes SDN for security research, [8] presentsuse of SDN for securing a real network, aspect which shallprove useful for future work.An interesting approach towards network security usingSDN is presented in [9]. The authors make use of the popularvirtual network framework mininet [6] in order to perform reconnaissance deception . Basically, by leveraging the powerof software defined networking, each real host in a networkpresents to the others a bogus image of the network, oncetaking part in a network scanning activity. While networkdeception fails to replace security scanning, the mechanismgreatly aids in increasing the time needed for an insider toinfer the layout and structure of the real network. Comparedto our solution, [9] shows an interesting usage of an existingframework, while we illustrate the creation of a framework forcreating virtual networks for use in security research.III. F RAMEWORK A RCHITECTURE
A. Overview
While designing and experimenting with the SDN frame-work, a series of compulsory requirements have emerged. Thefirst aspect, and probably the most critical: it should be ableto run on commodity hardware, including a personal laptop,while in the same time having the ability to model hundreds ofreal network hosts, each with customizable services exposed(e.g. FTP, HTTP, SSH).An issue that surfaced early on in the testing phase isthat emulation of services fails to deliver realistic results,since many exploits only utilize their malicious payloads ondetection of real, very specific services. Basically, emulatedservices represent bogus output exposed to attackers, whichperfectly matches the one of a real application. During recon-naissance of their target network and systems, most attackers resort to banner grabbing . This technique, as described in[10], consists of connecting to a remote application using network Swiss army knife tools such as nc , described in[11]. In most cases, exact version of software surfaces to themalicious scanner. Usually, service emulation solutions alsocover banner grabbing, together with response to commoncommands specific to a network service. Despite these efforts,many automatic bots rarely get tricked into triggering theirmalicious act.The SDN framework provides elasticity in the usage forcreating a virtual network, and for the scenarios tested, wechose 3 virtual machines, namely: victim , attacker , scanner .The number of network hosts, though, can easily be extendedto the hundreds, if not thousands without using additionalVMs. Moreover, the additional hosts are able to expose realservices on the network, with the particularity that they mustbe installed on the victim VM.Making use of not only simple, non-VM virtual hosts, butalso VMs in our framework stems from service emulationnegatively affecting expected detection outcome. In order toobtain scenarios as realistic as possible, these hosts need toreveal real network services, with the possibility of vastlyextending their variety. As a victim machine hosting variousnetwork services, we chose the popular
Metasploitable , whichas its creators affirm, represents ”a test environment [...]a secure place to perform penetration testing and securityresearch” . While virtual machines deliver excellent feedbackin security research, using more than 3 VMs on a typical laptopcan seriously take a toll on the host machine functionality.The other two virtual machines in our test setup, namely attacker and scanner , were also chosen with regard to theirspecificity. The attacker
VM represents an installation of anx86 Windows OS. The motivation behind our choice liesin the fact that many malware families exist for Windows,and the scope of our framework targets exactly having theability to collect network traffic information with malware ormalicious network activities. In addition, we have installedsome popular pentesting tools compiled for Windows, suchas network scanning tool nmap and brute force passwordcracking tool
Hydra [12]. The first one aids in performingdiscovery and analysis of neighboring hosts and their servicesin a network, while the second one employs automation byleveraging the power of dictionary attacks. Finally, the scanner
VM represents a version of the well-known Debian-basedLinux distribution,
Security Onion [13]. It comes as a great aidin detection of malicious network activities, by using a seriesof specific, pre-installed IDS tools such as Bro, Suricata orSnort. In addition, the authors of
Security Onion encouragethe security researcher utilizing this distribution to spenddays, weeks tailoring the stack of dedicated security tools,for example by adding new signatures for detection.Worth mentioning in the end are the fact that the attacker virtual machine could be used in order to model the attackerfrom inside the virtual network, while victims are the victim virtual machine together with all the non-VM, virtual redirec-tor nodes , that map certain ports onto ports of services that eed to be installed on the victim machine . B. Network-wise Architecture
At the core of the SDN Framework lie features in theLinux Kernel itself. First of all, the core of a virtual networkrepresents the Linux Bridge, which acts as a gateway for thevirtual network itself. With security in mind, both of the hostcomputer, and of a real network bearing the system as one ofits hosts, we carefully chose Linux Firewall rules and chains,in order to have isolation of the virtual network. On the otherhand, the virtual network may be configured to have Internetaccess, but DNS configuration at host level remains a task forthe human actor, in order to avoid accidental Internet leaks.Fig. 1: An overview of a virtual network implemented usingour framework. The VM -label rectangles represent the follow-ing, by color: pink-victim , red-attacker , green-scanner . Nextto each NIC symbol is the interface name in Linux. mybridge represents the virtual network bridge.Linux Network Namespaces and Linux virtual Ethernet de-vices lie at the heart of each non-VM host in the network. Con-cerning namespaces in the Linux operating system, the LinuxManpages [14] entry for namespaces provides relevant piecesof information: ”A namespace wraps a global system resourcein an abstraction that makes it appear to the processes withinthe namespace that they have their own isolated instance ofthe global resource. Changes to the global resource are visibleto other processes that are members of the namespace, butare invisible to other processes. One use of namespaces is to implement containers” . Basically, a virtual, non-VM host inour SDN solution represents a network namespace having anetwork interface that connects using virtual Ethernet to a vethpair interface in the default network namespace, which in turnconnects to the virtual network bridge.Since each non-VM host in the virtual network we cre-ated represents solely a networking context, we benefit from lightweight virtualization , allowing the existence of as manysuch hosts as the network address range allows us, withoutthere appearing noticeable impact on performance. Further-more, leveraging the capabilities of
NAT ( Network AddressTranslation ), each such host allows a mapping of its own portto a port of the victim machine, in order to deceive the attackerthat the virtual host actually exposes certain services on thenetwork on certain ports, while in reality they exist on the victim virtual machine, this being a requirement.With automation in mind to an extend as vast as possible,we chose to utilize networking capabilities of the underlyinghost operating system. Therefore, the 3 virtual machines, victim , attacker and scanner programmatically receive DHCPlease reservation upon creation or modification of the virtualnetwork.A particularity of the chosen setup aims at not only obtain-ing an isolated network, but also assuring in-depth scanningof the network traffic. In order to do so, the so-called scanner virtual machine connects to the virtual network in promiscuousmode and also benefits from port mirroring such that all thenetwork traffic from the bridge gets replicated in the scanner interface. A significant aspect that entails attention represents hiding the scanner machine, while at the same time assuringthat it can communicate with the bridge , in order to receive acopy of its entire traffic, and also the DHCP configuration. Thesolution for this represents blocking all ARP packets, exceptthose coming from the bridge, at the level of the scanner
VM.Worth mentioning is the method via which the componentsmentioned above connect with one another. Each virtual ma-chine receives a tun/tap interface onto which it attaches. Next,this interface connects to the bridge of the virtual network. Atthe level of non-VM hosts, namely the network namespaceswhich contain solely a network interface configuration andNAT redirection rules, communication takes place using so-called veth pairs . More exactly, upon creation, a networknamespace receives a network interface which communicatesvia a tunnel with a pair interface in the default networknamespace. In turn, the veth pair interface connects to thevirtual network bridge (as seen in Fig. 1).As far as networking is concerned, the critical aspect ofInternet access requires debate. While most SDN solutions,such as
Mininet [7] place network isolation high on their listof priorities, the security researcher utilizing our frameworkmight make it adamant that their setup requires connectionstowards outside networks. The entire architecture from Fig-ure 1 lies encapsulated in a laptop running Linux. Namely,upon creation of the virtual network, the laptop presents thefollowing interfaces: mybridge : the virtual network gateway, : for the 3 virtual machines in our testig. 2: An illustration of the interfaces and the firewall of thehost laptop running Linux. The devices in the area delimitedby the interrupted rectangle lie on the OS of the laptop itself.setup, and a number of veth interfaces equal to twice thenumber of virtual, non-VM hosts. For obvious reasons, on acomplete virtual network setup, only the veth interfaces fromthe default namespace appear when listing the interfaces on thelaptop (Figure 1 shows exactly the encapsulations at networknamespace level). The other half of veth interfaces becameconfigured accordingly to the virtual network and pushed intheir specific network namespaces corresponding to each non-VM host. Given the external network access issue describedearlier, and also the structure of the underlying system, let uscommence with describing the flow of outbound connectionsoriginating in our virtual network.Based on Figure 2, we can observe that the Linux Firewalllying on the host operating system establishes whether thevirtual network we created can initiate communication towardsan external network via Ethernet or WiFi. Note that completeisolation may exist, and that in our approach, having Inter-net connectivity works only with outbound connections, allinbound traffic being blocked.
C. Functionality-wise Architecture
For better illustrating the functionality-wise architecture , anattack scenario and the following steps shall be described.The security researcher runs an infected file on the attacker virtual machine. The sample ran aims at scanning the localnetwork. It shall detect as victims the victim virtual machine and the non-VM, virtual redirector nodes that solely maponto their own ports services that must be installed on the victim machine. The scanner virtual machine receives theentire network traffic and could also trigger detections. Thesecurity researcher performs a complete reset of the virtualmachines, but not before collecting the network capture, whichneeds manual inspection for new attack signatures to be addedto the scanner virtual machine .Functionality-wise, from its inception phase, our frameworkaimed at ease of use, automation, and possibility of reconfig- uration even when the virtual machines already performed acomplete boot-up, without the requirement of their restart.One of the advantages our solution brings, represents theseries of validations prior to creation of the virtual network.More precisely, MAC addresses of all the interfaces to becreated and added must not match any existing ones on thesystem. At IP level, validation takes place such that there existsno overlap of the IPv4 range of a network-to-be and existingones.An Object-Oriented abstraction was added, such that endusers can utilize the framework with disregard to specificitiesunderlying services invoke. Implementation-wise, we choseto utilize Python, due to ease in performing network-specificcalculations, such as inferring the number of hosts, gatewayIPv4 address or performing programmatic inquiry of existingnetwork interfaces on the host machine.Since our solution utilizes a series of virtual machines , wechose as virtualization software the Linux build of VirtualBox,as it provides the much entailed Command-Line Interfaceinteraction. Moreover, it being open-source assures ease ofuse backed up by a large on-line community.Programmatically, the user needs to provide a series ofscenario-specific parameters, such as IPv4 address of thenetwork and its netmask, MAC addresses, names of net-work interfaces and also NAT redirections. For our seriesof scenarios, the user also needs to provide configurationparameters for the collection of NICs in Figure 1, except theNICs responsible for interconnecting the network namespacesto the default network namespace, since they receive uniqueautomated names and MAC addresses. By default, a virtualnetwork created using our framework prepares the networkand the VMs, there existing the requirement that the userchooses which of the available IPv4 addresses to allocate tovirtual, non-VM hosts, and also what service redirections toperform at the level of each one (earlier we described that eachone can provide an entire collection of redirections towardsreal services installed on the victim
VM). Taking into accountthat the network aims at being used by a human actor insecurity research, DHCP reservations represent a feature. Inour series of runs, we chose a convention that victim , attacker and scanner receive the last 3 IP addresses in the network tobe created.Provided parameters choice took place, current state ofeach VM gets assessed, after which follows their network-wise configuration at OSI layer 1 and 2, regardless of thembeing switched on or off. In our specific case, tun/tap adaptersreceive the desired identification MAC and name. For our runs,we then prompted the user with the task of choosing the visibil-ity of the virtual network. More exactly, as Figure 2 shows, onemust choose a NIC of the host device for assuring connectivitytowards the Internet. At this step there exists the possibility ofchoosing complete isolation of the virtual network, taking intoaccount the possibility of malicious traffic occurring during itsuse afterwards. Next follows the configuration of firewall andinterfaces, after which the software calculates IPv4 specificparameters, and prepares a list of available IPv4 addresses.aving presented the architecture of our framework bothnetwork-wise, and at software level, we continue by illustrat-ing functionality of the API exposed. As stated earlier, giventhe variety of use cases, there exist no restrictions regardingthe structure of the virtual network to be created. Let us con-sider a scenario of the security researcher creating a networkcontaining the 3 virtual machines mentioned earlier. Initially,the network of choice for creation might be characterized bythe input parameters presented in Figure 3. bridgeName = "mybridge"tunTapNameVictim = "tunVictim"tunTapNameAttacker = "tunAttacker"tunTapNameScanner = "tunScanner"testIP = "192.165.15.0"testNM = "255.255.255.240"testMACBridge = "00:50:56:c0:aa:01"testMACTapVictim = "00:60:67:34:12:44"testMACTapAttacker = "00:60:67:34:12:55"testMACTapScanner = "00:60:67:34:12:66" Fig. 3: User added configuration parameters for the virtualnetwork to be created.The framework proceeds with configuration of all virtualhosts, followed by employing the user-established level ofisolation of the network to be created. With a successful runof the solution, the output ought to be similar to the oneillustrated in Figure 4.
Mynet:bridgeName : mybridgetunTapName
Fig. 4: Information inferred by the framework based on theinput parameters given.The framework user needs to consider the number ofadditional non-VM hosts the network currently supports. Inour specific use case, 11 slots left for IPv4 addresses assurea relatively limited sized network. An example of populatingthe network programmatically can be seen in Figure 5.As seen below, adding hosts to a virtual network using ourframework becomes accessible via custom wrapper functionswhich perform specific Linux networking tasks such as cre-ation of networking artifacts, address assigning, and perform-ing NAT redirections towards the victim from a non-VM host.Let us consider that a certain number of hosts were added, eachexposing a number of service redirections towards the victim.If the user considers more hosts are to be added, changing the futureHostIP = myNet.availableIPs[0]addVethHost(myNet, futureHostIP)redirectPort(aNetwork = myNet,fromIP = str(futureHostIP),fromPort = "2121",toIP = str(IPReservationVictim),toPort = "21")
Fig. 5: An example of API usage: adding a new non-VM host,which also maps its port 2121 to port 21 of the victim machine,using NAT.netmask from to one allowing more hostsexisting, such as can take place by changingthe netmask of the network and rerunning the creation script.Hosts and their redirections coded in so far remain availableon network reset. Advantages the implementation presents arethe fact that it takes a short time for reconfiguring the entiresystem forming our virtual network. In addition, changing thenetwork address to a completely different one, like for example and renaming interfaces can also take place. Thekey for speed lies in the fact that the virtual machines neednot restart for complete reconfiguration, and virtual non-VMhosts have a low footprint.IV. E
XPERIMENTAL R ESULTS
A. Attack Scenarios
Our validation phase, with accent placed on threats analysis,consisted of creating a virtual network whose network trafficto contain specific attack types, such as brute-force , but alsoreconnaissance activity, such as port scanning .
1) Port Redirections Towards Victim for Attacker Luring:
The listing shown in Figure 7, taken from the attacker ma-chine, represents an output of a network scan, performed usingthe nmap tool, with the following mapping scripted into aPython dictionary prior to virtual network creation. For eachtuple seen in Figure 6, the first item represents a port of avirtual redirector host, and the second one, the port of the victim virtual machine, which needs to host the services. redirDict[2]=[(11,21),(22,22),(33,23)]redirDict[3]=[(44,23),(55,25),(66,53),(77,80), (88,111)]redirDict[4]=[(99,139),(100,445),(110,514),(120,514),(130, 1524)]redirDict[5]=[(140,2049),(150,2121),(160,3306),(170,3632),(180,5432)]
Fig. 6: Port redirections towards victim. Each array offsetrepresents the ordinal of a non-VM virtual network host.
2) Brute Force and Port Scanning Detection:
A test sce-nario for validating the functionality of our framework in-volved creating a number of 4 virtual hosts that perform NATredirection on port 21 towards the victim virtual machine.From the attacker
VM, we ran a script which launches into map s c a n r e p o r t f o r
Host i s up ( 0 . 0 0 0 5 9 s l a t e n c y ) .
Not shown:
167 c l o s e d p o r t s
PORT STATE SERVICE11/tcp open systat22/tcp open ssh33/tcp open dspMAC Address:
CA: 9 9 : 1D: 6 E : E3 : 7D ( Unknown )Nmap s c a n r e p o r t f o r
Host i s up ( 0 . 0 0 0 4 9 s l a t e n c y ) .
Not shown:
165 c l o s e d p o r t s
PORT STATE SERVICE44/tcp open mpm-flags55/tcp open isi-gl66/tcp open sqlnet77/tcp open priv-rje88/tcp open kerberos-secMAC Address:
5E : 2 5 : B9 : 7 3 : F7 : B9 ( Unknown )Nmap s c a n r e p o r t f o r
Host i s up ( 0 . 0 0 0 4 9 s l a t e n c y ) .
Not shown:
165 c l o s e d p o r t s
PORT STATE SERVICE99/tcp open metagram100/tcp open newacct110/tcp open pop3120/tcp open cfdptkt130/tcp open cisco-fnaMAC Address:
Host i s up ( 0 . 0 0 0 4 2 s l a t e n c y ) .
Not shown:
165 c l o s e d p o r t s
PORT STATE SERVICE140/tcp open emfis-data150/tcp open sql-net160/tcp open sgmp-traps170/tcp open print-srv180/tcp open risMAC Address:
Fig. 7: An example of port scanning output with a virtualnetwork we built with custom NAT bindings to real servicesexisting on the victim virtual machine.execution 4 instances of the
Hydra brute force tool, targetsbeing the four virtual hosts. Results shown on the securitypanel of the scanner
VM appear in a timely manner, showingthe detection:
ET SCAN Potential FTP Brute-Force attempt with the source IP being a each virtual host, and the victim
VM as destination.Port scanning also triggers an alarm in our scanner ,promiscuous-mode connected VM, and what is more, onlaunching a complex scan from the attacker
VM (see [12]),many attack signatures trigger reactions at the level of the scanner
VM, including detection of binary payloads.
B. Performance
The first scenario for performance evaluation consists ofanalyzing the time required to add increasingly more virtual non-VM hosts to our network. We chose the network address , and added a number of
998 virtual hosts , eachperforming the following 5 NAT service redirections: • • • • • victim , attacker and scanner being , the IPrange of non-VM hosts is The plot below shows the behavior in time of the hostoperating system, as more non-VM virtual hosts are addedto the virtual network. , , , Number of hosts T i m e ( s ) Fig. 8: Running time by the number of hosts added to thenetwork.While the plot from Figure 8 shows that adding a virtualredirector non-VM host takes roughly one second, this isbecause the host operating system requires a considerablenumber of transactions to take place while configuring routes,interfaces and rules. In addition, resetting the network stateonly targets virtual machines, since virtual redirecting non-VM hosts solely redirect to services installed onto the victim virtual machine. The similar framework Mininet [7] requiresa similar amount of time for virtual non-VM host creation.The second scenario consists of automated running ofmalware Windows PE infected samples, in order to obtaina capture of their network traffic. The time required to run asample depends on the activity of the infected program. Withthe virtual network already created, once malware activitytook place, it only takes a few seconds to collect the networktraffic capture file, and restore state of virtual machines to theirpre-attack status, using snapshots. Therefore, within an hour,leaving each malware sample a time frame of 5 minutes, andwith a time of 5 seconds to restore virtual machine snapshotsor victim , attacker and scanner and save a *.pcap networkcapture from scanner or bridge level, an hour would allowcollecting network traffic from 11 infected programs. Whileappearing as a tedious process, malware research usually needsto allocate time for malware to manifest, 5 minutes beingconsidered a reasonable timespan.V. C ONCLUSIONS
Sandboxes are powerful tools for dynamic cyberthreatsanalysis but analyzing a threat in an isolated virtual machineis not enough to reveal the entire attack potential. We haveproposed a framework that addresses this issue by employingsoftware-defined networking concepts.Our framework can be used to define a custom virtualnetwork that resembles an entire home network or even acorporate network. The framework architecture was presentedboth network-wise and functionality-wise, describing the con-figurations that a user can perform in order to achieve thedesired results.Experimental results showed that the proposed system isable to detect common network attacks, while being able tosimulate even large networks (1000 virtual hosts) on commod-ity hardware. A
CKNOWLEDGMENT
Research supported, in part, by EC H2020 SMESEC GA
EFERENCES[1] C. Willems, T. Holz, and F. Freiling, “Toward automated dynamicmalware analysis using cwsandbox,”
IEEE Security & Privacy , vol. 5,no. 2, 2007.[2] A. Kharraz, W. Robertson, D. Balzarotti, L. Bilge, and E. Kirda, “Cuttingthe gordian knot: A look under the hood of ransomware attacks,” in
International Conference on Detection of Intrusions and Malware, andVulnerability Assessment . Springer, 2015, pp. 3–24.[3] C. Opris¸a, G. Cabu, and A. Takacs, “The ransomware strikes back,” in
Virus Bulletin conference , Berlin, Germany, 2013.[4] K. Rieck, T. Holz, C. Willems, P. D¨ussel, and P. Laskov, “Learningand classification of malware behavior,” in
International Conferenceon Detection of Intrusions and Malware, and Vulnerability Assessment .Springer, 2008, pp. 108–125.[5] K. Benzekki, A. El Fergougui, and A. Elbelrhiti Elalaoui, “Software-defined networking (sdn): a survey,”
Security and communication net-works , vol. 9, no. 18, pp. 5803–5833, 2016.[6] M. Team, “Mininet: An instant virtual network on your laptop (or otherpc)-mininet,”
Mininet. org , 2017.[7] R. L. S. De Oliveira, A. A. Shinoda, C. M. Schweitzer, and L. R.Prete, “Using mininet for emulation and prototyping software-definednetworks,” in
Communications and Computing (COLCOM), 2014 IEEEColombian Conference on . IEEE, 2014, pp. 1–6.[8] S. Shin, L. Xu, S. Hong, and G. Gu, “Enhancing network securitythrough software defined networking (sdn),” in
Computer Communica-tion and Networks (ICCCN), 2016 25th International Conference on .IEEE, 2016, pp. 1–9.[9] S. Achleitner, T. La Porta, P. McDaniel, S. Sugrim, S. V. Krishnamurthy,and R. Chadha, “Cyber deception: Virtual networks to defend insiderreconnaissance,” in
Proceedings of the 8th ACM CCS internationalworkshop on managing insider security threats . ACM, 2016, pp. 57–68.[10] T. S. Kondo and L. J. Mselle, “Penetration testing with banner grabbersand packet sniffers,”
Journal of Emerging Trends in Computing andInformation Sciences , vol. 5, no. 4, 2014.[11] E. Skoudis and T. Liston, “Counter hack reloaded,”
A Step-by-Step Guideto , 2006. [12] L. Allen,
Advanced Penetration Testing for Highly-Secured Environ-ments: The Ultimate Security Guide . Packt Publishing Ltd, 2012.[13] D. Burks, “Security onion,” nd.[Online]. Available: http://blog. securi-tyonion. net/p/securityonion. html.[Accessed 11 May 2014] , 2012.[14]