Evasion Engineering

General Thoughts

Evasion Engineering is strongest when it treats offensive tooling as engineering instead of disposable scripting. The first two parts gave me several ideas I can use immediately, and the techniques alone justify the price of admission. I came to the book with an OSCE3 background, but it still upgraded how I think about evasion.

The biggest lesson is that being evasive means blending in. Hiding a payload is only one part of the problem. The stronger approach is making the infrastructure, traffic, timing, and execution look like something a normal environment already produces. AWS Lambda, Google Cloud Platform, Firestore, cloud logging, and short-lived infrastructure make that idea concrete. Chapter 3 especially opened my eyes to the possibilities of quickly creating and destroying cloud resources while generating ordinary-looking traffic.

The book loses some focus in Part III. Chapters 9 and 10 contain useful detection and purple-team material, but they move away from the offensive-evasion thread that made the earlier chapters so strong. I also wanted fewer pages of code and more space for the techniques and reasoning behind it. The code is valuable because it shows how the authors build these tools, but some of it would have worked better as a reference section.

The book also succeeds because it makes the defender part of the design problem. A tool is not evasive simply because it avoids one signature. Its choices create binary, process, network, cloud, and timing signals that someone else can correlate. That framing changed the way I think about custom tooling more than any individual packing or encoding technique.

Chapter Breakdown

Part I: Red Teaming Fundamentals

Chapter 1: Principles of Application Design and Development

I enjoyed the focus on process and the reasoning behind the implementation. The discussion of robustness, reusability, and reliability approaches red-team tooling from first principles. It explains why an evasive tool should be designed as something maintainable instead of a one-off script for a single engagement.

That foundation matters for the rest of the book. The authors are not treating payload development as a sequence of clever tricks. They are asking what happens when a tool has to survive changing targets, incomplete assumptions, operational mistakes, and defensive visibility. I appreciated that emphasis because it makes the later examples feel like applications of a method rather than isolated demos.

Chapter 2: Evasion Strategies

Low-entropy encryption was the idea that stayed with me most. I had usually reached for XOR keys, and the chapter made me reconsider whether that choice can become part of the detection signature itself. Compression, simple encoding, and representations such as IP address lists or Morse code can produce different signals than conventional encrypted implants. The format and statistical properties of a payload deserve the same attention as the key protecting it.

The useful distinction is between hiding content and changing the signals that content produces. Simple encoding does not make a payload safe from analysis, but it can behave differently from a conventional encrypted blob. The chapter pushed me to think about entropy, compression, representation, and analysis cost as separate design variables instead of treating encryption as the entire evasion strategy.

Part II: Hands-On Evasive Tool Development

Chapter 3: Enumerating with Traffic Redirection

This is where the cloud material really started to land for me. AWS Lambda, CloudFormation, Step Functions, and rotating infrastructure show how quickly resources can be created and removed while operations communicate through services that already generate large amounts of normal web traffic. Cloud platforms become part of the operational behavior, not just places to host infrastructure.

The important shift is that traffic redirection is not presented as a single proxy trick. The infrastructure itself becomes disposable and programmable. An operator can create the resources needed for one phase, route activity through services that already have legitimate users, and remove the resources afterward. That combination of ordinary traffic and short-lived infrastructure is what made the chapter stand out to me.

Chapter 4: Developing Command-and-Control Implants

Seeing actual implant development was fantastic. The chapter moves from a proof of concept toward a more evasive design, including command-and-control through Firestore and behavior intended to avoid obvious process and network indicators. It is also where the book became code-heavy enough to feel more like a programming book. I still got a lot from it because the implementation makes the engineering decisions visible.

Firestore is a memorable choice because it demonstrates the broader principle: command and control does not have to look like a dedicated operator channel. The implementation also makes the tradeoffs visible. Every attempt to remove an obvious process or network indicator changes what the implant has to do elsewhere, and those new behaviors can become detection opportunities of their own.

Chapter 5: Creating Lateral Exploits with Worms

The value here is the diversity of tooling. A worm is a different engineering problem from a scanner or implant, reinforcing the argument for reusable design. The guardrails and honeypot checks were especially useful because they show operational control as part of the tool rather than an afterthought.

I liked that the chapter treats uncontrolled propagation as an engineering failure, not an inevitable property of worm mechanics. Guardrails and honeypot checks provide ways to limit damage and validate assumptions before an operation spreads into an environment that was not meant to be touched. That operational discipline connects directly to the reliability principles from Chapter 1.

Chapter 6: Enumerating Locally Without LOLBins

Living-off-the-Land Binaries are taught in many penetration-testing courses, but I have rarely found one that did not get flagged quickly by Endpoint Detection and Response. Implementing the required functionality directly in custom tools is one of the strongest sections in the book. It turns a familiar technique into an engineering question, then shows how avoiding common shell and binary execution patterns can change what defenders see.

This section was especially useful because it challenges a default assumption in offensive workflows. If a shell, system utility, or familiar execution path is already heavily monitored, repeating the same behavior with a different command does not solve the underlying problem. Building the required functionality into a custom tool changes the observable chain, while still leaving the operator with a new set of behaviors to understand and test.

Chapter 7: Bypassing Detection with Hybrid Packing

This chapter comes closer to the traditional evasion material I expected while connecting it to the earlier discussion of detection signals. Encoding, compression, payload transformation, and memory execution make the reader think carefully about how execution gets past modern EDR. It also reinforces that an evasion technique can create its own signal when the resulting behavior is unusual.

The hybrid approach is more interesting than simply adding another encoding layer. Packing changes the relationship between the artifact on disk, the code that executes, and the memory behavior defenders observe. That gives the operator more variables to work with, but it also means more stages and more opportunities for a detector to notice something unusual. The chapter kept bringing me back to the same question: what signal did this technique trade for the one it removed?

Chapter 8: Staging and Exfiltrating Data Covertly

The cloud focus drives the main argument home. Domain blocking is common, and a validated communication channel often means using services that already have a legitimate reason to exchange data. The staging and retrieval pipeline shows why cloud techniques matter to modern offensive operations, even when endpoint tooling is carefully designed.

The practical lesson is that a communication path has to be evaluated in context. A domain can be allowed and still produce suspicious timing, volume, authentication, or data-shape signals. The chapter made me think less about finding one trusted destination and more about whether the complete staging and retrieval workflow resembles a real application using that service.

Part III: Testing and Validation

Chapter 9: Building Detection Tools

The defensive view exposes the signatures used to identify the techniques developed earlier. I liked the analysis of binary properties and network behavior, although the full implementation interrupted the offensive thread and made the book feel like it was moving into a different subject.

I still found the chapter valuable because it forces the reader to inspect the artifacts created by the earlier work. Binary properties, execution behavior, and network patterns are not abstract defensive categories here. They are the evidence left behind by the tools the reader just built. I would have preferred this material to be shorter, but the perspective makes the offensive chapters more concrete in retrospect.

Chapter 10: Executing Controlled Reveals

This is useful purple-team material, particularly for cloud security testing. The controlled simulations and practical detection techniques gave me ideas for future assessments. It did not add much to my ability to operate evasively, so it felt like another departure from the book's main theme.

The controlled-reveal idea is still a good bridge between red and blue teams. It gives defenders a repeatable way to validate whether a behavior is visible without pretending that a one-time alert proves durable coverage. For readers who run collaborative assessments, this chapter may be more immediately useful than it was for me as a reader primarily focused on offensive evasion.

Appendix: Technical Prerequisites

The appendix does what it needs to do. Readers who lack experience with the languages and cloud platforms used in the labs will need it, while experienced practitioners can use it as a quick setup reference.

The prerequisites are practical rather than exotic: Go 1.21 or newer and Python 3.x, along with enough operating-system, networking, and cloud knowledge to understand what the tools are doing. That makes the book accessible to experienced security practitioners who are new to Go, but it is not a substitute for learning the underlying systems first.

Who Should Read This

Red-team operators and penetration testers who want to improve their evasion abilities will get the most from this book, especially those ready to build custom tooling instead of repeatedly modifying public tools. Incident responders, forensic investigators, and detection engineers should read it as well. The cloud-based tradecraft and custom execution patterns give defenders concrete ideas for what to look for and can jumpstart new detection rules.

Readers looking for a concise conceptual guide should know what they are buying. The labs contain a lot of code, and the book assumes experience with operating systems, cloud platforms, networking, and programming. The publisher lists Go 1.21+ and Python 3.x as technical prerequisites. Beginners may get more from a foundational resource first.

Closing

My impression did not change after working through the chapters. Parts I and II are extremely strong, while Part III provides useful information but wanders into blue-team and purple-team territory. I would have traded some implementation detail for more discussion of the techniques, tradeoffs, and reasoning that make the tooling evasive.

The idea that sticks with me is simple: blending in matters more than disappearing. Cloud computing gives operators ordinary services, short-lived resources, and trusted communication paths to work with. That has me thinking seriously about how those capabilities will shape agentic red-team tooling. Evasion Engineering earns its 8/10 because it makes that future feel technically immediate.

The score reflects both halves of the experience. The strongest chapters changed how I reason about tooling and gave me techniques I can apply immediately. The deduction comes from the pacing in Part III and the amount of implementation detail that sometimes replaces explanation. Even with that tradeoff, this is a book I would recommend to a practitioner who is ready to stop treating public tooling as a permanent answer.

I also received a signed copy of the book, and it was great getting to speak with Dennis Chow and Michael LaSalvia about the process of writing it. That conversation added a useful personal dimension to the review. The book's emphasis on robustness, reusability, and reliability is not just editorial positioning. It reflects how the authors think about building tools that have to work under real operational and defensive pressure.

Where to Buy

Evasion Engineering was published by No Starch Press in July 2026. The print edition is 256 pages and includes the ebook for $59.99. The standalone ebook edition is listed at $47.99.