IoTective: Automated Penetration Testing for Smart Home Environments

Kevin Nordnes

, Jia-Chun Lin

2 a

, Ming-Chang Lee

2 b

and Victor Chang

3 c

Mnemonic AS, Oslo, Norway

Department of Information Security and Communication Technology,

Norwegian University of Science and Technology (NTNU), Gjøvik, Norway

Department of Operations and Information Management, Aston Business School, Aston University, Birmingham, U.K.

Keywords:

IoT, Smart Homes, Penetration Testing, Security Testing, Vulnerability Identiﬁcation, Network Scanning.

Abstract:

As the prevalence of Internet of things (IoT) continues to increase, there is a corresponding escalation in

security concerns. Given that many IoT devices lack robust security features, the need for specialized security

testing tools has become evident. In this paper, we introduce an open-source automated penetration testing tool

named IoTective for smart home environments in response to the increasing security concerns surrounding IoT

devices. IoTective aims to discover devices in Wi-Fi, Bluetooth, and Zigbee networks, identify vulnerabilities,

and gather valuable information for further analysis. IoTective streamlines the initial stages of reconnaissance,

planning, and scanning, which provides a good support for a variety of devices and protocols common used

in smart home environments. With a focus on ease of use and ﬂexibility, the tool provides an intuitive user

interface and customizable scanning capabilities. We evaluated the effectiveness of IoTective and explored the

impact on overall security posture. Ethical considerations for automated penetration testing are also discussed.

1 INTRODUCTION

The Internet of Things (IoT) has evolved and ex-

panded over the years, driven by technological ad-

vances such as the development of wireless tech-

nologies like Wi-Fi, Bluetooth, and Zigbee. In re-

cent years, IoT applications such as smart home au-

tomation, Industrial Internet, and connected cars have

entered the market. The growing accessibility of

cloud computing and big data analytics has further

driven the expansion of IoT, making it applicable

across diverse domains, including agriculture, man-

ufacturing, healthcare, and transportation (Khanna

and Kaur, 2019)(Tekeste Habte et al., 2019)(Zantalis

et al., 2019).

With the escalating prevalence of IoT devices, se-

curity and privacy concerns have grown (Alrawais

et al., 2017)(Lee et al., 2019). The surge in IoT

devices, often lacking security considerations, raises

substantial security issues, especially when these de-

vices access sensitive information on home networks.

Penetration testing is a cybersecurity method to eval-

uate the security of a computer system. It involves

https://orcid.org/0000-0003-3374-8536

https://orcid.org/0000-0003-2484-4366

https://orcid.org/0000-0002-8012-5852

identifying vulnerabilities within the system and at-

tempting to exploit these vulnerabilities to gain unau-

thorized access (Shah and Mehtre, 2015). While sev-

eral cybersecurity-related tools exist such as Nmap

Wireshark

, and Metasploit

, there is still a growing

demand for more specialized tools capable of auto-

mated security testing in home environments. This

demand arises from the diverse range of devices

and heterogeneous network protocols used in smart

homes. Existing penetration testing tools do not ad-

equately address the unique challenges posed by IoT

devices, necessitating the development of specialized

tools.

The paper aims to contribute to this space by creat-

ing an open-source automated penetration testing tool

called IoTective, which is tailored for testing the secu-

rity of IoT devices in smart home environments. The

paper addresses several research questions, includ-

ing the identiﬁcation of common vulnerabilities in

smart home environments and the effectiveness of au-

tomated penetration testing compared to manual test-

ing. Furthermore, it discusses the impact on overall

security posture and ethical considerations.

Nmap https://nmap.org/

Wireshark https://www.wireshark.org/

Metasploit https://www.metasploit.com/

Nordnes, K., Lin, J., Lee, M. and Chang, V.

IoTective: Automated Penetration Testing for Smart Home Environments.

DOI: 10.5220/0012554500003705

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 9th International Conference on Internet of Things, Big Data and Security (IoTBDS 2024), pages 29-39

ISBN: 978-989-758-699-6; ISSN: 2184-4976

Our primary objective is to develop an automated

tool to assist penetration testers in the initial stages

of reconnaissance, planning, and scanning. IoTective

simpliﬁes the process of collecting information about

a target network, making it more accessible and more

efﬁcient. Additionally, it provides support for a vari-

ety of devices and protocols commonly found in IoT

environments, which thereby enhances its applicabil-

ity.

IoTective is designed for ease of use and ﬂexibility

by prioritizing an intuitive user interface and provid-

ing customizable scanning capabilities. Ultimately,

we aim to provide users with a useful and efﬁcient

tool for automatically identifying potential security

issues in smart home environments. Furthermore, to

emphasize responsible usage, our tool employs pas-

sive techniques to minimize risks by collecting infor-

mation and discovering vulnerabilities without log-

ging private data. Users must have authorized access

to the network, with the tool restricted to private IP

addresses and refraining from any probing over the

Internet.

We demonstrate the effectiveness of IoTective

through a case study in a real-world smart home en-

vironment. The generated report presents a compre-

hensive range of information gathered from various

sources, protocols, and devices, effectively showcas-

ing the capabilities of IoTective.

The rest of the paper is organized as follows: Sec-

tions 2 and 3 introduce smart homes and their security

issues, respectively. Section 4 presents related work.

In Section 5, we introduce the design of IoTective.

Section 6 presents the implementation details and the

effectiveness of IoTective through a case study. In

Section 7, we discuss the impact of automated pene-

tration testing on security posture and ethical consid-

erations. Finally, we conclude this paper and outline

future work in Section 8.

2 SMART HOMES

A smart home is a speciﬁc application of IoT tech-

nology focused on the residential environment. It in-

volves the use of internet-connected devices to enable

remote control and automation of appliances and sys-

tems, including lighting, heating, security, and enter-

tainment. The goal of smart homes is to enhance resi-

dents’ quality of life by providing convenience, com-

fort, energy efﬁciency, and entertainment (Li et al.,

2021).

The popularity of smart home technology has

surged, especially among younger generations, driven

by the rapid development of IoT and innovations in

artiﬁcial intelligence. A 2020 report by Strategy An-

alytics projected a signiﬁcant increase in spending on

smart home technologies, from $120 billion in 2021

to $175 billion by 2025 (Ablondi and Narcotta, 2020).

It is anticipated that by 2025, nearly 390 million

homes worldwide will have at least one type of smart

system installed, accounting for 19% of all house-

holds.

Smart home automation systems typically utilize

a central hub or controller that connects to various

devices and systems in the home. This hub en-

ables remote control and monitoring of these systems

through a smartphone application, tablet, or com-

puter. Some smart home automation systems also

feature voice control capabilities, allowing homeown-

ers to use voice commands to manage their devices.

Moreover, smart home automation can involve the use

of sensors, such as motion detectors, to automate spe-

ciﬁc functions, like turning on lights when someone

enters a room. Additionally, these systems can be in-

tegrated with other connected devices, such as smart

thermostats and locks, providing a more comprehen-

sive and seamless automation of home functions and

enhancing user convenience.

3 SECURITY ISSUES IN SMART

HOMES

H. Touqeer et al. (Touqeer et al., 2021) provided

a comprehensive overview of security challenges in

IoT environments and described potential attacks at

the application layer, perception layer, network layer,

and physical layer of these environments. Consider-

ing that smart homes are one of the IoT applications,

those attacks are applicable to smart home environ-

ments.

Furthermore, many vulnerabilities associated with

the network protocols used in smart home environ-

ments have been reported. For instances, Zigbee is

exposed to a suite of vulnerabilities. One such in-

stance was discovered by Wara et al. (Wara and Yu,

2020) which included a replay attack on the Zigbee

protocol in IoT applications. The authors were able

to re-transmit captured packets to victim devices and

demonstrated this on Phillips Hue bulbs and Xbee

S1 and S2C modules. Zigbee is based on the IEEE

802.15.4 protocol speciﬁcation, which lacks robust

replay attack protection. This vulnerability has been

exploited multiple times, often using the KillerBee

tool (Pan, 2021). In addition, Zigbee maintains an as-

sociation table that records all child nodes associated

with the parent. A problem with the implementation

is that the records are not deleted when a child node

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

leaves the network after a power failure. Attackers

can exploit this by causing a frequent replacement of

child nodes, which consequently ﬁlls up the associa-

tion table, making it impossible for new child nodes

to join the network. Other attacks targeting Zigbee

can be found in (Hussein and Nhlabatsi, 2022) (Okada

et al., 2021) (Morgner et al., 2017).

Bluetooth Low Energy (BLE), also known as

Bluetooth Smart, is a wireless communication tech-

nology speciﬁcally designed for low-power, low-data-

rate applications (Heydon and Hunn, 2012). BLE is

also one of commonly used protocols in smart home

environments. The survey conducted by Casar et al.

asar et al., 2022) extensively examines the weak-

nesses and vulnerabilities present in BLE technol-

ogy. The authors delve into known vulnerabilities

and attacks that have been discovered during the eval-

uation of BLE development. Some of the promi-

nent attacks against BLE include snifﬁng, man-in-the-

middle (MITM), and jamming. The authors also iden-

tify various weaknesses, particularly those related to

privacy. These weaknesses encompass issues such

as device tracking, the ability to infer user behavior

through trafﬁc analysis, and the disclosure of user

location through mobile applications. Furthermore,

Barua et al. (Barua et al., 2022) provided an overview

of the threat model against BLE devices and discussed

some of the relevant vulnerabilities found in BLE.

Davis et al. (Davis et al., 2020) conducted a smart

home case study, identifying several vulnerabilities in

smart bulbs across four aspects: physical, network,

software, and encryption by utilizing Common Vul-

nerabilities and Exposures (CVE) and National Vul-

nerability Database (NVD). In addition, a vulnerabil-

ity discovered in Philips Hue published in December

of 2020 made the devices vulnerable to a DoS attack

. By performing an SYN ﬂood on port tcp/80, the

Phillips Hue’s hub will not respond until the ﬂood-

ing has stopped. During the attack, users are unable

to control the lights or use the vendor’s cloud ser-

vices. Another CVE published in January of the same

year showed that the Philips Hue was vulnerable to a

heap-based buffer overﬂow attack, enabling attackers

to perform remote code execution

. A DoS attack is

also possible for the Sengled Zigbee Smart Bulb de-

vices

CVE-2018-7580 Detail https://nvd.nist.gov/vuln/deta

il/CVE-2018-7580

CVE-2020-6007 Detail https://nvd.nist.gov/vuln/deta

il/CVE-2020-6007

CVE-2022-47100 Detail https://nvd.nist.gov/vuln/de

tail/CVE-2022-47100

4 RELATED WORK

PENIOT

is an open-source penetration testing tool.

It tests commonly used protocols such as Advanced

Message Queuing Protocol (AMQP), Message Queu-

ing Telemetry Transport (MQTT), Constrained Ap-

plication Protocol (CoAP), and BLE. The tool aims

for semi- or fully automatic generic security at-

tacks on IoT devices, offering protocol-speciﬁc at-

tacks through a graphical interface. Users select

an attack, input required information, and receive a

downloadable report after completion. The authors

planned additional features, including snifﬁng and at-

tacks against Zigbee and RPL, but due to time con-

straints and lack of required hardware, they were not

implemented. Besides, PENIOT has not undergone

extensive development since its launch and, as of the

time of writing this paper, it still relies on Python ver-

sion 2.7.

HomePwn

is a security testing tool primarily de-

signed for discovery and device enumeration and of-

fers support for only snifﬁng and MAC spooﬁng. It

supports MQTT, mDNS, Wi-Fi, and BLE, provides

an interactive command line interface, and supports

attacks like replay, injection, and eavesdropping. The

tool also provides documentation and resources for

users to understand the vulnerabilities and their poten-

tial impact. HomePwn was written to support Python

3.6; however, it remained unchanged without receiv-

ing any updates in the past 3-4 years.

KillerBee

is an open-source framework and test-

ing tool designed for exploring and exploiting the se-

curity of Zigbee and IEEE 802.15.4 networks. De-

veloped in Python, KillerBee allows researchers and

security professionals to sniff, inject, and manipulate

Zigbee network trafﬁc in real time. The tool can also

be used to conduct replay attacks, capture network

keys, and perform other forms of network analysis.

KillerBee only provides a classic command line inter-

face, and it was originally written in C and is currently

being ported to Python 3.5 or higher.

EXPLIoT

is an open-source framework de-

signed for security testing and exploiting IoT products

and infrastructure. It was written in Python 3, offering

both interactive and non-interactive command line in-

terfaces. EXPLIoT aims to support various IoT proto-

cols, hardware platforms, and IoT products. However,

some plugins necessitate hardware connectors to in-

PENIOT: Penetration Testing Tool for IoT https://gith

ub.com/yakuza8/peniot

HomePwn - Swiss Army Knife for Pentesting of IoT

Devices https://github.com/Telefonica/HomePWN

KillerBee https://github.com/riverloopsec/killerbee

EXPLIoT https://expliot.io/

IoTective: Automated Penetration Testing for Smart Home Environments

teract with the relevant protocol, and the functionality

may vary for each supported protocol. Despite these

considerations, EXPLIoT appears to be a comprehen-

sive framework due to its extensive protocol support

and wide range of attacks.

Different from the aforementioned frameworks,

IoTective employs protocols such as mDNS, Zig-

bee, Wi-Fi, and Bluetooth primarily for scanning and

snifﬁng purposes. Furthermore, our tool incorporates

a Graphical User Interface (GUI) implemented within

the terminal environment, offering users the ability to

interact with the tool using cursor-based actions. This

design positions it as a hybrid interface, seamlessly

combining features of both GUI and interactive com-

mand line interfaces. Notably, IoTective is developed

to be compatible with the latest iteration of the Python

programming language, speciﬁcally Python 3.11.

5 IoTective

Figure 1 illustrates the overall design of IoTective,

which consists of four phases: Initialization, Scan-

ning, Snifﬁng, and Reporting.

Figure 1: The overall design of IoTective.

In the initialization phase, users have the option

to tailor their testing by choosing from four avail-

able options: Network scanning, Wi-Fi snifﬁng, Blue-

tooth snifﬁng, and Zigbee snifﬁng. Network scan-

ning involves conducting an ARP (Address Resolu-

tion Protocol) scan to collect information about ser-

vices, ports, operating systems, and known vulnera-

bilities associated with the services in the target smart

home environment. Wi-Fi snifﬁng involves using

packet capture to identify the hosts connected to the

access point through Wi-Fi. Bluetooth scanning con-

ducts a regular Bluetooth scan to gather information

about services and their characteristics. Zigbee sniff-

ing utilizes packet capture to provide an overview

of Zigbee devices and their communications on each

channel.

If users choose the Zigbee snifﬁng option, they

must select a corresponding adapter, which is also a

requirement shared with network scanning and Wi-Fi

snifﬁng. In contrast, Bluetooth adapters can be con-

ﬁgured automatically by IoTective. After conﬁgura-

tion, the tool proceeds based on the user selection and

preference.

Moving on to the scanning phase, as illustrated in

Figure 2, IoTective initiates an ARP scan to quickly

discover all live hosts by obtaining their IP and MAC

addresses. Each IP address is then targeted for an

extensive nmap enumeration. This enumeration may

take varied time based on connection speed. IoTec-

tive is conﬁgured to probe the top 2000 ports of each

host to identify running services. Note that these ports

are set by Nmap and is a common way of using the

tool for optimizing efﬁciency. This number strikes a

balance between an exhaustive list, which would be

time consuming, and allowing the discovery of more

obscure ports, such as port 8123 used by Home As-

sistant. The enumeration also involves guessing the

host’s operating system and determining the accuracy

of that guess.

Figure 2: The Scanning phase of IoTective.

Following device enumeration, IoTective focuses

on ﬁnding the Philips Hue Bridge, which is a hub

connecting and controlling Philips Hue smart bulbs

and lights. This choice is made considering that the

Philips Hue Bridge is a widely used and popular cen-

tral component in the Philips Hue smart lighting sys-

tem, representing a common device in smart home

environments. IoTective initiates the process with an

mDNS lookup, a protocol often used by IoT devices

for local network service discovery and recommended

by Philips Hue

. The subsequent steps depend on

whether the bridge is discovered. If it is found, Io-

Tective proceeds to retrieve the conﬁguration of the

devices. Otherwise, IoTective utilizes a GET request

on the broker server URL, which provides the private

IP address of any Philips Hue bridge on the network.

How to develop for Hue? https://developers.meethue

.com/develop/get-started-2/

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

The bridge conﬁguration is then acquired by querying

https://⟨BRIDGE PRIVATE IP ADDRESS⟩/api/0/

config using the acquired IP address.

Figure 3: The Snifﬁng phase of IoTective.

If any of the four scanning/snifﬁng options is cho-

sen in the Initialization phase, IoTective proceeds to

the Snifﬁng phase, as depicted in Figure 3.

For Wi-Fi monitoring, IoTective collects informa-

tion by identifying the Wi-Fi network name, or Ex-

tended Service Set Identiﬁer (ESSID), of the con-

nected network. This name may either be the default

set by the manufacturer or customized by the network

administrator. While the network name helps in iden-

tifying the network, the actual data transmissions are

tagged with a different identiﬁer, the Basic Service

Set Identiﬁer (BSSID), which is unique to each access

point (AP). This is because multiple APs can share

the same ESSID to create a single, seamless network

across a larger area, allowing devices to connect to the

Internet regardless of which speciﬁc access point they

are connected to. After identifying all BSSIDs asso-

ciated with the ESSID, IoTective collects capture data

packets related to these BSSIDs. Any unique hosts

communicating via these BSSIDs are considered to

be connected hosts.

Bluetooth snifﬁng is a straightforward process. It

begins with a standard Bluetooth scan, allowing Io-

Tective to recognize all Bluetooth devices in the sur-

rounding area. Following this, the tool initiates con-

nections with each device, seeking to gather addi-

tional information about the services and character-

istics associated with each one.

In Zigbee snifﬁng, IoTective systematically

checks every ZigBee channel one by one. This is

done to capture trafﬁc across the entire ZigBee spec-

trum to ensure no communications are missed. Note

that ZigBee networks operate across various chan-

nels in the radio frequency spectrum, primarily in the

2.4 GHz band. As IoTective scans each channel, it

identiﬁes and records information about each host it

ﬁnds, including their personal area network identiﬁer

(PAN ID). All information gathered during the Sniff-

ing phase is added to the report before proceeding to

the ﬁnal phase.

In the last phase, the Reporting phase, IoTec-

tive takes the report as input and generates a JSON

ﬁle. This decision is driven by the capability of Tex-

tual

, a rapid application development framework for

Python, to automatically generate a navigation user

interface. This feature enhances user experience by

facilitating the navigation of information and devices

in the report.

6 IMPLEMENTATION AND CASE

STUDY

IoTective is developed using Python 3.11 on Kali

Linux. Python 3.11 is the latest version at the time

of writing. Python is an ideal language for penetra-

tion testing tools due to its user-friendly syntax, ﬂex-

ibility, and rich libraries. On the other hand, Kali

Linux is a Debian-based Linux distribution designed

for security-related tasks. It comes pre-installed with

numerous security tools and utilities, making it a pop-

ular choice among cybersecurity professionals, ethi-

cal hackers, and individuals interested in testing and

securing computer systems.

IoTective requires the user to have a wireless

adapter, a Zigbee adapter, and a Bluetooth adapter

capable of monitoring mode. This enables the tool

to conduct wireless, Zigbee, and Bluetooth network

analyses, capturing and scrutinizing network trafﬁc to

identify potential vulnerabilities. Additionally, the in-

clusion of Bluetooth support enables the tool to scan

and analyze Bluetooth Low Energy (BLE) devices.

To demonstrate the effectiveness of IoTective in

identifying vulnerabilities and weaknesses in smart

home environments, we deployed it in a real smart

home setup. The environment included a Ethernet-

connected Philips Hue Bridge, a Philips Hue Bloom

light, a Philips Hue motion sensor, a Philips Hue

smart plug, as shown in Fig 4. Additionally, the en-

vironment comprised other devices not visible in the

ﬁgure, such as a Samsung TV, smartphones, comput-

ers, and a Raspberry Pi running Home Assistant and

Pi-hole. Home Assistant

controlled the Philips Hue

Bridge and connected IoT devices, while Pi-hole

served as a network-wide advertisement and malware

blocker. The Raspberry Pi operated on the Raspbian

Textual https://textual.textualize.io/

Home Assistant https://www.home-assistant.io/

Pi-hole https://pi-hole.net/

IoTective: Automated Penetration Testing for Smart Home Environments

OS, with both Home Assistant and Pi-hole set up as

Docker instances. This comprehensive setup repre-

sented a diverse range of devices commonly found

in smart home environments, enabling IoTective to

thoroughly assess and identify potential vulnerabili-

ties across different types of connected devices.

Figure 4: A simpliﬁed illustration of the smart home envi-

ronment used.

6.1 The Initialization Phase

To assess the the capability of IoTective, we activated

all the options in the Initialization phase, as shown in

Figure 5. This allows us to gain a comprehensive view

of the tested smart home environment. It is clear that

the interface of IoTective is user-friendly as it did not

require users to input any commands, thus lowering

the barrier for conducting penetration testing.

Figure 5: The initialization interface of IoTective.

6.2 The Scanning Phase

The Scanning phase began with an ARP scan to

quickly identify and link all IP addresses to their cor-

responding MAC addresses in the local network. This

scan enables the identiﬁcation of all connected de-

vices, with MAC addresses providing vendor infor-

mation. The scanning result was presented in an easy-

to-read table on the command line interface of IoTec-

tive, as shown in Figure 6. From the scan, we ob-

served seven active hosts in the network, each accom-

panied by its respective MAC and IP addresses. The

last column provides additional information about the

vendor, which facilitates the identiﬁcation of devices

based on their manufacturer.

Figure 6: Results of the ARP scan shown on the command

line interface of IoTective.

After identifying the connected hosts, IoTective

proceeded to perform a comprehensive Nmap scan for

each device. This scan gathered information about

the operating systems, open ports, running services

on each port, and any known vulnerabilities associ-

ated with these services. Figure 7 shows the scan-

ning results for the Raspberry Pi, a device running the

Home Assistant software. The results revealed four

open ports, with port 8123 being particularly note-

worthy. This port is commonly used by Home Assis-

tant for web services over HTTP, which is known as

an insecure protocol due to the lack of encryption for

data transmission. Additionally, the scan identiﬁed

77 known vulnerabilities associated with the services

running on this port.

Figure 7: Results of the Nmap scan for the Raspberry Pi

deployed in the tested smart home.

Figure 8 shows the scanning results for the Philips

Lighting BV host in the network. As expected, the

host was identiﬁed as a Philips Hue bridge, with the

operating system recognized as Philips Hue Bridge

2.0. The host had open ports 80 and 443, indicating

the presence of a web server.

Once all the devices were enumerated, IoTective

searched for a Philips Hue bridge on the network.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

Figure 8: The result of the Nmap scan for the Philips Light-

ing BV host deployed in the tested smart home.

Without prior knowledge of whether a Philips Hue

bridge exists, the tool initiated an mDNS (Multi-

cast DNS) lookup using the address ” hue. tcp.local”,

commonly associated with Philips Hue devices. How-

ever, since the mDNS query did not yield a response,

IoTective then resorted to a cloud lookup by sending

a GET request to https://discovery.meethue.com. As

the bridge periodically queries the cloud to announce

its private network address, if the bridge exists, the

cloud lookup returns the device’s private network ad-

dress.

Having conﬁrmed the presence of a Philips Hue

bridge on the network and obtained its associated pri-

vate network address, IoTective gained crucial infor-

mation. Each Philips Hue bridge features an API

that allows other applications, such as Home Assis-

tant or custom-developed software, to control con-

nected smart devices. Most API commands require

authentication and authorization by the application.

However, the ”conﬁg” query serves as an exception,

providing signiﬁcant information about the bridge.

This information was acquired by querying https:

//⟨BRIDGE PRIVATE IP ADDRESS⟩/api/0/config,

and the outcome is presented in Figure 9.

The conﬁguration information includes properties

such as model ID, bridge ID, and name. Of par-

ticular signiﬁcance for both the users and IoTective

are the API version and software version, as certain

CVEs are associated with speciﬁc versions of the API

and software used by the Philips Hue bridge. En-

suring that the API and software versions are current

and patched is crucial for safeguarding against CVEs

like CVE-2020-6007 (a buffer overﬂow vulnerabil-

ity), and CVE-2017-14797 (deﬁciency in transport

layer encryption).

6.3 The Snifﬁng Phase

After the scanning phase, IoTective progressed to

the Snifﬁng phase, starting with the capture of Wi-

Fi packets. It determined the BSSIDs of the access

Figure 9: Conﬁguration information gathered from Philips

Hue bridge API.

point to which the wireless adapter was connected.

This was achieved by capturing IEEE 802.11 broad-

cast packets on each channel and ﬁltering them based

on the access point’s ESSID. This approach is used

to avoid relying solely on the BSSID provided dur-

ing Wi-Fi connection, as many routers support both

2.4 GHz and 5 GHz bands under the same ESSID.

Each band has its distinct BSSID, and ﬁltering based

on only one of them could potentially result in miss-

ing relevant packets.

After identifying all the BSSIDs, the tool pro-

ceeded to capture packets on each channel, applying

ﬁlters based on the BSSIDs to determine the band to

which each connected device was connected. Despite

the encrypted nature of the packets limiting the ac-

quisition of new information, IoTective successfully

established a mapping between MAC addresses and

the addresses discovered during the Scanning phase.

However, IoTective could only discover two out of

four connected hosts, which is likely attributed to

the 10-second time frame for capturing packets on

each channel, as not all devices may transmit pack-

ets within that short period.

After identifying Wi-Fi hosts, IoTective pro-

ceeded to perform Bluetooth snifﬁng. It captured

information such as device name, company name,

device local name (i.e., human-readable name), sig-

nal strength, and service UUIDs (Universally Unique

Identiﬁers). IoTective then attempted to establish a

connection with each device to acquire additional in-

formation, including services and characteristics. The

scan detected a total of 44 Bluetooth devices, with

only three of them permitting access to information

regarding their services and characteristics.

Finally, IoTective proceeded with Zigbee packet

capture on each Zigbee channel to identify devices

associated with each channel. This phase requires a

Zigbee USB dongle with packet capture capabilities,

such as the Texas Instruments CC2531

. The dongle

Texas Instruments CC2531. https://www.ti.com/produ

ct/CC2531

IoTective: Automated Penetration Testing for Smart Home Environments

had been ﬂashed with a custom ﬁrmware designed for

this speciﬁc purpose. Although the encrypted nature

of the packets limits the available information, IoTec-

tive successfully identiﬁed crucial details including

the channel, protocol version, PAN ID, etc. The scan

discovered hosts distributed across channels 15, 20,

and 25, with a total of ﬁve devices.

6.4 The Reporting Phase

Once the scanning and snifﬁng phases are completed,

IoTective offers users a convenient way to access the

scan results through the ”View Reports” option. The

reports are listed chronologically, with the most re-

cent report displayed at the top, as shown in Figure

10. Each report includes the date, time, and enabled

scan types for reference.

Figure 10: List of reports generated by IoTective.

By opening a speciﬁc report, users can view the

information obtained during the scan (for example,

see Figure 11). The report is generated using Mark-

down language and presents the data in a structured

format, allowing for easy navigation between devices.

In this particular run, Bluetooth enumeration was per-

formed separately, so the report states that Bluetooth

scanning was not conducted. The scanning and sniff-

ing processes took a total of 29 minutes and 55 sec-

onds, with Wi-Fi and Zigbee accounting for 24 min-

utes and 41 seconds, while Bluetooth scanning took 4

minutes and 14 seconds.

Examining the Zigbee device section of the re-

port reveals detailed information about each device,

as presented in the table shown in Figure 12. This

table includes relevant details such as the PAN ID,

router capacity, device capacity, Link Quality Indica-

tor (LQI), and protocol version, etc. By analyzing the

channel number and PAN ID, users gain insights into

nearby Zigbee networks. If they have a Zigbee device

capable of packet injection, further active tests can be

Figure 11: Scan information displayed in the report.

Figure 12: Zigbee device information displayed in the re-

port.

conducted using tools like KillerBee.

If we move to the network device section, we can

see all the network devices discovered by IoTective,

including the Raspberry Pi device and its information,

as shown in Figure 13.

Figure 13: Information about Raspberry Pi device gathered

by IoTective.

During runtime, IoTective gains visibility into

open ports on the host and the corresponding services

running on those ports. For each open port, the report

presents a list of potential vulnerabilities. Addition-

ally, the report includes information on the Common

Platform Enumeration (CPE), which standardizes the

naming of software applications, operating systems,

and hardware platforms. In this context, the CPE

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

refers to the service operating on the respective port.

Users can utilize this information for further analysis,

such as examining the source code of the software.

In the case of the Home Assistant service running on

the Raspberry Pi, IoTective detected 77 CVEs. In the

report, each CVE entry provide information such as

the CVE ID, the Common Vulnerability Scoring Sys-

tem (CVSS) score (offering a numerical representa-

tion of the vulnerability’s severity), vulnerability type,

and an indication of whether an exploit for the known

vulnerability exists.

Figure 14: The identiﬁed CVE-2016-5636 on the Home As-

sistant service.

One example is CVE-2016-5636, as shown in Fig-

ure 14, which relates to a vulnerability found in cer-

tain earlier versions of Python. This vulnerability in-

volves an integer overﬂow issue that could potentially

trigger a heap-based buffer overﬂow, enabling a re-

mote attacker to exploit the vulnerability. It is im-

portant to note that although this CVE is associated

with Python 3.10 in the identiﬁed CPE, it does not

exclusively apply to the Home Assistant software im-

plementation. Instead, it is relevant to any software

utilizing Python as a programming language. Further

investigation of the CVE ID reveals that this vulnera-

bility only affects Python versions below 3.5.2, indi-

cating that it does not pose a direct risk to the current

Python installation used by Home Assistant.

Figure 15 illustrates the information gathered

from a Sony WH-1000XM4 wireless Bluetooth head-

set. This data provides valuable insights for the user

to understand the device’s capabilities and function-

alities. The gathered information reveals that the de-

vice is a product made by the Sony Corporation with

the name ”LE WH-1000XM4,” which represents the

simpliﬁed name of the product. The local name,

which is usually a shorter or alternative name that can

be changed by the user, remains unchanged in this

case and is identical to the Bluetooth MAC address

of the device.

In Bluetooth technology, Received Signal

Strength Indicator (RSSI) indicates the signal

strength on the receiving unit’s antenna, providing an

estimation of the signal’s quality and proximity of

the Bluetooth device. On the other hand, TX power

refers to the amount of energy transmitted by the

sending unit’s antenna. Service UUIDs, represented

Figure 15: Information gathered from Sony WH-1000XM4

headset.

as 128-bit values, are used to uniquely identify

different Bluetooth services or proﬁles offered by

a device. Each Bluetooth device may support one

or more services, and each service is identiﬁed by a

unique UUID. When scanning a Bluetooth device,

the list of service UUIDs provides information about

the available services that the device supports. This

information is useful for determining the capabilities

and functionalities of the Bluetooth device.

Figure 16 illustrates an example of one of the ser-

vices identiﬁed on the Sony headset. Each service is

accompanied by a description, which in this case is

”Google Inc.” This could indicate that the headset has

some sort of integration with Google, which aligns

with the presence of Google Assistant as a feature ser-

vice on the Sony WH-1000XM4 headset.

Figure 16: Service information gathered from Sony WH-

1000XM4 headset.

Services further consist of ”characteristics,” which

are individual data elements within a Bluetooth ser-

vice that contain speciﬁc information or attributes.

Both the service itself and each characteristic have

unique UUIDs. An interesting attribute for the user to

consider is the properties associated with each char-

acteristic. These properties indicate the capabilities

of each characteristic, specifying what actions can be

performed, such as write, read, or notify. This infor-

mation can be valuable for further testing, enabling

the user to explore possible device modiﬁcations or

gather additional information.

IoTective: Automated Penetration Testing for Smart Home Environments

By examining the gathered Bluetooth device in-

formation, users gain insights into the manufacturer,

names, signal strength, transmission power, supported

services, and their associated characteristics. This

knowledge allows for a better understanding of the

device’s capabilities, potential integration, and possi-

ble actions that can be performed with the Bluetooth

device.

The combination of network scanning, Wi-Fi

snifﬁng, Zigbee snifﬁng, and Bluetooth snifﬁng en-

ables IoTective to provide a comprehensive view of

connected devices and their services. The report gen-

erated presents a comprehensive range of informa-

tion gathered from various sources, protocols, and de-

vices, showcasing the capabilities of IoTective.

7 DISCUSSION

Although automated penetration testing is effective in

identifying a broad range of vulnerabilities in smart

home environments, its effectiveness is contingent

upon the quality of the test cases and the skill of users.

Manual testing is indispensable for uncovering com-

plex vulnerabilities that cannot be identiﬁed through

automated means alone. While IoTective addresses

the initial phases of information gathering and scan-

ning, further analysis is needed for the assessment to

be comprehensive. Therefore, a combination of au-

tomated and manual testing is recommended for con-

ducting thorough security assessments of smart home

environments.

Automated penetration testing has a positive im-

pact on the security posture of a smart home envi-

ronment. It identiﬁes vulnerabilities, provides re-

mediation recommendations, reduces the attack sur-

face, reveals security gaps, and offers ongoing in-

sights into the environment’s security. However, it is

important to acknowledge that automated penetration

testing should not be the sole security measure in a

smart home environment. Implementing other mea-

sures such as regular software updates, strong pass-

words, and network segmentation is essential to en-

sure comprehensive security.

When it comes to ethical considerations, the de-

velopment and use of automated penetration testing

tools hold the potential to beneﬁt both legitimate users

and malicious actors. Therefore, ethical considera-

tions are paramount to ensure that these tools are em-

ployed exclusively for ethical purposes. This involves

obtaining user consent, preventing potential damage,

and restricting access to the environment used for test-

ing.

One crucial ethical consideration involves the risk

of collateral damage. Automated penetration testing

tools can inadvertently disrupt network services or

disable critical functions. Testing must be conducted

within a controlled environment to minimize the po-

tential for unintended damage. This challenge was en-

countered during the development of IoTective, par-

ticularly in scoping the tool to speciﬁcally scan for

relevant Bluetooth and Zigbee devices. While striv-

ing for automation and minimal user input, ﬁltering

out devices outside the scope proved challenging due

to limited information. As a compromise, IoTective

collects information from all devices in the vicinity

but does so with minimal disruption, focusing on au-

thorized information from publicly available sources.

Protecting users’ privacy is another critical ethical

consideration. Automated penetration testing tools

may collect sensitive information, such as passwords

or personal data, during the testing process. It is im-

perative to ensure that any data collected remains con-

ﬁdential and is not used for unauthorized purposes. In

the case of IoTective, no sensitive data is collected as

it does not attempt to exploit target devices. Only au-

thorized information is gathered and analyzed using

publicly available sources.

Furthermore, automated penetration testing

should only be conducted with explicit consent from

users. Providing clear information about the purpose

of the testing, potential risks involved, and the steps

taken to minimize those risks is vital. Users should

have the option to opt-out of testing if they are

uncomfortable with it. Additionally, testing should

comply with relevant laws and regulations, such as

data protection laws and regulations governing the

use of automated tools for security testing. Lastly,

it is essential to ensure that automated penetration

testing is conducted transparently and accountably.

This includes documenting the testing process, the

obtained results, and the steps taken to address

identiﬁed vulnerabilities in a clear and accessible

manner.

8 CONCLUSIONS AND FUTURE

WORK

In this paper, we have introduced IoTective, which

is an open-source automated penetration testing tool

for identifying vulnerabilities in smart home environ-

ments. While many existing tools focus on providing

a wide range of features, relying on analysts to select

and perform speciﬁc tasks, IoTective takes a different

approach by emphasizing automation and user expe-

rience. It does not aim to match the power and thor-

oughness of tools. Instead, it focuses on automating

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

aspects of the penetration testing process that demand

minimal expertise and involve substantial manual ef-

fort. As a result, IoTective can be seen as a valu-

able supplement to these other tools, which excel in

more specialized and aggressive security testing. By

automating repetitive and time-consuming tasks, Io-

Tective streamlines the initial stages of IoT device as-

sessment, enabling users to focus on more advanced

security analysis and exploitation techniques. The

use case demonstration illustrates IoTective’s ability

to automate the discovery of network interfaces and

devices, enhancing usability through ﬂexible scan op-

tions and user-friendly reports.

In our future work, we would like to further en-

hance and extend IoTective by investigating more ef-

ﬁcient solutions for capturing Bluetooth and Zigbee

network information, providing exploitation capabil-

ity, and incorporating support for additional commu-

nication protocols commonly used in smart home en-

vironments, such as Z-wave or other proprietary pro-

tocols. Additionally, we plan to establish a process

for regular updates and maintenance to ensure that

IoTective stays current with the latest security vul-

nerabilities, attack techniques, and changes in device

ﬁrmware and communication protocols.

ACKNOWLEDGEMENT

The authors want to thank the anonymous reviewers

for their reviews and valuable suggestions to this pa-

per. This work was partially conducted within the

SFI-NORCICS (https://www.ntnu.edu/norcics). This

project has received funding from the Research Coun-

cil of Norway under grant no. 310105 “Norwegian

Centre for Cybersecurity in Critical Sectors.”

REFERENCES

Ablondi, W. and Narcotta, J. (2020). 2020 Global Smart

Home Forecast - June 2020.

Alrawais, A., Alhothaily, A., Hu, C., and Cheng, X. (2017).

Fog computing for the internet of things: Security and

privacy issues. IEEE Internet Computing, 21(2):34–

42.

Barua, A., Al Alamin, M. A., Hossain, M. S., and Hossain,

E. (2022). Security and privacy threats for bluetooth

low energy in iot and wearable devices: A compre-

hensive survey. IEEE Open Journal of the Communi-

cations Society, 3:251–281.

asar, M., Pawelke, T., Steffan, J., and Terhorst, G. (2022).

A survey on Bluetooth Low Energy security and pri-

vacy. Computer Networks, 205:108712.

Davis, B. D., Mason, J. C., and Anwar, M. (2020). Vulner-

ability studies and security postures of IoT devices: A

smart home case study. IEEE Internet of Things Jour-

nal, 7(10):10102–10110.

Heydon, R. and Hunn, N. (2012). Bluetooth low energy.

CSR Presentation, Bluetooth SIG https://www. blue-

tooth. org/DocMan/handlers/DownloadDoc. ashx.

Hussein, N. and Nhlabatsi, A. (2022). Living in the Dark:

MQTT-Based Exploitation of IoT Security Vulnera-

bilities in ZigBee Networks for Smart Lighting Con-

trol. IoT, 3(4):450–472.

Khanna, A. and Kaur, S. (2019). Evolution of Internet of

Things (IoT) and its signiﬁcant impact in the ﬁeld of

Precision Agriculture. Computers and electronics in

agriculture, 157:218–231.

Lee, M.-C., Lin, J.-C., and Owe, O. (2019). PDS: Deduce

elder privacy from smart homes. Internet of Things,

7:100072.

Li, W., Yigitcanlar, T., Erol, I., and Liu, A. (2021). Motiva-

tions, barriers and risks of smart home adoption: From

systematic literature review to conceptual framework.

Energy Research & Social Science, 80:102211.

Morgner, P., Mattejat, S., Benenson, Z., M

uller, C., and

Armknecht, F. (2017). Insecure to the touch: attack-

ing ZigBee 3.0 via touchlink commissioning. In Pro-

ceedings of the 10th ACM Conference on Security and

Privacy in Wireless and Mobile Networks, pages 230–

240.

Okada, S., Miyamoto, D., Sekiya, Y., and Nakamura, H.

(2021). New LDoS attack in zigbee network and

its possible countermeasures. In 2021 IEEE Inter-

national Conference on Smart Computing (SMART-

COMP), pages 246–251. IEEE.

Pan, T. (2021). ZigBee Wireless Network Attack and De-

tection. In Advances in Artiﬁcial Intelligence and

Security: 7th International Conference, ICAIS 2021,

Dublin, Ireland, July 19-23, 2021, Proceedings, Part

III 7, pages 391–403. Springer.

Shah, S. and Mehtre, B. M. (2015). An overview of

vulnerability assessment and penetration testing tech-

niques. Journal of Computer Virology and Hacking

Techniques, 11:27–49.

Tekeste Habte, T., Saleh, H., Mohammad, B., Ismail, M.,

Tekeste Habte, T., Saleh, H., Mohammad, B., and Is-

mail, M. (2019). IoT for healthcare. Ultra Low Power

ECG Processing System for IoT Devices, pages 7–12.

Touqeer, H., Zaman, S., Amin, R., Hussain, M., Al-

Turjman, F., and Bilal, M. (2021). Smart home

security: challenges, issues and solutions at differ-

ent IoT layers. The Journal of Supercomputing,

77(12):14053–14089.

Wara, M. S. and Yu, Q. (2020). New replay attacks on zig-

bee devices for internet-of-things (iot) applications.

In 2020 IEEE International Conference on Embedded

Software and Systems (ICESS), pages 1–6. IEEE.

Zantalis, F., Koulouras, G., Karabetsos, S., and Kandris, D.

(2019). A review of machine learning and IoT in smart

transportation. Future Internet, 11(4):94.

IoTective: Automated Penetration Testing for Smart Home Environments