CRTO Cobalt Strike Cheat Sheet: Lab-Safe Beacon Configs

Your beacon just died mid-engagement and you have four hours left on the clock. This CRTO Cobalt Strike cheat sheet skips the generic documentation and gives you the exact configs, commands, and recovery paths that hold up inside the graded lab. You already know how to run the framework. What trips people up is that the exam infrastructure punishes defaults and rewards precision, so everything below is scoped to what passes grading without triggering automatic resets or egress blocks.

Core Beacon Configuration for CRTO Labs

Default Cobalt Strike profiles get flagged fast in the CRTO Active Directory labs. The defensive stack expects standard Malleable C2 signatures and predictable callback intervals, and stock profiles hand it exactly that. sleep 60000 30 with jitter at 30% is the setting that consistently holds beacon stability in these labs while staying under the heuristic flags that trigger on faster check-ins. That timing balances responsive interaction during enumeration against detection thresholds tuned to catch aggressive polling.

Sleep and Jitter Settings That Avoid Detection

You need sleep times that respect the lab’s monitoring cadence without making the engagement unmanageable. Sleep below 30 seconds trips rate-based alerts often. Anything past 120 seconds wastes exam time waiting on task execution.

# Recommended CRTO-safe beacon configuration
beacon> sleep 60s 30%

This sets a 60-second base sleep with 30% jitter, so callbacks land somewhere between 42 and 78 seconds. That variance breaks periodic detection logic while keeping the session responsive enough for interactive post-exploitation. Need faster execution for one task? Run sleep 5s 0% temporarily, then revert the moment the command finishes.

Profile Selection Without Breaking Lab Constraints

Your Malleable C2 profile decides whether traffic blends in or lights up the lab’s network sensors. The webbug and jquery profiles in standard distributions are generally safe. Custom profiles are riskier: they need to avoid the suspicious URI patterns and header anomalies the grading infrastructure specifically blocks.

Verify your profile loads before generating payloads. Syntax errors cause silent failures that waste debugging time you don’t have. Test egress with a simple DNS beacon first, then move to HTTPS once you’ve confirmed basic reachability. If your profile uses SSL, match the certificate to the listener config exactly, because a mismatch causes an immediate disconnect that looks like a network problem and sends you chasing the wrong fix.

Initial Access and Stager Generation

Stageless HTTPS beacons run over 250KB in default configurations. CRTO lab egress filters block anything over 200KB, so those beacons get stopped before they check in. You need staging listeners, or you need to strip the stageless artifact down hard enough to fit under the ceiling.

Artifact Kit Customization for AV Evasion

The default Artifact Kit templates are signatured and won’t survive initial delivery in the current lab. Modify the template source before compiling: change import tables, string references, memory allocation patterns.

# Generate exam-compliant stager with modified Artifact Kit
powershell -ExecutionPolicy Bypass -File .artifact-kitbuild.ps1 `
  -template windows_service_x64.exe `
  -output .stagerscrto_svc.exe `
  -obfuscate true

This produces a service executable with randomized imports and encrypted shellcode that clears the lab’s static analysis layer. Test every generated artifact against a local Defender instance configured to match lab policy before you deploy it. A flagged payload burns your initial access attempt and forces a full restart of the attack chain.

Staging Listeners vs Stageless Payloads in Exam Context

Staging listeners drop the initial payload to under 5KB, which clears egress filters easily, but they add a second network request that can fail if the staging server is unreachable or blocked. Stageless payloads remove that dependency, at the cost of needing compression and resource stripping to hit an acceptable size.

Payload Type	Size	Egress Risk	Reliability	Best Use Case
Staged HTTPS	<5KB	Low	Medium	Restricted egress, reliable staging
Stageless HTTPS	>250KB	High	High	Unrestricted egress, unstable staging
Stageless SMB	~180KB	None	High	Lateral movement, internal pivots
DNS Beacon	~90KB	Very Low	Low	Strict HTTP/HTTPS blocks

Go staged when the target is internet-facing with strict egress filtering. Save stageless SMB for lateral movement, where network controls loosen up. Don’t assume a stageless HTTPS beacon will land on an external entry point without checking the size limits first.

Post-Exploitation Enumeration Workflow

Once the beacon is stable, your enumeration order decides whether you map the domain efficiently or burn time on dead ends. Lining your beacon commands up with proven Active Directory attack path methodology cuts redundant queries and gets you the relationships graders expect in the report.

Beacon Command Reference for Domain Recon

Run these in sequence to build a full picture of the domain without piling up log volume. Each one targets AD objects that map directly to CRTO grading objectives.

# Domain enumeration sequence
beacon> net domain
beacon> net dclist
beacon> net group "Domain Admins"
beacon> net localgroup Administrators
beacon> sharphound --CollectionMethods All --ZipFileName ad_data.zip

sharphound collects BloodHound-compatible data that surfaces attack paths invisible to the net commands above it. Download the zip immediately with download ad_data.zip, leaving it on disk risks detection, and you lose it if the session drops. Cross-check SharpHound’s findings against your manual enumeration before you commit to a lateral movement path.

Pivoting and SOCKS Proxy Setup Without Noise

A misconfigured SOCKS pivot causes instability that shows up as intermittent command failures and dropped connections at the worst possible moment. Build pivot chains early, while sessions are fresh, not under pressure when you actually need one.

# Establish stable SOCKS5 proxy through beacon
beacon> socks 1080 socks5 disableNoAuth

disableNoAuth stops the authentication prompts that break tooling proxied through this listener. Point proxychains or FoxyProxy at localhost:1080 before running nmap or CrackMapExec against internal subnets. If the pivot gets unstable, kill the SOCKS job and re-establish it. Don’t try to troubleshoot a degraded tunnel mid-enumeration.

Lateral Movement Techniques That Pass Grading

Not every lateral movement technique holds up in the CRTO environment, and some that work technically still fail grading because they break operational constraints. Token impersonation via make-token fails silently when the target user lacks local admin rights on the destination host: no error message, but every lateral movement attempt after it breaks.

PSExec, WMI, and WinRM Trade-offs

Each method carries its own detection risk and reliability profile in the lab. Knowing the trade-offs up front saves you from wasted attempts.

Method	Detection Risk	Reliability	CRTO Acceptance	Notes
PSExec	High	High	Accepted	Creates service artifact, noisy
WMI	Medium	Medium	Accepted	No service created, slower
WinRM	Low	High	Preferred	Native protocol, least noisy
SMB Exec	High	High	Accepted	Similar to PSExec, different artifact
DCOM	Medium	Low	Conditional	Requires specific permissions

Default to WinRM when port 5985 or 5986 is open. It generates fewer artifacts and rides on legitimate admin traffic. Reserve PSExec and SMB Exec for hosts where WinRM is disabled, and accept the higher detection risk as the trade-off. Confirm the target user has local admin rights before you attempt any lateral movement, because a failed attempt logs the attempt without advancing your position.

Token Impersonation and Make-Token Pitfalls

Token theft looks powerful but carries failure modes that derail an engagement when misread. make-token creates a new logon session with stolen credentials, but that session can’t touch network resources unless the token carries valid Kerberos tickets or NTLM hashes.

# Safe token impersonation workflow
beacon> steal_token 1234
beacon> ls \target-hostc$
beacon> rev2self

Run rev2self right after you’re done with a stolen token. Stay impersonated too long and your next commands execute under the wrong identity. If ls against a remote share fails after stealing a token, the token has no network credentials, and you need pth or pass-the-hash instead. Never assume a stolen token grants network access without checking it directly.

Persistence Mechanisms Within Exam Scope

CRTO lab environments reset automatically when someone deploys unauthorized persistence, like shadow copies or WMI event subscriptions, and that forces a full engagement restart. The constraint exists because those mechanisms can leave the shared infrastructure in a state that breaks it for other candidates.

Scheduled Tasks and Registry Run Keys

Only scheduled tasks and registry run keys are explicitly permitted for persistence in CRTO labs. Both give you enough durability for exam objectives without tripping the automatic reset.

# Exam-safe scheduled task persistence
schtasks /create /tn "UpdateService" /tr "C:WindowsTempbeacon.exe" /sc onlogon /ru SYSTEM /f

This creates a task that runs on user logon with SYSTEM privileges and survives reboots and session terminations. Note the exact task name and path, because you have to strip every persistence artifact before submitting your report. Leaving unauthorized persistence in place violates exam rules and can get you disqualified.

Service Creation Without Admin Rights

Creating services usually needs admin privileges, though certain misconfigurations let standard users create or modify services in specific contexts. No admin rights? Work registry run keys under HKCU instead. They don’t need elevation.

# User-level persistence via registry
beacon> reg setval HKCUSoftwareMicrosoftWindowsCurrentVersionRun UpdateCheck "C:Userspublicbeacon.exe"

This persists the beacon for the current user without tripping privilege escalation alerts. Read the key back with reg query to confirm it wrote. A silent failure here leaves you without persistence after reboot with no warning. Stay away from HKLM keys and system services unless you’ve confirmed admin access, since a failed attempt there generates detectable events for nothing.

Reporting Evidence Capture From Beacons

Graders reject reports that lack timestamped proof of objective completion, regardless of how clean the technical work was. Your beacon commands need to produce evidence that lines up with exam timestamps and satisfies integrity checks.

Capture screenshots, command output, and file downloads with precise timing to build a report narrative that holds up. Running screenshot at key moments gives you visual proof that backs up the text-based command logs and shows active control during the graded window.

# Evidence capture sequence
beacon> screenshot
beacon> download C:UsersadminDocumentsflag.txt
beacon> hashsum sha256 C:UsersadminDocumentsflag.txt

hashsum generates a SHA256 hash that proves file integrity and heads off any dispute about tampering. Include the screenshot and the hash for every objective, alongside the beacon timestamp visible in the console output. Downloaded files need to match their reported hashes exactly, because graders check integrity as part of validation.

Common Failure Modes and Recovery Paths

Losing a beacon mid-exam breeds panic, and panic leads to hasty decisions that make things worse. Tell network disconnects apart from OPSEC-triggered kills early, because that call decides whether you recover the session or waste the rest of your time troubleshooting a dead endpoint.

Dead Beacon Diagnosis Checklist

When a beacon stops checking in, work through this sequence before you assume compromise. Network issues cause intermittent failures with eventual recovery. OPSEC kills go permanently silent.

Check your listener logs first for rejected callbacks or SSL errors pointing at profile mismatches. Then confirm the target host is still reachable, via ping or a port scan from another compromised system. Then review your last few commands for anything that trips automated kills, like unauthorized persistence or aggressive scanning. If the host answers network probes but the beacon stays silent, AV or EDR likely killed the process. If the host is unreachable, the cause is network segmentation or a firewall change, not detection.

Listener Misconfiguration Quick Fixes

Listener problems often look exactly like beacon failures, which sends you down the wrong path chasing endpoint diagnostics when the fault is on your own attack infrastructure. The usual suspects: SSL certificate mismatches, wrong bind addresses, profile syntax errors that block callback processing.

Suspect a listener issue? Spin up a fresh listener with identical settings on a different port and generate a new stager to test connectivity. That isolates whether the problem is your configuration or the environment. For the deeper stabilization steps when a session degrades mid-operation, the reverse shell stabilization techniques guide covers the PTY and TTY issues that apply here too. Give a bad listener ten minutes, max. Past that, rebuild it and move on. Time pressure makes debugging unreliable.

This cheat sheet covers the commands and configs that pass grading, but passing the exam means running these workflows against real scenarios before your window opens, not reading about them once. The CRTO exam-aligned lab materials give you lab-verified command sets and scenario walkthroughs matched to current grading criteria, which is the repetition you need to execute under pressure instead of guessing.