DEV Community: IntSpired®

Back to the Sky

IntSpired® — Wed, 11 Nov 2026 08:16:07 +0000

Earlier this year, we turned our attention to the satellites overhead.

Four posts. One question: how exposed is the satellite and RF layer the world now depends on?

March: Satellite Signals Are Easier to Observe Than Many Realise

A laptop, an SDR and the right software were enough to watch satellite activity cross the waterfall in real time. The post also discussed separate academic research showing that some GEO satellite links carry unencrypted traffic.

Image 1: SDR monitoring setup used to observe satellite activity in real time.

Read the full post → https://intspired.co.uk/blog/f/satellite-signals-are-easier-to-observe-than-many-realise

May: Hardware Not Required: WebSDR and the Open RF Layer

Exploring satellite signals does not always require your own receiving equipment. This post looked at how publicly accessible WebSDR receivers open up the RF spectrum to anyone with an internet connection.

Image 2: Qatar-OSCAR 100 at Goonhilly Earth Station, Cornwall. Live satellite RF from Es’hail-2, streamed through a browser.

Read the full post → https://intspired.co.uk/blog/f/hardware-not-required-websdr-and-the-open-rf-layer

June: Tracking Down a 1964 US Navy Satellite No One Could Switch Off

Transit 5B-5. Launched in 1964. Still transmitting decades after its operational life ended. Using orbital data from CelesTrak and our ground station coordinates, we could predict when it would cross our horizon.

Image 3: Tracking Transit 5B-5 and predicting its pass over our location.

Read the full post → https://intspired.co.uk/blog/f/tracking-down-a-1964-us-navy-satellite-no-one-could-switch-off

Watch the short video of the pass on LinkedIn → https://www.linkedin.com/feed/update/urn:li:activity:7467236032044933122/

June: Satellite-to-Phone Connectivity

Ordinary smartphones are starting to connect directly to satellites. These connections bring satellite infrastructure into everyday mobile communications.

Image 4: How beamforming focuses satellite signal power towards a coverage area.

Read the full post → https://intspired.co.uk/blog/f/satellite-to-phone-connectivity

The common thread: signals people assume are invisible are often observable. Understanding what those signals reveal is part of assessing the risks to satellite-dependent systems.

Satellite dependence is growing. Jamming, spoofing and interference can disrupt the navigation, timing and communications those systems provide.

For the rest of 2026, we are going deeper:

The threats facing satellite-dependent systems
Detecting interference
Locating its source
The cyber side of space systems

This work leads into IntSpired’s RF interference investigation service, planned for 2027.

IntSpired®

From Local Broadcast to Networked Drone Intelligence

IntSpired® — Wed, 04 Nov 2026 15:33:33 +0000

Remote ID is designed to make a drone visible, and in the UK that visibility is now part of the regulatory landscape. From 1 January 2026, Direct Remote ID became mandatory for several UK drone classes, with broader requirements due from 1 January 2028.

Direct RID broadcasts identification and location information over Wi-Fi or Bluetooth to compatible receivers within range. For anyone working in wireless security, that is a familiar pattern: identifying data broadcast openly to anyone nearby. Receiving it is not a vulnerability; it is the whole point. But something changes when those local observations are networked, and a current US example shows what that can look like in practice.

From reception to aggregation

FliteGrid, a community-hosted Remote ID network built by SkySafe, pays hosts to run outdoor sensors. Hosts provide an outdoor location and power, and SkySafe provides a sensor that receives nearby Remote ID broadcasts and sends them back over built-in LTE. Eligible hosts receive $50 USDC per qualifying month, subject to uptime requirements, although the programme is limited to the continental United States and shipments are still pending. SkySafe says the network helps airports, public safety teams and infrastructure operators understand what is flying nearby, and that its wider network had tracked more than one million flights by 2025.

What matters is less the sensor than the architecture: drone → local broadcast → sensor → LTE → central platform. A single receiver sees a flight, limited by radio range and time. A network can start to see behaviour.

When observations become patterns

One reception shows a drone was in a particular place at a particular time. Repeated observations reveal where it tends to appear, how often it returns and whether the same identifier shows up across multiple collection points. None of this needs the broadcast to carry extra information; the intelligence comes from correlation. In the US, Standard Remote ID broadcasts include the control station location, while broadcast modules use the take-off location; in EU U-space, the network identification service carries the remote pilot’s position or take-off point. Correlated observations can therefore reveal not just where drones fly, but where they are flown from.

The security boundary gets bigger

The first questions sit at the radio layer, and anyone who has tested Wi-Fi or Bluetooth systems will recognise them. How does a receiver know a broadcast came from a genuine drone? What happens if fabricated broadcasts are injected? How does the system behave when the channel is congested or deliberately disrupted? In a standalone receiver, a false broadcast affects one local view. In an aggregation network, it flows into a shared dataset that other people rely on.

Beyond the radio, the attack surface includes sensors, device identities, update mechanisms, APIs and cloud infrastructure. Can the platform trust that a sensor is where it claims to be? How are firmware updates validated? Who can query historical observations, and for how long? None of this is a claim that FliteGrid or any other platform is vulnerable. These are the questions that arise whenever a local radio observation becomes part of a larger intelligence system.

The collection network has intelligence value too

FliteGrid publishes a hex-based hosting map showing areas that are available, requested or claimed by the community. With deployments still pending, it is not a live coverage map.

Image: FliteGrid’s public hosting map. https://flitegrid.io/map

Even so, it points to a wider issue: the network doing the observing can itself become worth understanding. Around airports, prisons, ports and energy infrastructure, knowing where collection is being prioritised may be valuable to defenders and potentially to adversaries.

Remote ID is not complete drone detection

Remote ID only helps when a drone is transmitting it. A drone that isn’t broadcasting may need radar, optical sensing or other RF techniques.

Why this matters in the UK

The UK is starting with Direct Remote ID, but the Civil Aviation Authority describes Hybrid RID as its preferred long-term solution, with Direct RID as the interim step. Hybrid RID adds Networked RID, which sends information over the internet to a central service accessible to authorised users. Europe is moving the same way: within designated U-space airspace, EU rules require a network identification service that continuously processes Remote ID and provides aggregated data to authorised users. FliteGrid matters here not because the same service is likely to arrive in Britain, but because it shows how distributed Remote ID collection is being built in practice.

From signal to intelligence

Remote ID begins as a local broadcast. A receiver turns that broadcast into an observation, a network turns observations into a dataset, correlation turns the dataset into patterns, and context turns those patterns into intelligence. The interesting security question is no longer simply who can hear the signal. It is who can build the picture.

IntSpired® | Offensive by design

Auditing IP Camera Exposure with Cameradar

IntSpired® — Tue, 27 Oct 2026 14:51:58 +0000

Part 4 of 4 in the series: Wireless and Wired IP Camera Exposure

The first three parts moved from finding cameras, to reading what an exposed endpoint reveals, to looking inside the device itself. Each one ended at the same door: a thing that might be a weakness, waiting to be proven one way or the other.

This part walks through that door. The final step is validation.

Finding an RTSP service doesn't tell you the stream is accessible. An authentication prompt doesn't tell you the credentials are weak. A tool reporting a camera doesn't tell you it's vulnerable. So for the finale, I put that distinction on the bench and tested it with Cameradar against a camera in my own environment.

Where Cameradar fits

Cameradar is built to assess RTSP-enabled camera infrastructure. It discovers RTSP services, identifies stream paths, detects authentication methods and tests supplied or candidate credentials. That makes it useful for both discovery and validation, but its real value here comes after reconnaissance has already walked you to an endpoint.

By this stage, whether the camera reached the network over Wi-Fi or Ethernet barely matters. The question is no longer how it got there. It's what the endpoint exposes, and what actually happens when you test it.

Image 1: Cameradar running in the test environment, showing options for target discovery, RTSP ports, custom routes, credential dictionaries and stream validation.

Start with the endpoint

Before asking Cameradar to do anything clever, I wanted a baseline. A targeted Nmap scan against the camera put RTSP on TCP/554, alongside a handful of other services.

That's useful, but it's only discovery. An open RTSP port confirms the service is reachable. It says nothing about whether a stream will actually play.

Image 2: Initial service discovery against the authorised camera. Nmap identifies RTSP on TCP/554 alongside other reachable services. Device identifiers have been redacted.

Discovery is not access

So I pointed Cameradar at it and let it work. It found the RTSP endpoint, detected Digest authentication, and tested its available credential set against the service.

The camera stopped it dead:

401 Unauthorized

Accessible streams: 0.

This is the run that matters most, and it's the one a dramatic writeup would be tempted to skip. An unauthenticated attacker, armed with the same tool, reaches this camera and still doesn't get the stream. The service is there. It's reachable. It's enumerable. And it stays shut against the credentials this run tried.

Image 3: Cameradar discovers the RTSP endpoint and identifies Digest authentication, while access stays blocked without valid credentials.

That 401 is not a failed assessment. It's evidence. A reachable service is part of the attack surface; it does not follow that the control protecting it has failed. This is the exact gap between exposure and compromise the whole series has been circling.

What authorised access actually looks like

In a real engagement, the next move is to test with credentials the client has authorised. I used a local camera account and the known RTSP stream path, and ran the same tool again.

This time it walked straight through. Cameradar detected Digest auth, accepted the credentials, and completed the handshake the first run never reached:

Route found → /stream1 → auth accepted → DESCRIBE 200 → SETUP 200 → stream validated

Accessible streams: 1. Availability: yes.

Image 4: Authorised RTSP validation. Cameradar identifies the /stream1 route, authenticates with the supplied camera account and confirms the stream is available.

Nothing about the camera changed between the two runs. Same device, same service, same authentication, same tool. The camera didn't become vulnerable. The assessment moved from unauthenticated discovery to authorised validation, and the difference between “0 streams” and “1 stream” was a valid credential supplied for the test.

That's also the honest limit of this run. I supplied the credential because the device is mine. On a real target you rarely have that luxury, and this is where a credential attack earns its place: when valid logins aren't already in hand, the next step is to try to recover them. Cameradar's dictionary is the first, cheapest pass at that, and against an unchanged default it can be enough on its own. Against anything stronger it's only the opening move: a larger or targeted wordlist, the model's documented defaults, or the HTTP panel Cameradar locates but doesn't attack. Those are heavier, noisier steps, and they belong strictly inside an engagement scoped to allow them.

The tool still needs an assessor

It wasn't quite that clean, and the rough edge is the most useful part.

On the authorised run, Cameradar initially latched onto the authentication response on the root RTSP path, treated it as the default route, and wouldn't carry through to the camera's known /stream1 path. I'd already validated that stream independently, so the behaviour pointed back to the tool rather than the camera. A small adjustment to the route-handling logic got Cameradar through the intended custom route and let it finish the validation.

That's the whole argument for why tool output is never the finding. Automated tools accelerate an assessment; they don't remove the need to understand the protocol, question an unexpected result, and tell the difference between a real weakness and a limitation in the tooling. The first answer was incomplete, and independent validation exposed the limitation.

What the assessment actually established

What the run produced is a set of facts, not a finding: a reachable service, enforced authentication, and a validated stream on supplied credentials. None of it, on its own or together, is a vulnerability. It describes the exposure and the controls around it, which is the point.

Bringing the series together

Across four parts, the assessment moved through four layers:

Reconnaissance → exposure → device trust → validation

The recurring lesson is simple: finding something is not the same as compromising it.

A camera can be visible without being vulnerable. A service can be exposed and still enforce authentication. A tool can produce technically correct output that needs context before it becomes a finding.

The tool supports the process. The assessment comes from understanding what the evidence actually means.

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

One practical note. One of the cheapest attacks here is credential guessing. Change factory defaults on deployment, use unique passwords that won't appear in common wordlists, and keep firmware current. That is often enough to turn a quick opportunistic attempt into work an exposed camera simply isn't worth.

Cameradar: github.com/Ullaakut/cameradar

Inside the Camera

IntSpired® — Tue, 20 Oct 2026 05:49:01 +0000

Part 3 of 4 in the series: Wireless and Wired IP Camera Exposure

The lens is the part everyone looks at. It is also the least interesting part of the attack surface.

Point a camera at the internet and the obvious question is what can it see. But the video feed is only the front of the device. Behind it sits an embedded computer with its own accounts, network stack, storage, update mechanism and relationships with other systems, and most of that surface has nothing to do with the picture on screen.

So an assessment doesn't stop when the feed has been examined. That's where it starts getting interesting.

More than a lens

Strip away the housing and an IP camera looks less like an appliance and more like a small server. It runs an operating environment. It serves web pages. It stores footage, streams it, and may speak several network protocols to do so.

Each of those functions is something a device has to trust to work: a login it honours, a configuration it accepts, an update it applies, a peer it talks to. And every point of trust is a place where the wrong answer to “should I allow this?” becomes someone else's foothold.

Image 1: Camera attribute and device configuration interface, with the live view alongside controls for exposure, white balance, day/night mode and IR settings.

The screen above is the friendly face of that trust. Image tuning is harmless enough on its own, but it sits inside the same administrative surface that governs network settings, storage and system management. Reaching this page at all tells you something about how the device decides who is allowed to change it.

The accounts a camera honours

Which brings us to the first real question of internal exposure: not can I see the camera, but who does the camera believe it should listen to.

The administrative interface is often the centre of gravity for the whole device. It controls network configuration, logging, storage and the accounts themselves, and the account model is often more revealing than any single setting.

Image 2: User management interface showing local accounts, group membership and administrative permissions.

A page like this answers questions a screenshot of a login prompt never could. How many accounts exist? Are there standing service or maintenance logins nobody rotates? Is anonymous access an option someone left switched on? A device can enforce a strong password on the admin account and still trust a forgotten maintenance user, or an “operator” whose permissions quietly include far more than operating.

None of that is proof of a weakness. It's a map of what the device is willing to honour, and therefore what deserves validation on equipment you own or inside an engagement you're authorised to run.

The firmware a camera accepts

The sharpest trust decision a camera makes is the one about its own code.

If a device offers firmware upload, three questions become critical. Where does the update come from? Who is allowed to start it? And, crucially, how does the device decide the file is genuine before it runs it?

Image 3: Firmware upgrade interface with a local import field and controls for initiating a device update.

That last question is the one that matters. If a camera does not adequately verify the authenticity and integrity of a firmware image, an attacker may be able to replace that image with their own. At that point, the issue is no longer about working around an individual control. It is about running code on a device that will trust it.

This is why it sits so high on the attack surface. Authentication, storage and streaming are individual functions; firmware defines how those behave in the first place. Whether a device properly verifies its updates is, once again, a validation point: never something to assume from an import field, and never something to test against a camera you merely found exposed.

The systems a camera trusts

Trust rarely stops at the device edge. A camera may communicate with a Network Video Recorder (NVR) or Video Management System (VMS), reach out to a cloud service, and share network access, credentials or other trust relationships with adjacent systems.

That turns a single exposed camera into a question about everything it can reach. A device on a flat network with a trusted path to the recorder is a very different finding from the same device isolated in its own segment. The camera may be the thing you found, but it's rarely the thing that matters most.

Why this is the real attack surface

A camera can lock down its video stream perfectly and still be exposed elsewhere: an account it shouldn't honour, a firmware image it shouldn't accept, a recorder it trusts too readily.

That's the point of looking inside. The feed tells you what a camera sees. The device tells you what it will allow. Assessing one without the other is how a system passes a review and fails in reality.

Next week: Part 4 — Auditing IP Camera Exposure with Cameradar

We bring the series together with a practical look at auditing IP camera exposure with Cameradar.

IntSpired®

Offensive by design.

From Connection to IP Exposure

IntSpired® — Thu, 08 Oct 2026 05:21:53 +0000

Part 2 of 4 in the series: Wireless and Wired IP Camera Exposure

Reconnaissance tells you a camera exists. It doesn't tell you what it's actually giving away.

The next stage is finding out what that endpoint actually exposes.

Once an IP camera is reachable, the assessment moves beyond simply identifying the device. The focus shifts to the information and services around it: live video, browser interfaces, authentication, management functions and network facing protocols.

What does exposure actually look like?
Exposure isn't one thing, it's a stack. A single reachable camera might hand over a live view of a factory floor, staff moving through a building, a front entrance, parked vehicles, a private residence, a management interface, a streaming service - sometimes all at once.

Image 1: Publicly reachable cameras identified during reconnaissance. As a precaution, specific details have been redacted.

What the live feed exposes
A live view can be accessible without any administrative access. What matters is whether that visibility was intended to be public, how the video is delivered and what controls, if any, sit behind it.

One common way IP cameras deliver video is through RTSP, the Real Time Streaming Protocol. The presence of RTSP is not itself a vulnerability.

The key questions to consider are reachability, authentication, access control and exposure beyond the intended network or audience.

Management interfaces expose another layer

Beyond the live feed, many IP cameras expose a browser based management interface, and that page is often chattier than it should be, revealing the manufacturer, model, firmware version, available functions and how access is controlled, sometimes before you have logged in at all.

Image 2: Publicly reachable Dahua IP camera login interface identified during reconnaissance. The IP address has been redacted.

This is a different category of exposure than simply seeing a live feed. In this example, the interface is being served over plain HTTP rather than HTTPS, meaning the connection itself is not protected by transport encryption. In an authorised test, an intercepting proxy such as Burp Suite can show exactly what the browser submits during authentication, including whether credentials or other sensitive values are exposed in readable form. That transport weakness exists regardless of how strong or weak the password ultimately turns out to be.

The question now shifts from:

Can I see the camera?

to:

What can someone who reaches this endpoint actually do?

Authentication matters
Once the manufacturer is known, default credentials and old configuration guides are usually one search away. So an exposed login page raises two separate questions, not one: are credentials protected in transit, and does the device still accept weak or default logins? Neither can be assumed from a screenshot. Both are things you test on equipment you own, or inside an assessment you're explicitly authorised to run.

The same logic extends to firmware and known CVEs. Identifying the interface is enough context to research the product family and figure out which published issues are actually relevant to the device in front of you.

Known authentication bypasses
The Dahua interface above gives us a concrete product family to research, and this is where the paper trail gets serious. CVE-2021-33044 is a critical improper-authentication flaw (CWE-287), publicly disclosed in September 2021 with a CVSS v3.1 base score of 9.8. It affects a specific range of Dahua IP cameras, thermal cameras, and VTH/VTO video intercom devices, and it's now listed on CISA's Known Exploited Vulnerabilities catalog - meaning this isn't theoretical, it has documented real-world exploitation. A publicly available research tool demonstrates the flaw directly: it targets the login process and, per its own description, bypasses authentication on affected devices whose firmware predates the vendor's fix. Whether any of that is relevant to a specific camera comes down to one question: does the identified model and firmware version actually fall in the affected range? Outside that range, the CVE is irrelevant noise. Inside it, the issue becomes a validation point - and validation happens on owned equipment or inside an assessment you're explicitly authorised to run, never against something you just found exposed on the internet.

Image 3: A Dahua Login Bypass research extension referencing CVE-2021-33044. Shown for research and identification purposes only. It was not run against the publicly identified camera above.

Separate the levels of exposure
Finding a camera service, viewing a stream, reaching a management interface, authenticating to the device and obtaining administrative control are separate outcomes. Reporting each one clearly defines what has been observed and what still requires validation.

Reconnaissance determines where to look. Part 2 shows what the endpoint actually exposes and which controls warrant further assessment.

Next week: Part 3 — Inside the Camera
In Part 3, we move beyond exposed services and into the camera itself, examining firmware, local users, configuration, storage, update mechanisms and how the device fits into the wider network environment.

IntSpired®
Offensive by design.

Reconnaissance Comes First

IntSpired® — Tue, 15 Sep 2026 09:32:46 +0000

Part 1 of 4 in the series: Wireless and Wired IP Camera Exposure

Understanding the client’s exposure before deeper assessment

IP cameras can reach a network in different ways. A wireless camera adds a Wi-Fi layer to the attack surface, while a wired camera typically connects over Ethernet. Once either becomes an IP endpoint, many of the same security questions begin to apply.

And that is why an IP camera assessment should not begin by trying to access the camera.

It should begin with reconnaissance.

Before interacting with a device, the first questions are much simpler:

What can be found?
What is already publicly visible?
What does that information reveal?
And what actually deserves further validation?

Start with discovery

Reconnaissance brings together local discovery, search-engine research, public technical information and Internet-wide service intelligence.

The objective is not to prove that a camera is vulnerable. It is to build an evidence-based picture of the environment: potential camera interfaces, exposed services, likely manufacturers or product families, and information that may guide later testing.

Search engines can reveal more than expected

Distinctive page titles, paths and interface strings sometimes lead to indexed camera interfaces or associated documentation.

Targeted Google dorking helps uncover pages associated with particular types of IP camera interface.

Image 1: Publicly indexed IP camera interfaces returned by the query.

Security research provides another layer of context, linking devices to known weaknesses, affected models and previously documented exposure.

Image 2: Published camera-exposure data illustrating how potentially vulnerable devices may be identified and mapped at scale.

The map links to individual cameras reported as affected by a known backdoor. However, identifying a device as potentially affected is not the same as gaining unauthorised access to it.

It is reconnaissance — an indication of what may be exposed and what should be investigated further in an authorised environment.

Internet-wide reconnaissance

Services such as Shodan can add another layer. A result may reveal an exposed port, protocol, service banner, manufacturer indicator or authentication behaviour associated with an IP camera.

Image 3: Shodan showing exposed IP camera services using Real-Time Streaming Protocol (RTSP) on port 554.

An Internet search result cannot, by itself, tell us whether the physical camera reaches the network through Wi-Fi or Ethernet. At this stage, we are observing the IP-facing service.

Build context before testing

Manufacturer documentation, firmware history, default configurations and credential information can help build the picture further.

But these remain reconnaissance inputs.

A documented default password is not evidence that a particular camera is using it. A known vulnerability is not evidence that a specific device is vulnerable.

Those claims need validation.

Image 4: Published default credential information highlighting Dahua and Hikvision, two major IP camera manufacturers referenced in security research.

So before deeper testing begins, the objective is to understand the client’s exposed camera estate.

Can it be found? What does it reveal? And what should be validated next?

Next week: Part 2 — From Connection to IP Exposure

In Part 2, we move from reconnaissance to the exposed endpoint itself — examining browser interfaces, RTSP services, authentication and what a reachable IP camera actually presents to the network.

IntSpired® Offensive by design.

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

A Wireless Foothold Is Only the Beginning

IntSpired® — Sat, 05 Sep 2026 15:31:56 +0000

Part 6 of 6: Attack Surface, Wireless Security, Infrastructure Impact.

Over the last five weeks, we’ve followed a wireless-specific attack path from OSINT through social engineering and proximity assessment, threat modelling and pentest validation.

This final post closes the loop: what happens once a wireless foothold is confirmed, and why the resulting risk often extends beyond the wireless layer.

A wireless compromise is rarely the objective

For example:

A cellular-connected edge device may lead towards backend or cloud-management systems beyond the device itself
A recovered Wi-Fi credential could grant entry to an internal network segment or, where credentials are reused, another enterprise service
A BLE connection can bridge through a gateway into a building management, access-control or operational system

Different technologies create different routes, but what matters is how the surrounding systems are connected and trusted.

Why this connection gets missed

Wired and wireless security are often owned by different teams, monitored through different tooling and reported in different sections of an assessment.

That separation may be organisationally convenient, but an attacker does not have to follow it.

A technical finding can therefore appear relatively minor when it is assessed in isolation from the systems, trust relationships and infrastructure around it.

Consider an exposed IoT interface: it may appear isolated until its gateway, credentials or management service is identified.

This is also where the visibility gap becomes important.

A conventional security operations team may see little or nothing of the RF-layer activity that created the initial access. The first indication can often come only once the attack reaches the network, assuming it is detected there at all.

Bringing the attack path together

Across the series, each stage has answered a different question:

OSINT — What can an attacker learn before arriving?

Social engineering — How could they gain the proximity needed to interact with the wireless environment?

Threat modelling — What assets, trust boundaries and attack paths become relevant from that position?

Pentest validation — Which of those hypotheses can actually be proved or disproved?

Infrastructure impact — Once a wireless foothold is confirmed, what systems, services or data could become reachable beyond it?

The final stage is therefore not another wireless test.

It is connecting the validated technical result to the infrastructure and operational processes the organisation actually depends on.

Image: The complete wireless assessment pipeline, linking validated findings to infrastructure impact, business risk and the risk register.

The drawing brings together the wireless layers followed throughout the series — cellular, Wi-Fi, BLE and wider RF — together with the IoT devices, gateways and infrastructure that may sit behind them.

Once testing has confirmed a weakness, the question changes.

It is no longer simply:

“Was the wireless test successful?”

It becomes:

“What did that success make possible?”

Closing the loop: from finding to risk register

That is why the technical finding itself cannot be the final output.

Each confirmed result needs enough context to explain how the attacker got there, what testing established, what could be affected and what needs to happen next.

A useful risk-register entry should capture:

Scenario and affected assets — what was exposed and which assets or systems form part of the scenario.

Access method — whether the attack was possible from a publicly accessible position or depended on social engineering, physical access or rogue-device placement.

Threat-model hypothesis — the specific attack path, trust boundary or assumption the pentest was intended to validate.

Confirmed technical result — what testing actually proved or disproved.

Downstream reach — which network segments, credentials, systems, cloud services, operational processes or data could become accessible.

Visibility — whether existing monitoring would have detected the initial wireless activity, only the later network activity, or neither.

Business impact — the potential consequence, such as data exposure, operational disruption, financial loss, regulatory impact or reputational damage.

Recommended action and owner — what should change and which team is responsible for reducing the risk.

This turns a standalone technical finding into something the organisation can prioritise and act on.

Compare:

“Weakness identified in corporate Wi-Fi.”

with a hypothetical finding such as:

“An attacker positioned in a publicly accessible area could exploit weaknesses across multiple wireless technologies, gain access to trusted infrastructure and reach internal services, with limited visibility to existing monitoring.”

The second statement connects the technical weakness to the attack path, its potential consequence and the reason it matters to the organisation.

Completing the pipeline

We opened this series with a simplified testing pipeline:

OSINT → Pentest

The point was not to question OSINT or pentesting, but to highlight what could be missed between them.

Without social engineering and proximity assessment, testing may begin from an attacker position that has never been justified.

Without threat modelling, technical testing may identify weaknesses but fail to establish which scenarios actually matter.

Without pentest validation, the model remains a set of assumptions.

And without following a confirmed wireless foothold into the wider infrastructure, even a valid technical finding can understate its significance.

The complete five-stage pipeline is therefore:

OSINT → Social Engineering → Threat Modelling → Pentest Validation → Infrastructure Impact

Together, these stages connect attacker position, testable hypotheses, validated findings and their potential consequences.

Business risk and the risk register are the output — translating that technical path into something the organisation can own, prioritise and remediate.

Why this matters

Wireless risk is growing, but not separately from the rest of the infrastructure.

Much of the software referenced throughout this series is free or open source, while capable wireless and SDR hardware is widely available.

The differentiator is not simply access to tools.

It is the process used to connect:

what is visible → what is reachable → what is plausible → what is exploitable → what it can affect.

Wireless is not a separate security world.

It is another layer of the same attack surface.

If an attack can begin in a publicly accessible RF environment, cross a wireless trust boundary and continue into infrastructure that supports the organisation, the assessment needs to follow the attack path all the way through.

A wireless foothold is only the beginning. The real risk is what it can reach next.

Want to know where a wireless compromise could lead inside your organisation?

Speak to IntSpired®.

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

Wireless Pentesting with Purpose

IntSpired® — Thu, 03 Sep 2026 05:55:17 +0000

Part 5 of 6: Attack Surface, Wireless Security, Pentest.

Everything up to this point, including OSINT, social engineering/proximity testing and threat modelling using DFDs and STRIDE, has produced a set of specific, prioritised hypotheses. This week is where they are tested using free and open-source software together with widely available wireless hardware. The distinction matters: this isn’t a generic tool walkthrough; each test is selected to validate what the threat model has already identified.

The model from last week extended beyond Wi-Fi, so validation now follows those same wireless layers: cellular, Wi-Fi, BLE and wider RF.

The examples below are not intended as an exhaustive list. They are grouped by technology for simplicity; in a real engagement, the exact toolset would be determined by the testing objectives, target environment and authorised scope.

Cellular

LTE Cell Scanner — establishes a starting point for passive cellular assessment by identifying nearby cells and their broadcast characteristics. Potential indicators of a rogue cell or cell-site simulator (IMSI catcher) include an unexpected or missing Cell ID (CID), unusually high received signal power (RXPWR) relative to neighbouring cells, unexpected frequency or channel use, and parameters inconsistent with the known local cellular environment. None is conclusive on its own. Establishing a local footprint should therefore be considered before treating any anomaly as significant.

Image 1: LTE Cell Scanner output showing detected cells and associated broadcast parameters.

Wi-Fi

Kismet — maps nearby access points and clients during Wi-Fi discovery, helping establish what is visible from the tester’s position and whether any AP appears inconsistent with the expected environment. This helps frame the spoofing hypothesis for further testing.

Wireshark — helps examine beacon and Robust Security Network (RSN) information during passive reconnaissance, establishing how protections such as Management Frame Protection (MFP) are configured.

Image 2: Wireshark screenshot showing RSN capabilities with MFP neither capable nor required, leaving deauthentication and disassociation management frames more susceptible to spoofing.

Aircrack-ng suite — supports wireless traffic capture, deauthentication testing and key recovery during active validation. This helps test hypotheses around management-frame exposure, authentication-material capture and wireless credential strength identified during threat modelling.

Image 3: Aircrack-ng successfully recovering a Wi-Fi passphrase from captured authentication traffic.

hcxdumptool / hcxtools — support targeted capture and processing of PMKID and handshake material, helping validate hypotheses around exposed authentication exchanges.

Wifite — automates several of the techniques above, helping apply consistent, repeatable checks across multiple access points during an engagement.

Bettercap — enables MITM testing and network reconnaissance once initial wireless access has been achieved. This helps determine what the foothold makes accessible, how far that access can extend and what additional risk it may expose.

Bluetooth / BLE

nRF Connect — inspects exposed BLE GATT services and characteristics, helping establish what a nearby device makes available before deeper testing begins.

Image 4: Annotated BLE UART capture showing a password transmitted in plaintext. The traffic was captured with the Nordic nRF Sniffer and analysed in Wireshark as part of IntSpired’s Bluetooth Exposure – Part 2 testing.

GATTacker — tests BLE pairing and MITM/tampering hypotheses identified during threat modelling.

RF / SDR

SDR + GNU Radio — captures and examines sub-GHz signals from IoT devices, key fobs and other non-Wi-Fi/BLE technologies identified through OSINT, helping determine which transmissions warrant closer examination.

Image 5: GNU Radio flowgraph using HackRF for 433 MHz RF monitoring and FFT-based spectrum analysis.

Universal Radio Hacker (URH) — takes captured RF signals into deeper protocol analysis, helping examine modulation, packet structure and unknown wireless protocols.

Inspectrum — provides detailed visual analysis of captured IQ data, making repeated transmissions, frequency offsets and timing structure easier to identify and measure.

Image 6: Repeated sub-GHz RF transmissions captured with HackRF and analysed in Inspectrum.

Mapping back to the model

The logic is the same in each case: the threat model defines the relevant attack path and trust boundary, from which a testable hypothesis is formed. The appropriate test is then selected, and the result either confirms, disproves or refines that hypothesis. The examples below show this mapping rather than treating each finding as a standalone result:

Example wireless pentest validation sheet

Image 7: Pentest validation sheet linking trust boundaries and attack paths to threat-model hypotheses, test tools and validation outcomes.

This is the difference between a wireless pentest that produces a list of incidental findings and one that directly answers the questions raised by the threat model.

Why this matters

Access to tooling is rarely the limiting factor in wireless testing. Much of the software used here is free and open source, while capable SDR hardware is widely available. The real differentiator is process: testing without a model can produce findings without context or priority, while modelling without validation leaves assumptions unproven. Used together, each stage turns the previous one into something more actionable.

Next week closes the series by following a confirmed wireless foothold beyond the wireless layer and examining where it can lead across the wider infrastructure.

Need your wireless hypotheses validated, not just scanned?

Speak to IntSpired®

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

Beyond Wi-Fi: Digital Twin Threat Modelling

IntSpired® — Fri, 21 Aug 2026 09:27:30 +0000

Part 4 of 6: Attack Surface, Wireless Security and Threat Modelling.

A wireless pentest can identify an access point, BLE device, IoT sensor or wireless bridge and still miss part of the picture: what that component connects to, what depends on it and where an attacker can realistically reach it from.

This is where threat modelling fits into the testing pipeline. In the previous stages of this series, OSINT established what an attacker might learn before arriving, while social engineering and proximity assessment considered how close that attacker could realistically get. Threat modelling takes those findings and asks what becomes relevant from that position.

Wireless components may not exist in isolation. They occupy physical locations, communicate with other systems, cross trust boundaries and depend on supporting infrastructure that may not be obvious when each device is considered separately. In this article, we use a digital twin to make those relationships visible and give the threat-modelling stage the context needed to define realistic attack paths and testable hypotheses.

Digital twins can represent anything from an individual component to a wider asset, system or operational process. For this purpose, the twin only needs enough detail to represent the parts of the environment relevant to the attack path.

From component to process

A useful way to think about digital twins is as a hierarchy. At component level, the model might represent an individual Wi-Fi access point, BLE peripheral, IoT sensor or wireless bridge. At asset level, several components form a functional asset, such as a staff handheld, camera unit, ticketing terminal or access-control device. At system level, those assets interact through wireless infrastructure, authentication, monitoring and backend services. At process level, the model shows the operational activity those systems collectively support.

Digital twin hierarchy

Image 1: Four-level digital twin hierarchy showing how wireless technologies sit within the wider assets, systems and operational processes they support.

For a wireless assessment, moving through these levels adds context to the technical target. An access point may look relatively unimportant when viewed as a single component, but the wider model may show that it supports a staff device connected to an operational system. Equally, an apparently interesting wireless device may have little meaningful connectivity or operational significance once its wider role is understood. The aim is not to model everything, but to understand enough of the surrounding environment to identify which technical paths deserve testing.

A fictional UK crossing

The relationship becomes particularly easy to see in environments where public access and operational infrastructure occupy the same physical space. Across the UK, ferry crossings, ports, transport terminals and similar sites can place members of the public within close proximity of systems supporting day-to-day operations.

Consider a deliberately simplified and fictional UK vehicle crossing, using Cornwall as the setting. Vehicles queue, pass through check or payment, cross a controlled-access boundary, enter a managed holding area and eventually board for the crossing. Supporting that process may be operational Wi-Fi, BLE-enabled staff devices, IoT sensors and cameras, wireless bridges, backend services and monitoring, together with shared dependencies such as power, UPS, backhaul and maintenance interfaces.

Digital twin of a fictional UK crossing

Image 2: Digital twin showing how the physical access boundary separates public and controlled areas, while wireless coverage may extend across both.

Where the boundaries actually sit

This is where the earlier proximity work begins to influence the pentest scope. A person sitting in the public vehicle queue has not necessarily bypassed any physical control; they may simply be occupying a location where members of the public are expected to wait. The question is what parts of the wireless environment become reachable from that legitimate position, and what trusted systems sit behind them.

Several boundaries can exist along the same attack path. The physical access boundary marks where public access ends. The RF trust boundary surrounds the radio-facing assets that can potentially be discovered or interacted with over Wi-Fi, BLE or other wireless technologies. Beyond those assets, authentication and access controls create a logical trust boundary before traffic enters the operational network, while backend or monitoring systems may introduce a further trust boundary of their own.

These boundaries do not necessarily align. A barrier may prevent a vehicle from moving beyond the public area, while RF coverage from multiple operational wireless assets could extend across that physical boundary. The wireless path can therefore become relevant before the attacker enters the controlled part of the site.

That matters because an assessment that begins with “assume the tester is already in range” has already removed part of the attack path from consideration. Threat modelling makes that path explicit: where can the attacker realistically position themselves, what becomes reachable from there, where does trust change, and what sits behind those boundaries?

Wireless threat model of the crossing

Image 3: Wireless threat model showing how realistic attacker position, RF and logical trust boundaries, data flows and adversary context shape the attack path before a pentest hypothesis is defined.

The same model can then be interrogated using established threat-modelling techniques. In the example, STRIDE is kept in its standard S–T–R–I–D–E order, with spoofing, tampering, information disclosure and denial of service highlighted as the primary concerns for this particular wireless path. Repudiation and elevation of privilege remain visible but are not treated as the main focus of the scenario.

The Diamond Model provides the wider context. The adversary is an unauthorised actor with legitimate public proximity; the infrastructure includes the public queue and RF-accessible environment; the capability is wireless discovery and interaction; and the victim is the connected operational asset or system. It is the same model applied at a broader wireless/RF level, now brought down to the scale of a single site and attack path — the same model, at a different altitude.

Turning the model into pentest hypotheses

The model does not establish that a vulnerability exists. Its value is in identifying which relationships are important enough to examine technically.

If operational Wi-Fi extends into the public queue, the relevant question is no longer only whether the network is securely configured. The pentest can examine what an unauthorised person can observe or interact with from that realistic location, what is exposed before authentication is established, whether public and operational services are adequately separated, and whether trusted infrastructure or clients can be impersonated.

BLE and IoT introduce a different path. A sensor, camera or short-range peripheral may appear relatively low value at component level, but the system model may show that it communicates through a gateway, management platform or staff device into a more trusted environment. The useful hypothesis then becomes whether interaction with the edge device exposes information, control or a path towards something more significant.

A wireless bridge may look like little more than another radio link when considered in isolation, while the system twin shows that it joins two network segments treated as internal infrastructure. That can make its RF exposure, management interfaces and the trust carried across the link more important than the radio component itself.

The model can also expose relationships just outside a narrowly defined wireless scope. For example, USB is not wireless, but a physically accessible maintenance interface on a wireless-connected asset may still form part of a relevant attack path. This does not automatically bring USB testing or other adjacent interfaces into scope, but it gives the organisation and tester the context to decide whether they should be included.

Availability can be treated in the same way. Wireless links can degrade because of weak signal, obstruction, equipment failure, interference or power loss. Deliberate RF interference or jamming is another possible threat, although any validation would require explicitly authorised and controlled testing. At the threat-modelling stage, the question is whether loss or degradation of that wireless dependency creates a meaningful test hypothesis.

Monitoring is part of the same path. A device experiencing weak RF, a failed component, loss of power or hostile interference may initially look very similar from the operational side: it simply disappears. If monitoring depends on the same wireless path, loss of connectivity may remove both the service and some of the visibility required to understand what happened.

Power and backhaul can reveal similar dependencies. Several wireless components may appear independent while relying on a common UPS, switch, network path or monitoring service. Those dependencies are not separate topics added to make the wireless pentest larger; they matter only where the threat model shows that they change the attack path, the likely impact or the assumptions worth validating.

Example pentest hypothesis sheet

Image 4: Threat-model output mapping realistic attacker positions and reachable paths to testable hypotheses for pentest validation.

DFDs and STRIDE underneath the twin

The digital twin provides the physical and operational context, while conventional threat-modelling techniques provide the structure for examining specific attack paths.

A data flow diagram (DFD) can isolate the communications relevant to a scenario: a staff handheld communicating with an AP and backend service, a BLE device exchanging data with a terminal, an IoT sensor reporting through a gateway, or a wireless bridge linking two network segments. Each flow can then be examined where it crosses a trust boundary.

This is preferable to producing one enormous diagram for the entire estate. Different wireless scenarios have different trust boundaries and failure points, so the useful model is built around the specific path being examined.

The selected STRIDE categories shown in Image 3 can then be applied to those flows, while the Diamond Model keeps the scenario tied to a plausible adversary, infrastructure, capability and victim. Together, they help turn each path into a testable pentest hypothesis rather than a generic checklist.

From threat modelling to the pentest

At the end of the threat-modelling stage, the useful output is not another architecture diagram. It is a short set of prioritised attack paths and hypotheses that the pentest can validate.

That is the role of threat modelling in the pipeline. OSINT establishes what an attacker can learn before arriving. Social engineering and proximity establish where they could realistically position themselves and what access opportunities may exist. Threat modelling then connects that position to reachable wireless components, the assets and systems behind them, and the trust boundaries they cross. From there, the pentest can validate the most relevant hypotheses before the results are considered in terms of wider infrastructure impact.

Five-stage wireless pentest pipeline

Image 5: Five-stage wireless pentest pipeline showing how reconnaissance and realistic proximity are converted through threat modelling into prioritised hypotheses for the pentest to validate.

Why this matters

A technically competent wireless pentest can still begin with incomplete assumptions if the attacker position, trust boundaries and wider system relationships are predefined before testing begins.

The digital twin gives the threat-modelling stage a practical way to connect those pieces. The DFD shows the relevant flows, trust boundaries identify where assumptions change, STRIDE helps interrogate the path, and the Diamond Model keeps the scenario tied to a plausible adversary and victim.

The result is a more specific instruction than simply “test the Wi-Fi.”

Instead, the pentester begins with defined questions about where the attacker can realistically operate, what wireless assets become reachable from that position, what those assets connect to and which of those relationships are important enough to prove or disprove.

Next week, we take those hypotheses into the pentest itself and look at how freely available wireless testing tools can be used to validate what the model predicted.

Want to know whether your wireless assessment is testing the right attack paths?

Speak to IntSpired®

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

Social Engineering: The Missing Step in Wireless Testing

IntSpired® — Mon, 17 Aug 2026 10:27:39 +0000

Part 3 of 6: Attack Surface, Wireless Security, Social Engineering.

Most wireless attacks share a constraint that wired and remote attacks do not: proximity.

An attacker needs to be close enough to receive and interact with the target’s radio signals, whether from a public road, loading bay, reception area, stairwell or within Bluetooth range of a device.

That requirement makes social engineering an important part of a wireless risk assessment. Skip it, and you may be assessing the technology without testing whether an attacker could reach it.

Proximity doesn’t happen by accident

A pentest that starts with “here’s a device already in range” has skipped an important part of the attack path: getting there in the first place.

Attackers may gain that proximity through methods that have little to do with radios:

Tailgating into a building behind an employee with a badge
Pretexting as a contractor, courier or auditor to reach reception areas, plant rooms, comms rooms or other restricted locations
Rogue device placement leaving a small Wi-Fi/BLE-capable device — a “drop box” — somewhere with power and plausible concealment
Impersonating IT or facilities staff to reach network cabinets or wireless infrastructure

None of this requires specialist wireless knowledge. It requires a credible story and enough supporting information to make it work.

That is where the OSINT groundwork from last week becomes useful: supplier names, contractor relationships, physical layouts, employee information and other details that strengthen a pretext.

Why this stage gets skipped

Social engineering is harder to scope than a conventional wireless test. It involves people, physical access and clear rules of engagement, and it may not produce the neat technical finding that fits easily into a standard pentest report.

It is simpler to authorise “test the Wi-Fi” than “attempt to enter the building.”

As a result, many wireless assessments simply stipulate proximity:

“Assume the attacker is in the car park.”

But location changes the risk.

A vulnerability that can be exploited from a public road presents a very different exposure from one that requires access to a particular floor, stairwell or equipment room.

The relevant question is therefore not only whether the weakness exists, but where an attacker needs to be to exploit it and what it would take to get there.

What a wireless-focused social engineering exercise should cover

This does not need to become a full red-team engagement.

A scoped exercise can include:

Physical access attempts at defined entry points under agreed rules of engagement
Pretext calls or emails using information identified during OSINT to test whether staff disclose guest credentials, provide network access or facilitate entry to restricted areas
Rogue device drop tests, with explicit client approval, to determine whether an unfamiliar device is detected, challenged or reported
Badge and visitor process review to assess the controls between public areas and locations where wireless assets come within reach

The objective is not simply to prove that someone can enter a building.

It is to understand how physical access and human behaviour shape wireless exposure.

From OSINT to Proximity Assessment

Image: A wireless-focused social engineering assessment flow: OSINT finding → pretext built → access attempt → wireless / perimeter sweep → rogue device / entry test → outcome logged.

This exercise produces a proximity assessment: how close an attacker can get, which wireless assets become reachable from that position, what method gets them there, and which controls stand in the way.

The result is a clearer picture of how an attack could unfold.

It feeds directly into next week’s threat modelling stage by showing which trust boundaries are actually reachable, rather than merely accessible in theory.

Why this matters

Skipping social engineering leaves part of the wireless attack path untested.

A technically sound pentest can still misrepresent the risk if it begins from a position without establishing whether an attacker can reach it. As a result, the risk assessment can be distorted in either direction.

If your last wireless assessment began with “assume the tester is already in range”, ask:

What would it take for an attacker to get there?

Want to know whether your controls would stop an attacker?

Speak to IntSpired®.

They Know Where to Stand

IntSpired® — Wed, 05 Aug 2026 13:53:24 +0000

Part 2 of 6: Attack Surface, Wireless Security and OSINT.

Before an attacker reaches your building, car park or Bluetooth-enabled devices, they may already have a working picture of your wireless estate. SSIDs, BSSIDs, encryption standards, hardware vendors and approximate locations can all appear in public-source data — before anyone switches on an adapter near your site.

Why wireless OSINT gets overlooked

Most OSINT checklists focus on domains, breached credentials, employee footprints and cloud misconfigurations. Wireless rarely gets its own line, even though public sources can reveal enough detail to build a meaningful picture of a site’s wireless environment without the researcher sending a single packet.

This matters because everything found here feeds directly into the next two stages of the pipeline: it tells a social engineer what to pretend to be, and it tells a threat modeller what assets and trust boundaries may exist.

Sources worth checking

WiGLE (wigle.net) — A crowdsourced wardriving database built from years of public submissions. A search around a company address can show the density and distribution of recorded wireless activity, reveal naming patterns and help identify where further investigation may be useful. The findings still require validation, because proximity does not establish ownership.

Image 1:Recorded wireless observations across Cornwall and the South West, illustrating the density and geographic spread of publicly available data.

Much of this data is contributed by wireless enthusiasts through everyday wardriving, organised projects and community events. Once uploaded, individual observations accumulate into a persistent public record — one that may remain searchable long after a network has been renamed, replaced or decommissioned.

Image 2: A recent community wardriving leaderboard showing how large numbers of new wireless observations can be collected and contributed during a single event.

Vendor and OUI lookups — The first three octets of a conventional MAC address form its Organisationally Unique Identifier. An OUI database links that prefix to the entity that registered the address block, turning an anonymous BSSID into a vendor or technology lead. Combined with procurement records, job advertisements or technical documentation, it can help narrow the hardware families that may be present and the issues worth investigating.

Image 3: An OUI lookup tool links an observed MAC prefix to the organisation that registered it.

Exposed configuration and documentation — Search engines, code repositories and document-sharing platforms regularly surface network diagrams, access-point configuration exports and even PSKs left in installer documentation, support tickets or public GitHub repositories. This is rarely a wireless-specific leak; it is a broader OSINT hygiene problem, but the impact becomes wireless-specific once the material is found.

Job postings and supplier listings — Job advertisements mentioning specific access-point controllers, MDM platforms or a named wireless vendor tell an attacker which product line to research for known vulnerabilities, with no scanning required.

Physical and social footprint — Site photographs on social media, contractor listings and building directories can reveal physical layout, reception locations and badge or access-control systems, all of which set up the social-engineering stage that follows.

Turning OSINT into a working picture

None of this is exploitation. It is context-building. A useful output at this stage is not a vulnerability list; it is an asset and assumption sheet:

• Likely access-point vendors and approximate hardware age

• Encryption standards apparently in use

• Physical sites with a confirmed wireless presence

• Credentials, configurations or documentation already exposed

• What a rogue actor could plausibly claim to be, based on visible suppliers or contractors

Together, these findings help establish the technologies an attacker may expect to encounter, the assumptions they may build around the site — and where they may try to stand.

Why this matters

Wireless OSINT is passive, accessible and often skipped in favour of jumping straight to active testing. That is a missed opportunity in both directions: for attackers, it offers low-risk reconnaissance; for defenders, it provides an early-warning exercise requiring little more than time.

The data is already public. The only question is whether you examine it before someone else does.

Want to know what is already visible about your wireless estate?

Speak to IntSpired®.

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

Sources and tools referenced:
https://wigle.net/
https://wireshark.askapache.com/tools/oui-lookup.html
https://maclookup.app/
https://defcon.social/@WiGLEnet

Why Your Wireless Security Pipeline Falls Short

IntSpired® — Thu, 30 Jul 2026 06:50:36 +0000

Part 1 of 6: Attack Surface, Wireless Security and Threat Modelling.

Wireless is no longer a side channel.

Wi-Fi, Bluetooth, RFID/NFC, sub-GHz IoT and mobile radio now sit underneath most of the infrastructure organisations depend on. This includes staff laptops, building access control, industrial sensors and, increasingly, 5G-connected devices.

Wireless risk has grown quietly, in parallel with everything else. It rarely gets its own line in a risk register. It usually gets folded into “network security” and left there.

That would be fine if the standard security testing pipeline reliably surfaced wireless exposure. In practice, it often doesn’t.

The problem is rarely a lack of tools. It’s the absence of the steps that connect discovery to meaningful testing.

The pipeline most organisations actually run

Ask most security teams to describe their testing process and you’ll hear some version of:

OSINT → Pentest

Recon happens. Then, fairly quickly, someone is pointed at a target with a tool. Findings get written up. A report gets delivered.

It’s a defensible process. It is also missing two steps that matter more for wireless than almost any other domain:

OSINT → Social Engineering → Threat Modelling → Pentest

Why the missing steps matter for wireless

Wired and remote attack paths can often be exploited from anywhere with network access. Wireless is different: an attacker usually has to get close. That single constraint is why the missing steps matter so much.

Social engineering establishes proximity

An attacker might gain access by tailgating into a building, posing as a contractor, working from a public reception area, or planting a rogue device somewhere on the premises.

Skip this step and you’ve only tested what’s reachable from a laptop in a car park, not what’s reachable once someone simply walks in.

Threat modelling establishes relevance

Threat modelling tells you which of your wireless exposures are worth testing at all, who would realistically target them, and what the actual business impact is if they succeed.

Skip this step and the pentest may miss a risk that actually matters, regardless of how thorough the testing itself is.

That’s the gap between a report that’s technically accurate and one that’s actually useful.

What this series covers

Over the next five weeks, we’ll walk the full pipeline as it applies specifically to wireless environments:

OSINT for wireless: what’s discoverable about your estate before an attacker is ever in range.
The missing middle: social engineering: how proximity gets earned, not assumed.
Threat modelling the wireless surface: DFDs, trust boundaries, STRIDE, and the Diamond Model applied at device/site scale.
Pentest: proving the model: free tools, used to validate hypotheses rather than as a standalone exercise.
Connecting wireless back to infrastructure: how a wireless foothold becomes an enterprise-wide problem.

Image: Illustrates a vertical flowchart of the five pipeline stages, with the threat modelling and infrastructure impact stages visually highlighted.

We’ve written before about the same principle at a larger scale in
Not All Threat Vectors Are Wired (link below), where the Diamond Model, MITRE FiGHT and ATT&CK were used to frame wireless risk that traditional monitoring never sees. This series brings that same discipline down to the Wi-Fi, Bluetooth and RF layer most organisations actually own and operate day to day.

Why this matters

A pentest report full of valid findings can still leave an organisation exposed, if the findings were never weighed against a realistic model of:

• who would target the organisation

• how they would obtain proximity

• which systems they would pursue

• how a wireless foothold could affect the wider environment

Wireless risk is growing. The gap in the pipeline that’s supposed to catch it isn’t a tooling problem, it’s a process one.

Over the coming weeks, we’ll show what filling that gap actually looks like, stage by stage, using freely available tools and frameworks throughout.

Need help identifying where your wireless testing pipeline has a gap?

Speak to IntSpired®.

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk

Further reading:
Not All Threat Vectors Are Wired - https://intspired.co.uk/blog/f/not-all-threat-vectors-are-wired