Focused Solution · E-ITDR
Cobalt Strike
detection and investigation
Cobalt Strike can reshape its traffic, inject into legitimate processes and land without a file. But using someone else's privilege to reach another machine still requires a credential — and what that leaves behind is what this solution is organised around. Every detection item states its platform, its collection prerequisites and how far it has been verified; nothing unverified is written up as covered.
Threat Context
When the tooling is legitimate, there is little left to judge on
Cobalt Strike is a commercial penetration testing framework that is also widely used as post-exploitation tooling in real intrusions. What makes it hard is not the strength of any one module: it runs the whole chain on mechanisms the operating system already provides — remote execution through system services, privilege escalation through token manipulation, persistence through scheduled tasks. Each step, on its own, looks like administration.
One thing to be clear about first: this does not mean existing tools detect none of it. Major endpoint products publish detection coverage for Cobalt Strike related behaviour and credential theft (Microsoft Security Intelligence). What this solution adds is a different layer: when both the tool and the credential are legitimate, it puts the grounds for judgement back on identity and authentication — and states how far each item has actually been verified.
Detection Coverage
Detection areas and supporting evidence
Review each behaviour, detection basis, platform and collection prerequisite. Rule matches and correlated evidence support investigation; specific techniques and samples require validation in the agreed environment.
| Detection area | Typical action | What E-ITDR judges on | Platform and prerequisites | Status |
|---|---|---|---|---|
| Credential theft | Dumping credentials from process memory, exporting credential files, imitating directory replication | Abnormal access to credential stores and process memory; a directory service receiving a replication request that host should never make | Windows; security log and process collection, with the matching audit policy enabled | Rule in catalogue |
| Abnormal authentication | Authenticating to other hosts with the credential just taken | One credential appearing across several hosts in a short window; authentication chains that downgrade or relay | Windows domain environment; logon and authentication event collection | Rule in catalogue |
| Remote execution | Running commands on a target host through a remote service | Execution started through a remote service, judged together with the initiating identity, the target's importance and delegation settings | Windows; process and service collection | Rule in catalogue |
| Delegation and ticket abuse | Unusual ticket requests, delegation settings modified | Tickets requested or aged in ways that do not fit; delegation and directory object changes | Windows domain environment; directory object change collection | Rule in catalogue |
| Persistence | Creating services, scheduled tasks, event subscriptions and autostart entries | Service and scheduled task creation, registry autostart changes, abnormal event subscriptions | Windows; service, task and registry collection | Rule in catalogue |
| Token manipulation | Stealing or forging process tokens, named pipe impersonation | Abnormal changes in process token and privilege context, judged together with what follows | Windows; needs ETW process and kernel auditing, invisible at lower collection levels | Depends on collection |
| Process injection | Writing and executing code inside a normal process | Abnormal writes to process memory and abnormal module loads | Windows; needs ETW process collection, invisible at lower collection levels | Depends on collection |
"Rule in catalogue" means the current rule catalogue contains a matching rule that can be reproduced in a demonstration environment. It does not mean it is visible by default in your environment. Whether an alert actually fires depends on the platform, the collection level, run-time permissions, audit policy and log visibility — which is why the fourth and fifth columns have to be read together.
This table lists rules and collection evidence available for investigation. Validate specialist coverage against the product version, samples and collection conditions; it does not promise detection of every technique or variant.
Evidence
Three kinds of evidence along one chain
The five stages below are the positions this kind of activity usually passes through. What a verdict actually rests on is not which stage happened, but the fields each one leaves behind — so the three kinds of evidence are listed separately.
A structural illustration, not a product screenshot. Whether a field can be obtained depends on that host's collection level and audit policy; fields that cannot be obtained are marked as gaps in the investigation view, never filled in by inference.
Correlation
Turning scattered points into a path you can retell
A single alert describes one fragment. Answering where it came from, how far it went and what it touched means organising those fragments by account, host and time — and marking clearly which stretch is inference.
A line is not causation, and an account is not a person. This solution does not attribute: matching the characteristics says this class of activity is present, not that it is a particular tool; and even a confirmed tool does not confirm who was operating it. How any of this is stated externally is for the organisation to determine under the law that applies to it.
Response
Six stages, and who owns each one
Containment and eradication affect the business directly, so every action has to say who executes it and what authorisation it needs. This solution owns the endpoint-side actions that can be authorised; the rest stays with the systems that already own them.
| Stage | E-ITDR | Executed by |
|---|---|---|
| Confirm | Supplies the alert, the grounds and the correlated path | A SOC analyst confirms whether the conclusion holds |
| Contain | Isolates a host or stops a process under authorisation and approval, reporting status | Disabling accounts runs in the identity system; blocking traffic runs on the network side |
| Eradicate | Handles files and collects evidence under authorisation | The scope and order of removal are set by the incident response process |
| Recover | Not executed on your behalf | Restore runs in the backup system with the business teams; credential resets run in the identity system |
| Investigate | Outputs the path, assets involved, account usage and file access records | The investigation team signs off the conclusion |
| Report | Provides an exportable evidence set | External wording and responsibility are determined by the organisation under applicable law |
High-risk actions require role permissions, approval and review, and depend on the agent being online and the command channel reachable. A receipt may say success, failure or timeout; success does not mean the threat is gone — the agreed scenario still has to be re-tested.
Scope & Limits
Objectives written up front, results filled in from the test
The cases below can be taken into an authorised test scope. Objectives and results are recorded separately: the objective is agreed in advance, the result can only come from a real test, and until then it stays empty.
| Case | Test objective | Actual result |
|---|---|---|
| Credential access | Reproduce a credential dump on an agreed host; check that an alert fires and that the grounds can be explained | To be measured |
| Abnormal authentication | Authenticate to a second host with that credential; check the cross-host correlation holds | To be measured |
| Remote execution | Execute on a target through a remote service; check the identity and target fields in the alert | To be measured |
| Persistence | Create a service or scheduled task; check the alert carries name, creator and execution path | To be measured |
| Chain correlation | Check whether the fragments above form one path, and whether gaps are marked | To be measured |
| Authorised response | Run one isolation or forensic action; check the receipt and the re-test | To be measured |
Agree the hosts, accounts, technique list, time window and acceptance criteria before testing, and record the collection prerequisites alongside them (run-time permissions, audit policy, collection level) — the same case run under different collection conditions produces results that cannot be compared. No detection-rate figures are reported until testing is complete. What the demonstration environment shows is a product demonstration scenario, not any customer's actual incident record.
Expert Consultation
Pick the techniques you care about and agree an authorised test
Tell us about your endpoint mix, your domain environment and the techniques on your list, and we will demonstrate detection for them, list the collection prerequisites, and state where each one currently stands:
Item-by-item review
Platform, prerequisites and current status
Scenario-based demonstration
Alerts and evidence for the techniques you name
Authorised test scope
Cases, time windows and acceptance criteria agreed together
Scan with Feishu to consult