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.

Disclaimer: The examples below are anonymised and aggregated across multiple engagements. The goal is to highlight recurring patterns, not embarrass any specific organisation.

Security Theatre: Field Notes from the Inside

The Scene

Most environments I assess are not wide open. They have firewalls, policies, and controls that look sensible on a slide deck.

The same weaknesses keep showing up anyway. Security gets implemented as a compliance checklist rather than an adversarial system.

That is security theatre: controls that exist, but fail under pressure.

It shows up in small things (a forgotten hyperlink), legacy things (Telnet still running), and complex things (multi-tenant routing edge cases that quietly break the idea of “internal”).

Most incidents do not start with a zero-day. They start with an assumption.

The Meaning

Security theatre is security that only works from one angle.

• It satisfies an audit requirement
• It meets a policy statement
• It was set up once and never re-validated
• It relies on “internal trust” as a boundary

It fails the moment an attacker does basic due diligence.

Real Security vs Theatre

A Simple Test

Rate each control against three questions:

1. Is it verified? Not configured, but tested.
2. Is it monitored? Will you know when it fails?
3. Is it owned? Is someone accountable for its health?

Two “no” answers means you do not have a control.

Field Notes

1. “Internal” RFC1918 Space Leaking Other People’s Infrastructure

On one client network, we found a large number of devices in the 172.30.x.x and 172.31.x.x ranges. Normal enough.

The exposed services were not normal:

• Cisco IOS devices presenting known vulnerabilities
• OpenSSH issues flagged, including severe exposure classes
• SNMP responding with default community strings (public)
• Telnet open in cleartext

When we pulled device information over SNMP, the fingerprints did not match the client’s environment. The devices looked like other organisations’ routers, visible from within this client’s own network.

Whether it was a provider-side forwarding mistake, a multi-tenant routing bleed, or a design choice nobody fully understood, the problem is the same:

“Internal” is a routing decision, not a security boundary.

A network can be “private” on paper while being multi-tenant in practice. Technically not the client’s fault. Still their problem.

The pessimistic outlook: unintended trust paths, lateral movement opportunities, messy incident response (“is that ours?” becomes a real question), and reputational fallout if the client network becomes a stepping stone into someone else’s infrastructure.

2. Monitoring Interfaces That Become Management Interfaces

SNMP is often justified as “monitoring only.”

In practice it provides device names, interfaces, routing hints, OS and platform fingerprinting, uptime, load, and depending on configuration, more. When SNMPv2c is exposed with default communities, “monitoring” becomes enumeration on demand.

The control exists (“we have monitoring”), but the threat model is absent (“monitoring endpoints are high-value targets”).

What to do instead:

• SNMPv3 with auth and privacy where possible
• Strict ACLs so only the monitoring system can reach SNMP
• Remove default communities, remove write communities unless there is a hard requirement
• Continuous checks for public/private drift

3. Telnet in 2026

Telnet still appears internally more often than people admit. Rarely a deliberate decision. More often a leftover: legacy device, a “temporary” troubleshooting session, vendor defaults, a project that ended but the port stayed open.

What to do:

• Disable Telnet everywhere, policy plus validation
• If legacy hardware makes that impossible, isolate it and treat it as hostile
• Enforce SSH and modern cipher suites for all management
• Log and alert on any Telnet session as a high-signal event

4. The Easiest Brand Hijack Is a Broken Hyperlink

One of the more sobering findings I have seen had no CVE attached.

A client website linked to their social media profiles. The X and Instagram links pointed to accounts that did not exist. We registered the usernames the website was implicitly endorsing.

Any visitor clicking those links landed on an attacker-controlled profile that looked official by association. I was, briefly, the client’s new social media manager.

The organisation likely had solid perimeter controls. Their public brand identity had an unguarded back door.

What to do:

• Treat web presence as an asset inventory: domains, handles, app store listings
• Reserve key usernames even on platforms you do not actively use
• Run a quarterly external exposure review with marketing and security together
• Add a brand protection checklist to release processes

5. Hidden SSIDs and Other Comforting Myths

I have assessed environments where the guest Wi-Fi was modern and well-configured (WPA3), additional SSIDs existed as “hidden,” and those SSIDs still covered public areas: roads, car parks, the perimeter.

Hidden SSIDs do not stop discovery. The tooling is trivial and takes minutes. They stop casual users from seeing the network in a dropdown list.

What to do:

• Remove unused SSIDs entirely
• Prefer WPA3-Enterprise (EAP) where feasible
• Segment wireless properly: guest is not corporate, corporate is not infrastructure
• Validate coverage from outside the perimeter

6. “Medium” Findings That Do Not Feel Medium

Scanner outputs create a predictable behaviour pattern. Critical gets attention, high gets scheduled, medium gets ignored, info gets laughed off.

Some medium findings describe classes of weakness that become severe with real-world conditions: SSH weaknesses that matter under MITM conditions, management interfaces with brute-force exposure, patch states that are “mostly fine” but leave a few critical paths open.

Severity is a starting hypothesis, not a verdict. Two mediums can combine into a critical.

Prioritise weaknesses that enable credential capture, management access, or trust boundary crossing regardless of how the scanner scored them.

7. Logs Exist, but Meaning Does Not

On the blue side, I often see logging enabled but not operationally useful.

Suricata is a good example. It can generate excellent visibility, but without a workflow it becomes noise. The questions that matter are: what are our top external destinations, which internal hosts talk to unusual places, and what changed since last week.

“We have monitoring” becomes a checkbox, and the logs do not get reviewed.

What to do:

• Build simple, repeatable queries that surface top talkers, new domains, and rare destinations
• Baseline normal behaviour and alert on deviations
• Assign ownership: someone reviews signals and acts on them

Why This Happens

Most security theatre comes from normal organisational pressure:

• Compliance is measurable; security is contextual
• Change control is painful, so legacy stays
• Ownership is fragmented, so controls drift
• Teams are stretched, so verification falls away
• Perimeters look strong, so internal trust grows by default

More tools will not fix this. Verification, ownership, and feedback loops will.

Breaking the Cycle

This week:

• Kill Telnet wherever it exists
• Remove default SNMP communities, lock SNMP behind ACLs
• Inventory and reserve public brand assets
• Delete unused SSIDs, validate coverage beyond the perimeter
• Review private ranges for routing weirdness and unintended reachability

The structural fix: a control is not done when it is configured. It is done when it is verified with adversarial thinking, monitored for failure, and owned with accountability.

If you cannot answer “who owns this control,” it is theatre waiting to fail.

The End

Security is not the number of controls you can list. It is the number that survive contact with an adversary.

If your “internal” network is only secure because everyone agrees to behave, that is not a network. It is a trust exercise.

Appendix: How Screwed Am I?

If any of these are true, you are looking at theatre:

• “It’s fine because it’s internal”
• “We enabled logging” (but nobody reviews it)
• “We use SNMP for monitoring” (but it’s v2c and broadly reachable)
• “It’s hidden” (SSIDs, panels, directories)
• “We patched most of it”
• “That’s only a medium”
• “We don’t know who owns it”

Hunt the assumptions, not just the CVEs.

Most environments aren’t completely unsecured. Firewalls are enabled. Logging exists. Alerts are configured. From the outside it looks fine, maybe even responsible.

Controls aren’t usually missing. They’re inactive.

In recent work I’ve seen environments where security features were technically enabled but effectively useless. Logs existed but nobody read them. Alerts fired and nobody came. Things broke and the outcome was the same either way.

An organisation’s security is only as strong as the people interacting with it. The tooling matters less than whether someone looks at it. The architecture diagram matters less than whether someone notices when something breaks.

Controls that exist, but don’t actually do anything.

What “On Paper” Actually Means

A control that exists on paper isn’t badly designed or poorly intentioned. It meets one or more of these conditions:

• Enabled, but not enforced
• Deployed, but not monitored
• Producing logs that nobody checks

Being enabled doesn’t make something active. Being deployed doesn’t mean anyone owns it.

This usually comes down to a preference for “set it and forget it” over “observe and react.” Once the checkbox is ticked, the control fades into the background, assumed to be working indefinitely. That assumption is where things go wrong.

Where Controls Drift

Detection Without Response

Detection systems promise visibility. Alerts come in, someone investigates, action is taken.

In practice it works for a while. Dashboards get checked. Alerts are acknowledged. Then the noise builds. False positives pile up. A day goes by without anyone looking, then two. Eventually nobody is sure who owns the dashboard anymore.

Alerts become background noise. Data is still being generated, but nobody acts on it. An alert that nobody investigates isn’t protection, it’s a log entry.

Authentication With Escape Hatches

Strong authentication controls get undermined by exceptions. Legacy devices that “don’t support it.” Applications that need compatibility modes. Temporary workarounds that quietly become permanent.

Then there’s the choice problem. Multiple authentication options enabled for convenience, some far weaker than others. The intention is resilience but the effect is dilution.

Attackers don’t try to break the strongest path. They use the weakest one you left open “just in case.”

Segmentation Without Isolation

Segmentation looks good in diagrams. Separate zones, clean boundaries, tidy rulesets.

In practice those boundaries collapse at shared services. DNS, authentication, file shares, and management interfaces punch holes through supposedly isolated segments. Rules get added to “make things work” and the isolation erodes quietly.

The network looks compartmentalised. When it matters, it behaves like a flat one.

Why This Keeps Happening

Operational load is real. Security gets treated as a deployment task rather than a continuous process. Once a control is installed and doesn’t cause immediate issues, it slides down the priority list. There’s always something more urgent.

Environments accumulate controls without accumulating engagement.

The Cost of Paper Security

The biggest risk isn’t failure. It’s false confidence.

Teams believe they’re protected because the tooling is there. Incidents take longer to detect. Root cause analysis gets harder. Attackers exploit the gaps between controls, not by breaking defences, but by walking through the parts nobody is watching.

Security Is Behaviour

A control only exists if it changes outcomes.

If nothing reacts when it fails, nothing is protected. If no one owns it, it doesn’t exist. If no human ever sees its output, it’s noise.

Fewer controls that are actively observed beat a long list that only looks good in a report.

I’ve always enjoyed tinkering with operating systems and finding ways they improve day-to-day life. I’m not a cloud hater. Cloud services are useful and I still use them. I self-host because it’s fun.

With most SaaS tools, you’re limited by design choices you had no part in. My biggest self-hosted system is a Plex machine. I watch what I want, how I want, for roughly the cost of electricity. There’s also been a serious learning component: networking, security, general IT practice. That alone has made it worth running.

Topology

Starting at the internet edge and working inward:

Router / Firewall I settled on OPNsense. It met and exceeded what I needed. The box runs intrusion detection, Unbound DNS, and a handful of other security-focused services.

Switching Traffic hits a 24-port unmanaged gigabit switch with SFP ports. Nothing exotic, but most ports are in use.

Flat Network The network is currently flat, so traffic flows directly to access points, servers, Raspberry Pis, NVR systems, gaming consoles, and everything else.

The topology is simple. The interesting part is what the devices are doing, not how complex the diagram looks.

Core Infrastructure

Alecto

Hardware

• Ryzen 7 1700X
• 1 TB NVMe
• 4 TB HDD
• GTX 1050 Ti

Nothing exotic, but it handles everything I need with around 85% idle time.

Software Ubuntu LTS as the host OS, Docker for everything else: media acquisition, media consumption, networking, local services, metrics, and automation.

Docker makes backing up and restoring critical services significantly easier, which is the main reason I keep everything containerised.

Services

Media Acquisition

The pipeline follows a simple request, acquire, process, library chain.

• Overseerr
• Prowlarr
• Sonarr / Radarr
• qBittorrent
• Deluge
• Unpackerr
• cross-seed

Prowlarr manages indexers. Private trackers have far less fake or malicious content than public ones, which matters later in the chain.

Sonarr and Radarr handle TV and movies. Quality profiles are simple: HD and 4K. That has covered everything so far. Both monitor RSS feeds from configured indexers and push matched torrents to the downloader automatically.

I run two download clients. qBittorrent handles the entire arr stack. Deluge handles manual downloads and non-media content. Dynamic save paths split movies and TV cleanly for Plex.

Unpackerr handles automatic extraction for downloads that arrive as archives. cross-seed finds identical or near-identical torrents across trackers and advertises that I already have the data, which improves speeds and availability for others.

The only recurring issue is Sonarr or Radarr occasionally grabbing a fake title. Aggressive regex-based filters have mostly resolved it.

Media Consumption

• Plex
• Tautulli
• Overseerr
• Homepage

Plex is the primary player. Mature, stable, available on every device, and accessible for non-technical users. I’ve tested Jellyfin and like it, but haven’t switched.

Tautulli gives visibility into Plex usage: playback activity, per-user bandwidth, transcoding load. That data makes decisions around limits and capacity easier.

Overseerr lets users request titles themselves rather than messaging me. Requests still require approval, but that takes seconds instead of a back-and-forth conversation.

Homepage is a single customisable dashboard with a high-level view of everything running. It doesn’t replace Zabbix or Grafana for monitoring, but it’s useful for day-to-day glancing.

Networking and VPN Containment

Torrent clients are routed through Gluetun, a dedicated VPN container running WireGuard. The downloaders have never touched my LAN directly and never see my public IP.

Gluetun runs in strict kill-switch mode. If the VPN drops, traffic stops. There’s no fallback to my home connection. Given the provider’s SLA, this hasn’t been an issue in practice.

No inbound ports need to be open, which reduces exposure further. Speed degradation from the VPN hasn’t been noticeable.

Observability

Prometheus, Node Exporter, cAdvisor, and Grafana cover system-level metrics: CPU load, memory usage, container behaviour. Critical alerts go to Telegram. I’m refining thresholds so only actionable issues send a notification.

Automation

Watchtower handles container updates on a schedule at 03:00. If an update breaks something, rolling back means redeploying from the same configuration paths. Docker’s stateless container model makes that straightforward.

Portainer handles anything that needs a UI.

Network Edge

OPNsense

OPNsense sits between the internet and all internal systems. UPnP is disabled. No device exposes itself automatically. Only explicitly required services are permitted outbound or inbound.

All traffic is statefully inspected. DNS is forced through Unbound. Suricata monitors inbound and outbound traffic for known malicious patterns. Devices can’t quietly phone home, bypass DNS filtering, or accept unsolicited inbound connections without generating an alert.

Services get published deliberately, not accidentally exposed.

Boreas

A Raspberry Pi running Nginx Proxy Manager and WireGuard. This started as a workaround for a previous router that lacked VPN support. After moving to OPNsense, the separation made enough sense to keep.

Boreas is my remote access point back into the LAN. Nginx Proxy Manager exposes Overseerr to friends and family outside the local network. Both services sit behind Cloudflare, primarily to obscure my real IP.

The throughput on the Pi is better than you’d expect for the hardware.

Chronos

A Tor middle relay running as a small contribution to online privacy. No exit node: the ISP complaints and CAPTCHA overhead aren’t worth it. A middle relay provides value without the operational noise. It’s low-maintenance and largely invisible once configured.

Failures and Lessons

In the past year, two things actually broke:

• Disks filled up from log spam. Entirely my fault. Log rotation is properly configured now.
• Incorrect or fake titles downloaded. Better filters and denied extension lists resolved most of it.

Beyond that, issues have been minor misconfigurations and occasional reboots.

What I’d Do Differently

I’d spread services across more hosts if I could go back. Some hardening measures were probably over-engineered, but I don’t regret that trade-off. Deploying the arr stack earlier would have saved time.

What’s Next

Hardware: managed switch, better access points, a more capable GPU for transcoding.

Monitoring: a consolidated Zabbix dashboard with proper alerting.

Networking: VLANs.

Self-hosted AI models aren’t on the list. Cloud tools cover what I need without the overhead.

Closing

Running this lab has mostly taught me patience. Getting multiple devices, containers, and services working together takes iteration. It’s improved my understanding of networking and containerised systems more than any course I’ve taken.

I keep running it because it’s fun and I learn from it. That’s enough reason.

I came across this cheap IPC camera on a local marketplace here in South Africa. The price was perfect to mess around with the device and potentially break it. The device cost around R300, or roughly $10.

My goal with this device was to go from zero to one hundred in terms of how I document findings, while also looking at every nook and cranny I could reasonably reach.

From my initial research into these no-name, internet-connected devices, they tend to compromise on both security and privacy.

From the outset, I want to make a few things clear. Within this post you will not find a tutorial on “how to hack”, nor will anything be blown out of proportion. This post is meant to be a reverse engineering and analysis exercise.

2. Initial Recon, Out of the Box Behaviour

To understand normal operating behaviour, the device needs to be used exactly as intended. This includes:

• Reading the manual it came with
• Plugging it in and getting a feel for boot times
• Watching for any boot messages
• Using the mobile app and understanding its dependency
• Noting early red flags such as cloud-only usage or lack of a local UI

With that methodology in mind, we start at the top.

The manual was fairly well written, with no obvious grammar or spelling issues. The app required for viewing and control is called Tris Home. It appears to be a generic IPC viewer backed by cloud infrastructure.

When powered on, the camera announces “device booting” via the onboard speaker. The app then pops up saying a nearby camera has been discovered. After adoption, another message plays: “device added to Wi-Fi”.

Initially there were no major red flags, but a few things stood out:

• Account creation immediately triggers cloud storage upsells
• The app appears to be the only supported interface
• The app feels generic, capable of onboarding many brands

3. Network Analysis, Watching It Talk

This is where things get interesting.

We set up a small lab using a spare Raspberry Pi and a simple script to create a MITM access point. The camera connects to the internet as normal, but all traffic passes through us.

Setting up a controlled network

The script configures hostapd and dnsmasq.

hostapd puts the Wi-Fi adapter into AP mode, creating a hotspot with an SSID and password of our choosing. dnsmasq handles DHCP and IP assignment.

This gives us a clean interface to monitor with tools like Wireshark, in this case wlan0.

For anyone being extra cautious, the Pi can be placed inside a dedicated VLAN, isolated from the rest of the network.

Tools used in the controlled network

• tcpdump
  CLI packet capture for raw traffic inspection.

• mitmproxy
  Active interception and inspection of higher-level traffic.

• Custom tooling
  Simple scripts to spoof or sinkhole unchecked HTTP services.

Observations

Before analysing anything meaningful, we verify the basics:

• The access point is working
• Devices receive IP addresses
• The camera has outbound connectivity
• Camera functionality remains intact

Once confirmed, the workflow is simple:

1. Start the access point
2. Start tcpdump
3. Start mitmproxy
4. Power on the camera

mitmproxy immediately surfaced interesting behaviour:

On boot, the camera contacts multiple external hosts and establishes persistent connections very early in the startup process.

Interesting Protocols Observed on the IPC Camera

During analysis, a few security related protocols stood out. None of these were theoretical. All were observed through traffic capture, MITM.

1. Proprietary TCP Control Channel (Port 34567)

This port appeared consistently.

• Proprietary binary protocol on TCP port 34567
• Used for registration, keep-alives, and remote control
• Common in low-cost Chinese IPC devices
• Historically associated with weak or static authentication

This effectively functions as the main control plane.

2. Plain HTTP (No TLS)

Although the device generated HTTP traffic, it did not expose a traditional local web interface.

Observed behaviour included:

• Backend-style HTTP requests
• Configuration and firmware-related endpoints
• Cloud communication over plaintext HTTP

Important clarifications:

• No browser-accessible admin interface
• No local login or management panel
• Endpoints were machine-to-machine, not user-facing

Key observations:

• No HTTPS by default
• No certificate validation or pinning
• Highly verbose during boot

This made the device susceptible to MITM.

3. Cloud Update and Configuration Endpoints

The device attempted to reach multiple cloud endpoints:

• Hardcoded IP addresses and domains
• Cloud-hosted infrastructure, including large public providers
• Domains such as *.secu100.net

Some endpoints were referenced directly by IP, indicating a weak update trust model.

4. Persistent Cloud Tunnel Behaviour

Rather than a single protocol, this was a consistent pattern:

• Device boots
• Immediately phones home
• Registers with cloud services
• Maintains long-lived TCP sessions

This enables NAT traversal but creates strong cloud dependency and reduced local-only usability.

Collectively, the device relies on:

• Proprietary TCP control traffic
• Unencrypted HTTP for updates and configuration
• Persistent outbound connections
• Cloud-first architecture with weak trust boundaries

4. Physical Teardown, Opening the Camera

I usually open devices to see what makes them tick. This camera is reasonably well built for mass production, but it does not resist a standard Phillips screwdriver.

This is not a full iFixit teardown, just a high-level inspection.

Notable components include:

• Main board
• LED and IR module
• Motors
• Enclosure components
• Antennas

A closer look at the PCB shows a Goke GK7210 SoC, a common vision processing chip used in low-cost cameras.

The flash ROM chip acts as the device’s primary storage. The Wi-Fi module is external to the SoC. Interestingly, only one antenna cable was actually connected. The second was present but unused, likely for marketing reasons.

5. Debug Interfaces, UART

Test pads were present on the board, outlined below.

These UART pads are commonly used during development and manufacturing and almost always remain on final products.

UART output was enabled and provided full boot logs, but all inbound input was ignored.

This strongly suggests a vendor-modified U-Boot configuration where interactive access is intentionally disabled, rather than a wiring or baud-rate issue.

6. Firmware Extraction and Analysis

With UART offering limited access, firmware extraction was required.

The flash chip was removed and dumped using a flash programmer. Multiple dumps were taken and hashed to ensure consistency, with a golden copy preserved.

Using binwalk, partitions and offsets were identified.

One notable finding was the presence of a root password hash in /etc/passwd, which cracked quickly using a common wordlist.

7. Cloud Dependency and Update Mechanism

The firmware and observed network behaviour make it clear that this device is heavily cloud-dependent.

On boot, the camera attempts to contact multiple vendor-controlled endpoints for registration, configuration, and update checks. Several of these endpoints are hardcoded into the primary application binary, rather than being dynamically resolved or user-configurable.

Firmware updates appear to follow a module-based OTA model. The device requests a list of available modules, then selectively downloads update payloads from cloud infrastructure. While this approach allows incremental updates, it also centralises trust entirely in external services.

There is no user-visible indication of signature verification, update provenance, or rollback capability. From an owner’s perspective, updates are opaque and automatic.

This raises several long-term concerns:

• If update servers go offline, functionality may degrade
• If domains expire or infrastructure is shut down, updates fail silently
• If the vendor disappears, cloud-dependent features may stop working entirely

Local-only usage appears limited. While RTSP streaming is present, configuration, management, and updates are clearly designed around continuous cloud connectivity.

This is less about immediate exploitation and more about lifecycle and supply-chain risk.

8. Security Observations (Not Sensational)

Objectively Weak Areas

• Unauthenticated network services exposed during normal operation
• Plaintext HTTP traffic for configuration and update-related requests
• Firmware built without obvious hardening, with debug strings present

Bad Design vs Exploitable Issues

Poor design choices include implicit trust in the local network, cloud-first assumptions, and opaque update mechanisms.

Potentially exploitable surfaces exist, but no active exploitation was attempted or demonstrated.

Attack Surface Summary

• Network: multiple open TCP ports, proprietary protocols, persistent outbound connections
• Physical: exposed UART pads with output enabled
• Firmware: monolithic image with cloud endpoint references

What Was Not Tested

No exploit development, fuzzing, credential attacks, firmware modification, or cloud impersonation was performed.

All observations were made through passive analysis, controlled network interception, and non-invasive hardware inspection.

9. Practical Takeaways

For home users, network isolation, firewalling, and local-only usage where possible significantly reduce exposure.

For researchers, cheap IoT devices remain excellent learning platforms, exposing real-world constraints and design trade-offs.

For vendors, basic improvements around authentication, TLS usage, and transparency would meaningfully raise the security baseline.

10. Closing, Why This Matters

Cheap IP cameras are not edge cases. They are everywhere, deployed on private networks and rarely revisited after installation.

Most users will never inspect firmware, observe network behaviour, or question update mechanisms. That gap between deployment and understanding is where hardware security still matters.

This research did not uncover a dramatic exploit, and that is the point. Security issues are often rooted in assumptions, not elite attackers.

Hardware hacking remains one of the few disciplines that cuts across firmware, silicon, network, and reality.

What’s Next

This analysis focused on observability rather than exploitation.

Follow-up work will look at:

• RTSP behaviour and access control
• Custom protocol reverse engineering
• Firmware update mechanics in more detail
• Cloud dependency and failure modes

That will form the basis of Part 2.

Not to sensationalise, but to understand.

Most of my time is spent breaking things apart , networks, embedded devices, cloud services, and poorly thought out assumptions , to understand how they fail, how they’re abused, and how they can be made better. I’m especially interested in areas where disciplines overlap like where hardware meets software, firmware meets networking, and theory meets reality.

Professionally, my background is rooted in offensive security, infrastructure, and research. I hold multiple industry certifications and spend a lot of time building internal tools, monitoring pipelines, and attack simulations rather than just running point-and-shoot tests. If something looks like a black box, I usually want to open it.

Outside of pure cybersecurity, I’m deeply hands-on. I tinker with electronics, reverse firmware, poke at undocumented protocols, and run an over-engineered home lab that probably exists more for curiosity than necessity. I enjoy projects that start simple and slowly spiral into “this is more complicated than it needs to be” , usually in a good way.

This blog exists as a place to document that process.

You’ll find write-ups on:

• Real-world security research and investigations
• Hardware and firmware analysis
• Network monitoring, telemetry, and weird traffic
• Tools I build to solve problems I couldn’t find good answers for
• Lessons learned the hard way

I’m not here to sell hype, shortcuts, or miracle tools. I care about understanding systems properly, sharing what works (and what doesn’t), and leaving things better documented than I found them.

If you’re curious, methodical, and comfortable sitting with complexity for a while, you’ll probably feel at home here.

Most of my time is spent breaking things apart — networks, embedded devices, cloud services, and poorly thought-out assumptions — to understand how they fail, how they’re abused, and how they can be made better. I’m especially interested in areas where disciplines overlap: where hardware meets software, firmware meets networking, and theory meets reality.

Professionally, my background is rooted in offensive security, infrastructure, and research. I hold multiple industry certifications and spend a lot of time building internal tools, monitoring pipelines, and attack simulations rather than just running point-and-shoot tests. If something looks like a black box, I usually want to open it.

Outside of pure cybersecurity, I’m deeply hands-on. I tinker with electronics, reverse firmware, poke at undocumented protocols, and run an over-engineered home lab that probably exists more for curiosity than necessity.

This blog documents that process: security research, hardware and firmware analysis, network monitoring, tooling, and lessons learned the hard way. If you’re curious, methodical, and comfortable sitting with complexity for a while, you’ll probably feel at home here.

You can find me on X / Twitter and LinkedIn.