OPSEC Best Practices¶

Comprehensive operational security reference for Stentor operators. This guide covers detection surfaces for every major technique category, the garble obfuscation pipeline, the runtime opsec posture command, a decision matrix for technique selection by environment, and operational recommendations from pre-engagement through cleanup.

Detection Surface by Technique Category¶

Each technique category produces distinct forensic artifacts across different detection layers (endpoint telemetry, network monitoring, log analysis). The sections below map Stentor's capabilities to their detection surfaces with specific MITRE ATT&CK references and recommended mitigations.

Process Injection¶

Credential Access¶

Lateral Movement¶

Persistence¶

Defense Evasion¶

Discovery¶

Garble Obfuscation Pipeline¶

Garble is Stentor's build-time obfuscation tool for Go binaries. It strips, encrypts, or randomizes the forensic artifacts that make Go binaries identifiable and reversible. Understanding what garble fixes and what it cannot fix is essential for OPSEC planning.

Build Pipeline Flow¶

graph LR
    A[Payload Generation<br/>API / CNA Hook] --> B[garble<br/>-seed=random<br/>-literals -tiny]
    B --> C[ldflags<br/>-s -w -trimpath<br/>-buildid=]
    C --> D[Compiled Binary<br/>EXE / DLL]
    D --> E{Shellcode<br/>Wrapping?}
    E -->|Yes| F[Donut<br/>Position-independent<br/>shellcode]
    E -->|No| G[Final Binary<br/>Obfuscated EXE/DLL]
    F --> H[Final Payload<br/>PE headers stripped]

    style A fill:#6a1b9a,color:#fff
    style B fill:#4a148c,color:#fff
    style C fill:#311b92,color:#fff
    style D fill:#1a237e,color:#fff
    style F fill:#0d47a1,color:#fff
    style H fill:#01579b,color:#fff

What Garble Fixes¶

Known Unfixable Limitations¶

These are architectural requirements of the Go runtime. No obfuscation tool can remove them without breaking the binary.

Build Modes¶

Detection Tools¶

Operator Guidance¶

• Garble is evasion, not invisibility. It makes static reverse engineering significantly harder but does not make a binary unanalyzable. A determined analyst with GoReSym can still recover function boundaries.

• Go binaries ARE identifiable as Go. The pclntab magic bytes are an architectural requirement. No obfuscation can change this. If "not Go" is a hard requirement, use the C stager for initial access.

• Wrap garbled implant in shellcode loader. Donut converts the garbled EXE to position-independent shellcode, stripping PE headers and section characteristics entirely.

• Sleep mask protects at runtime. During sleep, the .text section is encrypted in memory, defeating memory scanning for Go patterns.

• -seed=random means every build is unique. Each compilation produces a binary with different symbol names and string encryption keys, defeating signature-based AV detection.

• EDR behavioral detection is orthogonal to garble. Garble only affects static analysis. Behavioral detections (API call sequences, network patterns, thread injection) are not affected by binary obfuscation.

• C stager avoids Go signatures entirely. The MinGW C stager (~23KB) downloads and executes the full implant. It has no Go runtime, no pclntab, no goroutines. Use the C stager when initial access must not look like Go.

Runtime OPSEC Posture Command¶

The opsec command runs the OpsecModule (implant/internal/modules/opsec/opsec.go) and returns a scored posture report with 17 individual checks. Use it to audit a beacon's evasion configuration before executing sensitive operations.

Running the Command¶

Shell syntax:

opsec

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "opsec"
  }'

Example Output¶

[*] OPSEC Posture Report
[*] Score: 71/100

[+] syscall_method: indirect -- APIs routed via ntdll gadgets
[+] sleep_mask: enabled -- .text encrypted during sleep
[+] heap_mask: enabled -- Heap records encrypted during sleep
[!] stack_mask: disabled -- Thread stack visible during sleep
[+] beacon_gate: enabled (25 APIs) -- Sensitive APIs through syscall shim
[!] module_stomp: disabled -- No module stomping (MEM_PRIVATE allocations)
[+] ppid_spoof: explorer.exe -- Child processes spoofed under explorer.exe
[+] spawnto: RuntimeBroker.exe (pool: 7) -- Context-aware rotation
[+] amsi_patched: enabled -- AmsiScanBuffer patched in fork-and-run
[!] etw_patched: disabled -- ETW active in fork-and-run processes
[+] tls_fingerprint: chrome_auto -- uTLS fingerprint spoofing active
[!] sleep_method: direct -- Standard sleep (no timer queue obfuscation)
[+] drip_load_inject: enabled -- Injection memory allocated in small chunks
[+] use_rwx: disabled -- W^X compliant (RW->RX transitions)
[!] udrl: disabled -- Standard reflective loading
[-] edr_hooks: 3 hooked -- Hooked: NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx -- run edr_unhook
[+] hwbp_status: 2/4 DR slots active -- AMSI/ETW bypass via hardware breakpoints

Recommendations:
  - Consider enabling stack masking for additional sleep protection
  - Configure module stomping DLL for MEM_IMAGE backing
  - Consider timer_queue sleep method for Ekko-style timer-based sleep
  - Consider enabling UDRL for custom reflective loading
  - Run edr_unhook to remove EDR userland hooks before injection/credential operations

Score Calculation¶

Each of the 17 checks scores based on its status:

Formula: score = (sum of points / total checks) * 100

A score of 100 means all 17 checks are in the good state. Target a minimum score of 70 for standard engagements and 85+ for EDR-heavy environments.

All 17 Posture Checks¶

Decision Matrix: Technique Selection by Environment¶

Select evasion techniques based on the target environment's defensive posture. The matrix below maps each configurable setting to three environment profiles.

Complete Evasion Profiles¶

Use these copy-paste profiles as starting points for each environment type.

sleep 5
syscall-method none

sleep 60 25
syscall-method indirect
sleep_config sleep_mask on
sleep_config heap_mask on
beacon_gate enable
ppid explorer.exe
spawnto x64 %windir%\sysnative\RuntimeBroker.exe
blockdlls start
hwbp both on

sleep 300 40
syscall-method indirect
sleep_config sleep_mask on
sleep_config heap_mask on
sleep_config stack_spoof on
sleep_config stack_depth 0
sleep_config method timer_queue
beacon_gate enable
beacon_gate mask_on_call true
ppid explorer.exe
spawnto x64 %windir%\sysnative\dllhost.exe
blockdlls start
hwbp both on
argue net1.exe /enum /domain

Runtime Guardrails¶

Runtime guardrails enforce operational boundaries on beacon execution. Configure these at payload generation time to prevent beacons from running in unauthorized environments, after engagement deadlines, or outside operational windows.

Kill Date¶

The beacon checks the current date against the configured kill date on every poll cycle. After the kill date, the beacon executes CleanupArtifacts (removes scheduled tasks, registry keys, and self-deletes) then terminates.

kill_date: 2026-03-31

Working Hours¶

Restrict beacon activity to specific hours and days. Outside the configured window, the beacon calculates the time until the next working period and sleeps for that duration in a single obfuscated sleep call (not a rapid check-sleep loop).

working_hours: 08:00-18:00
working_days: Mon-Fri
timezone: America/New_York

Windows timezone mapping covers 16 common zones. The beacon resolves the Windows timezone name to UTC offset at startup.

Geofencing¶

Restrict execution to specific network environments. The beacon checks these constraints at startup and re-checks every 10 poll cycles.

{
  "geofence_ips": ["10.10.10.0/24", "192.168.1.0/24"],
  "geofence_hostnames": ["WS01", "WS02"],
  "geofence_domains": ["corp.local"],
  "geofence_usernames": ["labuser"]
}

DNS Canary Detection¶

Configure a DNS canary domain that the beacon resolves on startup. If the domain resolves (indicating the binary has been submitted to a sandbox that auto-resolves DNS), the beacon trips the canary endpoint and terminates.

dns_canary: canary.yourdomain.com

The canary trip endpoint is unauthenticated (accessible to the relay without a JWT token) so the beacon can report even before full C2 registration. The canary resolution uses net.Resolver (cross-platform, no build tags needed).

Pre-Task OPSEC Checks¶

When anti_analysis is enabled, the beacon runs environment checks before executing sensitive tasks:

1. EDR detection -- 10 vendor process signatures (CrowdStrike, SentinelOne, Defender, Carbon Black, Cylance, ESET, Kaspersky, Sophos, Trend Micro, Symantec)
2. Sandbox indicators -- Low CPU count, small RAM, recent OS install, known sandbox usernames
3. Debugger detection -- IsDebuggerPresent, NtQueryInformationProcess(ProcessDebugPort)
4. VM indicators -- Registry keys for VMware/VirtualBox/Hyper-V, known MAC prefixes

A 2+ indicator threshold is required to trigger (single indicator is ignored to reduce false positives). See Anti-Analysis for runtime configuration.

Cleanup on Exit¶

When a guardrail is tripped or kill date is reached, CleanupArtifacts performs:

1. Removes 3 known scheduled task names used by persistence
2. Cleans 3 registry key patterns used by persistence
3. Self-deletes the beacon binary via a batch file (cmd /c del /q /f <path>)

Operational Recommendations¶

Pre-Engagement¶

Operational security starts before the first payload touches the target network.

Infrastructure Setup:

• Domain categorization: Register domains 30+ days before engagement. Submit to categorization services (Bluecoat, McAfee, Palo Alto) for legitimate classification. Domains less than 7 days old are flagged by most web proxies.
• TLS certificates: Use Let's Encrypt or purchase legitimate certificates. Self-signed certificates are flagged by SSL inspection appliances and generate browser warnings.
• Redirectors: Place Apache/nginx redirectors between implant traffic and the teamserver. Configure redirect rules to filter analyst probing (user-agent, IP ranges, timing).
• Malleable profiles: Use a malleable C2 profile that mimics legitimate traffic patterns (Microsoft 365, Slack, CDN). Test the profile against JA3/JA4 fingerprint databases.

Payload Testing:

• Build with garble: Always use obfuscate: true for engagement payloads. Test detection rates against the target's AV/EDR in a mirrored environment.
• Set guardrails: Configure IP, hostname, domain, or username guardrails to prevent execution on analyst sandboxes.
• Set kill dates: Every engagement payload should have a kill date set to the engagement end date plus a buffer period.
• Verify garble output: Run strings against the garbled binary to confirm no cleartext C2 URLs, error messages, or package paths remain.

Initial Access¶

The first payload execution is the highest-risk moment. An unknown binary running for the first time triggers the most aggressive scanning.

• Use the C stager for Go-signature avoidance. The MinGW C stager (~23KB) has no Go runtime, no pclntab, no goroutines. It downloads and executes the full implant in memory. Use this when the initial dropper must not be identified as Go.
• Select transport carefully. HTTPS with uTLS fingerprinting (chrome_auto) is the safest default. DNS C2 is useful for environments that block direct HTTPS but has lower bandwidth. SMB is for internal pivoting only (not initial access).
• Use malleable profiles. A well-configured malleable profile makes C2 traffic appear as legitimate HTTPS to inspection appliances. Without it, default HTTP patterns are easily signatured.
• Minimize initial footprint. Run opsec immediately after first check-in. Apply the appropriate evasion profile before executing any post-exploitation commands.

Post-Exploitation¶

Every command executed through the beacon generates artifacts. Minimize footprint by choosing execution methods carefully.

• Prefer BOF over fork-and-run. Beacon Object Files execute inline in the beacon process -- no child process creation, no injection, no sacrificial process termination. Fork-and-run spawns a visible child process that EDR monitors.
• Prefer inline-execute over execute-assembly. For .NET tools, inline execution avoids the CLR loading artifacts that process-level .NET profiling detects.
• Manage sleep intervals. Interactive mode (sleep 0) generates continuous network traffic. Use sleep 5 for active operations and return to sleep 60+ when idle. Jitter prevents pattern detection.
• Monitor event log generation. Every technique generates specific Windows events. Be aware of which events your current operation produces (see the detection surface tables above).

Lateral Movement¶

Moving between systems generates authentication events that SOCs correlate across the environment.

• Avoid repeating PtH to the same target. Pass-the-Hash to the same system from the same source generates a pattern that automated correlation detects. Vary source beacons and techniques.
• Clean up services after PsExec. PsExec creates a service (Event 7045) that persists after execution. Delete the service immediately after use.
• Be aware of timestamps. Lateral movement during off-hours (3:00 AM login from workstation) generates alerts. Match activity to expected business hours for the target account.
• Prefer WMI or DCOM over PsExec. WMI execution and DCOM abuse generate fewer distinctive artifacts than service-based execution. WMI is especially good because WMI activity is common in enterprise environments.
• Use token impersonation for legitimate context. Steal tokens from processes owned by users who would legitimately access the target system, then move laterally in that context.

Persistence and Long-Haul¶

Long-running operations require careful attention to beacon behavior patterns.

• Sleep interval management. Long-haul beacons should use sleep intervals of 300+ seconds with 30-40% jitter. Low-and-slow check-in patterns are significantly harder to detect via network anomaly detection.
• Transport rotation. If operating over multiple days, consider rotating between transports (HTTPS to DNS, or between different HTTPS endpoints) to avoid consistent pattern detection.
• Beacon check-in patterns. Even with jitter, a beacon that checks in at perfectly regular intervals stands out. The combination of sleep + jitter creates natural variation, but be aware that extremely long engagements may show patterns in aggregate.
• Persistence mechanism diversity. Do not rely on a single persistence mechanism. Use COM hijacking (stealthy, low detection) as primary and a scheduled task (reliable, high detection) as backup. Test persistence survival across reboots in the lab.
• Credential refresh. Kerberos tickets and NTLM sessions expire. Plan for credential refresh intervals and have a procedure for re-obtaining access if persistence survives but cached credentials expire.

Cleanup¶

Engagement cleanup is an OPSEC obligation. Remove or document all artifacts left on target systems.

Event Log Awareness:

Each technique generates specific Windows events. Key events to be aware of:

Artifact Removal:

• Delete dropped files. Remove any executables, DLLs, or scripts placed on disk. Use timestomp to restore original timestamps on directories you accessed.
• Remove persistence mechanisms. Delete registry keys, scheduled tasks, services, and COM hijack entries. Verify removal with a second check.
• Clean up service artifacts. PsExec services, WMI subscriptions, and DCOM registrations should all be removed.
• Use timestomp for file operations. The timestomp command (T1070.006) modifies file timestamps to match the surrounding files, reducing timeline analysis effectiveness. See file operations for details.
• Document what cannot be removed. Some artifacts (event log entries, ETW traces, kernel-level audit records) cannot be removed post-execution. Document these in your engagement report so the client can reset baselines.

Context Menu Risk Indicators¶

The cockpit context menu displays a color-coded OPSEC risk dot next to every technique, giving operators an at-a-glance risk assessment before execution.

Color	Risk Level	What It Means
	Low	Passive enumeration, configuration reads, benign API calls. Generates minimal telemetry. Safe for initial reconnaissance.
	Medium	Active operations with moderate detection footprint. Fork-and-run, token manipulation, file operations, UAC bypass, LOLBins.
	High	Operations touching heavily monitored resources: LSASS, SAM, NTDS, process injection, credential dumping, PowerShell, destructive operations. Most EDRs flag these immediately.

Risk levels are defined in the knowledge base YAML metadata (server/knowledge_base/techniques/) and served via the API -- they are not hardcoded in the UI and can be tuned per engagement.

See the Context Menu Guide for the full list of visual indicators including privilege badges and OS filtering.

Cross-References¶

• Evasion Kits -- Build-time evasion options, custom kits (Artifact, Resource, UDRL, Sleep Mask), and the full evasion options reference table
• Evasion Commands -- Runtime evasion command syntax, API examples, and recommended profiles for each command
• Process Injection -- Injection technique details, supported methods, and per-technique OPSEC considerations
• Credential Access -- Credential harvesting commands with OPSEC guidance per technique
• Malleable Profiles -- Network-level OPSEC via traffic shaping, TLS fingerprint masking, and HTTP transformation