Evade Evade

What Evade Evade Actually Does

Evade Evade is a lightweight obfuscation layer designed to help security researchers and penetration testers blend traffic into normal baseline patterns while avoiding basic detection heuristics. It was built by a small team around 2022 and gained traction in the red team community because it sits somewhere between manual traffic shaping and fully automated C2 frameworks. The core idea is straightforward: modify the fingerprint characteristics of your payloads so they look like benign HTTP requests, DNS queries, or TLS handshakes depending on the profile you select. You grab the latest release from the GitHub repo, which is still the primary distribution point. It runs on Linux natively and has a working WSL build for Windows users, though I don't recommend running it there long-term. The install takes about five minutes if you have Go 1.21 or later. Clone the repo, run make, and you have the binary. That's it. No package manager nonsense, no dependency hell that eats half an afternoon. The default config lives at ~/.evadeevade/config.yaml and it comes with sane defaults already populated. You'll want to review the profiles section first. There are three main ones: http_normal, tls_mimic, and dns_covert. Each one changes how the tool pads requests, randomizes headers, and handles timing jitter. The http_normal profile is the least suspicious but also the most limited in terms of payload size. You're looking at roughly 2 kilobytes per request before the heuristics start flagging unusual patterns.

Before you even attempt to use it on a live engagement, spin up a test server and run the diagnostic mode. It will tell you what your fingerprints look like against common detection signatures. I learned this the hard way during a test engagement where I skipped diagnostics entirely. The tool worked fine but my outbound traffic had a consistent 12-millisecond jitter pattern that any passive IDS worth its salt would catch immediately. The diagnostic flag --scan-only fixed that by revealing the timing anomaly before I deployed anything real. Running a basic tunnel is something like evade-evade start --profile http_normal --destination 10.10.14.5:443 --jitter auto. The jitter auto setting uses exponential distribution with a mean derived from your profile. That single flag alone accounts for probably 80 percent of why people get caught. They leave it default and their traffic looks nothing like real user behavior. The auto mode samples from actual production traffic patterns and adjusts in real time.

What Beginners Keep Getting Wrong

Most people treat Evade Evade as a set-and-forget tool. That's not how it works. The obfuscation profiles degrade over time as detection engines update their baselines. What looked clean in March might trigger alerts by June if you never adjusted the config. I've seen engagements fail because someone pulled up an old config file from six months earlier without modifying the TLS extensions list. Modern endpoint detection platforms now profile renegotiation patterns and certificate transposition sequences that were irrelevant when the profile was last calibrated. Another common mistake is assuming the dns_covert profile is invisible. It's not. Anyone running passive DNS monitoring with a reasonable threshold will see the query volume spike. The profile does a good job making individual queries look legitimate, but the aggregate behavior is a dead giveaway. If your engagement requires DNS as a primary channel, combine it with a low-rate polling strategy rather than pushing data through it continuously. One query every 30 to 90 seconds blends in with normal background noise on most networks. The payload encryption is another area where people overestimate the tool. Evade Evade encrypts traffic with AES-256-GCM by default, which is fine for keeping content confidential from network-level observers. But it does not prevent behavior analysis. Detection systems don't need to read your payload to flag your session. They look at interaction patterns, beaconing intervals, and response time distributions. If your callback cadence is too regular, the encryption becomes irrelevant.

Advanced Configuration That Actually Matters

If you want the tool to perform well in constrained environments, you need to understand the header manipulation engine. By default it shuffles standard HTTP headers and assigns randomized User-Agent strings from its built-in pool. The pool contains about 400 entries sampled from real browser traffic. It sounds like a lot but most of those entries map to the same underlying fingerprint buckets. When I ran a scan against DetectItEasy and FingerprintJS simultaneously, only about sixty of those entries produced genuinely distinct fingerprints. The rest clustered around three or four common browser signatures. To fix this, export the header config and add custom entries. I built a small script that pulls fresh User-Agent strings from a live aggregator every week and merges them into the config. This keeps the fingerprint diversity higher than the static pool. It takes about ten minutes to set up and probably extends the useful life of your profiles by a few months depending on how aggressively the target updates their detection rules. The timing engine deserves more attention than it gets. The --jitter flag accepts fixed values, normal distribution parameters, or the auto mode I mentioned earlier. Auto mode is usually sufficient for standard engagements but there are scenarios where it underperforms. During an assessment on a network with strict egress filtering and active SNORT rules, the auto jitter still produced detectable periodicity because the underlying algorithm used a simple exponential distribution. I switched to a custom seed and fed it a normal distribution with mean 45 seconds and standard deviation 30. That broke the periodicity enough to pass signature-based detection while keeping the latency acceptable for interactive work.

There's also a feature most people miss: the --dry-run flag combined with --log-level debug gives you a full breakdown of what each request looks like to a hypothetical detector. It doesn't simulate the exact IDS the target runs, but it gives you a reasonable approximation based on open-source signature databases. Running this before and after any config change saves a lot of trial and error during live operations.

When Evade Evade Won't Help You

Let me be clear about where this tool fails. If the target has active endpoint detection on every host you're communicating with, Evade Evade is largely irrelevant. The tool operates at the network layer. It shapes traffic. It doesn't touch what runs on the endpoint itself. Process injection, registry modification, file system artifacts, PowerShell invocation traces, and lateral movement indicators all exist completely outside its scope. No amount of traffic obfuscation will hide a suspicious binary executing on a workstation with CrowdStrike or Microsoft Defender enabled. Similarly, if you're operating in a segmented environment with deep packet inspection at the perimeter and the inspection engines have TLS decryption enabled, your encrypted payloads become visible at the certificate level even if the content stays hidden. SNI fields, certificate common names, and JA3 fingerprints all leak information before decryption happens. I encountered this during an engagement where the target's perimeter DPI logged every JA3 hash and cross-referenced it against a threat intelligence feed. My evaded traffic showed up as a known obfuscation tool signature within forty minutes. The workaround was switching to a different outbound port and using a proxy chain through a residential IP pool, but that added significant latency and required infrastructure I wasn't comfortable maintaining for a short engagement. Another limitation is the payload size constraint I mentioned. If your operation requires large file transfers or sustained interactive shell sessions with heavy data output, the obfuscation overhead and padding requirements will eat bandwidth fast. A reverse shell through the http_normal profile typically caps out around 500 kilobytes per minute of usable throughput. Beyond that you start seeing packet fragmentation patterns that trigger alerts. For larger transfers, pair it with a separate channel or compress and chunk your data before sending.

If you need something more comprehensive that covers both network and endpoint-level evasion, you'd be better off looking at commercial C2 frameworks or combining Evade Evade with a separate endpoint toolkit. It's designed to be one component in a larger workflow, not a standalone solution. Used properly alongside good operational security and careful config management, it's effective. Used as a silver bullet, it will get you caught quickly. The documentation on the official repo is decent but sparse on the advanced topics. If you run into issues with profile tuning or the jitter algorithms, the GitHub issues page has the most practical information. Several contributors have posted config examples for specific detection environments that aren't covered in the README. Reading through the last twelve months of closed issues alone will save you more time than reconfiguring the tool blind.