Your Cobalt Strike beacon triggered an EDR alert on its default profile — can you claim the technique is detected?
answer
- alert matched the default, not the technique
- stock profile, named pipes, default cert
- change the profile and it passes
- detected-only, of the tool
- rerun customised to test what remains
basics
~20 sNo. If the alert fired on Cobalt Strike's default artefacts — its stock malleable profile, default named pipe names or default certificate — you detected the tool's defaults, not the technique. Change the profile and the same behaviour would sail through. You proved the SOC catches an out-of-the-box beacon, not the tradecraft.
solid answer
~60 sNot honestly. The result you can defend depends on *what* the alert matched. Operator C2 like Cobalt Strike ships with recognisable defaults — a stock **malleable C2 profile** (default HTTP headers and URIs), default **named pipe** names for SMB beacons, a well-known default TLS certificate. Those defaults are the most-signatured things in the product, so an out-of-the-box beacon lights up EDR the moment it runs. If that is what alerted, you have validated one narrow thing: your stack catches the *default configuration of the tool*. You have not validated detection of the underlying technique, because an operator who changes sleep, jitter, the pipe name and the profile — as any competent adversary would — produces the same C2 behaviour with none of those artefacts, and would pass. The honest claim is "detected-only, on the tool's default," and the follow-up is to rerun with a customised profile to see whether anything behavioural remains. Attributing a real intruder's detectability to a stock-profile hit is exactly the misattribution these exercises exist to avoid.
go deeper
Know that an alert firing means a detection matched something — not necessarily the technique — and that C2 tools ship recognisable default artefacts.
Explain which defaults get signatured — stock malleable profile, named pipe names, default certificate — and why changing sleep, jitter and the profile removes them.
State the honest verdict: detected-only of the tool's default configuration, and the rerun with a customised profile that tests whether any behavioural detection remains.
Own how emulation results are reported so a default-artefact hit is never sold to leadership as C2 coverage — the difference between proving you catch a lazy operator and proving you catch an adversary.
## The distinction that decides the answer An alert firing tells you a **detection fired** — it does not tell you *what the detection matched*. For operator command-and-control, that difference is everything, because these tools ship with defaults that are among the most heavily signatured artefacts in the whole security industry. **Cobalt Strike's defaults**, out of the box, include: - a **default malleable C2 profile** — the profile that defines the HTTP request/response shape (URIs, headers, user-agent), and the stock one is fingerprinted by every EDR and network vendor; - default **named pipe** names for its SMB/peer beacons (pipe names that pattern-match instantly); - a well-known default **TLS certificate** for HTTPS beacons; - default **process-injection** and post-exploitation behaviours with recognisable signatures. So when an unmodified Beacon runs and EDR alerts, the overwhelmingly likely cause is a match on one of those **default artefacts** — not a match on the *technique* the beacon is performing (say, HTTPS C2 or SMB lateral movement). ## Why "detected" would be the wrong verdict The outcome you may honestly claim is **detected-only, of the tool, not the behaviour**. The reasoning: 1. A real, competent adversary does **not** run defaults. They change the **sleep** interval and **jitter** (to break timing signatures), rename the **named pipes**, load a **custom malleable profile** (to change every network indicator), and often front the C2 behind a **redirector** on a legitimate-looking SaaS or CDN hostname. 2. Every one of those changes removes the exact artefact your alert matched. 3. Therefore the *same technique*, executed with a customised profile, would produce **no alert** — the detection does not generalise to the behaviour. Claiming "the technique is detected" from a stock-profile hit **overstates coverage**. You would tell leadership you catch C2 when you actually catch only the lazy, unmodified case — the version a real intruder would never ship. ## The honest verdict and the next step The defensible statement is: *"With the default Cobalt Strike profile, EDR alerted; this validates detection of the tool's default configuration only. Detection of the underlying C2 behaviour is unproven."* The correct follow-up is to **rerun with a customised profile** — change sleep/jitter, pipe names, the malleable profile, the certificate — and see whether *anything* still fires. What survives a profile change is a **behavioural** detection (something about the C2 pattern itself); what disappears was an **artefact** detection (a signature on a default string). Only the former tells you about a real adversary. Note the boundary: *how the defender would hunt that customised channel* — check-in periodicity, jitter, byte-ratio asymmetry in flow, DNS or proxy metadata — is a hunting problem owned elsewhere, and *how you would write a rule against the behaviour instead of the artefact* is a detection-engineering problem owned elsewhere. The point that belongs here is narrower and is about the operator's claim: **what may I honestly say this emulation run proved?** ## Reconciling with your own operator log This is where the operator's own record earns its keep. Your C2 framework logs every task and beacon check-in with timestamps. Reconciled against the defender's DNS and proxy metadata, that log lets you prove *what was actually sent and when* — so you can state precisely that the alert corresponds to the default-profile check-in and not to the technique. Without that ground truth you are guessing at what the EDR matched. ## The interview signal The weak answer is "yes, it alerted, so we detect Cobalt Strike." The strong answer separates **the tool fired an alert** from **the behaviour is detected**, identifies default artefacts (profile, pipes, certificate) as the likely match, predicts that a customised profile would pass, and states the honest, narrow claim plus the rerun that would test it. That is the misattribution the parent theme — *a miss is usually misattributed* — is built around, seen from the false-positive-of-success side: a hit on the tool's defaults masquerading as coverage of the tradecraft.
- What would you change before rerunning, to test whether any detection is behavioural rather than a default-artefact match?Load a custom malleable C2 profile so the HTTP indicators differ, rename the default named pipes, replace the default TLS certificate, and adjust sleep and jitter to break timing signatures — optionally front the C2 behind a redirector on a legitimate-looking hostname. Whatever still alerts after all the stock artefacts are gone is a behavioural detection; whatever stops alerting was a signature on a default string.
- How does your own operator log help you make the honest claim about what alerted?The C2 framework records each task and beacon check-in with timestamps. Reconciled against the defender's proxy and DNS metadata, that timeline lets you match the alert to a specific default-profile check-in, so you can state that the detection corresponds to the tool's default artefact rather than to the technique. Without that ground truth you are inferring what the EDR matched instead of proving it.
saying these in an interview costs you the question
- Concluding the technique is detected because an alert fired
- Not knowing Cobalt Strike ships heavily signatured defaults
- Ignoring that a changed profile removes the matched artefact
- Reporting stock-profile coverage as real C2 detection to leadership
- Confusing a detection firing with what the detection matched