In the Pyramid of Pain, why is renaming an implant's mutex cheaper than changing tools?

## What sits on the artefact rung The fourth rung of the Pyramid of Pain is network and host artefacts, and the phrase hides how mundane the contents are. On a host, these are the names and values a build chooses for itself: - the **mutex** it creates on start so a second copy does not run alongside the first - the **named pipe** it opens for local communication between components - the **service name**, **display name** or **scheduled-task name** it installs itself under - the **registry value name** or **install directory and filename** it writes to - on the network side, the **user-agent string** it sends, a fixed **URI path**, a header order, a distinctive request cadence Every one of those is a decision the tool's author made once and wrote into the source, or exposed as a field in a builder that generates configured payloads. None of them is load-bearing: a mutex works whether it is called `Global\7f21ac` or `Global\update-svc`, and the implant does not care which. ## Why the swap is cheap The change is: edit a literal, build, test that the build still runs on a machine resembling the target, ship. For a crew with any build discipline that is an afternoon, and for a crew whose builder exposes the field it is a dropdown. Nothing the crew can do is lost. Their capability is intact, their operators know the same workflow, their infrastructure is untouched. It is not literally free, which is worth saying out loud because it distinguishes a careful answer from a glib one. They still rebuild, still re-test, and anything already deployed with the old name does not update itself - so for a while they are running two generations with different strings, which is its own operational annoyance. Hours, not weeks. ## Why the tool rung is dear The rung above is not a string, it is the capability. If the tool has to go, the crew loses what the tool *does* - the way it stages code, the way it keeps a foothold, the way it moves data. Replacing that means one of: 1. **Write a new one.** Development time measured in weeks or months, plus testing against a realistic target, plus the new tool's own bugs. 2. **Buy or rent one.** Money, a supplier relationship, and whatever that supplier's other customers have already spent the tool's novelty on. 3. **Fall back to something they already have.** Cheapest, but the fallback is usually the tool they liked less, and effectiveness drops. All three carry a second cost that candidates usually miss: **operator familiarity**. A crew that has run one framework for three years has habits, scripts and instincts built around it. A new tool makes experienced operators temporarily clumsy, and clumsy operators make noise. ## When the gap collapses Two cases are worth naming, because they are what separates a middle answer from a senior one. **Rented tooling.** If the crew buys a builder rather than owning the source, they can change only what the builder exposes. A hard-coded pipe name inside a compiled component is not theirs to edit. For them the artefact rung and the tool rung both move at the supplier's pace, and the pyramid's neat one-rung gap disappears. **Commodity capability.** Conversely, when the tool is a widely available framework with a dozen equivalents, the tool rung is far cheaper than the model implies: swapping is a download and a week of familiarisation, not a development project. The rung is dear when the tool is bespoke, encodes years of work, or is the thing the whole crew's workflow is built around. ## The transferable point Both rungs are priced by *what the crew has to regenerate*. A string is regenerated by a build they already run. A capability is regenerated by engineering they have to fund, or by a purchase they have to make. That distinction - regenerated by an existing process versus acquired anew - is the real content of the pyramid's middle, and it is a better answer than reciting that artefacts are annoying and tools are challenging.