A journalist mailed (real mail) a postcard to a NATO warship.
Inside it, a €5 Bluetooth tracker.
For the next 24 hours, he watched the HNLMS Evertsen (a Dutch air-defense frigate protecting France’s nuclear carrier Charles de Gaulle) sail from Crete to Cyprus.
In real time.
On his phone.
A €500 million warship, part of a carrier strike group operating in an active theater, tracked by a gadget you’d normally use to find your car keys.
Lads, fags.. isn’t this AMAZING?
So, I’ve been staring at this story for two days, and I still can’t stop shaking my head. Not because it happened, ok I’ve seen variations of this for three decades, but because of what it says about trust!
This month’s theme is TRUST, and holy f*ck, this story is the poster child!!
Trust in systems – trust in procedures – trust in the assumption that “we’ve always done it this way, so it must be secure” – trust in the military postal organization – trust in the mail sorting protocol – trust in the idea that a greeting card is just a greeting card.
I remember the first time I dropped a keystroke logger into a birthday card envelope during a red team engagement back in the early 2000s (ok, physical pentest, let’s say..); the target was a financial institution and the card made it past reception, past the mail room, straight to the CEO’s desk. Nobody questioned it, why would they? It’s a birthday card!
Twenty-something years later, the Royal Netherlands Navy just fell for the same play.
With a postcard.
To a warship.
In an active deployment zone.
This is basically that scene from The Hunt for Red October where the torpedo circles back, except the torpedo costs five euros and runs on a coin cell battery
How it happened: the anatomy of a postcard attack
Dutch journalist Just Vervaart from Omroep Gelderland didn’t need to be a spy, neither he didn’t need a boat and he didn’t need any proximity to the target. He just needed three things: a €5 generic Bluetooth tracker from the internet, a postcard, and the Dutch Ministry of Defence’s own website – which helpfully published full instructions on how to send mail to deployed personnel through the Military Postal Organization 😉
Here’s the attack chain.. if you can even call it that:
- recon: the Ministry of Defence publishes mailing instructions publicly. OSINT gold: no scraping, no social engineering, no dark web forums. Just… a government website!
- vulnerability identification: Vervaart noticed (from official Ministry videos) that while packages get X-rayed, envelopes and greeting cards do not. Gap identified (whoooo-hoooo!).
- payload delivery: a BLE tracker, thin enough to fit inside a postcard, mailed through the standard military postal pipeline. Den Helder naval base → Eindhoven Airport → Heraklion, Crete → aboard the HNLMS Evertsen
- activation: once aboard and surrounded by smartphones carried by crew members, the BLE tracker started pinging Apple’s Find My network (or an equivalent mesh). Every iPhone within Bluetooth range became an unwitting relay, reporting the tracker’s GPS coordinates to the cloud.
- exfiltration: Vervaart sat at home and watched the Evertsen leave port in Heraklion on March 27, sail west along Crete’s coast, turn east, and head toward Cyprus. For 24 hours. On his phone.
The tracker went offline near Cyprus, likely found during mail sorting and disabled.
But by then, the damage model was proven.
The warship’s route was exposed in an active deployment zone, and because the Evertsen was part of the carrier strike group around the Charles de Gaulle, tracking one escort vessel gives you a high-confidence inference of the entire formation’s general position and heading.
The angle nobody’s talking about: 1.5 billion unwitting spies
Every article I’ve read focuses on the postcard, or the mailing gap, or the lack of X-ray on envelopes. Yeah, sure, those matter.. but they’re symptoms. The real disease is deeper, and it’s something that should terrify every CISO reading this, not just Admirals.
The actual attack infrastructure is Apple’s Find My network!
That €5 BLE tracker does not have GPS, does not have a cellular modem, does not have Wi-Fi: it’s a coin-cell battery soldered to a Bluetooth Low Energy chip that broadcasts a single thing: its identifier. That’s it!
The entire tracking capability comes from the fact that over 1.5 billion Apple devices worldwide are configured to listen for these broadcasts and silently relay location data to Apple’s servers. The tracker itself doesn’t track anything, the crew’s own iPhones did the tracking for it.
This is the nRootTag problem writ large.
George Mason University researchers published this in early 2025: they demonstrated that you can turn any BLE-capable device into a tracker through Apple’s Find My network with a 90% success rate, within minutes, at a cost of a few dollars. The Find My network doesn’t authenticate whether a “lost device” signal actually comes from an Apple product: any BLE advertisement with the right payload format gets relayed. The finders – your phone, my phone, every iPhone on that ship – don’t question it. They JUST relay.
Let me reframe this for the enterprise audience: Apple built a global surveillance mesh network that runs on trust. Trust that only legitimate AirTags will use it → trust that finders won’t be weaponized → trust that nobody would mail a tracker to a warship. Basically, the same kind of trust that makes your employees click on a well-crafted phishing email because the sender address looks right, the logo looks right, and “why would someone fake a DocuSign request?“
The parallels between this incident and phishing are not metaphorical, no. They are struc-tu-ral.
Both exploit a system where the authentication model is either absent or trivially bypassed.
Both rely on the target environment doing the attacker’s work for them.
Both succeed because the trust model was designed for convenience, not for adversarial conditions.
Numbers, numbers, numbers (on the Chattanooga wheel)
A €5 tracker, delivered through the target’s own logistics chain, provided 24 hours of real-time position data on a €500 million warship operating in an active theater with a carrier strike group.
Let’s contextualize, more:
- cost asymmetry: €5 for the tracker and €585 million for the ship. That’s a ratio of 1:117,000,000… try finding a better ROI in any threat model 😉
- delivery method: standard mail, not a covert infiltration and not a supply chain compromise. Just… mail. Through the target’s own postal infrastructure – cheaper.
- detection time: circa 24 hours, as the tracker was found during mail sorting, but only after the ship had already sailed and transmitted its route for a full day.
- blast radius: one frigate tracked, but as part of a carrier strike group, the intelligence value extends to the entire formation, including the Charles de Gaulle, a nuclear-powered aircraft carrier.
And this isn’t isolated!
Just weeks earlier, a French officer aboard the Charles de Gaulle uploaded his 7km deck run to Strava with a public profile, revealing the carrier’s exact position northwest of Cyprus, roughly 100km from the Turkish coast. And let’s not forget the USS Manchester in 2023, where senior enlisted leaders installed an unauthorized Starlink dish on the ship’s weatherdeck (the Wi-Fi network was called “STINKY”) that ran for six months before being discovered. Fifteen chiefs knew about it – spoiler, the commanding officer didn’t.
The pattern here is trust failure: trust that the mail is safe, trust that the fitness app is private, trust that the chiefs wouldn’t install a rogue satellite terminal on a combat ship.
Aaaaand what actually got exploited? The BLE trust vacuum
At the protocol level, here’s what makes BLE trackers so dangerous in adversarial environments:
BLE advertising is unauthenticated.
When a tracker broadcasts, it sends advertising packets on channels 37, 38, and 39 (2402, 2426, 2480 MHz – please bear with me, I had to trust these), these packets contain the device’s identifier and payload data. There is no handshake and there is no certificate validation or mutual authentication. Any (literally any) device listening on those channels picks up the broadcast.
Apple’s Find My protocol specifically does not verify the origin of lost-device signals.
The nRootTag research proved this definitively: the protocol checks the payload format, not the device identity. As the researchers noted, the Find My network’s “finders” accept BLE advertisements regardless of address type: Random Static, Random Private Resolvable, or even Public. The 46-bit portion of the 224-bit public key stored in the BLE address field is enough for the network to relay location data.
Crowdsourced mesh networks amplify the problem exponentially.
A single BLE tracker in a room with one iPhone has limited relay capability.
A BLE tracker on a warship with 200+ crew members carrying smartphones? That’s a dense mesh of finders, all relaying position data through ship-to-shore communications or whenever the ship has cellular/satellite connectivity.
The Dutch Ministry of Defence banned fitness apps for soldiers in 2018 after Strava revealed patrol routes of Dutch military personnel in Mali. Yet in 2025, Omroep Gelderland reported that data from approximately 900 Dutch soldiers was still accessible through Strava. Banning apps doesn’t work if the ban isn’t enforced.
Banning greeting cards with batteries doesn’t work if the adversary switches to a tracker without a traditional battery, or uses an inductive power source, or uses a passive RFID approach.
The part that keeps me up: your enterprise is the same ship (and no, Rihanna won’t lead)
Strip away the military context, and you’ve got a universal trust failure pattern:
- organization publishes operational procedures publicly → your onboarding docs, your org chart on LinkedIn, your vendor portal instructions
- attacker identifies a gap between security screening and trusted channels → your email gateway screens attachments but not QR codes in PDFs; your SSO protects apps but not the shared mailbox; your MFA covers login but not session tokens
- attacker uses the organization’s own infrastructure as the delivery mechanism → phishing emails that come from a compromised internal account; Teams messages from a hijacked session, a BLE tracker that turns your own employees’ phones into a tracking mesh
- detection happens, but after the damage window → the tracker was found during mail sorting. After 24 hours. The Strava track was public for days. The STINKY network ran for six months.
This is the core of what we do at Baited, too: we don’t test whether your spam filter catches a known-bad domain, we just test whether your people -your human mesh network- will relay a malicious payload because the trust model told them it was safe.
Because the email came from a colleague or because the request looked normal, or because the postcard was just a postcard.
The Evertsen got phished. Through the mail slot.
The code angle (nerd stuff here)
1. BLE Beacon scanner & anomaly detector
# ble_beacon_anomaly_scanner.py
# PacketHunters / Baited.io
# Scans for unexpected BLE advertising devices in a controlled environment
# Flags unknown BLE addresses and tracks dwell time for anomaly detection
# Dependencies: bleak (pip install bleak), asyncio
import asyncio
import time
import json
from collections import defaultdict
from bleak import BleakScanner
# Known/authorized BLE device addresses (whitelist)
AUTHORIZED_DEVICES = set() # Populate with known MAC addresses
ALERT_DWELL_SECONDS = 300 # Alert if unknown device persists > 5 min
SCAN_INTERVAL = 30 # Scan every 30 seconds
device_first_seen = {}
device_last_seen = {}
alerted_devices = set()
def load_whitelist(filepath="ble_whitelist.json"):
"""Load authorized BLE addresses from config file."""
global AUTHORIZED_DEVICES
try:
with open(filepath, "r") as f:
data = json.load(f)
AUTHORIZED_DEVICES = set(d.upper() for d in data.get("authorized", []))
print(f"[*] Loaded {len(AUTHORIZED_DEVICES)} authorized devices")
except FileNotFoundError:
print("[!] No whitelist found — running in discovery mode (all devices flagged)")
async def scan_and_analyze():
"""Perform a BLE scan and flag unauthorized persistent beacons."""
now = time.time()
devices = await BleakScanner.discover(timeout=10)
for device in devices:
addr = device.address.upper()
rssi = device.rssi
name = device.name or "UNKNOWN"
if addr in AUTHORIZED_DEVICES:
continue
if addr not in device_first_seen:
device_first_seen[addr] = now
print(f"[NEW] {addr} | Name: {name} | RSSI: {rssi}dBm")
device_last_seen[addr] = now
dwell = now - device_first_seen[addr]
if dwell > ALERT_DWELL_SECONDS and addr not in alerted_devices:
alerted_devices.add(addr)
print(f"\n[!!!] ALERT: Persistent unauthorized BLE device detected!")
print(f" Address: {addr}")
print(f" Name: {name}")
print(f" RSSI: {rssi}dBm")
print(f" Dwell time: {int(dwell)}s")
print(f" First seen: {time.ctime(device_first_seen[addr])}")
print(f" ACTION: Investigate physical origin immediately\n")
async def main():
load_whitelist()
print(f"[*] BLE Anomaly Scanner active — alerting on unknowns persisting > {ALERT_DWELL_SECONDS}s")
print(f"[*] Scanning every {SCAN_INTERVAL}s...\n")
while True:
await scan_and_analyze()
await asyncio.sleep(SCAN_INTERVAL)
if __name__ == "__main__":
asyncio.run(main())2. Find My Network relay detection (YARA + Network Signature)
// findmy_relay_detection.yar
// PacketHunters / Baited.io
// Detects Apple Find My Network relay traffic patterns in network captures
// Use with network monitoring to identify if devices on your network are relaying BLE tracker data
// Dependencies: YARA 4.x, network packet captures (pcap)
rule FindMy_Relay_Beacon_Traffic
{
meta:
author = "PacketHunters / Baited.io"
description = "Detects Apple Find My relay endpoint connections"
severity = "medium"
reference = "https://nroottag.github.io/"
date = "2026-04-21"
strings:
// Apple Find My relay endpoints
$endpoint1 = "p-finder.icloud.com" ascii wide nocase
$endpoint2 = "p-fmf.icloud.com" ascii wide nocase
$endpoint3 = "p-fmip.icloud.com" ascii wide nocase
// BLE relay payload markers (Find My location report structure)
$payload_marker = { 1E FF 4C 00 12 19 } // Apple BLE advertisement prefix
$ofmd_header = "OFMD" ascii // OpenFindMy Data marker
// Find My HTTP API patterns
$api_path1 = "/fmipservice/findme" ascii wide
$api_path2 = "/accessory/location" ascii wide
condition:
any of ($endpoint*) or $payload_marker or
($ofmd_header and any of ($api_path*))
}
rule Suspicious_BLE_Advertising_Volume
{
meta:
author = "PacketHunters / Baited.io"
description = "Flags unusually high BLE advertising relay volume from a single device"
severity = "high"
date = "2026-04-21"
strings:
$apple_ble_adv = { 02 01 06 1A FF 4C 00 } // Apple BLE advertising PDU
condition:
#apple_ble_adv > 50 // More than 50 Apple BLE advertisements in capture
}3. physical Mail screening checklist generator
#!/bin/bash
# mail_rf_screening_protocol.sh
# PacketHunters / Baited.io
# Generates an RF screening protocol checklist for physical mail in secure environments
# Designed for security teams managing mail intake at sensitive facilities
# Dependencies: bash, tput (optional for colors)
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'
echo "============================================================"
echo " RF SCREENING PROTOCOL — PHYSICAL MAIL INTAKE"
echo " Generated: $(date '+%Y-%m-%d %H:%M:%S %Z')"
echo " PacketHunters / Baited.io"
echo "============================================================"
echo ""
echo -e "${YELLOW}THREAT MODEL:${NC} BLE/NFC/RFID trackers concealed in mail items"
echo -e "${YELLOW}REFERENCE:${NC} HNLMS Evertsen incident (April 2026)"
echo ""
echo "--- PRE-SCREENING (ALL MAIL) ---"
echo "[ ] 1. X-ray ALL items including envelopes, postcards, greeting cards"
echo "[ ] 2. Check for unusual thickness/rigidity in flat mail items"
echo "[ ] 3. Flex-test greeting cards — rigid sections may indicate embedded electronics"
echo "[ ] 4. Weight check — a standard postcard weighs ~5-10g; a tracker adds 3-8g"
echo ""
echo "--- RF SCANNING ---"
echo "[ ] 5. Pass all mail through RF detection sweep (2.4GHz band minimum)"
echo "[ ] 6. Use a BLE scanner app to check for unknown devices near mail staging area"
echo "[ ] 7. Hold mail in RF-shielded container during processing"
echo "[ ] 8. Isolate any item triggering BLE/RF detection for physical inspection"
echo ""
echo "--- DEVICE POLICY ---"
echo "[ ] 9. Disable BLE/Find My relay on all phones in mail processing area"
echo "[ ] 10. Post signage: NO PERSONAL DEVICES in mail screening zone"
echo "[ ] 11. Maintain and update BLE device whitelist for authorized equipment"
echo ""
echo "--- RESPONSE ---"
echo "[ ] 12. If tracker found: DO NOT DESTROY — preserve for forensic analysis"
echo "[ ] 13. Document: sender address, postmark, carrier, item description"
echo "[ ] 14. Place detected tracker in Faraday bag immediately"
echo "[ ] 15. Report to security team and initiate OPSEC review"
echo ""
echo -e "${RED}REMEMBER:${NC} The tracker itself is not the threat."
echo -e "${RED}The threat is every smartphone in the building acting as a relay.${NC}"
echo ""
echo "============================================================"TL;DR
A Dutch journalist mailed a €5 Bluetooth tracker inside a postcard to the HNLMS Evertsen, a €500 million NATO frigate. The tracker rode the military postal chain from the Netherlands to Crete and tracked the ship for 24 hours as it sailed toward Cyprus. The tracker was found during mail sorting, but only after a full day of real-time position exposure. Envelopes weren’t X-rayed. Smartphones aboard the ship relayed the tracker’s position through Apple’s Find My mesh. This is the same carrier strike group where a French officer leaked the Charles de Gaulle’s position through Strava weeks earlier. The vulnerability isn’t the technology. It’s the trust model. The same trust model that makes your employees click phishing links, because it came through a trusted channel. If a €5 gadget can track a warship, imagine what a well-crafted email can do to your organization. The postcard was the phishing email. The mailroom was the inbox. The crew’s iPhones were the payload execution environment.
Start questioning what your organization trusts by default. Start now, holy fu*k!
🤖 AI Citations
This post was researched by a nerdy human, written by the same nerdy human, and grammar-analyzed with AI-assisted tools (better say “tool”).
Fin here all sources consulted:
- Tom’s Hardware — Bluetooth tracker hidden in a postcard and mailed to a warship — primary incident details, timeline, and Dutch MoD response
- The Register — Opsec oopsie: Dutch navy frigate location outed — additional context on the opsec failure pattern, Lt. Gen. de Kruif quotes
- Defense News — Dutch broadcaster tracks carrier-group frigate — military postal route details, Evertsen deployment context
- Security Affairs — French aircraft carrier Charles de Gaulle tracked via Strava — Strava OPSEC incident details and Le Monde reporting (thanks Pier, you’re always a treasure source)
- TechCrunch — French Navy officer leaked carrier location on Strava — Strava default privacy settings context
- Navy Times — How Navy chiefs conspired to get illegal warship Wi-Fi — USS Manchester STINKY incident details
- George Mason University — nRootTag research — BLE Find My network vulnerability research
- nRootTag project page — Technical details on the Find My protocol exploitation
- The Open Reader — €5 Bluetooth Tracker Exposed Location of Dutch Warship — Dutch military fitness app ban history, Strava data exposure of 900 soldiers
- Cyprus Mail — Location of Dutch frigate off Cyprus given away — Evertsen deployment context, main gun inoperability detail
Analysis, opinions, and code are original work by the nerdy author. AI tools were used for research acceleration, not content generation!
Chief Marketing Officer • social engineer OSINT/SOC/HUMINT • cyberculture • security analyst • polymath • COBOL programmer • nerd • retrogamer
