cobalt-strike.md (5755B)
1 --- 2 title: "Cobalt Strike" 3 description: "Cobalt Strike operator reference: beacon commands, listeners, pivoting and post-exploitation." 4 category: tools 5 tags: [c2, post-exploitation, red-team] 6 tools: [Cobalt Strike] 7 difficulty: advanced 8 updated: "2026-08-09" 9 source: "vault:Tools/Cobalt-Strike-Cheatsheet.md" 10 --- 11 12 # Cobalt Strike 13 14 > **Context —** Authorised red-team / lab C2 reference. Tool: Cobalt Strike (operator quick-ref). 15 16 Licensed adversary-simulation / C2 framework. This note is a **high-level operator checklist** for authorised engagements and lab study — not a piracy, crack, or bypass guide. Confirm every command against your licensed build's UI help and the vendor user guide for your version. 17 18 Related notes: Mimikatz, Rubeus, NetExec, Impacket, BloodHound, NTLM & Kerberos Relay. 19 20 --- 21 22 ## Summary 23 24 Cobalt Strike centres on a **team server**, a GUI/client, **listeners**, and **Beacon** sessions. Operators stage payloads, manage callbacks, run post-ex jobs, and coordinate lateral movement under a shared log. Treat it as a commercial C2: licensing, Malleable C2 profiles, and infrastructure OPSEC matter as much as individual Beacon commands. 25 26 > **Danger — authorised-use framing** 27 > 1. Use only with a valid licence and written authorisation. 28 > 2. Do not distribute cracked clients/servers or "update" cracks — out of scope for this note. 29 > 3. Align profile, redirectors, and kill dates with ROE and deconfliction. 30 31 --- 32 33 ## Team Server & Client 34 35 ```bash 36 # Typical lab pattern (paths/version-specific — verify locally) 37 ./teamserver <teamserver_IP> <password> [malleable.profile] 38 # Client connects to teamserver_IP with the shared password 39 ``` 40 41 > **Infrastructure basics** 42 > 1. **Team server** should sit behind redirectors; do not expose it directly to the internet. 43 > 2. Use a strong shared password; rotate per engagement. 44 > 3. Load a **Malleable C2** profile appropriate to the environment before phishing/staging. 45 > 4. Record listener ports, domains, and kill dates in the engagement runbook. 46 47 --- 48 49 ## Listeners & Payloads (concepts) 50 51 | Piece | Role | 52 |---|---| 53 | Listener | Defines how Beacon calls back (HTTP/HTTPS/DNS/SMB/TCP, etc.) | 54 | Payload / stageless artefact | Dropper or export generated for a listener | 55 | Malleable profile | Shapes network indicators to match allowed patterns | 56 | Staging vs stageless | Staged pulls stage0→stage; stageless embeds — trade size vs flexibility | 57 58 > **Operator checklist** 59 > 1. Create listener → generate artefact for the right arch (x86/x64). 60 > 2. Prefer HTTPS + valid-looking infra over raw IP:port in hostile networks. 61 > 3. SMB/TCP beacons are for **egress-limited** pivots inside the estate. 62 > 4. Name listeners clearly (`prod-https-redir1`) so multi-operator teams do not collide. 63 64 --- 65 66 ## Beacon Operator Essentials 67 68 > **Common console verbs (names stable across many versions; confirm in your build)** 69 > 1. **Situational**: `help`, `sleep`, `ps`, `pwd`, `ls`, `cd`, `drive`. 70 > 2. **Jobs / inject**: `jobs`, `jobkill`, `inject`, `spawnto`, `ppid` (OPSEC-sensitive). 71 > 3. **Creds / tokens**: `getuid`, `steal_token`, `make_token`, `rev2self` — pair with Mimikatz tradecraft only when approved. 72 > 4. **Files**: `upload`, `download`, `browserpivot` (as available in your version). 73 > 5. **Lateral**: prefer documented built-ins / approved BOFs over random scripts; Impacket/nxc from a pivot host is often cleaner for labs. 74 75 ```text 76 # Illustrative Beacon hygiene (not a full command bible) 77 sleep 60 10 # jittered callback — reduce chatty C2 78 getuid 79 ps 80 # run approved post-ex modules only under ROE 81 ``` 82 83 > **Warning — keep this sheet intentionally thin** 84 > 1. Full Beacon/Aggressor encyclopaedias belong in your licensed user guide. 85 > 2. Lab exams (CRTO-style) expect vendor docs + course notes — use those as source of truth. 86 87 --- 88 89 ## OPSEC Checklist 90 91 1. Sleep/jitter appropriate to detection risk; avoid interactive spam. 92 2. `spawnto` / parent PID spoofing only with a story that matches the host. 93 3. Long-haul vs short-haul listeners separated; burn short-haul after staging. 94 4. Log operator actions; attribute every lateral move to a ticket/finding. 95 5. Kill date / dead-man switches set before phishing. 96 6. Deconflict with blue team when ROE requires it. 97 98 --- 99 100 ## Engagement Workflow 101 102 ```text 103 1. Build redirectors + teamserver + profile 104 2. Stand up listeners (long-haul / short-haul) 105 3. Generate artefacts for approved initial-access path 106 4. Establish Beacon → situational awareness 107 5. Credential / ticket work per ROE (Mimikatz/Rubeus/CS modules) 108 6. Lateral with least noise that still meets objectives 109 7. Capture evidence → clean up persistence → tear down infra 110 ``` 111 112 --- 113 114 ## Troubleshooting & Gotchas 115 116 > **Common failures** 117 > 1. **No callback**: profile host/URI mismatch, broken redirector, or egress filter — verify with a controlled lab implant first. 118 > 2. **Team server reject**: clock skew, wrong password, or version skew between client and server. 119 > 3. **Beacon dies after sleep change**: unrealistic sleep/jitter or network middleboxes — stage carefully. 120 121 --- 122 123 ## Lessons Learned 124 125 1. Infrastructure and profiles win engagements before fancy post-ex. 126 2. Name listeners and log everything — multiplayer C2 is a coordination problem. 127 3. Use CS for C2 continuity; use Impacket/nxc/Rubeus when they are quieter or clearer for a specific task. 128 4. Keep piracy and "cracked CS" material out entirely. 129 5. Version drift is real — re-check help after upgrades. 130 131 --- 132 133 ## References 134 135 1. Cobalt Strike (Fortra) — https://www.cobaltstrike.com/ 136 2. Vendor user guide for your licensed version (Fortra documentation portal) 137 3. MITRE ATT&CK — Command and Control (TA0011) 138 4. SpecterOps / community OPSEC blogs — https://posts.specterops.io/