Every place has two RF layers. Stuff that’s always there and stuff that fires when something happens. Once you can tell them apart, the spectrum stops looking like static and starts looking like an inventory.

The premise

A house broadcasts more than people realise. Weather sensors that ping every 30 seconds. A smart meter that wakes up on its own schedule. The garage door, which is silent until it isn’t. Door contacts. A neighbour’s tyre pressure sensors driving past. Half of it is licensed ISM band traffic, the rest is whatever the manufacturer thought they could get away with.

I wanted to know, concretely:

• What devices in my own environment are emitting, and on what frequencies
• Which of them are predictable (heartbeats, polling) and which are reactive
• What’s mine vs what’s leaking in from outside

No reversing protocols yet. Just identification.

Tooling shift: rtl_433 does most of the work

rtl_power from pt 1 is fine for surveying energy. For identification, rtl_433 is what you want. It ships with decoders for hundreds of consumer devices on the common ISM bands and will happily print everything it recognises as JSON.

rtl_433 -F json -M time:iso -M level

That’s the entire starting command. No frequency argument means it sits on 433.92 MHz. Once it’s running, walk around the house and trigger things. Press the doorbell, open a window with a contact sensor, lock and unlock the car from inside. Anything decoded will print a line.

To save it:

rtl_433 -F json -M time:iso -M level 2>/dev/null \
  | tee -a ~/rf/rtl_433_$(date +%F).jsonl

JSONL is the right format here. One event per line, append-only, trivial to grep through later.

For other bands you tell it explicitly:

rtl_433 -f 315M -F json   # North American garage doors, TPMS, some fobs
rtl_433 -f 868M -F json   # European alarm sensors, smart meters
rtl_433 -f 915M -F json   # NA ISM, weather stations, some utility meters

If you have a HackRF, hackrf_sweep is the wider-net version for finding where activity is in the first place:

hackrf_sweep -f 300:960 -w 100000 -1 > sweep.csv

One pass from 300 to 960 MHz, 100 kHz bins, single sweep. Open it, see where the energy is, then point rtl_433 at the live bands.

Pass 1: the always-on layer

I left rtl_433 running on 433 MHz for a few hours with nobody touching anything in the house. The point was to see what fires on its own.

What showed up in my environment:

• A weather station outside that transmits temperature and humidity every 47 seconds, like clockwork. Same device ID every time.
• Soil moisture sensors from the garden, less frequent, but every device announces itself with the model name in the decoder output.
• A smart meter reading that wasn’t mine, coming from the direction of the neighbours’ wall.
• An LPG tank level sensor I’d forgotten was wireless.

The pattern is heartbeats. Always-on devices want to be polled, so they shout into the void on a fixed interval, and the interval itself is fingerprintable. If a sensor pings every 47 seconds with the same ID, you can plot it on a timeline and the gaps tell you when the device was off or out of range.

A useful question to ask of every constant emitter: do I own this? If not, why can I hear it, and what does that say about how far my receiver is reaching.

Pass 2: the event-driven layer

This is where you walk around the house being a nuisance. Press every button, open every door, trigger every motion sensor you know about. Have rtl_433 logging the whole time.

What I found:

• The garage door remote at 433.92 MHz, rolling code, decoder didn’t name it but the bit pattern is consistent per press.
• A wireless doorbell on 433 that the decoder identified by model.
• Two PIR sensors from the alarm panel that wake up on motion and stay quiet otherwise.
• Three door contacts that send a short burst on open and another on close.
• The TV remote, which is IR not RF, and reminded me that not everything you press is going to show up on an SDR.

The car key fob didn’t decode cleanly on 433. That one was on 868 in this region, which I only confirmed by re-running rtl_433 on the other band while pressing the unlock button.

Event-driven traffic is the more interesting half because it’s tied to physical state changes. A door contact that hasn’t transmitted in 12 hours either means the door hasn’t moved or the sensor is dead. Both are useful pieces of information if you’re the one who owns the network.

Building the inventory

After a couple of sessions I had enough to start a flat inventory. Mine looks like a TSV with these columns:

freq_mhz    type            label                   cadence         protocol_or_model
433.92      heartbeat       weather_station_outside ~47s            Acurate-986
433.92      heartbeat       soil_sensor_bed_1       ~5min           Generic-FS20
433.92      event           garage_door_remote      on_press        unknown_rolling
433.92      event           doorbell_front          on_press        Honeywell-RCWL
433.92      event           door_contact_kitchen    on_state_change unknown
868.30      heartbeat       smart_meter             ~10s            wmbus
868.30      event           car_fob                 on_press        unknown
915.00      heartbeat       (neighbour) utility     ~30s            unknown

That’s enough to do real things with. If something new shows up that isn’t on the list, it’s either a new device I just installed, a neighbour got something, or somebody’s nearby holding a transmitter. Any of those is worth a glance.

A small script for the boring part

The bit I wanted automated was “tell me what’s new since yesterday”. This is a 20-line script, not a project:

#!/usr/bin/env python3
import json, sys, collections

seen = collections.defaultdict(int)
for line in sys.stdin:
    try:
        d = json.loads(line)
    except json.JSONDecodeError:
        continue
    key = (d.get("model","?"), d.get("id","?"), round(d.get("freq",0), 2))
    seen[key] += 1

for (model, dev_id, freq), count in sorted(seen.items(), key=lambda x: -x[1]):
    print(f"{count:6d}  {freq:7.2f} MHz  {model:30s}  id={dev_id}")

Pipe a day of JSONL through it:

cat ~/rf/rtl_433_2026-06-01.jsonl | ./rf_summary.py

The output is a leaderboard of which device IDs were most active. New entries are obvious. Missing entries are obvious. That’s most of what you need for daily checks.

What surprised me

A few things from this round.

The smart meter wasn’t mine. It’s loud enough to clear the wall. That’s not a vulnerability exactly, but consumption telemetry leaving the building in the clear is a thing worth knowing about.

Cars driving past show up. TPMS sensors transmit at 315 or 433 depending on region and you can see them passing if you’re logging long enough. None of it is identifying on its own, but the pattern of passes is.

A device I thought was wired was wireless. The LPG tank sensor was installed by a contractor years ago and I had no documentation on it. The decoder gave me the model in one line of JSON.

Most “smart” devices announce themselves by manufacturer in the protocol header. There’s no obscurity here. If it’s on a hobbyist decoder list, it’s identifiable.

What I’m not doing

Not replaying anything. Not transmitting on the HackRF. Rolling code captures are interesting from a “how does this work” point of view, but the moment you press the button on a transmitter aimed at someone else’s gate you’ve crossed a line that isn’t worth crossing. The HackRF stays on receive.

Not trying to demodulate anything rtl_433 doesn’t already know about. URH (Universal Radio Hacker) is the next step for that and it’s its own rabbit hole.

Lessons

A few short ones.

Heartbeats are gold. Anything with a fixed cadence is easy to spot, easy to baseline, easy to alarm on when it goes quiet.

The decoder is more useful than the waterfall once you know roughly where things live. Waterfalls are for finding signals. Decoders are for identifying them.

Region matters. ISM bands are different in EU, US, and AU. If a fob doesn’t show on 433, it’s probably on 315 or 868. Try the other ones before assuming the hardware is broken.

Your inventory will outlive any single script. Keep it in a flat file you can read in ten years.

What’s next

A 30-day version of the inventory, with cadence drift tracking. If the weather station’s 47-second heartbeat starts arriving every 52 seconds, I want to know about it.

Some long captures on 868 MHz. The smart meter and the car fob are both there and I haven’t given that band the time it deserves.

A small dashboard. Probably a static page that reads the JSONL and renders last-seen times per device. Not a project, just a page.

Legal

Same as before. Receiving on bands I’m allowed to receive on, in an environment I own, on equipment I own. No transmitting, no replaying, no decoding anything that isn’t mine to look at. RF is the kind of hobby where the line between curious and a problem is short and worth respecting.

This is a notes post about standing it up, how it’s contained, and what actually showed up in the logs after a month.

Why bother

Most threat intelligence I read describes the internet as a battlefield. Every unpatched device is five minutes from compromise. Every IP gets 30,000 probes a day. The numbers are usually correct. They aren’t useful unless you can map them to what your environment looks like.

I wanted my own baseline. Not a vendor’s feed, not an aggregated report. What does my ISP-assigned IP attract, right now, and what does the traffic look like when you strip out the marketing spin.

Secondary reason: I wanted to segment the network, and a honeypot is a good forcing function. My homelab had been flat for too long. Nothing makes you VLAN a network faster than hanging something deliberately exposed off it.

Threat model and ground rules

Before anything went online, I wrote down what I was willing to tolerate and what I wasn’t.

Willing to accept:

• My IP appearing on scanning blocklists.
• My ISP sending me a polite note. (They never did.)
• Getting buried in logs I’d then have to process.

Not willing to accept:

• Anything the honeypot attracts touching my real LAN.
• A honeypot compromise turning into a pivot into anything else I own.
• Outbound traffic that looks like I’m participating in someone else’s botnet.

Those three constraints drove every architectural decision that followed.

Architecture

The honeypot runs as a single VM on a secondary host, isolated on its own VLAN behind OPNsense. It has one purpose, no shared storage, no shared credentials, and nothing legitimate behind it. If it gets popped, I wipe the VM from snapshot and start again.

The physical picture:

• Honey-VM: 4 vCPU, 8 GB RAM, 60 GB disk. Ubuntu 22.04 base, T-Pot on top.
• VLAN 66: dedicated “DMZ-lite”. No inter-VLAN access. DHCP scoped tight.
• OPNsense: port-forwards a curated set of TCP ports from WAN to the honey-VM.
• Suricata on the OPNsense WAN interface logs everything hitting those ports, independent of what the honeypot itself sees.
• Outbound rules on VLAN 66: no outbound except to a specific syslog collector and to Cloudflare DoH for DNS. No SSH out, no SMB out, no SMTP out, no arbitrary outbound anything.

The last point is the one that matters most. A honeypot with open outbound is a honeypot that can participate in the abuse you’re trying to study. If Cowrie accepts a shell and the intruder tries to curl a second-stage payload, they should fail at the network, not at the endpoint.

Ports exposed to the internet: 22, 23, 80, 443, 445, 1433, 2222, 3306, 3389, 5060, 5900, 8080. Nothing else.

Stack

I used T-Pot for the heavy lifting. It’s maintained, it aggregates sensible honeypots, and its dashboards are ready out of the box. The components that mattered for me:

• Cowrie on 22 and 2222. SSH and Telnet. Logs full session transcripts.
• Dionaea on 445, 1433, 3306, 5060. Protocol emulation for SMB, MSSQL, MySQL, SIP.
• Heralding on anything else that smells like a login prompt.
• Honeytrap as the generic catch-all TCP listener.
• Snare / Tanner serving HTTP decoy content on 80 and 8080.
• Elasticsearch + Kibana for the dashboards, with data shipped out to my own Loki instance as a backup.

T-Pot’s internal firewalling is fine, but I don’t rely on it. The OPNsense rules are the real enforcement. If T-Pot broke tomorrow, nothing on VLAN 66 would suddenly start talking to my real network.

Standing it up

Provisioning was uneventful once the segmentation was in place.

# T-Pot install on a fresh Ubuntu 22.04
env bash -c "$(curl -sL https://ghst.ly/tpot-install)"

The installer handles Docker, pulls the containers, and wires up the reverse proxy for the Kibana side. The one thing I changed was restricting the admin web interface to the management VLAN, reachable only over WireGuard.

SSHD for actual host management got moved to a non-standard port on the management interface. Cowrie owns 22 on the WAN side.

Before opening the firewall, I ran a full scan from an external VPS against the advertised ports to make sure only the intended services responded, and that the banners looked realistic enough to not scream “honeypot” on the first handshake. A couple of Cowrie defaults were too obvious (the default SSH version string, for one) and needed tweaking. Anyone running OpenCanary fingerprints or Shodan’s honeypot detector will still figure it out. Most bots won’t.

First 24 hours

I expected a slow ramp while DNS caches and scanners noticed the IP. That wasn’t the experience.

Within 12 minutes of opening port 22, the first SSH login attempt came in. Inside the first hour: 340 SSH attempts from 47 unique source IPs. By the end of the first day: 8,200 SSH attempts, 1,100 HTTP requests, and around 60 SMB connections.

There is no onboarding period for a public IP. You’re in the database already. Opening a port just tells the scanners that something is finally listening.

What 30 days actually looked like

Rough totals at the 30-day mark (Suricata plus T-Pot aggregated):

• SSH and Telnet attempts: 412,000 across 22 and 2222, from 14,300 unique source IPs.
• HTTP requests to honeypot web roots: 28,400. Mostly scanner fingerprints and path probes.
• SMB connections: 3,900.
• MSSQL login attempts: 1,100.
• RDP connections: 9,700, almost all from a handful of subnets running NLA probes.
• SIP INVITE floods: two distinct campaigns, one targeting Asterisk defaults, one targeting a specific FreePBX module.

Geography is the least interesting dimension and the one vendors love to lead with. Source IPs spread across 90+ countries. That maps to compromised hosts, not operator location. Treating a GeoIP heatmap as a map of threat actors is a mistake.

The credential side is more useful. Top ten SSH username/password combinations over the 30 days, in order:

1. root / root
2. admin / admin
3. root / 123456
4. root / password
5. admin / password
6. user / user
7. ubnt / ubnt
8. pi / raspberry
9. root / 1234
10. support / support

None of those will surprise anyone who’s spent time on this. They confirm what the big honeypot operators have been saying for years: the low end of the attack surface is stuck on the same dictionary it’s been stuck on for a decade, because it keeps working.

What the payloads looked like

Cowrie logs full session transcripts, which is the part worth reading. Patterns I saw repeatedly:

• uname -a; cat /proc/cpuinfo; free -m as environment fingerprinting before any payload drop. The bot wants to know whether it landed on an ARM router, a MIPS camera, or an x86 box, so it can pull the right binary.
• A wget or curl chain pointing at a staging server, usually on port 80 over a direct IP with no DNS. Almost always a short-lived URL, dead within days.
• A chmod 777 on the downloaded binary, followed by ./<binary> and a quick rm to clean up.
• Busybox-style commands with shell tricks to survive minimal environments.

Three payloads I captured and detonated in an isolated environment later:

• A Mirai variant targeting MIPS and ARM, with the usual hardcoded C2 list.
• A Monero miner compiled for x86_64 with an embedded pool address and worker ID.
• An XorDDoS dropper with the “encrypted” strings still trivially XOR-decodable against a one-byte key.

Nothing novel. That’s the point. The mass of the internet’s attack noise is bots spraying five-year-old payloads at anything that looks like a vulnerable edge device. A residential IP running no listening services would never see this traffic because the TCP connections would simply RST. Exposing ports makes you legible to the layer that scans for this kind of target.

The quieter, more interesting traffic

Once you filter out the SSH brute force floor, and it is a floor of roughly 300 to 600 attempts per hour, the rest gets more varied.

Log4Shell probes still show up on HTTP. More than two years after the advisory, JNDI probes are a standing wave. Most point at self-hosted Burp collaborators or long-dead VPS callbacks. Somebody, somewhere, is still paying for a scanner that fires these shots and never checks whether anyone answered.

A handful of requests were clearly scripted against specific CVEs:

• GPON router authentication bypass (CVE-2018-10561 / 10562). Still hitting in 2026.
• Various Ivanti and Fortinet path traversals.
• Confluence OGNL injection strings.
• Generic WordPress xmlrpc.php pingback fishing.

The unusual one: a small cluster of requests that tried to negotiate TLS with an SNI matching a real banking domain. No credentials, no follow-up. Probably a scanner doing inventory for cert transparency lookups. Possibly something less innocent. I don’t have enough data to tell, and that’s the honest answer.

Operational reality

A honeypot is not a set-and-forget box. In the first week I burned an evening chasing false positives and another fixing log rotation before a partition filled. The real costs:

• Disk grows fast. Cowrie session logs plus Elasticsearch indices ate about 18 GB in 30 days. That’s cheap, but it isn’t free.
• Containers drift. Watchtower handles the weekly pull. I still review breaking changes in the T-Pot release notes before merging.
• Elasticsearch is memory-hungry and will swap itself into uselessness if you underprovision. 8 GB is the practical floor.
• Alerting is where this gets useful. A 500-per-hour SSH baseline is noise. A successful Cowrie shell that persists for more than 30 seconds, or any outbound hit blocked at the OPNsense rule, is signal. Those page me. Everything else goes to a dashboard I check when I feel like it.

The alerting config is where most of my ongoing time goes. Without it, the whole thing is a pretty dashboard.

What I’d change

A few things I’ll do on the next iteration:

Split the honeypot across two IPs. Run Cowrie on one, everything else on the other. The SSH noise crowds the indices and makes queries slower than they need to be.

Move the dashboards off the honey-VM entirely. Shipping to an external Loki instance is already half the work. The remaining Kibana stack on-box is there for convenience, not necessity.

Add a second outbound-blocking layer inside the VM itself. Defence in depth against a container escape I’m still not fully satisfied with.

Log rolling PCAPs on a 7-day window. Right now I only have what Suricata and the honeypots chose to log. Full packet captures would let me revisit sessions I under-investigated at the time.

Does this change what I do at work

Partially. It doesn’t change how I think about APT-level adversaries. Nothing I saw in 30 days would strain a reasonable environment.

What it changes is how I talk about the baseline. The background radiation of the internet is real, it’s measurable, and it doesn’t stop. Any machine with an unpatched edge service survives hours, not days. Any default credential on a public interface is already compromised. You just haven’t noticed yet.

That isn’t a marketing line. That’s 412,000 login attempts across 30 days on one residential IP running an obvious honeypot.

Closing

Segment first. Then break something on purpose, in a place where it can’t reach anything you care about. The logs that come back are more honest than any vendor report.

I’ve started digging into RF, meaning anything noisy in the air that my SDR can see. This is a quick log of the first sessions using an RTL-SDR (cheap, RX-only) and a HackRF One (wider bandwidth, TX-capable, which stays off outside a legal setup).

This isn’t a decoding write-up. The goal for now is observation: watch the spectrum, log activity, and build something useful.

The kit

• RTL-SDR (RTL2832U + R820T): cheap receive, wide community support, good for learning.
• HackRF One: wider tuning range, bigger bandwidth, better lab potential.

Antennas matter more than most people want to admit. A random wire will pick something up, but it’ll also mislead you.

What I’m trying to do (v1)

Three things:

1. Scan a band, starting with the 433 MHz junk drawer
2. Log energy and activity over time to CSV
3. Watch live when a remote is pressed or something triggers

No demodulation, no protocol reversing yet. Just what’s alive and when.

RTL-SDR: first scans and the empty CSV problem

rtl_power is the right starting point for band surveys:

rtl_power -f 430M:440M:50k -i 1 -g 30 -e 15s /tmp/rtl_433_test.csv
head -n 3 /tmp/rtl_433_test.csv

Two things showed up immediately:

• Frequency hops, FFT bins, the tool doing its job.
• This line:

[R82XX] PLL not locked!

It looks bad. In practice it’s common with these dongles and the data is often usable anyway. If it looks broken, try adjusting the frequency range slightly, dropping the gain, swapping the USB port or cable, or ruling out power starvation.

The other thing: the numbers move even when you think nothing is happening. Your receiver sees something constantly. The job is separating signal from noise and logging it so you can compare runs over time.

HackRF: the access denied wall

hackrf_info

hackrf_open() failed: Access denied (insufficient permissions) (-1000)

Linux has the hardware, you don’t. Fix it with udev rules.

The fix

Add yourself to the plugdev group:

sudo usermod -aG plugdev $USER
# log out and back in after this

Check whether HackRF udev rules exist for your distro. If not, create them:

sudo nano /etc/udev/rules.d/53-hackrf.rules

Rule:

SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", MODE="0666"

Reload:

sudo udevadm control --reload-rules
sudo udevadm trigger

After that, hackrf_info works.

Driver detach and reattach noise

RTL tools print this during normal operation:

Detached kernel driver
...
Reattached kernel driver

The SDR tooling takes temporary ownership of the USB device. It becomes a problem when another service grabs the device at the same time, or when you switch tools quickly and the reattach doesn’t complete cleanly. Unplug and replug is a valid fix.

Current workflow

1. Quick band scan

Pick a known band, collect a short sample, inspect.

rtl_power -f 430M:440M:50k -i 1 -g 30 -e 60s ./rf_433_1min.csv

2. Trigger devices while logging

Press a remote, ring a doorbell, whatever you own and are allowed to test. Watch what shows up.

3. Passive logger

A script that samples a band, writes a CSV row with timestamp and strongest bins, and repeats for hours or days. The goal is trend visibility: activity spikes at these times, at these frequencies.

4. Long runs in screen

screen -S rfwatch
# run your loop / script
# detach: Ctrl+A then D
screen -r rfwatch

Lessons from the first two hours

• Antenna placement matters more than gain settings. Move it 30cm and signal becomes noise.
• Gain is not volume. Too much gain makes every bin look busy and kills your ability to compare runs.
• 433 MHz is crowded. Good for learning, bad for clean data.
• A CSV you can graph beats ten live waterfall sessions.
• Fix udev permissions before you need them, not during a session.

RTL-SDR vs HackRF

RTL-SDR: default always-on receiver. Cheap enough to leave plugged in and logging. Good for band surveys and learning.

HackRF One: used for broader coverage and lab work. TX stays off unless the environment is controlled and the use is legal.

What’s next

• A 24-hour monitor for 433 MHz, then other bands
• Lightweight analysis: top active frequencies, time-of-day patterns, spikes worth investigating
• Mapping RF fingerprints in the environment: gates, remotes, alarms, sensors. What’s constant vs what’s event-driven.

Legal

I’m monitoring what I’m allowed to monitor, on equipment I own, in environments where I have permission. RF gets murky fast if you treat it like network recon without thinking about it first.