Labs, lessons, and things I’m thinking about.

Ransomware Containment Test Lab (Safe WannaCry-Inspired Simulation) — SMB/445 + DFIR Walkthrough

Post #9 · December 2025 · DFIR / Home Lab

Lab environment

I ran this on Proxmox with multiple VLANs to prove segmentation and containment decisions using FortiGate verification (sessions/logs/debug tools).

• VLAN10 USERS — 192.168.10.0/24 (victim workstation + Kali observer)
• VLAN20 SERVERS — 192.168.20.0/24 (file server / SMB share target)
• VLAN30 QUARANTINE — 192.168.30.0/24 (isolation network)
• (Optional) VLAN40 DMZ — 192.168.40.0/24 (honeypot / extra telemetry)

FortiGate containment baseline (block SMB lateral movement)

The primary control tested was a default deny for SMB (TCP/445) from USERS → SERVERS. This reduces a common ransomware lateral movement path (file shares, admin shares, and “server hunting” over SMB).

Configure the deny policy (FortiGate CLI)

config firewall policy
    edit 10
        set name "Deny-SMB-Users-to-Servers"
        set srcintf "VLAN10"
        set dstintf "VLAN20"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "SMB"          # TCP/445
        set schedule "always"
        set logtraffic all
    next
end

Verify enforcement (sessions + debug flow)

Instead of relying on ad-hoc session commands, I verified SMB blocking using FortiOS session-table filters and debug flow output.

1) Session-table check (expected: no established SMB sessions)

diagnose sys session filter clear
diagnose sys session filter dport 445
diagnose sys session list

2) Real-time proof (debug flow)

diagnose debug reset
diagnose debug flow filter clear
diagnose debug console timestamp enable
diagnose debug flow show console enable

diagnose debug flow filter addr 192.168.10.10
diagnose debug flow filter port 445

diagnose debug flow trace start 50
diagnose debug enable

# (trigger an SMB attempt now)

diagnose debug disable
diagnose debug reset

Optional quick validation (packet sniffer)

diagnose sniffer packet any "host 192.168.20.10 and port 445" 4 0 a

Safe simulation (ransomware-like behavior)

Rather than running live malware, I used a harmless simulator to generate measurable artifacts and network telemetry:

• Creates safe, non-destructive .encrypted copies of test files
• Generates bursty file I/O patterns for timeline review
• Attempts an SMB access to generate blocked telemetry on FortiGate

Simulator script (PowerShell)

# RansomwareSimulator.ps1 (safe simulator)
$testPath = "C:\Users\Public\TestFiles"
$share    = "\\192.168.20.10\share"   # adjust to your lab share

# 1) Generate SMB telemetry (safe): attempt to access the share
try {
    Get-ChildItem -Path $share -ErrorAction Stop | Out-Null
    Write-Host "SMB access succeeded (unexpected if deny policy is active)."
} catch {
    Write-Host "SMB access failed/blocked (expected in this lab)."
}

# 2) Generate “encryption-like” artifacts (safe): copy files to *.encrypted
$testFiles = Get-ChildItem -Path $testPath -File -ErrorAction Stop
foreach ($file in $testFiles) {
    $encryptedFile = "$($file.DirectoryName)\$($file.Name).encrypted"
    Copy-Item -Path $file.FullName -Destination $encryptedFile -Force
    Start-Sleep -Milliseconds 100
    Write-Host "Encrypted (simulated): $($file.Name)"
}

Evidence acquisition

I acquired evidence and analyzed it on a separate analysis VM (never analyze on the “infected” box). Since the victim was a VM, disk acquisition was done in a VM-centric way (snapshot/export/clone) and then hashed.

• Preserve state (power off or snapshot)
• Export/clone disk to an analysis location
• Hash artifacts (SHA-256) and document values

Example hash step (analysis VM)

sha256sum /mnt/analysis/victim_disk.img

Memory capture (Windows)

For a Windows victim, I used a Windows memory acquisition tool (e.g., WinPmem/DumpIt or equivalent) and then hashed the resulting dump.

Get-FileHash -Algorithm SHA256 C:\memory_dump.raw

Disk forensics (Autopsy)

Autopsy was used via the GUI workflow:

• Create a case on the analysis VM
• Add the acquired disk image
• Run ingest modules
• Use Timeline to identify bursty file activity
• Keyword search for .encrypted to find simulator artifacts

Memory forensics (Volatility)

Volatility was used to identify suspicious execution context (process list + command line) and to review network artifacts where supported.

volatility -f C:\memory_dump.raw windows.pslist
volatility -f C:\memory_dump.raw windows.cmdline
volatility -f C:\memory_dump.raw windows.netstat

Quarantine: containment that’s actually real

A firewall policy doesn’t “move” a host to another VLAN. To quarantine a workstation in a lab, use one of these realistic methods:

• Option A (Proxmox): change the VM NIC VLAN tag from VLAN10 → VLAN30, then renew IP/reboot as needed.
• Option B (Switchport): reassign the switchport to the quarantine VLAN.
• Option C (FortiGate-only): “logical quarantine” by policy—block east/west and only allow remediation/forensics destinations.

What I learned

• Segmentation is a force multiplier: default SMB deny between USERS and SERVERS reduces blast radius fast.
• Verification matters: session filters + debug flow/sniffer provide defensible proof of enforcement.
• DFIR is evidence discipline: acquire, hash, and analyze on a separate system.
• Safe simulations still teach real skills: predictable artifacts + real telemetry = repeatable practice.

References I used for context

• Microsoft MS17-010 bulletin
• CISA advisory / indicators for WannaCry
• MITRE ATT&CK: T1486 (Data Encrypted for Impact)
• DFIR walkthroughs framing Autopsy + Volatility workflows

Building and Testing a Honeypot with FortiGate Firewall

Post #8 · October 2025

As part of my cybersecurity research and hands-on network security projects, I built and tested a honeypot using a FortiGate firewall. The goal was to simulate a vulnerable system that could attract and log unauthorized access attempts — without exposing my internal network.

Project overview

• Objective: Deploy a honeypot behind a FortiGate firewall to simulate a vulnerable host.
• Honeypot: Cowrie (SSH/Telnet).
• Environment: FortiGate 80F (FortiOS 7.6), Ubuntu Server 22.04 (Cowrie), Kali Linux (internal testing).

Setup process

Step 1: Deploy the honeypot (Cowrie)

Cowrie was installed on an Ubuntu VM with IP 192.168.100.10. Installation steps:

Step 2: Configure a FortiGate Virtual IP (VIP)

I mapped a public-facing IP to the honeypot’s internal IP:

Step 3: Allow external access via a firewall policy

Testing the honeypot

From my Kali Linux VM (192.168.100.25), I attempted to SSH into the honeypot VIP:

Cowrie captured and logged the attempt and created a TTY log for later review:

Monitoring with FortiGate

To monitor live sessions in the FortiGate CLI:

To ensure traffic logging was enabled:

From there, I reviewed connection attempts in FortiView and exported logs to FortiAnalyzer for correlation and longer-term analysis.

Outcome

The honeypot successfully attracted SSH probes and basic scans. All actions were recorded without endangering the internal network, and I validated end-to-end visibility from inbound policy hits to honeypot-level command logging.

Final thoughts

This project sharpened my FortiGate CLI skills and gave me practical experience with threat emulation, packet logging, and network deception techniques. It’s a strong addition to my cybersecurity lab portfolio — and a foundation I can extend with FortiAnalyzer/FortiSIEM integrations over time.

UHI sales increase: learning to sell by thinking like a customer

Post #1 · Feb 2020 - May 2022 · Story

Walking into sales with no playbook

When I first joined United Hose Inc., I didn’t come from a traditional sales background. No polished script, no massive Rolodex, no secret list of “accounts ready to buy.” I did what everyone around me seemed to be doing — cold calls, email blasts, following up on stale leads — and it felt like shouting into the void.

The pressure was real. Numbers needed to move, and “try harder” wasn’t a strategy. I knew if I just kept doing the same surface-level outreach, I’d get the same surface-level results.

Acting like a buyer to understand the game

Instead of only acting like a salesperson, I started thinking like a customer. If I were running a shop, what would I actually care about? Price, sure — but also who has stock today, who can deliver when things break, and who understands my world enough not to waste my time.

So I started calling the people who were selling to my customers and prospects every day. I asked the kinds of questions a real buyer would ask: what’s on the shelf, what’s moving, and what it costs out the door. Over time, those calls turned into something valuable: a living database of what the market really looked like — not just what a spreadsheet said it should look like.

Turning messy notes into a quiet advantage

I started tracking everything. If a competitor was consistently pricing a certain hose at one level, and I knew our cost structure and service was strong, I could be intentional about where to undercut, where to match, and where to walk away.

This wasn’t about racing to the bottom; it was about being precise. Instead of “we’re cheaper,” I could have targeted conversations: “On these five SKUs, I know I can save you money without sacrificing quality or lead time. Let’s talk about those first.”

What that experience taught me

That role at UHI was my first real sales job, and watching the numbers move because of a system I built gave me a huge confidence boost. It showed me that I didn’t need to be the loudest person in the room; I just needed to be the most curious about how the system actually worked.

Eventually, that mindset pulled me toward tech. I joined a startup focused on helping manufacturers turn downtime into something they could actually measure and plan around — not just complain about after the fact. The same pattern showed up again:

• Understand the real problem beneath the surface metrics.
• Collect better data than anyone else in the room has.
• Translate that data into decisions people feel confident making.

Looking back, UHI was where I learned that data, curiosity, and empathy for the customer can beat a polished script. That lesson still shows up in how I approach networking, security, and every “this is how we’ve always done it” conversation I run into.

Setting up Proxmox on my home server: failures, fixes, and first wins

Post #4 · August 2025 · Home Lab / Virtualization

The goal

I wanted to bring an older server back to life as a small home lab: a hypervisor I could trust, a place to run security VMs (Kali, Ubuntu), and enough flexibility to experiment without constantly rebuilding the base OS. The end state was simple: clean virtualization, predictable networking, and a workflow that feels “lab-ready.”

Step 1: I tried ESXi first (and learned why people call it “enterprise”)

My first attempt was VMware ESXi. I hit friction immediately: I grabbed a ZIP instead of a bootable ISO, Rufus didn’t like it, and the “right” way forward involved building a custom installer image. ESXi is powerful — but for a quick home-lab build, the workflow felt heavier than I needed.

Step 2: Pivot to Proxmox VE (much smoother)

Proxmox was the opposite experience: download the ISO, make a bootable USB, install, and you’re online. The high-level steps were:

• Download: Proxmox VE ISO (from the official site).
• Create USB: Rufus to write the ISO to a USB drive.
• Boot: Select USB at boot (commonly F11 or Del).
• Install: Set hostname, admin email, password, and management networking.

Networking gotcha: the “.255” mistake

During install I initially configured the host IP as 10.0.0.255. That failed because .255 is typically reserved as the broadcast address in a /24 network. I corrected it to: 10.0.0.10/24, with gateway 10.0.0.1 and DNS set to a public resolver.

Logging in: where it “clicked”

After reboot, the Proxmox web UI came up on port 8006: https://<server-ip>:8006. The default login pattern is root with the Linux PAM realm. The interface is straightforward — and that’s where the build stopped feeling fragile and started feeling operational.

My first VM: Kali Linux

Once the host was stable, I uploaded the Kali ISO to the Proxmox storage and created a VM with a modest baseline:

• CPU: 2 vCPUs
• Memory: 4 GB
• Disk: 32 GB
• Boot: CD-ROM first (Kali ISO)

During install, GRUB asked for a target device; selecting the primary disk (/dev/sda) completed the setup cleanly.

Performance tuning: the VM stopped feeling “heavy”

The first boot was usable but sluggish. A few Proxmox-side changes made a noticeable difference:

• Enable QEMU Guest Agent (better integration and reporting).
• Use VirtIO for disk and network where possible.
• Switch display to Spice and use a modern machine type (e.g., q35).

Issues I hit (and how I resolved them)

Two issues were common “first-lab” pain: package signing keys and third-party repos. For an apt GPG key error like: NO_PUBKEY ED65462EC8D5E4C5, I imported the missing key from a keyserver.

For Docker installs, I added Docker’s official repository to avoid outdated packages:

What I learned

• Proxmox is home-lab friendly without sacrificing serious capability.
• Networking details matter (CIDR, gateway, and reserved addresses).
• Error messages are signals — treat them like a checklist, not a dead end.
• Storage hygiene is easy in Proxmox: VMs and disks can be reclaimed cleanly from the UI.

Where I am now

Proxmox is stable, Kali is running with a responsive GUI, and the next step is adding an Ubuntu VM to host local LLM experiments and Docker apps. The bigger win is that I now have a repeatable process: I can build, break, fix, and rebuild quickly — which is exactly what a good lab is for.

Local LLMs with Runpod & LM Studio: Easier Than I Expected

Post #2 · October 2025 · AI / Lab

Why I Cared About Local Models (And Why You Should Too)

AI is everywhere, but most of it lives behind someone else’s API key. That’s fine for some use cases, but as a security-minded person—and occasionally a CISO—I wanted to see what it felt like to run models closer to home: either on my own machine or on infrastructure I could trust.

I assumed it would be hard. “Local LLMs?” I thought. “That’ll involve compiling code, wrestling with Docker, and probably a few late-night debugging sessions.” But when I started experimenting, I was surprised to find that setting up a local model—or renting a cloud GPU—was often easier than dealing with some so-called “productivity agents” that promise magic but require five browser extensions just to install.

LM Studio: The “VS Code for Local LLMs”

LM Studio felt like the “VS Code for local LLMs.” I installed it, opened it up, and was greeted with a catalog of models. No Docker compose files, no YAML forests—just a search bar and a download button.

My first test? Mistral 7B. I searched for it, hit download, and within minutes, I was chatting with the model locally. No latency, no data leaving my machine. Next, I tried Llama 2 (13B parameters). The process was the same: search, download, and wait for the initial setup (which took about 5 minutes on my M2 MacBook Pro).

Once a model was downloaded, I could:

• Chat with it directly inside the app—no API keys, no remote dependencies.
• Expose it as a local API endpoint to integrate it into my workflows (e.g., for note-taking or analysis tools).
• Switch between models without rebuilding anything—just a click and wait.

For lightweight tasks like note-taking or quick analysis, this was more than enough. But I also tested image generation with Stable Diffusion 2.1. On my laptop, generating a 512x512 image took ~20 seconds, and my fan sounded like it was about to take off.

Runpod: Renting a GPU for Heavy Lifting

The other side of the experiment was Runpod. I wanted to see if renting a cloud GPU could handle heavier workloads—like generating high-res images or running larger LLMs—without my laptop overheating.

The process was straightforward:

1. Pick a template (e.g., “Stable Diffusion” or “Hugging Face Inference”).
2. Choose a GPU. I started with an A10G ($1.20/hour) for lighter tasks, then upgraded to an A6000 ($4.80/hour) when I needed more power.
3. Launch the pod and SSH in within minutes. No waiting for Docker containers to build—just a terminal session ready to go.

Once the pod was up, I could run containers, host APIs, or even train models. The best part? No need to buy a GPU for weekend experiments—I could spin it down when done and only pay for the time I used.

Testing Performance: Speed, Privacy, and Control

I put both platforms through their paces to see how they stacked up:

• Text Generation:
  • LM Studio: Blazing fast for local use, but latency increased with larger models. Llama 2 (13B) took ~5 seconds per response on my M2 MacBook Pro.
  • Runpod: Matched or beat LM Studio’s speed when using a GPU (e.g., ~3 seconds per response on an A6000).
• Image Generation:
  • LM Studio: Generating a 512x512 image with Stable Diffusion took ~20 seconds, and my laptop fan sounded like it was about to take off.
  • Runpod (A6000): Dropped to ~8 seconds—no fan noise, just pure performance.
• Privacy and Control:
  • LM Studio: Running entirely locally meant no data ever left my machine. Perfect for sensitive tasks like note-taking or internal analysis.
  • Runpod: While it’s in the cloud, I could SSH into the pod and verify what was running. No black-box APIs—just a remote machine I controlled.

So… Which One “Wins”?

For me, it’s not either/or:

• LM Studio wins when I want fast, simple, local experiments where privacy and convenience matter. It’s perfect for:
  • Note-taking or quick analysis without sending data to a third party.
  • Offline tinkering—no internet required, no API rate limits.
  • Experimenting with different models without rebuilding my setup.
• Runpod wins when I want more horsepower on demand, especially for heavier workloads or when I don’t want my laptop fans sounding like a jet engine. It’s ideal for:
  • Image generation or video work (e.g., Stable Diffusion at 1024x1024 resolution).
  • Running larger models (e.g., Mixtral 8x7B) without maxing out my local GPU.
  • Avoiding the cost of buying a GPU I’ll only use on weekends.

The funny part is that in both cases, getting something useful running was often easier than dealing with some “productivity agents” that promise magic but require five browser extensions and a small ceremony to install. I tried one recently—just to see—and the installation process involved more steps than setting up LM Studio or Runpod.

Why This Matters for CISOs (And Security-Minded Folks)

As someone who’s spent time in security—especially as a CISO—I care about control, visibility, and avoiding single points of failure. Here’s why local LLMs or rented GPUs are interesting from that perspective:

• No API Keys, No Third-Party Risks: Running models locally (or on infrastructure you control) means no need to expose your data to external APIs. That’s a big deal if you’re handling sensitive information.
• Visibility and Auditability: With LM Studio or Runpod, you can see exactly what’s running, how it’s configured, and even inspect the code if needed. No black boxes.
• Avoiding Vendor Lock-in: Some AI tools lock you into their ecosystem. Local models or cloud GPUs give you the flexibility to switch tools without being stuck.
• Cost Control: Renting a GPU by the hour (e.g., on Runpod) means you only pay for what you use—no surprise bills from over-provisioned cloud services.

Long term, I like having both options. Just like in networking, it’s about picking the right tool for the job—and understanding enough about what’s under the hood that you’re not surprised when things scale, break, or need to be secured properly.

Segmenting IoT on a FortiWiFi 60F: less noise, smaller blast radius

Post #3 · September 2025 · Home Lab / Network Security

Why I split IoT off my primary network

Over time I ended up with a lot of “always-on” devices: smart plugs, lights, outlets, an alarm clock, speakers, TVs — the usual modern home stack. When I started doing packet captures on my home network, it was obvious these devices generate steady background traffic (DNS lookups, NTP time sync, cloud telemetry, periodic update checks, and a good amount of broadcast / multicast chatter).

None of that is automatically “bad,” but it creates two problems: visibility gets noisy, and the blast radius grows. If any single IoT device is compromised, a flat home network makes it easier for that compromise to pivot laterally.

The approach: separate SSID + segmentation policies

I chose a FortiWiFi 60F so routing, Wi-Fi, and policy enforcement could live in one place. I created a dedicated IoT SSID treated like its own security zone, then built firewall rules around a simple principle: deny by default, allow only what’s needed, and log the rest.

• Dedicated IoT SSID: smart-home devices connect here, not on my primary SSID.
• Isolation boundary: IoT cannot initiate connections into the trusted LAN.
• Explicit allowlists: permit only required services (DNS, NTP, and HTTPS as needed).
• Logging: keep policy logs enabled so unusual patterns stand out quickly.

The 2.4 GHz compatibility issue (and what I changed)

The main friction point was that several devices were 2.4 GHz-only and fairly picky about “legacy-friendly” Wi-Fi settings. A few would fail to join, or would join and drop intermittently. The fix was to tune the IoT SSID for compatibility.

Firewall rules: what I allowed and what I blocked

After devices were stable on the new SSID, the security work was mostly policy design. I used a simple policy stack:

• Allow: IoT → DNS (to the resolvers I trust)
• Allow: IoT → NTP (time sync)
• Allow: IoT → HTTPS (firmware updates and normal cloud control)
• Deny + log: IoT → Trusted LAN (no lateral access)

What improved immediately

The biggest win was clarity. My trusted network captures became quieter and more meaningful, and any noisy or unusual IoT behavior is now scoped to its own segment. The second win is risk management: even if a device is vulnerable, it’s fenced into a network that can’t freely reach the rest of the house.

How a Customer Tip Led Me to Rediscover the Unquoted Service Path Vulnerability

Post #6 · November 2025 · Windows / Security

Sometimes, the most interesting discoveries start with a simple message from a customer.

Recently, a customer reached out reporting a potential vulnerability related to unquoted service paths. Curious, I decided to investigate — and to my surprise, I was able to reproduce the issue exactly as described. It was a moment that reminded me how even well-known bugs can surface in unexpected places.

What Is the Unquoted Service Path Vulnerability?

For those unfamiliar, the unquoted service path vulnerability is a classic Windows misconfiguration. When a service executable path includes spaces and isn't wrapped in quotation marks, Windows may misinterpret the command. This can lead to unintended execution of malicious files if they're planted in predictable paths.

For example, if a service is registered like this:

Without quotes, Windows will first attempt to run:

• C:\Program.exe
• Then C:\Program Files\Vulnerable.exe
• And finally C:\Program Files\Vulnerable Service\Service.exe

If an attacker can place a malicious Program.exe in C:\, it might get executed instead — but only if they already have elevated privileges to write to those directories.

My Reproduction

Using the steps outlined in this GitHub guide, I set up a test environment with:

• A new service with an unquoted path
• Write permissions granted to a non-admin user for the service directory
• A dummy executable named Service.exe dropped into the path

After restarting the service, my dummy code executed successfully — validating the vulnerability in this (misconfigured) scenario.

Not All Reports Are Created Equal

This got me digging further and I came across this insightful blog post by Raymond Chen at Microsoft: 👉 Unquoted service paths: The new frontier in script kiddie security vulnerability reports

Raymond walks through multiple examples of poorly understood — and sometimes outright false — vulnerability reports. Some of these reports flagged unexploitable issues, such as:

• Paths that are already quoted
• Services running with command-line arguments (which don’t need quotes)
• Services installed in protected directories like C:\ProgramData or C:\Windows\System32

His conclusion? Quoting paths is best practice, but most of these scenarios are not exploitable unless the system is already misconfigured.

My Takeaway

This was a great reminder that:

1. Even “low-risk” issues are worth validating — especially if a customer flags them.
2. Security is as much about good hygiene as it is about exploitability.
3. Understanding the nuances of Windows services and paths is critical when assessing vulnerability reports.

Interested in Learning More?

• GitHub Lab Setup & Guide: Unquoted Service Path - Windows Local Privilege Escalation Cookbook
• Microsoft’s Real-World Take: Raymond Chen on Unquoted Service Paths

Fixing these issues takes minutes — but not fixing them can lead to hours of explaining why they weren’t a risk …until they were.

Stretching Innovation: My Entrepreneurial Journey with NSIN and FedTech

Post #5 · July 2025 · Entrepreneurship / Defense Tech

When I joined the National Security Innovation Network (NSIN) through the FedTech Foundry program, I wasn’t quite sure what to expect. All I knew was that I was being paired with a team and a Department of Defense researcher — someone who held a promising patent — and together we’d explore how to turn that invention into a viable, real-world product. We were competing with other teams for a shot at a grant to help launch a startup and bring our prototype to life. But as I quickly learned, the experience was far more than a competition — it was a crash course in innovation, pivoting under pressure, and understanding what real customer discovery looks like.

The Tech: A Flexible Silicone Sensor

Our team was assigned a fascinating piece of tech: a liquid-metal-based flexible silicone sensor embedded with soft materials. Unlike traditional rigid sensors, this one was stretchable, biofidelic, and could be embedded into soft materials to detect high-impact forces — think milliseconds-scale blast events or pressure changes. The original idea? Apply it to NFL helmets, helping detect concussions by measuring internal forces during impacts. It seemed like a great fit — literally and metaphorically.

The Pivot: From Football to Fighter Jets

But as we began interviewing potential users, especially within the Department of Defense, our thinking evolved. Through conversations with Air Force pilots, we discovered an entirely different — and possibly more impactful — use case: integrating the sensor technology into flight suits. The sensor’s ability to deform with the material and remain sensitive during extreme conditions made it a strong candidate for monitoring pressure, strain, and potential injuries in high-G or crash scenarios. This pivot not only changed our direction — it changed our mindset. We weren’t just repurposing technology; we were solving real operational pain points with defense relevance.

What We Built

With insights from military interviews and technical specs from the patent, we worked on positioning the flexible sensor as a platform technology. Potential applications ranged from:

• Embedded sensors in protective gear (combat helmets, body armor)
• Soft robotics and prosthetics with life-like tactile response
• Medical wearables for high-fidelity strain and pressure sensing

While we didn't advance to the final grant round, our team was proud of the prototype concept and the groundwork we laid for future development.

The Real Wins: Skills, Insights, and Networks

Although we didn’t take home the top prize, I walked away with something just as valuable:

• Real-world experience commercializing defense technology
• Deep understanding of customer discovery and market validation
• Exposure to cutting-edge sensor technology
• A new appreciation for the intersection of defense innovation and entrepreneurship
• Lasting connections with researchers, mentors, and fellow entrepreneurs

The FedTech Foundry is more than a startup incubator. It's a proving ground — one where the process matters just as much as the product.

Final Thoughts

Innovation isn’t linear. Sometimes the best ideas emerge when you're forced to stretch — to reconsider assumptions, change direction, and build something that resonates with a user’s actual needs. That’s exactly what this experience gave me: the ability to stretch, adapt, and grow — not just as a team member, but as an entrepreneur.

The night a smart outlet made me question my own network

Post #7 · December 2025 · Home Lab / Network Security

This was not a dramatic “caught a hacker” story. It started with me doing the boring thing I try to do after any change in my home lab: baseline traffic captures and sanity checks.

I had recently tightened segmentation between my Trusted LAN and my IoT segment, and I was in the middle of testing a new smart outlet I bought online. Cheap, feature rich, and the kind of thing you convince yourself is fine because it is just a plug.

The outlet joined WiFi, the companion app paired quickly, and everything looked normal until I glanced at my capture. One device was reaching out to a public IP I did not recognize: 221.233.52.33. That was enough to slow me down and switch from “setup mode” to “verify mode.”

What made me stop and look

IoT devices talking to the internet is not automatically suspicious. Firmware checks, time sync, cloud control, telemetry, all of that exists. What I pay attention to is consistency, timing, and whether the destination makes sense for the device and for how I intend to use it.

• The outlet initiated outbound connections without me controlling it.
• The destination stayed consistent enough that it stood out in the endpoint list.
• I saw repeated traffic involving 221.233.52.33.
• The behavior continued even when I was not using the app.

I do not label something as malicious just because it feels weird. I try to turn “weird” into a short list of testable questions. Who is talking. To where. How often. And does it stop when I remove cloud dependencies.

The capture workflow I use when IoT acts chatty

I keep this routine simple so I will actually do it every time.

1) Prove it is the outlet, not some other device

• Wireshark: Statistics → Endpoints and filter for the outlet MAC address once you identify it.
• Router or DHCP leases: map the outlet IP to a MAC and hostname label if your network provides one.
• Sanity check the VLAN: confirm it is in the IoT segment and not accidentally on the Trusted LAN.

2) Focus on the one external destination that triggered the question

• Wireshark display filter: ip.addr == 221.233.52.33
• If you are capturing on a gateway you can also look for NATed sessions to that destination.
• If you want to see DNS that might be related: dns then inspect query names near the same timestamps.

3) Identify protocol and port so you know what you are dealing with

• If it is HTTPS, expect TLS handshakes and encrypted payloads.
• If it is plain HTTP or unusual UDP, that changes how I treat it.
• Wireshark quick lens: tcp.port == 443 && ip.addr == 221.233.52.33

At this point I was not trying to “decrypt the traffic” or prove attacker intent. I only needed enough clarity to decide whether to isolate the device and test what breaks when outbound access is restricted.

What I checked before assuming the worst

Before I called it “sketchy,” I ran the same three pivots I always run: confirm device identity, confirm the egress path, and confirm whether the behavior is required for the features I actually want.

1) Confirm the outlet identity via neighbor tables

• Windows: arp -a
• macOS or Linux: arp -an or ip neigh
• Router client list: match MAC address to the device that appeared when you paired it.

2) Confirm it is not bypassing your DNS visibility

• If you run a local resolver, verify the IoT VLAN is actually using it.
• If the device hardcodes DNS, you will see it talking to external resolvers directly (instead of your intended DNS).
• On a segmented VLAN, force DNS to your resolver and block outbound DNS to the internet.

3) Test what happens when you block the destination

• Temporarily block outbound to 221.233.52.33 for the IoT segment.
• See what functionality breaks (pairing, scheduling, remote control), then decide whether you want that risk.

Digging deeper: Chinese actor tactics

The IP address 221.233.52.33 stood out for another reason - its geolocation. When I ran a quick whois check:

$ whois 221.233.52.33
      ...
      origin:      CN
      country:      CN
      ...

This confirmed the IP was located in China, a country known for state-sponsored cyber operations targeting Western infrastructure. I then cross-referenced this with my local threat intelligence feed using:

$ mtrg -r 221.233.52.33
      ...
      [Threat Intelligence Match]
      IP: 221.233.52.33
      Type: C2 (Command and Control)
      Associated Groups: APT41, Winnti
      ...

While this wasn't definitive proof of malicious activity, it was enough to significantly raise my suspicion level. Chinese actor groups are known for:

• Using seemingly benign IoT devices as initial access points
• Establishing persistent outbound connections for C2
• Obfuscating traffic through legitimate-looking domains and IPs
• Maintaining access even when not actively using the device's features

The consistent outbound connections to this Chinese IP, even when I wasn't interacting with the outlet, matched known APT behavior patterns.