LockBoxx

This year at NCCDC was strange in a way I do not think I fully appreciated until afterward. For two days, while we were running offensive operations against some of the best collegiate defenders in the country, the New York Times was sitting in the room with us. Watching. Asking questions. Trying to understand why half a dozen people would voluntarily spend months building custom malware, agent frameworks, and infrastructure just to stress test students in a national competition. You see the NYT article here, or read the free archive here. 

Not only that, but we were in the penthouse suite of the Cosmo, eating the best meals, and hacking at poolside cabanas when we weren't in the room. The suite looked exactly like what people imagine offensive security operations look like. Giant wall displays covered in telemetry. Attack infrastructure sprawled across tables. Music running nonstop. Guys fully immersed in the matrix wearing Apple Headsets. Operators shouting across the room, coordinating attacks, while reporters and photographers moved between clusters of laptops and cables running from table to table. If Hollywood designed a cyber operations center, it probably would have looked pretty close to our red team room this year.

One thing I appreciated about working with Cade over the interviews leading into the event was that he seemed genuinely interested in the operational reality rather than forcing everything into a predetermined narrative. What happened in the room was experienced operators using increasingly strange tools to move faster under pressure. For two days there were reporters from the New York Times sitting inside that ecosystem while some of the best operators I know showed them what did we normally do. I love NCCDC because we really go all out building tools, testing ideas, arguing about the infrastructure, then battle testing our ideas against some of the brightest in the Nation.

The agentic systems helped a lot. They also failed a lot. Sometimes within minutes of each other. That nuance matters. The agentic systems still do extremely strange, often unhinged things. But their value is obvious striking that balance is the golden mixture many people are chasing right now. After extensive testing I think it looks a little more like traditional automation, that calls out to LLMs as part of it's automation routines. This is of course opposed the claudbot or multi-agent approach that we see a lot of currently. 

To most people, a Vegas penthouse full of operators coordinating cyber attacks while journalists take notes would probably sound like fiction. By day two, for us, it was just the same war-game that we love to play. Because from the inside, after enough years, spending a weekend in a Vegas suite coordinating cyber attacks starts to feel very normal.

"Cybersecurity First Principles: A Reboot of Strategy and Tactics" by Rick Howard is a splendid attempt to boil down what is "cybersecurity" at it's fundamental level, and what are some core strategies for achieving this. If you are like me, you are probably very curious what these First Principles actually are, and you might be surprised to learn this is only one: 

"Reduce the probability of a material impact due to a cyber event over the next three years."

This year was one of the best NCCDC events I've ever played in. The environment was good. The blue teams were top-notch. The red team had new tools, old friends, and some killer 0day. Nearly every match-up turned into a long-form operational dogfight instead of a quick pop and dominate. The final standings ended up being:

• 1st place: Dakota State University
  
• 2nd place: University of Virginia
  
• 3rd place: Western Washington University

First I need to mention how sick the environment and our tooling was this year. Alex also writes about it here, but essentially it was a water treatment plant themed around some lovable pocket monsters. The infrastructure felt believable, the ICS components were integrated well, and the whole thing had a ton of personality. On top of that, White Team did something incredibly interesting this year. Going into the competition, we told them we planned to bring some legitimate 0day research targeting ESXi infrastructure. Rather than turning the event into an uncontrolled hypervisor bloodbath, White Team worked with the red team to create a controlled implant prebaked into the environment itself. Instead of live exploitation, we had an evenly deployed, pre-planted ESXi management backdoor that teams were gradually made aware of through threat intelligence notifications and environmental clues during play. It took our normal ESXi exploitation and evenly applied it to all teams, rather than cursing just a specific few teams with a significantly harder experience. Don’t get me wrong, this was very much a 'final-boss-level' computer security problem to hand blue teams. But this is Nationals, and part of the fun is keeping the threats fresh, forcing teams to deal with problems they probably have not seen before, and making sure the environment evolves beyond the standard “reset passwords and block SMB” playbook.

This year I was up against University of Central Florida (UCF), which continues to be one of the strongest CCDC teams in the country. They have an incredible program there and always present a serious challenge to the red team. UCF brings real operational maturity and professional grade tools to the competition. They come prepared with a defensive strategy that evolves throughout the event and involves adversarial strategy comparable to the red teams. They are one of the few teams that consistently adapts to the red team during play. This year was no different and I really love playing that game (it's rare). I actually figured out it was them during the competition because the epic tooling they bring comes with it's own mascot as well, SnoopyOnSecurity. They brought custom tooling including Red Baron 2, a proprietary Linux EDR-style agent that was actively identifying persistence, removing backdoors, and feeding telemetry back to defenders. They also deployed increasingly aggressive network monitoring stack known as Peanuts. As the event progressed, Peanuts passivly monitored most red team access then on day two they did a big flip to kick us out of scored services and shutdown our various c2 channels. At multiple points during the event they effectively changed the shape of the battlefield using their Palo Alto. Their ability to adapt operationally throughout the event was impressive. Most teams either collapse immediately or bunker permanently. UCF actively evolved throughout the engagement to monitor and respond to us. They hardened aggressively, deployed custom detection logic, constrained attacker movement, and thus forced the red team into progressively narrower operational paths.

While the dogfight over the individual machines continued, what actually sunk the team was the damage we were able to do their OT systems. They spent a ton of their time hardening their traditional "general computing" environment, but left their SCADA water treatment systems generally exposed throughout the life the competition. There were multiple paths into SCADA infrastructure including exposed Grafana instances, Node-RED deployments, MQTT brokers with anonymous access enabled, and just straight Modbus TCP devices with no authentication. Once access was established, operational impact became straightforward and devestating. Grafana service account tokens survived password rotation and allowed extraction of SCADA telemetry through the proxy interface. Node-RED provided command execution through malicious flow deployment. MQTT retained messages allowed persistent manipulation of the systems. And the Modbus infrastructure was particularly fragile. Several PLCs exposed unauthenticated register writes over port 1502. Continuous manipulation scripts were looped that repeatedly overwrote flow rate, chlorine values, pressure readings, pH, turbidity, and alarm states. What's even more wild is that Claude agents drove many of these OT attacks, showing that commercially available models are more than ready to attack critical infrastructure systems, given the right pretense.  

Most red teams started using the Dog-Tunnel and HyperSpace access on day 2 to attack domain controllers directly, usually by targeting DNS and trying to collapse the entire environment. My team spent a significant amount of time attempting the same thing against UCF. By that point, they had applied genuinely impressive local hardening to the DC. Application controls were tighter, local firewall rules were aggressive, and most of the blind command execution we attempted failed for unknown reasons. We could touch the system, but not in a way that let us execute anything operationally significant. I also thought if I decided to revert it, it would very quickly come back to this state and risk this amazing access I had. However the team's Achilles heel was their network configuration and architecture. Their Palo Alto appliance had become the backbone of their defensive posture. It was responsible for almost all of the network monitoring, filtering, and traffic suppression that had gradually forced the red team out of the environment. They smartly rerouted many of their machines behind the in-line Palo Alto device and used this to monitor and block lots of traffic. But the fatal flaw in this design was they placed their ESXi host controller behind this firewall (apparently because of the notifications they were getting from WhiteTeam about our ESXi exploits). I was able to revert their Palo instance to an earlier snapshot through our HyperSpace backdoor and the effect was immediate. Their filtering collapsed and the environment destabilized hard. For roughly two to four hours many of their services were entirely unavailable before they eventually appeared to hard revert portions of the environment back to an earlier state, resulting in a massive point loss. I don't think this lost them the competition, but it was certainly a great way for the red team to leverage their network architecture against them. The issue was that when it failed, it failed in a way that disrupted their own ability to manage and recover the environment. The defensive stack became a dependency instead of a resilience layer, and once the center collapsed, recovery became significantly harder to near impossible due to the remote nature.

I took a big experiment this year using an agentic swarm I made using a custom harness. I took a ton of my old techniques, broke them in agents, then fed the agents rules and skill files dynamically based on the task. I orchestrated them naively through tmux and a flat csv file system to start, which actually worked surprisingly well. I'm working on new versions now that use databases and message queues. It's super strange because it does make some stuff faster but also many normal operations can be slower. I brought a fairly mature CCDC-focused agent swarm framework into the competition. The system was designed around distributed operational assistance rather than full autonomy. Agents handled repetitive enumeration, credential validation, persistence verification, pathfinding, and operational state tracking while I focused on higher-order decisions. In some ways it worked incredibly well. The agents dramatically accelerated:

• credential spraying
• service validation
• host categorization
• persistence verification
• privilege escalation
• operational documentation
• environment mapping over time
• web app exploitation
• familiarity with lesser known systems

But the tradeoffs were real. Agentic systems introduce latency in places where experienced operators normally move instinctively. There is overhead in task routing, tokenization, querying a network service, querying an llm, result validation, and state synchronization. During the first few minutes of competition that overhead matters a lot. The result is a strange paradox. The system makes you simultaneously faster in some ways and slower in others. I think you are faster operationally across multi-hour engagements where rapid parallelization is required. However the longer the agents run the more they lose their original context and become more "unhinged". After running for several hours, they seemed to have lost track of their original agent files and thus true purpose, and the agents began drifting into one anothers' lanes. At one point, one of the agents even tried to execute some malware locally, but due to the sandboxing it was ineffective. The agents are also a lot slower tactically in the first moments of exploitation. Particularly, if you already know exactly what you want to do, then traditional automation works a lot better in many places. Essentially, while I think the agentic claude-code loop of an agent driving operations feels good, it is probably not the right long-term engineering solution. Rather, I think the more mature solution actually looks like traditional software kill-chain automation (think metasploit), that just queries an LLM when it needs to, rather than giving the agentic swarm more control. I almost certainly will follow up on these agentic thoughts soon in another post, but I wanted to get some of early operational thoughts down here. 

Hey all, I wanted to take a moment to say that I run training sessions in a variety of subjects. Not only is this an affordable way to hang out with me, it's a great way to learn a bunch of topics from me first hand. Over the years I’ve had the opportunity to work across offensive security, detection engineering, purple teaming, security engineering, large scale corporate engineering, AI systems, and competitive cyber operations. I’ve decided to open up a limited number of direct training engagements to the public, for those that want practical, hands-on instruction from someone with some deep experience in the field.

I offer both in-person and remote training sessions designed around real operational experience, not recycled certification material or generic slide decks. I've lead word class red team operations against fortune 100 companies and I've gotten real attackers indicted. I've presented to the board and testified in front of a grand jury on a cyber incident. I have a wide swath of experience with large corporate engineering challenges. 

I’m also the author of the bestselling cybersecurity book Adversarial Tradecraft in Cybersecurity, which focuses on modern offensive and defensive techniques refined through real-world network operations and adversarial tradecraft. not only that but I'm working on a new book titled AI Security Engineering that applies decade old security learnings to new LLM powered systems in a large corporate eningeering context. 

All of the courses consist of the following:

• Two 3-hour sessions
• 6 hours total instruction time
• Interactive discussion and Q&A
• Practical workflows, tooling, and operational methodologies
• Building tools and solutions live to your challenges
• Available online or onsite

The idea is an in-depth session with me where we can dig into specific material relevant to either your current problems at work or skills you want to work on improving. The sessions are really designed like educational courses to help transfer several skills and workflows I've developed over the years. The following courses are offered in either a Basic or Advanced versions. This is a lot of content that I have pre-canned, that I've developed over my career, but I can easily customize or pivot any of these sessions: 

• Building a Vulnerability Management Program
• Building Red Teaming Capabilities
• Detection Operations in Practice
• Purple Teaming in Practice
• How to Win at CCDC
• Building an Agentic Framework
• AI Security Engineering
• Zero-Trust Security Engineering

The general price is $3k* per student, per course. Prices may vary depending on the circumstance. Generally this is pricing designed for people to spend their corporate training budget but directly with me on a topic I have deep knowledge in and they are interested in. This could also be a good opportunity to spend corporate budget on some dedicated, 1:1, career coaching. One of the best parts about a training like this is we can tailor the material to exactly what you want to work on as opposed to a pre-canned course where you have to follow a conversation or program on rails. These courses are designed with some of the following groups in mind: 

• Security orgs looking to level up a team's operational capability
• Engineers transitioning into new offensive or defensive security roles
• Engineers looking to develop a 'senior' perspective or skill set
• Organizations wanting tailored, expert-led training
• Professionals using corporate education or training budgets

If you are interested in a course like this you can email me at: training@lockboxx.org 
* These prices are subject to change based on demand and circumstance

Welcome back y'all. I recently read all four of the current Black Hills Infosec Survival Guides: The Green (intro), Yellow (meta), Blue (SOC and blue team operations), and Orange (incident response) Books. The following is a quick review of all four, to see if they are right for you. Each book shares the same format: sections running 1-3 pages each, community contributor bylines, Loggy the cartoon log mascot in the margins, and a multi-page Antisyphon course catalog at the back. Once you've seen the pattern in one, you've seen the structural shape of all four. The main differences are in the focus of their contents, which you can see in their individual table of contents below. That said, the articles seem too shallow and unfocused to be practical desk references to me. As I explored all four books, I found them to contain great intro articles, but it didn't feel like they held a ton of value in revisiting. Each article barely has enough time to introduce the subject, then it has time to make about 2-5 points, which come with some heavy assumptions about how the user is operating. The end result is a bunch of introductory articles with essentially a subject intro and 1-2 nuggets of useful information. This actually lends itself best to the early articles in my opinion because it works best as an intro to Security as a whole, as opposed to technical reference or something you will revisit time and time again.

The first book in the series is the Green book, which I think was really just their first attempt at trying this, which you can kind of see later refined into the Yellow book material. Let's take a look at the contents of the green book:

• Choose Wisely
• Common Cyber Threats
• How to Set Smart Goals
• Use Your Home Lab
• OSINT
• Understanding GRC
• Malware Analysis
• Cloud Security
• Lead Effective Tabletops
• Backdoors & Breaches
• Network Engineering
• IT Help Desk
• Hire The Right Person
• Secure Small Business
• AI for Good
• Umm, Actually...
• Who is BHIS?
• Antisyphon Course List

I think this zine really is a great introduction to information security. Letting people dive into common cyber threats, setting up a home lab, helping them through early career advice is all great stuff. That said I don't think someone should be running malware only several pages after learning what some fundamental infosec threats and risks are. The Malware Analysis article assumes you already understand what a normal execution environment looks like. If you don't know that svchost.exe should always have services.exe as a parent, or why explorer.exe spawning cmd.exe is worth flagging, running a sample in a sandbox just produces output you can't interpret. You'll see registry modifications and process injections and have no baseline to compare them against. The article teaches you that the discipline exists, not how to practice it This isn't the worst if you are just getting introduced to the subject, but it can set you up for a bad time if you are actually trying to execute on these things as a novice practitioner. The OSINT article has the same problem in a different domain. Real OSINT is pivot chains, source corroboration, and knowing when you've actually exhausted a lead versus when you've just hit a wall. Two pages gets you a definition and a tool list. That's not a methodology, and a tool list without methodology is how people spend three hours in Maltego and conclude the subject doesn't exist online. I also think this is a bit of a Black Hills marketing play, as opposed to a real handbook. Don't get me wrong, there is a lot of value in these texts. But the big tell for me is in the page allocation, and we will see this again and again throughout each book. Backdoors & Breaches, a card game BHIS produces and sells, gets as much real estate as any single technical article. Often times it gets almost double the length of a normal article. The Antisyphon course catalog at the back also runs several pages. These aren't editorially neutral inclusions, they're product placements in a format that implies field reference. A real field guide doesn't sell you a companion course. 

The Yellow Book on the other hand seems to acknowledge this a little bit and be another attempt at tightening the scope. I believe this book is kind of a refinement of the Green book as there is a decent amount of overlap between the two. Each part is about 1-3 pages long:

• Choose Wisely
• 5 Phase Plan
• Quality Training
• Build a Home Lab
• To Cert or Not to Cert
• How to Get a Job
• Social Engineering
• Blue Team
• Security Operations Center (SOC)
• Threat Hunting
• Red Team
• Pentesting
• Backdoors & Breaches
• How to Tell a Client No
• How to Get a Yes
• Purple Team
• Incident Response
• Digital Forensics
• How to Write Reports
• Trials and Joys
• Mental Health
• Protect Your Privacy
• How to Put Yourself Out There
• Who is BHIS?
• Antisyphon Course List

This book honestly still comes off as a little too Black Hills skewed, and frankly a little unfocused. I was never really sure if the guide was on infosec skills, or the meta of the industry, or jobs within the industry. "How to Get a Job" and "Mental Health" are sitting in the same guide as "Threat Hunting" and "Digital Forensics." I suppose what connects them isn't subject matter, it's audience. People new to the industry who want orientation on everything at once. This also creates its own limitations though, the 'Threat Hunting' article can't go deep when the book's implicit audience is someone fresh to the industry. I think if it was more logically organized it would come off as cleaner and easier to grok. That said, I do think it's a strong resource for people who are brand new to the industry. It's a good way to orient oneself and it's a decent primer on some different fields in infosec. This again comes off as if it would be helpful for new people, but I'm not sure it's the desk reference that they were looking to make. By the time you crack open the Blue and Orange books, you've seen the pattern. BHIS has a template for each book that isn't changing. Each article runs 1-3 pages, written by community contributors, doodled over by Loggy the cartoon log mascot, and closed out with a multi-page advertisement for their training catalog and Backdoors & Breaches. These two books are the most technically focused of the series, and that's both their strength and the clearest lens through which their structural problems become visible. They are still going for the desk reference text, like a replacement for the red team or blue team field manual. I just don't think it quite nails the reference text. None of the format really feels like cheat sheets, or things I would reference over time. Rather it still feels like intro material. I think I would get the most value out of it the first time I read it or understood the ideas but not much after that. 

Let's look at the the Blue Book's table of contents:

• One Fight, Many Defenders
• The Life of a SOC Analyst
• Threat Hunter Methodology
• EDR 101
• Log Analysis Field Guide
• SIEM 101
• Network Traffic Analysis
• Cloud Basics and Investigation
• Backdoors & Breaches
• Report As You Go
• SOAR 101
• AI in SOC
• SOC & GRC
• Detection Engineering
• Application to Advancement
• John Strand's 11 Core Skills
• Who is BHIS?
• Antisyphon Class List

The Blue Book is the most focused of the four guides. The focus is clearly SOC work. It includes topics such as monitoring, detection, triage, and the daily grind of the analyst. If you're new to the field or trying to understand the SOC ecosystem conceptually, this is a genuinely decent orientation. The best articles in this book are the ones where someone sat down and tried to teach a skill rather than describe a role. The Network Traffic Analysis piece by Troy Wojewoda is really solid, sensor placement, flow directionality, east-west traffic as the canary in the coal mine. These are things a working defender actually needs to understand. And John Strand's 11 Core Skills at the tail end is probably the single most condensed piece of useful framing in the book. His point that we're training analysts to find needles in haystacks when they don't know what hay looks like is exactly right, and it's the kind of insight that belongs at page 2, not page 34. But those articles are surrounded by a lot of ambient noise. There's a lot of articles that can be read once or skipped all together. The format forces every article to stay at the same altitude, intro-level, regardless of whether the topic demands more. The biggest structural tell in the Blue Book, again is the page count. Backdoors & Breaches gets four pages, tied with zero other articles for most space. Meanwhile, articles on SIEM, SOAR, cloud security, and detection engineering only get two pages. The card game advertisement gets double the real estate as anything technical in the book. That's not a neutral editorial decision. Further, Backdoors and Breaches is largely a novelty. Don't get me wrong, it's cool they made an interactive card game and made it competitive. This is coming from an avid Magic the Gathering player. That said, I have never once used Backdoors and Breaches in a serious work scenario or in place of a real tabletop exercise. The critique is that a guide for SOC analysts is spending a large chunk of its technical page budget on a self produced novelty rather than a concrete Windows Event ID cheat sheet or an example of a SIEM correlation rule. Again this isn't something RTFM or BTFM would do. Ben Clark's Blue Team Field Manual gave you 180 pages of commands, one-liners, and reference tables.

Moving on to The Orange Book's table of contents:

• IR Manifesto
• "Goldilocks" Alert Review
• Your Critical First-Hour Response
• KAPE 101
• A Simple, Useful IR Plan
• Incident Investigations
• Hayabusa 101
• Know Your Enemy
• The MITRE ATT&CK® Framework
• Common IR Findings
• Backdoors & Breaches
• Containment & Eradication
• DeepBlueCLI 101
• Forensic Data
• Business Impact Planning
• Velociraptor 101
• Calling Reinforcements
• After the Dust Settles…
• Who is BHIS?
• Antisyphon Class List

The Orange Book is the best guide in the series. It's the one that most closely resembles what these publications were trying to be. The focus is tight, incident response from initial triage through post-incident review and several of the articles here are pretty good. The tool "101" articles are where this book earns its keep. KAPE 101, Hayabusa 101, DeepBlueCLI 101, and Velociraptor 101 all follow the same, practical structure. They are solid, usable guides. If you're a junior responder who has never run Velociraptor, you can read that article, download the binary, and run a VQL query against a process list inside of thirty minutes. That is field utility. That is the spirit of a field manual. I do wish these field guides contained more commands and maybe a few tips and tricks, but these articles are the closest thing to it, imo. One of the most shocking parts is the entire book is on the incident response life cycle but never really includes the incident response life cycle in full. There is an early article that shortcuts the lifecycle to 3 stages rather than 6. But I don't think you can teach shortcuts without first teaching the full process, otherwise you are shortcutting the lesson rather than the process. The 'Containment & Eradication' section delivers one of the most honest pieces of IR guidance in either book: disconnect the internet and rotate all credentials. "Simple doesn't mean easy." That framing is correct. Most organizations that get hit with ransomware don't fail because they didn't know these were the right moves. they fail because nobody mapped out the blast radius in advance and nobody practiced what credential rotation at scale actually looks like under pressure. The article drives this home effectively. The First-Hour Response article is the longest piece in the book at four pages (notably, the same as Backdoors & Breaches). It earns those pages. The structure, preserve evidence first, then triage, then communicate, is really good, and the escalation tiers (supervisor, security leadership, exec leadership, legal) are genuinely useful scaffolding for someone who has never run a real incident before. Incident Investigations by Patterson Cake is also strong. The MIND framework (Memory, Identity, Network, Disk) is a clean mental model for attack surface categorization, and the Windows/Linux artifact lists are the kind of concrete reference that belongs in a book like this. "Prioritize ASEPs, scheduled tasks, the MFT, and event logs" is something a responder can actually execute on. Compare that to the Blue Book's "know what's normal" advice, and the difference in operational altitude is clear. Where the Orange Book stumbles is the same place the Blue Book does, but the failures are more visible because the subject matter demands more depth. The MITRE ATT&CK® Framework gets exactly one page. One page, for a framework that entire training courses are built around. The article correctly identifies ATT&CK as a gap analysis goldmine and gives three full technique examples but then it's over. This is the exact wrong inversion: Backdoors & Breaches gets four pages; the framework that should inform every detection rule and hunting hypothesis gets one. Common IR Findings is also squeezed into a single page. It's structured around the Backdoors and Breaches (B&B) cards: Crisis Management, Isolation, UEBA, Endpoint Analysis, none of which I've ever seen as top level findings in an incident response report. These are like informational things you would bring up w/ the client, not real IR findings (like systemic malware or active attackers) which is a clever idea in theory, but in practice means the article is half-organized around teaching you about B&B rather than about the findings themselves. The marketing apparatus shapes the editorial even when it doesn't intend to. Finally they should just toss the IR Manifesto at the beginning of the book. The IR Manifesto that opens the book is two pages of "we are incident responders, we are curious, we serve and protect." It reads like the kind of thing you read at a conference keynote and then forget on the drive home. It takes up space that could have been a triage checklist. It's largely useless and no one is even remembering it, let alone ever repeating it.

The Blue and Orange books are the best two in the BHIS Survival Guide series, which is both a compliment and a qualification. The Orange Book in particular has genuine field value, primarily from the tool 101 articles and the Incident Investigations MIND framework. If you're a junior IR analyst who has never touched KAPE or Velociraptor, this book will save you time. Overall these books are more like intro texts for someone totally new to the topic. The Blue Book is a decent orientation for someone entering the SOC world, but it's more of a career primer than a field guide. John Strand's 11 Core Skills is the article everyone should probably read in my opinion. Neither book is what the RTFM/BTFM was. They don't have the density, the command-line specificity, or the format-as-function that made field manuals like the RTFM genuinely reference-worthy. They're closer to a well-curated blog anthology, which is essentially what they are, because the model is community contributors writing 2-page articles. That's not a bad model for building an audience and generating content at scale. But that model has several drawbacks. The most noticeable drawback to me is there is very little cohesiveness between the articles. Some articles approach the defensive posture like a SOC analyst looking at a well instrumented environment, and other articles approach the subject like a researcher or hobbyist working on single log files or samples. Worth buying at the paper price point for someone new to infosec? Sure, these are good and cheap zines to read if you are new to infosec. Is this worth buying as a desk reference or as a seasoned infosec practitioner? Check out the pdf and you can probably skip the hard copy. Think of them as a well-intentioned sampler platter, it's little nuggets of each idea to expose you to a topic. It's great for new people, but the value rapidly diminishes the longer you've been in the industry.

TL;DR Don't run random "games" sent over Discord, even from friends. Even if they're hosted somewhere that looks legitimate. Google it. Upload it to VirusTotal first. The campaign we are going to look at today steals credentials, crypto wallets, and browser sessions, then spreads through the compromised accounts it just emptied. We are going to look at Myth Journey or https://myth-journey.com

If you already ran it skip to the bottom, to "If You Ran It" immediately.

A friend messages you on Discord.

They want you to test their game.

You run it. Nothing happens.

48 hours later, your accounts are gone.

This is already happening. The Myth Journey campaign is active as of April 2026, and it costs the attacker nearly nothing to operate. I learned about it because my personal friend was compromised and asked me to "test his new game". Talk about sending your malware to the wrong person.

The Myth Journey landing page at myth-journey.com runs on Vercel's free tier, the same platform used by thousands of legitimate developers. The payload is hosted on GitHub Releases, with gofile.io as a fallback. The installer is 86 MB, indistinguishable in size from a real game download. Every piece of this sits on infrastructure the attacker didn't build and doesn't pay for.

The underlying malware, Myth Stealer, is sold as a subscription service on Telegram, payable in crypto and Razer Gold. A buyer doesn't write code. They pay a fee, get access to a builder, and assemble their own delivery chain. The Myth Journey campaign is one operator's version. There are others running parallel variants under different names with the same payload kit.

The result is a fully functional, professional-looking attack with near-zero overhead. A GitHub link or a Vercel URL is not a trust signal. The HTTPS padlock, the polished page, the fast download speed, none of these mean anything.

Everyone wants to play new games with their friends. Especially games their friends wrote. But your friend didn't send you that. Their hijacked account did.

Discord tokens, the session credentials that keep you logged in, are a primary target for this entire malware category. Once stolen, a token gives an attacker full account access without the password, without triggering 2FA. They can read your message history, understand your relationships, and craft targeted messages that fit the conversation. The account looks and sounds like your friend because it has your friend's entire history to draw from.

The lure is a game because it's plausible. Indie development is common. Beta testing is expected. The ask is small. There's no obvious red flag in the request itself, which is the point.

The download page adds one more nudge. The instructions read: "do not extract the ZIP file and run it in the zip for the best experience." That's not advice, it's an anti-inspection technique. The instruction discourages the one thing that might reveal what's inside before you execute it.

If anyone on Discord asks you to run a game or an installer, verify through a second channel before you do anything. Call them. Ask what the game is about. A stolen account cannot answer that question in real time.

Here is the full execution sequence, based on direct binary analysis and sandbox observation of our exact sample.

"MythicJourney Setup 1.1.2.exe" is an 86MB NSIS self-extracting installer, the same format used by Notepad++ and VLC. It shows a progress bar. It looks like every other installer you've ever run.

SHA-256: 1567e11339c9dd227691111007a2021a90195f28a1d4b7766c1baee961953324

The PE header checksum is zeroed. The compile timestamp reads 2018, a seven-year-old NSIS stub, reused because the timestamp mismatch confuses automated triage. The 86 MB of malicious content doesn't live in the standard PE sections at all, it's compressed in the overlay, invisible to plain string scanning. This malware hides its real payload so well that basic antivirus tools don't even see it. AV detection at time of analysis was effectively zero.

Inside the compressed overlay:

• app-64.7z - an 85 MB archive containing a complete Electron application (the actual stealer)
• Five other NSIS plugin DLLs for extraction and execution
• A fake uninstaller for cover

The install sequence:

1. NSIS decompresses everything to "%TEMP%\nsd557A.tmp\"
2. Installs the Electron payload to "%LOCALAPPDATA%\Programs\MythicJourney\MythicJourney.exe" 
3. Drops a persistence copy to "%LOCALAPPDATA%\mythicjourney-updater\installer.exe"
4. Then deletes the temp directory.

MythicJourney.exe is a full Electron application, the same framework used by VS Code, Slack, and Discord itself. Packaging a stealer as an Electron app is deliberate. It looks like legitimate software, behaves like legitimate software, is interpreted at runtime, and its network traffic looks like legitimate software.

The bundled native addons tell you exactly what it's after:

The stealer logic lives in a single 2.9 MB JavaScript file (main.js) inside the Electron application archive. It is layered three levels deep.

The outer layer uses a custom base91 encoding scheme: 321 string table entries, shuffled by a rotation function, the entire script wrapped in an obfuscated Function() constructor so nothing executes or resolves until runtime. No plaintext URLs. No IPs. Nothing for a scanner to catch.

Decoding that reveals an AES-256-GCM encrypted second payload embedded directly in the file:

Key:   26303b532115653c49f950999fa94f1af5abb94a8f39b113e102025adbc6ba4b
Nonce: 74fa957219626ffb885f5aec

Decrypting yields 1.1 MB of a second obfuscated JavaScript payload, itself with 679 encoded string table entries and state-machine control flow. The only thing that leaked in plaintext was the module list passed to require() — "axios" (HTTP client for C2), "crypto", and "bytenode" (bytecode loader, likely a third stage we haven't reached). The C2 address is still locked inside those 679 encrypted strings.

NSIS installer (86 MB)
  └─ app-64.7z (Electron runtime)
       └─ app.asar → main.js (basE91 obfuscated)
            └─ AES-256-GCM decrypt → stage2.js
                 └─ [bytenode .jsc] → possible Stage 3

I also uploaded a sample to VirusTotal for their sandboxes and HybridAnalysis. HybridAnalysis was good at teasing out the various layers of anti-reversing at play. Before touching credentials, the payload verifies the environment. It spawns 17+ PowerShell instances and queries system hardware, disk drives, BIOS, motherboard, RAM, GPU, monitors, then runs explicit evasion checks:

• "(Get-CimInstance Win32_ComputerSystem).HypervisorPresent" — are we in a VM?
• "[System.Windows.Forms.SystemInformation]::TerminalServerSession" — are we in an RDP/sandbox session?
• "echo %COMPUTERNAME%.%USERDNSDOMAIN%" — are we on a corporate domain-joined machine?
• "WHERE smartctl" — are disk forensics tools installed?

It immediately kills watcher.exe and mitmdump.exe, common dynamic analysis and MITM proxy tools, by name. If something is watching it, it kills the watcher.

The sandbox we submitted this to scored it 100/100 malicious.  But AV marked it clean at runtime! That gap is the entire point of this evasion layer.

With the environment cleared, the payload:

• Opens a handle to "lsass.exe", the Windows process holding cached authentication credentials in memory (NTLM hashes, Kerberos tickets)
• Injects 4,024 bytes into 18 PowerShell processes, with PAGE_GUARD memory protection on the injected code to block memory dumping
• Reads "desktop.ini" from every user shell folder (Desktop, Documents, Downloads, Music, Pictures, Videos, OneDrive), mapping the filesystem for data staging
• Attempts to access "%APPDATA%\EXODUS\EXODUS.WALLET\SEED.SECO", the Exodus wallet master seed phrase
• Decrypts browser credential stores via DPAPI and reads browser SQLite databases directly
• Packages everything into an encrypted archive for exfiltration

It's suspected that the C2 communication goes out over TLS:443 to CDN-fronted endpoints (104.16.124.96 on Cloudflare and 142.251.210.35 on Google's network). These are not the attacker's servers, they're CDN edge nodes. This enables the C2 to automatically rotate IPs without touching the malware binary and the network traffic is indistinguishable from normal HTTPS to Google.

The runtime also installs a certificate into the Windows certificate store, allowing its own TLS to be trusted without triggering OS warnings.

Assume full compromise. Don't spend time figuring out what was taken, move immediately.

1. Change every password from a clean device.
2. Revoke all active sessions: Discord, Google, GitHub, any financial service.
3. Enable hardware 2FA: TOTP app or phone verification minimum
4. Regenerate cryptocurrency wallets from a clean seed on a clean machine, then move funds before anything else.
5. Delete "%LOCALAPPDATA%\Programs\MythicJourney\" and "%LOCALAPPDATA%\mythicjourney-updater\"
6. Check "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup" for unexpected shortcuts
7. Report "github.com/ryprs" and "myth-journey.com" to GitHub and Vercel abuse teams

The attacker who built this campaign is almost certainly a MaaS customer, not the malware author. The author sells the kit; operators build their own delivery chains. The same payload runs under different names in parallel campaigns. If a friend on Discord asked you to test a game and something feels off, their account may already be hacked.

"Agentic Artificial Intelligence: Harnessing AI Agents to Reinvent Business, Work, and Life" by Pascal Bornet. This book was written at the very beginning of the agentic AI wave, looking at early adopters of using LLMs in agents to have generic language models drive computer tools. It has some great lessons learned on implementing agentic systems, but it’s largely non-technical, likely because it was written before these systems became standardized.. I listened to this on Audible at about ~$15 for roughly 10 hours (on 1.5x speed).  At nearly 500 pages it's a pretty heavy read, although I personally found the first two parts the most impactful in terms of AI theory and implementation insights. The final three parts shift toward business building, enterprise adoption, and long-term societal impact. While the end of the book seemed to depart from reality a bit (talking about Universal Basic Income once agents take over the majority of jobs), I thought the beginning was fascinating and eye opening in terms of planning and reasoning with agents. Overall I'm going to give this 5 out of 10 stars. I recommend this to people wanting to get more theory and guidance when building out agentic systems, although I'm not sure I would recommend this if you were looking for a technical book. The book has no real mention of actual technology needed to implement these ideas. There is almost no mention of specific models, structures, or even the types of agents that could be run to automate these goals. In that sense the book left a lot to be desired, it was almost purely theory.  That said, I did enjoy the first two parts of the book. The following are the chapters of the book so you can get a better idea of it's contents before picking it up:

Introduction
Part 1: The Rise of AI Agents
Chapter 1: Beyond ChatGPT: The Next Evolution of AI
Chapter 2: The Five Levels of AI Agents: From Automation to Autonomy
Chapter 3: Inside the Mind of an AI Agent
Chapter 4: Putting AI Agents to the Test
Part 2: The Three Keystones of Agentic AI
Chapter 5: Action: Teaching AI to Do, Not Just Think
Chapter 6: Reasoning: From Fast to Wise
Chapter 7: Memory: Building AI That Learns
Part 3: Entrepreneurship and Professional Growth with AI Agents
Chapter 8: A Practical Guide For Building Successful AI Agents
Chapter 9: From Ideas to Income: Business Models for the Agent Economy
Part 4: Enterprise Transformation Through Agentic AI
Chapter 10: Human-Agent Collaboration: Leadership, Trust, and Change
Chapter 11: Scaling AI Agents From Vision to Reality
Chapter 12: Case Study and Use Cases of Agents Across Industries
Part 5: Future Horizons For Work and Society
Chapter 13: The New World of Work
Chapter 14: Society in the Age of Agents
Conclusion

I struggled with parts of the book, because it repeatedly argues that agents should take action, but rarely explains how that action is implemented.. Should agents be calling APIs in a microservice architecture, or should we be giving agents full control of systems with local tools like ClawdBot? Is it better to give agents skills on how to use specific tools, or should we continue using MCP servers for up-to-date information on the tools? There is a ton of implementation details the book conveniently glosses over. The book also glosses over memory in a similar way, which in my experience if done wrong can make an agentic system much worse. Memory has lots of core questions, like storage location and structure, as well as retrieval quality and embedding limitations. It's a pretty hard thing to get right, so I'm surprised it didn't dive into any of the technical edge cases there. One technique the book does mention in depth is using an extensive RAG library or even a wiki or onboarding documents to support the agentic system if it needs to lookup context or understanding around a process. The book is also very idealistic. From it's estimations on agentic reasoning capabilities (nearly a year after it was written and these models still make regular mistakes) to it's predictions around Universal Basic Income when many common jobs are automated, it honestly makes me a little worried what a more grounded future might look like when I see these as proposed solutions. 

Welcome back Internet people! Lately I've seen a rise in AI generated articles, blog posts, and even book content. I need to say loudly, as a reader, this is a major turnoff. If a reader can tell that something was written by AI, then the tools are being used poorly. Please don’t pass off LLM output directly as human writing. It makes your work output feel cheap. AI should be used as a writing tool, it shouldn't be replacing human writers altogether. 

When writers use LLM output verbatim the result is often stale and lacks clarity. In many cases, it actually makes ideas harder to understand. Current LLMs struggle to maintain consistent, logical models of complex ideas. So while the writing may sound polished at first, it sometimes misrepresents concepts or drifts into conflicting, multiple definitions. Moving past the coherency issues, it's often obvious when a writer has an overreliance on verbatim LLM output. There are many obvious tells. From the overuse of the em dash, to the nonsensical use of the colon; AI generated content sticks out to those who use frontier models often. Certain phrasing patterns also stand out. For example: “It’s not X, it’s Y.” As a writer, this often feels like filler. Just write about Y. Just because these are the current form of these tells doesn't mean these are universal or ubiquitous tells. Quite the opposite, these will change over time as the models change, but the heavy users of the models will very likely recognize their output when used verbatim. 

Don't get me wrong, I'm not saying don't use LLMs to help you write. I previously wrote about how to use AI in your technical writing, such as creating templates, voice files, and dynamic prompts to generate rich content. It also makes for a great editor! But one of the key takeaways there is in the last paragraph, where I emphasize heavily modifying and adapting the output. You can't use the output verbatim; frontier LLM output is just too recognizable. 

I recently read this great and thoughtful article titled "Don't Let AI Write For You", where Alex Woods lays out that the point of writing is to develop and cement thoughts worth communicating, not simply generating words or content. I couldn't agree with this more. I often use LLMs to help expand on ideas, or think about edge cases I might be considering. I use it to help me refine my writing prompts and generate starting points. But very rarely do I use the ideas or output verbatim. It's an incredibly useful tool, but in my opinion it shouldn't replace the art all together. 

So I'll repeat it, and I hope somewhere out there other writers take it to heart. When writers use LLM output verbatim it comes across as incredibly lazy. And frankly, why would anyone read that? A reader could just prompt the model themselves and get the same result.

Last year a few of us in infosec met up for the National CCDC competition and did some LLM research while at the competition. We gathered data from both the defenders and the attackers on their ussage of LLMs and how well the technology aided them in the competition. This research goes on to show that these LLMs really aren't helping the blue teams, especially when paired with the evolutionary direction i've seen ALCCDC go. We can see a clear bias towards tools like Claude Code enabling offensive tool development and helping attackers, to the extent that the agent swarm will activly hack for the attacker, whereas the blue teams are struggling to get simple questions answered from LLMs like ChatGPT for the fear that the information may be abused. 

What we found became the basis of our research on Defensive Refusal Bias, but the story has only gotten more interesting since then. During the competition we collected thousands of real prompts from both blue and red interacting with LLMs. The results showed something counterintuitive: modern safety-aligned models were far more likely to refuse legitimate defensive questions than they were to block creative offensive questions. Blue teams trying to analyze malware, harden systems, or investigate suspicious processes were frequently blocked because their requests looked “too much like hacking.” Meanwhile, attackers could often get what they needed simply by framing their prompts as experimentation, scripting help, or development work.

Fast forward to spring 2026, and the gap appears to be widening. After just completing events like ALCCDC last weekend, tools like Claude Code are rapidly evolving into autonomous agent swarms, capable of developing deep offensive capabilities, writing exploit scripts, chaining reconnaissance tools, and iterating quickly on offensive tooling. Not only that, with some clever prompting and abstraction, Claude Code will drive an offensive agent swarm as an operator, doing fully automated hacking and post-exploitation of victim systems. In practice, what this means is that attackers can now spin up something closer to an offensive agent collective, a set of automated assistants that will explore systems, write exploits, refine attacks collaboratively, and move to post exploitation activities. They will also leverage their own post exploitation for creative attack chains moving forward. Instead of just answering questions, the model increasingly acts as a co-developer and operator for offensive tradecraft, where defenders are getting stopped when asking simple analysis questions.

Defenders are often stuck fighting the safety rails. Ask a model to help analyze a piece of malware or break down how an exploit works, and there’s a decent chance you’ll get a refusal or a heavily sanitized answer. The irony is hard to miss: the same guardrails meant to prevent misuse are often slowing down the people trying to defend systems, where the attackers are using the readily available, professional models today at blazing speeds to auto-hack. 

This was another amazing year for At Large CCDC, or Virtual CCDC as I've come to call it. We had our event this last weekend, Feb 28th and March 1st. I lead the red team again this year (last year's writeup faithful reader) and the core CIAS team hosted the environment for teams to attack/defend. Overall the competition was intense and engaging. We had 5 blue teams this year and just around 10 individual red teamers. We played zone, in the sense that we essentially hacked across all the teams in an equal manner, targeting specific services with sweeping exploits and laying down equivlent persistence. This is opposed to "man-to-man" or playing in a way where we pair specific red team members to specific blue teams, much the way we do nationals. 

This year Dakota state won again. It wasn't even really that close, they are getting really good. I would go out to say Dakota state dominated, playing a near perfect game relative to the other teams. I would also say the remaining teams were fairly closely grouped, with the next two teams being fairly equivalent in the middle, and the last two teams being fairly equal in last. I would argue the other teams should do their best to learn from the DSU playbook, because it is a winning model. They have a ton of infra for hosting your own CCDC-style attack and defense competition. There are a ton of great resources there for up-ing your personal game and emulating the way DSU plays. 

On to what I really want to write about from a pentest perspective. The competition is becoming dominated by AI written tooling, agents, and agent swarm pentesting. I'm not convinced yet, often times these tools are much sloppier, more reckless, and harder to control. If you thought pentesters were reckless and hard to control these agent swarms are so much worse. They also do incredibly obvious and silly things that will easily get caught, in an adversarial competition you can't really afford to make those kinds of silly mistakes. One person suggested it was because these haven't been post-tuned in a real world environment and thus were not battle tested. I would need to see these things get remarkably better from an operator perspective before allowing them again, they often don't apply attacks evenly or fairly which is a key feature of our red team at CCDC. Further, I wonder if they could understand how well a blue team is doing and adapt their attacks to level of skill. Regardless, it's a trend I want to comment on. From what I’ve observed so far, AI-enabled pentesting tools generally fall into two categories.

1. AI-Assisted Tool Development

The first approach uses AI like Claude Code to help write pentesting tools. Operators prompt a model to generate scripts, exploit logic, automation helpers, or reconnaissance tooling. The human still controls the attack, but AI accelerates the process of building the tools. Sometimes the model is helping set up the project directly, but I find it's often more productive when the human does the architecting and guides the features they want, and simply uses the AI to script the advanced features, like an LKM in-memoery loader, or similar features, as opposed to using the LLM to guiding those features. These systems tend to work quite well. In fact, some of the most interesting tooling I’ve seen recently has come from this approach. You get creative automation and rapid tool development without sacrificing operator control. This results in stable tools are develop quickly with extremely powerful features. 

2. AI-Pentester Operator Agent Swarm

The other approach I've seen uses AI agents that do the cognition and drive the tools. These tend to be more unhinged, and I imagine burn thousands of tokens just in the cognition of the attacks, which feels like less sustainable than using the tokens to write the tool. These are the systems that tend to behave the most erratically. Even the agent swarms that abstract the cognition through layers of agents have issues, such as sub-agent permissions, logging, runaway tasks, emergent behavior, and several other operational challenges that become very apparent once these systems are running in a live adversarial environment. I think a lot of the Claudius experiments show this, as powerful, amazing, and fast as the agents are they just aren't there yet in terms of planning and metacognition. Models are almost always better when you give them very narrow tasks, and thats what the agent swarm attempts to do, break up the the scope of the tasks into smaller, and smaller context windows of focused tasks. On top of that, the second approach feels like it just burns tokens in a crazy way, especially when the agent swarm becomes misfocused or off-task. 

I will have a lot more thoughts on these tools and this evolution of pentesting in the coming weeks to months. Stay tuned and let me know in the comments if you have thoughts or find this content interesting

We just wrapped this year's 'Mile-High' Wild West Hacking Fest. This was my second time attending the Denver event (distinct from the Deadwood conference), and the growth year over year has been impressive (read about the first one here). It keeps the laid-back, community-driven vibe that made it great to begin with, but the conference experience itself has leveled up in a big way. I personally like this one (over Deadwood) as I think it's much more accessible in downtown Denver, although I've never actually been to the other event. There are so many amazing features of this conference I want to highlight. 

To start, the conference app deserves a callout. It’s wasn't just a flat / static schedule, you can browse, and even watch presentations streamed live. If you can’t physically make it to a session, you can still follow along. That level of accessibility really sets it apart. They also run an active Discord server with dedicated channels for every track, workshop, and game. Slides get shared in real time, and conversations continue well beyond the talk itself. It makes Q&A more engaging and helps you connect with other attendees organically. I even joined a pickup team through Discord to compete in a CTF later.

I definitely want to highlight the pre-conference training as it was amazing. You can read my review here. Not only do they offer dedicated training before the conference, but the trainings are also streamed over the app. There are also free workshops during the event that anyone can drop into. And the content spread is excellent. There are advanced sessions diving deep into topics like shellcode curation, alongside beginner-friendly talks and workshops for those newer to the field. It was nice to see the conference strike more of a balance this year. 

Speaking of a better skill spread, there were three CTFs this year and felt like something for everyone. There was an intro CTF, an electronic badge challenge, and a full Attack/Defense competition. I think this was really nice as people could engage at any level of experience.  Beyond the talks and CTFs, there’s was a very lively vendor area, plus some seriously fun lockpicking challenges. The speed-picking competition alone is worth watching as people get intensely competitive.

It also still feels really small. With roughly 300–500 attendees across just two floors of a single hotel, it feels intimate and approachable. You can strike up conversations with speakers, organizers, and fellow attendees without fighting crowds. It reminds me of the old DerbyCon days, tight-knit, accessible, and community-focused, but with even more structured content and activities.

If you’re looking for a conference that combines strong technical content, hands-on activities, real community engagement, and a relaxed atmosphere, you should seriously consider going to Mile-High Wild West Hacking Fest, It’s one of the few events that still feels small in the best possible way, while delivering a big-conference experience.

I recently took an Antisyphon training, Breaching the Cloud With Beau Bullock, at the Mile High Wild West Hacking Fest 2026. I thought this was a fantastic training for intermediate infosec practitioners, and want to detail a few reasons why. The training was very cheap compared to other industry trainings, with most SANS or black hat trainings ranging from 2-5k. This course comes in around $575 which makes it similar to trainings like The Certified Cyber Defender in terms of price and access (its also available on demand). That alone makes it accessible in a way most “elite” trainings simply aren’t. You do get a certificate of completion for this, but unlike the CCD because there is no exam it doesn't hold too much weight in terms of a verification that the person knows the material. That said, certificates are always nice to get along w/ the sticker price. One aspect I wanted to callout is that Beau goes pretty fast through the content, and there is a ton of content. There are over 420+ slides and 18 hands-on labs throughout the course. The course is only 2 days of in-person, so I get why he has to go fast. Personally, I like it because it is enough to cover the material but let students dig in on their own time if they want more. As a pretty experienced infosec practitioner, a decent amount of the material was also review for me, so it was nice to rip through it from that perspective as well. The material is modern and relevant, comfortably within the last 2–5 years of cloud pentesting tradecraft. This isn’t recycled theory or checkbox cloud security, the course is packed with high-impact tools and techniques for initial access, cloud-native reconnaissance, lateral movement, and privilege escalation across real cloud environments. The course is dense with practical tooling and techniques: tons of scanners, identifying cloud-native weaknesses, pivoting through an organizations roles, and understanding where identity and access failures really hurt. There’s very little time wasted on low-impact “cloud vulnerabilities” that look scary in a scanner report but don’t meaningfully move an engagement forward. This is another great review that really encapsulates that, "You're paying for the experience of the instructor", not simply more rote pentesting content. And Beau is one of the best operators that has been doing this for several decades, so his hands on experience really cuts through a lot of the fluff out there. In my typical review style, the following are the hands on labs in the course to help you get a better understanding of the content:

• Lab 1: S3 Bucket Pillaging
• Lab 2: Password Spraying
• Lab 3: Pillage Code Repos for Secrets
• Lab 4: Microsoft Device Code Phishing
• Lab 5: Azure Situational Awareness
• Lab 6: Backdooring an AWS Account
• Lab 7: Azure Service Principal Backdoor
• Lab 8: Using AzureHound to Find PrivEsc
• Lab 9: AWS Privilege Escalation w/ Pacu & Obtaining Web Console Access
• Lab 10: ScoutSuite AWS Scanning
• Lab 11: Screenshot Web Services
• Lab 12: Exploiting SSRF to Gain IAM Keys
• Lab 13: Extract Password Hashes from VM Storage
• Lab 14: Dumping Azure Key Vaults
• Lab 15: Exploiting Amazon Elastic Container Service (ECS)
• Lab 16: Exploiting AWS Lambda Functions
• Lab 17: Azure App Services Phishing w/ Illicit Consent Grant
• Lab 18: ROADTools Entra ID Analysis w/ CAPS

The course has a big focus on both Azure and AWS. Many cloud classes go deep on a single provider and leave students mentally trapped there. This one does a good job showing the parallels, how the same underlying identity, application settings, and misconfiguration patterns appear across cloud platforms. I found there was a decent bit of overlap with FalconForce's "Advanced Detection Engineering in the Enterprise", in terms of some of the offensive cloud techniques presented, although that had more of a focus on the defensive techniques and it was only looking at Azure. I really like that the course gave you a lot of custom terraform such that you could host the testing environments yourself. You’re not just clicking through someone else’s pre-baked lab, you’re learning how these environments are actually built, broken, and you could even fix the vulns yourself. The course also heavily leveraged CloudGoat for some terraformed vulnerable cloud environments, which is an absolutely fantastic project that I also leveraged in CPTC2023 and while training for my AWS Cloud Specalist cert. The class even covers many parallels with GCP, although it doesn't have us host any GCP infrastructure to pentest. There’s also strong coverage of cloud-to-on-prem and on-prem-to-cloud attack paths, which is where real organizations still get burned. This isn’t cloud-in-a-vacuum theory, it’s hybrid red teaming grounded in real world examples. While the course doesn't implement a ton of best practices in it's own lab setup, Beau makes a point of highlighting good cloud theory in terms of the envs we are pentesting and the recommendations. The labs modeled proper group structure and role assumption workflows the way large organizations actually operate. The slides also cover the use of secrets managers and key vaults instead of hardcoded credentials or lazy storage patterns. Theres also a ton of coverage on cloud specific technologies, like writing security policy in AWS or leveraging Entra ID for better subscription management. 

Ultimately, I highly recommend this course for both the price point and the instructor. The emphasis stays squarely on high-impact red team tradecraft: identity abuse, role chaining, secrets exposure, cloud-to-on-prem boundary crossing, and realistic privilege escalation paths inside mature environments. These are the techniques that materially change the outcome of an engagement. They’re practical, repeatable, and aligned with how real organizations actually operate. There’s a noticeable absence of fluff. The content doesn’t wander into obscure edge cases or theoretical attack paths that rarely survive contact with production environments. Instead, it concentrates on methods that consistently produce leverage. That curation is intentional and it reflects experience. When an instructor has spent decades operating in the field, the signal-to-noise ratio improves dramatically. You get the attacks that work, the patterns that scale, and an understanding of cloud patterns that comes from doing the job repeatedly.

Some of the best, and most practically useful, content for red teamers appears in the chapter on Brush Contacts, in my opinion. These sections contain genuinely useful ideas and were one of the main reasons I picked the book up after thumbing through it. Tips such as waiting near elevator banks, escalators, or bus stops can be genuinely effective locations for brush contacts or even cloning physical access badges. This chapter, along with others like the one on dead drops, really emphasizes that parts of the book are grounded in real-world experience. Unfortunately, that grounding is undermined by the nearly 50+ pages devoted to improvised weapons and hand-to-hand combat, which make the book feel unrealistic and far more like Hollywood spy fiction. Don’t get me wrong, this approach probably sells well to the uninitiated. But real intelligence work is often incredibly boring. It usually involves observation, pattern tracking, and note-taking week after week, with very little actually happening. Most agents never want to engage in physical altercations, and many would consider a mission compromised if one occurred at all. That said, there are some good or common-sense tips scattered throughout the book. The guidance on remaining inconspicuous is fairly solid: things like wearing non-distinct clothing, never running, avoiding looking over your shoulder, and minimizing unnecessary interactions. The advice to change your outfit and approach routes when revisiting a location for reconnaissance is also sound. Still, the majority of the book feels like it’s pretending to be an action-movie secret agent manual rather than providing skills actual agents would find useful. I was also surprised by the near total absence of computer skills or technical tradecraft, especially given how central cyber operations are to modern intelligence work. No video for this one, just a friendly reminder that overly flashy and embellished techniques are rarely as real or practical as the boring, non-sexy ones. You should always be wary of anyone claiming to do intelligence work while presenting it like they’re some kind of 007.

I recently passed the Certified CyberDefender (CCD). Ultimately I think there is a lot of value in this certification and I think it finds a unique spot within the industry. If you treat CCD as a hands-on validation of blue-team and DFIR skills, it performs well. It's almost like a blue team version of the OSCP, which is funny considering the slogan on the challenge coin is, "Defend Smarter, Not Harder" (vs the classic offensive slogan, "Try Harder"). The combined cost of the labs and exam are approximately $499.99, which I consider very reasonable given the scope and hands-on nature of the material. I spent roughly one week reviewing the course content, followed by four additional days working through labs before attempting the exam. However this may be an accelerated rate for people that are newer to the subject material. The exact contents of the course is here, so you can make sure this specific skill development is what you are looking for.

From a return-on-investment perspective, the labs alone justify the price. Even experienced practitioners will find value in the scenarios, tooling exposure, and repetition across environments. The scenarios require investigation, hypothesis testing, and iterative analysis, much closer to real SOC or DFIR work than most other certifications. If you approach them like a real incident, with partial visibility and incomplete information, they feel authentic and worthwhile. I also like how most of the training has detailed instructions, followed by videos demonstrating the techniques, and finally a lab environment for participants to then try themselves. That said, some of the material and theory leaves a bit to desired. I wrote about some of this in my IR review, I'm talking about getting basic formulas for Risk incorrect or muddling the incident response lifecycle. The full course has similar issues, for example it instructs students to perform live response exercises like log collection and live system triage before capturing memory. In my experience you always want to capture memory first before running more live response tools as they can push evidence out of memory.

Still I thought this exam was great. I like the 48 hour nature of the exam, as well as the multiple sections and environments. This kept it fresh, if I got bored or stuck in one area it was easy to pivot and keep solving challenges. I also appreciated that the exam didn’t artificially gate progress behind single points of failure. My bottom line on this is that the exam is solid for testing hands-on forensic competence across multiple domains. The labs and exam are well worth the time and cost, and the exam format is among the better designs I’ve seen for blue-team certifications.

"Good Strategy / Bad Strategy" by Richard Rumelt is one of the clearest distinctions on what strategy is not that I've encountered. Its very illuminating for anyone caught in melancholy of normal corporate planning cycles. It's a very solid book on how to avoid bad strategy or what the difference is beyond just goal setting. This book attempts to answer how we carve real strategy out of our strengths and opportunities. It tries to take on the challenge of how we get an advantage when accomplishing our goals. One of the classic pitfalls in planning is simply setting forth a dog's dinner in terms of objectives that are hard to hit and don't lend themselves to any type of advantage in that work. I listened to the book on Audible for over 10 hours at essentially $15 or 1 credit. Overall I give it 6 out of 10 stars, for being eye-opening but ultimately lacking to build a clear path out of it's own problem statement. I recommend it to anyone involved in strategic planning or planning in general as I think it is valuable recognizing bad strategy at play. Despite my criticisms that the book doesn't help prepare a strategy, knowing what not to do actually greatly improves the planning process. The book really succeeds in sharpening your strategic eye. Even if it doesn't lay out a methodical process for carving out strategy, it does make you question the effectiveness and strategy of your methods, forcing you to re-evaluate until you land at a better place. In that sense, it really lends itself to red teaming your strategy, looking at it from multiple perspectives and finding both advantages and weakness in the approach. In my typical style, the following are the chapters of the book:

Introduction: Overwhelming Obstacles
Part I: Good and Bad Strategy
Chapter 1: Good Strategy is Unexpected
Chapter 2: Discovering Power
Chapter 3: Bad Strategy
Chapter 4: Why So Much Bad Strategy?
Chapter 5: The Kernel of Good Strategy
Part II: Sources of Power
Chapter 6: Using Leverage
Chapter 7: Proximate Objectives
Chapter 8: Chain-Link Systems
Chapter 9: Using Design
Chapter 10: Focus
Chapter 11: Growth
Chapter 12: Using Advantage
Chapter 13: Using Dynamics
Chapter 14: Inertia and Entropy
Chapter 15: Putting it Together
Part III: Thinking Like a Strategist
Chapter 16: The Science of Strategy
Chapter 17: Using Your Head
Chapter 18: Keeping Your Head


The book shows a lot of anecdotal examples of strategies that don't work. The book is big on calling out the misnomer that strategies have been set or applied when in reality there is no actual overarching strategy. The book talks about the active planning cycle and setting conscious thought into how to go about thinking or planning not just accomplishing the goals. I actually thought this was a little too anecdotal. I would have preferred a more repeatable approach to carving out strategies from planning routines. I would have preferred tips and tricks to analyzing a situation for an an advantage, perhaps some principles that could be leveraged in the planning process to better one those muscles or efforts. The book showed me a lot of what not to do, but left me wanting in terms of how to actually plan and formulate an advantage in a scientific way. Ultimately, the book showed more of what not to do, rather than what to do, which still had a ton of value in terms of planning. While the book also anecdotally mentions some entrepreneurs who found great strategic success in iterating or experimenting on their ideas, the book also downplays these motions as a tactic for refining and battle-testing a strategy. The role of experimentation, iteration, and feedback loops can't be understated in domains that require strategy to win. Further, there is often an adversarial component involved in domains where strategy matters more than an engineering plan. In those environment especially it is important to make sure your strategy remains dynamic and adaptable to environmental or situational feedback. If something works or stops working listening to that feedback can be some of your biggest strategic advantage in some environments.  The following is Richard discussing strategy on a podcast. Some of the concepts in the interview come from his newer books, but the interview is great so enjoy!  

This review is only for the Incident Response module within the Certified CyberDefender course and labs. I plan on doing a full review of the course and certification after I take I sit for the test, but in the mean-time this a review of just the Incident Response Module, in the Optional Modules section. To be honest, this module is why I purchased the course in the first place, as I was looking for an Incident Response primer to roll out to my teams at work. TL;DR this specific module is not great, there is a lot that seems contrary to common cyber security advice, which I break down briefly in this review. While this entire training may prepare a SOC analyst for their day job, I wouldn't say this IR module would prepare someone for an actual Incident Response. To be honest, I found the incident response module very lacking, both wrong on several traditional definitions, as well as not as focused in terms of tradecraft, as I would like to see. As a result I am writing my own training for the team in conjunction with several industry peers, but i wanted to call out several of the reasons I wouldn't use this module as a formal training.  Lets start w/ some of the most egregious examples of getting traditional definitions wrong. Very early on in module they have a formula for Risk that seems very wrong. 

They state: 
Risk = Threat x Vulnerability
However the traditional equation from the field of Risk Analysis is:
Risk = Likelihood x Impact

It's a very weird definition to change even if they explain it their terms. By changing these definitions it risks training a new set of people on different definitions for no apparent reason. And this isn't a definition of risk that the security industry made up either, this was a formula that the security industry adopted from financial risk actuaries, so using security specific terms like threat and vulnerability really make less sense in that context. Similarly when they break down the traditional three prime locations to do modern detection and log aggregation, they give four locations. The fourth domain comes from calling one area 'systems telemetry' and another 'edge systems telemetry', seemingly drawing the distinction between internal network telemetry and the edge network analysis. I think this is a weird distinction to make and especially trivial in the context of an incident response effort, beyond maybe finding the root compromise. Further, when we do edge security analysis it often isn't traffic analysis such as netflow or pcap, it's typically application logs or en-mass observability statistics. In general the module puts a large focus on network analysis, which includes some really good labs, using tools such as Suricata, Zeek, Velocialraptor, and RITA. These are great and powerful tools for real network analysis and automated detection, although modern incident response has shifted to largely using EDR solutions and some kind of unified identity log collection. I would have really liked to see more tradecraft around tracking an incident, documented compromised hosts, and using this to fight an active infection. A bigger focus on reporting in general could be helpful as incidents often coincide with breaches and understanding the difference is often critical to an incident responders job. The layout of the content is also unclear and generally confusing. The website tries to break the module up by "phases" of the IR lifecycle, only chunked together. This would work if it stayed to it's own self defined phases, such as:

Phase 1: Preparation
Phase 2: Detection and Analysis
Phase 3: Containment, Eradication, and Recovery
Phase 4: Post-Incident Activity

But instead it jumps all around these topics, having random sections such as "Remediation / Eradication" and 'Restore, Validate, and Monitor" in the middle of the previous phases, staying neither consistent in the naming nor the layout. The resulting module layout muddles the IR life cycle, how the engagement should proceed, and when to move between phases or apply different strategy. Finally the quizs are pretty simple for the IR module specific content, each quiz simply consists of 3 questions which you can challenge any number of times, making it an easy thing to blast through. That said, I can understand how the real test is supposed to be the certification exam, but seeing as how this is an optional module it would be nice to see real tests associated with this content. All that said, check back in as I challenge the certification and post a full review of the course. This other review I've read says the course isn't for beginners and was rather difficult, but I've actually found it great for those moving from novice with solid background into a SOC analyst role specifically. Check back soon!

"Cybersecurity Tabletop Exercises: From Planning to Execution" by Robert Lelewski and John Hollenberger was an interesting book that I picked up at Ada's Technical Books in Seattle. Granted, I do a lot of table top exercises, at least four annually, so this is subject matter I know pretty well. Still I wanted to make sure I wasn't missing some big or new thing. I paid over $60 for this book new at only 150 pages, which feels pricey. My default pricing for books is typically $10 per 100 pages with lots of flexibility depending on the subject matter and presentation. Overall I give this 5 out of 10 stars. Frankly, I think it was overpriced and didn't offer any groundbreaking insights. There are also dozens of free resources from the EPA to CISA to a million easily digestible blog posts that cover the same material, so the high sticker price really was a shocker to get that same content. The book is laid out such that the main book (Part 1) is really only about 100 pages of theory (and that feels like stretching it) and the following 50 pages (Part 2) are multiple examples and sample tabletop exercises. If you were mega tight on timing I could actually see grabbing this book for these canned scenarios. That said, there are also dozens of free table top exercises on the Internet. The theory is also a bit light, as stated, you could learn much of this for free on the Internet. The following is the chapters of the book:

Part 1: The Tabletop Exercise Process
Chapter 1: Why Perform Tabletop Exercises?
Chapter 2: Planning the Tabletop Exercise
Chapter 3: The Development Process: Where the Rubber Meets the Road
Chapter 4: Facilitating a Successful Tabletop Exercise
Chapter 5: Acting on What You've Learned: Evaluation and Next Steps
PART II: Example Scenarios
Chapter 6: Engaging a Technical Audience
Chapter 7: Engaging a Executive Audience
Chapter 8: Engaging the Business
Appendix: Reporting Templates

Despite those previously mentioned shortcomings, the book does highlight a few things I think are worth calling out. I think having the non-static, multiple injects per tabletop example was neat. My tabletops often follow phases of the IR life cycle, whereas having the arbitrary injects move the plot could change that pace and add more dynamic content. It's also a little more realistic this way and mixes things up. I also really liked the emphasis on choosing and fitting the exercise to the audience. Such as having specific exercises target technical or non-technical audiences. The book also did well getting planners to estimate modes of participation, brainstorming how to generate more audience participation, and estimating some of the expected outcomes. I also think the postmortems on the exercise itself are a critical step and I'm glad the text calls that out. It's important to extract the lessons learned into actionable tasks to be accomplished otherwise the exercise could be in vain (beyond the teamwork and educational opportunities from the exercise itself). The following is an random youtube video on how to run your own table top exercises if you are interested, it is generally unrelated to the book: 

"Conversational Intelligence: How Great Leaders Build Trust and Get Extraordinary Results" by Judith Glaser was a fairly decent book on building world class communication skills and thus interpersonal relationships. This was a fairly simple book that outlined how most corporate teams fail to communicate by issuing orders to one another and how to move toward conversations that view all parties as collaborators. I think the book is fairly thin in terms of actual stratagies to do this, and the author seemingly recreates a lot of existing theories and paradigms, without really referencing those existing structures. This was a cheap and very reasonably priced book at $10 for 200 pages. And this was a mega quick read, I finished it easily under 6 hours.  Overall I give this 5 out of 10 stars, as I think there are better ways to convey what the author is getting at. Overall I would probably recommend other leadership books unless you are specially suffering from bad communications skills and plagued by poor conversations. Don't get me wrong, I think there are good and important lessons here. Communicating at level three as she describes it, is critical I think to good interpersonal communication. But I also think the author makes up so many new terms, such as "double clicking" that it actually confuses their point when they could just describe the actual phenomenon more clearly. Further, other reviews have called out how the author seemingly bites other concepts without ever actually referencing the original materials. I got this vibe throughout the entire book and it was a really big turn off. For example she coins her own term and thus the title of the book as Conversational-Intelligence (C-IQ), as a play on the traditional Intelligence Quota (IQ) or the newer Emotional Intelligence (EQ). The problem is that her newly coined Conversational Intelligence is what most people have generally accepted as Emotional Intelligence (understanding others, their communication styles, and thus goals), yet I have never heard another use the phrase conversational intelligence in it's place, before this book. By redefining already accepted concepts to make them your own, without really adding anything new to the concepts you only serve to confuse the topic rather than clarify it. The book is split into 3 parts, in my normal style here at the chapters of the book:

Introduction: Discovering a New Intelligence
Part I: Conversational Intelligence and Why We Need It
Chapter 1: What We Can Learn from Our Worst Conversations
Chapter 2: When We Lose Trust, We Lose Our Voice
Chapter 3: Moving from Distrust to Trust
Part II: Raising Your Conversational Intelligence
Chapter 4: Challenges of Navigating the Conversational Highway
Chapter 5: Harvesting Conversational Intelligence Using the Wisdom of our Five Brains
Chapter 6: Bringing Conversation to Life
Chapter 7: Priming for Level III Conversations
Chapter 8: Conversational Agility: Reframing, Refocusing, Redirecting
Chapter 9: A Toolkit for Level III Conversations
Part III: Getting to the Next Level of Greatness
Chapter 10: Leading with Trust: Laying the Foundation for Level III Interactions
Chapter 11: Teaming Up Through Conversational Intelligence
Chapter 12: Changing the Game Through Conversational Intelligence
Epilogue: Creating Conversations That Change The World

As much as I think there are good, important lessons here around building trust and communication with your peers, many of the author's techniques in communicating how and why that is important, really rubbed me the wrong way. For example, the chapter on "the five brains" talks about fairly pseudo-science ideas that we have these oversimplified parts of our brain that evolved out of lizard brains. That combined with the advice that one must "work on their third eye" in order to improve conversations with people, just came off as hippie nonsense to me. The end notes and references are also extremely thin, mostly only referencing a few of these weird debunked brain theories. Further, where she should be citing other works in the field and ideas she's borrowed, she uses multiple pages to thank CEOs who were her clients at various points in time. It feels very self-serving and like a weird shout-out as opposed to actual acknowledgments of other work in the field. Beyond that criticism, I think the book could have done more to describe different modes of communication that scale differently and thus lend themselves to different types of corporate "conversations". The book is obviously pitched at improving work conversations, not all work conversations are equivalent, one on ones, or direct conversations. I would have liked to see more examples on what kind of "conversation" is an all-hands, and how can you open that up or best engage audiences at these levels of scale, not just in a single conversation or a small group setting. I think giving the readers more tools to have and improve these conversations could be genuinely really helpful in a book like this. That said, the book is easy to read and includes dozens of simple graphs and graphics, or nice images that emphasize the points and break up the normal text. Feedback on this book is all across the board, but there are certainly some people that think similar to I on amazon reviews. That said, this is also a best seller and massively popular, so don't let me dissuade you, a lot of people really like it!

"What Got You Here Won't Get You There: How Successful People Become Even More Successful" by Marshall Goldsmith is a great book on evolving your leadership and management approach. It's a self help book that aims on personal improvement through various methods of corporate feedback. The book is straightforward, anecdotal, and practical. It focuses on first breaking down the ego and understanding that all of us, no matter how successful we are, can still find things to improve and work on in our life. The book really hammers home how success can get in our way, blinding us to our own shortcomings, or creating excuses for our behavior that is still holding us back, despite our own success. One of the really cool things about Marshall is that he publishes all of his resources for free on his personal website, including a really neat LLM trained on his advice! I personally listened to the book on audible for roughly ~8 hours (at 1.5 speed) for less than $1. I found it highly enlightening and generally good use of my time. Overall I give the book 6 out of 10 stars, as it didn't really say anything too novel or that I haven't heard before in terms of leadership coaching, however they are still critical lessons for any person, especially those who are already successful, to hear (again). I recommenced this book to anyone in a corporate setting, I firmly believe we all have features we can improve within ourselves and that recognizing that and setting up a plan for achieving it is within everyone's locus of control. In my typical style, here are the chapters of the book:

Section One: The Trouble with Success
Chapter 1: You Are Here
Chapter 2: Enough About You
Chapter 3: The Success Delusion, or Why We Resist Change
Section Two: The Twenty Habits That Hold You Back from the Top
Chapter 4: The Twenty Habits
Chapter 5: The Twenty-First Habit: Goal Obsession
Section Three: How We Can Change for the Better
Chapter 6: Feedback
Chapter 7: Apologizing
Chapter 8: Telling the World, or Advertising
Chapter 9: Listening 
Chapter 10: Thanking
Chapter 11: Following Up
Chapter 12:Practicing Feedforward
Section Four: Pull Out the Stops
Chapter 13: Changing The Rules
Chapter 14: Special Challenges for People in Charge 

Some of the major themes I want to highlight from the book are as follows. Successful people often fall into what Marshall calls "success traps". What works early in a career (drive and competitiveness) becomes a liability at later levels or in different positions. Its important to not make excuses for our bad traits because we've been successful despite them. Practice "feedforward", not feedback. This is incredibly important when providing people input on their work. Don't diminish it or shoot it down by using negative language, rather focus on what to do next time or how to course correct going forward Perception is reality is a huge message. How others perceive your behavior defines your effectiveness as a leader, not how you perceive yourself. It's important to square your own assumptions with your external perception using peer feedback. Finally, interpersonal change is measurable. You can and should track progress in interpersonal behavior with regular check-ins and metric like systems, just as you would a technical program. 

Marshall makes a point of listing out 20 bad habits that can doom a career, I'de like to list them for readers below:

 1. Winning too much: The need to win at all costs and in all situations.
 2. Adding too much value: The overwhelming desire to add our 2 cents to every discussion.
 3. Passing judgment: The need to rate others and impose our standards on them.
 4. Making destructive comments: The needless sarcasm and cutting remarks that we think make us witty.
 5. Starting with NO, BUT, HOWEVER: The overuse of these negative words which  say to others that you’re wrong.
 6. Telling the world how smart we are: The need to show people we’re smarter than they think we are.
 7. Speaking when angry: Using emotional volatility as a management tool.
 8. Negativity, or “that won’t work”: The need to share our negative thoughts even when we weren’t asked.
 9. Withholding information: The refusal to share information in order to maintain an advantage over others.
 10. Failing to give proper recognition: The inability to give praise and reward.
 11. Claiming credit that that we don’t deserve: The most annoying way to overestimate our contribution to any success.
 12. Making excuses: The need to reposition our annoying behavior as a permanent fixture so people excuse us for it.
 13. Clinging to the past: To deflect blame away from ourselves and onto events and people from our past.
 14. Playing favorites: Failing to see that we are treating someone unfairly.
 15. Refusing to express regret: The inability to take responsibility for our actions.
 16. Not listening: The most passive-aggressive form of disrespect for colleagues.
 17. Failing to express gratitude: The most basic form of bad manners.
 18. Punishing the messenger: The misguided need to attack the innocent who are informing us.
 19. Passing the buck: The need to blame everyone but ourselves.
 20. An excessive need to be “me”: Exalting our faults as virtues simply because they’re who we are.

Below you can see Marshall speaking at Google on some of the lessons in the book. It's an extremely interactive session with breaks in the middle where he asks the audience to engage in some exercises. You should skip around those parts as you watch at home:

"High Output Management" by Andrew S Grove was a great book on various management strategies and lessons learned from Andy Grove scaling his career and business at Intel. The book is all about how managers can maximize their output, and thus the output of their team. It's all about where managers should be spending their time and what investments provide long term value in terms of company and employee growth. I think the book really resonated with me because there is such a focus on education and how a manager should really act as a guide and a teacher. Overall I give this a 6 out of 10 book in my journey of learning better management and leadership strategies.  I recommend this book to those who still don't believe in the power of 1 on 1s or want help managing large teams across multiple organizations. I really like how the book talks about a manger's primary role being that of information flow and circulation, such that they are constantly communicating important task level information downward, project level information horizontally, and progress on goals upward. A large part of that communication is receiving information and understanding what the different aspects of the business are doing, to be able to translate it effectively to different audiences. There are several practical tools in this book that managers can implement immediately to become better at their jobs. In my typical format, here are the chapters in the book:

Introduction
Part I: The Breakfast Factory
Chapter 1: The Basics of Production: Delivering a Breakfast
Chapter 2: Managing the Breakfast Factory
Part II: Management Is a Team Game
Chapter 3: Managerial Leverage
Chapter 4: Meetings: The Medium of Managerial Work
Chapter 5: Decisions, Decisions
Chapter 6: Planning: Today's Actions for Tomorrow's Output
Part III: Team of Teams
Chapter 7: The Breakfast Factory Goes National
Chapter 8: Hybrid Organizations
Chapter 9: Dual Reporting
Chapter 10: Modes of Control
Part IV: The Players
Chapter 11: The Sports Analogy
Chapter 12: Task-Relevant Maturity
Chapter 13: Performance Appraisal: Manager as Judge and Jury
Chapter 14: Two Difficult Tasks
Chapter 15: Compensation as Task-Relevant Feedback
Chapter 16: Why Training Is the Boss's Job
One More Thing... 

There are a few tools and themes that I found especially helpful from the book, such as tickler files, 1 on 1s, office hours, group decision making, matrix management, and task relevance maturity. I really like the idea of using tickler files as reminder files or note files. I personally set mine up as google calendar dates, with either advanced notice or just as informational popups. I also like them when dealing with all of the intricacies of various team work and interpersonal issues. Especially coupled with 1 on 1s, to track and address employee issues, tickler files can be especially useful to establish early and maintain as a way of generating talking points, saving important notes, or just reaching out for something. I've already talked about them in depth in other management book reviews, but 1 on 1s are a powerful tool for hearing employees as individuals, solving their direct problems, and providing valuable information about the job. Something new I got from this book was the idea of office hours to decrease short to medium-term interruptions by setting a dedicated time for them. The book also talks about career management and planning your career consciously, not only for yourself but helping your direct reports plan their career in their best interests. One really fascinating concept I got from this book around career growth, especially in terms of moving into management was the idea of 'task relevant maturity'. This is the idea that someone may be a great manager in a subject they are very familiar with, but a poor manager in another area where they are less familiar. This is important to consider as your role grows and changes throughout your career. Lastly, I really like the idea of matrix management for large projects, or the idea that multiple people can oversee different parts of a team, and employees are beholden to multiple stakeholders or managers in delivering these large work streams. Other ways to accomplish this for specific projects are RACI charts, but the concept of matrix management alone is powerful for larger teams and organizations. The following is a video series by Abi Tyas Tunggal on the book where he breaks the lessons from the book down into several short video lectures, it's really fantastic stuff:

David Campbell raises a valid concern: are we facing a looming engineering talent pipeline problem? His piece, The Coming Engineering Cliff, paints a picture of AI rapidly encroaching on the territory of a proper computer science education. While the allure of AI-powered development is undeniable, we must not lose a critical element in the development of jr engineers: the irreplaceable value of hard-won experience, the kind forged in the fires of scaling nightmares and security incidents. This isn't about AI vs. engineers; it's about ensuring the next generation doesn't just trade depth for velocity while building skills.

Campbell's argument hinges on AI's ability to automate and accelerate development. Fair enough. But engineering isn't just about churning out code; it's about understanding the underlying systems, anticipating failure modes, and crafting solutions that are both thoughtful and robust. This instinct isn't something you can simply train a LLM on. Instinct comes from going through a production outage at 3 AM, from tracing a memory leak through a million lines of code, from learning, often painfully, what not to do. It's about recognizing patterns not just statistically, but viscerally. It's the difference between knowing the rules of chess and being able to anticipate your opponent's strategy. In many ways it can be adversarial thinking, but applied to your own systems. LLMs excel at pattern matching. They can regurgitate solutions based on past incidents. But what happens when faced with a novel threat, a zero-day exploit, a scaling challenge no one has ever encountered before? That's where the A+ engineer, the one with the battle scars and the finely honed instincts, steps in. They don't just apply a prepackaged solution; they invent one that suits the need at hand.

Cloud platforms and AI-powered tools promise to abstract away the complexities of infrastructure and security. And in many ways, they deliver. But this abstraction comes at a cost. Younger engineers, raised on these platforms, are increasingly shielded from the 'unforgiving edge of scale', as Campbell aptly puts it. They can deploy applications with a few clicks, without ever grappling with the intricacies of load balancing, network security, or database optimization, as examples. They become vibe coders, deploying code they barely understand, hoping for the best. This isn't to say these tools are inherently bad; they're incredibly powerful if used by engineers who possess a solid foundation of knowledge. The problem is that these platforms can become a crutch, preventing younger engineers from developing the deep understanding necessary to troubleshoot complex issues and design resilient systems. They're learning to drive without ever understanding how the engine works. And when the engine inevitably breaks down, they're left stranded.

The core issue here is understanding why. A LLM trained on incident postmortems can identify potential failure points, but does it truly understand the underlying causes? Can it reason about nuanced trade-offs in a high-pressure situation? I'm reminded of the Chinese Room argument: the AI can manipulate symbols according to rules, but it doesn't actually understand the meaning behind those symbols. This lack of understanding is particularly dangerous in security contexts. Trusting a non-deterministic black box that's prone to hallucinations to make critical security decisions is a recipe for disaster. We need engineers who can not only identify vulnerabilities but also understand the attacker's mindset, anticipate their moves, and design defenses that are both effective and adaptable. AI can augment human intelligence, but it can't replace it. We still need engineers who can think critically, creatively, and independently, who can challenge assumptions, and who can make informed decisions in the face of uncertainty.

So, what's the solution? We can't simply abandon AI and cloud platforms; they're too valuable. Instead, we need to find ways to bridge the gap between abstraction and understanding, to cultivate the next generation of A+ engineers. Here are a few ideas:

• Revive the apprenticeship model: Pair junior engineers with experienced mentors who can guide them through the complexities of real-world systems.
• Create failure-friendly environments: Give engineers opportunities to experiment, to break things, and to learn from their mistakes in a safe and controlled setting. Think CTF environments where they must secure and scale vibe-coded programs.
• Capture the wisdom of the elders: Document the experiences and insights of our most seasoned engineers before they retire or move on to other ventures. This means more senior engineers should blog or write about their hard gained experiences.
• Integrate depth into the AI-assisted workflow: Design AI tools that not only automate tasks but also explain the underlying principles and trade-offs.

The goal isn't to eliminate AI, but to use it as a tool to enhance human intelligence, not to replace it. We need to create a culture that values depth of understanding, critical thinking, and the ability to adapt to unforeseen challenges. The coming engineering cliff isn't inevitable. But avoiding it requires a conscious effort to cultivate the next generation of A+ engineers, engineers who possess not only the technical skills but also the hard-won experience and the intuitive understanding necessary to navigate the complexities of the modern technological landscape. AI can be a powerful ally, but it's no substitute for human ingenuity. Let's not trade the wisdom of experience for the illusion of effortless automation. The future of engineering depends on it.

"The Language of Deception: Weaponizing Next Generation AI" By Justin Hutchens, takes an ambitious look at the intersection of social engineering, machine learning, and adversarial tradecraft. If you’re coming from a background in red teaming or threat intelligence, you’ll recognize many of the psychological and social principles, but what makes this book valuable is how it reframes those timeless tactics through the lens of AI for the general people. This book tries to warn people of the fallacy of the "thinking machine" or the idea that LLMs are intelligent or really considering ideas just because the output looks human. It's also a fantastic book on the history of AI, showing how these systems have evolved over time, and how models have been used throughout computer science. It's a long book around 400 pages, I listened to it on Audible at ~$15 for about 10.5 hours. I give it 6 out of 10 stars for being a great book on the risks of AI. Overall, I recommend the book to general technologists interested in AI as it lays out some stark realities with the tools, while not being too technical. Although it was written in 2023, it feels like it was written awhile ago (because the space moves so fast) but still several of their predictions have come true. Hutchens doesn’t treat AI as magic. He systematically looks at how attackers could operationalize it, from mass-scale phishing to automated social-engineering campaign pretexting. The framing feels very much in line with how threat actors actually iterate on attack campaigns. The following are the chapters of the book according to the Wiley website:

Chapter 1: Artificial Social Intelligence
Chapter 2: Social Engineering and Psychological Exploitation
Chapter 3: A History of Technology and Social Engineering
Chapter 4: A History of Language Modeling 
Chapter 5: Consciousness, Sentience, and Understanding
Chapter 6: The Imitation Game
Chapter 7: Weaponizing Social Intelligence
Chapter 8: Weaponizing Technical Intelligence
Chapter 9: Multimodal Manipulation
Chapter 10: The Future
Chapter 11: The Quest for Resolution

Some parts feel a little disconnected from the reality of the technologies. For example around Chapter 7 the author is talking about bot automation and automated service interaction and discuses using the UI and web scraping to avoid bot detection, when in reality these techniques are pretty different from simply using the or scraping the user UI, and such actives are heavily logged and scrutinized for bot activity. I know it's a small nitpick but it shows a strange disconnect from the reality of some of the techniques. It's also a little wonky because the audio book counts the chapters differently than the print book, but I've referenced the print chapters here. The book calls out one of the major threats my team repeatedly calls out, which is the illusion of intelligence in modern LLMs. Just because some it putting together a string of words that gives the illusion that it understands, doesn't mean the model has a true understanding of the content. This can cause users of these systems to place a false confidence in their output or misunderstand the tools entirely. Hutchens brilliantly demonstrates this with the "Chinese Room Paradox", reminding us that convincing language isn’t evidence of comprehension. The following is an interview with Hutchens discussing the contents of the book:

I recently volunteered as a DEF CON goon expecting to help people feel welcome and connected. Instead, I was let go for a minor infraction, an experience that left me concerned about how the culture of volunteering at DEF CON has shifted. When volunteers give their time and money, they should be empowered to support attendees, not treated like replaceable enforcers. DEF CON thrives on community, but that only works if volunteering stays rooted in connection, not control. I don't want to name any specific people or leaders involved in this decision process, but as a long term volunteer for security events this just felt over the top to me. I will name the group, as this happened while I was volunteering for the NFO section of the goons (info goons), but to be frank I thought they would be the most open and least "GOON"-like group. The official reason I was let go was that I missed a call from my shift lead and was absent from a newly created shift location for 45 minutes. I thought I was activly doing my job by showing people the rooms, as I was engaged in helping DEF CON attendees find locations and people they were interested in the entire time. At the end of the day I'm volunteering to make a more positive experience for others attending the thing. And I didn't do anything offensive or against the rules, I was just temporarily outside the control of a manager, and that was a terminal event. On top of that, I'm a highly educated person who is often in leadership and managerial positions, so I understand feedback and coarse correction if I'm not doing my job right. Firing me for being absent (due to a misinterpretation of what I thought I was supposed to be doing), is so absurd within a volunteer context that it really attributes itself to the over-zealous image of goons that the community has formed. Here are my major issues with the current culture of DEF CON goons:  

Authority & Power Trips - Certain goons come across like “mall cops,” more interested in enforcing rules than helping people. Some even brag about skipping lines or using their role for personal perks.

Clique-ish Dynamics - It can feel like an insider’s club where newcomers aren’t welcomed. First-time volunteers often struggle to connect, while long-timers stick together. 

Status Over Service - The role can seem like a badge of superiority rather than a commitment to supporting attendees.

Unapproachable - Groups of info goons often cluster together, making them intimidating and generally ineffective (They don't all answer questions when grouped like that, most of them stand around doing nothing). Attendees also report that simple questions often go unanswered.

Rules Over Hospitality - Instead of focusing on helping people, there’s a strong emphasis on enforcing arbitrary rules, which creates the impression that attendees are being policed rather than supported.

I recently took "Advanced Detection Engineering in the Enterprise" at BlackHat USA 2025. The course was taught by the FalconForce team, including the founders Olaf Hartong and Henri Hambartsumyan, as well as Theo Raedschelders and James Gratchoff. This was an amazing course, that largely focused on Windows detections leveraging modern Azure detection stacks. Microsoft Defender for Endpoint (MDE) and Azure Sentinel being the main hunting and detection platforms for log searching. The course followed a fantastic purple teaming structure, by providing us with fully instrumented Attacker and Victim VMs, that we could use to execute attacks and then hunt and detect said attacks in the logs. We were provided offensive tools such as Mythic, for command and control, and were able to emulate many modern, Windows, attacker tools and techniques, such as SharpHound, Mimikatz, ClickOnce Apps, HTML Smuggling, Living off the Land Drivers, DLL Hijacking, and even Macro weaponization. After executing the attacks we worked on many robust detections for said attacks, such as non-system processes making smb or kerberos calls. Overall these were highly relevant and modern techniques on both sides, with attacks that work in modern environments as well as effective and widely applicable detections for said attacks. The first two days focused on local enterprise detections using onsite technologies like MDE and instrumented host VMs. We used tools like OneClick and executed techniques like DLL hijacking and agent beaconing. Later we used SOCKS proxies to tunnel through our agents and hit further targets in the environment. The second two days focused on detections in the cloud using cloud-logs in Sentinel. Here we looked at techniques like cloud credential phishing and further Azure post-exploitation techniques and detections. The training included tons of good theory that was also applicable to non-Micorsoft environments, such as optimizing search queries, where / what logs to collect, and what log sources to write certain detections on (and why). They also broke down a lot of the technologies, showing edge cases in timing queries, and how certain join statements were better in certain situations, all very useful stuff if are trying to  debug query results in an investigation. They also taught a lot of meta-detection theory, such as storing detections as code, keeping wiki pages on every detection, and testing their detection pipelines end-to-end in an automated way.The lab was  brilliant as it incorporated both attacker and defender VMs that were both fully instrumented with the right tools and logging. My group often goofed around on the VMs and attacked each other using different techniques after we finished the labs. It was a wonderful environment to play around in and then hunt those activities. The adversary simulation was also very well throughout, it wasn't canned but was still representative of modern TTPs with edge cases considered for both escalations and detections. Overall, I highly recommend the course to defenders and attackers at every level. I think this is an amazing purple teaming course, and offers something to everyone. That said, I think the course will have a larger impact if your day-to-day environment is Windows or Azure based. I truly believe in learning both the attacker and defender techniques for a more holistic understanding of computer security and this course teaches exactly that. Even if you are a beginner I think you could follow this material, and if you are an expert there is so much cool esoteric knowledge packed into this course (and room to do your own stuff), that I promise you will enjoy it. The following is an older video of Olaf's but covers a good amount of the theory and approach to detections that they take as a group.