Simply put, sdnpwn (pronounced S-D-N-POWN) is a penetration testing toolkit for Software-Defined Networks (SDNs). While plenty of research has been done in the area of SDN security, the security community is still lacking a decent command line tool for experimenting with and testing for attacks in SDN. This article will provide an overview of the sdnpwn toolkit and its modules.

Related Work

Previous penetration testing tools have been created for SDN. Pickett [1] put together the “SDN-Toolkit” [2] for a talk at Blackhat Europe 2014. This set of tools included some for reconnaissance and others for attacking and exploiting vulnerabilities in controllers. However, this software was only designed to target Floodlight and OpenDaylight. The SDN security group from KAIST [3] developed DELTA [4]. DELTA is an automated penetration testing framework designed to run specific tests against networks and find new vulnerabilities in controllers through fuzzing. This works great if you’re in a position to perform a whitebox test, you’re only interested in the attack cases defined by DELTA, and you’re running SDN components which match the requirements for DELTA. Otherwise you’ll have some problems using the tool. DELTA currently supports certain versions of Floodlight, ONOS, OpenDaylight, and has support for Ryu coming soon. Although DELTA can be useful for automating security tests, it doesn’t reflect what’s needed for a complete penetration testing tool.

The Toolkit

Written in Python 3, sdnpwn aims to enable generic SDN attacks to be carried out while also allowing specific vulnerabilities to be exploited. Functionality in sdnpwn is divided up into separate modules. Each module contains the code used for a specific function or an attack, with other modules acting as libraries.


Getting sdnpwn is easy, just clone the Github repository for the latest version:

Next, make the script and the script executable:

The toolkit needs some additional software to work properly. The script will install all of the necessary software. This script may require root depending on your setup. It’s recommended to check any script like this before executing just to be sure nothing will go wrong.


As mentioned above, functionality in sdnpwn is divided into modules. These modules are executed through the core script. This is done like so:

Executing the script without any module will automatically execute the ‘help’ module. This module could also be executed like so:

The ‘mods’ module can be used to list and manage modules. The available modules can be listed by executing the module:

The modules shown in the output of the above command (shown below) contains all executable modules. Modules used as libraries will not be listed.

Each module is essentially it’s own tool with different options and parameters. A description and available options for a particular module can be printed using the ‘info’ module. The following command will print information for the ‘arpmon’ module:

Alternatively, executing a module with no parameters or executing it with the ‘-h’ option will usually print the same information.

Using the information printed about the arpmon module, it can then be used to watch ARP traffic on the eth0 interface with the following command:

A CLI is also available which can be accessed using the following command:

There is currently no benefit to using this CLI, but future work will see sessions being implemented which will make this useful.

Current Capabilities

As of writing this article sdnpwn has 17 modules; 3 reconnaissance modules, 4 management modules, and 10 attack modules.


The reconnaissance capabilities of sdnpwn are currently separated into 3 modules; arpmon, sdn-detect, and controller-detect. The arpmon module can be used to print information from ARP traffic captured at a certain interface. It’s nothing amazing, but it’s useful. The sdn-detect module is used to check whether or not a network is an SDN. It does this using the fingerprinting technique described in work by Shin et al [5]. The module works, however the detection rate need to be improved. The controller-detect module is used to fingerprint the network controller. It can be this by monitoring Link Layer Discovery Protocol (LLDP) traffic [6], or by enumerating the controller’s northbound interface. This module works well but is limited to being able to detect controllers for which sdnpwn has a profile for (i.e. Floodlight, OpenDaylight, ONOS, Pox, Beacon, and Ryu).


There are 4 modules used for management of sdnpwn; help, mods, info, and system. 3 of those modules have already been discussed. The system module can simply be use to execute commands. This isn’t useful outside of the sdnpwn CLI.


The rest of the modules are used for attacking the SDN and the SDN controller. The lfa-relay, lfa-scapy, and lldp-replay are all used to perform the Link Fabrication Attack (LFA) [7]. The host-location-hijack module is used to perform the host location hijacking attack [7]. The of-switch module can connect to a controller using OpenFlow version 1 with a custom switch configuration. This is useful for gathering default flows, testing control channel security, and exploiting vulnerabilities in the controller through the custom switch configuration. The of-gen module can generate OpenFlow messages which can then be used for flooding attacks or used alongside the of-switch module to perform more complex attacks against the controller. The dp-arp-poison, dp-mitm, phantom-host-scan, and phantom-storm are all implementations of attacks described in paper [8]. Future articles and tutorials will give a more in-depth look at each of the modules described in this sub-section.

Future Work

While all modules are functional, most can be improved or added to. More modules will be included to add other attacks against SDN to the toolkit. The of-gen and of-switch modules will be made to support other versions of OpenFlow and all OpenFlow message types. The modules designed for fingerprinting will have their accuracy improved.

Metasploit modules for various vulnerabilities in SDN components are being developed and will be released soon. These are being developed for Metasploit as the exploits are better suited to that type of framework. For this reason, it’s also planned to build an sdnpwn module to allow the Metasploit modules to be executed via sdnpwn.










What is sdnpwn?
Tagged on: