LSN โ€” Local Sovereign Network

Sliver: The Adversary Emulator That Became the Adversary

TI-2026-075D ยท Series: The Armory (Part D) ยท TLP:WHITE ยท 2026-07-10

Assessment (HIGH confidence on the threat class; local footprint deliberately small). The earlier letters of The Armory profiled the light end โ€” brute-forcers and scanners, tools whose dual-use is easy to shrug at. Sliver is the heavy end, and it removes every euphemism from the series' thesis. Sliver is a full command-and-control framework, published openly on GitHub by the security firm Bishop Fox, under the plain description "Adversary Emulation Framework" โ€” built to let red teams behave like a real intruder so defenders can practice catching one. It was then adopted, essentially as-is, by the real intruders: Russia's APT29, North Korean operators staging Play ransomware, and multiple criminal ransomware crews. The tool did exactly what its name promised. It emulated an adversary so faithfully that adversaries adopted it wholesale.

A note on grounding, up front and honest: the honeypot's own footprint for Sliver is a single sighting. This letter is OSINT-led by necessity โ€” its weight is the external record, its local anchor is one confirmatory data point. That is the correct calibration for a homelab sensor observing a global framework, and stating it plainly is the standard this series holds itself to.

1. The name is the argument

Most of the tension in dual-use tooling has to survive a little pleading. Hydra is a legitimate brute-forcer; Nmap is a legitimate scanner; they only look bad because a honeypot has no consent to give. Those arguments are true and this series has made them. But they require a step of interpretation, a moment where you concede that the tool is innocent and only the use is guilty.

Sliver skips the step, because Sliver says what it is on the label. Bishop Fox โ€” a reputable, well-known offensive-security company โ€” distributes it publicly, for free, described as an Adversary Emulation Framework. The entire product thesis is: here is a tool that behaves like a sophisticated intruder, so your defenders can rehearse against a sophisticated intruder. To do that job, it must be genuinely good at being an intruder. Not a toy that pretends; a real C2 that a real red team can point at a real client and realistically compromise them.

And so the argument makes itself. A tool built to be indistinguishable from a real adversary will be indistinguishable from a real adversary โ€” including when a real adversary is holding it. There is no version of "emulates the adversary well enough to train defenders" that is not also "serves the adversary well enough to attack." The dual-use is not a side effect of Sliver. It is the specification.

2. The capability set, and why every line is two things at once

Strip Sliver to its data sheet and read each capability twice โ€” once as a red-team feature, once as an intrusion feature โ€” and notice that you never have to change the words:

There is no line in that list where the offensive and defensive readings diverge, because they are the same operation described by people with different permissions. The capability is fixed; the permission is what varies; and the permission โ€” the consent โ€” is exactly the thing that lives nowhere in the binary. This is the point the whole Armory has been circling, and Sliver states it in its feature list.

3. The adopters read like an index

The clearest evidence that a red-team tool has become an adversary tool is who is caught holding it. Sliver's list is not a fringe:

Look at the range of that list. A tier-one nation-state intelligence service and a commodity ransomware crew, espionage and extortion, Moscow and Pyongyang and the criminal underground โ€” all reaching into the same open repository and pulling out the same framework. Bishop Fox stocked one shelf, the internet mirrored it a thousand times, and everyone from the SVR down shopped there. The availability did not create these actors' intent. It removed the friction between their intent and a capable tool, for free, at the speed of git clone.

4. Why they chose it: the arithmetic of detection

The interesting question is not that they adopted Sliver but why they migrated to it โ€” because most of these actors previously had Cobalt Strike, the commercial standard, whose cracked copies circulate widely. The stated reason is that Sliver has a "lower profile." Decoded, that is a piece of pure detection economics.

The defensive industry spent years building signatures, YARA rules, JA3/JARM fingerprints, and memory scanners for cracked Cobalt Strike, because it was everywhere. Its beacons became some of the most-watched artifacts on the internet. Cobalt Strike did not get less capable; it got more visible โ€” and visibility is a cost to an attacker measured in dwell time lost.

Sliver offered the same capability where that cost had not yet accrued. Free, open-source, with encrypted, per-binary-keyed, customizable traffic that static signatures struggle to pin. Migrating from Cobalt Strike to Sliver was not a power move; it was an arbitrage โ€” trade a heavily-signatured tool for an equally-capable, less-watched one, and buy back the dwell time. It is precisely the logic of the cloud contractor choosing reputable ranges: go where the defender's attention is thin. Tools, like infrastructure, are chosen against the map of what defenders are looking at โ€” and that map is public, so the arbitrage never closes for long.

5. The evasion the criminals inherited was a feature request

There is a specific, uncomfortable mechanism worth isolating, because it recurs across every open offensive framework.

Sliver's signature-resistance โ€” the per-binary keys, the customizable and encrypted transport, the dynamic compilation โ€” was not smuggled in. It was built on purpose, because an adversary-emulation tool that a defender's existing signatures catch instantly is a useless emulation. If Sliver were easy to detect, it would fail at its stated job: it could not honestly test whether a defense catches a competent intruder, only whether it catches an incompetent one. So evasion was a requirement, delivered deliberately, to make the red-team exercise meaningful.

And that exact evasion transfers, byte for byte, to the criminal holding the same binary. The tool cannot tell whose defense it is evading. The properties Bishop Fox engineered so a blue team's practice would be realistic are the properties that make a ransomware crew's intrusion hard to catch โ€” because "realistic against a good defender" and "effective against a good defender" are the same sentence. The criminals did not out-innovate the defenders. They inherited an evasion capability that was written, marketed, and shipped as a feature, by people trying to help defenders, for defenders' own benefit. That is not a knock on Bishop Fox; it is the structural trap of publishing capability. You cannot build a realistic adversary emulator without building a realistic adversary.

6. Steelman: doesn't open-sourcing offensive tools help defenders more?

The counter-argument is serious and deserves its strongest form. Open offensive tooling is good for defense in ways that are easy to underrate. It lets defenders study exactly what they will face, build detections against a known quantity, train realistically, and stop pretending the adversary lacks capabilities the whole internet already has. Security-through-obscurity โ€” hiding offensive capability and hoping attackers don't develop it โ€” has failed every time it has been tried. Bishop Fox publishing Sliver arguably raised the defensive floor by making a serious C2 studiable by everyone, not just those who could afford Cobalt Strike or write their own.

That case is real, and this letter does not pretend to refute it โ€” because it is probably, on balance, correct. But it does not erase the cost, and honesty requires naming both sides of the ledger. Publishing Sliver raised the defensive floor and handed APT29 a free, capable, low-profile C2. Both happened. The open-source-security debate is not resolved by pretending one column of the ledger is empty; it is conducted by admitting that capability, once released, is genuinely available to everyone, and that "everyone" includes the SVR. The honest position is not "Sliver should not exist" and not "Sliver's abuse is costless." It is that releasing capability is a real decision with real costs on both sides, and the record of who uses Sliver is the cost side, entered into evidence.

7. The seven questions

Who? Bishop Fox built and publishes it; APT29, North Korean operators, TA551, Exotic Lily, and ransomware crews (Nitrogen, Play) use it.

What? An open-source, Go-based, cross-platform C2 framework with full intrusion capability โ€” shell, escalation, injection, lateral movement, credential access โ€” over encrypted, per-binary-keyed channels.

When? In active abuse across recent years (Nitrogen, Sept 2024; ongoing state and criminal use); one local honeypot sighting in the 2026 window.

Where? Globally; C2 servers commonly on mainstream cloud (the disposable-instance model of 075B). The honeypot saw it once.

Why? Detection-arbitrage โ€” a free, capable, lower-profile alternative to the heavily-signatured Cobalt Strike.

How? git clone, compile a per-target implant, deploy over mTLS/DNS/HTTP(S), operate the intrusion; or, for criminals, deliver via a loader (BumbleBee) as a ransomware precursor.

So what? A tool built and named to emulate the adversary is now standard adversary equipment โ€” the Armory thesis stated by the tool itself, on its own label.

8. Read between the lines

The deepest thing Sliver says is that the boundary between offense and defense in this field is not a wall โ€” it is a revolving door, and it turns in one direction more easily than the other.

Capability flows out of the defensive community and into the offensive one with almost no friction: a git clone, a compile, a deploy. It flows back the other way โ€” offensive knowledge becoming defensive detection โ€” slowly, expensively, and always after the fact, because you cannot write the signature until you have seen the tool used, and by then it has been used. Sliver is a snapshot of that asymmetry. Bishop Fox released it to help defenders; the fastest, frictionless beneficiaries were attackers, who needed only to download it; the defenders it was meant to help then had to spend years learning to catch it โ€” catching, that is, the tool their own community had handed the attackers. The door turns freely toward offense and grinds toward defense, and the net flow of capability is outward even when the net flow of intent was meant to be inward.

This is not an argument against open offensive tooling. It is an argument for holding no illusions about it. The moment a capability is published, it is the adversary's capability too, and the only question left is how long the defensive community takes to catch up to the tool it built โ€” a race it starts, every time, one lap behind.

9. Detection and defence

  1. Detect behavior, not the binary. Sliver's static signature was engineered away on purpose. Hunt the behaviors โ€” anomalous mTLS/DNS beacon cadence, process injection, named-pipe artifacts, PsExec lateral movement, SOCKS tunnels โ€” that survive per-binary keying and customization.
  2. Do not attribute from the tool. Sliver in a capture means "a capable, detection-aware actor," not "APT29" and not "a ransomware crew." The tool is a crossroads that state and criminal actors both use; attribution must come from the infrastructure, targeting and tradecraft around it.
  3. Track adoption against your own coverage. Actors migrate toward tools you are not yet watching. Assume the next capable-but-unwatched framework is already being adopted, and invest in tool-agnostic C2 detection rather than chasing each framework's signature one migration behind.
  4. Treat 'evasion features' as adversary capabilities. Every stealth property marketed to red teams is a property your attackers will also hold. Evaluate offensive frameworks by assuming their best features are pointed at you.
  5. Assume the capability is available. Plan defense as if every actor has a free, capable, low-profile C2 โ€” because, via Sliver and its peers, every actor does.

10. The Armory, placed

Letters B and C found the dual-use thesis in infrastructure and in operators. Letter D finds it in the tool itself, in the sharpest possible form โ€” a framework whose name is the confession. The two letters that follow stay at the heavy end: Havoc, the open-source C2 that followed Sliver's path, and AdaptixC2, the newer framework whose abuse curve is still climbing. Each will tell a version of the same story, because it is one story: the offensive community publishes capability to help defenders; the capability is capability regardless of who holds it; and the shelf Bishop Fox stocked is the shelf the SVR shops from.

11. Sources

Confidence: HIGH on the threat class โ€” Sliver's nature, capabilities, and abuse by named actors are documented across multiple independent industry sources. The local grounding is deliberately and openly minimal (one honeypot sighting); this letter is OSINT-led and states so, treating the external record as the evidence and the local data as a confirmatory pin, per the series' honesty standard rather than in spite of it. Actor attributions (APT29, North Korea) are carried at the sources' confidence, not asserted independently. TLP:WHITE โ€” no exploit specifics, operational detail, or operator secrets; the framing is defensive throughout, and no claim of wrongdoing is made against Bishop Fox โ€” the opposite is the structural point.

โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Armory โ€” 4 / 26 Next โ†’