Bye Bye Digital Ocean

I’ve been running Nextcloud on a DigitalOcean droplet for a while. It works fine, but it costs money every month for something that’s essentially sitting idle most of the time — a personal file sync server with one user doesn’t need a cloud VM. A Raspberry Pi 5 sitting on my desk does the same job for free.

This post covers the full migration: tearing down the DO setup, getting Nextcloud running locally on the Pi 5, and setting up Tailscale so I can still reach it remotely without exposing anything to the public internet.

Part 1 covered the hardware assembly. The Pi 5 was in its case, the Alfa AWUS036ACM had arrived, and I had a VK-172 GPS dongle ready to go. This part covers getting the software stack operational and taking the whole thing out for its first real session.

Software Stack

The OS is Raspberry Pi OS Lite (64-bit, headless). No desktop — there’s no need for one, and it just adds overhead and attack surface. Kismet runs as a service and exposes a web UI on port 2501, which is enough.

For a while now I’ve wanted a proper portable wardriving setup. Not just a laptop. I want a self-contained, pocketable device that I can throw in a bag and run headlessly in the field. After moving away from the Pwnagotchi approach (it is very neat but the features are not as extensive as Kismet), I decided to build something more capable around a Raspberry Pi 5.

This is part one: getting the hardware assembled and ready. The full stack isn’t operational just yet. I’m still waiting on the Alfa AWUS036ACM WiFi adapter to ship, but the foundation is built.

Recon

Starting with a full port scan:

1
2
3
4
5
6

nmap -sV -p- 10.82.169.159

PORT    STATE  SERVICE VERSION
22/tcp  closed ssh
80/tcp  open   http
443/tcp open   https

The ports initially showed as closed because the machine was still booting. Worth remembering if results look wrong early on. Just wait and re-scan.

I’ve been warwalking around London with my Pwnagotchi (named Bootsy) and ended up with a directory full of .pcap files and no clean way to visualise what I’d actually captured. This post documents how I built a single-script tool to parse those captures and generate a self-contained HTML dashboard.

The Problem

Pwnagotchi stores captured handshakes as individual .pcap files, named in a loosely consistent format:

1
2
3

SSID_aabbccddeeff.pcap
HASH_SSID_aabbccddeeff.pcap
HASH_aabbccddeeff.pcap

The BSSID is always the last underscore-separated segment — a 12-character hex string without colons. SSIDs appear before it, sometimes prefixed with what looks like a session hash. There’s no single canonical format, which meant any parsing logic had to handle all three variants.

My Pi-hole had developed an annoying habit as of the last couple of weeks. The web UI would go unreachable, FTL would silently die, and DHCP would stop assigning addresses. The only fix I had was unplugging and replugging the device. Not ideal for something that sits in the middle of your network, especially when you live with other people.

This post covers how I diagnosed the issue and hardened the setup so that transient failures recover automatically rather than taking down the network.

If you dual boot Linux and Windows and share Bluetooth devices between them, you’ve probably hit this annoying issue: the speakers connect fine on one OS, and then after switching, they refuse to pair on the other.

When you pair a Bluetooth device, a link key is generated and stored on both the host and the device. The problem is that both Windows and Linux see the same physical Bluetooth adapter — same MAC address — but they don’t share their key stores. So when you pair on Linux, it writes a new key to the device. Boot into Windows, and Windows has a stale key that no longer matches. Pair on Windows, and now Linux is the one with the stale key.

This weekend I set up a permanent LoRa mesh network node on my windowsill overlooking Chelsea. Here’s what I learned, what worked, and what didn’t…

I decided to do this because of the increase in privacy concerns regarding messaging apps like Discord, etc. It seemed like as good a time as any to set this up, and I had been considering this for a long time.

Meshtastic?

Meshtastic is an open-source project that runs on cheap LoRa radio hardware and lets devices form a decentralised mesh network. That means no internet, no cellular, and no central infrastructure. :p

Recon

Starting with an nmap scan:

Three ports exposed. SSH on 22, and more interestingly, Apache Tomcat 8.5.5 on 8080 with the AJP connector exposed on 8009. AJP was new to me, so I looked into it.

Last night I developed some custom firmware for the ESP32 WROOM-32 that demonstrates captive portal attacks. This serves as both an educational tool and a practical demonstration of why users should be cautious when connecting to public WiFi networks.

Disclaimer: This tool is designed exclusively for authorized security testing and educational purposes. All testing was conducted on equipment I own in controlled environments.

What Is a Captive Portal Attack?

Captive portals are the login pages you see when connecting to public WiFi at coffee shops, hotels, or airports. An evil portal attack exploits this familiar user experience by:

Project Date: February 8, 2026
Tools Used: Cisco Packet Tracer
Difficulty: Intermediate

I designed and configured a small office network for a fictional company using enterprise networking concepts. The network implements VLAN segmentation to separate different departments, with centralized routing to enable controlled communication between them.

The Challenge

Modern networks need to balance two competing requirements:

• Security: Different departments shouldn’t all share the same broadcast domain
• Connectivity: Users still need to communicate across departments when necessary

The solution are VLANs (Virtual Local Area Networks) combined with inter-VLAN routing.

Background

I set my ICS/SCADA honeypot (Conpot) up mainly to try and analyze/monitor attacks on industrial systems (this one poses as a PLC for an HVAC system), however the majority of the attempts I’ve noticed have been opportunistic web-based attacks targeting the associated page on port 80.

Recently, I’ve noticed some similar looking attacks coming from Asia, both trying to connect to a C2 server.

Log Analysis

Here is an example of one of the logs I captured:

Attack Summary

On January 28, 2026 at 21:01:11 UTC, IP address 60[.]19[.]220[.]0 attempted to exploit my ICS honeypot with CVE-2017-17215, a remote code execution vulnerability in Huawei HG532 routers. The attack targeted /boaform/admin/formLogin with default credentials (username=user&psd=user) via HTTP/1.0.

The IP has two recent reports on AbuseIPDB, indicating active malicious scanning.

CVE-2017-17215

CVE-2017-17215 is a remote code execution flaw in Huawei HG532 home gateways discovered in November 2017. The vulnerability exists in the router’s UPnP implementation, where the TR-064 protocol (designed for local network configuration) was exposed to the WAN through port 37215¹.

Conpot Honeypot: First Day Attack Analysis

Within the first 6 hours of operation, my Conpot ICS honeypot (emulating a Siemens S7-1200 PLC) attracted 40+ distinct attack sessions from 30+ unique IP addresses across multiple continents. The attacks ranged from automated scanning to targeted industrial protocol exploitation, including the first documented S7comm diagnostic probe and a sustained Next.js remote code execution campaign.

This post analyzes the attack patterns observed, identifies gaps in the honeypot configuration, and extracts actionable threat intelligence for ICS security research.

The Problem with Default Templates

Conpot’s default template emulates an S7-200 PLC with whimsical configuration values clearly designed for demonstration purposes rather than realism. Examining the default template.xml reveals:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<entity name="unit">S7-200</entity>
<key name="FacilityName">
    <value type="value">"Mouser Factory"</value>
</key>
<key name="SystemName">
    <value type="value">"Technodrome"</value>
</key>
<key name="sysLocation">
    <value type="value">"Venus"</value>
</key>

While functional for basic honeypot deployment, these values present several issues for research purposes:

As part of my MSc research in Information Security at Royal Holloway, University of London, I’ve been investigating the threat landscape facing industrial control systems (ICS) and SCADA infrastructure. One of the most effective ways to understand attacker behavior in this space is through honeypot deployment; specifically, using Conpot to emulate vulnerable industrial systems.

This post documents my process of deploying a production ICS honeypot on DigitalOcean, the technical considerations involved, and some initial observations from the deployment.

Telnet, Shodan, and Claude

With the advent of these extremely powerful CLI coding agents, I decided to test out and see how well something like Claude performs. To do so, I used a fake Telnet server.

When trying it out, the first issue I ran into was that the connection immediately dropped. Claude was able to connect without issue, but since telnet expects continuous real-time reponses from the client, it drops the connection due to Claude not being able to do that.