The reason I finally had to was Wazuh.

My Proxmox host, lab0, was sitting on 32GB of RAM. I restarted it fresh, and it climbed right back to 63% memory utilization; on a normal day when I’m not touching anything, it drifts up to 70% or 71%. Almost all of that is one node. Wazuh was pulling around 18GB immediately after boot and creeping toward 30GB the longer it stayed up.

That’s what finally pushed me. It wasn’t that anything was broken; it’s that nothing new could ever get built. Every time I thought about spinning up another VM for a project, the math said no before I even got to the fun part. So I had to upgrade the memory.

Two G.SKILL Ripjaws V DDR4 sticks, 16GB each, to take the host from 32GB to 64GB. $239, which stung a little. If you’ve priced memory recently, you already know why: AI demand has RAM in a strange place right now, and DDR4 didn’t get a pass. Not an outrageous number for 32GB, but definitely a premium over what I paid for the original build.

Before I pulled power on anything, I did one small thing that I’d recommend to anybody about to do the same job. I went into the Wazuh VM options in Proxmox and turned on start at boot. It takes thirty seconds, and it means that when the host comes back, your important VMs come back with it. Then I shut the node down cleanly, powered off the machine, and unplugged it.

Where it started going wrong

Two open DIMM slots, two new sticks. I had this pegged as a fifteen-minute job.

The first one went in fine. Lined up the notch, pressed down, heard the click, felt pretty good about myself. I flipped the lever on the second slot, slid that stick in, and it felt locked, so I closed everything up, plugged the machine back in, and hit power.

Yellow light.

I gave it time, because I didn’t expect it to post instantly, and I kept refreshing the Proxmox page like that would help. It stayed yellow. Then, on a later attempt, it went red, and red is what actually worried me. So I looked both up, and it turns out the board had been telling me exactly what was wrong the entire time.

Solid yellow or amber on the DRAM light means memory failed the power-on self-test. Red means the system can’t detect a component at all.

Fine. Something’s loose. I powered down, opened it back up, and started reseating.

The thing I didn’t know about DDR4

This is where I burned most of the evening, and where the actual lesson lies.

I pulled the sticks and pushed them back in, and nothing changed. Did it again; still yellow. I was being careful, because these things are expensive and they feel fragile, and I kept thinking I was going to crack something. At one point I caught myself wondering if I was the problem, doing this on my office floor, in bad light, wearing jewelry, not grounded, which is a pretty complete list of what you’re not supposed to do.

I was the problem, just not in the way I assumed.

Read more

My primary homelab server lab0 was still running Proxmox VE 8.4 on Debian 12 Bookworm. Since Proxmox VE 9 had been out for a while and moves the underlying distribution to Debian 13 Trixie, I decided it was time to make the jump.

This is the same host running much of the infrastructure from my homelab series, including my Wazuh VM.

So before changing anything, I started where every major upgrade should start:

pve8to9 --full

The initial report was better than expected: 43 checks total, 29 passing, three warnings, and one failure.

The failure was the one that mattered most:

FAIL: systemd-boot meta-package installed.

There were a few other cleanup items too:

• AMD CPU microcode was missing.

• Legacy settings remained in /etc/sysctl.conf.

• LVM volumes were using the old autoactivation behavior.

• Wazuh’s third-party repository appeared as an unusual APT suite.

• One VM was still running.

None of that was catastrophic. But this is precisely why pre-upgrade checks exist: they turn hidden technical debt into an actionable checklist.

Full unedited upgrade process (with the help of ChatGPT).

Confirming the Boot Path

The first thing I wanted to understand was the bootloader warning.

Having the systemd-boot package installed does not necessarily mean the host actually boots using systemd-boot, so I checked the relevant state:

proxmox-boot-tool status
efibootmgr -v
dpkg -l | grep -E 'systemd-boot|grub|proxmox-boot'

The key detail was this EFI entry:

Boot0004* proxmox ... \EFI\proxmox\shimx64.efi

The host also had the full GRUB stack installed. In other words, it was booting through Proxmox’s GRUB/shim path—not systemd-boot. The package was simply an unnecessary meta-package left behind on the system.

I removed it, reran the checker, and the failure disappeared.

That took the host from one failure to zero.

Cleaning Up Before the Upgrade

Next, I worked through the remaining warnings.

Updating LVM autoactivation

Proxmox 9 changes how newly created LVM and LVM-thin guest volumes use autoactivation. One of my existing VM disks still had the older behavior enabled.

Proxmox provides a migration script for this:

/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation

It found the affected volume and corrected it.

One important lesson: I had to run this script a second time later in the upgrade

Read more

So before I left, I made sure Tailscale was already installed and running across the homelab: the Proxmox host, my laptops, all of it.

That one decision ended up being the whole point of this issue. Because once I was actually in D.C., sitting on hotel WiFi with zero trust in that network, I got to see firsthand just how powerful that setup really is.

So this issue is about showing that off: how I access my entire cybersecurity homelab from anywhere, without exposing Proxmox, SSH, or remote desktop services directly to the internet, and why setting it up before you need it is the move.

The two tools doing all the heavy lifting: Tailscale and RustDesk.

Watch the full walkthrough here:

Why I Set This Up Before I Ever Needed It

Here’s the thing about homelabs: the second you want to reach them from outside your own network, you’re one bad decision away from turning a learning environment into a real liability.

Port forward SSH to the router and you’ve got a service sitting on the open internet getting hammered by scanners or unrelentless AI agents within hours. Expose the Proxmox web UI the same way, and you’ve basically hung a sign that says “management plane, please attack me.”

I never even considered either of those routes. I wanted something that felt like I was still on my home network, no matter where I actually was, and I wanted it working well before I needed it under pressure.

That’s the whole premise of Tailscale: a mesh VPN built on WireGuard that quietly stitches all your devices into one private network (a “tailnet”), with no ports opened on your router at all.

How Tailscale Connects My Homelab Devices

The setup is almost anticlimactic in how simple it is. Install the Tailscale client on a device, authenticate, and it joins the tailnet. That’s it. No firewall rules, no static IP requirements, nothing crazy.

I’ve got it running across the homelab: the Proxmox host, individual VMs, my laptops, even devices that aren’t normally reachable from outside the house.

Once everything’s on the same tailnet, they can all talk to each other using stable, private IP addresses (or MagicDNS names, if you want something more human-readable). It doesn’t matter if I’m on hotel WiFi in D.C. or on my phone’s hotspot. As far as the network is concerned, I’m home.

Configuring and Using Exit Nodes

This is where it goes from “nice remote access” to genuinely useful: exit nodes.

An exit node lets you route your device’s entire internet traffic through another machine on your tailnet, in my case, a node sitting at home. Flip it on, and suddenly all my traffic looks like it’s coming from my home network, encrypted the whole way there.

Practically, that means I can be anywhere, connect through my home exit node, and get the same network posture I’d have sitting on my couch. For a security engineer who’s paranoid about hotel and conference WiFi (rightfully so), that’s a real upgrade over hoping a commercial VPN is trustworthy.

Remotely Accessing Machines With RustDesk and Tailscale

SSH gets you a terminal. Sometimes you need a screen or GUI.

That’s where RustDesk comes in, an open source remote desktop tool that I’m running entirely over the Tailscale network rather than exposing it to the open internet. Since RustDesk traffic rides on top of Tailscale’s already encrypted mesh, I get full remote desktop access to my homelab machines without opening a single port.

This combo (Tailscale for the private network, RustDesk for the actual screen access) means I can pull up a full desktop session on any lab machine from basically anywhere, and the attack surface stays exactly where I want it: nowhere on the public internet.

Using Tailscale SSH Across My Tailnet

Once devices are on the tailnet, Tailscale can also handle SSH directly, no separate key management, no exposed port 22, no fumbling with .ssh/config across a dozen machines.

Access control lives in Tailscale’s ACLs instead of a patchwork of firewall rules. Want to restrict which devices can SSH into which lab machines? That’s simple a policy.

For a homelab where I’m constantly spinning things up and tearing them down, this alone saves a meaningful amount of friction.

Secure File Sharing With Taildrop

Small feature, genuinely useful: Taildrop.

It lets me send files directly between devices on the tailnet, no cloud upload, no USB drive, no janky SCP command with a path I always mistype. Need to grab a config file off my macbook host onto my Proxmox while I’m out? Taildrop handles it, encrypted, peer-to-peer, done.

It’s not the headline feature, but it’s the kind of quality-of-life addition that makes the whole setup feel less like a workaround and more like an actual system.

Security Considerations for Remote Homelab Access

I’d be doing you a disservice if I didn’t call out the tradeoffs, because there always are some.

Tailscale and RustDesk dramatically shrink my attack surface compared to port forwarding, but they don’t eliminate risk. A few things I’m keeping in mind:

• Identity is the new perimeter. Tailscale ties device access to your identity provider. If that account gets compromised, the blast radius is your entire tailnet. Multi-factor authentication on that identity provider isn’t optional.

• ACLs need actual attention, not defaults. It’s tempting to let every device talk to every other device once it’s all “private” anyway. Don’t. Scope access the same way you would on any internal network. I’ll make a future issue on that.

• RustDesk still needs auditing. Remote desktop access is powerful, which means it’s also exactly the kind of access an attacker wants if something upstream goes wrong. I’m treating it the same way I’d treat any privileged access path in production: logged, reviewed, with MFA and not left on indefinitely.

None of this is a reason to avoid the setup. It’s a reason to run it the way I’d want anyone on my team running similar access in a real environment.

What I’m Taking Away From This

Setting it up before you need it is clutch. The whole reason this trip went smoothly is that Tailscale was already running when I needed it. If I’d waited until I was in a hotel room trying to configure a VPN for the first time, this story would read very differently.

Convenience and exposure aren’t the same tradeoff you think they are. I assumed secure remote access meant sacrificing convenience. Tailscale proved that wrong. The private mesh is often more convenient than the “exposed” version ever was.

Identity-based access beats network-based access almost every time now. Instead of asking “what can reach this port,” I’m asking “who is this device, and should it be allowed to talk to that other device?” That mental shift matters more than any specific tool.

The best security fix is usually the one that removes the exposure entirely, not the one that adds another layer on top of it. Zero open ports beats a hardened open port every time.

What’s Next

Now that I’ve seen how well this held up under real-world conditions, I want to push further into how I segment the tailnet itself: tighter ACLs between the Wazuh manager, the endpoints reporting to it, and everything else in the house.

If something in this house misbehaves while I’m three states away, I want to still catch it. If it breaks, I want to know why, from wherever I happen to be.

The homelab keeps getting more capable. Let’s see where it goes next.

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

That’s insane to say out loud. It’s July 2026 now.

Life’s been a whirlwind though, a good one. I got married. We went on our honeymoon. And somewhere in the middle of planning a wedding for six straight months, the homelab just… sat there. Dormant. Collecting dust.

But here’s the thing: now more than ever, this project matters. Because my wife and I living together has literally expanded our threat surface. New devices, new habits, new attack surface under one roof.

So this is a two-in-one issue, part homelab, part home security. Time to get this thing back on track.

The mission: deploy the Wazuh agent across four endpoints (three macOS machines and one Windows box) and make sure I have visibility into every single asset in this house.

Endpoint 1: The Command Center

First up is an old MacBook (M1, Apple Silicon) that used to be my daily driver, before it got demoted to “random stuff” duty once I upgraded. Still functional, still useful, so I gave it a new job: command center for the homelab.

Everything still runs off the makeshift PC server, where Proxmox lives. But this MacBook is where I access the Wazuh dashboard and manage the whole operation.

Following the Wazuh macOS install docs, the process is refreshingly simple:

• Log into the dashboard, click Deploy a new agent

• Confirm the architecture (Apple Silicon vs. Intel)

• Point it at the manager IP; mine’s sitting on 192.168.1.133

• Name the agent (I went with cwx-mac-cmd-ctr)

• Copy, paste, run

A few minutes later: agent active. To confirm it was actually working, I ran sudo -i to trigger a privileged session, and sure enough, Wazuh flagged it immediately: “First time user executed sudo.”

That’s the whole point of a homelab, honestly. You don’t just install something and trust it works. You poke it until it proves itself.

Endpoint 2: The Daily Driver

Next up was my actual daily driver, an M4 MacBook, also silicon, also where all my content and work actually happens. Same install flow, new agent name: cwx-mac-daily-driver

Ran the same sudo -i test. This time, four events came through: agent connected, agent stopped, agent started, first-time sudo. Clean.

Two active agents down. Two to go.

Endpoint 3: My Wife’s MacBook (Yes, “Big Bertha”)

This one came with a small hiccup, a connection refused error that turned out to be a missing https:// in the manager address. Classic. Once fixed, the install went smoothly on her M1 MacBook, which (for reasons I will not fully explain in a newsletter) was almost affectionately named Big Bertha.

Same sudo test, same confirmation. Three agents active.

Endpoint 4: The Proxmox Node

This is the one that actually matters most, the bare-metal node running every virtual machine in the lab. Confirmed it was a Debian-based AMD64 system with uname -m, grabbed the Linux install command, and named it cwx-proxmox-lab0, after the lab itself.

Then it broke.

“The job for the wazuh-agent service failed because the control process exited with error code.”
“Invalid server address found for manager IP.”

Classic homelab moment. Turns out I had previously installed the Wazuh manager on this exact node (back when this box briefly played SIEM server), and the config was still pointing at itself instead of the actual manager IP. A quick edit to swap the manager IP field to 192.168.1.133, a service reload, and it connected.

This is the part of homelabbing that never changes, no matter how many years in: trial and error is still the name of the game. Every fix teaches you something about how the system actually behaves under the hood, not just how the docs say it should.

Endpoint 5 (Sort Of): The Windows Box

Last endpoint: a Windows machine I picked up a couple years ago while (half-heartedly) studying for the SANS GCIH cert I never actually took. It’s been sitting around for VMware experiments and “special projects” ever since. Time to put it to work.

Here’s where I have to be honest with you: I goofed. OBS wasn’t configured to capture the screen properly, so the actual Windows install didn’t record. But the process is genuinely this simple:

• Copy the install command from the Wazuh dashboard

• Run it as admin in PowerShell

• Start the service

And then, don’t skip this, install Sysmon. Raw agent telemetry is good, but Sysmon is what turns “I have an agent” into “I actually have visibility.” I recommend Olaf Hartong’s Sysmon-modular config, probably the most useful config out there, or SwiftOnSecurity’s Sysmon config as a solid alternative.

What I’m Taking Away From This

A few things stuck with me rewatching this lab session:

Visibility isn’t a one-time project; it’s a maintenance habit. Nine months of dormancy meant nine months of blind spots. The moment life changes (new house, new person, new devices), your monitoring needs to catch up.

The “boring” fixes are usually config, not code. Every issue in this session (a missing https://, a stale manager IP left over from an old install) was a five-second fix once I actually read the error message instead of assuming the worst.

Test every agent the same way you’d expect a real event to fire. sudo -i isn’t glamorous, but it’s a fast, repeatable way to confirm an agent is actually alive and alerting, not just “installed.”

What’s Next?

The homelab’s back. Let’s see where it goes.

Watch the full episode:

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, Substack, and Discord 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

What once appeared as clumsy scams with broken English and shady attachments has evolved into sophisticated, multi-layered attacks. Modern attacker campaigns not only deceive users but also utilize legitimate cloud services and Windows tools to blend into regular activity se…

Read more

Behind every headline of breaches and takedowns are targeted campaigns carried out by methodical, well-resourced threat actors — each with their motives, tactics, and long-term goals.

One such group is Salt Typhoon (also tracked as FamousSparrow and GhostEmperor depending on the vendor).

A Chinese nation-state–backed adversary that has been discovered infiltrating major U.S. telecom networks — from T-Mobile to Verizon, Samsung, and others.

Salt Typhoon is known for stealth, patience, and precision.

They leave behind only faint traces across compromised networks, making it exceptionally difficult for defenders to contain or eradicate their activity.

That challenge is exactly where cyber threat intelligence (CTI) comes in.

From IOCs to Insight

Threat intelligence is not just about collecting IOCs (indicators of compromise, such as hashes, IPs, and domains) and feeding them into SIEMs.

At its best, CTI is about connecting the dots: finding patterns across disparate indicators, uncovering infrastructure, profiling adversary behavior, and turning raw data into actionable defense.

The value lies in the transformation:

• From a file hash → to the malware family behind it.

• From a suspicious domain → to the broader C2 network.

• From isolated alerts → to an adversary campaign strategy.

When done well, this enables defenders to build more effective detections, strengthen playbooks, automate enrichment, and prioritize risks in line with evolving active threat landscapes.

About Me

If you're new here, I'm Day, a Cybersecurity Engineer at Amazon. With five years in cybersecurity, my experience covers Detection Engineering, Cloud Security, Incident Response, Threat Hunting, and most recently, Threat Intelligence.

Before Amazon, I worked at Datadog as a cloud threat detection engineer, where I researched cloud threats and built detections for various cloud providers and SaaS applications.

I've worked my way up from various SOC analyst roles, investigating everything from endpoint threats to building detection systems for cloud-based abuse, so I know exactly what it takes to break into this field and make career advancements.

I started, just like many of you, learning from scratch, asking questions, and figuring it out one step at a time. And now, I'm here to help you do the same.

If you want to stay up-to-date on the cybersecurity industry and everything technical and career-related, be sure to like and subscribe to the newsletter for more content like this.

Join a vibrant cybersecurity community of over 6,500 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

Applying CTI in Practice

As a Security Engineer at Amazon, I’ve had the opportunity to use threat intelligence at scale.

But CTI isn’t just for enterprise SOCs. With the right tools, individual analysts and researchers can explore and learn from the same adversary tradecraft.

For this issue, I investigated Salt Typhoon using ANY.RUN’s Threat Intelligence Platform. It blends interactive sandboxing (their signature strength) with curated intelligence and lookup capabilities. Here’s what that looks like in practice:

• Starting with a handful of IOCs, such as an IP address, a SHA-256 hash, or a domain name.

• Pivoting into reports → correlating with published research from vendors like Trend Micro.

• Interactive detonation → running suspicious files in a sandbox, observing process creation, persistence mechanisms, and outbound C2 calls.

• Hunting for connections → mapping behaviors against known TTPs and extracting new indicators.

• YARA integration → building and running rules directly in the platform to surface related artifacts.

What begins as a single suspicious hash quickly expands into a narrative: a Trojan is dropped, a service is created for persistence, reconnaissance of the host is conducted, and finally, communication with a C2 domain occurs.

Why It Matters

The power of CTI lies in turning fragments into a story.

Instead of drowning in endless IOCs, analysts can contextualize activity, link it to known actors, and anticipate what might come next.

In this case, a few scattered data points around Salt Typhoon transformed into a clearer picture of:

• Their infrastructure choices

• Their persistence techniques

• Their reconnaissance behavior

• Their communication patterns

With that knowledge, defenders can proactively hunt for related TTPs in their environments or simulate adversary behavior to test defenses.

ANY.RUN Threat Intelligence

This issue is powered by ANY.RUN, which sponsored this deep dive. ANY.RUN makes it easy to turn raw indicators into actionable intelligence without needing to set up your own lab environment. If you’re serious about developing threat intelligence skills, it’s worth checking out.

🚀Unlock (free) ANY.RUN Threat Intel

Closing

What began as a file hash and a suspicious domain evolved into a broader narrative about Salt Typhoon’s operations. That’s the heart of cyber threat intelligence: transforming raw signals into stories that defenders can act on.

If you’re early in your cybersecurity journey, practice this workflow yourself:

• Begin with a known IOC from a publicly available report.

• Pivot into related domains, files, and hashes.

• Map the TTPs you discover against frameworks like MITRE ATT&CK.

• Build detections or run hunts based on your findings.

That’s how you transition from merely “consuming” intel to generating actionable intelligence — a skill that grows from home labs to Fortune 500 SOCs.

Here’s a video that can help you do that:

Thanks for reading Cyberwox Unplugged! This post is public, so feel free to share it.

Share

That spark led me to build my very first homelab in a small apartment bedroom. No mentors, no structured guidance, just curiosity and trial-and-error.

That project changed everything. It was the firs…

Read more