DEV Community: IntSpired®

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

Not All Threat Vectors Are Wired

IntSpired® — Tue, 21 Jul 2026 19:08:34 +0000

Most traditional security operations centres (SOCs) were built around IP-based enterprise infrastructure. Firewalls, endpoints, servers, identity systems, cloud logs and network traffic form the core of the detection stack.

That approach assumes suspicious activity will eventually surface through an IP connection, a managed device, an application log or another monitored part of the enterprise environment.

For a long time, that assumption covered much of the attack surface. It no longer covers all of it.

Wireless systems have always introduced risks that conventional monitoring may not see directly. Wi-Fi, Bluetooth, radio-frequency identification (RFID) and earlier cellular generations all created activity beyond the visibility of standard endpoint and network sensors.

Radio frequency (RF) does not stop at Wi-Fi.

5G has expanded the wireless attack surface across user equipment, radio access networks (RAN), virtualised core functions, edge infrastructure, service-based interfaces and machine-to-machine communications. 6G is likely to extend that dependence on distributed, software-defined and radio-connected infrastructure further still.

RAN activity, over-the-air signalling, rogue radio infrastructure, interference, handovers between devices and base stations, and manipulation of radio-layer protocols may never touch the sensors used by a traditional enterprise SOC.

Some of the resulting activity may eventually appear in an IP log or core-network event. The initial radio-layer activity may remain unobserved.

If your monitoring stack only watches enterprise networks, hosts and cloud infrastructure, an entire class of wireless threats may be invisible by design, not by accident.

This is not a minor blind spot. It is a structural visibility gap.

Where there is no SOC at all — which is common among smaller operators, private-network operators, MVNOs, suppliers and technology vendors — the gap does not disappear. It means a different process is needed to identify and prioritise the risk before an incident occurs.

Threat modelling without a SOC

Without a SOC, you are not necessarily detecting live attacks.

You are anticipating plausible attack paths, identifying what you could observe, exposing what you could not observe and deciding where controls should be strengthened.

That shifts the workflow from continuous detection towards structured prioritisation, but the underlying threat-modelling frameworks still provide a practical foundation.

Image 1: Threat modelling without a SOC. An IntSpired-style workflow combining the Diamond Model, MITRE FiGHT and ATT&CK, visibility-gap analysis, GSMA and ENISA guidance, baseline control mapping, and a prioritised risk register.

1. Diamond Model — frame the scenario

Before moving into technical detail, define the hypothetical event.

Who is the likely adversary? What infrastructure could they use? What capability would they need? Which device, service, network function, organisation or user would be the victim?

These four elements form the principal vertices of the Diamond Model:

Adversary
Infrastructure
Capability
Victim

The purpose is not to name a specific attacker without evidence. It is to create a structured scenario.

The adversary might be a financially motivated group, hostile operator, insider, criminal service provider or opportunistic attacker.

The infrastructure could include rogue radio equipment, rented cloud services, compromised network functions, malicious applications or attacker-controlled signalling infrastructure.

The capability might involve radio reconnaissance, identity manipulation, signalling abuse, denial of service, exploitation of a network function or unauthorised access to subscriber information.

The victim could be user equipment, a base station, private 5G deployment, core-network function, connected enterprise or the operator itself.

This is the scaffolding on which the rest of the analysis is built.

2. FiGHT and ATT&CK — enumerate the techniques

The capability vertex can then be expanded into specific adversary behaviours.

MITRE ATT&CK provides a structured knowledge base for tactics and techniques affecting enterprise, cloud and mobile environments.

MITRE FiGHT performs a similar role for 5G environments, covering techniques associated with user equipment, radio access, the core network, telecom services and supporting infrastructure.

The two should not be treated as competing frameworks. A realistic attack path may involve both.

An adversary might begin with activity against the radio or telecom environment and later use conventional enterprise techniques for credential access, persistence, lateral movement, command and control or data exfiltration.

The reverse is also possible. An attacker may first compromise an enterprise system, cloud service or management platform and then use that access to affect mobile-network infrastructure.

The technique-mapping stage should therefore ask:

Which FiGHT techniques are relevant to the RAN, core and telecom environment?
Which ATT&CK techniques become relevant once the attack reaches enterprise, cloud, identity or endpoint infrastructure?
Where do the two sets of behaviours connect?

This produces a more complete technique list than using either framework in isolation.

3. The coverage gap — flag what you cannot see

This is the step many threat-modelling exercises skip.

Identifying a plausible technique does not mean the organisation can detect it.

Traditional SOC monitoring commonly provides visibility into:

Firewalls
Endpoints
Servers
Identity systems
Applications
Cloud logs
IP and network traffic
Managed network devices

Visibility into the wireless and radio domain may be far more limited. This can include:

RF-spectrum activity
Air-interface behaviour
RAN signalling
Over-the-air traffic
Rogue or unauthorised radio infrastructure
Device-to-tower handovers
Radio interference and jamming
Subscriber identity activity involving SIM or eSIM systems
Manipulation of mobility or control-plane procedures

Some telecom operators have specialist RAN, signalling and network-assurance capabilities. Some private-network environments also collect detailed telemetry from radio and core components.

Many enterprise SOCs, however, have little or no direct visibility into those layers.

For every technique identified during the FiGHT and ATT&CK stage, the threat model should record one of three conditions:

Visible: the organisation has appropriate telemetry and can reasonably detect the activity.

Partially visible: some evidence may appear, but the initial activity or complete attack path cannot be observed.

Not visible: the organisation has no reliable source of telemetry for the technique.

This creates a visibility matrix, not merely a list of threats.

A control may exist while the telemetry required to confirm its effectiveness does not. That distinction matters.

4. GSMA FS.40 and ENISA — validate against known risk categories

Technique mapping should then be checked against broader telecom-security guidance.

GSMA FS.40 provides guidance on security considerations for 5G networks, while ENISA's work on the 5G threat landscape provides a wider view of threat actors, assets, vulnerabilities and attack scenarios affecting mobile infrastructure.

This cross-check helps prevent the threat model from becoming too narrow.

Working only from ATT&CK or FiGHT may produce a strong list of adversary techniques, but wider industry guidance can reveal categories that also need to be considered, including:

Fraud and identity abuse
Unauthorised access
Supply-chain compromise
Misconfiguration
Signalling exploitation
Eavesdropping and interception
Privacy and data exposure
Service disruption
Physical compromise
Third-party dependency
Virtualisation and cloud-infrastructure risk
Operational and management-plane weaknesses

The objective is not to copy every risk from every framework. It is to test whether the scenario has omitted an important category.

5. GSMA FS.31 — map to baseline controls

Once credible techniques and risks have been identified, they should be mapped against baseline security controls.

For each plausible attack path, ask:

Is there already a control intended to prevent it?
Is that control implemented across the relevant part of the architecture?
Can its effectiveness be verified?
Does the organisation have telemetry that would reveal failure or bypass?
Who owns the control? Is it operated internally, by a supplier or by a managed service provider?

This is where the exercise becomes an actual gap analysis.

A technique may be theoretically possible but already well controlled. Another may have a preventative control but no detection capability. A third may have neither.

The assessment should distinguish between:

Control present and monitored
Control present but not monitored
Control partially implemented
Control dependent on a third party
No effective control
Control status unknown

Unknown should not automatically be treated as secure. It should remain open until evidence is available.

6. Risk register — the output

Where there is no SOC converting the analysis into detection rules, alerts and response playbooks, the primary output is a prioritised risk register.

Each entry should contain enough information for leadership, engineering teams, suppliers or an MSSP to act on it, including:

Scenario and affected assets
Likely adversary
Relevant techniques
Existing controls
Visibility status
Potential impact
Likelihood or plausibility
Residual risk
Recommended action
Responsible owner
Target completion date

The result is not simply a list of theoretical wireless attacks.

It is a structured record of which attack paths matter to the organisation, which controls already reduce the risk and which areas remain exposed or invisible.

Where security monitoring is outsourced, the same register can be translated into specific requirements for an MSSP.

Instead of asking an MSSP to "monitor 5G security", the organisation can define the events, data sources, network functions and behaviours that must be covered.

Threats do not stay in one lane

None of this is as clean as placing wired and wireless into separate boxes.

The Extended Diamond Model adds meta-features such as timestamp, phase, result, direction, methodology and resources because a real intrusion is rarely a single isolated event.

It is more often an activity thread.

That thread can move from reconnaissance through weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. It may affect several systems or victims during the same campaign.

When multiple activity threads are connected, the result becomes an activity-attack graph rather than one standalone diamond.

Image 2: Threats do not stay in one lane. An IntSpired-style interpretation of how individual Diamond Model events can form activity threads and wider activity-attack graphs spanning the radio layer, telecom core, cloud infrastructure and enterprise environment.

The same principle applies to the distinction between wired and wireless infrastructure.

An attacker is unlikely to remain in one environment throughout an entire campaign.

A hypothetical attack might begin with RF reconnaissance against a radio site or device. It could continue through a malicious over-the-air interaction, exploitation of a modem or protocol weakness, compromise of a handset or subscriber identity, and access to data or services through the mobile core.

From there, the attacker may reach cloud infrastructure, management systems or enterprise networks.

The route can also move in the opposite direction.

An attacker might first compromise a cloud-hosted management service, supplier account, orchestration platform or enterprise administrator. That access could then be used to manipulate telecom services, network functions, subscriber systems or radio-connected devices.

The important point is not that every wireless event leads to a wired compromise.

It is that real attack chains can cross the boundary.

Treating wired and wireless as separate and absolute security categories misses how campaigns may progress in practice.

Wireless is not a separate security world. It is another layer of the same attack surface.

Why this matters

The Diamond Model, ATT&CK, FiGHT, GSMA guidance and ENISA threat analysis can help an organisation structure what it needs to examine.

They do not create telemetry.

They do not guarantee that a SOC can see radio-layer activity.

They do not confirm that a baseline control has been implemented correctly.

And they do not replace the need to understand the architecture being protected.

Where there is no SOC, threat modelling provides a method for identifying and prioritising credible exposures before monitoring capabilities are built or outsourced.

Where there is a SOC, the same process exposes the difference between what the organisation believes it monitors and what its sensors can actually observe.

That is where the value sits.

Wired infrastructure receives most of the conventional monitoring budget.

Wireless infrastructure often carries risk outside that conventional line of sight.
Threat modelling that does not account for the difference is not modelling the complete threat.

Need help identifying wireless and RF visibility gaps?

Speak to IntSpired®.

OFFENSIVE BY DESIGN. INTELLIGENT BY NATURE.

OWNED AT THE ANTENNA.The Attack Your VPN Cannot See

IntSpired® — Sat, 11 Jul 2026 08:28:54 +0000

Mobile communications did not begin as an app economy.

They began as RF engineering.

In 1973 Motorola built the first handheld cellular prototype. It weighed more than a kilogram, had no display, took around 10 hours to recharge and delivered about 35 minutes of talk time. A decade later, that development path led to the DynaTAC 8000X.

It was not a smartphone. It was not a software platform. It was a radio terminal.

Image 1: Motorola DynaTAC 8000X, FCC-approved in 1983 and widely recognised as the first commercial handheld mobile phone. This is where the handheld mobile era became real.

Four decades later, by 2012, mobile had crossed a line.

The smartphone was no longer emerging technology. It had become the default personal device of the modern internet era. Global mobile subscriptions had already reached billions. Smartphone sales were accelerating fast. Android and iPhone had reshaped the market. BlackBerry, Nokia and the old feature-phone model were visibly losing ground. Popular Mechanics ranked the smartphone number one in its list of 101 Gadgets That Changed the World, above the TV, the PC, the telephone and the light bulb.

That is why 2012 matters. It was not the year the smartphone began. It was the year the smartphone became normal.

Every security story has a starting point. And in that same year, an IEEE antenna-engineering lecture that most people never saw captured something important: the modern phone was already becoming a dense, multi-radio system.

A smartphone is not just a screen, an operating system and some apps. It is a radio device built around antennas, basebands, SIM identity, carrier signalling, roaming logic and legacy network compatibility. A lot of that sits below the layer most people think of as phone security.

Below the OS. Below the VPN. Below app permissions. Below the lock screen.

The antenna has always been part of the attack surface.

VULNERABILITY 01

You Are Carrying a Radio Array
A modern phone is not one radio. It is a collection of radios.

Cellular. Wi-Fi. Bluetooth. GPS/GNSS. NFC. Ultra-wideband. Multiple LTE and 5G bands. Multiple receive chains. Carrier aggregation. MIMO antenna paths. Roaming logic. Emergency calling logic. Legacy fallback logic.

A 2012 antenna-engineering slide already showed how crowded a phone PCB had become. UWB, RFID, FM, 2G/3G cellular, diversity receive, WLAN, Bluetooth, DVB-H and GPS were all competing for space inside a handheld device. That was 2012.

Image 2: Mobile-phone PCB showing multiple antenna systems competing for space inside a single handset. Adapted from IEEE AP-S Distinguished Lecture Program, 2012; © IMST GmbH. All rights reserved.

Today the problem is larger.
5G did not reduce the radio surface. It expanded it. More bands. More antennas. More tuning. More baseband logic. More decisions made automatically before the user sees anything.
That matters because your apps are not the first thing talking to the outside world.The modem is.

VULNERABILITY 02

The Downgrade Attack Still Matters
A brand-new 5G phone still has to live in the real world.

Coverage is uneven. Buildings block signal. Underground spaces degrade it. Crowded venues overload networks. Rural areas and roaming environments may still rely on older infrastructure. Even where 2G and 3G are being phased out, many devices and carrier profiles still retain legacy compatibility unless it is explicitly disabled.

That legacy matters.

An attacker does not always need to defeat 5G directly. They can try to move the device away from it.

False base stations and hostile RF environments can exploit the phone's need to maintain service. If stronger modern coverage is denied or degraded, and a weaker legacy path is allowed, the phone may be pushed toward a less secure network generation.

2G/GSM is the obvious risk. It was designed for a different era. It lacks the mutual authentication users expect from modern networks. Its legacy encryption options, including A5/1 and A5/2, have been publicly attacked for years.

The victim does not tap a malicious link. They do not install malware. They do not approve a permission prompt. Their signal bars may look normal.

The attack happens at the radio layer.

VULNERABILITY 03

IMSI Catchers Do Not Need Your Password
An IMSI catcher, also known as a Stingray or cell-site simulator, is a rogue base station.

Its purpose is not to guess your password. Its purpose is to make your phone identify itself.

Mobile networks rely on subscriber identity. Your SIM and device participate in attachment and authentication processes before your apps are involved. A rogue base station attacks that trust boundary. It broadcasts like infrastructure. Your phone evaluates it like infrastructure. Under the wrong conditions, your phone can be persuaded to reveal identifying information or attach to a hostile network environment before you have any meaningful visibility.

This is why a VPN is not the answer here.

A VPN protects IP traffic after connectivity exists. An IMSI catcher targets the cellular identity and radio attachment process before that tunnel matters.

The exposure is not your browser session. The exposure is that your device exists, where it is, and which subscriber identity or device identity it can be linked to.

VULNERABILITY 04

5G Improved Things. Legacy Did Not Disappear.
5G was designed with better subscriber identity protection than previous generations. That is true.

But 5G does not erase LTE. It does not erase roaming. It does not erase carrier implementation gaps. It does not erase fallback behaviour. It does not erase 2G where the device still supports it.

5G identity protection helps on genuine 5G connections. But a 5G-capable device can still be exposed through non-5G paths, especially where downgrade or fallback behaviour is possible.

The security of your 5G phone is not determined only by 5G. It is determined by the weakest network generation your phone is allowed to use, the carrier settings it accepts, the country you are in, the roaming partner you attach to and the RF environment around you.

The device in your hand may be modern. The trust chain around it may not be.

VULNERABILITY 05

SS7: The Network Behind the Network
SS7 is not an app-layer issue. It is not a phone setting. It is part of the signalling world that lets carriers route calls, deliver SMS, manage roaming and locate subscribers across networks. It was designed for a closed telecom environment where operators trusted each other. That assumption did not survive the modern telecom ecosystem.

SS7 weaknesses have been used for location tracking, surveillance and SMS interception. This is why SMS-based two-factor authentication is a weak choice for anything important.

The problem is not only whether your phone is infected. The problem is whether the signalling path delivering your one-time code can be manipulated before the message reaches you.

No malware on the handset. No handset exploit. No notification.

This is not theoretical. In 2017, German banking customers were hit when attackers abused SS7 to redirect SMS transaction codes used for payment approval. And in 2024, the EFF was still warning that SS7 remains a live risk because telecom providers stay connected to it for international roaming, enabling SMS interception and location tracking.

That is legacy telecom trust being abused in a world it was never designed for.

VULNERABILITY 06

Your Body and Environment Change the Radio Conditions
The human body affects antenna performance. That is not speculation. That is RF engineering.

Your hand, head, pocket, bag, car, building, basement or crowded venue can absorb energy, detune antennas, distort radiation patterns and weaken signal quality. The phone then tries to maintain service. It may adjust transmit power. It may change band. It may move cell. It may fall back where fallback is allowed.

Human-Mobile Interaction

Image 3: The human body affects RF exposure and antenna performance. Original IntSpired illustration. Concept informed by IEEE AP-S DLP 2012 / IMST GmbH antenna-engineering material.

Most of the time, that is normal radio behaviour. But in a hostile environment, radio conditions can be shaped.

Airports. Hotels. Underground car parks. Conference centres. Border zones. Executive venues. Sensitive meetings. Crowded places where users already expect poor reception.

That is useful cover for RF-layer manipulation.

What To Do

Disable 2G if your device and carrier settings allow it. On newer Android devices this may be exposed directly in network settings. On iPhone, Apple's Lockdown Mode turns off 2G and 3G cellular support, though it is designed for high-risk users and changes other device behaviour too.

Stop using SMS-based two-factor authentication on important accounts. Use an authenticator app, passkey or hardware security key instead.

Use Signal or another properly end-to-end encrypted messenger for sensitive calls and messages. If the transport layer is compromised, content encryption still matters.

Do not treat a VPN as RF-layer protection. A VPN helps with IP traffic after connectivity is established. It does not stop your phone identifying itself to cellular infrastructure before that tunnel exists.

Change your threat model in hostile environments. Conferences, sensitive meetings, border crossings, executive travel, investigative work and high-value business venues all deserve more caution than normal daily use.

Do not treat aeroplane mode as high-assurance RF silence. It is useful for reducing normal radio activity, but it still depends on the device, operating system and radio settings behaving as expected. For higher assurance, power the device off and physically separate it from the sensitive environment.

The Point
2012 was the year the smartphone became normal. The security briefing never came with it.

The world adopted the smartphone as a personal computer, camera, wallet, map, identity layer and communications hub. Underneath, it remained a radio device. A modem. A SIM. A set of antennas. A stack of legacy protocols. A negotiation with whatever network environment surrounds it.

From 2G to 5G, the story is not that everything is broken. The story is that part of the attack surface sits below where most users are looking.

Below the apps. Below the OS. Below the VPN.

The antenna is not just for signal.

The antenna is part of the attack surface.

It always was.

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

5G, IMSI Catchers and the Downgrade Problem

IntSpired® — Thu, 25 Jun 2026 05:17:31 +0000

5G makes IMSI catching harder, but fallback is where the risk remains.

The old IMSI catcher problem was fairly simple. A device could be pulled towards a stronger rogue cell, persuaded to connect, and then pushed into revealing identity information before the session was properly protected.

In 2G, 3G and 4G environments, that created a practical route to subscriber identification, tracking and follow-on targeting.

That weakness sits in the order of events. The device identifies itself before enough trust has been established.

5G Standalone changes that model. But that protection is not absolute in every real-world condition.

The permanent subscriber identity is no longer supposed to be exposed over the air in clear text. Instead, the device sends SUCI, the Subscription Concealed Identifier, which protects the underlying subscriber details using ECIES, the Elliptic Curve Integrated Encryption Scheme.

That means the fake base station may still attract the device, but it should not be able to read the permanent subscriber identity in clear text. That is a major architectural improvement.

But from an offensive security perspective, the important question is not simply:

Can 5G protect the identity?

The better question is:

Can the device be forced into a condition where that protection no longer applies?

This is where the operational risk remains. If a device, SIM, operator configuration or coverage environment allows fallback to 4G, then the older identity exposure path can still become relevant.

The attacker may not need to “break 5G” at all. They may only need to shape the radio environment, degrade service, manipulate selection behaviour, or force the user equipment into a weaker mode.

That is the part often missed in simplified security discussions.

Cryptography can be strong. The standard can be improved. The architecture can be better.

But the real world still depends on configuration, coverage, fallback behaviour, handset capability, operator maturity and the radio environment around the target.

For high-risk individuals, executives, journalists, legal teams, investigators and sensitive organisations, mobile surveillance risk should not be dismissed just because “5G is secure”.

The more realistic position is this:

5G Standalone makes traditional IMSI capture significantly harder, but mixed 4G/5G environments still create downgrade and exposure opportunities.

Consider:

What can be seen?

What can be forced?

What can be downgraded?

What can be tracked?

What happens when the device leaves the ideal security model and enters the real environment?

Security is not only about what the protocol promises. It is about what an attacker can make the target system do.

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

SIGINT: Know Before You’re Known

IntSpired® — Tue, 16 Jun 2026 06:18:02 +0000

Most security conversations begin at the point of impact: phishing, malware, ransomware, data breaches and compromised systems.

Those threats matter. But they are rarely where the adversary starts.

Before exploitation, there is collection.
Before intrusion, there is reconnaissance.
Before action, there is intelligence.

One area still under-discussed in the private security space is signals intelligence, or SIGINT.

Image 1: Understanding SIGINT in the Modern Threat Landscape.

Traditionally, SIGINT has been treated as a government, military or intelligence-agency discipline. But the modern threat landscape is no longer that cleanly separated.

Criminal groups, hostile actors and organised networks increasingly operate on the same principle. That is where cyber, physical security and intelligence begin to overlap.

The tools and techniques that once required state-level resource and access are increasingly available, affordable and understood beyond that world. Off-the-shelf hardware can monitor wireless environments. Geolocation data is commoditised. The barrier to conducting meaningful signals collection against a target has dropped considerably. That shift matters for any organisation that assumes its exposure begins and ends with its IT perimeter.

Image 2: Signals Intelligence Is No Longer Only a State-Level Concern.

Documented cases show organised criminal networks using phone metadata, geolocation data and signal disruption to identify law enforcement activity, evade surveillance and protect their operations. GPS jammers have been deployed to blind tracking systems during cargo theft. Counter-surveillance techniques once associated with state-level actors are now in active use by criminal organisations. The gap between state capability and criminal application is narrowing. That has direct implications for private sector organisations.

For private organisations, the lesson is clear: threat intelligence cannot stop at the firewall. The more important question is what an adversary already knows before the attack is even considered.

A mature security posture should ask:

What can an adversary observe before they attack?
What signals are we leaking?
What wireless or RF exposure exists around our people, sites, vehicles or operations?

Could location data, device behaviour, communications patterns or technical emissions be used to build intelligence against us?

Consider a straightforward example: a fleet of company vehicles passively broadcasting Bluetooth identifiers and Wi-Fi probe requests creates a pattern-of-life signature readable by anyone with basic monitoring equipment. Add mobile devices connecting to cell towers, and a picture of where your people are, how frequently they move and when routines deviate becomes available.

No breach required. No direct engagement with your systems.

Where are we visible before we are vulnerable?

Image 3: What Adversaries Can See Before They Attack.

At IntSpired®, our work is focused on that earlier phase of the threat lifecycle. We help organisations understand their own signal exposure before an adversary does, and identify where intelligence may already be accumulating against them.

That means looking beyond the obvious breach point: adversary visibility, pre-attack intelligence, wireless and RF exposure, OSINT, technical reconnaissance and the overlap between digital and physical risk.

The organisations that understand this earliest are the hardest to target.

INTSPIRED®
OFFENSIVE BY DESIGN. INTELLIGENT BY NATURE.

Sources / further reading:

This post draws on open-source reporting and public material, including:

National Crime Agency, National Strategic Assessment of Serious and Organised Crime (2024)

National Cyber Security Centre, Annual Review 2024 (2024)

Royal United Services Institute, Operation Destabilise: Russia, Organised Crime and Illicit Finance (2024)

Ofcom, Radio Frequency Jammers: Spectrum Offences under the Wireless Telegraphy Act 2006 (2023)

Privacy International, IMSI Catchers: UK Authorities Play Hide and Seek with Use of Intrusive Surveillance Technology (2023)

Satellite-to-Phone Connectivity

IntSpired® — Thu, 11 Jun 2026 05:45:44 +0000

Satellite phones are not new. What is changing is ordinary smartphones connecting directly to satellites.

For years satellite communication required specialist devices and dedicated terminals used by remote workers, maritime users, emergency responders, military personnel and journalists operating beyond normal mobile coverage.

Most people rely on terrestrial networks. That means everything connecting your phone or laptop to the internet through ground-based infrastructure. The cell tower in your street. The cables between exchanges. Your home broadband and Wi-Fi router. If it sits on the ground and carries your data it is part of the terrestrial network.

When those networks are unavailable, damaged, congested, jammed or out of range, connectivity fails. That is where direct-to-device satellite connectivity becomes relevant.

The shift has already started

Apple's satellite features allow compatible iPhones to contact emergency services with no cellular or Wi-Fi coverage. Starlink is developing direct-to-cell services using low Earth orbit satellites. AST SpaceMobile has received FCC approval to operate a constellation providing supplemental coverage through existing mobile partners.

Full satellite broadband to every phone as an everyday service is not here yet. But the move from specialist satellite hardware towards ordinary satellite-capable smartphones has begun.

Image 1: Starlink V1.5, V2 and V3.

Later Starlink satellites are expected to be larger and more capable to support direct-to-device connectivity. V3-class satellites are widely discussed as requiring Starship-scale launch capacity rather than routine Falcon 9 deployment. A larger antenna array can help the satellite focus a stronger and more precise signal beam towards a device on the ground. That is what makes connecting to an ordinary smartphone physically possible.

The signal strength problem

Many low Earth orbit communication satellites operate hundreds of kilometres above Earth. Research modelling often uses altitudes of around 550–560 km to illustrate the scale of the signal-strength challenge. Purpose-built ground terminals use large, focused antennas to receive these signals. Smartphones, by contrast, rely on much smaller built-in antennas. As a result, the received signal strength can be thousands of times weaker than with a dedicated ground terminal.

The solution is beamforming. Instead of broadcasting a signal in all directions, the satellite uses an array of antennas to focus power precisely towards a specific device. It is the difference between a lightbulb spreading light across a room and a torch aimed at a single point.

Image 2: Beamforming & Focusing the Signal.

Left: unfocused signal spreading in all directions with most power wasted. Right: beamforming concentrating power directly at the device on the ground.

A satellite has limited power. Beamforming focuses that power like a torch beam rather than spreading it like a lightbulb. This is one of the key techniques that allows a satellite to reach a standard smartphone without a specialist terminal on the ground.

Multiple satellites, one phone

Research published in 2026 by engineers at KTH Royal Institute of Technology shows how multiple satellites can coordinate to serve the same device simultaneously. Instead of connecting to one satellite a phone could receive data streams from several at once improving both speed and reliability. If one satellite moves out of range or is blocked, others may help maintain continuity. This coordination does not require the satellites to be precisely synchronised with each other removing one of the main practical barriers to real-world deployment.

Image 3: One Phone, Multiple Satellites.

Four satellites each sending a differently coloured beam to a single smartphone on the ground.

Future systems may allow a device to receive signals from several satellites simultaneously improving resilience and reducing the impact of movement, blockage or coverage gaps. Each satellite sends part of the data. The phone combines the signals.

Why this changes the risk landscape

Wider access creates wider exposure.

For ordinary users a satellite-capable phone can communicate outside normal network infrastructure even when that infrastructure is deliberately disrupted.

For organisations satellite-capable devices may bypass local network controls, corporate gateways or expected monitoring points.

The criminal threat: more than jamming

Jamming means broadcasting interference on the same frequency a satellite uses to block the signal. GPS jamming is already documented across multiple regions. Direct-to-device services use different frequencies but any wireless link can be vulnerable to interference if an attacker can affect the relevant signal path.

Spoofing mimics a legitimate signal. Spoofing or false-signal attacks could attempt to mislead devices or disrupt trust in the connection.

Covert communications. Historically, communicating beyond terrestrial network reach often required expensive and visible specialist hardware. A standard smartphone with satellite capability removes that barrier. Networks operating in remote areas, across borders or at sea gain a communications channel that no longer depends on infrastructure authorities can monitor or disrupt.

Evading lawful interception. Legal frameworks for intercepting communications are built around terrestrial infrastructure. When traffic routes through a satellite path it may complicate existing lawful intercept, monitoring and governance models that were designed for that environment.

Fraud and identity threats. SIM fraud, account compromise and interception attempts will follow satellite connectivity as they have followed every previous generation of mobile technology. Security frameworks built on terrestrial assumptions will need updating.

Physical security in sensitive locations. A satellite-capable phone carried into a restricted environment can communicate outside any local network controls in place. Existing device policies and physical security protocols may not account for this.

This technology does not create new crimes. It reduces friction, increases reach, and may weaken some existing assumptions around visibility, control and disruption.

The point for security awareness

Satellite connectivity is moving from specialist equipment into everyday phones and the infrastructure is being built now.

Criminal networks adapt quickly to new communications capabilities. They do not wait for policy frameworks to catch up. A new channel emerges, legitimate users adopt it, and those seeking to avoid detection follow.

The gap between how fast this technology is moving and how slowly security awareness tends to follow is where the risk lives.

IntSpired®
Offensive by Design. Intelligent by Nature.

References:
KTH Royal Institute of Technology, "Joint and Streamwise Distributed MIMO Satellite Communications with Multi-Antenna Ground Users" (2026)

NextBigFuture, "Satellite Direct to Cellphone — SpaceX Starlink vs Apple vs AST Space Mobile" (2025).

Tracking down a 1964 US Navy Satellite No One Could Switch Off

IntSpired® — Mon, 01 Jun 2026 06:05:54 +0000

They said it was dead. It kept transmitting.

Transit 5B-5. NORAD 965. OPS 6582.

Launched in December 1964 as part of the US Navy’s Transit satellite navigation system, the GPS of its era.

Nineteen days after launch, its navigation transmitters failed. The satellite stopped responding to commands. The telemetry transmitter could not be switched off.

This morning, from IntSpired, Cornwall, we tracked it.

Here is exactly how.

Image 1: Step 1 — Pull the orbital data.

Before you can track anything, you need to know where it is.

One command to CelesTrak. curl pulls the TLE directly from the source: two lines of orbital mechanics containing the epoch, inclination, eccentricity and mean motion.

That is everything Gpredict needs to compute where Transit 5B-5 will be, and when.

Written to 965.sat.

Ground truth established.

Image 2: Step 2 — Configure the ground station.

A satellite’s position means nothing without a reference point on Earth.

IntSpired, Cornwall, UK
50.5000°N, 5.0000°W
IO70MM
50 metres above sea level
Weather station: EGHQ

Every AOS time, LOS time, elevation calculation and Doppler prediction runs against this coordinate.

This is the anchor.

Get it wrong and nothing that follows is accurate.

Image 3: Step 3 — Wait for the geometry to align.

Forty-seven minutes to acquisition of signal.

Transit 5B-5 is 13,641 km away. Elevation -81°. Deep below the horizon. Eclipsed.

The red dotted line shows the incoming trajectory. Gpredict is computing the pass in real time. IntSpired is locked as the ground station and waiting.

This is the part nobody posts.

The prediction phase.

Knowing exactly when and where to look before anything appears.

That discipline is the skill. The SDR is just the receiver.

Image 4: Step 4 — Acquisition.

There it is.

Elevation 25.77°. Slant range 1,988 km.

Transit 5B-5 is inside IntSpired’s footprint on the map, the two points almost touching over the North Atlantic.

Doppler is at -362 Hz. The sign has already flipped, which means closest approach has passed and the satellite is now receding.

That zero-crossing happened live during the pass as the frequency shifted through zero.

That is observable proof of a real pass, not just a prediction on a screen.

Signal loss: 138.37 dB.
Orbit: 4108.
Observed from Cornwall with one dipole and one SDR.

Why this matters

Transit 5B-5 has no active operators. No mission control. No one managing it.

Its batteries failed decades ago. It appears to run directly from degraded solar cells. When it enters Earth’s shadow, the transmitter can drop within seconds. When sunlight returns, it recovers and transmits again.

It has continued doing this for more than 60 years because nobody can tell it to stop.

That is unmanaged RF exposure at the extreme end of the scale.

A signal crossing the sky that no one controls, few people monitor, and almost no one knows is there.

The workflow this morning was simple:

Gpredict.
One dipole.
One RTL-SDR.
One computer.

Nothing exotic.

The barrier to observing signals people assume are invisible is lower than most organisations think.

RF awareness is not only for signals intelligence units. It is a methodology.

It is knowing what is above your horizon, when it is there, and what it is transmitting.

That is our baseline.

Your adversary can do the same.

Watch the full pass

Countdown to AOS, acquisition, peak elevation and LOS — the complete observation recorded live from IntSpired, Cornwall:

tiktok.com

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