Cleaning up rogue IoT devices after a cyber breach

A post-breach investigation often focuses on laptops, servers, identities and cloud workloads. Internet of Things devices can be overlooked because they sit outside the traditional endpoint estate. Cameras, smart building controllers, printers, medical equipment, warehouse scanners, access systems and connected sensors may still hold credentials, communicate with command infrastructure or provide an attacker with a quiet route back into the environment.

For Australian organisations, the issue is especially relevant across distributed offices, retail sites, mines, logistics hubs and healthcare facilities. A rogue device in a Sydney head office may share the same management platform as equipment in Perth or Brisbane. Effective cleanup therefore requires more than unplugging suspicious hardware: security teams need to discover every connected asset, preserve evidence, contain malicious access and restore trusted operations without disrupting essential services.

Why IoT devices complicate post-breach response

IoT environments are rarely uniform. A business may operate equipment purchased by facilities teams, technology departments, contractors and specialist suppliers over many years. Some devices are recorded in a configuration management database, while others appear only in a switch log, wireless controller, building management console or vendor portal. Shadow IoT can therefore remain invisible during the first hours of an incident.

Many devices also have limited logging, weak update mechanisms or embedded credentials that cannot be changed easily. A camera may run an outdated operating system, a printer may retain email settings, and an industrial sensor may communicate through a gateway that obscures its true identity. These limitations make conventional endpoint detection and response less reliable.

The objective is to determine whether a device is compromised, exposed or simply poorly governed. A device should not be labelled malicious merely because it is unfamiliar. Analysts need to correlate its network behaviour, ownership, firmware, authentication history and physical location with the wider incident timeline.

Establishing an accurate device picture

Begin with passive discovery wherever possible. Collect DHCP leases, DNS requests, wireless association records, switch data, network access control events, firewall flows and cloud management records. Compare those sources with procurement data, facilities registers and supplier-maintained inventories. Passive collection reduces the risk of interrupting fragile equipment while the organisation is still preserving evidence.

Fingerprint each asset by manufacturer, model, firmware, operating system, MAC address, certificate, management interface and observed communications. Record the business owner, site, physical purpose and operational dependency. A barcode scanner used in a Melbourne distribution centre should receive a different treatment from an unused smart display in a meeting room.

Network traffic can reveal useful anomalies. Look for new outbound destinations, unexpected DNS providers, connections to residential proxy services, repeated authentication failures, unusual data volumes and management traffic outside approved maintenance windows. A camera that suddenly contacts an overseas host, or a building controller that begins scanning internal addresses, deserves immediate investigation.

Email-connected devices need particular care. Attackers may alter forwarding rules, relay settings or notification destinations to maintain visibility after credentials are reset. Analysts reviewing mail-enabled printers and scanners should also understand how a legitimate auto-forwarder differs from a spoofing relay, so normal automation is not confused with persistence.

Containing suspicious connected equipment

Containment should be proportionate to the device’s risk and operational role. A high-confidence malicious device can be disconnected, moved to a quarantine VLAN or blocked at the switch port. For equipment supporting patient care, public transport, production or emergency functions, abrupt isolation may create a safety issue. The incident commander should involve the service owner before taking disruptive action, while applying network restrictions as quickly as the situation allows.

Useful controls include blocking unapproved outbound traffic, denying east-west communication, disabling exposed management protocols and forcing access through a monitored jump host. Where a device cannot support modern authentication, place it behind a tightly controlled gateway. Segmentation should limit what the device can reach rather than assuming that its local network is trusted.

Device situation Immediate action Evidence to preserve Recovery decision
Unknown device with active suspicious traffic Quarantine or block its port Flow records, DHCP data, screenshots and timestamps Rebuild or replace after ownership is confirmed
Known device with vulnerable firmware Restrict communications and management access Firmware version, vendor advisories and configuration Patch, upgrade or isolate permanently
Critical device that cannot be disconnected Apply ACLs and enhanced monitoring Process impact, network sessions and operator notes Coordinate controlled maintenance with the supplier
Device showing signs of credential abuse Revoke tokens, rotate secrets and review peers Authentication logs, certificates and account activity Re-enrol with unique credentials
Unused or unauthorised asset Remove from the network and retain for analysis Physical identifiers and chain-of-custody records Dispose of it securely or return to the owner

A quarantine decision should be documented with the time, authority, technical control and expected business impact. This record helps responders explain why a device remained online, why a site lost service or why a supplier was asked to attend urgently.

Removing persistence and rebuilding trust

Eradication begins after the organisation understands the attacker’s access path. Reset local and service credentials, replace default passwords, revoke certificates, invalidate tokens and remove unauthorised accounts. Check associated management consoles because an attacker may have created a new administrator there rather than altering the device itself.

Reflash firmware or factory-reset equipment only when the approved procedure is understood and evidence has been captured. A reset can destroy useful artefacts, remove malicious files and eliminate configuration details needed for the investigation. For high-risk devices, retain a forensic image or photograph of the configuration before rebuilding.

Firmware should come from a verified vendor source, with cryptographic signatures checked where supported. Do not assume that the latest available package is suitable for every model or deployment. Confirm compatibility, document the change and test the device in an isolated network before returning it to production.

Replacement is often safer than attempted cleaning when a device has an unsupported operating system, an unknown firmware provenance, hard-coded credentials or no reliable reset process. Australian organisations should account for local supply and service constraints, particularly where specialised equipment is imported and replacement stock may take weeks to arrive.

Restoring services with operational checks

Recovery should proceed in stages. Place rebuilt devices in a restricted segment, verify their baseline behaviour and monitor DNS, authentication and outbound connections. Reintroduce access only after the device has a named owner, an approved purpose and a documented communication profile.

The following checks help teams avoid restoring an asset that still carries the original weakness.

Operational teams should test the service that depends on the device, not just whether the device powers on. A warehouse scanner may connect successfully while failing to submit inventory data. A building controller may appear healthy while losing alarms when a management server is blocked. Recovery acceptance should therefore include business validation and security monitoring.

For larger environments, create a temporary heightened-monitoring period after restoration. Review authentication events, configuration changes, unusual traffic and repeated connection attempts from previously quarantined addresses. A device that behaves normally for several hours but later re-establishes the original command path may indicate incomplete eradication or a compromised management platform.

Making IoT resilience part of security governance

Post-breach remediation should result in durable changes to procurement, architecture and incident response. Require suppliers to disclose supported firmware versions, security update periods, default account behaviour, logging capability and remote access arrangements. Contracts should define who can access the device, how access is recorded and how quickly vulnerabilities must be reported.

Australian organisations can map these controls to the Essential Eight where relevant, particularly secure configuration, patch applications, restricted administrative privileges and multi-factor authentication around management systems. Entities regulated by APRA should also consider how connected devices fit within CPS 234 expectations for information asset protection, control assurance and incident response. The exact control design will vary by sector, but unmanaged IoT should not sit outside the risk register.

Run exercises that include facilities staff, managed service providers, suppliers and local site managers. A tabletop exercise based in Sydney may expose different dependencies from one involving a remote mining operation in Western Australia. Include questions about physical access, replacement equipment, third-party remote support and the safe isolation of devices that affect people or production.

Two practical review cycles can keep the environment accountable:

Security operations should feed lessons from each incident into detection content and asset records. A rogue printer, camera or sensor may reveal a broader weakness in supplier access, wireless design or identity management. Treating the device as an isolated nuisance misses the control failure that allowed it to become useful to an intruder.

Coordinating a defensible response

A coordinated response combines technical investigation with clear decision-making. Security teams should maintain a timeline covering initial access, device discovery, containment, credential changes, firmware actions and service restoration. Preserve logs from network infrastructure and vendor portals before retention periods remove them, and record who authorised each major action.

External specialists may be needed when the environment includes operational technology, medical devices or proprietary equipment. Their work should fit the organisation’s evidence-handling process rather than creating a parallel investigation. Suppliers can provide firmware and diagnostic support, but access should be time-limited, monitored and approved through the incident command structure.

Communication also matters. Staff should know why a device has been removed, how a temporary process works and which support channel is legitimate. Customers and regulators may require notification depending on the data involved, the affected sector and the circumstances of the breach. Clear records allow the organisation to distinguish confirmed compromise from exposure, suspected activity and ordinary technical faults.

The central lesson is that IoT cleanup is an identity, network and supply-chain problem as much as a device problem. Find every connected asset, preserve evidence before resetting it, contain communications according to business risk and rebuild only from trusted firmware and credentials. When each device has an owner, an approved purpose and observable behaviour, rogue equipment becomes far less likely to provide an attacker with a second foothold.