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.

A stick can be locked at the bottom and completely loose at the top. It looks/looked seated, but it isn't.

DDR4 needs more force than feels acceptable, and it needs that force at both ends until each side clicks. Being gentle was why nothing worked. Once I pushed harder, every stick clicked twice, and suddenly they all looked properly seated in a way they hadn’t before. I had pushed one in earlier, and it wasn’t even sitting right, which is a little scary in hindsight.

So now everything was genuinely in. I closed it up, powered it on, and got yellow again.

The part that wasn’t the RAM

At that point I was lightheaded and out of ideas, so I went looking. I found people on Reddit describing the same lights and saying the fix was to reseat the big power cable that runs into the motherboard, which I hadn't touched once.

I grabbed my phone flashlight, which I should have done an hour earlier, and actually looked. The large connector was snug. The small one next to it wasn’t, and I’d been fighting it because I was going in the wrong order. There’s a little arrow stamped on it that had me second-guessing myself for a while, trying to work out which way it was supposed to point.

The small connector goes in first, and then the larger one seats on top of it and anchors, with a clip on the side. Once I did it in that order, it slid in and sat snug immediately.

Looking back, this is the part I’d want somebody to take from all of it. I was a hundred percent certain this was a memory problem, because memory was the thing I changed. It was partly memory, and partly a connector I never intended to move, and I only found the second half because I got desperate enough to stop trusting my own assumption. If you’re reading this thinking I was making it far harder than it needed to be, you’re right, and I knew it while it was happening.

Back online

I powered it on, and the light went yellow, then red, then white, then red again, then white, then green. I went through about six emotions in ten seconds.

Then the POST screen came up: ASUS TUF Gaming, total memory 65536MB.

It booted into safe mode, which makes sense after that many failed POST attempts and a few forced shutdowns. I went into the BIOS, checked the CPU temperature, confirmed DRAM status looked right, confirmed Proxmox was still first in the boot order, changed nothing, and saved and exited. One more reboot, and lab0 was back.

Proxmox reports 62GB usable rather than 64, which is normal. The BIOS sees the full 65536MB, and some gets reserved before the hypervisor ever counts it. Wazuh is now running around 59 percent of the 32GB I allocated to its VM, and that’s completely fine because it’s using what I gave it instead of squeezing the entire host. There’s finally room for the next VM.

Tailscale was the last loose end. The tail IP wouldn’t load at first and tailscale status reported it running but idle after all those hard resets. It came back on its own after a while, and by then it was the least of my concerns.

What I’m taking away

Turn on start at boot before you power down. Thirty seconds of prep so you’re not troubleshooting two problems at once.

Read the lights. Amber means DRAM, red means a component isn’t being detected. The board is specific. I guessed for twenty minutes before I looked it up.

RAM needs real force, at both ends. No click on both sides means it isn’t in, no matter how snug it looks.

Work on a flat surface with the light on. I did neither and made the whole thing harder than it had to be.

Question the thing you changed. I was sure it was the memory. The power cable I never touched was half the problem.

So, storage or a NAS?

The bottleneck has now moved, and now I’ve got headroom for the projects I’ve been putting off.

Storage is the next constraint. I’m on a single 1TB drive, and I keep going back and forth. I could drop in another SSD, which is cheap, quick, and solves the immediate problem. Or I could build out a mini NAS, which costs more and takes real work but gets the lab closer to something that actually resembles infrastructure instead of everything living on one disk. That’s also just a better project.

Still deciding, and you’ll be the first to know when I decide.

Two questions for you in the meantime. Would you have done this upgrade differently, and if so, how? What should I hit next: another drive or the NAS?

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 💙

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

because another LVM-backed VM state volume appeared after the new LVM configuration was installed.

A clean pre-upgrade check does not guarantee that nothing changes during the distribution upgrade itself. Run the checker again afterward.

Installing AMD microcode

lab0 uses an AMD Ryzen CPU, and the upgrade checker correctly identified that amd64-microcode was not installed.

The reason was straightforward: my Debian repositories only included:

main contrib

The microcode package lives in:

non-free-firmware

After updating the Bookworm repository definitions, I installed the package:

apt install amd64-microcode

That rebuilt the initramfs and queued the updated microcode for activation at the next reboot.

Another warning resolved.

Moving sysctl settings out of /etc/sysctl.conf

I also had these forwarding settings in the legacy /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

They are intentional. This host participates in networking within the lab—but Proxmox 9 wanted them moved into a dedicated file under /etc/sysctl.d/.

I created:

/etc/sysctl.d/99-homelab-forwarding.conf

With:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Then applied the configuration:

sysctl --system

Both forwarding values remained enabled.

After another upgrade-check run, I was down to:

WARNINGS: 1
FAILURES: 0

The remaining warning was simply that a VM was still running.

At that point, the host was ready.

Moving to Proxmox 9

Before changing repositories, I shut down Wazuh and temporarily disabled the Wazuh and Tailscale APT sources.

For a major Debian upgrade, I prefer to keep third-party repositories out of the transaction until the base OS and platform packages are stable. It reduces the number of variables involved if something goes sideways.

I then migrated the Debian repositories from Bookworm to Trixie and moved to the newer deb822-style APT configuration.

The Debian suites became:

trixie
trixie-updates
trixie-security

And the Proxmox repository became:

trixie pve-no-subscription

After updating package metadata:

apt update

I verified the intended upgrade path:

apt policy proxmox-ve

The output showed exactly what I wanted:

Installed: 8.4.0
Candidate: 9.2.0

Then came the real upgrade:

apt dist-upgrade

And that is where things became interesting.

The APT Terminal Disappeared

During the upgrade, Debian prompted for configuration-file decisions—normal things such as:

/etc/issue
/etc/lvm/lvm.conf

At some point, though, the shell running apt dist-upgrade disappeared due to a random glitch.

The upgrade process itself did not.

When I checked the Proxmox package state, I found a strange hybrid environment. Proxmox 9 packages were present:

pve-manager: 9.2.11
proxmox-kernel-7.0.14-12-pve

But many packages were listed as:

not correctly installed

That looks alarming, but it is exactly the moment when you should avoid making things worse.

My first check was:

dpkg --audit

It showed a long list of packages that had been unpacked but not yet configured.

I tried:

dpkg --configure -a

But APT still owned the package database.

So instead of deleting lock files or rebooting, I checked the process tree:

ps auxf | grep -E '[a]pt|[d]pkg'

There it was:

apt dist-upgrade
└── dpkg --configure --pending

The original APT transaction was still running.

I inspected its file descriptors:

ls -l /proc/<PID>/fd/{0,1,2}

That revealed the actual problem: APT’s input and output were connected to a deleted pseudo-terminal.

/dev/pts/0 (deleted)

The terminal was gone. The process was not.

The upgrade had effectively become stranded while holding the package manager state.

Recovering Safely

Once I knew what I was looking at, the recovery path was clear.

I terminated the orphaned APT process normally:

kill <PID>

I did not delete the package manager lock files.

I did not remove files from /var/lib/dpkg.

I did not reboot halfway through the package configuration process.

After the orphaned process exited, I ran:

dpkg --configure -a

This time it completed successfully.

LVM configured. GRUB configured. The new Proxmox kernel was detected:

Found linux image: /boot/vmlinuz-7.0.14-12-pve

Then the Proxmox packages finished configuring:

pve-manager configured
proxmox-ve configured

I followed with:

apt -f install

Which returned:

Upgrading: 0
Installing: 0
Removing: 0

Then:

apt-get dist-upgrade

Returned:

0 upgraded, 0 newly installed, 0 to remove

That was the confirmation I was looking for: the package database had returned to a healthy state.

pveversion -v Now showed:

proxmox-ve: 9.2.0
pve-manager: 9.2.11
proxmox-kernel-7.0.14-12-pve-signed

And the “not correctly installed” messages were gone.

One Last Weird Service Failure

There was still one failed service:

chrony.service

Chrony is responsible for time synchronization on this host. Its error was:

Fatal error: Could not send notification to $NOTIFY_SOCKET

At that moment, the host had a newly upgraded userspace (including systemd), but was still running the pre-upgrade kernel and runtime environment.

Rather than overcorrecting a failure that could be transient, I validated the essentials:

dpkg --audit

Returned clean.

The new Proxmox kernel was installed and set as the default:

7.0.14-12-pve

And the Proxmox upgrade checker showed no failures.

So I rebooted.

The Moment of Truth

The server came back cleanly.

uname -r

Returned:

7.0.14-12-pve

And:

pveversion -v

Confirmed:

proxmox-ve: 9.2.0
pve-manager: 9.2.11

Most importantly:

systemctl --failed

Returned:

0 loaded units listed.

Chrony had recovered after the reboot. A few seconds later:

chronyc tracking

Showed:

Leap status : Normal

With an active NTP source.

Storage was healthy too:

pvesm status

Both local and local-lvm were active.

Finally, I started Wazuh again:

qm start 100
qm status 100

And got:

status: running

The final validation was the best one:

pve8to9 --full

WARNINGS: 0
FAILURES: 0

Beautiful.

Repository Cleanup

The final step was restoring the repositories I had temporarily disabled.

Tailscale had a Debian 13 Trixie repository available, so I changed its suite from:

bookworm

To:

trixie

Then I re-enabled it.

Wazuh uses its own stable repository suite, so I re-enabled that source as well.

One last APT issue appeared: an enterprise Proxmox repository was still enabled.

https://enterprise.proxmox.com/debian/pve trixie

Since this lab uses the no-subscription repository, APT correctly returned:

401 Unauthorized

The fix was simple: disable the enterprise source and run:

apt update

This time:

All packages are up to date.

The Actual Lesson

This upgrade turned out to be a more valuable homelab exercise than I anticipated, mainly due to the circumstances surrounding it, not because Proxmox 9 introduced a significant breaking change.

Bootloaders. Repository management. CPU microcode. LVM behavior. Sysctl configuration. GRUB. systemd. NTP. Package state. Process trees. Terminal file descriptors. Recovering an interrupted package transaction.

Installing a SIEM is cool. Deploying Kubernetes is cool. Spinning up twenty containers is cool.

But maintaining infrastructure when the platform beneath it changes is where you build a different kind of engineering muscle.

At one point, I had:

• A Proxmox 9 userspace.

• A Proxmox 8 kernel still running.

• Dozens of unpacked-but-unconfigured packages.

• An orphaned APT process holding the package database lock.

• A deleted pseudo-terminal attached to that process.

The negative reaction would have been:

Delete the lock file and reboot.

The right response was:

1. Observe the actual state.

2. Identify what owns that state.

3. Fix the underlying failure.

4. Let the package manager finish the work it was already trying to do.

That is infrastructure engineering.

lab0 is now running:

Debian 13 Trixie
Proxmox VE 9.2
Kernel 7.0.14-12-pve
0 failed systemd services
0 pve8to9 warnings
0 pve8to9 failures

And Wazuh is back online.

Not a bad Friday afternoon in the homelab.

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 💙

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